freeswan/doc/compat.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <HTML>
   3 <HEAD>
   4 <TITLE> Introduction to FreeS/WAN</TITLE>
   5 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   6 </HEAD>
   7 <BODY>
   8 <A HREF="toc.html">Contents</a>
   9 <A HREF="roadmap.html">Previous</a>
  10 <A HREF="interop.html">Next</a>
  11 <HR>
  12 <H1><A name="compat">Linux FreeS/WAN Compatibility Guide</A></H1>
  13 <P> Most of this document is quoted directly from the Linux FreeS/WAN <A href="mail.html">
  14 mailing list</A>. Thanks very much to the community of  testers,
  15 patchers and commenters there, especially the ones quoted below but
  16  also various contributors we haven't quoted.</P>
  17 <H2><A name="spec">Implemented parts of the IPSEC Specification</A></H2>
  18 <P> In general, do not expect Linux FreeS/WAN to do everything yet.
  19 This is a work-in-progress and some parts of the IPSEC specification
  20 are not yet implemented.</P>
  21 <H3><A name="in">In Linux FreeS/WAN</A></H3>
  22 <P> Things we do, as of version 1.9:</P>
  23 <UL>
  24 <LI>key management methods
  25 <DL>
  26 <DT>manually keyed</DT>
  27 <DD>using keys stored in /etc/ipsec.conf</DD>
  28 <DT>automatically keyed</DT>
  29 <DD>Automatically negotiating session keys as required. All
  30  connections are automatically re-keyed periodically. The <A href="glossary.html#Pluto">
  31  Pluto</A> daemon implements this  using the <A href="glossary.html#IKE">
  32 IKE</A> protocol.</DD>
  33 </DL>
  34 </LI>
  35 <LI>Methods of authenticating gateways for IKE
  36 <DL>
  37 <DT>shared secrets</DT>
  38 <DD>stored in /etc/ipsec.secrets</DD>
  39 <DT>RSA signatures</DT>
  40 <DD>This was new code in 1.3. For details, see pluto(8).</DD>
  41 <DT>looking up RSA authentication keys from <A href="glossary.html#DNS">
  42 DNS</A>.</DT>
  43 <DD>This was new code in 1.4, and is not yet heavily tested. Note  that
  44 this technique cannot be fully secure until <A href="glossary.html#SDNS">
  45 secure DNS</A> is widely deployed.</DD>
  46 </DL>
  47 </LI>
  48 <LI>groups for Diffie-Hellman key negotiation
  49 <DL>
  50 <DT>group 2, modp 1024-bit</DT>
  51 <DT>group 5, modp 1536-bit</DT>
  52 <DD>We implement these two groups. </DD>
  53 <P> In negotiating a keying connection (ISAKMP SA, Phase 1) we propose
  54 both  groups when we are the initiator, and accept either when a peer
  55 proposes  them. Once the keying connection is made, we propose only the
  56 alternative  agreed there for data  connections (IPSEC SA's, Phase 2)
  57 negotiated over that keying connection.</P>
  58 </DL>
  59 </LI>
  60 <LI>encryption transforms
  61 <DL>
  62 <DT><A href="glossary.html#DES">DES</A></DT>
  63 <DD>DES is in the source code since it is needed to implement  3DES,
  64 but single DES is not made available to users because <A href="politics.html#desnotsecure">
  65 DES is insecure</A>.</DD>
  66 <DT><A href="glossary.html#3DES">Triple DES</A></DT>
  67 <DD>implemented, and used as the default encryption in Linux  FreeS/WAN.</DD>
  68 </DL>
  69 </LI>
  70 <LI>authentication transforms
  71 <DL>
  72 <DT>keyed <A href="glossary.html#MD5">MD5</A></DT>
  73 <DD>implemented, may be used in IKE or by by AH or ESP  transforms.</DD>
  74 <DT>keyed <A href="glossary.html#SHA">SHA</A></DT>
  75 <DD>implemented, may be used in IKE or by AH or ESP transforms.</DD>
  76 </DL>
  77 </LI>
  78 <P> In negotiations, we propose both of these and accept either. </P>
  79 <LI>compression transforms
  80 <DL>
  81 <DT>IPComp</DT>
  82 <DD>IPComp as described in RFC 2393 has been added for FreeS/WAN 1.6.
  83  It is disabled in the default FreeS/WAN kernel configuration because
  84 it  is new code, not yet fully trusted. Note that Pluto becomes
  85 confused if  you ask it to do IPComp when the kernel cannot. </DD>
  86 <P> Some difficulties in interopreation are anticipated with this. The
  87 RFC  says to leave out some things which many compression libraries put
  88 in.  We do leave these out, but other implementations may not. </P>
  89 </DL>
  90 </LI>
  91 </UL>
  92 <P> All combinations of implemented transforms are supported. Note that
  93 some form of packet-level <STRONG>authentication is required whenever
  94 encryption is used</STRONG>. Without it, the encryption will not be
  95 secure.</P>
  96 <H3><A name="dropped">Deliberately ommitted</A></H3>
  97  We do not implement everything in the RFCs because some of those
  98 things are insecure. See our discussions of avoiding <A href="politics.html#weak">
  99 bogus security</A>.
 100 <P>
 101 <P> Things we deliberately omit which are required in the RFCs are:</P>
 102 <UL>
 103 <LI>null encryption (to use ESP as an authentication-only service) </LI>
 104 <LI>single DES </LI>
 105 <LI>DH group 1, a 768-bit modp group </LI>
 106 </UL>
 107 <P> Since these are the only encryption algorithms and DH group the
 108 RFCs require, it is possible in theory to have a standards-conforming
 109 implementation which will not interpoperate with FreeS/WAN. Such an
 110 implementation would be inherently insecure, so we do not consider this
 111 a problem. Anyway, most implementations sensibly include more secure
 112 options as well, so dropping null encryption, single DES and Group 1
 113 does not greatly hinder interoperation in practice.</P>
 114 <P> We also do not implement some optional features allowed by the
 115 RFCs: </P>
 116 <UL>
 117 <LI>aggressive mode for negotiation of the keying channel or ISAKMP SA.
 118 This mode is a little faster than main mode, but exposes more
 119 information to an eavesdropper. </LI>
 120 </UL>
 121 <P> In theory, this should cause no interoperation problems since all
 122 implementations are required to support the more secure main mode,
 123 whether or not they also allow aggressive mode. </P>
 124 <P> In practice, it does sometimes produce problems with
 125 implementations such as Windows 2000 where aggressive mode is the
 126 default. Typically, these are easily solved with a configuration change
 127 that overrides that default.</P>
 128 <H3><A name="not">Not (yet) in Linux FreeS/WAN</A></H3>
 129 <P> Things we don't yet do, as of version 1.91:</P>
 130 <UL>
 131 <LI>key management methods
 132 <UL>
 133 <LI>authenticate key negotiations via local <A href="glossary.html#PKI">
 134 PKI</A> server, but see links to user <A href="web.html#patch">patches</A>
 135 </LI>
 136 <LI>authenticate key negotiations via <A href="glossary.html#SDNS">
 137 secure  DNS</A></LI>
 138 <LI>unauthenticated key management, using <A href="glossary.html#DH">
 139 Diffie-Hellman</A> key agreement protocol without  authentication.
 140 Arguably, this would be worth doing since it is  secure against all
 141 passive attacks. On the other hand, it is  vulnerable to an active <A href="glossary.html#middle">
 142 man-in-the-middle  attack</A>.</LI>
 143 <LI>opportunistic IPSEC tunnel creation, in which any two IPSEC aware
 144  machines can automatically try to negotiate encryption for any
 145  communication, subject of course to their local policies. This is a
 146  long-term goal of the Linux FreeS/WAN project, but it requires at
 147  least one of:
 148 <UL>
 149 <LI>a nearly universal PKI</LI>
 150 <LI>widespread use of secure DNS</LI>
 151 <LI>a decision to take the risks of unauthenticated keying</LI>
 152 </UL>
 153  None of these are in place yet. </LI>
 154 <P>We expect eventually to do it using DNS. The newer versions of <A href="glossary.html#BIND">
 155 BIND</A> provide much of what we need but they are not  yet widespread
 156 and our code to communicate with them is not  ready.</P>
 157 <P><STRONG> Update:</STRONG> As of 1.91, we have beta-testable code for
 158 opportunistic encryption. See our <A href="config.html#oppex">
 159 configuration document</A>. </P>
 160 </UL>
 161 </LI>
 162 </UL>
 163 <LI>encryption transforms </LI>
 164 <P>Currently <A href="glossary.html#3DES">Triple DES</A> is the only
 165 encryption  method Pluto will negotiate.</P>
 166 <P>No additional encryption transforms are yet implemented, though the
 167  RFCs allow them and some other IPSEC implementations support various
 168 of  them. We are not eager to add more, since they complicate both our
 169 work  and that of the gateway administrator without any obvious
 170 security  improvement. We would certainly not want to incorporate any
 171  cryptographic method that had inadequate key length or had not been
 172  sujected to intensive review over some time.</P>
 173 <P>Rjindael, which just won the <A href="glossary.html#AES">AES</A>
 174  competition to  choose a successor to the DES standard, is an
 175 excellent candidate  for inclusion in FreeS/WAN. This might be a good
 176 project for a  volunteer.</P>
 177 <LI>authentication transforms </LI>
 178 <P>No optional additional authentication transforms are currently
 179  implemented and we do not forsee a need to add any soon.</P>
 180 <LI>Policy checking on decrypted packets </LI>
 181 <P> To fully comply with the RFCs, it is not enough just to accept only
 182 packets  which survive any firewall rules in place to limit what IPSEC
 183 packets get in,  and then pass KLIPS authentication. That is what
 184 FreeS/WAN currently does. </P>
 185 <P> We should also apply additional tests, for example ensuring that
 186 all packets  emerging from a particular tunnel have sourcen and
 187 destination addresses that  fall within the subnets defined for that
 188 tunnel, and that packets with those  addresses that did not emerge from
 189 the appropriate tunnel are disallowed. </P>
 190 <P> This will be done as part of the KLIPS rewrite currently in
 191 progress. See  these <A href="intro.html#applied">links</A> and the <A href="mail.html">
 192  design mailing list</A> for discussion. </P>
 193 <H2><A name="pfkey">Our PF-Key implementation</A></H2>
 194 <P>We use PF-key Version Two for communication between the KLIPS kernel
 195 code  and the Pluto Daemon. PF-Key v2 is defined by <A href="http://www.normos.org/ietf/rfc/rfc2367.txt">
 196  RFC 2367</A>. </P>
 197 <P>The &quot;PF&quot; stands for Protocol Family. PF-Inet defines a
 198 kernel/userspace  interface for the TCP/IP Internet protocols (TCP/IP),
 199 and other members of  the PF series handle Netware, Appletalk, etc.
 200 PF-Key is just a PF for  key-related matters.</P>
 201 <P>Our PF-Key implementation is not yet (mid-July 2000) complete. In
 202  particular, it is mostly one-way, used for Pluto to talk to KLIPS but
 203 not  yet doing much upward communication from kernel to user space.
 204 This will  change, but is not at the top of our priority list.</P>
 205 <H3><A name="pfk.port">PF-Key portability</A></H3>
 206 <P> PF-Key came out of Berkeley Unix work and is used in the various
 207 BSD IPSEC implementations, and in Solaris. This means there is some
 208 hope of porting our Pluto(8) to one of the BSD distributions, or of
 209 running their photurisd(8) on Linux if you prefer <A href="glossary.html#photuris">
 210 Photuris</A> key management over IKE.</P>
 211 <P> It is, however, more complex than that. The PK-Key RFC deliberately
 212 deals only with keying, not policy management. The three PF-Key
 213 implementations we have looked at -- ours, OpenBSD and KAME -- all have
 214 extensions to deal with security policy, and the extensions are
 215 different. There have been discussions aimed at sorting out the
 216 differences, perhaps for a version three PF-Key spec. All players are
 217 in favour of this, but everyone involved is busy and it is not clear
 218 whether or when these discussions might bear fruit.</P>
 219 <H2><A name="otherk">Kernels other than 2.0.38 and 2.2.18</A></H2>
 220 <P> We develop and test on:</P>
 221 <UL>
 222 <LI>Redhat 6.1 with a 2.2.19 kernel.</LI>
 223 <LI>Redhat 7.1 with a 2.4.4 kernel.</LI>
 224 </UL>
 225 <P> This is what we recommend. </P>
 226 <H3><A name="kernel.2.0">Other 2.0.x Intel Kernels</A></H3>
 227 <P> Consider upgrading to the 2.2 kernel series. If you want to stay
 228 with the 2.0 series, then we strongly recommend 2.0.39. Some useful
 229 security patches were added in 2.0.38.</P>
 230 <P> Various versions of the code have run at various times on most
 231 2.0.xx kernels, but the current version is only lightly tested on
 232 2.0.39, and not at all on older kernels. </P>
 233 <P> Some of our patches for older kernels are shipped in 2.0.37 and
 234 later, so they are no longer provided in FreeS/WAN. This means recent
 235 versions of FreeS/WAN will probably not compile om anything earlier
 236 than 2.0.37.</P>
 237 <H3><A name="kernel.production">2.2 and 2.4 Kernels</A></H3>
 238 <DL>
 239 <DT>FreeS/WAN 1.0</DT>
 240 <DD>ran only on 2.0 kernels</DD>
 241 <DT>FreeS/WAN 1.1 to 1.8</DT>
 242 <DD>ran on 2.0 or 2.2 kernels
 243 <BR> ran on some development kernels, 2.3 or 2.4-test</DD>
 244 <DT>FreeS/WAN 1.9</DT>
 245 <DD>runs on 2.0, 2.2 or 2.4 kernels</DD>
 246 </DL>
 247 <P> In general, <STRONG>we suggest the latest 2.2 kernel or 2.4 for
 248 production use</STRONG>. At time of writing (early June 2001, just
 249 before our 1.91 release) these are 2.2.19 and 2.4.5. </P>
 250 <P> Of course no release can be guaranteed to run on kernels more
 251 recent than it is, so quite often there will be no stable FreeS/WAN for
 252 the absolute latest kernel. See the <A href="faq.html#k.versions">FAQ</A>
 253  for discussion. </P>
 254 <H2><A name="otherdist">Intel Linux distributions other than Redhat</A></H2>
 255 <P> We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat
 256 7.1 for 2.4, so minor changes may be required for other distributions.</P>
 257 <H3><A name="rh7">Redhat 7.0</A></H3>
 258 <P> There are some problems with FreeS/WAN on Redhat 7.0, but they are
 259 soluble. </P>
 260 <P> Redhat 7 ships with two compilers. </P>
 261 <UL>
 262 <LI>Their <VAR>gcc</VAR> is version 2.96. Various people, including the
 263 GNU compiler developers and Linus, have said fairly emphatically that
 264 using this was a mistake. 2.96 is a development version, not intended
 265 for production use. In particular, it will not compile a Linux kernel. </LI>
 266 <LI> Redhat therefore also ship a separate compiler, which they call <VAR>
 267 kgcc</VAR>, for compiling kernels. </LI>
 268 </UL>
 269 <P> Kernel Makefiles have <VAR>gcc</VAR> as a default, and must be
 270 adjusted to use <VAR>kgcc</VAR> before a kernel will compile on 7.0.
 271 This mailing list message gives details: </P>
 272 <PRE>
 273 Subject: Re: AW: Installing IPSEC on Redhat 7.0
 274    Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST)
 275   From: Mads Rasmussen &lt;mads@cit.com.br&gt;
 276
 277 &gt; From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1
 278
 279 cd to /usr/src/linux and open the Makefile in your favorite editor. You
 280 will need to look for a line similar to this:
 281
 282 CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
 283
 284
 285 This line specifies which C compiler to use to build the kernel. It should
 286 be changed to:
 287
 288 CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
 289
 290 for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can
 291 proceed with the typical compiling steps.
 292 </PRE>
 293  Check the <A href="mail.html">mailing list</A> archive for more recent
 294 news.
 295 <H3><A name="suse">SuSE Linux</A></H3>
 296 <P> SuSE 6.3 and later versions, at least in Europe, ship with
 297 FreeS/WAN included.</P>
 298 <P>Here are some notes for an earlier SuSE version.</P>
 299 <H4>SuSE Linux 5.3</H4>
 300 <PRE>Date: Mon, 30 Nov 1998
 301 From: Peter Onion &lt;ponion@srd.bt.co.uk&gt;
 302
 303 ... I got Saturdays snapshot working between my two SUSE5.3 machines at home.
 304
 305 The mods to the install process are quite simple.  From memory and looking at
 306 the files on the SUSE53 machine here at work....
 307
 308 And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
 309 which SUSE use to shut a service down.
 310
 311 A few mods in /etc/init.d/ipsec  to cope with the different places that SUSE
 312 put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
 313 /etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.
 314
 315 insert &quot;. /etc/rc.config&quot; to pick up the SUSE config info and use
 316
 317   if test -n &quot;$NETCONFIG&quot; -a &quot;$NETCONFIG&quot; != &quot;YAST_ASK&quot; ; then
 318
 319 to replace
 320
 321   [ ${NETWORKING} = &quot;no&quot; ] amp; exit 0
 322
 323 Create /etc/sysconfig  as SUSE doesn't have one.
 324
 325 I think that was all (but I prob forgot something)....</PRE>
 326 <P>You may also need to fiddle initialisation scripts to ensure that
 327  /var/run/pluto.pid is removed when rebooting. If this file is present,
 328 Pluto  does not come up correctly.</P>
 329 <H3><A name="slack">Slackware</A></H3>
 330 <PRE>
 331 Subject: Re: linux-ipsec: Slackware distribution
 332   Date:  Thu, 15 Apr 1999 12:07:01 -0700
 333   From:  Evan Brewer &lt;dmessiah@silcon.com&gt;
 334
 335 &gt; Very shortly, I will be needing to install ipsec on at least gateways that
 336 &gt; are running Slackware. . . .
 337
 338 The only trick to getting it up is that on the slackware dist there is no
 339 init.d directory in /etc/rc.d .. so create one.  Then, what I do is take the
 340 ipsec startup script which normally gets put into the init.d directory, and
 341 put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
 342 in init.d.  The only file in the dist you need to really edit is the
 343 utils/Makefile, setup4:
 344
 345 Everything else should be just fine.
 346 </PRE>
 347  A year or so later:
 348 <PRE>
 349 Subject: Re: HTML Docs- Need some cleanup?
 350    Date: Mon, 8 Jan 2001
 351    From: Jody McIntyre &lt;jodym@oeone.com&gt;
 352
 353 I have successfully installed FreeS/WAN on several Slackware 7.1 machines.
 354 FreeS/WAN installed its rc.ipsec file in /etc/rc.d.  I had to manually call
 355 this script from rc.inet2.  This seems to be an easier method than Evan
 356 Brewer's.
 357 </PRE>
 358 <H3><A name="deb">Debian</A></H3>
 359 <PRE>Subject: FreeS/WAN 1.0 on Debian 2.1
 360    Date: Tue, 20 Apr 1999
 361   From:  Tim Miller &lt;cerebus+counterpane@haybaler.sackheads.org&gt;
 362
 363         Compiled and installed without error on a Debian 2.1 system
 364 with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
 365 /etc/init.d.
 366
 367         /var/lock/subsys/ doesn't exist on Debian boxen, needs to be
 368 created; not a fatal error.
 369
 370         Finally, ipsec scripts appear to be dependant on GNU awk
 371 (gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
 372 With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
 373 operation appears flawless.</PRE>
 374 <P> The scripts in question have been modified since this was posted.
 375 Awk versions should no longer be a problem.</P>
 376 <H3><A name="caldera">Caldera</A></H3>
 377 <PRE>
 378 Subject: Re: HTML Docs- Need some cleanup?
 379    Date: Mon, 08 Jan 2001
 380    From: Andy Bradford &lt;andyb@calderasystems.com&gt;
 381
 382 On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote:
 383
 384 &gt;     Intel Linux distributions other than Redhat 5.x and 6.x
 385 &gt;         Redhat 7.0
 386 &gt;         SuSE Linux
 387 &gt;             SuSE Linux 5.3
 388 &gt;         Slackware
 389 &gt;         Debian
 390
 391 Can you please include Caldera in this list?  I have tested it since
 392 FreeS/Wan 1.1 and it works great with our systems---provided one
 393 follows the FreeS/Wan documentation. :-)
 394
 395 Thank you,
 396 Andy
 397 </PRE>
 398 <H2><A name="CPUs">CPUs other than Intel</A></H2>
 399 <P> FreeS/WAN has been run sucessfully on a number of different CPU
 400 architectures. If you have tried it on one not listed here, please post
 401 to the <A href="mail.html">mailing list</A>.</P>
 402 <H3><A name=" strongarm">Corel Netwinder (StrongARM CPU)</A></H3>
 403 <PRE>Subject: linux-ipsec: Netwinder diffs
 404 Date: Wed, 06 Jan 1999
 405 From: rhatfield@plaintree.com
 406
 407 I had a mistake in my ipsec-auto, so I got things working this morning.
 408
 409 Following are the diffs for my changes.  Probably not the best and cleanest way
 410 of doing it, but it works. . . . </PRE>
 411 <P>These diffs are in the 0.92 distribution and any snapshot after Feb
 412 20  1999, so these should work out-of-the-box on Netwinder.</P>
 413 <H3><A name="yellowdog">Yellow Dog Linux on Power PC</A></H3>
 414 <PRE>Subject:  Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
 415    Date:  11 Dec 1999
 416    From:  Darron Froese &lt;darron@fudgehead.com&gt;
 417
 418 I'm summarizing here for the record - because it's taken me many hours to do
 419 this (multiple times) and because I want to see IPSEC on more linuxes than
 420 just x86.
 421
 422 Also, I can't remember if I actually did summarize it before... ;-) I'm
 423 working too many late hours.
 424
 425 That said - here goes.
 426
 427 1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
 428 &lt;http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2&gt;
 429
 430 2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
 431 &lt;ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz&gt;
 432
 433 3. Get the gmp src rpm from here:
 434 &lt;ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm&gt;
 435
 436 4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
 437
 438 You will see a lot of text fly by and when you start to see the rpm
 439 recompiling like this:
 440
 441 Executing: %build
 442 + umask 022
 443 + cd /usr/src/redhat/BUILD
 444 + cd gmp-2.0.2
 445 + libtoolize --copy --force
 446 Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
 447 You should add the contents of `/usr/share/aclocal/libtool.m4' to
 448 `aclocal.m4'.
 449 + CFLAGS=-O2 -fsigned-char
 450 + ./configure --prefix=/usr
 451
 452 Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
 453 reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
 454 ydl.
 455
 456 cd /usr/src/redhat/BUILD/
 457 cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
 458 cd /usr/src/freeswan-1.1/
 459 rm -rf gmp
 460 mv gmp-2.0.2 gmp
 461
 462 5. Open the freeswan Makefile and change the line that says:
 463 KERNEL=$(b)zimage (or something like that) to
 464 KERNEL=vmlinux
 465
 466 6. cd ../linux/
 467
 468 7. make menuconfig
 469 Select an option or two and then exit - saving your changes.
 470
 471 8. cd ../freeswan-1.1/ ; make menugo
 472
 473 That will start the whole process going - once that's finished compiling,
 474 you have to install your new kernel and reboot.
 475
 476 That should build FreeS/WAN on ydl (I tried it on 1.1).</PRE>
 477  And a later message on the same topic:
 478 <PRE>Subject: Re: FreeS/WAN, PGPnet and E-mail
 479    Date: Sat, 22 Jan 2000
 480    From: Darron Froese &lt;darron@fudgehead.com&gt;
 481
 482 on 1/22/00 6:47 PM, Philip Trauring at philip@trauring.com wrote:
 483
 484 &gt; I have a PowerMac G3 ...
 485
 486 The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
 487 FreeS/WAN 1.2patch1 with a couple minor modifications:
 488
 489 1. In the Makefile it specifies a bzimage for the kernel compile - you have
 490 to change that to vmlinux for the PPC.
 491
 492 2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
 493 compile. I have gotten around this by getting the gmp src rpm from here:
 494
 495 ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
 496
 497 If you rip the source out of there - and place it where the gmp source
 498 resides it will compile just fine.</PRE>
 499 <H3><A name="mklinux">Mklinux</A></H3>
 500 <P>One user reports success on the Mach-based <STRONG> m</STRONG>icro<STRONG>
 501 k</STRONG>ernel Linux.</P>
 502 <PRE>Subject: Smiles on sparc and ppc
 503    Date: Fri, 10 Mar 2000
 504    From: Jake Hill &lt;jah@alien.bt.co.uk&gt;
 505
 506 You may or may not be interested to know that I have successfully built
 507 FreeS/WAN on a number of non intel alpha architectures; namely on ppc
 508 and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
 509 works, mostly, with few changes.</PRE>
 510 <H3><A name="alpha">Alpha 64-bit processors</A></H3>
 511 <PRE>Subject: IT WORKS (again) between intel &amp; alpha :-)))))
 512    Date: Fri, 29 Jan 1999
 513    From: Peter Onion &lt;ponion@srd.bt.co.uk&gt;
 514
 515 Well I'm happy to report that I've got an IPSEC connection between by intel &amp; alpha machines again :-))
 516
 517 If you look back on this list to 7th of December I wrote...
 518
 519 -On 07-Dec-98 Peter Onion wrote:
 520 -&gt;
 521 -&gt; I've about had enuf of wandering around inside the kernel trying to find out
 522 -&gt; just what is corrupting outgoing packets...
 523 -
 524 -Its 7:30 in the evening .....
 525 -
 526 -I FIXED IT  :-))))))))))))))))))))))))))))))))
 527 -
 528 -It was my own fault :-((((((((((((((((((
 529 -
 530 -If you ask me very nicly I'll tell you where I was a little too over keen to
 531 -change unsigned long int __u32 :-)  OPSE ...
 532 -
 533 -So tomorrow it will full steam ahead to produce a set of diffs/patches against
 534 -0.91
 535 -
 536 -Peter Onion.
 537 </PRE>
 538 <P>In general (there have been some glitches), FreeS/WAN has been
 539 running on  Alphas since then.</P>
 540 <H3><A name="SPARC">Sun SPARC processors</A></H3>
 541 <P>Several users have reported success with FreeS/WAN on SPARC Linux.
 542 Here  is one mailing list message:</P>
 543 <PRE>
 544 Subject: Smiles on sparc and ppc
 545    Date: Fri, 10 Mar 2000
 546    From: Jake Hill &lt;jah@alien.bt.co.uk&gt;
 547
 548 You may or may not be interested to know that I have successfully built
 549 FreeS/WAN on a number of non intel alpha architectures; namely on ppc
 550 and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
 551 works, mostly, with few changes.
 552
 553 I have a question, before I make up some patches. I need to hack
 554 gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
 555 trivial, but could I also use a different version of gmp? Is it vanilla
 556 here?
 557
 558 I guess my only real headache is from ipchains, which appears to stop
 559 running when IPSec has been started for a while. This is with 2.2.14 on
 560 sparc.</PRE>
 561 <P> This message, from a different mailing list, may be relevant for
 562 anyone working with FreeS/WAN on Suns:</P>
 563 <PRE>
 564 Subject: UltraSPARC DES assembler
 565    Date: Thu, 13 Apr 2000
 566    From: svolaf@inet.uni2.dk (Svend Olaf Mikkelsen)
 567      To: coderpunks@toad.com
 568
 569 An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
 570 file is available at http://inet.uni2.dk/~svolaf/des.htm.
 571
 572 This brings DES on UltraSPARC from slower than Pentium at the same
 573 clock speed to significantly faster.
 574 </PRE>
 575 <H3><A name="mips">MIPS processors</A></H3>
 576 <P>We know FreeS/WAN runs on at least some MIPS processors because <A href="http://www.lasat.com">
 577 Lasat</A> (who host our freeswan.org web site)  manufacture an IPSEC
 578 box based on an embedded MIPS running Linux with  FreeS/WAN. We have no
 579 details.</P>
 580 <H3><A name="coldfire">Motorola Coldfire</A></H3>
 581 <PRE>
 582 Subject: Re: Crypto hardware support
 583    Date: Mon, 03 Jul 2000
 584    From: Dan DeVault &lt;devault@tampabay.rr.com&gt;
 585
 586 .... I have been running
 587 uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay  (
 588 http://www.moretonbay.com )  and it was using a Coldfire processor
 589 and was able to do the Triple DES encryption at just about
 590 1 mbit / sec rate.......  they put a Hi/Fn 7901 hardware encryption
 591 chip on their board and now their system does over 25 mbit of 3DES
 592 encryption........ pretty significant increase if you ask me.
 593 </PRE>
 594 <H2><A name="multiprocessor">Multiprocessor machines</A></H2>
 595 <P> FreeS/WAN is designed to work on SMP (symmetric multi-processing)
 596 Linux machines and is regularly tested on dual processor x86 machines. </P>
 597 <P> We do not know of any testing on multi-processor machines with
 598 other CPU architectures or with more than two CPUs. Anyone who does
 599 test this, please report results to the <A href="mail.html">mailing list</A>
 600 . </P>
 601 <P> The current design does not make particularly efficient use of
 602 multiprocessor machines; some of the kernel work is single-threaded.
 603 This issue is being addressed in the KLIPS II redesign. </P>
 604 <H2><A name="hardware">Support for crypto hardware</A></H2>
 605 <P> Supporting hardware cryptography accelerators has not been a high
 606 priority for the development team because it raises a number of fairly
 607 complex issues:</P>
 608 <UL>
 609 <LI>Can you trust the hardware? If it is not Open Source, how do you
 610 audit its security? Even if it is, how do you check that the design has
 611 no concealed traps?</LI>
 612 <LI>If an interface is added for such hardware, can that interface be
 613 subverted or misused?</LI>
 614 <LI>Is hardware acceleration actually a performance win? It clearly is
 615 in many cases, but on a fast machine it might be better to use the CPU
 616 for the encryption than to pay the overheads of moving data to and from
 617 a crypto board.</LI>
 618 <LI>the current KLIPS code does not provide a clean interface for
 619 hardware accelerators</LI>
 620 </UL>
 621 <P> That said, we have a <A href="#coldfire">report</A> of FreeS/WAN
 622 working with one crypto accelerator and some work is going on to modify
 623 KLIPS to create a clean generic interface to such products. See this <A href="http://www.jukie.net/~bart/linux-ipsec/">
 624 web page</A> for some of the design discussion. </P>
 625 <H2><A name="ipv6">IP version 6 (IPng)</A></H2>
 626  The Internet currently runs on version four of the IP protocols. IPv4
 627 is what is in the standard Linux IP stack, and what FreeS/WAN was built
 628 for. In IPv4, IPSEC is an optional feature.
 629 <P> The next version of the IP protocol suite is version six, usually
 630 abbreviated either as &quot;IPv6&quot; or as &quot;IPng&quot; for &quot;IP: the next
 631 generation&quot;. For IPv6, IPSEC is a required feature. Any machine doing
 632 IPv6 is required to support IPSEC, much as any machine doing (any
 633 version of) IP is required to support ICMP.</P>
 634 <P> There is a Linux implementation of IPv6 in Linux kernels 2.2 and
 635 above. For details, see the <A href="http://www.cs-ipv6.lancs.ac.uk/ipv6/systems/linux/faq/">
 636 FAQ</A>. It does not yet support IPSEC. The <A href="http://www.linux-ipv6.org/">
 637 USAGI</A> project are also working on IPv6 for Linux.</P>
 638 <P> FreeS/WAN was originally built for the current standard, IPv4, but
 639 we are interested in seeing it work with IPv6. Some progress has been
 640 made, but at time of writing (February 2001), the job is not complete.
 641 For more recent information, check the <A href="mail.html">mailing list</A>
 642 .</P>
 643 <P> The first release of FreeS/WAN (1.8) patched for IPv6 support is
 644 now <A href="http://www.ipv6.iabg.de/downloadframe/index.html">
 645  available</A>. </P>
 646 <H3><A name="v6.back">IPv6 background</A></H3>
 647 <P> IPv6 has been specified by an IETF <A href="http://www.ietf.org/html.charters/ipngwg-charter.html">
 648 working group</A>. The group's page lists over 30 RFCs to date, and
 649 many Internet Drafts as well. The overview is <A href="http://www.ietf.org/rfc/rfc2460.txt">
 650 RFC 2460</A>. Major features include: </P>
 651 <UL>
 652 <LI>expansion of the address space from 32 to 128 bits, </LI>
 653 <LI>changes to improve support for
 654 <UL>
 655 <LI>mobile IP </LI>
 656 <LI>automatic network configuration </LI>
 657 <LI>quality of service routing </LI>
 658 <LI>... </LI>
 659 </UL>
 660 </LI>
 661 <LI>improved security via IPSEC </LI>
 662 </UL>
 663 <P> A number of projects are working on IPv6 implementation. A
 664 prominent Open Source effort is <A href="http://www.kame.net/">KAME</A>
 665 , a collaboration among several large Japanese companies to implement
 666 IPv6 for Berkeley Unix. Other major players are also working on IPv6.
 667 For example, see pages at <A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">
 668 Sun</A>, <A href="http://www.cisco.com/warp/public/732/ipv6/index.html">
 669 Cisco</A> and <A href="http://www.microsoft.com/WINDOWS2000/library/howitworks/communications/networkbasics/IPv6.asp">
 670 Microsoft</A>. The <A href="http://www.6bone.net/">6bone</A> (IPv6
 671 backbone) testbed network has been up for some time. There is an active <A
 672 href="http://www.ipv6.org/">IPv6 user group</A>. </P>
 673 <P> One of the design goals for IPv6 was that it must be possible to
 674 convert from v4 to v6 via a gradual transition process. Imagine the
 675 mess if there were a &quot;flag day&quot; after which the entire Internet used
 676 v6, and all software designed for v4 stopped working. Almost every
 677 computer on the planet would need major software changes! There would
 678 be huge costs to replace older equipment. Implementers would be worked
 679 to death before &quot;the day&quot;, systems administrators and technical support
 680 would be completely swamped after it. The bugs in every implementation
 681 would all bite simultaneously. Large chunks of the net would almost
 682 certainly be down for substantial time periods. ... </P>
 683 <P> Fortunately, the design avoids any &quot;flag day&quot;. It is therefore a
 684 little tricky to tell how quickly IPv6 will take over.  The transition
 685 has certainly begun. For examples, see announcements from <A href="http://www.mailbase.ac.uk/lists/internet2/2000-03/0016.html">
 686 NTT</A> and <A href="http://www.vnunet.com/News/1102383">Nokia</A>.
 687 However, it is not yet clear how quickly the process will gain
 688 momentum, or when it will be completed. Likely large parts of the
 689 Internet will remain with IPv4 for years to come. </P>
 690 <HR>
 691 <A HREF="toc.html">Contents</a>
 692 <A HREF="roadmap.html">Previous</a>
 693 <A HREF="interop.html">Next</a>
 694 </BODY>
 695 </HTML>