01 · 五大 RIR 信任锚格局
全球 RPKI 的信任根由五个区域互联网注册管理机构（RIR）各自运营的根 CA 构成，其 TAL 随所有主流验证器（Routinator、rpki-client、OctoRPKI 等）分发。每个 RIR 负责其服务区域内的号码资源与 RPKI 委托：
| RIR | 服务区域 | 信任锚 URI（示意，随版本演进） |
|---|---|---|
| ARIN | 北美 | rsync://rpki.arin.net/repository/arin-rpki-ta.cer（历史上需接受 Relying Party Agreement，2022 年后已取消该前置要求） |
| RIPE NCC | 欧洲 / 中东 / 中亚 | rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer |
| APNIC | 亚太 | rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer |
| LACNIC | 拉美 / 加勒比 | rsync://repository.lacnic.net/rpki/lacnic/rta-lacnic-rpki.cer |
| AFRINIC | 非洲 | rsync://rpki.afrinic.net/repository/AfriNIC.cer |
重要事实修正：每个现行 RIR TAL 通常同时列出 rsync 与 HTTPS（RRDP）两个 URI，验证器优先尝试 HTTPS。RFC 8630（2019）为现行 TAL 规范，取代 RFC 7730 与 RFC 6490。RP 只需这五个 TAL 即可发现并验证全部公开 RPKI 数据——这既是 RPKI 的优雅之处，也是"信任收敛于五点"的弹性风险之源。
02 · 集中化的量化证据
RPKI 在设计上分散了"全球根"，但在实践与"委托结构"层面存在多重集中：
- 信任根数量少：全球仅 5 个 RIR 信任锚，任一锚的不可用即等于该区域 RPKI 验证能力中断。
- 委托 CA 高度集中：Gilad 等（NDSS 2017）指出，RPKI 的部署在少数 CA（主要是各 RIR 与少数大型委托 CA）上高度集中；对少量 CA 的攻陷或误操作即可影响巨大比例的 ROA。
- 大量 ROA 未对真实宣告形成有效保护：Gilad 等（NDSS 2017）指出，相当比例（约三分之一量级，具体口径依前缀数/地址空间统计而异）的 RPKI 授权因 maxLength 设置过长、覆盖范围与真实宣告不匹配等原因，无法抵御伪造源子前缀劫持。IETF 后续以 RFC 9319（BCP 185，2022-10）系统给出了 maxLength 使用建议——这说明"覆盖率"不等于"保护率"，弹性评估须区分两者。
- 存储库托管集中：据 draft-li-sidrops-rpki-repository-problem-statement 实测，63 个 RPKI 存储库中 60 个由单一 AS 托管，仅 9 个位于 CDN（其中 8 个在 Cloudflare AS13335、1 个在 Amazon AS16509）——即存储层可用性高度依赖少数网络。
03 · 单信任锚失效的级联影响建模
当某一 RIR 信任锚或其母存储库失效时，影响并非"平均分布"，而是沿信任树向下传播。我们可将其建模为"以信任根为顶点的依赖有向无环图（DAG）"：
| 失效点 | 直接后果 | 级联范围 |
|---|---|---|
| RIR 根 CA 私钥泄露 | 攻击者可伪造该 RIR 区域任意 ROA/证书 | 整区域乃至跨区（若对象被其他区域引用）资源断言被污染；需紧急密钥轮换（RFC 6489）与 CRL 撤销 |
| 母存储库不可达 | RP 无法拉取该 RIR 全部分支的更新 | 该区域新增/变更 ROA 不生效；已有 VRP 随缓存过期逐渐变陈旧（影响窗口取决于 RP 缓存策略与 hold time） |
| 顶级 Manifest 过期 | 该 RIR 整棵子树的对象被判失效/不可见 | 该区域 ROA 大面积"消失"（AFRINIC 案例实证，见 §05） |
| 委托 CA 失效 | 该委托 CA 子树的对象不可用 | 仅影响该委托 CA 客户；范围较小但对其客户是 100% 中断 |
关键结论：RPKI 弹性遵循"木桶原理"的反面——最脆弱的那个信任根/存储库决定了最差情况下的区域可用性。对一个全球运营的网络而言，即便其本区域 RPKI 健康，只要它依赖的某一 RIR 锚失效，其基于该区域 ROA 的防护就会退化。因此弹性必须按"最坏区域"而非"平均区域"来设计。
04 · 委托 CA 与 NIR 的集中度
为灵活管理，RIR 可将资源证书委托给 NIR（国家互联网注册管理机构）或大型 ISP 自建的委托 CA。这带来"去中心"的好处，但也引入新的集中度与运维责任：
- NIR 角色：例如 CNNIC 作为 APNIC 框架下的 NIR，在中国境内承担资源证书委托与 ROA 管理支持；其自身 CA 的可用性直接影响我国相关前缀的 RPKI 断言。
- 托管 vs 自建：多数成员使用 RIR"托管 RPKI"（RIR 代签、代管存储库），此时单点集中在 RIR；少数大型 ISP 选择"自建 CA + 自管存储库"，把单点从 RIR 转移到自身——要求自身具备 HSM、监控、密钥轮换等能力。
- 委托 CA 故障的"半径效应"：一个委托 CA 失效只影响自身客户，但若是覆盖广、客户多的大型 ISP CA，其影响半径仍可观。调查中 45.3% 的托管用户表示计划运行自有存储库（draft-li 调查），预示未来独立存储库数量将显著增长，既分散风险也增加管理面。
实证：单一委托 CA 的区域级影响。2023-05-15/16，nic.br（LACNIC 体系下的大型委托 CA）因损坏的根 Manifest 连续两日发生故障，单一 CA 的问题即导致 LACNIC 区域 41.37% 的 ROA 消失（packetvis.com 记录；软件 bug 于 5 月 31 日修复）。2024-02-11，nic.br 又因 Manifest 更新缺口约 6 小时造成大量 ROA 短暂消失。这印证了"委托 CA 分散降低单点影响半径"的前提是各委托 CA 自身运维成熟——否则只是把 RIR 级 SPOF 换成大型委托 CA 级 SPOF。
05 · 实证：AFRINIC 反复 Manifest 失效（区域性 SPOF）
AFRINIC 在 2022—2024 年间反复发生顶级 Manifest 失效，是"单信任锚/存储库故障 = 区域级 ROA 消失"的最直接实证。据 packetvis.com 对 RPKI 信任锚故障的公开统计：
| 时间 | 事件 | ROA 受影响 |
|---|---|---|
| 2022-11-20 | AFRINIC 顶级 Manifest 过期，约 73.95% 的 ROA 消失约 7 小时 | ≈ 73.95% |
| 2023-01-01 | 顶级 Manifest 引用了仓库中不存在的文件，部分验证器将整棵 Manifest 判为损坏并丢弃，77.33% 的 ROA 消失 | ≈ 77.33% |
| 2023-07-07 | 非原子仓库操作期间被 RP 抓取到不一致状态，25.35% ROA 消失 | ≈ 25.35% |
| 2023-08-25 | 同类非原子不一致，25.60% ROA 消失 | ≈ 25.60% |
| 2023-10-24 | 同类非原子不一致，22.51% ROA 消失 | ≈ 22.51% |
| 2024-01-18 | 同类非原子不一致，50.55% ROA 消失 | ≈ 50.55% |
机理：问题根源在于"非原子（non-atomic）仓库发布"——CA 在更新证书/对象时，Manifest 与其引用的文件未能在同一时刻一致地对外可见。RP 在更新窗口内抓取到的 Manifest 指向了尚不存在或已删除的文件，便将对象判为缺失/损坏，从而整片 ROA 不可见。随着 AFRINIC 区域 ROA 创建/删除频率上升，非原子操作窗口被更频繁地触发。该案例证明：即便密码学完整，发布层的单点（一致性）失效仍可导致区域性防御崩塌。
06 · 缓解：多锚冗余、密钥轮换与证书策略
- 多协议 + 多源拉取：RP 应同时配置每个 RIR 的 rsync 与 RRDP URI，并在主源失败时回退；对关键区域可配置多个 RRDP 镜像/CDN 端点（第4、7页详述）。
- 密钥轮换（RFC 6489）：CA 应建立定期与应急两类的密钥轮换（KSK/CA key rollover）流程，并预演"根证书泄露"场景下的紧急轮换，缩短污染窗口。
- 证书策略与 CPS（RFC 6484）：各 RIR 的 CP（证书策略）与 CPS（认证实践声明）定义了密钥保护、发布时延、审计等要求；弹性评估应将"是否符合 CPS 中的可用性承诺"纳入审计。
- 原子发布与监控：CA 软件须保证 Manifest 与所引用文件"同刻一致"地发布（AFRINIC 教训），并对外提供发布点健康度监控与 Ghostbusters 紧急联系人（RFC 6493）。
- 委托 CA 分散：鼓励大型持有者采用委托/自建 CA 以缩小单点影响半径，但前提是具备等效的运维成熟度（HSM、监控、轮换）。
治理视角：信任锚集中化不是"是否该有五个根"的问题（五个根已是合理折中），而是"如何让五个根各自足够健壮、且任一失效时不影响跨区互操作"的工程与治理问题。第7页将给出可运营的弹性增强清单。
本节参考来源（第3页）
以下来源支撑本页的信任锚格局、集中度数据与 AFRINIC 实证案例。
IETF RFC 8630《RPKI Trust Anchor Locator》(2019)，现行 TAL 规范：rfc-editor.org/rfc/rfc8630。
Gilad Y. 等《Are We There Yet? On RPKI's Deployment and Security》(NDSS 2017)，集中度与约 1/3 ROA 未真正保护前缀的结论：doi.org/10.14722/ndss.2017.23123。
packetvis.com《RPKI Trust Anchor Malfunctions: A Review of the Last 3.5 Years》（AFRINIC 2022—2024 反复 Manifest 失效统计）：packetvis.com/blog/rpki-trust-anchor-malfunctions。
IETF RFC 6489《Certificate Key Rollover in RPKI》(2012)：rfc-editor.org/rfc/rfc6489；RFC 6484《Certificate Policy for RPKI》(2012)：rfc6484。
IETF draft-li-sidrops-rpki-repository-problem-statement《RPKI Repository Problem Statement and Analysis》（63 个存储库 60 个单 AS 托管）：datatracker.ietf.org。
Hivebook RPKI 知识库（五大 RIR TAL URI 与 ARIN RPA 2022 取消等事实核对，2026 验证）：hivebook.wiki。
ICANN OCTO-014《RPKI Technical Analysis》(2020)：icann.org octo-014。
IETF RFC 9319（BCP 185）《Avoiding Route Origin Authorization (ROA) Pitfalls》(2022-10)：maxLength 与覆盖范围最佳实践：rfc-editor.org/rfc/rfc9319。