互联网路由资源公钥基础设施（RPKI）

在互联网的边界网关协议（BGP）路由中，某个前缀被谁宣告，不能只靠宣告者自己的说法。互联网路由资源公钥基础设施（RPKI）把 IP 地址和自治系统号的分配关系、签名路由对象及分布式仓库组合起来，让接收网络可以核验：宣告这个前缀的起源自治系统（AS），是否得到地址持有者授权。它检查的是路由起源这一项，不会替网络决定哪条路由更合适。

资源证书沿互联网号码资源的分配层级签发，把公钥与受托的 IP 地址或 AS 号范围关联起来。依赖方从自己选择的信任锚验证证书链。资源证书证明资源授权，不证明证书主体的公司或个人身份；证书名称也不是网站域名身份声明。因此，RPKI不是浏览器验证 HTTPS 网站身份的 TLS 证书体系。

地址持有者可以用端实体证书签署路由起源授权（ROA），写明一个 AS 可以宣告一个或多个前缀。每份 ROA 指定一个被授权 AS；如需授权多个 AS，需分别签发对象。它是一项正向授权，不代表该路由已经在网上发布，也不承诺数据一定能到达。当前 ROA 对象格式见 RFC 9582；该标准已取代 RFC 6482。

证书、撤销信息和签名对象发布在分布式仓库中。依赖方（Relying Party）软件定期取得这些公开数据，验证证书链、有效期、撤销状态、签名和资源范围；只有通过相应检查的 ROA 才能供路由起源验证使用。签名或证书检查失败的对象不会变成一条可用授权记录。

验证器或缓存把有效 ROA 的关键信息整理为已验证 ROA 载荷（VRP）：前缀、允许的最大前缀长度和起源 ASN。路由器可通过 RPKI 到路由器协议从本地可信缓存接收这些条目；它收到的不是每一份原始证书或完整仓库。仓库更新与 BGP 路由传播分属不同流程，缓存刷新也有先后，因此不同网络、甚至同一网络的不同设备，短时间内可能持有不同的 VRP 集合。

VRP 是一项可重复用于比对的授权记录，不是某条路由的判决结果。路由器把本地的 VRP 集合与路由前缀、BGP AS_PATH 所示的起源 AS 比较；前缀被 VRP 覆盖，表示它等于该前缀或比它更具体。匹配还要求起源 ASN 相同，且公告前缀长度不超过 maxLength。

Valid 表示至少有一条有效 VRP 覆盖该路由前缀、授权同一个起源 AS，并允许该前缀长度。只要有一条匹配，路由就可判为 Valid；即使另有覆盖它、但起源 AS 或长度不匹配的条目，也不会抵消这条匹配。

Invalid 表示至少有一条有效 VRP 覆盖该路由前缀，但没有任何覆盖条目同时匹配起源 AS 和长度。常见原因是起源 AS 与授权号码不同，或公告了比 maxLength 更具体的前缀。这里的“Invalid”针对这条公告与现有授权不匹配，不等于证明其余网络路径或设备状态。

NotFound 表示没有有效 VRP 覆盖该路由前缀。它表达的是“当前找不到覆盖它的授权记录”，不能据此断定路线合法或恶意。网络对 NotFound 的接受、偏好或过滤方式由本地策略决定；RPKI 规范不要求自动丢弃它。

授权对象有变化时，验证结果也会变化。若新路由先于新 ROA 到达，或旧 ROA 尚未从缓存撤下，路由可能暂时呈现 Invalid；如果没有覆盖它的记录，则可能是 NotFound。若运营者配置了丢弃 Invalid 的策略，合法路由就可能在新授权传播完成前被挡住，导致改走较差路径或部分目的暂不可达。发布或变更 ROA 后，应同时确认仓库、验证器和路由器是否已看到预期结果。

状态本身不执行路由政策。网络可以按明确配置拒绝、降低优先级或继续接收 Invalid；对 NotFound 也有各自的处理方式。RFC 8481 澄清，设备不得仅因计算出某种验证状态就在没有运营者配置的情况下自动套用过滤政策。运营者仍需用常规入站与出站过滤、路由选择和其他控制限制路由。

新 VRP 到达时，设备还要重新评估受影响路由。RFC 9324 建议设备不要仅因收到新 RPKI 数据就向邻居请求路由刷新；实现必须保留完整的 Adj-RIB-In，或至少保留因 ROV 丢弃的路径，以便在本地重新评估。若设备向多个邻居请求刷新，响应到达顺序不同还可能导致最佳路径选择和出站通告反复变化。

起源检查也可以放在向邻居发送路由的出站阶段。此时必须按出站政策和 AS 路径改写之后的有效起源 AS 判定；例如移除私有 AS 或处理联盟路径，都可能改变最终呈现的起源。RFC 8893 补充了这类出站验证要求。

maxLength 把一条前缀授权延伸到允许的更具体前缀长度。例如，授权 203.0.113.0/24 且设 maxLength 为 26，表示指定的 AS 可以宣告该 /24 内长度为 /24、/25 或 /26 的前缀；/27 超出授权。若省略 maxLength，授权只覆盖精确列出的前缀。该字段只扩展这一 AS 可宣告的前缀长度，不会授权另一个 AS。

宽泛的 maxLength 会让更多具体路由通过起源检查。若攻击者在公告中伪装成该 ROA 已授权的起源 AS，且前缀长度落在许可范围内，起源验证就可能把公告判成 Valid；互联网上的最长前缀选择随后仍可能把流量导向错误位置。也就是说，起源验证不能识别 AS 路径中途是否有人冒用获授权起源。RFC 9319 因此建议尽可能使用只覆盖实际宣告前缀的最小 ROA，并通常避免使用 maxLength。

运维中也存在需要预先授权的临时或备用路由，例如流量清洗服务在 DDoS 应对时替客户宣告更具体路由。此类授权需要提前传播，因为 RPKI 仓库更新未必赶得上紧急的 BGP 变更。可以将额外的 AS 与前缀范围单独、尽量精确地授权，并把额外开放的前缀空间视作明确的安全与响应速度取舍，而不是把整个地址块一概放宽。

RPKI 起源验证回答的是“这个前缀的起源 AS 是否在一条有效授权中”，不验证 AS_PATH 里的每个中间 AS，不证明端到端路径没有被修改，也不保证路由可达或性能良好。它不能替代运营者的路由政策和过滤规则，也不是 TLS 网站身份验证。把它作为一项起源授权信号，结合本地策略使用，才能准确理解它能解决的问题和留下的缺口。

• RFC 6480，架构与资源授权：https://www.rfc-editor.org/rfc/rfc6480.html
• RFC 9582，当前 ROA 对象规范：https://www.rfc-editor.org/rfc/rfc9582.html
• RFC 8210，RPKI 到路由器协议：https://www.rfc-editor.org/rfc/rfc8210.html
• RFC 6811，前缀起源验证与 VRP 状态：https://www.rfc-editor.org/rfc/rfc6811.html
• RFC 8481，起源验证的政策澄清：https://www.rfc-editor.org/rfc/rfc8481.html
• RFC 9324，基于 RPKI 的政策与路由刷新：https://www.rfc-editor.org/rfc/rfc9324.html
• RFC 8893，BGP 出站起源验证：https://www.rfc-editor.org/rfc/rfc8893.html
• RFC 9319，maxLength 的最佳实践：https://www.rfc-editor.org/rfc/rfc9319.html