01 · 研究背景与意义
1.1 ROV的能力边界：解决了什么、没解决什么
RPKI v0体系（RFC 6480—6482定义基础设施与ROA对象，RFC 6811定义路由起源验证ROV，RFC 8210定义RTR分发协议）已在抵御前缀劫持上证明价值：据RIPE NCC发布的年度数据，RIPE区域IPv4地址空间ROA覆盖率由2024年底的约71%升至2025年底的约75%，IPv6由约40%升至约42%。但ROV只做一件事——检查BGP宣告的起源AS是否被该前缀的ROA授权，输出Valid/Invalid/NotFound三态之一。以下三类路径层问题，ROV均无法处理：
- 路由泄露（Route Leak）：路由的起源完全合法（起源AS正确、ROA验证通过），但其传播违反了AS间商业关系约束——例如AS把从对等体学到的路由转发给上游提供商，或将客户路由泄露给非客户。泄露是全球路由事故的最大来源（RFC 7908对泄露类型作了系统分类），大规模泄露可在数分钟内波及全球数千个AS。
- AS_PATH操纵：攻击者篡改AS_PATH（删除或插入ASN）使路径看起来"更短"或"更可信"，以影响远端选路或隐藏真实来源。ROV根本不检查AS_PATH内容。
- 合法起源＋非法中继：攻击者借用一段真实路径作掩护。例如在2024年6月Cloudflare 1.1.1.1事件中，劫持起源（AS267613宣告1.1.1.1/32）与泄露放大（AS262504将1.1.1.0/24泄露给上游）叠加出现，ROV只能覆盖其中起源一环。
1.2 路径层威胁模型
| 威胁 | 机理 | ROV能否检测 | ASPA能否缓解 |
|---|---|---|---|
| 起源劫持 | 未授权AS宣告他人前缀（含sub-prefix劫持） | 能（Invalid即丢弃） | 非其设计目标（与ROV互补） |
| 路由泄露 | 违反商业关系的路由传播（RFC 7908类型1—6） | 不能 | 能（核心目标：检测异常"下坡"段） |
| AS_PATH伪造 | 插入不存在的转接段以伪装靠近起源或绕过过滤 | 不能 | 部分能（无授权声明的伪造段会被判Invalid/Unknown） |
| 路径短化 | 删除AS_PATH中的ASN使路径在选路中占优 | 不能 | 部分能（删除会破坏授权链的连续性） |
| 对等互联操纵 | peer-to-peer关系被滥用为转接 | 不能 | 不能（ASPA不验证对等关系，见第7页局限分析） |
1.3 两条路径验证路线：BGPsec与ASPA
路线A——BGPsec（RFC 8205，2017年9月发布）：为BGP UPDATE的AS_PATH逐跳附加ECDSA签名，实现密码学意义上的全路径验证。配套标准包括RFC 8206（设计选择）、RFC 8207（运维考虑）、RFC 8208（安全考虑）、RFC 8209（BGPsec路由器证书）。设计目标完美，但部署门槛极高：每台路由器需维护签名密钥、逐跳验签带来CPU与内存开销、路径变化时需重签、且需要BGPsec路由器证书的全球分发体系。截至2026年，除少数科研试验床与厂商试验环境外，BGPsec在全球骨干网中几乎没有任何生产部署，被公认为"标准化成功、部署失败"的典型案例。BGPsec路由器证书（RFC 8209）的分发体系从未达到支撑全球部署的规模，RIR层面亦未将其转化为面向全体成员的大规模生产服务。
路线B——ASPA（IETF SIDROPS工作组规范，截至2026年9月已越过WGLC关键节点、尚未分配RFC编号）：不做逐跳签名，而是让每个AS签发一份"我的合法上游提供商列表"的RPKI签名对象（ASPA对象）。验证方将BGP路由的AS_PATH与全网ASPA声明逐跳比对：路径中"上坡段"（朝起源方向，每一跳都应是上一跳的授权提供商）与"下坡段"（朝接收方方向，每一跳都应是上一跳的客户）必须分别满足授权关系，路径顶点必须可被合理解释。任何一处违反授权声明即为Invalid。由于签名由AS持有者完成（与ROA完全相同的托管模型），路由器只消费验证结果（经RTR扩展下发），部署成本远低于BGPsec。
1.4 研究意义
ASPA是RPKI从v0到v2演进的枢纽：它复用ROA已有的信任锚、证书体系、托管服务与软件生态，将验证范围从"单点起源"扩展到"整条路径"。对运营者而言，掌握ASPA意味着在已有ROV投资之上以边际成本获得泄露检测能力；对安全机构而言，ASPA覆盖率的测量是评估全球路由安全成熟度的下一项核心指标（当前全球仅约0.5%的AS已签发ASPA，RIPE区域覆盖率约1.19%，处于极早期）；对反钓鱼治理而言，路径验证压缩了"劫持合法前缀＋操纵路径引流"的底层通道型攻击空间。
核心科学问题：ASPA的授权声明模型能否在"不签名路径"的前提下提供工程上足够强的路径合法性保证？围绕三个关键问题展开——KQ-1（算法正确性）：up-ramp/down-ramp验证逻辑在prepending、AS_SET、联盟路径、多归属等复杂现实场景下是否完备且无系统性误判？KQ-2（部署临界规模）：ASPA的保护效果随覆盖率增长呈何种形态，多大覆盖率才能使泄露检测对攻击者失去可趁之机？KQ-3（运营风险）：在覆盖率不足的漫长过渡期内，Unknown为主的判定结果如何安全地转化为路由策略而不误伤合法流量？
02 · 事实勘误：ASPA规范的真实状态
必须澄清的常见误引：网络上广泛流传的"ASPA已由RFC 8970（2020年）/ RFC 9015（2021年）标准化"的说法是错误的。经核对RFC Editor官方索引：RFC 8970是《IMAP4 Extension: Message Preview Generation》（IMAP邮件预览扩展），RFC 9015是《BGP Control Plane for the Network Service Header in Service Function Chaining》（服务功能链控制平面），两者与ASPA毫无关系。ASPA的真实规范状态如下表所示。本课题全部内容以IETF官方文档为准。
| 文档 | 真实身份与状态（截至2026年中，以datatracker.ietf.org为准） |
|---|---|
| draft-ietf-sidrops-aspa-profile | ASPA对象格式规范（对象结构、CMS封装、字段定义），SIDROPS工作组草案：v27（2026-06-19）演进至v29（2026-07-29），2026年下半年完成工作组最后征求意见（WGLC）相关评审，尚未分配RFC编号 |
| draft-ietf-sidrops-aspa-verification | 基于ASPA的AS_PATH验证算法规范，SIDROPS工作组草案：v26（2026-07-06）进入WG Last Call，2026-08-03工作组共识确认、进入Waiting for Write-Up；最新v28（2026-08-24） |
| draft-ietf-sidrops-8210bis | RPKI-to-Router协议第2版（RTR v2）草案：定义经RTR向路由器下发ASPA验证数据的ASPAs PDU，已演进至v27（2026-08-13）；现行RTR标准仍为RFC 8210 |
| RFC 9234（2022年5月） | 《Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages》，通过BGP OPEN协商角色并在UPDATE携带Only-to-Customer（OTC）属性——泄露治理的另一条已标准化路线，常与ASPA互补讨论 |
| RFC 8205—8209（2017年） | BGPsec协议簇（路径签名路线），已标准化但几乎无生产部署，与ASPA形成"设计哲学对照组" |
这一勘误对文献引用有实操影响：检索ASPA技术资料时应以datatracker.ietf.org中的draft-ietf-sidrops-*文档与RIR官方文档（RIPE NCC/ARIN/APNIC的ASPA说明页）为准，凡引用"RFC 8970/9015为ASPA"的二手资料均应视为不可靠来源。
03 · 研究目标与关键问题
- 规范掌握目标：形成对aspa-profile与aspa-verification两份草案的完整技术解读（对象结构、验证算法、边界条件），并持续跟踪其从草案到RFC的定稿过程。
- 能力评估目标：建立ASPA对历史路由事件的"反事实检测"推演方法（第6页），量化其与ROV、OTC各自的检测覆盖与盲区。
- 部署测量目标：构建ASPA签发侧（customer ASID数量、区域分布、上游声明结构）与消费侧（验证器、路由器支持度）的持续测量管道（第5页）。
- 风险治理目标：识别ASPA在真实多归属、联盟、IXP场景下的误判风险，制定分阶段策略建议（第7、8页）。
3.1 三个关键研究问题（KQ）
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 算法正确性与完备性 | 验证算法如何处理prepending去重、AS_SET、AS_CONFED_*段、路径顶点（peak）判定、provider-free声明等边界场景？是否存在合法路径被系统误判为Invalid的结构类型？ | 第3、4页 |
| KQ-2 | 部署激励与临界规模 | ASPA呈明显的单边网络效应：签发方数量决定检测价值。当前全球覆盖率约0.5%（2026年初），何种增长路径可达"攻击者无法找到Unknown盲区"的临界规模？ | 第5、6页 |
| KQ-3 | 过渡期的策略安全 | 在覆盖率不足阶段，绝大多数路径将判为Unknown：严格模式（拒绝Unknown）不可行，宽松模式（放行Unknown）则留下降级攻击面——如何设计灰度策略与监测指标？ | 第7、8页 |
04 · 生态全景与演进时间线
4.1 生态参与方与职责
| 角色 | 职责/产出 | 代表 |
|---|---|---|
| 标准组织 | ASPA对象规范、验证算法、RTR扩展、泄露治理机制的标准化 | IETF SIDROPS工作组（SIDR后继）；RFC 7908/8205-8209/9234及aspa-*系列草案 |
| 互联网注册管理机构 | 在托管RPKI系统中提供ASPA对象签发/撤销服务 | RIPE NCC（2025年11月生产上线）、ARIN（2026年1月生产上线）、APNIC（2026年上半年起经MyAPNIC与Registry API提供，以官方公告为准）、LACNIC与AFRINIC（NRO RPKI计划承诺2026年底前提供） |
| 开源软件 | ASPA签署、验证、RTR分发与路由侧实现 | 签署：Krill、RIPE NCC、ARIN、APNIC演示实现；验证：rpki-client、Routinator、FORT Validator；RTR：RTRTR、StayRTR；路由：OpenBGPD 7.8+、BIRD（实现分支/近期版本） |
| 设备厂商 | 路由操作系统内置ASPA验证与策略执行 | Cisco IOS-XR（早期现场试验EFT阶段）；华为等厂商文档与IETF草案中已出现ASPA相关实现资料 |
| 测量研究社区 | ASPA覆盖率统计、算法正确性分析、部署障碍研究 | RIPE NCC年度RPKI回顾、APNIC Blog（Geoff Huston等的RPKI年度分析）、IETF会议SIDROPS议程材料 |
4.2 领域演进关键时间线
| 时间 | 事件 |
|---|---|
| 2000—2003 | S-BGP（BBN，Kent等）与soBGP（Cisco）提出路径安全方案，因部署复杂度未获采用 |
| 2008—2012 | RPKI标准化（RFC 6480—6492，2012年）；起源验证具备工程基础 |
| 2016—2017 | RFC 7908系统定义路由泄露问题（2016）；BGPsec协议簇RFC 8205—8209发布（2017）；RTR协议RFC 8210发布（2017） |
| 2019—2020 | ASPA思路进入IETF SIDR/SIDROPS讨论，aspa-profile等草案开始长期迭代；验证算法历经多轮社区变体讨论（含上游/下游/出站侧验证等方向）后逐步收敛 |
| 2022 | 泄露治理的另一条路线标准化：RFC 9234（BGP角色＋OTC属性）发布（5月）；RIPE NCC在其RPKI试验环境提供ASPA API（Q4） |
| 2023 | OpenBSD rpki-client与OpenBGPD加入ASPA支持；Routinator、Krill、RTRTR、StayRTR、rpki-prover等相继支持；APNIC发布ASPA签名演示实现 |
| 2024 | RIPE NCC按aspa-profile草案v16更新试验环境；SIDROPS推进验证算法草案收敛；全球ASPA customer ASID仅87个（年底RIPE Labs统计） |
| 2025 | RIPE NCC于11月26日在RPKI Dashboard中正式提供ASPA生产支持（RIPE Labs文章发布于12月15日）；ASPA customer ASID激增至556个（+539%）；RIPE区域ASPA覆盖率达1.19% |
| 2026 | ARIN于1月20日宣布在ARIN Online全面提供ASPA（创建与自动续期）；APNIC于上半年起经MyAPNIC与Registry API提供（以官方公告为准）；aspa-verification v26（2026-07-06）进入工作组最后征求意见（WGLC），8月3日共识确认、进入Waiting for Write-Up（最新v28，2026-08-24）；aspa-profile演进至v29（2026-07-29），同样完成WGLC关键节点 |
05 · 术语速查与常见误区
5.1 核心术语
| 术语 | 释义 |
|---|---|
| ASPA / ASPA对象 | 由AS持有者签发的RPKI签名对象，声明该AS的一个或多个合法上游提供商（provider）AS号；消费侧用于AS_PATH验证 |
| customerASID | ASPA对象中的"客户AS"字段，即签发声明的主体（与其EE证书中的AS号必须一致） |
| Attested Provider Authorization | 验证算法的核心概念：AS_A的ASPA将AS_B列为提供商，即构成"B为A的授权提供商"的密码学声明（B对A的attestation） |
| provider-free ASPA | 由无上游的顶级网络（tier-1）签发、providers集合仅含保留AS号AS0的ASPA，用于显式声明"我不从任何AS购买转接"（transit-free），可将路径顶点判定从Unknown提升为Valid |
| afiLimit | ASPA可选字段，将某条提供商声明限定于IPv4或IPv6单栈场景 |
| up-ramp / peak / down-ramp | 验证算法对AS_PATH的三段式解读：朝起源方向逐跳核验"授权提供商"（上坡）、路径顶点、朝接收方方向逐跳核验"授权客户"（下坡） |
| OTC（Only to Customer） | RFC 9234定义的BGP可选传递属性：打上OTC的路由只能向客户方向传播，接收方据此发现泄露 |
| BGP角色（BGP Role） | RFC 9234定义的会话级角色对（provider/peer/customer/route-server*），在BGP OPEN消息中协商一致 |
5.2 常见误区辨析
| 误区 | 辨析 |
|---|---|
| "ASPA已由RFC 8970/9015标准化" | 错误（见本页§02勘误）。RFC 8970是IMAP扩展，RFC 9015是服务功能链控制平面。ASPA规范是SIDROPS工作组草案，引用时必须写全draft名称与版本。 |
| "ASPA能取代ROA" | 错误。二者验证对象不同：ROA验证起源，ASPA验证路径中的提供商—客户关系。ASPA的前提是起源合法（通常与ROV联合部署），目标是"源端验证＋路径验证"互补体系。 |
| "ASPA能检测所有路由泄露" | 过度承诺。ASPA不验证peer-to-peer关系，对等互联被滥用为转接的场景、以及涉及未签发ASPA的AS路径段只能得到Unknown判定，需要与RFC 9234 OTC、前缀过滤等手段叠加（第7页）。 |
| "ASPA是BGPsec的升级替代" | 不准确。二者安全模型本质不同：BGPsec是"路径逐跳密码学签名"（强保证、高成本），ASPA是"关系授权声明比对"（弱保证、低成本）。ASPA以放弃部分保证换取可部署性，安全强度分析见第7页。 |
| "路由器需要逐跳验签ASPA" | 错误。与ROV相同，验证在RPKI验证器（如rpki-client、Routinator）完成，路由器经RTR扩展接收验证结果并执行策略，转发面不承担密码学运算。 |
06 · 研究范围与合规边界
- 对象范围：面向全球公共互联网的AS_PATH验证问题，涵盖ASPA对象规范、验证算法、RTR扩展、泄露治理辅助机制（RFC 9234）及BGPsec对照分析；不覆盖域内IGP安全、段路由（SR/SRv6）路径安全。
- 深度边界：做到"规范解读＋能力评估＋部署路线"层面；BGP协议栈的代码级实现审计、具体设备渗透测试不在范围。
- 时效声明：ASPA规范仍处草案阶段，对象格式与算法在2026—2027年定稿过程中可能微调；本课题内容标注版本号，以IETF datatracker与RIR官方发布为最终依据。
合规与伦理声明：①本课题以防御研究为目的，严格遵守《网络安全法》《数据安全法》《个人信息保护法》；②文中涉及的绕过手法仅在概念层面描述其原理与检测思路，不提供可直接复用的攻击配置；③ASPA事件与数据的引用均标注公开来源与时间口径；④对具体AS的归因结论均标注置信度，不构成法律指控。
07 · 与课题体系的协同关系
| 协同子课题 | 数据/方法交换内容 |
|---|---|
| 01 BGP路由劫持检测与溯源 | 对方提供路径操纵事件分类学与案例库，作为ASPA"反事实检测"推演的输入；本课题输出ASPA验证结果标签（Valid/Invalid/Unknown）作为其检测管线的新富化维度 |
| 02 RPKI部署测量与效能评估 | 本课题的ASPA覆盖率测量管道（customer ASID统计、区域分布）并入其RPKI部署态势指标；对方提供ROA/ROV基线数据用于"ROV＋ASPA"联合效能分析 |
| 03 ROA数据质量分析 | ASPA与ROA共用EE证书与托管体系，对方的对象质量校验方法（过期、覆盖偏差）可直接迁移至ASPA对象质量监控 |
| 04 RPKI基础设施弹性 | ASPA对象的撤销/重签频率、Manifest失效场景输入对方可用性分析；对方信任锚弹性结论支撑ASPA大规模签发的前提假设 |
| 06 路由安全态势感知 | 本课题输出ASPA覆盖率趋势、Unknown/Invalid分布等结构化指标，直接支撑态势指标体系与年度趋势报告 |
08 · 预期成果与交付物
- 《ASPA对象规范与AS_PATH验证算法技术解读》研究报告（逐节解读aspa-profile与aspa-verification草案，附边界场景清单）
- ASPA部署测量管道（基于RPKI仓库快照的customer ASID统计、区域分布、上游声明结构画像）
- 历史泄露事件"反事实检测"推演集（第6页案例库，覆盖2008—2024年标志性事件）
- 《ASPA灰度部署策略与风险清单》（第7、8页，含宽松/严格模式决策树与监测指标）
- 工具适配验证报告（rpki-client/Routinator/OpenBGPD/BIRD的ASPA功能验证记录）
本节参考来源（第1页）
以下均为真实可查的权威来源（IETF官方文档、RIR官方发布、学术文献），用于支撑本页事实性表述。
IETF Datatracker，draft-ietf-sidrops-aspa-profile（ASPA对象规范草案）：datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile。
IETF Datatracker，draft-ietf-sidrops-aspa-verification（AS_PATH验证算法草案）：datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification。
IETF RFC 9234《Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages》（2022年5月）：rfc-editor.org/rfc/rfc9234。
IETF RFC 7908《Problems with Problematic BGP Routes》（路由泄露问题框架，2016年6月）：rfc-editor.org/rfc/rfc7908。
IETF RFC 8205《BGPsec Protocol Specification》（2017年9月）及RFC 8206/8207/8208/8209协议簇：rfc-editor.org/rfc/rfc8205。
RIPE Labs，Tim Bruijnzeels等《ASPA in the RPKI Dashboard: A New Layer of Routing Security》（2025年12月15日）：labs.ripe.net；RIPE NCC Annual Report 2025（ripe-855，ASPA覆盖率1.19%等数据）：ripe.net。
APNIC Blog，Geoff Huston等《RPKI's 2025 year in review》（2026年2月20日，ASPA customer ASID约0.5%等数据）：blog.apnic.net；RIPE Labs《RPKI's 2024 year in review》（2025年1月16日，2023/2024年ASPA数量）：labs.ripe.net。
RFC Editor官方索引，RFC 8970（IMAP4扩展）与RFC 9015（服务功能链）真实条目：rfc-editor.org/info/rfc8970、rfc-editor.org/info/rfc9015。
RIPE NCC RPKI规划档案（ASPA试点环境2022年Q4、生产决策时间线）：ripe.net/quarterly-planning；APNIC路线图：roadmap.apnic.net。