Two-way path tracing on the internet with trace-ssh

Visualising traceroutes

We recently introduced PathVis (short for Path Visualiser), a tool for visualising traceroutes. Traceroute is a standard tool available on almost all operating systems, and is widely used to obtain information about the route taken by packets on the internet, including the networks and IP addresses along the way to a specific destination host. For example, researchers use it to see which networks are connected and network operators use it to debug connectivity issues.

While traceroute provides details on the forward paths of active connections from source to destination, it has a significant limitation: it does not cover the reverse path back from the destination to the source. Having that information is important because return paths frequently differ from the corresponding forward paths. With just the latter, you may not see every network that your packets pass through.

So, to get details of both paths, we would somehow need to initiate two separate traceroutes, one from the source to the destination and another from the destination back to the source, which requires access to the remote system.

Getting details on forward and return paths through trace-ssh

To demonstrate the value of a reverse traceroute, we developed a prototype script called trace-ssh. It shows live traceroutes for both the forward and the reverse paths of a running SSH session. When you use trace-ssh to log into a remote machine, you can see to what extent the path taken by your SSH packets is the same in both directions.

Figure 1 illustrates the concept, with the main SSH session in the left window, a live traceroute to the destination in the top right window, and a live traceroute from the destination to the source in the bottom right window. It shows that the forward path in this example is different from the return path (the actual hosts are blurred, but some have different numbers, and their names are different lengths, though in this particular case the differences are minimal).

Figure 1. Screenshot of a trace-ssh session.

Towards general reverse traceroutes

The limitation of trace-ssh is that it only works with machines you have SSH access to and that have trace-ssh installed. It is also not very useful for debugging connectivity issues, since it only works if you have an active ssh connection.

To show the reverse path to any system on the internet, we would need to add tracing information to IP packet headers or use a specific ICMP packet that is sent back to the sender and updated with information from each hop along the way. That would require updating every router on the internet.

One step towards such a general solution is the Reverse Traceroute project, which defines a method for passing on traceroute information in a new ICMP packet. That information is collected and sent to interested parties by special reverse traceroute servers. While it is limited to reverse traceroutes from hosts that implement the protocol, it can be deployed gradually and does not require a significant change in the way routers on the internet operate.

The developers of the Trace Route project submitted their work to the IETF as an Internet Draft, and we hope it will come through. In the meantime, we hope you’ll find trace-ssh useful. :-)

Try it!

If you want to play around with trace-ssh, then download it here. You need to have tmux (a terminal multiplexer) installed on your local system and mtr installed on both the local and remote systems. We also recommend using SSH public key authentication, as trace-ssh requires two separate SSH sessions. By default, the mtr sessions display autonomous system (AS) numbers, the country of the AS, and either the host names or IP addresses of the intermediate hops, but the script can easily be modified to suit your preferences.