Secure MultiPath TCP : design and implementation

Details

Supervisors

Pereira, Olivier ; Bonaventure, Olivier

Faculty

Ecole polytechnique de Louvain

Degree label

Master [120] : ingénieur civil en informatique

Abstract

MultiPath TCP (MPTCP) is a recent transport protocol that was developed to take advantage of the multiple paths in the network that often exist between peers, and to use efficiently all the interfaces (e.g., Wifi and Ethernet). A MPTCP connection is composed of multiple TCP (Transmission Control Protocol) connections, called subflows. Compared to TCP that is restricted to a single path per connection, MPTCP improves the resource use in the network, the throughput and the resilience to network failure. It also enables to be more resilient against DoS attacks since MPTCP can easily close a subflow (i.e., a path) and re-establish another one. MPTCP is thus stronger than TCP against many Denial of Service (DoS) attacks. But despite growing adoption of MPTCP, it remains mostly unauthenticated and unencrypted. This is due to the fact that there is no encryption scheme integrated in MPTCP. There is only TLS that can be used above MPTCP in the same way than above TCP. And there is even less a mechanism to easily negotiate them. This is therefore a good opportunity to directly design a standard to negotiate these encryption schemes instead of letting people going their own way. This document thus defines a mechanism that enables easier negotiation of encryption schemes over MPTCP: MPTCP Encryption Scheme Negotiation (MPTCPesn). Designed to be modular and easy to update, it offers a good basis for the development of cryptographic protocols for MPTCP. Indeed, adding new encryption schemes that can be negotiated with MPTCPesn can be done quite easily. But the encryption schemes themselves were still missing. Therefore, in this document, we have also designed MPTCPsec, the first cryptographic protocol specially designed for MPTCP (and even integrated in it), negotiable with MPTCPesn. It enables two hosts to exchange data by means of a secure MPTCP connection. MPTCPsec is application independent, fast and it takes advantage of the MPTCP's properties (e.g., having several subflows). MPTCPsec provides the same security properties than TLS, except the identity authentication (achieved by certificates). But it is resistant to many more DoS attacks than TLS. MPTCPsec brings three main improvements, compared to simply running TLS above MPTCP. Firstly, the whole connection does not need to be closed when an attack is detected on a subflow (i.e., authentication failure). Only this subflow is closed, and another one can be opened to replace it. It is a great improvement since an attacker can no more close the whole connection by modifying only one byte of any segment in any subflow, as he could do against TLS. Furthermore, and this is the second improvement, an attacker is unable to interfere with a subflow without being on the path used by this subflow, even if he controls other subflows. He can neither prevent the establishment of subflows he does not control. This is due to the authentication of the MPTCP options. In fact, the most he can do is to close the subflows he is on, or to drop some or all the segments of these subflows (but they will be re-injected on other subflows). The third improvement is that segments can be decrypted as soon as they are received, even if a segment with lower DSN is not already received (i.e., segments out-of-sequence can be decrypted). Once the design has been finished, we have implemented the main parts of our protocol, directly in the Linux kernel, in order to properly incorporate it in the MPTCP implementation. First of all to prove to ourselves that our design makes sense and then to be able to compare our solution with TLS above MPTCP with some performance tests. Both objectives are fulfilled and the results are very satisfying. Especially as our implementation is not fully optimized, contrary to TLS implementation (OpenSSL) that has been optimized and improved for several years now. Our most important achievements are that MPTCPsec is a little faster in term of data processing and that the data flow continues even if an attacker is on one subflow and tries to modify segments (while TLS connection is closed). The results also show that even if MPTCPsec has a little smaller throughput than TLS (and we explain this difference), it remains very competitive.