STUN--RFC5389摘要

STUN：Session Traversal Utilities for NAT

1、概述

      RFC3489的劣势：一、NAT穿透有时会失败，但没有失败补救措施；二、NAT分类算法不适用于现代的很多NAT类型；三、安全弱点。

      与RFC3489不同，该文档不再把STUN描述为解决NAT穿透的完整解决方案，而是将STUN作为一种工具集成到其他更完备的解决方案中去，例如本协议的扩展可用于ICE的两个端点之间的连接检测、用于TURN的的两个端点之间的包中转、用于SIP的客户端初始化连接。

      该文档描述的STUN可运行在UDP、TLS/TCP、TCP上。

2、基础

      三种协议实体：STUN客户、STUN服务器、STUN代理。

      STUN是C/S协议，支持两种事务：一、Request/Response事务；二、指示事务（代理发出指示，无响应）。

      STUN消息以固定的头部开始，头部包含一个方法、一个类别、一个事务ID，方法指明各种各样的请求或者指示，RFC5389只定义一种方法（binding），其他方法在其他文档中定义（如RFC5766等）；类别有四种：请求、响应、错误响应、指示；消息头后面跟0个或者多个消息属性。消息头有20个字节，前两位为00，接着是消息类型，它的填充位由消息的方法和消息的类别共同决定的，然后是消息长度，接着是魔术字0x2112A442，最后是96位的事务ID。

      Binding方法可以使STUN Client学习到NAT公网上的IP地址+端口。

      STUN经常其他协议(ICE、SIP)复用，为区别STUN包，STUN在包头部使用三种有固定值的字段，另外可使用FINGERPRINT区分数据包。

3、基本的协议处理

      形成一个请求消息或者指示消息：

      代理依据固定的格式构造消息头，属性的添加根据不同方法而定。

      发送请求消息或者指示消息：

      通过UDP发送：可靠的请求/响应事务是通过客户端的重传实现的，而指示事务是不可靠的。客户端间隔一个RTO重传一个请求消息，每次重传，重传的间隔加倍。

      通过TCP或者TCP上的TLS：STUN协议层没有重传。对于请求/响应事务，如果Client在它发送SYN建立连接后经过Ti秒没有收到响应，它认为事务已经超时。

      Client可以通过TCP连接发送多个事务，在收到一个请求响应前可能发送其他请求，因此Client应该保持连接的打开状态，只有满足下述条件时，才关闭。一、没有其他的请求或者指示通过此连接发送；二、该连接发出的STUN请求，没有学习到任何资源（映射地址或者中转地址）；三、如果该端口复用了其他层的协议，等协议完成；四、使用与远程伙伴通讯相关联的端口已完成。

      接受STUN消息：

      当代理收到STUN消息后，首先检查消息，了解它是否合法，它的方法、它的类别、检查魔术字、事务ID等。不同的STUN方法中带有响应的属性，接下来就检查属性。

      处理请求：

      识别属性，不认识的回复420错误码。另外，Server需要关注不存储事务状态的前提下的请求重传的实现。

      形成成功或者错误的响应并回传给客户：

      同RFC3489差不多，只是RFC5389中加入了一些新的机制，如鉴权机制、指纹机制、备份服务器机制等，这些机制都对应着自己特有的消息属性。

4、与RFC3489的主要区别

      一、STUN的定义、用途的区别

     二、去掉了STUN的NAT类型检测，绑定生命周期发现的方法，相应的也去掉了一些消息属性

     三、消息头结构字段的变化

     四、增加指纹属性提供一种明确的方法来检测在STUN协议多路复用时，STUN与其他协议之间的差异

     五、支持ipv6

     六、增加长期证书认证机制

     七、去掉了共享私密方法

      八、增加了一些新属性：SOFTWARE、REALM、NONCE、ALTERNATE-SERVER

      九、去掉了使用连续10s侦听STUN响应来识别攻击的做法

      十、为TCP和TLS改变了DNS SRV的流程