SDxCentral
Join Log In
SD-WAN 5G Edge 1 IoT SDN NFV Containers Cloud Security AI Data Center Storage APM/NPM Open Source

Log In to SDxCentral

Log in with your email? Forgot your password?
  • Newsletters
  • eBriefs
  • Podcasts
  • Webinars
  • Videos
  • Directory
  • White Papers
  • Resources
  • Use Cases
  • Support

Join SDxCentral and get information tailored to your particular interests everyday.

Join
Sponsored:
Dell EMC Citrix Riverbed

As Multipath TCP Arrives, New Security Questions Arise

Multipath TCP Security
Craig Matsumoto
Craig MatsumotoAugust 11, 2014
2:32 pm MT
Email LinkedIn Facebook Twitter Reddit Hacker News

Multipath TCP stands a good chance of catching on as a Layer 4 networking technology, and if that happens, there are big security questions that no one seems to be addressing, according to researchers at security provider Neohapsis.

As Catherine Pearce and Patrick Thomas explained in a Black Hat session Wednesday afternoon, the problems come from the nature of multipath TCP. It allows one traffic flow to be spread across multiple TCP connections — a varying number of connections, no less — and that’s something networking and security gear isn’t equipped to understand, they said.

Related Articles

Juniper’s New 5G On-Ramp Products Include 400 GbE Triton Chip
Juniper’s New 5G On-Ramp Products Include 400 GbE Triton Chip
Cisco Boosts IoT Management Security With New Dev Tools and Hardware
Cisco Boosts IoT Management, Security With New Dev Tools and Hardware
Microsoft Adds AzureDevOps Bug Bounty, Offers $20K Rewards
Microsoft Adds AzureDevOps Bug Bounty, Offers $20K Rewards
VMware PKS Update Embraces Azure, Kubernetes Security
VMware PKS Update Embraces Azure, Kubernetes Security
IoT Spending to Hit $745 Billion in 2019, IDC Says
IoT Spending to Hit $745 Billion in 2019, IDC Says

“It breaks the way we do things,” Pearce said. “It confounds business models. It confounds security models that rely on inspection.”

Where Multipath TCP Comes From

Multipath TCP (MPTCP) is exactly what it sounds like: a protocol to spread a TCP flow across multiple paths. Developed through the IETF, MPTCP is meant to overcome certain limitations of TCP —the fact that neither side of a connection can move to a different port, for instance. It’s also an easier way to link-aggregate multiple TCP streams, so that one traffic session can use all of the combined bandwidth.

For the moment, MPTCP is being used only sparsely. Its star user is the Siri service on iPhones — but the rest of the iPhone doesn’t use it, Pearce said. Aside from that, usage is mostly limited to high-performance computing so far, she said.

Plenty of other TCP-enhancing protocols have come and gone without becoming mainstream, but MPTCP has gained momentum in the form of IETF RFCs and commercial implementations — Cisco and Juniper among them (but not Microsoft Windows). “This is one that looks like it might actually succeed,” Pearce said.

The point of the talk wasn’t that MPTCP itself is a problem. It’s more that the protocol upends the assumptions that most security tools make. (It’s not so friendly to general networking either, as The Register noted in September.)

MPTCP: What Could Possibly Go Wrong

One example is that if a malicious attack arrives via MPTCP, it’s going to be split among multiple lanes. Intrusion detection programs, watching one lane at a time, won’t necessarily catch on to what’s happening. What to do about this is still unclear; maybe some sort of probabilistic approach is called for, Pearce said.

The possibility of traffic stream-hopping opens up “an additional layer of obscurity” as well, Pearce said. As a security administrator, you might not know which fractions of a flow are still being watched by your monitoring gear.

There’s also this charmer:  When a session closes, the endpoints swap encryption keys. This normally isn’t a problem because the endpoint that’s closing the session has shut down its state — “It is no longer listening,” Pearce says. “‘Thing is, if you’re along that path, and you intercept that, you can leave the other end open and jump onto that connection.”

Is that easily exploitable? That’s the kind of question the industry needs to be looking at. The point of Pearce and Thomas’ talk was that despite the signs that MPTCP could be here to stay, there’s been very little discussion about its security implications.

“Security no worse than TCP was their goal. It’s not a very high bar,” Pearce said.

MPTCP opens questions beyond security, too. If an endpoint sending data wants to add paths to an MPTCP session, it notifies the receiving server, which then opens up the new path. That’s a contradiction — it’s meant to be a stream sending data (envision that as data being sent from “left” to “right” on a diagram), but the connection is originating in the other direction, right to left. From the point of view of a network tool, that new stream is “outbound, but incoming,” Pearce said. That could cause confusion in some monitoring and security tools.

SDxCentral Daily News

Join your Peers! Subscribe to SDxCentral's Newsletter

Article Tags:

Breaking News Cisco Juniper Networks Microsoft Neohapsis Security

Craig Matsumoto

About Craig Matsumoto

Craig Matsumoto is managing editor at SDxCentral.com, responsible for the site's content and for covering news. He is a "veteran" of the SDN scene, having started covering it way back in 2010, and his background in technology journalism goes back to 1994. Craig is based in Silicon Valley. He can be reached at craig@sdxcentral.com.

Subscribe to Get the Daily News!

About SDxCentral

  • Newsletters
  • About Us
  • Contact Us
  • Work With Us
  • Editorial Team
  • Careers
  • Legal
  • Support

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDxCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.

© 2012-2019 SDxCentral, LLC, All Rights Reserved. SDNCentral™, the SDNCentral logo, SDxCentral™, SDxCentral logo, SDxNews™, SDxTech™, SDx™, the SDx logo, and DemoFriday™ are trademarks of SDxCentral, LLC in the U.S. and other countries.

  • Terms of Service
  • Privacy