Research : QUIC Transport Protocol
QUIC is a new UDP-based, stream-multiplexing, encrypted transport protocol being developed in the IETF QUIC working group based on pre-standards implementation experience at Google. It is intended to be a secure modern transport protocol, that can effectively support applications such as HTTP/2. My interests in QUIC are in providing better support for multimedia streaming and interactive use cases, and in supporting peer-to-peer transport.
As part of the trend towards increasing use of end-to-end encryption on the Internet, we've started to see moves to encrypt the transport layer headers in addition to the payload data. The QUIC transport protocol is one example of a transport with this behaviour. Encrypting these headers has some widely discussed benefits: it reduces information leakage and provides some small privacy benefit, it helps prevent certain spoofing and injection attacks against the transport, and it limits the scope for middlebox-related ossification of the stack. The costs incurred by encrypting these headers have been less widely discussed, however. Gorry Fairhurst and I wrote a draft that considers these costs, that we presented in the OPSEC and TSVWG working groups at IETF 100 in Singapore in November 2017.
The initial focus of QUIC development has been on client-server use, primarily as a transport for HTTP/2. In the long term, however, if QUIC is to become a general purpose transport, it must be usable by peer-to-peer applications. This requires support for NAT traversal, for which the IETF has developed the STUN protocol and the ICE algorithm. The version of QUIC specified in draft-ietf-quic-transport-07 can't easily support this, since its packets are formatted such that they're difficult to distinguish from STUN packets. This post outlines the problems and proposes changes to simplify demultiplexing QUIC and STUN packets. It also considers how to distinguish QUIC packets from other protocols such as those used by WebRTC.