rfc6929 - tlv attributes in extended attribute 246

Mon Apr 4 15:09:02 CEST 2016

Hello,

I see a difference in behavior for a tlv attribute in an extended attribute 246 in FreeRadius version 3.0.x and FreeRadius version 3.1.x.

My dictionary contains the following attributes:
BEGIN-VENDOR    Alcatel-IPD format=Extended-Vendor-Specific-6
ATTRIBUTE Alcatel-IPD-Ext-6-TestAttr-1  1  integer
ATTRIBUTE Alcatel-IPD-Ext-6-TestAttr-2  2  string
ATTRIBUTE Alcatel-IPD-Ext-6-TestAttr-3  3  tlv
ATTRIBUTE Alcatel-IPD-Ext-6-TestAttr-3-1  3.1 string
ATTRIBUTE Alcatel-IPD-Ext-6-TestAttr-3-2  3.2 tlv
ATTRIBUTE Alcatel-IPD-Ext-6-TestAttr-3-2-1  3.2.1 string
END-VENDOR      Alcatel-IPD

I have the following attributes in my users file:
Alcatel-IPD-Ext-6-TestAttr-2 = "test3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLenAttention",
Alcatel-IPD-Ext-6-TestAttr-3-1 = "testattr_3_1",
Alcatel-IPD-Ext-6-TestAttr-3-2-1 =  "testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1",

The output of the freeRadius server in version 3.0.x :
The access-Accept message:
(2) Sent Access-Accept Id 14 from 138.203.10.191:1812 to 138.203.10.123:64388 length 0
....
.....
(2)   Alcatel-IPD-Ext-6-TestAttr-2 = "test3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLente"
(2)   Alcatel-IPD-Ext-6-TestAttr-3-1 = "testattr_3_1"
(2)   Alcatel-IPD-Ext-6-TestAttr-3-2-1 = "testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr"

The output of the FreeRadius server in version 3.1.x:
(0)    Alcatel-IPD-Ext-6-TestAttr-2 = "test3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLentest3FragWithLongLente"
(0)    Alcatel-IPD-Ext-6-TestAttr-3-1 = "testattr_3_1"
(0)    Alcatel-IPD-Ext-6-TestAttr-3-2-1 = "testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr_3_2_1testAttr"

Although the output of the FreeRadius server shows the same output in version 3.0.x and version 3.1.x , wiresharks shows that there is a difference in the access-accept packet sent,
In version 3.0.x the packet contains all the information for the tlv attribute  Alcatel-IPD-Ext-6-TestAttr-3_xx while in version 3.1.x I only see the attribute Alcatel-IPD-Ext-6-TestAttr-3-1.

Wireshark for version 3.0.x:
Frame 623: 1223 bytes on wire (9784 bits), 1223 bytes captured (9784 bits) on interface 0
Ethernet II, Src: SuperMic_a2:12:54 (00:25:90:a2:12:54), Dst: SuperMic_57:a0:76 (00:25:90:57:a0:76)
Internet Protocol Version 4, Src: 138.203.10.191, Dst: 138.203.10.123
User Datagram Protocol, Src Port: 1812 (1812), Dst Port: 64388 (64388)
RADIUS Protocol
    Code: Access-Accept (2)
    Packet identifier: 0xe (14)
    Length: 2661
    Authenticator: a01937c98d28165fc4c238e5cd8867cd
    [This is a response to a request in frame 615]
    [Time from request: 0.000860000 seconds]
    Attribute Value Pairs
        AVP: l=7 t=Unknown-Attribute(241): 060000003c
        ....
        AVP: l=255 t=Unknown-Attribute(246): 1a800000197f02746573743346726167576974684c6f6e67...
        AVP: l=147 t=Unknown-Attribute(246): 1a00726167576974684c6f6e674c656e7465737433467261...
        AVP: l=255 t=Unknown-Attribute(246): 1a800000197f03010e74657374617474725f335f3102ff01...
        AVP: l=27 t=Unknown-Attribute(246): 1a00417474725f335f325f3174657374417474725f335f32...
        AVP: l=7 t=Unknown-Attribute(243): 0b00000005
        AVP: l=7 t=Unknown-Attribute(243): 0b00000006
       ....
        AVP: l=11 t=Reply-Message(18): Welcome!\n

Wireshark for version 3.1.x:
Frame 516: 638 bytes on wire (5104 bits), 638 bytes captured (5104 bits) on interface 0
Ethernet II, Src: SuperMic_a2:12:54 (00:25:90:a2:12:54), Dst: SuperMic_57:a0:76 (00:25:90:57:a0:76)
Internet Protocol Version 4, Src: 138.203.10.191, Dst: 138.203.10.123
User Datagram Protocol, Src Port: 1812 (1812), Dst Port: 64384 (64384)
RADIUS Protocol
    Code: Access-Accept (2)
    Packet identifier: 0xf (15)
    Length: 2076
    Authenticator: 4545fca0176c445525748ced32857ae1
    [This is a response to a request in frame 502]
    [Time from request: 0.003358000 seconds]
    Attribute Value Pairs
        AVP: l=7 t=Unknown-Attribute(241): 060000003c
        ....
        AVP: l=255 t=Unknown-Attribute(246): 1a800000197f02746573743346726167576974684c6f6e67...
        AVP: l=147 t=Unknown-Attribute(246): 1a00726167576974684c6f6e674c656e7465737433467261...
        AVP: l=23 t=Unknown-Attribute(246): 1a000000197f03010e74657374617474725f335f31
        AVP: l=7 t=Unknown-Attribute(243): 0b00000005
        AVP: l=7 t=Unknown-Attribute(243): 0b00000006
        ....
        AVP: l=11 t=Reply-Message(18): Welcome!\n

I think the behavior of the FreeRadius version v3.0.x is ok.  The access-accept contains the attribute Alcatel-IPD-Ext-6-TestAttr-3-1 and the attribute Alcatel-IPD-Ext-6-TestAttr-3-2-1 is partially in the first fragment and in the second fragment for the max length of 255 bytes.
This is not the case in FreeRadius version v3.1.x?

Thanks,
Kind regards,
Katrien.