总结

  • LACNIC 将 ROA 描述为把 IP 前缀与获准发起该前缀的自治系统联系起来的签名对象；托管式 RPKI 使成员无需自行运行证书颁发机构也能使用该体系。
  • **BTW 分析：**只有当 ROA 与 BGP 公告保持一致、变更效果得到核验、起源验证以可观测且冗余的方式部署时，这项控制才真正产生运营价值。

来源：LACNIC RPKI 常见问题、RPKI 最佳实践、RPKI 十五周年回顾及 RPKI 与 IRR 常见问题。

起源授权的范围本来就有限

LACNIC 把 RPKI 解释为一种公钥基础设施：服务提供商可利用相应的加密材料，核验客户对特定互联网号码资源的使用权。路由起源授权把一个或多个 IP 前缀与获准在 BGP 中发起这些前缀的自治系统连接起来。

这是一项精确的控制，却不是对整条路由的全面认证。LACNIC 的常见问题明确指出，RPKI 不取代互联网路由注册库；IRR 仍提供按 ASN 登记策略等功能。LACNIC 2026 年的回顾也把系统早期解决的路由起源验证，与验证路由路径其他环节这一更复杂的问题区分开来。

托管服务降低了基础设施门槛

LACNIC 支持托管式和委托式 RPKI。采用托管模式，成员无需自行维护证书颁发机构即可执行 RPKI 相关操作。这减少了一项基础设施负担，但不会替成员决定 ROA 应覆盖哪些前缀和起源 ASN。

**BTW 分析：**这个边界把注册局支持的授权与网络执行分开。LACNIC 可以运营认证基础设施并发布操作指南；资源持有者仍对 ROA 的准确性负责，而网络运营者则决定经验证的起源数据如何影响路由。

控制质量取决于变更纪律

LACNIC 的最佳实践建议，ROA 应尽可能只覆盖实际在 BGP 中公告的前缀；它提醒运营者谨慎使用过宽的 maxLength，在创建或修改 ROA 后检查是否出现无效路由，并为冗余运行多个验证器。

对于刚开始部署路由起源验证的网络，该指南给出渐进路径：先监测有效性状态，再给公告打标签或调整优先级，待配置有足够把握后才丢弃无效公告。

这套顺序揭示了操作逻辑。RPKI 提供一种结构化方法来区分获授权与未获授权的起源，但其效果依赖日常维护、可观测的变更和恢复路径。即使所有加密签名均有效，过时或过宽的授权仍可能削弱控制。

证据没有证明什么

本篇引用的材料并未证明每个 LACNIC 成员都实现完整 ROA 覆盖，也未证明每个网络都会丢弃无效路由，更未证明有效起源必然可达或具备端到端安全。它们支持的是更有限的结论：LACNIC 提供了证明和验证路由起源授权的基础设施与运营指南。