Forgot your password?
typodupeerror
Networking Security

Multipath TCP Introduces Security Blind Spot 60

Posted by Unknown Lamer
from the thwart-spies-and-your-friendly-sysadmin dept.
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."
This discussion has been archived. No new comments can be posted.

Multipath TCP Introduces Security Blind Spot

Comments Filter:
  • by Assmasher (456699) on Friday August 01, 2014 @08:29AM (#47580797) Journal

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

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Seriously, the second somebody proposed this it should have been (and surely was) clear what the authentication and security implications were.

      It's not like multi-homed protocols based on IP are new. SCTP [ietf.org] has been around about a decade (half a decade as a real Internet standard).

      • It's not like multi-homed protocols based on IP are new. SCTP has been around about a decade (half a decade as a real Internet standard).

        SCTP does not do what a lot of people think it does. Additional paths are used only for redundancy.

    • by KiloByte (825081) on Friday August 01, 2014 @09:01AM (#47580997)

      For me, some extra resiliency against snooping is a bonus rather than a "critical vulnerability".

    • Three duh's from the article:

      Trust models users and networks have fostered with Internet providers are also changed—and in some cases broken. Contrary to that, providers will no longer be able to sniff traffic—under court order for example—unless they work hand in hand with other providers handling split traffic sessions.

      They lost me at "Trust models users .... have fostered with Internet providers".... Duh.

      “Technology like MPTCP makes it much harder for surveillance states,”

      • Exackitilly - trunking, traffic shaping and load sharing has been with us since the age of the dinosaurs. Reordering packets to assemble a stream from multiple routes is not a big deal.
        • Christ, it was one of the first lessons I learned that one could not simply sniff incoming packets and assume there was any order to them. People have been writing UDP protocols for decades now that require reassembly of packets into proper order.

          I get that multipath TCP means a lot more traffic will be sent in odd fashion, but really, if the recipient TCP stack can grab and reorder them, then that's what counts.

        • by Bengie (1121981)
          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. Imagi
    • it will likely be used in the appropriate places as opposed to 'everywhere in the tubes.'

      Appropriate meaning, in practical terms, any place it might save the operator of a given network segment a couple of bucks.

    • Of course, this technology is just begging the Tor network to adopt it!

    • by mellon (7048)

      The irony is that the article mentions that mptcp makes surveillance harder, as if that's a bad thing. Really tells you where the author(s) are coming from...

  • Great! (Score:3, Insightful)

    by Anonymous Coward on Friday August 01, 2014 @08:30AM (#47580801)

    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.

    • by BitZtream (692029)

      Not really.

      'The bad guys' have multiple options. Comcast will do DPI at the edge where you have only one path, so multipathing won't effect them and throttling your torrents will still be trivial. The NSA/CIA will just recombine the streams in their data center from the multiple taps they have. Its not really difficult if you have enough CPU and they have the budget to ensure they have enough CPU ... and if they don't have the budget, they have enough dirty on congress to get their budget upped until the

      • Re:Great! (Score:4, Informative)

        by Lennie (16154) on Friday August 01, 2014 @01:02PM (#47583253) Homepage

        I'm not sure what you mean, but MultiPath-TCP is about combining different technologies.

        So one part of the stream will run over Comcast, sure. But an other part will be transfered of 3G/LTE/whatever...

        In that case Comcast isn't going to get the whole stream. Good luck with your IDS and deep packet inspection.

        Al though most deep packet inspection problem looks for port-numbers, HTTP Host-headers, HTTPS SNI names and destination IP-addresses anyway. So impact in that case might not be that bad.

        An other use case for MultiPath-TCP is roaming without dropping a connection. So for example, going from one WiFi to an other Wifi network without interruption.

        If that is a different provider again Comcast won't see the whole stream.

        • by Bengie (1121981)

          Al though most deep packet inspection problem looks for port-numbers

          IPv6+IPSEC. Port numbers are also encrypted.

  • Design Issue (Score:4, Insightful)

    by sociocapitalist (2471722) on Friday August 01, 2014 @08:30AM (#47580809)

    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.

    • by Anonymous Coward

      But that's the point: it doesn't have to.

      Say you have a phone on corporate WiFi and 4G. The phone handles MPTCP, but the corporate firewall only sees the part of traffic that goes over WiFi.

      • But that's the point: it doesn't have to.

        Say you have a phone on corporate WiFi and 4G. The phone handles MPTCP, but the corporate firewall only sees the part of traffic that goes over WiFi.

        First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall) and in the second it will not cross the firewall anyway.

        Second, if the firewall sees traffic it doesn't understand it's just going to drop it. Security is not compromised.

        • by amorsen (7485)

          First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall)

          What stops a BYOD from using multipath? It will have to use the 4G connection when it isn't on the corporate wifi, so what keeps it from using both?

          • by karnal (22275)

            Corporate policies can be pushed to a non BYOD device. Obviously (as you point out) the BYOD device - if it's using both paths - could be blocked on the corporate WiFi environment due to the IPS policy but continue chugging along on 4G and effectively negating the bonus of multipath.

            There's never a clear solution for BYOD unless it can be centrally managed, which is the security concern for most (all?) companies, I'd think.

          • by Shatrat (855151)

            What's to stop it from using only the 4G connection and being completely undetectable by the firewall/IDS/IPS? That scenario is already broken.

          • First off, it seems unlikely as the phone will either be a corporate device, including BYOD, or a personal device. In the first case the traffic will have to flow across the network (including the firewall)

            What stops a BYOD from using multipath? It will have to use the 4G connection when it isn't on the corporate wifi, so what keeps it from using both?

            It's the destination that comes into play. If it's a personal destination it's not going to use the corporate network. If it's a corporate destination then it will.

            If it tries to do both - ie to a personal destination across the corporate network + 4G then the firewall will drop the packets and either it won't work at all or the upper level protocol will have to realize that one path is down and not use it.

            In any case, the security model is not broken.

          • by tepples (727027)

            What stops a BYOD from using multipath?

            The 4G carrier's monthly cap.

        • by Anonymous Coward

          The firewall sees another TCP connection. Everything looks great.

          Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.

          This is definitely a game changer. The old security inspections are successfully evaded. Add on the ability to open a stream in the opposite direction.

          The countermeasure is to enable deep protocol inspection (and HTTPS inspection!) and your NG firewall and have it try and understand MPTCP

          • Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.

            Mind you the same applies if someone downloads a malware binary across an encrypted protocol

            The countermeasure is to enable deep protocol inspection (and HTTPS inspection!)

            To inspect https traffic you have to force proxy it. Force proxying should be an effective measure to prevent multipath TCP as well.

          • The firewall sees another TCP connection. Everything looks great.

            Lets say... a malware binary is downloaded with a dynamic load balancing across 2 tcp streams. Everything looks fine to your NG firewall, no malware detected.

            This is definitely a game changer. The old security inspections are successfully evaded. Add on the ability to open a stream in the opposite direction.

            The countermeasure is to enable deep protocol inspection (and HTTPS inspection!) and your NG firewall and have it try and understand MPTCP and correlate multiple streams. Try doing that with an active/active firewall cluster.

            As another poster commented, we are definitely moving towards per-host IPS, hopefully in the hypervisor for your VMs.

            So I worked on a file transfer product some years ago that basically did the same thing - it transferred using multiple TCP connections to reliably overcome certain network conditions (e.g satcom, network drops, etc). Our clients built IDS/IPS rules to handle the whole thing without any issue, and we didn't have to provide documentation of our network protocol for them to do it. Of course, it was helped by the fact that we used the same port to open all the connections.

            So ultimately I don't see this as

        • by Bengie (1121981)

          if the firewall sees traffic it doesn't understand it's just going to drop it.

          MPTCP is backwards compatible with stateful firewalls, so unless your firewall knows about MPTCP, it will think it's just another TCP stream for an unknown Layer7 protocol and nothing will look wrong.

          • if the firewall sees traffic it doesn't understand it's just going to drop it.

            MPTCP is backwards compatible with stateful firewalls, so unless your firewall knows about MPTCP, it will think it's just another TCP stream for an unknown Layer7 protocol and nothing will look wrong.

            Sure, but if (due to MPTCP) the firewall only sees part of the flow (sequence number problem) or does not see the first packet of the flow as some packets are taking a path that does not flow through the firewall, it will drop the traffic.

            This is why I said this whole topic is a design issue. All paths must go through the firewall or traffic will be dropped.

    • by Anonymous Coward

      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.

  • by mysidia (191772) on Friday August 01, 2014 @08:38AM (#47580857)

    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.

    • by amorsen (7485)

      Your IDS/IPS cannot look inside SSL traffic

      Sure it can. You just push a new root certificate to your devices and intercept away.

      • by mysidia (191772)

        Sure it can. You just push a new root certificate to your devices and intercept away.

        Issuance of a bogus certificate to fool one of the parties to a SSL conversation is called a Man-in-The-Middle attack which is fraudulent conduct; pushing a fraudulently issued a certificate document claiming to be the other party and that this false thing was the other party's key.

        This is nothing to base a security model on, as the attack actually compromises encrypted data --- the parties to a legitimate conversat

    • by thermowax (179226)

      "Your IDS/IPS cannot look inside SSL traffic, either, which could contain exploit code (conveniently packed and encrypted by the SSL container)."

      You might want to go read up on SSLStrip before you make that assertion. There are a bunch of other utilities that do basically the same thing, but their names escape me at the moment.

      Admittedly, SSLStrip relies (generally) on the target ignoring the bad cert warning, but if you've compromised the target and inserted your root CA into the "trusted" list, well... n

  • Really??? (Score:5, Insightful)

    by Jaime2 (824950) on Friday August 01, 2014 @08:54AM (#47580945)
    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?
    • by jrumney (197329)

      BTW, this is the same security gear that can already be thwarted by end-to-end encryption. How is this any different?

      It's different because the agencies with security as their middle name don't have a backdoor for this.

      For actual security purposes, making sensitive data more difficult to spy on is a feature.

      • by BitZtream (692029)

        ... Right, because they can't just recombine the data from their multiple taps back in their data center.

        Because ... they don't do this already to correlate data from different single path streams or anything ...

        Those agencies will have no problem for dealing with this particular issue.

      • by Jaime2 (824950)

        It's different because the agencies with security as their middle name don't have a backdoor for this.

        That's why I was careful to say "end-to-end encryption" instead of "https". If you aren't using the public CA infrastructure, your data may be private.

  • by Anonymous Coward

    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

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

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

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

The reason why worry kills more people than work is that more people worry than work.

Working...