Differences between revisions 16 and 17
Revision 16 as of 2006-09-04 18:17:13
Size: 5872
Comment: Remove old kwiki cruft
Revision 17 as of 2007-01-05 16:43:57
Size: 5874
Editor: ?foo
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
Then, the Debian Linux packages (both source and images), starting with version 2.4.21, included a backport of the KAME kernel IPsec API from the 2.5 series of Linux. This presents a problem for those users of Debian [http://wiki.debian.net/index.cgi?DebianWoody Woody] using FreeS/WAN; the packages in Woody does not support the new API. The only possible solution was to use the kernel-patch-freeswan, but go back to version 2.4.18 of the Linux packages, which was apparently the only ones receiving security updates, anyway. Then, the Debian Linux packages (both source and images), starting with version 2.4.21, included a backport of the KAME kernel IPsec API from the 2.5 series of Linux. This presented a problem for those users of Debian [http://wiki.debian.net/index.cgi?DebianWoody Woody] using FreeS/WAN; the packages in Woody did not support the new API. The only possible solution was to use the kernel-patch-freeswan, but go back to version 2.4.18 of the Linux packages, which was apparently the only ones receiving security updates, anyway.
Line 17: Line 17:
Also, the FreeS/WAN project recently ended; the final version was 2.06. A program whose original API was not chosen for adoption in Linux and which faces an uncertain future is hardly the solution of choice for those who value stability. (FreeS/WAN has been forked, one branch of which is in Debian testing and unstable, but those projects has yet to prove themselves to have the stability and commitment of the FreeS/WAN project.) Also, the FreeS/WAN project had recently ended; the final version was 2.06. A program whose original API was not chosen for adoption in Linux and which faces an uncertain future is hardly the solution of choice for those who value stability. (FreeS/WAN has been forked, one branch of which is in Debian testing and unstable, but those projects has yet to prove themselves to have the stability and commitment of the FreeS/WAN project.)
Line 19: Line 19:
And for those users who '''needs''' a newer Linux than 2.4.18 for their hardware, and had been using 2.4.20, the situation was (and is) problematic. The newer Linux source packages could not be unpatched to remove the IPSec support without failed hunks. Neither could the FreeS/WAN source be patched to understand the new API without similar problems. The newer FreeS/WAN packages from "unstable" and "testing" failed to compile in Woody. And for those users who '''needed''' a newer Linux than 2.4.18 for their hardware, and had been using 2.4.20, the situation was problematic. The newer Linux source packages could not be unpatched to remove the IPSec support without failed hunks. Neither could the FreeS/WAN source be patched to understand the new API without similar problems. The newer FreeS/WAN packages from "unstable" and "testing" failed to compile in Woody.
Line 21: Line 21:
The only thing left to do for those users is to bite the bullet and convert completely to the "new" model; to use the KAME user-level programs which works with the new Linux API. The KAME tools do not exist in Woody, '''but''' they exist in testing and unstable, '''and''' the {{{debian/rules}}} file includes an easily-enabled conditional to enable compiling the packages for woody. See RacoonInWoody. The only thing left to do for those users was to bite the bullet and convert completely to the "new" model; to use the KAME user-level programs which works with the new Linux API. The KAME tools do not exist in Woody, '''but''' they existed in testing (later Sarge), '''and''' the {{{debian/rules}}} file includes an easily-enabled conditional to enable compiling the packages for woody. See RacoonInWoody.
Line 23: Line 23:
Now that Sarge is released, you can create IPSEC tunnels in two different ways. Either by using the Freeswan/Openswan KLIPS methodology or by using the Racoon/BSD KAME method. The necessary patches for Openswan modules are already backported into the stock Debian kernel (2.4.27 & 2.6.8 <I can verify this is true for the 2.6.8 kernel but haven't tried the 2.4.27 kernel>). This method allows for basic use (no NAT) with [http://www.shorewall.net/IPSEC.htm Shorewall] but doesn't implement the new Security Policy Database (SPD). Now that Sarge is released, you can create IPsec tunnels in two different ways. Either by using the Freeswan/Openswan KLIPS methodology or by using the Racoon/BSD KAME method. The necessary patches for Openswan modules are already backported into the stock Debian kernel (2.4.27 & 2.6.8 <I can verify this is true for the 2.6.8 kernel but haven't tried the 2.4.27 kernel>). This method allows for basic use (no NAT) with [http://www.shorewall.net/IPSEC.htm Shorewall] but doesn't implement the new Security Policy Database (SPD).
Line 38: Line 38:
Micro-Howto of using racoon and ipsec-tools in Woody: [Debian IPsec Micro-Howto http://www.fukt.bth.se/~teddy/debian-ipsec] Micro-Howto of using racoon and ipsec-tools in Woody: [Debian IPsec Micro-Howto http://www.fukt.bsnet.se/~teddy/debian-ipsec]

IPsec is short for "IP security". It is a means of authenticating and also optionally encrypting TCP/IP traffic, thereby ensuring a selected measure of security.

[More information about IPsec in general can be found on http://en.wikipedia.org/wiki/IPsec.]

There are, roughly, two parts to an IPsec implementation: one kernel part, which takes care of everything once the encryption or signing keys are known, and one "user-level" program which negotiates beforehand to set the keys up and give them to the kernel part via an IPSec-specific kernel API. The user-level program can also be configured to renegotiate keys periodically so no keys are used for too long.

Since the user-level-program requires kernel-level support it is not as simple as just selecting a package and installing it; you need to make sure that the kernel supports the kernel API that the package you select expects.

Before Linux had IPSec support, there was [http://wiki.debian.net/index.cgi?FreeSWAN FreeS/WAN] and [http://www.kame.net/project-overview.html KAME]. They both included a kernel patch which communicated with a key exchange daemon. KAME had no Debian package, so you would install the packages [http://packages.debian.org/stable/non-US/freeswan freeswan] and [http://packages.debian.org/stable/non-US/kernel-patch-freeswan kernel-patch-freeswan] (both version 1.96), and recompile your kernel with the patch. Life was simple, even if you were forced to use a non-standard kernel.

The experimental Linux 2.5 series (to become 2.6) adopted KAME's kernel API, and the newer upstream versions of FreeS/WAN (2.01 and above) started to support that API too, as well as their own.

Then, the Debian Linux packages (both source and images), starting with version 2.4.21, included a backport of the KAME kernel IPsec API from the 2.5 series of Linux. This presented a problem for those users of Debian [http://wiki.debian.net/index.cgi?DebianWoody Woody] using FreeS/WAN; the packages in Woody did not support the new API. The only possible solution was to use the kernel-patch-freeswan, but go back to version 2.4.18 of the Linux packages, which was apparently the only ones receiving security updates, anyway.

Also, the FreeS/WAN project had recently ended; the final version was 2.06. A program whose original API was not chosen for adoption in Linux and which faces an uncertain future is hardly the solution of choice for those who value stability. (FreeS/WAN has been forked, one branch of which is in Debian testing and unstable, but those projects has yet to prove themselves to have the stability and commitment of the FreeS/WAN project.)

And for those users who needed a newer Linux than 2.4.18 for their hardware, and had been using 2.4.20, the situation was problematic. The newer Linux source packages could not be unpatched to remove the IPSec support without failed hunks. Neither could the FreeS/WAN source be patched to understand the new API without similar problems. The newer FreeS/WAN packages from "unstable" and "testing" failed to compile in Woody.

The only thing left to do for those users was to bite the bullet and convert completely to the "new" model; to use the KAME user-level programs which works with the new Linux API. The KAME tools do not exist in Woody, but they existed in testing (later Sarge), and the debian/rules file includes an easily-enabled conditional to enable compiling the packages for woody. See ?RacoonInWoody.

Now that Sarge is released, you can create IPsec tunnels in two different ways. Either by using the Freeswan/Openswan KLIPS methodology or by using the Racoon/BSD KAME method. The necessary patches for Openswan modules are already backported into the stock Debian kernel (2.4.27 & 2.6.8 <I can verify this is true for the 2.6.8 kernel but haven't tried the 2.4.27 kernel>). This method allows for basic use (no NAT) with [http://www.shorewall.net/IPSEC.htm Shorewall] but doesn't implement the new Security Policy Database (SPD).

The other method is the newer KAME methodology. This is integrated directly into the 2.6 kernel but in order to work with the new security policies(SPD), you need to patch the kernel and iptables with the new netfilter policy match. There is a different Shorewall [http://www.shorewall.net/IPSEC-2.6.html setup] for this type of method.

Ken Bantoft of OpenSwan held a talk on LinuxTag 2004 entitled [The Future of IPsec on Linux http://www.xelerance.com/talks/linuxtag2004/] which contains some history and outlines possible future paths from here.

The KAME packages are called [http://packages.debian.org/testing/net/ipsec-tools ipsec-tools] (source package and command-line utilities) and [http://packages.debian.org/testing/net/racoon racoon] (key exchange daemon).

Micro-Howto of using racoon and ipsec-tools in Woody: [Debian IPsec Micro-Howto http://www.fukt.bsnet.se/~teddy/debian-ipsec]