摘要

  • RIPE 93 官方摘要称，2026 年 8 月 8 日至 14 日，有 786 组前缀与来源 ASN 在 IRR 中精确匹配，却整周维持 RPKI Invalid。
  • 其中 371 组超出 ROA 允许的最长前缀，415 组来源 ASN 不符。一个红灯，背后是两种排查路径。

记录在册，签名不认。网络工程师最怕的不是两套资料各说各话，而是自动脚本替人假装它们已经和解。RIPE 93 公布的研究摘要给出一组具体样本：Antonis Chariton 和 Usama Ejaz 对齐 8 月 8 日至 14 日的路由资料，发现 786 组有精确 IRR 记录的前缀与来源 ASN 始终被 RPKI 判为 Invalid。报告安排在 10 月 27 日星期二发表；目前可核对的是会前摘要。

这 786 组还要再拆开看。371 组的通告前缀比 ROA 允许的最长长度更细；另 415 组的来源 ASN 与授权不一致。RIPE NCC 对 ROA 的说明清楚区分这两类 Invalid。前者先查前缀拆分和授权长度，后者先查谁在宣告。IRR route 对象精确匹配，只说明某个登记来源写下了相同的前缀与来源组合。

研究使用 57 个 RIPE RIS 与 RouteViews 收集器、19 个 IRR 来源，以及整周可用的 17 个 RPKI 依赖方视图。在一周观察到的前缀—来源组合并集中，64.4% 有精确 IRR 匹配；而这些匹配中的 79.9% 只见于一个 IRR 来源。一个来源发出的绿灯，不能因为被两个系统读取就变成两份独立证据。

客户路由过滤还会碰到 AS-SET。研究另以 8 月 8 日资料重放 PeeringDB 声明的 AS-SET 递归展开，保留了 99.27% 的精确 IRR 匹配。未完成或无法解析的展开仍须人工核查。脚本找不到成员，可能是查询链断了；在过滤器里直接删掉这条来源，后果却会落到客户连接上。

RFC 6811定义验证状态，把后续过滤交给明确的本地策略。运营者在改规则前应把前缀、来源 ASN、IRR 来源、ROA 的冲突字段、观察时间、AS-SET 展开状态放进同一张决定单。谁控制过滤器，谁就应留下为何放行或拦截的记录。