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

Re: NAT Traversal



On 27 Feb 2002, Derek Atkins wrote:

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

Are you saying that doing layer 2 encryption will be impossible. If not
WEP some other protocol will do it given reasonable requirements. I would
be surprised if no one is working on it. There should be some requirements
for people to come up with WEP in the first place.

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

We don't yet have a certificate per person, it will probably be some time
before we can have a certifiate per device.

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

Exactly.

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

It's not about access control.

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

I am referring to the routing decision that the IP stack on the Server has
to make on the return traffic from the applications running on the server,
back to the client. Are you assuming that the Server is not multi homed,
and there is only one wireless network it is connected to. It could also
be connected to a high bandwidth optical ring within the house for
whatever reason.

We don't know what kind of address spaces these different networks will
use, and so we can't just inject a route to a private address that the
client got somewhere into the global routing table. You would have to
inject the route to the global IP address that the NAT gave for this to
work on a multi-homed server, and in some cases even on a single homed
server (what if the server and the home network is also a private
network, and the address you got in your guest network is already being
used by a node in your home network).

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

Yes, so while decapsulating, you use that address that the last NAT
finally gave us, we would jumble with the IP source address to do the SADB
check, and then put that address as the source address before shipping the
datagram to the applications. On the return traffic, you can't pick the
right SA. Please see my previous mail on why this is so.

    chinna

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

chinna narasimha reddy pellacuru
s/w engineer