摘要

  • RIPE 2026-02 仍处于讨论阶段，并非现行政策。草案以滚动 30 天内累计 14 天出现在获准基础设施黑名单上，作为启动行政程序的门槛。
  • 第 3.4 条把移出名单或经核实的行政隔离列为初步整改方式；第 3.6 条恢复限制时则写作移出名单，或在涉及 RPKI 时删除“适当的 ROA”。
  • ROA 证明资源持有人授权某个自治系统宣告特定前缀。单凭这一授权记录，无法证明钓鱼、恶意软件、DDoS 或垃圾邮件运营已经终止。

一条程序链，三类证据问题

RIPE 社群刚刚开始讨论一项针对基础设施级网络滥用的政策提案。官方页面显示，1.0 版于 2026 年 10 月 13 日发布，讨论期持续到 11 月 11 日。截至本文截点，公开资料没有显示该提案已获采纳、进入实施，或已有案件按此流程处理。它描述的是拟议义务，不是 RIPE NCC 正在执行的现行措施。

草案列出四类持续性的基础设施活动：DDoS 命令与控制架构、系统性恶意软件托管或分发网络、钓鱼网站部署网络或托管农场，以及系统性自动化垃圾邮件僵尸网络。它将这些情形与个别消费者设备受感染区分开来，并排除由资源持有人或全球路由注册机构指定的住宅及动态用户地址池。

这个范围界定是重要的设计选择。草案还试图先建立一套可复核的材料链：受影响的网络运营商或国家级计算机应急响应组织（CERT）提交 RIPE NCC 支持工单；工单附有来自获准基础设施黑名单的可验证自动化遥测，以及时间戳或密码签名。第 3.1 条再要求，相关前缀在滚动 30 天内累计 14 天出现在获准名单上。名单注册将由 Security Working Group 管理，要求遥测具备客观、自动化特征，排除住宅和动态网络，并保留公开可验证的历史档案。

之后的程序分别涉及三个证据节点，不能把它们当成同一件事：

阶段 草案写明的记录或操作 可以说明什么 单独不能说明什么
启动 滚动 30 天内有 14 天在获准黑名单上，并收到经认证的通知 某个地址在规定窗口内出现在特定名单 地址是否正确对应资源持有人，或哪项措施使活动停止
初步整改 将所涉前缀移出名单，或经核实采取行政隔离 名单状态发生变化，或在整改期限内执行了隔离动作 谁以何种方法核实隔离，以及名单条目为何消失
恢复状态 移出名单，或在涉及 RPKI 时删除“适当的 ROA” 名单发生变化，或路由起源授权记录发生变化 被举报的运营是否终止，以及该 ROA 为何是相关补救措施

问题不在于黑名单毫无价值，也不在于持续性的举报绝不应触发行政响应。问题是：流程在起点、整改和恢复时分别测量什么。第 3.1 条依据名单历史启动流程；第 3.4 条既接受名单变化，也接受经核实的隔离；第 3.6 条回到名单，另加入一个路由授权对象。它没有说清最后一种做法是在证明隔离、修正起源路由方面的指控，还是提供一条独立的行政通道。

ROA 能回答的问题更窄

RFC 9582 规定了 Route Origin Authorization（路由起源授权，ROA）的用途：依赖方可以据此核验，地址块持有人是否授权某个自治系统为列出的前缀发起路由。这种关系对路由安全很重要，但它不描述这些地址上运行着什么服务、产生了何种流量、主机是否遭到入侵，也不记录运营者是否在收到举报后隔离了系统。

如果举报针对未经授权的路由起源，或路由授权本身就是所称滥用机制的一部分，RPKI 确实可能相关。此时，明确前缀、起源自治系统、ROA 与通知之间的对应关系，可能让删除或替换某项授权成为有意义的控制措施。但提案列出的四类威胁并非都属于起源路由问题。钓鱼托管农场完全可能通过已获授权的路由对外可达；存在一份 ROA，并不能说明它促成了被举报的活动。

草案留下两处关键空白：“涉及 RPKI”具体指什么？如果资源持有人拥有多个前缀、起源自治系统或授权对象，哪一个才是“适当的 ROA”？答案会决定运营者被要求修改什么，也会决定 RIPE NCC 凭何种依据撤下公开的不合规状态。

删除 ROA 改变的是一项授权记录。结合其他授权数据和各网络的本地路由策略，它可能影响部分网络如何评估某条路由；现有来源不足以支持一个适用于所有网络的统一结果。更重要的是，这些可能的路由变化本身都不能证明黑名单所指的服务行为已经停止。相关服务可能仍在运行，路由也可能从其他路径宣告；持有人也可能因与举报无关的原因删除 ROA。不能把 RPKI 对象的存在当成案情说明。

abuse-c 联系政策回答的是另一道题

RIPE-705 管的是联系层：为相关资源记录规定 abuse-c 属性，要求有可接收举报的邮箱，并依据既有政策和程序进行年度验证与跟进。RIPE NCC 对 abuse-c 的说明也把它定位为帮助举报送达适当资源持有人的渠道。

把报告送到正确邮箱，并不等于认定其事实成立，也不证明运营者隔离了某个前缀，更无法决定之后应该采取哪种注册层面的限制。2026-02 提案拟增加另一条行政链：向法律、行政和账单联系人发送电子通知；从确认送达起提供七个工作日整改；如未满足条件，再施加中间限制，并在 RIPE 数据库公开“滥用不合规”状态。

草案表示，希望保留资源分配，避免立即断网；其论证也承认，具体限制需要社群通过另一份 RIPE 文件达成共识。即使分配记录还在，公开状态仍可能被第三方工具或合作方引用。因而需要知道它由什么材料支持，如何更正，以及何时有记录表明它已撤下。

提案论证把持续不整改称作合同义务违约。这属于提案方给出的理由，并非已经确立的法律结论。RIPE 政策制定程序仍在开放讨论中，以共识为基础。眼下更具体的操作问题是：状态每改变一次，应附上什么证据？

为每份通知保留一张证据收据

流程可以保留现有阶段，同时为每个案件建立一份可追溯的证据收据，而不公开敏感遥测。收据应把通知编号、准确前缀、名单版本与历史、观测日期、资源持有人归属、隔离动作及其核验者连接起来；若路由属于指控机制的一部分，还应记录相关 ROA。送达时间、整改期限、限制措施、纠正动作和恢复时间也应留档。

这样可以把四个问题分开：观察到了什么行为；当时存在什么起源授权；采取了什么遏制措施；RIPE NCC 发布了何种行政状态。如果举报针对路由起源，ROA 的变化可以是响应的一部分，但仍应有材料说明问题随之发生了什么变化。如果举报针对托管服务，没有证据关联的 ROA 删除就不应被视为隔离证明。

某个地址从名单中消失，也可能是因为活动停止、名单纠正了错误、评估标准变化，或观测窗口已经结束。这些原因对资源持有人意味着不同的事。公开历史档案有助于重建时间线，却不一定解释条目为何被移除。

RIPE-781 将政策制定划分为四个开放阶段，以共识形成决定；RIPE NCC 提供行政支持，包括影响评估和实施工作量分析。因此，讨论可以检验的并不只是 14 天门槛，还包括地址如何关联到持有人、行为如何关联到授权对象，以及整改如何关联到公开状态的撤下。

这项提案刚刚开启讨论。它最明确的边界，是把对象限定为持续性基础设施活动，并排除住宅和动态用户池。证据设计上的缺口则更窄：流程以名单记录起步，在初步整改时接受隔离，到恢复阶段却又加入另一个对象。在二者关系明确之前，删除 ROA 能证明的是一项路由授权发生了变化；仅凭这一点，还不足以结案。

来源