Extending RADIUS Attribute Space

[Avi Lior <avi@bridgewatersystems.com>]

Further to my last email:

The solution in the last email addresses extending an attribute beyong the
255 limit.  To fully address the requirement we should really address how to
extend the attributes beyong a single RADIUS packet.

If there was interest in that, I would propose to use the more robust scheme
that is used in PEAP.

Comments?

> -----Original Message-----
> From: Greg Weber [mailto:gdweber@cisco.com] 
> Sent: Wednesday, August 20, 2003 9:59 AM
> To: aboba@internaut.com
> Cc: radiusext@ops.ietf.org
> Subject: Re: Strawman RADIUSEXT WG charter
> 
> 
> > 
> > Here is a proposed strawman charter for a RADIUSEXT WG.  Comments 
> > welcome.
> 
> Some comments and questions inline.
> 
> > 
> > 
> ----------------------------------------------------------------------
> > ----
> > 
> > RADIUS Extensions Working Group (RADIUSEXT)
> > Last Modified: 2003-08-19
> > 
> > Chair(s):
> > Bernard Aboba <aboba@internaut.com>
> > David Nelson <dnelson@enterasys.com>
> > 
> > Operations and Management Area Director(s):
> > Randy Bush <randy@psg.com>
> > Bert Wijnen <bwijnen@lucent.com>
> > 
> > Operations and Management Area Advisor:
> > Randy Bush <randy@psg.com>
> > 
> > Mailing Lists:
> > General Discussion: radiusext@ops.ietf.org
> > To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe
> > Archive: http://ops.ietf.org/lists/radiusext
> > 
> > Description of Working Group:
> > 
> > The RADIUS Extensions Working Group will focus on extensions to the 
> > RADIUS protocol required to enable its use in applications 
> such as IP 
> > Telephony and Local Area Network authentication, authorization and 
> > accounting.  All extensions produced by this working group are 
> > required to demonstrate backward compatibility with the existing 
> > RADIUS protocol as well as compatibility with the equivalent 
> > capabilities in the Diameter protocol. No new RADIUS 
> commands will be 
> > defined.
> 
> Would this last sentence preclude future work items to 
> specify the behavior of packet types reserved by RFC 3575, 
> but not defined by RFC 2882?  In particular, I think producing 
> a specification for packet type codes 33 & 34 (Event-Request/
> Response) will be useful in a number of forums and can be 
> done in a Diameter compatible way.
> 
> > The immediate goals of the RADIUSEXT working group are to 
> address the 
> > following issues:
> > 
> > - Attribute space extension.  The RADIUS protocol, defined in
> >   RFC 2865, has an eight (8) bit attribute space, a good portion
> >   of which has already been allocated or is in use.  In order to
> >   address attribute exhaustion, an extended attribute space will be
> >   defined.
> 
> Will this work item include addressing the attribute size 
> limitation in the extended space?  A number of methods 
> for fragmenting large values across attributes have popped 
> up, e.g. as in the PacketCable 1.0 spec.  It would be nice 
> to have a standard way of doing this.
> 
> Greg
> 
> > 
> > - RADIUS UDP transport profile.  The transport behavior of 
> the RADIUS
> >   protocol is unspecified in RFC 2865 and 2866.  This has 
> resulted in
> >   implementations lacking support for congestion control. This task
> >   involves specification of the RADIUS UDP transport mapping,
> >   providing support for congestion control and jittering.  Failover
> >   behavior is not part of this work item, although it may be
> >   considered in the future.  An explicit non-goal of this work item
> >   is to bring RADIUS up to the level of reliability achievable in
> >   Diameter.
> > 
> > - Pre-paid support.  Pre-paid services are contemplated in a number
> >   of potential applications, including wireless LAN access and IP
> >   telephony. In order to enable support of pre-paid services in an
> >   interoperable way, a specification is required.  The 
> implementation of
> >   RADIUS prepaid needs to be compatible with RFC 2865 and 2866,
> >   as well as with Diameter prepaid capabilities.
> > 
> > - LAN attributes.  A number of additional attributes have been
> >   proposed to enable use of RADIUS authentication, authorization and
> >   accounting in wired and wireless LANs.  Standardization of these
> >   attributes will enable improved interoperability.
> > 
> > Goals and Milestones:
> > 
> > Apr 04  RADIUS attribute space extension submitted as a Proposed 
> > Standard RFC. Apr 04  RADIUS UDP transport profile submitted as a 
> > Proposed Standard RFC. Sep 04  RADIUS pre-paid suport 
> submitted as an 
> > Informational RFC. Dec 04  RADIUS attributes for LANs 
> submitted as an 
> > Informational RFC.
> > 
> > --
> > to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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