Re: RADIUS V2

[Bernard Aboba <aboba@internaut.com>]

> Look at how long it took vendors to support Dynamic Authorization
> (RFC3576) - most still don't support it. Similar with the
> MessageAuthenticator attribute.

At this point many RADIUS implementations do support
Message-Authenticator, but it took several years for this to be
implemented.  RFC 3576 is going to be adopted more slowly because it
represents a change in the message flow -- and requires changes in RADIUS
proxies.

> I like Jari's extended attribute for 1 reason : forwards compatibility
> with Diameter. They could be used to build a good bidirectional
> RADIUS-DIAMETER gateway, which is difficult now, especially when
> translating a request from DIAMETER to RADIUS.

As has been pointed out on this list, there are currently quite a few
"gotchas" in RADIUS/Diameter gateway operation.  For example, VSAs with
"sub-attributes" are translated to individual Diameter Vendor-Specific
AVPs, rather than "Grouped" AVPs.

It seems to me that Jari's proposal will improve the fidelity of
translation significantly, and make it quite a bit easier to define
attributes for both RADIUS and Diameter simultaneously.  It also may allow
for reuse of AVP definitions in RFC 3588, NASREQ, Diameter EAP, etc.,
saving considerable work (and text) in RADEXT WG documents.

Given the potential benefits, the proposal is definitely worth serious
examination.

--
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/>