One document matched: draft-paasch-mptcp-syncookies-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2018 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2018.xml">
<!ENTITY RFC4987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY RFC6824 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6824.xml">
<!ENTITY RFC7323 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7323.xml">
<!ENTITY RFC7413 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7413.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-paasch-mptcp-syncookies-02" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <front>
    <title abbrev="Multipath TCP deployment">Making Multipath TCP robust for stateless webservers</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->
    <author fullname="Christoph Paasch" initials="C.P." surname="Paasch">
      <organization>Apple, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>Cupertino</city>
          <region></region>
          <code></code>
          <country>US</country>
        </postal>
        <email>cpaasch@apple.com</email>
      </address>
    </author>
    <author fullname="Anumita Biswas" initials="A.B." surname="Biswas">
      <organization>Apple, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>Cupertino</city>
          <region></region>
          <code></code>
          <country>US</country>
        </postal>

        <email>anumita_biswas@apple.com</email>
      </address>
    </author>

    <author fullname="Darren Haas" initials="D.H." surname="Haas">
      <organization>Apple, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>Cupertino</city>
          <region></region>
          <code></code>
          <country>US</country>
        </postal>

        <email>dhaas@apple.com</email>
      </address>
    </author>

    <date year="2015" />
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <area>General</area>

    <workgroup>MPTCP Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

<abstract>
<t>
This document proposes a modification of the MPTCP handshake that allows it to
work efficiently with stateless servers. We first identify the issues around
stateless connection establishment using SYN-cookies. Further, we suggest an
extension to Multipath TCP to overcome these issues and discuss alternatives.
</t>
<t>
As a side-effect, the proposed modification to the handshake opens the door to
reduce the size of the MP_CAPABLE option in the SYN. This reduces the growing
pressure on the TCP-option space in the SYN-segment, giving space for future
extensions to TCP.
</t>
</abstract>
  </front>

<middle>
<section title="Introduction">
<t>
During the establishment of a TCP connection, a server must create state upon the reception of the SYN <xref target="RFC0793" />. Specifically, it needs to generate an initial sequence number, and reply to the options indicated in the SYN. The server typically maintains in-memory state for the embryonic connection, including state about what options were negotiated, such as window scale factor <xref target="RFC7323" /> and the maximum segment size. It also maintains state about whether SACK <xref target="RFC2018" /> and TCP Timestamps were negotiated during the 3-way handshake.
</t>

<t>
Attackers exploit this state creation on the server through the SYN-flooding attack. Indeed, an attacker only needs to emit SYN segments with different 4-tuples (source and destination IP addresses and port numbers) in order to make the server create the state and thus consume its memory, while the attacker itself does not need to maintain any state for such an attack <xref target="RFC4987" />.
</t>

<t>
A common mitigation of this attack is to use a mechanism called SYN-cookies. SYN-cookies rely on the fact that a TCP-connection echoes back certain information that the server puts in the SYN/ACK during the three-way handshake. Notably, the sequence-number is echoed back in the acknowledgment field as well as the TCP timestamp value inside the timestamp option. When generating the SYN/ACK, the server generates these fields in a verifiable fashion. Typically, servers use the 4-tuple, the client's sequence number plus a local secret (which changes over time) to generate the initial sequence number by applying a hashing function to the aforementioned fields. Further, setting certain bits either in the sequence number or the TCP timestamp value allows to encode for example whether SACK has been negotiated and what window-scaling has been received <xref target="M08"/>. Upon the reception of the third ACK, the server can thus verify whether the acknowledgment number is indeed the reply to a SYN/ACK it has generated (using the 4-tuple and the local secret). Further, it can decode from the timestamp echo reply the required information concerning SACK, window scaling and MSS-size.
</t>

<t>
In case the third ACK is lost during the 3-way handshake of TCP, stateless servers only work if it's the client who initiates the communication by sending data to the server - which is commonly the case in today's application-layer protocols. As the data segment includes the acknowledgement number for the original SYN/ACK as well as the TCP timestamp value, the server is able to reconstruct the connection state even if the third ACK is lost in the network. If the very first data segment is also lost, then the server is unable to reconstruct the connection state and will respond to subsequent data sent by the client with a TCP Reset.
</t>

<t>
Multipath TCP (MPTCP <xref target="RFC6824" />) is unable to reconstruct the MPTCP level connection state if the third ack is lost in the network (as explained in the following section). If the first data segment from the client reaches the server, the server can reconstruct the TCP state but not the MPTCP state. Such a server can fallback to regular TCP upon the loss of the third ACK. MPTCP is also prone to the same problem as regular TCP if the first data segment is also lost.
</t>

<t>
In the following section a more detailed assessment of the issues with MPTCP and TCP SYN-cookies is presented. Section 3 then shows how these issues might get solved.
</t>

</section>

<section anchor="problem" title="Problem statement">
<t>
Multipath TCP adds additional state to the 3-way handshake. Notably, the keys must be stored in the state so that later on new subflows can be established as well as the initial data sequence number is known to both hosts. In order to support stateless servers, Multipath TCP echoes the keys in the third ACK. A stateless server thus can generate its own key in a verifiable fashion (similar to the initial sequence number), and is able to learn the client's key through the echo in the third ACK. The generation of the key is implementation-specific. An example of such a key-generation would be: Key_Server = Hash(5-tuple, server's subflow sequence number, local_secret).
The reliance on the third ACK however implies that if this segment gets lost, then the server cannot reconstruct the state associated to the MPTCP connection. Indeed, a Multipath TCP connection is forced to fallback to regular TCP in case the third ACK gets lost or has been reordered with the first data segment of the client, because it cannot infer the client's key from the connection and thus won't be able to generate a valid HMAC to establish new subflows nor does it know the initial data sequence number. In the remainder of this document we refer to the aforementioned issue as "Loss of the third ACK".
</t>

<t>
Stateless servers also are unable to recover connection state when the third ack and the first data segment are lost. 
This issue, outlined hereafter, happens even when regular TCP is being used.
In case the client is sending multiple segments when initiating the connection, it might be that the third ack as well as the first data segment get lost. Thus, the server only receives the second data segment and will try to reconstruct the state based on this segment's 4-tuple, sequence number and timestamp value. However, as this segment's sequence number has already gone beyond the client's initial sequence number, it will not be able to regenerate the appropriate SYN-cookie and thus the verification will fail. The server effectively cannot infer that the sequence number in the segment has gone beyond TCP's initial sequence number. This will make the server send a TCP reset as it appears to the server that it received a segment for which no SYN cookie was ever generated.
</t>

</section>

<section anchor="proposal" title="Proposal">
<t>
This section shows how the above problems might be solved in Multipath TCP.
</t>
	<section title="Loss of the third ACK">

<t>
In order to make Multipath TCP robust against the loss of the third ACK
when SYN-cookies are being deployed on servers, we must make sure that the
state-information relevant to Multipath TCP reaches the server in a reliable
way. If the client is initiating the data transfer to the server (this data
is being delivered reliably through TCP) the state-information could be delivered together
with this data and thus is implicitly reliably sent to the server - when the
data reaches the server, the state-information reaches the server as well.
</t>

<t>
We achieve this by adding another variant to the MP_CAPABLE option,
differentiated by the length of it (we call this option MP_CAPABLE_ACK in the
remainder of this document).  It is solely sent on the very first data segment
from the client to the server.  This option serves the dual purpose of
conveying the client's and server's key as well as the DSS mapping which would
otherwise have been sent in a DSS option on the first data segment.
</t>

<t>
Making the MP_CAPABLE in the third ACK reliable opens the door for another
improvement in MPTCP. In fact, the client doesn't need to send its own key in
the SYN anymore (it will send it reliably in the MP_CAPABLE_ACK). Thus, the
MP_CAPABLE option in the SYN segment can avoid adding the key, reducing the
option-space requirement of the MP_CAPABLE down to 4 bytes. This is a major
improvement as the option-space in the SYN segment is very limited, and allows
a TCP connection to negotiate future extensions in the SYN.
</t>

<t>
As this change is a major extension to Multipath TCP, we require that the version
number of the MP_CAPABLE is increased. Further details on the negotiation are presented
in <xref target="negotiation"/>.
The following is a detailled description of the option format and the suggested handshake.
</t>

<section anchor="spec" title="MP_CAPABLE_ACK specification">

<t>
We suggest to remove the key from the MP_CAPABLE in the SYN-segment. The format
of the MP_CAPABLE remains the same (with the bits A to H as well as the version number),
with the difference that the key is no more present. Hosts are able to differentiate
between the different MP_CAPABLE options through the length-field of the TCP-option.
</t>

<t>
The MP_CAPABLE option in the SYN/ACK as well as the third ACK (which does not
contain any data) remain unmodified from RFC6824.
</t>

<t>
The MP_CAPABLE_ACK option (shown in <xref target="MP_CAPABLE_ACK"/>) contains the
same set of bits A to H as well as the version number, like the MP_CAPABLE
option. Further, the option includes the data-level length as well as the checksum
(in case it has been negotiated during the 3-way handshake). This allows the
server to reconstruct the mapping and deliver the data to the application. It
must be noted that the information inside the MP_CAPABLE_ACK is less explicit
than a DSS option. Notably, the data-sequence number, data acknowledgment as
well as the relative subflow-sequence number are not part of the
MP_CAPABLE_ACK. Nevertheless, the server is able to reconstruct the mapping
because the MP_CAPABLE_ACK is guaranteed to only be sent on the very first data
segment. Thus, implicitly the relative subflow-sequence number equals 1 as well
as the data-sequence number, which is equal to the initial data-sequence
number.
</t>

<figure align="center" anchor="MP_CAPABLE_ACK">
<artwork align="center"><![CDATA[
                     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=24  |Subtype|Version|A|B|C|D|E|F|G|H|
+---------------+---------------+-------+-----------------------+
|                  Sender's Key (64 bits)                       |
|                                                               |
+---------------+---------------+-------+-----------------------+
|                 Receiver's Key (64 bits)                      |
|                                                               |
+---------------------------------------------------------------+
| Data-Level Length (2 octets)  | Checksum (2 octets, optional) |
+---------------------------------------------------------------+
]]></artwork>
<postamble>Format of the MP_CAPABLE_ACK option.</postamble>
</figure>

<t>
The handshake (depicted in <xref target="new_handshake"/>) starts with the client
sending the MP_CAPABLE option to the server inside the SYN. The client is not
required to having generated its key already at this point.
</t>

<t>
Upon reception of this SYN-segment, a stateful server generates a random key
and replies with a SYN/ACK.
If the server behaves in a stateless manner it has to generate it's
own key in a verifiable fashion. This verifiable way of generating the key can be
done by using a hash of the 4-tuple, sequence number and a local secret (similar
to what is done for the TCP-sequence number <xref target="RFC4987"/>).
It will thus be able to verify whether it is indeed the originator of the key
echoed back in the MP_CAPABLE_ACK option. When generating this verifiable
key, the server has to ensure that the token derived from this key is locally unique (Section 3.1 of RFC6824).
If there is already an MPTCP-session with such a token, the server must
fallback to regular TCP by not sending an MP_CAPABLE in the third ACK.
</t>

<figure align="center" anchor="new_handshake">
<artwork align="center"><![CDATA[
Host A                                         Host B
------                                         ------
               SYN + MP_CAPABLE (4 bytes)
   -------------------------------------------->
             SYN/ACK + MP_CAPABLE (Key_B, 12 bytes)
   <--------------------------------------------
         ACK + MP_CAPABLE (Key_A, Key_B, 20 bytes)
   -------------------------------------------->

   DATA + MP_CAPABLE_ACK (Key_A, Key_B, Length, Csum, 24 bytes)
   -------------------------------------------->
]]></artwork>
<postamble>The modified MPTCP-handshake only consumes 4 bytes in the SYN.</postamble>
</figure>

<t>
To complete the three-way handshake, the client has to reply with a third ACK
and the MP_CAPABLE option (with both keys as defined in RFC6824).
If the client has already data to send, it can even avoid sending the third ACK,
and immediately send the data together with the MP_CAPABLE_ACK. Otherwise,
the client sends the MP_CAPABLE_ACK as soon as the application writes data on
the socket.
</t>

<t>
The goal of the third ACK (with the MP_CAPABLE) as well as the MP_CAPABLE_ACK is
to convey the client's key to the server. An indication for the client that the
server received the key is when the server issues a DATA_ACK inside the DSS-option (even
if this DATA_ACK does not acknowledge any data).
Thus, as long as the client has not sent an MP_CAPABLE_ACK with data, it must
add the MP_CAPABLE option in each (non-data) segment sent to the server. It must
do this until it either did send an MP_CAPABLE_ACK or until it received a DATA_ACK
from the server. The reason for this is explained in <xref target="tfo"/> and <xref target="nodata"/>.
Combining the MP_CAPABLE with the DATA_ACK will require 20 + 8 bytes, which still leaves 12 bytes for
the TCP timestamp option.
</t>

<t>
Finally, the server must send a duplicate acknowledgment to the client upon reception
of the client's key. This, to convey to the client that it successfully received
the MP_CAPABLE(_ACK) option. It must be noted that this 4-way handshake does not
prevent the client to send data before the reception of this fourth acknowledgment.
</t>

<t>
This mechanism of sending the MP_CAPABLE with a
DATA_ACK until the server acknowledges it, introduces additional complexity to
the handshake. However, we consider the gain of reducing the MP_CAPABLE option
in the SYN-segment as significant enough, that it is worth to accept this added
complexity.
</t>

</section>

	<section anchor="tfo" title="TCP Fast Open">
<t>
If TCP Fast Open <xref target="RFC7413"/> is being used
in combination with Multipath TCP <xref target="I-D.barre-mptcp-tfo"/>, the
server is allowed to send data right after the SYN/ACK, without the need to
wait for the third ACK. The server sending this data cannot include a DATA_ACK
option inside the DSS option as it does not yet know the client's key.
This is not an issue as the DATA_ACK is optional in the DSS option.
</t>

<t>
However, the client receiving this data sent by the server will have to acknowledge it with a
DATA_ACK. As specified above, the client must also send an MP_CAPABLE option on
this acknowledgment as it didn't yet receive a DATA_ACK from the server.
</t>
</section>

	<section anchor="negotiation" title="Negotiation">
<t>
We require a way
for the hosts to negotiate support for the suggested handshake. As we
modify the size of the MP_CAPABLE, our proposal relies on a new version
of MPTCP. The client requests this new version of MPTCP during the
MP_CAPABLE exchange (it remains to be defined by the IETF which version
of MPTCP includes the MP_CAPABLE_ACK option). If the server supports
this version, it replies with a SYN/ACK including the MP_CAPABLE and
indicating this same version.
</t>
	</section>

	<section title="DATA_FIN">

<t>
As the MP_CAPABLE_ACK option includes the same bitfields as the regular
MP_CAPABLE, there is no space to indicate a DATA_FIN as is done in the DSS
option. This implies that a client cannot send a DATA_FIN together with the
first segment of data. Thus, if the server requests the usage of MP_CAPABLE_ACK
through the C-bit, the client must send a separate segment with the DSS-option,
setting the DATA_FIN-flag to 1, after it has sent the data-segment that includes
the MP_CAPABLE_ACK option.
</t>

	</section>

	<section anchor="nodata" title="Server sending data">
	<t>
The MP_CAPABLE_ACK version can only be sent by the client if it actually
has data to send. One question that this raises is how the proposal will work when
the server is the first one to send data to the client. In the following we describe
how the handshake will still work when servers behave in a stateless and stateful manner.
	</t>

	<t>
For stateless servers the same issue arises as well for regular TCP. Upon loss
of the third ACK, the server cannot complete the three-way handshake. Thus,
stateless servers that begin the application level protocol by emitting data rely
on the fact that the third ACK is received (irregardless of whether MPTCP is used
or not). Thus, this implies that the server also will receive the MP_CAPABLE with
this third ACK.
	</t>

	<t>
Stateful servers will retransmit the SYN/ACK until the third ACK (including the
MP_CAPABLE) has been received. This will thus provide to the server the client's
key. When the client eventually sends its own first data segment
to the server, it actually does not has to use the MP_CAPABLE_ACK option because
the server already did send a DATA_ACK to the client.
	</t>

	</section>

	<section title="Middlebox considerations">
<t>
Multipath TCP has been designed with middleboxes in mind and so the MP_CAPABLE_ACK option must also be able to go through middleboxes. The following middlebox behaviors have been considered and MP_CAPABLE_ACK acts accordingly across these middleboxes:
</t>

<t><list style="symbols">

<t>Removing MP_CAPABLE_ACK-option: If a middlebox strips the MP_CAPABLE_ACK option out of the data segment, the server receives data without a corresponding mapping. As defined in Section 3.6 of <xref target="RFC6824"/>, the server must then do a seamless fallback to regular TCP. </t>

	<t>
Coalescing segments: A middlebox might coalesce the first and second data
segment into one single segment. While doing so, it might remove one of the
options (either MP_CAPABLE_ACK or the DSS-option of the second segment because
of the limited 40 bytes TCP option space). There are two cases to consider:
	<list style="symbols">
	<t>
If the DSS-option is not included in
the segment, the second half of the payload is not covered by a mapping. Thus,
the server will do a seamless fallback to regular TCP as defined by <xref
target="RFC6824"/> in Section 3.6. This fallback will trigger because RFC6824
specifies that during the beginning of a connection (as long as the path has not
been proven to let the MPTCP-options unmodified in both directions) a seamless
fallback to regular TCP must be done by stopping to send DATA_ACKs to the client.
	</t>
	<t>
If the MP_CAPABLE_ACK option is not present, then
the DSS-option provides an offset of the TCP sequence number. As the server
behaves statelessly it can only assume that the present mapping belongs to the
first byte of the payload (similar to what is explained in detail in <xref
target="lossfirst"/>). As this however is not true, it will calculate an
incorrect initial TCP sequence number and thus reply with a TCP-reset as the
SYN-cookie is invalid. As such kind of middleboxes are very rare we consider
this behavior as acceptable.
	</t>
	</list>
	</t>

<t>Splitting segments: A TCP segmentation offload engine (TSO) might split the first segment in smaller segments and copy the MP_CAPABLE_ACK option on each of these segments. Thanks to the data-length value included in the MP_CAPABLE_ACK option, the server is able to detect this and correctly reconstructs the mapping. In case the first of these splitted segments gets lost, the server finds itself in a situation similar to the one described in <xref target="problem"/>. The TCP sequence number doesn't allow anymore to verify the SYN-cookie and thus a TCP reset is sent. This behavior is the same as for regular TCP.</t>

<t>Payload modifying middlebox: In case the middlebox modifies the payload, the DSS-checksum included in the MP_CAPABLE_ACK option allows to detect this and will trigger a fallback to regular TCP as defined in <xref target="RFC6824" />.</t>

</list></t>
	</section>
	</section>

	<section anchor="lossfirst" title="Loss of the first data segment">
<t>
<xref target="problem" /> described the issue of losing the first data segment of a connection while TCP SYN-cookies are in use. The following outlines how Multipath TCP actually allows to fix this particular issue.
</t>

<t>
Consider the packet-flow of <xref target="lost_segment" />. Upon reception of the second data segment, the included data sequence mapping allows the server to actually detect that this is not the first segment of a TCP connection. Indeed, the relative subflow sequence number inside the DSS-mapping is actually 100, indicating that this segment is already further ahead in the TCP stream. This allows the server to actually reconstruct the initial sequence number based on the sequence number in the TCP-header ((X+100) - 100) that has been provided by the client and verify whether its SYN-cookie is correct. Thus, no TCP-reset is being sent - in contrast to regular TCP, where the server cannot verify the SYN-cookie. The server knows that the received segment is not the first one of the data stream and thus it can store it temporarily in the out-of-order queue of the connection. It must be noted that the server is not yet able to fully reconstruct the MPTCP state. In order to do this it still must await the MP_CAPABLE_ACK option that is provided in the first data segment.
</t>

<t>
The server responds to the out-of-order data with a duplicate ACK. The duplicate ACK may also have SACK data if SACK was negotiated. However, if this duplicate ACK does not have an MPTCP level Data ACK, the client may interpret this as a fallback to TCP. This is because the client cannot determine if an option stripping middlebox removed the MPTCP option on TCP segments after connection establishment. So even though the server has not fully recreated the MPTCP state at this point, it should respond with a Data ACK set to the Data Sequence Number Y-100. The client's TCP implementation may retransmit the first data segment after a TCP retransmit timeout or it may do so as part of an Early Retransmit that can be triggered by an ACK arriving from the server.
</t>

<figure align="center" anchor="lost_segment">
<artwork align="center"><![CDATA[
Host A                                         Host B
------                                         ------
               SYN + MP_CAPABLE
   -------------------------------------------->
             SYN/ACK + MP_CAPABLE
   <--------------------------------------------
         ACK + MP_CAPABLE
   -----------------------------------X

   DATA (TCP-seq = X) + MP_CAPABLE_ACK
   -----------------------------------X
   DATA (TCP-seq = X+100) + DSS (DSN = Y, subseq = 100)
   --------------------------------------------->

         DATA_ACK (Y - 100)
   <---------------------------------------------
]]></artwork>
<postamble>Multipath TCP's DSS option allows to handle the loss of the first data segment as the host can infer the initial sequence number.</postamble>
</figure>

	</section>
</section>

<section title="Alternative solutions">
<t>
An alternative solution to creating the MP_CAPABLE_ACK option would have been to emit the MP_CAPABLE-option together with the DSS-option on the first data segment. However, as the MP_CAPABLE option is 20 bytes long and the DSS-option (using 4-byte sequence numbers) consumes 16 bytes, a total of 36 bytes of the TCP option space would be consumed by this approach. This option has been dismissed as it would prevent any other TCP option in the first data segment, a constraint that would severely limit TCP's extensibility in the future.
</t>
</section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Our proposal requires the change of the MPTCP-version number.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
Sending the keys in a reliable way after the three-way handshake implies that
there is a larger window during which an on-path attacker might modify the keys
that are being sent in the MP_CAPABLE_ACK. However, we do not think that this
can actually be considered as a security issue. If an attacker modifies the keys,
the outcome will be that the client and the server won't agree anymore on the
data-sequence numbers. The data-flow will thus stall. Considering that the attacker
has to be an active on-path attacker to launch this attack, he has already
other means of interfering with the connection. Thus, this attack is considered as
irrelevant.
      </t>

      <t>
Further, if servers implement the proposal from <xref target="lossfirst"/>, to
handle the scenario where the first data-segment is lost, the incoming segments
need to be stored in the out-of-order queue. The server will store these segments
without having verified the key that the client provides in the MP_CAPABLE option.
This might be considered as a security risk where an attacker could consume
buffer space in the server. It must be noted however that in order to achieve this,
the attacker needs to correctly guess the SYN-cookie so that the verification described
in <xref target="lossfirst"/> is successful.
As MPTCP does not try to be more secure than regular TCP, this thread can
be considered acceptable, as it uses the same level of security as regular TCP's SYN-cookies.
Nevertheless, servers are free to avoid storing those segments in the out-of-order
queue if the thread is considered important enough.
      </t>
    </section>

<section anchor="acknow" title="Acknowledgments">
<t>
We would like to thank Olivier Bonaventure, Yoshifumi Nishida and Alan Ford for their comments and
suggestions on this draft.
</t>
</section>

  </middle>

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
    &RFC4987;
    &RFC6824;
    </references>

    <references title="Informative References">
    &RFC793;
    &RFC2018;
    &RFC7323;
    &RFC7413;
    <?rfc include='reference.I-D.barre-mptcp-tfo.xml'?>
      <reference anchor="M08"
                 target="http://lwn.net/Articles/277146/">
        <front>
          <title>Improving syncookies</title>
          <author fullname="Patrick McManus" initials="P.M." surname="McManus"/>
          <date year="2008" />
        </front>
      </reference>
    </references>
  </back>
</rfc>