Date: Thu, 30 Nov 2000 15:00:29 -0500 (EST) From: Dominick LaTrappe <seraf@2600.COM> To: itojun@iijlab.net 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: <Pine.NEB.4.21.0011301440230.8590-100000@phalse.2600.com> In-Reply-To: <26650.975598272@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Dec 2000 itojun@iijlab.net wrote: > from IPv6 point of view (yes, I'm IPv6 centric!) we cannot add extra > interface like tun0. IPv6 has scoped address, and if we add extra > interface in IP stack we will change the address semantics. I take this to mean that in KAME an IPv6 address's scope cannot span multiple interfaces, which is in itself a big limitation that will prevent a lot of code from being IPv6-enabled. Given that, I think a sysctl like net.inet.ipsec.filter would be a good solution -- to cause a pass over the filter rules to be called from inside KAME, when the packet is in its non-IPsec state. Address scope will be preserved because no additional interface is required. If the rules are written efficiently (with groups or skipto's to distinguish between IPsec and non-IPsec packets), the overhead will be little -- certainly no more than filtering built-into other IPsec implementations. Alternatively, this could be introduced as an SPD flag. So far, just one limitation comes to mind, which is that the packet filters cannot discriminate between a naturally non-IPsec packet, and a non-IPsec packet which 'was' or 'will be' an IPsec one. I don't think this is a big problem though. ||| Dominick 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?Pine.NEB.4.21.0011301440230.8590-100000>