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

Network Working Group                                        B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Informational                            March 09, 2015
Expires: September 10, 2015

           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

Trammell               Expires September 10, 2015               [Page 1]
Internet-Draft           Encapsulation Thoughts               March 2015

   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.

Trammell               Expires September 10, 2015               [Page 2]
Internet-Draft           Encapsulation Thoughts               March 2015

   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

Trammell               Expires September 10, 2015               [Page 3]
Internet-Draft           Encapsulation Thoughts               March 2015

   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.

Trammell               Expires September 10, 2015               [Page 4]
Internet-Draft           Encapsulation Thoughts               March 2015

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

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, May 2014.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, December 2014.

Trammell               Expires September 10, 2015               [Page 5]
Internet-Draft           Encapsulation Thoughts               March 2015

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for
              Browser-based Applications", draft-ietf-rtcweb-overview-13
              (work in progress), November 2014.

   [I-D.hildebrand-spud-prototype]
              Hildebrand, J. and B. Trammell, "Substrate Protocol for
              User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
              prototype-02 (work in progress), March 2015.

Author's Address

   Brian Trammell
   ETH Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Email: ietf@trammell.ch

Trammell               Expires September 10, 2015               [Page 6]