Subject: Extended attrs doc

From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 5 Sep 2011 20:23:56 +0200

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>