Re: NAT Traversal

[Tero Kivinen <kivinen@ssh.fi>]

pcn@cisco.com ("Chinna N.R. Pellacuru") writes:
> - UDP encapsulation schemes require the use of keepalives to keep the
> translation alive. That would not be easy to do, particularly if you are
> assuming that no one knows what kind of NAT boxes are out there.

And, again I will once more repeat, only you are sending keeplives
only if there is no other traffic going out, and only from the host
that is behind NAT box (i.e the "server" end with fixed ip-address
will not ever send them), and also the interval can be configured. 

> While it is true, not everyone is a "road-warrior". There is a vast
> majority of IPsec users who have a home and an office, and can know
> and influence what kind of NAT devices are butchering their IPsec
> traffic.

If they can control the NAT boxes, then fine, they can modify the
NAT-T translation lifetime up to 1 hour, and set the keepalive
interval of the IPsec to 30 minutes. No need to complain about
keepalives consuming bandwidth. 

> - As people have pointed out, even our solution has a lot of restrictions
> on which scenarios are supported. But, those restrictions also apply to
> the UDP encapsulation schemes. There are some schemes that claim to
> support more scenarios, but when we looked at them, they were paying a
> price that we were not willing to pay in terms of implementing a "built-in
> NAT".

Lets put it this way, if you ever want to get active mode FTP through
the NAT that is forwarding IPsec packets, someone who has the clear
text traffic must do the translation of the application data.

Lets take example. We have IPsec road warrior with laptop. He is
in an hotel that provides internet through NAT box. His corporate
headquarters have IPsec SGW which he can connect to make connection to
the corporate network. The corporate network has internal ftp-site
which can be used to get latest evaluation software.

Option 1)

The client will take IPsec connection to the IPsec SGW. Now the IPsec
SGW MUST do some kind of NAT for the IP address of the client coming
from the tunnel as he must forward the packet to the internal network
and he must ensure that the packets are routed back to him.

The client takes connection to the ftp server, he encapsulates the
packet to the UDP and sends it out, the hotel NAT will change the
outer IP address of the packet. The IPsec SGW will decapsulate the
UDP, check the MAC, decrypt the data, notice that the original
internal IP header has address that cannot be routed inside the
internal network, it modifies it to something that can be routed back
to SGW (i.e NAT on the internal header after it is decrypted) and
sends it to the network. The ftp server receives the packet send reply
back. It ends to the SGW, which will use the existing NAT translation
it created in the beginning and after that it will encrypt, mac,
encapsulate in UPD and send it to internet. Hotel NAT will again do
another NAT transformation for the outer IP header, and then the
client will do the decapsulation, decryption, etc.

Now when the client needs the IP address for the FTP port command it
uses the ip-number from the hotel network, and when the packet will
reach the IPsec SGW it must do the application NAT for the FTP port
command and change that IP address to something it starts listening
and which it can then NAT back to the UDP+IPsec tunnel.

Option 2)

The client connects to the IPsec SGW and then it will request the
IPsec SGW for an internal IP address which it can use in the internal
network (dhcp-over-ipsec or similar). Then it will create the IPsec SA
using that IP number, which now is routable in the corporate network,
meaning that the IPsec SGW does not have to do any NAT for the packets
when they are going through it. Again now client can use that IP
address it received from the IPsec SGW and use that for the FTP port
command, and everything will work fine.

The option 2 is much simplier and thats why in most cases you don't
need NAT inside the IPsec SGW. If the client always requires internal
ip address from the IPsec SGW then we never need it.

The simple NAT inside SGW might be needed in case we have a case where
the IPsec SGW is actually the IPsec enabled www-server and we use
UDP encapsulated transport mode (less overhead) to connect it. In this
case the client normally will not request internal ip address from
SGW, because it does not need it for normal operations. What we might
now need is to have simple address NAT inside the server host in case
it has two clients in hotel1 and hotel2 which both decide to give out
ip-numbers starting from the 10.0.0.1 and both those clients managed
to receive the 10.0.0.1 ip number.

When the IPsec processes the packets it knows that this packet came
from the tunnel1, and the real ip number of the other end is 10.0.0.1.
It can let that packet through (provided that when the www-server
replies to the 10.0.0.1 the packet will end up back to the IPsec and
it can map that packet back to the tunnel1).

When the packet comes from the tunnel2, the IPsec must also NAT it to
some other address. To which address, it actually doesn't matter, as
the packet never leaves the host, 127.0.1.2 would be as fine as
192.168.1.1, the ip address simply must be such that the operating
system will know that this is meant to be tunneled through IPsec and
it must be unique between all tunnels. Lets say the internal
implementation decided to select first free 10.42.0.0 network address,
i.e it selected 10.42.0.1. When the www-server replies the IPsec will
see that 10.42.0.1 ip number (which was BTW allocated when the second
IPsec SA with overlapping address was created) and it will know that
this packet should be forwarded to tunnel2.

As the option 2 is so much simplier, and more things work through it I
think we should be using it always unless we are talking about the
transport mode between client and the server.

Using option 2 also in that case (i.e get the ip-address from the
IPsec server) even when using transport mode removes the need for
application level NAT for the FTP port command for that case also.

Of course this means that if the corporate network and the hotel
network are using the same ip address space, then only one of them can
be used at time (i.e most likely all packets are being forwarded to
the IPsec tunnel), but on the other hand that is that most of the SGW
adminstrators would want to do anyways (i.e disable access to the
other hosts when the VPN tunnel is up, so nobody can use the laptop to
attack the corporate network). 

> That's a whole NAT implementation within IPsec. That is exporting
> the NAT functionality to another device that is actually an IPsec device.
> It is not easy to manage multiple NAT devices, and it would be almost
> impossible to manage multiple NAT devices, and multiple NAT
> implementations within each IPsec implementation.

Those NATs can be avoided if the hosts connecting to the server are
using addresses offered by the server. There is already protocol for
that. Also quite often the IPsec SGW contains some kind of firewall
capabilities also, and that includes NAT...

> >    Solution 2:
> >      By standardizing different UDP port for encapsulating ESP/AH traffic,
> >      it works through all existing NATs (supporting ESP ALG or not).
> >      One disadvantage is that it requires changes to IKE/IPSEC
> >      implementations.
> >
> >      By having different UDP port, the overhead also comes down by
> >      8 bytes. But, one more keepalive timer is required to make
> >      the NAT session alive.

Actually if we move the IKE SA traffic at the same time to the new
port also then we only need to keep that mapping up.

This would happen that in the middle of the main mode or after the
main mode, when the initiator knows it is behind NAT it moves all
traffic to new port and let the port 500 mapping to die. All traffic
then happens with this new port. To get the overhead down we can
defined the new port usage so that IKE payloads are identified with 4
bytes of 0 in beginning (i.e the ESP spi field), and the IKE packet
starts after that.

This makes things little more complicated and the responder needs to
update the IKE SA ip and port numbers when it sees the same IKE SA
cookies it did see previously but from different ip address and port.

I think Dixon has some kind of draft about this, but I don't know the
current status of it (I think it waits for me to incorporate it to
draft-ietf-ipsec-nat-t-ike-01.txt :-)

The reason we don't want directly to start from different port is that
that would require either long initial timeout in case the other end
does not support new NAT-T (i.e we send packets to port xxxx, but the
other end will ignore them and then we fall back to port 500), or we
consume more resources by starting two negotiations at the same time
one in port 500 and one in port xxxx, and the NAT-T aware
implementation would propably answer to both...
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/