STUN, TURN & ICE for NAT Traversal

A setback to IP and Video connectivity has been the restriction NATs and firewalls pose to reliable call completion. NATs and firewalls play a very important role in securing and enhancing the usability of internal networks, however impose significant problems in setting up IP endpoints.  IETF standards STUN, TURN and ICE were developed to address the NAT traversal problem.

nattraversal

STUN helps connect IP end-points:

  • discover whether they are behind a NAT/firewall, and if so,

  • to determine the public IP address and type of the firewall. STUN then uses this information to assist in establishing peer-to-peer IP connectivity.

While STUN is effective in addressing the NAT issue with most consumer NAT devices (routers), it doesn’t work effectively for many corporate networks. TURN, which stands for Traversal Using Relay NAT, addresses this by providing a fallback NAT traversal technique using a media relay server to facilitate media transport between end-points.

ICE is a framework that leverages both STUN and TURN to provide reliable IP  set-up and media transport, through a SIP offer/answer model for end-points to exchange multiple candidate IP addresses and ports (such as private addresses and TURN server addresses).

Eyeball Networks patented AnyFirewall Technology is at the core of several Eyeball Networks products that utilize the STUN, TURN and ICE standards, and our AnyFirewall Engine and AnyFirewall Server are the reference software for PacketCable 2.0 certification.

STUN TURN ICE Guaranteed Connectivity

Eyeball Networks Solutions for NAT Traversal

Eyeball Networks has several products that exploit the advantages of STUN, TURN, ICE to deliver reliable IP services, including:

AnyFirewall Engine

STUN TURN ICE Library for
Guaranteed IP Connectivity

AFS_full_web90px

STUN TURN Server Software for
Guaranteed IP Connectivity

AnyConnect-gatewayl

Enterprise Border Session Controller
for Network Inter-Connectivity

Benefits to Eyeball Networks implementation of the STUN, TURN and ICE standards

  • Guaranteed 100% call completion

  • Peer-to-peer for services scalable to 50M + subscribers

  • No compromise in NAT/firewall security

  • Easy integration with existing IP products and services

  • Standards based for maximum interoperability

  • Massive scalability for carrier-class implementations

  • Media delivery in UDP networks

STUN TURN ICE Standards

There are several important standards related to NAT traversal, and STUN, TURN, ICE implementations. Eyeball Networks technology supports and is compliant with the following standards:

  • RFC 5245 – ICE

  • RFC 5389 – STUN

  • RFC 5766 – TURN

  • RFC 5768 – ICE – SIP

  • RFC 6336 – ICE – IANA Registry

  • RFC 6544 – ICE – TCP

  • RFC 5928 – TURN Resolution Mechanism

  • RFC 6062 – TURN Extensions for TCP Allocations

  • RFC 6156 – Extension for IPv6

  • MS-STUN – Microsoft STUN extensions

  • MS-TURN – Microsoft TURN extensions

  • MS-ICE – Microsoft ICE extensions

  • MS-ICE2 – Microsoft ICE2 extensions

What is a NAT?

NAT stands for Network Address Translation. In general, it is the process used by routers to modify IP information by translating local IP addresses on a private subnet to public IP addresses typically assigned by an Internet service provider (ISP). They present a major challenge when attempting to establish direct connections between clients on a network.

There are four types of NATs present in today’s routers, presented in order from least restrictive to most restrictive:

Full cone

  • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent through eAddr:ePort. Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.

Address-restricted cone

  • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent through eAddr:ePort. An external host (hAddr:any) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:any. “Any” means the port number doesn’t matter.

Port-restricted cone (like address-restricted cone, but the restriction includes port numbers)

  • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent through eAddr:ePort. An external host (hAddr:hPort) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:hPort.

Symmetric

  • Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port, if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used. Only an external host that receives a packet from an internal host can send a packet back.

The techniques necessary to establish a direct connection between peers become more challenging as the NATs between them become more restrictive. In the worst case, a relay with a public IP address is needed to exchange packets between peers.

What is STUN?

STUN stands for Session Traversal Utilities for NAT. It is a network protocol/packet format (IETF RFC 5389) used by NAT traversal algorithms to assist in the discovery of network environment details. Messenger uses STUN packets when communicating with the Messenger server and other Messenger clients.

If the routers between peers use full cone, address-restricted, or port-restricted NAT, then a direct link can be discovered with STUN alone. If either one of the routers use symmetric NAT, then a link can be discovered with STUN packets only if the other router does not use symmetric or port-restricted NAT. Not to fear, though! If this is the case, Messenger will automatically discover a relayed path through the use of TURN.

What is TURN?

TURN stands for Traversal Using Relays around NAT. Like STUN, it is a network protocol/packet format (IETF RFC 5766) used to assist in the discovery of paths between peers on the Internet. It differs from STUN in that it uses a public intermediary relay to relay packets between peers. Messenger uses TURN to exchange media stream packets when no other option is available since it consumes server resources and has an increased latency due to the extra step.

The only time when TURN is necessary is when one of the peers is behind a symmetric NAT and the other peer is behind either a symmetric NAT or port-restricted NAT. The frequency of cases where a relay is necessary is difficult to pin down, but is estimated to be around 8% (source).

What is ICE?

ICE stands for Interactive Connectivity Establishment. It defines a technique that uses SDP, STUN, and TURN to discover a network path between peers on the Internet. Messenger implements the ICE specification (IETF RFC 5245) and as such, is compatible with other clients that implement the same spec.

Each RTP packet has a 7-bit payload type (0-127) and a binary payload. The payload type is used to identify the format of the payload, and is defined when constructing an Messenger connection. IANA has set aside some payload types for specific formats. If you are using an encoding format recognized by IANA, it is recommended that you use the corresponding payload type. If you are using an encoding format NOT recognized by IANA, it is recommended that you use a value in the range 96-127, per their recommendations. The only restriction enforced by Messenger is that payload types 72-76 are reserved for RTCP. These payload types may not be used as it would interfere with internal RTCP processing.

Trusted by tier one companies around the world, AnyFirewall Technology is embedded in products used by 98% of the Fortune 500 and 100% of the Fortune 100.

Eyeball-customers-300x182