diff options
Diffstat (limited to 'doc/src/compat.html')
| -rw-r--r-- | doc/src/compat.html | 795 |
1 files changed, 795 insertions, 0 deletions
diff --git a/doc/src/compat.html b/doc/src/compat.html new file mode 100644 index 000000000..a8e1455bf --- /dev/null +++ b/doc/src/compat.html @@ -0,0 +1,795 @@ +<html> +<head> + <meta http-equiv="Content-Type" content="text/html"> + <title>FreeS/WAN compatibility guide</title> + <meta name="keywords" + content="Linux, IPsec, VPN, security, FreeSWAN, compatibility"> + <!-- + + Written by Sandy Harris for the Linux FreeS/WAN project + Freely distributable under the GNU General Public License + + More information at www.freeswan.org + Feedback to users@lists.freeswan.org + + CVS information: + RCS ID: $Id: compat.html,v 1.1 2004/03/15 20:35:24 as Exp $ + Last changed: $Date: 2004/03/15 20:35:24 $ + Revision number: $Revision: 1.1 $ + + CVS revision numbers do not correspond to FreeS/WAN release numbers. + --> +</head> + +<body> +<h1><a name="compat">Linux FreeS/WAN Compatibility Guide</a></h1> + +<p>Much of this document is quoted directly from the Linux FreeS/WAN <a +href="mail.html">mailing list</a>. Thanks very much to the community of +testers, patchers and commenters there, especially the ones quoted below but +also various contributors we haven't quoted.</p> + +<h2><a name="spec">Implemented parts of the IPsec Specification</a></h2> + +<p>In general, do not expect Linux FreeS/WAN to do everything yet. This is a +work-in-progress and some parts of the IPsec specification are not yet +implemented.</p> + +<h3><a name="in">In Linux FreeS/WAN</a></h3> + +<p>Things we do, as of version 1.96:</p> +<ul> + <li>key management methods + <dl> + <dt>manually keyed</dt> + <dd>using keys stored in /etc/ipsec.conf</dd> + <dt>automatically keyed</dt> + <dd>Automatically negotiating session keys as required. All + connections are automatically re-keyed periodically. The <a + href="glossary.html#Pluto">Pluto</a> daemon implements this using + the <a href="glossary.html#IKE">IKE</a> protocol.</dd> + </dl> + </li> + <li>Methods of authenticating gateways for IKE + <dl> + <dt>shared secrets</dt> + <dd>stored in <a + href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a></dd> + <dt><a href="glossary.html#RSA">RSA</a> signatures</dt> + <dd>For details, see <a + href="manpage.d/ipsec_pluto.8.html">pluto(8)</a>.</dd> + <dt>looking up RSA authentication keys from <a + href="glossary.html#DNS">DNS</a>.</dt> + <dd>Note that this technique cannot be fully secure until <a + href="glossary.html#SDNS">secure DNS</a> is widely deployed.</dd> + </dl> + </li> + <li>groups for <a href="glossary.html#DH">Diffie-Hellman</a> key negotiation + <dl> + <dt>group 2, modp 1024-bit</dt> + <dt>group 5, modp 1536-bit</dt> + <dd>We implement these two groups. + <p>In negotiating a keying connection (ISAKMP SA, Phase 1) we + propose both groups when we are the initiator, and accept either + when a peer proposes them. Once the keying connection is made, we + propose only the alternative agreed there for data connections + (IPsec SA's, Phase 2) negotiated over that keying connection.</p> + </dd> + </dl> + </li> + <li>encryption transforms + <dl> + <dt><a href="glossary.html#DES">DES</a></dt> + <dd>DES is in the source code since it is needed to implement 3DES, + but single DES is not made available to users because <a + href="politics.html#desnotsecure">DES is insecure</a>.</dd> + <dt><a href="glossary.html#3DES">Triple DES</a></dt> + <dd>implemented, and used as the default encryption in Linux + FreeS/WAN.</dd> + </dl> + </li> + <li>authentication transforms + <dl> + <dt><a href="glossary.html#HMAC">HMAC</a> using <a + href="glossary.html#MD5">MD5</a></dt> + <dd>implemented, may be used in IKE or by by AH or ESP + transforms.</dd> + <dt><a href="glossary.html#HMAC">HMAC</a> using <a + href="glossary.html#SHA">SHA</a></dt> + <dd>implemented, may be used in IKE or by AH or ESP transforms.</dd> + </dl> + <p>In negotiations, we propose both of these and accept either.</p> + </li> + <li>compression transforms + <dl> + <dt>IPComp</dt> + <dd>IPComp as described in RFC 2393 was added for FreeS/WAN 1.6. Note + that Pluto becomes confused if you ask it to do IPComp when the + kernel cannot.</dd> + </dl> + </li> +</ul> + +<p>All combinations of implemented transforms are supported. Note that some +form of packet-level <strong>authentication is required whenever encryption +is used</strong>. Without it, the encryption will not be secure.</p> + +<h3><a name="dropped">Deliberately omitted</a></h3> +We do not implement everything in the RFCs because some of those things are +insecure. See our discussions of avoiding <a href="politics.html#weak">bogus +security</a>. + +<p>Things we deliberately omit which are required in the RFCs are:</p> +<ul> + <li>null encryption (to use ESP as an authentication-only service)</li> + <li>single DES</li> + <li>DH group 1, a 768-bit modp group</li> +</ul> + +<p>Since these are the only encryption algorithms and DH group the RFCs +require, it is possible in theory to have a standards-conforming +implementation which will not interpoperate with FreeS/WAN. Such an +implementation would be inherently insecure, so we do not consider this a +problem.</p> + +<p>Anyway, most implementations sensibly include more secure options as well, +so dropping null encryption, single DES and Group 1 does not greatly hinder +interoperation in practice.</p> + +<p>We also do not implement some optional features allowed by the RFCs:</p> +<ul> + <li>aggressive mode for negotiation of the keying channel or ISAKMP SA. + This mode is a little faster than main mode, but exposes more information + to an eavesdropper.</li> +</ul> + +<p>In theory, this should cause no interoperation problems since all +implementations are required to support the more secure main mode, whether or +not they also allow aggressive mode.</p> + +<p>In practice, it does sometimes produce problems with implementations such +as Windows 2000 where aggressive mode is the default. Typically, these are +easily solved with a configuration change that overrides that default.</p> + +<h3><a name="not">Not (yet) in Linux FreeS/WAN</a></h3> + +<p>Things we don't yet do, as of version 1.96:</p> +<ul> + <li>key management methods + <ul> + <li>authenticate key negotiations via local <a + href="glossary.html#PKI">PKI</a> server, but see links to user <a + href="web.html#patch">patches</a></li> + <li>authenticate key negotiations via <a + href="glossary.html#SDNS">secure DNS</a></li> + <li>unauthenticated key management, using <a + href="glossary.html#DH">Diffie-Hellman</a> key agreement protocol + without authentication. Arguably, this would be worth doing since it + is secure against all passive attacks. On the other hand, it is + vulnerable to an active <a + href="glossary.html#middle">man-in-the-middle attack</a>.</li> + </ul> + </li> + <li>encryption transforms + <p>Currently <a href="glossary.html#3DES">Triple DES</a> is the only + encryption method Pluto will negotiate.</p> + <p>No additional encryption transforms are implemented, though the RFCs + allow them and some other IPsec implementations support various of them. + We are not eager to add more. See this <a + href="faq.html#other.cipher">FAQ question</a>.</p> + <p><a href="glossary.html#AES">AES</a>, the successor to the DES + standard, is an excellent candidate for inclusion in FreeS/WAN, see links + to user <a href="web.html#patch">patches</a>.</p> + </li> + <li>authentication transforms + <p>No optional additional authentication transforms are currently + implemented. Likely <a href="glossary.html#SHA-256">SHA-256, SHA-384 and + SHA-512</a> will be added when AES is.</p> + </li> + <li>Policy checking on decrypted packets + <p>To fully comply with the RFCs, it is not enough just to accept only + packets which survive any firewall rules in place to limit what IPsec + packets get in, and then pass KLIPS authentication. That is what + FreeS/WAN currently does.</p> + <p>We should also apply additional tests, for example ensuring that all + packets emerging from a particular tunnel have source and destination + addresses that fall within the subnets defined for that tunnel, and that + packets with those addresses that did not emerge from the appropriate + tunnel are disallowed.</p> + <p>This will be done as part of a KLIPS rewrite. See these <a + href="intro.html#applied">links</a> and the <a href="mail.html">design + mailing list</a> for discussion.</p> + </li> +</ul> + +<h2><a name="pfkey">Our PF-Key implementation</a></h2> + +<p>We use PF-key Version Two for communication between the KLIPS kernel code +and the Pluto Daemon. PF-Key v2 is defined by <a +href="http://www.normos.org/ietf/rfc/rfc2367.txt">RFC 2367</a>.</p> + +<p>The "PF" stands for Protocol Family. PF-Inet defines a kernel/userspace +interface for the TCP/IP Internet protocols (TCP/IP), and other members of +the PF series handle Netware, Appletalk, etc. PF-Key is just a PF for +key-related matters.</p> + +<h3><a name="pfk.port">PF-Key portability</a></h3> + +<p>PF-Key came out of Berkeley Unix work and is used in the various BSD IPsec +implementations, and in Solaris. This means there is some hope of porting our +Pluto(8) to one of the BSD distributions, or of running their photurisd(8) on +Linux if you prefer <a href="glossary.html#photuris">Photuris</a> key +management over IKE.</p> + +<p>It is, however, more complex than that. The PK-Key RFC deliberately deals +only with keying, not policy management. The three PF-Key implementations we +have looked at -- ours, OpenBSD and KAME -- all have extensions to deal with +security policy, and the extensions are different. There have been +discussions aimed at sorting out the differences, perhaps for a version three +PF-Key spec. All players are in favour of this, but everyone involved is busy +and it is not clear whether or when these discussions might bear fruit.</p> + +<h2><a name="otherk">Kernels other than the latest 2.2.x and 2.4.y</a></h2> + +<p>We develop and test on Redhat Linux using the most recent kernel in the +2.2 and 2.4 series. In general, we recommend you use the latest kernel in one +of those series. Complications and caveats are discussed below.</p> + +<h3><a name="kernel.2.0">2.0.x kernels</a></h3> + +<p>Consider upgrading to the 2.2 kernel series. If you want to stay with the +2.0 series, then we strongly recommend 2.0.39. Some useful security patches +were added in 2.0.38.</p> + +<p>Various versions of the code have run at various times on most 2.0.xx +kernels, but the current version is only lightly tested on 2.0.39, and not at +all on older kernels.</p> + +<p>Some of our patches for older kernels are shipped in 2.0.37 and later, so +they are no longer provided in FreeS/WAN. This means recent versions of +FreeS/WAN will probably not compile on anything earlier than 2.0.37.</p> + +<h3><a name="kernel.production">2.2 and 2.4 kernels</a></h3> +<dl> + <dt>FreeS/WAN 1.0</dt> + <dd>ran only on 2.0 kernels</dd> + <dt>FreeS/WAN 1.1 to 1.8</dt> + <dd>ran on 2.0 or 2.2 kernels<br> + ran on some development kernels, 2.3 or 2.4-test</dd> + <dt>FreeS/WAN 1.9 to 1.96</dt> + <dd>runs on 2.0, 2.2 or 2.4 kernels</dd> +</dl> + +<p>In general, <strong>we suggest the latest 2.2 kernel or 2.4 for production +use</strong>.</p> + +<p>Of course no release can be guaranteed to run on kernels more recent than +it is, so quite often there will be no stable FreeS/WAN for the absolute +latest kernel. See the <a href="faq.html#k.versions">FAQ</a> for +discussion.</p> + +<h2><a name="otherdist">Intel Linux distributions other than Redhat</a></h2> + +<p>We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat 7.1 or +7.2 for 2.4, so minor changes may be required for other distributions.</p> + +<h3><a name="rh7">Redhat 7.0</a></h3> + +<p>There are some problems with FreeS/WAN on Redhat 7.0. They are soluble, +but we recommend you upgrade to a later Redhat instead..</p> + +<p>Redhat 7 ships with two compilers.</p> +<ul> + <li>Their <var>gcc</var> is version 2.96. Various people, including the GNU + compiler developers and Linus, have said fairly emphatically that using + this was a mistake. 2.96 is a development version, not intended for + production use. In particular, it will not compile a Linux kernel.</li> + <li>Redhat therefore also ship a separate compiler, which they call + <var>kgcc</var>, for compiling kernels.</li> +</ul> + +<p>Kernel Makefiles have <var>gcc</var> as a default, and must be adjusted to +use <var>kgcc</var> before a kernel will compile on 7.0. This mailing list +message gives details:</p> +<pre>Subject: Re: AW: Installing IPsec on Redhat 7.0 + Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST) + From: Mads Rasmussen <mads@cit.com.br> + +> From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1 + +cd to /usr/src/linux and open the Makefile in your favorite editor. You +will need to look for a line similar to this: + +CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH) + +This line specifies which C compiler to use to build the kernel. It should +be changed to: + +CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH) + +for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can +proceed with the typical compiling steps.</pre> + +<p>Check the <a href="mail.html">mailing list</a> archive for more recent +news.</p> + +<h3><a name="suse">SuSE Linux</a></h3> + +<p>SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN +included.</p> + +<P>FreeS/WAN packages distributed for SuSE 7.0-7.2 were somehow +miscompiled. You can find fixed packages on +<A HREF="http://www.suse.de/~garloff/linux/FreeSWAN"> +Kurt Garloff's page</A>.</P> + +<p>Here are some notes for an earlier SuSE version.</p> + +<h4>SuSE Linux 5.3</h4> +<pre>Date: Mon, 30 Nov 1998 +From: Peter Onion <ponion@srd.bt.co.uk> + +... I got Saturdays snapshot working between my two SUSE5.3 machines at home. + +The mods to the install process are quite simple. From memory and looking at +the files on the SUSE53 machine here at work.... + +And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec +which SUSE use to shut a service down. + +A few mods in /etc/init.d/ipsec to cope with the different places that SUSE +put config info, and remove the inculsion of /etc/rc.d/init.d/functions and . +/etc/sysconfig/network as they don't exists and 1st one isn't needed anyway. + +insert ". /etc/rc.config" to pick up the SUSE config info and use + + if test -n "$NETCONFIG" -a "$NETCONFIG" != "YAST_ASK" ; then + +to replace + + [ ${NETWORKING} = "no" ] && exit 0 + +Create /etc/sysconfig as SUSE doesn't have one. + +I think that was all (but I prob forgot something)....</pre> + +<p>You may also need to fiddle initialisation scripts to ensure that +<var>/var/run/pluto.pid</var> is removed when rebooting. If this file is +present, Pluto does not come up correctly.</p> + +<h3><a name="slack">Slackware</a></h3> +<pre>Subject: Re: linux-IPsec: Slackware distribution + Date: Thu, 15 Apr 1999 12:07:01 -0700 + From: Evan Brewer <dmessiah@silcon.com> + +> Very shortly, I will be needing to install IPsec on at least gateways that +> are running Slackware. . . . + +The only trick to getting it up is that on the slackware dist there is no +init.d directory in /etc/rc.d .. so create one. Then, what I do is take the +IPsec startup script which normally gets put into the init.d directory, and +put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file +in init.d. The only file in the dist you need to really edit is the +utils/Makefile, setup4: + +Everything else should be just fine.</pre> + +<p>A year or so later:</p> +<pre>Subject: Re: HTML Docs- Need some cleanup? + Date: Mon, 8 Jan 2001 + From: Jody McIntyre <jodym@oeone.com> + +I have successfully installed FreeS/WAN on several Slackware 7.1 machines. +FreeS/WAN installed its rc.ipsec file in /etc/rc.d. I had to manually call +this script from rc.inet2. This seems to be an easier method than Evan +Brewer's.</pre> + +<h3><a name="deb">Debian</a></h3> + +<p>A recent (Nov 2001) mailing list points to a <a +href="http://www.thing.dyndns.org/debian/vpn.htm">web page</a> on setting up +several types of tunnel, including IPsec, on Debian.</p> + +<p>Some older information:</p> +<pre>Subject: FreeS/WAN 1.0 on Debian 2.1 + Date: Tue, 20 Apr 1999 + From: Tim Miller <cerebus+counterpane@haybaler.sackheads.org> + + Compiled and installed without error on a Debian 2.1 system +with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to +/etc/init.d. + + /var/lock/subsys/ doesn't exist on Debian boxen, needs to be +created; not a fatal error. + + Finally, IPsec scripts appear to be dependant on GNU awk +(gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties. +With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk +operation appears flawless.</pre> + +<p>The scripts in question have been modified since this was posted. Awk +versions should no longer be a problem.</p> + +<h3><a name="caldera">Caldera</a></h3> +<pre>Subject: Re: HTML Docs- Need some cleanup? + Date: Mon, 08 Jan 2001 + From: Andy Bradford <andyb@calderasystems.com> + +On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote: + +> Intel Linux distributions other than Redhat 5.x and 6.x +> Redhat 7.0 +> SuSE Linux +> SuSE Linux 5.3 +> Slackware +> Debian + +Can you please include Caldera in this list? I have tested it since +FreeS/Wan 1.1 and it works great with our systems---provided one +follows the FreeS/Wan documentation. :-) + +Thank you, +Andy</pre> + +<h2><a name="CPUs">CPUs other than Intel</a></h2> + +<p>FreeS/WAN has been run sucessfully on a number of different CPU +architectures. If you have tried it on one not listed here, please post to +the <a href="mail.html">mailing list</a>.</p> + +<h3><a name=" strongarm">Corel Netwinder (StrongARM CPU)</a></h3> +<pre>Subject: linux-ipsec: Netwinder diffs +Date: Wed, 06 Jan 1999 +From: rhatfield@plaintree.com + +I had a mistake in my IPsec-auto, so I got things working this morning. + +Following are the diffs for my changes. Probably not the best and cleanest way +of doing it, but it works. . . . </pre> + +<p>These diffs are in the 0.92 and later distributions, so these should work +out-of-the-box on Netwinder.</p> + +<h3><a name="yellowdog">Yellow Dog Linux on Power PC</a></h3> +<pre>Subject: Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC) + Date: 11 Dec 1999 + From: Darron Froese <darron@fudgehead.com> + +I'm summarizing here for the record - because it's taken me many hours to do +this (multiple times) and because I want to see IPsec on more linuxes than +just x86. + +Also, I can't remember if I actually did summarize it before... ;-) I'm +working too many late hours. + +That said - here goes. + +1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13. +<http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2> + +2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1 +<ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz> + +3. Get the gmp src rpm from here: +<ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm> + +4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm + +You will see a lot of text fly by and when you start to see the rpm +recompiling like this: + +Executing: %build ++ umask 022 ++ cd /usr/src/redhat/BUILD ++ cd gmp-2.0.2 ++ libtoolize --copy --force +Remember to add `AM_PROG_LIBTOOL' to `configure.in'. +You should add the contents of `/usr/share/aclocal/libtool.m4' to +`aclocal.m4'. ++ CFLAGS=-O2 -fsigned-char ++ ./configure --prefix=/usr + +Hit Control-C to stop the rebuild. NOTE: We're doing this because for some +reason the gmp source provided with FreeS/WAN 1.1 won't build properly on +ydl. + +cd /usr/src/redhat/BUILD/ +cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/ +cd /usr/src/freeswan-1.1/ +rm -rf gmp +mv gmp-2.0.2 gmp + +5. Open the freeswan Makefile and change the line that says: +KERNEL=$(b)zimage (or something like that) to +KERNEL=vmlinux + +6. cd ../linux/ + +7. make menuconfig +Select an option or two and then exit - saving your changes. + +8. cd ../freeswan-1.1/ ; make menugo + +That will start the whole process going - once that's finished compiling, +you have to install your new kernel and reboot. + +That should build FreeS/WAN on ydl (I tried it on 1.1).</pre> +And a later message on the same topic: +<pre>Subject: Re: FreeS/WAN, PGPnet and E-mail + Date: Sat, 22 Jan 2000 + From: Darron Froese <darron@fudgehead.com> + +on 1/22/00 6:47 PM, Philip Trauring at philip@trauring.com wrote: + +> I have a PowerMac G3 ... + +The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run +FreeS/WAN 1.2patch1 with a couple minor modifications: + +1. In the Makefile it specifies a bzimage for the kernel compile - you have +to change that to vmlinux for the PPC. + +2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to +compile. I have gotten around this by getting the gmp src rpm from here: + +ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm + +If you rip the source out of there - and place it where the gmp source +resides it will compile just fine.</pre> + +<p>FreeS/WAN no longer includes GMP source.</p> + +<h3><a name="mklinux">Mklinux</a></h3> + +<p>One user reports success on the Mach-based +<strong>m</strong>icro<strong>k</strong>ernel Linux.</p> +<pre>Subject: Smiles on sparc and ppc + Date: Fri, 10 Mar 2000 + From: Jake Hill <jah@alien.bt.co.uk> + +You may or may not be interested to know that I have successfully built +FreeS/WAN on a number of non intel alpha architectures; namely on ppc +and sparc and also on osfmach3/ppc (MkLinux). I can report that it just +works, mostly, with few changes.</pre> + +<h3><a name="alpha">Alpha 64-bit processors</a></h3> +<pre>Subject: IT WORKS (again) between intel & alpha :-))))) + Date: Fri, 29 Jan 1999 + From: Peter Onion <ponion@srd.bt.co.uk> + +Well I'm happy to report that I've got an IPsec connection between by intel & alpha machines again :-)) + +If you look back on this list to 7th of December I wrote... + +-On 07-Dec-98 Peter Onion wrote: +-> +-> I've about had enuf of wandering around inside the kernel trying to find out +-> just what is corrupting outgoing packets... +- +-Its 7:30 in the evening ..... +- +-I FIXED IT :-)))))))))))))))))))))))))))))))) +- +-It was my own fault :-(((((((((((((((((( +- +-If you ask me very nicly I'll tell you where I was a little too over keen to +-change unsigned long int __u32 :-) OPSE ... +- +-So tomorrow it will full steam ahead to produce a set of diffs/patches against +-0.91 +- +-Peter Onion.</pre> + +<p>In general (there have been some glitches), FreeS/WAN has been running on +Alphas since then.</p> + +<h3><a name="SPARC">Sun SPARC processors</a></h3> + +<p>Several users have reported success with FreeS/WAN on SPARC Linux. Here is +one mailing list message:</p> +<pre>Subject: Smiles on sparc and ppc + Date: Fri, 10 Mar 2000 + From: Jake Hill <jah@alien.bt.co.uk> + +You may or may not be interested to know that I have successfully built +FreeS/WAN on a number of non intel alpha architectures; namely on ppc +and sparc and also on osfmach3/ppc (MkLinux). I can report that it just +works, mostly, with few changes. + +I have a question, before I make up some patches. I need to hack +gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are +trivial, but could I also use a different version of gmp? Is it vanilla +here? + +I guess my only real headache is from ipchains, which appears to stop +running when IPsec has been started for a while. This is with 2.2.14 on +sparc.</pre> + +<p>This message, from a different mailing list, may be relevant for anyone +working with FreeS/WAN on Suns:</p> +<pre>Subject: UltraSPARC DES assembler + Date: Thu, 13 Apr 2000 + From: svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) + To: coderpunks@toad.com + +An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c +file is available at http://inet.uni2.dk/~svolaf/des.htm. + +This brings DES on UltraSPARC from slower than Pentium at the same +clock speed to significantly faster.</pre> + +<h3><a name="mips">MIPS processors</a></h3> + +<p>We know FreeS/WAN runs on at least some MIPS processors because <a +href="http://www.lasat.com">Lasat</a> manufacture an IPsec box based on an +embedded MIPS running Linux with FreeS/WAN. We have no details.</p> + +<h3><a name="crusoe">Transmeta Crusoe</a></h3> + +<p>The Merilus <a +href="http://www.merilus.com/products/fc/index.shtml">Firecard</a>, a Linux +firewall on a PCI card, is based on a Crusoe processor and supports +FreeS/WAN.</p> + +<h3><a name="coldfire">Motorola Coldfire</a></h3> +<pre>Subject: Re: Crypto hardware support + Date: Mon, 03 Jul 2000 + From: Dan DeVault <devault@tampabay.rr.com> + +.... I have been running +uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay ( +http://www.moretonbay.com ) and it was using a Coldfire processor +and was able to do the Triple DES encryption at just about +1 mbit / sec rate....... they put a Hi/Fn 7901 hardware encryption +chip on their board and now their system does over 25 mbit of 3DES +encryption........ pretty significant increase if you ask me.</pre> + +<h2><a name="multiprocessor">Multiprocessor machines</a></h2> + +<p>FreeS/WAN is designed to work on SMP (symmetric multi-processing) Linux +machines and is regularly tested on dual processor x86 machines.</p> + +<p>We do not know of any testing on multi-processor machines with other CPU +architectures or with more than two CPUs. Anyone who does test this, please +report results to the <a href="mail.html">mailing list</a>.</p> + +<p>The current design does not make particularly efficient use of +multiprocessor machines; some of the kernel work is single-threaded.</p> + +<h2><a name="hardware">Support for crypto hardware</a></h2> + +<p>Supporting hardware cryptography accelerators has not been a high priority +for the development team because it raises a number of fairly complex +issues:</p> +<ul> + <li>Can you trust the hardware? If it is not Open Source, how do you audit + its security? Even if it is, how do you check that the design has no + concealed traps?</li> + <li>If an interface is added for such hardware, can that interface be + subverted or misused?</li> + <li>Is hardware acceleration actually a performance win? It clearly is in + many cases, but on a fast machine it might be better to use the CPU for + the encryption than to pay the overheads of moving data to and from a + crypto board.</li> + <li>the current KLIPS code does not provide a clean interface for hardware + accelerators</li> +</ul> + +<p>That said, we have a <a href="#coldfire">report</a> of FreeS/WAN working +with one crypto accelerator and some work is going on to modify KLIPS to +create a clean generic interface to such products. See this <a +href="http://www.jukie.net/~bart/linux-ipsec/">web page</a> for some of the +design discussion.</p> + +<p>More recently, a patch to support some hardware accelerators has been +posted:</p> +<pre>Subject: [Design] [PATCH] H/W acceleration patch + Date: Tue, 18 Sep 2001 + From: "Martin Gadbois" <martin.gadbois@colubris.com> + +Finally!! +Here's a web site with H/W acceleration patch for FreeS/WAN 1.91, including +S/W and Hifn 7901 crypto support. + +http://sources.colubris.com/ + +Martin Gadbois</pre> + +<p>Hardware accelerators could take performance well beyond what FreeS/WAN +can do in software (discussed <a href="performance.html">here</a>). Here is +some discussion off the IETF IPsec list, October 2001:</p> +<pre> ... Currently shipping chips deliver, 600 mbps throughput on a single + stream of 3DES IPsec traffic. There are also chips that use multiple + cores to do 2.4 gbps. We (Cavium) and others have announced even faster + chips. ... Mid 2002 versions will handle at line rate (OC48 and OC192) + IPsec and SSL/TLS traffic not only 3DES CBC but also AES and arc4.</pre> + +<p>The patches to date support chips that have been in production for some +time, not the state-of-the-art latest-and-greatest devices described in that +post. However, they may still outperform software and they almost certainly +reduce CPU overhead.</p> + +<h2><a name="ipv6">IP version 6 (IPng)</a></h2> + +<p>The Internet currently runs on version four of the IP protocols. IPv4 is +what is in the standard Linux IP stack, and what FreeS/WAN was built for. In +IPv4, IPsec is an optional feature.</p> + +<p>The next version of the IP protocol suite is version six, usually +abbreviated either as "IPv6" or as "IPng" for "IP: the next generation". For +IPv6, IPsec is a required feature. Any machine doing IPv6 is required to +support IPsec, much as any machine doing (any version of) IP is required to +support ICMP.</p> + +<p>There is a Linux implementation of IPv6 in Linux kernels 2.2 and above. +For details, see the <a +href="http://www.cs-ipv6.lancs.ac.uk/ipv6/systems/linux/faq/">FAQ</a>. It +does not yet support IPsec. The <a +href="http://www.linux-ipv6.org/">USAGI</a> project are also working on IPv6 +for Linux.</p> + +<p>FreeS/WAN was originally built for the current standard, IPv4, but we are +interested in seeing it work with IPv6. Some progress has been made, and a +patched version with IPv6 support is <a +href="http://www.ipv6.iabg.de/downloadframe/index.html">available</a>. For +more recent information, check the <a href="mail.html">mailing list</a>.</p> + +<h3><a name="v6.back">IPv6 background</a></h3> + +<p>IPv6 has been specified by an IETF <a +href="http://www.ietf.org/html.charters/ipngwg-charter.html">working +group</a>. The group's page lists over 30 RFCs to date, and many Internet +Drafts as well. The overview is <a +href="http://www.ietf.org/rfc/rfc2460.txt">RFC 2460</a>. Major features +include:</p> +<ul> + <li>expansion of the address space from 32 to 128 bits,</li> + <li>changes to improve support for + <ul> + <li>mobile IP</li> + <li>automatic network configuration</li> + <li>quality of service routing</li> + <li>...</li> + </ul> + </li> + <li>improved security via IPsec</li> +</ul> + +<p>A number of projects are working on IPv6 implementation. A prominent Open +Source effort is <a href="http://www.kame.net/">KAME</a>, a collaboration +among several large Japanese companies to implement IPv6 for Berkeley Unix. +Other major players are also working on IPv6. For example, see pages at:</p> +<ul> + <li><a + href="http://playground.sun.com/pub/ipng/html/ipng-main.html">Sun</a></li> + <li><a + href="http://www.cisco.com/warp/public/732/ipv6/index.html">Cisco</a></li> + <li><a + href="http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/IPv6.asp">Microsoft</a></li> +</ul> + +<p>The <a href="http://www.6bone.net/">6bone</a> (IPv6 backbone) testbed +network has been up for some time. There is an active <a +href="http://www.ipv6.org/">IPv6 user group</a>.</p> + +<p>One of the design goals for IPv6 was that it must be possible to convert +from v4 to v6 via a gradual transition process. Imagine the mess if there +were a "flag day" after which the entire Internet used v6, and all software +designed for v4 stopped working. Almost every computer on the planet would +need major software changes! There would be huge costs to replace older +equipment. Implementers would be worked to death before "the day", systems +administrators and technical support would be completely swamped after it. +The bugs in every implementation would all bite simultaneously. Large chunks +of the net would almost certainly be down for substantial time periods. +...</p> + +<p>Fortunately, the design avoids any "flag day". It is therefore a little +tricky to tell how quickly IPv6 will take over. The transition has certainly +begun. For examples, see announcements from <a +href="http://www.mailbase.ac.uk/lists/internet2/2000-03/0016.html">NTT</a> +and <a href="http://www.vnunet.com/News/1102383">Nokia</a>. However, it is +not yet clear how quickly the process will gain momentum, or when it will be +completed. Likely large parts of the Internet will remain with IPv4 for years +to come.</p> +</body> +</html> |