Re: ipsec vs. firewalls
Gabriel Montenegro <gab@Eng.Sun.Com> Sat, 09 May 1998 07:53 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA07604 for ipsec-outgoing; Sat, 9 May 1998 03:53:20 -0400 (EDT)
Date: Sat, 09 May 1998 00:58:54 -0700
From: Gabriel Montenegro <gab@Eng.Sun.Com>
Reply-To: Gabriel Montenegro <gab@Eng.Sun.Com>
Subject: Re: ipsec vs. firewalls
To: Joe Tardo <jtardo@freegate.com>
Cc: ipsec@tis.com, Steve Bellovin <smb@research.att.com>
In-Reply-To: "Your message with ID" <2.2.32.19980508164344.00cfbe8c@mailhost.hq.freegate.com>
Message-ID: <Roam.SIMC.2.0.6.894700734.2500.gab@eng.sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> At 08:12 PM 5/6/98 -0700, Steve Bellovin wrote: > > >I came up with a disturbing conflict between ubiquitous IPSEC and > >common firewall policies. I'm not certain how to resolve it, > >either. > > > >A common firewall policy permits most outgoing calls. (The > >requirement to authenticate such calls, say via AH from the inside > >host to the firewall, wouldn't affect what comes next.) Suppose, > >though, that the inside host wants to use ESP for end-to-end > >encryption to the destination. How will the firewall inspect the > >return packet? > > Why not just have included a 'return' SPI in the header? That's essentially what I propose in: ftp://ftp.ietf.org/internet-drafts/draft-montenegro-aatn-nar-00.txt The idea is that your inside host engages in an authentication and negotiation phase with the gateway/firewall/nat (whatever you want to call it), after which the latter will know that a given SPI on inbound packets is bound to the inside host. This allows it to (a) accept the packet, and (b) deliver it to the appropriate inside host. The authentication and negotiation phase between the inside host and the firewall is socks-based, so traditional socks-based authentication mechanisms can be reused. The firewall can impose its policy at the negotiation phase, or alternatively before (a), above. -gabriel
- ipsec vs. firewalls Steve Bellovin
- Re: ipsec vs. firewalls Phil Karn
- Re: ipsec vs. firewalls Damien Wetzel
- Re: ipsec vs. firewalls Bill Manning
- Re: ipsec vs. firewalls Steve Bellovin
- Re: ipsec vs. firewalls Steve Bellovin
- RE: ipsec vs. firewalls Davis, Terry L
- RE: ipsec vs. firewalls Davis, Terry L
- Re: ipsec vs. firewalls Phil Karn
- Re: ipsec vs. firewalls Robert Moskowitz
- Re: ipsec vs. firewalls Vach Kompella
- Re: ipsec vs. firewalls Phil Karn
- Re: ipsec vs. firewalls M.C.Nelson
- Re: ipsec vs. firewalls Marcus Leech
- Re: ipsec vs. firewalls Robert Moskowitz
- Re: ipsec vs. firewalls Joe Tardo
- Re: ipsec vs. firewalls Dan Stromberg
- Re: ipsec vs. firewalls Raul Miller
- Re: ipsec vs. firewalls Gabriel Montenegro
- Re: ipsec vs. firewalls Jean Chouanard
- Re: ipsec vs. firewalls Bill Sommerfeld
- Re: ipsec vs. firewalls Perry E. Metzger
- Re: ipsec vs. firewalls Jean Chouanard
- Re: ipsec vs. firewalls Henry Spencer
- Re: ipsec vs. firewalls Dan Stromberg
- Re: ipsec vs. firewalls Perry E. Metzger
- Re: ipsec vs. firewalls Robert Moskowitz