[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: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/>