The Multipath TCP control stream
During IETF89 we will present a draft [CS] that proposes to define the semantics of a single bit inside the DSS option. This change might appear small at first glance, but it could have a huge impact on the evolution of Multipath TCP and its future.
The DSS option is defined in RFC 6824 to encode the mapping between the Data Sequence Number and the subflow sequence number. RFC 6824 supports one bytestream in each direction between the communicating hosts. This bytestream is use to carry the data supplied by the user applications.
The Control Stream draft [CS] proposes to support two bytestreams in each direction. The first is the regular bytestream that is used to transport regular data. The second is a bytestream that allows the communicating hosts to exchange control information that is relevant for the Multipath TCP connection. [CS] defines the S bit in the DSS option shown below to indicate whether the mapping corresponds to the regular bytestream or to the control stream.
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|(reserved)|S|F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Control ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
|Control sequence number (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
|Control-Level Length (2 octets)| Checksum (2 octets) |
+-------------------------------+------------------------------+
The S bit of the 'reserved' field is set to 1 when sending on the
control stream.
Why would someone want to support two bytestreams over a single Multipath TCP connection ?
The main motivation is that we would like to exchange control information between communicating Multipath TCP hosts without being limited by the existing TCP options :
- TCP options are sent unreliably. When a host sends a segment that contains an ADD_ADDR option inside an acknowledgement, it cannot be certain that this option will be delivered to the other hosts. Some techniques to improve the reliability of the delivery of this option are discussed in [CellNet12]
- TCP options have a limited size. In the Multipath TCP handshake, we use several tricks to extract the required tokens and ISDN from a hash computation to minimize the length of the MP_CAPABLE option, but this hack is far from perfect
With a bytestream that allows to send control information inside the payload of TCP segments, it is possible to define new techniques to synchronise the two communicating state machines. As a first example, it becomes possible to ensure a reliable delivery of the ADD_ADDR option. Consider a client having several IPv6 addresses. An RFC 6824 compliant implementation would probably send these addresses inside independent TCP segments as shown below :
![msc {
width=800, arcgradient = 4;
c [label="Client", linecolour=black],
s [label="Server", linecolour=black];
|||;
c=>s [ label = "SYN(seq=x)\n\n"];
|||;
s=>c [label = "SYN+ACK(seq=y,ack=x+1)\n\n"];
|||;
c=>s [label="ACK(ack=y+1)\n\n"];
|||;
c=>s [label="ACK(seq=x+1,ack=y+1)ADD_ADDR(IP1)\n\n"];
|||;
c-Xs [label="ACK(seq=x+1,ack=y+1)ADD_ADDR(IP2)\n\n"];
|||;
c=>s [label="ACK(seq=x+1,ack=y+1)ADD_ADDR(IP3)\n\n"];
|||;
}](../../../_images/mscgen-36e5d88545e9727164e9eb84cc4810a461aef8ed.png)
The only way for the sender to recover from the loss of the segment advertising IP2 is to regularly send the list of addresses that it owns. This is inefficient.
With the control stream, advertising several addresses becomes much simpler.
![msc {
width=800, arcgradient = 4;
c [label="Client", linecolour=black],
s [label="Server", linecolour=black];
|||;
c=>s [ label = "SYN(seq=x)\n\n"];
|||;
s=>c [label = "SYN+ACK(seq=y,ack=x+1)\n\n"];
|||;
c=>s [label="ACK(ack=y+1)\n\n"];
|||;
c-Xs [label="ACK(seq=x+1,ack=y+1)DSS(CS,IP1-IP2-IP3)\n\n", linecolour=red];
|||;
...;
|||;
c=>s [label="ACK(seq=x+1,ack=y+1)DSS(CS,IP1-IP2-IP3)\n\n", linecolour=red];
|||;
s=>c [label="ACK()\n\n", linecolour=red];
}](../../../_images/mscgen-001a16cc1632cec41b443b5c9cf1d2c86ada432b.png)
The same applies to the RM_ADDR option. With the control stream, the list of the addresses owned by each host can be exchanged reliably.
This is not the only application of the proposed control stream. The control stream could prove to be very useful to enhance the security of Multipath TCP. RFC 6824 includes a basic method to “authenticate” the addition of subflows by exchanging 64 bits keys in clear during the initial three-way handshake. From a security viewpoint, exchanging 64 bits in clear is obviously not the best solution. A better solution would be to use longer keys and rely on a key exchange scheme that is secure even if a passive listener is able to capture the segments exchanged. By relying exclusively on TCP options, this is impossible. With the control stream, it becomes possible to use any secure key agreement mechanism such as Diffie Hellmann or any other scheme to agree on a shared secret. Once the shared secret has been negotiated, it can be used to authenticate the establishment of the additional subflows.
Transporting control information inside the payload of segments may sound familiar to those who have followed the discussions that lead to the design of Multipath TCP. During several months in 2010, the MPTCP working group discussed about two solutions to transport data over different paths.
The first approach, that became later RFC 6824 only uses TCP options to encode all the control information. This solution was considered to be optimal to pass through various types of middleboxes. Recent experience with Multipath TCP implementations shows that Multipath TCP can indeed pass through most types of middleboxes.
The second approach, proposed by Michael Scharf in [MCTCP] , was to encode all the control information inside the payload of the TCP segments. For this, MC-TCP relies on a TLV-format to exchange both control and user data. Compared to the first approach, the advantage of MC-TCP was that it was possible to implement it as a library in user-space, but the MPTCP working group felt that this solution was too risky given the prevalence of middleboxes.
The control stream makes a minimal use of the TLV format to encode some control information. It remains to be seen whether there are interactions with some types of middleboxes that could lead to problems. DPIs are a likely source of problem for the control stream, but they already hae a problem today with Multipath TCP if they do not process all the data for a given Multipath TCP connection. Adding the control stream does not create an additional problem and one can expect that with the deployment of Multipath TCP on all iOS7 devices, middlebox vendors will start to add support for Multipath TCP on the DPI boxes…
Bibliography
| [CS] | (1, 2, 3) Christoph Paasch, O. Bonaventure, A generic control stream for Multipath TCP , February 2014, Internet draft, work in progress, https://datatracker.ietf.org/doc/draft-paasch-mptcp-control-stream/ |
| [MCTCP] | Michael Scharf, Multi-Connection TCP (MCTCP) Transport , Internet draft, July 2010, work in progress |
| [CellNet12] | Christoph Paasch, Gregory Detal, Fabien Duchene, Costin Raiciu, and Olivier Bonaventure. 2012. Exploring mobile/WiFi handover with multipath TCP . In Proceedings of the 2012 ACM SIGCOMM workshop on Cellular networks: operations, challenges, and future design (CellNet ‘12). ACM, New York, NY, USA, 31-36. http://doi.acm.org/10.1145/2342468.2342476 |