Summary

  • JANOG RPKI Routing WG 是一个从 2013 年 1 月 22 日活动至 7 月 31 日的临时工作组。它组织两轮黑客松、实作课、教程和公开讨论，参与者确实操作过证书、ROA、验证缓存、RTR 数据传送与路由器侧观察，但这不是日本生产网络的统一部署。
  • JANOG32 讨论了多缓存、RTR 失联、路由器重载、坏数据和“全部变成 Invalid”的风险；一位参与者提出可按异常比例停止更新，但公开记录没有数值，也没有证据表明 JANOG 采纳过这项建议。更早发布的 RFC 6810 已经规定多缓存、保留数据和转接备用缓存等行为。
  • 后来的 IIJ、NTT、JPNIC、JPIX 与 JANOG 记录，以及 JPNIC 和 RIPE NCC 的真实事故，表明这些故障类别确实存在，却不能证明后来的做法由 2013 年工作组直接造成。RPKI 的安全收益与失效风险必须同时面对：监测要分层，执行要渐进，策略要可逆，异常要有分母，责任要落到真正能操作该层系统的主体。

三种验证状态，都不是路由命令

把 RPKI 路由起源验证说成一张“真假名单”，会把真实操作压扁成一个按钮。路由器收到 BGP 通告后，用其前缀、起源自治系统号和前缀长度，对照验证器生成的已验证 ROA 载荷，即 VRP。若可用 VRP 支持该组合，验证状态为 Valid；若存在覆盖该前缀的授权、但起源或长度不相符，可能得到 Invalid；若没有可用的覆盖授权，则是 NotFound。三者回答的是“现有 VRP 对这项起源声明怎么说”，而不是“路由器现在必须怎么做”。

Valid 的范围尤其容易被夸大。它确认的是前缀、起源 AS 与最大长度同可用 VRP 相符，不检查整条 AS 路径，也不取代前缀过滤、邻居政策、商业关系或异常侦测。它更不保证一条路由应当被接收。Invalid 也不等于恶意：最大长度设置错误、授权未及时更新、发布延迟和日常操作失误，都可能使合法通告落入这个状态。NotFound 则表示当前没有可用于比较的覆盖载荷，并不自动等于拒绝。降低优先级、加标签、接受、暂缓或丢弃，最终都是各网络的本地策略。

要理解一次异常为何不必然导致断网，必须把链条拆开。资源证书、证书吊销列表、manifest 和 ROA 先在 RPKI 仓库发布；依赖方软件抓取并验证对象，形成 VRP 集；ROA 缓存再经 RPKI-to-Router，也就是 RTR 协议，把载荷交给路由器；路由器据此计算验证状态；运营者的策略才决定路由动作；最后还要用流量、探测或用户报告判断连通性。仓库对象无效、VRP 集不完整、RTR 会话中断、路由状态 NotFound、路由状态 Invalid、本地拒绝与终端用户中断，是彼此相邻却不等同的事件。

这一区分不只是术语洁癖。若值班人员把仓库对象的“invalid”直接翻成“所有 BGP 路由都 Invalid”，就可能对错误的故障层采取过度动作；若事故报告把若干依赖方实例受影响直接写成若干次断网，公众又会得到一个并不存在的影响分母。一个安全信号越能改变路由选择，产生、传送与使用信号的每一层就越需要被单独观测。所谓失效安全，不是默认关闭验证，而是在证据尚未跨过下一层时，不让动作先跨过去。

半年的工作组，不是新的路由权威

JANOG 的工作组历史页给出了清楚边界：RPKI Routing WG 于 2013 年 1 月 22 日开始活动，至 2013 年 7 月 31 日结束。JANOG 召集运营者共同体，保存会议档案，提供实验、教程和技术讨论的公共空间；这个临时工作组并非常设权威。

它不是号码资源分配机构，不是区域互联网注册管理机构、证书颁发机构、监管机关、标准组织或生产网络运营者。公开资料也没有建立该工作组具有独立法人资格、签约权或财务控制。JANOG 能召集一场讨论，不能替参与者的自治网络配置路由器；工作组能记录一个建议，也不能据此把建议变成全国规则。把“JANOG 讨论了”写成“JANOG 规定了”，会把共同体影响力误认成命令权。

JPNIC 的角色不同。它是日本互联网注册管理机构，在相关资料中提供或运营过 RPKI 试验、仓库与指南；APNIC 等区域互联网注册管理机构在各自服务区域承担认证与仓库角色。注册管理机构能维护自己控制的认证和发布环节，却不能替每家运营者决定如何处置 Invalid。软件实现者可以修复验证器，缓存运营者可以调整拓扑，路由器厂商可以改变协议实现，本地网络才有权更改导入政策。事故恢复时，这些权限不能被一个模糊的“JANOG 方面”代替。

这种制度边界直接决定技术恢复路径。CRL 或 manifest 没有更新，要找仓库发布方；验证结果因实现严格度分叉，要检查依赖方软件；RTR 同步异常，要看缓存和路由器会话；拒绝政策造成影响，则由配置该政策的运营者回滚。任何一层都不能替下一层宣布“用户已经断网”或“系统已经无碍”。分清权力所在，也是分清证据所在。

2013 年，他们确实动过手，但没有完成生产证明

这个工作组并非讲座的别名。2013 年 1 月与 2 月举行的两轮黑客松，让参与者接触开源 RPKI 工具、验证缓存和实验性的 BGP 路由器链路。4 月与 5 月的实作活动采用更简化、预先准备的环境，继续进行证书与 ROA 签发，并观察路由起源验证结果。7 月的 JANOG32 则把实验经验、教程与没有解决的问题带进公开会议。2014 年修订的工作组报告和JPNIC 在 2013 年的回顾共同记录了这条活动轨迹。

第一轮遇到了环境与软件故障。研发人员修正问题后，第二轮在缓存构建等环节的完成情况有所改善；后续实作还以预构建虚拟机降低环境准备的摩擦。这个先坏、后修、再尝试的顺序说明参与者碰到了实际实现，而非只观看幻灯片。黑客松的价值恰在这里：运行代码会暴露安装、格式、版本和系统衔接上的问题，迫使抽象标准面对具体设备。

但现存材料没有给出完整缓存日志、路由器配置、验证器和路由器版本、逐项故障注入步骤、原始计时，也没有列出每名参与者是否走完端到端流程。我们知道第一轮发生缺陷、第二轮有所改善，却不知道可复算的失败率和参与者分母。报告由活动参与者及相关机构整理，属于重要的一手记录，不是独立实验室审计。第二轮“做得更顺”不能被扩写为系统已经达到生产可靠性。

“试验”也不能偷偷变成“部署”。参与者操作过证书和 ROA，建立或使用缓存，经 RTR 把验证载荷送到路由器并查看状态；这些是有技术含量的实验。公开资料却没有显示 JANOG 运营生产信任锚、在日本生产网络统一执行 ROV，或在 2013 年故意制造一次生产环境的全量 Invalid。小型、有人现场协助的实验能揭示实现问题，却不能自动回答长期运行、规模、真实流量、客户影响和组织交接。它足以证明“做过”，不足以证明“解决了”。

JANOG32 把最危险的情景说出了口

2013 年 7 月 4 日，JANOG32 的公开讨论把安全机制本身当作潜在故障源。问题包括路由器连接多个缓存时怎样选择，RTR 通信丢失后如何继续，路由器重载时验证数据何时恢复，以及异常或损坏的缓存数据会不会让大量路由呈现问题。会议记录还保留了“如果全部变成 Invalid 呢”这样的提问。

记录能够证明问题被提出，不能证明情景被执行。一位参与者建议，当异常达到某个百分比时，可否停止更新，避免可疑数据继续传给路由器。页面没有写出具体百分比；可查的公开资料也没有显示 JANOG 采纳过某个数值、正式规则、对应厂商功能或日本生产网络共同使用的门槛。更没有证据显示 2013 年实验把一张生产网推入了“全部 Invalid”。这是一项会场建议，而非“JANOG 断路器”。

同场演讲者把故障路径拆为外部缓存或 RTR 失联、路由器重载时的数据收敛、损坏的缓存数据，以及状态进入路由器后仍需面对的本地政策。《RPKI 的普及与课题》强调，即使一条路由是 Valid，是否接收仍是另一回事。这份材料证明演讲者当时如何分析风险，不证明每种风险都在受控实验中出现，更不证明它造成过用户中断。

百分比方案听来果断，实际会引出新的安全问题。一次合法的大批 ROA 变更也可能触发全局阈值，使旧 VRP 被过度保留；反过来，占全表比例很小的一组变化，可能恰好击中本地关键客户或基础设施前缀。攻击者也可能把触发冻结本身当成目标。2013 年资料没有评估假阳性、假阴性、冻结后的数据新鲜度或解除权限，因此这些只是应被测试的设计权衡，不是已被证明的缺陷，更不是现成政策。

会议之前，协议已经写下部分连续性机制

把多缓存和保留数据归功于 JANOG，经不起时间线检验。RFC 6810 于 2013 年 1 月发布，早于 7 月的 JANOG32。该标准允许路由器连接一个或多个缓存，并规定缓存不可用时的数据保留、尝试备用缓存以及重置和更新等行为。它是对“JANOG 发明了失效保护”的直接反证：工作组的价值在于把运营疑问公开化，而非创造协议已有的机制。

标准也不是运行结果。RFC 规定预期行为，不证明当时每个实现都符合，也不证明每家运营者部署了真正独立的缓存。两台缓存若位于同一站点、使用相同软件和凭据、依赖同一上游仓库，就可能因同一原因同时失败。即便软件不同，只要输入同一批损坏对象，两套验证器仍会共享数据根因。数量上的“两台”只有跨越站点、实现、上游与运维故障域时，才可能降低相应风险；它无法独力解决信任锚或仓库的相关故障。

2014 年 1 月发布的 RFC 7115又把验证状态的应用明确留给本地政策，并要求运营者在改变策略前预测与测量影响、持续监测、分阶段推进。NotFound 不因此默认被拒绝，Invalid 的动作也不是由 JANOG 或注册管理机构统一下达。最佳当前实践能够证明规范如何分配责任，却不能证明任何具名日本运营者已照办。

标准先于会议，是本文必须认真处理的反方解释。后来的稳健做法可能来自 IETF 规范、软件成熟、厂商支持、全球事故、客户要求和运营者自己的测试，而不一定源于 JANOG32。JANOG 的可证贡献更窄，也更准确：让规范里的缓存、重置和保留行为，变成一群运营者公开追问的“路由器重载时究竟发生什么”“两份结果不一致时该相信谁”。

2015 年，注册服务和路由动作仍由不同主体负责

2015 年 3 月 3 日，JPNIC 开始提供同注册管理数据关联的 RPKI 试验环境，使参与者可用实际获分配资源进入认证链路。一个多月后的 JANOG35.5 介绍页特别说明，若要做路由起源验证，还需另行配置 BGP 路由器。这句话把服务边界说得很明白：认证材料可以由注册体系提供，是否让验证状态影响路由，仍是运营者的工作。

JPNIC 的技术说明描述了分布式仓库、缓存验证、RTR 传送及服务停止对证书和 ROA 的影响。它是服务机构对自身体系的解释，不是独立运营审计，也不证明参与者启用了生产过滤。JPNIC 的试验服务不是 JANOG 的生产系统；JPNIC 能连接分配记录与认证，JANOG 能提供交流场合，网络运营者才控制路由器和本地例外。2015 年的记录展示的是责任交接，不是全国部署的完成。

这条交接有一个常被忽略的后果：一项认证服务“正常”不等于使用该服务的路由政策正确，一台路由器显示验证状态也不等于它已改变最佳路径。号码资源持有者维护授权，仓库发布对象，依赖方软件决定哪些对象形成 VRP，缓存服务 RTR，路由器计算状态，运营者应用政策。任何一环都不应把下一环当成自动发生。

后来的运营数字，为早期担忧提供了有限校验

IIJ 对 AS2497 的报告比 2013 年实验更接近生产规模。该运营者称，自己在 2020 年 3 月至 12 月从实验室和在线网络测试，逐步推进到按对等与上游群组分阶段拒绝 Invalid。每台路由器连接两台缓存，缓存位于日本国内不同地点，并使用不同实现。初期约观察到 3,000 条 Invalid 路由，约占当时全表 0.3%；部署范围包括 10 个节点与少于 2,000 个 BGP 邻居。JANOG47 的 IIJ 演示使外界至少能检查拓扑思路、推进阶段与数量级。

这些数值不能脱离归属和分母。3,000 与 0.3% 是 IIJ 报告的近似快照，10 个节点和少于 2,000 个邻居描述的是该网络，不是日本总体。演示没有公开全部配置、采集器、精确快照条件、逐次策略结果或外部中断审计。不同地点与不同软件降低一部分单站点、单实现风险，却没有证明共同仓库、上游连接、运维权限和信任链相互独立。它是有内容的运营者自报，不能升级为第三方认证。

2022 年 JANOG50 的实验则针对重启疑问。JPNIC 的公开总结称，模拟路由表含接近 80 万条路由，所测路由器的重启表现与普通 BGP 重启没有实质差异。这是对“引入验证数据必然显著拖慢重启”的重要反例，却只约束所测环境。路由数是近似值，公开材料缺少原始时间序列、完整设备矩阵和生产流量；它不能证明所有路由器、缓存、表规模与政策组合都同样安全。

2023 年 7 月的 JANOG52 计划页仍在比较多种 ROA 缓存实现、路由器厂商和 Invalid 处置。十年后还在测试，并不说明技术没有进步，反而说明生产化把问题从“能否连起来”推进到“每次升级、重连和策略变化如何验证”。这些后续记录与 2013 年关切趋同，却没有建立直接传承。

指南把谨慎落实为日常动作，但不是部署统计

JPNIC-01324 指南于 2024 年 11 月 13 日生效，并在 2026 年 3 月 27 日更新。它建议监测缓存进程、资源使用和抓取恢复，比较多台 ROA 缓存的数据集，举出的比较频率是每天一次；策略应分阶段上线，并预先测试回滚、重启和重连；缓存断线超过数据保留时间时需要响应；合法路由因上游数据问题被判 Invalid 时，可通过 SLURM 或其他本地政策处理例外。

这些动作的共同点不是“自动安全”，而是可观察、可比较、可逆。缓存进程仍在运行，不代表其数据完整；两份输出突然分叉，必须先能看见差异。策略影响超过预测时，需要回退路径。临时例外可以维持合法流量，也可能变成永久盲区，因此应记录前缀、原因、负责人、期限与源头修复进展。回滚不是否定 RPKI，而是把一次异常的影响限制在证据已知的范围。

指南仍是 JPNIC 的机构性建议，不是对日本所有网络的测量，也不能证明普遍遵从。其形成时间远晚于临时工作组，材料又指向 2022 至 2023 年研究与社区咨询。相似做法可以被称为回应了同类问题，不能仅凭相似性写成 2013 年工作组的政策后代。

多缓存解决可用性，未必解决数据正确性

“连接两台缓存”是 RPKI 运营中最容易传播、也最容易被误解的一条建议。它首先解决的是某个 RTR 服务端不可达：路由器若失去一条会话，可以尝试另一台缓存；在协议和实现允许的期限内，还可以保留此前取得的数据，避免状态立刻清空。这比依赖单个远程端点稳健得多，却只覆盖了一类故障。

缓存是否“活着”和它给出的 VRP 是否“正确”，是两项不同指标。进程可以响应健康检查，却因抓取停滞而长期输出旧数据；两台缓存也可以同时连通，却因依赖同一仓库对象而共同缺失一批 VRP。若运营监控只检查 TCP 端口或 RTR 会话，数据质量问题可能在所有绿色指示灯下继续存在。JPNIC 指南建议比较多台缓存的数据集，意义就在于把服务可用性监控推进到输出差异监控。

比较结果本身又需要语境。两台不同实现短暂存在差异，可能只是抓取时间不同，也可能是其中一台拒绝了另一台接受的对象。差异数骤增时，应先按信任锚、仓库、资源范围和首次出现时间分组，而不是立即投票“多数为真”。如果所有缓存都依赖同一份错误发布，多数一致也可能一致地错；如果只有一个严格实现拒绝不一致对象，它又可能在可用性上显得最差，却在安全判断上最符合自己的规则。

站点多样性也不能只看城市名称。缓存分布在两地，若仍共享云账户、自动化凭据、软件发布渠道、DNS、上游网络或同一远程仓库，就保留着相关故障。反过来，两套软件若由不同团队维护，也会引入版本节奏、告警含义与故障处置的不一致。所谓多样性不是越多越好，而是先列出准备抵御的故障，再确认每个副本是否真正跨过相应故障域。

数据保留同样是缓冲，不是保证。短暂断线时，继续使用刚刚验证过的 VRP 可以防止路由状态突然大面积转为 NotFound；时间拉长后，旧数据可能继续认可已经撤销的授权，也可能漏掉新近发布的合法 ROA。运营者必须知道实际实现保留多久、数据年龄如何告警、何时切换备用缓存，以及重新连通后怎样确认增量或全量同步完成。把“保留旧数据”写成“仓库故障不会影响路由”，只是把可用性风险换成了没有标注的陈旧风险。

临时例外也有同样的两面。合法前缀因发布或验证问题落入 Invalid 时，本地覆盖可以避免立即损害连通性；但覆盖若没有到期和复核，就会逐渐形成绕开验证的影子数据库。安全做法不是拒绝例外，而是把它变成一项有所有者、有证据、有适用范围、有结束条件的变更。上游对象修复后，还要确认缓存和路由器已经收到新状态，再撤销覆盖。否则一次成功的事故处置，会在网络里留下下一次事故的种子。

这些限制说明，冗余、保留和例外分别在不同时间尺度上争取诊断空间。它们不是替运营者作出最终判断，而是避免单一故障立刻触发不可逆路由动作。安全设计的质量取决于争取到的时间是否被用于定位、修复和清理，而不是取决于设备清单上有多少台缓存。

JPNIC 事故：几乎所有 ROA 对象失效，所见路由却是 NotFound

真实事故说明分层不是抽象练习。JPNIC 在 2022 年 2 月 2 日发布的事故通知称，问题自 1 月 26 日持续至 2 月 2 日恢复。磁盘空间写满，使新的 CRL 与 manifest 无法按时发布；几乎所有由 JPNIC 签发的 ROA 在仓库对象层失效。问题由用户发现，之后通过人工处置恢复。

受影响的 BGP 路由被观察为 NotFound，而非全部变成路由状态 Invalid。对象不能通过验证，就无法形成相应可用 VRP；路由器比较时缺少覆盖载荷，因此所见状态可能变为 NotFound。许多运营者对 NotFound 与 Invalid 采取不同政策，混写两个状态会直接歪曲事故的可能机制。

该通知没有给出受影响 BGP 路由数、依赖方实例数、流量变化或终端用户中断数，也没有建立 JANOG 的因果责任。能确认的是事故日期、磁盘写满、CRL 和 manifest 过期、对象层的大范围失效、所观察到的路由验证状态及人工恢复；不能据此写成“日本大面积断网”，也不能反向断言“没有用户受影响”。影响没有测量，就是未知，而非零。

事故还暴露多缓存的上游盲点。若两台缓存都从同一失效仓库抓取对象，复制缓存无法让仓库重新发布。不同实现可能在时间或严格度上呈现不同结果，却不能消除共同数据根因。有效监测必须同时覆盖仓库发布和对象新鲜度、依赖方验证结果、缓存间差异、RTR 连通、路由状态、本地动作及业务探测。单层冗余不是整条链的冗余。

RIPE NCC 事故：327 个实例不是 327 次断网

日本之外的独立案例验证了同一故障类别。2021 年 1 月 7 日，RIPE NCC 出现父子证书发布不一致。次日的公开事后说明称，采用较严格 manifest 处理的旧版本依赖方实现会拒绝全部 RIPE 资源证书，共有 327 个依赖方实例受到影响。事后改进包括原子发布计划。

327 的分母是依赖方实例，不是 327 家运营者、327 条路由、327 名用户或 327 起中断。RIPE NCC 只说事故“可能造成中断”，没有给出经过测量的终端用户影响。实现差异也不能被简单解释成“宽松更安全”：严格实现放大了发布不一致的可用性后果，宽松接受不一致对象又可能削弱安全判断。这是安全性与可用性必须共同评估的例子。

这次事故同 JANOG32 没有可证的因果线。它的意义在于从外部证明，仓库若未一致发布，依赖方实现可能拒绝整棵资源证书；若多台缓存共享该上游数据，设备数量不能消除相关风险。它让 2013 年“坏数据会不会造成大范围异常”的问题显得并非杞人忧天，同时仍要求我们把“可能中断”留在可能，不替来源补写用户损失。

两起事故验证同类风险，却不是同一条故障链

把两起事故并列的意义，不是重述经过，而是比较证据落点。JPNIC 案例给出了仓库对象层故障和路由验证状态，却没有依赖方、路由、流量或用户分母；RIPE NCC 案例给出了受影响的严格旧版依赖方实例数，却没有路由或用户影响。它们能共同支持“仓库发布异常会改变下游验证”这一判断，却不能把任一案例缺失的观测借给另一个案例。各自段落中的精确时间仍须分别保留，以便运营者对齐证书、manifest、缓存和路由观测；比较时则应记住，两起事件发生在不同服务区域，由不同主体负责，恢复动作也不同。

它们共同证明的上限很窄：仓库层广泛异常是真实故障类别，依赖方实现会影响下游所见，多台缓存若共享同一发布源就可能一起受影响。它们没有共同证明路由必然被拒绝，更没有证明终端用户必然中断。JPNIC 通知没有路由和用户分母，RIPE NCC 的 327 也不能换算成用户。若要从这些事件推导业务影响，还需要运营者策略、最佳路径或转发表变化、流量与探测、故障时段用户报告等额外证据。

两起事故还显示“更严格”与“更可用”并非简单排序。严格拒绝不一致对象，能避免把破坏完整性的材料继续当作可信输入，却可能在仓库发布错误时移除大量 VRP；继续接受则可能维持更多状态，却削弱对象一致性保障。合适的响应不是事后宣布某种实现哲学绝对正确，而是要求发布原子性、实现可观测性、版本更新、数据比较和可逆的本地政策共同承担风险。

这也是为何真实事故只能校验 2013 年提出的故障类别，不能为 2013 年工作组补写功劳。JANOG32 公开问过坏数据与大面积异常，后来别处确实出现仓库级事故；中间仍缺少设计传承、部署决策或处置参与的证据。相似的故障机制让早期问题更值得重读，但时间上的先后并不会自动生成组织因果。

反方证据：RPKI 越来越有用，而不是越来越不该部署

若文章只把缺陷与事故排成一列，故障工程就会被误写为反对 RPKI。2019 年同行评审的全球纵向研究 《RPKI Is Coming of Age》发现，早期常见的错误配置后来已大幅减少，并认为 RPKI 的成熟度足以支持更严格使用。这项研究有自身方法与观测窗口，范围也不是日本；它不能证明任何日本网络的部署状态，更不能证明 RPKI 已无故障。但它有力反驳了“早期实验出错，所以起源验证不适合进入路由政策”的静态结论。

NTT 的案例进一步展示安全收益如何来自持续操作，而不只来自一次过滤。APNIC 于 2022 年 12 月 15 日发布的案例研究称，NTT 持续监测所有地址族的已知 RPKI invalid，并通过软件和流程使无效通告减少 86.84%。这个百分比来自生态体系内发布的案例，不是原始数据集或独立审计，也不能归因于 JANOG32；它仍说明监测、联系资源持有者、修正数据与制度化响应能减少错误，而不是只能把路由丢弃。

路由起源验证的安全价值有清楚边界：当一个前缀由不符合授权的起源 AS 通告时，VRP 能提供可操作的不匹配信号。它不验证整条 AS 路径，也不能阻止所有路由泄漏，但确实补上 BGP 原生信任的一处缺口。随着 ROA 覆盖、工具与操作经验改善，无限期停留在“只监测、不执行”并非没有代价，错误起源仍可能传播。

成熟度反证没有消除仓库、软件、缓存、策略或相关故障。它改变的是结论：目标不应是证明 RPKI 永不出错，而是让错误可见、影响受限、动作可撤销、责任可追踪。一个安全机制越有用，失灵时越值得严肃处理。失效安全与部署不是相反方向；前者是后者能够承担更大权重的条件。

“可逆”也不能被当作长期不执行的委婉说法。仅给 Invalid 加标签而永远不改变选择，能积累观测经验，却无法持续提供拒绝错误起源的完整收益；在故障时永久放开所有状态，则会让攻击或误通告重新获得原有机会。更合理的办法，是把稳态政策与事故政策分别设计：正常情况下逐步执行经过测量的规则，异常时只对证据支持的范围回退，并设置恢复条件。这样既不把一次仓库故障变成放弃 ROV 的借口，也不以安全口号阻止必要的临时保护。

同理，减少 Invalid 通告与拒绝 Invalid 路由是两项工作。NTT 案例中的 86.84% 改善来自监测、软件与流程，强调的是从源头减少错误通告；IIJ 的分阶段部署描述的是路由接收侧如何扩大执行。前者能减少误伤与运营负担，后者在授权不匹配时提供防护。把二者配合起来，比只在路由器末端丢弃更接近成熟部署，也解释了为什么故障安全需要跨越资源持有者、注册体系和网络运营者之间的协作。

中央公共缓存退场，并不等于替代方案已经无懈可击

JPNIC 自 2015 年开始的公共 RPKI 缓存试验于 2025 年 12 月结束。服务变更通知把集中点顾虑、已有替代服务、操作指南和使用下降列为理由。这是 JPNIC 对自身决定的说明，缺少独立用户数、事故率和退役前后对比；它不能证明公共缓存天然不安全，也不能证明替代服务已经充分多样。

JPIX 在 2025 年 1 月的 JANOG55 材料中公开了东京与大阪两个 AWS 区域的缓存端点，支持 IPv4、IPv6 和 TCP 323。这份部署演示提供了可核对的服务端点与配置，却没有审计正常运行时间、客户数量、两地网络路径独立性或故障转移。两个区域增加选择，不等于端到端韧性已经得到证明。

两份记录合起来，更适合描述方向：运营环境从一个中央试验缓存，转向运营者自建、互联网交换相关服务与多区域端点并存。分散化可以削弱某些集中风险，也增加数据比较、配置、信任和告警协调的工作。多一个端点只是多一个可能路径；只有持续测量故障域与恢复行为，才能知道它是否构成有效替代。

2026 年的“VRP breaker”仍是一项提案

到 2026 年 7 月 16 日，JANOG58 的一项节目摘要仍在讨论不完整 VRP 集造成错误 Invalid 的风险，并提出检测到异常时暂停分发 VRP 的“VRP breaker”。节目页显示，提案来自 BIGLOBE 与长崎大学相关演讲者，并标注为专利申请中的机制。

截至 2026 年 7 月 20 日资料访问时，公开页面没有演示文稿、方法细节、部署结果或独立验证。因此它只能被称为提案，不能写成已上线的日本保护机制，也不能倒过来证明 2013 年的百分比建议被继承。两者都想在异常数据到达路由器前踩刹车，但现有资料没有给出组织或技术传承。

一个可用的断路机制至少要回答：异常按全球 VRP、某个信任锚、客户集合还是本地关键前缀计算？暂停后保留哪版数据、保留多久？合法的大批更新会不会误触发？攻击者能否用触发冻结来延长旧授权寿命？谁能解除暂停，运营者如何看到原因？没有公开测试结果之前，这些是评估提案的问题，不能用推理替代实证。

事故处置需要逐层核对，而不是寻找万能百分比

假设值班工程师先看到 NotFound 数量突然上升，稳妥的第一步不是批量拒绝，而是确定变化发生在哪一段时间线：仓库发布之后、验证器升级之后、缓存重启之后，还是路由器重连之后。若多台不同实现的缓存同时丢失同一批 VRP，共同上游更可疑；若只有一个实现偏离，应先检查软件、配置或验证严格度；若缓存数据一致而一台路由器的状态不同，排查方向才转向 RTR 会话、数据保留和路由器处理。

接着要把每层的分母分别记下。异常对象数不是缺失 VRP 数，VRP 数不是受影响 BGP 路由数，路由数不是会话数，会话数也不是用户数。还要判断受影响通告来自客户、对等还是上游，本地策略是否改变最佳路径或转发表，流量与主动探测是否出现可重复变化。只有最后一组证据才能支持连通性结论。

动作应尽量可逆。单台缓存出错，可以隔离或降低其优先级；共同仓库异常时，切换到抓取同一数据的另一台缓存未必有效。保留旧 VRP 能缓冲短暂断线，却把空集风险变成新鲜度风险：旧授权可能已经撤销，新授权也可能尚未进入。临时 SLURM 或本地例外可以维持合法路由，但必须限定范围、负责人和期限，恢复后还要清理。仓库重新发布不等于路由器已全量同步，路由状态恢复也不等于临时政策已经撤销。

这正是统一百分比难以取代分层判断的原因。同样的全表变化比例，对大型转接运营者、小型内容网络和互联网交换相关服务可能代表完全不同的客户与业务表面。一个很小的比例可以击中关键前缀，一次很大的变化也可能是合法批量更新。共同体可以共享指标、测试方法和事故档案，具体动作仍应由能观察本地风险、也承担本地后果的运营者决定。

2013 年有参与者提出按比例停更，2026 年又出现断路器提案；公开记录至今没有 JANOG 采纳的数值，也没有统一日本生产门槛。没有发现，不等于任何运营者内部从未使用阈值；它只意味着公共文章不能虚构共同规则。一个阈值即使存在，也需要基线、数据新鲜度、受影响资源、进入与退出条件、人工权限和事后审查，不能单凭百分比自证安全。

后来做法与 2013 年相似，不等于由 2013 年造成

后来的日本材料提及 JANOG30 至 JANOG32，说明这段经历留在共同体记忆中；后续会议也持续讨论缓存、重启和 Invalid 处置。但引用只能证明有人记得，不能证明因果。若要断言临时工作组直接导致 IIJ 的双缓存、NTT 的监测流程、JPNIC 的指南、JPIX 的区域布局或 2026 年提案，需要决策记录、设计文件的明确溯源、参与者访谈、版本历史，或可验证的人员和技术交接链。

现有公开材料没有完成这条链。RFC 6810 与 RFC 7115、验证软件成熟、RIPE NCC 等地的事故、客户与监管环境、厂商支持、运营者内部试验，都可以独立推动相似做法。更稳妥的结论是：后来实践与 2013 年公开提出的问题趋同，或者检验了同类故障。这样的表述没有贬低 JANOG，反而把其实际优势说得更清楚。

JANOG 的影响可能首先是一种公共记录能力。许多故障与策略讨论发生在企业内部，后来者难以查见。临时工作组把软件缺陷、缓存依赖、路由器行为和停更建议留在公开档案，使其他运营者能够重复、反驳或改进。会议档案可以成为学习基础设施，但它不是政策命令链，也不是后来部署的所有权凭证。

档案本身仍有限。会议页面经过整理，演示文稿压缩方法，参与者报告会选择呈现成功与教训；2013 年没有原始日志和完整失败结果，后来运营者材料也多为自报。同一 JANOG32 资料家族即使有多份页面和 PDF，也不会因链接变多而成为多项独立证据。编辑过的会议记录、演讲者分析、运营者报告、同行评审研究和事故事后说明，需要按各自的证据性质阅读。

结语：让权威停在证据能够支持的那一层

2013 年的临时工作组没有留下神奇数字，也没有替日本运营者制定统一保护规则。它留下了一组只有在证书、ROA、验证器、缓存、RTR 与路由器真正相连后才会变尖锐的问题。第一轮的软件缺陷证明规范不能代替运行检验；第二轮与实作活动又证明早期缺陷不必成为拒绝技术的终局；JANOG32 的讨论则把“安全数据自身出错怎么办”写进公共记录。

后来的证据使答案更具体，也更有限。RFC 6810 证明多缓存和数据保留不是 JANOG 的发明，RFC 7115 把动作留给本地政策。IIJ 的分阶段部署、JANOG50 接近 80 万路由的模拟测试、JPNIC 的指南和 NTT 的持续监测，表明路由起源验证能够谨慎进入现实运营。JPNIC 的磁盘写满与 RIPE NCC 的发布不一致又表明，上游对象和实现差异确实会广泛改变下游所见；但对象无效、NotFound、Invalid、本地拒绝和用户中断绝不能混成一个结果。

成熟的结论既不是“RPKI 太危险，不该部署”，也不是“RPKI 已经解决路由安全”。独立研究显示早期误配置随成熟度提升而减少，运营案例也显示监测与流程能降低无效通告；无限期不部署不是中立选择。与此同时，越多网络让验证状态参与路由决策，仓库发布、缓存比较、实现多样性、回滚与例外治理就越接近关键基础设施职责。

真正的失效安全，是让每一种权威只在自己的证据范围内生效：注册管理机构维护认证与发布，依赖方软件验证对象，缓存经 RTR 传送载荷，路由器计算状态，网络运营者决定动作，用户影响则必须另行测量。JANOG 能召集这些主体并保存可追问的历史，却不替任何一方掌权。只要这条边界清楚，坏数据就有机会先停留在可诊断、可回滚的控制面，而不会被一句含混的“全部 Invalid”直接推演成一场未经证明的断网。

元数据

字段 内容
SEO 标题 JANOG 的 RPKI 试验：验证数据失效时，路由如何安全处置
SEO 描述 回看 JANOG 2013 年临时 RPKI 工作组的实作、故障讨论与权限边界，并以 RFC、IIJ 部署及 JPNIC、RIPE NCC 事故检验路由起源验证的失效安全。
OG 标题 当验证数据出错：JANOG 的 RPKI 试验留下什么
OG 描述 从两轮黑客松到真实仓库事故，解释对象无效、NotFound、Invalid、本地拒绝与用户中断为何不能混为一谈。
Twitter 标题 JANOG 的 RPKI 试验如何追问失效安全
Twitter 描述 多缓存不是万能答案，百分比停更也从未成为 JANOG 规则。理解 RPKI 的收益，先看清每层故障与每个责任主体。
焦点关键词 JANOG RPKI 失效安全
Slug janog-rpki-fail-safe-trial
分类 jpnog
受控主题 rpki-and-route-security

特色图片说明

  • 图片替代文字：日本网络运营会议的实验室场景，工程师查看分层呈现的 RPKI 仓库、验证器、ROA 缓存、RTR 会话与路由器状态，橙色异常信号被隔离在控制面。
  • 图片说明：原创编辑概念图，展示从 RPKI 仓库对象到运营者本地路由策略的依赖链；不是 2013 年现场照片，也不代表任何真实事故画面。
  • 无障碍长描述：横向画面从左至右依次为资源认证与仓库、依赖方验证、ROA 缓存、RTR 传送、路由器验证状态和本地路由策略。仓库与缓存之间出现橙色警示，后续层以数据比较、保留、备用连接和回滚图标表示可控响应；画面不使用断网符号，也不暗示资料没有证明的用户中断。
  • 图片来源与制作说明：依据 JANOG、JPNIC、IETF、IIJ、JPIX、APNIC 与 RIPE NCC 的公开技术资料制作原创编辑示意；不复刻机构徽标、真实设备界面或事故截图，发布前核对所有技术标签与授权要求。

发布来源登记