The Future of Middlebox Cooperation in the Internet Protocol Stack

As you may have read in our last post, the MAMI project is celebrating the hard-won, long-discussed consensus to add a spin bit to QUIC. The spin bit was conceived as the minimum useful explicit signal one could add to a transport protocol, and we think the benefit for the overhead is quite worth it. Though it exposes “just” RTT, latency (together with data rate, which is available in QUIC simply by counting packets and bytes on the wire) is possibly the most important metric for understanding transport layer performance diagnosing all matter of transport-relevant network problems, and the spin signal itself can also be observed to infer loss and other issues with network treatment of a packet stream. The definition and deployment of the spin bit is therefore a victory for making network protocols more measurable while preserving the privacy gains from encryption, and a victory for network operations and management.

When we started the MAMI project, we had a much more extensive vision for middlebox cooperation: our Path Layer UDP Substrate (PLUS) proposal provides a generalized signaling mechanism allowing signals from the sender to the path element, as well as a mechanism for allowing on-path elements to communicate information to the receiver (and back to the sender with the receiver’s assistance) in a safe, limited way, all with end-to-end integrity protection. However, we failed to achieve consensus to move forward in the IETF with this proposal by forming a working group, so we refocused our efforts on a more modest implementation of the explicit signaling concept.

Selective exposure, however, has a pretty toxic reputation in the IETF, as it “breaks” TLS, by adding a third-party to a two-party protocol and changing its security properties, reducing or eliminating integrity and confidentiality protection with respect to a set of entities in the network that may or may not be known to one or both endpoints. In our recently published white paper, the outcome of the M3S meeting, we argued that all approaches in this space must provide transparency and control to the endpoints.

In hindsight, more important to the controversy around PLUS was (in our opinion) a fundamental misunderstanding about what is meant by the term “middlebox cooperation”, as there are two broad approaches to supporting on-path operations on encrypted traffic being pursued in the industry:

  • Explicit signaling approaches like PLUS, where information about encrypted traffic is carried separately from the encrypted traffic itself.
  • Selective exposure approaches like mcTLS, mbTLS, eTLS and so on, which share secrets from the end-to-end cryptographic context with middleboxes, allowing them to decrypt (and in some cases, modify) traffic between the endpoints.

We focused on explicit signaling in MAMI, in part due to the difficulty of building selective exposure approaches that still provide useful security properties for the end-to-end communication. However, large parts of industry are more interested in selective exposure, because building and deploying selective exposure approaches promises to be more easily backward-compatible with existing protocols and network hardware. PLUS, after all, envisioned deploying a new transport protocol stack. We examine the tradeoffs in these approaches in another white paper, released today.

Among the arguments presented against PLUS at our BoF in Berlin in July 2016 were doubts that the protocol was safe in general: that it provided new side-channels for data exfiltration or hooks for coercion. We looked into this as part of our own internal study of integrity-protected, encrypted-payload middlebox cooperation approaches like PLUS, finding in a white paper, also released today, that the additional attack surface presented by PLUS is negligible.

The looming end of the project does not mean the end of the problems we set out to solve, or interest among the project participants and the field in general in improving privacy and evolvability through encryption while retaining limited support for in network functions. So, we ask ourselves: what’s next?

Several threads of work in this space will outlive MAMI:

Our efforts to add measurability to QUIC, which appears to represent the first real hope of deployable transport evolution in the last three decades, will of course continue. And QUIC itself will continue to evolve. The group of implementors and network folks we’ve helped pull together around the spin bit will keep experimenting with the best ways to make it possible to do passive measurement and diagnosis, as QUIC traffic increasingly supplants TCP.

Our work on experimentation with the Loss/Latency Tradeoff (LoLa) signal continues, as we noted in the previous blog bost. LoLa may enable better performance for real-time communications traffic and was first specified as a bit in the PLUS header continues, with a possible implementation as a DSCP codepoint.

The IRTF Path Aware Networking Research Group (PANRG), founded by the project, is pursuing work both in understanding why previous attempts to consider middleboxes in transport layer interactions have failed, and in exploring a set of properties of end-to-end paths on which future explicit signaling methods could be built.

Further, there is ongoing work on UDP options in the IETF TSVWG and a discussion about support for proxying of UDP-based, encrypted protocol started in the at IETF-103 with some initial presentations about requirements and use cases in the tsvarea session.

We are very happy that this important discussion is continued and that we as a project could provide a valuable input based on measurement and experimentation. And while the project’s time had to come to an end at some point, the MAMI contributors will keep working on this in order to keep the Internet operational as well as improve  its robustness in operation, performance, and security.

 

About Brian Trammell

Brian Trammell is an Internet measurement and architecture geek, a senior researcher at ETH Zürich's Networked Systems Group, and a member of the Internet Architecture Board.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply