As we move forward to an ever more hyper-connected future, network protocols are shifting to enable powerful new functionality. Two interesting examples of this are Multipath TCP (MPTCP) and QUIC.
To help us understand these two dynamic protocols, we took the opportunity to chat with Catherine Pearce, a Senior Security Consultant at Cisco, after her presentation on the topic at APRICOT 2016.
What are Multipath TCP and QUIC?
TCP works by sending packets of data from a sender to a receiver via one path. The first packets that a sender sends to a receiver are primarily associated with negotiating whether the receiver is connected and if they would like to receive data, and in some cases some other features including encryption.
MPTCP is an extension to TCP that is implemented at the kernel level. It enables sessions to use multiple network endpoints and multiple network paths at the same time, and to change addresses in the middle of a connection.
QUIC, on the other hand, is a UDP Application protocol that multiplexes connections between endpoints at the application level, rather than the kernel level. QUIC also negotiates encryption without the back and forth negotiation that TCP and SSL/TLS use. What’s more, QUIC has an entire protocol suite within each connection with layered data streams transmitting different packets – think of it like a double or triple-decker bus that transports people on different levels the same distance.
These features help QUIC reduce latency, as data is transmitted with those first packets. In some cases this latency might be insignificant, but on a very long connection this decrease in latency is fairly considerable and particularly significant when streaming content.
Why have these protocols recently become popular?
Multipath technologies have been around for a long time, but there were different approaches.
We had SCTCP years ago, that implemented some of these things that MPTCP and QUIC do, but it never really took off at scale because people had to code applications to accommodate it, and have a network that supports it.
After a lot of research MPTCP was proposed as a solution, because it runs in the kernel as a socket, therefore doesn’t need applications to support it. However, a problem with MPTCP is your operating system needs to support it from both ends, so it needs to be a part of all the operating systems and API’s, and that complicates and slows down development.
This is how QUIC came to be. QUIC needs apps to support it – it handles all of the processing in the application – but is also backward compatible with existing networks and has open source code available, so you can just plug in open source QUIC implementation code.
The other reason for the recent increase in popularity has been the rise of mobile technologies and how most mobile devices (such as smart phones) these days have at least two connections available to them – cellular and wireless. MPTCP and QUIC seek to take advantage of the multiple Internet connections: the cheap, high bandwidth capabilities of wi-fi and these persistent connection abilities of cellular.
With packets being segmented and travelling via different paths and different streams, how do you secure traffic when you can’t see it all and when the endpoint addresses change in the middle of a connection?
The way the Internet was designed at the start, if you had a problem sending a packet from A to B, it would route around. However, with network security we look at things and decide if we like them before sending them on their way. Multipath technologies make it far more complicated if you are intending to inspect and understand the content and metadata using your network, particularly if packets are encrypted.
Even if you have the encryption key, how do you decrypt something that is missing chunks, because those chunks have travelled via different paths?
Another aspect that will make inspection more difficult is the ability of multipath technologies to de-prioritize a network that puts up too many roadblocks; instead of routing packets along another more reliable, or speedier, path.
What operators need to remember is that while you may control the management of your network, you don’t control the technology developments, or the users demands. It’s very tempting as a network operator to say, “I don’t understand this, so I’m just going to block it”. Did that mentality work well in the past with blocking mobile devices? No, it didn’t.
What drives business is demand, and supply usually has to catch up, whether or not it wants to.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.