前缀还能到达，为什么路由仍可能不可信：BGP来源验证能判断什么、不能判断什么

值班人员看到监测告警：同一个服务在甲地仍可访问，在乙地却超时，BGP观测同时显示起源AS刚刚改变。只做一次浏览器测试，很容易得出‘页面还能开，路由应该没事’的结论；只看RPKI的Invalid标签，又可能直接把事件写成劫持。两种判断都把不同层的证据揉在了一起。

RPKI来源验证能核对前缀与起源AS的授权关系，却不验证整条传播路径、业务身份或最终内容；处置要把验证状态、路由变化和应用结果分开记录。这样既不会因为局部可达而漏掉异常，也不会把一次ROA配置错误升级成已经确认的攻击。

先把三种问题拆开

可达性回答的是‘这个观察点现在有没有一条可用路径’。来源授权回答的是‘公告中的起源AS是否符合地址持有者发布的ROA’。应用验证则回答‘连到的服务、证书和内容是否符合预期’。三者可能同时正常，也可能只坏一层。

可达性说明某个观察点仍有路径，来源验证说明公告是否符合ROA，两者都不证明应用内容可信。例如，部分运营商拒绝Invalid公告，另一些暂时接受，用户便会看到地区性差异。即使所有地区都还能打开，也可能只是旧路径尚未撤回、缓存仍有效或观测点选择了另一条路。反过来，路由Valid也只说明起源字段与授权相符，不能证明页面没有被替换。

因此第一次记录不要只写‘能开’或‘不能开’。至少保存前缀、起源AS、观察点、时间、RPKI状态、DNS结果、TLS主体与应用响应摘要。后续人员才有可能判断变化发生在路由、传输还是内容层。

Valid、Invalid与NotFound怎样产生

RFC 6811规定，路由器从本地RPKI缓存取得已验证ROA载荷，也就是VRP。每项包含前缀、允许的最大前缀长度和起源AS。收到BGP公告后，路由器取AS_PATH最右端的起源AS，与覆盖该前缀的VRP比较。

来源验证有Valid、Invalid与NotFound三种状态，NotFound不等于Invalid。没有任何VRP覆盖公告前缀时是NotFound；至少一项同时匹配前缀范围、最大长度与起源AS时是Valid；存在覆盖项却没有任何一项匹配时才是Invalid。NotFound表示当前没有可用于这次核对的授权对象，不应写成‘验证失败’；Valid则是明确匹配，而不是泛泛的可信评分。

状态还带有时间和观察点。RFC 6811指出RPKI是分布式数据，不同缓存受抓取和更新时间影响，可能暂时拥有不同视图。同一前缀在两处监测结果不一致时，要记录各自的验证器更新时间，不能先挑一个符合预期的结果。

路由器把公告前缀和起源AS与本地缓存的VRP比较，再把结果交给本地路由策略决定接受、降权或拒绝。于是‘某地仍能访问’只表示那里的策略与路径组合仍允许流量通过，并不推翻另一个观察点的异常。

为什么Invalid不能直接写成攻击

RIPE NCC在AS3333部署来源验证时说明，错误的起源AS、前缀或MaxLength也会让合法公告成为Invalid。对外部观察者而言，仅凭状态无法分辨这是笔误还是劫持。它是需要升级核对的强信号，却不是事件归因。

实际排查先问三个问题。第一，起源变化是否在维护单、上游通知或DDoS清洗计划中。第二，覆盖ROA是否授权了新AS和实际公告长度。第三，多点路由与应用观测是否同时出现偏转、证书变化或内容差异。若只是ROA落后于计划切流，网络负责人可以修正授权并观察传播；若没有任何合法变更记录，且路径与应用均异常，事件优先级就应提高。

这套顺序也保护现场证据。不要为了让状态恢复Valid就先修改ROA，也不要在未核对前删除旧对象。先保存公告、覆盖VRP、序列号、验证时间和变更记录，再决定回滚路由还是更新授权。否则事后只能看到修正后的状态，无法解释异常如何发生。

maxLength与应急切流的取舍

RFC 9319建议尽可能使用最小ROA，只授权实际会由某个AS起源的前缀。宽泛的MaxLength虽然减少维护次数，却可能允许更多未实际使用的子前缀被伪造起源，扩大攻击面。

但应急切流有真实例外。DDoS清洗服务可能需要在短时间内由另一AS公告更具体前缀，而RPKI对象传播通常慢于BGP更新。若等攻击发生才创建ROA，新公告可能在传播期间被标成Invalid并遭拒绝。合理做法是事前精确列出可能使用的清洗前缀与AS，而不是把整个地址块无限放宽。

这是一项运营弹性与授权范围的受控交换，不是‘MaxLength越小越安全’的口号。每个预授权项都应对应合同、演练或应急流程；取消服务后及时移除；变更窗口前检查各验证点是否已取得新对象。没有这些记录，临时起源改变就很难与误配置或伪造区分。

一张能支持升级处置的核对表

事件单第一组写路由事实：前缀、旧与新起源AS、AS_PATH、首次观察时间、观察点和路由收敛变化。第二组写RPKI事实：Valid、Invalid或NotFound、覆盖ROA、最大长度、验证器与缓存更新时间。第三组写应用事实：解析地址、HTTP状态、TLS证书主体、页面或接口摘要。

接着做受控比较。用至少两个不同网络观察同一前缀；比较切流前后的起源与路径；再从已知正常入口取得一次应用结果。若只有一个观察点失联而起源和内容都未变，应先查本地策略或传输故障。若起源未授权、多个网络开始拒绝且没有变更单，则立刻联系前缀负责人和上游，并保留证据。

按前缀、起源AS、ROA、观察点、时间和应用结果保存证据，并向网络负责人核对计划变更。联系负责人时不要只转发一个红色标签，还要提供覆盖ROA和开始时间，询问是否为多宿、迁移或清洗动作。确认是计划变更后，仍要检查ROA何时发布、各缓存何时更新，以及旧起源是否按计划撤回。

Valid不验证完整AS路径；Invalid也可能来自配置错误或计划切流未同步ROA。来源验证更不能验证TLS身份、代理载入或最终页面内容。把这个边界留在事件单中，下一班人员才不会把‘已验证起源’误读成‘整项服务已经安全’，也不会因页面暂时可达而停止调查。

资料来源

• RFC Editor：《RFC 6811: BGP Prefix Origin Validation》，发布或更新于 2013-01-01
• RFC Editor：《RFC 9319: The Use of maxLength in the Resource Public Key Infrastructure (RPKI)》，发布或更新于 2022-10-01
• RIPE NCC：《RPKI and AS3333 or ‘How We Eat Our Own Dog Food’》，发布或更新于 2021-04-13