One document matched: draft-trammell-spud-req-01.xml

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

<!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 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 I-D.hildebrand-spud-prototype SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml3/reference.I-D.hildebrand-spud-prototype.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.iab-semi-report SYSTEM "http://unicorn-wg.github.io/idrefs/bibxml3/reference.I-D.iab-semi-report.xml">
]>

<?rfc toc="yes"?>

<rfc ipr="trust200902" docName="draft-trammell-spud-req-01" 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="2015" month="October" day="19"/>

    
    
    

    <abstract>


<t>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.</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 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>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
<xref target="I-D.hildebrand-spud-prototype"/>. 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="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.  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. 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
<xref target="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>

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

<t>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 <xref target="RFC0792"></xref>, 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” for error messages which should be application-visible; these
would traverse NATs in the same way as the traffic related to it, and be
deliverable to the application with appropriate tube information.</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 (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. 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).</t>

<t>The simplest mechanisms for association involve the addition of an identifier
to each packet in a tube. Current thoughts on the tradeoffs on requirements
and constraints on this identifier space are given in {{tradeoffs-in-tube-
identifiers}}.</t>

</section>
<section anchor="endpoint-to-path-signaling" title="Endpoint to Path Signaling">

<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.
Since it is implausible that an endpoint has pre-existing trust 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 appropriate. See {{in-band-out-of-
band-piggybacked-and-interleaved-signaling}} for more discussion.</t>

</section>
<section anchor="path-to-endpoint-signaling" title="Path to Endpoint Signaling">

<t>SPUD must be able to provide information from a SPUD-aware middlebox to the
endpoint. Though this information is not scoped to a tube in the same way that
endpoint to path signaling is, as the middleboxes do not originate the packets
in a tube, it is still associated with a tube, in terms of “the properties of
the path(s) this tube will traverse”. Path to endpoint signaling need not be
in-band; see <xref target="in-band-out-of-band-piggybacked-and-interleaved-signaling"/>
for more discussion.</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 <xref target="reliability-fragmentation-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. See <xref target="hard-state-vs-soft-state"/> and <xref target="tube-vs-superstrate-association-lifetime"/> for more discussion on tube start and end signaling.</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>

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

</section>
<section anchor="proof-a-device-is-on-path" title="Proof a device is on-path">

<t>Devices may make assertions of network characteristics relevant to a flow. One
way these assertions can be assessed is by a demonstration that the device
making it is on-path to the flow and so could adjust the characteristics to
match the assertion.  SPUD must therefore allow endpoints to distinguish on-
path devices from devices not on the path. Network elements may also need to
confirm that application-to-path assertions are made by the source indicated
in the flow.  In both cases, return routability (as in {{protection-against-
trivial-abuse}}) may offer one incrementally deployable method of testing the
topology to make this confirmation.</t>

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

<t>SPUD must provide integrity protection of SPUD-encapsulated packets, though
the details of this integrity protection are still open; see {{tradeoffs-in-
integrity-protection}}. 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
endpoint. Integrity protection of the superstrate is left up to the
superstrate.</t>

</section>
<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.</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 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. This encapsulation will require port numbers to support NAPT-
connected endpoints.  UDP encapsulation is the only mechanism that meets
these requirements.</t>

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

<t>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.</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 (root or “jailbreak”) on the endpoints. Usually all
operating systems will allow a user to open a UDP socket. This indicates UDP-
based encapsulation, either exclusively or as a mandatory-to-implement
feature.</t>

</section>
<section anchor="incremental-deployability-in-an-untrusted-unreliable-environment" title="Incremental Deployability in an Untrusted, Unreliable Environment">

<t>SPUD must operate in the present Internet. In order to maximize deployment, it
should also be useful 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 (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.</t>

<t>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 {{stackevo-
explicit-coop}} for more.</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 the 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 probably implies that SPUD should provide:</t>

<t><list style="symbols">
  <t>a proof of return routability,</t>
  <t>a feedback channel between endpoints,</t>
  <t>a method to probabilistically discriminiate legitimate SPUD traffic from reflected malicious traffic, and</t>
  <t>mechanisms to protect against state exhaustion and other denial-of-service attacks.</t>
</list></t>

<t>We note that return routability excludes use of a UDP source port that does
not accept traffic (i.e., for one-way communication, as is commonly done for
unidirectional UDP tunnels, e.g., MPLS in UDP <xref target="RFC7510"/> as an entropy input.)</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.</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="preservation-of-security-properties" title="Preservation of Security Properties">

<t>The use of SPUD must not weaken the security properties of the superstrate.  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.  While a box along the path may indicate a particular flow
is adminstratively prohibited or why it is prohibited, SPUD itself must not be
used to negotiate the means to lift the prohibition.</t>

</section>
<section anchor="reliability-fragmentation-and-duplication" title="Reliability, Fragmentation, 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. To avoid issues with fragment
reassembly, all in-band SPUD signaling information must fit within a single
packet. 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="interoperability-with-non-encapsulated-superstrates" title="Interoperability with non-encapsulated superstrates">

<t>It is presumed that “superstrate X with SPUD” is a distinct entity on the wire
from “superstrate X”. The APIs the superstrate presents to the application
should be equivalent, and the two wire protocols should be freely
transcodeable between each other, with the caveat that the variant without
SPUD would not necessarily support features enabling communication with the
path. However, there is no requirement that the headers the superstrate uses
be the same in the SPUD and non-SPUD variants. Headers that the superstrate
chooses always to expose to the path can therefore be encoded in the SPUD
layer but not appear in an upper-layer header.</t>

</section>
</section>
<section anchor="open-questions-and-discussion" title="Open questions and discussion">

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

<section anchor="tradeoffs-in-tube-identifiers" title="Tradeoffs in tube identifiers">

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

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

<t>If globally unique, N must 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
generated using an equivalent algorithm would be useful as such a globally-
unique tube identifier. An advantage of globally unique tube identifiers would
be 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. This alone probably speaks against using
globally unique identifiers for SPUD.</t>

<t>In the case of 5-tuple-scoped identifiers, mobility must be supported
separately from the tube identification mechanism. This could be specific to
each superstrate (i.e., hidden from the path), or SPUD could provide a
general endpoint-to-path tube grouping signal to allow an endpoint to
explicitly expose the fact that one tube is related to another to the path.
Even in this case, 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>

<t>When scoped to 5-tuples, the forward and backward directions of a
bidirectional flow probably 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>
<section anchor="property-binding" title="Property binding">

<t>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. It is also possible that SPUD will
provide a very limited set of per-packet signals (such as ECN) using flags in
the SPUD header, and require all more complicated properties to be bound per-
tube.</t>

</section>
<section anchor="tradeoffs-in-integrity-protection" title="Tradeoffs in integrity protection">

<t>In order to protect the integrity of information carried by SPUD against
forging by malicious devices along the path, it would be 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 superstrate; in this case, SPUD may be able borrow that
authentication to protect the integrity of endpoint-originated information.</t>

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

</section>
<section anchor="in-band-out-of-band-piggybacked-and-interleaved-signaling" title="In-band, out-of-band, piggybacked, and interleaved signaling">

<t>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 superstrate. However,
there are a wide variety of potential signaling arrangements: in-band
signaling can be piggybacked (where signaling happens on packets sent by the
superstrate) and/or interleaved (where SPUD and the superstrate each have
their own packets).  Signaling can also be out-of-band (on a different five
tuple, or even over a completely different protocol). Out of band signaling
for path-to-endpoint information can use direct return, allowing a device on
the path to communicate directly with an endpoint (i.e., as with ICMP). More
discussion on the tradeoffs here is given in <xref target="stackevo-explicit-coop"/>.</t>

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

</section>
<section anchor="discovery-and-capability-exposure" title="Discovery and capability exposure">

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

<t>In addition, endpoints may need to discover and negotiate which superstrates
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
superstrate to middleboxes.</t>

</section>
<section anchor="hard-state-vs-soft-state" title="Hard state vs. soft state">

<t>The initial thinking on signaling envisions “hard state” in middleboxes that
is established when the middlebox 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.</t>

</section>
<section anchor="tube-vs-superstrate-association-lifetime" title="Tube vs. superstrate association lifetime">

<t>The requirements as presently defined use tube start and stop signaling for
two things: (1) setting up and tearing down state along the path, and (2)
signaling superstrate such as association startup, acceptance, and teardown,
which may have security implications. These may require separate signaling.
Specifically, if tube start acknowledgement is to be used to provide explicit
guarantees to the path about the acceptability of a tube to a remote endpoint,
it cannot be a completely unreliable signal. Second, the lifetime of a tube
may be much shorter than the lifetime of a superstrate association, and the
creation of a new tube over an existing association may need to be treated
differently by endpoints and path devices than a tube creation coincident with
an association creation.</t>

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

<t>The security-relevant requirements for SPUD deal mainly with endpoint authentication and the integrity of exposed information (<xref target="authentication"/>, <xref target="integrity"/>, <xref target="privacy"/>, and <xref target="tradeoffs-in-integrity-protection"/>); protection against attacks (<xref target="proof-a-device-is-on-path"/>, <xref target="protection-against-trivial-abuse"/>, and <xref target="tradeoffs-in-tube-identifiers"/> and); and the trust relationships among endpoints and middleboxes <xref target="continuum-of-trust-among-endpoints-and-middleboxes"/>. 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 Roland Bless, Cameron Byrne, Toerless Eckert, Daniel Kahn Gillmor,
Tom Herbert, and Christian Huitema for feedback and comments on these
requirements, as well as to the participants at the SPUD BoF at IETF 92
meeting in Dallas inand the IAB SEMI workshop in Zurich for the discussions
leading to this work.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>

&RFC0792;
&RFC2827;
&RFC3234;
&RFC4122;
&RFC6347;
&RFC7510;
&I-D.hildebrand-spud-prototype;
&I-D.huitema-tls-dtls-as-subtransport;
<reference anchor="stackevo-explicit-coop" >
  <front>
    <title>Architectural Considerations for Transport Evolution with Explicit Path Cooperation</title>
    <author initials="B." surname="Trammell" fullname="Brian Trammell">
      <organization></organization>
    </author>
    <date year="2015" month="September" day="23"/>
  </front>
</reference>
&I-D.iab-semi-report;


    </references>



  </back>
</rfc>