摘要

  • RIPE NCC 为 RIPE 93 发布的 RPKI 更新摘要称，初步分析发现 ASPA 对象漏列多达 10% 的提供者 ASN；原因包括遗忘上游，以及把兼任上游的邻居当成纯对等方。
  • RIPE NCC 的 ASPA 指南明确指出：已签发对象若漏列提供者，经该提供者传递的路由可能被拒绝；目前仪表板也不给出从 BGP 观察得来的提供者提示。

错误不是密钥，是那张关系表

有些错会被密码学包得严严实实。自治系统持有人签发 ASPA，RPKI 验证器确认签名有效，提供者列表却少了真正承载流量的上游。验证器能证明这张表是谁写的；它无法替运营者补上那一行。

RIPE NCC 的 RIPE 93 RPKI 更新摘要 给这个问题添了一个数字：初步分析显示，ASPA 对象中多达 10% 的提供者 ASN 被漏列。这里计的是提供者 ASN，不能改写成“十分之一的网络出错”或“十分之一的 ASPA 对象不完整”。摘要点出两种来路：上游被忽略，或原本被当成对等方的邻居实际上也扮演提供者角色。

后一种更难靠旧表格发现。一次 BGP 会话在联系人名单里写着“peer”，商业和技术安排却可能让邻居在某些路径上提供上游服务。RIPE NCC 的 ASPA 指南 要求列入全部上游提供者、兼有提供者角色的复杂邻居，以及在 AS 路径上以提供者身份出现的非透明路由服务器。纯横向对等方和客户则不该混进来。运营人员要判断的是角色，不是通讯录里的称呼。

漏掉一个名字，判断就变了

指南把一条 AS 邻接关系分成三种结果。客户 AS 签发了 ASPA，且把对方列为上游，得到 Provider；签发了对象却没列出对方，得到 Not Provider；没有签发对象，得到 No Attestation。空白和漏项并不等价。签名清单一旦不完整，就可能把真实上游写成一条明确的负面证据。

RIPE NCC 因此警告，经漏列提供者传出的路由可能遭到拒绝。是否真的被丢弃，还取决于具体 AS 路径、接收网络是否启用 ASPA 验证，以及它怎样设置过滤规则。摘要没有公布事故或丢包统计；当前需要做的判断已经足够明确：在放紧过滤器之前，把已签对象同转接协议、实际会话角色和路由服务器安排逐项对照。

RIPE NCC 说本次更新将讨论更好的 ASPA 提示；现行仪表板还不会把 BGP 所见的上游候选呈给持有人。提示如果出现，应带着时间和路径证据，让运营者判断邻居到底承担了什么角色。看到相邻 AS，不等于自动读懂合同。

这个百分比还缺一页方法

官方摘要没有给出样本范围、观察时段、分子分母或角色判定方法。一份带日期的测量报告会说明“多达 10%”究竟覆盖哪些对象。持有人现在能做的事更直接：把 ASPA 清单放在正在运行的网络旁边看，而不是只看签名状态灯。

登记机构提供可信的署名；提供者清单的真实性，要由网络里真正承担上游角色的人来核对。

来源：RIPE 93 RPKI 更新摘要；RIPE NCC ASPA 指南；IETF ASPA 验证草案第 29 版。