摘要

  • RFC 2385 允许双方同步更换密钥，却没有提供协议内协商或密钥标识来完成这项同步。
  • RFC 5925 的 TCP-AO 用 KeyID 标明本报文的发送 MKT，用 RNextKeyID 公布发送方已准备在后续入站报文中使用的 MKT。

设想两台路由器之间的认证会话已经运行很久。运营方要轮换密钥，但网络里仍有使用旧密钥生成的报文在途。如果两端按墙上时钟同时切换，任何微小偏差都可能让合法报文看起来像伪造；如果为了保险而重建连接，又会丢掉长连接积累的状态。问题不是能否准备一把新钥，而是如何证明双方已经走到同一个切换阶段。

1998 年的 RFC 2385 为保护 BGP 会话定义了 TCP MD5 Signature Option。每个受保护报文携带一个 16 字节 MD5 摘要，所用秘密由两端独立配置。规范允许在连接期间更换密钥，条件是双方同步完成；但它既不协商密钥，也没有字段标明“本报文用了哪把钥”或“我已准备好下一把钥”。

2010 年的 RFC 5925 以 TCP Authentication Option 取代这套安排，并把认证状态拆开。Master Key Tuple（MKT）保存连接选择条件、标识符、密钥材料、算法及参数；每条具体连接再从 MKT 派生单向流量密钥。已经实例化的 MKT 组成部分不能在连接中改变，但可用 MKT 的集合可以变化，连接也可以转而使用另一个 MKT。

关键是 TCP-AO 选项里的两个单字节字段。KeyID 指出发送本报文时用于认证的 MKT；RNextKeyID 公布发送方已准备在后续入站报文中使用的 MKT。对端把这项公告作为信号，再依 RFC 滚动规则判断何时切换自己的出站 MKT 和 KeyID。它们不是秘密，也不是全球统一的钥匙名称，只是相关连接和配置内的协调索引。由于流量密钥有方向，发送状态和接收准备状态本来就不必同时移动。

滚动因此成为分阶段过程。一端先安装下一个入站 MKT，通过 RNextKeyID 公布它已准备使用这个 MKT。对端看到后，再按 RFC 状态规则判断何时改变自己的出站 KeyID；这项公告并不要求它在下一份 TCP 报文中立刻切换。在过渡窗口内，接收端仍可保留旧钥，验证已经离开发送端的在途报文。协议线上出现了明确进度，不再只能从时间表和 MAC 失败倒推。

这并不意味着 TCP-AO 自己管理密钥。它不协商主秘密，也不决定谁有权配置它们。MKT 来自静态配置或外部带外系统。TCP-AO 协调的是已获授权材料的使用，而不是创造授权。

现存 TCP MD5 连接也不能原地变成 TCP-AO。两者使用不同选项，RFC 5925 禁止同一连接同时使用二者；TCP MD5 连接建立后没有切换安全算法的路径。因此迁移到 TCP-AO 仍需越过新连接边界，但新连接内部的后续换钥可以保留传输状态。

RFC 5926 规定必要的 MAC 与密钥派生算法组合，解决互操作边界，却不规定运营者的主密钥或统一轮换周期。TCP-AO 提供报文完整性、真实性和重放防护，但不加密应用数据。

一手来源