[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Hello,
a few comments:
TLV encoding and M flag: All examples stuff the maximum payload into the first fragment, set the M bit and put the remainder into the next fragment. This is fine and sensible, but not enforced in the description.
One might also do any other split of the data, like if there is a 300 byte data to be transmitted, 150 in the first fragment, 150 in the second.
There also is no clarification whether fragmenting should only occur when it is needed. Without requiring this, a compliant implementation could as well split the 5-byte data "Hello" into five fragments. I suggest to add a bit of wording to strongly discourage that.
TLV encoding rules: Ext-Length field misses its unit ... (in octets)...
Example in Figure 3: VSA Length. 7 + 9 = 16, not 15.
Figure 4:
- is it worth mentioning that this encoding is not the only one possible, since the order of the struct members doesn't need to be preserved during marshalling?
- There is a one-off in the encoding of String b. b is 251 octets, i.e. comprised of b[0] thru b[250].
The first fragment can (correct in the figure) hold up to 245 characters, i.e b[0] thru b[244]. Six(!) characters remain, b[245] thru b[250]. The encoding of the second fragment needs to be changed for a TLV data length of 6, which also changes Ext-Length to 3 + 6 = 9 and VSA-Length to 7 + 9 + 7 = 23. The byte-order of the last integer is odd, it looks like the last two bytes are swapped. This is neither big- not little-endian, and I suspect it's an error.
A corrected figure is below:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor-Id
| | (7+9+7=23) | (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type
(0) |0| (42) | (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | |
(259) | (3 + 6 = 9) | (e) | ( ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| (e) | (n) | (d) | (.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont) Ext-type (cont)| Ext-Length | |
(0) (271) | (3 + 4 = 7) | (0x12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| (0x34) | (0x56) | (0x78) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Some nitbits:
- Intro: "101 or so have been". Or so sound a bit colloquial.
- first example: "Extended-Type *of* 257 by IANA." ( not 0f)
Finally, Security Considerations: This section is rather short, I suggest to expand the "TBD" :-)
Greetings,
Stefan Winter
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
--
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/>