Subject: Extended attrs doc

From: Alan DeKok <[email-masked]>
Date: Tue, 21 Jun 2011 14:41:49 +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'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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Peter Deacon <[email-masked]>
Date: Tue, 21 Jun 2011 09:49:37 -0700 (Pacific Daylight Time)

> whole "flags" thing seems awkward.

Interesting...RFC 2865 5:

"A RADIUS server or client MUST NOT have any dependencies on the order of 
attributes of different types."

"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'.

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.

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

WiMax uses more flags, EAP I will just ignore.

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)

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) ?  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 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.

With this approach the chance of at least detecting out of order fragments 
increase.

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.

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

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 21 Jun 2011 19:16:22 +0200

Peter Deacon wrote:
> "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."
> 

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

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

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

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

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

> Attr1 - (More=Yes, Counter=1) ... data ... Attr1 - (More=Yes, Counter=2)
> ... data ... Attr1 - (More=Yes, Counter=3) ... data ... Attr1 -
> (More=No, Counter=4) ... data ...
> 

  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.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 22 Jun 2011 13:12:17 -0700 (Pacific Daylight Time)

Slightly off-topic -- wanted to point out proxies seem to be allowed to 
add add attributes anywhere they want in a packet while still respecting 
ordering constraint of RFC 2865 2.3.

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

Yes, think we agree on the constraints.  Packet wide ordering would need 
to be preserved.

> been talk of extending the maximum RADIUS packet size.

I believe practically if this type of encoding were wrong the situation 
would be detected quickly in any reasonable interop test.  It is the not 
so obvious interactions between systems and extension attributes I'm most 
concerned about.

> modify how the VSA space is encoded.  That space is completely under

Don't think this applies to extensions VSAs.  In 4.6 Vendor Type is 
explicitly defined as a single byte.

"The Vendor-Type field is one octet.  Values are assigned at the sole 
discretion of the Vendor."

This type has a more flag so thinking we would expect the same encoding 
rules for all extensions VSAs where it came to fragmentation.

> That *should* be enough for most RADIUS purposes...

If I had to choose between a more flag and the counter I would pick the 
counter.

Prefer combination of more and counter since it gives you the end marker 
to detect truncation.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 23 Jun 2011 09:28:46 +0200

> ordering constraint of RFC 2865 2.3.

  Yes.

> so obvious interactions between systems and extension attributes I'm
> most concerned about.

  People do interop tests?  Maybe I post a list of vendors who've
blatantly violated the RFCs and interoperability.

> rules for all extensions VSAs where it came to fragmentation.

  Yes.  The top-level VSA can be fragmented.  Anything *inside* of that,
such as sub-TLVs, cannot be fragmented.

> Prefer combination of more and counter since it gives you the end marker

  Or, start the counter at the last fragment.  Counters go N, N-1, N-2,
..., 1, 0.  If the list is truncated, it doesn't end at zero.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 23 Jun 2011 01:18:58 -0700 (Pacific Daylight Time)

> ..., 1, 0.  If the list is truncated, it doesn't end at zero.

This shifts the problem from the end to the start.

regards,
Peter