[tcpdump-workers] [the-tcpdump-group/tcpdump] Added RADIUS attributes from RFC 5447 (#636)

Denis Ovsienko denis at ovsienko.info
Thu Aug 2 13:03:37 EDT 2018


 ---- On Thu, 02 Aug 2018 15:06:50 +0100 Herwin <notifications at github.com> wrote ---- 
 > @herwinw commented on this pull request.
 >   
 >   In print-radius.c:
 >  > @@ -569,6 +597,8 @@ static struct attrtype {      { "Digest-HA1",                      NULL, 0, 0, print_attr_string },      { "SIP-AOR",                         NULL, 0, 0, print_attr_string },      { "Delegated-IPv6-Prefix",           NULL, 0, 0, print_attr_netmask6 },+     { "MIP6-Feature-Vector",             NULL, 0, 0, print_attr_vector64 },+     { "MIP6-Home-Link-Prefix",           NULL, 0, 0, print_attr_netmask6 }, fun fact: freeradius and wireshark both use the same format as Framed-IPv6-Prefix and Delegated-IPv6-Prefix for this structure. This might require some "be liberal in what you accept" to make it work.


The IANA RADIUS Types registry currently lists 6 types with the "ipv6prefix" type:
```
170 Route-IPv6-Information [RFC6911]
152 PMIP6-Visited-HN-Prefix [RFC6572]
151 PMIP6-Home-HN-Prefix [RFC6572]
125 MIP6-Home-Link-Prefix [RFC5447]
123 Delegated-IPv6-Prefix [RFC4818]
97 Framed-IPv6-Prefix [RFC3162]
```
The type 125 (MIP6-Home-Link-Prefix) is the only one that has the encoding clearly different from the rest. This is how RFC 5447 defines it, and the current list of errata for this RFC does not concern this difference, which looks intentional as Section 4.2.4 of the spec says: "The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString" and the IANA Considerations section does not mention the type explicitly.

It looks like the allocation in the IANA registry was done incorrectly for type 125, perhaps because the attribute has "prefix" in its name. Then, if the authors of respective Wireshark and FreeRADIUS code took the attribute type from the registry and did not check it thoroughly in RFC 5447, that would explain why that code (incorrectly) handles MIP6-Home-Link-Prefix as an IPv6 prefix attribute (whereas it is OctetString) -- it just copies the error in the registry allocation.

I do not see a good way to accept both encodings for this attribute, given the way each encoding is defined. Are you aware of any other code that has copied this error, especially in the network devices firmware?

-- 
    Denis Ovsienko




More information about the tcpdump-workers mailing list