摘要

  • BGPMon 对2010年4月8日事件的原始观测显示，公开路由记录中被识别为中国电信数据中心网络的 AS23724，在大约十五分钟内宣告了约37,000个并不分配给它的唯一前缀；共同可见路径包含 AS4134 后接 AS23724，说明问责不能只停在异常起源 AS，也必须检查 AS4134 的导入、选择和继续通告边界。
  • 约37,000个前缀是异常控制平面规模信号，不是全球流量占比。BGPMon 后续说明中估计只有约十分之一异常前缀传播到中国网络之外，并明确提醒前缀份额不等于流量份额；公开证据证明异常公告和部分国际传播，但不能证明恶意意图、报文拦截、数据查看、数据存储或固定比例互联网流量被转移。

事件边界：只分析2010年4月8日的 AS23724-AS4134 路由事件

这起事件的边界应当先收紧。本文只讨论2010年4月8日由 BGPMon 记录的 AS23724 与 AS4134 相关控制平面异常，不把后来的中国电信路由事件、其他运营商泄漏、网络安全指控或商业争议并入同一事实包。这样的边界不是缩小问题，而是避免把不同时间、不同路径、不同证据类型的事件混成一个无法验证的叙事。

BGPMon 的原始说明给出了一个可操作的起点：在2010年4月8日，AS23724 宣告了一组异常庞大的前缀。BGPMon 描述说，该网络平时大约只起源40个前缀，但在该事件中宣告了约37,000个唯一前缀，持续约十五分钟。BGPMon 原始记录中的第一条异常公告时间为17:54:31 UTC，最后一条异常公告时间为18:10:14 UTC。这里的时间是收集器观测时间，不应被写成全球所有路由器、所有链路或所有数据包路径的绝对开始与结束时间。

这一区分很关键。BGP 是控制平面协议，路由收集器看到的是路由更新、路径属性和可达性变化。它能证明某些观察点收到了异常路由，能帮助还原路径传播范围，也能保存事后问责所需的时间线。但它不能仅凭路由更新证明某个终端用户的数据包实际走过哪条链路，不能证明数据包内容被检查，不能证明数据被保存，也不能证明事件一定出于恶意。把控制平面证据当成数据平面证据，是这类事件中最常见、也最容易误导的错误。

因此，本文使用“路由泄漏”“劫持”或“错误配置”时，只在被公开来源归因或在定义清楚的情况下使用。更准确的基础描述是：AS23724 在短时间内起源了大量并未分配给它的前缀；AS4134 出现在可见共同路径上，并且其对这些路由的导入、选择与继续通告，成为异常从起源边界向外传播的关键控制点之一。这个事实已经足够严肃，不需要额外假设恶意意图或数据查看行为。

时间线：十五分钟不是全网统一经历

BGPMon 记录的17:54:31 UTC 到18:10:14 UTC，常被简化为“十五分钟”。作为事件摘要，这个说法可以成立，但它仍然需要说明来源和含义。它表示 BGPMon 在自身观察集合中看到异常公告的起止窗口，而不是每一个网络、每一个前缀、每一个路由器都在同一秒开始接受异常路径，也不是所有被影响的路径在同一秒恢复。

在互联网路由中，传播具有层次性和选择性。一个 AS 可以起源路由；邻接 AS 可以接受或拒绝；接受后是否选为最佳路径，取决于本地偏好、AS path、MED、社区属性、商业关系和其他策略；被选中的路由是否继续向其他邻居通告，又取决于导出策略。由此，某个收集器看到异常，并不意味着全网都看到异常；某些外部网络没有看到异常，也不意味着起源公告不存在。

这也是为什么 BGPMon 后续说明对规模作了限定。它估计异常前缀中只有约十分之一传播到中国网络之外，并指出其分析所用的 RIPE RIS 收集器中有28%检测到了事件的一部分。这个28%不是全球路由器比例，不是终端用户比例，也不是数据流量比例。它只是收集器视角中的可见范围指标。用它可以说明事件确实越过了本地边界并进入部分国际观察点；不能用它推出全球互联网某固定百分比被“接管”。

如果要建立严谨时间线，至少需要分开记录六个时刻：AS23724 异常导出开始的时刻；AS4134 首次导入并可能选择该路径的时刻；AS4134 或其他邻接网络开始继续通告的时刻；外部监测系统产生告警并找到责任团队的时刻；配置修正或撤回开始的时刻；独立收集器和主动测量确认回到预期状态的时刻。公开材料能支撑其中一部分，不能补齐全部内部操作记录。这一缺口本身就是问责重点。

约37,000个前缀：异常规模信号，而非流量份额

BGPMon 的约37,000个唯一前缀，是这起事件中最醒目的数字。它之所以重要，不是因为它可以直接转换成互联网流量比例，而是因为它显示了一个明显超出正常授权边界的控制平面变化。一个通常只起源约40个前缀的网络，如果突然宣告约37,000个前缀，任何成熟的运营系统都应当把它视为高严重度异常：起源集合突变、前缀数量突变、路径关系突变、潜在外部传播突变。

BGPMon 后续复盘提到，约37,000个前缀约相当于当时路由表的十一个百分点左右。但前缀份额不是流量份额。一个前缀可能承载很少流量，也可能承载巨大流量；前缀长度不同，覆盖地址数量不同；某个前缀被异常宣告，也不表示所有目的地流量都会选择异常路径；即便控制平面选择发生变化，数据平面也可能因为本地策略、热土豆路由、缓存、会话状态、路径偏好或过滤而呈现不同结果。

因此，基于前缀数量说“固定比例的互联网流量被转移”，不符合证据边界。较稳妥的说法是：BGPMon 观察到约37,000个唯一前缀被 AS23724 异常起源，事件持续约十五分钟；BGPMon 估计其中约十分之一传播到中国网络之外；这些数字显示了异常路由公告的规模和部分外部传播范围，但不能证明对应比例的数据流量被转发、查看或保存。

后来一些报告给出更高或不同的数量，并不必然相互矛盾。不同观察者可能使用不同收集器、不同时间窗口、不同去聚合规则、不同“受影响”定义。有的统计路由条目，有的统计唯一前缀，有的统计被至少一个观察点看到的路径，有的统计某段时间内曾经出现过的异常可达性。问责分析不应挑选最大数字制造冲击，而应说明每个数字来自哪里、计量口径是什么、能证明什么、不能证明什么。

AS23724：异常起源与导出边界

在可见证据中，AS23724 是异常起源边界。公开路由记录将 AS23724 识别为中国电信数据中心网络，BGPMon 观测到它宣告大量不属于自己的前缀。无论触发原因是配置错误、自动化失控、策略模板误用还是其他内部操作，第一层问责问题都是：一个起源 AS 为什么能够把超出其授权集合的大量前缀导出到邻居？

起源边界的责任不是抽象道德判断，而是可以被配置和验证的工程责任。一个 AS 应当维护可解释的授权前缀集合：哪些前缀属于本 AS，哪些前缀来自客户，哪些前缀可向上游或对等方通告，哪些前缀只在内部可见，哪些例外有到期时间和审批记录。导出策略应当从这些记录生成或至少与这些记录一致，而不是依赖人工记忆或宽泛许可。

对 AS23724 这样的边界，最基本的失败模式包括：把从其他邻居学到的路由重新当作自身可导出的路由；把全表或大块路由错误导出；把测试或迁移配置推到生产会话；未设置最大前缀阈值；未对起源授权集合做自动校验；未在导出前检测“从约40个前缀到约37,000个前缀”的突变。上述任何一个机制缺口，都可能在几分钟内把局部配置错误变成跨域路由事件。

BGPMon 的作者曾认为事故性配置错误比恶意更可能，但也明确表示这是推测，因为没有与网络工程师核实。本文保留这个边界：配置错误是一个被公开来源提出的可能解释，不是已证实根因。真正可以问责的是控制面事实：异常导出发生了，规模异常明显，且没有在第一个边界被充分阻断。

AS4134：导入、选择与继续通告边界

AS4134 在共同可见路径中位于 AS23724 之前，这使它成为第二个关键控制点。AS23724 可以发出异常路由，但异常能否进一步传播，取决于直接邻居是否接受、是否选路、是否继续对外通告。AS4134 的责任不等同于 AS23724 的责任，却也不能被起源 AS 的异常完全吸收。

对直接邻居而言，导入策略是第一道防线。如果邻接关系是客户、对等或内部关联关系，不同关系应有不同可接受前缀集合。一个数据中心网络或下游客户突然向上游或骨干邻居提供约37,000个并不属于它的前缀，应该触发客户前缀过滤、IRR/RPKI 辅助校验、最大前缀阈值、告警和会话保护。即便个别路由被接受，关系感知导出策略也应限制这些路径向不合适的邻居继续传播。

这就是“AS4134 导入和继续通告边界”的核心。问责不是说 AS4134 一定发起了事件，也不是说它一定知道异常性质，而是说它控制了一个可测量的网络边界：从 AS23724 进入 AS4134 的路由是否被接受；被接受后是否成为可用路径；是否继续传播给其他 peers 或 transit；是否有最大前缀限制；是否有客户授权前缀过滤；是否有事件后审计记录能说明为什么当时策略没有阻断。

从可公开验证角度看，AS4134 的路径位置说明它是传播链中的一个重要节点。BGPMon 表示 AS4134 的 peers 至少传播了异常集合的一部分。这不等于每个 AS4134 邻居都接受，也不等于所有异常前缀都出境；但它足以要求对该边界提出工程问题：导入策略是否默认拒绝？客户前缀表如何生成？异常增量阈值是多少？路由泄漏发生时，撤回是否由独立观察点确认？

继续传播：每个邻居都有自己的责任

跨域路由事件不会只由一个 AS 的配置决定。AS23724 控制起源公告和导出策略；AS4134 控制第一层可见导入、选择和继续通告；更远的 peers 与 transit 网络控制自己的接受、偏好、过滤和再传播。传播范围是这些本地策略叠加后的结果。

这使“责任分布”比“责任稀释”更准确。每个网络不应因为上游已经出错，就自动免除自身过滤义务。尤其在商业关系清楚的场景下，客户到提供商、提供商到客户、对等到对等之间的导入导出规则应当反映关系方向。客户通常不应向提供商通告整个互联网；对等方通常不应成为第三方 transit；提供商不应把某个下游异常学来的大量前缀毫无约束地扩散。关系感知过滤正是为了把这些业务事实转化为路由策略。

这也是 BGP Roles 和路由泄漏防护讨论的意义所在。传统 BGP 本身信任邻居通告，并不内置完整的商业关系语义。没有本地策略，协议不会自动知道某条路径是否违反了客户、提供商、对等关系。BGP Roles 等机制试图为会话关系提供更明确的角色信息，辅助识别不应传播的路径。但这种机制也不是单独的万能解法。它需要双方配置一致，需要与现有策略、监测和例外管理结合，并且不能替代准确的授权前缀记录。

对更远的网络而言，问责重点不是“为什么没有知道 AS23724 内部发生了什么”，而是“为什么接受了与自身关系和授权数据不一致的路径”。如果某网络具备客户过滤、IRR 生成过滤、RPKI origin validation、最大前缀保护和异常告警，却仍然选择接受并传播异常前缀，那么它需要提供策略例外、误判原因和修复证据。如果它没有这些机制，问题则更直接：它把跨域路由完整性建立在邻居不会出错的假设上。

路由收集器能证明什么，不能证明什么

BGPMon、RIPE RIS、RouteViews 以及其他监测系统在这类事件中承担证据保存角色。它们可以记录路由公告何时出现，哪些观察点看到了路径，AS path 如何变化，前缀集合规模如何变化，异常路由何时消失。没有这些外部观察，事件可能只留下内部日志，外部受影响者无法判断传播范围和恢复状态。

但路由收集器不是生产转发表。它们通常连接到部分 peers，接收的是控制平面视图，且覆盖不均匀。一个收集器没有看到某条异常路由，不代表没有任何网络看到；一个收集器看到某条异常路由，也不代表所有流量都走该路径。收集器还可能受采样、会话位置、路径选择、路由聚合、时间分辨率和数据处理规则影响。事后统计必须说明观察点集合和处理口径。

对2010年4月8日事件，BGPMon 的价值在于给出了可引用的异常规模、时间窗口、路径关系和传播限定。它记录了约37,000个唯一前缀，约十五分钟，AS4134 与 AS23724 的共同可见路径，以及约十分之一异常前缀传播到中国网络之外的估计。它还明确修正了容易误读的“前缀份额等于流量份额”问题。这些都是问责分析的基础。

但是，若要证明数据平面影响，还需要不同证据：从多个地理和网络位置进行 traceroute 或主动探测；受影响前缀所有者的流量日志；运营商转发表快照；NetFlow 或等价流量记录；终端用户故障报告；DNS、应用层监测和路径变化对照。公开事实包没有提供足以量化全球数据流量转移的材料。因此，本文不声称固定流量比例、不声称报文内容被查看，也不把控制平面异常扩大成未经证明的数据平面结论。

RPKI 的作用与边界

RPKI 和 ROA 能帮助回答一个关键问题：某个 AS 是否被授权起源某个前缀。如果前缀持有人发布了准确 ROA，且接收网络启用了 RPKI origin validation，那么未授权 origin 可以被标记为 invalid，并可根据本地策略被拒绝。对于类似 AS23724 突然起源大量不属于自身前缀的场景，RPKI origin validation 能提供重要防线，尤其当被宣告前缀已有有效 ROA 且 AS23724 不是授权 origin 时。

但 RPKI 不是完整路由安全。第一，2010年时 RPKI 部署成熟度与今天不同，不能把今天的部署预期机械套回当时所有网络。第二，origin validation 只验证起源 AS，不验证完整 AS path 的商业关系是否合理。第三，如果某次泄漏保留了正确 origin，但在中间路径上错误传播，ROA 可能仍显示 origin valid，却无法判断路径违反了客户、提供商或对等关系。第四，RPKI 依赖前缀持有人维护准确 ROA；错误、过期或缺失记录会影响验证效果。

因此，RPKI 的正确位置是控制栈中的一层，而不是结论本身。它应与 IRR 数据、客户前缀过滤、默认拒绝外部策略、最大前缀限制、BGP Roles、ASPA 或其他路径关系验证思路、异常监测和人工升级流程一起工作。用 RPKI 可以减少未授权 origin 被接受的概率；不能用它证明某个事件不会发生，也不能用它替代邻居关系过滤。

对2010年事件的问责标准应当这样表达：如果当时所有相关前缀都有准确授权记录，且直接和间接邻居都启用了严格 origin validation，那么部分未授权起源可能被拒绝；但即便如此，仍需要关系感知过滤和最大前缀阈值来限制异常规模与传播范围。运行中的路由器策略才决定实际接受与传播，注册记录和 ROA 是决策依据，不是自动执行的路由警察。

前缀授权、IRR 与运行配置之间的差距

网络资源记录的作用是提供可核验的账本：哪个组织持有哪些前缀，哪个 AS 被授权起源，哪些客户前缀应被某个提供商接受，哪些对象已过期或不再有效。这些记录对问责很重要，因为它们让过滤策略有来源，让异常检测有基线，让事后审计能比较“应当接受什么”和“实际接受了什么”。

但记录本身不阻止路由传播。若运营商拥有准确 IRR 对象和 ROA，却没有把它们转化为路由器上的 prefix-list、route-map、policy-statement 或等价配置，异常仍可能被接受。若自动生成过滤器但不部署到所有边界，保护也会出现缺口。若部署了过滤器但例外长期不过期，或在维护窗口临时放开后没有恢复，账本与运行状态就会再次分离。

因此，成熟控制栈必须把四类状态绑定起来：源数据、生成配置、运行配置和观测结果。源数据说明哪些前缀被授权；生成配置说明这些授权如何转成具体过滤规则；运行配置说明路由器当前实际使用什么策略；观测结果说明外部世界是否仍能看到未授权传播。任何一层缺失，问责就会变成口头承诺。

在 AS23724-AS4134 事件中，最重要的不是事后说“应该有过滤”，而是提出可验证问题：AS23724 的导出列表在事件前是什么？AS4134 对 AS23724 的导入列表从哪里生成？最大前缀阈值是多少？当从约40个前缀增加到约37,000个前缀时，是否触发 warning-only 或 hard shutdown？异常路由撤回后，是否有独立收集器证明同类前缀不再通过同一边界传播？这些问题比简单归咎更有工程价值。

最大前缀阈值与异常体积控制

最大前缀控制是这类事件中最直观的防线之一。一个邻接会话平时只应接收几十、几百或几千个前缀时，突然收到约37,000个前缀，应当触发阈值保护。阈值可以分层：接近正常上限时告警，超过合理范围时拒绝新增路由，严重超限时关闭会话或进入保护状态。具体动作取决于业务关系和可用性要求，但不能没有阈值。

最大前缀控制不能证明每个前缀授权正确，也不能识别所有路径关系问题。一个攻击者或错误配置可以只泄漏少量高价值前缀，从而绕过体积阈值；一个合法客户在扩容时也可能短期增加前缀数量。因此，最大前缀不是完整安全机制，而是体积异常刹车。它的优势在于简单、可测试、适合阻断“从几十到数万”的突变。

在这起事件里，约37,000个前缀的规模恰好使最大前缀控制成为问责焦点。如果直接邻居对 AS23724 有符合关系的前缀上限，异常应当很快被限制在该会话边界。如果只是 warning-only 且无人响应，告警不等于控制。如果 hard limit 设置过高，阈值就失去意义。如果临时解除限制没有到期机制，维护便利就会变成系统风险。真正可接受的证据，是事件前后的阈值配置、告警记录、触发动作和恢复验证。

关系感知过滤：从“邻居说什么”到“邻居应该说什么”

BGP 的基本运行方式依赖邻居之间交换可达性信息。问题在于，邻居能说什么，并不等于邻居应该说什么。一个客户不应该向提供商宣告整个互联网；一个对等方不应该把另一个对等方当作 transit；一个数据中心网络不应突然成为数万外部前缀的起源。关系感知过滤的目标，就是把这些业务关系和资源授权转换成机器可执行规则。

在2010年事件中，AS23724 与 AS4134 的边界体现了这一点。即使 AS23724 发出了异常公告，AS4134 仍有机会在导入阶段检查：这些前缀是否属于 AS23724 或其客户？AS path 是否符合关系预期？数量是否超过阈值？是否与已有授权记录冲突？如果答案异常，策略应默认拒绝或至少阻止继续外传。

继续通告边界同样重要。一个网络可能因为内部偏好接受某条路由，但不代表应向所有邻居传播。商业关系决定导出范围：客户路由可以向提供商和 peers 宣告，提供商或 peer 学到的路由通常不应再向其他 providers 或 peers 随意传播。路由泄漏往往正是这些导出关系被破坏的结果。RFC 对路由泄漏的定义和运营最佳实践，正是把这种关系违背转化为可讨论、可检测、可缓解的类别。

关系感知过滤的难点在于数据准确性和例外管理。互联网商业关系复杂，某些网络同时存在客户、对等、私有互联和部分 transit；大型运营商内部还可能有多层 AS。控制栈必须允许例外，但例外必须有所有者、理由、到期时间和回放测试。否则，“复杂关系”会成为永久放开过滤的借口。

独立撤回验证：事件结束不能只看内部声明

一场路由泄漏的结束，不应只由涉事网络内部声明决定。内部可以说配置已回滚、会话已重置、错误路由已撤回；但问责所需的是外部可验证的恢复证据。BGPMon 原始窗口给出了最后异常公告的收集器时间，这类外部观测是恢复记录的重要组成部分。

可验证撤回应包括至少三个层次。第一，涉事边界发送了撤回或停止宣告异常前缀，且路由器日志能说明具体动作。第二，直接邻居不再从该边界接收异常集合，路由表和策略状态能证明过滤恢复。第三，独立收集器和主动测量从多个位置确认异常路径消失，相关前缀回到预期 origin 或不再通过异常路径可达。

如果只有内部工单，没有外部观察，公众无法判断异常是否真正结束。如果只有外部观察，没有内部原因记录，运营者无法证明失败类别已被修复。如果只有一次撤回，没有回放测试，未来同类错误仍可能穿过同一边界。可验证恢复必须把“停止异常”与“防止同类复发”连接起来。

对 AS23724-AS4134 事件，一个完整恢复包应回答：异常导出何时开始？AS4134 何时接受？哪些邻居继续传播？谁收到告警？谁拥有事件？配置如何改变？撤回何时发送？哪些独立观察点确认恢复？后续是否有控制测试证明同一约37,000前缀类别无法再次跨过边界？公开材料不足以完整回答这些问题，所以它们应成为事后问责清单，而不是被标题数字掩盖。

传播证据与测量限制并存

公开证据足以说明事件发生并产生部分外部传播。BGPMon 记录的路径包含 AS4134 和 AS23724；BGPMon 表示 AS4134 的 peers 至少传播了异常集合的一部分；其后续说明估计约十分之一异常前缀传播到中国网络之外；其 RIPE RIS 观察集合中28%的收集器检测到事件部分。这些证据构成了一个严肃的传播事实：异常不是只存在于单个内部路由器的配置文件中，而是被外部观察到。

与此同时，公开证据也要求克制。约十分之一外部传播是 BGPMon 观察口径下的前缀传播比例，不是流量比例。28%收集器检测到事件部分，是观测基础设施覆盖下的可见性指标，不是互联网用户比例。AS path 可见，不能证明每个数据包转发路径。路由公告被接受，不能证明应用连接实际迁移。异常路径出现，不能证明内容被读取。

这种克制不是替运营商开脱，而是使问责更有力。未经证明的流量或意图叙事，容易被一个事实反例击穿；可验证的控制平面问责则更难回避。一个 AS 是否异常起源，邻居是否接受，过滤是否存在，阈值是否触发，撤回是否被独立确认，这些都可以被证据检验。网络基础设施问责应优先抓住这些可验证点。

当前控制栈：没有单一补丁，只有分层约束

从今天看，这类事件的控制栈应包括多层机制。第一层是准确资源记录：RIR 分配记录、IRR route/route6 对象、ROA、客户清单和内部授权数据库应保持一致。第二层是默认拒绝策略：外部 BGP 会话不应默认接受邻居宣告的一切，而应只接受授权集合。第三层是自动生成和部署过滤器：把授权数据转为运行配置，并记录生成版本。第四层是体积保护：最大前缀阈值、异常增量告警和硬限制。

第五层是 RPKI origin validation。它可以拒绝 ROA 明确不授权的起源，但不能证明完整路径合法。第六层是关系感知策略，包括 BGP Roles 和泄漏防护机制，用来限制客户、提供商、对等之间不合理传播。第七层是监测和升级：监测系统要检测起源变化、路径变化、前缀体积变化和异常传播，并把告警交给有权改变配置的人。第八层是恢复验证：撤回和修复必须由独立观察点确认。

这些机制彼此补充，而非互相替代。只靠 IRR 会遇到数据陈旧；只靠 RPKI 会漏掉 origin valid 的路径泄漏；只靠最大前缀会漏掉小规模高影响异常；只靠人工监控会在分钟级事件中反应过慢；只靠内部声明无法建立外部信任。2010年 AS23724-AS4134 事件之所以仍有分析价值，正因为它显示了多层控制同时需要存在：起源不应越界，直接邻居不应盲收，继续传播不应无关系约束，撤回不应无法验证。

结论：把标题数字改写成可检验责任

2010年4月8日事件的公共讨论常被约37,000个前缀、约十一个百分点路由表、约十五分钟、约十分之一外部传播这些数字吸引。数字重要，但它们的正确用途不是制造流量结论，而是建立问责问题。约37,000个前缀说明起源集合异常；约十五分钟说明异常存在于可观测窗口内；约十分之一外部传播说明边界过滤没有把事件完全限制在本地；28%收集器可见说明外部观测基础设施记录到部分传播。每个数字都应绑定 BGPMon 的口径和限制。

真正的问责标准应当是可证伪的。AS23724 是否只能导出授权前缀？AS4134 是否只接受符合关系和授权的路由？继续通告是否遵守客户、提供商和对等关系？最大前缀阈值是否足以阻断从几十到数万的突变？RPKI 与 IRR 是否被转化为实际运行策略？异常撤回是否被独立观察点确认？同类失败是否在控制环境中回放并被阻断？

如果未来出现路由器日志证明完全不同的触发原因，结论应相应调整。如果数据平面测量证明传播范围显著不同，影响评估也应改变。如果当前配置、策略版本和回放测试能证明同一未经授权路由集合已无法跨过 AS23724-AS4134 类似边界，责任分析应记录这一改进。没有这些证据之前，最稳健的结论是：这起事件证明了互联网路由问责不能依靠信任邻居不会出错，而必须依靠授权记录、运行策略、关系过滤、异常测量和可验证恢复共同闭环。