Re: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt

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

Bernard Aboba <aboba@internaut.com> wrote:
> It would be nice to allow larger attributes if there was some way to
> accomplish this while maintaining backward compatibility.  Do we have a
> proposal for how to do this?

  As an absolutely horrible idea, how about overloading the "tag"
concept for new attributes which need (length > 253).  Quoting RFC
2868 out of context, the tag is already defined as "... a means of
grouping attributes in the same packet..."

  We could say that a new attribute, say Large-Attribute is of type
string, has a tag, and that the interpretation of the attribute is
such that all instances of Large-Attribute with the same tag should
have their string data concatenated, to obtain data with (length>253).
The definition of that data would come from the requirements on the
Large-Attribute design.

  I don't immediately see much in the way of backwards incompatibility
with this idea, but I'm not sure it's a good one.

> For example, if an attribute is defined with a length > 253, won't
> existing proxies have trouble figuring this out?

  I'm not sure how a RADIUS attribute can have length>253.

>  Or is the idea to have the *inner* length different from the
> *outer* length?  That way the outer length <= 253, but the inner
> length can be larger?

  That makes more sense to me.  But it gets back into the "packing
attributes inside of attributes", which was previously discussed with
some energy.

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