<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-boucadair-mptcp-connectivity-checks-00"
     ipr="trust200902">
  <front>
    <title abbrev="MPTCP Compatibility Assessement">MPTCP Connectivity
    Checks</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>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.).</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>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.</t>

      <t>The problem space is further described in <xref
      target="problem"></xref>, while a proposed solution is discussed in
      <xref target="solution"></xref>.</t>
    </section>

    <section anchor="problem" title="Problem Space">
      <t>Advanced flow-aware service functions (e.g., Performance Enhancement
      Proxies (<xref target="RFC3135"></xref>), NATs <xref
      target="RFC3022"></xref>, CGNs <xref target="RFC6888"></xref>, DS-Lite
      AFTR <xref target="RFC6333"></xref>, NAT64 <xref
      target="RFC6146"></xref>, NPTv6 <xref target="RFC6296"></xref>,
      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.</t>

      <t>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.</t>

      <t>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 <xref
      target="RFC6824"></xref>.</t>

      <t>MPTCP supports a mechanism to fallback to TCP when a flow-aware
      function interferes with MPTCP signals. <xref target="ex1"></xref> and
      <xref target="ex2"></xref> 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 <xref target="RFC6824"></xref> for more
      details about the exact fallback behavior.</t>

      <t><figure align="center" anchor="ex1" title="Fallback Case 1">
          <artwork><![CDATA[                Host T1                               Host T2
      ------------------------             ------------------------
      Address A1    Address A2             Address B1    Address B2
      ----------    ----------             ----------    ----------
          |             |                      |             |
          |     (initial MPTCP setup)          |             |
    T0    |----------------------------------->|             |
          |<-----------------------------------|             |
          |             |                      |             |
          |       Fall Back to TCP             |             |
    T0+t  |----------------------------------->|             |
          |<-----------------------------------|             | 
          |             |                      |             |
]]></artwork>
        </figure></t>

      <t><figure align="center" anchor="ex2" title="Fallback Case 2">
          <artwork><![CDATA[                Host T1                             Host T2
      ------------------------             ------------------------
      Address A1    Address A2             Address B1    Address B2
      ----------    ----------             ----------    ----------
          |             |                      |             |
          |     (initial MPTCP setup)          |             |
    T0    |----------------------------------->|             |
          |<-----------------------------------|             |
          |             |                      |             |
          |             |                      |             |  
          |<------- Wrong DSS------            |             | 
          |             |                      |             |
          |       Fall Back to TCP             |             |
    T0+t  |----------------------------------->|             |
          |<-----------------------------------|             | 
          |             |                      |             |
]]></artwork>
        </figure></t>

      <t>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.</t>
    </section>

    <section anchor="solution" title="Proposed Solution">
      <t>The problem in <xref target="problem"></xref> 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.</t>

      <t>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.</t>

      <t>This procedure 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.); it is not executed for every new MPTCP
      connection:<list style="symbols">
          <t>An MPTCP-enabled endpoint is configured with one or a list of
          MCCS servers. <vspace blankLines="1" />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 <xref target="RFC1123"></xref>) to
          retrieve the corresponding IP address(es) (IPv4, IPv6 or both).</t>

          <t>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. <vspace blankLines="1" />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. <vspace blankLines="1" />The tests are executed
          both from the MPTCP-enabled endpoint and also the MCCS. The
          extension defined <xref
          target="I-D.boucadair-mptcp-symmetric"></xref> is RECOMMENDED so
          that the MCCS can initiate MPTCP connections, add new subflows to an
          active MPTCP connection, etc. <vspace blankLines="1" />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
          <xref target="ex3"></xref> for illustration purposes.<figure
              align="center" anchor="ex3"
              title="An example of connectivity checks">
              <artwork><![CDATA[                Host T1                     MCCS
      ------------------------             ----------
      Address A1    Address An             Address 1
      ----------    ---------             ----------
          |            |                       |     
          |     (initial MPTCP setup 1)        |     
          |---------------------------------->-|     
          |<-----------------------------------|     
          |                ....                |     
          |            |(initial MPTCP setup n)|     
          |            |---------------------->|     
          |            |<----------------------|   
          |            |                       | 
          |                ....                |     
          |            |      MPTCP setup m    |     
          |            |<----------------------|     
          |            |---------------------->|   
          |            |                       | 
    
]]></artwork>
            </figure></t>

          <t>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.<vspace blankLines="1" />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.<vspace
          blankLines="1" />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).</t>

          <t>This procedure is executed whenever network conditions change, as
          perceived by an MPTCP-enabled endpoint.</t>
        </list></t>

      <t>In the context of <xref target="I-D.deng-mptcp-proxy"></xref>, 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.</t>

      <t>A deployment option would consist in integrating connectivity check
      capabilities in STUN servers <xref target="RFC5389"></xref>; an
      extension would be needed for that purpose, though.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>MPTCP-related security considerations are documented in <xref
      target="RFC6824"></xref> and <xref
      target="I-D.ietf-mptcp-attacks"></xref>.</t>

      <t>Security-consideration specific to MCCS will be discussed.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBC</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.6824'?>

      <?rfc include='reference.RFC.2119'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-mptcp-attacks"?>

      <?rfc include='reference.RFC.6333'?>

      <?rfc include='reference.RFC.1123'?>

      <?rfc include='reference.RFC.6888'?>

      <?rfc include='reference.RFC.3022'?>

      <?rfc include='reference.RFC.3135'?>

      <?rfc include='reference.RFC.6146'?>

      <?rfc include='reference.RFC.6296'?>

      <?rfc include='reference.RFC.5389'?>

      <?rfc include='reference.I-D.deng-mptcp-proxy'?>

      <reference anchor="I-D.boucadair-mptcp-symmetric"
                 target="https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-01">
        <front>
          <title>An Extension to MPTCP for Symmetrical Sub-Flow
          Management</title>

          <author fullname="Mohamed Boucadair" initials="M."
                  surname="Boucadair">
            <organization>France Telecom</organization>

            <address>
              <postal>
                <street></street>

                <city>Rennes</city>

                <region></region>

                <code>35000</code>

                <country>France</country>
              </postal>

              <email>mohamed.boucadair@orange.com</email>
            </address>
          </author>

          <author fullname="Christian Jacquenet" initials="C."
                  surname="Jacquenet">
            <organization>France Telecom</organization>

            <address>
              <postal>
                <street></street>

                <city>Rennes</city>

                <region></region>

                <code>35000</code>

                <country>France</country>
              </postal>

              <email>christian.jacquenet@orange.com</email>
            </address>
          </author>

          <date day="04" month="March" year="2015" />
        </front>
      </reference>

      <!---->
    </references>
  </back>
</rfc>
