[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Extending RADIUS Attribute Space
Jari,
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Thursday, August 21, 2003 1:26 PM
> To: Avi Lior
> Cc: 'Greg Weber'; 'aboba@internaut.com'; 'radiusext@ops.ietf.org'
> Subject: Re: Extending RADIUS Attribute Space
>
>
>
> I agree that attribute number space needs to be expanded, but
> I wonder how useful it is to do a redesign of the packet and
> attribute formats to cater for larger lengths. Seems like its
> a pretty big change, and if you need that, you'd have to
> worry about full transport reliability as well. If you
> willing to do such a big change, maybe its time to move to
> another protocol...
>
> --Jari
Allowing for larger attributes and allowing for attributes to span packets
is not a big change. It is in fact something that is done today already.
The point of this whole exercise is not to force people to go to another
protocol!!! People who want another protocol can choose to go to that other
protocol. It would be great to move to another protocol but there are huge
cost and business issues to consider as well.
I don't see the nexus between having larger lengths and full transport
reliability.
> Avi Lior wrote:
> > Further to my last email:
> >
> > The solution in the last email addresses extending an
> attribute beyong
> > the 255 limit. To fully address the requirement we should really
> > address how to extend the attributes beyong a single RADIUS packet.
> >
> > If there was interest in that, I would propose to use the
> more robust
> > scheme that is used in PEAP.
> >
> > Comments?
> >
> >
> >>-----Original Message-----
> >>From: Greg Weber [mailto:gdweber@cisco.com]
> >>Sent: Wednesday, August 20, 2003 9:59 AM
> >>To: aboba@internaut.com
> >>Cc: radiusext@ops.ietf.org
> >>Subject: Re: Strawman RADIUSEXT WG charter
> >>
> >>
> >>
> >>>Here is a proposed strawman charter for a RADIUSEXT WG. Comments
> >>>welcome.
> >>
> >>Some comments and questions inline.
> >>
> >>
> >>>
> >>------------------------------------------------------------
> ----------
> >>
> >>>----
> >>>
> >>>RADIUS Extensions Working Group (RADIUSEXT)
> >>>Last Modified: 2003-08-19
> >>>
> >>>Chair(s):
> >>>Bernard Aboba <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/>
> >
> >
>
>
--
to 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/>