STUN—简单地用UDP穿过NAT

RFC 3489 STUN 2003年3月
Rosenberg等 1页
网络工作组 J. Rosenberg
RFC:3489 J. Weinberger
种类:标准路线 dynamicsoft
C. Huitema
微软
R. Mahy
思科
2003年3月
STUN—简单地用UDP穿过NAT
本文状态
本文指定互联网社区的一个互联网标准路线协议,并请求进行改进的讨论和建议.该协
议的标准化状态请参考最新版的"互联网官方协议标准"(STD 1).可以无限制地分发本文.
版权声明
互联网协会(2003)版权所有(C).保留所有权利.
摘要
简单地用UDP穿过NAT(STUN)是个轻量级的协议.它允许应用发现它们与公共互
联网之间存在的NAT和防火墙及其类型.它还为应用提供判断NAT给它们分配的公共网际
协议(IP)地址.STUN可工作在许多现存NAT上,并且不需要它们的做任何特别的行为.
结果就是,它允许广泛的各类的应用穿过现存的NAT设施.
目录表
1. 适用性声明3
2. 简介3
3. 术语4
4. 定义4
5. NAT种类4
6. 操作概貌5
7. 消息概貌7
8. 服务器行为7
8.1 捆绑请求8
8.2 共享私密请求9
9. 客户行为11
RFC 3489 STUN 2003年3月
Rosenberg等 2页
9.1 发现11
9.2 获得共享私密11
9.3 表示捆绑请求12
9.4 处理捆绑响应13
10. 用例14
10.1 发现过程14
10.2 捆绑生命期发现15
10.3 获得捆绑16
11. 协议细节17
11.1 消息头17
11.2 消息属性18
11.2.1 MAPPED-ADDRESS19
11.2.2 RESPONSE-ADDRESS19
11.2.3 CHANGED-ADDRESS19
11.2.4 CHANGE-REQUEST19
11.2.5 SOURCE-ADDRESS20
11.2.6 USERNAME20
11.2.7 PASSWORD20
11.2.8 MESSAGE-INTEGRITY20
11.2.9 ERROR-CODE21
11.2.10 UNKNOWN-ATTRIBUTES21
11.2.11 REFLECTED-FROM22
12. 安全思考22
12.1 用STUN攻击22
12.1.1 攻击I:对同一目标的DDOS攻击22
12.1.2 攻击II:客户静言23
12.1.3 攻击III:假设客户的标识23
12.1.4 攻击IV:窃听23
12.2 发起攻击23
12.2.1 方法I:危害合法的STUN服务器23
12.2.2 方法II:DNS攻击24
12.2.3 方法III:欺骗路由器或NAT24
12.2.4 方法IV:MITM24
12.2.5 方法V:响应注射和DoS24
12.2.6 方法VI:复制25
12.3 对策25
12.4 其余的威胁26
13. IANA思考26
14. IAB思考26
14.1 问题定义27
14.2 退出策略27
14.3 引入STUN的脆弱性28
14.4 需要长期的解决方法29
14.5 与现存的NAPT盒的问题29
RFC 3489 STUN 2003年3月
Rosenberg等 3页
14.6 结束语30
15. 感谢30
16. 参考标准30
17. 参考信息31
18. 作者地址32
19. 完整版权声明32
1. 适用性声明
本协议不关心与NAT有关的所有问题.它不允许向内穿过NAT的TCP连接请求.它
允许向内穿过NAT的UDP数据包,但只可穿过现有NAT类型中的一个子集.特别是,STUN
不允许向内穿过对称(Symmetric)NAT(定义见下面)的UDP数据包.该类NAT在大型
企业中很常见.STUN的发现过程基于NAT对待UDP的假定;对于新型已部署的NAT设
备,该假定被证明是无效的.无法使用STUN来获取碰巧位于同个NAT之后的通迅端点的
地址.当STUN服务器不在公共共享地址域内时,STUN将无法工作.关于STUN限制的
更完整的讨论见14节.
2. 简介
网络地址转换(NAT),提供很多好处的同时,也带来了许多缺点.这些缺点中的最麻
烦的是它中断了许多现有的IP应用,并且使用部署新的应用非常困难.已经开发出描述如
果创建"NAT友好"的协议的指导方针[8],但是许多协议不能简单地使用该指导方针来创
建.这类协议的例子包括几乎所有的P2P协议,如多媒体通迅,文件共享和游戏.
为了与该问题作斗解,已经在NAT中嵌入了应用层网关(ALG).ALG执行特定协议
所需要的穿过NAT的应用层功能.一般情况下,这会引入重写应用层消息来包含转换后的
地址,而不是消息发送者在其中插入的.ALG有严重的限制,包括伸缩性,可靠性和部署
新应用的速度.要解决这些问题,正在开发中间盒通迅(MIDCOM)协议[9].MIDCOM允
许应用实体,如终端客户或一些类型的网络服务器(如会话发起协议(SIP)代理[10])来
控制NAT(或防火墙),以获得NAT的捆绑和打开或关闭这些洞.通过这种方法,NAT和
应用可再一次分开,剔除需要在NAT中嵌入ALG的需求,并解决利用当前结构的限制.
非常不幸,MIDCOM需要对现存的NAT和防火墙进行升级,应用组件也一样.对这些
NAT和防火墙产品进行完全地升级将花去很长的时间,可能是几年.这部分由于NAT和防
火墙的部署者与部署并使用应用的人是不同的.结果就是,许多情况下,升级这些设备的动
机将非常小.作为例子,考虑一个航空港的互联网沙龙提供通过NAT的接入服务.一个用
户连接到该NAT网络可能希望使用P2P服务,但是不能,因为NAT不支持.既然沙龙的管
理员不提供该服务,它们也没有动机来升级它们的NAT设备来支持该服务,而不管是ALG
还是MIDCOM.
MIDCOM协议的另一个问题是,它需要控制中间盒的代理知道这些中间盒的标识,并
且与这些允许控制的有关系.在许多配置下,这将是不可能的.例如,许多线路接入提供者
在他们的整个接入网络前使用NAT.这个NAT可能会附加上由终端用户购买和操作的住宅
NAT.终端用户可能与线路接入网络中的NAT没有控制关系,且可能并不知道他们的存在.
RFC 3489 STUN 2003年3月
Rosenberg等 4页
许多现存的私有协议,如在线游戏的协议(如在RFC 3027[11]中描述的游戏)和VoIP,
已经开发现这样的诡计.它允许他们穿过NAT进行操作而不需要改变这些NAT.可尝试从
本文获得一部分这些主意.本文将它们编辑成一个可互操作的协议,并可满足许多应用的需
要.
这里描述的协议,用UDP简单穿过NAT(STUN),允许NAT后的实体首先发现NAT
的存在和其类型,接着知道NAT分配的地址捆绑.STUN不需要修改NAT,并可工作在应
用实体和公共互联网前后间有任意数量的NAT的情况下.
3. 术语
在本文中,关键字"MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT",
"SHOULD","SHOULD NOT","RECOMMENDED","MAY",和"OPTIONAL"应按
BCP 14,RFC 2119[1]中描述的一样进行解释,并表明的顺从STUN的应用的所需的等级.
4. 定义
STUN客户
STUN客户(只引用为客户)是产生STUN请求的实体.STUN客户能够在终端系统上
执行,如用户的PC机,或能够在网络器件中运行,如会议服务器.
STUN服务器
STUN服务器(还是只引用为服务器)是接收STUN请求并发送STUN响应的实体.
STUN服务器通常连接到公共互联网.
5. NAT种类
假设用户熟悉NAT.观察发现NAT有各种对待UDP的实现.观察到的实现中的4程
对待方式是:
完全锥形
完全锥形NAT将从同个内部IP地址和端口号发出的所有请求映射为相同的外部IP地
址和端口号.此外,外部主机能够向内部主机发送数据包,即通过向映射过的外部地址发送
数据包.
限制锥形
限制锥形NAT将从同个内部IP地址和端口号发出的所有请求映射为相同的外部IP地
址和端口号.与完全锥形NAT不同的是,外部主机(IP地址为X)只能够向先前已经向IP
地址X发送过数据包的内部主机发送数据包.
RFC 3489 STUN 2003年3月
Rosenberg等 5页
端口限制锥形
端口限制锥形NAT与限制锥形NAT一样,但是限制包括端口号.特别是,有源IP地
址X和端口号P的外部主机只能够向先前已经向IP地址X和端口P发送过数据包的内部主
机发送数据包.
对称
对称NAT将从相同的内部IP地址和端口号,以及指定的目的IP地址和端口号,发出
的所有请求映射为相同的外部IP地址和端口号.如果同个主机用相同的源地址和端口给不
同的目的地发送数据包,将使用不同的映射.此外,只有收到数据的外部主机才可以反过来
向内部主机发送UDP数据包.
在许多情况下,决定NAT的类型是重要的.取决于应用相做什么,需要考虑特定的行
为.
6. 操作概貌
本节只作描述.标准行为在8和9节中描述.
图1:STUN配置
图1显示了典型的STUN配置.STUN客户连接到私有网络1.该网络又通过NAT1连
接到私我网络2.私有网络2又通过NAT2连接到公共互联网.STUN服务器位于公共互联
网上.
STUN是个简单的客户—服务器协议.客户向服务器发送请求,接着服务器返回响应.
有两种类型的请求—捆绑请求,通过UDP发送,和共享私密请求,通过TLS TCP[2].共享
私密请求叫服务器返回临时的用户名和密码.该用户名和密码用于后序的捆绑请求和捆绑响
STUN
服务器
NAT2
NAT1
公共互联网
私有网络2
STUN
客户
私有网络1
RFC 3489 STUN 2003年3月
Rosenberg等 6页
应,其目的是认证和检验消息的完整性.
捆绑请求用来获得NAT分配的捆绑.客户发送捆绑请求给服务器,通过UDP.服务器
检验该请求的源IP地址和端口号,然后将它们拷贝到回送给该客户的响应中.该请求中还
有一些参数允许客户请求响应发送到其它地方,或者请求服务器从不同的地址和端口发送该
响应.提供了属性来保证消息的完整性并认证.
该诡计就是使用STUN来发现NAT的存在,并获知和使用它们分配的捆绑.
STUN客户一般是嵌入到需要获得可用于接收数据的公共IP地址和端口号的应用程序
中.例如,可能需要获得IP地址和端口号来接收实时传输协议(RTP)[12]流量.当应用程
序开始时,应用程序中的STUN客户发送STUN共享私密请求给他的服务器,获得用户名
和密码,接着向它发送捆绑请求.STUN服务器能够从DNS SRV记录[3]发现,并且通常它
假定客户被配置了该域以发现STUN服务器.通常,这将会应用程序正使用的服务器的提
供者的域(这样的提供者被驱动部署STUN服务器,以允许他的客户可穿过NAT来使用他
的应用程序).当然,客户能够通过其它途径来判断STUN的地址或域名.STUN服务器甚
至可以嵌入到终端系统中.
STUN捆绑请求用于发现NAT的存在,并发现NAT生成的公共IP地址和端口号映射.
捆绑请求通过UDP发送给STUN服务器.当捆绑请求到达STUN服务器,它可能已经在
STUN客户和STUN服务器间通过了一个或更多个NAT.其结果是,服务器收到的请求的
源地址将会是由离服务器最近的NAT创建的映射过的地址.STUN服务器拷贝该源IP地址
和端口号到STUN的捆绑响应中,并回送给STUN请求的源IP地址和端口号.对于上面的
所有NAT类型,该响应将会到达STUN客户.
当STUN客户收到STUN捆绑响应,它将数据包中的IP地址和端口号与请求发送时他
绑定的本地IP地址和端口号相比较.如果这些不匹配,则STUN客户位于一个或更多个NAT
之后.在完全锥形NAT的情况下,STUN响应体内的IP地址和端口号是公共的,并且能够
被公共互联网上的任何主机用来向发送该STUN请求的应用程序发送数据包.应用程序只
需监听从STUN请求发送地来的IP地址和端口号.任何公共互联网上的主机发送到STUN
获知的公共地址和端口号的数据包将会被该应用程序收到.
当希,主机可能不在完全锥形NAT之后.其实,他也不知道他位于其后的NAT的类型.
要作出判断,客户使用附加的STUN捆绑请求.确切的过程是灵活的,但一般工作如下.
客户将发送第二个STUN捆绑请求,这时到一个不同的IP地址,但是从相同的源IP地址和
端口.如果响应中的IP地址和端口号与第一次的响应不同,客户就知道他位于对称NAT之
后.发判断是否在完全锥形NAT之后,客户可发送设置标志的STUN捆绑请示.该标志使
STUN服务器从与请求接收到的不同的IP地址和端口号发送响应.换句话说,如果客户使
用为X/Y的源IP地址/端口号向IP地址/端口号A/B发送捆绑请求,STUN服务器将使用源
IP地址/端口号C/D发送捆绑响应给X/Y.如果客户收到该响应,他就知道他在完全锥形NAT
之后.
STUN还允许客户使服务器从与收到请求相同的IP地址,但用不同的端口号发送捆绑
响应.这可用来检测客户是否在端口限制锥形NAT或只在限制锥形NAT之后.
RFC 3489 STUN 2003年3月
Rosenberg等 7页
要指出的是,图1中的配置不是唯一许可的配置.STUN服务器可在任何地方,包括在
另一个客户中.唯一的要求是,STUN服务器可被客户访问,并且如果客户要尝试获取公共
可路由的地址,则服务器应在公共互联网上.
7. 消息概貌
STUN消息是用TLV(类型—长度—值)编码的,使用大端字节序(网络字节序).所
有的STUN消息开始于STUN头,接着是STUN负载.负载是一系列的STUN属性,它的
集合由消息的类型决定.STUN头包含STUN消息类型,事务ID和长度.消息类型可以是
捆绑请求,捆绑响应,捆绑错误响应,共享私密请求,共享私密响应,或共享私密错误响应.
务ID用来关联请求和响应.长度指示STUN负载的总长度,不包括头.允许STUN运行
在TCP上.共享私密请求经常通过TCP发送(其实,是使用在TCP上的TLS).
定义了几个STUN属性.第一个是MAPPED-ADDRESS属性,这是IP地址和端口号.
它经常放在捆绑响应中,并且表示服务器看见的捆绑请求的源IP地址和端口号.还有一个
RESPONSE-ADDRESS属性,可以出现在捆绑请求中,且表示捆绑响应发送的目的地.它
是可选的,如果不存在,捆绑响应应发送给捆绑请求的源IP地址和端口号.
第3个是CHANGE-REQUEST属性,且它包含两个标志来控制用来发送响应的IP地址
和端口号.这些标志称为"改变IP"和"改变端口号"标志.CHANGE-REQUEST属性只
允许在捆绑请求中."改变IP"和"改变端口号"标志对于判断客户是否在限制锥形NAT
或限制端口锥形NAT之后是有用的.它们命令服务器从不同的源IP地址和端口号发送捆绑
响应.CHANGE-REQUEST属性在捆绑请求中是可选的.
第4个属性是CHANGED-ADDRESS属性.它存在于捆绑响应中.它表明,如果客户
请求了"改变IP"和"改变端口号"行为,客户应该使用的源IP地址和端口号.
第5个属性是SOURCE-ADDRESS属性.它只存在于捆绑响应中.它表明响应发送的
源IP地址和端口号.用于检测两次NAT的配置.
第6个属性是USERNAME属性.它存在于共享私密响应中.它为客户提供一个临时的
用户名和密码(在PASSWORD属性中编码).USERNAME还存在于捆绑请求中,用作共
享私密的索引,并用来对捆绑请求进行完整性保护.第7个属性,PASSWORD,只存在于
共享私密响应消息中.第8个属性是MESSAGE-INTEGRITY属性.它包含检查捆绑请求和
捆绑响应的完整性的消息.
第9个属性是ERROR-CODE属性.它存在于捆绑错误响应和共享私密错误响应中.它
指示所发生的错误.第10个属性是UNKNOWN-ATTRIBUTES属性,它存在于捆绑错误响
应或共享私密错误响应中.它表明请求的命令属性未知.第11个属性是REFLECTED-FROM
属性,存在于捆绑响应中.表明捆绑请求发送者的IP地址和端口号,用于阻止并跟踪某类
拒绝服务器攻击.
8. 服务器行为
RFC 3489 STUN 2003年3月
Rosenberg等 8页
服务器行为取决于请求是捆绑请求,还是共享私密请求.
8.1 捆绑请求
STUN服务器MUST准备接好收捆绑请求,在4个地址/端口号组合上,(A1,P1),(A2,