[Swan] NetKey vs KLIPS

[Paul Wouters]

On Thu, 11 Sep 2014, Lawrence Manning wrote:

> On 11 Sep 2014, at 15:53, Paul Wouters <paul at nohats.ca> wrote:
>
>> - The first+last packet caching for on-demand tunneling that NETKEY is still lacking.
>
> Yes, this was an annoyance when I looked at this. Any idea if it can ever be fixed, or does it have that behaviour as a result of a  design decision?

Just a matter of writing kernel code. the kernel people told me they are
willing to accept a patch - they just have no interested or resources
for writing it themselves.

>> - OCF cryptographic hardware offload support for embedded devices
>>  (somewhat available via the OCF cryptosoft driver for netkey)
>
> Interesting. One would think this would be a problem for KLIPS not NETKEY, since NETKEY is “core” kernel code.

the kernel ran through 3 iterations of crypto API's for hardware. It
failed three times and by now no one cares because concentrators cannot
compete with just adding more CPUs to generic hardware. (unless embedded
but even there the CPUs are getting better than the hardware offload)

So the OCF drivers (available on openbsd,freebsd and linux) are still
the most stable to write hardware drivers for.

>> - No more easy tcpdump use of crypted and decrypted packets (might be
>>  doable with Linux VTI)
>
> This is certainly irritating. It’s not just tcpdump but also in theory programs like snort benefit from the separation which the ipsec interfaces provide. (Yes I’ve been known to fire up snort on ipsec tunnels..)

I think if we ask the kernel people, they might provide a hook. Or for
better changes, write a patch for it to submit.

>> - incompatible iptables rules requiring a rewrite.
>
> At first I really thought this was a big problem, but the same functionality you get from an interface match are available in other ways (and indeed the control is finer grained). So this is not a problem, just a sign of progress.

Agreed.

>>> In essence, I’m wondering if KLIPS will continue to be maintained “forever” or is it less pain now to just make the switch?
>>
>> We will support KLIPS for a while, but we are not actively developing
>> for it. So it is mostly in maintanance mode, bringing it up for newer
>> kernels, etc. Some people still prefer KLIPS due to its much easier
>> use of firewalling and the ipsecX interfaces.
>
> I think the summary, for us, is there is no compelling reason to switch to NETKEY, but we will “one day”. I’m very very pleased that libreswan gives us this level of choice. It’s really appreciated.

And as I said, if someone adds the cryptoapi glue for SHA2, AES_CTR and
AES_GCM, I think KLIPS can last for years to come.

Paul