Chapter 2

XAUTH is often combined with Aggressive Mode, and the combination is vulnerable to a man-in- the-middle attack, because it uses a 'group password', and in general it is always a bad idea to share secret credentials with others. How secret is a secret that a whole group knows? It is expected that IKE version 2 will incorporate all the extra features of XAUTH without the problems that surround it.

Even though we do not recommend XAUTH, it is often the only way to get an IPsec connection into the big corporate networks.

X.509 Certificates

X.509 is a method of packing up cryptographic keys with an identity or other options and then digitally signing the bundle. Though people like to believe X.509 is the only way to use public key authentication, this is not the case. For example, DNSSEC-based raw RSA keys are another secure method for combining one's identity with a key.

The X.509 extensions to IKE move the IPsec authorization more to a Public Key Infrastructure (PKI) system. You have Certificate Agencies (CA) who can sign X.509 certificates for people or computers, which can then be used to permit or deny access to a VPN. X.509 certificates offer various options that can be set, tightly controlling their validity. X.509 is very popular in larger organizations.

Both IPsec hosts have the CA certificate and their own X.509 certificate, which includes their own private key belonging to the public key in the certificate. When they connect, they exchange their X.509 certificates, and verify the signature. If they have the proper CA certificate installed, they can each validate the other's identity. Then they can use each other's public RSA key from that certificate. The 'trusted third party' here, preventing the man-in-the-middle attack, is the CA, the certificate for which both ends already have installed.

The NAT Problem

Network Address Translation, NAT, is a classic example of a good hack gone bad. It proved to be so incredibly useful for so many people that NAT is not going to go away any time soon. The original reason for NAT was to hook up more networks and hosts behind fewer IP addresses, to hold off the end of the world when the IPv4 address space would run out.

Internal IP addresses of the network are translated on the fly by the NAT gateway. The NAT gateway swaps, or translates, the source address and source port of the packet for its own actual public address and another port that is free.

Usually NAT devices try to keep the same source port, but that is not always possible. Multiple clients in its local network could be using the same source port. It also remembers the destination address and keeps a list of these mappings ready. When a response comes in from a remote machine, which thinks that the NAT device itself sent the packet, the NAT device reverses the packet rewriting. It will look up the remote IP address, see which internal client belongs to this connection, and swap its own IP address in the packet it just received for the internal client's address (and port).

41

Practical Overview of the IPsec Protocol

We have looked at a similar network scenario to this already, the man-in-the-middle attack. Only at that time, we were talking about a malicious man in the middle, and not a friendly one. The problem is, of course, that IPsec peers cannot tell the difference.

One important feature (or limitation, depending on your point of view) is that a computer behind a NAT gateway can only initiate a connection to the outside world. The outside world cannot initiate a connection to a specific computer, since any connections from the outside to the original sender of the IP packet would just end up at the NAT device, since its IP address is the IP address that ended up as source address in the outgoing packet. When the NAT gateway receives a packet for a new connection, it will not be able to determine to which of the clients behind it should send the packet and it will be dropped.

The situation is further complicated by combining NAT with port-forwarding. For instance, one can put a web server behind a NAT device, and forward all HTTP packets that arrive on port 80 to the web server's internal IP on port 80. People have even used NAT to implement failover or load balancing solutions.

There are NATs that can only handle TCP and UDP. Most NAT routers can handle ICMP as well, but the IP protocol has 256 different protocols. Many consumer NAT routers do not support these other IP protocols, such as IPsec ESP or Multicast.

NATworks

People saw additional use for these NATed networks. They were much easier to deploy than the various SOCKS proxies. NAT, combined with transparent proxies, proved an excellent way to centrally control web browsing and caching within big companies. Additionally, machines with vulnerable software were no longer susceptible to being probed and taken over from the Internet, since the Internet couldn't reach those machines behind the NAT gateway.

However, NAT has been overused in recent years. Every company now claims their network is their own private network, and thus justifies using private IP space and a NAT gateway. Unfortunately, this is often an excuse to keep more control in their network, force a proxy or even a portal login site, and simply reduces the cost for deploying proper IP-space networks. Many public networks are now really just big private networks. The new GPRS and many WiFi networks especially suffer from this problem.

At the other end of the spectrum are the home users. Because many end-user ISPs give their customers only one IP address, NAT is used for home networks on a massive scale.

Passing Clients Through

As the big corporations switched from leased lines to VPNs, and broadband at home became commonplace, end users behind a NAT device became more of a problem. Usually the end-user machine has some fixed internal IP address, and at home, only one person would be using any VPN connection. So some NAT devices simply remember which internal client generated the first IPsec packet, and when IPsec answers come from the Internet, they simply translate these packets to that single IP address. On some devices, you would have to configure this single address manually. This option of the even friendlier man in the middle is called IPsec passthrough support.

42

Chapter 2

Unfortunately, it is both severely limiting in its requirement of a single client inside the NAT, and is also usually completely broken. IPsec and NAT just don't go together very well, since IPsec protects the packet integrity, and NAT mangles the packets and thus destroys integrity. A new standard was necessary, and many IETF drafts have been issued and implemented. The results of all these drafts are what we now call IPsec NAT-Traversal support, or NAT-T.T In January 2005 these drafts were finally released as RFC 3947 and RFC 3948.

NAT-Traversal

NAT-T is an addition on top of the IPsec protocol to detect a NAT device in between the two endpoints. It basically works by the clients telling each other what they believe their IP address is. The other end can then compare what the client thinks with what it sees. If it is different, the remote end is being NATed. It will then inform the other end of this unfortunate situation. Once both ends have found out and agreed that a NAT router would likely mangle or drop IPsec packets, the two sides will encapsulate each IPsec packet in a UDP packet. A NAT device can handle simple UDP packets, translating the outer IP address, without touching what is inside the packet, which in this case happens to be a full IPsec packet, which of course contains another complete packet in its payload.

At the other end, the IPsec peer will just discard the outer IP address, and take the payload and decapsulate it. The resulting IPsec packet, having survived any possible network mangling, can then be authenticated, verified, decrypted, and processed just like any normal IPsec packet.

NAT-T and IPsec Passthrough

Routers supporting IPsec passthrough sometimes recognize these IPsec in UDP packets and will try to attempt some passthrough-type operations on those packers. This almost always breaks NAT-T because at the very least, the SPI is changed by these routers, so they themselves can keep state of the connections.

That is why IPsec passthrough is no longer a feature you want to have on a NAT device. Unfortunately, especially vendors of NAT devices that do not support IPsec natively seem to like the sound of IPsec passthrough support, so they keep this feature in their products. But with all the major IPsec stacks now supporting full NAT-T, this feature breaks a lot more than it saves.

Always and without any exception, disable IPsec passthrough support. If you have not yet bought the device supporting IPsec passthrough, put it back on the shelf.

NAT-T Intricacies

When NAT is involved, IPsec needs to talk to an entity that is not the current IP address, since the current IP address is not that of the client, but of the NAT device. NAT-T uses the subnet-to-subnet method of connecting. So in the case of a roadwarrior for instance, where you would normally see a host-to-subnet connection from a public IP address, you now establish a subnet-to-subnet tunnel, where the roadwarrior's local subnet is its own internal IP address. This is how the packets can still reach the roadwarrior's internal IP address, while still being part of an IPsec connection with a different IP address as endpoint. And the encapsulation of this connection in UDP causes it to move through the NAT device without being mangled.

43