From nobody Mon Jan 5 02:26:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130C31A1B8A for ; Mon, 5 Jan 2015 02:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.11 X-Spam-Level: X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6DtEi67j1xZ for ; Mon, 5 Jan 2015 02:26:11 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAFB1A6D3F for ; Mon, 5 Jan 2015 02:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1542; q=dns/txt; s=iport; t=1420453571; x=1421663171; h=message-id:date:from:mime-version:to:subject; bh=kb0VRLvX3FOHX9AuPF8iy7NODOTWXx5rD0ZwoSS9AXc=; b=PZVYn2TGCcA6JbwqMPDj5ImR0nWkK/EyPDavmaYH0y7ZzFUvxxqzeoBn BBNiC95o814f0RLtjpXSzskHwMDplpP0vtPNO3FSK7NIQkaEomg7QvBjG XjXgB3E4RWpziF4UHRa4Vlmj4MPLsdI0A0yfMbs2cnz5EcNImLro2Lzyf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAKJlqlStJssW/2dsb2JhbABcg1jGd4cPAQEBAQF9hAOBCB8BHRYYAwIBAgFLDQgBAYgoDZlQowABAQEHAQEBARoElCcFlwiGBItMIoNvPYJ0AQEB X-IronPort-AV: E=Sophos;i="5.07,698,1413244800"; d="scan'208,217";a="300407728" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Jan 2015 10:26:08 +0000 Received: from [10.61.99.148] (dhcp-10-61-99-148.cisco.com [10.61.99.148]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t05AQ8DJ002118 for ; Mon, 5 Jan 2015 10:26:08 GMT Message-ID: <54AA62E9.5030105@cisco.com> Date: Mon, 05 Jan 2015 11:09:45 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: multipart/alternative; boundary="------------090600040902010003010109" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/REuB_UZ1rs3qIihbWn-jNFWXtPY Subject: [radext] RADEXT co-chair replacement X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 10:26:13 -0000 This is a multi-part message in MIME format. --------------090600040902010003010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Jouni expressed the desire to step down as RADEXT co-chair. I would like to thank Jouni for all these years of RADIUS dedication: You clearly made a difference! In terms of co-chair replacement, Lionel Morand accepted this open position. Lionel's chair experience, combined with a strong AAA knowledge , will provide a smooth transition, I'm sure! Regards, Benoit --------------090600040902010003010109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Jouni expressed the desire to step down as RADEXT co-chair.
I would like to thank Jouni for all these years of RADIUS dedication: You clearly made a difference!

In terms of co-chair replacement, Lionel Morand accepted this open position.
Lionel's chair experience, combined with a strong AAA knowledge, will provide a smooth transition, I'm sure!

Regards, Benoit

--------------090600040902010003010109-- From nobody Mon Jan 5 05:28:48 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18AB1A879F for ; Mon, 5 Jan 2015 05:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPUFH9pMhK9q for ; Mon, 5 Jan 2015 05:28:45 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47F41A7018 for ; Mon, 5 Jan 2015 05:28:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6353320550 for ; Mon, 5 Jan 2015 08:24:18 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3dGWh7__DzF for ; Mon, 5 Jan 2015 08:24:18 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-157-131-57.hsd1.ma.comcast.net [50.157.131.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 5 Jan 2015 08:24:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 72A3780EC9; Mon, 5 Jan 2015 08:28:33 -0500 (EST) From: Sam Hartman To: radext@ietf.org Date: Mon, 05 Jan 2015 08:28:33 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/radext/XL9Qw4qE4AdYb5dj8zEIAxCom5Q Subject: [radext] draft-ietf-radext-bigger-packets update in early February X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:28:46 -0000 Hi, folks. I'm in the middle of some significant deadlines at work and it will be early February before I get around to updating bigger packets. It's about to expire so I plan to republish without updates, but this version will not include Alan's fixes for the last call comments. --Sam From nobody Thu Jan 8 04:12:42 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C2F1A89F0 for ; Thu, 8 Jan 2015 04:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.21 X-Spam-Level: X-Spam-Status: No, score=-12.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZVNW4WhfkA4 for ; Thu, 8 Jan 2015 04:12:32 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E841ACD1A for ; Thu, 8 Jan 2015 04:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3522; q=dns/txt; s=iport; t=1420719150; x=1421928750; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=p3riW8v1dYIg24wzaEoJhGKic8QYfVpLSlaEkm5ZqL8=; b=kzYutmg36QKu3Hcq5TocGDiW87UkmJdKQod939U5jhwqctzAtx8mE+AM TApN86oQHjE+u0RDyXDHCN3JtZsW7Fnxnj3SSpdQ1WZNcI+34Xpgpl6Bf 3Ym1qLmFXwx9hiWXZsIS6PWrgrl0I/Y1Lm+rvAgU2fTHycQBLpNCBL3hr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAPxyrlStJssW/2dsb2JhbABcg1hYxgSFcQKBVAEBAQEBfYQNAQEEeAEQDx0WDwkDAgECAUUGDQEHAQGIKA3GNwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjygBAUsEB4QpBZF2ggODQYEOgnGCF4gfgzkig289MQGBC4E3AQEB X-IronPort-AV: E=Sophos;i="5.07,722,1413244800"; d="scan'208,217";a="303699615" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 08 Jan 2015 12:12:28 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t08CCR1h004160; Thu, 8 Jan 2015 12:12:27 GMT Message-ID: <54AE742B.9090509@cisco.com> Date: Thu, 08 Jan 2015 13:12:27 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <54AE70A5.6070407@cisco.com> In-Reply-To: <54AE70A5.6070407@cisco.com> X-Forwarded-Message-Id: <54AE70A5.6070407@cisco.com> Content-Type: multipart/alternative; boundary="------------010905000604000409040809" Archived-At: Cc: Kathleen Moriarty Subject: [radext] RADEXT WG transition to Kathleen as Responsible AD X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:12:36 -0000 This is a multi-part message in MIME format. --------------010905000604000409040809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, In order to execute the IESG YANG Model Work Redistribution plan (see https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html) and in accordance with the IETF areas re-organisation steps (see https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html), Kathleen Moriarty will become the RADEXT responsible AD. You will be in good hands with Kathleen, who will also be the DIME responsible AD. Note that RADEXT WG will remain in the OPS area. While Kathleen will be the responsible starting now, this change will only appear on the charter page in a little bit (we're targeting mid February). Indeed, the tooling aspects will have to checked: we might face a few issues when a non-OPS AD is responsible for an OPS WG. I will continue processing the drafts for which I started the AD review. Practically, it means: -draft-ietf-radext-nai-15 -draft-ietf-radext-radius-fragmentation-09 Note that I don't disappear from the IESG and I'm always available if you require my help, but Kathleen is now your responsible AD. It was a pleasure being your AD for the last 3 years. Please continue the good work. Regards, Benoit --------------010905000604000409040809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dear all,

In order to execute the IESG YANG Model Work Redistribution plan (see 
https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html) and in 
accordance with the IETF areas re-organisation steps (see 
https://www.ietf.org/mail-archive/web/ietf/current/msg91015.html), 
Kathleen Moriarty will become the RADEXT responsible AD. You will be in 
good hands with Kathleen, who will also be the DIME responsible AD.

Note that RADEXT WG will remain in the OPS area. While Kathleen will be 
the responsible starting now, this change will only appear on the 
charter page in a little bit (we're targeting mid February). Indeed, the 
tooling aspects will have to checked: we might face a few issues when a 
non-OPS AD is responsible for an OPS WG.

I will continue processing the drafts for which I started the AD review.
Practically, it means:
    - draft-ietf-radext-nai-15
    - draft-ietf-radext-radius-fragmentation-09

Note that I don't disappear from the IESG and I'm always available if you require 
my help, but Kathleen is now your responsible AD.

It was a pleasure being your AD for the last 3 years. Please continue 
the good work.

Regards, Benoit

--------------010905000604000409040809-- From nobody Fri Jan 9 00:55:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A48C1A8730; Fri, 9 Jan 2015 00:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSVaR7CBlc3F; Fri, 9 Jan 2015 00:55:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4B31A86FE; Fri, 9 Jan 2015 00:55:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109085508.20842.98092.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 00:55:08 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 08:55:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Support of fragmentation of RADIUS packets Authors : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-10.txt Pages : 35 Date : 2015-01-09 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy RADIUS Clients and Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 9 00:55:19 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BBB1A8730 for ; Fri, 9 Jan 2015 00:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvTSK3d18xkJ; Fri, 9 Jan 2015 00:55:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5891A871D; Fri, 9 Jan 2015 00:55:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, bclaise@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109085509.20842.44036.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 00:55:09 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-radius-fragmentation-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 08:55:13 -0000 A new version (-10) has been submitted for draft-ietf-radext-radius-fragmentation: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Jan 9 06:26:58 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3341A8AA8; Fri, 9 Jan 2015 06:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWLby63gyInp; Fri, 9 Jan 2015 06:26:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF871A8972; Fri, 9 Jan 2015 06:26:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109142651.10928.13057.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 06:26:51 -0800 From: IETF Secretariat Archived-At: Subject: [radext] Telechat update notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:26:53 -0000 Placed on agenda for telechat - 2015-01-22 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Fri Jan 9 12:05:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370271AC3E9 for ; Fri, 9 Jan 2015 12:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3CkVg50btRz; Fri, 9 Jan 2015 12:05:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 944361A9109; Fri, 9 Jan 2015 12:05:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109200533.12415.46588.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 12:05:33 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 20:05:36 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Sat Jan 17 12:43:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446B61AD0C4; Sat, 17 Jan 2015 12:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFycSu3JxepP; Sat, 17 Jan 2015 12:43:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C33ED1ACEE4; Sat, 17 Jan 2015 12:43:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150117204311.10536.79379.idtracker@ietfa.amsl.com> Date: Sat, 17 Jan 2015 12:43:11 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radius-fragmentation-10: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 20:43:13 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-radext-radius-fragmentation-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for positioning this as Experimental and for writing sections 2 and 3: they cleared up any concerns I had. In section 3 you say: Instead, the CoA client MUST send a CoA-Request packet containing session identification attributes, along with Service-Type = Additional-Authorization, and a State attribute. Implementations not supporting fragmentation will respond with a CoA- NAK, and an Error-Cause of Unsupported-Service. Since this is not new behaviour (i.e. an implementation that is not part of this experiment will follow this behaviour according to previous specifications), a reference would be nice. Perhaps... s/the CoA client MUST/according to [RFCfoo] the CoA client will/ From nobody Mon Jan 19 01:15:59 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481971AD360; Mon, 19 Jan 2015 01:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkEOrFZJOd8r; Mon, 19 Jan 2015 01:15:46 -0800 (PST) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id A437F1AD355; Mon, 19 Jan 2015 01:15:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id B94534AF1; Mon, 19 Jan 2015 10:15:42 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dK4HSVnqpFav; Mon, 19 Jan 2015 10:15:42 +0100 (CET) Received: from [155.54.205.116] (inf-205-116.inf.um.es [155.54.205.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id 19893982; Mon, 19 Jan 2015 10:15:35 +0100 (CET) Message-ID: <54BCCB36.4050404@um.es> Date: Mon, 19 Jan 2015 10:15:34 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Adrian Farrel , The IESG References: <20150117204311.10536.79379.idtracker@ietfa.amsl.com> In-Reply-To: <20150117204311.10536.79379.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radius-fragmentation-10: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 09:15:50 -0000 > Adrian Farrel has entered the following ballot position for > draft-ietf-radext-radius-fragmentation-10: No Objection > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for positioning this as Experimental and for writing sections 2 > and 3: they cleared up any concerns I had. > > In section 3 you say: > Instead, the CoA client MUST send a CoA-Request > packet containing session identification attributes, along with > Service-Type = Additional-Authorization, and a State attribute. > Implementations not supporting fragmentation will respond with a CoA- > NAK, and an Error-Cause of Unsupported-Service. > Since this is not new behaviour (i.e. an implementation that is not part > of this experiment will follow this behaviour according to previous > specifications), a reference would be nice. Perhaps... > s/the CoA client MUST/according to [RFCfoo] the CoA client will/ > > Hi Adrian, thanks for the comment. It makes total sense. We will do that when we are requested to produce a new version. Regards, Alejandro From nobody Mon Jan 19 15:35:31 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924E51B2D29; Mon, 19 Jan 2015 15:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2RyIkyy2yQw; Mon, 19 Jan 2015 15:35:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9381ACE82; Mon, 19 Jan 2015 15:35:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119233529.24420.90147.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 15:35:29 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Barry Leiba's Discuss on draft-ietf-radext-radius-fragmentation-10: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 23:35:30 -0000 Barry Leiba has entered the following ballot position for draft-ietf-radext-radius-fragmentation-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is just to make sure that the IANA allocations are clear, because I have some questions about that: -- Section 14 -- In particular, this document defines two new RADIUS attributes, entitled "Frag-Status" and "Proxy-State-Len" (see section 9), assigned values of TBD1 and TBD2 from the Long Extended Space But these are not defined in Section 9, but in Sections 10.1 and 10.2. And I see that these are the "Type" values, but where's the allocation of the "Extended-Type" values that are mentioned in those sections? Also, there's another "TBA" at the end of Section 14 that points to Section 4.1, but there is no Section 4.1. It looks like maybe that's supposed to be 5.1. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This seems a very well written document, and was easy to read. In particular, thanks very much for Section 2: it's one of the best of that sort of explanation I've seen, and should be a model for other such specs. Very minor point: In the diagram in Section 3, I suggest fitting all the boxed text as in the box that includes "CoA Proxy". That is, putting "CoA" on top of "Server" and "client" (why not "Client"?) in the other boxes makes the separation between the left-side text and the right-side text just a little clearer. -- Sections 10.1 and 10.2 -- It's not clear to me how the RFC Editor will know which values to replace into the four "TBA" items in these sections (two "Type" and two "Extended-Type" values). Shouldn't they be distinguished from each other, to make that clear? (And see my DISCUSS comments.) From nobody Mon Jan 19 23:43:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249561B2D75; Mon, 19 Jan 2015 23:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk2XdwKteqIj; Mon, 19 Jan 2015 23:43:37 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id C66A91B2D68; Mon, 19 Jan 2015 23:43:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 61E2CF0E; Tue, 20 Jan 2015 08:43:34 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SDwhtHaAEbHk; Tue, 20 Jan 2015 08:43:34 +0100 (CET) Received: from [10.42.0.18] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 8785F215; Tue, 20 Jan 2015 08:43:29 +0100 (CET) Message-ID: <54BE0721.6060401@um.es> Date: Tue, 20 Jan 2015 08:43:29 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150119233529.24420.90147.idtracker@ietfa.amsl.com> In-Reply-To: <20150119233529.24420.90147.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020206000204010801040500" Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] Barry Leiba's Discuss on draft-ietf-radext-radius-fragmentation-10: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 07:43:40 -0000 This is a multi-part message in MIME format. --------------020206000204010801040500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Barry, thanks for your comments. See my responses inline, please. El 20/01/15 a las 00:35, Barry Leiba escribiÃ³: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is just to make sure that the IANA allocations are clear, because I > have some questions about that: > > -- Section 14 -- > > In particular, this document defines two new RADIUS attributes, > entitled "Frag-Status" and "Proxy-State-Len" (see section 9), > assigned values of TBD1 and TBD2 from the Long Extended Space > > But these are not defined in Section 9, but in Sections 10.1 and 10.2. Right. It seems I forgot inserting an in this place, and therefore it didn't get updated when we included the new section 2. > > And I see that these are the "Type" values, but where's the allocation of > the "Extended-Type" values that are mentioned in those sections? Yes. Indeed, this is something the IANA already brought in. Lionel Morand provided suggestion of how to solve this issue, that has been agreed by us as the best way forward. In particular, the type will be fixed to 241, whereas the Extended-Type would be TBDX. The table would look as follows: Type Name Length Meaning ---- ---- ------ ------- 241.TBD1 Frag-Status 7 Signals fragmentation 241.TBD2 Proxy-State-Len(*gth*) 7 Indicates the length of the received Proxy-State attributes And the text in section 10.1 and 10.2 would be: Type 241 (To be confirmed by IANA) Length 7 Extended-Type TBDX > > Also, there's another "TBA" at the end of Section 14 that points to > Section 4.1, but there is no Section 4.1. It looks like maybe that's > supposed to be 5.1. Yes. In figure elements it seems that tags are not possible, and I forgot to update these numbers when Section 2 was introduced. The same has happened with the table immediately above that one, which points to Section 9.1 while it should say 10.1. Both need to be updated. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This seems a very well written document, and was easy to read. In > particular, thanks very much for Section 2: it's one of the best of that > sort of explanation I've seen, and should be a model for other such > specs. Thanks. > > Very minor point: In the diagram in Section 3, I suggest fitting all the > boxed text as in the box that includes "CoA Proxy". That is, putting > "CoA" on top of "Server" and "client" (why not "Client"?) in the other > boxes makes the separation between the left-side text and the right-side > text just a little clearer. We'll do it. Thanks. > > -- Sections 10.1 and 10.2 -- > It's not clear to me how the RFC Editor will know which values to replace > into the four "TBA" items in these sections (two "Type" and two > "Extended-Type" values). Shouldn't they be distinguished from each > other, to make that clear? (And see my DISCUSS comments.) > > See my comments above. Now TBA is only applied to the "Additional-Authorization" value. Best regards, Alejandro --------------020206000204010801040500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Barry,

thanks for your comments. See my responses inline, please.

El 20/01/15 a las 00:35, Barry Leiba escribiÃ³:

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is just to make sure that the IANA allocations are clear, because I
have some questions about that:

-- Section 14 --

   In particular, this document defines two new RADIUS attributes,
   entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
   assigned values of TBD1 and TBD2 from the Long Extended Space

But these are not defined in Section 9, but in Sections 10.1 and 10.2.

Right. It seems I forgot inserting an <xref> in this place, and therefore it didn't get updated when we included the new section 2.


And I see that these are the "Type" values, but where's the allocation of
the "Extended-Type" values that are mentioned in those sections?

Yes. Indeed, this is something the IANA already brought in. Lionel Morand provided suggestion of how to solve this issue, that has been agreed by us as the best way forward. In particular, the type will be fixed to 241, whereas the Extended-Type would be TBDX.

The table would look as follows:
Â Â Â Â Â Â TypeÂ Â Â Â Â Â NameÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â LengthÂ Meaning
Â Â Â Â Â Â ----Â Â Â Â Â Â ----Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ------Â -------
Â Â Â Â Â Â 241.TBD1Â Â Frag-StatusÂ Â Â Â Â Â Â Â Â Â Â 7Â Â Â Â Â Â Signals fragmentation
Â Â Â Â Â Â 241.TBD2Â Â Proxy-State-Len(*gth*) 7Â Â Â Â Â Â Indicates the length of the
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â received Proxy-State attributes

And the text in section 10.1 and 10.2 would be:

Â Â Â TypeÂ
Â Â Â Â Â 241 (To be confirmed by IANA)
Â Â Â Â Â Length
Â Â Â Â Â 7
Â Â Â Â Â Â Extended-TypeÂ
Â Â Â Â Â TBDX


Also, there's another "TBA" at the end of Section 14 that points to
Section 4.1, but there is no Section 4.1.  It looks like maybe that's
supposed to be 5.1.

Yes. In figure elements it seems that <xref> tags are not possible, and I forgot to update these numbers when Section 2 was introduced. The same has happened with the table immediately above that one, which points to Section 9.1 while it should say 10.1. Both need to be updated.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This seems a very well written document, and was easy to read.  In
particular, thanks very much for Section 2: it's one of the best of that
sort of explanation I've seen, and should be a model for other such
specs.

Thanks.


Very minor point: In the diagram in Section 3, I suggest fitting all the
boxed text as in the box that includes "CoA Proxy".  That is, putting
"CoA" on top of "Server" and "client" (why not "Client"?) in the other
boxes makes the separation between the left-side text and the right-side
text just a little clearer.

We'll do it. Thanks.


-- Sections 10.1 and 10.2 --
It's not clear to me how the RFC Editor will know which values to replace
into the four "TBA" items in these sections (two "Type" and two
"Extended-Type" values).  Shouldn't they be distinguished from each
other, to make that clear?  (And see my DISCUSS comments.)

See my comments above. Now TBA is only applied to the "Additional-Authorization" value.

Best regards,
Alejandro

--------------020206000204010801040500-- From nobody Tue Jan 20 03:55:27 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B971B2A1B; Tue, 20 Jan 2015 03:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2w9KWyDAVjN; Tue, 20 Jan 2015 03:55:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 637D91B29EB; Tue, 20 Jan 2015 03:55:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120115521.18529.86484.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 03:55:21 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 11:55:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Support of fragmentation of RADIUS packets Authors : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-11.txt Pages : 35 Date : 2015-01-20 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy RADIUS Clients and Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 20 03:55:29 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72291B2A1B for ; Tue, 20 Jan 2015 03:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfuw442arFym; Tue, 20 Jan 2015 03:55:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B33BA1B2A09; Tue, 20 Jan 2015 03:55:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, bclaise@cisco.com, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120115521.18529.73157.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 03:55:21 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-radius-fragmentation-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 11:55:26 -0000 A new version (-11) has been submitted for draft-ietf-radext-radius-fragmentation: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Jan 20 06:47:27 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116AC1B2DB5; Tue, 20 Jan 2015 06:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwm57bLbBuWV; Tue, 20 Jan 2015 06:47:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BD31B2CCE; Tue, 20 Jan 2015 06:47:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120144720.5579.43507.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 06:47:20 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Spencer Dawkins' No Objection on draft-ietf-radext-radius-fragmentation-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 14:47:26 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-radext-radius-fragmentation-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I echo Adrian's thanks for positioning this as Experimental, and describing what the experiment is. I echo Barry's "well-written document". I'm delighted to read this text: 12.4. Transport behaviour This proposal does not modify the way RADIUS interacts with the underlying transport (UDP). That is, RADIUS keeps following a lock- step behaviour, that requires receiving an explicit acknowledge for each chunk sent. Hence, bursts of traffic which could congest links between peers are not an issue. From nobody Tue Jan 20 07:07:10 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60DB1B2DB8; Tue, 20 Jan 2015 07:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi7JdjCyPVd4; Tue, 20 Jan 2015 07:06:45 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF211B2A02; Tue, 20 Jan 2015 07:06:37 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so34719653lab.9; Tue, 20 Jan 2015 07:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0omlV2ve2lUJ5RGDA1wujBD6e1Y9K3no7C9Qm9kaIu4=; b=vdQdjrhHM+Q0ktmVip86DyaSZLrToFAYcFqQk+XtHDStySEaAAG7gcuxBOPwYA3xGT IebbEO3SVjcPXWPkBYu+NwnMzZGDPS2+KVtz7fHpMMLYeyIxpHPZ3bhE2EjF5whl5n5g /3jtClZ9dAey+0SQ+X21gLkCBBjHzSkFriE0p6Sgh/mem723kUYACodLhqNITSKyPLoo P1FiFsg5QMQVFadPboTsDUQSpI2sru2k4FYkg2UIcX13rbNi5ISnZpwWgZTTTg6hgFOW OeIglfci90F46qOAU31LAL+Xg8om6IIWQjF4qdB8d6ptVmGx2F/Mmlby7ppeGk559yCS 3Low== MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr3011052lab.1.1421766395322; Tue, 20 Jan 2015 07:06:35 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 20 Jan 2015 07:06:35 -0800 (PST) In-Reply-To: <54BE0721.6060401@um.es> References: <20150119233529.24420.90147.idtracker@ietfa.amsl.com> <54BE0721.6060401@um.es> Date: Tue, 20 Jan 2015 10:06:35 -0500 X-Google-Sender-Auth: Q_B8QoYYZ8ytCXJxO6vTZKkxoP4 Message-ID: From: Barry Leiba To: Alejandro Perez Mendez Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "radext@ietf.org" , Stefan Winter , The IESG , "radext-chairs@tools.ietf.org" , draft-ietf-radext-radius-fragmentation.all@tools.ietf.org Subject: Re: [radext] Barry Leiba's Discuss on draft-ietf-radext-radius-fragmentation-10: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:06:47 -0000 X-List-Received-Date: Tue, 20 Jan 2015 15:06:47 -0000 Thanks for the quick response, Alejandro. It all sounds good, and I'm ready to clear the DISCUSS as soon as I see the revised I-D. Barry On Tue, Jan 20, 2015 at 2:43 AM, Alejandro Perez Mendez wrote: > Hi Barry, > > thanks for your comments. See my responses inline, please. > > El 20/01/15 a las 00:35, Barry Leiba escribi=F3: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is just to make sure that the IANA allocations are clear, because I > have some questions about that: > > -- Section 14 -- > > In particular, this document defines two new RADIUS attributes, > entitled "Frag-Status" and "Proxy-State-Len" (see section 9), > assigned values of TBD1 and TBD2 from the Long Extended Space > > But these are not defined in Section 9, but in Sections 10.1 and 10.2. > > > Right. It seems I forgot inserting an in this place, and therefore= it > didn't get updated when we included the new section 2. > > > And I see that these are the "Type" values, but where's the allocation of > the "Extended-Type" values that are mentioned in those sections? > > > Yes. Indeed, this is something the IANA already brought in. Lionel Morand > provided suggestion of how to solve this issue, that has been agreed by u= s > as the best way forward. In particular, the type will be fixed to 241, > whereas the Extended-Type would be TBDX. > > The table would look as follows: > > Type Name Length Meaning > ---- ---- ------ ------- > 241.TBD1 Frag-Status 7 Signals fragmentation > 241.TBD2 Proxy-State-Len(*gth*) 7 Indicates the length of = the > received Proxy-State > attributes > > And the text in section 10.1 and 10.2 would be: > > Type > 241 (To be confirmed by IANA) > > Length > 7 > > Extended-Type > TBDX > > > Also, there's another "TBA" at the end of Section 14 that points to > Section 4.1, but there is no Section 4.1. It looks like maybe that's > supposed to be 5.1. > > > Yes. In figure elements it seems that tags are not possible, and I > forgot to update these numbers when Section 2 was introduced. The same ha= s > happened with the table immediately above that one, which points to Secti= on > 9.1 while it should say 10.1. Both need to be updated. > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This seems a very well written document, and was easy to read. In > particular, thanks very much for Section 2: it's one of the best of that > sort of explanation I've seen, and should be a model for other such > specs. > > > Thanks. > > > Very minor point: In the diagram in Section 3, I suggest fitting all the > boxed text as in the box that includes "CoA Proxy". That is, putting > "CoA" on top of "Server" and "client" (why not "Client"?) in the other > boxes makes the separation between the left-side text and the right-side > text just a little clearer. > > > We'll do it. Thanks. > > > -- Sections 10.1 and 10.2 -- > It's not clear to me how the RFC Editor will know which values to replace > into the four "TBA" items in these sections (two "Type" and two > "Extended-Type" values). Shouldn't they be distinguished from each > other, to make that clear? (And see my DISCUSS comments.) > > > > See my comments above. Now TBA is only applied to the > "Additional-Authorization" value. > > Best regards, > Alejandro > From nobody Tue Jan 20 12:24:34 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FA61B2B64; Tue, 20 Jan 2015 12:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGvAVnXLheNC; Tue, 20 Jan 2015 12:24:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9421B2B68; Tue, 20 Jan 2015 12:24:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120202427.16025.25740.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 12:24:27 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Barry Leiba's No Objection on draft-ietf-radext-radius-fragmentation-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 20:24:29 -0000 Barry Leiba has entered the following ballot position for draft-ietf-radext-radius-fragmentation-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This seems a very well written document, and was easy to read. In particular, thanks very much for Section 2: it's one of the best of that sort of explanation I've seen, and should be a model for other such specs. Version -11 addresses all the minor comments I had; thanks. From nobody Wed Jan 21 02:26:43 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556461A1A02; Wed, 21 Jan 2015 02:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plFyiOIeI5AX; Wed, 21 Jan 2015 02:26:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B94D41A1A07; Wed, 21 Jan 2015 02:26:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121102634.30907.71805.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 02:26:34 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Martin Stiemerling's No Objection on draft-ietf-radext-radius-fragmentation-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:26:38 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-radext-radius-fragmentation-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A well-written document and thank you for being an experimental document. Looking forward to reports from the wild how good or bad it works. From nobody Wed Jan 21 10:22:04 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17371A1B6D; Wed, 21 Jan 2015 10:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70DniLEJVOxD; Wed, 21 Jan 2015 10:21:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98B1A1B71; Wed, 21 Jan 2015 10:21:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121182146.9534.92979.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 10:21:46 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Kathleen Moriarty's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:21:55 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-radext-radius-fragmentation-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In the security considerations section, I didn't see a discussion on packet re-assembly and associated security issues such as overlapping fragments. If there is a reference that already covers that in the draft, I missed it and would appreciate you pointing me to it. In a quick search, I found a couple of references that may be useful for some text/reference on details of this attack type, but are at the IP layer. The draft already prevents other attack types that involve ordering and size of fragments with lengths included, so this is just meant to ask about overlapping fragments. Section 4 of: https://tools.ietf.org/html/rfc1858 https://tools.ietf.org/html/draft-ietf-6man-overlap-fragment-03 Examples might overlap to change any part of the AAA data once reassembled. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft, I also agree that it is well written and placed well as experimental. From nobody Wed Jan 21 11:31:47 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867261A8722; Wed, 21 Jan 2015 11:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFj53Ar6iR-w; Wed, 21 Jan 2015 11:31:33 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8F11A871E; Wed, 21 Jan 2015 11:31:33 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so28325938lbv.3; Wed, 21 Jan 2015 11:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hbqPIIa4wybtUAsKmE3k8rO7SGDTxcUo6ZNCKac1jRw=; b=ZLlCZki8ZttzG5uw77N44TG1JmKBxGeFuavH3XafkmWVWMLH1W5+D/lBACIin0GYG+ E2sL7FY3Hc4T01gfRoG2sqFXWykK2Bud4w7lIfp6oC6RFXMgAnUO7uzuVhLSlVwmWlBK KTpMbuPX29X1SsENbpF3u6igp2699nhT44rXP6zU0wxhTXrZoENx+oupG81h4QqAHZ5u 3qhAG4NSUWI+Cdqh4MIJLQWEdHjxUcxKOuKClS1y9jHFCHVXyBgk42su8jAHoFMpNcp/ OnrS9BkwNCYuBUTTGxRKXRxGrwKVcBFRv2pCJZPYUwMqxWjgHviBEohK1MmEBy3gcGXH qcaA== MIME-Version: 1.0 X-Received: by 10.152.238.1 with SMTP id vg1mr46642188lac.83.1421868691683; Wed, 21 Jan 2015 11:31:31 -0800 (PST) Received: by 10.112.145.102 with HTTP; Wed, 21 Jan 2015 11:31:31 -0800 (PST) In-Reply-To: <81E348FD-93A4-422D-80E5-7498C229FC5D@networkradius.com> References: <20150121182146.9534.92979.idtracker@ietfa.amsl.com> <81E348FD-93A4-422D-80E5-7498C229FC5D@networkradius.com> Date: Wed, 21 Jan 2015 14:31:31 -0500 Message-ID: From: Kathleen Moriarty To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: radext@ietf.org, Winter Stefan , The IESG , "radext-chairs@tools.ietf.org" , draft-ietf-radext-radius-fragmentation.all@tools.ietf.org Subject: Re: [radext] Kathleen Moriarty's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:31:35 -0000 Alan, On Wed, Jan 21, 2015 at 2:18 PM, Alan DeKok wrote= : > On Jan 21, 2015, at 1:21 PM, Kathleen Moriarty wrote: >> In the security considerations section, I didn't see a discussion on >> packet re-assembly and associated security issues such as overlapping >> fragments. > > There are no overlapping fragments. The fragmentation method was desig= ned to avoid that. > > Unlike IP, there is no =E2=80=9Cfragment offset=E2=80=9D field. There = is simply a =E2=80=9Cfragment length=E2=80=9D field. The fragments are req= uested and received in lock-step order. The data in each fragment is appen= ded to the previous data. > >> If there is a reference that already covers that in the >> draft, I missed it and would appreciate you pointing me to it. > > Section 12.4 says: > > This proposal does not modify the way RADIUS interacts with the > underlying transport (UDP). That is, RADIUS keeps following a lock- > step behaviour, that requires receiving an explicit acknowledge for > each chunk sent. > > The overview in Section 4 describes the process. But it doesn=E2=80=99t= explicitly say that the fragments are simply appended. It just says: > > =E2=80=A6 When all the chunks have > been received, the original list of attributes is reconstructed and > processed as if it had been received in one packet. > > which leaves the =E2=80=9Creconstruction=E2=80=9D process open to interp= retation. > > We could add a short paragraph after the preaching text: > > The reconstruction process is performed by simply appending all of the ch= unks together. Unlike IPv4 fragmentation, there is no =E2=80=9Cfragment of= fset=E2=80=9D field. The chunks in this specification are explicitly order= ed, as RADIUS is a lock-step protocol, as noted in Section 12.4. That is, = chunk N+1 cannot be sent until all of the chunks up to and including N have= been received and acknowledged. > > We could also add text to the end of Section 12.4: > > Another benefit of the lock-step nature of RADIUS, is that there are no s= ecurity issues with overlapping fragments. Each chunk simply has a length,= with no =E2=80=9Cfragment offset=E2=80=9D field as with IPv4. The order o= f the fragments is determined by the order in which they are received. The= re is no ambiguity about the size or placement of each chunk, and therefore= no security issues associated with overlapping chunks. Thank you for the quick response and proposed text, this looks very good and I think is helpful. I'll switch to a yes when this text is added. --=20 Best regards, Kathleen From nobody Wed Jan 21 22:15:23 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615AE1AC41D; Wed, 21 Jan 2015 22:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiEzqn7QT3Yf; Wed, 21 Jan 2015 22:15:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6791AC411; Wed, 21 Jan 2015 22:15:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 22:15:16 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Pete Resnick's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 06:15:19 -0000 Pete Resnick has entered the following ballot position for draft-ietf-radext-radius-fragmentation-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have no concerns with the technical content of the document; I did a quick review, and nothing causes concern. But I do want to briefly DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on the call. The issue of "Updates" worries me a bit. Here's the part that concerned me: Note that if this experiment does not succeed, the "T" flag allocation would not persist, as it is tightly associated to this document. That's true, but using Updates will mean that RFC 6929 will *always* have an "Updated By" pointer pointing to this Experimental RFC. That itself could cause serious confusion, and would likely result in the "T" allocation never being able to be used again. I really don't think this document needs to, or should, update the other documents. 2865 and 6158 are only being updated because this document violates a MUST and a SHOULD. But it's an experiment. Any implementation of 2865 or 6158 not participating in the experiment is going to need to honor those MUSTs and SHOULDs. There's no real reason to call out this update to people who are only looking at those two documents. 6929 is a bit trickier, because of the issue of other folks trying to use the reserved value, but as you say in the document: "not such a great number of specifications extending that field are expected." If/when this document goes to Standards Track, that's the time to let people know. If there's a real fear of this experiment interfering with other implementations, it really is time to make the registry. Finally, I'm concerned about the precedent of Experimental documents updating Standards Track and BCP docs, especially on the grounds provided. Perhaps there's a case for that to happen once in a while, but we don't want pointers to possibly failed experiments to be in the meta-data forever. Like I said, we can sort this on the call pretty quickly. But I want to make sure we understand the implications here. From nobody Thu Jan 22 03:39:12 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91EC1AC7E7; Thu, 22 Jan 2015 03:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GFCXVv4E1XG; Thu, 22 Jan 2015 03:39:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2F91A1A15; Thu, 22 Jan 2015 03:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3198; q=dns/txt; s=iport; t=1421926750; x=1423136350; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rGCXDzQeLrOyxR7cPk3gCjBs1n0WMDPoN082SO10AZM=; b=PX4lcndp9lZ/EATMok7SSfcd5tysQFbTsDuQbNGByzsTTp2eV7iX49vz 422uNwO/Aqpxwa0+5rixykJHKAp94cqDEWM/BAGvqG8K8P1f2p2nlzQee 5WGfDK8DOptREH7dD+PmgzQ2ACwc1Kbt2P8QlLvG+fwYBAJa4hBFPyrW+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssEALPgwFStJssW/2dsb2JhbABag1hYvQmJMgyFJUoCgVsBAQEBAX2EDQEBBAEBATU2CgEQCw4TFg8JAwIBAgEVMAYBDAEFAgEBBYgjDdF7AQEBAQEBAQEBAQEBAQEBAQEBAQEBF48XEAIBTweEKQEEhT+McYVPgRQ2gkiCIIVUhi8igjKBPT0xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,448,1418083200"; d="scan'208";a="322366127" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2015 11:39:07 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0MBd5xv004080; Thu, 22 Jan 2015 11:39:06 GMT Message-ID: <54C0E159.3000500@cisco.com> Date: Thu, 22 Jan 2015 12:39:05 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick , The IESG References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> In-Reply-To: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] Pete Resnick's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 11:39:11 -0000 Hi Pete, For completeness, this was discussed on the RADEXT mailing list. See http://www.ietf.org/mail-archive/web/radext/current/msg09079.html Let's discuss during the IESG telechat. Regards, Benoit > Pete Resnick has entered the following ballot position for > draft-ietf-radext-radius-fragmentation-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have no concerns with the technical content of the document; I did a > quick review, and nothing causes concern. But I do want to briefly > DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on > the call. > > The issue of "Updates" worries me a bit. Here's the part that concerned > me: > > Note that if this experiment does not succeed, the > "T" flag allocation would not persist, as it is tightly associated to > this document. > > That's true, but using Updates will mean that RFC 6929 will *always* have > an "Updated By" pointer pointing to this Experimental RFC. That itself > could cause serious confusion, and would likely result in the "T" > allocation never being able to be used again. > > I really don't think this document needs to, or should, update the other > documents. 2865 and 6158 are only being updated because this document > violates a MUST and a SHOULD. But it's an experiment. Any implementation > of 2865 or 6158 not participating in the experiment is going to need to > honor those MUSTs and SHOULDs. There's no real reason to call out this > update to people who are only looking at those two documents. 6929 is a > bit trickier, because of the issue of other folks trying to use the > reserved value, but as you say in the document: "not such a great number > of specifications extending that field are expected." If/when this > document goes to Standards Track, that's the time to let people know. If > there's a real fear of this experiment interfering with other > implementations, it really is time to make the registry. Finally, I'm > concerned about the precedent of Experimental documents updating > Standards Track and BCP docs, especially on the grounds provided. Perhaps > there's a case for that to happen once in a while, but we don't want > pointers to possibly failed experiments to be in the meta-data forever. > > Like I said, we can sort this on the call pretty quickly. But I want to > make sure we understand the implications here. > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > . > From nobody Thu Jan 22 10:21:35 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38CB1ACF19; Thu, 22 Jan 2015 10:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMU_H36ni_-V; Thu, 22 Jan 2015 10:21:32 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC82C1ACEF6; Thu, 22 Jan 2015 10:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4241; q=dns/txt; s=iport; t=1421950876; x=1423160476; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=R0qQsIN410hV7vW3TXPo6E8TmFALnhrMCNvqZd4oZrY=; b=nEMnRdc+Ri77OJUzf0BFeFvScpR6KqDgPPTmklZcFyRqNQIf1krvu6l8 +CldEbJ/zAFwoEH2dY4ekUsa/L3yTTM/7HGJii1ewpKdxfZ+1ATH45WbV nquV4Rc4VxoimomC2tYMPWjturhewiIcMyVGamD9qNtZKIqBgw5MezMwV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssEANI+wVStJssW/2dsb2JhbABag1hYvQuJMgyFJUoCgVkBAQEBAX2EDQEBAwEBAQE1NgoBBQsLDhMWDwkDAgECARUwBgEMAQUCAQEFEogJCA3TQwEBAQEBAQEBAQEBAQEBAQEBAQEBARePFxEBUAeEKQEEhT+McYVPgRQ2gkiCIIVUhi8igjKBPT0xAYELgTcBAQE X-IronPort-AV: E=Sophos;i="5.09,450,1418083200"; d="scan'208";a="322083757" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2015 18:21:13 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0MILB5d006935; Thu, 22 Jan 2015 18:21:12 GMT Message-ID: <54C13F97.1090201@cisco.com> Date: Thu, 22 Jan 2015 19:21:11 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pete Resnick , The IESG References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> In-Reply-To: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] Pete Resnick's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 18:21:33 -0000 Dear all, This document was discussed during the IESG telechat today. There are 2 "update" types. 1. Update RFC 2865: Remote Authentication Dial In User Service (RADIUS) and RFC 6158: Radius design guidelines The question is: when an experimental RFC violates sentences from a standard track doc, do we want a forward pointer to that EXP RFC? The discussion went in the direction of not "updating" the standards RFCs. This is an experiment after all. 2. Update RFC 6929: Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions Here we have the issue of the T flag assignment. The IESG understands that this document effectively allocates a bit from the structure in RFC 6929. We evaluated multiple options: registry, "update" and then requiring yet another RFC if the experiment fails, no update. In the end, the propose solution is that this experimental RFC should not "update" RFC 6929. We should rely on the collective mind of the WG to recall that this T flag is used. When/if the experiment will be successful, the T flag will be properly assigned. So the next step is to publish a new revision without the 3 "updates", and including Kathleen's DISCUSS. Thanks and regards, Benoit > Pete Resnick has entered the following ballot position for > draft-ietf-radext-radius-fragmentation-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have no concerns with the technical content of the document; I did a > quick review, and nothing causes concern. But I do want to briefly > DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on > the call. > > The issue of "Updates" worries me a bit. Here's the part that concerned > me: > > Note that if this experiment does not succeed, the > "T" flag allocation would not persist, as it is tightly associated to > this document. > > That's true, but using Updates will mean that RFC 6929 will *always* have > an "Updated By" pointer pointing to this Experimental RFC. That itself > could cause serious confusion, and would likely result in the "T" > allocation never being able to be used again. > > I really don't think this document needs to, or should, update the other > documents. 2865 and 6158 are only being updated because this document > violates a MUST and a SHOULD. But it's an experiment. Any implementation > of 2865 or 6158 not participating in the experiment is going to need to > honor those MUSTs and SHOULDs. There's no real reason to call out this > update to people who are only looking at those two documents. 6929 is a > bit trickier, because of the issue of other folks trying to use the > reserved value, but as you say in the document: "not such a great number > of specifications extending that field are expected." If/when this > document goes to Standards Track, that's the time to let people know. If > there's a real fear of this experiment interfering with other > implementations, it really is time to make the registry. Finally, I'm > concerned about the precedent of Experimental documents updating > Standards Track and BCP docs, especially on the grounds provided. Perhaps > there's a case for that to happen once in a while, but we don't want > pointers to possibly failed experiments to be in the meta-data forever. > > Like I said, we can sort this on the call pretty quickly. But I want to > make sure we understand the implications here. > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > . > From nobody Thu Jan 22 10:24:49 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9701AD0A5 for ; Thu, 22 Jan 2015 10:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRu92UMd72UQ; Thu, 22 Jan 2015 10:24:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B77F91ACEF6; Thu, 22 Jan 2015 10:24:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122182446.14999.10443.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 10:24:46 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 18:24:48 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ From nobody Thu Jan 22 16:38:55 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4426A1A86F6; Wed, 21 Jan 2015 11:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrHCvzcPzhcJ; Wed, 21 Jan 2015 11:19:40 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4A371A8549; Wed, 21 Jan 2015 11:19:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 87AFE2240350; Wed, 21 Jan 2015 20:18:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_gwmWnxX61R; Wed, 21 Jan 2015 20:18:58 +0100 (CET) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id A702122401D3; Wed, 21 Jan 2015 20:18:56 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <20150121182146.9534.92979.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 14:18:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <81E348FD-93A4-422D-80E5-7498C229FC5D@networkradius.com> References: <20150121182146.9534.92979.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Thu, 22 Jan 2015 16:38:54 -0800 Cc: radext@ietf.org, Winter Stefan , The IESG , radext-chairs@tools.ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org Subject: Re: [radext] Kathleen Moriarty's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:19:42 -0000 On Jan 21, 2015, at 1:21 PM, Kathleen Moriarty = wrote: > In the security considerations section, I didn't see a discussion on > packet re-assembly and associated security issues such as overlapping > fragments. There are no overlapping fragments. The fragmentation method was = designed to avoid that. Unlike IP, there is no =93fragment offset=94 field. There is simply a = =93fragment length=94 field. The fragments are requested and received = in lock-step order. The data in each fragment is appended to the = previous data. > If there is a reference that already covers that in the > draft, I missed it and would appreciate you pointing me to it. Section 12.4 says: This proposal does not modify the way RADIUS interacts with the underlying transport (UDP). That is, RADIUS keeps following a lock- step behaviour, that requires receiving an explicit acknowledge for each chunk sent.=20 The overview in Section 4 describes the process. But it doesn=92t = explicitly say that the fragments are simply appended. It just says: =85 When all the chunks have been received, the original list of attributes is reconstructed and processed as if it had been received in one packet. which leaves the =93reconstruction=94 process open to interpretation. We could add a short paragraph after the preaching text: The reconstruction process is performed by simply appending all of the = chunks together. Unlike IPv4 fragmentation, there is no =93fragment = offset=94 field. The chunks in this specification are explicitly = ordered, as RADIUS is a lock-step protocol, as noted in Section 12.4. = That is, chunk N+1 cannot be sent until all of the chunks up to and = including N have been received and acknowledged. We could also add text to the end of Section 12.4: Another benefit of the lock-step nature of RADIUS, is that there are no = security issues with overlapping fragments. Each chunk simply has a = length, with no =93fragment offset=94 field as with IPv4. The order of = the fragments is determined by the order in which they are received. = There is no ambiguity about the size or placement of each chunk, and = therefore no security issues associated with overlapping chunks.= From nobody Fri Jan 23 05:12:28 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC171A90B6; Fri, 23 Jan 2015 05:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMmIJIWthPfI; Fri, 23 Jan 2015 05:12:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9581A90AE; Fri, 23 Jan 2015 05:12:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123131224.2371.18913.idtracker@ietfa.amsl.com> Date: Fri, 23 Jan 2015 05:12:24 -0800 Archived-At: Cc: radext@ietf.org, draft-ietf-radext-nai.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: [radext] Jari Arkko's No Objection on draft-ietf-radext-nai-15: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:12:25 -0000 Jari Arkko has entered the following ballot position for draft-ietf-radext-nai-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As far as I can see, and based on my attempt to find people who would still have an issue, we have cleared the issues that I worried about earlier. Thanks for the updates and working on this topic! From nobody Fri Jan 23 05:35:47 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327FF1A90B8; Fri, 23 Jan 2015 05:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JitwcT4HNZhe; Fri, 23 Jan 2015 05:35:32 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3422B1A90BA; Fri, 23 Jan 2015 05:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=746; q=dns/txt; s=iport; t=1422020132; x=1423229732; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=mbVEO/Tv5IXakmqwf8kBKkJDdcIdpj6OGxogv3txDM8=; b=VA+qgdECv4KnH2/poov/wfNINA7gRik7yQonhs9VM2nxYQk1zBSAsAcn AkLwkzkV5ABPCo7TmQ5KVWID+Xt/bYmOpa3HJFMRuFdWlnzUSW7QHponz PPHd8avI87RBomPeTirmIKCrOJ1BqxboXyoRYkaNMjahFGilEENOMZ70N U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEAI9NwlStJssW/2dsb2JhbABag1hZgn/DVIVjCoFZAQEBAQF9hDYVQTUCBSECEQJMDQEHAQEFiCMNvWOUYwEBAQEBAQEDAQEBAQEBHIEhjleCb4FBBZd/gRSCfoIgjAMig289gTYkgRoBAQE X-IronPort-AV: E=Sophos;i="5.09,453,1418083200"; d="scan'208";a="319051177" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 23 Jan 2015 13:35:30 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0NDZUhQ020492; Fri, 23 Jan 2015 13:35:30 GMT Message-ID: <54C24E21.50706@cisco.com> Date: Fri, 23 Jan 2015 14:35:29 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IESG IESG Subject: [radext] draft-ietf-radext-nai: 2 weeks review period X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:35:37 -0000 Dear all, This important document generated a lot of discussions during the IESG review, and those discussions led to some changes to the document. This is one of those situations were the changes are numerous. Therefore I would like to give one last opportunity for the WG to validate the latest document version (basically checking we didn't screw up anything). Please review the latest document version, or the diff compared to the draft version that left the WG: http://www.ietf.org/rfcdiff?url1=draft-ietf-radext-nai-10&difftype=--html&submit=Go!&url2=draft-ietf-radext-nai-15 If no feedback within the next two weeks, this version will be approved Thanks Alan for taking care of all of IESG issues. Regards, Benoit From nobody Fri Jan 23 05:41:52 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5AD1A90BA for ; Fri, 23 Jan 2015 05:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnsaXmSN7rW7 for ; Fri, 23 Jan 2015 05:41:47 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id A32271A90C0 for ; Fri, 23 Jan 2015 05:41:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E7CE822405D4; Fri, 23 Jan 2015 14:41:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tzXaORvXWWn; Fri, 23 Jan 2015 14:41:46 +0100 (CET) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id C88752240274; Fri, 23 Jan 2015 14:41:45 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <54C24E21.50706@cisco.com> Date: Fri, 23 Jan 2015 08:41:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54C24E21.50706@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] draft-ietf-radext-nai: 2 weeks review period X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:41:49 -0000 On Jan 23, 2015, at 8:35 AM, Benoit Claise wrote: > This important document generated a lot of discussions during the IESG = review, and those discussions led to some changes to the document. > This is one of those situations were the changes are numerous. = Therefore I would like to give one last opportunity for the WG to = validate the latest document version (basically checking we didn't screw = up anything). > Please review the latest document version, or the diff compared to the = draft version that left the WG: = http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-radext-nai-10&difftype=3D--h= tml&submit=3DGo!&url2=3Ddraft-ietf-radext-nai-15 The changes were largely clarifications. Additional text was added to = explain the NAI and it=92s use-cases. There was a clearer separation = made between the NAI format, and the NAI identifier. The format is what = the document standardizes. The identifier is a specific instance of = text using the NAI format. The use of =93we=94 was changed to a more = neutral term. The ABNF for the NAI was simplified. Alan DeKok. From nobody Tue Jan 27 02:19:15 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055181A877A; Tue, 27 Jan 2015 02:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr8s9HnY2F0A; Tue, 27 Jan 2015 02:18:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAA11A8767; Tue, 27 Jan 2015 02:18:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127101858.8419.73126.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 02:18:58 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 10:19:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Support of fragmentation of RADIUS packets Authors : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-12.txt Pages : 36 Date : 2015-01-27 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy RADIUS Clients and Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 27 02:19:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053831A877A for ; Tue, 27 Jan 2015 02:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1qzXmi1CR9s; Tue, 27 Jan 2015 02:19:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCD51A876D; Tue, 27 Jan 2015 02:18:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu, bclaise@cisco.com, presnick@qti.qualcomm.com, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127101859.8419.27059.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 02:18:59 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-radius-fragmentation-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 10:19:08 -0000 A new version (-12) has been submitted for draft-ietf-radext-radius-fragmentation: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-12.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Jan 27 02:20:09 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65A61A8776; Tue, 27 Jan 2015 02:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qub8fCUjw7wc; Tue, 27 Jan 2015 02:20:00 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 807771A8761; Tue, 27 Jan 2015 02:20:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id E3583C451; Tue, 27 Jan 2015 11:19:58 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dgxPRR2BQypQ; Tue, 27 Jan 2015 11:19:58 +0100 (CET) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 0A9B4C417; Tue, 27 Jan 2015 11:19:50 +0100 (CET) Message-ID: <54C76646.6030108@um.es> Date: Tue, 27 Jan 2015 11:19:50 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benoit Claise , Pete Resnick , The IESG References: <20150122061516.7611.80876.idtracker@ietfa.amsl.com> <54C13F97.1090201@cisco.com> In-Reply-To: <54C13F97.1090201@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: radext@ietf.org, draft-ietf-radext-radius-fragmentation.all@tools.ietf.org, radext-chairs@tools.ietf.org, stefan.winter@restena.lu Subject: Re: [radext] Pete Resnick's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 10:20:04 -0000 Dear Benoit, a new version has been submitted including the requested changes. Best regards, Alejandro El 22/01/15 a las 19:21, Benoit Claise escribió: > Dear all, > > This document was discussed during the IESG telechat today. > > There are 2 "update" types. > > 1. Update RFC 2865: Remote Authentication Dial In User Service > (RADIUS) and RFC 6158: Radius design guidelines > The question is: when an experimental RFC violates sentences from a > standard track doc, do we want a forward pointer to that EXP RFC? The > discussion went in the direction of not "updating" the standards RFCs. > This is an experiment after all. > > 2. Update RFC 6929: Remote Authentication Dial-In User Service > (RADIUS) Protocol Extensions > Here we have the issue of the T flag assignment. > The IESG understands that this document effectively allocates a bit > from the structure in RFC 6929. > We evaluated multiple options: registry, "update" and then requiring > yet another RFC if the experiment fails, no update. > In the end, the propose solution is that this experimental RFC should > not "update" RFC 6929. We should rely on the collective mind of the WG > to recall that this T flag is used. When/if the experiment will be > successful, the T flag will be properly assigned. > > So the next step is to publish a new revision without the 3 "updates", > and including Kathleen's DISCUSS. > > Thanks and regards, Benoit > >> Pete Resnick has entered the following ballot position for >> draft-ietf-radext-radius-fragmentation-11: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I have no concerns with the technical content of the document; I did a >> quick review, and nothing causes concern. But I do want to briefly >> DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on >> the call. >> >> The issue of "Updates" worries me a bit. Here's the part that concerned >> me: >> >> Note that if this experiment does not succeed, the >> "T" flag allocation would not persist, as it is tightly >> associated to >> this document. >> >> That's true, but using Updates will mean that RFC 6929 will *always* >> have >> an "Updated By" pointer pointing to this Experimental RFC. That itself >> could cause serious confusion, and would likely result in the "T" >> allocation never being able to be used again. >> >> I really don't think this document needs to, or should, update the other >> documents. 2865 and 6158 are only being updated because this document >> violates a MUST and a SHOULD. But it's an experiment. Any implementation >> of 2865 or 6158 not participating in the experiment is going to need to >> honor those MUSTs and SHOULDs. There's no real reason to call out this >> update to people who are only looking at those two documents. 6929 is a >> bit trickier, because of the issue of other folks trying to use the >> reserved value, but as you say in the document: "not such a great number >> of specifications extending that field are expected." If/when this >> document goes to Standards Track, that's the time to let people know. If >> there's a real fear of this experiment interfering with other >> implementations, it really is time to make the registry. Finally, I'm >> concerned about the precedent of Experimental documents updating >> Standards Track and BCP docs, especially on the grounds provided. >> Perhaps >> there's a case for that to happen once in a while, but we don't want >> pointers to possibly failed experiments to be in the meta-data forever. >> >> Like I said, we can sort this on the call pretty quickly. But I want to >> make sure we understand the implications here. >> >> >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> . >> >