Summary

  • 11 月的 MoQ 中继拒绝服务草案新增一个明确风险：行为不当的中继向许多客户端发送 GOAWAY，把不相干的第三方主机写成新会话地址，连接尝试便一起涌向该主机。
  • MoQT 传输草案规定，客户端收到服务器控制流上的 GOAWAY 后，必须使用其中非空的新会话 URI。地址字段告诉客户端去哪里，却没有证明那个目标有权接收这批观众。

设想一台有大量观众的中继。为了平稳迁移，它可以在关闭会话前给出下一站 URI。若这台中继把别人的服务器写进去，每个连接中的客户端都可能照着指令尝试重连。02 版新增的段落写得很直白：受害主机甚至不必运行 MoQT 服务。连接尝试依旧会到达，主机无法在它们发出之前让远端客户端停下。

规则本身有边界，但边界没有回答授权问题。工作组传输草案第 9.2 节允许服务器在控制流 GOAWAY 中给出新会话 URI。非空时客户端必须用它建立新会话。客户端不能用同样字段命令服务器转向别处。URI 最长 8,192 字节，同一控制流也不能反复发送 GOAWAY。这些限制挡不住中继把一台无关主机写成下一站。请求流上的 GOAWAY 用词不同，只建议请求方在指定地址重发该请求。大规模观众迁移对应的是服务器向客户端发出的控制流消息。

7 月的 01 版没有第三方主机这一段。11 月版本补入的是具体的负载转移机制，不是笼统的“中继也会耗资源”。草案提出的缺口同样具体：客户端在跟随新 URI 之前，必须有办法确认它对目标服务具有权威性。规则要由传输规范处理。TLS 以后可能拒绝不合适的终点，但连接尝试已先抵达目标。官方文件没有报告实际攻击或测得的超载。IETF 跟踪页仍把威胁文档列为个人草案。

运营者需要的记录不是一句“迁移完成”，而是原中继、新 URI、准入该 URI 的规则、连接尝试的数量和时间，以及目标主机收到的负载。观众规模越大，中继握着的就越像一张向别人开账单的支票。