From aaa0331ecf95ced1e913ac9be50168cf0e7cbb82 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:21:07 +0000 Subject: [svn-upgrade] Integrating new upstream version, strongswan (2.8.2) --- doc/src/compat.html | 795 ---------------------------------------------------- 1 file changed, 795 deletions(-) delete mode 100644 doc/src/compat.html (limited to 'doc/src/compat.html') 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 @@ - - - - FreeS/WAN compatibility guide - - - - - -

Linux FreeS/WAN Compatibility Guide

- -

Much of this document is quoted directly from the Linux FreeS/WAN mailing list. 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.

- -

Implemented parts of the IPsec Specification

- -

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.

- -

In Linux FreeS/WAN

- -

Things we do, as of version 1.96:

- - -

All combinations of implemented transforms are supported. Note that some -form of packet-level authentication is required whenever encryption -is used. Without it, the encryption will not be secure.

- -

Deliberately omitted

-We do not implement everything in the RFCs because some of those things are -insecure. See our discussions of avoiding bogus -security. - -

Things we deliberately omit which are required in the RFCs are:

- - -

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.

- -

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.

- -

We also do not implement some optional features allowed by the RFCs:

- - -

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.

- -

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.

- -

Not (yet) in Linux FreeS/WAN

- -

Things we don't yet do, as of version 1.96:

- - -

Our PF-Key implementation

- -

We use PF-key Version Two for communication between the KLIPS kernel code -and the Pluto Daemon. PF-Key v2 is defined by RFC 2367.

- -

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.

- -

PF-Key portability

- -

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 Photuris key -management over IKE.

- -

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.

- -

Kernels other than the latest 2.2.x and 2.4.y

- -

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.

- -

2.0.x kernels

- -

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.

- -

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.

- -

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.

- -

2.2 and 2.4 kernels

-
-
FreeS/WAN 1.0
-
ran only on 2.0 kernels
-
FreeS/WAN 1.1 to 1.8
-
ran on 2.0 or 2.2 kernels
- ran on some development kernels, 2.3 or 2.4-test
-
FreeS/WAN 1.9 to 1.96
-
runs on 2.0, 2.2 or 2.4 kernels
-
- -

In general, we suggest the latest 2.2 kernel or 2.4 for production -use.

- -

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 FAQ for -discussion.

- -

Intel Linux distributions other than Redhat

- -

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.

- -

Redhat 7.0

- -

There are some problems with FreeS/WAN on Redhat 7.0. They are soluble, -but we recommend you upgrade to a later Redhat instead..

- -

Redhat 7 ships with two compilers.

- - -

Kernel Makefiles have gcc as a default, and must be adjusted to -use kgcc before a kernel will compile on 7.0. This mailing list -message gives details:

-
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.
- -

Check the mailing list archive for more recent -news.

- -

SuSE Linux

- -

SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN -included.

- -

FreeS/WAN packages distributed for SuSE 7.0-7.2 were somehow -miscompiled. You can find fixed packages on - -Kurt Garloff's page.

- -

Here are some notes for an earlier SuSE version.

- -

SuSE Linux 5.3

-
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)....
- -

You may also need to fiddle initialisation scripts to ensure that -/var/run/pluto.pid is removed when rebooting. If this file is -present, Pluto does not come up correctly.

- -

Slackware

-
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.
- -

A year or so later:

-
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.
- -

Debian

- -

A recent (Nov 2001) mailing list points to a web page on setting up -several types of tunnel, including IPsec, on Debian.

- -

Some older information:

-
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.
- -

The scripts in question have been modified since this was posted. Awk -versions should no longer be a problem.

- -

Caldera

-
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
- -

CPUs other than Intel

- -

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 mailing list.

- -

Corel Netwinder (StrongARM CPU)

-
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. . . .
- -

These diffs are in the 0.92 and later distributions, so these should work -out-of-the-box on Netwinder.

- -

Yellow Dog Linux on Power PC

-
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).
-And a later message on the same topic: -
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.
- -

FreeS/WAN no longer includes GMP source.

- -

Mklinux

- -

One user reports success on the Mach-based -microkernel Linux.

-
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.
- -

Alpha 64-bit processors

-
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.
- -

In general (there have been some glitches), FreeS/WAN has been running on -Alphas since then.

- -

Sun SPARC processors

- -

Several users have reported success with FreeS/WAN on SPARC Linux. Here is -one mailing list message:

-
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.
- -

This message, from a different mailing list, may be relevant for anyone -working with FreeS/WAN on Suns:

-
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.
- -

MIPS processors

- -

We know FreeS/WAN runs on at least some MIPS processors because Lasat manufacture an IPsec box based on an -embedded MIPS running Linux with FreeS/WAN. We have no details.

- -

Transmeta Crusoe

- -

The Merilus Firecard, a Linux -firewall on a PCI card, is based on a Crusoe processor and supports -FreeS/WAN.

- -

Motorola Coldfire

-
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.
- -

Multiprocessor machines

- -

FreeS/WAN is designed to work on SMP (symmetric multi-processing) Linux -machines and is regularly tested on dual processor x86 machines.

- -

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 mailing list.

- -

The current design does not make particularly efficient use of -multiprocessor machines; some of the kernel work is single-threaded.

- -

Support for crypto hardware

- -

Supporting hardware cryptography accelerators has not been a high priority -for the development team because it raises a number of fairly complex -issues:

- - -

That said, we have a report 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 web page for some of the -design discussion.

- -

More recently, a patch to support some hardware accelerators has been -posted:

-
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
- -

Hardware accelerators could take performance well beyond what FreeS/WAN -can do in software (discussed here). Here is -some discussion off the IETF IPsec list, October 2001:

-
 ... 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.
- -

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.

- -

IP version 6 (IPng)

- -

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.

- -

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.

- -

There is a Linux implementation of IPv6 in Linux kernels 2.2 and above. -For details, see the FAQ. It -does not yet support IPsec. The USAGI project are also working on IPv6 -for Linux.

- -

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 available. For -more recent information, check the mailing list.

- -

IPv6 background

- -

IPv6 has been specified by an IETF working -group. The group's page lists over 30 RFCs to date, and many Internet -Drafts as well. The overview is RFC 2460. Major features -include:

- - -

A number of projects are working on IPv6 implementation. A prominent Open -Source effort is KAME, 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:

- - -

The 6bone (IPv6 backbone) testbed -network has been up for some time. There is an active IPv6 user group.

- -

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. -...

- -

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 NTT -and Nokia. 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.

- - -- cgit v1.2.3