[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt
Alan DeKok <> supposedly scribbled:
> Bernard Aboba <firstname.lastname@example.org> wrote:
>> It would be nice to allow larger attributes if there was some way
>> accomplish this while maintaining backward compatibility. Do we
>> 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
> string, has a tag, and that the interpretation of the attribute is
> such that all instances of Large-Attribute with the same tag
> 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.
I don't think that it's necessary: you could just define the real
value of Large-Attribute as the concatenation of the String fields
of all the Large-Attribute Attributes in the message, since
Attributes are guaranteed now to maintain relative order; that
wasn't true when RFC 2868 was undertaken.
>> For example, if an attribute is defined with a length > 253,
>> existing proxies have trouble figuring this out?
> I'm not sure how a RADIUS attribute can have length>253.
The value of the Length field can't be > 253; that doesn't
necessarily mean that an attribute can't be bigger than that (for
example, using the technique I roughly outlined). I can't think of
any compatibility problems off the top of my head, but I haven't
spent much (any ;-) time on it.
>> 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
> some energy.
And is already allowed (in VSAs) by RFC 2865.
> Alan DeKok.
Hope this helps,
Why is it that most of the world's problems can't be solved by
listening to John Coltrane? -- Henry Gabriel
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.