The Internet has experienced a lot of change from its initial design.
One of its earliest principles was that the network is dumb — whereby routing devices would only care about the network layer and not about packet data — and endpoints are intelligent — they would freely add functionalities to protocols and applications. For example, TCP options are fields that endpoints may use to add new functionalities to TCP flows. This so-called end-to-end principle has the advantage of making the Internet flexible and extensible.
Figure 1 — The Internet has evolved from a simple end-to-end network to an over-complex beast.
However, over the last few decades, devices specifically designed and deployed to push intelligence into the network have been introduced, specifically middleboxes. Although these have been essential/necessary for today’s Internet ecosystem, assisting with everything from Network Address Translation (NAT) to complex traffic engineering systems, their means of action are in explicit violation of the end-to-end principle. These devices often make assumptions about the traffic passing through them, which has the effect of damaging Internet extensibility and flexibility and introducing the transport-layer ossification phenomenon.
Read: The trouble with NAT
Furthermore, they cripple the deployment of new TCP features and transport protocols, such as disabling unknown features by default and have also been shown to generate a multitude of connectivity and performance issues to existing features. For example, simply establishing TCP connections with Explicit Congestion Notification (ECN) enabled could lead to connectivity blackouts, and using the Selective Acknowledgement (SACK) option in the presence of a sequence number reshuffling middlebox could stall the connection.
Given the impact of these devices, it is surprising that little is known about how prevalent middleboxes are within the Internet, nor the percentage of traffic that is affected by them.
Path impairments
To go some way to answering this, my colleague and I at the University of Liège, recently conducted a bottom-up investigation to evaluate the prevalence of TCP/IP middleboxes in the Internet.
Our methodology leverages ICMP payloads to associate transport interferences shown in Figure 2 to 18,667 (2%) middleboxes out of a total 948,457 TCP/IP devices.
Among the 52.8 million paths probed by our algorithm, our detection method discovered that 20.5 million (38.9%) paths are crossing at least one middlebox. More precisely:
- 32.4% of these paths include a benign middlebox.
- 6.5% of these paths are potentially impaired.
- 0.1% of these paths involve a middlebox that blocks traffic, which in the absence of a fallback mechanism, results in a connectivity failure.
- 0.8% of these paths are broken as they include multiple impairments, that is, they have two or more disabled features disrupting traffic and negotiation. Finally, 5.6% of paths are affected by traffic disruption middleboxes.
The future of the transport layer: encryption?
Several recent transport initiatives have chosen to use UDP as a lightweight substrate for new protocols. However, the crucial choice that might seal the fate of middlebox-induced path brokenness is the encryption-by-default of transport headers.
On the one hand, QUIC, currently used by the Chrome browser and other applications, is a famous example of such protocol entrenchment. It incorporates a multiplexed stream transport over UDP, its own application-level transport, and it authenticates and/or encrypts chosen fields. By putting critical semantics out of reach of the middleboxes (and everyone else), QUIC-like approaches would effectively solve a significant portion of transport ossification.
Read: A quick look at QUIC
On the other hand, there is the example of the MultiPath TCP extension (MPTCP) feature, which required dedicated effort to consider all possible in-path tampering and avoid unforeseen middlebox impairments to ensure MPTCP middlebox-proofness. Still, it showed that it is possible to design a mostly middlebox-proof feature without relying on encryption.
As of 2017, QUIC traffic accounted for 7% of total Internet traffic. While adoption is slowly growing, in the meantime we advocate for protocol designers to include carefully designed fallback mechanisms to ensure robustness to each of the middlebox classes described in this paper, which despite not being ideal (due to the extra latency they can produce), prevent more serious failures.
Korian Edeline is a Post-Doc at the University of Liege, Belgium.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.