|
|
14.6. NAT TraversalWe have already seen several instances of interactions between IPsec and NAT/PAT that result in operability problems.
RFC 3715 [Aboba and Dixon 2004] discusses these problems at length and remarks that attempts to solve them with NAT alone have not been completely successful and in some cases have made the problems worse. In this section, we discuss a relatively new solution, NAT-Traversal (NAT-T) that addresses many of these issues. Most of the interoperability difficulties between IPsec and NAT involve one or more of the following facts.
Because not much can be done about the first problem, NAT-T concerns itself only with ESP and IKE. Even with ESP, some common situations don't have a good solution. We look at a couple of these problem areas after we discuss the operation of NAT-T. As we'll see shortly, IPsec peers negotiate the use of NAT-T through IKE. UDP Encapsulation of ESP and IKEWhen NAT-T is used, ESP packets, whether in transport or tunnel mode, are encapsulated in UDP packets, as shown in Figure 14.6. The utility of this encapsulation is immediately clear when we consider that PAT now has an unprotected source port that it can remap. Figure 14.6. ESP UDP Encapsulation
RFC 3948 [Huttunen, Swander et al. 2005] specifies that the UDP checksum should be disabled by setting the checksum field to 0 and that this traffic should be sent on the same source and destination port that is used for IKE traffic. The source and destination ports are normally set to 4500, but the source port is subject to remapping by PAT. That means that the peer of a node behind a NAT must send its UDP packets to the remapped port instead of to port 4500. NAT Keep-AlivesOne of the problems that can occur when IPsec and NAT are used together is that the NAT mapping may time out if there is no traffic for a while. To prevent this, an IPsec node behind a NAT must ensure that the connection is not idle for longer than the NAT timeout threshold. The IPsec node does this by periodically sending keep-alive packets to its peer, using the same source and destination ports as the ESP and IKE traffic use. The keep-alive packets are a normal UDP packet with a single byte of 0xff as the payload. A peer receiving a keep-alive packet ignores it, because its only purpose is to prevent the sender's NAT from timing out. As with the encapsulated ESP packet, RFC 3948 specifies that the checksum should be disabled. IKE and NAT-TAs mentioned earlier, the use of NAT-T is negotiated by IKE. Both peers must support NAT-T for this to happen, of course, so they inform each other of their willingness to engage in NAT-T negotiations, by means of Vendor ID payloads, which they send in the first two messages of a phase 1 negotiation. The content of the Vendor ID payload is the MD5 hash of "RFC 3947." RFC 3947 [Kivinen, Swander, Huttunen, and Volpe 2005] specifies the NAT-T negotiation protocol within IKE.
Once the peers have agreed to negotiate NAT-T, they perform NAT discovery, which determines which, if any, of the peers is behind a NAT. They do this by sending NAT Discovery payloads as part of the phase 1 negotiationspecifically, in the third and fourth messages of Main mode or the second and third messages of Aggressive mode. The NAT Discovery (NAT-D) payload, shown in Figure 14.7, is a hash of an IP address and port. Each node sends at least two NAT-D payloads: The first is the hash of its peer's address and port, and the second is the address and port from which it is sending. If a node is multihomed and cannot determine which interface it will be using, it sends a NAT-D payload for each of its interfaces, in addition to the one for its peer's IP address and port. Figure 14.7. The NAT-D Payload
The hash is calculated as HASH(CKYi||CKYr||IP||port) where HASH is the negotiated hash. The payload type for the NAT-D payload is 20. When a node receives the NAT-D payloads, it checks that
If both of these tests succeed, the addresses have not changed in transit, so there is no NAT between the peers. If the first test fails, this peer is behind a NAT, so it must start sending NAT keep-alives, as discussed in the previous subsection.
We mentioned previously that IKE and ESP will use port 4500 when NAT-T is in use. The reason for this is that many NATs try to interoperate with IKE by not remapping port 500, even if there are multiple hosts behind the NAT, or by using some other method to demultiplex IKE traffic. By switching to port 4500, IPsec avoids this behavior and ensures that NAT-T can operate as intended. In Main mode, the initiator changes ports when it sends its Identification payload. Figure 14.8 shows a typical Main mode exchange when NAT-T is in use. The UDP header is included in the flow diagram in order to show which ports IKE is using. Figure 14.8. Main-Mode Exchange with NAT-T
Notice that in the second message, the responder replies to port X, the remapped port 500 from the initiator (see Exercise 14.7). After the initiator changes ports in the fifth message, the responder begins replying to port Y, the remapped port 4500. In Aggressive mode, the responder sends its NAT-D payloads in the second message, as shown in Figure 14.9. When the initiator receives this message, it will know whether a NAT is between the peers and, if so, will switch to port 4500. In the third message, the initiator sends its NAT-D payloads, so after receiving this message, the responder can determine whether a NAT is between the peers and also change to port 4500 if there is. Again, note how the responder replies to the remapped ports rather than to port 500 or 4500. Figure 14.9. Aggressive-Mode Exchange with NAT-T
Although not shown in Figure 14.8 or Figure 14.9, there is an additional change to the IKE packets when the peers change to port 4500. Because the encapsulated ESP packets will be carried in UDP datagrams using the same ports as IKE, IPsec must have a way of distinguishing between encapsulated ESP packets and NAT packets. IPsec does this by adding a non-ESP marker of four 0-bytes to IKE packets, as shown in Figure 14.10. Notice that the marker is in the same position as the SPI of an ESP packet. Figure 14.10. An IKE Packet with NAT-T
This means that ESP must never send an SPI of 0, but as we saw in Chapter 13, this is illegal anyway. After one of the exchanges shown in Figure 14.8 or Figure 14.9, IKE has negotiated the use of NAT-T for itself; all future IKE packets will use the new ports and will include the non-ESP marker. The use of NAT-T by ESP is negotiated in the Quick mode exchange by adding two new encapsulation modes to the SA payload: UDP-Encapsulated-Tunnel (3) and UDP-Encapsulated-Transport (4). These two modes replace the normal Tunnel and Transport modes when one or both of the peers is behind a NAT. Although it provides a port for PAT to remap, UDP encapsulation does not address the problem of TCP/UDP checksums. As mentioned earlier, these checksums include a pseudoheader and therefore depend on the source and destination addresses. NAT itself cannot correct these checksums, because they are encrypted and/or authenticated. Therefore, they must be adjusted after ESP has processed the packet. On the other hand, the receiver may not know the original addresses that were used to calculate the checksum. Therefore, the NAT-T peers must send each other these original addresses. The peers do this by exchanging their addresses in a NAT-OA packet, shown in Figure 14.11. Figure 14.11. The NAT-OA Payload
The NAT-OA payload has a payload type of 21. It is carried in the second and third message of the Quick exchange, as shown in Figure 14.12. Figure 14.12. The Quick Exchange with NAT-T
Unsolved ProblemsThere are interoperability problems between IPsec and NAT that NAT-T doesn't solve. A thorough discussion of these problems and the requirements to solve them are in RFC 3715 [Aboba and Dixon 2004]. We mention two examples from RFC 3948 that illustrate the types of problems that can occur. For the first example, imagine two mobile hosts in different locations connecting to their home network through a security gateway via a tunnel-mode VPN. Let's suppose that each of the mobile hosts is behind a NAT and that each has an assigned private address of 192.168.0.1, as shown in Figure 14.13. Figure 14.13. Two Mobile Hosts with the Same Private Address
When only one of the tunnels is activesay, from host ANAT-T handles everything just as we discussed earlier. The security gateway has an SA that says that traffic to 192.168.0.1 should be protected with ESP using UDP-Encapsulated-Tunnel mode encapsulation and that the traffic should be sent to 1.1.1.1. Now let's consider what happens if both tunnels are up at the same time. From the point of view of host C or D on the home network, both host A and host B are at 192.168.0.1, with the next hop being the security gateway. The security gateway has two SAs that specify UDP-Encapsulated-Tunnel mode ESP for 192.168.0.1, but they go to different endpoints, and the gateway has no way of determining which SA to use. The second example shows that transport mode can also be a problem. Suppose that host A and host B are behind the same NAT and that they both want to establish an ESP transport-mode connection to a remote server, host S, and send all their TCP traffic through it. Neither host A nor host B is aware of the other, and from their point of view, they each have a UDP-encapsulated-transport mode SA specifying that all TCP traffic to and from host S should be protected with ESP. Host S, however, has a problem. From its point of view, both host A and host B have the same addresstheir common NAT's external addressand both SAs say to protect all TCP traffic with ESP. The problem is, host S has no way of knowing which SA, and therefore which keys, to use, because both host A and host B look the same to it. In general, having the same traffic descriptor for multiple hosts behind the same NAT is not possible.  |
|
|
