Requirements for the design of a Substrate Protocol for User Datagrams (SPUD)
draft-trammell-spud-req-00

Network Working Group                                   B. Trammell, Ed.
Internet-Draft                                        M. Kuehlewind, Ed.
Intended status: Informational                                ETH Zurich
Expires: January 7, 2016                                   July 06, 2015

 Requirements for the design of a Substrate Protocol for User Datagrams
                                 (SPUD)
                       draft-trammell-spud-req-00

Abstract

   The Substrate Protocol for User Datagrams (SPUD) BoF session at the
   IETF 92 meeting in Dallas in March 2015 identified the potential need
   for a UDP-based encapsulation protocol to allow explicit cooperation
   with middleboxes while using new, encrypted transport protocols.
   This document proposes an initial set of requirements for such a
   protocol, and discusses tradeoffs to be made in further refining
   these requirements.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2016.

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.  Code Components extracted from this document must

Trammell & Kuehlewind    Expires January 7, 2016                [Page 1]
Internet-Draft              SPUD requirements                  July 2015

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Motivation

   A number of efforts to create new transport protocols or experiment
   with new network behaviors have been built on top of UDP, as it
   traverses firewalls and other middleboxes more readily than new
   protocols do.  Each such effort must, however, either manage its
   flows within common middlebox assumptions for UDP or train the
   middleboxes on the new protocol (thus losing the benefit of using
   UDP).  A common Substrate Protocol for User Datagrams (SPUD) would
   allow each effort to re-use a set of shared methods for notifying
   middleboxes of the flows' semantics, thus avoiding both the
   limitations of current flow semantics and the need to re-invent the
   mechanism for notifying the middlebox of the new semantics.

   As a concrete example, it is common for some middleboxes to tear down
   required state (such as NAT bindings) very rapidly for UDP flows.  By
   notifying the path that a particular transport using UDP maintains
   session state and explicitly signals session start and stop using the
   substrate, the using protocol may reduce or avoid the need for
   heartbeat traffic.

   This document defines a specific set of requirements for a SPUD
   facility, based on analysis on a target set of applications to be
   developed on SPUD developing experience with a prototype described in
   [I-D.hildebrand-spud-prototype].  It is intended as the basis for
   determining the next steps to make progress in this space, including
   eventually chartering an working group for specific protocol
   engineering work.

2.  History

   An outcome of the IAB workshop on Stack Evolution in a Middlebox
   Internet (SEMI) [I-D.iab-semi-report], held in Zurich in January
   2015, was a discussion on the creation of a substrate protocol to
   support the deployment of new transport protocols in the Internet.
   Assuming that a way forward for transport evolution in user space
   would involve encapsulation in UDP datagrams, the workshop noted 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 may assist firewalls and NATs in policy decision
   and state maintenance.  Further transport semantics would be used by
   the protocol running atop this facility, but would only be visible to
   the endpoints, as the transport protocol headers themselves would be

Trammell & Kuehlewind    Expires January 7, 2016                [Page 2]
Internet-Draft              SPUD requirements                  July 2015

   encrypted, along with the payload, to prevent inspection or
   modification.  This encryption might be accomplished by using DTLS
   [RFC6347] as a subtransport [I-D.huitema-tls-dtls-as-subtransport] or
   by other suitable methods.  This facility could also provide minimal
   application-to-path and path-to-application signaling, though there
   was less agreement about what should or could be signaled here.

   The Substrate Protocol for User Datagrams (SPUD) BoF was held at IETF
   92 in Dallas in March 2015 to develop this concept further.  It is
   clear from discussion before and during the SPUD BoF that any
   selective exposure of traffic metadata outside a relatively
   restricted trust domain must be advisory, non-negotiated, and
   declarative rather than imperative.  This conclusion matches
   experience with previous endpoint-to-middle and middle-to-endpoint
   signaling approaches.  As with other metadata systems, exposure of
   specific elements must be carefully assessed for privacy risks and
   the total of exposed elements must be so assessed.  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
   [I-D.trammell-stackevo-newtea].  This discussion includes privacy and
   trust concerns as well as the need for strong incentives for
   middlebox cooperation based on the information that are exposed.

3.  Terminology

   This document uses the following terms

   o  Overlying transport: : A transport protocol that uses SPUD for
      middlebox signaling and traversal.

   o  Endpoint: : A node that sends or receives a packet.  In this
      document, this term may refer to either the SPUD implementation on
      this node, the overlying transport implementation on this node, or
      the applications running over that overlying transport.

   o  Path: : The set of Internet Protocol nodes and links that a given
      packet traverses from endpoint to endpoint.

   o  Middlebox: : A device on the path that makes decisions about
      forwarding behavior based on other than IP or sub-IP addressing
      information, and/or that modifies the packet before forwarding.

Trammell & Kuehlewind    Expires January 7, 2016                [Page 3]
Internet-Draft              SPUD requirements                  July 2015

4.  Use Cases

   The primary use case for endpoint to path signaling, making use of
   packet grouping, is the binding of limited related semantics (start-
   tube and stop-tube) to a group of packets which are semantically
   related in terms of the application or overlying transport.  By
   explicitly signaling start and stop semantics, a flow allows
   middleboxes to use those signals for setting up and tearing down
   their relevant state (NAT bindings, firewall pinholes), rather than
   requiring the middlebox to infer this state from continued traffic.
   At best, this would allow the application to refrain from sending
   heartbeat traffic, which might result in reduced radio utilization
   (and thus greater battery life) on mobile platforms.

   SPUD may also provide some facility for SPUD-aware nodes on the path
   to signal some property of the path relative to a tube to the
   endpoints and other SPUD-aware nodes on the path.  The primary use
   case for path to application signaling is parallel to the use of ICMP
   [RFC0792], in that it describes a set of conditions (including
   errors) that applies to the datagrams as they traverse the path.
   This usage is, however, not a pure replacement for ICMP but a
   "5-tuple ICMP" which would traverse NATs in the same way as the
   traffic related to it, and be deliverable to the application with
   appropriate tube information.

   [EDITOR'S NOTE: specific applications we think need this go here?
   reference draft-kuehlewind-spud-use-cases.]

5.  Functional Requirements

   The following requirements detail the services that SPUD must provide
   to overlying transports, endpoints, and middleboxes using SPUD.

5.1.  Grouping of Packets

   Transport semantics and many properties of communication that
   endpoints may want to expose to middleboxes are bound to flows or
   groups of flows (five-tuples).  SPUD must therefore provide a basic
   facility for associating packets together (into what we call a "tube"
   ,for lack of a better term) and associate information to these groups
   of packets.  The simplest mechanisms for association would involve
   the addition of an identifier to each packet in a tube.  The tube ID
   must be bi-directional to support state establishment and is scoped
   to the forward and backward five-tuple due to privacy concern.
   Current thoughts on the tradeoffs on requirements and constraints on
   this identifier space are given in Section 7.1.

Trammell & Kuehlewind    Expires January 7, 2016                [Page 4]
Internet-Draft              SPUD requirements                  July 2015

5.2.  Endpoint to Path Signaling

   SPUD must be able to provide information from the end-point(s) to all
   SPUD-aware nodes on the path.  To be able to potentially communicate
   with all SPUD-aware middleboxes on the path SPUD must either be
   designed as an in-band signaling protocol, or there must be a pre-
   existing relationship between the endpoint and the SPUD-aware
   middleboxes along the path.  Since it is implausible that an endpoint
   has these relationships to all SPUD-aware middleboxes on a certain
   path in the context of the Internet, SPUD must provide in-band
   signaling.  SPUD may in addition also offer mechanisms for out-of-
   band signaling when it is appropriate to use.  See Section 7.5 for
   more discussion.

5.3.  Path to Endpoint Signaling

   SPUD must be able to provide information from a SPUD-aware middlebox
   to the endpoint.  See Section 7.5 for more discussion on tradeoffs
   here.

5.4.  Extensibility

   SPUD must enable multiple new transport semantics and application/
   path declarations without requiring updates to SPUD implementations
   in middleboxes.

5.5.  Authentication

   The basic SPUD protocol must not require any authentication or a
   priori trust relationship between endpoints and middleboxes to
   function.  However, SPUD should support the presentation/exchange of
   authentication information in environments where a trust relationship
   already exists, or can be easily established, either in-band or out-
   of-band.

5.6.  Integrity

   SPUD must provide integrity protection of SPUD-encapsulated packets,
   though the details of this integrity protection are still open; see
   Section 7.3.  At the very least, endpoints should be able to:

   1.  detect simple transmission errors over at least whatever headers
       SPUD uses its own signaling.

   2.  detect packet modifications by non-SPUD-aware middleboxes along
       the path

Trammell & Kuehlewind    Expires January 7, 2016                [Page 5]
Internet-Draft              SPUD requirements                  July 2015

   3.  detect the injection of packets into a SPUD flow (defined by
       5-tuple) or tube by nodes other than the remote endpoint.

   The decision of how to handle integrity check failures other than
   case (1) may be left up to the overlying transport.

5.7.  Privacy

   SPUD must allow endpoints to control the amount of information
   exposed to middleboxes, with the default being the minimum necessary
   for correct functioning.

6.  Non-Functional Requirements

   The following requirements detail the constraints on how the SPUD
   facility must meet its functional requirements.

6.1.  Middlebox Traversal

   SPUD must be able to traverse middleboxes that are not SPUD-aware.
   Therefore SPUD must be encapsulated in a transport protocol that is
   known to be accepted on a large fraction of paths in the Internet, or
   implement some form of probing to determine in advance which
   transport protocols will be accepted on a certain path.

6.2.  Low Overhead in Network Processing

   SPUD must be low-overhead, specifically requiring very little effort
   to recognize that a packet is a SPUD packet and to determine the tube
   it is associated with.

6.3.  Implementability in User-Space

   To enable fast deployment SPUD and transports above SPUD must be
   implementable without requiring kernel replacements or modules on the
   endpoints, and without having special privilege (root or "jailbreak")
   on the endpoints.  Usually all operating systems will allow a user to
   open a UDP socket.  Therefore SPUD must provide an UDP-based
   encapsulation, either exclusively or as a mandatory-to-implement
   feature.

6.4.  Incremental Deployability in an Untrusted, Unreliable Environment

   SPUD must operate in the present Internet.  In order to maximize
   deployment, it should also be useful as an encapsulation between
   endpoints even before the deployment of middleboxes that understand
   it.  The information exposed over SPUD must provide incentives for
   adoption by both endpoints and middleboxes, and must maximize privacy

Trammell & Kuehlewind    Expires January 7, 2016                [Page 6]
Internet-Draft              SPUD requirements                  July 2015

   (by minimizing information exposed).  Further, SPUD must be robust to
   packet loss, duplication and reordering by the underlying network
   service.  SPUD must work in multipath, multicast, and endpoint multi-
   homing environments.

   Incremental deployability likely requires limitations of the
   vocabulary used in signaling, to ensure that each actor in a
   nontrusted environment has incentives to participate in the signaling
   protocol honestly; see [I-D.trammell-stackevo-newtea] for more.

6.5.  Minimum restriction on the overlying transport

   SPUD must impose minimal restrictions on the transport protocols it
   encapsulates.  However, to serve as a substrate, it is necessary to
   factor out the information that middleboxes commonly rely on and
   endpoints are commonly willing to expose.  This information should be
   included in SPUD, and might itself impose additional restrictions to
   the overlying transport.  One example is that SPUD is likely to
   impose at least return routability and the presence of a feedback
   channel between endpoints, this being necessary for protection
   against reflection, amplification, and trivial state exhaustion
   attacks; see Section 7.4 for more.

6.6.  Minimum Header Overhead

   To avoid reducing network performance, the information and coding
   used in SPUD should be designed to use the minimum necessary amount
   of additional space in encapsulation headers.

6.7.  No additional start-up latency

   SPUD should not introduce additional start-up latency for overlying
   transports.

6.8.  Reliability and Duplication

   As any information provided by SPUD is anyway opportunistic, we
   assume for now that SPUD does not have to provide reliability and any
   SPUD mechanism using SPUD information must handle duplication of
   information.  However, this decision also depends on the signal type
   used by SPUD, as further discussed in Section 7.5, and currently
   assumes that there are no SPUD information that would need to be
   split over multiple packets.

Trammell & Kuehlewind    Expires January 7, 2016                [Page 7]
Internet-Draft              SPUD requirements                  July 2015

7.  Open questions and discussion

   The preceding requirements reflect the present best understanding of
   the authors of the functional and technical requirements on an
   encapsulation-based protocol for common middlebox-endpoint
   cooperation for overlying transports.  There remain a few large open
   questions and points for discussion, detailed in the subsections
   below.

7.1.  Tradeoffs in tube identifiers

   Grouping packets into tubes requires some sort of notional tube
   identifier; for purposes of this discussion we will assume this
   identifier to be a simple vector of N bits.  The properties of the
   tube identifier are subject to tradeoffs on the requirements for
   privacy, security, ease of implementation, and header overhead
   efficiency.

   We first assume that the 5-tuple of source and destination IP
   address, UDP (or other transport protocol) port, and IP protocol
   identifier (17 for UDP) is used in the Internet as an existing flow
   identifier, due to the widespread deployment of network address and
   port translation.  The question then arises whether tube identifiers
   should be scoped to 5-tuples (i.e., a tube is identified by a 6-tuple
   including the tube identifier) or should be separate, and presumed to
   be globally unique.

   If globally unique, N must be sufficiently large to reduce to
   negligibility the probability of collision among multiple tubes
   having the same identifier along the same path during some period of
   time.  An advantage of globally unique tube identifiers is they allow
   migration of per-tube state across multiple five-tuples for mobility
   support in multipath protocols.  However, globally unique tube
   identifiers would also introduce new possibilities for user and node
   tracking, with a serious negative impact on privacy.

   In the case of 5-tuple-scoped identifiers, mobility must be supported
   separately by each overlying transport.  N must still be sufficiently
   large, and the bits in the identifier sufficiently random, that
   possession of a valid tube ID implies that a node can observe packets
   belonging to the tube.  This reduces the chances of success of blind
   packet injection attacks of packets with guessed valid tube IDs.

   Further using multiple tube identifiers within one 5-tuple also
   raises some protocol design questions: Can one packet belong to
   multiple tubes?  Do all packets in a five-tuple flow have to belong
   to one tube?  Can/Must the backward flow have the same tube ID or a
   different one?  Especially at connection start-up, depending on the

Trammell & Kuehlewind    Expires January 7, 2016                [Page 8]
Internet-Draft              SPUD requirements                  July 2015

   semantics of the overlying transport protocol, there likely might be
   only one packet to start multiple streams/tubes.  Can this start
   message signal multiple tube IDs at once or do we need an own start
   message for each tube?  Or is it in this case not possible to have
   multiple tubes within one five-tuple?  These questions have to be
   further investigated based on the semantic of existing transport
   protocols.  The discussion in [I-D.ietf-dart-dscp-rtp] concerning use
   of different QoS treatments within a single 5-tuple is related, e.g.,
   WebRTC multiplexing of multiple application layer flows onto a single
   transport layer (5-tuple) flow.

7.2.  Property binding

   Related to identifier scope is the scope of properties bound to SPUD
   packets by endpoints.  SPUD may support both per-tube properties as
   well as per-packet properties.  Properties signaled per packet reduce
   state requirements at middleboxes, but also increase per-packet
   overhead.  It is likely that both types of property binding are
   necessary, but the selection of which properties to bind how must be
   undertaken carefully.

7.3.  Tradeoffs in integrity protection

   In order to protect the integrity of information carried by SPUD
   against trivial forging by malicious devices along the path, it is
   necessary to be able to authenticate the originator of that
   information.  We presume that the authentication of endpoints is a
   generally desirable property, and to be handled by the overlying
   transport; in this case, SPUD can borrow that authentication to
   protect the integrity of endpoint-originated information.

   However, in the Internet, it is not in the general case possible for
   the endpoint to authenticate every middlebox that might see packets
   it sends and receives.  In this case information produced by
   middleboxes may enjoy less integrity protection than that produced by
   endpoints.  In addition, endpoint authentication of middleboxes and
   vice-versa may be better conducted out-of- band (treating the
   middlebox as an endpoint for the authentication protocol) than in-
   band (treating the middlebox as a participant in a 3+ party
   communication).

7.4.  Return routability and feedback

   We have identified a requirement to support as wide a range of
   overlying transports as possible and feasible, in order to maximize
   SPUD's potential for improving the evolvability of the transport
   stack.

Trammell & Kuehlewind    Expires January 7, 2016                [Page 9]
Internet-Draft              SPUD requirements                  July 2015

   The ease of forging source addresses in UDP together with the only
   limited deployment of network egress filtering [RFC2827] means that
   UDP traffic presently lacks a return routability guarantee.  This has
   led in part to the present situation wherein UDP traffic may be
   blocked by firewalls when not explicitly needed by an organization as
   part of its Internet connectivity.  In addition, to defend against
   state exhaustion attacks on middleboxes, SPUD may need to see a first
   packet in a reverse direction on a tube to consider that tube
   acknowledged and valid.

   Return routability is therefore a minimal property of any transport
   that can be responsibly deployed at scale in the Internet.  Therefore
   SPUD should enforce bidirectional communication at start-up, whether
   the overlying transport is bidirectional or not.  This excludes use
   of the UDP source port as an entropy input that does not accept
   traffic (i.e., for one-way communication, as is commonly done for
   unidirectional UDP tunnels, e.g., MPLS in UDP [RFC7510]).

7.5.  In-band, out-of-band, piggybacked, and interleaved signaling

   Discussions about SPUD to date have focused on the possibility of in-
   band signaling from endpoints to middleboxes and back - the signaling
   channel happens on the same 5-tuple as the data carried by the
   overlying transport.  This arrangement would have the advantage that
   it does not require foreknowledge of the identity and addresses of
   devices along the path by endpoints and vice versa, but does add
   complexity to the signaling protocol.

   In-band signaling can be either piggybacked on the overlying
   transport or interleaved with it.  Piggybacked signaling uses some
   number of bits in each packet generated by the overlying transport to
   achieve signaling.  It requires either reducing the MTU available to
   the overlying transport (and telling the overlying transport about
   this MTU reduction, or relying on the overlying transport to use
   PLPMTUD [RFC4821]), or opportunistically using bits between the
   network-layer MTU and the bits actually used by the transport.

   This is even more complicated in the case of middleboxes that wish to
   add information to piggybacked-signaling packets, and may require the
   endpoints to introduce "scratch space" in the packets for potential
   middlebox signaling use, further increasing complexity and overhead.
   In any case, a SPUD sender would effectively request SPUD information
   from a middlebox that respectively the middlebox would be able to
   insert the requested information into this place holder.

   However, a SPUD using piggybacked signaling is at the mercy of the
   overlying transport's transmission scheduler to actually decide when
   to send packets.  At the same time, piggybacked signaling has the

Trammell & Kuehlewind    Expires January 7, 2016               [Page 10]
Internet-Draft              SPUD requirements                  July 2015

   benefit that SPUD can use the overlying transport's reliability
   mechanisms to meet any reliability requirements it has for its own
   use (e.g. in key exchange).  This would require SPUD to understand
   the semantics of the overlying protocol but can reduce overhead.
   Piggyback signaling is also the only way to achieve per-packet
   signaling as in Section 7.2.

   Interleaved signaling uses SPUD-only packets on the same 5-tuple with
   the same tube identifier to achieve signaling.  This reduces
   complexity and sidesteps MTU problems, but is only applicable to per-
   tube signaling.  It also would require SPUD to provide its own
   reliability mechanisms if per-tube signaling requires reliability,
   and still needs to interact well with the overlying transport's
   transmission scheduler.

   Out-of-band signaling uses direct connections between endpoints and
   middleboxes, separate from the overlying transport - connections that
   are perhaps negotiated by in-band signaling.  A key disadvantage here
   is that out-of-band signaling packets may not take the same path as
   the packets in the overlying transport and therefore connectivity
   cannot be guaranteed.

   Signaling of path-to-endpoint information, in the case that a
   middlebox wants to signal something to the sender of the packet,
   raises the added problem of either (1) requiring the middlebox to
   send the information to the receiver for later reflection back to the
   sender, which has the disadvantage of complexity, or (2) requiring
   out-of-band direct signaling back to the sender, which in turn either
   requires the middlebox to spoof the source address and port of the
   receiver to ensure equivalent NAT treatment, or some other NAT-
   traversal approach.

   The tradeoffs here must be carefully weighed, and the final approach
   may use a mix of all these communication patterns where SPUD provides
   different signaling patterns for different use case.  E.g., a
   middlebox might need to generate out-of-band signals for error
   messages or can provide requested information in-band and feedback
   over the receiver if a minimum or maximum value from all SPUD-aware
   middleboxes on path should be discovered.

7.6.  Continuum of trust among endpoints and middleboxes

   There are different security considerations for different security
   contexts.  The end-to-end context is one; anything that only needs to
   be seen by the path shouldn't be exposed in SPUD, but rather by the
   overlying transport.  There are multiple different types of end-to-
   middle context based on levels of trust between end and middle - is
   the middlebox on the same network as the endpoint, under control of

Trammell & Kuehlewind    Expires January 7, 2016               [Page 11]
Internet-Draft              SPUD requirements                  July 2015

   the same owner?  Is there some contract between the application user
   and the middlebox operator?  It may make sense for SPUD to support
   different levels of trust than the default ("untrusted, but presumed
   honest due to limitations on the signaling vocabulary") and fully-
   authenticated; this needs to be explored further.

7.7.  Discovery and capability exposure

   There are three open issues in discovery and capability exposure.
   First, an endpoint needs to discover if the other communication
   endpoint understands SPUD.  Second, endpoints need to test whether
   SPUD is potentially not usable along a path because of middleboxes
   that block SPUD packets or strip the SPUD header.  If such
   impairments exist in the path, a SPUD sender needs to fall back to
   some other approach to achieve the goals of the overlying transport.
   Third, endpoints might want to be able to discover SPUD-aware
   middleboxes along the path, and to discover which parts of the
   vocabulary that can be spoken by the endpoints are supported by those
   middleboxes as well as the other communication endpoint, and vice
   versa.

   In addition, endpoints may need to discover and negotiate which
   overlying transports are available for a given interaction.  SPUD
   could assist here.  However, it is explicitly not a goal of SPUD to
   expose information about the details of the overlying transport to
   middleboxes.

7.8.  Hard state vs. soft state

   The initial thinking on signaling envisions "hard state" in
   middleboxes that is established when the middlbox observes the start
   of a SPUD tube and is torn down when the middlebox observes the end
   (stop) of a SPUD tube.  Such state can be abandoned as a result of
   network topology changes (e.g., routing update in response to link or
   node failure).  An alternative is a "soft state" approach that
   requires periodic refresh of state in middleboxes, but cleanly times
   out and discards abandoned state.  SPUD has the opportunity to use
   different timeouts than the defaults that are required for current
   NAT and firewall pinhole maintenance.  Of course, applications will
   still have to detect non-SPUD middleboxes that use shorter timers.

8.  Security Considerations

   The security-relevant requirements for SPUD deal mainly with endpoint
   authentication and the integrity of exposed information (Section 5.5,
   Section 5.6, Section 5.7, and Section 7.3); protection against
   attacks (Section 7.1 and Section 7.4); and the trust relationships
   among endpoints and middleboxes Section 7.6.  These will be further

Trammell & Kuehlewind    Expires January 7, 2016               [Page 12]
Internet-Draft              SPUD requirements                  July 2015

   addressed in protocol definition work following from these
   requirements.

9.  IANA Considerations

   This document has no actions for IANA.

10.  Contributors

   In addition to the editors, this document is the work of David Black,
   Ken Calvert, Ted Hardie, Joe Hildebrand, Jana Iyengar, and Eric
   Rescorla.

   [EDITOR'S NOTE: make this a real contributor's section once we figure
   out how to make kramdown do that...]

11.  Informative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", RFC 7510, April 2015.

   [I-D.hildebrand-spud-prototype]
              Hildebrand, J. and B. Trammell, "Substrate Protocol for
              User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
              prototype-03 (work in progress), March 2015.

   [I-D.huitema-tls-dtls-as-subtransport]
              Huitema, C., Rescorla, E., and J. Jana, "DTLS as
              Subtransport protocol", draft-huitema-tls-dtls-as-
              subtransport-00 (work in progress), March 2015.

   [I-D.trammell-stackevo-newtea]
              Trammell, B., "Thoughts a New Transport Encapsulation
              Architecture", draft-trammell-stackevo-newtea-01 (work in
              progress), May 2015.

Trammell & Kuehlewind    Expires January 7, 2016               [Page 13]
Internet-Draft              SPUD requirements                  July 2015

   [I-D.iab-semi-report]
              Trammell, B. and M. Kuehlewind, "IAB Workshop on Stack
              Evolution in a Middlebox Internet (SEMI) Report", draft-
              iab-semi-report-00 (work in progress), June 2015.

   [I-D.ietf-dart-dscp-rtp]
              Black, D. and P. Jones, "Differentiated Services
              (DiffServ) and Real-time Communication", draft-ietf-dart-
              dscp-rtp-10 (work in progress), November 2014.

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    Expires January 7, 2016               [Page 14]