Slashdot Mirror
Multipath TCP Introduces Security Blind Spot
msm1267 (2804139) writes If multipath TCP is the next big thing to bring resilience and efficiency to networking, then there are some serious security issues to address before it goes mainstream. An expert at next week's Black Hat conference is expected to explain how the TCP extension leaves network security gear blind to traffic moving over multiple network streams. Today's IDS and IPS, for example, cannot correlate and re-assemble traffic as it's split over multiple paths. While such attacks are not entirely practical today, as multipath TCP becomes a fixture on popular networking gear and mobile devices, the risks will escalate. "[Multipath TCP] solves big problems we have today in an elegant fashion," said Catherine Pearce, security consultant and one of the presenters, along with Patrick Thomas. "You don't have to replace hardware or software; it handles all that stuff behind the scenes. But security tools are naïve [to MPTCP], and make assumptions that are no longer valid that were valid in the past."
Seriously, the second somebody proposed this it should have been (and surely was) clear what the authentication and security implications were. This doesn't mean multi-path is a bad thing, it just means it will likely be used in the appropriate places as opposed to 'everywhere in the tubes.'
Loading...
What you're saying is that Multipath-TCP will make deep packet inspection less useful? That's a win in my book. The net shouldn't be looking at packet contents anyway.
It's a design issue.
IDS and IPS can still intercept traffic taking muliple paths so long as those paths converge at the security device somewhere along the way.
i.e. traffic can be split across a WAN (MPLS / Internet IPSec paths for example) and be reassembled on the DMZ incoming to the destination site or hub site of a regional network.
blindly antisocialist = antisocial
Security is not meant to be, and now can't be a bolt-on feature without disrupting performance of the network. Nor is security what dictates the design of your protocols --- IP traffic is not meant to be intercepted, and more and more of it is becoming encrypted. Your IDS/IPS cannot look inside SSL traffic, either, which could contain exploit code (conveniently packed and encrypted by the SSL container).
You now need to move and have multiple IDS or IPS security agents on the end devices themselves; perhaps on the NIC, where you most certainly could have access to disparate MP-TCP sessions, with some software engineering.
I'm so sorry, it seems hard that you will now need to manage 1000 IPSes on all your endpoints which is less convenient than one centralized IPS, but the centralized IPS was always a hack and likely to be compromised or circumvented, for example, by tunneling, or leveraging a secondary WiFi network, as it's a ripe target.
In principle, the only sound thing to do is going to be to move your detectors.
Is this article suggesting that new communication paradigms are a bad idea because the security gear optimized for the old paradigm won't work? Should we wait for the security industry to invent multipath TCP? BTW, this is the same security gear that can already be thwarted by end-to-end encryption. How is this any different?
Async routing happens all the time and is already an issue. This shouldn't hold up the benefits that multipath tcp would give us. /sigh
Three duh's from the article:
They lost me at "Trust models users .... have fostered with Internet providers".... Duh.
Who cares? And if you really care enough, and you are a suveilance state, you can sniff from the soruce, or a common route in between in which all the data flows. Will you have to spend a little extra CPU and Memmory to piece together the full stream? yeah, duh.
And not very hard to fix for the firewall vendors. Will you have to patch your FW? Probably. Is that a problem? No, duh.
-Malakai
A Dragon Lives in my Garage
You seem to have missed the ability to open a connection in the reverse direction.
This is a game changer that breaks existing stream engines.
And it's stupid to assume they still are. An IP address is _not_ an identity, even in IPv6.
I am sick of IDS/firewall vendor corner cutting and laziness being wielded as an excuse to impede progress or otherwise nerf IP.
This is the same cast of characters who get caught naively mishandling IP layer fragmentation, option headers and hell even nested 802.1q.
Instead of owning up to it sit there like a bunch of two year olds and either complain their jobs are too hard or have the audacity to throw their weight at nerfing protocols themselves.
If people think multipath TCP is useful then they will deploy it and if IDS/firewall vendors don't step up with solutions they can step aside as their competitors win over their business.
What stops a BYOD from using multipath?
The 4G carrier's monthly cap.
Of course, this technology is just begging the Tor network to adopt it!
Hopefully this will lead to an increased emphasis on endpoint security, rather than the current "we have firewalls" attitude that's far too pervasive.
(For people who actually care about real security, that is. I've got no sympathy for those who just want to control/censor/monitor Internet traffic.)
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
So here we have security vendors trying YET AGAIN to hold back progress in Internet protocols. They did it with window scaling, ECN and IPv6. Each new invention doesn't work with their snake oil so they either disable it or tell people not to use it.
They like to lock down HTTP too, preventing anything that doesn't "look right." As if a server would respond to PUT or OPTION if it didn't intend to support that.
From TFA : Breaks Traffic Inspection
One good reason to use it !