RE: RADEXT charter for comment...

["Nelson, David" <dnelson@enterasys.com>]

> > I think the inclusion of the two bit fields (M, R) and a 14-bit
vendor
> > type field would be a good idea.  If we are to do this, I would
> > recommend using a different type code than 26, in aid of backward
> > compatibility.
> 
> I suppose that the issue of backward compatiblity is the presence of
an
> 'M' bit, correct? VSAs are other-wise always assumed optional and it
is
> probably not appropriate for something other than an SSA to carry such
a
> bit.
> Or is there some other issue too?

Primarily the M and R bits, but also the 14-bit length field.

Here's why I think the extended length field is significant. While *any*
octet string that fits within the length impositions of a VSA could be
the "vendor data" part, the suggested format in RFC 2865 indicates that
the existing RADIUS attribute structure is [re]used.  For VSA encodings
that follow this recommendation, existing RADIUS implementations only
need detect the VSA, and then "recursively" call the RADIUS attribute
parser code to extract the vendor AVPs from within the VSA.  

This would allow the vendor sub-attributes to be entered into a data
dictionary, at least one that was segregated by OUI so as to resolve
otherwise duplicate type encodings.  This implementation method relies
on the length of the vendor sub-attribute fields (AVPs) matching the
lengths of the corresponding standard RADIUS attribute header fields. If
the "vendor data" part follows some other pattern, it would not possible
to build a generic VSA sub-attribute parser that would be data
dictionary driven.  

The suggested format for SSA would defeat this "recursive AVP parsing"
trick.  Is this an important tradeoff?  I'm not sure...  Does any one
use this technique for parsing VSA sub-attributes?

-- Dave



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