Re: Questions on RADIUS Extended attributes

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

"Nelson, David" <dnelson@enterasys.com> wrote:
> > 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.
> 
> Please elaborate.  What field contains the "zero" that indicates
> concatenation?  Do I understand correctly that this is a mechanism for
> fragmentation and reassembly?  Some additional detail would be helpful.

  The proposed format for the Extended-Type is (in short)

  T L T2 L2 data...

  Where T and L are the RADIUS type and length.  T2 is the proposed 2
or 4 octet extended type, and L2 is the length of the encapsulated data.

  Since we have L, L2 isn't strictly necessary.  But even with L2, the
length of the data is limited to less than 253 bytes, which is a
problem for long data strings.  We could fix the data length problem
by allow L2 to be larger than 253, and relying on that to indicate
concatenation.

  e.g.

  T L T2 L2 data1... T L data2...

  Where L2 is the length of data1 + data2.  However, this makes
parsing the Extended-Type problematic, as the data in Extended-Type is
sometimes 'T2 L2 data', and sometimes just 'data..'  I've run into
these issues in the past, and they're awkward and problematic to deal
with.

  Therefore, my proposal is the following.  L2 is unnecessary, so we
drop it.  The format is now:

  T L T2 data...

  We still have the problem of data length, though.  We can solve this
by saying "if T2 is zero, then the data for this extended type is
concatenated to the data for the previous one".  e.g.

  T L T2 data1... T L 0000 data2...

  The format of Extended-Type is now always 'T2 data...', which seems
good to me.  The length of T2 is derived from from the lengths of the
encapsulating Extended-Type attribute.  And the concatatenation can
only occur if the first Extended-Type attribute has L=255, and even
then, only if the next Extended-Type attribute exists, AND has T2 != 0000.

  I hope that's a little clearer.

  My main reason for getting rid of L2 is that allowing it to be
larger than L is a nightmare.  i.e. the encapsulated structure
indicates it's larger than the structure that is performing the
encapsulation.  That's a recipe for buffer overflows, bugs,
incompatibilities, etc.  I'm rating developer efficiency as a higher
priority than network efficiency.  I have *rarely* seen packet size be
a problem in RADIUS, and I've seen many bugs and incompatibilities in
implementations.

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