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

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> 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:

  ... new VSA-style attributes with sub-types can be ignored by
servers that don't understand them.  Provisions for this behaviour are
already in the RFC's.  This makes adding new attributes easy, whatever
their internal format.

  I just don't see concrete reasons to oppose the idea that new
attributes may be interpreted in certain limited ways by servers which
have support for those attributes.  Whatever goes into those
attributes is irrelevant to anyone not implementing support for them.

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

  There's nothing to stop us from treating sequential instances of the
same attribute in the same way as we now deal with EAP-Message.  The
only limit on encapsulated data is RADIUS packet size.  Existing
implementations don't need to change.

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

  I don't see anyone here trying to create a data definition language
for RADIUS.  That's a bit much.  The only debate I've seen so far is
about the ability to have VSA-style sub-types in new attributes.

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

  I agree that this will be sufficient for many situations.  If there
is huge opposition to sub-types, then draft authors may trivially work
around the problem by defining "tagged" attributes, where the "tag" is
interpreted as a sub-type.  There will be no changes to existing
implementations, and the attributes will fit into the current
requirements.

  Would that solution be more, or less, acceptable than defining
VSA-style sub-types in a new attribute?

  Alan DeKok.

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