Potential RADIUS-related work items

[Bernard Aboba <aboba@internaut.com>]

Since the conclusion of the RADIUS WG in 2000,  work on the RADIUS
protocol has continued in a number of forms.

This includes a steady stream of Internet Draft submissions, quite a few
of which are actually being shipped in commercial products and deployed,
sometimes widely.

In addition, since the conclusion of the IETF RADIUS WG a number of SDOs
and trade associations, including 3GPP2,  IEEE 802 and WFA have published
their own extensions to the RADIUS protocol.

Un the last few months, a number of new RADIUS-related RFCs have
been approved for publication.  These include RFC 3575 and RFC 3576
(published and available on the IETF archive) as well as the forthcoming
RFC 3579 and 3580.

Given the steady stream of RADIUS-related work that has continued both
within the IETF as well as other organizations, the IESG has recently
suggested that we look into formation of a working group to handle this
work, rather than continuing to deal with it on an adhoc basis.

This mailing list is being set up as a forum for discussion of
RADIUS-related work in the IETF.  It is not intended to be the only place
where RADIUS work is discussed.  For example, there has been some
discussion in SIPPING WG on  potential RADIUS-related work
items, and the consensus (at least within SIPPING WG) seems to be that
SIP-specific items would be best handled in SIPPING rather than in a
RADIUSEXT WG.  Similarly, prior to its conclusion, there was discusssion
of PPVPN-related RADIUS work in the PPVPN WG,  and it is likely that that
discussion will continue within the successor WGs.

At IETF57, a meeting was held with authors of recent RADIUS-related
Internet-Drafts in order to better understand the need for new work, and
prioritize potential work items.

Here's a summary of the discussion so far.  Comments welcome.

Basic RADIUS work

Since RADIUS is running out of attribute space, it has been suggested that
a basic attribute extension mechanism (such as one using the reserved
vendorid of 0) be added.

This item could be handled in a 1-2 page document so it should have a
short timeframe (~6-9 months).

There is interest in specifying how RADIUS handles prepaid accounting.
Requests for this are coming from the SIP community as well as 3GPP2
and folks interested in WLAN prepaid:

http://www.watersprings.org/pub/id/draft-lior-radius-prepaid-extensions-01.txt

My understanding is that 3GPP2 intends to include this in a forthcoming
standard so that the timeframe needs to be set to meet their needs.
Anyone understand what this implies about delivery dates?

In order to address concerns about RADIUS transport behavior and
accounting reliability, there has been interest expressed on a draft on
RADIUS transport behavior. This would presumably address some of the more
egregious problems encountered with existing implementations (such as
lack of backoff or jittering) as well as describing how RADIUS might be
made to work more reliably:

http://www.watersprings.org/pub/id/draft-lior-radius-reliable-accounting-00.txt

Without some fundamental changes to RADIUS (such as addition of
a heartbeat), it is not clear that it will be possible to specify a
demonstrably correct failover algorithm in addition to handling basic
transport response issues (e.g. backoff, jittering, RTT estimation, etc.).

So there is some question about the scope of a potential transport
document (e.g. just basic retransmission behavior or retransmssion +
failover).  On the face of it, it seems that it would require a lot of
changes to make RADIUS as reliable as Diameter (RFC 3539), so perhaps this
should not be a goal.

The timeframe of this work could be short (~9 months) assuming that the
scope is containable.  One important question about this potential work
item is whether work in this area would be likely to be deployed, since at
a minimum it requires modification of the RADIUS client, and where
protocol changes are made, RADIUS server modifications as well.

WLAN-related

A number of different organizations (WFA, IEEE, etc.) have been specifying
WLAN-related attributes.  There appears to be interest in standardizing
the most useful ones.  This and some other WLAN-related work is described
here:

http://www.watersprings.org/pub/id/draft-adrangi-radius-issues-in-pwlan-roaming-00.txt

The timeframe for this is hard to estimate, but I'd guess it is ~18 months
or so.

There was interest expressed in work on fast handoff. Bill Arbaugh at the
University of Maryland is implementing the draft below:

http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-02.txt

However, Bill has requested that this work not be considered as an IETF WG
work item until his research is complete and the usefulness of the
proposed extension can be evaluated.  So this would appear to be off the
table.

Summary

It appears that  we have 4 potential work items:

a. Attribute space extension   ETA: 06/04
b. RADIUS Transport Profile    ETA: 06/04
c. RADIUS Prepaid              ETA: 09/04?
d. RADIUS attributes for WLAN  ETA: 12/04?

Comments?

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