摘要

  • APNIC在APNIC 62上说明，其托管ASPA界面会依据RIPE RIS给出上游建议。这些建议带有概率性质，需要人工审查，而且更容易多列而不是少列。
  • 界面还会检查提交的改动将如何影响已观测到的BGP路径。这能发现当下冲突，却不是对所有未来路径的演练。
  • IETF现行ASPA验证草案建议提前写入备用或应急上游，以免RPKI对象分发赶不上路由传播。可是，真正处于待机状态的上游本来就不该有一条现成路径供系统观察。
  • APNIC应保存一份“来源—场景凭证”，把观测建议、人工声明、排除项、当前路径检查和未被演练的故障切换明确分开。

一张简短名单，先要回答一个很长的问题

ASPA对象的外形很简单：一个客户ASN，一组获准充当上游的ASN。资源持有人签署对象，RPKI负责分发，验证器再用它判断AS_PATH里的客户—上游关系。密码学可以证明对象来自有权签署的一方，却不会替这一方决定名单是否完整。

APNIC的产品设计正试图减少这个决定里的盲区。在APNIC 62 Routing Security SIG的更新中，APNIC说托管界面使用RIPEstat的asn-neighbours端点生成建议，数据来自RIPE Routing Information Service。类似的建议机制已经用于路由对象管理。APNIC没有把算法包装成确定答案：演示文稿明确称其为概率性建议，要求用户审查，并指出它们更可能“多收”而不是“漏收”。

第二道护栏是在提交前检查变化。界面会把拟议的上游集合放到已观测的BGP路径旁，查看现有路径会受到什么影响。如果运营者误删了当前路径中确实出现的上游，系统有机会在对象发布前提醒。若算法提出了一个可疑邻居，人工也能先判断它到底是上游、下游、对等体还是别的角色。

这是一种负责的自动化：机器提供线索，人承担授权判断。不过，它天然止步于可见世界。平时不承载流量的DDoS清洗上游、只在链路中断时连接孤立区域的应急上游，或者冷备的第二转接，都可能不出现在日常BGP路径中。沉默不是故障，沉默就是采购这种服务的一部分。

RIS看到邻接，运营者才知道角色

RIPEstat对其数据边界写得相当清楚。ASN Neighbours端点返回RIS观察到的相邻ASN，并可提供邻居位于目标ASN左侧还是右侧、出现于多少条路径、被多少个全表对等方看到，以及查询时间或结果有效区间。某个左侧邻居若只因直接连接RIS采集器而出现，还可能被标成uncertain。

这些字段能让一条建议接受复核，却不能把它升级成商务关系证明。AS路径上的相邻ASN可能是上游、客户、横向对等体、不透明路由服务器，或者在不同地址族与前缀集合中承担不同角色的复杂邻接。RIS看到的是采集点所能看到的路由；它看不到一份尚未激活、尚未产生公告的应急协议。

因此，“偏向多列”并不是缺点。宁可让运营者删除一个误判的对等体，也不要悄悄漏掉一个活跃上游，导致发布后的授权集合与现网路径相冲突。然而，这一统计倾向不能变成完备性承诺。再全面的今天，也不会自动包含一条计划在明天启用的关系。

合格的界面至少要保留两种来源。第一种是观测事实：某ASN在某个RIS时间窗里与客户ASN相邻。第二种是责任声明：资源持有人确认某ASN有权充当上游，其中也包括今天不活跃的安排。把两者塞进同一个没有来源标记的勾选框，会同时削弱测量和授权。

IETF草案要求在路径出现之前行动

冻结的IETF材料把这个矛盾写成了一个时间问题。ASPA Profile第29版提出，一个Customer AS应维护一份包含全部上游的ASPA对象，必要时也包括不透明路由服务器。单一、完整的对象有助于避免更新过程中的竞态。

ASPA验证草案第28版更直接地谈到备用上游。它举出两类场景：临时接入DDoS缓解服务，以及用应急上游连接被隔离的网络部分。草案建议预先把这些上游加入ASPA，防止全球RPKI分发与BGP路由传播互相赛跑。

这恰好生成了一项“当前路径检查”无法完成的测试。故障切换之前，没有应急路径可供观察；故障切换之后，才开始发布授权可能已经太晚。正确决定必须落在一个特殊区间：授权和计划已经存在，生产路径尚不存在。

这与既有的一条常识并不冲突。ASPA中的一个上游不能证明它今天正在提供转接；反过来，今天看不见这条转接，也不能证明它不该被预先授权。一个是防止把授权误读成观测，另一个是防止把缺少观测误读成缺少授权。

这里没有理由声称APNIC发生过错误。公开演示没有报告失败切换、被拒路由、错误建议或遗漏的备用上游，还主动征求对建议与验证功能的反馈。公开材料也没有展示界面内部保存的全部字段。IETF文本仍是可修改的Internet-Draft，不是最终RFC。文章能得出的结论更窄：产品描述的检查覆盖已观测路径，而当前标准工作建议维护一种在定义上可能尚未被观测的授权。

“当前无冲突”不是“备用方案已通过”

设想一个客户ASN日常使用上游A和B，并与C约定在攻击发生时提供清洗服务。RIS看到A和B，也可能在部分路径中看到对等体D。界面建议A、B、D；运营者删除D，手工加入C。

系统能做很多有价值的事。它可以发现删除A会影响现有路径，可以提示B只在IPv6观察中出现，也可以揭示D来自带不确定标记的采集器邻接。最终，它可以如实说：“在本次检查的当前路径集合中，没有发现拟议名单造成的冲突。”

它不能据此说C会在危机时发布正确前缀、维持预期AS路径、具备足够容量，或者一定在新对象到达所有依赖方之后才启用。即使实验室里模拟过，也不等于真实攻击场景已经得到保证。

绿色结果并不因此失去价值。相反，边界清楚才让它可用。危险来自它离开页面之后：工单里一句“ASPA验证通过”，可能被一名工程师理解为对象格式正确，被另一名理解为当前路径兼容，又被管理层理解为故障切换已经演练。三句话需要三套不同证据。

给不存在的路径留一份凭证

补救不需要公开成员合同、链路编号或DDoS处置手册。一份默认留在MyAPNIC或成员内部变更单中的小型凭证已经足够。

每个候选上游首先要有来源类别：RIS观测建议、人工添加的活跃上游、备用上游、应急上游，或不透明路由服务器。观测建议应绑定查询时间、端点版本或响应摘要、左右位置、不确定标记、路径数与观察对等方数。若被排除，只需记录有限理由类别，例如客户、对等体、透明路由服务器、采集伪影或有待调查，无需泄露商业条款。

人工加入的休眠上游应记录启用类型、涉及IPv4还是IPv6、责任岗位、最近一次桌面推演或实验时间，以及下次复核日期。“DDoS缓解”或“孤立区域重连”作为类别已经足够，不必写下拓扑和凭据。

当前路径检查则应保存观测窗口、被检查路径集合的摘要、拟议上游集合和结果。最重要的字段，是明确列出哪些已授权上游没有出现在本次观测中，因此没有被演练。它能阻止“没发现现网冲突”被改写为“所有方案都通过”。

最后还要连接发布环节：人工确认时间、最终名单、ASPA对象身份、仓库发布时间，以及从一个独立依赖方看到新对象的时间。若应急事件早于可见性，凭证应保留真实次序，而不是事后移动授权时钟。

APNIC已经在DASH中加入ASPA状态页面。那里很适合分别显示“已发布、当前可见、场景已复核、需要复查”，而不是用一个徽标概括全部状态。APNIC 62演示中的293个ASPA——其中257个托管、36个委托——只是一张采用情况快照，不是验证部署率、名单完备率或备用方案演练率。

界面可以警告，但不能替路由器做决定

IETF草案中的ASPA验证先判断有序ASN对，再判断路径。有效对象中的已列上游会得到正向证明，未列上游会得到否定结果，没有有效对象则属于没有证明。草案对Invalid和Unknown路径给出建议，但缓解政策仍由接收网络配置。

这条权责链不能被一个绿色图标压扁。RIPE RIS负责观测，APNIC负责建议、提示和发布，ASN持有人负责授权，验证器负责计算，接收网络负责采取何种路由动作。

备用上游之所以值得单独设计，就是因为其价值先于流量出现。APNIC已经让日常情况更安全。若再加入场景凭证，界面便能对例外情况同样诚实地说：它已获授权，目前未被观测，场景经过复核，发布在需要它之前已经可见。

来源