Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 28 Aug 2003 14:34:01 +0000 Message-ID: <499DC368E25AD411B3F100902740AD651C62872C@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: 'Avi Lior' , "CONGDON,PAUL (HP-Roseville,ex1)" , 'Bernard Aboba' Cc: "'radiusext@ops.ietf.org'" , stds-802-1@ieee.org Subject: RE: Strawman RADIUSEXT WG charter - Take Three Date: Thu, 28 Aug 2003 07:32:52 -0700 MIME-Version: 1.0 Content-Type: text/plain This is no different than the development of any other specification. If the definitive document is an IETF document then it must follow IETF rules. If the IEEE doesn't like the direction being taken in the IETF they must interject as anyone would following IETF rules of engagement. I'm not sure this is any different than how MIBs are cross developed either. Paul > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Wednesday, August 27, 2003 8:10 PM > To: 'CONGDON,PAUL (HP-Roseville,ex1)'; Avi Lior; 'Bernard Aboba' > Cc: 'radiusext@ops.ietf.org' > Subject: RE: Strawman RADIUSEXT WG charter - Take Three > > > I get your point -- but supposing I was to adopt your IEEE > standard and then wanted changes done. Nothing compels the > IEEE to address my concerns. At least at the IETF I can do > something about it. > > So for example, if the VSAs belonged to the WiFi Alliance > well I would have to pay $25K to have a voice there. > > So you are right, it is all about who and how ;-) > > > -----Original Message----- > > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > > Sent: August 27, 2003 4:16 PM > > To: 'Avi Lior'; 'Bernard Aboba' > > Cc: 'radiusext@ops.ietf.org' > > Subject: RE: Strawman RADIUSEXT WG charter - Take Three > > > > > > > > I could imagine official organizations defining their own > > VSAs and making them standardized by writing appropriate RFCs > > to document them. Since they aren't truly an independent > > vendor, implementers shouldn't have the same loss of control > > feeling you are talking about. We are doing something > > similar for IEEE 802.1AB (link layer discovery protocol). We > > are allowing other organizations to define their own > > attributes to exchange in the protocol. Thus, it might be > > possible to use VSAs to extend what might > > otherwise be considered base attributes. Its all about who > > and how they > > are defined, not whether the occupy the base number space or not. > > > > Paul > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, August 27, 2003 9:27 AM > > > To: 'Bernard Aboba' > > > Cc: 'radiusext@ops.ietf.org' > > > Subject: RE: Strawman RADIUSEXT WG charter - Take Three > > > > > > > > > The other issues with VSA is that if I was an SDO I would > not want > > > to standerdize my specification on someone elses VSAs. > > > I simply would not have control over these. > > > > > > IMO, an SDO that wants to make something interoperable > outside their > > > scope of control should define attributes using base RADIUS > > > attribute space. Hence these would be done using RFCs and be > > > reviewed in a WG such as RADIUSEXT. Hence the need to extend the > > > base RADIUS Space. > > > > > > So I agree with Bernard this is the best reason for having a > > > RADIUSEXT group. > > > > > > This is what the plan is for prepaid. While prepaid was > defined in > > > the 3GPP2 specs using 3GPP2 specifications, the authors > of the draft > > > want to use RADIUS base attributes. > > > Once this is approved in the IETF they would make the changes > > > in subsequent 3GPP2 specification. > > > > > > > > > > -----Original Message----- > > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > > Sent: Monday, August 25, 2003 7:48 PM > > > > To: Richard Perlman > > > > Cc: Mark Jones; 'radiusext@ops.ietf.org' > > > > Subject: Re: Strawman RADIUSEXT WG charter - Take Three > > > > > > > > > > > > > As a practical matter, server vendors have to update code > > > regularly > > > > > anyway because of new VSA implementations. I think the > > > > question here > > > > > is really whether we should simply accept new types, > > and possible > > > > > reduce the pressure on new VSAs (but, as Bernard has noted > > > > in another > > > > > posting, increasing the pressure on the "standard" > > > > attributes) or just > > > > > stay with VSAs as a way of accommodating the need for > new types. > > > > > > > > > > Personally, I'd vote to leave it as-is and stick with the > > > > well known, > > > > > and imperfect VSA route. > > > > > > > > The issue with VSAs is that they tend to be un or > > under-documented, > > > > which creates problems in implementation or even in maintaining > > > > compatibility with Diameter. > > > > > > > > Also, multiple VSAs are sometimes produced to handle the same > > > > function in slightly different ways, which impacts > > interoperability. > > > > > > > > Here's what RFC 2865, Section 6.2 says about VSAs: > > > > > > > > Note that RADIUS defines a mechanism for Vendor-Specific > > > extensions > > > > (Attribute 26) and the use of that should be encouraged > > > instead of > > > > allocation of global attribute types, for functions > > specific only > > > > to > > > > one vendor's implementation of RADIUS, where no > > > interoperability is > > > > deemed useful. > > > > > > > > The problem is that VSAs are used today even where > > interoperability > > > > is required (as in SDO specifications). The result is > that those > > > > specifications may not obtain adequate review. > > > > > > > > So perhaps the best argument for attribute expansion > (and perhaps > > > > even the existence of a RADIUSEXT WG) is that it would > > make it more > > > > likely that the review process envisaged in RFC 2865 will > > actually > > > > take place. > > > > > > > > -- > > > > to unsubscribe send a message to > > radiusext-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message > text body. > > > > archive: > > > > > > > > > > -- > > > to unsubscribe send a message to > > radiusext-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: > > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 28 Aug 2003 03:26:54 +0000 Message-ID: From: Avi Lior To: "'CONGDON,PAUL (HP-Roseville,ex1)'" , Avi Lior , 'Bernard Aboba' Cc: "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter - Take Three Date: Wed, 27 Aug 2003 23:10:09 -0400 MIME-Version: 1.0 Content-Type: text/plain I get your point -- but supposing I was to adopt your IEEE standard and then wanted changes done. Nothing compels the IEEE to address my concerns. At least at the IETF I can do something about it. So for example, if the VSAs belonged to the WiFi Alliance well I would have to pay $25K to have a voice there. So you are right, it is all about who and how ;-) > -----Original Message----- > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] > Sent: August 27, 2003 4:16 PM > To: 'Avi Lior'; 'Bernard Aboba' > Cc: 'radiusext@ops.ietf.org' > Subject: RE: Strawman RADIUSEXT WG charter - Take Three > > > > I could imagine official organizations defining their own > VSAs and making them standardized by writing appropriate RFCs > to document them. Since they aren't truly an independent > vendor, implementers shouldn't have the same loss of control > feeling you are talking about. We are doing something > similar for IEEE 802.1AB (link layer discovery protocol). We > are allowing other organizations to define their own > attributes to exchange in the protocol. Thus, it might be > possible to use VSAs to extend what might > otherwise be considered base attributes. Its all about who > and how they > are defined, not whether the occupy the base number space or not. > > Paul > > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Wednesday, August 27, 2003 9:27 AM > > To: 'Bernard Aboba' > > Cc: 'radiusext@ops.ietf.org' > > Subject: RE: Strawman RADIUSEXT WG charter - Take Three > > > > > > The other issues with VSA is that if I was an SDO I would not > > want to standerdize my specification on someone elses VSAs. > > I simply would not have control over these. > > > > IMO, an SDO that wants to make something interoperable > > outside their scope of control should define attributes using > > base RADIUS attribute space. Hence these would be done using > > RFCs and be reviewed in a WG such as RADIUSEXT. Hence the > > need to extend the base RADIUS Space. > > > > So I agree with Bernard this is the best reason for having a > > RADIUSEXT group. > > > > This is what the plan is for prepaid. While prepaid was > > defined in the 3GPP2 specs using 3GPP2 specifications, the > > authors of the draft want to use RADIUS base attributes. > > Once this is approved in the IETF they would make the changes > > in subsequent 3GPP2 specification. > > > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: Monday, August 25, 2003 7:48 PM > > > To: Richard Perlman > > > Cc: Mark Jones; 'radiusext@ops.ietf.org' > > > Subject: Re: Strawman RADIUSEXT WG charter - Take Three > > > > > > > > > > As a practical matter, server vendors have to update code > > regularly > > > > anyway because of new VSA implementations. I think the > > > question here > > > > is really whether we should simply accept new types, > and possible > > > > reduce the pressure on new VSAs (but, as Bernard has noted > > > in another > > > > posting, increasing the pressure on the "standard" > > > attributes) or just > > > > stay with VSAs as a way of accommodating the need for new types. > > > > > > > > Personally, I'd vote to leave it as-is and stick with the > > > well known, > > > > and imperfect VSA route. > > > > > > The issue with VSAs is that they tend to be un or > under-documented, > > > which creates problems in implementation or even in maintaining > > > compatibility with Diameter. > > > > > > Also, multiple VSAs are sometimes produced to handle the same > > > function in slightly different ways, which impacts > interoperability. > > > > > > Here's what RFC 2865, Section 6.2 says about VSAs: > > > > > > Note that RADIUS defines a mechanism for Vendor-Specific > > extensions > > > (Attribute 26) and the use of that should be encouraged > > instead of > > > allocation of global attribute types, for functions > specific only > > > to > > > one vendor's implementation of RADIUS, where no > > interoperability is > > > deemed useful. > > > > > > The problem is that VSAs are used today even where > interoperability > > > is required (as in SDO specifications). The result is that those > > > specifications may not obtain adequate review. > > > > > > So perhaps the best argument for attribute expansion (and perhaps > > > even the existence of a RADIUSEXT WG) is that it would > make it more > > > likely that the review process envisaged in RFC 2865 will > actually > > > take place. > > > > > > -- > > > 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: Wed, 27 Aug 2003 20:17:18 +0000 Message-ID: <499DC368E25AD411B3F100902740AD651C628722@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: 'Avi Lior' , 'Bernard Aboba' Cc: "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter - Take Three Date: Wed, 27 Aug 2003 16:16:08 -0400 MIME-Version: 1.0 Content-Type: text/plain I could imagine official organizations defining their own VSAs and making them standardized by writing appropriate RFCs to document them. Since they aren't truly an independent vendor, implementers shouldn't have the same loss of control feeling you are talking about. We are doing something similar for IEEE 802.1AB (link layer discovery protocol). We are allowing other organizations to define their own attributes to exchange in the protocol. Thus, it might be possible to use VSAs to extend what might otherwise be considered base attributes. Its all about who and how they are defined, not whether the occupy the base number space or not. Paul > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Wednesday, August 27, 2003 9:27 AM > To: 'Bernard Aboba' > Cc: 'radiusext@ops.ietf.org' > Subject: RE: Strawman RADIUSEXT WG charter - Take Three > > > The other issues with VSA is that if I was an SDO I would not > want to standerdize my specification on someone elses VSAs. > I simply would not have control over these. > > IMO, an SDO that wants to make something interoperable > outside their scope of control should define attributes using > base RADIUS attribute space. Hence these would be done using > RFCs and be reviewed in a WG such as RADIUSEXT. Hence the > need to extend the base RADIUS Space. > > So I agree with Bernard this is the best reason for having a > RADIUSEXT group. > > This is what the plan is for prepaid. While prepaid was > defined in the 3GPP2 specs using 3GPP2 specifications, the > authors of the draft want to use RADIUS base attributes. > Once this is approved in the IETF they would make the changes > in subsequent 3GPP2 specification. > > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Monday, August 25, 2003 7:48 PM > > To: Richard Perlman > > Cc: Mark Jones; 'radiusext@ops.ietf.org' > > Subject: Re: Strawman RADIUSEXT WG charter - Take Three > > > > > > > As a practical matter, server vendors have to update code > regularly > > > anyway because of new VSA implementations. I think the > > question here > > > is really whether we should simply accept new types, and possible > > > reduce the pressure on new VSAs (but, as Bernard has noted > > in another > > > posting, increasing the pressure on the "standard" > > attributes) or just > > > stay with VSAs as a way of accommodating the need for new types. > > > > > > Personally, I'd vote to leave it as-is and stick with the > > well known, > > > and imperfect VSA route. > > > > The issue with VSAs is that they tend to be un or > > under-documented, which creates problems in implementation or > > even in maintaining compatibility with Diameter. > > > > Also, multiple VSAs are sometimes produced to handle the same > > function in slightly different ways, which impacts interoperability. > > > > Here's what RFC 2865, Section 6.2 says about VSAs: > > > > Note that RADIUS defines a mechanism for Vendor-Specific > extensions > > (Attribute 26) and the use of that should be encouraged > instead of > > allocation of global attribute types, for functions > > specific only to > > one vendor's implementation of RADIUS, where no > interoperability is > > deemed useful. > > > > The problem is that VSAs are used today even where > > interoperability is required (as in SDO specifications). The > > result is that those specifications may not obtain adequate review. > > > > So perhaps the best argument for attribute expansion (and > > perhaps even the existence of a RADIUSEXT WG) is that it > > would make it more likely that the review process envisaged > > in RFC 2865 will actually take place. > > > > -- > > 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: Wed, 27 Aug 2003 16:28:17 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' Cc: "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter - Take Three Date: Wed, 27 Aug 2003 12:27:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The other issues with VSA is that if I was an SDO I would not want to standerdize my specification on someone elses VSAs. I simply would not have control over these. IMO, an SDO that wants to make something interoperable outside their scope of control should define attributes using base RADIUS attribute space. Hence these would be done using RFCs and be reviewed in a WG such as RADIUSEXT. Hence the need to extend the base RADIUS Space. So I agree with Bernard this is the best reason for having a RADIUSEXT group. This is what the plan is for prepaid. While prepaid was defined in the 3GPP2 specs using 3GPP2 specifications, the authors of the draft want to use RADIUS base attributes. Once this is approved in the IETF they would make the changes in subsequent 3GPP2 specification. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, August 25, 2003 7:48 PM > To: Richard Perlman > Cc: Mark Jones; 'radiusext@ops.ietf.org' > Subject: Re: Strawman RADIUSEXT WG charter - Take Three > > > > As a practical matter, server vendors have to update code regularly > > anyway because of new VSA implementations. I think the > question here > > is really whether we should simply accept new types, and possible > > reduce the pressure on new VSAs (but, as Bernard has noted > in another > > posting, increasing the pressure on the "standard" > attributes) or just > > stay with VSAs as a way of accommodating the need for new types. > > > > Personally, I'd vote to leave it as-is and stick with the > well known, > > and imperfect VSA route. > > The issue with VSAs is that they tend to be un or > under-documented, which creates problems in implementation or > even in maintaining compatibility with Diameter. > > Also, multiple VSAs are sometimes produced to handle the same > function in slightly different ways, which impacts interoperability. > > Here's what RFC 2865, Section 6.2 says about VSAs: > > Note that RADIUS defines a mechanism for Vendor-Specific extensions > (Attribute 26) and the use of that should be encouraged instead of > allocation of global attribute types, for functions > specific only to > one vendor's implementation of RADIUS, where no interoperability is > deemed useful. > > The problem is that VSAs are used today even where > interoperability is required (as in SDO specifications). The > result is that those specifications may not obtain adequate review. > > So perhaps the best argument for attribute expansion (and > perhaps even the existence of a RADIUSEXT WG) is that it > would make it more likely that the review process envisaged > in RFC 2865 will actually take place. > > -- > 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, 26 Aug 2003 14:10:30 +0000 Message-ID: From: Mark Jones To: "'radiusext@ops.ietf.org'" Subject: RE: Best Current Practices for WISP Roaming Date: Tue, 26 Aug 2003 10:09:40 -0400 MIME-Version: 1.0 Content-Type: text/plain > The WFA document on "Best Current Practices for WISP Roaming" > has now been made publicly available: > > http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf > > Among other things, this document defines new RADIUS > attributes for WLAN, using the IANA Private Enterprise Number > of 14122 that is registered to the WiFi Alliance (WFA). > The document has been public since sometime in spring and the VSAs are already supported by at least one AP vendor and one server vendor. IMO, this has turned in to a "feature fishing expedition" because the criteria for work item selection are unclear and are not being applied consistently. Mark -- 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, 26 Aug 2003 12:37:53 +0000 Date: Tue, 26 Aug 2003 05:06:43 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Best Current Practices for WISP Roaming Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The WFA document on "Best Current Practices for WISP Roaming" has now been made publicly available: http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf Among other things, this document defines new RADIUS attributes for WLAN, using the IANA Private Enterprise Number of 14122 that is registered to the WiFi Alliance (WFA). -- 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, 26 Aug 2003 05:23:51 +0000 Message-ID: <3F4AEDF2.4000509@piuha.net> Date: Tue, 26 Aug 2003 08:19:46 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 MIME-Version: 1.0 To: Bernard Aboba Cc: Randy Bush , Avi Lior , radiusext@ops.ietf.org Subject: Re: Extending RADIUS Attribute Space Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >>>C) Optionally address the issue of how to extend a message again >>>using EAP. >> >>again, which of the two critical target applications asked for >>that, why, and can it be done with less change to existing >>protocol? Almost all usage of EAP today is on link layers where the EAP MTU is already constrained to a smaller value than the RADIUS MTU. RFC 2869 enables the RADIUS peers to know what the link MTU is, so that they can take this into account. There are some new cases where we have discussed the possibility of making the MTU larger, such as IKEv2, where making the MTU larger would leave fragmentation to be handled by the IP layer, presumably in a more efficient fashion than at EAP layer. However, even in this case the controlling end of the EAP "connection", the AAA server, would know that it is running over RADIUS. So it could take this fact into account when choosing the MTU. Most EAP methods with long messages can fragment on their own -- otherwise they could not be run on popular link layers such as WLANs. In conclusion, as far as EAP goes, there does not appear to be a critical need for extended message lengths. --Jari -- 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, 26 Aug 2003 00:45:28 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Aug 2003 09:45:05 +0900 To: Richard Perlman Cc: radiusext@ops.ietf.org Subject: Re: Extending RADIUS Attribute Space Message-Id: > There is always a possibility that the "need" may be for more than the "two > critical target applications." I can appreciate the desire to not open this > WG up to a de-facto re-write of RADIUS. But, we should be sure that we > don't simply and arbitrarily exclude some generally needed work simply > because it is not one of the "two critical target applications." > > Or, to put it differently, maybe there are "three critical target > applications." and maybe there are 10,000 or 100,000,000,000,000. it's gotta stop somewhere. and, to get chartered, it's gonna stop at the ones specified. this is not a feature fishing expedition. it is back-patching radius to meet some very limited existing and deployed uses. we have diameter with which to go forward. randy -- 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, 26 Aug 2003 00:32:22 +0000 Date: Mon, 25 Aug 2003 16:48:00 -0700 (PDT) From: Bernard Aboba To: Richard Perlman cc: Mark Jones , "'radiusext@ops.ietf.org'" Subject: Re: Strawman RADIUSEXT WG charter - Take Three Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > As a practical matter, server vendors have to update code regularly anyway > because of new VSA implementations. I think the question here is really > whether we should simply accept new types, and possible reduce the pressure > on new VSAs (but, as Bernard has noted in another posting, increasing the > pressure on the "standard" attributes) or just stay with VSAs as a way of > accommodating the need for new types. > > Personally, I'd vote to leave it as-is and stick with the well known, and > imperfect VSA route. The issue with VSAs is that they tend to be un or under-documented, which creates problems in implementation or even in maintaining compatibility with Diameter. Also, multiple VSAs are sometimes produced to handle the same function in slightly different ways, which impacts interoperability. Here's what RFC 2865, Section 6.2 says about VSAs: Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. The problem is that VSAs are used today even where interoperability is required (as in SDO specifications). The result is that those specifications may not obtain adequate review. So perhaps the best argument for attribute expansion (and perhaps even the existence of a RADIUSEXT WG) is that it would make it more likely that the review process envisaged in RFC 2865 will actually take place. -- 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, 26 Aug 2003 00:14:45 +0000 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 25 Aug 2003 17:14:16 -0700 Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two) From: Richard Perlman To: Bernard Aboba CC: Glen Zorn , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Bernard; I don't disagree on any of your points. I'd say that improving fail-over behavior for RADIUS is not necessary at this point. However, as you have previously noted, the retry behavior is something we should try to improve. Richard On 8/25/03 4:36 PM, "Bernard Aboba" wrote: >> In the case of a RADIUS "ping," a "good" result would certainly always be >> true, while a "bad" result might be false (because it was delayed/lost in >> proxy, etc.). So, if the goal is to determine if a server is available, >> there might still be some value to this. > > As is noted in RFC 2865, such a "ping" doesn't provide much more > information than attempting to send a RADIUS Request. For example, there > is nothing that says that a NAS can't track responses from a RADIUS proxy > in order to know whether that proxy is functioning. The problem is when > the NAS doesn't hear anything for a period of time. Sending a "ping" all > the way to the end server just adds traffic to the system; the NAS could > just retransmit instead. > >> Of course, you could also specify >> that a "ping" request MUST not be forwarded (but that may extend the scope >> of the WG beyond what is reasonable and sensible). > > Such a "ping" would require a new command, and a fundmental change in > proxy forwarding behavior. So it's probably out of scope for now. > > The question in my mind is whether *any* credible work on failover is > possible without this level of change -- and whether even if the changes > were made, they would be deployed. Most vendors have their own failover > algorithms at this point, and I'd suggest that many would probably not > choose to implement another one unless it was compelling. -- 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, 26 Aug 2003 00:11:53 +0000 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 25 Aug 2003 17:09:54 -0700 Subject: Re: Strawman RADIUSEXT WG charter - Take Three From: Richard Perlman To: Bernard Aboba , Mark Jones CC: "'radiusext@ops.ietf.org'" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Mark, Berrnard: As a practical matter, server vendors have to update code regularly anyway because of new VSA implementations. I think the question here is really whether we should simply accept new types, and possible reduce the pressure on new VSAs (but, as Bernard has noted in another posting, increasing the pressure on the "standard" attributes) or just stay with VSAs as a way of accommodating the need for new types. Personally, I'd vote to leave it as-is and stick with the well known, and imperfect VSA route. Richard On 8/25/03 4:15 PM, "Bernard Aboba" wrote: >>> - No RADIUS "sub-types" will be defined. >> >> I do not understand how introducing new sub-types or data types impacts >> backwards compatibility anymore than permitting the addition of new >> attributes. > > Introducing new data types means that existing RADIUS servers would need > to have their code updated -- the new attributes could not be supported > merely by adding a dictionary entry. -- 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, 26 Aug 2003 00:07:29 +0000 Date: Mon, 25 Aug 2003 16:36:04 -0700 (PDT) From: Bernard Aboba To: Richard Perlman cc: Glen Zorn , radiusext@ops.ietf.org Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > In the case of a RADIUS "ping," a "good" result would certainly always be > true, while a "bad" result might be false (because it was delayed/lost in > proxy, etc.). So, if the goal is to determine if a server is available, > there might still be some value to this. As is noted in RFC 2865, such a "ping" doesn't provide much more information than attempting to send a RADIUS Request. For example, there is nothing that says that a NAS can't track responses from a RADIUS proxy in order to know whether that proxy is functioning. The problem is when the NAS doesn't hear anything for a period of time. Sending a "ping" all the way to the end server just adds traffic to the system; the NAS could just retransmit instead. > Of course, you could also specify > that a "ping" request MUST not be forwarded (but that may extend the scope > of the WG beyond what is reasonable and sensible). Such a "ping" would require a new command, and a fundmental change in proxy forwarding behavior. So it's probably out of scope for now. The question in my mind is whether *any* credible work on failover is possible without this level of change -- and whether even if the changes were made, they would be deployed. Most vendors have their own failover algorithms at this point, and I'd suggest that many would probably not choose to implement another one unless it was compelling. -- 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, 26 Aug 2003 00:00:23 +0000 Date: Mon, 25 Aug 2003 16:15:43 -0700 (PDT) From: Bernard Aboba To: Mark Jones cc: "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter - Take Three Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > - No RADIUS "sub-types" will be defined. > > I do not understand how introducing new sub-types or data types impacts > backwards compatibility anymore than permitting the addition of new > attributes. Introducing new data types means that existing RADIUS servers would need to have their code updated -- the new attributes could not be supported merely by adding a dictionary entry. -- 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, 26 Aug 2003 00:00:21 +0000 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 25 Aug 2003 16:59:33 -0700 Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two) From: Richard Perlman To: Bernard Aboba , Glen Zorn CC: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Bernard, two short comments... Richard On 8/25/03 4:14 PM, "Bernard Aboba" wrote: > One problem with a "ping" based on existing RADIUS functionality is that > it too could be proxied. So if the goal is to get an idea of the health > of the next hop, then this doesn't help. Heartbeat appears to me to > be one of those things that is intrinsically done better in Diameter -- > with its TCP/SCTP transport, non-proxiable heartbeats, etc. In the case of a RADIUS "ping," a "good" result would certainly always be true, while a "bad" result might be false (because it was delayed/lost in proxy, etc.). So, if the goal is to determine if a server is available, there might still be some value to this. Of course, you could also specify that a "ping" request MUST not be forwarded (but that may extend the scope of the WG beyond what is reasonable and sensible). >> The draft also makes a couple of assumptions that are novel, at least to >> me. Is it true that RADIUS clients regularly choose proxies based upon >> NAI or some other piece of authentication data? > > I've never seen this, but perhaps someone else has. I have seen several requests from service providers for this "feature," but I don't know if any client vendors actually implement it. However, it seems that the concept behind RADIUS is to provide a centralized AAA service and placing routing intelligence in the client would seem to defeat that idea. -- 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, 25 Aug 2003 23:57:44 +0000 Date: Mon, 25 Aug 2003 16:26:32 -0700 (PDT) From: Bernard Aboba To: Randy Bush cc: Avi Lior , radiusext@ops.ietf.org Subject: RE: Extending RADIUS Attribute Space Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > A) As a minimum, create a mechanism to create more RADIUS > > attribute types in a way that is backwards compatible with > > existing RADIUS. > > why? i.e. which of the two critical target applications asked for > that, why, and can it be done with less change to existing > protocol? There might be an argument that pressure on the attribute space has so far been relieved only because VSAs have been used for the majority of new applications. If use of standard attributes were to be encouraged, then conceivably the rate of attribute exhaustion would greater than it is today. However, that's more of an argument for a future issue than an argument for why attribute space expansion is needed to allow an existing draft to go forward (which is the argument that is being made). > who? which of the two critical target applications? note that the > set of "someone asked for that" is often not numerable and does not > tend to shrink over time. So far, the only example that has been put forward is the Cable Lab spec, which apparently solved the problem without extending the length. Based on that, a standard way of concatenating the existing attributes seems to make sense, but it's hard to see why anything beyond that is required. > > C) Optionally address the issue of how to extend a message again > > using EAP. > > again, which of the two critical target applications asked for > that, why, and can it be done with less change to existing > protocol? Certainly, EAP users have never asked for this -- and would probably be horrified at the thought, since it would break interoperability. -- 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, 25 Aug 2003 23:45:21 +0000 Date: Mon, 25 Aug 2003 16:14:07 -0700 (PDT) From: Bernard Aboba To: Glen Zorn cc: radiusext@ops.ietf.org Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thank you for your review! > In the specific case of server overload due to > network-wide reboot (which is the best argument I've heard for tweaking > the RADIUS retransmission method), the primary problem isn't that > packets are being dropped by intermediate nodes due to network > congestion (although in severe cases congestion might be a seen). It is possible, with a large number of NASes, to encounter what is sometimes called "convergent congestion". That is, the RADIUS traffic sent by each NAS is small, but when it is aggregated near the RADIUS server, it is large enough to congest one or more links. This would be most likely to happen in an ISP network. In corporate network situations (where I've seen the problem occur), the backbone is typically 100 Mbps Ethernet or greater, so congestion of the backbone is relatively unlikely unless there are a large number of NASes. > Instead, the problem is that too many RADIUS messages are getting > through the network simultaneously; in this case, network congestion > might be the RADIUS server's friend, giving it a chance to catch up! Or the messages might be dropped in the RADIUS server itself. In general, the principle of "conservation of packets" (where additional packets are not injected into the system until an existing packet is determined to have left it) is designed to ensure that the response of the system to packet loss is a gain of less than 1 -- that is, that dropped packets do not result in even more packets being sent, but rather, in the rate decreasing to the point where the RADIUS server (and network) can handle the load. Unless the system is designed to be conservative in this way, packet loss won't necessary help the RADIUS server catch up -- because it could result in even more packets being sent, not less. That's the function of Additive Increase, Multiplicate Decrease (AIM) rate control. > Rather than an exponential back-off, the introduction of transmission > jitter might be a more effective strategy. Jittering is indeed important in the power loss case. Spreading requests out over a minute (as opposed to concentrating requests within the first 10 seconds) would decrease the initial rate by a factor of 6. > For "how many times to > retry", the answer is also unspecified. The rest of the questions are > also answered in simplistic and/or unhelpful ways. For example, > "failback" occurs after the expiration of an apparently static timer. This is a violation of "Conservation of Packets", because it could result in additional packets being sent into the network when there is no evidence that the original ones had left it. > Since the failback operation is not based upon any indication of the > failed server's health, this could very easily result in the abandonment > of a functional server in favor of a server that is down. It seems like > some type of metric of server responsiveness could be developed instead > so that the most responsive server would always be used; a simpler > method yet might be a timer-based RADIUS "ping" to discover whether a > given server is alive. One problem with a "ping" based on existing RADIUS functionality is that it too could be proxied. So if the goal is to get an idea of the health of the next hop, then this doesn't help. Heartbeat appears to me to be one of those things that is intrinsically done better in Diameter -- with its TCP/SCTP transport, non-proxiable heartbeats, etc. > The draft also makes a couple of assumptions that are novel, at least to > me. Is it true that RADIUS clients regularly choose proxies based upon > NAI or some other piece of authentication data? I've never seen this, but perhaps someone else has. > The last time I > checked, routing of RADIUS packets was the job of proxies, not clients, > but I won't claim to be familiar with the state of the art. In > addition, I was not aware that RADIUS proxies regularly implemented the > timeout and retry algorithm. If so, this seems like it would > _increase_, rather than decrease network traffic. Timeout and retry is pretty dangerous on a proxy because NASes already do retransmission. Thus typically, RADIUS transport dynamics is end-to-end between the NAS and ultimate RADIUS server -- which makes it very difficult for the NAS to know why a server isn't responding. It's much the same with a conversation between two Internet hosts -- did a router somewhere in the network die, or was the server not up? Like routers, RADIUs proxies only make a forwarding decision, they do not do timeout and retry, because doing so not only change the end-to-end dynamics, but would add gain to the system -- and would violate conservation of packets. -- 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, 25 Aug 2003 23:34:35 +0000 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 25 Aug 2003 16:33:06 -0700 Subject: Re: Extending RADIUS Attribute Space From: Richard Perlman To: Randy Bush , Avi Lior CC: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Randy: There is always a possibility that the "need" may be for more than the "two critical target applications." I can appreciate the desire to not open this WG up to a de-facto re-write of RADIUS. But, we should be sure that we don't simply and arbitrarily exclude some generally needed work simply because it is not one of the "two critical target applications." Or, to put it differently, maybe there are "three critical target applications." Richard On 8/25/03 4:04 PM, "Randy Bush" wrote: ... > a VERY few VERY SPECIFIC needs for two VERY SPECIFIC applications. > as you say, it is not to redo the trip down the diameter road, we > have already been there, and the sights were not enthralling. ... > why? i.e. which of the two critical target applications asked for > that, why, and can it be done with less change to existing > protocol? ... > who? which of the two critical target applications? note that the > set of "someone asked for that" is often not numerable and does not > tend to shrink over time. .. > again, which of the two critical target applications asked for > that, why, and can it be done with less change to existing > protocol? -- 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, 25 Aug 2003 23:04:24 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Aug 2003 08:04:07 +0900 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Extending RADIUS Attribute Space Message-Id: > I thought that this RADIUS EXT group is forming to help address > some of the new needs in RADIUS. a VERY few VERY SPECIFIC needs for two VERY SPECIFIC applications. as you say, it is not to redo the trip down the diameter road, we have already been there, and the sights were not enthralling. > A) As a minimum, create a mechanism to create more RADIUS > attribute types in a way that is backwards compatible with > existing RADIUS. why? i.e. which of the two critical target applications asked for that, why, and can it be done with less change to existing protocol? > B) As part of that we could provide a way to increase the message > size (someone asked for that). who? which of the two critical target applications? note that the set of "someone asked for that" is often not numerable and does not tend to shrink over time. > C) Optionally address the issue of how to extend a message again > using EAP. again, which of the two critical target applications asked for that, why, and can it be done with less change to existing protocol? randy -- 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, 25 Aug 2003 19:08:10 +0000 Reply-To: From: "Glen Zorn" To: "'Nelson, David'" Cc: Subject: RE: Strawman RADIUSEXT WG charter - Take Two Date: Mon, 25 Aug 2003 12:07:09 -0700 Organization: Cisco Systems Message-ID: <015d01c36b3c$27dc1390$909c4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nelson, David writes: ... > I don't know how to judge whether it's a contradiction, but (IMHO) it > certainly isn't a conflict of interest. The latter would imply that > actions and decisions in one WG would be adversely influenced by the > best interests of another. That's not the way in which I view the > proposed RADIUSEXT WG. =20 The _existence_ of the radiusext WG would adversely effect the work of the aaa WG, as well as the deployment of Diameter; I think that to suggest otherwise is na=EFve at best. To use your example of IPv6 vs. IPv4, do you think that if someone proposed a backward-compatible way to extend the v4 address space to 128 bits that that would be a boon to IPv6? =20 >=20 > Yes, Diameter is intended to replace RADIUS, much in the same way > that same way that IPv6 is intended to replace IPv4. Recently, > however, the Internet community has been speaking about IPv4 / IPv6 > co-existence more than it is speaking about transition or > replacement. I think we can take this approach with RADIUS. RADIUS > will likely continue to be used in problem spaces where it is > sufficiently useful. When the problem space requires the additional > flexibility and features of Diameter, that's what will likely be > deployed. =20 If that was true, we wouldn't be having this conversation: the only justification for this WG would be that RADIUS in its present form is _not_ sufficiently useful in problem spaces where people want or need to use it. =20 >=20 > The only question that I think needs to be answered here is whether > there is a valid need for a limited set of extensions to RADIUS, in > the existing protocol framework, that will not substantially > duplicate the features of Diameter. =20 Too late. In my mind the real question whether we will have two broken, inadequate AAA protocols (as now) or only one. I really don't care which one gets fixed, but given the IESG's ongoing & steadfast opposition to Diameter maybe RADIUS is the best choice. >=20 > -- Dave Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..."=20 -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets."=20 -- Voltaire -- 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, 25 Aug 2003 18:49:32 +0000 Message-ID: From: Mark Jones To: "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter - Take Three Date: Mon, 25 Aug 2003 14:49:11 -0400 MIME-Version: 1.0 Content-Type: text/plain > - No RADIUS "sub-types" will be defined. I do not understand how introducing new sub-types or data types impacts backwards compatibility anymore than permitting the addition of new attributes. Any new data types would only apply to new attributes. A RADIUS client/server either has these attributes in its data dictionary or it doesn't. If it doesn't, it is free to ignore them. How is this different from the introduction of IPv6 addresses in RFC2162? > - No "attribute grouping" mechanism will be defined. As it stands, new data types are being defined and each one requires new encode/decode routines to be implemented in client and server. Many of these new attributes are simply groupings of attributes of existing data types. If RADIUS had a defined mechanism for grouping attributes, most of the non-standard 3GPP/3GPP2 attribute data types could have been defined as groups of attributes. I agree wholeheartedly that we should not be re-inventing the wheel on this. Diameter already has grouped attributes so we should follow the same approach. Mark -- 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, 25 Aug 2003 18:47:22 +0000 Date: Mon, 25 Aug 2003 14:47:02 -0400 From: Barney Wolff To: radiusext@ops.ietf.org Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two) Message-ID: <20030825184702.GA46124@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i On Mon, Aug 25, 2003 at 11:21:40AM -0700, Glen Zorn wrote: > > The draft also makes a couple of assumptions that are novel, at least to > me. Is it true that RADIUS clients regularly choose proxies based upon > NAI or some other piece of authentication data? The last time I > checked, routing of RADIUS packets was the job of proxies, not clients, > but I won't claim to be familiar with the state of the art. A proxy is a client of whatever it sends the request on to. > In > addition, I was not aware that RADIUS proxies regularly implemented the > timeout and retry algorithm. If so, this seems like it would > _increase_, rather than decrease network traffic. A proxy can't just blindly forward the request unchanged, because (at least) there may be id collisions. Certainly the proxy I wrote years ago took active responsibility for throttling, retry and failover. That meant, among other things, suppressing duplicate requests if it was still working on the first attempt. While this was a violation of the end-to-end heuristic of system design, in the particular situation we had control over the proxy code but not even access to the client code. "Network traffic" is not a useful concept; particular links, routers and hosts may be congested, or not. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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, 25 Aug 2003 18:23:09 +0000 Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two) Date: Mon, 25 Aug 2003 11:21:40 -0700 Organization: Cisco Systems Message-ID: <014d01c36b35$cd0cc230$909c4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba writes: >> Is there evidence that this 'lack' is a fatal flaw? > > The draft below attempts to make the case for this work item. Could > you review it and send your thoughts to the list? > > http://www.ietf.org/internet-drafts/draft-lior-radius-reliable-accountin g-00.txt > This draft raises a number of questions, but unfortunately doesn't answer many (if any). This is not necessarily a criticism of the draft, however, since the questions posed, I believe, can only be answered in the context of specific network topologies and deployments. For example, section 2.1 says (in reference to retransmission of RADIUS messages): "How long to wait, how many times to retry, how to fail over, how and when to failback, is not covered by the RADIUS specification." The draft claims that this is a 'shortcoming' of the specification(s) in question; I would claim otherwise, but even if we accept that this omission should be rectified, this draft doesn't do it. WRT to "how long to wait", the draft gives a variable "T-retry" which is initialized to an unspecified minimum value and doubled with each failure until it reaches a similarly unspecified maximum. To me, it's difficult to distinguish this from RFC 2865's prescription to wait "some period of time". As I've mentioned before, I don't understand the use of an exponential back-off or other TCP-like methods in RADIUS. Correct me if I'm wrong, but I thought that the primary purpose of the TCP retransmission algorithm was to ensure that packets get through the network no matter what. In the specific case of server overload due to network-wide reboot (which is the best argument I've heard for tweaking the RADIUS retransmission method), the primary problem isn't that packets are being dropped by intermediate nodes due to network congestion (although in severe cases congestion might be a seen). Instead, the problem is that too many RADIUS messages are getting through the network simultaneously; in this case, network congestion might be the RADIUS server's friend, giving it a chance to catch up! Rather than an exponential back-off, the introduction of transmission jitter might be a more effective strategy. In any case, there are lots of ways to deal with the problem that would almost certainly be more effective than a protocol-based approach. For "how many times to retry", the answer is also unspecified. The rest of the questions are also answered in simplistic and/or unhelpful ways. For example, "failback" occurs after the expiration of an apparently static timer. Since the failback operation is not based upon any indication of the failed server's health, this could very easily result in the abandonment of a functional server in favor of a server that is down. It seems like some type of metric of server responsiveness could be developed instead so that the most responsive server would always be used; a simpler method yet might be a timer-based RADIUS "ping" to discover whether a given server is alive. The draft also makes a couple of assumptions that are novel, at least to me. Is it true that RADIUS clients regularly choose proxies based upon NAI or some other piece of authentication data? The last time I checked, routing of RADIUS packets was the job of proxies, not clients, but I won't claim to be familiar with the state of the art. In addition, I was not aware that RADIUS proxies regularly implemented the timeout and retry algorithm. If so, this seems like it would _increase_, rather than decrease network traffic. Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire -- 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, 25 Aug 2003 17:59:09 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , 'Greg Weber' Cc: "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter Date: Mon, 25 Aug 2003 13:58:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > Given there is a claim of usefulness and apparently some > uncertainty, > > is it desirable to preclude this work in the charter itself, as > > opposed to simply not having a current work item for the attribute > > space until need can possibly be demonstrated? > > That's reasonable. First: Why not just not have an explict workitem for this until its needed. Why are we prohibiting this explicitly in the charter? Second, given the following statement in the charter: "In order to ensure backward compatibility with RADIUS, the following restrictions are imposed on extensions considered by the RADIUSEXT WG:" Attribute Space Extension does not break backwards compatiblity in RADIUS so I don't see why it is to be excluded in the first place. The same is true about half the other "NO" items in the list. Second: I read packet cable specification. The problem is that their method of dealing with large attributes is not general. The Vendor Attribute length is still only 1 octet. Therefore they have to know which attributes are longer and they would have some difficulty in supporting multiple large attributes of the same kind. The solution that we proposed (in an earlier email) provides a clean approach to this problem. -Use a Vendor Attribute length that is 2 octets. If the length is greater than 247 then the next attribute is an extension. Repeat the concatenation until you satisfied the original length. This way you at least know how long the attribute is. A) Use Vendor Id zero to extend RADIUS attribute space; B) Use 2 octets for the internal length of the attribute; This is a slight modification on the recommendation in 2865. Instead of having a 1 octet length for the Vendor Attribute Length you have 2 octets of length. You can easily solve both these problems. What are we afraid of here? What is the issue? > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, August 25, 2003 11:21 AM > To: Greg Weber > Cc: radiusext@ops.ietf.org > Subject: Re: Strawman RADIUSEXT WG charter > > > > Given there is a claim of usefulness and apparently some > uncertainty, > > is it desirable to preclude this work in the charter itself, as > > opposed to simply not having a current work item for the attribute > > space until need can possibly be demonstrated? > > That's reasonable. > > > > Are they useful for newer applications as well as legacy ones? > > > > I'm not sure I can answer that right now, but my main point > was that I > > don't think we want to preclude describing something that we've > > defined and allocated in RFC 3575. I'm fine with the > language in your > > subsequent strawmen. > > OK. > > > > Can you describe the issues that came up in the PacketCable 1.0 > > > spec? > > > > Some of the attributes needed to support lawful intercept for voice > > exceeded the maximum length for VSAs. The PacketCable spec > defines a > > scheme for fragmenting data across VSAs in section 13.1.5.2 > of their > > event messaging spec: > > > http://www.packetcable.com/downloads/specs/PKT> -SP-EM-I07-030815.pdf > > > > RFC 2865 already offers SHOULD advice on the VSA attribute > encoding. > > I think it would be helpful to offer some guidance on long VSA > > attributes, so we don't end up with a profusion of incompatible > > techniques like PacketCable's. > > That seems reasonable, particularly since this issue has come > up in a deployed application. > > > -- > 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: Mon, 25 Aug 2003 15:52:25 +0000 Date: Mon, 25 Aug 2003 08:20:57 -0700 (PDT) From: Bernard Aboba To: Greg Weber cc: radiusext@ops.ietf.org Subject: Re: Strawman RADIUSEXT WG charter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Given there is a claim of usefulness and apparently some uncertainty, > is it desirable to preclude this work in the charter itself, as opposed > to simply not having a current work item for the attribute space until > need can possibly be demonstrated? That's reasonable. > > Are they useful for newer applications as well as legacy ones? > > I'm not sure I can answer that right now, but my main point > was that I don't think we want to preclude describing something > that we've defined and allocated in RFC 3575. I'm fine with the > language in your subsequent strawmen. OK. > > Can you describe the issues that came up in the PacketCable > > 1.0 spec? > > Some of the attributes needed to support lawful intercept for > voice exceeded the maximum length for VSAs. The PacketCable > spec defines a scheme for fragmenting data across VSAs in > section 13.1.5.2 of their event messaging spec: > http://www.packetcable.com/downloads/specs/PKT-SP-EM-I07-030815.pdf > > RFC 2865 already offers SHOULD advice on the VSA attribute > encoding. I think it would be helpful to offer some guidance > on long VSA attributes, so we don't end up with a profusion of > incompatible techniques like PacketCable's. That seems reasonable, particularly since this issue has come up in a deployed application. -- 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, 25 Aug 2003 15:33:32 +0000 From: Greg Weber Message-Id: <200308251532.LAA28265@cisco.com> Subject: Re: Strawman RADIUSEXT WG charter To: aboba@internaut.com (Bernard Aboba) Date: Mon, 25 Aug 2003 11:32:28 -0400 (EDT) Cc: gdweber@cisco.com (Greg Weber), radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Would this last sentence preclude future work items to > > specify the behavior of packet types reserved by RFC 3575, but > > not defined by RFC 2882? In particular, I think producing > > a specification for packet type codes 33 & 34 (Event-Request/ > > Response) will be useful in a number of forums and can be > > done in a Diameter compatible way. > > The focus is on extensions that are already deployed or providing > support for extensions that are already deployed. For example, there is > work that SIPPING WG would like to do in order to standardize SIP use of > RADIUS accounting, and they have requested work on RADIUS prepaid and > RADIUS transport profiles to support that. It has been claimed that > RADIUS prepaid work would benefit from an extension of the attribute > space. Given there is a claim of usefulness and apparently some uncertainty, is it desirable to preclude this work in the charter itself, as opposed to simply not having a current work item for the attribute space until need can possibly be demonstrated? > And there are WLAN extensions that have already been defined in > WFA, IEEE 802, vendor-specific attributes, etc. > > So my question is: > > What do packet type codes 33 and 34 do? Are these extensions used today? These packet types are used for cross-session accounting data and do ship today from a major NAS/server vendor as a google search will show. > Are they useful for newer applications as well as legacy ones? I'm not sure I can answer that right now, but my main point was that I don't think we want to preclude describing something that we've defined and allocated in RFC 3575. I'm fine with the language in your subsequent strawmen. > > Will this work item include addressing the attribute size > > limitation in the extended space? A number of methods > > for fragmenting large values across attributes have popped > > up, e.g. as in the PacketCable 1.0 spec. It would be nice > > to have a standard way of doing this. > > If this represents something that is already deployed, then it might be > appropriate. Can you describe the issues that came up in the PacketCable > 1.0 spec? Some of the attributes needed to support lawful intercept for voice exceeded the maximum length for VSAs. The PacketCable spec defines a scheme for fragmenting data across VSAs in section 13.1.5.2 of their event messaging spec: http://www.packetcable.com/downloads/specs/PKT-SP-EM-I07-030815.pdf RFC 2865 already offers SHOULD advice on the VSA attribute encoding. I think it would be helpful to offer some guidance on long VSA attributes, so we don't end up with a profusion of incompatible techniques like PacketCable's. Greg > -- > 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: Mon, 25 Aug 2003 12:43:37 +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: Strawman RADIUSEXT WG charter - Take Two Date: Mon, 25 Aug 2003 08:42:33 -0400 Message-ID: Thread-Topic: Strawman RADIUSEXT WG charter - Take Two Thread-Index: AcNpkW3qii9fTI9sTdW6/+mMnw+5lQBc1xWg From: "Nelson, David" To: Cc: Glen Zorn writes... =20 > Isn't it just a bit of a contradiction (not to mention a conflict of > interest) for the same person to chair 2 WGs whose purposes are so > diametrically opposed? Correct me if I'm wrong, but I thought that > Diameter was to replace RADIUS as the IETF standard AAA protocol, while > the apparent purpose of this proposed WG is to delay that replacement as > long as possible, if not to kill Diameter altogether. Therefore, I > would suggest that you abandon the dead-end work of the AAA WG > altogether in favor of more fruitful area of RADIUS extensions. I don't know how to judge whether it's a contradiction, but (IMHO) it certainly isn't a conflict of interest. The latter would imply that actions and decisions in one WG would be adversely influenced by the best interests of another. That's not the way in which I view the proposed RADIUSEXT WG. Yes, Diameter is intended to replace RADIUS, much in the same way that same way that IPv6 is intended to replace IPv4. Recently, however, the Internet community has been speaking about IPv4 / IPv6 co-existence more than it is speaking about transition or replacement. I think we can take this approach with RADIUS. RADIUS will likely continue to be used in problem spaces where it is sufficiently useful. When the problem space requires the additional flexibility and features of Diameter, that's what will likely be deployed. The only question that I think needs to be answered here is whether there is a valid need for a limited set of extensions to RADIUS, in the existing protocol framework, that will not substantially duplicate the features of Diameter. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 25 Aug 2003 12:25:34 +0000 Message-ID: From: Avi Lior To: 'Randy Bush' , Avi Lior Cc: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: RE: Extending RADIUS Attribute Space Date: Mon, 25 Aug 2003 08:25:06 -0400 MIME-Version: 1.0 Content-Type: text/plain See inline. > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: August 25, 2003 2:31 AM > To: Avi Lior > Cc: 'Nelson, David'; 'radiusext@ops.ietf.org' > Subject: RE: Extending RADIUS Attribute Space > > > > My point is this, so far we have a request for addressing > an issue for > > allowing an attribute to be larger then that which is allowed by > > RADIUS. Instead of inventing a specific scheme for that I > am proposing > > to reuse a solution that already exists that will address > that problem > > *plus* another one. > > good idea. you might want to look at the aaa diameter work. > let's not reinvent it piece by piece. I am totally familiar with Diameter. Are you suggesting that if I need larger attributes I should use Diameter? If you are then, I will be fine with that. However, Diameter is only requested by 3GPP and new features in 3GPP2. The rest of the world, is using RADIUS and will continue to use RADIUS for a long time to come. I thought that this RADIUS EXT group is forming to help address some of the new needs in RADIUS. So I am trying to solve these types of problems. I am not trying to reinvent Diameter piece by piece. I don't even see how you get to that conclusion from my message. All we wanted to do was: A) As a minimum, create a mechanism to create more RADIUS attribute types in a way that is backwards compatible with existing RADIUS. B) As part of that we could provide a way to increase the message size (someone asked for that). This again can be done easily by borrowing from EAP and PEAP; and C) Optionally address the issue of how to extend a message again using EAP. If these 3 items are reinventing Diameter then perhaps we shouldn't have done Diameter. Avi -- 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, 25 Aug 2003 06:32:06 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 25 Aug 2003 15:31:24 +0900 To: Avi Lior Cc: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: RE: Extending RADIUS Attribute Space Message-Id: > My point is this, so far we have a request for addressing an issue for > allowing an attribute to be larger then that which is allowed by RADIUS. > Instead of inventing a specific scheme for that I am proposing to reuse a > solution that already exists that will address that problem *plus* another > one. good idea. you might want to look at the aaa diameter work. let's not reinvent it piece by piece. randy -- 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, 24 Aug 2003 22:05:28 +0000 Date: Sun, 24 Aug 2003 14:34:17 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Strawman RADIUSEXT WG charter - Take Three Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK. Here's another try... ------------------------------------------------------- RADIUS Extensions Working Group (RADIUSEXT) Last Modified: 2003-08-22 Chair(s): David Nelson Operations and Management Area Director(s): Randy Bush Bert Wijnen Operations and Management Area Advisor: Randy Bush Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe Archive: http://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP Telephony and Local Area Network authentication, authorization and accounting. All extensions produced by this working group are required to demonstrate backward compatibility with the existing RADIUS protocol as well as compatibility with the equivalent capabilities in the Diameter protocol. In order to ensure backward compatibility with RADIUS, the following restrictions are imposed on extensions considered by the RADIUSEXT WG: - No new RADIUS commands will be defined. Documentation of commands currently in use may be considered in the future. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. - No changes will be considered to the RADIUS attribute format. - No new RADIUS attribute data types will be defined. - The RADIUS maximum packet size (4K) will not be increased. - No RADIUS "sub-types" will be defined. - No "attribute grouping" mechanis will be defined. - No new RADIUS security mechanisms will be defined. - All changes MUST be backward compatible with existing RADIUS RFCs. Work Items The immediate goals of the RADIUSEXT working group are to address the following issues: - RADIUS UDP transport profile. The transport behavior of the RADIUS protocol is unspecified in existing RFCs. This has resulted in implementations lacking support for congestion control. This task involves specification of the RADIUS UDP transport mapping, providing support for congestion control and jittering. Failover behavior is not part of this work item. An explicit non-goal of this work item is to bring RADIUS up to the level of reliability achievable in Diameter. - Pre-paid support. Pre-paid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, a specification is required. The implementation of RADIUS prepaid needs to be compatible with existing RADIUS RFCs as well as with Diameter prepaid capabilities. - LAN attributes. A number of additional attributes have been proposed to enable use of RADIUS authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. Goals and Milestones: Apr 04 RADIUS UDP transport profile submitted as a Proposed Standard RFC. Sep 04 RADIUS pre-paid suport submitted as an Informational RFC. Dec 04 RADIUS attributes for LANs submitted as an Informational RFC. Quality Control Plan In order to ensure quality of work: * This WG will not be chartered until sufficient resources can be demonstrated to be available to guarantee a high probability of success. This includes recruitment of a core of editors and reviewers with significant IETF experience and demonstrated time commitment. * All drafts will need to undergo review prior to acceptance as WG work items. The SIRs process will be used, including the potential to disqualify a submission based on the initial review. * All work items will need to pass a "Diameter Compatibility" and "RADIUS backward compatibility" review within 6 months of being accepted as a WG work item. * The WG will utilize an automated issue tracking system (such as Roundup) in order to track ongoing issues. * XML to RFC will be used in production of documents. This enables production of HTML and text files from a single source file as well as automated production of difference files. -- 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, 23 Aug 2003 23:25:30 +0000 Date: Sat, 23 Aug 2003 15:54:35 -0700 (PDT) From: Bernard Aboba To: Glen Zorn cc: radiusext@ops.ietf.org Subject: RE: Strawman RADIUSEXT WG charter - Take Two Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is there evidence that this 'lack' is a fatal flaw? The draft below attempts to make the case for this work item. Could you review it and send your thoughts to the list? http://www.ietf.org/internet-drafts/draft-lior-radius-reliable-accounting-00.txt > I doubt very much that this is possible, given that pre-paid support > would undoubtedly use the capabilities defined (sort of) in RFC 3576 and > magically justified after the fact by RFC 3575 (unless, of course, we're > redefining "compatible" to mean "in direct violation of")... Could you take a look at the draft below and provide us with your opinion of it? http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-01.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: Sat, 23 Aug 2003 17:01:58 +0000 Date: Sat, 23 Aug 2003 09:28:21 -0700 (PDT) From: Bernard Aboba To: Glen Zorn cc: radiusext@ops.ietf.org Subject: RE: Strawman RADIUSEXT WG charter - Take Two Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > - RADIUS UDP transport profile. The transport behavior of the RADIUS > > protocol is unspecified in RFC 2865 and 2866. This has resulted in > > implementations lacking support for congestion control. > > Is there evidence that this 'lack' is a fatal flaw? There are cases where after a power failure or large scale reboot of many NASes, overly aggressive RADIUS clients have swamped the RADIUS server. > > - Pre-paid support. Pre-paid services are contemplated in a number > > of potential applications, including wireless LAN access and IP > > telephony. In order to enable support of pre-paid services in an > > interoperable way, a specification is required. The implementation > > of RADIUS prepaid needs to be compatible with RFC 2865 and 2866, > > I doubt very much that this is possible, given that pre-paid support > would undoubtedly use the capabilities defined (sort of) in RFC 3576 and > magically justified after the fact by RFC 3575 (unless, of course, we're > redefining "compatible" to mean "in direct violation of")... We could change this to "compatible with existing RADIUS RFCs." > > as well as with Diameter prepaid capabilities. > > Who cares? I think that there is a desire to potentially gateway between RADIUS prepaid clients and a Diameter prepaid server, no? -- 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, 23 Aug 2003 16:11:40 +0000 Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: Strawman RADIUSEXT WG charter - Take Two Date: Sat, 23 Aug 2003 09:10:41 -0700 Organization: Cisco Systems Message-ID: <07b701c36991$2bb62e80$50944104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit owner-radiusext@ops.ietf.org writes: > RADIUS Extensions Working Group (RADIUSEXT) > Last Modified: 2003-08-22 > > Chair(s): > Bernard Aboba Isn't it just a bit of a contradiction (not to mention a conflict of interest) for the same person to chair 2 WGs whose purposes are so diametrically opposed? Correct me if I'm wrong, but I thought that Diameter was to replace RADIUS as the IETF standard AAA protocol, while the apparent purpose of this proposed WG is to delay that replacement as long as possible, if not to kill Diameter altogether. Therefore, I would suggest that you abandon the dead-end work of the AAA WG altogether in favor of more fruitful area of RADIUS extensions. > David Nelson > > Operations and Management Area Director(s): > Randy Bush > Bert Wijnen > > Operations and Management Area Advisor: > Randy Bush > > Mailing Lists: > General Discussion: radiusext@ops.ietf.org > To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe > Archive: http://ops.ietf.org/lists/radiusext > > Description of Working Group: > > The RADIUS Extensions Working Group will focus on extensions > to the RADIUS protocol required to enable its use in applications > such as IP Telephony and Local Area Network authentication, > authorization and accounting. All extensions produced by this > working group are required to demonstrate backward compatibility with > the existing RADIUS protocol as well as compatibility with the > equivalent capabilities in the Diameter protocol. > > In order to ensure backward compatibility with RADIUS, the following > restrictions are imposed on extensions considered by the RADIUSEXT > WG: > > - No new RADIUS commands will be defined. Documentation of commands > currently in use may be considered in the future. > - No new RADIUS transports (e.g. TCP, SCTP) will be defined. > - No changes will be considered to the RADIUS attribute format. > - No new RADIUS attribute data types will be defined. > > Work Items > > The immediate goals of the RADIUSEXT working group are to address the > following issues: > > - RADIUS UDP transport profile. The transport behavior of the RADIUS > protocol is unspecified in RFC 2865 and 2866. This has resulted in > implementations lacking support for congestion control. Is there evidence that this 'lack' is a fatal flaw? > This task > involves specification of the RADIUS UDP transport mapping, > providing support for congestion control and jittering. Failover > behavior is not part of this work item. An explicit non-goal of > this work item is to bring RADIUS up to the level of reliability > achievable in Diameter. > > - Pre-paid support. Pre-paid services are contemplated in a number > of potential applications, including wireless LAN access and IP > telephony. In order to enable support of pre-paid services in an > interoperable way, a specification is required. The implementation > of RADIUS prepaid needs to be compatible with RFC 2865 and 2866, I doubt very much that this is possible, given that pre-paid support would undoubtedly use the capabilities defined (sort of) in RFC 3576 and magically justified after the fact by RFC 3575 (unless, of course, we're redefining "compatible" to mean "in direct violation of")... > as well as with Diameter prepaid capabilities. Who cares? > > - LAN attributes. A number of additional attributes have been > proposed to enable use of RADIUS authentication, authorization and > accounting in wired and wireless LANs. Standardization of these > attributes will enable improved interoperability. > > Goals and Milestones: > > Apr 04 RADIUS UDP transport profile submitted as a Proposed Standard > RFC. Sep 04 RADIUS pre-paid suport submitted as an Informational > RFC. Dec 04 RADIUS attributes for LANs submitted as an Informational > RFC. > > Quality Control Plan > > In order to ensure quality of work, all drafts will need to undergo > review prior to acceptance as WG work items. > > The WG will utilize an automated issue tracking system (such as > Roundup) in order to track ongoing issues. > > XML to RFC will be used in production of documents. This enables > production of HTML and text files from a single source file as well > as automated production of difference files. Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire -- 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, 23 Aug 2003 14:28:19 +0000 Date: Sat, 23 Aug 2003 06:57:24 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Strawman RADIUSEXT WG charter - Take Two Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RADIUS Extensions Working Group (RADIUSEXT) Last Modified: 2003-08-22 Chair(s): Bernard Aboba David Nelson Operations and Management Area Director(s): Randy Bush Bert Wijnen Operations and Management Area Advisor: Randy Bush Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe Archive: http://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP Telephony and Local Area Network authentication, authorization and accounting. All extensions produced by this working group are required to demonstrate backward compatibility with the existing RADIUS protocol as well as compatibility with the equivalent capabilities in the Diameter protocol. In order to ensure backward compatibility with RADIUS, the following restrictions are imposed on extensions considered by the RADIUSEXT WG: - No new RADIUS commands will be defined. Documentation of commands currently in use may be considered in the future. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. - No changes will be considered to the RADIUS attribute format. - No new RADIUS attribute data types will be defined. Work Items The immediate goals of the RADIUSEXT working group are to address the following issues: - RADIUS UDP transport profile. The transport behavior of the RADIUS protocol is unspecified in RFC 2865 and 2866. This has resulted in implementations lacking support for congestion control. This task involves specification of the RADIUS UDP transport mapping, providing support for congestion control and jittering. Failover behavior is not part of this work item. An explicit non-goal of this work item is to bring RADIUS up to the level of reliability achievable in Diameter. - Pre-paid support. Pre-paid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, a specification is required. The implementation of RADIUS prepaid needs to be compatible with RFC 2865 and 2866, as well as with Diameter prepaid capabilities. - LAN attributes. A number of additional attributes have been proposed to enable use of RADIUS authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. Goals and Milestones: Apr 04 RADIUS UDP transport profile submitted as a Proposed Standard RFC. Sep 04 RADIUS pre-paid suport submitted as an Informational RFC. Dec 04 RADIUS attributes for LANs submitted as an Informational RFC. Quality Control Plan In order to ensure quality of work, all drafts will need to undergo review prior to acceptance as WG work items. The WG will utilize an automated issue tracking system (such as Roundup) in order to track ongoing issues. XML to RFC will be used in production of documents. This enables production of HTML and text files from a single source file as well as automated production of difference files. -- 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, 23 Aug 2003 12:11:42 +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: Some thoughts Date: Sat, 23 Aug 2003 08:11:14 -0400 Message-ID: Thread-Topic: Some thoughts Thread-Index: AcNo+7XogiS1CyJgR8SeHyeXinAA6wAcroWg From: "Nelson, David" To: "CONGDON,PAUL (HP-Roseville,ex1)" , Paul Congdon writes... > Sorry for joining the conversation late, but was the original commenter > saying that we have all the attributes defined that we need, or just that > the size of the attribute field is large enough? [DBN] I was suggesting that the 8-bit attribute number space would seem to still be sufficient given the scope of proposed work, and that EAP-Message style application level fragmentation and re-assembly seems like it might be sufficient to cover any need for attributes longer than the current maximum attribute length. Or at least I haven't yet seen any compelling counter examples, based on currently deployed or defined usages. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 23 Aug 2003 03:42:36 +0000 Reply-To: From: "Glen Zorn" To: "'Nelson, David'" , Subject: RE: Extending RADIUS Attribute Space Date: Fri, 22 Aug 2003 20:41:11 -0700 Organization: Cisco Systems Message-ID: <071f01c36928$779aae20$50944104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit owner-radiusext@ops.ietf.org writes: > Avi Lior writes... > >> RADIUS does not have a scheme for doing this. > > No, but there are non-standard, or vendor-specific ways to do this, > or so I believe. My suggestion was *IF* RADIUS were to have a > well-defined method (not per-vendor or per-attribute) of performing > application-level fragmentation and reassembly of attributes, would > this not solve the problem without changing the existing attribute > TLV format? > > -- Dave Fragmentation and reassembly of attributes is simple, but the maximum size of a RADIUS packet is small (far smaller than the largest UDP datagram). Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire -- 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, 23 Aug 2003 02:34:50 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Extending RADIUS Attribute Space Date: Fri, 22 Aug 2003 13:19:19 -0400 Message-ID: Thread-Topic: Extending RADIUS Attribute Space Thread-Index: AcNo0K3HS87fAt9yQMKfF7axjlHaAwAAC8FA From: "Nelson, David" To: Avi Lior writes... > RADIUS does not have a scheme for doing this. No, but there are non-standard, or vendor-specific ways to do this, or so I believe. My suggestion was *IF* RADIUS were to have a well-defined method (not per-vendor or per-attribute) of performing application-level fragmentation and reassembly of attributes, would this not solve the problem without changing the existing attribute TLV format? -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 22 Aug 2003 22:19:32 +0000 Message-ID: <499DC368E25AD411B3F100902740AD651C6286D9@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Some thoughts Date: Fri, 22 Aug 2003 18:14:09 -0400 MIME-Version: 1.0 Content-Type: text/plain Sorry for joining the conversation late, but was the original commenter saying that we have all the attributes defined that we need, or just that the size of the attribute field is large enough? I can imagine several 802 specific attributes that are not consistent outside of vendor extensions. It would be good if these were consistently defined (i.e. standardized). Paul > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Friday, August 22, 2003 11:16 AM > To: radiusext@ops.ietf.org > Subject: RE: Some thoughts > > > Bernard Aboba writes.. > > > So far, I'm not clear about the link between "attribute > extension" and > the > > above goals. Currently there are more than enough RADIUS attributes > left > > to handle the needs that have been described so far -- which would > suggest > > that attribute extension is not essential, and therefore is a > candidate > > for being removed from the charter. > > > > Comments? > > Acknowledging the existing RADIUS attributes in the IANA > registry (both approved by standards action and > "grandfathered") it does seem that attribute space > exhaustion, within the scope of currently proposed work, is > not imminent. I would support removing this work from the charter. > > -- Dave > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- 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, 22 Aug 2003 21:32:05 +0000 Date: Fri, 22 Aug 2003 13:46:47 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: RE: Some thoughts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If you look at prepaid for example you will see that that approach taken was > to use subtypes. RADIUS [RFC2865] is explicit about the data types that are allowable. "Sub-types" are not something that can be supported in most RADIUS implementations without code changes. So I'd argue that such an approach is not backward compatible with RADIUS. > One of the reason for doing so was due to the lack of > attributes space. If we were to expand these attributes then we would run > out of space (maybe not within the two features we are considering now but > pretty soon.) Note that using subtypes also increases the size of the > attribute. How many attributes do you need? > Furthermore, you still have a potential issue about the size of the > attributes. > > Nobody addressed the problem I have put forward. How do you map a (3 octet) > length Diameter attribute to a (one Octet) length Radius attribute? You presumably break up the Diameter attribute into multiple RADIUS attributes which cannot be reordered. -- 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, 22 Aug 2003 20:27:59 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: RE: Some thoughts Date: Fri, 22 Aug 2003 16:26:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" So this is a very interesting... If you look at prepaid for example you will see that that approach taken was to use subtypes. One of the reason for doing so was due to the lack of attributes space. If we were to expand these attributes then we would run out of space (maybe not within the two features we are considering now but pretty soon.) Note that using subtypes also increases the size of the attribute. Furthermore, you still have a potential issue about the size of the attributes. Nobody addressed the problem I have put forward. How do you map a (3 octet) length Diameter attribute to a (one Octet) length Radius attribute? > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Friday, August 22, 2003 2:16 PM > To: radiusext@ops.ietf.org > Subject: RE: Some thoughts > > > Bernard Aboba writes.. > > > So far, I'm not clear about the link between "attribute > extension" and > the > > above goals. Currently there are more than enough RADIUS attributes > left > > to handle the needs that have been described so far -- which would > suggest > > that attribute extension is not essential, and therefore is a > candidate > > for being removed from the charter. > > > > Comments? > > Acknowledging the existing RADIUS attributes in the IANA > registry (both approved by standards action and > "grandfathered") it does seem that attribute space > exhaustion, within the scope of currently proposed work, is > not imminent. I would support removing this work from the charter. > > -- Dave > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- 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, 22 Aug 2003 18:33:33 +0000 Date: Fri, 22 Aug 2003 10:18:16 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: RE: Extending RADIUS Attribute Space Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > RADIUS does not have a scheme for doing this. RFC 2869 does describe how EAP-Message attributes are fragmented and reassembled. > So EAP has a mechanism for > dealing with big attributes but it would be wrong to use EAP messages to > implement something like prepaid or any other application that is not an EAP > application. I don't think this is what is being suggested. > I don't think it would be a good idea to create a situation where every > RADIUS application RFC comes up with its own way of dealing with big > attributes. As far as I can tell, the existing RADIUS RFCs are consistent in this respect, no? Can you provide a reference to the specific sections of the documents that are inconsistent? -- 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, 22 Aug 2003 18:21:15 +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: Some thoughts Date: Fri, 22 Aug 2003 14:16:28 -0400 Message-ID: Thread-Topic: Some thoughts Thread-Index: AcNo2JeBWznXvExgTr2Pm4lxoN62MgAAEwfA From: "Nelson, David" To: Bernard Aboba writes.. > So far, I'm not clear about the link between "attribute extension" and the > above goals. Currently there are more than enough RADIUS attributes left > to handle the needs that have been described so far -- which would suggest > that attribute extension is not essential, and therefore is a candidate > for being removed from the charter. >=20 > Comments? Acknowledging the existing RADIUS attributes in the IANA registry (both approved by standards action and "grandfathered") it does seem that attribute space exhaustion, within the scope of currently proposed work, is not imminent. I would support removing this work from the charter. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 22 Aug 2003 18:09:10 +0000 Date: Fri, 22 Aug 2003 10:33:37 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Some thoughts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As has been noted previously, the discusson of potential IETF RADIUS work is focussed on the *minimum* work needed to enable deployed applications such as IP Telephony or (W)LAN access. That implies that if you'd like to suggest a work item, that the tie between this and the above applications needs to be clearly made. For example, the work on RADIUS transport profiles was suggested in order to improve the usability of RADIUS accounting in usage-based billing scenarios, primarily for IP telephony, but also potentially for (W)LAN access. It was also suggested that these services would benefit from prepaid accounting support. Since today various SDOs are already standardizing (W)LAN related attributes it was suggested that better interoperability would be obtained by having an IETF RFC on the subject. So far, I'm not clear about the link between "attribute extension" and the above goals. Currently there are more than enough RADIUS attributes left to handle the needs that have been described so far -- which would suggest that attribute extension is not essential, and therefore is a candidate for being removed from the charter. Comments? -- 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, 22 Aug 2003 17:42:40 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: RE: Extending RADIUS Attribute Space Date: Fri, 22 Aug 2003 13:13:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Friday, August 22, 2003 12:44 PM > To: radiusext@ops.ietf.org > Subject: RE: Extending RADIUS Attribute Space > > > > Avi Lior writes... > > > If we want to interoperate with Diameter for example, how would we > address > > the fact that the length of a diameter attribute is 3 octets? > > > > Is this enough of a justification to allow RADIUS Extended > attributes > to > > be longer than 1 octet in length? > > Well, I don't know. I think it once again depends on the > actual attributes and applications under consideration. If > RADIUS has a well-defined mechanism for achieving > application-level fragmentation and re-assembly of "oversize" > attributes, why isn't it sufficient for a RADIUS-Diameter > gateway function to utilize that fragmentation and > re-assembly when translating between RADIUS and Diameter? RADIUS does not have a scheme for doing this. So EAP has a mechanism for dealing with big attributes but it would be wrong to use EAP messages to implement something like prepaid or any other application that is not an EAP application. I don't think it would be a good idea to create a situation where every RADIUS application RFC comes up with its own way of dealing with big attributes. > Making the translation simple and straightforward is > important, but I think that requirement can be met with > fragmentation and re-assembly. I don't understand what you mean here. If you meant "requirment can be met with frametation and re-assembly that exists in RADIUS" then I have answered above. >Execution efficiency is another matter, of course... > > -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 22 Aug 2003 16:46:33 +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: Extending RADIUS Attribute Space Date: Fri, 22 Aug 2003 12:44:05 -0400 Message-ID: Thread-Topic: Extending RADIUS Attribute Space Thread-Index: AcNowqHr/CmOe3ZHToeCMU4rBBwHMAACTG+Q From: "Nelson, David" To: Avi Lior writes... > If we want to interoperate with Diameter for example, how would we address > the fact that the length of a diameter attribute is 3 octets? >=20 > Is this enough of a justification to allow RADIUS Extended attributes to > be longer than 1 octet in length? Well, I don't know. I think it once again depends on the actual attributes and applications under consideration. If RADIUS has a well-defined mechanism for achieving application-level fragmentation and re-assembly of "oversize" attributes, why isn't it sufficient for a RADIUS-Diameter gateway function to utilize that fragmentation and re-assembly when translating between RADIUS and Diameter? Making the translation simple and straightforward is important, but I think that requirement can be met with fragmentation and re-assembly. Execution efficiency is another matter, of course... -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 22 Aug 2003 15:31:38 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" Cc: Avi Lior Subject: RE: Extending RADIUS Attribute Space Date: Fri, 22 Aug 2003 11:29:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" If we want to interoperate with Diameter for example, how would we address the fact that the length of a diameter attribute is 3 octets? Is this enough of a justification to allow RADIUS Extended attributes to be longer than 1 octet in length? > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, August 22, 2003 1:34 AM > To: Jari Arkko > Cc: Avi Lior; 'Nelson, David'; 'radiusext@ops.ietf.org' > Subject: Re: Extending RADIUS Attribute Space > > > > As well, we have been involved in a case where someone > wanted to do a > > packet audit against a wireless session where a counter is reported > > against a range of IP addresses. These counters and Ipaddress are > > stored in a container attribute. This container attribute > would span > > a RADIUS accounting packet. > > Note: The issue was dropped for other reasons. > > This kind of thing is already covered in the IPFIX 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: Fri, 22 Aug 2003 06:19:48 +0000 Date: Thu, 21 Aug 2003 22:33:47 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Avi Lior , "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: Re: Extending RADIUS Attribute Space Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > As well, we have been involved in a case where someone wanted to do a packet > audit against a wireless session where a counter is reported against a range > of IP addresses. These counters and Ipaddress are stored in a container > attribute. This container attribute would span a RADIUS accounting packet. > Note: The issue was dropped for other reasons. This kind of thing is already covered in the IPFIX 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: Fri, 22 Aug 2003 06:14:46 +0000 Date: Thu, 21 Aug 2003 22:30:17 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Avi Lior , "'Greg Weber'" , "'radiusext@ops.ietf.org'" Subject: Re: Extending RADIUS Attribute Space Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I agree that attribute number space needs to be expanded, but > I wonder how useful it is to do a redesign of the packet and > attribute formats to cater for larger lengths. Seems like its > a pretty big change, and if you need that, you'd have to > worry about full transport reliability as well. If you > willing to do such a big change, maybe its time to move > to another protocol... I'd agree. The goal is to do the absolute minimum work necessary to enable IP telephony and WLAN applications. It's even somewhat of a stretch to argue that attribute extension is required to accomplish that, since there are more than enough attributes still to be allocated to accomodate any that would be necessary for the work that is described. -- 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, 22 Aug 2003 06:12:46 +0000 Date: Thu, 21 Aug 2003 22:41:31 -0700 (PDT) From: Bernard Aboba To: Greg Weber cc: radiusext@ops.ietf.org Subject: Re: Strawman RADIUSEXT WG charter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Would this last sentence preclude future work items to > specify the behavior of packet types reserved by RFC 3575, but > not defined by RFC 2882? In particular, I think producing > a specification for packet type codes 33 & 34 (Event-Request/ > Response) will be useful in a number of forums and can be > done in a Diameter compatible way. The focus is on extensions that are already deployed or providing support for extensions that are already deployed. For example, there is work that SIPPING WG would like to do in order to standardize SIP use of RADIUS accounting, and they have requested work on RADIUS prepaid and RADIUS transport profiles to support that. It has been claimed that RADIUS prepaid work would benefit from an extension of the attribute space. And there are WLAN extensions that have already been defined in WFA, IEEE 802, vendor-specific attributes, etc. So my question is: What do packet type codes 33 and 34 do? Are these extensions used today? Are they useful for newer applications as well as legacy ones? > Will this work item include addressing the attribute size > limitation in the extended space? A number of methods > for fragmenting large values across attributes have popped > up, e.g. as in the PacketCable 1.0 spec. It would be nice > to have a standard way of doing this. If this represents something that is already deployed, then it might be appropriate. Can you describe the issues that came up in the PacketCable 1.0 spec? -- 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, 21 Aug 2003 22:41:51 +0000 Date: Thu, 21 Aug 2003 18:38:20 -0400 From: Barney Wolff To: Jari Arkko Cc: Avi Lior , "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: Re: Extending RADIUS Attribute Space Message-ID: <20030821223820.GA12376@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i On Fri, Aug 22, 2003 at 12:33:06AM +0300, Jari Arkko wrote: > > Yes, a per-destination accounting record would be quite interesting. > The transport issues of this are quite interesting, too... Especially with blaster pinging the whole IP space. May I suggest that we not add opportunities to DoS ourselves with our extensions? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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, 21 Aug 2003 22:04:12 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: 'Greg Weber' , "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter Date: Thu, 21 Aug 2003 18:03:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, August 21, 2003 4:50 PM > To: Avi Lior > Cc: 'Greg Weber'; 'radiusext@ops.ietf.org' > Subject: RE: Strawman RADIUSEXT WG charter > > > > Hi Greg, > > I am readying an individual submission for AVP extension > which could > > address your length extension issue. Take a look at > > > http://www.lior.org/standards/ietf/radiusext/d> raft-lior-radius-attribu > > te-typ > > e-extension-00-1.rtf > > > > In my proposal if we make the extended attribute length 2 > octets then > > if Extended Attribute is longer then its container (the > specail RADIUS > > VSAs) then the attribute would span multiple consecutive VSAs. > > > > Will that work for you? I would apperciate any comments on this > > document. > > > > I will be sumitting it shortly. > > The existing RADIUS VSA mechanism enables merging of > attributes without an additional length field, so it's not > clear to me why this would be necessary. I don't follow your point. Can you explain? > Also, Diameter already has a 32-bit attribute field so > allowing that many RADIUS attributes would seem to create > Diameter incompatibilities -- how would you map RADIUS > attributes to Diameter? We are not introducing 32bit RADIUS attribute types. We are introducing a mechanism for encoding 32bit RADIUS attributes within a VSA not at a top level. Therefore there should not be any Diameter incompatiblity. Diameter will simply encode these RADIUS attributes the way it will encode any VSA. -- 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, 21 Aug 2003 21:36:37 +0000 Message-ID: <3F453A92.7090906@piuha.net> Date: Fri, 22 Aug 2003 00:33:06 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 MIME-Version: 1.0 To: Avi Lior Cc: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: Re: Extending RADIUS Attribute Space Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi Lior wrote: > I can't give you an example because its not possible to do this today using > RADIUS attribute. > > However, EAP/TLS and EAP/PEAP, both are sending attributes that transcend > the boundary of a RADIUS packet. So its not hard to imagine the need for > this. I'm not sure I follow. EAP TLS supports fragmentation, so it will really send its messages piece-by-piece to the peer. In this case the limiting factor is not typically RADIUS, its the link layer which might not support very long packets. And EAP layer does not support fragmentation in a general sense, so the methods are responsible for this. But it has been discussed that if you use EAP TLS in a context where EAP is run over IP, then IP could take care of fragmentation. Thus there could be large packets. For instance when running EAP TLS under IKEv2 (a weird combination by anyone's standards), the IKEv2 GW might be talking over RADIUS to a AAA server, and require 10K messages, because the GW indicated to AAA server EAP module that 10K was OK. However, even in this case the AAA server EAP module should be able to figure out that 10K is not OK, given that it knows it is running over RADIUS. So I'm not certain if EAP TLS support is an argument. But there might be other cases. > As well, we have been involved in a case where someone wanted to do a packet > audit against a wireless session where a counter is reported against a range > of IP addresses. These counters and Ipaddress are stored in a container > attribute. This container attribute would span a RADIUS accounting packet. > Note: The issue was dropped for other reasons. Yes, a per-destination accounting record would be quite interesting. The transport issues of this are quite interesting, too... --Jari -- 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, 21 Aug 2003 21:34:57 +0000 Date: Thu, 21 Aug 2003 13:49:42 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'Greg Weber'" , "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hi Greg, > I am readying an individual submission for AVP extension which could address > your length extension issue. Take a look at > http://www.lior.org/standards/ietf/radiusext/draft-lior-radius-attribute-typ > e-extension-00-1.rtf > > In my proposal if we make the extended attribute length 2 octets then if > Extended Attribute is longer then its container (the specail RADIUS VSAs) > then the attribute would span multiple consecutive VSAs. > > Will that work for you? I would apperciate any comments on this document. > > I will be sumitting it shortly. The existing RADIUS VSA mechanism enables merging of attributes without an additional length field, so it's not clear to me why this would be necessary. Also, Diameter already has a 32-bit attribute field so allowing that many RADIUS attributes would seem to create Diameter incompatibilities -- how would you map RADIUS attributes to Diameter? -- 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, 21 Aug 2003 19:40:47 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" Cc: "'radiusext@ops.ietf.org'" Subject: RE: Extending RADIUS Attribute Space Date: Thu, 21 Aug 2003 15:40:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I can't give you an example because its not possible to do this today using RADIUS attribute. However, EAP/TLS and EAP/PEAP, both are sending attributes that transcend the boundary of a RADIUS packet. So its not hard to imagine the need for this. As well, we have been involved in a case where someone wanted to do a packet audit against a wireless session where a counter is reported against a range of IP addresses. These counters and Ipaddress are stored in a container attribute. This container attribute would span a RADIUS accounting packet. Note: The issue was dropped for other reasons. My point is this, so far we have a request for addressing an issue for allowing an attribute to be larger then that which is allowed by RADIUS. Instead of inventing a specific scheme for that I am proposing to reuse a solution that already exists that will address that problem *plus* another one. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, August 21, 2003 2:57 PM > Cc: radiusext@ops.ietf.org > Subject: RE: Extending RADIUS Attribute Space > > > Avi Lior writes... > > > Allowing for larger attributes and allowing for attributes to span > packets > > is not a big change. It is in fact something that is done today > already. > > Do you have an example of an attribute that would need to be > so long as to span two or more packets (UDP datagrams)? > > Regards, > > Dave > > David B. Nelson > Wireless & AAA Architect, Office of the CTO > Enterasys Networks, Inc. > 50 Minuteman Road > Andover, MA 01810-1008 > Phone: (978) 684-1330 > E-mail: dnelson@enterasys.com > > > -- > 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, 21 Aug 2003 18:58:35 +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: Extending RADIUS Attribute Space Date: Thu, 21 Aug 2003 14:56:49 -0400 Message-ID: Thread-Topic: Extending RADIUS Attribute Space Thread-Index: AcNoD0+fhhF7y9USRiKJYdagACp60AABjLCQ From: "Nelson, David" Cc: Avi Lior writes... > Allowing for larger attributes and allowing for attributes to span packets > is not a big change. It is in fact something that is done today already. Do you have an example of an attribute that would need to be so long as to span two or more packets (UDP datagrams)? Regards, =20 Dave =20 David B. Nelson Wireless & AAA Architect, Office of the CTO Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330 =20 E-mail: dnelson@enterasys.com -- 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, 21 Aug 2003 18:08:32 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Avi Lior Cc: 'Greg Weber' , "'aboba@internaut.com'" , "'radiusext@ops.ietf.org'" Subject: RE: Extending RADIUS Attribute Space Date: Thu, 21 Aug 2003 14:08:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, August 21, 2003 1:26 PM > To: Avi Lior > Cc: 'Greg Weber'; 'aboba@internaut.com'; 'radiusext@ops.ietf.org' > Subject: Re: Extending RADIUS Attribute Space > > > > I agree that attribute number space needs to be expanded, but > I wonder how useful it is to do a redesign of the packet and > attribute formats to cater for larger lengths. Seems like its > a pretty big change, and if you need that, you'd have to > worry about full transport reliability as well. If you > willing to do such a big change, maybe its time to move to > another protocol... > > --Jari Allowing for larger attributes and allowing for attributes to span packets is not a big change. It is in fact something that is done today already. The point of this whole exercise is not to force people to go to another protocol!!! People who want another protocol can choose to go to that other protocol. It would be great to move to another protocol but there are huge cost and business issues to consider as well. I don't see the nexus between having larger lengths and full transport reliability. > Avi Lior wrote: > > Further to my last email: > > > > The solution in the last email addresses extending an > attribute beyong > > the 255 limit. To fully address the requirement we should really > > address how to extend the attributes beyong a single RADIUS packet. > > > > If there was interest in that, I would propose to use the > more robust > > scheme that is used in PEAP. > > > > Comments? > > > > > >>-----Original Message----- > >>From: Greg Weber [mailto:gdweber@cisco.com] > >>Sent: Wednesday, August 20, 2003 9:59 AM > >>To: aboba@internaut.com > >>Cc: radiusext@ops.ietf.org > >>Subject: Re: Strawman RADIUSEXT WG charter > >> > >> > >> > >>>Here is a proposed strawman charter for a RADIUSEXT WG. Comments > >>>welcome. > >> > >>Some comments and questions inline. > >> > >> > >>> > >>------------------------------------------------------------ > ---------- > >> > >>>---- > >>> > >>>RADIUS Extensions Working Group (RADIUSEXT) > >>>Last Modified: 2003-08-19 > >>> > >>>Chair(s): > >>>Bernard Aboba > >>>David Nelson > >>> > >>>Operations and Management Area Director(s): > >>>Randy Bush > >>>Bert Wijnen > >>> > >>>Operations and Management Area Advisor: > >>>Randy Bush > >>> > >>>Mailing Lists: > >>>General Discussion: radiusext@ops.ietf.org > >>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe > >>>Archive: http://ops.ietf.org/lists/radiusext > >>> > >>>Description of Working Group: > >>> > >>>The RADIUS Extensions Working Group will focus on extensions to the > >>>RADIUS protocol required to enable its use in applications > >> > >>such as IP > >> > >>>Telephony and Local Area Network authentication, authorization and > >>>accounting. All extensions produced by this working group are > >>>required to demonstrate backward compatibility with the existing > >>>RADIUS protocol as well as compatibility with the equivalent > >>>capabilities in the Diameter protocol. No new RADIUS > >> > >>commands will be > >> > >>>defined. > >> > >>Would this last sentence preclude future work items to > >>specify the behavior of packet types reserved by RFC 3575, > >>but not defined by RFC 2882? In particular, I think producing > >>a specification for packet type codes 33 & 34 (Event-Request/ > >>Response) will be useful in a number of forums and can be > >>done in a Diameter compatible way. > >> > >> > >>>The immediate goals of the RADIUSEXT working group are to > >> > >>address the > >> > >>>following issues: > >>> > >>>- Attribute space extension. The RADIUS protocol, defined in > >>> RFC 2865, has an eight (8) bit attribute space, a good portion > >>> of which has already been allocated or is in use. In order to > >>> address attribute exhaustion, an extended attribute space will be > >>> defined. > >> > >>Will this work item include addressing the attribute size > >>limitation in the extended space? A number of methods > >>for fragmenting large values across attributes have popped > >>up, e.g. as in the PacketCable 1.0 spec. It would be nice > >>to have a standard way of doing this. > >> > >>Greg > >> > >> > >>>- RADIUS UDP transport profile. The transport behavior of > >> > >>the RADIUS > >> > >>> protocol is unspecified in RFC 2865 and 2866. This has > >> > >>resulted in > >> > >>> implementations lacking support for congestion control. > This task > >>> involves specification of the RADIUS UDP transport mapping, > >>> providing support for congestion control and jittering. > Failover > >>> behavior is not part of this work item, although it may be > >>> considered in the future. An explicit non-goal of this > work item > >>> is to bring RADIUS up to the level of reliability achievable in > >>> Diameter. > >>> > >>>- Pre-paid support. Pre-paid services are contemplated in a number > >>> of potential applications, including wireless LAN access and IP > >>> telephony. In order to enable support of pre-paid services in an > >>> interoperable way, a specification is required. The > >> > >>implementation of > >> > >>> RADIUS prepaid needs to be compatible with RFC 2865 and > 2866, as > >>> well as with Diameter prepaid capabilities. > >>> > >>>- LAN attributes. A number of additional attributes have been > >>> proposed to enable use of RADIUS authentication, > authorization and > >>> accounting in wired and wireless LANs. Standardization of these > >>> attributes will enable improved interoperability. > >>> > >>>Goals and Milestones: > >>> > >>>Apr 04 RADIUS attribute space extension submitted as a Proposed > >>>Standard RFC. Apr 04 RADIUS UDP transport profile submitted as a > >>>Proposed Standard RFC. Sep 04 RADIUS pre-paid suport > >> > >>submitted as an > >> > >>>Informational RFC. Dec 04 RADIUS attributes for LANs > >> > >>submitted as an > >> > >>>Informational RFC. > >>> > >>>-- > >>>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: > > > > > > -- 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, 21 Aug 2003 17:29:29 +0000 Message-ID: <3F4500C1.7080008@piuha.net> Date: Thu, 21 Aug 2003 20:26:25 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 MIME-Version: 1.0 To: Avi Lior Cc: 'Greg Weber' , "'aboba@internaut.com'" , "'radiusext@ops.ietf.org'" Subject: Re: Extending RADIUS Attribute Space Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree that attribute number space needs to be expanded, but I wonder how useful it is to do a redesign of the packet and attribute formats to cater for larger lengths. Seems like its a pretty big change, and if you need that, you'd have to worry about full transport reliability as well. If you willing to do such a big change, maybe its time to move to another protocol... --Jari Avi Lior wrote: > Further to my last email: > > The solution in the last email addresses extending an attribute beyong the > 255 limit. To fully address the requirement we should really address how to > extend the attributes beyong a single RADIUS packet. > > If there was interest in that, I would propose to use the more robust scheme > that is used in PEAP. > > Comments? > > >>-----Original Message----- >>From: Greg Weber [mailto:gdweber@cisco.com] >>Sent: Wednesday, August 20, 2003 9:59 AM >>To: aboba@internaut.com >>Cc: radiusext@ops.ietf.org >>Subject: Re: Strawman RADIUSEXT WG charter >> >> >> >>>Here is a proposed strawman charter for a RADIUSEXT WG. Comments >>>welcome. >> >>Some comments and questions inline. >> >> >>> >>---------------------------------------------------------------------- >> >>>---- >>> >>>RADIUS Extensions Working Group (RADIUSEXT) >>>Last Modified: 2003-08-19 >>> >>>Chair(s): >>>Bernard Aboba >>>David Nelson >>> >>>Operations and Management Area Director(s): >>>Randy Bush >>>Bert Wijnen >>> >>>Operations and Management Area Advisor: >>>Randy Bush >>> >>>Mailing Lists: >>>General Discussion: radiusext@ops.ietf.org >>>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe >>>Archive: http://ops.ietf.org/lists/radiusext >>> >>>Description of Working Group: >>> >>>The RADIUS Extensions Working Group will focus on extensions to the >>>RADIUS protocol required to enable its use in applications >> >>such as IP >> >>>Telephony and Local Area Network authentication, authorization and >>>accounting. All extensions produced by this working group are >>>required to demonstrate backward compatibility with the existing >>>RADIUS protocol as well as compatibility with the equivalent >>>capabilities in the Diameter protocol. No new RADIUS >> >>commands will be >> >>>defined. >> >>Would this last sentence preclude future work items to >>specify the behavior of packet types reserved by RFC 3575, >>but not defined by RFC 2882? In particular, I think producing >>a specification for packet type codes 33 & 34 (Event-Request/ >>Response) will be useful in a number of forums and can be >>done in a Diameter compatible way. >> >> >>>The immediate goals of the RADIUSEXT working group are to >> >>address the >> >>>following issues: >>> >>>- Attribute space extension. The RADIUS protocol, defined in >>> RFC 2865, has an eight (8) bit attribute space, a good portion >>> of which has already been allocated or is in use. In order to >>> address attribute exhaustion, an extended attribute space will be >>> defined. >> >>Will this work item include addressing the attribute size >>limitation in the extended space? A number of methods >>for fragmenting large values across attributes have popped >>up, e.g. as in the PacketCable 1.0 spec. It would be nice >>to have a standard way of doing this. >> >>Greg >> >> >>>- RADIUS UDP transport profile. The transport behavior of >> >>the RADIUS >> >>> protocol is unspecified in RFC 2865 and 2866. This has >> >>resulted in >> >>> implementations lacking support for congestion control. This task >>> involves specification of the RADIUS UDP transport mapping, >>> providing support for congestion control and jittering. Failover >>> behavior is not part of this work item, although it may be >>> considered in the future. An explicit non-goal of this work item >>> is to bring RADIUS up to the level of reliability achievable in >>> Diameter. >>> >>>- Pre-paid support. Pre-paid services are contemplated in a number >>> of potential applications, including wireless LAN access and IP >>> telephony. In order to enable support of pre-paid services in an >>> interoperable way, a specification is required. The >> >>implementation of >> >>> RADIUS prepaid needs to be compatible with RFC 2865 and 2866, >>> as well as with Diameter prepaid capabilities. >>> >>>- LAN attributes. A number of additional attributes have been >>> proposed to enable use of RADIUS authentication, authorization and >>> accounting in wired and wireless LANs. Standardization of these >>> attributes will enable improved interoperability. >>> >>>Goals and Milestones: >>> >>>Apr 04 RADIUS attribute space extension submitted as a Proposed >>>Standard RFC. Apr 04 RADIUS UDP transport profile submitted as a >>>Proposed Standard RFC. Sep 04 RADIUS pre-paid suport >> >>submitted as an >> >>>Informational RFC. Dec 04 RADIUS attributes for LANs >> >>submitted as an >> >>>Informational RFC. >>> >>>-- >>>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: > > -- 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, 21 Aug 2003 15:02:13 +0000 Message-ID: From: Avi Lior To: 'Greg Weber' , "'aboba@internaut.com'" Cc: "'radiusext@ops.ietf.org'" Subject: Extending RADIUS Attribute Space Date: Thu, 21 Aug 2003 11:01:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Further to my last email: The solution in the last email addresses extending an attribute beyong the 255 limit. To fully address the requirement we should really address how to extend the attributes beyong a single RADIUS packet. If there was interest in that, I would propose to use the more robust scheme that is used in PEAP. Comments? > -----Original Message----- > From: Greg Weber [mailto:gdweber@cisco.com] > Sent: Wednesday, August 20, 2003 9:59 AM > To: aboba@internaut.com > Cc: radiusext@ops.ietf.org > Subject: Re: Strawman RADIUSEXT WG charter > > > > > > Here is a proposed strawman charter for a RADIUSEXT WG. Comments > > welcome. > > Some comments and questions inline. > > > > > > ---------------------------------------------------------------------- > > ---- > > > > RADIUS Extensions Working Group (RADIUSEXT) > > Last Modified: 2003-08-19 > > > > Chair(s): > > Bernard Aboba > > David Nelson > > > > Operations and Management Area Director(s): > > Randy Bush > > Bert Wijnen > > > > Operations and Management Area Advisor: > > Randy Bush > > > > Mailing Lists: > > General Discussion: radiusext@ops.ietf.org > > To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe > > Archive: http://ops.ietf.org/lists/radiusext > > > > Description of Working Group: > > > > The RADIUS Extensions Working Group will focus on extensions to the > > RADIUS protocol required to enable its use in applications > such as IP > > Telephony and Local Area Network authentication, authorization and > > accounting. All extensions produced by this working group are > > required to demonstrate backward compatibility with the existing > > RADIUS protocol as well as compatibility with the equivalent > > capabilities in the Diameter protocol. No new RADIUS > commands will be > > defined. > > Would this last sentence preclude future work items to > specify the behavior of packet types reserved by RFC 3575, > but not defined by RFC 2882? In particular, I think producing > a specification for packet type codes 33 & 34 (Event-Request/ > Response) will be useful in a number of forums and can be > done in a Diameter compatible way. > > > The immediate goals of the RADIUSEXT working group are to > address the > > following issues: > > > > - Attribute space extension. The RADIUS protocol, defined in > > RFC 2865, has an eight (8) bit attribute space, a good portion > > of which has already been allocated or is in use. In order to > > address attribute exhaustion, an extended attribute space will be > > defined. > > Will this work item include addressing the attribute size > limitation in the extended space? A number of methods > for fragmenting large values across attributes have popped > up, e.g. as in the PacketCable 1.0 spec. It would be nice > to have a standard way of doing this. > > Greg > > > > > - RADIUS UDP transport profile. The transport behavior of > the RADIUS > > protocol is unspecified in RFC 2865 and 2866. This has > resulted in > > implementations lacking support for congestion control. This task > > involves specification of the RADIUS UDP transport mapping, > > providing support for congestion control and jittering. Failover > > behavior is not part of this work item, although it may be > > considered in the future. An explicit non-goal of this work item > > is to bring RADIUS up to the level of reliability achievable in > > Diameter. > > > > - Pre-paid support. Pre-paid services are contemplated in a number > > of potential applications, including wireless LAN access and IP > > telephony. In order to enable support of pre-paid services in an > > interoperable way, a specification is required. The > implementation of > > RADIUS prepaid needs to be compatible with RFC 2865 and 2866, > > as well as with Diameter prepaid capabilities. > > > > - LAN attributes. A number of additional attributes have been > > proposed to enable use of RADIUS authentication, authorization and > > accounting in wired and wireless LANs. Standardization of these > > attributes will enable improved interoperability. > > > > Goals and Milestones: > > > > Apr 04 RADIUS attribute space extension submitted as a Proposed > > Standard RFC. Apr 04 RADIUS UDP transport profile submitted as a > > Proposed Standard RFC. Sep 04 RADIUS pre-paid suport > submitted as an > > Informational RFC. Dec 04 RADIUS attributes for LANs > submitted as an > > Informational RFC. > > > > -- > > to unsubscribe send a message to > radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 21 Aug 2003 14:22:09 +0000 Message-ID: From: Avi Lior To: 'Greg Weber' , "'aboba@internaut.com'" Cc: "'radiusext@ops.ietf.org'" Subject: RE: Strawman RADIUSEXT WG charter Date: Thu, 21 Aug 2003 10:20:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Greg, I am readying an individual submission for AVP extension which could address your length extension issue. Take a look at http://www.lior.org/standards/ietf/radiusext/draft-lior-radius-attribute-typ e-extension-00-1.rtf In my proposal if we make the extended attribute length 2 octets then if Extended Attribute is longer then its container (the specail RADIUS VSAs) then the attribute would span multiple consecutive VSAs. Will that work for you? I would apperciate any comments on this document. I will be sumitting it shortly. > -----Original Message----- > From: Greg Weber [mailto:gdweber@cisco.com] > Sent: Wednesday, August 20, 2003 9:59 AM > To: aboba@internaut.com > Cc: radiusext@ops.ietf.org > Subject: Re: Strawman RADIUSEXT WG charter > > > > - Attribute space extension. The RADIUS protocol, defined in > > RFC 2865, has an eight (8) bit attribute space, a good portion > > of which has already been allocated or is in use. In order to > > address attribute exhaustion, an extended attribute space will be > > defined. > > Will this work item include addressing the attribute size > limitation in the extended space? A number of methods > for fragmenting large values across attributes have popped > up, e.g. as in the PacketCable 1.0 spec. It would be nice > to have a standard way of doing this. > > Greg epaid capabilities. -- 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, 20 Aug 2003 13:59:19 +0000 From: Greg Weber Message-Id: <200308201358.JAA05146@cisco.com> Subject: Re: Strawman RADIUSEXT WG charter To: aboba@internaut.com (Bernard Aboba) Date: Wed, 20 Aug 2003 09:58:53 -0400 (EDT) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Here is a proposed strawman charter for a RADIUSEXT WG. Comments welcome. Some comments and questions inline. > > -------------------------------------------------------------------------- > > RADIUS Extensions Working Group (RADIUSEXT) > Last Modified: 2003-08-19 > > Chair(s): > Bernard Aboba > David Nelson > > Operations and Management Area Director(s): > Randy Bush > Bert Wijnen > > Operations and Management Area Advisor: > Randy Bush > > Mailing Lists: > General Discussion: radiusext@ops.ietf.org > To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe > Archive: http://ops.ietf.org/lists/radiusext > > Description of Working Group: > > The RADIUS Extensions Working Group will focus on extensions > to the RADIUS protocol required to enable its use in applications > such as IP Telephony and Local Area Network authentication, > authorization and accounting. All extensions produced by this > working group are required to demonstrate backward compatibility with > the existing RADIUS protocol as well as compatibility with the > equivalent capabilities in the Diameter protocol. No new RADIUS commands > will be defined. Would this last sentence preclude future work items to specify the behavior of packet types reserved by RFC 3575, but not defined by RFC 2882? In particular, I think producing a specification for packet type codes 33 & 34 (Event-Request/ Response) will be useful in a number of forums and can be done in a Diameter compatible way. > The immediate goals of the RADIUSEXT working group are to address the > following issues: > > - Attribute space extension. The RADIUS protocol, defined in > RFC 2865, has an eight (8) bit attribute space, a good portion > of which has already been allocated or is in use. In order to > address attribute exhaustion, an extended attribute space will be > defined. Will this work item include addressing the attribute size limitation in the extended space? A number of methods for fragmenting large values across attributes have popped up, e.g. as in the PacketCable 1.0 spec. It would be nice to have a standard way of doing this. Greg > > - RADIUS UDP transport profile. The transport behavior of the RADIUS > protocol is unspecified in RFC 2865 and 2866. This has resulted in > implementations lacking support for congestion control. This task > involves specification of the RADIUS UDP transport mapping, > providing support for congestion control and jittering. Failover > behavior is not part of this work item, although it may be > considered in the future. An explicit non-goal of this work item > is to bring RADIUS up to the level of reliability achievable in > Diameter. > > - Pre-paid support. Pre-paid services are contemplated in a number > of potential applications, including wireless LAN access and IP > telephony. In order to enable support of pre-paid services in an > interoperable way, a specification is required. The implementation of > RADIUS prepaid needs to be compatible with RFC 2865 and 2866, > as well as with Diameter prepaid capabilities. > > - LAN attributes. A number of additional attributes have been > proposed to enable use of RADIUS authentication, authorization and > accounting in wired and wireless LANs. Standardization of these > attributes will enable improved interoperability. > > Goals and Milestones: > > Apr 04 RADIUS attribute space extension submitted as a Proposed Standard RFC. > Apr 04 RADIUS UDP transport profile submitted as a Proposed Standard RFC. > Sep 04 RADIUS pre-paid suport submitted as an Informational RFC. > Dec 04 RADIUS attributes for LANs submitted as an Informational RFC. > > -- > 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, 19 Aug 2003 18:57:02 +0000 Message-ID: <3F42724B.5040301@piuha.net> Date: Tue, 19 Aug 2003 21:54:03 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Strawman RADIUSEXT WG charter Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Looks good to me. A few nits and questions inline: > RADIUS Extensions Working Group (RADIUSEXT) > Last Modified: 2003-08-19 > > Chair(s): > Bernard Aboba > David Nelson > > Operations and Management Area Director(s): > Randy Bush > Bert Wijnen > > Operations and Management Area Advisor: > Randy Bush > > Mailing Lists: > General Discussion: radiusext@ops.ietf.org > To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe > Archive: http://ops.ietf.org/lists/radiusext > > Description of Working Group: > > The RADIUS Extensions Working Group will focus on extensions > to the RADIUS protocol required to enable its use in applications > such as IP Telephony and Local Area Network authentication, Maybe explicitly say somewhere that actual attrs for IP telephony are done elsewhere, even if the attr space extension and other features provided by this WG are used at the bottom? > authorization and accounting. All extensions produced by this > working group are required to demonstrate backward compatibility with > the existing RADIUS protocol as well as compatibility with the > equivalent capabilities in the Diameter protocol. No new RADIUS commands > will be defined. > > The immediate goals of the RADIUSEXT working group are to address the > following issues: > > - Attribute space extension. The RADIUS protocol, defined in > RFC 2865, has an eight (8) bit attribute space, a good portion > of which has already been allocated or is in use. In order to > address attribute exhaustion, an extended attribute space will be > defined. > > - RADIUS UDP transport profile. The transport behavior of the RADIUS > protocol is unspecified in RFC 2865 and 2866. This has resulted in > implementations lacking support for congestion control. This task > involves specification of the RADIUS UDP transport mapping, > providing support for congestion control and jittering. Failover > behavior is not part of this work item, although it may be > considered in the future. An explicit non-goal of this work item > is to bring RADIUS up to the level of reliability achievable in > Diameter. > > - Pre-paid support. Pre-paid services are contemplated in a number > of potential applications, including wireless LAN access and IP > telephony. In order to enable support of pre-paid services in an > interoperable way, a specification is required. The implementation of > RADIUS prepaid needs to be compatible with RFC 2865 and 2866, > as well as with Diameter prepaid capabilities. > > - LAN attributes. A number of additional attributes have been > proposed to enable use of RADIUS authentication, authorization and > accounting in wired and wireless LANs. Standardization of these > attributes will enable improved interoperability. > > Goals and Milestones: > > Apr 04 RADIUS attribute space extension submitted as a Proposed Standard RFC. > Apr 04 RADIUS UDP transport profile submitted as a Proposed Standard RFC. > Sep 04 RADIUS pre-paid suport submitted as an Informational RFC. s/suport/support/ > Dec 04 RADIUS attributes for LANs submitted as an Informational RFC. Is there a specific target group for this item? 802.11? What is their deadline, is Dec 04 OK for that? Or are there multiple groups? If yes, do their ideas about the attributes agree? --Jari -- 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, 19 Aug 2003 15:17:09 +0000 Date: Tue, 19 Aug 2003 07:46:10 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Strawman RADIUSEXT WG charter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a proposed strawman charter for a RADIUSEXT WG. Comments welcome. -------------------------------------------------------------------------- RADIUS Extensions Working Group (RADIUSEXT) Last Modified: 2003-08-19 Chair(s): Bernard Aboba David Nelson Operations and Management Area Director(s): Randy Bush Bert Wijnen Operations and Management Area Advisor: Randy Bush Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe Archive: http://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP Telephony and Local Area Network authentication, authorization and accounting. All extensions produced by this working group are required to demonstrate backward compatibility with the existing RADIUS protocol as well as compatibility with the equivalent capabilities in the Diameter protocol. No new RADIUS commands will be defined. The immediate goals of the RADIUSEXT working group are to address the following issues: - Attribute space extension. The RADIUS protocol, defined in RFC 2865, has an eight (8) bit attribute space, a good portion of which has already been allocated or is in use. In order to address attribute exhaustion, an extended attribute space will be defined. - RADIUS UDP transport profile. The transport behavior of the RADIUS protocol is unspecified in RFC 2865 and 2866. This has resulted in implementations lacking support for congestion control. This task involves specification of the RADIUS UDP transport mapping, providing support for congestion control and jittering. Failover behavior is not part of this work item, although it may be considered in the future. An explicit non-goal of this work item is to bring RADIUS up to the level of reliability achievable in Diameter. - Pre-paid support. Pre-paid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, a specification is required. The implementation of RADIUS prepaid needs to be compatible with RFC 2865 and 2866, as well as with Diameter prepaid capabilities. - LAN attributes. A number of additional attributes have been proposed to enable use of RADIUS authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. Goals and Milestones: Apr 04 RADIUS attribute space extension submitted as a Proposed Standard RFC. Apr 04 RADIUS UDP transport profile submitted as a Proposed Standard RFC. Sep 04 RADIUS pre-paid suport submitted as an Informational RFC. Dec 04 RADIUS attributes for LANs submitted as an Informational RFC. -- 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, 17 Aug 2003 21:49:22 +0000 Date: Sun, 17 Aug 2003 14:19:11 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: RADIUS work items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, SIPPING does want support for HTTP digest as well as SIP accounting. However, they've expressed a preference for doing this work in SIPPING WG, with potential review by a RADIUS-related WG. SIPPING also requested work on RADIUS reliability improvements, to support the accounting work. The question is whether a modest "transport profile" for RADIUS would actually get them the improved reliability they're looking for. My take is that it won't unless there is some work on failover as well as basic transport behavior. Coexistence with the equivalent Diameter applications is important. ---------- Forwarded message ---------- Date: Tue, 12 Aug 2003 10:22:14 +0000 From: Jari Arkko To: radiusext@ops.ietf.org Subject: Re: Potential RADIUS-related work items Bernard Aboba wrote: > It appears that we have 4 potential work items: > > a. Attribute space extension ETA: 06/04 > b. RADIUS Transport Profile ETA: 06/04 > c. RADIUS Prepaid ETA: 09/04? > d. RADIUS attributes for WLAN ETA: 12/04? > > Comments? Looks good. I'd scope the transport draft very, very narrowly. Didn't the SIPPING group ask for RADIUS HTTP Digest? Also, it since there is ongoing Diameter work on prepaid and digest, it would be useful to coordinate the digest/prepaid and maybe wlan work so that co-existence of the protocols can be assured without spending too much effort on the translation devices. That is, please do not invent widely different schemes for the two protocols ;-) --Jari -- 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, 17 Aug 2003 21:48:27 +0000 Date: Sun, 17 Aug 2003 14:18:03 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Potential RADIUS-related work items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since the conclusion of the RADIUS WG in 2000, work on the RADIUS protocol has continued in a number of forms. This includes a steady stream of Internet Draft submissions, quite a few of which are actually being shipped in commercial products and deployed, sometimes widely. In addition, since the conclusion of the IETF RADIUS WG a number of SDOs and trade associations, including 3GPP2, IEEE 802 and WFA have published their own extensions to the RADIUS protocol. Un the last few months, a number of new RADIUS-related RFCs have been approved for publication. These include RFC 3575 and RFC 3576 (published and available on the IETF archive) as well as the forthcoming RFC 3579 and 3580. Given the steady stream of RADIUS-related work that has continued both within the IETF as well as other organizations, the IESG has recently suggested that we look into formation of a working group to handle this work, rather than continuing to deal with it on an adhoc basis. This mailing list is being set up as a forum for discussion of RADIUS-related work in the IETF. It is not intended to be the only place where RADIUS work is discussed. For example, there has been some discussion in SIPPING WG on potential RADIUS-related work items, and the consensus (at least within SIPPING WG) seems to be that SIP-specific items would be best handled in SIPPING rather than in a RADIUSEXT WG. Similarly, prior to its conclusion, there was discusssion of PPVPN-related RADIUS work in the PPVPN WG, and it is likely that that discussion will continue within the successor WGs. At IETF57, a meeting was held with authors of recent RADIUS-related Internet-Drafts in order to better understand the need for new work, and prioritize potential work items. Here's a summary of the discussion so far. Comments welcome. Basic RADIUS work Since RADIUS is running out of attribute space, it has been suggested that a basic attribute extension mechanism (such as one using the reserved vendorid of 0) be added. This item could be handled in a 1-2 page document so it should have a short timeframe (~6-9 months). There is interest in specifying how RADIUS handles prepaid accounting. Requests for this are coming from the SIP community as well as 3GPP2 and folks interested in WLAN prepaid: http://www.watersprings.org/pub/id/draft-lior-radius-prepaid-extensions-01.txt My understanding is that 3GPP2 intends to include this in a forthcoming standard so that the timeframe needs to be set to meet their needs. Anyone understand what this implies about delivery dates? In order to address concerns about RADIUS transport behavior and accounting reliability, there has been interest expressed on a draft on RADIUS transport behavior. This would presumably address some of the more egregious problems encountered with existing implementations (such as lack of backoff or jittering) as well as describing how RADIUS might be made to work more reliably: http://www.watersprings.org/pub/id/draft-lior-radius-reliable-accounting-00.txt Without some fundamental changes to RADIUS (such as addition of a heartbeat), it is not clear that it will be possible to specify a demonstrably correct failover algorithm in addition to handling basic transport response issues (e.g. backoff, jittering, RTT estimation, etc.). So there is some question about the scope of a potential transport document (e.g. just basic retransmission behavior or retransmssion + failover). On the face of it, it seems that it would require a lot of changes to make RADIUS as reliable as Diameter (RFC 3539), so perhaps this should not be a goal. The timeframe of this work could be short (~9 months) assuming that the scope is containable. One important question about this potential work item is whether work in this area would be likely to be deployed, since at a minimum it requires modification of the RADIUS client, and where protocol changes are made, RADIUS server modifications as well. WLAN-related A number of different organizations (WFA, IEEE, etc.) have been specifying WLAN-related attributes. There appears to be interest in standardizing the most useful ones. This and some other WLAN-related work is described here: http://www.watersprings.org/pub/id/draft-adrangi-radius-issues-in-pwlan-roaming-00.txt The timeframe for this is hard to estimate, but I'd guess it is ~18 months or so. There was interest expressed in work on fast handoff. Bill Arbaugh at the University of Maryland is implementing the draft below: http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-02.txt However, Bill has requested that this work not be considered as an IETF WG work item until his research is complete and the usefulness of the proposed extension can be evaluated. So this would appear to be off the table. Summary It appears that we have 4 potential work items: a. Attribute space extension ETA: 06/04 b. RADIUS Transport Profile ETA: 06/04 c. RADIUS Prepaid ETA: 09/04? d. RADIUS attributes for WLAN ETA: 12/04? Comments? -- 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, 13 Aug 2003 11:07:56 +0000 Message-ID: <3F3A1B65.8050201@piuha.net> Date: Wed, 13 Aug 2003 14:05:09 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net, jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Potential RADIUS-related work items Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit (Repost, had a problem with my mailer configs.) Bernard Aboba wrote: > It appears that we have 4 potential work items: > > a. Attribute space extension ETA: 06/04 > b. RADIUS Transport Profile ETA: 06/04 > c. RADIUS Prepaid ETA: 09/04? > d. RADIUS attributes for WLAN ETA: 12/04? > > Comments? Looks good. I'd scope the transport draft very, very narrowly. Didn't the SIPPING group ask for RADIUS HTTP Digest? Also, it since there is ongoing DIameter work on prepaid and digest, it would be useful to coordinate the digest/prepaid and maybe wlan work so that co-existence of the protocols can be assured without spending too much effort on the translation devices. That is, please do not invent widely different schemes for the two protocols ;-) --Jari -- 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, 12 Aug 2003 13:15:56 +0000 Date: Tue, 12 Aug 2003 05:46:13 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: RADIUS work items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, SIPPING does want support for HTTP digest as well as SIP accounting. However, they've expressed a preference for doing this work in SIPPING WG, with potential review by a RADIUS-related WG. SIPPING also requested work on RADIUS reliability improvements, to support the accounting work. The question is whether a modest "transport profile" for RADIUS would actually get them the improved reliability they're looking for. My take is that it won't unless there is some work on failover as well as basic transport behavior. Coexistence with the equivalent Diameter applications is important. ---------- Forwarded message ---------- Date: Tue, 12 Aug 2003 10:22:14 +0000 From: owner-radiusext@ops.ietf.org To: radiusext@ops.ietf.org Subject: Re: Potential RADIUS-related work items References: In-Reply-To: Bernard Aboba wrote: > It appears that we have 4 potential work items: > > a. Attribute space extension ETA: 06/04 > b. RADIUS Transport Profile ETA: 06/04 > c. RADIUS Prepaid ETA: 09/04? > d. RADIUS attributes for WLAN ETA: 12/04? > > Comments? Looks good. I'd scope the transport draft very, very narrowly. Didn't the SIPPING group ask for RADIUS HTTP Digest? Also, it since there is ongoing Diameter work on prepaid and digest, it would be useful to coordinate the digest/prepaid and maybe wlan work so that co-existence of the protocols can be assured without spending too much effort on the translation devices. That is, please do not invent widely different schemes for the two protocols ;-) --Jari -- 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, 12 Aug 2003 06:30:37 +0000 Date: Mon, 11 Aug 2003 23:00:46 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Potential RADIUS-related work items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since the conclusion of the RADIUS WG in 2000, work on the RADIUS protocol has continued in a number of forms. This includes a steady stream of Internet Draft submissions, quite a few of which are actually being shipped in commercial products and deployed, sometimes widely. In addition, since the conclusion of the IETF RADIUS WG a number of SDOs and trade associations, including 3GPP2, IEEE 802 and WFA have published their own extensions to the RADIUS protocol. Un the last few months, a number of new RADIUS-related RFCs have been approved for publication. These include RFC 3575 and RFC 3576 (published and available on the IETF archive) as well as the forthcoming RFC 3579 and 3580. Given the steady stream of RADIUS-related work that has continued both within the IETF as well as other organizations, the IESG has recently suggested that we look into formation of a working group to handle this work, rather than continuing to deal with it on an adhoc basis. This mailing list is being set up as a forum for discussion of RADIUS-related work in the IETF. It is not intended to be the only place where RADIUS work is discussed. For example, there has been some discussion in SIPPING WG on potential RADIUS-related work items, and the consensus (at least within SIPPING WG) seems to be that SIP-specific items would be best handled in SIPPING rather than in a RADIUSEXT WG. Similarly, prior to its conclusion, there was discusssion of PPVPN-related RADIUS work in the PPVPN WG, and it is likely that that discussion will continue within the successor WGs. At IETF57, a meeting was held with authors of recent RADIUS-related Internet-Drafts in order to better understand the need for new work, and prioritize potential work items. Here's a summary of the discussion so far. Comments welcome. Basic RADIUS work Since RADIUS is running out of attribute space, it has been suggested that a basic attribute extension mechanism (such as one using the reserved vendorid of 0) be added. This item could be handled in a 1-2 page document so it should have a short timeframe (~6-9 months). There is interest in specifying how RADIUS handles prepaid accounting. Requests for this are coming from the SIP community as well as 3GPP2 and folks interested in WLAN prepaid: http://www.watersprings.org/pub/id/draft-lior-radius-prepaid-extensions-01.txt My understanding is that 3GPP2 intends to include this in a forthcoming standard so that the timeframe needs to be set to meet their needs. Anyone understand what this implies about delivery dates? In order to address concerns about RADIUS transport behavior and accounting reliability, there has been interest expressed on a draft on RADIUS transport behavior. This would presumably address some of the more egregious problems encountered with existing implementations (such as lack of backoff or jittering) as well as describing how RADIUS might be made to work more reliably: http://www.watersprings.org/pub/id/draft-lior-radius-reliable-accounting-00.txt Without some fundamental changes to RADIUS (such as addition of a heartbeat), it is not clear that it will be possible to specify a demonstrably correct failover algorithm in addition to handling basic transport response issues (e.g. backoff, jittering, RTT estimation, etc.). So there is some question about the scope of a potential transport document (e.g. just basic retransmission behavior or retransmssion + failover). On the face of it, it seems that it would require a lot of changes to make RADIUS as reliable as Diameter (RFC 3539), so perhaps this should not be a goal. The timeframe of this work could be short (~9 months) assuming that the scope is containable. One important question about this potential work item is whether work in this area would be likely to be deployed, since at a minimum it requires modification of the RADIUS client, and where protocol changes are made, RADIUS server modifications as well. WLAN-related A number of different organizations (WFA, IEEE, etc.) have been specifying WLAN-related attributes. There appears to be interest in standardizing the most useful ones. This and some other WLAN-related work is described here: http://www.watersprings.org/pub/id/draft-adrangi-radius-issues-in-pwlan-roaming-00.txt The timeframe for this is hard to estimate, but I'd guess it is ~18 months or so. There was interest expressed in work on fast handoff. Bill Arbaugh at the University of Maryland is implementing the draft below: http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-02.txt However, Bill has requested that this work not be considered as an IETF WG work item until his research is complete and the usefulness of the proposed extension can be evaluated. So this would appear to be off the table. Summary It appears that we have 4 potential work items: a. Attribute space extension ETA: 06/04 b. RADIUS Transport Profile ETA: 06/04 c. RADIUS Prepaid ETA: 09/04? d. RADIUS attributes for WLAN ETA: 12/04? Comments? -- 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, 10 Aug 2003 17:33:48 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 10 Aug 2003 10:33:41 -0700 To: radiusext@ops.ietf.org Subject: welcome to new mailing list Message-Id: this is a test. if it was reality, you would have been given a manual and proper clothing. -- 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: