diff options
Diffstat (limited to 'doc/src/compat.html')
| -rw-r--r-- | doc/src/compat.html | 795 |
1 files changed, 0 insertions, 795 deletions
diff --git a/doc/src/compat.html b/doc/src/compat.html deleted file mode 100644 index a8e1455bf..000000000 --- a/doc/src/compat.html +++ /dev/null @@ -1,795 +0,0 @@ -<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> |