ROA数据质量分析与错误识别第2页：ROA技术体系、数据模型与错误原理

01 · ROA在RPKI信任链中的位置

ROA并非孤立存在，而是RPKI密码学信任链末端的"签名对象（Signed Object）"。理解整条链，才能理解"ROA是如何被验证器信任、又会在哪个环节失效"的。

1.1 从信任锚到ROA的五层结构

1.2 Manifest与CRL：容易被忽视的"同步闸门"

RPKI的可用性高度依赖Manifest（RFC 6486）与CRL（证书撤销列表）。Manifest是一份"内容清单"，列出某CA下所有已发布对象的哈希值；验证器会先核对Manifest，确认拉取到的对象与签发者发布的一致。一旦Manifest或CRL因发布流程故障而陈旧（stale）或未及时更新，许多RP实现会据此判定该CA子树"不一致"，进而拒绝其中的ROA——即便ROA对象本身毫无问题。这正是第1页所述"生命周期型/存储库型"缺陷的典型来源，也是ROA质量监控必须覆盖Manifest新鲜度的原因。需要说明的是，Manifest规范RFC 6486已被RFC 9286（2022年6月）更新取代，生产RP实现普遍遵循新版；引用与实现时应注意版本对应关系。

02 · ROA对象数据模型（RFC 6482）

RFC 6482以ASN.1定义了ROA的精确结构。准确记忆这一结构是识别字段级错误的前提。一个ROA对象的核心字段如下：

RouteOriginAttestation ::= SEQUENCE {
    version         [0] INTEGER DEFAULT 0,        -- 版本号（默认0）
    asID                ASID,                     -- 被授权的起源AS号
    ipAddrBlocks        SEQUENCE OF IPAddressFamily  -- 被授权的前缀族
}

IPAddressFamily ::= SEQUENCE {
    addressFamily      OCTET STRING,              -- IPv4(0001)或IPv6(0002)
    addresses          SEQUENCE OF ROAIPAddress
}

ROAIPAddress ::= SEQUENCE {
    address            IPAddress,                  -- 前缀（含掩码）
    maxLength    [0] INTEGER OPTIONAL             -- 可选的最大前缀长度
}

2.1 三个必须精确的字段

• asID：唯一被授权作为该组前缀起源的AS号。若填写错误（如写成上游/邻居AS），则真实宣告者会被判Invalid——这是高频"配置型"错误。
• address（前缀）：授权覆盖的地址块。注意一个ROA只能包含同一地址族的前缀（IPv4与IPv6必须分两个ROA）；一个ROA可包含多个前缀，但它们共享同一个asID。
• maxLength（可选）：限定被授权前缀可被宣告的最大掩码长度。它约束的是"宣告的具体程度"，而非"覆盖范围的下限"。省略maxLength等价于"只允许与address完全相同长度的前缀"（即maxLength = address前缀长度）。

2.2 一个常被误解的语义：ROA授权的是"范围"，不是"精确前缀"

设某ROA声明：asID = AS64500，address = 203.0.113.0/24，maxLength = 24。它授权AS64500宣告203.0.113.0/24 这一条（因为maxLength=24=前缀长度，不允许更具体）。若改为maxLength = 23，则授权AS64500宣告203.0.112.0/23 及其任何更具体前缀（含203.0.112.0/24、203.0.113.0/24）。因此：maxLength必须大于等于address的前缀长度才有意义，且它开放的是"更具体"一侧。把maxLength设得比address本身还小，该ROA实际上无法匹配任何真实宣告（因为宣告至少要与address等长），属于逻辑错误。

2.3 ROA的物理形态：CMS签名对象（RFC 6488）

在存储库中，一个ROA文件（.roa）并非裸ASN.1，而是符合RFC 6488《Signed Object Template for the RPKI》的CMS（Cryptographic Message Syntax, RFC 5652）签名对象：外层为CMS SignedData结构，content字段内嵌上述RouteOriginAttestation内容，由EE证书对应的私钥签名。RP验证器正是按这一模板解析与验签的。这意味着：质量分析的对象粒度是"CMS签名对象"而非纯数据字段——任何编码不合法（如非DER编码）的对象在解析阶段即被淘汰，这本身就是一道前置质量闸门。

2.4 路由器侧的消费通道：RTR协议（RFC 6810 / RFC 8210）

RP验证器并不让路由器直接解析RPKI对象，而是通过RTR（RPKI to Router）协议下发验证结果：RFC 6810定义v0，RFC 8210定义v1（增加expires等参数，推荐用于生产）。路由器以RTR客户端身份周期性地从RP获取VRP集合，并据此执行ROV。由此形成一条"RIR存储库 → RP验证 → RTR下发 → 路由器判定"的完整链路——链路中任何一环（存储库不可用、RP验证失败、RTR会话中断）都会改变路由器看到的ROA视图，质量分析必须区分"ROA本身错误"与"消费链路异常"。

03 · ROV验证算法与三态判定（RFC 6483）

RFC 6483规定了路由器（或RP验证器）如何把一条BGP路由（起源AS = O，前缀 = P）映射为三种状态。算法逻辑严谨但存在若干易错点：

3.1 判定流程

1. 在ROA库中查找覆盖前缀P的所有ROA（即ROA的address是P的less-specific或equal，且前缀族匹配）。
2. 若没有任何ROA覆盖P → 状态为 NotFound。
3. 若存在覆盖P的ROA集合：
   • 若其中至少一条ROA满足：asID == O 且（该ROA对此前缀无maxLength限制，或 P的长度 ≤ 该ROA的maxLength）→ 状态为 Valid。
   • 否则（所有覆盖ROA要么asID≠O，要么maxLength过小）→ 状态为 Invalid。

3.2 三个易错点（直接关联数据质量）

3.3 一个特殊的质量相关对象：AS 0 ROA（宣告否定，RFC 6483第4节）

RFC 6483第4节定义了AS 0 ROA：asID填0的ROA是前缀持有者对其地址块及其所有更具体前缀的"不应在路由中使用"的密码学声明。按惯例其maxLength应设为32（IPv4）/128（IPv6）。它在质量分析中有两类关联：其一，它是合法的"否定型授权"，错误检测规则必须把asID=0识别为合法取值而非"错误asID"；其二，当持有者永久下线一段地址时，用AS 0 ROA兜底否定比"删除ROA"更稳妥——删除只会让前缀回到NotFound（无保护），而AS 0 ROA能让其所有更具体宣告被判Invalid，防止地址回收后被他人劫持利用。这是本课题"僵尸ROA治理"中值得推荐的规范化处置手段。

04 · ROA生命周期与签发/吊销

ROA不是"签一次永久有效"的静态数据，而是有生命周期的密码学对象。理解生命周期，才能理解"过期"类质量缺陷为何系统性存在。

4.1 签发链路（Provisioning）

资源持有者通过RIR/NIR的门户或RFC 6492定义的供应协议（Provisioning Protocol）请求签发ROA；RIR在其资源证书下生成一张短期EE证书，用它对ROA内容做CMS签名，再把ROA与其Manifest发布到存储库。整条链路涉及多张证书的有效期叠加。

4.2 有效期与重签（Re-signing）

• EE证书有效期短：ROA绑定的EE证书通常有效期较短（常见数天至数月），需要由RIR的签发系统自动定期重签。若RIR侧自动化流程出现中断，批量ROA会在EE到期后同时失效。
• CA证书轮换：RIR根CA/中间CA证书也有有效期，需按RFC 6489（CA Key Rollover）进行密钥轮换，新老证书需有一段重叠期以保证平滑过渡；轮换失败会造成大范围失效。
• 业务侧变更：当持有者转让地址、下线业务、变更起源AS时，必须主动吊销或更新对应ROA，否则留下僵尸/越界数据。

4.3 吊销机制

ROA的"吊销"主要通过两种机制体现：①在存储库中删除该对象并更新Manifest；②在CRL中标记其EE证书为已撤销。验证器据此判定对象不再可信。质量分析中，"本应被吊销却仍在库"与"已删除却因Manifest滞后仍被部分RP看到"都是需要关注的边界情形。

05 · 错误产生的根因分类

把第1页的威胁模型落到"技术根因"层面，ROA质量缺陷可归纳为四个相互交叉的根因族。第4页将在此基础上建立可操作的错误分类学。

5.1 同一缺陷在不同RP下的后果可能不同：RFC 6487 与 RFC 8360

按RFC 6487的严格验证模式，资源证书越界（overclaim）即整体拒绝；而RFC 8360《Resource Public Key Infrastructure (RPKI) Validation Reconsidered》（2018年）定义了替代验证流程：签发CA可通过特定的策略OID声明"按交集接受"——即对越界证书只接受其与签发证书资源范围的交集部分。这意味着同一张over-claim ROA，在严格模式RP下被整体拒收，在交集模式RP下可能部分有效。质量分析报告必须注明所依据的验证模式，否则同一结论在不同读者环境中会得出不同的处置判断。这也是本课题在采集环节记录RP实现与版本号的原因。

06 · maxLength的深层陷阱

maxLength是ROA中最容易被"好心办坏事"的字段，值得单列。它同时影响"防护强度"与"误伤风险"两个相反的方向：

• 过严（maxLength < 真实最具体宣告长度）：合法运营商为流量工程对前缀做deaggregation（如宣告/24而非/23），但ROA maxLength只到/23，则更具体的/24被判定Invalid → 启用ROV的对等方丢弃 → 自伤型中断。这是部署ROV后最常见、最痛的"首痛"。
• 过松（maxLength 远大于真实需要）：例如为203.0.113.0/24设maxLength=32，等于授权该AS可宣告到/32的任何更具体前缀。攻击者若劫持该AS的更具体前缀（sub-prefix hijack），因长度≤32而仍然Valid，ROA对sub-prefix劫持完全失效。RFC 7454（BCP 194，2015年2月）在其路由起源验证相关章节明确建议：maxLength应设为"真实宣告的最大长度"，不应盲目放大。
• 等于address长度（省略maxLength）：只允许精确该前缀，最安全但最不灵活——任何更具体宣告都会Invalid。

07 · 各RIR平台的ROA表达差异

尽管ROA的底层格式（RFC 6482 ASN.1）是统一的，但五大RIR/NIR的门户交互与默认值存在差异，这些差异会间接影响数据质量：

因此，跨RIR的ROA质量比较需要归一化：本课题在采集时以RFC 6482对象本身为唯一真相源，门户差异仅作为"错误成因的背景解释"，不纳入质量打分。

本节参考来源（第2页）

以下均为真实可查的权威来源，用于支撑本页技术表述。