01 · RPKI 信任层级模型
RPKI 复用 X.509 公钥基础设施思想（RFC 5280），但嵌入了 RFC 3779 定义的"IP 地址与 AS 标识符"扩展，使证书不仅绑定身份，还绑定具体的互联网号码资源（IP 前缀与 AS 号）。其信任结构是一棵严格的层级树：
| 层级 | 角色与职责 | 密钥/证书特征 |
|---|---|---|
| L0 信任锚（RIR TA） | 五大 RIR（APNIC/ARIN/RIPE NCC/LACNIC/AFRINIC）各持有自签名根证书，是验证起点；通过 TAL 向 RP 公布 | 根私钥离线/强保护（类 DNSSEC 的 KSK）；证书有效期通常 1—5 年，需按 RFC 6489 做密钥轮换 |
| L1 RIR 生产 CA | RIR 运营的下级 CA，负责向成员/NIR 委托资源证书，并维护母存储库 | 由 HSM 保护；签发下属资源证书与 CRL/Manifest |
| L2 委托 CA / NIR | 从 RIR 获得资源证书并进一步向下委托；可自建 CA 与存储库（托管 RPKI 或自建 RPKI） | 例如 CNNIC 作为 APNIC 框架下的 NIR；大型 ISP 亦可成为委托 CA |
| L3 ISP / 终端持有者 CA | 最终资源持有者，签发 ROA 等终端对象授权其前缀的合法起源 AS | 多为托管模式（RIR 代签），少数自建 CA 自管密钥 |
| EE 证书 + 签名对象 | 每个 ROA、Manifest、CRL、Ghostbusters 均由一张一次性 EE 证书签名 | EE 证书短寿命（如 Manifest EE 7 天、ROA EE 18 个月，依 RIR CPS 而异） |
弹性含义：信任树的"扇出"意味着越靠近根，单点影响越大。一个 RIR 根 CA 的失效会波及该 RIR 全部分支；而一个委托 CA 的失效只影响其子树——这正是第3页"信任锚集中化风险"与"委托 CA 集中度"讨论的出发点。IANA 负责向五大 RIR 分配号码资源，但 RPKI 信任根本身分布在五个 RIR，不存在单一全球根（这与 DNSSEC 的根不同）。
02 · 证书与对象体系
2.1 两类证书
- CA 证书（RFC 6487）：用于委托与签发，持有 RFC 3779 资源扩展；其
Subject Information Access (SIA)指向该 CA 的存储库发布点。 - EE 证书（终端实体）：不用于委托，仅用于签署某一个具体对象（ROA/Manifest/CRL/Ghostbusters）；被父 CA 的 Manifest 列举。
2.2 核心签名对象
| 对象 | 规范 | 作用 / 弹性相关性 |
|---|---|---|
| ROA | RFC 6482（已由 RFC 9582 更新，正式名为 RouteOriginAttestation） | 声明"前缀—起源AS—maxLength"授权；是 ROV 的数据源。其可用性直接受存储库与 Manifest 影响 |
| Manifest | RFC 6486 → RFC 9286 | 枚举发布点内所有对象文件名与哈希，检测对象被抑制/替换；有自身的有效期限（见第5页） |
| CRL | RFC 5280/6487 框架 | 列出被撤销的证书；需定期重签，过期将导致相关对象失效（见第5页） |
| Ghostbusters | RFC 6493 | 以 vCard 形式记录 CA 维护者紧急联系方式，供 RP 在 Manifest/CRL 过期时联系处置 |
| ASPA（草案） | draft-ietf-sidrops-aspa-profile（IETF 草案，尚未 RFC） | 声明合法上游提供商，用于 AS_PATH 验证；同样发布于 RPKI 存储库，受相同单点故障影响 |
| Router Cert / 其他 | RFC 8205 BGPsec 等 | BGPsec 路由器证书等；属演进方向，部署有限 |
所有对象都依赖父 CA 的 Manifest 与 CRL：RP（依赖方）校验一个 ROA 时，不仅要验证 ROA 的签名，还要确认其 EE 证书未被父 CA 的 CRL 撤销，且其父 CA 的 Manifest 仍有效。因此，Manifest/CRL 的健康度是整棵子树可用性的"总开关"——这是第5页的重点。
03 · 存储库结构与发布机制
每个 CA 的出版物（证书、ROA、Manifest、CRL 等）存放于一个存储库发布点（Repository Publication Point），其结构由 RFC 6481 规定。CA 证书中的 SIA 扩展给出该发布点的访问 URI，目前支持两种协议：
| 协议 | 规范 | 工作机制 | 弹性评价 |
|---|---|---|---|
| rsync | RPKI 早期默认（RFC 6481 采用） | RP 通过 rsync 拉取整棵目录树，做增量同步；服务端 CPU/内存开销大 | 服务器易过载、难做 CDN 缓存、易被 DoS；但实现简单、历史悠久 |
| RRDP | RFC 8182（2017） | 基于 HTTPS，提供"更新通知文件 + 快照 + 增量 Delta"；内容发布后不可变，可经 CDN 高效分发 | 显著降低源站负载、可走 CDN 提升可用性、支持原子增量；是缓解存储库 SPOF 的关键 |
现代 RIR 的 TAL 与证书 SIA 通常同时携带 rsync 与 HTTPS（RRDP）两种 URI，RP 优先尝试 RRDP，失败再回退 rsync（详见第4、7页）。值得注意的是：即便使用 RRDP，对象本身仍由 CA 密码学签名，中间人无法伪造有效对象，但可实施 withhold/replay（扣留或重放旧数据），使 RP 无法获知更新——这本身就是可用性/完整性威胁（第6页详述）。
04 · 分发：RTR 协议
验证器（RP，如 Routinator、rpki-client）在本地完成全部 RPKI 验证后，需把 VRP 安全地交给路由器执行 ROV。这一过程由 RTR（RPKI-to-Router）协议完成：
- RFC 6810（2013）：首个 RTR 规范，定义基于 TCP 的会话与序列化协议。
- RFC 8210（2017，v1）：对 6810 的更新，是当前广泛实现的版本；默认端口 323（缓存到路由器）/324（路由器到缓存），实际部署常用 3323 等。
- 状态语义：RTR 仅传输"已验证的前缀—AS—maxLength"结果，路由器据此标记路由为 Valid / Invalid / NotFound。
- 会话保持：RTR 定义了会话重置、序号同步与"保持时间（hold time）"；一旦会话中断超过保持时间，路由器可能继续使用上次缓存或清空 VRP（取决于实现与本地策略）。
弹性盲点：RTR 通道本身也是一个单点。若验证器宕机、或 RTR 会话中断且本地无兜底，路由器要么使用陈旧 VRP，要么退化为"不验证"。更危险的是中间人篡改 RTR 会话（若未启用 SSH/IPsec 等安全传输），可污染路由器的 VRP 视图。RFC 8897 建议 RP 实现提供缓存备份管理与安全传输（如 IPsec）。第6页将进一步分析 RTR 通道的攻击面。
05 · 验证路径：TAL → VRP → ROV
一个 RP 完成一轮验证的标准路径如下，理解这条路径有助于精确定位"故障发生在哪一层"：
| 步骤 | 动作 | 可能失效点（对应本子课题） |
|---|---|---|
| 1 | 读取五个 RIR 的 TAL，定位各自根证书 | 信任锚根证书过期/私钥泄露（第3页） |
| 2 | 按 SIA 从存储库拉取 CA 证书、CRL、Manifest 与子对象 | 存储库不可达/非原子不一致（第4页） |
| 3 | 逐层校验签名、资源扩展（RFC 3779）、CRL 撤销状态、Manifest 一致性 | CRL/Manifest 过期导致对象被判失效（第5页） |
| 4 | 汇集通过验证的 ROA，生成 VRP 集合 | 上游任一层失效都会使 VRP 缺失/陈旧 |
| 5 | 经 RTR 将 VRP 推送到路由器，执行 ROV | RTR 会话中断/被篡改（第6页） |
关键洞察：RPKI 的"安全"是端到端的——任何一层的中断都会让最终 ROV 决策建立在不可靠数据上。本子课题的价值，正是把"端到端弹性"拆解为可度量、可加固的若干环节。
06 · 关键设计权衡
| 设计抉择 | 选项 A | 选项 B | 弹性权衡 |
|---|---|---|---|
| 信任根 | 单一全球根（类似 DNSSEC） | 五个 RIR 分散根（现状） | 现状避免了"全球单点"，但任何单一 RIR 根失效仍影响该区域；分散根也意味着 RP 需信任五个锚 |
| CA 模式 | 集中托管（RIR 代签） | 委托/自建 CA（去中心） | 委托 CA 增加单点数量但降低单点影响半径；前提是每个委托 CA 自身运维可靠 |
| 发布协议 | rsync | RRDP（HTTPS/CDN） | RRDP 显著提升源站可用性与抗 DoS；但引入对 CDN/TLS 的依赖与 withhold 威胁 |
| 失效时行为 | 严格：缺失即判 Invalid | 宽松：缺失视为 NotFound | 宽松（RFC 7115 思路）避免在存储库故障时大规模误删路由，但牺牲部分防御强度 |
小结：RPKI 的弹性不是由单一机制决定的，而是"分散信任根 + 委托 CA + RRDP/CDN + 冗余验证器 + 宽松兜底策略"共同构成的防御纵深。后续第3—7页将逐一剖析每个环节的失效模式与加固手段。
本节参考来源（第2页）
以下均为 IETF 标准原文与权威资料，用于支撑本页技术表述。
IETF RFC 6480《An Infrastructure to Support Secure Internet Routing》；RFC 6481《Repository Structure》；RFC 6487《X.509 Resource Certificates》：rfc-editor.org/rfc/rfc6480 等。
IETF RFC 3779《X.509 Extensions for IP Addresses and AS Identifiers》(2004)：rfc-editor.org/rfc/rfc3779。RPKI 资源扩展基础。
IETF RFC 8182《The RPKI Repository Delta Protocol (RRDP)》(2017)：rfc-editor.org/rfc/rfc8182。
IETF RFC 6810 / RFC 8210《The RPKI to Router Protocol》：rfc-editor.org/rfc/rfc8210。
IETF RFC 8897《Requirements for RPKI Relying Parties》(2021)：rfc-editor.org/rfc/rfc8897。RP 行为、缓存备份、安全传输建议。
IETF RFC 9582《A Profile for Route Origin Authorizations (ROAs)》(2024-05，更新 RFC 6482)：rfc-editor.org/rfc/rfc9582。
ICANN OCTO-014《RPKI Technical Analysis》(2020)：icann.org octo-014。五大 RIR 与信任锚结构说明。