<?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-symmetric-02"
     ipr="trust200902" updates="6824">
  <front>
    <title abbrev="Symmetrical MPTCP">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 />

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

      <t>This document updates RFC 6824.</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 title="Introduction">
      <t>This document specifies a MPTCP <xref target="RFC6824"></xref>
      extension to achieve symmetrical subflow management. The problem space
      is further described in <xref target="problem"></xref>, while a proposed
      solution is discussed in <xref target="solution"></xref>.</t>

      <t>This document assumes Port Control Protocol (PCP)-enabled networks
      <xref target="RFC6887"></xref>. 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 <xref
      target="RFC6888"></xref>, firewall, etc.).</t>
    </section>

    <section anchor="problem" title="Problem Space">
      <t>The following is extracted from<xref
      target="I-D.ietf-mptcp-experience"></xref>:</t>

      <t><list style="empty">
          <t>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 <xref
          target="I-D.eardley-mptcp-implementations-survey"></xref> 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.</t>
        </list></t>

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

    <section anchor="solution" title="Proposed Solution">
      <t>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:<list style="symbols">
          <t>Each endpoint proceeds to the discovery of upstream flow-aware
          devices (e.g., NAT, Firewall).<vspace blankLines="1" />This can be
          achieved by various means, e.g., using UPnP IGD <xref
          target="IGD1"></xref><xref target="IGD2"></xref>, PCP server
          discovery <xref target="RFC6887"></xref>, PCP DHCP option <xref
          target="RFC7291"></xref>, DS-Lite AFTR <xref
          target="RFC6334"></xref>, etc.<vspace blankLines="1" />A
          NAT/firewall can be embedded in a CPE (Customer Premises Equipment)
          and/or hosted in the network provider's side.</t>

          <t>Appropriate mappings are instantiated in those discovered
          flow-aware devices. In particular, external IP address(es) and port
          numbers are retrieved. <vspace blankLines="1" />This can be achieved
          using PCP <xref target="RFC6887"></xref>. 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). <vspace blankLines="1" />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. <vspace blankLines="1" />If the
          host is a UPnP IGD Control Point, <xref target="RFC6970"></xref>
          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 <xref target="I-D.ietf-pcp-proxy"></xref> in
          intermediate NATs/firewalls.</t>

          <t>When initiating an MPTCP connection, external IP addresses and
          port numbers are communicated to the remote peer.<vspace
          blankLines="1" />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.<vspace
          blankLines="1" />A second 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. Indicating the
          lifetime associated with an IP address is seen as a limitation of
          current APIs as discussed in Section-3.2.1 of <xref
          target="RFC6250"></xref>. The lifetime can be used as a hint to
          migrate flows to another subflows.<vspace blankLines="1" />Another
          implementation flavor is to update ADD_ADDR as shown in <xref
          target="updated"></xref>. "IPVer" is useless since the length is
          sufficient to determine whether the enclosed IP address is IPv4 or
          IPv6.<figure anchor="updated">
              <artwork><![CDATA[OLD:
        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    |ADD_ADDR| IPVer  |  Address ID   |
       +---------------+---------------+--------+--------+---------------+
       |          Address (IPv4 - 4 octets / IPv6 - 16 octets)           |
       +-------------------------------+---------------------------------+
       |   Port (2 octets)             |
       +-------------------------------+

NEW:
       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    |ADD_ADDR| Flags  |  Address ID   |
      +---------------+---------------+--------+--------+---------------+
      |          Address (IPv4 - 4 octets / IPv6 - 16 octets)           |
      +-------------------------------+---------------------------------+
      |   Port (2 octets)             |
      +-------------------------------+

                                        +-+-+-+-+
      Flags is a set of 4 flags:        |C|r|r|r|
                                        +-+-+-+-+

      C flag MUST be set to 1 when the address/port are checked.
      "rrr" are for future assignment as additional flag bits.
      r bits MUST each be sent as zero and MUST be ignored on receipt.
]]></artwork>
            </figure></t>
        </list></t>

      <t></t>
    </section>

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

    <section anchor="iana" title="IANA Considerations">
      <t>TBC.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thank to Olivier Bonaventure who suggested the idea of updating
      ADD_ADDR.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-mptcp-attacks'?>

      <?rfc include='reference.I-D.eardley-mptcp-implementations-survey'?>

      <?rfc include='reference.I-D.ietf-pcp-proxy'?>

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

      <reference anchor="IGD1">
        <front>
          <title>WANIPConnection:1 Service
          (http://www.upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf)</title>

          <author fullname="UPnP Forum" surname="UPnP Forum">
            <organization></organization>
          </author>

          <date day="" month="November" year="2001" />
        </front>
      </reference>

      <reference anchor="IGD2">
        <front>
          <title>WANIPConnection:2 Service
          (http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf)</title>

          <author fullname="UPnP Forum" surname="UPnP Forum">
            <organization></organization>
          </author>

          <date day="15" month="September" year="2010" />
        </front>
      </reference>

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