Chapter 3

NETKEY, the 2.6 IPsec Stack

This relatively new IPsec stack is based on the KAME stack from the BSD world. It is not a direct port, but it uses the same API, so the same software that runs on a BSD can be used to run it on Linux (The Racoon daemon or the isakmpd daemon). Because of the various back ports of this stack to the 2.4 kernel, one should not call this 'the 2.6 stack'. Other suggestions for names have been made, such as '26sec' or 'native' stack. Throughout the book, we will call this the NETKEY stack, since the configuration option for this stack is CONFIG_NET_KEY.

The NETKEY stack is under heavy development, which can be considered both good and bad. It supports both IPv4 and IPv6. It does not support first packet caching and still seems to have a little bit more of a problem with Path MTU discovery.

NETKEY also hooks into the networking code differently. Packets are intercepted by the IPsec stack after they are received on the physical ethX interface, and magically reappear on the same device in decrypted form. Packets that are being sent appear only in encrypted form. This complicates iptables-based firewall rules and can be confusing when using tcpdump to debug IPsec connections.

This interception also creates problems when using NAT and IPsec on the same machine, since the packet does not traverse through all the iptables as expected. Unencrypted packets never travel the POSTROUTING table. The netfilter patch-o-matic set of patches contains fixes for this, but they are being tested and are not yet ready for inclusion in the kernel.

Finally, NETKEY has another problem in how it implements the state of IPsec tunnels and the matching of known IPsec tunnels. Where KLIPS sorts its tunnels like a routing table, meaning it uses the most specific match first, NETKEY sorts based on destination for the incoming packets, and based on source for the outgoing packets. This results in a strange match on most generic first. This causes problems for a setup where a local IP range used by teleworkers (for instance 192.168.1.0/24) is part of a bigger range used by the entire company (like 192.168.0.0/16). With KLIPS you can define one tunnel for this setup, but with NETKEY you need to poke holes to avoid having the local IP nodes being considered on the other end of the tunnel.

Most people agree that this will become the default IPsec stack to use on Linux, but there is a clear demand for the features of KLIPS to be added to NETKEY. For Linux 2.6, you have a choice of either KLIPS or NETKEY. Hopefully, the good sides of both will merge into one stack that is even better.

The USAGI / SuSE IPsec Stack

The USAGI patch to add IPv6 to KLIPS was rejected by its maintainers, because it consisted of a crude cut-and-paste job. A lot of the code from KLIPS had been copied, renamed and had IPv6 features added to it. This was considered to be an unmaintainable hack that would have duplicated code all over the place. SuSE, however, had a strong need for IPv6, and reluctantly integrated the USAGI patch into KLIPS. Now, just like most other distributions, SuSE is moving towards NETKEY for its IPv6 functionality, so don't count on anyone maintaining this stack.

53