[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extended attrs doc
On Tue, 21 Jun 2011, Alan DeKok wrote:
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.
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
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/>
--
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/>