An Illustrated Guide to IPSec

Posted Aug 27, 2005 6:07 UTC (Sat) by jd (subscriber, #26381) [Link]

In the end, the ISAKMP/Oakley crowd won the favour of the IETF, who declared it to be the IPSec standard. Sun kept pushing SK/IP for a while but have now dropped it entirely. Which goes to show how perilous any single-vendor standard is, however big the vendor. A Linux version of SK/IP - EnSKIP - exists but has received no new work for years.

It is interesting to note that ISAKMP/Oakley was favoured by the US military - the DoD released a prototype and the Naval Research Laboratory regularly churned out *BSD patches for some time. A number of Universities also produced prototypes, but the NRL version was by far the best maintained, the most up-to-date and the most complete. I do not know if any current IPSec implementation actually uses any of their code or not, though.

NIST also produced an IPSec implementation - this time for Linux - called Cerberos. They abandoned it, shortly after the restrictions on exporting encryption systems was lifted, although it was so poorly maintained that it was impossible to use for anything other than as a demonstration of the principle anyway.

The idea of IPSec is a good one, current implementations are improving, interoperability is improving and fewer projects are becoming abandonware, but it will not make any serious headway at this point unless sites make use of it. (eg: Websites could offer an alternative address that used IPSec.) SSH and SSL are "good enough" that there's no pressure to use IPSec, and SSL gets all of the newspaper coverage so is the only one general users are even aware of.

Having said that, IPSec is sill very controversial, with plenty of people arguing that it encrypts at the wrong layer. The primary benefits are that you've a single implementation (therefore fewer opportunities for bugs and fewer states to track if heavily used) and that it encrypts everything, so it is impossible for crackers to use non-encrypted session information to help in breaking the keys. However, because it encrypts everything that goes through the tunnel, it adds a lot to the latency. This is helped some with encryption co-processors, such as Motorola's S1, but these are not widely used or supported. Or even known about.

Linux kernel developers, for a long time, opposed ANY support for encryption hardware in the kernel. They argued that encryption was an application activity, so kernel support was the wrong place. Even if that were true, one major point of a kernel is to provide abstraction for hardware and another is to control access to it. The kernel's memory is also a little more secure than userspace, which is really handy if you're planning on maintaining non-trivial security.

This kind of fighting was not limited to Linux, by any means, and is far from dead in any system - although, for microkernels that implement mandatory access controls for virtual memory, it might be considered a moot point as there would be no serious distinction between kernel encryption and userland encryption at that point.

Of course, all of it is largely redundant anyway. IPSec over the Internet is quite impossible, when you have mandatory wiretapping, because it is wiretapping that IPSec is designed to prevent. IPSec, then, is only really legal for internal networks - and that is probably the least useful place for it (except maybe for wireless networks).