[Openswan Users] ipsec look on 2.6

[Paul Wouters]

On Thu, 1 Dec 2005, Herbert Xu wrote:

> I'm afraid this is inaccurate.

I'm always glad to see improvements in either stack. I love to be corrected
on these things!

> It seems that KLIPS crashes a lot especially with new kernels.
> The in-kernel stack has also been around for three years now.

That is correct. Mostly, this is due to the lack of kernel documention on
these changes. todays crashes are afaik mostly related to two items. First
the SMP related crashes, which is probably due to a missing spin lock/unlock,
or changed behaviour in the spinlocking methods. Second, the sk_alloc changes
in the kernel. AFAIK we have the proper fix for its arguments changing using
the NET_26_SK_ALLOC define, but we are still seeing crashers with sk_alloc.
Possibly something more sublte changed that we are not aware of.

> > - ipsecX interfaces
>
> This is arguable as to whether it's an advantage since it introduces
> other problems such as how it interacts with policy routing.

>From the enduser point of view, this makes tremendous sense. And even for
developers, seeing plaintext packets with tcpdump, and crossing your fingers
that the packets will be encrypted after tcpdump can no longer see the
packets is to me just a very bad design.

> > - async/sync crypto offloading (eg hardware accelerators)
>
> That's certainly planned for the in-kernel stack.

Excellent.

> > - non-lineair SA search
>
> Huh?

AFAIK KLIPS uses radij trees where NETKEY has to search linearly through
kernel state? At least that was what I was told. Especially when doing OE,
a lot of pass policies are added to the kernel that this becomes important.

> > - most specific route first selection on SA's
>
> Works for the in-kernel stack too.

Is this used per default as well?

> > - path mtu support
>
> The in-kernel stack fully supports PMTU with IPsec.

Do you know when this was added?

> > - faster hand assembly coded ciphers
>
> The in-kernel stack has optimised assembly routines too.  It also supports
> the VIA Padlock.

Yes, both stacks seem on their way to fully use CryptoAPI.

> > - support for dynamic SA's and packet caching
> >  (needed for Opportunistic Encryption)
>
> Coming soon to the in-kernel stack, as soon as the netfilter work is
> finished.

That would truly be excellent news!

Paul