Multipath TCP speeds up the internet so much that security breaks The burgeoning Multipath TCP (MPTCP) standard promises to speed up the internet but will also break security solutions including intrusion detection and data leak prevention, says security researcher Catherine Pearce. MPTCP technology is an update to the core communications backbone of the internet that will allow the …
The gist of this article is that MPTCP may be restricted - and therefore we have a slower and less reliable service - because it makes it difficult to "undetectably alter or sniff your traffic".
Since when is this a socially legitimate rationale?
Is this the ultimate legacy of Snowden and WikiLeaks - that it becomes mandatory to build in the ability for the powers that be (corporate, governments, Silicon Valley firms) to view and meddle with your ostensibly private network traffic?
I think you are missing a fair bit of the other commentary in the article.
While increasing speed, it also increases traffic by multiplexing communications, which would further hamper networks.
Stateful systems aren't equipped to handle distributed state, thus pretty much any system that isn't an endpoint of a MCTCP connection is useless at doing anything besides simply forwarding the packets.
What I will agree with you on the whims of corportations is regarding the research on "side channel attacks." I don't really understand why being able to infer throughput, congestion, packet delay, etc of other ISPs is an issue. None of that information sounds horribly proprietary, but what do I know.
"Stateful systems aren't equipped to handle distributed state, thus pretty much any system that isn't an endpoint of a MCTCP connection is useless at doing anything besides simply forwarding the packets."
Correct. That's all they're supposed to be doing.
How is this different from a VPN (other than performance considerations)? Or spread-spectrum radio?
This post has been deleted by its author
"While increasing speed, it also increases traffic by multiplexing communications, which would further hamper networks."
So MPTCP could increase traffic, and that is bad?
With that reasoning, we should stop using the networks at all, since using them means network traffic, and that is bad.
"Stateful systems aren't equipped to handle distributed state, thus pretty much any system that isn't an endpoint of a MCTCP connection is useless at doing anything besides simply forwarding the packets."
Forwarding is exactly what the non-endpoints should do, and nothing else. They do not need to be, and should not be, stateful in any way.
"What I will agree with you on the whims of corportations is regarding the research on "side channel attacks." I don't really understand why being able to infer throughput, congestion, packet delay, etc of other ISPs is an issue. None of that information sounds horribly proprietary, but what do I know."
I too agree with this, fully. There are much simpler ways of measuring the performance of a competitor's network - just send traffic through it.
"The gist of this article is that MPTCP may be restricted - and therefore we have a slower and less reliable service - because it makes it difficult to "undetectably alter or sniff your traffic".
Since when is this a socially legitimate rationale?"
When you're my employee trying to access corporate resources that I, as the business owner, demand be secured.
Now, I could of course force the streams to recombine via the use of proxies, VPN or various gateways at the edge of my network then perform analysis on single stream after it gets recombined. (Whatever happened to the idea of a DMZ?) But that would be silly, and it's much better instead to simply ban the use of said protocols altogether.
Okay, the snark is tongue in cheek. The reality is that if we did as I proposed we'd all have to reengineer our security mechanisms, and in turn goodly chunks of our networks. What will happen is that we'll simply ban MPTCP until such a time a few things occur A) our Preferred Vendors come up with single-unit solutions to this and B) we're on a refresh cycle anyways C) it's a minimal additional cost (as opposed to an expensive new feature) where the "additional cost" is deemed to be lower than the business benefit of allowing MPTCP on our networks.
This issue was raised a while ago, so there are probably about 5 startups in stealth mode with tech to handle it. They'll have a coming out part either at VMworld 2014 or in Early 2015. They will see minimal uptake and be followed by a flood of new entrants over the next 3 years at which point Juniper will implement it as a feature (probably by buying a startup) and Cisco will implement it as a Really Expensive Feature, but get it wrong and try to use it as a hook to make everything proprietary.
Shortly thereafter Palo Alto Networks and F5 will have figured out how to get it right and simply slipped it into the next release, making it somewhere between 5 and 6 years to enterprise mundane and probably 8 years to full commoditisation.
10 years from now we'll see enough support for MPTCP in the consumer gear that's actually in people's homes that we'll be able to see widespread adoption by device manufacturers and programers and 12 years from now we'll come up with something more efficient.
I could of course force the streams to recombine via the use of proxies, VPN
yes you could, and while we are at it, can you pls remind what's wrong with obligatory VPN to access corporate network? I know it's not exactly free, but c'mon it just plain sense.
Paris because I'm just the same puzzled.
Not really madness. When engineers like myself talk about sniffing traffic, we are more interested in the performance of the underlying network.
The probes in question are really more for Service Assurance as opposed to intercept - probe vendor examples are Accedian, JDSU, Spirent etc. We are talking different things.
Intercept is typically done at CLI level i.e. lawful-intercept command, built into most Internetworking OS systems.
One Vendor example of this is below:
http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/ht_ssi.html
Other Vendors are of course available (Juniper, Alu, Huawei et al), but all must enable the same thing in the OS with no exception.
The challenge we face on the Service Assurance front with MSTCP is correlating the streams to understand how the underlying network is performing. The probe vendors will eventually suss this out via standards and the security guys will also need to do the same.
Those of us in the OSS space ingest all of this probe data and conduct analytics on it to correlate network events. The ISP or CP can then act accordingly; network config, billing rec, SLA management (i.e. am I claiming or paying credits) etc.
Challenges in networking always exist, this is just another that is aimed to the probe vendors, security guys and the network guys.
Network Guy
@"Network guy"
I don't understand what you are saying. MPTCP means that there are two or more routes for data to get from A to B. It takes the fastest available route, sometimes by spamming both routes with the data. The only bit you care about is the bit that hits your network. I.E. that which travels over your network (via WiFi, for example) or where both streams enter your network and try to accomplish something.
The rest is Someone Else's Problem...and for them it's just transit traffic. Worst case scenario from a speed perspective, this makes the guys at ThousandEyes have to put a few weeks in to solve the problem.
So if MPTCP is a concern for those trying to figure out network congestion - which shouldn't care about the content of the packets at all - I don't understand how. What does matter if the ability to do intercept, because with MPTCP you could have some packets on path A and some on path B, and so intercept on any given path won't get the whole stream.
If you want to really get it the correctness of it....
The rules for prefixes depend on the origin of the root word, generally is it Latin or Germanic in origin.
For Germanic origin words the prefix un- should be used where as for Latin origin words in- should be used.
The root word in this case, detect, comes from Latin meaning "uncovered". Therefore indetectable/indetectably are the correct forms.
However the correct use of un- and in- is something that has been debated and abused for centuries and the trend toward one or the other changes over time. Look at the American declaration of independence as you will see it contains the word "unalienable" but generally in the modern day the word inalienable is used and is the correct form due to the root origin or alien being Latin.
However as with most things in modern language (especially English) it is generally accepted that the version that sounds best and is most fluid to say is the version that is used.
To me personally saying "he passed undetected" is much more comfortable on the tongue than saying "he passed indetected".
Phil, English has many, many words with mixed roots. How should a word like unbiodegradable be made “correct”, with its mixture of Old English, Greek, and Latin roots? “unlifeshendable”? “abiodiasporable”? “invitadegradable”?
If you would really like to get to the historical truth of the matter, read the wall of text which is the entry for un- in the OED.
How about a hyphenated prefix of non- just like you get for non-biological washing powder.
As I pointed out previously, in the development of modern language it's whatever people like the sound of best that wins, not what scholars say is correct. Especially as the OED has taken to adding all kinds of linguistic turds to it's contents as long as someone is using them, such as "srsly", "ridics" and "whatevs".
Phil, a non- prefix would certainly be possible, thanks to the flexibility of English, but does not fully address the “correctness” issue which you’d stated came from root inconsistency, since biodegradable is itself a mix of Greek and Latin roots.
English has a long tradition of using an un- prefix with words which don’t have English roots, e.g. unsavoury from the 13th century. My original point was that there was no reason to mark undetectably with “sic”, since that word exists and was used comprehensibly.
Since the OED is descriptive rather than prescriptive, collecting linguistic turds is part of its remit.
I'm referring to products sold explicitly as "IDS", not products (such as load balancers, routers and plain old servers) that have built in "IDS" features.
I mean, at work we have all kinds of dedicated appliance boxes that claim to perform "deep packet" analysis and other proprietary tricks. Yet I've never, ever, seen anything reported from these systems detecting or alerting about something that a simple firewall can't do.
I can get that information from logs, say ssh connection attempts from outside the perimeter, network scans, DDoS attempts and such so exactly what these IDSs do? Unless IDSs are a fancy name for "firewalls & logs", I can't tell exactly what they actually do.
Maybe it's me and I'm a security ignorant, or lack the experience, or the people manning these systems are not really competent to do it. But I currently view IDSs as no more than expensive check-box-ticking-compliance-solutions, which in its own have its value but does not contribute anything to actually securing the data. Open to hear from anyone that has seen any of these actually work.
(So currently don't see any drama about changes in TCP "breaking" IDSs)
From the unnecessary repeat department: thanks for confirming my assumpion while not contributing to my knowledge one iota. Guess that you never, ever face any problems outside your area of expertise, and that the knowledge in that area has been magically infused to you since when/if you asked any question admitting ignorance you just got a response confirming your ignorance.
You are referring to network IDS. I cannot comment much on those as my experience has been with host-based solutions, but my understanding is that firewalls are fairly static, whereas an IDS or IPS should perform some analysis based on heuristics or signatures similar to an AV product (and yes, I know there are some of my fellow commentards who decry their use). However, you mention firewalls, which the article said could be broken by MPTCP. It is more complex than that, depending on configuration of the FW to accept it, the implementation of MPTCP, the FW being used. However, the simple solution, as far as I can tell, is to disable it at the FW if possible. Also, the cited Cisco article includes NATed networks as being affected.
Unless there is a business case for using it, it should be disabled (pretty much true for anything from a security standpoint). If there is a good reason for using it, I'm happy I'm not the person doing the implementation.
It's hardly surprising that it might be easier to monitor the state of an alternate traffic path in MPTCP than in traditional TCP, since with TCP the other path doesn't exist. Except in the case where there are two parallel direct trunks between the endpoints, I'm not sure what useful information this provides - any measured congestion could be taking place at any point on the path which will normally involve a number of hops via a number of carriers.
Besides, the fact that an ISP might be able to infer something about the saturation of a competitor's trunks is hardly a big "security" deal compared to the benefit of making interception significantly trickier (particularly for encrypted traffic).
Yes, "security" systems that attempt to reassemble and scan individual traffic flows will not be able to do so unless they recognise MPTCP and reassemble accordingly. However, since an intruder can pretty much pick any protocol they like to interact with a hacked system an IDS that relies on the black hats sticking to the RFCs doesn't sound terribly useful.
Whether any of this stuff should be going on at the transport layer is another matter, of course...
"Do these things that are broken by MPTCP support IPv6?"
Well, NAT doesn't, but we don't need or want NAT for IPv6, so that's fine.
Apart from that I think MPTCP is IP-version-agnostic. Also consider that multiple paths *require* multiple addresses, which are much more likely to occur with IPv6. So it's really the other way round: Is MPTCP actually any use for IPv4, considering that multiple paths are extremely rare?
HI, I’m Catherine Pearce (@secvalve), the primary researcher for the Blackhat research referred to here.
Just thought I’d clarify a few things and attempt to bring some nuance back to this discussion. One of my key points in this work was to raise awareness to this tech so people can respond appropriately, in whatever way that means for them and their technology.
Firstly, Many of the techniques done in MPTCP aren't entirely novel, you could do them at the application layer if you wanted to - but MPTCP brings them to most existing tech without having to handle the complexity in the application. I recommend people see this paper if they're technically inclined: http://inl.info.ucl.ac.be/system/files/nsdi12-final125.pdf As for the discussions on congestion, flow control, and network load, there has been some research done into this, see "theoretical background" here: http://nrg.cs.ucl.ac.uk/mptcp/
One short way to think about packet switching is that packets of data should be sent wherever the best route is at the time. With TCP however, you're stuck with whatever link and address(es) you initially use. MPTCP extends TCP and frees you from this restriction.
Shifting power: Yes, one of the key things a tech like MPTCP does is shift some degree of trust away from network operators and on to the endpoints. While you should be using things like encryption, in cases where this isn't possible or efficient you are generally at the mercy of whichever networks you pass your traffic over. MPTCP gives you a bit more choice, and a bit more ability to split things up and compare difference. This is seen as bad in organizations (who like to be effectively totalitarian in their own domain), but is a good thing if you're trying to protect yourself from a network (state-level attackers).
Regarding how people can deal with this, of course they can bottleneck it, or stop it going multipath in the first place, but this prevents you from getting the benefits. Network operators shouldn't shortsightedly kill something because they don't understand it - there are more sensible ways to deal with a threat than panicking and beating it to death.
Oh, and MPTCP can also split traffic over both ipv6 and ipv4 at the same time. I find that fun to think about...
More details will come out next week -- Catherine
You can't implement it at the application layer yet without either OS support or administrative privileges (for crafting raw packets)
To your question though, i think this sort of technique shows huge promise as a privacy preserving technology. I'm not the right person to make it happen, if you break TOR you kill people. Nevertheless, i will be encouraging the right people to look into it.
Network operators shouldn't shortsightedly kill something because they don't understand it - there are more sensible ways to deal with a threat than panicking and beating it to death.
Welcome to the fun, Catherine, and thanks for the research. Most of what you say makes good sense, though I have one quibble with the above statement: this is exactly how network admins should react to anything on their network they do not understand. They should make every effort to gain the knowledge to make a rational decision, but until that point, not so much. Besides the obvious concern that it, whatever it is, is not under your control, there is also the idea that if you do not understand it, you have no assurance you it is configured properly and doing what you want it too. I am not so sure about the panic portion of the equation, but I am sure someone in management can cover that.
While i agree you should be in control of your network, its also easy to think that you have more visibility or control than you do. You'd be surprised how many time i see orgs not stripping/proxying outbound SSL and not understanding why it matters to their DLP.
For a small or HIGHLY managed network you can work to maintain security via network totalitarianism. The larger the network, or the more dynamic the systems on it, the less realistic this becomes. Within the .mil space or small companies this can be done. But i have never seen this succeed in big dynamic orgs, other than in very tightly restricted network segments. Usually i can tunnel over http or DNS for a good length of time anyway. If they catch on and block that, then there are other methods.
A serious academic ventured into the Register forums? Flee, while you still have some sanity remaining!
I don't see what application MPTCP has outside of the mobile space. How many homes have two internet connections? So everything goes through one bottleneck anyway. I see the application for mobiles though, and in particular for smoother handoffs from mobile to WLAN and back. I imagine that's why Apple use it - it's not for performance, it's so Siri doesn't glitch out when you leave wireless range and transition to the new IP address on the cell net.
Heh i'm not an academic, i'm a lowly Security consultant. I get paid to 1. break stuff and 2. Help people secure things for the future. Sanity left long ago. Research is a side hobby of mine and not my day job (yet?)..
I'm used to people spinning this into the sky is falling, or commenting on this work when they obviously haven't read the actual article or sources. This leads to a hilarious bingo card by the way: "OMG SO OBVIOUS" = take one token, "Why would i want this" = 1 token, "KILL IT, KILL IT!" = 2 tokens...
You're right that the mobile space is a big driver. Another is highly connected networks such as one might find in datacenters. This is because it allows you to aggregate link capacity without complicated & proprietary tech.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
