01 · 弹性设计原则
RPKI 弹性提升不应依赖"某单一环节永不失效"的假设，而应假设失效必然发生，并让系统在失效时仍能维持"降级但可用"。本课题提炼四条原则：
| 原则 | 含义 | 落地抓手 |
|---|---|---|
| 防御纵深 | 不依赖单点，多层互备 | 多验证器、双协议、多存储库镜像 |
| 冗余 | 关键组件 ≥2 份、地理/网络分散 | ≥2 验证器异地部署；RRDP+rsync 双拉 |
| 优雅降级 | 失效时"少防护"而非"全错判" | 宽松 NotFound 语义、SLURM 本地兜底 |
| 可观测 | 失效可被及时发现与度量 | 发布点健康监控、VRP 新鲜度看板、告警 |
设计判据：任何弹性方案都应回答三个问题——当该组件失效时，(1) 影响多大比例的前缀/AS？(2) 影响持续多久？(3) 能否自动回退而不需人工介入？无法回答的方案，其"弹性"只是口号。
02 · 多信任锚冗余
- 现状基线：全球仅 5 个 RIR 信任锚，RP 默认加载全部五个 TAL。多信任锚"在信任根层面"已是冗余的——任一 RIR 锚失效不影响其他四个区域的验证。
- 强化方向：对关键网络，可额外维护各 RIR 的多 RRDP 镜像 URI（同一信任锚的不同发布端点）以缓解"锚可达但某发布点不可达"的情形；并定期演练"某 RIR 区域整体不可达"时本网的 ROV 退化评估。
- 密钥轮换预置（RFC 6489 + RFC 9691）：CA 应建立定期与应急两类的密钥轮换（KSK/CA key rollover）流程，并预演"根证书泄露"场景下的紧急轮换。2024 年发布的 RFC 9691（TAK 对象）为信任锚提供了带内轮换信号：TA 发布列有"当前密钥 + 后继密钥"的 TAK 签名对象，RP 经 30 天接受定时器自动验证并平滑过渡到后继密钥——使信任锚轮换从"停机事件"变为"不停机迁移"。根密钥泄露的应急轮换仍须依赖 CRL 撤销与带外 TAL 更新，二者应结合演练。
- CP/CPS 约束（RFC 6484）：将"可用性承诺"（发布时延、密钥保护、审计）写入各 RIR 的 CP/CPS，并对外接受度量（呼应第4、5页）。
03 · 分布式 / 冗余存储库（RRDP + CDN）
存储库是 SPOF 最高发的环节（第4页案例库）。弹性提升的核心是把"单 AS 托管"变为"多节点/CDN 分发"：
- RRDP 优先 + CDN 边缘：RRDP（RFC 8182）对象发布后不可变，天然适合 CDN 缓存。把存储库内容推到 CDN（如 Cloudflare/Amazon 边缘），可将源站负载与单点风险转移到分布式边缘（但需注意第4页指出的"仅 9/63 在 CDN"的现状差距）。
- 多发布点（SIA 多 URI）：CA 证书的 SIA 可并列多个 RRDP 通知文件 URI，RP 依次尝试，实现发布点级冗余。
- 原子发布：强制 Manifest 与其引用文件"同刻一致"切换，消除非原子不一致（AFRINIC 反复事故的病根）。draft-ietf-sidrops-publication-server-bcp（2026-03 为 -06 版）正将原子发布、重签调度与监控要求标准化，CA/发布服务运营者应对齐该草案的最新要求。
- 循环依赖规避：确保验证器至少有一条"不受本仓库所承载 ROA 约束"的访问路径（如经独立管理网/不同 AS 的 RRDP），打破第4页所述的"仓库宕机→AS 路由降级→更难访问仓库"死锁。
04 · 跨 RIR / 跨存储库故障转移
当某一 RIR 区域整体不可达时，单靠该区域内部的冗余已无能为力，需要"跨区"视角：
- 跨区验证互备：关键网络可在不同区域部署验证器，互为健康检查与数据比对；一旦某区域的 VRP 异常（如大面积 ROA 消失），可触发告警并暂用其他验证器的视图（需结合 SLURM 审慎兜底）。
- RRDP 镜像社区化：鼓励社区运行额外的 RRDP 镜像（第三方镜像），提升单点失效时的可替代数据源；同时依赖"对象签名"保证镜像内容不可被伪造。
- 标准推动：支持 IETF draft-ietf-sidrops-prefer-rrdp 的渐进落地，把对 rsync 的运营依赖降为兜底，并推动 draft-li 所述"存储库问题"进入标准化议程（多 admission/治理机制）。
05 · 冗余验证器与 RTR 冗余
- ≥2 个验证器、地理/网络分散：两个验证器应位于不同机房、不同上游网络，避免"同机房断电/同运营商中断"导致双双失效。两者独立拉取并验证，输出各自的 VRP。
- 多实现对冲：部署不同实现的验证器（如 Routinator + rpki-client + OctoRPKI），降低单实现 stale 处理偏差（第5页 §05）导致的集体误判。
- RTR 会话冗余：路由器配置到多个验证器的 RTR 会话；当主会话中断超过 hold time，自动切换到备会话，并使用本地 VRP 缓存避免清空。
- 安全传输：RTR 会话启用 IPsec 等安全传输（RFC 8897 建议），防止中间人篡改 VRP（第6页 §04）。
- 缓存备份：验证器定期落盘缓存备份，灾难恢复时可直接加载，缩短重建时长。
06 · 优雅降级：SLURM 本地兜底
当上游 RPKI 数据缺失/陈旧时，最危险的不是"不验证"，而是"基于错误数据做激进拦截"。SLURM（RFC 8416）提供了本地覆盖能力：
| 机制 | 作用 | 弹性价值 |
|---|---|---|
| SLURM 白名单 | 本地强制某些前缀/AS 的 VRP 结论（Valid） | 即便上游 ROA 暂时不可见，关键自身前缀仍被正确授权，避免误拦 |
| SLURM 黑名单 | 本地强制某些前缀/AS 的 VRP 结论（Invalid） | 即便上游撤销信息未能及时传播，已知恶意授权仍被拦截 |
| 宽松 NotFound 语义 | 缺失即视为 NotFound（不拦截），遵循 RFC 7115 思路 | 存储库故障时避免大规模误删路由 |
平衡提示：SLURM 是"兜底"而非"默认"。过度依赖本地白名单会削弱 RPKI 的全局一致性优势；应仅对"已知关键且稳定"的前缀使用，并随上游数据恢复及时复审，避免形成长期偏离全局视图的孤岛配置。
07 · 标准化缺口与未来方向
- RRDP 优先化落地：推动 draft-ietf-sidrops-prefer-rrdp 从草案走向标准，明确各阶段强制时间线。
- 存储库治理：将 draft-li-sidrops-rpki-repository-problem-statement 提出的"托管集中、循环依赖、规模爆炸"问题纳入标准与运营实践，研究合理的仓库准入/治理机制。
- 发布点健康信号：探索标准化的"发布点健康/新鲜度"信号，使 RP 能更快识别 stale 并触发告警或回退。
- 验证器互操作测试：建立跨实现的一致性测试（尤其 stale/非原子场景），缩小第5页所述的 RP 行为差异。
- 与 ASPA 的弹性协同：ASPA（草案阶段）对象同样发布于 RPKI 存储库，其路径验证的弹性依赖同一基础设施；未来 ASPA 规模化时须复用本子课题的弹性框架。
- RTR 协议 v2：draft-ietf-sidrops-8210bis 正在修订 RTR 协议，关注分发可靠性与新需求，路由器与验证器软件应跟踪其实现窗口。
- ASPA 的弹性复用与部署启动：ASPA 规范虽仍为草案，但 2025-12-15 起 RIPE NCC 已支持发布 ASPA 对象；其对象与 ROA 共用同一存储库/撤销机制，须在本子课题弹性框架内同步规划（尤其避免新对象类型放大 Manifest 非原子窗口）。
收束：RPKI 的弹性不是某一个补丁，而是"信任锚冗余 × 存储库多节点 × 验证器互备 × 优雅降级 × 可观测治理"的乘积。第8页将把上述方案转化为可执行的测量方法与实施路线图。
本节参考来源（第7页）
以下来源支撑本页的弹性方案与标准化方向。
IETF RFC 8182《The RPKI Repository Delta Protocol (RRDP)》(2017)：CDN 友好分发：rfc-editor.org/rfc/rfc8182。
IETF draft-ietf-sidrops-prefer-rrdp《RPKI Repository Requirements》（RRDP 优先化渐进方案）：datatracker.ietf.org。
IETF draft-li-sidrops-rpki-repository-problem-statement《RPKI Repository Problem Statement and Analysis》：datatracker.ietf.org。
IETF RFC 8416《SLURM》（本地 VRP 覆盖）；RFC 8897《RP Relying Party Requirements》（多验证器/安全传输/缓存备份）：rfc8416 / rfc8897。
IETF RFC 7115《Affirmation of the Current Practice of Not Filtering Based on Route Origin (RPKI 宽松 NotFound 语义)》：rfc-editor.org/rfc/rfc7115。
IETF RFC 9691《A Profile for RPKI Trust Anchor Keys (TAKs)》(2024)：带内信任锚密钥轮换信号与 30 天接受定时器：rfc-editor.org/rfc/rfc9691；RFC 9697《Detecting RRDP Session Desynchronization》(2024-09)：rfc-editor.org/rfc/rfc9697。