Extended attrs doc

[Alan DeKok <aland@deployingradius.com>]

  Does anyone have feedback?

  My $0.02 is that the format of the "long" attributes is very awkward.
  It means that there are *two* format changes.  The "flags" octet has 7
unused bits, which doesn't seem useful.  And the discussion around the
whole "flags" thing seems awkward.

  I've had some off-list discussions with people, and would like to
propose an alternative.

  The idea is to allow "fragmented" attributes, via an explicit
"Fragment-Data" attribute.  This attribute would be assigned number 255,
and would be defined as being a fragment of the *previous* attribute.

  The rules for encoding it are:

- take attribute data (> 253 octets)
- fill up the first attribute as normal, until "length = 255"
- take the rest of the data
  - chop it into fragments of 253 octets
  - pack it into "Fragment-Data" (type = 255, length = 255)
  - last fragment has length <= 255
    OR last fragment has length == 255, AND the next attribute
    is not Fragment-Data

  The rules for decoding it are:

- For each attribute in the packet
  - if length is 255 AND the next attribute is Fragment-Data (255)
    THEN the data from the next attribute is concatenated to this one

  There are two issues with this proposal:

1) vendors have "self allocated" attribute 255.  This proposal is
   compatible with that, as Fragment-Data is define only when the
   previous attribute has Length==255.  This should be rare.

2) existing proxies re-ordering attributes.
   RFC 2865 says that implementations MUST NOT re-order attributes
   of the same type.  But they CAN re-order attributes of differing
   type.  So there's a chance that proxies which don't understand
   Fragment-Data will re-order them, breaking the packet entirely...

  I'm not aware of many (if any) proxies that do (2).  Most are more
stringent than the requirements of RFC 2865, and don't re-order
attributes of differing type.

  Thoughts?

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