One document matched: draft-trammell-semi-report-01.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.23 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3234 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC5218 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5218.xml">
<!ENTITY RFC6347 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC7305 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7305.xml">
<!ENTITY I-D.hardie-spud-use-cases SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hardie-spud-use-cases.xml">
<!ENTITY I-D.hildebrand-spud-prototype SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hildebrand-spud-prototype.xml">
<!ENTITY I-D.huitema-tls-dtls-as-subtransport SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.huitema-tls-dtls-as-subtransport.xml">
<!ENTITY I-D.trammell-stackevo-newtea SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.trammell-stackevo-newtea.xml">
]>


<rfc ipr="trust200902" docName="draft-trammell-semi-report-01" category="info">

  <front>
    <title abbrev="SEMI Workshop">IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Report</title>

    <author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Gloriastrasse 35</street>
          <city>8092 Zurich</city>
          <country>Switzerland</country>
        </postal>
        <email>ietf@trammell.ch</email>
      </address>
    </author>
    <author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind" role="editor">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Gloriastrasse 35</street>
          <city>8092 Zurich</city>
          <country>Switzerland</country>
        </postal>
        <email>mirja.kuehlewind@tik.ee.ethz.ch</email>
      </address>
    </author>

    <date year="2015" month="May" day="19"/>

    
    
    

    <abstract>


<t>The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop, provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The transport layer of the Internet has becomed ossified, squeezed between narrow interfaces (from BSD sockets to pseudo-transport over HTTPS) and increasing in-network modification of traffic by middleboxes that make assumptions about the protocols running through them. This ossification makes it difficult to innovate in the transport layer, through the deployment of new protocols or the extension of existing ones. At the same time, emerging applications require functionality that existing protocols can provide only inefficiently, if at all.</t>

<t>To begin to address this problem, the IAB, within the scope of its IP Stack Evolution Program, organized a workshop to discuss approaches to de-ossifying transport, especially with respect to interactions with middleboxes and new methods for implementing transport protocols. Recognizing that the end-to-end principle has long been compromised, we start with the fundamental question of matching paths through the Internet with certain characteristics to application and transport requirements.</t>

<t>We posed the following questions in the call for papers: 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 to 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?</t>

<t>Topics for contributions in the call for papers with a focus on approaches that are incrementally deployable within the present Internet were identified as follows:</t>

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

<t>The SEMI workshop followed in part from the IAB’s longer term interest in the
evolution of the Internet and the adoption of Internet protocols, including
the Internet Technology Adoption and Transition workshop <xref target="RFC7305"/>, “What
Makes for a Successful Protocol” <xref target="RFC5218"/>, back to Deering’s “Watching the
Waist of the Protocol Hourglass” at IETF 51 in 2001 and before.</t>

<section anchor="organization-of-this-report" title="Organization of this report">

<t>This workshop report summarizes the contributions to and discussions at the
workshop, organized by topic. We started with a summary of the current
situation with respect to stack ossification, and explored the incentives which
have made it that way and the role of incentives in evolution. Many
contributions were broadly split into two areas: middlebox measurement,
classification, and approaches to defense against middlebox modification of
packets; and approaches to support transport evolution. All accepted position
papers and detailed transcripts of discussion are available at https://www.iab.org/activities/workshops/semi/.</t>

<t>The outcomes of the workshop are discussed in <xref target="outcomes"/>, and discuss progress after the workshop toward each of the identified work items as of the time of publication of this report.</t>

</section>
</section>
<section anchor="the-situation-in-review" title="The Situation in Review">

<t>At the time of Deering’s talk in 2001, network address translation (NAT) was
identified as the key challenge to the Internet architecture. Since then, the
NAT traversal problem has been largely solved, but the boxes in the middle are
getting smarter and more varied.</t>

<t>SEMI and the Stack Evolution program in general are by far not the first
attempt to solve the problems caused by middlebox interference in the end to
end model. Just within the IETF the MIDCOM, NSIS, and BEHAVE efforts have
addressed this problem, and the TRAM working group is updating the NAT
traversal outcomes of MIDCOM to reflect current reality.</t>

<t>We believe we have an opportunity to improve the situation in the present,
however, due to a convergence of forces. While the tussle between security and
middleboxes is not new, the accelerating deployment of cryptography for
integrity and confidentiality makes many packet inspection and packet
modification operations obsolete, creating pressure to improve the situation.
There is also new energy in the IETF around work which requires transport
layer flexibility we’re not sure we have (e.g. WebRTC) as well as around
flexibility at the transport interface (TAPS).</t>

</section>
<section anchor="incentives-for-stack-ossification-and-evolution" title="Incentives for Stack Ossification and Evolution">

<t>The current situation is, of course, the result of a variety of 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 scaleable to deploy functionality in-network than on
endpoints, and middleboxes are something vendors can vend. This trend
increases ossification of the network stack.</t>

<t>Any effort to reduce this ossification in order to make it easier to evolve
the transport stack, then, must consider the incentives to deployment of new
approaches by each of these actors.</t>

<t>As Christian Huitema <xref target="huitema-semi"/> pointed out, encryption provides a
powerful incentive here: putting a transport protocol atop a cryptographic
protocol atop UDP resets the transport versus middlebox tussle by making
inspection and modification above the encryption and demux layer impossible.
Any transport evolution strategy using this approach must also deliver better
performance or functionality (e.g. setup latency) than existing approaches
while being as or more deployable than these approaches.</t>

<t>Indeed, significant positive net value at each organization where change is
required – operators, application developers, equipment vendors, enterprise
and private users – is best to drive deployment of a new protocol, said Dave
Thaler, pointing to <xref target="RFC5218"/>. All tussles in networking stem from
conflicting incentives 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 a
implementation, maintenance, and management standpoint. For lower layer
protocols, incentives tend toward ignoring and or disabling optional features,
as there is a positive feedback cycle between being rarely used and rarely
implemented.</t>

</section>
<section anchor="the-role-and-rule-of-middleboxes" title="The Role and Rule of Middleboxes">

<t>Middleboxes are commonplace in the Internet and constrain the ability to deploy new protocols and protocol extensions. Engineering around this problem requires a “bestiary” of middleboxes, a classification of which kinds of impairments middleboxes cause and how often, according to Benoit Donnet <xref target="edeline-semi"/>.</t>

<t>Even though the trend towards Network Function Visualization (NFV) allows for faster update-cycle of middleboxes and thereby more flexibility, the function provided by middleboxes will stay. In fact service chaining may lead to more and more add-ons to address and management a problem in the network which might further increase the complexity of network management. Ted Hardie <xref target="hardie-semi"/> warned that each instance may add a new queue and may increase the bufferbloat problem which is contra-productive for new emerging latency-sensitive applications. However, as further discussed at the workshop this new flexibility also provides a chance to move functionality back to the end host and/or implement more appropriate in-network functionality that could benefit from additional information in application and path characteristics, but might also require trust between different actors. Especially in mobile networks, an increasing trend of in-network functionality can be observed.</t>

<t>Costin Raiciu <xref target="raiciu-semi"/> stated that middleboxes make the Internet unpredictable, leading to a trade-off between efficiency and reachability. While constructive cooperation with middleboxes to establish a clear contract between the network and the end might be one approach to address this challenge, the alternative to force this contract might lead to extensive tunneling as illustrated by the “ninja tunneling” approach.</t>

</section>
<section anchor="evolving-the-transport-layer" title="Evolving the Transport Layer">

<t>For evolution in the transport layer itself various proposals have been discussed, reaching from the development of new protocols (potentially as user-level stacks) encapsulated in UDP as a transport identification sub-header to the use of TCP as a substrate where the semantics of TCP are relaxed (e.g. regarding reliability, ordering, flow control etc.) and a more flexible API is provided to the application.</t>

<t>Discussion on evolution during the workshop divided amicably along two lines: working to fix the deployability of TCP extensions (“the TCP Liberation Front”) versus working to build new encapulation-based mechanisms to allow wholly new protocols to be deployed (“the People’s Front of UDP”). David Black <xref target="black-semi"/> pointed out that UDP encapsulation has to be adapted and separately discussed for every use case, which can be a long and painful process. UDP encapsulation can be an approach to develop more specialized protocols than helps to address special needs of certain applications. However, Stuart Cheshire <xref target="cheshire-semi"/> (as presented by Brian Trammell) pointed out that designing a new protocol instead of fixing/extending TCP might not always solve the problem.</t>

<t>To address the extensibility problem of TCP, Bob Briscoe proposed Inner Space <xref target="briscoe-semi"/>. Here, the general principle is to extend layer X’s header within layer X+1; in the case of TCP, additional TCP header and option space is provided within the TCP payload, such that it cannot presently be inspected and modified by middleboxes.</t>

<t>Further instead of only focusing on those cases there new extensions and protocols are not deployable, Micheal Welzl <xref target="welzl-semi"/> points out that there are also a lot of paths in the network that are not ossified. To enable deployment on these paths an end host would need to probe or use a happy-eyeball-like approach and potentially fallback. The TAPS working group implements the first step to decouples applications from transport protocols allowing for the needed flexibility in the transport layer.</t>

</section>
<section anchor="outcomes" title="Outcomes">

<t>The SEMI workshop identified several areas for further work, outlined below:</t>

<section anchor="minimal-signaling-for-encapsulated-transports" title="Minimal signaling for encapsulated transports">

<t>Assuming that a way forward for transport evolution in user space would
involve encapsulation in UDP datagrams, the workshop identified that it may be
useful to have a facility built atop UDP to provide minimal signaling of the
semantics of a flow that would otherwise be available in TCP: at the very
least, indications of first and last packets in a flow to assist firewalls and
NATs in policy decision and state maintenance. This facility could also
provide minimal application-to-path and path-to-application signaling, though
there was less agreement exactly what should or could be signaled here.</t>

<t>The workshop did note that, given the increasing deployment of encryption in the
Internet, this facility should cooperate with DTLS <xref target="RFC6347"/> in order to
selectively expose information about traffic flows where the transport headers
and payload themselves are encrypted.</t>

<t>To develop this concept further, it was decided to propose a non working group
forming BoF session, SPUD (Substrate Protocol for User Datagrams), at the IETF
92 meeting in March in Dallas. A draft on use cases
<xref target="I-D.hardie-spud-use-cases"/>, a prototype specification for a shim protocol
over UDP  {{I-D.hildebrand-spud-prototype}, and a separate specification of
the use of DTLS as a subtransport layer
<xref target="I-D.huitema-tls-dtls-as-subtransport"/> were prepared following discussions
at SEMI, and presented at the BoF.</t>

<t>Clear from discussion before and during the SPUD BoF, and drawing on
experience with previous endpoint-to-middle and middle-to-endpoint signaling
approaches, is that any selective exposure of traffic metadata outside a
relatively restricted trust domain must be declarative as opposed to
imperative, non-negotiated, and advisory. Each exposed parameter should also
be independently verifiable, so that each entity can assign its own trust to
other entities. Basic transport over the substrate must continue working even
if signaling is ignored or stripped, to support incremental deployment. These restrictions on vocabulary are discussed further in <xref target="I-D.trammell-stackevo-newtea"/>.</t>

<t>There was much interest in the room in continuing work on an approach like the
one under discussion. While it was relatively clear that the state of the
discussion and prototyping activity now is not yet mature enough for
standardization within an IETF working group, it is not clear in what venue
the work should continue.</t>

<t>Discussion contiunes on the spud mailing list (spud@ietf.org). The UDP shim layer prototype described by <xref target="I-D.hildebrand-spud-prototype"/>.</t>

</section>
<section anchor="middlebox-measurement" title="Middlebox measurement">

<t>Discussion about the impairments caused by middleboxes quickly identified the
need to get more and better data about how prevalent certain types of
impairments are in the network. It doesn’t make much sense, for instance, to
engineer complex workarounds for certain types of impairments into transport
protocols if those impairments are relatively rare. There are dedicated
measurement studies for certain types of impairment, but the workshop noted
that prevalence data might be available from error logs from TCP stacks and
applications on both clients and servers: these entities are in a position to
know when attempts to use particular transport features failed, providing an
opportunity to measure the network as a side effect of using it. Many clients
already have a feature for sending these bug reports back to their developers.
These present opportunities to bring data to bear on discussion and decisions
about protocol engineering in an Internet full of middleboxes.</t>

<t>The HOPS (How Ossified is the Protocol Stack) informal birds of a feather
session (“BarBoF”) was held at the IETF 92 meeting in Dallas, to discuss
approaches to get aggregated data from these logs about potential middlebox
impairment, focusing on common data formats and issues of preserving end-user
privacy. While some discussion focused on aggregating impairment observations
at the network level, initial work will focus on making relative prevalence
information available on an Internet-wide scope. The first activity identified
has been to match the types of data required to answer questions relevant to
protocol engineering to the data that currently is or can easily be collected.</t>

<t>A mailing list (hops@ietf.org) has been established to continue discussion.</t>

</section>
<section anchor="guidelines-for-middlebox-design-and-deployment" title="Guidelines for middlebox design and deployment">

<t>The workshop identified the potential to update <xref target="RFC3234"/> to provide
guidelines on middlebox design, implementation, and deployment in order to
reduce inadvertent or accidental impact on stack ossification in existing and
new middlebox designs. This document will be produced by the IAB IP Stack
Evolution program, drawing in part on the work of the BEHAVE working group,
and on experience with STUN, TURN, and ICE, all of which focus more
specifically on network address translation.</t>

</section>
<section anchor="architectural-guidelines-for-transport-stack-evolution" title="Architectural guidelines for transport stack evolution">

<t>The workshop identified the need for architectural guidance in general for
transport stack evolution: tradeoffs between user- and kernel-space
implementations, tradeoffs in and considerations for encapsulations
(especially UDP), tradeoffs in implicit versus explicit interaction with
devices along the path, and so on. This document will be produced by the IAB
IP Stack Evolution Program; the new transport encapsulations draft
<xref target="I-D.trammell-stackevo-newtea"/> may evolve into the basis for this work.</t>

<t>Further due to the underlying discuss on trust and a needed “balance of power” between the end hosts and the network, the workshop participants concluded that it is neccessary to define cryptographic protocol based approaches to enable transport protocol extensibility.</t>

</section>
<section anchor="additional-activities-in-the-ietf-and-iab" title="Additional Activities in the IETF and IAB">

<t>The workshop identified the need to socialize ideas connected to transport stack evolution within the IETF community, including presentations in the transport and applications open area meetings on protocol extensibility, UDP encapsulation considerations, and the application of TLS/DTLS in order to prevent middlebox meddling. Much of the energy coming out of the workshop went into the SPUD BoF (see <xref target="minimal-signaling-for-encapsulated-transports"/>), so these presentations will be given at future meetings.</t>

<t>There are also clear interactions 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 to help especially with privacy implications of the outcomes of the workshop.</t>

</section>
<section anchor="additional-activities-in-other-venues" title="Additional Activities in Other Venues">

<t>Bob Briscoe did an informal liaison of the SEMI workshop discussions to the ETSI Network Function Virtualization (NFV) Industry Specification Group (ISG) following the workshop, focusing as well on the implications of end to end encryption on 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 in the presence of end to end encryption.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document presents no security considerations.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The IAB thanks the SEMI Program Committee: Brian Trammell, Mirja Kuehlewind,
Joe Hildebrand, Eliot Lear, Mat Ford, Gorry Fairhurst, and Martin Stiemerling.
We additionally thank Prof. Dr. Bernhard Plattner of the Communication Systems
Group at ETH for hosting the workshop, and the Internet Society for its
support.</t>

</section>
<section anchor="attendees" title="Attendees">

<t>The following people attended the SEMI workshop:</t>

<t>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.</t>

<t>Additionally, Stuart Cheshire and Eric Rescorla contributed to the workshop but were unable to attend.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>

&RFC3234;
&RFC5218;
&RFC6347;
&RFC7305;
&I-D.hardie-spud-use-cases;
&I-D.hildebrand-spud-prototype;
&I-D.huitema-tls-dtls-as-subtransport;
&I-D.trammell-stackevo-newtea;
<reference anchor="black-semi" >
  <front>
    <title>UDP Encapsulation: Framework Considerations (https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_black.pdf)</title>
    <author initials="D." surname="Black">
      <organization></organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="briscoe-semi" >
  <front>
    <title>Tunneling Through Inner Space (https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_briscoe.pdf)</title>
    <author initials="B." surname="Briscoe">
      <organization></organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="cheshire-semi" >
  <front>
    <title>Restoring the Reputation of the Much-Maligned TCP (https://www.iab.org/wp-content/IAB-uploads/2015/01/semi2015-cheshire.pdf)</title>
    <author initials="S." surname="Cheshire">
      <organization></organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="edeline-semi" >
  <front>
    <title>On a Middlebox Classification (https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_edeline.pdf)</title>
    <author initials="K." surname="Edeline" fullname="Korian Edeline">
      <organization>Univ. Liege</organization>
    </author>
    <author initials="B." surname="Donnet" fullname="Benoit Donnet">
      <organization>Univ. Liege</organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="hardie-semi" >
  <front>
    <title>Network Function Virtualization and Path Character (https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_hardie.pdf)</title>
    <author initials="T." surname="Hardie">
      <organization></organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="huitema-semi" >
  <front>
    <title>The Secure Transport Tussle (https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_huitema.pdf)</title>
    <author initials="C." surname="Huitema" fullname="Christian Huitema">
      <organization>Microsoft</organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="raiciu-semi" >
  <front>
    <title>Good Cop, Bad Cop: Forcing Middleboxes to Cooperate  (https://www.iab.org/wp-content/IAB-uploads/2015/01/ninja.pdf)</title>
    <author initials="C." surname="Raiciu">
      <organization></organization>
    </author>
    <author initials="V." surname="Olteanu">
      <organization></organization>
    </author>
    <author fullname="R. Stoenescu">
      <organization></organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="welzl-semi" >
  <front>
    <title>Ossification: a result of not even trying? (https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_welzl.pdf)</title>
    <author initials="M." surname="Welzl">
      <organization></organization>
    </author>
    <author initials="G." surname="Fairhurst">
      <organization></organization>
    </author>
    <author initials="D." surname="Ros">
      <organization></organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>


    </references>



  </back>
</rfc>