ICMP Extensions

[fujiapple852]

Tracking issue for ICMP Extensions.

Add support for generic Ipv4 & Ipv6 ICMP extensions, with specific parsing for:

• Add support for parsing ICMP extensions in IPv4/IPv6 #751
• Add support for MPLS Label Stack Class ICMP Extension Object #753
• Add support for Interface Information ICMP Extension Object
• Add support for Interface Identification ICMP Extension Object
• Add support for Extended Information ICMP Extension Object
• Add additional tests for non-compliant ICMP Extension Object cases
• Add support for ICMP Extensions in Tui #752
• Add support for ICMP Extensions in tracing backend #807
• Add support for ICMP extensions in reports #806
• Investigate unusual MPLS example #804
• Add support for IPv6 Extensions in splitter

[ytti]

Or perhaps more generic EO support.

https://www.rfc-editor.org/rfc/rfc5837.html
https://github.com/8enet/traceroute/blob/master/traceroute/extension.c#L101
https://lore.kernel.org/all/[email protected]/T/
https://www.juniper.net/documentation/us/en/software/junos/transport-ip/topics/topic-map/icmp.html

This would allow you to for example report latency and loss per LAG member, as well as discover which keys are hashed to which path.

[fujiapple852]

Thanks for the suggestion and links @ytti.

I agree that Trippy should target supporting a larger set of ICMP extension objects and not focus solely on MPLS.

I must confess I haven't spent much time looking at these extension, mainly as I've observed that they are seldom used on public networks, perhaps they are used more within private networks? What has been your experience of how these extensions are used in practise and what useful insights they can provide?

Once added, how would you imagine this data would be used within Trippy?

The easiest thing to do would be to support them generically and simply render the data somehow (perhaps in the expanded hop detail navigation view?). This appears to be the approach taken in the example traceroute code you linked.

Beyond that, Trippy could be aware of specific Extension Objects, such as MPLS and the "Interface Information Object" defined in rfc 5837, such that it could do more semantically useful things with the data, such as "report latency and loss per LAG member" as you suggest. I think this would be more useful, but only if the majority of hops in the path provide the extended data.

As a start, the Trippy net code needs to be able to parse ICMP Extension Objects (Multi-Part Messages) as defined in rfc4884. This is something I can do, unless you were keen to work on this yourself?

[fujiapple852]

Also do you know of any public hosts which include "Interface Information Object" EO in ICMP TimeExceeded messages? This is very useful for development.

I did manage to find an example host which provides MPLS EO: 129.250.2.50

[ytti]

I do not, I hope it'll become more common but currently as far as I know, only Juniper QFX5k does it. I have some reasons to expect that wider availability is coming.

[fujiapple852]

@ytti I have some (very rough!) WIP code up in #696 that parses ICMP extensions (v4 only for now) generically. For now it just prints out any extension object(s) found for each ICMP TimeExceeded or DestinationUnreachable response.

It supports both compliant and non-compliant ICMP extensions as per section 5 of rfc4884.

Example (the only one I can find in the wild, a non-compliant MPLS extension):

extension header: version=2, checksum=39226
extension object: length=8, class_num=MultiProtocolLabelSwitchingLabelStack, class_subtype=ClassSubType(1), payload=04 bb 41 01

Next up, I'm going to add parsing for the four classes with assigned numbers.

After that is icmp V6 extensions and then some thought about how to display the information in the TUI. This will also need some new command line config to enable/disable extension parsing and rendering.

It'll also need to be thoroughly tested on all platforms due to weirdnesses of the way some platforms treat some Ipv4 fields (i.e. total_length) in raw socket mode that are important here. Without a source of extensions to test against it may be impossible to test the Interface Information Object, Interface Identification Object & Extended Information objects, beyond syntactic test data.

[ytti]

Sounds very good indeed. And I believe this is right approach, in the quoted traceroute URL we can see similar approach. Where as mtr takes opposite strategy, and implements MPLS labels as its own specific thing, making it much harder for next person to add pretty printing of new extensions.

The MPLS example while not pretty printed, is very useful example how unrecognised data can be printed, and pretty printing can be added once someone explains what the data is and how it could be used to enrich UX.

Many thanks!

[fujiapple852]

@ytti progress...

Only rendering a single MPLS label/ttl for now, but the plumbing is there to add any/all extensions.

We'll need to think how best to render these in the Tui and textual report modes given:

• Each hop (ttl) can have multiple hosts (so do we show the union of extension objects per hop or per host?)
• Each host receives multiple probe responses (i.e. one per round), each of which may or may not have extensions (so would these extensions accumulate over the rounds or would they be removed if they do not appear in a round?)
• Each probe response can contain multiple extensions, of various types (mpls, Interface Information Object, unknown, etc)
• Specifically for MPLS, each stack can contain multiple members (i.e. labels), so we'd need to show them all. Each member has a label, a ttl, an exp which we can show.

It feels like we need to render a tree structure here.

Edit: moved the Tui discussion to #752

[fujiapple852]

Need to test if the label extraction is accurate (matches Wireshark on MacOS but seems to differ from tcpdump on Linux, maybe an endianness thing?)

[fujiapple852]

@ytti do you know anyone who would be able to help diagnose the issue I describe in #804? I'm unsure which of tcpdump or Wireshark is interpreting it correctly (the differ!). My reading of rfc4884 is that Wireshark is interpreting it correctly, as I apply the same logic in Trippy and get the same result. However there is clearly an MPLS extension present and tcpdump does manage to parse it out, somehow.

[fujiapple852]

Code was merged and can be found here along with all test cases: https://github.com/fujiapple852/trippy/blob/master/src/tracing/packet/icmp_extension.rs#L804