Re: [multipathtcp] Hardening MPTCP against middlebox interference

[Olivier Bonaventure <[e-mail]>]

Bob,
>>>
>>> [I don't generally follow the multipathtcp list at the mo, so pls ensure
>>> you cc me if you want me to read any responses. And apologies if I'm
>>> covering old ground - I did check, but only a cursory check.]
>>>
>>> It needs to be harder for a meddlebox that has intercepted the key but
>>> is not on-path for all subflows to shut down MPTCP on all the other
>>> subflows.
>>>
>>> RFC6824 CURRENT:
>>>     o  Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B
>>>        answers on the same subflow with a TCP RST and tears down all
>>>        subflows.
>>> SUGGESTED:
>>>     o  Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B
>>>        waits for a RST on every other established sub-flow. Once they
>>> are
>>>        all received, it responds to the MP_FASTCLOSE on the same subflow
>>>        with a TCP RST and tears down all subflows.
>>
>> The motivation for MP_FASTCLOSE is to be able to quickly close an
>> MPTCP session at the and of a transfer to enable a server to free
>> state. If we need to wait for RST on all subflows to terminate the
>> connection, then we'll have to deal with all the cases where a RST is
>> lost on one of the subflows.
>>
>> The key problem from a security viewpoint is that the meddlebox is
>> able to see the keys. If we could adopt something similar to
>> http://tools.ietf.org/html/draft-paasch-mptcp-ssl-00
>> then we can hide the keys to the meddlebox and prevent this problem.
>
> Understood. But one of the stated goals in RFC6824 is to allow
> meddleboxes to adjust the payload.
>
> "
>     It should be emphasized that we are not attempting to prevent the use
>     of middleboxes that want to adjust the payload.  An MPTCP-aware
>     middlebox could provide such functionality by also rewriting
>     checksums.
> "

This part is related to the DSS checksum failure that would trigger a 
fallback to regular TCP.


> I think it's a good idea for a base MPTCP to exist that allows
> meddleboxes to meddle, as long as there's a separate way for the ends to
> add full e2e integrity protection (e.g. Christophe's mptcp-ssl approach)
> if they want it.
>
> Would my proposed change be more acceptable if it was optional? Ie.
> MP_FASTCLOSE doesn't require an endpoint to shut down the whole MPTCP
> connection until it gets all the RSTs as well, but the endpoint can shut
> the connection down without waiting for all the RSTs if it needs to.

An endpoint can already terminate a connection at any time if it fails 
out of resources or reboots. I would not put it as a specific option.

My concern with your solution is that there are corner cases that we 
need to consider :
- a RST sent over one of the subflow may be lost, how long should the 
host that received the fastclose wait for all RSTs ?
- the two communicating hosts may not have the same vision of the number 
of established subflows (host A might think that there are currently two 
subflows while host B considers that there are three subflows in the 
established state)

By allowing to terminate an MPTCP connection with a single packet 
containing fastclose, we also allow on-path meddleboxes to terminate 
such a connection. This is what today's TCP middleboxes are already 
capable of.

>>
>>> However, I don't quite see how a listening host that
>>> reflects back the same MPTCP options in the SYN/ACK can be mistaken for
>>> an MPTCP-capable host.

This is the default operation for most TCP stacks. If you sent the 
timestamp option in a SYN and receive it in a SYN/ACK, you expect that 
the server supports the timestamp option.

With MPTCP, we learned that this is not sufficient. If you try to open 
an MPTCP connection to www.baidu.com on port 80 today, it replies by 
echoing the MP_CAPABLE option that you've sent. If you assume that MPTCP 
can be used to interact with this host, you are wrong, it does not 
support Multipath TCP.


Olivier




INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be