TTNet 2004 路由泄漏与客户前缀过滤问责框架

摘要

冻结事件边界：本文覆盖了 2004 年 12 月 24 日观察到的 AS9121/TTNet 路由表泄漏。该内容不将该事件与后续土耳其连通事件、无关的路由劫持，或涉及其他自治系统的其他泄漏合并在一起。
规模应当被归因：NANOG 的重建工作和后续研究显示，这次泄漏涉及超过 100,000 个前缀，代表了当时部分监测点可见全球路由表的多数份额。具体数量取决于采集点、时间间隔、重复项处理方式及事件定义。该数字是证据性估计，不是任何统一运营商日志。
故障跨越了关系边界：从一个关系上下文学习到的路由被广告到不应到达的地方。其他网络在其本地策略下接收并传播了这些路由。结果不仅是 TTNet 的服务故障，而是分布式的全球路由状态变化。
责任随控制而定：AS9121 控制了其路由的引入、导出、路由生成、发布、监测与撤销。直接提供商和对等体控制了客户前缀过滤、AS 路径约束、最大前缀限制、告警和后续导出。进一步的导入方控制了自身的接收与收敛边界。
注册表是证据而非执法：ASN、地址、IRR 与后期 RPKI 记录可以描述预期来源与资源持有人。它们不会单独配置路由器策略。实际运行代码和加载后的策略才决定了哪条路由被接收并传播。
现代控制是互补的：显式 eBGP 策略、授权前缀过滤、最大前缀限制、路由来源验证、BGP Roles 与 OTC、客户锥验证、异常检测以及经过测试的回滚可覆盖不同故障模式。没有任何单一措施能完全事后修复全部问题。
恢复需要外部证据：单次路由修正或会话重置不足以构成证据。可问责的恢复记录应展示撤销、替代路径、剩余陈旧路由、对等方协同、收敛过程，以及从独立视角确认恢复的可达性。

事件边界是 2004 年 12 月 24 日

进行基础设施事故复盘的第一步，是先冻结事件边界。2004 年 12 月 24 日，运营商观察到与 TTNet（自治系统 9121）相关的一组异常路由。该事件当时在 NANOG 上讨论，后续又利用 RouteViews 与 RIPE 采集器的公开 BGP 数据，在 NANOG 演示中重建了该过程。[1][2] 后来的学术研究将该事件作为典型示例，或将其作为路由泄漏与路由异常分析的案例标签。[3][4][5]

公开记录持续支持核心命题：AS9121 在其预期范围之外传播了极大一部分路由表，且其他网络接收并重新分发了足够多的公告，导致可达性问题广泛出现。本文分析的就是这一事实模式。

必须避免夸大该命题。公开来源并未提供完整的 TTNet 路由配置、每条路由映射、所有双边协议、所有运营消息，或一条普适且权威的时间线。它们也未能证明确认恶意意图。它们没有显示互联网里的每个网络都接受了每一条泄漏路径，也没有显示每个用户体验到完全一致的影响。

数字需要特别谨慎处理。NANOG 重建结果和后续文献常见描述为受影响前缀超过 100,000 个，并将该集合描述为当时可见全局表的大部分。[1][3][4] 这些表述有意义，但属于测量表述。采集器仅能看到其所连接会话输出的路由。不同采集器可能接收到不同路径，在不同时间记录更新、以不同方式抑制重复项，并对抵达前就被过滤的路由保持不可见。

因此合适的编辑实践是偏向归因而非虚假精确。按 2004 年路由表规模而言，这一事件很大。其精确前缀数量和持续时间随观测点和分析方法而变化。这种变异并不构成缩小事件严重程度的理由，而是要求保留底层 BGP 证据，并说明估算方法。

时间维度也很关键。多年后才标准化的控制机制应作为比较基线，而非追溯合规测试。RFC 7908 的路由泄漏分类在 2016 年发布。[12] RFC 8212 的显式策略默认行为在 2017 年发布。[13] RFC 9234 的 BGP Roles 与 Only-to-Customer 机制在 2022 年发布。[14] 这些文档帮助识别控制问题，但并不能证明 2004 年 AS9121 或其邻居已部署了这些机制。

可辩护的问题不是“为什么 2004 年网络未符合 2022 标准”，而是“哪些运营不变量应限制客户或对等方可发布的范围、哪些组织控制了这些不变量、以及哪些证据可证明路由状态恢复到正常状态。”

路由泄漏是关系策略失效

BGP 在自治系统间分发可达性信息。每个网络在本地策略下选择路由，并决定将哪些已选路由通告给哪个邻居。RFC 4271 定义了基础协议、消息类型、路由属性、选择流程和撤销行为。[11] 它并未对每个会话编码通用的商业或运营关系。

关系信息很重要，因为并非所有邻居都会自动接收该网络的一切可达性信息。客户通常通告自身路由以及其有权转接的路由。提供商通常可向客户发布较广范围可达性，因为客户为其购买中转服务。结算对等通常交换自身和客户路由，而不是在无关联提供商之间免费提供中转。

“客户”“提供商”“对等体”这些术语简化了真实安排，但会暴露策略边界。从一个提供商学到的路由通常不应被当作该网络向另一提供商提供中转而去通告。对等体学到的路由通常不应被导出到另一个对等体或提供商。客户的完整路由表通常不应被视为客户的授权起源全集。

RFC 7908 后来将路由泄漏定义为超出预期范围传播，通常违反与成对关系相关的策略。[12] 该定义在这里有用，因为它关注可观测到的路由传播，而非推断动机。错误的路由穿越了错误的边界。

TTNet 事件常被描述为路由表泄漏，因为异常公告表示一组庞大的路由，这组路由 AS9121 在当时语境下不应导出。可问责性问题在于：无论触发错误是源于路由映射、重分发、策略生成、会话分类或其他机制，公开可见的失败都是导出集合与有界客户或对等角色严重不一致。

接收方随后作出本地决策。直接邻居接收了这些路由。一些接收方可能基于路径属性、商业偏好或路径长度而优选它们。一些进一步导出。另一些则可能过滤，或在最大前缀限制下拒绝，或选择不受影响的替代路径。事件的影响范围因此是多种策略共同作用的结果。

分布式因果不应变成无主因果。泄漏方控制了它发布什么；直接邻居控制了其在该关系中接收什么；后续每个转发方控制了它中继什么。职责不同，但每项职责都具体且可执行。

BGP 更新证据不是万能的转发日志

公开路由采集器使历史问责成为可能。RouteViews 存档参与节点的 BGP 更新和路由信息库。其 2004 年 12 月更新归档保存了研究者可用于重建 TTNet 事件变化的数据。[9] RIPE 的路由信息服务提供了另一个分布式测量面，并说明采集器可观测与不可观测内容。[10]

一条更新记录表明某条路由公告或撤销通过特定会话到达采集器。该记录可保留前缀、AS 路径、来源 AS、属性与时间。通过对比观测，研究者可估计异常路径何时出现、传播多广、何时出现撤销或替代路径。

这是一种有力证据，但也有限。

第一，采集器可见性是部分的。某条路由可能到达了未向采集器供给的网络。另一条路由在到达任何公开观测点前就被过滤。采集端点可能只导出其最佳路径，而非所有学习到的路径。由此公共记录会不完整。

第二，控制平面可见性不等于数据平面转发。路由器可以收到更新却不安装。路由可进路由表却未进转发表。流量可能沿该路径转发，但在路径后段遭遇拥塞或黑洞。反过来，缓存会话和路径多样性可能使部分服务在控制面不稳定时仍可达。

第三，时间戳仅反映观测。一个归档中的第一条更新不一定是全网第一条异常公告。某采集器的最后一次撤销也不一定意味着陈旧状态在全网结束。收敛是分布式的。

第四，前缀计数依赖定义。分析者必须决定是否计入唯一前缀、更新消息、路径、起源或路由变更；必须定义事件区间并处理重复公告。不同合理方法会产生不同结果。

因此问责性分析应避免“整个互联网正好下线 X 分钟”这类表述，除非有证据支撑该范围。更稳妥也更准确的命题是：AS9121 产生了异常规模路由异常；该异常被大范围传播；公开测量显示控制平面发生了变化；并且可达性遭到实质性破坏。

证据缺口表明完整事故资料应包含什么。公开 BGP 数据应与原始网络的配置差异、策略生成日志、发布记录、告警时间线、会话状态、撤销指令、NOC 工单和对等通信配对使用。直接邻居应保留其接收的路由、应用的过滤、发生的最大前缀事件，以及会话为何保持开启或被重置的原因。

缺少这些私有记录时，外部调查可重建影响，但不能将每一项内部动作都归因。这应被呈现为证据边界，而非以猜测填补。

“泄漏”比“劫持”更精确

公共讨论中，路由事故常被称为“劫持”，因为流量跟随错误网络路径。该术语在故意冒名或伪起源事件中有用，但也可能暗示证据未支持的意图。

TTNet 记录更支持“路由泄漏”这一主项。路由超出了预期关系范围。该事件与严重策略或配置错误一致，不需要断言 TTNet 试图冒充所有受影响前缀的所有者或故意截获流量。

术语差异在技术上很关键。路由起源劫持通常指某自治系统通告了其未被授权的前缀。路径策略泄漏可以保留合法起源，但经过一个不应承载该路由的关系链路。部分事件会同时包含二者，公开记录也可能存在歧义。

路由来源验证回答的是：在路由源授权下，当前前缀是否允许该 ASN 通告。RFC 6811 定义了路由器如何使用 RPKI 数据对路由进行分类。[15] 它不能编码每一对客户-提供商关系，也不能单独判断合法起源的路由是否经过了违规关系路径。

关系感知机制则回答：给定当前学习路径，是否应在该会话上导出或接收该路由？RFC 9234 将 BGP Roles 和 Only-to-Customer 属性用于一类泄漏预防与检测机制。[14] 客户锥或 ASPA 式方法从另一角度处理路径授权。

把每个事件都称作“劫持”会导致修复不完整。运营方可能生成 ROA，看到泄漏路由仍是合法起源，于是认为问题已解决；但这并不成立。起源授权、关系授权、容量约束和变更安全性是不同控制。

意图仍影响法律与纪律结论，但并非运营遏制所必需。无论是误操作、自动化被入侵、恶意行为还是理解偏差，都应拒绝未经授权的路由集合。监测应警报一个客户导出接近全球表规模的异常，而不是先追问动机。

这种以证据为先的术语是现实层的一部分。它描述网络宣布、接收并传播什么，不会把关于动机的推断当成事实。

客户前缀授权应可执行

最直接的控制经验是：客户的预期公告集合应表示为可执行策略。

如果客户被授权公告一组明确前缀，提供商可创建入向过滤器，只允许这些前缀其余拒绝。真值来源可包括合同记录、路由注册表、RPKI 起源授权、客户直接确认、历史路由观测与人工例外。每个来源都有边界，但最终结果必须落到明确的路由器决策上。

允许列表优于大范围拒绝列表。拒绝列表往往只枚举显然不可能的路由（如默认路由或保留空间），其余巨大未列集合仍被接受。允许列表从客户应原始起源或中转的路由出发，将新增扩展作为受控变更处理。

生成的过滤必须经过测试。正确外观的注册对象仍可能导致错误配置。自动化链路可能合并了错误客户、遗漏前缀、接受过宽聚合，或在数据不可用时降级为放行。测试应对比预期资源、生成策略与一组代表性的被接收/被拒绝公告。

例外需要负责人和过期机制。客户可能在迁移时需要通告新前缀，为附属机构提供中转，或故障时聚合发布。例外应明确批准人、证据、受影响会话、前缀与路径范围、开始时间、复审时间和回滚条件。长期“临时”例外会造成隐含风险转移。

TTNet 事件说明规模本身也是授权信号。一个按预期应通告有限集合的网络，不应在未触发多重控制时突然导出接近全球表的前缀。即便前缀列表陈旧或不完整，路由量级变化仍应被视作异常。

客户前缀授权也有反向维度。客户应验证其自身导出内容。客户应在变更前冻结预期路由集合，检查生成输出，并将实际外发与该集合对比。提供商应独立校验其接收内容。此类控制不是冗余，而是降低共模故障的手段。

书面预期不会自动生效。IRR 对象、合同、表格和工单是问责记录；路由器实现边界。实操检验在于未授权路由是否能在安全验证演练中被拒绝，并且该拒绝对运营方双向可见。

AS 路径检查与关系策略覆盖不同证据

前缀授权回答该路由是否覆盖预期目的地。AS 路径检查回答该路径在关系上是否合理。

客户可能合法为下游网络提供转接。如果只用以客户自身起源 ASN 为条件的前缀过滤，就会误拦合法服务。提供商需要客户锥或其他表示客户可承载哪些起源与路径的机制。

路径表示很难稳定。AS 关系会变化。并购、转售、区域代理、路由服务器、联邦和复杂会话都不适合简单分类。公开关系推断有用但并不完美。私有商业记录更精确，但常来不及进入路由运营链路。

这种复杂性不应成为接受所有路径的理由，而应促使对不确定性分类、边界收紧和偏差监测。提供商可以结合客户声明、注册表证据、观察到的稳定路径、RPKI 起源数据与人工复核。可以拒绝包含自身 ASN 在异常位置、保留 ASN、异常长度，或明显未授权起源的路径。

RFC 9234 的 BGP Roles 使两端会话关系显式化，并定义提供商、客户、对等、路由服务器与路由服务器客户端的传播规则。[14] OTC 属性可标记应仅向客户继续传播的路由。该机制帮助防止并检测违反关系规则的泄漏。

但 BGP Roles 并非穷尽所有商业关系的完整模型。该 RFC 承认关系复杂，也警告错误的角色配置会影响传播。课程不是“启用某单一特性”，而是“将关系结构变为可机读、尽可能与邻居确认、测试结果并监测运行中的路由状态”。

对于 2004 事件，这些机制是回溯性对比。更持久的结论是：关系策略确实关键，但太多执行依赖未能阻断异常的导出与接收链条。

最大前缀限制提供容量断路器

最大前缀限制为 BGP 会话可贡献的路由数量设定上限。若超出阈值，路由器可告警、拒绝新增路由或按实现与策略关闭会话。

面对超过 100,000 个意外前缀的事件，合适的阈值可形成明显遏制。通常通告较小集合的客户，不应在未越过阈值前扩展到接近全网规模。

该控制在概念上简单，但部署上精细。

阈值设得过低，合法增长或去聚合事件会重置会话导致故障；设得过高则流于装饰。自动重启会话而不修复路由源会导致抖动。只告警而无明确响应责任，告警将变成噪声。

阈值应基于预期路由量、增长幅度、运营波动和故障代价来设定。应设置告警与硬动作两个层级。例外应有文档并限定时间。响应应明确是否保持会话下线、仅允许授权子集、或与客户协调纠错。

最大前缀本身不证明授权。客户可在阈值内泄漏一个小但有害的集合：一个关键更细分前缀、一个缺省路由，或规模看似正常但属于他人组织的路由组。该限制是断路器，不是替代前缀与路径验证的方案。

该事件展示了独立控制的价值。若前缀允许列表失效，容量限制仍可遏制大规模泄漏；若两者都失效，异常检测可将当前路由与客户基线对比；若监测失效，外部路由告警和对等报告仍可触发响应。

可问责运营方应可报告：多少外部会话配置了告警与硬限制、阈值如何复查、哪些会话有例外、触发频率与频次，以及演练是否证明该控制同时保护路由安全与业务连续性。

明确的导入与导出策略减少含糊默认

RFC 8212 将 eBGP 会话的预期默认行为改为：未明确配置策略时，不应导入或导出路由。[13] 该标准针对反复出现的一类故障，即缺失策略导致大规模传播。

该原则超出供应商默认值。每个外部会话都应有明确的入向与出向意图。运营方应知道：若某条路由映射缺失、生成失败、引用空对象或维护时被拆离，会发生何种行为。

在可用性压力下，失效开放行为很吸引人。注册表源不可用时，接收全部路由可维持会话；策略生成报错时，保留上一个配置可能不再同步；拒绝全部路由则可能中断服务。不存在普适答案。

问责要求是有意选择并测试故障模式。运营方可保留最近一次已知良好策略，仅阻断新增扩展；可要求手工批准；也可切换流量路径。应避免在事故中才发现缺失对象默默把“允许这些路由”变成“允许全部”。

导出策略同样必须同等重视。一个网络可能校验客户入向，但误将提供商或对等路由向另一关系转告。它可能加错社区、遗漏无导出控制，或将路由映射方向用反。生成的外发路由集合应在部署前与关系意图对比。

TTNet 事件是政策系统的有效测试用例。把一组完整表或异常客户路由集放入实验会话，验证：客户自身导出控制是否拒绝该集合、提供商入向控制是否拒绝该集合、最大前缀是否容纳、监测是否捕获剩余路由。

该测试关注行为本身。口头声明“客户路由被过滤”并不等于当前生成配置确实拦截该类事件。

RPKI 改善起源证据，但不编码每类泄漏

RPKI 允许资源持有者创建可加密校验的路由来源授权（ROA）。可靠路由器可将 BGP 路由的前缀与来源 ASN 与有效 ROA 对比，在相关语义下将路由归类为 Valid、Invalid 或 NotFound。RFC 6811 定义了前缀来源验证。[15]

这比未经认证的起源声明有明显改进。如果泄漏公告显示的起源 ASN 未获资源持有者授权，路由来源验证可在本地策略下识别并拒绝。

但关系路径泄漏可保留合法起源。假设客户从一个提供商获取了合法路由，随后将其泄漏给另一提供商，起源 ASN 仍合法；该路由可能是起源有效的，但传播却违背关系边界。RPKI 起源验证本身并不完整表达这种“谷底关系”问题。

这对 TTNet 非常关键。公开摘要在受影响路由的起源与路径结构表述上并不完全一致。在未对当期授权进行实际测试前，不能声称 RPKI 会自动拦截所有公告；而当时的现代形式授权机制也并未同时存在。

NIST SP 800-189 提倡分层的域间路由保护，包括基于 RPKI 的起源验证和前缀过滤。[18] 这一更广框架说明：弹性路由需要多机制，因为起源安全、路径策略、伪装、拒绝服务响应和运行监测是不同问题。

RPKI 也带来运营责任。运营方需要验证缓存多样性、更新新鲜度监测、仓库失败时的安全行为、Invalid 与 NotFound 路由策略、例外治理，以及实际执行指标。仅创建 ROA 而不启用路由起源验证，会使证据停留在转发决策之外。

在此可看到 Heng.lu 原则：注册记录是台账。它们能建立授权证据并支持问责；并非对路由器的主权指令。执行策略才决定证据是否影响可达性。

监测必须将运行路由与预期路由比较

TTNet 泄漏之所以可见，是因为路由状态变化幅度非常大。成熟监测体系应识别该变化的多个维度。

容量监测关注某会话发布、撤销和保留多少前缀。若从受控基线跃升到接近全网比例，应视为重大事件。

来源监测关注预期前缀是否出现起源 ASN 变化，或客户是否开始通告其无权管理的地址空间。RPKI 与注册表数据可支持该对比。

路径监测关注客户、提供商、对等关系是否出现异常顺序。它可识别谷底式传播、环路、突降路径长度或本自治系统 ASN 处于异常位置。

粒度监测关注是否出现意外更细分前缀。即使总路由数仍在阈值内，少量更细粒度前缀也可能吸引大量流量。

地理与拓扑监测对比多个采集点的观测。仅在一地区出现的路由可能是局部策略问题；跨独立上游传播则表明范围更广。

变更关联应连接路由异常与部署、维护窗口、配置提交和自动化作业。若全局路由激增发生在策略下发后数秒，系统应立即标记候选变更，而无需让运营人员在无关系统里检索。

监测应产出可行动证据。告警需要责任人、严重程度、受影响会话、观测到的路由增量、预期基线、建议遏制和升级路径。应保留触发告警的路由样本。

告警本身不是遏制。网络可在检测到泄漏后仍在关键分钟内确认谁可以重置会话、恢复哪个路由映射、如何联系对等体，以及回滚是否会扩大中断。演练应测试完整运营链路。

公开监测提供独立层。客户和关键业务运营方可从外部视角观察自身前缀和起源。提供商可将内网视角与 RouteViews、RIPE RIS 或商业源进行对比。独立证据有助于检测内部遥测缺陷，并确认撤销是否已传播。

AS9121、提供商、对等体与导入方的责任分配

问责应基于控制、证据与职责。

AS9121 对其导出的路由集合拥有第一责任。其运营复盘应识别触发点、预期策略、生成配置、审批路径、部署路径、检测时间、遏制动作、撤销流程与修复演练。若某个客户或下游路由源触发了表异常，复盘应区分该触发与 AS9121 对接收与导出的责任。

直接上游提供商和对等体控制第一层外部遏制边界。它们应展示 AS9121 会话的关系定义、预期前缀与路径集合、最大前缀策略、例外记录、告警以及后续导出策略。若它们接收了异常规模的路由，应说明哪项控制失败、缺失或被覆盖。

进一步的传输网络和对等方控制后续边界。它们的责任取决于学到何物、来源是谁，以及该关系下何种策略是合理的。下游客户从提供商接收完整表与提供商从小客户接收完整表并不相同。

路由采集器运营方控制的是测量而非传播。其职责是记录可见点、时间戳、保留策略和方法限制。研究者应在许可和隐私允许下保持变换可复现。

关键服务运营方负责事件中恢复韧性。多宿主、供应商多样化、外部路由监测、异步通信和故障切换可降低影响，但这些运营方不控制泄漏源，也不应承受本应归于域间策略边界的全部责任。

终端用户对 BGP 控制几乎没有控制权。用户只会看到慢速连接、黑洞或服务失效。其报告可帮助检测影响，但不能验证 AS 路径或下发撤销。

该分层模型避免了两类错误。第一类是将全部责任归给源网络并将提供商视为被动通道。第二类是责任过度分散，以致无控制主体被追责。每个网络应对其实际运行的边界负责。

恢复是路由状态转移，而非宣告

停止触发源是必要条件，但不足以完成恢复。BGP 是分布式的，路由状态需时收敛。

源网络可修正策略、撤销路由、重置会话或断开来源。直接邻居必须处理撤销或会话丢失，选择备选路径并导出变化。其邻居重复该过程。路由抖动、陈旧路由机制、会话状态、计时器行为和本地策略会影响时间线。

“配置已修复”之类的运营声明标记了内部动作，但不能证明全球路由状态已清洁。

可问责恢复记录应回答：

AS9121 何时停止导出异常路由集合？
哪些会话被重置、过滤或保持降级？
何时直接邻居观察到撤销或替代？
每个独立采集点在各时点仍有多少异常前缀？
合法路径是否恢复，且是否在数据平面可实际使用？
主要修复后是否仍可见陈旧路径或二次泄漏？
何时跨区域与接入网络的关键服务恢复？
哪些对等方需要直接协同，而非依赖自动收敛？

路由归档可帮助回答部分问题。私有会话日志和路由快照可回答更多问题。数据平面探测可区分路由表归一化与实际可达性的差异。

恢复证据还应保留不确定性。如果某采集点在 10:00 已归一化，另一个在 10:07 才归一化，报告不应编造单一全球恢复秒数，应报告收敛区间并说明观测点。

最后一步是安全复现。运营方应在实验室或受控验证环境复现该失败类型。挑选代表性客户尝试宣告异常的大规模且未授权路由集合。测试应展示哪一层拒绝、哪些告警触发、由谁响应，以及证据如何被保留。

没有这类演练，策略变更仅是承诺而非验证。

现代控制体系是分层的

任何单一控制都不能解决所有路由泄漏，且应设计为彼此独立失效。

明确的会话策略：导入与导出行为应明确，对缺失或失效的策略对象有安全处理。RFC 8212 提供了有用的默认方向。[13]

授权前缀过滤：直接客户应限制在其被授权起源或可中转的前缀集合内，并基于维护中的证据与受控例外。

AS 路径与客户锥约束：提供商应评估路径在关系上的合理性，而不仅仅是起源是否有效。

最大前缀限制：会话级阈值应提前预警并在表级泄漏传播前进行封堵。

路由起源验证：路由器应在运营策略下使用已验证的起源证据，处理 Invalid、NotFound、缓存失效与例外治理。[15]

BGP Roles 与 OTC：在适用场景下，双向确认的角色定义和 Only-to-Customer 处理可编码并执行关系预期。[14]

生成策略测试：自动化应比较预期资源、生成配置与仿真公告，并在部署前执行。

变更安全：高风险路由变更应采用分段发布、复核、可用时的金丝雀、自动停止条件与经过测试的回滚。

独立监测：内部与外部视图应能检测容量、起源、路径与细粒度异常，并与近期变更关联。

事件协同：运营方需要有效联系人、异步通道、预授权遏制动作，以及共享受影响前缀与撤销证据的模板。

恢复验证：应有多点控制平面和数据平面视角确认归一化。

这些控制应可量化。可用指标包括：带有生成型允许列表的客户会话占比、硬性前缀上限、已生效起源策略、外部监测覆盖、当前关系分类完整率、最近一次泄漏演练和例外老化时间等。

MANRS 将过滤、协同、反伪装和全球验证视为运营者行动框架。[17] NIST SP 800-189 也强调路由安全是互补措施组合，而非单设备解法。[18] 这些框架的价值在于运营采纳与可验证性。

注册表证据与运行代码优先

TTNet 事件直接落在 Heng.lu 问责面：BGP 路由、ASN 与 IP 注册表证据，以及对等/中转关系。

ASN 记录可识别 AS9121。地址注册表可识别分配与受让人。路由注册表可发布路由对象和策略。RPKI 可提供签名的起源授权。这些记录减少歧义并形成证据链。

它们不直接转发数据包。

运行中的路由器根据加载配置和会话状态接受并传播路由集合。若运行策略忽略、误解或未检索注册证据，那么书面记录并未真正约束网络。

这就是为何应将注册表视为账本或记录者，而非主权机构。其合法性来自准确、唯一、安全、可转移且可用于运营决策的记录本身；执行仍是运营者职责。

运行代码优先并不否认治理。它使治理可被测试。董事会可以要求授权资源记录，但也应要求这些记录转化为过滤与路由决策。审计员可检查一个 IRR 对象，但还应追踪该对象通过策略生成器落到某台路由器，再测试冲突公告。

现实层驳斥两种极端立场。其一是“去中心化因此无人问责”；其二是“一个中央注册表可命令网络走向正确”。两者都不符合系统现实。

互联网是由独立运营系统通过协议会话与协议约定连接而成的网络。问责来自准确证据、清晰边界、可执行策略、独立校验和可验证恢复。

若从文章中去掉 BGP 导出、AS9121、前缀授权、关系策略、采集器与撤销机制，就会破坏论点。网络控制面并非点缀，它就是主体。

可信修复记录应包含什么

可信的 TTNet 级修复包应足够具体，以便其他运营方或审计方复核控制主张。

它应从事故时间线起步，区分首次内部触发、首次外部异常路由、首次告警、诊断、遏制、撤销、部分收敛和可验证恢复。每个时间戳应标明来源和时间标准。

它应包含相关会话的预期入向与出向策略、事故前的实际配置、产生泄漏的变更或故障、及修正后配置。敏感值可脱敏，但应保留逻辑。

它应冻结预期客户前缀与路径集合，说明源记录，列出例外，并展示生成的过滤。应记录最大前缀告警与硬性阈值。

它应包含来自内部监测、直接对等方、RouteViews 与 RIPE RIS 的代表性 BGP 更新。并说明采集器限制和计数方法。

它应说明原始控制为何失效：过滤缺失、数据陈旧、会话角色错误、生成失败、策略顺序错误、过宽例外、失效开放行为、告警无人值守，或其他有证据的原因。

它应记录遏制决策与对等协调。若会话被重置，应说明原因；若有选择性拒绝，应说明匹配条件。

它应按观测点提供撤销与收敛图，并提供关键目的地的数据平面检查。

它应报告修复归属、到期日期、完成证据与残余风险。只写“已更新流程”不够。

最后，应包括受控复现：展示在受控环境下，完整表或异常客户导出在多层被拒，且事件能在不扩散到生产对等体的前提下触发运营警报。

该包不能让互联网变得零风险，但能使运营方的控制主张可被证伪。

治理问题应围绕路由展开

高管、监管者、审计方和服务采购方可提出有效问题，而不必假装自己配置路由器。

董事会应询问可改变公开 BGP 公告的变更数量、多少客户会话缺少当前允许列表或硬性前缀限制、例外如何批准、最后一次泄漏演练发生时间。

过境提供商应询问关系记录是否是最新的、导入与导出策略是否明确、生成过滤是否有安全失败处理，以及异常路由是否在再次传播前被隔离。

企业采购方应询问提供商路径是否拓扑独立、关键前缀是否有外部监测，以及提供商事故报告是否包含路由状态证据。

审计员应抽查实时配置与生成策略，追踪资源证据是否进入路由决策，并测试反例。仅凭策略门户截图不能证明执行。

监管者应避免单一控制法规，将部署和结果混淆。要求 ROA 可以改善起源证据，但路由泄漏问责还需关系策略、过滤、监测、协同与恢复演练。

事故复盘不应止于“人为失误”。该术语解释不了为何某个错误会导出异常规模表集合、为何直接邻居会接收、为何既有保障未限制传播、为何恢复所用时间如此。

指标应反映覆盖率与例外，而非形式化数字。网络可能报告 99% 的过滤覆盖率，但仍有一个高流量客户未设限制；风险取决于暴露边界，而非平均值。

治理还应维护真实不确定性。运营方应披露无法重建的路由状态部分、未留存的数据、未测试的反事实控制。

问责测试是有界传播与验证撤销

2004 年 12 月 24 日的 TTNet 事件仍具现实意义，因为它暴露了一个控制缺口：当 BGP 关系没有明示、过滤过宽、且路由证据未与运行策略联通时，问题会持续存在。

AS9121 导出了异常规模的路由集合。其他自治系统接收并再分发了足够多的路由，将局部策略失效转化为分布式可达性事件。公开路由采集器保留了部分控制平面记录，后续分析使该事件成为泄漏检测的基准。

公开证据并未支持恶意意图说法、一个精确的全网前缀总数，或完整重建每个运营决策。这些限制应保持可见。

责任是分层的。导出网络控制其路由生成与公告。直接提供商和对等体控制第一道外部接收边界。后续网络控制后续传播。监测运营方控制证据质量。服务运营方控制恢复韧性。终端用户承受影响，却不控制路由状态。

现代修复也应分层。授权前缀过滤、AS 路径约束、最大前缀限制、明确策略、RPKI 验证、BGP Roles、策略测试、独立监测、协同响应与恢复验证分别覆盖失败链条不同部分。

Heng.lu 原则给出最终区分。路由和资源注册表可说明谁应通告哪些资源、哪些关系被预期，且这些记录对问责至关重要。运行路由器仍决定可达性。

因此可信运营方应能证明三点。

第一，它要知道客户或对等方被授权通告什么。

第二，其运行系统能在其中一项策略源或自动化组件故障时，仍拒绝或遏制超出范围的公告。

第三，若不良状态外溢，能快速撤销，并从独立视角证明互联网上恢复到授权路由状态。

这就是 2004 年 TTNet 泄漏揭示的客户前缀过滤问责测试。该标准不是完美防护，而是有界传播、清晰责任、留痕证据与可验证恢复。

TTNet 的 2004 年路由泄漏将客户前缀过滤变成问责测试

为何重要

摘要