本文是关于QUIC版本协商机制的更新文档译文，尚未完成翻译，欢迎指正。

QUIC没有提供一个完整的版本协商机制，仅仅给服务端提供了一种方式用以声明客户端选择的版本是不可接受的。本文描述了一种版本协商机制，使得客户端和服务端能够选择一个相互都能支持的版本。可选地，如果客户端选择的版本及协商的版本具有兼容的首飞格式（first flight format），协商者可以立即生效而不需要再等一个往返。本网是对RFC 8999的更新。

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

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

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

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

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

QUIC的版本不变属性^{《QUIC版本通用属性》}定义了版本协商包，但是没有指定终端收到该类包后该如何响应。QUIC版本1^{《QUIC传输协议》}允许服务端使用版本协商包指出客户端选择的版本是不可接受的，但是其没有允许客户端安全地通过该信息使用一个双端支持的版本创建新的连接。本文通过为版本协商包定义版本协商机制，更新《QUIC版本通用属性》。

有着合适且安全的机制，版本协商包可以成为该机制的一部分，从而使得两个QUIC实现得以在两个完全不相关的QUIC版本之间进行协商。本文使用版本协商包指定版本协商，如果需要的话其会在连接建立期间增加一个额外的往返。

尽可能避免额外的往返延迟是有利的，尤其是假设大多数新增版本与先前版本是广泛相似的。本规范也定义了一种简单版本协商机制，其为各个版本赋能相似性，且可以在“兼容的”协商之间协商而不需要额外的往返延迟。

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

本文使用了下述术语：

• 在指定QUIC连接上下文中，包的“首飞（first flight）”指的是客户端在其收到服务端回包前创建并发送的用来初始化连接的所有包。
• 在给定QUIC连接上下文中，“客户端选择版本（client’s Chosen Version）”是连接首飞使用的QUIC版本。
• “初始版本（Original Version）”是客户端发给服务端的最初第一个包的QUIC版本。 如果版本协商跨越多个连接（详见第2.4章），初始版本等于第一个QUIC连接的客户端选择版本。
• “协商版本（Negotiated Version）”是版本协商过程一经完成后连接使用的QUIC版本。
• “最大段生命周期”（MSL，Maximum Segment Lifetime）表示QUIC包可以在网络上生存的时间。 实现可以将其置为可配置的，并且推荐值是1分钟。 注意，这里的“段（segment）”概念源自《TCP》第3.4.1章。

本文指出了两个版本协商的结果：1、“不兼容的”，需要一个额外的往返且适用于所有版本，以及2、“兼容的”，可以保留一个往返但是只适用于兼容的版本之间（详见第2.2章）。

客户端通过选择一个初始版本，发送长包头的首飞QUIC包给服务端，以初始化QUIC连接^{《QUIC版本通用属性》}。客户端的首飞包括版本信息（详见第3章），将被用于可选地开启兼容的版本协商（详见第2.3章），且阻止版本降级攻击（详见第4章）。

在收到首飞后，服务端检验其是否知道如何从选择版本（此种场景下也即初始版本）解析首飞包。如果其不能解析，则启动不兼容的版本协商（详见第2.1章），这会导致客户端使用另一个版本初始化一条新连接。例如，如果客户端使用服务端不能解析的版本A初始化一条连接，服务端启动不兼容版本协商；然后，客户端使用版本B初始化一条连接，则说第一条连接的客户端选择版本是A，第二条连接的客户端选择版本是B，而整个过程的初始版本是A。

如果服务端可以解析首飞，则它可以使用客户端选择版本建立连接，也可以选择其他兼容的版本，详见第2.3章。

注意，服务端也可能有能力解析首飞，即使其无法完整支持给定的版本，其在解析首飞以进行版本确认方面的实现是足够的，但是不足以完整地使用相应版本建立连接。

服务端通过发送版本协商包启动非兼容版本协商。该包强烈要求在一个支持版本字段（Supported Version filed）中包含来自服务端提供版本（详见第5章）集合的每个入口。服务端可以往支持版本字段中添加保留版本（如《QUIC传输协议》第6.3章所述）。

如果版本协商包包含客户端提供的初始版本，客户端可将忽略该包，如第4章所述。客户端也会忽略保护不正确连接ID字段的版本协商包，如《QUIC版本通用属性》第6章所述。

在收到版本协商包后，客户端强烈要求在服务端提供的列表中搜索一个其支持的版本。如果没有找到这样的版本，其强烈要求中止连接尝试。否则，其强烈要求选择一个相互支持的版本并以该版本发送一个新的首飞——该版本就是当前的协商版本。

新的首飞将允许终端使用协商版本创建连接。协商版本的握手将交换版本信息（详见第3章），用于确保版本协商的真实性，也即没有攻击者为了影响版本协商过程中途注入数据包（详见第4章）。

只有服务端可以发起非兼容版本协商。客户端必须不能发送版本协商包，且服务端必须忽略所有收到的版本协商包。

如果A、B是两个不同的QUIC版本，A是所谓“兼容”B的，如果其可以识别版本A的首飞包，并将其转换为版本B的首飞包。例如，如果版本A和B在握手期间的链路镜像及行为上是绝对一致的，但是在握手后不一致，那么A是兼容B的且B也兼容A。注意，对首飞的转换可能是有损耗的；一些数据，例如QUIC版本1的0-RTT包，可能在转换及随后的重传时被忽略。

版本兼容性不是对称的。存在版本A兼容版本B但是版本B不兼容版本A的情况。这可能发生在，例如，如果版本B是版本A的一个严格超集，也即，如果版本A包含流及流帧的概念，而版本B包含流及假定的连同流帧及管道帧的管道概念，那么A兼容B，但是B不兼容A。

注意版本兼容性并不意味着首飞的任何单独可能的实例都将成功转换到其他版本。如果满足两个条件，则称使用版本A的首飞“兼容”版本B：1、版本A兼容版本B且，2、其定义了首飞对版本B的转换。例如，如果版本B除了在首飞中引入的版本A不能解析或会忽略的新帧之外其他所有方面与版本A一致，则版本B可能仍然兼容版本A，因为转换对于该帧不被使用的连接可能成功。在该例中，使用版本B的首飞所携带的该新帧不兼容版本A。

当定义一个新的QUIC版本时，一般假设其不兼容任何其他版本，除非额外指定。同样地，没有其他版本兼容该新版本除非额外指定。QUIC实现必须不能假设不同版本之间是兼容的，除非额外指定。

注意双端可能对两个版本是否兼容持相反意见。例如，两个版本可能同时被定义，但是却在很久后的第三份文档中被定义为兼容的——在那种场景下，一端可能注意到了该兼容性稳定，而另一端则没有。

当服务端可以使用客户端选择的版本解析客户端的首飞，则其能够解出客户端的版本信息结构（详见第3章）。这包含客户端所知道的其所兼容的版本的列表。

为了执行兼容版本协商，服务端必须选择其中一个版本：（1）支持，且（2）知道兼容客户端选择版本。这个选择的版本就是当前的协商版本。完成选择后，服务端试图将客户端首飞信息转换成该版本并回复客户端，正如其收到的转换后的首飞。

如果这些格式是完全相同的，就像协商版本与客户端选择版本一致那样，那么这将是恒等转换。如果首飞是正确格式，那么这个转换过程不能通过对兼容的首飞进行定义而失败；如果服务端不能转换该首飞，其必须中断握手。

如果一份文档确定了一个QUIC版本，其兼容另一个版本，该文档必须确定使客户端知晓协商版本的机制。这样的机制的一个例子是，客户端通过验证QUIC长包头版本字段确认服务端的协商版本。注意，在这个示例机制中，对于服务端而言在切换到协商版本前（这可能发生在客户端版本信息结构跨越多个数据包的时候；在这种情况下，服务端可能确认了包括客户端选择版本的首包及其后切换到一个不同的协商版本的数据包）使用客户端选择的版本发送初始包是可行的。相互兼容的版本应该使用相同的机制。

注意，在首飞转换成协商版本后，握手以协商版本结束。如果协商版本在握手过程中有什么要求，这些要求将适用于整个握手过程，包括转化后的首飞。特别是，如果协商版本要求终端验证握手包，终端必须对转化后的首飞也进行同等验证。例如，如果协商版本要求五元组保持稳定（正如QUIC版本1所要求的），那么终端两侧需要验证握手期间收到的所有包的五元组，包括转化后的首飞。

注意客户端也可以通过只在版本信息字段可用版本中包含选定版本来禁止兼容版本协商（详见第3章）。

如果服务端没有找到一个兼容版本（包括客户端选择的版本），其将转而执行不兼容版本协商（详见第2.1章）。

注意可能先发生不兼容版本协商后，再紧随着发生兼容版本协商。例如，如果版本A兼容版本B且版本C兼容版本D，下述情况可能发生：

TODO：重新作图

客户端                                  服务端

选择版本 = A, 可选版本 = (A, B) ------------->
<------------------------ 版本协商 = (D, C)

选择版本 = C, 可选版本 = (C, D) ------------->
<------------- 选择版本 = D, 可选版本 = (D, C)

图1：组合协商图

在这个示例中，客户端从服务端版本协商包中选择版本C，但是服务端倾向于版本D，并从客户端提供的选项中选择了D。

QUIC连接在客户端与服务端之间共享状态^{《QUIC版本不变属性》}。本文定义的兼容版本协商机制（详见第2.3章）作为一条QUIC连接的一部分执行，也就是说，客户端选择版本数据包与协商版本的数据包一样，都属于同一条连接。

作为对比，不兼容版本协商机制，通过利用QUIC版本协商包（详见第2.1章），在概念上跨越两条QUIC连接执行操作。也就是说，收到版本协商包之前的建联尝试，与随后采用不兼容版本的连接是不同的。

注意，这种跨越两个连接的区分是概念上的，也就是说，其仅适用于QUIC的规范需求，但是不需要在实现上使用两个不同的连接实体。

当客户端选择其原始版本时，其应该尝试避免不兼容版本协商，从而节约一个往返时间。因此，客户端应该选择一个能最大化下述两者的组合概率：

• 服务端知道如何从初始版本解析首飞，而且
• 初始版本兼容客户端首选的版本。

若缺乏更多信息，可能意味着选择客户端支持的最老的版本，并在客户端首飞中推荐较新的兼容版本。

握手期间，终端将交换版本信息（Version Information），包括一个选定版本及一系列可选版本。任何支持该机制的QUIC版本必须提供一个能够在握手期间双向交换版本信息的机制，并确保该数据得到认证。

在QUIC版本1中，版本信息通过一个version_information（版本信息）传输参数（详见《QUIC传输协议》第7.4章）。版本信息内容如下（使用《QUIC传输协议》第1.3章所述表示法表示）：

版本信息 {
  选定版本 (32),
  可选版本 (32) ...,
}

图2：版本信息格式

各个字段内容描述如下：

选定版本（Chosen Version）：

发送端为连接选择的版本。在大多数情况下，该字段的值等于承载该段数据的长包头中版本字段的值。但是，未来的版本或扩展可以选择在长包头的版本字段设置不同的值。

可选版本字段的内容基于其发送端是客户端还是服务端。

客户端发送的可选版本（Client-Sent Available Versions）：

当由客户端发送的时候，可选版本字段列出所有该首飞兼容的版本，并按降序排列。注意，该列表中必须包含选定版本字段中的版本，使得客户端得以表明偏好该选定版本；且该偏好仅供参考，服务端可以选择自身偏好的版本取代。

服务端发送的可选版本（Server-Sent Available Versions）：

当由服务端发送的时候，可选版本字段列出所有当前服务端完整部署的版本（Fully Deployed Versions，详见第5章）。该字段列出的版本在排序上不具有任何涵义。注意，选定版本字段中的版本不要求必须包含在该列表中，因为服务端操作者可能正在移除对该版本的支持。基于同样的原因，可选版本字段可以为空。

客户端和服务端都可以在其可选版本列表中包含0x?a?a?a?a格式的版本。这些版本用于测试版本协商（详见《QUIC传输协议》第15章），且永远不会被用于连接。

版本降级是一种由恶意实体设法使QUIC终端协商出的版本不同于其在不受该攻击情况下协商得到的版本的攻击。本文描述的机制是为了防范降级攻击而设计的。

客户端必须忽略任何包含初始版本的版本协商包。试图基于从版本协商包得到的信息创建新的连接的客户端必须忽略所有其收到的用于回应该连接的版本协商包。

握手期间，双端必须解析对端发送的版本信息。如果解析失败（例如，版本信息太短或其长度不能被4整除），终端必须关闭连接；如果连接使用QUIC版本1，必须使用类型为TRANSPORT_PARAMETER_ERROR（传输参数错误）的传输错误关闭连接。如果终端收到的选定版本为零，或任何可选版本为零，必须视为解析错误。如果服务端收到的版本信息中的可选版本不包含选定版本，也必须视为解析错误。

任何支持版本协商的QUIC版本必须定义一种以版本协商错误关闭连接的。对于QUIC版本1，版本协商错误通过VERSION_NEGOTIATION_ERROR类型传输错误（详见第10.2章）进行标识。

当服务端收到客户端的首飞，服务端将首先确定该连接使用的QUIC版本，从而正确解析首飞。这可能涉及检查握手记录之外的数据，例如部分包头。当服务端解析完客户端的版本信息时，必须校验客户端选定版本是否与连接当前使用版本一致。如果两者不一致，服务端必须以版本协商错误为由关闭连接。

在QUIC版本1的特定情况下，服务端通过观察其收到的首个长包头包的版本字段值为0x00000001从而确认当前连接使用的是QUIC版本1。接下来，如果服务端通过QUIC版本1连接收到客户端的版本信息（通过长包头包版本字段携带的传输参数）中客户端的选定版本未设置为0x00000001，服务端必须以版本协商错误关闭连接。

即使版本信息缺失，服务端也可以完成握手。如果客户端处理版本协商包时缺少版本信息，那么其必须不能完成握手，但是在其他情况下是可以的。

如果客户端收到的版本信息中服务端的选定版本不在客户端发送的可选版本中，那么客户端必须以版本协商错误关闭连接。如果客户端处理了版本协商包而其中缺乏版本信息，那么客户端必须以版本协商错误关闭连接。

如果客户端收到且执行了版本协商包，那么客户端必须验证服务端的可选版本字段。验证可选版本字段通过确认如果客户端知道服务端支持的版本，则其将尝试同样的版本。就是说，如果已经收到版本协商包，其中列出了服务端可选版本字段支持的版本，包括协商版本，则客户端将选择相同的版本。如果客户端将选择不同的版本，则其必须以版本协商错误关闭连接。特别是，如果客户端处理版本协商包时发现服务端的可选版本字段是空的，则其必须以版本协商错误关闭连接。这些连接关闭使得攻击者不能使用伪造的版本协商包强制版本降级。

例如，假设客户端支持QUIC版本10、12和14，并优先支持较高的版本。客户端以版本12发起建联尝试。接下来探讨两个独立的示例场景：

• 在第一个场景中，服务端支持版本10、13和14，但是只有版本13和14是完整部署的（详见第2章）。服务端发送了携带版本10、13和14的版本协商包。触发了一个非兼容版本协商，且客户端以创建了基于版本14的新连接。然后，服务端的可选版本字段包含13和14。在该场景中，如果客户端收到了包含版本10、13和14的版本协商包，客户端仍然会选择版本14；因此，握手以版本14成功完成。

• 在第二个场景中，服务端支持版本10、13和14，且它们都进行了完整部署。然而，攻击者伪造包含版本10和13的版本协商包。触发了一个非兼容版本协商，且客户端以创建了基于版本10的新连接。然后，服务端的可选版本字段包含版本10、13和14。在该场景中，如果客户端收到了包含版本10、13和14的版本协商包，客户端会选择版本14；因此，客户端以版本协商错误中止握手过程。

这种对可选版本的验证不足以防范降级攻击。防范降级攻击还需要客户端忽略包含原始版本的版本协商包（详见第2.1章）。

在本文描述的版本协商过程完成后，连接使用的版本将是服务端在其版本信息的选定版本字段中提供的版本。即使在连接生命周期中任何时刻有其他长包头的版本字段使用过其他的版本，这一点也是成立的。特别是，由于客户端可能通过QUIC长包头关注着兼容版本协商期间的协商版本（详见第2.3章），客户端必须验证服务端的选定版本是否等于协商版本；如果两者不一致，客户端必须以版本协商错误关闭连接。这阻止了攻击者通过伪造长包头的版本字段影响版本协商。

虽然本文主要讨论单个QUIC服务端，但是QUIC服务端实际部署中通常会包含多个服务器实例构成的服务器集群。因此，本文定义了下述术语：

可接受版本（Acceptable Versions）：

这是给定的服务端实例支持的QUIC版本的集合。更具体来说就是，如果客户端使用这些版本发起首飞，它们是服务端实例实际会选择的版本。

提供版本（Offered Versions）：

这是给定的服务端实例在收到未知版本的首飞后，会在发送的版本协商包中列出的版本集合。该集合更有可能等于可接受版本集合，除开添加或删除版本时短暂过渡期间（见下）。

完整部署版本（Fully Deployed Versions）：

这是在该服务端部署中每个QUIC服务端实例都支持且能够协商的版本集合。如果服务端部署只包含一个服务器实例，那么该集合等于提供版本集合，除开添加或删除版本时短暂过渡期间（见下）。

如果服务端部署包含多个实例，软件更新可能无法确保在所有服务器实例上同时进行。因此，客户端可能收到已经升级的服务器实例发来的版本协商包，发起建联尝试的对象却是另一个尚未更新的服务器实例。

然而，即使只有一个实例，如果服务端在版本协商包在飞时执行软件更新，客户端仍然会收到一个过时的版本协商包。

这可能导致第4章描述的版本降级防范机制错误地判断为降级攻击。为了避免这种情况，当服务端希望添加或删除对某个版本的支持的时候，其应该执行三步过程，如下所述。

当添加对一个新版本的支持时：

• 第一步是逐步给所有服务器实例增加对新版本的支持。这一步更新接受版本但是不更新提供版本及完整部署版本。一旦所有服务器实例更新完毕，操作者至少等待一个MSL，以确保任何在飞的版本协商包都有时间到达。

• 然后，第二步是逐渐将新版本纳入所有服务器实例的提供版本中。这一步做完后，操作者至少再等待一个MSL。

• 最后，第三步是逐步将心版本添加到所有服务器实例的完整部署版本中。

当移除对一个版本的支持时：

• 第一步是逐步从所有服务器实例的完整部署版本中移除该版本。一旦移除完成，操作者等待至少一个MSL以准许任何在飞版本协商包到达。

• 然后，第二步是逐步从所有服务器实例的提供版本中移除该版本。一旦完成，操作者再等待至少一个MSL。

• 最后，第三步是逐步从所有服务器实例中移除对该版本的支持。这一步将更新接受版本。

注意，在更新的窗口期，连接极易由于接受版本没有得到完整部署而受到版本降级攻击。这是因为客户端不能辨别降级攻击与更新前及更新后的服务端实例之间的合法信息交换。

客户端创建QUIC连接是为了使用应用层协议。因此，在考虑哪些版本兼容时，客户端只会考虑那些支持其预定使用的其中一个应用层协议的版本。如果客户端首飞推荐了多个应用层协议协商（ALPN^《ALPN》）令牌及多个兼容版本，那么可能存在某些应用层协议无法在所提供的兼容版本上运行。服务端负责选择一个且只选择一个可以运行选定的兼容QUIC版本的ALPN令牌。

给定ALPN令牌必须不能用于其最初定义的QUIC版本之外其他新的QUIC版本，除非满足下述所有要求：

• 新QUIC版本支持该应用层协议所需的传输特性；
• 新QUIC版本支持ALPN；
• 新QUIC版本兼容ALPN令牌最初定义的QUIC版本。

当使用不兼容版本协商时，为响应收到的版本协商数据包而创建的第二个连接必须重启其应用层协议协商进程，且忽略初始版本。

为了方便未来部署新的QUIC版本，未来QUIC版本的设计者应该尝试设计使其新版本兼容已部署的QUIC版本兼容。

QUIC版本1定义了多种QUIC不变量中没有指明的特性。因为在撰写本文时，QUIC版本1已经广泛部署，本章讨论设计未来版本时的注意事项，帮助其兼容QUIC版本1。

QUIC版本1中的重试数据包特性使得服务端可以在解析客户端首飞前发送该包验证客户端IP。服务端可以先发送重试数据包，再解析客户端首飞。因此，发送重试数据包时，服务端可能尚未处理客户端的版本信息。

如果未来文档希望定义两个版本之间对重试包支持的兼容性，该文档必须指定握手期间两个版本都需要的版本协商机制（包括兼容的和不兼容的）如何与重试包进行交互。例如，可以通过让服务端先用初始版本发送一个重试数据包，从而在尝试兼容版本协商之前验证客户端IP地址。如果两个版本都支持认证重试数据包，则两者之间的兼容性还需要定义如何认证协商版本握手过程中的重试包，即使该重试包本身是使用客户端选择版本发送的。

QUIC版本1使用TLS 1.3，通过在一条连接中发送可供后续连接使用的会话票据（session ticket，详见《TLS》第2.2章）从而实现连接复用。当新版本也使用TLS 1.3时，其应该确保其会话票据只能用于同一QUIC版本，客户端不能跨版本使用，且要求服务端验证客户端的请求。这有助于缓解跨协议攻击。

QUIC版本1允许客户端在握手期间通过0-RTT数据包向服务器发送数据。如果未来文档希望定义支持0-RTT的两个版本之间的兼容性，该文档必须处理客户端首飞中存在0-RTT包的场景。例如，可以通过定义对0-RTT数据包应用哪些转换来实现。该文档可以指定通过兼容版本协商导致服务器拒绝0-RTT数据。

因为QUIC版本1是本文发布前唯一以IETF标准发布的QUIC协议，所以它被特殊处理如下：如果客户端正在发起一条QUIC版本1的连接响应接收到的版本协商包，且服务端的传输参数中缺失version_information参数，那么客户端强烈要求假定服务端传输参数包含version_information字段且其中包含值为0x00000001的选定版本以及包含版本集中恰好由0x00000001组成的可选版本列表。从而得以与只支持QUIC版本1的服务端进行版本协商。注意，希望通过版本协商来协商除QUIC版本1之外的版本的QUIC实现必须实现本文定义的版本协商机制。

本版本协商机制的安全性依赖于认证握手期间交换的版本信息。在QUIC版本1中，传输参数是经过认证的，从而确保了该机制的安全性。兼容版本之间的协商将具有最弱公共版本的安全性。

要求假设版本不兼容能够降低跨协议攻击的可能性，但是仍需做进一步分析。该分析超出了本文范畴。

IANA已经注册了下述“QUIC传输参数（QUIC Transport Parameters）”，由https://www.iana.org/assignments/quic维护。

IANA已经注册了下述“QUIC传输错误码（QUIC Transport Error Codes）”，由https://www.iana.org/assignments/quic维护。

感谢Nick Banks、Mike Bishop、Martin Duke、Ryan Hamilton、Roberto Peon、Anthony Rossi及Martin Thomson的投入和贡献！

David Schinazi

美国加州山景城94043圆形剧场公园路1600号谷歌公司

Email: dschinazi.ietf@gmail.com

Eric Rescorla

Mozilla

Email: ekr@rtfm.com

译

• 方秋航
  • Email: fangqiuhang@163.com