Re: IPSec in 2.5 Kernel?

Paul Wouters wrote:

 > On Tue, 18 Mar 2003, John S. Denker wrote:
 >
 >>What would it take to get state-of-the-art IPsec into
 >>the mainline kernel development process?
 >
 > The only viable way I see, with the current positions of Gilmore,
 > Torvalds, Miller and Daniel,

Are you certain what the _current_ positons are in all cases, or
making assumptions? I know the history and see the problem, but
policies can change to take account of developments, and arguably
it may be time for some of that here.

Summary of the positions as I understand them:

The position of the FreeS/WAN project, set by management but
supported for obvious reasons by the whole team past and present,
has always been that it is critically important that FreeS/WAN be
protected from any interference by the US gov't. Development and
distribution must take place outside the US, with no patches from
US citizens and residents, so that it is utterly clear They cannot
block the work or distribution.

On the other hand, the position of key kernel developers has
always been that they could not accept anything into the main
kernel tree that they weren't allowed to change.

There are good reasons for both positions, but their combined
effect is problematic. The fault isn't with either group here,
but with the US gov't policies on crypto. This has kept IPsec
out of the standard kernel far too long.

There are also assorted problems with KLIPS as it stands, so
we've had much discussion of KLIPS-2 or KLIPS-ng design, and
there have some oddities like Gerhard's group wrting a lot of
their own code to integrate with the v6 stack.

Presumably the new kernel code is cleaner than current KLIPS.

As I see it, the FreeS/WAN project should now drop all effort
toward KLIPS-ng and instead aim at

	supporting Pluto over the mainline kernel IPsec in 2.6
	getting the good ideas of KLIPS or KLIPS-ng into that
	 mainline kernel code	

We probably also need to prepare an extra-solid fallback position,
a final release for 2.2 and 2.4 kernels that is entirely outside
US gov't control, so that if they decide to do something nasty
users can just revert there.

I believe the mainline stuff supports some undesirable "features"
such as single DES encryption. That's OK, as long as Pluto won't
negotiate them. By making Pluto available, we may keep users away
from other daemons that will.

I realise that what I'm suggesting represents a policy change for
FreeS/WAN and is not a decision to be taken lightly. I'm not
making the suggestion lightly; I think it is our best route to
getting IPsec, and in particular Opportunistic Eencryption, widely
deployed.

 > is to ensure that kernel level ipsec talks to both
 > KAME/Racoon and FreeS/WAN userland.

That's likely not enough.

Opportunistic Encryption has the potential to get large portions
of the net encrypted by default. It may be the only realistic way
to do that, and this has been a project goal all along.

OE can also make large VPNs much easier to manage. The number of
DNS entries you need to manage grows linearly as you add systems,
where the number of tunnel descriptions for a VPN can grow
quadratically.

These are extremely worthy goals, and they require some kernel
support.

Also, the desire to avoid Stoopid Rooting Tricks(TM) and make
IPsec play nicely with routing protocols, with DHCP address
assigment, with devices that go up and down, ... imposes
additional requirements on the kernel stuff; see Denker's paper
for details.
http://www.monmouth.com/~jsd/vpn/ipsec+routing/mast.htm

It is not enough to make Pluto run over 2.5 kernel IPsec.
The objective should be really good IPsec for the 2.6
kernel.

The FreeS/WAN team and various associates -- Denker, Steffen and
Trojanowski leap to mind, but there are others -- have done a lot
of design work on these problems. It should be applied to 2.6.