Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 31 Oct 2006 12:16:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: RFC 3588 "aaas" Scheme: Feedback Needed! Date: Tue, 31 Oct 2006 14:15:28 +0200 Message-ID: Thread-Topic: RFC 3588 "aaas" Scheme: Feedback Needed! Thread-Index: Acb8zVRqXFbplntCRmi5KbrO3BeS0wAF6InA From: To: Hi all, Hannes has asked some implementors about aaas scheme. Does anyone else have any info on implementations of this feature? John >I would like to solicit some feedback regarding the usage of=20 >AAAS as defined in Section 4.3. of http://www.ietf.org/rfc/rfc3588.txt: > >" > "aaas://" FQDN [ port ] [ transport ] [ protocol ] " > >Questions: > >a) Who has implemented the "aaas" scheme? >b) Who is using the "aaas" scheme? > >Ciao >Hannes > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 30 Oct 2006 21:23:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: IETF67 RADEXT Agenda Take Two Date: Mon, 30 Oct 2006 16:22:26 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4955@MABOSEVS2.ets.enterasys.com> Thread-Topic: IETF67 RADEXT Agenda Take Two Thread-Index: Acb8aX9tpKLI9tKZQ6Cqx56rBboHhQ== From: "Nelson, David" To: Agenda for the RADEXT WG Meeting at IETF 67 Tuesday, November 7, 2006, Morning Session I 0900-1130 Room Name: Harbor Island I WGs meeting at the same time: widex, 16ng, trill, avt, dkim, ippm, rserpool =20 A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes) B. Agenda Bashing C. Milestone Status Review (5 minutes) C.1 Discussion of RADEXT Crypto-Agility work item descriptive text. (10 minutes) D. Document Status D.1 Documents with errata D.1.1 RFC 4590 has an error in the IANA assignment for a RADIUS Attribute Type ID. Discuss whether this can be handled by an RFC Editor Errata note, or whether it requires an RFC4590bis ID to correct the error. http://www.ietf.org/rfc/rfc4590.txt. (TBD, 5 minutes) =20 D.2 Documents in IESG review D.2.1 draft-ietf-radext-delegated-prefix-05.txt. (TBD, 5 minutes) D.3 Documents in Pre-WG review D.3.1 NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt=20 D.3.2 NAS-Traffic-Rule Attributes (Mauricio Sanchez, 15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-01.tx t=20 D.3.3 Extended RADIUS Attributes (TBD, 15 minutes) http://www.ietf.org/draft-lior-radius-attribute-type-extension-01.txt General Discussion of Extended Attributes, using this draft as a straw-man proposal. (WG at large, 30 minutes) D.3.4 Issues & Fixes (Alan DeKok, 10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-03.txt D.3.5 Additional IEEE802 Values for the NAS-Port-Type Attribute (Yan Renxiang, 5 minutes) http://www.ietf.org/internet-drafts/draft-yan-radext-port-type-01.txt D.4 Documents requiring cross-WG review D.4.1 RADIUS Mobile IPv6 Support (TBD, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-01.txt E. Next Steps E.1 Is it sufficient for the RADIUS Prepaid Attributes work to be published as an Informational RFC, using Vendor Specific Attributes? (10 minutes) E.2 The RADIUS WLAN Attributes work is waiting on a finalization of requirements form IEEE 802.11r. What should we do with this work item? (5 minutes) E.3 Do we need a BCP on attribute design for "classic attributes" or do we only need a design guideline for "extended attributes"? (10 minutes) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 30 Oct 2006 19:58:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: IETF-67 RADEXT Agenda Take One Date: Mon, 30 Oct 2006 14:57:33 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4953@MABOSEVS2.ets.enterasys.com> Thread-Topic: IETF-67 RADEXT Agenda Take One Thread-Index: Acb8XaK1WDvqRBhFQ/SSLNutcLZDvA== From: "Nelson, David" To: Proposed Agenda for RADEXT at IETF-67. Please comment. BTW, it would be very helpful for attendees to have read the relevant drafts. Draft authors who are available to present, please respond to the chairs, so that we can fill in the TBDs. ----------------------------------------------------------------------- Agenda for the RADEXT WG Meeting at IETF 67 Tuesday, November 7, 2006, Morning Session I 0900-1130 Room Name: Harbor Island I WGs meeting at the same time: widex, 16ng, trill, avt, dkim, ippm, rserpool =20 A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes) B. Agenda Bashing C. Milestone Status Review (5 minutes) C.1 Discussion of RADEXT Crypto-Agility work item descriptive text. (10 minutes) D. Document Status D.1 Documents with errata D.1.1 RFC 4590 has an error in the IANA assignment for a RADIUS Attribute Type ID. Discuss whether this can be handled by an RFC Editor Errata note, or whether it requires an RFC4590bis ID to correct the error. http://www.ietf.org/rfc/rfc4590.txt. (TBD, 5 minutes) =20 D.2 Documents in IESG review D.2.1 draft-ietf-radext-delegated-prefix-05.txt. (TBD, 5 minutes) D.3 Documents in Pre-WG review D.3.1 NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt=20 D.3.2 NAS-Traffic-Rule Attributes (Mauricio Sanchez, 15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-01.tx t=20 D.3.3 Extended RADIUS Attributes (TBD, 20 minutes) http://www.ietf.org/draft-lior-radius-attribute-type-extension-01.txt General Discussion of Extended Attributes, using this draft as a straw-man proposal. (WG at large, 30 minutes) =20 D.3.4 Issues & Fixes (TBD, 10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-03.txt D.4 Documents requiring cross-WG review D.4.1 RADIUS Mobile IPv6 Support (TBD, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-01.txt E. Next Steps E.1 Is it sufficient for the RADIUS Prepaid Attributes work to be published as an Informational RFC, using Vendor Specific Attributes? (10 minutes) E.2 The RADIUS WLAN Attributes work is waiting on a finalization of requirements form IEEE 802.11r. What should we do with this work item? (5 minutes) E.3 Do we need a BCP on attribute design for "classic attributes" or do we only need a design guideline for "extended attributes"? (10 minutes) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 26 Oct 2006 16:43:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RADEXT Crypto-agility work item Date: Thu, 26 Oct 2006 10:39:08 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4946@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Crypto-agility work item Thread-Index: Acb5DH5Pfk5lapY3RDOsAOeeo2Y5Kw== From: "Nelson, David" To: At IETF-66, the RADEXT chairs took the action item to come up with some charter text that would describe the scope of the crypto-agility work item. The following text is being proposed, after having been vetted by Russ Housley, Security Area AD. Please comment. If this text is acceptable to the WG, we will propose it to the O&M ADs for addition to the RADEXT charter. The RADEXT WG will review the security requirements for crypto-agility in IETF protocols, and identify the deficiencies of the existing RADIUS protocol specifications against these requirements. Specific attention will be paid to the requirements of draft-housley-aaa-key-mgmt-04.txt. The RADEXT WG will propose one or more Internet Drafts to remediate any identified deficiencies in the crypto-agility properties of the RADIUS protocol. The known deficiencies include the issue of negotiation of substitute algorithms for the message digest functions, the key-wrap functions, and the password hiding function. Additionally, at least one mandatory to implement algorithm will be defined in each of these areas, as required. Regards, =20 Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 26 Oct 2006 12:37:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of Issue: Review of draft-chowdhury-mip6-radius-02 Date: Thu, 26 Oct 2006 15:36:53 +0300 Message-ID: Thread-Topic: Review of Issue: Review of draft-chowdhury-mip6-radius-02 Thread-Index: Acb4TnDBW+sn8uCVQNi+EDa6rjdCoAAqps/A From: To: Cc: , , Hi Avi, Thanks for taking care of the issues. A couple of comments below: > 11) For the split scenario, the document should define what to put > in Service-Type and NAS-Port-Type attributes (and maybe also > Calling-Station-Id and Called-Station-Id). >=20 > [avi] Service Type we should not touch. NAS-Port-Type should be > HA-MIP6 or something like that. > > We need to find out what is going on in Diameter with this. It wouldn't hurt to specify what Service-Type the HA should use ("Framed" looks like an obvious choice). And yes, a new NAS-Port-Type might be needed. > Not sure about calling Station-ID or Called Station id, I don't > think we should specify anything for those. SDOs or specific > deployements may use those attributes. In the split scenario, Calling-Station-ID would be the obvious place to send the MN's CoA from the HA to the AAA server. If we want this to work in interoperable manner, the spec should say so. > 13) The document should either point to RFC 2548, or explicitly say > that this document does not contain an interoperable solution for > the split scenario, since it does not specify (either here or by > referencing some other document) how to send the MSK from the RADIUS > server to the HA. >=20 > [Avi] What do you mean by that? In the split scenario this document > does not send an MSK to the HA. >=20 > [Avi] I don't think we should specify how the MSK is carried. The > specific EAP methods do that see EAP-AKA EAP-TLSbis etc... We could > say in the absence of a method to transport MSK, the method > specified by RFC 2548 SHOULD be used. Note that that is not enough, > since we have to specify what goes in the SEND KEY and RECEIVE KEY. EAP methods don't carry the MSK to the HA (who needs it to complete the IKEv2 exchanges with the MN). For send/recv key, we might adapt/borrow text from RFC 4072: o Diameter EAP-Master-Session-Key AVP can be translated to the vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key attributes [RFC2548]. The first up to 32 octets of the key is stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if present) are stored into MS-MPPE-Send-Key. The encryption of this attribute is described in [RFC2548]. > 15) And last (but not least, as everyone who has followed RADEXT knows > :-): the document does not have a Diameter considerations section. >=20 > Done From vlan06.txt Modified for our purposes. The text was fine for vlan-06, but in this case, we also have draft-ietf-dime-mip6-integrated and draft-ietf-dime-mip6-split to consider. The text you proposed more-or-less makes both of them redundant. I'm not saying that's a bad thing :-) but clearly some coordination between DIME and MIP6 WGs is needed on this issue (unless we really want to have two different ways to do MIP6 in Diameter). Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Oct 2006 19:51:04 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-filter-04.txt Message-Id: Date: Wed, 25 Oct 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Filter Rule Attribute Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-filter-04.txt Pages : 10 Date : 2006-10-25 This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS), equivalent to the Diameter NAS-Filter-Rule AVP described in RFC 4005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-filter-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-filter-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-25110429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-filter-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-filter-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25110429.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Oct 2006 15:58:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Review of Issue: Review of draft-chowdhury-mip6-radius-02 Date: Wed, 25 Oct 2006 11:58:16 -0400 Message-ID: From: "Avi Lior" To: Cc: , "Kuntal Chowdhury @ Starent" , "Hannes Tschofenig" Hi Pasi, =20 Thanx for the review. I belive we have addressed most of your comments. The responses are enclosed. The comments were addressed in ietf-mip6-radius-01.txt There are some issues that were not addressed. Take a look at: 7, 11 and 13. 1) The document should give all new attributes short names that don't contain spaces (e.g. "MIP6-Home-Link-Prefix" or just "Home-Link-Prefix"). [Avi] Sounds like a good idea. The attributes are now called: MIP6-HA =20 MIP6-HA-FQDN =20 MIP6-HL-Prefix =20 MIP6-HOA DNS-Update-MO 2) Section 5: "The attributes MAY be present in the Access-Accept and the Accounting-Request." The accounting part is too ambiguous;=20 does e.g. requesting DNS update really make sense for accounting messages? At the very least, the document should explicitly say what is included in accounting messages and what it means. [avi] The following attributes MAY be included in RADIUS Accounting Packets: MIP6-HA so that backoffice may know which is the serving HA for this session. MIP6-HA-FQDN same reason as above (one or the other or both maybe used) MIP6-HOA so that the backoffice may know the IP address of the MN. 3) Section 5.2: This attribute should use the same data type as other attributes containing FQDNs (i.e., just the FQDN, without the zeroes in the beginning). [avi] I agree. Done. 4) Section 5.3: This attribute should use the same data type as other attributes containing IPv6 prefixes (e.g. Framed-IPv6-Prefix in RFC 3162). [avi] The difference is Prefix-Length. Done. 5) Section 5.5: This section should describe that the status code field uses values defined in "draft-ietf-mip6-bootstrapping-split-02"; now it gives the impression that totally number space is created (but doesn't give any IANA considerations on how to manage it). [avi] Seems reasonable. Done. 6) Section 5.5 first says "response to the request MAY not carry a FQDN value" but then changes its mind "The data field MUST contain a FQDN". If we don't use two attributes as suggested by comment 7 then reword: FQDN of the mobile node: The data field MUST contain a FQDN as described in [9]. TO: In an Access-Request the data field MUST contain a FQDN. In an Access-Accept the FQDN MAY contain a FQDN. FQDN is as specified in [9]. 7) Section 5.5: This attribute should probably be split to 2..3 separate attributes (e.g. DNS-Update-FQDN and DNS-Update-Result); this would=20 be better in line with other recent RADIUS documents. [avi] Okay. BTW CUI didnt do this. If we try to econmomize radius attributes then lets not do this. Otherwize why not. Not done. 8) Section 5: Suggest rephrasing "All bits set to 0" to "The bits MUST be initialized to zero by the sender, and MUST be ignored by the receiver." [Avi] Seems okay. Done. 9) Section 8: According to Section 5, the first four attributes are sent by the RADIUS server to the NAS, so the first column should be "0" instead of "0-1" (alternatively, Section 5 needs to specify what these attributes mean in Access-Requests).=20 We kept the attributes in the Access-Request.=20 They can act as a hint to the RADIUS server that a) the NAS supports dynamic HA assignment and b)=20 they can be a suggestion as to what values should be used when the RADIUS server does assing the=20 HA in the visited network. The RADIUS server may use these values or may use other values. 10) Section 8: The table should probably include accounting messages and CoA-Request as well. [avi] Done. Not sure if we need anything in COA since I cant think of any dynamic "actions". =20 11) For the split scenario, the document should define what to put in Service-Type and NAS-Port-Type attributes=20 (and maybe also Calling-Station-Id and Called-Station-Id). [avi] Service Type we should not touch. NAS-Port-Type should be HA-MIP6 or something like that. We need to find out what is going on in Diameter with this. Not sure about calling Station-ID or Called Station id, I don't think we should specify anything for those. SDOs or specific deployements may use those attributes. 12) The document talks about doing EAP authentication over RADIUS, but never mentions RFC 3579?=20 [avi] Add an informational reference to RFC 3579. 13) The document should either point to RFC 2548, or explicitly say that this document does not contain an interoperable solution for the split scenario,=20 since it does not specify (either here or by referencing some other document) how to send the MSK from the RADIUS server to the HA. [Avi] What do you mean by that? In the split scenario this document does not send an MSK to the HA. [Avi] I don't think we should specify how the MSK is carried. The specific EAP methods do that see EAP-AKA EAP-TLSbis etc...=20 We could say in the absence of a method to transport MSK, the method specified by RFC 2548 SHOULD be used. =20 Note that that is not enough, since we have to specify what goes in the SEND KEY and RECEIVE KEY. 14) The document should probably have at least informative reference to RFC 4306. [avi] Sure. Done. 15) And last (but not least, as everyone who has followed RADEXT knows :-): the document does not have a Diameter considerations section. Done From vlan06.txt Modified for our purposes. Diameter Considerations When used in Diameter, the attributes defined in this specification can be used as Diameter AVPs from the Code space 1-255 (RADIUS attribute compatibility space). No additional Diameter Code values are therefore allocated. The data types and flag rules for the attributes are as follows: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ | | |SHLD| MUST| | Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| -------------------------------|----+-----+----+-----|----| HA-IPv6 Address | M | P | | V | Y | HA-FQDN UTF8String | M | P | | V | Y | Home-Link-Prefix OctetString| M | P | | V | Y | HOA-IPv6 Address | M | P | | V | Y | DNS-UPDATE-TYPE OctetString| M | P | | V | Y | -------------------------------|----+-----+----+-----|----| Other than HA-IPv6 and HOA-IPv6, the attributes in this specification have no special translation requirements for Diameter to RADIUS or RADIUS to Diameter gateways; they are copied as is, except for changes relating to headers, alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC 4005] Section 9. HA-IPv6 and HOA-IPv6 must be translated between=20 their RADIUS representation of String to a Diameter Address format=20 which requires that the AddressType field be set to 2 for IP6 (IP version 6) What this specification says about the applicability of the attributes for RADIUS Access-Request packets applies in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072]. What is said about Access-Challenge applies in Diameter to AA-Answer [RFC 4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate success. Similarly, what is said about RADIUS Access-Reject packets applies in Diameter to AA- Answer or Diameter-EAP-Answer messages that indicate failure. What is said about COA-Request applies in Diameter to Re-Auth-Request [RFC 4005]. What is said about Accounting-Request applies to Diameter Accounting- Request [RFC 4005] as well. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Avi Lior =20 Bridgewater Systems Corporation=20 Phone : +1 (613) 591-9104 x6417 Cell : +1 (613) 796-4183 E-mail : mailto:avi@bridgewatersystems.com =20 www.bridgewatersystems.com =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 20 Oct 2006 23:24:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6F49E.CFBA231E" Subject: FYI: I-D ACTION:draft-lior-radius-attribute-type-extension-01.txt Date: Fri, 20 Oct 2006 16:23:51 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502D2BD4C@xmb-sjc-215.amer.cisco.com> Thread-Topic: FYI: I-D ACTION:draft-lior-radius-attribute-type-extension-01.txt Thread-Index: Acb0gkBKOupJBXegR5qFj24cXtGK6QAHHbuw From: "Glen Zorn \(gwz\)" To: DKIM-Signature: a=rsa-sha1; q=dns; l=4359; t=1161386654; x=1162250654; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:FYI=3A=20I-D=20ACTION=3Adraft-lior-radius-attribute-type-extension-01.tx t=20; X=v=3Dcisco.com=3B=20h=3DoX41scF5mwZA1RNasygrfmb1D3M=3D; b=cI6XrPjn4ejmzO7EeIrqYbsuuc3WUMwyACN7lluuyAUEnG1b+L5h/qgVFLQZ6Ov0ieYwMBS/ jFNBlY0HsLulmwf8JRhL/HP9KsyX1e3nVtBHD5g2CTGntLsFFzPkM3jX; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F49E.CFBA231E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Internet-Drafts@ietf.org supposedly scribbled on Friday, October 20, 2006 12:50 PM: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 >=20 >=20 > Title : Remote Authentication Dial In User Service (RADIUS) > Attribute Type Extension Author(s) : A. Lior, et al. > Filename : draft-lior-radius-attribute-type-extension-01.txt > Pages : 11 > Date : 2006-10-20 >=20 > In order for the Remote Authentication Dial In User Service protocol > to continue to support new applications, the RADIUS attribute space > must be extended beyond the current limit of 255 possible attribute > types. This document defines a mechanism to extend the base RADIUS > attribute types while maintaining backwards compatibility as well > as compatibility with Diameter. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext ension-01.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-lior-radius-attribute-type-extension-01.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-lior-radius-attribute-type-extension-01.txt".=20 >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------_=_NextPart_001_01C6F49E.CFBA231E Content-Type: application/octet-stream; name="ATT4024120.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT4024120.TXT Content-Disposition: attachment; filename="ATT4024120.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0xMC0yMDEyMjE1MC5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saW9yLXJhZGl1cy1hdHRy aWJ1dGUtdHlwZS1leHRlbnNpb24tMDEudHh0DQo= ------_=_NextPart_001_01C6F49E.CFBA231E Content-Type: application/octet-stream; name="draft-lior-radius-attribute-type-extension-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-lior-radius-attribute-type-extension-01.URL Content-Disposition: attachment; filename="draft-lior-radius-attribute-type-extension-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saW9yLXJhZGl1cy1hdHRyaWJ1dGUtdHlwZS1leHRlbnNpb24tMDEudHh0DQo= ------_=_NextPart_001_01C6F49E.CFBA231E Content-Type: text/plain; name="ATT4024121.txt" Content-Transfer-Encoding: base64 Content-Description: ATT4024121.txt Content-Disposition: attachment; filename="ATT4024121.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C6F49E.CFBA231E-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 20 Oct 2006 19:50:48 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-filter-03.txt Message-Id: Date: Fri, 20 Oct 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Filter Rule Attribute Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-filter-03.txt Pages : 11 Date : 2006-10-20 This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS), equivalent to the Diameter NAS-Filter-Rule AVP described in RFC 4005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-filter-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-filter-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-20142234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-filter-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-filter-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-20142234.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 20 Oct 2006 03:55:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Filter Separation using a NUL? Date: Thu, 19 Oct 2006 20:55:08 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502D2B8A9@xmb-sjc-215.amer.cisco.com> Thread-Topic: Filter Separation using a NUL? Thread-Index: AcbziIevPva/R7iaRGWILzwJL9W8kQAcimrQ From: "Glen Zorn \(gwz\)" To: "Emile van Bergen" Cc: "Bernard Aboba" , , DKIM-Signature: a=rsa-sha1; q=dns; l=2639; t=1161316511; x=1162180511; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Filter=20Separation=20using=20a=20NUL?; X=v=3Dcisco.com=3B=20h=3De0rWTOWwt+UYSyGKdH9Y5Lx0SDA=3D; b=E1F1DONL6/5+McFHziq6DmR/SXtz/+f7z+yUyhcKk6uyL+j79R3tHuMXnPXUHVjXBmihArno 7bRoKMVehZ5NHQ+k6p5QkDwaDkffgRGSgblZTKNLtu5YdpqOiurPKvuO; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Emile van Bergen supposedly scribbled on Thursday, October 19, 2006 7:15 AM: > Hi, >=20 > On Thu, Oct 19, 2006 at 01:52:39AM -0700, Glen Zorn (gwz) wrote: >=20 >> OK, I'm having a little trouble understanding the point of this & the >> reasoning behind it. I thought that the problem we were trying to >> solve was the transmission of a filter set, consisting of one or more >> rules, which is potentially larger than the data size of a RADIUS >> attribute. Further, the document leads me to believe that it is >> expected that=20 >> this set will be used as such, giving explicit instructions for its >> reconstruction on the client ("Where multiple NAS-Filter-Rule >> attributes are included in a RADIUS packet, the String field of the >> attributes are to be concatenated to form a set of filter rules."); >> presumably, the client will need to parse these rules in order to >> install them, since the syntax used is that of BSD (not the most >> popular NAS OS on the planet, AFAIK). So what is the point of taking >> apart this nice set, parsing it into individual rules, then >> reconcatenating the >> (NUL-terminated) rules into a set again for transmission? I suspect >> that I'm just confused, but maybe somebody can help me out. >=20 > As far as I've understood the case so far, there is an encoding > defined for individual rules, but no encoding for a complete rule > set. =20 "Where multiple NAS-Filter-Rule attributes are included in a RADIUS packet, the String field of the attributes are to be concatenated to form a set of filter rules." This appears to me to state that a filter rule set is exactly the result of in-order concatenation of the individual rules. >=20 > The knowledge of where each rule begins and ends therefore needs to > be transported out of band, along with the rule set string.=20 OK, one more time: if the goal is to end up w/the concatenation of the rules into a rule set, why is it necessary to know where the individual rules begin or end (except, of course, for the first and last rules in the set)? >=20 > DIAMETER uses separate attribute instances for that purpose; what's > just been proposed is that RADIUS uses NUL characters instead. Thus, > we first define a single long rule set string, and then say that it > is to be transported in a 0-1 "single long" attribute (which is > formed by concatenating all instances of a string attribute in their > order of appearance in the packet). =20 See above. Maybe the text I'm quoting is in error? =20 >=20 > Cheers, >=20 >=20 > Emile. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 22:07:01 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: Filter Separation using a NULL? cc: radiusext@ops.ietf.org Date: Thu, 19 Oct 2006 17:55:44 -0400 Message-Id: <20061019215544.7327A16CBC@mail.nitros9.org> "Bernard Aboba" wrote: > Thanks. Here is some revised text: Looks good to me. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 19:50:40 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-05.txt Message-Id: Date: Thu, 19 Oct 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Delegated-IPv6-Prefix Attribute Author(s) : J. Salowey, R. Droms Filename : draft-ietf-radext-delegated-prefix-05.txt Pages : 9 Date : 2006-10-19 This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-delegated-prefix-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-delegated-prefix-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-19115057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-delegated-prefix-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-delegated-prefix-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19115057.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 16:05:39 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: mauricio.sanchez@hp.com, openradius-radextwg@e-advies.nl, radiusext@ops.ietf.org Bcc: Subject: Re: Filter Separation using a NULL? Date: Thu, 19 Oct 2006 09:04:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Thanks. Here is some revised text: String The String field is one or more octets. It contains filter rules in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with individual filter rules separated by a NUL (0x00). A NAS-Filter- Rule attribute may contain a partial rule, one rule, or more than one rule. Filter rules may be continued across attribute boundaries, so implementations cannot assume that individual filter rules begin or end on attribute boundaries. The set of NAS-Filter-Rule attributes SHOULD be created by concatenating the individual filter rules, separated by a NUL (0x00) octet. The resulting data should be split on 253 byte boundaries to obtain a set of NAS-Filter-Rule attributes. On reception, the individual filter rules SHOULD be determined by concatenating the contents of all NAS-Filter-Rule attributes, and then splitting individual filter rules with the the NUL octet (0x00) as a delimeter. > I would say: > > The String field is one or more octets. It contains filter rules > in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with > individual filter rules separated by a NULL (0x00). A > NAS-Filter-Rule attribute may contain a partial rule, one rule, > or more than one rule. Filter rules may be continued across > attribute boundaries, so implementations cannot assume that > individual filter rules begin or end on attribute boundaries. > > The set of NAS-Filter-Rule attributes SHOULD be created by > concatenating the individual filter rules, separated by a NULL > (0x00) character. The resulting data should be split on 252 > byte boundaries to obtain a set of NAS-Filter-Rule attributes. > On reception, the individual filter rules SHOULD be determined > by concatenating the contents of all NAS-Filter-Rule attributes, > and then splitting the resulting data at the NULL (0x00) characters. > > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 14:12:24 +0000 Date: Thu, 19 Oct 2006 16:14:40 +0200 From: Emile van Bergen To: "Glen Zorn \(gwz\)" Cc: Bernard Aboba , mauricio.sanchez@hp.com, radiusext@ops.ietf.org Subject: Re: Filter Separation using a NUL? Message-ID: <20061019141440.GA31449@web1> Mail-Followup-To: "Glen Zorn (gwz)" , Bernard Aboba , mauricio.sanchez@hp.com, radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Oct 19, 2006 at 01:52:39AM -0700, Glen Zorn (gwz) wrote: > OK, I'm having a little trouble understanding the point of this & the > reasoning behind it. I thought that the problem we were trying to solve > was the transmission of a filter set, consisting of one or more rules, > which is potentially larger than the data size of a RADIUS attribute. > Further, the document leads me to believe that it is expected that this > set will be used as such, giving explicit instructions for its > reconstruction on the client ("Where multiple NAS-Filter-Rule attributes > are included in a RADIUS packet, the String field of the attributes are > to be concatenated to form a set of filter rules."); presumably, the > client will need to parse these rules in order to install them, since > the syntax used is that of BSD (not the most popular NAS OS on the > planet, AFAIK). So what is the point of taking apart this nice set, > parsing it into individual rules, then reconcatenating the > (NUL-terminated) rules into a set again for transmission? I suspect > that I'm just confused, but maybe somebody can help me out. As far as I've understood the case so far, there is an encoding defined for individual rules, but no encoding for a complete rule set. The knowledge of where each rule begins and ends therefore needs to be transported out of band, along with the rule set string. DIAMETER uses separate attribute instances for that purpose; what's just been proposed is that RADIUS uses NUL characters instead. Thus, we first define a single long rule set string, and then say that it is to be transported in a 0-1 "single long" attribute (which is formed by concatenating all instances of a string attribute in their order of appearance in the packet). Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 08:53:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Filter Separation using a NULL? Date: Thu, 19 Oct 2006 01:52:39 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502CCA7F0@xmb-sjc-215.amer.cisco.com> Thread-Topic: Filter Separation using a NULL? Thread-Index: AcbzOmo5e+bieuNXQiOwseRIS7DBhQAHaPHg From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , , , DKIM-Signature: a=rsa-sha1; q=dns; l=3625; t=1161247960; x=1162111960; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Filter=20Separation=20using=20a=20NULL?; X=v=3Dcisco.com=3B=20h=3D7BzlS7H2damIyb0M114tgYpiRgQ=3D; b=z6r3zSFsXtu7FNRfW9n6Yd/IFBR8R2zn4nHsz6g9G2zqvmvim+MXzRiFVEf7D9QogSl2E8Wf kr3Wtede/wEOMiENi9fykCrQ8z0fKJ1JZ75cjoNzrOW7ooilH+BZhatv; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba <> supposedly scribbled on Wednesday, October 18, 2006 9:52 PM: > To clarify Mauricio's question, I've changed the text somewhat. The > updated text is available for inspection here:=20 >=20 > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-03.txt OK, I'm having a little trouble understanding the point of this & the reasoning behind it. I thought that the problem we were trying to solve was the transmission of a filter set, consisting of one or more rules, which is potentially larger than the data size of a RADIUS attribute. Further, the document leads me to believe that it is expected that this set will be used as such, giving explicit instructions for its reconstruction on the client ("Where multiple NAS-Filter-Rule attributes are included in a RADIUS packet, the String field of the attributes are to be concatenated to form a set of filter rules."); presumably, the client will need to parse these rules in order to install them, since the syntax used is that of BSD (not the most popular NAS OS on the planet, AFAIK). So what is the point of taking apart this nice set, parsing it into individual rules, then reconcatenating the (NUL-terminated) rules into a set again for transmission? I suspect that I'm just confused, but maybe somebody can help me out. =20 >=20 > Here is how the new Section 2 reads: >=20 > 2. NAS-Filter-Rule Attribute >=20 > Description >=20 > This attribute indicates filter rules to be applied for this > user. Zero or more NAS-Filter-Rule attributes MAY be sent in > Access- Accept, CoA-Request, or Accounting-Request packets. >=20 > The NAS-Filter-Rule attribute is not intended to be used > concurrently with any other filter rule attribute, including > Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and > MUST NOT appear in the same RADIUS packet. If a Filter-Id or > NAS- Traffic-Rule attribute is present, then implementations of > this specification MUST silently discard NAS-Filter-Rule > attributes, if present. >=20 > Where multiple NAS-Filter-Rule attributes are included in a > RADIUS packet, the String field of the attributes are to be > concatenated to form a set of filter rules. As noted in > [RFC2865] Section 2.3, "the forwarding server MUST NOT change > the order of any attributes of the same type", so that RADIUS > proxies will not reorder NAS- Filter-Rule attributes. >=20 > A summary of the NAS-Filter-Rule Attribute format is shown > below. The fields are transmitted from left to right. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =20 > =20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =20 > Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 >=20 > Type >=20 > TBD >=20 > Length >=20 > >=3D3 >=20 > String >=20 > The String field is one or more octets. It contains filter > rules in the IPFilterRule syntax defined in [RFC3588] Section > 4.3, with filter rules separated by a NULL (0x00). One or more > filter rules may be included within a NAS-Filter-Rule > attribute, and filter rules may be continued across attribute > boundaries, so in general implementations cannot assume that > filter rules begin and end on attribute boundaries. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 06:57:30 +0000 Date: Thu, 19 Oct 2006 08:59:57 +0200 From: Emile van Bergen To: Bernard Aboba Cc: barney@databus.com, radiusext@ops.ietf.org Subject: Re: Request for Review: RADIUS Filter Attribute Document Message-ID: <20061019065957.GA30151@web1> Mail-Followup-To: Bernard Aboba , barney@databus.com, radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Wed, Oct 18, 2006 at 09:45:49PM -0700, Bernard Aboba wrote: > >I have mixed feelings. On the one hand, there is precedent for glomming > >all instances of an attribute together, for EAP. On the other, EAP is > >different in that the RADIUS code does not parse the result. What will > >happen with the next attribute, where a byte value of 0x00 may be valid? > > This approach works for this particular attribute because the IPFilter > syntax only permits ASCII characters. It's not a general solution, as you > point out. That wider problem may be part of the extended attribute > discussion. Since NAS-Filter-Rule isn't an extended attribute I think that > discussion is somewhat orthogonal. Well, the solution may be more general than people think, considering it has two orthogonal parts: 1. concatenation, 2. splitting. The first part, concatenation, can be used a. stand-alone (without subsequent splitting), useful for eg. EAP, but also for all other > 253 attributes of which only 0..1 instances can occur; b. with splitting on a delimiter (as just proposed for NAS-Filter-Rule); c. with splitting based on a length, value scheme (needed for octet string attributes), and d. with splitting based on a type, (flags or tag + child tag), length, value scheme, as proposed in the various extended attribute drafts. If you can't put any constraints on the values of the octets in an attribute, then you simply need c. instead of b., but the method of concatenation while disregarding original attribute boundaries still stands. How does c. work? Let's assume we need a new (octet) string attribute, 0..n instances, any number of instances, possibly > 253 in length. As said, we first perform standard attribute concatenation, to get a single octet string of size up to ~4000. Then, instead of splitting on a delimiter as proposed for NAS-Filter-Rule, you decode this string as a series of length, value pairs to get the real "instances": 0 1 2 +----+----+----+---- ~ --+----+----+----+---- | Length1 | Value1... | Length2 | Value2... +----+----+----+---- ~ --+----+----+----+---- If that looks familiar, it is; it's a normal RADIUS attribute without the 'type' field and with a 2-octet length field. So, it's pick and choose. We don't even need to design a single extended attribute that does it all. You can overcome the <= 253 value size limit by concatenation, at the price of limiting an attribute to one long instance. This is sufficient for EAP-Message and possibly other attributes. On top of that facility, you can overcome the single long instance limit per attribute type by splitting on delimiters, at the price of limiting value ranges (sufficient for NAS-Filter-Rule), or by splitting using internal length fields. On top of the last facility, you can overcome the <= 255 attribute type number space limit by adding a (wider) type field to each internal attribute instance contained in the concatenated string. To overcome the limited outer structure (flat list of attributes), you can either physically nest attributes inside one another (diameter-based drafts), or add a tag and a child-tag field (my draft) to each internal attribute instance contained in the concatenated string. In short, the concatenation half of the solution is as generic as you can get; it's already in use for EAP and you can build all other facilities that were discussed here in the past year on top of it. The splitting-on-a-delimiter is indeed limited to text values, but we can just as well decide to split-on-a-two-octet-length-field instead, which has no other side effects than being slightly less efficient for text values. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 05:34:38 +0000 Date: Thu, 19 Oct 2006 01:34:26 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Request for Review: RADIUS Filter Attribute Document Message-ID: <20061019053426.GA32499@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) On Wed, Oct 18, 2006 at 10:01:56PM -0700, Glen Zorn (gwz) wrote: > Bernard Aboba <> supposedly scribbled on Wednesday, October 18, 2006 > 9:46 PM: > > >> I have mixed feelings. On the one hand, there is precedent for > >> glomming all instances of an attribute together, for EAP. On the > >> other, EAP is different in that the RADIUS code does not parse the > >> result. What will happen with the next attribute, where a byte > >> value of 0x00 may be valid? > > > > This approach works for this particular attribute because the > > IPFilter syntax only permits ASCII characters. It's not a general > > solution, as you point out. That wider problem may be part of the > > extended attribute discussion. Since NAS-Filter-Rule isn't an > > extended attribute I think that discussion is somewhat orthogonal. > > I think that if we can really come to an agreement upon the extension > method fairly soon it should be. I strongly agree with Glen. "There's more than one way to do it" works well for Perl but not for us. -- Barney Wolff I never met a computer I didn't like. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 05:16:22 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: Filter Separation using a NULL? cc: mauricio.sanchez@hp.com, openradius-radextwg@e-advies.nl, radiusext@ops.ietf.org Date: Thu, 19 Oct 2006 01:10:06 -0400 Message-Id: <20061019051006.077E716CBC@mail.nitros9.org> "Bernard Aboba" wrote: ... I would say: The String field is one or more octets. It contains filter rules in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with individual filter rules separated by a NULL (0x00). A NAS-Filter-Rule attribute may contain a partial rule, one rule, or more than one rule. Filter rules may be continued across attribute boundaries, so implementations cannot assume that individual filter rules begin or end on attribute boundaries. The set of NAS-Filter-Rule attributes SHOULD be created by concatenating the individual filter rules, separated by a NULL (0x00) character. The resulting data should be split on 252 byte boundaries to obtain a set of NAS-Filter-Rule attributes. On reception, the individual filter rules SHOULD be determined by concatenating the contents of all NAS-Filter-Rule attributes, and then splitting the resulting data at the NULL (0x00) characters. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 05:02:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: RADIUS Filter Attribute Document Date: Wed, 18 Oct 2006 22:01:56 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502CCA7C9@xmb-sjc-215.amer.cisco.com> Thread-Topic: Request for Review: RADIUS Filter Attribute Document Thread-Index: AcbzOX+wJmtwMTiURbCIdhZnjGQvAwAAgo8w From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=856; t=1161234119; x=1162098119; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Request=20for=20Review=3A=20RADIUS=20Filter=20Attribute=20Docume nt; X=v=3Dcisco.com=3B=20h=3DoaAHH9ZdidORUc8kqMxV7HClG9M=3D; b=NGu+p4fdu7vJ94zHRsdMzzfya/PLtt3qrYXobsItOBzSd5JC+xQxOCtS3/xpjroQ+LllF1iz C3/RyKkBBwJytB5x6rBl5J0iJxndzdnaUssvQonFpbA8xRd2F3OXsjZv; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba <> supposedly scribbled on Wednesday, October 18, 2006 9:46 PM: >> I have mixed feelings. On the one hand, there is precedent for >> glomming all instances of an attribute together, for EAP. On the >> other, EAP is different in that the RADIUS code does not parse the >> result. What will happen with the next attribute, where a byte >> value of 0x00 may be valid?=20 >=20 > This approach works for this particular attribute because the > IPFilter syntax only permits ASCII characters. It's not a general > solution, as you point out. That wider problem may be part of the > extended attribute discussion. Since NAS-Filter-Rule isn't an > extended attribute I think that discussion is somewhat orthogonal.=20 I think that if we can really come to an agreement upon the extension method fairly soon it should be. =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 04:52:41 +0000 Message-ID: From: "Bernard Aboba" To: mauricio.sanchez@hp.com, openradius-radextwg@e-advies.nl, radiusext@ops.ietf.org Bcc: Subject: RE: Filter Separation using a NULL? Date: Wed, 18 Oct 2006 21:52:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed To clarify Mauricio's question, I've changed the text somewhat. The updated text is available for inspection here: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-03.txt Here is how the new Section 2 reads: 2. NAS-Filter-Rule Attribute Description This attribute indicates filter rules to be applied for this user. Zero or more NAS-Filter-Rule attributes MAY be sent in Access- Accept, CoA-Request, or Accounting-Request packets. The NAS-Filter-Rule attribute is not intended to be used concurrently with any other filter rule attribute, including Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST NOT appear in the same RADIUS packet. If a Filter-Id or NAS- Traffic-Rule attribute is present, then implementations of this specification MUST silently discard NAS-Filter-Rule attributes, if present. Where multiple NAS-Filter-Rule attributes are included in a RADIUS packet, the String field of the attributes are to be concatenated to form a set of filter rules. As noted in [RFC2865] Section 2.3, "the forwarding server MUST NOT change the order of any attributes of the same type", so that RADIUS proxies will not reorder NAS- Filter-Rule attributes. A summary of the NAS-Filter-Rule Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length >=3 String The String field is one or more octets. It contains filter rules in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with filter rules separated by a NULL (0x00). One or more filter rules may be included within a NAS-Filter-Rule attribute, and filter rules may be continued across attribute boundaries, so in general implementations cannot assume that filter rules begin and end on attribute boundaries. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 04:46:00 +0000 Message-ID: From: "Bernard Aboba" To: barney@databus.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Request for Review: RADIUS Filter Attribute Document Date: Wed, 18 Oct 2006 21:45:49 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I have mixed feelings. On the one hand, there is precedent for glomming >all instances of an attribute together, for EAP. On the other, EAP is >different in that the RADIUS code does not parse the result. What will >happen with the next attribute, where a byte value of 0x00 may be valid? This approach works for this particular attribute because the IPFilter syntax only permits ASCII characters. It's not a general solution, as you point out. That wider problem may be part of the extended attribute discussion. Since NAS-Filter-Rule isn't an extended attribute I think that discussion is somewhat orthogonal. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Oct 2006 04:42:52 +0000 Message-ID: From: "Bernard Aboba" To: mauricio.sanchez@hp.com, openradius-radextwg@e-advies.nl, radiusext@ops.ietf.org Bcc: Subject: RE: Filter Separation using a NULL? Date: Wed, 18 Oct 2006 21:41:54 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Can we be stronger and state MUST NOT instead of SHOULD NOT on the mixture >of NAS-Traffic-Rule and NAS-Filter-Rule? If we stick with SHOULD NOT, then >what is the expected behavior of the NAS when both appear? We can say MUST NOT, although then we'd probably say what a NAS should do if both are included. >RADIUS packet or RADIUS message? I thought the right term was message. The term packet is used in RFC 2865. >The current wording of "...filter rules separated by a NULL" makes it sound >like multiple rules can be put in within a single NAS-Filter-Id attribute. I think this is what Emile suggested -- you concatenate all the attribute together and then separate the rules via the NULL character. So you could have multiple rules in one attribute, partial rules split between attributes, etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 16:53:38 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Filter Separation using a NULL? Date: Wed, 18 Oct 2006 11:52:15 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C3_01C6F29B.1736AE30" Message-ID: <2F2D38A4B8346F48A683750A46BAB2117018C6@G3W0072.americas.hpqcorp.net> Thread-Topic: Filter Separation using a NULL? Thread-Index: Acbyudv11z5IrqTNTy6VlLYg1wT5NgAGaU3w From: "Sanchez, Mauricio (ProCurve)" To: "Bernard Aboba" , , This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C6F29B.1736AE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit See below... > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, October 18, 2006 6:32 AM > To: openradius-radextwg@e-advies.nl; radiusext@ops.ietf.org > Subject: Filter Separation using a NULL? > The NAS-Filter-Rule attribute is not intended to be used > concurrently with any other filter rule attribute, including > Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and > SHOULD NOT appear in the same RADIUS packet. If a Filter-Id Can we be stronger and state MUST NOT instead of SHOULD NOT on the mixture of NAS-Traffic-Rule and NAS-Filter-Rule? If we stick with SHOULD NOT, then what is the expected behavior of the NAS when both appear? RADIUS packet or RADIUS message? I thought the right term was message. > attribute is present, then implementations of this specification > MUST silently discard NAS-Filter-Rule attributes, if present. > The String field is one or more octets. It contains > filter rules > in the IPFilterRule syntax defined in [RFC3588] Section > 4.3, with > filter rules separated by a NULL (0x00). A robust > implementation > SHOULD support the field as undistinguished octets. The current wording of "...filter rules separated by a NULL" makes it sound like multiple rules can be put in within a single NAS-Filter-Id attribute. Is this the case? If not, consider instead the wording "filter rules terminated by a NULL (0x00)" and stating that the start of a new rule should always use an additional attribute. MS ------=_NextPart_000_00C3_01C6F29B.1736AE30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MTAxODE2NTIxNFowIwYJ KoZIhvcNAQkEMRYEFHAh5ZYoSg7ynWarFMOMBvyuPUexMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgIYgccjieHWbCTYdiiNq1hj8dhneVYJJF+B35AuiRbfNoQctVJm7M/4JIcTT5MVU XR9PT33nPlg8Ll45y+iLBLtz9qIY/lObsS9hU9akQgsXVo6MIkrK738k5oyr9RB1Dgw4Dwv3ADBB nlIDke6OB/sl4ut+jyM/1maCf4ScABCrAAAAAAAA ------=_NextPart_000_00C3_01C6F29B.1736AE30-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 16:53:30 +0000 Date: Wed, 18 Oct 2006 12:52:21 -0400 From: Barney Wolff To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Request for Review: RADIUS Filter Attribute Document Message-ID: <20061018165221.GA20537@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) On Wed, Oct 18, 2006 at 06:12:40AM -0700, Bernard Aboba wrote: > >I am increasingly convinced that the attempt to re-use the tag mechanism > >for segmentation and concatenation is misguided and will lead implementers > >into trouble. > > Question: what do you think of Emile's proposal to just use a \0 as a > delimiter? It would appear that this approach doesn't require any tags at > all. I have mixed feelings. On the one hand, there is precedent for glomming all instances of an attribute together, for EAP. On the other, EAP is different in that the RADIUS code does not parse the result. What will happen with the next attribute, where a byte value of 0x00 may be valid? I wish the WG would support solving the problems of attribute type exhaustion, grouping and length limitation once rather than re-invent polygonal wheels endlessly. Ok, if the Diameter attribute header is too big, ugly and NIH to be accepted, RADIUS can have its own extended attribute header. But if we're going to bite that bullet, we SHOULD first agree on requirements and how competing proposals will be evaluated, before making proposals. To repeat approximately a slide from last March, here is my view: Criteria for evaluating extended attribute format This is Transfer syntax, must support desired power & flexibility available to definers of new RADIUS features Top priorities remove 255 limit on attribute type number remove 253 limit on attribute value length support rich set of standard attribute value types support grouping easy transition of attributes from vsa to standard Mid priorities ease of gatewaying <-> Diameter support multi-level (nested) grouping M-bit build on / re-use existing work Low priorities minimal attribute header size elegance, alas Alternatively, we could with little loss of realistic function simply declare that no filter rule can exceed 253 bytes. -- Barney Wolff I never met a computer I didn't like. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 15:21:38 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: Request for Review: RADIUS Filter Attribute Document Date: Wed, 18 Oct 2006 08:21:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Does anyone see the need for tagged sets of rules, in the same vein that >we have tagged sets of tunnel attributes, i.e. as alternative sets of >rules? The goal of this document is to provide the same functionality as the NAS-Filter-Rule AVP in Diameter, which doesn't support alternative rule sets. If there is a need for that feature at all, it can be provided as an extension to the filter rule language itself, without the need for tagging. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 15:02:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: RADIUS Filter Attribute Document Date: Wed, 18 Oct 2006 11:02:40 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565605A492A@MABOSEVS2.ets.enterasys.com> Thread-Topic: Request for Review: RADIUS Filter Attribute Document Thread-Index: AcbywzFoPFfNa8FNRQey8sNA0XxPQwAAv6rg From: "Nelson, David" To: Emile van Bergen writes... > Not for NAS-Filter-Rule's basic function as a transport mechanism > for a single rule set, no. Does anyone see the need for tagged sets of rules, in the same vein that we have tagged sets of tunnel attributes, i.e. as alternative sets of rules? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 14:59:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Filter Separation using a NULL? Date: Wed, 18 Oct 2006 10:59:25 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4929@MABOSEVS2.ets.enterasys.com> Thread-Topic: Filter Separation using a NULL? Thread-Index: AcbyudKuLHUBEoqEQKaj5kYVJyTXagAC2sbQ From: "Nelson, David" To: Bernard Aboba writes... > The String field is one or more octets. It contains filter rules > in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with > filter rules separated by a NULL (0x00). A robust implementation > SHOULD support the field as undistinguished octets. The sentence "A robust implementation SHOULD support the field as undistinguished octets." is standard in RADIUS documents, achieving the status of special "words of art". Yet, in this context, I wonder what it means. I would think that "undistinguished octets" means the same thing as "opaque binary blob". Yet, that clearly can't be the case, as we anticipate that the attribute contents are a sequence of ASCII strings delimited by NULs. So, what exactly does this sentence mean to convey? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 14:39:03 +0000 Date: Wed, 18 Oct 2006 16:41:36 +0200 From: Emile van Bergen To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Request for Review: RADIUS Filter Attribute Document Message-ID: <20061018144136.GA26737@web1> Mail-Followup-To: Bernard Aboba , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Wed, Oct 18, 2006 at 06:11:29AM -0700, Bernard Aboba wrote: > [EvB] > >To my mind, such an approach to long attributes (concatenate first; then > >resplit if necessary) is both more generic and simpler, and solves the > >issue at hand. > > It should be easy to implement, either in a NAS or in a RADIUS/Diameter > gateway. Do we even need a tag at all if we adopt this proposal? Not for NAS-Filter-Rule's basic function as a transport mechanism for a single rule set, no. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 13:32:05 +0000 Message-ID: From: "Bernard Aboba" To: openradius-radextwg@e-advies.nl, radiusext@ops.ietf.org Bcc: Subject: Filter Separation using a NULL? Date: Wed, 18 Oct 2006 06:31:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed A respin of the document based on your suggestion is available here: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-03.txt Here is what Section 2 now looks like -- it is indeed much simpler, and I can't see that any functionality has been lost. What do people think? 2. NAS-Filter-Rule Attribute Description This attribute indicates filter rules to be applied for this user. Zero or more NAS-Filter-Rule attributes MAY be sent in Access- Accept, CoA-Request, or Accounting-Request packets. The NAS-Filter-Rule attribute is not intended to be used concurrently with any other filter rule attribute, including Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and SHOULD NOT appear in the same RADIUS packet. If a Filter-Id attribute is present, then implementations of this specification MUST silently discard NAS-Filter-Rule attributes, if present. Where multiple NAS-Filter-Rule attributes are included in a RADIUS packet, the String field of the attributes are to be concatenated to form a set of filter rules. As noted in [RFC2865] Section 2.3, "the forwarding server MUST NOT change the order of any attributes of the same type", so that RADIUS proxies will not reorder NAS- Filter-Rule attributes. A summary of the NAS-Filter-Rule Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length >=4 String The String field is one or more octets. It contains filter rules in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with filter rules separated by a NULL (0x00). A robust implementation SHOULD support the field as undistinguished octets. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 13:12:47 +0000 Message-ID: From: "Bernard Aboba" To: barney@databus.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Request for Review: RADIUS Filter Attribute Document Date: Wed, 18 Oct 2006 06:12:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I am increasingly convinced that the attempt to re-use the tag mechanism >for segmentation and concatenation is misguided and will lead implementers >into trouble. Question: what do you think of Emile's proposal to just use a \0 as a delimiter? It would appear that this approach doesn't require any tags at all. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 13:12:03 +0000 Message-ID: From: "Bernard Aboba" To: openradius-radextwg@e-advies.nl, radiusext@ops.ietf.org Bcc: Subject: Re: Request for Review: RADIUS Filter Attribute Document Date: Wed, 18 Oct 2006 06:11:29 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I still strongly feel the tag scheme is needlessly complex for what it >intends to achieve. Simple is better, of course. >Also, the requirement that even though the attribute has a tag, a strict >ordering of attribute instances must be maintained /disregarding the >tags/, meaning that you have to maintain the order in which the tagged >sets appear, including their interleaving, seems a little at odds with >the spirit of other uses of tags, such as eg. RFC2869. Of course it is >allowed because of the ordering requirements in RFC2865, but it creates >a new requirement from a tagged attribute viewpoint. Right. >With 'normal' tagged attributes, there is no relative ordering between >tagged sets that must be maintained, i.e. for most purposes you can >consider an attribute with a different tag a wholly different attribute >type. > >I think there is a simpler solution, /if/ you let go of the desire to >represent a single rule in a single attribute 'most of the time'. > >Once you do that, you can specify that in order to interpret >NAS-Filter-Rule, the values of /all/ instances must first be bluntly >concatenated based on their normal order of appearance (as also done for >EAP; it's perfectly OK to rely on relative ordering among attributes >having the same type and tag), and then split using a simple delimiting >to obtain the individual filtering rules. > >Whether that splitting is done the same way as in DNS (a length byte (in >our case that would be 2 bytes) before every individual rule), or using >a real delimiter (\0, \n, whatever, anything that does not appear in an >individual filter rule), is mostly a matter of taste. Since in practice the rules are only expressed in ASCII, \0 would work. >To my mind, such an approach to long attributes (concatenate first; then >resplit if necessary) is both more generic and simpler, and solves the >issue at hand. It should be easy to implement, either in a NAS or in a RADIUS/Diameter gateway. Do we even need a tag at all if we adopt this proposal? >Because of its layering, it's also more future proof, as the upper half >of the solution (splitting) may be preserved when other generic methods >of transporting longer values appear, and creates a useful de-facto >representation of a rule set as a single octet string as a byproduct; >the lower half of the solution -- the method of encoding a single long >attribute by plain concatenation of RADIUS attributes -- can also be >used for other attribute types and delimiting styles. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 08:13:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Review requested: draft-ietf-radext-filter-02.txt Date: Wed, 18 Oct 2006 10:12:35 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E030135A428@SEHAN021MB.tcad.telia.se> Thread-Topic: Review requested: draft-ietf-radext-filter-02.txt Thread-Index: AcbnKMT5dnJyc+BzTPmdwrQRW6hRyQHfD6Kw From: To: , Hi, I have basically few issues related to the tags. RFC2868 says that tags are between 0x01-0x1f. Then RFC2882 says tags are between 0x01-0x3f (and giving the reference to RFC2868) like this draft also. I lack history here for the reason, which I assume exists. But I guess we=20 should go for the original range if there is no compelling reason to use the extended range. Also why using tags in a middle of range? Can't we just use 0x01 when the attribute is not concatenated and 0x02 -> 0x1f when the attribute is concatenated? Honestly, whether we use tags or one bit, I don't really care ;) Maybe the one bit approach as suggested by some ppl could be simpler. Cheers, Jouni > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: 3. lokakuuta 2006 23:14 > To: radiusext@ops.ietf.org > Subject: Review requested: draft-ietf-radext-filter-02.txt >=20 > A new version has been posted to the archive: > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt >=20 > Does this version address the open issues (198 & 202)? Are=20 > there any other=20 > issues/problems with it? >=20 > 3GPP asked out the status of it in the last IETF/3GPP liaison=20 > conference=20 > call. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 07:17:57 +0000 Date: Wed, 18 Oct 2006 09:20:33 +0200 From: Emile van Bergen To: radiusext@ops.ietf.org Cc: Bernard Aboba Subject: Re: Request for Review: RADIUS Filter Attribute Document Message-ID: <20061018072033.GA25400@web1> Mail-Followup-To: radiusext@ops.ietf.org, Bernard Aboba Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Tue, Oct 17, 2006 at 07:01:57PM -0700, Bernard Aboba wrote: > The RADIUS Filter Attribute document has gone through another revision to > address the filter continuation issue. Please review the current version > and send comments to the WG list: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt > > Are the changes an improvement? I still strongly feel the tag scheme is needlessly complex for what it intends to achieve. Also, the requirement that even though the attribute has a tag, a strict ordering of attribute instances must be maintained /disregarding the tags/, meaning that you have to maintain the order in which the tagged sets appear, including their interleaving, seems a little at odds with the spirit of other uses of tags, such as eg. RFC2869. Of course it is allowed because of the ordering requirements in RFC2865, but it creates a new requirement from a tagged attribute viewpoint. With 'normal' tagged attributes, there is no relative ordering between tagged sets that must be maintained, i.e. for most purposes you can consider an attribute with a different tag a wholly different attribute type. I think there is a simpler solution, /if/ you let go of the desire to represent a single rule in a single attribute 'most of the time'. Once you do that, you can specify that in order to interpret NAS-Filter-Rule, the values of /all/ instances must first be bluntly concatenated based on their normal order of appearance (as also done for EAP; it's perfectly OK to rely on relative ordering among attributes having the same type and tag), and then split using a simple delimiting to obtain the individual filtering rules. Whether that splitting is done the same way as in DNS (a length byte (in our case that would be 2 bytes) before every individual rule), or using a real delimiter (\0, \n, whatever, anything that does not appear in an individual filter rule), is mostly a matter of taste. To my mind, such an approach to long attributes (concatenate first; then resplit if necessary) is both more generic and simpler, and solves the issue at hand. Because of its layering, it's also more future proof, as the upper half of the solution (splitting) may be preserved when other generic methods of transporting longer values appear, and creates a useful de-facto representation of a rule set as a single octet string as a byproduct; the lower half of the solution -- the method of encoding a single long attribute by plain concatenation of RADIUS attributes -- can also be used for other attribute types and delimiting styles. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 06:56:21 +0000 Date: Wed, 18 Oct 2006 02:54:34 -0400 From: Barney Wolff To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Request for Review: RADIUS Filter Attribute Document Message-ID: <20061018065434.GA75345@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) On Tue, Oct 17, 2006 at 07:01:57PM -0700, Bernard Aboba wrote: > The RADIUS Filter Attribute document has gone through another revision to > address the filter continuation issue. Please review the current version > and send comments to the WG list: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt > > Are the changes an improvement? I am increasingly convinced that the attempt to re-use the tag mechanism for segmentation and concatenation is misguided and will lead implementers into trouble. In the realm of biology, frequent instances of genes and structures being re-used, often quite clumsily, for completely new functions is one of the proofs of natural evolution rather than intelligent design. But protocols do, or should, have intelligent designers. Tags were designed to collect different attributes, in arbitrary order, into groups. Limitations on tag values (originally 0x01-0x1f - when did that change to 0x3f?) were motivated by allowing the tags to be optional. Group precedence was defined by an explicit attribute. For segmentation, a simple 1-bit question needs to be answered: Does this attribute, of maximum length, stand on its own or is the next filter attribute to be concatenated with it? From that point of view, the rules on tag values and especially against repetition of a tag value, make no sense. But there is a more subtle trap waiting for the implementer who blindly uses existing tag code. Filter rule precedence is governed by the order of appearance in the RADIUS message. Within a given tag value, the code may well just happen to work that way. But across different tag values it most likely will not. Thus all the attributes with tag '0' will maintain order, but any rule that needs segmentation will lose its position information relative to all others. Since huge rules are actually quite rare, I suspect such bugs will survive to be fielded. I propose, instead, that Avi's suggestion of reserving one bit of the tag field for segmentation and leaving the other 7 for grouping be adopted, and that the bit be called MORE, indicating that this attribute is not the last piece of the rule. (One could just as well name it EXT and have it set only in the attribute that extends the previous one. There are pros and cons either way.) -- Barney Wolff I never met a computer I didn't like. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Oct 2006 02:02:52 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for Review: RADIUS Filter Attribute Document Date: Tue, 17 Oct 2006 19:01:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The RADIUS Filter Attribute document has gone through another revision to address the filter continuation issue. Please review the current version and send comments to the WG list: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt Are the changes an improvement? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Oct 2006 21:16:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RADEXT - Requested session has been scheduled for IETF 67 Date: Mon, 16 Oct 2006 17:15:50 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4920@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT - Requested session has been scheduled for IETF 67 Thread-Index: Acbw9c1gGrszD1O9QMOkj43dnqdVlQAchzoA From: "Nelson, David" To: The RADEXT session at IETF-67 has been scheduled for: RADEXT Session 1 (2.5 hours) Tuesday, Morning Session I 0900-1130 Room Name: Harbor 1 ---------------------------------------------- Please respond to the chairs with requests for agenda slots, including the subject, the I-D, and requested time. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Oct 2006 11:25:42 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6F04C.8333E0D0" Subject: FW: I-D ACTION:draft-carpenter-extension-recs-00.txt Date: Sun, 15 Oct 2006 13:24:43 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-carpenter-extension-recs-00.txt Thread-Index: AcbuOCHdoM+VCZn7SmCqF960lBf9LACFEQhg From: "Romascanu, Dan \(Dan\)" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F04C.8333E0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I believe that radext participants may be interested in this document.=20 Dan =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, October 12, 2006 9:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-carpenter-extension-recs-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Design issues for protocol extensions Author(s) : B. Carpenter Filename : draft-carpenter-extension-recs-00.txt Pages : 15 Date : 2006-10-12 =09 This document discusses issues related to the extensibility of IETF protocols, with a focus on the architectural design considerations involved. Concrete case study examples are included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-extension-recs-00.tx t To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-carpenter-extension-recs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-carpenter-extension-recs-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C6F04C.8333E0D0 Content-Type: application/octet-stream; name="ATT138496.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT138496.TXT Content-Disposition: attachment; filename="ATT138496.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0xMC0xMjExMzkzOS5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jYXJwZW50ZXItZXh0ZW5z aW9uLXJlY3MtMDAudHh0DQo= ------_=_NextPart_001_01C6F04C.8333E0D0 Content-Type: application/octet-stream; name="draft-carpenter-extension-recs-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-carpenter-extension-recs-00.URL Content-Disposition: attachment; filename="draft-carpenter-extension-recs-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1jYXJwZW50ZXItZXh0ZW5zaW9uLXJlY3MtMDAudHh0DQo= ------_=_NextPart_001_01C6F04C.8333E0D0 Content-Type: text/plain; name="ATT138496.txt" Content-Transfer-Encoding: base64 Content-Description: ATT138496.txt Content-Disposition: attachment; filename="ATT138496.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C6F04C.8333E0D0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Oct 2006 00:12:45 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org cc: Subject: ISSUE: Table of attributes in RFC 4590 Message-Id: <20060926173118.04C6416D7C@mail.nitros9.org> Date: Tue, 26 Sep 2006 13:31:18 -0400 (EDT) Description of issue: The table of attributes in Section 5 of RFC 4590 lists "0-1", or "0+" for all of the Digest attributes in the Access-Request. This would seem to indicate that we can have Digest authentication where no Digest attributes exist in the Access-Request. Submitter name: Alan DeKok Submitter email address: aland@nitros9.org Date first submitted: Sept. 26, 2006 Reference: Document: RFC 4590 Comment type: Technical Priority: S Section: 5 Rationale/Explanation of issue: The body text, and examples in Section 6 appear to indicate that at least Digest-Method is required in every Access-Request. Yet in Section 5, the Table of Attributes indicates that no Digest attributes are required in an Access-Request packet. I first ran into this issue when I was looking at an implementation of RFC 4590, and wanted to enforce the requirement that the Message-Authenticator attribute must appear in every packet implementing Digest authentication. If the server sends an Access-Accept or Access-Challenge packet with Digest attributes, it is simple to determine that the Message-Authenticator must be included in the packet. However, for Access-Request, there appears to be no way to determine if the request is, in fact a request for Digest authentication, because there is no requirement that any Digest attributes exist in the Access-Request. Reading Section 1.3, the paragraph at the top of page 6 seems to indicate that a Digest-Method is always sent in an Access-Request. Other text in the document also indicates that the first Access-Request always contains a Digest-Method attribute. It may be that Digest-Method does NOT have to appear in Access-Request if the Access-Request is in response to an Access-Challenge, but this is not clear from the text. My recommendation is to make Digest-Method required in the Access-Request, which simplifies implementation. It also appears that this requirement is the intent in RFC 4590, because all of the examples have Digest-Method in every Access-Request. I also have noted that none of the Access-Challenges in the examples contain a State attribute, and the State attribute is not mentioned anywhere in RFC 4590. That indicates to me that the Access-Request in response to an Access-Challenge MUST contain sufficient information to finish the authentication process, and have the server return either Access-Accept or Access-Reject. The alternative is for the server to repeatedly challenge the client, which does not appear to be the intent. That says to me that the Access-Challenge MUST contain a State attribute, which is copied to the subsequent Access-Request. The server MUST respond with either an Access-Accept or Access-Reject to an Access-Request that contains a State attribute. The server MUST NOT respond with Access-Challenge to an Access-Request that contains a State attribute. I believe that may be another issue. Requested change: Update the Table of Attributes as follows: . | 1 | 0 | 0 | 0 | 108 | Digest-Method | . Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Oct 2006 23:26:53 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Cc: beckw@t-systems.com, david.kessens@nokia.com Bcc: Subject: RE: Serious error in RFC4590 Date: Sat, 23 Sep 2006 05:52:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed I agree that we need to get the IANA web pages corrected and also need to submit an errata to the RFC Editor. However, I'm concerned that even with these measures, there is the potential for confusion to linger. As I recall, the original RADIUS RFCs had to be re-issued to fix a port allocation problem. I'm wondering what the WG thinks we should do in this situation. >---------- Forwarded message ---------- >Date: Thu, 21 Sep 2006 09:21:55 +0200 >From: "Beck01, Wolfgang" >To: Alexander.Schrab@axis.com, baruch@kayote.com, dscreat@dscreat.com, > david@kayote.com, dwilli@cisco.com >Cc: dnelson@enterasys.com, aboba@internaut.com >Subject: AW: Serious error in RFC4590 > >Alexander > > > In table 2 the Digest-Nextnonce and Digest-Response-Auth are > > numbered 106 and 107. But furthur down they are numbered in > > reverse order. >This is ugly. The numbering is consistent in the main text >and in the attributes table. The exception is section 7, IANA >considerations. It's wrong in the IANA registry www.iana.org >as well. > >Not an excuse, but an explanation: the IANA section is inserted >at the end of the standardization process. It did not get the >same attention and review time as the rest of the text. > > > If you already know about this problem I am sorry for > > spamming you. But I feel it is important that this error > > doesn't sneek it's way into implementations... > >Hopefully, the implementors will stick to the text and to the >attribute table in section 5. > >I've cc'ed this mail to the chairs of the RADEXT WG. We should >correct the IANA registry entries and issue an errata. > >106 is Digest-Response-Auth >107 is Digest-Nextnonce > >Wolfgang > >-- >T-Systems >Next Generation IP Services and Systems >+49 6151 937 2863 >Am Kavalleriesand 3 >64295 Darmstadt >Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Oct 2006 08:59:47 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org cc: Subject: ISSUE: Table of attributes in RFC 4590 Message-Id: <20060926173118.04C6416D7C@mail.nitros9.org> Date: Tue, 26 Sep 2006 13:31:18 -0400 (EDT) Description of issue: The table of attributes in Section 5 of RFC 4590 lists "0-1", or "0+" for all of the Digest attributes in the Access-Request. This would seem to indicate that we can have Digest authentication where no Digest attributes exist in the Access-Request. Submitter name: Alan DeKok Submitter email address: aland@nitros9.org Date first submitted: Sept. 26, 2006 Reference: Document: RFC 4590 Comment type: Technical Priority: S Section: 5 Rationale/Explanation of issue: The body text, and examples in Section 6 appear to indicate that at least Digest-Method is required in every Access-Request. Yet in Section 5, the Table of Attributes indicates that no Digest attributes are required in an Access-Request packet. I first ran into this issue when I was looking at an implementation of RFC 4590, and wanted to enforce the requirement that the Message-Authenticator attribute must appear in every packet implementing Digest authentication. If the server sends an Access-Accept or Access-Challenge packet with Digest attributes, it is simple to determine that the Message-Authenticator must be included in the packet. However, for Access-Request, there appears to be no way to determine if the request is, in fact a request for Digest authentication, because there is no requirement that any Digest attributes exist in the Access-Request. Reading Section 1.3, the paragraph at the top of page 6 seems to indicate that a Digest-Method is always sent in an Access-Request. Other text in the document also indicates that the first Access-Request always contains a Digest-Method attribute. It may be that Digest-Method does NOT have to appear in Access-Request if the Access-Request is in response to an Access-Challenge, but this is not clear from the text. My recommendation is to make Digest-Method required in the Access-Request, which simplifies implementation. It also appears that this requirement is the intent in RFC 4590, because all of the examples have Digest-Method in every Access-Request. I also have noted that none of the Access-Challenges in the examples contain a State attribute, and the State attribute is not mentioned anywhere in RFC 4590. That indicates to me that the Access-Request in response to an Access-Challenge MUST contain sufficient information to finish the authentication process, and have the server return either Access-Accept or Access-Reject. The alternative is for the server to repeatedly challenge the client, which does not appear to be the intent. That says to me that the Access-Challenge MUST contain a State attribute, which is copied to the subsequent Access-Request. The server MUST respond with either an Access-Accept or Access-Reject to an Access-Request that contains a State attribute. The server MUST NOT respond with Access-Challenge to an Access-Request that contains a State attribute. I believe that may be another issue. Requested change: Update the Table of Attributes as follows: .. | 1 | 0 | 0 | 0 | 108 | Digest-Method | .. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Oct 2006 05:59:36 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Cc: beckw@t-systems.com, david.kessens@nokia.com Bcc: Subject: RE: Serious error in RFC4590 Date: Sat, 23 Sep 2006 05:52:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed I agree that we need to get the IANA web pages corrected and also need to submit an errata to the RFC Editor. However, I'm concerned that even with these measures, there is the potential for confusion to linger. As I recall, the original RADIUS RFCs had to be re-issued to fix a port allocation problem. I'm wondering what the WG thinks we should do in this situation. >---------- Forwarded message ---------- >Date: Thu, 21 Sep 2006 09:21:55 +0200 >From: "Beck01, Wolfgang" >To: Alexander.Schrab@axis.com, baruch@kayote.com, dscreat@dscreat.com, > david@kayote.com, dwilli@cisco.com >Cc: dnelson@enterasys.com, aboba@internaut.com >Subject: AW: Serious error in RFC4590 > >Alexander > > > In table 2 the Digest-Nextnonce and Digest-Response-Auth are > > numbered 106 and 107. But furthur down they are numbered in > > reverse order. >This is ugly. The numbering is consistent in the main text >and in the attributes table. The exception is section 7, IANA >considerations. It's wrong in the IANA registry www.iana.org >as well. > >Not an excuse, but an explanation: the IANA section is inserted >at the end of the standardization process. It did not get the >same attention and review time as the rest of the text. > > > If you already know about this problem I am sorry for > > spamming you. But I feel it is important that this error > > doesn't sneek it's way into implementations... > >Hopefully, the implementors will stick to the text and to the >attribute table in section 5. > >I've cc'ed this mail to the chairs of the RADEXT WG. We should >correct the IANA registry entries and issue an errata. > >106 is Digest-Response-Auth >107 is Digest-Nextnonce > >Wolfgang > >-- >T-Systems >Next Generation IP Services and Systems >+49 6151 937 2863 >Am Kavalleriesand 3 >64295 Darmstadt >Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Oct 2006 19:50:49 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-04.txt Message-Id: Date: Tue, 10 Oct 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Delegated-IPv6-Prefix Attribute Author(s) : J. Salowey, R. Droms Filename : draft-ietf-radext-delegated-prefix-04.txt Pages : 8 Date : 2006-10-10 This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-delegated-prefix-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-delegated-prefix-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-10132746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-delegated-prefix-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-delegated-prefix-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-10132746.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 06 Oct 2006 19:01:04 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E979.9C421BB5" Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt Date: Fri, 6 Oct 2006 14:59:54 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD358@exchtewks2.starentnetworks.com> Content-Transfer-Encoding: 7bit Thread-Topic: Review requested: draft-ietf-radext-delegated-prefix-03.txt thread-index: AcbpXPtY5HAxMh+IThKNTKodfLz3hAAGTVKw From: "Chowdhury, Kuntal" To: "Behcet Sarikaya" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E979.9C421BB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Friday, October 06, 2006 10:35 AM To: Chowdhury, Kuntal Cc: radiusext@ops.ietf.org Subject: Re: Review requested: draft-ietf-radext-delegated-prefix-03.txt =20 Hi Kuntal, Comments inline. =20 Regards, =20 --behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: radiusext@ops.ietf.org Sent: Thursday, October 5, 2006 11:23:33 PM Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt I don't know at what stage we are in with respect to this draft, but it seems that the draft lacks a description of the use case that it is trying to address. The introduction seems to be conveying very little about the motivation for this document: =20 " =20 The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an IPv6 prefix to be delegated to the user, for use in the user's network. =20 =20 " Comment: Delegated-IPv6-Prefix is NOT a RADIUS attribute that is defined in reference [1] i.e. RFC 2865. If it was, we would not need this document. =3D=3D> True. So I suggest the following fix: The Delegated-IPv6-Prefix is a new RADIUS [1] attribute that carries an ... " [KC>] Ok, but I still think referencing RFC 2865 in the above sentence is odd. A _new_ attribute cannot be in an RFC unless the RFC is revised. This is just an editorial nit, IMHO. =20 For example, the prefix in a Delegated-IPv6-Prefix attribute can be delegated to another node through DHCP Prefix Delegation [2]. " Comment: If prefix delegation by DHCP as described in RFC 3633 already exists, then why we need another mechanism? RFC 3633 has figure 1 which shows the prefix delegation scenario. I request that the authors clarify using this figure where the RADIUS transaction with this attribute applies. =3D=3D> I think you missed the point with this whole draft. =20 [KC>] Since you seem to have understood the point in the draft very well, why don't you help me understand it? In RFC 3633 there are several entities shown in fig 1, ISP, Aggregation Device (delegating router), CPE (requesting router), and Subscriber PC. So, we need to know how this RADIUS draft fits into this scenario. Where is the RADIUS Client? If it is the Aggregation Device why is it outsourcing the prefix management to a RADIUS server? What is the motivation for doing this? Is the motivation to avoid prefix provisioning in the Aggregation Device? Does the Aggregation Device have a NAS that performs user auth/authz. What is the user? Is it one of the Customers PC or is it the CPE (requesting router)?=20 =20 The text in this draft SHOULD clarify the use case. =20 -Kuntal =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, October 03, 2006 5:04 PM To: ' Behcet Sarikaya ' Cc: radiusext@ops.ietf.org Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt =20 In RADIUS/Diameter Accounting messages announce both the beginning and end of a session.=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@ yahoo .com]=20 Sent: Tuesday, October 03, 2006 2:05 PM To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Review requested: draft-ietf-radext-delegated-prefix-03.txt =20 Hello Bernard, I agree with your changes, please also add this typo too: The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are: ->The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are: Is session termination communicated with Accounting Request message in Radius/Diameter? =20 Thanks, =20 Behcet ----- Original Message ---- From: Bernard Aboba < bernard_aboba@hotmail.com > To: radiusext@ops.ietf.org Sent: Tuesday, October 3, 2006 3:21:42 PM Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt A new version of the Delegated Prefix attribute has been posted to the=20 archive: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-0 3.txt This document has already gone through IESG review, so it is one step away=20 from publication. Can people take a look at it? I found one typo, in Section 5: The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Framed-IPv6- 97 6.11.6 OctetString| M | P | | V | Y | Prefix | | | | | | Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix;=20 the AVP should be TBD instead of 97, and the Section Defined entry should be=20 deleted. One other quibble. In Section 1, it is stated: " The Framed-IPv6-Prefix attribute [4] is not designed to carry an IPv6 prefix to be used in the user's network, and therefore Framed-IPv6- Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." It strikes me that this statement is not necessarily accurate. For example,=20 if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix=20 attribute *could* be used to carry an IPv6 prefix to be used in the user's=20 network. However, if we are talking about a router, then this will not=20 work. So I think the sentence should be changed to: " The Framed-IPv6-Prefix attribute [4] is not designed to support=20 delegation of prefixes to be used in the user's network, and therefore Framed-IPv6-Prefix and=20 Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: =20 "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."=20 =20 ------_=_NextPart_001_01C6E979.9C421BB5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = Behcet Sarikaya = [mailto:behcetsarikaya@yahoo.com]
Sent: Friday, October 06, = 2006 10:35 AM
To: Chowdhury, Kuntal
Cc: = radiusext@ops.ietf.org
Subject: Re: Review = requested: draft-ietf-radext-delegated-prefix-03.txt

 

Hi Kuntal,

Comments inline.

 

Regards,

 

--behcet

----- Original = Message ----
From: "Chowdhury, Kuntal" = <kchowdhury@starentnetworks.com>
To: radiusext@ops.ietf.org
Sent: Thursday, October 5, 2006 11:23:33 PM
Subject: RE: Review requested: = draft-ietf-radext-delegated-prefix-03.txt

I don’t know at what stage we = are in with respect to this draft, but it seems that the draft lacks a = description of the use case that it is trying to address. The introduction seems to be conveying very little about the motivation for this = document:

 

“   =

The Delegated-IPv6-Prefix is a = RADIUS attribute [1] that carries an

   IPv6 prefix to be = delegated to the user, for use in the user's

   network.  =

 

“

=

Comment: Delegated-IPv6-Prefix is = NOT a RADIUS attribute that is defined in reference [1] i.e. RFC 2865. If it = was, we would not need this document.

=3D=3D> True. So I suggest =  the following fix:

The Delegated-IPv6-Prefix is a new = RADIUS [1] attribute that carries an ...

“

[KC>] Ok, but I still think referencing RFC 2865 = in the above sentence is odd. A _new_ attribute cannot be in = an RFC unless the RFC is revised. This is just an editorial nit, = IMHO.

 

For example, the prefix in a Delegated-IPv6-Prefix

   attribute can be = delegated to another node through DHCP Prefix

   Delegation = [2].

“

=

Comment: If prefix delegation by = DHCP as described in RFC 3633 already exists, then why we need another = mechanism? RFC 3633 has figure 1 which shows the prefix delegation scenario.  I = request that the authors clarify using this figure where the RADIUS transaction = with this attribute applies.

 =3D=3D> I think you missed = the point with this whole draft.

 

=

[KC>] Since you seem to have understood the point = in the draft very well, why don’t you help me understand it? In RFC 3633 = there are several entities shown in fig 1, ISP, Aggregation Device (delegating router), CPE (requesting router), and Subscriber PC.  So, we need = to know how this RADIUS draft fits into this scenario. Where is the RADIUS = Client? If it is the Aggregation Device why is it outsourcing the prefix management = to a RADIUS server? What is the motivation for doing this? Is the motivation = to avoid prefix provisioning in the Aggregation Device? Does the = Aggregation Device have a NAS that performs user auth/authz. What is the user? Is it = one of the Customers PC or is it the CPE (requesting router)? =

 

The text in this draft SHOULD clarify the use = case.

 

-Kuntal

=

 

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On Behalf Of Bernard Aboba
Sent: Tuesday, October = 03, 2006 5:04 PM
To: ' Behcet Sarikaya '
Cc: = radiusext@ops.ietf.org
Subject: RE: Review = requested: draft-ietf-radext-delegated-prefix-03.txt

 

In RADIUS/Diameter Accounting = messages announce both the beginning and end of a session. =

 

From: = Behcet Sarikaya [mailto:behcetsarikaya@ = yahoo .com]
Sent: Tuesday, October = 03, 2006 2:05 PM
To: Bernard Aboba
Cc: = radiusext@ops.ietf.org
Subject: Re: Review = requested: draft-ietf-radext-delegated-prefix-03.txt

 

Hello Bernard, I agree with your changes, please = also add this typo too:

The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:
->The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute = are:

Is session termination communicated with Accounting Request message in Radius/Diameter?

 

Thanks,

 

Behcet

----- Original = Message ----
From: Bernard Aboba < bernard_aboba@hotmail.com >
To: radiusext@ops.ietf.org
Sent: Tuesday, October 3, 2006 3:21:42 PM
Subject: Review requested: = draft-ietf-radext-delegated-prefix-03.txt

A new version of the Delegated Prefix attribute has been posted = to the
archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-d= elegated-prefix-03.txt

This document has already gone through IESG review, so it is one step = away
from publication.

Can people take a look at it?

I found one typo, in Section 5:

   The AVP flag rules [5] for the Delegate-IPv6-Prefix = attribute are:

            &= nbsp;           &n= bsp;           &nb= sp;       +---------------------+
            &= nbsp;           &n= bsp;           &nb= sp;       |    AVP= Flag rules   |
            &= nbsp;           &n= bsp;           &nb= sp;       |----+-----+----+-----|----+=
            &= nbsp;      AVP  Section        &nb= sp;    |    |     |SHLD| MUST|    |
   Attribute Name  Code Defined  Value = Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
=    Framed-IPv6-      97  6.11.6 = ; OctetString| M  |  P  |    | &n= bsp;V  | Y  |
     Prefix           &= nbsp;           &n= bsp;         |    |     = |    |     |    |


Here the attribute should be Delegated-IPv6-Prefix, not = Framed-IPv6-Prefix;
the AVP should be TBD instead of 97, and the Section Defined entry = should be
deleted.

One other quibble.   In Section 1, it is stated:

"   The Framed-IPv6-Prefix attribute [4] is not designed = to carry an IPv6
   prefix to be used in the user's network, and therefore Framed-IPv6-
   Prefix and Delegated-IPv6-Prefix attributes may be included = in the
   same RADIUS packet."

It strikes me that this statement is not necessarily = accurate.  For example,
if a bridge device connected to a NAS, then in fact the = Framed-IPv6-Prefix
attribute *could* be used to carry an IPv6 prefix to be used in the = user's
network.  However, if we are talking about a router, then this = will not
work.  So I think the sentence should be changed to:

"  The Framed-IPv6-Prefix attribute [4] is not designed = to support
delegation of prefixes to
   be used in the user's network, and therefore = Framed-IPv6-Prefix and
Delegated-IPv6-Prefix
   attributes may be included in the same RADIUS = packet."



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

 

"This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to create or = change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action = in reliance upon this e-mail and its attachments by persons or entities = other than the intended recipient is prohibited. If you are not the intended = recipient, please notify the sender immediately -- by replying to this message or = by sending an email to postmaster@starentnetworks.com -- and destroy all = copies of this message and any attachments without reading or disclosing their = contents. Thank you."

 

------_=_NextPart_001_01C6E979.9C421BB5-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 06 Oct 2006 04:24:30 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E8FF.2F4ECD90" Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt Date: Fri, 6 Oct 2006 00:23:33 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD34A@exchtewks2.starentnetworks.com> Content-Transfer-Encoding: 7bit Thread-Topic: Review requested: draft-ietf-radext-delegated-prefix-03.txt thread-index: AcbnL6LzUgfo47wGQEaJ3WJoUDyY2AACB7mgAHF3rzA= From: "Chowdhury, Kuntal" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E8FF.2F4ECD90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I don't know at what stage we are in with respect to this draft, but it seems that the draft lacks a description of the use case that it is trying to address. The introduction seems to be conveying very little about the motivation for this document: =20 " =20 The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an IPv6 prefix to be delegated to the user, for use in the user's network. =20 =20 " Comment: Delegated-IPv6-Prefix is NOT a RADIUS attribute that is defined in reference [1] i.e. RFC 2865. If it was, we would not need this document. =20 " For example, the prefix in a Delegated-IPv6-Prefix attribute can be delegated to another node through DHCP Prefix Delegation [2]. " Comment: If prefix delegation by DHCP as described in RFC 3633 already exists, then why we need another mechanism? RFC 3633 has figure 1 which shows the prefix delegation scenario. I request that the authors clarify using this figure where the RADIUS transaction with this attribute applies. =20 -Kuntal =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, October 03, 2006 5:04 PM To: 'Behcet Sarikaya' Cc: radiusext@ops.ietf.org Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt =20 In RADIUS/Diameter Accounting messages announce both the beginning and end of a session.=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Tuesday, October 03, 2006 2:05 PM To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Review requested: draft-ietf-radext-delegated-prefix-03.txt =20 Hello Bernard, I agree with your changes, please also add this typo too: The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are: ->The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are: Is session termination communicated with Accounting Request message in Radius/Diameter? =20 Thanks, =20 Behcet ----- Original Message ---- From: Bernard Aboba To: radiusext@ops.ietf.org Sent: Tuesday, October 3, 2006 3:21:42 PM Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt A new version of the Delegated Prefix attribute has been posted to the=20 archive: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-0 3.txt This document has already gone through IESG review, so it is one step away=20 from publication. Can people take a look at it? I found one typo, in Section 5: The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Framed-IPv6- 97 6.11.6 OctetString| M | P | | V | Y | Prefix | | | | | | Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix;=20 the AVP should be TBD instead of 97, and the Section Defined entry should be=20 deleted. One other quibble. In Section 1, it is stated: " The Framed-IPv6-Prefix attribute [4] is not designed to carry an IPv6 prefix to be used in the user's network, and therefore Framed-IPv6- Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." It strikes me that this statement is not necessarily accurate. For example,=20 if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix=20 attribute *could* be used to carry an IPv6 prefix to be used in the user's=20 network. However, if we are talking about a router, then this will not=20 work. So I think the sentence should be changed to: " The Framed-IPv6-Prefix attribute [4] is not designed to support=20 delegation of prefixes to be used in the user's network, and therefore Framed-IPv6-Prefix and=20 Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: =20 "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C6E8FF.2F4ECD90 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I don’t know at what stage we = are in with respect to this draft, but it seems that the draft lacks a = description of the use case that it is trying to address. The introduction seems to be conveying very little about the motivation for this = document:

 

“   =

The Delegated-IPv6-Prefix is a = RADIUS attribute [1] that carries an

   IPv6 prefix to be = delegated to the user, for use in the user's

   network.  =

 

“

=

Comment: Delegated-IPv6-Prefix is = NOT a RADIUS attribute that is defined in reference [1] i.e. RFC 2865. If it = was, we would not need this document.

 

“

=

For example, the prefix in a Delegated-IPv6-Prefix

   attribute can be = delegated to another node through DHCP Prefix

   Delegation = [2].

“

=

Comment: If prefix delegation by = DHCP as described in RFC 3633 already exists, then why we need another = mechanism? RFC 3633 has figure 1 which shows the prefix delegation scenario.  I = request that the authors clarify using this figure where the RADIUS transaction = with this attribute applies.

 

-Kuntal

=

 

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On Behalf Of Bernard Aboba
Sent: Tuesday, October = 03, 2006 5:04 PM
To: 'Behcet Sarikaya'
Cc: = radiusext@ops.ietf.org
Subject: RE: Review = requested: draft-ietf-radext-delegated-prefix-03.txt

 

In RADIUS/Diameter Accounting = messages announce both the beginning and end of a session. =

 

From: = Behcet Sarikaya = [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, October = 03, 2006 2:05 PM
To: Bernard Aboba
Cc: = radiusext@ops.ietf.org
Subject: Re: Review = requested: draft-ietf-radext-delegated-prefix-03.txt

 

Hello Bernard, I agree with your changes, please = also add this typo too:

The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:
->The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute = are:

Is session termination communicated with Accounting Request message in Radius/Diameter?

 

Thanks,

 

Behcet

----- Original = Message ----
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: radiusext@ops.ietf.org
Sent: Tuesday, October 3, 2006 3:21:42 PM
Subject: Review requested: = draft-ietf-radext-delegated-prefix-03.txt

A new version of the Delegated Prefix attribute has been posted = to the
archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-d= elegated-prefix-03.txt

This document has already gone through IESG review, so it is one step = away
from publication.

Can people take a look at it?

I found one typo, in Section 5:

   The AVP flag rules [5] for the Delegate-IPv6-Prefix = attribute are:

            &= nbsp;           &n= bsp;           &nb= sp;       +---------------------+
            &= nbsp;           &n= bsp;           &nb= sp;       |    AVP= Flag rules   |
            &= nbsp;           &n= bsp;           &nb= sp;       |----+-----+----+-----|----+=
            &= nbsp;      AVP  Section        &nb= sp;    |    |     |SHLD| MUST|    |
   Attribute Name  Code Defined  Value = Type |MUST| MAY | NOT|  NOT|Encr|
   = -----------------------------------------|----+-----+----+-----|----|
=    Framed-IPv6-      97  6.11.6 = ; OctetString| M  |  P  |    | &n= bsp;V  | Y  |
     Prefix           &= nbsp;           &n= bsp;         |    |     |    |     = |    |


Here the attribute should be Delegated-IPv6-Prefix, not = Framed-IPv6-Prefix;
the AVP should be TBD instead of 97, and the Section Defined entry = should be
deleted.

One other quibble.   In Section 1, it is stated:

"   The Framed-IPv6-Prefix attribute [4] is not designed = to carry an IPv6
   prefix to be used in the user's network, and therefore Framed-IPv6-
   Prefix and Delegated-IPv6-Prefix attributes may be included = in the
   same RADIUS packet."

It strikes me that this statement is not necessarily = accurate.  For example,
if a bridge device connected to a NAS, then in fact the = Framed-IPv6-Prefix
attribute *could* be used to carry an IPv6 prefix to be used in the = user's
network.  However, if we are talking about a router, then this = will not
work.  So I think the sentence should be changed to:

"  The Framed-IPv6-Prefix attribute [4] is not designed = to support
delegation of prefixes to
   be used in the user's network, and therefore = Framed-IPv6-Prefix and
Delegated-IPv6-Prefix
   attributes may be included in the same RADIUS = packet."



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

 

"This email message and any attachments are confidential information = of Starent Networks, Corp. The information transmitted may not be used = to create or change any contractual obligations of Starent Networks, = Corp. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this e-mail and its attachments by = persons or entities other than the intended recipient is prohibited. If = you are not the intended recipient, please notify the sender immediately = -- by replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C6E8FF.2F4ECD90-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 18:22:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting Date: Wed, 4 Oct 2006 14:22:04 -0400 Message-ID: From: "Avi Lior" To: "Barney Wolff" Cc: Okay Barney. So at one hand having 61 rules is definitely limiting -- that is you see an application that would require more then 61 rules. Therefore regardless of how we handle fragmentation, by the same token 16 rules will not sufficie either and we need another solution whereby we can send on the order of 60 rules whether they fragment or not. But realistically, perhaps we need in the order of 10 rules where some may overflow - or something like that. With respect to apriori knowledge of RADIUS client knowing about fragementation, I agree that it is an advantage but only marginally. The current scheme has issues as I pointed out in the first email. BTW you can have grouping and fragmentation if you use the approach whereby you use the most significant bit of the TAG as fragmentation bit. The rest of the bits of the tag are used for grouping. If you don't have fragmentation the the MSB is clear. If you have fragmentation the MSB is set. If you don't have grouping the 7 LSBs are zero, if you do have grouping then the 7LSBs indicate the group id. So we can have our cake an eat it too!!! =20 > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=20 > Sent: Wednesday, October 04, 2006 1:35 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Proposed Resolution to Issue 198: Attribute=20 > Concatenation/Splitting >=20 > On Wed, Oct 04, 2006 at 01:00:10PM -0400, Avi Lior wrote: > >=20 > > Do you think that allowing 62 NAS Filter rules per message=20 > is limiting? >=20 > Yes, definitely. >=20 > > If yes then I suggest that even with the existing text we have an=20 > > unreasonable limitation since I can only support 61 NAS=20 > Filter Rules=20 > > per message that overflow. >=20 > Well, no. 4096/255 is about 16. >=20 > > > Why would we want to hide from the receiver whether a=20 > rule is going=20 > > > to be segmented? > >=20 > > We are not. The receiver can easily detect that a rule is a=20 > > continuation. >=20 > Only when it sees the continuation, if every rule needs a unique tag. > It would be useful, potentially, to know when seeing the=20 > first part of the rule that there is more to come. >=20 > > Note that both approaches (or all approaches) presented so=20 > far have a=20 > > flaw in that they will prevent us from grouping=20 > NAS-Filter-Rules into=20 > > groups of rules. This could be harmful in the future. We=20 > arleady see=20 > > evidence that a filter-rule can be used for several=20 > purposes. We wont=20 > > be able to express these in RADIUS. >=20 > There was an attempt to provide such power for RADIUS, by=20 > adopting the Diameter attribute header. It did not meet with=20 > group approval. Of course I would prefer to see a general=20 > mechanism for handling both grouping and segmentation, rather=20 > than have to debate it over again for every attribute that=20 > might need such facilities. >=20 > --=20 > Barney Wolff I never met a computer I didn't like. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 17:53:06 +0000 Date: Wed, 4 Oct 2006 13:51:38 -0400 From: Barney Wolff To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting Message-ID: <20061004175138.GB97764@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) On Wed, Oct 04, 2006 at 10:15:01AM -0700, Bernard Aboba wrote: > >Why would we want to limit the number of possible rules? > > I don't think we want to do that. As a Glen has pointed out, there are > deployments in which a very large number of rules are being used. > > >Why would we want to hide from the receiver whether a rule is going > >to be segmented? > > It's probably best not to hide that from the receiver. > > > If TAG is non-zero, the next NAS-Filter-Rule attribute is a > > continuation of this one. If TAG is zero, this attribute is > > the last or only segment of this rule. > > So if a continued filter is followed by a non-continued one, then we have > two attributes with zero (0) tag fields? Yes. What's wrong with that? > Why not just say that the tag field needs to be different between adjacent > filter rules, with the exception of a zero tag that represents a > non-continued filter rule? A rule may potentially need more than two segments. The receiver might like to be able to predict whether a rule is 504 octets or >=505 before seeing the next attribute. Once we're using the Tag only for continuation, and not for grouping, it really is a 1-bit field, and different nonzero values convey no meaning. If we want grouping as well, Avi's idea of using the hi-bit of the Tag for continuation is a good one, at the cost of making it harder to enter the value by typing ASCII. Perhaps we should use the low-bit for continuation, leaving the high 7 for grouping. -- Barney Wolff I never met a computer I didn't like. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 17:35:15 +0000 Date: Wed, 4 Oct 2006 13:34:44 -0400 From: Barney Wolff To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting Message-ID: <20061004173444.GA97764@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) On Wed, Oct 04, 2006 at 01:00:10PM -0400, Avi Lior wrote: > > Do you think that allowing 62 NAS Filter rules per message is limiting? Yes, definitely. > If yes then I suggest that even with the existing text we have an > unreasonable limitation since I can only support 61 NAS Filter Rules per > message that overflow. Well, no. 4096/255 is about 16. > > Why would we want to hide from the receiver whether a rule is > > going to be segmented? > > We are not. The receiver can easily detect that a rule is a > continuation. Only when it sees the continuation, if every rule needs a unique tag. It would be useful, potentially, to know when seeing the first part of the rule that there is more to come. > Note that both approaches (or all approaches) presented so far have a > flaw in that they will prevent us from grouping NAS-Filter-Rules into > groups of rules. This could be harmful in the future. We arleady see > evidence that a filter-rule can be used for several purposes. We wont > be able to express these in RADIUS. There was an attempt to provide such power for RADIUS, by adopting the Diameter attribute header. It did not meet with group approval. Of course I would prefer to see a general mechanism for handling both grouping and segmentation, rather than have to debate it over again for every attribute that might need such facilities. -- Barney Wolff I never met a computer I didn't like. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 17:30:47 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Resolution to Issue 198: Another attempt Date: Wed, 04 Oct 2006 10:30:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed So as to lessen restrictions on the number of potential rules, here is another attempt at text relating to the Tag field. Is this better? " Tag The Tag field is used to identify the filter rule that is represented; the length of the Tag field is one octet and it MUST always be present. Where a single filter rule is less than or equal to 252 octets in length, it MUST be encoded with a Tag field value of zero (0) and MUST NOT be split between multiple NAS-Filter-Rule attributes. On receipt, attributes with a Tag field value of zero (0) MUST NOT be concatenated to form a single filter rule. Where a single filter rule exceeds 252 octets in length, the rule MUST be encoded across multiple NAS-Filter-Rule attributes, each with the same Tag value which MUST be in the range 0x01 - 0x3F. NAS-Filter-Rule attributes comprising a single filter rule MUST be sent consecutively, without intervening attributes with another Tag field value. The Tag field value of 0xFF is reserved and NAS-Filter-Rule attributes containing this Tag field value should be ignored upon receipt. Adjacent filter rules exceeding 252 octets in length MUST be encoded with different non-zero Tag field values; however, the Tag field value used for a given filter rule need not be unique within the entire RADIUS packet. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 17:17:58 +0000 Message-ID: From: "Bernard Aboba" To: barney@databus.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting Date: Wed, 04 Oct 2006 10:15:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Why would we want to limit the number of possible rules? I don't think we want to do that. As a Glen has pointed out, there are deployments in which a very large number of rules are being used. >Why would we want to hide from the receiver whether a rule is going >to be segmented? It's probably best not to hide that from the receiver. > If TAG is non-zero, the next NAS-Filter-Rule attribute is a > continuation of this one. If TAG is zero, this attribute is > the last or only segment of this rule. So if a continued filter is followed by a non-continued one, then we have two attributes with zero (0) tag fields? Why not just say that the tag field needs to be different between adjacent filter rules, with the exception of a zero tag that represents a non-continued filter rule? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 17:00:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting Date: Wed, 4 Oct 2006 13:00:10 -0400 Message-ID: From: "Avi Lior" To: "Barney Wolff" Cc: Barney, Do you think that allowing 62 NAS Filter rules per message is limiting? If yes then I suggest that even with the existing text we have an unreasonable limitation since I can only support 61 NAS Filter Rules per message that overflow. I just think that allowing for 62 per packet is more then enough. > Why would we want to hide from the receiver whether a rule is=20 > going to be segmented? We are not. The receiver can easily detect that a rule is a continuation. If you want we can use the MSB to indicate whether an attribute is continuation or not. This is what I am proposing for Extended RADIUS. > The "TAG thing" is very complex because we're using an 8-bit=20 > field to convey 1 bit of meaning. We could just as well say: >=20 > If TAG is non-zero, the next NAS-Filter-Rule attribute is a > continuation of this one. If TAG is zero, this attribute is > the last or only segment of this rule. >=20 > The attempt to reuse the existing tag mechanism has failed. =20 > It's time to move on. So I agree with that as well. This is another issue. Note that both approaches (or all approaches) presented so far have a flaw in that they will prevent us from grouping NAS-Filter-Rules into groups of rules. This could be harmful in the future. We arleady see evidence that a filter-rule can be used for several purposes. We wont be able to express these in RADIUS. > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=20 > Sent: Wednesday, October 04, 2006 12:38 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Proposed Resolution to Issue 198: Attribute=20 > Concatenation/Splitting >=20 > On Wed, Oct 04, 2006 at 12:22:41PM -0400, Avi Lior wrote: > >=20 > > This TAG thing is very complex. We can get rid of the '0' tag=20 > > requirement by saying that every NAS Filter Rule MUST have a unique=20 > > non-zero TAG value in the range of 0x01 to 0x3F. > > If an NAS filter rule attribute needs to be fragmeneted (length is=20 > > greater then 252) then the fragments is placed in a subsequent=20 > > NAS-Filter-Rule attribute and the same TAG value is used. >=20 > Why would we want to limit the number of possible rules? > Why would we want to hide from the receiver whether a rule is=20 > going to be segmented? >=20 > The "TAG thing" is very complex because we're using an 8-bit=20 > field to convey 1 bit of meaning. We could just as well say: >=20 > If TAG is non-zero, the next NAS-Filter-Rule attribute is a > continuation of this one. If TAG is zero, this attribute is > the last or only segment of this rule. >=20 > The attempt to reuse the existing tag mechanism has failed. =20 > It's time to move on. >=20 > --=20 > Barney Wolff I never met a computer I didn't like. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 16:38:21 +0000 Date: Wed, 4 Oct 2006 12:37:50 -0400 From: Barney Wolff To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting Message-ID: <20061004163750.GA52138@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) On Wed, Oct 04, 2006 at 12:22:41PM -0400, Avi Lior wrote: > > This TAG thing is very complex. We can get rid of the '0' tag > requirement by saying that every NAS Filter Rule MUST have a unique > non-zero TAG value in the range of 0x01 to 0x3F. > If an NAS filter rule attribute needs to be fragmeneted (length is > greater then 252) then the fragments is placed in a subsequent > NAS-Filter-Rule attribute and the same TAG value is used. Why would we want to limit the number of possible rules? Why would we want to hide from the receiver whether a rule is going to be segmented? The "TAG thing" is very complex because we're using an 8-bit field to convey 1 bit of meaning. We could just as well say: If TAG is non-zero, the next NAS-Filter-Rule attribute is a continuation of this one. If TAG is zero, this attribute is the last or only segment of this rule. The attempt to reuse the existing tag mechanism has failed. It's time to move on. -- Barney Wolff I never met a computer I didn't like. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 04 Oct 2006 16:24:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting Date: Wed, 4 Oct 2006 12:22:41 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , Cc: Bernard and all, This TAG thing is very complex. We can get rid of the '0' tag requirement by saying that every NAS Filter Rule MUST have a unique non-zero TAG value in the range of 0x01 to 0x3F. If an NAS filter rule attribute needs to be fragmeneted (length is greater then 252) then the fragments is placed in a subsequent NAS-Filter-Rule attribute and the same TAG value is used.=20 Anyway...here are some comments on the proposed text... See inline... > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, September 29, 2006 4:30 PM > To: barney@databus.com > Cc: radiusext@ops.ietf.org > Subject: Re: Proposed Resolution to Issue 198: Attribute=20 > Concatenation/Splitting >=20 > How about this? >=20 > Tag >=20 > The Tag field is used to identify the filter rule that is > represented;=20 The tag field is not identifying the filter rule because filter rules that are not fragmented will have a tag of '0'. My proposal above makes the TAG identify the filter rule uniquely. > the length of the Tag field is one octet=20 > and it MUST > always be present. The Tag field value MUST be in the range > 0x01-0x3F; NAS-Filter-Rule attributes with a Tag field value of > 0x00 are ignored upon receipt. >=20 > Where a single filter rule is less than or equal to 252=20 > octets in > length, it MUST be encoded with a tag value of '0'=20 > (0x30) and MUST > NOT be split between multiple NAS-Filter-Rule=20 > attributes. Where a > single filter rule is split into multiple NAS-Filter-Rule > attributes, the attributes SHOULD be sent consecutively, without > intervening attributes with another Tag field value. =20 I think you want to say: "the attributes MUST be sent consecutively, without intervening NAS-Filter-Rule attributes with a different Tag field value." RADIUS already covers in order delivery. Yes the above statement does allow for a RADIUS server to insert other attributes between two NAS-Filter-Rules. And yes receivers have to cope with that. However that is allowed behavior of RADIUS and we must not change that even with a SHOULD. > On receipt, > attributes with a Tag value of '0' (0x30) MUST NOT be=20 > concatenated > to form a single filter rule. >=20 > Where a single filter rule exceeds 252 octets in=20 > length, the rule > MUST be encoded across multiple NAS-Filter-Rule attributes, each > with the same Tag value which MUST NOT be '0' (0x30). =20 > Tag values > MUST be unique for each filter rule present in a RADIUS packet > with the exception of a Tag value of '0' (0x30), which=20 > may be used > in multiple attributes, each describing a single filter rule. >=20 >=20 > >From: Barney Wolff > >To: Bernard Aboba > >CC: radiusext@ops.ietf.org > >Subject: Re: Proposed Resolution to Issue 198: Attribute=20 > >Concatenation/Splitting > >Date: Fri, 29 Sep 2006 14:57:30 -0400 > > > >On Thu, Sep 28, 2006 at 11:27:23PM -0700, Bernard Aboba wrote: > > > Tag > > > > > > The Tag field is one octet, and MUST always be=20 > present. It is > > > used to identify the filter rule that is=20 > represented. Where a > > > single filter rule exceeds 253 octets in length, the=20 > rule MUST be > > > encoded across multiple NAS-Filter-Rule attributes,=20 > each with the > > > same Tag value; Tag values MUST be unique for each=20 > filter rule > > > present in a RADIUS packet with the exception of a=20 > Tag value of > > > '0' (0x30). The value of '0' (0x30) in the Tag=20 > field indicates > > > that the attribute contains a filter rule that does=20 > not exceed 253 > > > octets in length; as a result attributes with a Tag=20 > value of 0x30 > > > MUST NOT be concatenated, and one or more=20 > Filter-Rule attributes > > > with a tag value of 0x30 may be included in a single RADIUS > > > packet, each describing a single filter rule. > > > >May I suggest that NAS-Filter-Rule attributes with different=20 > tag values=20 > >MUST NOT appear between the segments into which a long rule is split? > >There is no benefit to the sender to allowing anything else, and=20 > >considerable nuisance to the receiver. > > > >Also, I suggest that a rule which is not split MUST have tag=20 > value '0'. > >Again, there is no value to the sender for anything else,=20 > and this way=20 > >the receiver can know whether a rule is going to be=20 > extended. Perhaps=20 > >the language implying that a rule <252 octets MUST NOT be=20 > split should=20 > >be made more explicit, too. > > > >As an aside, it is a general misfeature of RADIUS that senders are=20 > >allowed to do things, such as random ordering of attributes,=20 > that have=20 > >little value for the sender but cause hardship for the receiver. We=20 > >are all so used to this nuisance that we hardly perceive it as such. > > > >-- > >Barney Wolff I never met a computer I didn't like. > > > >-- > >to unsubscribe send a message to radiusext-request@ops.ietf.org with=20 > >the word 'unsubscribe' in a single line as the message text body. > >archive: >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Oct 2006 22:04:59 +0000 Message-ID: From: "Bernard Aboba" To: "'Behcet Sarikaya'" Cc: Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt Date: Tue, 3 Oct 2006 15:04:17 -0700 Message-ID: <000801c6e737$decc5b30$278a3b9d@ntdev.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C6E6FD.3293A8D0" Thread-Index: AcbnL6LzUgfo47wGQEaJ3WJoUDyY2AACB7mg This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C6E6FD.3293A8D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In RADIUS/Diameter Accounting messages announce both the beginning and end of a session. _____ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Tuesday, October 03, 2006 2:05 PM To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Review requested: draft-ietf-radext-delegated-prefix-03.txt Hello Bernard, I agree with your changes, please also add this typo too: The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are: ->The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are: Is session termination communicated with Accounting Request message in Radius/Diameter? Thanks, Behcet ----- Original Message ---- From: Bernard Aboba To: radiusext@ops.ietf.org Sent: Tuesday, October 3, 2006 3:21:42 PM Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt A new version of the Delegated Prefix attribute has been posted to the archive: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.tx t This document has already gone through IESG review, so it is one step away from publication. Can people take a look at it? I found one typo, in Section 5: The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Framed-IPv6- 97 6.11.6 OctetString| M | P | | V | Y | Prefix | | | | | | Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix; the AVP should be TBD instead of 97, and the Section Defined entry should be deleted. One other quibble. In Section 1, it is stated: " The Framed-IPv6-Prefix attribute [4] is not designed to carry an IPv6 prefix to be used in the user's network, and therefore Framed-IPv6- Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." It strikes me that this statement is not necessarily accurate. For example, if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix attribute *could* be used to carry an IPv6 prefix to be used in the user's network. However, if we are talking about a router, then this will not work. So I think the sentence should be changed to: " The Framed-IPv6-Prefix attribute [4] is not designed to support delegation of prefixes to be used in the user's network, and therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ------=_NextPart_000_0009_01C6E6FD.3293A8D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In RADIUS/Diameter Accounting = messages announce both the beginning and end of a session. =

 

From: = Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, October = 03, 2006 2:05 PM
To: Bernard Aboba
Cc: = radiusext@ops.ietf.org
Subject: Re: Review = requested: draft-ietf-radext-delegated-prefix-03.txt

 

Hello Bernard, I agree with your changes, please = also add this typo too:

The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:
->The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute = are:

Is session termination communicated with Accounting Request message in Radius/Diameter?

 

Thanks,

 

Behcet

----- Original = Message ----
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: radiusext@ops.ietf.org
Sent: Tuesday, October 3, 2006 3:21:42 PM
Subject: Review requested: = draft-ietf-radext-delegated-prefix-03.txt

A new version of the Delegated Prefix attribute has been posted = to the
archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-d= elegated-prefix-03.txt

This document has already gone through IESG review, so it is one step = away
from publication.

Can people take a look at it?

I found one typo, in Section 5:

   The AVP flag rules [5] for the Delegate-IPv6-Prefix = attribute are:

            &= nbsp;           &n= bsp;           &nb= sp;       +---------------------+
            &= nbsp;           &n= bsp;           &nb= sp;       |    AVP= Flag rules   |
            &= nbsp;           &n= bsp;           &nb= sp;       |----+-----+----+-----|----+=
            &= nbsp;      AVP  Section        &nb= sp;    |    |     |SHLD| = MUST|    |
   Attribute Name  Code Defined  Value = Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
=    Framed-IPv6-      97  6.11.6 = ; OctetString| M  |  P  |    | &n= bsp;V  | Y  |
     Prefix           &= nbsp;           &n= bsp;         |    |     |    |     = |    |


Here the attribute should be Delegated-IPv6-Prefix, not = Framed-IPv6-Prefix;
the AVP should be TBD instead of 97, and the Section Defined entry = should be
deleted.

One other quibble.   In Section 1, it is stated:

"   The Framed-IPv6-Prefix attribute [4] is not designed = to carry an IPv6
   prefix to be used in the user's network, and therefore Framed-IPv6-
   Prefix and Delegated-IPv6-Prefix attributes may be included = in the
   same RADIUS packet."

It strikes me that this statement is not necessarily = accurate.  For example,
if a bridge device connected to a NAS, then in fact the = Framed-IPv6-Prefix
attribute *could* be used to carry an IPv6 prefix to be used in the = user's
network.  However, if we are talking about a router, then this = will not
work.  So I think the sentence should be changed to:

"  The Framed-IPv6-Prefix attribute [4] is not designed = to support
delegation of prefixes to
   be used in the user's network, and therefore = Framed-IPv6-Prefix and
Delegated-IPv6-Prefix
   attributes may be included in the same RADIUS = packet."



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

 

------=_NextPart_000_0009_01C6E6FD.3293A8D0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Oct 2006 20:22:03 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt Date: Tue, 03 Oct 2006 13:21:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed A new version of the Delegated Prefix attribute has been posted to the archive: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt This document has already gone through IESG review, so it is one step away from publication. Can people take a look at it? I found one typo, in Section 5: The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Framed-IPv6- 97 6.11.6 OctetString| M | P | | V | Y | Prefix | | | | | | Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix; the AVP should be TBD instead of 97, and the Section Defined entry should be deleted. One other quibble. In Section 1, it is stated: " The Framed-IPv6-Prefix attribute [4] is not designed to carry an IPv6 prefix to be used in the user's network, and therefore Framed-IPv6- Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." It strikes me that this statement is not necessarily accurate. For example, if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix attribute *could* be used to carry an IPv6 prefix to be used in the user's network. However, if we are talking about a router, then this will not work. So I think the sentence should be changed to: " The Framed-IPv6-Prefix attribute [4] is not designed to support delegation of prefixes to be used in the user's network, and therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Oct 2006 20:15:32 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Review requested: draft-ietf-radext-filter-02.txt Date: Tue, 03 Oct 2006 13:14:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed A new version has been posted to the archive: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt Does this version address the open issues (198 & 202)? Are there any other issues/problems with it? 3GPP asked out the status of it in the last IETF/3GPP liaison conference call. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 02 Oct 2006 14:50:38 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-filter-02.txt Message-Id: Date: Mon, 02 Oct 2006 10:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Filter Rule Attribute Author(s) : P. Congdon Filename : draft-ietf-radext-filter-02.txt Pages : 10 Date : 2006-10-2 This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS), equivalent to the Diameter NAS-Filter-Rule AVP described in RFC 4005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-filter-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-filter-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-2093813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-filter-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-filter-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-2093813.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: