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

[Denis Ovsienko <denis () ovsienko info>]

 ---- On Thu, 02 Aug 2018 15:06:50 +0100 Herwin <notifications () 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


_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers