Re: Extended attrs doc

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> Interesting...RFC 2865 5:
> 
> "A RADIUS server or client MUST NOT have any dependencies on the order
> of attributes of different types."

  Yes.  However, the WG can change that if consensus is reached.

> "A RADIUS server or client MUST NOT require attributes of the same type
> to be contiguous."
> 
> RFC 3579 3.1 (EAP)
> 
> "If multiple EAP-Message attributes are contained within an
> Access-Request or Access-Challenge packet, they MUST be in order and
> they MUST be consecutive attributes in the Access-Request or
> Access-Challenge packet."
> 
> Note the direct contradiction of 'MUST NOT' vs 'MUST'.

  Yes.  I haven't seen any interoperability issues as a result of EAP
violating RFC 2865 Section 5.

> I tend to prefer a system which minimizes the possibility of data
> corruption caused by ordering or truncation of attributes by systems
> (Not necessarily only proxies) some of which may not even know what an
> extended attribute is.

  I agree.

> If the system detects an error or the data is missing no data is ALWAYS
> preferable to wrong data.

  That's why the document introduces the concept of an "invalid
attribute".  These are attributes which are not treated as their alleged
number would indicate.

> Extended attribute is like WiMax however a little worse in that the
> inner attribute type is not preserved in the next fragment so any error
> could cause weird situations where the data field of a mis-ordered
> extended type leaks into a separate attributes 'type' field. (Esp last
> attribute with more bit not set)

  Yes.  The hope is that proxies will not re-order attributes of the
same type.  So having the fragments buried inside of multiple attributes
of type 245 *should* be OK.

> The use of a separate fragment-data attribute raises more ordering
> dependency questions.  From a design POV I prefer the attributes to be
> self-contained within the same type.  What happens when there are
> multiple ext frag attributes in the same request with different
> attribute id's (245,246) ?

  My message describes how they're treated.  Ordering *is* important.

>  There is no RFC anywhere preventing reorder
> and as you mention how do you know which fragment is which or when one
> stops and the other starts?

  My message describes how to detect when a fragment starts and stops.

> My suggestion is to keep the draft as is but add an explicit fragment
> counter next to the more flag using some or all of the remaining 7-bits.
> Since max RADIUS packet size is 4096 there are more than enough bits.

  One issue is having a "fragment id" field means there's another
opportunity for implementations to get the encoding wrong.  And there's
been talk of extending the maximum RADIUS packet size.

> For example Attr1 requires 4 fragments to assemble..
> 
> Attr1 - (More=Yes, Counter=1) ... data ... Attr1 - (More=Yes, Counter=2)
> ... data ... Attr1 - (More=Yes, Counter=3) ... data ... Attr1 -
> (More=No, Counter=4) ... data ...
> 
> Attr2 does not require fragmentation:
> 
> Attr2 - (More=No, Counter=0)
> 
> Note attributes not requiring fragmentation could use 0 to explicitly
> indicate so they could never be confused with an end of fragment.

  OK.

> I also prefer fragmentation occur on the same level of the attribute
> like WiMax VSAs where the attributes inner type is fully defined before
> the fragmentation payload so there can never be any ambiguity regarding
> at least the attribute type the fragment belongs.

  The difficulty with that is that the fragmentation method *cannot*
modify how the VSA space is encoded.  That space is completely under
control of the vendors.

>  With the above
> Counter fields in the picture this preference does not matter as much
> and perhaps saving the extra byte(s) is the better tradeoff.

  The counter makes it easier to detect re-ordered attributes, that's true.

  Changing the "more" flag to an 8-bit fragment counter would solve a
number of issues.  You would have an explicit ordering of fragments, and
it would mean that attributes could be 251*255, or 64005 octets long.
That *should* be enough for most RADIUS purposes...

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