Most computers now after the hosts behind a firewall or NAT, there is little direct computer access to Internet. Usually, people want to network two days computers can communicate (direct P2P communication ), rather than the need to transfer to other public servers.
After the host since the NAT or a firewall, before performing P2P communication, the need for testing to confirm whether P2P communication and how the communication between them. This technique is commonly referred to as a NAT-Traversal (NAT Traversal) . The most common is based on UDP NAT traversal technologies such as RFC3489 STUN protocol defined.
NAT treatment of UDP implementations:
- Full Cone NAT:
full cone NAT, from all mappings from a request sent over the same IP network and a port number are the same as the external network IP and port number, and any of a host outside the network are mapped by the external network and port number of IP packets to this internal host. - Restricted Cone NAT:
restricted cone NAT, from which a request is transmitted from all be mapped over the same IP network and a port number are the same as the external network IP and port number. Completely different from the tapered and is only able to external host had previously sent a packet to its previous host within the network packet transmission. - Port Restricted Cone NAT:
port cone NAT restrictions, and limitations cone NAT is very similar, except that it includes a port number. In other words, an IP address outside the network host ports X and P wants to send packets to host within the network, this must be within the network host has previously been given the IP address X and port P sent a packet. - Symmetric NAT:
Symmetric the NAT, all requests from the transmission to a specific destination IP port number and the same IP network and a port number, are mapped to the same IP and port number. If the same host using the same source address and port number of the packet, but sent to a different destination, the NAT will use different mappings. Further, only the received data external host can send packet network server in turn inwardly.
A, STUN Detailed
The STUN, first in RFC3489 definition, as a complete NAT traversal solution is the English name Simple Traversal of UDP Through NATs, i.e. simply using UDP through NAT . Is a lightweight protocol is based on UDP through NAT on the complete solution. It allows applications to discover the existence between them and the public Internet and other types of NAT and firewalls. It also allows the application to determine the NAT assigned to their public IP address and port number.
In the new revision to RFC5389 STUN protocol is positioned to provide tools for traditional NAT , but not a complete solution, that is, NAT session penetrate utility (Session Traversal Utilities for NAT). RFC5389 and RFC3489 in addition to the name change, the biggest difference is the support for TCP penetration .
1、RFC3489/STUN
STUN is a protocol / Server's Client, also a / Response protocol Request, the default port number is 3478.
(1) packet structure
Ø [header]
All STUN messages contain message header byte 20: 16-bit message type (the MessageType) , the 16-bit message length (MessageLength) , 128-bit transaction ID (the Transaction ID) .
Message Type allowable value: 0x0001 (bundled request), 0x0101 (binding response), 0x0111 (error response bundled), 0x0002 (shared secret request), 0x0102 (shared secret response), 0x0112 (error response shared secret).
Message length: the size of the message bytes, not including the 20-byte header.
Transaction ID: 128 bit identifier, and in response to random requests, a request response corresponding with all with the same identifier.
Ø Message Properties []
After the header is 0 or more attributes, each attribute TLV encoding, including 16-bit attribute type, attribute length, and the 16-bit variable-length attribute value.
Property type definitions:
- ADDRESS-the MAPPED: the MAPPED-ADDRESS attribute represents the mapped IP address and port. It includes an 8-bit group address, port number and 16-bit fixed-length IP addresses.
- ADDRESS-the RESPONSE: the RESPONSE-ADDRESS attribute indicates the destination address of the response
- CHASNGE-REQUEST: the client 32 using the CHANGE-REQUEST attribute to send a response request to the server using a different address or port number.
- ADDRESS-the SOURCE: the SOURCE ADDRESS attribute appears in the bundling-response, the server sends a response that represents the source IP address and port.
- CHANGED-ADDRESS: the CHANGE-bundle if the REQUEST request attribute "change IP" and "change port" flag is set, the CHANGED-ADDRESS attribute indicates the IP address and port number sent in response.
- USERNAME: USERNAME attribute checks the integrity of the message, a message integrity check identify the shared secret. USERNAME shared secret usually appears in the response, together with the PASSWORD. When a message integrity check, may optionally appear in the bundle request.
- PASSWORD: PASSWORD attribute with the shared secret in response, together with USERNAME. PASSWORD value is variable length, as a shared secret, its length must be a multiple of 4 bytes, aligned to ensure that the boundary property.
- INTEGRITY-the MESSAGE: the MESSAGE-INTEGRITY attribute contains the HMAC-SHA1 STUN message, which may occur in the bundle or bundled request response; MESSAGE-INTEGRITY attribute must be the last attribute any STUN message. Its content determines the value HMAC Key input.
- CODE-ERROR: ERROR-CODE attribute appears in response to an error or the shared secret bundling the error response. Its response number from the numerical range 100-699.
- ATTRIBUTES-UNKNOWN: UNKNOWN-ATTRIBUTES attribute thereof in response to the presence of only the number ERROR-CODE attribute bundle 420 in response to an error or the error response the shared secret.
- The FROM-the REFLECTED: the REFLECTED the FROM-binding property is present only in response to a request to its corresponding bundle comprising RESPONSE-ADDRESS attribute. Attribute contains the source IP address of the request issued, its object is to provide traceability, so can not be used as a DOS attack STUN reflector.
Specific ERROR-CODE (response number), with their default reason statement together, the current is defined as follows:
- 400 (Error Request): Request deformed. The customer in front of previous attempts to modify should not retry the request.
- 401 (Unauthorized): bundling the request contains no MESSAGE-INTERITY property.
- 420 (Unknown Attribute): The server does not know the request mandatory attributes.
- 430 (expired eligibility): Bundle request did not contain MESSAGE-INTEGRITY attribute, but it uses outdated
- Shared secret. Customers should obtain a new shared secret and retry again.
- 431 (integrity check fails): bundling request contains MESSAGE-INTEGRITY attribute, but experience HMAC
- Authentication failed. This may be the performance potential attacks, or client implementation error
- 432 (loss username): bundling request contains MESSAGE-INTEGRITY attribute, but no
- USERNAME attribute. Integrity check two must be present.
- 433 (using TLS): a shared secret request has been through TLS (Transport Layer Security, namely security
- Transport layer protocol) sent but not received on TLS.
- 500 (Server Error): The server encountered a temporary error, customers should try again.
- 600 (global failure): server refused to fulfill the request, the client should not retry.
Attribute space is divided into an optional part of the forced portion, the value exceeding 0x7fff attribute is optional , i.e., client or server, even if not recognize this attribute can process the message; value is less than or equal 0x7fff attribute is mandatory appreciated that, unless understand the property, otherwise the client or the server can not process the message.
(2) The principle
Full interaction STUN protocol is as follows:
STUN protocol specific implementation steps:
一般情况下，客户会配置STUN服务器提供者的域名，该域名被解析为IP地址和SRV过程的端口号。
服务器名是“stun”，使用UDP协议发送捆绑请求，使用TCP协议发送共享私密请求。STUN协议的缺省端口号为3478。若要提供完整性检查，STUN在客户和服务器间使用128位的共享私密，作为捆绑请求和捆绑响应中的密匙。
首先，客户通过发现过程获得它将与之建立TCP连接的IP地址和端口号。客户打开该地址和端口的连接，开始TLS协商，验证服务器的标识。客户发送共享私密请求。该请求没有属性，只有头。服务器生成响应。客户会在该连接上生成多个请求，但在获得用户名和密码后关闭该连接。
其次，服务器收到共享私密请求，验证从TLS连接上到达的该请求；如果不是通过TLS收到的请求，则生成共享私密错误响应，并设置ERROR-CODE属性为响应号433；这里区分两种情况：若通过TCP收到请求，则错误响应通过收到请求的相同连接发送；若通过UDP收到请求，则错误响应发送回请求送出的源IP和端口。
服务器检查请求中的任何属性，当其中有不理解的小于或等于0x7fff的值，则生成共享私密错误响应，设置ERROR-CODE属性为响应号420,并包括UNKNOWN-ATTRIBUTE属性，列出它不理解的小于或等于0x7fff的属性的值。该错误响应通过TLS连接发送。
然后，若请求正确，服务器创建共享私密响应，包含与请求中相同的事务ID，并包含USERNAME和PASSWORD属性。用户名在10分钟内有效。共享私密响应通过与收到请求的相同的TLS连接发送，服务器保持连接打开状态，由客户关闭它。
接着，客户发送捆绑请求，携带的属性包括：
- 可选属性：RESPONSE-ADDRESS属性和CHANGE-REQUEST属性；
- 强制属性：MESSAGE-INTEGRITY属性和USERNAME属性。
客户发送捆绑请求，通过客户重传来提供可靠性。客户开始用100ms的间隔重传，每次重传间隔加倍，直至1.6秒。之间间隔1.6秒的重传继续，直到收到响应或总共已经发送了9次。因此，若9500ms后，还未收到响应，客户认为传输已经失败。
随后，服务器检查捆绑请求的MESSAGE-INTEGRITY属性，不存在则生成捆绑错误响应，设置ERROR-CODE属性为响应号401；若存在，计算请求的HMACKey值。
服务器检查USERNAME属性，不存在则生成捆绑错误响应，设置ERROR-CODE属性为响应号432；若存在，但不认识该USERNAME的共享私密（例如，它超时了），生成捆绑错误响应，设置ERROR-CODE属性为响应号430。
服务器如知道该共享私密，计算HMAC与请求是否相同，如果相同生成捆绑错误响应，设置ERROR-CODE属性为响应号431。
假设消息完整性检查通过了，服务器检查请求中的任何属性的值，若遇到不理解的小于或等于0x7fff的值，生成捆绑错误响应，设置ERROR-CODE属性为响应号420，该响应包含UNKNOWN-ATTRIBUTE属性，并列出不理解的小于或等于0x7fff的属性。
若请求正确，服务器生成单个捆绑响应，包含与捆绑请求相同的事务ID。服务器在捆绑响应中加入MAPPED-ADDRESS属性，该属性的IP地址和端口号为捆绑请求的源IP地址和端口号。
捆绑响应的源地址和端口号取决于捆绑请求中CHANGE-REQUEST属性的值及捆绑请求收到的地址和端口号相关。
（3）总结
服务器在捆绑响应中加入SOURCE-ADDRESS属性，包含用于发送捆绑响应的源地址和端口号；加入CHANGED-ADDRESS属性，包含源IP地址和端口号。
如果捆绑请求中包含了USERNAME和MESSAGE-INTEGRITY属性，则服务器在捆绑响应中加入MESSAGE-INTEGRITY属性。
如果捆绑请求包含RESPONSE-ADDRESS属性，则服务器在捆绑响应中加入REFLECTED-FROM属性：如果捆绑请求使用从共享私密请求获得的用户名进行认证，则REFLECTED-FROM属性包含共享私密请求到达的源IP地址和端口号；若请求中的用户名不是使用共享私密分配的，则REFLECTED-FROM属性包含获得该用户名的实体的源IP地址和端口号；若请求中没有用户名，且服务器愿意处理该请求，则REFLECTED-FROM属性包含请求发出的源IP地址和端口号。
服务器不会重传响应，可靠性通过客户周期性地重发请求来保障，每个请求都会触发服务器进行响应。
客户端判断响应的类型是捆绑错误响应还是捆绑响应。捆绑错误响应通常在请求发送的源地址和端口收到；捆绑响应通常在请求中的RESPONSE-ADDRESS属性的地址和端口收到，若没有该属性，则捆绑响应将在请求发送的源地址和端口号收到。
- 若是捆绑错误响应，客户检查响应中的ERROR-CODE属性的响应号：400至499之间的未知属性按属性400处理，500至599之间的未知属性按500处理，600至699之间的未知属性按600处理。任何100和399之间的响应都会使请求重传中止，但其他则忽略；若客户收到响应的属性类型大于0x7fff，则忽略该属性，若小于或等于0x7fff，则请求重传停止，并忽略整个响应；
- 若是捆绑响应，客户检查响应的MESSAGE-INTEGRITY属性：如果不存在，客户在请求中加入MESSAGE-INTEGRITY属性，并放弃该响应；如果存在，客户计算响应的HMAC。如果计算出的HMAC与响应中的不同，则放弃该响应，并警告客户可能受到了攻击；若计算出的HMAC与响应中的匹配，则过程继续；
- 不论收到捆绑响应还是捆绑错误响应，都将中止该请求的重传。客户在第一次响应后继续监听捆绑请求的响应10秒钟，如果这期间它收到任何消息类型不同的响应或不同的MAPPED-ADDRESS属性，它将警告用户可能受到攻击；并且，如果客户收到的捆绑响应次数超过它发送的捆绑请求数的两倍，它将警告用户可能受到攻击；若捆绑响应经过认证，上述攻击并未导致客户丢弃MAPPED-ADDRESS，则客户可以使用该MAPPED-ADDRESS和SOURCE-ADDRESS属性。
（4）STUN功能举例
客户通过带外方式获得STUN服务器信息后，就打开对应的地址和端口的连接，并开始与STUN服务器进行TLS协商。一旦打开了连接，客户就通过TCP协议发送共享私密请求，服务器生成共享私密响应。STUN在客户和服务器间使用共享私密，用作捆绑请求和捆绑响应中的密匙。之后，客户使用UDP协议向STUN服务器发送捆绑请求，当捆绑请求消息到达服务器的时候，它可能经过了一个或者多个NAT。结果是STUN服务器收到的捆绑请求消息的源IP地址被映射成最靠近STUN服务器的NAT的IP地址，STUN服务器把这个源IP地址和端口号复制到一个捆绑响应消息中，发送回拥有这个IP地址和端口号的客户端。
当STUN客户端收到捆绑响应消息之后，它会将自己发送捆绑请求时绑定的本地IP地址和端口号同捆绑响应消息中的IP地址和端口号进行比较，如果不匹配，就表示客户端正处于一个或者多个NAT的前面。
在Full-Cone NAT的情况下，在捆绑响应消息中的IP地址和端口是属于公网的，公网上的任何主机都可以使用这个IP地址和端口号向这个应用程序发送数据包，应用程序只需要在刚才发送捆绑请求的IP地址和端口上监听即可。
当然，客户可能并不在一个Full-Cone NAT的前面，实际上，它并不知道自己在一个什么类型的NAT的前面。为了确定NAT的类型，客户端使用附加的捆绑请求。具体过程是很灵活的，但一般都会像下面这样工作：客户端再发送一个捆绑请求，这次发往另一个IP地址，但是使用的是跟上一次同一个源IP地址和源端口号，如果返回的数据包里面的IP地址和端口号和第一次返回的数据包中的不同，客户端就会知道它是在一个对称NAT的前面。客户端为了确认自己是否在一个完全锥形NAT的前面，客户端可以发送一个带有标志的捆绑请求，这个标志告诉服务器使用另一个IP地址和端口发送捆绑响应。换句话说，如果客户端使X/Y的IP地址端口对向A/B的IP地址端口对发送捆绑请求，服务器就会使用源IP地址和源端口号为C/D的地址端口对向X/Y发送捆绑响应。如果客户端收到了这个响应，它就知道它是在一个Full-Cone NAT前面。
STUN协议允许客户端请求服务器从收到捆绑请求的IP地址往回发捆绑响应，但是要使用不同的端口号。这可以用来检查客户端是否在Port Restricted Cone NAT的前面还是在Restricted Cone NAT的前面。
2、RFC5389/STUN
http://www.52im.net/thread-557-1-1.html
二、TURN详解