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

Versions: 00 01

INTERNET-DRAFT                                                T. Herbert
Intended Status: Informational                                  Facebook
Expires: January 7, 2017

                                                            July 6, 2016


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


Abstract

   This specification defines a mechanism to encapsulate layer 4
   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. Transport connection
   identification can be disassociated from network location (IP
   addresses) to provide connection persistence for mobility and across
   state eviction in NAT.

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




Herbert                 Expires January 7, 2017                 [Page 1]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   Copyright (c) 2016 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.



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
   3  Disassociated location encapsulation  . . . . . . . . . . . . .  8
     3.1 Packet format  . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2 Session identifiers  . . . . . . . . . . . . . . . . . . . .  9
     3.3 TOU Identity . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.4 Connection tuple . . . . . . . . . . . . . . . . . . . . . . 10
     3.5 Session lookup tables  . . . . . . . . . . . . . . . . . . . 11
     3.6 Session identifier negotiation . . . . . . . . . . . . . . . 11
     3.7 Transport connection lookup  . . . . . . . . . . . . . . . . 13
     3.8 Established state  . . . . . . . . . . . . . . . . . . . . . 14
     3.9 Learning addresses and ports . . . . . . . . . . . . . . . . 14
     3.10 Closing a sessions  . . . . . . . . . . . . . . . . . . . . 14
     3.11 Session creation deferral . . . . . . . . . . . . . . . . . 14
   4  TCP over UDP  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.1 Mapping TCP state to TOU session state . . . . . . . . . . . 15
     4.2 Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     4.3 SYN cookies  . . . . . . . . . . . . . . . . . . . . . . . . 15
   5  Security Considerations . . . . . . . . . . . . . . . . . . . . 16
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 17
     7.2  Informative References  . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18





Herbert                 Expires January 7, 2017                 [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 is 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.

   TOU allows "disassociated location" for connection identification at
   the end points. That is the identification of a connection for a
   received packet can be independent of the network layer addresses of
   the packet. Disassociated location enables connection persistence for
   different use cases in mobility and NAT state eviction.

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



Herbert                 Expires January 7, 2017                 [Page 3]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


         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.

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



Herbert                 Expires January 7, 2017                 [Page 4]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   identify connections at the endpoints independent of IP addresses or
   UDP ports. A similar concept is adopted for TOU in the session
   abstraction.

   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
   (e.g. UDP, DCCP, UDP-lite) and stateful protocols (e.g TCP, SCTP).

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         | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
   |           Length              |          Checksum             | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |0x0|C|   Hlen  |  Proto/ctype  |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     GUE Fields (optional)                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Transport layer packet                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Herbert                 Expires January 7, 2017                 [Page 5]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   Proto/ctype contains the IP protocol number of the GUE payload, in
   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 zero for TOU indicating that GUE is carrying a data packet.
   Certain general GUE flags and 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         | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
   |           Length              |          Checksum             | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |0x0|0|    0    |   Protocol    |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Transport layer packet                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


















Herbert                 Expires January 7, 2017                 [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         | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
   |           Length              |          Checksum             | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |0x0|0|   0     |       6       |             0                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   |          Source Port          |       Destination Port        | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                        Sequence Number                        | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                    Acknowledgment Number                      | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |  Data |           |U|A|P|R|S|F|                               | TCP
   | 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 January 7, 2017                 [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 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 is
   changed to only cover the transport layer ports and not the IP
   addresses. Note that the addresses in a packet traversing NAT may be
   changed so that the pseudo header checksum for TOU would no longer be
   correct-- not including the addresses in the pseudo header checksum
   avoids these bad checksums. In this case the IP addresses are already
   covered in IPv4 header checksum or the outer UDP checksum for IPv6.

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 changing. 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 two field are defined for TOU.
   The format of this encapsulation is illustrated below:









Herbert                 Expires January 7, 2017                 [Page 8]


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         | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
   |           Length              |          Checksum             | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |0x0|0|  Hlen  |    Protocol    |       0     |S|D|      0      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Source session identifier                    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +               Destination session identifier                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Transport layer packet                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      D: Destination session identifier bit. This indicates the presence
         of the destination session identifier field.

      Source session identifier: 64-bit field that holds the source
         (sender's) session identifier.

      Destination session identifier: 64-bit field that holds the
         destination (receiver's) session identifier.

3.2 Session identifiers

   A session represents a flow of packets that correspond to the same
   transport layer connection. Sessions are identified by a pair of
   session identifiers where both sides of a connection create session
   identifier for the session. Session identifier negotiation
   establishes the session pair between two hosts so that each host will
   know both the locally created session identifier as well as the one
   created by the remote peer. When a packet is sent on a session the
   peer's session identifier is included in the packet, on reception the
   received session identifier is matched to a session.

   A session has identifier has two uses:




Herbert                 Expires January 7, 2017                 [Page 9]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


      1) A 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. Local session
   identifiers must be unique in the name space of each node in the
   communication. Each side of a transport communication creates a local
   session identifier for a session.

3.3 TOU Identity

   TOU disassociates the IP address of a peer from the abstraction of
   transport protocol endpoint. A peer's identity is implicit in session
   identifiers that are established between the two nodes of a
   communications session. All packets sent in the session contain a
   session identifier. Each local 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. Note that sessions identifiers are not symmetric for both
   directions of a flow.

   Transport layer communications occurs between two nodes in a network.
   Nodes in this context are 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.4 Connection tuple

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



Herbert                 Expires January 7, 2017                [Page 10]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   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 at receive by the 4-
   tuple:

      <protocol, destination SID, 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. A single
   session could be used to multiplex several connections over the same
   session however that is not recommended. If such semantics are needed
   the transport layer protocol can provide that (SCTP sub-streams for
   instance). A transport layer connection may be sent using different
   session identifiers during its lifetime. This may be useful for
   instance to limit tracking of long lived transport connections.

3.5 Session lookup tables

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

      - Local session table

         The tuple used to match in this table is:

            <srcIP, dstIP, udp_sport, udp_dport, source_SID>

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

            <destination_SID>

   The session negotiation table is consulted when a TOU packet is
   received where the S bit is set and the D bit is not set-- most
   commonly this occurs when session negotiation is being performed. The
   established sessions table is consulted when the D bit is set in a
   TOU packet.

3.6 Session identifier negotiation

   The process of session identifier negotiation is:



Herbert                 Expires January 7, 2017                [Page 11]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


      1) The initiating host creates its session state and local session
         identifier. The process is:

         a) Create a 64-bit random number

         b) Check the local sessions table if a state with a local
            session identifier of the same value exists

            - If no session has that same local identifier it is
               considered unique. Process to next step.

            - Else, the proposed value is not unique. Repeat the process
               (got back to step a.)

      2) Send a TOU packet with the S bit set and the source session
         identifier set to the value created in step 1.

      3) Peer host receives the TOU packet. Since the S bit is set and
         the D bit is not set this indicates session identifier
         negotiation.

      4) The target creates a proposed session identifier. This is based
         on a secure hash over the 6-tuple:

         <srcIP, dstIP, udp_sport, udp_dport, source_SID, gen>

         srcIP, dstIP, udp_sport, udp_dport, and source_SID are the
         respective values in the packet. gen is a generation number for
         the algorithm. For the first invocation this value is zero. The
         hash calculation should include a randomly seeded key.

      5) The target performs a lookup on the proposed local session
         identifier. There are three possibilities:

         - If no session is found with the same identifier proceed with
           the next step. This is a new negotiation.

         - If a matching session is found and it is less than N seconds
           old and the saved local IP address, remote IP adress, local
           UDP port, remote UDP port, and peer SID match the dstIP,
           srcIP, udp_dport, udp_sport, and source_SID in the packet--
           then the session negotiation is considered a retransmission.
           Goto step 7.

         - Else, the proposed local session identifier is not unique.
           Repeat the process with an incremented generation number
           (goto step 4).




Herbert                 Expires January 7, 2017                [Page 12]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


      6) Create a new session state. Save the IP address, UDP port
         numbers, the source_SID as the remoteSID, and the created SID
         value as the local SID.

      7) Send a response packet (e.g. a TCP SYN-ACK) with both the S bit
         and the D bit set. The source session identifier is the local
         session identifier, the destination is the remote session
         identifier that was learned from the initiator.

      8) When the intitiator receives the packet it will match the local
         session based on the destination session identifier. The source
         session identifier is recorded in the session state.

         The initiator responds (e.g. final ACK in TCP 3WHS) with both
         the source and destination identifiers set (to allow use with
         SYN cookies). The destination session identifier contains the
         value learned from the target.

      9) When the target receives a TOU packet with the D bit set and
         matches a session, this indicates that session negotiation is
         complete. Any subsequent packets sent by either the target or
         initiator will only have the destination session identifer set.

3.7 Transport connection lookup

   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.



Herbert                 Expires January 7, 2017                [Page 13]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


3.8 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 destination session identifier is set in
   packets by both sides of the connection to the peer's session
   identifier. When either side receives a packet a lookup is performed
   on the destination session identifier in the established sessions
   table.

3.9 Learning addresses and ports

   After session negotiation is complete connection identification is
   disassociated from the network layer, however a host still needs to
   know the IP address and destination UDP port to send a TOU packets to
   a destination. These are learned from received packets and are
   recorded in the session state.

   The destination address and port for a session can change over time
   (for example a NAT may remap the UDP flow to use different addresses
   and ports). The peer address and port are inferred from the source
   address and port in packets received over the session. When a packet
   on a session is received and has been fully validated (session state
   matched and authenticity is verified by  security mechanisms such as
   DTLS), if the source address or source port does not match those
   recorded in the session state then the new values are saved in the
   session state; packets subsequently sent will use the new address and
   port for the destination.

3.10 Closing a sessions

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

3.11 Session creation deferral

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

4  TCP over UDP

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



Herbert                 Expires January 7, 2017                [Page 14]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   mobile.

4.1 Mapping TCP state to TOU session state

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

   For SYN packets the destination session identifier must be zero (D
   bit is not set). The source session identifier is set to a value that
   is unique among all connections in the client name space as described
   in section 3.6.

   Replies to SYN, ie. SYN-ACK packets, must have both the source and
   destination identifiers set (D bit and S bit are set). The source
   identifier on the responding host is created as described in section
   3.6.

   The final ACK to complete TWS and all packets sent in established
   state and beyond only include the destination session (only the D bit
   is set).

   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.

   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.2 Resets

   TCP resets may be sent with either the destination session identifier
   set or the source session identifier set. If the reset is being sent
   based on an existing connection state with negotiated session
   identifiers, then the peer session identifier is used as the
   destination session identifier in the reset packet. If the reset is
   generated without any associated session state, then the destination
   session identifier in the packet that generated the reset is used as
   the source session identifer in the reset packet.

4.3 SYN cookies

   For SYN cookies, a target may send a SYN-ACK without creating a
   session state. A session identifier should be created so that it is



Herbert                 Expires January 7, 2017                [Page 15]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   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. As described in section 3.6 the
   session identifier created in response to a SYN packet is based on a
   secure hash and so is useful for validation of SYN cookies.

5  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
   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         | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
   |           Length              |          Checksum             | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |0x0|0|   Hlen  |      59       |       0   |T|S|D|      0      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Payload Transform Field                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Source session identifier                    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +               Destination session identifier                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~               Encrypted transport layer packet                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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



Herbert                 Expires January 7, 2017                [Page 16]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


   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.

6  IANA Considerations

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

   Port 6080 has been reserved for GUE, however we will request another
   port specfically for TOU. GUE would be used on this TOU port, however
   only TOU that encapsulates a transport protocol with TCP-friendly
   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 subject to reflection or
   other attacks common to some uses of UDP.

7  References

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

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



Herbert                 Expires January 7, 2017                [Page 17]


INTERNET DRAFT     Transport layer protocols over UDP       May 19, 2016


             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
             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 January 7, 2017                [Page 18]


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