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

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

       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)|
      +-------------------------------+

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:

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

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

7.2. Informative References

Authors' Addresses