Subject: RE: Strawman RADIUSEXT WG charter - Take Three
From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
To: 'Avi Lior' <[email-masked]>, "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Date: Thu, 28 Aug 2003 07:32:52 -0700

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:[email-masked]] 
> Sent: Wednesday, August 27, 2003 8:10 PM
> To: 'CONGDON,PAUL (HP-Roseville,ex1)'; Avi Lior; 'Bernard Aboba'
> Cc: [email-masked]'
> 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:[email-masked]]
> > Sent: August 27, 2003 4:16 PM
> > To: 'Avi Lior'; 'Bernard Aboba'
> > Cc: [email-masked]'
> > 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:[email-masked]]
> > > Sent: Wednesday, August 27, 2003 9:27 AM
> > > To: 'Bernard Aboba'
> > > Cc: [email-masked]'
> > > 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:[email-masked]]
> > > > Sent: Monday, August 25, 2003 7:48 PM
> > > > To: Richard Perlman
> > > > Cc: Mark Jones; [email-masked]'
> > > > 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
> > [email-masked] with
> > > > the word 'unsubscribe' in a single line as the message 
> text body.
> > > > archive: <http://psg.com/lists/radiusext/>
> > > > 
> > > 
> > > --
> > > to unsubscribe send a message to
> > [email-masked] with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> > > 
> > 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 28 Aug 2003 03:26:54 +0000
From: Avi Lior <[email-masked]>
To: "'CONGDON,PAUL (HP-Roseville,ex1)'" <[email-masked]>, Avi Lior <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter - Take Three
Date: Wed, 27 Aug 2003 23:10:09 -0400

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:[email-masked]] 
> Sent: August 27, 2003 4:16 PM
> To: 'Avi Lior'; 'Bernard Aboba'
> Cc: [email-masked]'
> 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:[email-masked]]
> > Sent: Wednesday, August 27, 2003 9:27 AM
> > To: 'Bernard Aboba'
> > Cc: [email-masked]'
> > 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:[email-masked]]
> > > Sent: Monday, August 25, 2003 7:48 PM
> > > To: Richard Perlman
> > > Cc: Mark Jones; [email-masked]'
> > > 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 
> [email-masked] with 
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> > > 
> > 
> > --
> > to unsubscribe send a message to 
> [email-masked] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 27 Aug 2003 20:17:18 +0000
From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
To: 'Avi Lior' <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter - Take Three
Date: Wed, 27 Aug 2003 16:16:08 -0400

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:[email-masked]] 
> Sent: Wednesday, August 27, 2003 9:27 AM
> To: 'Bernard Aboba'
> Cc: [email-masked]'
> 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:[email-masked]]
> > Sent: Monday, August 25, 2003 7:48 PM
> > To: Richard Perlman
> > Cc: Mark Jones; [email-masked]'
> > 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
> > [email-masked] with the word 'unsubscribe' in 
> > a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 27 Aug 2003 16:28:17 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter - Take Three
Date: Wed, 27 Aug 2003 12:27:24 -0400

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:[email-masked]] 
> Sent: Monday, August 25, 2003 7:48 PM
> To: Richard Perlman
> Cc: Mark Jones; [email-masked]'
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 14:10:30 +0000
From: Mark Jones <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Best Current Practices for WISP Roaming
Date: Tue, 26 Aug 2003 10:09:40 -0400

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 12:37:53 +0000
Date: Tue, 26 Aug 2003 05:06:43 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Best Current Practices for WISP Roaming

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 05:23:51 +0000
Date: Tue, 26 Aug 2003 08:19:46 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: Randy Bush <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Extending RADIUS Attribute Space

>>>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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 00:45:28 +0000
From: Randy Bush <[email-masked]>
Date: Tue, 26 Aug 2003 09:45:05 +0900
To: Richard Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: Extending RADIUS Attribute Space

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 00:32:22 +0000
Date: Mon, 25 Aug 2003 16:48:00 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Richard Perlman <[email-masked]>
cc: Mark Jones <[email-masked]>, "[email-masked]'" <[email-masked]>
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 00:14:45 +0000
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 <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Glen Zorn <[email-masked]>, <[email-masked]>

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" <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 00:11:53 +0000
Date: Mon, 25 Aug 2003 17:09:54 -0700
Subject: Re: Strawman RADIUSEXT WG charter - Take Three
From: Richard Perlman <[email-masked]>
To: Bernard Aboba <[email-masked]>, Mark Jones <[email-masked]>
CC: "[email-masked]'" <[email-masked]>

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" <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 00:07:29 +0000
Date: Mon, 25 Aug 2003 16:36:04 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Richard Perlman <[email-masked]>
cc: Glen Zorn <[email-masked]>, [email-masked]
Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two)

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 00:00:23 +0000
Date: Mon, 25 Aug 2003 16:15:43 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Mark Jones <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter - Take Three

> > - 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 26 Aug 2003 00:00:21 +0000
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 <[email-masked]>
To: Bernard Aboba <[email-masked]>, Glen Zorn <[email-masked]>
CC: <[email-masked]>

Bernard, two short comments...

Richard

On 8/25/03 4:14 PM, "Bernard Aboba" <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 23:57:44 +0000
Date: Mon, 25 Aug 2003 16:26:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Randy Bush <[email-masked]>
cc: Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Extending RADIUS Attribute Space

> > 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 23:45:21 +0000
Date: Mon, 25 Aug 2003 16:14:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
cc: [email-masked]
Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two)

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 23:34:35 +0000
Date: Mon, 25 Aug 2003 16:33:06 -0700
Subject: Re: Extending RADIUS Attribute Space
From: Richard Perlman <[email-masked]>
To: Randy Bush <[email-masked]>, Avi Lior <[email-masked]>
CC: <[email-masked]>

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" <[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 23:04:24 +0000
From: Randy Bush <[email-masked]>
Date: Tue, 26 Aug 2003 08:04:07 +0900
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Extending RADIUS Attribute Space

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 19:08:10 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter - Take Two
Date: Mon, 25 Aug 2003 12:07:09 -0700
Organization: Cisco Systems

Nelson, David <mailto:[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 18:49:32 +0000
From: Mark Jones <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter - Take Three
Date: Mon, 25 Aug 2003 14:49:11 -0400

> - 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 18:47:22 +0000
Date: Mon, 25 Aug 2003 14:47:02 -0400
From: Barney Wolff <[email-masked]>
To: [email-masked]
Subject: Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXT WG charter - Take Two)

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 18:23:09 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
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

Bernard Aboba <mailto:[email-masked]> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 17:59:09 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, 'Greg Weber' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter
Date: Mon, 25 Aug 2003 13:58:35 -0400

> 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:[email-masked]] 
> Sent: Monday, August 25, 2003 11:21 AM
> To: Greg Weber
> Cc: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 15:52:25 +0000
Date: Mon, 25 Aug 2003 08:20:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Greg Weber <[email-masked]>
cc: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 15:33:32 +0000
From: Greg Weber <[email-masked]>
Subject: Re: Strawman RADIUSEXT WG charter
To: [email-masked] (Bernard Aboba)
Date: Mon, 25 Aug 2003 11:32:28 -0400 (EDT)
Cc: [email-masked] (Greg Weber), [email-masked]

> > 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 12:43:37 +0000
content-class: urn:content-classes:message
Subject: RE: Strawman RADIUSEXT WG charter - Take Two
Date: Mon, 25 Aug 2003 08:42:33 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 12:25:34 +0000
From: Avi Lior <[email-masked]>
To: 'Randy Bush' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Extending RADIUS Attribute Space
Date: Mon, 25 Aug 2003 08:25:06 -0400

See inline.

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]] 
> Sent: August 25, 2003 2:31 AM
> To: Avi Lior
> Cc: 'Nelson, David'; [email-masked]'
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 25 Aug 2003 06:32:06 +0000
From: Randy Bush <[email-masked]>
Date: Mon, 25 Aug 2003 15:31:24 +0900
To: Avi Lior <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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.

randy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 24 Aug 2003 22:05:28 +0000
Date: Sun, 24 Aug 2003 14:34:17 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Strawman RADIUSEXT WG charter - Take Three

OK.  Here's another try...

-------------------------------------------------------
RADIUS Extensions Working Group (RADIUSEXT)
Last Modified: 2003-08-22

Chair(s):
David Nelson <[email-masked]>

Operations and Management Area Director(s):
Randy Bush <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
Randy Bush <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Aug 2003 23:25:30 +0000
Date: Sat, 23 Aug 2003 15:54:35 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
cc: [email-masked]
Subject: RE: Strawman RADIUSEXT WG charter - Take Two

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Aug 2003 17:01:58 +0000
Date: Sat, 23 Aug 2003 09:28:21 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>
cc: [email-masked]
Subject: RE: Strawman RADIUSEXT WG charter - Take Two

> > - 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Aug 2003 16:11:40 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter - Take Two
Date: Sat, 23 Aug 2003 09:10:41 -0700
Organization: Cisco Systems

[email-masked] <mailto:[email-masked]>
writes:

> RADIUS Extensions Working Group (RADIUSEXT)
> Last Modified: 2003-08-22
> 
> Chair(s):
> Bernard Aboba <[email-masked]>

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 <[email-masked]>
> 
> Operations and Management Area Director(s):
> Randy Bush <[email-masked]>
> Bert Wijnen <[email-masked]>
> 
> Operations and Management Area Advisor:
> Randy Bush <[email-masked]>
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Aug 2003 14:28:19 +0000
Date: Sat, 23 Aug 2003 06:57:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Strawman RADIUSEXT WG charter - Take Two

RADIUS Extensions Working Group (RADIUSEXT)
Last Modified: 2003-08-22

Chair(s):
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Operations and Management Area Director(s):
Randy Bush <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
Randy Bush <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Aug 2003 12:11:42 +0000
content-class: urn:content-classes:message
Subject: RE: Some thoughts
Date: Sat, 23 Aug 2003 08:11:14 -0400
From: "Nelson, David" <[email-masked]>
To: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, <[email-masked]>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Aug 2003 03:42:36 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, <[email-masked]>
Subject: RE: Extending RADIUS Attribute Space
Date: Fri, 22 Aug 2003 20:41:11 -0700
Organization: Cisco Systems

[email-masked] <mailto:[email-masked]>
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 23 Aug 2003 02:34:50 +0000
content-class: urn:content-classes:message
Subject: RE: Extending RADIUS Attribute Space
Date: Fri, 22 Aug 2003 13:19:19 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 22:19:32 +0000
From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Some thoughts
Date: Fri, 22 Aug 2003 18:14:09 -0400

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:[email-masked]] 
> Sent: Friday, August 22, 2003 11:16 AM
> To: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 21:32:05 +0000
Date: Fri, 22 Aug 2003 13:46:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Some thoughts

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 20:27:59 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Some thoughts
Date: Fri, 22 Aug 2003 16:26:29 -0400

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:[email-masked]] 
> Sent: Friday, August 22, 2003 2:16 PM
> To: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 18:33:33 +0000
Date: Fri, 22 Aug 2003 10:18:16 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Extending RADIUS Attribute Space

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 18:21:15 +0000
content-class: urn:content-classes:message
Subject: RE: Some thoughts
Date: Fri, 22 Aug 2003 14:16:28 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 18:09:10 +0000
Date: Fri, 22 Aug 2003 10:33:37 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Some thoughts

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 17:42:40 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Extending RADIUS Attribute Space
Date: Fri, 22 Aug 2003 13:13:05 -0400

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Friday, August 22, 2003 12:44 PM
> To: [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 16:46:33 +0000
content-class: urn:content-classes:message
Subject: RE: Extending RADIUS Attribute Space
Date: Fri, 22 Aug 2003 12:44:05 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 15:31:38 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Avi Lior <[email-masked]>
Subject: RE: Extending RADIUS Attribute Space
Date: Fri, 22 Aug 2003 11:29:52 -0400

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:[email-masked]] 
> Sent: Friday, August 22, 2003 1:34 AM
> To: Jari Arkko
> Cc: Avi Lior; 'Nelson, David'; [email-masked]'
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 06:19:48 +0000
Date: Thu, 21 Aug 2003 22:33:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Avi Lior <[email-masked]>, "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 06:14:46 +0000
Date: Thu, 21 Aug 2003 22:30:17 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Avi Lior <[email-masked]>, "'Greg Weber'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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...

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 22 Aug 2003 06:12:46 +0000
Date: Thu, 21 Aug 2003 22:41:31 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Greg Weber <[email-masked]>
cc: [email-masked]
Subject: Re: Strawman RADIUSEXT WG charter

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 22:41:51 +0000
Date: Thu, 21 Aug 2003 18:38:20 -0400
From: Barney Wolff <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: Avi Lior <[email-masked]>, "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Extending RADIUS Attribute Space

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 22:04:12 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: 'Greg Weber' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter
Date: Thu, 21 Aug 2003 18:03:24 -0400

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, August 21, 2003 4:50 PM
> To: Avi Lior
> Cc: 'Greg Weber'; [email-masked]'
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 21:36:37 +0000
Date: Fri, 22 Aug 2003 00:33:06 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Extending RADIUS Attribute Space

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 21:34:57 +0000
Date: Thu, 21 Aug 2003 13:49:42 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "'Greg Weber'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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/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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 19:40:47 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Extending RADIUS Attribute Space
Date: Thu, 21 Aug 2003 15:40:35 -0400

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:[email-masked]] 
> Sent: Thursday, August 21, 2003 2:57 PM
> Cc: [email-masked]
> 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: [email-masked]
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 18:58:35 +0000
content-class: urn:content-classes:message
Subject: RE: Extending RADIUS Attribute Space
Date: Thu, 21 Aug 2003 14:56:49 -0400
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

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: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 18:08:32 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: 'Greg Weber' <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Extending RADIUS Attribute Space
Date: Thu, 21 Aug 2003 14:08:09 -0400

Jari,

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, August 21, 2003 1:26 PM
> To: Avi Lior
> Cc: 'Greg Weber'; [email-masked]'; [email-masked]'
> 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:[email-masked]]
> >>Sent: Wednesday, August 20, 2003 9:59 AM
> >>To: [email-masked]
> >>Cc: [email-masked]
> >>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 <[email-masked]>
> >>>David Nelson <[email-masked]>
> >>>
> >>>Operations and Management Area Director(s):
> >>>Randy Bush <[email-masked]>
> >>>Bert Wijnen <[email-masked]>
> >>>
> >>>Operations and Management Area Advisor:
> >>>Randy Bush <[email-masked]>
> >>>
> >>>Mailing Lists:
> >>>General Discussion: [email-masked]
> >>>To Subscribe: [email-masked], 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
> >>
> >>[email-masked] with
> >>
> >>>the word 'unsubscribe' in a single line as the message text body.
> >>>archive: <http://psg.com/lists/radiusext/>
> >>>
> >>
> >>--
> >>to unsubscribe send a message to
> >>[email-masked] with the word 'unsubscribe' in 
> >>a single line as the message text body.
> >>archive: <http://psg.com/lists/radiusext/>
> >>
> > 
> > --
> > to unsubscribe send a message to 
> [email-masked] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> > 
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 17:29:29 +0000
Date: Thu, 21 Aug 2003 20:26:25 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: 'Greg Weber' <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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

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:[email-masked]] 
>>Sent: Wednesday, August 20, 2003 9:59 AM
>>To: [email-masked]
>>Cc: [email-masked]
>>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 <[email-masked]>
>>>David Nelson <[email-masked]>
>>>
>>>Operations and Management Area Director(s):
>>>Randy Bush <[email-masked]>
>>>Bert Wijnen <[email-masked]>
>>>
>>>Operations and Management Area Advisor:
>>>Randy Bush <[email-masked]>
>>>
>>>Mailing Lists:
>>>General Discussion: [email-masked]
>>>To Subscribe: [email-masked], 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 
>>
>>[email-masked] with 
>>
>>>the word 'unsubscribe' in a single line as the message text body.
>>>archive: <http://psg.com/lists/radiusext/>
>>>
>>
>>--
>>to unsubscribe send a message to 
>>[email-masked] with the word 'unsubscribe' in 
>>a single line as the message text body.
>>archive: <http://psg.com/lists/radiusext/>
>>
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 15:02:13 +0000
From: Avi Lior <[email-masked]>
To: 'Greg Weber' <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Extending RADIUS Attribute Space
Date: Thu, 21 Aug 2003 11:01:53 -0400

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:[email-masked]] 
> Sent: Wednesday, August 20, 2003 9:59 AM
> To: [email-masked]
> Cc: [email-masked]
> 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 <[email-masked]>
> > David Nelson <[email-masked]>
> > 
> > Operations and Management Area Director(s):
> > Randy Bush <[email-masked]>
> > Bert Wijnen <[email-masked]>
> > 
> > Operations and Management Area Advisor:
> > Randy Bush <[email-masked]>
> > 
> > Mailing Lists:
> > General Discussion: [email-masked]
> > To Subscribe: [email-masked], 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 
> [email-masked] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 21 Aug 2003 14:22:09 +0000
From: Avi Lior <[email-masked]>
To: 'Greg Weber' <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Strawman RADIUSEXT WG charter
Date: Thu, 21 Aug 2003 10:20:59 -0400

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:[email-masked]] 
> Sent: Wednesday, August 20, 2003 9:59 AM
> To: [email-masked]
> Cc: [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 20 Aug 2003 13:59:19 +0000
From: Greg Weber <[email-masked]>
Subject: Re: Strawman RADIUSEXT WG charter
To: [email-masked] (Bernard Aboba)
Date: Wed, 20 Aug 2003 09:58:53 -0400 (EDT)
Cc: [email-masked]

> 
> 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 <[email-masked]>
> David Nelson <[email-masked]>
> 
> Operations and Management Area Director(s):
> Randy Bush <[email-masked]>
> Bert Wijnen <[email-masked]>
> 
> Operations and Management Area Advisor:
> Randy Bush <[email-masked]>
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 19 Aug 2003 18:57:02 +0000
Date: Tue, 19 Aug 2003 21:54:03 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Strawman RADIUSEXT WG charter

Looks good to me. A few nits and questions inline:

> RADIUS Extensions Working Group (RADIUSEXT)
> Last Modified: 2003-08-19
> 
> Chair(s):
> Bernard Aboba <[email-masked]>
> David Nelson <[email-masked]>
> 
> Operations and Management Area Director(s):
> Randy Bush <[email-masked]>
> Bert Wijnen <[email-masked]>
> 
> Operations and Management Area Advisor:
> Randy Bush <[email-masked]>
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked], 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<something>?
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 19 Aug 2003 15:17:09 +0000
Date: Tue, 19 Aug 2003 07:46:10 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Strawman RADIUSEXT WG charter

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 <[email-masked]>
David Nelson <[email-masked]>

Operations and Management Area Director(s):
Randy Bush <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
Randy Bush <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 17 Aug 2003 21:49:22 +0000
Date: Sun, 17 Aug 2003 14:19:11 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS work items

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 <[email-masked]>
To: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 17 Aug 2003 21:48:27 +0000
Date: Sun, 17 Aug 2003 14:18:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Potential RADIUS-related work items

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 13 Aug 2003 11:07:56 +0000
Date: Wed, 13 Aug 2003 14:05:09 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked], [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Potential RADIUS-related work items

(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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 12 Aug 2003 13:15:56 +0000
Date: Tue, 12 Aug 2003 05:46:13 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS work items

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: [email-masked]
To: [email-masked]
Subject: Re: Potential RADIUS-related work items
References: <[email-masked]>
In-Reply-To: <[email-masked]>

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 12 Aug 2003 06:30:37 +0000
Date: Mon, 11 Aug 2003 23:00:46 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Potential RADIUS-related work items

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 10 Aug 2003 17:33:48 +0000
From: Randy Bush <[email-masked]>
Date: Sun, 10 Aug 2003 10:33:41 -0700
To: [email-masked]
Subject: welcome to new mailing list

this is a test.  if it was reality, you would have been given
a manual and proper clothing.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>