[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT Traversal



To build on this scenario, assume that the laptop (behind
the nat) wants to communicate with an IPSec peer behind a
corporate gateway through which all traffic must be IPSec
protected.

 ------------ Transport mode IPSec ------------
 |                                            |
 |  --------- Tunnel mode IPSec ----
 |  |                              |          |
laptop+-----+NAT+---( cloud )----+GW+---+IPsec peer

Wouldn't there be a requirement that the tunnel mode
IPSec SAs be setup prior to negotiating the transport
mode IPSec SAs? The reason being that the GW would be
performing NAT for those cases where the laptop is using
private addresses thus changing the addresses the
IPSec peer would see.

----- Original Message -----
From: "Chinna N.R. Pellacuru" <pcn@cisco.com>
To: "Derek Atkins" <derek@ihtfp.com>
Cc: "Markus Stenberg" <mstenber@ssh.com>; <ipsec@lists.tislabs.com>
Sent: Tuesday, February 26, 2002 9:20 PM
Subject: Re: NAT Traversal


| On 26 Feb 2002, Derek Atkins wrote:
|
| > "Chinna N.R. Pellacuru" <pcn@cisco.com> writes:
| >
| > > In what "other" cases are you saying we need to do IPsec transport
mode
| > > through NAT? Someone gets a private address, and does plain IPsec
| > > transport mode through NAT! to whom? and why?
| >
| > Here's an example: A person at a conference who's laptop is setup to
| > perform RSA-based transport-mode opportunistic encryption, but where
| > the conference is sitting on a NAT?  I've been to conferences where
| > they conference LAN is sitting behind a NAT, but I would still like to
| > be able to use my laptop and the services it has the same way I would
| > if I were NOT sitting behind a NAT.  To my laptop, it shouldn't
| > matter.
| >
| > Keep in mind that the user who wants to run IPsec and the manager who
| > runs the network with a NAT may NOT be the same person!
| >
|
| Could you elaborate this scenario more. What/who are you doing transport
| mode with and what kind of applications are generating this traffic?
|
| In general we see people running tunnel mode in this case to a border
| security gateway or a remote access aggregator, and access the machines
| within the network which is behind the aggregator. Or people could run
| L2TP or GRE to a border router (if they want multicast), and run IPsec
| transport mode on those tunnels.
|
| Consider a sample network at a conference which gives out private
| addresses and runs NAT at its border
|
|    laptop+-----------+NAT+-----( cloud )-------+IPsec peer
|
| laptop got an address 10.0.0.5
| NAT box is going to translate it to say 5.0.0.1
| IPsec peer is 6.0.0.1
|
| Now, IPsec proxy identities are 10.0.0.5 and 6.0.0.1.
|
| Question1: So, do the applications on the IPsec peer think that they are
| talking to 10.0.0.5 or do they think they are talking to 5.0.0.1?
|
| You can't have the applications on IPsec peer to expect the traffic to be
| coming from a private address space(10.0.0.5 in our case), of which he has
| no knowledge about, and only the network administrator of the conference
| has control over. IPsec peer cannot route traffic based on the private
| addresses becuase it has no prior knowledge or control of the private
| address space, and there could be overlapping private address spaces.  We
| do IPsec after routing. If we can't route properly, we won't even get to
| IPsec. So, let's say the address that is expected is address that NAT
| gives it, which is 5.0.0.1.
|
| Because the IPsec proxy identities are 10.0.0.5 and 6.0.0.1, the NAT
| decapsulation process will need to change the source address from 5.0.0.1
| to 10.0.0.5 before checking the packet against the SADB. This check is for
| seeing whether the packet matches the proxy identities negotiated for this
| SA. After that we need to use the appropriate source IP address based on
| the answer to Question1. If the applications are expecting 5.0.0.1, then
| before we ship the datagram to the applications we need to change the
| source IP address on the datagram back to 5.0.0.1 after the SADB check.
|
| Say the NAT box uses a source port of 9999 in the UDP encapsulation header
| for your laptop. For another laptop it uses 8888. Now if both the laptops
| are talking to the IPsec peer, the return traffic will all be traffic to
| 5.0.0.1, because applications only know about 5.0.0.1. How will the IPsec
| layer decide which SA to use (hence which UDP port to use in the UDP
| encapsulation header)? If we don't use the right UDP port, the NAT box
| cannot demultiplex properly between the laptops.
|
| Now if you want to make IPsec even more NAT aware, we need to keep track
| of the source and destination ports of the data traffic in the IPsec layer
| (in addition to ports in the UDP encapsulation header). Now if the first
| laptop was doing TCP from port 5000 to 23, and the second laptop is doing
| TCP from port 6000 to 23, then we can store this information in the
| IPsec-NAT translation table and use that information to pick up the right
| IPsec SA. This would NOT work if both laptops pick up the same source TCP
| port though. This also would NOT work for protocols that don't have ports.
| Now if it is some other protocol, then the IPsec layer should understand
| that protocol and some how keep enough information to pick the right SAs.
| This is just a slippery slope.
|
| -So, people have to do a "built-in host NAT implementation within the
| IPsec stack". I just can't imagine how pretty that would be.
|
| -Curious why this is not being acknowledged in the latest drafts.
|
| -In order to go through NAT, we will implement the whole of NAT in IPsec!
| Now we don't have to worry about how many NATs are there enroute, but we
| got this done by having a NAT implementation in each IPsec implementation!
|
| -Now everytime a new application layer protocol comes along which NAT has
| to deal with, we go and change our NAT implementation and also our own NAT
| implementation within our IPsec implementation too!
|
| -So, all NAT boxes have to be upgraded for dealing with non-IPsec traffic
| of this new protocol and all IPsec implementations will need to be
| upgraded if that new protocol needs to be IPsec protected!
|
| -Doesn't it look like bending over backwards to accommidate some scenario
| we are not sure how/who, if at all, will use it?
|
| -Even after doing all this, it may not work in some cases.
|
| I think it is not prudent to judge solutions based on such corner cases.
| Even if we consider the above technique as a way to solve this corner
| case, it is not easy to implement, and it forces all IPsec implementations
| to do a full NAT implementation, and even if we do it, it still may not
| work in even more corner cases.
|
|     chinna
|
|