Thoughts on New Transport Encapsulation Approaches
draft-trammell-stackevo-newtea-00

Abstract

This document presently consists of a collection of unordered thoughts about new approaches to using encapsulation in support of stack evolution and new transport protocol deployment in an increasingly encrypted Internet. It aims eventually to enumerate a set of architectural assumptions for transport evolution based upon new encapsulations, and discuss limitations on the vocabulary used in each of these new interfaces necessary to achieve deployment

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 September 10, 2015.

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

The current work of the IAB IP Stack Evolution Program is 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 APIs (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.

This problem is already being addressed in various ways by the IETF. The Transport Services (TAPS) Working Group will define a new abstract interface for specifying transport requirements to the transport layer, with a vocabulary based upon existing transport protocol service features. This will allow the transport layer itself, presumably implemented in a library to be used by application developers, to select a wire protocol based upon these requirements and the properties of the middleboxes on path and which protocols they allow end-to-end.

The Substrate Protocol for User Datagrams (SPUD) mailing list and Birds of a Feather (BoF) session at IETF 92 in Dallas in March 2015 is discussing use cases and a prototype protocol [I-D.hildebrand-spud-prototype] for encapsulating opaque (i.e., probably encrypted) content in UDP, with a facility for signaling limited transport semantics and binding metadata to packets and flows in a flexible way. This encapsulation is designed to provide explicit cooperation between endpoints and middleboxes where this makes sense, while allowing new transport protocol development to happen both in kernelspace as well as in userspace.

Both of these efforts aim at building flexible mechanisms to solve, respectively, the problem of expanding the interface between the transport layer and the applications above it, and the problem of making explicit the contract between the transport layer and devices on path which should, in an end-to-end Internet, limit themselves to lower-layer interactions, but practically speaking have not done for the last two decades.

This document aims to tie these efforts together, enumerating a set of architectural assumptions for transport evolution based upon new encapsulations, and discussing limitations on the vocabulary used in each of these new interfaces necessary to achieve deployment. At the moment, however, given that it was written a few minutes before deadline, this document consists of an unordered collection of thoughts toward that aim.

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.

2.1. 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.

2.2. 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.

2.3. Mark reputation

It is probably not possible, especially in an environment with ubiquitous opportunistic encryption [RFC7435], to define a useful marking vocabulary such that every marking will be so easily verifiable. However, in an environment in which markings are implicitly trusted but verified, the trustworthiness of each endpoint and path can be independently assessed by any node involved in a communication, and reputation-tracking approaches can be used to signal how believable a declaration is to transport protocols which use those declarations, as well as to provide an additional incentive to mark honestly.

Network address translation, of course, makes it difficult to identify nodes to which to assign reputation, in the absence of some cryptographically protected identity. Encapsulation approaches can help make reputation-tracking more feasible by at least making it difficult for an attacker to spoof an endpoint or node in order to ruin its reputation.

The possibility to assign reputation to metadata has interface implications, as well. A transport layer which uses reputation or other trustworthiness information about metadata received from the path should make that reputation information available to the application. Conversely, a transport layer interface that allows an application to expose information about its traffic to the path should be designed to make honest declarations easier to make than dishonest ones, e.g. by defaulting to making declarations based on locally measured quanitites.

3. Encapsulations are narrow

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.

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.

4. IANA Considerations

This document has no considerations 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.

7. Informative References

Author's Address

Table of Contents

• 1. Introduction
• 2. Implicit trust in endpoint-path signaling
• 2.1. Declarative marking
• 2.2. Verifiable marking
• 2.3. Mark reputation
• 3. Encapsulations are narrow
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgments
• 7. Informative References
• Author's Address