jfernandez@sgi.esNetwork Address Translation (commonly refered as simply NAT) is the method by which an IP address is translated into another IP addresss. NAT is defined in RFC 1631. The need of NAT arised by the wide deployment of IP networks in corporate environments, in the intention to solve two problems:
A NAT device will, transparently, translate IP addresses in a given addressing realm into addresses in another realm. The equipment in charge of this translation is called a NAT router.
There are different NAT methods defined:
Both Basic NAT and NATP are called Traditional NAT as described in RFC 1631, and are further described in RFC 3022. However, NAT is, as a matter of fact, a short-term solution of this problem whileas introducing some others. The main advantage is that this change can be put to effect without changing either the internal hosts or the external routers (this is not quite precise, as we will see below, due to the fact that NAT does not interoperate with some protocols).
The solution to this protocols that include IP information in the payload, is the use of application level gateways (ALGs) that cooperate with the NAT-device in order to modify this payload at the same time that the packets are being translated by it.
NAT breaks one of the fundamentals of IP, that is, end-to-end meaning of an IP address. In TCP/IP the IP address is always considered as an unique identifier of the host, with NAT, this is not the case. A given IP address can be shared, at the same time, by different hosts, and can dinamically change to serve as address for a host at one moment, and later on, to be the address of a completely different host.
While, in most cases, this loss of end-to-end connections with the inclusion of a NAT-capable device, will not have side effects, in some protocols some interoperability issues will arise. Mainly, this is due to the fact that some protocols consider information that is changed by the application of NAT, IP addresss and TCP/UDP port, as part of the protocol itself. This information might be used to establish or enforce security measures, for example, and NAT will break these applications due to the change it will make of each and every TCP/IP packet traversing it.
As the RFC 3027 and [NAT-EFF] describes, there are known problems with some protocols, mainly:
Also, there are problems in some special cases, like NAPT and use of IP fragmentation, which affects any and all protocols and applications. The example described in RFC 3027:
"two private hosts originated fragmented
TCP/UDP packets to the same destination host. And, they happened to
use the same fragmentation identifier. When the target host receives
the two unrelated datagrams, carrying same fragmentation id, and from
the same assigned host address, the target host is unable to
determine which of the two sessions the datagrams belong to.
Consequently, both sessions will be corrupted."
The fact that some protocols might not work correctly when a NAT device is placed in between in the communication channel, can be solved making use of elements referred as ALG (Application Level Gateway). An ALG is not exactly a proxy (although proxies are another solution as explained below), it is an element in charge of modifying the payload of packets crossing a NAT device in order to fix the interoperability issues outlined above.
An ALG is designed specifically for a given protocol. In the case, for example, of a FTP-ALG, it would inspect packets with the PORT and PASV commands sent by the FTP client to the server (which included port information) and cooperate with the NAT device in order to substitute this information with port information that can later on traverse the NAT device.
The applications which can be function properly when using an ALG are:
Another, application level solution is the introduction of proxies behind the NAT server which can benefit from 1:1 static mappings in the NAT device, an option not available for the multiple clients in the private network. However, this proxies do break end-to-end connection to the remote hosts, proxies act as servers for the clients and as clients for the remote hosts. Use of proxies might solve interoperability issues for some applications.
However, when encryption in protocols is used, the issues cannot be easily solved with either ALGs or proxies. Since encrypted packets might contain IP address and port information, no ALG can access the payload and decrypt them. Although the NAT device (or ALG) could be provided with the secret key to enable them to decrypt the data, the fact is that this would have some shortcomings:
The problems generated by the widespread of use of NAT without a previous knowledge of the interoperability issues that would arise later on have been slowly appeared in the deployment of networks incorporating new protocols and standards. Such is the case of IPsec, the security model developed for IPv6 which can also be deployed in IPv4 networks.
IPsec is currently the security standard for the IP layer, based on the use of cryptographic keys. IPsec can be used to encrypt the communication between a pair of hosts and ensure that data transmitted between them is both tamper-proof and spy-proof. The devices that incorporate IPsec functionalitiy are called security gateways. Security services at the IP layer can provide:
Since this services are provided at the IP layer, any other service on top of it can benefit from the security functionality added by the use of IPsec.
IPsec uses two protocols to provide security. One is AH (Authentication Header, RFC 2402) and the other is ESP (Encapsulating Security Payload, RFC 2406), they can be used separately or combined depending on the security needs for a given connection.
AH provides authentication for the IP header so that if it is tampered with, the changes will be noticed and the packet can be discarded. In order to provide AH-IPsec, the security gateway will add a new IP header, including an Integrity Check Value, which is obtained using criptographic technices (symetric algorithms like DES, or one-way hashes like MD5).
ESP provides encryption for the IP payload included in the packet, including the CRC sum of the packet itself. This way, ESP can provide both confidentiality in communications (since all the payload is encrypted), authentication (of source) and protection against tampering (if used in tunnel mode).
The last definition which is inherently part of IPsec is ISAKMP ( Internet Security Association and Key Management Protocol) and IKE (Internet Key Exchange) which are the processes by which two security gateways can start an exchange of IPsec packets and provide security end-to-end. IKE is probably the most complicated protocol of IPsec, in which it provides many features to act in different modes (depending on the needs and the kind of key that is being exchanged). Without going into much depth, IPsec used UDP port 500 for the key exchange and enables security gateways to negotiate which encryption algorithm, hash method and authentication method to use. Also, end-to-end authentication can be stablished beforehand (usually any identifier can be used, but some modes might use the source IP address for authentication)
After reviewing some of the main facts around IPsec it is easy to see that such a protocol is definetely an issue whe considering networking security aspects. Security, of course, might be enforced at other levels, such as the application level, using SSL or TLS. However, one can define attacks that will break this protocols if the underlying base (TCP/IP) is not really secure end-to-end.
IPsec, however, is not of widespread use nowadays, although it is slowly being included in operating systems TCP/IP stacks and network devices. Surely, the use of other VPN (or tunneling) protocols developed by vendors, as well as the difficulty in its implementation (due to the need of the deployment jointly with a Public Key Infrastructure).
But NAT might as well have taken an important role in the under-development of IPsec. As we have seen before, NAT does break the end-to-end idea on the Internet, succesfully hiding private IP spaces but succesfully breaking, at the same time, security models based on this end-to-end premise, like IPsec.
AH breaks when a NAT device is introduced between two security gateways that wish to establish secure communications using IPsec.
The main reason for this is that AH hashes the IP header so that any tamperings, even by NAT, can be detected. In this case, the packets will be silently discarded. So, unless there is a device (maybe the security gateway device) fixing the NAT translation back to the original one (a specific case of Double NAT), AH will not work across NAT devices.
Of course, if the NAT device is the same as the security gateway, NAT can be applied before the AH ICV calculation is done and IPsec will work. Also, if the NAT device has access to the secret encryption key, as well as the function used for calculation, it could decrypt the packet, recalculate the ICV and the encrypt it again. However, this cases might not be available in many scenarios. In the first case, when a mobile user is connecting to its corporation using a public ISP which makes NAT translation. In the second case, when the NAT device is across the security domain of the network, for example, if it belongs to the internet provider of a corporation.
When considering ESP, the problem with NAT is still an issue, even if the IP address is not included in the encrypted payload. The change of IP address implies a change in CRC checksum in TCP/UDP packets, and this checksum is included in the encrypted payload. A NAT device that does not have access to this payload will change the IP address but will not be able to update the CRC inside the payload. Thus, the packet will be discarded, not because of an IPsec error, but of an CRC error in the TCP/IP stack.
There is a specific problem, if using NATP. The reason for this is that IPsec ``sits´´ between the Network Layer (IP) and the Transport Layer (TCP), and it does encrypt TCP and UDP port information.
Thus, this information cannot be changed unless the NAT devices can decrypt the payload by itself, modify them and encrypt the packet. If the port information is not modified, the return packets to the NATted host cannot be sent back to it since the NAT device cannot, internally, take note of the port used for that host. The packet will be discarded, either when outgoing from the NAT device, when received on the other security gateway (if tampered with) or when incoming to the NAT device.
However, there is a single case when ESP will work, regardless of NAT, and this ESP tunnel mode. In this mode, since the original IP address and transport information is included as payload, adding new IP headers which are discarded by the security gateways, NAT devices will not change packets in a way that they will be discarded later on.
When considering IPsec one has to include also IKE/ISAKMP since the key negotiation is the first step taken towards the definition of the Security Associations, or, rather, of the IPsec protocol itself (either using AH or ESP).
IKE does have some problems when NAT devices transparently modify outgoing packets. The first issue is that some devices might depend on IKE negotiation being made by incoming packets sent from UDP port 500. If a NATP device is introduced, the final packet port will, most surely, not be the expected port, and IKE negotiation will not even began.
Another issue comes about when IKE includes IP addresses as part of the authentication process, which depends on which IKE mode is used. If the authentication is based on the IP address, the changes made by a NAT device will make sure that IKE will never come to an end.
Even when IP addresses are not used in IKE payloads, if the address mapping of the NAT does change from the time the IKE negotiation completed and the time IPsec is used, the IPsec protocol might not work after all. Since the Security Association, related to a given IP address, no longer stands.
Currently there are several drafts that provide some possible solutions for NAT and IPsec interoperability. These include VPN Masquerade Assist (VMA) and NAT-Traversal (NAT-T). The first one is a Lucent proposal based on Linux' FreeSwan implementation, the second one is a proposal by SSH Security Communications. Both have advantages and disadvantanges, as outlined in [draft-aboba-nat-ipsec-02].
However, NAT-T is currently considere as the only full IPsec implementation that works seamlessly with NAT. NAT-T is based on an IKE exchange which, in case of failure, is added with a small overhead that includes IP and port addresses as perceived by both ends, in order to determine if a NAT device is hindering the IKE negotiation. Also, IPsec SAs are encapsulated in UDP packets, in order to fully go through NAPT devices. This implementation is expected to work regardless of the NAT device in use, even though it does introduce some disadvantages: increasing time in IKE negotiation and loss of efficiency due to loss of UDP packets.
On the half-term, however, before IPv6 gets fully deployed a new (and broader) solution might need to be considered. The proposal that is considered to fix the known NAT problems introduced in this document is RSIP (Realm Specific IP), currently an IETF draft.
This proposal introduces a new protocol for address translation that introduces a new method of dealing with it. In this new protocol clients are aware of the address space in use after the RSIP device performs the translation, and of the IP and port assigned to them in that space. This awareness comes from the use of the RSIP protocol with which hosts are assigned the address that will be used when crossing their private address space.
If hosts are aware of this translation, and use the communication to the RSIP as a tunnel, payloads in packets that include information which will be, later on, modified, can be calculated in advance and sent to the RSIP host through the tunnel. For example, when using IPsec's AH mode, security gateways could consider hashing the real (external, after mapping) packet header instead of the private (internal, before mapping) packet header. That way, when the internal header is ripped off the packet, the real packet contains a valid AH header since it depends on the translated IP address.
RSIP does have its disavantages. Mainly, the introduction of RSIP means changes in the TCP/IP stack of operating systems to make them RSIP aware. Also NAT devices have to be subsituted for RSIP devices, or these need to be place alognsided NAT devices.
The use of NAT has been the savior as well as the doom-maker for IP network deployment. At the same time that it solved address space issues and enabled the deployment of private IP networks, favoring address reuse, it has introduce major issues, breaking some of Internet's protocols and applications.
IPsec might be considered one of the main protocols that NAT has broken, even if there are currently solutions in order to ``make´´ IPsec work when NAT devices are in place, the truth is, IPsec deployment is seriously hindered. Thus, the situation currently is that IPsec works in NAT devices (which are tipically firewalls), and major vendors in firewall technologies have included it in their products. However, IP security end-to-end from any host to any other host in the Internet is yet far from a reality.