Subject: [multipathtcp] Multipath TCP: Breaking Today's Networks with Tomorrow's Protocols

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

1) On 6 Aug, there was an excellent briefing on MPTCP at black hat USA 2014:

"Multipath TCP: Breaking Today's Networks with Tomorrow's Protocols"
by Catherine Pearce + Patrick Thomas
<https://www.blackhat.com/docs/us-14/materials/us-14-Pearce-Multipath-TCP-Breaking-Todays-Networks-With-Tomorrows-Protocols.pdf>

There's lots of interesting stuff within, and an insight into the 
mindset of those who design network security boxes.

2) Shamus McGillicuddy interpreted the message as follows for SearchNetworking:

"MPTCP offers performance and resiliency but security is nonexistent"
<http://go.techtarget.com/r/32751251/16552648/1>

The heading of the article is unfortunate. It implies that it's MPTCP 
that is not secure, as if security middleboxes are only expected to 
detect attacks that comply with protocol rules known at the time the 
box was written. This is a particularly sad reflection on the state 
of network security. It's even sadder that a new protocol gets blamed 
for non-existent security, when in fact the protocol designers have 
done everything possible to enable security middleboxes to work with 
it. Middlebox designers seem to have been sitting on their hands.

3) Also notice that the knee-jerk security response is to propose 
that security middleboxes cross-correlate sub-flows between each 
other. There's no consideration of the problem here; the box 
protecting my wifi network has to correlate with all boxes protecting 
all cellular networks that I might use, and with all cable networks, 
and all DSL networks, and all fibre networks, and... This is not just 
an n-squared problem; it's n^m, where n is the number of MPTCP 
endpoints and m is the number of sub-flows on each that might use 
different networks.

The idea that MPTCP will drive a shift towards better security within 
the endpoints doesn't seem to have occurred to these people yet. They 
have lost sight of the purpose of what they are doing; providing 
security to end-users. They haven't yet realised that the 
business-model they are assuming isn't the only one. Selling boxes to 
network operators is convenient but not enough; it has to be combined 
with better endpoint security. On its own, the middlebox model is not 
secure - the limited choice of business model is actually the 
security flaw here.

4) It seems that it would be worth opening more channels with the 
security middlebox community to ensure they address these problems 
properly. Otherwise they will resort to the lazy option of blocking 
MPTCP. Perhaps this is already in hand?

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

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

Hi,

I'm the researcher that presented at blackhat. We've also been concerned too about mindless panic, and tried to guard against it where we can. Nevertheless journalists will do their thing. 

I've actually tried to start opening communications to various middle box groups, but they aren't very receptive right now. The presentation was intended to shake them up a little. If they didn't start adapting now then the option stripping would have come with abandon once the protocol has wide uptake. 

Not really in a position to give a detailed email right now, but I'm keen to open a dialogue and help where I can. The technology is great and solved real problems, but it breaks network "security" as it is & was done. The network was intended to transfer packets, not controlling or looking at data as is do often done. 

Absolutely keen to talk in more detail, please let me know if you've any specific questions about what we released, I've got a good amount unreleased too...

Catherine (Kate) pearce

> On Aug 26, 2014, at 7:35 AM, Bob Briscoe <[email-masked]> wrote:
> 
> 
> < https://www.blackhat.com/docs/us-14/materials/us-14-Pearce- Multipath-TCP -Breaking-Todays-Networks-With-Tomorrows-Protocols.pdf>
> 
> There's lots of interesting stuff within, and an insight into the mindset of those who design network security boxes. 
> 
> 
> < http://go.techtarget.com/r/32751251/16552648/1>
> 
> The heading of the article is unfortunate. It implies that it's MPTCP that is not secure, as if security middleboxes are only expected to detect attacks that comply with protocol rules known at the time the box was written. This is a particularly sad reflection on the state of network security. It's even sadder that a new protocol gets blamed for non-existent security, when in fact the protocol designers have done everything possible to enable security middleboxes to work with it. Middlebox designers seem to have been sitting on their hands.
> 
> 3) Also notice that the knee-jerk security response is to propose that security middleboxes cross-correlate sub-flows between each other. There's no consideration of the problem here; the box protecting my wifi network has to correlate with all boxes protecting all cellular networks that I might use, and with all cable networks, and all DSL networks, and all fibre networks, and... This is not just an n-squared problem; it's n^m, where n is the number of MPTCP endpoints and m is the number of sub-flows on each that might use different networks.
> 
> The idea that MPTCP will drive a shift towards better security within the endpoints doesn't seem to have occurred to these people yet. They have lost sight of the purpose of what they are doing; providing security to end-users. They haven't yet realised that the business-model they are assuming isn't the only one. Selling boxes to network operators is convenient but not enough; it has to be combined with better endpoint security. On its own, the middlebox model is not secure - the limited choice of business model is actually the security flaw here. 
> 
> 4) It seems that it would be worth opening more channels with the security middlebox community to ensure they address these problems properly. Otherwise they will resort to the lazy option of blocking MPTCP. Perhaps this is already in hand?
> 
> 
> Bob
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Aug 2014 15:02:45 +0100

Kate,

Thx for the excellent research. I'm keen to help ensure the security 
community copes with MPTCP properly (ie combining endpoint with 
network-based as I suggested, and certainly not just lazily blocking 
all MPTCP).

But I'll let others take the lead and only step in if I have to, 'cos 
I'm trying to focus on other stuff at the mo.

Thx again.

Bob

PS. MPTCP also challenges the assumptions that the in-network load 
balancing community and the DPI community hold, so similar comments apply.

At 13:22 26/08/2014, Kate Pearce wrote:
>Hi,
>
>I'm the researcher that presented at blackhat. We've also been 
>concerned too about mindless panic, and tried to guard against it 
>where we can. Nevertheless journalists will do their thing.
>
>I've actually tried to start opening communications to various 
>middle box groups, but they aren't very receptive right now. The 
>presentation was intended to shake them up a little. If they didn't 
>start adapting now then the option stripping would have come with 
>abandon once the protocol has wide uptake.
>
>Not really in a position to give a detailed email right now, but I'm 
>keen to open a dialogue and help where I can. The technology is 
>great and solved real problems, but it breaks network "security" as 
>it is & was done. The network was intended to transfer packets, not 
>controlling or looking at data as is do often done.
>
>Absolutely keen to talk in more detail, please let me know if you've 
>any specific questions about what we released, I've got a good 
>amount unreleased too...
>
>Catherine (Kate) pearce
>
>On Aug 26, 2014, at 7:35 AM, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>>
>>< https://www.blackhat.com/docs/us-14/materials/us-14-Pearce- 
>>Multipath-TCP -Breaking-Todays-Networks-With-Tomorrows-Protocols.pdf>
>>
>>The heading of the article is unfortunate. It implies that it's 
>>MPTCP that is not secure, as if security middleboxes are only 
>>expected to detect attacks that comply with protocol rules known at 
>>the time the box was written. This is a particularly sad reflection 
>>on the state of network security. It's even sadder that a new 
>>protocol gets blamed for non-existent security, when in fact the 
>>protocol designers have done everything possible to enable security 
>>middleboxes to work with it. Middlebox designers seem to have been 
>>sitting on their hands.
>>
>>protecting my wifi network has to correlate with all boxes 
>>protecting all cellular networks that I might use, and with all 
>>cable networks, and all DSL networks, and all fibre networks, 
>>and... This is not just an n-squared problem; it's n^m, where n is 
>>the number of MPTCP endpoints and m is the number of sub-flows on 
>>each that might use different networks.
>>
>>The idea that MPTCP will drive a shift towards better security 
>>within the endpoints doesn't seem to have occurred to these people 
>>yet. They have lost sight of the purpose of what they are doing; 
>>providing security to end-users. They haven't yet realised that the 
>>business-model they are assuming isn't the only one. Selling boxes 
>>to network operators is convenient but not enough; it has to be 
>>combined with better endpoint security. On its own, the middlebox 
>>model is not secure - the limited choice of business model is 
>>actually the security flaw here.
>>
>><mailto:[email-masked]>[email-masked]

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 Aug 2014 09:03:47 +0200

Kate,

> I'm the researcher that presented at blackhat. We've also been concerned
> too about mindless panic, and tried to guard against it where we can.
> Nevertheless journalists will do their thing.
>
> I've actually tried to start opening communications to various middle
> box groups, but they aren't very receptive right now. The presentation
> was intended to shake them up a little. If they didn't start adapting
> now then the option stripping would have come with abandon once the
> protocol has wide uptake.
>
> keen to open a dialogue and help where I can. The technology is great
> and solved real problems, but it breaks network "security" as it is &
> was done. The network was intended to transfer packets, not controlling
> or looking at data as is do often done.

We analyzing the interactions between middleboxes and MPTCP, there are 
two different situations that are worth being discussed. Let us consider 
a middlebox like a firewall that needs to see the entire traffic from 
the users that it "controls"

Scenario 1 : multihomed client

client --- net1 ---- mbox --- internet --- server
   +                              +
   +----------------- net2 -------+

With regular TCP, a TCP connection can either see the network as

client --- net1 ---- mbox --- internet --- server

or as

client                        internet --- server
   +                              +
   +----------------- net2 -------+

This second scenario is worrying for the middlebox operator because it 
does not see anything about the traffic from the client. Note that this 
issue arises simply because there are two interfaces on the client 
device. A typical example is a smartphone connected to an entreprise 
WiFi network and a public 3G/4G provider. Note that an entreprise that 
deploys IPv6 and IPv4 might quickly end up in this scenario where a 
middlebox does not see the IPv4 and IPv6 packets produced by a given host.

If the middlebox operator needs to "control" all the traffic to/from his 
clients, there it needs to block access to net2 or force them to pass 
through a VPN/proxy/... so that all subflows pass through the middlebox. 
Which brings us to the second scenario.

Scenario 2 : single homed client, MPTCP subflows on same interface

client --- net ---- mbox --- internet --- server

The middlebox can see all the packets exchanged by the client and the 
server. In full generality, to perform DPI with Multipath TCP, the 
middlebox would need to reassemble the stream, take into account the 
retransmissions, ... In an entreprise network, it is also possible to 
have a more active middlebox that would for example :
- refuse the addition of TCP subflows so that MPTCP only uses one 
subflow at a time
- limit the number of subflows to one per IP address assigned to the 
client/server
- verify the MP_JOIN options
- perform traffic normalisation
- ...

> Absolutely keen to talk in more detail, please let me know if you've any
> specific questions about what we released, I've got a good amount
> unreleased too...

It would be nice if you could contribute to the wg draft on operational 
experience

Olivier

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