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.

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

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

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.