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

Re: IPSEC and NAT

To: hsw@columbia.sparta.com (Howard Weiss)
Subject: Re: IPSEC and NAT
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Date: Fri, 22 Aug 1997 17:13:25 -0400
Cc: smb@research.att.com (Steven Bellovin), dave@tlogic.com, ipsec@tis.com
In-Reply-To: hsw's message of Tue, 19 Aug 1997 09:21:11 -0400. <9708191321.AA03146@katahdin.columbia.sparta.com>
Sender: owner-ipsec@ex.tis.com

> > The point is simple:  IPSEC guards against tampering with the packet,
> > and NAT boxes by definition tinker with at least the addresses.
> > 
> 
> Couldn't one tunnel through a NAT?

I am not anywhere near as optimistic as Bob about whether we can make
IPSEC and NAT play nice with each other.


It's not immediately clear what this means, because NAT is a way to
bridge between multiple routing/addressing domains.  By tunnelling
through, you're (pardon the Ghostbusters analogy) "crossing the
streams".  are the addresses on the "inside" of the tunnel from one
domain, or the other?  or do they form a third addressing domain?

Are you going to force NAT functionality into the systems on each end
of the tunnel (and one end may well be the "road warrior") so that
they can deal with address collisions between the local "real" network
and the tunnel?  How do you distinguish between addressing domains at
the socket/API layer on an end system?  How do you make this
manageable?

It seems like an awful lot of work to do to accomodate a technology
which completely breaks just about every single system/protocol I've
worked on in the past 10 years.

					- Bill

Follow-Ups:

Re: IPSEC and NAT

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>

References:

Re: IPSEC and NAT

From: hsw@columbia.sparta.com (Howard Weiss)

Prev by Date: Re: ESP/AH draft comments
Next by Date: Draft IPSec working group minutes
Prev by thread: Re: IPSEC and NAT
Next by thread: Re: IPSEC and NAT
Index(es):
- Main
- Thread