[Docs] [txt|pdf] [Tracker] [Email] [Nits]



INTERNET-DRAFT                                                T. Herbert
Intended Status: Informational                                  Facebook
Expires: November 20, 2016

                                                            May 19, 2016


                   Transport layer protocols over UDP
                  draft-herbert-transports-over-udp-00


Abstract

   This specification defines a mechanism to encapsulate layer four
   transport protocols over UDP. Such encapsulation facilitates
   deployment of alternate transport protocols or transport protocol
   features on the Internet. DTLS can be employed to encrypt the
   encapsulated transport header in a packet thus minimizing the
   exposure of transport layer information to the network and so
   promoting the end-to-end networking principle.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Herbert                Expires November 20, 2016                [Page 1]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   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.



Table of Contents

   1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  5
   2 Basic encapsulation  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1 Encapsulation format . . . . . . . . . . . . . . . . . . . .  5
     2.2 Direct transport protocol encapsulation  . . . . . . . . . .  6
     2.3 Encapsulated Extension headers . . . . . . . . . . . . . . .  8
     2.4 Obfuscating transport layer protocol number  . . . . . . . .  8
   3 Disassociated location encapsulation . . . . . . . . . . . . . .  9
     3.1 Packet format  . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2 TOU Identity . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.4 Communication roles  . . . . . . . . . . . . . . . . . . . . 11
     3.5 Session identifier format  . . . . . . . . . . . . . . . . . 11
     3.6 Connection tuple . . . . . . . . . . . . . . . . . . . . . . 12
     3.7 Operation  . . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.7.1 Session lookup tables  . . . . . . . . . . . . . . . . . 12
       3.7.2 Transport connection lookup  . . . . . . . . . . . . . . 13
       3.7.3 Session identifier negotiation . . . . . . . . . . . . . 14
       3.7.3 Established state  . . . . . . . . . . . . . . . . . . . 16
       3.7.4 Closing a sessions . . . . . . . . . . . . . . . . . . . 16
       3.7.5 Session creation deferral  . . . . . . . . . . . . . . . 16
     3.8 TCP over UDP example . . . . . . . . . . . . . . . . . . . . 16
   4  Security Considerations . . . . . . . . . . . . . . . . . . . . 17
   5  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.1  Normative References  . . . . . . . . . . . . . . . . . . . 19
     6.2  Informative References  . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20







Herbert                Expires November 20, 2016                [Page 2]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


1 Introduction

   This specification defines Transport Layer Protocols over UDP (TOU)
   as generic mechanism to encapsulate IP transport protocols over UDP
   [RFC0768]. The purpose of TOU to facilitate the use of alternate
   protocols and protocol mechanisms over the Internet.

   The realities of protocol ossification in the Internet, particularly
   the infeasibility of deploying IP protocol extensions and alternative
   transport protocols (protocols other than UDP and TCP), have been
   well documented. A direction to resolve protocol ossification is
   suggested in RFC7663 [RFC7663]:

      "... putting a transport protocol atop a cryptographic protocol
      atop UDP resets the transport versus middlebox tussle by making
      inspection and modification above the encryption and demux layer
      impossible."

   Accordingly, this specification provides a method to encapsulate
   transport layer protocols in UDP and allows encrypting most of the
   UDP payload including the encapsulated transport headers and
   payloads. This solution espouses a model that only the minimal
   necessary information about the packet is made visible to the
   network. This exposed information is sufficient to route the packet
   through the network and to demultiplex and decrypt the packet at the
   receiving end host. In particular, the encapsulated protocol and
   related connection state may be rendered invisible to the network.
   Additionally, this solution allows encapsulation of IPv6 extension
   headers, particularly destination options, which can then also be
   hidden from inspection in the network.

1.1 Requirements

   The requirements of TOU are:

       - Allow encapsulation of any IP transport layer protocol (e.g.
         TCP, SCTP, UDP, DCCP, etc.) over UDP.

       - Work seamlessly with NAT including conditions where the ports
         or addresses being used for an encapsulated connection change.
         To provide for this we disassociate the layer 4 endpoint
         identification from the IP addresses.

       - Allow encryption/authentication of the encapsulated transport
         packet including transport headers. The encryption algorithm
         should be flexible to allow different methods. Any layer 4
         information that is exposed in cleartext (such as session
         identifier defined below) should be authenticated.



Herbert                Expires November 20, 2016                [Page 3]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


       - Information needed for TOU is sent with along with encapsulated
         transport packets, there are no standalone TOU messages. Any
         negotiation to set up state for TOU should not require any
         additional round trips apart from those needed by the
         encapsulated transport protocol.

       - The solution must not be biased towards any particular
         implementation method. Specifically, TOU should allow for
         transport protocol implementations in userspace, kernel,
         hardware, etc.

       - Minimize changes to transport protocols and implementation. TOU
         should not require any changes to the transport protocol
         proper, however TOU will extend the concept of transport
         endpoints beyond the canonical 5-tuple.

       - Minimize changes to applications. TOU should be enabled with
         existing applications, APIs, and transport protocols without
         needing major rework. The desire to use transport layer
         protocols over UDP should not require applications to adopt
         completely new transport protocols.

1.2 Related work

   Several transport and encapsulation protocols have been defined to be
   encapsulated within UDP [RFC0768]. In this model, the payload of a
   UDP packet contains a protocol header and payload for an encapsulated
   protocol.

   TCP-over-UDP [I-D.chesire-tcp-over-udp] specifies a method to
   encapsulate TCP in UDP. That solution essentially casts UDP header
   into a modified TCP header so that the port numbers simultaneously
   refer to both the UDP and TCP flows. In TOU, the TCP header
   (generally transport header) is encapsulated in UDP without changing
   the header format.

   SCTP-over-UDP [RFC6951] describes a straightforward encapsulation of
   SCTP in UDP. This work should be leverage-able for use with SCTP in
   TOU. One potential benefit of TOU is that disassociated location
   encapsulation (described below) could be used to maintain SCTP
   connections when UDP NAT flow mappings change.

   QUIC [QUIC] implements a new transport protocol that is intended to
   run over UDP. QUIC defines a connection identifier that is used to
   identify connections at the endpoints independent of IP addresses or
   UDP ports. A similar concept is adopted for TOU in the session
   abstraction.




Herbert                Expires November 20, 2016                [Page 4]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   SPUD [I-D.hildebrand-spud-prototype] defines an architecture for
   group grouping UDP packets together in a "tube", also allowing
   network devices on the path between endpoints to participate
   explicitly in the tube outside the end-to-end context. TOU implements
   a subset of the the SPUD architecture but expressly does not require
   or include provisions to leak end-to-end information for consumption
   in the network. The encapsulation protocol used in TOU (GUE) is
   extensible to optionally allow information exposure if this proves to
   be warranted.

1.3 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2 Basic encapsulation

   Generic UDP Encapsulation (GUE) [I-D.ietf-nvo3-gue] is the
   encapsulation protocol for encapsulating transport layer protocols
   over UDP. TOU can encapsulate both stateless transport protocols
   (such as UDP, DCCP, UDP-lite) and stateful protocols (like TCP and
   SCTP). Additionally, TOU may encapsulate IPv6 Destination Options
   extension headers.

2.1 Encapsulation format

   The general format of TOU encapsulation using GUE (UDP) is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Source port            |      Destination port         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Length              |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0x0|C|   Hlen  |  Proto/ctype  |            Flags              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                     GUE Fields (optional)                     ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Transport layer packet                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Proto/ctype contains the IP protocol number of the GUE payload, in



Herbert                Expires November 20, 2016                [Page 5]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   the case of TOU this contains the protocol number of a transport
   protocol (e.g. for TCP over UDP the value is 6). The C bit (control)
   is not used with TOU indicating that GUE is carrying a data packet.
   The flags and fields may be set for TOU as described below. Certain
   general GUE flags-fields, such as remote checksum offload or
   fragmentation, may be useful for TOU but not required for its
   operation. The example packet formats in the remainder of the this
   document do not indicate use of any flags or fields other than those
   required for TOU operation.

   The Hlen contains the GUE header length in 32-bit words, including
   optional fields but not the first four bytes of the header. Computed
   as (header_len - 4) / 4. All GUE headers are a multiple of four bytes
   in length. Maximum header length is 128 bytes.

2.2 Direct transport protocol encapsulation

   Transport protocol packets can be encapsulated directly in GUE. The
   simplest format of this is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Source port            |      Destination port         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Length              |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0x0|0|    0    |   Protocol    |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Transport layer packet                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


















Herbert                Expires November 20, 2016                [Page 6]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   For example, TCP over UDP could be encapsulated as:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Source port            |      Destination port         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Length              |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0x0|0|   0     |       6       |             0                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source Port          |       Destination Port        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Acknowledgment Number                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Data |           |U|A|P|R|S|F|                               |
      | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
      |       |           |G|K|H|T|N|N|                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Checksum            |         Urgent Pointer        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Options                    |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             data                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For TOU the flow identification of the encapsulated transport packet
   includes the encapsulating UDP source and destination port. For a
   transport protocol that uses the canonical ports for flow
   identification, flows are identified by the 7-tuple:

      <Protocol, SrcIP, DstIP, SrcPort, DstPort, SrcUport, DstUport>

   Where protocol refers to the encapsulated protocol (taken from the
   Proto/ctype field in the GUE header), SrcIP and DstIP refer to the
   source and destination IP addresses, SrcPort and DstPort refer to the
   respective ports in the encapsulated transport header, SrcUport and
   DstUport refer to the source and destination ports in the
   encapsulating (outer) UDP header.

   To reply to a transport layer packet encapsulated in TOU, a
   corresponding TOU packet is sent where the source and destination
   addresses, source and destination UDP ports, and source and
   destination transport ports are swapped. The outer addresses and
   ports may have undergone NAT so that the return path must also go
   through NAT. To ensure reachabilty, a host MUST reply to a TOU



Herbert                Expires November 20, 2016                [Page 7]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   encapsulated with a corresponding TOU packet.

   Stateful protocol connections are identified by the 7-tuple as
   defined above. Since the UDP ports are included in the connection
   tuples, the typical transport layer 5-tuple (<Protocol, SrcIP, DstIP,
   Sport, Dport>) of a TOU connection does not need to be unique with
   those of non-TOU connections.

   The inner and outer ports have no correlation. The lengths and
   checksums must also be set correctly in each header layer. In the
   case of UDP over UDP for IPv6 that both the inner and outer checksum
   must be set.

   For encapsulated transport packets that define a checksum that
   includes a pseudo header (e.g. TCP) the checksum pseudo header
   remains the same. The pseudo header includes the IP addresses and
   transport layer ports. In particular the UDP ports are not included
   in that pseudo header and the UDP checksum covers the UDP ports.

2.3 Encapsulated Extension headers

   For IPv6, encapsulation of IPv6 Fragment and Destination Options
   extension headers is permitted. These options are processed at a
   destination after processing the UDP and GUE encapsulation headers.
   Logically, the encapsulation headers are treated as though they are
   themselves extension headers, so processing an encapsulated extension
   header is done in the context of being an extension header within the
   corresponding IP layer packet.

   Since encapsulated extension headers are contained within the UDP
   payload (and the payload may often be encrypted) there is no
   allowance that intermediate devices parse these headers. Extension
   headers that require visibility to intermediate nodes, such as hop by
   hop option or routing header, cannot be encapsulated in TOU.

2.4 Obfuscating transport layer protocol number

   The GUE header indicates the IP protocol of the encapsulated packet.
   This is either contained in the Proto/ctype field of the primary GUE
   header, or is contained in the Payload Type field of a GUE Transform
   Field (used to encrypt the payload with DTLS). If the protocol must
   be obfuscated, that is the transport protocol in use must be hidden
   from the network, then a trivial destination options can be used.

   The PadN destination option can be used to encode the transport
   protocol as a next header of an extension header (and maintain
   alignment of encapsulated transport headers). The Proto/ctype field
   or Payload Type field of the GUE Transform field is set to 60 to



Herbert                Expires November 20, 2016                [Page 8]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   indicate that the first encapsulated header is a Destination Options
   extension header.

   The format of the extension header is below:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Header |    2      |     1     |      0    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For IPv4, it is permitted in TOU to used this precise destination
   option to contain the obfuscated protocol number. In this case next
   header must refer to a valid IP protocol for IPv4. No other extension
   headers or destination options are permitted with IPv4.

3 Disassociated location encapsulation

   TOU allows transport protocol encapsulation where the location is
   disassociated from flow identification. That is a connection can
   remain functional even if the addresses or encapsulation ports
   change. A common use case will be when NAT state mappings for UDP
   flows change. TOU includes a facility to negotiate a shared session
   identifier for a transport connection which is sent as part of the
   encapsulation of packets for the connection. The session identifier
   is used in connection lookup instead of the IP addresses and
   encapsulation ports.

   This section describes the protocol formats and operational aspects
   of TOU for disassociated location transport protocol encapsulation.

3.1 Packet format

   Transport layer packets are encapsulated using Generic UDP
   Encapsulation (GUE). Two GUE flags and one field are defined for TOU.
   The format of this encapsulation is illustrated below:

















Herbert                Expires November 20, 2016                [Page 9]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Source port            |      Destination port         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Length              |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0x0|0|   2  |    Protocol      |       0     |S|I|      0      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Session identifier                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Transport layer packet                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      S: Session identifier bit. This indicates the presence of the
         session identifier field.

      I: Initiator bit. When set indicates that the packet is sent from
         the initiator side of the session, when not set indicates the
         packet is sent from the target.

      Session identifier: 64-bit field that holds the session
         identifier.

3.2 TOU Identity

   TOU disassociates the IP address of a peer from the abstraction of
   transport protocol endpoint. A peer's identity is implicit in a
   session identifier that is established between the two nodes of a
   communications session (corresponding to one transport connection).
   All packets sent in the session contain a session identifier. The
   session identifier is unique among all other communications for a
   node, so the node can use it to distinguish between different
   communicating peers. A session identifier is meaningful only to the
   nodes that share it in a communication, externally to those nodes it
   has no defined meaning. Since session identifiers are disassociated
   with IP addresses, no relevant information can consistently be
   inferred in the network. Two packets containing the same session
   identifier but use different addresses may in fact refer to the same
   session. Two packets with the same session identifier and same
   addresses (and UDP ports) that are temporally observed probably, but
   not definitely, refer to the same session.

   Transport layer communications occurs between two nodes in a network.



Herbert                Expires November 20, 2016               [Page 10]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   Nodes in this context is not restricted to hosts, any application or
   process can be considered a node. A node is unambiguously reachable
   and distinguishable from other nodes, that is if a packet is received
   it must be deterministic as to which node on the host the packet
   belongs. For a server application that listens on one or more UDP
   ports for TOU packets, each listener port instance can be considered
   a node. For a client application, each peer destination (IP address,
   TOU port) might be considered to belong to a different node, however
   for simplicity the whole client application could considered as one
   node.

3.3 Sessions

   TOU uses sessions to enable communications between two nodes using an
   encapsulated transport layer protocol. A session is represented by a
   session identifier. The session identifier has two uses:

      1) An location independent representation of the identities in the
         communication.

      2) Security context for encryption or authentication of the
         encapsulated packet.

   Each node defines a namespace over its communications.  Session
   identifiers must be unique in the name space of each node in the
   communication. Each side of a communication contributes to the
   session identifier so that the identifier is unique relative to each
   node.

3.4 Communication roles

   At the start of a communications the session identifier must be
   negotiated between two nodes. The node that initiates a communication
   is the "initiator" and its peer is the "target". The roles are
   persistent for the lifetime of the session, each packet in the
   session is marked to indicate whether it was sent by the initiator or
   the target.

3.5 Session identifier format

   A session identifier is a 64-bit value that is sent in each packet of
   a session. To ensure relative uniqueness within both nodes of a
   communication, each side contributes part of the session identifier.
   A session identifier negotiation is defined to create the shared
   session identifier.

   The session identifier is split into a 32-bit initiator component and
   a 32-bit target component as illustrated below:



Herbert                Expires November 20, 2016               [Page 11]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Initiator component                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Target component                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Initiator and Target components of the Session Identifier are
   always non-zero except in the case that session identifier
   negotiation is in progress in which case an initiator sends a session
   identifier with a Target component that is zero.

3.6 Connection tuple

   The session identifier, instead of IP addresses, provides the
   endpoint identity of a transport layer connection. As mentioned this
   allows the IP addresses associated with the endpoint addresses to
   change without breaking the connection. The transport layer tuple
   that identifies a specific connection thus changes accordingly to use
   the session identifier instead of addresses.

   For a transport protocol that uses canonical ports for flow
   identification, a flow in TOU is identified by the 4-tuple:

      <protocol, session, source port, destination port>

   Where the source and destination ports refer to the encapsulated
   transport layer ports in a TOU packet.

   A session is created for each transport layer connection, there is no
   concept of multiplexing different transport connections over a single
   sessions. If such semantics are needed the transport layer protocol
   can provide that (SCTP sub-streams for instance).

3.7 Operation

   This section describes the operation of TOU using disassociated
   location encapsulation. TOU state, such as session, is created and
   destroyed in conjunction with corresponding state changes in the
   connection of an encapsulated transport protocol.

3.7.1 Session lookup tables

   TOU logically uses two different tables to perform session lookup.:

      - Session negotiation table

         The tuple used to match in this table is:




Herbert                Expires November 20, 2016               [Page 12]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


            <srcIP, dstIP, udp_sport, udp_dport, ISID>

         Where ISID refers to the initiator component of the session
         identifier, the target component is not considered for lookup
         in the session negotiation table.

      - Established sessions table

         Lookups in the established sessions table are performed on the
         session identifier of a received packet. The lookup tuple in
         established sessions table is trivially:

            <Session identifier>

   Before session negotiation completes connection lookup is always
   performed on the session negotiation table using fixed location mode
   (that is the addresses, ports, and initiator component of the session
   identifier are matched).

   The target must consult the session negotiation table when the Target
   session identifier component of a received packet is zero. It
   consults the established sessions table when the Target component of
   session identifier is non-zero.

   The initiator first consults the established sessions table for every
   packet. If an entry is not found for the session identifier then the
   session negotiation table is consulted. Note that if the ISID is
   unique for all connections in the node then the two tables can be
   consolidated into a single one which is keyed solely by ISID. So in
   this method the session lookup process is:

      1) Initiator performs a lookup based on ISID. If no entry is found
         then the session does not exist in the node's namespace.

      2) If the entry contains a non-zero TSID and the TSID matches that
         received in the packet then this entry is a match. If the TSID
         doesn't match then the session is not matched.

      3) Otherwise the the entry contains a zero value for the transport
         component of the session ID so session negotiation is in
         progress. Perform fixed location verification by matching the
         received address and port numbers to the recorded values. If
         they all match, then the session is matched. The recorded TSID
         is set to the non-zero value received in the packet which
         implicitly moves the entry to the established sessions table.

3.7.2 Transport connection lookup




Herbert                Expires November 20, 2016               [Page 13]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   A connected transport protocol typically maintains one or more tables
   of connections (i.e. multiple tables may be used for different
   connection states). In lieu of using IP addresses, connection lookup
   is performed in TOU using the session (specifically a reference to
   the session).

   For a transport protocol using the canonical definition of ports, the
   tuple for matching connections in TOU becomes:

   <Protocol, Session, Source-port, Destination-port>

   This implies that connection lookup for a received packet involves
   two lookups:

      1) A lookup is performed to find the session.

      2) A connection lookup is performed using the session found in #1
         in the lookup tuple.

   Note that TOU requires that a separate session is created for each
   encapsulated transport layer connection. This  allows consolidating
   session and connection lookup by including a reference to the
   transport connection in the session state.

3.7.3 Session identifier negotiation

   A session must be negotiated between two nodes to create a unique
   session identifier within the namespace of each node. Session
   negotiation is initiated by one node which assumes the role of
   "initiator", and its peer node has the role of "target". Typically,
   initiators would be clients and targets are servers. Initiating a
   session identifier negotiation coincides with the start of connection
   establishment in the encapsulated transport protocol.

   During session identifier negotiation session lookup is be done in
   fixed location mode (IP address, UDP ports, ISID must be matched) for
   either the initiator or the target.

   The steps for session negotiation are:

      1) Initiator creates initial packet for sending to a target with
         an encapsulated transport packet. The transport packet must
         contain an initial packet for establishing a transport layer
         connection (e.g. a TCP-SYN). The initiator component of the
         session identifier is set to a random value that makes it
         unique with other existing sessions in the node; the target
         component is set to zero.




Herbert                Expires November 20, 2016               [Page 14]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


      2) Target receives packet. Since the target portion of the session
         identifier is zero this indicates a session identifier
         negotiation. Target performs a lookup in the session identifier
         negotiation table in fixed location mode. The session
         identifier negotiation table records session negotiations that
         are in progress.

         - If an entry is not found in the session negotiation table
           then this is a new negotiation. The target creates the target
           portion of the session identifier such that whole session
           identifier is unique in the target node's name space. Next
           the target creates a corresponding entry in the session
           negotiation table.

         - If an entry is found, then this is a retransmission of a
           session negotiation packet. The target value saved in the
           entry indicates the value to set in session identifier for
           reply packets.

      3) Target responds with a transport protocol packet. In the case
         of TCP connection establishment this will be a SYN-ACK. The
         fully qualified session identifier is used in the TOU
         encapsulation.

      4) Initiator receives response packet (SYN-ACK). It performs a
         session lookup using the session identifier.

         - First the established sessions table is consulted. If an
           entry for the session identifier is present in the table then
           the session is matched.

         - If no entry is found in the established sessions table, then
           the session negotiation table is consulted. The initiator
           component is used for lookup. If a matching entry is found,
           the addresses and ports in the packet must be verified to
           match the entry using fixed location mode.

      5) Initiator sends an ACK (completing three-way handshake in the
         transport protocol). The fully qualified session identifier is
         used in the TOU encapsulation.

      6) Target receives ACK. Target moves the session entry from the
         session negotiation table to the established sessions table.

   Note that after a session moves to the established sessions table in
   a target, it is possible that an out of order retransmission of an
   initial packet (e.g. SYN) may be received for the session. The TSID
   of the packet is zero and the target will not find the session in the



Herbert                Expires November 20, 2016               [Page 15]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   session identifier negotiation table. The target will treat this as
   new connection and reply to the intiator with different session
   identfier (TSID differs) than that for the established session. When
   the initiator receives the reply packet it may match the ISID to the
   established session, but the TSID in the received packet differs from
   the recorded one so the packet is dropped. The spurious session in
   session negotiation table of the target will be removed when the
   underlying connection times out. Alternatively, the target may
   maintain an entry in the session negotiation table for some period of
   time to identify retransmitted session negotiation packets.

   Since the initiator component is assumed to be unique for all created
   sessions, the session negotiation table and established tables can be
   consolodated into a single table keyed by the initiator component of
   the session identifier.

3.7.3 Established state

   After session establishment, which normally corresponds to transport
   protocol connection being established, running operations commences.
   Each packet sent on the underlying connection will be encapsulated
   using TOU. The 64-bit session identifier is set by both sides of the
   connection, and each side sets the Initiator bit (I bit in the GUE
   header) accordingly-- the initiator sets I bit in all packets of the
   connection, the target clears the bit. When either side receives a
   packet a lookup is performed on the session identifier in the
   established sessions table.

3.7.4 Closing a sessions

   A session is closed when the underlying transport connection closes
   (e.g. a TCP connection moves to closed state).

3.7.5 Session creation deferral

   When a target receives an initial packet (e.g. a TCP SYN with a
   session identifier whose target component is zero) creating a session
   state may be deferred until until the transport layer creates its
   state. If the transport layer does not create a state (e.g. the SYN
   generated a reset) no TOU state is created. The reply packet is
   returned with TOU using the same session identifier received in the
   request (in this case target component of the session identifier is
   zero).

3.8 TCP over UDP example

   TCP over UDP implicitly allows nodes using TCP to be multihomed and
   mobile.



Herbert                Expires November 20, 2016               [Page 16]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   For SYN packets the target session identifier must be set to zero.
   The initiator's session identifier is set to a value that is unique
   among all connections in the client name space.

   The initiator must set the I bit for all packet sent for a
   connection. SYN packets (no ACK) MUST contain a zero value in the
   Target session identifier field. If a SYN packet with a nonzero
   Target Session Identifier is received from an initiator the packet
   must be dropped. All other packets sent by the initiator must have
   the Target Session Identifier set to nonzero, if a non-SYN packet is
   received from an initiator (I bit is set) with a nonzero Target
   session identifier then the packet must be dropped.

   The target must clear the I bit for all packet sent for a connection.
   All packet sent by a target (I bit not set) must have a nonzero
   Target session identifier except in the case that the target is
   rejecting a connection request (e.g. a TCP-RST is sent in reply to a
   TCP-SYN).

   Note that simultaneous opens cannot happen. A simultaneous connection
   attempt between two nodes with same TCP ports will result in two
   different sessions with two different identifiers.

   Session state can be created in conjunction with creating TCP state
   (TCP PCB for instance). If a TCP packet is received for which no
   state exists, a rely to the packet is sent without creating session
   state. For instance this would happen is a TCP stack sends a TCP-RST
   in response to a SYN.

   In the cases of SYN cookies, a target may send a SYN-ACK without
   creating a session state. A session identifier should be created so
   that it is unique with other established sessions or any values used
   in other SYN responses within last N minutes. When a client responds
   to the SYN cookie ACK and the server verifies the SYN cookie is valid
   (including the session identifier) the TCP connection state and
   session state can then be created using the session identifier
   provided in the received packet.

   The session state is destroyed when the underlying TCP connection
   moves to closed state. In the initiator this entails freeing session
   identifier to be used with new connections. At the target, the full
   session identifier is free to be reused.

4  Security Considerations

   Using strong end to end security is recommended with TOU. In
   disassociated location encapsulation security is extremely important
   to prevent spoofing and connection hijacking (assuming that an



Herbert                Expires November 20, 2016               [Page 17]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   attacker can deduce the session identifiers). In order to thwart this
   end to end security should be established that authenticates the
   nodes in a communication.

   Security is provided using DTLS [RFC6347] and the GUE Payload
   Transform Field [I-D.hy-gue-4-secure-transport]. The encapsulation
   format of TOU with DTLS is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Source port            |      Destination port         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Length              |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0x0|0|    3    |   Protocol    |     0     |T|S|I|      0      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Payload Transform Field                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Session identifier (optional)                 +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~               Encrypted transport layer packet                ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The T flag bit in the GUE header indicates the presence of the
   Payload Transform Field.

   The Payload Transform field is defined as:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type       | Payload Type  |            Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: Payload transform codepoint. 0x1 indicates DTLS.

      Payload type: IP protocol of the encrypted payload.

   The Proto/type field in the GUE header is set to 59 "no next header"
   to indicate that the GUE payload cannot be parsed as an IP protocol.

5  IANA Considerations

   Two bits and one field in the GUE header are reserved for TOU use.




Herbert                Expires November 20, 2016               [Page 18]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   Port 6080 has been reserved for GUE, however we will request another
   port specficilly for TOU. GUE would be used on this TOU port, however
   only TOU that encapsulates a transport protocol with TCP-frienly
   congestion control is used. Thus traffic destined to the TOU port (as
   well as traffic in the reverse direction of a flow) can be assumed to
   be properly congestion controlled and not suject to reflection or
   other attacks common to some uses of UDP.

6  References

6.1  Normative References

   [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980, <http://www.rfc-editor.org/info/rfc768>.

   [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
             Security Version 1.2", RFC 6347, January 2012,
             <http://www.rfc-editor.org/info/rfc6347>.

6.2  Informative References

   [RFC7663] B. Trammell, Ed., M. Kuehlewind, Ed. "Report from the IAB
             Workshop on Stack Evolution in a Middlebox     Internet
             (SEMI)}, October 2015.

   [I-D.chesire-tcp-over-udp] Chesire, S., Graessley, J., and McGuire,
             R., "Encapsulation of TCP and other Transport Protocols
             over UDP", June 2013

   [QUIC]    Roskind, J., "QUIC: Multiplexed Stream Transport Over UDP",
             http://www.ietf.org/proceedings/88/slides/slides-88-
             tsvarea-10.pdf

   [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
             Control Transmission Protocol (SCTP) Packets for End-Host
             to End-Host Communication", RFC 6951, May 2013,
             <http://www.rfc-editor.org/info/rfc6951>.

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

   [I-D.ietf-nvo3-gue] Herbert, T., Yong, L., and Zia, O., "Generic UDP
             Encapsulation", draft-ietf-nvo3-gue-01 (work in progress),
             March 2016.

   [I-D.hy-gue-4-secure-transport] Yong, L. and Herbert, T. Generic UDP



Herbert                Expires November 20, 2016               [Page 19]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


             Encapsulation (GUE) for Secure Transport draft-hy-gue-4-
             secure-transport-03 (work in progress), March 2016

   [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
             Security Version 1.2", RFC 6347, January 2012,
             <http://www.rfc-editor.org/info/rfc6347>.



Authors' Addresses

   Tom Herbert
   Facebook
   1 Hacker Way
   Menlo Park, CA
   US

   EMail: tom@herbertland.com

































Herbert                Expires November 20, 2016               [Page 20]


Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/