[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Extended attrs doc
> 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 agree. Packet space is a finite resource, and it seems inefficient to essentially waste an additional two octets per concatenated value, unless someone can come up with some additional uses for the flags field...
> 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
>
Seems sensible to me...
> 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.
It goes directly against RFC 2865 too. They've broken the existing standard, and so forwards compatibility of their implementations is not guaranteed.
>
> 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.
The only time I can see this happening is when filtering a request. But as the attributes are usually processed in order, and copied in order; this should be a non issue...
>
> Thoughts?
>
No worse than the original implementation of VSAs :)
-Arran
--
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/>