摘要

  • RFC 5925 在计算或验证 TCP-AO MAC 前，把本地维护的 SND.SNE、RCV.SNE 与 TCP 的 32 位序号组合起来。
  • SNE 不是报文新增字段；接收端必须根据序号变化、连接上下文以及回绕边界附近的乱序推断正确的高 32 位。

设想一条长期运行的路由会话已经传输足够多的数据。新的 TCP 报文终于带着一个曾经出现过的 32 位序号回来。TCP 接收窗口仍能判断它在当前字节流中的位置，但认证还有另一道问题：不能因为低位数字相同，就让两个不同历史时刻形成相同的 MAC 输入。

RFC 5925 为此引入 32 位 Sequence Number Extension。连接建立时，发送方向的 SND.SNE 与接收方向的 RCV.SNE 都从零开始。发送报文时，SNE 被放在 IP 伪首部和 TCP 材料之前参与 MAC 计算；接收端则先重建对应的高位值，再验证 MAC。两者合在一起，为认证模拟出 64 位序号空间。

关键设计恰恰是 SNE 不上网线。TCP-AO 没有增加另一个可能与 TCP 状态分叉的传输计数器。发送端可以在内部维护 64 位序号，直接取高 32 位；接收端只看到报文里的低 32 位，必须从这条连接已经发生的变化中推断 RCV.SNE。

RFC 给出了一种示例算法。序号从空间的高半区跨到低半区时，SNE 加一并设置标志。如果随后又收到高序号报文，那可能是跨越边界的乱序旧报文，应使用加一前的 SNE。标志要到另一处中间边界才清除，防止重复递增。这是可行实现示例，不是规范唯一规定的数据结构。

于是，相同的可见序号被归入不同的认证时代。SNE 不是时间戳、运营标识或全球计数器；它只属于某条连接的某个方向，可信度来自端点保存的连续历史。

来源