Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 29 Mar 2007 14:50:54 +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-rfc3576bis-03.txt Message-Id: Date: Thu, 29 Mar 2007 10: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 : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Author(s) : M. Chiba, et al. Filename : draft-ietf-radext-rfc3576bis-03.txt Pages : 34 Date : 2007-3-29 This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-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-rfc3576bis-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-rfc3576bis-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: <2007-3-29082436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-rfc3576bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-rfc3576bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-29082436.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, 29 Mar 2007 01:08:48 +0000 Message-ID: <460B118B.9000603@nitros9.org> Date: Thu, 29 Mar 2007 02:08:27 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for review of draft-ietf-mip4-radius-requirements-01.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > We have received a request from the chairs of the MIPv4 WG for review of > the following document: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements-01.txt > > > Any volunteers to do the review? I can help. 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, 29 Mar 2007 00:48:38 +0000 Message-ID: <460B0CCE.6000405@nitros9.org> Date: Thu, 29 Mar 2007 01:48:14 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: radext mailing list Subject: New Issue: review of of draft-lior-radius-attribute-type-extension-01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Review of the document Submitter name: Alan DeKok Submitter email address: aland@nitros9.org Date first submitted: March 28, 2007 Reference: Document: Extended attributes Comment type: E Priority: S Section: Many Rationale/Explanation of issue: Section 1.1: Should to be completed, as is noted in the document. I suggest using the usual NAS, RADIUS server, and proxy server from the other drafts and/or RFC's. I don't think much more is necessary. Section 2: ... In the real world, certain vendors have grabbed attribute type codes that they shouldn't have. ... I suggest "certain vendors have not followed the recommended practice to obtain an IANA allocation, and have not used VSA's." I also suggest adding stronger comments about this. e.g. "We re-iterate that vendors MUST NOT allocate attributes out of the RFC attribute space. Those attributes can only be allocated by IANA. Vendors performing such allocations cause inter-operability problems, heart-aches, and great gnashing of teeth". Or something like that. When told, some vendors fix their software, some don't understand what the problem is, and some don't care. Section 2: ... Therefore, the proposed scheme NUST provide a mechanism to group attributes. ... Typo "MUST". Section 2: ... In recent years, attribute sizes are threatening the limit of 253 octets. ... "threatening" sounds harsh. Maybe "pushing the limits of the current RADIUS attributes." Section 3: ... We allocate RADIUS the Vendor-Id of zero (0). ... As noted earlier, I have compatibility concerns about using vendor Id of zero. If possible, a non-zero ID could be used. However, the IETF does not currently have a private enterprise code (last I checked). Adding one just for RADIUS may have ripple effects through other WG's and other protocols. Section 3: ... Vendor Specific attributes are encoded by using the Vendor-Specific (26) type code, followed by Length (1 octet), a 4 octet Vendor-Id identified using 3 octets (4 octets really) ... "Really"? I suggest just saying "4 octet Vendor-Id." Section 4: The ASCII art is in a different format than the attribute definitions in the existing RADIUS RFC's. It should be consistent. The ASCII art also has two "Length" fields. The second should be "Extended-Length". The following text also has "Length >= 10", and a second "Length >= 4". The second Length should be Extended-Length. I suggest also noting that "Extended-Length = Length - 6". Otherwise, it becomes theoretically possible for them to have conflicting values. Section 4: ... Values XXXX-YYYY are reserved. ... I suggest reserving the same number range as in RFC 2865. Section 4: ... Fragmentation (F): When set(1) the attribute is fragmented. When clear (0), the attribute is not fragmented. When the value portion of an extended attribute exceeds 246 octets the value is fragmented over one or more extended attribute. In this case the Fragmentation Flag is set on the attribute(s) that contain the value fragments. ... I suggest noting that the "Extended-Length" field is the length of THIS PORTION of the fragmented attribute. The real length of the attribute is found by summing the Extended-Lengths of adjacent attributes with the "F" bit set, AND where the Extended-Type is the same, AND where the Tag is the same. Likewise, the value of the extended attribute is formed by concatenating the values of adjacent attributes with the "F" bit set, AND where the Extended-Type is the same, AND where the Tag is the same. This text seems to indicate that the "F" bit is set if an attribute is fragmented... does that mean that the first fragmented attributes has "F" set? The examples in Section 5 indicate that it doesn't. Either way, the text & examples need to be clarified and made consistent. On one hand, setting the "F" bit on the first fragment helps the receiver know immediately that the attribute is fragmented. Otherwise, it has to look at the *next* attribute to see the fragmentation status of the current attribute. But if the "F" bit is set for all fragments, then the receiver has to compare the Extended-Types && Tags to see if the current fragment is part of the previous attribute. I think I prefer the first approach, where "F" is set on all fragments. It also avoids issues. e.g. One implementor decides to fragment at non-246 octet boundaries. Another implementor decides that with "F" zero, and "Extended-Length" less than 246, the attribute *cannot* be fragmented, so two attributes are created where the sender intended to send one. Also, attributes generated by a client or server MUST NOT be fragmented at boundaries other than 246 octets. Doing so would decrease the efficiency of packing. Robust implementations SHOULD support receiving attributes fragmented at non-246 octet boundaries. The Tag field could be renamed, to avoid conflict with the existing Tag field. They seem to be a little different... There should be more text explaining what the meaning of the grouping is for the Tag field. e.g. use-cases. Guidelines to implementation authors help significantly with comprehension of the document, and in creating inter-operable implementations. The document should probably have a section 4.1, explaining all of these issues. Section 5: The ASCII art should again be the same format as in RFC 2865 et al. I also suggest full hex dumps of the attributes, in addition to the ASCII art. Using "0xDEADDEAD" is interesting. Maybe something more innocuous, like "0x12345678" ? The document introduces a new syntax to refer to extended attributes without defining it. e.g. Foo(0,10). It looks like the "0" refers to the Tag, and "10" to the Extended-Type. If we follow the convention of previous documents, we do not need to mention the Tag if it is zero. We also do not need to mention the value of the Extended-Type. Section 6: I don't think there are any security considerations. The document doesn't define any new packets, protocol exchanges, encryption types, or integrity checks. Section 7: If we're going to allocate a private enterprise code for the IETF, it should be something other than zero. Otherwise, I would silently avoid the idea that we're allocating a vendor ID of 0 to the IETF. 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, 29 Mar 2007 00:43:06 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for review of draft-ietf-mip4-radius-requirements-01.txt Date: Wed, 28 Mar 2007 17:42:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed We have received a request from the chairs of the MIPv4 WG for review of the following document: http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements-01.txt Any volunteers to do the review? >From: "McCann Peter-A001034" >To: "Madjid Nakhjiri" , , > >CC: "Mobile IPv4 Mailing List" , "Chowdhury, Kuntal" >, , "Avi Lior" >, "Henrik Levkowetz" > >Subject: RE: [Mip4] Minutes from Prague >Date: Wed, 28 Mar 2007 18:51:29 -0400 > >Hi, Madjid, > >Sorry, I missed the distinction between nakhjiri-radius-mip4-02 >and ietf-mip4-radius-requirement. My mistake. > >From our charter: > > 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been > proposed for MIPv4. > > The working group will first produce a requirements specification, > describing how the work differs from the requirements in RFC 2977 and > the functionality provided by RFC 4004 (the MIPv4 Diameter App). The > reason why this first step is required is that RFC 3127 shows that > full RFC 2977 functionality can't be provided by even a considerably > extended RADIUS, so we need to match the requirements to what can be > done within RADIUS. > > Provided the requirements work finds approval with ADs and RADEXT WG, > the workgroup will complete the specification of MIPv4 RADIUS > attributes, solicit feedback from the RADEXT WG, adjust, and submit > this for publication. Note that the work may require extensions to >the > RADIUS attribute space which will be handled outside the MIP4 WG. > >RADEXT chairs: could one of you (or someone you designate) >please review the draft-ietf-mip4-radius-requirements-01.txt, >and let us know whether it answers your concerns? > >Thanks, > >-Pete > > > >Madjid Nakhjiri wrote: > > Hi Pete, > > > > As I said the reviews were on the nakhjiri-radius-mip4-02 and mainly > > around how/whether Mobile IP is extending RADIUS beyond its limit or > > not and that is why we wrote the ietf-mip4-radius-requirement as a > > response to those reviews to show that we are not stressing RADIUS in > > any way. Part of the issue was also that RADEXT has been working on > > its attribute space extension. > > > > The requirement doc has not been reviewed, since 00 was presumably > > expired before a review. My suggestion was to force a review through > > last call. > > > > If you are interested in the comments on nakhjiri-radius-mip4, I can > > send it. > > > > R, > > > > Madjid > > > > > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Wednesday, March 28, 2007 1:49 PM > > To: Madjid Nakhjiri; Mobile IPv4 Mailing List > > Cc: Chowdhury, Kuntal; kleung@cisco.com; Avi Lior; Henrik Levkowetz > > Subject: RE: [Mip4] Minutes from Prague > > > > Hi, Madjid, > > > > Would it be possible to get the reviews sent to the list, and some > > description from you of how they were addressed? > > > > -Pete > > > > Madjid Nakhjiri wrote: > >> Hi Chairs, > >> > >> > >> draft-ietf-mip4-radius-requirements Active - > >> Needs review!!! Peter: Will go outside the WG to find reviewers. > >> > >> This document was actually produced as a response to the outside (AD > >> and RADEXT chairs) reviews on the draft-nakhjiri-radius-mip4-02. > >> > >> Is it possible to do a last call on this requirement document? > >> > >> Thanks, > >> > >> Madjid > >> > >> -----Original Message----- > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >> Sent: Wednesday, March 28, 2007 8:25 AM > >> To: Mobile IPv4 Mailing List > >> Subject: [Mip4] Minutes from Prague > >> > >> Attached are the draft minutes from the mip4 meeting at IETF 68 in > >> Prague. Please review and send comments and corrections to the list. > >> > >> Thanks to Vidya Narayanan and Nicolas Montavont for taking notes > >> during the meeting. > >> > >> -Pete > -- 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, 28 Mar 2007 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-rfc3576bis-02.txt Message-Id: Date: Wed, 28 Mar 2007 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 : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Author(s) : M. Chiba, et al. Filename : draft-ietf-radext-rfc3576bis-02.txt Pages : 34 Date : 2007-3-28 This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-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-rfc3576bis-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-rfc3576bis-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: <2007-3-28122635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-rfc3576bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-rfc3576bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-28122635.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: Mon, 26 Mar 2007 14:30:26 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Issue 169: Handling Unparsable NAS-Filter-Rule (traffic-rule-draft) Date: Mon, 26 Mar 2007 14:29:50 -0000 Content-Type: multipart/signed; boundary="----=_NextPart_000_0005_01C76F78.89CF95B0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110139D2C9@G3W0072.americas.hpqcorp.net> Thread-Topic: Issue 169: Handling Unparsable NAS-Filter-Rule (traffic-rule-draft) Thread-Index: AcaWRwBd8Gd5W0+GQWyOSh7HGlSTxzXM/chw From: "Sanchez, Mauricio (ProCurve)" To: Cc: This is a multipart message in MIME format. ------=_NextPart_000_0005_01C76F78.89CF95B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Re-mailing last email on issue 169 where discussion went cold. Proposed resolution in email. MS -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (ProCurve) Sent: Thursday, June 22, 2006 2:59 PM To: radiusext@ops.ietf.org Cc: Greg Weber (gdweber) Subject: Issue 169: Handling Unparsable NAS-Filter-Rule Greg pointed out... >Issue 169: Handling Unparsable NAS-Filter-Rule >Submitter names: Greg Weber >Submitter email address: gdweber@cisco.com >Date first submitted: February 2, 2006 >Reference: http://ops.ietf.org/lists/radiusext/2006/msg00104.html >Document: IEEE 802-01 >Comment type: Technical >Priority: S >Section: 1.4, 6 >Rationale/Explanation of issue: >The NAS-Filter-Rule represents a *lot* of functionality. >I think we can expect lots of variability in NASes which >support various parts, e.g. maybe all the filtering, but >not HTTP redirection, etc. I think we maybe need to be >clearer on what is supposed to happen when the NAS gets >a CoA-Request or Access-Request containing directives >that it cannot parse or apply. In particular, in Section >1.4 "Attribute Interpretation", I see text indicating that >non-understood attributes result in Access-Rejects. But, >in Section 6 "Security Considerations", I see text like: >"...a NAS could be configured to ... not accept any >redirection rules if it is known they are not used in >this environment." These would seem to be contradictory. > >Requested change: >Need clarification on the intent. I hear you on this issue. How about the change of section 1.4 to read from: "If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document which it cannot apply, it MUST act as though it had received an Access-Reject." To "If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document which it cannot apply, it MUST act as though it had received an Access-Reject. A NAS may be incapable of applying an attribute due to functional limitations of the NAS or security reasons (as described in section 7 - Security Considerations)." Does this help? MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_000_0005_01C76F78.89CF95B0 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyNjE0Mjk1MFowIwYJ KoZIhvcNAQkEMRYEFPKlBvczbX1tKv65z+2r0w7eFiteMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgB/5uVNouVDYxB+k1m2lxJCKuZ1gycTrhSivve9pI3SF61uBkGopw1LB9Y1v3k+B DTtnNhtzVnLpeqfmJOB1Dt/Ahtlcogv6eBMTtF+cI5hyYLw+sxyUcJQ8s/avWpJvype9sEqnzKfw DUxznKVAvHnMG94WJs+TRfUQWHxNTwEZAAAAAAAA ------=_NextPart_000_0005_01C76F78.89CF95B0-- -- 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, 26 Mar 2007 14:27:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Issue 111: Accounting (traffic-rule-draft) Date: Mon, 26 Mar 2007 14:26:12 -0000 Content-Type: multipart/signed; boundary="----=_NextPart_000_02DA_01C76D3E.B6785D90"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110139D2B9@G3W0072.americas.hpqcorp.net> Thread-Topic: Issue 111: Accounting (traffic-rule-draft) Thread-Index: AcXo4zP4owynFIS2QNSRGzb5U8v1kQ+rl+DwUXnVq8A= From: "Sanchez, Mauricio (ProCurve)" To: Cc: "Bernard Aboba" , This is a multipart message in MIME format. ------=_NextPart_000_02DA_01C76D3E.B6785D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Per IETF-68 discussion, sending last email where discussion went cold. This email proposes a resolution as noted below. MS -----Original Message----- From: Sanchez, Mauricio (PNB Roseville) Sent: Wednesday, February 01, 2006 4:50 PM To: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: Issue 111: Accounting Bernard noted a while back... > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, November 13, 2005 10:17 PM > To: radiusext@ops.ietf.org > Subject: Re: Issue 111: Accounting > > Here is what RFC 2866 says about the notion of an Accounting Session: > <...removed what RFC2866 says about accounting...> > > As Greg noted, the Service-Type is not being changed here, so > that the Service is continuing, and sending of additional > Start/Stop messages is somewhat odd. Also, do we really want > individual RADIUS attributes to provide their own definitions > of when a new session is started and stopped? > RADIUS accounting is a separate protocol from RADIUS > authentication, and runs on a separate port. Authentication > attributes that affect accounting (Class, > Acct-Interim-Interval) have to date been general ones. > Terminating the Accounting Session in mid-stream could cause > issues with RADIUS implementations that use the Accounting > Records for things like simultaneous usage control. > > Paul Congdon said: > > At IETF-64 we reviewed this issue. There did not seem to be > any objection to having compliance statements in the Annex > given that this Annex is where the context for the statements > is developed. Also, since a new session is created, as > stated in the draft, there is no need to use INTERM messages. > > -------------------------------------------------------------- > ------------------- > Issue 111: Accounting > Submitter name: Greg Weber > Submitter email address: gdweber@cisco.com Date first > submitted: August 10, 2005 > Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html > Document: IEEE802-00 > Comment type: T > Priority: S > Section: A.3 > Rationale/Explanation of issue: > > The accounting requirements do not seem to be fully treated > by the draft. Section A.3 has a MUST requirement related to > accounting. I would think that MUST requirements should be > treated by the text, not in an appendix. Why does > redirection require a STOP/START pair? Can't this > information be conveyed via an INTERIM record for the same > session? If the Service- Type is not changing, I'd think > that an INTERIM would suffice. In light that the treatment of accounting behavior would be best treated elsewhere, such as in 3576bis, I would suggest that we omit any discussion of accounting behavior in this draft. This means that sections 1.4 would be modified and section A.3 would be eliminated to remove accounting references. Does this seem like a reasonable path? Cheers, MS ------=_NextPart_000_02DA_01C76D3E.B6785D90 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyMzE4MzA1MlowIwYJ KoZIhvcNAQkEMRYEFNCW3y5v+z7+zXcte9l1f0lFzvEBMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgAUkV2i+AowFDMYfubzhOK9qSpMNHFY5ispgrqk9Ey5dShwNtaMI5F9rHjYuOLzn cvIH4JDdhwFlk8NmJ369BJdHFlzW/PrWWVXNjr5BOIbvuvMFqMS24W2jkKKVsv54xqtIy6NF4uGb vhQg23iElHMqcYa0oSo6HiIOQs3eUbRnAAAAAAAA ------=_NextPart_000_02DA_01C76D3E.B6785D90-- -- 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, 26 Mar 2007 14:27:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Filter-rules-01 & Issue 192 Date: Mon, 26 Mar 2007 14:26:20 -0000 Content-Type: multipart/signed; boundary="----=_NextPart_000_034D_01C76D44.DE5A44D0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110139D2BD@G3W0072.americas.hpqcorp.net> Thread-Topic: Filter-rules-01 & Issue 192 Thread-Index: AccE8jWDqHfTTRcPTs+qxqshRGUcBBlHcMfAAAOiFFAABtzgMAACESFgAM8bgxA= From: "Sanchez, Mauricio (ProCurve)" To: Cc: This is a multipart message in MIME format. ------=_NextPart_000_034D_01C76D44.DE5A44D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jouni recommended... > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [JiK] Yes. Is there a particular reason to add a trailing rule-delim if > there is only a single rule? If not maybe the example below would work: > > rule-list = rule > rule-list =/ rule-list rule-delim rule > rule = "v1" " " (flush-rule / permit-all-rule > / l2-filter-rule / l2-tunnel-rule > / ip-filter-rule / ip-tunnel-rule > / http-filter-rule / http-redir-rule) Yes, your syntax saves one whole octet :), but is the complexity merited? Can we just go with my proposal? It would keep the general rule syntax consistent. MS ------=_NextPart_000_034D_01C76D44.DE5A44D0 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyMzE5MTQ1NVowIwYJ KoZIhvcNAQkEMRYEFIOvBj+D065G3IAgA1JvxZX6slgeMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgDhWcYsyVpvH+r7jvNwqGNKBRspG3y8z4Acw/hDXxYqXvuuCyBgXZtCA15cZpwsK MAsjtxRWM4stNbL3yEalKOBMqVJqv/eNmZrqLzdr286YE/hcKlOPiKL4+txzOhY66iB+JBO9SJC9 qzRNRZ4Fw2o4JCpSTWBKfG+GAPdy0U/fAAAAAAAA ------=_NextPart_000_034D_01C76D44.DE5A44D0-- -- 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, 26 Mar 2007 14:27:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Issue 164: Review (traffic-rule-draft) Date: Mon, 26 Mar 2007 14:26:18 -0000 Content-Type: multipart/signed; boundary="----=_NextPart_000_0340_01C76D43.72FE3FD0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110139D2BC@G3W0072.americas.hpqcorp.net> Thread-Topic: Issue 164: Review (traffic-rule-draft) Thread-Index: AcdtesZJhECeJIf1Q0aE8461B+wZ7A== From: "Sanchez, Mauricio (ProCurve)" To: Cc: "Jari Arkko" This is a multipart message in MIME format. ------=_NextPart_000_0340_01C76D43.72FE3FD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0341_01C76D43.72FE3FD0" ------=_NextPart_001_0341_01C76D43.72FE3FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I believe draft -02 contains resolutions to all Jari's comments in issue 164. Need confirmation from Jari. Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- ------=_NextPart_001_0341_01C76D43.72FE3FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 164: Review (traffic-rule-draft)

I believe draft = -02 contains resolutions to all Jari’s comments in issue = 164.  Need confirmation from = Jari.

Cheers,

MS

-----------= ---------------------------------

Mauricio Sanchez, CISSP

Network Security Architect

ProCurve Networking Business

Hewlett Packard

8000 Foothills Boulevard, ms 5557

Roseville CA, 95747-5557

916.785.1910 Tel

916.785.1815 Fax

mauricio.sanc= hez@hp.com

-------------= -------------------------------  

------=_NextPart_001_0341_01C76D43.72FE3FD0-- ------=_NextPart_000_0340_01C76D43.72FE3FD0 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyMzE5MDQ0NlowIwYJ KoZIhvcNAQkEMRYEFAZgygmfenkAJVcNCnM/To414f3uMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgAWQsh70+/JIAlZKvTRciyM69rt4YCZ0pZ4jynHNeuc3QkkILeisXiy9NbCM++7Q RpO/UDUgO7sURgxsP4LsDKveefzHVCFsbQpikwWbrmm1YO+YXFPKFDHty1E+2kZIT66vtf+6Hs4+ gK37Z66DHFTMaFTL+HaPpSG1sEpPn1eVAAAAAAAA ------=_NextPart_000_0340_01C76D43.72FE3FD0-- -- 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, 26 Mar 2007 14:27:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Issue 130: Diameter Compatibility (traffic-rule-draft) Date: Mon, 26 Mar 2007 14:26:15 -0000 Content-Type: multipart/signed; boundary="----=_NextPart_000_02E4_01C76D3F.B71F2F70"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110139D2BB@G3W0072.americas.hpqcorp.net> Thread-Topic: Issue 130: Diameter Compatibility (traffic-rule-draft) Thread-Index: AcW0v0758aeqZRlCQEuG0c65N9hZnQAABfQQDI7iMgBhn8vmoA== From: "Sanchez, Mauricio (ProCurve)" To: Cc: "Bernard Aboba" This is a multipart message in MIME format. ------=_NextPart_000_02E4_01C76D3F.B71F2F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard submitted... > > Issue 130: Diameter Compatibility > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com Date first > > submitted: August 29, 2005 > > Reference: > > Document: IEEE802-00 > > Comment type: T > > Priority: S > > Section: Various > > Rationale/Explanation of issue: > > The document does not contain a Diameter Compatibility section, as > > required by the RADEXT WG charter. > > > > In reviewing the document, there appears to a major compatibility > > problem between this document and Diameter NASREQ (RFC 4005). > > > > The NAS-Filter-Rule attribute defined in the document is not > > compatible with the NAS-Filter-Rule attribute defined in RFC 4005, > > which is based on the IPFilterRule type defined in RFC 3588. > > This incompatibility will break RADIUS/Diameter gateways. Propose resolution to be the current Diameter Considerations section in draft -02. This uses the same approach as RFC4675. Cheers, MS ------=_NextPart_000_02E4_01C76D3F.B71F2F70 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyMzE4MzgwMlowIwYJ KoZIhvcNAQkEMRYEFLsxRveVEiyy48ijXYn2oxp8mf8jMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgG8UvShDRdp4A7U1bbAHHt1qKuAxuH8owcSS3Rezg2UKvZCKMfVU35led+Ep8Qno 4F545FMQpx+5OnlLHYYr2Vfzj/du1AlmwIuEzDwKSHv0pVuxPbvYPoSjhb1mADeeQTPVeaLvUDlw CwVUVtdV9nvKqPbe6/fRvx21LMSM3QioAAAAAAAA ------=_NextPart_000_02E4_01C76D3F.B71F2F70-- -- 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, 26 Mar 2007 14:26:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Issue 114: WGLC Review (traffic-rule-draft) Date: Mon, 26 Mar 2007 14:26:14 -0000 Content-Type: multipart/signed; boundary="----=_NextPart_000_02DF_01C76D3F.0FC78650"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2F2D38A4B8346F48A683750A46BAB2110139D2BA@G3W0072.americas.hpqcorp.net> Thread-Topic: Issue 114: WGLC Review (traffic-rule-draft) Thread-Index: AcWePzlODImo9agLSDucXCqk/4aVIB3wxFrwVd3JBbA= From: "Sanchez, Mauricio (ProCurve)" To: Cc: "Bernard Aboba" This is a multipart message in MIME format. ------=_NextPart_000_02DF_01C76D3F.0FC78650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Per IETF-68 resending email where discussion went cold. See below. Resolution proposed in original email. MS -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (PNB Roseville) Sent: Tuesday, January 10, 2006 8:44 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: Issue 114: WGLC Review Bernard submitted a while back... > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Subject: Issue 114: WGLC Review > > I do not understand the purpose of the accounting > functionality in the draft. > > The focus of this document is VLAN attribute, priority and > filtering. How does Acct-EAP-Auth-Method fit into that? I > think this is a leftover WLAN attribute which should be removed. [ms] Agree. This was a vestiage from earlier days of document and was left in error. > > Acct-NAS-Filter-Rule attribute. The purpose of this attribute > is to keep count of hits on filter rules. This duplicates > functionality under development in other WGs such as IPFIX, > and so I'd question whether this is appropriate functionality > for RADIUS accounting. [ms] I see this accounting attribute as adding basic audit capability to the authorization policy expressed through the NAS-Filter-Rule attribute. Surely you would agree that performing accounting/audit functions is well within scope of RADIUS. Accounting records already have data counts for session use, so why not have filter hit counts along with them? A straightforward use case is an administrator that has a (strict) filter policy for which he/she wishes to be notified anytime a user tries to pass unauthorized traffic through the NAS. Errant users could then be sanctioned in the future. > > Overview > > I do not understand the purpose of Section 2, Overview. Most > of it seems like it could be deleted without losing anything. [ms] Other than the first paragraph, most of the material comes by way of the old redirect draft Avi was stewarding. If he has no objection, we can see about removing text from this section. Cheers, MS -- 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_02DF_01C76D3F.0FC78650 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMyMzE4MzMyMVowIwYJ KoZIhvcNAQkEMRYEFI1sJnVmAKO7xXCYlBCfj3z1cw4aMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgK3R9gh+LG53YIi4KVGLFQ6DkASF4Z4mLUF2m28VCsQdKnJt6B7SWXKXO0F2bEFf DK67QgoGlX10SaW9IZ9vxjkOgD1e6G8YEKjhVIeamN4eea55OSAT3PeJB8FYk791Az40+F9BPWxy qBTJfhccEi2mjWK+zlpsndbPmFaoWgRsAAAAAAAA ------=_NextPart_000_02DF_01C76D3F.0FC78650-- -- 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, 26 Mar 2007 00:59:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 224: RFC 3576bis and Renumbering Date: Sun, 25 Mar 2007 20:58:37 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , Hi Bernard,=20 See inline please.... -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Sunday, March 25, 2007 12:53 PM To: Avi Lior; radiusext@ops.ietf.org Subject: RE: Issue 224: RFC 3576bis and Renumbering >First in response to Framed-IP, Framed-IPv6 etc > >Framed-IP-Address and the other attributes are very valid session=20 >identifier and I dont think we should >remove from them session=20 >identification. Are you actually using Framed-IP-Address and/or Framed-IPv6-Prefix/Framed-Interface-Id this way? [Avi] Does it matter if I use it this way. Are we designing for what we are doing today or the future? If we take this away what could I use in the futre if I want to do this?=20 So now the pragmatic answer. In WiMAX and other technologies we have the concept of a Network Access Session and IP Session. RADIUS performs Network Access Authentication (802.16e) and then one or more IP Sessions can be established (typically using MIP/RADIUS interactions). =20 >The other attributes used for session identification are not as good. =20 >For example, if identity hiding is >used User-Name is not useable as a=20 >session identifier. Right. There could be 10 "anonymous" users on the same NAS. [Avi] Or more likely like 000s of anonymous users on the same NAS >Accounting-Session ID is also poor because accounting session ids can=20 >change without >reauthentication. Can you explain this more? [Avi] A change in QoS for example can trigger a stop and a start. The Acct-Session-ID will change. The change in QoS can come from anywhere. To correlate to the session we use Acct-MultiSession-Id or Framed-IP address, or even Class, etc.... >NAS-Port ??? I am not sure if that is used. It seems harmless though, since this is not an attribute that could be changed in a CoA-Request. [Avi]I agree. >Also Framed-IP is used to identify an IP-Session of the a user. A user >can have several IP sessions: >serveral IPv4 sessions and IPv6 sessions >all associated with the same authentication. We may want to=20 >>specifically target the COA to an IP session and thus we need the IP=20 >address attributes to achieve >that. OK. >Therefore, I think there needs to be a scheme where we can use an=20 >attribute both for session >identification and also to change the value >of that attribute. I can propose two approaches: > >-Where we have a session identification attribute, if we want to modify >that session identification >attribute then we can send two values: the >first value identifies the session and the next value will >change the=20 >value. > >-A more explicit method is to introduce new attributes such as=20 >New-Framed-IP-Address. This seems like the kind of problem that Service-Type=3D"Authorize-Only" is helpful in solving. Just identify the session (you can use Framed-IPv6-Prefix/Framed-Interface-Id) and then send a new Framed-IPv6-Prefix attribute in response to the Access-Request. [Avi] Sure but that is very in efficient right? We have a push model lets not cripple it. Before we thought that the these valid session identifiers were immutable now we are seeing that that is not the case (at least for some of them and in the future others will come up). Lets fix this correctly so we don't have to do this again. For now I favour not reallying on the inefficient semantics of COA with Authorize-Only. And I prefer the explicit use of attributes. So for renumbering lets create a new attribute(s) for them. Others can be introduced in the future. We can add text to provide such guidance in 3576bis. >The second point I want to make speaks to your statement that states=20 >that only attributes that appear >in the table can appear in a COA message. >This is not good because as we see, everytime someone >creates a new=20 >attribute then we would have to bis 3576 again. Which is bad. Right. >Perhaps we can put some text that says that future attributes may be=20 >allowed in COA messages. And >it would be up to those specific RFCs=20 >to spec. that their attributes can go into the COA message. Yes, we should say that. >Delegated Prefix should have done that. It did, actually. The document states that it is legal for inclusion in a CoA-Request. >My final point, as you are adding Delegated Prefix to 3576. We should=20 >also add CUI to 3576. It can >be an excellent user identification=20 >attribute especially when User-Name does not work. Thanks. I had forgotten about that. \ -- 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, 25 Mar 2007 20:52:32 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: Issue 224: RFC 3576bis and Renumbering Date: Sun, 25 Mar 2007 13:51:29 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Based on Avi's comments, the list of session identification attributes now looks like this: Session identification attributes Attribute # Reference Description --------- --- --------- ----------- User-Name 1 [RFC2865] The name of the user associated with the session. NAS-Port 5 [RFC2865] The port on which the session is terminated. Framed-IP-Address 8 [RFC2865] The IPv4 address associated with the session. Called-Station-Id 30 [RFC2865] The link address to which the session is connected. Calling-Station-Id 31 [RFC2865] The link address from which the session is connected. Acct-Session-Id 44 [RFC2866] The identifier uniquely identifying the session on the NAS. Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely identifying related sessions. NAS-Port-Type 61 [RFC2865] The type of port used. NAS-Port-Id 87 [RFC2869] String identifying the port where the session is. Chargeable-User- 89 [RFC4372] The CUI associated with the Identity session. Needed in situations where a privacy NAI is used, so that User-Name may not be unique (e.g. "anonymous"). Originating-Line-Info 94 [RFC4005] Provides information on the characteristics of the line from which a session originated. Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier associated with the session; always sent with Framed-IPv6-Prefix. Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated with the session, always sent with Framed-Interface-Id. The following text is proposed for Section 2.3, to address the issue of new attribute support for RFC 3576bis: " Within this specification attributes may be used for identification, authorization or other purposes. RADIUS Attribue specifications created after publication of this document SHOULD state whether an Attribute can be included in CoA or Disconnect messages and if so, which messages it may be included in and whether it serves as an identification or authorization attribute. Even if a NAS implements an attribute for use with RADIUS authentication and accounting, it may not support inclusion of that attribute within Disconnect-Request or CoA-Request packets, given the difference in attribute semantics. This is true even for attributes specified as allowable within Access-Accept packets (such as those defined within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675], [RFCFilter] and [RFCDelegated]). If unsupported attributes are included within a Disconnect/CoA-Request packet, the RADIUS client will send a Disconnect-NAK/CoA-NAK in response, possibly containing an Error- Cause attribute with value Unsupported Attribute (401)." I have added the following entry to the CoA and Disconnect Attribute tables: 0-1 0 0 89 Chargeable-User-Identity [Note 1] I have added a [Note 8] entry for Framed-IP-Address, Framed-IPv6-Prefix and Framed-Interface-Id. The text for Note 8 reads as follows: [Note 8] Since the Framed-IP-Address, Framed-IPv6-Prefix and Framed- Interface-Id attributes are used for identification, these attributes cannot be updated by including new values within a CoA-Request. Instead, a CoA-Request with Service-Type="Authorize Only" is used, and the new values can be supplied in response to the ensuing Access- Request. Here is the new text for Appendix A: Appendix A - Changes from RFC 3576 This Appendix lists the major changes between [RFC3576] and this document. Minor changes, including style, grammar, spelling, and editorial changes are not mentioned here. o Added details relating to handling of the Proxy-State Attribute. Added requirement for duplicate detection on the RADIUS client (Section 2.3). o Added Chargeable-User-Identity as a session identification attribute (Section 3). o Added requirements for inclusion of the State Attribute in CoA- Request packets with a Service-Type of "Authorize Only" (Section 3.1). o Added clarification on the calculation of the Message-Authenticator Attribute (Section 3.2). o Added statement that support for "Authorize Only" Service-Type is optional (Section 3.4). o Updated CoA-Request Attribute Table to include Filter-Rule, Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN- Name and User-Priority attributes (Section 3.4). o Added the Chargeable-User-Identity Attribute to both the CoA- Request and Disconnect-Request Attribute Table (Section 3.4). o Added note relating to use of Service-Type="Authorize Only" for renumbering (Section 3.4). o Use of a Service-Type Attribute within a Disconnect-Request is prohibited (Section 3.4,4). o Added Diameter Considerations (Section 5). o Changed the text to indicate that the Event-Timestamp Attribute should not be recalculated on retransmission. The implications for replay and duplicate detection are discussed (Section 6.4). -- 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, 25 Mar 2007 16:54:07 +0000 Message-ID: From: "Bernard Aboba" To: avi@bridgewatersystems.com, radiusext@ops.ietf.org Bcc: Subject: RE: Issue 224: RFC 3576bis and Renumbering Date: Sun, 25 Mar 2007 09:52:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >First in response to Framed-IP, Framed-IPv6 etc > >Framed-IP-Address and the other attributes are very valid session >identifier and I dont think we should >remove from them session >identification. Are you actually using Framed-IP-Address and/or Framed-IPv6-Prefix/Framed-Interface-Id this way? >The other attributes used for session identification are not as good. For >example, if identity hiding is >used User-Name is not useable as a session >identifier. Right. There could be 10 "anonymous" users on the same NAS. >Accounting-Session ID is also poor because accounting session ids can >change without >reauthentication. Can you explain this more? >NAS-Port ??? I am not sure if that is used. It seems harmless though, since this is not an attribute that could be changed in a CoA-Request. >Also Framed-IP is used to identify an IP-Session of the a user. A user can >have several IP sessions: >serveral IPv4 sessions and IPv6 sessions all >associated with the same authentication. We may want to >specifically >target the COA to an IP session and thus we need the IP address attributes >to achieve >that. OK. >Therefore, I think there needs to be a scheme where we can use an >attribute both for session >identification and also to change the value of >that attribute. I can propose two approaches: > >-Where we have a session identification attribute, if we want to modify >that session identification >attribute then we can send two values: the >first value identifies the session and the next value will >change the >value. > >-A more explicit method is to introduce new attributes such as >New-Framed-IP-Address. This seems like the kind of problem that Service-Type="Authorize-Only" is helpful in solving. Just identify the session (you can use Framed-IPv6-Prefix/Framed-Interface-Id) and then send a new Framed-IPv6-Prefix attribute in response to the Access-Request. >The second point I want to make speaks to your statement that states that >only attributes that appear >in the table can appear in a COA message. >This is not good because as we see, everytime someone >creates a new >attribute then we would have to bis 3576 again. Which is bad. Right. >Perhaps we can put some text that says that future attributes may be >allowed in COA messages. And >it would be up to those specific RFCs to >spec. that their attributes can go into the COA message. Yes, we should say that. >Delegated Prefix should have done that. It did, actually. The document states that it is legal for inclusion in a CoA-Request. >My final point, as you are adding Delegated Prefix to 3576. We should also >add CUI to 3576. It can >be an excellent user identification attribute >especially when User-Name does not work. Thanks. I had forgotten about that. -- 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: Sat, 24 Mar 2007 21:54:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76E5F.04F860A3" Subject: RE: Issue 224: RFC 3576bis and Renumbering Date: Sat, 24 Mar 2007 17:54:38 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C76E5F.04F860A3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bernard, =20 This issue is raising a couple of other issues. This email addresses the = following:=20 =20 -Why I dont think it is a good idea to remove Framed-Ip from session = idenftication. -Need to have a method for avoiding bising 3576 when new attributes are = added. -Need to add CUI from 4372 to 3576bis as a session identifier. =20 First in response to Framed-IP, Framed-IPv6 etc =20 Framed-IP-Address and the other attributes are very valid session = identifier and I dont think we should remove from them session = identification. =20 The other attributes used for session identification are not as good. = For example, if identity hiding is used User-Name is not useable as a = session identifier. =20 Accounting-Session ID is also poor because accounting session ids can = change without reauthentication. =20 NAS-Port ??? I am not sure if that is used. =20 Also Framed-IP is used to identify an IP-Session of the a user. A user = can have several IP sessions: serveal IPv4 sessions and IPv6 sessions = all associated with the same authentication. We may want to = specifically target the COA to an IP session and thus we need the IP = address attributes to acheive that. =20 =20 Therefore, I think there needs to be a scheme where we can use an = attribute both for session identification and also to change the value = of that attribute. I can propose two approaches: =20 -Where we have a session identification attribute, if we want to modify = that session identification attribute then we can send two values: the = first value identifies the session and the next value will change the = value. =20 -A more explicit method is to introduce new attributes such as = New-Framed-IP-Address. =20 The second point I want to make speaks to your statement that states = that only attributes that appear in the table can appear in a COA = message. This is not good because as we see, everytime someone creates = a new attribute then we would have to bis 3576 again. Which is bad. =20 Perhaps we can put some text that says that future attributes may be = allowed in COA messages. And it would be up to those specific RFCs to = spec. that their attributes can go into the COA message. =20 Delegated Prefix should have done that. =20 My final point, as you are adding Delegated Prefix to 3576. We should = also add CUI to 3576. It can be an excellent user identification = attribute especially when User-Name does not work. =20 =20 =20 =20 Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183 ________________________________ From: owner-radiusext@ops.ietf.org on behalf of Bernard Aboba Sent: Sat 3/24/2007 2:37 AM To: radiusext@ops.ietf.org Subject: Issue 224: RFC 3576bis and Renumbering Issue 224: RFC 3576bis and Renumbering Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 19, 2007 Reference: Document: RFC 3576bis-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: During the 16ng meeting, the need for renumbering support in 3576bis was discussed. This would involve changing the Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes in a CoA-Request, so that the new = prefixes could be advertised. In reviewing RFC 3576, it appears that Framed-IPv6-Prefix is used as an identifying attribute and therefore it cannot be changed in a CoA-Request (although it would be possible to use Service-Type=3D"Authorize Only" to change it). The same thing is true = of Framed-IP-Address and Framed-Interface-Id, although these attributes are typically used with PPP, so they would only be effective if the user was able to renegotiate NCP in mid-session, which most implementations don't support. In rereading RFC 3576, it also seems to imply that only the attributes listed in the table can be included in a CoA-Request, which would limit = the ability to include a Delegated-IPv6-Prefix attribute. However, the = point is really that a NAS might not support an attribute that is being changed = (new or old), so that the text should make that point instead. Assuming that existing implementations aren't using the = Framed-IP-Address, Framed-IPv6-Prefix and Framed-Interface-Id attributes for session identification, my recommendation is that we consider removing them from = the list of session identification attributes. Attributes such as Acct-Session-Id, User-Name, NAS-Port, etc. remain and should be adequate = for session identification. We also should add the VLAN attributes defined in RFC 4675 to the list = of attributes. The required changes are as follows: Change: "This is true even for attributes specified within [RFC2865], [RFC2868], [RFC2869], [RFC3162] or [RFC3579] as allowable within Access-Accept packets. As a result, if attributes beyond those specified in Section 3.5 To: "This is true even for attributes specified as allowable within Access-Accept packets (such as within [RFC2865],[RFC2868],[RFC2869],[RFC3162],[RFC3579],[RFC4675], [RFCFilter][RFCDelegated]). As a result, if unsupported attributes" Remove Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix = from the list of session identification attributes. In the Attribute Table, change Framed-IP-Address, Framed-Interface-Id = and Framed-IPv6-Prefix from [Note 1] (Session Identification Attributes) to [Note 3] authorization attributes changeable in a CoA-Request. Remove = them from the attributes includable in a Disconnect-Request. Add Delegated-IPv6-Prefix as changeable in a CoA-Request (0+) [Note 3]. Add Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, User-Priority-Table Attributes as changeable in the CoA-Request. Add references to RFC 4675 and the Delegated-IPv6-Prefix documents. Add the following statements to Appendix A: Updated CoA-Request Attribute Table to include Filter-Rule, Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, User-Priority-Table Attributes. Clarified use of Framed-IPv6-Prefix, Framed-IP-Address, Delegated-IPv6-Prefix in renumbering. -- 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_001_01C76E5F.04F860A3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Issue 224: RFC 3576bis and = Renumbering=0A= =0A= =0A= =0A=
=0A=
Hi = Bernard,
=0A=
 
=0A=
This issue is raising a = couple of other issues. This email addresses the = following: 
=0A=
 
=0A=
-Why I dont think it is a = good idea to remove Framed-Ip from session idenftication.
=0A=
-Need to have a method for = avoiding bising 3576 when new attributes are added.
=0A=
-Need to add CUI from 4372 to = 3576bis as a session identifier.
=0A=
 
=0A=
First in response to = Framed-IP, Framed-IPv6 etc
=0A=
 
=0A=
Framed-IP-Address and the = other attributes are very valid session identifier and I dont think = we should remove from them session identification.
=0A=
 
=0A=
The other attributes used for = session identification are not as good.  For example, if identity = hiding is used User-Name is not useable as a session = identifier.
=0A=
 
=0A=
Accounting-Session ID is also = poor because accounting session ids can change without = reauthentication.
=0A=
 
=0A=
NAS-Port ???  I am not = sure if that is used.
=0A=
 
=0A=
Also Framed-IP is used to = identify an IP-Session of the a user.  A user can have several IP = sessions: serveal IPv4 sessions and IPv6 sessions all associated with = the same authentication.  We may want to specifically target the = COA to an IP session and thus we need the IP address attributes to = acheive that. 
=0A=
 
=0A=
Therefore,  I think = there needs to be a scheme where we can use an attribute both for = session identification and also to change the value of that = attribute.  I can propose two approaches:
=0A=
 
=0A=
-Where we have a session = identification attribute, if we want to modify that session = identification attribute then we can send two values: the first value = identifies the session and the next value will change the = value.
=0A=
 
=0A=
-A more explicit method is to = introduce new attributes such as New-Framed-IP-Address.
=0A=
 
=0A=
The second point I want to = make speaks to your statement = that states that only attributes that appear in the table can appear in = a COA message.  This is not good because as we see, everytime = someone creates a new attribute then we would have to bis 3576 = again.  Which is bad.
=0A=
 
=0A=
Perhaps we can put some text = that says that future attributes may be allowed  in COA = messages.  And it would be up to those specific RFCs to  spec. = that their attributes can go into the COA message.
=0A=
 
=0A=
Delegated Prefix should have = done that.
=0A=
 
=0A=
My final point, as you are = adding Delegated Prefix to 3576.  We should also add CUI to = 3576.  It can be an excellent user identification attribute = especially when User-Name does not work.
=0A=
 
=0A=
 
=0A=
 
=0A=
 
=0A=
=0A=
Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 = 796-4183
=0A=


=0A=

=0A=
From: owner-radiusext@ops.ietf.org =
on behalf of Bernard Aboba
Sent: Sat 3/24/2007 2:37 =
AM
To: radiusext@ops.ietf.org
Subject: Issue 224: =
RFC 3576bis and Renumbering

=0A=

=0A=

Issue 224: RFC 3576bis and Renumbering
Submitter =
name: Bernard Aboba
Submitter email address: =
aboba@internaut.com
Date first submitted: March 19, =
2007
Reference:
Document: RFC 3576bis-00
Comment type: =
T
Priority: S
Section: Various
Rationale/Explanation of =
issue:

During the 16ng meeting, the need for renumbering support =
in 3576bis was
discussed.  This would involve changing the =
Framed-IPv6-Prefix and
Delegated-IPv6-Prefix attributes in a =
CoA-Request, so that the new prefixes
could be =
advertised.   In reviewing RFC 3576, it appears =
that
Framed-IPv6-Prefix is used as an identifying attribute and =
therefore it
cannot be changed in a CoA-Request (although it would be =
possible to use
Service-Type=3D"Authorize Only" to change =
it).   The same thing is true of
Framed-IP-Address and =
Framed-Interface-Id, although these attributes are
typically used =
with PPP, so they would only be effective if the user was
able to =
renegotiate NCP in mid-session, which most implementations =
don't
support.

In rereading RFC 3576, it also seems to imply =
that only the attributes
listed in the table can be included in a =
CoA-Request, which would limit the
ability to include a =
Delegated-IPv6-Prefix attribute.  However, the point is
really =
that a NAS might not support an attribute that is being changed =
(new
or old), so that the text should make that point =
instead.

Assuming that existing implementations aren't using the =
Framed-IP-Address,
Framed-IPv6-Prefix and Framed-Interface-Id =
attributes for session
identification, my recommendation is that we =
consider removing them from the
list of session identification =
attributes.  Attributes such as
Acct-Session-Id, User-Name, =
NAS-Port, etc. remain and should be adequate for
session =
identification.

We also should add the VLAN attributes defined in =
RFC 4675 to the list of
attributes.

The required changes are =
as follows:

Change:

"This is true even for =
attributes
specified within [RFC2865], [RFC2868], =
[RFC2869],
[RFC3162] or [RFC3579] as allowable within Access-Accept =
packets.
As a result, if attributes beyond those specified in Section =
3.5

To:

"This is true even for attributes specified as =
allowable within
Access-Accept packets (such as =
within
[RFC2865],[RFC2868],[RFC2869],[RFC3162],[RFC3579],[RFC4675],[RFCFilter][RFCDelegated]).  As a result, if unsupported =
attributes"

Remove Framed-IP-Address, Framed-Interface-Id and =
Framed-IPv6-Prefix from
the list of session identification =
attributes.

In the Attribute Table, change Framed-IP-Address, =
Framed-Interface-Id and
Framed-IPv6-Prefix from [Note 1] (Session =
Identification Attributes) to
[Note 3] authorization attributes =
changeable in a CoA-Request.  Remove them
from the attributes =
includable in a Disconnect-Request.  Add
Delegated-IPv6-Prefix =
as changeable in a CoA-Request (0+) [Note 3].  =
Add
Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, =
User-Priority-Table
Attributes as changeable in the =
CoA-Request.

Add references to RFC 4675 and the =
Delegated-IPv6-Prefix documents.

Add the following statements to =
Appendix A:

Updated CoA-Request Attribute Table to include =
Filter-Rule,
Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, =
Egress-VLAN-Name,
User-Priority-Table Attributes.

Clarified =
use of Framed-IPv6-Prefix, Framed-IP-Address,
Delegated-IPv6-Prefix =
in renumbering.



--
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/<=
/A>>

------_=_NextPart_001_01C76E5F.04F860A3--

--
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: Sat, 24 Mar 2007 06:39:10 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Issue 224:  RFC 3576bis and Renumbering
Date: Fri, 23 Mar 2007 23:37:39 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Issue 224: RFC 3576bis and Renumbering
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: March 19, 2007
Reference:
Document: RFC 3576bis-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

During the 16ng meeting, the need for renumbering support in 3576bis was 
discussed.  This would involve changing the Framed-IPv6-Prefix and 
Delegated-IPv6-Prefix attributes in a CoA-Request, so that the new prefixes 
could be advertised.   In reviewing RFC 3576, it appears that 
Framed-IPv6-Prefix is used as an identifying attribute and therefore it 
cannot be changed in a CoA-Request (although it would be possible to use 
Service-Type="Authorize Only" to change it).   The same thing is true of 
Framed-IP-Address and Framed-Interface-Id, although these attributes are 
typically used with PPP, so they would only be effective if the user was 
able to renegotiate NCP in mid-session, which most implementations don't 
support.

In rereading RFC 3576, it also seems to imply that only the attributes 
listed in the table can be included in a CoA-Request, which would limit the 
ability to include a Delegated-IPv6-Prefix attribute.  However, the point is 
really that a NAS might not support an attribute that is being changed (new 
or old), so that the text should make that point instead.

Assuming that existing implementations aren't using the Framed-IP-Address, 
Framed-IPv6-Prefix and Framed-Interface-Id attributes for session 
identification, my recommendation is that we consider removing them from the 
list of session identification attributes.  Attributes such as 
Acct-Session-Id, User-Name, NAS-Port, etc. remain and should be adequate for 
session identification.

We also should add the VLAN attributes defined in RFC 4675 to the list of 
attributes.

The required changes are as follows:

Change:

"This is true even for attributes
specified within [RFC2865], [RFC2868], [RFC2869],
[RFC3162] or [RFC3579] as allowable within Access-Accept packets.
As a result, if attributes beyond those specified in Section 3.5

To:

"This is true even for attributes specified as allowable within
Access-Accept packets (such as within
[RFC2865],[RFC2868],[RFC2869],[RFC3162],[RFC3579],[RFC4675],
[RFCFilter][RFCDelegated]).  As a result, if unsupported attributes"

Remove Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix from 
the list of session identification attributes.

In the Attribute Table, change Framed-IP-Address, Framed-Interface-Id and 
Framed-IPv6-Prefix from [Note 1] (Session Identification Attributes) to 
[Note 3] authorization attributes changeable in a CoA-Request.  Remove them 
from the attributes includable in a Disconnect-Request.  Add 
Delegated-IPv6-Prefix as changeable in a CoA-Request (0+) [Note 3].  Add 
Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, User-Priority-Table 
Attributes as changeable in the CoA-Request.

Add references to RFC 4675 and the Delegated-IPv6-Prefix documents.

Add the following statements to Appendix A:

Updated CoA-Request Attribute Table to include Filter-Rule, 
Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, 
User-Priority-Table Attributes.

Clarified use of Framed-IPv6-Prefix, Framed-IP-Address, 
Delegated-IPv6-Prefix in renumbering.



--
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, 23 Mar 2007 08:27:40 +0000
Message-ID: <46038F33.4020702@gmx.net>
Date: Fri, 23 Mar 2007 09:26:27 +0100
From: Hannes Tschofenig 
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: "Parviz Yegani (pyegani)" 
CC: Bernard Aboba ,  radiusext@ops.ietf.org
Subject: Re: Publication of RADIUS Prepaid Document
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

As I mentioned during the meeting, this is fine for me as well.

Ciao
Hannes

Parviz Yegani (pyegani) wrote:
> I was unable to attend this week's IETF meeting in Prague. I support
> this approach!
>
> -Parviz
>
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
> On Behalf Of Bernard Aboba
> Sent: Wednesday, March 21, 2007 3:27 AM
> To: radiusext@ops.ietf.org
> Subject: Publication of RADIUS Prepaid Document
>
> At IETF 68, it was suggested that the RADIUS Prepaid document be
> published as an Informational RFC documenting existing usage (presumably
> based on 
> RADIUS VSAs).   This would enable us to unblock the document, since 
> conformance to the Guidelines document (still in progress) would no
> longer be required.
>
> Are there any objections to this approach?
>
>
>
> --
> 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: Fri, 23 Mar 2007 01:27: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: RE: Publication of RADIUS Prepaid Document
Date: Thu, 22 Mar 2007 18:26:30 -0700
Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB03481F17@xmb-sjc-236.amer.cisco.com>
Thread-Topic: Publication of RADIUS Prepaid Document
Thread-Index: Acdro3aGXTi81IMARdynXd6tlAks7ABRmQhg
From: "Parviz Yegani \(pyegani\)" 
To: "Bernard Aboba" , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=901; t=1174613194; x=1175477194; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pyegani@cisco.com; z=From:=20=22Parviz=20Yegani=20\(pyegani\)=22=20 |Subject:=20RE=3A=20Publication=20of=20RADIUS=20Prepaid=20Document |Sender:=20; bh=z1qJfIiy2SljiVoM2rQ60NFQEA6IIsojd/PQz5Ca3qw=; b=kqfLmpO9ap420GUHswq0LKTEcRHSt8cGEiYnLrmUYfP/vh9iiFtfRZ5rrTJQWk6/lph86SA3 zOsMp5bcsSYBJT0nOT3yCQuNhp7W1/IE2vcyBdTxW9UIx76xrusSRBvt;
Authentication-Results: sj-dkim-6; header.From=pyegani@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; );

I was unable to attend this week's IETF meeting in Prague. I support
this approach!

-Parviz

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Bernard Aboba
Sent: Wednesday, March 21, 2007 3:27 AM
To: radiusext@ops.ietf.org
Subject: Publication of RADIUS Prepaid Document

At IETF 68, it was suggested that the RADIUS Prepaid document be
published as an Informational RFC documenting existing usage (presumably
based on=20
RADIUS VSAs).   This would enable us to unblock the document, since=20
conformance to the Guidelines document (still in progress) would no
longer be required.

Are there any objections to this approach?



--
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, 22 Mar 2007 15:39:12 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-01.txt
Date: Thu, 22 Mar 2007 08:38:52 -0700
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_124c_4a91_31af"

This is a multi-part message in MIME format.

------=_NextPart_000_124c_4a91_31af
Content-Type: text/plain; format=flowed

I believe that this version of the document closes all the issues that were 
raised in WG last call.  Please look it over.  If no additional problems are 
found by April 8, 2007 we will send it off to the IESG for publication.


>From: Internet-Drafts@ietf.org
>To: i-d-announce@ietf.org
>CC: radiusext@ops.ietf.org
>Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-01.txt Date: Thu, 22 Mar 
>2007 10:50:03 -0400
>
>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		: Dynamic Authorization Extensions to Remote Authentication Dial In 
>User Service (RADIUS)
>	Author(s)	: M. Chiba, et al.
>	Filename	: draft-ietf-radext-rfc3576bis-01.txt
>	Pages		: 33
>	Date		: 2007-3-22
>
>This document describes a currently deployed extension to the Remote
>    Authentication Dial In User Service (RADIUS) protocol, allowing
>    dynamic changes to a user session, as implemented by network access
>    server products.  This includes support for disconnecting users and
>    changing authorizations applicable to a user session.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-01.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-rfc3576bis-01.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-rfc3576bis-01.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_000_124c_4a91_31af
Content-Type: Multipart/Alternative; name="attach3";
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attach3";



--attach3--

------=_NextPart_000_124c_4a91_31af--

--
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, 22 Mar 2007 15:38:22 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: I-D ACTION:draft-ietf-radext-rfc4590bis-01.txt
Date: Thu, 22 Mar 2007 08:37:53 -0700
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_6520_49d1_6970"

This is a multi-part message in MIME format.

------=_NextPart_000_6520_49d1_6970
Content-Type: text/plain; format=flowed

I believe that this version of the document closes all the issues that were 
raised in WG last call.  Please look it over.  If no additional problems are 
found by April 8, 2007 we will send it off to the IESG for publication.


>From: Internet-Drafts@ietf.org
>To: i-d-announce@ietf.org
>CC: radiusext@ops.ietf.org
>Subject: I-D ACTION:draft-ietf-radext-rfc4590bis-01.txt Date: Thu, 22 Mar 
>2007 10:50:03 -0400
>
>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 Extension for Digest Authentication
>	Author(s)	: B. Sterman, et al.
>	Filename	: draft-ietf-radext-rfc4590bis-01.txt
>	Pages		: 33
>	Date		: 2007-3-22
>
>This document defines an extension to the Remote Authentication Dial-
>    In User Service (RADIUS) protocol to enable support of Digest
>    Authentication, for use with HTTP-style protocols like the Session
>    Initiation Protocol (SIP) and HTTP.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-01.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-rfc4590bis-01.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-rfc4590bis-01.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_000_6520_49d1_6970
Content-Type: Multipart/Alternative; name="attach3";
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attach3";



--attach3--

------=_NextPart_000_6520_49d1_6970--

--
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, 22 Mar 2007 14:50:54 +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-rfc4590bis-01.txt 
Message-Id: 
Date: Thu, 22 Mar 2007 10:50:03 -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 Extension for Digest Authentication
	Author(s)	: B. Sterman, et al.
	Filename	: draft-ietf-radext-rfc4590bis-01.txt
	Pages		: 33
	Date		: 2007-3-22
	
This document defines an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-01.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-rfc4590bis-01.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-rfc4590bis-01.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:	<2007-3-22085226.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc4590bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc4590bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2007-3-22085226.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, 22 Mar 2007 14:50:43 +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-rfc3576bis-01.txt 
Message-Id: 
Date: Thu, 22 Mar 2007 10:50:03 -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		: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: M. Chiba, et al.
	Filename	: draft-ietf-radext-rfc3576bis-01.txt
	Pages		: 33
	Date		: 2007-3-22
	
This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-01.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-rfc3576bis-01.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-rfc3576bis-01.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:	<2007-3-22084600.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2007-3-22084600.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, 22 Mar 2007 12:22:49 +0000
From: "David B. Nelson" 
To: 
Subject: Revised Requirements for RADIUS crypto-agility
Date: Thu, 22 Mar 2007 08:20:22 -0400
Message-ID: <022a01c76c7c$7706d730$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdsUYOjmygOEGj8QNytomOAeGg0mQAKNlsA

Herewith are the revised requirements for RADIUS Crypto-Agility,
based on the discussions held at IETF-68.

OVERALL APPROACH

1. RADIUS crypto-agility solutions are not restricted to utilizing
technology described in existing RFCs.  Since RADIUS over IPsec is
already described in RFC 3162 and 3579, this technique is already
available to those who wish to use it.  Therefore it is expected that
proposals will utilize other techniques.

SECURITY SERVICES

2. Proposals MUST support the negotiation of cryptographic
algorithms for per-packet integrity/authentication protection.  
Support for confidentiality of entire RADIUS packets is OPTIONAL.  
However, proposals MUST support the negotiation of algorithms for
encryption (sometimes referred to as "hiding") of RADIUS attributes.
If possible, it is desirable for proposals to provide for the
encryption of existing attributes.  This includes existing "hidden"
attributes as well as attributes (such as location attributes) that
require confidentiality.

Included in negotiation techniques are "hint and consent" mechanisms
where the NAS provides a list of algorithms and the server selects
one.
 
3. Proposals MUST support replay protection.  The existing mechanisms
for replay protection are considered adequate and should be maintained.

4. Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each mechanism.

BACKWARD COMPATIBILITY

5. Solutions to the problem MUST demonstrate backward compatibility
with existing RADIUS implementations.  That is, a crypto-agility
solution needs to be able to send packets that a legacy RADIUS client
or server will receive and process successfully.  Similarly, a
crypto-agility solution needs to be capable of receiving and processing
packets from a legacy RADIUS client or server.

6. Crypto-agility solutions MUST avoid security compromise, even
in situations where the existing cryptographic algorithms utilized by
RADIUS implementations are shown to be weak enough to provide little or
no security (e.g. in event of compromise of the "legacy" RADIUS shared
secret). Included in this would be protection against bidding down 
attacks.

INTEROPERABILITY AND CHANGE CONTROL

7. Proposals MUST indicate a willingness to cede change control to
the IETF.

8. Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the
specification.

SCOPE OF WORK

9. Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Challenge, Reject & Accept,
Accounting-Request/Response, and CoA/Disconnect messages.
 
10. Proposals MUST include a Diameter compatibility section, although
it is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is exchanged
with Diameter.
 
11. Crypto-agility solutions SHOULD NOT require fundamental changes to
The RADIUS operational model, such as the introduction of new commands
Or maintenance of state on the RADIUS server.  Similarly, a proposal 
Should focus on the crypto-agility problem and nothing else.  For 
example, proposals should not require new attribute formats or include
definition of new RADIUS services.  Unless modified, the restrictions
in the RADEXT WG charter apply.

Note that for the purposes of this work, the RADEXT WG charter
Restriction against definition of "new security mechanisms" should be
interpreted as prohibiting changes to the basic RADIUS packet format
(e.g. headers), but permits new crypto-algorithms to be substituted
For use in existing security mechanisms.

Regards,

Bernard Aboba
Dave Nelson

RADEXT Co-Chairs




--
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, 22 Mar 2007 08:46:31 +0000
Message-ID: <46024222.4070409@nitros9.org>
Date: Thu, 22 Mar 2007 09:45:22 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Bernard Aboba 
CC:  radiusext@ops.ietf.org
Subject: Re: Proposed Resolution of Issue 223: Event-Timestamp and Duplicate Detection
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Recommendation is to replace that text (which has remained in RFC
> 3576bis) by the following:
> 
> "RADIUS clients implementing this specification
> MUST be capable of detecting a duplicate request if it has the same
> server source IP
> address, source UDP port and Identifier within a short span of time."

  Yes.

  Do we want to mention that clients can have multiple ports open?  The
key I've been using on the client side are (socket, server IP, server
port, Identifier).  On the server side, (socket, client IP, client port,
Identifier).

  I haven't heard of anyone discarding duplicates because they got
confused about client sockets, so maybe adding text to address that
isn't necessary.

> If this is done, then the quoted text above from Section 6.4 becomes
> redundant, and can be replaced by:
> 
> As noted in Section 2.3, duplicate detection is REQUIRED
> for RADIUS clients implementing this specification.

  Yes.

  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, 22 Mar 2007 06:55:20 +0000
Message-ID: 
From: "Bernard Aboba" 
To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org
Bcc: 
Subject: RE: RFC 4590bis Attribute table
Date: Wed, 21 Mar 2007 23:54:35 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

In looking through RFC 4590 again, it seems that only one of the Qop 
attributes is selected by the NAS.  I am assuming that only that attribute 
ends up in the Accounting-Request, so that the entry should actually be 0-1. 
  Is this right?

Bernard Aboba said:
>During IETF 68, it was recommended that review of the revised RFC 4590bis 
>Attribute Table take place on the mailing list.  After looking this over 
>again, here is where I think we are:
>
>Access- Access- Access- Access-    Acct-
>Request Accept  Reject  Challenge  Req   #  Attribute
>0-1      0      0      0          0-1   1  User-Name
>0-1      0      0      1          0    24  State [4]
>1        1      1      1          0-1  80  Message-Authenticator
>0-1      0      0      0          0   103  Digest-Response
>0-1      0      0      1          0-1 104  Digest-Realm
>0-1      0      0      1          0   105  Digest-Nonce
>0        0-1    0      0          0   106  Digest-Response-Auth [1][2]
>0        0-1    0      0          0   107  Digest-Nextnonce
>1        0      0      0          0-1 108  Digest-Method
>0-1      0      0      0          0-1 109  Digest-URI
>0-1      0      0      0+         0+  110  Digest-Qop
>0-1      0      0      0-1        0-1 111  Digest-Algorithm [3]
>0-1      0      0      0          0   112  Digest-Entity-Body-Hash
>0-1      0      0      0          0   113  Digest-CNonce
>0-1      0      0      0          0   114  Digest-Nonce-Count
>0-1      0      0      0          0-1 115  Digest-Username
>0-1      0      0      0-1        0   116  Digest-Opaque
>0+       0+     0      0+         0+  117  Digest-Auth-Param
>0-1      0      0      0          0   118  Digest-AKA-Auts
>0        0      0      0+         0+  119  Digest-Domain
>0        0      0      0-1        0   120  Digest-Stale
>0        0-1    0      0          0   121  Digest-HA1 [1][2]
>0-1      0      0      0          0   122  SIP-AOR
>
>Note that Digest-Qop and Digest-Auth-Param are now 0+ in 
>Accounting-Requests, since it is possible for the server to return more 
>than one value.  There is some question about whether Digest-AKA-Auts can 
>be included in an Accounting-Request; we'll leave this out unless someone 
>thinks that it should be included.
>
>
>
>--
>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, 22 Mar 2007 00:16:54 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: RFC 4590bis Attribute table
Date: Wed, 21 Mar 2007 17:16:06 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

During IETF 68, it was recommended that review of the revised RFC 4590bis 
Attribute Table take place on the mailing list.  After looking this over 
again, here is where I think we are:

Access- Access- Access- Access-    Acct-
Request Accept  Reject  Challenge  Req   #  Attribute
0-1      0      0      0          0-1   1  User-Name
0-1      0      0      1          0    24  State [4]
1        1      1      1          0-1  80  Message-Authenticator
0-1      0      0      0          0   103  Digest-Response
0-1      0      0      1          0-1 104  Digest-Realm
0-1      0      0      1          0   105  Digest-Nonce
0        0-1    0      0          0   106  Digest-Response-Auth [1][2]
0        0-1    0      0          0   107  Digest-Nextnonce
1        0      0      0          0-1 108  Digest-Method
0-1      0      0      0          0-1 109  Digest-URI
0-1      0      0      0+         0+  110  Digest-Qop
0-1      0      0      0-1        0-1 111  Digest-Algorithm [3]
0-1      0      0      0          0   112  Digest-Entity-Body-Hash
0-1      0      0      0          0   113  Digest-CNonce
0-1      0      0      0          0   114  Digest-Nonce-Count
0-1      0      0      0          0-1 115  Digest-Username
0-1      0      0      0-1        0   116  Digest-Opaque
0+       0+     0      0+         0+  117  Digest-Auth-Param
0-1      0      0      0          0   118  Digest-AKA-Auts
0        0      0      0+         0+  119  Digest-Domain
0        0      0      0-1        0   120  Digest-Stale
0        0-1    0      0          0   121  Digest-HA1 [1][2]
0-1      0      0      0          0   122  SIP-AOR

Note that Digest-Qop and Digest-Auth-Param are now 0+ in 
Accounting-Requests, since it is possible for the server to return more than 
one value.  There is some question about whether Digest-AKA-Auts can be 
included in an Accounting-Request; we'll leave this out unless someone 
thinks that it should be included.



--
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, 21 Mar 2007 21:50:42 +0000
Message-ID: 
From: "Bernard Aboba" 
To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org
Bcc: 
Subject: RE: Proposed Resolution of Issue 223: Event-Timestamp and Duplicate Detection
Date: Wed, 21 Mar 2007 14:50:19 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>RADIUS clients implementing this specification MUST be capable of detecting 
>a duplicate request if it has the same source IP
>address, source UDP port and Identifier within a short span of time.

RFC 3576 Section 2.3 contained the following statement:

"The RADIUS client can detect a duplicate request if
it has the same server source IP address and source UDP port and
Identifier within a short span of time."

Recommendation is to replace that text (which has remained in RFC 3576bis) 
by the following:

"RADIUS clients implementing this specification
MUST be capable of detecting a duplicate request if it has the same server 
source IP
address, source UDP port and Identifier within a short span of time."

If this is done, then the quoted text above from Section 6.4 becomes 
redundant, and can be replaced by:

As noted in Section 2.3, duplicate detection is REQUIRED
for RADIUS clients implementing this specification.



--
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, 21 Mar 2007 21:26:22 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: RE: Proposed Resolution of Issue 223: Event-Timestamp and Duplicate Detection
Date: Wed, 21 Mar 2007 14:25:48 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>RADIUS clients implementing this specification MUST be capable of
>detecting a duplicate request if it has the same source IP
>address, source UDP port and Identifier within a short span of time.
>
>On RADIUS clients that support the Event-Timestamp Attribute for replay 
>protection,  the time window used for duplicate detection MUST be the same 
>as the window used to detect stale Event-Timestamp Attributes.

In looking at the original text, it would appear that support for 
Event-Timestamp based replay detection is required on RADIUS clients 
implementing RFC 3576; it is support on servers that is optional.  
Therefore, the second sentence above should probably be:

"The time windows used for duplicate detection MUST be..."



--
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, 21 Mar 2007 21:14:19 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Proposed Resolution of Issue 223: Event-Timestamp and Duplicate Detection
Date: Wed, 21 Mar 2007 14:13:11 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

The WG came to the conclusion at IETF 68 that Event-Timestamp should NOT be 
recalculated on retransmission.  Here are the changes necessary to address 
this issue in RFC 3576bis:

Section 2.3

Delete:

"     Note that if the Event-Timestamp Attribute is included, it will be
      updated when the packet is retransmitted, changing the content of
      the Attributes field and requiring a new Identifier and Request
      Authenticator."

Section 6.4

Change:

"When the Event-Timestamp attribute is present,
both the NAS and the RADIUS server MUST check that the Event-Timestamp
Attribute is current within an acceptable time window.
If the Event-Timestamp Attribute is not
current, then the packet MUST be silently discarded.
This implies the need for loose time
synchronization within the network, which can be achieved
by a variety of means, including SNTP, as described in [RFC4330].

Implementations SHOULD be configurable to discard CoA-Request or
Disconnect-Request packets not containing
an Event-Timestamp attribute.
A default time window of 300 seconds is recommended."

To:

"When the Event-Timestamp attribute is present,
both the NAS and the RADIUS server MUST check that the
Event-Timestamp Attribute is current within an
acceptable time window. If the Event-Timestamp
Attribute is not current, then the packet MUST be silently
discarded.  This implies the need for loose time
synchronization within the network, which can be achieved
by a variety of means, including SNTP, as described in [RFC4330].
Implementations SHOULD be configurable to discard CoA-Request or
Disconnect-Request packets not containing an Event-Timestamp attribute.

If the Event-Timestamp Attribute is included, it represents the time
at which the original packet was sent, and therefore it SHOULD NOT
be updated when the packet is retransmitted.
If the Event-Timestamp attribute is not updated, this implies that the 
Identifier
is not changed in retransmitted packets.  As a result, the ability to detect 
replay
within the time window is dependent on support for duplicate detection 
within
that same window.  RADIUS clients implementing this specification MUST be 
capable of
detecting a duplicate request if it has the same source IP
address, source UDP port and Identifier within a short span of time.

On RADIUS clients that support the Event-Timestamp Attribute for replay
protection,  the time window used for duplicate detection MUST be the
same as the window used to detect stale Event-Timestamp Attributes.
Since the RADIUS Identifier cannot be repeated within the selected time
window, no more than 256 Requests can be accepted within the time
window.  As a result, the chosen time window will depend on the
expected maximum volume of CoA/Disconnect-Requests, so that
unnecessary discards can be avoided.  A default time window of
300 seconds should be adequate in many circumstances."



--
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, 21 Mar 2007 18:29:19 +0000
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NiLuDpL5jln8Vos+VPBDrWLp7RwX/dKaY8GwoMhsC7hgoD9aJQfBl8iCj3M/o87D1spuQ7eo823wUkKeI8mPkjoUxj9aHhmiMb244Rq30rmaxVRzuDj97tcUOc/xnv5k7J5B2ytM0SSlRnKsr+r8KnYcHJpG2Yr53gRJq0lzJxc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nrILg7HQi3DX4KU6dGGwg0lVyodNyva9C4HXAWYTUyuS8cs30GbXqelaDOlI3xW7Z41yUUa+RzYOBPfItsrbj80tIMZLYJTD1+KACcB4RNV70d7bTQwfUlWp+xL8QLFq4leegR5WICRKJRNczQh3FnxtsbYG/6vaPF6xAqN5emg=
Message-ID: 
Date: Wed, 21 Mar 2007 13:47:55 -0300
From: "Claudio Lapidus" 
To: "Avi Lior" 
Subject: Re: RFC 3576bis discussion at IETF 68
Cc: "Alan DeKok" ,  "Bernard Aboba" ,  "radext mailing list" 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Anyway, if we're discussing Event-Timestamp in the context of
retransmissions, it doesn't really matter what happens to the NAS
clock when it reboots.


On 3/21/07, Avi Lior  wrote:
>
>
>
> I wonder how much a problem this really is.
>
>  It should get a time from NNTP at bootup right?
>
> And even if the NAS had a clock drift issue, surely it wouldnt be longer
> then the time it took to reboot and start the RADIUS server.
>
>
> Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
>
>
>  ________________________________
>  From: Alan DeKok
> Sent: Wed 3/21/2007 7:50 AM
> To: Bernard Aboba; radext mailing list
> Subject: Re: RFC 3576bis discussion at IETF 68
>
>
> Bernard Aboba wrote:
> > Also, it was pointed out that Event-Timestamp does not require
> > synchronized clocks, only for the RADIUS server to remember the last
> > value for a given NAS, and to make sure that it is monotonically
> > increasing.
>
>  And when the NAS reboots, and loses its time?
>
>  I'm not sure how to address that.
>
>  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: 
>
>

--
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, 21 Mar 2007 13:03:21 +0000
MIME-Version: 1.0
Subject: RE: RFC 3576bis discussion at IETF 68
From: Avi Lior 
To: Alan DeKok , Bernard Aboba ,  radext mailing list 
Content-Type: multipart/alternative; boundary="_28742F49-BC91-4A32-8C85-34A431956928_"
Message-ID: <07C43B7C-DC00-4F56-817D-F9AC71BD6A56@mimectl>
Date: Wed, 21 Mar 2007 09:03:55 -0400

--_28742F49-BC91-4A32-8C85-34A431956928_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I wonder how much a problem this really is.

 It should get a time from NNTP at bootup right?

And even if the NAS had a clock drift issue, surely it wouldnt be longer th=
en the time it took to reboot and start the RADIUS server.

Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183




From: Alan DeKok
Sent: Wed 3/21/2007 7:50 AM
To: Bernard Aboba; radext mailing list
Subject: Re: RFC 3576bis discussion at IETF 68


Bernard Aboba wrote:
> Also, it was pointed out that Event-Timestamp does not require
> synchronized clocks, only for the RADIUS server to remember the last
> value for a given NAS, and to make sure that it is monotonically
> increasing.

  And when the NAS reboots, and loses its time?

  I'm not sure how to address that.

  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: 

--_28742F49-BC91-4A32-8C85-34A431956928_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






I wonder how muc=
h a problem this really is.


 


 It should get a time from =
NNTP at bootup right?


 


And even if the NAS had a clock =
drift issue, surely it wouldnt be longer then the time it took to reboot an=
d start the RADIUS server.


 




Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
=







From: Alan DeKok
Sent: Wed 3/=
21/2007 7:50 AM
To: Bernard Aboba; radext mailing list
Subj=
ect: Re: RFC 3576bis discussion at IETF 68



Bernard Aboba wrote:
> Also, it was pointed out that Event-Timestamp does not require
> synchronized clocks, only for the RADIUS server to remember the last
> value for a given NAS, and to make sure that it is monotonically
> increasing.

  And when the NAS reboots, and loses its time?

  I'm not sure how to address that.

  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: <http://psg.com/lists/radiusext/>



--_28742F49-BC91-4A32-8C85-34A431956928_--

--
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, 21 Mar 2007 12:57:15 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Request for RADIUS crypto-agility solutions
Date: Wed, 21 Mar 2007 05:56:59 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

This is a formal request for submission of documents solving the RADIUS 
crypto-agility problem.  Proposers should send an email to the RADEXT WG 
list providing a pointer to their proposal by April 21, 2007.   Once the 
proposals have been submitted, we will initiate WG review.

A revised requirements list incorporating discussion at IETF 68 will be 
posted ASAP.



--
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, 21 Mar 2007 12:51:22 +0000
Subject: RE: Publication of RADIUS Prepaid Document
Mime-Version: 1.0
From: Avi Lior 
To: Bernard Aboba , 
Content-Type: multipart/alternative; boundary="_3E7659CE-141A-4A84-A278-6D853672B6FE_"
Message-ID: <9B7FA996-88FE-4D61-9531-1596E6060290@mimectl>
Date: Wed, 21 Mar 2007 08:52:15 -0400

--_3E7659CE-141A-4A84-A278-6D853672B6FE_
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As one of the Authors, I have no problems with this. =20

I will let the other Authors speak for themselves.

Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183




From: Bernard Aboba
Sent: Wed 3/21/2007 6:26 AM
To: radiusext@ops.ietf.org
Subject: Publication of RADIUS Prepaid Document


At IETF 68, it was suggested that the RADIUS Prepaid document be published=
=20
as an Informational RFC documenting existing usage (presumably based on=20
RADIUS VSAs).   This would enable us to unblock the document, since=20
conformance to the Guidelines document (still in progress) would no longer=
=20
be required.

Are there any objections to this approach?



--
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: 

--_3E7659CE-141A-4A84-A278-6D853672B6FE_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






As one of the Au=
thors, I have no problems with this.  


 


I will let the other Authors spe=
ak for themselves.


 




Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
=







From: Bernard Aboba
Sent: Wed=
 3/21/2007 6:26 AM
To: radiusext@ops.ietf.org
Subject: =
Publication of RADIUS Prepaid Document



At IETF 68, it was suggested that=
 the RADIUS Prepaid document be published=20
as an Informational RFC documenting existing usage (presumably based on=20
RADIUS VSAs).   This would enable us to unblock the document, since=20
conformance to the Guidelines document (still in progress) would no longer=
=20
be required.

Are there any objections to this approach?



--
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/>



--_3E7659CE-141A-4A84-A278-6D853672B6FE_--

--
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, 21 Mar 2007 12:48:03 +0000
Subject: RE: Issue 215
Mime-Version: 1.0
From: Avi Lior 
To: Bernard Aboba , 
Content-Type: multipart/alternative; boundary="_948B0DEB-1181-408A-8BA3-764D2AC7BA62_"
Message-ID: <462DE544-3790-422F-BE0B-AA4296FF517E@mimectl>
Date: Wed, 21 Mar 2007 08:48:05 -0400

--_948B0DEB-1181-408A-8BA3-764D2AC7BA62_
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

See inline.

Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183




From: Bernard Aboba
Sent: Wed 3/21/2007 8:24 AM
To: radiusext@ops.ietf.org
Subject: RE: Issue 215


To:
   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a CoA-Request containing a Service-
   Type value of "Authorize-Only" but lacking a State attribute MUST
   send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
   attribute with value 402 (Missing Attribute).

[BA] I think that "or Disconnect-NAK" should be deleted here, since that=20
won't be sent in response to a CoA-Request.

[Avi] Yes I agree. I have missed that one.
To:
      "Unsupported Service" is a fatal error sent if a Service-Type
      Attribute included with the Request is sent with an invalid or
      unsupported value.  Only valid when performing Change of
      Authorization.

[BA] How about if we say "This error cannot be sent in response to a=20
Disconnect-Request." for the last sentence?
[Avi] Works for me.

In Appendix A - Changes from RFC 3576
**************************************

Add:

Disallowed usage of Service-Type and State attribute in
Disconnect-Message

[BA] How about:

   o Use of a Service-Type Attribute within a Disconnect-Request is=20
prohibited (Section 4).


[Avi] Again, works for me.

--
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: 

--_948B0DEB-1181-408A-8BA3-764D2AC7BA62_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






See inline.


 




Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
=







From: Bernard Aboba
Sent: Wed=
 3/21/2007 8:24 AM
To: radiusext@ops.ietf.org
Subject: =
RE: Issue 215



To:
   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a CoA-Request containing a Service-
   Type value of "Authorize-Only" but lacking a State attribute MUST
   send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
   attribute with value 402 (Missing Attribute).

[BA] I think that "or Disconnect-NAK" should be deleted here, since that=20
won't be sent in response to a CoA-Request.

[Avi] Yes I agree. I have missed=
 that one.
To:
      "Unsupported Service" is a fatal error sent if a Service-Type
      Attribute included with the Request is sent with an invalid or
      unsupported value.  Only valid when performing Change of
      Authorization.

[BA] How about if we say "This error cannot be sent in response to a=20
Disconnect-Request." for the last sentence?
[Avi] Works for me.

In Appendix A - Changes from RFC 3576
**************************************

Add:

Disallowed usage of Service-Type and State attribute in
Disconnect-Message

[BA] How about:

   o Use of a Service-Type Attribute within a Disconnect-Request is=20
prohibited (Section 4).


[Avi] Again, works for me.

--
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/>



--_948B0DEB-1181-408A-8BA3-764D2AC7BA62_--

--
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, 21 Mar 2007 12:25:04 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: RE: Issue 215
Date: Wed, 21 Mar 2007 05:24:44 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

To:
   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a CoA-Request containing a Service-
   Type value of "Authorize-Only" but lacking a State attribute MUST
   send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
   attribute with value 402 (Missing Attribute).

[BA] I think that "or Disconnect-NAK" should be deleted here, since that 
won't be sent in response to a CoA-Request.

To:
      "Unsupported Service" is a fatal error sent if a Service-Type
      Attribute included with the Request is sent with an invalid or
      unsupported value.  Only valid when performing Change of
      Authorization.

[BA] How about if we say "This error cannot be sent in response to a 
Disconnect-Request." for the last sentence?

In Appendix A - Changes from RFC 3576
**************************************

Add:

Disallowed usage of Service-Type and State attribute in
Disconnect-Message

[BA] How about:

   o Use of a Service-Type Attribute within a Disconnect-Request is 
prohibited (Section 4).



--
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, 21 Mar 2007 12:19:06 +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: Closure of Traffic-Rule Issues
Date: Wed, 21 Mar 2007 13:18:46 +0100
Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301A40175@SEHAN021MB.tcad.telia.se>
Thread-Topic: Closure of Traffic-Rule Issues
Thread-Index: Acdro8JNxmJ+RliIRg2ICxSa14WxawADzF9g
From: 
To: , 

Sounds reasonable.=20

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org=20
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: 21. maaliskuuta 2007 12:28
> To: radiusext@ops.ietf.org
> Subject: Closure of Traffic-Rule Issues
>=20
> At IETF 68, we discussed how to close the remaining issues on the=20
> Traffic-Rule document.   Mauricio will email proposed=20
> resolutions to the=20
> list and the original submitters, and if he does not get a=20
> response suggesting that additional changes are necessary, we=20
> will close all existing issues and bring the document to=20
> RADEXT WG last call.
>=20
> Any objections to this approach?
>=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: Wed, 21 Mar 2007 11:51:08 +0000
Message-ID: <46011C05.2000007@nitros9.org>
Date: Wed, 21 Mar 2007 12:50:29 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Bernard Aboba ,  radext mailing list 
Subject: Re: RFC 3576bis discussion at IETF 68
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Also, it was pointed out that Event-Timestamp does not require
> synchronized clocks, only for the RADIUS server to remember the last
> value for a given NAS, and to make sure that it is monotonically
> increasing.

  And when the NAS reboots, and loses its time?

  I'm not sure how to address that.

  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: Wed, 21 Mar 2007 11:45:05 +0000
Message-ID: 
From: "Bernard Aboba" 
To: pcalhoun@cisco.com, radiusext@ops.ietf.org
Bcc: 
Subject: RE: RFC 3576bis discussion at IETF 68
Date: Wed, 21 Mar 2007 04:44:47 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

The Nonce attribute wasn't included in RFC 3576, so I don't think there's a 
backwards compatibility issue.


>From: "Pat Calhoun (pacalhou)" 
>To: "Bernard Aboba" , 
>Subject: RE: RFC 3576bis discussion at IETF 68
>Date: Wed, 21 Mar 2007 04:33:39 -0700
>
>Is the cost of breaking backward compatibility worth the removal of the 
>Nonce attribute?
>
>
>PatC
>
>  -----Original Message-----
>From: 	Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>Sent:	Wednesday, March 21, 2007 03:25 AM Pacific Standard Time
>To:	radiusext@ops.ietf.org
>Subject:	RFC 3576bis discussion at IETF 68
>
>As part of the RFC 3576bis discussion, it was suggested that RFC 3576bis
>remove mention of the Nonce attribute, since this did not really address
>replay protection.  Also, it should be clarified that the Event-Timestamp
>attribute does NOT require changing the Identifier on a retransmision; the
>Event-Timestamp refers to the time of the original transmission, and
>therefore does not need to change on a re-transmission.
>
>Also, it was pointed out that Event-Timestamp does not require synchronized
>clocks, only for the RADIUS server to remember the last value for a given
>NAS, and to make sure that it is monotonically increasing.
>
>Any objections to implementing these suggestions in RFC 3576bis-01?
>
>
>
>--
>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: Wed, 21 Mar 2007 11:34:22 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76BAC.C5AC45D5"
Subject: RE: RFC 3576bis discussion at IETF 68
Date: Wed, 21 Mar 2007 04:33:39 -0700
Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2036D3E73@xmb-sjc-235.amer.cisco.com>
Thread-Topic: RFC 3576bis discussion at IETF 68
Thread-Index: AcdrozpiVkqw+Pm7S9yVYmHMrnaNuQACYs8f
From: "Pat Calhoun \(pacalhou\)" 
To: "Bernard Aboba" , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3387; t=1174476820; x=1175340820; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pcalhoun@cisco.com; z=From:=20=22Pat=20Calhoun=20\(pacalhou\)=22=20 |Subject:=20RE=3A=20RFC=203576bis=20discussion=20at=20IETF=2068 |Sender:=20; bh=hEANek23rFxxzKo5ojynDYoDS6leR5uFUPcE1QEdNjg=; b=X1eR6wTBDlbTELxbC0UHghjyYyH9oDoVvhLszzzxDBwwNsAFminm/Q8bYXAICWFDhwNFHb96 Cd0SzucD6yV9e/Ra0/jP1yRn+x2rRPcsM+NACUBvxUpiKAYKR0jC4nARV7wVJP8ISwZN53U0K+ vJgmzu8vNsCadhubrhNZEYk2o=;
Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76BAC.C5AC45D5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is the cost of breaking backward compatibility worth the removal of the =
Nonce attribute?


PatC

 -----Original Message-----
From: 	Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent:	Wednesday, March 21, 2007 03:25 AM Pacific Standard Time
To:	radiusext@ops.ietf.org
Subject:	RFC 3576bis discussion at IETF 68

As part of the RFC 3576bis discussion, it was suggested that RFC 3576bis =

remove mention of the Nonce attribute, since this did not really address =

replay protection.  Also, it should be clarified that the =
Event-Timestamp=20
attribute does NOT require changing the Identifier on a retransmision; =
the=20
Event-Timestamp refers to the time of the original transmission, and=20
therefore does not need to change on a re-transmission.

Also, it was pointed out that Event-Timestamp does not require =
synchronized=20
clocks, only for the RADIUS server to remember the last value for a =
given=20
NAS, and to make sure that it is monotonically increasing.

Any objections to implementing these suggestions in RFC 3576bis-01?



--
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_001_01C76BAC.C5AC45D5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




RE: RFC 3576bis discussion at IETF 68








------_=_NextPart_001_01C76BAC.C5AC45D5--

--
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, 21 Mar 2007 10:31:08 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: RFC 4590bis discussion
Date: Wed, 21 Mar 2007 03:30:57 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

At IETF 68, there was discussion of the Attribute table with respect to what 
attributes can be placed in Accounting-Request packets:


Access- Access- Access- Access-    Acct-
Request Accept  Reject  Challenge  Req   #  Attribute
0-1      0      0      0          0-1   1  User-Name
0-1      0      0      1          0    24  State [4]
1        1      1      1          0-1  80  Message-Authenticator
0-1      0      0      0          0   103  Digest-Response
0-1      0      0      1          0-1 104  Digest-Realm
0-1      0      0      1          0   105  Digest-Nonce
0        0-1    0      0          0   106  Digest-Response-Auth [1][2]
0        0-1    0      0          0   107  Digest-Nextnonce
1        0      0      0          0-1 108  Digest-Method
0-1      0      0      0          0-1 109  Digest-URI
0-1      0      0      0+         0-1 110  Digest-Qop
0-1      0      0      0-1        0-1 111  Digest-Algorithm [3]
0-1      0      0      0          0   112  Digest-Entity-Body-Hash
0-1      0      0      0          0   113  Digest-CNonce
0-1      0      0      0          0   114  Digest-Nonce-Count
0-1      0      0      0          0-1 115  Digest-Username
0-1      0      0      0-1        0   116  Digest-Opaque
0+       0+     0      0+         0   117  Digest-Auth-Param
0-1      0      0      0          0   118  Digest-AKA-Auts
0        0      0      0+         0-1 119  Digest-Domain
0        0      0      0-1        0   120  Digest-Stale
0        0-1    0      0          0   121  Digest-HA1 [1][2]
0-1      0      0      0          0   122  SIP-AOR

The discussion seems to indicate that Digest-Auth-Param and Digest-AKA-Auts 
mght also be possibly included in Accounting-Request packets.

Are there comments on this?  Should these entries be changed to 0-1 in 
Accounting-Requests?



--
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, 21 Mar 2007 10:28:20 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Closure of Traffic-Rule Issues
Date: Wed, 21 Mar 2007 03:28:14 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

At IETF 68, we discussed how to close the remaining issues on the 
Traffic-Rule document.   Mauricio will email proposed resolutions to the 
list and the original submitters, and if he does not get a response 
suggesting that additional changes are necessary, we will close all existing 
issues and bring the document to RADEXT WG last call.

Any objections to this approach?



--
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, 21 Mar 2007 10:27:00 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Publication of RADIUS Prepaid Document
Date: Wed, 21 Mar 2007 03:26:47 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

At IETF 68, it was suggested that the RADIUS Prepaid document be published 
as an Informational RFC documenting existing usage (presumably based on 
RADIUS VSAs).   This would enable us to unblock the document, since 
conformance to the Guidelines document (still in progress) would no longer 
be required.

Are there any objections to this approach?



--
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, 21 Mar 2007 10:25:16 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: RFC 3576bis discussion at IETF 68
Date: Wed, 21 Mar 2007 03:25:00 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

As part of the RFC 3576bis discussion, it was suggested that RFC 3576bis 
remove mention of the Nonce attribute, since this did not really address 
replay protection.  Also, it should be clarified that the Event-Timestamp 
attribute does NOT require changing the Identifier on a retransmision; the 
Event-Timestamp refers to the time of the original transmission, and 
therefore does not need to change on a re-transmission.

Also, it was pointed out that Event-Timestamp does not require synchronized 
clocks, only for the RADIUS server to remember the last value for a given 
NAS, and to make sure that it is monotonically increasing.

Any objections to implementing these suggestions in RFC 3576bis-01?



--
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, 21 Mar 2007 10:11:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76BA1.24DAECE1"
Subject: Remove replay protection stuff from cryptoagility reqs.
Date: Wed, 21 Mar 2007 03:10:24 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503A565DF@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Remove replay protection stuff from cryptoagility reqs.
Thread-Index: AcdroSQFmiRi+wsfQYmsvtqnN5nqcQ==
From: "Glen Zorn \(gwz\)" 
To: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1178; t=1174471826; x=1175335826; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20Remove=20replay=20protection=20stuff=20from=20cryptoagility=2 0reqs. |Sender:=20; bh=pBwKXdiALFXq9iDp8oS07YZ69AEXf3uy8whGw49v5ik=; b=ZPmj0CTBmz4KpwT6Mr171lwPUuMCSBm4BOX4476ZknEQ9esqGFpBQixvgX9kNhNvTIWoxT4W 4sXc7y9bHXFEyjbdzoTZEuKL6kswi+cVoSH/pHlrBVOUS7gulauYeta8;
Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76BA1.24DAECE1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think that it would be appropriate to remove the mention of the
inadequacy of replay protection in RADIUS from the crypto-agility
requirements, since the replay protection does not, in fact, appear to
be inadequate.


------_=_NextPart_001_01C76BA1.24DAECE1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Remove replay protection stuff from cryptoagility reqs.





I think that it would be appropriate to =
remove the mention of the inadequacy of replay protection in RADIUS from =
the crypto-agility requirements, since the replay protection does not, =
in fact, appear to be inadequate.




------_=_NextPart_001_01C76BA1.24DAECE1--

--
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, 21 Mar 2007 06:59:44 +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: REMINDER:  Consideration of draft-lior-radius-attribute-type-extension-01
Date: Tue, 20 Mar 2007 23:58:11 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503A565CD@xmb-sjc-215.amer.cisco.com>
Thread-Topic: REMINDER:  Consideration of draft-lior-radius-attribute-type-extension-01
Thread-Index: AcdrR7HDLlIPKUlyTjudpnw4ix6fawAPnGKA
From: "Glen Zorn \(gwz\)" 
To: "Bernard Aboba" 
Cc: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2783; t=1174460293; x=1175324293; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20REMINDER=3A=20=20Consideration=20of=20draft-lior-radi us-attribute-type-extension-01 |Sender:=20; bh=WrskgHpa6GPFiUOZViuJ4CCKcbGzxb5OGEbwCxZtN94=; b=eTD4stYQiTgctMOeJY0SitOzDVb3okiqW50MF173ZMIugguqkk7GnV1k/Av/j/3gqfaSdcOK UVnDImmRfs9hylALkI8dLZI51QElYDhpL09CaIywWK3I2icYHZx80ufE;
Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; );

Bernard Aboba <> allegedly scribbled on Tuesday, March 20, 2007 4:29 PM:

> On December 5, 2006 a call for review of the RADIUS extended
> attribute document was issued to the RADEXT WG as well as other IETF
> WGs affected by the document: =20
> http://ops.ietf.org/lists/radiusext/2006/msg01002.html
>=20
> Unfortunately, no review comments were received relating to this
> document.=20
>=20
> Given that the call for review occurred during the holiday season,we
> are reissuing the call for review.=20

I think that it's a wonderful idea! ;-)

>=20
>
------------------------------------------------------------------------
---
>=20
> The RADEXT WG has a charter deliverable for an extended form of
> RADIUS attribute.  The apparent consensus in the WG is to solve a
> very simple set of problems in this space, including the pending
> exhaustion of the standard RADIUS attribute IDs, a consistent
> mechanism for application layer fragmentation and reassembly for
> Diameter interoperability, and a consistent mechanism for grouping of
> attributes for data structuring, also for Diameter interoperability.=20
>=20
> Given the list of proposed work in RADEXT and other IETF WGs with
> RADIUS extensions work on their charters, it is conceivable that we
> might exhaust the existing IANA RADIUS registry for Attribute Types
> fairly soon.  =20
> Therefore, this work is considered to be of some urgency.
>=20
> The structure of the extended attribute format currently under
> consideration may require changes in various RADIUS extensions drafts
> in RADEXT and other =20
> working groups.   This assumes that at least some of these documents
> will=20
> ultimately use the RADIUS extended attribute allocations.
>=20
> The RADEXT WG Chairs are requesting that the RADEXT WG and all other
> affected WGs please review the following document:=20
>=20
>
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-01.txt
>=20
> Please comment as to whether this document is ready for adoption as a
> RADEXT WG work item, and provide comments as to suggested changes or
> mprovements by sending email to radiusext@ops.ietf.org.  Please use
> the RADEXT Issue Tracker format template, found at:  =20
>=20
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> and submit your comments to the RADEXT WG mailing list with the
> keyword "New Issue" in the subject header.=20
>=20
> Please respond by April 10, 2006.  Once all the resultant open issues
> have been resolved, the RADEXT WG Chairs expect that a WGLC will be
> issued on the revised draft soon thereafter. =20
>=20
> Thank you, in advance, for your timely review.
>=20
> Regards,
>=20
> Dave Nelson
> Bernard Aboba
>=20
> Co-Chairs, RADEXT WG

--
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, 21 Mar 2007 00:15:27 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Slides for IETF 68
Date: Tue, 20 Mar 2007 17:15:19 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

The slides for the RADEXT WG meeting at IETF 68 are now available online 
here:

http://www.drizzle.com/~aboba/IETF68/RADEXT/



--
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, 21 Mar 2007 00:13:37 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: REMINDER: Consideration of draft-lior-radius-attribute-type-extension-01
Date: Tue, 20 Mar 2007 17:13:17 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

On December 5, 2006 a call for review of the RADIUS extended attribute 
document was issued to the RADEXT WG as well as other IETF WGs affected by 
the document:
http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this document.

Given that the call for review occurred during the holiday season,we are 
reissuing the call for review.

---------------------------------------------------------------------------

The RADEXT WG has a charter deliverable for an extended form of RADIUS 
attribute.  The apparent consensus in the WG is to solve a very simple set 
of problems in this space, including the pending exhaustion of the standard 
RADIUS attribute IDs, a consistent mechanism for application layer 
fragmentation and reassembly for Diameter interoperability, and a consistent 
mechanism for grouping of attributes for data structuring, also for Diameter 
interoperability.

Given the list of proposed work in RADEXT and other IETF WGs with RADIUS 
extensions work on their charters, it is conceivable that we might exhaust 
the existing IANA RADIUS registry for Attribute Types fairly soon.  
Therefore, this work is considered to be of some urgency.

The structure of the extended attribute format currently under consideration 
may require changes in various RADIUS extensions drafts in RADEXT and other 
working groups.   This assumes that at least some of these documents will 
ultimately use the RADIUS extended attribute allocations.

The RADEXT WG Chairs are requesting that the RADEXT WG and all other 
affected WGs please review the following document:

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-01.txt

Please comment as to whether this document is ready for adoption as a RADEXT 
WG work item, and provide comments as to suggested changes or mprovements by 
sending email to radiusext@ops.ietf.org.  Please use the RADEXT Issue 
Tracker format template, found at:

http://www.drizzle.com/~aboba/RADEXT/

and submit your comments to the RADEXT WG mailing list with the keyword
"New Issue" in the subject header.

Please respond by April 10, 2007.  Once all the resultant open issues  have 
been resolved, the RADEXT WG Chairs expect that a WGLC will be issued on the 
revised draft soon thereafter.

Thank you, in advance, for your timely review.

Regards,

Dave Nelson
Bernard Aboba
Co-Chairs, RADEXT WG



--
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, 20 Mar 2007 23:30:05 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: REMINDER:  Consideration of draft-lior-radius-attribute-type-extension-01
Date: Tue, 20 Mar 2007 16:29:04 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

On December 5, 2006 a call for review of the RADIUS extended attribute 
document was issued to the RADEXT WG as well as other IETF WGs affected by 
the document:
http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this document.

Given that the call for review occurred during the holiday season,we are 
reissuing the call for review.

---------------------------------------------------------------------------

The RADEXT WG has a charter deliverable for an extended form of RADIUS 
attribute.  The apparent consensus in the WG is to solve a very simple set 
of problems in this space, including the pending exhaustion of the standard 
RADIUS attribute IDs, a consistent mechanism for application layer 
fragmentation and reassembly for Diameter interoperability, and a consistent 
mechanism for grouping of attributes for data structuring, also for Diameter 
interoperability.

Given the list of proposed work in RADEXT and other IETF WGs with RADIUS 
extensions work on their charters, it is conceivable that we might exhaust 
the existing IANA RADIUS registry for Attribute Types fairly soon.  
Therefore, this work is considered to be of some urgency.

The structure of the extended attribute format currently under consideration 
may require changes in various RADIUS extensions drafts in RADEXT and other 
working groups.   This assumes that at least some of these documents will 
ultimately use the RADIUS extended attribute allocations.

The RADEXT WG Chairs are requesting that the RADEXT WG and all other 
affected WGs please review the following document:

http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-01.txt

Please comment as to whether this document is ready for adoption as a RADEXT 
WG work item, and provide comments as to suggested changes or mprovements by 
sending email to radiusext@ops.ietf.org.  Please use the RADEXT Issue 
Tracker format template, found at:

http://www.drizzle.com/~aboba/RADEXT/

and submit your comments to the RADEXT WG mailing list with the keyword
"New Issue" in the subject header.

Please respond by April 10, 2006.  Once all the resultant open issues
have been resolved, the RADEXT WG Chairs expect that a WGLC will be
issued on the revised draft soon thereafter.

Thank you, in advance, for your timely review.

Regards,

Dave Nelson
Bernard Aboba

Co-Chairs, RADEXT WG



--
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, 20 Mar 2007 09:42:29 +0000
Message-ID: <45FFAC39.8090609@nitros9.org>
Date: Tue, 20 Mar 2007 10:41:13 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Bernard Aboba 
CC:  radiusext@ops.ietf.org
Subject: Re: Review of RFC 4590bis
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Is there any need for Digest-Qop or Digest-Algorithm?

  Sure, for informational purposes.  It may be useful also to have some
attributes appear in Accounting-Start, but not in later interim update
packets.

> Personally, I can't see why any digest attributes would be included in a
> CoA-Request or Disconnect-Request.

  OK.

  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: Tue, 20 Mar 2007 04:05:35 +0000
Date: Tue, 20 Mar 2007 00:04:13 -0400
From: Barney Wolff 
To: radiusext@ops.ietf.org
Subject: Backus obit
Message-ID: <20070320040413.GA49976@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)

I see on nytimes.com that John Backus died Saturday at 82.  Given our
reliance on ABNF, perhaps a moment of silence on the list is appropriate.

Those of us so old that Fortran was our first computer language have
an additional reason to mourn.

A reminder that the giants on whose shoulders we stand are mortal.
Regards,
Barney

-- 
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: Mon, 19 Mar 2007 17:40:09 +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: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Date: Mon, 19 Mar 2007 10:39:45 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625039F5F2C@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Thread-Index: AcdqD9VPNSzGff05SjW6S1RSTErXowAEJNMwAActDAAAA/s2sA==
From: "Glen Zorn \(gwz\)" 
To: "Sanchez, Mauricio \(ProCurve\)" 
Cc: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2138; t=1174325997; x=1175189997; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Extended=20Filter=20attribute=3A=20=20Change=20summar y=20from=20-01=20to=2002=3B=20Issues=20score=20card=20review |Sender:=20; bh=co9b69WTDvc91CuL576r9IjkjrSzkMu/sHzpedOY2X8=; b=EF7cNLnoc+SNNRrwegSv7/gFqqtM+AMfi2/1/UzO4XuJ7Ek2y7NEL8lk6U+WHP85lK2sEzAv XzyXA1lbTkD3KkxrNUGuKbDNhp5vhO5i0MfAudZ3Z7Pfef0owykyQRoM;
Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; );

Sanchez, Mauricio (ProCurve)  allegedly
scribbled on Monday, March 19, 2007 8:51 AM:

> Glen proclaimed...

Proclaimed? ;-)

>=20
>> -----Original Message-----
>>> 3. Added a version label prefix to rule syntax.  Each rule now
>>> includes a "v1" prefix designating the rule as conforming to version
>>> 1 of traffic-rule syntax.  The idea here is to allow future
>>> updates/changes to the rule syntax without having to define another
>>> attribute and burn another type number.
>>=20
>> I was under the impression that we had decided to use the new
>> extended attribute format for this, thus obviating the concern about
>> 'burning another type number'.
>=20
> [MS1] Well, even if consuming type is no longer an issue, wouldn't
> you agree that it would be cleaner to modify the same attribute than
> defining an entirely new attribute every time a rule syntax update
> was necessary?  =20

Absolutely; I think that a "grouped AVP" type of thing might make that
even easier...

>=20
>=20
>>> 4. Re-did the Diameter Considerations section [5].  Now are using
>>> the same approach employed by rfc4675 (RADIUS attributes for virtual
>>> LAN and priority support).  The approach eliminates the need to
>>> re-create a diameter-specific version of nas-traffic-rule and rather
>>> relies on the general radius<->diameter interoperability mechanisms.
>>> I do have a question as to whether the diameter value type specified
>>> (OctetString) is the right one or not.  I'm no diameter value type
>>> expert, so feedback welcome.
>>=20
>> A far better idea would be to get rid of the OS-specific Diameter
>> stuff & define an extensible grouped AVP for filters.
>=20
> [MS1] Can you described the pain point(s) you're experiencing with
> Diameter's current syntax approach?  I guess I question whether
> Diameter's chosen approach is truly broken enough to merit a complete
> re-write.  =20

Basically the same thing you mentioned above: using a string means you
have to create a new AVP every time you need to filter something else. =20

>=20
> Cheers,
> MS

--
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, 19 Mar 2007 17:32:55 +0000
Message-ID: 
From: "Bernard Aboba" 
To: aland@nitros9.org
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: Re: Review of RFC 4590bis
Date: Mon, 19 Mar 2007 10:32:32 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>   It would be useful to have the following attributes in
>Accounting-Request packets:
>
>   Digest-Method, Digest-Realm, Digest-Domain, Digest-Username and
>Digest-URI.
>
>   i.e. the User-Name is in accounting packets now, so it would be useful
>to have Digest-Username && associated attributes, too.

Is there any need for Digest-Qop or Digest-Algorithm?

>   As for CoA-Request, I'm not sure which attributes would be included.
>Maybe a statement saying the digest attributes may/may not be included,
>and give reasons?

Personally, I can't see why any digest attributes would be included in a 
CoA-Request or Disconnect-Request.



--
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, 19 Mar 2007 17:23:52 +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-rules-01 & Issue 192
Date: Mon, 19 Mar 2007 18:23:19 +0100
Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301A4015F@SEHAN021MB.tcad.telia.se>
Thread-Topic: Filter-rules-01 & Issue 192
Thread-Index: AccE8jWDqHfTTRcPTs+qxqshRGUcBBlHcMfAAAOiFFAABtzgMAACESFg
From: 
To: 
Cc: 

Hi,

See inline marked with [JiK]..

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20
> Sent: 19. maaliskuuta 2007 17:41
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; radiusext@ops.ietf.org
> Subject: RE: Filter-rules-01 & Issue 192
>=20
>=20
> Jouni writes...
>=20
> > -----Original Message-----
> > > [MS1]  There may actually be more than one rule per attribute.=20
> > > Another interesting case is when one rule is split across two=20
> > > attributes (due to length).  What if we added the following to in=20
> > > the description section?
> > > "A NAS-Traffic-Rule attribute may contain a partial rule,=20
> one rule,=20
> > > or more than one rule. Traffic rules may be contained across=20
> > > attribute boundaries, so implementations cannot assume that=20
> > > individual traffic rules begin or end on attribute boundaries."
> >=20
> > [JiK] The proposed text is OK. Just wondering whether the=20
> ABNF is up=20
> > to date with the above text. I could be wrong but to me it=20
> appears the=20
> > the ABNF cannot support more than one rule per attribute.
>=20
> [MS2] Are you thinking that we should replace the following,
>=20
> " ; Start of ABNF description of NAS-Traffic-Rule       =20
>          rule           =3D  "v1" " " (flush-rule / permit-all-rule =20
>                            / l2-filter-rule / l2-tunnel-rule=20
>                            / ip-filter-rule / ip-tunnel-rule =20
>                            / http-filter-rule / http-redir-rule) =20
>                            rule-delim"
> with
>=20
> " ; Start of ABNF description of NAS-Traffic-Rule=20
> 	   rule-list      =3D rule *(rule)
>          rule           =3D  "v1" " " (flush-rule / permit-all-rule =20
>                            / l2-filter-rule / l2-tunnel-rule=20
>                            / ip-filter-rule / ip-tunnel-rule =20
>                            / http-filter-rule / http-redir-rule) =20
>                            rule-delim"
>=20
> =20

[JiK] Yes. Is there a particular reason to add a trailing rule-delim if
there is only a single rule? If not maybe the example below would work:

	   rule-list      =3D  rule
         rule-list      =3D/ rule-list rule-delim rule
         rule           =3D  "v1" " " (flush-rule / permit-all-rule =20
                           / l2-filter-rule / l2-tunnel-rule=20
                           / ip-filter-rule / ip-tunnel-rule =20
                           / http-filter-rule / http-redir-rule) =20
 =20
> > > [MS1] Ok.  How about the following in the intro?
> > > "Layer 2 filters are useful in filtering BPDU traffic for which=20
> > > layer 3 filters have no effect."
> > >
> > > We may also consider adding BPDU to the terminology section.
> >=20
> > [JiK] Thanks.. and I think it would be good to add the BPDU to the=20
> > terminology section.
>=20
> [MS2] Ok. =20
> =20
> > And then one more nit. Aren't we supposed to use=20
> example.com for all=20
> > example domain names? Now there are goo.org etc ;)
>=20
> [MS2] Dunno. You're probably right. I've been searching for=20
> an RFC that describes formatting for URLs, but haven't found any. =20

[JiK] RFC2606 I guess..

Cheers,
	Jouni

>=20
> Cheers,
> MS=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: 


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 19 Mar 2007 15:52:07 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Date: Mon, 19 Mar 2007 15:51:18 -0000
Content-Type: multipart/signed; boundary="----=_NextPart_000_0065_01C76A46.D0BAB360"; protocol="application/x-pkcs7-signature"; micalg=SHA1
Message-ID: <2F2D38A4B8346F48A683750A46BAB2110130D809@G3W0072.americas.hpqcorp.net>
Thread-Topic: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Thread-Index: AcdqD9VPNSzGff05SjW6S1RSTErXowAEJNMwAActDAA=
From: "Sanchez, Mauricio (ProCurve)" 
To: "Glen Zorn (gwz)" 
Cc: 

This is a multipart message in MIME format.

------=_NextPart_000_0065_01C76A46.D0BAB360
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Glen proclaimed...

> -----Original Message-----
> > 3. Added a version label prefix to rule syntax.  Each rule now
> > includes a "v1" prefix designating the rule as conforming to version
> > 1 of traffic-rule syntax.  The idea here is to allow future
> > updates/changes to the rule syntax without having to define another
> > attribute and burn another type number.
> 
> I was under the impression that we had decided to use the new extended
> attribute format for this, thus obviating the concern about 'burning
> another type number'.

[MS1] Well, even if consuming type is no longer an issue, wouldn't you agree
that it would be cleaner to modify the same attribute than defining an
entirely new attribute every time a rule syntax update was necessary?


> > 4. Re-did the Diameter Considerations section [5].  Now are using the
> > same approach employed by rfc4675 (RADIUS attributes for virtual LAN
> > and priority support).  The approach eliminates the need to re-create
> > a diameter-specific version of nas-traffic-rule and rather relies on
> > the general radius<->diameter interoperability mechanisms.  I do have
> > a question as to whether the diameter value type specified
> > (OctetString) is the right one or not.  I'm no diameter value type
> > expert, so feedback welcome.
> 
> A far better idea would be to get rid of the OS-specific Diameter stuff
> & define an extensible grouped AVP for filters.

[MS1] Can you described the pain point(s) you're experiencing with
Diameter's current syntax approach?  I guess I question whether Diameter's
chosen approach is truly broken enough to merit a complete re-write.

Cheers,
MS

------=_NextPart_000_0065_01C76A46.D0BAB360
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMxOTE1NTExOFowIwYJ
KoZIhvcNAQkEMRYEFPjLFPSuVtN3LMi1EBTAg2rQnOo9MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK
ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu
MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp
CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th
cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy
bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT
J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi
b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG
9w0BAQEFAASBgIjUfext2DMGnLniIazw5PSbeOsV6GDGG6hILsUcxq0k5pOhnFpe+GgxfjhnhMtf
9fWOvKqe9Bq7LQW9iyPbpehvWXfjJpvpLX9aPqOVaW4KWBa7U0WJJ+nMsBC89OdshLOFfHrjI4Hl
7Vq4ozhSWmM6wcCO7hZF7jerKqshmxbZAAAAAAAA

------=_NextPart_000_0065_01C76A46.D0BAB360--

--
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, 19 Mar 2007 15:41:53 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Filter-rules-01 & Issue 192
Date: Mon, 19 Mar 2007 15:40:30 -0000
Content-Type: multipart/signed; boundary="----=_NextPart_000_0060_01C76A45.4E8ED660"; protocol="application/x-pkcs7-signature"; micalg=SHA1
Message-ID: <2F2D38A4B8346F48A683750A46BAB2110130D7D0@G3W0072.americas.hpqcorp.net>
Thread-Topic: Filter-rules-01 & Issue 192
Thread-Index: AccE8jWDqHfTTRcPTs+qxqshRGUcBBlHcMfAAAOiFFAABtzgMA==
From: "Sanchez, Mauricio (ProCurve)" 
To: , 

This is a multipart message in MIME format.

------=_NextPart_000_0060_01C76A45.4E8ED660
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


Jouni writes...

> -----Original Message-----
> > [MS1]  There may actually be more than one rule per
> > attribute. Another interesting case is when one rule is split
> > across two attributes (due to length).  What if we added the
> > following to in the description section?
> > "A NAS-Traffic-Rule attribute may contain a partial rule, one
> > rule, or more than one rule. Traffic rules may be contained
> > across attribute boundaries, so implementations cannot assume
> > that individual traffic rules begin or end on attribute boundaries."
> 
> [JiK] The proposed text is OK. Just wondering whether the ABNF is up to
> date with the above text. I could be wrong but to me it appears the the
> ABNF cannot support more than one rule per attribute.

[MS2] Are you thinking that we should replace the following,

" ; Start of ABNF description of NAS-Traffic-Rule        
         rule           =  "v1" " " (flush-rule / permit-all-rule  
                           / l2-filter-rule / l2-tunnel-rule 
                           / ip-filter-rule / ip-tunnel-rule  
                           / http-filter-rule / http-redir-rule)  
                           rule-delim"
with

" ; Start of ABNF description of NAS-Traffic-Rule 
	   rule-list      = rule *(rule)
         rule           =  "v1" " " (flush-rule / permit-all-rule  
                           / l2-filter-rule / l2-tunnel-rule 
                           / ip-filter-rule / ip-tunnel-rule  
                           / http-filter-rule / http-redir-rule)  
                           rule-delim"

 
> >
> > [MS1] Ok.  How about the following in the intro?
> > "Layer 2 filters are useful in filtering BPDU traffic for
> > which layer 3 filters have no effect."
> >
> > We may also consider adding BPDU to the terminology section.
> 
> [JiK] Thanks.. and I think it would be good to add the BPDU to the
> terminology section.

[MS2] Ok.  
 
> And then one more nit. Aren't we supposed to use example.com for all
> example domain names? Now there are goo.org etc ;)

[MS2] Dunno. You're probably right. I've been searching for an RFC that
describes formatting for URLs, but haven't found any.  

Cheers,
MS 

------=_NextPart_000_0060_01C76A45.4E8ED660
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMxOTE1NDAzMFowIwYJ
KoZIhvcNAQkEMRYEFJ39ZYadTkrhk23iRfkkFETjBEmdMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK
ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu
MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp
CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th
cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy
bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT
J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi
b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG
9w0BAQEFAASBgEOV6aF5NvVmmmJ2lhfkR6sOG3XMPLyMFqUJevTLpkpO8rpV2KbFKjHHbHe/PSwo
AWhxkJfDy2Fs5evG5+MJ89ouGCXomH82SW6erHgozdBMUHSUUiIT+5PTnCmvr6yfb/MORQTX4fAS
F4D+oMNl/r57A/7xlOZRvxMBFW2l4zKKAAAAAAAA

------=_NextPart_000_0060_01C76A45.4E8ED660--

--
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, 19 Mar 2007 13:43:04 +0000
Message-ID: <45FE9328.3080407@nitros9.org>
Date: Mon, 19 Mar 2007 14:42:00 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Bernard Aboba 
CC:  radiusext@ops.ietf.org
Subject: Re: Review of RFC 4590bis
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Section 3
> 
> Typos have been introduced into this Section.

 2.2.1, also:

The RADIUS server removes '' characters that escape quote and ''

  The previous document had '\'.  (Which is also arguably wrong, but for
different reasons)

...
> Section 5
> 
> The attribute table does not include entries for CoA-Request and
> Accounting-Request packets.

  It would be useful to have the following attributes in
Accounting-Request packets:

  Digest-Method, Digest-Realm, Digest-Domain, Digest-Username and
Digest-URI.

  i.e. the User-Name is in accounting packets now, so it would be useful
to have Digest-Username && associated attributes, too.

  As for CoA-Request, I'm not sure which attributes would be included.
Maybe a statement saying the digest attributes may/may not be included,
and give reasons?

  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: Mon, 19 Mar 2007 12:35:11 +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-rules-01 & Issue 192
Date: Mon, 19 Mar 2007 13:34:27 +0100
Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301A40159@SEHAN021MB.tcad.telia.se>
Thread-Topic: Filter-rules-01 & Issue 192
Thread-Index: AccE8jWDqHfTTRcPTs+qxqshRGUcBBlHcMfAAAOiFFA=
From: 
To: , 

Hi Sanchez,

See my replies inline.. using [JiK] for my replies.=20

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20
> Sent: 19. maaliskuuta 2007 12:43
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; radiusext@ops.ietf.org
> Subject: RE: Filter-rules-01 & Issue 192
>=20
> Jouni,
>=20
> See below for response to your comments.  Using [MS1] for my=20
> responses.=20
>=20
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org [mailto:owner-=20
> > radiusext@ops.ietf.org] On Behalf Of jouni.korhonen@teliasonera.com
> > Sent: Friday, November 10, 2006 7:01 PM [JiK] -01 looks=20
> better now. I=20
> > would still change change the
> >        'local operator' to 'local visited operator'.
>=20
> [MS1] Ok. I forgot to do this in -02, but will make change in -03.=20

[JiK] Thanks.

> > >  o what is the purpose of the rule-delim in the
> > >    NAS-Traffic-Rule ABNF? As far as I interpreted the
> > >    ABNF there can be only one rule per attribute anyway?
> > >    I could be wrong ;)
> >=20
> > The first version of the syntax had no rule delimiter and people=20
> > commented that having a delimiter would eliminate any=20
> possibility for=20
> > ambiguity of rule end.
> >=20
> > [JiK] So if there can be only one rule per attribute I=20
> still don't see=20
> > a
> >       need for rule-delim. It does not add any value imho.
>=20
> [MS1]  There may actually be more than one rule per=20
> attribute. Another interesting case is when one rule is split=20
> across two attributes (due to length).  What if we added the=20
> following to in the description section? =20
> "A NAS-Traffic-Rule attribute may contain a partial rule, one=20
> rule, or more than one rule. Traffic rules may be contained=20
> across attribute boundaries, so implementations cannot assume=20
> that individual traffic rules begin or end on attribute boundaries."

[JiK] The proposed text is OK. Just wondering whether the ABNF is up to
date with the above text. I could be wrong but to me it appears the the
ABNF cannot support more than one rule per attribute.

> > >  o What's the intended use for the L2 filtering? I'd
> > >    like to see some real use case described here
> >=20
> > BPDU filtering is one real use case.
> >=20
> > [JiK] Right. Probably a sentence or two saying L2 filtering=20
> is needed
> >       e.g. for BPDU filtering in the intro or some appendix examples
> >       would be good..
>=20
> [MS1] Ok.  How about the following in the intro?
> "Layer 2 filters are useful in filtering BPDU traffic for=20
> which layer 3 filters have no effect."
>=20
> We may also consider adding BPDU to the terminology section.

[JiK] Thanks.. and I think it would be good to add the BPDU to the
terminology section.


And then one more nit. Aren't we supposed to use example.com for all
example domain names? Now there are goo.org etc ;)

Cheers,
	Jouni

>=20
> Cheers,
> MS
>=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: Mon, 19 Mar 2007 12:22: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: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Date: Mon, 19 Mar 2007 05:20:21 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625039F5D05@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Thread-Index: AcdqD9VPNSzGff05SjW6S1RSTErXowAEJNMw
From: "Glen Zorn \(gwz\)" 
To: "Sanchez, Mauricio \(ProCurve\)" 
Cc: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2636; t=1174306888; x=1175170888; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Extended=20Filter=20attribute=3A=20=20Change=20summar y=20from=20-01=20to=2002=3B=20Issues=20score=20card=20review |Sender:=20; bh=4tFQvxSN4GZyniA6jSrQVruGwOCp6Wv1UW6arVloUuQ=; b=f50IIiKBVNhhYmRGmmO1CWXFlxtgyWtOn6iQgRAmHETkpH02/l69UoAV1aym80Xz4PUGgQYZ fFd86QuLYYVNpzlaTCdmFKe2Enz4Gd4kzkdaYAUvLvbJUTJoRXXccx8+;
Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; );

Sanchez, Mauricio (ProCurve) <> allegedly scribbled on Monday, March 19,
2007 3:18 AM:

> For those keeping track, the extended filter draft
> (draft-ietf-radext-filter-rules-02.txt ) has been an active working
> group item for over two years in one form or another.  At the rate
> it's going, we may all retire before it's complete. ;) Anyway. =20
>=20
> Substantive changes from version -01 to -02
> -------------------------------------------
> 1. Removed requirement that rule types appear in a specific order by
> removing text: "Furthermore, if the list contains different types of
> rules, they MUST appear in the following order: flush rules, base
> encapsulation tunnel rules, base encapsulation filter rules, IP
> tunnel rules, HTTP redirect rules, IP filter rules, and HTTP filter
> rules."  (Section 2.5)    =20
>=20
> The above change address should address part of Issue 170 (Precedence
> and order for NAS-filter-rule).=20
>=20
> 2. Updated attribute behavior in presence of NAS-filter-rule:
> "Filter-ID (11), NAS-Filter-Rule [Filter] and NAS-Traffic-Rule
> attributes define how filters are to be applied in the NAS. These
> attributes are not =20
> intended to be used concurrently and          SHOULD NOT appear in
> the same=20
> RADIUS message. Only one type of filtering attribute must be
> processed. If a Filter-ID (11) is present, then the NAS-Traffic-Rule
> MUST be ignored, if present." (Section 2.5) =20
>=20
> 3. Added a version label prefix to rule syntax.  Each rule now
> includes a "v1" prefix designating the rule as conforming to version
> 1 of traffic-rule syntax.  The idea here is to allow future
> updates/changes to the rule syntax without having to define another
> attribute and burn another type number.   =20

I was under the impression that we had decided to use the new extended
attribute format for this, thus obviating the concern about 'burning
another type number'.

>=20
> 4. Re-did the Diameter Considerations section [5].  Now are using the
> same approach employed by rfc4675 (RADIUS attributes for virtual LAN
> and priority support).  The approach eliminates the need to re-create
> a diameter-specific version of nas-traffic-rule and rather relies on
> the general radius<->diameter interoperability mechanisms.  I do have
> a question as to whether the diameter value type specified
> (OctetString) is the right one or not.  I'm no diameter value type
> expert, so feedback welcome.  =20

A far better idea would be to get rid of the OS-specific Diameter stuff
& define an extensible grouped AVP for filters. =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: 


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 19 Mar 2007 10:44:23 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Filter-rules-01 & Issue 192
Date: Mon, 19 Mar 2007 10:43:01 -0000
Content-Type: multipart/signed; boundary="----=_NextPart_000_003C_01C76A1B.BF7B0440"; protocol="application/x-pkcs7-signature"; micalg=SHA1
Message-ID: <2F2D38A4B8346F48A683750A46BAB2110130D622@G3W0072.americas.hpqcorp.net>
Thread-Topic: Filter-rules-01 & Issue 192
Thread-Index: AccE8jWDqHfTTRcPTs+qxqshRGUcBBlHcMfA
From: "Sanchez, Mauricio (ProCurve)" 
To: , 

This is a multipart message in MIME format.

------=_NextPart_000_003C_01C76A1B.BF7B0440
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Jouni,

See below for response to your comments.  Using [MS1] for my responses. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org [mailto:owner-
> radiusext@ops.ietf.org] On Behalf Of jouni.korhonen@teliasonera.com
> Sent: Friday, November 10, 2006 7:01 PM
> [JiK] -01 looks better now. I would still change change the
>        'local operator' to 'local visited operator'.

[MS1] Ok. I forgot to do this in -02, but will make change in -03. 

> >  o what is the purpose of the rule-delim in the
> >    NAS-Traffic-Rule ABNF? As far as I interpreted the
> >    ABNF there can be only one rule per attribute anyway?
> >    I could be wrong ;)
> 
> The first version of the syntax had no rule delimiter and people
> commented
> that having a delimiter would eliminate any possibility for ambiguity
> of
> rule end.
> 
> [JiK] So if there can be only one rule per attribute I still don't see
> a
>       need for rule-delim. It does not add any value imho.

[MS1]  There may actually be more than one rule per attribute. Another
interesting case is when one rule is split across two attributes (due to
length).  What if we added the following to in the description section?  
"A NAS-Traffic-Rule attribute may contain a partial rule, one rule, or more
than one rule. Traffic rules may be contained across attribute boundaries,
so implementations cannot assume that individual traffic rules begin or end
on attribute boundaries."

 
> >  o What's the intended use for the L2 filtering? I'd
> >    like to see some real use case described here
> 
> BPDU filtering is one real use case.
> 
> [JiK] Right. Probably a sentence or two saying L2 filtering is needed
>       e.g. for BPDU filtering in the intro or some appendix examples
>       would be good..

[MS1] Ok.  How about the following in the intro?
"Layer 2 filters are useful in filtering BPDU traffic for which layer 3
filters have no effect."

We may also consider adding BPDU to the terminology section.

Cheers,
MS

------=_NextPart_000_003C_01C76A1B.BF7B0440
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMxOTEwNDMwMVowIwYJ
KoZIhvcNAQkEMRYEFEEx4XDTbI95vq+6c0IbjkTgLJ4zMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK
ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu
MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp
CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th
cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy
bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT
J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi
b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG
9w0BAQEFAASBgArdRA8u9Kp+fK0dL0y5PJHdveWxFxtkZrLbhwps3J0gbDh0JWKAMbqkPrGNuvQI
1p0gN4C5y1EdojMRom8xReGbteBTjA+PXezgICIoLWnuzFxbslbMqvYmJONQK8ylQ5wrti2XVSty
j3ZIr+QCzdlqgxR+BWMad+VWrkuYma78AAAAAAAA

------=_NextPart_000_003C_01C76A1B.BF7B0440--

--
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, 19 Mar 2007 10:18:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Date: Mon, 19 Mar 2007 10:17:44 -0000
Content-Type: multipart/signed; boundary="----=_NextPart_000_0032_01C76A18.371B16B0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
Message-ID: <2F2D38A4B8346F48A683750A46BAB2110130D621@G3W0072.americas.hpqcorp.net>
Thread-Topic: Extended Filter attribute:  Change summary from -01 to 02; Issues score card review
Thread-Index: AcdqD9VPNSzGff05SjW6S1RSTErXow==
From: "Sanchez, Mauricio (ProCurve)" 
To: 

This is a multipart message in MIME format.

------=_NextPart_000_0032_01C76A18.371B16B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

For those keeping track, the extended filter draft
(draft-ietf-radext-filter-rules-02.txt
) has been an active working group item for over two years in one form or
another.  At the rate it's going, we may all retire before it's complete. ;)
Anyway.

Substantive changes from version -01 to -02
-------------------------------------------
1. Removed requirement that rule types appear in a specific order by
removing text: "Furthermore, if the list contains different types of rules,
they MUST appear in the following order: flush rules, base encapsulation
tunnel rules, base encapsulation filter rules, IP tunnel rules, HTTP
redirect rules, IP filter rules, and HTTP filter rules."  (Section 2.5)

The above change address should address part of Issue 170 (Precedence and
order for NAS-filter-rule).

2. Updated attribute behavior in presence of NAS-filter-rule:
"Filter-ID (11), NAS-Filter-Rule [Filter] and NAS-Traffic-Rule attributes
define how filters are to be applied in the NAS. These attributes are not
intended to be used concurrently and          SHOULD NOT appear in the same
RADIUS message. Only one type of filtering attribute must be processed. If a
Filter-ID (11) is present, then the NAS-Traffic-Rule MUST be ignored, if
present." (Section 2.5)

3. Added a version label prefix to rule syntax.  Each rule now includes a
"v1" prefix designating the rule as conforming to version 1 of traffic-rule
syntax.  The idea here is to allow future updates/changes to the rule syntax
without having to define another attribute and burn another type number.  

4. Re-did the Diameter Considerations section [5].  Now are using the same
approach employed by rfc4675 (RADIUS attributes for virtual LAN and priority
support).  The approach eliminates the need to re-create a diameter-specific
version of nas-traffic-rule and rather relies on the general
radius<->diameter interoperability mechanisms.  I do have a question as to
whether the diameter value type specified (OctetString) is the right one or
not.  I'm no diameter value type expert, so feedback welcome. 

Issues scorecard
---------------
According to extended RADEXT website, the draft has the following issues
filed against it:

1. Issue 111: Accounting (submitted by Greg W.)
I believe this issue is no longer relevant since the sections in question
are no longer present. Next step: close out on website.

2. Issue 114: WGLC Review (submitted by Bernard A.)
Various sub-issues under this issue.  All but one sub-issue are closed.
Remaining sub-issue is on why rule hit accounting is present in the draft.
Next step: discuss this week.

3. Issue 115: WG Last Call Comments (submitted by Dave N.)
Various sub-issues under this issue.  I believe the only remaining sub-issue
open is about moving the section 1.3 (Attribute Interpretation) into the
security section.  Didn't understand why back then and I still don't
understand.  Next step:  discuss this week.

4. Issue 130: Diameter Compatibility (submitted by Bernard A.)
Given the overhaul of section 5, this one may be finally solved. Next step:
Bernard to approve/disapprove section 5

5. Issue 164: Review (submitted by Jari A.)
Various sub-issues under this issue.  I don't believe there are any
unresolved sub-issue left, but Jari needs to confirm/refute my stance.  Next
step: Jari to review whether all his comments have been addressed.

6. Issue 169: Handing unparsable nas-filter-rule (submitted by Greg W.)
I believe Greg's issue have been dealt with.  Next step: Greg to review
whether his comment have been addressed.

7. Issue 170:  Precedence and order for NAS-filter-rule (submitted Greg W.)
Last discussion on this one was in June '06.  Unsure whether draft -02
continues or deals with the various sub-issues discussed on the email list
thus far.  Next step:  Review of draft -02 to see whether sub-issues still
exist.

8. Issue 192: Comments (Submitted by Jouni K.)
Last discussion on this was back on Nov. 10, 2006.  Jouni agreed with many
of the changes in -01 that address his comments.  Next step: I'm going to
reply to Jouni's email on remaining open comments. 

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez@hp.com
--------------------------------------------   

------=_NextPart_000_0032_01C76A18.371B16B0
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDMxOTEwMTc0M1owIwYJ
KoZIhvcNAQkEMRYEFPnS224drURuoDws5Zfqi8nuL3cOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK
ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu
MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp
CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th
cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy
bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT
J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi
b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG
9w0BAQEFAASBgK7fH5e0IkCSo+qGpB1dwryLqj/hol0FWjywm89J32d6cGiM2lg/x6hkmTk+iTBX
+bAOiVzxez47GntALdliEZM5wOZyzC2pBKJraKatyeA44cUP6j+n36wXy0Ri0pC3QKzIy+i8n4No
c8i0Y0CUqDVNxdmSEs74+Igi0pO9KMsHAAAAAAAA

------=_NextPart_000_0032_01C76A18.371B16B0--

--
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, 19 Mar 2007 10:11:40 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Issue 224: Comments
Date: Mon, 19 Mar 2007 03:11:14 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Issue 224: Comments
Submitter name: Jouni Malinen
Submitter email address: jkm@devicescape.com
Date first submitted: January 8, 2007
Reference:
Document: RADIUS WLAN
Comment type: T
Priority: S
Section: 2.1, 2.2, 2.3, 2.7
Rationale/Explanation of issue:

2.1 and 2.3

I think I understood what Allowed-SSID and Allowed-Called-Station-ID
attributes are defined for. However, the way I interpret the current
text would make these attributes more or less useless..

NAS is required to silently discard these attributes if the specified
SSID/BSSID does not match with their own configuration. If all the
allowed values are silently discarded, the Access-Accept message is
processed without any Allowed-SSID or Allowed-Called-Station-ID
attributes. I would interpret that to mean that there is no
restriction on SSID or BSSID.. In other words, there would be no way
for the AS to specify this restriction in a way that NAS would act on
it. Should there be text saying that if one or more Allowed-SSID (and
similarly for Allowed-Called-Station-ID) attributes were present, the
client would not be allowed to use the NAS if none of them
matched. For this to work, the attributes cannot be silently ignored.

2.2 SSID

Isn't RFC 3580 already defining a mechanism for including SSID in
Called-Station-Id? Why add a duplicated attribute for delivering this?
RFC 3580 marks the SSID as "SHOULD" and this new attribute is only
"MAY".

2.3 Allowed-Called-Station-ID

typo: this should be -Id, not -ID (both Allowed-Called-Station-Id and
Called-Station-Id)

The requirement of not including SSID (MUST NOT) sounds a bit odd here
taken into account that RFC 3580 has "where the SSID is known, it
SHOULD be appended to the Access Point MAC address" in description of
Called-Station-Id. This is at least confusing, if not
conflicting..

How would a NAS determine whether a Called-Station-Id (which includes an
SSID) is allowed or not, if the set of Allowed-Called-Station-Id
attributes do not include SSID? Is the NAS supposed to strip SSID from
the Called-Station-Id attribute before comparing it to the
Allowed-Called-Station-Id attribute(s)?

Is the goal here to also remove SSID from Called-Station-Id (which
would explain the new SSID attribute)? If yes, that should be stated
explicitly by modifying Called-Station-Id definition of RFC 3580. If
not, Allowed-Called-Station-Id should also include SSID or at least
should have instructions on how the NAS is to compare these two
attributes that have conflicting definition as far as inclusion of SSID
is concerned.

2.7 Mobility-Domain-Id

This attribute is recommended to use UTF-8 encoding. However, 802.11r
defines MDID as a 48-bit value that looks very much like a MAC
address. There is not much point in trying to use UTF-8 for that. In
order to avoid confusion, I would suggest removing the comment about
UTF-8 here. I would expect that this attribute would be using
"undistinguished octets" with 6 octets and not an ASCII hexdump of
this value.

[IEEE-802.11r]

Refering 802.11r/D1.2 does not look very good.. At minimum, this
should be marked as "Work in Progress" like IETF drafts are refered to
and this should also be updated to the latest draft version.

[KEYFRAME]

This should also be refered as "Work in Progress" unless keyframe draft
is published as an RFC before RADEXT WLAN.

-----------------
> > Should there be text saying that if one or more Allowed-SSID (and
> > similarly for Allowed-Called-Station-ID) attributes were present, the
> > client would not be allowed to use the NAS if none of them
> > matched. For this to work, the attributes cannot be silently ignored.

>That would make sense for implementations of the specification. However,
>legacy implementations may well ignore these (and other) attributes they
>do not understand. So it's probably a good idea to put in a warning
>saying that the Allowed-SSID and Allowed-Called-Station-Id attributes
>should only be sent to authenticators known to support them.

If the authenticator does not support them, the attributes will be
ignored, so no harm there as far as I can tell. However, what I would
like to see added is a clarification for the case where these attributes
are supported, but none of the included attributes actually match with
the current configuration of the NAS. At least as far as
Allowed-Called-Station-Id is concerned, I don't think the attributes
should be silently ignored in such a case.

For example, with 802.11r, the initial association could get a set of
Allowed-Called-Station-Id attributes. R0KH would need to store the full
set of attributes, including the addresses for foreign devices, with the
PMK-R0 SA and then deliver these to R1KHs in order to allow them to do
this kind of filtering on allowed Called-Station-Id addresses. Same
would apply for opportunistic key caching with 802.11i.

"If the Called-Stationd Id included in the Allowed-Called-Station-Id
attribute does not describe a layer 2 endpoint of the NAS, the attribute
is silently discarded." seems to prevent the kind of use I described
above.

> > 2.2 SSID

>Yes, RFC 3580 does enable the SSID to be placed in the Called-Station-Id.
>Quite a few implementations do this, but others seem to prefer sending this
>in a separate (vendor specific) attribute. So the question was whether
>there is enough interest in standardizing that alternative.

OK. I just implemented this based on RFC 3580 and haven't looked into
other implementations. If there are indeed number of implementations
that use VSA for this and the vendors would be interested in replacing
those with this new attribute, this sounds fine.

> > How would a NAS determine whether a Called-Station-Id (which includes an
> > SSID) is allowed or not, if the set of Allowed-Called-Station-Id
> > attributes do not include SSID? Is the NAS supposed to strip SSID from
> > the Called-Station-Id attribute before comparing it to the
> > Allowed-Called-Station-Id attribute(s)?

>OK. I hadn't thought of the potential need to restrict use of certain
>BSSIDs with certain SSIDs, but it make sense. In that case it probably
>makes sense to enable an Allowed-Called-Station-Id attribute to contain an
>SSID. And if this is done, there may be a need for only one attribute.

That would be one case, but more importantly, there needs to be a clear
description on how the comparison is to be done if this is done at the
RADIUS attribute level. If NAS is comparing the exact contents of
Allowed-Called-Station-Id and Called-Station-Id, there could be
mismatches based on whether the SSID is included in none/one/both of
them. If the comparison is done outside the "RADIUS context" by storing
just the BSSID list from the Allowed-Called-Station-Id attributes, this
is less likely to cause problems.


One more comment: It might be useful to standardize on a mechanism to
allow NAS to indicate that the authentication is for 802.11i
pre-authentication case. I have not seen this described anywhere and
don't know how other implementations are taking care of this (if they
are). I ended up using "IEEE 802.11i Pre-Authentication" as the
Connect-Info attribure for this, but this is not really defined
anywhere. Anyway, I don't see anything in either RFC 2869 or RFC 3580
conflicting with this kind of use.

Somewhat related question would be whether there is any need for
indicating the difference between IEEE 802.11i and 802.11r in
Access-Request. There has been some discussion on this in TGr when the
topic of pre-authentication for 802.11r came up and there seemed to be
consensus on the same MSK/PMK not being allowed for both uses, so this
would need to be prevented at the authenticator. AS does not really need
to know about this, but it could be useful information if there is any
desire to describe different behavior for 802.11r and 802.11i cases.



--
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, 19 Mar 2007 08:25:09 +0000
Message-ID: <45FE48AF.6080506@nitros9.org>
Date: Mon, 19 Mar 2007 09:24:15 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Bernard Aboba 
CC:  radiusext@ops.ietf.org
Subject: Re: Issue 223: Event-Timestamp and Duplicate Detection
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
...
> However, if an Event-Timestamp attribute is included in a request, then
> the Identifier will change on retransmission, and this technique will
> not work.

  Yes.

> RFC 2869 Section 5.3, appears to prohibit inclusion of Event-Timestamp
> except in an Accounting-Request:
...
> RFC 2869 Section 5.19 does not include a table row for the
> Event-Timestamp attribute, suggesting that Event-Timestamp is prohibited
> in Access-Request, Accept, Reject and Challenge packets.

  That sounds good.

> However, RFC 3576 suggested inclusion of an Event-Timestamp attribute in
> CoA and Disconnect messages for replay protection.  Since the
> Event-Timestamp attribute will change on retransmission of a CoA-Request
> or Disconnect-Request, the Identifier will also change, and this implies
> that duplicates would potentially go undetected. Could this cause a
> problem?



> I do not think so.  If one Disconnect-Request arrives and is responded
> to, then the user has been disconnected (or not) and receiving another
> duplicate request will not make a difference, since you can't disconnect
> a user twice.  Similarly, if a CoA-Request was already processed,
> processing it again will yield the same result.

  So long as there are no race conditions (login, disconnect, login,
duplicate disconnect), that would appear to be OK.

  A longer term fix would be to require Access-Request packets to
contain a Acct-Session-Id attribute, which would be used to detect
duplicate sessions, independent of duplicate packets.  That fix would
also mean that EAP may not need the State attribute, as discussed in the
Isses & Fixes draft.

> Still, the Nonce attribute described in RFC 3576bis does not have this
> issue, because the Nonce doesn't change if the packet is retransmitted. 
> Would it be a good idea to remove mention of Event-Timestamp from RFC
> 3576bis?

  I would agree.  Optional parts of the protocol that could cause
problems are best left umentioned.

> Also, would it be a good idea to include language similar to RFC 2865 in
> RFC 3576bis, such as:
> 
>      The NAS can detect a duplicate CoA or Disconnect-Request if
>      it has the same server source IP address and source UDP port and
>      Identifier within a short span of time.

  Yes.

  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: Mon, 19 Mar 2007 01:37:35 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Issue 223: Event-Timestamp and Duplicate Detection
Date: Sun, 18 Mar 2007 18:37:20 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Issue 223: Event-Timestamp and Duplicate Detection
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: March 19, 2007
Reference:
Document: RFC 3576bis
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

During the discussion of RADIUS duplicate detection it occurred to me that 
the inclusion of the Event-Timestamp attribute in RFC 3576bis messages 
impacts the duplicate detection functionality described in RFC 2865 Section 
3:

      The RADIUS server can detect a duplicate request if
      it has the same client source IP address and source UDP port and
      Identifier within a short span of time.

However, if an Event-Timestamp attribute is included in a request, then the 
Identifier will change on retransmission, and this technique will not work.

RFC 2869 Section 5.3, appears to prohibit inclusion of Event-Timestamp 
except in an Accounting-Request:

      This attribute is included in an Accounting-Request packet to
      record the time that this event occurred on the NAS, in seconds
      since January 1, 1970 00:00 UTC.

RFC 2869 Section 5.19 does not include a table row for the Event-Timestamp 
attribute, suggesting that Event-Timestamp is prohibited in Access-Request, 
Accept, Reject and Challenge packets.

However, RFC 3576 suggested inclusion of an Event-Timestamp attribute in CoA 
and Disconnect messages for replay protection.  Since the Event-Timestamp 
attribute will change on retransmission of a CoA-Request or 
Disconnect-Request, the Identifier will also change, and this implies that 
duplicates would potentially go undetected. Could this cause a problem?

I do not think so.  If one Disconnect-Request arrives and is responded to, 
then the user has been disconnected (or not) and receiving another duplicate 
request will not make a difference, since you can't disconnect a user twice. 
  Similarly, if a CoA-Request was already processed, processing it again 
will yield the same result.

Still, the Nonce attribute described in RFC 3576bis does not have this 
issue, because the Nonce doesn't change if the packet is retransmitted.  
Would it be a good idea to remove mention of Event-Timestamp from RFC 
3576bis?

Also, would it be a good idea to include language similar to RFC 2865 in RFC 
3576bis, such as:

      The NAS can detect a duplicate CoA or Disconnect-Request if
      it has the same server source IP address and source UDP port and
      Identifier within a short span of 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: Mon, 19 Mar 2007 01:13:30 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Issue 222: Review
Date: Sun, 18 Mar 2007 18:12:39 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Issue 222: Review
Submitter name: Stuart Kerry
Submitter email address: stuart.kerry@philips.com
Date first submitted: January 11, 2007
Reference:
Document: draft-aboba-radext-wlan-03.txt
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

IEEE 802.11 has received a request to provide review comments on the IETF 
RADEXT internet draft draft-aboba-radext-wlan-03.txt. Comments on 
draft-aboba-radext-wlan-03.txt are as follows:

Section 1.1, Terminology, Definition of Authenticator. Suggest changing the 
definition to
that used in IEEE Std 802.1X-2004, “Authenticator – An entity at one end of 
a point-to-point
LAN segment that facilitates authentication of the entity attached to the 
other end of the link.”

Section 1.1, Terminology, Definition of Supplicant. Suggest changing the 
definition to that
used in IEEE Std 802.1X-2004, “Supplicant – An entity at one end of a 
point-to-point LAN
segment that seeks to be authenticated by an Authenticator attached to the 
other end of that link.”

Section 1.1, Terminology, Listing of “authentication server”. Suggest 
capitalizing, e.g. “Authentication Server”.

Sections 2.1 and 2.3, “Allowed-SSID and “Allowed-Called-Station-ID”. Suggest 
inserting
text to provide guidance in the case that the attributes are supported but 
not present:
“The the Allowed-Called-Station-Id (SSID) included in the 
Allowed-Called-Station-Id (SSID)
Atttribute does not describe a layer 2 endpoint of the NAS, the attribute is 
silently discarded”.

Section 2.3, Allowed-Called-Station-ID. Change “-ID” to “-Id”.

Section 2.3, Allowed-Called-Station-ID. Add a description of how the NAS 
compares the contents
of the Allowed-Called-Station-Id and the Called-Station-Id attributes, 
accounting for the cases
when the SSID is is not/included.

Section 2.4, Description. Here and in the corresponding text in 2.5 and 2.6, 
the text states
“depends on the link layer in question” and “not all link layers use this 
name”. Suggest deleting
this text, as the focus of the document appears to be a single link layer, 
IEEE 802.11.
Section 2.7, Mobility Domain-Id. Suggest removing the use of UTF-8 encoding, 
as the Mobility
Domain is expected to be used as a maximum of 6 “undistinguished octets”.

Section 7, References, IEEE-802.11.  The current version of the IEEE 802.11 
Standard is
“ANSI/IEEE Std. 802.11Ò-1999, as amended by IEEE Std. 802.11a, IEEE Std. 
802.11b,
IEEE Std. 802.11b-COR1, IEEE Std. 802.11d, IEEE Std. 802.11g-2003, IEEE Std. 
802.11h-2003,
IEEE Std. 802.11i-2004, IEEE Std. 802.11j-2004”. If publication of the 
internet draft follows
publication of IEEE 802.11-REVma, then the reference should be to “ANSI/IEEE 
Std 802.11Ò-2007.

Section 7, References, IEEE-802.11r. Suggest updating the reference from 
Draft 1.2, February 2006  to Draft 4.0, November 2006.



--
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, 18 Mar 2007 23:51:12 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Re: Issue RFC 3576bis Usage of service-type in Disconnect-Request
Date: Sun, 18 Mar 2007 16:49:52 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

This has been assigned Issue 215.

Are there any objections to accepting the proposed changes?

===========================
   Description of issue
    Submitter name: Avi Lior
    Submitter email address: avi@bridgewatersystems.com
    Date first submitted: March 14th, 2007
    Reference:
    Document: RFC 3576bis
    Comment type: T
    Priority: S
    Section: Insert_Section_Number_Here
    Rationale/Explanation of issue:

    Service-Type = "Authorize-Only" does not make sense for Disconnect
Message.

    Length description of problem:

    Service-Type = "Authorize-Only" was added to make the Change of
Authorization compatible with the Diameter specification.

    However, Diameters ASR message directly correlates with Disconnect
Message, that is, both can be sent by the server to the client.
    Therefore, the 3756 semantics for Service-Type = "Authorize-Only"
are not required for Disconnect Message.

    Requested change:

    Remove the use of Service-Type = 'Authorize-Only' from RFC3576bis
and disallow State in Disconnect Messages details follow.



In section 2.1.  Disconnect Messages (DM)
*********************************************


Remove the following:
   "A NAS MUST respond to a
   Disconnect-Request including a Service-Type Attribute with an
   unsupported value with a Disconnect-NAK; an Error-Cause Attribute
   with value "Unsupported Service" MAY be included."

And remove the following:

   "A NAS supporting the "Authorize Only" Service-Type within a
   Disconnect-Request responds with a Disconnect-NAK containing a
   Service-Type Attribute with value "Authorize Only" and an Error-Cause
   Attribute with value "Request Initiated".  The NAS will then send an
   Access-Request containing a Service-Type Attribute with a value of
   "Authorize Only", along with a State Attribute.  The RADIUS server
   MUST reply to this Access-Request with an Access-Reject.
   "


In section: 3.  Attributes
**************************

Change:
   A Disconnect-Request MUST contain only NAS and session identification
   attributes (see Section 3), as well as Service-Type, Nonce and State
   attributes.  If other attributes are included in a Disconnect-
   Request, implementations MUST send a Disconnect-NAK; an Error-Cause
   Attribute with value "Unsupported Attribute" MAY be included.

To:
   A Disconnect-Request MUST contain only NAS and session identification
   attributes (see Section 3), as well as Nonce.  If other attributes
are
   included in a Disconnect-Request, implementations MUST send a
   Disconnect-NAK; an Error-Cause Attribute with value "Unsupported
Attribute" MAY be included.


In section 3.1.  State
**********************

Change:
   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request or Disconnect-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a CoA-Request or Disconnect-Request containing a Service-
   Type value of "Authorize-Only" but lacking a State attribute MUST
   send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
   attribute with value 402 (Missing Attribute).

To:
   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a CoA-Request containing a Service-
   Type value of "Authorize-Only" but lacking a State attribute MUST
   send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
   attribute with value 402 (Missing Attribute).


In section 3.4.  Error-Cause
****************************

Change:
      "Unsupported Service" is a fatal error sent if a Service-Type
      Attribute included with the Request is sent with an invalid or
      unsupported value.
To:
      "Unsupported Service" is a fatal error sent if a Service-Type
      Attribute included with the Request is sent with an invalid or
      unsupported value.  Only valid when performing Change of
Authorization.


Change:

      "Request Initiated" is a fatal error sent in response to a Request
      including a Service-Type Attribute with a value of "Authorize
      Only".  It indicates that the Disconnect-Request or CoA-Request
      has not been honored, but that a RADIUS Access-Request including a
      Service-Type Attribute with value "Authorize Only" is being sent
      to the RADIUS server.
To:
      "Request Initiated" is a fatal error sent in response to a
CoA-Request
      including a Service-Type Attribute with a value of "Authorize
      Only".  It indicates that the CoA-Request
      has not been honored, but that a RADIUS Access-Request including a
      Service-Type Attribute with value "Authorize Only" is being sent
      to the RADIUS server.


In section 3.5.  Table of Attributes
***************************************

In the Disconnect Messages Table:

   Request   ACK      NAK   #   Attribute

Change:
   0-1       0        0-1   6   Service-Type [Note 6]
To:
   0         0        0     6   Service-Type

Change:
0-1       0-1      0-1  24   State [Note 7]
To:
   0       0      0  24   State

Change NOTE 6 from:

   [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
   on the NAS and RADIUS server.  A NAS supporting the "Authorize Only"
   Service-Type value within Disconnect-Request or CoA-Request packets
   MUST respond with a Disconnect-NAK or CoA-NAK respectively,
   containing a Service-Type Attribute with value "Authorize Only", and
   an Error-Cause Attribute with value "Request Initiated".  The NAS
   then sends an Access-Request to the RADIUS server with a Service-Type
   Attribute with value "Authorize Only".  This Access-Request SHOULD
   contain the NAS attributes from the Disconnect or CoA-Request, as
   well as the session attributes from the Request legal for inclusion
   in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869]
   and [RFC3162].  As noted in [RFC2869] Section 5.19, a Message-
   Authenticator attribute SHOULD be included in an Access-Request that
   does not contain a User-Password, CHAP-Password, ARAP-Password or
   EAP-Message Attribute.  The RADIUS server should send back an Access-
   Accept to (re-)authorize the session or an Access-Reject to refuse to
   (re-)authorize it.

   A NAS that does not support the Service-Type Attribute with the value
   "Authorize Only" within a Disconnect-Request MUST respond with a
   Disconnect-NAK including no Service-Type Attribute; an Error-Cause
   Attribute with value "Unsupported Service" MAY be included.  A NAS
   that does not support the Service-Type Attribute with the value
   "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
   including no Service-Type Attribute; an Error-Cause Attribute with
   value "Unsupported Service" MAY be included.

To:

   [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
   on the NAS and RADIUS server.  A NAS supporting the "Authorize Only"
   Service-Type value within a CoA-Request packet
   MUST respond with a CoA-NAK,
   containing a Service-Type Attribute with value "Authorize Only", and
   an Error-Cause Attribute with value "Request Initiated".  The NAS
   then sends an Access-Request to the RADIUS server with a Service-Type
   Attribute with value "Authorize Only".  This Access-Request SHOULD
   contain the NAS attributes from the CoA-Request, as
   well as the session attributes from the Request legal for inclusion
   in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869]
   and [RFC3162].  As noted in [RFC2869] Section 5.19, a Message-
   Authenticator attribute SHOULD be included in an Access-Request that
   does not contain a User-Password, CHAP-Password, ARAP-Password or
   EAP-Message Attribute.  The RADIUS server should send back an Access-
   Accept to (re-)authorize the session or an Access-Reject to refuse to
   (re-)authorize it.

   A NAS
   that does not support the Service-Type Attribute with the value
   "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
   including no Service-Type Attribute; an Error-Cause Attribute with
   value "Unsupported Service" MAY be included.


Change:

   [Note 7] The State Attribute is available to be sent by the RADIUS
   server to the NAS in a Disconnect-Request or CoA-Request packet and
   MUST be sent unmodified from the NAS to the RADIUS server in a
   subsequent ACK or NAK packet.  If a Service-Type Attribute with value
   "Authorize Only" is included in a Disconnect-Request or CoA-Request
   then a State Attribute MUST be present, and MUST be sent unmodified
   from the NAS to the RADIUS server in the resulting Access-Request
   sent to the RADIUS server, if any.  The State Attribute is also
   available to be sent by the RADIUS server to the NAS in a CoA-Request
   that also includes a Termination-Action Attribute with the value of
   RADIUS-Request.  If the client performs the Termination-Action by
   sending a new Access-Request upon termination of the current session,
   it MUST include the State Attribute unchanged in that Access-Request.
   In either usage, the client MUST NOT interpret the Attribute locally.
   A Disconnect- Request or CoA-Request packet must have only zero or
   one State Attribute.  Usage of the State Attribute is implementation
   dependent.  If the RADIUS server does not recognize the State
   Attribute in the Access-Request, then it MUST send an Access-Reject.

To:
   [Note 7] The State Attribute is available to be sent by the RADIUS
   server to the NAS in a CoA-Request packet and
   MUST be sent unmodified from the NAS to the RADIUS server in a
   subsequent ACK or NAK packet.  If a Service-Type Attribute with value
   "Authorize Only" is included in a CoA-Request
   then a State Attribute MUST be present, and MUST be sent unmodified
   from the NAS to the RADIUS server in the resulting Access-Request
   sent to the RADIUS server, if any.  The State Attribute is also
   available to be sent by the RADIUS server to the NAS in a CoA-Request
   that also includes a Termination-Action Attribute with the value of
   RADIUS-Request.  If the client performs the Termination-Action by
   sending a new Access-Request upon termination of the current session,
   it MUST include the State Attribute unchanged in that Access-Request.
   In either usage, the client MUST NOT interpret the Attribute locally.
   A Disconnect-Request or CoA-Request packet must have only zero or
   one State Attribute.  Usage of the State Attribute is implementation
   dependent.

NOTE: I am recommending to delete the last sentence

"If the RADIUS server does not recognize the State
   Attribute in the Access-Request, then it MUST send an Access-Reject."

   because it does not belong in this document.



In section 4.  Diameter Considerations
***************************************

Change:

   Since both the ASR/ASA and Disconnect-Request/Disconnect-
   NAK/Disconnect-ACK exchanges involve just a request and response,
   inclusion of an "Authorize Only" Service-Type within a Disconnect-
   Request is not needed to assist in Diameter/RADIUS translation, and
   may make translation more difficult.  As a result, inclusion of a
   Service-Type of "Authorize Only" within a Disconnect-Request is NOT
   RECOMMENDED.

To:
   Since both the ASR/ASA and Disconnect-Request/Disconnect-
   NAK/Disconnect-ACK exchanges involve just a request and response,
   inclusion of an "Authorize Only" Service-Type within a Disconnect-
   Request is not needed to assist in Diameter/RADIUS translation, and
   may make translation more difficult.  As a result, the Service-Type
   attribute MUST NOT be used within a Disconnect-Request.

In Appendix A - Changes from RFC 3576
**************************************

Add:

Disallowed usage of Service-Type and State attribute in
Disconnect-Message



--
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: Sat, 17 Mar 2007 19:18:43 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Slides for IETF 68...
Date: Sat, 17 Mar 2007 12:17:44 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Please send your IETF 68 slide presentations to myself and David as soon as 
possible.



--
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, 15 Mar 2007 00:01:36 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Issue RFC3576bis Usage of service-type in Disconnect-Request 
Date: Wed, 14 Mar 2007 20:00:40 -0400
Message-ID: 
From: "Avi Lior" 
To: 
Cc: "Bernard Aboba" 

   Description of issue
    Submitter name: Avi Lior
    Submitter email address: avi@bridgewatersystems.com
    Date first submitted: March 14th, 2007
    Reference:=20
    Document: RFC 3576bis
    Comment type: T
    Priority: S
    Section: Insert_Section_Number_Here
    Rationale/Explanation of issue:
   =20
    Service-Type =3D "Authorize-Only" does not make sense for Disconnect
Message.
   =20
    Length description of problem:
   =20
    Service-Type =3D "Authorize-Only" was added to make the Change of
Authorization compatible with the Diameter specification.
   =20
    However, Diameters ASR message directly correlates with Disconnect
Message, that is, both can be sent by the server to the client. =20
    Therefore, the 3756 semantics for Service-Type =3D "Authorize-Only"
are not required for Disconnect Message.

    Requested change:
   =20
    Remove the use of Service-Type =3D 'Authorize-Only' from RFC3576bis
and disallow State in Disconnect Messages details follow.
   =20


In section 2.1.  Disconnect Messages (DM)=20
*********************************************


Remove the following:
   "A NAS MUST respond to a
   Disconnect-Request including a Service-Type Attribute with an
   unsupported value with a Disconnect-NAK; an Error-Cause Attribute
   with value "Unsupported Service" MAY be included."

And remove the following:

   "A NAS supporting the "Authorize Only" Service-Type within a
   Disconnect-Request responds with a Disconnect-NAK containing a
   Service-Type Attribute with value "Authorize Only" and an Error-Cause
   Attribute with value "Request Initiated".  The NAS will then send an
   Access-Request containing a Service-Type Attribute with a value of
   "Authorize Only", along with a State Attribute.  The RADIUS server
   MUST reply to this Access-Request with an Access-Reject.
   "


In section: 3.  Attributes
**************************

Change:
   A Disconnect-Request MUST contain only NAS and session identification
   attributes (see Section 3), as well as Service-Type, Nonce and State
   attributes.  If other attributes are included in a Disconnect-
   Request, implementations MUST send a Disconnect-NAK; an Error-Cause
   Attribute with value "Unsupported Attribute" MAY be included.

To:
   A Disconnect-Request MUST contain only NAS and session identification
   attributes (see Section 3), as well as Nonce.  If other attributes
are=20
   included in a Disconnect-Request, implementations MUST send a=20
   Disconnect-NAK; an Error-Cause Attribute with value "Unsupported
Attribute" MAY be included.

  =20
In section 3.1.  State
**********************

Change:
   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request or Disconnect-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a CoA-Request or Disconnect-Request containing a Service-
   Type value of "Authorize-Only" but lacking a State attribute MUST
   send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
   attribute with value 402 (Missing Attribute).

To:
   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a CoA-Request containing a Service-
   Type value of "Authorize-Only" but lacking a State attribute MUST
   send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
   attribute with value 402 (Missing Attribute).


In section 3.4.  Error-Cause
****************************

Change:
      "Unsupported Service" is a fatal error sent if a Service-Type
      Attribute included with the Request is sent with an invalid or
      unsupported value.
To:
      "Unsupported Service" is a fatal error sent if a Service-Type
      Attribute included with the Request is sent with an invalid or
      unsupported value.  Only valid when performing Change of
Authorization.


Change:

      "Request Initiated" is a fatal error sent in response to a Request
      including a Service-Type Attribute with a value of "Authorize
      Only".  It indicates that the Disconnect-Request or CoA-Request
      has not been honored, but that a RADIUS Access-Request including a
      Service-Type Attribute with value "Authorize Only" is being sent
      to the RADIUS server.
To:
      "Request Initiated" is a fatal error sent in response to a
CoA-Request
      including a Service-Type Attribute with a value of "Authorize
      Only".  It indicates that the CoA-Request
      has not been honored, but that a RADIUS Access-Request including a
      Service-Type Attribute with value "Authorize Only" is being sent
      to the RADIUS server.


In section 3.5.  Table of Attributes
***************************************

In the Disconnect Messages Table:

   Request   ACK      NAK   #   Attribute
  =20
Change:
   0-1       0        0-1   6   Service-Type [Note 6]
To:
   0         0        0     6   Service-Type

Change:
 0-1       0-1      0-1  24   State [Note 7]
To:
   0       0      0  24   State=20
=20
Change NOTE 6 from:

   [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
   on the NAS and RADIUS server.  A NAS supporting the "Authorize Only"
   Service-Type value within Disconnect-Request or CoA-Request packets
   MUST respond with a Disconnect-NAK or CoA-NAK respectively,
   containing a Service-Type Attribute with value "Authorize Only", and
   an Error-Cause Attribute with value "Request Initiated".  The NAS
   then sends an Access-Request to the RADIUS server with a Service-Type
   Attribute with value "Authorize Only".  This Access-Request SHOULD
   contain the NAS attributes from the Disconnect or CoA-Request, as
   well as the session attributes from the Request legal for inclusion
   in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869]
   and [RFC3162].  As noted in [RFC2869] Section 5.19, a Message-
   Authenticator attribute SHOULD be included in an Access-Request that
   does not contain a User-Password, CHAP-Password, ARAP-Password or
   EAP-Message Attribute.  The RADIUS server should send back an Access-
   Accept to (re-)authorize the session or an Access-Reject to refuse to
   (re-)authorize it.

   A NAS that does not support the Service-Type Attribute with the value
   "Authorize Only" within a Disconnect-Request MUST respond with a
   Disconnect-NAK including no Service-Type Attribute; an Error-Cause
   Attribute with value "Unsupported Service" MAY be included.  A NAS
   that does not support the Service-Type Attribute with the value
   "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
   including no Service-Type Attribute; an Error-Cause Attribute with
   value "Unsupported Service" MAY be included.

To:

   [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
   on the NAS and RADIUS server.  A NAS supporting the "Authorize Only"
   Service-Type value within a CoA-Request packet
   MUST respond with a CoA-NAK,
   containing a Service-Type Attribute with value "Authorize Only", and
   an Error-Cause Attribute with value "Request Initiated".  The NAS
   then sends an Access-Request to the RADIUS server with a Service-Type
   Attribute with value "Authorize Only".  This Access-Request SHOULD
   contain the NAS attributes from the CoA-Request, as
   well as the session attributes from the Request legal for inclusion
   in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869]
   and [RFC3162].  As noted in [RFC2869] Section 5.19, a Message-
   Authenticator attribute SHOULD be included in an Access-Request that
   does not contain a User-Password, CHAP-Password, ARAP-Password or
   EAP-Message Attribute.  The RADIUS server should send back an Access-
   Accept to (re-)authorize the session or an Access-Reject to refuse to
   (re-)authorize it.

   A NAS
   that does not support the Service-Type Attribute with the value
   "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
   including no Service-Type Attribute; an Error-Cause Attribute with
   value "Unsupported Service" MAY be included.


Change:

   [Note 7] The State Attribute is available to be sent by the RADIUS
   server to the NAS in a Disconnect-Request or CoA-Request packet and
   MUST be sent unmodified from the NAS to the RADIUS server in a
   subsequent ACK or NAK packet.  If a Service-Type Attribute with value
   "Authorize Only" is included in a Disconnect-Request or CoA-Request
   then a State Attribute MUST be present, and MUST be sent unmodified
   from the NAS to the RADIUS server in the resulting Access-Request
   sent to the RADIUS server, if any.  The State Attribute is also
   available to be sent by the RADIUS server to the NAS in a CoA-Request
   that also includes a Termination-Action Attribute with the value of
   RADIUS-Request.  If the client performs the Termination-Action by
   sending a new Access-Request upon termination of the current session,
   it MUST include the State Attribute unchanged in that Access-Request.
   In either usage, the client MUST NOT interpret the Attribute locally.
   A Disconnect- Request or CoA-Request packet must have only zero or
   one State Attribute.  Usage of the State Attribute is implementation
   dependent.  If the RADIUS server does not recognize the State
   Attribute in the Access-Request, then it MUST send an Access-Reject.

To: =20
   [Note 7] The State Attribute is available to be sent by the RADIUS
   server to the NAS in a CoA-Request packet and
   MUST be sent unmodified from the NAS to the RADIUS server in a
   subsequent ACK or NAK packet.  If a Service-Type Attribute with value
   "Authorize Only" is included in a CoA-Request
   then a State Attribute MUST be present, and MUST be sent unmodified
   from the NAS to the RADIUS server in the resulting Access-Request
   sent to the RADIUS server, if any.  The State Attribute is also
   available to be sent by the RADIUS server to the NAS in a CoA-Request
   that also includes a Termination-Action Attribute with the value of
   RADIUS-Request.  If the client performs the Termination-Action by
   sending a new Access-Request upon termination of the current session,
   it MUST include the State Attribute unchanged in that Access-Request.
   In either usage, the client MUST NOT interpret the Attribute locally.
   A Disconnect-Request or CoA-Request packet must have only zero or
   one State Attribute.  Usage of the State Attribute is implementation
   dependent. =20
  =20
NOTE: I am recommending to delete the last sentence=20

"If the RADIUS server does not recognize the State
   Attribute in the Access-Request, then it MUST send an Access-Reject."

   because it does not belong in this document.
  =20


In section 4.  Diameter Considerations
***************************************

Change:

   Since both the ASR/ASA and Disconnect-Request/Disconnect-
   NAK/Disconnect-ACK exchanges involve just a request and response,
   inclusion of an "Authorize Only" Service-Type within a Disconnect-
   Request is not needed to assist in Diameter/RADIUS translation, and
   may make translation more difficult.  As a result, inclusion of a
   Service-Type of "Authorize Only" within a Disconnect-Request is NOT
   RECOMMENDED.

To:
   Since both the ASR/ASA and Disconnect-Request/Disconnect-
   NAK/Disconnect-ACK exchanges involve just a request and response,
   inclusion of an "Authorize Only" Service-Type within a Disconnect-
   Request is not needed to assist in Diameter/RADIUS translation, and
   may make translation more difficult.  As a result, the Service-Type=20
   attribute MUST NOT be used within a Disconnect-Request.



In Appendix A - Changes from RFC 3576
**************************************

Add:

Disallowed usage of Service-Type and State attribute in
Disconnect-Message

=20
=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: Wed, 14 Mar 2007 19:42:38 +0000
Message-ID: 
From: "Bernard Aboba" 
To: avi@bridgewatersystems.com, radiusext@ops.ietf.org
Bcc: 
Subject: RE: REMINDER: RADEXT WG Last Call on RFC 3576bis
Date: Wed, 14 Mar 2007 11:41:35 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Yes.  In particular, it would be helpful if you could suggest proposed 
changes.


>From: "Avi Lior" 
>To: "Bernard Aboba" ,
>Subject: RE: REMINDER: RADEXT WG Last Call on RFC 3576bis
>Date: Tue, 13 Mar 2007 18:26:56 -0400
>
>Do you want an official issues raised?
>
>-----Original Message-----
>From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>Sent: Tuesday, March 13, 2007 4:41 PM
>To: Avi Lior; radiusext@ops.ietf.org
>Subject: RE: REMINDER: RADEXT WG Last Call on RFC 3576bis
>
>You are right.  There is no good reason to support Service-Type =
>Authorize-Only for a Disconnect-Request.  As you point out, it isn't
>needed for Diameter compatibility (in fact, it would complicate things).
>Also, what if the RADIUS server doesn't send an Access-Reject in
>response to the Access-Request?  Then it would function just like a
>CoA-Request.
>
>Assuming that there are no objections,  it might be a good idea to
>remove this.
>
> >Forgive me for asking a potentially stupid question but why is
> >Service-Type = Authorise-Only required Disconnect Message?
> >
> >I can see the use of it in Change of Authorization but why in
> >Disconnect Message?
> >
> >There is a direct command that goes from the Server to the Client in
> >Diameter and that would map directly to the Disconnect Message sent
> >from the Server to the Client. Why do we need the Service-Type =
> >Authorize-Only semantics?  It doesn't make sense.
>
>
>
>--
>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, 13 Mar 2007 22:27:11 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: REMINDER: RADEXT WG Last Call on RFC 3576bis
Date: Tue, 13 Mar 2007 18:26:56 -0400
Message-ID: 
From: "Avi Lior" 
To: "Bernard Aboba" , 

Do you want an official issues raised?=20

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20
Sent: Tuesday, March 13, 2007 4:41 PM
To: Avi Lior; radiusext@ops.ietf.org
Subject: RE: REMINDER: RADEXT WG Last Call on RFC 3576bis

You are right.  There is no good reason to support Service-Type =3D
Authorize-Only for a Disconnect-Request.  As you point out, it isn't
needed for Diameter compatibility (in fact, it would complicate things).
Also, what if the RADIUS server doesn't send an Access-Reject in
response to the Access-Request?  Then it would function just like a
CoA-Request.

Assuming that there are no objections,  it might be a good idea to
remove this.

>Forgive me for asking a potentially stupid question but why is=20
>Service-Type =3D Authorise-Only required Disconnect Message?
>
>I can see the use of it in Change of Authorization but why in=20
>Disconnect Message?
>
>There is a direct command that goes from the Server to the Client in=20
>Diameter and that would map directly to the Disconnect Message sent=20
>from the Server to the Client. Why do we need the Service-Type =3D=20
>Authorize-Only semantics?  It doesn't make sense.



--
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, 13 Mar 2007 20:40:58 +0000
Message-ID: 
From: "Bernard Aboba" 
To: avi@bridgewatersystems.com, radiusext@ops.ietf.org
Bcc: 
Subject: RE: REMINDER: RADEXT WG Last Call on RFC 3576bis
Date: Tue, 13 Mar 2007 12:40:47 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

You are right.  There is no good reason to support Service-Type = 
Authorize-Only for a Disconnect-Request.  As you point out, it isn't needed 
for Diameter compatibility (in fact, it would complicate things).  Also, 
what if the RADIUS server doesn't send an Access-Reject in response to the 
Access-Request?  Then it would function just like a CoA-Request.

Assuming that there are no objections,  it might be a good idea to remove 
this.

>Forgive me for asking a potentially stupid question but why is
>Service-Type = Authorise-Only required Disconnect Message?
>
>I can see the use of it in Change of Authorization but why in Disconnect
>Message?
>
>There is a direct command that goes from the Server to the Client in
>Diameter and that would map directly to the Disconnect Message sent from
>the Server to the Client. Why do we need the Service-Type =
>Authorize-Only semantics?  It doesn't make sense.



--
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, 13 Mar 2007 20:38:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: REMINDER: RADEXT WG Last Call on RFC 3576bis
Date: Tue, 13 Mar 2007 16:37:25 -0400
Message-ID: 
From: "Avi Lior" 
To: "Bernard Aboba" , 

Forgive me for asking a potentially stupid question but why is
Service-Type =3D Authorise-Only required Disconnect Message?

I can see the use of it in Change of Authorization but why in Disconnect
Message?

There is a direct command that goes from the Server to the Client in
Diameter and that would map directly to the Disconnect Message sent from
the Server to the Client. Why do we need the Service-Type =3D
Authorize-Only semantics?  It doesn't make sense.

=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: Mon, 12 Mar 2007 16:34:59 +0000
Message-ID: 
From: "Bernard Aboba" 
To: aland@nitros9.org
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: RE: Conflicting RADIUS && EAP retransmits (was re: Issues & Fixes..)
Date: Mon, 12 Mar 2007 08:34:13 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>   How about adding the following text at the bottom of 2.1.2:
>
>   "Implementations that do not use this algorithm are often restricted
>to having an EAP Identifier space per NAS, or perhaps one that is global
>to the implementation.  These restrictions are unnecessary when the
>above algorithm is used, which gives each session a unique EAP
>Identifier space.  The above algorithm SHOULD be used to track EAP
>sessions in preference to any other method.

This looks good.

>   Should we talk about EAP duplicate detection in a RADIUS document?  Or
>just say something about RADIUS as a transport protocol?

I agree that the proposed text is awkward.  I'd rather focus solely on 
duplicate detection within RADIUS.

The question in my mind was whether the algorithm in Section 2.1.2 also 
enabled RADIUS duplicate detection to take place on a per-session rather 
than a per-NAS basis.  That was the tradeoff that Jouni was referring to in 
his message.



--
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, 12 Mar 2007 10:33:01 +0000
Message-ID: <45F52C2D.6060805@nitros9.org>
Date: Mon, 12 Mar 2007 11:32:13 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Bernard Aboba 
CC:  radiusext@ops.ietf.org
Subject: Conflicting RADIUS && EAP retransmits (was re: Issues & Fixes..)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> However, I think we might want to explicitly state in Section 2.1.2 that
> there is no need for per-NAS Identifier restrictions, using appropriate
> normative language (SHOULD?).

  How about adding the following text at the bottom of 2.1.2:

  "Implementations that do not use this algorithm are often restricted
to having an EAP Identifier space per NAS, or perhaps one that is global
to the implementation.  These restrictions are unnecessary when the
above algorithm is used, which gives each session a unique EAP
Identifier space.  The above algorithm SHOULD be used to track EAP
sessions in preference to any other method.

> Also, in the section on duplicate detection, we should make it clear
> that this should be handled at the per-EAP session level, not the NAS
> level,  potentially using the algorithm described in Section 2.1.2.  The
> concern is that if a RADIUS server implements clumsy Identifier
> restrictions, then the ability to support duplicate detection may be
> also limited.  For example, Jouni mentions a product that, when
> duplicate detection is enabled, imposes simultaneous session
> restrictions (not clear if this was per-NAS or (shudder) per server).

  Should we talk about EAP duplicate detection in a RADIUS document?  Or
just say something about RADIUS as a transport protocol?

  The following text is awkward, to say the least.  It also opens up a
weird case, as outlined below:


2.x.x  RADIUS as a transport protocol

  RADIUS is often used as a transport protocol for other authentication
protocols such as EAP.  When a transported protocol needs to send a
duplicate packet, that packet is often carried in a RADIUS packet that
is a duplicate of the one that carried the original transported packet.
However, the RADIUS protocol requirements mandate that in some
situations a new RADIUS packet is sent, such as when the RADIUS packet
contains an Event-Timestamp attribute.   In that case, the transported
packet is identical to that sent an earlier RADIUS packet, even though
the RADIUS packet performing that transport has changed.

  When a RADIUS server acts as a transport layer for other protocols, it
SHOULD implement duplicate detection for the transported protocol in
addition to RADIUS layer duplicate detection.  The algorithm described
above in Section 2.1.2 SHOULD be used to perform this detection.

  If the RADIUS server receives a duplicate transported packet for which
 it has already sent a transported response, it SHOULD resend the
original transported response without reprocessing the transported
packet.  This transported response MAY be carried in a different RADIUS
packet than one that carried the original transported response, due to
the RADIUS requirements mentioned above.

!!! What about interaction effects? !!!

  i.e. The RADIUS server is slow, and has not responded to a request.
For EAP, the supplicant may retransmit, the NAS may send a *new* RADIUS
packet with an Event-Timestamp, containing "duplicate" EAP information.

  The RADIUS server can't send a duplicate EAP response, because it
doesn't have one.  It can't silently discard the new RADIUS packet,
because that would cause EAP to fail.  It can't respond to the original
EAP request either, because the NAS may be tracking EAP sessions via
RADIUS ID's, and it now has a new RADIUS Id for the ongoing EAP session.

  We could tie EAP retransmits to RADIUS retransmits.  i.e. forbid the
RADIUS packet to change if the underlying authentication protocol is
retransmitting.  But that's not nice.

  I guess the only thing to do is mention this possibility, and note
that the only choice is to send the duplicate transported packet to the
underlying authentication protocol... which should also do duplicate
detection, and then send duplicate responses.

  i.e.

1. Access-Request Id=1, Event-Timestamp, EAP Id=2
2. RADIUS server sends EAP packet to EAP server.
3. Access-Request ID=2, Event-Timestamp, EAP Id=2
4. RADIUS server sees no RADIUS duplicate, sends packet to EAP server
5. EAP server notices duplicate, sits on the new request
6. EAP server finishes request from stage 2, responds to BOTH stage 2 &&
 stage 4.
7. RADIUS server responds with Access-Challenge Id=1, EAP...
8. RADIUS server responds with Access-Challenge Id=2, EAP...

  where the EAP content in (7) and (8) is identical.

  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: Mon, 12 Mar 2007 08:55:42 +0000
Message-ID: <45F51553.5040401@nitros9.org>
Date: Mon, 12 Mar 2007 09:54:43 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Alper Yegin 
CC: 'Bernard Aboba' ,  radiusext@ops.ietf.org
Subject: Re: Issues & Fixes: Ordered delivery of EAP messages
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alper Yegin wrote:

> Or, we can adapt from RFC 3748 text:
...

  OK.

> And if necessary, we can also describe the other case:
> 
> 	The peer MUST silently discard any duplicate requests for which a
> 	response has not been sent yet.

  That case should be described, too.

  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: Mon, 12 Mar 2007 05:01:05 +0000
Date: Sun, 11 Mar 2007 09:26:27 -0400
To: Lakshminath Dondeti 
Message-ID: <20070311132627.GA26207@steelhead>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 
Cc: radiusext@ops.ietf.org, eap@frascone.com
Subject: Re: [eap] TLS clarifications (Re: Ordered delivery of EAP messages)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Sat, Mar 10, 2007 at 10:06:12PM -0800, Lakshminath Dondeti wrote:
> 
> Do EAP methods require in-order delivery to support any of their 
> security properties?
> 
> I think yes; for example, TTLS would need in-order delivery for
> "Replay protection:        Yes"
> in Section 9 of draft-funk-eap-ttls-v1-01.

We can ask ourselves a question similar to Avi's here: can attacker
succeed a replay attack on TTLS without in-order delivery?  I believe
the answer is no.  Instead, TTLS session would be terminated
immediately when a replayed TLS record is received.  Note that this
session termination due to an active attacker could happen even if
transport is reliable.

Yoshihiro Ohba


> 
> Thoughts?
> 
> Lakshminath
> 
> >
> >If TLS are used over unreliable transport, of course it is not
> >possible for TLS to maintain implicit sequence number.  Without
> >reliable transport implicit sequence number would not work if loss or
> >out-of-order delivery of TLS records happens and *even if there is no
> >attacker*.  That is why I think that reliable transport is needed for
> >TLS to make implicit sequence number work *correctly* so that it is
> >used for *security*.  Maybe we are talking about the same thing in
> >different ways.
> >
> >Yoshihiro Ohba
> >
> >On Sat, Mar 10, 2007 at 09:08:42PM -0800, Lakshminath Dondeti wrote:
> >>Yoshihiro Ohba wrote:
> >>>On Sat, Mar 10, 2007 at 02:37:11AM -0800, Lakshminath Dondeti wrote:
> >>>>TLS requires reliable transport for replay protection.  (I guess 
> >>>>Bernard was trying to get at this in another context in this thread)
> >>>TLS requires reliable transport for implicit sequence number to work
> >>>for replay protection.  
> >>Right, that's what I was getting at.
> >>
> >>>But this does not mean replay attack is
> >>>possible if TLS is run over unreliable transport.
> >>How is the sequence number maintained in that case?  Are you saying that 
> >>we might use an explicit sequence number as in DTLS?  But, we are not 
> >>discussing DTLS, are we?
> >>
> >>What am I missing?
> >>
> >>thanks,
> >>Lakshminath
> >>
> >>PS: To Avi's question, I was thinking in case of PEAP and TTLS if the 
> >>EAP layer cannot guarantee in-order reliable delivery, how else do the 
> >>endpoints maintain sequence numbers?  If there is no other way, we can 
> >>conclude that PEAP and TTLS require in-order reliable delivery for one 
> >>of its security guarantees.
> >>
> >>>Yoshihiro Ohba
> >>>
> >
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

--
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, 12 Mar 2007 00:27:00 +0000
Message-ID: 
From: "Bernard Aboba"
To: 
Date: Sun, 11 Mar 2007 08:50:59 -0800
Mime-Version: 1.0
Cc: , 
Subject: Re: [eap] Simultaneous session limits and duplicate detection
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>On Thu, Mar 08, 2007 at 02:46:34PM -0800, Bernard Aboba wrote:
> > Alper Yegin said:
> > "RADIUS does not talk about 1, does not properly mandate 2a...
> > If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can 
>we
> > assume all of the current RADIUS implementations are already supporting 
>2a,
> > so that in the absence of 1 and 2b EAP works well?"
> >
> > [BA] Yes, I think we can assume this. Alan's proposed language will 
>mandate
> > 2a.
>
>I hit this issue in testing couple of years ago when EAP-SIM tests
>were failing if NAS re-transmitted the Access-Request quickly. In other
>words, the RADIUS server was not doing duplicate detection.. Since then,
>this particular implementation has added support for duplicate
>detection, but I believe it can be disabled in configuration and there
>has been discussion on some deployments doing that in order to avoid
>issues with large number of requests (more than 256 per the duplicate
>window of couple of seconds, i.e., more than the number of unique
>Identifiers..).

The Issues & Fixes document Section 2.1.2 talks about how a combination of 
the EAP Identifier, source IP address and State attribute can be used to 
enable each EAP session to have its own unique Identifier space.  If handled 
this way, there would not be a tradeoff between duplicate elimination and 
restrictions on the number of simultaneous sessions that can be handled.


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

--
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, 12 Mar 2007 00:22:47 +0000
Message-ID: 
From: "Bernard Aboba"
To: 
Subject: Issues & Fixes: Duplicate Detection and Simultaneous Session Limits
Date: Sun, 11 Mar 2007 09:02:11 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

As noted in a previous message from Jouni, there appears to be a 
mis-understanding that a tradeoff exists between duplicate detection and 
simultaneous session limits.  Issues & Fixes Section 2.1.2 describes an 
algorithm that provides each EAP session with its own unique Identifier 
space, thereby removing any per-NAS Identifier limitations.

However, I think we might want to explicitly state in Section 2.1.2 that 
there is no need for per-NAS Identifier restrictions, using appropriate 
normative language (SHOULD?).

Also, in the section on duplicate detection, we should make it clear that 
this should be handled at the per-EAP session level, not the NAS level,  
potentially using the algorithm described in Section 2.1.2.  The concern is 
that if a RADIUS server implements clumsy Identifier restrictions, then the 
ability to support duplicate detection may be also limited.  For example, 
Jouni mentions a product that, when duplicate detection is enabled, imposes 
simultaneous session restrictions (not clear if this was per-NAS or 
(shudder) per server).



--
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: 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

--
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, 12 Mar 2007 00:22:40 +0000
Date: Sun, 11 Mar 2007 09:26:27 -0400
To: Lakshminath Dondeti
Cc: Yoshihiro Ohba, Avi Lior, , 
Subject: Re: TLS clarifications (Re: [eap] Ordered delivery of EAP messages)
Message-ID: <20070311132627.GA26207@steelhead>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba

On Sat, Mar 10, 2007 at 10:06:12PM -0800, Lakshminath Dondeti wrote:
> 
> Do EAP methods require in-order delivery to support any of their 
> security properties?
> 
> I think yes; for example, TTLS would need in-order delivery for
> "Replay protection:        Yes"
> in Section 9 of draft-funk-eap-ttls-v1-01.

We can ask ourselves a question similar to Avi's here: can attacker
succeed a replay attack on TTLS without in-order delivery?  I believe
the answer is no.  Instead, TTLS session would be terminated
immediately when a replayed TLS record is received.  Note that this
session termination due to an active attacker could happen even if
transport is reliable.

Yoshihiro Ohba


> 
> Thoughts?
> 
> Lakshminath
> 
> >
> >If TLS are used over unreliable transport, of course it is not
> >possible for TLS to maintain implicit sequence number.  Without
> >reliable transport implicit sequence number would not work if loss or
> >out-of-order delivery of TLS records happens and *even if there is no
> >attacker*.  That is why I think that reliable transport is needed for
> >TLS to make implicit sequence number work *correctly* so that it is
> >used for *security*.  Maybe we are talking about the same thing in
> >different ways.
> >
> >Yoshihiro Ohba
> >
> >On Sat, Mar 10, 2007 at 09:08:42PM -0800, Lakshminath Dondeti wrote:
> >>Yoshihiro Ohba wrote:
> >>>On Sat, Mar 10, 2007 at 02:37:11AM -0800, Lakshminath Dondeti wrote:
> >>>>TLS requires reliable transport for replay protection.  (I guess 
> >>>>Bernard was trying to get at this in another context in this thread)
> >>>TLS requires reliable transport for implicit sequence number to work
> >>>for replay protection.  
> >>Right, that's what I was getting at.
> >>
> >>>But this does not mean replay attack is
> >>>possible if TLS is run over unreliable transport.
> >>How is the sequence number maintained in that case?  Are you saying that 
> >>we might use an explicit sequence number as in DTLS?  But, we are not 
> >>discussing DTLS, are we?
> >>
> >>What am I missing?
> >>
> >>thanks,
> >>Lakshminath
> >>
> >>PS: To Avi's question, I was thinking in case of PEAP and TTLS if the 
> >>EAP layer cannot guarantee in-order reliable delivery, how else do the 
> >>endpoints maintain sequence numbers?  If there is no other way, we can 
> >>conclude that PEAP and TTLS require in-order reliable delivery for one 
> >>of its security guarantees.
> >>
> >>>Yoshihiro Ohba
> >>>
> >
> 

--
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: 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

--
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, 11 Mar 2007 23:50:22 +0000
From: "Alper Yegin" 
To: "'Alper Yegin'" , "'Glen Zorn \(gwz\)'" , "'Bernard Aboba'" , 
Cc: , , 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Mon, 12 Mar 2007 01:48:51 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdgMQqMZiN0SjwXQHuDtOzsvDkSoQAE0rIQAA7veWAACzDP0AAd/fsgACh/YJAAmzE50A==
Message-ID: <0MKp2t-1HQXmb1pdI-0007vf@mrelay.perfora.net>

> Given that EAP is a lock-step protocol, any one of the three remedies is
> sufficient to ensure packets never get out of order:
> 
> 1-  EAP lower layer ensures ordering
> 2a- EAP lower layer eliminates duplicates
> 2b- EAP eliminates duplicates
> 
> Having more than one of the remedies is not necessary.
> 
> Correct?

Hmmm... It appears like 2a alone is not sufficient, but it also needs to be
coupled with "reliable delivery" at the EAP lower layer. Or, in other words,
2a makes sense only when we have a reliable lower layer.


If the retransmissions are not generated by the lower layer, there is no
"duplicates" that can be caught and eliminated by the lower layer.

So, I think 2a should read:

2a- EAP-layer retransmissions is disabled, EAP lower layer is reliable and
eliminates duplicates



Alper









> 
> RADIUS does not talk about 1, does not properly mandate 2a.
> 
> EAP mandates 2a. It talks about 2b, but falls short of using normative
> language (no MUSTs or SHOULDs).
> 
> 
> If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can we
> assume all of the current RADIUS implementations are already supporting
2a,
> so that in the absence of 1 and 2b EAP works well?
> 
> If we decide to go with 2b, we need to fix EAP spec. Meanwhile, can we
> assume all of the current EAP implementations are already supporting 2b,
> so that in the absence of 1 and 2a EAP works well?
> 
> If we decide to go with 1, we need to fix RADIUS spec. Meanwhile, can we
> assume all of the current RADIUS implementations are already supporting 1,
> so that in the absence of 2a and 2b EAP works well?
> 
> 
> ...
> 
> We have at least two on-going designs that are gated on this decision. One
> in WiMAX Forum, and another PANA.
> 
> 
> Alper
> 
> 
> 
> > -----Original Message-----
> > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> > Sent: Thursday, March 08, 2007 4:01 AM
> > To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
> > Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> > Subject: RE: [eap] Ordered delivery of EAP messages
> >
> > Alper Yegin  allegedly scribbled on
> > Wednesday, March 07, 2007 3:39 AM:
> >
> > >> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
> > >> well?
> > >
> > > With the appropriate normative text in the RFC covering both end
> > > points this could be used. But we don't have such text in RFC 3748.
> >
> > OK, so what is the real purpose of the Identifier in EAP?  I would have
> > thought that this would be one:
> >
> >    [5] Possible duplication.  Where the lower layer is reliable, it will
> >        provide the EAP layer with a non-duplicated stream of packets.
> >        However,  while it is desirable that lower layers provide for
> >        non-duplication, this is not a requirement.  The Identifier field
> >        provides both the peer and authenticator with the ability to
> >        detect duplicates.
> >
> > But I'm hearing that this is N/A because somebody didn't bother to
> > implement it...
> >
> > >
> > > Alper
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> > >> Sent: Wednesday, March 07, 2007 8:17 AM
> > >> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
> > >> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> > >> Subject: RE: [eap] Ordered delivery of EAP messages
> > >>
> > >> Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25
> > >> PM:
> > >>
> > >>>> Both EAP and RADIUS do not detect duplicates arriving out of order;
> > >>>> they depend on the underlying lower layer to provide in-order
> > >>>> delivery so as to enable duplicate detection.
> > >>>
> > >>> RFC 2865 says:
> > >>>
> > >>>       The RADIUS server can detect a duplicate request if
> > >>>       it has the same client source IP address and source UDP port
> > >>>       and Identifier within a short span of time.
> > >>>
> > >>> This, to me, implies duplicate detection on the server side does not
> > >>> rely on orderly delivery. Keeping the history for "a short span of
> > >>> time" allows duplicate detection irrespective of the order the
> > >>> requests come in.
> > >>
> > >> Agree.
> > >>
> > >>>
> > >>> As for the responses... Assuming the RADIUS client transmitted a
> > >>> request twice (first one timed out), if it receives one of the
> > >>> responses, would it still accept the second (duplicate) response if
> > >>> it arrives as well? Wouldn't the RADIUS client just drop the second
> > >>> response because there is no outstanding request to match anymore?
> > >>
> > >> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
> > >> well?
> > >>
> > >>>
> > >>>
> > >>> Alper


--
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, 11 Mar 2007 17:02:25 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Issues & Fixes: Duplicate Detection and Simultaneous Session Limits
Date: Sun, 11 Mar 2007 09:02:11 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

As noted in a previous message from Jouni, there appears to be a 
mis-understanding that a tradeoff exists between duplicate detection and 
simultaneous session limits.  Issues & Fixes Section 2.1.2 describes an 
algorithm that provides each EAP session with its own unique Identifier 
space, thereby removing any per-NAS Identifier limitations.

However, I think we might want to explicitly state in Section 2.1.2 that 
there is no need for per-NAS Identifier restrictions, using appropriate 
normative language (SHOULD?).

Also, in the section on duplicate detection, we should make it clear that 
this should be handled at the per-EAP session level, not the NAS level,  
potentially using the algorithm described in Section 2.1.2.  The concern is 
that if a RADIUS server implements clumsy Identifier restrictions, then the 
ability to support duplicate detection may be also limited.  For example, 
Jouni mentions a product that, when duplicate detection is enabled, imposes 
simultaneous session restrictions (not clear if this was per-NAS or 
(shudder) per server).



--
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, 11 Mar 2007 16:51:57 +0000
Message-ID: 
From: "Bernard Aboba" 
To: j@w1.fi
Cc: alper.yegin@yegin.org, eap@frascone.com, radiusext@ops.ietf.org
Bcc: 
Subject: Re: Simultaneous session limits and duplicate detection
Date: Sun, 11 Mar 2007 08:50:59 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>On Thu, Mar 08, 2007 at 02:46:34PM -0800, Bernard Aboba wrote:
> > Alper Yegin said:
> > "RADIUS does not talk about 1, does not properly mandate 2a...
> > If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can 
>we
> > assume all of the current RADIUS implementations are already supporting 
>2a,
> > so that in the absence of 1 and 2b EAP works well?"
> >
> > [BA] Yes, I think we can assume this. Alan's proposed language will 
>mandate
> > 2a.
>
>I hit this issue in testing couple of years ago when EAP-SIM tests
>were failing if NAS re-transmitted the Access-Request quickly. In other
>words, the RADIUS server was not doing duplicate detection.. Since then,
>this particular implementation has added support for duplicate
>detection, but I believe it can be disabled in configuration and there
>has been discussion on some deployments doing that in order to avoid
>issues with large number of requests (more than 256 per the duplicate
>window of couple of seconds, i.e., more than the number of unique
>Identifiers..).

The Issues & Fixes document Section 2.1.2 talks about how a combination of 
the EAP Identifier, source IP address and State attribute can be used to 
enable each EAP session to have its own unique Identifier space.  If handled 
this way, there would not be a tradeoff between duplicate elimination and 
restrictions on the number of simultaneous sessions that can be handled.



--
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, 11 Mar 2007 13:27:17 +0000
Date: Sun, 11 Mar 2007 09:26:27 -0400
To: Lakshminath Dondeti 
Cc: Yoshihiro Ohba , Avi Lior , radiusext@ops.ietf.org, eap@frascone.com
Subject: Re: TLS clarifications (Re: [eap] Ordered delivery of EAP messages)
Message-ID: <20070311132627.GA26207@steelhead>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 

On Sat, Mar 10, 2007 at 10:06:12PM -0800, Lakshminath Dondeti wrote:
> 
> Do EAP methods require in-order delivery to support any of their 
> security properties?
> 
> I think yes; for example, TTLS would need in-order delivery for
> "Replay protection:        Yes"
> in Section 9 of draft-funk-eap-ttls-v1-01.

We can ask ourselves a question similar to Avi's here: can attacker
succeed a replay attack on TTLS without in-order delivery?  I believe
the answer is no.  Instead, TTLS session would be terminated
immediately when a replayed TLS record is received.  Note that this
session termination due to an active attacker could happen even if
transport is reliable.

Yoshihiro Ohba


> 
> Thoughts?
> 
> Lakshminath
> 
> >
> >If TLS are used over unreliable transport, of course it is not
> >possible for TLS to maintain implicit sequence number.  Without
> >reliable transport implicit sequence number would not work if loss or
> >out-of-order delivery of TLS records happens and *even if there is no
> >attacker*.  That is why I think that reliable transport is needed for
> >TLS to make implicit sequence number work *correctly* so that it is
> >used for *security*.  Maybe we are talking about the same thing in
> >different ways.
> >
> >Yoshihiro Ohba
> >
> >On Sat, Mar 10, 2007 at 09:08:42PM -0800, Lakshminath Dondeti wrote:
> >>Yoshihiro Ohba wrote:
> >>>On Sat, Mar 10, 2007 at 02:37:11AM -0800, Lakshminath Dondeti wrote:
> >>>>TLS requires reliable transport for replay protection.  (I guess 
> >>>>Bernard was trying to get at this in another context in this thread)
> >>>TLS requires reliable transport for implicit sequence number to work
> >>>for replay protection.  
> >>Right, that's what I was getting at.
> >>
> >>>But this does not mean replay attack is
> >>>possible if TLS is run over unreliable transport.
> >>How is the sequence number maintained in that case?  Are you saying that 
> >>we might use an explicit sequence number as in DTLS?  But, we are not 
> >>discussing DTLS, are we?
> >>
> >>What am I missing?
> >>
> >>thanks,
> >>Lakshminath
> >>
> >>PS: To Avi's question, I was thinking in case of PEAP and TTLS if the 
> >>EAP layer cannot guarantee in-order reliable delivery, how else do the 
> >>endpoints maintain sequence numbers?  If there is no other way, we can 
> >>conclude that PEAP and TTLS require in-order reliable delivery for one 
> >>of its security guarantees.
> >>
> >>>Yoshihiro Ohba
> >>>
> >
> 

--
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, 11 Mar 2007 05:57:15 +0000
Date: Sun, 11 Mar 2007 00:56:16 -0500
To: Lakshminath Dondeti 
Cc: Yoshihiro Ohba , Avi Lior , radiusext@ops.ietf.org, eap@frascone.com
Subject: Re: TLS clarifications (Re: [eap] Ordered delivery of EAP messages)
Message-ID: <20070311055609.GC22843@steelhead>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 

Let's forget about DTLS and focus on TLS.  I was arguing that
correctness and security are different things.

If TLS are used over unreliable transport, of course it is not
possible for TLS to maintain implicit sequence number.  Without
reliable transport implicit sequence number would not work if loss or
out-of-order delivery of TLS records happens and *even if there is no
attacker*.  That is why I think that reliable transport is needed for
TLS to make implicit sequence number work *correctly* so that it is
used for *security*.  Maybe we are talking about the same thing in
different ways.

Yoshihiro Ohba

On Sat, Mar 10, 2007 at 09:08:42PM -0800, Lakshminath Dondeti wrote:
> Yoshihiro Ohba wrote:
> >On Sat, Mar 10, 2007 at 02:37:11AM -0800, Lakshminath Dondeti wrote:
> >>TLS requires reliable transport for replay protection.  (I guess Bernard 
> >>was trying to get at this in another context in this thread)
> >
> >TLS requires reliable transport for implicit sequence number to work
> >for replay protection.  
> 
> Right, that's what I was getting at.
> 
> >But this does not mean replay attack is
> >possible if TLS is run over unreliable transport.
> 
> How is the sequence number maintained in that case?  Are you saying that 
> we might use an explicit sequence number as in DTLS?  But, we are not 
> discussing DTLS, are we?
> 
> What am I missing?
> 
> thanks,
> Lakshminath
> 
> PS: To Avi's question, I was thinking in case of PEAP and TTLS if the 
> EAP layer cannot guarantee in-order reliable delivery, how else do the 
> endpoints maintain sequence numbers?  If there is no other way, we can 
> conclude that PEAP and TTLS require in-order reliable delivery for one 
> of its security guarantees.
> 
> >
> >Yoshihiro Ohba
> >
> 

--
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, 11 Mar 2007 02:11:32 +0000
Date: Sat, 10 Mar 2007 21:10:11 -0500
To: Lakshminath Dondeti 
Cc: Yoshihiro Ohba , Avi Lior , radiusext@ops.ietf.org, eap@frascone.com
Subject: Re: TLS clarifications (Re: [eap] Ordered delivery of EAP messages)
Message-ID: <20070311021010.GB10637@steelhead>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 

On Sat, Mar 10, 2007 at 02:37:11AM -0800, Lakshminath Dondeti wrote:
> 
> TLS requires reliable transport for replay protection.  (I guess Bernard 
> was trying to get at this in another context in this thread)

TLS requires reliable transport for implicit sequence number to work
for replay protection.  But this does not mean replay attack is
possible if TLS is run over unreliable transport.

Yoshihiro Ohba

--
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, 09 Mar 2007 22:40:11 +0000
From: "Alper Yegin" 
To: "'Alan DeKok'" 
Cc: "'Bernard Aboba'" , 
Subject: RE: Issues & Fixes: Ordered delivery of EAP messages
Date: Sat, 10 Mar 2007 00:38:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdiJ00Xi9k7fs7iRgSLWg4m6PE5FQAczP6g
Message-ID: <0MKoyl-1HPnjr3moV-0001rP@mrelay.perfora.net>

> >> ...  If no response is
> >> available, the duplicate Access-Request MUST be silently discarded.
> >
> > And in that case, protocol stalls... If the RADIUS server sent response
> to
> > the request, but the RADIUS client hasn't received it, the client will
> > retransmit the request but according to this text the server will keep
> > dropping the retransmitted requests.
> 
>   Your statement assumes that the server sent a response, but did not
> cache it.  So for that reason (and others), the text about caching will
> be MUST, rather than SHOULD.
> 
>   i.e. SHOULD cache means that it might not, leading to the problem you
> noted above.
> 
> > RADIUS server MUST respond to duplicate requests.
> 
>   Not in all cases.  See the following logic flow for why:
> 
> 1. RADIUS server receives & caches Access-Request
> 2. RADIUS server responds with, and caches Access-Accept (etc.)
> 3. RADIUS server receives duplicate Access-Request
> 4. RADIUS server sends duplicate Access-Accept (etc.)
> 
>   But there's a race condition:
> 
> 1a. RADIUS server receives duplicate Access-Request
> 
>   And the server hasn't yet responded with an Access-Accept.  In that
> case, the ONLY thing the server can do is to silently discard the
> duplicate.  It can't reply, because a reply doesn't exist.  It can't
> process it, because it's already being processed.  (And processing it
> again would negate the effectiveness of the duplicate detection.)
> 
>   How about changing the text to say:
> 
>  .. If a response is not yet available for any reason, the duplicate
> Access-Request MUST be silently discarded.
> 
>   Would that address your concerns?

Or, we can adapt from RFC 3748 text:

      If a peer receives a valid duplicate Request for which it has
      already sent a Response, it MUST resend its original Response
      without reprocessing the Request.

And if necessary, we can also describe the other case:

	The peer MUST silently discard any duplicate requests for which a
	response has not been sent yet.


Alper


> 
>   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: Fri, 09 Mar 2007 08:45:42 +0000
Message-ID: <45F11EA1.5020402@nitros9.org>
Date: Fri, 09 Mar 2007 09:45:21 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Alper Yegin 
CC: 'Bernard Aboba' ,  radiusext@ops.ietf.org
Subject: Re: Issues & Fixes: Ordered delivery of EAP messages
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alper Yegin wrote:
>> ...  If no response is
>> available, the duplicate Access-Request MUST be silently discarded.  
> 
> And in that case, protocol stalls... If the RADIUS server sent response to
> the request, but the RADIUS client hasn't received it, the client will
> retransmit the request but according to this text the server will keep
> dropping the retransmitted requests.

  Your statement assumes that the server sent a response, but did not
cache it.  So for that reason (and others), the text about caching will
be MUST, rather than SHOULD.

  i.e. SHOULD cache means that it might not, leading to the problem you
noted above.

> RADIUS server MUST respond to duplicate requests. 

  Not in all cases.  See the following logic flow for why:

1. RADIUS server receives & caches Access-Request
2. RADIUS server responds with, and caches Access-Accept (etc.)
3. RADIUS server receives duplicate Access-Request
4. RADIUS server sends duplicate Access-Accept (etc.)

  But there's a race condition:

1a. RADIUS server receives duplicate Access-Request

  And the server hasn't yet responded with an Access-Accept.  In that
case, the ONLY thing the server can do is to silently discard the
duplicate.  It can't reply, because a reply doesn't exist.  It can't
process it, because it's already being processed.  (And processing it
again would negate the effectiveness of the duplicate detection.)

  How about changing the text to say:

 .. If a response is not yet available for any reason, the duplicate
Access-Request MUST be silently discarded.

  Would that address your concerns?

  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: Fri, 09 Mar 2007 08:39:44 +0000
Message-ID: <45F11D0B.7060600@nitros9.org>
Date: Fri, 09 Mar 2007 09:38:35 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Alper Yegin 
CC: "'Glen Zorn (gwz)'" ,  'Bernard Aboba' , peterd@iea-software.com,  Pasi.Eronen@nokia.com,  eap@frascone.com,  radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alper Yegin wrote:
> EAP gets confused if it ever receives packets out of order.

  Are we saying that the individual EAP methods do not need to catch
invalid state transitions?

> Given that EAP is a lock-step protocol, any one of the three remedies is
> sufficient to ensure packets never get out of order:
> 
> 1-  EAP lower layer ensures ordering
> 2a- EAP lower layer eliminates duplicates
> 2b- EAP eliminates duplicates
> 
> Having more than one of the remedies is not necessary.

  Yes.

> RADIUS does not talk about 1, does not properly mandate 2a.

  Yes.  That will be fixed in the next release of the Issues & Fixes draft.

> If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can we
> assume all of the current RADIUS implementations are already supporting 2a,
> so that in the absence of 1 and 2b EAP works well?

  No.

  While all non-toy RADIUS implementations I'm aware of already do
duplicate detection, this has nothing whatsoever to do with EAP.  There
are EAP-only servers, and those servers MUST ALSO perform duplicate
detection, or an approach with similar results.  This mandate needs to
be part of the EAP specification.

  The RADIUS spec will be fixed independently of EAP, but at the same
time, for the same reasons.

  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: Fri, 09 Mar 2007 04:29:32 +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: [eap] Ordered delivery of EAP messages
Date: Thu, 8 Mar 2007 20:28:43 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250391A8E9@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: AcdgMQqMZiN0SjwXQHuDtOzsvDkSoQAE0rIQAA7veWAACzDP0AAd/fsgACh/YJAADuNrwA==
From: "Glen Zorn \(gwz\)" 
To: "Alper Yegin" , "Bernard Aboba" , 
Cc: , , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5013; t=1173414531; x=1174278531; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=FhrMEcG6U+st2ynqb9u0y5pEFfckpfNH60Wk2EH8sVQ=; b=MIGlGjC/uMMad0+myg1I6GJd7JS4SyRIvXVzsJdDaN1ZIBsfi7hJiyKrA49tpmYoMflLEB8S Y1sf/XmuGdfPPv+3mlP80HtGHZzk26mgNsL16TzuPB7C0yLJteLQ/eWr;
Authentication-Results: sj-dkim-7; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; );

Alper Yegin  allegedly scribbled on
Thursday, March 08, 2007 1:41 PM:

> EAP gets confused if it ever receives packets out of order.

So does RADIUS, unless it takes the same steps as recommended in RFC3748
for EAP.

>=20
> Given that EAP is a lock-step protocol, any one of the three remedies
> is sufficient to ensure packets never get out of order:=20
>=20
> 1-  EAP lower layer ensures ordering
> 2a- EAP lower layer eliminates duplicates
> 2b- EAP eliminates duplicates
>=20
> Having more than one of the remedies is not necessary.
>=20
> Correct?

Yes.

>=20
> RADIUS does not talk about 1, does not properly mandate 2a.
>=20
> EAP mandates 2a. It talks about 2b, but falls short of using
> normative language (no MUSTs or SHOULDs).=20
>=20
>=20
> If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile,
> can we assume all of the current RADIUS implementations are already
> supporting 2a, so that in the absence of 1 and 2b EAP works well?=20

No, not all.
=20
>=20
> If we decide to go with 2b, we need to fix EAP spec. Meanwhile, can
> we assume all of the current EAP implementations are already
> supporting 2b, so that in the absence of 1 and 2a EAP works well?=20

Again, not all; however in both cases the implementations that don't can
reasonably be considered to be broken, I think.
=20
>=20
> If we decide to go with 1, we need to fix RADIUS spec. Meanwhile, can
> we assume all of the current RADIUS implementations are already
> supporting 1, so that in the absence of 2a and 2b EAP works well?=20

If we go with either 1 or 2b for EAP, then it still doesn't fix the
problem because the transport under RADIUS doesn't guarantee ordered
delivery, either.
=20
>=20
>=20
> ...
>=20
> We have at least two on-going designs that are gated on this
> decision. One in WiMAX Forum, and another PANA.=20
>=20
>=20
> Alper
>=20
>=20
>=20
>> -----Original Message-----
>> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
>> Sent: Thursday, March 08, 2007 4:01 AM
>> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
>> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
>> Subject: RE: [eap] Ordered delivery of EAP messages
>>=20
>> Alper Yegin  allegedly scribbled on
>> Wednesday, March 07, 2007 3:39 AM:
>>=20
>>>> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
>>>> well?
>>>=20
>>> With the appropriate normative text in the RFC covering both end
>>> points this could be used. But we don't have such text in RFC 3748.
>>=20
>> OK, so what is the real purpose of the Identifier in EAP?  I would
>> have thought that this would be one:
>>=20
>>    [5] Possible duplication.  Where the lower layer is reliable, it
>>        will provide the EAP layer with a non-duplicated stream of
>>        packets. However,  while it is desirable that lower layers
>>        provide for non-duplication, this is not a requirement.  The
>>        Identifier field provides both the peer and authenticator
>> with the ability to        detect duplicates.=20
>>=20
>> But I'm hearing that this is N/A because somebody didn't bother to
>> implement it...=20
>>=20
>>>=20
>>> Alper
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
>>>> Sent: Wednesday, March 07, 2007 8:17 AM
>>>> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
>>>> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
>>>> Subject: RE: [eap] Ordered delivery of EAP messages
>>>>=20
>>>> Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25
>>>> PM:=20
>>>>=20
>>>>>> Both EAP and RADIUS do not detect duplicates arriving out of
>>>>>> order; they depend on the underlying lower layer to provide
>>>>>> in-order delivery so as to enable duplicate detection.
>>>>>=20
>>>>> RFC 2865 says:
>>>>>=20
>>>>>       The RADIUS server can detect a duplicate request if
>>>>>       it has the same client source IP address and source UDP port
>>>>>       and Identifier within a short span of time.
>>>>>=20
>>>>> This, to me, implies duplicate detection on the server side does
>>>>> not rely on orderly delivery. Keeping the history for "a short
>>>>> span of time" allows duplicate detection irrespective of the order
>>>>> the requests come in.
>>>>=20
>>>> Agree.
>>>>=20
>>>>>=20
>>>>> As for the responses... Assuming the RADIUS client transmitted a
>>>>> request twice (first one timed out), if it receives one of the
>>>>> responses, would it still accept the second (duplicate) response
>>>>> if it arrives as well? Wouldn't the RADIUS client just drop the
>>>>> second response because there is no outstanding request to match
>>>>> anymore?=20
>>>>=20
>>>> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
>>>> well?=20
>>>>=20
>>>>>=20
>>>>>=20
>>>>> Alper

--
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, 09 Mar 2007 02:28:14 +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: [eap] Ordered delivery of EAP messages
Date: Thu, 8 Mar 2007 18:27:17 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250391A892@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: AcdhhS3FhMK4FrTNRQKkSmdFkeMN1gAbSDug
From: "Glen Zorn \(gwz\)" 
To: "Yoshihiro Ohba" 
Cc: "Avi Lior" , , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1001; t=1173407246; x=1174271246; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=OCNikWFtP8COwfn7h9nLT3FyFeqms5VO3FKfmUbIm7I=; b=susOKH+vi7GV6tUzOGdgHrQ19AuARrnrwATxg51GC5WGkL0gcReF263pUkq9BkDGtAqLQFqR 31psReQC0LN9kFIyv2Zg0fky+kP1no0eJ40lZL+Pvie+kdVhN5puHnoI;
Authentication-Results: sj-dkim-6; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; );

Yoshihiro Ohba  allegedly scribbled on
Thursday, March 08, 2007 5:25 AM:

> Glen,
>=20
> On Wed, Mar 07, 2007 at 10:15:24PM -0800, Glen Zorn (gwz) wrote:
>>=20
>> My basic argument is that EAP _does_ work over a transport that
>> doesn't guarantee in-order delivery (the example being RADIUS) except
>> in a deep, dark, cobweb-filled corner case.  The arguments have been
>> that "well-behaved" RADIUS implementations exhibit what amounts to
>> in-order delivery despite the fact that it is not required by the
>> RFCs=20
>> but badly behaved EAP implementations will fail in a contrived,
>> pathological case. I am saying that a badly-behaved RADIUS
>> implementation would fail in=20
>> that same pathological case and the converse.
>>=20
>=20
> Which case do you mean by "badly-behaved EAP implementations"?

I expect that any implementation that would fall prey to Pasi's
pathological example would be badly behaved.

>=20
> Yoshihiro Ohba

--
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, 08 Mar 2007 21:42:02 +0000
From: "Alper Yegin" 
To: "'Glen Zorn \(gwz\)'" , "'Bernard Aboba'" , 
Cc: , , 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Thu, 8 Mar 2007 23:41:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdgMQqMZiN0SjwXQHuDtOzsvDkSoQAE0rIQAA7veWAACzDP0AAd/fsgACh/YJA=
Message-ID: <0MKoyl-1HPQMH3sDJ-0001l1@mrelay.perfora.net>

EAP gets confused if it ever receives packets out of order.

Given that EAP is a lock-step protocol, any one of the three remedies is
sufficient to ensure packets never get out of order:

1-  EAP lower layer ensures ordering
2a- EAP lower layer eliminates duplicates
2b- EAP eliminates duplicates

Having more than one of the remedies is not necessary.

Correct?
 
RADIUS does not talk about 1, does not properly mandate 2a.

EAP mandates 2a. It talks about 2b, but falls short of using normative
language (no MUSTs or SHOULDs).

 
If we decide to go with 2a, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 2a,
so that in the absence of 1 and 2b EAP works well?

If we decide to go with 2b, we need to fix EAP spec. Meanwhile, can we
assume all of the current EAP implementations are already supporting 2b, so
that in the absence of 1 and 2a EAP works well?

If we decide to go with 1, we need to fix RADIUS spec. Meanwhile, can we
assume all of the current RADIUS implementations are already supporting 1,
so that in the absence of 2a and 2b EAP works well?


...

We have at least two on-going designs that are gated on this decision. One
in WiMAX Forum, and another PANA. 


Alper



> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> Sent: Thursday, March 08, 2007 4:01 AM
> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> Subject: RE: [eap] Ordered delivery of EAP messages
> 
> Alper Yegin  allegedly scribbled on
> Wednesday, March 07, 2007 3:39 AM:
> 
> >> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
> >> well?
> >
> > With the appropriate normative text in the RFC covering both end
> > points this could be used. But we don't have such text in RFC 3748.
> 
> OK, so what is the real purpose of the Identifier in EAP?  I would have
> thought that this would be one:
> 
>    [5] Possible duplication.  Where the lower layer is reliable, it will
>        provide the EAP layer with a non-duplicated stream of packets.
>        However,  while it is desirable that lower layers provide for
>        non-duplication, this is not a requirement.  The Identifier field
>        provides both the peer and authenticator with the ability to
>        detect duplicates.
> 
> But I'm hearing that this is N/A because somebody didn't bother to
> implement it...
> 
> >
> > Alper
> >
> >
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> >> Sent: Wednesday, March 07, 2007 8:17 AM
> >> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
> >> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> >> Subject: RE: [eap] Ordered delivery of EAP messages
> >>
> >> Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25
> >> PM:
> >>
> >>>> Both EAP and RADIUS do not detect duplicates arriving out of order;
> >>>> they depend on the underlying lower layer to provide in-order
> >>>> delivery so as to enable duplicate detection.
> >>>
> >>> RFC 2865 says:
> >>>
> >>>       The RADIUS server can detect a duplicate request if
> >>>       it has the same client source IP address and source UDP port
> >>>       and Identifier within a short span of time.
> >>>
> >>> This, to me, implies duplicate detection on the server side does not
> >>> rely on orderly delivery. Keeping the history for "a short span of
> >>> time" allows duplicate detection irrespective of the order the
> >>> requests come in.
> >>
> >> Agree.
> >>
> >>>
> >>> As for the responses... Assuming the RADIUS client transmitted a
> >>> request twice (first one timed out), if it receives one of the
> >>> responses, would it still accept the second (duplicate) response if
> >>> it arrives as well? Wouldn't the RADIUS client just drop the second
> >>> response because there is no outstanding request to match anymore?
> >>
> >> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
> >> well?
> >>
> >>>
> >>>
> >>> Alper


--
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, 08 Mar 2007 21:34:08 +0000
Message-ID: 
From: "Bernard Aboba" 
To: alper.yegin@yegin.org, aland@deployingradius.com
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: RE: Issues & Fixes: Ordered delivery of EAP messages
Date: Thu, 08 Mar 2007 13:33:50 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>Why not MUST? Why leave the door open for some implementations to go 
>without
>dup detection, and have more of these discussions in the future?

OK.  Having no more of these discussions is a very persuasive argument :)



--
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, 08 Mar 2007 21:26:44 +0000
From: "David B. Nelson" 
To: 
Subject: RE: Issues & Fixes: Ordered delivery of EAP messages
Date: Thu, 8 Mar 2007 16:26:15 -0500
Message-ID: <01f701c761c8$740ad950$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acdhw72NzvnMB1GpRXein80GOVNLeAABISXw

Bernard Aboba writes...

> If the server implements duplicate detection, then it 
> MUST NOT process the duplicates again.

Ah, so this is a "conditional" MUST NOT?




--
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, 08 Mar 2007 21:14:21 +0000
From: "Alper Yegin" 
To: "'Bernard Aboba'" , 
Cc: 
Subject: RE: Issues & Fixes: Ordered delivery of EAP messages
Date: Thu, 8 Mar 2007 23:13:44 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdhmmRcBiVt7PjrSWuougIjkayDBQAK13iQ
Message-ID: <0MKp2t-1HPPvo1fd6-0006Eu@mrelay.perfora.net>

> 
> We therefore recommend that RADIUS servers SHOULD

Why not MUST? Why leave the door open for some implementations to go without
dup detection, and have more of these discussions in the future?

> implement duplicate detection for Access-Request packets, as described
> in Section 3 of [RFC2865].  Implementations SHOULD also cache the
> responses to those Access-Request packets.  If a duplicate
> Access-Request packet is detected, the server MUST respond with a
> previously sent response packet (Access-Accept, Access-Challenge, or
> Access-Reject), if that packet is available.  If no response is
> available, the duplicate Access-Request MUST be silently discarded.  

And in that case, protocol stalls... If the RADIUS server sent response to
the request, but the RADIUS client hasn't received it, the client will
retransmit the request but according to this text the server will keep
dropping the retransmitted requests.

RADIUS server MUST respond to duplicate requests. 

> In
> either case, the server MUST NOT process the duplicate Access-Request
> again, as though it was an independent new request.

Yes, that's needed. This simply suggests caching the responses. Keep that
MUST NOT and recommend caching as a way to achieve this requirement.

Alper



> 
> 
> 
> --
> 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, 08 Mar 2007 20:53:29 +0000
Message-ID: 
From: "Bernard Aboba" 
To: d.b.nelson@comcast.net, radiusext@ops.ietf.org
Bcc: 
Subject: RE: Issues & Fixes: Ordered delivery of EAP messages
Date: Thu, 08 Mar 2007 12:52:47 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>How is this SHOULD
>
> > We therefore recommend that RADIUS servers SHOULD
> > implement duplicate detection for Access-Request
> > packets, as described in Section 3 of [RFC2865].
>
>consistent with this MUST NOT?
>
> > ... the server MUST NOT process the duplicate Access-Request
> > again, as though it was an independent new request.

If the server implements duplicate detection, then it MUST NOT process the 
duplicates again. This is not inconsistent with saying that the server 
SHOULD implement duplicate detection.



--
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, 08 Mar 2007 17:59:00 +0000
From: "David B. Nelson" 
To: 
Subject: RE: Issues & Fixes: Ordered delivery of EAP messages
Date: Thu, 8 Mar 2007 12:15:30 -0500
Message-ID: <00ae01c761a5$61483a10$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acdhmnk52RAfUHp5QmiM2pGCr+x6EwACpeVA

Bernard Aboba writes...

How is this SHOULD

> We therefore recommend that RADIUS servers SHOULD
> implement duplicate detection for Access-Request 
> packets, as described in Section 3 of [RFC2865].

consistent with this MUST NOT?

> ... the server MUST NOT process the duplicate Access-Request
> again, as though it was an independent new request.




--
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, 08 Mar 2007 17:57:33 +0000
From: "David B. Nelson" 
To: "'Avi Lior'" , 
Subject: RE: Issue with draft-ietf-radext-fixes-01.txt section 2.3.2
Date: Thu, 8 Mar 2007 11:36:45 -0500
Message-ID: <008a01c7619f$f6947fd0$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdhmdtFhfSnROQAR4yEioMP/J6f6QABfcww

Avi Lior
> Delete this section.
> 
> Alternatively, you can reinforce that Acct-Session-Id is of type TEXT.

I think that would be the much preferred resolution.




--
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, 08 Mar 2007 17:35:57 +0000
Message-ID: <45F0495F.2050501@nitros9.org>
Date: Thu, 08 Mar 2007 18:35:27 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: radext mailing list 
Subject: Re: Issues & Fixes: Ordered delivery of EAP messages
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Picking up on Avi's point, in the first paragraph, are these really all
> MUSTs?  Also does this apply only to new implementations? I'd suggest
> the following:

  Applications that perform an action twice because of underlying packet
retransmission aren't robust.  That's my $0.02, but I'm not set on it.

  The "new implementations" text isn't necessary.

> We therefore recommend that RADIUS servers SHOULD
> implement duplicate detection for Access-Request packets, as described
> in Section 3 of [RFC2865].  Implementations SHOULD also cache the
> responses to those Access-Request packets.  If a duplicate
> Access-Request packet is detected, the server MUST respond with a
> previously sent response packet (Access-Accept, Access-Challenge, or
> Access-Reject), if that packet is available.  If no response is
> available, the duplicate Access-Request MUST be silently discarded.  In
> either case, the server MUST NOT process the duplicate Access-Request
> again, as though it was an independent new request.

  That's fine by me.

  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, 08 Mar 2007 17:35:48 +0000
Message-ID: <45F04949.1040704@nitros9.org>
Date: Thu, 08 Mar 2007 18:35:05 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Avi Lior 
CC:  radiusext@ops.ietf.org
Subject: Re: Issue with draft-ietf-radext-fixes-01.txt section 2.3.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Avi Lior wrote:

> Section 2.3.2 is attempting to fix a problem with Acct-Session-Id which
> is not really a problem.

  It's more a clarification of the language in RFC 2865.  It says
Acct-Session-Id is "Text" in the ASCII art, but "String" in the body,
and defines "String" as having the same contents as the type "Text"
defined in RFC 2865.

  Acct-Multi-Session-Id is similar.  It defines the attribute as
"Acct-Session-Id" just before the ASCII art (which has type "String"),
and then also defines "String" as having the same contents as the type
"Text" defined in RFC 2865.

> Infact, the proposed change will break existing RADIUS server
> implemenations, Accounting Correlation and Mediation systems and other
> backoffice systems.

  That was not out intention.

> Requested change:
> 
> Delete this section.
> 
> Alternatively, you can reinforce that Acct-Session-Id is of type TEXT.

  How about the following text:

[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
figure summarizing the attribute format, but then goes to state that
"The String field SHOULD be a string of UTF-8 encoded 10646
characters."

[RFC2865] defines the "Text" type as "containing UTF-8 encoded 10646
characters", which is compatible with the description of
Acct-Session-Id.  Since other attributes are consistently described as
"Text" within both the figure summarizing the attribute format, and
the following attribute definition, it appears that this is a
typographical error, and that Acct-Session-Id is of type Text, and not
of type String.

The definition of the Acct-Multi-Session-Id attribute also has
typographical errors.  It says

   A summary of the Acct-Session-Id attribute format ...

This text should read

  A summary of the Acct-Multi-Session-Id attribute format ...

The Acct-Multi-Session-Id attribute is also defined as being of type
"String".  However, the language in the text strongly recommends that
implementors consider the attribute as being of type "Text".  It is
unclear why the type "String" was chosen for this attribute when the
type "Text" would be sufficient.
...

  I would like to recommend treating it as type "Text", which would be
compatible with most implementations I've seen.  i.e. I can't recall one
which treats it as opaque octets.

  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, 08 Mar 2007 17:10:09 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Issue with draft-ietf-radext-fixes-01.txt section 2.3.2
Date: Thu, 8 Mar 2007 12:09:06 -0500
Message-ID: 
From: "Avi Lior" 
To: "David B. Nelson" , 

Hi David,

I am okay with that approach.=20

-----Original Message-----
From: David B. Nelson [mailto:d.b.nelson@comcast.net]=20
Sent: Thursday, March 08, 2007 11:37 AM
To: Avi Lior; radiusext@ops.ietf.org
Subject: RE: Issue with draft-ietf-radext-fixes-01.txt section 2.3.2


Avi Lior
> Delete this section.
>=20
> Alternatively, you can reinforce that Acct-Session-Id is of type TEXT.

I think that would be the much preferred resolution.




--
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, 08 Mar 2007 15:54:06 +0000
Message-ID: 
From: "Bernard Aboba" 
To: aland@deployingradius.com
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: Re: Issues & Fixes: Ordered delivery of EAP messages
Date: Thu, 08 Mar 2007 07:53:55 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>We therefore state that new implementations of RADIUS servers MUST
>implement duplicate detection for Access-Request packets, as described
>in Section 3 of [RFC2865].  New implementations MUST also cache the
>responses to those Access-Request packets.  If a duplicate
>Access-Request packet is detected, the server MUST respond with a
>previously sent response packet (Access-Accept, Access-Challenge, or
>Access-Reject), if that packet is available.  If no response is
>available, the duplicate Access-Request MUST be silently discarded.  In
>either case, the server MUST NOT process the duplicate Access-Request
>again, as though it was an independent new request.
>
>   The time span for duplicate detection SHOULD be no less than 5
>seconds, and no more than 30 seconds.

Picking up on Avi's point, in the first paragraph, are these really all 
MUSTs?  Also does this apply only to new implementations? I'd suggest the 
following:

We therefore recommend that RADIUS servers SHOULD
implement duplicate detection for Access-Request packets, as described
in Section 3 of [RFC2865].  Implementations SHOULD also cache the
responses to those Access-Request packets.  If a duplicate
Access-Request packet is detected, the server MUST respond with a
previously sent response packet (Access-Accept, Access-Challenge, or
Access-Reject), if that packet is available.  If no response is
available, the duplicate Access-Request MUST be silently discarded.  In
either case, the server MUST NOT process the duplicate Access-Request
again, as though it was an independent new request.



--
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, 08 Mar 2007 15:49:26 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Issue with draft-ietf-radext-fixes-01.txt section 2.3.2
Date: Thu, 8 Mar 2007 10:48:35 -0500
Message-ID: 
From: "Avi Lior" 
To: 

Description of issue
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: March 8, 2007
Reference:=20
Document: draft-ietf-radext-fixes-01.txt
Comment type: T=20
Priority: S
Section: 2.3.2.  Acct-Session-Id and Acct-Multi-Session-Id
Rationale/Explanation of issue:

Section 2.3.2 is attempting to fix a problem with Acct-Session-Id which
is not really a problem.

Infact, the proposed change will break existing RADIUS server
implemenations, Accounting Correlation and Mediation systems and other
backoffice systems.

The text from issues and fixes is as follows:

2.3.2.  Acct-Session-Id and Acct-Multi-Session-Id

   [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
   description, but also states that "The String field SHOULD be a
   string of UTF-8 encoded 10646 characters."

Effectively there is no inconsistency since both definitions lead to the
same result.  Acct-Session-Id will be implmented as "UTF-8 encoded 10646
characters".  No developer will implment Acct-Session-Id as a String.=20

Requested change:

Delete this section.

Alternatively, you can reinforce that Acct-Session-Id is of type TEXT.

=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: Thu, 08 Mar 2007 13:25:41 +0000
Date: Thu, 08 Mar 2007 08:24:33 -0500
From: Yoshihiro Ohba 
Subject: Re: [eap] Ordered delivery of EAP messages
To: "Glen Zorn (gwz)" 
Cc: Yoshihiro Ohba , Avi Lior , radiusext@ops.ietf.org, eap@frascone.com
Message-id: <20070308132433.GA28821@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)

Glen,

On Wed, Mar 07, 2007 at 10:15:24PM -0800, Glen Zorn (gwz) wrote:
> 
> My basic argument is that EAP _does_ work over a transport that doesn't
> guarantee in-order delivery (the example being RADIUS) except in a deep,
> dark, cobweb-filled corner case.  The arguments have been that
> "well-behaved" RADIUS implementations exhibit what amounts to in-order
> delivery despite the fact that it is not required by the RFCs but badly
> behaved EAP implementations will fail in a contrived, pathological case.
> I am saying that a badly-behaved RADIUS implementation would fail in
> that same pathological case and the converse.
> 

Which case do you mean by "badly-behaved EAP implementations"?

Yoshihiro Ohba

--
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, 08 Mar 2007 06:15:53 +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: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 22:15:24 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250391A382@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: AcdhQYeyeRqB1oR8SkmCHv6plLBxaQABh2sQ
From: "Glen Zorn \(gwz\)" 
To: "Yoshihiro Ohba" , "Avi Lior" 
Cc: , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5710; t=1173334528; x=1174198528; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=US9FQDIQ6jeqtJ62d2OfPYIeA8rQw7W0Rlnrri4N95A=; b=E7/VpCX+qYb2Ofm6Qr4YxvAVqzAyOCPldUVcjOk6oIV7ftWQt1OeBu4zrZfWF+1I+8Bm5HGY OMHXK3EJZHedvho84Vhba5KznTGJf9YNu/57WY48wEWs0bsy2BGgfyR55FyKkG+2Fcmz84a0J7 vk1NuqQpKoyPvGStgFxUMK4/0=;
Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; );

Yoshihiro Ohba  allegedly scribbled on
Wednesday, March 07, 2007 9:20 PM:

> On Wed, Mar 07, 2007 at 11:11:35PM -0500, Avi Lior wrote:
>> I don't agree that the RECOMMENDED part should be a MUST.
>>=20
>> You have to prove that this property is required for Correct Secure
>> Operation.
>=20
> This is what I don't understand.  Correctness and security are two
> separate things.=20
>=20
> I can show you a typical example, TLS.  TLS requires reliable
> transport for its correct operation.  Without use of reliable
> transport, TLS session will be immediately shutdown when a packet is
> lost, but it is still secure.  This does not mean that TLS requires
> reliable transport for its secure operation.   =20
>=20
> Note that DTLS does not require reliable transport, because it
> modifies TLS to correcly work over unreliable transport.=20
>=20
> For the same reason, if we want to remove the orderly delivery
> requirement from EAP, we would need to modify EAP to correctly work
> with non-orderly delivery. =20

My basic argument is that EAP _does_ work over a transport that doesn't
guarantee in-order delivery (the example being RADIUS) except in a deep,
dark, cobweb-filled corner case.  The arguments have been that
"well-behaved" RADIUS implementations exhibit what amounts to in-order
delivery despite the fact that it is not required by the RFCs but badly
behaved EAP implementations will fail in a contrived, pathological case.
I am saying that a badly-behaved RADIUS implementation would fail in
that same pathological case and the converse.

>=20
> Yoshihiro Ohba
>=20
>>=20
>>=20
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>> Sent: Wednesday, March 07, 2007 7:15 PM
>> To: Avi Lior
>> Cc: Bernard Aboba; alper.yegin@yegin.org; radiusext@ops.ietf.org;
>> eap@frascone.com Subject: Re: [eap] Ordered delivery of EAP messages
>>=20
>> I agree that there is some ambiguity, but I'd rather think that the
>> RECOMMENDED part should be a MUST from operational perspective, not
>> the other way around.=20
>>=20
>> Yoshihiro Ohba
>>=20
>> On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
>>> I think this is an interesting discussion on RADIUS but we seem to
>>> have diverted from the original question posed.
>>>=20
>>> RFC 3748, section 3.1 says:
>>>=20
>>> [6] Ordering guarantees.  EAP does not require the Identifier to be
>>>        monotonically increasing, and so is reliant on lower layer
>>>        ordering guarantees for correct operation.
>>>=20
>>> Lower layer transports for EAP MUST preserve ordering between a
>>>        source and destination at a given priority level (the
>>>        ordering guarantee provided by [IEEE-802]).
>>>=20
>>> I don't think that the "MUST" above is true!
>>>=20
>>> A little further down it says:
>>>=20
>>> "It is RECOMMENDED that EAP only be run over lower layers that
>>> provide
>>=20
>>> ordering guarantees; "
>>>=20
>>> Isn't that a requirement contradiction of the previous statement,
>>> or am I missing something?=20
>>>=20
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>>> Sent: Tuesday, March 06, 2007 11:55 PM
>>> To: alper.yegin@yegin.org
>>> Cc: radiusext@ops.ietf.org; eap@frascone.com
>>> Subject: Re: [eap] Ordered delivery of EAP messages
>>>=20
>>>> RFC 2865 says:
>>>>=20
>>>>       The RADIUS server can detect a duplicate request if
>>>>       it has the same client source IP address and source UDP port
>>>>       and Identifier within a short span of time.
>>>>=20
>>>> This, to me, implies duplicate detection on the server side does
>>>> not rely on orderly delivery. Keeping the history for "a short span
>>>> of time" allows duplicate detection irrespective of the order the
>>>> requests
>>>=20
>>>> come in.
>>>=20
>>> That advice seems sensible; if implemented, I think it would address
>>> the FRTO scenarios we have been discussing, wouldn't it?  Given
>>> client
>>=20
>>> backoff, it seems highly unlikely that an Access-Request would be
>>> reordered outside of a "short span of time" (e.g. say, 1 minute).
>>>=20
>>>> As for the responses... Assuming the RADIUS client transmitted a
>>>> request twice (first one timed out), if it receives one of the
>>>> responses, would it still accept the second (duplicate) response if
>>>> it
>>> arrives as well?
>>>> Wouldn't
>>>> the RADIUS client just drop the second response because there is no
>>>> outstanding request to match anymore?
>>>=20
>>> Yes, I think that the RADIUS client will drop a duplicate response.
>>> The problem occurs more on the RADIUS server side, where the server
>>> could potentially send an Access-Reject if it wasn't doing duplicate
>>> detection as referred to above, and as a result the EAP method got
>>> mixed up.=20
>>>=20
>>>=20
>>> _________________________________________________________________
>>> To unsubscribe or modify your subscription options, please visit:
>>> http://lists.frascone.com/mailman/listinfo/eap
>>>=20
>>> Arhives: http://lists.frascone.com/pipermail/eap
>>>=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
>>>=20
>>=20
>>=20
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>=20
> Arhives: http://lists.frascone.com/pipermail/eap

--
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, 08 Mar 2007 05:21:06 +0000
Date: Thu, 8 Mar 2007 00:20:17 -0500
To: Avi Lior 
Cc: Yoshihiro Ohba , Bernard Aboba , alper.yegin@yegin.org, radiusext@ops.ietf.org, eap@frascone.com
Subject: Re: [eap] Ordered delivery of EAP messages
Message-ID: <20070308052017.GA26227@steelhead>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Yoshihiro Ohba 

On Wed, Mar 07, 2007 at 11:11:35PM -0500, Avi Lior wrote:
> I don't agree that the RECOMMENDED part should be a MUST. 
> 
> You have to prove that this property is required for Correct Secure
> Operation.  

This is what I don't understand.  Correctness and security are two
separate things.

I can show you a typical example, TLS.  TLS requires reliable
transport for its correct operation.  Without use of reliable
transport, TLS session will be immediately shutdown when a packet is
lost, but it is still secure.  This does not mean that TLS requires
reliable transport for its secure operation.

Note that DTLS does not require reliable transport, because it
modifies TLS to correcly work over unreliable transport.

For the same reason, if we want to remove the orderly delivery
requirement from EAP, we would need to modify EAP to correctly work
with non-orderly delivery.

Yoshihiro Ohba

>  
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> Sent: Wednesday, March 07, 2007 7:15 PM
> To: Avi Lior
> Cc: Bernard Aboba; alper.yegin@yegin.org; radiusext@ops.ietf.org;
> eap@frascone.com
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> I agree that there is some ambiguity, but I'd rather think that the
> RECOMMENDED part should be a MUST from operational perspective, not the
> other way around.
> 
> Yoshihiro Ohba
> 
> On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
> > I think this is an interesting discussion on RADIUS but we seem to 
> > have diverted from the original question posed.
> > 
> > RFC 3748, section 3.1 says:
> > 
> > [6] Ordering guarantees.  EAP does not require the Identifier to be 
> >        monotonically increasing, and so is reliant on lower layer 
> >        ordering guarantees for correct operation. 
> > 
> > Lower layer transports for EAP MUST preserve ordering between a 
> >        source and destination at a given priority level (the ordering 
> >        guarantee provided by [IEEE-802]). 
> > 
> > I don't think that the "MUST" above is true! 
> > 
> > A little further down it says:
> > 
> > "It is RECOMMENDED that EAP only be run over lower layers that provide
> 
> > ordering guarantees; "
> > 
> > Isn't that a requirement contradiction of the previous statement, or 
> > am I missing something?
> > 
> > 
> > 
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > Sent: Tuesday, March 06, 2007 11:55 PM
> > To: alper.yegin@yegin.org
> > Cc: radiusext@ops.ietf.org; eap@frascone.com
> > Subject: Re: [eap] Ordered delivery of EAP messages
> > 
> > >RFC 2865 says:
> > >
> > >       The RADIUS server can detect a duplicate request if
> > >       it has the same client source IP address and source UDP port
> and
> > >       Identifier within a short span of time.
> > >
> > >This, to me, implies duplicate detection on the server side does not 
> > >rely on orderly delivery. Keeping the history for "a short span of 
> > >time" allows duplicate detection irrespective of the order the 
> > >requests
> > 
> > >come in.
> > 
> > That advice seems sensible; if implemented, I think it would address 
> > the FRTO scenarios we have been discussing, wouldn't it?  Given client
> 
> > backoff, it seems highly unlikely that an Access-Request would be 
> > reordered outside of a "short span of time" (e.g. say, 1 minute).
> > 
> > >As for the responses... Assuming the RADIUS client transmitted a 
> > >request twice (first one timed out), if it receives one of the 
> > >responses, would it still accept the second (duplicate) response if 
> > >it
> > arrives as well?
> > >Wouldn't
> > >the RADIUS client just drop the second response because there is no 
> > >outstanding request to match anymore?
> > 
> > Yes, I think that the RADIUS client will drop a duplicate response.  
> > The problem occurs more on the RADIUS server side, where the server 
> > could potentially send an Access-Reject if it wasn't doing duplicate 
> > detection as referred to above, and as a result the EAP method got
> mixed up.
> > 
> > 
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> > 
> > Arhives: http://lists.frascone.com/pipermail/eap
> > 
> > --
> > 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, 08 Mar 2007 04:11:39 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 23:11:35 -0500
Message-ID: 
From: "Avi Lior" 
To: "Yoshihiro Ohba" 
Cc: "Bernard Aboba" , , , 

I don't agree that the RECOMMENDED part should be a MUST.=20

You have to prove that this property is required for Correct Secure
Operation. =20
=20

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20
Sent: Wednesday, March 07, 2007 7:15 PM
To: Avi Lior
Cc: Bernard Aboba; alper.yegin@yegin.org; radiusext@ops.ietf.org;
eap@frascone.com
Subject: Re: [eap] Ordered delivery of EAP messages

I agree that there is some ambiguity, but I'd rather think that the
RECOMMENDED part should be a MUST from operational perspective, not the
other way around.

Yoshihiro Ohba

On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
> I think this is an interesting discussion on RADIUS but we seem to=20
> have diverted from the original question posed.
>=20
> RFC 3748, section 3.1 says:
>=20
> [6] Ordering guarantees.  EAP does not require the Identifier to be=20
>        monotonically increasing, and so is reliant on lower layer=20
>        ordering guarantees for correct operation.=20
>=20
> Lower layer transports for EAP MUST preserve ordering between a=20
>        source and destination at a given priority level (the ordering=20
>        guarantee provided by [IEEE-802]).=20
>=20
> I don't think that the "MUST" above is true!=20
>=20
> A little further down it says:
>=20
> "It is RECOMMENDED that EAP only be run over lower layers that provide

> ordering guarantees; "
>=20
> Isn't that a requirement contradiction of the previous statement, or=20
> am I missing something?
>=20
>=20
>=20
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Tuesday, March 06, 2007 11:55 PM
> To: alper.yegin@yegin.org
> Cc: radiusext@ops.ietf.org; eap@frascone.com
> Subject: Re: [eap] Ordered delivery of EAP messages
>=20
> >RFC 2865 says:
> >
> >       The RADIUS server can detect a duplicate request if
> >       it has the same client source IP address and source UDP port
and
> >       Identifier within a short span of time.
> >
> >This, to me, implies duplicate detection on the server side does not=20
> >rely on orderly delivery. Keeping the history for "a short span of=20
> >time" allows duplicate detection irrespective of the order the=20
> >requests
>=20
> >come in.
>=20
> That advice seems sensible; if implemented, I think it would address=20
> the FRTO scenarios we have been discussing, wouldn't it?  Given client

> backoff, it seems highly unlikely that an Access-Request would be=20
> reordered outside of a "short span of time" (e.g. say, 1 minute).
>=20
> >As for the responses... Assuming the RADIUS client transmitted a=20
> >request twice (first one timed out), if it receives one of the=20
> >responses, would it still accept the second (duplicate) response if=20
> >it
> arrives as well?
> >Wouldn't
> >the RADIUS client just drop the second response because there is no=20
> >outstanding request to match anymore?
>=20
> Yes, I think that the RADIUS client will drop a duplicate response. =20
> The problem occurs more on the RADIUS server side, where the server=20
> could potentially send an Access-Reject if it wasn't doing duplicate=20
> detection as referred to above, and as a result the EAP method got
mixed up.
>=20
>=20
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>=20
> Arhives: http://lists.frascone.com/pipermail/eap
>=20
> --
> 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

--
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, 08 Mar 2007 04:10:48 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 23:10:13 -0500
Message-ID: 
From: "Avi Lior" 
To: "Yoshihiro Ohba" 
Cc: "Bernard Aboba" , , , , , 

Yoshi

Please see inline....=20

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20
Sent: Wednesday, March 07, 2007 2:43 PM
To: Avi Lior
Cc: Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org;
Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

On Wed, Mar 07, 2007 at 11:40:39AM -0500, Avi Lior wrote:
> Bernard,
>=20
> You said:=20
>=20
> "So overall, I don't think that the majority of EAP methods deployed=20
> today are capable of handling arbitrary reordering."
>=20
> Okay, but what is the result when this occurs, would this result in an

> Unauthenticateable user to be Authenticated?
>=20
> If NOT, then EAP Methods do not require in order delivery by the=20
> underlying transport(s) to give results that are secure.
>=20
> In order delivery is desirable for optimal performance -- an=20
> Authenticateble user getting authenticated without having to retry the

> method.

Orderly delivery is required for authenticable user to be authenticated.


[Avi] Correct.

Without orderly delivery, authentication for authenticable user can fail
even if (i) EAP and lower layer are doing their jobs correctly as
specified in their specifications, (ii) valid credentials are being used
and (iii) there is no attacking.  From operational perspective, this is
something that should not happen, IMO.

[Avi] I agree.  Yes and RFC 3748 addresses that already and makes a
recommendation that the transport layer should provide inorder delivery.
But it is an entirely different matter to require in order delivery.
The point again and again is that in order delivery by the transport
layer is NOT required for Correct Secure operation of EAP.  EAP Method
need to take care of that aspect themselves they should not delegate
that responsibility to the transport layer.

Yoshihiro Ohba


>=20
>=20
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Tuesday, March 06, 2007 11:43 PM
> To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org;=20
> Pasi.Eronen@nokia.com; eap@frascone.com
> Cc: radiusext@ops.ietf.org
> Subject: RE: [eap] Ordered delivery of EAP messages
>=20
> Avi Lior said:
>=20
> "If an EAP method designer designed their method assuming the in order

> delivery of packets then this would be a bad thing I think.
>=20
> A hacker could then exploit this assumption by re-order the packets.
> Surely EAP methods are not susceptible to this type of attack. Right?"
>=20
> Certainly, it is a good thing for an EAP method to protect itself=20
> against replay.  Using the mechanism provided in RFC 3579, an EAP=20
> method could discard replayed packets and ask the NAS to send another
one.
>=20
> On the other hand, there are EAP methods that are not protected=20
> against replay (e.g. Identity, Notification, etc.).  There are also=20
> situations in which EAP packets can be fragmented, and if reassembled=20
> in the wrong order, this could cause failure of the MIC which can be a

> terminal error (e.g. in TLS-based methods).
>=20
> So overall, I don't think that the majority of EAP methods deployed=20
> today are capable of handling arbitrary reordering.
>=20
>=20
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>=20
> Arhives: http://lists.frascone.com/pipermail/eap
>=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, 08 Mar 2007 03:27:17 +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: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 19:26:55 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250391A338@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: Acdgvtm4R6Uzr440TuSPiLZpYyqzbAAck2uw
From: "Glen Zorn \(gwz\)" 
To: "Alan DeKok" , "Alper Yegin" 
Cc: "Bernard Aboba" , , , , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1705; t=1173324424; x=1174188424; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=YKK5ekf/B5sgOckhT5UA2f7zswFKFVhqJfz+sIJnr1g=; b=KBEgD8sK6ymDX+m2GeHlqYtSzj+KaLDrnhCa4oyDZMjg5zzFv/6MZZ0QG1PrksdvRyvIPD61 4THYQ06z09HppY2QnXrB+CDkuZuJto1NAVpy3+o5PYsDnLOMuXR58lm0Wsju8lK1mb10DbHMsg qZZ+Myb9BxhlNh6gqGo0/bvEU=;
Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; );

Alan DeKok  allegedly scribbled on
Wednesday, March 07, 2007 5:45 AM:

> Alper Yegin wrote:
>> RFC 2865 says:
>>=20
>>       The RADIUS server can detect a duplicate request if
>>       it has the same client source IP address and source UDP port
>>       and Identifier within a short span of time.
>>=20
>> This, to me, implies duplicate detection on the server side does not
>> rely on orderly delivery. Keeping the history for "a short span of
>> time" allows duplicate detection irrespective of the order the
>> requests come in.=20
>=20
>   Yes.  All well-behaved RADIUS servers do this.  RADIUS servers that
> *don't* do this can led to believe that a user has logged in twice,
> when the second attempt was just a duplicate.=20
>=20
>> As for the responses... Assuming the RADIUS client transmitted a
>> request twice (first one timed out), if it receives one of the
>> responses, would it still accept the second (duplicate) response if
>> it arrives as well?=20
>=20
>   What do you mean "accept"?  The client has already had a response
> to the first transmission.  The only safe thing to do here is to
> silently discard the response to the re-transmitted request.=20
> Ideally, this case SHOULD be separated from the case of unsolicited
> or spoofed "replies" by the client also caching requests for a period
> of time.    =20
>=20
>> Wouldn't
>> the RADIUS client just drop the second response because there is no
>> outstanding request to match anymore?
>=20
>   That is the safest thing to do, yes.

All of these things make total sense but AFAICT none are actually
mandated by RFC 2865.=20

>=20
>   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, 08 Mar 2007 03:22: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: Issues & Fixes: Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 19:22:20 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA7DF@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Issues & Fixes: Ordered delivery of EAP messages
Thread-Index: AcdgjzE8myxrxLLZSuyisPeypSLe6AAoEnAg
From: "Glen Zorn \(gwz\)" 
To: "Bernard Aboba" 
Cc: , , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1235; t=1173324146; x=1174188146; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Issues=20&=20Fixes=3A=20Ordered=20delivery=20of=20EAP =20messages |Sender:=20; bh=oeFuuqlecUNjP4eOExm2GWXiE7EBpAf452Aa9kOF8CY=; b=kDovJ9YznDtAnvGa7Gx11/tPuhLdON9bQWfPpZvSmYdm6zs0iXpG84MHRlBMJGPGyFmTrkmi 2Y3hSboPLPr+cml0u3b/TjPS9ykbpk3aaMgvWUakt17xvB9hGEf7Ywcv;
Authentication-Results: sj-dkim-6; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; );

Bernard Aboba  allegedly scribbled on
Wednesday, March 07, 2007 12:04 AM:

>> Ordered delivery & duplicate rejection aren't the same thing.
>=20
> In general, that's true.  But if you have an ACK/NAK protocol that
> only allows a single packet in flight other than retransmissions,
> doesn't effective duplicate rejection imply ordered delivery?=20

Perhaps.  Unfortunately, RADIUS does not require duplicate detection.
This is what RFC 2865 says about duplicate detection: "The RADIUS server
can detect a duplicate request if it has the same client source IP
address and source UDP port and Identifier within a short span of time."
That's it.  I don't see the word "MUST" (or even "SHOULD") in that
sentence.  In fact, RFC 3748 is actually a bit stronger on the topic
(Section 4.1): "The peer is responsible for detecting and handling
duplicate Request messages before processing them in any way, including
passing them on to an outside party.  The authenticator is also
responsible for discarding Response messages with a non-matching
Identifier value before acting on them in any way, including passing
them on to the backend authentication server for verification."=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, 08 Mar 2007 03:09:22 +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: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 19:08:31 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA7D6@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: Acdg/E4XgdfwwOKcSlarrC1nGr9jkQAMnw7w
From: "Glen Zorn \(gwz\)" 
To: "Yoshihiro Ohba" , "Avi Lior" 
Cc: "Bernard Aboba" , , , , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4140; t=1173323323; x=1174187323; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=mRCf26dIyHvmHCIX/pIERjGRj8tUSpkkf7gkgj5Bqqo=; b=OiZp02Y6ryAymuzHtFUMlJpHKlyFjltBNaiqc1m3DEe44IIs2XItdZm/ISzD2VRjxaX9OfzQ P5gZ5Ax+4upg8s8YtHY8gdSYsE17wT5K2Owlirt93ijuuSF7JtU6RgMj;
Authentication-Results: sj-dkim-8; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; );

Yoshihiro Ohba  allegedly scribbled on
Wednesday, March 07, 2007 1:05 PM:
...
>> But you didn't answer the first part -- which is the key part.  If
>> you had unordered delivery of packets, could an unAuthenticatble
>> user be authenticated?
>=20
> I have been thinking about this, and so far I have not found an
> example case of unauthenticatble user be authenticated when
> misordering happens.  The answer is "I don't know." =20
>=20
>>=20
>> If the answer to this question is NO, then EAP does not require in
>> order delivery of packets and RFC 3748 has an error.
>=20
> I am not sure what makes you conclude like this.  I don't want my
> authentication attempt to fail just because IP packets are arriving
> out of order. =20

Just to be clear, we're talking about EAP packets here, not IP packets.

>=20
> Yoshihiro Ohba
>=20
>=20
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>> Sent: Wednesday, March 07, 2007 2:43 PM
>> To: Avi Lior
>> Cc: Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org;
>> Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
>> Subject: Re: [eap] Ordered delivery of EAP messages
>>=20
>> On Wed, Mar 07, 2007 at 11:40:39AM -0500, Avi Lior wrote:
>>> Bernard,
>>>=20
>>> You said:
>>>=20
>>> "So overall, I don't think that the majority of EAP methods deployed
>>> today are capable of handling arbitrary reordering."
>>>=20
>>> Okay, but what is the result when this occurs, would this result in
>>> an
>>=20
>>> Unauthenticateable user to be Authenticated?
>>>=20
>>> If NOT, then EAP Methods do not require in order delivery by the
>>> underlying transport(s) to give results that are secure.
>>>=20
>>> In order delivery is desirable for optimal performance -- an
>>> Authenticateble user getting authenticated without having to retry
>>> the
>>=20
>>> method.
>>=20
>> Orderly delivery is required for authenticable user to be
>> authenticated. Without orderly delivery, authentication for
>> authenticable user can fail even if (i) EAP and lower layer are
>> doing their jobs correctly as specified in their specifications,
>> (ii) valid credentials are being used and (iii) there is no
>> attacking.  From operational perspective, this is something that
>> should not happen, IMO.=20
>>=20
>> Yoshihiro Ohba
>>=20
>>=20
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>>> Sent: Tuesday, March 06, 2007 11:43 PM
>>> To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org;
>>> Pasi.Eronen@nokia.com; eap@frascone.com
>>> Cc: radiusext@ops.ietf.org
>>> Subject: RE: [eap] Ordered delivery of EAP messages
>>>=20
>>> Avi Lior said:
>>>=20
>>> "If an EAP method designer designed their method assuming the in
>>> order
>>=20
>>> delivery of packets then this would be a bad thing I think.
>>>=20
>>> A hacker could then exploit this assumption by re-order the packets.
>>> Surely EAP methods are not susceptible to this type of attack.
>>> Right?"=20
>>>=20
>>> Certainly, it is a good thing for an EAP method to protect itself
>>> against replay.  Using the mechanism provided in RFC 3579, an EAP
>>> method could discard replayed packets and ask the NAS to send
>>> another
>> one.
>>>=20
>>> On the other hand, there are EAP methods that are not protected
>>> against replay (e.g. Identity, Notification, etc.).  There are also
>>> situations in which EAP packets can be fragmented, and if
>>> reassembled in the wrong order, this could cause failure of the MIC
>>> which can be a
>>=20
>>> terminal error (e.g. in TLS-based methods).
>>>=20
>>> So overall, I don't think that the majority of EAP methods deployed
>>> today are capable of handling arbitrary reordering.
>>>=20
>>>=20
>>> _________________________________________________________________
>>> To unsubscribe or modify your subscription options, please visit:
>>> http://lists.frascone.com/mailman/listinfo/eap
>>>=20
>>> Arhives: http://lists.frascone.com/pipermail/eap

--
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, 08 Mar 2007 02:02:34 +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: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 18:01:26 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA7A3@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: AcdgMQqMZiN0SjwXQHuDtOzsvDkSoQAE0rIQAA7veWAACzDP0AAd/fsg
From: "Glen Zorn \(gwz\)" 
To: "Alper Yegin" , "Bernard Aboba" , 
Cc: , , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2563; t=1173319301; x=1174183301; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=TfTtfxrUsGOkL/fdgBp+lSpIytHqrBmLuKqfMIh3F5c=; b=x4qc8lDNF3eiVFyKEcWbiL3w6uSBG05Py5GlDv+EW8xeA4FVoPrm4N7tyfnXZmCDB7FZkzDW +N94vIQKWowjyWddawLCm3EP5LNEA81uF+h4wZUiZto3g+gtG27FgaeG;
Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; );

Alper Yegin  allegedly scribbled on
Wednesday, March 07, 2007 3:39 AM:

>> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
>> well?=20
>=20
> With the appropriate normative text in the RFC covering both end
> points this could be used. But we don't have such text in RFC 3748.=20

OK, so what is the real purpose of the Identifier in EAP?  I would have
thought that this would be one:

   [5] Possible duplication.  Where the lower layer is reliable, it will
       provide the EAP layer with a non-duplicated stream of packets.
       However,  while it is desirable that lower layers provide for
       non-duplication, this is not a requirement.  The Identifier field
       provides both the peer and authenticator with the ability to
       detect duplicates.

But I'm hearing that this is N/A because somebody didn't bother to
implement it...

>=20
> Alper
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> -----Original Message-----
>> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
>> Sent: Wednesday, March 07, 2007 8:17 AM
>> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
>> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
>> Subject: RE: [eap] Ordered delivery of EAP messages
>>=20
>> Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25
>> PM:=20
>>=20
>>>> Both EAP and RADIUS do not detect duplicates arriving out of order;
>>>> they depend on the underlying lower layer to provide in-order
>>>> delivery so as to enable duplicate detection.
>>>=20
>>> RFC 2865 says:
>>>=20
>>>       The RADIUS server can detect a duplicate request if
>>>       it has the same client source IP address and source UDP port
>>>       and Identifier within a short span of time.
>>>=20
>>> This, to me, implies duplicate detection on the server side does not
>>> rely on orderly delivery. Keeping the history for "a short span of
>>> time" allows duplicate detection irrespective of the order the
>>> requests come in.
>>=20
>> Agree.
>>=20
>>>=20
>>> As for the responses... Assuming the RADIUS client transmitted a
>>> request twice (first one timed out), if it receives one of the
>>> responses, would it still accept the second (duplicate) response if
>>> it arrives as well? Wouldn't the RADIUS client just drop the second
>>> response because there is no outstanding request to match anymore?
>>=20
>> Seems reasonable.  So why wouldn't this reasoning apply to EAP as
>> well?=20
>>=20
>>>=20
>>>=20
>>> Alper

--
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, 08 Mar 2007 00:15:42 +0000
Date: Wed, 07 Mar 2007 19:14:37 -0500
From: Yoshihiro Ohba 
Subject: Re: [eap] Ordered delivery of EAP messages
To: Avi Lior 
Cc: Bernard Aboba , alper.yegin@yegin.org, radiusext@ops.ietf.org, eap@frascone.com
Message-id: <20070308001437.GQ22467@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)

I agree that there is some ambiguity, but I'd rather think that the
RECOMMENDED part should be a MUST from operational perspective, not
the other way around.

Yoshihiro Ohba

On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
> I think this is an interesting discussion on RADIUS but we seem to have
> diverted from the original question posed.
> 
> RFC 3748, section 3.1 says:
> 
> [6] Ordering guarantees.  EAP does not require the Identifier to be 
>        monotonically increasing, and so is reliant on lower layer 
>        ordering guarantees for correct operation. 
> 
> Lower layer transports for EAP MUST preserve ordering between a 
>        source and destination at a given priority level (the ordering 
>        guarantee provided by [IEEE-802]). 
> 
> I don't think that the "MUST" above is true! 
> 
> A little further down it says:
> 
> "It is RECOMMENDED that EAP only be run over lower layers that provide 
> ordering guarantees; "
> 
> Isn't that a requirement contradiction of the previous statement, or am
> I missing something?
> 
> 
> 
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Tuesday, March 06, 2007 11:55 PM
> To: alper.yegin@yegin.org
> Cc: radiusext@ops.ietf.org; eap@frascone.com
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> >RFC 2865 says:
> >
> >       The RADIUS server can detect a duplicate request if
> >       it has the same client source IP address and source UDP port and
> >       Identifier within a short span of time.
> >
> >This, to me, implies duplicate detection on the server side does not 
> >rely on orderly delivery. Keeping the history for "a short span of 
> >time" allows duplicate detection irrespective of the order the requests
> 
> >come in.
> 
> That advice seems sensible; if implemented, I think it would address the
> FRTO scenarios we have been discussing, wouldn't it?  Given client
> backoff, it seems highly unlikely that an Access-Request would be
> reordered outside of a "short span of time" (e.g. say, 1 minute).
> 
> >As for the responses... Assuming the RADIUS client transmitted a 
> >request twice (first one timed out), if it receives one of the 
> >responses, would it still accept the second (duplicate) response if it
> arrives as well?
> >Wouldn't
> >the RADIUS client just drop the second response because there is no 
> >outstanding request to match anymore?
> 
> Yes, I think that the RADIUS client will drop a duplicate response.  The
> problem occurs more on the RADIUS server side, where the server could
> potentially send an Access-Reject if it wasn't doing duplicate detection
> as referred to above, and as a result the EAP method got mixed up.
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
> --
> 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: Wed, 07 Mar 2007 21:35:43 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 16:35:19 -0500
Message-ID: 
From: "Avi Lior" 
To: "Yoshihiro Ohba" 
Cc: "Bernard Aboba" , , , , , 

Okay Yoshi fair enough.  But that is the most important question to
answer.

Because if the answer is YES.  Then it means that despite the best
effort of EAP method designers, a man in the middle could simply
re-order packets and get authenticated.  If true, this has got to be the
weak point of EAP.  I don't think its true or I hope that its not true.
The IETF will have egg on its face.

So the other part of my question on another thread is the issue with the
contradiction in 3748

RFC 3748, section 3.1 says: [6] Ordering guarantees. =20

Lower layer transports for EAP MUST preserve ordering between a=20
       source and destination at a given priority level (the ordering=20
       guarantee provided by [IEEE-802]).=20

A little further down it says:

"It is RECOMMENDED that EAP only be run over lower layers that provide
ordering guarantees; "

Isn't that a requirement contradiction of the previous statement, or am
I missing something? Do you have any opinions on this?



=20

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20
Sent: Wednesday, March 07, 2007 4:05 PM
To: Avi Lior
Cc: Yoshihiro Ohba; Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org;
Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

Hi Avi,

On Wed, Mar 07, 2007 at 03:41:31PM -0500, Avi Lior wrote:
> Hi Yoshi
>=20
> Very good so an authenticatble user will not be authenticated.
> Understood.
>=20
> But you didn't answer the first part -- which is the key part.  If you

> had unordered delivery of packets, could an unAuthenticatble user be=20
> authenticated?

I have been thinking about this, and so far I have not found an example
case of unauthenticatble user be authenticated when misordering happens.
The answer is "I don't know."

>=20
> If the answer to this question is NO, then EAP does not require in=20
> order delivery of packets and RFC 3748 has an error.

I am not sure what makes you conclude like this.  I don't want my
authentication attempt to fail just because IP packets are arriving out
of order.

Yoshihiro Ohba


>=20
>=20
>=20
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Wednesday, March 07, 2007 2:43 PM
> To: Avi Lior
> Cc: Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org;=20
> Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> Subject: Re: [eap] Ordered delivery of EAP messages
>=20
> On Wed, Mar 07, 2007 at 11:40:39AM -0500, Avi Lior wrote:
> > Bernard,
> >=20
> > You said:=20
> >=20
> > "So overall, I don't think that the majority of EAP methods deployed

> > today are capable of handling arbitrary reordering."
> >=20
> > Okay, but what is the result when this occurs, would this result in=20
> > an
>=20
> > Unauthenticateable user to be Authenticated?
> >=20
> > If NOT, then EAP Methods do not require in order delivery by the=20
> > underlying transport(s) to give results that are secure.
> >=20
> > In order delivery is desirable for optimal performance -- an=20
> > Authenticateble user getting authenticated without having to retry=20
> > the
>=20
> > method.
>=20
> Orderly delivery is required for authenticable user to be
authenticated.
> Without orderly delivery, authentication for authenticable user can=20
> fail even if (i) EAP and lower layer are doing their jobs correctly as

> specified in their specifications, (ii) valid credentials are being=20
> used and (iii) there is no attacking.  From operational perspective,=20
> this is something that should not happen, IMO.
>=20
> Yoshihiro Ohba
>=20
>=20
> >=20
> >=20
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > Sent: Tuesday, March 06, 2007 11:43 PM
> > To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org;=20
> > Pasi.Eronen@nokia.com; eap@frascone.com
> > Cc: radiusext@ops.ietf.org
> > Subject: RE: [eap] Ordered delivery of EAP messages
> >=20
> > Avi Lior said:
> >=20
> > "If an EAP method designer designed their method assuming the in=20
> > order
>=20
> > delivery of packets then this would be a bad thing I think.
> >=20
> > A hacker could then exploit this assumption by re-order the packets.
> > Surely EAP methods are not susceptible to this type of attack.
Right?"
> >=20
> > Certainly, it is a good thing for an EAP method to protect itself=20
> > against replay.  Using the mechanism provided in RFC 3579, an EAP=20
> > method could discard replayed packets and ask the NAS to send=20
> > another
> one.
> >=20
> > On the other hand, there are EAP methods that are not protected=20
> > against replay (e.g. Identity, Notification, etc.).  There are also=20
> > situations in which EAP packets can be fragmented, and if=20
> > reassembled in the wrong order, this could cause failure of the MIC=20
> > which can be a
>=20
> > terminal error (e.g. in TLS-based methods).
> >=20
> > So overall, I don't think that the majority of EAP methods deployed=20
> > today are capable of handling arbitrary reordering.
> >=20
> >=20
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> >=20
> > Arhives: http://lists.frascone.com/pipermail/eap
> >=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: 


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 07 Mar 2007 21:05:56 +0000
Date: Wed, 07 Mar 2007 16:05:06 -0500
From: Yoshihiro Ohba 
Subject: Re: [eap] Ordered delivery of EAP messages
To: Avi Lior 
Cc: Yoshihiro Ohba , Bernard Aboba , gwz@cisco.com, alper.yegin@yegin.org, Pasi.Eronen@nokia.com, eap@frascone.com, radiusext@ops.ietf.org
Message-id: <20070307210506.GK22467@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)

Hi Avi,

On Wed, Mar 07, 2007 at 03:41:31PM -0500, Avi Lior wrote:
> Hi Yoshi
> 
> Very good so an authenticatble user will not be authenticated.
> Understood.
> 
> But you didn't answer the first part -- which is the key part.  If you
> had unordered delivery of packets, could an unAuthenticatble user be
> authenticated? 

I have been thinking about this, and so far I have not found an
example case of unauthenticatble user be authenticated when
misordering happens.  The answer is "I don't know."

> 
> If the answer to this question is NO, then EAP does not require in order
> delivery of packets and RFC 3748 has an error.

I am not sure what makes you conclude like this.  I don't want my
authentication attempt to fail just because IP packets are arriving
out of order.

Yoshihiro Ohba


> 
> 
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
> Sent: Wednesday, March 07, 2007 2:43 PM
> To: Avi Lior
> Cc: Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org;
> Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> On Wed, Mar 07, 2007 at 11:40:39AM -0500, Avi Lior wrote:
> > Bernard,
> > 
> > You said: 
> > 
> > "So overall, I don't think that the majority of EAP methods deployed 
> > today are capable of handling arbitrary reordering."
> > 
> > Okay, but what is the result when this occurs, would this result in an
> 
> > Unauthenticateable user to be Authenticated?
> > 
> > If NOT, then EAP Methods do not require in order delivery by the 
> > underlying transport(s) to give results that are secure.
> > 
> > In order delivery is desirable for optimal performance -- an 
> > Authenticateble user getting authenticated without having to retry the
> 
> > method.
> 
> Orderly delivery is required for authenticable user to be authenticated.
> Without orderly delivery, authentication for authenticable user can fail
> even if (i) EAP and lower layer are doing their jobs correctly as
> specified in their specifications, (ii) valid credentials are being used
> and (iii) there is no attacking.  From operational perspective, this is
> something that should not happen, IMO.
> 
> Yoshihiro Ohba
> 
> 
> > 
> > 
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > Sent: Tuesday, March 06, 2007 11:43 PM
> > To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org; 
> > Pasi.Eronen@nokia.com; eap@frascone.com
> > Cc: radiusext@ops.ietf.org
> > Subject: RE: [eap] Ordered delivery of EAP messages
> > 
> > Avi Lior said:
> > 
> > "If an EAP method designer designed their method assuming the in order
> 
> > delivery of packets then this would be a bad thing I think.
> > 
> > A hacker could then exploit this assumption by re-order the packets.
> > Surely EAP methods are not susceptible to this type of attack. Right?"
> > 
> > Certainly, it is a good thing for an EAP method to protect itself 
> > against replay.  Using the mechanism provided in RFC 3579, an EAP 
> > method could discard replayed packets and ask the NAS to send another
> one.
> > 
> > On the other hand, there are EAP methods that are not protected 
> > against replay (e.g. Identity, Notification, etc.).  There are also 
> > situations in which EAP packets can be fragmented, and if reassembled 
> > in the wrong order, this could cause failure of the MIC which can be a
> 
> > terminal error (e.g. in TLS-based methods).
> > 
> > So overall, I don't think that the majority of EAP methods deployed 
> > today are capable of handling arbitrary reordering.
> > 
> > 
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> > 
> > Arhives: http://lists.frascone.com/pipermail/eap
> > 
> 
> 

--
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, 07 Mar 2007 20:42:08 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 15:41:31 -0500
Message-ID: 
From: "Avi Lior" 
To: "Yoshihiro Ohba" 
Cc: "Bernard Aboba" , , , , , 

Hi Yoshi

Very good so an authenticatble user will not be authenticated.
Understood.

But you didn't answer the first part -- which is the key part.  If you
had unordered delivery of packets, could an unAuthenticatble user be
authenticated?=20

If the answer to this question is NO, then EAP does not require in order
delivery of packets and RFC 3748 has an error.



-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20
Sent: Wednesday, March 07, 2007 2:43 PM
To: Avi Lior
Cc: Bernard Aboba; gwz@cisco.com; alper.yegin@yegin.org;
Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

On Wed, Mar 07, 2007 at 11:40:39AM -0500, Avi Lior wrote:
> Bernard,
>=20
> You said:=20
>=20
> "So overall, I don't think that the majority of EAP methods deployed=20
> today are capable of handling arbitrary reordering."
>=20
> Okay, but what is the result when this occurs, would this result in an

> Unauthenticateable user to be Authenticated?
>=20
> If NOT, then EAP Methods do not require in order delivery by the=20
> underlying transport(s) to give results that are secure.
>=20
> In order delivery is desirable for optimal performance -- an=20
> Authenticateble user getting authenticated without having to retry the

> method.

Orderly delivery is required for authenticable user to be authenticated.
Without orderly delivery, authentication for authenticable user can fail
even if (i) EAP and lower layer are doing their jobs correctly as
specified in their specifications, (ii) valid credentials are being used
and (iii) there is no attacking.  From operational perspective, this is
something that should not happen, IMO.

Yoshihiro Ohba


>=20
>=20
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Tuesday, March 06, 2007 11:43 PM
> To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org;=20
> Pasi.Eronen@nokia.com; eap@frascone.com
> Cc: radiusext@ops.ietf.org
> Subject: RE: [eap] Ordered delivery of EAP messages
>=20
> Avi Lior said:
>=20
> "If an EAP method designer designed their method assuming the in order

> delivery of packets then this would be a bad thing I think.
>=20
> A hacker could then exploit this assumption by re-order the packets.
> Surely EAP methods are not susceptible to this type of attack. Right?"
>=20
> Certainly, it is a good thing for an EAP method to protect itself=20
> against replay.  Using the mechanism provided in RFC 3579, an EAP=20
> method could discard replayed packets and ask the NAS to send another
one.
>=20
> On the other hand, there are EAP methods that are not protected=20
> against replay (e.g. Identity, Notification, etc.).  There are also=20
> situations in which EAP packets can be fragmented, and if reassembled=20
> in the wrong order, this could cause failure of the MIC which can be a

> terminal error (e.g. in TLS-based methods).
>=20
> So overall, I don't think that the majority of EAP methods deployed=20
> today are capable of handling arbitrary reordering.
>=20
>=20
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>=20
> Arhives: http://lists.frascone.com/pipermail/eap
>=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, 07 Mar 2007 19:43:40 +0000
Date: Wed, 07 Mar 2007 14:42:30 -0500
From: Yoshihiro Ohba 
Subject: Re: [eap] Ordered delivery of EAP messages
To: Avi Lior 
Cc: Bernard Aboba , gwz@cisco.com, alper.yegin@yegin.org, Pasi.Eronen@nokia.com, eap@frascone.com, radiusext@ops.ietf.org
Message-id: <20070307194230.GH22467@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)

On Wed, Mar 07, 2007 at 11:40:39AM -0500, Avi Lior wrote:
> Bernard,
> 
> You said: 
> 
> "So overall, I don't think that the majority of EAP methods deployed
> today are capable of handling arbitrary reordering."
> 
> Okay, but what is the result when this occurs, would this result in an
> Unauthenticateable user to be Authenticated?
> 
> If NOT, then EAP Methods do not require in order delivery by the
> underlying transport(s) to give results that are secure.
> 
> In order delivery is desirable for optimal performance -- an
> Authenticateble user getting authenticated without having to retry the
> method.

Orderly delivery is required for authenticable user to be
authenticated.  Without orderly delivery, authentication for
authenticable user can fail even if (i) EAP and lower layer are doing
their jobs correctly as specified in their specifications, (ii) valid
credentials are being used and (iii) there is no attacking.  From
operational perspective, this is something that should not happen, IMO.

Yoshihiro Ohba


> 
> 
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Tuesday, March 06, 2007 11:43 PM
> To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org;
> Pasi.Eronen@nokia.com; eap@frascone.com
> Cc: radiusext@ops.ietf.org
> Subject: RE: [eap] Ordered delivery of EAP messages
> 
> Avi Lior said:
> 
> "If an EAP method designer designed their method assuming the in order
> delivery of packets then this would be a bad thing I think.
> 
> A hacker could then exploit this assumption by re-order the packets.
> Surely EAP methods are not susceptible to this type of attack. Right?"
> 
> Certainly, it is a good thing for an EAP method to protect itself
> against replay.  Using the mechanism provided in RFC 3579, an EAP method
> could discard replayed packets and ask the NAS to send another one.
> 
> On the other hand, there are EAP methods that are not protected against
> replay (e.g. Identity, Notification, etc.).  There are also situations
> in which EAP packets can be fragmented, and if reassembled in the wrong
> order, this could cause failure of the MIC which can be a terminal error
> (e.g. in TLS-based methods).
> 
> So overall, I don't think that the majority of EAP methods deployed
> today are capable of handling arbitrary reordering.
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 

--
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, 07 Mar 2007 16:53:51 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 11:53:40 -0500
Message-ID: 
From: "Avi Lior" 
To: "Bernard Aboba" , 
Cc: , 

I think this is an interesting discussion on RADIUS but we seem to have
diverted from the original question posed.

RFC 3748, section 3.1 says:

[6] Ordering guarantees.  EAP does not require the Identifier to be=20
       monotonically increasing, and so is reliant on lower layer=20
       ordering guarantees for correct operation.=20

Lower layer transports for EAP MUST preserve ordering between a=20
       source and destination at a given priority level (the ordering=20
       guarantee provided by [IEEE-802]).=20

I don't think that the "MUST" above is true!=20

A little further down it says:

"It is RECOMMENDED that EAP only be run over lower layers that provide=20
ordering guarantees; "

Isn't that a requirement contradiction of the previous statement, or am
I missing something?



-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20
Sent: Tuesday, March 06, 2007 11:55 PM
To: alper.yegin@yegin.org
Cc: radiusext@ops.ietf.org; eap@frascone.com
Subject: Re: [eap] Ordered delivery of EAP messages

>RFC 2865 says:
>
>       The RADIUS server can detect a duplicate request if
>       it has the same client source IP address and source UDP port and
>       Identifier within a short span of time.
>
>This, to me, implies duplicate detection on the server side does not=20
>rely on orderly delivery. Keeping the history for "a short span of=20
>time" allows duplicate detection irrespective of the order the requests

>come in.

That advice seems sensible; if implemented, I think it would address the
FRTO scenarios we have been discussing, wouldn't it?  Given client
backoff, it seems highly unlikely that an Access-Request would be
reordered outside of a "short span of time" (e.g. say, 1 minute).

>As for the responses... Assuming the RADIUS client transmitted a=20
>request twice (first one timed out), if it receives one of the=20
>responses, would it still accept the second (duplicate) response if it
arrives as well?
>Wouldn't
>the RADIUS client just drop the second response because there is no=20
>outstanding request to match anymore?

Yes, I think that the RADIUS client will drop a duplicate response.  The
problem occurs more on the RADIUS server side, where the server could
potentially send an Access-Reject if it wasn't doing duplicate detection
as referred to above, and as a result the EAP method got mixed up.


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

--
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, 07 Mar 2007 16:41:20 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 11:40:39 -0500
Message-ID: 
From: "Avi Lior" 
To: "Bernard Aboba" , , , , 
Cc: 

Bernard,

You said:=20

"So overall, I don't think that the majority of EAP methods deployed
today are capable of handling arbitrary reordering."

Okay, but what is the result when this occurs, would this result in an
Unauthenticateable user to be Authenticated?

If NOT, then EAP Methods do not require in order delivery by the
underlying transport(s) to give results that are secure.

In order delivery is desirable for optimal performance -- an
Authenticateble user getting authenticated without having to retry the
method.


-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20
Sent: Tuesday, March 06, 2007 11:43 PM
To: Avi Lior; gwz@cisco.com; alper.yegin@yegin.org;
Pasi.Eronen@nokia.com; eap@frascone.com
Cc: radiusext@ops.ietf.org
Subject: RE: [eap] Ordered delivery of EAP messages

Avi Lior said:

"If an EAP method designer designed their method assuming the in order
delivery of packets then this would be a bad thing I think.

A hacker could then exploit this assumption by re-order the packets.
Surely EAP methods are not susceptible to this type of attack. Right?"

Certainly, it is a good thing for an EAP method to protect itself
against replay.  Using the mechanism provided in RFC 3579, an EAP method
could discard replayed packets and ask the NAS to send another one.

On the other hand, there are EAP methods that are not protected against
replay (e.g. Identity, Notification, etc.).  There are also situations
in which EAP packets can be fragmented, and if reassembled in the wrong
order, this could cause failure of the MIC which can be a terminal error
(e.g. in TLS-based methods).

So overall, I don't think that the majority of EAP methods deployed
today are capable of handling arbitrary reordering.



--
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, 07 Mar 2007 11:39:46 +0000
From: "Alper Yegin" 
To: "'Glen Zorn \(gwz\)'" , "'Bernard Aboba'" , 
Cc: , , 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 13:38:30 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdgMQqMZiN0SjwXQHuDtOzsvDkSoQAE0rIQAA7veWAACzDP0A==
Message-ID: <0MKoyl-1HOuTZ1JIV-0008RU@mrelay.perfora.net>

> Seems reasonable.  So why wouldn't this reasoning apply to EAP as well?

With the appropriate normative text in the RFC covering both end points this
could be used. But we don't have such text in RFC 3748.

Alper







> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
> Sent: Wednesday, March 07, 2007 8:17 AM
> To: Alper Yegin; Bernard Aboba; peterd@iea-software.com
> Cc: Pasi.Eronen@nokia.com; eap@frascone.com; radiusext@ops.ietf.org
> Subject: RE: [eap] Ordered delivery of EAP messages
> 
> Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25 PM:
> 
> >> Both EAP and RADIUS do not detect duplicates arriving out of order;
> >> they depend on the underlying lower layer to provide in-order
> >> delivery so as to enable duplicate detection.
> >
> > RFC 2865 says:
> >
> >       The RADIUS server can detect a duplicate request if
> >       it has the same client source IP address and source UDP port and
> >       Identifier within a short span of time.
> >
> > This, to me, implies duplicate detection on the server side does not
> > rely on orderly delivery. Keeping the history for "a short span of
> > time" allows duplicate detection irrespective of the order the
> > requests come in.
> 
> Agree.
> 
> >
> > As for the responses... Assuming the RADIUS client transmitted a
> > request twice (first one timed out), if it receives one of the
> > responses, would it still accept the second (duplicate) response if
> > it arrives as well? Wouldn't the RADIUS client just drop the second
> > response because there is no outstanding request to match anymore?
> 
> Seems reasonable.  So why wouldn't this reasoning apply to EAP as well?
> 
> >
> >
> > Alper


--
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, 07 Mar 2007 08:04:19 +0000
Message-ID: 
From: "Bernard Aboba" 
To: gwz@cisco.com, Pasi.Eronen@nokia.com, eap@frascone.com
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: RE: Issues & Fixes: Ordered delivery of EAP messages
Date: Wed, 07 Mar 2007 00:04:02 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>Ordered delivery & duplicate rejection aren't the same thing.

In general, that's true.  But if you have an ACK/NAK protocol that only 
allows a single packet in flight other than retransmissions, doesn't 
effective duplicate rejection imply ordered delivery?

>Suppose that the conditions you specify are met for the EAP peer and
>authenticator, as well.  Does that solve the problem?

If EAP were to implement duplicate rejection within a short time window, yes 
that would solve the problem.  We discussed this during the development of 
RFC 3748, partly out of the desire to reconcile EAP with IEEE 802.1X-2001 
which utilized a monotonically increasing Identifier field.  During that 
discussion we found that there were EAP implementations (such as the Solaris 
version, as I recall) that did not implement a duplicate rejection window.  
That is how the ordering guarantee found its way into RFC 3748, so as to 
guarantee that those implementations would work.



--
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, 07 Mar 2007 07:47:11 +0000
From: "Alper Yegin" 
To: "'Bernard Aboba'" , , , 
Cc: 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Tue, 6 Mar 2007 20:09:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acdf/KPtpihAGiyXR++8xap5r+RvSwAHWOlA
Message-ID: <0MKp2t-1HOe6Y06Cw-0006B5@mrelay.perfora.net>

The problem scenario requires EAP-layer retransmission, correct?
Authentication server does not perform such retransmission. So, I don't see
equivalence between the two legs of the EAP transport.

Alper

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Tuesday, March 06, 2007 4:35 PM
> To: gwz@cisco.com; Pasi.Eronen@nokia.com; eap@frascone.com
> Cc: radiusext@ops.ietf.org
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> Glen Zorn said:
> 
> "There are a couple of problems with this statement that I think are
> pertinent to the question at hand.  First, RADIUS is a "lockstep" protocol
> in almost (if not exactly) the same way that EAP is: the semantics of the
> Identifier field in the header of RADIUS messages are identical to that of
> the EAP version (RFC 2865 only says that the Identifier must change on new
> requests, not how it must change -- in particular, monotonicity is not
> assured) and requests are retransmitted.  The other problem is that
> neither
> RADIUS nor the underlying UDP transport guarantees in-order delivery of
> packets.  So, I would claim that this sentence is completely false."
> 
> I think you are correct.  If the RADIUS retransmission timer were
> under-estimated, RADIUS can deliver EAP messages out of order.  That is,
> the
>   NAS could retransmit an Access-Request, and then could receive an
> Access-Challenge in response to an earlier Access-Request.  The NAS would
> then send a new Access-Request, which could cross paths with the
> retransmitted one.
> 
> Note that if an Event-Timestamp attribute were to be included in the
> RADIUS
> Access-Request, then the Identifier would change on the retransmitted
> Access-Request.  The NAS would then be able to determine that a False
> Retransmission (FRTO) had occurred.  But from the point of view of the
> RADIUS server, I don't think it matters, since it won't be checking that
> the
> Event-Timestamp attribute is monotonically increasing.
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap


--
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, 07 Mar 2007 06:17:11 +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: [eap] Ordered delivery of EAP messages
Date: Tue, 6 Mar 2007 22:16:54 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2F4@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: AcdgMQqMZiN0SjwXQHuDtOzsvDkSoQAE0rIQAA7veWA=
From: "Glen Zorn \(gwz\)" 
To: "Alper Yegin" , "Bernard Aboba" , 
Cc: , , 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1186; t=1173248216; x=1174112216; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=ke8PTch05fL4SwC2jLIlvM/tAHEQ3y++i4HP6/icjbw=; b=olJMvLX1FFLB/0w7vL0pAGdjuZhptS+FE9k7k+CH6a9fXleIZApXSeNAcsGYt8dT5LwPdlu9 KH2V8WFm9X8axZSaHGYGsRWEoFo6YMX39yO7MAa2dpOqWNVfOvjgaTIM7JtN48vtqnSwPvpB55 12SWlijAgKTYV8d3fgaQ8qwVs=;
Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; );

Alper Yegin <> allegedly scribbled on Tuesday, March 06, 2007 3:25 PM:

>> Both EAP and RADIUS do not detect duplicates arriving out of order;
>> they depend on the underlying lower layer to provide in-order
>> delivery so as to enable duplicate detection.
>=20
> RFC 2865 says:
>=20
>       The RADIUS server can detect a duplicate request if
>       it has the same client source IP address and source UDP port and
>       Identifier within a short span of time.
>=20
> This, to me, implies duplicate detection on the server side does not
> rely on orderly delivery. Keeping the history for "a short span of
> time" allows duplicate detection irrespective of the order the
> requests come in.  =20

Agree.

>=20
> As for the responses... Assuming the RADIUS client transmitted a
> request twice (first one timed out), if it receives one of the
> responses, would it still accept the second (duplicate) response if
> it arrives as well? Wouldn't the RADIUS client just drop the second
> response because there is no outstanding request to match anymore? =20

Seems reasonable.  So why wouldn't this reasoning apply to EAP as well?
 =20
>=20
>=20
> Alper

--
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, 07 Mar 2007 05:51:37 +0000
From: "Alper Yegin" 
To: "'Bernard Aboba'" , 
Cc: , , , 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Wed, 7 Mar 2007 01:24:52 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcdgMQqMZiN0SjwXQHuDtOzsvDkSoQAE0rIQ
Message-ID: <0MKoyl-1HOj1b3yrW-0008UX@mrelay.perfora.net>

> Both EAP and RADIUS do not detect duplicates arriving out of order; they
> depend on the underlying lower layer to provide in-order delivery so as to
> enable duplicate detection.

RFC 2865 says:

      The RADIUS server can detect a duplicate request if
      it has the same client source IP address and source UDP port and
      Identifier within a short span of time.

This, to me, implies duplicate detection on the server side does not rely on
orderly delivery. Keeping the history for "a short span of time" allows
duplicate detection irrespective of the order the requests come in.

As for the responses... Assuming the RADIUS client transmitted a request
twice (first one timed out), if it receives one of the responses, would it
still accept the second (duplicate) response if it arrives as well? Wouldn't
the RADIUS client just drop the second response because there is no
outstanding request to match anymore?


Alper





--
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, 07 Mar 2007 05:32: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: Issues & Fixes: Ordered delivery of EAP messages
Date: Tue, 6 Mar 2007 21:32:13 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA2E7@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Issues & Fixes: Ordered delivery of EAP messages
Thread-Index: AcdgdtnNWnGU8s6oQUer+s9lO1HligAAm0XQ
From: "Glen Zorn \(gwz\)" 
To: "Bernard Aboba" , , 
Cc: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1492; t=1173245546; x=1174109546; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Issues=20&=20Fixes=3A=20Ordered=20delivery=20of=20EAP =20messages |Sender:=20; bh=2xSqtBMLpO/MK3RuxTdf8s/8OxBbtAr5uJnEaWWN+nw=; b=eWHZH+TOK2i5AX82IY0pKZdlFPRrDOUyb7A0V2VZRWc9Q41TuliuSFu+0NHucWE0Ieod/Syi 82RABJ5bdYNMdd/gynUGXxsMrzpXQYJWvbQ/sVGTt27HqFUVqvzo0p6+;
Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; );

Bernard Aboba  allegedly scribbled on
Tuesday, March 06, 2007 9:10 PM:

>> I've recently been reminded that I can be a bit too terse at times;
>> it appears that this is one of >those times.  I blame MO ;-).=20
>> Anyway, part of RFC 3748 that I quoted says
>>=20
>>        Encapsulation of EAP within RADIUS [RFC3579]
>>        satisfies ordering requirements, since RADIUS is a "lockstep"
>>        protocol that delivers packets in order.
>>=20
>> There are a couple of problems with this statement that I think are
>> pertinent to the question at >hand...
>=20
> Given the discussion, it would appear to me that RADIUS does provide
> for ordering and non-duplicate delivery of EAP packets,=20

Ordered delivery & duplicate rejection aren't the same thing. =20

> although the
> "lockstep" =20
> aspect is not as important as the following statement from RFC 2865,
> Section 3:
>=20
> "The RADIUS server can detect a duplicate request if it has the same
> client source IP address and source UDP port and Identifier within a
> short span of time." =20
>=20
> Therefore, assuming that the replay window is large enough in
> proportion to the RTT, and the NAS RTO estimate is in the ballpark
> and being backed off, then it seems like the problem is covered. =20
>=20
> Or am I missing something?

Suppose that the conditions you specify are met for the EAP peer and
authenticator, as well.  Does that solve the problem?

--
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, 07 Mar 2007 05:10:07 +0000
Message-ID: 
From: "Bernard Aboba" 
To: gwz@cisco.com, Pasi.Eronen@nokia.com, eap@frascone.com
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: Issues & Fixes: Ordered delivery of EAP messages
Date: Tue, 06 Mar 2007 21:09:50 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>I've recently been reminded that I can be a bit too terse at times; it 
>appears that this is one of >those times.  I blame MO ;-).  Anyway, part of 
>RFC 3748 that I quoted says
>
>        Encapsulation of EAP within RADIUS [RFC3579]
>        satisfies ordering requirements, since RADIUS is a "lockstep"
>        protocol that delivers packets in order.
>
>There are a couple of problems with this statement that I think are 
>pertinent to the question at >hand...

Given the discussion, it would appear to me that RADIUS does provide for 
ordering and non-duplicate delivery of EAP packets, although the "lockstep" 
aspect is not as important as the following statement from RFC 2865, Section 
3:

"The RADIUS server can detect a duplicate request if it has the same client 
source IP address and source UDP port and Identifier within a short span of 
time."

Therefore, assuming that the replay window is large enough in proportion to 
the RTT, and the NAS RTO estimate is in the ballpark and being backed off, 
then it seems like the problem is covered.

Or am I missing something?



--
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, 07 Mar 2007 04:54:56 +0000
Message-ID: 
From: "Bernard Aboba" 
To: alper.yegin@yegin.org
Cc: eap@frascone.com, radiusext@ops.ietf.org
Bcc: 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Tue, 06 Mar 2007 20:54:36 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>RFC 2865 says:
>
>       The RADIUS server can detect a duplicate request if
>       it has the same client source IP address and source UDP port and
>       Identifier within a short span of time.
>
>This, to me, implies duplicate detection on the server side does not rely 
>on
>orderly delivery. Keeping the history for "a short span of time" allows
>duplicate detection irrespective of the order the requests come in.

That advice seems sensible; if implemented, I think it would address the 
FRTO scenarios we have been discussing, wouldn't it?  Given client backoff, 
it seems highly unlikely that an Access-Request would be reordered outside 
of a "short span of time" (e.g. say, 1 minute).

>As for the responses... Assuming the RADIUS client transmitted a request
>twice (first one timed out), if it receives one of the responses, would it
>still accept the second (duplicate) response if it arrives as well? 
>Wouldn't
>the RADIUS client just drop the second response because there is no
>outstanding request to match anymore?

Yes, I think that the RADIUS client will drop a duplicate response.  The 
problem occurs more on the RADIUS server side, where the server could 
potentially send an Access-Reject if it wasn't doing duplicate detection as 
referred to above, and as a result the EAP method got mixed up.



--
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, 07 Mar 2007 04:43:24 +0000
Message-ID: 
From: "Bernard Aboba" 
To: avi@bridgewatersystems.com, gwz@cisco.com, alper.yegin@yegin.org, Pasi.Eronen@nokia.com, eap@frascone.com
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Tue, 06 Mar 2007 20:42:43 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Avi Lior said:

"If an EAP method designer designed their method assuming the in order
delivery of packets then this would be a bad thing I think.

A hacker could then exploit this assumption by re-order the packets.
Surely EAP methods are not susceptible to this type of attack. Right?"

Certainly, it is a good thing for an EAP method to protect itself against 
replay.  Using the mechanism provided in RFC 3579, an EAP method could 
discard replayed packets and ask the NAS to send another one.

On the other hand, there are EAP methods that are not protected against 
replay (e.g. Identity, Notification, etc.).  There are also situations in 
which EAP packets can be fragmented, and if reassembled in the wrong order, 
this could cause failure of the MIC which can be a terminal error (e.g. in 
TLS-based methods).

So overall, I don't think that the majority of EAP methods deployed today 
are capable of handling arbitrary reordering.



--
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, 07 Mar 2007 02:21:06 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Tue, 6 Mar 2007 21:21:15 -0500
Message-ID: 
From: "Avi Lior" 
To: "Avi Lior" , "Glen Zorn \(gwz\)" , "Alper Yegin" , "Bernard Aboba" , , 
Cc: 

As a follow on to my previous email message

If an EAP method designer designed their method assuming the in order
delivery of packets then this would be a bad thing I think.

A hacker could then exploit this assumption by re-order the packets.
Surely EAP methods are not susceptible to this type of attack. Right? =20

-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]=20
Sent: Tuesday, March 06, 2007 9:14 PM
To: Glen Zorn (gwz); Alper Yegin; Bernard Aboba; Pasi.Eronen@nokia.com;
eap@frascone.com
Cc: radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

Unless I am missing something most of the converstaion so far has been
related to efficiency.  That is, if the transport layer provides inorder
delivery the EAP works well.

I think we need to answer this question first:

Does EAP require to have inorder delivery to work correctly.  By work
correctly I mean that it does not falsely authenticate someone.

Can someone show how EAP falsely authenticate someone if packets arrive
in arbitrary order.


If this cant be shown the inorder delivery is not a MUST but a nice to
have feature of the transport layer and the statement in the RFC should
be changed from a MUST to a SHOULD.
=20

-----Original Message-----
From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Tuesday, March 06, 2007 6:45 PM
To: Alper Yegin; Bernard Aboba; Pasi.Eronen@nokia.com; eap@frascone.com
Cc: radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

Alper Yegin  allegedly scribbled on
Tuesday, March 06, 2007 10:10 AM:

> The problem scenario requires EAP-layer retransmission, correct?

Yes, I suppose so.

> Authentication server does not perform such retransmission.=20

>From the Abstract to RFC 3748 "EAP provides its own support for
duplicate elimination and retransmission..."; the Authenticator is
responsible for all retransmission.

> So, I
> don't see equivalence between the two legs of the EAP transport.=20

You are imagining that there are always 2 legs, which is not true; the
quoted portion of RFC 3748 does not state that assumption, either.  But
actually, you are right: it appears that RADIUS would generally be in
far greater peril of the risk then EAP, especially in a proxied network.

>=20
> Alper
>=20
>> -----Original Message-----
>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>> Sent: Tuesday, March 06, 2007 4:35 PM
>> To: gwz@cisco.com; Pasi.Eronen@nokia.com; eap@frascone.com
>> Cc: radiusext@ops.ietf.org
>> Subject: Re: [eap] Ordered delivery of EAP messages
>>=20
>> Glen Zorn said:
>>=20
>> "There are a couple of problems with this statement that I think are=20
>> pertinent to the question at hand.  First, RADIUS is a "lockstep"
>> protocol in almost (if not exactly) the same way that EAP is: the=20
>> semantics of the Identifier field in the header of RADIUS messages=20
>> are identical to that of the EAP version (RFC 2865 only says that the

>> Identifier must change on new requests, not how it must change -- in=20
>> particular, monotonicity is not
>> assured) and requests are retransmitted.  The other problem is that=20
>> neither RADIUS nor the underlying UDP transport guarantees in-order=20
>> delivery of packets.  So, I would claim that this sentence is=20
>> completely false."
>>=20
>> I think you are correct.  If the RADIUS retransmission timer were=20
>> under-estimated, RADIUS can deliver EAP messages out of order.  That
>>   is, the NAS could retransmit an Access-Request, and then could=20
>> receive an Access-Challenge in response to an earlier Access-Request.

>> The NAS would then send a new Access-Request, which could cross paths

>> with the retransmitted one.
>>=20
>> Note that if an Event-Timestamp attribute were to be included in the=20
>> RADIUS Access-Request, then the Identifier would change on the=20
>> retransmitted Access-Request.  The NAS would then be able to=20
>> determine that a False Retransmission (FRTO) had occurred.  But from=20
>> the point of view of the RADIUS server, I don't think it matters,=20
>> since it won't be checking that the Event-Timestamp attribute is=20
>> monotonically increasing.
>>=20
>>=20
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/eap
>>=20
>> Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

--
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, 07 Mar 2007 02:14:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Tue, 6 Mar 2007 21:13:59 -0500
Message-ID: 
From: "Avi Lior" 
To: "Glen Zorn \(gwz\)" , "Alper Yegin" , "Bernard Aboba" , , 
Cc: 

Unless I am missing something most of the converstaion so far has been
related to efficiency.  That is, if the transport layer provides inorder
delivery the EAP works well.

I think we need to answer this question first:

Does EAP require to have inorder delivery to work correctly.  By work
correctly I mean that it does not falsely authenticate someone.

Can someone show how EAP falsely authenticate someone if packets arrive
in arbitrary order.


If this cant be shown the inorder delivery is not a MUST but a nice to
have feature of the transport layer and the statement in the RFC should
be changed from a MUST to a SHOULD.
=20

-----Original Message-----
From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20
Sent: Tuesday, March 06, 2007 6:45 PM
To: Alper Yegin; Bernard Aboba; Pasi.Eronen@nokia.com; eap@frascone.com
Cc: radiusext@ops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

Alper Yegin  allegedly scribbled on
Tuesday, March 06, 2007 10:10 AM:

> The problem scenario requires EAP-layer retransmission, correct?

Yes, I suppose so.

> Authentication server does not perform such retransmission.=20

>From the Abstract to RFC 3748 "EAP provides its own support for
duplicate elimination and retransmission..."; the Authenticator is
responsible for all retransmission.

> So, I
> don't see equivalence between the two legs of the EAP transport.=20

You are imagining that there are always 2 legs, which is not true; the
quoted portion of RFC 3748 does not state that assumption, either.  But
actually, you are right: it appears that RADIUS would generally be in
far greater peril of the risk then EAP, especially in a proxied network.

>=20
> Alper
>=20
>> -----Original Message-----
>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>> Sent: Tuesday, March 06, 2007 4:35 PM
>> To: gwz@cisco.com; Pasi.Eronen@nokia.com; eap@frascone.com
>> Cc: radiusext@ops.ietf.org
>> Subject: Re: [eap] Ordered delivery of EAP messages
>>=20
>> Glen Zorn said:
>>=20
>> "There are a couple of problems with this statement that I think are=20
>> pertinent to the question at hand.  First, RADIUS is a "lockstep"
>> protocol in almost (if not exactly) the same way that EAP is: the=20
>> semantics of the Identifier field in the header of RADIUS messages=20
>> are identical to that of the EAP version (RFC 2865 only says that the

>> Identifier must change on new requests, not how it must change -- in=20
>> particular, monotonicity is not
>> assured) and requests are retransmitted.  The other problem is that=20
>> neither RADIUS nor the underlying UDP transport guarantees in-order=20
>> delivery of packets.  So, I would claim that this sentence is=20
>> completely false."
>>=20
>> I think you are correct.  If the RADIUS retransmission timer were=20
>> under-estimated, RADIUS can deliver EAP messages out of order.  That
>>   is, the NAS could retransmit an Access-Request, and then could=20
>> receive an Access-Challenge in response to an earlier Access-Request.

>> The NAS would then send a new Access-Request, which could cross paths

>> with the retransmitted one.
>>=20
>> Note that if an Event-Timestamp attribute were to be included in the=20
>> RADIUS Access-Request, then the Identifier would change on the=20
>> retransmitted Access-Request.  The NAS would then be able to=20
>> determine that a False Retransmission (FRTO) had occurred.  But from=20
>> the point of view of the RADIUS server, I don't think it matters,=20
>> since it won't be checking that the Event-Timestamp attribute is=20
>> monotonically increasing.
>>=20
>>=20
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/eap
>>=20
>> Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

--
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, 06 Mar 2007 23:46: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: [eap] Ordered delivery of EAP messages
Date: Tue, 6 Mar 2007 15:44:49 -0800
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625038BA1E6@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [eap] Ordered delivery of EAP messages
Thread-Index: Acdf/KPtpihAGiyXR++8xap5r+RvSwAHWOlAAAt8ngA=
From: "Glen Zorn \(gwz\)" 
To: "Alper Yegin" , "Bernard Aboba" , , 
Cc: 
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2975; t=1173224697; x=1174088697; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[eap]=20Ordered=20delivery=20of=20EAP=20messages |Sender:=20; bh=aWGvNL7t3BeN5LDdBd40vn67JdWOofHb5DsqQLjrPCw=; b=MJAuOe5itb2QIQ3U9aTa+sNqaaHEtOXODxOO8bpD3/nproJsqqtjSRqBX2tK9BI8t2CgeVZZ KxKm5RcMNlfTGhCTnWBfS6caLjsVF1yXrSk/qHyXa9GWWIyuy/E4ruf1;
Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; );

Alper Yegin  allegedly scribbled on
Tuesday, March 06, 2007 10:10 AM:

> The problem scenario requires EAP-layer retransmission, correct?

Yes, I suppose so.

> Authentication server does not perform such retransmission.=20

>From the Abstract to RFC 3748 "EAP provides its own support for
duplicate elimination and retransmission..."; the Authenticator is
responsible for all retransmission.

> So, I
> don't see equivalence between the two legs of the EAP transport.=20

You are imagining that there are always 2 legs, which is not true; the
quoted portion of RFC 3748 does not state that assumption, either.  But
actually, you are right: it appears that RADIUS would generally be in
far greater peril of the risk then EAP, especially in a proxied network.

>=20
> Alper
>=20
>> -----Original Message-----
>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>> Sent: Tuesday, March 06, 2007 4:35 PM
>> To: gwz@cisco.com; Pasi.Eronen@nokia.com; eap@frascone.com
>> Cc: radiusext@ops.ietf.org
>> Subject: Re: [eap] Ordered delivery of EAP messages
>>=20
>> Glen Zorn said:
>>=20
>> "There are a couple of problems with this statement that I think are
>> pertinent to the question at hand.  First, RADIUS is a "lockstep"
>> protocol in almost (if not exactly) the same way that EAP is: the
>> semantics of the Identifier field in the header of RADIUS messages
>> are identical to that of the EAP version (RFC 2865 only says that the
>> Identifier must change on new requests, not how it must change -- in
>> particular, monotonicity is not
>> assured) and requests are retransmitted.  The other problem is that
>> neither RADIUS nor the underlying UDP transport guarantees in-order
>> delivery of packets.  So, I would claim that this sentence is
>> completely false."=20
>>=20
>> I think you are correct.  If the RADIUS retransmission timer were
>> under-estimated, RADIUS can deliver EAP messages out of order.  That
>>   is, the NAS could retransmit an Access-Request, and then could
>> receive an Access-Challenge in response to an earlier
>> Access-Request.  The NAS would then send a new Access-Request, which
>> could cross paths with the retransmitted one.=20
>>=20
>> Note that if an Event-Timestamp attribute were to be included in the
>> RADIUS Access-Request, then the Identifier would change on the
>> retransmitted Access-Request.  The NAS would then be able to
>> determine that a False Retransmission (FRTO) had occurred.  But from
>> the point of view of the RADIUS server, I don't think it matters,
>> since it won't be checking that the Event-Timestamp attribute is
>> monotonically increasing.=20
>>=20
>>=20
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/eap
>>=20
>> Arhives: http://lists.frascone.com/pipermail/eap

--
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, 06 Mar 2007 22:10:05 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Review of RFC 4590bis
Date: Tue, 06 Mar 2007 14:09:19 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Section 3

Typos have been introduced into this Section.

Currently Section 3 reads as follows:

"3.  New RADIUS Attributes

   If not stated otherwise, the attributes have the following format:

   0                   1                   2
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       | Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Quote and backslash characters in Digest-* attributes representing
   HTTP-style directives with a quoted-string syntax are escaped.  The
   surrounding quotes are removed.  They are syntactical delimiters that
   are redundant in RADIUS.  For example, the directive

   realm="the

   is represented as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Digest-Realm  |       23      | the
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

Instead, it should read the same as in RFC 4590:

"3.  New RADIUS Attributes

   If not stated otherwise, the attributes have the following format:

   0                   1                   2
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       | Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Quote and backslash characters in Digest-* attributes representing
   HTTP-style directives with a quoted-string syntax are escaped.  The
   surrounding quotes are removed.  They are syntactical delimiters that
   are redundant in RADIUS.  For example, the directive

   realm="the \"example\" value"

   is represented as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Digest-Realm  |       23      | the \"example\" value |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

Section 5

The attribute table does not include entries for CoA-Request and 
Accounting-Request packets.  It also does not include a key explaining the 
meaning of the entries.  Also, it suggests that the User-Name is always 
present in an Access-Request, which contradicts the examples (See Issue 
196).  I suggest that it be rewritten as follows:

5.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

Access- Access- Access- Access- CoA- Acct-
Request Accept  Reject  Chlnge  Req  Req   #  Attribute
0-1      0      0      0       1    0-1   1  User-Name
1        1      1      1       1    0-1  80  Message-Authenticator
0-1      0      0      0       0    0   103  Digest-Response
0-1      0      0      1       0    0-1 104  Digest-Realm
0-1      0      0      1       0    0   105  Digest-Nonce
0      0-1      0      0       0    0   106  Digest-Response-Auth [1][2]
0      0-1      0      0       0    0   107  Digest-Nextnonce
1        0      0      0       0    0-1 108  Digest-Method
0-1      0      0      0       0    0-1 109  Digest-URI
0-1      0      0    0+        0    0-1 110  Digest-Qop
0-1      0      0    0-1       0    0-1 111  Digest-Algorithm [3]
0-1      0      0      0       0    0   112  Digest-Entity-Body-Hash
0-1      0      0      0       0    0   113  Digest-CNonce
0-1      0      0      0       0    0   114  Digest-Nonce-Count
0-1      0      0      0       0    0-1 115  Digest-Username
0-1      0      0    0-1       0    0   116  Digest-Opaque
0+      0+      0     0+       0    0   117  Digest-Auth-Param
0-1      0      0      0       0    0   118  Digest-AKA-Auts
0        0      0     0+       0    0-1 119  Digest-Domain
0        0      0    0-1       0    0   120  Digest-Stale
0      0-1      0      0       0    0   121  Digest-HA1 [1][2]
0-1      0      0      0       0    0   122  SIP-AOR
0-1      0      0      1       0    0    24  State [4]

   The following table defines the meaning of the above table entries.

     0     This attribute MUST NOT be present in the packet.
     0+    Zero or more instances of this attribute MAY be
           present in the packet.
     0-1   Zero or one instance of this attribute MAY be
           present in the packet.

   [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
   Digest-Qop is 'auth-int'.

   [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
   Digest-Qop is 'auth'.

   [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.

   [Note 4] An Access-Challenge MUST contain a State attribute, which is
   copied to the subsequent Access-Request.  A server receiving an
   Access-Request that contains a State attribute MUST respond with
   either an Access-Accept or an Access-Reject; the server MUST NOT
   respond with an Access-Challenge.

Appendix A

There is no section listing the changes between RFC 4590 and RFC 4590bis.  
Recommend that Appendix A be added:

Appendix A - Changes from RFC 4590

   This Appendix lists the major changes between [RFC4590] and this
   document.  Minor changes, including style, grammar, spelling, and
   editorial changes are not mentioned here.

   o The Table of Attributes (Section 5) now indicates that the Digest-
   Method attribute is required within an Access-Request.  Also, an
   entry has been added for the State attribute.  The table also
   includes entries for CoA-Request and Accounting-Request messages.  As
   noted in the examples, the User-Name attribute is not always present
   in an Access-Request.

   o Two errors in attribute assignment have been corrected within the
   IANA Considerations (Section 7).  Digest-Response-Auth is assigned
   attribute 106, and Digest-Nextnonce is assigned attribute 107.



--
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, 06 Mar 2007 20:56:53 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: RADEXT WG Agenda for IETF 68 (Take 3)
Date: Tue, 06 Mar 2007 12:56:41 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Date: Wednesday, March 21, 2007
Time: 9:00 - 11:30 AM
Room: KARLIN II

PRELIMINARIES (10 minutes)

Blue sheets
Minute takers
Agenda bash
Document Status

COMPLETED RADEXT WG LAST CALL (30 minutes)

Topic: 4590bis
Presenter: TBD
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-00.txt

Topic: 3576bis
Presenter: Bernard Aboba
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-00.txt

Topic: Issues & Fixes
Presenter: Alan DeKok
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-01.txt

WG WORK ITEMS (10 minutes)

Topic: Extended Filter Attribute
Presenter:  Mauricio Sanchez
Time: 10 minutes
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt

INDVIDUAL SUBMISSIONS (20 minutes)

Topic: WLAN Attributes
Presenter: Bernard Aboba
Time: 5 minutes
URL: http://www.watersprings.org/pub/id/draft-aboba-radext-wlan-03.txt

Topic: Design Guidelines
Presenter: Bernard Aboba
Time: 15 minutes
URL: 
http://www.watersprings.org/pub/id/draft-weber-radius-attr-guidelines-03.txt

CRYPTO-AGILITY (40 minutes)

Topic: Requirements for RADIUS Crypto-agility
Presenter: David Nelson
Time: 10 minutes
URLs:
http://ops.ietf.org/lists/radiusext/2007/msg00048.html
http://ops.ietf.org/lists/radiusext/2007/msg00053.html

Topic: RADIUS + DTLS
Presenter: Alan DeKok
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt

Topic: RADIUS crypto-agility
Presenter: Joe Salowey
Time: 20 minutes
URL: http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-12.txt



--
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, 06 Mar 2007 20:51:00 +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-rules-02.txt 
Message-Id: 
Date: Tue, 06 Mar 2007 15:50:04 -0500

--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 Attributes for Filtering and Redirection
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-rules-02.txt
	Pages		: 29
	Date		: 2007-3-6
	
This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic-
      Rule attributes within Remote Authentication Dial In User Service 
      (RADIUS) that is based on and extends on the filtering capability 
      defined by Diameter's NAS-Filter-Rule Attribute Value Pair (AVP) 
      described in RFC 4005, and the IPFilterRule syntax defined in RFC 
      3588.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-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-rules-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-rules-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:	<2007-3-6143159.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-filter-rules-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-rules-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2007-3-6143159.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: Tue, 06 Mar 2007 20:50:52 +0000
Message-ID: 
From: "Bernard Aboba" 
To: peterd@iea-software.com
Cc: alper.yegin@yegin.org, gwz@cisco.com, Pasi.Eronen@nokia.com, eap@frascone.com, radiusext@ops.ietf.org
Bcc: 
Subject: Re: [eap] Ordered delivery of EAP messages
Date: Tue, 06 Mar 2007 12:50:09 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>Assuming that per session there can only be one outstanding request for an 
>EAP conversation >since the conversation depends on acks from its peer to 
>continue.

ACK/NAK protocols can have more than one packet in flight, if you take false 
retransmissions into account.

>Then if new messages and retries are sent out in any order on the wire they 
>would either be detected by either side as duplicates or processed and 
>handled accordingly regardless of order of receipt.

Both EAP and RADIUS do not detect duplicates arriving out of order; they 
depend on the underlying lower layer to provide in-order delivery so as to 
enable duplicate detection.



--
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, 06 Mar 2007 18:41:03 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: REMINDER:  RADEXT WG last call on Issues & Fixes
Date: Tue, 06 Mar 2007 10:40:47 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

This is a reminder of the RADEXT WG last call on the Issues & Fixes 
Document, prior to sending the document to the IESG for consideration as a 
Proposed Standard.

The document is available on the IETF archive here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-01.txt

WG last call will last until March 15, 2007. Comments should be sent to the 
RADEXT WG mailing list (radiusext@ops.ietf.org), in the format described on 
the RADEXT Issues list:

http://www.drizzle.com/~aboba/RADEXT/



--
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, 06 Mar 2007 18:40:19 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: REMINDER:  RADEXT WG last call on RFC 4590bis
Date: Tue, 06 Mar 2007 10:39:58 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

This is a reminder about the ongoing RADEXT WG last call on RFC 4590bis, 
prior to sending the document to the IESG for consideration as a Proposed 
Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-00.txt

WG last call will last until March 9, 2007. Comments should be sent to the 
RADEXT WG mailing list (radiusext@ops.ietf.org), in the format described on 
the RADEXT Issues list:

http://www.drizzle.com/~aboba/RADEXT/



--
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, 06 Mar 2007 18:39:18 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: REMINDER:  RADEXT WG last call on RFC 3576bis
Date: Tue, 06 Mar 2007 10:39:01 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

This is a reminder of the RADEXT WG last call on RFC 3576bis, prior to 
sending the document to the IESG for consideration as a Proposed Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-00.txt

WG last call will last until March 9, 2007. Comments should be sent to the 
RADEXT WG mailing list (radiusext@ops.ietf.org), in the format described on 
the RADEXT Issues list:

http://www.drizzle.com/~aboba/RADEXT/



--
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, 06 Mar 2007 18:33:46 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: RADEXT WG Agenda at IETF 68 (take 2)
Date: Tue, 06 Mar 2007 10:33:30 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Date: Wednesday, March 21, 2007
Time: 9:00 - 11:30 AM
Room: KARLIN II

PRELIMINARIES (10 minutes)

Blue sheets
Minute takers
Agenda bash
Document Status

ITEMS IN RADEXT WG LAST CALL (30 minutes)

Topic: 4590bis
Presenter: TBD
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-00.txt

Topic: 3576bis
Presenter: Bernard Aboba
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-00.txt

Topic: Issues & Fixes
Presenter: Alan DeKok
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-01.txt

WG WORK ITEMS (10 minutes)

Topic: Extended Filter Attribute
Presenter:  Mauricio Sanchez
Time: 10 minutes

URL: 
http://www.watersprings.org/pub/id/draft-ietf-radext-filter-rules-01.txt

DESIGN GUIDELINES (20 minutes)

Topic: Design Guidelines
Presenter: Bernard Aboba
Time: 20 minutes

URL: 
http://www.watersprings.org/pub/id/draft-weber-radius-attr-guidelines-03.txt

CRYPTO-AGILITY (50 minutes)

Topic: Requirements for RADIUS Crypto-agility
Presenter: David Nelson
Time: 20 minutes
URL: http://ops.ietf.org/lists/radiusext/2007/msg00053.html

Topic: RADIUS + DTLS
Presenter: Alan DeKok
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt

Topic: RADIUS crypto-agility
Presenter: Joe Salowey
Time: 20 minutes
URL: http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-12.txt



--
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, 06 Mar 2007 18:25:30 +0000
Message-ID: 
From: "Bernard Aboba" 
To: alper.yegin@yegin.org, gwz@cisco.com, Pasi.Eronen@nokia.com, eap@frascone.com
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Tue, 06 Mar 2007 10:24:41 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

RADIUS could conceivably reorder packets even where there is no EAP 
retransmission.

This would seem to be most likely in trans-continental roaming scenarios 
where the RTTs could be quite large, and the RADIUS RTO is set low (e.g. a 
second or less) without backoff.

Trans-continential roaming test have shown very high failure rates for EAP 
conversations with lots of roundtrips, so I wouldn't be surprised if this 
issue was showing up in real networks.

One way to make this less likely would be for the NAS to detect FRTO via 
Event-Timestamp & Identifier change, and then wait until sending a new 
Access-Request, to allow the retransmitted Access-Request to drain from the 
network.


Alper said:

The problem scenario requires EAP-layer retransmission, correct?
Authentication server does not perform such retransmission. So, I don't see
equivalence between the two legs of the EAP transport.



--
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, 06 Mar 2007 14:35:29 +0000
Message-ID: 
From: "Bernard Aboba" 
To: gwz@cisco.com, Pasi.Eronen@nokia.com, eap@frascone.com
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: RE: [eap] Ordered delivery of EAP messages
Date: Tue, 06 Mar 2007 06:34:43 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Glen Zorn said:

"There are a couple of problems with this statement that I think are 
pertinent to the question at hand.  First, RADIUS is a "lockstep" protocol 
in almost (if not exactly) the same way that EAP is: the semantics of the 
Identifier field in the header of RADIUS messages are identical to that of 
the EAP version (RFC 2865 only says that the Identifier must change on new 
requests, not how it must change -- in particular, monotonicity is not 
assured) and requests are retransmitted.  The other problem is that neither 
RADIUS nor the underlying UDP transport guarantees in-order delivery of 
packets.  So, I would claim that this sentence is completely false."

I think you are correct.  If the RADIUS retransmission timer were 
under-estimated, RADIUS can deliver EAP messages out of order.  That is, the 
  NAS could retransmit an Access-Request, and then could receive an 
Access-Challenge in response to an earlier Access-Request.  The NAS would 
then send a new Access-Request, which could cross paths with the 
retransmitted one.

Note that if an Event-Timestamp attribute were to be included in the RADIUS 
Access-Request, then the Identifier would change on the retransmitted 
Access-Request.  The NAS would then be able to determine that a False 
Retransmission (FRTO) had occurred.  But from the point of view of the 
RADIUS server, I don't think it matters, since it won't be checking that the 
Event-Timestamp attribute is monotonically increasing.



--
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, 01 Mar 2007 18:59:12 +0000
Message-ID: 
From: "Bernard Aboba" 
To: aland@nitros9.org
Cc: radiusext@ops.ietf.org
Bcc: 
Subject: Re: Review of draft-ietf-radext-fixes-01.txt
Date: Thu, 01 Mar 2007 10:58:06 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>Bernard Aboba wrote:
> > Section 2.6
> >
> >   Where a NAS offers multiple services, confusion may result with
> >   respect to interpretation of a Disconnect-Request [RFC3576].  In
> >   order to prevent confusion a RADIUS Server SHOULD identify the
> >   session that it desires to terminate as specifically as possible.
> >   For example, an Acct-Session-Id attribute SHOULD be included in
> >   Disconnect-Request and CoA-Request packets, rather than just the
> >   User-Name attribute.
> >
> > I think this material might better belong in RFC 3576bis.
>
>   I have no objections.  We should therefore remove references to RFC
>3576 from the document, as that paragraph contains the only textual
>reference to that document.

Right.

>...
> > You might include a reference to the RADIUS Prefix Delegation document
> > (now in the RFC Editor Queue).
>
>   OK.
>
> >   It appears that the Framed-IPv6-Prefix is used for the link between
> >   the NAS and CPE only if a /64 prefix is assigned.  When a larger
> >   prefix is sent, the intent is for the NAS to send a routing
> >   advertisement containing the information present in the Framed-
> >   IPv6-Prefix attribute.
> >
> > Even if a /64 prefix is assigned, I think that the NAS is expected
> > to send an RA to the CPE, no?  Otherwise I'm not sure how the CPE
> > could learn the prefix.
>
>   I believe so, yes.
>
> > The other issue is how the CPE obtains a prefix to use for its own
> > network, in the case that the CPE is decrementing TTL.  Prefix
> > Delegation is the mechanism created for that purpose.  If the CPE
> > is acting as a Bridge or ND-Proxy, then it does not need to request
> > that a prefix be delegated.  It might make sense to say a few words
> > about this.
>
>   I will add a sentence about this.

Thanks.



--
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, 01 Mar 2007 15:35:41 +0000
Message-ID: <45E6F265.8060302@nitros9.org>
Date: Thu, 01 Mar 2007 16:33:57 +0100
From: Alan DeKok 
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Bernard Aboba 
CC:  radiusext@ops.ietf.org
Subject: Re: Review of draft-ietf-radext-fixes-01.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Section 2.6
> 
>   Where a NAS offers multiple services, confusion may result with
>   respect to interpretation of a Disconnect-Request [RFC3576].  In
>   order to prevent confusion a RADIUS Server SHOULD identify the
>   session that it desires to terminate as specifically as possible.
>   For example, an Acct-Session-Id attribute SHOULD be included in
>   Disconnect-Request and CoA-Request packets, rather than just the
>   User-Name attribute.
>
> I think this material might better belong in RFC 3576bis.

  I have no objections.  We should therefore remove references to RFC
3576 from the document, as that paragraph contains the only textual
reference to that document.

...
> You might include a reference to the RADIUS Prefix Delegation document
> (now in the RFC Editor Queue).

  OK.

>   It appears that the Framed-IPv6-Prefix is used for the link between
>   the NAS and CPE only if a /64 prefix is assigned.  When a larger
>   prefix is sent, the intent is for the NAS to send a routing
>   advertisement containing the information present in the Framed-
>   IPv6-Prefix attribute.
> 
> Even if a /64 prefix is assigned, I think that the NAS is expected
> to send an RA to the CPE, no?  Otherwise I'm not sure how the CPE
> could learn the prefix.

  I believe so, yes.

> The other issue is how the CPE obtains a prefix to use for its own
> network, in the case that the CPE is decrementing TTL.  Prefix
> Delegation is the mechanism created for that purpose.  If the CPE
> is acting as a Bridge or ND-Proxy, then it does not need to request
> that a prefix be delegated.  It might make sense to say a few words
> about this.

  I will add a sentence about this.

  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, 01 Mar 2007 05:01:16 +0000
Message-ID: 
From: "Bernard Aboba" 
To: radiusext@ops.ietf.org
Bcc: 
Subject: Proposed RADEXT WG Agenda for IETF 68 (Take 1)
Date: Wed, 28 Feb 2007 21:00:21 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

PRELIMINARIES (10 minutes)

Blue sheets
Minute takers
Agenda bash
Document Status

ITEMS IN RADEXT WG LAST CALL (30 minutes)

Topic: 4590bis
Presenter: TBD
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-00.txt

Topic: 3576bis
Presenter: Bernard Aboba
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-00.txt

Topic: Issues & Fixes
Presenter: Alan DeKok
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-01.txt

WG WORK ITEMS (10 minutes)

Topic: Extended Filter Attribute
Presenter:  Mauricio Sanchez
Time: 10 minutes
URL: 
http://www.watersprings.org/pub/id/draft-ietf-radext-filter-rules-01.txt

DESIGN GUIDELINES (20 minutes)

Topic: Design Guidelines
Presenter: Bernard Aboba
Time: 20 minutes
URL: 
http://www.watersprings.org/pub/id/draft-weber-radius-attr-guidelines-03.txt

CRYPTO-AGILITY (30 minutes)

Topic: Requirements for RADIUS Crypto-agility
Presenter: David Nelson
Time: 20 minutes
URL: http://ops.ietf.org/lists/radiusext/2007/msg00053.html

Topic: RADIUS + DTLS
Presenter: Alan DeKok
Time: 10 minutes
URL: http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt



--
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: 


Is the cost of breaking backward compatibility worth =
the removal of the Nonce attribute?





PatC



 -----Original Message-----

From:   Bernard Aboba [mailto:bernard_aboba@hotmail.co=
m]

Sent:   Wednesday, March 21, 2007 03:25 AM Pacific Standard =
Time

To:     radiusext@ops.ietf.org

Subject:        RFC 3576bis =
discussion at IETF 68



As part of the RFC 3576bis discussion, it was suggested that RFC =
3576bis

remove mention of the Nonce attribute, since this did not really =
address

replay protection.  Also, it should be clarified that the =
Event-Timestamp

attribute does NOT require changing the Identifier on a retransmision; =
the

Event-Timestamp refers to the time of the original transmission, and

therefore does not need to change on a re-transmission.



Also, it was pointed out that Event-Timestamp does not require =
synchronized

clocks, only for the RADIUS server to remember the last value for a =
given

NAS, and to make sure that it is monotonically increasing.



Any objections to implementing these suggestions in RFC 3576bis-01?







--

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/<=
/A>>