1997 AS7007 泄露：路由过滤如何成为互联网问责测试

摘要

冻结事件边界：本文审视了 1997 年 4 月 25 日由 AS7007 发起的路由及其引发的可达性中断。它并未将该事件与后续路由泄露、恶意劫持或同名交换点中的无关故障混为一体。同期的 NANOG 记录显示，运营商观察到其本应源自其他来源的地址空间，以更具体前缀的形式出现，并标记为 AS7007 来源。[3][4]
有边界的技术重建：后续的 APNIC 说明文档描述了无类 eBGP 路由进入一个系统后被重分发到 RIPv1，丢失前缀长度信息，并返回 BGP 后重写来源信息。[1] 这是一个强解释性重建，但不能据此推导出单一的内部命令序列。
为何这些路由会生效：互联网转发遵循最长前缀匹配。更具体路由可在许多 BGP 路径属性比较之前吸引流量。由此导致泄露路由在运行状态上压过资源归属预期和来源声明。
责任随控制而在：AS7007 控制了重分发、导出策略、变更校验、监测与撤回。其上游提供商控制了客户过滤、前缀上限与传播策略。导入对等体控制了自己的接受策略和应急响应。最终用户可上报故障，但不能修复跨域路由状态。
注册表证据并非执法：ASN、地址注册库、IRR 以及后续 RPKI 记录可保存资源持有者与授权来源的证据。路由器仍依据加载到运行系统中的路由和策略执行转发表决策。该事件因此清楚体现了“运行代码优先”：书面权威只有在被运行策略执行时才生效。
现代控制是分层的：来源校验、显式导入/导出策略、BGP Roles、客户锥过滤、前缀上限、独立监测以及经过验证的回滚流程可覆盖不同失效路径。任何单一机制都不应被描述为普适的事后“万能解”。
恢复必须可证明：切断或纠正起始路由器并不等于责任结束。运营商需要提供撤回证据、陈旧路由清理、路由表归一化、对等体协同和来自多个观测点的恢复性转发结果。

事件边界是 1997 年 4 月 25 日

有约束力的技术史研究始于先冻结事件边界。1997 年 4 月 25 日，互联网运营商报告了一个异常的大量更具体路由集合与 AS7007 相关，该 AS 由 MAI Network Services 运营。当天的 NANOG 消息提供了当时运营者所见现象的实时证据：预期由其他来源起源的地址块，以更小前缀被 AS7007 宣布，而流量也跟随这些通告走入无法正确递送的路径。[3][4]

该事件后续常被称为“AS7007 incident”或早期重大互联网路由泄露。该标签仅在与证据一一对应时才有意义，不应成为当时所有路由错误的代名词，也不应被解释为带有恶意。现有最强公开记录支持这是一起意外传播故障，具有严重影响。它并未支持“AS7007 意图拦截流量”或“有意声明所有受影响地址空间所有权”的结论。

后续技术史通常提到约 6,000 条/24 公告，以及约两小时的急剧中断。APNIC 的回溯给出了约 6,000 条/24 公告的估算，并重建了有类路由行为如何将一个更大外部表转换为更具体前缀。[1] Secure Routing 的事件目录同样将该事件记录为一个里程碑式路由失效。[2] 这些后续来源有助于组织历史脉络，但当时运营者消息仍然关键，因为它们显示的是事件发生时可见的外部路由状态。

公告数、每个位置可见的准确起止时间，以及完整的内部配置并未由单一公开文档固定。BGP 视图具有观测点差异：某一前缀可能先在某个对等点出现，又在另一个点撤回后仍残留，或被某个网络的过滤器抑制。可辩护的记述应保留数量级估计，并避免将单一采集器视图当作统一时钟。

佛罗里达互联网交换点的作用也需要谨慎界定。后续叙事有时会将事件与交换基础设施关联，或把交换点名称当作事件地点标签。此处审查的公开证据不足以支持将全部故障直接归因于该交换点。责任论证落点在于路由变换、出口策略、对等接收和恢复机制，并不需要无依据地增加“某一设施拥有该事件”的论断。

这类边界划分很关键，因为诊断决定了修复方向。如果错误地将事件定性为蓄意劫持，响应会集中在凭证与恶意来源检测；若将其仅看作一般故障，响应可能只关注可用性。证据所指向的是一次路由策略变换越过内部边界并被外部边界接受的过程。

无类 BGP 遇见有类内部协议

该技术机制足够特殊，必须谨慎解释。BGP 在自治系统之间传递网络层可达性信息。现代 BGP 路由包含前缀与前缀长度，如/16 或/24，并带有供运营者在选路与导出策略中使用的路径属性。RFC 4271 描述了基础协议与决策流程。[8]

RIPv1 设计于更早的有类模型，不在路由通告中携带子网掩码。按有类解释时，地址可依据历史网络类别进行处理，而非 BGP 无类路由里的显式前缀长度。当路由在不同信息模型的协议间流转时，重分发并非中性复制，而是一次语义转换。

APNIC 的重建将通过无类 eBGP 学习到的路由重分发到 RIPv1 说明了这一点。由于 RIPv1 不能保留原始无类前缀长度，这些路由被表征为会导致去聚合的形式。当这些路由再次重分发回 BGP 时，最终公告表现为大量更具体前缀，且原始 AS 路径历史信息不再被完整保留。[1]

该重建同步解释了两点：第一，为什么会出现大量/24 公告。更少数量的更宽前缀在语义转换后可形成更多窄前缀。第二，为什么 AS7007 会被看作其他网络地址空间的来源。若外部路径信息在重分发中丢失并重新引入 BGP，重引入的自治系统就可能变成可见来源。

公共记录并未披露每个软件版本、路由器对象、重分发命令、路由映射或管理动作。把该重建硬塞成一条编造的终端命令串，会是不可负责任的做法。证据支持的是一类机制：信息在协议边界之间丢失或被转换，转换后的路由又被导出到域间 BGP。

这一点对责任判断尤其重要。事后复盘不应止于“RIP 过时”或“重分发危险”。它应追问：是谁授权了协议边界、哪些属性预期保留、测试了哪些路由集合、哪些导出不变量应当拦截该结果，以及当路由规模与来源变化时应触发何种告警。

协议翻译是持续的基础设施风险。两种协议均可按各自设计正常运行，但组合后可能违背系统意图。一条在一套表示内有效的路由，导入另一套表示后可能发生实质差异。控制方必须验证转换输出，而不仅是验证两端语法。

更具体路由将错误信息转化为转发现实

BGP 路径选择很重要，但转发优先级先于路径属性比较。路由器按转发表里的最长匹配前缀转发。/24 路由匹配的地址范围比覆盖它的/16 更窄。两者并存时，属于/24 范围的流量会走/24 路径，即使覆盖路由仍可用。

该特性有利于流量工程与多归属接入，也使偶发去聚合具备放大效应。如果 AS7007 宣告了数千条更具体路由，这些路由会吸走流量，偏离合法的覆盖路由。网络无需“法律上”认定 AS7007 所有这些地址；只要足够多的路由器接受并安装了这些更具体路径，结果即成。

所有权与可达性之间的区分是核心。地址注册库可记录谁被分配了某网段，路由注册库可记录预期策略，RPKI 可让持有人为前缀授权来源 ASN。以上记录并不会直接改变转发表。运行网络遵循的是在策略配置下被接受的路由。

事件期间，运营者报告了自己的网络路径显示 AS7007 为来源。[3][4] 如果流量沿这些更具体路由前往其无法正确递送的网络，就会形成大规模黑洞。一些路径可能表现不同，原因在于网络应用了过滤、偏好其他路径，或尚未收到通告。该差异并不削弱机制本身；反而表明影响范围取决于分布式策略。

在本案例中，“泄露”相比“劫持”更准确。RFC 7908 后来给出了泄露的分类，定义为超出预期范围传播。[9]1997 年的事件早于该标准，且其异常去聚合不必被硬塞进单一现代类别，责任结论本身仍可成立：路由越界、转发声明误导、传播范围足以破坏可达性。

安全讨论有时会把任何来源错误的路由视为攻击证据。该推断在此不成立。运营控制应检测有害路由状态，而不必先认定操作员是疏忽、已入侵或恶意。前缀上限告警、授权来源校验或导出集合对比都不必预先判定动机即可阻断公告。

这也是路由证据有价值之处。它允许调查者在不推测动机的情况下，描述网络声明了什么、接受了什么。责任由控制这些声明与接受决策的系统与组织承担。

责任分布明确，但并非无人负责

域间路由是去中心化的。这并不意味着责任消失，而意味着责任应分配给各组织可实际执行的控制点。

AS7007 控制了内部重分发边界。它控制外部 BGP 路由是否进入内部协议、属性和前缀语义是否保留、转换后的路由是否能返回 BGP、以及哪些公告被导出至上游。它还控制变更审批、部署、监测、回滚与事故沟通。

接受 AS7007 路由的上游提供商控制另一条边界。它们可维护客户前缀白名单、拒绝非授权来源、限制前缀数、限制可接受的更具体粒度，或对异常通告设置例外。它们也控制已接受路由是否继续导出给对等体和下游客户。

导入对等体与下游网络控制自身策略。部分网络可能有过滤器涵盖了事件的一部分，另一部分可能仍对上游关系默认信任。它们的责任不同于起源方，因为其未构造转换后的路由，但路由接收本身仍是一个可操作的决策行为。

关键服务和企业网络运营方控制其路由系统周边的韧性。它们可监测外部路由状态、使用多运营商接入、保留带外沟通渠道，并测试所谓路径多样性是否共享同一上游依赖。该类控制能减轻影响或提升检测速度，但不能直接在源头修正全局路由集合。

最终用户和普通客户几乎没有实质控制权。他们可以重试、在存在替代的情况下切换接入网络，或提交故障报告；却无法检查每条 BGP 路径、修改供应商过滤或强制路由撤回。仅以无法绕行为由责怪用户，会把暴露与责任混为一谈。

控制分层后可得出以下结论：

起源网络的首要职责是阻止内部转换变成外部声明。
直接上游有强约束职责，因为其知晓客户关系并可定义预期路由。
其他网络有维持可辩护导入策略并监测异常的一般职责。
服务运营方有保持连续性的职责，需理解路由依赖并检测外部故障。
公开证据提供者承担观察角色，而非生产控制角色。

此模型避免两个极端：把所有后果都推给可能仅执行改动的一名工程师，也避免因“互联网过度去中心化”而否定问责可能。关键问题始终是实际控制力：谁能预防、限制、检测、撤回或验证？

出口建模应测试生成路由集合

写在制度里的“不得发布他人前缀”规则不足够。系统需要可机检的预期导出集合模型，并与配置实际生成的路由集合比对。

对于客户网或边缘网络，出口模型可定义：

网络被授权并预期起源的前缀；
正常与应急状态下的最大路由条目数；
允许的前缀长度范围；
可向每个关系类型通告的路由；
客户、对等体与上游学到路由是否可重导出；
预期的 AS 路径和 community；
例外项、审批人以及到期时间。

生成配置应在部署前进行测试。测试不应只确认某个 route-map 存在，而应将代表性路由输入策略并检查输出公告。若无类路由跨越有类或有损表示，应比较转换前后的前缀数、前缀长度、来源和路径。

AS7007 事件展示了一个高价值不变量：路由进程不应导出未明确授权的外部前缀更具体路由。另一不变量可约束生成与预期集合之间的差异上限。若从普通客户发布集合跳到数千条/24 路由，应在部署前终止发布，即使每条路由在语法上看似合法。

前缀上限是第二道防线。上游可配置每个客户可接受的前缀条目上限。合适阈值应保留运维冗余，但也要足够低以拦截重大泄露。阈值应按关系类型设置：转运提供商、内容网络与小型接入客户拥有不同的正常路由集合。

前缀上限并非充分条件。泄露可在更宽松上限下仍造成严重危害。客户可能发布正确数量路由，却发布了错误路由。故上限应与前缀与来源授权结合。

客户过滤可基于注册库、合同、IRR 和 RPKI 数据，但这些数据源有缺口。可辩护的系统应记录每条路由依据的来源、刷新时间和冲突处理方式。应急例外应显式、临时并可审计，而非隐藏绕过。

RFC 7454 提供了 BGP 运营安全实践的指导，涵盖过滤与前缀上限。[13] MANRS 将相关实践定义为运营者动作。[14] BITAG 与 NIST 亦描述了路由安全控制与部署现实。[15][16] 这些文档用于构建控制体系，不应替代在相关会话上“控制真正生效”的证据。

最有力的证据是测试记录：预期路由集合、生成路由集合、每个差异的策略处理、审批例外清单、验收金丝雀结果以及部署后的实时路由观测。

Heng.lu 原理区分记录与执行

AS7007 事件是 Heng.lu 原理的直接网络控制案例。资源必须保持唯一性、准确记录、转移历史、安全元数据与运营连续性。这些记录重要，但注册库是账本与记录者，非运行路由器的主权控制者。

ASN 记录可识别 AS7007。地址注册数据可识别出在 AS7007 名下的期望持有人。IRR 路由对象可描述预期来源策略。ROA 可授权某 ASN 起源某前缀。这些都属于证据层。

现实层是路由器接受并安装用于转发的路由。1997 年 4 月 25 日，运行真相并非只在注册库；关键是 AS7007 作为来源的更具体路由被接受并传播，流量随后跟随这些公告。

这并非否定记录。没有记录，运营商在构建过滤时缺乏可信依据，调查者在识别异常时也更难。关键在于，记录只有在被策略消费、例外可控且部署可验证时，才转化为运行中的保护。

“运行代码优先”同样适用于书面流程。流程可要求评审与前缀过滤；若生成配置绕过过滤，实际运行系统才决定结果。只检查流程的审计会把控制错误估计得比事故中发生的更强。

因此该原理可映射为三个实际要求：

准确账本：资源与策略记录必须识别预期前缀、来源与责任运营者。
执行政策：路由器与路由服务器必须把上述证据转换为导入与导出决策。
运营连续性：监测与回滚必须证明异常状态可清除，且可达性可恢复。

该文章不应将这些原则转向支持某一注册机构或产品。证据边界更窄：该事件证明了当路由策略接受了矛盾的运行状态时，资源唯一性与所有权记录并不自动阻止危害。

如果去掉 BGP 重分发、前缀粒度、AS 来源、对等过滤与撤回事实，文章的论点就会瓦解。由此可见，本文不是之后才添上网络术语的通用企业风险叙事，而是网络基础设施的问责分析。

RPKI、RFC 8212 与 BGP Roles 解决不同问题

现代路由安全讨论常问：RPKI 是否能防住旧事故。审慎回答是“有条件的”。

路由来源校验将观测到的前缀与来源 ASN 与 Route Origin Authorizations 进行比对。RFC 6811 定义了路由器使用的校验状态。[12] 若一个前缀拥有有效 ROA 授权给另一来源，AS7007 若宣布冲突更具体路由，可根据前缀覆盖与最大长度规则被判为无效。

因此，在充分覆盖且正确配置的 RPKI 环境中，许多 AS7007 型错误来源会更容易识别和拒绝，这是有意义的控制增强，但不能据此断言 1997 年所有路由都会被拒绝。

覆盖范围很关键。无覆盖 ROA 的路由不会因观测者怀疑而自动失效。最大长度设置也关键：覆盖授权可能使某一更具体路由失效，但过于宽泛的授权又可能允许有害的粒度。部署策略也重要，因为网络可能计算出校验状态却不拒绝无效路由。

来源校验也不能重建关系意图。即使来源被授权，路由仍可能从客户传播到提供商或对等体，违反预期导出策略。RFC 7908 定义了多个泄露场景，在这些场景中来源可合法，但传播不合法。[9]

RFC 8212 要求 eBGP 默认策略显式化。[10] 这降低了因“默认全部接受”造成的偶发传播，但并不保证显式策略本身正确。运营者可能配置了过宽放行策略、授权了不安全转换，或绑定了错误策略对象。

RFC 9234 引入 BGP Roles 与 OTC 属性，旨在基于关系角色识别并预防部分泄露。[11] 其作用是关系感知传播约束，不会替代来源授权、生成策略测试、前缀上限或回滚机制。

客户锥方法推断或维护客户及其下游预期路由集合。Peerlock 风格过滤约束涉及主要网络路径。研究表明，部分部署仍可提供有效保护，但也伴随边界和复杂性。[17]

分层结论是：

RPKI 与路由来源校验解决授权来源问题。
IRR 与注册库支持预期前缀和策略记录。
RFC 8212 要求显式策略。
BGP Roles 与 OTC 处理关系感知泄露预防。
客户锥与路径过滤约束传播。
前缀上限约束流量体量。
配置建模检测生成策略缺陷。
独立监测检测运行状态偏差。
回滚与协同用于恢复服务。

将单一控制当作完整解会产生新的问责缺口。运营者应说明每种控制覆盖的故障模式、数据缺失时的行为、例外如何复核，以及该控制如何通过故障场景测试。

恢复并未在起始路由器断开时结束

最具启发性的当时证据来自恢复阶段。NANOG 发布的一封道歉信提到，在起始路由器断开后仍然难以清除错误路由。[4] 这把“简单断电叙事”转化为分布式状态问题。

BGP 路由通过多个自治系统传播。当来源撤回路由或会话下线，邻居处理变更、更新选路并通告后续变化。计时器、路由抑制、会话状态、实现行为与本地策略都会影响表归一化速度。

原始源可停止发出错误路由，但旧信息仍可能在其他地方留存。某个对等体可能暂时保留路径，路由反射器处理节奏不同，或需重置会话以清除预期外状态。单点观测不能证明每台路由器都已收敛。

可问责的恢复记录应包含：

起源何时停止生成或导出错误路由；
各直接上游何时观察到撤回；
是否重置会话及其原因；
路由抑制或陈旧状态机制是否影响清理；
采集器何时停止看到错误来源；
合法来源与覆盖路由何时恢复到预期可见性；
何时对端点进行转发测试并达到预期；
何时主要对等体确认路由表已归一；
哪些路由仍异常及持续时长；
何人宣布服务恢复及依据。

该事件同样说明回滚计划需要路由状态验证。仅恢复先前配置不足以证明问题已止，因为错误路由可能仍保留在源外部。回滚清单应包含预期撤回、表对比和外部确认。

CAIDA 的 BGPStream 提供历史与实时路由数据供分析。[18] 路由采集器对独立确认有价值，但它们是样本。成熟恢复流程应结合内部 RIB/FIB、直接对等报告、公共采集器和转发探测。

恢复沟通应区分源端封堵与全局恢复。“路由器已断开”只是封堵事件；“所有受影响对等体已撤回”是传播里程碑；“独立观测点不再看到错误路由且转发恢复正常”才更接近恢复证据。

这种结构可避免过早收口，也能帮助组织区分其可直接控制的恢复部分与协同依赖的恢复部分。

公共路由证据强但不完整

1997 年路由事件的公共记录非常有价值，但依然有限。NANOG 消息提供了直接运营者观察与道歉。[3][4] 同期报道捕捉了中断规模与突发程度。[5] 后续技术论述解释了协议交互。[1][2][6] 标准与治理文件给出了可应用的控制方法。[8]-[17]

没有任何公开来源能揭示全部私网路由表、配置差分、工单、对等合同或决策日志。证据不能确定每一台设备何时接收每条路由，或精确受影响用户数量。也无法显示哪些过滤在静默生效、阻止了更大规模传播。

历史重建也面临术语漂移。1997 年运营者用当时可得语言和工具描述事件，后续文本则使用路由泄露、劫持、去聚合和来源校验等更晚出现的说法。审慎写法不能让 1997 年的运营者看似遵循或违反当时尚未制定的标准。

现代标准是当前控制设计的借鉴，而非对过去事件的追溯合规要求。RFC 4271 晚于该事件发布，但记录了成熟的 BGP-4 模型。RFC 7908、RFC 8212 与 RFC 9234 更晚出现。[8]-[11] 它们有助于解释失败类型和预防层，但不能证明 AS7007 或其上游在 1997 年有合约层面的部署要求。

证据支持以下高置信结论：

AS7007 为与其他网络相关的地址空间发出了大量更具体路由。
路由状态造成了显著可达性中断。
可得记录支持该事件为偶发事故。
内部到外部的重分发是后续技术重建的核心环节。
对等方接收与传播扩大了影响范围。
撤回与清理并非瞬时完成。

它同时支持若干中等置信度结论：

无类到有类的重分发合理解释了去聚合和重写来源。
直接上游过滤或前缀上限可限制大量路由集合的扩散。
更完善的出口建模可暴露预期与生成公告之间的大幅差异。

仍有重要未知：

确切的配置执行顺序；
完整的设备与软件拓扑；
每个直接对等体的完整过滤状态；
完整事件时间线；
决策归属与审批信息；
按网络与地域的全量影响；
事件后实施了哪些修复。

当这些置信度保持可见，问责能力更强。过度断言会让文章更容易受到质疑，也更难作为审计参考。

可验证的整改议程

公共记录并未界定 MAI Network Services 或每个上游后来实施了哪些控制。正确应对是定义可证明故障路径已受控的证据要求。

1. 固定预期导出集合

对每条 eBGP 会话保留版本化的预期导出集合。集合应包含前缀、最大粒度、来源、路径约束、关系类型与经过审批的例外，并基于权威记录与明确运维意图生成。

证据：仓库提交、审批记录、数据源时间戳、例外所有者与到期时间。

2. 测试协议转换

当路由在 BGP、IGP、静态路由系统或其他表示之间流动时，应测试前缀长度、来源、路径和策略属性是否按预期保留。除非结果路由集合明确受限，否则应拒绝有信息损失的转换。

证据：代表性输入路由、生成输出路由、不变量结果与负向测试。

3. 比较生成与预期公告

在部署前计算路由差异。若生成集合出现未授权前缀、意外更具体路由、来源变化或路由规模超过批准边界，应中止发布。

证据：部署前差异与停止条件结果。

4. 强化直接客户过滤

上游应按预期集合过滤客户路由，按关系设定前缀上限，并记录每条例外。注册库与 RPKI 可辅助集合构建，但未解决冲突时应安全失败或要求显式复核。

证据：实时策略挂载、测试通告接受与拒绝、刷新历史和例外清单。

5. 部署显式关系策略

每条 eBGP 会话都应有显式导入与导出策略。若支持，BGP Roles 及关系感知控制应与运营关系匹配。配置应在角色缺失或不一致时拒绝宽泛默认，而非静默接受。

证据：会话清单、角色映射、策略挂载与合规测试。

6. 从外部监控

从独立视角监控来源、粒度、路径、路由量与可达性。告警应将路由异常与转发探测关联，使响应可区分“公告变化”与“用户可见影响”。

证据：采集器查询、告警时间线、探测结果与事故联动记录。

7. 设置自动发布停止

当路由规模、异常来源、更多具体路由量、对等可见性或转发损伤超阈值时，部署应自动停止。该停止不应完全依赖人工观察公众投诉。

证据：金丝雀策略、阈值定义、触发条件与执行记录。

8. 执行撤回与清理

在实验室或隔离环境运行安全测试，验证异常路由可被撤回、会话收敛、陈旧状态可被识别，独立探测恢复到正常。测试应覆盖对等体沟通与带外接入。

证据：来源撤回、对等接收、表归一化与转发恢复的时间戳。

9. 保留事件证据

保留路由更新、配置差分、策略生成输入、审批记录、告警、命令与恢复核查。时间同步应使事件序列可审计。

证据：带哈希与访问控制的不变更包。

10. 按原始故障类型验证整改

切勿用“监测改进”一句泛化完成整改。应复现安全版本的无类到有类转换或等效未授权去聚合场景，展示当前控制链条如何阻断该类失败。

证据：测试设计、预期失败点、观察结果与独立复核。

该议程有意保持供应商中立，不要求使用特定厂商、注册机构或安全服务。它要求运营方证明预期策略准确、运行策略执行、异常可阻断、恢复可被独立验证。

治理问题应紧跟路由路径

董事会、监管机构、服务采购方与审计方并不必懂 BGP 也能提出有效问题。关键是沿着路由经过的控制链条追问。

董事会应关注哪些变更会改变公开公告、生成出口是否经过测试、谁可审批例外以及回滚速度。应收到演练结果，而非仅政策文本。

传输提供商应询问客户过滤是否基于当前证据、多少会话配置了前缀上限、哪些会话接受了宽泛例外及其是否到期。适用于多数客户的控制也可能在高风险会话上失守。

企业采购方应关注双提供商是否真正运营上独立，外部路由监测是否覆盖关键前缀，以及事故通告是否区分路由故障与应用故障。合同上的接入多样性不等于路径多样性。

审计方应抽查实际会话策略、生成路由集合与路由观测。其应将单条注册或 RPKI 记录追踪到路由决策，并测试数据缺失或冲突时系统行为。

监管方应避免把路由问责定义为单一技术部署要求。要求制作 ROA 确实可提升来源安全，但并不证明关系感知过滤、变更验证或恢复机制具备。应要求运营者按角色记录适配自身职责的控制，并测试其有效性。

事故复盘应分离根因、贡献条件、触发、发现、响应与恢复。“人为错误”不足以定义根因，它并未解释为何系统生成了成千上万意外路由，为什么上游接纳了这些路由，以及为何监测未阻断传播、清理为何持续困难。

治理目标不是让每次路由变更都零风险，而是确保具备实际控制力的组织能够证明其网络位点所产生风险被降低、被限制并可修复。

可观察执行才是问责测试

1997 年的 AS7007 事件之所以重要，是因为它将多项网络基础设施职责压缩到单次故障中。内部协议边界改变路由信息，转换输出越过外部策略边界，更具体路由改变了转发现实；多个网络接受并传播这些声明；恢复需要分布式的撤回与协同。

公共记录不足以支持恶意意图推断，也不支持一条未公开命令序列的唯一说法；但它足以支持一条强运营结论：预期的资源所有权与书面路由意图未能约束运行路由状态。

责任是分层的。AS7007 控制了转换与导出。直接上游控制客户接收与封堵。其他网络控制导入策略。服务运营方控制外部监测与韧性。最终用户承担后果，但未具备实质路由控制。

现代机制可改善控制环境，但前提是其边界要明确。RPKI 可帮助拒绝未授权来源；RFC 8212 可取消 eBGP 隐式默认接收；BGP Roles 与 OTC 可帮助限制关系泄露；前缀上限可抓异常规模；客户过滤可约束预期路由；建模可比较生成公告与意图；监测与回滚可用于封堵和修复。

Heng.lu 原理给出了简明的最终标准。注册与路由策略记录保留可追溯证据，但不直接支配转发平面。运行代码、已配置策略与被接受路由决定互联网实际行为。运营连续性要求错误状态可被检测、清除且可由外部独立确认。

因此可发表的一份可信恢复记录应展示预期导出集合、生成策略测试、直接客户过滤、前缀上限、实时异常检测、撤回时序、对等确认与转发恢复，并在受控环境下复现原始故障类别，证明哪一层控制停止了其发生。

1997 年 4 月 25 日留下的长期问题，不是今天的运营者是否明白路由泄露危险，而是其是否能证明：一个被转换、未授权且高度具体的路由集合不会在其边界内不受控传播；一旦发生，是否能够证明可观察地恢复。AS7007 事件让这一互联网问责测试可被看见。