PathVis: visualising traceroute for non-technical users

The need for path transparency

People use the internet without realising how their data packets move across it. For most users, communicating over the internet ‘just works’. This seamless behaviour has contributed to the huge success of the internet.

However, as a consequence, the internet does not provide users with insight as to how their data is sent from source to destination and how these paths change over time. Most of these changes are benign, such as a route change made when a switch breaks down and traffic has to be rerouted via another switch. However, some are malicious, such as route hijacks, and cause network traffic to be diverted to a third party.

Such a malicious change can be bad for the user’s privacy, because their network traffic may contain sensitive information, both in the meta data and in the primary data. Without the ability to check routing paths, users will be unaware that their data has been intercepted. Transparency on routing paths can provide users with greater insight, which may be desirable for many different reasons, such as:

• User privacy: for example to verify that user traffic is going through jurisdictions that implement the General Data Protection Regulation

• Data security: for example being notified when traffic is being rerouted

  through untrusted networks that may carry out a man-in-the-middle attack

• Supply chain security: just like with traditional supply chain security, organisations may want to establish the security of their network uplink suppliers too

• Data autonomy: provide tech-savvy individuals with greater insight into who handles their (encrypted) data

• Sustainability: in future scenarios, know the CO2 footprint of networks through which the Internet routes traffic

Path transparency itself cannot provide full details of, say, a network’s CO2 usage or hardware properties, but it provides internet users with knowledge of which networks their data passes through. It is up to the networks (autonomous systems) themselves to publish additional information.

Existing tooling: traceroute

The most popular tool for revealing routing paths on the internet is traceroute, which was originally developed in 1987. It can show the path to another internet destination and is part of virtually all operating systems, including Linux, macOS and Windows.

Traceroute works by incrementally increasing the time-to-live (TTL) fields in data packets. The TTL field specifies the number of hops after which a data packet should be dropped, thus preventing data packets from going around on the internet forever. A traceroute starts by sending a packet with a TTL value of 1, which will trigger a response from the first router on the path. Then, a packet with a TTL of 2 is sent, which will get a response from the second router that the packet encounters. By continuously increasing the TTL until the destination is reached, the routing path through the network can be mapped. Every router that receives a traceroute packet will decrease the TTL value by 1 before forwarding the packet to the next hop in the network. When the TTL field reaches 0, the packet is dropped, and the router returns an ICMP message to the sender.

An alternative tool for revealing routing paths is mtr, which works in a similar way, but continuously pings all intermediate hops.

Why traceroute is insufficient for path transparency

While traceroute is ubiquitously available, it is a tool for experts like network engineers, who know their way around command line interfaces. However, it is less appealing or informative for users such as service engineers, who use the internet’s end-to-end communication services rather than managing them.

Furthermore, traceroute only shows the current state of the path to a destination. To detect subsequent changes, the user must manually run traceroute again and compare the output with the previous output. Few users would be willing to do that for a single destination, let alone for multiple destinations.

Finally, an inherent limitation of traceroute is that the resulting view is one-way: only the route that data packets travel from the user to a destination is monitored. The return path of data packets may be different, but that can’t be measured with traceroute.

Other path tracing tools and their limitations

Beyond traceroute, there are other methods of monitoring how traffic is routed on the internet. Looking glasses provide information about routing tables on the internet. They are incredibly useful for detecting large-scale events on the internet such as route hijacks. However, they do not provide a complete picture of how a user’s traffic is routed across domains to other hosts.

Another tool is tracemon, which uses the RIPE Atlas network to visualise the paths from the probes to the host, which is useful if a service provider wants to optimise its reachability. However, like looking glasses, it does not provide a complete picture of the inter-domain path followed by a user’s data.

Looking at “clean slate” internet architectures, the SCION protocols do provide insight into the inter-domain paths of data packets. In SCION, the user can specify the path that a packet should take through the network ('path control'). SCION does that by adding an autonomous system-level (AS-level) path to the packet’s header, providing path transparency. The path information in the header is protected against illegitimate modification by means of Message Authentication Codes (MACs), which means that a host can verify the correctness of a data path. Although SCION has potential benefits for inter-domain communication (e.g. path control), it requires large-scale adoption before it is of practical value for increasing internet transparency.

Visual approach to path tracing using PathVis

We developed PathVis with the aforementioned requirements for path transparency, with users other than network engineers in mind. PathVis is a tool that visualises traceroutes for non-experts, while providing experts with additional information from public sources available on the internet. It is intended to demonstrate how a user’s network traffic travels across the internet.

Figure 1 shows the visualisation of routing information by PathVis. It refreshes the data regularly by rerunning traceroute for every open connection. PathVis then shows the active paths and uses a graph-like structure to show how the host system is connected to all its destinations with the hops in between.

Figure 1: a PathVis demonstration presented at the ECP conference

PathVis shows the origin host as ‘You’ at the top of the graph (in yellow at the top of Figure 1). The remote endpoints to which there are open connections are shown at the bottom of Figure 1 in orange. Connecting the origin and endpoints are intermediate hops, shown in the middle in blue. For each router, we show the autonomous system (AS) number, the internet Protocol (IP) address, and a small tick indicating ROA validity. Route Origin Validation is part of RPKI, which aims to secure routing on the internet.

When a path changes, PathVis records a change event and sends a notification to the user. The user can click on the notification to inspect the change to the network.

Collecting feedback: demonstrating PathVis at conferences

We have demonstrated PathVis at three conferences. We went to ICT.OPEN2022 and ACM SIGCOMM 2022, two conferences that bring academia and industry together. Additionally, we demonstrated PathVis at the ECP conference, which is frequented not only by technical folk, but also by many public policy makers and businesspeople, mostly from the Netherlands. This year’s ECP conference attracted around 800 people, some of whom visited our booth.

We presented our work at those conferences for two reasons. The first reason was that we wanted to use PathVis as a vehicle for starting a discussion about internet transparency, starting with questions such as:

• Can increased internet transparency benefit users?

• If so, which users benefit from increased internet transparency?

• Would improved transparency increase user trust, or decrease it by overwhelming the user with technical information?

We found that a PathVis visualisation is easier for most users to understand than plain traceroute, but still requires a lot of guidance and context. Most people agree that increased transparency can benefit internet users, but the presentation of transparency information can be overwhelming. Therefore, follow-up research is needed to investigate how such information can be presented in a way that avoids overwhelming users, but instead increases the user’s trust in the internet.

The second reason for making the demo was to gather feedback from participants about presenting transparency information in a way that people find useful. People who viewed the demo were therefore asked questions such as:

• What do you think of the information presented by PathVis and how it is presented?

• Is the information provided by PathVis useful?

The idea of path transparency attracted the interest of visitors, including the Dutch Minister of Economic Affairs, who dropped by our booth atthe ECP conference. We observed that people with less IT knowledge were mostly impressed by the visualization, as they were previously unaware how internet routing works. People with knowledge of computer networks of course noticed the similarities with traditional traceroute, but could appreciate the visualisation and the added information, such as AS numbers and RPKI information.

Conclusions and future work

The internet has limited support for monitoring paths and no support for controlling paths as an end user. With a view to addressing those limitations, we have created PathVis, a tool with more functionality than the existing traceroute. PathVis adds visualisation, continuous monitoring and the recording of changes to all currently open connections on an end-user system.

We plan develop methods for network operators to share specific information about their networks, which we could then visualize through PathVis. Moreover, we plan to use PathVis as a vehicle to demonstrate a new concept called the Autonomous System Information Service (ASIS), which we will introduce in a blog post next year.

In addition, to demonstrate PathVis more easily, we have developed a little tool called Router Spaghetti, which uses Linux Network Namespaces. We will publish a blog post about Router Spaghetti next year.

Finally, while we were working on PathVis, we noticed that having a well-defined data format that interfaces between computer programs (our PathVis visualisation tool, for example) and the underlying path tracing functions would be beneficial. Every path tracing tool has slightly different output, and having a universal data format would make it easier to automate functions based on the tools.

It’s open source!

PathVis is open source and available on GitHub. We have tested PathVis on Linux, macOS and OpenBSD; the tool also features untested Windows support. We encourage you to download PathVis, test it and send us feedback at sidnlabs@sidn.nl.

We are particularly interested in feedback from (and potentially collaborating with) researchers and operatorsworking on the evolution of the Internet infrastructure. We’re also interested in working with folks who would like to improve PathVis’ user interface design, because we’re not experts in that field.