ROA数据质量分析与错误识别第6页：案例库：典型ROA错误与质量事件深度复盘

00 · 案例复盘方法

为保持严谨，本页所有案例统一采用"五步复盘法"，并强制标注性质：

A · maxLength过严导致的自伤型中断 【机制推演示例】

场景与成因

某网络为其前缀 198.51.100.0/23 签发ROA，maxLength设为23（"照前缀填"的常见做法）。为做流量工程，该网络在BGP中把前缀拆分为两个/24宣告。启用ROV的对等方依据RFC 6483，发现更具体的/24长度（24）＞ maxLength（23），判定其为Invalid并丢弃。结果：该网络自身的一部分流量路径被对等方切断，业务出现间歇性不可达——而故障源不是攻击者，正是自己签的ROA。

影响面与定位

• 影响：仅对"启用ROV且据此丢弃Invalid"的对等方不可达；未启用ROV的网络不受影响。这种"部分可达、部分不可达"的诡异表现，正是maxLength过严的典型特征。
• 定位信号：BGP中该/24被宣告、ROA覆盖/23且maxLength=23 → 长度差1即触发。本课题第4/5页的"maxLength vs 真实宣告长度"比对可提前发现。

处置与教训

将maxLength调整为真实最具体宣告长度（如24），或收回deaggregation、恢复单一/23宣告。教训：maxLength应等于"真实会宣告的最具体长度"，RFC 7454已明确此建议；创建ROA时应以"实际BGP宣告长度分布"为输入，而非仅看聚合前缀。

B · RPKI证书/Manifest过期或存储库一致性问题导致批量ROA失效 【机制推演示例】

场景与成因

RPKI对象依赖EE/CA证书与Manifest的新鲜度（见第2页）。若RIR的自动重签流程因运维中断而停摆，或某CA的Manifest更新滞后，依赖该子树的RP验证器会判定"不一致"，进而批量拒绝其中的ROA。由于一条RIR CA下挂着成千上万张ROA，这类故障的影响是规模化的：受影响网络的大量合法路由在启用ROV的对等方眼中突然变为Invalid。

影响面与定位

• 影响：跨越多组织、多前缀的瞬时失效；与"单条ROA写错"不同，它的影响面由CA子树规模决定，可能波及一国或一区域的众多网络。
• 定位信号：多个无业务关联的ROA在同一时刻集体失效；Manifest的thisUpdate显著滞后或EE notAfter集中越过。本课题"生命周期检查"（第4页）与"过期率"指标（第5页）专门用于预警此类风险。

处置与教训

RIR侧需保证重签/发布流水线的冗余与监控；网络侧应监控自身ROA的证书新鲜度（可借助Ghostbusters记录 RFC 6493 快速联系到证书持有者），并在启用ROV时设置"Invalid但来源可疑时先告警不立即丢弃"的灰度策略以降低突发失效的杀伤力。这也是子课题04（基础设施弹性）的研究对象。

说明：RPKI社区与多家RP实现维护方确实多次公开讨论过"Manifest陈旧/存储库不一致导致验证结果波动"的现象；本示例为对其机制的归纳，未特指某一具体日期或运营者。

C · 僵尸ROA与越界授权（资源转让未清理） 【机制推演示例】

场景与成因

某组织将其持有的地址块转让给另一主体后，忘记（或未能）清理原先为该地址块签发的ROA。于是存储库中仍驻留一张"授权某AS宣告该地址"的ROA，而该地址的合法持有方已变更。这类数据既是僵尸ROA（无对应真实宣告或归属错位），也可能构成over-claim（授权超出当前资源证书范围，因证书范围已随转让更新）。

影响面与定位

• 影响：不直接造成Invalid，但制造数据噪声、虚高覆盖率，并在地址易主后让新持有方陷入"我的前缀被别人ROA覆盖"的治理混乱；若被恶意方利用，可能造成错误授权争议。
• 定位信号：ROA前缀在RDAP中状态为已转让/回收，或签发者资源证书范围已不含该前缀。本课题"ROA × RDAP越界核验"（第5页）即为此设计。

处置与教训

建立"地址生命周期 ↔ ROA生命周期"联动：在RIR门户转让/回收地址时强制提示清理相关ROA；资源持有者定期审计ROA与RDAP状态的一致性。教训：ROA不是"签了就完事"，它必须随资源状态同步演进。

D · Cloudflare 1.1.1.1 事件（2024-06-27）：健康ROA + ROV 的防护实证 【真实公开事件】

事件概况

据Cloudflare官方博客（2024年7月初）公开复盘：2024年6月27日18:51 UTC，巴西ISP Eletronet S.A.（AS267613）开始宣告 1.1.1.1/32 主机路由（Cloudflare核实该宣告未经授权，确属BGP劫持——Cloudflare为1.1.1.1签发的ROA仅授权其自身AS宣告）；18:52，Nova Rede（AS262504）将 1.1.1.0/24 泄露给其上游 AS1031（Peer-1 Global Internet Exchange——AS1031未对客户会话做有效前缀过滤，而是按邻接关系整体重分发，从而放大了泄露范围，泄露路径中亦可见AS267613）。一家Tier-1运营商将这条更具体的/32宣告误判为RTBH（Remotely Triggered Black Hole，远程触发黑洞）路由而予以接受，进一步扩大了影响。事件波及70个国家、约300个网络对Cloudflare 1.1.1.1公共DNS解析器的访问（无法访问或严重降速），Cloudflare随后通过停用与AS267613的多处对等会话限制了泄露影响。

与ROA质量的关联

• 防护生效：Cloudflare在事件报告中明确指出，其自身已部署RPKI/ROV，自动拒绝Invalid路由，从而帮助减轻了事件的内部影响。这正说明：一张"正确且健康"的ROA（覆盖1.1.1.1/32且asID正确、maxLength合理、证书有效），是ROV能在劫持发生时自动拦截的前提。
• 反向印证质量重要性：若Cloudflare的ROA当时存在maxLength过严或错误asID等质量缺陷，其自身1.1.1.1/32路由反而可能被误判Invalid、自伤可用性——质量缺陷会直接抵消RPKI的防护价值。因此，该事件是"高质量ROA = 有效防护"的正面标杆，也是本子课题强调"质量优先于覆盖率"的强力注脚。

启示

高质量ROA的价值，只有在劫持/泄露真实发生时才显现。本案例同时连接子课题01（劫持检测，事件本身）与子课题03（ROA质量，防护前提）：没有健康的ROA，就没有可靠的ROV防护。

E · 合法的多ROA矛盾（迁移/任播窗口） 【机制推演示例 · 误报规避】

场景与成因

某组织将前缀的起源从AS-A迁移到AS-B。在迁移窗口内，它同时为同一前缀签发了两张ROA（asID=AS-A 与 asID=AS-B），以保证过渡期两种宣告都Valid。从"单ROA视角"看，这像"矛盾ROA（错误地多授权了一个AS）"，但实际上它是合法且有意的迁移操作。

为何是误报规避的典型

• 若质量分析规则简单粗暴地"同一前缀出现多asID即判错误"，会把这种合法迁移/任播/多归属场景误报为P1错误，进而给出"删掉其中一张ROA"的错误建议——可能恰好在迁移期制造中断。
• 本课题第4页的"白名单/已知合法模式 + 置信度分级"机制，正是为这类场景设计：多asID需结合"是否同时存在对应BGP宣告""是否标注迁移意图""是否为任播"等上下文，才决定是否告警。

启示

ROA质量分析的难点不在"发现异常"，而在"区分异常与合法例外"。本例是"宁可漏报边界、不可误判合法"原则（第4页）的生动注脚。

06 · 案例启示汇总

本节参考来源（第6页）

以下为真实可查权威来源；其中案例D为公开事件，其余为基于RFC机制与公开运营文献的推演示例（已在正文标注）。