RPKI部署测量与效能评估第2页：RPKI技术体系与部署架构解剖

01 · RPKI对象模型：测量对象的解剖

RPKI是一套以X.509资源证书为基础（复用RFC 5280证书规范并加入IP/AS资源扩展）的密码学基础设施。测量的第一步是弄清"被部署的对象到底是什么"。RPKI存储库中部署与验证涉及的对象类型如下：

1.1 信任链示例

以一条RIPE NCC区域的ROA验证链为例：

RIR信任锚（RIPE NCC, 自签名）
  └─ CA证书（LIR：某会员机构，获授权 203.0.113.0/24）
       └─ EE证书（一次性签发，仅用于签署单个ROA）
            └─ ROA：{ asID: AS64496, prefix: 203.0.113.0/24, maxLength: 24 }  ← CMS签名对象
RP软件验证：TA指纹（TAL内嵌）→ 证书链逐层校验 → 资源授权包含性检查 →
            有效期/撤销状态检查 → 提取VRP (203.0.113.0/24, max=24, AS64496)

02 · ROV三态判定算法：效能测量的基准线

路由起源验证的判定规则由RFC 6483定义、RFC 6811给出操作框架：对BGP宣告{prefix p, origin AS a}，在本地VRP库中寻找匹配项：

for each VRP {prefix v, maxLength m, authorized AS asn}:
    if p ⊆ v 且 length(p) ≤ m:
        if a == asn  → 判定 Valid（存在授权，且起源一致）
        else         → 判定 Invalid（存在授权，但起源不一致 → 疑似劫持）
if 无任何VRP覆盖 p:
    判定 NotFound（无证据，默认接受 → 无防护状态）

• 最长前缀匹配优先：多条VRP同时覆盖时，以最长匹配VRP为准；VRP库中相同前缀可能存在多条记录（不同授权AS）。
• maxLength语义：声明"授权宣告允许的最长掩码"。若LIR只宣告/24却签署maxLength=24覆盖整个/16，攻击者仍无法以/25劫持（maxLength约束），但若maxLength=16而实际宣告/24，则合法宣告反而被判Invalid——这是ROA配置错误的主要来源之一（第7页展开）。
• 判定结果只是"输入"：路由器对Invalid路由的策略（discard / de-prefer / log-only）由本地配置决定，RPKI本身不强制任何动作——这导致"全球ROA覆盖率"与"全球实际防护率"之间必然存在落差（第5、6页的测量重点）。
• 验证状态可传播：RFC 8097定义了携带起源验证三态结果的BGP扩展团体属性，边界路由器的OV判定可沿iBGP传递给域内其他路由器，支撑"一处验证、域内一致策略"的部署形态——测量执行率时，"全网统一discard"与"仅边界执行"是两种不同的执行强度档位。

03 · RTR协议（RFC 8210）：执行测量的关键观测面

RTR是RP软件与路由器之间的验证结果分发协议，v1版由RFC 8210（2017）定义，废黜了2013年的v0（RFC 6810）。协议要点：

• 传输与会话：运行于TCP之上（约定服务端口323），通过Serial Number机制支持增量同步；支持IPv4/IPv6双栈VRP下发。
• PDU类型：Serial Query / Serial Notify / Reset Query / Cache Response / IPv4 Prefix PDU / IPv6 Prefix PDU / End of Data / Error Report等；Prefix PDU携带前缀、掩码、最大长度与起源AS，即VRP的线上编码。
• 会话重置：RP侧缓存重置或路由器会话异常时，触发全量刷新（Reset Query → Cache Response → 全量PDU → End of Data）。
• 安全考量：协议本身不强制加密（RFC 8210建议部署方以TCP-AO或隧道等方式保护会话），同一RP可为多台路由器服务，形成"一点验证、多点分发"结构。

3.1 RTR版本演进与兼容现状

04 · 存储库分发：rsync与RRDP双轨制

RPKI对象从RIR存储库到RP软件的同步存在两套机制，直接影响覆盖测量的采集时效：

RRDP的引入是RPKI测量史上的分水岭：2017年之前，全局覆盖统计只能做到"日级甚至更粗"的快照；RRDP普及后，RP软件（如rpki-client、Routinator）可将全部五大RIR对象的同步周期压缩至10—15分钟，使"接近实时的全球ROA覆盖仪表盘"成为可能（NIST RPKI Monitor、RIPE NCC统计均基于此）。

05 · 部署模式：托管与委托

资源持有者参与RPKI有两种模式，测量时必须区分（两者在存储库拓扑、证书控制权上差异显著）：

不同RIR的托管/委托成熟度不同：RIPE NCC与ARIN的托管服务较早成熟，APNIC提供托管与委托双轨，AFRINIC/LACNIC亦提供托管平台。测量上，托管比例高的区域ROA增长更快、错误率更低，这是区域对比（第4页）的重要解释变量。

06 · 信任锚体系与例外处理

• 五大信任锚：APNIC、ARIN、RIPE NCC、LACNIC、AFRINIC各自运营信任锚；IANA将号码资源按区域委托给RIR，RPKI信任结构与此一一对应（RFC 6491描述RIR代表IANA签发的对象）。
• 跨区迁移的历史对象：资源在RIR之间转移（如欧洲LIR迁入ARIN区域）时，历史ROA可能在旧RIR侧残留、新RIR侧未签，形成"幽灵VRP"——测量覆盖时若仅以"当前宣告前缀∩ROA"计算，会低估实际冲突风险；Testart等（IMC 2019）将此列为Invalid宣告的重要来源之一。
• SLURM本地层（RFC 8416）：RP软件支持管理员本地添加或过滤VRP。它是灰度上线（先log-only观察）与例外处置的标准手段，但也意味着"RP侧实际生效的VRP集"可能偏离"全球客观ROA集"——严肃测量应区分两集合并记录差异。
• 路由器和RP的角色分离：RP软件（验证者）与路由器（消费者）可同机或分离部署；大型网络常采用中心RP集群+边缘RTR分发结构，测量RTR会话规模时需按"每对会话"而非"每组织"计数。

本节参考来源（第2页）

以下均为真实可查的IETF标准原文与权威文档。