freeswan/doc/intro.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="install.html">Next</a>
  10 <HR>
  11 <H1><A name="intro">Introduction</A></H1>
  12 <P>This section gives an overview of:</P>
  13 <UL>
  14 <LI>what IP Security (IPSEC) does</LI>
  15 <LI>how IPSEC works</LI>
  16 <LI>why we are implementing it for Linux</LI>
  17 <LI>how this implementation works</LI>
  18 </UL>
  19 <P> This section is intended to cover only the essentials, <EM>things
  20 you should know before trying to use FreeS/WAN.</EM></P>
  21 <P> For more detailed background information, see the <A href="politics.html">
  22 history and politics</A> and <A href="ipsec.html">IPSEC protocols</A>
  23  sections.</P>
  24 <H2><A name="ipsec.intro">IPSEC, Security for the Internet Protocol</A></H2>
  25 <P> FreeS/WAN is a Linux implementation of the IPSEC (IP security)
  26 protocols. IPSEC provides encryption and authentication services at the
  27 IP (Internet Protocol) level of the network protocol stack. </P>
  28 <P> Working at this level, IPSEC can protect any traffic carried over
  29 IP, unlike other encryption which generally protects only a particular
  30 higher-level protocol -- <A href="glossary.html#PGP">PGP</A> for mail, <A
  31 href="glossary.html#SSH">SSH</A> for remote login, <A href="glossary.html#SSL">
  32 SSL</A> for web work, and so on. This has both advantages and
  33 disadvantages, discussed in our <A href="ipsec.html#others">IPSEC
  34 section</A></P>
  35 <P> IPSEC can be used on any machine which does IP networking.
  36 Dedicated IPSEC gateway machines can be installed wherever required to
  37 protect traffic. IPSEC can also run on routers, on firewall machines,
  38 on various application servers, and on end-user desktop or laptop
  39 machines. </P>
  40 <P> Three protocols are used</P>
  41 <UL>
  42 <LI><A href="glossary.html#AH">AH</A> (Authentication Header) provides
  43 a packet-level authentication service</LI>
  44 <LI><A href="glossary.html#ESP">ESP</A> (Encapsulating Security
  45 Payload) provides encryption plus authentication</LI>
  46 <LI><A href="glossary.html#IKE">IKE</A> (Internet Key Exchange)
  47 negotiates connection parameters, including  keys, for the other two</LI>
  48 </UL>
  49 <P> Our implementation has three main parts:</P>
  50 <UL>
  51 <LI><A href="glossary.html#KLIPS">KLIPS</A> (kernel IPSEC) implements
  52 AH, ESP, and packet handling within the  kernel</LI>
  53 <LI><A href="glossary.html#Pluto">Pluto</A> (an IKE daemon) implements
  54 IKE, negotiating connections with other  systems</LI>
  55 <LI>various scripts provide an adminstrator's interface to the
  56  machinery</LI>
  57 </UL>
  58 <P> IPSEC is optional for the current (version 4) Internet Protocol.
  59 FreeS/WAN adds IPSEC to the Linux IPv4 network stack. Implementations
  60 of <A href="glossary.html#ipv6.gloss">IP version 6</A> are required to
  61 include IPSEC. Work toward integrating FreeS/WAN into the Linux IPv6
  62 stack has <A href="compat.html#ipv6">started</A>.</P>
  63 <P>For more information on IPSEC, see our <A href="ipsec.html">IPSEC
  64 protocols</A> section, our collection of <A href="web.html#ipsec.link">
  65 IPSEC links</A> or the <A href="rfc.html">RFCs</A> which are the
  66 official definitions of these protocols.</P>
  67 <H3><A name="intro.interop">Interoperating with other IPSEC
  68 implementations</A></H3>
  69 <P>IPSEC is designed to let different implementations work together. We
  70 provide:</P>
  71 <UL>
  72 <LI>a <A href="web.html#implement">list</A> of some other
  73 implementations</LI>
  74 <LI>information on <A href="interop.html">using FreeS/WAN with other
  75  implementations</A></LI>
  76 </UL>
  77 <P> The VPN Consortium fosters cooperation among implementers and
  78 interoperability among implementations. Their <A href="http://www.vpnc.org/">
  79 web site</A> has much more information. </P>
  80 <H3><A name="applications">Applications of IPSEC</A></H3>
  81 <P> Because IPSEC operates at the network layer, it is remarkably
  82 flexible and can be used to secure nearly any type of Internet traffic.
  83 Two applications, however, are extremely widespread:</P>
  84 <UL>
  85 <LI>a <A href="glossary.html#VPN">Virtual Private Network</A>, or VPN,
  86 allows multiple  sites to communicate securely over an insecure
  87 Internet by encrypting all  communication between the sites.</LI>
  88 <LI>&quot;Road Warriors&quot; connect to the office from home, or perhaps from a
  89 hotel  somewhere</LI>
  90 </UL>
  91 <P> There is enough opportunity in these applications that vendors are
  92 flocking to them. IPSEC is being built into routers, into firewall
  93 products, and into major operating systems, primarily to support these
  94 applications. See our <A href="web.html#implement">list</A> of
  95 implementations for details. </P>
  96 <P> We support both of those applications, and various less common
  97 IPSEC applications as well, but we also add one of our own:</P>
  98 <UL>
  99 <LI>opportunistic encryption, the ability to set up FreeS/WAN gateways
 100 so  that any two of them can encrypt to each other, and will do so
 101 whenever  packets pass between them.</LI>
 102 </UL>
 103 <P>This is an extension we are adding to the protocols. FreeS/WAN is
 104 the first prototype implementation, though we hope other IPSEC
 105 implementations will adopt the technique once we demonstrate it. See <A href="#goals">
 106 project goals</A> below for why we think this is important.</P>
 107 <P>A somewhat more detailed description of each of these applications
 108 is below. Our <A href="config.html">setup</A> section will show you how
 109 to build each of them.</P>
 110 <H4><A name="makeVPN">Using secure tunnels to create a VPN</A></H4>
 111 <P> A VPN, or <STRONG>V</STRONG>irtual <STRONG>P</STRONG>rivate <STRONG>
 112 N</STRONG>etwork lets two networks communicate securely when the only
 113 connection between them is over a third network which they do not trust.</P>
 114 <P>The method is to put a security gateway machine between each of the
 115 communicating networks and the untrusted network. The gateway machines
 116 encrypt packets entering the untrusted net and decrypt packets leaving
 117 it, creating a secure tunnel through it.</P>
 118 <P>If the cryptography is strong, the implementation is careful, and
 119 the administration of the gateways is competent, then one can
 120 reasonably trust the security of the tunnel. The two networks then
 121 behave like a single large private network, some of whose links are
 122 encrypted tunnels through untrusted nets.</P>
 123 <P>Actual VPNs are often more complex. One organisation may have fifty
 124 branch offices, plus some suppliers and clients, with whom it needs to
 125 communicate securely. Another might have 5,000 stores, or 50,000
 126 point-of-sale devices. The untrusted network need not be the Internet.
 127 All the same issues arise on a corporate or institutional network
 128 whenever two departments want to communicate privately with each other.</P>
 129 <P>Administratively, the nice thing about many VPN setups is that large
 130 parts of them are static. You know the IP addresses of most of the
 131 machines involved. More important, you know they will not change on
 132 you. This simplifies some of the admin work. For cases where the
 133 addresses do change, see the next section.</P>
 134 <H4><A name="road.intro">Road Warriors</A></H4>
 135 <P> The prototypical &quot;Road Warrior&quot; is a traveller connecting to home
 136 base from a laptop machine. Administratively, most of the same problems
 137 arise for a telecommuter connecting from home to the office, especially
 138 if the telecommuter does not have a static IP address.</P>
 139 <P>For purposes of this document:</P>
 140 <UL>
 141 <LI>anyone with a dynamic IP address is a &quot;Road Warrior&quot;.</LI>
 142 <LI>any machine doing IPSEC processing is a &quot;gateway&quot;. Think of the
 143  single-user road warrior machine as a gateway with a degenerate subnet
 144  (one machine, itself) behind it.</LI>
 145 </UL>
 146 <P> These require somewhat different setup than VPN gateways with
 147 static addresses and with client systems behind them, but are basically
 148 not problematic.</P>
 149 <P> There are some difficulties which appear for some road warrior
 150 connections:</P>
 151 <UL>
 152 <LI>Road Wariors who get their addresses via DHCP may have a problem.
 153  FreeS/WAN can quite happily build and use a tunnel to such an address,
 154 but  when the DHCP lease expires, FreeS/WAN does not know that. The
 155 tunnel  fails, and the only recovery method is to tear it down and
 156 re-build  it.</LI>
 157 <LI>If Network Address Translation (NAT) is applied between the two
 158 IPSEC  Gateways, this breaks IPSEC. IPSEC authenticates packets on an
 159 end-to-end  basis, to ensure they are not altered en route. NAT
 160 rewrites packets as  they go by. See our <A href="firewall.html#NAT">
 161 firewalls</A> document for details.</LI>
 162 </UL>
 163 <P> In most situations, however, FreeS/WAN supports road warrior
 164 connections just fine.</P>
 165 <H4><A name="opp.intro">Opportunistic encryption</A></H4>
 166 <P> One of the reasons we are working on FreeS/WAN is that it gives us
 167 the opportunity to add what we call opportuntistic encryption. This
 168 means that any two FreeS/WAN gateways will be able to encrypt their
 169 traffic, <EM>even if the two gateway administrators have had no prior
 170 contact and neither system has any preset information about the other</EM>
 171 .  We hope this will go some distance toward creating a secure
 172 Internet, an environment where message privacy is the default. See our <A
 173 href="politics.html">history and politics of cryptography</A> section
 174 for discussion.</P>
 175 <P> Both systems pick up the authentication information they need from
 176 the <A href="glossary.html#DNS.gloss">DNS</A> (domain name service),
 177 the service they already use to look up IP addresses. Of course the
 178 administrators must put that information in the DNS, and must set up
 179 their gateways with opportunistic encryption enabled.  Once that is
 180 done, everything is automatic. The gateways look for opportunities to
 181 encrypt, and encrypt whatever they can. Whether they also accept
 182 unencrypted communication is a policy decision the administrator can
 183 make.</P>
 184 <P> A draft document giving most of the details of how we plan to
 185 implement this has been posted to the mailing list. See <A href="#applied">
 186 links</A> below.</P>
 187 <P> Only one current product we know of implements a form of
 188 opportunistic encryption. <A href="web.html#ssmail">Secure sendmail</A>
 189  will automatically encrypt server-to-server mail transfers whenever
 190 possible.</P>
 191 <H3><A name="types">The need to authenticate gateways</A></H3>
 192 <P>A complication, which applies to any type of connection -- VPN, Road
 193 Warrior or opportunistic -- is that a secure connection cannot be
 194 created magically. <EM>There must be some mechanism which enables the
 195 gateways to reliably identify each other.</EM> Without this, they
 196 cannot sensibly trust each other and cannot create a genuinely secure
 197 link.</P>
 198 <P>Any link they do create without some form of <A href="glossary.html#authentication">
 199 authentication</A> will be vulnerable to a <A href="glossary.html#middle">
 200 man-in-the-middle attack</A>. If <A href="glossary.html#alicebob">Alice
 201 and Bob</A> are the people creating the connection, a villian who can
 202 re-route or intercept the packets can pose as Alice while talking to
 203 Bob and pose as Bob while talking to Alice. Alice and Bob then both
 204 talk to the man in the middle, thinking they are talking to each other,
 205 and the villain gets everything sent on the bogus &quot;secure&quot; connection.</P>
 206 <P>There are two ways to build links securely, both of which exclude
 207 the man-in-the middle:</P>
 208 <UL>
 209 <LI>with <STRONG>manual keying</STRONG>, Alice and Bob share a secret
 210 key  (which must be transmitted securely, perhaps in a note or via PGP
 211 or SSH)  to encrypt their messages. For FreeS/WAN, such keys are stored
 212 in the <A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A> file. Of
 213 course, if  an enemy gets the key, all is lost.</LI>
 214 <LI>with <STRONG>automatic keying</STRONG>, the two systems
 215 authenticate  each other and negotiate their own secret keys. The keys
 216 are automatically  changed periodically.</LI>
 217 </UL>
 218 <P> Automatic keying is much more secure, since if an enemy gets one
 219 key only messages between the previous re-keying and the next are
 220 exposed. It is therefore the usual mode of operation for most IPSEC
 221 deployment, and the mode we use in our setup examples. FreeS/WAN does
 222 support manual keying for special circumstanes. See this <A href="config.html#prodman">
 223 section</A>. </P>
 224 <P> For automatic keying, the two systems must authenticate each other
 225 during the negotiations. There is a choice of methods for this:</P>
 226 <UL>
 227 <LI>a <STRONG>shared secret</STRONG> provides authentication. If Alice
 228 and  Bob are the only ones who know a secret and Alice recives a
 229 message which  could not have been created without that secret, then
 230 Alice can safely  believe the message came from Bob.</LI>
 231 <LI>a <A href="glossary.html#public">public key</A> can also provide
 232 authentication. If  Alice receives a message signed with Bob's private
 233 key (which of course  only he should know) and she has a trustworthy
 234 copy of his public key (so  that she can verify the signature), then
 235 she can safely believe the  message came from Bob.</LI>
 236 </UL>
 237 <P> Public key techniques are much preferable, for reasons discussed <A href="config.html#choose">
 238 later</A>, and will be used in all our setup examples. FreeS/WAN does
 239 also support auto-keying with shared secret authentication. See this <A href="config.html#prodsecrets">
 240 section</A>.</P>
 241 <H2><A name="project">The FreeS/WAN project</A></H2>
 242 <H3><A name="goals">Project goals</A></H3>
 243 <P> Our overall goal in FreeS/WAN is to make the Internet more secure
 244 and more private.</P>
 245 <P> Our IPSEC implementation supports VPNs and Road Warriors of course.
 246 Those are important applications. Many users will want FreeS/WAN to
 247 build corporate VPNs or to provide secure remote access. </P>
 248 <P> However, our goals in building it go beyond that. We are trying to
 249 help <STRONG>build security into the fabric of the Internet</STRONG> so
 250 that anyone who choses to communicate securely can do so, as easily as
 251 they can do anything else on the net.</P>
 252 <P>More detailed objectives are:</P>
 253 <UL>
 254 <LI>help make IPSEC widespread by providing an implementation with no
 255  restrictions:
 256 <UL>
 257 <LI>freely available in source code under the <A href="glossary.html#GPL">
 258 GNU General  Public License</A></LI>
 259 <LI>running on a range of readily available hardware</LI>
 260 <LI>not subject to US or other nations' <A href="politics.html#exlaw">
 261 export  restrictions</A>.
 262 <BR> Note that in order to avoid <EM>even the appearance</EM> of being
 263  subject to those laws, the project cannot accept software
 264  contributions -- <EM>not even one-line bug fixes</EM> -- from US
 265  residents or citizens.</LI>
 266 </UL>
 267 </LI>
 268 <LI>provide a high-quality IPSEC implementation for Linux
 269 <UL>
 270 <LI>portable to all CPUs Linux supports: <A href="compat.html#CPUs">
 271 (current  list)</A></LI>
 272 <LI>interoperable with other IPSEC implementations: <A href="interop.html">
 273 (current list)</A></LI>
 274 </UL>
 275 </LI>
 276 <LI>extend IPSEC to do <A href="glossary.html#carpediem">opportunistic
 277 encryption</A> so  that
 278 <UL>
 279 <LI>any two systems can secure their communications without a
 280 pre-arranged connection</LI>
 281 <LI>secure connections can be the default, falling back to unencrypted
 282 connections only  if:
 283 <UL>
 284 <LI><EM>both</EM> the partner is not set up to co-operate on securing
 285 the connection </LI>
 286 <LI><EM>and</EM> your policy allows insecure connections </LI>
 287 </UL>
 288 </LI>
 289 <LI>a significant fraction of all Internet traffic is encrypted</LI>
 290 </UL>
 291 </LI>
 292 </UL>
 293 <P> If we can get opportunistic encryption implemented and widely
 294 deployed, then it becomes impossible for even huge well-funded agencies
 295 to monitor the net. </P>
 296 <P> See also our section on <A href="politics.html">history and politics</A>
 297  of cryptography, which includes our project leader's <A href="politics.html#gilmore">
 298 rationale</A> for starting the project.</P>
 299 <H3><A name="staff">Project team</A></H3>
 300  Two of the team are from the US and can therefore contribute no code:
 301 <UL>
 302 <LI>John Gilmore: founder and policy-maker (<A href="http://www.toad.com/gnu/">
 303 home page</A>) </LI>
 304 <LI>Hugh Daniel: project manager, Most Demented Tester, and
 305 occasionally Pointy-Haired Boss </LI>
 306 </UL>
 307  The rest of the team are Canadians, working in Canada. (<A href="politics.html#status">
 308 Why Canada?</A>)
 309 <UL>
 310 <LI>Henry Spencer: technical lead, script programming </LI>
 311 <LI>Hugh Redelmeier: <A href="glossary.html#Pluto">Pluto daemon</A>
 312  programmer </LI>
 313 <LI>Richard Guy Briggs: <A href="glossary.html#KLIPS">KLIPS</A>
 314  programmer </LI>
 315 <LI>Claudia Schmeing: technical support via the <A href="mail.html">
 316 mailing lists</A></LI>
 317 <LI>Sandy Harris: documentation </LI>
 318 </UL>
 319  The project is funded by civil libertarians who consider our goals
 320 worthwhile. The team are paid for this work.
 321 <P> People outside this core team have made substantial contributions.
 322 See </P>
 323 <UL>
 324 <LI>our <A href="../CREDITS">CREDITS</A> file </LI>
 325 <LI>the <A href="web.html#patch">patches and add-ons</A> section of our
 326 web references file </LI>
 327 <LI>lists below of user-written <A href="#howto">HowTos</A> and <A href="#applied">
 328 other papers</A></LI>
 329 </UL>
 330  Additional contributions are welcome. See the <A href="faq.html#contrib.faq">
 331 FAQ</A> for details.
 332 <H3><A name="webdocs">Information on the web</A></H3>
 333 <UL>
 334 <LI>current site, <A href="http://liberty.freeswan.org">freeswan.org</A></LI>
 335 <LI>original project site at <A href="http://www.xs4all.nl/~freeswan">
 336 xs4all.nl</A></LI>
 337 </UL>
 338 <A name="sites">
 339 <H3><A name="sites">Distribution sites</A></H3>
 340  FreeS/WAN is available from a number of sites:
 341 <UL>
 342 <LI>Primary site, in Holland:
 343 <UL>
 344 <LI><A href="http://www.xs4all.nl/~freeswan">HTTP</A></LI>
 345 <LI><A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan">FTP</A></LI>
 346 </UL>
 347 </LI>
 348 <LI><A href="http://www.flora.org/freeswan">Eastern Canada</A> (limited
 349  resouces)</LI>
 350 <LI><A href="ftp://ludwig.doculink.com/pub/freeswan/">Eastern Canada</A>
 351  (has older versions too)</LI>
 352 <LI><A href="ftp://ntsc.notBSD.org/pub/crypto/freeswan/">Eastern Canada</A>
 353  (has older versions too)</LI>
 354 <LI><A href="ftp://ftp.kame.net/pub/freeswan/">Japan</A></LI>
 355 <LI><A href="ftp://ftp.futuredynamics.com/freecrypto/FreeSWAN/">Hong
 356  Kong</A></LI>
 357 <LI><A href="ftp://ipsec.dk/pub/freeswan/">Denmark</A></LI>
 358 <LI><A href="ftp://ftp.net.lut.ac.uk/freeswan">the UK</A></LI>
 359 <LI><A href="http://storm.alert.sk/comp/mirrors/freeswan/">Slovak
 360  Republic</A></LI>
 361 <LI><A href="http://the.wiretapped.net/security/vpn-tunnelling/freeswan/">
 362 Australia</A></LI>
 363 <LI><A href="http://freeswan.technolust.cx/">technolust</A></LI>
 364 <LI>Ivan Moore's <A href="http://snowcrash.tdyc.com/freeswan/">site</A></LI>
 365 <LI>the <A href="http://www.cryptoarchive.net/">Crypto Archive</A> on
 366 the <A href="http://www.securityportal.com/"> Security Portal</A> site </LI>
 367 </UL>
 368 <H4><A name="munitions">The &quot;munitions&quot; archive of Linux crypto software</A>
 369 </H4>
 370  There is also an archive of Linux crypto software called &quot;munitions&quot;,
 371 with its own mirrors in a number of countries. It includes FreeS/WAN,
 372 though not always the latest version. Some of its sites are:
 373 <UL>
 374 <LI><A href="http://munitions.vipul.net/">Germany</A></LI>
 375 <LI><A href="http://munitions.iglu.cjb.net/">Italy</A></LI>
 376 <LI><A href="http://munitions2.xs4all.nl/">Netherlands</A></LI>
 377 </UL>
 378 <P> Any of those will have a list of other &quot;munitions&quot; mirrors. </P>
 379 <H3><A name="archives">Archives of the project mailing list</A></H3>
 380  Until quite recently, there was only one FreeS/WAN mailing list, and
 381 archives of it were:
 382 <UL>
 383 <LI><A href="http://www.sandelman.ottawa.on.ca/linux-ipsec">Canada</A></LI>
 384 <LI><A href="http://www.nexial.com">Holland</A></LI>
 385 </UL>
 386  The two archives use completely different search engines. You might
 387 want to try both.
 388 <P> More recently we have expanded to five lists, each with its own
 389 archive. </P>
 390 <P><A href="mail.html"> More information</A> on mailing lists.</P>
 391 <H2><A name="products">Products containing FreeS/WAN</A></H2>
 392 <P> Unfortunately the <A href="politics.html#exlaw">export laws</A> of
 393 some countries restrict the distribution of strong cryptography.
 394 FreeS/WAN is therefore not in the standard Linux kernel and not in all
 395 CD or web distributions.</P>
 396 <H3><A name="distwith">Full Linux distributions</A></H3>
 397 <P>FreeS/WAN is included in various general-purpose Linux distributions
 398 from countries (shown in brackets) with more sensible laws:</P>
 399 <UL>
 400 <LI>European versions of <A href="http://www.suse.com/">SuSE Linux</A>
 401  (Germany)</LI>
 402 <LI><A href="http://www.conectiva.com">Conectiva</A> (Brazil)</LI>
 403 <LI>the server edition of <A href="http://www.corel.com">Corel</A>
 404  Linux (Canada)</LI>
 405 <LI>the <A href="http://www.pld.org.pl/">Polish(ed) Linux Distribution</A>
 406  (Poland)</LI>
 407 <LI><A href="http://www.trustix.net/">Trustix Secure Linux</A> (Norway) </LI>
 408 </UL>
 409 <P> For distributions which do not include FreeS/WAN and are not Redhat
 410 (which we develop and test on), there is additional information in our <A
 411 href="compatibility.html#otherdist">compatibility</A> section.</P>
 412 <P> We would appreciate hearing of other distributions using FreeS/WAN.</P>
 413 <H3><A name="fw_dist">Firewall distributions</A></H3>
 414  FreeS/WAN is also included in, or available for, more specialised
 415 distributions intended for firewall and router applications:
 416 <UL>
 417 <LI><A href="http://www.gibraltar.at/">Gibraltar</A> is based on Debian
 418 GNU/Linux.  It is bootable directly from CD-ROM,  usable on a machine
 419 without hard disk. </LI>
 420 <LI>The <A href="http://www.linuxrouter.org/">Linux Router Project</A>
 421  produces a distribution that will boot from a single floppy. Charles
 422  Steinkuehler's LRP site provides <A href="http://lrp.steinkuehler.net/Packages/ipsec1.5.htm">
 423  FreeS/WAN packaged for LRP</A>. </LI>
 424 <LI><A href="http://www.astaro.com/products/index.html">Astaro Security
 425 Linux</A> includes FreeS/WAN.  It has some web-based tools for managing
 426 the firewall that include FreeS/WAN configuration  management.</LI>
 427 <LI><A href="http://www.linuxwall.de">Linuxwall</A></LI>
 428 </UL>
 429 <P> There are also several sets of scripts available for managing a
 430 firewall which is also acting as a FreeS/WAN IPSEC gateway. See this <A href="firewall.html#examplefw">
 431 list</A>. </P>
 432 <P> We would appreciate hearing of other specialised distributions
 433 using FreeS/WAN, or other script sets.</P>
 434 <H3><A name="turnkey">Firewall and VPN products</A></H3>
 435 <P>Several vendors use FreeS/WAN as the IPSEC component of a turnkey
 436 firewall or VPN product:</P>
 437 <UL>
 438 <LI>The <A href="http://www.lasat.com">LASAT SafePipe[tm]</A> series.
 439 is an  IPSEC box based on an embedded MIPS running Linux with FreeS/WAN
 440 and a  web-config front end. This company also host our freeswan.org
 441 web  site.</LI>
 442 <LI><A href="www.rebel.com">Rebel.com</A>, makers of the Netwinder ARM
 443 Linux  machine, have a new (mid-2000) division <A href="http://www.rebel.com/solutions/smb/rn-what.html">
 444 Rebel Networks</A> whose product uses FreeS/WAN.</LI>
 445 <LI><A href="http://www.linuxmagic.com/vpn/index.html">Linux Magic</A>
 446  offer  a VPN/Firewall product using FreeS/WAN</LI>
 447 <LI>The Software Group's <A href="http://www.wanware.com/sentinet/">
 448 Sentinet</A> product uses  FreeS/WAN</LI>
 449 <LI><A href="http://www.merilus.com">Merilus</A> use FreeS/WAN in their
 450 Gateway Guardian firewall  product and in their <A href="http://www.merilus.com/firecard/index.shtml">
 451 Firecard</A> product, a Linux firewall on a PCI card. </LI>
 452 <LI><A href="http://www.kyzo.com/">Kyzo</A> have a &quot;pizza box&quot; product
 453 line with various types of  server, all running from flash. One of them
 454 is an IPSEC/PPTP VPN server. </LI>
 455 <LI><A href="http://www.linuxcare.com">Linuxcare</A> have &quot;bootable
 456 business card&quot;  usable as a recovery disk for broken Linux systems. </LI>
 457 </UL>
 458 <P>We would appreciate hearing of other products using FreeS/WAN.</P>
 459 <H2><A name="docs">Documentation</A></H2>
 460 <H3><A name="docformats">This HowTo, in multiple formats</A></H3>
 461 <P> FreeS/WAN documentation up to version 1.5 was available only in
 462 HTML. Now we ship two formats: </P>
 463 <UL>
 464 <LI>as HTML, one file for each doc section plus a global <A href="toc.html">
 465 Table of Contents</A></LI>
 466 <LI><A href="HowTo.html">one big HTML file</A> for easy searching</LI>
 467 </UL>
 468  and provide a Makefile to generate other formats if required:
 469 <UL>
 470 <LI><A href="HowTo.pdf">PDF</A></LI>
 471 <LI><A href="HowTo.ps">Postscript</A></LI>
 472 <LI><A href="HowTo.txt">ASCII text</A></LI>
 473 </UL>
 474 <P> The Makefile assumes the htmldoc tool is available. You can
 475 download it from <A href="http://www.easysw.com">Easy Software</A>. You
 476 may need to get source code and change some of the limits in <NOBR><VAR>
 477 #define MAX_&lt;whatever&gt;</VAR></NOBR> statements near the end of its <VAR>
 478 config.h.in</VAR> file. Otherwise it core dumps when those limits are
 479 exceeded on large files such as our glossary.html.</P>
 480 <P> All formats should be available at the following websites: </P>
 481 <UL>
 482 <LI><A href="http://www.freeswan.org/doc.html">FreeS/WAN project</A></LI>
 483 <LI><A href="http://www.linuxdoc.org">Linux Documentation Project</A></LI>
 484 </UL>
 485 <P> The distribution tarball has only the two HTML formats.</P>
 486 <P><STRONG> Note:</STRONG> If you need the latest doc version, for
 487 example to see if anyone has managed to set up interoperation between
 488 FreeS/WAN and whatever, then you should download the current snapshot.
 489 What is on the web is documentation as of the last release. Snapshots
 490 have all changes I've checked in to date. </P>
 491 <H3><A name="text">Other documents in the distribution</A></H3>
 492 <P>Text files in the main distribution directory are README, INSTALL,
 493 CREDITS, CHANGES, BUGS and COPYING.</P>
 494 <P> FreeS/WAN commands and library routines are documented in standard
 495 Unix manual pages, accessible via the <VAR>man(1)</VAR> command. We
 496 also provide them in HTML, accessible from this <A href="manpages.html">
 497 index</A>. In the event of disagreement between this HowTo and the man
 498 pages, the man pages are more likely correct since they are written by
 499 the implementers. Please report any such inconsistency on the <A href="mail.html">
 500 mailing list</A>.</P>
 501 <P>The gmp (GNU multi-precision arithmetic) and Libdes (encryption)
 502 libraries which we use each have their own documentation. You can find
 503 it in those library directories.</P>
 504 <H3><A name="howto">User-written HowTo information</A></H3>
 505 <P> Various user-written HowTo documents are available. The ones
 506 covering FreeS/WAN-to-FreeS/WAN connections are:</P>
 507 <UL>
 508 <LI>Jean-Francois Nadeau's <A href="http://jixen.tripod.com/">practical
 509  configurations</A> document</LI>
 510 <LI>Jens Zerbst's HowTo on <A href="http://dynipsec.tripod.com/">Using
 511 FreeS/WAN with dynamic IP  addresses</A>. </LI>
 512 <LI>an entry in Kurt Seifried's <A href="http://www.securityportal.com/lskb/kben00000013.html">
 513  Linux Security Knowledge Base</A>. </LI>
 514 <LI>a section of David Ranch's <A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
 515 Trinity  OS Guide</A></LI>
 516 <LI>a section in David Bander's book <A href="biblio.html#bander">Linux
 517 Security Toolkit</A></LI>
 518 </UL>
 519 <P> User-wriiten HowTo material may be <STRONG>especially helpful if
 520 you need to interoperate with another IPSEC implementation</STRONG>. We
 521 have neither the equipment nor the manpower to test such
 522 configurations. Users seem to be doing an admirable job of filling the
 523 gaps.</P>
 524 <UL>
 525 <LI>list of user-written <A href="interop.html#otherpub">interoperation
 526 HowTos</A> in our interop document </LI>
 527 </UL>
 528 <P> Check what version of FreeS/WAN user-written documents cover. The
 529 software is under active development and the current version may be
 530 significantly different from what an older document describes.</P>
 531 <H3><A name="applied">Papers on FreeS/WAN</A></H3>
 532 <P> Two design documents show current team thinking on new
 533 developments: </P>
 534 <UL>
 535 <LI><A href="opportunism.spec">Opportunistic Encryption</A> by
 536 technical lead Henry Spencer and Pluto programmer Hugh Redelemeier </LI>
 537 <LI><A href="klips2.spec">KLIPS II Design</A> by kernel programmer
 538 Richard Guy Briggs </LI>
 539 </UL>
 540  Both documents are works in progress and frequently revised. The most
 541 recent versions can be found either in FreeS/WAN snapshots or on the <A href="mail.html">
 542 design mailing list</A>. Comments should go to that list.
 543 <P> A number of papers giving further background on FreeS/WAN, or
 544 exploring its future or its applications, are also available:</P>
 545 <UL>
 546 <LI>Both Henry and Richard gave talks on FreeS/WAN at the 2000 <A href="http://www.linuxsymposium.org">
 547 Ottawa Linux Symposium</A>.
 548 <UL>
 549 <LI>Richard's <A href="http://www.conscoop.ottawa.on.ca/rgb/freeswan/ols2k/">
 550 slides</A></LI>
 551 <LI>Henry's paper</LI>
 552 <LI>MP3 audio of their talks is available from the <A href="http://www.linuxsymposium.org/">
 553 conference page</A></LI>
 554 </UL>
 555 </LI>
 556 <LI><CITE>Moat: A Virtual Private Network Appliances and Services
 557  Platform</CITE> is a paper about large-scale (a few 100 links) use of
 558  FreeS/WAN in a production application at AT&amp;T research. It is
 559  available in Postscript or PDF from co-author Steve Bellovin's <A href="http://www.research.att.com/~smb/papers/index.html">
 560 papers list  page</A>.</LI>
 561 <LI>One of the Moat co-authors, John Denker, has also written
 562 <UL>
 563 <LI>a <A href="http://www.quintillion.com/fdis/moat/ipsec+routing/">
 564 proposal</A> for how future versions of FreeS/WAN might interact with
 565 routing  protocols</LI>
 566 <LI>a <A href="http://www.quintillion.com/fdis/moat/wishlist.html">
 567 wishlist</A> of possible new features</LI>
 568 </UL>
 569 </LI>
 570 <LI>Bart Trojanowski's web page has a draft design for <A href="http://www.jukie.net/~bart/linux-ipsec/">
 571  hardware acceleration</A> of FreeS/WAN </LI>
 572 <LI>Feczak Szabolcs' <A href="http://feczo.koli.kando.hu/vpn/">thesis</A>
 573 , in Hungarian </LI>
 574 </UL>
 575 <P> Several of these provoked interesting discussions on the mailing
 576 lists, worth searching for in the <A href="mail.html#archive">archives</A>
 577 . </P>
 578 <H3><A name="test">Test results</A></H3>
 579 <UL>
 580 <LI><A href="http://tsc.llwybr.org.uk/public/reports/SWANTIME/">Speed
 581 test  results</A> from a Welsh university.</LI>
 582 </UL>
 583 <P> Interoperability test results are in our <A href="web.html#result">
 584 web links</A> document. </P>
 585 <H2><A name="licensing">License and copyright information</A></H2>
 586  All code and documentation written for this project is distributed
 587 under either the GNU General Public License (<A href="glossary.html#GPL">
 588 GPL</A>) or the GNU Library General Public License. For details see the
 589 COPYING file in the distribution.
 590 <P>Not all code in the distribution is ours, however. See the CREDITS
 591 file for details. In particular, note that the <A href="glossary.html#LIBDES">
 592 Libdes</A> library has its own license.</P>
 593 <H2><A NAME="1_6">Links to other sections</A></H2>
 594 <P>For more detailed background information, see:</P>
 595 <UL>
 596 <LI><A href="politics.html">history and politics</A> of cryptography</LI>
 597 <LI><A href="ipsec.html">IPSEC protocols</A></LI>
 598 </UL>
 599 <P> To begin working with FreeS/WAN, go to: </P>
 600 <UL>
 601 <LI><A href="install.html">installation</A> if you need to install
 602 FreeS/WAN</LI>
 603 <LI><A href="config.html">setup</A> if your distribution came with
 604 FreeS/WAN so  you just need to configure your IPSEC links</LI>
 605 </UL>
 606 <HR>
 607 <A HREF="toc.html">Contents</a>
 608 <A HREF="install.html">Next</a>
 609 </BODY>
 610 </HTML>