[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Bernard Aboba wrote:
> This is a reminder of the RADEXT WG Last Call on "Extended
> RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard.
Submitter name: Alan DeKok
Submitter email address: email@example.com
Date first submitted: Aug 14 2008
Comment type: T
o The final octet of the header contains the More flag and Tag
field. If the one bit More flag is set (1) this indicates that
the encapsulated TLV is continued in the following Extended
Attribute; if the More flag is clear (0) then all of the
encapsulated TLVs fit into the current Extended Attribute. The
More flag MUST NOT be set if the Extended Attribute contains more
than one TLV.
To be clear: this means that the Extended-Attribute can encapsulate
multiple TLV's if they're short, or only one TLV if it's long.
The More Flag is one (1) bit in length and MUST be present. When
a value to be transmitted exceeds 246 octets in length it is
fragmented over two or more Extended Attributes. If the More Flag
is set (1), this indicates that the Value field of the Extended
Attribute contains a fragment of a larger value, which is
continued in the next Extended Attribute of the same Ext-Type.
Can we add a MUST? i.e. If the More Flag is set, the next attribute
MUST be an Extended-Attribute of the same Extended-Type.
Inserting *other* attributes in between a fragemented attribute is
annoying and pointless. It's better to forbid this, and to declare that
packets failing this test are malformed, and SHOULD be silently discarded.
Two (2) octets. Up-to-date values of the Ext-Type field are
specified in the most recent "Assigned Numbers" [IANA]. Values
XXXX-YYYY are reserved.
I would suggest reserving the top 1K: 64512-65535
Consider an attribute called Foo of type String. Foo has been
allocated an Extended-Type 0f 257 by IANA. The following figure
shows the encoding of Foo(0,4) = "Hello":
What does "Foo(0,4)" mean? This is the first reference in that
document to that attribute naming scheme. (I presume it's an attribute
naming scheme). Why not just refer to it as "Foo"?
The diagram also has Ext-Type (16 bits) of 257 split between two bytes
(8 bits) of 0 and 257. I welcome the novel ability to count to 257 in
an 8-bit field, but perhaps this could be corrected. :)
The examples should use numbers from the reserved space (i.e. 64512),
and not from the IANA allocated space (257). The examples also use the
attribute name "Foo" multiple times. It should instead use unique names.
Figure 2 below
illustrates the encoding of the first 7 octets of the first Extended
Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second
attribute (Foo(246,250) = "e end.") is encoded.
Hmm... So Foo(N,M) is a reference to the fragments? I don't see why
this is necessary. We don't do it for EAP-Message. I would suggest
just referring to it as "Foo", and "the first fragment (octets 0 through
245)", and "the second fragment (octets 246 through 250).
Consider the following structure:
What syntax is this? I think I understand it, but I'm not sure
everyone will come to a shared understanding. Maybe instead the example
can be given by reference to existing RADIUS data types. e.g. A
structure of RADIUS data types (integer, text, integer) would previously
have to be encoded as three separate and independent attributes. Here,
it can be encoded as 3 attributes sharing a common tag.
Reading the rest of the example, I find the b(4,5) syntax very
awkward. I suggest discarding it, and just referring to the diagrams.
The examples could also given broken-out hex encoding of the
attributes, which may be clearer than the ASCII art diagrams. e.g.
1a 0f 00 00 00 00 00 01 01 08 48 65 6c 6c 6f
7. Security Considerations
I suggest adding a note that a new attribute encoding is an
opportunity for buffer overflows, inadequate checks, etc. Implementors
SHOULD take care to validate the lengths, etc. before decoding the
contents of the attributes.
8. IANA Considerations
It also requires that IANA set up a new registry for the RADIUS
Extended Attribute Types.
I suggest leaving the first 0..255 attributes as unallocated, in order
to avoid confusion with legacy RADIUS attributes.
9. Open Issues
What is the numbering scheme for attributes that will be used by RFC
writers going forward? For example today we write user-name(1).
Uh... We do? I've never seen that in an RFC. I suggest deleting this
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.