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

Versions: 00

MPTCP Working Group                                           B. Peirens
Internet-Draft                                                  Proximus
Intended status: Informational                                  G. Detal
Expires: January 6, 2017                                        S. Barre
                                                          O. Bonaventure
                                                                Tessares
                                                           July 05, 2016


              Link bonding with transparent Multipath TCP
                   draft-peirens-mptcp-transparent-00

Abstract

   This document describes the utilisation of the transparent Multipath
   TCP mode to enable network operators to provide link bonding services
   in hybrid access networks.

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



Peirens, et al.          Expires January 6, 2017                [Page 1]


Internet-Draft              MPTCP Transparent                  July 2016


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Reference architecture . . . . . . . . . . . . . . . . . . . .  4
   3.  Operator requirements  . . . . . . . . . . . . . . . . . . . .  6
   4.  Existing solutions . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Datalink solutions for hybrid access networks  . . . . . .  8
     4.2.  Network layer solutions for hybrid access networks . . . .  8
     4.3.  Transport layer solutions  . . . . . . . . . . . . . . . .  9
     4.4.  Application layer solutions  . . . . . . . . . . . . . . .  9
   5.  The transparent MPTCP mode . . . . . . . . . . . . . . . . . . 11
   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21






























Peirens, et al.          Expires January 6, 2017                [Page 2]


Internet-Draft              MPTCP Transparent                  July 2016


1.  Introduction

   Internet Service Provider networks are composed of different parts :
   access networks, metropolitan and wide area networks.  Given the
   growing demand for bandwidth, these networks must evolve.  In the
   metropolitan and wide area parts, bandwidth increases thanks to the
   utilisation of optical fiber or through link aggregation.  Increasing
   bandwidth in the core is not sufficient to allow all users to benefit
   from faster services.  For many operators, the last-mile of the
   access network remains a bottleneck that is difficult to upgrade.

   Many service providers do not rely on a single access network
   technology.  They often have deployed different access networks that
   were initially targeted at different types of users and customers.
   Such access networks include xDSL, DOCSIS, FTTx and various wireless
   technologies (3G, 4G, Wimax, satellite, 5G, ...).  With these
   different access networks, service providers have different ways to
   reach their customers and combining two access networks would enable
   them to deliver higher bandwidth services to their customers
   [I-D.zhang-banana-problem-statement].

   In this document, we first describe in section Section 2 the hybrid
   access networks that are being deployed by various network operators.
   We focus on the aggregation of a fixed network (e.g. xDSL) with a
   cellular network (e.g.  LTE).  Many operators wish to use the
   bandwidth that is not consumed by the mobile devices on their
   cellular network to deliver better services to their fixed line
   customers.  Section Section 3 lists the main requirements expressed
   by these operators.  Section Section 4 briefly evaluates whether the
   main proposed bonding techniques meet those requirements.  We then
   describe in section Section 5 how a transparent mode of operation for
   Multipath TCP [RFC6824] can be used to meet those operator
   requirements.


















Peirens, et al.          Expires January 6, 2017                [Page 3]


Internet-Draft              MPTCP Transparent                  July 2016


2.  Reference architecture

   Our reference architecture is shown in figure Figure 1.  We use a
   similar terminology as in [WT-348] and consider the following
   elements :

   o  a single homed end host H that is attached through one interface
      (e.g.  WiFi) to a Hybrid Customer Premisses Equipment (HCPE)

   o  a Hybrid Customer Premises Equipment (HCPE) that is connected to
      two different access networks.  The solution proposed in this
      document support any number of access networks, but we restrict
      our examples to two.

   o  A Hybrid Aggregation Gateway (HAG) that is reachable over both
      access networks

   o  a regular server, S


                    ___________
                   /            \
              +---| access net 2 |-+
              |    \____________/  |
              |               _____|___
    +-+    +--+--+           /         \   +---+        +-+
    |H|----|HCPE |          | Backbone  +--|HAG|-/.../--|S|
    +-+    +--+--+           \_________/   +---+        +-+
              |                    |
              |    ___________     |
              |   /           \    |
              +--| access net 1|---+
                  \___________/

                     Figure 1: Hybrid access networks

   We assume that IP addresses are assigned according to the best
   current practices, i.e. host H is allocated one IP address, and one
   IP address is assigned to each interface of the HCPE.  Furthermore,
   BCP 38 [RFC2827] is used on the two access networks attached to the
   HCPE.  The solution proposed in this document is agnostic of the IP
   version that is used.  It operates equally well with both IPv4 and
   IPv6 and can use any mix of IPv4/IPv6.  When writing IP addresses, we
   use the @ notation.  For example, H@ is the IP address assigned to
   host H, HCPE@1 is the IP address assigned to the HCPE on access
   network 1,...  For most network operators, the different access
   networks that need to be aggregated are not equivalent.  One network,
   typically a fixed access network managed by the operator, is



Peirens, et al.          Expires January 6, 2017                [Page 4]


Internet-Draft              MPTCP Transparent                  July 2016


   considered to be the main access network.  The other access network,
   possibly managed by another network operator, is used to provide
   additional capacity to cope with bandwidth limitations on the primary
   access network.  We focus on this bandwidth aggregation scenario in
   this document.  While the second access network can also be used in
   case of failure of the primary access network we currently leave it
   out of scope of the solution (existing solutions are already deployed
   by operators for this).











































Peirens, et al.          Expires January 6, 2017                [Page 5]


Internet-Draft              MPTCP Transparent                  July 2016


3.  Operator requirements

   Many operators have expressed their interest in efficiently
   supporting hybrid access networks.  We list here some of the
   requirements that they have identified and have guided the design of
   the proposed solution.

   o  Req1: the bonding solution MUST support IPv6 and IPv4

   o  Req2: the bonding solution SHOULD minimize the additional delay
      that it introduces in the network

   o  Req3: the bonding solution MUST not expose multiple addresses for
      a given customer and the same address MUST be used for all
      transport protocols used by each customer

   o  Req4 : the bonding solution MUST not use more than one public IPv4
      address per customer

   o  Req5 : the bonding solution SHOULD enable the operator to trace
      the connections created by a given customer

   o  Req6 : the bonding solution MUST monitor the quality of the
      different links and adapt the load distribution dynamically
      according to the load and the operator's policies

   o  Req7 : the bonding solution MUST be decoupled from the underlying
      fixed/mobile access network

   o  Req8: the bonding solution MUST be able to efficiently load-
      balance the packets belonging to a single TCP connection over
      several access networks

   o  Req9: the bonding solution SHOULD not change the subscriber
      service attachment and authentication point in the network.

   The second requirement reflects the importance of minimising the
   latency.  Many applications, including HTTP, are affected by any
   increased latency.  The third requirement reflects operational
   issues.  Many applications expect that all the flows originated by a
   host will have the same source address, independently of the protocol
   used for each flow.  A solution that would use different addresses
   for different transport protocols or for flows that do not benefit
   from hybrid access (e.g. by defined policy), would cause operational
   problems.  The fifth requirement reflects the desire of the network
   operator to have some visibility of the flows that pass through its
   access network in order to apply filtering rules, log flows or
   provide QoS.  The sixth requirement reflects the fact that the



Peirens, et al.          Expires January 6, 2017                [Page 6]


Internet-Draft              MPTCP Transparent                  July 2016


   bandwidth of the access networks that are aggregated can vary
   quickly.  This is particularly the case for cellular networks where
   mobile devices could have priority over the bonding service.  The
   last two requirements correspond to the utilisation of large TCP
   flows.  Measurement studies in access networks show that TCP is the
   dominant protocol in these networks and that most of the data volume
   is carried by long TCP connections.  Such connections must be load-
   balanced on a per packet basis to achieve a good aggregation.











































Peirens, et al.          Expires January 6, 2017                [Page 7]


Internet-Draft              MPTCP Transparent                  July 2016


4.  Existing solutions

   In this document, we focus on solutions that can combine very
   different access network technologies, typically a fixed line access
   network such as xDSL and a wireless access network such as LTE.  We
   discuss only some of the proposed techniques.  A complete overview of
   all the available solutions is outside the scope of this document.

4.1.  Datalink solutions for hybrid access networks

   Some datalink technologies, such as Multilink PPP [RFC1990], can load
   balance packets over different links.  Unfortunately, they cannot
   easily be used in hybrid access networks that rely on different types
   of datalinks.

4.2.  Network layer solutions for hybrid access networks

   Various solutions exist in the network layer.  A first possibility is
   to assign the same address to the HCPE (and thus the hosts behind it)
   over the different access networks.  This requires a specific
   configuration of the routing in the access network and some network
   operators have deployed such solutions.  Per-flow and per-packet load
   balancing are possible with this approach.  Unfortunately, it has a
   number of important drawbacks :

   o  it is difficult for the HAG/HCPE to measure the performance of the
      different access networks in to adjust their utilisation in
      realtime (Req6)

   o  assigning the same address to the HCPE over different networks
      requires integration on the subscriber attachment points for both
      the fixed and mobile network (e.g.  BNG & P-GW) for the bonding
      solution which might not be desirable (Req7)

   o  if packets from a transport connection are spread over different
      access networks, they experience different delays and different
      levels of congestion, but the transport protocol is unaware of
      those different networks.  The net result is a lower throughput
      since the congestion control scheme adapts the throughput to the
      access network offering the lowest performance (Req8).

   An alternative to assigning the same IP addresses on the different
   access networks is to use tunnels between the HCPE and the HAG.
   Various types of IP tunnels are possible [RFC2784]
   [I-D.zhang-gre-tunnel-bonding].  With such tunnels, the problems
   mentioned above remain and the tunneling protocol adds a per-packet
   overhead which may be significant in some environments.  Extensions
   have been recently proposed to include flow control mechanisms in



Peirens, et al.          Expires January 6, 2017                [Page 8]


Internet-Draft              MPTCP Transparent                  July 2016


   some of these tunneling techniques
   [I-D.zhang-banana-tcp-in-bonding-tunnels] but this increases the
   complexity of the solution.  Tunnel based solutions assign the
   external exposed customer address within the tunnel and change the
   subscriber service attachment point (Req9) which forces operators to
   re-implement authentication, logging and service definitions at a
   different location than the non-hybrid access customers.  See also
   concerns listed in the next section {#transport}.

4.3.  Transport layer solutions

   The Multipath TCP plain mode option [I-D.boucadair-mptcp-plain-mode]
   was recently proposed as a solution to cope with some of the above
   problems of the network layer solutions.  This solution is an
   extension of the TCP option proposed in [HotMiddlebox13b].  With the
   plain mode option, the HAG maintains a pool of public addresses that
   are used to translate the client addresses.  From an addressing
   viewpoint, this is equivalent to the deployment of a carrier-grade
   NAT which leads to operational problems for the management of access-
   lists that are used to provide QoS, firewalling, but also for the
   collection of meta data about customer traffic, logs, ...  With
   [I-D.boucadair-mptcp-plain-mode], all the TCP traffic in the access
   networks appears to be destined to the HAG.

   While the Multipath TCP plain mode optionally allows transparency of
   the source address by using the option a second time with D-bit set
   to zero, it would require subscriber session information from the
   network element that assigned the now embedded source address to
   correctly implement BCP-38 [RFC2827] validation when restoring this
   at the HAG.

4.4.  Application layer solutions

   The SOCKS protocol [RFC1928] was designed to enable clients behind a
   firewall to establish TCP connections through a TCP proxy running on
   the firewall.  A possible deployment in hybrid access networks is to
   use the HAG as a SOCKS server over Multipath TCP to benefit from its
   aggregation capabilities.  Since regular hosts usually do not use a
   SOCKS client and do not support Multipath TCP, the HCPE needs to act
   as a transparent TCP/Multipath-TCP+SOCK proxy.

   Compared with the network layer solutions and
   [I-D.boucadair-mptcp-plain-mode], the SOCKS approach has several
   drawbacks from an operational viewpoint :

   o  the HAG must maintain a pool of public addresses





Peirens, et al.          Expires January 6, 2017                [Page 9]


Internet-Draft              MPTCP Transparent                  July 2016


   o  to establish a TCP connection through a SOCKS server running on
      the HAG, the HCPE must first perform the three-way handshake and
      then exchange SOCKS messages to authenticate the client (the
      number of messages is function of the SOCKS authentication scheme
      that is used).  This increases the establishment time for each TCP
      connection by one or more additional round-trip times (Req2).













































Peirens, et al.          Expires January 6, 2017               [Page 10]


Internet-Draft              MPTCP Transparent                  July 2016


5.  The transparent MPTCP mode

   The transparent MPTCP mode proposed in this documented was designed
   under the assumption that in many hybrid access networks, there is a
   primary access network and the other access network(s) that are
   combined are used to (virtually) increase the capacity of the primary
   access network.  In such networks, operators usually expect that the
   secondary access networks will only be used if the primary access
   networks does not have sufficient capacity to handle the load.

   The solution is targeted at TCP traffic only.  Non TCP traffic is
   sent over the primary access network.  Support for other transport
   protocols over the secondary access networks is outside the scope of
   this document.

                    ____________        _________
                   /            \      /         \    +-+
              +---| access net 2 |----|  backbone |---|S|
              |    \____________/      \_________/    +-+
              |                               |
    +-+    +--+--+                          +-+-+
    |H|----|HCPE |                 +--------|HAG|
    +-+    +--+--+                 |        +---+
              |                    |
              |    ___________     |
              |   /           \    |
              +--| access net 1|---+
                  \___________/

                     Figure 2: Reference architecture

   We consider the network environment shown in figure Figure 2.  Access
   net 1 is the primary network.  This figure reflects the specific
   network configuration that is required for the transparent Multipath
   TCP mode.  The HAG MUST reside on the path followed by the packets
   sent to/from the HCPE that it serves.  This can be achieved, by e.g.
   using a specific mobile APN that has restricted routing, using
   service chaining at BNG/BRAS, using specific BNG/BRAS domains or AAA/
   RADIUS triggered policy routing at BNG/BRAS.  Several vendors have
   implemented such solutions and they are deployed in various networks.

   A HAG typically serves a group of HCPEs and several HAGs can be
   deployed by an operator.  Note that the requirement of placing the
   HAG on the path of the HCPE that it serves only applies to the
   primary access network.  The other access networks only need to be
   able to reach the HAG.  They do not need direct Internet access.

   The HCPE has two IP addresses (or IP prefixes in the case of IPv6



Peirens, et al.          Expires January 6, 2017               [Page 11]


Internet-Draft              MPTCP Transparent                  July 2016


   prefix delegation) : HCPE@1 and HCPE@2.  HCPE@1 is the primary
   address prefix assigned to the HCPE and host H uses one address from
   this prefix as its public address when contacting remote servers (we
   assume IPv6 in this description.  With IPv4, the HCPE will assign a
   private IPv4 address to the hosts that it serves and will perform
   NAT).  The HAG has one IP address that is reachable from the
   secondary network, identified as HAG@2.  This is illustrated by the
   vertical link on the HAG in Figure 2.

   Both the HCPE and the HAG include a transparent Multipath-TCP/TCP
   proxy.  Various forms of TCP proxies have been defined and are
   deployed [RFC3135].  The HCPE uses its TCP/Multipath TCP proxy to
   convert the regular TCP connections initiated by the client host, H,
   into Multipath TCP connections towards the distant server.  However,
   these Multipath TCP connections do not directly reach the distant
   server.  They are converted into regular TCP connections by the
   Multipath-TCP/TCP proxy running on the HAG.  This is illustrated in
   figure Figure 3.

    +-+       +-----+               +---+      +-+
    |H|       |HCPE |               |HAG|      |S|
    +-+       +-----+               +---+      +-+
     |           |                   |         |
     |<--TCP---->|<=======MPTCP=====>|<--TCP-->|
     |           |                   |         |


    Figure 3: The TCP<->Multipath TCP proxies used on the HCPE and the
                                    HAG


   H           HCPE                            HAG                 S
               @1  @2                         @1  @2
   |           |   |                          |    |               |
    --SYN(1)->
                --------SYN+MPC(2)----------->
                                              --------SYN(3)------>
                                              <------SYN+ACK(4)----
                <-----SYN+ACK+MPC(5)----------
    <-SYN+  --
      ACK(6)


    Figure 4: Creation of the initial subflow with the transparent mode

   The operation of the transparent mode is illustrated in figure
   Figure 4.  We consider the establishment of one TCP connection from
   host H (using address H@) to a distant server, S@.  The following



Peirens, et al.          Expires January 6, 2017               [Page 12]


Internet-Draft              MPTCP Transparent                  July 2016


   packets are exchanged :

   o  (1) H sends a SYN towards S@.

   o  (2) The HCPE intercepts the SYN of the initial handshake.  It
      creates some state for a regular TCP connection between H@ and
      itself acting as a transparent proxy for S@ and a Multipath TCP
      connection towards S@.  These two connections are linked together
      and any data received over one connection is forwarded over the
      other.  The HCPE then sends a SYN with the MP_CAPABLE option
      towards S@ over its primary access network to create a Multipath
      TCP connection to the HAG.  Over the primary access network, this
      SYN appears as originating from H@ and being sent to S@.

   o  (3) The HAG acts as a transparent proxy for S@ and intercepts the
      SYN that contains the MP_CAPABLE option.  It creates some state
      for this Multipath TCP connection and initiates a regular TCP
      connection towards S@.  It should be noted that neither the HCPE
      nor the HAG perform address translation.  The distant server
      receives the SYN from the client as originating from address H@.

   o  (4) The server replies with a SYN+ACK to confirm the establishment
      of the connection.

   o  (5) The HAG intercepts the returning SYN+ACK.  The HAG then sends
      a SYN+ACK with the MP_CAPABLE option to confirm the establishment
      of the Multipath TCP connection that is proxied by the HCPE.

   o  (6) The HCPE sends a SYN+ACK to the client host to confirm the
      establishment of the regular TCP connection

   At this point, the establishment of the three connections can be
   finalised by sending a third ACK.  Data can be exchanged by the
   client and the server through the proxied connections.

   The end-to-end connection between the client host (H) and the server
   (S) is composed of three TCP connections : a regular TCP connection
   between the host and the HCPE, a Multipath TCP connection between the
   HCPE and the HAG and a regular TCP connection between the HAG and the
   remote server.  All the packets sent on these three connections
   contain the H@ and S@ addresses in their IP header.

   To use another access network, the HAG simply advertises its address
   reachable through this access network (HAG@2) on the initial subflow
   by sending an ADD_ADDR option (1).  This triggers the establishment
   of an additional subflow from the HCPE over the second access network
   (arrows (2), (3) and (4) in figure Figure 5).  The endpoints of this
   subflow are the IP address of the HCPE on the second access network,



Peirens, et al.          Expires January 6, 2017               [Page 13]


Internet-Draft              MPTCP Transparent                  July 2016


   i.e.  HCPE@2, and the IP address of the HAG, i.e.  HAG@2.  Note that
   the ADD_ADDR option shown in figure Figure 5 is optional.  If the
   HCPE already knows, e.g. by configuration or through mechanisms such
   as [I-D.boucadair-mptcp-radius] or [I-D.boucadair-mptcp-dhc], the IP
   address of the HAG, it can crate the additional subflow without
   waiting for the ADD_ADDR option.

   H           HCPE                            HAG                 S
               @1  @2                         @1  @2
   |           |   |                          |    |               |
   |           |   |                          |    |               |
               <------ADD_ADDR(1)-------------
                   ------SYN+MP_JOIN(2)---------->
                   <-----SYN+ACK+MPJOIN(3)--------
                   -------ACK+MP_JOIN(4)---------->


       Figure 5: Creation of the second subflow by the HCPE with the
                          transparent MPTCP mode

   At this point, any data received from the host by the HCPE or from
   the server by the HAG can be transported over any of the established
   subflows.  Both the HAG and the HCPE select the most appropriate
   subflow based on their policies and the current network conditions
   that are automatically measured by Multipath TCP.

   This is not the only way to create additional subflows.  The HAG may
   also create additional subflows.  This is illustrated in figure
   Figure 6 where we assume that the HAG already knows the IP address of
   the HCPE and thus does not wait for the reception of an ADD_ADDR
   option from the HCPE to create the additional subflow.

   H           HCPE                            HAG                 S
              @1  @2                          @1  @2
   |           |   |                          |    |               |
   |           |   |                          |    |               |
                   <------SYN+MP(1)-----------------
                   -----SYN+ACK+MPJOIN(2)---------->
                   <-------ACK+MP_JOIN(3)-----------


       Figure 6: Creation of the second subflow by the HAG with the
                          transparent MPTCP mode








Peirens, et al.          Expires January 6, 2017               [Page 14]


Internet-Draft              MPTCP Transparent                  July 2016


6.  Security considerations

   Providing a bonding service through different access networks
   introduces new capabilities, but also new threats to the network.  We
   focus in this section on the threats that are specific to the bonding
   service and assume that the CPE devices implement the recommendations
   listed in [RFC6092].  For the HAG, since it operates on the path like
   a router, many of the the security considerations for routers apply.

   When Multipath TCP is used over different paths, the security threats
   listed in [RFC6181] and [RFC7430] need to be considered.  Some of
   these can be mitigated through proper configuration of the HCPEs,
   HAGs and access networks.

   An important security threat with Multipath TCP is if an attacker
   were able to inject data on an existing Multipath TCP by associating
   an additional subflow.  Such an attack is already covered by the
   utilisation of keys in the Multipath TCP handshake.  Thanks to the
   utilisation of the tokens and the HMAC in the MP_JOIN option, the HAG
   and the HCPE will refuse additional subflows created by an attacker
   who did not observe the initial SYN packets.  Note that since the
   keys are only exchanged on the first access network, this attacker
   would have to reside on this access network.

   Since the HAG and the HCPE only create subflows among themselves, it
   is possible for an operator to configure those devices to only accept
   SYN packets with the MP_CAPABLE or MP_JOIN option to those prefixes.
   Furthermore, the second access network does not need to be connected
   to the Internet.  This implies that an attacker would need to reside
   on this network to send packets towards the visible address of the
   HAG.  Ingress filtering and uRPF should be deployed on the access
   networks to prevent spoofing attacks.

   If TCP connections originating from the Internet are accepted on the
   HCPEs, then the HAG must be secured against denial of service attacks
   since it will be involved in the processing of all incoming SYN
   packets.














Peirens, et al.          Expires January 6, 2017               [Page 15]


Internet-Draft              MPTCP Transparent                  July 2016


7.  IANA Considerations

   There are no IANA considerations in this document.
















































Peirens, et al.          Expires January 6, 2017               [Page 16]


Internet-Draft              MPTCP Transparent                  July 2016


8.  Conclusion

   In this document, we have proposed the transparent mode for Multipath
   TCP and described its utilisation in hybrid access networks where a
   secondary access network is used to complement a primary access
   network.  Our solution leverages the flow and congestion control
   capabilities of Multipath TCP to allow an efficient utilisation of
   the different access networks, even if their capacity fluctuates.

   Compared with network layer solutions such as
   [I-D.zhang-gre-tunnel-bonding], the transparent mode does not
   introduce any per-packet overhead and does not require any form of
   network address translation.  Compared with the plain mode Multipath
   TCP proposed in [I-D.boucadair-mptcp-plain-mode], our solution does
   not require any form of network address translation which has clear
   operational benefits.



































Peirens, et al.          Expires January 6, 2017               [Page 17]


Internet-Draft              MPTCP Transparent                  July 2016


9.  References

9.1.  Normative References

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

9.2.  Informative References

   [HotMiddlebox13b]
              Detal, G., Paasch, C., and O. Bonaventure, "Multipath in
              the Middle(Box)", HotMiddlebox'13 , December 2013, <http:/
              /inl.info.ucl.ac.be/publications/multipath-middlebox>.

   [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.boucadair-mptcp-plain-mode]
              Boucadair, M., Jacquenet, C., Behaghel, D.,
              stefano.secci@lip6.fr, s., Henderickx, W., Skog, R.,
              Bonaventure, O., Vinapamula, S., Seo, S., Cloetens, W.,
              Meyer, U., and L. Contreras, "An MPTCP Option for Network-
              Assisted MPTCP Deployments: Plain Transport Mode",
              draft-boucadair-mptcp-plain-mode-08 (work in progress),
              July 2016.

   [I-D.boucadair-mptcp-radius]
              Boucadair, M. and C. Jacquenet, "RADIUS Extensions for
              Network-Assisted Multipath TCP (MPTCP)",
              draft-boucadair-mptcp-radius-01 (work in progress),
              January 2016.

   [I-D.zhang-banana-problem-statement]
              Cullen, M., Leymann, N., Heidemann, C., Boucadair, M.,
              Hui, D., Zhang, M., and B. Sarikaya, "Problem Statement:
              Bandwidth Aggregation for Internet Access",
              draft-zhang-banana-problem-statement-02 (work in
              progress), July 2016.

   [I-D.zhang-banana-tcp-in-bonding-tunnels]
              Zhang, M., Leymann, N., Heidemann, C., and M. Cullen,
              "Flow Control for Bonding Tunnels",
              draft-zhang-banana-tcp-in-bonding-tunnels-00 (work in
              progress), March 2016.



Peirens, et al.          Expires January 6, 2017               [Page 18]


Internet-Draft              MPTCP Transparent                  July 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.

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

   [RFC1990]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
              Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
              DOI 10.17487/RFC1990, August 1996,
              <http://www.rfc-editor.org/info/rfc1990>.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <http://www.rfc-editor.org/info/rfc2784>.

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

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135,
              DOI 10.17487/RFC3135, June 2001,
              <http://www.rfc-editor.org/info/rfc3135>.

   [RFC6092]  Woodyatt, J., Ed., "Recommended Simple Security
              Capabilities in Customer Premises Equipment (CPE) for
              Providing Residential IPv6 Internet Service", RFC 6092,
              DOI 10.17487/RFC6092, January 2011,
              <http://www.rfc-editor.org/info/rfc6092>.

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

   [RFC7430]  Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
              Raiciu, "Analysis of Residual Threats and Possible Fixes
              for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/
              RFC7430, July 2015,
              <http://www.rfc-editor.org/info/rfc7430>.



Peirens, et al.          Expires January 6, 2017               [Page 19]


Internet-Draft              MPTCP Transparent                  July 2016


   [WT-348]   Broadband Forum, ., "Hybrid Access for Broadband Network",
              2014, <http://datatracker.ietf.org/liaison/1355/>.

















































Peirens, et al.          Expires January 6, 2017               [Page 20]


Internet-Draft              MPTCP Transparent                  July 2016


Authors' Addresses

   Bart Peirens
   Proximus

   Email: bart.peirens@proximus.com


   Gregory Detal
   Tessares

   Email: Gregory.Detal@tessares.net


   Sebastien Barre
   Tessares

   Email: Sebastien.Barre@tessares.net


   Olivier Bonaventure
   Tessares

   Email: Olivier.Bonaventure@tessares.net



























Peirens, et al.          Expires January 6, 2017               [Page 21]


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