摘要

  • ASPA 是由客户 AS 发布的签名 RPKI 对象，用于授权一组提供商 AS。它证明的是供验证算法使用的关系声明，而不是逐跳签署整条路径。
  • 验证会依据可用对象和传播场景给出 Valid、Invalid 或 Unknown；这些结果不能替代起源验证、现实身份认证或运营者自己的路由策略。
  • 可靠运行需要一份观察与完整性账本，分别记录对象有效性、提供商集合、缓存时间、会话角色、验证结果、本地动作和未决不确定性。

路由安全面板上的 “Valid” 很容易被理解为完整保证。ASPA 的含义更窄：在相关传播方向上，所观察到的路径与算法能够检查的客户—提供商授权相容。这个结论有用，却不是一份对路径每一跳都签名的履历。

当前 ASPA profile 仍是 Internet-Draft。它定义了一种 RPKI 签名对象：客户 AS 号码的持有者列出获授权的提供商 AS。草案要求列全所有提供商，并期望每个客户 AS 只发布一个 ASPA。依赖方必须先验证对象，再使用其中的载荷。

因此，ASPA 回答的是一个限定问题：客户 AS 是否在已发布数据中授权了这个提供商 AS？对象不包含被通告的前缀。ROA 和路由起源验证负责起源授权，ASPA 负责路径中的提供商关系，两者是互补控制。

签名也不等于现实身份。RFC 9255 明确说明 RPKI 中的 “I” 不代表 Identity。有效对象支持号码资源授权结论，却不能证明两家公司当前存在商业合同、登记人员没有填错，或某条链路此刻确实承载流量。

完整性是第二条边界。验证草案期望客户 AS 登记所有提供商及相关的非透明路由服务器。如果漏掉合法提供商，随着验证覆盖扩大，真实关系上的路径也可能被判为 Invalid。密码学签名可以完全正确，而被维护的声明仍然不完整。

算法保留了这种不确定性。关系层面可能得到 Provider+、Not Provider+ 或 No Attestation，路径层面则可能是 Valid、Invalid 或 Unknown。Unknown 并不是把 Invalid 说得委婉，而是现有证明不足以下结论。Valid 也不证明每个 AS 都签署了路径、起源已获授权或全部出口策略得到遵守。

ASPA 与 BGPsec 的证据语义不同。ASPA 将路径与各方独立发布的提供商授权比较，并非逐跳路径签名。顺序也很关键。RFC 9774 弃用 AS_SET 和 AS_CONFED_SET，因为无序集合无法表达客户—提供商方向；ASPA 验证也无法从这种集合恢复所需语义。

RFC 9234 的 BGP Roles 为路由泄漏判断提供会话关系背景，但协商出的 capability 并不是通用商业记录。收到结果的运营者仍需决定 Valid、Invalid 和 Unknown 如何影响本地选路、可达性和例外。

一份可审计账本至少要分开六类记录：经过验证的 ASPA 对象；提供商清单完整性的复核依据；依赖方的载荷哈希与观察时间；有序路径、会话角色与观察点；带原因的算法结果；本地动作、负责人、例外和到期时间。

这些记录的时间不能合并。周五新增提供商、周六更新 ASPA、周日缓存才刷新，是三个不同状态。复盘时必须使用路由被接收当时可见的对象和观察，而不能只看事后修正的数据。

本文引用的两份 ASPA 文档仍可能在成为 RFC 前变化，且本文不指称任何真实网络发生事故。长期有效的治理原则是：ASPA 是范围明确的提供商授权。把有效性、完整性和使用动作分别留证，才能避免把一个信号夸大为整条路径的证明。

来源