One document matched: draft-paasch-mptcp-lowoverhead-00.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 RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ietf-mptcp-multiaddressed SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-multiaddressed-10">
]>
<?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="info" docName="draft-paasch-mptcp-lowoverhead-00" 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 MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="MPTCP Low Overhead">MultiPath TCP Low Overhead</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." role="editor"
surname="Paasch">
<organization>UCLouvain</organization>
<address>
<postal>
<street>Place Sainte Barbe, 2</street>
<city>Louvain-la-Neuve</city>
<region></region>
<code>1348</code>
<country>BE</country>
</postal>
<email>christoph.paasch@uclouvain.be</email>
</address>
</author>
<author fullname="Olivier Bonaventure" initials="O.B."
surname="Bonaventure">
<organization>UCLouvain</organization>
<address>
<postal>
<street>Place Sainte Barbe, 2</street>
<city>Louvain-la-Neuve</city>
<region></region>
<code>1348</code>
<country>BE</country>
</postal>
<email>olivier.bonaventure@uclouvain.be</email>
</address>
</author>
<date month="October" year="2012" />
<area>General</area>
<workgroup>MPTCP</workgroup>
<keyword></keyword>
<abstract>
<t>
This document describes a low overhead connection establishment mechanism for
Multipath TCP. Its goal is to reduce the computational overhead of establishing
an MPTCP connection and the associated TCP subflows in controlled environments
where security attacks are not a concern.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document introduces a variant of the MPTCP handshake that is suitable for
an environment where security attacks are not an issue. The proposed handshake is
a low overhead, low security version of the MPTCP handshake defined in
<xref target="I-D.ietf-mptcp-multiaddressed"/>.
</t>
<t>
Its goal is to provide an MPTCP handshake and authentication mechanism, reducing
the computational overhead provided by MPTCP version 0.
</t>
<!-- <section 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>
</section>-->
</section>
<section anchor="Initial subflow" title="Connection initiation">
<t>
MultiPath TCP uses the MP_CAPABLE option in the handshake for the initial subflow. This
handshake was designed to meet several requirements. When designing another variant of
the Multipath TCP handshake, it is important to have these requirements in mind. These requirements
are :
<list style="numbers">
<t>Detect whether the peer supports MultiPath TCP.</t>
<t>Each host generates a locally unique token that unambiguously identifies the Multipath TCP connection</t>
<t>Agree on an Initial Data Sequence Number to initialize the MPTCP state on each direction of the Multipath TCP connection </t>
</list>
Before discussing the proposed low overhead handshake, it is important to have in mind how <xref target="I-D.ietf-mptcp-multiaddressed"/> meets the three requirements above.
</t>
<t>
The first requirement is simply met by using a Multipath TCP specific option like all TCP extensions.
</t>
<t>
To meet the second requirement, a simple solution would have been to encode the token inside the MP_CAPABLE option. However, this would have increased the size of the MP_CAPABLE option. This would have limited the possibility of extending Multipath TCP later by adding new TCP options that require space inside the SYN segments. To minimize the number of option bytes consummed in the SYN segment, <xref target="I-D.ietf-mptcp-multiaddressed"/> uses a hash function to compute the token based on the keys exchanged in clear. However, using hash functions implies that implementations must handle the possible collisions which increases the complexity of the Multipath TCP handshake.
</t>
<t>
The third requirement is more subtle but is also important to ensure the reliability of a Multipath TCP connection. Let us assume that Multipath TCP hosts do not agree on an Initial Data Sequence Number. Consider the following scenario. Host A opens the initial TCP subflow of the Multipath TCP connection. Host B opens a second subflow in this Multipath TCP connection. Host B sends one byte with DSN x over the initial subflow, but this data never reaches host A. Host B then sends one byte, starting at DSN x+1 over the second subflow. If host A does not know the Initial Data Sequence Number used by host B, it cannot determine whether the byte received over the second subflow can be acknowledged at the DSN level or not. <xref target="I-D.ietf-mptcp-multiaddressed"/> solves this problem by allowing the two hosts to derive the Initial Data Sequence Number from the keys exchanged in the MP_CAPABLE option. However, this is achieved by computing a hash over the exchanged keys, which increases the computational
overhead of generating/processing the MP_CAPABLE option.
</t>
<t>
The figure below provides a simpler and low overhead handshake that meets the three requirements identified above.
</t>
<figure align="center" anchor="low_initial">
<artwork align="center"><![CDATA[
Host A Host B
---------- ----------
Address A1 Address B1
---------- ----------
| |
| SYN+MP_CAPABLE(Token-A, Rand-A) |
|----------------------------------->|
| |
|SYN/ACK+MP_CAPABLE(Token-B, Rand-B) |
|<-----------------------------------|
| |
| ACK+MP_CAPABLE(Token-A, Rand-A, |
| Token-B, Rand-B) |
|----------------------------------->|
]]></artwork>
<postamble>Handshake of the initial subflow.</postamble>
</figure>
<t>
MPTCP's establishment of the initial subflow follows TCP's regular 3-way handshake,
but the SYN, SYN/ACK and ACK packets contain the MP_CAPABLE-option. The proposed MP_CAPABLE
option contains one 32 bits token and one 32 bits random number in the SYN and SYN/ACK segments.
The third ACK includes an MP_CAPABLE option that contains the two tokens and random numbers.
The tokens are used to explictely exchange identifier of the Multipath TCP connection.
The random numbers, combined with the tokens produce the Initial Data Sequence Numbers.
Echoing all the information back in the third ACK allows stateless operation of
the server.
</t>
<t>
The format of the proposed MP_CAPABLE option is proposed in the figures below.
</t>
<figure align="center" anchor="mp_capable_syn">
<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 |Subtype|Version|A|B|C|D|E|F|G|H|
+---------------+---------------+-------+-------+---------------+
| Sender's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
]]></artwork>
<postamble>Format of the MP_CAPABLE-option in the SYN and SYN/ACK packets</postamble>
</figure>
<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 |Subtype|Version|A|B|C|D|E|F|G|H|
+---------------+---------------+-------+-------+---------------+
| Sender's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
| Receiver's Token (32 bits) |
+---------------------------------------------------------------+
| Receivers's Random Number (32 bits) |
+---------------------------------------------------------------+
]]></artwork>
<postamble>Format of the MP_CAPABLE-option in the third ACK of the handshake</postamble>
</figure>
<t>
The format of the MP_CAPABLE option is shown in <xref target="mp_capable_syn"/>. To
indicate that this MP_CAPABLE contains tokens/random numbers and not keys (as in
<xref target="I-D.ietf-mptcp-multiaddressed"/>, the Version-field is set to 1.
The message format of the third ACK's MP_CAPABLE option is show in <xref target="mp_capable_ack"/>.
</t>
<t>
The Initial Data Sequence Number (IDSN) serves to initialize the MPTCP state on the end-hosts
in the same way as TCP's sequence numbers do during the 3-way handshake.
There is one IDSN for each direction of the data-stream.
The IDSN for the data from the client to the server is the concatenation of
Rand-A and Token-A (Rand-A||Token-A). Rand-A is thus the high-order 32 bits of the IDSN,
and Token-A the low-order 32 bits.
For the data from server to client, the IDSN is the concatenation of
Rand-B and Token-B (Rand-B||Token-B).
Rand-A and Rand-B MUST be random numbers with sufficient randomness so that they
are hard to guess. Recommendations for generating random numers for use in keys are given in <xref target="RFC4086"/>.
</t>
<t>
The meaning of the other fields and behavior of the end-hosts during the MP_CAPABLE
exchange is the same as specified in <xref target="I-D.ietf-mptcp-multiaddressed"/>.
</t>
</section>
<section anchor="New subflow" title="Starting a new subflow">
<t>
Once an MPTCP connection has been established and the tokens exchanged, new subflows
can be established. The establishment of the new subflows follows the handshake
as show in <xref target="low_add"/>.
</t>
<figure align="center" anchor="low_add">
<artwork align="center"><![CDATA[
Host A Host B
---------- ----------
Address A2 Address B2
---------- ----------
| |
| SYN + MP_JOIN(Token B) |
|----------------------------------->|
| |
| SYN/ACK + MP_JOIN() |
|<-----------------------------------|
| |
| ACK + MP_JOIN(Token B) |
|----------------------------------->|
]]></artwork>
<postamble>Handshake for a new subflow.</postamble>
</figure>
<t>
As the low-overhead version of MPTCP does not try to protect against hijacking
attacks, the only goal of the MP_JOIN inside the 3-way handshake is to identify
the MPTCP connection this subflow is joining. The token inside the MP_JOIN of the
SYN-segment allows the server to identify the connection. The SYN/ACK also contains
an MP_JOIN option because the server needs to signal to the client that it indeed
received the SYN together with the MP_JOIN and that there is no middlebox that removes
MPTCP options on this path.
Finally, the client replies with the third ack. This third ack contains again
token B. This allows the server to handle MP_JOIN's in a stateless manner,
as described below.
The third ack is sent in a reliable manner as explained in
<xref target="I-D.ietf-mptcp-multiaddressed"/>.
</t>
<figure align="center" anchor="mp_join">
<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 |Subtype| |B| Address ID |
+---------------+---------------+-------+-------+---------------+
| Receiver's Token (32 bits) |
| (if option Length == 8) |
+---------------------------------------------------------------+
]]></artwork>
<postamble>Format of the MP_JOIN-option</postamble>
</figure>
<t>
The semantics of the backup-bit "B" and the Address ID are the same as in
<xref target="I-D.ietf-mptcp-multiaddressed"/>.
</t>
</section>
<section anchor="Mechanisms" title="Operation">
<section anchor="Token generation" title="Generating the token">
<t>
The token must only be locally unique. The method used to generate the token
is implementation specific. One possible way to generate the token is by applying
a block-cipher on a counter together with a local secret. This approach has the
benefit of a higher probability of uniqueness of the token. We will only have a token
collision after the counter has wrapped around. This means, that a connection must have
survived 2^32 other connections to cause a collision. Thus, a token collision is less
likely to occur than with <xref target="I-D.ietf-mptcp-multiaddressed"/>.
</t>
</section>
<section anchor="Stateless" title="Stateless Servers">
<t>
To allow stateless SYN+Join handling, the server has
to perform the following upon reception of a SYN:
<list style="symbols">
<t>
Check whether there exists an MPTCP-connection corresponding
to the token inside the MP_JOIN option.
</t>
<t>
Send a SYN/ACK as it is done on today's stateless
servers.
</t>
</list>
When receiving the third ACK (sent reliably as it is
done in today's MPTCP), the server verifies that indeed
it has generated a SYN/ACK (like regular TCP's SYN-cookie
mechanism) and thanks to the token echoed
back in the third ACK, the server can find the MPTCP-session
this subflow is joining.
</t>
<t>
Handling the SYN+Join in a stateless manner allows the server to protect itself
against attackers that are flooding the server with SYN+Join messages. As the server
does not need to create state when sending the SYN/ACK, flooding performed by the attacker
will not prevent real clients from establishing new subflows.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The proposed solution removes the HMAC authentication mechanism described in
<xref target="I-D.ietf-mptcp-multiaddressed"/>. It is assumed that end-hosts will
only use this low-overhead version of MPTCP for non-security critical traffic
or in controlled environments like isolated data-centers.
</t>
<t>
Security-critical traffic is nowadays typically sent over SSL/TLS or similar secure
application level protocols. This is done because the transport protocols like TCP
do not provide a sufficient security. An application using SSL over MPTCP benefits
from the same security provided by SSL. There is one downside of using SSL over MPTCP.
If an attacker manages to join an existing connection thanks to a JOIN-exchange,
he can inject data into the SSL-session. However, thanks to the MAC-authentication of the
SSL messages, the end-hosts will tear down the SSL session.
</t>
</section>
</middle>
<back>
<!-- <references title="Normative References">
</references>-->
<references title="Informative References">
&I-D.ietf-mptcp-multiaddressed;
&RFC4086;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:52:21 |