Skip to main content

An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport Mode
draft-boucadair-mptcp-plain-mode-08

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Mohamed Boucadair , Christian Jacquenet , Denis Behaghel , Stefano Secci , Wim Henderickx , Robert Skog , Olivier Bonaventure , Suresh Vinapamula , SungHoon Seo , Wouter Cloetens , Ullrich Meyer , Luis M. Contreras
Last updated 2016-07-04
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-boucadair-mptcp-plain-mode-08
Network Working Group                                       M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Experimental                                     Orange
Expires: January 5, 2017                                     D. Behaghel
                                                               OneAccess
                                                                S. Secci
                                                                    UPMC
                                                           W. Henderickx
                                                    Nokia/Alcatel-Lucent
                                                                 R. Skog
                                                                Ericsson
                                                          O. Bonaventure
                                                                Tessares
                                                           S. Vinapamula
                                                                 Juniper
                                                                  S. Seo
                                                           Korea Telecom
                                                             W. Cloetens
                                                              SoftAtHome
                                                                U. Meyer
                                                                Vodafone
                                                           LM. Contreras
                                                              Telefonica
                                                            July 4, 2016

An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport
                                  Mode
                  draft-boucadair-mptcp-plain-mode-08

Abstract

   Because of the lack of Multipath TCP (MPTCP) support at the server
   side, some service providers now consider a network-assisted model
   that relies upon the activation of a dedicated function called MPTCP
   concentrator.  This document focuses on a deployment scheme where the
   identity of the MPTCP concentrator(s) is explicitly configured on
   connected hosts.

   This document specifies an MPTCP option that is used to avoid the
   encapsulation of packets and out-of-band signaling between the CPE
   and the MPTCP concentrator.  Also, this document specifies how UDP
   traffic, in particular, can be distributed among available paths by
   leveraging MPTCP capabilities.

Boucadair, et al.        Expires January 5, 2017                [Page 1]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

Requirements Language

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

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 January 5, 2017.

Copyright Notice

   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Assumptions & Scope . . . . . . . . . . . . . . . . . . . . .   7
   4.  Plain Transport Mode Behavior . . . . . . . . . . . . . . . .   8
     4.1.  Plain Mode MPTCP Option . . . . . . . . . . . . . . . . .   9
     4.2.  Carrying the Plain Mode Option  . . . . . . . . . . . . .  10
     4.3.  Binding Tables  . . . . . . . . . . . . . . . . . . . . .  11
       4.3.1.  On the Need to Maintain a State . . . . . . . . . . .  11

Boucadair, et al.        Expires January 5, 2017                [Page 2]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

       4.3.2.  Binding & Transport Session Entries . . . . . . . . .  12
       4.3.3.  Expiration of a Binding Entry . . . . . . . . . . . .  14
     4.4.  Theory of Operation: Focus on TCP . . . . . . . . . . . .  15
       4.4.1.  Processing an Outgoing SYN  . . . . . . . . . . . . .  15
       4.4.2.  Processing an Incoming SYN  . . . . . . . . . . . . .  16
       4.4.3.  Processing Subsequent Outgoing/Incoming Non-SYNs  . .  17
       4.4.4.  Handling TCP RST Messages . . . . . . . . . . . . . .  17
   5.  Processing UDP Traffic  . . . . . . . . . . . . . . . . . . .  18
     5.1.  Behavior  . . . . . . . . . . . . . . . . . . . . . . . .  18
       5.1.1.  UDP to TCP Conversion . . . . . . . . . . . . . . . .  18
       5.1.2.  TCP to UDP Conversion . . . . . . . . . . . . . . . .  20
       5.1.3.  Terminating UDP-Triggered Subflows  . . . . . . . . .  20
     5.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  21
     5.3.  Fragmentation & Reassembly Considerations . . . . . . . .  22
       5.3.1.  Receiving IPv4 Fragments on the Internet-Facing
               Interface of the Concentrator . . . . . . . . . . . .  23
       5.3.2.  Receiving IPv4 Fragments from the LAN . . . . . . . .  24
       5.3.3.  Distinct Address Families . . . . . . . . . . . . . .  24
   6.  Deployment Scenarios  . . . . . . . . . . . . . . . . . . . .  24
   7.  Additional Considerations . . . . . . . . . . . . . . . . . .  26
     7.1.  Authorization . . . . . . . . . . . . . . . . . . . . . .  26
     7.2.  Checksum Adjustment . . . . . . . . . . . . . . . . . . .  27
     7.3.  Logging . . . . . . . . . . . . . . . . . . . . . . . . .  27
     7.4.  Middlebox Interference  . . . . . . . . . . . . . . . . .  27
     7.5.  EPC Billing & Accounting  . . . . . . . . . . . . . . . .  28
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
     9.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  28
     9.2.  Denial-of-Service (DoS) . . . . . . . . . . . . . . . . .  29
     9.3.  Illegitimate Concentrator . . . . . . . . . . . . . . . .  29
     9.4.  High Rate Reassembly  . . . . . . . . . . . . . . . . . .  29
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  29
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     11.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   One of the promising deployment scenarios for Multipath TCP (MPTCP,
   [RFC6824]) is to enable a Customer Premises Equipment (CPE) that is
   connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the
   usage of such resources.  This deployment scenario is called a
   network-assisted MPTCP model, and relies upon MPTCP proxies located
   on both the CPE and network sides (Figure 1).  The latter plays the
   role of an MPTCP concentrator.  Such concentrator terminates the
   MPTCP sessions established from CPEs, before redirecting traffic into
   legacy TCP sessions.

Boucadair, et al.        Expires January 5, 2017                [Page 3]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

  +------------+        _--------_    +----------------+
  |            |       (e.g., LTE )   |                |
  |   CPE      +=======+          +===+  Backbone      |
  | (MPTCP     |       (_        _)   |   Network      |
  |  Proxy)    |         (_______)    |+--------------+|
  |            |       IP Network #1  || Concentrator ||------> Internet
  |            |                      || (MPTCP proxy)||
  |            |                      |+--------------+|
  |            |       IP Network #2  |                |
  |            |        _--------_    |                |
  |            |       ( e.g., DSL )  |                |
  |            +=======+           +==+                |
  |            |       (_        _)   |                |
  +-----+------+        (_______)     +----------------+
        |
  ---- LAN ----
        |
    end-nodes

                 Figure 1: "Network-Assisted" MPTCP Design

   Network-assisted MPTCP deployment models are designed to facilitate
   the adoption of MPTCP for the establishment of multi-path
   communications without making any assumption about the support of
   MPTCP by the communicating peers.  Thus, MPTCP proxies deployed in
   CPEs and in concentrators located in the network are responsible for
   establishing multi-path communications on behalf of endpoints,
   thereby taking advantage of MPTCP capabilities to optimize resource
   usage to achieve different goals that include (but are not limited
   to) bandwidth aggregation, primary/backup communication paths, and
   traffic offload management.  Figure 2 depicts the various TCP
   connection legs in network-assisted MPTCP deployment models.

     +--+      +-----+                           +------------+   +--+
     |H1|      | CPE |                           |Concentrator|   |RM|
     +--+      +--+--+                           +------+-----+   +--+
      |           |                                     |           |
      |<=TCP Leg=>|<============MPTCP Leg==============>|<=TCP Leg=>|
      |           |                                     |           |

     Legend:
        H1: Host 1
        RM: Remote Machine

                Figure 2: Connection Legs (CPE-based Model)

   There are also MPTCP deployments to assist hosts that are directly
   connected to multiple networks to establish multi-path

Boucadair, et al.        Expires January 5, 2017                [Page 4]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   communications.  The communication legs that are involved in such
   deployments are shown in Figure 2.

     +--+                                        +------------+   +--+
     |H1|                                        |Concentrator|   |RM|
     +--+                                        +------+-----+   +--+
      |                                                 |           |
      |<==================MPTCP Leg====================>|<=TCP Leg=>|
      |                                                 |           |

               Figure 3: Connection Legs (Host-based Model)

   Most of the current operational deployments that take advantage of
   multi-interfaced devices rely upon the use of an encapsulation scheme
   (such as GRE [I-D.zhang-gre-tunnel-bonding]).  The use of
   encapsulation is motivated by the need to steer traffic towards the
   concentrator and also to allow the distribution of any kind of
   traffic besides TCP (e.g., UDP) among the available paths without
   requiring any advanced traffic engineering tweaking technique in the
   network side to intercept traffic and redirect it towards the
   appropriate concentrator.

   This specification assumes an MPTCP concentrator is reachable by
   means of one or multiple IP addresses.  Also, it assumes the various
   network attachments provided to an MPTCP-enabled device (CPE or host)
   are managed by the same administrative entity.  The IP reachability
   information of an MPTCP concentrator can be explicitly configured on
   a device, e.g., by means of a specific DHCP option
   [I-D.boucadair-mptcp-dhc].  This document assumes such explicit
   configuration.  Additional assumptions are listed in Section 3.

   Current operational MPTCP deployments by network operators are
   focused on the forwarding of TCP traffic.  In addition, the design of
   such deployments sometimes assumes the use of extra signalling
   provided by SOCKS [RFC1928], at the cost of additional management
   complexity and possible service degradation (e.g., up to 8 SOCKS
   messages may need to be exchanged between two MPTCP proxies before an
   MPTCP connection is established, thereby yielding several tens of
   milliseconds of extra delay before the connection is established) .

   To avoid the burden of encapsulation and additional signalling
   between MPTCP proxies, this document explains how a plain transport
   mode is enabled, so that packets are exchanged between the CPE and
   the concentrator without requiring the activation of any
   encapsulation scheme (e.g., IP-in-IP [RFC2473], GRE [RFC1701]).  This
   plain transport mode also avoids the need for out-of-band signalling.

Boucadair, et al.        Expires January 5, 2017                [Page 5]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   The solution described in this document also works properly when NATs
   are present in the communication path between the CPE and the
   concentrator, unlike solutions that rely upon GRE tunneling.  In
   particular, the solution proposed in this document accommodates
   deployments that involve CGN (Carrier Grade NAT) upstream the
   concentrator.

   The plain transport mode is characterized as follows:

   o  No encapsulation required (no tunnels, whatsoever).
   o  No out-of-band signaling for each MPTCP subflow required.
   o  Carries any protocol (incl.  UDP) for the benefit of massive MPTCP
      adoption (Section 5).
   o  Accommodates various deployment contexts (Section 6).

2.  Terminology

   The reader should be familiar with the terminology defined in
   [RFC6824].

   This document makes use of the following terms:

   Customer-facing interface:   is an interface of the MPTCP
      concentrator that is visible to a CPE or a host directly connected
      to the operator's network, and which is used for communication
      purposes between a CPE/host and the MPTCP concentrator.

   Internet-facing interface:   is an interface of the MPTCP
      concentrator that is visible to a remote host on the Internet.

   IP transport address:  refers to an IP address and transport port
      number.

   MPTCP proxy:   is a software module that is responsible for
      transforming a TCP connection into an MPTCP connection, and vice
      versa.  Typically, an MPTCP proxy is embedded in a CPE and a
      concentrator.

   MPTCP leg:   refers to a network segment where MPTCP is used to
      establish TCP connections (see Figure 2).

   MPTCP concentrator (or concentrator):  refers to a functional element
      that is responsible for aggregating traffic pertaining to a group
      of CPEs.  This element is typically located upstream in the
      network, e.g., beyond a Broadband Network Gateway (BNG) or a PDN
      Gateway (PGW) in wired and wireless access network environments,
      respectively.  One or multiple concentrators can be deployed in

Boucadair, et al.        Expires January 5, 2017                [Page 6]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

      the network to help MPTCP-enabled CPEs establish MPTCP connections
      via available network attachments.

      On the uplink path, the concentrator terminates the MPTCP
      connections received from its customer-facing interfaces and
      transforms these connections into legacy TCP connections towards
      upstream servers.

      On the downlink path, the concentrator converts the legacy
      server's TCP connections into MPTCP connections towards its
      customer-facing interfaces.

3.  Assumptions & Scope

   The following assumptions are made:

   o  The logic for mounting network attachments by a CPE (or a host
      directly connected to the operator's network) is deployment- and
      implementation-specific and is out of scope of this document.

   o  Policies can be enforced by a concentrator instance operated by
      the Network Provider to manage both upstream and downstream
      traffic.  These policies may be subscriber-specific, connection-
      specific, system-wide, or else.

   o  The concentrator may be notified about monitoring results (e.g.,
      provided by passive or active probes) that detail the status of
      the various network legs available to service a customer, a group
      of customers, a whole region, etc.  No assumption is made in this
      document about how these monitoring operations are executed.

   o  An MPTCP-enabled, multi-interfaced CPE or host that is directly
      connected to one or multiple access networks is allocated
      addresses/prefixes via legacy mechanisms (e.g., DHCP) supported by
      the various available network attachments.  The CPE/host may be
      assigned the same or distinct IP address/prefix via the various
      available network attachments.

   o  The location of the concentrator(s) is deployment-specific.
      Network Providers may choose to adopt centralized or distributed
      designs.  Nevertheless, in order to take advantage of MPTCP, the
      location of the concentrator should not jeopardize packet
      forwarding performance overall.

   o  The logic of traffic distribution over multiple paths is
      deployment-specific.  This document does not require nor preclude
      any particular traffic distribution schemes.

Boucadair, et al.        Expires January 5, 2017                [Page 7]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   o  No assumption is made whether one single or multiple IP addresses/
      prefixes are assigned to host connected to a CPE.

   It is out of the scope of this document to discuss criteria for
   selecting traffic to be eligible to MPTCP service.  It is out of
   scope of the document to specify how a CPE selects its
   concentrator(s), too.

   Likewise, methods to avoid TCP fragmentation, such as rewriting the
   TCP Maximum Segment Size (MSS) option, are out of scope for this
   document.

   This document focuses on the CPE-based model (i.e., the CPE embeds a
   MPTCP proxy that behaves on behalf of terminal devices), but plain
   transport mode can also apply to host-based models.

   TCP/MPTCP session tracking by the MPTCP proxy is implementation-
   specific.  Readers may refer to Section 2 of [RFC7857].

   This specifications focuses on TCP and UDP.  Future documents may
   specify the exact behavior for transporting other protocols over
   MPTCP connections.

   Also, this specification focuses on a stateful design; stateless
   approaches that rely on including the Plain Mode option in all
   packets are out of scope.

4.  Plain Transport Mode Behavior

   As shown in Figure 2, TCP connections initiated by a host are
   converted by the CPE into MPTCP connections towards the concentrator.
   Then, the concentrator converts these connections into legacy TCP
   connections towards the final destinations.  Since the concentrator
   can be located anywhere in the operator's network, Section 4.1
   introduces a new TCP option to supply the concentrator with required
   information to forward the traffic to its final destination.  When a
   CPE receives a SYN segment from a host of the LAN, it rewrites the
   destination address of that segment to an address of the
   concentrator, and places the original destination (and possibly
   source) addresses in this TCP option.  Further details are specified
   in the following sub-sections.

   Specific UDP processing is discussed in Section 5.

Boucadair, et al.        Expires January 5, 2017                [Page 8]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

4.1.  Plain Mode MPTCP Option

   The Plain Mode (PM) option carries the source/destination IP
   addresses and/or port numbers of the origin source and destination
   nodes.  It is also used to indicate whether the data carried in the
   packet is relayed from a native TCP connection or refers to the use
   of another transport protocol.  The format of the option is shown in
   Figure 4.

   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
   +---------------+---------------+-------+-+-----+---------------+
   |     Kind      |     Length    |SubType|D|Flags|    Protocol   |
   +---------------+---------------+-------+-+-----+---------------+
   |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
   +-------------------------------+-------------------------------+
   |   Port (2 octets, optional)   |
   +-------------------------------+

                     Figure 4: Plain Mode MPTCP Option

   The description of the fields is as follows:

   o  Kind and Length: are the same as in Section 3 of [RFC6824].

   o  Subtype: to be defined by IANA (Section 8).  Implementations may
      use "0xe" subtype encoding for early deployment purposes in
      managed networks.

   o  D-bit (direction bit): this flag indicates whether the enclosed IP
      address (and port number) reflects the source or destination IP
      address (and port).  When the D-bit is set, the enclosed IP
      address must be interpreted as the source IP address.  When the
      D-bit is unset, the enclosed IP address must be interpreted as the
      destination IP address.

   o  "Flag" bits: are reserved bits for future assignment as additional
      flag bits.  These additional flag bits MUST each be set to zero
      and MUST be ignored upon receipt.

   o  Protocol: conveys the protocol number as assigned by IANA
      [proto_numbers].  For example, this field is set to 17 for UDP
      traffic, or 6 for TCP.  The processing of UDP flows is further
      discussed in Section 5.

   o  Address: includes a source or destination IP address.  The address
      family is determined by the "Length" field.  Concretely, a PM
      option containing an IPv4 address has a Length field of 8 bytes
      (or 10 if a port number is included).  A PM option containing an

Boucadair, et al.        Expires January 5, 2017                [Page 9]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

      IPv6 address has a Length of 20 bytes (or 22 if a port number is
      included).

   o  Port: If the D-bit is set (resp. unset), a source (resp.
      destination) port number may be associated with the IP address.
      This field is valid for protocols that use a 16 bit port number
      (e.g., UDP, TCP, SCTP).

4.2.  Carrying the Plain Mode Option

   When using an MPTCP connection to forward traffic (whether it's TCP
   traffic or any other traffic), the CPE (resp. the concentrator) MUST
   insert a Plain Mode option in a SYN packet sent to the concentrator
   (resp. the CPE).  The Plain Mode option MUST be included in the SYN
   payload.

      Note: Given the length of the PM option, especially when IPv6
      addresses are used, and the set of TCP options that are likely to
      be included in a SYN message, it will not always be possible to
      place the PM option inside the dedicated TCP option space.  Given
      that this option is designed to be used in a controlled
      environment, this specification recommends to always place the PM
      options inside the payload of a SYN segment.  Including data in a
      SYN payload is allowed as per Section 3.4 of [RFC0793].

   If the original SYN message contains data in its payload (e.g.,
   [RFC7413]), that data MUST be placed right after PM and "End of
   Options List" (EOL) options when generating the SYN in the MPTCP leg.
   The EOL option serves as a marker to delineate the end of the TCP
   options and the beginning of the data included in the original SYN .

   The Plain Mode option MUST only appear in SYN segments that contain
   the MP_CAPABLE option.  SYN messages to create subsequent subflows of
   a given MPTCP connection MUST NOT include any PM option (Figure 5).

Boucadair, et al.        Expires January 5, 2017               [Page 10]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

              +-----+                          +------------+
              | CPE |                          |Concentrator|
              +-+-+-+                          +------+-----+
                | |                                   |
                | |     (Initial connection setup)    |
                |------------------(PM)-------------->|
                |<------------------------------------|
                | |                                   |
                | |      (Additional subflow setup)   |
                | |/---------------------------------\|
                | |\---------------------------------/|
                | |                                   |

     Figure 5: Carrying the Plain Mode Option (Focus on the MPTCP Leg)

   By default, source IP address preservation is assumed for IPv6 while
   global address sharing is assumed for IPv4.  This means that, by
   default, two plain mode option instances MUST be included in a SYN
   segment for IPv6 (both source and destination) and one instance MUST
   be present for IPv4 (either the source or the destination).  The CPE
   and the concentrator MUST support a configurable parameter to modify
   this default behavior to accommodate alternate deployment models (see
   Section 6).

   An implementation MUST ignore PM options that include multicast,
   broadcast, and host loopback addresses [RFC6890].

   The 'Protocol' field of the PM option MUST be copied from the
   'Protocol' field of the IPv4 header or set to the type of the
   transport header of the IPv6 packet that will be forwarded along
   MPTCP subflows.  The CPE and the concentrator MAY be configured to
   disable traffic aggregation for some transport protocols because of
   the nature of the service they relate to (e.g., IP multicast traffic
   typically specific of live TV broadcasting services).  By default,
   TCP and UDP traffic bonding MUST be enabled.

4.3.  Binding Tables

4.3.1.  On the Need to Maintain a State

   Because the source IP and/or destination IP addresses are
   communicated only during the SYN exchange of the initial subflow, the
   CPE and the concentrator MUST maintain a state that binds the MPTCP
   transport coordinates to the destination/source IP address, ports,
   and protocol.  This specification discusses the external behavior of
   this stateful design; the internal behavior for maintaining that
   state is implementation-specific.

Boucadair, et al.        Expires January 5, 2017               [Page 11]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   This document uses 'Internal transport session identifier' to
   identify a particular transport session on the LAN side of the CPE
   and 'External transport session identifier' to identify a particular
   transport session on the Internet-facing Interface of the
   concentrator.  An implementation could use the classical 4-tuple
   (source and destination addresses and ports) as such an identifier.

   An MPTCP proxy also needs to identify a particular MPTCP connection.
   We refer to it as the 'MPTCP transport coordinates'.  An
   implementation could, for example, use the token assigned to a
   specific connection to identify an MPTCP connection.  The 4-tuple of
   each subflow that belong to an MPTCP connection can also be part of
   the MPTCP transport coordinates.

   Binding entries can be created as a result of a packet or be
   configured directly on the CPE or the concentrator.

4.3.2.  Binding & Transport Session Entries

   An implementation may maintain distinct binding tables, each for a
   given transport protocol, or maintain one single binding table to
   handle all supported transport protocols.

   Subflows can be added or deleted during the lifetime of an MPTCP
   connection based on triggers that are local to the CPE/concentrator,
   based on signals received from the concentrator/CPE, or as a result
   of processing a packet.  These triggers are outside the scope of this
   specification.

   The CPE must maintain a binding entry that allows to associate the
   internal transport address (IP address, port number) with one or a
   set of external IP transport addresses, that are assigned in the WAN
   interfaces of the CPE in the context of a given MPTCP connection.
   Each of the external transport addresses points to a subflow that is
   created between the CPE and the concentrator.  For each binding
   entry, one or multiple transport session entries are maintained by
   the CPE and the concentrator.  These session entries are meant to
   store the information that is required for rewriting packets.  A
   session entry is created as a result of handling a packet.

   A session entry maintained by the CPE may be structured as follows:

   Internal transport session identifier:   This information typically
      include the source IP transport address (IPl, Pl) and the
      destination IP transport address (IPd, Pd) of the connection.

   MPTCP transport coordinates:  These coordinates include information
      about the subflows that compose this MPTCP connection.  When a

Boucadair, et al.        Expires January 5, 2017               [Page 12]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

      packet matches an existing binding entry, the CPE may decide
      whether existing subflows can be used to forward the packet, or
      whether a new subflow is to be created.

      The following information is maintained for each MPTCP subflow:

      *  (IPwi, Pwi): The source IP address and port for this subflow.

      *  (IPci, Pci): IPci is one of the concentrator's IP addresses,
         while Pci is a port number selected to establish this subflow.
         This information is used as the destination IP address and port
         of a packet matching this entry.

   Transport protocol:   This information is typically retrieved from
      the outgoing packet that will be placed in MPTCP connections.  The
      transport protocol specifies the protocol that is used in the LAN
      side.

   Lifetime:  This information indicates the remaining validity lifetime
      for the session entry.  When the lifetime expires, this session
      entry is deleted from the table.  If all sessions bound to a given
      binding entry expired, that binding entry must be deleted.
      Recommendations for setting this parameter are defined in
      [RFC7857][RFC5382][RFC4787].

   For example:

   o  An outgoing packet {src=(IPl, Pl); dst=(IPd,Pd)} will be
      transformed by the CPE to {src=(IPwi,Pwi); dst=(IPci,Pci)}.

   o  An incoming packet {src=(IPci,Pci); dst=(IPwi,Pwi) will be
      transformed by the CPE to {src=(IPd, Pd); dst=(IPl,Pl)};

   The structure of a session entry maintained by the concentrator may
   be as follows:

   External transport session identifier:  This information typically
      include the external IP transport address (IPe, Pe) and the
      destination IP transport address (IPd, Pd) of the connection.  The
      external IP transport address is set to the (IPl, Pl) if and only
      if the concentrator is configured to preserve the source IP
      address and port.  In such case, this information is retrieved
      from the PM option included in a SYN packet.  Otherwise, the
      external IP address and port are selected by the concentrator from
      a local pool.

   MPTCP transport coordinates:  These coordinates include information
      about the subflows that compose this MPTCP connection.  When a

Boucadair, et al.        Expires January 5, 2017               [Page 13]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

      packet matches an existing binding entry, the concentrator may
      decide whether existing subflows can be used to forward the
      packet, or whether a new subflow is to be created.

      The following information is maintained for each MPTCP subflow:

      *  (IPwi, Pwi): The source IP address and port for this subflow.

      *  (IPci, Pci): The destination IP address and port for this
         subflow.  It can be set by the CPE or selected by the
         concentrator.

   Transport protocol:  This information is retrieved from the PM option
      included in a SYN packet.  The transport protocol specifies the
      protocol that must be used when sending the packet through the
      Internet-facing interface.

   Lifetime:  This information indicates the remaining validity lifetime
      for the session entry.  When the lifetime expires, this session
      entry is deleted from the table.  If all sessions bound to a given
      binding entry expired, that binding entry must be deleted.
      Recommendations for setting this parameter are defined in
      [RFC7857][RFC5382][RFC4787].

   For example:

   o  An outgoing packet {src=(IPwi,Pwi); dst=(IPci,Pci)} will be
      transformed by the concentrator to {src=(IPe,Pe); dst=(IPd,Pd)}.

   o  An incoming packet {src=(IPd,Pd); dst=(IPe,Pe) will be transformed
      by the concentrator to {src=(IPd, Pd); dst=(IPci,Pci)}.

4.3.3.  Expiration of a Binding Entry

   A configurable parameter MAY be supported by the CPE and the
   concentrator to terminate MPTCP connections with the FASTCLOSE
   procedure (Section 3.5 of [RFC6824]) when a binding entry expires.

   If there is no binding state that matches a received non-SYN segment,
   the CPE/concentrator SHOULD reply with a RST segment.  This behavior
   aims to synchronize the binding tables between the CPE and the
   concentrator by clearing bindings that are present either in the CPE
   or in the concentrator.

   The configurable parameter is set by default to 'Disable'.

Boucadair, et al.        Expires January 5, 2017               [Page 14]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

4.4.  Theory of Operation: Focus on TCP

4.4.1.  Processing an Outgoing SYN

   PM option usage for an outgoing TCP SYN (i.e., from the CPE to the
   concentrator) is as follows:

   (1)  Outgoing TCP SYNs that can be forwarded by a CPE along MPTCP
        subflows are transformed by the CPE into TCP packets carried
        over an MPTCP connection.

        The decision-making process to decide whether a given flow
        should be MPTCP-serviced or not is local to the CPE, and
        reflects the service-inferred policies as defined by the bonding
        service provider.  As such, the decision-making process is
        policy-driven, implementation- and deployment-specific.

   (2)  As a result, SYNs packets are sent over an MPTCP connection
        according to the plain transport mode (i.e., without any
        encapsulation header), and the related instructions carried in
        the PM option.

        The source IP address and port number are those assigned to one
        of the CPE WAN interfaces.  Because multiple IP addresses may be
        available to the CPE, the address used to rewrite the source IP
        address for an outgoing packet forwarded through a given network
        attachment (typically, a WAN interface) MUST be associated with
        that network attachment.  It is assumed that ingress traffic
        filtering policies ([RFC2827]) are enforced at the network
        boundaries to prevent any spoofing attack.

        The destination IP address is replaced by the CPE with one of
        the IP addresses of the concentrator.

        The destination port number may be maintained as initially set
        by the host or altered by the CPE.

        The original destination and/or source IP address are copied
        into Plain Mode options.  The option is inserted as per the
        guidelines documented in Section 4.2.

        A session entry (including the protocol) MUST be maintained by
        the CPE for that outgoing packet (Section 4.3).  A timeout is
        associated with this entry as per the recommendations in
        [RFC5382].

   (3)  Upon receipt of a SYN packet on its MPTCP leg, the concentrator
        extracts the IP address(es) included in the PM option and uses

Boucadair, et al.        Expires January 5, 2017               [Page 15]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

        it as the destination (and possibly the source) IP address of
        the corresponding SYN packet that it will forward towards its
        final destination.  The 'Protocol' field of the PM option
        indicates the transport protocol that must be used when sending
        the packet through the Internet-facing interface.

        The source IP address and port belong to a pool that is
        configured to the concentrators if address or prefix rewriting
        is enabled (see Section 6).  A session entry MUST be
        instantiated by the concentrator to record the state (see
        Section 4.3).

        The concentrator may be configured to behave as either a 1:1
        IPv4 address translator or a N:1 IPv4 address translator where a
        given global IPv4 address is therefore shared by multiple CPEs.
        Network Providers should be aware of the complications that may
        arise if a given IP address/prefix is shared by multiple
        customers (see [RFC6269][RFC6967]).  Whether these complications
        apply or not to a network-assisted MPTCP environment is
        deployment-specific.

        The concentrator should preserve the same external IP address
        that was assigned to a given CPE for all its outgoing
        connections when forwarding traffic from an MPTCP connection to
        the Internet (i.e., use an "IP address pooling" behavior of
        "Paired") [RFC4787].  The port allocation policy configured on
        the concentrator (e.g., port set assignment, deterministic NAPT,
        etc.) is implementation and deployment-specific.

4.4.2.  Processing an Incoming SYN

   In order to appropriately handle incoming SYN packets, the
   concentrator (resp.  CPE) are supposed to be configured with
   instructions that allows to redirect the traffic to the appropriate
   CPE (resp.  Internal host).

   Plain transport mode operation for an incoming TCP SYN (i.e., when
   traffic is forwarded from the concentrator towards the CPE) is as
   follows:

   (1)  If the incoming TCP SYN matches a binding entry (Section 4.3),
        the concentrator rewrites some of the packet's fields according
        to the information maintained in this entry.  In addition, the
        concentrator records the source IP address and port in the PM
        option.  Also, the 'Protocol' field of the PM option is set
        according to the guidelines in Section 4.2.

Boucadair, et al.        Expires January 5, 2017               [Page 16]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

        The source IP address is replaced with one of the IP addresses
        listed in the binding information base maintained by the
        concentrator.

        The destination IP address is replaced with one of the CPE's IP
        addresses.

        A session entry is instantiated to record the transport-related
        information to rewrite the packet.

   (2)  Upon receipt of the TCP SYN by the CPE, it extracts the IP
        address included in the Plain Mode option and uses it as the
        source IP address of the packet that the CPE will forward
        through its LAN interface until the packet reaches its final
        destination.

        The destination IP address, port, and protocol are retrieved
        from a binding entry maintained by the CPE.

4.4.3.  Processing Subsequent Outgoing/Incoming Non-SYNs

   The required information to rewrite non-SYN packets that match an
   existing binding entry, is retrieved from the Binding Information
   Bases (BIB) maintained by the CPE and the concentrator (see
   Section 4.3).  The MPTCP proxy may decide at any time to create or
   terminate subflows associated to an MPTCP connection.  When a packet
   arrives, its content is transported over one of the subflows of a
   bound MPTCP connection.

   Non-SYN messages exchanged in the context of an existing subflow and
   all messages for non-initial subflows do not include the PM option.

4.4.4.  Handling TCP RST Messages

   RST messages may be received from the LAN side of the CPE or by the
   concentrator in its Internet-facing interface.  When the CPE or the
   concentrator receive a TCP RST matching an existing entry, it MUST
   apply the FASTCLOSE procedure defined in Section 3.5 of [RFC6824]) to
   terminate the MPTCP connection and the associated subflows.  The
   transport coordinates of the FASTCLOSE messages are set according to
   the information maintained in the binding table.

   The CPE and the concentrator SHOULD wait for 4 minutes before
   deleting the session and removing any state associated with it if no
   packets are received during that 4-minute timeout [RFC7857].

Boucadair, et al.        Expires January 5, 2017               [Page 17]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

5.  Processing UDP Traffic

   This document leverages the ability to create MPTCP connections on
   the CPE/concentrator to also carry data conveyed in UDP datagrams.  A
   UDP flow can be defined as a series of UDP packets that have the same
   source and destination address and ports.  Upon receipt of the first
   packet of such a flow, a binding entry (Section 4.3) is created to
   map this flow onto an MPTCP connection between the CPE and the
   concentrator.  All the subsequent UDP segments of this UDP flow are
   transported over that MPTCP connection.  The MPTCP connection is
   released when no traffic is exchanged for this flow (Section 5.1.3).

5.1.  Behavior

   From an application standpoint, there may be a value to distribute
   UDP datagrams among available network attachments for the sake of
   network resource optimization, for example.  This document uses MPTCP
   features to control how UDP datagrams are distributed among existing
   network attachments.  The data carried in UDP datagrams belonging to
   a given UDP flow are therefore transported in an MPTCP connection.
   An MPTCP connection is bound to one UDP flow.  New MPTCP connections
   are created in order to handle additional UDP flows.

   The management of MPTCP connections that are triggered by UDP
   datagrams follows the guidelines documented in [RFC6824].

   The following sub-sections exclusively focus on the external behavior
   to achieve UDP to TCP conversion (Section 5.1.1), and vice versa
   (Section 5.1.2).

5.1.1.  UDP to TCP Conversion

   This function is applied to UDP traffic received by the CPE from the
   LAN, and to UDP traffic received by the concentrator from one of its
   Internet-facing interfaces.

   When the CPE (or the concentrator) receives a UDP datagram to be
   distributed over MPTCP subflows, it MUST check whether the packet
   matches an existing binding entry (Section 4.3).

   If an entry is found, and the packet is to be placed on an existing
   subflow, the packet is processed according to the corresponding
   session entry.  If an entry is found, but the packet should be placed
   on a new subflow, a session entry MUST be instantiated by the CPE for
   that outgoing packet.  The information about the transport protocol
   (UDP, in this case) MUST also be included in this binding entry.  In
   both cases, the CPE (or the concentrator) MUST proceed as follows:

Boucadair, et al.        Expires January 5, 2017               [Page 18]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   1.  Extract the payload and its length from the UDP datagram.

   2.  Send the length (as a 16 bits field in network byte order)
       followed by the payload of the UDP datagram over the bound MPTCP
       connection.

   UDP packets that are received by the concentrator, but do not match
   an existing binding, MUST be silently dropped.

   UDP packets that are received by the CPE, but do not match an
   existing binding, MUST be proceed as follows:

   1.  Instantiate a new binding entry for this outgoing packet.  The
       information about the transport protocol (UDP, in this case) MUST
       also be included in this binding entry.

   2.  Initiate the MPTCP connection that will be used to carry the UDP
       datagrams of this flow towards the chosen concentrator.  For
       this, the CPE MUST create a SYN segment containing the following
       information :

       *  The MP_CAPABLE option and possibly other TCP options.

       *  The payload contains the following information (in this
          order):

          +  A PM option indicating the original source address and port
             if source address preservation is enabled.

          +  A PM option indicating the original destination address and
             port.

          +  The EOL TCP option.

          +  The Length of the UDP payload in network byte order.

          +  The payload of the UDP datagram.

   When setting the source IP address, the destination IP address, and
   the IP address enclosed in the Plain Mode MPTCP option of the
   corresponding TCP packet, the same considerations as specified in
   Section 4.3 MUST be applied.

   Whether one or multiple UDP payloads are included in the same TCP
   segment is implementation- and deployment-specific.

Boucadair, et al.        Expires January 5, 2017               [Page 19]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

5.1.2.  TCP to UDP Conversion

   Upon receipt of a SYN segment containing the PM option specifying the
   UDP protocol, the concentrator MUST proceed as follows:

   o  Create a binding entry to map this MPTCP connection to a UDP flow
      (Section 4.3).

   o  Extract the destination, and possibly source, transport addresses
      from the PM option and complete the session entry with this
      information.

   o  Extract the UDP payload.

   o  Generate a UDP datagram with the corresponding IP addresses and
      ports and the UDP payload.

   Upon receipt of a SYN segment containing the PM option specifying the
   UDP protocol, the CPE MUST proceed as follows:

   o  If no binding is found, the packet MUST be silently dropped.

   o  If a binding is found:

      *  Extract the source (optionally, destination) transport
         addresses from the PM option.

      *  Create a session entry to map this MPTCP connection to a UDP
         flow (Section 4.3).

      *  Extract the UDP payload.

      *  Generate a UDP datagram with the corresponding IP addresses and
         ports and the UDP payload.

   Upon receipt of data over an MPTCP connection that is bound to a UDP
   flow, the 'Length' field is used to extract the UDP payloads from the
   bytestream and generates the corresponding UDP datagrams.

   The concentrator (or the CPE) MUST follow the same procedure as
   mentioned in Section 4.3 for address and port rewriting purposes.

5.1.3.  Terminating UDP-Triggered Subflows

   UDP-triggered subflows SHOULD be terminated by an MPTCP endpoint (CPE
   or concentrator) if no UDP packet matching the corresponding binding
   entry is received for at least 5 minutes (see Section 4.3 of
   [RFC4787]).  Consequently, the procedure in Section 4.4.4 MUST be

Boucadair, et al.        Expires January 5, 2017               [Page 20]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   followed to terminate the MPTCP connection and the associated
   subflows.  The transport coordinates of the FASTCLOSE messages are
   set according to the information maintained in the binding table.

5.2.  Examples

   A flow example is shown in Figure 6 to illustrate how TCP packets are
   generated to relay UDP datagrams using several subflows.  Non-SYN
   messages that belong to a given subflow do not include any PM option.
   Also, this example shows how subsequent UDP datagrams of this flow
   are transported over the existing subflow or how a new subflow is
   created.  In this example, the SYN segment issued to add a new
   subflow also includes data received in the original UDP datagram.

        +--------+                                    +------------+
        |  CPE   |                                    |Concentrator|
        +--------+                                    +------------+
             |                                              |
      src=s_@|src=cpe_@1                         dst=conc_@1|src=conc_@
    ---UDP-->|----------------TCP SYN (Data)--------------->|---UDP-->
      dst=d_@|          PM(D=0;Protocol=17;d_@)             |dst=d_@
             |<-----------------TCP SYN/ACK-----------------|
             |---------------------TCP ACK----------------->|
      src=s_@|                                              |src=conc_@
    ---UDP-->|---------------------TCP Data---------------->|---UDP-->
      dst=d_@|                                              |dst=d_@
             |                                              |
                                      ....
      src=s_@|src=cpe_@2                         dst=conc_@1|src=conc_@
    ---UDP-->|----------------TCP SYN (Data)--------------->|---UDP-->
      dst=d_@|                                              |dst=d_@
             |                                              |
             |<-----------------TCP SYN/ACK-----------------|
             |---------------------TCP ACK----------------->|
             |                                              |
                                      ....

        Figure 6: Distributing UDP packets over multiple paths (1)

   Figure 7 shows an example of UDP datagrams that are transported over
   MPTCP subflows.  Unlike the previous example, additional subflows to
   transport UDP datagrams of the same flow are established in advance
   between the CPE and the concentrator.

Boucadair, et al.        Expires January 5, 2017               [Page 21]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

        +--------+                                    +------------+
        |  CPE   |                                    |Concentrator|
        +--------+                                    +------------+
             |                                              |
      src=s_@|src=cpe_@1                         dst=conc_@1|src=conc_@
    ---UDP-->|----------------TCP SYN (Data)--------------->|---UDP-->
      dst=d_@|          PM(D=0;Protocol=17;d_@)             |dst=d_@
             |<-----------------TCP SYN/ACK-----------------|
             |---------------------TCP ACK----------------->|
      src=s_@|                                              |src=conc_@
    ---UDP-->|---------------------TCP Data---------------->|---UDP-->
      dst=d_@|                                              |dst=d_@
             |                                              |
                                    ....
             |          (Additional subflow setup)          |
             |src=cpe_@2                         dst=conc_@1|
             |--------------------TCP SYN------------------>|
             |<-----------------TCP SYN/ACK-----------------|
             |---------------------TCP ACK----------------->|
      src=s_@|src=cpe_@1                         dst=conc_@1|src=conc_@
    ---UDP-->|---------------------TCP Data---------------->|---UDP-->
      dst=d_@|                                              |dst=d_@
             |                                              |
                                   ....
      src=s_@|src=cpe_@2                         dst=conc_@1|src=conc_@
    ---UDP-->|---------------------TCP Data---------------->|---UDP-->
      dst=d_@|                                              |dst=d_@
             |                                              |
                                   ....

        Figure 7: Distributing UDP packets over multiple paths (2)

5.3.  Fragmentation & Reassembly Considerations

   The subsequent UDP/TCP header swapping introduced in Section 5.1
   represents an overhead that is equal to the difference between TCP
   and UDP header sizes.  To avoid fragmentation when processing large
   UDP datagrams, it is RECOMMENDED to increase the MTU of all links
   between the CPE and the concentrator to accommodate this overhead.

   Nevertheless, in deployments where increasing the MTU of all links is
   not possible for some reason, the CPE and the concentrator SHOULD be
   configurable to enable/disable fragmentation and reassembly of UDP
   datagrams.  The decision to enable or disable this parameter is
   deployment-specific.  This parameter is set to 'Disabled' by default.

   If this configurable parameter is set to 'Disabled', large UDP
   datagrams that may thus be fragmented MUST NOT be forwarded along the

Boucadair, et al.        Expires January 5, 2017               [Page 22]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   MPTCP connection, i.e., the bonding service MUST NOT be applied to
   such large packets.

   If this configurable parameter is set to 'Enabled', the CPE and the
   concentrator MUST perform IPv4 fragmentation and reassembly for
   packets that exceed the link MTU.  Concretely, IPv4 fragmentation
   MUST be performed once UDP/TCP header swapping is completed.  Packet
   reassembly MUST occur before TCP/UDP header swapping.  The behavior
   to adopt whenever the swapping of UDP/TCP headers leads to IPv4
   fragmentation is as follows:

   o  Present the packet to the MPTCP proxy as per Section 5.1.1.

   o  Fragment the transformed packet (TCP), and then forward the
      fragments.

   The remote MPTCP endpoint (CPE or concentrator) then adopts the
   following behavior:

   o  Reassemble the TCP packet,

   o  Present the packet to the MPTCP proxy as per Section 5.1.2.

   In order to protect the CPE and the concentrator and minimize the
   risk of degrading the overall bonding service performance, dedicated
   resources SHOULD be reserved for handling fragments (e.g., by
   limiting the amount of resources to process out-of-order packets).

5.3.1.  Receiving IPv4 Fragments on the Internet-Facing Interface of the
        Concentrator

   The forwarding of an IPv4 packet received on the Internet-facing
   interface of the concentrator requires the IPv4 destination address
   and the transport-protocol destination port for binding lookup
   purposes.  If the first packet received contains the transport-
   protocol information, the concentrator uses a cache and forwards the
   fragments unchanged (i.e., without reassembly).  A description of
   such a caching algorithm is outside the scope of this document.  If
   subsequent fragments arrive before the first fragment, the
   concentrator SHOULD queue these fragments till the first fragment is
   received.

   The processing of the first fragment MUST follow the same procedure
   as in Section 5.1.1.  The rewriting of the IP addresses of subsequent
   fragments MUST follow the instructions maintained in the binding
   table and the fragmentation cache.  The MF (More Fragments) bit and
   'Fragment offset' field MUST NOT be modified by the concentrator.

Boucadair, et al.        Expires January 5, 2017               [Page 23]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

5.3.2.  Receiving IPv4 Fragments from the LAN

   If the first packet received contains the transport-protocol
   information, the CPE uses a cache and forwards the fragments
   unchanged (i.e., without reassembly).  If subsequent fragments arrive
   before the first fragment, the concentrator SHOULD queue these
   fragments till the first fragment is received.

   The processing of the first fragment MUST follow the same procedure
   as in Section 5.1.2.  The rewriting of the IP addresses of subsequent
   fragments MUST follow the instructions maintained in the binding
   table and the fragmentation cache.  The MF bit and 'Fragment offset'
   field MUST NOT be modified by the CPE.

5.3.3.  Distinct Address Families

   If distinct address families are used in the UDP and MPTCP legs,
   fragmentation SHOULD be handled as described in Sections 4 and 5 of
   [RFC7915].

6.  Deployment Scenarios

   The Plain Transport Mode accommodates various deployment contexts
   such as:

   IPv4 address sharing:  Because of global IPv4 address depletion,
      optimization of the IPv4 address usage is mandatory, and this
      includes IPv4 addresses that are assigned by the concentrator at
      its Internet-facing interfaces (Figure 8).  A pool of global IPv4
      addresses is provisioned to the concentrator along with possible
      instructions about the address sharing ratio to apply (see
      Appendix B of [RFC6269]).  Adequate forwarding policies are
      enforced so that traffic destined to an address of such pool is
      intercepted by the appropriate concentrator.

Boucadair, et al.        Expires January 5, 2017               [Page 24]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   +--+      +-----+                           +------------+   +--+
   |H1|      | CPE |                           |Concentrator|   |RM|
   +--+      +--+--+                           +------+-----+   +--+
    |           |                                     |           |
    |Src:IP@s   |Src:IP@cpe1  PM(D=0,IP@d)  Dst:IP@ccf|Src:IP@cif |
    |---SYN---->|----------------SYN----------------->|---SYN---->|
    |   Dst:IP@d|                                     |   Dst:IP@d|
    |           |                                     |           |
    |<--SYN/ACK-|<---------------SYN/ACK--------------|<-SYN/ACK--|
    |---ACK---->|----------------ACK----------------->|---ACK---->|
    |           |                                     |           |

   Legend:
     ccf: Concentrator Customer-facing Interface
     cif: Concentrator Internet-facing Interface

   Figure 8: Example of Outgoing SYN without Source Address Preservation

   IPv4 address 1:1 translation:  For networks that do not face global
      IPv4 address depletion yet, the concentrator can be configured so
      that source IPv4 addresses of the CPE are replaced with other
      (public) IPv4 address.  A pool of global IPv4 addresses is then
      provisioned to the concentrator for this purpose.  Rewriting
      source IPv4 addresses may be used as a means to redirect incoming
      traffic towards the appropriate concentrator.

   Source IPv6 address preservation:  Some IPv6 deployments may require
      the preservation of the source IPv6 address (Figure 9).  This
      model avoids the need for the concentrator to support ALGs to
      accommodate applications with IPv6 address referrals.  In order to
      intercept incoming traffic, specific IPv6 routes are injected so
      that traffic is redirected towards the concentrator.

   +--+      +-----+                           +------------+   +--+
   |H1|      | CPE |                           |Concentrator|   |RM|
   +--+      +--+--+                           +------+-----+   +--+
    |           |                                     |           |
    |Src:IP@s   |Src:IP@cpe1  PM(D=0,IP@d)  Dst:IP@ccf|Src:IP@s   |
    |---------->|------------------------------------>|---------->|
    |   Dst:IP@d|             PM(D=1,IP@s)            |   Dst:IP@d|
    |           |                                     |           |
    |<--SYN/ACK-|<---------------SYN/ACK--------------|<-SYN/ACK--|
    |---ACK---->|----------------ACK----------------->|---ACK---->|
    |           |                                     |           |

    Figure 9: Example of Outgoing SYN with Source Address Preservation

Boucadair, et al.        Expires January 5, 2017               [Page 25]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   IPv6 prefix sharing (NPTv6):  Rewriting the source IPv6 prefix
      ([RFC6296]) may be needed to redirect incoming traffic towards the
      appropriate concentrator.  A pool of IPv6 prefixes is then
      provisioned to the concentrator for this purpose.

   Subflows of a given MPTCP connection can be associated to the same
   address family or may be established with different address families.
   Also, the plain transport mode applies regardless of the addressing
   scheme enforced by each CPE network attachment.  In particular, the
   plain transport mode indifferently accommodates the following
   combinations.

             LAN Leg CPE-Concentrator Legs Concentrator-RM Leg
             ------- --------------------- -------------------
               IPv4           IPv4                 IPv4
               IPv4           IPv6                 IPv4
               IPv4       IPv6 & IPv4              IPv4
               IPv6           IPv6                 IPv6
               IPv6           IPv4                 IPv6
               IPv6       IPv6 & IPv4              IPv6

   Also, the CPE and the concentrator may be configured to preserve the
   same DSCP marking or enforce DSCP re-marking policies, and the plain
   transport mode described in this document fully respects these DSCP
   marking policies.  Those considerations are deployment-specific.

7.  Additional Considerations

7.1.  Authorization

   The Network Provider that manages the various network attachments
   (including the concentrators) may enforce authentication and
   authorization policies using appropriate mechanisms.  For example, a
   non-exhaustive list of methods to achieve authorization is provided
   hereafter:

   o  The network provider may enforce a policy based on the
      International Mobile Subscriber Identity (IMSI) to verify that a
      user is allowed to benefit from the aggregation service.  If that
      authorization fails, the PDP context /bearer won't be mounted.
      This method does not require any involvement from the
      concentrator.

   o  The network provider may enforce a policy based on Access Control
      Lists (ACLs), e.g., at the Broadband Network Gateway (BNG) to
      control the CPEs that are authorized to communicate with a
      concentrator.  These ACLs may be installed as a result of RADIUS

Boucadair, et al.        Expires January 5, 2017               [Page 26]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

      exchanges, for instance.  This method does not require any
      involvement from the concentrator.

   o  The concentrator may implement an Ident interface [RFC1413] to
      retrieve an identifier that will be used to assess whether that
      client is authorized to make use of the aggregation service.
      Ident exchanges will take place only when receiving the first
      subflow from a given source IP address.

   o  The concentrator may embed a RADIUS client that will solicit an
      AAA server to check whether connections received from a given
      source IP address are authorized or not.

   A first safeguard against the misuse of the concentrator resources by
   illegitimate users (e.g., users with access networks that are not
   managed by the same operator owning the concentrator) is to reject
   MPTCP connections received on the Internet-facing interfaces.  Only
   MPTCP connections received on the customer-facing interfaces of a
   concentrator will be accepted.

   Because only the CPE is entitled to establish MPTCP connections with
   a concentrator, ACLs may be installed on the CPE to avoid that
   internal terminals issue MPTCP connections towards one of the
   concentrators.

7.2.  Checksum Adjustment

   Given that the TCP and UDP checksum covers the pseudo-header that
   contains the source and destination IP addresses, the checksum should
   be updated to reflect the change of these addresses.  For the
   particular case of UDP/TCP conversion (Section 5), the UDP checksum
   can be computed from the TCP one and vice versa.

7.3.  Logging

   If the concentrator is used in global IPv4 address sharing
   environments, the logging recommendations discussed in Section 4 of
   [RFC6888] need to be considered.  Security-related issues encountered
   in address sharing environments are documented in Section 13 of
   [RFC6269].

7.4.  Middlebox Interference

   The use of the Plain Transport Mode option is primarily meant for
   MPTCP designs that involve access networks managed by the same
   operator.  Appropriate setup is required before MPTCP with the Plain
   Transport Mode option is activated, so that possible middleboxes

Boucadair, et al.        Expires January 5, 2017               [Page 27]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   located in these access networks do not strip MPTCP signals, nor
   remove data contained in the SYN payload.

   The plain transport mode may be deployed at large but some
   complications may arise, e.g., if an in-path middlebox removes the
   MPTCP option or data from the SYN payload.  These complications not
   specific to the Plain Mode, and are encountered whenever MPTCP is
   deployed.

7.5.  EPC Billing & Accounting

   In case that one of MPTCP subflow between CPE and concentrator
   includes mobile (e.g., LTE, 3G, etc), billing and accounting of the
   traffic may be considered per subflow, per subscriber, or else.
   Since packets generated from/to the subscriber (CPE) are destined/
   sourced to/from the concentrator, the EPC nodes may need to inspect,
   in some deployments, the destination/source address and/or port
   included in the plain mode option to check and make billing and
   accounting actions.  Alternate deployment approaches may be adopted
   to avoid inspecting L3/4 information (e.g., rely on application-based
   filters, correlate flow characteristics retrieved using Policy and
   Charging Control (PCC) interfaces, etc.).

   It is out of the scope of this document to make any recommendation in
   that area.

8.  IANA Considerations

   This document requests an MPTCP subtype code for this option:

   o  Plain Mode MPTCP Option

      NOTE: Implementations may use "0xe" subtype encoding for early
      deployment purposes in managed networks.

9.  Security Considerations

   MPTCP-related security threats are discussed in [RFC6181] and
   [RFC6824].  Additional considerations are discussed in the following
   sub-sections.

9.1.  Privacy

   The concentrator may have access to privacy-related information
   (e.g., IMSI, link identifier, subscriber credentials, etc.).  The
   concentrator MUST NOT leak such sensitive information outside a local
   domain.

Boucadair, et al.        Expires January 5, 2017               [Page 28]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

9.2.  Denial-of-Service (DoS)

   Means to protect the MPTCP concentrator against Denial-of-Service
   (DoS) attacks MUST be enabled.  Such means include the enforcement of
   ingress filtering policies at the network boundaries [RFC2827].

   In order to prevent the exhaustion of concentrator's resources, by
   establishing a large number of simultaneous subflows for each MPTCP
   connection, the administrator SHOULD limit the number of allowed
   subflows per CPE for a given connection.  Means to protect against
   SYN flooding attacks MUST also be enabled ([RFC4987]).

   Attacks that originate outside of the domain can be prevented if
   ingress filtering policies are enforced.  Nevertheless, attacks from
   within the network between a host and a concentrator instance are yet
   another actual threat.  Means to ensure that illegitimate nodes
   cannot connect to a network should be implemented.

9.3.  Illegitimate Concentrator

   Traffic theft is a risk if an illegitimate concentrator is inserted
   in the path.  Indeed, inserting an illegitimate concentrator in the
   forwarding path allows traffic intercept and can therefore provide
   access to sensitive data issued by or destined to a host.  To
   mitigate this threat, secure means to discover a concentrator should
   be enabled.

9.4.  High Rate Reassembly

   The CPE and the concentrator may perform packet reassembly.  Some
   security-related issues are discussed in [RFC4963][RFC1858][RFC3128].

10.  Acknowledgements

   Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
   Nishida, and Christoph Paasch for the comments.

   Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
   Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos
   Aires).

   Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
   Xavier Grall for their valuable comments.

   Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
   Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
   Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun
   Srinivasan, and Raghavendra Mallya for the discussion.

Boucadair, et al.        Expires January 5, 2017               [Page 29]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

11.  References

11.1.  Normative References

   [proto_numbers]
              http://www.iana.org/assignments/protocol-numbers,
              "Protocol Numbers".

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
              2007, <http://www.rfc-editor.org/info/rfc4787>.

   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, DOI 10.17487/RFC5382, October 2008,
              <http://www.rfc-editor.org/info/rfc5382>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <http://www.rfc-editor.org/info/rfc6824>.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, DOI 10.17487/RFC6890, April 2013,
              <http://www.rfc-editor.org/info/rfc6890>.

   [RFC7857]  Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
              S., and K. Naito, "Updates to Network Address Translation
              (NAT) Behavioral Requirements", BCP 127, RFC 7857,
              DOI 10.17487/RFC7857, April 2016,
              <http://www.rfc-editor.org/info/rfc7857>.

   [RFC7915]  Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
              "IP/ICMP Translation Algorithm", RFC 7915,
              DOI 10.17487/RFC7915, June 2016,
              <http://www.rfc-editor.org/info/rfc7915>.

Boucadair, et al.        Expires January 5, 2017               [Page 30]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

11.2.  Informative References

   [I-D.boucadair-mptcp-dhc]
              Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options
              for Network-Assisted Multipath TCP (MPTCP)", draft-
              boucadair-mptcp-dhc-05 (work in progress), May 2016.

   [I-D.zhang-gre-tunnel-bonding]
              Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and
              M. Cullen, "Huawei's GRE Tunnel Bonding Protocol", draft-
              zhang-gre-tunnel-bonding-03 (work in progress), May 2016.

   [RFC1413]  St. Johns, M., "Identification Protocol", RFC 1413,
              DOI 10.17487/RFC1413, February 1993,
              <http://www.rfc-editor.org/info/rfc1413>.

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701,
              DOI 10.17487/RFC1701, October 1994,
              <http://www.rfc-editor.org/info/rfc1701>.

   [RFC1858]  Ziemba, G., Reed, D., and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              DOI 10.17487/RFC1858, October 1995,
              <http://www.rfc-editor.org/info/rfc1858>.

   [RFC1928]  Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
              L. Jones, "SOCKS Protocol Version 5", RFC 1928,
              DOI 10.17487/RFC1928, March 1996,
              <http://www.rfc-editor.org/info/rfc1928>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <http://www.rfc-editor.org/info/rfc2473>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <http://www.rfc-editor.org/info/rfc2827>.

   [RFC3128]  Miller, I., "Protection Against a Variant of the Tiny
              Fragment Attack (RFC 1858)", RFC 3128,
              DOI 10.17487/RFC3128, June 2001,
              <http://www.rfc-editor.org/info/rfc3128>.

Boucadair, et al.        Expires January 5, 2017               [Page 31]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
              Errors at High Data Rates", RFC 4963,
              DOI 10.17487/RFC4963, July 2007,
              <http://www.rfc-editor.org/info/rfc4963>.

   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
              Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
              <http://www.rfc-editor.org/info/rfc4987>.

   [RFC6181]  Bagnulo, M., "Threat Analysis for TCP Extensions for
              Multipath Operation with Multiple Addresses", RFC 6181,
              DOI 10.17487/RFC6181, March 2011,
              <http://www.rfc-editor.org/info/rfc6181>.

   [RFC6269]  Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
              P. Roberts, "Issues with IP Address Sharing", RFC 6269,
              DOI 10.17487/RFC6269, June 2011,
              <http://www.rfc-editor.org/info/rfc6269>.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
              <http://www.rfc-editor.org/info/rfc6296>.

   [RFC6888]  Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
              A., and H. Ashida, "Common Requirements for Carrier-Grade
              NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
              April 2013, <http://www.rfc-editor.org/info/rfc6888>.

   [RFC6967]  Boucadair, M., Touch, J., Levis, P., and R. Penno,
              "Analysis of Potential Solutions for Revealing a Host
              Identifier (HOST_ID) in Shared Address Deployments",
              RFC 6967, DOI 10.17487/RFC6967, June 2013,
              <http://www.rfc-editor.org/info/rfc6967>.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
              <http://www.rfc-editor.org/info/rfc7413>.

Authors' Addresses

   Mohamed Boucadair
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

Boucadair, et al.        Expires January 5, 2017               [Page 32]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   Christian Jacquenet
   Orange
   Rennes
   France

   Email: christian.jacquenet@orange.com

   Denis Behaghel
   OneAccess

   Email: Denis.Behaghel@oneaccess-net.com

   Stefano Secci
   Universite Pierre et Marie Curie
   Paris
   France

   Email: stefano.secci@lip6.fr

   Wim Henderickx
   Nokia/Alcatel-Lucent
   Belgium

   Email: wim.henderickx@alcatel-lucent.com

   Robert Skog
   Ericsson

   Email: robert.skog@ericsson.com

   Olivier Bonaventure
   Tessares
   Belgium

   Email: olivier.bonaventure@tessares.net

Boucadair, et al.        Expires January 5, 2017               [Page 33]
Internet-Draft         Plain MPTCP Transport Mode              July 2016

   Suresh Vinapamula
   Juniper
   1137 Innovation Way
   Sunnyvale, CA  94089
   USA

   Email: Sureshk@juniper.net

   SungHoon Seo
   Korea Telecom
   Seoul
   Korea

   Email: sh.seo@kt.com

   Wouter Cloetens
   SoftAtHome
   Vaartdijk 3 701
   3018 Wijgmaal
   Belgium

   Email: wouter.cloetens@softathome.com

   Ullrich Meyer
   Vodafone
   Germany

   Email: ullrich.meyer@vodafone.com

   Luis M. Contreras
   Telefonica
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com

Boucadair, et al.        Expires January 5, 2017               [Page 34]