Re: NAT Traversal

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On 27 Feb 2002, Derek Atkins wrote:

> "Chinna N.R. Pellacuru" <pcn@cisco.com> writes:
>
> > Could you elaborate this scenario more. What/who are you doing transport
> > mode with and what kind of applications are generating this traffic?
>
> Ok, here's an example:
>
> Assumption: My home LAN is insecure!  It's sitting on a wireless
> network, I don't know who may be listening in on it.

you could also choose to run a layer 2 security protocol to secure your
home wireless network. Otherwise you need to run IPsec between all the
nodes on your home network when one talks to another. That would be a bit
hard to manage: a certificate for each of your machines at home, possibly
including home appliances which are on the network.

>
> Now, based on that assumption, here's my scenario: I've got a laptop
> that I use as my primary environment, but I use a bunch of network
> services off my home network.  Keep in mind that my home network is
> insecure -- I do not trust it!  Therefore, I want to setup IPsec
> between my laptop and each of my home servers.
>

Or possibly one might have an array of laptops and palmtops to access
different services from different servers or even simultaneously from the
same server on the home network.

> So, I setup IPsec transport between my laptop and my file server to
> protect my file system traffic.  I setup IPsec with my mail server so
> I can securely send and receive email.  Expand until you have a full
> mesh of transport-mode IPsec connections!
>

OK. Even multiply that by a factor of N, N being the number of access
devices one is using.

> When I travel, I want to continue doing this.  I don't want to change
> my behavior just because I happen to be sitting behind a NAT (and no,
> Phill, I wasn't talking about IETF -- I was actually referring to
> Usenix Security).  This way I can work the same (modulo network
> latencies) regrdless of my current physical location.

You could choose to do IPsec tunnel mode with private addresses from your
home network on the inside, but if you don't want to make any concessions
at all, you would want to do transport mode only, just like if NAT did not
exist.

But with the current set of UDP encapsulation drafts, it would add more
than 20 bytes for the UDP encapsulation anyway. And, it does NOT work for
this scenario. In another mail it was mentioned that it is NOT mandatory
that any NAT IPsec solution has to solve this scenario.

>
> > 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.
>
> Of course that's how you see it, but that's not the only way that
> IPsec can be run.  The original goal of IPsec (assuming you were
> around for those discussions in '92-93) were to enable end-to-end
> IPsec.  If I tunneled back to my home LAN it would still violate
> assumption #1, that my home LAN is insecure.
>
> I want end-to-end security; tunneling to a security gateway does not
> provide that.
>

I've been following IPsec only since '96. I've been a software developer
and an implementor of IPsec ever since. I wasnt' around in the discussions
of '92-93.

End-to-end security is fine, but what authentication infrastructure was
envisoned? I hope it wasn't global pre-shared keys. Global pre-shared keys
are a rather radical idea that gained popularity in more recent times,
probably from frustration over PKI. The idea is that the pre-shared key is
"global", IE. a large section or even all users of a particualr
authentication infrastructure will use the same pre-shared key.


> > 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?
>
> It doesn't matter.

It matters.

>
> The Security Association has a binding to:
>         Certificate, RSA, id=Derek Atkins <derek@ihtfp.com>
> or perhaps
>         Certificate, RSA, id=derek-laptop.ihtfp.com
>
> The point being that IPsec knows who I am regardless of the IP
> address.  The IP address can be anything, and that's ok.
>
> Applications that want to depend on IPsec for security should not key
> off the IP Address; they should key off the SA.  The SA knows all.

I agree, this is the IKE Security association, and we don't need to have
IP addresses as the IKE identities.

I am referring to the end points of the actual data, the application data.
If you look at the section that was snipped from this mail, the IP
addresses being used and expected are important to do routing. Unless you
can route it properly, the data won't even reach IPsec.

    chinna