摘要

  • ASPA 把签名的客户—提供商关系加入 RPKI，使路径判断超出 ROA 的起源授权范围。
  • 发布与执行是两个状态：路由器必须收到验证结果、识别会话角色，并对 Invalid 路径执行明确动作。
  • 在渐进部署中，Unknown 是必须保留的不确定状态，不能当作 Valid 或 Invalid。

面板已经有记录，异常路由仍在表里

工程师在 RPKI 面板中看到新 ASPA，提供商列表正确、签名有效、仓库可达。随后把同一条刻意构造的 Invalid 客户路径发布到生产边缘；它仍被安装，因为生产导入策略没有消费验证器给出的 ASPA 结果。

这并不说明 ASPA 失效。对象已经完成了声明授权关系的职责；该测试明确隔离出的缺口，是生产导入策略没有据验证结果采取动作。

APNIC 将 ASPA 描述为 ASN 持有者签署的授权上游列表。ROA 能证明某起源可发布前缀，却不说明 AS_PATH 是否遵循提供商关系。IETF 当前工作定义的正是如何按客户、对等、提供商、路由服务器客户或 sibling 等接收关系验证路径。

因此，关键问题不是“对象是否存在”，而是接收路由器在当时证据下做了什么决定。

Unknown 必须被看见

渐进部署意味着很多路径包含没有 ASPA 的跳点。RIPE 的运营说明把它归为 Unknown，并在部分部署阶段接受。若把缺少声明都当作 Invalid，证据覆盖不足会变成可用性故障。

这也要求报告严格区分三个状态：Valid 表示现有声明支持路径；Invalid 表示现有声明与路径矛盾；Unknown 表示证据不足。把所有已接受路由称为“已验证”，会同时掩盖风险与渐进上线的安全机制。

ASPA 也不是完整的路由策略语言。IETF 草案指出，它不能阻止所有由本地 AS 发起的泄漏，并建议以 OTC 属性补充。密码学路径判定也不证明数据平面交付、流量工程意图或商业关系本身。