ASPA对象规范深度解析第3页：对象规范与生命周期

01 · ASPA对象的定位与总体结构

1.1 规范来源与版本说明

ASPA对象的格式由IETF SIDROPS工作组草案draft-ietf-sidrops-aspa-profile定义（截至2026年6月为第27版，处于工作组最后征求意见阶段）。该草案与ROA规范（RFC 6482）在结构哲学上保持高度一致：ASPA同样是RPKI签名的CMS对象，由AS号持有者的终端实体（EE）证书签名，托管于RIR维护的RPKI资料库（repository）中，经Manifest与CRL机制管理时效性。

1.2 对象封装的四层结构

• EE证书层：ASPA由"客户AS"（customer AS）的EE证书私钥签名。EE证书由该AS的资源证书（CA证书链）签发，证书中携带AS号资源（与RFC 6487规定的AS号编码方式一致）。因此，ASPA的权威性直接继承RPKI信任链：任何人均可沿 RIR信任锚→CA证书→EE证书 的链条验证签名，无需任何额外信任假设。
• CMS SignedData层：对象按RFC 6488（RPKI签名对象模板）封装为CMS SignedData，eContent为DER编码的ASPA内容。
• ASPA内容层：核心字段见§02。
• 资料库管理层：ASPA对象发布于RIR资料库，纳入Manifest（RFC 6486）清单管理；撤销通过重签不含该ASPA的清单、吊销EE证书或使对象过期实现。

02 · 核心字段详解

2.1 字段总览（按aspa-profile草案v27的结构描述）

2.2 字段语义的精确解读

• customerASID与EE证书绑定：这是ASPA防伪的根基。验证器在校验签名时同步核对证书AS号与customerASID是否一致——攻击者无法用自己的证书为受害AS签发ASPA，也就无法伪造"他人授权我作其提供商"的声明。
• providers列表的方向性：声明是单向的：customerASID → providerASID 表示"我承认P是我的提供商"。它不蕴含"P承认我是其客户"（后者需要P自己签发包含customerASID=C的ASPA，或C的ASPA存在且P未否认——注意ASPA模型本身不含"否认"机制，见第7页讨论）。
• afiLimit的工程动机：现实中存在仅购买单栈转接的场景（如只买IPv4转接、IPv6走其他上游）。afiLimit允许AS精确表达单栈授权，避免验证器将双栈语义强加于单栈商业关系，减少误判。
• provider-free ASPA（providers仅含AS0）：顶级网络（tier-1）无上游。通过在providers集合中仅声明保留AS号0（AS0）表达transit-free语义，可让验证器将路径顶点判定从"不可判定"提升为Valid——这是草案鼓励的最佳实践之一（人可读记法示例：AS64500 => AS0）。

2.3 合法关系与声明覆盖的对照

03 · 对象生命周期：签发、发布、验证、撤销

3.1 签发与托管服务

ASPA的签发路径与ROA一致：AS号持有者通过所属RIR的托管RPKI系统（托管环境下的证书供应遵循RFC 6492框架）或自托管CA（如Krill）生成EE证书与ASPA对象，对象经RIR资料库发布（rsync/RRDP）供全球验证器抓取。RIR支持状态（截至2026年）：RIPE NCC于2025年11月26日在RPKI Dashboard提供生产级ASPA管理；ARIN于2026年1月在ARIN Online上线（含自动续期）；APNIC于2026年上半年上线（以官方公告为准；已发布签名演示实现）；LACNIC承诺2026年底前、AFRINIC列入路线图。

3.2 验证流程（消费侧）

1. 验证器（rpki-client、Routinator等）从各RIR资料库同步ASPA对象与配套证书、Manifest、CRL；
2. 按RPKI标准流程校验完整证书链与签名（RFC 6480/6487），并核对customerASID与EE证书AS号一致；
3. 对同一customerASID的多个ASPA对象进行规范化处理（合并providers集、应用afiLimit），形成"每AS一张授权提供商表"的验证数据仓；
4. 经RTR扩展（draft-ietf-sidrops-8210bis，定义ASPAs PDU）将数据仓下发给路由器；路由器据此执行AS_PATH验证（算法见第4页）。

3.3 撤销与更新

• 关系变更：客户更换上游时，需撤销旧ASPA并签发新ASPA；RIR托管界面（如RIPE NCC Dashboard）通常提供"替换声明"操作；
• 证书到期：EE证书与CA证书均有有效期（常见为一年托管周期），到期未续签的对象自动失效——误期未续签会造成自身路由被误判的风险，运营纪律要求高（与子课题03的ROA过期问题同构）；
• 密钥轮换：按RFC 6489的CA密钥轮换流程处理，轮换期间需保持新旧链均可验证。

04 · ASPA与ROA对象的结构对比

05 · 编码结构示意

以下为ASPA内容的抽象结构示意（帮助理解字段关系，非完整DER编码，实现请以aspa-profile草案v27的正式ASN.1模块为准）：

ASPA ::= SEQUENCE {
    version         INTEGER (0),            -- 格式版本
    customerASID    ASID,                   -- 客户AS号（须与EE证书AS号一致）
    providers       SEQUENCE (SIZE(1..MAX)) OF ProviderAS
}

ProviderAS ::= SEQUENCE {
    providerASID    ASID,                   -- 被授权的上游提供商AS号
    afiLimit        AFI OPTIONAL            -- 1=IPv4, 2=IPv6；缺省=双栈授权
}

-- 业务语义示例：
-- 客户AS 64496 声明其上游为 64500（双栈）与 64501（仅IPv4）
ASPA {
  version      = 0,
  customerASID = 64496,
  providers    = [ {providerASID=64500},
                   {providerASID=64501, afiLimit=1} ]
}

-- transit-free（无上游/tier-1）声明：providers仅含保留AS号0
ASPA {
  version      = 0,
  customerASID = 64497,
  providers    = [ {providerASID=0} ]   -- 仅含AS0
}

06 · 注册操作中的常见错误模式

本节参考来源（第3页）

以IETF官方文档与RIR官方文档为准；草案内容可能随版本演进，引用时请注明版本号。