摘要

  • 2023 年 10 月，ARIN 开始在 ROA 被删除时通知 Admin、Tech 与 Routing POC；2024 年 6 月，又把一个组织可删除 ROA 的上限从 20,000 提高到 40,000。
  • ACSP 2025.6 要求批量删除时可关闭该次调用产生的全部邮件；ACSP 2026.6 则指出，创建和修改 ROA 并不会向全部 POC 发出同类通知。
  • 邮件过载确实需要解决，但“删除”并不是风险的可靠替身。新增或改写一项授权，也可能改变某条 BGP 公告被判为 Valid、Invalid 或 NotFound 的证据条件。
  • 最小而有效的控制，是让每笔已提交事务只生成一份持久的授权变更摘要：谁以什么权限操作、前后状态如何、事务是否整体成功、何时观察到发布，以及哪个独立渠道收到了通知。

两份建议，指向同一个粒度错误

第一份建议希望少发邮件，第二份建议希望多覆盖动作。它们并不真正矛盾。

ACSP 2025.6 提交于 2025 年 7 月 11 日。提议者说，大型 IP 地址管理者可能维护很长的 POC 名单；批量删除 ROA 时，团队要提前提醒同事会收到大量邮件，ARIN 的邮件服务器和收件人的邮箱也要承担负担。建议是在删除 API 中加入一个可选标志，默认保持现状，启用时则不为那次调用生成任何邮件。

ARIN 在 7 月 23 日答复，这项功能有益，会列入开发日程并加以优先考虑。冻结资料时，页面仍标为 Open，等待实施。这说明需求已被接受进入规划，并不说明开关已经上线，更不能据此猜测最终字段或默认行为。

ACSP 2026.6 在 2026 年 4 月 23 日把另一半问题写了出来：当前 ROA 被移除时，ARIN 会向全部 POC 发送站内及邮件通知；创建或修改 ROA 时却没有同样做法。它要求对创建、修改和删除分别提供可选通知，或为 ARIN Online 账户设置全局偏好。

四天后，ARIN 表示会把这项增强与其他待办的 ROA 通知改进归为一组，交给内部优先级和实施规划流程，并关闭建议。这里的 Closed 是 ACSP 工单状态，不是生产功能的验收单。

一份建议反对大量重复消息，另一份建议反对动作覆盖不完整。共同的问题是：系统把“通知多少封”当成“保留多少证据”。真正需要观察的不是邮件数量，而是一笔授权事务把路由证明从什么状态改成了什么状态。

删除值得告警，但理由不是那个动词

ARIN 的现有规则有充分的防守理由。2023 年 10 月 9 日的软件发布记录显示，ARIN Online 开始在 ROA 被删除时通知 Admin、Tech 和 Routing POC。执行 API 的账号、负责组织关系的管理员和实际值守的路由团队可能并不是同一个人。把信号推送给操作人之外的角色，可以较早暴露误操作、交接遗漏或凭据被滥用。

删除本身也有技术后果。ROA 是前缀持有者对某个自治系统发起这些路由的签名授权。RFC 8211 说明，当 ROA 从发布点消失时，前缀与 AS 之间的可验证绑定随之失效。若没有其他覆盖该前缀的 ROA，原先受支持的路由可能变成 NotFound；如果剩余的覆盖 ROA 授权的是另一个 AS，则可能变成 Invalid。

“可能”必须保留。不同验证器看到更新的时间不同，网络也自行决定如何处理 Invalid 路由。资料没有证明任何具体删除导致断网。不过，这一机制足以解释为什么删除不能只留在操作者自己的会话里。

问题出在规模。ARIN 2024 年 6 月 3 日的发布记录把一个组织允许删除 ROA 的上限从 20,000 提高到了 40,000。这是配置上限，不是事故数量，也没有证明曾有组织一次删掉 40,000 项。它至少表明产品必须处理很大的变更集合。

如果每个对象都向每个 POC 发送一封邮件，消息量就是对象数乘以收件人数。一笔统一维护被拆成几万条重复警报，收件人很快会设过滤器、略过内容，或者把整批信息当作预先知道的噪声。形式上的覆盖增加了，实际注意力反而下降。

因此，提议减少邮件不是逃避问责，而是在指出现有信号单位不适合批量操作。

创建和修改同样会改变比较基准

把告警扩展到所有动作，也不能简单理解为“再多发两类邮件”。在路由源验证中，新增 ROA 并不天然安全。

假设一个新的覆盖 ROA 授权了某个 AS。原本没有覆盖 ROA、因而是 NotFound 的其他公告，如果来源 AS 不符，或者公告长度超过 maxLength，就可能转为 Invalid。修改 ROA 时，授权 AS、前缀范围或 maxLength 的变化，也可能缩小、扩大或迁移实际授权集合。

所以，数据库里的 add 不等于路由世界里的“只增加保护”，delete 也不等于“必然失去可达性”。判断材料性必须比较两个集合：事务前哪些“前缀—来源 AS—最大长度”组合有效，事务后哪些组合有效。

ARIN 的现行 API 已经提供了合适的边界。RPKI RESTful 指南把创建、修改和删除 ROA 设计成组织级统一调用；同一事务还可以合并 ASPA 变更，并且整组操作要么全部成功，要么全部失败。payload 中有待删除列表和待新增列表。

原子性是一项很强的保护。它避免“旧授权删了、新授权没加上”这类半完成状态。更重要的是，系统本来就知道这些对象属于同一意图、同一提交和同一结果。告警若把它们重新拆散，反而丢掉了最有价值的上下文。

ARIN 已经拥有一份重要的事后记录

不能把 ARIN 描述成没有日志。2025 年 9 月上线的 ROA Change Log 覆盖过去 365 天。现行文档列出的字段包括时间戳、Added 或 Removed 操作、Web User、API User 或 ARIN System 来源、Origin AS、前缀、maxLength，以及作出变更的 ARIN Online 用户姓名。超过 100 条会分页；完整 CSV 可提交工单申请，ARIN 处理后供下载。

这是一项实质性的审计能力。现有证据没有显示它不准确、可被普通用户篡改或无法访问。任何新的建议都应当从这份日志出发，而不是为了强调缺口而否认已有能力。

但“有地方可以查”和“有独立渠道主动提醒”对应不同故障。日志需要授权用户主动登录并检查；通知会打断另一个人或系统，告诉它现在值得检查。如果发起事务的账号本身有问题，独立观察就尤其重要。反过来，如果独立渠道只收到几万封没有共同标识的邮件，独立性还在，上下文却碎了。

最合理的做法，是把日志的精确字段与通知的独立性合在一起。

让一笔事务只说一次，但把话说完整

每笔成功提交的 RPKI 事务都可以生成一份持久摘要。它不是公开展示员工资料的公告，也不是要求所有 POC 会签的审批单，而是组织内部可保存、可转发、可关联的证据对象。

摘要字段 它回答的问题
事务标识与完成时间 哪次请求在何时真正提交
组织与受保护的操作者类别 操作基于哪一类授权，而不必公开个人资料
动作组合 是创建、替换、删除，还是连同 ASPA、IRR 一起变化
授权前后差异 哪些 prefix、origin AS、maxLength 绑定发生改变
原子结果 整组成功、失败，还是没有提交
发布观察状态 新状态是否已在 RPKI 仓库中被观察到，还是仍待确认
独立收件渠道与送达状态 除操作者之外，哪个安全渠道确实收到摘要
纠正链接 后续哪笔事务撤销或替代了本次变化

偏好设置可以围绕这份核心记录发挥作用。有人需要逐对象详情，有人只要每笔事务一封邮件，网络运营中心可能选择 webhook，低风险动作也可以按时段汇总。紧急纠错不应等所有 POC 批准：通知不是授权，确认收到也不是否决权。

不可让渡的底线更薄：便利性开关可以关闭重复邮件，但不能同时抹掉持久记录和所有由独立管理员控制的信号。

证据到哪里为止

这里没有 40,000 项删除事故，没有已确认的失窃账号，没有通知故障，也没有可归因的路由中断。ACSP 2025.6 仍在等待实施；2026.6 的关闭也不等于上线。Change Log 被文档明确描述，不能无证据地称为不可靠。ARIN 更不会替全球网络决定是否拒绝 Invalid 路由。

资料证明的是更窄的一点：ARIN 已有能够表达整体意图的原子事务，也有包含操作者和对象字段的 365 天日志；推送告警却主要跟随删除动作，公开改进建议又在“扩大通知”与“完全静默”之间摇摆。把单位从对象改成事务，无需等待事故，就能把这道边界画得更准确。

来源