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?
With a 40Gb stream, there is about 5MB of data per millisecond. You're going to need some large network buffers to handle out of order packets.
The biggest issue is you went from firewalls that didn't need to know about each other's state to not only sharing state, but every packet. Essentially you went from a lock-free design to a giant lock.
I assume this would be way too much load for the firewalls, so you'd be better off mirroring all edge traffic to a central server to demultiplex the streams. Imagine you're a company with several 100gb connections, with a total of 1tb of bandwidth, and you have a central server that needs to somehow handle 1tb of mirrored packets getting forwarded to it. That'll be interesting.