rfc6929 : combination extended-type/long-extended-type and TLV data type
Hello, I am using freeradius server version V3.0.x. According to rfc6929 the combination of a extended or long-extended-type and tlv-data type is allowed. The rfc states that the TLV-length must have a value between 3 and 255, but is this correct in case of an extended or long extended type , should it then not be respectively 252 and 251 max? I was testing the TLV data type and long extended type, I defined in my dictionary the following: ATTRIBUTE Test-Attr-261-11 246.11 tlv ATTRIBUTE Test-Attr-261-11-1 246.11.1 octets And in my users file I included Test-Attr-261-11-1 = 0x00112233445566aabbccddeeff0011223344.......... => with a length more than 300 octets In the wireshark I see that the attribute is fragmented but the length-attr and the tlv-length are both set to ff and the second fragmented part does only contain the octets up till data length 255, not all octets specified in my users file. Is this correct? Wireshark output : f6 ff 0b 80 01 ff 00 11 22 33 44 55 ..... f6 08 0b 00 99 aa bb cc ... Thanks, Kind regards, Katrien.
On Nov 10, 2015, at 5:41 AM, Vereecke, Katrien (Katrien) <katrien.vereecke@alcatel-lucent.com> wrote:
According to rfc6929 the combination of a extended or long-extended-type and tlv-data type is allowed. The rfc states that the TLV-length must have a value between 3 and 255, but is this correct in case of an extended or long extended type , should it then not be respectively 252 and 251 max?
When the TLV is encapsulated in another attribute, yes... the allowed length is smaller than 255.
I was testing the TLV data type and long extended type, I defined in my dictionary the following: ATTRIBUTE Test-Attr-261-11 246.11 tlv ATTRIBUTE Test-Attr-261-11-1 246.11.1 octets
And in my users file I included Test-Attr-261-11-1 = 0x00112233445566aabbccddeeff0011223344.......... => with a length more than 300 octets
Which is allowed by the server internally, as it can handle arbitrary length data.
In the wireshark I see that the attribute is fragmented but the length-attr and the tlv-length are both set to ff and the second fragmented part does only contain the octets up till data length 255, not all octets specified in my users file. Is this correct?
Yes. The RADIUS encoder truncates the data to the maximum allowed length. It does this for *all* attributes. Try setting large values for User-Name, or Class. The same thing will happen. Alan DeKok.
Hello, I understand that for 'normal attributes' the Radius encoder truncates the data to the max allowed. But, if I use the long-extended type 246 with the More bit set then my understanding is that it would not be truncated on the 255 bytes of data. I see a difference in behavior for e.g 246.5 and 246.11.1 which both contain 320 bytes of data in my users file. 246.5 is not truncated, all data is available, fragmented over two attributes while 246.11.1 is truncated at 255 bytes, not all data is available. Dictionary : ATTRIBUTE Test-Attr-246-5 246.5 octets ATTRIBUTE Test-Attr-246-11 246.11 tlv ATTRIBUTE Test-Attr-246-11-1 246.11.1 octets Kind regards, Katrien. -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+katrien.vereecke=alcatel-lucent.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Tuesday, November 10, 2015 15:49 To: FreeRadius users mailing list Subject: Re: rfc6929 : combination extended-type/long-extended-type and TLV data type On Nov 10, 2015, at 5:41 AM, Vereecke, Katrien (Katrien) <katrien.vereecke@alcatel-lucent.com> wrote:
According to rfc6929 the combination of a extended or long-extended-type and tlv-data type is allowed. The rfc states that the TLV-length must have a value between 3 and 255, but is this correct in case of an extended or long extended type , should it then not be respectively 252 and 251 max?
When the TLV is encapsulated in another attribute, yes... the allowed length is smaller than 255.
I was testing the TLV data type and long extended type, I defined in my dictionary the following: ATTRIBUTE Test-Attr-261-11 246.11 tlv ATTRIBUTE Test-Attr-261-11-1 246.11.1 octets
And in my users file I included Test-Attr-261-11-1 = 0x00112233445566aabbccddeeff0011223344.......... => with a length more than 300 octets
Which is allowed by the server internally, as it can handle arbitrary length data.
In the wireshark I see that the attribute is fragmented but the length-attr and the tlv-length are both set to ff and the second fragmented part does only contain the octets up till data length 255, not all octets specified in my users file. Is this correct?
Yes. The RADIUS encoder truncates the data to the maximum allowed length. It does this for *all* attributes. Try setting large values for User-Name, or Class. The same thing will happen. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 10, 2015, at 10:31 AM, Vereecke, Katrien (Katrien) <katrien.vereecke@alcatel-lucent.com> wrote:
I understand that for 'normal attributes' the Radius encoder truncates the data to the max allowed.
*All* attributes are normal attributes. *All* attributes are truncated to the maximum allowed.
But, if I use the long-extended type 246 with the More bit set then my understanding is that it would not be truncated on the 255 bytes of data.
If you have an attribute "264.5" of type "octets", it can encode more than 253 bytes of data. This does *not* apply to TLVs. A TLV attribute has an 8 bit length. This means that it can encode a maximum of 253 bytes of data. BUT if a TLV is contained in another attributes which is *also* less than 253 octets, then the TLV length is limited by the attribute which encapsulates it. This isn't complicated. An attribute having maximum length of 253 means that any data carried inside of that attribute can be no more than 253 bytes.
I see a difference in behavior for e.g 246.5 and 246.11.1 which both contain 320 bytes of data in my users file. 246.5 is not truncated, all data is available,
Because it can be encoded as multiple fragments.
fragmented over two attributes while 246.11.1 is truncated at 255 bytes, not all data is available.
Because it's a TLV. The TLV-Length is at most 253 bytes. How do you expect a TLV to encode 320 bytes in a field which can contain only 253 bytes? And How do you encode the number "320" into a field which is 8 bits? 8 bits only goes to 255... RFC 6929 discusses this. You *cannot* have "long" attributes inside of a TLV. For the "evs" data type, we specifically chose to *not* include a length. This means that vendor-specific attributes in the "long" space can encode more than 253 bytes in a VSA. Alan DeKok.
participants (2)
-
Alan DeKok -
Vereecke, Katrien (Katrien)