The increasing number of middleboxes (such as firewalls, NATs, proxies, or Deep Packet Inspection) has raised concerns over the impact of such middleboxes on the network and the possibility to innovate. As a result, operators and researchers are studying the distribution and behaviour of middleboxes in large networks. In this article, we will describe a tool called Tracebox that helps in detecting middleboxes. Tracebox was developed at the Université Catholique de Louvain (UCL) and at university of Liège (ULg) in 2013 and funded by Change (INFSO-ICT-257422), mPlane (ICT-318627), and Bestcom IAP. We believe that adding tracebox-like capabilities to RIPE Atlas could give network operators a deeper insight into their systems and help debugging network problems.
About the authors: Benoit Baufays and Julien Colmonts are students at UCL, working on our Master thesis on network measurements. One goal of our thesis is to re-run the measurements performed by Paxson on routing behaviour and to compare the results from 1995 with today's observations. We use Tracebox to extend the original analyses made in the nineties.
Detection of middleboxes
According to the RFC 3234 ("Middleboxes: Taxonomy and Issues"), a middlebox is defined as "any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and a destination host". The tool Tracebox will detect modifications made by such boxes to packets using a traceroute-like strategy: when a packet with Time-To-Live (TTL) value 0 reaches a router that follows the recommendation in RFC 1812 ("Requirements for IP Version 4 Routers"), the router sends back an ICMP time-exceeded message with the original IP packet header and the first 64 bits of its payload (containing source and destination ports, and sequence number for a TCP segment). Analysing the returned packet allows the detection of modifications by middleboxes.
Major vendors have recently updated their routers to be RFC1812-compliant, and in fact we observed in our experiments (see below) that in 96% of the cases, a path contains at least one router that replies with a full ICMP packet. In other words, tracebox has the potential to reveal the presence of middleboxes in 96% of the cases. Tracebox offers different options and even Lua bindings to control the header and payload of the probing packets, thus allowing the detection of various types of middleboxes. More details can be found in "Revealing Middlebox Interference with Tracebox." by G. Detal, B. Hesmans, O. Bonaventure, Yves Vanaubel and Benoit Donnet.
See below a short example to illustrate the workings of Tracebox. Let's say MB
1
be a middlebox, R
1
a router that is not RFC1812-compliant, and R
2
a router that is RFC1812-compliant. Tracebox will detect that a modification occurred between the source and R
2
. In our example, the
Maximum Segment Size
(MSS), initially set to 9000, has been changed.
A first look at RIPE Atlas anchors
When we used Tracebox as part of our Master thesis, the main objective was to take a first look at the RIPE Atlas infrastructure and to test some well-known IP and TCP options. We used Tracebox to test the path from our home (Louvain-La-Neuve, Belgium) to each of the 106 RIPE Atlas anchors. To date, only IPv4 has been tested, because IPv6 is currently not enabled at our home.
Out of the set of header fields and options that we tested, a first run of experiments revealed modifications of the
IP TTL
field, the IP differentiated services code point (
DSCP
) field, and the
TCP MSS
option. The following table shows the number of reported modifications with hops sorted by distance from the destination. For each RIPE Atlas anchor, we looked at the 10 hops closest to the destination.
| Modification | Hop 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| IP:TTL | 84 | 86 | 88 | 83 | 80 | 84 | 89 | 79 | 77 |
| IP::DiffServiceCP | 24 | 32 | 28 | 26 | 20 | 19 | 15 | 8 | 4 |
| TCPOptionMaxSegSize::MaxSegSize | 13 | 17 | 25 | 24 | 28 | 30 | 31 | 35 | 40 |
TTL field:
Our measurements show that, in 90% of the cases, the TTL values decrease by one or two, which is the expected behaviour. The remaining 10% indicate middleboxes decrementing the TTL value or tunnels which are hidden from traceroute.
DSCP field:
We observed that in some cases the DSCP field was modified from 0 (normal priority; default value set by Tracebox) to 8, i.e., to a higher priority. To study this phenomenon further, we performed a second experiment: we sent packets with a DSCP value of 20 to all destinations that experienced a DSCP modification during the first experiment. Interestingly, we didn't see more modifications in this experiment than in the first experiment. This is an important observation, because one could imagine that a transit network doesn't want to trust packets marked outside its network. This observation must be confirmed later with a bigger set of IP addresses.
MSS option:
We also observed modifications of the MSS option. To study this further, we performed another experiment where we sent packets with a high MSS value of 9000. Often, middleboxes modify the MSS value to fix issues with the MTU discovery process created by other middleboxes. The MTU discovery process is based on ICMP destination-unreachable packets, and sometimes middleboxes do not correctly forward these packets. To fix this issue, middleboxes change the value of the MSS or set it directly to the packet size. But as written in related literature (tracebox paper), "in an Internet that respects the end-to-end principle, this option should never be modified". We observe that 50% of the modifications are MSS modifications in a distance of 10 hops from the destination.
Future Steps
Tracebox can be configured to detect different kinds of middleboxes, such as proxies or NATs. Amongst others, we are interested in analysing how middleboxes might impact the large-scale introduction of Multipath-TCP (MPTCP) by modifications of MPTCP-related options, especially the MPCAPABLE option. This requires us to also test the downstream direction for modifications of SYN+ACK packets.
Conclusion and final remarks
Introducing new technologies and protocols in large networks requires an understanding of how routers and middleboxes respond to new packet options. Tracebox is the right tool for this, because it will help to detect a lot of errors that were hidden or misunderstood. Modified TCP options, presence of firewalls, proxies, or NAT's can be detected with this tool. In cases where new technologies are being added, such as MPTCP, the tool can give an evaluation of how a large-scale network is reacting to new messages or packet options. Currently, Tracebox is a stand-alone tool. We believe that it would be interesting for the RIPE community to have Tracebox-like capabilities in RIPE Atlas. We would be happy to receive feedback from the RIPE community and especially from operators on this
.
Comments 1
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Simon Leinen •
DSCP=8 doesn't necessarily mean "higher priority". In fact, some networks such as GÉANT use it (or at least did so in the past) for "Lower than Best-Effort" (LBE) service. Some ISPs also use DSCPs other than zero to mark certain kinds of traffic for accounting. For example, one can mark all traffic coming in over expensive links with some DSCP on a transit router, and then use that to measure this traffic further downstream, e.g. at a customer access router, to bill the customer specially for this expensively-routed traffic. Or even if it is not billed separately, the ISP may still want to measure this e.g. for traffic planning/management.