MPTCP Connectivity Checks
draft-boucadair-mptcp-connectivity-checks-00

Abstract

This document specifies an extension to minimize the delay induced by the presence of MPTCP-unfriendly nodes in some of the paths selected by a MPTCP endpoint, and which may support the establishment of MPTCP subflows. Concretely, this procedure allows a MPTCP endpoint to assess whether the networks the endpoint connects to are compliant with MPTCP signals or not. The procedure is not enabled for every new MPTCP connection; it is activated upon bootstrap or when a network attachment change occurs (e.g., attach to a new network, discover a new external IP address, etc.).

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 5, 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 an extension that minimizes the delay induced by the presence of MPTCP-unfriendly nodes in the some of the paths selected by a MPTCP endpoint, and which may support the establishment of MPTCP subflows.

The problem space is further described in Section 2, while a proposed solution is discussed in Section 3.

2. Problem Space

Advanced flow-aware service functions (e.g., Performance Enhancement Proxies ([RFC3135]), NATs [RFC3022], CGNs [RFC6888], DS-Lite AFTR [RFC6333], NAT64 [RFC6146], NPTv6 [RFC6296], firewalls, etc.) are required to achieve various objectives such as IP address sharing, firewalling, avoid covert channels, detect and protect against ever increasing DDoS attacks, etc.

Removing those functions is not an option because they are used to address constraints that are often typical of the current yet protean Internet situation (global IPv4 address depletion comes to mind, but also the plethora of services with different QoS/security/robustness requirements, etc.), and this is even exacerbated by environment-specific designs (e.g., the nature and the number of service functions that need to be invoked at the Gi interface of a mobile infrastructure). Moreover, these sophisticated service functions are located in the network but also in service platforms, or intermediate entities (e.g., CDNs). A flow-aware device can be embedded in a CPE (Customer Premises Equipment) and/or hosted in the network provider's side.

In the meantime, the presence of these flow-aware functions complicates the introduction of new protocols or the introduction of additional features for existing ones. Also, because some of these flow-aware functions do not expose a deterministic behavior, additional complications are encountered even if the protocol design includes built-in features to detect (and possibly accommodate) the presence of such functions. This document focuses on MPTCP [RFC6824].

MPTCP supports a mechanism to fallback to TCP when a flow-aware function interferes with MPTCP signals. Figure 1 and Figure 2 show two typical examples of the fallback behavior. It is out of scope of this document to list all the possible fallback scenarios. Refer to [RFC6824] for more details about the exact fallback behavior.

                Host T1                               Host T2
      ------------------------             ------------------------
      Address A1    Address A2             Address B1    Address B2
      ----------    ----------             ----------    ----------
          |             |                      |             |
          |     (initial MPTCP setup)          |             |
    T0    |----------------------------------->|             |
          |<-----------------------------------|             |
          |             |                      |             |
          |       Fall Back to TCP             |             |
    T0+t  |----------------------------------->|             |
          |<-----------------------------------|             | 
          |             |                      |             |

                Host T1                             Host T2
      ------------------------             ------------------------
      Address A1    Address A2             Address B1    Address B2
      ----------    ----------             ----------    ----------
          |             |                      |             |
          |     (initial MPTCP setup)          |             |
    T0    |----------------------------------->|             |
          |<-----------------------------------|             |
          |             |                      |             |
          |             |                      |             |  
          |<------- Wrong DSS------            |             | 
          |             |                      |             |
          |       Fall Back to TCP             |             |
    T0+t  |----------------------------------->|             |
          |<-----------------------------------|             | 
          |             |                      |             |

                Host T1                     MCCS
      ------------------------             ----------
      Address A1    Address An             Address 1
      ----------    ---------             ----------
          |            |                       |     
          |     (initial MPTCP setup 1)        |     
          |---------------------------------->-|     
          |<-----------------------------------|     
          |                ....                |     
          |            |(initial MPTCP setup n)|     
          |            |---------------------->|     
          |            |<----------------------|   
          |            |                       | 
          |                ....                |     
          |            |      MPTCP setup m    |     
          |            |<----------------------|     
          |            |---------------------->|   
          |            |                       |