From owner-freebsd-net@FreeBSD.ORG Wed Dec 28 15:31:12 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 1FD2516A41F for ; Wed, 28 Dec 2005 15:31:12 +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 2911443D5F for ; Wed, 28 Dec 2005 15:31:09 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 55DA9B5; Wed, 28 Dec 2005 10:31:31 -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 0D03F20B1; Wed, 28 Dec 2005 10:31:29 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErdGc-0001qB-KS; Wed, 28 Dec 2005 15:31:06 +0000 Date: Wed, 28 Dec 2005 15:31:06 +0000 From: Brian Candler To: Matt Emmerton Message-ID: <20051228153106.GA7041@uk.tiscali.com> References: <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca> 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 15:31:12 -0000 On Wed, Dec 28, 2005 at 10:08:54AM -0500, Matt Emmerton wrote: > While correct, note the scenario for which the configuration is describing: > > 14.10.3 The Scenario: Two networks, connected to the Internet, to behave as > one. > > This is something I do all the time to connect retail outlets to the server > at the head office. This double-encapsulation ensures that nobody can sniff > my packets, which contain sensitive information such as credit card data > (which is already encrypted via HTTPS, but you can't be too safe!) Well yes, but that's the whole point of IPSEC tunnel mode. The original IP datagram (header+payload) is wrapped in an ESP encrypted packet, a new IP header added (with the tunnel endpoint IPs as source and destination), and the packet is sent. If you sniff it, all you see is the tunnel header and the opaque ESP blob. You can see neither the original data nor the original source and destination IP addresses. There's no point doing GIF tunneling tunneling as well when IPSEC tunnel mode does that already. For someone new to IPSEC it confuses the issue; it adds extra processing overhead; and it reduces the number of bytes of usable payload data in each packet. I can also see a problem where someone implements the first part of this document (the GIF tunnel without IPSEC), finds that their two networks are communicating successfully, and says "great, I have a VPN, I don't need to do any more!" Or they could make a mistake with their IPSEC policy configuration, and believe that they have a secure encrypted VPN, when in fact all they have is GIF encapsulation. > > ISTM that this chapter should be rewritten to use IPSEC tunnel mode > solely. > > Do people here generally agree? If so I'll try to find the time to modify > > it. > > This perhaps would be a good _addition_ to the existing documentation -- > it's likely a configuration that many would want to set up, especially to > inter-operate with corporate networks (using commercial IPSec solutions) -- > or for those who don't need the double-encapsulation. My question is: who *does* need the double-encapsulation? I cannot see any benefit, and I can see good reasons not to do it. I would like to rewrite this document (or see it rewritten) to include: - Gateways with IPSEC tunnel mode and static keys - Gateways with IPSEC tunnel mode and racoon - Gateways with IPSEC tunnel mode, racoon and XAUTH/RADIUS (= Cisco road warrier) - IPSEC Transport mode with racoon - L2TP + IPSEC transport mode (= Windows road warrier) plus descriptions of how to get each of those to interoperate with some other common IPSEC implementations. Those are the most useful modes of IPSEC. Having others like GIF+IPSEC just complicates something which is already far too complicated, and shows a lack of understanding of the IPSEC security model anyway. If FreeBSD supports etherip encapsulation (RFC 3378), and it's possible to combine bridging with etherip and IPSEC transport mode, then that's another mode which would be useful to document (i.e. ethernet bridge over WAN) Also excellent would be "bump in the wire" bridging, where the gateway negotiates transport-mode security on behalf of clients without their being aware of it, but as far as I know only OpenBSD supports that. Regards, Brian.