Re: FW: HTTP digest and RADIUS; new version of the Sterman draft

[Bernard Aboba <aboba@internaut.com>]

> The single largest reason for defining sub-types is not to make our
> life easier when writing new I-D's for RADIUS.  It's to give other
> people a standard way of extending RADIUS, and thus to make our life
> easier when we have to implement their modifications to the protocol.

One of the basic design principles of RADIUS is that adding a new
attributes does not require code changes on the server.  To maintain this
principle while adding sub-types is extremely difficult because:

a.  RADIUS attributes are of limited length.  In Diameter, attributes can
be much larger, which allowed us to introduce "Grouped" AVPs. However,
"Grouped" attributes are permitted in RFC 2865 only within attribute
26, Vendor-Specific, but they are of limited utility since in RADIUS
an attribute can only be 253 octets in length.

b. AAA protocols have chosen not to introduce a data definition language
such as the SMI.  This was debated in the AAA WG, but it was decided that
this would introduce a level of complexity that was not warranted.  In any
case, now that Diameter has chosen grouped AVPs, introduction of a data
type definition language in RADIUS would introduce compatibility issues.

Given the constraints implied by a) and b), the traditional approach in
RADIUS has been to introduce "tagged" attributes that fit within existing
data types.  For example, RFC 2867 and 2868 utilize tags within 4-octet
integers, so that no new data types are required.

Another potential approach would be to add additional fundamental types,
such as 128-bit IPv6 addresses.  While code changes would be required,
they would presumably only need to be done once, and the basic RADIUS
design principle would be upheld.


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