One document matched: draft-trammell-spud-req-03.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.30 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0792 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC2827 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC3234 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC4122 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.4122.xml">
<!ENTITY RFC4443 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4821 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.4821.xml">
<!ENTITY RFC5226 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC6347 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC7510 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.7510.xml">
<!ENTITY RFC7663 SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml/reference.RFC.7663.xml">
<!ENTITY I-D.ietf-tsvwg-rfc5405bis SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml3/reference.I-D.ietf-tsvwg-rfc5405bis.xml">
<!ENTITY I-D.kuehlewind-spud-use-cases SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml3/reference.I-D.kuehlewind-spud-use-cases.xml">
<!ENTITY I-D.huitema-tls-dtls-as-subtransport SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml3/reference.I-D.huitema-tls-dtls-as-subtransport.xml">
<!ENTITY I-D.trammell-stackevo-explicit-coop SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml3/reference.I-D.trammell-stackevo-explicit-coop.xml">
]>

<?rfc toc="yes"?>

<rfc ipr="trust200902" docName="draft-trammell-spud-req-03" category="info">

  <front>
    <title abbrev="SPUD requirements">Requirements for the design of a Substrate Protocol for User Datagrams (SPUD)</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="2016" month="April" day="29"/>

    
    
    

    <abstract>


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



    </abstract>


  </front>

  <middle>


<section anchor="motivation" title="Motivation">

<t>A number of efforts to create new transport protocols or experiment with new
network behaviors in the Internet 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.</t>

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

<t>The intention of this work is to make it possible to define and deploy
new transport protocols that use encryption to protect their own operation as
well as the confidentiality, authenticity, integrity, and linkability
resistance of their payloads. The accelerating deployment of encryption will
render obsolete network operations techniques that rely on packet inspection and
modification based upon assumptions about the protocols in use. This
work will allow the replacement the current regime of middlebox inspection and
modification of transport and application-layer headers and payload with one
that allows inspection only of information explicitly exposed by the
endpoints, and modification of such information only under endpoint control.</t>

<t>Any selective exposure of traffic metadata outside a relatively restricted
trust domain must be advisory, non-negotiated, and declarative rather than
imperative. As with other signaling 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 <xref target="I-D.trammell-stackevo-explicit-coop"/>.
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.</t>

<t>Within this document, requirements are presented for a facility
implementable as an encapsulation protocol, atop which new transports
(“superstrates”) can be built. Alternately, these could be viewed as a set of
requirements for future transport protocol development without a layer
separation between the transport and the superstrate.</t>

<t>This document defines a specific set of requirements for a SPUD facility,
based on analysis on a target set of applications. It is intended as the basis
for determining the next steps to make progress in this space, including
possibly chartering a working group for specific protocol engineering work.</t>

</section>
<section anchor="history" title="History">

<t>An outcome of the IAB workshop on Stack Evolution in a Middlebox Internet
(SEMI) <xref target="RFC7663"/>, 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.  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. 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
encrypted, along with the payload, to prevent inspection or modification.
This encryption might be accomplished by using DTLS <xref target="RFC6347"/> as a
subtransport <xref target="I-D.huitema-tls-dtls-as-subtransport"/> or by other suitable
methods.</t>

<t>The Substrate Protocol for User Datagrams (SPUD) BoF was held at IETF 92 in
Dallas in March 2015 to develop this concept further. Restrictions on
vocabulary assumed in these requirements are derived from discussions during
this BoF, based on experience with previous endpoint-to-middle and middle-to-
endpoint signaling approaches as well as concerns about the privacy
implications of endpoint-to-middle signaling.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>This document uses the following terms:</t>

<t><list style="symbols">
  <t>Superstrate: The transport protocol or protocol stack “above” SPUD, that uses SPUD for explicit path cooperation and path traversal. The superstrate usually consists of a security layer (e.g. TLS, DTLS) and a transport protocol, or a transport protocol with integrated security features, to protect headers and payload above SPUD.</t>
  <t>Endpoint: One end of a communication session, located on a single node that is a source or destination of packets in that session. In this document, this term may refer to either the SPUD implementation at the endpoint, the superstrate implementation running over SPUD, or the applications running over that superstrate.</t>
  <t>Path: The sequence of Internet Protocol nodes and links that a given packet traverses from endpoint to endpoint.</t>
  <t>Middlebox: As defined in <xref target="RFC3234"/>, a middlebox is any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host; e.g. making decisions about forwarding behavior based on other than addressing information, and/or modifying a packet before forwarding.</t>
</list></t>

</section>
<section anchor="use-cases" title="Use Cases">

<t>Use cases are outlined in more detail in <xref target="I-D.kuehlewind-spud-use-cases"/>. We
summarize some of the primary use cases below.</t>

<t>The primary use case for endpoint to path signaling in the Internet making use
of packet grouping, as described in the use case document, is the binding of
limited related semantics (start, ack, and stop) to a flow or a group of
packets within a flow that are semantically related in terms of the
application or superstrate. 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 reduce heartbeat traffic, which might result in
reduced radio utilization and thus greater battery life on mobile platforms.</t>

<t>SPUD could also be used to provide information relevant for network treatment
for middleboxes as a replacement for deep packet inspection for traffic
classification purposes, rendered ineffective by superstrate encryption. In
this application, properties would be expressed in terms of network-relevant
parameters (intended bandwidth, latency and loss sensitivity, etc.) as opposed
to application-relevant semantics. See <xref target="I-D.trammell-stackevo-explicit-coop"/>
for discussion on limitations in signaling in untrusted environments.</t>

<t>SPUD may also provide some facility for SPUD-aware nodes on the path to signal
some property of the path 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 <xref target="RFC0792"/> and ICMPv6 <xref target="RFC4443"/>, in that it describes a set
of conditions (including errors) that applies to the datagrams as they
traverse the path. Since the signals here would traverse NATs in the same way
as the traffic related to them, this use case would sidestep problems with
ICMP availability in the deployed Internet.</t>

<t>Link-layer characteristics of use to the transport layer (e.g., whether a
high-transient-delay, highly-buffered link such as LTE is present on the path)
could also be signaled using this path-to-endpoint facility.</t>

</section>
<section anchor="functional-requirements" title="Functional Requirements">

<t>The following requirements detail the services that SPUD must provide to
superstrates, endpoints, and middleboxes using SPUD.</t>

<section anchor="grouping-of-packets-into-tubes" title="Grouping of Packets (into “tubes”)">

<t>Transport semantics and many properties of communication that endpoints may
want to expose to middleboxes are bound to flows or groups of flows (5-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. Each packet in a SPUD “flow”
(determined by 5-tuple) belongs to exactly one tube. Notionally, a tube
consists of a set of packets with a set of common properties, that should
therefore receive equivalent treatment from the network; these tubes may or
may not be related to separate semantic entities in the superstrate (e.g. SCTP
streams), at the superstrate’s discretion.</t>

<t>The simplest mechanisms for association involve the addition of an identifier
to each packet in a tube. Other mechanisms that don’t directly encode the
identifier in a packet header, but instead provide it in a way that it is
simple to derive from other information available in the packet at the
endpoints and along the path, are also possible. In any cases, for the
purposes of this requirement we treat this identifier as 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.</t>

<t>In determining the optimal size and scope for this tube identifier, we first
assume that the 5-tuple of source and destination IP address, UDP 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. We conclude that SPUD tube IDs should be scoped to this 5-tuple.</t>

<t>While a globally-unique identifier would allow easier state comparison and
migration for mobility use cases, it would have two serious disadvantages.
First, N would need to be sufficiently large to minimize the probability of
collision among multiple tubes having the same identifier along the same path
during some period of time. A 128-bit UUID <xref target="RFC4122"/> or an identifier of
equivalent size generated using an equivalent algorithm would probably be
sufficient, at the cost of 128 bits of header space in every packet. Second,
globally unique tube identifiers would also introduce new possibilities for
user and node tracking, with a serious negative impact on privacy. We note
that global identifiers for mobility, when necessary to expose to the path,
can be supported separately from the tube identification mechanism, by using a
generic tube-grouping application-to-path signaling bound to the tube.</t>

<t>Even when tube IDs are scoped to 5-tuples, 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.</t>

</section>
</section>
<section anchor="bidirectionality-of-tubes" title="Bidirectionality of Tubes">

<t>When scoped to 5-tuples, the forward and backward directions of a
bidirectional connection will have different tube IDs, since these will
necessarily take different paths and may interact with a different set of
middleboxes due to asymmetric routing. SPUD will therefore require some
facility to note that one tube is the “reverse” direction of another, a
general case of the tube grouping signal above.</t>

<section anchor="signaling-of-per-tube-properties" title="Signaling of Per-Tube Properties">

<t>SPUD must be able to provide information scoped to a tube from the end-
point(s) to all SPUD-aware nodes on the path about the packets in that tube.</t>

<t>We note that in-band signaling would meet this requirement.</t>

</section>
<section anchor="path-to-receiver-signaling-under-sender-control" title="Path to Receiver Signaling under Sender Control">

<t>SPUD must be able to provide information about from a SPUD-aware middlebox to
the endpoint. This information is associated with a tube, in terms of “the
properties of the path(s) the packets in this tube will traverse”. This
signaling must happen only with explicit sender permission and be sent to the
receiver of packets in the tube.</t>

<t>We note that in-band signaling would meet this requirement, if the sender
created a “placeholder” in-band that could be filled in by the middlebox(es)
on path. In-band signaling has 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.
Piggybacked signaling uses some number of bits in each packet generated by the
overlying transport. It requires either reducing the MTU available to the
encapsulated transport and/or opportunistically using “headroom” as it is
available: bits between the network-layer MTU and the bits actually used by
the transport. For use cases that accumulate information from devices on path
in the SPUD header, piggybacked signaling also requires a mechanism for
endpoints to create “scratch space” for potential use of the on-path devices.</t>

<t>In contrast, interleaved signaling uses signaling packets on the same 5-tuple
and tube ID, which don’t carry any superstrate data. These interleaved packets
could also contain scratch space for on-path device use. This reduces
complexity and sidesteps MTU problems, at the cost of sending more packets per
flow.</t>

</section>
<section anchor="receiver-to-sender-feedback" title="Receiver to Sender Feedback">

<t>SPUD must be able send information collected from SPUD-aware middleboxes along
the path to a receiver back to the sender that gave permission; see
<xref target="encrypted-feedback"/> for restrictions on this facility.</t>

</section>
<section anchor="direct-path-to-sender-signaling" title="Direct Path to Sender Signaling">

<t>SPUD must provide a facility for a middlebox to send a packet directly in
response to a sending endpoint, primarily to signal error conditions (e.g.
“packet administratively prohibited” or “no route to destination”, as in
present ICMP).</t>

<t>In this case, the direct return packet generated by the middlebox uses the
reversed end-to-end 5-tuple in order to receive equivalent NAT treatment,
though the reverse path might not be the same as the forward path. Endpoints
have control over this feature: A SPUD-aware middlebox must not emit a direct
return packet unless it is in direct response to a packet from a sending
endpoint, and must not forward a packet for which it has sent a direct return
packet; see <xref target="protection-against-trivial-abuse"/>.</t>

</section>
<section anchor="tube-start-and-end-signaling" title="Tube Start and End Signaling">

<t>SPUD must provide a facility for endpoints to signal that a tube has started,
that the start of the tube has been acknowledged and accepted by the remote
endpoint(s), and that a tube has ended and its state can be forgotten by the
path. Given unreliable signaling (see<vspace />
<xref target="on-reliability-fragmentation-mtu-and-duplication"/>), 
both endpoints and devices on the path must be resilient to
the loss of any of these signals. Specifically, timeouts are still necessary
to clean up stale state.</t>

</section>
<section anchor="common-transport-semantic-signaling" title="Common Transport Semantic Signaling">

<t>Similar to tube start and end signaling, SPUD must provide a facility for
endpoints to signal that a superstrate transport session has been requested,
set up, and/or torn down. This facility provides an explicit replacement for
the common practice in TCP-aware middleboxes of modeling TCP state of flows by
inspecting the TCP flags byte.</t>

<t>Given the fact that a superstrate transport session may consist of multiple
tubes, this signaling must be separate from that for tube start and end.</t>

</section>
<section anchor="declarative-signaling" title="Declarative signaling">

<t>All information signaled via SPUD is defined to be declarative (as opposed to
imperative). A SPUD endpoint must function correctly even no middlebox along
the path understands the signals it sends, or if sent signals from middleboxes
it does not understand. It must also function correctly if the path (and
thereby the set of middleboxes traversed) changes during the lifetime of a
tube; endpoints cannot rely on the creation or maintenance of state even on
cooperative middleboxes. Likewise, a SPUD-aware middlebox must function
correctly if sent signals from endpoints it does not understand, or in the
absence of expected signals from endpoints.</t>

<t>The declarative nature of this signaling removes any requirement that SPUD
provide reliability for its signals.</t>

</section>
<section anchor="extensibility" title="Extensibility">

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

<t>The use of SPUD for experimental signaling must be possible either without the
registration of codepoints or namespaces with IANA, or with trivially easy
(First Come, First Served <xref target="RFC5226"/> registration of such codepoints.</t>

</section>
<section anchor="common-vocabulary" title="Common Vocabulary">

<t>For the interoperability of SPUD endpoints and middleboxes with each other,
the use of SPUD for standard signaling must use a common vocabulary with
registered codepoints allocated under relatively restrictive policy. This
restrictive policy serves primarily security and privacy goals (i.e., reducing
the risk of misuse of the extensibility provided by the protocol).</t>

<t>We note that an IANA registry requiring Standards Action {RFC5226}} to modify
would meet this requirement.</t>

</section>
<section anchor="additional-per-packet-signaling" title="Additional Per-Packet Signaling">

<t>SPUD may provide a facility for signaling semantically simple information
(similar to tube start and end) on a per-packet as opposed to a per-tube
basis. Properties signaled per packet reduce state requirements at
middleboxes, but also increase per-packet overhead. Small signal size (in bits
of entropy) and encoding efficiency (in bits on the wire) is therefore more
important for per-packet signaling that per-tube signaling. If per-packet
signals need to be used by multiple hops along a path, these will need to be
encoded in an efficiently-implementable way (i.e., using fixed-length,
constant-offset data structures).</t>

<t>Given these constraints, per-packet signaling is necessary for certain use
cases, it is likely that SPUD will provide a very limited set of per-packet
signals using flags in a SPUD header, and require all more complex properties
to be bound per-tube.</t>

</section>
</section>
<section anchor="security-requirements" title="Security Requirements">

<section anchor="privacy" title="Privacy">

<t>SPUD must allow endpoints to control the amount of information exposed to
middleboxes, with the default being the minimum necessary for correct
functioning. This includes the cryptographic protection of transport layer
headers from inspection by devices on path, in order to prevent ossification
of these headers.</t>

</section>
<section anchor="authentication" title="Authentication">

<t>The basic SPUD protocol must not require any authentication or a priori trust
relationship between endpoints and middleboxes to function.  However, SPUD
should interoperate with 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, and use this information
where possible and appropriate.</t>

<t>Given the advisory nature of the signaling it supports, SPUD may also support
eventual authentication: authentication of a signal after the reception of a
packet after that containing the signal.</t>

</section>
<section anchor="integrity" title="Integrity">

<t>SPUD must be able to provide integrity protection of information exposed by
endpoints in SPUD-encapsulated packets, though the details of this integrity
protection are still open.</t>

<t>Endpoints should be able to detect changes to headers SPUD uses for its own
signaling (whether due to error, accidental modification, or malicious
modification), as well as the injection of packets into a SPUD flow (defined
by 5-tuple) or tube by nodes other than the remote endpoints. Errors and
accidental modifications can be detected using a simple checksum over the SPUD
header, while detecting malicious modifications requires cryptographic
integrity protection. Similar to <xref target="authentication"/>, cryptographic integrity
protection may also be eventual.</t>

<t>Integrity protection of the superstrate is left up to the superstrate.</t>

</section>
<section anchor="encrypted-feedback" title="Encrypted Feedback">

<t>As feedback from a receiver to a sender (see <xref target="receiver-to-sender-feedback"/>) 
does not need to be exposed to the path, this feedback channel should be
encrypted for confidentiality and authenticity, when available (see
<xref target="authentication"/>). This facility will rely on cooperation with the
superstrate or some other out-of-band mechanism to provide these guarantees.</t>

</section>
<section anchor="preservation-of-security-properties" title="Preservation of Security Properties">

<t>The use of SPUD must not weaken the essential security properties of the
superstrate: confidentiality, integrity, authenticity, and defense against
linkability. If the superstrate includes payload encryption for
confidentiality, for example, the use of SPUD must not allow deep packet
inspection systems to have access to the plaintext. Likewise, the use of SPUD
must not create additional opportunities for linkability not already existing
in the superstrate.</t>

</section>
<section anchor="protection-against-trivial-abuse" title="Protection against trivial abuse">

<t>Malicious background traffic is a serious problem for UDP-based protocols
due to the ease of forging source addresses in UDP together with only
limited deployment of network egress filtering <xref target="RFC2827"/>. Trivial abuse
includes flooding and state exhaustion attacks, as well as reflection and
amplification attacks.  SPUD must provide minimal protection against this
trivial abuse. This implies that SPUD should provide:</t>

<t><list style="symbols">
  <t>a proof of return routability, that the endpoint identified by a packet’s source address receives packets sent to that address;</t>
  <t>a feedback channel between endpoints;</t>
  <t>a method to probabilistically discriminiate legitimate SPUD traffic from reflected malicious traffic;</t>
  <t>a method to probabilistically discriminate SPUD traffic from on-path devices from devices off-path; and</t>
  <t>the ability to deploy mechanisms to protect against state exhaustion and other denial-of-service attacks against SPUD itself.</t>
</list></t>

<t>We note that using a “magic number” or other pattern of bits in an
encapsulation-layer header not used in any widely deployed protocol has the
nice property that no existing node in the Internet can be induced to reflect
traffic containing it. This allows the magic number to provide probabilistic
assurance that a given packet is not reflected, assisting in meeting this
requirement.</t>

<t>If SPUD is implemented over UDP, see <xref target="I-D.ietf-tsvwg-rfc5405bis"/> for
guidelines on the safe usage of UDP in the Internet, which addresses some of these issues.</t>

</section>
<section anchor="continuum-of-trust-among-endpoints-and-middleboxes" title="Continuum of trust among endpoints and middleboxes">

<t>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 superstrate. 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 the same owner? Is there some contract between the
application user and the middlebox operator? SPUD should support different
levels of trust than the default (“untrusted, but presumed honest due to
limitations on the signaling vocabulary”) and fully-authenticated; how these
points along the continuum are to be implemented and how they relate to each
other needs to be explored further.</t>

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

</section>
</section>
<section anchor="technical-requirements" title="Technical Requirements">

<t>The following requirements detail the constraints on how the SPUD facility must meet its functional requirements.</t>

<section anchor="middlebox-traversal" title="Middlebox Traversal">

<t>SPUD, including all path-to-endpoint and endpoint-to-path signaling as well as
superstrate and superstrate payload, should be able to traverse existing
middleboxes and firewalls, including those 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. This encapsulation will require port numbers to support
endpoints connected via network address and port translation (NAPT). We note
that UDP encapsulation would meet these requirements.</t>

</section>
<section anchor="low-overhead-in-network-processing" title="Low Overhead in Network Processing">

<t>SPUD must be desgined to have 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. We note that a magic number as in<vspace />
<xref target="protection-against-trivial-abuse"/> 
would also have a low probability of colliding with
any non-SPUD traffic, therefore meeting the recognition requirement. Tube
identifiers appearing directly in the encapsulation-layer header would meet
the tube association requirement.</t>

</section>
<section anchor="implementability-in-user-space" title="Implementability in User-Space">

<t>To enable fast deployment SPUD and superstrates must be implementable without
requiring kernel replacements or modules on the endpoints, and without having
special privilege (such as is required for raw packet transmission, i.e. root
or “jailbreak”) on the endpoints.</t>

<t>We note here that UDP would meet this requirement, as nearly all operating
systems and application development platforms allow a userspace application to
open UDP sockets.</t>

<t>We additionally note that while TCP APIs are also widely available to userspace
applications, they are bound to TCP transport semantics, and generally do not
provide enough control over segmentation and transmission to successfully
implement superstrate transports.</t>

</section>
<section anchor="incremental-deployability" title="Incremental Deployability">

<t>SPUD must be designed to operate in the present Internet, 
and must be designed to encourage incremental deployment.</t>

<t>As endpoint implementations can change more quickly than middleboxes can be
designed and deployed, a SPUD facility that was be useful between endpoints
even before the deployment of middleboxes that understand it would stimulate
deployment. The information exposed over SPUD must provide incentives for
adoption by both endpoints and middleboxes.</t>

<t>SPUD must not be designed in such a way that precludes its deployability in
multipath, multicast, and/or endpoint multi-homing environments.</t>

</section>
<section anchor="no-unnecessary-restrictions-on-the-superstrate" title="No unnecessary restrictions on the superstrate">

<t>Beyond those restrictions deemed necessary as common features of any secure,
responsible transport protocol (see <xref target="protection-against-trivial-abuse"/>),
SPUD must impose only 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 superstrate.</t>

</section>
<section anchor="minimal-additional-start-up-latency" title="Minimal additional start-up latency">

<t>SPUD should not introduce additional start-up latency for superstrates.
Specifically, superstrates which can send data on an initial packet must be
able to do so when encapsulated within SPUD.</t>

</section>
<section anchor="minimal-header-overhead" title="Minimal header overhead">

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

</section>
<section anchor="minimal-non-productive-traffic" title="Minimal non-productive traffic">

<t>SPUD should minimize additional non-productive traffic (e.g. keepalives),
and should provide mechanisms to allow its superstrates to minimize their
reliance on non-productive traffic.</t>

</section>
<section anchor="endpoint-control" title="Endpoint Control">

<t>In some cases, a middlebox may need to send a packet directly in response to a
sending endpoint, e.g. to signal an error condition. In this case, the direct
return packet generated by the middlebox uses the reversed end-to-end 5-tuple
in order to receive equivalent NAT treatment, though the reverse path might
not be the same as the forward path. Endpoints have control over this feature:
A SPUD-aware middlebox must not emit a direct return packet unless it is in
direct response to a packet from a receiving endpoint, and must not forward a
packet for which it has sent a direct return packet.</t>

</section>
<section anchor="on-reliability-fragmentation-mtu-and-duplication" title="On Reliability, Fragmentation, MTU, and Duplication">

<t>As any information provided by SPUD is anyway opportunistic, SPUD need not
provide reliable signaling for the information associated with a tube. Signals
must be idempotent; all middleboxes and endpoints must gracefully handle
receiving duplicate signal information. SPUD must continue working in the
presence of IPv4 fragmentation on path, but in order to reduce the impact of
requiring fragments reassembly at middleboxes for signals to be intelligible,
endpoints using SPUD should attempt to fit all signals into single MTU-sized
packets.</t>

<t>Given the importance of good path MTU information to SPUD’s own signaling,
SPUD should implement packetization layer path MTU discovery <xref target="RFC4821"/>.</t>

<t>Any facilities requiring more than an MTU’s worth of data in a single
signal should use an out-of-band method which does provide reliability – this
method may be an existing transport or superstrate/SPUD combination, or a
“minimal transport” defined by SPUD for its own use.</t>

</section>
<section anchor="spud-support-discovery" title="SPUD Support Discovery">

<t>If SPUD is not usable on a path to an endpoint, a SPUD sender needs to be able
to fall back to some other approach to achieve the goals of the superstrate; a
SPUD endpoint must be able to easily determine whether a remote endpoint with
which it wants to communicate using SPUD as a substrate can support SPUD, and
whether path to the remote endpoint as well as the return path from the remote
endpoint will pass SPUD packets.</t>

<t>It is not clear whether this is a requirement of SPUD, or a requirement of the
superstrate / application over SPUD.</t>

<!--
# 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 superstrates. There
remain a few large open questions and points for discussion, detailed in the
subsections below.

## Discovery and capability exposure

There are two open issues in discovery and capability exposure. First,
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. Second, SPUD could assist endpoints in
discovering and negotiate which superstrates are available for a given
interaction, though it is explicitly not a goal of SPUD to expose information
about the details of the superstrate to middleboxes.
-->

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

<t>The security-relevant requirements for SPUD are outlined in 
<xref target="security-requirements"/>. 
These will be further addressed in protocol
definition work following from these requirements.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no actions for IANA.</t>

</section>
<section anchor="contributors" title="Contributors">

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

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

<t>Thanks to Ozgu Alay, Roland Bless, Cameron Byrne, Toerless Eckert, Gorry
Fairhurst, Daniel Kahn Gillmor, Tom Herbert, Christian Huitema, Iain
Learmonth, Diego Lopez, and Matteo Varvelli for feedback and comments on these
requirements, as well as to the participants at the SPUD BoF at IETF 92
meeting in Dallas and the IAB SEMI workshop in Zurich for the discussions
leading to this work.</t>

<t>This work is supported by the European Commission under Horizon 2020 grant
agreement no. 688421 Measurement and Architecture for a Middleboxed Internet
(MAMI), and by the Swiss State Secretariat for Education, Research, and
Innovation under contract no. 15.0268. This support does not imply
endorsement.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>

&RFC0792;
&RFC2827;
&RFC3234;
&RFC4122;
&RFC4443;
&RFC4821;
&RFC5226;
&RFC6347;
&RFC7510;
&RFC7663;
&I-D.ietf-tsvwg-rfc5405bis;
&I-D.kuehlewind-spud-use-cases;
&I-D.huitema-tls-dtls-as-subtransport;
&I-D.trammell-stackevo-explicit-coop;


    </references>



  </back>
</rfc>