From mauricio.sanchez@hp.com Wed Sep 5 12:07:10 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1624821F86E0 for ; Wed, 5 Sep 2012 12:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZMPOo0z+TG8 for ; Wed, 5 Sep 2012 12:07:09 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id A157721F865B for ; Wed, 5 Sep 2012 12:07:09 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 138A386A3 for ; Wed, 5 Sep 2012 19:07:08 +0000 (UTC) Received: from G6W2545G.americas.hpqcorp.net (16.205.233.30) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 5 Sep 2012 18:59:51 +0000 Received: from G6W2500.americas.hpqcorp.net ([169.254.12.101]) by G6W2545G.americas.hpqcorp.net ([16.205.233.30]) with mapi id 14.02.0283.003; Wed, 5 Sep 2012 18:59:02 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: RADEXT @ IETF84: Meeting notes posted Thread-Index: AQHNi5iDDaFl09NQU060b0RUpdRo6A== Date: Wed, 5 Sep 2012 18:59:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [15.193.49.28] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] RADEXT @ IETF84: Meeting notes posted X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 05 Sep 2012 19:07:10 -0000 RADEXT community, Meeting notes have finally been posted for IETF 84. Thanks go out to Nancy= C. for great note taking. http://www.ietf.org/proceedings/84/minutes/minutes-84-radext Any corrections/modifications welcome. -MS From leaf.y.yeh@huawei.com Thu Sep 6 02:26:25 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE33721F8567 for ; Thu, 6 Sep 2012 02:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XHp9AIOLbaH for ; Thu, 6 Sep 2012 02:26:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6121F85AF for ; Thu, 6 Sep 2012 02:26:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKK23188; Thu, 06 Sep 2012 09:26:23 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Sep 2012 10:25:33 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Sep 2012 10:26:21 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 6 Sep 2012 17:25:47 +0800 From: Leaf yeh To: "Sanchez, Mauricio (HP Networking)" , "radext@ietf.org" Thread-Topic: [radext] RADEXT @ IETF84: Meeting notes posted Thread-Index: AQHNi5iDDaFl09NQU060b0RUpdRo6Jd89lGg Date: Thu, 6 Sep 2012 09:25:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: jouni korhonen Subject: Re: [radext] RADEXT @ IETF84: Meeting notes posted X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 09:26:25 -0000 Thanks for the posted Meeting notes. Though I am not there in the discussio= n session, I still can see your fair comments.=20 I am trying to catch the following technical points related to the topic of= 7. 7. RADIUS traffic accounting work, Stefan Winter - http://tools.ietf.org/id/draft-winter-radext-fancyaccounting=20 - http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics=20 -Status: 2 drafts to speak of the same thing: to extend existing accounting= drafts. -What to do with 2 drafts? WG needs to discuss if the accounting should be= extensible or focus on (hardcoding) IPv6 vs. IPv4? -Draft-winter-radext-fancyaccounting uses classes by string label which sho= uld be a URN pointing to the exact definition of what is being accounted fo= r.=20 -Draft-yeh-radext-ext-statistics only addresses IPv6 vs. IPv4; DSCP was add= ed does the accounting by enumerated integer labels. -Alan: believes they are both very similar, the winter draft is simpler and= more clear; has comments on how to clean up with filter rules. If there a= re complicated rules, then you may not want to send these in the packet; so= using the old style filter rule may not be good to use; identifiers are be= tter. But don't have strong intelligent suggestion to address URN. -Alan: clarifies that there's 2 things needed: to define the traffic class = (getting sent to the NAS as it may not be in RADIUS) and then providing the= traffic class information itself. -Marc B: draft-yeh seems to be fairly straight forward as it only focuses o= n the IPv6 traffic as it doesn't bring other stuff to the table. As a quic= k browse on the winter draft, while it=C2=B9s a nice architecture it may be= bringing a bigger picture to solve a little problem (e.g. IPv6) -Alan: Avi has done a lot of 3GPP and other similar work to what's been pro= posed in the winter draft; e.g. bringing flexibility and classifiers to acc= ounting. =20 -Jouni: mentions yes some work has been done in the diameter space. -Mauricio: we could take a narrower scope in the yeh draft, but Stefan rais= es good point that if new work comes then they'd have to define a new class= ifier so would be good to discuss that too. So may need a combination of b= oth drafts and encourages them to converge to a new draft. But question is = whether we take a tactical approach vs. flexible approach. I brought the specific requirement on reporting the traffic statistics in d= ual-stack scenario and some possible attribute designs for the RADIUS accou= nting extension to this WG from 2011, Mar., and believe some of design (suc= h as the traditional one in flat mode, not employed in the extended type sp= ace) or both of the above 2 approaches (in the extended type space) can sol= ved the existing problem. The main difference between the above 2 approache= s is that, one use the existing data type, enumerated integer, for the traf= fic type and solve the problem within the existing protocol framework; whil= e the other (draft-winter) proposed the new fashion data type of 'String in= URN format' for the traffic type. I prefer the idea to take a narrower scope in the draft, not too divergent = to solve the undefined problem, and combine the above 2 drafts for the same= design target discussed before. I am still & also not quite sure about the requirement to report the traffi= c statistics in other protocols, including IPFIX, Syslog and SNMP-MIB, for = some kind of accounting in AAA or BOSS systems. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Sanchez, Mauricio (HP Networking) Sent: Thursday, September 06, 2012 2:59 AM To: radext@ietf.org Subject: [radext] RADEXT @ IETF84: Meeting notes posted RADEXT community, Meeting notes have finally been posted for IETF 84. Thanks go out to Nancy= C. for great note taking. http://www.ietf.org/proceedings/84/minutes/minutes-84-radext Any corrections/modifications welcome. -MS _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bclaise@cisco.com Tue Sep 11 06:41:56 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C7D21F87E2 for ; Tue, 11 Sep 2012 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-2.313, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfggTuVzcZJc for ; Tue, 11 Sep 2012 06:41:56 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id C77CB21F87C8 for ; Tue, 11 Sep 2012 06:41:55 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8BDfj8I018975; Tue, 11 Sep 2012 15:41:45 +0200 (CEST) Received: from [10.60.67.93] (ams-bclaise-89112.cisco.com [10.60.67.93]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8BDfjOq008934; Tue, 11 Sep 2012 15:41:45 +0200 (CEST) Message-ID: <504F3F99.3030603@cisco.com> Date: Tue, 11 Sep 2012 15:41:45 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Leaf yeh References: <502522E8.1080700@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "draft-ietf-radext-ipv6-access@tools.ietf.org" Subject: Re: [radext] [MARKETING] Re: AD review: draft-ietf-radext-ipv6-access-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2012 13:41:57 -0000 Leah, Thanks for your answer. Regards, B. > Benoit - Recursive DNS Servers. Why recursive? > > We can also find option 23 named 'DNS Recursive Name Server Option' for DHCPv6 (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml ). I guess 'recursive' might be a native feature of DNS. > > > Benoit - where does the "framed" in the attribute naming convention come from? > > I guess the 1st 'framed' might appear in the attribute 6 named 'Service-Type' defined in RADIUS basic protocol, section 5.6 of RFC2865 (http://www.iana.org/assignments/radius-types/radius-types.xml ). > > Framed A Framed Protocol should be started for the User, such as PPP or SLIP. > > The word, 'framed' sounds a 'real convention' per the above statement, because we might use it not only for PPPoE, but also for IPoE in the broadband access. I guess it might mean 'nothing' in this case. > > > Best Regards, > Leaf > > > > ----------------------------------------------------------------------------------------------------------------- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Friday, August 10, 2012 11:04 PM > To: draft-ietf-radext-ipv6-access@tools.ietf.org > Cc: radext@ietf.org > Subject: [radext] AD review: draft-ietf-radext-ipv6-access-11 > > Dear authors, > > Here is my review. Mainly editorial > > - Radius -> RADIUS > > - In section 2.1 and section 2.5 > > OLD: > > DHCPv6 [RFC3315] provides a mechanism to assign one or more or non- > temporary IPv6 addresses to hosts. > > NEW > DHCPv6 [RFC3315] provides a mechanism to assign one or more non- > temporary IPv6 addresses to hosts. > > - Extend "IPv6CP" something meaningful: PPP's IP v6 Control protocol > > - Section 2.3 > OLD: > This document specifies the RADIUS attribute that allows the AAA > system to provision the announcement by the NAS of a specific Route > Information Option to an accessing host. > > NEW: > This document specifies the RADIUS attribute that allows the AAA > server to provision the announcement by the NAS of a specific Route > Information Option to an accessing host. > > - Section 2.4 > DHCPv6-PD expands to prefix delegation > - Section 2.2 > Recursive DNS Servers. Why recursive? > Same remark for the section 3.2: > The DNS-Server-IPv6-Address Attribute contains the IPv6 address of a > recursive DNS server. This attribute MAY be included multiple times > in Access-Accept packets, when the intention is for a NAS to announce > more than one recursive DNS address to an RG/host. > - Section 3.4 > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 delegated prefix for the user. If a NAS does > not support multiple prefix pools, the NAS MUST ignore this > Attribute. > > What is the user? It's confusing with the end user. > However, section 3.3 mentions: > This Attribute specifies a prefix (and corresponding route) for the > user on the NAS, ... > > So maybe the solution is: > OLD: > > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 delegated prefix for the user. > > NEW: > > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 delegated prefix for the user on the NAS. > > > Same remark for the section 3.5 > OLD: > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 address for the user. > NEW: > This Attribute contains the name of an assigned pool that SHOULD be > used to select an IPv6 address for the user on the NAS. > > - Section 3.4 > If a NAS does not support multiple prefix pools, the NAS MUST > ignore this Attribute. > > I'm confused by the "multiple" > > Please provide a revised ID, including the editorial improvements from Leaf Yeh on the mailing. > Note: Leaf's comments came after the WG LC, but could be made again in the IETF LC. So let's ease everybody's live, and let's include them directly. > > > And, finally, for my personal education, where does the "framed" in the attribute naming convention come from? > > Regards, Benoit (OPS AD) > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > From leaf.y.yeh@huawei.com Wed Sep 26 23:52:08 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20621F842E; Wed, 26 Sep 2012 23:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocrKK8mO7xju; Wed, 26 Sep 2012 23:52:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA58721F841C; Wed, 26 Sep 2012 23:52:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKB39783; Thu, 27 Sep 2012 06:52:05 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 07:51:20 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 07:52:02 +0100 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Thu, 27 Sep 2012 14:51:58 +0800 From: Leaf yeh To: Benoit Claise Thread-Topic: [AAA-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-09-27 IESG Teleconference Thread-Index: AQHNml618I7NHZ2c4E6Qw1lvMTKVcJedwm7w Date: Thu, 27 Sep 2012 06:51:56 +0000 Message-ID: References: <20120920221213.28653.10040.idtracker@ietfa.amsl.com> <50606A5C.4080901@cisco.com> In-Reply-To: <50606A5C.4080901@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "aaa-doctors@ietf.org" , "radext@ietf.org" Subject: Re: [radext] [AAA-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-09-27 IESG Teleconference X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2012 06:52:08 -0000 ------------------------- 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review ----------------------------------------------- Any clue about the progress (or review) of RADEXT WG Re-chartering? Best Regards, Leaf From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On= Behalf Of Benoit Claise Sent: Monday, September 24, 2012 10:13 PM To: aaa-doctors@ietf.org; MIB Doctors (E-mail); YANG Doctors; ops-dir@ietf.= org; IETF DNS Directorate Subject: [AAA-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 20= 12-09-27 IESG Teleconference Dear all,=20 Please find the agenda of the September 27th=A0 IESG telechat at https://da= tatracker.ietf.org/iesg/agenda/documents/ Note that this URL is more complete that the agenda below. Please send your questions, comments and concerns before Sept 26 COB.=20 Thanks and Regards, Benoit.=20 -------- Original Message --------=20 Subject:=20 [IESG-AGENDA-DIST] Summarized Agenda for the 2012-09-27 IESG Teleconference Date:=20 Thu, 20 Sep 2012 15:12:13 -0700 From:=20 IESG Secretary To:=20 iesg-agenda-dist@ietf.org INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2012-09-27 IESG Teleconference This agenda was generated at 2012-09-20 15:09:47 PDT Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ = =20 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-websec-strict-transport-sec-13 HTTP Strict Transport Security (HSTS) (Proposed Standard) Token: Barry Leiba o draft-ietf-ipfix-ie-doctors-05 Guidelines for Authors and Reviewers of IPFIX Information Elements (Best Current Practice) Note: Juergen Quittek (Quittek@neclab.eu) is the document shepherd. Token: Ronald Bonica o draft-ietf-isis-mi-07 IS-IS Multi-Instance (Proposed Standard) Note: Chris Hopps (chopps@rawdofmt.org) is the document shepherd. Token: Adrian Farrel 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items NONE 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Operations and Management Area Working Group (opsawg) 4.2.2 Proposed for Approval o Hypertext Transfer Protocol Bis (httpbis) From jouni.nospam@gmail.com Sat Sep 29 02:12:08 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B586421F8522 for ; Sat, 29 Sep 2012 02:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd6182jfo3bd for ; Sat, 29 Sep 2012 02:12:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1727321F8501 for ; Sat, 29 Sep 2012 02:10:58 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1680966wgb.13 for ; Sat, 29 Sep 2012 02:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=SFvWE6C6dZHQfsYQtGdL7PhdjzNDxHJsY5N15MU6qbU=; b=h4f5i13tmkwdLy2JgqiFzQpJMHyU9vRhW3lbM6MG4wlnakG5smmScNJWYatyZXMx0B Rx6rllaci54FOMLEdidcA7YlZGP+HN18VEzLw6bbNU17C1esMu2g7DWi/jNZUTBJw2rN oriIS83OCeyHOYB4C8Tbz9gA+4Y7mSbPJLuA6iTeK3tCL8sC39CQln9k4F32wC4cBkYt vBcytQN1JgHBUM0WEs/iVJDMfwV7/m7yaj2w8Gi/GG46eDNAcAsRY92zE8u+mBRRMNxx yIY0RaA9iUmNVs8DVMznCAqwzv6cUXB26AKsujo4BmDy87c4XiRqDYz3SaLTxKWY07Z7 Fitg== Received: by 10.180.104.5 with SMTP id ga5mr2846142wib.10.1348909858180; Sat, 29 Sep 2012 02:10:58 -0700 (PDT) Received: from [10.116.1.210] (62-50-227-135.client.stsn.net. [62.50.227.135]) by mx.google.com with ESMTPS id cl8sm3883888wib.10.2012.09.29.02.10.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Sep 2012 02:10:57 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Sep 2012 12:10:52 +0300 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: radext-chairs@tools.ietf.org, Alan DeKok Subject: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 09:12:08 -0000 Folks, This email starts a two week WGLC (the third in row) for "Remote = Authentication Dial In User Service (RADIUS) Protocol Extensions" I-D = (draft-ietf-radext-radius-extensions-06). The WGLC ends 13-Oct-2012. Send your comments to the mailer and please = also use the Issue Tracker. No comments would this time also imply that everybody agrees = with the content. - Jouni & Mauricio= From leaf.y.yeh@huawei.com Sat Sep 29 02:44:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7254721F8594 for ; Sat, 29 Sep 2012 02:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kry9Rcf2OX4G for ; Sat, 29 Sep 2012 02:44:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22E1E21F8504 for ; Sat, 29 Sep 2012 02:44:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALD83965; Sat, 29 Sep 2012 09:44:17 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 10:42:25 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 17:43:13 +0800 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 17:40:50 +0800 From: Leaf yeh To: jouni korhonen , "radext@ietf.org" Thread-Topic: [radext] WGLC for draft-ietf-radext-radius-extensions-06 Thread-Index: AQHNniKIX6EKyrH6o0WEskBYux+PLJehDyCw Date: Sat, 29 Sep 2012 09:40:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "radext-chairs@tools.ietf.org" , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 09:44:19 -0000 Just for a check, would this WG draft like to add a section for the new dat= a type, Sting in URN format, proposed in draft-winter-radext-fancyaccountin= g-02? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= jouni korhonen Sent: Saturday, September 29, 2012 5:11 PM To: radext@ietf.org Cc: radext-chairs@tools.ietf.org; Alan DeKok Subject: [radext] WGLC for draft-ietf-radext-radius-extensions-06 Folks, This email starts a two week WGLC (the third in row) for "Remote Authentica= tion Dial In User Service (RADIUS) Protocol Extensions" I-D (draft-ietf-radext-radius-ex= tensions-06). The WGLC ends 13-Oct-2012. Send your comments to the mailer and please also= use the Issue Tracker. No comments would this time also imply that everybody agrees with = the content. - Jouni & Mauricio _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Sat Sep 29 05:15:07 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E07121F84D4 for ; Sat, 29 Sep 2012 05:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.403 X-Spam-Level: **** X-Spam-Status: No, score=4.403 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcL3JnZzeHmB for ; Sat, 29 Sep 2012 05:15:06 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5EE21F84BF for ; Sat, 29 Sep 2012 05:15:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 820AC20118; Sat, 29 Sep 2012 08:14:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B0070414A; Sat, 29 Sep 2012 08:14:16 -0400 (EDT) From: Sam Hartman To: Leaf yeh References: Date: Sat, 29 Sep 2012 08:14:16 -0400 In-Reply-To: (Leaf yeh's message of "Sat, 29 Sep 2012 09:40:49 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , jouni korhonen , "radext-chairs@tools.ietf.org" , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 12:15:07 -0000 >>>>> "Leaf" == Leaf yeh writes: Leaf> Just for a check, would this WG draft like to add a section Leaf> for the new data type, Sting in URN format, proposed in Leaf> draft-winter-radext-fancyaccounting-02? Best Regards, Leaf I'd prefer to get this draft approved sooner rather than later and believe now is not the time for adding things to it that can be handled in other drafts. --Sam From bclaise@cisco.com Sat Sep 29 06:58:49 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096A221F84D9 for ; Sat, 29 Sep 2012 06:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.612 X-Spam-Level: X-Spam-Status: No, score=-8.612 tagged_above=-999 required=5 tests=[AWL=1.986, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JzZEUSs-UTF for ; Sat, 29 Sep 2012 06:58:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4837B21F84B9 for ; Sat, 29 Sep 2012 06:58:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8TDwYHm021481; Sat, 29 Sep 2012 15:58:35 +0200 (CEST) Received: from [10.61.89.4] (ams3-vpn-dhcp6405.cisco.com [10.61.89.4]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8TDwV5S028765; Sat, 29 Sep 2012 15:58:32 +0200 (CEST) Message-ID: <5066FE87.6040309@cisco.com> Date: Sat, 29 Sep 2012 15:58:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030109090600080900080509" Cc: "radext@ietf.org" Subject: Re: [radext] new charter proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 13:58:49 -0000 This is a multi-part message in MIME format. --------------030109090600080900080509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Since we also discussed this new charter during the IETF meeting, I'll take the lack of replies as agreement. However, I have a concern regarding the RADIUS Accounting Extensions for Traffic Statistics, for two reasons: 1. there are two competing proposals, tactical approach vs. flexible approach, as mentioned in the meeting minutes. And there is ongoing discussion on the mailing regarding the direction to take. 2. If we go for the flexible approach, where do we stop in terms of flexibility? Should the URN in WInter's draft contain: then ipv4 versus ipv6, then all the DSCP values, then the next hop, then AS-path ... All of which To finally end up with the IPFIX flexibility, i.e. a template based mechanism, based on any selection of all IPFIX IANA IEs So I would like the WG to agree on the problem statement first. Since both the NAI and the fragmentation work is agreed upon, we could proceed with the new charter, modulo the "RADIUS Accounting Extensions for Traffic Statistics" Regards, Benoit. > Description of Working Group > > The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. > > In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. > > Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: > > - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. > > Work Items > The immediate goals of the RADEXT working group are to address the following issues: > > - RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. > > - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > > - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. > > - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. > > - RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording. > > - Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865. > > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication > Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current Practice RFC > Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an Informational RFC > Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC > Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC > Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC > Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC > Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC > Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC > Apr 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > --------------030109090600080900080509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Since we also discussed this new charter during the IETF meeting, I'll take the lack of replies as agreement.

However, I have a concern regarding the RADIUS Accounting Extensions for Traffic Statistics, for two reasons:
1. there are two competing proposals, tactical approach vs. flexible approach, as mentioned in the meeting minutes. And there is ongoing discussion on the mailing regarding the direction to take.
2. If we go for the flexible approach, where do we stop in terms of flexibility?
Should the URN in WInter's draft contain: then ipv4 versus ipv6, then all the DSCP values, then the next hop, then AS-path ... All of which
To finally end up with the IPFIX flexibility, i.e. a template based mechanism, based on any selection of all IPFIX IANA IEs

So I would like the WG to agree on the problem statement first.

Since both the NAI and the fragmentation work is agreed upon, we could proceed with the new charter, modulo the "RADIUS Accounting Extensions for Traffic Statistics"

Regards, Benoit.

Description of Working Group

The RADIUS Extensions Working Group will focus on extensions to the RADIUS  protocol required to expand and enrich the standard attribute space, address  cryptographic algorithm agility, use of new secure transports and clarify its usage and definition.

In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS  implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG:

- All documents produced MUST specify means of interoperation with legacy RADIUS  and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539.

Work Items
The immediate goals of the RADEXT working group are to address the following issues:

- RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes.

- IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

- Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases.  In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies.  In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS.

- RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording.

- Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865.

Goals and Milestones
Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Done RFC 2486bis submitted as a Proposed Standard RFC
Done RFC 3576 MIBs submitted as an Informational RFC
Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope)
Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC
Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft)
Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RADIUS Design Guidelines submitted as a Best Current Practice RFC
Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC
Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC
Done Status-Server I-D submitted as a Proposed Standard RFC
Done RADIUS Crypto-agility Requirements submitted as an Informational RFC
Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC
Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC
Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC
Apr 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------030109090600080900080509-- From bclaise@cisco.com Sat Sep 29 06:59:49 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7761A21F855A for ; Sat, 29 Sep 2012 06:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.632 X-Spam-Level: X-Spam-Status: No, score=-8.632 tagged_above=-999 required=5 tests=[AWL=1.966, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfSjqhvggo8k for ; Sat, 29 Sep 2012 06:59:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB2921F84D9 for ; Sat, 29 Sep 2012 06:59:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8TDxie0021540; Sat, 29 Sep 2012 15:59:44 +0200 (CEST) Received: from [10.61.89.4] (ams3-vpn-dhcp6405.cisco.com [10.61.89.4]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8TDxg5q029157; Sat, 29 Sep 2012 15:59:43 +0200 (CEST) Message-ID: <5066FECE.80008@cisco.com> Date: Sat, 29 Sep 2012 15:59:42 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: <5066FE87.6040309@cisco.com> In-Reply-To: <5066FE87.6040309@cisco.com> Content-Type: multipart/alternative; boundary="------------050207010209040100000107" Cc: "radext@ietf.org" Subject: Re: [radext] new charter proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 13:59:49 -0000 This is a multi-part message in MIME format. --------------050207010209040100000107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sent to fast. See in line. > Dear all, > > Since we also discussed this new charter during the IETF meeting, I'll > take the lack of replies as agreement. > > However, I have a concern regarding the RADIUS Accounting Extensions > for Traffic Statistics, for two reasons: > 1. there are two competing proposals, tactical approach vs. flexible > approach, as mentioned in the meeting minutes. And there is ongoing > discussion on the mailing regarding the direction to take. > 2. If we go for the flexible approach, where do we stop in terms of > flexibility? > Should the URN in WInter's draft contain: then ipv4 versus ipv6, then > all the DSCP values, then the next hop, then AS-path ... All of which ... could be used for differentiated charging. Regards, Benoit. > To finally end up with the IPFIX flexibility, i.e. a template based > mechanism, based on any selection of all IPFIX IANA IEs > > So I would like the WG to agree on the problem statement first. > > Since both the NAI and the fragmentation work is agreed upon, we could > proceed with the new charter, modulo the "RADIUS Accounting Extensions > for Traffic Statistics" > > Regards, Benoit. > >> Description of Working Group >> >> The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. >> >> In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. >> >> Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: >> >> - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. >> >> Work Items >> The immediate goals of the RADEXT working group are to address the following issues: >> >> - RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. >> >> - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. >> >> - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. >> >> - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. >> >> - RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording. >> >> - Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865. >> >> Goals and Milestones >> Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication >> Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC >> Done RFC 2486bis submitted as a Proposed Standard RFC >> Done RFC 3576 MIBs submitted as an Informational RFC >> Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) >> Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC >> Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) >> Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) >> Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) >> Done RADIUS Design Guidelines submitted as a Best Current Practice RFC >> Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC >> Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC >> Done Status-Server I-D submitted as a Proposed Standard RFC >> Done RADIUS Crypto-agility Requirements submitted as an Informational RFC >> Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC >> Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC >> Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC >> Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC >> Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC >> Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC >> Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC >> Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC >> Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC >> Apr 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> >> > --------------050207010209040100000107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Sent to fast.
See in line.
Dear all,

Since we also discussed this new charter during the IETF meeting, I'll take the lack of replies as agreement.

However, I have a concern regarding the RADIUS Accounting Extensions for Traffic Statistics, for two reasons:
1. there are two competing proposals, tactical approach vs. flexible approach, as mentioned in the meeting minutes. And there is ongoing discussion on the mailing regarding the direction to take.
2. If we go for the flexible approach, where do we stop in terms of flexibility?
Should the URN in WInter's draft contain: then ipv4 versus ipv6, then all the DSCP values, then the next hop, then AS-path ... All of which
... could be used for differentiated charging.

Regards, Benoit.
To finally end up with the IPFIX flexibility, i.e. a template based mechanism, based on any selection of all IPFIX IANA IEs

So I would like the WG to agree on the problem statement first.

Since both the NAI and the fragmentation work is agreed upon, we could proceed with the new charter, modulo the "RADIUS Accounting Extensions for Traffic Statistics"

Regards, Benoit.

Description of Working Group

The RADIUS Extensions Working Group will focus on extensions to the RADIUS  protocol required to expand and enrich the standard attribute space, address  cryptographic algorithm agility, use of new secure transports and clarify its usage and definition.

In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS  implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG:

- All documents produced MUST specify means of interoperation with legacy RADIUS  and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539.

Work Items
The immediate goals of the RADEXT working group are to address the following issues:

- RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes.

- IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

- Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases.  In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies.  In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS.

- RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording.

- Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865.

Goals and Milestones
Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Done RFC 2486bis submitted as a Proposed Standard RFC
Done RFC 3576 MIBs submitted as an Informational RFC
Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope)
Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC
Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft)
Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RADIUS Design Guidelines submitted as a Best Current Practice RFC
Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC
Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC
Done Status-Server I-D submitted as a Proposed Standard RFC
Done RADIUS Crypto-agility Requirements submitted as an Informational RFC
Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC
Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC
Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC
Apr 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext


--------------050207010209040100000107-- From peterd@iea-software.com Sat Sep 29 10:47:09 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C031221F85B4 for ; Sat, 29 Sep 2012 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebcfgmbigger for ; Sat, 29 Sep 2012 10:47:09 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 37C9321F85AC for ; Sat, 29 Sep 2012 10:47:09 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sat, 29 Sep 2012 10:45:50 -0700 Date: Sat, 29 Sep 2012 10:47:06 -0700 (Pacific Daylight Time) From: Peter Deacon To: jouni korhonen In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org, radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 17:47:09 -0000 On Sat, 29 Sep 2012, jouni korhonen wrote: > This email starts a two week WGLC (the third in row) for "Remote Authentication Dial In > User Service (RADIUS) Protocol Extensions" I-D (draft-ietf-radext-radius-extensions-06). > The WGLC ends 13-Oct-2012. Send your comments to the mailer and please also use the Issue > Tracker. No comments would this time also imply that everybody agrees with the content. As mentioned on list in detail earlier I am still concerned with mechanism for fragmentation of long attributes (3.5,3.6) especially when combined with VSAs (4.5,4.6) The risk of (silent) data corruption due to handling order of attributes in a way permitted by existing RFCs seems to be higher than necessary. Have previously offered what I believe to be simple ideas to mitigate: Prevent extensions compliant systems from interacting with RADIUS RFC compliant intermediaries not supporting extensions. Fragment VSAs at the VSA Value field to prevent any opportunity for another attributes Value field to select Vendor and Vendor Type. Use reserved field as sequence number to better detect missing or out of order attributes. Checking and setting could be made optional such that systems finding it too difficult to increment a counter need not be adversely effected. regards, Peter From aland@deployingradius.com Sat Sep 29 23:58:30 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DFE21F8466 for ; Sat, 29 Sep 2012 23:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZGZ9Nezv8i2 for ; Sat, 29 Sep 2012 23:58:30 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D016721F845F for ; Sat, 29 Sep 2012 23:58:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8CDCD2240EE9; Sun, 30 Sep 2012 08:58:27 +0200 (CEST) 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 d80jrO6IBduO; Sun, 30 Sep 2012 08:58:25 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id C161F2240223; Sun, 30 Sep 2012 08:58:24 +0200 (CEST) Message-ID: <5067ED96.9000301@deployingradius.com> Date: Sun, 30 Sep 2012 08:58:30 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise , "radext@ietf.org" References: <5066FE87.6040309@cisco.com> In-Reply-To: <5066FE87.6040309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] new charter proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 06:58:30 -0000 Benoit Claise wrote: > Should the URN in WInter's draft contain: then ipv4 versus ipv6, then > all the DSCP values, then the next hop, then AS-path ... All of which > To finally end up with the IPFIX flexibility, i.e. a template based > mechanism, based on any selection of all IPFIX IANA IEs > That is definitely relevant. If I may speak for the RADIUS side, I think that the current goal is a *slightly* more capable accounting than what we're doing now. However... there's a balance between doing "just a little more" and re-inventing something, versus just doing it right the first time. And there's always the tendency to re-use your own expertise, rather than using external expertise. My $0.02 is that IPFIX is very opaque. I've spent some time reading the RFCs, and all I know now is that there are sets, templates, layers, and more layers. It's not clear what's going on. For example, the link you posted above defines "flowStartSeconds". Which is in a unit called "dateTimeSeconds". It's defined in RFC 5102. Section 3.1.15 (http://tools.ietf.org/html/rfc5102#section-3.1.15) defines it. But... it doesn't say how *big* it is. I still have no idea how many bytes to put into a packet. This makes re-using IPFIX problematic. We would have to re-define some of the terms used in IPFIX. My take-away is that re-using IPFIX could be very helpful. The main benefit is that we would not need to re-define *what* piece of information we're tracking. We could just reference the IPFIX definitions. We would still be left with the problem of how to *represent* that information in RADIUS. That requires some work. Alan DeKok. From aland@deployingradius.com Sun Sep 30 00:03:06 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB62A21F852A for ; Sun, 30 Sep 2012 00:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0s8Xx1-0LEG for ; Sun, 30 Sep 2012 00:03:06 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E99A21F84CF for ; Sun, 30 Sep 2012 00:03:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 81B3C2240EE9; Sun, 30 Sep 2012 09:02:13 +0200 (CEST) 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 iST4eLgu5YxN; Sun, 30 Sep 2012 09:02:13 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id 10524224070E; Sun, 30 Sep 2012 09:02:13 +0200 (CEST) Message-ID: <5067EE7A.2090201@deployingradius.com> Date: Sun, 30 Sep 2012 09:02:18 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, jouni korhonen Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 07:03:07 -0000 Peter Deacon wrote: > As mentioned on list in detail earlier I am still concerned with > mechanism for fragmentation of long attributes (3.5,3.6) especially when > combined with VSAs (4.5,4.6) > > The risk of (silent) data corruption due to handling order of attributes > in a way permitted by existing RFCs seems to be higher than necessary. I'm not sure I agree. > Have previously offered what I believe to be simple ideas to mitigate: > > Prevent extensions compliant systems from interacting with RADIUS RFC > compliant intermediaries not supporting extensions. I don't understand that. Existing systems which are RFC compliant and *not* supporting extensions won't be affected by them. The extensions attributes use previously undefined numbers. RFC compliant systems don't touch unassigned attributes. > Fragment VSAs at the VSA Value field to prevent any opportunity for > another attributes Value field to select Vendor and Vendor Type. That is a problem if, and only if, non-RFC compliant systems re-use unassigned values AND mangle them. While that can happen, I think it can be detectable in practice. > Use reserved field as sequence number to better detect missing or out of > order attributes. Checking and setting could be made optional such that > systems finding it too difficult to increment a counter need not be > adversely effected. Sequence numbers are possible. I think the previous consensus was that they didn't make much difference. Alan DeKok. From avi.ietf@lior.org Sun Sep 30 11:23:07 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9216F21F867B for ; Sun, 30 Sep 2012 11:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnKP1GmUiqi9 for ; Sun, 30 Sep 2012 11:23:07 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7121F8679 for ; Sun, 30 Sep 2012 11:23:06 -0700 (PDT) Received: by iec9 with SMTP id 9so12300849iec.31 for ; Sun, 30 Sep 2012 11:23:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=W1SwMwRqSlV15mh0UGJOwhkQ1aylSfGtql6eEC1dswQ=; b=AWZPwkU4YH4QQhMrmTCXsKD6+nsQG6QGwRu2KIiSz+Mf4T+bsOF5lNG5ZRB/bOarge UPNB2t53RluDOLCHTJV4naLyiC7KNidDSpkxIkMQlbKMtrox8+/R/5mO3qYtKweKvAFV Sc0V+29DboqCLhAr/a86iGjUYwVBpu5vSq4N9YSdtzaWbgtLcR5zHJ/dK/+vvzPUF1MX Le8LmfQToMPpVTxBzNt692erSnSUGMtsLJxURBQlS+zt+89H2vzQtaxCZpTgOzEVqlNd qQ3HQD7FXceiWOfCAnsZHvOghDGkFnoWbMrTNBY+fAj8UuCJ1E+G4/c4yujndn+4R/Uw zJXQ== Received: by 10.50.42.197 with SMTP id q5mr3755338igl.21.1349029386339; Sun, 30 Sep 2012 11:23:06 -0700 (PDT) Received: from [172.17.17.120] (CPE10bf48d33c88-CM602ad089cf9c.cpe.net.cable.rogers.com. [99.224.172.207]) by mx.google.com with ESMTPS id ma9sm4771357igc.17.2012.09.30.11.23.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 11:23:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Avi Lior In-Reply-To: <5067EE7A.2090201@deployingradius.com> Date: Sun, 30 Sep 2012 14:23:03 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5067EE7A.2090201@deployingradius.com> To: "radext@ietf.org" , Peter Deacon X-Mailer: Apple Mail (2.1498) X-Gm-Message-State: ALoCoQm9uCJVtVLZ38o6+0xsJle9zrLRGtIZgGjd7SSADw+1T0o8vJgc/1MB6f98JrZWRY8KgURx Cc: jouni korhonen , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 18:23:07 -0000 I agree with Alan. As well, to sequence numbers, I don't see any need for them. On 2012-09-30, at 3:02 , Alan DeKok wrote: > Peter Deacon wrote: >> As mentioned on list in detail earlier I am still concerned with >> mechanism for fragmentation of long attributes (3.5,3.6) especially when >> combined with VSAs (4.5,4.6) >> >> The risk of (silent) data corruption due to handling order of attributes >> in a way permitted by existing RFCs seems to be higher than necessary. > > I'm not sure I agree. > >> Have previously offered what I believe to be simple ideas to mitigate: >> >> Prevent extensions compliant systems from interacting with RADIUS RFC >> compliant intermediaries not supporting extensions. > > I don't understand that. Existing systems which are RFC compliant and > *not* supporting extensions won't be affected by them. The extensions > attributes use previously undefined numbers. RFC compliant systems > don't touch unassigned attributes. > >> Fragment VSAs at the VSA Value field to prevent any opportunity for >> another attributes Value field to select Vendor and Vendor Type. > > That is a problem if, and only if, non-RFC compliant systems re-use > unassigned values AND mangle them. While that can happen, I think it > can be detectable in practice. > >> Use reserved field as sequence number to better detect missing or out of >> order attributes. Checking and setting could be made optional such that >> systems finding it too difficult to increment a counter need not be >> adversely effected. > > Sequence numbers are possible. I think the previous consensus was > that they didn't make much difference. > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From ghalwasi@cisco.com Sun Sep 30 18:43:45 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3F821F84F3 for ; Sun, 30 Sep 2012 18:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.319 X-Spam-Level: X-Spam-Status: No, score=-10.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5i8sYU40MMTV for ; Sun, 30 Sep 2012 18:43:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3654021F844C for ; Sun, 30 Sep 2012 18:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=906; q=dns/txt; s=iport; t=1349055824; x=1350265424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r256UUfiOI+hLHZVUxrO7+YDX2QWaQSVaHplfgLnhCo=; b=Ze+ihIhGOHm2ZL/uF3tyXHJK+6EOv5/lDPKv6DAlcbRsBHRLwmIoCTyY ACk7bXywScy5/pP/BTmA+CNK5PB0KelbLBlz5JC20YGqw2KzSbHVgDA+x ZOOwJAYa4vBi9SjucRMSYt2oEkWzOPK2MWiixLjD1mOCxcAZ29rBgalHH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FABv0aFCtJV2c/2dsb2JhbABFhUS4dIEIgiABAQEEAQEBDwEnNAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgah2MLmhefDgSLH4VrYAOkK4FpgmeBYzQ X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="126925265" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 01 Oct 2012 01:43:43 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q911hhUW010140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Oct 2012 01:43:43 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.235]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Sun, 30 Sep 2012 20:43:43 -0500 From: "Gaurav Halwasia (ghalwasi)" To: jouni korhonen , "radext@ietf.org" Thread-Topic: [radext] WGLC for draft-ietf-radext-radius-extensions-06 Thread-Index: AQHNniKEP7YlXpELDkW6ZXmuGJlcqpejr9gA Date: Mon, 1 Oct 2012 01:43:42 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BD39FA7@xmb-aln-x06.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.79.208] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19222.004 x-tm-as-result: No--30.880800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext-chairs@tools.ietf.org" , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 01:43:45 -0000 I am in favor of advancing with this document. Thanks, Gaurav -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= jouni korhonen Sent: Saturday, September 29, 2012 2:41 PM To: radext@ietf.org Cc: radext-chairs@tools.ietf.org; Alan DeKok Subject: [radext] WGLC for draft-ietf-radext-radius-extensions-06 Folks, This email starts a two week WGLC (the third in row) for "Remote Authentica= tion Dial In User Service (RADIUS) Protocol Extensions" I-D (draft-ietf-rad= ext-radius-extensions-06). The WGLC ends 13-Oct-2012. Send your comments to the mailer and please also= use the Issue Tracker. No comments would this time also imply that everybo= dy agrees with the content. - Jouni & Mauricio _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.yeh.sdo@gmail.com Sun Sep 30 21:14:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27AF21F8532 for ; Sun, 30 Sep 2012 21:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=1.849, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkf+6n5ya90i for ; Sun, 30 Sep 2012 21:14:18 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 124E221F8526 for ; Sun, 30 Sep 2012 21:14:18 -0700 (PDT) Received: by padfb11 with SMTP id fb11so3902802pad.31 for ; Sun, 30 Sep 2012 21:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=qYPVp5cMjzropMIprok3m6UYx2liI64FIz+ndy6cWn4=; b=FgV2F6gngbEAVm6umzfp6gTzdGPrP9IzUUmBu9FiopmeC3tibc4RLhS+Y2cSg1htUY rm/EO4bMVatoJKqNesTiJUdkiQ1j6SLDJLtd5TqjEHwthOTMdzXHTQL9Vnkcmq6ScygQ +PPAuk1a40TkzOG7EjdkarE4+O1NxPlFBkmDnJHmXlPKE5c2AWtiOZ1+7eVN1kP9fQ4S cwFV9ZucSDHjt7nTJzwgvTaMPSbrkJ1lApyBIynFLLAPb4mHqD9T6I1VehVWQnpyU/cf 7hwUBDclXG5jYqUrfS3gK+ONSdgGmINUVdJ4+gryRk84eaSKDXTTAXrWQgFlhw6Xm+XL UmwA== Received: by 10.68.195.195 with SMTP id ig3mr38576098pbc.108.1349064857680; Sun, 30 Sep 2012 21:14:17 -0700 (PDT) Received: from lst9242355d22a ([218.18.218.70]) by mx.google.com with ESMTPS id o1sm9703890pax.21.2012.09.30.21.14.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 21:14:16 -0700 (PDT) From: "Leaf Yeh" To: "'Benoit Claise'" , "'Sanchez, Mauricio \(HP Networking\)'" References: <5066FE87.6040309@cisco.com> <5066FECE.80008@cisco.com> In-Reply-To: <5066FECE.80008@cisco.com> Date: Mon, 1 Oct 2012 12:14:08 +0800 Message-ID: <50691898.2150420a.26ae.417e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2eSrLpCeNvjq07Qk6zCokFpBS9EQABVR5g Content-Language: zh-cn Cc: radext@ietf.org Subject: Re: [radext] new charter proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 04:14:19 -0000 Dear Benoit, Benoit - If we go for the flexible approach, where do we stop in terms of flexibility? Draft-yeh-radext-ext-traffic-statistics suggests we could get the 1st stop at stack-type (ipv4-only, ipv6-only & dual-stack) and DSCP-type (optional). Within this solution, Stack-type can directly meet the explicit requirement defined in section 9.4 of BBF TR-187. Even if we intend to report traffic of each subscriber in DSCP-types, that always means triple (or more) statistic resources for each subscriber are required on the NAS, right? Benoit - Should the URN in WInter's draft contain: then ipv4 versus ipv6, then all the DSCP values, then the next hop, then AS-path ... All of which ... could be used for differentiated charging. a. I haven't see the requirement, application scenario or business model from the industry related to the differentiated accounting with 'next hop', 'AS-path' & etc. [BBF TR-187] [draft-hu-v6ops-radius-issues-ipv6-00] from China Telecom [draft-maglione-radext-ipv6-acct-extensions-01] from Telecom Italia. mentioned in draft-yeh-radext-ext-traffic-statistics-03 may show some of the interests from the industry for your reference. b. I doubt 'next hop' or 'AS-path' are subscrber-specified (or based) feature, which sounds not associated with the accounting for the different subscribers. c. In the RADIUS accounting protocol defined in RFC2866, we only have 2 messages. Accounting-Request is for reporting, and Accounting-Response is for acknowledgement. To my understanding, RADIUS can only report service duration (per the attribute of Acct-Session-Time) or traffic volume (per the attribute of Acct-Input/Output-Octet/Packet) now, it seems we have still have no means (or attributes) defined for the Access-Accept to support the on-demand accounting information reporting. If the assumption sounds IPFIX informational model (which I am not familiar with yet) can provide more information related with the traffic aspects than here for each subscriber, we still need figure out which of those information is what the subscriber accounting need, and find a way for the on-demand reporting, right? d. As a date type, the newly proposed 'String in URN format' sounds an alternative option of the traditional existing date type of 'Enumerated Integer' for the same enumeration question of the traffic type in this case. I meant the data type of 'Enumerated Integer' is the convention for enumeration in RADIUS (almost in every RADIUS RFC) before, it can just solve the problem in this case, but it is called 'tactical approach' here now. Best Regards, Leaf From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Saturday, September 29, 2012 10:00 PM To: Sanchez, Mauricio (HP Networking) Cc: radext@ietf.org Subject: Re: [radext] new charter proposal Sent to fast. See in line. Dear all, Since we also discussed this new charter during the IETF meeting, I'll take the lack of replies as agreement. However, I have a concern regarding the RADIUS Accounting Extensions for Traffic Statistics, for two reasons: 1. there are two competing proposals, tactical approach vs. flexible approach, as mentioned in the meeting minutes. And there is ongoing discussion on the mailing regarding the direction to take. 2. If we go for the flexible approach, where do we stop in terms of flexibility? Should the URN in WInter's draft contain: then ipv4 versus ipv6, then all the DSCP values, then the next hop, then AS-path ... All of which ... could be used for differentiated charging. Regards, Benoit. To finally end up with the IPFIX flexibility, i.e. a template based mechanism, based on any selection of all IPFIX IANA IEs So I would like the WG to agree on the problem statement first. Since both the NAI and the fragmentation work is agreed upon, we could proceed with the new charter, modulo the "RADIUS Accounting Extensions for Traffic Statistics" Regards, Benoit. Description of Working Group The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. - RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording. - Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865. Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC Apr 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Sun Sep 30 21:21:26 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D0B21F848F for ; Sun, 30 Sep 2012 21:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQWAscHH52kY for ; Sun, 30 Sep 2012 21:21:26 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id EC41121F8484 for ; Sun, 30 Sep 2012 21:21:25 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 30 Sep 2012 21:20:26 -0700 Date: Sun, 30 Sep 2012 21:21:24 -0700 (Pacific Daylight Time) From: Peter Deacon To: Avi Lior In-Reply-To: Message-ID: References: <5067EE7A.2090201@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" , jouni korhonen , Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 04:21:26 -0000 On Sun, 30 Sep 2012, Avi Lior wrote: > I agree with Alan. > As well, to sequence numbers, I don't see any need for them. Attribute ordering in RFC compliant systems not supporting extensions is only a recommendation. The possible consequences of assuming order can be severe (silent corruption and control over vendor id, vendor type and vendor value fields) I don't think it is prudent to ignore this when a complete solution for RADIUS packets containing single long attributes and less than complete when more than one long attribute are present is trivial. regards, Peter From aland@deployingradius.com Sun Sep 30 23:34:00 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595BA21F84F5 for ; Sun, 30 Sep 2012 23:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-5+lBI7Qj2W for ; Sun, 30 Sep 2012 23:33:59 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 122C821F8505 for ; Sun, 30 Sep 2012 23:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 978592240D01; Mon, 1 Oct 2012 08:33:09 +0200 (CEST) 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 NNBwhA+NRBbL; Mon, 1 Oct 2012 08:33:07 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id F39D12240797; Mon, 1 Oct 2012 08:33:06 +0200 (CEST) Message-ID: <5069392B.4080606@deployingradius.com> Date: Mon, 01 Oct 2012 08:33:15 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5067EE7A.2090201@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , jouni korhonen , Avi Lior Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 06:34:00 -0000 Peter Deacon wrote: > Attribute ordering in RFC compliant systems not supporting extensions is > only a recommendation. And implemented by all RADIUS servers I'm aware of. > The possible consequences of assuming order can be severe (silent > corruption and control over vendor id, vendor type and vendor value fields) > > I don't think it is prudent to ignore this when a complete solution for > RADIUS packets containing single long attributes and less than complete > when more than one long attribute are present is trivial. Sequence numbers aren't trivial. My $0.02 is that a simpler solution would be to use one "reserved" bit as a "start" flag. The first fragment has "start" set. All others don't. If you see a first fragment *without* the "start" bit set, you know someone screwed up, and you ignore all subsequent fragments of the same type. You might even want to toss the packet entirely as non-compliant. That soles the problem with minimal changes to the draft. My guess is that it could be added in only a few sentences. Alan DeKok.