01 · 方法论：历史事件的"反事实检测"推演
1.1 推演框架
ASPA部署覆盖率目前仅约0.5%（2025年底），尚无任何已公开记录的真实大规模泄露事件是"被ASPA拦截"的——这本身反映了其早期阶段。因此，评估ASPA价值的科学方法是反事实推演（counterfactual analysis）：选取有详实公开档案的历史路径事件，将当时真实的AS_PATH代入ASPA验证算法，回答三个问题：
- 可检测性：若当时相关AS均已签发准确的ASPA，该事件会被判为Invalid吗？
- 覆盖敏感性：需要路径上哪些关键AS签署声明，检测才能成立？（即"最小关键签署集"）
- 机制互补性：ROV、OTC、ASPA各自能覆盖该事件的哪个环节？
方法声明：以下推演中的AS_PATH均为事件公开报告与BGP档案（RouteViews/RIS/BGPStream等）中的真实记录或合理重建；但"假设覆盖率"属于思想实验，不构成对历史处置方式的评价，也不声称任何机构当时应当已部署ASPA。推演仅用于界定各机制的能力边界与部署优先级。
1.2 推演使用的判定规则
对每个事件，按第4页算法给出判定：Valid（形态合规）/Invalid（形态违反——泄露或操纵的强证据）/Unknown（缺声明不可判定）。并标注"最小关键签署集"——使判定成立所需的最少ASPA声明组合。
02 · 案例：2019年6月美国Verizon泄露事件
2.1 事件档案
| 要素 | 内容 |
|---|---|
| 时间 | 2019年6月24日（持续约20分钟的主影响期） |
| 事件链 | 美国宾夕法尼亚州小型运营商DQE Communications（AS33154）使用Noction公司的BGP Optimizer产品，将Cloudflare等网络的大前缀拆分为更具体路由（more-specifics）并宣告给客户Allegheny Technologies（AS396531），后者传递至其上游Verizon（AS701）；Verizon未做有效的入向过滤，将这些路由传播至其全球对等互联，导致Cloudflare、Amazon、Facebook、Linode等大型网络流量被错误牵引（峰值期间Cloudflare全球流量一度下降约15%） |
| 定性 | 典型路由泄露（RFC 7908类型5：从对等/非客户方向学到的路由传播给提供商并扩散）——起源完全合法，ROV全程无感 |
| 公开档案 | Cloudflare官方博客《How a small ISP in Pennsylvania caused a big Internet outage》（2019-06-24）；BGPmon/BGPStream事件记录 |
2.2 反事实推演
- ROV：所有泄露路由的起源AS均正确且多有ROA覆盖 → 全部Valid，无任何拦截能力（与事实一致，事件正是穿过ROV部署网络扩散的）；
- ASPA：泄露路径的关键特征是"上坡段之后又出现上坡"——合法路径从起源上行至Verizon层级应单峰下行，而DQE→Verizon一跳构成非法的第二上坡。若最小关键签署集{受害者AS的ASPA（声明其真实上游）、DQE的ASPA（声明其真实上游不含泄露来源）、Verizon的ASPA（声明其真实上游）}齐备，泄露路径将被判为Invalid，Verizon本可在自家网络内就地拦截，无需上游配合；
- OTC：若DQE上游方向普遍携带OTC，Verizon收到带OTC的路由来自非客户方向即可现场告警——但OTC依赖"打标者配合"，无密码学强制力；
- 结论：该事件是ASPA价值的最强论证场景之一：泄露检测正是ASPA的核心设计目标，而最小关键签署集仅涉及事件链中少数几个AS——即便全网覆盖率不高，重点AS（大型上游与IXP）签署即可在事件级获得检测能力。事件峰值期间Cloudflare全球流量一度下降约15%，足见单点过滤失效的放大效应。
03 · 案例：2024年6月Cloudflare 1.1.1.1劫持＋泄露叠加事件
3.1 事件档案
| 要素 | 内容 |
|---|---|
| 时间 | 2024年6月27日前后 |
| 事件链 | 两条异常前后叠加：18:51 UTC，巴西Eletronet S.A.（AS267613）开始宣告1.1.1.1/32（起源劫持，因最长前缀匹配被部分网络误当作RTBH路由接受）；1分钟后，Nova Rede de Telecomunicações（AS262504）将1.1.1.0/24不当泄露给AS1031（PEER 1）并被进一步扩散——两者叠加导致70余个国家/地区300多个网络的1.1.1.1解析服务不可达或高时延 |
| 定性 | 劫持与泄露的复合事件（起源维度＋路径维度同时被攻击/出错） |
| 公开档案 | Cloudflare官方博客事件报告（2024年6月）；BleepingComputer等媒体报道 |
3.2 反事实推演
- ROV（实证部分）：Cloudflare官方报告确认，其自身与已部署ROV的网络自动拒绝了Invalid的劫持宣告——ROV拦截了事件中的起源维度，这是已发生的事实而非推演；未部署ROV的网络则同时暴露在劫持与泄露之下；
- ASPA：泄露维度的路径（Nova Rede→上游→全球）在ASPA齐备时将呈现"起源合法、路径形态违规"——Nova Rede的真实客户中不含Cloudflare，其ASPA声明与路径方向矛盾 → 泄露段判Invalid。该事件因此是"ROV＋ASPA双机制覆盖双维度"的教科书式样本：ROV挡起源，ASPA挡扩散；
- 结论：任何只部署ROV的网络在该事件中只能保护"自己不被劫持宣告欺骗"，却仍是泄露的放大器或受害者；ASPA补上的正是这一环。
04 · 案例：2008年巴基斯坦电信劫持YouTube事件
4.1 事件档案与推演
| 要素 | 内容 |
|---|---|
| 时间 | 2008年2月24日（持续约2小时） |
| 事件链 | 巴基斯坦电信（AS17557）为执行国内管制，宣告YouTube的208.65.153.0/24（YouTube自身宣告208.65.152.0/22，/24为其sub-prefix，依最长前缀匹配优先生效），经PCCW（AS3491）等传播至全球，导致全球YouTube流量被牵引至巴基斯坦 |
| 定性 | 起源劫持（配合政府管制意图）；因ROA体系当时尚不存在（2012年才有RFC 6482），当年无任何密码学防御 |
- ASPA适用性：本事件属起源维度，ASPA非其防御机制；若当时有ROV，劫持宣告将判Invalid并被拒绝（这正是今天ROV已能覆盖的场景）；
- 启示：该事件表明"底层通道型"劫持可以服务于政治性流量操纵——与钓鱼流量重定向同源。路径验证（ASPA）虽不治起源劫持，但可显著压缩"劫持＋精心构造传播路径"组合攻击的可用路径空间（攻击者无法再用任意AS拼接看似合法的传播链）。
05 · 案例：2018年MyEtherWallet DNS劫持事件（路由层辅助的钓鱼）
5.1 事件档案与推演
| 要素 | 内容 |
|---|---|
| 时间 | 2018年4月24日（持续约2小时） |
| 事件链 | 攻击者通过BGP劫持亚马逊Route 53的DNS服务器前缀，将myetherwallet.com用户的DNS查询牵引至攻击者控制的解析器，返回钓鱼IP并配合伪造证书实施中间人攻击，盗取价值十余万美元的ETH |
| 定性 | "底层通道型"钓鱼：不依赖邮件/域名社工，应用层防御（URL过滤、域名信誉）对此无效 |
- ROV反事实：Route 53前缀当时已有ROA声明（亚马逊是ROA早期采用者），若受害用户所在网络部署ROV，劫持宣告将判Invalid——该事件因此常被引为ROV价值论据；
- ASPA反事实：攻击者为使劫持宣告在骨干传播，需构造看似合法的传播路径；在ASPA齐备环境下，攻击者控制的宣告路径中"未经授权的第二上坡"会被判Invalid，传播面被压缩至未部署检测的网络——ASPA的边际价值在于压缩钓鱼流量重定向的可达范围；
- 反钓鱼视角：该事件是本课题与反钓鱼治理的直接连接点：钓鱼落地需要流量可达，路径验证让"可达"变得更贵、更窄、更快暴露。
06 · 案例：2020年4月Rostelecom异常宣告事件与超大规模泄露
6.1 事件档案
| 要素 | 内容 |
|---|---|
| 时间 | 2020年4月1日19:28 UTC起，持续约一小时 |
| 事件链 | 俄罗斯Rostelecom（AS12389）异常宣告了8,000余个不属于其客户的前缀（Qrator口径：8,870个前缀、近200个AS，含Akamai、Cloudflare、Hetzner、DigitalOcean、AWS等），经Rascom（AS20764）、Cogent（AS174）、Level3（AS3356）逐级扩散至全球 |
| 定性 | 超大规模异常宣告（泄露或配置事故，公开分析未形成单一归因）；此类事件中受影响前缀的合法起源不受影响，ROV无感 |
| 同类参照 | 2013年4月印尼Indosat（AS4761）事件：单日异常宣告量达数十万条（接近当时全网路由表规模），影响全球；大规模泄露的共同特征是"少数AS的过滤失效被全网信任放大" |
6.2 反事实推演
- ASPA最小关键签署集：此类事件的检测不依赖"每个受害者AS"签署——只需肇事AS自身（其ASPA声明的真实上游与异常宣告的传播方向矛盾）与其直接上游（路径形态在本地即违规）签署即可在数跳内判Invalid；
- 时效价值：分钟级判Invalid意味着上游与大型对等方可以自动隔离肇事AS的异常宣告，将"全网事故"降级为"局部事件"——这是ASPA对超大规模泄露最具杠杆价值的场景；
- 局限提示：若肇事AS从未签发ASPA（Unknown），验证退化为不可判定——再次指向"先让大型AS签署"的部署策略（第5页§05）。
07 · 综合：各机制检测覆盖矩阵
| 事件类型 | ROV | OTC（RFC 9234） | ASPA | 组合结论 |
|---|---|---|---|---|
| 起源劫持（含sub-prefix） | ✔ 直接拦截 | ✘ | △ 压缩传播路径 | ROV为主，ASPA压缩攻击面 |
| 客户→上游泄露（上坡泄露） | ✘ | △ 依赖打标 | ✔ 核心检测（Invalid） | ASPA为主 |
| 对等/跨方向泄露 | ✘ | △ | ✔ 形态违规即Invalid | ASPA为主，OTC互补 |
| AS_PATH伪造/短化 | ✘ | ✘ | △ 破坏授权链可检出 | ASPA部分覆盖 |
| peer关系滥用（不涉客户授权） | ✘ | ✘ | ✘ 结构性盲区 | 需出站过滤/ROA+人工（见第7页） |
核心结论：①ASPA的最小有效部署单元远小于"全网覆盖"——肇事AS及其上游、大型枢纽AS的声明即可在事件级产生检测能力，这显著改善了部署激励结构；②ASPA与ROV构成"起源＋路径"的互补闭环，与OTC构成"密码学判定＋轻量信号"的互补层级；③peer关系滥用是唯一无机制覆盖的结构性盲区，须依靠出口过滤纪律与监测运营兜底（第7页）。
本节参考来源（第6页）
Cloudflare Blog《How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today》（2019年6月24日）及其姊妹篇《The deep-dive into how Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Monday》：blog.cloudflare.com。
Cloudflare Blog 1.1.1.1劫持与泄露事件官方复盘（2024年6月27日事件，7月初发布）：blog.cloudflare.com。
2008年巴基斯坦电信/YouTube事件：RIPE NCC与CAIDA等机构的公开分析（事件发生于2008年2月24日，属路由安全领域教科书案例）。
2018年MyEtherWallet事件：Qrator Labs等安全厂商与媒体的公开报告（2018年4月24日，BGP劫持配合DNS重定向的加密货币盗窃）。
2020年4月1日Rostelecom（AS12389）异常宣告事件：Qrator Labs分析（2020年4月2日）与MANRS复盘（2020年4月6日）；2013年Indosat（AS4761）事件：RIPE NCC/行业公开分析。
Testart C.等《Profiling BGP Serial Hijackers》（ACM IMC 2019）与BGPStream事件档案：bgpstream.caida.org（事件数据底座）。