Subject: [multipathtcp] Hardening MPTCP against middlebox interference

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Aug 2014 12:30:50 +0100

Folks,

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

I noticed a point in the recent presentation on MPTCP to black hat 
USA 2014{Note 1} that suggest a protocol tweak to make MPTCP more robust:

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.

However, this rule could prevent valid MPTCP endpoint from shutting 
down the whole connection, e.g. if two MPTCP endpoints can ever get 
into a state where one holds a different list of all established 
subflows from the other. I don't know enough about MPTCP to know if 
that is a valid concern.

BTW, There's also an interesting idea for a MPTCP capability scanner 
on slide 74 that claims to use less resources than opening a full 
MPTCP connection. 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. Surely the probability of 
choosing the same key in the SYN/ACK is so low that it can be assumed 
that this response is dumb reflection, not a sign of MPTCP-capability.

Cheers

Bob

{Note 1} See earlier posting re 
<https://www.blackhat.com/docs/us-14/materials/us-14-Pearce-Multipath-TCP-Breaking-Todays-Networks-With-Tomorrows-Protocols.pdf> 

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 26 Aug 2014 14:12:13 +0200

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.]
>
> I noticed a point in the recent presentation on MPTCP to black hat USA
> 2014{Note 1} that suggest a protocol tweak to make MPTCP more robust:
>
> 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:
> However, this rule could prevent valid MPTCP endpoint from shutting down
> the whole connection, e.g. if two MPTCP endpoints can ever get into a
> state where one holds a different list of all established subflows from
> the other. I don't know enough about MPTCP to know if that is a valid
> concern.

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.

>
> BTW, There's also an interesting idea for a MPTCP capability scanner on
> slide 74 that claims to use less resources than opening a full MPTCP
> connection.

The scanner is implemented in scapy and relies on transmitting a single 
packet to the server. This is like nmap that uses less state than a 
regular TCP stack.

> 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.Surely the probability of choosing the same key
> in the SYN/ACK is so low that it can be assumed that this response is
> dumb reflection, not a sign of MPTCP-capability.

Last time we checked, this was the kind of answer that we received from 
Baidu.com and other sites in China. We had to modify the MPTCP 
implementation in the Linux kernel to enable Chinese users to access 
baidu.com with an MPTCP-enabled client

Olivier

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

---

From: Kate Pearce <[email-masked]>
Date: Tue, 26 Aug 2014 08:25:16 -0400

Correct. Looking for keys is probably a better solution in most cases, as we have had pointed out to us. 

Our method will also allow you to detect subtly different things such as if a middle box is option stripping no capable but not mp join. 

Catherine Pearce

> On Aug 26, 2014, at 7:30 AM, Bob Briscoe <[email-masked]> wrote:
> 
> Folks,
> 
> [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.]
> 
> I noticed a point in the recent presentation on MPTCP to black hat USA 2014{Note 1} that suggest a protocol tweak to make MPTCP more robust:
> 
> 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:
> However, this rule could prevent valid MPTCP endpoint from shutting down the whole connection, e.g. if two MPTCP endpoints can ever get into a state where one holds a different list of all established subflows from the other. I don't know enough about MPTCP to know if that is a valid concern.
> 
> 
> BTW, There's also an interesting idea for a MPTCP capability scanner on slide 74 that claims to use less resources than opening a full MPTCP connection. 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. Surely the probability of choosing the same key in the SYN/ACK is so low that it can be assumed that this response is dumb reflection, not a sign of MPTCP-capability.
> 
> 
> Cheers
> 
> 
> Bob
> 
> {Note 1} See earlier posting re <https://www.blackhat.com/docs/us-14/materials/us-14-Pearce-Multipath-TCP-Breaking-Todays-Networks-With-Tomorrows-Protocols.pdf> 
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Aug 2014 14:56:04 +0100

Olivier,

At 13:12 26/08/2014, Olivier Bonaventure wrote:
>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

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

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.

>The scanner is implemented in scapy and relies on transmitting a 
>single packet to the server. This is like nmap that uses less state 
>than a regular TCP stack.
>
>Last time we checked, this was the kind of answer that we received 
>from Baidu.com and other sites in China. We had to modify the MPTCP 

Sorry, I'm not sure what you're saying. Can you be more precise? I'm 
not clear what you mean by 'this'? And I'm not clear what changes you 
made? And I'm not clear how this relates to my question about 
checking if the key is different in the response?

Bob

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 Aug 2014 10:26:20 +0200

Bob,
>> connection, then we'll have to deal with all the cases where a RST is
>> lost on one of the subflows.
>>

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

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

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

---

From: Arun Kumar <[email-masked]>
Date: Wed, 27 Aug 2014 14:44:21 +0530

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 <
[email-masked]> wrote:

> 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 ?
> containing fastclose, we also allow on-path meddleboxes to terminate such a
> connection. This is what today's TCP middleboxes are already capable of.
>
>
>
> 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
>
>
>
>
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 27 Aug 2014 14:55:15 +0100

Olivier,

I've split the two separate questions into separate threads. This 
one's about MP_CAPABLE. See inline...

At 09:26 27/08/2014, Olivier Bonaventure wrote:
>>>>an MPTCP-capable host. Surely the probability of choosing the 
>>>>same key in the SYN/ACK is so low that it can be assumed that 
>>>>this response is dumb reflection, not a sign of MPTCP-capability.
>
>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.

I understood all this. But you deleted the last sentence of my 
question, which was the actual question (I've re-instated it above)

The MP_CAPABLE option includes a key. So, if a server really is 
MP_CAPABLE the key it returns in the MP_CAPABLE option will be 
different from the one the client sent. This is surely an obvious way 
to detect a real MP_CAPABLE server, because the key in a reflected 
MP_CAPABLE option would be identical to the client's.

What am I missing?

Bob

PS. I'll leave someone else to answer Arun's question.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 27 Aug 2014 16:19:32 +0100

Olivier,

At 09:26 27/08/2014, Olivier Bonaventure wrote:
>This part is related to the DSS checksum failure that would trigger 
>a fallback to regular TCP.

Yup, that's clear.

>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.
>
>- a RST sent over one of the subflow may be lost, how long should 
>the host that received the fastclose wait for all RSTs ?

As long as it chooses. When you pointed out that RST loss would be a 
problem, that's why I said waiting is optional (whether it waits, and 
how long it waits).

Also, remember that, if TCP X sends a RST then it continues to see 
packets from TCP Y as if it hadn't seen the RST, TCP X will 
automatically re-send RSTs until TCP Y stops talking.

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

That was my question. Can this really happen? The TCP state machine 
should prevent such an error, shouldn't it? If not, how exactly can 
this happen?

>such a connection. This is what today's TCP middleboxes are already capable of.

I am arguing that this is one feature of TCP that MPTCP should not 
mandate. An MPTCP endpoint should be able to choose:
- yes I allow a middlebox to shut down all my connections (current RFC6824)
- no, I can prevent a middlebox from shutting down connections that 
it can't see (solution TBA, e.g. my proposal).

Reason: MPTCP needs to worry about self-preservation. TCP didn't have to.

Bob

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 Aug 2014 18:04:52 +0200

Bob,

>> 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.
>
> I understood all this. But you deleted the last sentence of my question,
> which was the actual question (I've re-instated it above)
>
> MP_CAPABLE the key it returns in the MP_CAPABLE option will be different
> from the one the client sent. This is surely an obvious way to detect a
> real MP_CAPABLE server, because the key in a reflected MP_CAPABLE option
> would be identical to the client's.

Agreed, but I wanted to point out that afaik this is the first time that 
we have to do this with a TCP extension. In the past, the reception of 
option X in the SYN/ACK was sufficient to indicate that the server 
understood option X. This is not true anymore :-(

Olivier

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 27 Aug 2014 18:14:44 +0100

Olivier,

Thanks and understood.

Bob

At 17:04 27/08/2014, Olivier Bonaventure wrote:
>Agreed, but I wanted to point out that afaik this is the first time 
>that we have to do this with a TCP extension. In the past, the 
>reception of option X in the SYN/ACK was sufficient to indicate that 
>the server understood option X. This is not true anymore :-(
>
>
>Olivier
>
>
>
>--