【RFC5245 ICE：提供/应答协议的网络地址转换器（NAT）遍历协议】第一篇（缩译）

原文 rfc5245 (ietf.org) Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols 交互式连接建立（ICE）: Offer/Answer协议的网络地址转换器（NAT）遍历协议

注：由于该文献过长，将分为五篇来翻译，本文为第一篇。（包含第一章节和第二章节）

概述

本文档介绍了使用Offer/Answer模型建立的，基于UDP的多媒体会话的网络地址转换器（NAT）遍历的协议。 该协议称为交互式连接建立（ICE）。 ICE利用了用于NAT的会话遍历实用程序（STUN）协议及其扩展“使用中继NAT遍历”（TURN）。 ICE可以由任何利用Offer/Answer模型的协议使用，例如会话发起协议（SIP）。

目录

1. 简介
2. ICE概述
    2.1 收集候选地址
    2.2 连接检查
    2.3 排序候选人
    2.4 冻结候选人
    2.5 支票的安全性
    2.6 总结ICE
    2.7 精简版的实现
3. 术语
4. 发送初始Offer
    4.1 完整的实施要求
          4.1.1 收集候选人
                   4.1.1.1 寄宿候选人
                   4.1.1.2 服务器自反和中继候选人
                   4.1.1.3 计算基础
                   4.1.1.4 让候选人保活
         4.1.2 优先考虑候选人
                   4.1.2.1 推荐配方
                   4.1.2.2 选择类型和本地优先级的准则
         4.1.3 消除多余的候选人
         4.1.4 选择默认候选人
   4.2 精简版实施要求
   4.3 对SDP进行编码
5. 接收初始Offer
    5.1 验证ICE支持
    5.2 确定角色
    5.3 收集候选人
    5.4 优先考虑候选人
    5.5 选择默认候选人
    5.6 对SDP进行编码
    5.7 形成检查列表
          5.7.1 形成候选对
          5.7.2 计算对优先级和排序对
          5.7.3 修剪对
          5.7.4 计算状态
    5.8 计划检查
6. 收到初始Answer
    6.1 验证ICE支持
    6.2 确定角色
    6.3 形成检查列表
    6.4 执行普通检查
7. 执行连接检查
    7.1 STUN客户端程序
          7.1.1 为中继候选人创建权限
          7.1.2 发送请求 
                   7.1.2.1 优先级和USE-CANDIDATE
                   7.1.2.2 ICE被控制和ICE控制
                   7.1.2.3 形成证书
                   7.1.2.4 DiffServ处理
          7.1.3 处理响应
                   7.1.3.1 失败案例
                   7.1.3.2 成功案例
                               7.1.3.2.1 发现对等端自反候选人
                               7.1.3.2.2 构造有效对
                               7.1.3.2.3 更新配对状态
                               7.1.3.2.4 更新提名标志
                  7.1.3.3 检查列表和计时器状态更新
     7.2 STUN服务器程序
           7.2.1 完整实施的附加程序
                    7.2.1.1 发现和修复角色冲突
                    7.2.1.2 计算映射地址
                    7.2.1.3 学习对等端自反候选人
                    7.2.1.4 触发检查
                    7.2.1.5 更新提名标志
           7.2.2 Lite实现的附加程序
8. 结束ICE处理
    8.1 全面实施的程序
          8.1.1 提名对
                   8.1.1.1 定期提名
                   8.1.1.2 激进提名
          8.1.2 更新状态
    8.2 Lite实现的程序
          8.2.1 对等端已满
          8.2.2 对等端是精简版
    8.3 释放候选人
          8.3.1 完整的实施程序
          8.3.2 精简版的实施程序
9. 随后的Offer/Answer交换
    9.1 生成Offer
          9.1.1 所有实施程序
                   9.1.1.1 ICE重新启动
                   9.1.1.2 删除媒体流
                   9.1.1.3 添加媒体流
         9.1.2 全面实施的程序
                  9.1.2.1 ICE在运行中的现有媒体流
                  9.1.2.2 ICE已完成的现有媒体流
         9.1.3 Lite实现的程序
                  9.1.3.1 ICE在运行中的现有媒体流
                  9.1.3.2 ICE已完成的现有媒体流
    9.2 接受Offer并生成Answer
           9.2.1 所有实施程序
                   9.2.1.1 正在检测ICE重新启动
                   9.2.1.2 新媒体流
                   9.2.1.3 删除了媒体流
          9.2.2 全面实施的程序
                   9.2.2.1 ICE正在运行中且没有ICE远端候选人的现有媒体流
                   9.2.2.2 ICE已完成并且没有远端候选人的现有媒体流
                   9.2.2.3 现有的媒体流和远程候选人
          9.2.3 Lite实现的程序
    9.3 更新检查和有效列表
           9.3.1 全面实施的程序
                    9.3.1.1 ICE重新启动
                    9.3.1.2 新媒体流
                    9.3.1.3 删除了媒体流
                    9.3.1.4 现有媒体流的ICE连续性
           9.3.2 Lite实现的程序
10. Keepalives保活
11. 媒体处理
     11.1 发送媒体
             11.1.1 全面实施的程序
             11.1.2 Lite实现的程序
             11.1.3 所有实施程序
     11.2 接收媒体
12. 与SIP结合使用
      12.1 延迟准则
              12.1.1 在INVITE(邀请）中的Offer
              12.1.2 在RESPONSE（回应）中的Offer
      12.2 SIP选项标签和媒体功能标签
      12.3 与分叉的交互作用
      12.4 与前提条件的交互作用
       12.5 与第三方呼叫控制的交互作用
13. 与ANAT的关系
14. 可扩展性注意事项
15. 语法
      15.1 “候选”属性
      15.2 “远程候选人”属性
      15.3 “ ice-lite”和“ ice-mismatch”属性
      15.4 “ ice-ufrag”和“ ice-pwd”属性
      15.5 “ ice-options”属性
16. 设置Ta和RTO
      16.1 RTP媒体流
      16.2 非RTP会话
17. 示例
18. 安全注意事项
      18.1 对连接检查的攻击
      18.2 服务器自反地址收集的攻击
      18.3 对中继候选人收集的攻击
      18.4 对Offer/Answer交换的攻击
      18.5 内部攻击
              18.5.1 音锤攻击
              18.5.2 STUN放大攻击
      18.6 与应用层网关和SIP的交互作用
19. STUN扩展程序
      19.1 新属性
      19.2 新的错误响应码
20. 操作注意事项
     20.1 NAT和防火墙类型
     20.2 带宽要求
              20.2.1 STUN和TURN服务器容量规划
              20.2.2 收集和连通性检查
              20.2.3 Keepalives保活
      20.3 ICE和ICE-lite
      20.4 故障排除和性能管理
      20.5 端点配置
21. IANA注意事项
      21.1 SDP属性
               21.1.1 候选属性
               21.1.2 remote-candidates属性
               21.1.3 ice-lite属性
               21.1.4 ice-mismatch属性
               21.1.5 ice-pwd属性
               21.1.6 ice-ufrag属性
               21.1.7 ice-options属性
      21.2 STUN属性
      21.3 STUN错误响应
22. IAB注意事项
     22.1 问题定义
     22.2 退出策略
     22.3 ICE引入的脆性
     22.4长期解决方案的要求
     22.3 现有NAPT盒的问题   
23.致谢
24.参考资料
     24.1 规范参考
     24.2 信息参考
   附录A精简版和完整实现
   附录B设计动机
     B.1 STUN交易的定价
     B.2 有多个基地的候选人
     B.3 和属性的用途
     B.4 STUN用户名的重要性
     B.5 候选对优先级公式
     B.6 远程候选人属性
     B.7 为什么需要Keepalives？ 
     B.8 为什么更喜欢对等端自反候选人？ 
     B.9 为什么发送更新的Offer？
     B.10 为什么绑定指示被用于Keepalive？
     B.11 为什么需要冲突解决机制？

1. 介绍

RFC 3264 [RFC3264]定义了会话描述协议（SDP）消息[RFC4566]的两阶段交换，目的是建立多媒体会议。此Offer/Answer机制由诸如会话发起协议（SIP）[RFC3261]之类的协议使用。

使用Offer/Answer的协议很难通过网络地址转换器（NAT）进行操作。因为他们的目的是建立一个媒体数据包流，它们倾向于携带媒体源和接收器消息中的IP地址和端口，这也是已知的NAT引起问题的场景。该协议还寻求在参与者之间直接创建媒体流，以便它们之间没有应用层的参与。这样做是为了减少媒体等待时间，减少数据包丢失，并减少部署应用程序的运营成本。但是，这是很难通过NAT完成。完整的原因的内容超出了本规范的范围。

已经定义了许多解决方案，以允许这些协议通过NAT运行。这些包括应用层网关（ALG），中间盒控制协议[RFC3303]，原始简单的通过NAT穿越UDP（STUN）[RFC3489]规范，以及领域特定IP [RFC3102] [RFC3103]以及使它们起作用所需的会话描述扩展，例如实时控制协议（RTCP）[RFC3605]的会话描述协议（SDP）[RFC4566]属性。不幸的是，这些技术各有利弊，这使得每种技术在某些网络拓扑中是最优的，但在其他拓扑中却是一个糟糕的选择。结果是管理员和实施者正在对将在其中部署其解决方案的网络拓扑进行假设。这给系统带来了复杂性和脆弱性。需要的是一个单一的解决方案，该解决方案足够灵活，可以在所有情况下正常工作。

该规范定义了交互式连接建立（ICE）作为基于UDP的媒体流进行NAT遍历的技术（尽管ICE可以扩展为处理其他传输协议，例如TCP [ICE-TCP]）已基于Offer/Answer模型建立了协议。 ICE是对Offer/Answer模型的扩展，并且将IP地址和端口的多样性包含在SDP的Offer和Answer，然后进行端对端的连接性检查。包含在SDP中的IP地址和端口的连接性检查使用修订后的STUN规范[RFC5389]执行，该规范现已重命名为用于NAT会话遍历实用程序。新名称和新规范反映了其作为与其他NAT遍历技术（即ICE）一起使用的工具，而不是像原始STUN那样的独立NAT遍历解决方案。ICE还利用TURN[RFC5766]，作为STUN的扩展。因为ICE为每种媒体流交换多个IP地址和端口，它还允许为多宿主和双栈主机选择地址，因此，它不推荐使用RFC 4091 [RFC4091]和[RFC4092]。

2. ICE概述

在典型的ICE部署中，我们有两个要进行通信的终端点（在RFC 3264术语中称为AGENTS）。他们能够通过某些信令协议（例如SIP）进行间接通信，通过它们可以执行SDP [RFC3264]消息的Offer/Answer交换。请注意，ICE并非旨在用于SIP的NAT遍历，它假定是通过另一种机制[RFC5626]提供的。在ICE进程开始时，代理(Agent)不了解它们自己的拓扑。特别是，它们可能位于或不位于NAT（或多层NAT）的后面。 ICE使代理可以发现有关其拓扑的足够信息，从而有可能找到一条或多条可以进行通信的路径。

图1显示了ICE部署的典型环境。它们两个终端点分别标记为L和R（用于左侧和右侧，这有助于可视化呼叫流程）。 L和R都在它们自己的NAT之后，尽管它们可能不知道。 NAT的类型及其属性也是未知的。代理(Agent) L和R有能力参与在Offer/Answer交换中，它们可以交换SDP消息，目的是在L和R之间建立媒体会话。通常，这种交换将通过SIP服务器进行。除了代理，SIP服务器和NAT，ICE通常与网络中的STUN或TURN服务器配合使用。 每个代理可以拥有自己的STUN或TURN服务器，它们也可以是相同的。

ICE的基本思想如下：每个代理都有多种候选传输地址（特定传输协议的IP地址和端口的组合，在此规范中始终为UDP），它可以用来与其他代理进行通信。
这些可能包括：
   o直接连接的网络接口上的传输地址
   o NAT公共端上的转换后的传输地址（一个“服务器自反”地址）
   o从TURN服务器分配的传输地址（一个“中继地址”）。
潜在地，任何L的候选传输地址都可用于与R的任何候选传输地址进行通信。然而，在实践中，许多组合都行不通。例如，如果L和R都位于NAT之后，它们的直接连接的接口地址不太可能直接通信（这就是为什么需要ICE！）。 ICE的目的是发现哪些地址对有效。 ICE执行此操作的方法是系统地尝试所有可能的对（以仔细排序的顺序）直到找到一个或多个有效的方法为止。

2.1 收集候选人地址

为了执行ICE，代理必须识别其所有地址候选人。 候选人是一个传输地址-以下特定传输协议的IP地址和端口的各种组合（此处仅指定了UDP）。本文档定义了三种类型的候选对象，其中一些来自物理或逻辑网络接口，其他可以通过STUN和TURN发现的。自然地，一个可行的候选者是直接从本地接口获取的传输地址。这样的候选人称为“本地候选人”。本地接口可以是以太网或WiFi，也可以是通过隧道机制（例如VPN或移动IP（MIP））。在所有情况下，这样的网络接口对代理而言都是本地端口（以及候选人）都可以分配。

如果代理是多宿主的，则它将从每个IP地址中获取候选者。取决于在与代理相关的IP网络上的对等端的位置（在会话中的另一个代理），代理可以通过这些IP地址中的一个或多个IP地址可被对等端访问。
例如，一个代理有私网的本地IP地址（I1）的代理，第二个连接到公共互联网（I2）。来自I1的候选人将与同一个私网I0的对等端直接可达，来自I2的候选人与公共Internet上的对等端进行通信时，将可以直接到达I2的候选对象。服务提供者不是在发送Offer之前尝试猜测哪个IP地址可以工作，而是要提供Offer的代理将两个候选对象同时包含在Offer中。
在报价中同时包括两个候选人。

接下来，代理使用STUN或TURN来获取其他候选者。这些有两种形式：NAT公共端转换后的地址（服务器自反候选地址）和TURN服务器上的地址（中继候选地址）。 当使用TURN服务器时，两种类型的候选者都可以从TURN服务器获得。 如果仅使用STUN服务器，则仅从中获得服务器自反候选者。 这些候选者与主机候选者(host candidate)的关系如图2所示。在该图中，使用TURN发现了两种类型的候选者。 在图中，符号X：x表示IP地址X和UDP端口x。

当代理从IP地址和端口X：x发送TURN分配请求时，NAT（假设有一个）将创建一个X1'：x1'的绑定，将此服务器自反候选者映射到主机候选者X：x。从主机候选发送的传出数据包将由NAT转换为服务器自反候选。发送到服务器自反候选者的传入数据包将由NAT转换为主机候选者，并转发给代理。我们将与给定服务器自反候选者关联的主机候选者称为BASE。

注意：“Base”是指代理从特定候选人那里发送来的地址。因此，作为简并案例的主机候选者也有一个base，但与主机候选者相同。

当代理程序与TURN服务器之间存在多个NAT时，TURN请求将在每个NAT上创建绑定，但是只有最外面的服务器自反候选对象（最靠近TURN的那个服务器）将由代理发现。如果代理不在NAT之后，则base候选者将与服务器相同自反候选者和服务器自反候选者是相同的，并将被淘汰。

然后，分配请求到达TURN服务器。 TURN服务器从其本地IP地址Y分配端口y，并生成分配响应，从而将通知该中继候选的代理。TURN服务器还将通知服务器自反候选者的代理X1'：x1'，方法是复制分配请求的源传输地址到分配响应中。 TURN服务器充当数据包中继，在L和R之间转发流量。为了向L发送流量，R在Y：y将流量发送到TURN服务器，然后TURN服务器将其转发到X1'：x1'，后者通过NAT被映射到X：x并传递给L。

当仅使用STUN服务器时，代理会发送STUN绑定到其STUN服务器请求[RFC5389]。 STUN服务器将通知服务器自反候选X1'：x1'的代理，方法是复制绑定请求的源传输地址到绑定回复中。

2.2 连接检查

一旦L收集了所有候选人，它会以最高到最低优先级的顺序命令它们，并通过信令信道将其发送给R。
候选者包含在SDP Offer中的属性中。当R收到Offer，它执行相同的收集过程，并且用自己的候选人名单回应。在此过程结束时，每个代理都有其候选人和对等候选人的完整列表。它将它们配对，产生候选对。为了查看哪个对有效，每个代理程序安排一系列的检查CHECKS。每个检查都是一个STUN请求/响应事务，客户端将通过将STUN请求从本地候选者发送到远端候选者，来对特定的候选者对执行。
连接检查的基本原理很简单：
   1.按优先顺序对候选对进行排序。
   2.按优先级顺序对每个候选对发送检查checks。
   3.收到其他代理发出的确认checks。

在两个代理都对一个候选对执行检查的情况下，结果是四次握手：

重要的是要注意，STUN请求是与用于媒体的IP地址和端口完全相同的发出和发回的（例如RTP和RTCP）。因此，代理使用数据包的内容而非接收它们的端口对STUN和RTP / RTCP进行多路分解。幸运的是，这种多路分解很容易做到，特别是对于RTP和RTCP。

由于STUN Binding绑定请求用于连接检查，STUN绑定响应将在代理之间的任何NAT的公共端上包含代理的转换后的传输地址和它的对等端。如果此传输地址不同于已经学习到的其他候选者，则代表是新的候选者，称为PEER REFLEXIVE CANDIDATE对等端自反候选者，然后由ICE与其他任何候选者一样进行测试。

作为一种优化，R一收到L的检查消息，R就计划将发送连接性检查消息给到同一候选对的L。这加快了寻找有效候选者的过程，称为“触发检查”。

在握手结束后，L和R都知道他们可以发送（和接收）两个方向的端到端消息。

2.3 排序候选人

由于上述算法会搜索所有候选对，因此如果工作的对存在，无论候选者按什么顺序尝试，最终都会找到答案。为了产生更快（更好）的结果，候选者以指定的顺序排序。排序后的候选对的结果列表称为“检查列表”。
该算法在第4.1.2节中进行了描述，但遵循以下两个常规原则：

   o每个代理都为其候选人赋予数字优先级，并伴随着候选者信息发送给对等端。
   o将本地和远程优先级组合在一起，以便每个代理有相同排序的候选对。

第二个属性对于使ICE工作很重要，当NAT是位于L和R的前面。通常，NAT不会允许来自主机的数据包，直到位于NAT后的代理向该主机发送了数据包为止。因此，除非双方都通过各自的NAT发送了检查，否则各个方向上的ICE检查都不会成功。

代理会通过定期发送对列表上的下一个候选对的STUN请求来检查该清单。这些叫做普通检查ORDINARY CHECKS。

一般而言，优先级算法的设计应使相似的类型具有相似的优先级，因此更直接的路线（即通过更少的媒体中继和更少的NAT）优先于间接媒体（具有更多媒体中继和更多的NAT）。但是，在这些准则范围内，代理关于如何调整算法的自由裁量权有着合理的数量。

2.4 冷冻候选人

前面的描述仅针对代理希望与一个组件建立媒体会话的情况（一个媒体流需要一个传输地址；一个媒体流可能需要多个组件，每个组件都必须工作才能使整个媒体流正常工作）。通常（例如，使用RTP和RTCP），代理实际上需要为多个流建立连接。

对于每个组件，网络属性可能非常相似（尤其是因为RTP和RTCP是从同一IP地址发送和接收的）。通常可以利用来自一个媒体组件的信息来确定另一个媒体组件的最佳候选者。 ICE通过称为“冻结候选人”的机制来做到这一点。

每个候选人都与一个称为“基金会”的属性相关联。当两个候选对象“相似”时，它们具有相同的类型，并且是使用相同协议从相同的主机候选对象和STUN服务器获得的。否则，他们的基础是不同的。候选对也有基础，这仅仅是它的两个候选者的基础的串联。最初，仅测试具有独特基础的候选对。其他候选对被标记为“冻结”。何时连接检查候选对是否成功，其他候选对具有
相同的基础未冻结。这样可以避免重复检查那些表面上更具吸引力但实际上可能会失败的组件。

尽管我们出于说明目的，在此处将“冻结”描述为一种单独的机制，实际上，它是ICE不可或缺的一部分，并且ICE优先级排序算法可自动确保解冻正确的候选者不被冻结，并按正确的顺序被检查。

2.5 Checks检查安全

由于使用ICE来发现哪些地址可用于在两个代理之间发送媒体，因此确保该进程不能被劫持，从而将媒体发送到错误的位置非常重要。每个STUN连接检查都由使用在信令信道中交换的密钥计算出的消息认证码（MAC）覆盖。该MAC提供消息完整性和数据源身份验证，从而阻止攻击者伪造或修改连接检查消息。此外，如果SIP [RFC3261]呼叫者正在使用ICE及其呼叫分叉，则ICE交换将与每个分叉的接收者独立发生。在这种情况下，在信令中交换的密钥有助于将每个ICE交换与每个分叉的接收者相关联。