RFC 8999 QUIC 不变量 2021年5月
Thomson 标准轨道 [页]
流：
互联网工程任务组（IETF）
RFC：
8999
类别：
标准轨道
发布时间：
ISSN：
2070-1721
作者：
M. Thomson
Mozilla

RFC 8999

QUIC 的版本无关属性

摘要

本文档定义了 QUIC 传输协议中所有版本共有的属性。

本备忘录状态

这是一份互联网标准轨道文档。

本文档是互联网工程任务组（IETF）的产物。它代表了 IETF 社区的共识。它已经过公开审查，并已由互联网工程指导组 （IESG）批准发布。关于互联网标准的更多信息可见 RFC 7841 第 2 节。

关于本文档当前状态、任何勘误以及如何提供反馈的信息， 可以在 https://www.rfc-editor.org/info/rfc8999获取。

▲

目录

1. QUIC 的极度抽象描述

QUIC 是两个端点之间的面向连接协议。这些端点交换 UDP 数据报。这些 UDP 数据报包含 QUIC 数据包。QUIC 端点使用 QUIC 数据包来建立 QUIC 连接，该连接是这些端点之间共享的 协议状态。

2. 所有 QUIC 版本的固定属性

除了提供安全的多路复用传输之外，QUIC [QUIC-TRANSPORT] 还允许选择协商版本。这使得协议能够随着时间推移响应新的需求而 发生变化。协议的许多特征都可能在不同版本之间发生变化。

本文档描述 QUIC 中预期在新版本开发和部署时保持稳定的 子集。所有这些不变量都独立于 IP 版本。

本文档的主要目标是确保可以部署新的 QUIC 版本。通过记录 不能改变的属性，本文档旨在保留 QUIC 端点协商协议任何其他方面 变更的能力。因此，这也保证了向端点之外的实体提供最少量的 信息。除非本文档明确禁止，否则协议的任何方面都可以在不同版本 之间发生变化。

附录 A 包含一个非穷尽列表，列出了一些 可能基于 QUIC 版本 1 的知识而作出的错误假设；这些假设并不适用于 QUIC 的每个版本。

3. 约定与定义

本文档中的关键词“MUST”、“MUST NOT”、 “REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、 “SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”，当且仅当它们如这里所示以全大写形式出现时， 应按 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。

即使未使用规范性语言，本文档也定义了对未来 QUIC 版本的要求。

本文档使用 [QUIC-TRANSPORT] 中的术语和记法约定。

4. 记法约定

数据包的格式使用本节定义的记法来描述。 该记法与 [QUIC-TRANSPORT] 中使用的记法相同。

复杂字段先命名，然后跟随一组由一对匹配花括号括起的字段。 此列表中的每个字段都用逗号分隔。

各个字段包括长度信息，以及关于固定值、可选性或重复的指示。 各个字段使用以下记法约定，所有长度均以位为单位：

x (A)：

表示 x 的长度为 A 位

x (A..B)：

表示 x 可以是从 A 到 B 的任意长度；可以省略 A 来表示 最小为零位，也可以省略 B 来表示没有设定的上限； 这种格式的值总是在字节边界处结束

x (L) = C：

表示 x 具有固定值 C；x 的长度由 L 描述，L 可以使用上述任何长度形式

x (L) ...：

表示 x 重复零次或多次，且每个实例的长度为 L

本文档使用网络字节序（即大端序）值。字段从每个字节的高位开始放置。

图 1 展示了一个示例结构：

Example Structure {
  One-bit Field (1),
  7-bit Field with Fixed Value (7) = 61,
  Arbitrary-Length Field (..),
  Variable-Length Field (8..24),
  Repeated Field (8) ...,
}
图 1： 示例格式

5. QUIC 数据包

QUIC 端点交换包含一个或多个 QUIC 数据包的 UDP 数据报。 本节描述 QUIC 数据包的不变特征。QUIC 的某个版本可以允许 单个 UDP 数据报中包含多个 QUIC 数据包，但这些不变属性只描述 数据报中的第一个数据包。

QUIC 定义了两类数据包标头：长标头和短标头。长标头数据包通过 第一个字节的最高有效位被置位来识别；短标头数据包则清除此位。

QUIC 数据包可能受到完整性保护，包括标头。不过，QUIC 版本协商数据包不受完整性保护；见第 6 节。

除这里描述的值之外，QUIC 数据包的有效载荷是 版本特定的，并且长度任意。

5.1. 长标头

长标头采用图 2 所描述的形式。

Long Header Packet {
  Header Form (1) = 1,
  Version-Specific Bits (7),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Version-Specific Data (..),
}
图 2： QUIC 长标头

带有长标头的 QUIC 数据包将第一个字节的高位置为 1。 该字节中的所有其他位都是版本特定的。

接下来的四个字节包含一个 32 位 Version 字段。版本在 第 5.4 节中描述。

下一个字节包含其后 Destination Connection ID 字段的字节长度。该长度编码为 8 位无符号整数。 Destination Connection ID 字段跟在 Destination Connection ID Length 字段之后，长度在 0 到 255 字节之间。连接 ID 在 第 5.3 节中描述。

下一个字节包含其后 Source Connection ID 字段的 字节长度。该长度编码为 8 位无符号整数。 Source Connection ID 字段跟在 Source Connection ID Length 字段之后， 长度在 0 到 255 字节之间。

数据包的其余部分包含版本特定的内容。

5.2. 短标头

短标头采用图 3 所描述的形式。

Short Header Packet {
  Header Form (1) = 0,
  Version-Specific Bits (7),
  Destination Connection ID (..),
  Version-Specific Data (..),
}
图 3： QUIC 短标头

带有短标头的 QUIC 数据包将第一个字节的高位置为 0。

带有短标头的 QUIC 数据包在第一个字节之后立即包含 Destination Connection ID。短标头不包含 Destination Connection ID Length、Source Connection ID Length、Source Connection ID 或 Version 字段。Destination Connection ID 的长度不会编码在 带短标头的数据包中，并且不受本规范约束。

数据包的其余部分具有版本特定的语义。

5.3. 连接 ID

连接 ID 是一个任意长度的不透明字段。

连接 ID 的主要功能是确保较低协议层（UDP、IP 及更低层）的 寻址变化不会导致某个 QUIC 连接的数据包被递送到错误的 QUIC 端点。端点以及支持它们的中间设备使用连接 ID 来确保每个 QUIC 数据包能够递送到正确的端点实例。在端点处，连接 ID 用于标识该数据包所针对的 QUIC 连接。

连接 ID 由每个端点使用版本特定的方法选择。 同一个 QUIC 连接的数据包可能使用不同的连接 ID 值。

5.4. 版本

Version 字段包含一个 4 字节标识符。端点可以使用该值来 标识 QUIC 版本。值为 0x00000000 的 Version 字段保留用于版本协商；见第 6 节。 所有其他值都可能有效。

本文档描述的属性适用于 QUIC 的所有版本。 不符合本文档所描述属性的协议不是 QUIC。未来的文档可能描述 适用于特定 QUIC 版本或某一范围 QUIC 版本的其他属性。

6. 版本协商

接收到带长标头且版本无法理解或不支持的数据包的 QUIC 端点， 可能会发送版本协商数据包作为响应。带短标头的数据包不会触发 版本协商。

版本协商数据包设置第一个字节的高位，因此它符合 第 5.1 节中定义的长标头数据包格式。版本协商数据包可通过 Version 字段识别，该字段被设置为 0x00000000。 

Version Negotiation Packet {
  Header Form (1) = 1,
  Unused (7),
  Version (32) = 0,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Supported Version (32) ...,
}
图 4： 版本协商数据包

版本协商数据包第一个字节中只有最高有效位具有已定义的值。 其余 7 位标记为“Unused”，发送时可以设置为任意值， 接收时MUST忽略。

在 Source Connection ID 字段之后，版本协商数据包包含一个 Supported Version 字段列表，每个字段标识发送该数据包的端点所支持的一个版本。 版本协商数据包不包含其他字段。端点MUST忽略不包含任何 Supported Version 字段或包含截断的 Supported Version 值的数据包。

版本协商数据包不使用完整性或机密性保护。 特定的 QUIC 版本可能包含协议元素，使端点能够检测受支持版本集合中的 修改或损坏。

端点MUST在 Destination Connection ID 字段中包含其所接收数据包的 Source Connection ID 字段中的值。Source Connection ID 字段的值 MUST从接收到的数据包的 Destination Connection ID 字段复制，该字段最初由客户端随机选择。回显这两个连接 ID 可以让客户端在一定程度上确信服务器接收到了该数据包，并且版本协商数据包 不是由无法观察数据包的攻击者生成的。

接收到版本协商数据包的端点可能会更改其决定用于后续数据包的 版本。端点更改其 QUIC 版本的条件将取决于它所选择的 QUIC 版本。

关于支持 QUIC 版本 1 的端点如何生成和使用版本协商数据包的 更详尽描述，见 [QUIC-TRANSPORT]。

7. 安全与隐私考量

中间设备可能会观察 QUIC 某个特定版本的特征，并假设当 QUIC 的其他版本表现出类似特征时，表达的是相同的底层语义。 这种特征可能有很多；见附录 A。QUIC 版本 1 中已经作出一些努力， 以消除或混淆某些可观察特征，但其中许多特征仍然存在。 其他 QUIC 版本可能作出不同的设计决策，因此表现出不同的特征。

QUIC 版本号并不会出现在所有 QUIC 数据包中，这意味着如果要 基于版本特定的特征可靠地从流中提取信息，中间设备需要为它们看到的 每个连接 ID 保留状态。

本文档描述的版本协商数据包不受完整性保护；它只对攻击者插入提供 有限保护。如果端点因此尝试使用不同的 QUIC 版本，则它MUST 对版本协商数据包的语义内容进行认证。

8. 参考文献

8.1. 规范性参考文献

[RFC2119]
Bradner, S.，“RFC 中用于 指示要求级别的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，，<https://www.rfc-editor.org/info/rfc2119>。
[RFC8174]
Leiba, B.，“RFC 2119 关键词中 大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，，<https://www.rfc-editor.org/info/rfc8174>。

8.2. 资料性参考文献

[QUIC-TLS]
Thomson, M., Ed. 和 S. Turner, Ed.， “使用 TLS 保护 QUIC”，RFC 9001， DOI 10.17487/RFC9001，，<https://www.rfc-editor.org/info/rfc9001>。
[QUIC-TRANSPORT]
Iyengar, J., Ed. 和 M. Thomson, Ed.， “QUIC：一种基于 UDP 的多路复用安全传输”，RFC 9000，DOI 10.17487/RFC9000，，<https://www.rfc-editor.org/info/rfc9000>。
[RFC5116]
McGrew, D.，“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，，<https://www.rfc-editor.org/info/rfc5116>。

附录 A. 错误假设

QUIC 版本 1 [QUIC-TRANSPORT] 有若干特征并未 受到防观察保护，但在部署新版本时仍被认为是可改变的。

本节列出了一些可能基于 QUIC 版本 1 的知识而对 QUIC 作出的错误假设示例。其中一些陈述甚至对 QUIC 版本 1 也不成立。 这不是一个穷尽列表；它仅用于说明。

以下任一或全部陈述对于给定 QUIC 版本都可能是错误的：

作者地址

Martin Thomson
Mozilla