[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (NAT) Re: Interactions between IPSEC and NAT
If this is a 'hint', it makes NAT people to just give up with
IPsec since they have nothing to do after an IPsec transform is done.
If IPsec wg ignores the NAT one, that actually would affect the
customer base for both technologies.
IPsec works the way it does for very sound security reasons. The
changes that have been suggested simply won't happen. The challenge
is to figure out how to build an IPsec-friendly NAT *environment*.
One approach is, as noted, to bundle NAT and IPsec boxes together. At
least one vendor that I know of is already doing this. It's a perfectly
reasonable approach, since both functions often take place at the boundary.
A second approach is to use some form of encapsulation to accomplish
NAT-like functionality. That, too, works well, since IPsec supports
an encapsulation mode.
A third approach -- and it's one I don't like -- is to make the NAT box
trusted. In that case, IPsec sessions, inbound and outbound, terminate
at the NAT box. Heaven help us all if the NAT box is penetrated, of
course -- but much of the early IPsec deployment will be on trusted
encryption gateways anyway; the effective loss of trust will be rather
small. To do this requires playing games with the security gateway
discovery mechanism; since that isn't defined yet, there's room to work.
(I'm not even convinced the problem is well-understood yet, I should
add.) Broadly speaking -- and with many implied "secure XXX" qualifiers --
the process is similar to the use of MX records for mail delivery.
A box that speaks IPsec will ask some sort of server (which may or may
not be the DNS) for its peer's security gateway; it will receive back
an authenticated reply. If the reply says "talk to the NAT box" and
the IPsec speaker believes it, the setup will be transparent.
The trick, of course, is to make the reply believable. That probably
implies issuing fake certificates from the NAT box, so the IPsec box
will have to be told to accept it as a CA. But that's about the same
game NAT boxes will have to play with DNSsec.
(I should note that the reason I don't like this is that being a
security weenie, I prefer end-to-end security. I suspect, though,
that it's the most general solution, since I think that it will
fool most IPsec boxes that do peer gateway discovery.)
The fourth solution is to assume that there isn't a problem. For the
next couple of years, I strongly suspect that most IPsec deployment
will either be gateway-to-gateway and host-to-gateway, both in support
of different flavors of VPN. In either case, we will often see
the same -- possibly non-routable -- address space used on the inside
of the VPN. And "inside" includes the virtual interface used by
the host talking to the gateway. IPsec between arbitrary pairs of
hosts is still several years off, I think. (I don't claim that this
solves everyone's problems. And I can just hear Bob Moskowitz readying
his response about how his former employer really needs more complex
topologies with IPsec and NAT.)
Follow-Ups: