22. IAB 考虑 (IAB Considerations)
IAB 研究过 "Unilateral Self-Address Fixing" 问题, 即 agent 通过协作式协议反射机制, 试图确定自己在 NAT 另一侧另一个 realm 中地址的一般过程 [RFC3424]. ICE 是执行此类功能的协议示例. 有趣的是, ICE 的过程不是单边的, 而是双边的, 这种差异对 IAB 提出的问题有显著影响. 实际上, ICE 可以被视为 B-SAF (Bilateral Self-Address Fixing) 协议, 而不是 UNSAF 协议. 无论如何, IAB 要求为此目的开发的任何协议记录一组特定考虑. 本节满足这些要求.
22.1. 问题定义
根据 RFC 3424, 任何 UNSAF 提案都必须提供:
Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short-term fix should not be generalized to solve other problems; this is why "short-term fixes usually aren't".
ICE 要解决的具体问题是:
-
提供一种方式, 使两个 peers 能确定可用于通信的 transport addresses 集合.
-
提供一种方式, 使 agent 能确定一个地址, 该地址可被其希望通信的另一个 peer 到达.
22.2. 退出策略
根据 RFC 3424, 任何 UNSAF 提案都必须提供:
Description of an exit strategy/transition plan. The better short-term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
ICE 本身不容易被逐步淘汰. 但是, 即便在全球互连的 Internet 中, 它也有用, 例如可作为检测路由器故障是否临时破坏连接性的方式. ICE 还有助于防止某些与 NAT 无关的安全攻击. 不过, ICE 所做的是帮助逐步淘汰其他 UNSAF 机制. ICE 实际上在这些机制之间进行选择, 优先考虑更好的机制, 降低较差机制的优先级. 可以优先选择本地 IPv6 地址. 随着 IPv6 引入而 NAT 开始消退, server reflexive 和 relayed candidates (二者都是 UNSAF addresses 的形式) 将不会被使用, 因为原生 host candidates 存在更高优先级的连接性. 因此, servers 的使用会越来越少, 当使用量降至零时最终可以移除.
实际上, ICE 可以辅助从 IPv4 到 IPv6 的过渡. 当两个 dual-stack hosts 使用 SIP 通信时, 它可用于确定使用 IPv6 还是 IPv4 (会使用 IPv6). 它还可以允许同时具有 6to4 和原生 v6 连接性的网络在与 peer 通信时确定使用哪个地址.
22.3. ICE 引入的脆弱性
根据 RFC 3424, 任何 UNSAF 提案都必须提供:
Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
ICE 实际上移除了现有 UNSAF 机制中的脆弱性. 特别是, classic STUN (如 RFC 3489 [RFC3489] 所述) 有若干脆弱点. 其中之一是 discovery process, 它要求 agent 尝试对其所在 NAT 类型进行分类. 这个过程容易出错. 使用 ICE 时, 该 discovery process 根本不会被使用. 与单方面评估地址有效性不同, 地址有效性通过测量到 peer 的连接性来动态确定. 确定连接性的过程非常健壮.
classic STUN 以及任何其他单边机制的另一个脆弱点是它绝对依赖额外 server. ICE 使用 server 分配单边地址, 但允许 agents 在可能时直接连接. 因此, 在某些情况下, 使用 ICE 时即便 STUN server 失效, 呼叫仍可继续.
classic STUN 的另一个脆弱点是它假设 STUN server 位于 public Internet. 有趣的是, 对 ICE 而言这不是必需的. 不同 address realms 中可以存在多个 STUN servers. ICE 会发现提供可用地址的那个 server.
classic STUN 中最令人担忧的脆弱点是它并不适用于所有网络拓扑. 在每个 agent 与 STUN server 之间存在共享 NAT 的情况下, 传统 STUN 可能无法工作. 使用 ICE 后, 这一限制被移除.
classic STUN 还引入了一些安全考虑. 幸运的是, 这些安全考虑也由 ICE 缓解.
因此, ICE 用于修复 classic STUN 中引入的脆弱性, 而不会向系统引入任何额外脆弱性.
这些改进的代价是 ICE 会增加 session establishment times.
22.4. 长期解决方案的需求
根据 RFC 3424, 任何 UNSAF 提案都必须提供:
... requirements for longer term, sound technical solutions -- contribute to the process of finding the right longer term solution.
我们从 RFC 3489 得出的结论保持不变. 不过, 我们认为 ICE 实际上有所帮助, 因为我们相信它可以成为长期解决方案的一部分.
22.5. 现有 NAPT 设备的问题
根据 RFC 3424, 任何 UNSAF 提案都必须提供:
Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports.
目前有许多 NAT 设备正在投放市场, 它们试图提供 "generic" ALG 功能. 这些 generic ALGs 会在分组内以文本或二进制形式查找 IP 地址, 并在匹配某个 binding 时重写它们. 这会干扰 classic STUN. 但是, STUN 的更新 [RFC5389] 使用一种编码, 可向 generic ALGs 隐藏这些二进制地址.
现有 NAPT 设备对基于 UDP 的 bindings 具有非确定性且通常较短的过期时间. 这要求实现发送周期性 keepalives 来维护这些 bindings. ICE 使用 15 s 的默认值, 这是非常保守的估计. 最终, 随着时间推移, 当 NAT 设备变得符合 behave [RFC4787] 时, 这种最小 keepalive 将变得确定且众所周知, ICE timers 可以随之调整. 若能发现并控制最小 keepalive 间隔, 将会更好.