01 · 研究背景与意义
1.1 RPKI 作为"安全基座"自身的结构性脆弱性
RPKI 的目标是为 BGP 路由宣告提供密码学可验证的"来源合法性"证明，使路由器能够基于 ROA（路由源授权）执行路由起源验证（ROV）。然而，RPKI 自身的运行高度依赖一套分层信任链与集中式出版基础设施：从五个 RIR（区域互联网注册管理机构）持有的信任锚（Trust Anchor），到各 CA（证书颁发机构）签发的证书与对象，再到 RIR 或委托 CA 运营的存储库（Repository），最后经由 RTR 协议（RPKI-to-Router）分发给路由器。任何一环的失效、被控或被隔离，都可能削弱乃至瓦解 RPKI 对路由安全的保护能力。
一个常被忽视的事实是：RPKI 让路由层更安全的同时，也把"路由安全"这一关键能力收敛到了少数基础设施之上。换言之，RPKI 用"信任少数 CA 与存储库"替换了"信任所有 AS 的自觉过滤"，这降低了单点作恶的概率，却抬高了单点失效的潜在影响。本子课题正是要量化并缓解这一"安全基座"自身的脆弱性。
1.2 单点故障的五种形态
| 单点类型 | 失效表现 | 典型后果 |
|---|---|---|
| 信任锚（TAL） | 某一 RIR 的根 CA 私钥泄露、根证书过期，或其出版物长期不可达 | 整片信任子树无法被验证，对应区域 ROA 集体"消失"或降级 |
| 存储库（Repository） | rsync/RRDP 端点宕机、过载、被劫持或内容处于非原子（non-atomic）不一致状态 | 依赖方（RP）无法拉取更新，VRP 数据变陈旧，新 ROA 不生效 |
| CRL / Manifest | CA 未能按期重签 CRL 或 Manifest（软件故障、磁盘满、密钥轮换卡住） | 对象被视为"过期/失效"，合法 ROA 被错误标记为 Invalid 或 NotFound |
| RTR 通道 | RTR 会话中断、被中间人篡改，或验证器（Validator）宕机 | 路由器持有陈旧/被污染的 VRP，ROV 决策失真 |
| 委托 CA 私钥 | 委托 CA（如某大型 ISP、NIR）私钥泄露或被滥用 | 可签发恶意 ROA/证书，污染其整棵子树 |
1.3 威胁模型：当"保护者"自身失能
- 可用性攻击（最现实）：攻击者无需攻破密码学，只需让某 RIR 存储库不可达、让 Manifest 过期、或在 RP 刷新窗口内制造非原子不一致，即可使大量 ROA"看不见"。对依赖 ROV 的网络，这等价于削弱其防御。
- 完整性攻击：攻陷委托 CA 私钥或篡改存储库内容（在 RRDP 场景下实施中间人 withholding/replay），注入恶意 ROA 或撤销合法 ROA。
- 信任锚级攻击：针对 RIR 根 CA 的供应链/内部运维攻击（极低概率、极高影响），可动摇整个区域的信任根。
- 配置/运维事故（最常见）：真实世界中绝大多数 RPKI 可用性事件并非来自攻击，而是来自 CA 软件缺陷、磁盘满、DNS 误配、密钥轮换流程卡死——这正是本子课题测量的重点。
1.4 研究意义
对 RIR/NIR 运营者，本课题提供"RPKI 基础设施可用性度量框架"与失败模式清单，可前置发现单点；对网络架构师，本课题论证了冗余验证器、多协议拉取（RRDP+rsync）、SLURM 本地兜底等工程实践的价值；对标准与治理研究者，本课题量化了"信任锚集中化"与"存储库托管集中化"的系统性风险，为 RRDP 优先化、存储库去中心化等演进提供实证。需要强调的是：RPKI 的弹性不是"它是否安全"的问题，而是"它失效时互联网路由安全退化得多优雅"的问题。
核心科学问题：在 RPKI 信任链高度收敛于少数 RIR 信任锚与集中式存储库的现实下，如何（1）量化各类单点故障对 ROV 防护能力的实际影响窗口与范围（KQ-1）；（2）刻画 CRL/Manifest 撤销机制在重签延迟、传播抖动下的可靠性边界（KQ-2）；（3）设计可运营、低成本的弹性增强方案，使 RPKI 在局部失效时仍能以"降级但可用"的方式维持路由安全（KQ-3）？本课题围绕这三大关键问题展开。
02 · 研究目标与关键问题
- 韧性度量目标：建立可复现的 RPKI 基础设施可用性度量管道，覆盖五大 RIR 信任锚、其下委托 CA 与存储库的"可达性、内容新鲜度、验证时延"三类指标，输出可用性基线（如季度 Uptime、Manifest 重签周期、RRDP/rsync 双栈可用率）。
- 可靠性目标：刻画 CRL/Manifest 机制在"正常重签"与"重签失败"两种情形下的行为边界，明确何种失效会导致合法 ROA 被错误降级，并量化影响时长与范围。
- 加固目标：形成一套面向网络运营者的弹性部署清单（冗余验证器、多协议拉取、本地 SLURM 兜底、存储库可观测性），并评估各项措施对单点故障的缓解收益。
- 治理目标：向标准与治理界输出"信任锚集中化""存储库托管集中化"的量化证据，支撑 RRDP 优先化、存储库多元化等演进议题。
2.1 三个关键研究问题（KQ）
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 单点影响量化 | 当某 RIR 信任锚或存储库失效时，受影响 ROA 占比、影响 AS/前缀规模、VRP 恢复时延如何？不同 RIR 的集中化程度是否存在差异？ | 第3页 §02—§04 / 第4页 |
| KQ-2 | 撤销机制可靠性 | CRL/Manifest 的重签周期、传播抖动、过期判定规则，在"正常"与"CA 故障"下分别对 ROV 产生何种影响？RP 软件的 stale 处理策略差异有多大？ | 第5页 §02—§05 |
| KQ-3 | 弹性增强可运营性 | 冗余验证器、RRDP+rsync 双拉、SLURM 兜底、跨存储库故障转移等措施，在成本与收益上如何权衡？能否形成可落地的部署基线？ | 第6页 / 第7页 §02—§05 |
03 · 路由安全生态全景
3.1 生态参与方与职责
| 角色 | 职责/产出 | 代表 |
|---|---|---|
| 信任锚（RIR） | 持有根 CA 私钥、发布自签名根证书与 TAL，是整条信任链的起点；运营母存储库 | APNIC、ARIN、RIPE NCC、LACNIC、AFRINIC 五大 RIR；IANA 负责号码资源分配 |
| 委托 CA / NIR | 从 RIR 获得资源证书并向下委托，可自建 CA 与存储库，独立签发 ROA | CNNIC（APNIC 框架下 NIR）、大型 ISP（如 Deutsche Telekom、NTT 等的托管/自管 RPKI） |
| 存储库运营方 | 以 rsync 与/或 RRDP 方式对外发布 CA 出版物（证书、ROA、Manifest、CRL、Ghostbusters） | 各 RIR 默认存储库、委托 CA 自运营存储库（数量已从 5 个增长到 60+ 个） |
| 依赖方 / 验证器（RP） | 从 TAL 出发遍历信任树，拉取并验证所有对象，产出 VRP 经 RTR 发给路由器 | Routinator（NLnet Labs）、rpki-client（OpenBSD/RIPE）、OctoRPKI、RIPE RPKI Validator、Krill（CA） |
| 路由器 / 网络 | 通过 RTR 会话获取 VRP，执行 ROV（Valid/Invalid/NotFound），按策略丢弃或标记 | 启用 ROV 的大型网络（Cloudflare、Google、HE、AT&T、Telia 等） |
| 标准/治理 | 制定 RPKI 标准、CP/CPS、推荐部署实践，推动协同治理 | IETF SIDROPS/SIDR、五大 RIR、MANRS、NIST（RPKI Monitor） |
3.2 关键时间线（与弹性相关的里程碑）
| 时间 | 事件 |
|---|---|
| 2011-10 / 2012-02 | RFC 6490（TAL 初始规范）于 2011-10 发布；RFC 6480—6489、6491、6492 于 2012-02 批次发布，定义 RPKI 完整技术栈：框架(6480)、存储库结构(6481)、ROA(6482)、起源验证(6483)、CP(6484)、算法(6485)、Manifest(6486)、X.509资源证书(6487)、签名对象模板(6488)、CA密钥轮换(6489)、IANA对象(6491)、供应协议(6492) |
| 2013/2017 | RTR 协议 RFC 6810（2013）发布，RFC 8210（2017，v1）更新，定义 RP 与路由器间的数据分发通道 |
| 2016—2019 | TAL 规范演进：RFC 6490 → RFC 7730（2016）→ RFC 8630（2019，现行 TAL 规范）；Ghostbusters 记录 RFC 6493（2012）；RP 要求 RFC 8897 |
| 2017 | RRDP（RPKI Repository Delta Protocol）以 RFC 8182 发布，用 HTTPS/可走 CDN 的方式替代/补充 rsync，显著提升存储库弹性 |
| 2017—2022 | 多起真实 RPKI 可用性事件暴露单点脆弱性（RIPE NCC 2020—2022 多次、AFRINIC 2022—2024 反复、ARIN 2022 RRDP 中断）；Manifest 规范由 RFC 6486 演进为 RFC 9286（2022） |
| 2024—至今 | 2024-05 RFC 9582 发布（更新 RFC 6482，ROA 正式定名 "RouteOriginAttestation"）；2024 年 RFC 9691 发布，定义信任锚密钥（TAK）签名对象，为信任锚密钥轮换提供带内信号（30 天接受定时器）；RFC 9697（2024-09）定义 RRDP 会话失步检测机制。IETF sidrops 已提出 RRDP 优先化要求草案 draft-ietf-sidrops-prefer-rrdp《RPKI Repository Requirements》（最新版 -01，2021-10，近年未见更新，以 datatracker 实时状态为准）；存储库问题陈述（draft-li-sidrops-rpki-repository-problem-statement）量化托管集中化风险 |
| 2022-10 | RFC 9319（BCP 185）《Avoiding Route Origin Authorization (ROA) Pitfalls》发布，针对 maxLength 误用等 ROA 配置陷阱给出最佳实践——回应 Gilad 等（NDSS 2017）发现的"大量 ROA 未有效保护前缀"问题 |
| 2025—2026 | ASPA 规范（draft-ietf-sidrops-aspa-profile / -verification）持续推进（截至 2026-04 仍为草案，-25 版）；2025-12-15 起 RIPE NCC RPKI Dashboard 已支持成员发布 ASPA 对象。draft-ietf-sidrops-publication-server-bcp《Best Practices for Operating RPKI Publication Services》进入标准化流程（2026-03 为 -06 版），系统规范发布服务的原子发布、重签调度与监控要求 |
04 · 术语速查与常见误区
4.1 核心术语
| 术语 | 释义 |
|---|---|
| 信任锚（Trust Anchor, TA） | RPKI 信任链的根，由 RIR 持有自签名根证书；TAL（Trust Anchor Locator，RFC 8630）是 RP 定位并引导验证该根证书的起点文件 |
| CA / EE 证书 | CA（证书颁发机构）证书用于向下委托与签发；EE（终端实体）证书用于签署具体对象（ROA、Manifest、CRL、Ghostbusters） |
| 存储库（Repository） | CA 发布其全部已签名对象的文件系统/Web 服务，按 SIA（Subject Information Access）URI 对外提供，支持 rsync 与 RRDP 两种访问方式 |
| Manifest（清单） | 由 EE 证书签名的对象，枚举该发布点内所有对象的文件名与哈希，使 RP 能检测对象被抑制/替换；现行规范 RFC 9286 |
| CRL（证书撤销列表） | 由 CA 签发的被撤销证书序列号列表；RPKI 基于 RFC 5280/6487 的 X.509 框架，需定期重签 |
| VRP / ROV | VRP（Validated ROA Payload）是 RP 验证后的"前缀—起源AS—maxLength"三元组；ROV 是路由器据此对 BGP 路由做 Valid/Invalid/NotFound 判定的过程 |
| RTR 协议 | RPKI-to-Router（RFC 6810/8210），将 VRP 从验证器安全分发到路由器的协议，默认端口 323/324 |
| SLURM | Simplified Local Internet Number Resource Management（RFC 8416），允许运营者在本地对 VRP 做"白名单/黑名单"覆盖，用于异常兜底 |
| Ghostbusters 记录 | RFC 6493 定义的紧急联系人对象（vCard 形式），当某 CA 证书/CRL/Manifest 过期或异常时，供 RP 联系该 CA 的维护者 |
4.2 常见误区辨析
| 误区 | 辨析 |
|---|---|
| "部署了 RPKI，路由就安全了" | 错误。RPKI 提供的是"可验证的来源授权"，其有效性依赖整套基础设施持续可用。一旦存储库不可达或 Manifest 过期，ROV 将基于陈旧/缺失数据决策，防护能力随之退化。 |
| "RPKI 是去中心化的，没有单点" | 需澄清。RPKI 在密码学意义上是分层委托的，但信任根仍高度收敛于 5 个 RIR 信任锚，且许多存储库由单一 AS 托管。Gilad 等（NDSS 2017）已指出 RPKI 部署在少数 CA 上高度集中。 |
| "RSYNC 和 RRDP 二选一即可" | 误导。最佳实践是两者并存、RRDP 优先、rsync 兜底。真实事件（如 RIPE 2022-02-16 的 RRDP 不可达）证明：缺少任一协议的回退，都会放大可用性风险。 |
| "CA 过期只是理论风险" | 错误。AFRINIC 2022-11-20 顶级 Manifest 过期导致约 74%、2023-01-01 又达约 77% 的 ROA 在该区域"消失"数小时——这是反复发生的真实运维事故。 |
| "ASPA 已经是 RFC，可立即部署" | 需纠正。截至本课题撰写时，ASPA（自治系统提供商授权）仍处于 IETF 草案阶段（draft-ietf-sidrops-aspa-profile / -verification），尚未成为 RFC；将其称为"RFC 8970"系常见误引，请以 IETF 官方 datatracker 状态为准。截至 2026-04，ASPA 规范最新版仍为草案（draft-ietf-sidrops-aspa-profile -25）；但部署已在推进——2025-12-15 起 RIPE NCC RPKI Dashboard 已支持发布 ASPA 对象。引用时请以 IETF datatracker 实时状态为准。 |
05 · 研究范围与合规边界
- 对象范围：聚焦 RPKI 公共信任体系（五大 RIR 信任锚及其委托子树）的弹性与单点故障，覆盖信任锚、存储库、CRL/Manifest、RTR 通道、委托 CA 五类资产。
- 深度边界：本课题做到"失败模式建模 + 可用性度量 + 工程加固建议"层面；对 RPKI 密码学原语本身的安全性证明、具体 CA 软件代码级漏洞挖掘不在范围。
- 数据边界：仅使用公开数据（各 RIR 存储库、RRDP/rsync 端点、RIPE NCC Radar、NIST RPKI Monitor、公开的 incident 邮件列表归档、学术论文），不采集未公开的运营内部数据。
合规与伦理声明：①本课题以防御与韧性提升为目的，严格遵守《网络安全法》《数据安全法》《个人信息保护法》及《反电信网络诈骗法》；②对 RIR 存储库与 RRDP 端点的探测须遵守各 RIR 的服务条款与速率限制，避免对其造成额外负载；③文中对失效机理与攻击面的描述仅用于构建防御，不提供可直接复用的攻击配置；④所有事件归因均标注来源与置信度，不构成对任何机构的法律指控；⑤对受影响方的通报遵循负责任披露原则。
06 · 与课题体系协同关系
| 协同子课题 | 数据/方法交换内容 |
|---|---|
| 01 BGP路由劫持检测与溯源 | 本课题的"存储库失效导致 ROA 缺失"场景，可解释部分 Invalid/NotFound 误报，反哺劫持检测的抑制规则 |
| 02 RPKI部署测量与效能评估 | 本课题的可用性度量（Uptime、Manifest 新鲜度）是其"部署态势"的重要维度；对方提供各区域 ROA 覆盖率基线 |
| 03 ROA数据质量分析 | 本课题的"过期/缺失 Manifest 致 ROA 不可验证"机制，是 ROA 数据可用性问题的根因之一 |
| 05 ASPA与路径验证演进 | ASPA 对象同样发布于 RPKI 存储库，其弹性同样受本课题研究的单点故障影响；路径验证的弹性依赖相同基础设施 |
| 06 路由安全态势感知 | 本课题输出的"RPKI 基础设施健康度"指标，可纳入态势感知的底层基础设施健康看板 |
07 · 预期成果与交付物
- 《RPKI基础设施弹性与单点故障研究报告》（含五类单点失败模式库、可用性度量方法论、弹性加固清单）
- 五大 RIR 信任锚与存储库可用性基线（季度 Uptime、Manifest/CRL 重签周期、RRDP/rsync 双栈可用率）
- 真实事件案例库（2020—2024 年 RIPE NCC / AFRINIC / ARIN / JPNIC 等公开 incident 的结构化复盘，见第4、5页）
- CRL/Manifest 可靠性边界分析（重签延迟、传播抖动、RP stale 策略差异对 ROV 的影响模型）
- 运营者弹性部署清单与上线检查表（见第7、8页）
08 · 研究风险与局限性
为保证研究结论的可信度，特声明以下局限，供读者在引用本课题结论时权衡：
- 测量覆盖偏差：被动测量依赖 RIPE RIS、Route Views 等公共收集器，其对中小型网络的覆盖存在盲区；NIST RPKI Monitor 亦声明其结果"仅供设计与标准化讨论"。故本课题的区域性结论（尤其涉及非洲、拉美地区）存在系统性低估或高估的可能。
- 事件归因的不确定性：RIR 对故障的公开程度不一（AFRINIC、LACNIC 多起事故至今无技术报告，部分根因依赖社区排查推断）。本课题所有事件归因均标注来源与置信度；对仅有社区转述、缺乏一手报告的案例已作明确标注。
- 草案时效性：本课题引用的多个 IETF 草案（prefer-rrdp、repository-problem-statement、aspa-profile、publication-server-bcp、8210bis）仍处演进中，其编号、版本与内容可能变化；引用时请以 datatracker 实时状态为准。
- 数据时效性：存储库数量、ROA 覆盖率、托管集中度等数字均为特定时点快照（2024-06 至 2024-08），随 RPKI 部署增长会快速变化；本课题承诺按季度刷新基线。
- 研究边界：本课题不评估 RPKI 密码学原语强度，不对具体 CA 软件做代码级审计；对路径验证（ASPA/BGPsec）仅讨论其与本课题共享的基础设施弹性，不评估路径验证本身的攻防。
方法论声明：本课题遵循"可核验优先"原则——每一项关键数据均给出可公开访问的一手来源（RFC/IETF、RIR 公告、同行评审论文、知名工程师的公开测量）；对无法一手核验的表述一律降级为定性描述或标注置信度，不以推测充当事实。
本节参考来源（第1页）
以下均为真实可查的权威来源（IETF 标准原文、RIR 公开事故邮件列表、学术论文、NIST/ICANN 技术报告），用于支撑本页事实性表述。
IETF RFC 6480《An Infrastructure to Support Secure Internet Routing》（2012-02）及 RFC 6481—6492 系列：rfc-editor.org/rfc/rfc6480。RPKI 核心框架与证书/存储库/ROA/Manifest/TAL 规范族。
IETF RFC 8630《Resource Public Key Infrastructure (RPKI) Trust Anchor Locator》（2019-08，现行 TAL 规范，取代 RFC 7730/6490）：rfc-editor.org/rfc/rfc8630。
IETF RFC 8182《The RPKI Repository Delta Protocol (RRDP)》（2017-07）：rfc-editor.org/rfc/rfc8182。基于 HTTPS、可走 CDN 的弹性存储库分发协议。
IETF RFC 9286《Manifests for the Resource Public Key Infrastructure (RPKI)》（2022-06，取代 RFC 6486）：rfc-editor.org/rfc/rfc9286。
IETF RFC 6493《The RPKI Ghostbusters Record》（2012-02）；RFC 8897《Requirements for RPKI Relying Parties》（2021）：rfc-editor.org/rfc/rfc6493 / rfc8897。
Gilad Y., Cohen A., Herzberg A., Schapira M., Shulman H.《Are We There Yet? On RPKI's Deployment and Security》(NDSS 2017)：doi.org/10.14722/ndss.2017.23123。指出 RPKI 部署集中化与约 1/3 ROA 未真正保护前缀等安全问题。
RIPE NCC Routing Working Group 公开邮件列表（2020—2022 多起 RPKI incident 事后复盘）：ripe.net routing-wg。
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 draft-li-sidrops-rpki-repository-problem-statement《RPKI Repository Problem Statement and Analysis》（存储库托管集中化量化：63 个存储库中 60 个由单一 AS 托管）：datatracker.ietf.org。
ICANN OCTO-014《RPKI Technical Analysis》（2020-09，五大 RIR 与信任锚结构说明）：icann.org octo-014。