summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7663.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7663.txt')
-rw-r--r--doc/rfc/rfc7663.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7663.txt b/doc/rfc/rfc7663.txt
new file mode 100644
index 0000000..31c40f5
--- /dev/null
+++ b/doc/rfc/rfc7663.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB) B. Trammell, Ed.
+Request for Comments: 7663 M. Kuehlewind, Ed.
+Category: Informational ETH Zurich
+ISSN: 2070-1721 October 2015
+
+
+ Report from the IAB Workshop
+ on Stack Evolution in a Middlebox Internet (SEMI)
+
+Abstract
+
+ 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 and 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.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7663.
+
+
+
+
+
+
+
+
+Trammell & Kuehlewind Informational [Page 1]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+Copyright Notice
+
+ 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 review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Trammell & Kuehlewind Informational [Page 2]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+1. Introduction
+
+ The transport layer of the Internet has become 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.
+
+ 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-ossify 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.
+
+ 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?
+
+ The call for papers encouraged a focus on approaches that are
+ incrementally deployable within the present Internet. Identified
+ topics included the following:
+
+ o Development and deployment of transport-like features in
+ application-layer protocols
+
+ o Methods for discovery of path characteristics and protocol
+ availability along a path
+
+ o Methods for middlebox detection and characterization of middlebox
+ behavior and functionality
+
+ o Methods for NAT and middlebox traversal in the establishment of
+ end-to-end paths
+
+ o Mechanisms for cooperative path-endpoint signaling, and lessons
+ learned from existing approaches
+
+
+
+Trammell & Kuehlewind Informational [Page 3]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ o Economic considerations and incentives for cooperation in
+ middlebox deployment
+
+ The Internet Architecture Board (IAB) holds occasional workshops
+ designed to consider long-term issues and strategies for the
+ Internet, and to suggest future directions for the Internet
+ architecture. This long-term planning function of the IAB is
+ complementary to the ongoing engineering efforts performed by working
+ groups of the Internet Engineering Task Force (IETF), under the
+ leadership of the Internet Engineering Steering Group (IESG) and area
+ directorates.
+
+ 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 [RFC7305], "What Makes for a Successful Protocol"
+ [RFC5218], back to Deering's plenary talk [deering-plenary] at IETF
+ 51 in 2001.
+
+1.1. Organization of This Report
+
+ 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 that 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/.
+
+ The outcomes of the workshop are discussed in Section 6, including
+ progress after the workshop toward each of the identified work items
+ as of the time of publication of this report.
+
+2. The Situation in Review
+
+ 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.
+
+ SEMI, as the IP Stack Evolution program in general, is far from 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
+
+
+
+
+Trammell & Kuehlewind Informational [Page 4]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ BEHAVE efforts have addressed this problem, and the TRAM working
+ group is updating the NAT traversal outcomes of MIDCOM to reflect
+ current reality.
+
+ 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 that requires 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 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 scalable to deploy
+ functionality in-network than on endpoints, and middleboxes are
+ something vendors can vend. These trends increase ossification of
+ the network stack.
+
+ Any effort to reduce the resulting 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.
+
+ As Christian Huitema [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 deployable as
+ these approaches, or moreso.
+
+ 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 [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 an implementation,
+ maintenance, and management standpoint. For lower-layer protocols,
+
+
+
+Trammell & Kuehlewind Informational [Page 5]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ incentives tend toward ignoring and or disabling optional features,
+ as there is a positive feedback cycle between being rarely used and
+ rarely implemented.
+
+4. The Role and Rule of Middleboxes
+
+ 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 [edeline-semi].
+
+ 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 manage problems in the network, in turn further increasing the
+ complexity of network management. Ted Hardie [hardie-semi] warned
+ that each instance may add a new queue and may increase the
+ bufferbloat problem that is counterproductive for new emerging
+ latency-sensitive applications. However, this new flexibility also
+ provides a chance to move functionality back to the end host.
+ Alternately, more appropriate in-network functionality could benefit
+ from additional information in application and path characteristics,
+ though this in turn implies a variety of complicated trust
+ relationships among nodes in the network. In any case, an increasing
+ trend of in-network functionality can be observed, especially in
+ mobile networks.
+
+ Costin Raiciu [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 endpoint might
+ be one approach to address this challenge, enforcement of contract in
+ less cooperative environments might require extensive tunneling.
+ Raiciu's contribution on "ninja tunneling" illustrates one such
+ approach.
+
+5. Evolving the Transport Layer
+
+ 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.
+
+
+
+
+Trammell & Kuehlewind Informational [Page 6]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ Discussion on evolution during the workshop divided amicably along
+ two lines: working to fix the deployability of TCP extensions
+ (referred to in discussion as "the TCP Liberation Front") versus
+ working to build new encapsulation-based mechanisms to allow wholly
+ new protocols to be deployed (referred to in discussion as "the
+ People's Front of UDP"). David Black [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 that helps to address 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/extending TCP might not always solve the problem.
+
+ To address the extensibility problem of TCP, Bob Briscoe proposed
+ Inner Space [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.
+
+ Further, instead of only focusing on those cases where new extensions
+ and protocols are not deployable, Micheal Welzl [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 [RFC6555] and
+ potentially fallback. The TAPS working group implements the first
+ step to decouple applications from transport protocols allowing for
+ the needed flexibility in the transport layer.
+
+6. Outcomes
+
+ The SEMI workshop identified several areas for further work, outlined
+ below.
+
+6.1. Minimal Signaling for Encapsulated Transports
+
+ 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 on exactly what should or could be signaled here.
+
+
+
+
+
+
+Trammell & Kuehlewind Informational [Page 7]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ The workshop did note that, given the increasing deployment of
+ encryption in the Internet, this facility should cooperate with
+ Datagram Transport Layer Security (DTLS) [RFC6347] in order to
+ selectively expose information about traffic flows where the
+ transport headers and payload themselves are encrypted.
+
+ To develop this concept further, it was decided to propose a BoF
+ session that would not form a working group, SPUD (Substrate Protocol
+ for User Datagrams), at the IETF 92 meeting in March in Dallas. A
+ document on use cases [SPUD-USE], a prototype specification for a
+ shim protocol over UDP [SPUD-PROTO], and a separate specification of
+ the use of DTLS as a subtransport layer [TLS-DTLS] were prepared
+ following discussions at SEMI and presented at the BoF.
+
+ 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 [EXP-COOP].
+
+ There was much interest in the room in continuing work on an approach
+ like the one under discussion. 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. An
+ appropriate venue for continuing the work remains unclear.
+
+ Discussion continues on the spud mailing list (spud@ietf.org). The
+ UDP shim layer prototype is described by [SPUD-PROTO].
+
+6.2. Middlebox Measurement
+
+ 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
+
+
+
+Trammell & Kuehlewind Informational [Page 8]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ 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.
+
+ The HOPS (How Ossified is the Protocol Stack) informal birds of a
+ feather session ("Bar BoF") 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.
+
+ A mailing list (hops@ietf.org) has been established to continue
+ discussion.
+
+6.3. Guidelines for Middlebox Design and Deployment
+
+ The workshop identified the potential to update [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. The IAB Stack
+ Evolution Program will follow up on this with the participants in the
+ now-closed BEHAVE working group, as it most closely follows the work
+ of that group. It will draw 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.
+
+6.4. Architectural Guidelines for Transport Stack Evolution
+
+ 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 document [EXP-COOP] may evolve into the
+ basis for this work.
+
+ 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 necessary to define approaches
+ based on the cryptographic protocol to enable transport protocol
+ extensibility.
+
+
+
+
+Trammell & Kuehlewind Informational [Page 9]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+6.5. Additional Activities in the IETF and IAB
+
+ 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
+ Section 6.1), so these presentations will be given at future
+ meetings.
+
+ 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.
+
+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) 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.
+
+7. Security Considerations
+
+ This document presents no security considerations.
+
+8. Informative References
+
+ [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+ Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
+ <http://www.rfc-editor.org/info/rfc3234>.
+
+ [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful
+ Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
+ <http://www.rfc-editor.org/info/rfc5218>.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+ January 2012, <http://www.rfc-editor.org/info/rfc6347>.
+
+ [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
+ Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
+ 2012, <http://www.rfc-editor.org/info/rfc6555>.
+
+
+
+Trammell & Kuehlewind Informational [Page 10]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
+ Technology Adoption and Transition (ITAT)", RFC 7305,
+ DOI 10.17487/RFC7305, July 2014,
+ <http://www.rfc-editor.org/info/rfc7305>.
+
+ [SPUD-USE] Hardie, T., "Use Cases for SPUD", Work in Progress,
+ draft-hardie-spud-use-cases-01, February 2015.
+
+ [SPUD-PROTO]
+ Hildebrand, J. and B. Trammell, "Substrate Protocol for
+ User Datagrams (SPUD) Prototype", Work in Progress,
+ draft-hildebrand-spud-prototype-03, March 2015.
+
+ [TLS-DTLS] Huitema, C., Rescorla, E., and J. Jana, "DTLS as
+ Subtransport protocol", Work in Progress,
+ draft-huitema-tls-dtls-as-subtransport-00, March 2015.
+
+ [EXP-COOP] Trammell, B., Ed., "Architectural Considerations for
+ Transport Evolution with Explicit Path Cooperation", Work
+ in Progress, draft-trammell-stackevo-explicit-coop-00,
+ September 2015.
+
+ [black-semi]
+ Black, D., "UDP Encapsulation: Framework Considerations",
+ January 2015, <https://www.iab.org/wp-content/
+ IAB-uploads/2014/12/semi2015_black.pdf>.
+
+ [briscoe-semi]
+ Briscoe, B., "Tunneling Through Inner Space", October
+ 2014, <https://www.iab.org/wp-content/IAB-uploads/2014/12/
+ semi2015_briscoe.pdf>.
+
+ [cheshire-semi]
+ Cheshire, S., "Restoring the Reputation of the
+ Much-Maligned TCP", January 2015, <https://www.iab.org/
+ wp-content/IAB-uploads/2015/01/semi2015-cheshire.pdf>.
+
+ [deering-plenary]
+ Deering, S., "Watching the Waist of the Protocol
+ Hourglass", August 2001,
+ <https://www.ietf.org/proceedings/51/slides/plenary-1>.
+
+ [edeline-semi]
+ Edeline, K. and B. Donnet, "On a Middlebox
+ Classification", January 2015, <https://www.iab.org/
+ wp-content/IAB-uploads/2014/12/semi2015_edeline.pdf>.
+
+
+
+
+
+Trammell & Kuehlewind Informational [Page 11]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+ [hardie-semi]
+ Hardie, T., "Network Function Virtualization and Path
+ Character", January 2015, <https://www.iab.org/wp-content/
+ IAB-uploads/2014/12/semi2015_hardie.pdf>.
+
+ [huitema-semi]
+ Huitema, C., "The Secure Transport Tussle", October 2014,
+ <https://www.iab.org/wp-content/IAB-uploads/2014/12/
+ semi2015_huitema.pdf>.
+
+ [raiciu-semi]
+ Raiciu, C., Olteanu, V., and , "Good Cop, Bad Cop: Forcing
+ Middleboxes to Cooperate", January 2015,
+ <https://www.iab.org/wp-content/IAB-uploads/2015/01/
+ ninja.pdf>.
+
+ [welzl-semi]
+ Welzl, M., Fairhurst, G., and D. Ros, "Ossification: a
+ result of not even trying?", January 2015,
+ <https://www.iab.org/wp-content/IAB-uploads/2014/12/
+ semi2015_welzl.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Trammell & Kuehlewind Informational [Page 12]
+
+RFC 7663 SEMI Workshop October 2015
+
+
+Appendix A. Attendees
+
+ The following people attended the SEMI workshop:
+
+ 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.
+
+ Additionally, Stuart Cheshire and Eric Rescorla contributed to the
+ workshop but were unable to attend.
+
+Acknowledgments
+
+ 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. Thanks 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
+
+
+
+
+
+
+
+
+Trammell & Kuehlewind Informational [Page 13]
+