Re: IPSec in 2.5 Kernel?

On Wed, 19 Mar 2003, Sandy Harris wrote:

>  > 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've received quite the emotional emails from Derek, Linus and Alan yes.
I haven't heard from John, but through Hugh I take it nothing much has
changed so far. AFAIK, the stalemate is still there. Not sure if people
are talking about this, I hope they are.

> 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.

I can argue with them, but it's not ours to argue :(
 
> 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.

Agreed. 

> 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	

Yes, but that means convincing those people that some features, such as
OE are not toy features, but essential freedom issues. I did have some
email exchange with Derek, so I hope that helped.

> 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.

Still, without maintaining that, a few years down the road it will be
practically unusable. I am not sure how to address this issue. Clearly
efford spend at kernelland is more or less wasted, esp. if the opensource
bandwagon takes off and more and more features are put in in the "tainted"
version. I sometimes feel there is no way to keep klips* as a "second
untainted" ipsec stack. But I guess we can always try. But most people
don't care so much about klips, as long as pluto doesn't lose features
talking to 2.5 ipsec.

> 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.

Perhaps it is time to give people the tools to cut themselves. There
will always be 1DES patches out there. Perhaps it is better to warn
loudly and support it, then to drive people away. 

> 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.

I agree here. It needs a careful rethink and reevaluation of current
policies and events. How ironic we'll be at war in two days with the
biggest EU<->US cold war phase starting to dawn upon us.

Btw. I still don't see how pluto will get into big distro's, eg RedHat.
Since they embarked on their own kernel ipsec, they should do the same
for userland. The best we can hope for is that all parties coordinate
those areas where thinks might break or conflict with each other, and
ensure both kernel and userlands combine nicely. So that if someone
decides to pick klips, he doesn't need to recompile the entire stock
RedHat kernel, or visa versa for SuSe.

> 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.

I think, and hope, that Derrick sees how important OE is, but I can
imagine he has other priorities (Like get IKE working in the first place)

> 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.

Everyone agrees here.
 
> 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.

Aye.

Paul 
-- 
> What would it take to get state-of-the-art IPsec into the mainline
> kernel development process?

A regime change in the USG...  :-0
               --- Richard Guy Briggs on [email protected]