摘要

  • KeyID 标识当前发送报文所使用的 Master Key Tuple；RNextKeyID 只表示发送方希望用哪个 MKT 验证未来收到的报文。它既不携带秘密，也不确认对端已经切换。
  • TCP-AO 的状态具有方向性：每一端都有一把当前发送密钥和一把首选接收密钥。一项会话只有一个“活动密钥”的面板，恰好抹掉了换钥是否安全所需的四个事实。
  • 只有在两个方向都观察到新 KeyID、新 MKT 验证成功、BGP 稳定、重连通过、旧密钥依赖归零且回滚资料完整之后，旧 MKT 才具备退役条件。

这次故障不一定源于秘密分发失败。两个团队可能通过合规的带外通道拿到了完全相同的字节。真正的分歧发生在本地命名上：A 把新 MKT 的 SendID 和 RecvID 都设为 42；B 采用自己的编号规则，把 SendID 和 RecvID 都设为 43。变更单上，大家都把它称为“42 号密钥”。协议处理的却不是会议里的名字，而是每个方向的有效编号。

A 把新 MKT 设为首选接收密钥。它发出的 TCP 段仍以旧 KeyID=17 计算 MAC，同时宣告 RNextKeyID=42。B 可以用旧 MKT 正确验证这个报文。随后，它会针对这条 socket pair 查找 SendID 为 42、可用于发送的本地 MKT。如果没有匹配对象，RFC 5925 要求的不是报错，而是不采取切换动作。这个失败请求对应 B→A：B 继续用 17 发送。若 B 随后宣告 RNextKeyID=43，A 也必须先有 SendID 43 的就绪发送 MKT，才能把 A→B 切到新密钥。

这份沉默是一项安全边界。远端不能靠一个字节迫使本端使用不存在、未批准或已失效的密钥。问题在于，监控系统把“没有错误”翻译成了“换钥完成”。

两个编号分别约束两个方向

TCP-AO 是 TCP Kind 29 选项，携带 Length、KeyID、RNextKeyID 和 MAC。格式很小，职责也应保持很小：协调端点已经持有的密钥上下文，而不是在报文里交付密钥。

KeyID 描述正在发送的这个段。发送端从当前 MKT 取出 SendID；接收端把这个字节与本地 MKT 的 RecvID 以及源、目的地址和端口一起匹配，然后验证 MAC。一个方向的 SendID，必须与另一个方向的 RecvID 对上。

RNextKeyID 指向反向的未来流量。发送方把首选接收 MKT 的 RecvID 写进去，告诉对端：“以后你若用相应的发送 MKT，我已经准备接收。”对端收到后，仍需在自己的 MKT 集合中找到匹配的 SendID，才能把它设为新的 current_key。

这两个字节都没有密码学属性。0 到 255 只是任意标签，不要求随机，不要求递增，也没有保留值。两个方向可以使用不同数字；数字相同也没有特殊含义。两个抽屉都贴着 42，不代表里面的秘密、算法、MAC 长度、有效期和适用连接相同。

因此，RNextKeyID=42 的准确含义是：“如果你已经具备兼容的发送 MKT，我首选用 RecvID 42 接收。”它不是秘密交付回执，也不是双边同步证书。

真正的对象是 MKT，而不是标签

Master Key Tuple 不只是一串秘密。RFC 5925 把它与 TCP 连接标识绑定：本地和远端 IP、端口，以及实现可能支持的范围、掩码或通配方式。MKT 还包含 SendID、RecvID、主密钥、密钥派生算法、MAC 算法和是否把其他 TCP 选项纳入 MAC 的策略。管理系统还可能为它附加接收、发送或失效时间。

一个入站 TCP-AO 段必须根据 socket pair 和 KeyID 精确匹配一个 MKT。这意味着，相同秘密若落在错误的 VRF、地址族、对端范围、方向或 RecvID 下，就不是可用的同一个对象。

TCP 选项策略同样可能造成分叉。TCP-AO 自身的字段总会进入计算，只是在计算时把 MAC 字段置零。其他 TCP 选项是否纳入，则由 MKT 决定。两端若在这个开关、算法或 MAC 长度上不一致，即使主密钥字节相同，验证仍会失败。

可靠清单必须记录本地/远端地址与端口、路由实例、SendID、RecvID、算法、MAC 长度、选项策略、有效期、current/rnext 角色和 TCP 连接纪元。“42 已安装”无法授权任何不可逆操作。

主密钥不会直接给每个报文签名

TCP-AO 从 MKT 和连接上下文派生 traffic key。输入包括两端地址、端口，以及连接建立后的双向 Initial Sequence Number。发送与接收、SYN 与建立后的流量使用不同方向或类别的派生密钥。

因此，同一主密钥在不同对端、方向和连接纪元中会产生不同 traffic key。即使重连后地址与端口相同，新 ISN 也会改变认证上下文。旧连接上的成功抓包，不能证明新 SYN 一定选择并派生出相同的有效状态。

Sequence Number Extension 为长连接补充高位序列状态，在 32 位 TCP 序号回绕时维持重放防护。两个方向各自维护 SNE，并在建立连接时从零开始。调查 MAC 错误时，必须知道报文属于哪次连接，而不能只看一个离线报文。

派生机制减少了跨连接复用，却也揭示了“秘密指纹相同”的局限。指纹一致是必要证据，但编号、连接范围、方向、算法、选项策略和连接状态仍可能不一致。

一条 BGP 会话包含两套耦合的换钥状态机

每个非 IDLE 的 TCP-AO 连接，在每个端点至多有一个 current_key 和一个 rnext_key。前者认证出站段，后者表示首选的入站 MKT。一条 A—B 会话因此共有四项实质状态。

安全换钥首先是分发。新 MKT 在 A、B 两端都真正进入可接收状态，旧 MKT 继续有效。检查对象必须是运行中的 socket 状态；配置已提交，并不代表守护进程已经加载，或现有连接已经绑定。

然后处理 B 到 A。A 宣告新的接收偏好，B 用自己的 MKT 表解析这个 RNextKeyID。只有找到兼容项，B 才改变 current_key。B 第一个携带新 KeyID 的段被 A 正确验证，才证明这个方向完成切换。

A 到 B 必须独立重复。B 宣告偏好，A 本地解析并改变发送状态。在一段时间内，B 可能已经用新密钥发，而 A 仍用旧密钥发。这可以是合法的中间态，不应被单一“会话密钥”字段隐去。

最后才是退役。在明确的重叠期内覆盖配置传播、重传、观测延迟、重连和回滚，然后证明没有路径再依赖旧 MKT。

一个合格界面至少要显示 A→B 的 KeyID、A 宣告的 RNextKeyID、B→A 的 KeyID、B 宣告的 RNextKeyID，以及每一项在本端实际解析到的 MKT。就绪状态是一张矩阵，不是一个灯。

不切换，恰恰体现本地决定权

入站报文可以在旧密钥下完全合法，同时请求一个本端不存在的 RNextKeyID。此时不切换，是协议的正确行为。远端只能表达偏好，不能在本端凭空制造密钥，也不能延长或绕过本端的有效期政策。

共同规范只定义最小互操作语言；每个参与方根据自己可验证的状态决定是否采用。真正的采用发生在运行状态和流量上，不发生在一项宣告里。

所以，换钥证据必须追踪后果。收到 RNext 宣告后，对端的实际出站 KeyID 是否改变？新 MKT 的 good-MAC 计数是否增长？是否出现 key-not-found、RNext request、wrong MAC length 或 bad MAC？若仍使用 17，Established 只证明旧状态还活着，不证明 42 已就绪。

密钥供应与删除都在 TCP-AO 之外

RFC 5925 明确假设带外协议或人工机制供应新 MKT。它不定义秘密库、API、加密传输、审批者、轮换票据或恢复程序，也不协调旧 MKT 的删除。

RFC 6518 将这个缺口放回生命周期：密钥应有期限，避免长期暴露；但过于频繁的人工分发也会增加泄露和人为错误。路由传输层应支持不中断邻接的换钥，密钥管理机制则应让新鲜度真正可运营。RFC 7211 进一步强调先开放接收、再启用发送，检查 key table 一致性，并在过期前告警。

一份完整的权威记录，应说明谁生成秘密、明文可能出现在哪里、通过什么通道到达每一端、本地分配了哪些 SendID/RecvID、接收与发送何时开始、旧密钥何时结束、谁有权撤销变更。

这里所需的是实际运营控制：运营者能够检查有效 MKT、保管证据与回滚材料，在不依赖一个看不到双端事实的厂商面板时恢复 BGP。

删除旧密钥是不可逆边缘

安装会增加一种可能；删除会消灭一个退路。旧 MKT 仍在时，它可以支撑尚未切换的方向或回滚。两端删掉后，新纪元的任何分歧都会直接变成 TCP 可用性问题。

无限保留也不安全。若秘密已经泄露，只要接收端继续接受，它就仍有攻击价值。无期限重叠也允许系统悄然退回旧密钥而不触发配置违规。正确选择是“由证据界定的退役”。

先批准重叠时长，覆盖传播、重传、遥测滞后、受控重连和回滚窗口。分别记录两个方向最后一个旧 KeyID 与第一个新 KeyID，确认新 MKT 的 good-MAC 增长、bad-MAC 与 unknown-key 不增，BGP 保持稳定，路由数量和选择符合基线。

必须测试重连。一个长期存在的 socket 继承的 current/rnext 状态，可能与新 SYN 的 MKT 选择路径不同。旧连接稳定，不能证明下一次建立也成功。

Linux 官方文档提供 per-key 检查、good/bad、key-not-found、AO-required 等计数及多个 trace event，还提供强制删除并同时指定替代 current/rnext 的方式。文档也明确警告：若对端仍请求旧密钥，这个动作可能破坏连接。修复能力不能替代双向证明。

回滚必须恢复完整对象：socket 范围、SendID、RecvID、算法、MAC 长度、选项策略、有效期和秘密来源。“把 17 加回来”不是可执行的回滚说明。

正确 MAC 不会授权一条路由

TCP-AO 能证明一个 TCP 段符合预期密钥上下文，不会证明 UPDATE 中的前缀属于对方、AS_PATH 正确，或远端操作员有权发布它。持有合法密钥的真实 BGP peer 仍可能误配置、被入侵或故意发送坏路由。

RFC 4272 把外部注入攻击与真实 peer 的错误路由区分开。RFC 7454 因而把 TCP 保护、GTSM、控制平面过滤、prefix filter、max-prefix 和 AS-path policy 当作不同控制。

诊断也必须分列。bad MAC 应在 BGP 解析之前被丢弃；认证正确但未授权的前缀，应到达 import policy 后被拒绝；max-prefix 可以有意关闭一条密码学正常的会话。一个“peer security”总灯会摧毁这条因果链。

Canary 必须证明四个边缘

先精确识别会话：路由实例、两端地址、端口、BGP peer、TCP 纪元和路由基线。读取两端所有匹配 MKT，记录 SendID、RecvID、算法、长度、选项策略、有效期和角色。秘密只能通过受保护的指纹或受控验证比较，不能贴进工单。

第一步证明两端都能接收新 MKT，而旧流量仍能通过。第二步由 A 宣告偏好，捕获 B 第一个新 KeyID，并证明 A 首次成功验证。第三步反向独立完成，不从前一方向推导。

两个方向都进入新纪元后，发送 KEEPALIVE 和受控的 route refresh 或小范围 UPDATE，比较 Adj-RIB、已选路由、重传和状态机。经过重叠与重连，证明旧 KeyID 使用为零，再在 canary peer 上删除旧 MKT，并重复传输与路由检查。

TCP-AO 的价值来自克制。两个独立管理的端点只交换必要的本地标签，不让网络报文承担秘密分发权威。新密钥纪元也只有在双方都能解析、两个方向都能生成并验证、BGP 能承受重连、旧依赖归零且回滚仍完整时，才成为运行事实。在此之前，42 只是提议。