QUIC-LB: 生成可路由QUIC连接ID ( draft-ietf-quic-load-balancers-02)

最新推荐文章于 2023-12-23 20:23:58 发布

aashuii

最新推荐文章于 2023-12-23 20:23:58 发布

阅读量1.4k

点赞数 2

分类专栏： quic 文章标签：算法分布式

本文链接：https://blog.csdn.net/aashuii/article/details/105537151

版权

quic 专栏收录该内容

13 篇文章 5 订阅

订阅专栏

QUIC M. Duke
Internet-Draft F5 Networks, Inc.
目的状态: 标准跟踪 N. Banks
到期日: 10, 2020.9.10 Microsoft
March 9, 2020

QUIC-LB: 生成可路由QUIC连接ID draft-ietf-quic-load-balancers-02

摘要

QUIC连接ID保证地址端口四元组变化情况下的连续性，可以为无状态或低状态负载均衡器存储路由信息。它们还可以通过客户端服务器之间使用受保护的通信来防止主动地址迁移链接的被关联。这为负载均衡中间件带来了问题。本规范对给定一组配置参数的路由信息编码方法进行了标准化。该框架还允许将其他QUIC功能卸载到可信的中间件，前提是QUIC服务器要进行明确的合作。

介绍 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 术语 . . . . . . . . . . . . . . . . . . . . . . . 4
协议的目标 . . . . . . . . . . . . . . . . . . . . . 5
2.1. 简单化 . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. 安全性 . . . . . . . . . . . . . . . . . . . . . . . . 5
第一个CID octet . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. 配置循环（Rotation） . . . . . . . . . . . . . . . . . . . . . 6
3.2. 配置回滚 . . . . . . . . . . . . . . . . . 6
3.3. 长度自描述. . . . . . . . . . . . . . . . . 7
路由算法 . . . . . . . . . . . . . . . . . . . . . 7
4.1. 明文CID 算法. . . . . . . . . . . . . . . . . 8
4.1.1. 配置代理行为 . . . . . . . . . . . . . 8
4.1.2. 负载平衡器行为 . . . . . . . . . . . . . . . . 9
4.1.3. 服务器行为 . . . . . . . . . . . . . . . . . . . 9
4.2. 混淆CID算法 . . . . . . . . . . . . . . . . 9
4.2.1. 配置代理行为 . . . . . . . . . . . . . 9
4.2.2. 负载平衡器行为 . . . . . . . . . . . . . . . . 10
4.2.3. 服务器行为 . . . . . . . . . . . . . . . . . . . 10
4.3. 流加密CID算法 . . . . . . . . . . . . . . . 10
4.3.1. 配置代理 . . . . . . . . . . . . . 11
4.3.2. 负载均衡器 . . . . . . . . . . . . . . . . 11
4.3.3. 服务器 . . . . . . . . . . . . . . . . . . . 12
4.4. 分组密码CID算法 . . . . . . . . . . . . . . . 12
4.4.1. 配置代理 . . . . . . . . . . . . . 12
4.4.2. 负载均衡器 . . . . . . . . . . . . . . . . 13
4.4.3. 服务器 . . . . . . . . . . . . . . . . . . . 13
重试服务 . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. 一般要求. . . . . . . . . . . . . . . . . . . 14
5.2. 无共享状态重试服务 . . . . . . . . . . . . . . 14
5.2.1. 配置代理行为 . . . . . . . . . . . . . 14
5.2.2. 服务要求 . . . . . . . . . . . . . . . . 15
5.2.3. 服务器要求 . . . . . . . . . . . . . . . . . 16
5.3. 共享状态重试服务 . . . . . . . . . . . . . . . 17
5.3.1. 配置代理行为 . . . . . . . . . . . . . 18
5.3.2. 服务要求 . . . . . . . . . . . . . . . . 18
5.3.3. 服务器要求 . . . . . . . . . . . . . . . . . 18
配置要求 . . . . . . . . . . . . . . . . . 19
额外用例 . . . . . . . . . . . . . . . . . . . . 20
7.1. 负载均衡器链 . . . . . . . . . . . . . . . . . . 20
7.2. 在服务器间移动链接 . . . . . . . . . . . 21
安全考虑 . . . . . . . . . . . . . . . . . . . 21
8.1. 攻击者不在负载平衡器和服务器中间 . . . 21
8.2. 攻击者在负载平衡器和服务器中间 . . . . . 22
IANA 考虑 . . . . . . . . . . . . . . . . . . . . . 22
参考 . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. 引用标准 . . . . . . . . . . . . . . . . . . 22
10.2. 参考资料 . . . . . . . . . . . . . . . . . 22
附录A. 负载均衡器测试指引 . . . . . . . . . . . . . 22
A.1. 模糊连接ID算法 . . . . . . . . . . . 23
A.2. 流加密连接ID算法 . . . . . . . . . . 24
A.3. 快加密连接ID算法 . . . . . . . . . . 25
附录 B. 致谢 . . . . . . . . . . . . . . . . . . 26
附录 C. 变化日志 . . . . . . . . . . . . . . . . . . . . . 26
C.1. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 26
C.2. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 26
C.3. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 26
C.4. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 26
C.5. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 26
C.6. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 27
C.7. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 27
C.8. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 27
C.9. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 27
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 27

1. 介绍

QUIC包[QUIC-TRANSPORT]一般包含一个链接来联系具有不同四元组的同一个链接上下文。这个特性使得NAT重绑定后链接依然健壮。QUIC终端通常指定连接ID，对端使用该ID来寻址数据包。服务器生成连接ID产生了支持QUIC带外通信的潜在需求。

QUIC允许服务器(或负载平衡器)指定一个初始连接ID来为负载平衡器编码有用的路由信息。它还鼓励服务器(在加密保护的包中)向客户端提供额外的连接ID。这允许将要更改IP地址或端口的客户端在新路径上使用单独的连接ID，从而降低了客户端满世界移动时的可关联性。
在提供路由信息和降低可关联性的需求之间存在着紧张关系。由于新的连接ID在受保护的包中，如果负载平衡器不能访问连接密钥，则必须在服务器上生成。但是，负载均衡器具有生成连接ID所需的上下文，该连接ID对有用的路由信息进行编码。在负载均衡器和服务器之间不存在任何共享状态的情况下，负载均衡器必须维护一个相对昂贵的服务器生成的连接ID表，如果它们使用的连接ID最初是在受保护的NEW_CONNECTION_ID帧中通告的，那么负载均衡器不能正确地路由包。
本规范提供了在给定一些共享参数的连接ID中对服务器映射进行编码的通用算法。通常只有具有参数的观察者才能发现映射，尽可能保持不可关联性。
除负载均衡外，QUIC服务器可能还希望将其他协议功能卸载给可信的中间件。这些中间件可能包括服务器主机本身的硬件辅助，不需要完全解密QUIC包。例如，本文指定了一种卸载无状态重试以对抗拒绝服务攻击的方法。提出了一种对所有数据包中连接ID长度进行自编码的系统，使密码卸载能够一致地查找密钥信息。
虽然本文描述了一小组配置参数用来使服务器映射变得可理解，但是在负载均衡器、服务器和其他受信任的中间件之间分配这些参数的方法超出了本文的范围。有许著名的配置分发基础设施。

1.1. 术语

本文中，除非另有说明，“客户端”和“服务器”指QUIC连接的端点。“负载均衡器”是不具有QUIC连接密钥的连接中间件，但它可以重写IP地址或进行其他IP或UDP处理。请注意，通过终止与客户端的QUIC连接，然后使用QUIC或其他协议从服务器检索数据，作为代理的有状态负载均衡器被视为与此规范相关的服务器。

2. 协议目标

2.1. 简单化

QUIC旨在提供跨连接迁移的不可关联性，但是服务器不需要提供额外的连接ID来有效地防止关联。如果协作方案难以实现，使用连接ID进行路由的负载均衡器背后的服务器将使用可关联的连接ID。因此，客户将被迫在迁移期间终止连接或保持可关联之间进行选择，从而破坏了QUIC的设计目标。
解决方案应该既易于实现，又不需要额外的加密密钥基础设施等。

2.2. 安全

在到服务器池的连接很少的限制条件下，任何方案都无法阻止两个连接ID的高概率关联。相反的限制是，所有服务器都有许多频繁启动和结束的连接，即使知道两个连接ID映射到同一个服务器，也很难将它们关联起来。
QUIC-LB与这两极之间的区域相关：当两个连接ID映射到同一服务器的信息有助于关联两个连接ID时。显然，任何将这种映射透明地传递给外部观察者的方案都会损害QUIC对可关联的防御。
虽然QUIC-LB设计没有明确的目标，但是隐藏服务器映射也会使集中攻击池中特定服务器的尝试变得复杂。

3. CID第一个八位

一个连接ID的前八位是为两个特殊目的而保留的，一个是强制性的(配置rotation)，另一个是可选的(长度自描述)。
本文的后续部分将这个octet的内容称为“第一个八位”。

3.1. 配置Rotation

任何连接ID的前两位必须编码该ID的配置区段。QUIC-LB消息表示它们编码的算法的区段和参数。
新配置可能更改旧配置的一个或多个参数，或更改使用的算法。
服务器可能具有相互排斥的支持算法集，或者从一种算法过渡到另一种算法，从而导致有效负载失败。这两位中编码的四个状态允许两个互斥的服务器池共存，并且每个服务器池都可以转换到一组新的参数。
当新配置被分发到服务器时，将会有一个过渡期，在此期间，旧配置和新配置产生的连接ID将在网络中共存。rotation位允许负载均衡器将正确的路由算法和参数应用到传入的包。
服务器在为新配置发送Ack有效负载后，不能使用旧配置生成新连接ID。
负载均衡器不应该使用codepoint来表示新配置，直到它采取预防措施以确保使用该codepoint上的旧配置的ID的所有连接都已关闭或转换。他们可能会在一段合理的时间间隔后删除旧配置的连接ID，以加速此过程。

3.2. 配置回滚

如果服务器没有收到有效的QUIC-LB配置，并且认为路径上存在低状态、感知连接ID的负载均衡器，那么它应该生成配置rotation位设置为‘11’的连接ID，并且应该在所有新的QUIC连接中使用“disable_migration”传输参数。不能发送带有新值的NEW_CONNECTION_ID帧。
一个负载均衡器看到一个配置rotation位设置为’11’的连接ID必须恢复到5元组路由。

3.3. 长度自描述

本地硬件密码卸载设备可能通过接收索引到连接ID的QUIC密钥来加速服务器。但是，在操作多个QUIC服务器的物理设备上，如果连接ID没有对其自身长度进行自编码，那么高效地查找这些密钥是不切实际的。
注意，这是特定服务器设备的功能，与负载均衡器无关。因此，负载均衡器可能会在其配置中忽略这一点。但是，连接ID的第一个八位中的其余6位保留下来表示接下来的连接ID的长度，不包括第一个八位。
不使用此功能的服务器应该使这6位看起来是随机的。

4. 路由算法

在QUIC-LB中，负载均衡器不会生成到服务器的连接ID。相反，它们通过协商算法的参数来生成可路由的连接ID。
这些算法在负载均衡器和服务器上的配置复杂性有所不同。增加复杂性可以改进服务器映射的模糊。
由于客户端有时会在长报头中生成DCID，因可能不符合路由算法的期望。这些被称为“不兼容DCID”:
o DCID可能不够长，路由算法无法处理。
o 提取服务器映射可能不对应于活动服务器。
o 一个字段在解密后应该都是0，但可能不是这样。

负载均衡器必须使用自己选择的算法将长报头和不兼容的DCID的包转发到活动服务器。它不需要与服务器协调此算法。算法应该在短时间内是确定的，这样相关的包就可以到达相同的服务器。例如，一个不兼容的DCID可能被转换成一个整数，然后除以服务器的数量，用模数来转发数据包。服务器的数量在QUIC连接握手的时间尺度上通常是一致的。
负载平衡器应该在短报头中删除包含不兼容DCID的包。负载平衡器必须根据所选的路由算法，将带有符合DCID的包转发到服务器。
负载均衡器不能使路由行为依赖于QUIC包报头的前八位中的任何位，除非第一个位表示一个长报头。所有其他的位都是依赖于QUIC版本的，并且中间件不能在特定于版本的模板上构建它们的设计。
在某些情况下，服务器池可能同时运行两个或多个路由算法或参数集。负载均衡器使用连接ID的前两位通过这些方案来复用传入的DCID。
本节描述三个参与者:配置代理、负载均衡器和服务器。

4.1. 明文CID算法

明文CID算法没有试图掩盖连接到服务器的映射，显著提高了可关联性。格式如图所示：

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  First octet  |             Server ID (X=8..152)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Any (0..152-X)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1: 明文CID格式

4.1.1. 配置代理行为

配置代理选择服务器连接ID (SCID)的若干字节来编码各个服务器ID，称为“路由字节”。字节数必须具有足够的熵，以使每个服务器具有不同的码点。
它还为每个服务器分配一个服务器ID。

4.1.2. 负载平衡器行为

在每个传入的数据包上，负载均衡器会提取从第二个八位开始的连续字节。这些字节代表服务器的ID。

4.1.3. 服务器行为

服务器选择连接ID长度。这个长度必须比路由字节至少长一个字节。
当服务器需要一个新的连接ID时，它会将其分配的服务器ID编码为从第二个字节开始的连续字节。连接ID中的所有其他位，除了第一个八位字节外，都可以设置为任何其他值。这些其他位在观察者看来应该是随机的。

4.2. 模糊CID算法

模糊CID算法试图在不需要真正的加密和解密的情况下，对连接到服务器的映射进行模糊化处理，以降低关联性。其格式如下图所示：

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  First octet  |  Mixed routing and non-routing bits (64..152) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: 模糊CID格式

4.2.1. 配置代理行为

配置代理选择一组任意的服务器连接ID（SCID）的位，用来路由到指定的服务器，称为 “路由位”。位数必须有足够的熵，以便每个服务器有不同的码点，并且应该有足够的熵，以便每个服务器有很多码点。
配置代理不能选择一个路由掩码超过136的路由位，这样在一个最大长度的连接ID中，允许第一个八位和最多2个八位用于服务器寻址。
配置代理选择的除数必须大于服务器数量。它应该足够大，以适应服务器数量的合理增加。除数必须是一个奇数，所以某些额外操作并不总是产生一个偶数。
配置代理也会给每个服务器分配一个"模数"，即0和除数减1之间的整数。这些必须是每个服务器唯一的，并且应该分布在0和除数之间的整个数字空间中。

4.2.2. 负载均衡器行为

在收到QUIC数据包后，负载平衡器提取SCID的选定位，并将其表示为该长度的无符号整数。然后，负载平衡器将结果除以所选除数。这个操作的模数映射到目标服务器的模数。
请注意，任何包含服务器的模数，加上除数的任意整数倍的SCID在路由位中都是可路由到该服务器的，而不考虑非路由位的内容。因此，不知道除数或路由位的外部观察者将难以识别两个SCIDs路由到同一服务器。
还请注意，并非所有的连接ID都是可路由的，因为计算出的模数可能与分配给任何服务器的模数都不匹配。如上所述，这些DCID是不合规的。

4.2.3. 服务器行为

服务器选择一个连接ID长度。这个长度必须包含所有的路由位，并且必须至少是9个八位，以提供足够的熵。
当服务器需要一个新的连接ID时，它在不超过路由位数所限制的最大整数值的前提下，在其模数中加入一个任意的非负整数倍数。在这些约束条件下，倍数的选择应该是随机的。
服务器在路由位中对结果进行编码。它可以把任何其他的值放到既不用于路由也不用于配置rotation的位上。这些位应该在观察者看来是随机的。

4.3. 流加密CID 算法

流加密CID算法提供了真正的加密保护，而不是单纯的模糊，但代价是在负载均衡器上对每个数据包进行额外的处理，以解密每个传入的连接ID。 CID格式如下图所示。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  First Octet  |            Nonce (X=64..144)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Encrypted Server ID (Y=8..152-X)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   For server use (0..152-X-Y)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: 流加密CID格式

4.3.1. 配置代理行为

配置代理为池中的每台服务器分配一个服务器ID，并确定一个足够大的服务器ID长度（以八位为单位），以便对所有服务器ID进行加密，包括潜在的未来服务器。
配置代理还选择了一个 nonce 长度和 16 字节 AES-ECB 密钥用于连接 ID 解密。 nonce长度必须至少为8个八位，不超过16个八位。nonce长度和服务器ID长度必须为19个八位或更少。

4.3.2. 负载均衡器行为

当收到一个非初始或0-RTT类型的QUIC包时，负载平衡器会从目标连接ID中提取出尽可能多的最早的八位来匹配nonce长度。紧随其后的是服务器ID。
负载均衡器使用128位AES电子密码本(ECB)模式对服务器ID进行解密，类似于QUIC头保护。 nonce八位数被归零到16个八位。 AES-ECB使用其密钥对这个nonce进行加密，生成一个掩码，并将其应用到加密的服务器ID上。
server_id = encrypted_server_id ^ AES-ECB(key, padded-nonce)
例如，如果nonce的长度是10个八位，而服务器ID的长度是2个八位，那么连接ID可以小到13个八位。负载均衡器使用连接ID的第二到第十一位的nonce，用令牌的前6个八位将其归零为16个八位，然后用它来解密服务器ID的第十二和第十三个八位。解密的输出是负载均衡器用于路由的服务器ID。

4.3.3. 服务器行为

当生成一个可路由连接ID时，服务器会将任意位写入nonce的八位，并将其提供的服务器ID写入服务器ID的八位。服务器可以选择在nonce和服务器ID之外有一个更长的连接ID。 nonce和额外的位可以编码额外的信息，但对观察者来说，应该是随机的。
服务器使用128位AES电子密码本（ECB）模式对服务器ID进行解密，类似于QUIC头保护。 nonce八位数是由零添加到16个八位，并使用令牌的第一个八位中的尽可能多的八位。 AES-ECB会用它的密钥来加密这个nonce，生成一个掩码，并应用到服务器ID上。

4.4. 块加密CID算法

块加密CID算法，通过使用完整的16个八位明文和128位密码，提供了更高的密码保护和检测不符合要求的连接ID。但是，它也要求连接ID至少为17个八位的连接ID，增加了客户端到服务器数据包的开销。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  First octet  |       加密server ID (X=8..144)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             加密0 填充 (Y=0..144-X)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           服务器使用的加密字节 (144-X-Y)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           服务器使用的非加密字节 (0..24)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 图4: 块加密CID格式

4.4.1. 配置代理行为

配置代理为其池中的每个服务器分配一个服务器ID，并确定一个足够大的服务器ID长度（以八位为单位），以编码所有服务器ID，包括潜在的未来服务器。服务器ID将从解密后的连接ID的第二个八位开始，并在该八位之外占据连续的八位元组。
配置代理选择一个零填充长度。这个长度应该至少是四个八位，以便检测到不符合要求的DCID。服务器ID和零填充长度的总和不能超过16个八位。它们的总和应该不超过12个八位，以便为服务器提供足够的空间来编码自己的不透明数据。
配置代理也会选择一个16个八位的AES-ECB密钥用于连接ID解密。

4.4.2. 负载均衡器行为

收到QUIC包后，负载均衡器读取第一个八位，以获得配置rotation位。然后，它使用AES-ECB解密和选择的密钥对随后的16个八位进行解密。解密后的明文包含了服务器ID、零填充和不透明的服务器数据，依次为服务器ID、零填充和不透明的服务器数据。负载均衡器使用服务器ID八位来进行路由。

4.4.3. 服务器行为

当生成一个可路由连接ID时，服务器必须选择一个连接ID长度在17到20个八位数之间。服务器将其提供的服务器ID写入服务器ID八位数，将零写入零填充的八位数，并将任意位写入剩余的比特。这些任意位可以编码额外的信息。第一、十八、十九和二十个八位元组中的位对观察者来说应该基本上是随机的。第一个八位数保留如第3节所述。
然后，服务器使用128位AES-ECB密码对第二个到第十七个八位数进行加密。

5. 重试服务

当服务器处于加载状态时，QUICv1允许它推迟存储连接状态，直到客户端证明它可以在其公布的IP地址上接收数据包。通过使用重试包、客户端初始化包中的令牌和original_connection_id传输参数，服务器可以验证地址的所有权，客户端可以验证没有 "中间人 "产生重试数据包。
由于受信任的重试服务从字面上看就是一个 “中间人”，所以服务必须将 original_connection_id传回服务器，这样就可以通过客户端认证。它还必须要么验证地址本身（服务器信任这个验证），要么确保有共同的上下文让服务器使用服务生成的令牌来验证地址。
有两种不同的机制允许将DoS mitigation卸载到信任的网络服务。一种是不需要共享状态；服务器只需要配置为信任重试服务即可，尽管这样做会带来其他操作限制。另一种需要共享密钥，没有此类约束。
重试服务必须转发所有非 Initial 或 0-RTT 类型的 QUIC 数据包。其他类型的数据包可能涉及更改的IP地址或连接ID，因此重试服务无法识别这些数据包的有效或无效。

5.1. 一般要求

不管机制如何，重试服务都有一个主动模式，在这个模式中它生成重试包，而一个非主动模式(在这个模式中它不生成重试包)，这是基于它对服务器负载的评估和被攻击的可能性。模式的选择可以基于每个包或每个连接，通过随机过程或客户端地址。
重试服务必须转发它不理解的QUIC版本的所有包。注意，如果服务器支持重试服务不支持的版本，这可能会增加服务器的负载。但是，丢弃这些数据包会引入阻塞点，阻止新的 QUIC 版本的部署。需要注意的是，QUIC 的未来版本可能没有重试数据包，在重试中需要不同的信息，或者使用不同的数据包类型指导。

5.2. 无状态重试服务

无共享状态重试服务不需要协作，只是服务器必须被配置为接受该服务，并知道重试服务支持哪些QUIC版本。该方案使用令牌的第一个位来区分来自重试数据包的令牌（码点’0’）和来自NEW_TOKEN帧的令牌（码点’1’）。

5.2.1. 配置代理行为

配置代理分发重试服务支持的QUIC 版本列表。

5.2.2. 服务行为

从潜在客户机到服务器的所有路径上必须有一个无共享状态重试服务。如果服务因任何原因失败， QUIC流量不能通过这些路径。也就是说，如果该服务没有运行，服务器不能暴露在客户端流量中。否则，已经禁用了重试功能的服务器将很容易受到攻击。
重试服务和服务器之间的路径必须没有任何潜在的攻击者。注意，这和上述其他要求严重限制了无共享状态重试服务可以安全运行的条件。
由服务产生的重试令牌必须具有以下格式：

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| ODCIL (7) |  Original Destination Connection ID (0..160)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Original Destination Connection ID (...)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Opaque Data (variable)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5: Format of non-shared-state retry service tokens

服务生成的重试令牌的第一个位必须为0。该令牌有以下附加字段：
ODCIL：初始包的原始目的连接ID的长度。这是以明文形式存在，以便服务器可以读取，但验证稍后用令牌进行。
原始目的连接ID：也是以明文形式，随后进行验证。
不透明的数据：该数据必须包含加密信息，允许重试服务根据QUIC规范验证客户端的IP地址。它还必须对原始目的连接ID字段进行安全加密，以验证该字段未被编辑。
收到以’0’开头的初始数据包后，重试服务必须按照 QUIC 规范验证该令牌。它还必须验证连接 ID 的安全散列是否正确。如果不正确，则令牌无效。
在主动模式下，服务必须为所有不包含令牌或令牌第一位设置为’1’的客户端初始数据包发出重试数据包。它不能将数据包转发到服务器。服务必须验证所有第一个位设置为’0’的令牌。如果成功，服务必须在令牌完好的情况下转发该包。如果不成功，它必须丢弃该包。
注意，这个方案有一个性能上的缺点。当重试服务处于主动模式时，即使有NEW_TOKEN帧中的令牌的客户机有地址证明，也会受到1-RTT的惩罚。
在非主动模式下，该服务必须转发所有没有令牌或第一个位设置为’1’的令牌的包。它必须验证所有第一位设置为’0’的令牌。如果成功，服务必须在令牌完好的情况下转发该包。如果不成功，必须丢弃，或者在转发时删除令牌。后者需要对整个初始数据包进行解密和重新加密，以避免认证失败。转发该包会导致服务器在没有 original_connection_id 传输参数的情况下进行响应，这就保留了正常的 QUIC 信号给客户端，即有一个未授权的人在中间。

5.2.3. 服务器要求

非共享状态重试服务后面的服务器不能为重试服务理解的 QUIC 版本发送重试数据包。它可以为重试服务不理解的QUIC版本发送重试数据包。在NEW_TOKEN帧中发送的令牌必须将第一个位设置为’1’。
如果服务器收到的初始包的第一个位被设置为’1’，那么它可能来自于服务器生成的NEW_TOKEN帧，应该按照QUIC规范进行处理。如果服务器接收到第一个位为’0’的初始包，它是一个重试令牌，服务器不能尝试验证它。相反，它必须假定该地址已被验证，并且必须提取原始目的连接ID，假定采用第5.2.2节中描述的格式。

5.3. 共享状态重试服务

共享状态重试服务使用一个共享密钥，这样服务器就可以解码服务的重试令牌。它不要求所有的流量都要通过重试服务，所以服务器可以发送重试包来响应没有包含有效令牌的初始包。
服务器和服务必须统一时间，尽管不需要严格同步。
所有由服务器或重试服务生成的令牌都必须使用以下格式。这种格式是明文版本。在网络上，这些字段使用AES-ECB密码和令牌密钥进行加密。如果令牌不是16个八位数的倍数，最后一个块被填充为零。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ODCIL    |   Original Destination Connection ID (0..160)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Client IP Address (128)                  +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                         date-time (160)                       |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Opaque Data (optional)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 6: Cleartext format of shared-state retry tokens

令牌有以下字段：
ODCIL：原始目的连接ID长度。 NEW_TOKEN帧中的令牌必须将此字段设置为0。
原始目的连接ID：这是从客户端初始包中的字段复制过来的。
客户端 IP 地址：从客户端初始包中复制的。触发初始包中的源IP地址。客户端 IP 地址为 16 个八位数。如果是IPv4地址，最后12个八位数为零。
dat-time：日期时间。dat-time字符串共20个八位数，编码令牌生成的时间。日期-时间的格式在[RFC3339]第5.6节中描述了。这个ASCII字段必须使用 "Z "字符来表示时间延迟。
不透明数据：服务器可以使用这个字段来编码额外的信息，例如拥塞窗口、RTT或MTU。不透明数据也应该允许服务器区分重试令牌（触发使用original_connection_id 传输参数）和 NEW_TOKEN 帧令牌。

5.3.1. 配置管理行为

配置代理生成和分发令牌密钥。

5.3.2. 服务要求

在主动模式下，当服务收到没有令牌的客户端初始包时，必须以上述格式生成重试令牌。
在主动模式下，服务应该解密传入的令牌。服务应该丢弃IP地址不匹配的数据包，而应该转发省略其他字段的包。
在非主动模式下，服务应将所有数据包转发到服务器，以便服务器向客户端发出最新的令牌。

5.3.3. 服务器行为

服务器必须验证所有收到的初始包中的令牌，因为它们可能已经绕过了重试服务。它应该使用日期-时间字段来控制令牌过期。这不需要与重试服务同步。但是，由于可能的时钟同步问题，服务器可能会允许重试令牌被标记为几秒钟后的重试。
服务器不能发送一个重试包来响应包含重试令牌的初始包。

6. 配置要求

QUIC-LB需要统一配置，以同步理解编码并保证服务器的明确同意。
负载均衡器和服务器必须就路由算法和算法的相关参数达成一致。
对于明文CID路由，这包括服务器ID和路由字节。服务器ID对每个服务器是唯一的，而路由字节是全局的。
对于模糊CID 路由，这包括路由位、除数和模数。模数是每个服务器唯一的，但其他的必须是全局的。
对于流加密的CID路由，由服务器ID、服务器ID长度、密钥和Nonce长度组成。服务器ID是每个服务器唯一的，但其他的必须是全局的。认证令牌必须在带外发布，才能使该算法运行。
对于快加密CID路由，由服务器ID、服务器ID长度、密钥和零填充长度组成。服务器ID对每个服务器来说是唯一的，但其他的必须是全局的。
一个完整的QUIC-LB 配置还必须指定第一个 CID 八位数的信息以及任何重试服务的存在和模式。
下面的伪代码描述了在服务器上存储完整的QUIC-LB 配置所需的数据项。它的目的是描述概念范围，而不是指定这种配置在互联网数据包中的表现形式。注释表示可接受的值范围（如果适用的话）。

7. 其他用例

本节讨论了上述规范中未提及的一些部署方案的考虑。

7.1. 负载均衡链

有些网络架构可能有多层低状态负载均衡器，第一层的设备做出路由决定，直到数据包到达服务器为止，以此类推。虽然QUIC-LB没有明确为这种用例设计，但可以支持这种用例。如果给每个负载均衡器分配了一个服务器ID的范围，这个范围是分配给离客户端较近的设备的ID的子集，那么第一个处理入站数据包的设备就可以提取服务器ID，然后将其映射到正确的转发地址。注意，这个方案可以扩展到任意数量的负载均衡层，因为服务器ID的最大空间相当大。

7.2. 服务期间的链路迁移

有些部署可能会将连接从一台服务器透明地转移到另一台服务器。在服务器之间转移连接状态的方法不在本文的范围内。
为了支持交接，参与过渡的服务器可以通过NEW_CONNECTION_ID帧发布映射到新服务器的CID，并使用该帧中的 "Retire Prior To "字段来撤销与新服务器相关联的CID。
另外，如果旧服务器要下线，负载均衡器可以简单地将其服务器ID映射到新服务器的地址上。

8. 安全考虑

QUIC-LB的目的是为了防止关联。因此，攻击者会试图颠覆这一目的。
请注意，明文CID算法没有试图掩盖服务器映射，因此没有解决这些问题。它的存在是为了在整个网络基础设施中实现一致的CID编码，以实现兼容性。正在运行明文CID算法的服务器应该只用它来为服务器初始包生成新的CID，而不应该在QUIC NEW_CONNECTION_ID帧中发送CID。这样做可能会向客户端错误地暗示说CID是以安全的方式生成的。
关联性攻击会找到一些方法来确定两个连接ID路由到同一服务器。如上所述，没有任何方案可以严格防止所有流量模式的可关联性，因此，对服务器ID编码的任何分析都会有影响。

8.1. 攻击者不在负载均衡器和服务器中间

任何攻击者都可能打开一个连接到服务器，并积极地退掉连接ID，以获得大量映射到同一服务器的ID样本。然后，它可以应用分析技术，试图获得服务器的编码。
加密的CID算法提供了鲁棒的熵，可以进行任何形式的连接。模糊CID掩盖了映射，防止了简单的蛮力攻击来确定路由参数，但并不能提供对复杂攻击的稳健保护。
如果这种分析是为了获得服务器的编码，那么路径上的观察者可能会将这种分析应用于不同的客户端IP地址的关联。

8.2. 攻击者在负载均衡器和服务器中间

处于这种特权地位的攻击者本质上能够将两个连接ID映射到同一个服务器上。如果服务器在为该连接生成新的ID时进行合理的选择，QUIC-LB算法确实可以防止两个连接ID关联。

9. IANA考虑

没有IANA 要求

10. 参考资料

10.1. 参考标准

[QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, draft-ietf-quic-transport (work in progress).

[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”, RFC 3339, DOI 10.17487/RFC3339, July 2002, https://www.rfc-editor.org/info/rfc3339.

10.2. 参考资料

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

附录A. 负载均衡器测试指导

由于本规范中的任何连接ID编码都包括了许多用于服务器的位，而不影响连接ID的提取，因此对于任何给定的参数集都有许多可能的连接ID。但是，每个连接ID都应该产生一个唯一的服务器ID。下面的连接ID可以用来验证负载均衡器实现是否提取了正确的服务器ID。

aashuii

关注

2
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
QUIC-LB: 生成可路由QUIC连接ID ( draft-ietf-quic-load-balancers-02)

QUIC M. DukeInternet-Draft F5 Networks, Inc.目的状态: 标准跟踪 N. Banks...
复制链接

扫一扫