Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Dec 2005 15:31:06 +0000
From:      Brian Candler <B.Candler@pobox.com>
To:        Matt Emmerton <matt@gsicomp.on.ca>
Cc:        freebsd-net@freebsd.org
Subject:   Re: IPSEC documentation
Message-ID:  <20051228153106.GA7041@uk.tiscali.com>
In-Reply-To: <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca>
References:  <20051228143817.GA6898@uk.tiscali.com> <001401c60bc0$a3c87e90$1200a8c0@gsicomp.on.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051228153106.GA7041>