[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Alan DeKok <mailto://email@example.com> writes:
> Section 4:
> 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.
OK, are you saying that the existing text isn't clear? It seems pretty
precise to me, should it be more vague (e.g., "long" & "short")?
> Section 5:
> M (More)
> 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
> 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.
> 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 the following structure:
> Integer a;
> String b;
> Integer c;
> What syntax is this? I think I understand it, but I'm not sure
> everyone will come to a shared understanding. Maybe instead the
> can be given by reference to existing RADIUS data types. e.g. A
> structure of RADIUS data types (integer, text, integer) would
> have to be encoded as three separate and independent attributes.
Previously, such a structure was impossible to encode in RADIUS.
> it can be encoded as 3 attributes sharing a common tag.
Or as 3 TLVs in a single attribute (depending upon the length of the string.
> 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.
Actually, I'd just as soon discard the examples: this draft has way too much
flavor of a tutorial for my taste...
> 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
You're joking, right?
> 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
> to avoid confusion with legacy RADIUS attributes.
Presumably the people who would get confused are those who have to be told
to protect against buffer overflows (& send "hello" as five separate
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.