摘要

  • IESG 于 2026 年 6 月 22 日批准一份最佳当前实践指南：运营商不得通过跨越管理边界的 EBGP 路径属性传递 RPKI 派生验证状态。现行第 12 版已进入 RFC Editor 队列。
  • 这条边界同时保护证据和控制面。验证状态取决于本地缓存、本地时间和本地策略；把结果塞进未签名的路径属性既不能带走证据链，又会让 ROA 或 RTR 变化触发大批原本无须重发的路由。

五分钟并没有让故障结束

批准稿给出一个很具体的时序。它不是现实事故报告，而是用于暴露机制的推演：AS65536 是 AS65537 的客户，双方都使用同一个中央 RTR 服务，并以 300 秒为周期取得验证载荷；双方还会按验证状态给路由添加 BGP Community。

服务停止前一秒，AS65536 刚完成刷新；停止后一秒，AS65537 正好需要刷新。于是上游先失去新的验证载荷，原先标为 Valid 的大量路由转成 NotFound。因为这些状态写在路径属性中，上游必须向客户锥重新发送 UPDATE，AS65536 接收后继续传播。

约 300 秒之后，AS65536 的本地状态也到期。它再次改写 Community，第二轮 UPDATE 随之出现。即便部署缓存，若故障时间超过 TTL，缓存只能把两轮波动推迟，不能把它们合并掉。

这里真正变化的是哪个层次？不是前缀可达性，不是 AS_PATH，也不是起源 ASN。故障发生在验证数据供应层，负担却被转嫁给路由传播层。一个本应局限在本地决策中的状态，因获得了对外路径身份，变成全网需要处理的工作。

“有效”不是一张可以转交的证书

RFC 6811 规定了 NotFound、Valid 和 Invalid 三种起源验证状态。路由器从本地缓存取得已经处理的 RPKI 数据，再用本地保存的 VRP 对前缀和起源 ASN 做匹配。RFC 特别要求实现把结果看成该路由的本地属性。

“本地”不是措辞上的保守，而是证据结构。结果取决于依赖方抓到了哪些签名对象、哪些对象通过验证、缓存何时刷新、RTR 会话是否正常，以及本地策略如何使用结果。两张路由器在一段时间内拥有不同视图，并不必然说明其中一张失职。

Community 只能携带结论，不能携带生成结论所需的 VRP 集合、信任锚状态、刷新时点、缓存健康或策略规则。邻居看到一个绿色的 Valid，却拿不到重做这次判断的材料。

批准稿还指出，普通 EBGP 路径属性没有签名保证，第三方可能添加或修改所谓验证状态。因此，属性跟随路由到达并不证明它来自实际完成验证的节点，也不证明它仍然对应接收方此刻看到的 RPKI。它最多是发送方某一时刻内部机制的痕迹。

2017 年的标准已经画过边界

RFC 8097 定义过 BGP Origin Validation State Extended Community，目的在于让一个 AS 内的 IBGP speaker 共享计算结果，避免每台设备分别执行验证。这个扩展 Community 是非传递的；默认情况下，实现从 EBGP 邻居收到它时必须丢弃，也不应向 EBGP 邻居发送。

RFC 留下的例外同样清楚：两个相邻 AS 若属于同一管理主体，可能经配置收发该状态。决定范围的不是 AS 号码是否不同，而是证据、信任和责任是否仍在同一个管理域中。

新指南把这条原则从一个标准 Community 推广到所有可能造成跨域 UPDATE 的路径属性，包括普通、扩展和 Large Community，以及未来用来传递 RPKI 派生结论的属性。若 ASPA 或 BGPsec 的本地验证状态被以类似方式对外携带，也在同一范围内。

内部实现确实可能依赖状态属性。指南没有否认这种现实，而是要求运营商在向外部管理域通告 NLRI 之前删除它。内部便利不能悄悄升级为外部权威。

一个标签可以把变化乘到八十五万条路由

指南引用了两组带时间边界的数据。2024 年 2 月的一次 RIS 观测发现，所见 BGP UPDATE 中有 8% 至 10% 带有公开已知、用于表达 NotFound 或 Valid 的 Community；创建或删除一个 ROA 后，更新链持续约一小时。作者明确提示，这只是当时的测量。

指南还以 2026 年中为截面：IPv4 与 IPv6 合计路由表约 130 万条，约 65% 被 ROA 覆盖。若缓存崩溃或 RTR 会话终止导致状态变化，并且运营商把状态写进对外属性，可能需要重发超过 85 万条路由。

这些数字的价值不在于制造永久比例，而在于说明放大器的位置。一张 ROA 的变化本来只需让相关路由器重新验证并执行本地策略；中央缓存故障本来只需进入验证服务的连续性处置。属性一旦成为跨域路径的一部分，局部重新计算就变成邻居必须接收、存储和处理的大量路由替换。

攻击面也随之变化。能为自有前缀反复签发和撤销对象的攻击者，可以制造状态翻转；重新通告 NLRI 的一方也能直接改动未签名属性。若外部路径身份依赖这些状态，验证层事件就获得了驱动控制面震荡的杠杆。

邻居真正需要的是自己的当前证据

指南提出一个简单的收益检验：若上游已经在本地验证并执行 RPKI 策略，Invalid 路由理应没有被导入，也就不会再发给客户。客户实际收到的路由集合已经包含上游决策的效果。

下游若要形成自己的安全判断，应基于自己的当前 RPKI 视图验证。上游附带的 Valid 无法替代这一过程，因为它既未认证，也没有足够材料让下游重现。外部标签暴露了发送方内部过程，却没有提供可独立核验的外部控制。

这正是薄协调层应守住的界线：共同层负责能够被各参与方独立验证的最小互操作事实，而不是把一方的内部结论包装成另一方的准入许可。一个记录可以描述发生过的计算；跨越边界并不会让它自动获得决定权。

把三类事故重新分开

实践上的修复并不复杂。RPKI 材料在本地取得并验证，结果用于本地路由策略；内部 speaker 若必须共享状态，可以在管理域内完成；所有外部出口都应证明状态属性已被删除。

这样做也恢复了事故分类。缓存陈旧或 RTR 中断，是验证依赖故障；本地接受或拒绝结果变化，是策略事件；真实撤回路由，才是可达性事件。把三者都表达为对外路径属性变化，会让处置者误以为每次证据波动都是全网路由事实改变。

路由仍然可以传播，邻居仍然可以验证。唯一不应传播的，是某台路由器的结论天然带着所有证据、时效和授权的幻觉。

来源