摘要

  • IESG 9 月 24 日议程列入 draft-irtf-nmrg-ai-challenges-06 的 RFC 5742 冲突审查。这是 IRTF 网络管理研究组拟以 Informational 类别发表的研究文件，不是互联网标准。
  • -00 答复原拟写“无冲突”，并附加对抗性攻击与不安全输出的备注；9 月 24 日的 -01 保留拟议主结论，删去备注。Datatracker 仍标示 IESG Evaluation，且有 DISCUSS 待解决。
  • 草案第 9.2 节分析针对 AI 本身的攻击，第 9.3 节分析 AI 造成的危险操作。前者的防护证据不能自动证明后者的执行边界可靠。

把自动化变更挡在机房之外，需要知道它为什么错。假设流量分类器吃进被投毒的训练数据，错误来自输入和模型受攻击；再假设模型从未遭篡改，却建议把链路带宽分配得比物理容量还大，错误来自输出所触碰的现实边界。两者都可能在批准页面显示成一条“AI 建议”，但排查材料、阻断位置和责任人不能合并。

值得报道的是两版答复之间的删改。-00 曾在拟议“无冲突”结论后，请作者考虑 IRSG 审查中关于第 9.2、9.3 节界线的评论。历史记录显示，Mohamed Boucadair 同意“不冲突”，却反对借这份答复要求处理 IRSG 评论；Tommy Jensen 支持这一程序异议。9 月 24 日出现的 -01 保留拟议主结论，删除该备注。先后次序清楚，但公开资料不能证明编辑的全部动机，更不能把仍处 IESG Evaluation、仍有 DISCUSS 的文本写成最终决议。两类风险的区分仍在研究草案中，而非当前拟议答复中。

第 9.2 节列举训练数据投毒、逃避流量分类以及从模型推测训练信息等攻击面。要检验这种风险，需追问数据来源、谁能修改训练与推理输入、模型对故意操纵的反应。第 9.3 节换了对象：自动修改过滤表可能损害访问策略，质量服务参数也可能许诺超出链路能力的资源。即使没有攻击者，也应有独立于模型的配置上限、分阶段执行与回退。草案讨论渐进动作和回退，但没有证明所有实施都能做到。

程序权限同样有限。RFC 5742 对来自 IRTF 等非 IETF 流的投稿设置的是与 IETF 工作的冲突检查，不是可部署性或安全性认证。这份文件是研究组共识，目标类别为 Informational；目前尚无 RFC 编号，也没有材料证明某运营网络采用了它或因此发生事故。把拟议的“不冲突”写成 IETF 认可一套 AI 控制器，会越过公开证据。

Daniel Kade 建议在实际采用前留下两份可核对的记录：一份写明模型与数据的威胁假设、攻击测试和输入变更权限；另一份写明 AI 可以触及的网络命令、外部约束、暂停条件、人工授权以及回退后实际恢复的状态。这是编辑提出的检验办法，不是 IETF 新规。它的用处在于防止“模型看起来没问题”成为“它的每条指令都可以执行”的简写。

Sources