QUIC Version Aliasing
draft-duke-quic-version-aliasing-04
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Author | Martin Duke | ||
| Last updated | 2021-05-03 (Latest revision 2020-10-30) | ||
| Replaces | draft-ietf-quic-version-aliasing | ||
| Stream | (None) | ||
| Formats |
Expired & archived
plain text
html
xml
htmlized
pdfized
bibtex
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
https://www.ietf.org/archive/id/draft-duke-quic-version-aliasing-04.txt
Abstract
The QUIC transport protocol [QUIC-TRANSPORT] preserves its future extensibility partly by specifying its version number. There will be a relatively small number of published version numbers for the foreseeable future. This document provides a method for clients and servers to negotiate the use of other version numbers in subsequent connections and encrypts Initial Packets using secret keys instead of standard ones. If a sizeable subset of QUIC connections use this mechanism, this should prevent middlebox ossification around the current set of published version numbers and the contents of QUIC Initial packets, as well as improving the protocol's privacy properties.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)