2018 年 Google 路由泄漏暴露了路由合同与实际控制之间的脱节

摘要

• 2018 年 11 月 12 日，尼日利亚提供商 MainOne 将与 Google 服务相关的路由泄露给 China Telecom，随后通过其他提供商传播，导致部分发往 Google 的流量走了意外路径，使部分用户的服务变得不可达。
• 该事件与 2008 年巴基斯坦电信 YouTube 劫持不同。在此事件中，关键的责任问题并非国家级封锁被错误地导出为来源更具体的路由，而是合同与控制的错配——通过一种关系学到的路由逃逸到了其他关系中。
• 公开记录支持这是一次意外配置错误，而非成功的内容入侵。据报道，Google 表示受影响流量已加密，且无理由相信服务遭到入侵；而独立观察者则将这条路由路径视为严重的可用性和监控风险。
• RPKI 源验证并非此类故障的完整解决方案，因为受影响的路由仍可能看似来自合法的 Google AS。路由泄漏需要客户与对等方过滤、关系感知控制、前缀限制、监控、协调以及后续机制，如 BGP Roles。
• 责任教训在于，商业对等互联与转接合同无法自我执行。运营商必须将业务关系转化为路由器策略和外部可验证的控制措施，以避免泄漏路由导致全球中断。

证据记录及其使用方式

本文将公开记录视为分层证据。事件报告、标准、浏览器或路由测量数据、监管或政策材料以及当前的运营商指南被用于不同的论断。公司撰写的来源归因于公司立场。标准及后续指南用于解释控制措施并提出问责预期，而非在公开记录不支持的情况下捏造内部事实或追溯性强加后来的义务。

事件关乎路由器无法推断的边界

2018 年 Google 路由泄漏很容易简化为一句话：BGP 是脆弱的。这句话正确但不够精确。更深刻的教训是，互联网中存在许多路由软件无法推断的业务关系，除非运营商进行编码。对等方可能会发送本应留在本地范围的路由。转接提供商可能会收到绝不应从该邻居处接收的路由。一条路由可能保留正确的源头 AS，却仍然穿过违背商业和运营预期的路径。

Cloudflare、ThousandEyes 和 Internet Society 的叙述汇聚出核心轮廓。MainOne 在拉各斯通过互联关系与 Google 连接。与 Google 相关的路由从该关系逃逸至 China Telecom。China Telecom 将其向外传播，出现了涉及 TransTelecom、NTT 及其他网络的路径。试图访问 Google 服务的用户随即沿这些路径前进，但这些路径并无承载该流量的容量、策略或预期过滤。部分流量被丢弃，一些用户的服务变为不可达。

这与巴基斯坦电信 YouTube 劫持机制不同。2008 年，巴基斯坦电信从一个错误的源头 AS 发起了 YouTube 地址空间的更具体路由，PCCW 对其进行了传播。2018 年，重要的公开分析描述的是一次路由泄漏，即源自 Google 的路由被传播出了预期关系之外。源可能看似合法，但路径依然是错误的。这一区分很重要，因为它改变了本可帮助的控制手段。源验证可以拒绝虚假源，但它本身不能证明一条正确源的路由仅通过了有效的业务关系。

合同与控制脱节是治理问题的核心。互联合同可能规定，一方只应交换某些路由或不应提供转接。转接协议可能定义了客户锥和导出规则。但远程路由器将基于收到的路由和配置的策略进行转发。如果策略缺失、陈旧或过于宽松，法律或商业边界就变得毫无意义。数据包跟着控制面走，而非合同 PDF。

这正是该事件属于治理范畴的原因。故障并非神秘的自然灾害。它是技术配置、业务关系、路由授权、监控和上报之间的错配。路径上的每个组织只有比全球影响狭窄得多的运营视图。MainOne 可能配置错了导出。China Telecom 可能接收并传播。其他提供商可能偏好或传递这些路径。Google 可以检测、沟通并保护服务层机密性，但它无法直接重写每一份外部导入策略。

正确的源并不意味着正确的路由

许多路由安全讨论始于劫持，因为错误源公告更容易解释。一个不拥有某前缀的人实际上在说“把流量发给我”。RPKI 路由源验证正是为应对这类问题而设计的：资源持有者发布路由源授权，验证网络可拒绝源 AS 或前缀长度不匹配的路由。该控制很重要。2018 年 Google 事件显示了它的边界。

Internet Society 在其公开分析中清楚地指出了这一点：在本次情景中，前缀仍合法地源自正确的 AS，因此中间网络仅靠源验证难以阻断泄漏。路由可能具有有效源，但仍代表无效的导出关系。这就是路由泄漏不仅仅是语气更缓和的劫持的原因。它是一种关系失效：路由被传播到预期范围之外。

对用户而言，实际影响可能同样严重。一条穿过错误提供商的正确源路由可能将流量带入容量不足、过滤严格、存在监控担忧或可达性差的网络。用户看到超时。客户看到云服务中断。事件团队看到经过意想之外的国家/提供商的路由跟踪。正确的源并不能让他们安心，如果路径丢包或违背了他们的风险假设。

这一区分应改变采购和董事会监督。询问提供商是否具备 RPKI 有用但不完整。采购方还应询问提供商是否过滤客户路由、拒绝与业务关系不一致的路由、维护前缀限制、监控泄漏、参与协调渠道，并能解释如何防止对等互联路由变成转接路由。关于 RPKI 覆盖范围的是/否答案不能替代关系感知的路由控制。

后续技术工作，如 BGP Roles 和 Only-to-Customer 属性，试图使业务关系对路由协议可见。这些机制在 2018 年并非完成的通用控制手段，本文不将其作为强制性标准追溯。它们的相关性在于解释：它们之所以存在，是因为运营商认识到许多破坏性泄漏是路径策略失效而非源授权失效。行业需要使“此路由不应走向那边”变得机器可检查的方法。

China Telecom 是传播放大器

公开记录显示 MainOne 是泄漏源头，但事件之所以产生全球影响，是因为其他提供商接收并传播了这些路由。公开报道中 China Telecom 处于中心位置，因为它接收了泄漏的 Google 路由并将其传递出去。这一角色需谨慎描述。公开来源支持意外或错误的路由处理；它们并未证明这是一次成功的流量拦截行动。但意图并非问责的必要条件。转接提供商如果相信了本应过滤的客户或对等方路由，就可能导致重大损害。

具有全球覆盖的提供商有高杠杆义务，要知道邻居被授权公布哪些路由以及哪些路由应被导出。这并不意味着每个路由决策都简单。客户锥会变化，对等方关系复杂，互联网交换承载多样路由，而注册数据可能杂乱。但基本职责依然存在：大型提供商不应仅仅因为 BGP 语法有效就将每条意外路由视为全球可导出的。

过滤也必须匹配关系。对等方路由不应成为转接路由，除非关系明确允许。除非客户确实为该平台提供转接服务，否则不应能发布一个巨型云平台的路由。提供商应应用前缀和 AS 路径过滤器、最大前缀限制、基于可信数据生成路由策略、监控路由集的突然大幅变化，并设立针对异常的知名前缀公告的带外上报机制。

路由路径的公开可见性使得传播角色难以忽视。ThousandEyes 描述了经过 China Telecom 和 TransTelecom 的路径。Cloudflare 记录了异常路由和服务影响。新闻报道聚焦于流量经过中国和俄罗斯，因为该路径带有明显的政治和监控关切。即使流量被加密且未被证明遭入侵，路由本身也损害了客户对流量将传输到哪里以及服务是否保持可达的预期。

这正是政策要点：一个导出泄漏路由的提供商会将另一网络的错误转化为全球事件。初始配置错误很重要，但传播决定了影响半径。因此，路由问责应衡量首次错误导出和每个主要放大点。

Google 有韧性职责但无单边控制权

Google 是受影响的服务运营商，也是最能察觉到发往 Google 的流量出现异常的当事方之一。它还控制着重要的应用层保护。公开报道称，Google 表示受影响流量已加密，且无理由相信服务遭到入侵。这一区分很重要。加密可降低路由错误时的机密性风险，但无法解决可用性风险，但能防止路由泄漏自动成为已被证实的数据泄露事件。

Google 在此类事件中的职责包括路由监控、ROA 发布、准确的 IRR 对象、提供商上报、客户沟通、紧急流量工程和事后证据。像 Google 这样规模的平台无法阻止每一次外部泄漏，但可以缩短检测和修复时间。它还可以将服务设计为即使路径迂回，也不静默暴露用户内容。加密、证书卫生、服务冗余和网络遥测都是该韧性包的组成部分。

同时，Google 无法单方面强制 MainOne 或 China Telecom 应用正确的导入和导出策略。这就是路由安全问责应遵循控制能力而非品牌知名度的原因。用户经历了 Google 中断的症状，Google 品牌承受了面向公众的信任损失。但接受并导出泄漏路由的路由器策略位于 Google 网络之外。治理问题在于 Google 的合同、互联安排和上报手册在事件前如何处理这外部依赖。

受影响平台若能提供更详尽的公开记录，将包括检测时间、受影响前缀数量、面向客户的影响、观察到的路径变化、加密和机密性评估、联系过的提供商、修复时间戳，以及事件后对路由监控或合作伙伴要求的任何更改。其中一些证据在实时事件中可能敏感，但事后摘要可以分享类别，而不暴露防御秘密。

对客户而言，教训不在于因每次外部路由而指责 Google，而在于向大型云和平台提供商询问他们如何监控全球可达性、哪些路由已授权、多快能检测到可疑路径，以及在第三方路由故障导致服务不可达时做出哪些承诺。可用性不止于提供商边界。

合同需要可执行的控制手段

“合同-控制脱节”这个短语捕捉了一种贯穿互联网基础设施的失效模式。各方可能签订了定义谁是对等方、客户或提供商的合同。但路由器执行的是路由策略，而非法律意图。若路由策略未体现该关系，合同就成了事后争论的依据，而非预防性控制。2018 年 Google 泄漏让这一缺口对普通用户可见，因为路径变化破坏了高度可见的服务。

可执行的控制包括基于客户授权路由集构建的前缀过滤器、AS 路径过滤器、路由限制、对等会话策略、RPKI 源验证、路由泄漏检测、针对突发知名前缀导出的告警，以及经过测试的紧急联系人。还包括治理控制：导出策略的变更审查、定期路由集核对、客户锥审查、事件演练，以及快速关闭泄漏会话的文档化授权。

MANRS、NIST 和 IETF 的指南使这些控制比早年更不陌生。重点并非每个运营商都能在明天消除所有泄漏，而是控制词汇已经存在。销售全球可达性的提供商应能解释其如何防止本地对等互联路由变成全球转接，以及在预防失效时如何检测故障。

董事会应要求证据，而非口号。“我们遵循最佳实践”是不够的。一个有用的仪表板应显示 RPKI 验证策略、客户过滤器覆盖率、显式 EBGP 导入和导出策略覆盖率、最大前缀事件、过时路由对象例外、泄漏告警、响应时间和未解决的异常。它应区分源无效拒绝和路径泄漏控制，因为它们是不同的风险类别。

底线是，2018 年 Google 路由泄漏是以关系可控性为核心的问责事件。MainOne 的错误很重要。China Telecom 的传播很重要。其他网络的接受很重要。Google 的韧性和沟通很重要。公众不得不将路由策略失效体验为服务中断。修复的教训不仅仅在于抽象的更好 BGP 卫生；更在于将合同和期望转化为路由控制，使失效可见且能迅速恢复。

因路径运营错误而显得具有政治性

2018 年 Google 路由泄漏之所以引发公众关注，部分原因是流量似乎经过了中国和俄罗斯。这一地理特征对用户和记者很重要，因为它引发了监控和主权担忧。它也说明了一个更普遍的规则：当路由路径违背预期时，解释空间会迅速扩大。用户不知道自己看到的是拥塞、审查、劫持、意外泄漏、监控、攻击还是路由优化出错。因此，运营商的记录必须足够精确，以区分可用性影响与机密性受损，以及意外与蓄意。

公开报道保留了 Google 的立场，即受影响流量已加密且无理由相信其服务遭到入侵。这一声明很重要。它降低了将路径迂回自动视为内容泄露的风险。但加密并未消除可用性问题。加密后再被丢弃的流量仍然无法到达服务。依赖 Google 服务且无法访问的企业仍面临运营中断。即使负载机密性得以保留，路径现在经过意想之外的辖区的公共机构仍可能有政策顾虑。

该路径也揭示了为何关系感知控制比国家标签更重要。China Telecom 的角色有问题的原因不仅是该网络是中国的一部分，更在于该路由显然不应以那种形式被接受和传播。另一国家的一个不同大型提供商，如果接受了一条违反路由策略的对等方学得或客户泄漏的路由，本也可能造成类似的中断。因此，问责标准应侧重于过滤器、路由授权、关系、监控和修复证据，同时承认地理位置能放大用户顾虑。

这一区分有助于避免两种不良解读。一种不良解读是在无证据的情况下将事件视为恶意拦截的证明。另一种则是因未证实内容入侵而将其视为无关紧要的事故。正确的解读介于两者之间：路由泄漏可能是意外且仍然严重；加密流量可能保持机密但仍不可用；提供商可能缺乏恶意意图但仍未能履行重要的过滤职责。治理需要这种中间话语。

政治光学也显示了及时公开沟通为何重要。在缺乏运营商解释的情况下，路由跟踪和 BGP 路径成为了推测的素材。受影响平台应沟通路径的已知情况、加密的已知情况、仍未知的部分、已修复的内容以及哪些当事方控制了失效的路由策略。这不仅是声誉管理，也是一种让用户避免将每条异常路由都视为已证实入侵，同时仍将可用性和路由完整性视为真实风险的方式。

对等互联与转接是带有技术牙齿的业务关系

对等互联与转接常被概括为商业安排：对等方相互交换流量以互利，而转接提供商出售抵达更广泛互联网的能力。Google 泄漏显示了为何这些术语需要技术牙齿。通过互联学到的路由不应被自动导出，仿佛它是客户路由一般。客户路由不应被自动相信，仿佛客户有权转接一个全球平台。一条在某种关系下接受的路由在跨越另一边界时应带有策略约束。

这种映射必须通过路由器配置和验证系统实现。它包括对邻居可发送内容的显式导入策略、对路由可去向何方的显式导出策略、前缀和 AS 路径过滤器、路由限制、RPKI 源验证（适用时）、关系标签、针对路由集突然扩展的监控以及紧急关闭授权。重要的词是“显式”。当配置错误可使 Google 不可达时，默认设置、假设和部落知识是不够的。

RFC 8212 的默认拒绝原则反映了同样的理念：外部 BGP 会话不应在无显式策略的情况下导入或导出路由。这并不能防止所有错误。一个显式但错误的策略仍可能泄漏路由。但它消除了最危险的假设，即未配置或欠配置的会话应默认传播。用治理语言来说，默认拒绝迫使运营商在控制平面行动前声明其路由意图。

合同应遵循同样的逻辑。对等互联协议或转接合同不应仅说明双方的意图；还应要求提供意图被执行的证据。各方是否维护了路由过滤器？客户前缀集是如何生成的？多久审查一次？当邻居泄漏知名前缀时会发生什么？谁有权关闭会话？之后会发出哪些公开或客户通知？这些条款不是过度的法律要求，而是将路由损害转化为运营义务的翻译。

即使客户不是网络运营商，也应关心这些。SaaS 买家、银行、出版商或政府机构可能依赖于一个可达性取决于转接关系的提供商。买家无法审计每条全球路由，但可以向其关键提供商询问他们如何监控可达性、如何使用 RPKI、如何防范路由泄漏，以及当外部路由故障影响服务时如何通知客户。将“互联网路由问题”排除在外的服务级别协议也许能描述法律分配，但并不会使运营依赖消失。

为何源验证仍属于讨论范畴

由于 2018 年 Google 事件是一次路由泄漏而非简单的错误源劫持，部分读者可能得出结论认为 RPKI 无关紧要。这将是错误的教训。对此次泄漏，RPKI 源验证虽非完整控制，但仍属于问责工具箱的一部分。它有助于区分一类虚假授权与另一类，降低不良路由的背景水平，并为许多原本需要人工信任的事件提供机器可读证据。

其局限性很精确。若路由仍源自已授权的 Google AS，源组件可验证通过而路径仍不可接受。在此情形下，RPKI 表明源是允许的，却并未表明 MainOne、China Telecom、TransTelecom、NTT 或任何其他路径段应在该关系中承载该路由。路径验证和路由泄漏预防需要额外的控制。这就是为何 RFC 9234 和关系感知机制很重要。它们解决了信任问题的另一部分。

源验证仍可在事件响应期间提供帮助。若可疑路由是源无效的，运营商可拒绝它或将其上报为可能未经授权。若其源有效但路径可疑，运营商可将事件归类为泄漏或路径策略失效。该分类影响联系谁以及检查哪些证据。一个成熟的路由安全运营不会要求 RPKI 回答所有问题；它使用 RPKI 在可能时消除模糊性，然后应用额外的路由策略检查。

RPKI 还改变围绕文档的激励。像 Google 这样的平台应维护准确的 ROA，还应维护路由对象、对等策略、提供商联系人和外部监控。像 China Telecom 这样的提供商应验证源，还应根据关系过滤。像 MainOne 这样的对等方应防止对等方学得的路由泄漏到转接中。这些控制相互补充而非替代。

因此，读者应带走分层模型。RPKI 处理源授权。前缀和 AS 路径过滤器处理预期的客户和对等方授权。BGP Roles 和 OTC 可编码关系方向。监控检测偏差。人工协调修复自动化无法安全决定的部分。合同语言和治理指标保持这些层级的维护。Google 事件暴露了该分层模型中的缺口，而非构建它的无意义。

更详尽的公开修复记录本可区分每个控制点

对于 2018 年泄漏，有用的事后记录应标识路径中的每个控制点。在 MainOne，记录应说明从 Google 学到了哪个路由集，哪些策略本应阻止导出，发生了什么变化，泄漏何时开始，何时被检测到，以及如何纠正。在 China Telecom，应解释为何泄漏路由被接受，是否存在客户或对等方过滤器，路由限制是否触发，以及导出何时停止。在下游提供商，应说明选择了哪些路径及原因。

对于 Google，记录应涵盖面向客户的影响、受影响服务、加密与入侵评估、检测时间线、提供商上报、路由监控、任何紧急流量工程以及事件后对等互联要求的变更。对于独立观察者，路由采集器证据可显示传播和撤回。对于客户，简洁的摘要可区分可用性损失与数据暴露证据。这些分离的记录将使各方能为自己的控制面负责，而不迫使某一方的声明解释整个互联网。

公开记录部分可通过独立分析获得，但内部修复记录仍然薄弱。这在路由事件中很常见。运营商经常修复路由后就继续前进。问题在于，路由事件只有在控制失效被描述到可修复的层级时才能成为学习机会。仅“配置错误”是不够的。是哪个策略？哪个会话？哪个路由集？哪个邻居关系？哪个告警？哪个撤销权限？没有这些答案，相同的失效可能在不同的前缀和平台上重演。

监管机构和大型买家不应要求每个运营商发布敏感路由器配置。他们可以要求提供路由安全计划和证据类别。例如：客户前缀过滤器覆盖率、RPKI 验证策略、路由泄漏告警、显式 EBGP 策略覆盖率、最大前缀例外、紧急联系人成功率以及事件事后摘要。这些指标足够实际，无需暴露每条路由器行即可审计。

2018 年 Google 泄漏仍然有用，因为它使合同-控制脱节可见。仅凭业务关系暗示路由不应如此传播是不够的。路由器需要可执行的策略。监控需看到偏差。人类需有可联系到的联系人。公众需要证据证明泄漏已被遏制，且加密限制了机密性风险。这就是该事件暴露的治理栈。

读者对路由合同的决策

读者应从 2018 年 Google 路由泄漏中带走的采购和治理问题是：我们的关键提供商是否将路由关系转化为我们可衡量的控制手段？路由泄漏不在乎合同将邻居标记为对等方或客户。它在意路由器策略是否阻止了错误导出，以及监控是否在策略失效时捕获泄漏。因此，客户应向提供商索要客户前缀过滤、显式 EBGP 导入和导出策略、RPKI 验证、路由泄漏告警和全天候上报联系人的证据。

对平台而言，决策在于将外部路由视为服务韧性的一部分。提供商可以拥有优秀的数据中心、强大的 TLS 和经过加固的应用，却仍可能因远程网络偏好一条泄漏路径而变得不可达。这意味着全球路由监控、提供商上报演练、ROA 卫生、路由对象卫生和客户沟通需置于常规可用性工程附近。“互联网在我们边界之外中断了”或许在描述上正确，但客户仍需检测、诊断和修复的证据。

对转接提供商而言，决策在于在知名路由泄漏使问题公开之前证明过滤能力。客户或对等方会话不应被允许成为 Google、银行、政府服务或 CDN 的意外转接路径。提供商应了解预期路由集、拒绝不合理的公告、对突然扩展发出告警，并保存足够日志以解释修复。全球覆盖的价值伴随着不将另一方的错误全球化的责任。

对董事会和监管机构而言，教训在于要求路由安全指标，如同要求网络指标一样。RPKI 无效拒绝率、客户过滤器覆盖率、显式策略覆盖率、泄漏告警、过时路由对象、最大前缀事件和联系人响应时间都是治理信号。它们不是深层数据包秘密，而是关系边界具有技术执行的证据。

2018 年事件仍有用，因为它拒绝适合单一控制。RPKI 很重要，但仅源验证不够。合同很重要，但它们不自我执行。加密很重要，但它不恢复可达性。修复需要整个栈：路由策略、监控、协调、客户沟通和公开证据。

一个最终的运营测试是询问下一次路由泄漏会由客户、外部研究人员还是承载它的网络首先注意到。如果外部用户是主要检测者，那么合同-控制系统就太薄弱了。提供商应能看到当对等方突然似乎转接一个超大型网络时，当客户导出超出其授权的路由集时，以及当流量路径违背业务关系时。这种可见性将路由合同从文书工作转化为可执行的基础设施。

同样的测试属于云和内容提供商的采购。买家可能不在全球范围内运行 BGP，但可以询问其提供商是否监控路由泄漏、验证源、发布路由安全联系人、演练提供商上报，并能解释流量是仅仅不可用还是也暴露了路径风险。这些答案不是抽象的网络微末知识，它们塑造收入连续性、客户支持、隐私保障和公共部门访问。因此，Google/MainOne 事件提醒我们，应用所有者无论其团队是否接触路由器策略，都继承了一些路由依赖。当这一继承依赖被命名、衡量并分配给控制所有者，而非被视为互联网的莫名天气时，问责就开始了。

该控制所有者也应控制中断期间使用的语言。路由泄漏听起来像是遥远的运营商琐事，但客户的问题是即时的：用户能否访问服务、路径是否可信、发生了什么变化以及何时恢复正常？一份强大的事件记录会区分可达性损失、意外转接路径、加密状态、疑似入侵和修复。Google 记录显示了为何这些区分很重要。流量已加密的保证很重要，但它不能回答可用性问题。路由撤回可能恢复服务，但它不解释哪个关系发生了失效。良好的沟通使这些控制面足够分离，以便买家、用户和运营商从事件中学习。

字体排印

最终结论

问责标准是实际控制与公开证据的结合。最强大的记录并不假装每个行为者控制了每个结果。它识别谁能够阻止失效、谁能够检测到它、谁能够限制影响范围、谁能够通知受影响方、谁能够修复信任关系，以及何种证据证明修复到达了依赖它的系统和人员。