网络协议：QUIC协议（5）地址验证

RFC9000 QUIC：基于UDP的多路复用和安全传输

【8 地址验证】

地址验证确保端点不能用于流量放大攻击。在此类攻击中，发送一个带有伪装源地址信息的包到服务器，该信息标识受害者。如果服务器根据该包生成更多或更大的数据包，攻击者可以使用该服务器向受害者发送比其自身能够发送的数据更多的数据。

主要防御放大攻击的方法是验证对等方是否能够接收其声称的传输地址上的数据包。因此，在收到尚未验证的地址上的数据包后，端点必须将其发送给未验证地址的数据量限制为从该地址接收到的数据量的三倍。此响应大小的限制称为反放大限制。

地址验证既在建立连接时执行(见第8.1节),也在连接迁移时执行(见第8.2节)。

【8.1连接建立期间的地址验证】

连接的隐式建立为两端提供地址验证。特别是，收到用握手密钥保护的数据包确认对等方成功处理了初始数据包。一旦端点成功处理了来自对等方的握手数据包，它就可以认为对等方的地址已得到验证。

此外，如果对等方使用由端点选择的连接ID且连接ID包含至少64位熵，端点还可以认为对等方的地址已得到验证。

对于客户端，其第一个初始数据包中的Destination Connection ID字段的值允许其将服务器地址作为成功处理任何数据包的一部分进行验证。服务器从这个值派生出(参见[QUIC-TLS]第5.2节)用于保护其初始数据包的密钥。或者，服务器可以在版本协商数据包(第6节)中回显该值，或者在重试数据包(第5.8节)的Integrity Tag中包含该值。

在验证客户端地址之前，服务器不得发送超过它们接收到字节数的三倍的数据。这限制了可以使用伪造源地址进行放大攻击的任何放大攻击的范围。为了避免在地址验证之前进行放大，服务器必须计算在唯一地归属于单个连接的数据报中接收到的所有有效负载字节数。这包括包含成功处理的数据包和包含所有丢弃的数据包的数据报。

客户端必须确保包含初始数据包的UDP数据报具有至少1200字节的有效负载，并在必要时添加填充帧。发送填充数据报的客户端允许服务器在完成地址验证之前发送更多数据。

服务器丢失初始或握手数据包可能导致死锁，如果客户端不发送额外的初始或握手数据包。当服务器达到其反放大限制并且客户端已对其发送的所有数据获得确认时，可能会发生死锁。在这种情况下，当客户端没有发送额外数据的原因时，服务器将无法再发送更多数据，因为它尚未验证客户端的地址。为了防止这种死锁，客户端必须在Probe Timeout上发送一个数据包(详见[QUIC-RECOVERY]第6.2节)。具体而言，如果客户端没有握手密钥，则必须在包含至少1200字节的有效负载的UDP数据报中发送初始数据包；否则，应发送握手数据包。

服务器可能希望在开始加密握手之前验证客户端地址。QUIC在初始数据包中使用令牌提供在完成握手之前进行地址验证。此令牌在与Retry数据包一起通过连接建立期间(见第8.1.2节)或在其之前的先前连接中使用NEW_TOKEN帧(见第8.1.3节)传递给客户端。

此外，除了在地址验证前施加的发送限制之外，服务器还受到拥塞控制器设置的限制所约束。客户端仅受拥塞控制器的限制。

【8.1.1. Token构建】

在NEW_TOKEN帧或Retry数据包中发送的令牌必须以一种允许服务器识别如何提供给客户端的方式进行构建。这些令牌在同一字段中携带，但需要从服务器处采取不同的处理方式。

【8.1.2. 使用Retry数据包进行地址验证】

在收到客户端的Initial数据包后，服务器可以通过发送包含令牌的Retry数据包(第17.2.5节)来请求地址验证。此令牌必须在客户端接收到Retry数据包后，为该连接发送的所有Initial数据包中重复。

对于包含在Retry数据包中提供的令牌的Initial数据包的响应，服务器不能发送另一个Retry数据包；它只能拒绝连接或允许其继续。

只要攻击者无法为其自己的地址生成有效的令牌(参见第8.1.4节),并且客户端能够返回该令牌，它就向服务器证明已收到该令牌。

一个服务器也可以使用重试数据包来推迟连接建立的状态和处理成本。要求服务器提供不同的连接ID,以及在第18.2节中定义的原始目标连接ID传输参数，迫使服务器证明它或它合作的实体收到了客户端的原始初始数据包。提供不同的连接ID还可以使服务器对后续数据包的路由有一定的控制。这可以用于将连接引导到不同的服务器实例。

如果服务器收到包含无效重试令牌但其他方面有效的客户端初始数据包，它知道客户端不会接受另一个重试令牌。服务器可以丢弃这样的数据包并允许客户端超时以检测握手失败，但这可能会给客户端带来显著的延迟开销。相反，服务器应该立即关闭(第10.2节)与INVALID_TOKEN错误相关的连接。请注意，此时服务器尚未为该连接建立任何状态，因此也不会进入关闭阶段。

一个显示重试数据包使用情况的流程在下图中显示：

示例：带有重试的握手

【8.1.3. 未来连接的地址验证】

服务器在一次连接期间可以向客户端提供一个地址验证令牌，该令牌可以在随后的连接中使用。由于0-RTT可能会导致服务器向客户端发送大量数据，因此地址验证对于0-RTT尤为重要。

服务器使用NEW_TOKEN帧(第19.7节)向客户端提供一个可用于未来连接的地址验证令牌。在未来的连接中，客户端将在初始数据包中包含此令牌以进行地址验证。客户端必须在所有发送的初始数据包中包含该令牌，除非Retry用一个更新的令牌替换它。客户端不得在未来的连接中使用Retry提供的令牌。服务器可能会丢弃不携带预期令牌的任何初始数据包。

与用于立即使用的Retry数据包创建的令牌不同，NEW_TOKEN帧中发送的令牌可以在一段时间后使用。因此，令牌应具有过期时间，可以是显式的过期时间，也可以是可用于动态计算过期时间的发行时间戳。服务器可以存储过期时间或将其作为加密形式包含在令牌中。

使用NEW_TOKEN发行的令牌不应包含允许观察者将值链接到发出它的连接的信息。例如，它不能包括先前的连接ID或寻址信息，除非这些值被加密。服务器必须确保其发送的每个NEW_TOKEN帧在其所有客户端之间都是唯一的，除了那些用于修复之前发送的NEW_TOKEN帧的丢失的数据包。允许服务器区分来自Retry和NEW_TOKEN的令牌的信息可能对除服务器以外的实体可访问。

不太可能在两个不同的连接上使用相同的客户端端口号；因此，验证端口也不太可能成功。

在一个NEW_TOKEN帧中接收到的令牌适用于任何客户端认为其权威的服务器(例如，证书中包含的服务器名称)。当连接到一个客户端保留适用且未使用的令牌的服务器时，它应该在其初始数据包的Token字段中包含该令牌。包括令牌可能允许服务器在无需额外往返的情况下验证客户端地址。客户端不得包括与其正在连接的服务器不相关的令牌，除非客户端知道颁发令牌的服务器和其正在连接的服务器共同管理这些令牌。客户端可以使用与该服务器之前的任何连接相关的任何令牌。

令牌允许服务器关联在发放令牌的连接和在其中使用它的任何连接之间的活动。希望与服务器断开连续身份认证的客户端可以丢弃使用NEW_TOKEN帧提供的令牌。相比之下，在连接尝试期间必须立即使用的Retry数据包中的令牌不能用于后续连接尝试。

客户端不应为不同的连接尝试重用来自NEW_TOKEN帧的令牌。重用令牌允许网络路径上的实体将连接链接起来；请参见第9.5节。

在单个连接上，客户端可能会收到多个令牌。除了防止链接性之外，任何令牌都可以用于任何连接尝试。服务器可以向其发送额外的令牌，以启用多个连接尝试的地址验证或替换可能变得无效的旧令牌。对于客户端而言，这种歧义意味着发送最近未使用的令牌最有可能有效。尽管保存和使用旧令牌没有负面影响，但客户端可以将旧令牌视为不太可能对服务器进行地址验证。

当服务器接收到带有地址验证令牌的初始数据包时，除非已完成地址验证，否则它必须尝试验证该令牌。如果令牌无效，则服务器应按客户端未经过验证的地址处理，包括可能发送重试数据包。通过服务器(参见第8.1.1节)可以区分提供在新令帧和重试数据包中的令牌，后者可以更严格地进行验证。如果验证成功，则服务器应允许握手继续进行。

注意：将客户端视为未验证而非丢弃数据包的原因是，客户端可能在之前的连接中使用NEW_TOKEN帧接收了令牌，如果服务器丢失状态，它可能无法验证令牌，导致如果丢弃数据包，则会引发连接失败。

在一个无状态的设计中，服务器可以使用加密和认证的令牌将信息传递给客户端，以便服务器稍后可以恢复并使用这些令牌验证客户端地址。令牌没有集成到加密握手中，因此它们没有经过认证。例如，客户端可能能够重用一个令牌。为了避免利用这一特性的攻击，服务器可以将令牌的使用限制为仅用于验证客户端地址所需的信息。

客户端在尝试使用相同版本的任何连接时都可以使用一次连接获得的令牌。在选择要使用的令牌时，客户端不需要考虑正在尝试的其他连接属性，包括可能的应用程序协议、会话票据或其他连接属性。

【8.1.4地址验证令牌完整性】

地址验证令牌的完整性必须难以猜测。在令牌中包含至少128位熵的随机值就足够了，但这取决于服务器记住它发送给客户端的值。基于令牌的方案允许服务器将与验证相关的任何状态卸载到客户端。为了使这种设计有效，令牌必须受到客户端修改或伪造的完整性保护。如果没有完整性保护，恶意客户端可以生成或猜测令牌的值，这些值将被服务器接受。只有服务器需要访问用于令牌的完整性保护密钥。

由于生成令牌的服务器也会消耗它，因此不需要为令牌定义单一的明确格式。在Retry数据包中发送的令牌应包括允许服务器验证客户端数据包中的源IP地址和端口保持不变的信息。在NEW_TOKEN帧中发送的令牌应包括允许服务器验证客户端IP地址未在令牌颁发时更改的信息。服务器可以使用NEW_TOKEN帧中的令牌来决定不发送Retry数据包，即使客户端地址已更改。如果客户端IP地址已更改，服务器必须遵守反放大限制；请参阅第8节。请注意，在NAT存在的情况下，此要求可能不足以保护与其他共享NAT的其他主机免受放大攻击。

攻击者可以重放令牌以在DDoS攻击中使用服务器作为放大器。为了防止此类攻击，服务器必须确保阻止或限制令牌的重放。服务器应确保Retry数据包中发送的令牌仅在短时间内接受，因为它们会立即由客户端返回。在NEW_TOKEN帧中提供的令牌(第19.7节)需要更长时间有效，但不应多次接受。服务器鼓励只允许一次使用令牌(如果可能),并且令牌可能包含有关客户端的附加信息，以进一步缩小适用范围或重复使用。

【8.2路径验证】

路径验证在连接迁移期间由对等方同时使用(见第9节),以验证地址更改后可达性。在路径验证中，端点测试特定本地地址和特定对等方地址之间的可达性，其中地址是IP地址和端口的二元组。

路径验证测试发送到对等方路径上的数据包是否被该对等方接收。路径验证用于确保从迁移对等方接收到的数据包不携带伪造的源地址。

路径验证不能验证对等方是否能在返回方向上发送数据。确认无法用于返回路径验证，因为它们包含不足的熵并且可能被伪造。端点独立地确定每条路径的每个方向的可达性，因此只能由对等方建立返回可达性。

路径验证可以在任何时间由任一端点使用。例如，一个端点可能会检查在一段时间的静默后，对等方是否仍然拥有其地址。

路径验证不是设计为NAT遍历机制。尽管此处描述的机制对于创建支持NAT遍历的NAT绑定可能是有效的，但预期的是，一个端点能够在没有首先在该路径上发送数据包的情况下接收数据包。有效的NAT遍历需要提供在此未提供的附加同步机制。

一个端点可能包含其他帧，其中包括用于路径验证的PATH_CHALLENGE和PATH_RESPONSE帧。特别是，端点可以包含具有PATH_CHALLENGE帧的PADDING帧，用于Path最大传输单元发现(PMTUD);请参阅第14.2.1节。当发送PATH_RESPONSE帧时，端点还可以包含其自身的PATH_CHALLENGE帧。

当从新的本地地址发送探测请求时，端点使用一个新的连接ID;请参见第9.5节。当探测新路径时，端点可以确保其对等方有一个未使用的连接ID可用于响应。如果对等方的active_connection_id_limit允许，在同一个数据包中发送NEW_CONNECTION_ID和PATH_CHALLENGE帧可以确保在发送响应时对等方将有一个可用的未使用的连接ID。

端点可以选择同时探测多个路径。用于探测的并发路径数量受限于其对等方先前提供的额外连接ID的数量，因为每个用于探测的新本地地址都需要一个先前未使用的连接ID。

【8.2.1初始化路径验证】

为了启动路径验证，端点在要验证的路径上发送一个包含不可预测负载的PATH_CHALLENGE帧。

端点可以发送多个PATH_CHALLENGE帧以防止数据包丢失。但是，端点不应该在一个数据包中发送多个PATH_CHALLENGE帧。

端点不应该用包含PATH_CHALLENGE帧的数据包更频繁地探测新路径，而是应该像建立新连接一样频繁地发送初始数据包。这确保了连接迁移不会对新路径造成比建立新连接更大的负担。

端点必须在每个PATH_CHALLENGE帧中使用不可预测的数据，以便将对等方的响应与其相应的PATH_CHALLENGE关联起来。

端点必须将包含PATH_CHALLENGE帧的数据报扩展到至少允许的最小最大数据报大小1200字节的最小值，除非该路径的反放大限制不允许发送此大小的数据报。发送此大小的UDP数据报可以确保从端点到对等方的网络路径可用于QUIC;请参阅第14节。

当端点由于反放大限制无法将数据报大小扩展到1200字节时，将不验证路径MTU。为了确保路径MTU足够大，端点必须通过发送至少1200字节的数据报来执行第二次路径验证。此附加验证可以在成功接收到PATH_RESPONSE之后或在已收到路径上足够的字节后进行，此时发送较大的数据报不会超过反放大限制。

与其他情况下数据报扩展不同，当包含PATH_CHALLENGE或PATH_RESPONSE的数据报看起来太小时，端点不得丢弃它们。

【8.2.2 路径验证响应】

在收到PATH_CHALLENGE帧后，端点必须通过回显PATH_CHALLENGE帧中包含的数据在PATH_RESPONSE帧中进行回应。端点不得因拥塞控制而延迟发送包含PATH_RESPONSE帧的数据包。

PATH_RESPONSE帧必须在接收到PATH_CHALLENGE帧的网络路径上发送。这确保了只有在双向路径都正常的情况下，对等方才能成功验证路径。发起路径验证的端点不应强制执行此要求，因为这将使攻击者能够进行迁移攻击；请参阅第9.3.3节。

端点必须至少将包含PATH_RESPONSE帧的数据报扩展到最小允许的最大数据报大小1200字节。这验证了路径是否能够在两个方向上承载这种大小的数据报。然而，如果结果数据超过了抗放大限制，端点不得扩展包含PATH_RESPONSE的数据报。这通常只发生在未在扩展数据报中发送的收到的PATH_CHALLENGE帧中发生。

端点在响应一个PATH_CHALLENGE帧时不得发送多于一个PATH_RESPONSE帧；请参阅第13.3节。预期情况下，对等方会根据需要发送更多PATH_CHALLENGE帧以引发更多的PATH_RESPONSE帧。

【8.2.3成功的路径验证】

路径验证成功当收到一个包含先前PATH_CHALLENGE帧中发送的数据的PATH_RESPONSE帧时。

在任何网络路径上收到的PATH_RESPONSE帧验证了PATH_CHALLENGE所发送的路径。

如果端点在一个未至少扩展到1200字节的数据报中发送PATH_CHALLENGE帧，并且对其的响应验证了对等方地址，则路径被验证但未验证路径MTU。因此，端点现在可以发送比已接收数据量多三倍的数据。然而，端点必须使用扩展后的数据报发起另一个路径验证以验证该路径是否支持所需的MTU。

接收到包含PATH_CHALLENGE帧的数据包的确认信息并不足以进行验证，因为确认信息可能被恶意的对等方篡改。

【8.2.4失败的路径验证】

路径验证仅在尝试验证路径的端点放弃验证路径时失败。

端点应基于计时器放弃路径验证。设置此计时器时，实现应注意新路径可能具有比原始路径更长的往返时间。将当前PTO或新路径的PTO(使用kInitialRtt定义，如QUIC-RECOVERY中所述)的三倍作为推荐值。

此超时允许多个PTO在失败路径验证之前过期，以防止单个PATH_CHALLENGE或PATH_RESPONSE帧导致路径验证失败。

请注意，端点可能会在新路径上收到包含其他帧的数据包，但要使路径验证成功，需要发送适当的PATH_RESPONSE帧。

当端点放弃路径验证时，它确定该路径无法使用。这并不一定意味着连接失败——端点可以根据需要继续通过其他路径发送数据包。如果没有可用路径，端点可以等待新路径出现或关闭连接。如果端点没有到其对等方的有效网络路径，则可以使用NO_VIABLE_PATH连接错误进行信号，指出这只有在网络路径存在但不支持所需的MTU(第14节)时才可能发生。

除了失败之外，路径验证还可能因其他原因而被中止。主要原因是在旧路径上的路径验证正在进行中时启动到新路径的连接迁移。

2023年下半年网络规划设计师考试时间是11月4日。

考试科目：

网络规划设计师考试共三科，科目一是网络规划与设计综合知识、科目二是网络规划与设计案例分析、科目三是网络规划与设计论文。

考试时间：

科目一的考试时间是11月4日上午9:00至11:30，科目二的考试时间是11月4日下午1:30至3:00，科目三的考试时间是下午3:30至5:30。

考试题型：

科目一考试的题型是单项选择题共75道题，每题1分，满分75分；

科目二考试的题型是问答题共三道大题每题25分，满分75分；

科目三考试的题型是论文题，两个话题二选一写论文，满分75分。

考试教程：

最新版的网络规划设计师教程是清华大学出版社2021年12月出版的《网络规划设计师教程（第2版）》。教材内容共8章423页，教材结构如下所示：

2023年网络规划设计师的备考内容包括最新考试大纲、最新教材内容学习，近三年科目一综合知识、科目二案例例分析和科目三论文真题分析；综合知识模拟题精讲、考前专项训练。

【网规视频】

2022网络规划设计师数字人视频（106个），视频内容可以通过在华华早起公众号“软考网络”菜单的“网络规划设计师”查看，或者可以在华华早起公众号搜索“软考”查看全部视频内容。