An Extension to MPTCP for Symmetrical Sub-Flow Management
draft-boucadair-mptcp-symmetric-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Mohamed Boucadair  , Christian Jacquenet 
Last updated 2015-03-03
Stream (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Experimental                             France Telecom
Expires: September 4, 2015                                 March 3, 2015

       An Extension to MPTCP for Symmetrical Sub-Flow Management
                   draft-boucadair-mptcp-symmetric-00

Abstract

   This document specifies a MPTCP extension that allows to achieve
   symmetrical subflow management.  In particular, this extension allows
   both endpoints to add new subflows whenever needed without waiting
   for the endpoint which initiated the first subflow to add new ones.

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 September 4, 2015.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Boucadair & Jacquenet   Expires September 4, 2015               [Page 1]
Internet-Draft              Symmetrical MPTCP                 March 2015

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Space . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Proposed Solution . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   This document specifies a MPTCP [RFC6824] extension to achieve
   symmetrical subflow management.  The problem space is further
   described in Section 2, while a proposed solution is discussed in
   Section 3.

   This document assumes Port Control Protocol (PCP)-enabled networks
   [RFC6887].  But other procedures can be used to instantiate mappings
   and discover the external lP address/port assigned by an upstream
   flow-aware device (e.g., CGN [RFC6888], firewall, etc.).

2.  Problem Space

   The following is extracted from[I-D.ietf-mptcp-experience]:

      From a subflow viewpoint, the Multipath TCP protocol is completely
      symmetrical.  Both the clients and the server have the capability
      to create subflows.  However in practice the existing Multipath
      TCP implementations [I-D.eardley-mptcp-implementations-survey]
      have opted for a strategy where only the client creates new
      subflows.  The main motivation for this strategy is that often the
      client resides behind a NAT or a firewall, preventing passive
      subflow openings on the client.

   This means that in practice only the client (that is the TCP endpoint
   that initiated the first subflow) can initiate new subflows.  This is
   not optimal in situations where (1) the remote endpoints want to
   boost their sending rate or handover to a new IP address without

Boucadair & Jacquenet   Expires September 4, 2015               [Page 2]
Internet-Draft              Symmetrical MPTCP                 March 2015

   waiting for the client to add new subflows, (2) or when the traffic
   distribution as observed by the remote endpoint does not meet its
   local policies.  Adding new subflows should be subject to both the
   client's and server's local policies, not only those of the client.

3.  Proposed Solution

   This procedure can be activated upon bootstrap or when a network
   attachment change occurs (e.g., attach to a new network); it is not
   executed for every new MPTCP connection:

   o  Each endpoint proceeds to the discovery of upstream flow-aware
      devices (e.g., NAT, Firewall).

      This can be achieved by various means, e.g., using UPnP IGD
      [IGD1][IGD2], PCP server discovery [RFC6887], PCP DHCP option
      [RFC7225], DS-Lite AFTR [RFC6334], etc.

      A NAT/firewall can be embedded in a CPE (Customer Premises
      Equipment) and/or hosted in the network provider's side.

   o  Appropriate mappings are instantiated in those discovered flow-
      aware devices.  In particular, external IP address(es) and port
      numbers are retrieved.

      This can be achieved using PCP [RFC6887].  Note, mappings created
      by PCP MAP requests are, by definition, endpoint-independent
      mappings (EIMs) with endpoint-independent filtering (EIF).
      Filters can be associated with the PCP MAP request to restrict a
      mapping to be bound to specific remote peer(s).

      PCP allows to dynamically control both NATs and firewalls.
      Furthermore, PCP allows to retrieve the lifetime associated with
      an external IP address and external port number.

      If the host is a UPnP IGD Control Point, [RFC6970] allows to relay
      UPnP IGD primitives into PCP messages.  PCP can also be used to
      control multi-layered NATs/firewall owing to the activation of
      [I-D.ietf-pcp-proxy] in intermediate NATs/firewalls.

   o  When initiating an MPTCP connection, external IP addresses and
      port numbers are communicated to the remote peer.

      This can be achieved using ADD_ADDR together with a new option
      that will indicate that the address/port pair (identified by
      Address ID) enclosed in ADD_ADDR has been checked so that incoming
      flows can be sent to this address/port.

Boucadair & Jacquenet   Expires September 4, 2015               [Page 3]
Internet-Draft              Symmetrical MPTCP                 March 2015

      Another implementation flavor is to define a new option, similar
      to ADD_ADDR, but which will include an optional field (lifetime).
      The lifetime can be used as an input to the traffic management
      block at the remote side.  This field can be derived from the
      lease returned in DHCP, or in PCP requests.  The use of this
      option is an indication that appropriate actions were undertaken
      at the remote side to receive incoming packets.  A remote peer can
      use the enclosed address/port to add a new subflow without any
      risk to experience failures at the client side.

        1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+-------+-------+---------------+
       |     Kind      |     Length    |TBD    | IPVer |  Address ID   |
       +---------------+---------------+-------+-------+---------------+
       |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
       +-------------------------------+-------------------------------+
       |   Port (2 octets)             |Lifetime (Optional) (4 octets) |
       +-------------------------------+-------------------------------+
       | Lifetime (Optional)(continued)|
       +-------------------------------+

4.  Security Considerations

   PCP-related security considerations are discussed in [RFC6887].
   MPTCP-related security considerations are documented in [RFC6824] and
   [I-D.ietf-mptcp-attacks].

5.  IANA Considerations

   TBC.

6.  Acknowledgements

   TBC

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, January 2013.

Boucadair & Jacquenet   Expires September 4, 2015               [Page 4]
Internet-Draft              Symmetrical MPTCP                 March 2015

7.2.  Informative References

   [I-D.eardley-mptcp-implementations-survey]
              Eardley, P., "Survey of MPTCP Implementations", draft-
              eardley-mptcp-implementations-survey-02 (work in
              progress), July 2013.

   [I-D.ietf-mptcp-attacks]
              Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
              Raiciu, "Analysis of MPTCP residual threats and possible
              fixes", draft-ietf-mptcp-attacks-03 (work in progress),
              February 2015.

   [I-D.ietf-mptcp-experience]
              Bonaventure, O., Paasch, C., and G. Detal, "Experience
              with Multipath TCP", draft-ietf-mptcp-experience-00 (work
              in progress), September 2014.

   [I-D.ietf-pcp-proxy]
              Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
              Cheshire, "Port Control Protocol (PCP) Proxy Function",
              draft-ietf-pcp-proxy-06 (work in progress), December 2014.

   [IGD1]     UPnP Forum, , "WANIPConnection:1 Service
              (http://www.upnp.org/specs/gw/
              UPnP-gw-WANIPConnection-v1-Service.pdf)", November 2001.

   [IGD2]     UPnP Forum, , "WANIPConnection:2 Service
              (http://upnp.org/specs/gw/
              UPnP-gw-WANIPConnection-v2-Service.pdf)", September 2010.

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
              RFC 6334, August 2011.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
              2013.

   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Requirements for Carrier-Grade NATs
              (CGNs)", BCP 127, RFC 6888, April 2013.

   [RFC6970]  Boucadair, M., Penno, R., and D. Wing, "Universal Plug and
              Play (UPnP) Internet Gateway Device - Port Control
              Protocol Interworking Function (IGD-PCP IWF)", RFC 6970,
              July 2013.

Boucadair & Jacquenet   Expires September 4, 2015               [Page 5]
Internet-Draft              Symmetrical MPTCP                 March 2015

   [RFC7225]  Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
              Port Control Protocol (PCP)", RFC 7225, May 2014.

Authors' Addresses

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

   Christian Jacquenet
   France Telecom
   Rennes  35000
   France

   Email: christian.jacquenet@orange.com

Boucadair & Jacquenet   Expires September 4, 2015               [Page 6]