[e2e] IPV6 FIREWALLS

[RJ Atkinson]

On Tuesday, Jul 1, 2003, at 00:40 America/Montreal, David P. Reed wrote:
> One could have hoped that in creating the IPv6 stacks of end systems,
> vendor OS stacks and apps would be properly authenticated using IPSEC,
> thus eliminating the need for (and ability to implement) firewalls that
> must read payload content as if they knew what it meant.

Certainly my intent when designing ESP/AH about 10 years ago was to 
foster
deployment of end-to-end security, not VPNs.  However, the manufacturers
of routers, firewalls, and other middle boxes have been more aggressive
in marketing ESP/AH than typical host vendors have been, so most 
deployment
of ESP/AH today is in a VPN context.  (A side-effect, since about 1996, 
has
been that the IETF's IPsec WG has been dominated by VPN middlebox 
implementers
-- with host implementers being somewhat drowned out in that WG.)

It is a sad outcome.

> But alas, and to my great sadness, that was not to be.   [...]   I 
> presume that
> these firewalls will demand that IPSEC traffic expose its content 
> before being
> allowed passage so instead of being more secure, the traffic gets less 
> secure.

Actually, this is merely the continuation of an existing widespread 
practice.
It is very very common today for a business/organisation to deploy their
internal network roughly like this:
	- private IPv4 addressing inside the organisation (NOT because public
		address space was unavailable, but as a deliberate choice
		to make it more difficult for outside parties to be able to
		reach inside the organisation's network)
	- combination middlebox at the administrative boundary, providing
		- packet-inspection firewall functions,
		- ESP/AH VPN functions (on the external interface, typically
			to connect other sites of the same organisation
			via encrypted tunnel over the public global Internet) [1],
		- NAT/PT for applications that are either allowed to reach from
			outside inwards (by policy) or are initially established
			from the inside,
		- and audit/accounting/logging capabilities

End users actually LIKE this kind of setup.  One imagines that they LIKE
it in part because of successful marketing to sell them this kind of 
setup,
but nonetheless we are where we are.

Sigh.

Ran
rja at extremenetworks.com

[1] In many cases, this uses manual static keys, not any kind of dynamic
	key management.