[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on RADIUS Extended attributes
"Bernard Aboba" <bernard_aboba@hotmail.com> wrote:
> a. Do we want an Extended-Type field of two or four octets? If it is four
> octets, this would seem to imply that RADIUS attributes and Diameter AVPs
> share the same type space. Will this work? If it is two octets, we could
> reserve 65535 values within the existing Diameter attribute space for RADIUS
> Extended-Type attributes. Opinions solicited.
I think 2 octets is OK. There are nowhere near 64k RADIUS
attributes in existence today, even including VSA's. So 64k would
seem to be sufficient for a while.
> b. Should the second length field include the Extended-Type field or not?
> If it is included and Extended-Type is 4 octets, then this implies that the
> Value field could only be 251 octets. If the second length field doesn't
> include Extended-Type, it could be as long as 255 octets, but then we'd need
> to allow Extended-Type attributes to be split among multiple RADIUS
> attributes.
I would say the length field does not need to be included.
The issue of data length can be addressed, for example, by reserving
0 for "concatenate values to the end of the previous Extended-Type".
This allows the values to extend past 251 octets, and makes the format
of the attribute constant.
> c. Should we allow multiple Extended-Type attributes to be placed inside a
> single RADIUS attribute? This is OK for RADIUS VSAs, is there an issue here?
If we include a length, yes. We should then say that all
implementations MUST support it.
If we don't include a length, no.
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/>