December 08, 2018

The evolution of the MP_CAPABLE option

A TCP connection always starts with a three-way handshake. The client sends a SYN packet that contains the TCP options that it wants to negotiate with the server. The server replies with the TCP options that it supports. Like most TCP extensions (the only known exception is the support for Explicit Congestion Notification defined in RFC 3168 that uses bits of the TCP header for its negotiation), Multipath TCP defines the MP_CAPABLE option that needs to be used in the SYN.

This option first appeared in draft-ford-mptcp-multiaddressed-00. Its evolution since 2009 reflects the evolution of the protocol and some of the lessons learned during its design and based on experiments.

This firs draft proposed the following format for this MP_CAPABLE option.

This initial format contains several interesting fields. Like most TCP options, the MP_CAPABLE option is encoded using a type length value format. draft-ford-mptcp-multiaddressed-00 decided to use a different option type for different Multipath TCP options. At that time, this was considered to be a normal practice. The Selective Acknowledgement option RFC 2018 also defined two TCP options: one to negotiate its utilization in the SYN packet and one to carry the selective acknowledgements. Besides the Kind and Length field, this first MP_CAPABLE option contained a Version number (the protocol designers already anticipated the possibility of having different versions of Multipath TCP) and a 32 bits Sender Token.

TCP uses IP addresses and port numbers to identify connections. Each packet belonging to a connection carries the source and destination addresses and ports that uniquely identify it. Multipath TCP cannot rely on this to identify connections since each Multipath TCP connection is composed of a set of TCP connections, called subflows, which can vary over time. As indicated in RFC 6182, Multipath TCP uses unique identifiers that are called tokens to identify connections. Each host generates a token that identifies each connection locally. The MP_CAPABLE option carries the token chosen by the client in the SYN and the token chosen by the server in the SYN+ACK.

The first change to this important option appeared in draft-ford-mptcp-multiaddressed-03.txt which was published in March 2010.

When a TCP connection starts, the client selects its initial sequence number and places it inside the SYN. The server does the same with its SYN+ACK. In addition to the TCP sequence numbers that are included in the TCP header, Multipath TCP uses Data Sequence Numbers (DSN) that are placed in the DSN option. These DSNs are used to number the data that is sent over the different TCP subflows. The first drafts assumed that the DSN would start at 0 in both directions when a Multipath TCP connection is created. However, this choice raised security concerns since an attacker could easily predict the content of the DSN option that he should use to inject data inside a Multipath TCP connection. The normal way to solve such a problem is to use a random value for the initial DSN in each direction. The second version of the MP_CAPABLE option carries this value.

This draft was adopted by the working group as draft-ietf-mptcp-multiaddressed-00. The MP_CAPABLE option was modified again in draft-ietf-mptcp-multiaddressed-02. The new format is shown below.

The new format still contains a version number but it adds two keys. The client sends an MP_CAPABLE option that contains the sender key in the SYN, while the server replies with a SYN+ACK that contains an MP_CAPABLE option with both the Sender and the Receiver keys. These keys were introduced to improve the security of the addition of new subflows with the MP_JOIN option. The client and the server exchange their keys during the three-way handshake and later used them to prove their ownership of the connection when they add a new subflow. A simple solution to carry these keys would have been to extend the MP_CAPABLE option that was shown earlier. Unfortunately, it would have become difficult to open a Multipath TCP connection given the limited length of the TCP extended header.

These two keys help to authenticate the establishment of subflows, but we saw earlier that Multipath TCP hosts need to exchange tokens and agree on initial sequence numbers and that this information was included in the MP_CAPABLE option. With the new format, we had to find a way to compute these tokens and initial data sequence numbers from the keys. draft-ietf-mptcp-multiaddressed-02 computes them with a hash function and uses the high (resp. low) order bits of this hash as the token (resp. initial data sequence number).

Thanks to these hashes, we could reduce the length of the MP_CAPABLE option. However, this created a small risk of collision. When a host generates a random 64 bits key, it must verify that the hash of this key does collide with the token of an existing Multipath TCP connection. The figure below, extracted from [RPB+12], shows that the performance impact of this verification is not too high.

Two modifications appeared in draft-ietf-mptcp-multiaddressed-03. The first one is that this document requests a single TCP Option Kind for all Multipath TCP options. This was mainly because we feared that a middlebox could drop one type of Multipath TCP option and not the other. Dealing with such corner cases would have made the protocol much more complex. We hoped that if a middlebox decided to drop unknown TCP options, it would do so based on their TCP Option Kind. Such a middlebox would thus either remove the MP_CAPABLE option from the SYN packet or discard such a SYN packet. Multipath TCP clients already coped with the latter by removing the MP_CAPABLE option after 3 unsuccessful attempts to transmit a SYN that carries this option.

The second modification introduced in draft-ietf-mptcp-multiaddressed-03 is the definition of two flags : S and C. S was intended to negotiate the hash function used to compute the tokens and the initial sequence numbers from the keys. C allows to negotiate the utilization of the DSN checksum that will be explained in a subsequent blog post.

The format of this option changed again in draft-ietf-mptcp-multiaddressed-10 to clarify the different flags.

Besides the changes to the format of the MP_CAPABLE option, there were also changes to the processing of this option. As middleboxes such as firewalls could block SYN that contain an unknown option, the Multipath TCP draft, draft-ford-mptcp-multiaddressed-00 already suggested that a client should only set the MP_CAPABLE options in the first few transmissions of a SYN and fallback to TCP if it does not receive any SYN+ACK in response. This is illustrated in the figure below.

Another issue with Multipath TCP is that exchanging keys in the SYN and SYN+ACK forces the server to maintain state for each connection attempt upon reception of the client SYN. This could lead to denial of service attacks that have affected TCP implementations in the past RFC 4987. Since draft-ietf-mptcp-multiaddressed-02, Multipath TCP copes with this problem by allowing the server to be stateless. For this, the client needs to retransmit its key and the server key inside an MP_CAPABLE option that is carried in the third ACK.

The presence of the MP_CAPABLE option in the third packet also confirms the utilization of Multipath TCP to the server.

At this point, RFC 6824 was published in January 2013. In September 2013, Apple deployed Multipath TCP on all iPhones to support the Siri application. This deployment will be discussed in a specific blog post.

Based on the feedback received from implementors and given the successful deployments, the MPTCP working group started in late 2013 to work on a revision of RFC 6824 : draft-ietf-mptcp-rfc6824bis-00. A first change was proposed in draft-ietf-mptcp-rfc6824bis-05. This was an attempt to reduce the length of the options in the SYN packet.

The client sends a small MP_CAPABLE option that only contains the first four bytes. The server replies with its key and then the client echoes the client and server keys in the third ACK. The MP_CAPABLE option is also placed in the first packet that carries data. This choice was motivated by the fact that the third ACK is not transmitted reliably. If this packet does not reach the server, then it will not be aware of the client key. By placing the MP_CAPABLE option inside a packet that carries data, we ensure that it will eventually reach the server.

Another important modification appeared in draft-ietf-mptcp-rfc6824bis-07. Although this modification only specifies the value of one bit in the MP_CAPABLE option, it is important to efficiently support load-balancers. This has been described in details in [DB17].

References

[DB17]

Fabien Duchene and Olivier Bonaventure. Making multipath tcp friendlier to load balancers and anycast. In Network Protocols (ICNP), 2017 IEEE 25th International Conference on, 1–10. IEEE, 2017. URL: https://inl.info.ucl.ac.be/publications/making-multipath-tcp-friendlier-load-balancers-and-anycast.html.

[RPB+12]

C. Raiciu, C. Paasch, S. Barre, A. Ford, M. Honda, F. Duchene, O. Bonaventure, and M. Handley. How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP. In Proceedings of the 9th Symposium on Networked Systems Design and Implementation (NSDI). 2012. URL: https://inl.info.ucl.ac.be/publications/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp.html.

Posted by Olivier Bonaventure

Filed under: advent calendar

Tags: MPCAPABLE

• « Why is the Multipath TCP scheduler so important ?
• Multipath TCP encounters its first middlebox »

Recent Posts

• Native Multipath TCP support for OpenSSH
• Apple Music on iOS13 uses Multipath TCP through load-balancers
• SOCKS and Multipath TCP
• Using load balancers in front of Multipath TCP servers
• Which servers use Multipath TCP ?
• Advertising addresses with Multipath TCP
• Multipath TCP APIs
• Evolution of the documents produced by the MPTCP working group
• Apple uses Multipath TCP
• Can Multipath TCP cope with middleboxes ?

Search

Categories

• advent calendar (20)
• apple (1)
• apps (1)
• architecture (1)
• coding (1)
• datacenter (2)
• ietf (1)
• ios (2)
• load-balancing (1)
• measurements (11)
• middleboxes (3)
• MPTCP (1)
• mptcp (1)
• news (1)
• packet trace (1)
• protocol (3)
• security (1)
• smartphones (1)
• software (2)
• tracebox (1)
• use case (1)
• use cases (1)
• wireless (1)

Tags Cloud

add_addr   Android   API   apple   cellular   configuration   congestion   congestion control   connected car   datacenter   experiment   fountain codes   ios   load balancing   measurement   measurements   mesh   middlebox   middleboxes   MPCAPABLE   MPTCP   ns-3   packet trace   performance   protocol   scapy   scheduler   simulations   Siri   smartphone   socket   socks   software   ssh   tools   tutorial   wifi   wireless   wireshark