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