摘要

  • LACNIC在7月20日宣布FORT 1.7.0可以验证ASPA对象并把信息提供给路由器，同时明确指出ASPA尚未正式发布为标准，因此该功能仍属实验性。
  • 对应的1.7.0.experimental版本把--server.max-rtr-version默认设为0，而同版本文档说明只有RTRv2才加入ASPA；独立的--output.aspa文件输出也默认关闭。
  • 可审计的启用记录应把已发布代码、本地配置、实际协商版本、通过验证的对象、路径判定与路由策略动作拆成不同事件。

这次发布最值得注意的数字不是1.7.0，而是0。

LACNIC博客称，新版FORT可验证一些RPKI仓库中已经出现的ASPA对象，并把相关信息提供给路由器，以支持更好的路由决策。提前四天发布的GitHub版本给出了更完整的名称：1.7.0.experimental。它实现了ASPA和RTRv2，但服务器愿意协商的RTR最高版本默认仍为0。

博客陈述的是“能做什么”，发布说明陈述的是“在操作员作出选择之前会做什么”。两者可以同时成立，也都不能证明任何具体网络已经怎样配置。

现有证据不支持“LACNIC隐瞒实验状态”的说法。博客明确写道，ASPA尚未正式成为标准，仍可能变化。项目也解释了保守默认值：FORT当前不产生Router Key，因而RTRv1在此实现中没有新增载荷；RTRv2规范还在更新。问题不是把谨慎写成缺陷，而是能否从已安装二进制一路追踪到路由结果。

一项功能背后有三道开关

与发布标签绑定的FORT使用文档列出了三类不同控制面。

配置 默认值 控制对象
--aspa.max-providers 4,000 一个客户ASN在一次验证周期内可声明的提供商ASN上限
--output.aspa NULL，关闭 是否把有效ASPA写入JSON文件或标准输出
--server.max-rtr-version 0 FORT服务器与客户端协商的RPKI-to-Router最高版本

第一项限制验证输入，第二项打开文件出口，第三项打开面向路由器的协议。启用其中任何一项，都不会自动启用另外两项。

文档同时说明了载荷边界：RTRv0提供前缀VRP，RTRv1增加Router Key，RTRv2才增加ASPA。因此，在默认配置下，FORT仍可在内部验证ASPA；若另行指定文件，也可输出JSON；但协商在版本0的路由器会话无法收到版本2的ASPA PDU。

这不等于“所有路由器都收不到ASPA”。操作员可以把上限调到2，并与兼容客户端建立v2会话。这里能够证明的只是软件出厂状态，而不是地区部署率。

协商结果本身就是证据

现行RTRv2草案第27版要求路由器以自己实现的最高版本发起查询。缓存支持该版本时，会话在该版本建立；只支持较低兼容版本时，可以降级。降级完成后，高版本功能在该会话中不可用。

所以，把配置写成2只证明意图。客户端还必须实现并请求v2；会话必须实际在v2完成；缓存必须送出相关ASPA；路由器必须形成路径状态；本地策略还必须决定是否改变可选路由。

一条链可能在多个位置断开：运行了错误包、对象未通过验证、文件出口关闭、服务器上限未提升、客户端只协商低版本、相关客户ASN没有可用对象、结果是Unknown而非Invalid，或者策略只监测而不处置。把这些状态都叫作“ASPA已开”或“ASPA没用”，只会掩盖真正的故障域。

对象有效不等于路径有效

ASPA对象规范第29版定义了客户ASN持有者签署的提供商授权对象。Relying Party先验证签名、证书与内容，这一步产生可用的授权数据，却没有判断某条BGP AS_PATH。

ASPA路径验证第28版才产生Valid、Unknown或Invalid。草案建议使Invalid路径失去路由选择资格，把Unknown与Valid置于同一优先级；但具体缓解策略仍由网络操作员决定。

因此，有效对象数量衡量的是验证器；v2会话衡量的是传输；三类路径计数衡量的是计算；RIB、FIB和策略记录才说明实际动作。收到一份授权数据，并不自动等于拒绝一条路由。

反过来，也不能把v0解释为“什么都没有做”。旧版本仍传递源验证数据，文件输出还可用于实验。准确结论是：FORT交付了实验性ASPA能力，而把传输与执行交给了明确的后续选择。

草案版号属于软件身份

标签文档说明，FORT的RTRv2实现依据8210bis第25版。截至调查日，现行文本已到第27版，ASPA对象规范是第29版，路径验证则在8月24日更新到第28版。

版号差异本身不能证明不兼容。更新可能只是文字修订，也可能包含行为变化，必须通过差异审查与互操作测试判断。它能够证明的是：对实验性实现，只写“支持RTRv2”无法复现结果；还要记录具体草案、代码commit、构建包和测试对端。

RFC 8210仍是版本1的正式规范，ASPA PDU属于尚在推进的版本2工作。这正是默认值保持谨慎的理由，也是日后调整默认值时必须保留迁移证据的理由。

下载量不能代替这条链。下载不等于安装，安装不等于运行，运行不等于v2会话，会话也不等于缓解动作。

一张发布能力卡，一份本地启用凭证

项目可公开能力卡，无需收集私有网络遥测。它应记录标签和commit、软件包与哈希、ASPA规范/RTRv2/验证算法的具体版本、默认值和范围、已知偏差、已测试客户端、替换与回退路径。

操作员保存启用凭证：安装包哈希、进程启动时间与配置指纹；RTR上限；按协商版本汇总的客户端数量；验证周期时间；按原因分类的ASPA接受与拒绝量；文件输出状态与哈希；验证模式；路径状态计数；缓解策略、例外与回滚。

路由器身份和拓扑无需公开。对外可以只披露不敏感的汇总；审计或事件响应时再核验完整本地记录。

两份记录应以软件包哈希、实现草案版本与配置指纹连接。缺少这些键，发布页只描述可能行为，运行报告只描述一个无名进程；连接之后，才能证明被审查的能力确实跨过了启用边界。

证据的边界

现有资料没有告诉我们多少网络安装了版本、修改了0、协商了v2、验证了多少相关对象或拒绝了哪条路由。它不能证明LACNIC的公告虚假，不能证明默认值必须是2，也不能证明第25版与第27版不兼容。

ASPA也不是全部BGP安全。它提供客户—提供商授权证据并支持路由泄漏检测，却不验证转发平面，不消除Unknown，也不取消本地路由权。

资料足以证明四件事：FORT 1.7.0.experimental实现了ASPA和RTRv2；面向路由器的上限默认为0；ASPA文件输出默认关闭；最终缓解由操作员决定。与其问“是否支持ASPA”，不如问：哪个构建、哪版草案、哪个出口、哪次协商、哪类状态、哪项策略？

来源