One document matched: draft-trammell-spud-req-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:40 |