244 |
SIP: Understanding the Session Initiation Protocol |
10.6 NAT Mapping Examples
Figure 10.4 shows an example of a NAT. The packet sent from 192.168.0.1:1234 to 2.73.3.2:5678 appears to host 1 to have come from 23.3.2.8:4219. The packet sent from 192.168.0.1:1234 to 62.3.9.9:5678 appears to host 1 to have also come from 23.3.2.8:4219. Since these two mapped addresses are the same, this indicates the NAT is an endpoint independent mapping NAT. Since the internal and external port numbers are different, no port preservation is used. Since the even internal port maps to an odd external port, port parity is also not used by this NAT.
Figure 10.5 shows another example of a NAT, which has two IP addresses assigned to it, 23.3.2.8 and 23.3.2.9. A packet sent from 192.168.0.1:1234 to 2.73.3.2:5678 appears to host 1 to have come from 23.3.2.9:4219. The packet sent from 192.168.0.1:1234 to 62.3.9.9:5678 appears to host 1 to have come from 23.3.2.9:2194. Since this is a different mapped address, this indicates an address dependent mapping NAT.
Figure 10.6 shows another example. The packet sent from 192.168.0.1:1234 to 2.73.3.2:5678 appears to host 1 to have come from 23.3.2.8:4219. The packet sent from 192.168.0.1:1234 to 2.73.3.2:9101 appears to host 1 to have come from 23.3.3.7:6421. Since the mapping is different despite the destination being the same address, this indicates an address and port dependent mapping NAT.
Figure 10.7 shows another example NAT. In this example, the packet sent from 192.168.0.1:1234 to 2.73.3.2:5678 appears to host 1 to have come from
23.3.2.8:4219. The packet sent from 192.168.0.1:1235 to 2.73.3.2:5679 appears
to host 1 to have come from 23.3.2.8:2170. Since these two packets are not sent from the same source address and port, these data provide no information about
Figure 10.4 Example of endpoint independent mapping NAT.
|
|
Network Address Translation |
245 |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 10.5 Example of address dependent mapping NAT.
Figure 10.6 Example of address and port dependent mapping NAT.
the type of mapping used by the NAT. However, this indicates paired IP address pooling. No port preservation is used. No port parity or port contiguity is used.
10.7 NATs and SIP
Now that we have an understanding of what NAT is and how it works, we can look at its impact on applications and protocols such as SIP and RTP. Over-
246 |
|
SIP: Understanding the Session Initiation Protocol |
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 10.7 Example of paired IP address pooling NAT.
all, NATs work reasonably well with unencrypted client/server protocols such as Web browsing, e-mail, and so forth. However, they can cause problems with IPSec VPNs, which can fail signature checks if the signature includes address and port information. Many NATs have application layer gateways (ALGs) for common applications such as FTP (File Transfer Protocol). However, NAT does cause problems for peer-to-peer protocols such as SIP. NATs also cause problems for protocols that carry imbedded IP addresses and port numbers, such as SIP.
Guidelines for NAT-friendly protocol design were published in 2002 in RFC 3235 [7]. However, this was much too late to be helpful for SIP. The main recommendations were as follows:
•Limit peer-to-peer applications and approaches in favor of client/server applications.
•Don’t rely on end-to-end IPSec security.
•Use DNS names not IP addresses.
•Multicast is problematic.
•Avoid session bundles (e.g., one session controlling/establishing another session).
•Use TCP instead of UDP.
Unfortunately, SIP violates most of these recommendations.
Early work on SIP essentially ignored NAT or assumed that IPv6 deployments would cause them to go away. Many properties of SIP assume reflexive routability, which is often not present with NAT. The reality of SIP deployments
Network Address Translation |
247 |
was that while most servers (proxies, registrars, and so forth) had public IP addresses, most UAs were behind NAT and hence had nonroutable private IP addresses. Since the SIP servers provided rendezvous service, typically the SIP exchange would work while the RTP media session would fail.
Early solutions that were examined included application layer gateways (ALGs) which would effectively make NAT SIP-aware. Another early solution was a simple discovery approach in which a UA would send test packets to determine if it was behind a NAT, and to discover mapped addresses. This protocol was STUN [8], which initially stood for simple traversal of UDP through NAT. A STUN client sent test packets (essentially pings) to a STUN server, which responds with the mapped address and port the packet appeared to be received from. STUN will be described in Section 10.9. Using the mapped addresses discovered using STUN, UAs tried to fix the IP addresses and ports in their SIP messages. Unfortunately, this did not work under all scenarios and with all types of NAT. Instead, a back-to-back user agent (B2BUA) approach has developed in the industry to ensure both SIP and RTP traverse NAT.
To overcome the deficiencies of STUN, the IETF developed the Interactive Communications Establishment (ICE) [9], which runs a series of end-to-end tests using STUN between the two UAs attempting to establish communication. This protocol used an approach known as hole punching which was developed by peer-to-peer gamers to establish gaming connections.
10.8 Properties of a Friendly NAT or How a NAT Should BEHAVE
The basic properties of a NAT, which is friendly towards SIP and RTP, is summarized in Table 10.3. The NAT should have endpoint independent mapping, and paired IP address pooling. The port assignment should not do port preservation or port overloading. Port parity preservation and contiguity is good but not essential. The NAT should use endpoint independent or address dependent filtering. The UDP refresh timer should be 5 minutes.
Table 10.3
How a NAT Should BEHAVE
Endpoint independent mapping
Address independent or address dependent filtering
Pair IP address pooling
Not port preservation
Not port overloading
Port parity preservation is helpful
UDP refresh timer 5 minutes