NAT traversal with session border controllers

Last updated

Network address translators (NAT) are used to overcome the lack of IPv4 address availability by hiding an enterprise or even an operator's network behind one or few IP addresses. The devices behind the NAT use private IP addresses that are not routable in the public Internet. The Session Initiation Protocol (SIP) has established itself as the de facto standard for voice over IP (VoIP) communication. [1] In order to establish a call, a caller sends a SIP message, which contains its own IP address. The callee is supposed to reply back with a SIP message destined to the IP addresses included in the received SIP message. This will obviously not work if the caller is behind a NAT and is using a private IP address.

Contents

Probably the single biggest mistake in SIP design was ignoring the existence of NATs. This error came from a belief in IETF leadership that IP address space would be exhausted more rapidly and would necessitate global upgrade to IPv6 and eliminate the need for NATs. The SIP standard has assumed that NATs do not exist, an assumption, which turned out to be a failure. SIP simply didn't work for the majority of Internet users who are behind NATs. At the same time it became apparent that the standardization life-cycle is slower than how the market ticks: Session Border Controllers (SBC) [2] were born, and began to fix what the standards failed to do: NAT traversal.

In case a user agent is located behind a NAT then it will use a private IP address as its contact address in the contact and via headers as well as the SDP part. This information would then be useless for anyone trying to contact this user agent from the public Internet.

There are different NAT traversal solutions such as STUN, TURN and ICE. [3] Which solution to use depends on the behavior of the NAT and the call scenario. When using an SBC to solve the NAT traversal issues the most common approach for SBC is to act as the public interface of the user agents. [4] This is achieved by replacing the user agent's contact information with those of the SBC.

SBC handling of user registration and NAT traversal

NAT traversal handling with SBC during call establishment SBC NAT Call Handling.jpg
NAT traversal handling with SBC during call establishment

In order for a user agent to be reachable through the public interfaces of an SBC, the SBC will manipulate the registration information of the user agent. The user includes its private IP address as its contact information in the REGISTER requests. Calls to this address will fail, since it is not publicly routable. The SBC replaces the information in the contact header with its own IP address. This is the information that is then registered at the registrar. Calls destined to the user will then be directed to the SBC.

In order for the SBC to know which user agent is actually being contacted the SBC can keep a local copy of the user agent's registration. The local copy includes the private IP address and the user's SIP URI as well as the public IP address included in the IP header that was assigned to the SIP message by the NAT.

Alternatively the SBC can store this information in the forwarded SIP messages. This is displayed in the figure here. The user's contact information is combined in a special format and added as an additional parameter to the contact header. The contact information include the user's private IP address and SIP URI as well as the public IP address in the IP header of the SIP message. When the registrar receives a request for the user, the registrar will return the complete contact information to the proxy, which will include this information in the SIP message. The SBC can then retrieve this information from the SIP request and use it to properly route the request to the user.

Adding the user agent's contact information to the registered contact information has many advantages. As the SBC does not have to keep local registration information this solution is simple to implement and does not require memory for keeping the information. Further, requests destined to the user agent do not necessarily have to traverse the SBC that has processed the user agent's registration messages. Any SBC that can reach the user agent can correctly route messages destined to the user agent based on the information included in the SIP request. This advantage applies, however, only in some cases. In case the NAT used in front of the user agent accepts traffic only from the IP addresses which the user agent has contacted previously then only the SBC that has processed the user agent's REGISTER requests will be able to contact the user agent.

The other option is to keep a local copy of the registration information which can, however, increase the processing requirements on the SBC. The SBC will have to manage a local registration database. Beside the memory requirements the SBC will have to replicate this information to a backup system if it is to be highly available. This will further increase the processing requirements on the SBC and increase the bandwidth consumption.

However, keeping a local copy of the registration information has its advantages as well. When receiving a message from a user agent a network address translator binds the private IP address of the user agent to a public IP address. This binding will remain active for a period of time –binding period. In case the user agent does not send or receive any messages for a period of time longer than the binding period then the NAT will delete the binding and the user agent will no longer be reachable from the outside. To keep the binding active, the user agent will have to regularly refresh it. This is achieved by sending REGISTER requests at time intervals shorter than the binding period. As REGISTER messages have to be usually authenticated, having to deal with REGISTER messages sent at a high frequency would impose a high performance hit on the operator's infrastructure. SBCs can help to offload this load. When a user agent sends the first REGISTER request, the SBC forwards the REGISTER request to the operator's registration servers. Once the registration was successfully authenticated and accepted by the operator, the SBC will keep a local copy of the registration information. Instead of forwarding each incoming REGIETER request to the operator's registration servers, the SBC will only send REGISTER requests to the registration servers at rather large time intervals (in the range of hours). Registration requests arriving from the user agent that do not change the content registration information will be replied to by the SBC itself. The SBC will also inform the registration server once the local registration expires or changes.

SBC handling of call establishment and NAT traversal

NAT traversal with SBC during user registration SBC NAT Registration Handling.jpg
NAT traversal with SBC during user registration

Similar to the registration case, the SBC will also include itself in the path of INVITE and other request messages. When receiving an INVITE from a user agent behind a NAT, the SBC will include a via header with its own address, replace the information in the contact header with its own address and also replace the address information in the SDP body with its own address. Thereby, all SIP messages and media packets will traverse the SBC.

SBC handling of media packets and NAT traversal

After the establishment of a call using SIP, media packets, namely voice, video or data are exchanged -usually using the Real-time Transport Protocol (RTP) While NAT traversal of SIP messages may appear complicated after all, the yet more complex task is enabling media to traverse NATs. The initial problem statement is the same. If SIP devices behind NATs advertise their IP addresses, their peers on the other side of NATs cannot route traffic to them. The solution SBCs came with simply ignores the way SIP works. Instead of sending media to the IP address and port number advertised in the SIP SDP bodies, SBCs send media for a user agent symmetrically back to where the agent has sent its own media from. This symmetric communication typically works because it is the traffic pattern NAT manufactures have been used to before the arrival of VoIP.

It is important to know that while this mostly works, it has several limitations. First of all, it only works with clients that are built "symmetric way", i.e., they use the same port for sending and receiving media. Nowadays that's fortunately the majority of available equipment.

The other noticeable disadvantage is "triangular routing": an SBC must relay all VoIP traffic for a call, to make the paths caller-SBC and SBC-callee symmetric. That is in fact quite an overhead for a VoIP operator. With the most common codec, G.711, a relayed call consumes four 87.2 kbit/s streams: two outbound, two inbound.

Some other disturbing limitations may occur too. For example, if a SIP device uses voice activity detection (VAD) and fails to send any voice packets initially, the SBC will not learn its address and will not forward incoming media to it as well.

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

<span class="mw-page-title-main">Network address translation</span> Protocol facilitating connection of one IP address space to another

Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was originally used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the network's address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.

Voice over Internet Protocol (VoIP), also called IP telephony, is a method and group of technologies for voice calls, the delivery of voice communication sessions over Internet Protocol (IP) networks, such as the Internet.

Telephone number mapping is a system of unifying the international telephone number system of the public switched telephone network with the Internet addressing and identification name spaces. Internationally, telephone numbers are systematically organized by the E.164 standard, while the Internet uses the Domain Name System (DNS) for linking domain names to IP addresses and other resource information. Telephone number mapping systems provide facilities to determine applicable Internet communications servers responsible for servicing a given telephone number using DNS queries.

STUN is a standardized set of methods, including a network protocol, for traversal of network address translator (NAT) gateways in applications of real-time voice, video, messaging, and other interactive communications.

Mobile IP is an Internet Engineering Task Force (IETF) standard communications protocol that is designed to allow mobile device users to move from one network to another while maintaining a permanent IP address. Mobile IP for IPv4 is described in IETF RFC 5944, and extensions are defined in IETF RFC 4721. Mobile IPv6, the IP mobility implementation for the next generation of the Internet Protocol, IPv6, is described in RFC 6275.

The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is a standardised architectural framework for delivering IP multimedia services. Historically, mobile phones have provided voice call services over a circuit-switched-style network, rather than strictly over an IP packet-switched network. Alternative methods of delivering voice (VoIP) or other multimedia services have become available on smartphones, but they have not become standardized across the industry. IMS is an architectural framework that provides such standardization.

A session border controller (SBC) is a network element deployed to protect SIP based voice over Internet Protocol (VoIP) networks.

<span class="mw-page-title-main">VoIP phone</span> Phone using one or more VoIP technologies

A VoIP phone or IP phone uses voice over IP technologies for placing and transmitting telephone calls over an IP network, such as the Internet. This is in contrast to a standard phone which uses the traditional public switched telephone network (PSTN).

Network address translation traversal is a computer networking technique of establishing and maintaining Internet Protocol connections across gateways that implement network address translation (NAT).

Traversal Using Relays around NAT (TURN) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. It may be used with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It is most useful for clients on networks masqueraded by symmetric NAT devices. TURN does not aid in running servers on well known ports in the private network through a NAT; it supports the connection of a user behind a NAT to only a single peer, as in telephony, for example.

Interactive Connectivity Establishment (ICE) is a technique used in computer networking to find ways for two computers to talk to each other as directly as possible in peer-to-peer networking. This is most commonly used for interactive media such as Voice over Internet Protocol (VoIP), peer-to-peer communications, video, and instant messaging. In such applications, communicating through a central server would be slow and expensive, but direct communication between client applications on the Internet is very tricky due to network address translators (NATs), firewalls, and other network barriers.

A middlebox is a computer networking device that transforms, inspects, filters, and manipulates traffic for purposes other than packet forwarding. Examples of middleboxes include firewalls, network address translators (NATs), load balancers, and deep packet inspection (DPI) devices.

An application-level gateway is a security component that augments a firewall or NAT employed in a computer network. It allows customized NAT traversal filters to be plugged into the gateway to support address and port translation for certain application layer "control/data" protocols such as FTP, BitTorrent, SIP, RTSP, file transfer in IM applications. In order for these protocols to work through NAT or a firewall, either the application has to know about an address/port number combination that allows incoming packets, or the NAT has to monitor the control traffic and open up port mappings dynamically as required. Legitimate application data can thus be passed through the security checks of the firewall or NAT that would have otherwise restricted the traffic for not meeting its limited filter criteria.

<span class="mw-page-title-main">H.323</span> Audio-visual communication signaling protocol

H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols to provide audio-visual communication sessions on any packet network. The H.323 standard addresses call signaling and control, multimedia transport and control, and bandwidth control for point-to-point and multi-point conferences.

An INVITE of Death is a type of attack on a VoIP-system that involves sending a malformed or otherwise malicious SIP INVITE request to a telephony server, resulting in a crash of that server. Because telephony is usually a critical application, this damage causes significant disruption to the users and poses tremendous acceptance problems with VoIP. These kinds of attacks do not necessarily affect only SIP-based systems; all implementations with vulnerabilities in the VoIP area are affected. The DoS attack can also be transported in other messages than INVITE. For example, in December 2007 there was a report about a vulnerability in the BYE message by using an obsolete header with the name "Also". However, sending INVITE packets is the most popular way of attacking telephony systems. The name is a reference to the ping of death attack that caused serious trouble in 1995–1997.

The Session Initiation Protocol (SIP) is the signaling protocol selected by the 3rd Generation Partnership Project (3GPP) to create and control multimedia sessions with multiple participants in the IP Multimedia Subsystem (IMS). It is therefore a key element in the IMS framework.

STIR/SHAKEN, or SHAKEN/STIR, is a suite of protocols and procedures intended to combat caller ID spoofing on public telephone networks. Caller ID spoofing is used by robocallers to mask their identity or to make it appear the call is from a legitimate source, often a nearby phone number with the same area code and exchange, or from well-known agencies like the Internal Revenue Service or Ontario Provincial Police. This sort of spoofing is common for calls originating from voice-over-IP (VoIP) systems, which can be located anywhere in the world.

References

  1. ↑ Sinnreich, Henry; Johnston, Alan B. (2001), Internet Communication Using SIP, Wiley, p. 180, ISBN   0-471-77657-2
  2. ↑ "Understanding Session Border Controllers" (PDF).
  3. ↑ Rosenberg, J. (April 2010). Interactive connectivity establishment (ICE): a protocol for network address translator (NAT) traversal for offer/answer protocols. IETF. RFC 5245
  4. ↑ Hautakorpi, J.; Camarillo, G.; Penfield, R.; Hawrylyshen, A.; Bhatia, M. (April 2010). Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments. IETF. RFC 5853
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.