rfc6929 radius ext - nested tlv format question

[Alan DeKok]

On Sep 24, 2015, at 4:47 PM, Vereecke, Katrien (Katrien) <katrien.vereecke at alcatel-lucent.com> wrote:

> Hello,
> 
> I have a question regarding the nesting of radius attributes according to rfc6929.
> 
> I am using the freeradius-server  version V3.0.x and I defined as test the following in my dictionary :
> ATTRIBUTE  Test-Attr-50     241.50  tlv
> ATTRIBUTE  Test-Attr-50_1   241.50.1 octets
> ATTRIBUTE  Test-Attr-50_1_2 241.50.1.2 string

  That dictionary is wrong.  The last attribute is a sub-TLV, but the parent isn't of type tlv.

  I've pushed a fix which causes the server to reject that dictionary, and refuse to start.

> These attributes are sent in the access-accept:
> (156) Sent Access-Accept Id 247 from 138.203.10.191:1812 to 138.203.10.123:64395 length 0
> (156)   Test-Attr-50_1 = 0x112233
> (156)   Test-Attr-50_1_2 = "testString50"
> 
> I expected that this would give problems because the attribute 241.50.1 is not defined as tlv in the dictionary, but the wireshark shows that the attribute includes both the octets for Test-Attr-50_1 and the nested attribute Test-Attr-50_1_2 .
> Is the above a valid configuration? When decoding this attribute, how can one distinguish whether 241.50.1 contains real data or again a nested attribute 241.50.1.2?

  You can't.  The dictionary is wrong, so the attributes are wrong, so the encoder does the wrong thing.  The encoder assumes that each VALUE_PAIR contains enough information to encode the VP.  If the data in the VP is wrong, the encoder will encode the data according to the wrong definition.

  Fixing the parser means that the dictionary is rejected, and the wrong VALUE_PAIR isn't create, and the encoder will then only encode the correct thing.

  Alan DeKok.