Skip to content
←

필사 모드: ROV 挡住了什么，ASPA 还挡不住什么 — 2026年6月 Telegram 劫持事件与路由安全的下一层

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 国内封锁跨越国境的那一天

2026年6月16日，印度政府下令封锁Telegram。围绕NEET医学院入学重考，有组织的作弊频道成了问题，依据IT法案第69A条，命令要求在6月22日前完成封锁。到这里为止，这还不是一个路由问题。

问题出在封锁的方式上。印度电信商Rcom(AS18101，是Reliance Communications，不是Reliance Jio)选择直接通过BGP广播Telegram的IP段，把流量引过来再丢进黑洞。据Kentik的Doug Madory当时撰写的BGP数据分析，从07:17 UTC起，AS18101开始originate Telegram使用的多个IP段，而这条路由泄漏到了印度境外。

这是一种非常眼熟的失败模式。用Madory的话说，它属于 既是故意、又是事故 这一类——国内封锁未能停留在国境之内，而是外溢到全球路由表，其原型是2008年巴基斯坦电信劫持YouTube事件。2021年缅甸政变期间对Twitter的封锁、2022年俄罗斯、巴西对X的封锁(AS263276)，以及2023年8月伊拉克对Telegram的封锁，形状都一样。

不过这一次留下了一个数字。据Kentik测算，Telegram(AS62041)正常originate的91.108.4.0/22，其劫持路径 只被Kentik自家BGP数据源的1.6%看到 。Madory写道，原因 很可能 (likely owing to)是Telegram给自己所有路由都挂了ROA，使得各网络得以丢弃RPKI-invalid的路径。

这个数字是以Kentik自家BGP数据源为基准的厂商自测，而Madory本人没有断言因果关系、只写了"likely"，这一点我原样保留在这里。即便如此，方向是明确的。RPKI ROV是2026年真正起作用的一种防御。

本文从这起事件出发，来看ROV实际挡住了什么、天花板又在哪里，以及瞄准这个天花板之外的ASPA，截至2026年7月走到了哪一步。BGP、AS、对等互联、RPKI的基础知识，已经在BGP互联网路由完全指南一文中讲过，这里只讲2026年新发生的事。

ROV 实际挡住了什么，天花板又在哪里

ROV(Route Origin Validation，RFC 6811)只做一件事：把"这个AS是否有权originate这个前缀"，拿去和签在ROA(RFC 9582)里的内容比对。AS18101用自己的名义originate Telegram前缀的那一刻，origin就对不上了，于是开启了ROV的路由器会判定这条路由invalid并丢弃。这就是为什么传播停在了1.6%。

实际失败在哪里，也是公开的。印度网络研究者Anurag Bhatia在事件次日撰写的分析中指出，除了Rcom的失误之外，真正失败的是 上游没有做RPKI ROV ，并具体点名了FLAG(AS15412)和Tata Communications(AS4755)。他的论点是：既然前缀已经签了名，只要部署了ROV，这些路径本可以被轻易过滤掉，劫持本会被困在AS18101及其下游内部。

Bhatia写道，他通过包括伦敦RIPE RIS RRC01在内的多个收集器确认，91.105.192.0/23从16:14:19 GMT(21:44:19 IST)开始被AS18101 originate。这与Madory的时间线也吻合——即Telegram为了夺回自己的IP空间打出more-specific路由后，AS18101从16:14 UTC起跟进，把劫持一路做到了那些more-specific路由的那部分。两份互相独立的分析指向了同一个时刻。

但Bhatia文章里真正重要的一句话是另一句。他认为这不是故意的，而是"fat finger mistake"(这是他个人的判断)，给出的理由是：

如果真是故意的，攻击者本应保留origin ASN不变，把Telegram的AS211157伪造在AS18101后面。那样一来，横跨transit-free的tier-1层级和各条骨干网、IXP的RPKI ROV过滤，根本就不会被触发。

这一句话精确地画出了ROV的天花板。ROV只看AS_PATH最末端的origin。攻击者只要把受害者的ASN原样留在origin位置、把自己插到它前面，ROA比对就能通过。哪怕路径完全是伪造的，ROV也不会说什么。这次事件里ROV之所以赢了，只是因为攻击手法拙劣，把origin给换掉了。

路由泄漏 — origin 合法的攻击

比伪造origin的劫持常见得多的，是路由泄漏(route leak)。RFC 7908对这一现象做了定义和分类，概括来说就是 路由被重新传播到了不该去的方向 。如果某个客户把从供应商A那里学到的路由，泄漏给了另一个供应商B，B就会通过这个客户学到一条通往A的路由。这条路由不该存在，但它的origin完全合法。

这就是关键所在。 在路由泄漏中，origin是真实的。 前缀正确签名，originate的AS也与ROA相符。ROV会把这条路由判定为valid。判定并没有错，只是这根本不是ROV被设计来回答的问题。BGP接受了这条路由，流量跟着这条路由走，而盯着路由表的运维人员，什么信号都看不到。

部分性的防御已经存在。RFC 9234定义的OTC(Only to Customer)属性，给BGP会话附加一个role，携带"这条路由仅供客户"这样的标记，用来检测和缓解 意外的 路由泄漏。但OTC只有在制造泄漏的那个AS自己遵守规则时才起作用。如果源头本身就是恶意的，它就完全无能为力——而这恰恰是ASPA规范自己在开篇就承认的一点：RFC 9234处理的是意外的路由泄漏，ROV处理的是意外的origin错误。

ASPA 是怎么运作的 — up-ramp 与 down-ramp

ASPA(Autonomous System Provider Authorization)的思路很简单。就像ROA签的是"这个前缀由这个AS originate"，ASPA 签的是"我的供应商只有这些" 。对象本身极简——看profile草案里的ASN.1定义，内容就只有一个customerASID和一份provider AS列表。

ASProviderAttestation ::= SEQUENCE {
  version       [0] INTEGER DEFAULT 0,
  customerASID      CAS,
  providers         ProviderASSet }

CAS ::= INTEGER (1..4294967295)
ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF PAS
PAS ::= INTEGER (0..4294967295)

验证就是把valley-free原则套用到AS_PATH上。验证草案取一条COMPRESSED_AS_PATH——也就是去掉了连续重复ASN的AS_PATH——并认为一条正常的路径应当只由两段组成：从origin往上爬的up-ramp，以及朝接收方往下走的down-ramp。每一跳都必须是customer-to-provider关系。照搬规范原文的说法：如果up-ramp和down-ramp的长度之和大于等于N，AS_PATH就是valid(没有路由泄漏)；如果长度之和小于N，说明这条路径要么泄漏了，要么AS_PATH本身有误。

                 AS(L) ............. AS(K)
                 /                      \
                .                        .
  (down-ramp)  .                          .  (up-ramp)
              .                            .
             /                              \
          AS(N)                             AS(1)
           /                              (Origin AS)
  接收/验证 AS (AS(N+1))

  每段ramp都是自下而上连续的customer-to-provider跳

前面提到的APNIC那个例子(ASPA at APNIC)把这一点讲得很具体。AS2同时是AS1和AS3的客户，AS1发布了一份ASPA，说"我唯一的供应商是AS5"。如果AS2把从AS1那里学到的路由不小心泄漏给了AS3，AS3就会去查AS1的ASPA，发现AS2并没有被登记为AS1的供应商。这条路由就变成ASPA-invalid，可以被拒绝。

这里有一个重要的性质——这种验证 并不要求路径上的每一个AS都做验证。 就像APNIC第二个例子那样，即便中间的AS3没有做验证、把泄漏原样传了下去，更下游的AS4只要自己做验证，仍然能发现路径走出了"供应商→客户→再回到供应商"的形状，从而抓住它。

2026年7月10日，ASPA 技术栈进入 Last Call

以上是设计层面的内容，2026年的新闻是这个。 2026年7月10日，三份与ASPA相关的草案同时进入了IETF工作组Last Call(WGLC)。 直接查询IETF Datatracker上的文档事件可以确认，三份文档都在同一天的13:20到13:21之间变更为"IETF WG state changed to In WG Last Call from WG Document"。

草案版本状态
draft-ietf-sidrops-aspa-profile27 (2026-06-19)In WG Last Call (2026-07-10)
draft-ietf-sidrops-aspa-verification26 (2026-07-06)In WG Last Call (2026-07-10)
draft-ietf-sidrops-8210bis (RTR v2)26 (2026-07-09)In WG Last Call (2026-07-10)

第三份尤其重要。RTR(RPKI-to-Router)协议是验证器把RPKI数据交给路由器的通道，要携带ASPA payload就需要RTR版本2。也就是说，ASPA需要对象profile、验证流程、传输协议这三层同时就位才能运转，而这三层是在同一天一起进入Last Call的。

拿这个进度和去年年底的预测对比一下，就能看出走了多远。Job Snijders在2026年2月写的《RPKI 2025年回顾》里写道，"工作组Last Call已经临近!运气好的话，规范或许能在2026年底之前发布。"Last Call实际上是在那之后5个月才真正开始的。

不过， 它现在还不是RFC。 在Datatracker上，三份文档的rfc字段都还是空的，IESG状态是"I-D Exists"——也就是IESG甚至还没开始处理的阶段。Last Call只是工作组内部的流程，之后还有IESG审查和RFC编辑队列在等着。早期评审已经开始进来了——2026年7月15日，一份ARTART评审以"Ready with Nits"结项，一份BGPDIR评审以"Almost Ready"结项。

而在RIR这一侧，发布功能已经开放了。RIPE NCC在2025年12月15日为RPKI仪表盘加入了ASPA，ARIN在2026年1月20日的发布说明中宣布"ARIN's implementation of Autonomous System Provider Authorizations (ASPA) is now fully available in ARIN Online"。APNIC在2026年7月9日宣布MyAPNIC和Registry API支持时写道，自2025年11月起RIPE NCC、ARIN、APNIC都已经部署了支持，并且 预计到2026年底，全部五家RIR都会支持ASPA 。

那么今天到底铺开了多少 — 我自己数了一遍

如果规范已经进入Last Call，三家RIR也已经打开了发布的开关，那实际部署到底走到了哪一步?与其相信宣传口径，不如自己数一遍。

截至2026年7月16日，我看了两个独立的数据源。第一个是Job Snijders运营的rpki-client控制台的ASPA数据转储，我自己抓取并解析了它(页面生成时间为Thu Jul 16 13:14:42 2026)。第二个是Hurricane Electric的RPKI & ASPA报告，同一天抓取。

两个数据源几乎完全一致。

项目数值来源
ASPA对象数2,391HE.net
ASPA对象数2,394rpki-client控制台(自行统计)
路由表中已发布ASPA的ASN2,122HE.net
路由表中的ASN总数87,781HE.net
路由表中的ASN总数87,595RIPE RIS (2026-07-15)
ASPA覆盖率2.42 %HE.net
参考：前缀的RPKI(ROA)覆盖率67.36 %HE.net

两个相互独立的工具，在对象数上只差3个、在ASN总数上只差两百来个，收敛得相当一致。HE.net自身的内部算术也对得上——把各RIR拥有ASPA的ASN数相加(RIPE 1,473 + ARIN 442 + LACNIC 107 + APNIC 100 + AFRINIC 0)，正好是2,122，而2,122除以87,781，正好是2.42%。

重点在最后两行的对比。 ROA覆盖了67%的前缀，而ASPA只覆盖了个位数百分比的ASN。 这是不同数量级的差距。

按RIR拆开看，部署的先后顺序一目了然。

RIR拥有ASPA的ASNASN总数覆盖率
RIPE NCC1,47331,7384.64 %
ARIN44220,4622.16 %
LACNIC10712,6230.85 %
APNIC10020,3070.49 %
AFRINIC02,1240

RIPE最先开放，所以最高;紧接着是ARIN;APNIC这个月才刚刚开放，所以是0.49%;AFRINIC还没支持，所以正好是0。有意思的是LACNIC的107——按APNIC那篇文章的说法，LACNIC还没有部署支持。我解析出来的发布点(publication point)显示，这些对象来自rpki-repo.registro.br——因为巴西的NIC.br运营着自己的CA。这意味着可以通过委托RPKI(delegated RPKI)直接发布，不必等RIR的托管服务，而实际上，我数出来的32个不同发布主机中，有相当一部分是运行Krill的各个独立机构。

增长的速度是真实的。Job Snijders那篇年度回顾里有一个"Uniq ASPA Customer ASIDs"的计数器，从2024年底的 87 个增长到2025年底的 556 个(+539%)。我今天数到的唯一customer AS是2,393个。也就是说，一年半里走过了87 → 556 → 2,393。

与此同时，常被引用的数字其实已经过时了。Job那句"大约0.5%"是2026年2月的说法，而一篇迟至2026年6月底的RIPE Labs文章仍然写着"well under 1% of the global ASN space"。今天用两个数据源测量，结果是2.42%。方向是好的，但97.6%的ASN依然没有ASPA，这个事实没有变。

对象本身的形态也能看出一些东西。在我解析的2,394个对象中，供应商条目总共有7,941个，平均每个对象3.32个，中位数是2个。恰好只列了1个供应商的对象最多，有718个(占总数的30%)，最多的是列出204个的AS14789。声明没有任何供应商的AS0类ASPA有59个。而验证草案建议(SHOULD)"一个AS应当只注册一份ASPA对象"，在2,394个对象里，违反这条建议的AS只有一个(AS61574)，而且那个还是一个大学的研究测试床。这条建议基本上是被遵守的。

Unknown 实际上等同于 Valid — 部分部署下的算术

那么在2.42%的覆盖率下，ASPA到底能起多少作用?读规范就能得到答案。而这一部分，是本文最重要的地方。

ASPA的验证结果只有三种——Valid、Unknown、Invalid。这三者是怎么被区分开的，是决定性的一点。验证草案第5.2节定义了一个provider authorization函数，对于一对(AS x, AS y)，会返回三种结果之一：如果AS x没有ASPA或ASPA无效，返回 "No Attestation" ;如果ASPA存在且AS y在列表中，返回 "Provider+" ;如果ASPA存在但AS y不在列表中，返回 "Not Provider+" 。

而第5.3节这样定义ramp长度的上下界：

  • max_up_ramp：算到 "Not Provider+" 第一次出现的位置为止。也就是说，没有ASPA的那一跳会被 乐观地 计入ramp。
  • min_up_ramp：算到 "No Attestation" 或 "Not Provider+" 第一次出现的位置为止。也就是说，只要没有ASPA，就在那里截断(悲观处理)。

判定结果由此分成三种。

max_up_ramp + max_down_ramp < N   ->  Invalid
min_up_ramp + min_down_ramp < N   ->  Unknown   (信息不足)
其余情况                          ->  Valid

由此可以得出一个结论。 要得到Invalid的判定，必须有人发布了ASPA，并且这份ASPA明确否定了那一跳。 如果ASPA压根不存在，那就是"No Attestation"，永远不会触发max那一路的计算，因此永远不会得出Invalid。结果只会是Unknown。

而第5.6节推荐的宽松策略是这样的——如果是Invalid，就把这条路由排除在路径选择之外(但仍保留在Adj-RIB-In中，以便重新评估)。但 被判定为Unknown的路由，应当(SHOULD)以与Valid相同的优先级来对待 。

把这两点合在一起，就是今天的现实。2.42%的覆盖率意味着，在任意一条AS_PATH上，泄漏真正发生的那一跳所在的AS，恰好发布了ASPA的概率很低。于是判定结果是Unknown，Unknown又被当作Valid来对待，什么都不会发生。RIPE Labs上发表的《ASPA Is Live. Can You See It Working?》一文里，作者用真实的RPKI数据跑实验，得到的结论也一样——大多数路由都显示为Unknown，不是因为这些路由本身可疑，而是因为大多数运营者根本还没有注册ASPA对象。

这不是bug，而是设计使然。在部分部署的情况下，要避免因误报(false positive)而误杀正常路由，就必须这样保守。ROV当年也走过同样的路。作为代价，付出的东西也很明确—— 现在这一刻打开ASPA，几乎挡不住任何东西。 收益要等覆盖率积累起来之后才会到来。

规范自己承认的局限

不少文章把ASPA包装成解决路由泄漏的万能药，但规范本身对自己的局限写得相当诚实，值得一读。

供应商劫持自己客户的情况抓不住。 第7.3节写道——供应商可以用forged-origin或forged-segment的AS_PATH，劫持直接或间接客户的前缀，也可以篡改发给客户的路由的AS_PATH， 这类攻击可能不会被ASPA检测到。 规范在这里的防线不是技术性的，而是合约性的——它认为这在理论上可能，但不是一个现实的场景，通常客户和供应商之间都有签署的合同，这类违规要么会带来法律后果，要么客户可以直接终止关系并删除对应的ASPA记录。这套说法有没有说服力见仁见智，但威胁模型的一部分被推给了合同，这一点值得知道。

AS_PATH prepend的操纵抓不住。 第7.4节——ASPA验证流程无法检测AS_PATH中AS号重复出现次数的删减或增加。不过规范补充说，这类攻击本身并不影响路由泄漏检测的能力。

自己发起的泄漏挡不住。 第8.4节明确指出——基于ASPA的验证能够检测和缓解AS_PATH中更早出现的AS所制造的路由泄漏，但 无法阻止本地AS自己向邻居发起泄漏。 路径上存在复杂关系时，也可能导致泄漏检测失败。规范因此写道，这正是OTC属性(RFC 9234)要填补的空白，并建议(RECOMMENDED)实现OTC流程来补充ASPA验证。 ASPA不是OTC的替代品，而是它的搭档。

ASPA一旦出错，两个方向都会受伤。 第7.2节——漏填一个供应商会削弱泄漏检测能力，而错填一个供应商，则可能导致一条完全正常的路由日后被判为ASPA Invalid。因此第4节建议，像DDoS缓解服务商这样的备用(standby)供应商，或应急专用的供应商，都应当 提前 登记好，以避免ASPA传播和路由传播之间出现竞态。在运维层面，这是最痛的一点——恰恰是在想把流量绕开走应急路径的那一刻，那条经由未登记供应商的路由会因为Invalid而失效。

IPv4/IPv6的不对称，被抹平到了宽松的一侧。 第7.1节——供应商集合是把IPv4和IPv6合并在一起管理的，因此只在某一种地址族上存在的客户-供应商关系，看起来在另一种地址族上也被允许了。规范把这称为"合理的折中"，理由是这样能让注册和验证更简单，也不会产生误报。

实现三年前就已经有了

部署没有铺开，原因不是缺代码。

  • OpenBGPD 根据验证草案的实现现状小节，从7.8版本起支持ASPA。查GitHub上openbgpd-portable的标签可知，7.8是在 2023年2月3日 发布的——距今三年零五个月。
  • BIRD 根据它自己的NEWS文件，在 2.16(2024-12-04) 加入了"ASPA support in filters, Static and RPKI"，之后在2.16.1修复了解析器的bug，在2.18(2025-12-26)加入了AS_SET处理，在2.19.0(2026-05-25)修复了downstream验证。这说明它正被积极维护着。
  • Routinator (NLnet Labs)在0.13.0加入了ASPA和RTR版本2支持，从0.14.1(2025-01-22)起默认编译进去。不过现在仍然需要用--enable-aspa选项 显式打开 ——官方文档里ASPA至今仍列在"Advanced Features"下，并附有"目前记述于IETF的两份Internet-Draft中"这样的说明。
  • 商业厂商 还没跟上。验证草案记录的是Cisco在2025年基于IOS-XR的 Early Field Trial 实现，此外还列了RTRlib、NIST-BGP-SRx(不支持IXP/RS扩展)和FreeRTR。APNIC写道"多家商业厂商已发布或正在开发支持"，但没有点名是哪几家。

再补充一点，草案的实现现状小节本身已经过时了。BIRD那一条仍然写着"位于side branch(mq-aspa)，预计在RTR v2定稿之后发布"，而BIRD自己的NEWS却说支持从2.16起就已经进入了正式版本。这不该怪草案本身——该小节自己就写明"没有花任何力气去独立核实这里列出的信息"，内容都是贡献者自行提交的，而且明确表示这一节会在正式发布为RFC之前被删除。不过这也确实说明，这一节不该被当作厂商支持情况的对照表来读。

归纳一下： 开源路由器上的ASPA验证代码三年前就已经存在，而覆盖率是2.42%。 瓶颈不在代码，而在对象本身，以及真正去强制执行的决心。

那么现在该做什么

现在就值得做的事：发布ASPA对象。 这是一个不对称地便宜的动作。我发布ASPA，受益的不是我自己，而是所有验证我路由的其他人(而如果我的前缀被泄漏了，抓住这一点的也是别人的验证器)。它不需要我自己的路由器打开任何开关，也不影响我自己的流量。如果你是RIPE NCC、ARIN或APNIC的会员，在仪表盘上就能操作。即便不是这三家的会员，上面registro.br的例子也说明了可以通过委托RPKI直接发布。要注意的地方前面已经写了——别漏掉备用、应急供应商，每个AS只保留一份对象，并建立一个供应商关系一变化就更新的运维流程。忘记更新的ASPA，日后会杀死自己的路由。

还不必急着做的事：把拒绝ASPA Invalid路由这个开关打开。 在今天2.42%的覆盖率下，打开它带来的防护几乎可以忽略不计，而因为登记错误的ASPA误杀正常路由的风险却是真实存在的。更何况规范目前还不是RFC，Last Call评审刚刚给出的是"Almost Ready"的结论。RTR v2也排在同一个队列里。用日志模式观察(第6.6节专门讲了日志)、看着覆盖率慢慢上升，才是这个阶段该做的事。

依然应当优先做的事：ROV。 证据就是本文的出发点本身。在Telegram事件中，真正造成损失的，是那些没有做ROV的上游;而挡住损失的，是其余做了ROV的一方。ROA覆盖率是67%，ASPA只有个位数百分比。如果你还没有强制执行ROV，那应该先做这件事，再去考虑ASPA。 同时也请一并看看RFC 9234的OTC ——ASPA规范自己就建议用OTC作为补充，OTC已经是RFC了，而且它是唯一能阻止你自己向别人发起泄漏的那一层。

ASPA也许根本不是你的问题。 如果你是只有一个上游的stub AS，发布几分钟就能搞定(只有一个供应商的ASPA——今天全部对象里有30%就是这个样子)，自己去跑验证的理由并不多。验证真正能发挥价值的，是那些从多个对等方和多条转接线路接收路由的网络。

结语

2026年6月的Telegram事件，证明了RPKI ROV确实在起作用。据Kentik测算，劫持路径只触达了自家数据源的1.6%，Madory和Bhatia都把原因指向了Telegram自己的ROA和上游的过滤。和2008年的巴基斯坦-YouTube事件相比，互联网明显变得更好了。

与此同时，同一起事件也暴露了天花板。正如Bhatia指出的，这一次ROV之所以赢了，是因为这次攻击手法拙劣，把origin给换掉了。如果攻击者保留origin不变、把自己插到前面，ROV本会保持沉默——而路由泄漏本质上正因为origin合法，从一开始就不会触发ROV要回答的那个问题。

ASPA是瞄准这一空白的下一层，2026年正是这一层开始成形的一年——7月10日三份草案进入Last Call，三家RIR开放了发布，预计年底前五家全部开放。实现代码在OpenBGPD里已经存在了三年。

可是今天清点一下，只有2.42%。而按验证算法的结构，覆盖率低意味着判定结果会是Unknown，而Unknown又和Valid受到同等对待。也就是说， ASPA哪怕现在就打开，也几乎挡不住任何东西。 这不是失败，而是这类技术被部署时本来的样子——ROA当年也是从87个对象起步的，如今已经覆盖了67%的前缀。

所以结论平淡，但很明确。现在就去发布，先别急着强制执行，把ROV和OTC先安排好。而在引用任何数字之前，请按当天的日期自己去数一遍——就在"well under 1%"这句话到2026年下半年的文章里还在被反复引用的同时，两个独立数据源在今天测出的数字是2.42%。

参考资料

현재 단락 (1/124)

2026年6月16日，印度政府下令封锁Telegram。围绕NEET医学院入学重考，有组织的作弊频道成了问题，依据IT法案第69A条，命令要求在6月22日前完成封锁。到这里为止，这还不是一个路由问题。

작성 글자: 0자원문 글자: 14,330자작성 단락: 0/124