Date: Wed, 28 Dec 2005 16:06:01 +0000 From: Brian Candler <B.Candler@pobox.com> To: Phil Regnauld <regnauld@catpipe.net> Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation Message-ID: <20051228160601.GB7166@uk.tiscali.com> In-Reply-To: <20051228150404.GA49024@moof.catpipe.net> References: <20051228143817.GA6898@uk.tiscali.com> <20051228150404.GA49024@moof.catpipe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 28, 2005 at 04:04:04PM +0100, Phil Regnauld wrote: > > This is a really strange approach which is almost guaranteed not to > > interoperate with other IPSEC gateways. > > It's probably for FreeBSD <-> FreeBSD setups, where it might make sense > to have an interface endpoint, rather than the "transparent" IPsec > approach -- otherwise it's not possible to route via the remote > endpoint, or apply filters at interface level before leaving the > gateway. If it's done that way purely as a workaround for limitations of the FreeBSD IPSEC architecture then that's OK, but I think it should be explicitly documented as such. Otherwise the rationale is unclear. (Presumably by "transparent" IPSEC you mean that the kernel takes care of IPSEC policy independently of ipfw/pf filtering; you're not talking about a transparent IPSEC gateway such as http://www.thought.net/jason/bridgepaper/node12.html ) It's a shame that this workaround means that you actually have to change the data format on the wire, as this will reduce interoperability. ISTM what you really want is to be able to have IPSEC tunnels each appear as separate interfaces, e.g. ipsec0 or tun0, so that firewall policy can be associated with each one. The old userland IPSEC implementations had this benefit, of course. Are any of these still maintained and usable? If so then perhaps they should also be documented as an alternative. Actually, I did come across a paper which discussed extending the socket API so that application decisions could be made on the basis of the IPSEC attributes by which the data was delivered; ah yes, here it is. http://seclab.cs.ucdavis.edu/papers/314-PHIL.pdf Integrating something like that with ipfw/pf would also give the flexibility to associate packets with their IPSEC flows. But I digress. Regards, Brian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051228160601.GB7166>