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/compat.html | 707 -------------------------------------------------------- 1 file changed, 707 deletions(-) delete mode 100644 doc/compat.html (limited to 'doc/compat.html') diff --git a/doc/compat.html b/doc/compat.html deleted file mode 100644 index f01efa64c..000000000 --- a/doc/compat.html +++ /dev/null @@ -1,707 +0,0 @@ - - - -Introduction to FreeS/WAN - - - - -Contents -Previous -Next -
-

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

-
-Contents -Previous -Next - - -- cgit v1.2.3