摘要

  • PIM 工作组 GAAP 草案第 25 版把第 5 节改称“示例性 GAAP API”，并明确 GAAP 是协议，不是程序库或 Python API。实现可以采用任何应用接口，甚至不提供此类接口，前提是遵守线路上的 Claim 协议。第 24 版已经说明示例 API 不具规范性，不能把这一点说成第 25 版才新增。
  • 第 25 版还把 Claim 的四个实际字段与解释字段用途的文字分开，并解释为何没有消息认证码的 ChaCha20 会让密文可被篡改。这不是换了报文格式、首次禁止这种用法，也不是对现网攻击的报道。

设想两个独立团队要让各自的软件使用同一组地址分配机制。它们未必使用相同语言，也未必通过相同进程边界发出请求；但如果要彼此识别 Claim，就必须在可交换的信息上达成一致。GAAP 讨论的正是无需单一分配服务器的组播地址分配。草案给出伪 Python 调用，原本用于帮助读者理解调用过程。第 25 版把“这段例子不是协议本身”的界线直接写进正文：GAAP 并非 Python 程序库；实现者可自行选择接口，或完全不暴露编程接口，只要遵循线路上的 Claim 协议。

这个变化不应被夸大成“撤销强制 Python 绑定”。第 24 版已经称相关 API 为说明性、非规范性内容。新的作用是堵住一种解释上的滑坡：读者可能因为文档写了 gaap.init() 之类的例子，就误以为函数名称和库边界已经获得标准地位。草案现在否定这种等同。一个实现若把地址请求交给本地守护进程，另一个若把逻辑嵌入设备，是否符合协议仍要看彼此能否正确交换 Claim；这两种实现形式只是说明可能的本地选择，并非我们掌握的实际部署。

第 4 节处理了另一处容易混淆的“边界”。Claim 记录包括 IPv4 组播组地址、IPv6 组播组地址、时间戳和组名四项。其后的段落讲字段如何使用、比较、解析。第 25 版明确后者是解释，不是继续往记录里加字段。因此，版本差异不能作为“新增第五字段”“改变字段顺序”或“运营网络需要迁移报文格式”的证据。值得注意的是说明方式更加严谨，而不是新格式已经被实测互通。

安全部分也要求区分旧规则与新解释。第 24 版已说，仅用 ChaCha20 而没有消息认证码，不能满足 GAAP 的完整性要求，不得单独使用。第 25 版补充原因：流密码若缺少完整性保护，路径上的攻击者能够翻转密文比特，让接收方解出的组地址、时间戳或组名发生变化而不被发现。草案甚至认为，让人误以为受保护，可能比明确使用不加密的基础模式更危险。这里陈述的是草案的风险分析；没有证据表明某个现网 GAAP 系统采用这种配置，或发生了此类攻击。

这些修订放在一起，呈现了两种不同的自由。应用内部如何调用，可以由实现者决定；交换给其他参与方的 Claim 及其安全性质，则不能随意解释。只检查软件里有没有某个 Python 函数，无法证明互操作；只看到了密文，也无法证明收到的内容未被改写。相反，线路交换和完整性测试才是可对照的证据。这个判断是本文的编辑性解读，并非 IETF 发布的认证方案。

Datatracker 目前将第 25 版列为 PIM 工作组 Internet-Draft，处于 IESG Evaluation 的 AD Followup，目标状态为 Experimental；它尚不是 RFC，更不是部署公告。BTW 早前对 GAAP 第 23 版的报道讨论固定地址范围以及网络分区重新连通后的同名 Claim 收敛问题。那些问题仍然存在于背景中，但这篇报道不重复该论点，也不声称第 25 版已解决它们。本次明确的新事实，是线路协议与本地接口之分，以及对字段和完整性证据的表述。

来源