跳到主要内容

5. 要求, 安全操作和可选校验和 (Requirements, Security Operations, and Optional Checksum)

[RFC9097] 未覆盖安全和校验和操作, 它只定义测量方法 (Method of Measurement). 本节补充与安全和可选校验和相关的操作规范. 由于额外复杂性, 以及第 3 层与第 4 层之间数据包到数据报的直接映射会丢失, 推荐避免第 3 层分片. 一种简化做法是选择足够小的默认数据报大小, 以防止分片. 本规范版本不支持数据报包化层路径 MTU 发现 (Datagram Packetization Layer Path MTU Discovery, DPLPMTUD) [RFC8899]. 未来版本可以规定如何支持它. DPLPMTUD 支持将需要经过谨慎适配的协议设计, 以确保互操作性. 除非预期会发生 IP 分片, 并且分片本身是被测属性之一, 否则所有测试都应当设置 IPv4 Don't Fragment (DF) 位.

注: 当本规范用于网络调试时, 由测试管理员控制分片可能很有用.

本节规定通用要求, 符合本规范的测量负载速率调整算法必须满足这些要求.

5.1. 负载速率调整算法要求 (Load Rate Adjustment Algorithm Requirements)​

本文档规定一种使用负载速率调整算法的主动容量测量方法. 本节列出的要求以及当前标准化的负载速率调整算法 B [Y.1540Amd2] 和 C [TR-471], 源自原作者多年的实验和测试. 这些测试在实验室和 Internet 中执行, 覆盖了不同国家和大陆上的多种固定, 宽带, 移动和无线接入类型及技术. 此外, 下面列出的负载速率调整算法要求反映了性能测量专家的反馈, 也反映了 [RFC9097] 标准化所带来的变更, 这些变更也体现在算法 B [Y.1540Amd2] 中, 该算法更新了此算法的早期版本.

用于容量测量的负载速率调整算法必须符合本节规定的要求. 新的容量测量标准负载速率调整算法在被分配 "Test Activation PDU Rate Adjustment Algo" 注册表中的代码点之前, 必须由 IETF 指定专家审查.

用于容量测量的负载速率调整算法要求如下:

  1. 本节描述的测量负载速率调整算法禁止用作通用拥塞控制算法 (Congestion Control Algorithm, CCA).

  2. 本规范必须只用于诊断和操作测量应用.

  3. Load PDU 消息和 Status Feedback PDU 消息都必须包含序列号.

  4. 目标端测量间隔的标称持续时间, 即参数 testIntTime ([RFC9097] 中的 "I"), 默认值必须不超过 10 秒.

  5. 用于快速达到高发送速率的高速模式必须把测量负载降低到某个水平以下, 该水平是第一个反馈间隔根据测量推断出"拥塞"时对应的水平. 如果连续反馈间隔中序列号异常计数超过阈值, 和/或所有这些连续间隔都包含上限延迟变化阈值异常, 则表示测试中存在"拥塞". 连续反馈间隔阈值必须可配置, 默认值为 3 个间隔, 推断拥塞的最长持续时间为 500 ms (毫秒).

  6. 如果 Status Feedback PDU 表明检测到序列号异常, 或者延迟范围高于上限延迟变化阈值, 则必须指示拥塞. 推荐的阈值为: 序列号间隙 10, 下限延迟变化阈值 30 ms, 上限延迟变化阈值 90 ms.

  7. 负载速率调整算法必须包含 Load PDU 超时和 Status PDU 超时. 当接收的 PDU 流意外停止时, 这两个超时都会停止测试.

  8. 每次收到 Load PDU 时, Load PDU 超时都必须重置为配置值. 如果 Load PDU 超时到期, 接收方必须关闭, 且不再发送 Status PDU 反馈. 默认 Load PDU 超时必须不超过 1 秒.

  9. 每次收到反馈消息时, Status PDU 超时都必须重置为配置值. 如果 Status PDU 超时到期, 发送方必须关闭, 且不再发送负载数据包. 默认 Status PDU 超时必须不超过 1 秒.

  10. 如果网络运营商确信要验证的 IP 层容量 (IP-Layer Capacity), 可以从 IP 层容量上的固定速率测试开始, 并避免激活测量负载速率调整算法 (见 [RFC9097] 第 8.1 节). 但是, 诊断测试的触发因素 (如订户请求) 强烈暗示不存在这种确定性, 因此推荐使用负载调整算法.

  11. 本规范必须只在符合 [RFC9097] 第 10 节 (安全注意事项) 的情形下使用.

  12. 进一步的测量负载速率调整算法要求由 [RFC9097] 规定.

以下测量负载速率调整算法受这些要求约束:

  • 测量负载速率调整算法 B [Y.1540Amd2].

  • 测量负载速率调整算法 C [TR-471].

5.2. 参数和定义 (Parameters and Definitions)​

关于最大 IP 层容量度量 (Maximum IP-Layer Capacity Metric) 和方法相关参数的概述, 请参见 [RFC9097] 第 4 节. 第 12.3.5 节提供了一组用于支持调试的错误码.

5.3. 安全模式操作 (Security Mode Operations)​

有两种安全操作模式会对客户端/服务器消息传递执行认证. 这两种模式为:

  1. 必需模式, 在控制阶段 (Control phase, Test Setup 和 Test Activation 交换) 执行认证. 对于大规模服务器或处理能力需要考虑的低端客户端设备, 此模式可能更适合 (见第 3 节).

  2. 可选模式, 在数据阶段 (Data phase) 额外认证 Status Feedback 消息. 对于希望在整个测试期间获得额外消息完整性验证级别的环境, 此模式可能更适合 (见第 3 节).

下文讨论的要求涉及下方第 6 节和第 7 节中的 PDU, 主要包括 authMode, keyId, authUnixTime 和 authDigest 字段. 本节中的角色已被泛化, 以便 PDU 发送方和接收方的要求可以被复用, 并由本文档内的其他章节引用. 每个后续模式都会提高安全性, 但也会带来额外的性能影响和复杂性. 本协议使用很小的负载, 并且可能运行在非常低端的设备上. 提供多种安全操作模式的灵活性, 可以适配终端设备可用资源. 一般而言, 本文档定义的这类主动测量技术更适合保护测量相关方的隐私 [RFC7594].

负载速率调整方法需要满足第 5.1 节列出的要求. 这也是必要的, 以避免在发生过载或丢失 (包括控制路径上的丢失) 后可能诱发拥塞.

5.3.1. 模式 1: 必需认证模式 (Required Authenticated Mode)​

在此模式中, 客户端和服务器必须配置为使用若干共享秘密密钥之一, 并通过数字 keyId 字段指定 (见第 5.4 节). 如第 5.4.1 节所规定, 该密钥必须用作密钥派生函数 (Key Derivation Function, KDF) 的输入, 以获得客户端和服务器实际用于认证的密钥.

在控制阶段, 发送方必须读取当前系统时间 (挂钟时间), 填充 authUnixTime 字段, 然后根据 [RFC6234] 第 6 节计算整个 PDU 的 32 个八位字节 HMAC-SHA-256 哈希值 (authDigest 和 checkSum 预设为全零). authDigest 字段由结果填充, 随后将数据包发送给接收方. authUnixTime 字段中的值是 32 位时间戳, 接收方必须使用 10 秒容差窗口 (+/- 5 秒) 来区分 PDU 的后续重放. 关于推荐的时间戳分辨率, 见 [TR-471] 表 2.

接收时, 接收方必须验证消息 PDU 的长度正确性, authDigest 有效性, authUnixTime 即时性以及预期格式 (也会检查 PDU 特定字段, 例如协议版本). 验证 authDigest 时, 需要先从 PDU 中提取它, 并在用于比较的哈希消息认证码 (Hashed Message Authentication Code, HMAC) 计算之前, 将该字段与 checkSum 字段一起置零 (见 [RFC9145] 第 7.2 节).

如果验证失败, 接收方不应继续控制阶段, 并应当实现静默拒绝 (不再在该地址/端口对上发送数据包). 例外情况是测试主机已配置为排查控制阶段故障, 且拒绝消息有助于该过程.

如果验证成功, 接收方必须继续控制阶段, 并构造成功响应或指示已识别错误条件 (如有) 的响应.

对于 Test Setup 交换中的请求和响应, 包括 Null Request (第 6 节) 以及 Test Activation 交换 (第 7 节), 都必须执行此过程.

5.3.2. 模式 2: 数据阶段可选认证模式 (Optional Authenticated Mode for Data Phase)​

此模式包含认证模式 1. 在数据阶段使用可选认证时, 认证也必须应用于 Status Feedback PDU (见第 8.2 节). 在下行测试中客户端发送 Status PDU, 在上行测试中服务器发送 Status PDU.

Status PDU 发送方必须 1) 读取当前系统时间 (挂钟时间) 并填充 authUnixTime 字段, 2) 计算整个 Status PDU 的 authDigest 字段 (authDigest 和 checkSum 预设为全零), 以及 3) 将数据包发送给接收方. authUnixTime 字段和 authDigest 字段的值按第 5.3.1 节定义确定.

接收时, 接收方必须验证消息 PDU 的长度正确性, authDigest 有效性, authUnixTime 即时性以及预期格式 (也会检查 PDU 特定字段, 例如协议版本). 验证 authDigest 时, 需要先从 PDU 中提取它, 并在用于比较的 HMAC 计算之前, 将该字段与 checkSum 字段一起置零.

如果认证验证失败, 接收方必须忽略该消息. 如果看门狗定时器因连续验证失败而到期, 测试会话将提前终止 (且禁止再传输负载流量). 这也是必要的, 以避免在控制路径上发生过载或丢失后可能诱发拥塞.

如果未选择此可选模式, 则 Status PDU 的 keyId, authUnixTime 和 authDigest 字段 (见第 8.2 节) 必须设置为全零.

5.4. 密钥管理 (Key Management)​

[RFC7210] 第 2 节规定了一个用于长期密码学密钥的概念性数据库. 密钥表必须与必需认证模式和可选认证模式一起使用 (使用同一密钥). 对于认证, 如第 5.4.1 节所规定, 该密钥只能用作 KDF 的输入, 以派生用于认证处理的实际密钥. 密钥轮换和相关管理细节超出本文档范围.

按照 [RFC7210] 第 2 节, 密钥表的每条记录必须至少包含以下字段:

  • AdminKeyName

  • LocalKeyName

  • KDF

  • AlgID

  • Key

  • SendLifetimeStart

  • SendLifeTimeEnd

  • AcceptLifeTimeStart

  • AcceptLifeTimeEnd

LocalKeyName 必须根据后续 PDU 中相应的 keyId 字段确定.

5.4.1. 密钥派生函数 (Key Derivation Function, KDF)​

KDF 是一种单向函数, 用于提供密钥材料的密码学隔离. 协议需要 KDF 来安全派生用于协议消息认证的密码学密钥. 引入 KDF 可确保密钥以标准化且密码学安全的方式生成, 从而降低密钥泄露风险, 并支持不同实现之间的互操作性. 使用 KDF 的益处包括:

  • 安全性: KDF 生成具有高熵的密钥, 可抵抗暴力破解和相关密钥攻击, 从而为协议通信提供稳健保护.

  • 灵活性: KDF 允许从单个共享秘密派生多个密钥, 支持客户端认证和服务器认证使用不同密钥.

  • 标准化: 通过遵循既有密码学标准, KDF 确保与现有安全框架兼容, 并便于实现审计.

  • 效率: KDF 支持高效生成密钥, 无需额外密钥交换机制, 从而最小化协议开销.

KDF 算法必须是 [NIST800-108] 第 4.1 节规定的计数器模式密钥派生函数 (Key Derivation Function in Counter Mode). 该算法使用基于计数器的机制从共享秘密生成密钥材料, 确保确定性且安全的密钥派生. KDF 中使用的伪随机函数 (Pseudorandom Function, PRF) 必须是 HMAC-SHA-256, 如 [RFC6234] 第 6 节所定义. IANA 已将 "HMAC-SHA-256" 分配为新的 KeyTable KDF (第 12.2 节).

KDF 必须使用以下参数:

  • Kin (key-derivation key): PDU 中 keyId 字段所标识的共享密钥.

  • Label: 固定字符串 "UDPSTP" (不含引号), 编码为 UTF-8 字符串, 用于将派生密钥绑定到此特定协议.

  • Context: 从客户端发送到服务器的第一个 Setup Request PDU 中收到的 authUnixTime 字段的 UTF-8 字符串表示. 这确保派生密钥对该会话唯一, 并绑定到初始设置交换的时间上下文. authUnixTime 字段充当随机数 (nonce), 并受到 authDigest 字段中 HMAC-SHA-256 哈希值的保护, 防止被修改.

  • r: 计数器二进制编码的长度必须为 32 (位).

派生密钥材料总长度必须为 512 位 (64 个八位字节). 密钥材料必须按照如下结构组织, 从最高有效位 (Most Significant Bit, MSB) 到最低有效位 (Least Significant Bit, LSB):

  • Client Authentication Key: 256 位 (32 个八位字节); 用于认证客户端发送的消息.

  • Server Authentication Key: 256 位 (32 个八位字节); 用于认证服务器发送的消息.

此结构确保派生密钥足以保护协议内的认证操作, 同时保持功能和方向性的清晰隔离.

如果服务器收到的初始 Setup Request PDU 因 authDigest 字段无效而认证失败, 则任何以及所有派生的密钥材料和密钥都必须视为无效.

从初始 Setup Request PDU 派生的密钥材料, 无论是在客户端发送前派生还是在服务器接收时派生, 都必须用于该测试连接中双方随后发送的所有 PDU. 因此, 每个测试连接中, 客户端和服务器只需执行一次 KDF.

附录 A 的图 12 提供了一个代码片段, 演示如何使用 OpenSSL 密码学库从密钥材料派生指定密钥, 具体使用高级 Key-Based EVP_KDF 实现 (Key-Based Envelope Key Derivation Function); 详情见 [EVP_KDF-KB].

5.5. 带状态过滤的网络功能配置 (Configuration of Network Functions with Stateful Filtering)​

与本地防火墙成功交互的前提是, 防火墙被配置为允许主机通过对给定传输协议发送一个使用唯一源地址, 目标地址以及端口号 (即 4 元组) 的数据包, 来打开使用该 4 元组的双向连接. 客户端与其防火墙的交互取决于此配置.

服务器侧防火墙必须为服务器 IP 地址和服务器标准 UDP 端口号配置开放针孔. 客户端发送给服务器的所有消息都使用这个标准 UDP 端口号.

服务器为每个测试连接使用一个临时 UDP 端口号. 假设服务器侧防火墙管理不允许开放 UDP 临时端口范围, 则服务器必须从 Test Setup Response 中告知客户端的临时端口号向客户端发送 Null Request. Null Request 可能无法到达客户端: 它可能被客户端防火墙丢弃.

如果服务器防火墙管理允许开放 UDP 临时端口范围, 则 Null Request 并非严格必要. 但是, 不能假定存在开放端口范围策略.

与防火墙相比, 网络地址转换器 (Network Address Translator, NAT) 预期会支持更广泛的一组操作配置. 除上述内容外, 涵盖 NAT 行为的规范超出本文档范围, NAT 与防火墙的组合实现也同样超出范围.

5.6. 可选校验和 (Optional Checksum)​

协议对其发送的所有 IPv4 和 IPv6 数据报都必须使用标准 UDP 校验和. 此校验和的目的是保护预期接收方, 以及可能收到损坏数据包的其他接收方. 这提供了:

  • 保护端点传输状态, 避免不必要的额外状态 (例如来自异常数据包的无效状态).

  • 保护端点传输状态, 避免内部状态被破坏.

  • 由端点预先过滤错误数据, 以保护传输层免受不必要处理以及其自身无法拒绝的破坏.

  • 在响应源地址之前, 预先过滤地址错误的目标数据包.

客户端与服务器之间交换的所有 PDU 都支持一个可选头部校验和, 该校验和覆盖 UDPSTP PDU 中的各字段 (不包括 Load PDU 的负载内容, 并且明确地说, 也不包括 IP 和 UDP 头部). 计算方式与 IPv4 数据包 Header Checksum 规范中使用的 16 位一补码 Internet 校验和相同 (见 [RFC0791] 第 3.1 节). 此校验和面向 UDP 数据完整性可能不确定的环境. 这包括接收时未验证标准 UDP 校验和, 或使用非标准网络 API 的情况 (这些做法通常用于提升低端设备性能). 但是, 通过 IPv4 或 IPv6 传输的所有 UDPSTP 数据报都必须包含标准 UDP 校验和, 以保护可能收到损坏数据包的其他潜在接收方. 在使用非标准网络 API 的情况下, 降低处理开销的一种选择可以是将测试限制为只使用全零负载内容, 这样 Load PDU 的 UDP 校验和计算就不必包含该内容.

如果 PDU 发送方填充 checkSum 字段, 则必须在 PDU 的其他所有方面都构建完成之后, 将其作为最后一步执行 (计算前 checkSum 字段设置为零). 随后, 只要已配置校验和处理且该字段已填充, PDU 接收方就必须验证 PDU 校验和. 如果 PDU 校验和验证失败, 则必须丢弃该 PDU.

由于与认证结合使用时存在冗余, PDU 发送方可以选择使用 UDPSTP checkSum 字段. 但是, 因为认证不适用于 Load PDU, 所以只要 UDP 数据完整性可能不确定 (如上所述), 发送方就必须使用 checkSum 字段.

最后于 更新