摘要

  • ICE 控制方可以为每个组件提名一个有效候选对；两个完整代理同时声称控制角色时，由均匀随机选出的 64 位决胜值分工。
  • 赢得角色冲突不等于赢得会话所有权，更不能替代信令认证、持续同意、媒体保护、应用接收或业务结果证据。

“控制”首先是一个容易误读的名字

在管理界面上，“控制方”很像拥有最终决定权的一方。但 ICE 所说的控制，只回答一个狭窄问题：哪个代理负责提名候选对。

每个完整 ICE 代理预先从零到 2^64−1 之间均匀选择一个决胜值。若双方都发送 ICE-CONTROLLING，便比较数值；一方保留控制角色，另一方切换，487 Role Conflict 响应可以纠正冲突。角色变了，并不因为这次切换重新抽取一个数值。

这个设计没有采集组织身份、主叫关系、报价顺序、付款责任、设备产权或人的授权。较大的随机数不会因此成为身份证，也不会使对应代理更可信。它只是让两个状态机在无需另建选举系统的情况下完成分工。

因此，把这个角色显示成“会话所有者”“主端”或“授权端”，并不是更友好的翻译，而是凭空增加了 RFC 从未观察到的权力。

一次提名背后至少有五张不同收据

ICE 先收集主机候选、服务器反射候选与中继候选，再通过已有的信令连接交换候选，组成并排序候选对，最后执行 STUN 连通性检查。成功的事务可以把候选对放入有效列表，表明当时测试报文能够沿该路径双向往返。

之后，控制方才依据本地策略选择候选对。常规提名会在一次检查中携带 USE-CANDIDATE。RFC 8445 保留了常规提名，同时删除了 RFC 5245 的激进提名方式。

候选优先级、检查成功、进入有效列表、被提名、被双方选中，是五种不同状态。优先级是偏好，不是可达性；有效不是已选；提名不是永久同意；已选更不是服务成功。一个“ICE 已连接”的总状态把它们压扁后，故障调查便无法回答究竟是哪一步成立、哪一步从未发生。

信令为 ICE 借来信任

ICE 假设双方已经拥有信令连接，它自己并不为这条信令穿越 NAT。候选、用户名片段和短期密码都从外部信令边界进入。STUN 消息完整性可以保护检查报文，但保护的意义取决于密钥是否经可信信令交给了正确对象。

如果信令被替换，ICE 完全可能在错误输入上忠实执行。RFC 8445 的安全分析讨论了假无效、假有效与假对等反射候选等结果。这恰好说明，“有效”是特定凭证、事务与状态机之内的结论，不是对地址所有权或对端身份的普遍认证。

运维记录若只保留“完整性校验通过”，却丢掉凭证来源，就只能证明报文与某把密钥一致，不能解释为何那把密钥代表预期的对端。

协议同意不等于人的意愿

RFC 7675 把初始 ICE 成功视为针对候选对发送数据的初始应用级同意，同时明确说明这里没有人的介入。这种同意绑定于一个五元组，需要后续请求与响应不断刷新，过期后不再是当前证据。

候选对的“已选中”记录可能长期保留，而同意新鲜度按另一只时钟衰减。仅靠 ICE 也无法知道同意何时结束。把历史选中状态展示为“用户已经授权”有双重越权：它把机器协议状态解释为人的意愿，又把有时效的收据解释为永久许可。

至少应分开保存：选中的候选对、覆盖的五元组、最近一次同意事务，以及在其他系统中取得的人或机构授权。

路径并不担保路径上承载的内容

ICE 解决报文走哪条路。媒体的机密性、完整性和端点认证由其他协议解决；应用负责解码和接受；用户体验与商业结果还在更高层。

所以，系统可以准确报告“完整性受保护的检查成功、控制方完成提名、双方选中该对”，却不能据此断言媒体受保护、音频可理解、会话达到 SLA 或会议完成目标。

RFC 8828 之所以处理主机候选隐私，是因为候选披露可能暴露网络拓扑。知道一个地址、甚至能够到达它，都不等于拥有该地址或获得公开它的许可。RFC 5128 则说明直连可能失败而必须使用中继；被选中的路径并不天然直接、便宜、稳定或独立。

为证据建立台阶，而不是一个绿灯

更可靠的账本应逐层记录：角色声明、冲突比较、信令认证、STUN 完整性、候选对成功、控制方提名、双方选择、当前同意、受保护数据通过、应用接受、服务结果出现。

Lu Heng 关于现实层的原则在这里十分具体：每张收据只能证明它实际观察到的事实，低层结果不得借用高层权威。随机数能决定谁执行提名，提名能决定控制方建议使用哪条已检查路径；二者都不能继承身份、治理或结果层的含义。

RFC 5245 已成为历史规范，通用 ICE 流程由 RFC 8445 取代，SDP 要约/应答部分由 RFC 8839 承接。审计时必须确认部署实际遵循哪一代规则。但无论版本如何，最关键的约束没有变化：程序角色必须停留在程序之内。

来源