Date: Thu, 30 Nov 2000 15:40:09 +0900 From: itojun@iijlab.net To: Dominick LaTrappe <seraf@2600.COM> Cc: freebsd-net@freebsd.org, Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, Gerhard Sittig <Gerhard.Sittig@gmx.net> Subject: Re: filtering ipsec traffic (fwd) Message-ID: <20718.975566409@coconut.itojun.org> In-Reply-To: seraf's message of Thu, 30 Nov 2000 01:17:56 EST. <Pine.NEB.4.21.0011292359200.29728-100000@phalse.2600.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>The order of packet processing cannot just be changed to fix this, because >NAT is part of filtering, and NAT has to happen before IPsec (other >reasons anyone?). Perhaps two passes of packet filtering (pre-IPsec and >post-IPsec) are appropriate as an option...? Or perhaps KAME transport >mode just has this inherent limitation...? Help! ;-) basically, the problem is not that simple. - relationship between packet filters and tunelling some people would like to filter before decapsulation, some would like to do it after decapsulation - relationship between filters and encryption/authentication ditto. some wants to filter before decryption, some wants to filter after decryption. - NAT and filters - NAT and IPsec they are fundamentally unfriendly, I believe. there are couple of ways to make it better: - enhance packet filters so that we can differentiate between multiple filtering points (make it possible to specify "this filter should be applied here"). - integrate all packet-filter-like mechanism into one. make ipsec processing invoked via packet filter. this still leaves question regarding to NAT and some other mechanisms. again, there's no clear solution. some change may make you happy while it makes others unhappy. itojun@kame To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20718.975566409>