跳到主要内容

RFC 8999 - QUIC的版本无关属性

  • 状态: Proposed Standard
  • 发布日期: May 2021
  • Stream: IETF
  • 勘误: 无勘误

摘要​

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

备忘录状态​

本文档是互联网标准跟踪文档.

本文档是互联网工程任务组(IETF)的产品.它代表了IETF社区的共识,已经过公开审查并获得互联网工程指导组(IESG)的批准发布.有关互联网标准的更多信息,请参阅RFC 7841第2节.

有关本文档的当前状态、勘误表以及如何提供反馈的信息,请访问 https://www.rfc-editor.org/info/rfc8999

版权声明​

Copyright (c) 2021 IETF Trust及文档作者.保留所有权利.

本文档受BCP 78和IETF信托关于IETF文档的法律规定(https://trustee.ietf.org/license-info)约束,这些规定在本文档发布之日有效.请仔细阅读这些文档,因为它们描述了您对本文档的权利和限制.

目录​

  1. QUIC的极简抽象描述
  2. 所有QUIC版本的固定属性
  3. 约定和定义
  4. 符号约定
  5. QUIC数据包
    • 5.1. 长报头
    • 5.2. 短报头
    • 5.3. 连接ID
    • 5.4. 版本
  6. 版本协商
  7. 安全和隐私考虑
  8. 参考文献
    • 8.1. 规范性参考文献
    • 8.2. 信息性参考文献

附录​

作者信息​

Martin Thomson
Mozilla
Email: [email protected]

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定义了两种类型的数据包报头:长报头和短报头.具有长报头的数据包由第一个字节的最高有效位设置为1来标识;具有短报头的数据包将该位清零.

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位的版本字段.版本在第5.4节中描述.

下一个字节包含其后的目标连接ID字段的长度(以字节为单位).此长度编码为8位无符号整数.目标连接ID字段跟随在目标连接ID长度字段之后,长度在0到255字节之间.连接ID在第5.3节中描述.

下一个字节包含其后的源连接ID字段的长度(以字节为单位).此长度编码为8位无符号整数.源连接ID字段跟随在源连接ID长度字段之后,长度在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数据包在第一个字节之后立即包含目标连接ID.短报头不包括目标连接ID长度、源连接ID长度、源连接ID或版本字段.具有短报头的数据包中目标连接ID的长度未在数据包中编码,也不受本规范约束.

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

5.3. 连接ID​

连接ID是任意长度的不透明字段.

连接ID的主要功能是确保较低协议层(UDP、IP及以下)的地址变化不会导致QUIC连接的数据包被传递到错误的QUIC端点.端点和支持它们的中间设备使用连接ID来确保每个QUIC数据包都能传递到端点的正确实例.在端点处,连接ID用于标识数据包所针对的QUIC连接.

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

5.4. 版本​

版本字段包含一个4字节标识符.端点可以使用此值来标识QUIC版本.值为0x00000000的版本字段保留用于版本协商;参见第6节.所有其他值都是潜在有效的.

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

6. 版本协商​

接收到具有长报头和不理解或不支持的版本的数据包的QUIC端点可能会发送版本协商数据包作为响应.具有短报头的数据包不会触发版本协商.

版本协商数据包设置第一个字节的高位,因此符合第5.1节中定义的具有长报头的数据包格式.版本协商数据包可通过版本字段来识别,该字段设置为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:版本协商数据包

只有版本协商数据包的第一个字节的最高有效位具有任何定义的值.标记为"Unused"的其余7位可以在发送时设置为任何值,并且在接收时必须(MUST)被忽略.

在源连接ID字段之后,版本协商数据包包含一个支持版本字段列表,每个字段标识发送数据包的端点支持的一个版本.版本协商数据包不包含其他字段.端点必须(MUST)忽略不包含支持版本字段或包含截断的支持版本值的数据包.

版本协商数据包不使用完整性或机密性保护.特定的QUIC版本可能包括允许端点检测支持版本集中的修改或损坏的协议元素.

端点必须(MUST)在其接收的数据包的源连接ID字段中包含目标连接ID字段的值.源连接ID字段的值必须(MUST)从接收数据包的目标连接ID字段复制,该字段最初由客户端随机选择.回显两个连接ID可以让客户端确信服务器收到了数据包,并且版本协商数据包不是由无法观察数据包的攻击者生成的.

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

有关支持QUIC版本1的端点如何生成和使用版本协商数据包的更详细描述,请参阅 [QUIC-TRANSPORT].

7. 安全和隐私考虑​

中间设备可能会观察特定版本的QUIC的特征,并假设当其他版本的QUIC表现出类似特征时,正在表达相同的底层语义.可能存在许多这样的特征;参见附录A.在QUIC版本1中已经做出了一些努力来消除或模糊一些可观察的特征,但其中许多仍然存在.其他QUIC版本可能会做出不同的设计决策,因此表现出不同的特征.

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

本文档中描述的版本协商数据包不受完整性保护;它只对攻击者的插入有适度的保护.如果端点因此尝试不同的QUIC版本,则必须(MUST)对版本协商数据包的语义内容进行身份验证.

8. 参考文献 (References)​

8.1. 规范性参考文献 (Normative References)​

[RFC2119] Bradner, S., "RFC 中用于指示需求级别的关键词", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC8174] Leiba, B., "RFC 2119 关键词中大写与小写的歧义", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

8.2. 信息性参考文献 (Informative References)​

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "使用 TLS 保护 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, https://www.rfc-editor.org/info/rfc9001.

[QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: 基于 UDP 的多路复用安全传输", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[RFC5116] McGrew, D., "认证加密的接口和算法", RFC 5116, DOI 10.17487/RFC5116, January 2008, https://www.rfc-editor.org/info/rfc5116.

附录A. 错误假设​

QUIC版本1 [QUIC-TRANSPORT] 有几个特征不受观察保护,但仍然被认为在部署新版本时可以更改.

本节列出了基于QUIC版本1知识可能对QUIC做出的一些错误假设的示例.其中一些陈述甚至对QUIC版本1也不成立.这不是详尽的列表;它仅用于说明目的.

以下任何和所有陈述对于给定的QUIC版本都可能是错误的:

  • QUIC使用TLS [QUIC-TLS],并且一些TLS消息在线路上可见.

  • QUIC长报头仅在连接建立期间交换.

  • 给定5元组上的每个流都将包括连接建立阶段.

  • 在流上交换的第一批数据包使用长报头.

  • 长时间静默之前的最后一个数据包可能被假定为仅包含确认.

  • QUIC使用经过身份验证的关联数据加密(AEAD)函数(AEAD_AES_128_GCM;参见 [RFC5116])来保护它在连接建立期间交换的数据包.

  • QUIC数据包号被加密并显示为第一批加密字节.

  • QUIC数据包号对于发送的每个数据包递增1.

  • QUIC对客户端发送的第一个握手数据包有最小大小要求.

  • QUIC规定客户端首先发言.

  • QUIC数据包始终设置第一个字节的第二位(0x40).

  • QUIC版本协商数据包仅由服务器发送.

  • QUIC连接ID很少改变.

  • 如果QUIC端点收到版本协商数据包,它们会更改其使用的版本.

  • QUIC长报头中的版本字段在两个方向上是相同的.

  • 版本字段中具有特定值的QUIC数据包意味着正在使用相应版本的QUIC.

  • 在任何一对QUIC端点之间一次只建立一个连接.