RFC 7663

Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)

📅 published October 2015, from ietf

RFC 7663: Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) 🦋

  • Request for Comments: 7663
  • Authors: B. Trammell, Ed. and M. Kuehlewind, Ed. (both from ETH Zurich) 🎀
  • Published by: Internet Architecture Board (IAB)
  • Category: Informational
  • ISSN: 2070-1721
  • Date: October 2015

Abstract ✨

okay so the IAB, through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich teamed up to host the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015. 💅 The big question was how we can keep evolving the transport layer when middleboxes and interfaces have basically frozen the whole stack in place. The goal was to produce architectural and engineering guidance to break the logjam 🔥, focusing on approaches that can be deployed bit by bit and that give both endpoints (new transport layers and applications) and middleboxes (run by network operators) a clear reason to actually adopt them.

This document recaps what people contributed to the workshop, walks through the discussion, and lists the outcomes and next steps the workshop identified. ngl the views and positions in here belong to the workshop participants. They do not necessarily reflect the IAB's views and positions. 🫶

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes. 🌸

This document is a product of the Internet Architecture Board (IAB). It holds information the IAB has decided is worth keeping on the permanent record, and it represents the consensus of the IAB. Documents the IAB approves for publication are not candidates for any level of Internet Standard. See Section 2 of RFC 5741 for more on that.

For current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7663. ✨

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, bestie, because they spell out your rights and restrictions for this document. 🙏

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Organization of This Report . . . . . . . . . . . . . . .   4
2.  The Situation in Review . . . . . . . . . . . . . . . . . . .   4
3.  Incentives for Stack Ossification and Evolution . . . . . . .   5
4.  The Role and Rule of Middleboxes  . . . . . . . . . . . . . .   6
5.  Evolving the Transport Layer  . . . . . . . . . . . . . . . .   6
6.  Outcomes  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
  6.1.  Minimal Signaling for Encapsulated Transports . . . . . .   7
  6.2.  Middlebox Measurement . . . . . . . . . . . . . . . . . .   8
  6.3.  Guidelines for Middlebox Design and Deployment  . . . . .   9
  6.4.  Architectural Guidelines for Transport Stack Evolution  .   9
  6.5.  Additional Activities in the IETF and IAB . . . . . . . .  10
  6.6.  Additional Activities in Other Venues . . . . . . . . . .  10
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
8.  Informative References  . . . . . . . . . . . . . . . . . . .  10
Appendix A.  Attendees  . . . . . . . . . . . . . . . . . . . . .  13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1. Introduction ✨

okay the transport layer of the Internet has become seriously ossified 💀. It's squeezed between narrow interfaces (everything from BSD sockets to pseudo-transport over HTTPS) and a growing pile of in-network changes to traffic from middleboxes that make assumptions about the protocols running through them. That ossification makes it really hard to innovate at the transport layer, whether by deploying new protocols or extending existing ones. Meanwhile, emerging applications need things that current protocols can only do inefficiently, if they can do them at all. 😭

So the IAB, as part of its IP Stack Evolution Program, organized a workshop to figure out how to de-ossify transport, especially when it comes to interactions with middleboxes and new ways of implementing transport protocols. We know the end-to-end principle has been compromised for a while now, so we're starting from the basic question: how do we match the paths through the Internet that have certain characteristics with what applications and transports actually need? 🧚

The call for papers asked these questions:

  • Which paths through the Internet are actually available to applications?
  • Which transports can be used over these paths?
  • How can applications cooperate with network elements to improve path establishment and discovery?
  • Can common transport functionality and standardization help application developers implement and deploy such approaches in today's Internet?
  • Could cooperative approaches give us a way to rebalance the Internet back toward its end-to-end roots? 🌸

The call for papers also encouraged a focus on approaches that can be deployed incrementally within the present Internet. The topics it named were:

  • Development and deployment of transport-like features in application-layer protocols
  • Methods for discovery of path characteristics and protocol availability along a path
  • Methods for middlebox detection and characterization of middlebox behavior and functionality
  • Methods for NAT and middlebox traversal in the establishment of end-to-end paths
  • Mechanisms for cooperative path-endpoint signaling, and lessons learned from existing approaches
  • Economic considerations and incentives for cooperation in middlebox deployment 💅

The Internet Architecture Board (IAB) holds occasional workshops to look at long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning is complementary to the ongoing engineering work done by IETF working groups, under the leadership of the Internet Engineering Steering Group (IESG) and the area directorates. 🎀

SEMI partly grew out of the IAB's longer-term interest in how the Internet evolves and how Internet protocols get adopted. That includes the Internet Technology Adoption and Transition workshop [RFC7305], "What Makes for a Successful Protocol" [RFC5218], and all the way back to Deering's plenary talk [deering-plenary] at IETF 51 in 2001. It's giving history 📚

1.1. Organization of This Report 🗂️

This workshop report sums up the contributions and discussions from the workshop, organized by topic. We start with a summary of where things stand on stack ossification. Then we dig into the incentives that created this situation and the role incentives play in evolution. Lots of contributions split into two main areas: middlebox measurement, classification, and defenses against middlebox modification of packets; and approaches that support transport evolution. All accepted position papers and detailed discussion transcripts are available at https://www.iab.org/activities/workshops/semi/. 🦋

The outcomes of the workshop are covered in Section 6, including progress made since the workshop toward each of the identified work items as of the time this report was published. 👑

2. The Situation in Review 🔥

When Deering gave his talk in 2001, network address translation (NAT) was named as the key challenge to the Internet architecture. Since then, the NAT traversal problem has mostly been solved, but the boxes in the middle keep getting smarter and more varied. 🙈

SEMI, like the IP Stack Evolution program in general, is far from the first attempt to fix the problems caused by middlebox interference with the end-to-end model. Inside the IETF alone, the MIDCOM, NSIS, and BEHAVE efforts have dealt with this problem, and the TRAM working group is updating the NAT traversal outcomes of MIDCOM to match current reality. 🧠

We think there's a real chance to improve things right now because a few forces are converging. The tussle between security and middleboxes isn't new, but the accelerating deployment of cryptography for integrity and confidentiality makes many packet inspection and packet modification operations obsolete, which creates pressure to change things. There's also new energy in the IETF around work that needs transport-layer flexibility we're not sure we have (e.g., WebRTC), as well as flexibility at the transport interface (TAPS). ✨

3. Incentives for Stack Ossification and Evolution 💖

The current situation is, of course, the result of many processes and the convergence of incentives for network operators, content providers, network equipment vendors, application developers, operating system developers, and end users. Moore's Law makes it easier to deploy more processing on-path, network operators need to find ways to add value, enterprises find it more scalable to deploy functionality in the network than on endpoints, and middleboxes are something vendors can sell. These trends increase ossification of the network stack. 😩

So any effort to reduce that ossification and make the transport stack easier to evolve has to consider the incentives each of these actors has to deploy new approaches. 🫶

As Christian Huitema [huitema-semi] pointed out, encryption is a powerful incentive here. Putting a transport protocol on top of a cryptographic protocol on top of UDP resets the transport-versus-middlebox tussle, because inspection and modification above the encryption and demux layer become impossible. 🔐 Any transport evolution strategy that uses this approach must also deliver better performance or functionality (e.g., setup latency) than existing approaches, while being as deployable as those approaches, or more so. 🚀

Dave Thaler, pointing to [RFC5218], said that significant positive net value at each organization where change is required (operators, application developers, equipment vendors, enterprise and private users) is the best way to drive deployment of a new protocol. Every tussle in networking comes from conflicting incentives that are unavoidable in a free market. For upper-layer protocols, incentives tend to favor protocols that work anywhere, use the most efficient mechanism that works, and are as simple as possible from an implementation, maintenance, and management standpoint. For lower-layer protocols, incentives tend to push toward ignoring or disabling optional features, because there's a positive feedback cycle between being rarely used and rarely implemented. 🌈

4. The Role and Rule of Middleboxes 🎀

okay so middleboxes are EVERYWHERE on the Internet 🌐 and they seriously limit what we can roll out, like new protocols and protocol extensions just get stuck. 😭 To deal with this, we need a "bestiary" of middleboxes 🐉, which is basically a catalogue of what kinds of impairments they cause and how often they show up. Benoit Donnet put that together in [edeline-semi] and it's iconic work, no cap. 💅

Now, the move toward Network Function Visualization (NFV) makes middleboxes faster to update, so they get more flexible ✨ but the functions they provide aren't going anywhere. 🫶 Honestly, service chaining could mean even more add-ons piling up to fix and manage problems in the network, which makes network management even more complicated 💀. Ted Hardie [hardie-semi] warned that each instance may add a new queue and make the bufferbloat problem worse, and that's bad news for latency-sensitive apps that are just starting to show up. 🙈 BUT, this new flexibility is also a chance to move functionality back to the end host 🧚. Another option is that more appropriate in-network functionality could use extra information about applications and path characteristics, though that comes with a bunch of complicated trust relationships among nodes in the network. 🌸 Either way, in-network functionality is trending up, especially in mobile networks 📱.

Costin Raiciu [raiciu-semi] said middleboxes make the Internet unpredictable, which creates a trade-off between efficiency and reachability. ⚖️ One approach is constructive cooperation with middleboxes, so the network and the endpoint agree on a clear contract 🤝. But if the environment isn't very cooperative, enforcing that contract might need extensive tunneling 🚇. Raiciu's work on "ninja tunneling" shows one approach like that, and it's giving clever 🥷✨.

5. Evolving the Transport Layer 🦋

okay, so for evolution in the transport layer itself, people have floated a bunch of ideas 💭. One is developing new protocols (maybe as user-level stacks) that get encapsulated in UDP with a transport identification sub-header. Another is using TCP as a substrate where TCP's semantics get relaxed (things like reliability, ordering, and flow control) and the application gets a more flexible API 🔥.

The discussion at the workshop split pretty amicably into two camps 👑. One group wanted to fix the deployability of TCP extensions, which they jokingly called "the TCP Liberation Front" ✊. The other wanted to build new encapsulation-based mechanisms so that totally new protocols could be deployed, known as "the People's Front of UDP" 🌈. David Black [black-semi] pointed out that UDP encapsulation has to be adapted and discussed separately for every use case, and that can be a long, painful process 😩. Still, UDP encapsulation can help build more specialized protocols that address the special needs of certain applications 🍓. However, Stuart Cheshire [cheshire-semi] (as presented by Brian Trammell) pointed out that designing a new protocol instead of fixing or extending TCP might not always solve the problem 🙃.

To tackle TCP's extensibility problem, Bob Briscoe proposed Inner Space [briscoe-semi] 🫧. The main idea is to extend layer X's header inside layer X+1. For TCP, that means extra TCP header and option space gets placed inside the TCP payload, so middleboxes can't currently inspect or modify it 🔒.

Micheal Welzl [welzl-semi] also points out that not every path is ossified, so there are lots of paths where new extensions and protocols could work 🌿. To use those paths, an end host would need to probe or use a happy-eyeball-like approach [RFC6555] and possibly fall back 🔁. The TAPS working group is working on the first step: decoupling applications from transport protocols so the transport layer gets the flexibility it needs 💜.

6. Outcomes 🎉

The SEMI workshop identified several areas for further work, which are outlined below 📝.

6.1. Minimal Signaling for Encapsulated Transports 📡

Assuming transport evolution in user space involves encapsulation in UDP datagrams, the workshop figured it might be useful to have a facility built on top of UDP. It would provide minimal signaling of flow semantics that TCP already offers. At the very least, it would indicate first and last packets in a flow, so firewalls and NATs can make policy decisions and maintain state 🛡️. This facility could also provide minimal application-to-path and path-to-application signaling, though people didn't agree on exactly what should or could be signaled 🤷‍♀️.

The workshop also noted that, since encryption is becoming more common on the Internet, this facility should cooperate with Datagram Transport Layer Security (DTLS) [RFC6347] 🔐. The goal is to selectively expose information about traffic flows where the transport headers and payload are themselves encrypted 👀.

To develop this concept further, it was decided to propose a BoF session, not a working group, called SPUD (Substrate Protocol for User Datagrams), at the IETF 92 meeting in March in Dallas 🤠. A use cases document [SPUD-USE], a prototype specification for a shim protocol over UDP [SPUD-PROTO], and a separate specification for using DTLS as a subtransport layer [TLS-DTLS] were prepared after the SEMI discussions and presented at the BoF 🎤.

It was clear from discussion before and during the SPUD BoF, and from experience with earlier endpoint-to-middle and middle-to-endpoint signaling approaches, that any selective exposure of traffic metadata outside a relatively restricted trust domain must be declarative rather than imperative, non-negotiated, and advisory 🚨. Each exposed parameter should also be independently verifiable, so each entity can decide how much trust to give the others 💅. Basic transport over the substrate MUST keep working even if signaling is ignored or stripped, to support incremental deployment. These restrictions on vocabulary are discussed further in [EXP-COOP] 📚.

There was a lot of interest in the room in continuing work on an approach like the one being discussed 🙌. It was pretty clear, though, that the discussion and prototyping are not yet mature enough for standardization within an IETF working group 🥲. Where the work should continue is still unclear 🤔.

Discussion continues on the spud mailing list (spud@ietf.org) 📬. The UDP shim layer prototype is described in [SPUD-PROTO] ✨.

6.2. Middlebox Measurement 📊

Talking about the impairments middleboxes cause quickly showed that we need better, more detailed data on how common each type of impairment is in the network 🔍. For example, it doesn't make much sense to engineer complicated workarounds for certain impairments into transport protocols if those impairments are fairly rare 🙅‍♀️. There are dedicated measurement studies for some types of impairment, but the workshop noted that prevalence data might already exist in error logs from TCP stacks and applications on both clients and servers 📋. Those entities can tell when attempts to use particular transport features failed, so they can measure the network just by being used 🪄. Lots of clients already have a feature that sends these bug reports back to their developers 💌. All of this gives us a chance to bring real data into decisions about protocol engineering in an Internet full of middleboxes 🌐.

The HOPS (How Ossified is the Protocol Stack) informal birds of a feather session, also called the "Bar BoF," was held at the IETF 92 meeting in Dallas 🤠. It discussed ways to aggregate data from these logs about potential middlebox impairment, focusing on common data formats and on preserving end-user privacy 🔐. Some discussion focused on aggregating impairment observations at the network level, but initial work will focus on making relative prevalence information available on an Internet-wide scope 🌍. The first step is to match the types of data needed to answer protocol engineering questions with the data that is already being collected or can easily be collected 🧩.

A mailing list (hops@ietf.org) has been set up to keep the discussion going 💬.

6.3. Guidelines for Middlebox Design and Deployment 🛠️

The workshop found the potential to update [RFC3234] so it provides guidelines on middlebox design, implementation, and deployment 📘. The aim is to reduce inadvertent or accidental impact on stack ossification in existing and new middlebox designs 🦖. The IAB Stack Evolution Program will follow up on this with the participants in the now-closed BEHAVE working group, since it most closely follows that group's work 🤝. It will draw partly on the BEHAVE working group's work and on experience with STUN, TURN, and ICE, all of which focus more specifically on network address translation 🔄.

6.4. Architectural Guidelines for Transport Stack Evolution 🏗️

The workshop identified a need for general architectural guidance on transport stack evolution 🧱. That covers tradeoffs between user-space and kernel-space implementations, tradeoffs and considerations for encapsulations (especially UDP), tradeoffs between implicit and explicit interaction with devices along the path, and so on 🧐. The IAB IP Stack Evolution Program will produce this document, and the new transport encapsulations document [EXP-COOP] may grow into the basis for this work 🌱.

Also, because of the underlying discussion on trust and the need for a "balance of power" between end hosts and the network, the workshop participants concluded that it is necessary to define approaches based on the cryptographic protocol to enable transport protocol extensibility 🔑.

6.5. Additional Activities in the IETF and IAB 🏛️

The workshop identified a need to socialize ideas around transport stack evolution within the IETF community 📣. That includes presentations in the transport and applications open area meetings on protocol extensibility, UDP encapsulation considerations, and applying TLS/DTLS to prevent middlebox meddling 🙅. Much of the energy from the workshop went into the SPUD BoF (see Section 6.1), so these presentations will be given at future meetings 🗓️.

There are also clear connections between the future work following the SEMI workshop and the IAB's Privacy and Security Program. Privacy and Security program members will be encouraged to follow developments in transport stack evolution, especially for the privacy implications of the workshop's outcomes 👀🔐.

6.6. Additional Activities in Other Venues 🌏

Bob Briscoe informally liaised the SEMI workshop discussions to the ETSI Network Function Virtualization (NFV) Industry Specification Group (ISG) after the workshop 🗣️. He also focused on the implications of end-to-end encryption for the present and future of in-network functionality 🔒. In the ISG's Security Working Group, he proposed text for best practices on middlebox access to data when end-to-end encryption is in use 🫶.

7. Security Considerations 🔐

This document presents no security considerations 🙂.

8. Informative References ✨

Okay bestie, here's the reading list 📚 Every source the RFC leans on is below, with all the details kept exactly as written.

Appendix A. Attendees 🧚

The people who showed up to the SEMI workshop were:

Mary Barnes, Richard Barnes, David Black, Marc Blanchet, Bob Briscoe, Ken Calvert, Spencer Dawkins, Benoit Donnet, Lars Eggert, Gorry Fairhurst, Aaron Falk, Mat Ford, Ted Hardie, Joe Hildebrand, Russ Housley, Felipe Huici, Christian Huitema, Jana Iyengar, Mirja Kuehlewind, Eliot Lear, Barry Leiba, Xing Li, Szilveszter Nadas, Erik Nordmark, Colin Perkins, Bernhard Plattner, Miroslav Ponec, Costin Raiciu, Philipp Schmidt, Martin Stiemerling, Dave Thaler, Brian Trammell, Michael Welzl, Brandon Williams, Dan Wing, and Aaron Yi Ding.

Stuart Cheshire and Eric Rescorla also contributed to the workshop, even though they couldn't make it in person. 🥹

Acknowledgments 🫶

The IAB is so grateful to the SEMI Program Committee: Brian Trammell, Mirja Kuehlewind, Joe Hildebrand, Eliot Lear, Mat Ford, Gorry Fairhurst, and Martin Stiemerling. 💖 They also thank Prof. Dr. Bernhard Plattner of the Communication Systems Group at ETH for hosting the workshop, and the Internet Society for its support. Huge thanks as well to Suzanne Woolf and Aaron Falk for the feedback and review 🌸

Authors' Addresses 🦋

Brian Trammell (editor)
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Email: ietf@trammell.ch

Mirja Kuehlewind (editor)
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Email: mirja.kuehlewind@tik.ee.ethz.ch
📦 where this page comes from