Internet DRAFT - draft-trammell-stackevo-explicit-coop
draft-trammell-stackevo-explicit-coop
Network Working Group B. Trammell, Ed.
Internet-Draft ETH Zurich
Intended status: Informational September 23, 2015
Expires: March 26, 2016
Architectural Considerations for Transport Evolution with Explicit Path
Cooperation
draft-trammell-stackevo-explicit-coop-00
Abstract
The IAB Stack Evolution in a Middlebox Internet (SEMI) workshop in
Zurich in January 2015 and the follow-up 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 to allow explicit cooperation with middleboxes while
using encryption at the transport layer and above to protect user
payload and metadata from inspection and interference. This document
proposes a set of architectural considerations for such approaches.
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 March 26, 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
Trammell Expires March 26, 2016 [Page 1]
Internet-Draft Explicit Cooperation September 2015
to this document. Code Components extracted from this document must
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. Introduction and Motivation
The IAB IP Stack Evolution Program aims to support the evolution of
the Internet's transport layer and its interfaces to other layers in
the Internet Protocol stack. The need for this work is driven by two
trends. First is the development and increased deployment of
cryptography in Internet protocols to protect against pervasive
monitoring [RFC7258], which will break many middleboxes used in the
operation and management of Internet-connected networks and which
assume access to plaintext content. An additional encapsulation
layer to allow selective, explicit metadata exchange between the
endpoints and devices on path to replace ad-hoc packet inspection is
one approach to retain network manageability in an encrypted
Internet.
Second is the increased deployment of new applications (e.g.
interactive media as in RTCWEB [I-D.ietf-rtcweb-overview]) for which
the abstractions provided by today's transport protocols (i.e.,
either a single reliable stream as in SOCK_STREAM over TCP, or an
unreliable, unordered packet sequence as in SOCK_DGRAM over UDP) are
inadequate. This evolution is constrained by the presence of
middleboxes which interfere with connectivity or packet invariability
in the presence of new transport protocols or transport protocol
extensions.
The core issue is one of layer violation. The boundary between the
network and transport layers was originally defined to be the
boundary between information used (and potentially modified) hop-by-
hop, and that only used end-to-end. The widespread deployment of
network address and port translation (NAPT) in the Internet has
eroded this boundary. The first four bytes after the IP header or
header chain - the source and destination ports - are now the de
facto boundary between the layers. This erosion has continued into
the transport and application layer headers and down into content, as
the capabilities of deployed middleboxes have increased over time.
Evolution above the network layer is only possible if this layer
boundary is reinforced. Asking on-path devices nicely not to muck
about in the transport layer and below - stating in an RFC that
devices on path MUST NOT use or modify some header field - has not
proven to be of much use here, so we need a new approach.
This boundary can be reinforced by encapsulating new transport
protocols in UDP and encrypting everything above the UDP header.
Trammell Expires March 26, 2016 [Page 2]
Internet-Draft Explicit Cooperation September 2015
However, this brings with it other problems. First, middleboxes
which maintain state must use timers to expire that state for UDP
flows, since there is no exposure of flow lifetime and bidirectional
establishment as with TCP's SYN, ACK, FIN, and RST flags. These
timers are often set fast enough to require a relatively high rate of
heartbeat traffic to maintain this state. A limited facility to
expose basic semantics of the underlying transport protocol would
allow these devices to keep state as they do with TCP, with no worse
characteristics with respect to state management than those of TCP.
This is a specific case of a more general issue: some of the
inspection of traffic done by middleboxes above the network-transport
boundary is operationally useful. However, the use of transport
layer and higher layer headers is an implicit feature of the
architecture: middleboxes are exploiting the fact that these headers
are transmitted in cleartext. There is no explicit cooperation here:
the endpoints have no control over the information exposed to the
path, and the middleboxes no information about the intentions of the
endpoint application other than that inferred from the inspected
traffic. We propose a change to the architecture to remedy this
condition.
2. Explicit Cooperation as Architectural Principle
The principle behind this change is one of explicit cooperation.
The present Internet architecture is rife with implicit cooperation
between endpoints and devices on the path between them. It is this
implicit cooperation which has led to the ossification of the
transport layer in the Internet. Implicit cooperation requires
devices along the path to make assumptions about the format of the
packets and the nature of the traffic they are forwarding, which in
turn leads to problems using protocols which don't meet these
assumptions. It also forces application and transport protocol
developers to build protocols that operate in this presumed, least-
common-denominator network environment.
This situation can be improved by making this cooperation explicit.
We first explore the properties of an ideal architecture for explicit
cooperation, then consider the constraints imposed by the present
configuration of the Internet which would make transition to this
ideal architecture infeasible. From this we derive a set of
architectural principles and protocol design requirements which will
support an incrementally deployable approach to explicit cooperation
between applications on endpoints and middleboxes in the Internet.
Trammell Expires March 26, 2016 [Page 3]
Internet-Draft Explicit Cooperation September 2015
2.1. What does good look like?
We can take some guidance for the future from the original Internet
architecture.
The original Internet architecture defined the split between TCP and
IP by defining IP to contain those functions the gateways need to
handle (and possibly de- and re-encapsulate, including
fragmentation), while defining TCP to contain functions that can be
handled by hosts end-to-end [RFC0791]. Gateways were essentially
trusted not to meddle in TCP.
As a first principle, a strict division between hop-to-hop and end-
to-end functions is desirable to restore and maintain end-to-end
service in the Internet.
In the original architecture, there was no provision for "in-network
functionality" beyond forwarding, fragmentation, and basic
diagnostics. Forwarding is inherently explicit: placing an address
in the destination address field, the endpoint (and by extension, the
application) indicates that a packet should be sent to a given
address. Fragmentation was implicit in IPv4, though in-network
fragmentation was removed in IPv6 [RFC2460]. This was as much a
function of adherence to the end-to-end-principle [Saltzer84] as it
was an engineering reaction to limited computational and state
capacity on the gateways.
We note that layer boundaries can be enforced using sufficiently
strong cryptography.
As a second principle, in-network functionality along a path which
results in the modification of packet streams received at the other
end of a connection should be explicitly visible (and, where
appropriate to the nature of the functionality, controllable) by the
endpoints.
This explicitness extends into the transport stack in the endpoint.
When applications can clearly define transport requirements, instead
of implicitly lensing them through known implementations of each
socket type, these transport requirements can be exposed to and/or
matched with properties of devices along the path, where that is
useful.
2.2. What keeps us from getting there?
The clear separation of network and transport layer has been steadily
eroded over the past twenty years or so. Network address and port
translation (NAPT) have effectively made the first four bytes of the
Trammell Expires March 26, 2016 [Page 4]
Internet-Draft Explicit Cooperation September 2015
transport header a de-facto part of the network layer, and have made
it difficult to deploy protocols where NAPT devices don't know that
the ports are safe to touch: anything other than UDP and TCP.
Protocols to support NAT traversal (e.g. Interactive Connectivity
Establishment [RFC5245]) do not address this fundamental issue.
Mechanisms that could be used to support explicit cooperation between
applications and middleboxes could be supported within the network
layer. The IPv6 Hop-by-Hop Options Header is intended for this
purpose, and a new hop-by-hop option could be defined. However,
there are some limitations to using this header: it is only supported
by IPv6, it may itself cause packets to be dropped, it may not be
handled efficiently (or indeed at all) by currently deployed routers
and middleboxes [I-D.baker-6man-hbh-header-handling], and it requires
changes to operating system stacks at the endpoints to allow
applications to access these headers.
One of the effects of the fact that cryptography enforces layer
boundaries is that applications and transports run over HTTPS de
facto [I-D.blanchet-iab-internetoverport443], since HTTPS is the most
widely implemented, accessible, and deployable way for application
developers to get this enforcement.
However, the greatest barriers to explicit cooperation between
applications and devices along the path is the lack of explicit trust
among them. While it is possible to assign trust within the "first
hop" administrative domains, especially when the endpoint and network
operator are the same entity, building and operating an
infrastructure for assigning and maintaining these trust
relationships within an Internet context is currently impractical.
Finally, the erosion of the end-to-end principle has not occurred in
a vacuum. There are incentives to deploy in-network functions, and
services that are impaired by them have already worked around these
impairments. For example, the present trend toward service
recentralization can be seen in part as the market's response to the
end of end-to-end. If every application-layer transaction is
mediated by services owned by the application's operator, two-end NAT
traversal is no longer important. This new architecture for services
has additional implications for the types of interactions supported,
and for the types of business models encouraged, which may in turn
make some of the concerns about limited deployability of new
transport protocols moot.
Trammell Expires March 26, 2016 [Page 5]
Internet-Draft Explicit Cooperation September 2015
2.3. What can we do?
First we turn to the problem of re-separation of the network layer
from the transport layer. NAPT, as noted, has effectively made the
ports part of the network layer, and this change is not easy to undo,
so we can make this explicit. In many NAPT environments only UDP and
TCP traffic will be forwarded, and a packet with a TCP header may be
assumed by middleboxes to have TCP semantics; therefore, the solution
space is most probably constrained to putting the "new" separation
between the network and transport layers within a UDP encapsulation.
Since the relative delay in getting new transport protocols into
widely deployed kernel implementations has historically been another
impediment to deploying these new protocols in the Internet, a UDP
encapsulation based approach has a further implication for
incremental deployability: it is possible to implement UDP-based
encapsulations in userspace. While userspace implementations may
lack some of the interfaces to lower layers available to kernelspace
implementations necessary to build high-performance transport
implementations, the ability to deploy widely and quickly may help
break the chicken-and-egg problem of getting a transport protocol
adopted into kernelspace.
To support explicit cooperation in an environment where trust
relationships are variable and there may be no context with which to
authenticate every device along a path with which a
3. Properties of encapsulation and signaling mechanisms
We now turn to observations about and probable constraints on an
encapsulation and signaling-based approaches to explicit cooperation.
These thoughts are presently unordered, some having come from initial
efforts at defining requirements for SPUD.
3.1. The narrowness of encapsulation
A good deal of experience with tunnels has shown that the per-stream
overhead of a given encapsulation is generally less important than
its impact on MTU. For instance, the SPUD prototype as presently
defined needs at least 20 additional bytes in the header per packet:
2 each for source and destination UDP port, 2 for UDP length, 2 for
UDP checksum, 8 to identify tubes, 1 for control bits for SPUD
itself, and 3 for the smallest possible CBOR map containing a single
opaque higher layer datagram. For 1500-byte Ethernet frames, the
marginal cost of SPUD before is therefore 1.33% in byte terms, but it
does imply that 1450 byte application datagrams will no longer fit in
a single SPUD-over-UDP-over-IPv4-over Ethernet packet.
Trammell Expires March 26, 2016 [Page 6]
Internet-Draft Explicit Cooperation September 2015
This fact has two implications for encapsulation design: First,
maximum payload size per packet should be communicated up to the
higher layer, as an explicit feature of the transport layer's
interface. Second, link-layer MTU is a fundamental property of each
link along a path, so any signaling protocol allowing path elements
to communicate to the endpoint should treat MTU as one of the most
important properties along the path to explicitly signal.
3.2. Implicit trust in endpoint-path signaling
In a perfect world, the trust relationships among endpoints and
elements on path would be precisely and explicitly defined: an
endpoint would explicitly delegate some processing to a network
element on its behalf, network elements would be able to trust any
command from any endpoint, and the integrity and authenticity of
signaling in both directions would be cryptographically protected.
However, both the economic reality that the users at the endpoints
and the operators of the network may not always have aligned
interests, as well as the difficulty of universal key exchange and
trust distribution among widely heterogeneous devices across
administrative domain boundaries, require us to take a different
approach toward building deployable, useful metadata signaling.
We observe that imperative signaling approaches in the past have
often failed in that they give each actor incentives to lie.
Markings to ask the network to explicitly treat some packets as more
important than others will see their value inflate away - i.e., most
packets from most sources will be so marked - unless some mechanism
is built to police those markings. Reservation protocols suffer from
the same problem: for example, if an endpoint really needs 1Mbps, but
there is no penalty for reserving 1.5Mbps "just in case", a
conservative strategy on the part of the endpoint leads to over-
reservation.
3.3. Declarative marking
An alternate approach is to treat these markings as declarative and
advisory, and to treat all markings on packets and flows as relative
to other markings on packets and flows from the same sender. In this
case, where neither endpoints nor path elements can reliably predict
the actions other elements in the network will take with respect to
the marking, and where no endpoint can ask for special treatment at
the expense of other endpoints, the incentives to marking inflation
are greatly diminished.
Trammell Expires March 26, 2016 [Page 7]
Internet-Draft Explicit Cooperation September 2015
3.4. Verifiable marking
Second, markings and declarations should be defined in such a way
that they are verifiable, and verification built end to endpoints and
middleboxes wherever practical. Suppose for example an endpoint
declares that it will send constant-bitrate, loss-insensitive traffic
at 192kbps. The average data rate for the given flow is trivially
verifiable at any endpoint. A firewall which uses this data for
traffic classification and differential quality of service may spot-
check the data rate for such flows, and penalize those flows and
sources which are clearly mismarking their traffic.
We note that it is optimistic to assume, especially in an environment
with ubiquitous opportunistic encryption [RFC7435], that it is
possible to define a useful marking vocabulary such that every
marking will be so easily verifiable. However, using verifiability
as a design goal can lead to marking vocabularies which are less
likely, on balance, to be be gameable and gamed.
3.5. Privacy Tradeoffs in Metadata Signaling
Protocol engineering experience has shown that extensibility is a key
design goal for new protocols: especially in this case, an attempt to
"de-ossify" the protocol stack is really an attempt to "re-ossify" it
around new realities and requirements, so it makes sense to ensure
this effort must not be repeated. However, extensibility brings with
it the potential for adding new metadata which can be used to
increase linkability and surveillability of traffic. Identifiers
used internally by the signaling mechanism may also increase
linkability. Care must be taken when designing identifier spaces and
extensibility mechanisms to minimize these risks.
3.6. In-band, out-of-band, piggybacked, and interleaved signaling
Signaling channels may be in-band (that is, using the same 5 tuple as
the encapsulated traffic) or out-of-band (using another channel and
different flows). Here there are also many tradeoffs to consider.
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.
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 encapsulated transport and/or opportunistically using bits
Trammell Expires March 26, 2016 [Page 8]
Internet-Draft Explicit Cooperation September 2015
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 contrast, interleaved signaling uses signaling packets on the same
5-tuple. This reduces complexity and sidesteps MTU problems, but is
only applicable when the signaling can be considered valid for the
entire flow or bound to some subset of packets in the flow via an
identifier.
Out-of-band signaling uses direct connections between endpoints and
middleboxes, separate from the encapsulated 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 encapsulated transport; 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 a comprehensive
approach may use a mix of all these communication patterns.
3.7. Reflection protection and return routability
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
leads to UDP being useful for reflection and amplification attacks,
which in turn 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.
Return routability is therefore a minimal property of any transport
that can be responsibly deployed at scale in the Internet.
Trammell Expires March 26, 2016 [Page 9]
Internet-Draft Explicit Cooperation September 2015
4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
This revision of this document presents no security considerations.
A more rigorous definition of the limits of declarative and
verifiable marking would need to be evaluated against a specified
threat model, but we leave this to future work.
6. Acknowledgments
Many thanks to the attendees of the IAB Workshop on Stack Evolution
in a Middlebox Internet (SEMI) in Zurich, 26-27 January 2015; most of
the thoughts in this document follow directly from discussions at
SEMI and the subsequent SPUD BoF in Dallas in March 2015. Some text
for this revision of this document has been taken from
[I-D.trammell-spud-req], written with Mirja Kuehlewind, David Black,
Ken Calvert, Ted Hardie, Joe Hildebrand, Jana Iyengar, and Eric
Rescorla. This work is partially supported by the European
Commission under Grant Agrement FP7-318627 mPlane; support does not
imply endorsement by the Commission of the content of this work.
7. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, DOI
10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
Trammell Expires March 26, 2016 [Page 10]
Internet-Draft Explicit Cooperation September 2015
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-14
(work in progress), June 2015.
[I-D.ietf-taps-transports]
Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
provided by IETF transport protocols and congestion
control mechanisms", draft-ietf-taps-transports-06 (work
in progress), July 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.blanchet-iab-internetoverport443]
Blanchet, M., "Implications of Blocking Outgoing Ports
Except Ports 80 and 443", draft-blanchet-iab-
internetoverport443-02 (work in progress), July 2013.
[I-D.baker-6man-hbh-header-handling]
Baker, F., "IPv6 Hop-by-Hop Header Handling", draft-baker-
6man-hbh-header-handling-02 (work in progress), July 2015.
[I-D.trammell-spud-req]
Trammell, B. and M. Kuehlewind, "Requirements for the
design of a Substrate Protocol for User Datagrams (SPUD)",
draft-trammell-spud-req-00 (work in progress), July 2015.
[Saltzer84]
Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
in System Design (ACM Trans. Comp. Sys.)", 1984.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
Trammell Expires March 26, 2016 [Page 11]
Internet-Draft Explicit Cooperation September 2015
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/
RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>.
[I-D.trammell-stackevo-newtea]
Trammell, B., "Thoughts a New Transport Encapsulation
Architecture", draft-trammell-stackevo-newtea-01 (work in
progress), May 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-01 (work in progress), July 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.
Author's Address
Brian Trammell (editor)
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Email: ietf@trammell.ch
Trammell Expires March 26, 2016 [Page 12]
