[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                       M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Experimental                             France Telecom
Expires: September 5, 2015                                 March 4, 2015


                       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.








Boucadair & Jacquenet   Expires September 5, 2015               [Page 1]


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

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.





Boucadair & Jacquenet   Expires September 5, 2015               [Page 2]


Internet-Draft       MPTCP Compatibility Assessement          March 2015


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

                         Figure 1: Fallback Case 1








Boucadair & Jacquenet   Expires September 5, 2015               [Page 3]


Internet-Draft       MPTCP Compatibility Assessement          March 2015


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

                         Figure 2: Fallback Case 2

   This behavior, if adopted for every new connection, will have
   negative impacts on the quality of experience as perceived by a user.
   This is not desirable.

3.  Proposed Solution

   The problem in Section 2 can be originated by MPTCP-unfriendly
   service function(s) located at the initiator side, the receiver side,
   or the network in between.  In order to avoid increasing the delay to
   establish a TCP-based connection involving an MPTCP-enabled endpoint,
   this document suggests the use of connectivity checks to assess
   whether available paths as perceived by an MPTCP-enabled endpoint can
   safely convey MPTCP signals.  Doing so, the results of such
   connectivty checks allow an MPTCP-enabled endpoint to decide whether
   MPTCP needs to be disabled for all or part of its available network
   attachments.  This also allows the endpoint to identify which paths
   cannot be used to establish the first subflow.  Network attachments
   that aren't MPTCP-friendly are tagged as such.

   A dedicated functional element (referred to as MPTCP Connectivity
   Check Server (MCCS)) is proposed to assess the MPTCP friendliness of
   its network attachments.  MCCS is attached to a network that does not
   involve any MPTCP-unfriendly service function.  If any MPTCP problem
   is encountered when establishing a connection with an MCCS, it is an
   indication that the issue is located at the remote MPTCP-enabled
   endpoint.

   This procedure is activated upon bootstrap or when a network
   attachment change occurs (e.g., attach to a new network, discover a



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


Internet-Draft       MPTCP Compatibility Assessement          March 2015


   new external IP address, etc.); it is not executed for every new
   MPTCP connection:

   o  An MPTCP-enabled endpoint is configured with one or a list of MCCS
      servers.

      A well-known name can be used for this purpose.  The name is then
      passed to the name resolution library (e.g., Section 6.1.1 of
      [RFC1123]) to retrieve the corresponding IP address(es) (IPv4,
      IPv6 or both).

   o  The MPTCP-enabled terminal then establishes MPTCP connections
      based upon all the IP addresses that have been retrieved (or a
      subset thereof).  Executing the procedure with more than one MCCS
      (if available) is RECOMMENDED.

      These MPTCP connections are meant to assess for each available
      network attachment, interface, discovered external IP address,
      etc., that the path that will be solicited when issuing packets
      does not break MPTCP connections.

      The tests are executed both from the MPTCP-enabled endpoint and
      also the MCCS.  The extension defined
      [I-D.boucadair-mptcp-symmetric] is RECOMMENDED so that the MCCS
      can initiate MPTCP connections, add new subflows to an active
      MPTCP connection, etc.

      The tests are performed to cover all failure cases (e.g., strip
      MPTCP signals, alter some options, corrupted DSS, etc.).  An
      example is depicted in Figure 3 for illustration purposes.





















Boucadair & Jacquenet   Expires September 5, 2015               [Page 5]


Internet-Draft       MPTCP Compatibility Assessement          March 2015


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


                Figure 3: An example of connectivity checks

   o  As an outcome of the previous step, the MPTCP-enabled endpoint can
      conclude whether all or some of its available network attachments
      can "safely" be used when establishing MPTCP connections.

      Interfaces/address/networks that are MPTCP-unfriendly are tagged
      accordingly; those are not used when establishing a new MPTCP
      connection with a remote peer or to add a new subflow to an
      existing MPTCP connection.

      In particular, an MPTCP-enabled endpoint will not use MPTCP when
      all its network attachments are MPTCP-unfriendly.  This covers in
      particular the situation where the endpoint initialed the
      connection or when the MPTCP device receives an MPTCP connection
      (e.g., user-generated content context).

   o  This procedure is executed whenever network conditions change, as
      perceived by an MPTCP-enabled endpoint.

   In the context of [I-D.deng-mptcp-proxy], this procedure can be
   implemented at the CPE side on behalf of the MPTCP-enabled terminals
   the CPE is connected to in the user premises.  An MPTCP-enabled
   terminal localed behind a CPE assumes by default that its default
   gateway is its MCCS.  Doing so, this design allows to avoid re-using
   the same connectivity checks for all the terminals located behind a
   CPE.




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


Internet-Draft       MPTCP Compatibility Assessement          March 2015


   A deployment option would consist in integrating connectivity check
   capabilities in STUN servers [RFC5389]; an extension would be needed
   for that purpose, though.

4.  Security Considerations

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

   Security-consideration specific to MCCS will be discussed.

5.  IANA Considerations

   This document does not require any action from IANA.

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.

7.2.  Informative References

   [I-D.boucadair-mptcp-symmetric]
              Boucadair, M. and C. Jacquenet, "An Extension to MPTCP for
              Symmetrical Sub-Flow Management", March 2015,
              <https://tools.ietf.org/html/draft-boucadair-mptcp-
              symmetric-01>.

   [I-D.deng-mptcp-proxy]
              Lingli, D., Liu, D., Sun, T., Boucadair, M., and G.
              Cauchie, "Use-cases and Requirements for MPTCP Proxy in
              ISP Networks", draft-deng-mptcp-proxy-01 (work in
              progress), October 2014.








Boucadair & Jacquenet   Expires September 5, 2015               [Page 7]


Internet-Draft       MPTCP Compatibility Assessement          March 2015


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

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022, January
              2001.

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135, June 2001.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, June 2011.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

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

Authors' Addresses

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com







Boucadair & Jacquenet   Expires September 5, 2015               [Page 8]


Internet-Draft       MPTCP Compatibility Assessement          March 2015


   Christian Jacquenet
   France Telecom
   Rennes  35000
   France

   Email: christian.jacquenet@orange.com













































Boucadair & Jacquenet   Expires September 5, 2015               [Page 9]