From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 16:06:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4D8516A41F for ; Wed, 28 Dec 2005 16:06:47 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA9D43D78 for ; Wed, 28 Dec 2005 16:06:15 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 6C576AE; Wed, 28 Dec 2005 11:06:26 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 30AA02AD0; Wed, 28 Dec 2005 11:06:25 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErdoP-0001sX-Sp; Wed, 28 Dec 2005 16:06:02 +0000 Date: Wed, 28 Dec 2005 16:06:01 +0000 From: Brian Candler To: Phil Regnauld Message-ID: <20051228160601.GB7166@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <20051228150404.GA49024@moof.catpipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051228150404.GA49024@moof.catpipe.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: IPSEC documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 16:06:47 -0000 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.