摘要

  • RFC 2385 用共享秘密验证每个受保护的 TCP 报文段，验证失败即静默丢弃，降低了伪造重置报文破坏长期 BGP 会话的风险。
  • 为了塞进紧张的 TCP 选项空间，报文没有携带算法或密钥标识；摘要匹配只能证明这个报文段符合本地现有配置，不能证明密钥纪元、对端权限或路由真实。

一条很小的重置报文

BGP 选择 TCP，获得了有序、可靠的字节流，也继承了 TCP 的状态转换。攻击者若能猜中连接端点和序列号，就可能伪造一个 RST。TCP 连接关闭后，路由进程需要重新连接，甚至会暂时撤下从对端学到的路由。几十个字节的假报文，后果可以扩散到远大于它自身的范围。

RFC 2385 把防线放在传输层。受保护的 TCP 报文段携带 Kind 19 选项：一个类型字节、一个长度字节和 16 字节 MD5 摘要。摘要依次覆盖 IPv4 伪首部、不含选项且校验和视为零的 TCP 首部、报文段数据，以及双方预先知道的秘密。

接收端用自己的秘密重新计算。若结果不一致，报文段必须被丢弃，并且不能向发送者回复。日志可以记录，但远端不会得到一张“为什么失败”的回执。静默让伪造者少了一个探测接口，也让正常配置错误更难在网络上自证。

RFC 前面的 IESG 注释没有夸大成效。它把方案称为抵挡某些简单攻击的既有实践，同时承认面对有组织攻击仍有弱点。这里保护的是一个边界：哪些 TCP 报文段可以进入连接状态机，而不是整个 BGP 的真实性。

摘要匹配究竟证明什么

“Signature”很容易让人联想到身份签名。RFC 2385 的线粒度更细。匹配只说明：收到的报文段字节、伪首部中的端点地址、接收端选中的本地秘密，产生了同样的 MD5 结果。

它没有指出真实运营者是谁，没有证明某个 AS 有权发布某个前缀，也没有证明 UPDATE 通过导入策略、进入 RIB、写入 FIB，最后让业务数据包抵达目的地。即使连接一直处于 Established，也不能把这些后续结果倒推回来。

更关键的是，报文中连“使用了哪把密钥”都没有写。密钥身份来自路由器配置。若两端的变更记录不一致，报文段无法裁决哪个版本才是当前版本；实现只能按照自己选中的本地状态计算，然后得到通过或失败。

因此必须拆开证据链：报文段已经发出、选项确实存在、本地选择了某个秘密、摘要验证通过、TCP 接受报文、BGP 会话存续、UPDATE 被策略接受、路由进入控制面和转发面、最终业务可达。RFC 2385 只封住了这条链最前面的一段。

安全要求不在协商里

RFC 2385 明确不协商是否启用这个选项。是否强制保护，由站点策略和应用决定。远端不能通过在 SYN/ACK 中不带选项，诱使发送端自动降级。要求签名的一方仍然按本地规则处理；未签名的响应会被忽略，连接不会建立。

这是有价值的本地自主权。它也说明，真正的双边协议存在于报文之外。两端必须事先知道要启用保护，安装同一秘密，并在兼容的时间生效。网络上的静默失败无法区分：对端没有启用、双方密码不同、报文受损，还是有人正在伪造。

文档允许在连接期间更换密码，条件是双方同步。紧接着它承认了一个难题：某些实现的重传会出问题。使用旧秘密生成的报文段可能在接收端切到新秘密后才到达。选项里没有 KeyID，报文自己不能告诉验证端该使用旧状态还是新状态。

换句话说，算法计算是确定的，但它的前提——当前密钥纪元——没有成为可携带的共同状态。

没有出现的那个字节

TCP 首部长度字段把完整首部限制在 60 字节。固定首部占 20 字节，所有选项只剩 40 字节。RFC 2385 列出的 SYN 示例很紧：MSS、窗口扩大、时间戳、MD5 选项和填充，正好用完 40 字节。

MD5 选项占 18 字节：Kind、Length 和 16 字节摘要。RFC 发布时，MD5 的碰撞搜索问题已经受到关注，但规范仍固定使用 MD5。原因不只在密码学判断，也在已经部署的格式：Kind 19 没有算法类型字段。

文档把当时的取舍写得很直白。增加算法字段至少需要一个字节，选项会从 18 变成 19 字节，而实际实现很可能填充到 20 字节。在只有 40 字节的总预算中，两个有效字节会与其他 TCP 能力竞争。面向 1998 年的设备与实践，少占空间、继续互操作，是可以理解的工程选择。

代价在未来出现。Kind 19 无法在同一格式中表示另一种算法。想换算法，不能只改一个本地参数；必须定义另一个选项，建立新的兼容关系。省下的一个字段并非 TCP MD5 长期存在的唯一原因，却使算法选择恰好在需要跨实现确认的地方不可见。

Held Errata 4432 后来把首部长度描述中的“32-byte words”纠正为“32-bit words”。RFC 6691 又纠正了 MSS 处理：接收端公告的 MSS 只扣除固定 IP/TCP 首部，真正发送数据时才由发送端根据实际选项长度缩短负载。这些修订让历史记录更精确，但没有改变 40 字节选项上限，也没有补回算法字段。

被移到配置里的生命周期

RFC 2385 把共享秘密的形式交给应用和实现。报文格式因此保持很薄，密钥管理却没有消失。它进入路由器配置、运维流程和双方的时间协调。

RFC 3562 后来量化了这份工作：建议密钥长度为 12 至 24 字节，避免多个 BGP 对等关系共用同一密钥，并至少每 90 天更换一次。当时更现实的攻击不仅是抽象的 MD5 碰撞。短密钥可能被猜中，复用密钥会扩大泄露半径，不同步的换钥会直接切断会话。

RFC 2385 没有密钥编号、下一密钥提示，也没有为同一端点组合的新连接提供独立的重放区分。一个验证成功的报文段只能证明“某个本地配置的秘密有效”，不能证明它足够新、只用于这条对等关系，也不能证明它仍由预期的两台设备独占。

这正是“把决定留在本地”与“假装决定不存在”的区别。共同层可以很薄，但若完全没有可验证的状态，独立实现就无法安全地完成替换。

TCP-AO 补回了哪些状态

RFC 5925 用 TCP Authentication Option 取代 TCP MD5。TCP-AO 把算法放进可扩展的定义，增加 KeyID 与接收方下一密钥标识，为具体连接派生流量密钥，并对长连接和重复建立的连接提供重放保护。接收端不再需要让每个报文段在一组无名秘密之间猜测。

但 TCP-AO 仍不负责分发主密钥，也不在 TCP 内动态协商自己是否启用。运营者或外部密钥管理系统依然承担这些职责。它也没有把传输认证变成路由授权、加密或完整的 BGP 安全体系。

总表中已有一篇文章专门讨论 TCP-AO 的 KeyID、RNextKeyID 和双向密钥纪元。本篇不重复那段历史。RFC 2385 的独立问题更早：一项已经部署的防御能说“这个报文段符合我们共享的状态”，却无法说这个状态属于哪种可替换算法、哪把可识别密钥。

历史留下的边界

RFC 2385 后来被废止，不等于它在 1998 年毫无价值。它针对真实而狭窄的攻击，用当时设备能够承受的空间和运行实践提供了防线。它拒绝由未经认证的远端提示决定降级，也保留了运营者的本地控制。

更长久的教训属于证据设计。最小共同机制要足够薄，才能进入运行代码；同时又要暴露足够的状态，让不同实现能够验证、替换和迁移。如果算法和密钥身份完全留在报文之外，一次成功验证可以证明今天兼容，却不给明天的兼容留下可携带的路径。

互联网后来得到了更强的新选项。之所以必须是“新选项”，正说明旧格式的边界：RFC 2385 保护了报文段，但缺失的选择字段让算法无法在原有协议表面内演进。

资料来源