本文是关于如何协商QUIC位的网络规范文档译文，尚未完成翻译，欢迎指正。

本文档描述了一种方法，使用此方法能够协商是否在QUIC数据包中的第二最高有效位上传输任意值。

本文是互联网标准追踪文档。

本文产自互联网工程任务组（IETF），已接受公开审查，并由互联网互联网工程指导委员会（IESG）批准出版。更多互联网标准相关信息详见RFC 7841第2章。

关于本文当前状态、勘误及反馈方式等相关信息请移步https://www.rfc-editor.org/info/rfc9287。

版权所有（c）2022 IETF信托及确认为文档作者的个人。保留所有权利。

本文遵守BCP 78及在本文发布之日起生效的IETF信托涉及IETF文档的法律条文（https://trustee.ietf.org/license-info）。请仔细阅读相关条文，因为其描述了你对本文所有的权利及限制。从本文中摘录的代码组件必须包含信托法律条文第4.e章的简版BSD License文件，并且不附带任何该文件所描述的保证。

在与版本无关的QUIC定义《QUIC不变量》中描述了少量对于并非终端的实体可见的字段。除了那些不可变的特征外，QUIC的“通信线路图象”（wire image， 详见《RFC8546》）几乎是不可见的。

在QUIC版本1中（详见《QUIC》），所有QUIC数据包的首个字节的第二最高有效位被指定为固定值。设定该固定值的目的是为了与允许终端高效地将QUIC从其他协议中区分出来；有关可以利用该属性的系统的描述，详见《DEMUX》。由于能够使用该比特位来辨识数据包是否为QUIC，因此它有时被称为“QUIC位”。

在支持QUIC的终端和中间设备并不要求QUIC位必须是固定值的情况下，在所有数据包中都使用相同的值的做法相比其好处，更多的是一种负担。相反，如果这些系统都依赖着固定值，那么就不可能再定义一个为该比特位添加语义的QUIC版本。

为了保护该比特位将来的用途，本文档定义了一个QUIC传输参数，它能表明终端愿意接收该比特位被设置为其他值的QUIC数据包。通过释放对该比特位的限制，希望能够在将来随时利用该位的值（详见《USE-IT》）。

本文中的关键字“必须（MUST）”、“必须不（MUST NOT）”、“需要（REQUIRED）”、“强烈要求（SHALL）”、“强烈要求不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）”，以及“可选（OPTIONAL）”应理解为BCP 14 《RFC2119》《RFC8174》所描述的，当且仅当它们像本段一样以斜体加粗方式出现的时候。

本文使用了来自《QUIC》的术语和标记上的约定。

传输参数grease_quic_bit（值为0x2ab2）是为QUIC版本1（详见《QUIC》）定义的。客户端和服务器都可以发送该传输参数。发送该传输参数时将值设置为空；理解该传输参数的终端必须将接收到此传输参数且其值为非空的情况视作类型为TRANSPORT_PARAMETER_ERROR（传输参数错误）的连接错误。

宣告传输参数grease_quic_bit的终端必须接受QUIC位被设置为0的数据包。QUIC位的定义是QUIC数据包的首个字节的第二最高有效位（也就是掩码0x40所指示的位）。

从对端接收到传输参数grease_quic_bit的终端应该将QUIC位设置为不可预测的值，除非另一个扩展为该比特位的值指定了特定的含义。

终端可以将所有在接收并处理完传输参数后发送的数据包的QUIC位设置为0。其中可能包括初始数据包、握手数据包和重试数据包。

客户端还可以在从服务器接收到传输参数前就将发送出去的初始数据包、握手数据包或0-RTT数据包的QUIC位设置为0。不过，只有在客户端发送的初始数据包中包含了服务器在新令牌帧（详见《QUIC》的第19.7章）中提供的令牌，且这个帧是在过去604800秒（7天）内，在一条服务器使用了传输参数grease_quic_bit的连接上接收到的时，它才可以这么做。

这个7天的时限容许服务器的配置发生变化。如果服务器改变了配置且客户端没有设置QUIC位，那么服务器有可能丢弃数据包，使得连接失败。

服务器必须仅在处理完来自客户端的传输参数后再将QUIC位设置为0。服务器必须不记忆客户端在先前的连接中协商的扩展，或基于该信息来将QUIC位设置为0。

终端在不了解对端是否支持本扩展的情况下必须不将QUIC位设置为0。由于无状态重置数据包（详见《QUIC》的第10.3章）仅会在连接状态丢失后才被使用，所以终端不太可能在无状态重置数据包中将QUIC位设置为0。

本扩展的目的是允许QUIC位被用于将来的扩展中。

可以在协商传输参数grease_quic_bit的同时协商是否使用为QUIC位定义语义的QUIC扩展。在这种情况下，接收方需要有能力分辨随机值和按照扩展传递信息的值。使用QUIC位的扩展必须在使用值的语义前先协商它们的用途。

例如，某扩展可能定义一个与传输参数grease_quic_bit一起发送的另一个传输参数。尽管对端接收到的数据包中的QUIC位可能一开始是按照扩展定义的规则来设置的，但在发送前它们可能按照本文档的规定经过了随机化。

如果终端接收到了某使用了QUIC位的扩展所定义的传输参数，那么它就能确信对端支持扩展中定义的语义。为了避免对随机值作出反应，扩展可以要求终端按照扩展的规则来设置QUIC位，但是推迟对传递的信息做出反应，直到接收到该扩展定义的传输参数。

可以不使用传输参数grease_quic_bit来协商是否使用为QUIC位定义语义的扩展。然而，同时使用这两种扩展使得QUIC位能在其替代用途不受支持的情况下仍能得到转义。

本文档为终端或依赖终端协作的实体引入新的安全风险。然而，该变更使得分辨QUIC的任务在没有终端协作的情况下变得更加困难。这有时与网络运营商依靠网络分类来识别威胁的安全目标背道而驰；有关此话题更全面的分析，详见《QUIC可管理性》的第3.1章。

本文档在《QUIC》的第22.3章定义的注册表《QUIC传输参数》中注册了传输参数grease_quic_bit。注册字段如下：

值：

0x2ab2

参数名称：

grease_quic_bit

状态：

永久

规范：

RFC 9287

日期：

2022-07-13

更改责任人：

IETF (iesg@ietf.org)

联系方式：

QUIC工作组 (quic@ietf.org)

备注：

（无）

Martin Thomson

Mozilla

Email: mt@lowentropy.net

译

• Yunzhe

  • Email: yunzhe@zju.edu.cn

• ruokeqx

  • Email: ruokeqx@163.com

• 方秋航

  • Email: fangqiuhang@163.com