Re: [multipathtcp] Hardening MPTCP against middlebox interference

[Arun Kumar <[e-mail]>]

Hello Sir,

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.
>

how without mptcp enabled system can send MP_CAPABLE option.
My question here, is it possible an mptcp enabed end system can connect
Internet server for example sourceForge server to download an file.
Here, my host only enabled with mptcp (have two interfaces), others not,
how can I achieve to use both my host interfaces simultaneously to download
data from sourceForge.
Is it possible ( middleboxes may not support mptcp).

Thanks and Regards,
SJK.


On Wed, Aug 27, 2014 at 1:56 PM, Olivier Bonaventure <
[e-mail]> wrote:

> 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
>
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>