Re: NAT Traversal

[Derek Atkins <derek@ihtfp.com>]

"Chinna N.R. Pellacuru" <pcn@cisco.com> writes:

> > 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

Except there are none that work.  WEP certainly doesn't fit this
bill.  What do you propose?

Also, that presupposes that I _WANT_ a closed network.  What if I'm
a member of an open neighborhood network, ala NYCWireless?

> 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.

Why is a certificate-per-machine hard to manage?

> 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.

IIRC, back in the old days the authentication infrastructure
envisioned was the (non-existant) PKI..  The "there will be this
global PKI that will solve all our problems" answer, which we know
today doesn't quite exist.

> > > 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.

No, honestly, it does not.  The application should not be making
access-control decisions based on the IP address.  It should be making
access-control decisions based on the cryptographic authentication of
the SA.

Obviously the packet needs to be routed, which implies that it would
see an IP address of the (last) NAT box in the network.  For example
I've run in this situation:

            A       B           C       D
 VMWare Guest -<nat>- VMWare Host -<nat>- [Internet] - Server

In this architecture I'd like a secure end-to-end connection between
the VMWare Guest (client) and the Server, but there are TWO nat's
involved.  Obviously for routing purposes the server needs to send
packets back to address D in order to physically get them to the
client.

Obviously in transport ESP you wouldn't be able to protect the IP
address, but that's ok.  It's not the IP address itself that's
important.  It's the fact that the address does not change over time
that's important.  You want linkability, and that is sufficient.

> > 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.

Right.  In my mind it would use whatever address it would see if you
used regular NAT without IPsec.  My point is: the fact that I don't
know the IP address that you see shouldn't affect my ability to use
IPsec with you.

>     chinna

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com