[multipathtcp] Comments on draft-bagnulo-mptcp-privacy-00

[Olivier Bonaventure <[e-mail]>]

Marcelo, Amelia, Christoph,

Thanks for having initiated the above draft. As I will not be able to 
participate to the discussion in Montreal, here are some suggestions and 
comments.

Generic comments

First, I think that it would be useful to compare the privacy features 
of QUIC (or a forthcoming Multipath QUIC) with those of MPTCP. 
Obvisouly, given that MPTCP does not encrypt anything, it suffers from 
more types of privacy attacks than QUIC.

Second, beyond looking at the issues with the current version of MPTCP, 
we could consider whether an hypothetical MPTCP version x could solve 
some of these issues. In the draft, you mention the possibility of 
encrypting some of the MPTCP options. If this is done with the keys 
exchanged in clear during the handshake, it would probably not help. 
However, since a privacy sensitive application would anyway use TLS, why 
not consider a solution like

https://datatracker.ietf.org/doc/html/draft-paasch-mptcp-ssl

that basically extracts the MPTCP keys from the TLS exchange. The above 
draft has experied, but could probably be updated to support TLS 1.3 and 
the latest version of MPTCP.

If we had this extension inside MPTCP, which options would need to be 
encrypted/authenticated :

- MP_CAPABLE(no)	
- MP_JOIN (maybe)
- DSS (but TCP sequence number would not be encyrpted)
- ADD_ADDR
- REMOVE_ADDR	
- MP_PRIO	
- MP_FAIL	
- MP_FASTCLOSE

Another possible design point is MPTCPSec, see 
https://inl.info.ucl.ac.be/publications/secure-multipath-tcp-design-impementation.html

A third design point would be to explore the integration of TCPINC and 
MPTCP, if this is possible.


Detailed comments

I think that it would be useful to provide a discussion on privacy 
considerations in the configuration of MPTCP and when add_addr and 
mp_join should be sent. A client that always sends add_addr and creates 
a full mesh of subflows is more vulnerable from this viewpoint than a 
client that does not send add_addr and only sends mp_join when the 
primary path fails. Of course, this increases the reaction time in case 
of failures.

Changing the token in mp_join is something that looks interesting. We 
could imagine a server that provides to its client the next token to be 
used (possibly encrypted). This allows the server to control the 
numberof subflows that a client can establish, and also improves 
privacy. I would encourage you to explore this direction and also 
consider the implementation cost on servers.

Considering the benefits of spreading data over multiple paths, there 
are benefits from the viewpoint of countering an attacker willing to 
capture the entire bytestream. On the other hand, an attacker who wishes 
to simply collect metadata about who talks with who would get more data 
from mptcp than from regular tcp...

Overal, I think that there are many tradeoffs between privacy, reaction 
to failures, protocol/implementation complexity that would be worth to 
discuss in the draft.


Best regards,



Olivier