18734 lines
936 KiB
HTML
18734 lines
936 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Introduction to FreeS/WAN</TITLE>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
|
|
<STYLE TYPE="text/css"><!--
|
|
BODY { font-family: serif }
|
|
H1 { font-family: sans-serif }
|
|
H2 { font-family: sans-serif }
|
|
H3 { font-family: sans-serif }
|
|
H4 { font-family: sans-serif }
|
|
H5 { font-family: sans-serif }
|
|
H6 { font-family: sans-serif }
|
|
SUB { font-size: smaller }
|
|
SUP { font-size: smaller }
|
|
PRE { font-family: monospace }
|
|
--></STYLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<CENTER><A HREF="#CONTENTS"><H1>Introduction to FreeS/WAN</H1></A><BR>
|
|
</CENTER>
|
|
<HR>
|
|
<H1 ALIGN="CENTER"><A NAME="CONTENTS">Table of Contents</A></H1>
|
|
<BR>
|
|
<BR><B><A HREF="#intro">Introduction</A></B>
|
|
<UL>
|
|
<LI><A HREF="#ipsec.intro">IPsec, Security for the Internet Protocol</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#intro.interop">Interoperating with other IPsec
|
|
implementations</A></LI>
|
|
<LI><A HREF="#advantages">Advantages of IPsec</A></LI>
|
|
<LI><A HREF="#applications">Applications of IPsec</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#makeVPN">Using secure tunnels to create a VPN</A></LI>
|
|
<LI><A HREF="#road.intro">Road Warriors</A></LI>
|
|
<LI><A HREF="#opp.intro">Opportunistic encryption</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#types">The need to authenticate gateways</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#project">The FreeS/WAN project</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#goals">Project goals</A></LI>
|
|
<LI><A HREF="#staff">Project team</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#products">Products containing FreeS/WAN</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#distwith">Full Linux distributions</A></LI>
|
|
<LI><A HREF="#kernel_dist">Linux kernel distributions</A></LI>
|
|
<LI><A HREF="#office_dist">Office server distributions</A></LI>
|
|
<LI><A HREF="#fw_dist">Firewall distributions</A></LI>
|
|
<LI><A HREF="#turnkey">Firewall and VPN products</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#docs">Information sources</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#docformats">This HowTo, in multiple formats</A></LI>
|
|
<LI><A HREF="#rtfm">RTFM (please Read The Fine Manuals)</A></LI>
|
|
<LI><A HREF="#text">Other documents in the distribution</A></LI>
|
|
<LI><A HREF="#assumptions">Background material</A></LI>
|
|
<LI><A HREF="#archives">Archives of the project mailing list</A></LI>
|
|
<LI><A HREF="#howto">User-written HowTo information</A></LI>
|
|
<LI><A HREF="#applied">Papers on FreeS/WAN</A></LI>
|
|
<LI><A HREF="#licensing">License and copyright information</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#sites">Distribution sites</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#1_5_1">Primary site</A></LI>
|
|
<LI><A HREF="#mirrors">Mirrors</A></LI>
|
|
<LI><A HREF="#munitions">The "munitions" archive of Linux crypto
|
|
software</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#1_6">Links to other sections</A></LI>
|
|
</UL>
|
|
<B><A HREF="#2">Upgrading to FreeS/WAN 2.x</A></B>
|
|
<UL>
|
|
<LI><A HREF="#2_1">New! Built in Opportunistic connections</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#2_1_1">Upgrading Opportunistic Encryption to 2.01 (or
|
|
later)</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#2_2">New! Policy Groups</A></LI>
|
|
<LI><A HREF="#2_3">New! Packetdefault Connection</A></LI>
|
|
<LI><A HREF="#2_4">FreeS/WAN now disables Reverse Path Filtering</A></LI>
|
|
<LI><A HREF="#2_5">Revised ipsec.conf</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#2_5_1">No promise of compatibility</A></LI>
|
|
<LI><A HREF="#2_5_2">Most ipsec.conf files will work fine</A></LI>
|
|
<LI><A HREF="#2_5_3">Backward compatibility patch</A></LI>
|
|
<LI><A HREF="#2_5_4">Details</A></LI>
|
|
<LI><A HREF="#2_5_5">Upgrading from 1.x RPMs to 2.x RPMs</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#quickstart">Quickstart Guide to Opportunistic Encryption</A>
|
|
</B>
|
|
<UL>
|
|
<LI><A HREF="#opp.setup">Purpose</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#3_1_1">OE "flag day"</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#opp.dns">Requirements</A></LI>
|
|
<LI><A HREF="#easy.install">RPM install</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#3_3_1">Download RPMs</A></LI>
|
|
<LI><A HREF="#3_3_2">Check signatures</A></LI>
|
|
<LI><A HREF="#3_3_3">Install the RPMs</A></LI>
|
|
<LI><A HREF="#testinstall">Test</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#opp.setups.list">Our Opportunistic Setups</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#3_4_1">Full or partial opportunism?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#opp.client">Initiate-only setup</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#3_5_1">Restrictions</A></LI>
|
|
<LI><A HREF="#forward.dns">Create and publish a forward DNS record</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#3_5_2_1">Find a domain you can use</A></LI>
|
|
<LI><A HREF="#3_5_2_2">Choose your ID</A></LI>
|
|
<LI><A HREF="#3_5_2_3">Create a forward TXT record</A></LI>
|
|
<LI><A HREF="#3_5_2_4">Publish the forward TXT record</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#3_5_3">Test that your key has been published</A></LI>
|
|
<LI><A HREF="#3_5_4">Configure, if necessary</A></LI>
|
|
<LI><A HREF="#3_5_5">Test</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#3_6">Full Opportunism</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#3_6_1">Put a TXT record in a Forward Domain</A></LI>
|
|
<LI><A HREF="#3_6_2">Put a TXT record in Reverse DNS</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#3_6_2_1">Create a Reverse DNS TXT record</A></LI>
|
|
<LI><A HREF="#3_6_2_2">Publish your TXT record</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#3_6_3">Test your DNS record</A></LI>
|
|
<LI><A HREF="#3_6_4">No Configuration Needed</A></LI>
|
|
<LI><A HREF="#3_6_5">Consider Firewalling</A></LI>
|
|
<LI><A HREF="#3_6_6">Test</A></LI>
|
|
<LI><A HREF="#3_6_7">Test</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#opp.test">Testing opportunistic connections</A></LI>
|
|
<LI><A HREF="#3_8">Now what?</A></LI>
|
|
<LI><A HREF="#3_9">Notes</A></LI>
|
|
<LI><A HREF="#3_10">Troubleshooting OE</A></LI>
|
|
<LI><A HREF="#3_11">Known Issues</A></LI>
|
|
</UL>
|
|
<B><A HREF="#4">How to Configure Linux FreeS/WAN with Policy Groups</A></B>
|
|
<UL>
|
|
<LI><A HREF="#4_1">What are Policy Groups?</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#4_1_1">Built-In Security Options</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#4_2">Using Policy Groups</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#4_2_1">Example 1: Using a Base Policy Group</A></LI>
|
|
<LI><A HREF="#4_2_2">Example 2: Defining IPsec Security Policy with
|
|
Groups</A></LI>
|
|
<LI><A HREF="#4_2_3">Example 3: Creating a Simple IPsec VPN with the
|
|
private Group</A></LI>
|
|
<LI><A HREF="#4_2_4">Example 4: New Policy Groups to Protect a Subnet</A>
|
|
</LI>
|
|
<LI><A HREF="#4_2_5">Example 5: Adding a Subnet to the VPN</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#4_3">Appendix</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#4_3_1">Our Hidden Connections</A></LI>
|
|
<LI><A HREF="#4_3_2">Custom Policy Groups</A></LI>
|
|
<LI><A HREF="#4_3_3">Disabling Opportunistic Encryption</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#5">FreeS/WAN FAQ</A></B>
|
|
<UL>
|
|
<LI><A HREF="#questions">Index of FAQ questions</A></LI>
|
|
<LI><A HREF="#whatzit">What is FreeS/WAN?</A></LI>
|
|
<LI><A HREF="#problems">How do I report a problem or seek help?</A></LI>
|
|
<LI><A HREF="#generic">Can I get ...</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#lemme_out">Can I get an off-the-shelf system that includes
|
|
FreeS/WAN?</A></LI>
|
|
<LI><A HREF="#consultant">Can I hire consultants or staff who know
|
|
FreeS/WAN?</A></LI>
|
|
<LI><A HREF="#commercial">Can I get commercial support?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#release">Release questions</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#rel.current">What is the current release?</A></LI>
|
|
<LI><A HREF="#relwhen">When is the next release?</A></LI>
|
|
<LI><A HREF="#rel.bugs">Are there known bugs in the current release?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#mod_cons">Modifications and contributions</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#modify.faq">Can I modify FreeS/WAN to ...?</A></LI>
|
|
<LI><A HREF="#contrib.faq">Can I contribute to the project?</A></LI>
|
|
<LI><A HREF="#ddoc.faq">Is there detailed design documentation?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#interact">Will FreeS/WAN work in my environment?</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#interop.faq">Can FreeS/WAN talk to ...?</A></LI>
|
|
<LI><A HREF="#old_to_new">Can different FreeS/WAN versions talk to each
|
|
other?</A></LI>
|
|
<LI><A HREF="#faq.bandwidth">Is there a limit on throughput?</A></LI>
|
|
<LI><A HREF="#faq.number">Is there a limit on number of tunnels?</A></LI>
|
|
<LI><A HREF="#faq.speed">Is a ... fast enough to handle FreeS/WAN with
|
|
my loads?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#work_on">Will FreeS/WAN work on ... ?</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#versions">Will FreeS/WAN run on my version of Linux?</A></LI>
|
|
<LI><A HREF="#nonIntel.faq">Will FreeS/WAN run on non-Intel CPUs?</A></LI>
|
|
<LI><A HREF="#multi.faq">Will FreeS/WAN run on multiprocessors?</A></LI>
|
|
<LI><A HREF="#k.old">Will FreeS/WAN work on an older kernel?</A></LI>
|
|
<LI><A HREF="#k.versions">Will FreeS/WAN run on the latest kernel
|
|
version?</A></LI>
|
|
<LI><A HREF="#interface.faq">Will FreeS/WAN work on unusual network
|
|
hardware?</A></LI>
|
|
<LI><A HREF="#vlan">Will FreeS/WAN work on a VLAN (802.1q) network?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#features.faq">Does FreeS/WAN support ...</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#VPN.faq">Does FreeS/WAN support site-to-site VPN (Virtual
|
|
Private Network) applications?</A></LI>
|
|
<LI><A HREF="#warrior.faq">Does FreeS/WAN support remote users
|
|
connecting to a LAN?</A></LI>
|
|
<LI><A HREF="#road.shared.possible">Does FreeS/WAN support remote users
|
|
using shared secret authentication?</A></LI>
|
|
<LI><A HREF="#wireless.faq">Does FreeS/WAN support wireless networks?</A>
|
|
</LI>
|
|
<LI><A HREF="#PKIcert">Does FreeS/WAN support X.509 or other PKI
|
|
certificates?</A></LI>
|
|
<LI><A HREF="#Radius">Does FreeS/WAN support user authentication
|
|
(Radius, SecureID, Smart Card...)?</A></LI>
|
|
<LI><A HREF="#NATtraversal">Does FreeS/WAN support NAT traversal?</A></LI>
|
|
<LI><A HREF="#virtID">Does FreeS/WAN support assigning a "virtual
|
|
identity" to a remote system?</A></LI>
|
|
<LI><A HREF="#noDES.faq">Does FreeS/WAN support single DES encryption?</A>
|
|
</LI>
|
|
<LI><A HREF="#AES.faq">Does FreeS/WAN support AES encryption?</A></LI>
|
|
<LI><A HREF="#other.cipher">Does FreeS/WAN support other encryption
|
|
algorithms?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#canI">Can I ...</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#policy.preconfig">Can I use policy groups along with
|
|
explicitly configured connections?</A></LI>
|
|
<LI><A HREF="#policy.off">Can I turn off policy groups?</A></LI>
|
|
<LI><A HREF="#reload">Can I reload connection info without restarting?</A>
|
|
</LI>
|
|
<LI><A HREF="#masq.faq">Can I use several masqueraded subnets?</A></LI>
|
|
<LI><A HREF="#dup_route">Can I use subnets masqueraded to the same
|
|
addresses?</A></LI>
|
|
<LI><A HREF="#road.masq">Can I assign a road warrior an address on my
|
|
net (a virtual identity)?</A></LI>
|
|
<LI><A HREF="#road.many">Can I support many road warriors with one
|
|
gateway?</A></LI>
|
|
<LI><A HREF="#road.PSK">Can I have many road warriors using shared
|
|
secret authentication?</A></LI>
|
|
<LI><A HREF="#QoS">Can I use Quality of Service routing with FreeS/WAN?</A>
|
|
</LI>
|
|
<LI><A HREF="#deadtunnel">Can I recognise dead tunnels and shut them
|
|
down?</A></LI>
|
|
<LI><A HREF="#demanddial">Can I build IPsec tunnels over a demand-dialed
|
|
link?</A></LI>
|
|
<LI><A HREF="#GRE">Can I build GRE, L2TP or PPTP tunnels over IPsec?</A></LI>
|
|
<LI><A HREF="#NetBIOS">... use Network Neighborhood (Samba, NetBIOS)
|
|
over IPsec?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#setup.faq">Life's little mysteries</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#cantping">I cannot ping ....</A></LI>
|
|
<LI><A HREF="#forever">It takes forever to ...</A></LI>
|
|
<LI><A HREF="#route">I send packets to the tunnel with route(8) but they
|
|
vanish</A></LI>
|
|
<LI><A HREF="#down_route">When a tunnel goes down, packets vanish</A></LI>
|
|
<LI><A HREF="#firewall_ate">The firewall ate my packets!</A></LI>
|
|
<LI><A HREF="#dropconn">Dropped connections</A></LI>
|
|
<LI><A HREF="#defaultroutegone">Disappearing %defaultroute</A></LI>
|
|
<LI><A HREF="#tcpdump.faq">TCPdump on the gateway shows strange things</A>
|
|
</LI>
|
|
<LI><A HREF="#no_trace">Traceroute does not show anything between the
|
|
gateways</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#man4debug">Testing in stages</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#nomanual">Manually keyed connections don't work</A></LI>
|
|
<LI><A HREF="#spi_error">One manual connection works, but second one
|
|
fails</A></LI>
|
|
<LI><A HREF="#man_no_auto">Manual connections work, but automatic keying
|
|
doesn't</A></LI>
|
|
<LI><A HREF="#nocomp">IPsec works, but connections using compression
|
|
fail</A></LI>
|
|
<LI><A HREF="#pmtu.broken">Small packets work, but large transfers fail</A>
|
|
</LI>
|
|
<LI><A HREF="#subsub">Subnet-to-subnet works, but tests from the
|
|
gateways don't</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#compile.faq">Compilation problems</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#gmp.h_missing">gmp.h: No such file or directory</A></LI>
|
|
<LI><A HREF="#noVM">... virtual memory exhausted</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#error">Interpreting error messages</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#route-client">route-client (or host) exited with status 7</A>
|
|
</LI>
|
|
<LI><A HREF="#unreachable">SIOCADDRT:Network is unreachable</A></LI>
|
|
<LI><A HREF="#modprobe">ipsec_setup: modprobe: Can't locate module ipsec</A>
|
|
</LI>
|
|
<LI><A HREF="#noKLIPS">ipsec_setup: Fatal error, kernel appears to lack
|
|
KLIPS</A></LI>
|
|
<LI><A HREF="#noDNS">ipsec_setup: ... failure to fetch key for ... from
|
|
DNS</A></LI>
|
|
<LI><A HREF="#dup_address">ipsec_setup: ... interfaces ... and ... share
|
|
address ...</A></LI>
|
|
<LI><A HREF="#kflags">ipsec_setup: Cannot adjust kernel flags</A></LI>
|
|
<LI><A HREF="#message_num">Message numbers (MI3, QR1, et cetera) in
|
|
Pluto messages</A></LI>
|
|
<LI><A HREF="#conn_name">Connection names in Pluto error messages</A></LI>
|
|
<LI><A HREF="#cantorient">Pluto: ... can't orient connection</A></LI>
|
|
<LI><A HREF="#no.interface">... we have no ipsecN interface for either
|
|
end of this connection</A></LI>
|
|
<LI><A HREF="#noconn">Pluto: ... no connection is known</A></LI>
|
|
<LI><A HREF="#nosuit">Pluto: ... no suitable connection ...</A></LI>
|
|
<LI><A HREF="#noconn.auth">Pluto: ... no connection has been authorized</A>
|
|
</LI>
|
|
<LI><A HREF="#noDESsupport">Pluto: ... OAKLEY_DES_CBC is not supported.</A>
|
|
</LI>
|
|
<LI><A HREF="#notransform">Pluto: ... no acceptable transform</A></LI>
|
|
<LI><A HREF="#rsasigkey">rsasigkey dumps core</A></LI>
|
|
<LI><A HREF="#sig4">!Pluto failure!: ... exited with ... signal 4</A></LI>
|
|
<LI><A HREF="#econnrefused">ECONNREFUSED error message</A></LI>
|
|
<LI><A HREF="#no_eroute">klips_debug: ... no eroute!</A></LI>
|
|
<LI><A HREF="#SAused">... trouble writing to /dev/ipsec ... SA already
|
|
in use</A></LI>
|
|
<LI><A HREF="#ignore">... ignoring ... payload</A></LI>
|
|
<LI><A HREF="#unknown_rightcert">unknown parameter name "rightcert"</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#spam">Why don't you restrict the mailing lists to reduce
|
|
spam?</A></LI>
|
|
</UL>
|
|
<B><A HREF="#manpages">FreeS/WAN manual pages</A></B>
|
|
<UL>
|
|
<LI><A HREF="#man.file">Files</A></LI>
|
|
<LI><A HREF="#man.command">Commands</A></LI>
|
|
<LI><A HREF="#man.lib">Library routines</A></LI>
|
|
</UL>
|
|
<B><A HREF="#firewall">FreeS/WAN and firewalls</A></B>
|
|
<UL>
|
|
<LI><A HREF="#filters">Filtering rules for IPsec packets</A></LI>
|
|
<LI><A HREF="#examplefw">Firewall configuration at boot</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#simple.rules">A simple set of rules</A></LI>
|
|
<LI><A HREF="#complex.rules">Other rules</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#7_2_2_1">Adding additional rules</A></LI>
|
|
<LI><A HREF="#7_2_2_2">Modifying existing rules</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#rules.pub">Published rule sets</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#Ranch.trinity">Scripts based on Ranch's work</A></LI>
|
|
<LI><A HREF="#seawall">The Seattle firewall</A></LI>
|
|
<LI><A HREF="#rcf">The RCF scripts</A></LI>
|
|
<LI><A HREF="#asgard">Asgard scripts</A></LI>
|
|
<LI><A HREF="#user.scripts">User scripts from the mailing list</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#updown">Calling firewall scripts, named in ipsec.conf(5)</A>
|
|
</LI>
|
|
<UL>
|
|
<LI><A HREF="#pre_post">Scripts called at IPsec start and stop</A></LI>
|
|
<LI><A HREF="#up_down">Scripts called at connection up and down</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#fw.default">The default script</A></LI>
|
|
<LI><A HREF="#userscript">User-written scripts</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#ipchains.script">Scripts for ipchains or iptables</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#NAT">A complication: IPsec vs. NAT</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#nat_ok">NAT on or behind the IPsec gateway works</A></LI>
|
|
<LI><A HREF="#nat_bad">NAT between gateways is problematic</A></LI>
|
|
<LI><A HREF="#NAT.ref">Other references on NAT and IPsec</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#complications">Other complications</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#through">IPsec through the gateway</A></LI>
|
|
<LI><A HREF="#ipsec_only">Preventing non-IPsec traffic</A></LI>
|
|
<LI><A HREF="#unknowngate">Filtering packets from unknown gateways</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#otherfilter">Other packet filters</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#ICMP">ICMP filtering</A></LI>
|
|
<LI><A HREF="#traceroute">UDP packets for traceroute</A></LI>
|
|
<LI><A HREF="#l2tp">UDP for L2TP</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#packets">How it all works: IPsec packet details</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#noport">ESP and AH do not have ports</A></LI>
|
|
<LI><A HREF="#header">Header layout</A></LI>
|
|
<LI><A HREF="#dhr">DHR on the updown script</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#trouble">Linux FreeS/WAN Troubleshooting Guide</A></B>
|
|
<UL>
|
|
<LI><A HREF="#overview">Overview</A></LI>
|
|
<LI><A HREF="#install">1. During Install</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_2_1">1.1 RPM install gotchas</A></LI>
|
|
<LI><A HREF="#8_2_2">1.2 Problems installing from source</A></LI>
|
|
<LI><A HREF="#install.check">1.3 Install checks</A></LI>
|
|
<LI><A HREF="#oe.trouble">1.3 Troubleshooting OE</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#negotiation">2. During Negotiation</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#state">2.1 Determine Connection State</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_3_1_1">Finding current state</A></LI>
|
|
<LI><A HREF="#8_3_1_2">What's this supposed to look like?</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#find.pluto.error">2.2 Finding error text</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_3_2_1">Verbose start for more information</A></LI>
|
|
<LI><A HREF="#8_3_2_2">Debug levels count</A></LI>
|
|
<LI><A HREF="#8_3_2_3">ipsec barf for lots of debugging information</A></LI>
|
|
<LI><A HREF="#8_3_2_4">Find the error</A></LI>
|
|
<LI><A HREF="#8_3_2_5">Play both sides</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#interpret.pluto.error">2.3 Interpreting a Negotiation
|
|
Error</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#ikepath">Connection stuck at STATE_MAIN_I1</A></LI>
|
|
<LI><A HREF="#8_3_3_2">Other errors</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#use">3. Using a Connection</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_4_1">3.1 Orienting yourself</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_4_1_1">How do I know if it works?</A></LI>
|
|
<LI><A HREF="#8_4_1_2">ipsec barf is useful again</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#8_4_2">3.2 Those pesky configuration errors</A></LI>
|
|
<LI><A HREF="#route.firewall">3.3 Check Routing and Firewalling</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_4_3_1">Background:</A></LI>
|
|
<LI><A HREF="#ifconfig">View Interface and Firewall Statistics</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#sniff">3.4 When in doubt, sniff it out</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_4_4_1">Anticipate your packets' path</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#find.use.error">3.5 Check your logs</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#interpret.use.error">Interpreting log text</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#bigpacket">3.6 More testing for the truly thorough</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_4_6_1">Large Packets</A></LI>
|
|
<LI><A HREF="#8_4_6_2">Stress Tests</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#prob.report">4. Problem Reporting</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#8_5_1">4.1 How to ask for help</A></LI>
|
|
<LI><A HREF="#8_5_2">4.2 Where to ask</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#notes">5. Additional Notes on Troubleshooting</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#system.info">5.1 Information available on your system</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#logusage">Logs used</A></LI>
|
|
<LI><A HREF="#pages">man pages provided</A></LI>
|
|
<LI><A HREF="#statusinfo">Status information</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#testgates"> 5.2 Testing between security gateways</A></LI>
|
|
<LI><A HREF="#ifconfig1">5.3 ifconfig reports for KLIPS debugging</A></LI>
|
|
<LI><A HREF="#gdb"> 5.4 Using GDB on Pluto</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#compat">Linux FreeS/WAN Compatibility Guide</A></B>
|
|
<UL>
|
|
<LI><A HREF="#spec">Implemented parts of the IPsec Specification</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#in">In Linux FreeS/WAN</A></LI>
|
|
<LI><A HREF="#dropped">Deliberately omitted</A></LI>
|
|
<LI><A HREF="#not">Not (yet) in Linux FreeS/WAN</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#pfkey">Our PF-Key implementation</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#pfk.port">PF-Key portability</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#otherk">Kernels other than the latest 2.2.x and 2.4.y</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#kernel.2.0">2.0.x kernels</A></LI>
|
|
<LI><A HREF="#kernel.production">2.2 and 2.4 kernels</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#otherdist">Intel Linux distributions other than Redhat</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#rh7">Redhat 7.0</A></LI>
|
|
<LI><A HREF="#suse">SuSE Linux</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#9_4_2_1">SuSE Linux 5.3</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#slack">Slackware</A></LI>
|
|
<LI><A HREF="#deb">Debian</A></LI>
|
|
<LI><A HREF="#caldera">Caldera</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#CPUs">CPUs other than Intel</A></LI>
|
|
<UL>
|
|
<LI><A HREF="# strongarm">Corel Netwinder (StrongARM CPU)</A></LI>
|
|
<LI><A HREF="#yellowdog">Yellow Dog Linux on Power PC</A></LI>
|
|
<LI><A HREF="#mklinux">Mklinux</A></LI>
|
|
<LI><A HREF="#alpha">Alpha 64-bit processors</A></LI>
|
|
<LI><A HREF="#SPARC">Sun SPARC processors</A></LI>
|
|
<LI><A HREF="#mips">MIPS processors</A></LI>
|
|
<LI><A HREF="#crusoe">Transmeta Crusoe</A></LI>
|
|
<LI><A HREF="#coldfire">Motorola Coldfire</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#multiprocessor">Multiprocessor machines</A></LI>
|
|
<LI><A HREF="#hardware">Support for crypto hardware</A></LI>
|
|
<LI><A HREF="#ipv6">IP version 6 (IPng)</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#v6.back">IPv6 background</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#10">Interoperating with FreeS/WAN</A></B>
|
|
<UL>
|
|
<LI><A HREF="#10_1">Interop at a Glance</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#10_1_1">Key</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#10_2">Basic Interop Rules</A></LI>
|
|
<LI><A HREF="#10_3">Longer Stories</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#10_3_1">For More Compatible Implementations</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#freeswan">FreeS/WAN</A></LI>
|
|
<LI><A HREF="#isakmpd">isakmpd (OpenBSD)</A></LI>
|
|
<LI><A HREF="#kame">Kame</A></LI>
|
|
<LI><A HREF="#mcafee">PGPNet/McAfee</A></LI>
|
|
<LI><A HREF="#microsoft">Microsoft Windows 2000/XP</A></LI>
|
|
<LI><A HREF="#ssh">SSH Sentinel</A></LI>
|
|
<LI><A HREF="#safenet">Safenet SoftPK/SoftRemote</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#10_3_2">For Other Implementations</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#6wind">6Wind</A></LI>
|
|
<LI><A HREF="#alcatel">Alcatel Timestep</A></LI>
|
|
<LI><A HREF="#apple">Apple Macintosh System 10+</A></LI>
|
|
<LI><A HREF="#ashleylaurent">AshleyLaurent VPCom</A></LI>
|
|
<LI><A HREF="#borderware">Borderware</A></LI>
|
|
<LI><A HREF="#checkpoint">Check Point VPN-1 or FW-1</A></LI>
|
|
<LI><A HREF="#cisco">Cisco</A></LI>
|
|
<LI><A HREF="#equinux">Equinux VPN tracker (for Mac OS X)</A></LI>
|
|
<LI><A HREF="#fsecure">F-Secure</A></LI>
|
|
<LI><A HREF="#gauntlet">Gauntlet GVPN</A></LI>
|
|
<LI><A HREF="#aix">IBM AIX</A></LI>
|
|
<LI><A HREF="#as400">IBM AS/400</A></LI>
|
|
<LI><A HREF="#intel">Intel Shiva LANRover / Net Structure</A></LI>
|
|
<LI><A HREF="#lancom">LanCom (formerly ELSA)</A></LI>
|
|
<LI><A HREF="#linksys">Linksys</A></LI>
|
|
<LI><A HREF="#lucent">Lucent</A></LI>
|
|
<LI><A HREF="#netasq">Netasq</A></LI>
|
|
<LI><A HREF="#netcelo">Netcelo</A></LI>
|
|
<LI><A HREF="#netgear">Netgear fvs318</A></LI>
|
|
<LI><A HREF="#netscreen">Netscreen 100 or 5xp</A></LI>
|
|
<LI><A HREF="#nortel">Nortel Contivity</A></LI>
|
|
<LI><A HREF="#radguard">Radguard</A></LI>
|
|
<LI><A HREF="#raptor">Raptor (NT or Solaris)</A></LI>
|
|
<LI><A HREF="#redcreek">Redcreek Ravlin</A></LI>
|
|
<LI><A HREF="#sonicwall">SonicWall</A></LI>
|
|
<LI><A HREF="#sun">Sun Solaris</A></LI>
|
|
<LI><A HREF="#symantec">Symantec</A></LI>
|
|
<LI><A HREF="#watchguard">Watchguard Firebox</A></LI>
|
|
<LI><A HREF="#xedia">Xedia Access Point/QVPN</A></LI>
|
|
<LI><A HREF="#zyxel">Zyxel</A></LI>
|
|
</UL>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#performance">Performance of FreeS/WAN</A></B>
|
|
<UL>
|
|
<LI><A HREF="#pub.bench">Published material</A></LI>
|
|
<LI><A HREF="#perf.estimate">Estimating CPU overheads</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#perf.more">Higher performance alternatives</A></LI>
|
|
<LI><A HREF="#11_2_2">Other considerations</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#biggate">Many tunnels from a single gateway</A></LI>
|
|
<LI><A HREF="#low-end">Low-end systems</A></LI>
|
|
<LI><A HREF="#klips.bench">Measuring KLIPS</A></LI>
|
|
<LI><A HREF="#speed.compress">Speed with compression</A></LI>
|
|
<LI><A HREF="#methods">Methods of measuring</A></LI>
|
|
</UL>
|
|
<B><A HREF="#test.freeswan">Testing FreeS/WAN</A></B>
|
|
<UL>
|
|
<LI><A HREF="#test.oe">Testing opportunistic connections</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#12_1_1">Basic OE Test</A></LI>
|
|
<LI><A HREF="#12_1_2">OE Gateway Test</A></LI>
|
|
<LI><A HREF="#12_1_3">Additional OE tests</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#test.uml">Testing with User Mode Linux</A></LI>
|
|
<LI><A HREF="#testnet">Configuration for a testbed network</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#testbed">Testbed network</A></LI>
|
|
<LI><A HREF="#tcpdump.test">Using packet sniffers in testing</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#verify.crypt">Verifying encryption</A></LI>
|
|
<LI><A HREF="#mail.test">Mailing list pointers</A></LI>
|
|
</UL>
|
|
<B><A HREF="#kernelconfig">Kernel configuration for FreeS/WAN</A></B>
|
|
<UL>
|
|
<LI><A HREF="#notall">Not everyone needs to worry about kernel
|
|
configuration</A></LI>
|
|
<LI><A HREF="#assume">Assumptions and notation</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#labels">Labels used</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#kernelopt">Kernel options for FreeS/WAN</A></LI>
|
|
</UL>
|
|
<B><A HREF="#adv_config">Other configuration possibilities</A></B>
|
|
<UL>
|
|
<LI><A HREF="#thumb">Some rules of thumb about configuration</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#cheap.tunnel">Tunnels are cheap</A></LI>
|
|
<LI><A HREF="#subnet.size">Subnet sizes</A></LI>
|
|
<LI><A HREF="#example.more">Other network layouts</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#internet.subnet">The Internet as a big subnet</A></LI>
|
|
<LI><A HREF="#wireless.config">Wireless</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#choose">Choosing connection types</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#man-auto">Manual vs. automatic keying</A></LI>
|
|
<LI><A HREF="#auto-auth">Authentication methods for auto-keying</A></LI>
|
|
<LI><A HREF="#adv-pk">Advantages of public key methods</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#prodsecrets">Using shared secrets in production</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#secrets">Putting secrets in ipsec.secrets(5)</A></LI>
|
|
<LI><A HREF="#securing.secrets">File security</A></LI>
|
|
<LI><A HREF="#notroadshared">Shared secrets for road warriors</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#prodman">Using manual keying in production</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#ranbits">Creating keys with ranbits</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#boot">Setting up connections at boot time</A></LI>
|
|
<LI><A HREF="#multitunnel">Multiple tunnels between the same two
|
|
gateways</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#advroute">One tunnel plus advanced routing</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#opp.gate">An Opportunistic Gateway</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#14_7_1">Start from full opportunism</A></LI>
|
|
<LI><A HREF="#14_7_2">Reverse DNS TXT records for each protected machine</A>
|
|
</LI>
|
|
<LI><A HREF="#14_7_3">Publish your records</A></LI>
|
|
<LI><A HREF="#14_7_4">...and test them</A></LI>
|
|
<LI><A HREF="#14_7_5">No Configuration Needed</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#extruded.config">Extruded Subnets</A></LI>
|
|
<LI><A HREF="#roadvirt">Road Warrior with virtual IP address</A></LI>
|
|
<LI><A HREF="#dynamic">Dynamic Network Interfaces</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#basicdyn">Basics</A></LI>
|
|
<LI><A HREF="#bootdyn">Boot Time</A></LI>
|
|
<LI><A HREF="#changedyn">Change Time</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#unencrypted">Unencrypted tunnels</A></LI>
|
|
</UL>
|
|
<B><A HREF="#install">Installing FreeS/WAN</A></B>
|
|
<UL>
|
|
<LI><A HREF="#15_1">Requirements</A></LI>
|
|
<LI><A HREF="#15_2">Choose your install method</A></LI>
|
|
<LI><A HREF="#15_3">FreeS/WAN ships with some Linuxes</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#15_3_1">FreeS/WAN may be altered...</A></LI>
|
|
<LI><A HREF="#15_3_2">You might need to create an authentication keypair</A>
|
|
</LI>
|
|
<LI><A HREF="#15_3_3">Start and test FreeS/WAN</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#15_4">RPM install</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#15_4_1">Download RPMs</A></LI>
|
|
<LI><A HREF="#15_4_2">For freeswan.org RPMs: check signatures</A></LI>
|
|
<LI><A HREF="#15_4_3">Install the RPMs</A></LI>
|
|
<LI><A HREF="#15_4_4">Start and Test FreeS/WAN</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#15_5">Install from Source</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#15_5_1">Decide what functionality you need</A></LI>
|
|
<LI><A HREF="#15_5_2">Download FreeS/WAN</A></LI>
|
|
<LI><A HREF="#15_5_3">For freeswan.org source: check its signature</A></LI>
|
|
<LI><A HREF="#15_5_4">Untar, unzip</A></LI>
|
|
<LI><A HREF="#15_5_5">Patch if desired</A></LI>
|
|
<LI><A HREF="#15_5_6">... and Make</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#15_5_6_1">Userland-only Install for 2.6 kernels</A></LI>
|
|
<LI><A HREF="#15_5_6_2">KLIPS install for 2.2, 2.4, or 2.6 kernels</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#15_6">Start FreeS/WAN and test your install</A></LI>
|
|
<LI><A HREF="#15_7">Test your install</A></LI>
|
|
<LI><A HREF="#15_8">Making FreeS/WAN play well with others</A></LI>
|
|
<LI><A HREF="#15_9">Configure for your needs</A></LI>
|
|
</UL>
|
|
<B><A HREF="#config">How to configure FreeS/WAN</A></B>
|
|
<UL>
|
|
<LI><A HREF="#16_1">Requirements</A></LI>
|
|
<LI><A HREF="#config.netnet">Net-to-Net connection</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#netnet.info.ex">Gather information</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#16_2_1_1">Get your leftrsasigkey</A></LI>
|
|
<LI><A HREF="#16_2_1_2">...and your rightrsasigkey</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#16_2_2">Edit /etc/ipsec.conf</A></LI>
|
|
<LI><A HREF="#16_2_3">Start your connection</A></LI>
|
|
<LI><A HREF="#16_2_4">Do not MASQ or NAT packets to be tunneled</A></LI>
|
|
<LI><A HREF="#16_2_5">Test your connection</A></LI>
|
|
<LI><A HREF="#16_2_6">Finishing touches</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#config.rw">Road Warrior Configuration</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#rw.info.ex">Gather information</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#16_3_1_1">Get your leftrsasigkey...</A></LI>
|
|
<LI><A HREF="#16_3_1_2">...and your rightrsasigkey</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#16_3_2">Customize /etc/ipsec.conf</A></LI>
|
|
<LI><A HREF="#16_3_3">Start your connection</A></LI>
|
|
<LI><A HREF="#16_3_4">Do not MASQ or NAT packets to be tunneled</A></LI>
|
|
<LI><A HREF="#16_3_5">Test your connection</A></LI>
|
|
<LI><A HREF="#16_3_6">Finishing touches</A></LI>
|
|
<LI><A HREF="#16_3_7">Multiple Road Warriors</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#16_4">What next?</A></LI>
|
|
</UL>
|
|
<B><A HREF="#background">Linux FreeS/WAN background</A></B>
|
|
<UL>
|
|
<LI><A HREF="#dns.background">Some DNS background</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#forward.reverse">Forward and reverse maps</A></LI>
|
|
<LI><A HREF="#17_1_2">Hierarchy and delegation</A></LI>
|
|
<LI><A HREF="#17_1_3">Syntax of DNS records</A></LI>
|
|
<LI><A HREF="#17_1_4">Cacheing, TTL and propagation delay</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#MTU.trouble">Problems with packet fragmentation</A></LI>
|
|
<LI><A HREF="#nat.background">Network address translation (NAT)</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#17_3_1">NAT to non-routable addresses</A></LI>
|
|
<LI><A HREF="#17_3_2">NAT to routable addresses</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#user.examples">FreeS/WAN script examples</A></B>
|
|
<UL>
|
|
<LI><A HREF="#poltorak">Poltorak's Firewall script</A></LI>
|
|
</UL>
|
|
<B><A HREF="#makecheck">How to configure to use "make check"</A></B>
|
|
<UL>
|
|
<LI><A HREF="#19_1">What is "make check"</A></LI>
|
|
<LI><A HREF="#19_2">Running "make check"</A></LI>
|
|
</UL>
|
|
<B><A HREF="#20">How to write a "make check" test</A></B>
|
|
<UL>
|
|
<LI><A HREF="#20_1">Structure of a test</A></LI>
|
|
<LI><A HREF="#20_2">The TESTLIST</A></LI>
|
|
<LI><A HREF="#20_3">Test kinds</A></LI>
|
|
<LI><A HREF="#20_4">Common parameters</A></LI>
|
|
<LI><A HREF="#20_5">KLIPStest paramaters</A></LI>
|
|
<LI><A HREF="#20_6">mkinsttest paramaters</A></LI>
|
|
<LI><A HREF="#20_7">rpm_build_install_test paramaters</A></LI>
|
|
<LI><A HREF="#20_8">libtest paramaters</A></LI>
|
|
<LI><A HREF="#20_9">umlplutotest paramaters</A></LI>
|
|
<LI><A HREF="#20_10">umlXhost parameters</A></LI>
|
|
<LI><A HREF="#20_11">kernel_patch_test paramaters</A></LI>
|
|
<LI><A HREF="#20_12">module_compile paramaters</A></LI>
|
|
</UL>
|
|
<B><A HREF="#21">Current pitfalls</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#umltesting">User-Mode-Linux Testing guide</A></B>
|
|
<UL>
|
|
<LI><A HREF="#22_1">Preliminary Notes on BIND</A></LI>
|
|
<LI><A HREF="#22_2">Steps to Install UML for FreeS/WAN</A></LI>
|
|
</UL>
|
|
<B><A HREF="#23">Debugging the kernel with GDB</A></B>
|
|
<UL>
|
|
<LI><A HREF="#23_1">Other notes about debugging</A></LI>
|
|
</UL>
|
|
<B><A HREF="#24">User-Mode-Linux mysteries</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#25">Getting more info from uml_netjig</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#politics">History and politics of cryptography</A></B>
|
|
<UL>
|
|
<LI><A HREF="#intro.politics">Introduction</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#26_1_1">History</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#26_1_1_1">World War II</A></LI>
|
|
<LI><A HREF="#postwar">Postwar and Cold War</A></LI>
|
|
<LI><A HREF="#recent">Recent history -- the crypto wars</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#intro.poli">Politics</A></LI>
|
|
<LI><A HREF="#26_1_3">Links</A></LI>
|
|
<LI><A HREF="#26_1_4">Outline of this section</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#leader">From our project leader</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#gilmore">Swan: Securing the Internet against Wiretapping</A>
|
|
</LI>
|
|
<UL>
|
|
<LI><A HREF="#26_2_1_1">Deployment of IPSEC</A></LI>
|
|
<LI><A HREF="#26_2_1_2">Current status</A></LI>
|
|
<LI><A HREF="#26_2_1_3">Why?</A></LI>
|
|
<LI><A HREF="#26_2_1_4">What You Can Do</A></LI>
|
|
<LI><A HREF="#26_2_1_5">Related projects</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#policestate">Stopping wholesale monitoring</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#weak">Government promotion of weak crypto</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#escrow">Escrowed encryption</A></LI>
|
|
<LI><A HREF="#shortkeys">Limited key lengths</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#26_3_2_1">Some real trade-offs</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#exlaw">Cryptography Export Laws</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#USlaw">US Law</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#UScontrib">US contributions to FreeS/WAN</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#wrong">What's wrong with restrictions on cryptography</A></LI>
|
|
<LI><A HREF="#Wassenaar">The Wassenaar Arrangement</A></LI>
|
|
<LI><A HREF="#status">Export status of Linux FreeS/WAN</A></LI>
|
|
<LI><A HREF="#help">Help spread IPsec around</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#desnotsecure">DES is Not Secure</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#deshware">Dedicated hardware breaks DES in a few days</A></LI>
|
|
<LI><A HREF="#spooks">Spooks may break DES faster yet</A></LI>
|
|
<LI><A HREF="#desnet">Networks break DES in a few weeks</A></LI>
|
|
<LI><A HREF="#no_des">We disable DES</A></LI>
|
|
<LI><A HREF="#40joke">40-bits is laughably weak</A></LI>
|
|
<LI><A HREF="#altdes">Triple DES is almost certainly secure</A></LI>
|
|
<LI><A HREF="#aes.ipsec">AES in IPsec</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#press">Press coverage of Linux FreeS/WAN:</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#26_6_1">FreeS/WAN 1.0 press</A></LI>
|
|
<LI><A HREF="#release">Press release for version 1.0</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#ipsec.detail">The IPsec protocols</A></B>
|
|
<UL>
|
|
<LI><A HREF="#27_1">Protocols and phases</A></LI>
|
|
<LI><A HREF="#others">Applying IPsec</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#advantages">Advantages of IPsec</A></LI>
|
|
<LI><A HREF="#limitations">Limitations of IPsec</A></LI>
|
|
<LI><A HREF="#uses">IPsec is a general mechanism for securing IP</A></LI>
|
|
<LI><A HREF="#authonly">Using authentication without encryption</A></LI>
|
|
<LI><A HREF="#encnoauth">Encryption without authentication is dangerous</A>
|
|
</LI>
|
|
<LI><A HREF="#multilayer">Multiple layers of IPsec processing are
|
|
possible</A></LI>
|
|
<LI><A HREF="#traffic.resist">Resisting traffic analysis</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#extra">Using "unnecessary" encryption</A></LI>
|
|
<LI><A HREF="#multi-encrypt">Using multiple encryption</A></LI>
|
|
<LI><A HREF="#fewer">Using fewer tunnels</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#primitives">Cryptographic components</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#block.cipher">Block ciphers</A></LI>
|
|
<LI><A HREF="#hash.ipsec">Hash functions</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#hmac.ipsec">The HMAC construct</A></LI>
|
|
<LI><A HREF="#27_3_2_2">Choice of hash algorithm</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#DH.keying">Diffie-Hellman key agreement</A></LI>
|
|
<LI><A HREF="#RSA.auth">RSA authentication</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#structure">Structure of IPsec</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#IKE.ipsec">IKE (Internet Key Exchange)</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#phases">Phases of IKE</A></LI>
|
|
<LI><A HREF="#sequence">Sequence of messages in IKE</A></LI>
|
|
<LI><A HREF="#struct.exchange">Structure of IKE messages</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#services">IPsec Services, AH and ESP</A></LI>
|
|
<LI><A HREF="#AH.ipsec">The Authentication Header (AH)</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#keyed">Keyed MD5 and Keyed SHA</A></LI>
|
|
<LI><A HREF="#sequence">Sequence numbers</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#ESP.ipsec">Encapsulated Security Payload (ESP)</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#modes">IPsec modes</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#tunnel.ipsec">Tunnel mode</A></LI>
|
|
<LI><A HREF="#transport.ipsec">Transport mode</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#parts">FreeS/WAN parts</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#KLIPS.ipsec">KLIPS: Kernel IPsec Support</A></LI>
|
|
<LI><A HREF="#Pluto.ipsec">The Pluto daemon</A></LI>
|
|
<LI><A HREF="#command">The ipsec(8) command</A></LI>
|
|
<LI><A HREF="#ipsec.conf">Linux FreeS/WAN configuration file</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#key">Key management</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#current">Currently Implemented Methods</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#manual">Manual keying</A></LI>
|
|
<LI><A HREF="#auto">Automatic keying</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#notyet">Methods not yet implemented</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#noauth">Unauthenticated key exchange</A></LI>
|
|
<LI><A HREF="#DNS">Key exchange using DNS</A></LI>
|
|
<LI><A HREF="#PKI">Key exchange using a PKI</A></LI>
|
|
<LI><A HREF="#photuris">Photuris</A></LI>
|
|
<LI><A HREF="#skip">SKIP</A></LI>
|
|
</UL>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#lists">Mailing lists and newsgroups</A></B>
|
|
<UL>
|
|
<LI><A HREF="#list.fs">Mailing lists about FreeS/WAN</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#projlist">The project mailing lists</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#which.list">Which list should I use?</A></LI>
|
|
<LI><A HREF="#policy.list">List policies</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#archive">Archives of the lists</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#indexes">Indexes of mailing lists</A></LI>
|
|
<LI><A HREF="#otherlists">Lists for related software and topics</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#28_3_1">Products that include FreeS/WAN</A></LI>
|
|
<LI><A HREF="#linux.lists">Linux mailing lists</A></LI>
|
|
<LI><A HREF="#ietf">Lists for IETF working groups</A></LI>
|
|
<LI><A HREF="#other">Other mailing lists</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#newsgroups">Usenet newsgroups</A></LI>
|
|
</UL>
|
|
<B><A HREF="#weblink">Web links</A></B>
|
|
<UL>
|
|
<LI><A HREF="#freeswan">The Linux FreeS/WAN Project</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#patch">Add-ons and patches for FreeS/WAN</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#29_1_1_1">Current patches</A></LI>
|
|
<LI><A HREF="#29_1_1_2">Older patches</A></LI>
|
|
<LI><A HREF="#VPN.masq">VPN masquerade patches</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#dist">Distributions including FreeS/WAN</A></LI>
|
|
<LI><A HREF="#used">Things FreeS/WAN uses or could use</A></LI>
|
|
<LI><A HREF="#alternatives">Other approaches to VPNs for Linux</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#ipsec.link">The IPsec Protocols</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#general">General IPsec or VPN information</A></LI>
|
|
<LI><A HREF="#overview">IPsec overview documents or slide sets</A></LI>
|
|
<LI><A HREF="#otherlang">IPsec information in languages other than
|
|
English</A></LI>
|
|
<LI><A HREF="#RFCs1">RFCs and other reference documents</A></LI>
|
|
<LI><A HREF="#analysis">Analysis and critiques of IPsec protocols</A></LI>
|
|
<LI><A HREF="#IP.background">Background information on IP</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#implement">IPsec Implementations</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#linuxprod">Linux products</A></LI>
|
|
<LI><A HREF="#router">IPsec in router products</A></LI>
|
|
<LI><A HREF="#fw.web">IPsec in firewall products</A></LI>
|
|
<LI><A HREF="#ipsecos">Operating systems with IPsec support</A></LI>
|
|
<LI><A HREF="#29_3_5">IPsec on network cards</A></LI>
|
|
<LI><A HREF="#opensource">Open source IPsec implementations</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#linuxipsec">Other Linux IPsec implementations</A></LI>
|
|
<LI><A HREF="#BSD">IPsec for BSD Unix</A></LI>
|
|
<LI><A HREF="#misc">IPsec for other systems</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#interop.web">Interoperability</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#result">Interoperability results</A></LI>
|
|
<LI><A HREF="#test1">Interoperability test sites</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<LI><A HREF="#linux.link">Linux links</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#linux.basic">Basic and tutorial Linux information</A></LI>
|
|
<LI><A HREF="#general">General Linux sites</A></LI>
|
|
<LI><A HREF="#docs.ldp">Documentation</A></LI>
|
|
<LI><A HREF="#advroute.web">Advanced routing</A></LI>
|
|
<LI><A HREF="#linsec">Security for Linux</A></LI>
|
|
<LI><A HREF="#firewall.linux">Linux firewalls</A></LI>
|
|
<LI><A HREF="#linux.misc">Miscellaneous Linux information</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#crypto.link">Crypto and security links</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#security">Crypto and security resources</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#std.links">The standard link collections</A></LI>
|
|
<LI><A HREF="#FAQ">Frequently Asked Question (FAQ) documents</A></LI>
|
|
<LI><A HREF="#cryptover">Tutorials</A></LI>
|
|
<LI><A HREF="#standards">Crypto and security standards</A></LI>
|
|
<LI><A HREF="#quotes">Crypto quotes</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#policy">Cryptography law and policy</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#legal">Surveys of crypto law</A></LI>
|
|
<LI><A HREF="#oppose">Organisations opposing crypto restrictions</A></LI>
|
|
<LI><A HREF="#other.policy">Other information on crypto policy</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#crypto.tech">Cryptography technical information</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#cryptolinks">Collections of crypto links</A></LI>
|
|
<LI><A HREF="#papers">Lists of online cryptography papers</A></LI>
|
|
<LI><A HREF="#interesting">Particularly interesting papers</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#compsec">Computer and network security</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#seclink">Security links</A></LI>
|
|
<LI><A HREF="#firewall.web">Firewall links</A></LI>
|
|
<LI><A HREF="#vpn">VPN links</A></LI>
|
|
<LI><A HREF="#tools">Security tools</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#people">Links to home pages</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#ourgloss">Glossary for the Linux FreeS/WAN project</A></B>
|
|
<UL>
|
|
<LI><A HREF="#jump">Jump to a letter in the glossary</A></LI>
|
|
<LI><A HREF="#gloss">Other glossaries</A></LI>
|
|
<LI><A HREF="#definitions">Definitions</A></LI>
|
|
</UL>
|
|
<B><A HREF="#biblio">Bibliography for the Linux FreeS/WAN project</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#RFC">IPsec RFCs and related documents</A></B>
|
|
<UL>
|
|
<LI><A HREF="#RFCfile">The RFCs.tar.gz Distribution File</A></LI>
|
|
<LI><A HREF="#sources">Other sources for RFCs & Internet drafts</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#RFCdown">RFCs</A></LI>
|
|
<LI><A HREF="#drafts">Internet Drafts</A></LI>
|
|
<LI><A HREF="#FIPS1">FIPS standards</A></LI>
|
|
</UL>
|
|
<LI><A HREF="#RFCs.tar.gz">What's in the RFCs.tar.gz bundle?</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#rfc.ov">Overview RFCs</A></LI>
|
|
<LI><A HREF="#basic.prot">Basic protocols</A></LI>
|
|
<LI><A HREF="#key.ike">Key management</A></LI>
|
|
<LI><A HREF="#rfc.detail">Details of various things used</A></LI>
|
|
<LI><A HREF="#rfc.ref">Older RFCs which may be referenced</A></LI>
|
|
<LI><A HREF="#rfc.dns">RFCs for secure DNS service, which IPsec may use</A>
|
|
</LI>
|
|
<LI><A HREF="#rfc.exp">RFCs labelled "experimental"</A></LI>
|
|
<LI><A HREF="#rfc.rel">Related RFCs</A></LI>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#roadmap">Distribution Roadmap: What's Where in Linux
|
|
FreeS/WAN</A></B>
|
|
<UL>
|
|
<LI><A HREF="#top">Top directory</A></LI>
|
|
<LI><A HREF="#doc">Documentation</A></LI>
|
|
<LI><A HREF="#klips.roadmap">KLIPS: kernel IP security</A></LI>
|
|
<LI><A HREF="#pluto.roadmap">Pluto key and connection management daemon</A>
|
|
</LI>
|
|
<LI><A HREF="#utils">Utils</A></LI>
|
|
<LI><A HREF="#lib">Libraries</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#fswanlib">FreeS/WAN Library</A></LI>
|
|
<LI><A HREF="#otherlib">Imported Libraries</A></LI>
|
|
<UL>
|
|
<LI><A HREF="#33_6_2_1">LibDES</A></LI>
|
|
<LI><A HREF="#33_6_2_2">GMP</A></LI>
|
|
</UL>
|
|
</UL>
|
|
</UL>
|
|
<B><A HREF="#umltesting">User-Mode-Linux Testing guide</A></B>
|
|
<UL>
|
|
<LI><A HREF="#34_1">Preliminary Notes on BIND</A></LI>
|
|
<LI><A HREF="#34_2">Steps to Install UML for FreeS/WAN</A></LI>
|
|
</UL>
|
|
<B><A HREF="#35">Debugging the kernel with GDB</A></B>
|
|
<UL>
|
|
<LI><A HREF="#35_1">Other notes about debugging</A></LI>
|
|
</UL>
|
|
<B><A HREF="#36">User-Mode-Linux mysteries</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#37">Getting more info from uml_netjig</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#makecheck">How to configure to use "make check"</A></B>
|
|
<UL>
|
|
<LI><A HREF="#38_1">What is "make check"</A></LI>
|
|
<LI><A HREF="#38_2">Running "make check"</A></LI>
|
|
</UL>
|
|
<B><A HREF="#39">How to write a "make check" test</A></B>
|
|
<UL>
|
|
<LI><A HREF="#39_1">Structure of a test</A></LI>
|
|
<LI><A HREF="#39_2">The TESTLIST</A></LI>
|
|
<LI><A HREF="#39_3">Test kinds</A></LI>
|
|
<LI><A HREF="#39_4">Common parameters</A></LI>
|
|
<LI><A HREF="#39_5">KLIPStest paramaters</A></LI>
|
|
<LI><A HREF="#39_6">mkinsttest paramaters</A></LI>
|
|
<LI><A HREF="#39_7">rpm_build_install_test paramaters</A></LI>
|
|
<LI><A HREF="#39_8">libtest paramaters</A></LI>
|
|
<LI><A HREF="#39_9">umlplutotest paramaters</A></LI>
|
|
<LI><A HREF="#39_10">umlXhost parameters</A></LI>
|
|
<LI><A HREF="#39_11">kernel_patch_test paramaters</A></LI>
|
|
<LI><A HREF="#39_12">module_compile paramaters</A></LI>
|
|
</UL>
|
|
<B><A HREF="#40">Current pitfalls</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#nightly">Nightly regression testing</A></B>
|
|
<BR>
|
|
<BR><B><A HREF="#nightlyhowto">How to setup the nightly build</A></B>
|
|
<UL>
|
|
<LI><A HREF="#42_1"> Files you need to know about</A></LI>
|
|
<LI><A HREF="#42_2">Configuring freeswan-regress-env.sh</A></LI>
|
|
</UL>
|
|
<HR>
|
|
<H1><A name="intro">Introduction</A></H1>
|
|
<P>This section gives an overview of:</P>
|
|
<UL>
|
|
<LI>what IP Security (IPsec) does</LI>
|
|
<LI>how IPsec works</LI>
|
|
<LI>why we are implementing it for Linux</LI>
|
|
<LI>how this implementation works</LI>
|
|
</UL>
|
|
<P>This section is intended to cover only the essentials,<EM> things you
|
|
should know before trying to use FreeS/WAN.</EM></P>
|
|
<P>For more detailed background information, see the<A href="#politics">
|
|
history and politics</A> and<A href="#ipsec.detail"> IPsec protocols</A>
|
|
sections.</P>
|
|
<H2><A name="ipsec.intro">IPsec, Security for the Internet Protocol</A></H2>
|
|
<P>FreeS/WAN is a Linux implementation of the IPsec (IP security)
|
|
protocols. IPsec provides<A href="#encryption"> encryption</A> and<A href="#authentication">
|
|
authentication</A> services at the IP (Internet Protocol) level of the
|
|
network protocol stack.</P>
|
|
<P>Working at this level, IPsec can protect any traffic carried over IP,
|
|
unlike other encryption which generally protects only a particular
|
|
higher-level protocol --<A href="#PGP"> PGP</A> for mail,<A href="#ssh">
|
|
SSH</A> for remote login,<A href="#SSL"> SSL</A> for web work, and so
|
|
on. This approach has both considerable advantages and some
|
|
limitations. For discussion, see our<A href="#others"> IPsec section</A>
|
|
</P>
|
|
<P>IPsec can be used on any machine which does IP networking. Dedicated
|
|
IPsec gateway machines can be installed wherever required to protect
|
|
traffic. IPsec can also run on routers, on firewall machines, on
|
|
various application servers, and on end-user desktop or laptop
|
|
machines.</P>
|
|
<P>Three protocols are used</P>
|
|
<UL>
|
|
<LI><A href="#AH">AH</A> (Authentication Header) provides a packet-level
|
|
authentication service</LI>
|
|
<LI><A href="#ESP">ESP</A> (Encapsulating Security Payload) provides
|
|
encryption plus authentication</LI>
|
|
<LI><A href="#IKE">IKE</A> (Internet Key Exchange) negotiates connection
|
|
parameters, including keys, for the other two</LI>
|
|
</UL>
|
|
<P>Our implementation has three main parts:</P>
|
|
<UL>
|
|
<LI><A href="#KLIPS">KLIPS</A> (kernel IPsec) implements AH, ESP, and
|
|
packet handling within the kernel</LI>
|
|
<LI><A href="#Pluto">Pluto</A> (an IKE daemon) implements IKE,
|
|
negotiating connections with other systems</LI>
|
|
<LI>various scripts provide an adminstrator's interface to the machinery</LI>
|
|
</UL>
|
|
<P>IPsec is optional for the current (version 4) Internet Protocol.
|
|
FreeS/WAN adds IPsec to the Linux IPv4 network stack. Implementations
|
|
of<A href="#ipv6.gloss"> IP version 6</A> are required to include
|
|
IPsec. Work toward integrating FreeS/WAN into the Linux IPv6 stack has<A
|
|
href="#ipv6"> started</A>.</P>
|
|
<P>For more information on IPsec, see our<A href="#ipsec.detail"> IPsec
|
|
protocols</A> section, our collection of<A href="#ipsec.link"> IPsec
|
|
links</A> or the<A href="#RFC"> RFCs</A> which are the official
|
|
definitions of these protocols.</P>
|
|
<H3><A name="intro.interop">Interoperating with other IPsec
|
|
implementations</A></H3>
|
|
<P>IPsec is designed to let different implementations work together. We
|
|
provide:</P>
|
|
<UL>
|
|
<LI>a<A href="#implement"> list</A> of some other implementations</LI>
|
|
<LI>information on<A href="#interop"> using FreeS/WAN with other
|
|
implementations</A></LI>
|
|
</UL>
|
|
<P>The VPN Consortium fosters cooperation among implementers and
|
|
interoperability among implementations. Their<A href="http://www.vpnc.org/">
|
|
web site</A> has much more information.</P>
|
|
<H3><A name="advantages">Advantages of IPsec</A></H3>
|
|
<P>IPsec has a number of security advantages. Here are some
|
|
independently written articles which discuss these:</P>
|
|
<P><A HREF="http://www.sans.org/rr/"> SANS institute papers</A>. See the
|
|
section on Encryption &VPNs.
|
|
<BR><A HREF="http://www.cisco.com/en/US/netsol/ns110/ns170/ns171/ns128/networking_solutions_white_papers_list.html">
|
|
Cisco's white papers on "Networking Solutions"</A>.
|
|
<BR><A HREF="http://iscs.sourceforge.net/HowWhyBrief/HowWhyBrief.html">
|
|
Advantages of ISCS (Linux Integrated Secure Communications System;
|
|
includes FreeS/WAN and other software)</A>.</P>
|
|
<H3><A name="applications">Applications of IPsec</A></H3>
|
|
<P>Because IPsec operates at the network layer, it is remarkably
|
|
flexible and can be used to secure nearly any type of Internet traffic.
|
|
Two applications, however, are extremely widespread:</P>
|
|
<UL>
|
|
<LI>a<A href="#VPN"> Virtual Private Network</A>, or VPN, allows
|
|
multiple sites to communicate securely over an insecure Internet by
|
|
encrypting all communication between the sites.</LI>
|
|
<LI>"Road Warriors" connect to the office from home, or perhaps from a
|
|
hotel somewhere</LI>
|
|
</UL>
|
|
<P>There is enough opportunity in these applications that vendors are
|
|
flocking to them. IPsec is being built into routers, into firewall
|
|
products, and into major operating systems, primarily to support these
|
|
applications. See our<A href="#implement"> list</A> of implementations
|
|
for details.</P>
|
|
<P>We support both of those applications, and various less common IPsec
|
|
applications as well, but we also add one of our own:</P>
|
|
<UL>
|
|
<LI>opportunistic encryption, the ability to set up FreeS/WAN gateways
|
|
so that any two of them can encrypt to each other, and will do so
|
|
whenever packets pass between them.</LI>
|
|
</UL>
|
|
<P>This is an extension we are adding to the protocols. FreeS/WAN is the
|
|
first prototype implementation, though we hope other IPsec
|
|
implementations will adopt the technique once we demonstrate it. See<A href="#goals">
|
|
project goals</A> below for why we think this is important.</P>
|
|
<P>A somewhat more detailed description of each of these applications is
|
|
below. Our<A href="#quick_guide"> quickstart</A> section will show you
|
|
how to build each of them.</P>
|
|
<H4><A name="makeVPN">Using secure tunnels to create a VPN</A></H4>
|
|
<P>A VPN, or<STRONG> V</STRONG>irtual<STRONG> P</STRONG>rivate<STRONG> N</STRONG>
|
|
etwork lets two networks communicate securely when the only connection
|
|
between them is over a third network which they do not trust.</P>
|
|
<P>The method is to put a security gateway machine between each of the
|
|
communicating networks and the untrusted network. The gateway machines
|
|
encrypt packets entering the untrusted net and decrypt packets leaving
|
|
it, creating a secure tunnel through it.</P>
|
|
<P>If the cryptography is strong, the implementation is careful, and the
|
|
administration of the gateways is competent, then one can reasonably
|
|
trust the security of the tunnel. The two networks then behave like a
|
|
single large private network, some of whose links are encrypted tunnels
|
|
through untrusted nets.</P>
|
|
<P>Actual VPNs are often more complex. One organisation may have fifty
|
|
branch offices, plus some suppliers and clients, with whom it needs to
|
|
communicate securely. Another might have 5,000 stores, or 50,000
|
|
point-of-sale devices. The untrusted network need not be the Internet.
|
|
All the same issues arise on a corporate or institutional network
|
|
whenever two departments want to communicate privately with each other.</P>
|
|
<P>Administratively, the nice thing about many VPN setups is that large
|
|
parts of them are static. You know the IP addresses of most of the
|
|
machines involved. More important, you know they will not change on
|
|
you. This simplifies some of the admin work. For cases where the
|
|
addresses do change, see the next section.</P>
|
|
<H4><A name="road.intro">Road Warriors</A></H4>
|
|
<P>The prototypical "Road Warrior" is a traveller connecting to home
|
|
base from a laptop machine. Administratively, most of the same problems
|
|
arise for a telecommuter connecting from home to the office, especially
|
|
if the telecommuter does not have a static IP address.</P>
|
|
<P>For purposes of this document:</P>
|
|
<UL>
|
|
<LI>anyone with a dynamic IP address is a "Road Warrior".</LI>
|
|
<LI>any machine doing IPsec processing is a "gateway". Think of the
|
|
single-user road warrior machine as a gateway with a degenerate subnet
|
|
(one machine, itself) behind it.</LI>
|
|
</UL>
|
|
<P>These require somewhat different setup than VPN gateways with static
|
|
addresses and with client systems behind them, but are basically not
|
|
problematic.</P>
|
|
<P>There are some difficulties which appear for some road warrior
|
|
connections:</P>
|
|
<UL>
|
|
<LI>Road Wariors who get their addresses via DHCP may have a problem.
|
|
FreeS/WAN can quite happily build and use a tunnel to such an address,
|
|
but when the DHCP lease expires, FreeS/WAN does not know that. The
|
|
tunnel fails, and the only recovery method is to tear it down and
|
|
re-build it.</LI>
|
|
<LI>If<A href="#NAT.gloss"> Network Address Translation</A> (NAT) is
|
|
applied between the two IPsec Gateways, this breaks IPsec. IPsec
|
|
authenticates packets on an end-to-end basis, to ensure they are not
|
|
altered en route. NAT rewrites packets as they go by. See our<A href="#NAT">
|
|
firewalls</A> document for details.</LI>
|
|
</UL>
|
|
<P>In most situations, however, FreeS/WAN supports road warrior
|
|
connections just fine.</P>
|
|
<H4><A name="opp.intro">Opportunistic encryption</A></H4>
|
|
<P>One of the reasons we are working on FreeS/WAN is that it gives us
|
|
the opportunity to add what we call opportuntistic encryption. This
|
|
means that any two FreeS/WAN gateways will be able to encrypt their
|
|
traffic, even if the two gateway administrators have had no prior
|
|
contact and neither system has any preset information about the other.</P>
|
|
<P>Both systems pick up the authentication information they need from
|
|
the<A href="#DNS"> DNS</A> (domain name service), the service they
|
|
already use to look up IP addresses. Of course the administrators must
|
|
put that information in the DNS, and must set up their gateways with
|
|
opportunistic encryption enabled. Once that is done, everything is
|
|
automatic. The gateways look for opportunities to encrypt, and encrypt
|
|
whatever they can. Whether they also accept unencrypted communication
|
|
is a policy decision the administrator can make.</P>
|
|
<P>This technique can give two large payoffs:</P>
|
|
<UL>
|
|
<LI>It reduces the administrative overhead for IPsec enormously. You
|
|
configure your gateway and thereafter everything is automatic. The need
|
|
to configure the system on a per-tunnel basis disappears. Of course,
|
|
FreeS/WAN allows specifically configured tunnels to co-exist with
|
|
opportunistic encryption, but we hope to make them unnecessary in most
|
|
cases.</LI>
|
|
<LI>It moves us toward a more secure Internet, allowing users to create
|
|
an environment where message privacy is the default. All messages can
|
|
be encrypted, provided the other end is willing to co-operate. See our<A
|
|
href="#politics"> history and politics of cryptography</A> section for
|
|
discussion of why we think this is needed.</LI>
|
|
</UL>
|
|
<P>Opportunistic encryption is not (yet?) a standard part of the IPsec
|
|
protocols, but an extension we are proposing and demonstrating. For
|
|
details of our design, see<A href="#applied"> links</A> below.</P>
|
|
<P>Only one current product we know of implements a form of
|
|
opportunistic encryption.<A href="#ssmail"> Secure sendmail</A> will
|
|
automatically encrypt server-to-server mail transfers whenever
|
|
possible.</P>
|
|
<H3><A name="types">The need to authenticate gateways</A></H3>
|
|
<P>A complication, which applies to any type of connection -- VPN, Road
|
|
Warrior or opportunistic -- is that a secure connection cannot be
|
|
created magically.<EM> There must be some mechanism which enables the
|
|
gateways to reliably identify each other.</EM> Without this, they
|
|
cannot sensibly trust each other and cannot create a genuinely secure
|
|
link.</P>
|
|
<P>Any link they do create without some form of<A href="#authentication">
|
|
authentication</A> will be vulnerable to a<A href="#middle">
|
|
man-in-the-middle attack</A>. If<A href="#alicebob"> Alice and Bob</A>
|
|
are the people creating the connection, a villian who can re-route or
|
|
intercept the packets can pose as Alice while talking to Bob and pose
|
|
as Bob while talking to Alice. Alice and Bob then both talk to the man
|
|
in the middle, thinking they are talking to each other, and the villain
|
|
gets everything sent on the bogus "secure" connection.</P>
|
|
<P>There are two ways to build links securely, both of which exclude the
|
|
man-in-the middle:</P>
|
|
<UL>
|
|
<LI>with<STRONG> manual keying</STRONG>, Alice and Bob share a secret
|
|
key (which must be transmitted securely, perhaps in a note or via PGP
|
|
or SSH) to encrypt their messages. For FreeS/WAN, such keys are stored
|
|
in the<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> file. Of
|
|
course, if an enemy gets the key, all is lost.</LI>
|
|
<LI>with<STRONG> automatic keying</STRONG>, the two systems authenticate
|
|
each other and negotiate their own secret keys. The keys are
|
|
automatically changed periodically.</LI>
|
|
</UL>
|
|
<P>Automatic keying is much more secure, since if an enemy gets one key
|
|
only messages between the previous re-keying and the next are exposed.
|
|
It is therefore the usual mode of operation for most IPsec deployment,
|
|
and the mode we use in our setup examples. FreeS/WAN does support
|
|
manual keying for special circumstanes. See this<A href="#prodman">
|
|
section</A>.</P>
|
|
<P>For automatic keying, the two systems must authenticate each other
|
|
during the negotiations. There is a choice of methods for this:</P>
|
|
<UL>
|
|
<LI>a<STRONG> shared secret</STRONG> provides authentication. If Alice
|
|
and Bob are the only ones who know a secret and Alice recives a message
|
|
which could not have been created without that secret, then Alice can
|
|
safely believe the message came from Bob.</LI>
|
|
<LI>a<A href="#public"> public key</A> can also provide authentication.
|
|
If Alice receives a message signed with Bob's private key (which of
|
|
course only he should know) and she has a trustworthy copy of his
|
|
public key (so that she can verify the signature), then she can safely
|
|
believe the message came from Bob.</LI>
|
|
</UL>
|
|
<P>Public key techniques are much preferable, for reasons discussed<A href="#choose">
|
|
later</A>, and will be used in all our setup examples. FreeS/WAN does
|
|
also support auto-keying with shared secret authentication. See this<A href="#prodsecrets">
|
|
section</A>.</P>
|
|
<H2><A name="project">The FreeS/WAN project</A></H2>
|
|
<P>For complete information on the project, see our web site,<A href="http://liberty.freeswan.org">
|
|
freeswan.org</A>.</P>
|
|
<P>In summary, we are implementing the<A href="#IPSEC"> IPsec</A>
|
|
protocols for Linux and extending them to do<A href="#carpediem">
|
|
opportunistic encryption</A>.</P>
|
|
<H3><A name="goals">Project goals</A></H3>
|
|
<P>Our overall goal in FreeS/WAN is to make the Internet more secure and
|
|
more private.</P>
|
|
<P>Our IPsec implementation supports VPNs and Road Warriors of course.
|
|
Those are important applications. Many users will want FreeS/WAN to
|
|
build corporate VPNs or to provide secure remote access.</P>
|
|
<P>However, our goals in building it go beyond that. We are trying to
|
|
help<STRONG> build security into the fabric of the Internet</STRONG> so
|
|
that anyone who choses to communicate securely can do so, as easily as
|
|
they can do anything else on the net.</P>
|
|
<P>More detailed objectives are:</P>
|
|
<UL>
|
|
<LI>extend IPsec to do<A href="#carpediem"> opportunistic encryption</A>
|
|
so that
|
|
<UL>
|
|
<LI>any two systems can secure their communications without a
|
|
pre-arranged connection</LI>
|
|
<LI><STRONG>secure connections can be the default</STRONG>, falling back
|
|
to unencrypted connections only if:
|
|
<UL>
|
|
<LI><EM>both</EM> the partner is not set up to co-operate on securing
|
|
the connection</LI>
|
|
<LI><EM>and</EM> your policy allows insecure connections</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>a significant fraction of all Internet traffic is encrypted</LI>
|
|
<LI>wholesale monitoring of the net (<A href="#intro.poli">examples</A>)
|
|
becomes difficult or impossible</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>help make IPsec widespread by providing an implementation with no
|
|
restrictions:
|
|
<UL>
|
|
<LI>freely available in source code under the<A href="#GPL"> GNU General
|
|
Public License</A></LI>
|
|
<LI>running on a range of readily available hardware</LI>
|
|
<LI>not subject to US or other nations'<A href="#exlaw"> export
|
|
restrictions</A>.
|
|
<BR> Note that in order to avoid<EM> even the appearance</EM> of being
|
|
subject to those laws, the project cannot accept software contributions
|
|
--<EM> not even one-line bug fixes</EM> -- from US residents or
|
|
citizens.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>provide a high-quality IPsec implementation for Linux
|
|
<UL>
|
|
<LI>portable to all CPUs Linux supports:<A href="#CPUs"> (current list)</A>
|
|
</LI>
|
|
<LI>interoperable with other IPsec implementations:<A href="#interop">
|
|
(current list)</A></LI>
|
|
</UL>
|
|
</LI>
|
|
</UL>
|
|
<P>If we can get opportunistic encryption implemented and widely
|
|
deployed, then it becomes impossible for even huge well-funded agencies
|
|
to monitor the net.</P>
|
|
<P>See also our section on<A href="#politics"> history and politics</A>
|
|
of cryptography, which includes our project leader's<A href="#gilmore">
|
|
rationale</A> for starting the project.</P>
|
|
<H3><A name="staff">Project team</A></H3>
|
|
<P>Two of the team are from the US and can therefore contribute no code:</P>
|
|
<UL>
|
|
<LI>John Gilmore: founder and policy-maker (<A href="http://www.toad.com/gnu/">
|
|
home page</A>)</LI>
|
|
<LI>Hugh Daniel: project manager, Most Demented Tester, and occasionally
|
|
Pointy-Haired Boss</LI>
|
|
</UL>
|
|
<P>The rest of the team are Canadians, working in Canada. (<A href="#status">
|
|
Why Canada?</A>)</P>
|
|
<UL>
|
|
<LI>Hugh Redelmeier:<A href="#Pluto"> Pluto daemon</A> programmer</LI>
|
|
<LI>Richard Guy Briggs:<A href="#KLIPS"> KLIPS</A> programmer</LI>
|
|
<LI>Michael Richardson: hacker without portfolio</LI>
|
|
<LI>Claudia Schmeing: documentation</LI>
|
|
<LI>Sam Sgro: technical support via the<A href="#lists"> mailing lists</A>
|
|
</LI>
|
|
</UL>
|
|
<P>The project is funded by civil libertarians who consider our goals
|
|
worthwhile. Most of the team are paid for this work.</P>
|
|
<P>People outside this core team have made substantial contributions.
|
|
See</P>
|
|
<UL>
|
|
<LI>our<A href="../CREDITS"> CREDITS</A> file</LI>
|
|
<LI>the<A href="#patch"> patches and add-ons</A> section of our web
|
|
references file</LI>
|
|
<LI>lists below of user-written<A href="#howto"> HowTos</A> and<A href="#applied">
|
|
other papers</A></LI>
|
|
</UL>
|
|
<P>Additional contributions are welcome. See the<A href="#contrib.faq">
|
|
FAQ</A> for details.</P>
|
|
<H2><A name="products">Products containing FreeS/WAN</A></H2>
|
|
<P>Unfortunately the<A href="#exlaw"> export laws</A> of some countries
|
|
restrict the distribution of strong cryptography. FreeS/WAN is
|
|
therefore not in the standard Linux kernel and not in all CD or web
|
|
distributions.</P>
|
|
<P>FreeS/WAN is, however, quite widely used. Products we know of that
|
|
use it are listed below. We would appreciate hearing, via the<A href="#lists">
|
|
mailing lists</A>, of any we don't know of.</P>
|
|
<H3><A name="distwith">Full Linux distributions</A></H3>
|
|
<P>FreeS/WAN is included in various general-purpose Linux distributions,
|
|
mostly from countries (shown in brackets) with more sensible laws:</P>
|
|
<UL>
|
|
<LI><A href="http://www.suse.com/">SuSE Linux</A> (Germany)</LI>
|
|
<LI><A href="http://www.conectiva.com">Conectiva</A> (Brazil)</LI>
|
|
<LI><A href="http://www.linux-mandrake.com/en/">Mandrake</A> (France)</LI>
|
|
<LI><A href="http://www.debian.org">Debian</A></LI>
|
|
<LI>the<A href="http://www.pld.org.pl/"> Polish(ed) Linux Distribution</A>
|
|
(Poland)</LI>
|
|
<LI><A>Best Linux</A> (Finland)</LI>
|
|
</UL>
|
|
<P>For distributions which do not include FreeS/WAN and are not Redhat
|
|
(which we develop and test on), there is additional information in our<A
|
|
href="#otherdist"> compatibility</A> section.</P>
|
|
<P>The server edition of<A href="http://www.corel.com"> Corel</A> Linux
|
|
(Canada) also had FreeS/WAN, but Corel have dropped that product line.</P>
|
|
<H3><A name="kernel_dist">Linux kernel distributions</A></H3>
|
|
<UL>
|
|
<LI><A href="http://sourceforge.net/projects/wolk/">Working Overloaded
|
|
Linux Kernel (WOLK)</A></LI>
|
|
</UL>
|
|
<H3><A name="office_dist">Office server distributions</A></H3>
|
|
<P>FreeS/WAN is also included in several distributions aimed at the
|
|
market for turnkey business servers:</P>
|
|
<UL>
|
|
<LI><A href="http://www.e-smith.com/">e-Smith</A> (Canada), which has
|
|
recently been acquired and become the Network Server Solutions group of<A
|
|
href="http://www.mitel.com/"> Mitel Networks</A> (Canada)</LI>
|
|
<LI><A href="http://www.clarkconnect.org/">ClarkConnect</A> from Point
|
|
Clark Networks (Canada)</LI>
|
|
<LI><A href="http://www.trustix.net/">Trustix Secure Linux</A> (Norway)</LI>
|
|
</UL>
|
|
<H3><A name="fw_dist">Firewall distributions</A></H3>
|
|
<P>Several distributions intended for firewall and router applications
|
|
include FreeS/WAN:</P>
|
|
<UL>
|
|
<LI>The<A href="http://www.linuxrouter.org/"> Linux Router Project</A>
|
|
produces a Linux distribution that will boot from a single floppy. The<A
|
|
href="http://leaf.sourceforge.net"> LEAF</A> firewall project provides
|
|
several different LRP-based firewall packages. At least one of them,
|
|
Charles Steinkuehler's Dachstein, includes FreeS/WAN with X.509
|
|
patches.</LI>
|
|
<LI>there are several distributions bootable directly from CD-ROM,
|
|
usable on a machine without hard disk.
|
|
<UL>
|
|
<LI>Dachstein (see above) can be used this way</LI>
|
|
<LI><A href="http://www.gibraltar.at/">Gibraltar</A> is based on Debian
|
|
GNU/Linux.</LI>
|
|
<LI>at time of writing,<A href="www.xiloo.com"> Xiloo</A> is available
|
|
only in Chinese. An English version is expected.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="http://www.astaro.com/products/index.html">Astaro Security
|
|
Linux</A> includes FreeS/WAN. It has some web-based tools for managing
|
|
the firewall that include FreeS/WAN configuration management.</LI>
|
|
<LI><A href="http://www.linuxwall.de">Linuxwall</A></LI>
|
|
<LI><A href="http://www.smoothwall.org/">Smoothwall</A></LI>
|
|
<LI><A href="http://www.devil-linux.org/">Devil Linux</A></LI>
|
|
<LI>Coyote Linux has a<A href="http://embedded.coyotelinux.com/wolverine/index.php">
|
|
Wolverine</A> firewall/VPN server</LI>
|
|
</UL>
|
|
<P>There are also several sets of scripts available for managing a
|
|
firewall which is also acting as a FreeS/WAN IPsec gateway. See this<A href="#rules.pub">
|
|
list</A>.</P>
|
|
<H3><A name="turnkey">Firewall and VPN products</A></H3>
|
|
<P>Several vendors use FreeS/WAN as the IPsec component of a turnkey
|
|
firewall or VPN product.</P>
|
|
<P>Software-only products:</P>
|
|
<UL>
|
|
<LI><A href="http://www.linuxmagic.com/vpn/index.html">Linux Magic</A>
|
|
offer a VPN/Firewall product using FreeS/WAN</LI>
|
|
<LI>The Software Group's<A href="http://www.wanware.com/sentinet/">
|
|
Sentinet</A> product uses FreeS/WAN</LI>
|
|
<LI><A href="http://www.merilus.com">Merilus</A> use FreeS/WAN in their
|
|
Gateway Guardian firewall product</LI>
|
|
</UL>
|
|
<P>Products that include the hardware:</P>
|
|
<UL>
|
|
<LI>The<A href="http://www.lasat.com"> LASAT SafePipe[tm]</A> series. is
|
|
an IPsec box based on an embedded MIPS running Linux with FreeS/WAN and
|
|
a web-config front end. This company also host our freeswan.org web
|
|
site.</LI>
|
|
<LI>Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
|
|
Firecard</A> is a Linux firewall on a PCI card.</LI>
|
|
<LI><A href="http://www.kyzo.com/">Kyzo</A> have a "pizza box" product
|
|
line with various types of server, all running from flash. One of them
|
|
is an IPsec/PPTP VPN server</LI>
|
|
<LI><A href="http://www.pfn.com">PFN</A> use FreeS/WAN in some of their
|
|
products</LI>
|
|
</UL>
|
|
<P><A href="www.rebel.com">Rebel.com</A>, makers of the Netwinder Linux
|
|
machines (ARM or Crusoe based), had a product that used FreeS/WAN. The
|
|
company is in receivership so the future of the Netwinder is at best
|
|
unclear.<A href="#patch"> PKIX patches</A> for FreeS/WAN developed at
|
|
Rebel are listed in our web links document.</P>
|
|
<H2><A name="docs">Information sources</A></H2>
|
|
<H3><A name="docformats">This HowTo, in multiple formats</A></H3>
|
|
<P>FreeS/WAN documentation up to version 1.5 was available only in HTML.
|
|
Now we ship two formats:</P>
|
|
<UL>
|
|
<LI>as HTML, one file for each doc section plus a global<A href="toc.html">
|
|
Table of Contents</A></LI>
|
|
<LI><A href="HowTo.html">one big HTML file</A> for easy searching</LI>
|
|
</UL>
|
|
<P>and provide a Makefile to generate other formats if required:</P>
|
|
<UL>
|
|
<LI><A href="HowTo.pdf">PDF</A></LI>
|
|
<LI><A href="HowTo.ps">Postscript</A></LI>
|
|
<LI><A href="HowTo.txt">ASCII text</A></LI>
|
|
</UL>
|
|
<P>The Makefile assumes the htmldoc tool is available. You can download
|
|
it from<A href="http://www.easysw.com"> Easy Software</A>.</P>
|
|
<P>All formats should be available at the following websites:</P>
|
|
<UL>
|
|
<LI><A href="http://www.freeswan.org/doc.html">FreeS/WAN project</A></LI>
|
|
<LI><A href="http://www.linuxdoc.org">Linux Documentation Project</A></LI>
|
|
</UL>
|
|
<P>The distribution tarball has only the two HTML formats.</P>
|
|
<P><STRONG>Note:</STRONG> If you need the latest doc version, for
|
|
example to see if anyone has managed to set up interoperation between
|
|
FreeS/WAN and whatever, then you should download the current snapshot.
|
|
What is on the web is documentation as of the last release. Snapshots
|
|
have all changes I've checked in to date.</P>
|
|
<H3><A name="rtfm">RTFM (please Read The Fine Manuals)</A></H3>
|
|
<P>As with most things on any Unix-like system, most parts of Linux
|
|
FreeS/WAN are documented in online manual pages. We provide a list of<A href="/mnt/floppy/manpages.html">
|
|
FreeS/WAN man pages</A>, with links to HTML versions of them.</P>
|
|
<P>The man pages describing configuration files are:</P>
|
|
<UL>
|
|
<LI><A href="/mnt/floppy/manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></LI>
|
|
<LI><A href="/mnt/floppy/manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets(5)</A></LI>
|
|
</UL>
|
|
<P>Man pages for common commands include:</P>
|
|
<UL>
|
|
<LI><A href="/mnt/floppy/manpage.d/ipsec.8.html">ipsec(8)</A></LI>
|
|
<LI><A href="/mnt/floppy/manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</A>
|
|
</LI>
|
|
<LI><A href="/mnt/floppy/manpage.d/ipsec_newhostkey.8.html">
|
|
ipsec_newhostkey(8)</A></LI>
|
|
<LI><A href="/mnt/floppy/manpage.d/ipsec_auto.8.html">ipsec_auto(8)</A></LI>
|
|
</UL>
|
|
<P>You can read these either in HTML using the links above or with the<VAR>
|
|
man(1)</VAR> command.</P>
|
|
<P>In the event of disagreement between this HTML documentation and the
|
|
man pages, the man pages are more likely correct since they are written
|
|
by the implementers. Please report any such inconsistency on the<A href="#lists">
|
|
mailing list</A>.</P>
|
|
<H3><A name="text">Other documents in the distribution</A></H3>
|
|
<P>Text files in the main distribution directory are README, INSTALL,
|
|
CREDITS, CHANGES, BUGS and COPYING.</P>
|
|
<P>The Libdes encryption library we use has its own documentation. You
|
|
can find it in the library directory..</P>
|
|
<H3><A name="assumptions">Background material</A></H3>
|
|
<P>Throughout this documentation, I write as if the reader had at least
|
|
a general familiarity with Linux, with Internet Protocol networking,
|
|
and with the basic ideas of system and network security. Of course that
|
|
will certainly not be true for all readers, and quite likely not even
|
|
for a majority.</P>
|
|
<P>However, I must limit amount of detail on these topics in the main
|
|
text. For one thing, I don't understand all the details of those topics
|
|
myself. Even if I did, trying to explain everything here would produce
|
|
extremely long and almost completely unreadable documentation.</P>
|
|
<P>If one or more of those areas is unknown territory for you, there are
|
|
plenty of other resources you could look at:</P>
|
|
<DL>
|
|
<DT>Linux</DT>
|
|
<DD>the<A href="http://www.linuxdoc.org"> Linux Documentation Project</A>
|
|
or a local<A href="http://www.linux.org/groups/"> Linux User Group</A>
|
|
and these<A href="#linux.link"> links</A></DD>
|
|
<DT>IP networks</DT>
|
|
<DD>Rusty Russell's<A href="http://netfilter.samba.org/unreliable-guides/networking-concepts-HOWTO/index.html">
|
|
Networking Concepts HowTo</A> and these<A href="#IP.background"> links</A>
|
|
</DD>
|
|
<DT>Security</DT>
|
|
<DD>Schneier's book<A href="#secrets"> Secrets and Lies</A> and these<A href="#crypto.link">
|
|
links</A></DD>
|
|
</DL>
|
|
<P>Also, I do make an effort to provide some background material in
|
|
these documents. All the basic ideas behind IPsec and FreeS/WAN are
|
|
explained here. Explanations that do not fit in the main text, or that
|
|
not everyone will need, are often in the<A href="#ourgloss"> glossary</A>
|
|
, which is the largest single file in this document set. There is also a<A
|
|
href="#background"> background</A> file containing various explanations
|
|
too long to fit in glossary definitions. All files are heavily
|
|
sprinkled with links to each other and to the glossary.<STRONG> If some
|
|
passage makes no sense to you, try the links</STRONG>.</P>
|
|
<P>For other reference material, see the<A href="#biblio"> bibliography</A>
|
|
and our collection of<A href="web.html#weblinks"> web links</A>.</P>
|
|
<P>Of course, no doubt I get this (and other things) wrong sometimes.
|
|
Feedback via the<A href="#lists"> mailing lists</A> is welcome.</P>
|
|
<H3><A name="archives">Archives of the project mailing list</A></H3>
|
|
<P>Until quite recently, there was only one FreeS/WAN mailing list, and
|
|
archives of it were:</P>
|
|
<UL>
|
|
<LI><A href="http://www.sandelman.ottawa.on.ca/linux-ipsec">Canada</A></LI>
|
|
<LI><A href="http://www.nexial.com">Holland</A></LI>
|
|
</UL>
|
|
The two archives use completely different search engines. You might
|
|
want to try both.
|
|
<P>More recently we have expanded to five lists, each with its own
|
|
archive.</P>
|
|
<P><A href="#lists">More information</A> on mailing lists.</P>
|
|
<H3><A name="howto">User-written HowTo information</A></H3>
|
|
<P>Various user-written HowTo documents are available. The ones covering
|
|
FreeS/WAN-to-FreeS/WAN connections are:</P>
|
|
<UL>
|
|
<LI>Jean-Francois Nadeau's<A href="http://jixen.tripod.com/"> practical
|
|
configurations</A> document</LI>
|
|
<LI>Jens Zerbst's HowTo on<A href="http://dynipsec.tripod.com/"> Using
|
|
FreeS/WAN with dynamic IP addresses</A>.</LI>
|
|
<LI>an entry in Kurt Seifried's<A href="http://www.securityportal.com/lskb/kben00000013.html">
|
|
Linux Security Knowledge Base</A>.</LI>
|
|
<LI>a section of David Ranch's<A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
|
|
Trinity OS Guide</A></LI>
|
|
<LI>a section in David Bander's book<A href="#bander"> Linux Security
|
|
Toolkit</A></LI>
|
|
</UL>
|
|
<P>User-wriiten HowTo material may be<STRONG> especially helpful if you
|
|
need to interoperate with another IPsec implementation</STRONG>. We
|
|
have neither the equipment nor the manpower to test such
|
|
configurations. Users seem to be doing an admirable job of filling the
|
|
gaps.</P>
|
|
<UL>
|
|
<LI>list of user-written<A href="interop.html#otherpub"> interoperation
|
|
HowTos</A> in our interop document</LI>
|
|
</UL>
|
|
<P>Check what version of FreeS/WAN user-written documents cover. The
|
|
software is under active development and the current version may be
|
|
significantly different from what an older document describes.</P>
|
|
<H3><A name="applied">Papers on FreeS/WAN</A></H3>
|
|
<P>Two design documents show team thinking on new developments:</P>
|
|
<UL>
|
|
<LI><A href="opportunism.spec">Opportunistic Encryption</A> by technical
|
|
lead Henry Spencer and Pluto programmer Hugh Redelemeier</LI>
|
|
<LI>discussion of<A href="http://www.sandelman.ottawa.on.ca/SSW/freeswan/klips2req/">
|
|
KLIPS redesign</A></LI>
|
|
</UL>
|
|
<P>Both documents are works in progress and are frequently revised. For
|
|
the latest version, see the<A href="#lists"> design mailing list</A>.
|
|
Comments should go to that list.</P>
|
|
<P>There is now an<A href="http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-06.txt">
|
|
Internet Draft on Opportunistic Encryption</A> by Michael Richardson,
|
|
Hugh Redelmeier and Henry Spencer. This is a first step toward getting
|
|
the protocol standardised so there can be multiple implementations of
|
|
it. Discussion of it takes place on the<A href="http://www.ietf.org/html.charters/ipsec-charter.html">
|
|
IETF IPsec Working Group</A> mailing list.</P>
|
|
<P>A number of papers giving further background on FreeS/WAN, or
|
|
exploring its future or its applications, are also available:</P>
|
|
<UL>
|
|
<LI>Both Henry and Richard gave talks on FreeS/WAN at the 2000<A href="http://www.linuxsymposium.org">
|
|
Ottawa Linux Symposium</A>.
|
|
<UL>
|
|
<LI>Richard's<A href="http://www.conscoop.ottawa.on.ca/rgb/freeswan/ols2k/">
|
|
slides</A></LI>
|
|
<LI>Henry's paper</LI>
|
|
<LI>MP3 audio of their talks is available from the<A href="http://www.linuxsymposium.org/">
|
|
conference page</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><CITE>Moat: A Virtual Private Network Appliances and Services
|
|
Platform</CITE> is a paper about large-scale (a few 100 links) use of
|
|
FreeS/WAN in a production application at AT&T Research. It is available
|
|
in Postscript or PDF from co-author Steve Bellovin's<A href="http://www.research.att.com/~smb/papers/index.html">
|
|
papers list page</A>.</LI>
|
|
<LI>One of the Moat co-authors, John Denker, has also written
|
|
<UL>
|
|
<LI>a<A href="http://www.av8n.com/vpn/ipsec+routing.htm"> proposal</A>
|
|
for how future versions of FreeS/WAN might interact with routing
|
|
protocols</LI>
|
|
<LI>a<A href="http://www.av8n.com/vpn/wishlist.htm"> wishlist</A> of
|
|
possible new features</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Bart Trojanowski's web page has a draft design for<A href="http://www.jukie.net/~bart/linux-ipsec/">
|
|
hardware acceleration</A> of FreeS/WAN</LI>
|
|
</UL>
|
|
<P>Several of these provoked interesting discussions on the mailing
|
|
lists, worth searching for in the<A href="#archive"> archives</A>.</P>
|
|
<P>There are also several papers in languages other than English, see
|
|
our<A href="#otherlang"> web links</A>.</P>
|
|
<H3><A name="licensing">License and copyright information</A></H3>
|
|
<P>All code and documentation written for this project is distributed
|
|
under either the GNU General Public License (<A href="#GPL">GPL</A>) or
|
|
the GNU Library General Public License. For details see the COPYING
|
|
file in the distribution.</P>
|
|
<P>Not all code in the distribution is ours, however. See the CREDITS
|
|
file for details. In particular, note that the<A href="#LIBDES"> Libdes</A>
|
|
library and the version of<A href="#MD5"> MD5</A> that we use each have
|
|
their own license.</P>
|
|
<H2><A name="sites">Distribution sites</A></H2>
|
|
<P>FreeS/WAN is available from a number of sites.</P>
|
|
<H3><A NAME="1_5_1">Primary site</A></H3>
|
|
<P>Our primary site, is at xs4all (Thanks, folks!) in Holland:</P>
|
|
<UL>
|
|
<LI><A href="http://www.xs4all.nl/~freeswan">HTTP</A></LI>
|
|
<LI><A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan">FTP</A></LI>
|
|
</UL>
|
|
<H3><A name="mirrors">Mirrors</A></H3>
|
|
<P>There are also mirror sites all over the world:</P>
|
|
<UL>
|
|
<LI><A href="http://www.flora.org/freeswan">Eastern Canada</A> (limited
|
|
resouces)</LI>
|
|
<LI><A href="ftp://ludwig.doculink.com/pub/freeswan/">Eastern Canada</A>
|
|
(has older versions too)</LI>
|
|
<LI><A href="ftp://ntsc.notBSD.org/pub/crypto/freeswan/">Eastern Canada</A>
|
|
(has older versions too)</LI>
|
|
<LI><A href="ftp://ftp.kame.net/pub/freeswan/">Japan</A></LI>
|
|
<LI><A href="ftp://ftp.futuredynamics.com/freecrypto/FreeSWAN/">Hong
|
|
Kong</A></LI>
|
|
<LI><A href="ftp://ipsec.dk/pub/freeswan/">Denmark</A></LI>
|
|
<LI><A href="ftp://ftp.net.lut.ac.uk/freeswan">the UK</A></LI>
|
|
<LI><A href="http://storm.alert.sk/comp/mirrors/freeswan/">Slovak
|
|
Republic</A></LI>
|
|
<LI><A href="http://the.wiretapped.net/security/vpn-tunnelling/freeswan/">
|
|
Australia</A></LI>
|
|
<LI><A href="http://freeswan.technolust.cx/">technolust</A></LI>
|
|
<LI><A href="http://freeswan.devguide.de/">Germany</A></LI>
|
|
<LI>Ivan Moore's<A href="http://snowcrash.tdyc.com/freeswan/"> site</A></LI>
|
|
<LI>the<A href="http://www.cryptoarchive.net/"> Crypto Archive</A> on
|
|
the<A href="http://www.securityportal.com/"> Security Portal</A> site</LI>
|
|
<LI><A href="http://www.wiretapped.net/">Wiretapped.net</A> in Australia</LI>
|
|
</UL>
|
|
<P>Thanks to those folks as well.</P>
|
|
<H3><A name="munitions">The "munitions" archive of Linux crypto software</A>
|
|
</H3>
|
|
<P>There is also an archive of Linux crypto software called "munitions",
|
|
with its own mirrors in a number of countries. It includes FreeS/WAN,
|
|
though not always the latest version. Some of its sites are:</P>
|
|
<UL>
|
|
<LI><A href="http://munitions.vipul.net/">Germany</A></LI>
|
|
<LI><A href="http://munitions.iglu.cjb.net/">Italy</A></LI>
|
|
<LI><A href="http://munitions2.xs4all.nl/">Netherlands</A></LI>
|
|
</UL>
|
|
<P>Any of those will have a list of other "munitions" mirrors. There is
|
|
also a CD available.</P>
|
|
<H2><A NAME="1_6">Links to other sections</A></H2>
|
|
<P>For more detailed background information, see:</P>
|
|
<UL>
|
|
<LI><A href="#politics">history and politics</A> of cryptography</LI>
|
|
<LI><A href="#ipsec.detail">IPsec protocols</A></LI>
|
|
</UL>
|
|
<P>To begin working with FreeS/WAN, go to our<A href="quickstart.html#quick.guide">
|
|
quickstart</A> guide.</P>
|
|
<HR>
|
|
<A NAME="upgrading"></A>
|
|
<H1><A NAME="2">Upgrading to FreeS/WAN 2.x</A></H1>
|
|
<H2><A NAME="2_1">New! Built in Opportunistic connections</A></H2>
|
|
<P>Out of the box, FreeS/WAN 2.x will attempt to encrypt all your IP
|
|
traffic. It will try to establish IPsec connections for:</P>
|
|
<UL>
|
|
<LI> IP traffic from the Linux box on which you have installed
|
|
FreeS/WAN, and</LI>
|
|
<LI> outbound IP traffic routed through that Linux box (eg. from a
|
|
protected subnet).</LI>
|
|
</UL>
|
|
<P>FreeS/WAN 2.x uses<STRONG> hidden, automatically enabled<VAR>
|
|
ipsec.conf</VAR> connections</STRONG> to do this.</P>
|
|
<P>This behaviour is part of our campaign to get Opportunistic
|
|
Encryption (OE) widespread in the Linux world, so that any two Linux
|
|
boxes can encrypt to one another without prearrangement. There's one
|
|
catch, however: you must<A HREF="#quickstart"> set up a few DNS records</A>
|
|
to distribute RSA public keys and (if applicable) IPsec gateway
|
|
information.</P>
|
|
<P>If you start FreeS/WAN before you have set up these DNS records, your
|
|
connectivity will be slow, and messages relating to the built in
|
|
connections will clutter your logs. If you are unable to set up DNS for
|
|
OE, you will wish to<A HREF="#disable_policygroups"> disable the hidden
|
|
connections</A>.</P>
|
|
<A NAME="upgrading.flagday"></A>
|
|
<H3><A NAME="2_1_1">Upgrading Opportunistic Encryption to 2.01 (or
|
|
later)</A></H3>
|
|
<P>As of FreeS/WAN 2.01, Opportunistic Encryption (OE) uses DNS TXT
|
|
resource records (RRs) only (rather than TXT with KEY). This change
|
|
causes a "flag day". Users of FreeS/WAN 2.00 (or earlier) OE who are
|
|
upgrading may need to post additional resource records.</P>
|
|
<P>If you are running<A HREF="#initiate-only"> initiate-only OE</A>, you<EM>
|
|
must</EM> put up a TXT record in any forward domain as per our<A HREF="#opp.client">
|
|
quickstart instructions</A>. This replaces your old forward KEY.</P>
|
|
<P> If you are running full OE, you require no updates. You already have
|
|
the needed TXT record in the reverse domain. However, to facilitate
|
|
future features, you may also wish to publish that TXT record in a
|
|
forward domain as instructed<A HREF="#opp.incoming"> here</A>.</P>
|
|
<P>If you are running OE on a gateway (and encrypting on behalf of
|
|
subnetted boxes) you require no updates. You already have the required
|
|
TXT record in your gateway's reverse map, and the TXT records for any
|
|
subnetted boxes require no updating. However, to facilitate future
|
|
features, you may wish to publish your gateway's TXT record in a
|
|
forward domain as shown<A HREF="#opp.incoming"> here</A>.</P>
|
|
<P> During the transition, you may wish to leave any old KEY records up
|
|
for some time. They will provide limited backward compatibility.
|
|
<!--
|
|
For more
|
|
detail on that compatibility, see <A HREF="oe.known-issues">Known Issues with
|
|
OE</A>.
|
|
-->
|
|
</P>
|
|
<H2><A NAME="2_2">New! Policy Groups</A></H2>
|
|
<P>We want to make it easy for you to declare security policy as it
|
|
applies to IPsec connections.</P>
|
|
<P>Policy Groups make it simple to say:</P>
|
|
<UL>
|
|
<LI>These are the folks I want to talk to in the clear.</LI>
|
|
<LI>These spammers' domains -- I don't want to talk to them at all.</LI>
|
|
<LI>To talk to the finance department, I must use IPsec.</LI>
|
|
<LI>For any other communication, try to encrypt, but it's okay if we
|
|
can't.</LI>
|
|
</UL>
|
|
<P>FreeS/WAN then implements these policies, creating OE connections if
|
|
and when needed. You can use Policy Groups along with connections you
|
|
explicitly define in ipsec.conf.</P>
|
|
<P>For more information, see our<A HREF="policygroups.html"> Policy
|
|
Group HOWTO</A>.</P>
|
|
<H2><A NAME="2_3">New! Packetdefault Connection</A></H2>
|
|
<P>Free/SWAN 2.x ships with the<STRONG> automatically enabled, hidden
|
|
connection</STRONG><VAR> packetdefault</VAR>. This configures a
|
|
FreeS/WAN box as an OE gateway for any hosts located behind it. As
|
|
mentioned above, you must configure some<A HREF="quickstart.html"> DNS
|
|
records</A> for OE to work.</P>
|
|
<P>As the name implies, this connection functions as a default. If you
|
|
have more specific connections, such as policy groups which configure
|
|
your FreeS/WAN box as an OE gateway for a local subnet, these will
|
|
apply before<VAR> packetdefault</VAR>. You can view<VAR> packetdefault</VAR>
|
|
's specifics in<A HREF="manpage.d/ipsec.conf.5.html"> man ipsec.conf</A>
|
|
.</P>
|
|
<H2><A NAME="2_4">FreeS/WAN now disables Reverse Path Filtering</A></H2>
|
|
<P>FreeS/WAN often doesn't work with reverse path filtering. At start
|
|
time, FreeS/WAN now turns rp_filter off, and logs a warning.</P>
|
|
<P>FreeS/WAN does not turn it back on again. You can do this yourself
|
|
with a command like:</P>
|
|
<PRE> echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter</PRE>
|
|
<P>For eth0, substitute the interface which FreeS/WAN was affecting.</P>
|
|
<A NAME="ipsec.conf_v2"></A>
|
|
<H2><A NAME="2_5">Revised<VAR> ipsec.conf</VAR></A></H2>
|
|
<H3><A NAME="2_5_1">No promise of compatibility</A></H3>
|
|
<P>The FreeS/WAN team promised config-file compatibility throughout the
|
|
1.x series. That means a 1.5 config file can be directly imported into
|
|
a fresh 1.99 install with no problems.</P>
|
|
<P>With FreeS/WAN 2.x, we've given ourselves permission to make the
|
|
config file easier to use. The cost: some FreeS/WAN 1.x configurations
|
|
will not work properly. Many of the new features are, however, backward
|
|
compatible.</P>
|
|
<H3><A NAME="2_5_2">Most<VAR> ipsec.conf</VAR> files will work fine</A></H3>
|
|
<P>... so long as you paste this line,<STRONG> with no preceding
|
|
whitespace</STRONG>, at the top of your config file:</P>
|
|
<PRE> version 2</PRE>
|
|
<H3><A NAME="2_5_3">Backward compatibility patch</A></H3>
|
|
<P>If the new defaults bite you, use<A HREF="ipsec.conf.2_to_1"> this<VAR>
|
|
ipsec.conf</VAR> fragment</A> to simulate the old default values.</P>
|
|
<H3><A NAME="2_5_4">Details</A></H3>
|
|
<P> We've obsoleted various directives which almost no one was using:</P>
|
|
<PRE> dump
|
|
plutobackgroundload
|
|
no_eroute_pass
|
|
lifetime
|
|
rekeystart
|
|
rekeytries</PRE>
|
|
<P>For most of these, there is some other way to elicit the desired
|
|
behaviour. See<A HREF="http://lists.freeswan.org/pipermail/design/2002-August/003243.html">
|
|
this post</A>.</P>
|
|
<P> We've made some settings, which almost everyone was using, defaults.
|
|
For example:</P>
|
|
<PRE> interfaces=%defaultroute
|
|
plutoload=%search
|
|
plutostart=%search
|
|
uniqueids=yes</PRE>
|
|
<P>We've also changed some default values to help with OE and Policy
|
|
Groups:</P>
|
|
<PRE> authby=rsasig ## not secret!!!
|
|
leftrsasigkey=%dnsondemand ## looks up missing keys in DNS when needed.
|
|
rightrsasigkey=%dnsondemand</PRE>
|
|
<P> Of course, you can still override any defaults by explictly
|
|
declaring something else in your connection.</P>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/design/2002-August/003243.html">
|
|
A post with a list of many ipsec.conf changes.</A>
|
|
<BR><A HREF="manpage.d/ipsec.conf.5.html"> Current ipsec.conf manual.</A>
|
|
</P>
|
|
<A NAME="upgrading.rpms"></A>
|
|
<H3><A NAME="2_5_5">Upgrading from 1.x RPMs to 2.x RPMs</A></H3>
|
|
<P>Note: When upgrading from 1-series to 2-series RPMs,<VAR> rpm -U</VAR>
|
|
will not work.</P>
|
|
<P>You must instead erase the 1.x RPMs, then install the 2.x set:</P>
|
|
<PRE> rpm -e freeswan</PRE>
|
|
<PRE> rpm -e freeswan-module</PRE>
|
|
<P>On erasing, your old<VAR> ipsec.conf</VAR> should be moved to<VAR>
|
|
ipsec.conf.rpmsave</VAR>. Keep this. You will probably want to copy
|
|
your existing connections to the end of your new 2.x file.</P>
|
|
<P>Install the RPMs suitable for your kernel version, such as:</P>
|
|
<PRE> rpm -ivh freeswan-module-2.04_2.4.20_20.9-0.i386.rpm</PRE>
|
|
<PRE> rpm -ivh freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm</PRE>
|
|
<P>Or, to splice the files:</P>
|
|
<PRE> cat /etc/ipsec.conf /etc/ipsec.conf.rpmsave > /etc/ipsec.conf.tmp
|
|
mv /etc/ipsec.conf.tmp /etc/ipsec.conf</PRE>
|
|
<P>Then, remove the redundant<VAR> conn %default</VAR> and<VAR> config
|
|
setup</VAR> sections. Unless you have done any special configuring
|
|
here, you'll likely want to remove the 1.x versions. Remove<VAR> conn
|
|
OEself</VAR>, if present.</P>
|
|
<HR>
|
|
<H1><A name="quickstart">Quickstart Guide to Opportunistic Encryption</A>
|
|
</H1>
|
|
<A name="quick_guide"></A>
|
|
<H2><A name="opp.setup">Purpose</A></H2>
|
|
<P>This page will get you started using Linux FreeS/WAN with
|
|
opportunistic encryption (OE). OE enables you to set up IPsec tunnels
|
|
without co-ordinating with another site administrator, and without hand
|
|
configuring each tunnel. If enough sites support OE, a "FAX effect"
|
|
occurs, and many of us can communicate without eavesdroppers.</P>
|
|
<H3><A NAME="3_1_1">OE "flag day"</A></H3>
|
|
<P>As of FreeS/WAN 2.01, OE uses DNS TXT resource records (RRs) only
|
|
(rather than TXT with KEY). This change causes a<A href="http://jargon.watson-net.com/jargon.asp?w=flag+day">
|
|
"flag day"</A>. Users of FreeS/WAN 2.00 (or earlier) OE who are
|
|
upgrading may require additional resource records, as detailed in our<A href="#upgrading.flagday">
|
|
upgrading document</A>. OE setup instructions here are for 2.02 or
|
|
later.</P>
|
|
<H2><A name="opp.dns">Requirements</A></H2>
|
|
<P>To set up opportunistic encryption, you will need:</P>
|
|
<UL>
|
|
<LI>a Linux box. For OE to the public Internet, this box must NOT be
|
|
behind<A HREF="#NAT.gloss"> Network Address Translation</A> (NAT).</LI>
|
|
<LI>to install Linux FreeS/WAN 2.02 or later</LI>
|
|
<LI>either control over your reverse DNS (for full opportunism) or the
|
|
ability to write to some forward domain (for initiator-only).<A HREF="http://www.fdns.net">
|
|
This free DNS service</A> explicitly supports forward TXT records for
|
|
FreeS/WAN use.</LI>
|
|
<LI>(for full opportunism) a static IP</LI>
|
|
</UL>
|
|
<P>Note: Currently, only Linux FreeS/WAN supports opportunistic
|
|
encryption.</P>
|
|
<H2><A name="easy.install">RPM install</A></H2>
|
|
<P>Our instructions are for a recent Red Hat with a 2.4-series stock or
|
|
Red Hat updated kernel. For other ways to install, see our<A href="#install">
|
|
install document</A>.</P>
|
|
<H3><A NAME="3_3_1">Download RPMs</A></H3>
|
|
<P>If we have prebuilt RPMs for your Red Hat system, this command will
|
|
get them:</P>
|
|
<PRE> ncftpget ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/`uname -r | tr -d 'a-wy-z'`/\*</PRE>
|
|
<P>If that fails, you will need to try<A HREF="install.html"> another
|
|
install method</A>. Our kernel modules<B> will only work on the Red Hat
|
|
kernel they were built for</B>, since they are very sensitive to small
|
|
changes in the kernel.</P>
|
|
<P>If it succeeds, you will have userland tools, a kernel module, and an
|
|
RPM signing key:</P>
|
|
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm
|
|
freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm
|
|
freeswan-rpmsign.asc</PRE>
|
|
<H3><A NAME="3_3_2">Check signatures</A></H3>
|
|
<P>If you're running RedHat 8.x or later, import the RPM signing key
|
|
into the RPM database:</P>
|
|
<PRE> rpm --import freeswan-rpmsign.asc</PRE>
|
|
<P>For RedHat 7.x systems, you'll need to add it to your<A HREF="#PGP">
|
|
PGP</A> keyring:</P>
|
|
<PRE> pgp -ka freeswan-rpmsign.asc</PRE>
|
|
<P>Check the digital signatures on both RPMs using:</P>
|
|
<PRE> rpm --checksig freeswan*.rpm </PRE>
|
|
<P>You should see that these signatures are good:</P>
|
|
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
|
|
freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK</PRE>
|
|
<H3><A NAME="3_3_3">Install the RPMs</A></H3>
|
|
<P>Become root:</P>
|
|
<PRE> su</PRE>
|
|
<P>Install your RPMs with:</P>
|
|
<P></P>
|
|
<PRE> rpm -ivh freeswan*.rpm</PRE>
|
|
<P>If you're upgrading from FreeS/WAN 1.x RPMs, and have problems with
|
|
that command, see<A HREF="#upgrading.rpms"> this note</A>.</P>
|
|
<P>Then, start FreeS/WAN:</P>
|
|
<PRE> service ipsec start</PRE>
|
|
<H3><A name="testinstall">Test</A></H3>
|
|
<P>To check that you have a successful install, run:</P>
|
|
<PRE> ipsec verify</PRE>
|
|
<P>You should see as part of the<VAR> verify</VAR> output:</P>
|
|
<PRE>
|
|
Checking your system to see if IPsec got installed and started correctly
|
|
Version check and ipsec on-path [OK]
|
|
Checking for KLIPS support in kernel [OK]
|
|
Checking for RSA private key (/etc/ipsec.secrets) [OK]
|
|
Checking that pluto is running [OK]
|
|
...</PRE>
|
|
<P>If any of these first four checks fails, see our<A href="#install.check">
|
|
troubleshooting guide</A>.</P>
|
|
<H2><A name="opp.setups.list">Our Opportunistic Setups</A></H2>
|
|
<H3><A NAME="3_4_1">Full or partial opportunism?</A></H3>
|
|
<P>Determine the best form of opportunism your system can support.</P>
|
|
<UL>
|
|
<LI>For<A HREF="#opp.incoming"> full opportunism</A>, you'll need a
|
|
static IP and and either control over your reverse DNS or an ISP that
|
|
can add the required TXT record for you.</LI>
|
|
<LI>If you have a dynamic IP, and/or write access to forward DNS only,
|
|
you can do<A HREF="#opp.client"> initiate-only opportunism</A></LI>
|
|
<LI>To protect traffic bound for real IPs behind your gateway, use<A HREF="#opp.gate">
|
|
this form of full opportunism</A>.</LI>
|
|
</UL>
|
|
<H2><A name="opp.client">Initiate-only setup</A></H2>
|
|
<H3><A NAME="3_5_1">Restrictions</A></H3>
|
|
<P>When you set up initiate-only Opportunistic Encryption (iOE):</P>
|
|
<UL>
|
|
<LI>there will be<STRONG> no incoming connection requests</STRONG>; you
|
|
can initiate all the IPsec connections you need.</LI>
|
|
<LI><STRONG>only one machine is visible</STRONG> on your end of the
|
|
connection.</LI>
|
|
<LI>iOE also protects traffic on behalf of<A HREF="#NAT.gloss"> NATted</A>
|
|
hosts behind the iOE box.</LI>
|
|
</UL>
|
|
<P>You cannot network a group of initiator-only machines if none of
|
|
these is capable of responding to OE. If one is capable of responding,
|
|
you may be able to create a hub topology using routing.</P>
|
|
<H3><A name="forward.dns">Create and publish a forward DNS record</A></H3>
|
|
<H4><A NAME="3_5_2_1">Find a domain you can use</A></H4>
|
|
<P>Find a DNS forward domain (e.g. example.com) where you can publish
|
|
your key. You'll need access to the DNS zone files for that domain.
|
|
This is common for a domain you own. Some free DNS providers, such as<A HREF="http://www.fdns.net">
|
|
this one</A>, also provide this service.</P>
|
|
<P>Dynamic IP users take note: the domain where you place your key need
|
|
not be associated with the IP address for your system, or even with
|
|
your system's usual hostname.</P>
|
|
<H4><A NAME="3_5_2_2">Choose your ID</A></H4>
|
|
<P>Choose a name within that domain which you will use to identify your
|
|
machine. It's convenient if this can be the same as your hostname:</P>
|
|
<PRE> [root@xy root]# hostname --fqdn
|
|
xy.example.com</PRE>
|
|
<P>This name in FQDN (fully-qualified domain name) format will be your
|
|
ID, for DNS key lookup and IPsec negotiation.</P>
|
|
<H4><A NAME="3_5_2_3">Create a forward TXT record</A></H4>
|
|
<P>Generate a forward TXT record containing your system's public key
|
|
with a command like:</P>
|
|
<PRE> ipsec showhostkey --txt @xy.example.com</PRE>
|
|
<P>using your chosen ID in place of xy.example.com. This command takes
|
|
the contents of /etc/ipsec.secrets and reformats it into something
|
|
usable by ISC's BIND. The result should look like this (with the key
|
|
data trimmed down for clarity):</P>
|
|
<PRE>
|
|
; RSA 2192 bits xy.example.com Thu Jan 2 12:41:44 2003
|
|
IN TXT "X-IPsec-Server(10)[email protected]"
|
|
"AQOF8tZ2... ...+buFuFn/"
|
|
</PRE>
|
|
<H4><A NAME="3_5_2_4">Publish the forward TXT record</A></H4>
|
|
<P>Insert the record into DNS, or have a system adminstrator do it for
|
|
you. It may take up to 48 hours for the record to propagate, but it's
|
|
usually much quicker.</P>
|
|
<H3><A NAME="3_5_3">Test that your key has been published</A></H3>
|
|
<P>Check your DNS work</P>
|
|
<PRE> ipsec verify --host xy.example.com</PRE>
|
|
<P>As part of the<VAR> verify</VAR> output, you ought to see something
|
|
like:</P>
|
|
<PRE> ...
|
|
Looking for TXT in forward map: xy.example.com [OK]
|
|
...</PRE>
|
|
<P>For this type of opportunism, only the forward test is relevant; you
|
|
can ignore the tests designed to find reverse records.</P>
|
|
<H3><A NAME="3_5_4">Configure, if necessary</A></H3>
|
|
<P> If your ID is the same as your hostname, you're ready to go.
|
|
FreeS/WAN will use its<A HREF="policygroups.html"> built-in connections</A>
|
|
to create your iOE functionality.</P>
|
|
<P>If you have chosen a different ID, you must tell FreeS/WAN about it
|
|
via<A HREF="manpage.d/ipsec.conf.5.html"><VAR> ipsec.conf</VAR></A>:</P>
|
|
<PRE> config setup
|
|
[email protected]</PRE>
|
|
<P>and restart FreeS/WAN:</P>
|
|
<PRE> service ipsec restart</PRE>
|
|
<P>The new ID will be applied to the built-in connections.</P>
|
|
<P>Note: you can create more complex iOE configurations as explained in
|
|
our<A HREF="#policygroups"> policy groups document</A>, or disable OE
|
|
using<A HREF="#disable_policygroups"> these instructions</A>.</P>
|
|
<H3><A NAME="3_5_5">Test</A></H3>
|
|
<P>That's it!<A HREF="#opp.test"> Test your connections</A>.</P>
|
|
<A name="opp.incoming"></A>
|
|
<H2><A NAME="3_6">Full Opportunism</A></H2>
|
|
<P>Full opportunism allows you to initiate and receive opportunistic
|
|
connections on your machine.</P>
|
|
<A name="incoming.opp.dns"></A>
|
|
<H3><A NAME="3_6_1">Put a TXT record in a Forward Domain</A></H3>
|
|
<P>To set up full opportunism, first<A HREF="#forward.dns"> set up a
|
|
forward TXT record</A> as for<A HREF="#opp.client"> initiator-only OE</A>
|
|
, using an ID (for example, your hostname) that resolves to your IP. Do
|
|
not configure<VAR> /etc/ipsec.conf</VAR>, but continue with the
|
|
instructions for full opportunism, below.</P>
|
|
<P>Note that this forward record is not currently necessary for full OE,
|
|
but will facilitate future features.</P>
|
|
<A name="incoming.opp.dns"></A>
|
|
<H3><A NAME="3_6_2">Put a TXT record in Reverse DNS</A></H3>
|
|
<P>You must be able to publish your DNS RR directly in the reverse
|
|
domain. FreeS/WAN will not follow a PTR which appears in the reverse,
|
|
since a second lookup at connection start time is too costly.</P>
|
|
<H4><A NAME="3_6_2_1">Create a Reverse DNS TXT record</A></H4>
|
|
<P>This record serves to publicize your FreeS/WAN public key. In
|
|
addition, it lets others know that this machine can receive
|
|
opportunistic connections, and asserts that the machine is authorized
|
|
to encrypt on its own behalf.</P>
|
|
<P>Use the command:</P>
|
|
<PRE> ipsec showhostkey --txt 192.0.2.11</PRE>
|
|
<P>where you replace 192.0.2.11 with your public IP.</P>
|
|
<P>The record (with key shortened) looks like:</P>
|
|
<PRE> ; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"</PRE>
|
|
<H4><A NAME="3_6_2_2">Publish your TXT record</A></H4>
|
|
<P>Send these records to your ISP, to be published in your IP's reverse
|
|
map. It may take up to 48 hours for these to propagate, but usually
|
|
takes much less time.</P>
|
|
<H3><A NAME="3_6_3">Test your DNS record</A></H3>
|
|
<P>Check your DNS work with</P>
|
|
<PRE> ipsec verify --host xy.example.com</PRE>
|
|
<P>As part of the<VAR> verify</VAR> output, you ought to see something
|
|
like:</P>
|
|
<PRE> ...
|
|
Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
|
|
...</PRE>
|
|
<P>which indicates that you've passed the reverse-map test.</P>
|
|
<H3><A NAME="3_6_4">No Configuration Needed</A></H3>
|
|
<P>FreeS/WAN 2.x ships with full OE enabled, so you don't need to
|
|
configure anything. To enable OE out of the box, FreeS/WAN 2.x uses the
|
|
policy group<VAR> private-or-clear</VAR>, which creates IPsec
|
|
connections if possible (using OE if needed), and allows traffic in the
|
|
clear otherwise. You can create more complex OE configurations as
|
|
described in our<A HREF="#policygroups"> policy groups document</A>, or
|
|
disable OE using<A HREF="#disable_policygroups"> these instructions</A>
|
|
.</P>
|
|
<P>If you've previously configured for initiator-only opportunism,
|
|
remove<VAR> myid=</VAR> from<VAR> config setup</VAR>, so that peer
|
|
FreeS/WANs will look up your key by IP. Restart FreeS/WAN so that your
|
|
change will take effect, with</P>
|
|
<PRE> service ipsec restart</PRE>
|
|
<H3><A NAME="3_6_5">Consider Firewalling</A></H3>
|
|
<P>If you are running a default install of RedHat 8.x, take note: you
|
|
will need to alter your iptables rule setup to allow IPSec traffic
|
|
through your firewall. See<A HREF="#simple.rules"> our firewall
|
|
document</A> for sample<VAR> iptables</VAR> rules.</P>
|
|
<H3><A NAME="3_6_6">Test</A></H3>
|
|
<P>That's it. Now,<A HREF="#opp.test"> test your connection</A>.</P>
|
|
<H3><A NAME="3_6_7">Test</A></H3>
|
|
<P>Instructions are in the next section.</P>
|
|
<H2><A NAME="opp.test">Testing opportunistic connections</A></H2>
|
|
<P>Be sure IPsec is running. You can see whether it is with:</P>
|
|
<PRE> ipsec setup status</PRE>
|
|
<P>If need be, you can restart it with:</P>
|
|
<PRE> service ipsec restart</PRE>
|
|
<P>Load a FreeS/WAN test website from the host on which you're running
|
|
FreeS/WAN. Note: the feds may be watching these sites. Type one of:</P>
|
|
<P></P>
|
|
<PRE> links oetest.freeswan.org</PRE>
|
|
<PRE> links oetest.freeswan.nl</PRE>
|
|
|
|
<!--<PRE> links oetest.freeswan.ca</PRE>-->
|
|
<P>A positive result looks like this:</P>
|
|
<PRE>
|
|
You seem to be connecting from: 192.0.2.11 which DNS says is:
|
|
gateway.example.com
|
|
_________________________________________________________________
|
|
|
|
Status E-route
|
|
OE enabled 16 192.139.46.73/32 -> 192.0.2.11/32 =>
|
|
[email protected]
|
|
OE enabled 176 192.139.46.77/32 -> 192.0.2.11/32 =>
|
|
[email protected]
|
|
</PRE>
|
|
<P>If you see this, congratulations! Your OE host or gateway will now
|
|
encrypt its own traffic whenever it can. For more OE tests, please see
|
|
our<A HREF="#test.oe"> testing document</A>. If you have difficulty,
|
|
see our<A HREF="#oe.trouble"> OE troubleshooting tips</A>.</P>
|
|
<H2><A NAME="3_8">Now what?</A></H2>
|
|
<P>Please see our<A HREF="policygroups.html"> policy groups document</A>
|
|
for more ways to set up Opportunistic Encryption.</P>
|
|
<P>You may also wish to make some<A HREF="config.html"> pre-configured
|
|
connections</A>.</P>
|
|
<H2><A NAME="3_9">Notes</A></H2>
|
|
<UL>
|
|
<LI>We assume some facts about your system in order to make
|
|
Opportunistic Encryption easier to configure. For example, we assume
|
|
that you wish to have FreeS/WAN secure your default interface.</LI>
|
|
<LI>You may change this, and other settings, by altering the<VAR> config
|
|
setup</VAR> section in<VAR> /etc/ipsec.conf</VAR>.</LI>
|
|
<LI>Note that the built-in connections used to build policy groups do
|
|
not inherit from<VAR> conn default</VAR>.</LI>
|
|
|
|
<!--
|
|
<LI>If you do not define your local identity
|
|
(eg. <VAR>leftid</VAR>), this will be the IP address of your default
|
|
FreeS/WAN interface.
|
|
-->
|
|
<LI> If you fail to define your local identity and do not fill in your
|
|
reverse DNS entry, you will not be able to use OE.</LI>
|
|
</UL>
|
|
<A NAME="oe.trouble"></A>
|
|
<H2><A NAME="3_10">Troubleshooting OE</A></H2>
|
|
<P>See the OE troubleshooting hints in our<A HREF="#oe.trouble">
|
|
troubleshooting guide</A>.</P>
|
|
<A NAME="oe.known-issues"></A>
|
|
<H2><A NAME="3_11">Known Issues</A></H2>
|
|
<P>Please see<A HREF="opportunism.known-issues"> this list</A> of known
|
|
issues with Opportunistic Encryption.</P>
|
|
<HR>
|
|
<H1><A NAME="4">How to Configure Linux FreeS/WAN with Policy Groups</A></H1>
|
|
<A NAME="policygroups"></A>
|
|
<H2><A NAME="4_1">What are Policy Groups?</A></H2>
|
|
<P><STRONG>Policy Groups</STRONG> are an elegant general mechanism to
|
|
configure FreeS/WAN. They are useful for many FreeS/WAN users.</P>
|
|
<P>In previous FreeS/WAN versions, you needed to configure each IPsec
|
|
connection explicitly, on both local and remote hosts. This could
|
|
become complex.</P>
|
|
<P>By contrast, Policy Groups allow you to set local IPsec policy for
|
|
lists of remote hosts and networks, simply by listing the hosts and
|
|
networks which you wish to have special treatment in one of several
|
|
Policy Group files. FreeS/WAN then internally creates the connections
|
|
needed to implement each policy.</P>
|
|
<P>In the next section we describe our five Base Policy Groups, which
|
|
you can use to configure IPsec in many useful ways. Later, we will show
|
|
you how to create an IPsec VPN using one line of configuration for each
|
|
remote host or network.</P>
|
|
<A NAME="builtin_policygroups"></A>
|
|
<H3><A NAME="4_1_1">Built-In Security Options</A></H3>
|
|
<P>FreeS/WAN offers these Base Policy Groups:</P>
|
|
<DL>
|
|
<DT>private</DT>
|
|
<DD> FreeS/WAN only communicates privately with the listed<A HREF="#CIDR">
|
|
CIDR</A> blocks. If needed, FreeS/WAN attempts to create a connection
|
|
opportunistically. If this fails, FreeS/WAN blocks communication.
|
|
Inbound blocking is assumed to be done by the firewall. FreeS/WAN
|
|
offers firewall hooks but no modern firewall rules to help with inbound
|
|
blocking.</DD>
|
|
<DT>private-or-clear</DT>
|
|
<DD> FreeS/WAN prefers private communication with the listed CIDR
|
|
blocks. If needed, FreeS/WAN attempts to create a connection
|
|
opportunistically. If this fails, FreeS/WAN allows traffic in the
|
|
clear.</DD>
|
|
<DT>clear-or-private</DT>
|
|
<DD> FreeS/WAN communicates cleartext with the listed CIDR blocks, but
|
|
also accepts inbound OE connection requests from them. Also known as<A HREF="#passive.OE">
|
|
passive OE (pOE)</A>, this policy may be used to create an<A HREF="#responder">
|
|
opportunistic responder</A>.</DD>
|
|
<DT>clear</DT>
|
|
<DD> FreeS/WAN only communicates cleartext with the listed CIDR blocks.</DD>
|
|
<DT>block</DT>
|
|
<DD>FreeS/WAN blocks traffic to and from and the listed CIDR blocks.
|
|
Inbound blocking is assumed to be done by the firewall. FreeS/WAN
|
|
offers firewall hooks but no modern firewall rules to help with inbound
|
|
blocking.
|
|
<!-- also called "blockdrop".-->
|
|
</DD>
|
|
</DL>
|
|
<A NAME="policy.group.notes"></A>
|
|
<P>Notes:</P>
|
|
<UL>
|
|
<LI>Base Policy Groups apply to communication with this host only.</LI>
|
|
<LI>The most specific rule (whether policy or pre-configured connection)
|
|
applies. This has several practical applications:
|
|
<UL>
|
|
<LI>If CIDR blocks overlap, FreeS/WAN chooses the most specific
|
|
applicable block.</LI>
|
|
<LI>This decision also takes into account any pre-configured connections
|
|
you may have.</LI>
|
|
<LI>If the most specific connection is a pre-configured connection, the
|
|
following procedure applies. If that connection is up, it will be used.
|
|
If it is routed, it will be brought up. If it is added, no action will
|
|
be taken.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Base Policy Groups are created using built-in connections. Details
|
|
in<A HREF="manpage.d/ipsec.conf.5.html"> man ipsec.conf</A>.</LI>
|
|
<LI>All Policy Groups are bidirectional.<A HREF="src/policy-groups-table.html">
|
|
This chart</A> shows some technical details. FreeS/WAN does not support
|
|
one-way encryption, since it can give users a false sense of security.</LI>
|
|
</UL>
|
|
<H2><A NAME="4_2">Using Policy Groups</A></H2>
|
|
<P>The Base Policy Groups which build IPsec connections rely on
|
|
Opportunistic Encryption. To use the following examples, you must first
|
|
become OE-capable, as described in our<A HREF="#quickstart"> quickstart
|
|
guide</A>.<A NAME="example1"></A></P>
|
|
<H3><A NAME="4_2_1">Example 1: Using a Base Policy Group</A></H3>
|
|
<P>Simply place CIDR blocks (<A HREF="#dnswarning">names</A>, IPs or IP
|
|
ranges) in /etc/ipsec.d/policies/<VAR>[groupname]</VAR>, and reread the
|
|
policy group files.</P>
|
|
<P>For example, the<VAR> private-or-clear</VAR> policy tells FreeS/WAN
|
|
to prefer encrypted communication to the listed CIDR blocks. Failing
|
|
that, it allows talk in the clear.</P>
|
|
<P>To make this your default policy, place<A HREF="#fullnet"> fullnet</A>
|
|
in the<VAR> private-or-clear</VAR> policy group file:</P>
|
|
<PRE> [root@xy root]# cat /etc/ipsec.d/policies/private-or-clear
|
|
# This file defines the set of CIDRs (network/mask-length) to which
|
|
# communication should be private, if possible, but in the clear otherwise.
|
|
....
|
|
0.0.0.0/0</PRE>
|
|
<P>and reload your policies with</P>
|
|
<PRE> ipsec auto --rereadgroups</PRE>
|
|
<P>Use<A HREF="#opp.test"> this test</A> to verify opportunistic
|
|
connections.</P>
|
|
<A NAME="example2"></A>
|
|
<H3><A NAME="4_2_2">Example 2: Defining IPsec Security Policy with
|
|
Groups</A></H3>
|
|
<P>Defining IPsec security policy with Base Policy Groups is like
|
|
creating a shopping list: just put CIDR blocks in the appropriate group
|
|
files. For example:</P>
|
|
<PRE> [root@xy root]# cd /etc/ipsec.d/policies
|
|
[root@xy policies]# cat private
|
|
192.0.2.96/27 # The finance department
|
|
192.0.2.192/29 # HR
|
|
192.0.2.12 # HR gateway
|
|
irc.private.example.com # Private IRC server
|
|
|
|
[root@xy policies]# cat private-or-clear
|
|
0.0.0.0/0 # My default policy: try to encrypt.
|
|
|
|
[root@xy policies]# cat clear
|
|
192.0.2.18/32 # My POP3 server
|
|
192.0.2.19/32 # My Web proxy
|
|
|
|
[root@xy policies]# cat block
|
|
spamsource.example.com</PRE>
|
|
<P>To make these settings take effect, type:</P>
|
|
<PRE> ipsec auto --rereadgroups</PRE>
|
|
<P>Notes:</P>
|
|
<UL>
|
|
<LI>For opportunistic connection attempts to succeed, all participating
|
|
FreeS/WAN hosts and gateways must be configured for OE.</LI>
|
|
<LI>Examples 3 through 5 show how to implement a detailed<VAR> private</VAR>
|
|
policy.</LI>
|
|
<LI><A NAME="dnswarning"></A><FONT COLOR="RED"> Warning:</FONT> Using
|
|
DNS names in policy files and ipsec.conf can be tricky. If the name
|
|
does not resolve, the policy will not be implemented for that name. It
|
|
is therefore safer either to use IPs, or to put any critical names in
|
|
/etc/hosts. We plan to implement periodic DNS retry to help with this.
|
|
<BR> Names are resolved at FreeS/WAN startup, or when the policies are
|
|
reloaded. Unfortunately, name lookup can hold up the startup process.
|
|
If you have fast DNS servers, the problem may be less severe.</LI>
|
|
</UL>
|
|
<A HREF="example3"></A>
|
|
<H3><A NAME="4_2_3">Example 3: Creating a Simple IPsec VPN with the<VAR>
|
|
private</VAR> Group</A></H3>
|
|
<P>You can create an IPsec VPN between several hosts, with only one line
|
|
of configuration per host, using the<VAR> private</VAR> policy group.</P>
|
|
<P>First, use our<A HREF="quickstart.html"> quickstart guide</A> to set
|
|
up each participating host with a FreeS/WAN install and OE.</P>
|
|
<P>In one host's<VAR> /etc/ipsec.d/policies/private</VAR>, list the
|
|
peers to which you wish to protect traffic. For example:</P>
|
|
<PRE> [root@xy root]# cd /etc/ipsec.d/policies
|
|
[root@xy policies]# cat private
|
|
192.0.2.9 # several hosts at example.com
|
|
192.0.2.11
|
|
192.0.2.12
|
|
irc.private.example.com
|
|
</PRE>
|
|
<P>Copy the<VAR> private</VAR> file to each host. Remove the local host,
|
|
and add the initial host.</P>
|
|
<PRE> scp2 /etc/ipsec.d/policies/private [email protected]:/etc/ipsec.d/policies/private</PRE>
|
|
<P>On each host, reread the policy groups with</P>
|
|
<PRE> ipsec auto --rereadgroups</PRE>
|
|
<P>That's it! You're configured.</P>
|
|
<P>Test by pinging between two hosts. After a second or two, traffic
|
|
should flow, and</P>
|
|
<PRE> ipsec eroute</PRE>
|
|
<P>should yield something like</P>
|
|
<PRE> 192.0.2.11/32 -> 192.0.2.8/32 => [email protected]</PRE>
|
|
<P>where your host IPs are substituted for 192.0.2.11 and 192.0.2.8.</P>
|
|
<P>If traffic does not flow, there may be an error in your OE setup.
|
|
Revisit our<A HREF="quickstart.html"> quickstart guide</A>.</P>
|
|
<P>Our next two examples show you how to add subnets to this IPsec VPN.</P>
|
|
<A NAME="example4"></A>
|
|
<H3><A NAME="4_2_4">Example 4: New Policy Groups to Protect a Subnet</A></H3>
|
|
<P>To protect traffic to a subnet behind your FreeS/WAN gateway, you'll
|
|
need additional DNS records, and new policy groups. To set up the DNS,
|
|
see our<A HREF="#opp.gate"> quickstart guide</A>. To create five new
|
|
policy groups for your subnet, copy these connections to<VAR>
|
|
/etc/ipsec.conf</VAR>. Substitute your subnet's IPs for 192.0.2.128/29.</P>
|
|
<PRE>
|
|
conn private-net
|
|
also=private # inherits settings (eg. auto=start) from built in conn
|
|
leftsubnet=192.0.2.128/29 # your subnet's IPs here
|
|
|
|
conn private-or-clear-net
|
|
also=private-or-clear
|
|
leftsubnet=192.0.2.128/29
|
|
|
|
conn clear-or-private-net
|
|
also=clear-or-private
|
|
leftsubnet=192.0.2.128/29
|
|
|
|
conn clear-net
|
|
also=clear
|
|
leftsubnet=192.0.2.128/29
|
|
|
|
conn block-net
|
|
also=block
|
|
leftsubnet=192.0.2.128/29
|
|
</PRE>
|
|
<P>Copy the gateway's files to serve as the initial policy group files
|
|
for the new groups:</P>
|
|
<PRE>
|
|
cp -p /etc/ipsec.d/policies/private /etc/ipsec.d/policies/private-net
|
|
cp -p /etc/ipsec.d/policies/private-or-clear /etc/ipsec.d/policies/private-or-clear-net
|
|
cp -p /etc/ipsec.d/policies/clear-or-private /etc/ipsec.d/policies/clear-or-private-net
|
|
cp -p /etc/ipsec.d/policies/clear /etc/ipsec.d/policies/clear-net
|
|
cp -p /etc/ipsec.d/policies/block /etc/ipsec.d/policies/block
|
|
</PRE>
|
|
<P><STRONG>Tip: Since a missing policy group file is equivalent to a
|
|
file with no entries, you need only create files for the connections
|
|
you'll use.</STRONG></P>
|
|
<P>To test one of your new groups, place the fullnet 0.0.0.0/0 in<VAR>
|
|
private-or-clear-net</VAR>. Perform the subnet test in<A HREF="#opp.test">
|
|
our quickstart guide</A>. You should see a connection, and</P>
|
|
<PRE> ipsec eroute</PRE>
|
|
<P>should include an entry which mentions the subnet node's IP and the
|
|
OE test site IP, like this:</P>
|
|
<PRE> 192.0.2.131/32 -> 192.139.46.77/32 => [email protected]</PRE>
|
|
<A HREF="example5"></A>
|
|
<H3><A NAME="4_2_5">Example 5: Adding a Subnet to the VPN</A></H3>
|
|
<P>Suppose you wish to secure traffic to a subnet 192.0.2.192/29 behind
|
|
a FreeS/WAN box 192.0.2.12.</P>
|
|
<P>First, add DNS entries to configure 192.0.2.12 as an opportunistic
|
|
gateway for that subnet. Instructions are in our<A HREF="#opp.gate">
|
|
quickstart guide</A>. Next, create a<VAR> private-net</VAR> group on
|
|
192.0.2.12 as described in<A HREF="#example4"> Example 4</A>.</P>
|
|
<P>On each other host, add the subnet 192.0.2.192/29 to<VAR> private</VAR>
|
|
, yielding for example</P>
|
|
<PRE> [root@xy root]# cd /etc/ipsec.d/policies
|
|
[root@xy policies]# cat private
|
|
192.0.2.9 # several hosts at example.com
|
|
192.0.2.11
|
|
192.0.2.12 # HR department gateway
|
|
192.0.2.192/29 # HR subnet
|
|
irc.private.example.com
|
|
</PRE>
|
|
<P>and reread policy groups with</P>
|
|
<PRE> ipsec auto --rereadgroups</PRE>
|
|
<P>That's all the configuration you need.</P>
|
|
<P>Test your VPN by pinging from a machine on 192.0.2.192/29 to any
|
|
other host:</P>
|
|
<PRE> [[email protected]]# ping 192.0.2.11</PRE>
|
|
<P>After a second or two, traffic should flow, and</P>
|
|
<PRE> ipsec eroute</PRE>
|
|
<P>should yield something like</P>
|
|
<PRE> 192.0.2.11/32 -> 192.0.2.194/32 => [email protected]
|
|
</PRE>
|
|
<P>Key:</P>
|
|
<TABLE>
|
|
<TR><TD>1.</TD><TD>192.0.2.11/32</TD><TD>Local start point of the
|
|
protected traffic.</TD></TR>
|
|
<TR><TD>2.</TD><TD>192.0.2.194/32</TD><TD>Remote end point of the
|
|
protected traffic.</TD></TR>
|
|
<TR><TD>3.</TD><TD>192.0.2.12</TD><TD>Remote FreeS/WAN node (gateway or
|
|
host). May be the same as (2).</TD></TR>
|
|
<TR><TD>4.</TD><TD>[not shown]</TD><TD>Local FreeS/WAN node (gateway or
|
|
host), where you've produced the output. May be the same as (1).</TD></TR>
|
|
</TABLE>
|
|
<P>For additional assurance, you can verify with a packet sniffer that
|
|
the traffic is being encrypted.</P>
|
|
<P>Note</P>
|
|
<UL>
|
|
<LI>Because strangers may also connect via OE, this type of VPN may
|
|
require a stricter firewalling policy than a conventional VPN.</LI>
|
|
</UL>
|
|
<H2><A NAME="4_3">Appendix</A></H2>
|
|
<A NAME="hiddenconn"></A>
|
|
<H3><A NAME="4_3_1">Our Hidden Connections</A></H3>
|
|
<P>Our Base Policy Groups are created using hidden connections. These
|
|
are spelled out in<A HREF="manpage.d/ipsec.conf.5.html"> man ipsec.conf</A>
|
|
and defined in<VAR> /usr/local/lib/ipsec/_confread</VAR>.</P>
|
|
<A NAME="custom_policygroups"></A>
|
|
<H3><A NAME="4_3_2">Custom Policy Groups</A></H3>
|
|
<P>A policy group is built using a special connection description in<VAR>
|
|
ipsec.conf</VAR>, which:</P>
|
|
<UL>
|
|
<LI>is<STRONG> generic</STRONG>. It uses<VAR>
|
|
right=[%group|%opportunisticgroup]</VAR> rather than specific IPs. The
|
|
connection is cloned for every name or IP range listed in its Policy
|
|
Group file.</LI>
|
|
<LI>often has a<STRONG> failure rule</STRONG>. This rule, written<VAR>
|
|
failureshunt=[passthrough|drop|reject|none]</VAR>, tells FreeS/WAN what
|
|
to do with packets for these CIDRs if it fails to establish the
|
|
connection. Default is<VAR> none</VAR>.</LI>
|
|
</UL>
|
|
<P>To create a new group:</P>
|
|
<OL>
|
|
<LI>Create its connection definition in<VAR> ipsec.conf</VAR>.</LI>
|
|
<LI>Create a Policy Group file in<VAR> /etc/ipsec.d/policies</VAR> with
|
|
the same name as your connection.</LI>
|
|
<LI>Put a CIDR block in that file.</LI>
|
|
<LI>Reread groups with<VAR> ipsec auto --rereadgroups</VAR>.</LI>
|
|
<LI>Test:<VAR> ping</VAR> to activate any OE connection, and view
|
|
results with<VAR> ipsec eroute</VAR>.</LI>
|
|
</OL>
|
|
<A NAME="disable_oe"></A><A NAME="disable_policygroups"></A>
|
|
<H3><A NAME="4_3_3">Disabling Opportunistic Encryption</A></H3>
|
|
<P>To disable OE (eg. policy groups and packetdefault), cut and paste
|
|
the following lines to<VAR> /etc/ipsec.conf</VAR>:</P>
|
|
<PRE>conn block
|
|
auto=ignore
|
|
|
|
conn private
|
|
auto=ignore
|
|
|
|
conn private-or-clear
|
|
auto=ignore
|
|
|
|
conn clear-or-private
|
|
auto=ignore
|
|
|
|
conn clear
|
|
auto=ignore
|
|
|
|
conn packetdefault
|
|
auto=ignore</PRE>
|
|
<P>Restart FreeS/WAN so that the changes take effect:</P>
|
|
<PRE> ipsec setup restart</PRE>
|
|
<HR>
|
|
<H1><A NAME="5">FreeS/WAN FAQ</A></H1>
|
|
<P>This is a collection of questions and answers, mostly taken from the
|
|
FreeS/WAN<A href="mail.html"> mailing list</A>. See the project<A href="http://www.freeswan.org/">
|
|
web site</A> for more information. All the FreeS/WAN documentation is
|
|
online there.</P>
|
|
<P>Contributions to the FAQ are welcome. Please send them to the project<A
|
|
href="mail.html"> mailing list</A>.</P>
|
|
<HR>
|
|
<H2><A name="questions">Index of FAQ questions</A></H2>
|
|
<UL>
|
|
<LI><A href="#whatzit">What is FreeS/WAN?</A></LI>
|
|
<LI><A href="#problems">How do I report a problem or seek help?</A></LI>
|
|
<LI><A href="#generic">Can I get ...</A>
|
|
<UL>
|
|
<LI><A href="#lemme_out">... an off-the-shelf system that includes
|
|
FreeS/WAN?</A></LI>
|
|
<LI><A href="#contractor">... contractors or staff who know FreeS/WAN?</A>
|
|
</LI>
|
|
<LI><A href="#commercial">... commercial support?</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#release">Release questions</A>
|
|
<UL>
|
|
<LI><A href="#rel.current">What is the current release?</A></LI>
|
|
<LI><A href="#relwhen">When is the next release?</A></LI>
|
|
<LI><A href="#rel.bugs">Are there known bugs in the current release?</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="mod_cons">Modifications and contributions</A>
|
|
<UL>
|
|
<LI><A href="#modify.faq">Can I modify FreeS/WAN to ...?</A></LI>
|
|
<LI><A href="#contrib.faq">Can I contribute to the project?</A></LI>
|
|
<LI><A href="#ddoc.faq">Is there detailed design documentation?</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#interact">Will FreeS/WAN work in my environment?</A>
|
|
<UL>
|
|
<LI><A href="#interop.faq">Can FreeS/WAN talk to ... ?</A></LI>
|
|
<LI><A href="#old_to_new">Can different FreeS/WAN versions talk to each
|
|
other?</A></LI>
|
|
<LI><A href="#faq.bandwidth">Is there a limit on throughput?</A></LI>
|
|
<LI><A href="#faq.number">Is there a limit on number of connections?</A></LI>
|
|
<LI><A href="#faq.speed">Is a ... fast enough to handle FreeS/WAN with
|
|
my loads?</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#work_on">Will FreeS/WAN work on ...</A>
|
|
<UL>
|
|
<LI><A href="#versions">... my version of Linux?</A></LI>
|
|
<LI><A href="#nonIntel.faq">... non-Intel CPUs?</A></LI>
|
|
<LI><A href="#multi.faq">... multiprocessors?</A></LI>
|
|
<LI><A href="#k.old">... an older kernel?</A></LI>
|
|
<LI><A href="#k.versions">... the latest kernel version?</A></LI>
|
|
<LI><A href="#interface.faq">... unusual network hardware?</A></LI>
|
|
<LI><A href="#vlan">... a VLAN (802.1q) network?</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#features.faq">Does FreeS/WAN support ...</A>
|
|
<UL>
|
|
<LI><A href="#VPN.faq">... site-to-site VPN applications</A></LI>
|
|
<LI><A href="#warrior.faq">... remote users connecting to a LAN</A></LI>
|
|
<LI><A href="#road.shared.possible">... remote users using shared secret
|
|
authentication?</A></LI>
|
|
<LI><A href="#wireless.faq">... wireless networks</A></LI>
|
|
<LI><A href="#PKIcert">... X.509 or other PKI certificates?</A></LI>
|
|
<LI><A href="#Radius">... user authentication (Radius, SecureID, Smart
|
|
Card ...)?</A></LI>
|
|
<LI><A href="#NATtraversal">... NAT traversal</A></LI>
|
|
<LI><A href="#virtID">... assigning a "virtual identity" to a remote
|
|
system?</A></LI>
|
|
<LI><A href="#noDES.faq">... single DES encryption?</A></LI>
|
|
<LI><A href="#AES.faq">... AES encryption?</A></LI>
|
|
<LI><A href="#other.cipher">... other encryption algorithms?</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#canI">Can I ...</A>
|
|
<UL>
|
|
<LI><A href="#policy.preconfig">...use policy groups along with
|
|
explicitly configured connections?</A></LI>
|
|
<LI><A href="#policy.off">...turn off policy groups?</A></LI>
|
|
|
|
<!--
|
|
<li><a href="#policy.otherinterface">...use policy groups
|
|
on an interface other than <VAR>%defaultroute</VAR>?</a></li>
|
|
-->
|
|
<LI><A href="#reload">... reload connection info without restarting?</A></LI>
|
|
<LI><A href="#masq.faq">... use several masqueraded subnets?</A></LI>
|
|
<LI><A href="#dup_route">... use subnets masqueraded to the same
|
|
addresses?</A></LI>
|
|
<LI><A href="#road.masq">... assign a road warrior an address on my net
|
|
(a virtual identity)?</A></LI>
|
|
<LI><A href="#road.many">... support many road warriors with one
|
|
gateway?</A></LI>
|
|
<LI><A href="#road.PSK">... have many road warriors using shared secret
|
|
authentication?</A></LI>
|
|
<LI><A href="#QoS">... use Quality of Service routing with FreeS/WAN?</A>
|
|
</LI>
|
|
<LI><A href="#deadtunnel">... recognise dead tunnels and shut them down?</A>
|
|
</LI>
|
|
<LI><A href="#demanddial">... build IPsec tunnels over a demand-dialed
|
|
link?</A></LI>
|
|
<LI><A href="#GRE">... build GRE, L2TP or PPTP tunnels over IPsec?</A></LI>
|
|
<LI><A href="#NetBIOS">... use Network Neighborhood (Samba, NetBIOS)
|
|
over IPsec?</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#setup.faq">Life's little mysteries</A>
|
|
<UL>
|
|
<LI><A href="#cantping">I cannot ping ....</A></LI>
|
|
<LI><A href="#forever">It takes forever to ...</A></LI>
|
|
<LI><A href="#route">I send packets to the tunnel with route(8) but they
|
|
vanish</A></LI>
|
|
<LI><A href="#down_route">When a tunnel goes down, packets vanish</A></LI>
|
|
<LI><A href="#firewall_ate">The firewall ate my packets!</A></LI>
|
|
<LI><A href="#dropconn">Dropped connections</A></LI>
|
|
<LI><A href="#defaultroutegone">Disappearing %defaultroute</A></LI>
|
|
<LI><A href="#tcpdump.faq">TCPdump on the gateway shows strange things</A>
|
|
</LI>
|
|
<LI><A href="#no_trace">Traceroute does not show anything between the
|
|
gateways</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#man4debug">Testing in stages (or .... works but ...
|
|
doesn't)</A>
|
|
<UL>
|
|
<LI><A href="#nomanual">Manually keyed connections don't work</A></LI>
|
|
<LI><A href="#spi_error">One manual connection works, but second one
|
|
fails</A></LI>
|
|
<LI><A href="#man_no_auto">Manual connections work, but automatic keying
|
|
doesn't</A></LI>
|
|
<LI><A href="#nocomp">IPsec works, but connections using compression
|
|
fail</A></LI>
|
|
<LI><A href="#pmtu.broken">Small packets work, but large transfers fail</A>
|
|
</LI>
|
|
<LI><A href="#subsub">Subnet-to-subnet works, but tests from the
|
|
gateways don't</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#compile.faq">Compilation problems</A>
|
|
<UL>
|
|
<LI><A href="#gmp.h_missing">gmp.h: No such file or directory</A></LI>
|
|
<LI><A href="#noVM">... virtual memory exhausted</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#error">Interpreting error messages</A>
|
|
<UL>
|
|
<LI><A href="#route-client">route-client (or host) exited with status 7</A>
|
|
</LI>
|
|
<LI><A href="#unreachable">SIOCADDRT:Network is unreachable</A></LI>
|
|
<LI><A href="#modprobe">ipsec_setup: modprobe: Can't locate moduleipsec</A>
|
|
</LI>
|
|
<LI><A href="#noKLIPS">ipsec_setup: Fatal error, kernel appears to lack
|
|
KLIPS</A></LI>
|
|
<LI><A href="#noDNS">ipsec_setup: ... failure to fetch key for ... from
|
|
DNS</A></LI>
|
|
<LI><A href="#dup_address">ipsec_setup: ... interfaces ... and ... share
|
|
address ...</A></LI>
|
|
<LI><A href="#kflags">ipsec_setup: Cannot adjust kernel flags</A></LI>
|
|
<LI><A href="#message_num">Message numbers (MI3, QR1, et cetera) in
|
|
Pluto messages</A></LI>
|
|
<LI><A href="#conn_name">Connection names in Pluto error messages</A></LI>
|
|
<LI><A href="#cantorient">Pluto: ... can't orient connection</A></LI>
|
|
<LI><A href="#no.interface">... we have no ipsecN interface for either
|
|
end of this connection</A></LI>
|
|
<LI><A href="#noconn">Pluto: ... no connection is known</A></LI>
|
|
<LI><A href="#nosuit">Pluto: ... no suitable connection ...</A></LI>
|
|
<LI><A href="#noconn.auth">Pluto: ... no connection has been authorized</A>
|
|
</LI>
|
|
<LI><A href="#noDESsupport">Pluto: ... OAKLEY_DES_CBC is not supported.</A>
|
|
</LI>
|
|
<LI><A href="#notransform">Pluto: ... no acceptable transform</A></LI>
|
|
<LI><A href="#rsasigkey">rsasigkey dumps core</A></LI>
|
|
<LI><A href="#sig4">!Pluto failure!: ... exited with ... signal 4</A></LI>
|
|
<LI><A href="#econnrefused">ECONNREFUSED error message</A></LI>
|
|
<LI><A href="#no_eroute">klips_debug: ... no eroute!</A></LI>
|
|
<LI><A href="#SAused">... trouble writing to /dev/ipsec ... SA already
|
|
in use</A></LI>
|
|
<LI><A href="#ignore">... ignoring ... payload</A></LI>
|
|
<LI><A href="#unknown_rightcert">unknown parameter name "rightcert"</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="#spam">Why don't you restrict the mailing lists to reduce
|
|
spam?</A></LI>
|
|
</UL>
|
|
<HR>
|
|
<H2><A name="whatzit">What is FreeS/WAN?</A></H2>
|
|
<P>FreeS/WAN is a Linux implementation of the<A href="#IPSEC"> IPsec</A>
|
|
protocols, providing security services at the IP (Internet Protocol)
|
|
level of the network.</P>
|
|
<P>For more detail, see our<A href="intro.html"> introduction</A>
|
|
document or the FreeS/WAN project<A href="http://www.freeswan.org/">
|
|
web site</A>.</P>
|
|
<P>To start setting it up, go to our<A href="quickstart.html">
|
|
quickstart guide</A>.</P>
|
|
<P>Our<A href="web.html"> web links</A> document has information on<A href="#implement">
|
|
IPsec for other systems</A>.</P>
|
|
<H2><A name="problems">How do I report a problem or seek help?</A></H2>
|
|
<DL>
|
|
<DT>Read our<A href="trouble.html"> troubleshooting</A> document.</DT>
|
|
<DD>
|
|
<P>It may guide you to a solution. If not, see its<A href="#prob.report">
|
|
problem reporting</A> section.</P>
|
|
<P>Basically, what it says is<STRONG> give us the output from<VAR> ipsec
|
|
barf</VAR> from both gateways</STRONG>. Without full information, we
|
|
cannot diagnose a problem. However,<VAR> ipsec barf</VAR> produces a
|
|
lot of output. If at all possible,<STRONG> please make barfs accessible
|
|
via the web or FTP</STRONG> rather than sending enormous mail messages.</P>
|
|
</DD>
|
|
<DT><STRONG>Use the<A href="mail.html"> users mailing list</A> for
|
|
problem reports</STRONG>, rather than mailing developers directly.</DT>
|
|
<DD>
|
|
<UL>
|
|
<LI>This gives you access to more expertise, including users who may
|
|
have encountered and solved the same problems.</LI>
|
|
<LI>It is more likely to get a quick response. Developers may get behind
|
|
on email, or even ignore it entirely for a while, but a list message
|
|
(given a reasonable Subject: line) is certain to be read by a fair
|
|
number of people within hours.</LI>
|
|
<LI>It may also be important because of<A href="#exlaw"> cryptography
|
|
export laws</A>. A US citizen who provides technical assistance to
|
|
foreign cryptographic work might be charged under the arms export
|
|
regulations. Such a charge would be easier to defend if the discussion
|
|
took place on a public mailing list than if it were done in private
|
|
mail.</LI>
|
|
</UL>
|
|
</DD>
|
|
<DT>Try irc.freenode.net#freeswan.</DT>
|
|
<DD>
|
|
<P>FreeS/WAN developers, volunteers and users can often be found there.
|
|
Be patient and be prepared to provide lots of information to support
|
|
your question.</P>
|
|
<P>If your question was really interesting, and you found an answer,
|
|
please share that with the class by posting to the<A href="mail.html">
|
|
users mailing list</A>. That way others with the same problem can find
|
|
your answer in the archives.</P>
|
|
</DD>
|
|
<DT>Premium support is also available.</DT>
|
|
<DD>
|
|
<P>See the next several questions.</P>
|
|
</DD>
|
|
</DL>
|
|
<H2><A name="generic">Can I get ...</A></H2>
|
|
<H3><A name="lemme_out">Can I get an off-the-shelf system that includes
|
|
FreeS/WAN?</A></H3>
|
|
<P>There are a number of Linux distributions or firewall products which
|
|
include FreeS/WAN. See this<A href="#products"> list</A>. Using one of
|
|
these, chosen to match your requirements and budget, may save you
|
|
considerable time and effort.</P>
|
|
<P>If you don't know your requirements, start by reading Schneier's<A href="#secrets">
|
|
Secrets and Lies</A>. That gives the best overview of security issues I
|
|
have seen. Then consider hiring a consultant (see next question) to
|
|
help define your requirements.</P>
|
|
<H3><A name="consultant">Can I hire consultants or staff who know
|
|
FreeS/WAN?</A></H3>
|
|
<P>If you want the help of a contractor, or to hire staff with FreeS/WAN
|
|
expertise, you could:</P>
|
|
<UL>
|
|
<LI>check availability in your area through your local Linux User Group
|
|
(<A href="http://lugww.counter.li.org/">LUG Index</A>)</LI>
|
|
<LI>try asking on our<A href="mail.html"> mailing list</A></LI>
|
|
</UL>
|
|
<P>For companies offerring support, see the next question.</P>
|
|
<H3><A name="commercial">Can I get commercial support?</A></H3>
|
|
<P>Many of the distributions or firewall products which include
|
|
FreeS/WAN (see this<A href="#products"> list</A>) come with commercial
|
|
support or have it available as an option.</P>
|
|
<P>Various companies specialize in commercial support of open source
|
|
software. Our project leader was a founder of the first such company,
|
|
Cygnus Support. It has since been bought by<A href="http://www.redhat.com">
|
|
Redhat</A>. Another such firm is<A href="http://www.linuxcare.com">
|
|
Linuxcare</A>.</P>
|
|
<H2><A name="release">Release questions</A></H2>
|
|
<H3><A name="rel.current">What is the current release?</A></H3>
|
|
<P>The current release is the highest-numbered tarball on our<A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan">
|
|
distribution site</A>. Almost always, any of<A href="#mirrors"> the
|
|
mirrors</A> will have the same file, though perhaps not for a day or so
|
|
after a release.</P>
|
|
<P>Unfortunately, the web site is not always updated as quickly as it
|
|
should be.</P>
|
|
<H3><A name="relwhen">When is the next release?</A></H3>
|
|
<P>We try to do a release approximately every six to eight weeks.</P>
|
|
<P>If pre-release tests fail and the fix appears complex, or more
|
|
generally if the code does not appear stable when a release is
|
|
scheduled, we will just skip that release.</P>
|
|
<P>For serious bugs, we may bring out an extra bug-fix release. These
|
|
get numbers in the normal release series. For example, there was a bug
|
|
found in FreeS/WAN 1.6, so we did another release less than two weeks
|
|
later. The bug-fix release was called 1.7.</P>
|
|
<H3><A name="rel.bugs">Are there known bugs in the current release?</A></H3>
|
|
<P>Any problems we are aware of at the time of a release are documented
|
|
in the<A href="../BUGS"> BUGS</A> file for that release. You should
|
|
also look at the<A href="../CHANGES"> CHANGES</A> file.</P>
|
|
<P>Bugs discovered after a release are discussed on the<A href="mail.html">
|
|
mailing lists</A>. The easiest way to check for any problems in the
|
|
current code would be to peruse the<A href="http://lists.freeswan.org/pipermail/briefs">
|
|
List In Brief</A>.</P>
|
|
<H2><A name="mod_cons">Modifications and contributions</A></H2>
|
|
<H3><A name="modify.faq">Can I modify FreeS/WAN to ...?</A></H3>
|
|
<P>You are free to modify FreeS/WAN in any way. See the discussion of<A href="#licensing">
|
|
licensing</A> in our introduction document.</P>
|
|
<P>Before investing much energy in any such project, we suggest that you</P>
|
|
<UL>
|
|
<LI>check the list of<A href="#patch"> existing patches</A></LI>
|
|
<LI>post something about your project to the<A href="mail.html"> design
|
|
mailing list</A></LI>
|
|
</UL>
|
|
<P>This may prevent duplicated effort, or lead to interesting
|
|
collaborations.</P>
|
|
<H3><A name="contrib.faq">Can I contribute to the project?</A></H3>
|
|
In general, we welcome contributions from the community. Various
|
|
contributed patches, either to fix bugs or to add features, have been
|
|
incorporated into our distribution. Other patches, not yet included in
|
|
the distribution, are listed in our<A href="#patch"> web links</A>
|
|
section.
|
|
<P>Users have also contributed heavily to documentation, both by
|
|
creating their own<A href="#howto"> HowTos</A> and by posting things on
|
|
the<A href="mail.html"> mailing lists</A> which I have quoted in these
|
|
HTML docs.</P>
|
|
<P>There are, however, some caveats.</P>
|
|
<P>FreeS/WAN is being implemented in Canada, by Canadians, largely to
|
|
ensure that is it is entirely free of export restrictions. See this<A href="#status">
|
|
discussion</A>. We<STRONG> cannot accept code contributions from US
|
|
residents or citizens</STRONG>, not even one-line bugs fixes. The
|
|
reasons for this were recently discussed extensively on the mailing
|
|
list, in a thread starting<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00111.html">
|
|
here</A>.</P>
|
|
<P>Not all contributions are of interest to us. The project has a set of
|
|
fairly ambitious and quite specific goals, described in our<A href="#goals">
|
|
introduction</A>. Contributions that lead toward these goals are likely
|
|
to be welcomed enthusiastically. Other contributions may be seen as
|
|
lower priority, or even as a distraction.</P>
|
|
<P>Discussion of possible contributions takes place on the<A href="mail.html">
|
|
design mailing list</A>.</P>
|
|
<H3><A name="ddoc.faq">Is there detailed design documentation?</A></H3>
|
|
There are:
|
|
<UL>
|
|
<LI><A href="rfc.html">RFCs</A> specifying the protocols we implement</LI>
|
|
<LI><A href="manpages.html">man pages</A> for our utilities, library
|
|
functions and file formats</LI>
|
|
<LI>comments in the source code</LI>
|
|
<LI><A href="index.html">HTML documentation</A> written primarily for
|
|
users</LI>
|
|
<LI>archived discussions from the<A href="mail.html"> mailing lists</A></LI>
|
|
<LI>other papers mentioned in our<A href="#applied"> introduction</A></LI>
|
|
</UL>
|
|
<P>The only formal design documents are a few papers in the last
|
|
category above. All the other categories, however, have things to say
|
|
about design as well.</P>
|
|
<H2><A name="interact">Will FreeS/WAN work in my environment?</A></H2>
|
|
<H3><A name="interop.faq">Can FreeS/WAN talk to ...?</A></H3>
|
|
<P>The IPsec protocols are designed to support interoperation. In
|
|
theory, any two IPsec implementations should be able to talk to each
|
|
other. In practice, it is considerably more complex. We have a whole<A href="interop.html">
|
|
interoperation document</A> devoted to this problem.</P>
|
|
<P>An important part of that document is links to the many<A href="interop.html#otherpub">
|
|
user-written HowTos</A> on interoperation between FreeS/WAN and various
|
|
other implementations. Often the users know more than the developers
|
|
about these issues (and almost always more than me :-), so these
|
|
documents may be your best resource.</P>
|
|
<H3><A name="old_to_new">Can different FreeS/WAN versions talk to each
|
|
other?</A></H3>
|
|
<P>Linux FreeS/WAN can interoperate with many IPsec implementations,
|
|
including earlier versions of Linux FreeS/WAN itself.</P>
|
|
<P>In a few cases, there are some complications. See our<A href="interop.html#oldswan">
|
|
interoperation</A> document for details.</P>
|
|
<H3><A name="faq.bandwidth">Is there a limit on throughput?</A></H3>
|
|
<P>There is no hard limit, but see below.</P>
|
|
<H3><A name="faq.number">Is there a limit on number of tunnels?</A></H3>
|
|
<P>There is no hard limit, but see next question.</P>
|
|
<H3><A name="faq.speed">Is a ... fast enough to handle FreeS/WAN with my
|
|
loads?</A></H3>
|
|
<P>A quick summary:</P>
|
|
<DL>
|
|
<DT>Even a limited machine can be useful</DT>
|
|
<DD>A 486 can handle a T1, ADSL or cable link, though the machine may be
|
|
breathing hard.</DD>
|
|
<DT>A mid-range PC (say 800 MHz with good network cards) can do a lot of
|
|
IPsec</DT>
|
|
<DD>With up to roughly 50 tunnels and aggregate bandwidth of 20 Megabits
|
|
per second, it willl have cycles left over for other tasks.</DD>
|
|
<DT>There are limits</DT>
|
|
<DD>Even a high end CPU will not come close to handling a fully loaded
|
|
100 Mbit/second Ethernet link.
|
|
<P>Beyond about 50 tunnels it needs careful management.</P>
|
|
</DD>
|
|
</DL>
|
|
<P>See our<A href="performance.html"> FreeS/WAN performance</A> document
|
|
for details.</P>
|
|
<H2><A name="work_on">Will FreeS/WAN work on ... ?</A></H2>
|
|
<H3><A name="versions">Will FreeS/WAN run on my version of Linux?</A></H3>
|
|
<P>We build and test on Redhat distributions, but FreeS/WAN runs just
|
|
fine on several other distributions, sometimes with minor fiddles to
|
|
adapt to the local environment. Details are in our<A href="#otherdist">
|
|
compatibility</A> document. Also, some distributions or products come
|
|
with<A href="#products"> FreeS/WAN included</A>.</P>
|
|
<H3><A name="nonIntel.faq">Will FreeS/WAN run on non-Intel CPUs?</A></H3>
|
|
<P>FreeS/WAN is<STRONG> intended to run on all CPUs Linux supports</STRONG>
|
|
. We know of it being used in production on x86, ARM, Alpha and MIPS. It
|
|
has also had successful tests on PPC and SPARC, though we don't know of
|
|
actual use there. Details are in our<A href="#CPUs"> compatibility</A>
|
|
document.</P>
|
|
<H3><A name="multi.faq">Will FreeS/WAN run on multiprocessors?</A></H3>
|
|
<P>FreeS/WAN is designed to work on any SMP architecture Linux supports,
|
|
and has been tested successfully on at least dual processor Intel
|
|
architecture machines. Details are in our<A href="#multiprocessor">
|
|
compatibility</A> document.</P>
|
|
<H3><A name="k.old">Will FreeS/WAN work on an older kernel?</A></H3>
|
|
<P>It might, but we strongly recommend using a recent 2.2 or 2.4 series
|
|
kernel. Sometimes the newer versions include security fixes which can
|
|
be quite important on a gateway.</P>
|
|
<P>Also, we use recent kernels for development and testing, so those are
|
|
better tested and, if you do encounter a problem, more easily
|
|
supported. If something breaks applying recent FreeS/WAN patches to an
|
|
older kernel, then "update your kernel" is almost certain to be the
|
|
first thing we suggest. It may be the only suggestion we have.</P>
|
|
<P>The precise kernel versions supported by a particular FreeS/WAN
|
|
release are given in the<A href="XX"> README</A> file of that release.</P>
|
|
<P>See the following question for more on kernels.</P>
|
|
<H3><A name="k.versions">Will FreeS/WAN run on the latest kernel
|
|
version?</A></H3>
|
|
<P>Sometimes yes, but quite often, no.</P>
|
|
<P>Kernel versions supported are given in the<A href="../README"> README</A>
|
|
file of each FreeS/WAN release. Typically, they are whatever production
|
|
kernels were current at the time of our release (or shortly before; we
|
|
might release for kernel<VAR> n</VAR> just as Linus releases<VAR> n+1</VAR>
|
|
). Often FreeS/WAN will work on slightly later kernels as well, but of
|
|
course this cannot be guaranteed.</P>
|
|
<P>For example, FreeS/WAN 1.91 was released for kernels 2.2.19 or 2.4.5,
|
|
the current kernels at the time. It also worked on 2.4.6, 2.4.7 and
|
|
2.4.8, but 2.4.9 had changes that caused compilation errors if it was
|
|
patched with FreeS/WAN 1.91.</P>
|
|
<P>When such changes appear, we put a fix in the FreeS/WAN snapshots,
|
|
and distribute it with our next release. However, this is not a high
|
|
priority for us, and it may take anything from a few days to several
|
|
weeks for such a problem to find its way to the top of our kernel
|
|
programmer's To-Do list. In the meanwhile, you have two choices:</P>
|
|
<UL>
|
|
<LI>either stick with a slightly older kernel, even if it is not the
|
|
latest and greatest. This is recommended for production systems; new
|
|
versions may have new bugs.</LI>
|
|
<LI>or fix the problem yourself and send us a patch, via the<A href="mail.html">
|
|
Users mailing list</A>.</LI>
|
|
</UL>
|
|
<P>We don't even try to keep up with kernel changes outside the main 2.2
|
|
and 2.4 branches, such as the 2.4.x-ac patched versions from Alan Cox
|
|
or the 2.5 series of development kernels. We'd rather work on
|
|
developing the FreeS/WAN code than on chasing these moving targets. We
|
|
are, however, happy to get patches for problems discovered there.</P>
|
|
<P>See also the<A href="install.html#choosek"> Choosing a kernel</A>
|
|
section of our installation document.</P>
|
|
<H3><A name="interface.faq">Will FreeS/WAN work on unusual network
|
|
hardware?</A></H3>
|
|
<P>IPsec is designed to work over any network that IP works over, and
|
|
FreeS/WAN is intended to work over any network interface hardware that
|
|
Linux supports.</P>
|
|
<P>If you have working IP on some unusual interface -- perhaps Arcnet,
|
|
Token Ring, ATM or Gigabit Ethernet -- then IPsec should "just work".</P>
|
|
<P>That said, practice is sometimes less tractable than theory. Our
|
|
testing is done almost entirely on:</P>
|
|
<UL>
|
|
<LI>10 or 100 Mbit Ethernet</LI>
|
|
<LI>ADSL or cable connections, with and without PPPoE</LI>
|
|
<LI>IEEE 802.11 wireless LANs (see<A href="#wireless.faq"> below</A>)</LI>
|
|
</UL>
|
|
<P>If you have some other interface, especially an uncommon one, it is
|
|
entirely possible you will get bitten either by a FreeS/WAN bug which
|
|
our testing did not turn up, or by a bug in the driver that shows up
|
|
only with our loads.</P>
|
|
<P>If IP works on your interface and FreeS/WAN doesn't, seek help on the<A
|
|
href="mail.html"> mailing lists</A>.</P>
|
|
<P>Another FAQ section describes<A href="#pmtu.broken"> MTU problems</A>
|
|
. These are a possibility for some interfaces.</P>
|
|
<H3><A name="vlan">Will FreeS/WAN work on a VLAN (802.1q) network?</A></H3>
|
|
<P> Yes, FreeSwan works fine, though some network drivers have problems
|
|
with jumbo sized ethernet frames. If you used interfaces=%defaultroute
|
|
you do not need to change anything, but if you specified an interface
|
|
(eg eth0) then remember you must change that to reflect the VLAN
|
|
interface (eg eth0.2 for VLAN ID 2).</P>
|
|
<P> The "eepro100" module is known to be broken, use the e100 driver for
|
|
those cards instead (included in 2.4 as 'alternative driver' for the
|
|
Intel EtherExpressPro/100.</P>
|
|
<P> You do not need to change any MTU setting (those are workarounds
|
|
that are only needed for buggy drivers)</P>
|
|
<P><EM>This FAQ contributed by Paul Wouters.</EM></P>
|
|
<H2><A name="features.faq">Does FreeS/WAN support ...</A></H2>
|
|
<P>For a discussion of which parts of the IPsec specifications FreeS/WAN
|
|
does and does not implement, see our<A href="#spec"> compatibility</A>
|
|
document.</P>
|
|
<P>For information on some often-requested features, see below.</P>
|
|
<H3><A name="VPN.faq"></A>Does FreeS/WAN support site-to-site VPN (<A HREF="#VPN">
|
|
Virtual Private Network</A>) applications?</H3>
|
|
<P>Absolutely. See this FreeS/WAN-FreeS/WAN<A HREF="config.html">
|
|
configuration example</A>. If only one site is using FreeS/WAN, there
|
|
may be a relevant HOWTO on our<A HREF="interop.html"> interop page</A>.</P>
|
|
<H3><A name="warrior.faq">Does FreeS/WAN support remote users connecting
|
|
to a LAN?</A></H3>
|
|
<P>Yes. We call the remote users "Road Warriors". Check out our
|
|
FreeS/WAN-FreeS/WAN<A HREF="#config.rw"> Road Warrior Configuration
|
|
Example</A>.</P>
|
|
<P>If your Road Warrior is a Windows or Mac PC, you may need to install
|
|
an IPsec implementation on that machine. Our<A HREF="interop.html">
|
|
interop</A> page lists many available brands, and features links to
|
|
several HOWTOs.</P>
|
|
<H3><A name="road.shared.possible">Does FreeS/WAN support remote users
|
|
using shared secret authentication?</A></H3>
|
|
<P><STRONG>Yes, but</STRONG> there are severe restrictions, so<STRONG>
|
|
we strongly recommend using</STRONG><A href="#RSA"><STRONG> RSA</STRONG>
|
|
</A><STRONG> keys for</STRONG><A href="#authentication"><STRONG>
|
|
authentication</STRONG></A><STRONG> instead</STRONG>.</P>
|
|
<P>See this<A href="#road.PSK"> FAQ question</A>.</P>
|
|
<H3><A name="wireless.faq">Does FreeS/WAN support wireless networks?</A></H3>
|
|
<P>Yes, it is a common practice to use IPsec over wireless networks
|
|
because their built-in encryption,<A href="#WEP"> WEP</A>, is insecure.</P>
|
|
<P>There is some<A href="#wireless.config"> discussion</A> in our
|
|
advanced configuration document. See also the<A HREF="http://www.wavesec.org">
|
|
WaveSEC site</A>.</P>
|
|
<H3><A name="PKIcert">Does FreeS/WAN support X.509 or other PKI
|
|
certificates?</A></H3>
|
|
<P>Vanilla FreeS/WAN does not support X.509, but Andreas Steffen and
|
|
others have provided a popular, well-supported X.509 patch.</P>
|
|
<UL>
|
|
<LI><A HREF="http://www.strongsec.com/freeswan">patch</A></LI>
|
|
<LI><A HREF="http://www.freeswan.ca">Super FreeS/WAN</A> incorporates
|
|
this and other user-contributed patches.</LI>
|
|
<LI> Kai Martius'<A HREF="http://www.strongsec.com/freeswan/install.htm">
|
|
X.509 Installation and Configuration Guide</A></LI>
|
|
</UL>
|
|
<P> Linux FreeS/WAN features<A HREF="quickstart.html"> Opportunistic
|
|
Encryption</A>, an alternative Public Key Infrastructure based on
|
|
Secure DNS.</P>
|
|
<H3><A name="Radius">Does FreeS/WAN support user authentication (Radius,
|
|
SecureID, Smart Card...)?</A></H3>
|
|
<P>Andreas Steffen's<A HREF="http://www.strongsec.com/freeswan"> X.509
|
|
patch</A> (v. 1.42+) supports Smart Cards. The patch does not ship with
|
|
vanilla FreeS/WAN, but will be incorporated into<A HREF="http://www.freeswan.ca/">
|
|
Super FreeS/WAN 2.01+</A>. The patch implements the PCKS#15
|
|
Cryptographic Token Information Format Standard, using the OpenSC
|
|
smartcard library functions.</P>
|
|
<P>Older news:</P>
|
|
<P>A user-supported patch to FreeS/WAN 1.3, for smart card style
|
|
authentication, is available on<A HREF="http://alcatraz.webcriminals.com/~bastiaan/ipsec">
|
|
Bastiaan's site</A>. It supports skeyid and ibutton. This patch is not
|
|
part of Super FreeS/WAN.</P>
|
|
<P>For a while progress on this front was impeded by a lack of standard.
|
|
The IETF<A href="http://www.ietf.org/html.charters/ipsra-charter.html">
|
|
working group</A> has now nearly completed its recommended solution to
|
|
the problem; meanwhile several vendors have implemented various things.</P>
|
|
|
|
<!--
|
|
<p>The <a href="web.html#patch">patches</a> section of our web links document
|
|
has links to some user work on this.</p>
|
|
-->
|
|
<P>Of course, there are various ways to avoid any requirement for user
|
|
authentication in IPsec. Consider the situation where road warriors
|
|
build IPsec tunnels to your office net and you are considering
|
|
requiring user authentication during tunnel negotiation. Alternatives
|
|
include:</P>
|
|
<UL>
|
|
<LI>If you can trust the road warrior machines, then set them up so that
|
|
only authorised users can create tunnels. If your road warriors use
|
|
laptops, consider the possibility of theft.</LI>
|
|
<LI>If the tunnel only provides access to particular servers and you can
|
|
trust those servers, then set the servers up to require user
|
|
authentication.</LI>
|
|
</UL>
|
|
<P>If either of those is trustworthy, it is not clear that you need user
|
|
authentication in IPsec.</P>
|
|
<H3><A name="NATtraversal">Does FreeS/WAN support NAT traversal?</A></H3>
|
|
<P>Vanilla FreeS/WAN does not, but thanks to Mathieu Lafon and Arkoon
|
|
Network Security, there's a patch to support this.</P>
|
|
<UL>
|
|
<LI><A HREF="http://open-source.arkoon.net">patch and documentation</A></LI>
|
|
<LI><A HREF="http://www.freeswan.ca">Super FreeS/WAN</A> incorporates
|
|
this and other user-contributed patches.</LI>
|
|
</UL>
|
|
<P>The NAT traversal patch has some issues with PSKs, so you may wish to
|
|
authenticate with RSA keys, or X.509 (requires a patch which is also
|
|
included in Super FreeS/WAN). Doing the latter also has advantages when
|
|
dealing with large numbers of clients who may be behind NAT; instead of
|
|
having to make an individual Roadwarrior connection for each virtual
|
|
IP, you can use the "rightsubnetwithin" parameter to specify a range.
|
|
See<A HREF="http://www.strongsec.com/freeswan/install.htm#section_4.4">
|
|
these<VAR> rightsubnetwithin</VAR> instructions</A>.</P>
|
|
<H3><A name="virtID">Does FreeS/WAN support assigning a "virtual
|
|
identity" to a remote system?</A></H3>
|
|
<P>Some IPsec implementations allow you to make the source address on
|
|
packets sent by a Road Warrior machine be something other than the
|
|
address of its interface to the Internet. This is sometimes described
|
|
as assigning a virtual identity to that machine.</P>
|
|
<P>FreeS/WAN does not directly support this, but it can be done. See
|
|
this<A href="#road.masq"> FAQ question</A>.</P>
|
|
<H3><A name="noDES.faq">Does FreeS/WAN support single DES encryption?</A>
|
|
</H3>
|
|
<P><STRONG>No</STRONG>, single DES is not used either at the<A href="#IKE">
|
|
IKE</A> level for negotiating connections or at the<A href="#IPSEC">
|
|
IPsec</A> level for actually building them.</P>
|
|
<P>Single DES is<A href="#desnotsecure"> insecure</A>. As we see it, it
|
|
is more important to deliver real security than to comply with a
|
|
standard which has been subverted into allowing use of inadequate
|
|
methods. See this<A href="#weak"> discussion</A>.</P>
|
|
<P>If you want to interoperate with an IPsec implementation which offers
|
|
only DES, see our<A href="interop.html#noDES"> interoperation</A>
|
|
document.</P>
|
|
<H3><A name="AES.faq">Does FreeS/WAN support AES encryption?</A></H3>
|
|
<P><A href="#AES">AES</A> is a new US government<A href="#block"> block
|
|
cipher</A> standard to replace the obsolete<A href="#DES"> DES</A>.</P>
|
|
<P>At time of writing (March 2002), the FreeS/WAN distribution does not
|
|
yet support AES but user-written<A href="#patch"> patches</A> are
|
|
available to add it. Our kernel programmer is working on integrating
|
|
those patches into the distribution, and there is active discussion of
|
|
this on the design mailimg list.</P>
|
|
<H3><A name="other.cipher">Does FreeS/WAN support other encryption
|
|
algorithms?</A></H3>
|
|
<P>Currently<A href="#3DES"> triple DES</A> is the only cipher
|
|
supported. AES will almost certainly be added (see previous question),
|
|
and it is likely that in the process we will also add the other two AES
|
|
finalists with open licensing, Twofish and Serpent.</P>
|
|
<P>We are extremely reluctant to add other ciphers. This would make both
|
|
use and maintenance of FreeS/WAN more complex without providing any
|
|
clear benefit. Complexity is emphatically not desirable in a security
|
|
product.</P>
|
|
<P>Various users have written patches to add other ciphers. We provide<A href="#patch">
|
|
links</A> to these.</P>
|
|
<H2><A name="canI">Can I ...</A></H2>
|
|
<H3><A name="policy.preconfig">Can I use policy groups along with
|
|
explicitly configured connections?</A></H3>
|
|
<P>Yes, you can, so long as you pay attention to the selection rule,
|
|
which can be summarized "the most specific connection wins". We
|
|
describe the rule in our<A HREF="#policy.group.notes"> policy groups</A>
|
|
document, and provide a more technical explanation in<A HREF="manpage.d/ipsec.conf.5.html">
|
|
man ipsec.conf</A>.</P>
|
|
<P>A good guideline: If you have a regular connection defined in<VAR>
|
|
ipsec.conf</VAR>, ensure that a subset of that connection is not listed
|
|
in a less restrictive policy group. Otherwise, FreeS/WAN will use the
|
|
subset, with its more specific source/destination pair.</P>
|
|
<P>Here's an example. Suppose you are the system administrator at
|
|
192.0.2.2. You have this connection in ipsec.conf:<VAR> ipsec.conf</VAR>
|
|
:</P>
|
|
<PRE>conn net-to-net
|
|
left=192.0.2.2 # you are here
|
|
right=192.0.2.8
|
|
rightsubnet=192.0.2.96/27
|
|
....
|
|
</PRE>
|
|
<P>If you then place a host or net within<VAR> rightsubnet</VAR>, (let's
|
|
say 192.0.2.98) in<VAR> private-or-clear</VAR>, you may find that
|
|
192.0.2.2 at times communicates in the clear with 192.0.2.98. That's
|
|
consistent with the rule, but may be contrary to your expectations.</P>
|
|
<P>On the other hand, it's safe to put a larger subnet in a less
|
|
restrictive policy group file. If<VAR> private-or-clear</VAR> contains
|
|
192.0.2.0/24, then the more specific<VAR> net-to-net</VAR> connection
|
|
is used for any communication to 192.0.2.96/27. The more general policy
|
|
applies only to communication with hosts or subnets in 192.0.2.0/24
|
|
without a more specific policy or connection.</P>
|
|
<H3><A name="policy.off">Can I turn off policy groups?</A></H3>
|
|
<P>Yes. Use<A HREF="#disable_policygroups"> these instructions</A>.</P>
|
|
|
|
<!--
|
|
<h3><a name="policy.otherinterface">Can I use policy groups
|
|
on an interface other than <VAR>%defaultroute</VAR>?</a></h3>
|
|
|
|
<p>??<p>
|
|
-->
|
|
<H3><A name="reload">Can I reload connection info without restarting?</A>
|
|
</H3>
|
|
<P>Yes, you can do this. Here are the details, in a mailing list message
|
|
from Pluto programmer Hugh Redelmeier:</P>
|
|
<PRE>| How can I reload config's without restarting all of pluto and klips? I am using
|
|
| FreeSWAN -> PGPNet in a medium sized production environment, and would like to be
|
|
| able to add new connections ( i am using include config/* ) without dropping current
|
|
| SA's.
|
|
|
|
|
| Can this be done?
|
|
|
|
|
| If not, are there plans to add this kind of feature?
|
|
|
|
ipsec auto --add whatever
|
|
This will look in the usual place (/etc/ipsec.conf) for a conn named
|
|
whatever and add it.
|
|
|
|
If you added new secrets, you need to do
|
|
ipsec auto --rereadsecrets
|
|
before Pluto needs to know those secrets.
|
|
|
|
| I have looked (perhaps not thoroughly enough tho) to see how to do this:
|
|
|
|
There may be more bits to look for, depending on what you are trying
|
|
to do.</PRE>
|
|
<P>Another useful command here is<VAR> ipsec auto --replace <conn_name></VAR>
|
|
which re-reads data for a named connection.</P>
|
|
<H3><A name="masq.faq">Can I use several masqueraded subnets?</A></H3>
|
|
<P>Yes. This is done all the time. See the discussion in our<A href="config.html#route_or_not">
|
|
setup</A> document. The only restriction is that the subnets on the two
|
|
ends must not overlap. See the next question.</P>
|
|
<P>Here is a mailing list message on the topic. The user incorrectly
|
|
thinks you need a 2.4 kernel for this -- actually various people have
|
|
been doing it on 2.0 and 2.2 for quite some time -- but he has it right
|
|
for 2.4.</P>
|
|
<PRE>Subject: Double NAT and freeswan working :)
|
|
Date: Sun, 11 Mar 2001
|
|
From: Paul Wouters <[email protected]>
|
|
|
|
Just to share my pleasure, and make an entry for people who are searching
|
|
the net on how to do this. Here's the very simple solution to have a double
|
|
NAT'ed network working with freeswan. (Not sure if this is old news, but I'm
|
|
not on the list (too much spam) and I didn't read this in any HOWTO/FAQ/doc
|
|
on the freeswan site yet (Sandy, put it in! :)
|
|
|
|
10.0.0.0/24 --- 10.0.0.1 a.b.c.d ---- a.b.c.e {internet} ----+
|
|
|
|
|
10.0.1.0/24 --- 10.0.1.1 f.g.h.i ---- f.g.h.j {internet} ----+
|
|
|
|
the goal is to have the first network do a VPN to the second one, yet also
|
|
have NAT in place for connections not destinated for the other side of the
|
|
NAT. Here the two Linux security gateways have one real IP number (cable
|
|
modem, dialup, whatever.
|
|
|
|
The problem with NAT is you don't want packets from 10.*.*.* to 10.*.*.*
|
|
to be NAT'ed. While with Linux 2.2, you can't, with Linux 2.4 you can.
|
|
|
|
(This has been tested and works for 2.4.2 with Freeswan snapshot2001mar8b)
|
|
|
|
relevant parts of /etc/ipsec.conf:
|
|
|
|
left=f.g.h.i
|
|
leftsubnet=10.0.1.0/24
|
|
leftnexthop=f.g.h.j
|
|
leftfirewall=yes
|
|
[email protected]
|
|
leftrsasigkey=0x0........
|
|
right=a.b.c.d
|
|
rightsubnet=10.0.0.0/24
|
|
rightnexthop=a.b.c.e
|
|
rightfirewall=yes
|
|
[email protected]
|
|
rightrsasigkey=0x0......
|
|
# To authorize this connection, but not actually start it, at startup,
|
|
# uncomment this.
|
|
auto=add
|
|
|
|
and now the real trick. Setup the NAT correctly on both sites:
|
|
|
|
iptables -t nat -F
|
|
iptables -t nat -A POSTROUTING -o eth0 -d \! 10.0.0.0/8 -j MASQUERADE
|
|
|
|
This tells the NAT code to only do NAT for packets with destination other then
|
|
10.* networks. note the backslash to mask the exclamation mark to protect it
|
|
against the shell.
|
|
|
|
Happy painting :)
|
|
|
|
Paul</PRE>
|
|
<H3><A name="dup_route">Can I use subnets masqueraded to the same
|
|
addresses?</A></H3>
|
|
<P><STRONG>No.</STRONG> The notion that IP addresses are unique is one
|
|
of the fundamental principles of the IP protocol. Messing with it is
|
|
exceedingly perilous.</P>
|
|
<P>Fairly often a situation comes up where a company has several
|
|
branches, all using the same<A href="#non-routable"> non-routable
|
|
addresses</A>, perhaps 192.168.0.0/24. This works fine as long as those
|
|
nets are kept distinct. The<A href="#masq"> IP masquerading</A> on
|
|
their firewalls ensures that packets reaching the Internet carry the
|
|
firewall address, not the private address.</P>
|
|
<P>This can break down when IPsec enters the picture. FreeS/WAN builds a
|
|
tunnel that pokes through both masquerades and delivers packets from<VAR>
|
|
leftsubnet</VAR> to<VAR> rightsubnet</VAR> and vice versa. For this to
|
|
work, the two subnets<EM> must</EM> be distinct.</P>
|
|
<P>There are several solutions to this problem.</P>
|
|
<P>Usually, you<STRONG> re-number the subnets</STRONG>. Perhaps the
|
|
Vancouver office becomes 192.168.101.0/24, Calgary 192.168.102.0/24 and
|
|
so on. FreeS/WAN can happily handle this. With, for example<VAR>
|
|
leftsubnet=192.168.101.0/24</VAR> and<VAR> rightsubnet=192.168.102.0/24</VAR>
|
|
in a connection description, any machine in Calgary can talk to any
|
|
machine in Vancouver. If you want to be more restrictive and use
|
|
something like<VAR> leftsubnet=192.168.101.128/25</VAR> and<VAR>
|
|
rightsubnet=192.168.102.240/28</VAR> so only certain machines on each
|
|
end have access to the tunnel, that's fine too.</P>
|
|
<P>You could also<STRONG> split the subnet</STRONG> into smaller ones,
|
|
for example using<VAR> 192.168.1.0/25</VAR> in Vancouver and<VAR>
|
|
rightsubnet=192.168.0.128/25</VAR> in Calgary.</P>
|
|
<P>Alternately, you can just<STRONG> give up routing</STRONG> directly
|
|
to machines on the subnets. Omit the<VAR> leftsubnet</VAR> and<VAR>
|
|
rightsubnet</VAR> parameters from your connection descriptions. Your
|
|
IPsec tunnels will then run between the public interfaces of the two
|
|
firewalls. Packets will be masqueraded both before they are put into
|
|
tunnels and after they emerge. Your Vancouver client machines will see
|
|
only one Calgary machine, the firewall.</P>
|
|
<H3><A name="road.masq">Can I assign a road warrior an address on my net
|
|
(a virtual identity)?</A></H3>
|
|
<P>Often it would be convenient to be able to give a Road Warrior an IP
|
|
address which appears to be on the local network. Some IPsec
|
|
implementations have support for this, sometimes calling the feature
|
|
"virtual identity".</P>
|
|
<P>Currently (Sept 2002) FreeS/WAN does not support this, and we have no
|
|
definite plans to add it. The difficulty is that is not yet a standard
|
|
mechanism for it. There is an Internet Draft for a method of doing it
|
|
using<A href="#DHCP"> DHCP</A> which looks promising. FreeS/WAN may
|
|
support that in a future release.</P>
|
|
<P>In the meanwhile, you can do it yourself using the Linux iproute2(8)
|
|
facilities. Details are in<A href="http://www.av8n.com/vpn/iproute2.htm">
|
|
this paper</A>.</P>
|
|
<P>Another method has also been discussed on the mailing list.:</P>
|
|
<UL>
|
|
<LI>You can use a variant of the<A href="#extruded.config"> extruded
|
|
subnet</A> procedure.</LI>
|
|
<LI>You have to avoid having the road warrior's assigned address within
|
|
the range you actually use at home base. See previous question.</LI>
|
|
<LI>On the other hand, you want the roadwarrior's address to be within
|
|
the range that<EM> seems</EM> to be on your network.</LI>
|
|
</UL>
|
|
<P>For example, you might have:</P>
|
|
<DL>
|
|
<DT>leftsubnet=a.b.c.0/25</DT>
|
|
<DD>head office network</DD>
|
|
<DT>rightsubnet=a.b.c.129/32</DT>
|
|
<DD>extruded to a road warrior. Note that this is not in a.b.c.0/25</DD>
|
|
<DT>a.b.c.0/24</DT>
|
|
<DD>whole network, including both the above</DD>
|
|
</DL>
|
|
<P>You then set up routing so that the office machines use the IPsec
|
|
gateway as their route to a.b.c.128/25. The leftsubnet parameter tells
|
|
the road warriors to use tunnels to reach a.b.c.0/25, so you should
|
|
have two-way communication. Depending or your network and applications,
|
|
there may be some additional work to do on DNS or Windows configuration</P>
|
|
<H3><A name="road.many">Can I support many road warriors with one
|
|
gateway?</A></H3>
|
|
<P>Yes. This is easily done, using</P>
|
|
<DL>
|
|
<DT>either RSA authentication</DT>
|
|
<DD>standard in the FreeS/WAN distribution</DD>
|
|
<DT>or X.509 certificates</DT>
|
|
<DD>requires<A href="#PKIcert"> Super FreeS/WAN or a patch</A>.</DD>
|
|
</DL>
|
|
<P>In either case, each Road Warrior must have a different key or
|
|
certificate.</P>
|
|
<P>It is also possible using pre-shared key authentication, though we
|
|
don't recommend this; see the<A href="#road.PSK"> next question</A> for
|
|
details.</P>
|
|
<P>If you expect to have more than a few dozen Road Warriors connecting
|
|
simultaneously, you may need a fairly powerful gateway machine. See our
|
|
document on<A href="performance.html"> FreeS/WAN performance</A>.</P>
|
|
<H3><A name="road.PSK">Can I have many road warriors using shared secret
|
|
authentication?</A></H3>
|
|
<P><STRONG>Yes, but avoid it if possible</STRONG>.</P>
|
|
<P>You can have multiple Road Warriors using shared secret
|
|
authentication<STRONG> only if they all use the same secret</STRONG>.
|
|
You must also set:</P>
|
|
<P></P>
|
|
<PRE> uniqueids=no </PRE>
|
|
<P>in the connection definition.</P>
|
|
<P>Why it's less secure:</P>
|
|
<UL>
|
|
<LI>If you have many users, it becomes almost certain the secret will
|
|
leak</LI>
|
|
<LI>The secret becomes quite valuable to an attacker</LI>
|
|
<LI>All users authenticate the same way, so the gateway cannot tell them
|
|
apart for logging or access control purposes</LI>
|
|
<LI>Changing the secret is difficult. You have to securely notify all
|
|
users.</LI>
|
|
<LI>If you find out the secret has been compromised, you can change it,
|
|
but then what? None of your users can connect without the new secret.
|
|
How will you notify them all, quickly and securely, without using the
|
|
VPN?</LI>
|
|
</UL>
|
|
<P>This is a designed-in limitation of the<A href="#IKE"> IKE</A> key
|
|
negotiation protocol, not a problem with our implementation.</P>
|
|
<P><STRONG>We very strongly recommend that you avoid using shared secret
|
|
authentication for multiple Road Warriors.</STRONG> Use RSA
|
|
authentication instead.</P>
|
|
<P>The longer story: When using shared secrets, the protocol requires
|
|
that the responding gateway be able to determine which secret to use at
|
|
a time when all it knows about the initiator is an IP address. This
|
|
works fine if you know the initiator's address in advance and can use
|
|
it to look up the appropiriate secret. However, it fails for Road
|
|
Warriors since the gateway cannot know their IP addresses in advance.</P>
|
|
<P>With RSA signatures (or certificates) the protocol is slightly
|
|
different. The initiator provides an identifier early in the exchange
|
|
and the responder can use that identifier to look up the correct key or
|
|
certificate. See<A href="#road.many"> above</A>.</P>
|
|
<H3><A name="QoS">Can I use Quality of Service routing with FreeS/WAN?</A>
|
|
</H3>
|
|
<P>From project technical lead Henry Spencer:</P>
|
|
<PRE>> Do QoS add to FreeS/WAN?
|
|
> For example integrating DiffServ and FreeS/WAN?
|
|
|
|
With a current version of FreeS/WAN, you will have to add hidetos=no to
|
|
the config-setup section of your configuration file. By default, the TOS
|
|
field of tunnel packets is zeroed; with hidetos=no, it is copied from the
|
|
packet inside. (This is a modest security hole, which is why it is no
|
|
longer the default.)
|
|
|
|
DiffServ does not interact well with tunneling in general. Ways of
|
|
improving this are being studied.</PRE>
|
|
<P>Copying the<A href="#TOS"> TOS</A> (type of service) information from
|
|
the encapsulated packet to the outer header reveals the TOS information
|
|
to an eavesdropper. This does not tell him much, but it might be of use
|
|
in<A href="#traffic"> traffic analysis</A>. Since we do not have to
|
|
give it to him, our default is not to.</P>
|
|
<P>Even with the TOS hidden, you can still:</P>
|
|
<UL>
|
|
<LI>apply QOS rules to the tunneled (ESP) packets; for example, by
|
|
giving ESP packets a certain priority.</LI>
|
|
<LI>apply QOS rules to the packets as they enter or exit the tunnel via
|
|
an IPsec virtual interface (eg.<VAR> ipsec0</VAR>).</LI>
|
|
</UL>
|
|
<P>See<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> for more
|
|
on the<VAR> hidetos=</VAR> parameter.</P>
|
|
<H3><A name="deadtunnel">Can I recognise dead tunnels and shut them
|
|
down?</A></H3>
|
|
<P>There is no general mechanism to do this is in the IPsec protocols.</P>
|
|
<P>From time to time, there is discussion on the IETF Working Group<A href="#ietf">
|
|
mailing list</A> of adding a "keep-alive" mechanism (which some say
|
|
should be called "make-dead"), but it is a fairly complex problem and
|
|
no consensus has been reached on whether or how it should be done.</P>
|
|
<P>The protocol does have optional<A href="#ignore"> delete-SA</A>
|
|
messages which one side can send when it closes a connection in hopes
|
|
this will cause the other side to do the same. FreeS/WAN does not
|
|
currently support these. In any case, they would not solve the problem
|
|
since:</P>
|
|
<UL>
|
|
<LI>a gateway that crashes or hangs would not send the messages</LI>
|
|
<LI>the sender is not required to send them</LI>
|
|
<LI>they are not authenticated, so any receiver that trusts them leaves
|
|
itself open to a<A href="#DOS"> denial of service</A> attack</LI>
|
|
<LI>the receiver is not required to do anything about them</LI>
|
|
<LI>the receiver cannot acknowledge them; the protocol provides no
|
|
mechanism for that</LI>
|
|
<LI>since they are not acknowledged, the sender cannot rely on them</LI>
|
|
</UL>
|
|
<P>However, connections do have limited lifetimes and you can control
|
|
how many attempts your gateway makes to rekey before giving up. For
|
|
example, you can set:</P>
|
|
<PRE>conn default
|
|
keyingtries=3
|
|
keylife=30m</PRE>
|
|
<P>With these settings old connections will be cleaned up. Within 30
|
|
minutes of the other end dying, rekeying will be attempted. If it
|
|
succeeds, the new connection replaces the old one. If it fails, no new
|
|
connection is created. Either way, the old connection is taken down
|
|
when its lifetime expires.</P>
|
|
<P>Here is a mailing list message on the topic from FreeS/WAN tech
|
|
support person Claudia Schmeing:</P>
|
|
<PRE>You ask how to determine whether a tunnel is redundant:
|
|
|
|
> Can anybody explain the best way to determine this. Esp when a RW has
|
|
> disconnected? I thought 'ipsec auto --status' might be one way.
|
|
|
|
If a tunnel goes down from one end, Linux FreeS/WAN on the
|
|
other end has no way of knowing this until it attempts to rekey.
|
|
Once it tries to rekey and fails, it will 'know' that the tunnel is
|
|
down.
|
|
|
|
Because it doesn't have a way of knowing the state until this point,
|
|
it will also not be able to tell you the state via ipsec auto --status.
|
|
|
|
> However, comparing output from a working tunnel with that of one that
|
|
> was closed
|
|
> did not show clearly show tunnel status.
|
|
|
|
If your tunnel is down but not 'unrouted' (see man ipsec_auto), you
|
|
should not be able to ping the opposite side of the tunnel. You can
|
|
use this as an indicator of tunnel status.
|
|
|
|
On a related note, you may be interested to know that as of 1.7,
|
|
redundant tunnels caused by RW disconnections are likely to be
|
|
less of a pain. From doc/CHANGES:
|
|
|
|
There is a new configuration parameter, uniqueids, to control a new Pluto
|
|
option: when a new connection is negotiated with the same ID as an old
|
|
one, the old one is deleted immediately. This should help eliminate
|
|
dangling Road Warrior connections when the same Road Warrior reconnects.
|
|
It thus requires that IDs not be shared by hosts (a previously legal but
|
|
probably useless capability). NOTE WELL: the sample ipsec.conf now has
|
|
uniqueids=yes in its config-setup section.
|
|
|
|
|
|
Cheers,
|
|
|
|
Claudia</PRE>
|
|
<H3><A name="demanddial">Can I build IPsec tunnels over a demand-dialed
|
|
link?</A></H3>
|
|
<P>This is possible, but not easy. FreeS/WAN technical lead Henry
|
|
Spencer wrote:</P>
|
|
<PRE>> 5. If the ISDN link goes down in between and is reestablished, the SAs
|
|
> are still up but the eroute are deleted and the IPsec interface shows
|
|
> garbage (with ifconfig)
|
|
> 6. Only restarting IPsec will bring the VPN back online.
|
|
|
|
This one is awkward to solve. If the real interface that the IPsec
|
|
interface is mounted on goes down, it takes most of the IPsec machinery
|
|
down with it, and a restart is the only good way to recover.
|
|
|
|
The only really clean fix, right now, is to split the machines in two:
|
|
|
|
1. A minimal machine serves as the network router, and only it is aware
|
|
that the link goes up and down.
|
|
|
|
2. The IPsec is done on a separate gateway machine, which thinks it has
|
|
a permanent network connection, via the router.
|
|
|
|
This is clumsy but it does work. Trying to do both functions within a
|
|
single machine is tricky. There is a software package (diald) which will
|
|
give the illusion of a permanent connection for demand-dialed modem
|
|
connections; I don't know whether it's usable for ISDN, or whether it can
|
|
be made to cooperate properly with FreeS/WAN.
|
|
|
|
Doing a restart each time the interface comes up *does* work, although it
|
|
is a bit painful. I did that with PPP when I was running on a modem link;
|
|
it wasn't hard to arrange the PPP scripts to bring IPsec up and down at
|
|
the right times. (I'd meant to investigate diald but never found time.)
|
|
|
|
In principle you don't need to do a complete restart on reconnect, but you
|
|
do have to rebuild some things, and we have no nice clean way of doing
|
|
only the necessary parts.</PRE>
|
|
<P>In the same thread, one user commented:</P>
|
|
<PRE>Subject: Re: linux-ipsec: IPsec and Dial Up Connections
|
|
Date: Wed, 22 Nov 2000
|
|
From: Andy Bradford <[email protected]>
|
|
|
|
On Wed, 22 Nov 2000 19:47:11 +0100, Philip Reetz wrote:
|
|
|
|
> Are there any ideas what might be the cause of the problem and any way
|
|
> to work around it.
|
|
> Any help is highly appreciated.
|
|
|
|
On my laptop, when using ppp there is a ip-up script in /etc/ppp that
|
|
will be executed each time that the ppp interface is brought up.
|
|
Likewise there is an ip-down script that is called when it is taken
|
|
down. You might consider custimzing those to stop and start FreeS/WAN
|
|
with each connection. I believe that ISDN uses the same files, though
|
|
I could be wrong---there should be something similar though.</PRE>
|
|
<H3><A name="GRE">Can I build GRE, L2TP or PPTP tunnels over IPsec?</A></H3>
|
|
<P>Yes. Normally this is not necessary, but it is useful in a few
|
|
special cases. For example, if you must route non-IP packets such as
|
|
IPX, you will need to use a tunneling protocol that can route these
|
|
packets. IPsec can be layered around it for extra security. Another
|
|
example: you can provide failover protection for high availability (HA)
|
|
environments by combining IPsec with other tools. Ken Bantoft describes
|
|
one such setup in<A HREF="http://www.freeswan.ca/docs/HA"> Using
|
|
FreeS/WAN with Linux-HA, GRE, OSPF and BGP for enterprise grade VPN
|
|
solutions</A>.</P>
|
|
<P>GRE over IPsec is covered as part of<A HREF="http://www.freeswan.ca/docs/HA">
|
|
that document</A>.<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00209.html">
|
|
Here are links</A> to other GRE resources. Jacco de Leuw has created<A HREF="http://www.jacco2.dds.nl/networking/">
|
|
this page on L2TP over IPsec</A> with instructions for FreeS/WAN and
|
|
several other brands of IPsec software.</P>
|
|
<P>Please let us know of other useful links via the<A HREF="mail.html">
|
|
mailing lists</A>.</P>
|
|
<H3><A name="NetBIOS">... use Network Neighborhood (Samba, NetBIOS) over
|
|
IPsec?</A></H3>
|
|
<P>Your local PC needs to know how to translate NetBIOS names to IP
|
|
addresses. It may do this either via a local LMHOSTS file, or using a
|
|
local or remote WINS server. The WINS server is preferable since it
|
|
provides a centralized source of the information to the entire network.
|
|
To use a WINS server over the<A HREF="#VPN"> VPN</A> (or any IP-based
|
|
network), you must enable "NetBIOS over TCP".</P>
|
|
<P><A HREF="http://www.samba.org">Samba</A> can emulate a WINS server on
|
|
Linux.</P>
|
|
<P> See also several discussions in our<A HREF="http://lists.freeswan.org/pipermail/users/2002-September/thread.html">
|
|
September 2002 Users archives</A></P>
|
|
<H2><A name="setup.faq">Life's little mysteries</A></H2>
|
|
<P>FreeS/WAN is a fairly complex product. (Neither the networks it runs
|
|
on nor the protocols it uses are simple, so it could hardly be
|
|
otherwise.) It therefore sometimes exhibits behaviour which can be
|
|
somewhat confusing, or has problems which are not easy to diagnose.
|
|
This section tries to explain those problems.</P>
|
|
<P>Setup and configuration of FreeS/WAN are covered in other
|
|
documentation sections:</P>
|
|
<UL>
|
|
<LI><A href="quickstart.html">basic setup and configuration</A></LI>
|
|
<LI><A href="adv_config.html">advanced configuration</A></LI>
|
|
<LI><A href="trouble.html">Troubleshooting</A></LI>
|
|
</UL>
|
|
<P>However, we also list some of the commonest problems here.</P>
|
|
<H3><A name="cantping">I cannot ping ....</A></H3>
|
|
<P>This question is dealt with in the advanced configuration section
|
|
under the heading<A href="#multitunnel"> multiple tunnels</A>.</P>
|
|
<P>The standard subnet-to-subnet tunnel protects traffic<STRONG> only
|
|
between the subnets</STRONG>. To test it, you must use pings that go
|
|
from one subnet to the other.</P>
|
|
<P>For example, suppose you have:</P>
|
|
<PRE> subnet a.b.c.0/24
|
|
|
|
|
eth1 = a.b.c.1
|
|
gate1
|
|
eth0 = 192.0.2.8
|
|
|
|
|
|
|
~ internet ~
|
|
|
|
|
|
|
eth0 = 192.0.2.11
|
|
gate2
|
|
eth1 = x.y.z.1
|
|
|
|
|
subnet x.y.z.0/24</PRE>
|
|
<P>and the connection description:</P>
|
|
<PRE>conn abc-xyz
|
|
left=192.0.2.8
|
|
leftsubnet=a.b.c.0/24
|
|
right=192.0.2.11
|
|
rightsubnet=x.y.z.0/24</PRE>
|
|
<P>You can test this connection description only by sending a ping that
|
|
will actually go through the tunnel. Assuming you have machines at
|
|
addresses a.b.c.2 and x.y.z.2, pings you might consider trying are:</P>
|
|
<DL>
|
|
<DT>ping from x.y.z.2 to a.b.c.2 or vice versa</DT>
|
|
<DD>Succeeds if tunnel is working. This is the<STRONG> only valid test
|
|
of the tunnel</STRONG>.</DD>
|
|
<DT>ping from gate2 to a.b.c.2 or vice versa</DT>
|
|
<DD><STRONG>Does not use tunnel</STRONG>. gate2 is not on protected
|
|
subnet.</DD>
|
|
<DT>ping from gate1 to x.y.z.2 or vice versa</DT>
|
|
<DD><STRONG>Does not use tunnel</STRONG>. gate1 is not on protected
|
|
subnet.</DD>
|
|
<DT>ping from gate1 to gate2 or vice versa</DT>
|
|
<DD><STRONG>Does not use tunnel</STRONG>. Neither gate is on a protected
|
|
subnet.</DD>
|
|
</DL>
|
|
<P>Only the first of these is a useful test of this tunnel. The others
|
|
do not use the tunnel. Depending on other details of your setup and
|
|
routing, they:</P>
|
|
<UL>
|
|
<LI>either fail, telling you nothing about the tunnel</LI>
|
|
<LI>or succeed, telling you nothing about the tunnel since these packets
|
|
use some other route</LI>
|
|
</UL>
|
|
<P>In some cases, you may be able to get around this. For the example
|
|
network above, you could use:</P>
|
|
<PRE> ping -I a.b.c.1 x.y.z.1</PRE>
|
|
<P>Both the adresses given are within protected subnets, so this should
|
|
go through the tunnel.</P>
|
|
<P>If required, you can build additional tunnels so that all the
|
|
machines involved can talk to all the others. See<A href="#multitunnel">
|
|
multiple tunnels</A> in the advanced configuration document for
|
|
details.</P>
|
|
<H3><A name="forever">It takes forever to ...</A></H3>
|
|
<P>Users fairly often report various problems involving long delays,
|
|
sometimes on tunnel setup and sometimes on operations done through the
|
|
tunnel, occasionally on simple things like ping or more often on more
|
|
complex operations like doing NFS or Samba through the tunnel.</P>
|
|
<P>Almost always, these turn out to involve failure of a DNS lookup. The
|
|
timeouts waiting for DNS are typically set long so that you won't time
|
|
out when a query involves multiple lookups or long paths. Genuine
|
|
failures therefore produce long delays before they are detected.</P>
|
|
<P>A mailing list message from project technical lead Henry Spencer:</P>
|
|
<PRE>> ... when i run /etc/rc.d/init.d/ipsec start, i get:
|
|
> ipsec_setup: Starting FreeS/WAN IPsec 1.5...
|
|
> and it just sits there, doesn't give back my bash prompt.
|
|
|
|
Almost certainly, the problem is that you're using DNS names in your
|
|
ipsec.conf, but DNS lookups are not working for some reason. You will
|
|
get your prompt back... eventually. But the DNS timeouts are long.
|
|
Doing something about this is on our list, but it is not easy.</PRE>
|
|
<P>In the meanwhile, we recommend that connection descriptions in<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> use numeric IP addresses rather than names which will
|
|
require a DNS lookup.</P>
|
|
<P>Names that do not require a lookup are fine. For example:</P>
|
|
<UL>
|
|
<LI>a road warrior might use the identity<VAR>
|
|
[email protected]</VAR></LI>
|
|
<LI>the gateway might use<VAR> [email protected]</VAR></LI>
|
|
</UL>
|
|
<P>These are fine. The @ sign prevents any DNS lookup. However, do not
|
|
attempt to give the gateway address as<VAR> left=camelot.example.org</VAR>
|
|
. That requires a lookup.</P>
|
|
<P>A post from one user after solving a problem with long delays:</P>
|
|
<PRE>Subject: Final Answer to Delay!!!
|
|
Date: Mon, 19 Feb 2001
|
|
From: "Felippe Solutions" <[email protected]>
|
|
|
|
Sorry people, but seems like the Delay problem had nothing to do with
|
|
freeswan.
|
|
|
|
The problem was DNS as some people sad from the beginning, but not the way
|
|
they thought it was happening. Samba, ssh, telnet and other apps try to
|
|
reverse lookup addresses when you use IP numbers (Stupid that ahh).
|
|
|
|
I could ping very fast because I always ping with "-n" option, but I don't
|
|
know the option on the other apps to stop reverse addressing so I don't use
|
|
it.</PRE>
|
|
<P>This post is fairly typical. These problems are often tricky and
|
|
frustrating to diagnose, and most turn out to be DNS-related.</P>
|
|
<P>One suggestion for diagnosis: test with both names and addresses if
|
|
possible. For example, try all of:</P>
|
|
<UL>
|
|
<LI>ping<VAR> address</VAR></LI>
|
|
<LI>ping -n<VAR> address</VAR></LI>
|
|
<LI>ping<VAR> name</VAR></LI>
|
|
</UL>
|
|
<P>If these behave differently, the problem must be DNS-related since
|
|
the three commands do exactly the same thing except for DNS lookups.</P>
|
|
<H3><A name="route">I send packets to the tunnel with route(8) but they
|
|
vanish</A></H3>
|
|
<P>IPsec connections are designed to carry only packets travelling
|
|
between pre-defined connection endpoints. As project technical lead
|
|
Henry Spencer put it:</P>
|
|
<BLOCKQUOTE> IPsec tunnels are not just virtual wires; they are virtual
|
|
wires with built-in access controls. Negotiation of an IPsec tunnel
|
|
includes negotiation of access rights for it, which don't include
|
|
packets to/from other IP addresses. (The protocols themselves are quite
|
|
inflexible about this, so there are limits to what we can do about it.)</BLOCKQUOTE>
|
|
<P>For fairly obvious security reasons, and to comply with the IPsec
|
|
RFCs,<A href="#KLIPS"> KLIPS</A> drops any packets it receives that are
|
|
not allowed on the tunnels currently defined. So if you send it packets
|
|
with<VAR> route(8)</VAR>, and suitable tunnels are not defined, the
|
|
packets vanish. Whether this is reported in the logs depends on the
|
|
setting of<VAR> klipsdebug</VAR> in your<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> file.</P>
|
|
<P>To rescue vanishing packets, you must ensure that suitable tunnels
|
|
for them exist, by editing the connection descriptions in<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A>. For example, supposing you have a simple setup:</P>
|
|
<PRE> leftsubnet -- leftgateway === internet === roadwarrior</PRE>
|
|
<P>If you want to give the roadwarrior access to some resource that is
|
|
located behind the left gateway but is not in the currently defined
|
|
left subnet, then the usual procedure is to define an additional tunnel
|
|
for those packets by creating a new connection description.</P>
|
|
<P>In some cases, it may be easier to alter an existing connection
|
|
description, enlarging the definition of<VAR> leftsubnet</VAR>. For
|
|
example, instead of two connection descriptions with 192.168.8.0/24 and
|
|
192.168.9.0/24 as their<VAR> leftsubnet</VAR> parameters, you can use a
|
|
single description with 192.168.8.0/23.</P>
|
|
<P>If you have multiple endpoints on each side, you need to ensure that
|
|
there is a route for each pair of endpoints. See this<A href="#multitunnel">
|
|
example</A>.</P>
|
|
<H3><A name="down_route">When a tunnel goes down, packets vanish</A></H3>
|
|
<P>This is a special case of the vanishing packet problem described in
|
|
the previous question. Whenever KLIPS sees packets for which it does
|
|
not have a tunnel, it drops them.</P>
|
|
<P>When a tunnel goes away, either because negotiations with the other
|
|
gateway failed or because you gave an<VAR> ipsec auto --down</VAR>
|
|
command, the route to its other end is left pointing into KLIPS, and
|
|
KLIPS will drop packets it has no tunnel for.</P>
|
|
<P>This is a documented design decision, not a bug. FreeS/WAN must not
|
|
automatically adjust things to send packets via another route. The
|
|
other route might be insecure.</P>
|
|
<P>Of course, re-routing may be necessary in many cases. In those cases,
|
|
you have to do it manually or via scripts. We provide the<VAR> ipsec
|
|
auto --unroute</VAR> command for these cases.</P>
|
|
<P>From<A href="manpage.d/ipsec_auto.8.html"> ipsec_auto(8)</A>:</P>
|
|
<BLOCKQUOTE> Normally, pluto establishes a route to the destination
|
|
specified for a connection as part of the --up operation. However, the
|
|
route and only the route can be established with the --route operation.
|
|
Until and unless an actual connection is established, this discards any
|
|
packets sent there, which may be preferable to having them sent
|
|
elsewhere based on a more general route (e.g., a default route).</BLOCKQUOTE><BLOCKQUOTE>
|
|
Normally, pluto's route to a destination remains in place when a --down
|
|
operation is used to take the connection down (or if connection setup,
|
|
or later automatic rekeying, fails). This permits establishing a new
|
|
connection (perhaps using a different specification; the route is
|
|
altered as necessary) without having a ``window'' in which packets
|
|
might go elsewhere based on a more general route. Such a route can be
|
|
removed using the --unroute operation (and is implicitly removed by
|
|
--delete).</BLOCKQUOTE>
|
|
<P>See also this mailing list<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00523.html">
|
|
message</A>.</P>
|
|
<H3><A name="firewall_ate">The firewall ate my packets!</A></H3>
|
|
<P>If firewalls filter out:</P>
|
|
<UL>
|
|
<LI>either the UDP port 500 packets used in IKE negotiations</LI>
|
|
<LI>or the ESP and AH (protocols 50 and 51) packets used to implement
|
|
the IPsec tunnel</LI>
|
|
</UL>
|
|
<P>then IPsec cannot work. The first thing to check if packets seem to
|
|
be vanishing is the firewall rules on the two gateway machines and any
|
|
other machines along the path that you have access to.</P>
|
|
<P>For details, see our document on<A href="firewall.html"> firewalls</A>
|
|
.</P>
|
|
<P>Some advice from technical lead Henry Spencer on diagnosing such
|
|
problems:</P>
|
|
<PRE>> > Packets vanishing between the hardware interface and the ipsecN interface
|
|
> > is usually the result of firewalls not being configured to let them in...
|
|
>
|
|
> Thanks for the suggestion. If only it were that simple! My ipchains startup
|
|
> script does take care of that, but just in case I manually inserted rules
|
|
> accepting everything from london on dublin. No difference.
|
|
|
|
The other thing to check is whether the "RX packets dropped" count on the
|
|
ipsecN interface (run "ifconfig ipsecN", for N=1 or whatever, to see the
|
|
counts) is rising. If so, then there's some sort of configuration mismatch
|
|
between the two ends, and IPsec itself is rejecting them. If none of the
|
|
ipsecN counts is rising, then the packets are never reaching the IPsec
|
|
machinery, and the problem is almost certainly in firewalls etc.</PRE>
|
|
<H3><A name="dropconn">Dropped connections</A></H3>
|
|
<P>Networks being what they are, IPsec connections can be broken for any
|
|
number of reasons, ranging from hardware failures to various software
|
|
problems such as the path MTU problems discussed<A href="#pmtu.broken">
|
|
elsewhere in the FAQ</A>. Fortunately, various diagnostic tools exist
|
|
that help you sort out many of the possible problems.</P>
|
|
<P>There is one situation, however, where FreeS/WAN (using default
|
|
settings) may destroy a connection for no readily apparent reason. This
|
|
occurs when things are<STRONG> misconfigured</STRONG> so that<STRONG>
|
|
two tunnels</STRONG> from the same gateway expect<STRONG> the same
|
|
subnet on the far end</STRONG>.</P>
|
|
<P>In this situation, the first tunnel comes up fine and works until the
|
|
second is established. At that point, because of the way we track
|
|
connections internally, the first tunnel ceases to exist as far as this
|
|
gateway is concerned. Of course the far end does not know that, and a
|
|
storm of error messages appears on both systems as it tries to use the
|
|
tunnel.</P>
|
|
<P>If the far end gives up, goes back to square one and negotiates a new
|
|
tunnel, then that wipes out the second tunnel and ...</P>
|
|
<P>The solution is simple.<STRONG> Do not build multiple conn
|
|
descriptions with the same remote subnet</STRONG>.</P>
|
|
<P>This is actually intended to be a feature, rather than a bug.
|
|
Consider the situation where a single remote system goes down, then
|
|
comes back up and reconnects to the gateway. It is useful to have the
|
|
gateway tear down the old tunnel and recover resources when the
|
|
reconnection is made. It recognises that situation by checking the
|
|
remote subnet for each tunnel it builds and discarding duplicates. This
|
|
works fine as long as you don't configure multiple tunnels with the
|
|
same remote subnet.</P>
|
|
<P>If this behaviour is inconvenient for you, you can disable it by
|
|
setting<VAR> uniqueids=no</VAR> in<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A>.</P>
|
|
<H3><A name="defaultroutegone">Disappearing %defaultroute</A></H3>
|
|
<P>When an underlying connection (eg. ppp) goes down, FreeS/WAN will not
|
|
recover properly without a little help. Here are the symptoms that
|
|
FreeS/WAN user Michael Carmody noticed:</P>
|
|
<PRE>
|
|
> After about 24 hours the freeswan connection takes over the default route.
|
|
>
|
|
> i.e instead of deafult gateway pointing to the router via eth0, it becomes a
|
|
> pointer to the router via ipsec0.
|
|
|
|
> All internet access is then lost as all replies (and not just the link I
|
|
> wanted) are routed out ipsec0 and the router doesn't respond to the ipsec
|
|
> traffic.
|
|
</PRE>
|
|
<P>If you're using a FreeS/WAN 2.x/KLIPS system, simply re-attach the
|
|
IPsec virtual interface with<EM> ipsec tnconfig</EM> command such as:</P>
|
|
<PRE> ipsec tnconfig --attach --virtual ipsec0 --physical ppp0</PRE>
|
|
<P>In your command, name the physical and virtual interfaces as they
|
|
appear paired on your system during regular uptime. For a system with
|
|
several physical/virtual interface pairs on flaky links, you'll need
|
|
more than one such command. If you're using FreeS/WAN 1.x, you must
|
|
restart FreeS/WAN, which is more time consuming.</P>
|
|
<P><A href="http://lists.freeswan.org/pipermail/design/2002-July/003070.html">
|
|
Here</A> is a script which can help to automate the process of
|
|
FreeS/WAN restart at need. It could easily be adapted to use tnconfig
|
|
instead.</P>
|
|
<H3><A name="tcpdump.faq">TCPdump on the gateway shows strange things</A>
|
|
</H3>
|
|
As another user pointed out, keeping the connect
|
|
<P>Attempting to look at IPsec packets by running monitoring tools on
|
|
the IPsec gateway machine can produce silly results. That machine is
|
|
mangling the packets for IPsec, and possibly for firewall or NAT
|
|
purposes as well. If the internals of the machine's IP stack are not
|
|
what the monitoring tool expects, then the tool can misinterpret them
|
|
and produce nonsense output.</P>
|
|
<P>See our<A href="#tcpdump.test"> testing</A> document for more detail.</P>
|
|
<H3><A name="no_trace">Traceroute does not show anything between the
|
|
gateways</A></H3>
|
|
<P>As far as traceroute can see, the two gateways are one hop apart; the
|
|
data packet goes directly from one to the other through the tunnel. Of
|
|
course the outer packets that implement the tunnel pass through
|
|
whatever lies between the gateways, but those packets are built and
|
|
dismantled by the gateways. Traceroute does not see them and cannot
|
|
report anything about their path.</P>
|
|
<P>Here is a mailing list message with more detail.</P>
|
|
<PRE>Date: Mon, 14 May 2001
|
|
To: [email protected]
|
|
From: "John S. Denker" <[email protected]<
|
|
Subject: Re: traceroute: one virtual hop
|
|
|
|
At 02:20 PM 5/14/01 -0400, Claudia Schmeing wrote:
|
|
>
|
|
>> > A bonus question: traceroute in subnet to subnet enviroment looks like:
|
|
>> >
|
|
>> > traceroute to andris.dmz (172.20.24.10), 30 hops max, 38 byte packets
|
|
>> > 1 drama (172.20.1.1) 0.716 ms 0.942 ms 0.434 ms
|
|
>> > 2 * * *
|
|
>> > 3 andris.dmz (172.20.24.10) 73.576 ms 78.858 ms 79.434 ms
|
|
>> >
|
|
>> > Why aren't there the other hosts which take part in the delivery during
|
|
> * * * ?
|
|
>
|
|
>If there is an ipsec tunnel between GateA and Gate B, this tunnel forms a
|
|
>'virtual wire'. When it is tunneled, the original packet becomes an inner
|
|
>packet, and new ESP and/or AH headers are added to create an outer packet
|
|
>around it. You can see an example of how this is done for AH at
|
|
>doc/ipsec.html#AH . For ESP it is similar.
|
|
>
|
|
>Think about the packet's path from the inner packet's perspective.
|
|
>It leaves the subnet, goes into the tunnel, and re-emerges in the second
|
|
>subnet. This perspective is also the only one available to the
|
|
>'traceroute' command when the IPSec tunnel is up.
|
|
|
|
Claudia got this exactly right. Let me just expand on a couple of points:
|
|
|
|
*) GateB is exactly one (virtual) hop away from GateA. This is how it
|
|
would be if there were a physically private wire from A to B. The
|
|
virtually private connection should work the same, and it does.
|
|
|
|
*) While the information is in transit from GateA to GateB, the hop count
|
|
of the outer header (the "envelope") is being decremented. The hop count
|
|
of the inner header (the "contents" of the envelope) is not decremented and
|
|
should not be decremented. The hop count of the outer header is not
|
|
derived from and should not be derived from the hop count of the inner header.
|
|
|
|
Indeed, even if the packets did time out in transit along the tunnel, there
|
|
would be no way for traceroute to find out what happened. Just as
|
|
information cannot leak _out_ of the tunnel to the outside, information
|
|
cannot leak _into_ the tunnel from outside, and this includes ICMP messages
|
|
from routers along the path.
|
|
|
|
There are some cases where one might wish for information about what is
|
|
happening at the IP layer (below the tunnel layer) -- but the protocol
|
|
makes no provision for this. This raises all sorts of conceptual issues.
|
|
AFAIK nobody has ever cared enough to really figure out what _should_
|
|
happen, let alone implement it and standardize it.
|
|
|
|
*) I consider the "* * *" to be a slight bug. One might wish for it to be
|
|
replaced by "GateB GateB GateB". It has to do with treating host-to-subnet
|
|
traffic different from subnet-to-subnet traffic (and other gory details).
|
|
I fervently hope KLIPS2 will make this problem go away.
|
|
|
|
*) If you want to ask questions about the link from GateA to GateB at the
|
|
IP level (below the tunnel level), you have to ssh to GateA and launch a
|
|
traceroute from there.</PRE>
|
|
<H2><A name="man4debug">Testing in stages</A></H2>
|
|
<P>It is often useful in debugging to test things one at a time:</P>
|
|
<UL>
|
|
<LI>disable IPsec entirely, for example by turning it off with
|
|
chkconfig(8), and make sure routing works</LI>
|
|
<LI>Once that works, try a manually keyed connection. This does not
|
|
require key negotiation between Pluto and the key daemon on the other
|
|
end.</LI>
|
|
<LI>Once that works, try automatically keyed connections</LI>
|
|
<LI>Once IPsec works, add packet compression</LI>
|
|
<LI>Once everything seems to work, try stress tests with large
|
|
transfers, many connections, frequent re-keying, ...</LI>
|
|
</UL>
|
|
<P>FreeS/WAN releases are tested for all of these, so you can be
|
|
reasonably certain they<EM> can</EM> do them all. Of course, that does
|
|
not mean they<EM> will</EM> on the first try, especially if you have
|
|
some unusual configuration.</P>
|
|
<P>The rest of this section gives information on diagnosing the problem
|
|
when each of the above steps fails.</P>
|
|
<H3><A name="nomanual">Manually keyed connections don't work</A></H3>
|
|
<P>Suspect one of:</P>
|
|
<UL>
|
|
<LI>mis-configuration of IPsec system in the /etc/ipsec.conf file
|
|
<BR> common errors are incorrect interface or next hop information</LI>
|
|
<LI>mis-configuration of manual connection in the /etc/ipsec.conf file</LI>
|
|
<LI>routing problems causing IPsec packets to be lost</LI>
|
|
<LI>bugs in KLIPS</LI>
|
|
<LI>mismatch between the transforms we support and those another IPsec
|
|
implementation offers.</LI>
|
|
</UL>
|
|
<H3><A name="spi_error">One manual connection works, but second one
|
|
fails</A></H3>
|
|
<P>This is a fairly common problem when attempting to configure multiple
|
|
manually keyed connections from a single gateway.</P>
|
|
<P>Each connection must be identified by a unique<A href="#SPI"> SPI</A>
|
|
value. For automatic connections, these values are assigned
|
|
automatically. For manual connections, you must set them with<VAR> spi=</VAR>
|
|
statements in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A>.</P>
|
|
<P>Each manual connection must have a unique SPI value in the range
|
|
0x100 to 0x999. Two or more with the same value will fail. For details,
|
|
see our doc section<A href="#prodman"> Using manual keying in
|
|
production</A> and the man page<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A>.</P>
|
|
<H3><A name="man_no_auto">Manual connections work, but automatic keying
|
|
doesn't</A></H3>
|
|
<P>The most common reason for this behaviour is a firewall dropping the
|
|
UDP port 500 packets used in key negotiation.</P>
|
|
<P>Other possibilities:</P>
|
|
<UL>
|
|
<LI>mis-configuration of auto connection in the /etc/ipsec.conf file.
|
|
<P>One common configuration error is forgetting that you need<VAR>
|
|
auto=add</VAR> to load the connection description on the receiving end
|
|
so it recognises the connection when the other end asks for it.</P>
|
|
</LI>
|
|
<LI>error in shared secret in /etc/ipsec.secrets</LI>
|
|
<LI>one gateway lacks a route to the other so Pluto's UDP packets are
|
|
lost</LI>
|
|
<LI>bugs in Pluto</LI>
|
|
<LI>incompatibilities between Pluto's<A href="#IKE"> IKE</A>
|
|
implementation and the IKE at the other end of the tunnel.
|
|
<P>Some possibile problems are discussed in out<A href="interop.html#interop.problem">
|
|
interoperation</A> document.</P>
|
|
</LI>
|
|
</UL>
|
|
<H3><A name="nocomp">IPsec works, but connections using compression fail</A>
|
|
</H3>
|
|
<P>When we first added compression, we saw some problems:</P>
|
|
<UL>
|
|
<LI>compatibility issues with other implementations. We followed the
|
|
RFCs and omitted some extra material that many compression libraries
|
|
add by default. Some other implementations left the extras in</LI>
|
|
<LI>bugs in assembler compression routines on non-Intel CPUs. The
|
|
workaround is to use C code instead of possibly problematic assembler.</LI>
|
|
</UL>
|
|
<P>We have not seen either problem in some time (at least six months as
|
|
I write in March 2002), but if you have some unusual configuration then
|
|
you may see them.</P>
|
|
<H3><A name="pmtu.broken">Small packets work, but large transfers fail</A>
|
|
</H3>
|
|
<P>If tests with ping(1) and a small packet size succeed, but tests or
|
|
transfers with larger packet sizes fail, suspect problems with packet
|
|
fragmentation and perhaps<A href="#pathMTU"> path MTU discovery</A>.</P>
|
|
<P>Our<A href="#bigpacket"> troubleshooting document</A> covers these
|
|
problems. Information on the underlying mechanism is in our<A href="#MTU.trouble">
|
|
background</A> document.</P>
|
|
<H3><A name="subsub">Subnet-to-subnet works, but tests from the gateways
|
|
don't</A></H3>
|
|
<P>This is described under<A href="#cantping"> I cannot ping...</A>
|
|
above.</P>
|
|
<H2><A name="compile.faq">Compilation problems</A></H2>
|
|
<H3><A name="gmp.h_missing">gmp.h: No such file or directory</A></H3>
|
|
<P>Pluto needs the GMP (<STRONG>G</STRONG>NU</P>
|
|
<P><STRONG>M</STRONG>ulti-<STRONG>P</STRONG>recision) library for the
|
|
large integer calculations it uses in<A href="#public"> public key</A>
|
|
cryptography. This error message indicates a failure to find the
|
|
library. You must install it before Pluto will compile.</P>
|
|
<P>The GMP library is included in most Linux distributions. Typically,
|
|
there are two RPMs, libgmp and libgmp-devel, You need to<EM> install
|
|
both</EM>, either from your distribution CDs or from your vendor's web
|
|
site.</P>
|
|
<P>On Debian, a mailing list message reports that the command to give is<VAR>
|
|
apt-get install gmp2</VAR>.</P>
|
|
<P>For more information and the latest version, see the<A href="http://www.swox.com/gmp/">
|
|
GMP home page</A>.</P>
|
|
<H3><A name="noVM">... virtual memory exhausted</A></H3>
|
|
<P>We have had several reports of this message appearing, all on SPARC
|
|
Linux. Here is a mailing message on a solution:</P>
|
|
<PRE>> ipsec_sha1.c: In function `SHA1Transform':
|
|
> ipsec_sha1.c:95: virtual memory exhausted
|
|
|
|
I'm seeing exactly the same problem on an Ultra with 256MB ram and 500
|
|
MB swap. Except I am compiling version 1.5 and its Red Hat 6.2.
|
|
|
|
I can get around this by using -O instead of -O2 for the optimization
|
|
level. So it is probably a bug in the optimizer on the sparc complier.
|
|
I'll try and chase this down on the sparc lists.</PRE>
|
|
<H2><A name="error">Interpreting error messages</A></H2>
|
|
<H3><A name="route-client">route-client (or host) exited with status 7</A>
|
|
</H3>
|
|
<P>Here is a discussion of this error from FreeS/WAN "listress" (mailing
|
|
list tech support person) Claudia Schmeing. The "FAQ on the network
|
|
unreachable error" which she refers to is the next question below.</P>
|
|
<PRE>> I reached the point where the two boxes (both on dial-up connections, but
|
|
> treated as static IPs by getting the IP and editing ipsec.conf after the
|
|
> connection is established) to the point where they exchange some info, but I
|
|
> get an error like "route-client command exited with status 7 \n internal
|
|
> error".
|
|
> Where can I find a description of this error?
|
|
|
|
In general, if the FAQ doesn't cover it, you can search the mailing list
|
|
archives - I like to use
|
|
http://www.sandelman.ottawa.on.ca/linux-ipsec/
|
|
but you can see doc/mail.html for different archive formats.
|
|
|
|
|
|
Your error comes from the _updown script, which performs some
|
|
routing and firewall functions to help Linux FreeS/WAN. More info
|
|
is available at doc/firewall.html and man ipsec.conf. Its routing
|
|
is integral to the health of Linux FreeS/WAN; it also provides facility
|
|
to insert custom firewall rules to be executed when you create or destroy
|
|
a connection.
|
|
|
|
Yours is, of course, a routing error. You can be fairly sure the routing
|
|
machinery is saying "network is unreachable". There's a FAQ on the
|
|
"network is unreachable" error, but more information is available now; read on.
|
|
|
|
If your _updown script is recent (for example if it shipped with
|
|
Linux FreeS/WAN 1.91), you will see another debugging line in your logs
|
|
that looks something like this:
|
|
|
|
> output: /usr/local/lib/ipsec/_updown: `route add -net 128.174.253.83
|
|
> netmask 255.255.255.255 dev ipsec0 gw 66.92.93.161' failed
|
|
|
|
This is, of course, the system route command that exited with status 7,
|
|
(ie. failed). Man route for details. Seeing the command typed out yields
|
|
more information. If your _updown script is older, you may wish to update
|
|
it to show the command explicitly.
|
|
|
|
Three parameters fed to the route command: net, netmask and gw [gateway]
|
|
are derived from things you've put in ipsec.conf.
|
|
|
|
Net and netmask are derived from the peer's IP and mask. In more detail:
|
|
|
|
You may see a routing error when routing to a client (ie. subnet), or
|
|
to a host (IPSec gateway or freestanding host; a box that does IPSec for
|
|
itself). In _updown, the "route-client" section is responsible to set up
|
|
the route for IPSec'd (usually, read 'tunneled') packets headed to a
|
|
peer subnet. Similarly, route-host routes IPSec'd packets to a peer host
|
|
or IPSec gateway.
|
|
|
|
When routing to a 'client', net and netmask are ipsec.conf's left- or
|
|
rightsubnet (whichever is not local). Similarly, when routing to a
|
|
'host' the net is left or right. Host netmask is always /32, indicating a
|
|
single machine.
|
|
|
|
Gw is nexthop's value. Again, the value in question is left- or rightnexthop,
|
|
whichever is local. Where left/right or left-/rightnexthop has the special
|
|
value %defaultroute (described in man ipsec.conf), gw will automagically get
|
|
the value of the next hop on the default route.
|
|
|
|
Q: "What's a nexthop and why do I need one?"
|
|
|
|
A: 'nexthop' is a routing kluge; its value is the next hop away
|
|
from the machine that's doing IPSec, and toward your IPSec peer.
|
|
You need it to get the processed packets out of the local system and
|
|
onto the wire. While we often route other packets through the machine
|
|
that's now doing IPSec, and are done with it, this does not suffice here.
|
|
After packets are processed with IPSec, this machine needs to know where
|
|
they go next. Of course using the 'IPSec gateway' as their routing gateway
|
|
would cause an infinite loop! [To visualize this, see the packet flow
|
|
diagram at doc/firewall.html.] To avoid this, we route packets through
|
|
the next hop down their projected path.
|
|
|
|
Now that you know the background, consider:
|
|
1. Did you test routing between the gateways in the absence of Linux
|
|
FreeS/WAN, as recommended? You need to ensure the two machines that
|
|
will be running Linux FreeS/WAN can route to one another before trying to
|
|
make a secure connection.
|
|
2. Is there anything obviously wrong with the sense of your route command?
|
|
|
|
Normally, this problem is caused by an incorrect local nexthop parameter.
|
|
Check out the use of %defaultroute, described in man ipsec.conf. This is
|
|
a simple way to set nexthop for most people. To figure nexthop out by hand,
|
|
traceroute in-the-clear to your IPSec peer. Nexthop is the traceroute's
|
|
first hop after your IPSec gateway.</PRE>
|
|
<H3><A name="unreachable">SIOCADDRT:Network is unreachable</A></H3>
|
|
<P>This message is not from FreeS/WAN, but from the Linux IP stack
|
|
itself. That stack is seeing packets it has no route for, either
|
|
because your routing was broken before FreeS/WAN started or because
|
|
FreeS/WAN's changes broke it.</P>
|
|
<P>Here is a message from Claudia suggesting ways to diagnose and fix
|
|
such problems:</P>
|
|
<PRE>You write,
|
|
> I have correctly installed freeswan-1.8 on RH7.0 kernel 2.2.17, but when
|
|
> I setup a VPN connection with the other machine(RH5.2 Kernel 2.0.36
|
|
> freeswan-1.0, it works well.) it told me that
|
|
> "SIOCADDRT:Network is unreachable"! But the network connection is no
|
|
> problem.
|
|
|
|
Often this error is the result of a misconfiguration.
|
|
|
|
Be sure that you can route successfully in the absence of Linux
|
|
FreeS/WAN. (You say this is no problem, so proceed to the next step.)
|
|
|
|
Use a custom copy of the default updownscript. Do not change the route
|
|
commands, but add a diagnostic message revealing the exact text of the
|
|
route command. Is there a problem with the sense of the route command
|
|
that you can see? If so, then re-examine those ipsec.conf settings
|
|
that are being sent to the route command.
|
|
|
|
You may wish to use the ipsec auto --route and --unroute commands to
|
|
troubleshoot the problem. See man ipsec_auto for details.</PRE>
|
|
<P>Since the above message was written, we have modified the updown
|
|
script to provide a better diagnostic for this problem. Check<VAR>
|
|
/var/log/messages</VAR>.</P>
|
|
<P>See also the FAQ question<A href="#route-client"> route-client (or
|
|
host) exited with status 7</A>.</P>
|
|
<H3><A name="modprobe">ipsec_setup: modprobe: Can't locate module ipsec</A>
|
|
</H3>
|
|
<H3><A name="noKLIPS">ipsec_setup: Fatal error, kernel appears to lack
|
|
KLIPS</A></H3>
|
|
<P>These messages indicate an installation failure. The kernel you are
|
|
running does not contain the<A href="#KLIPS"> KLIPS (kernel IPsec)</A>
|
|
code.</P>
|
|
<P>Note that the "modprobe: Can't locate module ipsec" message appears
|
|
even if you are not using modules. If there is no KLIPS in your kernel,
|
|
FreeS/WAN tries to load it as a module. If that fails, you get this
|
|
message.</P>
|
|
<P>Commands you can quickly try are:</P>
|
|
<DL>
|
|
<DT><VAR>uname -a</VAR></DT>
|
|
<DD>to get details, including compilation date and time, of the
|
|
currently running kernel</DD>
|
|
<DT><VAR>ls /</VAR></DT>
|
|
<DT><VAR>ls /boot</VAR></DT>
|
|
<DD>to ensure a new kernel is where it should be. If kernel compilation
|
|
puts it in<VAR> /</VAR> but<VAR> lilo</VAR> wants it in<VAR> /boot</VAR>
|
|
, then you should uncomment the<VAR> INSTALL_PATH=/boot</VAR> line in
|
|
the kernel<VAR> Makefile</VAR>.</DD>
|
|
<DT><VAR>more /etc/lilo.conf</VAR></DT>
|
|
<DD>to see that<VAR> lilo</VAR> has correct information</DD>
|
|
<DT><VAR>lilo</VAR></DT>
|
|
<DD>to ensure that information in<VAR> /etc/lilo.conf</VAR> has been
|
|
transferred to the boot sector</DD>
|
|
</DL>
|
|
<P>If those don't find the problem, you have to go back and check
|
|
through the<A href="install.html"> install</A> procedure to see what
|
|
was missed.</P>
|
|
<P>Here is one of Claudia's messages on the topic:</P>
|
|
<PRE>> I tried to install freeswan 1.8 on my mandrake 7.2 test box. ...
|
|
|
|
> It does show version and some output for whack.
|
|
|
|
Yes, because the Pluto (daemon) part of ipsec is installed correctly, but
|
|
as we see below the kernel portion is not.
|
|
|
|
> However, I get the following from /var/log/messages:
|
|
>
|
|
> Mar 11 22:11:55 pavillion ipsec_setup: Starting FreeS/WAN IPsec 1.8...
|
|
> Mar 11 22:12:02 pavillion ipsec_setup: modprobe: Can't locate module ipsec
|
|
> Mar 11 22:12:02 pavillion ipsec_setup: Fatal error, kernel appears to lack
|
|
> KLIPS.
|
|
|
|
This is your problem. You have not successfully installed a kernel with
|
|
IPSec machinery in it.
|
|
|
|
Did you build Linux FreeS/WAN as a module? If so, you need to ensure that
|
|
your new module has been installed in the directory where your kernel
|
|
loader normally finds your modules. If not, you need to ensure
|
|
that the new IPSec-enabled kernel is being loaded correctly.
|
|
|
|
See also doc/install.html, and INSTALL in the distro.</PRE>
|
|
<H3><A name="noDNS">ipsec_setup: ... failure to fetch key for ... from
|
|
DNS</A></H3>
|
|
<P>Quoting Henry:</P>
|
|
<PRE>Note that by default, FreeS/WAN is now set up to
|
|
(a) authenticate with RSA keys, and
|
|
(b) fetch the public key of the far end from DNS.
|
|
Explicit attention to ipsec.conf will be needed if you want
|
|
to do something different.</PRE>
|
|
<P>and Claudia, responding to the same user:</P>
|
|
<PRE>You write,
|
|
|
|
> My current setup in ipsec.conf is leftrsasigkey=%dns I have
|
|
> commented this and authby=rsasig out. I am able to get ipsec running,
|
|
> but what I find is that the documentation only specifies for %dns are
|
|
> there any other values that can be placed in this variable other than
|
|
> %dns and the key? I am also assuming that this is where I would place
|
|
> my public key for the left and right side as well is this correct?
|
|
|
|
Valid values for authby= are rsasig and secret, which entail authentication
|
|
by RSA signature or by shared secret, respectively. Because you have
|
|
commented authby=rsasig out, you are using the default value of authby=secret.
|
|
|
|
When using RSA signatures, there are two ways to get the public key for the
|
|
IPSec peer: either copy it directly into *rsasigkey= in ipsec.conf, or
|
|
fetch it from dns. The magic value %dns for *rsasigkey parameters says to
|
|
try to fetch the peer's key from dns.
|
|
|
|
For any parameters, you may find their significance and special values in
|
|
man ipsec.conf. If you are setting up keys or secrets, be sure also to
|
|
reference man ipsec.secrets.</PRE>
|
|
<H3><A name="dup_address">ipsec_setup: ... interfaces ... and ... share
|
|
address ...</A></H3>
|
|
<P>This is a fatal error. FreeS/WAN cannot cope with two or more
|
|
interfaces using the same IP address. You must re-configure to avoid
|
|
this.</P>
|
|
<P>A mailing list message on the topic from Pluto developer Hugh
|
|
Redelmeier:</P>
|
|
<PRE>| I'm trying to get freeswan working between two machine where one has a ppp
|
|
| interface.
|
|
| I've already suceeded with two machines with ethernet ports but the ppp
|
|
| interface is causing me problems.
|
|
| basically when I run ipsec start i get
|
|
| ipsec_setup: Starting FreeS/WAN IPsec 1.7...
|
|
| ipsec_setup: 003 IP interfaces ppp1 and ppp0 share address 192.168.0.10!
|
|
| ipsec_setup: 003 IP interfaces ppp1 and ppp2 share address 192.168.0.10!
|
|
| ipsec_setup: 003 IP interfaces ppp0 and ppp2 share address 192.168.0.10!
|
|
| ipsec_setup: 003 no public interfaces found
|
|
|
|
|
| followed by lots of cannot work out interface for connection messages
|
|
|
|
|
| now I can specify the interface in ipsec.conf to be ppp0 , but this does
|
|
| not affect the above behaviour. A quick look in server.c indicates that the
|
|
| interfaces value is not used but some sort of raw detect happens.
|
|
|
|
|
| I guess I could prevent the formation of the extra ppp interfaces or
|
|
| allocate them different ip but I'd rather not. if at all possible. Any
|
|
| suggestions please.
|
|
|
|
Pluto won't touch an interface that shares an IP address with another.
|
|
This will eventually change, but it probably won't happen soon.
|
|
|
|
For now, you will have to give the ppp1 and ppp2 different addresses.</PRE>
|
|
<H3><A name="kflags">ipsec_setup: Cannot adjust kernel flags</A></H3>
|
|
<P>A mailing list message form technical lead Henry Spencer:</P>
|
|
<PRE>> When FreeS/WAN IPsec 1.7 is starting on my 2.0.38 Linux kernel the following
|
|
> error message is generated:
|
|
> ipsec_setup: Cannot adjust kernel flags, no /proc/sys/net/ipsec directory!
|
|
> What is supposed to create this directory and how can I fix this problem?
|
|
|
|
I think that directory is a 2.2ism, although I'm not certain (I don't have
|
|
a 2.0.xx system handy any more for testing). Without it, some of the
|
|
ipsec.conf config-setup flags won't work, but otherwise things should
|
|
function. </PRE>
|
|
<P>You also need to enable the<VAR> /proc</VAR> filesystem in your
|
|
kernel configuration for these operations to work.</P>
|
|
<H3><A name="message_num">Message numbers (MI3, QR1, et cetera) in Pluto
|
|
messages</A></H3>
|
|
<P>Pluto messages often indicate where Pluto is in the IKE protocols.
|
|
The letters indicate<STRONG> M</STRONG>ain mode or<STRONG> Q</STRONG>
|
|
uick mode and<STRONG> I</STRONG>nitiator or<STRONG> R</STRONG>esponder.
|
|
The numerals are message sequence numbers. For more detail, see our<A href="#sequence">
|
|
IPsec section</A>.</P>
|
|
<H3><A name="conn_name">Connection names in Pluto error messages</A></H3>
|
|
<P>From Pluto programmer Hugh Redelmeier:</P>
|
|
<PRE>| Jan 17 16:21:10 remus Pluto[13631]: "jumble" #1: responding to Main Mode from Road Warrior 130.205.82.46
|
|
| Jan 17 16:21:11 remus Pluto[13631]: "jumble" #1: no suitable connection for peer @banshee.wittsend.com
|
|
|
|
|
| The connection "jumble" has nothing to do with the incoming
|
|
| connection requests, which were meant for the connection "banshee".
|
|
|
|
You are right. The message tells you which Connection Pluto is
|
|
currently using, which need not be the right one. It need not be the
|
|
right one now for the negotiation to eventually succeed! This is
|
|
described in ipsec_pluto(8) in the section "Road Warrior Support".
|
|
|
|
There are two times when Pluto will consider switching Connections for
|
|
a state object. Both are in response to receiving ID payloads (one in
|
|
Phase 1 / Main Mode and one in Phase 2 / Quick Mode). The second is
|
|
not unique to Road Warriors. In fact, neither is the first any more
|
|
(two connections for the same pair of hosts could differ in Phase 1 ID
|
|
payload; probably nobody else has tried this).</PRE>
|
|
<H3><A name="cantorient">Pluto: ... can't orient connection</A></H3>
|
|
<P>Older versions of FreeS/WAN used this message. The same error now
|
|
gives the "we have no ipsecN ..." error described just below.</P>
|
|
<H3><A name="no.interface">... we have no ipsecN interface for either
|
|
end of this connection</A></H3>
|
|
<P>Your tunnel has no IP address which matches the IP address of any of
|
|
the available IPsec interfaces. Either you've misconfigured the
|
|
connection, or you need to define an appropriate IPsec interface
|
|
connection.<VAR> interfaces=%defaultroute</VAR> works in many cases.</P>
|
|
<P>A longer story: Pluto needs to know whether it is running on the
|
|
machine which the connection description calls<VAR> left</VAR> or on<VAR>
|
|
right</VAR>. It figures that out by:</P>
|
|
<UL>
|
|
<LI>looking at the interfaces given in<VAR> interfaces=</VAR> lines in
|
|
the<VAR> config setup</VAR> section</LI>
|
|
<LI>discovering the IP addresses for those interfaces</LI>
|
|
<LI>searching for a match between those addresses and the ones given in<VAR>
|
|
left=</VAR> or<VAR> right=</VAR> lines.</LI>
|
|
</UL>
|
|
<P>Normally a match is found. Then Pluto knows where it is and can set
|
|
up other things (for example, if it is<VAR> left</VAR>) using
|
|
parameters such as<VAR> leftsubnet</VAR> and<VAR> leftnexthop</VAR>,
|
|
and sending its outgoing packets to<VAR> right</VAR>.</P>
|
|
<P>If no match is found, it emits the above error message.</P>
|
|
<H3><A name="noconn">Pluto: ... no connection is known</A></H3>
|
|
<P>This error message occurs when a remote system attempts to negotiate
|
|
a connection and Pluto does not have a connection description that
|
|
matches what the remote system has requested. The most common cause is
|
|
a configuration error on one end or the other.</P>
|
|
<P>Parameters involved in this match are<VAR> left</VAR>,<VAR> right</VAR>
|
|
,<VAR> leftsubnet</VAR> and<VAR> rightsubnet</VAR>.</P>
|
|
<P><STRONG>The match must be exact</STRONG>. For example, if your left
|
|
subnet is a.b.c.0/24 then neither a single machine in that net nor a
|
|
smaller subnet such as a.b.c.64/26 will be considered a match.</P>
|
|
<P>The message can also occur when an appropriate description exists but
|
|
Pluto has not loaded it. Use an<VAR> auto=add</VAR> statement in the
|
|
connection description, or an<VAR> ipsec auto --add <conn_name></VAR>
|
|
command, to correct this.</P>
|
|
<P>An explanation from the Pluto developer:</P>
|
|
<PRE>| Jul 12 15:00:22 sohar58 Pluto[574]: "corp_road" #2: cannot respond to IPsec
|
|
| SA request because no connection is known for
|
|
| 216.112.83.112/32===216.112.83.112...216.67.25.118
|
|
|
|
This is the first message from the Pluto log showing a problem. It
|
|
means that PGPnet is trying to negotiate a set of SAs with this
|
|
topology:
|
|
|
|
216.112.83.112/32===216.112.83.112...216.67.25.118
|
|
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
|
|
client on our side our host PGPnet host, no client
|
|
|
|
None of the conns you showed look like this.
|
|
|
|
Use
|
|
ipsec auto --status
|
|
to see a snapshot of what connections are in pluto, what
|
|
negotiations are going on, and what SAs are established.
|
|
|
|
The leftsubnet= (client) in your conn is 216.112.83.64/26. It must
|
|
exactly match what pluto is looking for, and it does not.</PRE>
|
|
<H3><A name="nosuit">Pluto: ... no suitable connection ...</A></H3>
|
|
<P>This is similar to the<A href="#noconn"> no connection known</A>
|
|
error, but occurs at a different point in Pluto processing.</P>
|
|
<P>Here is one of Claudia's messages explaining the problem:</P>
|
|
<PRE>You write,
|
|
|
|
> What could be the reason of the following error?
|
|
> "no suitable connection for peer '@xforce'"
|
|
|
|
When a connection is initiated by the peer, Pluto must choose which entry in
|
|
the conf file best matches the incoming connection. A preliminary choice is
|
|
made on the basis of source and destination IPs, since that information is
|
|
available at that time.
|
|
|
|
A payload containing an ID arrives later in the negotiation. Based on this
|
|
id and the *id= parameters, Pluto refines its conn selection. ...
|
|
|
|
The message "no suitable connection" indicates that in this refining step,
|
|
Pluto does not find a connection that matches that ID.
|
|
|
|
Please see "Selecting a connection when responding" in man ipsec_pluto for
|
|
more details.</PRE>
|
|
<P>See also<A href="#conn_name"> Connection names in Pluto error
|
|
messages</A>.</P>
|
|
<H3><A name="noconn.auth">Pluto: ... no connection has been authorized</A>
|
|
</H3>
|
|
<P>Here is one of Claudia's messages discussing this problem:</P>
|
|
<PRE>You write,
|
|
|
|
> May 22 10:46:31 debian Pluto[25834]: packet from x.y.z.p:10014:
|
|
> initial Main Mode message from x.y.z.p:10014
|
|
but no connection has been authorized
|
|
|
|
This error occurs early in the connection negotiation process,
|
|
at the first step of IKE negotiation (Main Mode), which is itself the
|
|
first of two negotiation phases involved in creating an IPSec connection.
|
|
|
|
Here, Linux FreeS/WAN receives a packet from a potential peer, which
|
|
requests that they begin discussing a connection.
|
|
|
|
The "no connection has been authorized" means that there is no connection
|
|
description in Linux FreeS/WAN's internal database that can be used to
|
|
link your ipsec interface with that peer.
|
|
|
|
"But of course I configured that connection!"
|
|
|
|
It may be that the appropriate connection description exists in ipsec.conf
|
|
but has not been added to the database with ipsec auto --add myconn or the
|
|
auto=add method. Or, the connection description may be misconfigured.
|
|
|
|
The only parameters that are relevant in this decision are left= and right= .
|
|
Local and remote ports are also taken into account -- we see that the port
|
|
is printed in the message above -- but there is no way to control these
|
|
in ipsec.conf.
|
|
|
|
|
|
Failure at "no connection has been authorized" is similar to the
|
|
"no connection is known for..." error in the FAQ, and the "no suitable
|
|
connection" error described in the snapshot's FAQ. In all three cases,
|
|
Linux FreeS/WAN is trying to match parameters received in the
|
|
negotiation with the connection description in the local config file.
|
|
|
|
As it receives more information, its matches take more parameters into
|
|
account, and become more precise: first the pair of potential peers,
|
|
then the peer IDs, then the endpoints (including any subnets).
|
|
|
|
The "no suitable connection for peer *" occurs toward the end of IKE
|
|
(Main Mode) negotiation, when the IDs are matched.
|
|
|
|
"no connection is known for a/b===c...d" is seen at the beginning of IPSec
|
|
(Quick Mode, phase 2) negotiation, when the connections are matched using
|
|
left, right, and any information about the subnets.</PRE>
|
|
<H3><A name="noDESsupport">Pluto: ... OAKLEY_DES_CBC is not supported.</A>
|
|
</H3>
|
|
<P>This message occurs when the other system attempts to negotiate a
|
|
connection using<A href="#DES"> single DES</A>, which we do not support
|
|
because it is<A href="#desnotsecure"> insecure</A>.</P>
|
|
<P>Our interoperation document has suggestions for<A href="interop.html#noDES">
|
|
how to deal with</A> systems that attempt to use single DES.</P>
|
|
<H3><A name="notransform">Pluto: ... no acceptable transform</A></H3>
|
|
<P>This message means that the other gateway has made a proposal for
|
|
connection parameters, but nothing they proposed is acceptable to
|
|
Pluto. Possible causes include:</P>
|
|
<UL>
|
|
<LI>misconfiguration on either end</LI>
|
|
<LI>policy incompatibilities, for example we require encrypted
|
|
connections but they are trying to create one with just authentication</LI>
|
|
<LI>interoperation problems, for example they offer only single DES and
|
|
FreeS/WAN does not support that. See<A href="interop.html#interop.problem">
|
|
discussion</A> in our interoperation document.</LI>
|
|
</UL>
|
|
<P>A more detailed explanation, from Pluto programmer Hugh Redelmeier:</P>
|
|
<PRE>Background:
|
|
|
|
When one IKE system (for example, Pluto) is negotiating with another
|
|
to create an SA, the Initiator proposes a bunch of choices and the
|
|
Responder replies with one that it has selected.
|
|
|
|
The structure of the choices is fairly complicated. An SA payload
|
|
contains a list of lists of "Proposals". The outer list is a set of
|
|
choices: the selection must be from one element of this list.
|
|
|
|
Each of these elements is a list of Proposals. A selection must be
|
|
made from each of the elements of the inner list. In other words,
|
|
*all* of them apply (that is how, for example, both AH and ESP can
|
|
apply at once).
|
|
|
|
Within each of these Proposals is a list of Transforms. For each
|
|
Proposal selected, one Transform must be selected (in other words,
|
|
each Proposal provides a choice of Transforms).
|
|
|
|
Each Transform is made up of a list of Attributes describing, well,
|
|
attributes. Such as lifetime of the SA. Such as algorithm to be
|
|
used. All the Attributes apply to a Transform.
|
|
|
|
You will have noticed a pattern here: layers alternate between being
|
|
disjunctions ("or") and conjunctions ("and").
|
|
|
|
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
|
|
cut back. There must be exactly one Proposal. So this degenerates to
|
|
a list of Transforms, one of which must be chosen.
|
|
|
|
In your case, no proposal was considered acceptable to Pluto (the
|
|
Responder). So negotiation ceased. Pluto logs the reason it rejects
|
|
each Transform. So look back in the log to see what is going wrong.</PRE>
|
|
<H3><A name="rsasigkey">rsasigkey dumps core</A></H3>
|
|
A comment on this error from Henry:
|
|
<PRE>On Fri, 29 Jun 2001, Rodrigo Gruppelli wrote:
|
|
> ...Well, it seem that there's
|
|
> another problem with it. When I try to generate a pair of RSA keys,
|
|
> rsasigkey cores dump...
|
|
|
|
*That* is a neon sign flashing "GMP LIBRARY IS BROKEN". Rsasigkey calls
|
|
GMP a lot, and our own library a little bit, and that's very nearly all it
|
|
does. Barring bugs in its code or our library -- which have happened, but
|
|
not very often -- a problem in rsasigkey is a problem in GMP.</PRE>
|
|
<P>See the next question for how to deal with GMP errors.</P>
|
|
<H3><A name="sig4">!Pluto failure!: ... exited with ... signal 4</A></H3>
|
|
<P>Pluto has died. Signal 4 is SIGILL, illegal instruction.</P>
|
|
<P>The most likely cause is that your<A href="#GMP"> GMP</A> (GNU
|
|
multi-precision) library is compiled for a different processor than
|
|
what you are running on. Pluto uses that library for its public key
|
|
calculations.</P>
|
|
<P>Try getting the GMP sources and recompile for your processor type.
|
|
Most Linux distributions will include this source, or you can download
|
|
it from the<A href="http://www.swox.com/gmp/"> GMP home page</A>.</P>
|
|
<H3><A name="econnrefused">ECONNREFUSED error message</A></H3>
|
|
<P>From John Denker, on the mailing list:</P>
|
|
<PRE>1) The log message
|
|
some IKE message we sent has been rejected with
|
|
ECONNREFUSED (kernel supplied no details)
|
|
is much more suitable than the previous version. Thanks.
|
|
|
|
2) Minor suggestion for further improvement: it might be worth mentioning
|
|
that the command
|
|
tcpdump -i eth1 icmp[0] != 8 and icmp[0] != 0
|
|
is useful for tracking down the details in question. We shouldn't expect
|
|
all IPsec users to figure that out on their own. The log message might
|
|
even provide a hint as to where to look in the docs.</PRE>
|
|
<P>Reply From Pluto developer Hugh Redelmeier</P>
|
|
<PRE>Good idea.
|
|
|
|
I've added a bit pluto(8)'s BUGS section along these lines.
|
|
I didn't have the heart to lengthen this message.</PRE>
|
|
<H3><A name="no_eroute">klips_debug: ... no eroute!</A></H3>
|
|
<P>This message means<A href="#KLIPS"> KLIPS</A> has received a packet
|
|
for which no IPsec tunnel has been defined.</P>
|
|
<P>Here is a more detailed duscussion from the team's tech support
|
|
person Claudia Schmeing, responding to a query on the mailing list:</P>
|
|
<PRE>> Why ipsec reports no eroute! ???? IP Masq... is disabled.
|
|
|
|
In general, more information is required so that people on the list may
|
|
give you informed input. See doc/prob.report.</PRE>
|
|
<P>The document she refers to has since been replaced by a<A href="#prob.report">
|
|
section</A> of the troubleshooting document.</P>
|
|
<PRE>However, I can make some general comments on this type of error.
|
|
|
|
This error usually looks something like this (clipped from an archived
|
|
message):
|
|
|
|
> ttl:64 proto:1 chk:45459 saddr:192.168.1.2 daddr:192.168.100.1
|
|
> ... klips_debug:ipsec_findroute: 192.168.1.2->192.168.100.1
|
|
> ... klips_debug:rj_match: * See if we match exactly as a host destination
|
|
> ... klips_debug:rj_match: ** try to match a leaf, t=0xc1a260b0
|
|
> ... klips_debug:rj_match: *** start searching up the tree, t=0xc1a260b0
|
|
> ... klips_debug:rj_match: **** t=0xc1a260c8
|
|
> ... klips_debug:rj_match: **** t=0xc1fe5960
|
|
> ... klips_debug:rj_match: ***** not found.
|
|
> ... klips_debug:ipsec_tunnel_start_xmit: Original head/tailroom: 2, 28
|
|
> ... klips_debug:ipsec_tunnel_start_xmit: no eroute!: ts=47.3030, dropping.
|
|
|
|
|
|
What does this mean?
|
|
- --------------------
|
|
|
|
"eroute" stands for "extended route", and is a special type of route
|
|
internal to Linux FreeS/WAN. For more information about this type of route,
|
|
see the section of man ipsec_auto on ipsec auto --route.
|
|
|
|
"no eroute!" here means, roughly, that Linux FreeS/WAN cannot find an
|
|
appropriate tunnel that should have delivered this packet. Linux
|
|
FreeS/WAN therefore drops the packet, with the message "no eroute! ...
|
|
dropping", on the assumption that this packet is not a legitimate
|
|
transmission through a properly constructed tunnel.
|
|
|
|
|
|
How does this situation come about?
|
|
- -----------------------------------
|
|
|
|
Linux FreeS/WAN has a number of connection descriptions defined in
|
|
ipsec.conf. These must be successfully brought "up" to form actual tunnels.
|
|
(see doc/setup.html's step 15, man ipsec.conf and man ipsec_auto
|
|
for details).
|
|
|
|
Such connections are often specific to the endpoints' IPs. However, in
|
|
some cases they may be more general, for example in the case of
|
|
Road Warriors where left or right is the special value %any.
|
|
|
|
When Linux FreeS/WAN receives a packet, it verifies that the packet has
|
|
come through a legitimate channel, by checking that there is an
|
|
appropriate tunnel through which this packet might legitimately have
|
|
arrived. This is the process we see above.
|
|
|
|
First, it checks for an eroute that exactly matches the packet. In the
|
|
example above, we see it checking for a route that begins at 192.168.1.2
|
|
and ends at 192.168.100.1. This search favours the most specific match that
|
|
would apply to the route between these IPs. So, if there is a connection
|
|
description exactly matching these IPs, the search will end there. If not,
|
|
the code will search for a more general description matching the IPs.
|
|
If there is no match, either specific or general, the packet will be
|
|
dropped, as we see, above.
|
|
|
|
Unless you are working with Road Warriors, only the first, specific part
|
|
of the matching process is likely to be relevant to you.
|
|
|
|
|
|
"But I defined the tunnel, and it came up, why do I have this error?"
|
|
- ---------------------------------------------------------------------
|
|
|
|
One of the most common causes of this error is failure to specify enough
|
|
connection descriptions to cover all needed tunnels between any two
|
|
gateways and their respective subnets. As you have noticed, troubleshooting
|
|
this error may be complicated by the use of IP Masq. However, this error is
|
|
not limited to cases where IP Masq is used.
|
|
|
|
See doc/configuration.html#multitunnel for a detailed example of the
|
|
solution to this type of problem.</PRE>
|
|
<P>The documentation section she refers to is now<A href="#multitunnel">
|
|
here</A>.</P>
|
|
<H3><A name="SAused">... trouble writing to /dev/ipsec ... SA already in
|
|
use</A></H3>
|
|
<P>This error message occurs when two manual connections are set up with
|
|
the same SPI value.</P>
|
|
<P>See the FAQ for<A href="#spi_error"> One manual connection works, but
|
|
second one fails</A>.</P>
|
|
<H3><A name="ignore">... ignoring ... payload</A></H3>
|
|
<P>This message is harmless. The IKE protocol provides for a number of
|
|
optional messages types:</P>
|
|
<UL>
|
|
<LI>delete SA</LI>
|
|
<LI>initial contact</LI>
|
|
<LI>vendor ID</LI>
|
|
<LI>...</LI>
|
|
</UL>
|
|
<P>An implementation is never required to send these, but they are
|
|
allowed to. The receiver is not required to do anything with them.
|
|
FreeS/WAN ignores them, but notifies you via the logs.</P>
|
|
<P>For the "ignoring delete SA Payload" message, see also our discussion
|
|
of cleaning up<A href="#deadtunnel"> dead tunnels</A>.</P>
|
|
<H3><A name="unknown_rightcert">unknown parameter name "rightcert"</A></H3>
|
|
<P>This message can appear when you've upgraded an X.509-enabled Linux
|
|
FreeS/WAN with a vanilla Linux FreeS/WAN. To use your X.509 configs you
|
|
will need to overwrite the new install with<A HREF="http://www.freeswan.ca">
|
|
Super FreeS/WAN</A>, or add the<A HREF="http://www.strongsec.ca/freeswan">
|
|
X.509 patch</A> by hand.</P>
|
|
<H2><A name="spam">Why don't you restrict the mailing lists to reduce
|
|
spam?</A></H2>
|
|
<P>As a matter of policy, some of our<A href="mail.html"> mailing lists</A>
|
|
need to be open to non-subscribers. Project management feel strongly
|
|
that maintaining this openness is more important than blocking spam.</P>
|
|
<UL>
|
|
<LI>Users should be able to get help or report bugs without subscribing.</LI>
|
|
<LI>Even a user who is subscribed may not have access to his or her
|
|
subscribed account when he or she needs help, miles from home base in
|
|
the middle of setting up a client's gateway.</LI>
|
|
<LI>There is arguably a legal requirement for this policy. A US resident
|
|
or citizen could be charged under munitions export laws for providing
|
|
technical assistance to a foreign cryptographic project. Such a charge
|
|
would be more easily defended if the discussion takes place in public,
|
|
on an open list.</LI>
|
|
</UL>
|
|
<P>This has been discussed several times at some length on the list. See
|
|
the<A href="#archive"> list archives</A>. Bringing the topic up again
|
|
is unlikely to be useful. Please don't. Or at the very least, please
|
|
don't without reading the archives and being certain that whatever you
|
|
are about to suggest has not yet been discussed.</P>
|
|
<P>Project technical lead Henry Spencer summarised one discussion:</P>
|
|
<BLOCKQUOTE> For the third and last time: this list *will* *not* do
|
|
address-based filtering. This is a policy decision, not an
|
|
implementation problem. The decision is final, and is not open to
|
|
discussion. This needs to be communicated better to people, and steps
|
|
are being taken to do that.</BLOCKQUOTE>
|
|
<P>Adding this FAQ section is one of the steps he refers to.</P>
|
|
<P>You have various options other than just putting up with the spam,
|
|
filtering it yourself, or unsubscribing:</P>
|
|
<UL>
|
|
<LI>subscribe only to one or both of our lists with restricted posting
|
|
rules:
|
|
<UL>
|
|
<LI><A href="mailto:[email protected]?body=subscribe">briefs</A>
|
|
, weekly list summaries</LI>
|
|
<LI><A href="mailto:[email protected]?body=subscribe">announce</A>
|
|
, project-related announcements</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>read the other lists via the<A href="#archive"> archives</A></LI>
|
|
</UL>
|
|
<P>A number of tools are available to filter mail.</P>
|
|
<UL>
|
|
<LI>Many mail readers include some filtering capability.</LI>
|
|
<LI>Many Linux distributions include<A href="http://www.procmail.org/">
|
|
procmail(8)</A> for server-side filtering.</LI>
|
|
<LI>The<A href="http://www.spambouncer.org/"> Spam Bouncer</A> is a set
|
|
of procmail(8) filters designed to combat spam.</LI>
|
|
<LI>Roaring Penguin have a<A href="http://www.roaringpenguin.com/mimedefang/">
|
|
MIME defanger</A> that removes potentially dangerous attachments.</LI>
|
|
</UL>
|
|
<P>If you use your ISP's mail server rather than running your own,
|
|
consider suggesting to the ISP that they tag suspected spam as<A href="http://www.msen.com/1997/spam.html#SUSPECTED">
|
|
this ISP</A> does. They could just refuse mail from dubious sources,
|
|
but that is tricky and runs some risk of losing valuable mail or
|
|
senselessly annoying senders and their admins. However, they can safely
|
|
tag and deliver dubious mail. The tags can greatly assist your
|
|
filtering.</P>
|
|
<P>For information on tracking down spammers, see these<A href="http://www.rahul.net/falk/#howtos">
|
|
HowTos</A>, or the<A href="http://www.sputum.com/index2.html"> Sputum</A>
|
|
site. Sputum have a Linux anti-spam screensaver available for download.</P>
|
|
<P>Here is a more detailed message from Henry:</P>
|
|
<PRE>On Mon, 15 Jan 2001, Jay Vaughan wrote:
|
|
> I know I'm flogging a dead horse here, but I'm curious as to the reasons for
|
|
> an aversion for a subscriber-only mailing list?
|
|
|
|
Once again: for legal reasons, it is important that discussions of these
|
|
things be held in a public place -- the list -- and we do not want to
|
|
force people to subscribe to the list just to ask one question, because
|
|
that may be more than merely inconvenient for them. There are also real
|
|
difficulties with people who are temporarily forced to use alternate
|
|
addresses; that is precisely the time when they may be most in need of
|
|
help, yet a subscribers-only policy shuts them out.
|
|
|
|
These issues do not apply to most mailing lists, but for a list that is
|
|
(necessarily) the primary user support route for a crypto package, they
|
|
are very important. This is *not* an ordinary mailing list; it has to
|
|
function under awkward constraints that make various simplistic solutions
|
|
inapplicable or undesirable.
|
|
|
|
> We're *ALL* sick of hearing about list management problems, not just you
|
|
> old-timers, so why don't you DO SOMETHING EFFECTIVE ABOUT IT...
|
|
|
|
Because it's a lot harder than it looks, and many existing "solutions"
|
|
have problems when examined closely.
|
|
|
|
> A suggestion for you, based on 10 years of experience with management of my
|
|
> own mailing lists would be to use mailman, which includes pretty much every
|
|
> feature under the sun that you guys need and want, plus some. The URL for
|
|
> mailman...
|
|
|
|
I assure you, we're aware of mailman. Along with a whole bunch of others,
|
|
including some you almost certainly have never heard of (I hadn't!).
|
|
|
|
> As for the argument that the list shouldn't be configured to enforce
|
|
> subscription - I contend that it *SHOULD* AT LEAST require manual address
|
|
> verification in order for posts to be redirected.
|
|
|
|
You do realize, I hope, that interposing such a manual step might cause
|
|
your government to decide that this is not truly a public forum, and thus
|
|
you could go to jail if you don't get approval from them before mailing to
|
|
it? If you think this sounds irrational, your government is noted for
|
|
making irrational decisions in this area; we can't assume that they will
|
|
suddenly start being sensible. See above about awkward constraints. You
|
|
may be willing to take the risk, but we can't, in good conscience, insist
|
|
that all users with problems do so.
|
|
|
|
Henry Spencer
|
|
[email protected]</PRE>
|
|
<P>and a message on the topic from project leader John Gilmore:</P>
|
|
<PRE>Subject: Re: The linux-ipsec list's topic
|
|
Date: Sat, 30 Dec 2000
|
|
From: John Gilmore <[email protected]>
|
|
|
|
I'll post this single message, once only, in this discussion, and then
|
|
not burden the list with any further off-topic messages. I encourage
|
|
everyone on the list to restrain themself from posting ANY off-topic
|
|
messages to the linux-ipsec list.
|
|
|
|
The topic of the linux-ipsec mailing list is the FreeS/WAN software.
|
|
|
|
I frequently see "discussions about spam on a list" overwhelm the
|
|
volume of "actual spam" on a list. BOTH kinds of messages are
|
|
off-topic messages. Twenty anti-spam messages take just as long to
|
|
detect and discard as twenty spam messages.
|
|
|
|
The Linux-ipsec list encourages on-topic messages from people who have
|
|
not joined the list itself. We will not censor messages to the list
|
|
based on where they originate, or what return address they contain.
|
|
In other words, non-subscribers ARE allowed to post, and this will not
|
|
change. My own valid contributions have been rejected out-of-hand by
|
|
too many other mailing lists for me to want to impose that censorship
|
|
on anybody else's contributions. And every day I see the damage that
|
|
anti-spam zeal is causing in many other ways; that zeal is far more
|
|
damaging to the culture of the Internet than the nuisance of spam.
|
|
|
|
In general, it is the responsibility of recipients to filter,
|
|
prioritize, or otherwise manage the handling of email that comes to
|
|
them. It is not the responsibility of the rest of the Internet
|
|
community to refrain from sending messages to recipients that they
|
|
might not want to see. If your software infrastructure for managing
|
|
your incoming email is insufficient, then improve it. If you think
|
|
the signal-to-noise ratio on linux-ipsec is too poor, then please
|
|
unsubscribe. But don't further increase the noise by posting to the
|
|
linux-ipsec list about those topics.
|
|
|
|
John Gilmore
|
|
founder & sponsor, FreeS/WAN project</PRE>
|
|
<HR>
|
|
<H1><A name="manpages">FreeS/WAN manual pages</A></H1>
|
|
<P>The various components of Linux FreeS/WAN are of course documented in
|
|
standard Unix manual pages, accessible via the man(1) command.</P>
|
|
<P>Links here take you to an HTML version of the man pages.</P>
|
|
<H2><A name="man.file">Files</A></H2>
|
|
<DL>
|
|
<DT><A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></DT>
|
|
<DD>IPsec configuration and connections</DD>
|
|
<DT><A href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</A></DT>
|
|
<DD>secrets for IKE authentication, either pre-shared keys or RSA
|
|
private keys</DD>
|
|
</DL>
|
|
<P>These files are also discussed in the<A href="config.html">
|
|
configuration</A> section.</P>
|
|
<H2><A name="man.command">Commands</A></H2>
|
|
<P>Many users will never give most of the FreeS/WAN commands directly.
|
|
Configure the files listed above correctly and everything should be
|
|
automatic.</P>
|
|
<P>The exceptions are commands for mainpulating the<A href="#RSA"> RSA</A>
|
|
keys used in Pluto authentication:</P>
|
|
<DL>
|
|
<DT><A href="manpage.d/ipsec_rsasigkey.8.html">ipsec_rsasigkey(8)</A></DT>
|
|
<DD>generate keys</DD>
|
|
<DT><A href="manpage.d/ipsec_newhostkey.8.html">ipsec_newhostkey(8)</A></DT>
|
|
<DD>generate keys in a convenient format</DD>
|
|
<DT><A href="manpage.d/ipsec_showhostkey.8.html">ipsec_showhostkey(8)</A>
|
|
</DT>
|
|
<DD>extract<A href="#RSA"> RSA</A> keys from<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets(5)</A> (or optionally, another file) and format them for
|
|
insertion in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> or
|
|
in DNS records</DD>
|
|
</DL>
|
|
<P>Note that:</P>
|
|
<UL>
|
|
<LI>These keys are for<STRONG> authentication only</STRONG>. They are<STRONG>
|
|
not secure for encryption</STRONG>.</LI>
|
|
<LI>The utility uses random(4) as a source of<A href="#random"> random
|
|
numbers</A>. This may block for some time if there is not enough
|
|
activity on the machine to provide the required entropy. You may want
|
|
to give it some bogus activity such as random mouse movements or some
|
|
command such as<NOBR> <TT>du /usr > /dev/null &</TT>.</LI>
|
|
</UL>
|
|
<P>The following commands are fairly likely to be used, if only for
|
|
testing and status checks:</P>
|
|
<DL>
|
|
<DT><A href="manpage.d/ipsec.8.html">ipsec(8)</A></DT>
|
|
<DD>invoke IPsec utilities</DD>
|
|
<DT><A href="manpage.d/ipsec_setup.8.html">ipsec_setup(8)</A></DT>
|
|
<DD>control IPsec subsystem</DD>
|
|
<DT><A href="manpage.d/ipsec_auto.8.html">ipsec_auto(8)</A></DT>
|
|
<DD>control automatically-keyed IPsec connections</DD>
|
|
<DT><A href="manpage.d/ipsec_manual.8.html">ipsec_manual(8)</A></DT>
|
|
<DD>take manually-keyed IPsec connections up and down</DD>
|
|
<DT><A href="manpage.d/ipsec_ranbits.8.html">ipsec_ranbits(8)</A></DT>
|
|
<DD>generate random bits in ASCII form</DD>
|
|
<DT><A href="manpage.d/ipsec_look.8.html">ipsec_look(8)</A></DT>
|
|
<DD>show minimal debugging information</DD>
|
|
<DT><A href="manpage.d/ipsec_barf.8.html">ipsec_barf(8)</A></DT>
|
|
<DD>spew out collected IPsec debugging information</DD>
|
|
</DL>
|
|
<P>The lower-level utilities listed below are normally invoked via
|
|
scripts listed above, but they can also be used directly when required.</P>
|
|
<DL>
|
|
<DT><A href="manpage.d/ipsec_eroute.8.html">ipsec_eroute(8)</A></DT>
|
|
<DD>manipulate IPsec extended routing tables</DD>
|
|
<DT><A href="manpage.d/ipsec_klipsdebug.8.html">ipsec_klipsdebug(8)</A></DT>
|
|
<DD>set Klips (kernel IPsec support) debug features and level</DD>
|
|
<DT><A href="manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</A></DT>
|
|
<DD>IPsec IKE keying daemon</DD>
|
|
<DT><A href="manpage.d/ipsec_spi.8.html">ipsec_spi(8)</A></DT>
|
|
<DD>manage IPsec Security Associations</DD>
|
|
<DT><A href="manpage.d/ipsec_spigrp.8.html">ipsec_spigrp(8)</A></DT>
|
|
<DD>group/ungroup IPsec Security Associations</DD>
|
|
<DT><A href="manpage.d/ipsec_tncfg.8.html">ipsec_tncfg(8)</A></DT>
|
|
<DD>associate IPsec virtual interface with real interface</DD>
|
|
<DT><A href="manpage.d/ipsec_whack.8.html">ipsec_whack(8)</A></DT>
|
|
<DD>control interface for IPsec keying daemon</DD>
|
|
</DL>
|
|
<H2><A name="man.lib">Library routines</A></H2>
|
|
<DL>
|
|
<DT><A href="manpage.d/ipsec_atoaddr.3.html">ipsec_atoaddr(3)</A></DT>
|
|
<DT><A href="manpage.d/ipsec_addrtoa.3.html">ipsec_addrtoa(3)</A></DT>
|
|
<DD>convert Internet addresses to and from ASCII</DD>
|
|
<DT><A href="manpage.d/ipsec_atosubnet.3.html">ipsec_atosubnet(3)</A></DT>
|
|
<DT><A href="manpage.d/ipsec_subnettoa.3.html">ipsec_subnettoa(3)</A></DT>
|
|
<DD>convert subnet/mask ASCII form to and from addresses</DD>
|
|
<DT><A href="manpage.d/ipsec_atoasr.3.html">ipsec_atoasr(3)</A></DT>
|
|
<DD>convert ASCII to Internet address, subnet, or range</DD>
|
|
<DT><A href="manpage.d/ipsec_rangetoa.3.html">ipsec_rangetoa(3)</A></DT>
|
|
<DD>convert Internet address range to ASCII</DD>
|
|
<DT>ipsec_atodata(3)</DT>
|
|
<DT><A href="manpage.d/ipsec_datatoa.3.html">ipsec_datatoa(3)</A></DT>
|
|
<DD>convert binary data from and to ASCII formats</DD>
|
|
<DT><A href="manpage.d/ipsec_atosa.3.html">ipsec_atosa(3)</A></DT>
|
|
<DT><A href="manpage.d/ipsec_satoa.3.html">ipsec_satoa(3)</A></DT>
|
|
<DD>convert IPsec Security Association IDs to and from ASCII</DD>
|
|
<DT><A href="manpage.d/ipsec_atoul.3.html">ipsec_atoul(3)</A></DT>
|
|
<DT><A href="manpage.d/ipsec_ultoa.3.html">ipsec_ultoa(3)</A></DT>
|
|
<DD>convert unsigned-long numbers to and from ASCII</DD>
|
|
<DT><A href="manpage.d/ipsec_goodmask.3.html">ipsec_goodmask(3)</A></DT>
|
|
<DD>is this Internet subnet mask a valid one?</DD>
|
|
<DT><A href="manpage.d/ipsec_masktobits.3.html">ipsec_masktobits(3)</A></DT>
|
|
<DD>convert Internet subnet mask to bit count</DD>
|
|
<DT><A href="manpage.d/ipsec_bitstomask.3.html">ipsec_bitstomask(3)</A></DT>
|
|
<DD>convert bit count to Internet subnet mask</DD>
|
|
<DT><A href="manpage.d/ipsec_optionsfrom.3.html">ipsec_optionsfrom(3)</A>
|
|
</DT>
|
|
<DD>read additional ``command-line'' options from file</DD>
|
|
<DT><A href="manpage.d/ipsec_subnetof.3.html">ipsec_subnetof(3)</A></DT>
|
|
<DD>given Internet address and subnet mask, return subnet number</DD>
|
|
<DT><A href="manpage.d/ipsec_hostof.3.html">ipsec_hostof(3)</A></DT>
|
|
<DD>given Internet address and subnet mask, return host part</DD>
|
|
<DT><A href="manpage.d/ipsec_broadcastof.3.html">ipsec_broadcastof(3)</A>
|
|
</DT>
|
|
<DD>given Internet address and subnet mask, return broadcast address</DD>
|
|
</DL>
|
|
<HR>
|
|
<H1><A name="firewall">FreeS/WAN and firewalls</A></H1>
|
|
<P>FreeS/WAN, or other IPsec implementations, frequently run on gateway
|
|
machines, the same machines running firewall or packet filtering code.
|
|
This document discusses the relation between the two.</P>
|
|
<P>The firewall code in 2.4 and later kernels is called Netfilter. The
|
|
user-space utility to manage a firewall is iptables(8). See the<A href="http://netfilter.samba.org">
|
|
netfilter/iptables web site</A> for details.</P>
|
|
<H2><A name="filters">Filtering rules for IPsec packets</A></H2>
|
|
<P>The basic constraint is that<STRONG> an IPsec gateway must have
|
|
packet filters that allow IPsec packets</STRONG>, at least when talking
|
|
to other IPsec gateways:</P>
|
|
<UL>
|
|
<LI>UDP port 500 for<A href="#IKE"> IKE</A> negotiations</LI>
|
|
<LI>protocol 50 if you use<A href="#ESP"> ESP</A> encryption and/or
|
|
authentication (the typical case)</LI>
|
|
<LI>protocol 51 if you use<A href="#AH"> AH</A> packet-level
|
|
authentication</LI>
|
|
</UL>
|
|
<P>Your gateway and the other IPsec gateways it communicates with must
|
|
be able to exchange these packets for IPsec to work. Firewall rules
|
|
must allow UDP 500 and at least one of<A href="#AH"> AH</A> or<A href="#ESP">
|
|
ESP</A> on the interface that communicates with the other gateway.</P>
|
|
<P>For nearly all FreeS/WAN applications, you must allow UDP port 500
|
|
and the ESP protocol.</P>
|
|
<P>There are two ways to set this up:</P>
|
|
<DL>
|
|
<DT>easier but less flexible</DT>
|
|
<DD>Just set up your firewall scripts at boot time to allow IPsec
|
|
packets to and from your gateway. Let FreeS/WAN reject any bogus
|
|
packets.</DD>
|
|
<DT>more work, giving you more precise control</DT>
|
|
<DD>Have the<A href="manpage.d/ipsec_pluto.8.html"> ipsec_pluto(8)</A>
|
|
daemon call scripts to adjust firewall rules dynamically as required.
|
|
This is done by naming the scripts in the<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> variables<VAR> prepluto=</VAR>,<VAR> postpluto=</VAR>
|
|
,<VAR> leftupdown=</VAR> and<VAR> rightupdown=</VAR>.</DD>
|
|
</DL>
|
|
<P>Both methods are described in more detail below.</P>
|
|
<H2><A name="examplefw">Firewall configuration at boot</A></H2>
|
|
<P>It is possible to set up both firewalling and IPsec with appropriate
|
|
scripts at boot and then not use<VAR> leftupdown=</VAR> and<VAR>
|
|
rightupdown=</VAR>, or use them only for simple up and down operations.</P>
|
|
<P>Basically, the technique is</P>
|
|
<UL>
|
|
<LI>allow IPsec packets (typically, IKE on UDP port 500 plus ESP,
|
|
protocol 50)
|
|
<UL>
|
|
<LI>incoming, if the destination address is your gateway (and
|
|
optionally, only from known senders)</LI>
|
|
<LI>outgoing, with the from address of your gateway (and optionally,
|
|
only to known receivers)</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>let<A href="#Pluto"> Pluto</A> deal with IKE</LI>
|
|
<LI>let<A href="#KLIPS"> KLIPS</A> deal with ESP</LI>
|
|
</UL>
|
|
<P>Since Pluto authenticates its partners during the negotiation, and
|
|
KLIPS drops packets for which no tunnel has been negotiated, this may
|
|
be all you need.</P>
|
|
<H3><A name="simple.rules">A simple set of rules</A></H3>
|
|
<P>In simple cases, you need only a few rules, as in this example:</P>
|
|
<PRE># allow IPsec
|
|
#
|
|
# IKE negotiations
|
|
iptables -I INPUT -p udp --sport 500 --dport 500 -j ACCEPT
|
|
iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
|
|
# ESP encryption and authentication
|
|
iptables -I INPUT -p 50 -j ACCEPT
|
|
iptables -I OUTPUT -p 50 -j ACCEPT
|
|
</PRE>
|
|
<P>This should be all you need to allow IPsec through<VAR> lokkit</VAR>,
|
|
which ships with Red Hat 9, on its medium security setting. Once you've
|
|
tweaked to your satisfaction, save your active rule set with:</P>
|
|
<PRE>service iptables save</PRE>
|
|
<H3><A name="complex.rules">Other rules</A></H3>
|
|
You can add additional rules, or modify existing ones, to work with
|
|
IPsec and with your network and policies. We give a some examples in
|
|
this section.
|
|
<P>However, while it is certainly possible to create an elaborate set of
|
|
rules yourself (please let us know via the<A href="mail.html"> mailing
|
|
list</A> if you do), it may be both easier and more secure to use a set
|
|
which has already been published and tested.</P>
|
|
<P>The published rule sets we know of are described in the<A href="#rules.pub">
|
|
next section</A>.</P>
|
|
<H4><A NAME="7_2_2_1">Adding additional rules</A></H4>
|
|
If necessary, you can add additional rules to:
|
|
<DL>
|
|
<DT>reject IPsec packets that are not to or from known gateways</DT>
|
|
<DD>This possibility is discussed in more detail<A href="#unknowngate">
|
|
later</A></DD>
|
|
<DT>allow systems behind your gateway to build IPsec tunnels that pass
|
|
through the gateway</DT>
|
|
<DD>This possibility is discussed in more detail<A href="#through">
|
|
later</A></DD>
|
|
<DT>filter incoming packets emerging from KLIPS.</DT>
|
|
<DD>Firewall rules can recognise packets emerging from IPsec. They are
|
|
marked as arriving on an interface such as<VAR> ipsec0</VAR>, rather
|
|
than<VAR> eth0</VAR>,<VAR> ppp0</VAR> or whatever.</DD>
|
|
</DL>
|
|
<P>It is therefore reasonably straightforward to filter these packets in
|
|
whatever way suits your situation.</P>
|
|
<H4><A NAME="7_2_2_2">Modifying existing rules</A></H4>
|
|
<P>In some cases rules that work fine before you add IPsec may require
|
|
modification to work with IPsec.</P>
|
|
<P>This is especially likely for rules that deal with interfaces on the
|
|
Internet side of your system. IPsec adds a new interface; often the
|
|
rules must change to take account of that.</P>
|
|
<P>For example, consider the rules given in<A href="http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-5.html">
|
|
this section</A> of the Netfilter documentation:</P>
|
|
<PRE>Most people just have a single PPP connection to the Internet, and don't
|
|
want anyone coming back into their network, or the firewall:
|
|
|
|
## Insert connection-tracking modules (not needed if built into kernel).
|
|
# insmod ip_conntrack
|
|
# insmod ip_conntrack_ftp
|
|
|
|
## Create chain which blocks new connections, except if coming from inside.
|
|
# iptables -N block
|
|
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
|
|
# iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
|
|
# iptables -A block -j DROP
|
|
|
|
## Jump to that chain from INPUT and FORWARD chains.
|
|
# iptables -A INPUT -j block
|
|
# iptables -A FORWARD -j block</PRE>
|
|
<P>On an IPsec gateway, those rules may need to be modified. The above
|
|
allows new connections from<EM> anywhere except ppp0</EM>. That means
|
|
new connections from ipsec0 are allowed.</P>
|
|
<P>Do you want to allow anyone who can establish an IPsec connection to
|
|
your gateway to initiate TCP connections to any service on your
|
|
network? Almost certainly not if you are using opportunistic
|
|
encryption. Quite possibly not even if you have only explicitly
|
|
configured connections.</P>
|
|
<P>To disallow incoming connections from ipsec0, change the middle
|
|
section above to:</P>
|
|
<PRE> ## Create chain which blocks new connections, except if coming from inside.
|
|
# iptables -N block
|
|
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
|
|
# iptables -A block -m state --state NEW -i ppp+ -j DROP
|
|
# iptables -A block -m state --state NEW -i ipsec+ -j DROP
|
|
# iptables -A block -m state --state NEW -i -j ACCEPT
|
|
# iptables -A block -j DROP</PRE>
|
|
<P>The original rules accepted NEW connections from anywhere except
|
|
ppp0. This version drops NEW connections from any PPP interface (ppp+)
|
|
and from any ipsec interface (ipsec+), then accepts the survivors.</P>
|
|
<P>Of course, these are only examples. You will need to adapt them to
|
|
your own situation.</P>
|
|
<H3><A name="rules.pub">Published rule sets</A></H3>
|
|
<P>Several sets of firewall rules that work with FreeS/WAN are
|
|
available.</P>
|
|
<H4><A name="Ranch.trinity">Scripts based on Ranch's work</A></H4>
|
|
<P>One user, Rob Hutton, posted his boot time scripts to the mailing
|
|
list, and we included them in previous versions of this documentation.
|
|
They are still available from our<A href="http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/firewall.html#examplefw">
|
|
web site</A>. However, they were for an earlier FreeS/WAN version so we
|
|
no longer recommend them. Also, they had some bugs. See this<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00316.html">
|
|
message</A>.</P>
|
|
<P>Those scripts were based on David Ranch's scripts for his "Trinity
|
|
OS" for setting up a secure Linux. Check his<A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html">
|
|
home page</A> for the latest version and for information on his<A href="#ranch">
|
|
book</A> on securing Linux. If you are going to base your firewalling
|
|
on Ranch's scripts, we recommend using his latest version, and sending
|
|
him any IPsec modifications you make for incorporation into later
|
|
versions.</P>
|
|
<H4><A name="seawall">The Seattle firewall</A></H4>
|
|
<P>We have had several mailing lists reports of good results using
|
|
FreeS/WAN with Seawall (the Seattle Firewall). See that project's<A href="http://seawall.sourceforge.net/">
|
|
home page</A> on Sourceforge.</P>
|
|
<H4><A name="rcf">The RCF scripts</A></H4>
|
|
<P>Another set of firewall scripts with IPsec support are the RCF or
|
|
rc.firewall scripts. See their<A href="http://jsmoriss.mvlan.net/linux/rcf.html">
|
|
home page</A>.</P>
|
|
<H4><A name="asgard">Asgard scripts</A></H4>
|
|
<P><A href="http://heimdall.asgardsrealm.net/linux/firewall/">Asgard's
|
|
Realm</A> has set of firewall scripts with FreeS/WAN support, for 2.4
|
|
kernels and iptables.</P>
|
|
<H4><A name="user.scripts">User scripts from the mailing list</A></H4>
|
|
<P>One user gave considerable detail on his scripts, including
|
|
supporting<A href="#IPX"> IPX</A> through the tunnel. His message was
|
|
too long to conveniently be quoted here, so I've put it in a<A href="user_examples.html">
|
|
separate file</A>.</P>
|
|
<H2><A name="updown">Calling firewall scripts, named in ipsec.conf(5)</A>
|
|
</H2>
|
|
<P>The<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A>
|
|
configuration file has three pairs of parameters used to specify an
|
|
interface between FreeS/WAN and firewalling code.</P>
|
|
<P>Note that using these is not required if you have a static firewall
|
|
setup. In that case, you just set your firewall up at boot time (in a
|
|
way that permits the IPsec connections you want) and do not change it
|
|
thereafter. Omit all the FreeS/WAN firewall parameters and FreeS/WAN
|
|
will not attempt to adjust firewall rules at all. See<A href="#examplefw">
|
|
above</A> for some information on appropriate scripts.</P>
|
|
<P>However, if you want your firewall rules to change when IPsec
|
|
connections change, then you need to use these parameters.</P>
|
|
<H3><A name="pre_post">Scripts called at IPsec start and stop</A></H3>
|
|
<P>One pair of parmeters are set in the<VAR> config setup</VAR> section
|
|
of the<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> file and
|
|
affect all connections:</P>
|
|
<DL>
|
|
<DT>prepluto=</DT>
|
|
<DD>script to be called before<A href="manpage.d/ipsec_pluto.8.html">
|
|
pluto(8)</A> IKE daemon is started.</DD>
|
|
<DT>postpluto=</DT>
|
|
<DD>script to be called after<A href="manpage.d/ipsec_pluto.8.html">
|
|
pluto(8)</A> IKE daemon is stopped.</DD>
|
|
</DL>
|
|
These parameters allow you to change firewall parameters whenever IPsec
|
|
is started or stopped.
|
|
<P>They can also be used in other ways. For example, you might have<VAR>
|
|
prepluto</VAR> add a module to your kernel for the secure network
|
|
interface or make a dialup connection, and then have<VAR> postpluto</VAR>
|
|
remove the module or take the connection down.</P>
|
|
<H3><A name="up_down">Scripts called at connection up and down</A></H3>
|
|
<P>The other parameters are set in connection descriptions. They can be
|
|
set in individual connection descriptions, and could even call
|
|
different scripts for each connection for maximum flexibility. In most
|
|
applications, however, it makes sense to use only one script and to
|
|
call it from<VAR> conn %default</VAR> section so that it applies to all
|
|
connections.</P>
|
|
<P>You can:</P>
|
|
<DL>
|
|
<DT><STRONG>either</STRONG></DT>
|
|
<DD>set<VAR> leftfirewall=yes</VAR> or<VAR> rightfirewall=yes</VAR> to
|
|
use our supplied default script</DD>
|
|
<DT><STRONG>or</STRONG></DT>
|
|
<DD>assign a name in a<VAR> leftupdown=</VAR> or<VAR> rightupdown=</VAR>
|
|
line to use your own script</DD>
|
|
</DL>
|
|
<P>Note that<STRONG> only one of these should be used</STRONG>. You
|
|
cannot sensibly use both. Since<STRONG> our default script is obsolete</STRONG>
|
|
(designed for firewalls using<VAR> ipfwadm(8)</VAR> on 2.0 kernels),
|
|
most users who need this service will<STRONG> need to write a custom
|
|
script</STRONG>.</P>
|
|
<H4><A name="fw.default">The default script</A></H4>
|
|
<P>We supply a default script named<VAR> _updown</VAR>.</P>
|
|
<DL>
|
|
<DT>leftfirewall=</DT>
|
|
<DD></DD>
|
|
<DT>rightfirewall=</DT>
|
|
<DD>indicates that the gateway is doing firewalling and that<A href="manpage.d/ipsec_pluto.8.html">
|
|
pluto(8)</A> should poke holes in the firewall as required.</DD>
|
|
</DL>
|
|
<P>Set these to<VAR> yes</VAR> and Pluto will call our default script<VAR>
|
|
_updown</VAR> with appropriate arguments whenever it:</P>
|
|
<UL>
|
|
<LI>starts or stops IPsec services</LI>
|
|
<LI>brings a connection up or down</LI>
|
|
</UL>
|
|
<P>The supplied default<VAR> _updown</VAR> script is appropriate for
|
|
simple cases using the<VAR> ipfwadm(8)</VAR> firewalling package.</P>
|
|
<H4><A name="userscript">User-written scripts</A></H4>
|
|
<P>You can also write your own script and have Pluto call it. Just put
|
|
the script's name in one of these<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> lines:</P>
|
|
<DL>
|
|
<DT>leftupdown=</DT>
|
|
<DD></DD>
|
|
<DT>rightupdown=</DT>
|
|
<DD>specifies a script to call instead of our default script<VAR>
|
|
_updown</VAR>.</DD>
|
|
</DL>
|
|
<P>Your script should take the same arguments and use the same
|
|
environment variables as<VAR> _updown</VAR>. See the "updown command"
|
|
section of the<A href="manpage.d/ipsec_pluto.8.html"> ipsec_pluto(8)</A>
|
|
man page for details.</P>
|
|
<P>Note that<STRONG> you should not modify our _updown script in place</STRONG>
|
|
. If you did that, then upgraded FreeS/WAN, the upgrade would install a
|
|
new default script, overwriting your changes.</P>
|
|
<H3><A name="ipchains.script">Scripts for ipchains or iptables</A></H3>
|
|
<P>Our<VAR> _updown</VAR> is for firewalls using<VAR> ipfwadm(8)</VAR>,
|
|
the firewall code for the 2.0 series of Linux kernels. If you are using
|
|
the more recent packages<VAR> ipchains(8)</VAR> (for 2.2 kernels) or<VAR>
|
|
iptables(8)</VAR> (2.4 kernels), then you must do one of:</P>
|
|
<UL>
|
|
<LI>use static firewall rules which are set up at boot time as described<A
|
|
href="#examplefw"> above</A> and do not need to be changed by Pluto</LI>
|
|
<LI>limit yourself to ipchains(8)'s ipfwadm(8) emulation mode in order
|
|
to use our script</LI>
|
|
<LI>write your own script and call it with<VAR> leftupdown</VAR> and<VAR>
|
|
rightupdown</VAR>.</LI>
|
|
</UL>
|
|
<P>You can write a script to do whatever you need with firewalling.
|
|
Specify its name in a<VAR> [left|right]updown=</VAR> parameter in<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> and Pluto will automatically call it for you.</P>
|
|
<P>The arguments Pluto passes such a script are the same ones it passes
|
|
to our default _updown script, so the best way to build yours is to
|
|
copy ours and modify the copy.</P>
|
|
<P>Note, however, that<STRONG> you should not modify our _updown script
|
|
in place</STRONG>. If you did that, then upgraded FreeS/WAN, the
|
|
upgrade would install a new default script, overwriting your changes.</P>
|
|
<H2><A name="NAT">A complication: IPsec vs. NAT</A></H2>
|
|
<P><A href="#NAT.gloss">Network Address Translation</A>, also known as
|
|
IP masquerading, is a method of allocating IP addresses dynamically,
|
|
typically in circumstances where the total number of machines which
|
|
need to access the Internet exceeds the supply of IP addresses.</P>
|
|
<P>Any attempt to perform NAT operations on IPsec packets<EM> between
|
|
the IPsec gateways</EM> creates a basic conflict:</P>
|
|
<UL>
|
|
<LI>IPsec wants to authenticate packets and ensure they are unaltered on
|
|
a gateway-to-gateway basis</LI>
|
|
<LI>NAT rewrites packet headers as they go by</LI>
|
|
<LI>IPsec authentication fails if packets are rewritten anywhere between
|
|
the IPsec gateways</LI>
|
|
</UL>
|
|
<P>For<A href="#AH"> AH</A>, which authenticates parts of the packet
|
|
header including source and destination IP addresses, this is fatal. If
|
|
NAT changes those fields, AH authentication fails.</P>
|
|
<P>For<A href="#IKE"> IKE</A> and<A href="#ESP"> ESP</A> it is not
|
|
necessarily fatal, but is certainly an unwelcome complication.</P>
|
|
<H3><A name="nat_ok">NAT on or behind the IPsec gateway works</A></H3>
|
|
<P>This problem can be avoided by having the masquerading take place<EM>
|
|
on or behind</EM> the IPsec gateway.</P>
|
|
<P>This can be done physically with two machines, one physically behind
|
|
the other. A picture, using SG to indicate IPsec<STRONG> S</STRONG>
|
|
ecurity<STRONG> G</STRONG>ateways, is:</P>
|
|
<PRE> clients --- NAT ----- SG ---------- SG
|
|
two machines</PRE>
|
|
<P>In this configuration, the actual client addresses need not be given
|
|
in the<VAR> leftsubnet=</VAR> parameter of the FreeS/WAN connection
|
|
description. The security gateway just delivers packets to the NAT box;
|
|
it needs only that machine's address. What that machine does with them
|
|
does not affect FreeS/WAN.</P>
|
|
<P>A more common setup has one machine performing both functions:</P>
|
|
<PRE> clients ----- NAT/SG ---------------SG
|
|
one machine</PRE>
|
|
<P>Here you have a choice of techniques depending on whether you want to
|
|
make your client subnet visible to clients on the other end:</P>
|
|
<UL>
|
|
<LI>If you want the single gateway to behave like the two shown above,
|
|
with your clients hidden behind the NAT, then omit the<VAR> leftsubnet=</VAR>
|
|
parameter. It then defaults to the gateway address. Clients on the
|
|
other end then talk via the tunnel only to your gateway. The gateway
|
|
takes packets emerging from the tunnel, applies normal masquerading,
|
|
and forwards them to clients.</LI>
|
|
<LI>If you want to make your client machines visible, then give the
|
|
client subnet addresses as the<VAR> leftsubnet=</VAR> parameter in the
|
|
connection description and
|
|
<DL>
|
|
<DT>either</DT>
|
|
<DD>set<VAR> leftfirewall=yes</VAR> to use the default<VAR> updown</VAR>
|
|
script</DD>
|
|
<DT>or</DT>
|
|
<DD>use your own script by giving its name in a<VAR> leftupdown=</VAR>
|
|
parameter</DD>
|
|
</DL>
|
|
These scripts are described in their own<A href="#updown"> section</A>.
|
|
<P>In this case, no masquerading is done. Packets to or from the client
|
|
subnet are encrypted or decrypted without any change to their client
|
|
subnet addresses, although of course the encapsulating packets use
|
|
gateway addresses in their headers. Clients behind the right security
|
|
gateway see a route via that gateway to the left subnet.</P>
|
|
</LI>
|
|
</UL>
|
|
<H3><A name="nat_bad">NAT between gateways is problematic</A></H3>
|
|
<P>We recommend not trying to build IPsec connections which pass through
|
|
a NAT machine. This setup poses problems:</P>
|
|
<PRE> clients --- SG --- NAT ---------- SG</PRE>
|
|
<P>If you must try it, some references are:</P>
|
|
<UL>
|
|
<LI>Jean_Francois Nadeau's document on doing<A href="http://jixen.tripod.com/#NATed gateways">
|
|
IPsec behind NAT</A></LI>
|
|
<LI><A href="#VPN.masq">VPN masquerade patches</A> to make a Linux NAT
|
|
box handle IPsec packets correctly</LI>
|
|
</UL>
|
|
<H3><A name="NAT.ref">Other references on NAT and IPsec</A></H3>
|
|
<P>Other documents which may be relevant include:</P>
|
|
<UL>
|
|
<LI>an Internet Draft on<A href="http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-04.txt">
|
|
IPsec and NAT</A> which may eventually evolve into a standard solution
|
|
for this problem.</LI>
|
|
<LI>an informational<A href="http://www.cis.ohio-state.edu/rfc/rfc2709.txt">
|
|
RFC</A>,<CITE> Security Model with Tunnel-mode IPsec for NAT Domains</CITE>
|
|
.</LI>
|
|
<LI>an<A href="http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html">
|
|
article</A> in Cisco's<CITE> Internet Protocol Journal</CITE></LI>
|
|
</UL>
|
|
<H2><A name="complications">Other complications</A></H2>
|
|
<P>Of course simply allowing UDP 500 and ESP packets is not the whole
|
|
story. Various other issues arise in making IPsec and packet filters
|
|
co-exist and even co-operate. Some of them are summarised below.</P>
|
|
<H3><A name="through">IPsec<EM> through</EM></A> the gateway</H3>
|
|
<P>Basic IPsec packet filtering rules deal only with packets addressed
|
|
to or sent from your IPsec gateway.</P>
|
|
<P>It is a separate policy decision whether to permit such packets to
|
|
pass through the gateway so that client machines can build end-to-end
|
|
IPsec tunnels of their own. This may not be practical if you are using<A
|
|
href="#NAT"> NAT (IP masquerade)</A> on your gateway, and may conflict
|
|
with some corporate security policies.</P>
|
|
<P>Where possible, allowing this is almost certainly a good idea. Using
|
|
IPsec on an end-to-end basis is more secure than gateway-to-gateway.</P>
|
|
<P>Doing it is quite simple. You just need firewall rules that allow UDP
|
|
port 500 and protocols 50 and 51 to pass through your gateway. If you
|
|
wish, you can of course restrict this to certain hosts.</P>
|
|
<H3><A name="ipsec_only">Preventing non-IPsec traffic</A></H3>
|
|
You can also filter<EM> everything but</EM> UDP port 500 and ESP or AH
|
|
to restrict traffic to IPsec only, either for anyone communicating with
|
|
your host or just for specific partners.
|
|
<P>One application of this is for the telecommuter who might have:</P>
|
|
<PRE> Sunset==========West------------------East ================= firewall --- the Internet
|
|
home network untrusted net corporate network</PRE>
|
|
<P>The subnet on the right is 0.0.0.0/0, the whole Internet. The West
|
|
gateway is set up so that it allows only IPsec packets to East in or
|
|
out.</P>
|
|
<P>This configuration is used in AT&T Research's network. For details,
|
|
see the<A href="#applied"> papers</A> links in our introduction.</P>
|
|
<P>Another application would be to set up firewall rules so that an
|
|
internal machine, such as an employees-only web server, could not talk
|
|
to the outside world except via specific IPsec tunnels.</P>
|
|
<H3><A name="unknowngate">Filtering packets from unknown gateways</A></H3>
|
|
<P>It is possible to use firewall rules to restrict UDP 500, ESP and AH
|
|
packets so that these packets are accepted only from known gateways.
|
|
This is not strictly necessary since FreeS/WAN will discard packets
|
|
from unknown gateways. You might, however, want to do it for any of a
|
|
number of reasons. For example:</P>
|
|
<UL>
|
|
<LI>Arguably, "belt and suspenders" is the sensible approach to
|
|
security. If you can block a potential attack in two ways, use both.
|
|
The only question is whether to look for a third way after implementing
|
|
the first two.</LI>
|
|
<LI>Some admins may prefer to use the firewall code this way because
|
|
they prefer firewall logging to FreeS/WAN's logging.</LI>
|
|
<LI>You may need it to implement your security policy. Consider an
|
|
employee working at home, and a policy that says traffic from the home
|
|
system to the Internet at large must go first via IPsec to the
|
|
corporate LAN and then out to the Internet via the corporate firewall.
|
|
One way to do that is to make<VAR> ipsec0</VAR> the default route on
|
|
the home gateway and provide exceptions only for UDP 500 and ESP to the
|
|
corporate gateway. Everything else is then routed via the tunnel to the
|
|
corporate gateway.</LI>
|
|
</UL>
|
|
<P>It is not possible to use only static firewall rules for this
|
|
filtering if you do not know the other gateways' IP addresses in
|
|
advance, for example if you have "road warriors" who may connect from a
|
|
different address each time or if want to do<A href="#carpediem">
|
|
opportunistic encryption</A> to arbitrary gateways. In these cases, you
|
|
can accept UDP 500 IKE packets from anywhere, then use the<A href="#updown">
|
|
updown</A> script feature of<A href="manpage.d/ipsec_pluto.8.html">
|
|
pluto(8)</A> to dynamically adjust firewalling for each negotiated
|
|
tunnel.</P>
|
|
<P>Firewall packet filtering does not much reduce the risk of a<A href="#DOS">
|
|
denial of service attack</A> on FreeS/WAN. The firewall can drop
|
|
packets from unknown gateways, but KLIPS does that quite efficiently
|
|
anyway, so you gain little. The firewall cannot drop otherwise
|
|
legitmate packets that fail KLIPS authentication, so it cannot protect
|
|
against an attack designed to exhaust resources by making FreeS/WAN
|
|
perform many expensive authentication operations.</P>
|
|
<P>In summary, firewall filtering of IPsec packets from unknown gateways
|
|
is possible but not strictly necessary.</P>
|
|
<H2><A name="otherfilter">Other packet filters</A></H2>
|
|
<P>When the IPsec gateway is also acting as your firewall, other packet
|
|
filtering rules will be in play. In general, those are outside the
|
|
scope of this document. See our<A href="#firewall.linux"> Linux
|
|
firewall links</A> for information. There are a few types of packet,
|
|
however, which can affect the operation of FreeS/WAN or of diagnostic
|
|
tools commonly used with it. These are discussed below.</P>
|
|
<H3><A name="ICMP">ICMP filtering</A></H3>
|
|
<P><A href="#ICMP.gloss">ICMP</A> is the<STRONG> I</STRONG>nternet<STRONG>
|
|
C</STRONG>ontrol<STRONG> M</STRONG>essage<STRONG> P</STRONG>rotocol. It
|
|
is used for messages between IP implementations themselves, whereas IP
|
|
used is used between the clients of those implementations. ICMP is,
|
|
unsurprisingly, used for control messages. For example, it is used to
|
|
notify a sender that a desination is not reachable, or to tell a router
|
|
to reroute certain packets elsewhere.</P>
|
|
<P>ICMP handling is tricky for firewalls.</P>
|
|
<UL>
|
|
<LI>You definitely want some ICMP messages to get through; things won't
|
|
work without them. For example, your clients need to know if some
|
|
destination they ask for is unreachable.</LI>
|
|
<LI>On the other hand, you do equally definitely do not want untrusted
|
|
folk sending arbitrary control messages to your machines. Imagine what
|
|
someone moderately clever and moderately malicious could do to you,
|
|
given control of your network's routing.</LI>
|
|
</UL>
|
|
<P>ICMP does not use ports. Messages are distinguished by a "message
|
|
type" field and, for some types, by an additional "code" field. The
|
|
definitive list of types and codes is on the<A href="http://www.iana.org">
|
|
IANA</A> site.</P>
|
|
<P>One expert uses this definition for ICMP message types to be dropped
|
|
at the firewall.</P>
|
|
<PRE># ICMP types which lack socially redeeming value.
|
|
# 5 Redirect
|
|
# 9 Router Advertisement
|
|
# 10 Router Selection
|
|
# 15 Information Request
|
|
# 16 Information Reply
|
|
# 17 Address Mask Request
|
|
# 18 Address Mask Reply
|
|
|
|
badicmp='5 9 10 15 16 17 18'</PRE>
|
|
<P>A more conservative approach would be to make a list of allowed types
|
|
and drop everything else.</P>
|
|
<P>Whichever way you do it, your ICMP filtering rules on a FreeS/WAN
|
|
gateway should allow at least the following ICMP packet types:</P>
|
|
<DL>
|
|
<DT>echo (type 8)</DT>
|
|
<DD></DD>
|
|
<DT>echo reply (type 0)</DT>
|
|
<DD>These are used by ping(1). We recommend allowing both types through
|
|
the tunnel and to or from your gateway's external interface, since
|
|
ping(1) is an essential testing tool.
|
|
<P>It is fairly common for firewalls to drop ICMP echo packets addressed
|
|
to machines behind the firewall. If that is your policy, please create
|
|
an exception for such packets arriving via an IPsec tunnel, at least
|
|
during intial testing of those tunnels.</P>
|
|
</DD>
|
|
<DT>destination unreachable (type 3)</DT>
|
|
<DD>This is used, with code 4 (Fragmentation Needed and Don't Fragment
|
|
was Set) in the code field, to control<A href="#pathMTU"> path MTU
|
|
discovery</A>. Since IPsec processing adds headers, enlarges packets
|
|
and may cause fragmentation, an IPsec gateway should be able to send
|
|
and receive these ICMP messages<STRONG> on both inside and outside
|
|
interfaces</STRONG>.</DD>
|
|
</DL>
|
|
<H3><A name="traceroute">UDP packets for traceroute</A></H3>
|
|
<P>The traceroute(1) utility uses UDP port numbers from 33434 to
|
|
approximately 33633. Generally, these should be allowed through for
|
|
troubleshooting.</P>
|
|
<P>Some firewalls drop these packets to prevent outsiders exploring the
|
|
protected network with traceroute(1). If that is your policy, consider
|
|
creating an exception for such packets arriving via an IPsec tunnel, at
|
|
least during intial testing of those tunnels.</P>
|
|
<H3><A name="l2tp">UDP for L2TP</A></H3>
|
|
<P> Windows 2000 does, and products designed for compatibility with it
|
|
may, build<A href="#l2tp"> L2TP</A> tunnels over IPsec connections.</P>
|
|
<P>For this to work, you must allow UDP protocol 1701 packets coming out
|
|
of your tunnels to continue to their destination. You can, and probably
|
|
should, block such packets to or from your external interfaces, but
|
|
allow them from<VAR> ipsec0</VAR>.</P>
|
|
<P>See also our Windows 2000<A href="interop.html#win2k"> interoperation
|
|
discussion</A>.</P>
|
|
<H2><A name="packets">How it all works: IPsec packet details</A></H2>
|
|
<P>IPsec uses three main types of packet:</P>
|
|
<DL>
|
|
<DT><A href="#IKE">IKE</A> uses<STRONG> the UDP protocol and port 500</STRONG>
|
|
.</DT>
|
|
<DD>Unless you are using only (less secure, not recommended) manual
|
|
keying, you need IKE to negotiate connection parameters, acceptable
|
|
algorithms, key sizes and key setup. IKE handles everything required to
|
|
set up, rekey, repair or tear down IPsec connections.</DD>
|
|
<DT><A href="#ESP">ESP</A> is<STRONG> protocol number 50</STRONG></DT>
|
|
<DD>This is required for encrypted connections.</DD>
|
|
<DT><A href="#AH">AH</A> is<STRONG> protocol number 51</STRONG></DT>
|
|
<DD>This can be used where only authentication, not encryption, is
|
|
required.</DD>
|
|
</DL>
|
|
<P>All of those packets should have appropriate IPsec gateway addresses
|
|
in both the to and from IP header fields. Firewall rules can check this
|
|
if you wish, though it is not strictly necessary. This is discussed in
|
|
more detail<A href="#unknowngate"> later</A>.</P>
|
|
<P>IPsec processing of incoming packets authenticates them then removes
|
|
the ESP or AH header and decrypts if necessary. Successful processing
|
|
exposes an inner packet which is then delivered back to the firewall
|
|
machinery, marked as having arrived on an<VAR> ipsec[0-3]</VAR>
|
|
interface. Firewall rules can use that interface label to distinguish
|
|
these packets from unencrypted packets which are labelled with the
|
|
physical interface they arrived on (or perhaps with a non-IPsec virtual
|
|
interface such as<VAR> ppp0</VAR>).</P>
|
|
<P>One of our users sent a mailing list message with a<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00006.html">
|
|
diagram</A> of the packet flow.</P>
|
|
<H3><A name="noport">ESP and AH do not have ports</A></H3>
|
|
<P>Some protocols, such as TCP and UDP, have the notion of ports. Others
|
|
protocols, including ESP and AH, do not. Quite a few IPsec newcomers
|
|
have become confused on this point. There are no ports<EM> in</EM> the
|
|
ESP or AH protocols, and no ports used<EM> for</EM> them. For these
|
|
protocols,<EM> the idea of ports is completely irrelevant</EM>.</P>
|
|
<H3><A name="header">Header layout</A></H3>
|
|
<P>The protocol numbers for ESP or AH are used in the 'next header'
|
|
field of the IP header. On most non-IPsec packets, that field would
|
|
have one of:</P>
|
|
<UL>
|
|
<LI>1 for ICMP</LI>
|
|
<LI>4 for IP-in-IP encapsulation</LI>
|
|
<LI>6 for TCP</LI>
|
|
<LI>17 for UDP</LI>
|
|
<LI>... or one of about 100 other possibilities listed by<A href="http://www.iana.org">
|
|
IANA</A></LI>
|
|
</UL>
|
|
<P>Each header in the sequence tells what the next header will be. IPsec
|
|
adds headers for ESP or AH near the beginning of the sequence. The
|
|
original headers are kept and the 'next header' fields adjusted so that
|
|
all headers can be correctly interpreted.</P>
|
|
<P>For example, using<STRONG> [</STRONG><STRONG> ]</STRONG> to indicate
|
|
data protected by ESP and unintelligible to an eavesdropper between the
|
|
gateways:</P>
|
|
<UL>
|
|
<LI>a simple packet might have only IP and TCP headers with:
|
|
<UL>
|
|
<LI>IP header says next header --> TCP</LI>
|
|
<LI>TCP header port number --> which process to send data to</LI>
|
|
<LI>data</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>with ESP<A href="#transport"> transport mode</A> encapsulation, that
|
|
packet would have:
|
|
<UL>
|
|
<LI>IP header says next header --> ESP</LI>
|
|
<LI>ESP header<STRONG> [</STRONG> says next --> TCP</LI>
|
|
<LI>TCP header port number --> which process to send data to</LI>
|
|
<LI>data<STRONG> ]</STRONG></LI>
|
|
</UL>
|
|
Note that the IP header is outside ESP protection, visible to an
|
|
attacker, and that the final destination must be the gateway.</LI>
|
|
<LI>with ESP in<A href="#tunnel"> tunnel mode</A>, we might have:
|
|
<UL>
|
|
<LI>IP header says next header --> ESP</LI>
|
|
<LI>ESP header<STRONG> [</STRONG> says next --> IP</LI>
|
|
<LI>IP header says next header --> TCP</LI>
|
|
<LI>TCP header port number --> which process to send data to</LI>
|
|
<LI>data<STRONG> ]</STRONG></LI>
|
|
</UL>
|
|
Here the inner IP header is protected by ESP, unreadable by an
|
|
attacker. Also, the inner header can have a different IP address than
|
|
the outer IP header, so the decrypted packet can be routed from the
|
|
IPsec gateway to a final destination which may be another machine.</LI>
|
|
</UL>
|
|
<P>Part of the ESP header itself is encrypted, which is why the<STRONG>
|
|
[</STRONG> indicating protected data appears in the middle of some
|
|
lines above. The next header field of the ESP header is protected. This
|
|
makes<A href="#traffic"> traffic analysis</A> more difficult. The next
|
|
header field would tell an eavesdropper whether your packet was UDP to
|
|
the gateway, TCP to the gateway, or encapsulated IP. It is better not
|
|
to give this information away. A clever attacker may deduce some of it
|
|
from the pattern of packet sizes and timings, but we need not make it
|
|
easy.</P>
|
|
<P>IPsec allows various combinations of these to match local policies,
|
|
including combinations that use both AH and ESP headers or that nest
|
|
multiple copies of these headers.</P>
|
|
<P>For example, suppose my employer has an IPsec VPN running between two
|
|
offices so all packets travelling between the gateways for those
|
|
offices are encrypted. If gateway policies allow it (The admins could
|
|
block UDP 500 and protocols 50 and 51 to disallow it), I can build an
|
|
IPsec tunnel from my desktop to a machine in some remote office. Those
|
|
packets will have one ESP header throughout their life, for my
|
|
end-to-end tunnel. For part of the route, however, they will also have
|
|
another ESP layer for the corporate VPN's encapsulation. The whole
|
|
header scheme for a packet on the Internet might be:</P>
|
|
<UL>
|
|
<LI>IP header (with gateway address) says next header --> ESP</LI>
|
|
<LI>ESP header<STRONG> [</STRONG> says next --> IP</LI>
|
|
<LI>IP header (with receiving machine address) says next header --> ESP</LI>
|
|
<LI>ESP header<STRONG> [</STRONG> says next --> TCP</LI>
|
|
<LI>TCP header port number --> which process to send data to</LI>
|
|
<LI>data<STRONG> ]]</STRONG></LI>
|
|
</UL>
|
|
<P>The first ESP (outermost) header is for the corporate VPN. The inner
|
|
ESP header is for the secure machine-to-machine link.</P>
|
|
<H3><A name="dhr">DHR on the updown script</A></H3>
|
|
<P>Here are some mailing list comments from<A href="manpage.d/ipsec_pluto.8.html">
|
|
pluto(8)</A> developer Hugh Redelmeier on an earlier draft of this
|
|
document:</P>
|
|
<PRE>There are many important things left out
|
|
|
|
- firewalling is important but must reflect (implement) policy. Since
|
|
policy isn't the same for all our customers, and we're not experts,
|
|
we should concentrate on FW and MASQ interactions with FreeS/WAN.
|
|
|
|
- we need a diagram to show packet flow WITHIN ONE MACHINE, assuming
|
|
IKE, IPsec, FW, and MASQ are all done on that machine. The flow is
|
|
obvious if the components are run on different machines (trace the
|
|
cables).
|
|
|
|
IKE input:
|
|
+ packet appears on public IF, as UDP port 500
|
|
+ input firewalling rules are applied (may discard)
|
|
+ Pluto sees the packet.
|
|
|
|
IKE output:
|
|
+ Pluto generates the packet & writes to public IF, UDP port 500
|
|
+ output firewalling rules are applied (may discard)
|
|
+ packet sent out public IF
|
|
|
|
IPsec input, with encapsulated packet, outer destination of this host:
|
|
+ packet appears on public IF, protocol 50 or 51. If this
|
|
packet is the result of decapsulation, it will appear
|
|
instead on the paired ipsec IF.
|
|
+ input firewalling rules are applied (but packet is opaque)
|
|
+ KLIPS decapsulates it, writes result to paired ipsec IF
|
|
+ input firewalling rules are applied to resulting packet
|
|
as input on ipsec IF
|
|
+ if the destination of the packet is this machine, the
|
|
packet is passed on to the appropriate protocol handler.
|
|
If the original packet was encapsulated more than once
|
|
and the new outer destination is this machine, that
|
|
handler will be KLIPS.
|
|
+ otherwise:
|
|
* routing is done for the resulting packet. This may well
|
|
direct it into KLIPS for encoding or encrypting. What
|
|
happens then is described elsewhere.
|
|
* forwarding firewalling rules are applied
|
|
* output firewalling rules are applied
|
|
* the packet is sent where routing specified
|
|
|
|
IPsec input, with encapsulated packet, outer destination of another host:
|
|
+ packet appears on some IF, protocol 50 or 51
|
|
+ input firewalling rules are applied (but packet is opaque)
|
|
+ routing selects where to send the packet
|
|
+ forwarding firewalling rules are applied (but packet is opaque)
|
|
+ packet forwarded, still encapsulated
|
|
|
|
IPsec output, from this host or from a client:
|
|
+ if from a client, input firewalling rules are applied as the
|
|
packet arrives on the private IF
|
|
+ routing directs the packet to an ipsec IF (this is how the
|
|
system decides KLIPS processing is required)
|
|
+ if from a client, forwarding firewalling rules are applied
|
|
+ KLIPS eroute mechanism matches the source and destination
|
|
to registered eroutes, yielding a SPI group. This dictates
|
|
processing, and where the resulting packet is to be sent
|
|
(the destinations SG and the nexthop).
|
|
+ output firewalling is not applied to the resulting
|
|
encapsulated packet
|
|
|
|
- Until quite recently, KLIPS would double encapsulate packets that
|
|
didn't strictly need to be. Firewalling should be prepared for
|
|
those packets showing up as ESP and AH protocol input packets on
|
|
an ipsec IF.
|
|
|
|
- MASQ processing seems to be done as if it were part of the
|
|
forwarding firewall processing (this should be verified).
|
|
|
|
- If a firewall is being used, it is likely the case that it needs to
|
|
be adjusted whenever IPsec SAs are added or removed. Pluto invokes
|
|
a script to do this (and to adjust routing) at suitable times. The
|
|
default script is only suitable for ipfwadm-managed firewalls. Under
|
|
LINUX 2.2.x kernels, ipchains can be managed by ipfwadm (emulation),
|
|
but ipchains more powerful if manipulated using the ipchains command.
|
|
In this case, a custom updown script must be used.
|
|
|
|
We think that the flexibility of ipchains precludes us supplying an
|
|
updown script that would be widely appropriate.</PRE>
|
|
<HR>
|
|
<H1><A NAME="trouble"></A>Linux FreeS/WAN Troubleshooting Guide</H1>
|
|
<H2><A NAME="overview"></A>Overview</H2>
|
|
<P> This document covers several general places where you might have a
|
|
problem:</P>
|
|
<OL>
|
|
<LI><A HREF="#install">During install</A>.</LI>
|
|
<LI><A HREF="#negotiation">During the negotiation process</A>.</LI>
|
|
<LI><A HREF="#use">Using an established connection</A>.</LI>
|
|
</OL>
|
|
<P>This document also contains<A HREF="#notes"> notes</A> which expand
|
|
on points made in these sections, and tips for<A HREF="#prob.report">
|
|
problem reporting</A>. If the other end of your connection is not
|
|
FreeS/WAN, you'll also want to read our<A HREF="interop.html#interop.problem">
|
|
interoperation</A> document.</P>
|
|
<H2><A NAME="install"></A>1. During Install</H2>
|
|
<H3><A NAME="8_2_1">1.1 RPM install gotchas</A></H3>
|
|
<P>With the RPM method:</P>
|
|
<UL>
|
|
<LI>Be sure you have installed both the userland tools and the kernel
|
|
components. One will not work without the other. For example, when
|
|
using FreeS/WAN-produced RPMs for our 2.04 release, you need both:
|
|
<PRE> freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm
|
|
freeswan-module-2.04_2.4.20_20.9-0.i386.rpm
|
|
</PRE>
|
|
</LI>
|
|
</UL>
|
|
<H3><A NAME="8_2_2">1.2 Problems installing from source</A></H3>
|
|
<P>When installing from source, you may find these problems:</P>
|
|
<UL>
|
|
<LI>Missing library. See<A HREF="#gmp.h_missing"> this</A> FAQ.</LI>
|
|
<LI>Missing utilities required for compile. See this<A HREF="install.html#tool.lib">
|
|
checklist</A>.</LI>
|
|
<LI>Kernel version incompatibility. See<A HREF="#k.versions"> this</A>
|
|
FAQ.</LI>
|
|
<LI>Another compile problem. Find information in the out.* files, ie.
|
|
out.kpatch, out.kbuild, created at compile time in the top-level Linux
|
|
FreeS/WAN directory. Error messages generated by KLIPS during the boot
|
|
sequence are accessible with the<VAR> dmesg</VAR> command.
|
|
<BR> Check the list archives and the List in Brief to see if this is a
|
|
known issue. If it is not, report it to the bugs list as described in
|
|
our<A HREF="#prob.report"> problem reporting</A> section. In some
|
|
cases, you may be asked to provide debugging information using gdb;
|
|
details<A HREF="#gdb"> below</A>.</LI>
|
|
<LI>If your kernel compiles but you fail to install your new
|
|
FreeS/WAN-enabled kernel, review the sections on<A HREF="install.html#newk">
|
|
installing the patched kernel</A>, and<A HREF="#testinstall"> testing</A>
|
|
to see if install succeeded.</LI>
|
|
</UL>
|
|
<H3><A NAME="install.check"></A>1.3 Install checks</H3>
|
|
<P><VAR>ipsec verify</VAR> checks a number of FreeS/WAN essentials. Here
|
|
are some hints on what do to when your system doesn't check out:</P>
|
|
<P></P>
|
|
<TABLE border="1">
|
|
<TR><TD><STRONG>Problem</STRONG></TD><TD><STRONG>Status</STRONG></TD><TD>
|
|
<STRONG>Action</STRONG></TD></TR>
|
|
<TR><TD><VAR>ipsec</VAR> not on-path</TD><TD> </TD><TD>
|
|
<P>Add<VAR> /usr/local/sbin</VAR> to your PATH.</P>
|
|
</TD></TR>
|
|
<TR><TD>Missing KLIPS support</TD><TD><FONT COLOR="#FF0000">critical</FONT>
|
|
</TD><TD>See<A HREF="#noKLIPS"> this FAQ.</A></TD></TR>
|
|
<TR><TD>No RSA private key</TD><TD> </TD><TD>
|
|
<P>Follow<A HREF="install.html#genrsakey"> these instructions</A> to
|
|
create an RSA key pair for your host. RSA keys are:</P>
|
|
<UL>
|
|
<LI>required for opportunistic encryption, and</LI>
|
|
<LI>our preferred method to authenticate pre-configured connections.</LI>
|
|
</UL>
|
|
</TD></TR>
|
|
<TR><TD><VAR>pluto</VAR> not running</TD><TD><FONT COLOR="#FF0000">
|
|
critical</FONT></TD><TD>
|
|
<PRE>service ipsec start</PRE>
|
|
</TD></TR>
|
|
<TR><TD>No port 500 hole</TD><TD><FONT COLOR="#FF0000">critical</FONT></TD><TD>
|
|
Open port 500 for IKE negotiation.</TD></TR>
|
|
<TR><TD>Port 500 check N/A</TD><TD> </TD><TD>Check that port 500 is open
|
|
for IKE negotiation.</TD></TR>
|
|
<TR><TD>Failed DNS checks</TD><TD> </TD><TD>Opportunistic encryption
|
|
requires information from DNS. To set this up, see<A HREF="#opp.setup">
|
|
our instructions</A>.</TD></TR>
|
|
<TR><TD>No public IP address</TD><TD> </TD><TD>Check that the interface
|
|
which you want to protect with IPSec is up and running.</TD></TR>
|
|
</TABLE>
|
|
<H3><A NAME="oe.trouble"></A>1.3 Troubleshooting OE</H3>
|
|
<P>OE should work with no local configuration, if you have posted DNS
|
|
TXT records according to the instructions in our<A HREF="quickstart.html">
|
|
quickstart guide</A>. If you encounter trouble, try these hints. We
|
|
welcome additional hints via the<A HREF="mail.html"> users' mailing
|
|
list</A>.</P>
|
|
<TABLE border="1">
|
|
<TR><TD><STRONG>Symptom</STRONG></TD><TD><STRONG>Problem</STRONG></TD><TD>
|
|
<STRONG>Action</STRONG></TD></TR>
|
|
<TR><TD> You're running FreeS/WAN 2.01 (or later), and initiating a
|
|
connection to FreeS/WAN 2.00 (or earlier). In your logs, you see a
|
|
message like:
|
|
<PRE>no RSA public key known for '192.0.2.13';
|
|
DNS search for KEY failed (no KEY record
|
|
for 13.2.0.192.in-addr.arpa.)</PRE>
|
|
The older FreeS/WAN logs no error.</TD><TD><A NAME="oe.trouble.flagday">
|
|
</A> A protocol level incompatibility between 2.01 (or later) and 2.00
|
|
(or earlier) causes this error. It occurs when a FreeS/WAN 2.01 (or
|
|
later) box for which no KEY record is posted attempts to initiate an OE
|
|
connection to older FreeS/WAN versions (2.00 and earlier). Note that
|
|
older versions can initiate to newer versions without this error.</TD><TD>
|
|
If you control the peer host, upgrade its FreeS/WAN to 2.01 (or later),
|
|
and post new style TXT records for it. If not, but if you know its
|
|
sysadmin, perhaps a quick note is in order. If neither option is
|
|
possible, you can ease the transition by posting an old style KEY
|
|
record (created with a command like "ipsec showhostkey --key") to the
|
|
reverse map for the FreeS/WAN 2.01 (or later) box.</TD></TR>
|
|
<TR><TD>OE host is very slow to contact other hosts.</TD><TD>Slow DNS
|
|
service while running OE.</TD><TD>It's a good idea to run a caching DNS
|
|
server on your OE host, as outlined in<A HREF="http://lists.freeswan.org/pipermail/design/2003-January/004205.html">
|
|
this mailing list message</A>. If your DNS servers are elsewhere, put
|
|
their IPs in the<VAR> clear</VAR> policy group, and re-read groups with
|
|
<PRE>ipsec auto --rereadgroups</PRE>
|
|
</TD></TR>
|
|
<TR><TD>
|
|
<PRE>Can't Opportunistically initiate for
|
|
192.0.2.2 to 192.0.2.3: no TXT record
|
|
for 13.2.0.192.in-addr.arpa.</PRE>
|
|
</TD><TD>Peer is not set up for OE.</TD><TD>
|
|
<P>None. Plenty of hosts on the Internet do not run OE. If, however, you
|
|
have set OE up on that peer, this may indicate that you need to wait up
|
|
to 48 hours for its DNS records to propagate.</P>
|
|
</TD></TR>
|
|
<TR><TD><VAR>ipsec verify</VAR> does not find DNS records:
|
|
<PRE>...
|
|
Looking for TXT in forward map:
|
|
xy.example.com...[FAILED]
|
|
Looking for TXT in reverse map...[FAILED]
|
|
...</PRE>
|
|
You also experience authentication failure:
|
|
<BR>
|
|
<PRE>Possible authentication failure:
|
|
no acceptable response to our
|
|
first encrypted message</PRE>
|
|
</TD><TD>DNS records are not posted or have not propagated.</TD><TD>Did
|
|
you post the DNS records necessary for OE? If not, do so using the
|
|
instructions in our<A HREF="#quickstart"> quickstart guide</A>. If so,
|
|
wait up to 48 hours for the DNS records to propagate.</TD></TR>
|
|
<TR><TD><VAR>ipsec verify</VAR> does not find DNS records, and you
|
|
experience authentication failure.</TD><TD>For iOE, your ID does not
|
|
match location of forward DNS record.</TD><TD>In<VAR> config setup</VAR>
|
|
, change<VAR> myid=</VAR> to match the forward DNS where you posted the
|
|
record. Restart FreeS/WAN. For reference, see our<A HREF="#opp.client">
|
|
iOE instructions</A>.</TD></TR>
|
|
<TR><TD><VAR>ipsec verify</VAR> finds DNS records, yet there is still
|
|
authentication failure. ( ? )</TD><TD>DNS records are malformed.</TD><TD>
|
|
Re-create the records and send new copies to your DNS administrator.</TD>
|
|
</TR>
|
|
<TR><TD><VAR>ipsec verify</VAR> finds DNS records, yet there is still
|
|
authentication failure. ( ? )</TD><TD>DNS records show different keys
|
|
for a gateway vs. its subnet hosts.</TD><TD>All TXT records for boxes
|
|
protected by an OE gateway must contain the gateway's public key.
|
|
Re-create and re-post any incorrect records using<A HREF="#opp.incoming">
|
|
these instructions</A>.</TD></TR>
|
|
<TR><TD>OE gateway loses connectivity to its subnet. The gateway's
|
|
routing table shows routes to the subnet through IPsec interfaces.</TD><TD>
|
|
The subnet is part of the<VAR> private</VAR> or<VAR> block</VAR> policy
|
|
group on the gateway.</TD><TD>Remove the subnet from the group, and
|
|
reread groups with
|
|
<PRE>ipsec auto --rereadgroups</PRE>
|
|
</TD></TR>
|
|
<TR><TD>OE does not work to hosts on the local LAN.</TD><TD>This is a
|
|
known issue.</TD><TD>See<A HREF="opportunism.known-issues"> this list</A>
|
|
of known issues with OE.</TD></TR>
|
|
<TR><TD>FreeS/WAN does not seem to be executing your default policy. In
|
|
your logs, you see a message like:
|
|
<PRE>/etc/ipsec.d/policies/iprivate-or-clear"
|
|
line 14: subnet "0.0.0.0/0",
|
|
source 192.0.2.13/32,
|
|
already "private-or-clear"</PRE>
|
|
</TD><TD><A HREF="#fullnet">Fullnet</A> in a policy group file defines
|
|
your default policy. Fullnet should normally be present in only one
|
|
policy group file. The fine print: you can have two default policies
|
|
defined so long as they protect different local endpoints (e.g. the
|
|
FreeS/WAN gateway and a subnet).</TD><TD> Find all policies which
|
|
contain fullnet with:
|
|
<BR>
|
|
<PRE>grep -F 0.0.0.0/0 /etc/ipsec.d/policies/*</PRE>
|
|
then remove the unwanted occurrence(s).</TD></TR>
|
|
</TABLE>
|
|
<H2><A NAME="negotiation"></A>2. During Negotiation</H2>
|
|
<P>When you fail to bring up a tunnel, you'll need to find out:</P>
|
|
<UL>
|
|
<LI><A HREF="#state">what your connection state is,</A> and often</LI>
|
|
<LI><A HREF="#find.pluto.error">an error message</A>.</LI>
|
|
</UL>
|
|
<P>before you can<A HREF="#interpret.pluto.error"> diagnose your problem</A>
|
|
.</P>
|
|
<H3><A NAME="state"></A>2.1 Determine Connection State</H3>
|
|
<H4><A NAME="8_3_1_1">Finding current state</A></H4>
|
|
<P>You can see connection states (STATE_MAIN_I1 and so on) when you
|
|
bring up a connection on the command line. If you have missed this, or
|
|
brought up your connection automatically, use:</P>
|
|
<PRE>ipsec auto --status</PRE>
|
|
<P>The most relevant state is the last one reached.</P>
|
|
<H4><A NAME="8_3_1_2"><VAR>What's this supposed to look like?</VAR></A></H4>
|
|
<P>Negotiations should proceed though various states, in the processes
|
|
of:</P>
|
|
<OL>
|
|
<LI>IKE negotiations (aka Phase 1, Main Mode, STATE_MAIN_*)</LI>
|
|
<LI>IPSEC negotiations (aka Phase 2, Quick Mode, STATE_QUICK_*)</LI>
|
|
</OL>
|
|
<P>These are done and a connection is established when you see messages
|
|
like:</P>
|
|
<PRE> 000 #21: "myconn" STATE_MAIN_I4 (ISAKMP SA established)...
|
|
000 #2: "myconn" STATE_QUICK_I2 (sent QI2, IPsec SA established)...</PRE>
|
|
<P> Look for the key phrases are "ISAKMP SA established" and "IPSec SA
|
|
established", with the relevant connection name. Often, this happens at
|
|
STATE_MAIN_I4 and STATE_QUICK_I2, respectively.</P>
|
|
<P><VAR>ipsec auto --status</VAR> will tell you what states<STRONG> have
|
|
been achieved</STRONG>, rather than the current state. Since
|
|
determining the current state is rather more difficult to do, current
|
|
state information is not available from Linux FreeS/WAN. If you are
|
|
actively bringing a connection up, the status report's last states for
|
|
that connection likely reflect its current state. Beware, though, of
|
|
the case where a connection was correctly brought up but is now downed:
|
|
Linux FreeS/WAN will not notice this until it attempts to rekey.
|
|
Meanwhile, the last known state indicates that the connection has been
|
|
established.</P>
|
|
<P>If your connection is stuck at STATE_MAIN_I1, skip straight to<A HREF="#ikepath">
|
|
here</A>.</P>
|
|
<H3><A NAME="find.pluto.error"></A>2.2 Finding error text</H3>
|
|
<P>Solving most errors will require you to find verbose error text,
|
|
either on the command line or in the logs.</P>
|
|
<H4><A NAME="8_3_2_1">Verbose start for more information</A></H4>
|
|
<P> Note that you can get more detail from<VAR> ipsec auto</VAR> using
|
|
the --verbose flag:</P>
|
|
<PRE STYLE="margin-bottom: 0.2in"> ipsec auto --verbose --up west-east</PRE>
|
|
<P> More complete information can be gleaned from the<A HREF="#logusage">
|
|
log files</A>.</P>
|
|
<H4><A NAME="8_3_2_2">Debug levels count</A></H4>
|
|
<P>The amount of description you'll get here depends on ipsec.conf debug
|
|
settings,<VAR> klipsdebug</VAR>= and<VAR> plutodebug</VAR>=. When
|
|
troubleshooting, set at least one of these to<VAR> all</VAR>, and when
|
|
done, reset it to<VAR> none</VAR> so your logs don't fill up. Note that
|
|
you must have enabled the<VAR> klipsdebug</VAR><A HREF="install.html#allbut">
|
|
compile-time option</A> for the<VAR> klipsdebug</VAR> configuration
|
|
switch to work.</P>
|
|
<P>For negotiation problems<VAR> plutodebug</VAR> is most relevant.<VAR>
|
|
klipsdebug</VAR> applies mainly to attempts to use an
|
|
already-established connection. See also<A HREF="#parts"> this</A>
|
|
description of the division of duties within Linux FreeS/WAN.</P>
|
|
<P>After raising your debug levels, restart Linux FreeS/WAN to ensure
|
|
that ipsec.conf is reread, then recreate the error to generate verbose
|
|
logs.</P>
|
|
<H4><A NAME="8_3_2_3"><VAR>ipsec barf</VAR> for lots of debugging
|
|
information</A></H4>
|
|
<P><A HREF="manpage.d/ipsec_barf.8.html"><VAR> ipsec barf (8)</VAR></A>
|
|
collects a bunch of useful debugging information, including these logs
|
|
Use the command</P>
|
|
<PRE>
|
|
ipsec barf > barf.west
|
|
</PRE>
|
|
<P>to generate one.</P>
|
|
<H4><A NAME="8_3_2_4">Find the error</A></H4>
|
|
<P>Search out the failure point in your logs. Are there a handful of
|
|
lines which succinctly describe how things are going wrong or contrary
|
|
to your expectation? Sometimes the failure point is not immediately
|
|
obvious: Linux FreeS/WAN's errors are usually not marked "Error". Have
|
|
a look in the<A HREF="faq.html"> FAQ</A> for what some common failures
|
|
look like.</P>
|
|
<P>Tip: problems snowball. Focus your efforts on the first problem,
|
|
which is likely to be the cause of later errors.</P>
|
|
<H4><A NAME="8_3_2_5">Play both sides</A></H4>
|
|
<P>Also find error text on the peer IPSec box. This gives you two
|
|
perspectives on the same failure.</P>
|
|
<P>At times you will require information which only one side has. The
|
|
peer can merely indicate the presence of an error, and its approximate
|
|
point in the negotiations. If one side keeps retrying, it may be
|
|
because there is a show stopper on the other side. Have a look at the
|
|
other side and figure out what it doesn't like.</P>
|
|
<P>If the other end is not Linux FreeS/WAN, the principle is the same:
|
|
replicate the error with its most verbose logging on, and capture the
|
|
output to a file.</P>
|
|
<H3><A NAME="interpret.pluto.error"></A>2.3 Interpreting a Negotiation
|
|
Error</H3>
|
|
<H4><A NAME="ikepath"></A>Connection stuck at STATE_MAIN_I1</H4>
|
|
<P>This error commonly happens because IKE (port 500) packets, needed to
|
|
negotiate an IPSec connection, cannot travel freely between your IPSec
|
|
gateways. See<A HREF="#packets"> our firewall document</A> for details.</P>
|
|
<H4><A NAME="8_3_3_2">Other errors</A></H4>
|
|
<P>Other errors require a bit more digging. Use the following resources:</P>
|
|
<UL>
|
|
<LI><A HREF="faq.html">the FAQ</A> . Since this document is constantly
|
|
updated, the snapshot's FAQ may have a new entry relevant to your
|
|
problem.</LI>
|
|
<LI>our<A HREF="background.html"> background document</A> . Special
|
|
considerations which, while not central to Linux FreeS/WAN, are often
|
|
tripped over. Includes problems with<A href="#MTU.trouble"> packet
|
|
fragmentation</A>, and considerations for testing opportunism.</LI>
|
|
<LI>the<A HREF="#lists"> list archives</A>. Each of the searchable
|
|
archives works differently, so it's worth checking each. Use a search
|
|
term which is generic, but identifies your error, for example "No
|
|
connection is known for".
|
|
<BR> Often, you will find that your question has been answered in the
|
|
past. Finding an archived answer is quicker than asking the list. You
|
|
may, however, find similar questions without answers. If you do, send
|
|
their URLs to the list with your trouble report. The additional
|
|
examples may help the list tech support person find your answer.</LI>
|
|
<LI>Look into the code where the error is being generated. The pluto
|
|
code is nicely documented with comments and meaningful variable names.</LI>
|
|
</UL>
|
|
<P>If you have failed to solve your problem with the help of these
|
|
resources, send a detailed problem report to the users list, following
|
|
these<A HREF="#prob.report"> guidelines</A>.</P>
|
|
<H2><A NAME="use"></A>3. Using a Connection</H2>
|
|
<H3><A NAME="8_4_1">3.1 Orienting yourself</A></H3>
|
|
<H4><A NAME="8_4_1_1"><VAR>How do I know if it works?</VAR></A></H4>
|
|
<P>Test your connection by sending packets through it. The simplest way
|
|
to do this is with ping, but the ping needs to<STRONG> test the correct
|
|
tunnel.</STRONG> See<A HREF="#testgates"> this example scenario</A> if
|
|
you don't understand this.</P>
|
|
<P></P>
|
|
<P>If your ping returns, test any other connections you've brought u all
|
|
check out, great. You may wish to<A HREF="#bigpacket"> test with large
|
|
packets</A> for MTU problems.</P>
|
|
<H4><A NAME="8_4_1_2"><VAR>ipsec barf</VAR> is useful again</A></H4>
|
|
<P>If your ping fails to return, generate an ipsec barf debugging report
|
|
on each IPSec gateway. On a non-Linux FreeS/WAN implementation, gather
|
|
equivalent information. Use this, and the tips in the next sections, to
|
|
troubleshoot. Are you sure that both endpoints are capable of hearing
|
|
and responding to ping?</P>
|
|
<H3><A NAME="8_4_2">3.2 Those pesky configuration errors</A></H3>
|
|
<P>IPSec may be dropping your ping packets since they do not belong in
|
|
the tunnels you have constructed:</P>
|
|
<UL>
|
|
<LI>Your ping may not test the tunnel you intend to test. For details,
|
|
see our<A HREF="#cantping"> "I can't ping"</A> FAQ.</LI>
|
|
<LI> Alternately, you may have a configuration error. For example, you
|
|
may have configured one of the four possible tunnels between two
|
|
gateways, but not the one required to secure the important traffic
|
|
you're now testing. In this case, add and start the tunnel, and try
|
|
again.</LI>
|
|
</UL>
|
|
<P>In either case, you will often see a message like:</P>
|
|
<PRE>klipsdebug... no eroute</PRE>
|
|
<P>which we discuss in<A HREF="#no_eroute"> this FAQ</A>.</P>
|
|
<P>Note:</P>
|
|
<UL>
|
|
<LI><A HREF="#NAT.gloss">Network Address Translation (NAT)</A> and<A HREF="#masq">
|
|
IP masquerade</A> may have an effect on which tunnels you need to
|
|
configure.</LI>
|
|
<LI>When testing a tunnel that protects a multi-node subnet, try several
|
|
subnet nodes as ping targets, in case one node is routing incorrectly.</LI>
|
|
</UL>
|
|
<H3><A NAME="route.firewall"></A>3.3 Check Routing and Firewalling</H3>
|
|
<P>If you've confirmed your configuration assumptions, the problem is
|
|
almost certainly with routing or firewalling. Isolate the problem using
|
|
interface statistics, firewall statistics, or a packet sniffer.</P>
|
|
<H4><A NAME="8_4_3_1">Background:</A></H4>
|
|
<UL>
|
|
<LI>Linux FreeS/WAN supplies all the special routing it needs; you need
|
|
only route packets out through your IPSec gateway. Verify that on the<VAR>
|
|
subnetted</VAR> machines you are using for your ping-test, your routing
|
|
is as expected. I have seen a tunnel "fail" because the subnet machine
|
|
sending packets out an alternate gateway (not our IPSec gateway) on
|
|
their return path.</LI>
|
|
<LI>Linux FreeS/WAN requires particular<A HREF="firewall.html">
|
|
firewalling considerations</A>. Check the firewall rules on your IPSec
|
|
gateways and ensure that they allow IPSec traffic through. Be sure that
|
|
no other machine - for example a router between the gateways - is
|
|
blocking your IPSec packets.</LI>
|
|
</UL>
|
|
<H4><A NAME="ifconfig"></A>View Interface and Firewall Statistics</H4>
|
|
<P>Interface reports and firewall statistics can help you track down
|
|
lost packets at a glance. Check any firewall statistics you may be
|
|
keeping on your IPSec gateways, for dropped packets.</P>
|
|
<P><STRONG>Tip</STRONG>: You can take a snapshot of the packets
|
|
processed by your firewall with:</P>
|
|
<PRE> iptables -L -n -v</PRE>
|
|
<P>You can get creative with "diff" to find out what happens to a
|
|
particular packet during transmission.</P>
|
|
<P>Both<VAR> cat /proc/net/dev</VAR> and<VAR> ifconfig</VAR> display
|
|
interface statistics, and both are included in<VAR> ipsec barf</VAR>.
|
|
Use either to check if any interface has dropped packets. If you find
|
|
that one has, test whether this is related to your ping. While you ping
|
|
continuously, print that interface's statistics several times. Does its
|
|
drop count increase in proportion to the ping? If so, check why the
|
|
packets are dropped there.</P>
|
|
<P>To do this, look at the firewall rules that apply to that interface.
|
|
If the interface is an IPSec interface, more information may be
|
|
available in the log. Grep for the word "drop" in a log which was
|
|
created with<VAR> klipsdebug=all</VAR> as the error happened.</P>
|
|
<P>See also this<A HREF="#ifconfig1"> discussion</A> on interpreting<VAR>
|
|
ifconfig</VAR> statistics.</P>
|
|
<H3><A NAME="sniff"></A>3.4 When in doubt, sniff it out</H3>
|
|
<P>If you have checked configuration assumptions, routing, and firewall
|
|
rules, and your interface statistics yield no clue, it remains for you
|
|
to investigate the mystery of the lost packet by the most thorough
|
|
method: with a packet sniffer (providing, of course, that this is legal
|
|
where you are working).</P>
|
|
<P>In order to detect packets on the ipsec virtual interfaces, you will
|
|
need an up-to-date sniffer (tcpdump, ethereal, ksnuffle) on your IPSec
|
|
gateway machines. You may also find it useful to sniff the ping
|
|
endpoints.</P>
|
|
<H4><A NAME="8_4_4_1">Anticipate your packets' path</A></H4>
|
|
<P>Ping, and examine each interface along the projected path, checking
|
|
for your ping's arrival. If it doesn't get to the the next stop, you
|
|
have narrowed down where to look for it. In this way, you can isolate a
|
|
problem area, and narrow your troubleshooting focus.</P>
|
|
<P>Within a machine running Linux FreeS/WAN, this<A HREF="#packets">
|
|
packet flow diagram</A> will help you anticipate a packet's path.</P>
|
|
<P>Note that:</P>
|
|
<UL>
|
|
<LI> from the perspective of the tunneled packet, the entire tunnel is
|
|
one hop. That's explained in<A HREF="#no_trace"> this</A> FAQ.</LI>
|
|
<LI> an encapsulated IPSec packet will look different, when sniffed,
|
|
from the plaintext packet which generated it. You can see plaintext
|
|
packets entering an IPSec interface and the resulting cyphertext
|
|
packets as they emerge from the corresponding physical interface.</LI>
|
|
</UL>
|
|
<P>Once you isolate where the packet is lost, take a closer look at
|
|
firewall rules, routing and configuration assumptions as they affect
|
|
that specific area. If the packet is lost on an IPSec gateway, comb
|
|
through<VAR> klipsdebug</VAR> output for anomalies.</P>
|
|
<P>If the packet goes through both gateways successfully and reaches the
|
|
ping target, but does not return, suspect routing. Check that the ping
|
|
target routes packets back to the IPSec gateway.</P>
|
|
<H3><A NAME="find.use.error"></A>3.5 Check your logs</H3>
|
|
<P>Here, too, log information can be useful. Start with the<A HREF="#find.pluto.error">
|
|
guidelines above</A>.</P>
|
|
<P>For connection use problems, set<VAR> klipsdebug=all</VAR>. Note that
|
|
you must have enabled the<VAR> klipsdebug</VAR><A HREF="install.html#allbut">
|
|
compile-time option</A> to do this. Restart Linux FreeS/WAN so that it
|
|
rereads<VAR> ipsec.conf</VAR>, then recreate the error condition. When
|
|
searching through<VAR> klipsdebug</VAR> data, look especially for the
|
|
keywords "drop" (as in dropped packets) and "error".</P>
|
|
<P>Often the problem with connection use is not software error, but
|
|
rather that the software is behaving contrary to expectation.</P>
|
|
<H4><A NAME="interpret.use.error"></A>Interpreting log text</H4>
|
|
<P>To interpret the Linux FreeS/WAN log text you've found, use the same
|
|
resources as indicated for troubleshooting connection negotiation:<A HREF="faq.html">
|
|
the FAQ</A> , our<A HREF="background.html"> background document</A>,
|
|
and the<A HREF="#lists"> list archives</A>. Looking in the KLIPS code
|
|
is only for the very brave.</P>
|
|
<P>If you are still stuck, send a<A HREF="#prob.report"> detailed
|
|
problem report</A> to the users' list.</P>
|
|
<H3><A NAME="bigpacket"></A>3.6 More testing for the truly thorough</H3>
|
|
<H4><A NAME="8_4_6_1">Large Packets</A></H4>
|
|
<P>If each of your connections passed the ping test, you may wish to
|
|
test by pinging with large packets (2000 bytes or larger). If it does
|
|
not return, suspect MTU issues, and see this<A HREF="#MTU.trouble">
|
|
discussion</A>.</P>
|
|
<H4><A NAME="8_4_6_2">Stress Tests</A></H4>
|
|
<P>In most users' view, a simple ping test, and perhaps a large-packet
|
|
ping test suffice to indicate a working IPSec connection.</P>
|
|
<P>Some people might like to do additional stress tests prior to
|
|
production use. They may be interested in this<A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00224.html">
|
|
testing protocol</A> we use at interoperation conferences, aka
|
|
"bakeoffs". We also have a<VAR> testing</VAR> directory that ships with
|
|
the release.</P>
|
|
<H2><A NAME="prob.report"></A>4. Problem Reporting</H2>
|
|
<H3><A NAME="8_5_1">4.1 How to ask for help</A></H3>
|
|
<P>Ask for troubleshooting help on the users' mailing list,<A HREF="mailto:[email protected]">
|
|
[email protected]</A>. While sometimes an initial query with a
|
|
quick description of your intent and error will twig someone's memory
|
|
of a similar problem, it's often necessary to send a second mail with a
|
|
complete problem report.</P>
|
|
<P>When reporting problems to the mailing list(s), please include:</P>
|
|
<UL>
|
|
<LI>a brief description of the problem</LI>
|
|
<LI>if it's a compile problem, the actual output from make, showing the
|
|
problem. Try to edit it down to only the relevant part, but when in
|
|
doubt, be as complete as you can. If it's a kernel compile problem, any
|
|
relevant out.* files</LI>
|
|
<LI>if it's a run-time problem, pointers to where we can find the
|
|
complete output from "ipsec barf" from BOTH ENDS (not just one of
|
|
them). Remember that it's common outside the US and Canada to pay for
|
|
download volume, so if you can't post barfs on the web and send the URL
|
|
to the mailing list, at least compress them with tar or gzip.
|
|
<BR> If you can, try to simplify the case that is causing the problem.
|
|
In particular, if you clear your logs, start FreeS/WAN with no other
|
|
connections running, cause the problem to happen, and then do<VAR>
|
|
ipsec barf</VAR> on both ends immediately, that gives the smallest and
|
|
least cluttered output.</LI>
|
|
<LI>any other error messages, complaints, etc. that you saw. Please send
|
|
the complete text of the messages, not just a summary.</LI>
|
|
<LI>what your network setup is. Include subnets, gateway addresses, etc.
|
|
A schematic diagram is a good format for this information.</LI>
|
|
<LI>exactly what you were trying to do with Linux FreeS/WAN, and exactly
|
|
what went wrong</LI>
|
|
<LI>a fix, if you have one. But remember, you are sending mail to people
|
|
all over the world; US residents and US citizens in particular, please
|
|
read doc/exportlaws.html before sending code -- even small bug fixes --
|
|
to the list or to us.</LI>
|
|
<LI>When in doubt about whether to include some seemingly-trivial item
|
|
of information, include it. It is rare for problem reports to have too
|
|
much information, and common for them to have too little.</LI>
|
|
</UL>
|
|
<P>Here are some good general guidelines on bug reporting:<A href="http://tuxedo.org/~esr/faqs/smart-questions.html">
|
|
How To Ask Questions The Smart Way</A> and<A href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">
|
|
How to Report Bugs Effectively</A>.</P>
|
|
<H3><A NAME="8_5_2">4.2 Where to ask</A></H3>
|
|
<P>To report a problem, send mail about it to the users' list. If you
|
|
are certain that you have found a bug, report it to the bugs list. If
|
|
you encounter a problem while doing your own coding on the Linux
|
|
FreeS/WAN codebase and think it is of interest to the design team,
|
|
notify the design list. When in doubt, default to the users' list. More
|
|
information about the mailing lists is found<A HREF="#lists"> here</A>.</P>
|
|
<P>For a number of reasons -- including export-control regulations
|
|
affecting almost any<STRONG> private</STRONG> discussion of encryption
|
|
software -- we prefer that problem reports and discussions go to the
|
|
lists, not directly to the team. Beware that the list goes worldwide;
|
|
US citizens, read this important information about your<A HREF="#exlaw">
|
|
export laws</A>. If you're using this software, you really should be on
|
|
the lists. To get onto them, visit<A HREF="http://lists.freeswan.org/">
|
|
lists.freeswan.org</A>.</P>
|
|
<P>If you do send private mail to our coders or want a private reply
|
|
from them, please make sure that the return address on your mail (From
|
|
or Reply-To header) is a valid one. They have more important things to
|
|
do than to unravel addresses that have been mangled in an attempt to
|
|
confuse spammers.</P>
|
|
<H2><A NAME="notes"></A>5. Additional Notes on Troubleshooting</H2>
|
|
<P>The following sections supplement the Guide:<A HREF="#system.info">
|
|
information available on your system</A>;<A HREF="#testgates"> testing
|
|
between security gateways</A>;<A HREF="#ifconfig1"> ifconfig reports
|
|
for KLIPS debugging</A>;<A HREF="#gdb"> using GDB on Pluto</A>.</P>
|
|
<H3><A NAME="system.info"></A>5.1 Information available on your system</H3>
|
|
<H4><A NAME="logusage"></A>Logs used</H4>
|
|
<P>Linux FreeS/WAN logs to:</P>
|
|
<UL>
|
|
<LI>/var/log/secure (or, on Debian, /var/log/auth.log)</LI>
|
|
<LI>/var/log/messages</LI>
|
|
</UL>
|
|
<P>Check both places to get full information. If you find nothing, check
|
|
your<VAR> syslogd.conf(5)</VAR> to see where your /etc/syslog.conf or
|
|
equivalent is directing<VAR> authpriv</VAR> messages.</P>
|
|
<H4><A NAME="pages"></A>man pages provided</H4>
|
|
<DL>
|
|
<DT><A HREF="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></DT>
|
|
<DD> Manual page for IPSEC configuration file.</DD>
|
|
<DT><A HREF="manpage.d/ipsec.8.html"> ipsec(8)</A></DT>
|
|
<DD STYLE="margin-bottom: 0.2in"> Primary man page for ipsec utilities.</DD>
|
|
</DL>
|
|
<P> Other man pages are on<A HREF="manpages.html"> this list</A> and in</P>
|
|
<UL>
|
|
<LI>/usr/local/man/man3</LI>
|
|
<LI>/usr/local/man/man5</LI>
|
|
<LI>/usr/local/man/man8/ipsec_*</LI>
|
|
</UL>
|
|
<H4><A NAME="statusinfo"></A>Status information</H4>
|
|
<DL>
|
|
<DT>ipsec auto --status</DT>
|
|
<DD> Command to get status report from running system. Displays Pluto's
|
|
state. Includes the list of connections which are currently "added" to
|
|
Pluto's internal database; lists state objects reflecting ISAKMP and
|
|
IPsec SAs being negotiated or installed.</DD>
|
|
<DT> ipsec look</DT>
|
|
<DD> Brief status info.</DD>
|
|
<DT> ipsec barf</DT>
|
|
<DD STYLE="margin-bottom: 0.2in"> Copious debugging info.</DD>
|
|
</DL>
|
|
<H3><A NAME="testgates"></A> 5.2 Testing between security gateways</H3>
|
|
<P>Sometimes you need to test a subnet-subnet tunnel. This is a tunnel
|
|
between two security gateways, which protects traffic on behalf of the
|
|
subnets behind these gateways. On this network:</P>
|
|
<PRE> Sunset==========West------------------East=========Sunrise
|
|
IPSec gateway IPSec gateway
|
|
local net untrusted net local net</PRE>
|
|
<P> you might name this tunnel sunset-sunrise. You can test this tunnel
|
|
by having a machine behind one gateway ping a machine behind the other
|
|
gateway, but this is not always convenient or even possible.</P>
|
|
<P>Simply pinging one gateway from the other is not useful. Such a ping
|
|
does not normally go through the tunnel.<STRONG> The tunnel handles
|
|
traffic between the two protected subnets, not between the gateways</STRONG>
|
|
. Depending on the routing in place, a ping might</P>
|
|
<UL>
|
|
<LI>either succeed by finding an unencrypted route</LI>
|
|
<LI>or fail by finding no route. Packets without an IPSEC eroute are
|
|
discarded.</LI>
|
|
</UL>
|
|
<P><STRONG>Neither event tells you anything about the tunnel</STRONG>.
|
|
You can explicitly create an eroute to force such packets through the
|
|
tunnel, or you can create additional tunnels as described in our<A HREF="#multitunnel">
|
|
configuration document</A>, but those may be unnecessary complications
|
|
in your situation.</P>
|
|
<P>The trick is to explicitly test between<STRONG> both gateways'
|
|
private-side IP addresses</STRONG>. Since the private-side interfaces
|
|
are on the protected subnets, the resulting packets do go via the
|
|
tunnel. Use either ping -I or traceroute -i, both of which allow you to
|
|
specify a source interface. (Note: unsupported on older Linuxes). The
|
|
same principles apply for a road warrior (or other) case where only one
|
|
end of your tunnel is a subnet.</P>
|
|
<H3><A NAME="ifconfig1"></A>5.3 ifconfig reports for KLIPS debugging</H3>
|
|
<P>When diagnosing problems using ifconfig statistics, you may wonder
|
|
what type of activity increments a particular counter for an ipsecN
|
|
device. Here's an index, posted by KLIPS developer Richard Guy Briggs:</P>
|
|
<PRE>Here is a catalogue of the types of errors that can occur for which
|
|
statistics are kept when transmitting and receiving packets via klips.
|
|
I notice that they are not necessarily logged in the right counter.
|
|
. . .
|
|
|
|
Sources of ifconfig statistics for ipsec devices
|
|
|
|
rx-errors:
|
|
- packet handed to ipsec_rcv that is not an ipsec packet.
|
|
- ipsec packet with payload length not modulo 4.
|
|
- ipsec packet with bad authenticator length.
|
|
- incoming packet with no SA.
|
|
- replayed packet.
|
|
- incoming authentication failed.
|
|
- got esp packet with length not modulo 8.
|
|
|
|
tx_dropped:
|
|
- cannot process ip_options.
|
|
- packet ttl expired.
|
|
- packet with no eroute.
|
|
- eroute with no SA.
|
|
- cannot allocate sk_buff.
|
|
- cannot allocate kernel memory.
|
|
- sk_buff internal error.
|
|
|
|
|
|
The standard counters are:
|
|
|
|
struct enet_statistics
|
|
{
|
|
int rx_packets; /* total packets received */
|
|
int tx_packets; /* total packets transmitted */
|
|
int rx_errors; /* bad packets received */
|
|
int tx_errors; /* packet transmit problems */
|
|
int rx_dropped; /* no space in linux buffers */
|
|
int tx_dropped; /* no space available in linux */
|
|
int multicast; /* multicast packets received */
|
|
int collisions;
|
|
|
|
/* detailed rx_errors: */
|
|
int rx_length_errors;
|
|
int rx_over_errors; /* receiver ring buff overflow */
|
|
int rx_crc_errors; /* recved pkt with crc error */
|
|
int rx_frame_errors; /* recv'd frame alignment error */
|
|
int rx_fifo_errors; /* recv'r fifo overrun */
|
|
int rx_missed_errors; /* receiver missed packet */
|
|
|
|
/* detailed tx_errors */
|
|
int tx_aborted_errors;
|
|
int tx_carrier_errors;
|
|
int tx_fifo_errors;
|
|
int tx_heartbeat_errors;
|
|
int tx_window_errors;
|
|
};
|
|
|
|
of which I think only the first 6 are useful.</PRE>
|
|
<H3><A NAME="gdb"></A> 5.4 Using GDB on Pluto</H3>
|
|
<P>You may need to use the GNU debugger, gdb(1), on Pluto. This should
|
|
be necessary only in unusual cases, for example if you encounter a
|
|
problem which the Pluto developer cannot readily reproduce or if you
|
|
are modifying Pluto.</P>
|
|
<P>Here are the Pluto developer's suggestions for doing this:</P>
|
|
<PRE>Can you get a core dump and use gdb to find out what Pluto was doing
|
|
when it died?
|
|
|
|
To get a core dump, you will have to set dumpdir to point to a
|
|
suitable directory (see <A HREF="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A>).
|
|
|
|
To get gdb to tell you interesting stuff:
|
|
$ script
|
|
$ cd dump-directory-you-chose
|
|
$ gdb /usr/local/lib/ipsec/pluto core
|
|
(gdb) where
|
|
(gdb) quit
|
|
$ exit
|
|
|
|
The resulting output will have been captured by the script command in
|
|
a file called "typescript". Send it to the list.
|
|
|
|
Do not delete the core file. I may need to ask you to print out some
|
|
more relevant stuff.</PRE>
|
|
<P> Note that the<VAR> dumpdir</VAR> parameter takes effect only when
|
|
the IPsec subsystem is restarted -- reboot or ipsec setup restart.</P>
|
|
<P>
|
|
<BR>
|
|
<BR></P>
|
|
<HR>
|
|
<H1><A name="compat">Linux FreeS/WAN Compatibility Guide</A></H1>
|
|
<P>Much of this document is quoted directly from the Linux FreeS/WAN<A href="mail.html">
|
|
mailing list</A>. Thanks very much to the community of testers,
|
|
patchers and commenters there, especially the ones quoted below but
|
|
also various contributors we haven't quoted.</P>
|
|
<H2><A name="spec">Implemented parts of the IPsec Specification</A></H2>
|
|
<P>In general, do not expect Linux FreeS/WAN to do everything yet. This
|
|
is a work-in-progress and some parts of the IPsec specification are not
|
|
yet implemented.</P>
|
|
<H3><A name="in">In Linux FreeS/WAN</A></H3>
|
|
<P>Things we do, as of version 1.96:</P>
|
|
<UL>
|
|
<LI>key management methods
|
|
<DL>
|
|
<DT>manually keyed</DT>
|
|
<DD>using keys stored in /etc/ipsec.conf</DD>
|
|
<DT>automatically keyed</DT>
|
|
<DD>Automatically negotiating session keys as required. All connections
|
|
are automatically re-keyed periodically. The<A href="#Pluto"> Pluto</A>
|
|
daemon implements this using the<A href="#IKE"> IKE</A> protocol.</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>Methods of authenticating gateways for IKE
|
|
<DL>
|
|
<DT>shared secrets</DT>
|
|
<DD>stored in<A href="manpage.d/ipsec.secrets.5.html"> ipsec.secrets(5)</A>
|
|
</DD>
|
|
<DT><A href="#RSA">RSA</A> signatures</DT>
|
|
<DD>For details, see<A href="manpage.d/ipsec_pluto.8.html"> pluto(8)</A>
|
|
.</DD>
|
|
<DT>looking up RSA authentication keys from<A href="#DNS"> DNS</A>.</DT>
|
|
<DD>Note that this technique cannot be fully secure until<A href="#SDNS">
|
|
secure DNS</A> is widely deployed.</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>groups for<A href="#DH"> Diffie-Hellman</A> key negotiation
|
|
<DL>
|
|
<DT>group 2, modp 1024-bit</DT>
|
|
<DT>group 5, modp 1536-bit</DT>
|
|
<DD>We implement these two groups.
|
|
<P>In negotiating a keying connection (ISAKMP SA, Phase 1) we propose
|
|
both groups when we are the initiator, and accept either when a peer
|
|
proposes them. Once the keying connection is made, we propose only the
|
|
alternative agreed there for data connections (IPsec SA's, Phase 2)
|
|
negotiated over that keying connection.</P>
|
|
</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>encryption transforms
|
|
<DL>
|
|
<DT><A href="#DES">DES</A></DT>
|
|
<DD>DES is in the source code since it is needed to implement 3DES, but
|
|
single DES is not made available to users because<A href="#desnotsecure">
|
|
DES is insecure</A>.</DD>
|
|
<DT><A href="#3DES">Triple DES</A></DT>
|
|
<DD>implemented, and used as the default encryption in Linux FreeS/WAN.</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>authentication transforms
|
|
<DL>
|
|
<DT><A href="#HMAC">HMAC</A> using<A href="#MD5"> MD5</A></DT>
|
|
<DD>implemented, may be used in IKE or by by AH or ESP transforms.</DD>
|
|
<DT><A href="#HMAC">HMAC</A> using<A href="#SHA"> SHA</A></DT>
|
|
<DD>implemented, may be used in IKE or by AH or ESP transforms.</DD>
|
|
</DL>
|
|
<P>In negotiations, we propose both of these and accept either.</P>
|
|
</LI>
|
|
<LI>compression transforms
|
|
<DL>
|
|
<DT>IPComp</DT>
|
|
<DD>IPComp as described in RFC 2393 was added for FreeS/WAN 1.6. Note
|
|
that Pluto becomes confused if you ask it to do IPComp when the kernel
|
|
cannot.</DD>
|
|
</DL>
|
|
</LI>
|
|
</UL>
|
|
<P>All combinations of implemented transforms are supported. Note that
|
|
some form of packet-level<STRONG> authentication is required whenever
|
|
encryption is used</STRONG>. Without it, the encryption will not be
|
|
secure.</P>
|
|
<H3><A name="dropped">Deliberately omitted</A></H3>
|
|
We do not implement everything in the RFCs because some of those things
|
|
are insecure. See our discussions of avoiding<A href="#weak"> bogus
|
|
security</A>.
|
|
<P>Things we deliberately omit which are required in the RFCs are:</P>
|
|
<UL>
|
|
<LI>null encryption (to use ESP as an authentication-only service)</LI>
|
|
<LI>single DES</LI>
|
|
<LI>DH group 1, a 768-bit modp group</LI>
|
|
</UL>
|
|
<P>Since these are the only encryption algorithms and DH group the RFCs
|
|
require, it is possible in theory to have a standards-conforming
|
|
implementation which will not interpoperate with FreeS/WAN. Such an
|
|
implementation would be inherently insecure, so we do not consider this
|
|
a problem.</P>
|
|
<P>Anyway, most implementations sensibly include more secure options as
|
|
well, so dropping null encryption, single DES and Group 1 does not
|
|
greatly hinder interoperation in practice.</P>
|
|
<P>We also do not implement some optional features allowed by the RFCs:</P>
|
|
<UL>
|
|
<LI>aggressive mode for negotiation of the keying channel or ISAKMP SA.
|
|
This mode is a little faster than main mode, but exposes more
|
|
information to an eavesdropper.</LI>
|
|
</UL>
|
|
<P>In theory, this should cause no interoperation problems since all
|
|
implementations are required to support the more secure main mode,
|
|
whether or not they also allow aggressive mode.</P>
|
|
<P>In practice, it does sometimes produce problems with implementations
|
|
such as Windows 2000 where aggressive mode is the default. Typically,
|
|
these are easily solved with a configuration change that overrides that
|
|
default.</P>
|
|
<H3><A name="not">Not (yet) in Linux FreeS/WAN</A></H3>
|
|
<P>Things we don't yet do, as of version 1.96:</P>
|
|
<UL>
|
|
<LI>key management methods
|
|
<UL>
|
|
<LI>authenticate key negotiations via local<A href="#PKI"> PKI</A>
|
|
server, but see links to user<A href="#patch"> patches</A></LI>
|
|
<LI>authenticate key negotiations via<A href="#SDNS"> secure DNS</A></LI>
|
|
<LI>unauthenticated key management, using<A href="#DH"> Diffie-Hellman</A>
|
|
key agreement protocol without authentication. Arguably, this would be
|
|
worth doing since it is secure against all passive attacks. On the
|
|
other hand, it is vulnerable to an active<A href="#middle">
|
|
man-in-the-middle attack</A>.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>encryption transforms
|
|
<P>Currently<A href="#3DES"> Triple DES</A> is the only encryption
|
|
method Pluto will negotiate.</P>
|
|
<P>No additional encryption transforms are implemented, though the RFCs
|
|
allow them and some other IPsec implementations support various of
|
|
them. We are not eager to add more. See this<A href="#other.cipher">
|
|
FAQ question</A>.</P>
|
|
<P><A href="#AES">AES</A>, the successor to the DES standard, is an
|
|
excellent candidate for inclusion in FreeS/WAN, see links to user<A href="#patch">
|
|
patches</A>.</P>
|
|
</LI>
|
|
<LI>authentication transforms
|
|
<P>No optional additional authentication transforms are currently
|
|
implemented. Likely<A href="#SHA-256"> SHA-256, SHA-384 and SHA-512</A>
|
|
will be added when AES is.</P>
|
|
</LI>
|
|
<LI>Policy checking on decrypted packets
|
|
<P>To fully comply with the RFCs, it is not enough just to accept only
|
|
packets which survive any firewall rules in place to limit what IPsec
|
|
packets get in, and then pass KLIPS authentication. That is what
|
|
FreeS/WAN currently does.</P>
|
|
<P>We should also apply additional tests, for example ensuring that all
|
|
packets emerging from a particular tunnel have source and destination
|
|
addresses that fall within the subnets defined for that tunnel, and
|
|
that packets with those addresses that did not emerge from the
|
|
appropriate tunnel are disallowed.</P>
|
|
<P>This will be done as part of a KLIPS rewrite. See these<A href="#applied">
|
|
links</A> and the<A href="mail.html"> design mailing list</A> for
|
|
discussion.</P>
|
|
</LI>
|
|
</UL>
|
|
<H2><A name="pfkey">Our PF-Key implementation</A></H2>
|
|
<P>We use PF-key Version Two for communication between the KLIPS kernel
|
|
code and the Pluto Daemon. PF-Key v2 is defined by<A href="http://www.normos.org/ietf/rfc/rfc2367.txt">
|
|
RFC 2367</A>.</P>
|
|
<P>The "PF" stands for Protocol Family. PF-Inet defines a
|
|
kernel/userspace interface for the TCP/IP Internet protocols (TCP/IP),
|
|
and other members of the PF series handle Netware, Appletalk, etc.
|
|
PF-Key is just a PF for key-related matters.</P>
|
|
<H3><A name="pfk.port">PF-Key portability</A></H3>
|
|
<P>PF-Key came out of Berkeley Unix work and is used in the various BSD
|
|
IPsec implementations, and in Solaris. This means there is some hope of
|
|
porting our Pluto(8) to one of the BSD distributions, or of running
|
|
their photurisd(8) on Linux if you prefer<A href="#photuris"> Photuris</A>
|
|
key management over IKE.</P>
|
|
<P>It is, however, more complex than that. The PK-Key RFC deliberately
|
|
deals only with keying, not policy management. The three PF-Key
|
|
implementations we have looked at -- ours, OpenBSD and KAME -- all have
|
|
extensions to deal with security policy, and the extensions are
|
|
different. There have been discussions aimed at sorting out the
|
|
differences, perhaps for a version three PF-Key spec. All players are
|
|
in favour of this, but everyone involved is busy and it is not clear
|
|
whether or when these discussions might bear fruit.</P>
|
|
<H2><A name="otherk">Kernels other than the latest 2.2.x and 2.4.y</A></H2>
|
|
<P>We develop and test on Redhat Linux using the most recent kernel in
|
|
the 2.2 and 2.4 series. In general, we recommend you use the latest
|
|
kernel in one of those series. Complications and caveats are discussed
|
|
below.</P>
|
|
<H3><A name="kernel.2.0">2.0.x kernels</A></H3>
|
|
<P>Consider upgrading to the 2.2 kernel series. If you want to stay with
|
|
the 2.0 series, then we strongly recommend 2.0.39. Some useful security
|
|
patches were added in 2.0.38.</P>
|
|
<P>Various versions of the code have run at various times on most 2.0.xx
|
|
kernels, but the current version is only lightly tested on 2.0.39, and
|
|
not at all on older kernels.</P>
|
|
<P>Some of our patches for older kernels are shipped in 2.0.37 and
|
|
later, so they are no longer provided in FreeS/WAN. This means recent
|
|
versions of FreeS/WAN will probably not compile on anything earlier
|
|
than 2.0.37.</P>
|
|
<H3><A name="kernel.production">2.2 and 2.4 kernels</A></H3>
|
|
<DL>
|
|
<DT>FreeS/WAN 1.0</DT>
|
|
<DD>ran only on 2.0 kernels</DD>
|
|
<DT>FreeS/WAN 1.1 to 1.8</DT>
|
|
<DD>ran on 2.0 or 2.2 kernels
|
|
<BR> ran on some development kernels, 2.3 or 2.4-test</DD>
|
|
<DT>FreeS/WAN 1.9 to 1.96</DT>
|
|
<DD>runs on 2.0, 2.2 or 2.4 kernels</DD>
|
|
</DL>
|
|
<P>In general,<STRONG> we suggest the latest 2.2 kernel or 2.4 for
|
|
production use</STRONG>.</P>
|
|
<P>Of course no release can be guaranteed to run on kernels more recent
|
|
than it is, so quite often there will be no stable FreeS/WAN for the
|
|
absolute latest kernel. See the<A href="#k.versions"> FAQ</A> for
|
|
discussion.</P>
|
|
<H2><A name="otherdist">Intel Linux distributions other than Redhat</A></H2>
|
|
<P>We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat 7.1
|
|
or 7.2 for 2.4, so minor changes may be required for other
|
|
distributions.</P>
|
|
<H3><A name="rh7">Redhat 7.0</A></H3>
|
|
<P>There are some problems with FreeS/WAN on Redhat 7.0. They are
|
|
soluble, but we recommend you upgrade to a later Redhat instead..</P>
|
|
<P>Redhat 7 ships with two compilers.</P>
|
|
<UL>
|
|
<LI>Their<VAR> gcc</VAR> is version 2.96. Various people, including the
|
|
GNU compiler developers and Linus, have said fairly emphatically that
|
|
using this was a mistake. 2.96 is a development version, not intended
|
|
for production use. In particular, it will not compile a Linux kernel.</LI>
|
|
<LI>Redhat therefore also ship a separate compiler, which they call<VAR>
|
|
kgcc</VAR>, for compiling kernels.</LI>
|
|
</UL>
|
|
<P>Kernel Makefiles have<VAR> gcc</VAR> as a default, and must be
|
|
adjusted to use<VAR> kgcc</VAR> before a kernel will compile on 7.0.
|
|
This mailing list message gives details:</P>
|
|
<PRE>Subject: Re: AW: Installing IPsec on Redhat 7.0
|
|
Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST)
|
|
From: Mads Rasmussen <[email protected]>
|
|
|
|
> From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1
|
|
|
|
cd to /usr/src/linux and open the Makefile in your favorite editor. You
|
|
will need to look for a line similar to this:
|
|
|
|
CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
|
|
|
|
This line specifies which C compiler to use to build the kernel. It should
|
|
be changed to:
|
|
|
|
CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
|
|
|
|
for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can
|
|
proceed with the typical compiling steps.</PRE>
|
|
<P>Check the<A href="mail.html"> mailing list</A> archive for more
|
|
recent news.</P>
|
|
<H3><A name="suse">SuSE Linux</A></H3>
|
|
<P>SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN
|
|
included.</P>
|
|
<P>FreeS/WAN packages distributed for SuSE 7.0-7.2 were somehow
|
|
miscompiled. You can find fixed packages on<A HREF="http://www.suse.de/~garloff/linux/FreeSWAN">
|
|
Kurt Garloff's page</A>.</P>
|
|
<P>Here are some notes for an earlier SuSE version.</P>
|
|
<H4><A NAME="9_4_2_1">SuSE Linux 5.3</A></H4>
|
|
<PRE>Date: Mon, 30 Nov 1998
|
|
From: Peter Onion <[email protected]>
|
|
|
|
... I got Saturdays snapshot working between my two SUSE5.3 machines at home.
|
|
|
|
The mods to the install process are quite simple. From memory and looking at
|
|
the files on the SUSE53 machine here at work....
|
|
|
|
And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
|
|
which SUSE use to shut a service down.
|
|
|
|
A few mods in /etc/init.d/ipsec to cope with the different places that SUSE
|
|
put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
|
|
/etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.
|
|
|
|
insert ". /etc/rc.config" to pick up the SUSE config info and use
|
|
|
|
if test -n "$NETCONFIG" -a "$NETCONFIG" != "YAST_ASK" ; then
|
|
|
|
to replace
|
|
|
|
[ ${NETWORKING} = "no" ] && exit 0
|
|
|
|
Create /etc/sysconfig as SUSE doesn't have one.
|
|
|
|
I think that was all (but I prob forgot something)....</PRE>
|
|
<P>You may also need to fiddle initialisation scripts to ensure that<VAR>
|
|
/var/run/pluto.pid</VAR> is removed when rebooting. If this file is
|
|
present, Pluto does not come up correctly.</P>
|
|
<H3><A name="slack">Slackware</A></H3>
|
|
<PRE>Subject: Re: linux-IPsec: Slackware distribution
|
|
Date: Thu, 15 Apr 1999 12:07:01 -0700
|
|
From: Evan Brewer <[email protected]>
|
|
|
|
> Very shortly, I will be needing to install IPsec on at least gateways that
|
|
> are running Slackware. . . .
|
|
|
|
The only trick to getting it up is that on the slackware dist there is no
|
|
init.d directory in /etc/rc.d .. so create one. Then, what I do is take the
|
|
IPsec startup script which normally gets put into the init.d directory, and
|
|
put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
|
|
in init.d. The only file in the dist you need to really edit is the
|
|
utils/Makefile, setup4:
|
|
|
|
Everything else should be just fine.</PRE>
|
|
<P>A year or so later:</P>
|
|
<PRE>Subject: Re: HTML Docs- Need some cleanup?
|
|
Date: Mon, 8 Jan 2001
|
|
From: Jody McIntyre <[email protected]>
|
|
|
|
I have successfully installed FreeS/WAN on several Slackware 7.1 machines.
|
|
FreeS/WAN installed its rc.ipsec file in /etc/rc.d. I had to manually call
|
|
this script from rc.inet2. This seems to be an easier method than Evan
|
|
Brewer's.</PRE>
|
|
<H3><A name="deb">Debian</A></H3>
|
|
<P>A recent (Nov 2001) mailing list points to a<A href="http://www.thing.dyndns.org/debian/vpn.htm">
|
|
web page</A> on setting up several types of tunnel, including IPsec, on
|
|
Debian.</P>
|
|
<P>Some older information:</P>
|
|
<PRE>Subject: FreeS/WAN 1.0 on Debian 2.1
|
|
Date: Tue, 20 Apr 1999
|
|
From: Tim Miller <[email protected]>
|
|
|
|
Compiled and installed without error on a Debian 2.1 system
|
|
with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
|
|
/etc/init.d.
|
|
|
|
/var/lock/subsys/ doesn't exist on Debian boxen, needs to be
|
|
created; not a fatal error.
|
|
|
|
Finally, IPsec scripts appear to be dependant on GNU awk
|
|
(gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
|
|
With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
|
|
operation appears flawless.</PRE>
|
|
<P>The scripts in question have been modified since this was posted. Awk
|
|
versions should no longer be a problem.</P>
|
|
<H3><A name="caldera">Caldera</A></H3>
|
|
<PRE>Subject: Re: HTML Docs- Need some cleanup?
|
|
Date: Mon, 08 Jan 2001
|
|
From: Andy Bradford <[email protected]>
|
|
|
|
On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote:
|
|
|
|
> Intel Linux distributions other than Redhat 5.x and 6.x
|
|
> Redhat 7.0
|
|
> SuSE Linux
|
|
> SuSE Linux 5.3
|
|
> Slackware
|
|
> Debian
|
|
|
|
Can you please include Caldera in this list? I have tested it since
|
|
FreeS/Wan 1.1 and it works great with our systems---provided one
|
|
follows the FreeS/Wan documentation. :-)
|
|
|
|
Thank you,
|
|
Andy</PRE>
|
|
<H2><A name="CPUs">CPUs other than Intel</A></H2>
|
|
<P>FreeS/WAN has been run sucessfully on a number of different CPU
|
|
architectures. If you have tried it on one not listed here, please post
|
|
to the<A href="mail.html"> mailing list</A>.</P>
|
|
<H3><A name=" strongarm">Corel Netwinder (StrongARM CPU)</A></H3>
|
|
<PRE>Subject: linux-ipsec: Netwinder diffs
|
|
Date: Wed, 06 Jan 1999
|
|
From: [email protected]
|
|
|
|
I had a mistake in my IPsec-auto, so I got things working this morning.
|
|
|
|
Following are the diffs for my changes. Probably not the best and cleanest way
|
|
of doing it, but it works. . . . </PRE>
|
|
<P>These diffs are in the 0.92 and later distributions, so these should
|
|
work out-of-the-box on Netwinder.</P>
|
|
<H3><A name="yellowdog">Yellow Dog Linux on Power PC</A></H3>
|
|
<PRE>Subject: Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
|
|
Date: 11 Dec 1999
|
|
From: Darron Froese <[email protected]>
|
|
|
|
I'm summarizing here for the record - because it's taken me many hours to do
|
|
this (multiple times) and because I want to see IPsec on more linuxes than
|
|
just x86.
|
|
|
|
Also, I can't remember if I actually did summarize it before... ;-) I'm
|
|
working too many late hours.
|
|
|
|
That said - here goes.
|
|
|
|
1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
|
|
<http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2>
|
|
|
|
2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
|
|
<ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz>
|
|
|
|
3. Get the gmp src rpm from here:
|
|
<ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm>
|
|
|
|
4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
|
|
|
|
You will see a lot of text fly by and when you start to see the rpm
|
|
recompiling like this:
|
|
|
|
Executing: %build
|
|
+ umask 022
|
|
+ cd /usr/src/redhat/BUILD
|
|
+ cd gmp-2.0.2
|
|
+ libtoolize --copy --force
|
|
Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
|
|
You should add the contents of `/usr/share/aclocal/libtool.m4' to
|
|
`aclocal.m4'.
|
|
+ CFLAGS=-O2 -fsigned-char
|
|
+ ./configure --prefix=/usr
|
|
|
|
Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
|
|
reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
|
|
ydl.
|
|
|
|
cd /usr/src/redhat/BUILD/
|
|
cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
|
|
cd /usr/src/freeswan-1.1/
|
|
rm -rf gmp
|
|
mv gmp-2.0.2 gmp
|
|
|
|
5. Open the freeswan Makefile and change the line that says:
|
|
KERNEL=$(b)zimage (or something like that) to
|
|
KERNEL=vmlinux
|
|
|
|
6. cd ../linux/
|
|
|
|
7. make menuconfig
|
|
Select an option or two and then exit - saving your changes.
|
|
|
|
8. cd ../freeswan-1.1/ ; make menugo
|
|
|
|
That will start the whole process going - once that's finished compiling,
|
|
you have to install your new kernel and reboot.
|
|
|
|
That should build FreeS/WAN on ydl (I tried it on 1.1).</PRE>
|
|
And a later message on the same topic:
|
|
<PRE>Subject: Re: FreeS/WAN, PGPnet and E-mail
|
|
Date: Sat, 22 Jan 2000
|
|
From: Darron Froese <[email protected]>
|
|
|
|
on 1/22/00 6:47 PM, Philip Trauring at [email protected] wrote:
|
|
|
|
> I have a PowerMac G3 ...
|
|
|
|
The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
|
|
FreeS/WAN 1.2patch1 with a couple minor modifications:
|
|
|
|
1. In the Makefile it specifies a bzimage for the kernel compile - you have
|
|
to change that to vmlinux for the PPC.
|
|
|
|
2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
|
|
compile. I have gotten around this by getting the gmp src rpm from here:
|
|
|
|
ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
|
|
|
|
If you rip the source out of there - and place it where the gmp source
|
|
resides it will compile just fine.</PRE>
|
|
<P>FreeS/WAN no longer includes GMP source.</P>
|
|
<H3><A name="mklinux">Mklinux</A></H3>
|
|
<P>One user reports success on the Mach-based<STRONG> m</STRONG>icro<STRONG>
|
|
k</STRONG>ernel Linux.</P>
|
|
<PRE>Subject: Smiles on sparc and ppc
|
|
Date: Fri, 10 Mar 2000
|
|
From: Jake Hill <[email protected]>
|
|
|
|
You may or may not be interested to know that I have successfully built
|
|
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
|
|
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
|
|
works, mostly, with few changes.</PRE>
|
|
<H3><A name="alpha">Alpha 64-bit processors</A></H3>
|
|
<PRE>Subject: IT WORKS (again) between intel & alpha :-)))))
|
|
Date: Fri, 29 Jan 1999
|
|
From: Peter Onion <[email protected]>
|
|
|
|
Well I'm happy to report that I've got an IPsec connection between by intel & alpha machines again :-))
|
|
|
|
If you look back on this list to 7th of December I wrote...
|
|
|
|
-On 07-Dec-98 Peter Onion wrote:
|
|
->
|
|
-> I've about had enuf of wandering around inside the kernel trying to find out
|
|
-> just what is corrupting outgoing packets...
|
|
-
|
|
-Its 7:30 in the evening .....
|
|
-
|
|
-I FIXED IT :-))))))))))))))))))))))))))))))))
|
|
-
|
|
-It was my own fault :-((((((((((((((((((
|
|
-
|
|
-If you ask me very nicly I'll tell you where I was a little too over keen to
|
|
-change unsigned long int __u32 :-) OPSE ...
|
|
-
|
|
-So tomorrow it will full steam ahead to produce a set of diffs/patches against
|
|
-0.91
|
|
-
|
|
-Peter Onion.</PRE>
|
|
<P>In general (there have been some glitches), FreeS/WAN has been
|
|
running on Alphas since then.</P>
|
|
<H3><A name="SPARC">Sun SPARC processors</A></H3>
|
|
<P>Several users have reported success with FreeS/WAN on SPARC Linux.
|
|
Here is one mailing list message:</P>
|
|
<PRE>Subject: Smiles on sparc and ppc
|
|
Date: Fri, 10 Mar 2000
|
|
From: Jake Hill <[email protected]>
|
|
|
|
You may or may not be interested to know that I have successfully built
|
|
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
|
|
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
|
|
works, mostly, with few changes.
|
|
|
|
I have a question, before I make up some patches. I need to hack
|
|
gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
|
|
trivial, but could I also use a different version of gmp? Is it vanilla
|
|
here?
|
|
|
|
I guess my only real headache is from ipchains, which appears to stop
|
|
running when IPsec has been started for a while. This is with 2.2.14 on
|
|
sparc.</PRE>
|
|
<P>This message, from a different mailing list, may be relevant for
|
|
anyone working with FreeS/WAN on Suns:</P>
|
|
<PRE>Subject: UltraSPARC DES assembler
|
|
Date: Thu, 13 Apr 2000
|
|
From: [email protected] (Svend Olaf Mikkelsen)
|
|
To: [email protected]
|
|
|
|
An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
|
|
file is available at http://inet.uni2.dk/~svolaf/des.htm.
|
|
|
|
This brings DES on UltraSPARC from slower than Pentium at the same
|
|
clock speed to significantly faster.</PRE>
|
|
<H3><A name="mips">MIPS processors</A></H3>
|
|
<P>We know FreeS/WAN runs on at least some MIPS processors because<A href="http://www.lasat.com">
|
|
Lasat</A> manufacture an IPsec box based on an embedded MIPS running
|
|
Linux with FreeS/WAN. We have no details.</P>
|
|
<H3><A name="crusoe">Transmeta Crusoe</A></H3>
|
|
<P>The Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
|
|
Firecard</A>, a Linux firewall on a PCI card, is based on a Crusoe
|
|
processor and supports FreeS/WAN.</P>
|
|
<H3><A name="coldfire">Motorola Coldfire</A></H3>
|
|
<PRE>Subject: Re: Crypto hardware support
|
|
Date: Mon, 03 Jul 2000
|
|
From: Dan DeVault <[email protected]>
|
|
|
|
.... I have been running
|
|
uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay (
|
|
http://www.moretonbay.com ) and it was using a Coldfire processor
|
|
and was able to do the Triple DES encryption at just about
|
|
1 mbit / sec rate....... they put a Hi/Fn 7901 hardware encryption
|
|
chip on their board and now their system does over 25 mbit of 3DES
|
|
encryption........ pretty significant increase if you ask me.</PRE>
|
|
<H2><A name="multiprocessor">Multiprocessor machines</A></H2>
|
|
<P>FreeS/WAN is designed to work on SMP (symmetric multi-processing)
|
|
Linux machines and is regularly tested on dual processor x86 machines.</P>
|
|
<P>We do not know of any testing on multi-processor machines with other
|
|
CPU architectures or with more than two CPUs. Anyone who does test
|
|
this, please report results to the<A href="mail.html"> mailing list</A>
|
|
.</P>
|
|
<P>The current design does not make particularly efficient use of
|
|
multiprocessor machines; some of the kernel work is single-threaded.</P>
|
|
<H2><A name="hardware">Support for crypto hardware</A></H2>
|
|
<P>Supporting hardware cryptography accelerators has not been a high
|
|
priority for the development team because it raises a number of fairly
|
|
complex issues:</P>
|
|
<UL>
|
|
<LI>Can you trust the hardware? If it is not Open Source, how do you
|
|
audit its security? Even if it is, how do you check that the design has
|
|
no concealed traps?</LI>
|
|
<LI>If an interface is added for such hardware, can that interface be
|
|
subverted or misused?</LI>
|
|
<LI>Is hardware acceleration actually a performance win? It clearly is
|
|
in many cases, but on a fast machine it might be better to use the CPU
|
|
for the encryption than to pay the overheads of moving data to and from
|
|
a crypto board.</LI>
|
|
<LI>the current KLIPS code does not provide a clean interface for
|
|
hardware accelerators</LI>
|
|
</UL>
|
|
<P>That said, we have a<A href="#coldfire"> report</A> of FreeS/WAN
|
|
working with one crypto accelerator and some work is going on to modify
|
|
KLIPS to create a clean generic interface to such products. See this<A href="http://www.jukie.net/~bart/linux-ipsec/">
|
|
web page</A> for some of the design discussion.</P>
|
|
<P>More recently, a patch to support some hardware accelerators has been
|
|
posted:</P>
|
|
<PRE>Subject: [Design] [PATCH] H/W acceleration patch
|
|
Date: Tue, 18 Sep 2001
|
|
From: "Martin Gadbois" <[email protected]>
|
|
|
|
Finally!!
|
|
Here's a web site with H/W acceleration patch for FreeS/WAN 1.91, including
|
|
S/W and Hifn 7901 crypto support.
|
|
|
|
http://sources.colubris.com/
|
|
|
|
Martin Gadbois</PRE>
|
|
<P>Hardware accelerators could take performance well beyond what
|
|
FreeS/WAN can do in software (discussed<A href="performance.html"> here</A>
|
|
). Here is some discussion off the IETF IPsec list, October 2001:</P>
|
|
<PRE> ... Currently shipping chips deliver, 600 mbps throughput on a single
|
|
stream of 3DES IPsec traffic. There are also chips that use multiple
|
|
cores to do 2.4 gbps. We (Cavium) and others have announced even faster
|
|
chips. ... Mid 2002 versions will handle at line rate (OC48 and OC192)
|
|
IPsec and SSL/TLS traffic not only 3DES CBC but also AES and arc4.</PRE>
|
|
<P>The patches to date support chips that have been in production for
|
|
some time, not the state-of-the-art latest-and-greatest devices
|
|
described in that post. However, they may still outperform software and
|
|
they almost certainly reduce CPU overhead.</P>
|
|
<H2><A name="ipv6">IP version 6 (IPng)</A></H2>
|
|
<P>The Internet currently runs on version four of the IP protocols. IPv4
|
|
is what is in the standard Linux IP stack, and what FreeS/WAN was built
|
|
for. In IPv4, IPsec is an optional feature.</P>
|
|
<P>The next version of the IP protocol suite is version six, usually
|
|
abbreviated either as "IPv6" or as "IPng" for "IP: the next
|
|
generation". For IPv6, IPsec is a required feature. Any machine doing
|
|
IPv6 is required to support IPsec, much as any machine doing (any
|
|
version of) IP is required to support ICMP.</P>
|
|
<P>There is a Linux implementation of IPv6 in Linux kernels 2.2 and
|
|
above. For details, see the<A href="http://www.cs-ipv6.lancs.ac.uk/ipv6/systems/linux/faq/">
|
|
FAQ</A>. It does not yet support IPsec. The<A href="http://www.linux-ipv6.org/">
|
|
USAGI</A> project are also working on IPv6 for Linux.</P>
|
|
<P>FreeS/WAN was originally built for the current standard, IPv4, but we
|
|
are interested in seeing it work with IPv6. Some progress has been
|
|
made, and a patched version with IPv6 support is<A href="http://www.ipv6.iabg.de/downloadframe/index.html">
|
|
available</A>. For more recent information, check the<A href="mail.html">
|
|
mailing list</A>.</P>
|
|
<H3><A name="v6.back">IPv6 background</A></H3>
|
|
<P>IPv6 has been specified by an IETF<A href="http://www.ietf.org/html.charters/ipngwg-charter.html">
|
|
working group</A>. The group's page lists over 30 RFCs to date, and
|
|
many Internet Drafts as well. The overview is<A href="http://www.ietf.org/rfc/rfc2460.txt">
|
|
RFC 2460</A>. Major features include:</P>
|
|
<UL>
|
|
<LI>expansion of the address space from 32 to 128 bits,</LI>
|
|
<LI>changes to improve support for
|
|
<UL>
|
|
<LI>mobile IP</LI>
|
|
<LI>automatic network configuration</LI>
|
|
<LI>quality of service routing</LI>
|
|
<LI>...</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>improved security via IPsec</LI>
|
|
</UL>
|
|
<P>A number of projects are working on IPv6 implementation. A prominent
|
|
Open Source effort is<A href="http://www.kame.net/"> KAME</A>, a
|
|
collaboration among several large Japanese companies to implement IPv6
|
|
for Berkeley Unix. Other major players are also working on IPv6. For
|
|
example, see pages at:</P>
|
|
<UL>
|
|
<LI><A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">Sun</A>
|
|
</LI>
|
|
<LI><A href="http://www.cisco.com/warp/public/732/ipv6/index.html">Cisco</A>
|
|
</LI>
|
|
<LI><A href="http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/IPv6.asp">
|
|
Microsoft</A></LI>
|
|
</UL>
|
|
<P>The<A href="http://www.6bone.net/"> 6bone</A> (IPv6 backbone) testbed
|
|
network has been up for some time. There is an active<A href="http://www.ipv6.org/">
|
|
IPv6 user group</A>.</P>
|
|
<P>One of the design goals for IPv6 was that it must be possible to
|
|
convert from v4 to v6 via a gradual transition process. Imagine the
|
|
mess if there were a "flag day" after which the entire Internet used
|
|
v6, and all software designed for v4 stopped working. Almost every
|
|
computer on the planet would need major software changes! There would
|
|
be huge costs to replace older equipment. Implementers would be worked
|
|
to death before "the day", systems administrators and technical support
|
|
would be completely swamped after it. The bugs in every implementation
|
|
would all bite simultaneously. Large chunks of the net would almost
|
|
certainly be down for substantial time periods. ...</P>
|
|
<P>Fortunately, the design avoids any "flag day". It is therefore a
|
|
little tricky to tell how quickly IPv6 will take over. The transition
|
|
has certainly begun. For examples, see announcements from<A href="http://www.mailbase.ac.uk/lists/internet2/2000-03/0016.html">
|
|
NTT</A> and<A href="http://www.vnunet.com/News/1102383"> Nokia</A>.
|
|
However, it is not yet clear how quickly the process will gain
|
|
momentum, or when it will be completed. Likely large parts of the
|
|
Internet will remain with IPv4 for years to come.</P>
|
|
<HR>
|
|
<A NAME="interop"></A>
|
|
<H1><A NAME="10">Interoperating with FreeS/WAN</A></H1>
|
|
<P>The FreeS/WAN project needs you! We rely on the user community to
|
|
keep up to date. Mail [email protected] with your interop
|
|
success stories.</P>
|
|
<P><STRONG>Please note</STRONG>: Most of our interop examples feature
|
|
Linux FreeS/WAN 1.x config files. You can convert them to 2.x files
|
|
fairly easily with the patch in our<A HREF="#ipsec.conf_v2"> Upgrading
|
|
Guide</A>.</P>
|
|
<H2><A NAME="10_1">Interop at a Glance</A></H2>
|
|
<TABLE BORDER="1">
|
|
<TR><TD> </TD><TD colspan="5">FreeS/WAN VPN</TD><TD>Road Warrior</TD><TD>
|
|
OE</TD></TR>
|
|
<TR><TD> </TD><TD>PSK</TD><TD>RSA Secret</TD><TD>X.509
|
|
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
|
|
NAT-Traversal
|
|
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
|
|
Manual
|
|
<BR>Keying</TD><TD> </TD><TD> </TD></TR>
|
|
<TR><TD colspan="8">More Compatible</TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#freeswan">FreeS/WAN</A><A NAME="freeswan.top"> </A></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#isakmpd">isakmpd (OpenBSD)</A><A NAME="isakmpd.top"> </A>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD>
|
|
<FONT color="#cc0000">No </FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#kame">Kame (FreeBSD,
|
|
<BR> NetBSD, MacOSX)
|
|
<BR> <SMALL>aka racoon</SMALL></A><A NAME="kame.top"> </A></TD><TD><FONT
|
|
color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#mcafee">McAfee VPN
|
|
<BR><SMALL>was PGPNet</SMALL></A><A NAME="mcafee.top"> </A></TD><TD><FONT
|
|
color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#microsoft">Microsoft
|
|
<BR> Windows 2000/XP</A><A NAME="microsoft.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">
|
|
No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#ssh">SSH Sentinel</A><A NAME="ssh.top"> </A></TD><TD><FONT
|
|
color="#00cc00">Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT>
|
|
</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#safenet">Safenet SoftPK
|
|
<BR>/SoftRemote</A><A NAME="safenet.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">
|
|
No</FONT></TD></TR>
|
|
<TR><TD colspan="8">Other</TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#6wind">6Wind</A><A NAME="6wind.top"> </A></TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
<FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#alcatel">Alcatel Timestep</A><A NAME="alcatel.top"> </A>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD> </TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#apple">Apple Macintosh
|
|
<BR>System 10+</A><A NAME="apple.top"> </A></TD><TD><FONT color="#cccc00">
|
|
Maybe</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cccc00">
|
|
Maybe</FONT></TD><TD> </TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#ashleylaurent">AshleyLaurent
|
|
<BR> VPCom</A><A NAME="ashleylaurent.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT
|
|
color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#borderware">Borderware</A><A NAME="borderware.top"> </A>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD><TD><FONT color="#cc0000">
|
|
No</FONT></TD></TR>
|
|
|
|
<!--
|
|
http://www.cequrux.com/vpn-guides.php3
|
|
"coming soon" guide to connect with FreeS/WAN.
|
|
-->
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#checkpoint">Check Point FW-1/VPN-1</A><A NAME="checkpoint.top">
|
|
</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
|
|
<FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#cisco">Cisco with 3DES</A><A NAME="cisco.top"> </A></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT>
|
|
</TD><TD> </TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#equinux">Equinux VPN Tracker
|
|
<BR> (for Mac OS X)</A><A NAME="equinux.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#fsecure">F-Secure</A><A NAME="fsecure.top"> </A></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD><FONT color="#cccc00">
|
|
Maybe</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#gauntlet">Gauntlet GVPN</A><A NAME="gauntlet.top"> </A>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT color="#cc0000">
|
|
No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#aix">IBM AIX</A><A NAME="aix.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
|
|
</TD><TD> </TD><TD> </TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#as400">IBM AS/400</A><A NAME="as400"> </A></TD><TD><FONT
|
|
color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#intel">Intel Shiva
|
|
<BR>LANRover/Net Structure</A><A NAME="intel.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT
|
|
color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#lancom">LanCom (formerly ELSA)</A><A NAME="lancom.top">
|
|
</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD> </TD><TD> </TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#linksys">Linksys</A><A NAME="linksys.top"> </A></TD><TD>
|
|
<FONT color="#cccc00">Maybe</FONT></TD><TD> </TD><TD><FONT color="#cc0000">
|
|
No</FONT></TD><TD> </TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
|
|
<FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#lucent">Lucent</A><A NAME="lucent.top"> </A></TD><TD><FONT
|
|
color="#cccc00">Partial</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#netasq">Netasq</A><A NAME="netasq.top"> </A></TD><TD>
|
|
</TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#netcelo">netcelo</A><A NAME="netcelo.top"> </A></TD><TD>
|
|
</TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#netgear">Netgear fvs318</A><A NAME="netgear.top"> </A>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD> </TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#netscreen">Netscreen 100
|
|
<BR>or 5xp</A><A NAME="netscreen.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT color="#cccc00">
|
|
Maybe</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#nortel">Nortel Contivity</A><A NAME="nortel.top"> </A>
|
|
</TD><TD><FONT color="#cccc00">Partial</FONT></TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#radguard">RadGuard</A><A NAME="radguard.top"> </A></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#raptor">Raptor</A><A NAME="raptor"> </A></TD><TD><FONT
|
|
color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#redcreek">Redcreek Ravlin</A><A NAME="redcreek.top"> </A>
|
|
</TD><TD><FONT color="#00cc00">Yes</FONT><FONT color="#cccc00">/Partial</FONT>
|
|
</TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT color="#cc0000">
|
|
No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#sonicwall">SonicWall</A><A NAME="sonicwall.top"> </A></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT
|
|
color="#cccc00">Maybe</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD><TD>
|
|
<FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#sun">Sun Solaris</A><A NAME="sun.top"> </A></TD><TD><FONT
|
|
color="#00cc00">Yes</FONT></TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT>
|
|
</TD><TD> </TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD><FONT
|
|
color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#symantec">Symantec</A><A NAME="symantec.top"> </A></TD><TD>
|
|
<FONT color="#00cc00">Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD>
|
|
</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#watchguard">Watchguard
|
|
<BR> Firebox</A><A NAME="watchguard.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#xedia">Xedia Access Point
|
|
<BR>/QVPN</A><A NAME="xedia.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT
|
|
color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
<TR><TD><A HREF="#zyxel">Zyxel Zywall
|
|
<BR>/Prestige</A><A NAME="zyxel.top"> </A></TD><TD><FONT color="#00cc00">
|
|
Yes</FONT></TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD> </TD><TD><FONT
|
|
color="#cc0000">No</FONT></TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE
|
|
|
|
|
|
<TR>
|
|
<TD><A HREF="#sample">sample</A></TD>
|
|
<TD> </TD>
|
|
<TD> </TD>
|
|
<TD> </TD>
|
|
<TD> </TD>
|
|
<TD> </TD>
|
|
<TD> </TD>
|
|
<TD><FONT color="#cc0000">No</FONT></TD>
|
|
</TR>
|
|
|
|
-->
|
|
<TR><TD> </TD><TD>PSK</TD><TD>RSA Secret</TD><TD>X.509
|
|
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
|
|
NAT-Traversal
|
|
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
|
|
Manual
|
|
<BR>Keying</TD><TD> </TD><TD> </TD></TR>
|
|
<TR><TD> </TD><TD colspan="5">FreeS/WAN VPN</TD><TD>Road Warrior</TD><TD>
|
|
OE</TD></TR>
|
|
|
|
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
|
|
</TABLE>
|
|
<H3><A NAME="10_1_1">Key</A></H3>
|
|
<TABLE BORDER="1">
|
|
<TR><TD><FONT color="#00cc00">Yes</FONT></TD><TD>People report that this
|
|
works for them.</TD></TR>
|
|
<TR><TD>[Blank]</TD><TD>We don't know.</TD></TR>
|
|
<TR><TD><FONT color="#cc0000">No</FONT></TD><TD>We have reason to
|
|
believe it was, at some point, not possible to get this to work.</TD></TR>
|
|
<TR><TD><FONT color="#cccc00">Partial</FONT></TD><TD>Partial success.
|
|
For example, a connection can be created from one end only.</TD></TR>
|
|
<TR><TD><FONT color="#00cc00">Yes</FONT><FONT color="#cccc00">/Partial</FONT>
|
|
</TD><TD>Mixed reports.</TD></TR>
|
|
<TR><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>We think the answer
|
|
is "yes", but need confirmation.</TD></TR>
|
|
</TABLE>
|
|
<A NAME="interoprules"></A>
|
|
<H2><A NAME="10_2">Basic Interop Rules</A></H2>
|
|
<P>Vanilla FreeS/WAN implements<A HREF="#compat"> these parts</A> of the
|
|
IPSec specifications. You can add more with<A HREF="http://www.freeswan.ca">
|
|
Super FreeS/WAN</A>, but what we offer may be enough for many users.</P>
|
|
<UL>
|
|
<LI> To use X.509 certificates with FreeS/WAN, you will need the<A HREF="http://www.strongsec.org/freeswan">
|
|
X.509 patch</A> or<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>
|
|
, which includes that patch.</LI>
|
|
<LI> To use<A HREF="#NAT.gloss"> Network Address Translation</A> (NAT)
|
|
traversal with FreeS/WAN, you will need Arkoon Network Security's<A HREF="http://open-source.arkoon.net">
|
|
NAT traversal patch</A> or<A HREF="http://www.freeswan.ca"> Super
|
|
FreeS/WAN</A>, which includes it.</LI>
|
|
</UL>
|
|
<P>We offer a set of proposals which is not user-adjustable, but covers
|
|
all combinations that we can offer. FreeS/WAN always proposes triple
|
|
DES encryption and Perfect Forward Secrecy (PFS). In addition, we
|
|
propose Diffie Hellman groups 5 and 2 (in that order), and MD5 and
|
|
SHA-1 hashes. We accept the same proposals, in the same order of
|
|
preference.</P>
|
|
<P>Other interop notes:</P>
|
|
<UL>
|
|
<LI> A<A HREF="http://lists.freeswan.org/archives/users/2003-September/msg00462.html">
|
|
SHA-1 bug in FreeS/WAN 2.00, 2.01 and 2.02</A> may affect some interop
|
|
scenarios. It does not affect 1.x versions, and is fixed in 2.03 and
|
|
later.</LI>
|
|
<LI> Some other implementations will close a connection with FreeS/WAN
|
|
after some time. This may be a problem with rekey lifetimes. Please see<A
|
|
HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
|
|
this tip</A> and<A HREF="http://lists.freeswan.org/pipermail/users/2001-December/005758.html">
|
|
this workaround</A>.</LI>
|
|
</UL>
|
|
<H2><A NAME="10_3">Longer Stories</A></H2>
|
|
<H3><A NAME="10_3_1">For<EM> More Compatible</EM> Implementations</A></H3>
|
|
<H4><A NAME="freeswan">FreeS/WAN</A></H4>
|
|
<P> See our documentation at<A HREF="http://www.freeswan.org">
|
|
freeswan.org</A> and the Super FreeS/WAN docs at<A HREF="http://www.freeswan.ca">
|
|
freeswan.ca</A>. Some user-written HOWTOs for FreeS/WAN-FreeS/WAN
|
|
connections are listed in<A HREF="#howto"> our Introduction</A>.</P>
|
|
<P>See also:</P>
|
|
<UL>
|
|
<LI><A HREF="http://lugbe.ch/action/reports/ipsec_htbe.phtml"> A German
|
|
FreeS/WAN-FreeS/WAN page by Markus Wernig (X.509)</A></LI>
|
|
</UL>
|
|
<P><A HREF="#freeswan.top">Back to chart</A></P>
|
|
<H4><A NAME="isakmpd">isakmpd (OpenBSD)</A></H4>
|
|
<P><A HREF="http://www.openbsd.org/faq/faq13.html">OpenBSD FAQ: Using
|
|
IPsec</A>
|
|
<BR><A HREF="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html">
|
|
Hans-Joerg Hoexer's interop Linux-OpenBSD (PSK)</A>
|
|
<BR><A HREF="http://www.segfault.net/ipsec/"> Skyper's configuration
|
|
(PSK)</A>
|
|
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
|
|
French page with configs (X.509)</A></P>
|
|
<P><A HREF="#isakmpd.top">Back to chart</A></P>
|
|
<H4><A NAME="kame">Kame</A></H4>
|
|
<UL>
|
|
<LI>For FreeBSD and NetBSD. Ships with Mac OS X; see also our<A HREF="#apple">
|
|
Mac</A> section.</LI>
|
|
<LI>Also known as<EM> racoon</EM>, its keying daemon.</LI>
|
|
</UL>
|
|
<P><A HREF="http://www.kame.net">Kame homepage, with FAQ</A>
|
|
<BR><A HREF="http://www.netbsd.org/Documentation/network/ipsec">
|
|
NetBSD's IPSec FAQ</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00560.html">
|
|
Ghislaine's post explaining some interop peculiarities</A></P>
|
|
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/09/msg00511.html">
|
|
Itojun's Kame-FreeS/WAN interop tips (PSK)</A>
|
|
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2000"> Ghislaine
|
|
Labouret's French page with links to matching FreeS/WAN and Kame
|
|
configs (RSA)</A>
|
|
<BR><A HREF="http://lugbe.ch/lostfound/contrib/freebsd_router/"> Markus
|
|
Wernig's HOWTO (X.509, BSD gateway)</A>
|
|
<BR><A HREF="http://web.morgul.net/~frodo/docs/kame+freeswan_interop.html">
|
|
Frodo's Kame-FreeS/WAN interop (X.509)</A>
|
|
<BR><A HREF="http://www.wavesec.org/kame.phtml"> Kame as a WAVEsec
|
|
client.</A></P>
|
|
<P><A HREF="#kame.top">Back to chart</A></P>
|
|
<H4><A NAME="mcafee">PGPNet/McAfee</A></H4>
|
|
<P></P>
|
|
<UL>
|
|
<LI>Now called McAfee VPN Client.</LI>
|
|
<LI>PGPNet also came in a freeware version which did not support subnets</LI>
|
|
<LI>To support dhcp-over-ipsec, you need the X.509 patch, which is
|
|
included in<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>.</LI>
|
|
</UL>
|
|
<P><A HREF="http://www.freeswan.ca/docs/WindowsInterop"> Tim Carr's
|
|
Windows Interop Guide (X.509)</A>
|
|
<BR><A HREF="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html#Interop2">
|
|
Hans-Joerg Hoexer's Guide for Linux-PGPNet (PSK)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00339.html">
|
|
Kai Martius' instructions using RSA Key-Extractor Tool (RSA)</A>
|
|
<BR> <A HREF="http://www.zengl.net/freeswan/english.html">Christian
|
|
Zeng's page (RSA)</A> based on Kai's work. English or German.
|
|
<BR><A HREF="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">
|
|
Oscar Delgado's PDF (X.509, no configs)</A>
|
|
<BR><A HREF="http://www-ec.njit.edu/~rxt1077/Howto.txt"> Ryan's HOWTO
|
|
for FreeS/WAN-PGPNet (X.509)</A>. Through a Linksys Router with IPsec
|
|
Passthru enabled.
|
|
<BR><A HREF="http://jixen.tripod.com/#RW-PGP-to-Fwan"> Jean-Francois
|
|
Nadeau's Practical Configuration (Road Warrior with PSK)</A>
|
|
<BR><A HREF="http://www.evolvedatacom.nl/freeswan.html#toc"> Wouter
|
|
Prins' HOWTO (Road Warrior with X.509)</A>
|
|
<BR></P>
|
|
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/01/msg00271.html">
|
|
Rekeying problem with FreeS/WAN and older PGPNets</A>
|
|
<BR></P>
|
|
<P><A HREF="http://www.strongsec.com/freeswan/dhcprelay/index.htm"> DHCP
|
|
over IPSEC HOWTO for FreeS/WAN (requires X.509 and dhcprelay patches)</A>
|
|
</P>
|
|
<P><A HREF="#mcafee.top">Back to chart</A></P>
|
|
<H4><A NAME="microsoft">Microsoft Windows 2000/XP</A></H4>
|
|
<UL>
|
|
<LI>IPsec comes with Win2k, and with XP Support Tools. May require<A HREF="http://www.microsoft.com/windows2000/downloads/recommended/encryption/default.asp">
|
|
High Encryption Pack</A>. WinXP users have also reported better results
|
|
with Service Pack 1.</LI>
|
|
<LI>The Road Warrior setup works either way round. Windows (XP or 2K)
|
|
IPsec can connect as a Road Warrior to FreeS/WAN. However, FreeS/WAN
|
|
can also successfully connect as a Road Warrior to Windows IPsec (see
|
|
Nate Carlson's configs below).</LI>
|
|
<LI>FreeS/WAN version 1.92 or later is required to avoid an
|
|
interoperation problem with Windows native IPsec. Earlier FreeS/WAN
|
|
versions did not process the Commit Bit as Windows native IPsec
|
|
expected.</LI>
|
|
</UL>
|
|
<P><A HREF="http://www.freeswan.ca/docs/WindowsInterop"> Tim Carr's
|
|
Windows Interop Guide (X.509)</A>
|
|
<BR><A HREF="http://ipsec.math.ucla.edu/services/ipsec.html"> James
|
|
Carter's instructions (X.509, NAT-T)</A>
|
|
<BR><A HREF="http://jixen.tripod.com/#Win2000-Fwan"> Jean-Francois
|
|
Nadeau's Net-net Configuration (PSK)</A>
|
|
<BR><A HREF="http://security.nta.no/freeswan-w2k.html"> Telenor's
|
|
Node-node Config (Transport-mode PSK)</A>
|
|
<BR><A HREF="http://vpn.ebootis.de"> Marcus Mueller's HOWTO using his
|
|
VPN config tool (X.509).</A> Tool also works with PSK.
|
|
<BR><A HREF="http://www.natecarlson.com/include/showpage.php?cat=linux&page=ipsec-x509">
|
|
Nate Carlson's HOWTO using same tool (Road Warrior with X.509)</A>.
|
|
Unusually, FreeS/WAN is the Road Warrior here.
|
|
<BR><A HREF="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">
|
|
Oscar Delgado's PDF (X.509, no configs)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022425.html">
|
|
Tim Scannell's Windows XP Additional Checklist (X.509)</A>
|
|
<BR></P>
|
|
|
|
<!-- Note to self: Include L2TP references? -->
|
|
<P><A HREF="http://www.microsoft.com/windows2000/en/server/help/default.asp?url=/windows2000/en/server/help/sag_TCPIP_ovr_secfeatures.htm">
|
|
Microsoft's page on Win2k TCP/IP security features</A>
|
|
<BR><A HREF="http://support.microsoft.com/support/kb/articles/Q257/2/25.ASP">
|
|
Microsoft's Win2k IPsec debugging tips</A>
|
|
<BR>
|
|
<!-- Alt-URL http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257225
|
|
Perhaps newer? -->
|
|
<A HREF="http://www.wired.com/news/technology/0,1282,36336,00.html">
|
|
MS VPN may fall back to 1DES</A></P>
|
|
<P><A HREF="#microsoft.top">Back to chart</A></P>
|
|
<H4><A NAME="ssh">SSH Sentinel</A></H4>
|
|
<UL>
|
|
<LI>Popular and well tested.</LI>
|
|
<LI>Also rebranded in<A HREF="http://www.zyxel.com"> Zyxel Zywall</A>.
|
|
Our Zyxel interop notes are<A HREF="#zyxel"> here</A>.</LI>
|
|
<LI> SSH supports IPsec-over-UDP NAT traversal.</LI>
|
|
<LI>There is this<A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/12/msg00370.html">
|
|
potential problem</A> if you're not using the Legacy Proposal option.</LI>
|
|
</UL>
|
|
<P><A HREF="http://www.ssh.com/support/sentinel/documents.cfm"> SSH's
|
|
Sentinel-FreeSWAN interop PDF (X.509)</A>
|
|
<BR><A HREF="http://www.nadmm.com/show.php?story=articles/vpn.inc">
|
|
Nadeem Hassan's SUSE-to-Sentinel article (Road warrior with X.509)</A>
|
|
<BR><A HREF="http://www.zerozone.it/documents/Linux/HowTo/VPN-IPsec-Freeswan-HOWTO.html">
|
|
O-Zone's Italian HOWTO (Road Warrior, X.509, DHCP)</A>
|
|
<BR></P>
|
|
<P><A HREF="#ssh.top">Back to chart</A></P>
|
|
<H4><A NAME="safenet">Safenet SoftPK/SoftRemote</A></H4>
|
|
<UL>
|
|
<LI>People recommend SafeNet as a low cost Windows client.</LI>
|
|
<LI>SoftRemote seems to be the newer name for SoftPK.</LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005061.html">
|
|
Whit Blauvelt's SoftRemote tips</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015591.html">
|
|
Tim Wilson's tips (X.509)</A><A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00607.html">
|
|
Workaround for a "gotcha"</A></P>
|
|
<P><A HREF="http://jixen.tripod.com/#Rw-IRE-to-Fwan"> Jean-Francois
|
|
Nadeau's Practical Configuration (Road Warrior with PSK)</A>
|
|
<BR><A HREF="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">
|
|
Terradon Communications' PDF (Road Warrior with PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/?????.html">
|
|
Seaan.net's PDF (Road Warrior to Subnet, with PSK)</A>
|
|
<BR><A HREF="http://www.redbaronconsulting.com/freeswan/fswansafenet.pdf">
|
|
Red Baron Consulting's PDF (Road Warrior with X.509)</A></P>
|
|
<P><A HREF="#safenet.top">Back to chart</A></P>
|
|
<H3><A NAME="10_3_2">For<EM> Other Implementations</EM></A></H3>
|
|
<H4><A NAME="6wind">6Wind</A></H4>
|
|
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
|
|
French page with configs (X.509)</A></P>
|
|
<P><A HREF="#6wind.top">Back to chart</A></P>
|
|
<H4><A NAME="alcatel">Alcatel Timestep</A></H4>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011878.html">
|
|
Alain Sabban's settings (PSK or PSK road warrior; through static NAT)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00100.html">
|
|
Derick Cassidy's configs (PSK)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/08/msg00194.html">
|
|
David Kerry's Timestep settings (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013711.html">
|
|
Kevin Gerbracht's ipsec.conf (X.509)</A></P>
|
|
<P><A HREF="#alcatel.top">Back to chart</A></P>
|
|
<H4><A NAME="apple">Apple Macintosh System 10+</A></H4>
|
|
<UL>
|
|
<LI>Since the system is based on FreeBSD, this should interoperate<A HREF="#kame">
|
|
just like FreeBSD</A>.</LI>
|
|
<LI> To use Appletalk over IPsec tunnels,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005116.html">
|
|
run it over TCP/IP</A>, or use Open Door Networks' Shareway IP tool,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005426.html">
|
|
described here.</A></LI>
|
|
<LI>See also the<A HREF="#equinux"> Equinux VPN Tracker</A> for Mac OS
|
|
X.</LI>
|
|
</UL>
|
|
<P><A HREF="http://ipsec.math.ucla.edu/services/ipsec.html"> James
|
|
Carter's instructions (X.509, NAT-T)</A></P>
|
|
<P><A HREF="#apple.top">Back to chart</A></P>
|
|
<H4><A NAME="ashleylaurent">AshleyLaurent VPCom</A></H4>
|
|
<P><A HREF="http://www.ashleylaurent.com/newsletter/01-28-00.htm">
|
|
Successful interop report, no details</A></P>
|
|
<P><A HREF="#ashleylaurent.top">Back to chart</A></P>
|
|
<H4><A NAME="borderware">Borderware</A></H4>
|
|
<UL>
|
|
<LI>I suspect the Borderware client is a rebranded Safenet. If that's
|
|
true, our<A HREF="#safenet"> Safenet section</A> will help.</LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-March/008288.html">
|
|
Philip Reetz' configs (PSK)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/09/msg00217.html">
|
|
Borderware server does not support FreeS/WAN road warriors</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007733.html">
|
|
Older Borderware may not support Diffie Hellman groups 2, 5</A>
|
|
<BR></P>
|
|
<P><A HREF="#borderware.top">Back to chart</A></P>
|
|
<H4><A NAME="checkpoint">Check Point VPN-1 or FW-1</A></H4>
|
|
<UL>
|
|
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00099.html">
|
|
Caveat about IP-range inclusion on Check Point.</A></LI>
|
|
<LI> Some versions of Check Point may require an aggressive mode patch
|
|
to interoperate with FreeS/WAN.
|
|
<BR><A HREF="http://www.freeswan.ca/code/super-freeswan"> Super
|
|
FreeS/WAN</A> now features this patch.
|
|
<!--
|
|
<A HREF="http://www.freeswan.ca/patches/aggressivemode">Steve Harvey's
|
|
aggressive mode patch for FreeS/WAN 1.5</A>
|
|
-->
|
|
</LI>
|
|
<LI></LI>
|
|
<LI>A Linux FreeS/WAN-Checkpoint connection may close after some time.
|
|
Try<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
|
|
this tip</A> toward a workaround.</LI>
|
|
</UL>
|
|
<P><A HREF="http://www.fw-1.de/aerasec/ng/vpn-freeswan/CPNG+Linux-FreeSWAN.html">
|
|
AERAsec's Firewall-1 NG site (PSK, X.509, Road Warrior with X.509,
|
|
other algorithms)</A>
|
|
<BR> <A HREF="http://www.fw-1.de/aerasec/ng/vpn-freeswan/CPNG+Linux-FreeSWAN.html#support-matrix">
|
|
AERAsec's detailed Check Point-FreeS/WAN support matrix</A>
|
|
<BR><A HREF="http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/fw-linuxvpn.pdf">
|
|
Checkpoint.com PDF: Linux as a VPN Client to FW-1 (PSK)</A>
|
|
<BR><A HREF="http://www.phoneboy.com"> PhoneBoy's Check Point FAQ (on
|
|
Check Point only, not FreeS/WAN)</A>
|
|
<BR></P>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2001-August/002351.html">
|
|
Chris Harwell's tips FreeS/WAN configs (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009362.html">
|
|
Daniel Tombeil's configs (PSK)</A></P>
|
|
<P><A HREF="#checkpoint.top">Back to chart</A></P>
|
|
<H4><A NAME="cisco">Cisco</A></H4>
|
|
<UL>
|
|
<LI> Cisco supports IPsec-over-UDP NAT traversal.</LI>
|
|
<LI>Cisco VPN Client appears to use nonstandard IPsec and does not work
|
|
with FreeS/WAN.<A HREF="https://mj2.freeswan.org/archives/2003-August/maillist.html">
|
|
This message</A> concerns Cisco VPN Client 4.01.
|
|
<!-- fix link -->
|
|
</LI>
|
|
<LI>A Linux FreeS/WAN-Cisco connection may close after some time.<A HREF="http://lists.freeswan.org/pipermail/users/2001-December/005758.html">
|
|
Here</A> is a workaround, and<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
|
|
here</A> is another comment on the same subject.</LI>
|
|
<LI><A HREF="http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t2/3desips.htm">
|
|
Older Ciscos</A> purchased outside the United States may not have 3DES,
|
|
which FreeS/WAN requires.</LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-June/000406.html">
|
|
RSA keying may not be possible between Cisco and FreeS/WAN.</A></LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/004357.html">
|
|
In ipsec.conf, VPN3000 DN (distinguished name) must be in binary (X.509
|
|
only)</A></LI>
|
|
</UL>
|
|
<P><A HREF="http://rr.sans.org/encryption/cisco_router.php"> SANS
|
|
Institute HOWTO (PSK).</A> Detailed, with extensive references.
|
|
<BR><A HREF="http://www.worldbank.ro/IPSEC/cisco-linux.txt"> Short HOWTO
|
|
(PSK)</A>
|
|
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
|
|
French page with configs for Cisco IOS, PIX and VPN 3000 (X.509)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-August/002966.html">
|
|
Dave McFerren's sample configs (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-September/003422.html">
|
|
Wolfgang Tremmel's sample configs (PSK road warrior)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00578.html">
|
|
Old doc from Pete Davis, with William Watson's updated Tips (PSK)</A>
|
|
<BR></P>
|
|
<P><STRONG>Some PIX specific information:</STRONG>
|
|
<BR><A HREF="http://www.wlug.org.nz/FreeSwanToCiscoPix"> Waikato Linux
|
|
Users' Group HOWTO. Nice detail (PSK)</A>
|
|
<BR><A HREF="http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html">
|
|
John Leach's configs (PSK)</A>
|
|
<BR><A HREF="http://www.diverdown.cc/vpn/freeswanpix.html"> Greg
|
|
Robinson's settings (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007901.html">
|
|
Scott's ipsec.conf for PIX (PSK, FreeS/WAN side only)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/003949.html">
|
|
Rick Trimble's PIX and FreeS/WAN settings (PSK)</A>
|
|
<BR></P>
|
|
<P><A href="http://www.cisco.com/public/support/tac"> Cisco VPN support
|
|
page</A>
|
|
<BR><A href="http://www.ieng.com/warp/public/707/index.shtml#ipsec">
|
|
Cisco IPsec information page</A></P>
|
|
<P><A HREF="#cisco.top">Back to chart</A></P>
|
|
<H4><A NAME="equinux">Equinux VPN tracker (for Mac OS X)</A></H4>
|
|
<UL>
|
|
<LI>Graphical configurator for Mac OS X IPsec. May be an interface to
|
|
the<A HREF="#apple"> native Mac OS X IPsec</A>, which is essentially<A HREF="#kame">
|
|
KAME</A>.</LI>
|
|
<LI>To use Appletalk over IPsec tunnels,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005116.html">
|
|
run it over TCP/IP</A>, or use Open Door Networks' Shareway IP tool,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005426.html">
|
|
described here.</A></LI>
|
|
</UL>
|
|
<P> Equinux provides<A HREF="http://www.equinux.com/download/HowTo_FreeSWAN.pdf">
|
|
this excellent interop PDF</A> (PSK, RSA, X.509).</P>
|
|
<P><A HREF="#equinux.top">Back to chart</A></P>
|
|
<H4><A NAME="fsecure">F-Secure</A></H4>
|
|
<UL>
|
|
<LI>
|
|
<!-- <A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007596.html"> -->
|
|
F-Secure supports IPsec-over-UDP NAT traversal.</LI>
|
|
</UL>
|
|
<P><A HREF="http://www.pingworks.de/tech/vpn/vpn.txt">pingworks.de's
|
|
"Connecting F-Secure's VPN+ to Linux FreeS/WAN" (PSK road warrior)</A>
|
|
<BR> <A HREF="http://www.pingworks.de/tech/vpn/vpn.pdf">Same thing
|
|
as PDF</A>
|
|
<BR><A HREF="http://www.exim.org/pipermail/linux-ipsec/Week-of-Mon-20010122/000061.html">
|
|
Success report, no detail (PSK)</A>
|
|
<BR><A HREF="http://www.exim.org/pipermail/linux-ipsec/Week-of-Mon-20010122/000041.html">
|
|
Success report, no detail (Manual)</A></P>
|
|
|
|
<!-- Other NAT traversers:
|
|
http://lists.freeswan.org/pipermail/users/2002-April/009136.html
|
|
and ssh sentinel:
|
|
http://lists.freeswan.org/pipermail/users/2001-September/003108.html
|
|
-->
|
|
<P><A HREF="#fsecure.top">Back to chart</A></P>
|
|
<H4><A NAME="gauntlet">Gauntlet GVPN</A></H4>
|
|
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00535.html">
|
|
Richard Reiner's ipsec.conf (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011434.html">
|
|
Might work without that pesky firewall... (PSK)</A>
|
|
<BR>
|
|
<!-- insert archive link -->
|
|
In late July, 2003 Alexandar Antik reported success interoperating
|
|
with Gauntlet 6.0 for Solaris (X.509). Unfortunately the message is not
|
|
properly archived at this time.</P>
|
|
<P><A HREF="#gauntlet.top">Back to chart</A></P>
|
|
<H4><A NAME="aix">IBM AIX</A></H4>
|
|
<P><A HREF="http://www-1.ibm.com/servers/esdd/articles/security.html">
|
|
IBM's "Built-In Network Security with AIX" (PSK, X.509)</A>
|
|
<BR><A HREF="http://www-1.ibm.com/servers/aix/products/ibmsw/security/vpn/faqandtips/#ques20">
|
|
IBM's tip: importing Linux FreeS/WAN settings into AIX's<VAR> ikedb</VAR>
|
|
(PSK)</A></P>
|
|
<P><A HREF="#aix.top">Back to chart</A></P>
|
|
<H4><A NAME="as400">IBM AS/400</A></H4>
|
|
<UL>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009106.html">
|
|
Road Warriors may act flaky</A>.</LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-September/014264.html">
|
|
Richard Welty's tips and tricks</A>
|
|
<BR></P>
|
|
<P><A HREF="#as400.top">Back to chart</A></P>
|
|
<H4><A NAME="intel">Intel Shiva LANRover / Net Structure</A></H4>
|
|
<UL>
|
|
<LI>Intel Shiva LANRover is now known as Intel Net Structure.</LI>
|
|
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00298.html">
|
|
Shiva seems to have two modes: IPsec or the proprietary "Shiva Tunnel".</A>
|
|
Of course, FreeS/WAN will only create IPsec tunnels.</LI>
|
|
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00293.html">
|
|
AH may not work for Shiva-FreeS/WAN.</A> That's OK, since FreeS/WAN has
|
|
phased out the use of AH.</LI>
|
|
</UL>
|
|
<P><A HREF="http://snowcrash.tdyc.com/freeswan/"> Snowcrash's configs
|
|
(PSK)</A>
|
|
<BR><A HREF="http://www.opus1.com/vpn/index.html"> Old configs from an
|
|
interop (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/003831.html">
|
|
The day Shiva tickled a Pluto bug (PSK)</A>
|
|
<BR> <A HREF="http://lists.freeswan.org/pipermail/users/2001-October/004270.html">
|
|
Follow up: success!</A></P>
|
|
<P><A HREF="#intel.top">Back to chart</A></P>
|
|
<H4><A NAME="lancom">LanCom (formerly ELSA)</A></H4>
|
|
<UL>
|
|
<LI>This router is popular in Germany.</LI>
|
|
</UL>
|
|
<P> Jakob Curdes successfully created a PSK connection with the LanCom
|
|
1612 in August 2003.
|
|
<!-- add ML link when it appears -->
|
|
</P>
|
|
<P><A HREF="#lancom.top">Back to chart</A></P>
|
|
<H4><A NAME="linksys">Linksys</A></H4>
|
|
<UL>
|
|
<LI>Linksys may be used as an IPsec tunnel endpoint,<STRONG> OR</STRONG>
|
|
as a router in "IPsec passthrough" mode, so that the IPsec tunnel
|
|
passes through the Linksys.</LI>
|
|
</UL>
|
|
<H5>As tunnel endpoint</H5>
|
|
<P><A HREF="http://www.freeswan.ca/docs/BEFVP41/"> Ken Bantoft's
|
|
instructions (Road Warrior with PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007814.html">
|
|
Nate Carlson's caveats</A></P>
|
|
<H5>In IPsec passthrough mode</H5>
|
|
<P><A HREF="http://www-ec.njit.edu/~rxt1077/Howto.txt"> Sample HOWTO
|
|
through a Linksys Router</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2002/02/msg00114.html">
|
|
Nadeem Hasan's configs</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2002/02/msg00180.html">
|
|
Brock Nanson's tips</A>
|
|
<BR></P>
|
|
<P><A HREF="#linksys.top">Back to chart</A></P>
|
|
<H4><A NAME="lucent">Lucent</A></H4>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010976.html">
|
|
Partial success report; see also the next message in thread</A></P>
|
|
|
|
<!-- section done -->
|
|
<P><A HREF="#lucent.top">Back to chart</A></P>
|
|
<H4><A NAME="netasq">Netasq</A></H4>
|
|
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
|
|
French page with configs (X.509)</A></P>
|
|
|
|
<!-- section done -->
|
|
<P><A HREF="#netasq.top">Back to chart</A></P>
|
|
<H4><A NAME="netcelo">Netcelo</A></H4>
|
|
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
|
|
French page with configs (X.509)</A>
|
|
<!-- section done -->
|
|
</P>
|
|
<P><A HREF="#netcelo.top">Back to chart</A></P>
|
|
<H4><A NAME="netgear">Netgear fvs318</A></H4>
|
|
<UL>
|
|
<LI>With a recent Linux FreeS/WAN, you will require the latest (12/2002)
|
|
Netgear firmware, which supports Diffie-Hellman (DH) group 2. For
|
|
security reasons, we phased out DH 1 after Linux FreeS/WAN 1.5.</LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011833.html">
|
|
This message</A> reports the incompatibility between Linux FreeS/WAN
|
|
1.6+ and Netgear fvs318 without the firmware upgrade.</LI>
|
|
<LI>We believe Linux FreeS/WAN 1.5 and earlier will interoperate with
|
|
any NetGear firmware.</LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2003-February/017891.html">
|
|
John Morris' setup (PSK)</A></P>
|
|
<P><A HREF="#netgear.top">Back to chart</A></P>
|
|
<H4><A NAME="netscreen">Netscreen 100 or 5xp</A></H4>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013409.html">
|
|
Errol Neal's settings (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015265.html">
|
|
Corey Rogers' configs (PSK, no PFS)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013051.html">
|
|
Jordan Share's configs (PSK, 2 subnets, through static NAT)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/08/msg00404.html">
|
|
Set src proxy_id to your protected subnet/mask</A>
|
|
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
|
|
French page with ipsec.conf, Netscreen screen shots (X.509, may need to
|
|
revert to PSK...)</A></P>
|
|
<P><A HREF="http://archives.neohapsis.com/archives/sf/linux/2001-q2/0123.html">
|
|
A report of a company using Netscreen with FreeS/WAN on a large scale
|
|
(FreeS/WAN road warriors?)</A></P>
|
|
<P><A HREF="#netscreen.top">Back to chart</A></P>
|
|
<H4><A NAME="nortel">Nortel Contivity</A></H4>
|
|
<UL>
|
|
<LI> Nortel supports IPsec-over-UDP NAT traversal.</LI>
|
|
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00417.html">
|
|
Some older versions of Contivity and FreeS/WAN will not communicate.</A>
|
|
</LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010924.html">
|
|
FreeS/WAN cannot be used as a "client" to a Nortel Contivity server,
|
|
but can be used as a branch-office tunnel.</A></LI>
|
|
|
|
<!-- Probably obsoleted by Ken's post
|
|
<LI>
|
|
(Matthias siebler from old interop)
|
|
At one point you could not configure Nortel-FreeS/WAN tunnels as
|
|
"Client Tunnels" since FreeS/WAN does not support Aggressive Mode.
|
|
Current status of this problem: unknown.
|
|
<LI>
|
|
<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/004612.html">
|
|
How do we map group and user passwords onto the data that FreeS/WAN wants?
|
|
</A>
|
|
</LI>
|
|
-->
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015455.html">
|
|
Contivity does not send Distinguished Names in the order FS wants them
|
|
(X.509).</A></LI>
|
|
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00137.html">
|
|
Connections may time out after 30-40 minutes idle.</A></LI>
|
|
</UL>
|
|
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00137.html">
|
|
JJ Streicher-Bremer's mini HOWTO for old new software. (PSK with two
|
|
subnets)</A>
|
|
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
|
|
French page with configs (X.509)</A>. This succeeds using the above
|
|
X.509 tip.</P>
|
|
|
|
<!-- I could do more searching but this is a solid start. -->
|
|
<P><A HREF="#nortel.top">Back to chart</A></P>
|
|
<H4><A NAME="radguard">Radguard</A></H4>
|
|
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00009.html">
|
|
Marko Hausalo's configs (PSK).</A> Note: These do create a connection,
|
|
as you can see by "IPsec SA established".
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/???.html">
|
|
Claudia Schmeing's comments</A></P>
|
|
<P><A HREF="#radguard.top">Back to chart</A></P>
|
|
<H4><A NAME="raptor">Raptor (NT or Solaris)</A></H4>
|
|
<P></P>
|
|
<UL>
|
|
<LI>Now known as Symantec Enterprise Firewall.</LI>
|
|
<LI>The Raptor does not normally come with X.509, but this may be
|
|
available as an add-on.</LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010256.html">
|
|
Raptor requires alphanumberic PSK values, whereas FreeS/WAN uses hex.</A>
|
|
</LI>
|
|
<LI>Raptor's tunnel endpoint may be a host, subnet or group of subnets
|
|
(see<A HREF="http://lists.freeswan.org/pipermail/design/2001-November/001295.html">
|
|
this message</A> ). FreeS/WAN cannot handle the group of subnets; you
|
|
must create separate connections for each in order to interoperate.</LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010113.html">
|
|
Some versions of Raptor accept only single DES.</A> According to this
|
|
German message,<A HREF="http://radawana.cg.tuwien.ac.at/mail-archives/lll/200012/msg00065.html">
|
|
the Raptor Mobile Client demo offers single DES only.</A></LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-January/006935.html">
|
|
Peter Mazinger's settings (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005522.html">
|
|
Peter Gerland's configs (PSK)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00597.html">
|
|
Charles Griebel's configs (PSK).</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-July/012275.html">
|
|
Lumir Srch's tips (PSK)</A></P>
|
|
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00214.html">
|
|
John Hardy's configs (Manual)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/01/msg00236.html">
|
|
Older Raptors want 3DES keys in 3 parts (Manual).</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/06/msg00480.html">
|
|
Different keys for each direction? (Manual)</A>
|
|
<BR></P>
|
|
<P><A HREF="#raptor.top">Back to chart</A></P>
|
|
<H4><A NAME="redcreek">Redcreek Ravlin</A></H4>
|
|
<UL>
|
|
<LI>Known issue #1: The Ravlin expects a quick mode renegotiation right
|
|
after every Main Mode negotiation.</LI>
|
|
<LI> Known issue #2: The Ravlin tries to negotiate a zero connection
|
|
lifetime, which it takes to mean "infinite".<A HREF="http://www.bear-cave.org.uk/linux/ravlin/">
|
|
Jim Hague's patch</A> addresses both issues.</LI>
|
|
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/03/msg00191.html">
|
|
Interop works with Ravlin Firmware > 3.33. Includes tips (PSK).</A></LI>
|
|
</UL>
|
|
<P><A HREF="#redcreek.top">Back to chart</A></P>
|
|
<H4><A NAME="sonicwall">SonicWall</A></H4>
|
|
<UL>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-June/000998.html">
|
|
Sonicwall cannot be used for Road Warrior setups</A></LI>
|
|
<LI> At one point,<A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00217.html">
|
|
only Sonicwall PRO supported triple DES</A>.</LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-March/008600.html">
|
|
Older Sonicwalls (before Nov 2001) feature Diffie Hellman group 1 only</A>
|
|
.</LI>
|
|
</UL>
|
|
<P><A HREF="http://www.xinit.cx/docs/freeswan.html"> Paul Wouters'
|
|
config (PSK)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00073.html">
|
|
Dilan Arumainathan's configuration (PSK)</A>
|
|
<BR><A HREF="http://www.gravitas.co.uk/vpndebug"> Dariush's setup...
|
|
only opens one way (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022302.html">
|
|
Andreas Steffen's tips (X.509)</A>
|
|
<BR></P>
|
|
<P><A HREF="#sonicwall.top">Back to chart</A></P>
|
|
<H4><A NAME="sun">Sun Solaris</A></H4>
|
|
<UL>
|
|
<LI> Solaris 8+ has a native (in kernel) IPsec implementation.</LI>
|
|
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010503.html">
|
|
Solaris does not seem to support tunnel mode, but you can make IP-in-IP
|
|
tunnels instead, like this.</A></LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2003-June/022216.html">
|
|
Reports of some successful interops</A> from a fellow @sun.com. See
|
|
also<A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022247.html">
|
|
these follow up posts</A>.
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00332.html">
|
|
Aleks Shenkman's configs (Manual in transport mode)</A>
|
|
<BR>
|
|
<!--sparc 64 stuff goes where?-->
|
|
</P>
|
|
<P><A HREF="#solaris.top">Back to chart</A></P>
|
|
<H4><A NAME="symantec">Symantec</A></H4>
|
|
<UL>
|
|
<LI>The Raptor, covered<A HREF="#raptor"> above</A>, is now known as
|
|
Symantec Enterprise Firewall.</LI>
|
|
<LI>Symantec's "distinguished name" is a KEY_ID. See Andreas Steffen's
|
|
post, below.</LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009037.html">
|
|
Andreas Steffen's configs for Symantec 200R (PSK)</A></P>
|
|
<P><A HREF="#symantec.top">Back to chart</A></P>
|
|
<H4><A NAME="watchguard">Watchguard Firebox</A></H4>
|
|
<UL>
|
|
<LI>Automatic keying works with WatchGuard 5.0+ only.</LI>
|
|
<LI>Seen to interoperate with WatchGuard 1000, II, III; firmware v. 5,
|
|
6..</LI>
|
|
<LI>For manual keying, Watchguard's Policy Manager expects SPI numbers
|
|
and encryption and authentication keys in decimal (not hex).</LI>
|
|
</UL>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-July/012595.html">
|
|
WatchGuard's HOWTO (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013342.html">
|
|
Ronald C. Riviera's Settings (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00179.html">
|
|
Walter Wickersham's Notes (PSK)</A>
|
|
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015587.html">
|
|
Max Enders' Configs (Manual)</A></P>
|
|
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009404.html">
|
|
Old known issue with auto keying</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00124.html">
|
|
Tips on key generation and format (Manual)</A>
|
|
<BR></P>
|
|
<P><A HREF="#watchguard.top">Back to chart</A></P>
|
|
<H4><A NAME="xedia">Xedia Access Point/QVPN</A></H4>
|
|
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/12/msg00520.html">
|
|
Hybrid IPsec/L2TP connection settings (X.509)</A>
|
|
<BR><A HREF="http://www.sandelman.ottawa.on.ca/ipsec/1999/08/msg00140.html">
|
|
Xedia's LAN-LAN links don't use multiple tunnels</A>
|
|
<BR> <A HREF="http://www.sandelman.ottawa.on.ca/ipsec/1999/08/msg00140.html">
|
|
That explanation, continued</A></P>
|
|
<P><A HREF="#xedia.top">Back to chart</A></P>
|
|
<H4><A NAME="zyxel">Zyxel</A></H4>
|
|
<UL>
|
|
<LI>The Zyxel Zywall is a rebranded SSH Sentinel box. See also our
|
|
section on<A HREF="#ssh"> SSH</A>.</LI>
|
|
<LI>There seems to be a problem with keeping this connection alive. This
|
|
is caused at the Zyxel end. See this brief<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00141.html">
|
|
discussion and solution.</A></LI>
|
|
</UL>
|
|
<P><A HREF="http://www.zyxel.com/support/supportnote/zywall/app/zw_freeswan.htm">
|
|
Zyxel's Zywall to FreeS/WAN instructions (PSK)</A>
|
|
<BR><A HREF="http://www.zyxel.com/support/supportnote/p652/app/zw_freeswan.htm">
|
|
Zyxel's Prestige to FreeS/WAN instructions (PSK)</A>. Note: not all
|
|
Prestige versions include VPN software.
|
|
<BR><A HREF="http://www.lancry.net/techdocs/freeswan-zyxel.txt"> Fabrice
|
|
Cahen's HOWTO (PSK)</A>
|
|
<BR> </P>
|
|
<P><A HREF="#zyxel.top">Back to chart</A></P>
|
|
|
|
<!-- SAMPLE ENTRY
|
|
|
|
<H4><A NAME="timestep">Timestep</A></H4>
|
|
|
|
<P>Text goes here.
|
|
</P>
|
|
|
|
-->
|
|
<HR>
|
|
<H1><A name="performance">Performance of FreeS/WAN</A></H1>
|
|
The performance of FreeS/WAN is adequate for most applications.
|
|
<P>In normal operation, the main concern is the overhead for encryption,
|
|
decryption and authentication of the actual IPsec (<A href="#ESP">ESP</A>
|
|
and/or<A href="#AH"> AH</A>) data packets. Tunnel setup and rekeying
|
|
occur so much less frequently than packet processing that, in general,
|
|
their overheads are not worth worrying about.</P>
|
|
<P>At startup, however, tunnel setup overheads may be significant. If
|
|
you reboot a gateway and it needs to establish many tunnels, expect
|
|
some delay. This and other issues for large gateways are discussed<A href="#biggate">
|
|
below</A>.</P>
|
|
<H2><A name="pub.bench">Published material</A></H2>
|
|
<P>The University of Wales at Aberystwyth has done quite detailed speed
|
|
tests and put<A href="http://tsc.llwybr.org.uk/public/reports/SWANTIME/">
|
|
their results</A> on the web.</P>
|
|
<P>Davide Cerri's<A href="http://www.linux.it/~davide/doc/"> thesis (in
|
|
Italian)</A> includes performance results for FreeS/WAN and for<A href="#TLS">
|
|
TLS</A>. He posted an<A href="http://lists.freeswan.org/pipermail/users/2001-December/006303.html">
|
|
English summary</A> on the mailing list.</P>
|
|
<P>Steve Bellovin used one of AT&T Research's FreeS/WAN gateways as his
|
|
data source for an analysis of the cache sizes required for key
|
|
swapping in IPsec. Available as<A href="http://www.research.att.com/~smb/talks/key-agility.email.txt">
|
|
text</A> or<A href="http://www.research.att.com/~smb/talks/key-agility.pdf">
|
|
PDF slides</A> for a talk on the topic.</P>
|
|
<P>See also the NAI work mentioned in the next section.</P>
|
|
<H2><A name="perf.estimate">Estimating CPU overheads</A></H2>
|
|
<P>We can come up with a formula that roughly relates CPU speed to the
|
|
rate of IPsec processing possible. It is far from exact, but should be
|
|
usable as a first approximation.</P>
|
|
<P>An analysis of authentication overheads for high-speed networks,
|
|
including some tests using FreeS/WAN, is on the<A href="http://www.pgp.com/research/nailabs/cryptographic/adaptive-cryptographic.asp">
|
|
NAI Labs site</A>. In particular, see figure 3 in this<A href="http://download.nai.com/products/media/pgp/pdf/acsa_final_report.pdf">
|
|
PDF document</A>. Their estimates of overheads, measured in Pentium II
|
|
cycles per byte processed are:</P>
|
|
<TABLE align="center" border="1"><TBODY></TBODY>
|
|
<TR><TH></TH><TH>IPsec</TH><TH>authentication</TH><TH>encryption</TH><TH>
|
|
cycles/byte</TH></TR>
|
|
<TR><TD>Linux IP stack alone</TD><TD>no</TD><TD>no</TD><TD>no</TD><TD align="right">
|
|
5</TD></TR>
|
|
<TR><TD>IPsec without crypto</TD><TD>yes</TD><TD>no</TD><TD>no</TD><TD align="right">
|
|
11</TD></TR>
|
|
<TR><TD>IPsec, authentication only</TD><TD>yes</TD><TD>SHA-1</TD><TD>no</TD><TD
|
|
align="right">24</TD></TR>
|
|
<TR><TD>IPsec with encryption</TD><TD>yes</TD><TD>yes</TD><TD>yes</TD><TD
|
|
align="right">not tested</TD></TR>
|
|
</TABLE>
|
|
<P>Overheads for IPsec with encryption were not tested in the NAI work,
|
|
but Antoon Bosselaers'<A href="http://www.esat.kuleuven.ac.be/~bosselae/fast.html">
|
|
web page</A> gives cost for his optimised Triple DES implementation as
|
|
928 Pentium cycles per block, or 116 per byte. Adding that to the 24
|
|
above, we get 140 cycles per byte for IPsec with encryption.</P>
|
|
<P>At 140 cycles per byte, a 140 MHz machine can handle a megabyte -- 8
|
|
megabits -- per second. Speeds for other machines will be proportional
|
|
to this. To saturate a link with capacity C megabits per second, you
|
|
need a machine running at<VAR> C * 140/8 = C * 17.5</VAR> MHz.</P>
|
|
<P>However, that estimate is not precise. It ignores the differences
|
|
between:</P>
|
|
<UL>
|
|
<LI>NAI's test packets and real traffic</LI>
|
|
<LI>NAI's Pentium II cycles, Bosselaers' Pentium cycles, and your
|
|
machine's cycles</LI>
|
|
<LI>different 3DES implementations</LI>
|
|
<LI>SHA-1 and MD5</LI>
|
|
</UL>
|
|
<P>and does not account for some overheads you will almost certainly
|
|
have:</P>
|
|
<UL>
|
|
<LI>communication on the client-side interface</LI>
|
|
<LI>switching between multiple tunnels -- re-keying, cache reloading and
|
|
so on</LI>
|
|
</UL>
|
|
<P>so we suggest using<VAR> C * 25</VAR> to get an estimate with a bit
|
|
of a built-in safety factor.</P>
|
|
<P>This covers only IP and IPsec processing. If you have other loads on
|
|
your gateway -- for example if it is also working as a firewall -- then
|
|
you will need to add your own safety factor atop that.</P>
|
|
<P>This estimate matches empirical data reasonably well. For example,
|
|
Metheringham's tests, described<A href="#klips.bench"> below</A>, show
|
|
a 733 topping out between 32 and 36 Mbit/second, pushing data as fast
|
|
as it can down a 100 Mbit link. Our formula suggests you need at least
|
|
an 800 to handle a fully loaded 32 Mbit link. The two results are
|
|
consistent.</P>
|
|
<P>Some examples using this estimation method:</P>
|
|
<TABLE align="center" border="1"><TBODY></TBODY>
|
|
<TR><TH colspan="2">Interface</TH><TH colspan="3">Machine speed in MHz</TH>
|
|
</TR>
|
|
<TR><TH>Type</TH><TH>Mbit per
|
|
<BR> second</TH><TH>Estimate
|
|
<BR> Mbit*25</TH><TH>Minimum IPSEC gateway</TH><TH>Minimum with other
|
|
load
|
|
<P>(e.g. firewall)</P>
|
|
</TH></TR>
|
|
<TR><TD>DSL</TD><TD align="right">1</TD><TD align="right">25 MHz</TD><TD rowspan="2">
|
|
whatever you have</TD><TD rowspan="2">133, or better if you have it</TD></TR>
|
|
<TR><TD>cable modem</TD><TD align="right">3</TD><TD align="right">75 MHz</TD>
|
|
</TR>
|
|
<TR><TD><STRONG>any link, light load</STRONG></TD><TD align="right"><STRONG>
|
|
5</STRONG></TD><TD align="right">125 MHz</TD><TD>133</TD><TD>200+,<STRONG>
|
|
almost any surplus machine</STRONG></TD></TR>
|
|
<TR><TD>Ethernet</TD><TD align="right">10</TD><TD align="right">250 MHz</TD><TD>
|
|
surplus 266 or 300</TD><TD>500+</TD></TR>
|
|
<TR><TD><STRONG>fast link, moderate load</STRONG></TD><TD align="right"><STRONG>
|
|
20</STRONG></TD><TD align="right">500 MHz</TD><TD>500</TD><TD>800+,<STRONG>
|
|
any current off-the-shelf PC</STRONG></TD></TR>
|
|
<TR><TD>T3 or E3</TD><TD align="right">45</TD><TD align="right">1125 MHz</TD><TD>
|
|
1200</TD><TD>1500+</TD></TR>
|
|
<TR><TD>fast Ethernet</TD><TD align="right">100</TD><TD align="right">
|
|
2500 MHz</TD><TD align="center" colspan="2" rowspan="2">// not feasible
|
|
with 3DES in software on current machines //</TD></TR>
|
|
<TR><TD>OC3</TD><TD align="right">155</TD><TD align="right">3875 MHz</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>Such an estimate is far from exact, but should be usable as minimum
|
|
requirement for planning. The key observations are:</P>
|
|
<UL>
|
|
<LI>older<STRONG> surplus machines</STRONG> are fine for IPsec gateways
|
|
at loads up to<STRONG> 5 megabits per second</STRONG> or so</LI>
|
|
<LI>a<STRONG> mid-range new machine</STRONG> can handle IPsec at rates
|
|
up to<STRONG> 20 megabits per second</STRONG> or more</LI>
|
|
</UL>
|
|
<H3><A name="perf.more">Higher performance alternatives</A></H3>
|
|
<P><A href="#AES">AES</A> is a new US government block cipher standard,
|
|
designed to replace the obsolete<A href="#DES"> DES</A>. If FreeS/WAN
|
|
using<A href="#3DES"> 3DES</A> is not fast enough for your application,
|
|
the AES<A href="#patch"> patch</A> may help.</P>
|
|
<P>To date (March 2002) we have had only one<A href="http://lists.freeswan.org/pipermail/users/2002-February/007771.html">
|
|
mailing list report</A> of measurements with the patch applied. It
|
|
indicates that, at least for the tested load on that user's network,<STRONG>
|
|
AES roughly doubles IPsec throughput</STRONG>. If further testing
|
|
confirms this, it may prove possible to saturate an OC3 link in
|
|
software on a high-end box.</P>
|
|
<P>Also, some work is being done toward support of<A href="#hardware">
|
|
hardware IPsec acceleration</A> which might extend the range of
|
|
requirements FreeS/WAN could meet.</P>
|
|
<H3><A NAME="11_2_2">Other considerations</A></H3>
|
|
<P>CPU speed may be the main issue for IPsec performance, but of course
|
|
it isn't the only one.</P>
|
|
<P>You need good ethernet cards or other network interface hardware to
|
|
get the best performance. See this<A href="http://www.ethermanage.com/ethernet/ethernet.html">
|
|
ethernet information</A> page and this<A href="http://www.scyld.com/diag">
|
|
Linux network driver</A> page.</P>
|
|
<P>The current FreeS/WAN kernel code is largely single-threaded. It is
|
|
SMP safe, and will run just fine on a multiprocessor machine (<A href="#multiprocessor">
|
|
discussion</A>), but the load within the kernel is not shared
|
|
effectively. This means that, for example to saturate a T3 -- which
|
|
needs about a 1200 MHz machine -- you cannot expect something like a
|
|
dual 800 to do the job.</P>
|
|
<P>On the other hand, SMP machines do tend to share loads well so --
|
|
provided one CPU is fast enough for the IPsec work -- a multiprocessor
|
|
machine may be ideal for a gateway with a mixed load.</P>
|
|
<H2><A name="biggate">Many tunnels from a single gateway</A></H2>
|
|
<P>FreeS/WAN allows a single gateway machine to build tunnels to many
|
|
others. There may, however, be some problems for large numbers as
|
|
indicated in this message from the mailing list:</P>
|
|
<PRE>Subject: Re: Maximum number of ipsec tunnels?
|
|
Date: Tue, 18 Apr 2000
|
|
From: "John S. Denker" <[email protected]>
|
|
|
|
Christopher Ferris wrote:
|
|
|
|
>> What are the maximum number ipsec tunnels FreeS/WAN can handle??
|
|
|
|
Henry Spencer wrote:
|
|
|
|
>There is no particular limit. Some of the setup procedures currently
|
|
>scale poorly to large numbers of connections, but there are (clumsy)
|
|
>workarounds for that now, and proper fixes are coming.
|
|
|
|
1) "Large" numbers means anything over 50 or so. I routinely run boxes
|
|
with about 200 tunnels. Once you get more than 50 or so, you need to worry
|
|
about several scalability issues:
|
|
|
|
a) You need to put a "-" sign in syslogd.conf, and rotate the logs daily
|
|
not weekly.
|
|
|
|
b) Processor load per tunnel is small unless the tunnel is not up, in which
|
|
case a new half-key gets generated every 90 seconds, which can add up if
|
|
you've got a lot of down tunnels.
|
|
|
|
c) There's other bits of lore you need when running a large number of
|
|
tunnels. For instance, systematically keeping the .conf file free of
|
|
conflicts requires tools that aren't shipped with the standard freeswan
|
|
package.
|
|
|
|
d) The pluto startup behavior is quadratic. With 200 tunnels, this eats up
|
|
several minutes at every restart. I'm told fixes are coming soon.
|
|
|
|
2) Other than item (1b), the CPU load depends mainly on the size of the
|
|
pipe attached, not on the number of tunnels.
|
|
</PRE>
|
|
<P>It is worth noting that item (1b) applies only to repeated attempts
|
|
to re-key a data connection (IPsec SA, Phase 2) over an established
|
|
keying connection (ISAKMP SA, Phase 1). There are two ways to reduce
|
|
this overhead using settings in<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A>:</P>
|
|
<UL>
|
|
<LI>set<VAR> keyingtries</VAR> to some small value to limit repetitions</LI>
|
|
<LI>set<VAR> keylife</VAR> to a short time so that a failing data
|
|
connection will be cleaned up when the keying connection is reset.</LI>
|
|
</UL>
|
|
<P>The overheads for establishing keying connections (ISAKMP SAs, Phase
|
|
1) are lower because for these Pluto does not perform expensive
|
|
operations before receiving a reply from the peer.</P>
|
|
<P>A gateway that does a lot of rekeying -- many tunnels and/or low
|
|
settings for tunnel lifetimes -- will also need a lot of<A href="#random">
|
|
random numbers</A> from the random(4) driver.</P>
|
|
<H2><A name="low-end">Low-end systems</A></H2>
|
|
<P><EM>Even a 486 can handle a T1 line</EM>, according to this mailing
|
|
list message:</P>
|
|
<PRE>Subject: Re: linux-ipsec: IPSec Masquerade
|
|
Date: Fri, 15 Jan 1999 11:13:22 -0500
|
|
From: Michael Richardson
|
|
|
|
. . . A 486/66 has been clocked by Phil Karn to do
|
|
10Mb/s encryption.. that uses all the CPU, so half that to get some CPU,
|
|
and you have 5Mb/s. 1/3 that for 3DES and you get 1.6Mb/s....</PRE>
|
|
<P>and a piece of mail from project technical lead Henry Spencer:</P>
|
|
<PRE>Oh yes, and a new timing point for Sandy's docs... A P60 -- yes, a 60MHz
|
|
Pentium, talk about antiques -- running a host-to-host tunnel to another
|
|
machine shows an FTP throughput (that is, end-to-end results with a real
|
|
protocol) of slightly over 5Mbit/s either way. (The other machine is much
|
|
faster, the network is 100Mbps, and the ether cards are good ones... so
|
|
the P60 is pretty definitely the bottleneck.)</PRE>
|
|
<P>From the above, and from general user experience as reported on the
|
|
list, it seems clear that a cheap surplus machine -- a reasonable 486,
|
|
a minimal Pentium box, a Sparc 5, ... -- can easily handle a home
|
|
office or a small company connection using any of:</P>
|
|
<UL>
|
|
<LI>ADSL service</LI>
|
|
<LI>cable modem</LI>
|
|
<LI>T1</LI>
|
|
<LI>E1</LI>
|
|
</UL>
|
|
<P>If available, we suggest using a Pentium 133 or better. This should
|
|
ensure that, even under maximum load, IPsec will use less than half the
|
|
CPU cycles. You then have enough left for other things you may want on
|
|
your gateway -- firewalling, web caching, DNS and such.</P>
|
|
<H2><A name="klips.bench">Measuring KLIPS</A></H2>
|
|
<P>Here is some additional data from the mailing list.</P>
|
|
<PRE>Subject: FreeSWAN (specically KLIPS) performance measurements
|
|
Date: Thu, 01 Feb 2001
|
|
From: Nigel Metheringham <[email protected]>
|
|
|
|
I've spent a happy morning attempting performance tests against KLIPS
|
|
(this is due to me not being able to work out the CPU usage of KLIPS so
|
|
resorting to the crude measurements of maximum throughput to give a
|
|
baseline to work out loading of a box).
|
|
|
|
Measurements were done using a set of 4 boxes arranged in a line, each
|
|
connected to the next by 100Mbit duplex ethernet. The inner 2 had an
|
|
ipsec tunnel between them (shared secret, but I was doing measurements
|
|
when the tunnel was up and running - keying should not be an issue
|
|
here). The outer pair of boxes were traffic generators or traffic sink.
|
|
|
|
The crypt boxes are Compaq DL380s - Uniprocessor PIII/733 with 256K
|
|
cache. They have 128M main memory. Nothing significant was running on
|
|
the boxes other than freeswan. The kernel was a 2.2.19pre7 patched
|
|
with freeswan and ext3.
|
|
|
|
Without an ipsec tunnel in the chain (ie the 2 inner boxes just being
|
|
100BaseT routers), throughput (measured with ttcp) was between 10644
|
|
and 11320 KB/sec
|
|
|
|
With an ipsec tunnel in place, throughput was between 3268 and 3402
|
|
KB/sec
|
|
|
|
These measurements are for data pushed across a TCP link, so the
|
|
traffic on the wire between the 2 ipsec boxes would have been higher
|
|
than this....
|
|
|
|
vmstat (run during some other tests, so not affecting those figures) on
|
|
the encrypting box shows approx 50% system & 50% idle CPU - which I
|
|
don't believe at all. Interactive feel of the box was significantly
|
|
sluggish.
|
|
|
|
I also tried running the kernel profiler (see man readprofile) during
|
|
test runs.
|
|
|
|
A box doing primarily decrypt work showed basically nothing happening -
|
|
I assume interrupts were off.
|
|
A box doing encrypt work showed the following:-
|
|
Ticks Function Load
|
|
~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
956 total 0.0010
|
|
532 des_encrypt2 0.1330
|
|
110 MD5Transform 0.0443
|
|
97 kmalloc 0.1880
|
|
39 des_encrypt3 0.1336
|
|
23 speedo_interrupt 0.0298
|
|
14 skb_copy_expand 0.0250
|
|
13 ipsec_tunnel_start_xmit 0.0009
|
|
13 Decode 0.1625
|
|
11 handle_IRQ_event 0.1019
|
|
11 .des_ncbc_encrypt_end 0.0229
|
|
10 speedo_start_xmit 0.0188
|
|
9 satoa 0.0225
|
|
8 kfree 0.0118
|
|
8 ip_fragment 0.0121
|
|
7 ultoa 0.0365
|
|
5 speedo_rx 0.0071
|
|
5 .des_encrypt2_end 5.0000
|
|
4 _stext 0.0140
|
|
4 ip_fw_check 0.0035
|
|
2 rj_match 0.0034
|
|
2 ipfw_output_check 0.0200
|
|
2 inet_addr_type 0.0156
|
|
2 eth_copy_and_sum 0.0139
|
|
2 dev_get 0.0294
|
|
2 addrtoa 0.0143
|
|
1 speedo_tx_buffer_gc 0.0024
|
|
1 speedo_refill_rx_buf 0.0022
|
|
1 restore_all 0.0667
|
|
1 number 0.0020
|
|
1 net_bh 0.0021
|
|
1 neigh_connected_output 0.0076
|
|
1 MD5Final 0.0083
|
|
1 kmem_cache_free 0.0016
|
|
1 kmem_cache_alloc 0.0022
|
|
1 __kfree_skb 0.0060
|
|
1 ipsec_rcv 0.0001
|
|
1 ip_rcv 0.0014
|
|
1 ip_options_fragment 0.0071
|
|
1 ip_local_deliver 0.0023
|
|
1 ipfw_forward_check 0.0139
|
|
1 ip_forward 0.0011
|
|
1 eth_header 0.0040
|
|
1 .des_encrypt3_end 0.0833
|
|
1 des_decrypt3 0.0034
|
|
1 csum_partial_copy_generic 0.0045
|
|
1 call_out_firewall 0.0125
|
|
|
|
Hope this data is helpful to someone... however the lack of visibility
|
|
into the decrypt side makes things less clear</PRE>
|
|
<H2><A name="speed.compress">Speed with compression</A></H2>
|
|
<P>Another user reported some results for connections with and without
|
|
IP compression:</P>
|
|
<PRE>Subject: [Users] Speed with compression
|
|
Date: Fri, 29 Jun 2001
|
|
From: John McMonagle <[email protected]>
|
|
|
|
Did a couple tests with compression using the new 1.91 freeswan.
|
|
|
|
Running between 2 sites with cable modems. Both using approximately
|
|
130 mhz pentium.
|
|
|
|
Transferred files with ncftp.
|
|
|
|
Compressed file was a 6mb compressed installation file.
|
|
Non compressed was 18mb /var/lib/rpm/packages.rpm
|
|
|
|
Compressed vpn regular vpn
|
|
Compress file 42.59 kBs 42.08 kBs
|
|
regular file 110.84 kBs 41.66 kBs
|
|
|
|
Load was about 0 either way.
|
|
Ping times were very similar a bit above 9 ms.
|
|
|
|
Compression looks attractive to me.</PRE>
|
|
Later in the same thread, project technical lead Henry Spencer added:
|
|
<PRE>> is there a reason not to switch compression on? I have large gateway boxes
|
|
> connecting 3 connections, one of them with a measly DS1 link...
|
|
|
|
Run some timing tests with and without, with data and loads representative
|
|
of what you expect in production. That's the definitive way to decide.
|
|
If compression is a net loss, then obviously, leave it turned off. If it
|
|
doesn't make much difference, leave it off for simplicity and hence
|
|
robustness. If there's a substantial gain, by all means turn it on.
|
|
|
|
If both ends support compression and can successfully negotiate a
|
|
compressed connection (trivially true if both are FreeS/WAN 1.91), then
|
|
the crucial question is CPU cycles.
|
|
|
|
Compression has some overhead, so one question is whether *your* data
|
|
compresses well enough to save you more CPU cycles (by reducing the volume
|
|
of data going through CPU-intensive encryption/decryption) than it costs
|
|
you. Last time I ran such tests on data that was reasonably compressible
|
|
but not deliberately contrived to be so, this generally was not true --
|
|
compression cost extra CPU cycles -- so compression was worthwhile only if
|
|
the link, not the CPU, was the bottleneck. However, that was before the
|
|
slow-compression bug was fixed. I haven't had a chance to re-run those
|
|
tests yet, but it sounds like I'd probably see a different result. </PRE>
|
|
The bug he refers to was a problem with the compression libraries that
|
|
had us using C code, rather than assembler, for compression. It was
|
|
fixed before 1.91.
|
|
<H2><A name="methods">Methods of measuring</A></H2>
|
|
<P>If you want to measure the loads FreeS/WAN puts on a system, note
|
|
that tools such as top or measurements such as load average are
|
|
more-or-less useless for this. They are not designed to measure
|
|
something that does most of its work inside the kernel.</P>
|
|
<P>Here is a message from FreeS/WAN kernel programmer Richard Guy Briggs
|
|
on this:</P>
|
|
<PRE>> I have a batch of boxes doing Freeswan stuff.
|
|
> I want to measure the CPU loading of the Freeswan tunnels, but am
|
|
> having trouble seeing how I get some figures out...
|
|
>
|
|
> - Keying etc is in userspace so will show up on the per-process
|
|
> and load average etc (ie pluto's load)
|
|
|
|
Correct.
|
|
|
|
> - KLIPS is in the kernel space, and does not show up in load average
|
|
> I think also that the KLIPS per-packet processing stuff is running
|
|
> as part of an interrupt handler so it does not show up in the
|
|
> /proc/stat system_cpu or even idle_cpu figures
|
|
|
|
It is not running in interrupt handler. It is in the bottom half.
|
|
This is somewhere between user context (careful, this is not
|
|
userspace!) and hardware interrupt context.
|
|
|
|
> Is this correct, and is there any means of instrumenting how much the
|
|
> cpu is being loaded - I don't like the idea of a system running out of
|
|
> steam whilst still showing 100% idle CPU :-)
|
|
|
|
vmstat seems to do a fairly good job, but use a running tally to get a
|
|
good idea. A one-off call to vmstat gives different numbers than a
|
|
running stat. To do this, put an interval on your vmstat command
|
|
line.</PRE>
|
|
and another suggestion from the same thread:
|
|
<PRE>Subject: Re: Measuring the CPU usage of Freeswan
|
|
Date: Mon, 29 Jan 2001
|
|
From: Patrick Michael Kane <[email protected]>
|
|
|
|
The only truly accurate way to accurately track FreeSWAN CPU usage is to use
|
|
a CPU soaker. You run it on an unloaded system as a benchmark, then start up
|
|
FreeSWAN and take the difference to determine how much FreeSWAN is eating.
|
|
I believe someone has done this in the past, so you may find something in
|
|
the FreeSWAN archives. If not, someone recently posted a URL to a CPU
|
|
soaker benchmark tool on linux-kernel.</PRE>
|
|
<HR>
|
|
<H1><A name="test.freeswan">Testing FreeS/WAN</A></H1>
|
|
This document discusses testing FreeS/WAN.
|
|
<P>Not all types of testing are described here. Other parts of the
|
|
documentation describe some tests:</P>
|
|
<DL>
|
|
<DT><A href="#testinstall">installation</A> document</DT>
|
|
<DD>testing for a successful install</DD>
|
|
<DT><A href="config.html#testsetup">configuration</A> document</DT>
|
|
<DD>basic tests for a working configuration</DD>
|
|
<DT><A href="#interop.web">web links</A> document</DT>
|
|
<DD>General information on tests for interoperability between various
|
|
IPsec implementations. This includes links to several test sites.</DD>
|
|
<DT><A href="interop.html">interoperation</A> document.</DT>
|
|
<DD>More specific information on FreeS/WAN interoperation with other
|
|
implementations.</DD>
|
|
<DT><A href="performance.html">performance</A> document</DT>
|
|
<DD>performance measurements</DD>
|
|
</DL>
|
|
<P>The test setups and procedures described here can also be used in
|
|
other testing, but this document focuses on testing the IPsec
|
|
functionality of FreeS/WAN.</P>
|
|
<H2><A NAME="test.oe">Testing opportunistic connections</A></H2>
|
|
<P>This section teaches you how to test your opportunistically encrypted
|
|
(OE) connections. To set up OE, please see the easy instructions in our<A
|
|
HREF="quickstart.html"> quickstart guide</A>.</P>
|
|
<H3><A NAME="12_1_1">Basic OE Test</A></H3>
|
|
<P>This test is for basic OE functionality.
|
|
<!-- You may use it on an
|
|
<A HREF="quickstart.html#oppo.client">initiate-only OE</A> box or a
|
|
<A HREF="quickstart.html#opp.incoming">full OE</A> box. -->
|
|
For additional tests, keep
|
|
reading.</P>
|
|
<P>Be sure IPsec is running. You can see whether it is with:</P>
|
|
<PRE> ipsec setup status</PRE>
|
|
<P>If need be, you can restart it with:</P>
|
|
<PRE> service ipsec restart</PRE>
|
|
<P>Load a FreeS/WAN test website from the host on which you're running
|
|
FreeS/WAN. Note: the feds may be watching these sites. Type one of:</P>
|
|
<P></P>
|
|
<PRE> links oetest.freeswan.org</PRE>
|
|
<PRE> links oetest.freeswan.nl</PRE>
|
|
|
|
<!--<PRE> links oetest.freeswan.ca</PRE>-->
|
|
<P>A positive result looks like this:</P>
|
|
<PRE>
|
|
You seem to be connecting from: 192.0.2.11 which DNS says is:
|
|
gateway.example.com
|
|
_________________________________________________________________
|
|
|
|
Status E-route
|
|
OE enabled 16 192.139.46.73/32 -> 192.0.2.11/32 =>
|
|
[email protected]
|
|
OE enabled 176 192.139.46.77/32 -> 192.0.2.11/32 =>
|
|
[email protected]
|
|
</PRE>
|
|
<P>If you see this, congratulations! Your OE box will now encrypt its
|
|
own traffic whenever it can. If you have difficulty, see our<A HREF="#oe.trouble">
|
|
OE troubleshooting tips</A>.</P>
|
|
<H3><A NAME="12_1_2">OE Gateway Test</A></H3>
|
|
<P>If you've set up FreeS/WAN to protect a subnet behind your gateway,
|
|
you'll need to run another simple test, which can be done from a
|
|
machine running any OS. That's right, your Windows box can be protected
|
|
by opportunistic encryption without any FreeS/WAN install or
|
|
configuration on that box. From<STRONG> each protected subnet node</STRONG>
|
|
, load the FreeS/WAN website with:</P>
|
|
<PRE> links oetest.freeswan.org</PRE>
|
|
<PRE> links oetest.freeswan.nl</PRE>
|
|
<P>A positive result looks like this:</P>
|
|
<PRE>
|
|
You seem to be connecting from: 192.0.2.98 which DNS says is:
|
|
box98.example.com
|
|
_________________________________________________________________
|
|
|
|
Status E-route
|
|
OE enabled 16 192.139.46.73/32 -> 192.0.2.98/32 =>
|
|
[email protected]
|
|
OE enabled 176 192.139.46.77/32 -> 192.0.2.11/32 =>
|
|
[email protected]
|
|
</PRE>
|
|
<P>If you see this, congratulations! Your OE gateway will now encrypt
|
|
traffic for this subnet node whenever it can. If you have difficulty,
|
|
see our<A HREF="#oe.trouble"> OE troubleshooting tips</A>.</P>
|
|
<H3><A NAME="12_1_3">Additional OE tests</A></H3>
|
|
<P>When testing OE, you will often find it useful to execute this
|
|
command on the FreeS/WAN host:</P>
|
|
<PRE> ipsec eroute</PRE>
|
|
<P>If you have established a connection (either for or for a subnet
|
|
node) you will see a result like:</P>
|
|
<PRE> 192.0.2.11/32 -> 192.139.46.73/32 => [email protected]
|
|
</PRE>
|
|
<P>Key:</P>
|
|
<TABLE>
|
|
<TR><TD>1.</TD><TD>192.0.2.11/32</TD><TD>Local start point of the
|
|
protected traffic.</TD></TR>
|
|
<TR><TD>2.</TD><TD>192.0.2.194/32</TD><TD>Remote end point of the
|
|
protected traffic.</TD></TR>
|
|
<TR><TD>3.</TD><TD>192.0.48.38</TD><TD>Remote FreeS/WAN node (gateway or
|
|
host). May be the same as (2).</TD></TR>
|
|
<TR><TD>4.</TD><TD>[not shown]</TD><TD>Local FreeS/WAN node (gateway or
|
|
host), where you've produced the output. May be the same as (1).</TD></TR>
|
|
</TABLE>
|
|
<P>For extra assurance, you may wish to use a packet sniffer such as<A HREF="http://www.tcpdump.org">
|
|
tcpdump</A> to verify that packets are being encrypted. You should see
|
|
output that indicates<STRONG> ESP</STRONG> encrypted data, for example:</P>
|
|
<PRE> 02:17:47.353750 PPPoE [ses 0x1e12] IP 154: xy.example.com > oetest.freeswan.org: ESP(spi=0x87150d16,seq=0x55)</PRE>
|
|
<H2><A name="test.uml">Testing with User Mode Linux</A></H2>
|
|
<P><A href="http://user-mode-linux.sourceforge.net/">User Mode Linux</A>
|
|
allows you to run Linux as a user process on another Linux machine.</P>
|
|
<P>As of 1.92, the distribution has a new directory named testing. It
|
|
contains a collection of test scripts and sample configurations. Using
|
|
these, you can bring up several copies of Linux in user mode and have
|
|
them build tunnels to each other. This lets you do some testing of a
|
|
FreeS/WAN configuration on a single machine.</P>
|
|
<P>You need a moderately well-endowed machine for this to work well.
|
|
Each UML wants about 16 megs of memory by default, which is plenty for
|
|
FreeS/WAN usage. Typical regression testing only occasionally uses as
|
|
many as 4 UMLs. If one is doing nothing else with the machine (in
|
|
particular, not running X on it), then 128 megs and a 500MHz CPU are
|
|
fine.</P>
|
|
Documentation on these scripts is<A href="umltesting.html"> here</A>.
|
|
There is also documentation on automated testing<A href="makecheck.html">
|
|
here</A>.
|
|
<H2><A name="testnet">Configuration for a testbed network</A></H2>
|
|
<P>A common test setup is to put a machine with dual Ethernet cards in
|
|
between two gateways under test. You need at least five machines; two
|
|
gateways, two clients and a testing machine in the middle.</P>
|
|
<P>The central machine both routes packets and provides a place to run
|
|
diagnostic software for checking IPsec packets. See next section for
|
|
discussion of<A href="#tcpdump.faq"> using tcpdump(8)</A> for this.</P>
|
|
<P>This makes things more complicated than if you just connected the two
|
|
gateway machines directly to each other, but it also makes your test
|
|
setup much more like the environment you actually use IPsec in. Those
|
|
environments nearly always involve routing, and quite a few apparent
|
|
IPsec failures turn out to be problems with routing or with firewalls
|
|
dropping packets. This approach lets you deal with those problems on
|
|
your test setup.</P>
|
|
<P>What you end up with looks like:</P>
|
|
<H3><A name="testbed">Testbed network</A></H3>
|
|
<PRE> subnet a.b.c.0/24
|
|
|
|
|
eth1 = a.b.c.1
|
|
gate1
|
|
eth0 = 192.168.p.1
|
|
|
|
|
|
|
|
eth0 = 192.168.p.2
|
|
route/monitor box
|
|
eth1 = 192.168.q.2
|
|
|
|
|
|
|
|
eth0 = 192.168.q.1
|
|
gate2
|
|
eth1 = x.y.z.1
|
|
|
|
|
subnet x.y.z.0/24</PRE>
|
|
<PRE>Where p and q are any convenient values that do not interfere with other
|
|
routes you may have. The ipsec.conf(5) file then has, among other things:</PRE>
|
|
<PRE>conn abc-xyz
|
|
left=192.168.p.1
|
|
leftnexthop=192.168.p.2
|
|
right=192.168.q.1
|
|
rightnexthop=192.168.q.2</PRE>
|
|
<P>Once that works, you can remove the "route/monitor box", and connect
|
|
the two gateways to the Internet. The only parameters in ipsec.conf(5)
|
|
that need to change are the four shown above. You replace them with
|
|
values appropriate for your Internet connection, and change the eth0 IP
|
|
addresses and the default routes on both gateways.</P>
|
|
<P>Note that nothing on either subnet needs to change. This lets you
|
|
test most of your IPsec setup before connecting to the insecure
|
|
Internet.</P>
|
|
<H3><A name="tcpdump.test">Using packet sniffers in testing</A></H3>
|
|
<P>A number of tools are available for looking at packets. We will
|
|
discuss using<A href="http://www.tcpdump.org/"> tcpdump(8)</A>, a
|
|
common Linux tool included in most distributions. Alternatives
|
|
offerring more-or-less the same functionality include:</P>
|
|
<DL>
|
|
<DT><A href="http://www.ethereal.com">Ethereal</A></DT>
|
|
<DD>Several people on our mailing list report a preference for this over
|
|
tcpdump.</DD>
|
|
<DT><A href="http://netgroup-serv.polito.it/windump/">windump</A></DT>
|
|
<DD>a Windows version of tcpdump(8), possibly handy if you have Windows
|
|
boxes in your network</DD>
|
|
<DT><A href="http://reptile.rug.ac.be/~coder/sniffit/sniffit.html">
|
|
Sniffit</A></DT>
|
|
<DD>A linux sniffer that we don't know much about. If you use it, please
|
|
comment on our mailing list.</DD>
|
|
</DL>
|
|
<P>See also this<A href="http://www.tlsecurity.net/unix/ids/sniffer/">
|
|
index</A> of packet sniffers.</P>
|
|
<P>tcpdump(8) may misbehave if run on the gateways themselves. It is
|
|
designed to look into a normal IP stack and may become confused if you
|
|
ask it to display data from a stack which has IPsec in play.</P>
|
|
<P>At one point, the problem was quite severe. Recent versions of
|
|
tcpdump, however, understand IPsec well enough to be usable on a
|
|
gateway. You can get the latest version from<A href="http://www.tcpdump.org/">
|
|
tcpdump.org</A>.</P>
|
|
<P>Even with a recent tcpdump, some care is required. Here is part of a
|
|
post from Henry on the topic:</P>
|
|
<PRE>> a) data from sunset to sunrise or the other way is not being
|
|
> encrypted (I am using tcpdump (ver. 3.4) -x/ping -p to check
|
|
> packages)
|
|
|
|
What *interface* is tcpdump being applied to? Use the -i option to
|
|
control this. It matters! If tcpdump is looking at the ipsecN
|
|
interfaces, e.g. ipsec0, then it is seeing the packets before they are
|
|
encrypted or after they are decrypted, so of course they don't look
|
|
encrypted. You want to have tcpdump looking at the actual hardware
|
|
interfaces, e.g. eth0.
|
|
|
|
Actually, the only way to be *sure* what you are sending on the wire is to
|
|
have a separate machine eavesdropping on the traffic. Nothing you can do
|
|
on the machines actually running IPsec is 100% guaranteed reliable in this
|
|
area (although tcpdump is a lot better now than it used to be).</PRE>
|
|
<P>The most certain way to examine IPsec packets is to look at them on
|
|
the wire. For security, you need to be certain, so we recommend doing
|
|
that. To do so, you need a<STRONG> separate sniffer machine located
|
|
between the two gateways</STRONG>. This machine can be routing IPsec
|
|
packets, but it must not be an IPsec gateway. Network configuration for
|
|
such testing is discussed<A href="#testnet"> above</A>.</P>
|
|
<P>Here's another mailing list message with advice on using tcpdump(8):</P>
|
|
<PRE>Subject: RE: [Users] Encrypted???
|
|
Date: Thu, 29 Nov 2001
|
|
From: "Joe Patterson" <[email protected]>
|
|
|
|
tcpdump -nl -i $EXT-IF proto 50
|
|
|
|
-nl tells it not to buffer output or resolve names (if you don't do that it
|
|
may confuse you by not outputing anything for a while), -i $EXT-IF (replace
|
|
with your external interface) tells it what interface to listen on, and
|
|
proto 50 is ESP. Use "proto 51" if for some odd reason you're using AH, and
|
|
"udp port 500" if you want to see the isakmp key exchange/tunnel setup
|
|
packets.
|
|
|
|
You can also run `tcpdump -nl -i ipsec0` to see what traffic is on that
|
|
virtual interface. Anything you see there *should* be either encrypted or
|
|
dropped (unless you've turned on some strange options in your ipsec.conf
|
|
file)
|
|
|
|
Another very handy thing is ethereal (http://www.ethereal.com/) which runs
|
|
on just about anything, has a nice gui interface (or a nice text-based
|
|
interface), and does a great job of protocol breakdown. For ESP and AH
|
|
it'll basically just tell you that there's a packet of that protocol, and
|
|
what the spi is, but for isakmp it'll actually show you a lot of the tunnel
|
|
setup information (until it gets to the point in the protocol where isakmp
|
|
is encrypted....)</PRE>
|
|
<H2><A name="verify.crypt">Verifying encryption</A></H2>
|
|
<P>The question of how to verify that messages are actually encrypted
|
|
has been extensively discussed on the mailing list. See this<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00262.html">
|
|
thread</A>.</P>
|
|
<P>If you just want to verify that packets are encrypted, look at them
|
|
with a packet sniffer (see<A href="#tcpdump.test"> previous section</A>
|
|
) located between the gateways. The packets should, except for some of
|
|
the header information, be utterly unintelligible.<STRONG> The output
|
|
of good encryption looks<EM> exactly</EM> like random noise</STRONG>.</P>
|
|
<P>A packet sniffer can only tell you that the data you looked at was
|
|
encrypted. If you have stronger requirements -- for example if your
|
|
security policy requires verification that plaintext is not leaked
|
|
during startup or under various anomolous conditions -- then you will
|
|
need to devise much more thorough tests. If you do that, please post
|
|
any results or methodological details which your security policy allows
|
|
you to make public.</P>
|
|
<P>You can put recognizable data into ping packets with something like:</P>
|
|
<PRE> ping -p feedfacedeadbeef 11.0.1.1</PRE>
|
|
<P>"feedfacedeadbeef" is a legal hexadecimal pattern that is easy to
|
|
pick out of hex dumps.</P>
|
|
<P>For other protocols, you may need to check if you have encrypted data
|
|
or ASCII text. Encrypted data has approximately equal frequencies for
|
|
all 256 possible characters. ASCII text has most characters in the
|
|
printable range 0x20-0x7f, a few control characters less than 0x20, and
|
|
none at all in the range 0x80-0xff. 0x20, space, is a good character to
|
|
look for. In normal English text space occurs about once in seven
|
|
characters, versus about once in 256 for random or encrypted data.</P>
|
|
<P>One thing to watch for: the output of good compression, like that of
|
|
good encryption, looks just like random noise. You cannot tell just by
|
|
looking at a data stream whether it has been compressed, encrypted, or
|
|
both. You need a little care not to mistake compressed data for
|
|
encrypted data in your testing.</P>
|
|
<P>Note also that weak encryption also produces random-looking output.
|
|
You cannot tell whether the encryption is strong by looking at the
|
|
output. To be sure of that, you would need to have both the algorithms
|
|
and the implementation examined by experts.</P>
|
|
<P>For IPsec, you can get partial assurance from interoperability tests.
|
|
See our<A href="interop.html"> interop</A> document. When twenty
|
|
products all claim to implement<A href="#3DES"> 3DES</A>, and they all
|
|
talk to each other, you can be fairly sure they have it right. Of
|
|
course, you might wonder whether all the implementers are consipring to
|
|
trick you or, more plausibly, whether some implementations might have
|
|
"back doors" so they can get also it wrong when required.. If you're
|
|
seriously worried about things like that, you need to get the code you
|
|
use audited (good luck if it is not Open Source), or perhaps to talk to
|
|
a psychiatrist about treatments for paranoia.</P>
|
|
<H2><A name="mail.test">Mailing list pointers</A></H2>
|
|
<P>Additional information on testing can be found in these<A href="mail.html">
|
|
mailing list</A> messages:</P>
|
|
<UL>
|
|
<LI>a user's detailed<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00571.html">
|
|
setup diary</A> for his testbed network</LI>
|
|
<LI>a FreeS/WAN team member's<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00425.html">
|
|
notes</A> from testing at an IPsec interop "bakeoff"</LI>
|
|
</UL>
|
|
<HR>
|
|
<H1><A name="kernelconfig">Kernel configuration for FreeS/WAN</A></H1>
|
|
<P> This section lists many of the options available when configuring a
|
|
Linux kernel, and explains how they should be set on a FreeS/WAN IPsec
|
|
gateway.</P>
|
|
<H2><A name="notall">Not everyone needs to worry about kernel
|
|
configuration</A></H2>
|
|
<P>Note that in many cases you do not need to mess with these.</P>
|
|
<P> You may have a Linux distribution which comes with FreeS/WAN
|
|
installed (see this<A href="#products"> list</A>). In that case, you
|
|
need not do a FreeS/WAN installation or a kernel configuration. Of
|
|
course, you might still want to configure and rebuild your kernel to
|
|
improve performance or security. This can be done with standard tools
|
|
described in the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
|
|
Kernel HowTo</A>.</P>
|
|
<P>If you need to install FreeS/WAN, then you do need to configure a
|
|
kernel. However, you may choose to do that using the simplest
|
|
procedure:</P>
|
|
<UL>
|
|
<LI>Configure, build and test a kernel for your system before adding
|
|
FreeS/WAN. See the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
|
|
Kernel HowTo</A> for details.<STRONG> This step cannot be skipped</STRONG>
|
|
. FreeS/WAN needs the results of your configuration.</LI>
|
|
<LI>Then use FreeS/WAN's<VAR> make oldgo</VAR> command. This sets
|
|
everything FreeS/WAN needs and retains your values everywhere else.</LI>
|
|
</UL>
|
|
<P> This document is for those who choose to configure their FreeS/WAN
|
|
kernel themselves.</P>
|
|
<H2><A name="assume">Assumptions and notation</A></H2>
|
|
<P> Help text for most kernel options is included with the kernel files,
|
|
and is accessible from within the configuration utilities. We assume
|
|
you will refer to that, and to the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
|
|
Kernel HowTo</A>, as necessary. This document covers only the
|
|
FreeS/WAN-specific aspects of the problem.</P>
|
|
<P> To avoid duplication, this document section does not cover settings
|
|
for the additional IPsec-related kernel options which become available
|
|
after you have patched your kernel with FreeS/WAN patches. There is
|
|
help text for those available from within the configuration utility.</P>
|
|
<P> We assume a common configuration in which the FreeS/WAN IPsec
|
|
gateway is also doing ipchains(8) firewalling for a local network, and
|
|
possibly masquerading as well.</P>
|
|
<P> Some suggestions below are labelled as appropriate for "a true
|
|
paranoid". By this we mean they may cause inconvenience and it is not
|
|
entirely clear they are necessary, but they appear to be the safest
|
|
choice. Not using them might entail some risk. Of course one suggested
|
|
mantra for security administrators is: "I know I'm paranoid. I wonder
|
|
if I'm paranoid enough."</P>
|
|
<H3><A name="labels">Labels used</A></H3>
|
|
<P> Six labels are used to indicate how options should be set. We mark
|
|
the labels with [square brackets]. For two of these labels, you have no
|
|
choice:</P>
|
|
<DL>
|
|
<DT>[required]</DT>
|
|
<DD>essential for FreeS/WAN operation.</DD>
|
|
<DT>[incompatible]</DT>
|
|
<DD>incompatible with FreeS/WAN.</DD>
|
|
</DL>
|
|
<P>those must be set correctly or FreeS/WAN will not work</P>
|
|
<P>FreeS/WAN should work with any settings of the others, though of
|
|
course not all combinations have been tested. We do label these in
|
|
various ways, but<EM> these labels are only suggestions</EM>.</P>
|
|
<DL>
|
|
<DT>[recommended]</DT>
|
|
<DD>useful on most FreeS/WAN gateways</DD>
|
|
<DT>[disable]</DT>
|
|
<DD>an unwelcome complication on a FreeS/WAN gateway.</DD>
|
|
<DT>[optional]</DT>
|
|
<DD>Your choice. We outline issues you might consider.</DD>
|
|
<DT>[anything]</DT>
|
|
<DD>This option has no direct effect on FreeS/WAN and related tools, so
|
|
you should be able to set it as you please.</DD>
|
|
</DL>
|
|
<P> Of course complexity is an enemy in any effort to build secure
|
|
systems.<STRONG> For maximum security, any feature that can reasonably
|
|
be turned off should be</STRONG>. "If in doubt, leave it out."</P>
|
|
<H2><A name="kernelopt">Kernel options for FreeS/WAN</A></H2>
|
|
<P> Indentation is based on the nesting shown by 'make menuconfig' with
|
|
a 2.2.16 kernel for the i386 architecture.</P>
|
|
<DL>
|
|
<DT><A name="maturity">Code maturity and level options</A></DT>
|
|
<DD>
|
|
<DL>
|
|
<DT><A name="devel">Prompt for development ... code/drivers</A></DT>
|
|
<DD>[optional] If this is<VAR> no</VAR>, experimental drivers are not
|
|
shown in later menus.
|
|
<P>For most FreeS/WAN work,<VAR> no</VAR> is the preferred setting.
|
|
Using new or untested components is too risky for a security gateway.</P>
|
|
<P>However, for some hardware (such as the author's network cards) the
|
|
only drivers available are marked<VAR> new/experimental</VAR>. In such
|
|
cases, you must enable this option or your cards will not appear under
|
|
"network device support". A true paranoid would leave this option off
|
|
and replace the cards.</P>
|
|
</DD>
|
|
<DT>Processor type and features</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Loadable module support</DT>
|
|
<DD>
|
|
<DL>
|
|
<DT>Enable loadable module support</DT>
|
|
<DD>[optional] A true paranoid would disable this. An attacker who has
|
|
root access to your machine can fairly easily install a bogus module
|
|
that does awful things, provided modules are enabled. A common tool for
|
|
attackers is a "rootkit", a set of tools the attacker uses once he or
|
|
she has become root on your system. The kit introduces assorted
|
|
additional compromises so that the attacker will continue to "own" your
|
|
system despite most things you might do to recovery the situation. For
|
|
Linux, there is a tool called<A href="http://www.sans.org/newlook/resources/IDFAQ/knark.htm">
|
|
knark</A> which is basically a rootkit packaged as a kernel module.
|
|
<P>With modules disabled, an attacker cannot install a bogus module. The
|
|
only way he can achieve the same effects is to install a new kernel and
|
|
reboot. This is considerably more likely to be noticed.</P>
|
|
<P>Many FreeS/WAN gateways run with modules enabled. This simplifies
|
|
some administrative tasks and some ipchains features are available only
|
|
as modules. Once an enemy has root on your machine your security is
|
|
nil, so arguably defenses which come into play only in that situation
|
|
are pointless.</P>
|
|
<P></P>
|
|
</DD>
|
|
<DT>Set version information ....</DT>
|
|
<DD>[optional] This provides a check to prevent loading modules compiled
|
|
for a different kernel.</DD>
|
|
<DT>Kernel module loader</DT>
|
|
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
|
|
entails some risk.</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>General setup</DT>
|
|
<DD>We list here only the options that matter for FreeS/WAN.
|
|
<DL>
|
|
<DT>Networking support</DT>
|
|
<DD>[required]</DD>
|
|
<DT>Sysctl interface</DT>
|
|
<DD>[optional] If this option is turned on and the<VAR> /proc</VAR>
|
|
filesystem installed, then you can control various system behaviours by
|
|
writing to files under<VAR> /proc/sys</VAR>. For example:
|
|
<PRE> echo 1 > /proc/sys/net/ipv4/ipforward</PRE>
|
|
turns IP forwarding on.
|
|
<P>Disabling this option breaks many firewall scripts. A true paranoid
|
|
would disable it anyway since it might conceivably be of use to an
|
|
attacker.</P>
|
|
</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>Plug and Play support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Block devices</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Networking options</DT>
|
|
<DD>
|
|
<DL>
|
|
<DT>Packet socket</DT>
|
|
<DD>[optional] This kernel feature supports tools such as tcpdump(8)
|
|
which communicate directly with network hardware, bypassing kernel
|
|
protocols. This is very much a two-edged sword:
|
|
<UL>
|
|
<LI>such tools can be very useful to the firewall admin, especially
|
|
during initial testing</LI>
|
|
<LI>should an evildoer breach your firewall, such tools could give him
|
|
or her a great deal of information about the rest of your network</LI>
|
|
</UL>
|
|
We recommend disabling this option on production gateways.</DD>
|
|
<DT><A name="netlink">Kernel/User netlink socket</A></DT>
|
|
<DD>[optional] Required if you want to use<A href="#adv"> advanced
|
|
router</A> features.</DD>
|
|
<DT>Routing messages</DT>
|
|
<DD>[optional]</DD>
|
|
<DT>Netlink device emulation</DT>
|
|
<DD>[optional]</DD>
|
|
<DT>Network firewalls</DT>
|
|
<DD>[recommended] You need this if the IPsec gateway also functions as a
|
|
firewall.
|
|
<P>Even if the IPsec gateway is not your primary firewall, we suggest
|
|
setting this so that you can protect the gateway with at least basic
|
|
local packet filters.</P>
|
|
</DD>
|
|
<DT>Socket filtering</DT>
|
|
<DD>[disable] This enables an older filtering interface. We suggest
|
|
using ipchains(8) instead. To do that, set the "Network firewalls"
|
|
option just above, and not this one.</DD>
|
|
<DT>Unix domain sockets</DT>
|
|
<DD>[required] These sockets are used for communication between the<A href="manpage.d/ipsec.8.html">
|
|
ipsec(8)</A> commands and the<A href="manpage.d/ipsec_pluto.8.html">
|
|
ipsec_pluto(8)</A> daemon.</DD>
|
|
<DT>TCP/IP networking</DT>
|
|
<DD>[required]
|
|
<DL>
|
|
<DT>IP: multicasting</DT>
|
|
<DD>[anything]</DD>
|
|
<DT><A name="adv">IP: advanced router</A></DT>
|
|
<DD>[optional] This gives you policy routing, which some people have
|
|
used to good advantage in their scripts for FreeS/WAN gateway
|
|
management. It is not used in our distributed scripts, so not required
|
|
unless you want it for custom scripts. It requires the<A href="#netlink">
|
|
netlink</A> interface between kernel code and the iproute2(8) command.</DD>
|
|
<DT>IP: kernel level autoconfiguration</DT>
|
|
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
|
|
entails some risk.</DD>
|
|
<DT>IP: firewall packet netlink device</DT>
|
|
<DD>[disable]</DD>
|
|
<DT>IP: transparent proxy support</DT>
|
|
<DD>[optional] This is required in some firewall configurations, but
|
|
should be disabled unless you have a definite need for it.</DD>
|
|
<DT>IP: masquerading</DT>
|
|
<DD>[optional] Required if you want to use<A href="#non-routable">
|
|
non-routable</A> private IP addresses for your local network.</DD>
|
|
<DT>IP: Optimize as router not host</DT>
|
|
<DD>[recommended]</DD>
|
|
<DT>IP: tunneling</DT>
|
|
<DD>[required]</DD>
|
|
<DT>IP: GRE tunnels over IP</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>IP: aliasing support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>IP: ARP daemon support (EXPERIMENTAL)</DT>
|
|
<DD>Not required on most systems, but might prove useful on
|
|
heavily-loaded gateways.</DD>
|
|
<DT>IP: TCP syncookie support</DT>
|
|
<DD>[recommended] It provides a defense against a<A href="#DOS"> denial
|
|
of service attack</A> which uses bogus TCP connection requests to waste
|
|
resources on the victim machine.</DD>
|
|
<DT>IP: Reverse ARP</DT>
|
|
<DD></DD>
|
|
<DT>IP: large window support</DT>
|
|
<DD>[recommended] unless you have less than 16 meg RAM</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>IPv6</DT>
|
|
<DD>[optional] FreeS/WAN does not currently support IPv6, though work on
|
|
integrating FreeS/WAN with the Linux IPv6 stack has begun.<A href="#ipv6">
|
|
Details</A>.
|
|
<P> It should be possible to use IPv4 FreeS/WAN on a machine which also
|
|
does IPv6. This combination is not yet well tested. We would be quite
|
|
interested in hearing results from anyone expermenting with it, via the<A
|
|
href="mail.html"> mailing list</A>.</P>
|
|
<P> We do not recommend using IPv6 on production FreeS/WAN gateways
|
|
until more testing has been done.</P>
|
|
</DD>
|
|
<DT>Novell IPX</DT>
|
|
<DD>[disable]</DD>
|
|
<DT>Appletalk</DT>
|
|
<DD>[disable] Quite a few Linux installations use IP but also have some
|
|
other protocol, such as Appletalk or IPX, for communication with local
|
|
desktop machines. In theory it should be possible to configure IPsec
|
|
for the IP side of things without interfering with the second protocol.
|
|
<P>We do not recommend this. Keep the software on your gateway as simple
|
|
as possible. If you need a Linux-based Appletalk or IPX server, use a
|
|
separate machine.</P>
|
|
</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>Telephony support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>SCSI support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>I2O device support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Network device support</DT>
|
|
<DD>[anything] should work, but there are some points to note.
|
|
<P>The development team test almost entirely on 10 or 100 megabit
|
|
Ethernet and modems. In principle, any device that can do IP should be
|
|
just fine for IPsec, but in the real world any device that has not been
|
|
well-tested is somewhat risky. By all means try it, but don't bet your
|
|
project on it until you have solid test results.</P>
|
|
<P>If you disabled experimental drivers in the<A href="#maturity"> Code
|
|
maturity</A> section above, then those drivers will not be shown here.
|
|
Check that option before going off to hunt for missing drivers.</P>
|
|
<P>If you want Linux to automatically find more than one ethernet
|
|
interface at boot time, you need to:</P>
|
|
<UL>
|
|
<LI>compile the appropriate driver(s) into your kernel. Modules will not
|
|
work for this</LI>
|
|
<LI>add a line such as
|
|
<PRE>
|
|
append="ether=0,0,eth0 ether=0,0,eth1"
|
|
</PRE>
|
|
to your /etc/lilo.conf file. In some cases you may need to specify
|
|
parameters such as IRQ or base address. The example uses "0,0" for
|
|
these, which tells the system to search. If the search does not succeed
|
|
on your hardware, then you should retry with explicit parameters. See
|
|
the lilo.conf(5) man page for details.</LI>
|
|
<LI>run lilo(8)</LI>
|
|
</UL>
|
|
Having Linux find the cards this way is not necessary, but is usually
|
|
more convenient than loading modules in your boot scripts.</DD>
|
|
<DT>Amateur radio support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>IrDA (infrared) support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>ISDN subsystem</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Old CDROM drivers</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Character devices</DT>
|
|
<DD>The only required character device is:
|
|
<DL>
|
|
<DT>random(4)</DT>
|
|
<DD>[required] This is a source of<A href="#random"> random</A> numbers
|
|
which are required for many cryptographic protocols, including several
|
|
used in IPsec.
|
|
<P>If you are comfortable with C source code, it is likely a good idea
|
|
to go in and adjust the<VAR> #define</VAR> lines in<VAR>
|
|
/usr/src/linux/drivers/char/random.c</VAR> to ensure that all sources
|
|
of randomness are enabled. Relying solely on keyboard and mouse
|
|
randomness is dubious procedure for a gateway machine. You could also
|
|
increase the randomness pool size from the default 512 bytes (128
|
|
32-bit words).</P>
|
|
</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>Filesystems</DT>
|
|
<DD>[anything] should work, but we suggest limiting a gateway machine to
|
|
the standard Linux ext2 filesystem in most cases.</DD>
|
|
<DT>Network filesystems</DT>
|
|
<DD>[disable] These systems are an unnecessary risk on an IPsec gateway.</DD>
|
|
<DT>Console drivers</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Sound</DT>
|
|
<DD>[anything] should work, but we suggest enabling sound only if you
|
|
plan to use audible alarms for firewall problems.</DD>
|
|
<DT>Kernel hacking</DT>
|
|
<DD>[disable] This might be enabled on test machines, but should not be
|
|
on production gateways.</DD>
|
|
</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
<H1><A name="adv_config">Other configuration possibilities</A></H1>
|
|
<P>This document describes various options for FreeS/WAN configuration
|
|
which are less used or more complex (often both) than the standard
|
|
cases described in our<A href="#config"> config</A> and<A href="#quick_guide">
|
|
quickstart</A> documents.</P>
|
|
<H2><A name="thumb">Some rules of thumb about configuration</A></H2>
|
|
<H3><A name="cheap.tunnel">Tunnels are cheap</A></H3>
|
|
<P>Nearly all of the overhead in IPsec processing is in the encryption
|
|
and authentication of packets. Our<A href="performance.html">
|
|
performance</A> document discusses these overheads.</P>
|
|
<P>Beside those overheads, the cost of managing additional tunnels is
|
|
trivial. Whether your gateway supports one tunnel or ten just does not
|
|
matter. A hundred might be a problem; there is a<A href="#biggate">
|
|
section</A> on this in the performance document.</P>
|
|
<P>So, in nearly all cases, if using multiple tunnels gives you a
|
|
reasonable way to describe what you need to do, you should describe it
|
|
that way in your configuration files.</P>
|
|
<P>For example, one user recently asked on a mailing list about this
|
|
network configuration:</P>
|
|
<PRE> netA---gwA---gwB---netB
|
|
|----netC
|
|
|
|
netA and B are secured netC not.
|
|
netA and gwA can not access netC</PRE>
|
|
<P>The user had constructed only one tunnel, netA to netB, and wanted to
|
|
know how to use ip-route to get netC packets into it. This is entirely
|
|
unnecessary. One of the replies was:</P>
|
|
<PRE> The simplest way and indeed the right way to
|
|
solve this problem is to set up two connections:
|
|
|
|
leftsubnet=NetA
|
|
left=gwA
|
|
right=gwB
|
|
rightsubnet=NetB
|
|
and
|
|
leftsubnet=NetA
|
|
left=gwA
|
|
right=gwB
|
|
rightsubnet=NetC</PRE>
|
|
<P>This would still be correct even if we added nets D, E, F, ... to the
|
|
above diagram and needed twenty tunnels.</P>
|
|
<P>Of course another possibility would be to just use one tunnel, with a
|
|
subnet mask that includes both netB and netC (or B, C, D, ...). See
|
|
next section.</P>
|
|
<P>In general, you can construct as many tunnels as you need. Networks
|
|
like netC in this example that do not connect directly to the gateway
|
|
are fine, as long as the gateway can route to them.</P>
|
|
<P>The number of tunnels can become an issue if it reaches 50 or so.
|
|
This is discussed in the<A href="#biggate"> performance</A> document.
|
|
Look there for information on supporting hundreds of Road Warriors from
|
|
one gateway.</P>
|
|
<P>If you find yourself with too many tunnels for some reason like
|
|
having eight subnets at one location and nine at another so you end up
|
|
with 9*8=72 tunnels, read the next section here.</P>
|
|
<H3><A name="subnet.size">Subnet sizes</A></H3>
|
|
<P>The subnets used in<VAR> leftsubnet</VAR> and<VAR> rightsubnet</VAR>
|
|
can be of any size that fits your needs, and they need not correspond
|
|
to physical networks.</P>
|
|
<P>You adjust the size by changing the<A href="#subnet"> subnet mask</A>
|
|
, the number after the slash in the subnet description. For example</P>
|
|
<UL>
|
|
<LI>in 192.168.100.0/24 the /24 mask says 24 bits are used to designate
|
|
the network. This leave 8 bits to label machines. This subnet has 256
|
|
addresses. .0 and .255 are reserved, so it can have 254 machines.</LI>
|
|
<LI>A subnet with a /23 mask would be twice as large, 512 addresses.</LI>
|
|
<LI>A subnet with a /25 mask would be half the size, 128 addresses.</LI>
|
|
<LI>/0 is the whole Internet</LI>
|
|
<LI>/32 is a single machine</LI>
|
|
</UL>
|
|
<P>As an example of using these in connection descriptions, suppose your
|
|
company's head office has four physical networks using the address
|
|
ranges:</P>
|
|
<DL>
|
|
<DT>192.168.100.0/24</DT>
|
|
<DD>development</DD>
|
|
<DT>192.168.101.0/24</DT>
|
|
<DD>production</DD>
|
|
<DT>192.168.102.0/24</DT>
|
|
<DD>marketing</DD>
|
|
<DT>192.168.103.0/24</DT>
|
|
<DD>administration</DD>
|
|
</DL>
|
|
<P>You can use exactly those subnets in your connection descriptions, or
|
|
use larger subnets to grant broad access if required:</P>
|
|
<DL>
|
|
<DT>leftsubnet=192.168.100.0/24</DT>
|
|
<DD>remote hosts can access only development</DD>
|
|
<DT>leftsubnet=192.168.100.0/23</DT>
|
|
<DD>remote hosts can access development or production</DD>
|
|
<DT>leftsubnet=192.168.102.0/23</DT>
|
|
<DD>remote hosts can access marketing or administration</DD>
|
|
<DT>leftsubnet=192.168.100.0/22</DT>
|
|
<DD>remote hosts can access any of the four departments</DD>
|
|
</DL>
|
|
<P>or use smaller subnets to restrict access:</P>
|
|
<DL>
|
|
<DT>leftsubnet=192.168.103.0/24</DT>
|
|
<DD>remote hosts can access any machine in administration</DD>
|
|
<DT>leftsubnet=192.168.103.64/28</DT>
|
|
<DD>remote hosts can access only certain machines in administration.</DD>
|
|
<DT>leftsubnet=192.168.103.42/32</DT>
|
|
<DD>remote hosts can access only one particular machine in
|
|
administration</DD>
|
|
</DL>
|
|
<P>To be exact, 192.68.103.64/28 means all addresses whose top 28 bits
|
|
match 192.168.103.64. There are 16 of these because there are 16
|
|
possibilities for the remainingg 4 bits. Their addresses are
|
|
192.168.103.64 to 192.168.103.79.</P>
|
|
<P>Each connection description can use a different subnet if required.</P>
|
|
<P>It is possible to use all the examples above on the same FreeS/WAN
|
|
gateway, each in a different connection description, perhaps for
|
|
different classes of user or for different remote offices.</P>
|
|
<P>It is also possible to have multiple tunnels using different<VAR>
|
|
leftsubnet</VAR> descriptions with the same<VAR> right</VAR>. For
|
|
example, when the marketing manager is on the road he or she might have
|
|
access to:</P>
|
|
<DL>
|
|
<DT>leftsubnet=192.168.102.0/24</DT>
|
|
<DD>all machines in marketing</DD>
|
|
<DT>192.168.101.32/29</DT>
|
|
<DD>some machines in production</DD>
|
|
<DT>leftsubnet=192.168.103.42/32</DT>
|
|
<DD>one particular machine in administration</DD>
|
|
</DL>
|
|
<P>This takes three tunnels, but tunnels are cheap. If the laptop is set
|
|
up to build all three tunnels automatically, then he or she can access
|
|
all these machines concurrently, perhaps from different windows.</P>
|
|
<H3><A name="example.more">Other network layouts</A></H3>
|
|
<P>Here is the usual network picture for a site-to-site VPN::</P>
|
|
<PRE> Sunset==========West------------------East=========Sunrise
|
|
local net untrusted net local net</PRE>
|
|
<P>and for the Road Warrior::</P>
|
|
<PRE> telecommuter's PC or
|
|
traveller's laptop
|
|
Sunset==========West------------------East
|
|
corporate LAN untrusted net</PRE>
|
|
<P>Other configurations are also possible.</P>
|
|
<H4><A name="internet.subnet">The Internet as a big subnet</A></H4>
|
|
<P>A telecommuter might have:</P>
|
|
<PRE> Sunset==========West------------------East ================= firewall --- the Internet
|
|
home network untrusted net corporate network</PRE>
|
|
<P>This can be described as a special case of the general
|
|
subnet-to-subnet connection. The subnet on the right is 0.0.0.0/0, the
|
|
whole Internet.</P>
|
|
<P>West (the home gateway) can have its firewall rules set up so that
|
|
only IPsec packets to East are allowed out. It will then behave as if
|
|
its only connection to the world was a wire to East.</P>
|
|
<P>When machines on the home network need to reach the Internet, they do
|
|
so via the tunnel, East and the corporate firewall. From the viewpoint
|
|
of the Internet (perhaps of some EvilDoer trying to break in!), those
|
|
home office machines are behind the firewall and protected by it.</P>
|
|
<H4><A name="wireless.config">Wireless</A></H4>
|
|
<P>Another possible configuration comes up when you do not trust the
|
|
local network, either because you have very high security standards or
|
|
because your are using easily-intercepted wireless signals.</P>
|
|
<P>Some wireless networks have built-in encryption called<A href="#WEP">
|
|
WEP</A>, but its security is dubious. It is a fairly common practice to
|
|
use IPsec instead.</P>
|
|
<P>In this case, part of your network may look like this:</P>
|
|
<PRE> West-----------------------------East == the rest of your network
|
|
workstation untrusted wireless net</PRE>
|
|
<P>Of course, there would likely be several wireless workstations, each
|
|
with its own IPsec tunnel to the East gateway.</P>
|
|
<P>The connection descriptions look much like Road Warrior descriptions:</P>
|
|
<UL>
|
|
<LI>each workstation should have its own unique
|
|
<UL>
|
|
<LI>identifier for IPsec</LI>
|
|
<LI>RSA key</LI>
|
|
<LI>connection description.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>on the gateway, use<VAR> left=%any</VAR>, or the workstation IP
|
|
address</LI>
|
|
<LI>on workstations,<VAR> left=%defaultroute</VAR>, or the workstation
|
|
IP address</LI>
|
|
<LI><VAR>leftsubnet=</VAR> is not used.</LI>
|
|
</UL>
|
|
<P>The<VAR> rightsubnet=</VAR> parameter might be set in any of several
|
|
ways:</P>
|
|
<DL>
|
|
<DT>rightsubnet=0.0.0.0/0</DT>
|
|
<DD>allowing workstations to access the entire Internet (see<A href="#internet.subnet">
|
|
above</A>)</DD>
|
|
<DT>rightsubnet=a.b.c.0/24</DT>
|
|
<DD>allowing access to your entire local network</DD>
|
|
<DT>rightsubnet=a.b.c.d/32</DT>
|
|
<DD>restricting the workstation to connecting to a particular server</DD>
|
|
</DL>
|
|
<P>Of course you can mix and match these as required. For example, a
|
|
university might allow faculty full Internet access while letting
|
|
student laptops connect only to a group of lab machines.</P>
|
|
<H2><A name="choose">Choosing connection types</A></H2>
|
|
<P>One choice you need to make before configuring additional connections
|
|
is what type or types of connections you will use. There are several
|
|
options, and you can use more than one concurrently.</P>
|
|
<H3><A name="man-auto">Manual vs. automatic keying</A></H3>
|
|
<P>IPsec allows two types of connections, with manual or automatic
|
|
keying. FreeS/WAN starts them with commands such as:</P>
|
|
<PRE> ipsec manual --up <VAR>name</VAR>
|
|
ipsec auto --up <VAR>name</VAR></PRE>
|
|
<P>The difference is in how they are keyed.</P>
|
|
<DL>
|
|
<DT><A href="#manual">Manually keyed</A> connections</DT>
|
|
<DD>use keys stored in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A>
|
|
.</DD>
|
|
<DT><A href="#auto">Automatically keyed</A> connections</DT>
|
|
<DD>use keys automatically generated by the Pluto key negotiation
|
|
daemon. The key negotiation protocol,<A href="#IKE"> IKE</A>, must
|
|
authenticate the other system. (It is vulnerable to a<A href="#middle">
|
|
man-in-the-middle attack</A> if used without authentication.) We
|
|
currently support two authentication methods:
|
|
<UL>
|
|
<LI>using shared secrets stored in<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets</A>.</LI>
|
|
<LI>RSA<A href="#public"> public key</A> authentication, with our
|
|
machine's private key in<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets</A>. Public keys for other machines may either be placed
|
|
in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A> or provided via
|
|
DNS.</LI>
|
|
</UL>
|
|
<P>A third method, using RSA keys embedded in<A href="#X509"> X.509</A>
|
|
certtificates, is provided by user<A href="#patch"> patches</A>.</P>
|
|
</DD>
|
|
</DL>
|
|
<P><A href="#manual">Manually keyed</A> connections provide weaker
|
|
security than<A href="#auto"> automatically keyed</A> connections. An
|
|
opponent who reads ipsec.secrets(5) gets your encryption key and can
|
|
read all data encrypted by it. If he or she has an archive of old
|
|
messages, all of them back to your last key change are also readable.</P>
|
|
<P>With automatically-(re)-keyed connections, an opponent who reads
|
|
ipsec.secrets(5) gets the key used to authenticate your system in IKE
|
|
-- the shared secret or your private key, depending what authentication
|
|
mechanism is in use. However, he or she does not automatically gain
|
|
access to any encryption keys or any data.</P>
|
|
<P>An attacker who has your authentication key can mount a<A href="#middle">
|
|
man-in-the-middle attack</A> and, if that succeeds, he or she will get
|
|
encryption keys and data. This is a serious danger, but it is better
|
|
than having the attacker read everyting as soon as he or she breaks
|
|
into ipsec.secrets(5).. Moreover, the keys change often so an opponent
|
|
who gets one key does not get a large amount of data. To read all your
|
|
data, he or she would have to do a man-in-the-middle attack at every
|
|
key change.</P>
|
|
<P>We discuss using<A href="#prodman"> manual keying in production</A>
|
|
below, but this is<STRONG> not recommended</STRONG> except in special
|
|
circumstances, such as needing to communicate with some implementation
|
|
that offers no auto-keyed mode compatible with FreeS/WAN.</P>
|
|
<P>Manual keying may also be useful for testing. There is some
|
|
discussion of this in our<A href="#man4debug"> FAQ</A>.</P>
|
|
<H3><A name="auto-auth">Authentication methods for auto-keying</A></H3>
|
|
<P>The IKE protocol which Pluto uses to negotiate connections between
|
|
gateways must use some form of authentication of peers. A gateway must
|
|
know who it is talking to before it can create a secure connection. We
|
|
support two basic methods for this authentication:</P>
|
|
<UL>
|
|
<LI>shared secrets, stored in<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets(5)</A></LI>
|
|
<LI>RSA authentication</LI>
|
|
</UL>
|
|
<P>There are, howver, several variations on the RSA theme, using
|
|
different methods of managing the RSA keys:</P>
|
|
<UL>
|
|
<LI>our RSA private key in<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets(5)</A> with other gateways' public keys
|
|
<DL>
|
|
<DT>either</DT>
|
|
<DD>stored in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A></DD>
|
|
<DT>or</DT>
|
|
<DD>looked up via<A href="#DNS"> DNS</A></DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>authentication with<A href="#X509"> x.509</A> certificates.; See our<A
|
|
href="#patch"> links section</A> for information on user-contributed
|
|
patches for this.:</LI>
|
|
</UL>
|
|
<P>Public keys in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5</A>
|
|
) give a reasonably straightforward method of specifying keys for
|
|
explicitly configured connections.</P>
|
|
<P>Putting public keys in DNS allows us to support<A href="#carpediem">
|
|
opportunistic encryption</A>. Any two FreeS/WAN gateways can provide
|
|
secure communication, without either of them having any preset
|
|
information about the other.</P>
|
|
<P>X.509 certificates may be required to interface to various<A href="#PKI">
|
|
PKI</A>s.</P>
|
|
<H3><A name="adv-pk">Advantages of public key methods</A></H3>
|
|
<P>Authentication with a<A href="#public"> public key</A> method such as<A
|
|
href="#RSA"> RSA</A> has some important advantages over using shared
|
|
secrets.</P>
|
|
<UL>
|
|
<LI>no problem of secure transmission of secrets
|
|
<UL>
|
|
<LI>A shared secret must be shared, so you have the problem of
|
|
transmitting it securely to the other party. If you get this wrong, you
|
|
have no security.</LI>
|
|
<LI>With a public key technique, you transmit only your public key. The
|
|
system is designed to ensure that it does not matter if an enemy
|
|
obtains public keys. The private key never leaves your machine.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>easier management
|
|
<UL>
|
|
<LI>Suppose you have 20 branch offices all connecting to one gateway at
|
|
head office, and all using shared secrets. Then the head office admin
|
|
has 20 secrets to manage. Each of them must be kept secret not only
|
|
from outsiders, but also from 19 of the branch office admins. The
|
|
branch office admins have only one secret each to manage.
|
|
<P>If the branch offices need to talk to each other, this becomes
|
|
problematic. You need another 20*19/2 = 190 secrets for
|
|
branch-to-branch communication, each known to exactly two branches. Now
|
|
all the branch admins have the headache of handling 20 keys, each
|
|
shared with exactly one other branch or with head office.</P>
|
|
<P>For larger numbers of branches, the number of connections and secrets
|
|
increases quadratically and managing them becomes a nightmare. A
|
|
1000-gateway fully connected network needs 499,500 secrets, each known
|
|
to exactly two players. There are ways to reduce this problem, for
|
|
example by introducing a central key server, but these involve
|
|
additional communication overheads, more administrative work, and new
|
|
threats that must be carefully guarded against.</P>
|
|
</LI>
|
|
<LI>With public key techniques, the<EM> only</EM> thing you have to keep
|
|
secret is your private key, and<EM> you keep that secret from everyone</EM>
|
|
.
|
|
<P>As network size increaes, the number of public keys used increases
|
|
linearly with the number of nodes. This still requires careful
|
|
administration in large applications, but is nothing like the disaster
|
|
of a quadratic increase. On a 1000-gateway network, you have 1000
|
|
private keys, each of which must be kept secure on one machine, and
|
|
1000 public keys which must be distributed. This is not a trivial
|
|
problem, but it is manageable.</P>
|
|
</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>does not require fixed IP addresses
|
|
<UL>
|
|
<LI>When shared secrets are used in IPsec, the responder must be able to
|
|
tell which secret to use by looking at the IP address on the incoming
|
|
packets. When the other parties do not have a fixed IP address to be
|
|
identified by (for example, on nearly all dialup ISP connections and
|
|
many cable or ADSL links), this does not work well -- all must share
|
|
the same secret!</LI>
|
|
<LI>When RSA authentication is in use, the initiator can identify itself
|
|
by name before the key must be determined. The responder then checks
|
|
that the message is signed with the public key corresponding to that
|
|
name.</LI>
|
|
</UL>
|
|
</LI>
|
|
</UL>
|
|
<P>There is also a disadvantage:</P>
|
|
<UL>
|
|
<LI>your private key is a single point of attack, extremely valuable to
|
|
an enemy
|
|
<UL>
|
|
<LI>with shared secrets, an attacker who steals your ipsec.secrets file
|
|
can impersonate you or try<A href="#middle"> man-in-the-middle</A>
|
|
attacks, but can only attack connections described in that file</LI>
|
|
<LI>an attacker who steals your private key gains the chance to attack
|
|
not only existing connections<EM> but also any future connections</EM>
|
|
created using that key</LI>
|
|
</UL>
|
|
</LI>
|
|
</UL>
|
|
<P>This is partly counterbalanced by the fact that the key is never
|
|
transmitted and remains under your control at all times. It is likely
|
|
necessary, however, to take account of this in setting security policy.
|
|
For example, you should change gateway keys when an administrator
|
|
leaves the company, and should change them periodically in any case.</P>
|
|
<P>Overall, public key methods are<STRONG> more secure, more easily
|
|
managed and more flexible</STRONG>. We recommend that they be used for
|
|
all connections, unless there is a compelling reason to do otherwise.</P>
|
|
<H2><A name="prodsecrets">Using shared secrets in production</A></H2>
|
|
<P>Generally, public key methods are preferred for reasons given above,
|
|
but shared secrets can be used with no loss of security, just more work
|
|
and perhaps more need to take precautions.</P>
|
|
<P>What I call "shared secrets" are sometimes also called "pre-shared
|
|
keys". They are used only for for authentication, never for encryption.
|
|
Calling them "pre-shared keys" has confused some users into thinking
|
|
they were encryption keys, so I prefer to avoid the term..</P>
|
|
<P>If you are interoperating with another IPsec implementation, you may
|
|
find its documentation calling them "passphrases".</P>
|
|
<H3><A name="secrets">Putting secrets in ipsec.secrets(5)</A></H3>
|
|
<P>If shared secrets are to be used to<A href="#authentication">
|
|
authenticate</A> communication for the<A href="#DH"> Diffie-Hellman</A>
|
|
key exchange in the<A href="#IKE"> IKE</A> protocol, then those secrets
|
|
must be stored in<VAR> /etc/ipsec.secrets</VAR>. For details, see the<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets(5)</A> man page.</P>
|
|
<P>A few considerations are vital:</P>
|
|
<UL>
|
|
<LI>make the secrets long and unguessable. Since they need not be
|
|
remembered by humans, very long ugly strings may be used. We suggest
|
|
using our<A href="manpage.d/ipsec_ranbits.8.html"> ipsec_ranbits(8)</A>
|
|
utility to generate long (128 bits or more) random strings.</LI>
|
|
<LI>transmit secrets securely. You have to share them with other
|
|
systems, but you lose if they are intercepted and used against you. Use<A
|
|
href="#PGP"> PGP</A>,<A href="#ssh"> SSH</A>, hand delivery of a floppy
|
|
disk which is then destroyed, or some other trustworthy method to
|
|
deliver them.</LI>
|
|
<LI>store secrets securely, in root-owned files with permissions
|
|
rw------.</LI>
|
|
<LI>limit sharing of secrets. Alice, Bob, Carol and Dave may all talk to
|
|
each other, but only Alice and Bob should know the secret for an
|
|
Alice-Bob link.</LI>
|
|
<LI><STRONG>do not share private keys</STRONG>. The private key for RSA
|
|
authentication of your system is stored in<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets(5)</A>, but it is a different class of secret from the
|
|
pre-shared keys used for the "shared secret" authentication. No-one but
|
|
you should have the RSA private key.</LI>
|
|
</UL>
|
|
<P>Each line has the IP addresses of the two gateways plus the secret.
|
|
It should look something like this:</P>
|
|
<PRE> 10.0.0.1 11.0.0.1 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"</PRE>
|
|
<P><VAR>PSK</VAR> indicates the use of a<STRONG> p</STRONG>re-<STRONG>s</STRONG>
|
|
hared<STRONG> k</STRONG>ey. The quotes and the whitespace shown are
|
|
required.</P>
|
|
<P>You can use any character string as your secret. For security, it
|
|
should be both long and extremely hard to guess. We provide a utility
|
|
to generate such strings,<A href="manpage.d/ipsec_ranbits.8.html">
|
|
ipsec_ranbits(8)</A>.</P>
|
|
<P>You want the same secret on the two gateways used, so you create a
|
|
line with that secret and the two gateway IP addresses. The
|
|
installation process supplies an example secret, useful<EM> only</EM>
|
|
for testing. You must change it for production use.</P>
|
|
<H3><A name="securing.secrets">File security</A></H3>
|
|
<P>You must deliver this file, or the relevant part of it, to the other
|
|
gateway machine by some<STRONG> secure</STRONG> means.<EM> Don't just
|
|
FTP or mail the file!</EM> It is vital that the secrets in it remain
|
|
secret. An attacker who knew those could easily have<EM> all the data
|
|
on your "secure" connection</EM>.</P>
|
|
<P>This file must be owned by root and should have permissions<VAR>
|
|
rw-------</VAR>.</P>
|
|
<H3><A name="notroadshared">Shared secrets for road warriors</A></H3>
|
|
<P>You can use a shared secret to support a single road warrior
|
|
connecting to your gateway, and this is a reasonable thing to do in
|
|
some circumstances. Public key methods have advantages, discussed<A href="#choose">
|
|
above</A>, but they are not critical in this case.</P>
|
|
<P>To do this, the line in ipsec.secrets(5) is something like:</P>
|
|
<PRE> 10.0.0.1 0.0.0.0 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"</PRE>
|
|
where the<VAR> 0.0.0.0</VAR> means that any IP address is acceptable.
|
|
<P><STRONG>For more than one road warrior, shared secrets are<EM> not</EM>
|
|
recommended.</STRONG> If shared secrets are used, then when the
|
|
responder needs to look up the secret, all it knows about the sender is
|
|
an IP address. This is fine if the sender is at a fixed IP address
|
|
specified in the config file. It is also fine if only one road warrior
|
|
uses the wildcard<VAR> 0.0.0.0</VAR> address. However, if you have more
|
|
than one road warrior using shared secret authentication, then they
|
|
must all use that wildcard and therefore<STRONG> all road warriors
|
|
using PSK autentication must use the same secret</STRONG>. Obviously,
|
|
this is insecure.</P>
|
|
<P><STRONG>For multiple road warriors, use public key authentication.</STRONG>
|
|
Each roadwarrior can then have its own identity (our<VAR> leftid=</VAR>
|
|
or<VAR> rightid=</VAR> parameters), its own public/private key pair,
|
|
and its own secure connection.</P>
|
|
<H2><A name="prodman">Using manual keying in production</A></H2>
|
|
<P>Generally,<A href="#auto"> automatic keying</A> is preferred over<A href="#manual">
|
|
manual keying</A> for production use because it is both easier to
|
|
manage and more secure. Automatic keying frees the admin from much of
|
|
the burden of managing keys securely, and can provide<A href="#PFS">
|
|
perfect forward secrecy</A>. This is discussed in more detail<A href="#man-auto">
|
|
above</A>.</P>
|
|
<P>However, it is possible to use manual keying in production if that is
|
|
what you want to do. This might be necessary, for example, in order to
|
|
interoperate with some device that either does not provide automatic
|
|
keying or provides it in some version we cannot talk to.</P>
|
|
<P>Note that with manual keying<STRONG> all security rests with the keys</STRONG>
|
|
. If an adversary acquires your keys, you've had it. He or she can read
|
|
everything ever sent with those keys, including old messages he or she
|
|
may have archived.</P>
|
|
<P>You need to<STRONG> be really paranoid about keys</STRONG> if you're
|
|
going to rely on manual keying for anything important.</P>
|
|
<UL>
|
|
<LI>keep keys in files with 600 permissions, owned by root</LI>
|
|
<LI>be extremely careful about security of your gateway systems. Anyone
|
|
who breaks into a gateway and gains root privileges can get all your
|
|
keys and read everything ever encrypted with those keys, both old
|
|
messages he has archived and any new ones you may send.</LI>
|
|
<LI>change keys regularly. This can be a considerable bother, (and
|
|
provides an excellent reason to consider automatic keying instead), but
|
|
it is<EM> absolutely essential</EM> for security. Consider a manually
|
|
keyed system in which you leave the same key in place for months:
|
|
<UL>
|
|
<LI>an attacker can have a very large sample of text sent with that key
|
|
to work with. This makes various cryptographic attacks much more likely
|
|
to succeed.</LI>
|
|
<LI>The chances of the key being compromised in some non-cryptographic
|
|
manner -- a spy finds it on a discarded notepad, someone breaks into
|
|
your server or your building and steals it, a staff member is bribed,
|
|
tricked, seduced or coerced into revealing it, etc. -- also increase
|
|
over time.</LI>
|
|
<LI>a successful attacker can read everything ever sent with that key.
|
|
This makes any successful attack extremely damaging.</LI>
|
|
</UL>
|
|
It is clear that you must change keys often to have any useful
|
|
security. The only question is how often.</LI>
|
|
<LI>use<A href="#PGP"> PGP</A> or<A href="#ssh"> SSH</A> for all key
|
|
transfers</LI>
|
|
<LI>don't edit files with keys in them when someone can look over your
|
|
shoulder</LI>
|
|
<LI>worry about network security; could someone get keys by snooping
|
|
packets on the LAN between your X desktop and the gateway?</LI>
|
|
<LI>lock up your backup tapes for the gateway system</LI>
|
|
<LI>... and so on</LI>
|
|
</UL>
|
|
<P>Linux FreeS/WAN provides some facilities to help with this. In
|
|
particular, it is good policy to<STRONG> keep keys in separate files</STRONG>
|
|
so you can edit configuration information in /etc/ipsec.conf without
|
|
exposing keys to "shoulder surfers" or network snoops. We support this
|
|
with the<VAR> also=</VAR> and<VAR> include</VAR> syntax in<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A>.</P>
|
|
<P>See the last example in our<A href="examples"> examples</A> file. In
|
|
the /etc/ipsec.conf<VAR> conn samplesep</VAR> section, it has the line:</P>
|
|
<PRE> also=samplesep-keys</PRE>
|
|
<P>which tells the "ipsec manual" script to insert the configuration
|
|
description labelled "samplesep-keys" if it can find it. The
|
|
/etc/ipsec.conf file must also have a line such as:</P>
|
|
<PRE>include ipsec.*.conf</PRE>
|
|
<P>which tells it to read other files. One of those other files then
|
|
might contain the additional data:</P>
|
|
<PRE>conn samplesep-keys
|
|
spi=0x200
|
|
esp=3des-md5-96
|
|
espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
|
|
espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf</PRE>
|
|
<P>The first line matches the label in the "also=" line, so the indented
|
|
lines are inserted. The net effect is exactly as if the inserted lines
|
|
had occurred in the original file in place of the "also=" line.</P>
|
|
<P>Variables set here are:</P>
|
|
<DL>
|
|
<DT>spi</DT>
|
|
<DD>A number needed by the manual keying code. Any 3-digit hex number
|
|
will do, but if you have more than one manual connection then<STRONG>
|
|
spi must be different</STRONG> for each connection.</DD>
|
|
<DT>esp</DT>
|
|
<DD>Options for<A href="#ESP"> ESP</A> (Encapsulated Security Payload),
|
|
the usual IPsec encryption mode. Settings here are for<A href="#encryption">
|
|
encryption</A> using<A href="#3DES"> triple DES</A> and<A href="#authentication">
|
|
authentication</A> using<A href="#MD5"> MD5</A>. Note that encryption
|
|
without authentication should not be used; it is insecure.</DD>
|
|
<DT>espenkey</DT>
|
|
<DD>Key for ESP encryption. Here, a 192-bit hex number for triple DES.</DD>
|
|
<DT>espauthkey</DT>
|
|
<DD>Key for ESP authentication. Here, a 128-bit hex number for MD5.</DD>
|
|
</DL>
|
|
<P><STRONG>Note</STRONG> that the<STRONG> example keys we supply</STRONG>
|
|
are intended<STRONG> only for testing</STRONG>. For real use, you
|
|
should go to automatic keying. If that is not possible, create your own
|
|
keys for manual mode and keep them secret</P>
|
|
<P>Of course, any files containing keys<STRONG> must</STRONG> have 600
|
|
permissions and be owned by root.</P>
|
|
<P>If you connect in this way to multiple sites, we recommend that you
|
|
keep keys for each site in a separate file and adopt some naming
|
|
convention that lets you pick them all up with a single "include" line.
|
|
This minimizes the risk of losing several keys to one error or attack
|
|
and of accidentally giving another site admin keys which he or she has
|
|
no business knowing.</P>
|
|
<P>Also note that if you have multiple manually keyed connections on a
|
|
single machine, then the<VAR> spi</VAR> parameter must be different for
|
|
each one. Any 3-digit hex number is OK, provided they are different for
|
|
each connection. We reserve the range 0x100 to 0xfff for manual
|
|
connections. Pluto assigns SPIs from 0x1000 up for automatically keyed
|
|
connections.</P>
|
|
<P>If<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> contains
|
|
keys for manual mode connections, then it too must have permissions<VAR>
|
|
rw-------</VAR>. We recommend instead that, if you must manual keying
|
|
in production, you keep the keys in separate files.</P>
|
|
<P>Note also that<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A>
|
|
is installed with permissions<VAR> rw-r--r--</VAR>. If you plan to use
|
|
manually keyed connections for anything more than initial testing, you<B>
|
|
must</B>:</P>
|
|
<UL>
|
|
<LI>either change permissions to<VAR> rw-------</VAR></LI>
|
|
<LI>or store keys separately in secure files and access them via include
|
|
statements in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A>.</LI>
|
|
</UL>
|
|
<P>We recommend the latter method for all but the simplest
|
|
configurations.</P>
|
|
<H3><A name="ranbits">Creating keys with ranbits</A></H3>
|
|
<P>You can create new<A href="#random"> random</A> keys with the<A href="manpage.d/ipsec_ranbits.8.html">
|
|
ranbits(8)</A> utility. For example, the commands:</P>
|
|
<PRE> umask 177
|
|
ipsec ranbits 192 > temp
|
|
ipsec ranbits 128 >> temp</PRE>
|
|
<P>create keys in the sizes needed for our default algorithms:</P>
|
|
<UL>
|
|
<LI>192-bit key for<A href="#3DES"> 3DES</A> encryption
|
|
<BR> (only 168 bits are used; parity bits are ignored)</LI>
|
|
<LI>128-bit key for keyed<A href="#MD5"> MD5</A> authentication</LI>
|
|
</UL>
|
|
<P>If you want to use<A href="#SHA"> SHA</A> instead of<A href="#MD5">
|
|
MD5</A>, that requires a 160-bit key</P>
|
|
<P>Note that any<STRONG> temporary files</STRONG> used must be kept<STRONG>
|
|
secure</STRONG> since they contain keys. That is the reason for the
|
|
umask command above. The temporary file should be deleted as soon as
|
|
you are done with it. You may also want to change the umask back to its
|
|
default value after you are finished working on keys.</P>
|
|
<P>The ranbits utility may pause for a few seconds if not enough entropy
|
|
is available immediately. See ipsec_ranbits(8) and random(4) for
|
|
details. You may wish to provide some activity to feed entropy into the
|
|
system. For example, you might move the mouse around, type random
|
|
characters, or do<VAR> du /usr > /dev/null</VAR> in the background.</P>
|
|
<H2><A name="boot">Setting up connections at boot time</A></H2>
|
|
<P>You can tell the system to set up connections automatically at boot
|
|
time by putting suitable stuff in /etc/ipsec.conf on both systems. The
|
|
relevant section of the file is labelled by a line reading<VAR> config
|
|
setup</VAR>.</P>
|
|
<P>Details can be found in the<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> man page. We also provide a file of<A href="examples">
|
|
example configurations</A>.</P>
|
|
<P>The most likely options are something like:</P>
|
|
<DL>
|
|
<DT>interfaces="ipsec0=eth0 ipsec1=ppp0"</DT>
|
|
<DD>Tells KLIPS which interfaces to use. Up to four interfaces numbered
|
|
ipsec[0-3] are supported. Each interface can support an arbitrary
|
|
number of tunnels.
|
|
<P>Note that for PPP, you give the ppp[0-9] device name here, not the
|
|
underlying device such as modem (or eth1 if you are using PPPoE).</P>
|
|
</DD>
|
|
<DT>interfaces=%defaultroute</DT>
|
|
<DD>Alternative setting, useful in simple cases. KLIPS will pick up both
|
|
its interface and the next hop information from the settings of the
|
|
Linux default route.</DD>
|
|
<DT>forwardcontrol=no</DT>
|
|
<DD>Normally "no". Set to "yes" if the IP forwarding option is disabled
|
|
in your network configuration. (This can be set as a kernel
|
|
configuration option or later. e.g. on Redhat, it's in
|
|
/etc/sysconfig/network and on SuSE you can adjust it with Yast.) Linux
|
|
FreeS/WAN will then enable forwarding when starting up and turn it off
|
|
when going down. This is used to ensure that no packets will be
|
|
forwarded before IPsec comes up and takes control.</DD>
|
|
<DT>syslog=daemon.error</DT>
|
|
<DD>Used in messages to the system logging daemon (syslogd) to specify
|
|
what type of software is sending the messages. If the settings are
|
|
"daemon.error" as in our example, then syslogd treats the messages as
|
|
error messages from a daemon.
|
|
<P>Note that<A href="#Pluto"> Pluto</A> does not currently pay attention
|
|
to this variable. The variable controls setup messages only.</P>
|
|
</DD>
|
|
<DT>klipsdebug=</DT>
|
|
<DD>Debug settings for<A href="#KLIPS"> KLIPS</A>.</DD>
|
|
<DT>plutodebug=</DT>
|
|
<DD>Debug settings for<A href="#Pluto"> Pluto</A>.</DD>
|
|
<DT>... for both the above DEBUG settings</DT>
|
|
<DD>Normally, leave empty as shown above for no debugging output.
|
|
<BR> Use "all" for maximum information.
|
|
<BR> See ipsec_klipsdebug(8) and ipsec_pluto(8) man page for other
|
|
options. Beware that if you set /etc/ipsec.conf to enable debug output,
|
|
your system's log files may get large quickly.</DD>
|
|
<DT>dumpdir=/safe/directory</DT>
|
|
<DD>Normally, programs started by ipsec setup don't crash. If they do,
|
|
by default, no core dump will be produced because such dumps would
|
|
contain secrets. If you find you need to debug such crashes, you can
|
|
set dumpdir to the name of a directory in which to collect the core
|
|
file.</DD>
|
|
<DT>manualstart=</DT>
|
|
<DD>List of manually keyed connections to be automatically started at
|
|
boot time. Useful for testing, but not for long term use. Connections
|
|
which are automatically started should also be automatically re-keyed.</DD>
|
|
<DT>pluto=yes</DT>
|
|
<DD>Whether to start<A href="#Pluto"> Pluto</A> when ipsec startup is
|
|
done.
|
|
<BR> This parameter is optional and defaults to "yes" if not present.
|
|
<P>"yes" is strongly recommended for production use so that the keying
|
|
daemon (Pluto) will automatically re-key the connections regularly. The
|
|
ipsec-auto parameters ikelifetime, ipseclifetime and reykeywindow give
|
|
you control over frequency of rekeying.</P>
|
|
</DD>
|
|
<DT>plutoload="reno-van reno-adam reno-nyc"</DT>
|
|
<DD>List of tunnels (by name, e.g. fred-susan or reno-van in our
|
|
examples) to be loaded into Pluto's internal database at startup. In
|
|
this example, Pluto loads three tunnels into its database when it is
|
|
started.
|
|
<P>If plutoload is "%search", Pluto will load any connections whose
|
|
description includes "auto=add" or "auto=start".</P>
|
|
</DD>
|
|
<DT>plutostart="reno-van reno-adam reno-nyc"</DT>
|
|
<DD>List of tunnels to attempt to negotiate when Pluto is started.
|
|
<P>If plutostart is "%search", Pluto will start any connections whose
|
|
description includes "auto=start".</P>
|
|
<P>Note that, for a connection intended to be permanent,<STRONG> both
|
|
gateways should be set try to start</STRONG> the tunnel. This allows
|
|
quick recovery if either gateway is rebooted or has its IPsec
|
|
restarted. If only one gateway is set to start the tunnel and the other
|
|
gateway restarts, the tunnel may not be rebuilt.</P>
|
|
</DD>
|
|
<DT>plutowait=no</DT>
|
|
<DD>Controls whether Pluto waits for one tunnel to be established before
|
|
starting to negotiate the next. You might set this to "yes"
|
|
<UL>
|
|
<LI>if your gateway is a very limited machine and you need to conserve
|
|
resources.</LI>
|
|
<LI>for debugging; the logs are clearer if only one connection is
|
|
brought up at a time</LI>
|
|
</UL>
|
|
For a busy and resource-laden production gateway, you likely want "no"
|
|
so that connections are brought up in parallel and the whole process
|
|
takes less time.</DD>
|
|
</DL>
|
|
<P>The example assumes you are at the Reno office and will use IPsec to
|
|
Vancouver, New York City and Amsterdam.</P>
|
|
<H2><A name="multitunnel">Multiple tunnels between the same two gateways</A>
|
|
</H2>
|
|
<P>Consider a pair of subnets, each with a security gateway, connected
|
|
via the Internet:</P>
|
|
<PRE> 192.168.100.0/24 left subnet
|
|
|
|
|
192.168.100.1
|
|
North Gateway
|
|
101.101.101.101 left
|
|
|
|
|
101.101.101.1 left next hop
|
|
[Internet]
|
|
202.202.202.1 right next hop
|
|
|
|
|
202.202.202.202 right
|
|
South gateway
|
|
192.168.200.1
|
|
|
|
|
192.168.200.0/24 right subnet</PRE>
|
|
<P>A tunnel specification such as:</P>
|
|
<PRE>conn northnet-southnet
|
|
left=101.101.101.101
|
|
leftnexthop=101.101.101.1
|
|
leftsubnet=192.168.100.0/24
|
|
leftfirewall=yes
|
|
right=202.202.202.202
|
|
rightnexthop=202.202.202.1
|
|
rightsubnet=192.168.200.0/24
|
|
rightfirewall=yes</PRE>
|
|
will allow machines on the two subnets to talk to each other. You might
|
|
test this by pinging from polarbear (192.168.100.7) to penguin
|
|
(192.168.200.5).
|
|
<P>However,<STRONG> this does not cover other traffic you might want to
|
|
secure</STRONG>. To handle all the possibilities, you might also want
|
|
these connection descriptions:</P>
|
|
<PRE>conn northgate-southnet
|
|
left=101.101.101.101
|
|
leftnexthop=101.101.101.1
|
|
right=202.202.202.202
|
|
rightnexthop=202.202.202.1
|
|
rightsubnet=192.168.200.0/24
|
|
rightfirewall=yes
|
|
|
|
conn northnet-southgate
|
|
left=101.101.101.101
|
|
leftnexthop=101.101.101.1
|
|
leftsubnet=192.168.100.0/24
|
|
leftfirewall=yes
|
|
right=202.202.202.202
|
|
rightnexthop=202.202.202.1</PRE>
|
|
<P>Without these, neither gateway can do IPsec to the remote subnet.
|
|
There is no IPsec tunnel or eroute set up for the traffic.</P>
|
|
<P>In our example, with the non-routable 192.168.* addresses used,
|
|
packets would simply be discarded. In a different configuration, with
|
|
routable addresses for the remote subnet,<STRONG> they would be sent
|
|
unencrypted</STRONG> since there would be no IPsec eroute and there
|
|
would be a normal IP route.</P>
|
|
<P>You might also want:</P>
|
|
<PRE>conn northgate-southgate
|
|
left=101.101.101.101
|
|
leftnexthop=101.101.101.1
|
|
right=202.202.202.202
|
|
rightnexthop=202.202.202.1</PRE>
|
|
<P>This is required if you want the two gateways to speak IPsec to each
|
|
other.</P>
|
|
<P>This requires a lot of duplication of details. Judicious use of<VAR>
|
|
also=</VAR> and<VAR> include</VAR> can reduce this problem.</P>
|
|
<P>Note that, while FreeS/WAN supports all four tunnel types, not all
|
|
implementations do. In particular, some versions of Windows 2000 and
|
|
the freely downloadable version of PGP provide only "client"
|
|
functionality. You cannot use them as gateways with a subnet behind
|
|
them. To get that functionality, you must upgrade to Windows 2000
|
|
server or the commercially available PGP products.</P>
|
|
<H3><A name="advroute">One tunnel plus advanced routing</A></H3>
|
|
It is also possible to use the new routing features in 2.2 and later
|
|
kernels to avoid most needs for multple tunnels. Here is one mailing
|
|
list message on the topic:
|
|
<PRE>Subject: Re: linux-ipsec: IPSec packets not entering tunnel?
|
|
Date: Mon, 20 Nov 2000
|
|
From: Justin Guyett <[email protected]>
|
|
|
|
On Mon, 20 Nov 2000, Claudia Schmeing wrote:
|
|
|
|
> Right Left
|
|
> "home" "office"
|
|
> 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24
|
|
>
|
|
> I've created all four tunnels, and can ping to test each of them,
|
|
> *except* homegate-officenet.
|
|
|
|
I keep wondering why people create all four tunnels. Why not route
|
|
traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
|
|
And 99% of the time you don't need to access "office" directly, which
|
|
means you can eliminate all but the subnet<->subnet connection.</PRE>
|
|
and FreeS/WAN technical lead Henry Spencer's comment:
|
|
<PRE>> I keep wondering why people create all four tunnels. Why not route
|
|
> traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
|
|
|
|
This is feasible, given some iproute2 attention to source addresses, but
|
|
it isn't something we've documented yet... (partly because we're still
|
|
making some attempt to support 2.0.xx kernels, which can't do this, but
|
|
mostly because we haven't caught up with it yet).
|
|
|
|
> And 99% of the time you don't need to access "office" directly, which
|
|
> means you can eliminate all but the subnet<->subnet connection.
|
|
|
|
Correct in principle, but people will keep trying to ping to or from the
|
|
gateways during testing, and sometimes they want to run services on the
|
|
gateway machines too.</PRE>
|
|
|
|
<!-- Is this in the right spot in this document? -->
|
|
<H2><A name="opp.gate">An Opportunistic Gateway</A></H2>
|
|
<H3><A NAME="14_7_1">Start from full opportunism</A></H3>
|
|
<P>Full opportunism allows you to initiate and receive opportunistic
|
|
connections on your machine. The remaining instructions in this section
|
|
assume you have first set up full opportunism on your gateway using<A HREF="#opp.incoming">
|
|
these instructions</A>. Both sets of instructions require mailing DNS
|
|
records to your ISP. Collect DNS records for both the gateway (above)
|
|
and the subnet nodes (below) before contacting your ISP.</P>
|
|
<H3><A NAME="14_7_2">Reverse DNS TXT records for each protected machine</A>
|
|
</H3>
|
|
<P>You need these so that your Opportunistic peers can:</P>
|
|
<UL>
|
|
<LI>discover the gateway's address, knowing only the IP address that
|
|
packets are bound for</LI>
|
|
<LI>verify that the gateway is authorised to encrypt for that endpoint</LI>
|
|
</UL>
|
|
<P>On the gateway, generate a TXT record with:</P>
|
|
<PRE> ipsec showhostkey --txt 192.0.2.11</PRE>
|
|
<P>Use your gateway address in place of 192.0.2.11.</P>
|
|
<P>You should see (keys are trimmed for clarity throughout our example):</P>
|
|
<PRE> ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"</PRE>
|
|
<P><B>This MUST BE the same key as in your gateway's TXT record, or
|
|
nothing will work.</B></P>
|
|
<P>In a text file, make one copy of this TXT record for each subnet
|
|
node:</P>
|
|
<PRE> ; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"</PRE>
|
|
<P>Above each entry, insert a line like this:</P>
|
|
<PRE> 98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.</PRE>
|
|
<P>It must include:</P>
|
|
<UL>
|
|
<LI>The subnet node's address in reverse map format. For example,
|
|
192.0.2.120 becomes<VAR> 120.2.0.192.in-addr.arpa.</VAR>. Note the
|
|
final period.</LI>
|
|
<LI><VAR>IN PTR</VAR></LI>
|
|
<LI>The node's name, ie.<VAR> arthur.example.com.</VAR>. Note the final
|
|
period.</LI>
|
|
</UL>
|
|
<P>The result will be a file of TXT records, like this:</P>
|
|
<PRE> 98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
|
|
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
99.2.0.192.in-addr.arpa. IN PTR ford.example.com.
|
|
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
|
|
|
|
100.2.0.192.in-addr.arpa. IN PTR trillian.example.com.
|
|
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
|
|
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"</PRE>
|
|
<H3><A NAME="14_7_3">Publish your records</A></H3>
|
|
<P>Ask your ISP to publish all the reverse DNS records you have
|
|
collected. There may be a delay of up to 48 hours as the records
|
|
propagate.</P>
|
|
<H3><A NAME="14_7_4">...and test them</A></H3>
|
|
<P>Check a couple of records with commands like this one:</P>
|
|
<PRE> ipsec verify --host ford.example.com
|
|
ipsec verify --host trillian.example.com</PRE>
|
|
<P>The<VAR> verify</VAR> command checks for TXT records for both the
|
|
subnet host and its gateway. You should see output like:</P>
|
|
<PRE> ...
|
|
Looking for TXT in reverse map: 99.2.0.192.in-addr.arpa [OK]
|
|
...
|
|
Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
|
|
...
|
|
Looking for TXT in reverse map: 100.2.0.192.in-addr.arpa [OK]
|
|
...
|
|
Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
|
|
...</PRE>
|
|
<H3><A NAME="14_7_5">No Configuration Needed</A></H3>
|
|
<P>FreeS/WAN 2.x ships with a built-in, automatically enabled OE
|
|
connection<VAR> conn packetdefault</VAR> which applies OE, if possible,
|
|
to all outbound traffic routed through the FreeS/WAN box. The<A HREF="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5) manual</A> describes this connection in detail. While the
|
|
effect is much the same as<VAR> private-or-clear</VAR>, the
|
|
implementation is different: notably, it does not use policy groups.</P>
|
|
<P>You can create more complex OE configurations for traffic forwarded
|
|
through a FreeS/WAN box, as explained in our<A HREF="#policygroups">
|
|
policy groups document</A>, or disable OE using<A HREF="#disable_policygroups">
|
|
these instructions</A>.</P>
|
|
<H2><A name="extruded.config">Extruded Subnets</A></H2>
|
|
<P>What we call<A href="glossary.html#extruded"> extruded subnets</A>
|
|
are a special case of<A href="glossary.html#VPN.gloss"> VPNs</A>.</P>
|
|
<P>If your buddy has some unused IP addresses, in his subnet far off at
|
|
the other side of the Internet, he can loan them to you... provided
|
|
that the connection between you and him is fast enough to carry all the
|
|
traffic between your machines and the rest of the Internet. In effect,
|
|
he "extrudes" a part of his address space over the network to you, with
|
|
your Internet traffic appearing to originate from behind his Internet
|
|
gateway.</P>
|
|
<P>As far as the Internet is concerned, your new extruded net is behind
|
|
your buddy's gateway. You route all your packets for the Internet at
|
|
large out his gateway, and receive return packets the same way. You
|
|
route your local packets locally.</P>
|
|
<P>Suppose your friend has a.b.c.0/24 and wants to give you
|
|
a.b.c.240/28. The initial situation is:</P>
|
|
<PRE> subnet gateway Internet
|
|
a.b.c.0/24 a.b.c.1 p.q.r.s</PRE>
|
|
where anything from the Internet destined for any machine in a.b.c.0/24
|
|
is routed via p.q.r.s and that gateway knows what to do from there.
|
|
<P>Of course it is quite normal for various smaller subnets to exist
|
|
behind your friend's gateway. For example, your friend's company might
|
|
have a.b.c.16/28=development, a.b.c.32/28=marketing and so on. The
|
|
Internet neither knows not cares about this; it just delivers packets
|
|
to the p.q.r.s and lets the gateway do whatever needs to be done from
|
|
there.</P>
|
|
<P>What we want to do is take a subnet, perhaps a.b.c.240/28, out of
|
|
your friend's physical location<EM> while still having your friend's
|
|
gateway route to it</EM>. As far as the Internet is concerned, you
|
|
remain behind that gateway.</P>
|
|
<PRE> subnet gateway Internet your gate extruded
|
|
|
|
a.b.c.0/24 a.b.c.1 p.q.r.s d.e.f.g a.b.c.240/28
|
|
|
|
========== tunnel ==========</PRE>
|
|
<P>The extruded addresses have to be a complete subnet.</P>
|
|
<P>In our example, the friend's security gateway is also his Internet
|
|
gateway, but this is not necessary. As long as all traffic from the
|
|
Internet to his addresses passes through the Internet gate, the
|
|
security gate could be a machine behind that. The IG would need to
|
|
route all traffic for the extruded subnet to the SG, and the SG could
|
|
handle the rest.</P>
|
|
<P>First, configure your subnet using the extruded addresses. Your
|
|
security gateway's interface to your subnet needs to have an extruded
|
|
address (possibly using a Linux<A href="#virtual"> virtual interface</A>
|
|
, if it also has to have a different address). Your gateway needs to
|
|
have a route to the extruded subnet, pointing to that interface. The
|
|
other machines at your site need to have addresses in that subnet, and
|
|
default routes pointing to your gateway.</P>
|
|
<P>If any of your friend's machines need to talk to the extruded subnet,<EM>
|
|
they</EM> need to have a route for the extruded subnet, pointing at his
|
|
gateway.</P>
|
|
<P>Then set up an IPsec subnet-to-subnet tunnel between your gateway and
|
|
his, with your subnet specified as the extruded subnet, and his subnet
|
|
specified as "0.0.0.0/0".</P>
|
|
<P>The tunnel description should be:</P>
|
|
<PRE>conn extruded
|
|
left=p.q.r.s
|
|
leftsubnet=0.0.0.0/0
|
|
right=d.e.f.g
|
|
rightsubnet=a.b.c.0/28</PRE>
|
|
<P>If either side was doing firewalling for the extruded subnet before
|
|
the IPsec connection is set up, you'll need to poke holes in your<A HREF="#firewall">
|
|
firewall</A> to allow packets through.</P>
|
|
<P>And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that
|
|
is, the whole Internet -- through the tunnel to his SG, which then
|
|
sends it onward as if it came from his subnet. When traffic for the
|
|
extruded subnet arrives at his SG, it gets sent through the tunnel to
|
|
your SG, which passes it to the right machine.</P>
|
|
<P>Remember that when ipsec_manual or ipsec_auto takes a connection
|
|
down, it<EM> does not undo the route</EM> it made for that connection.
|
|
This lets you take a connection down and bring up a new one, or a
|
|
modified version of the old one, without having to rebuild the route it
|
|
uses and without any risk of packets which should use IPsec
|
|
accidentally going out in the clear. Because the route always points
|
|
into KLIPS, the packets will always go there. Because KLIPS temporarily
|
|
has no idea what to do with them (no eroute for them), they will be
|
|
discarded.</P>
|
|
<P>If you<EM> do</EM> want to take the route down, this is what the
|
|
"unroute" operation in manual and auto is for. Just do an unroute after
|
|
doing the down.</P>
|
|
<P>Note that the route for a connection may have replaced an existing
|
|
non-IPsec route. Nothing in Linux FreeS/WAN will put that pre-IPsec
|
|
route back. If you need it back, you have to create it with the route
|
|
command.</P>
|
|
<H2><A name="roadvirt">Road Warrior with virtual IP address</A></H2>
|
|
<P>Please note that<A HREF="http://www.freeswan.ca/download.php"> Super
|
|
FreeS/WAN</A> now features DHCP-over-IPsec, which is an alternate
|
|
procedure for Virtual IP address assignment.</P>
|
|
<P></P>
|
|
<P>Here is a mailing list message about another way to configure for
|
|
road warrior support:</P>
|
|
<PRE>Subject: Re: linux-ipsec: understanding the vpn
|
|
Date: Thu, 28 Oct 1999 10:43:22 -0400
|
|
From: Irving Reid <[email protected]>
|
|
|
|
> local-------linux------internet------mobile
|
|
> LAN box user
|
|
> ...
|
|
|
|
> now when the mobile user connects to the linux box
|
|
> it is given a virtual IP address, i have configured it to
|
|
> be in the 10.x.x.x range. mobile user and linux box
|
|
> have a tunnel between them with these IP addresses.
|
|
|
|
> Uptil this all is fine.
|
|
|
|
If it is possible to configure your mobile client software *not* to
|
|
use a virtual IP address, that will make your life easier. It is easier
|
|
to configure FreeS/WAN to use the actual address the mobile user gets
|
|
from its ISP.
|
|
|
|
Unfortunately, some Windows clients don't let you choose.
|
|
|
|
> what i would like to know is that how does the mobile
|
|
> user communicate with other computers on the local
|
|
> LAN , of course with the vpn ?
|
|
|
|
> what IP address should the local LAN
|
|
> computers have ? I guess their default gateway
|
|
> should be the linux box ? and does the linux box need
|
|
> to be a 2 NIC card box or one is fine.
|
|
|
|
As someone else stated, yes, the Linux box would usually be the default
|
|
IP gateway for the local lan.
|
|
|
|
However...
|
|
|
|
If you mobile user has software that *must* use a virtual IP address,
|
|
the whole picture changes. Nobody has put much effort into getting
|
|
FreeS/WAN to play well in this environment, but here's a sketch of one
|
|
approach:
|
|
|
|
Local Lan 1.0.0.0/24
|
|
|
|
|
+- Linux FreeS/WAN 1.0.0.2
|
|
|
|
|
| 1.0.0.1
|
|
Router
|
|
| 2.0.0.1
|
|
|
|
|
Internet
|
|
|
|
|
| 3.0.0.1
|
|
Mobile User
|
|
Virtual Address: 1.0.0.3
|
|
|
|
Note that the Local Lan network (1.0.0.x) can be registered, routable
|
|
addresses.
|
|
|
|
Now, the Mobile User sets up an IPSec security association with the
|
|
Linux box (1.0.0.2); it should ESP encapsulate all traffic to the
|
|
network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key
|
|
negotiation, which needs to work outside of the IPSec tunnel.
|
|
|
|
On the Linux side, there's a bunch of stuff you need to do by hand (for
|
|
now). FreeS/WAN should correctly handle setting up the IPSec SA and
|
|
routes, but I haven't tested it so this may not work...
|
|
|
|
The FreeS/WAN conn should look like:
|
|
|
|
conn mobile
|
|
right=1.0.0.2
|
|
rightsubnet=1.0.0.0/24
|
|
rightnexthop=1.0.0.1
|
|
left=0.0.0.0 # The infamous "road warrior"
|
|
leftsubnet=1.0.0.3/32
|
|
|
|
Note that the left subnet contains *only* the remote host's virtual
|
|
address.
|
|
|
|
Hopefully the routing table on the FreeS/WAN box ends up looking like
|
|
this:
|
|
|
|
% netstat -rn
|
|
Kernel IP routing table
|
|
Destination Gateway Genmask Flags MSS Window irtt Iface
|
|
1.0.0.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0
|
|
127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo
|
|
0.0.0.0 1.0.0.1 0.0.0.0 UG 1500 0 0 eth0
|
|
1.0.0.3 1.0.0.1 255.255.255.255 UG 1433 0 0 ipsec0
|
|
|
|
So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should
|
|
get bundled up and sent through the tunnel. To get the packets for
|
|
1.0.0.3 to the Linux box in the first place, you need to use "proxy
|
|
ARP".
|
|
|
|
How this works is: when a host or router on the local Ethernet segment
|
|
wants to send a packet to 1.0.0.3, it sends out an Ethernet level
|
|
broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would
|
|
reply, saying "send IP packets for 1.0.0.3 to my Ethernet address".
|
|
|
|
Instead, you need to set up the Linux box so that _it_ answers ARP
|
|
requests for 1.0.0.3, even though that isn't its IP address. That
|
|
convinces everyone else on the lan to send 1.0.0.3 packets to the Linux
|
|
box, where the usual FreeS/WAN processing and routing take over.
|
|
|
|
% arp -i eth0 -s 1.0.0.3 -D eth0 pub
|
|
|
|
This says, if you see an ARP request on interface eth0 asking for
|
|
1.0.0.3, respond with the Ethernet address of interface eth0.
|
|
|
|
Now, as I said at the very beginning, if it is *at all* possible to
|
|
configure your client *not* to use the virtual IP address, you can avoid
|
|
this whole mess.</PRE>
|
|
<H2><A name="dynamic">Dynamic Network Interfaces</A></H2>
|
|
<P>Sometimes you have to cope with a situation where the network
|
|
interface(s) aren't all there at boot. The common example is notebooks
|
|
with PCMCIA.</P>
|
|
<H3><A name="basicdyn">Basics</A></H3>
|
|
<P>The key issue here is that the<VAR> config setup</VAR> section of the<VAR>
|
|
/etc/ipsec.conf</VAR> configuration file lists the connection between
|
|
ipsecN and hardware interfaces, in the<VAR> interfaces=</VAR> variable.
|
|
At any time when<VAR> ipsec setup start</VAR> or<VAR> ipsec setup
|
|
restart</VAR> is run this variable<STRONG> must</STRONG> correspond to
|
|
the current real situation. More precisely, it<STRONG> must not</STRONG>
|
|
mention any hardware interfaces which don't currently exist. The
|
|
difficulty is that an<VAR> ipsec setup start</VAR> command is normally
|
|
run at boot time so interfaces that are not up then are mis-handled.</P>
|
|
<H3><A name="bootdyn">Boot Time</A></H3>
|
|
<P>Normally, an<VAR> ipsec setup start</VAR> is run at boot time.
|
|
However, if the hardware situation at boot time is uncertain, one of
|
|
two things must be done.</P>
|
|
<UL>
|
|
<LI>One possibility is simply not to have IPsec brought up at boot time.
|
|
To do this:
|
|
<PRE> chkconfig --level 2345 ipsec off</PRE>
|
|
That's for modern Red Hats or other Linuxes with chkconfig. Systems
|
|
which lack this will require fiddling with symlinks in /etc/rc.d/rc?.d
|
|
or the equivalent.</LI>
|
|
<LI>Another possibility is to bring IPsec up with no interfaces, which
|
|
is less aesthetically satisfying but simpler. Just put
|
|
<PRE> interfaces=</PRE>
|
|
in the configuration file. KLIPS and Pluto will be started, but won't
|
|
do anything.</LI>
|
|
</UL>
|
|
<H3><A name="changedyn">Change Time</A></H3>
|
|
<P>When the hardware *is* in place, IPsec has to be made aware of it.
|
|
Someday there may be a nice way to do this.</P>
|
|
<P>Right now, the way to do it is to fix the<VAR> /etc/ipsec.conf</VAR>
|
|
file appropriately, so<VAR> interfaces</VAR> reflects the new
|
|
situation, and then restart the IPsec subsystem. This does break any
|
|
existing IPsec connections.</P>
|
|
<P>If IPsec wasn't brought up at boot time, do</P>
|
|
<PRE> ipsec setup start</PRE>
|
|
while if it was, do
|
|
<PRE> ipsec setup restart</PRE>
|
|
which won't be as quick.
|
|
<P>If some of the hardware is to be taken out, before doing that, amend
|
|
the configuration file so interfaces no longer includes it, and do</P>
|
|
<PRE> ipsec setup restart</PRE>
|
|
<P>Again, this breaks any existing connections.</P>
|
|
<H2><A name="unencrypted">Unencrypted tunnels</A></H2>
|
|
<P>Sometimes you might want to create a tunnel without encryption. Often
|
|
this is a bad idea, even if you have some data which need not be
|
|
private. See this<A href="#traffic.resist"> discussion</A>.</P>
|
|
<P>The IPsec protocols provide two ways to do build such tunnels:</P>
|
|
<DL>
|
|
<DT>using ESP with null encryption</DT>
|
|
<DD>not supported by FreeS/WAN</DD>
|
|
<DT>using<A href="#AH"> AH</A> without<A href="#ESP"> ESP</A></DT>
|
|
<DD>supported for manually keyed connections</DD>
|
|
<DD>possible with explicit commands via<A href="manpage.d/ipsec_whack.8.html">
|
|
ipsec_whack(8)</A> (see this<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00190.html">
|
|
list message</A>)</DD>
|
|
<DD>not supported in the<A href="manpage.d/ipsec_auto.8.html">
|
|
ipsec_auto(8)</A> scripts.</DD>
|
|
</DL>
|
|
One situation in which this comes up is when otherwise some data would
|
|
be encrypted twice. Alice wants a secure tunnel from her machine to
|
|
Bob's. Since she's behind one security gateway and he's behind another,
|
|
part of the tunnel that they build passes through the tunnel that their
|
|
site admins have built between the gateways. All of Alice and Bob's
|
|
messages are encrypted twice.
|
|
<P>There are several ways to handle this.</P>
|
|
<UL>
|
|
<LI>Just accept the overhead of double encryption. The site admins might
|
|
choose this if any of the following apply:
|
|
<UL>
|
|
<LI>policy says encrypt everything (usually, it should)</LI>
|
|
<LI>they don't entirely trust Alice and Bob (usually, if they don't have
|
|
to, they shouldn't)</LI>
|
|
<LI>if they don't feel the saved cycles are worth the time they'd need
|
|
to build a non-encrypted tunnel for Alice and Bob's packets (often,
|
|
they aren't)</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Use a plain IP-in-IP tunnel. These are not well documented. A good
|
|
starting point is in the Linux kernel source tree, in
|
|
/usr/src/linux/drivers/net/README.tunnel.</LI>
|
|
<LI>Use a manually-keyed AH-only tunnel.</LI>
|
|
</UL>
|
|
<P>Note that if Alice and Bob want end-to-end security, they must build
|
|
a tunnel end-to-end between their machines or use some other end-to-end
|
|
tool such as PGP or SSL that suits their data. The only question is
|
|
whether the admins build some special unencrypted tunnel for those
|
|
already-encrypted packets.</P>
|
|
<HR>
|
|
<H1><A name="install">Installing FreeS/WAN</A></H1>
|
|
<P>This document will teach you how to install Linux FreeS/WAN. If your
|
|
distribution comes with Linux FreeS/WAN, we offer tips to get you
|
|
started.</P>
|
|
<H2><A NAME="15_1">Requirements</A></H2>
|
|
<P>To install FreeS/WAN you must:</P>
|
|
<UL>
|
|
<LI>be running Linux with the 2.4 or 2.2 kernel series. See this<A HREF="http://www.freeswan.ca/download.php#contact">
|
|
kernel compatibility table</A>.
|
|
<BR>We also have experimental support for 2.6 kernels. Here are two
|
|
basic approaches:
|
|
<UL>
|
|
<LI> install FreeS/WAN, including its<A HREF="#parts"> KLIPS</A> kernel
|
|
code. This will remove the native IPsec stack and replace it with
|
|
KLIPS.</LI>
|
|
<LI> install the FreeS/WAN<A HREF="#parts"> userland tools</A> (keying
|
|
daemon and supporting scripts) for use with<A HREF="http://lartc.org/howto/lartc.ipsec.html">
|
|
2.6 kernel native IPsec</A>,</LI>
|
|
</UL>
|
|
See also these<A HREF="2.6.known-issues"> known issues with 2.6</A>.</LI>
|
|
<LI>have root access to your Linux box</LI>
|
|
<LI>choose the version of FreeS/WAN you wish to install based on<A HREF="http://www.freeswan.org/mail.html">
|
|
mailing list reports</A>
|
|
<!-- or
|
|
our updates page (coming soon)-->
|
|
</LI>
|
|
</UL>
|
|
<H2><A NAME="15_2">Choose your install method</A></H2>
|
|
<P>There are three basic ways to get FreeS/WAN onto your system:</P>
|
|
<UL>
|
|
<LI>activating and testing a FreeS/WAN that<A HREF="#distroinstall">
|
|
shipped with your Linux distribution</A></LI>
|
|
<LI><A HREF="#rpminstall">RPM install</A></LI>
|
|
<LI><A HREF="#srcinstall">Install from source</A></LI>
|
|
</UL>
|
|
<A NAME="distroinstall"></A>
|
|
<H2><A NAME="15_3">FreeS/WAN ships with some Linuxes</A></H2>
|
|
<P>FreeS/WAN comes with<A HREF="#distwith"> these distributions</A>.</P>
|
|
<P>If you're running one of these, include FreeS/WAN in the choices you
|
|
make during installation, or add it later using the distribution's
|
|
tools.</P>
|
|
<H3><A NAME="15_3_1">FreeS/WAN may be altered...</A></H3>
|
|
<P>Your distribution may have integrated extra features, such as Andreas
|
|
Steffen's X.509 patch, into FreeS/WAN. It may also use custom startup
|
|
script locations or directory names.</P>
|
|
<H3><A NAME="15_3_2">You might need to create an authentication keypair</A>
|
|
</H3>
|
|
<P>If your FreeS/WAN came with your distribution, you may wish to
|
|
generate a fresh RSA key pair. FreeS/WAN will use these keys for
|
|
authentication.</P>
|
|
<P> To do this, become root, and type:</P>
|
|
<PRE> ipsec newhostkey --output /etc/ipsec.secrets --hostname xy.example.com
|
|
chmod 600 /etc/ipsec.secrets</PRE>
|
|
<P>where you replace xy.example.com with your machine's fully-qualified
|
|
domain name. Generate some randomness, for example by wiggling your
|
|
mouse, to speed the process.</P>
|
|
<P>The resulting ipsec.secrets looks like:</P>
|
|
<PRE>: RSA {
|
|
# RSA 2192 bits xy.example.com Sun Jun 8 13:42:19 2003
|
|
# for signatures only, UNSAFE FOR ENCRYPTION
|
|
#pubkey=0sAQOFppfeE3cC7wqJi...
|
|
Modulus: 0x85a697de137702ef0...
|
|
# everything after this point is secret
|
|
PrivateExponent: 0x16466ea5033e807...
|
|
Prime1: 0xdfb5003c8947b7cc88759065...
|
|
Prime2: 0x98f199b9149fde11ec956c814...
|
|
Exponent1: 0x9523557db0da7a885af90aee...
|
|
Exponent2: 0x65f6667b63153eb69db8f300dbb...
|
|
Coefficient: 0x90ad00415d3ca17bebff123413fc518...
|
|
}
|
|
# do not change the indenting of that "}"</PRE>
|
|
<P>In the actual file, the strings are much longer.</P>
|
|
<H3><A NAME="15_3_3">Start and test FreeS/WAN</A></H3>
|
|
<P>You can now<A HREF="#starttest"> start FreeS/WAN and test whether
|
|
it's been successfully installed.</A>.</P>
|
|
<A NAME="rpminstall"></A>
|
|
<H2><A NAME="15_4">RPM install</A></H2>
|
|
<P>These instructions are for a recent Red Hat with a stock Red Hat
|
|
kernel. We know that Mandrake and SUSE also produce FreeS/WAN RPMs. If
|
|
you're running either, install using your distribution's tools.</P>
|
|
<H3><A NAME="15_4_1">Download RPMs</A></H3>
|
|
<P>Decide which functionality you need:</P>
|
|
<UL>
|
|
<LI>standard FreeS/WAN RPMs. Use these shortcuts:
|
|
<BR>
|
|
<UL>
|
|
<LI>(for 2.6 kernels: userland only)
|
|
<BR> ncftpget
|
|
ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/\*userland*
|
|
</LI>
|
|
<LI>(for 2.4 kernels)
|
|
<BR> ncftpget
|
|
ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/`uname -r
|
|
| tr -d 'a-wy-z'`/\*</LI>
|
|
<LI> or view all the offerings at our<A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs">
|
|
FTP site</A>.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>unofficial<A href="http://www.freeswan.ca/download.php"> Super
|
|
FreeS/WAN</A> RPMs, which include Andreas Steffen's X.509 patch and
|
|
more. Super FreeS/WAN RPMs do not currently include<A HREF="#NAT.gloss">
|
|
Network Address Translation</A> (NAT) traversal, but Super FreeS/WAN
|
|
source does.</LI>
|
|
</UL>
|
|
<A NAME="2.6.rpm"></A>
|
|
<P>For 2.6 kernels, get the latest FreeS/WAN userland RPM, for example:</P>
|
|
<PRE> freeswan-userland-2.04.9-0.i386.rpm</PRE>
|
|
<P>Note: FreeS/WAN's support for 2.6 kernel IPsec is preliminary. Please
|
|
see<A HREf="2.6.known-issues"> 2.6.known-issues</A>, and the latest<A HREF="http://www.freeswan.org/mail.html">
|
|
mailing list reports</A>.</P>
|
|
<P>Change to your new FreeS/WAN directory, and make and install the</P>
|
|
<P>For 2.4 kernels, get both kernel and userland RPMs. Check your kernel
|
|
version with</P>
|
|
<PRE> uname -r</PRE>
|
|
<P>Get a kernel module which matches that version. For example:</P>
|
|
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm</PRE>
|
|
<P>Note: These modules<B> will only work on the Red Hat kernel they were
|
|
built for</B>, since they are very sensitive to small changes in the
|
|
kernel.</P>
|
|
<P>Get FreeS/WAN utilities to match. For example:</P>
|
|
<PRE> freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm</PRE>
|
|
<H3><A NAME="15_4_2">For freeswan.org RPMs: check signatures</A></H3>
|
|
<P>While you're at our ftp site, grab the RPM signing key</P>
|
|
<PRE> freeswan-rpmsign.asc</PRE>
|
|
<P>If you're running RedHat 8.x or later, import this key into the RPM
|
|
database:</P>
|
|
<PRE> rpm --import freeswan-rpmsign.asc</PRE>
|
|
<P>For RedHat 7.x systems, you'll need to add it to your<A HREF="#PGP">
|
|
PGP</A> keyring:</P>
|
|
<PRE> pgp -ka freeswan-rpmsign.asc</PRE>
|
|
<P>Check the digital signatures on both RPMs using:</P>
|
|
<PRE> rpm --checksig freeswan*.rpm </PRE>
|
|
<P>You should see that these signatures are good:</P>
|
|
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
|
|
freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK</PRE>
|
|
<H3><A NAME="15_4_3">Install the RPMs</A></H3>
|
|
<P>Become root:</P>
|
|
<PRE> su</PRE>
|
|
<P>For a first time install, use:</P>
|
|
<PRE> rpm -ivh freeswan*.rpm</PRE>
|
|
<P>To upgrade existing RPMs (and keep all .conf files in place), use:</P>
|
|
<PRE> rpm -Uvh freeswan*.rpm</PRE>
|
|
<P>If you're upgrading from FreeS/WAN 1.x to 2.x RPMs, and encounter
|
|
problems, see<A HREF="#upgrading.rpms"> this note</A>.</P>
|
|
<H3><A NAME="15_4_4">Start and Test FreeS/WAN</A></H3>
|
|
<P>Now,<A HREF="#starttest"> start FreeS/WAN and test your install</A>.</P>
|
|
<A NAME="srcinstall"></A>
|
|
<H2><A NAME="15_5">Install from Source</A></H2>
|
|
|
|
<!-- Most of this section, along with "Start and Test", can replace
|
|
INSTALL. -->
|
|
<H3><A NAME="15_5_1">Decide what functionality you need</A></H3>
|
|
<P>Your choices are:</P>
|
|
<UL>
|
|
<LI><A HREF="ftp://ftp.xs4all.nl/pub/crypto/freeswan">standard FreeS/WAN</A>
|
|
,</LI>
|
|
<LI>standard FreeS/WAN plus any of these<A HREF="#patch"> user-supported
|
|
patches</A>, or</LI>
|
|
<LI><A HREF="http://www.freeswan.ca/download">Super FreeS/WAN</A>, an
|
|
unofficial FreeS/WAN pre-patched with many of the above. Provides
|
|
additional algorithms, X.509, SA deletion, dead peer detection, and<A HREF="#NAT.gloss">
|
|
Network Address Translation</A> (NAT) traversal.</LI>
|
|
</UL>
|
|
<H3><A NAME="15_5_2">Download FreeS/WAN</A></H3>
|
|
<P>Download the source tarball you've chosen, along with any patches.</P>
|
|
<H3><A NAME="15_5_3">For freeswan.org source: check its signature</A></H3>
|
|
<P>While you're at our ftp site, get our source signing key</P>
|
|
<PRE> freeswan-sigkey.asc</PRE>
|
|
<P>Add it to your PGP keyring:</P>
|
|
<PRE> pgp -ka freeswan-sigkey.asc</PRE>
|
|
<P>Check the signature using:</P>
|
|
<PRE> pgp freeswan-2.04.tar.gz.sig freeswan-2.04.tar.gz</PRE>
|
|
<P>You should see something like:</P>
|
|
<PRE> Good signature from user "Linux FreeS/WAN Software Team ([email protected])".
|
|
Signature made 2002/06/26 21:04 GMT using 2047-bit key, key ID 46EAFCE1</PRE>
|
|
|
|
<!-- Note to self: [email protected] has angled brackets in the original.
|
|
Changed because it conflicts with HTML tags. -->
|
|
<H3><A NAME="15_5_4">Untar, unzip</A></H3>
|
|
<P>As root, unpack your FreeS/WAN source into<VAR> /usr/src</VAR>.</P>
|
|
<PRE> su
|
|
mv freeswan-2.04.tar.gz /usr/src
|
|
cd /usr/src
|
|
tar -xzf freeswan-2.04.tar.gz
|
|
</PRE>
|
|
<H3><A NAME="15_5_5">Patch if desired</A></H3>
|
|
<P>Now's the time to add any patches. The contributor may have special
|
|
instructions, or you may simply use the patch command.</P>
|
|
<H3><A NAME="15_5_6">... and Make</A></H3>
|
|
<P>Choose one of the methods below.</P>
|
|
<H4><A NAME="15_5_6_1">Userland-only Install for 2.6 kernels</A></H4>
|
|
<A NAME="2.6.src"></A>
|
|
<P>Note: FreeS/WAN's support for 2.6 kernel IPsec is preliminary. Please
|
|
see<A HREf="2.6.known-issues"> 2.6.known-issues</A>, and the latest<A HREF="http://www.freeswan.org/mail.html">
|
|
mailing list reports</A>.</P>
|
|
<P>Change to your new FreeS/WAN directory, and make and install the
|
|
FreeS/WAN userland tools.</P>
|
|
<PRE> cd /usr/src/freeswan-2.04
|
|
make programs
|
|
make install</PRE>
|
|
<P>Now,<A HREF="#starttest"> start FreeS/WAN and test your install</A>.</P>
|
|
<H4><A NAME="15_5_6_2">KLIPS install for 2.2, 2.4, or 2.6 kernels</A></H4>
|
|
<A NAME="modinstall"></A>
|
|
<P>To make a modular version of KLIPS, along with other FreeS/WAN
|
|
programs you'll need, use the command sequence below. This will change
|
|
to your new FreeS/WAN directory, make the FreeS/WAN module (and other
|
|
stuff), and install it all.</P>
|
|
<PRE> cd /usr/src/freeswan-2.04
|
|
make oldmod
|
|
make minstall</PRE>
|
|
<P><A HREF="#starttest">Start FreeS/WAN and test your install</A>.</P>
|
|
<P>To link KLIPS statically into your kernel (using your old kernel
|
|
settings), and install other FreeS/WAN components, do:</P>
|
|
<PRE> cd /usr/src/freeswan-2.04
|
|
make oldmod
|
|
make minstall</PRE>
|
|
<P>Reboot your system and<A HREF="#testonly"> test your install</A>.</P>
|
|
<P>For other ways to compile KLIPS, see our Makefile.</P>
|
|
<A name="starttest"></A>
|
|
<H2><A NAME="15_6">Start FreeS/WAN and test your install</A></H2>
|
|
<P>Bring FreeS/WAN up with:</P>
|
|
<PRE> service ipsec start</PRE>
|
|
<P>This is not necessary if you've rebooted.</P>
|
|
<A name="testonly"></A>
|
|
<H2><A NAME="15_7">Test your install</A></H2>
|
|
<P>To check that you have a successful install, run:</P>
|
|
<PRE> ipsec verify</PRE>
|
|
<P>You should see at least:</P>
|
|
<PRE>
|
|
Checking your system to see if IPsec got installed and started correctly
|
|
Version check and ipsec on-path [OK]
|
|
Checking for KLIPS support in kernel [OK]
|
|
Checking for RSA private key (/etc/ipsec.secrets) [OK]
|
|
Checking that pluto is running [OK]
|
|
</PRE>
|
|
<P>If any of these first four checks fails, see our<A href="#install.check">
|
|
troubleshooting guide</A>.</P>
|
|
<H2><A NAME="15_8">Making FreeS/WAN play well with others</A></H2>
|
|
<P>There are at least a couple of things on your system that might
|
|
interfere with FreeS/WAN, and now's a good time to check these:</P>
|
|
<UL>
|
|
<LI>Firewalling. You need to allow UDP 500 through your firewall, plus
|
|
ESP (protocol 50) and AH (protocol 51). For more information, see our
|
|
updated firewalls document (coming soon).</LI>
|
|
<LI>Network address translation. Do not NAT the packets you will be
|
|
tunneling.</LI>
|
|
</UL>
|
|
<H2><A NAME="15_9">Configure for your needs</A></H2>
|
|
<P>You'll need to configure FreeS/WAN for your local site. Have a look
|
|
at our<A HREF="quickstart.html"> opportunism quickstart guide</A> to
|
|
see if that easy method is right for your needs. Or, see how to<A HREF="config.html">
|
|
configure a network-to-network or Road Warrior style VPN</A>.</P>
|
|
<HR>
|
|
<H1><A NAME="config">How to configure FreeS/WAN</A></H1>
|
|
<P>This page will teach you how to configure a simple network-to-network
|
|
link or a Road Warrior connection between two Linux FreeS/WAN boxes.</P>
|
|
<P>See also these related documents:</P>
|
|
<UL>
|
|
<LI>our<A HREF="#quickstart"> quickstart</A> guide to<A HREF="#carpediem">
|
|
opportunistic encryption</A></LI>
|
|
<LI>our guide to configuration with<A HREF="#policygroups"> policy
|
|
groups</A></LI>
|
|
<LI>our<A HREF="#adv_config"> advanced configuration</A> document</LI>
|
|
</UL>
|
|
<P> The network-to-network setup allows you to connect two office
|
|
networks into one Virtual Private Network, while the Road Warrior
|
|
connection secures a laptop's telecommute to work. Our examples also
|
|
show the basic procedure on the Linux FreeS/WAN side where another
|
|
IPsec peer is in play.</P>
|
|
<P> Shortcut to<A HREF="#config.netnet"> net-to-net</A>.
|
|
<BR> Shortcut to<A HREF="#config.rw"> Road Warrior</A>.</P>
|
|
<H2><A NAME="16_1">Requirements</A></H2>
|
|
<P>To configure the network-to-network connection you must have:</P>
|
|
<UL>
|
|
<LI>two Linux gateways with static IPs</LI>
|
|
<LI>a network behind each gate. Networks must have non-overlapping IP
|
|
ranges.</LI>
|
|
<LI>Linux FreeS/WAN<A HREF="#install"> installed</A> on both gateways</LI>
|
|
<LI><A HREF="http://www.tcpdump.org"><VAR>tcpdump</VAR></A> on the local
|
|
gate, to test the connection</LI>
|
|
</UL>
|
|
<P>For the Road Warrior you need:</P>
|
|
<UL>
|
|
<LI>one Linux box with a static IP</LI>
|
|
<LI>a Linux laptop with a dynamic IP</LI>
|
|
<LI>Linux FreeS/WAN installed on both</LI>
|
|
<LI>for testing,<VAR> tcpdump</VAR> on your gateway or laptop</LI>
|
|
</UL>
|
|
<P>If both IPs are dynamic, your situation is a bit trickier. Your best
|
|
bet is a variation on the<A HREF="#config.rw"> Road Warrior</A>, as
|
|
described in<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00282.html">
|
|
this mailing list message</A>.</P>
|
|
<H2><A name="config.netnet"></A>Net-to-Net connection</H2>
|
|
<H3><A name="netnet.info.ex">Gather information</A></H3>
|
|
<P>For each gateway, compile the following information:</P>
|
|
<UL>
|
|
<LI>gateway IP</LI>
|
|
<LI>IP range of the subnet you will be protecting. This doesn't have to
|
|
be your whole physical subnet.</LI>
|
|
<LI>a name by which that gateway can identify itself for IPsec
|
|
negotiations. Its form is a Fully Qualified Domain Name preceded by an
|
|
@ sign, ie. @xy.example.com.
|
|
<BR> It does not need to be within a domain that you own. It can be a
|
|
made-up name.</LI>
|
|
</UL>
|
|
<H4><A NAME="16_2_1_1">Get your leftrsasigkey</A></H4>
|
|
<P>On your local Linux FreeS/WAN gateway, print your IPsec public key:</P>
|
|
<PRE> ipsec showhostkey --left</PRE>
|
|
<P>The output should look like this (with the key shortened for easy
|
|
reading):</P>
|
|
<PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002
|
|
leftrsasigkey=0sAQOnwiBPt...</PRE>
|
|
<P>Don't have a key? Use<A HREF="manpage.d/ipsec_newhostkey.8.html"><VAR>
|
|
ipsec newhostkey</VAR></A> to create one.</P>
|
|
<H4><A NAME="16_2_1_2">...and your rightrsasigkey</A></H4>
|
|
<P>Get a console on the remote side:</P>
|
|
<PRE> ssh2 ab.example.com</PRE>
|
|
<P>In that window, type:</P>
|
|
<PRE> ipsec showhostkey --right</PRE>
|
|
<P>You'll see something like:</P>
|
|
<PRE> # RSA 2192 bits ab.example.com Thu May 16 15:26:20 2002
|
|
rightrsasigkey=0sAQOqH55O...</PRE>
|
|
<H3><A NAME="16_2_2">Edit<VAR> /etc/ipsec.conf</VAR></A></H3>
|
|
<P>Back on the local gate, copy our template to<VAR> /etc/ipsec.conf</VAR>
|
|
. (on Mandrake,<VAR> /etc/freeswan/ipsec.conf</VAR>). Substitute the
|
|
information you've gathered for our example data.</P>
|
|
<PRE>conn net-to-net
|
|
left=192.0.2.2 # Local vitals
|
|
leftsubnet=192.0.2.128/29 #
|
|
[email protected] #
|
|
leftrsasigkey=0s1LgR7/oUM... #
|
|
leftnexthop=%defaultroute # correct in many situations
|
|
right=192.0.2.9 # Remote vitals
|
|
rightsubnet=10.0.0.0/24 #
|
|
[email protected] #
|
|
rightrsasigkey=0sAQOqH55O... #
|
|
rightnexthop=%defaultroute # correct in many situations
|
|
auto=add # authorizes but doesn't start this
|
|
# connection at startup</PRE>
|
|
<P> "Left" and "right" should represent the machines that have FreeS/WAN
|
|
installed on them, and "leftsubnet" and "rightsubnet" machines that are
|
|
being protected. /32 is assumed for left/right and left/rightsubnet
|
|
parameters.</P>
|
|
<P>Copy<VAR> conn net-to-net</VAR> to the remote-side /etc/ipsec.conf.
|
|
If you've made no other modifications to either<VAR> ipsec.conf</VAR>,
|
|
simply:</P>
|
|
<PRE> scp2 ipsec.conf [email protected]:/etc/ipsec.conf</PRE>
|
|
<H3><A NAME="16_2_3">Start your connection</A></H3>
|
|
<P>Locally, type:</P>
|
|
<PRE> ipsec auto --up net-to-net</PRE>
|
|
<P>You should see:</P>
|
|
<PRE> 104 "net-net" #223: STATE_MAIN_I1: initiate
|
|
106 "net-net" #223: STATE_MAIN_I2: sent MI2, expecting MR2
|
|
108 "net-net" #223: STATE_MAIN_I3: sent MI3, expecting MR3
|
|
004 "net-net" #223: STATE_MAIN_I4: ISAKMP SA established
|
|
112 "net-net" #224: STATE_QUICK_I1: initiate
|
|
004 "net-net" #224: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE>
|
|
<P>The important thing is<VAR> IPsec SA established</VAR>. If you're
|
|
unsuccessful, see our<A HREF="#trouble"> troubleshooting tips</A>.</P>
|
|
<H3><A NAME="16_2_4">Do not MASQ or NAT packets to be tunneled</A></H3>
|
|
<P>If you are using<A HREF="#masq"> IP masquerade</A> or<A HREF="#NAT.gloss">
|
|
Network Address Translation (NAT)</A> on either gateway, you must now
|
|
exempt the packets you wish to tunnel from this treatment. For example,
|
|
if you have a rule like:</P>
|
|
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
|
|
</PRE>
|
|
<P>change it to something like:</P>
|
|
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE>
|
|
<P>This may be necessary on both gateways.</P>
|
|
<H3><A NAME="16_2_5">Test your connection</A></H3>
|
|
<P>Sit at one of your local subnet nodes (not the gateway), and ping a
|
|
subnet node on the other (again, not the gateway).</P>
|
|
<PRE> ping fileserver.toledo.example.com</PRE>
|
|
<P>While still pinging, go to the local gateway and snoop your outgoing
|
|
interface, for example:</P>
|
|
<PRE> tcpdump -i ppp0</PRE>
|
|
<P>You want to see ESP (Encapsulating Security Payload) packets moving<B>
|
|
back and forth</B> between the two gateways at the same frequency as
|
|
your pings:</P>
|
|
<PRE> 19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
|
|
19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE>
|
|
<P>If you see this, congratulations are in order! You have a tunnel
|
|
which will protect any IP data from one subnet to the other, as it
|
|
passes between the two gates. If not, go and<A HREF="#trouble">
|
|
troubleshoot</A>.</P>
|
|
<P>Note: your new tunnel protects only net-net traffic, not
|
|
gateway-gateway, or gateway-subnet. If you need this (for example, if
|
|
machines on one net need to securely contact a fileserver on the IPsec
|
|
gateway), you'll need to create<A HREF="#adv_config"> extra connections</A>
|
|
.</P>
|
|
<H3><A NAME="16_2_6">Finishing touches</A></H3>
|
|
<P>Now that your connection works, name it something sensible, like:</P>
|
|
<PRE>conn winstonnet-toledonet</PRE>
|
|
<P>To have the tunnel come up on-boot, replace</P>
|
|
<PRE> auto=add</PRE>
|
|
<P>with:</P>
|
|
<PRE> auto=start</PRE>
|
|
<P>Copy these changes to the other side, for example:</P>
|
|
<PRE> scp2 ipsec.conf [email protected]:/etc/ipsec.conf</PRE>
|
|
<P>Enjoy!</P>
|
|
<H2><A name="config.rw"></A>Road Warrior Configuration</H2>
|
|
<H3><A name="rw.info.ex">Gather information</A></H3>
|
|
<P>You'll need to know:</P>
|
|
<UL>
|
|
<LI>the gateway's static IP</LI>
|
|
<LI>the IP range of the subnet behind that gateway</LI>
|
|
<LI>a name by which each side can identify itself for IPsec
|
|
negotiations. Its form is a Fully Qualified Domain Name preceded by an
|
|
@ sign, ie. @road.example.com.
|
|
<BR> It does not need to be within a domain that you own. It can be a
|
|
made-up name.</LI>
|
|
</UL>
|
|
<H4><A NAME="16_3_1_1">Get your leftrsasigkey...</A></H4>
|
|
<P>On your laptop, print your IPsec public key:</P>
|
|
<PRE> ipsec showhostkey --left</PRE>
|
|
<P>The output should look like this (with the key shortened for easy
|
|
reading):</P>
|
|
<PRE> # RSA 2192 bits road.example.com Sun Jun 9 02:45:02 2002
|
|
leftrsasigkey=0sAQPIPN9uI...</PRE>
|
|
<P>Don't have a key? See<A HREF="old_config.html#genrsakey"> these
|
|
instructions</A>.</P>
|
|
<H4><A NAME="16_3_1_2">...and your rightrsasigkey</A></H4>
|
|
<P>Get a console on the gateway:</P>
|
|
<PRE> ssh2 xy.example.com</PRE>
|
|
<P>View the gateway's public key with:</P>
|
|
<PRE> ipsec showhostkey --right</PRE>
|
|
<P>This will yield something like</P>
|
|
<PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002
|
|
rightrsasigkey=0sAQOnwiBPt...</PRE>
|
|
<H3><A NAME="16_3_2">Customize<VAR> /etc/ipsec.conf</VAR></A></H3>
|
|
<P>On your laptop, copy this template to<VAR> /etc/ipsec.conf</VAR>. (on
|
|
Mandrake,<VAR> /etc/freeswan/ipsec.conf</VAR>). Substitute the
|
|
information you've gathered for our example data.</P>
|
|
<PRE>conn road
|
|
left=%defaultroute # Picks up our dynamic IP
|
|
leftnexthop=%defaultroute #
|
|
[email protected] # Local information
|
|
leftrsasigkey=0sAQPIPN9uI... #
|
|
right=192.0.2.10 # Remote information
|
|
rightsubnet=10.0.0.0/24 #
|
|
[email protected] #
|
|
rightrsasigkey=0sAQOnwiBPt... #
|
|
auto=add # authorizes but doesn't start this
|
|
# connection at startup</PRE>
|
|
<P>The template for the gateway is different. Notice how it reverses<VAR>
|
|
left</VAR> and<VAR> right</VAR>, in keeping with our convention that<STRONG>
|
|
L</STRONG>eft is<STRONG> L</STRONG>ocal,<STRONG> R</STRONG>ight<STRONG>
|
|
R</STRONG>emote. Be sure to switch your rsasigkeys in keeping with
|
|
this.</P>
|
|
<PRE> ssh2 xy.example.com
|
|
vi /etc/ipsec.conf</PRE>
|
|
<P>and add:</P>
|
|
<PRE>conn road
|
|
left=192.0.2.2 # Gateway's information
|
|
[email protected] #
|
|
leftsubnet=192.0.2.128/29 #
|
|
leftrsasigkey=0sAQOnwiBPt... #
|
|
rightnexthop=%defaultroute # correct in many situations
|
|
right=%any # Wildcard: we don't know the laptop's IP
|
|
[email protected] #
|
|
rightrsasigkey=0sAQPIPN9uI... #
|
|
auto=add # authorizes but doesn't start this
|
|
# connection at startup</PRE>
|
|
<H3><A NAME="16_3_3">Start your connection</A></H3>
|
|
<P>You must start the connection from the Road Warrior side. On your
|
|
laptop, type:</P>
|
|
<PRE> ipsec auto --start net-to-net</PRE>
|
|
<P>You should see:</P>
|
|
<PRE>104 "net-net" #223: STATE_MAIN_I1: initiate
|
|
106 "road" #301: STATE_MAIN_I2: sent MI2, expecting MR2
|
|
108 "road" #301: STATE_MAIN_I3: sent MI3, expecting MR3
|
|
004 "road" #301: STATE_MAIN_I4: ISAKMP SA established
|
|
112 "road" #302: STATE_QUICK_I1: initiate
|
|
004 "road" #302: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE>
|
|
<P>Look for<VAR> IPsec SA established</VAR>. If you're unsuccessful, see
|
|
our<A HREF="#trouble"> troubleshooting tips</A>.</P>
|
|
<H3><A NAME="16_3_4">Do not MASQ or NAT packets to be tunneled</A></H3>
|
|
<P>If you are using<A HREF="#masq"> IP masquerade</A> or<A HREF="#NAT.gloss">
|
|
Network Address Translation (NAT)</A> on either gateway, you must now
|
|
exempt the packets you wish to tunnel from this treatment. For example,
|
|
if you have a rule like:</P>
|
|
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
|
|
</PRE>
|
|
<P>change it to something like:</P>
|
|
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE>
|
|
<H3><A NAME="16_3_5">Test your connection</A></H3>
|
|
<P>From your laptop, ping a subnet node behind the remote gateway. Do
|
|
not choose the gateway itself for this test.</P>
|
|
<PRE> ping ns.winston.example.com</PRE>
|
|
<P>Snoop the packets exiting the laptop, with a command like:</P>
|
|
<PRE> tcpdump -i wlan0</PRE>
|
|
<P>You have success if you see (Encapsulating Security Payload) packets
|
|
travelling<B> in both directions</B>:</P>
|
|
<PRE> 19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
|
|
19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE>
|
|
<P>If you do, great! Traffic between your Road Warrior and the net
|
|
behind your gateway is protected. If not, see our<A HREF="#trouble">
|
|
troubleshooting hints</A>.</P>
|
|
<P>Your new tunnel protects only traffic addressed to the net, not to
|
|
the IPsec gateway itself. If you need the latter, you'll want to make
|
|
an<A HREF="#adv_config"> extra tunnel.</A>.</P>
|
|
<H3><A NAME="16_3_6">Finishing touches</A></H3>
|
|
<P>On both ends, name your connection wisely, like:</P>
|
|
<PRE>conn mike-to-office</PRE>
|
|
<P><B>On the laptop only,</B> replace</P>
|
|
<PRE> auto=add</PRE>
|
|
<P>with:</P>
|
|
<PRE> auto=start</PRE>
|
|
<P>so that you'll be connected on-boot.</P>
|
|
<P>Happy telecommuting!</P>
|
|
<H3><A NAME="16_3_7">Multiple Road Warriors</A></H3>
|
|
<P>If you're using RSA keys, as we did in this example, you can add as
|
|
many Road Warriors as you like. The left/rightid parameter lets Linux
|
|
FreeS/WAN distinguish between multiple Road Warrior peers, each with
|
|
its own public key.</P>
|
|
<P>The situation is different for shared secrets (PSK). During a PSK
|
|
negotiation, ID information is not available at the time Pluto is
|
|
trying to determine which secret to use, so, effectively, you can only
|
|
define one Roadwarrior connection. All your PSK road warriors must
|
|
therefore share one secret.</P>
|
|
<H2><A NAME="16_4">What next?</A></H2>
|
|
<P>Using the principles illustrated here, you can try variations such
|
|
as:</P>
|
|
<UL>
|
|
<LI>a telecommuter with a static IP</LI>
|
|
<LI>a road warrior with a subnet behind it</LI>
|
|
</UL>
|
|
<P>Or, look at some of our<A HREF="#adv_config"> more complex
|
|
configuration examples.</A>.</P>
|
|
<HR>
|
|
<H1><A name="background">Linux FreeS/WAN background</A></H1>
|
|
<P>This section discusses a number of issues which have three things in
|
|
common:</P>
|
|
<UL>
|
|
<LI>They are not specifically FreeS/WAN problems</LI>
|
|
<LI>You may have to understand them to get FreeS/WAN working right</LI>
|
|
<LI>They are not simple questions</LI>
|
|
</UL>
|
|
<P>Grouping them here lets us provide the explanations some users will
|
|
need without unduly complicating the main text.</P>
|
|
<P>The explanations here are intended to be adequate for FreeS/WAN
|
|
purposes (please comment to the<A href="mail.html"> users mailing list</A>
|
|
if you don't find them so), but they are not trying to be complete or
|
|
definitive. If you need more information, see the references provided
|
|
in each section.</P>
|
|
<H2><A name="dns.background">Some DNS background</A></H2>
|
|
<P><A href="#carpediem">Opportunistic encryption</A> requires that the
|
|
gateway systems be able to fetch public keys, and other IPsec-related
|
|
information, from each other's DNS (Domain Name Service) records.</P>
|
|
<P><A href="#DNS">DNS</A> is a distributed database that maps names to
|
|
IP addresses and vice versa.</P>
|
|
<P>Much good reference material is available for DNS, including:</P>
|
|
<UL>
|
|
<LI>the<A href="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"> DNS HowTo</A>
|
|
</LI>
|
|
<LI>the standard<A href="#DNS.book"> DNS reference</A> book</LI>
|
|
<LI><A href="http://www.linuxdoc.org/LDP/nag2/index.html">Linux Network
|
|
Administrator's Guide</A></LI>
|
|
<LI><A href="http://www.nominum.com/resources/whitepapers/bind-white-paper.html">
|
|
BIND overview</A></LI>
|
|
<LI><A href="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">
|
|
BIND 9 Administrator's Reference</A></LI>
|
|
</UL>
|
|
<P>We give only a brief overview here, intended to help you use DNS for
|
|
FreeS/WAN purposes.</P>
|
|
<H3><A name="forward.reverse">Forward and reverse maps</A></H3>
|
|
<P>Although the implementation is distributed, it is often useful to
|
|
speak of DNS as if it were just two enormous tables:</P>
|
|
<UL>
|
|
<LI>the forward map: look up a name, get an IP address</LI>
|
|
<LI>the reverse map: look up an IP address, get a name</LI>
|
|
</UL>
|
|
<P>Both maps can optionally contain additional data. For opportunistic
|
|
encryption, we insert the data need for IPsec authentication.</P>
|
|
<P>A system named gateway.example.com with IP address 10.20.30.40 should
|
|
have at least two DNS records, one in each map:</P>
|
|
<DL>
|
|
<DT>gateway.example.com. IN A 10.20.30.40</DT>
|
|
<DD>used to look up the name and get an IP address</DD>
|
|
<DT>40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</DT>
|
|
<DD>used for reverse lookups, looking up an address to get the
|
|
associated name. Notice that the digits here are in reverse order; the
|
|
actual address is 10.20.30.40 but we use 40.30.20.10 here.</DD>
|
|
</DL>
|
|
<H3><A NAME="17_1_2">Hierarchy and delegation</A></H3>
|
|
<P>For both maps there is a hierarchy of DNS servers and a system of
|
|
delegating authority so that, for example:</P>
|
|
<UL>
|
|
<LI>the DNS administrator for example.com can create entries of the form<VAR>
|
|
name</VAR>.example.com</LI>
|
|
<LI>the example.com admin cannot create an entry for counterexample.com;
|
|
only someone with authority for .com can do that</LI>
|
|
<LI>an admin might have authority for 20.10.in-addr.arpa.</LI>
|
|
<LI>in either map, authority can be delegated
|
|
<UL>
|
|
<LI>the example.com admin could give you authority for
|
|
westcoast.example.com</LI>
|
|
<LI>the 20.10.in-addr.arpa admin could give you authority for
|
|
30.20.10.in-addr.arpa</LI>
|
|
</UL>
|
|
</LI>
|
|
</UL>
|
|
<P>DNS zones are the units of delegation. There is a hierarchy of zones.</P>
|
|
<H3><A NAME="17_1_3">Syntax of DNS records</A></H3>
|
|
<P>Returning to the example records:</P>
|
|
<PRE> gateway.example.com. IN A 10.20.30.40
|
|
40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</PRE>
|
|
<P>some syntactic details are:</P>
|
|
<UL>
|
|
<LI>the IN indicates that these records are for<STRONG> In</STRONG>
|
|
ternet addresses</LI>
|
|
<LI>The final periods in '.com.' and '.arpa.' are required. They
|
|
indicate the root of the domain name system.</LI>
|
|
</UL>
|
|
<P>The capitalised strings after IN indicate the type of record.
|
|
Possible types include:</P>
|
|
<UL>
|
|
<LI><STRONG>A</STRONG>ddress, for forward lookups</LI>
|
|
<LI><STRONG>P</STRONG>oin<STRONG>T</STRONG>e<STRONG>R</STRONG>, for
|
|
reverse lookups</LI>
|
|
<LI><STRONG>C</STRONG>anonical<STRONG> NAME</STRONG>, records to support
|
|
aliasing, multiple names for one address</LI>
|
|
<LI><STRONG>M</STRONG>ail e<STRONG>X</STRONG>change, used in mail
|
|
routing</LI>
|
|
<LI><STRONG>SIG</STRONG>nature, used in<A href="#SDNS"> secure DNS</A></LI>
|
|
<LI><STRONG>KEY</STRONG>, used in<A href="#SDNS"> secure DNS</A></LI>
|
|
<LI><STRONG>T</STRONG>e<STRONG>XT</STRONG>, a multi-purpose record type</LI>
|
|
</UL>
|
|
<P>To set up for opportunistic encryption, you add some TXT records to
|
|
your DNS data. Details are in our<A href="quickstart.html"> quickstart</A>
|
|
document.</P>
|
|
<H3><A NAME="17_1_4">Cacheing, TTL and propagation delay</A></H3>
|
|
<P>DNS information is extensively cached. With no caching, a lookup by
|
|
your system of "www.freeswan.org" might involve:</P>
|
|
<UL>
|
|
<LI>your system asks your nameserver for "www.freeswan.org"</LI>
|
|
<LI>local nameserver asks root server about ".org", gets reply</LI>
|
|
<LI>local nameserver asks .org nameserver about "freeswan.org", gets
|
|
reply</LI>
|
|
<LI>local nameserver asks freeswan.org nameserver about
|
|
"www.freeswan.org", gets reply</LI>
|
|
</UL>
|
|
<P>However, this can be a bit inefficient. For example, if you are in
|
|
the Phillipines, the closest a root server is in Japan. That might send
|
|
you to a .org server in the US, and then to freeswan.org in Holland. If
|
|
everyone did all those lookups every time they clicked on a web link,
|
|
the net would grind to a halt.</P>
|
|
<P>Nameservers therefore cache information they look up. When you click
|
|
on another link at www.freeswan.org, your local nameserver has the IP
|
|
address for that server in its cache, and no further lookups are
|
|
required.</P>
|
|
<P>Intermediate results are also cached. If you next go to
|
|
lists.freeswan.org, your nameserver can just ask the freeswan.org
|
|
nameserver for that address; it does not need to query the root or .org
|
|
nameservers because it has a cached address for the freeswan.org zone
|
|
server.</P>
|
|
<P>Of course, like any cacheing mechanism, this can create problems of
|
|
consistency. What if the administrator for freeswan.org changes the IP
|
|
address, or the authentication key, for www.freeswan.org? If you use
|
|
old information from the cache, you may get it wrong. On the other
|
|
hand, you cannot afford to look up fresh information every time. Nor
|
|
can you expect the freeswan.org server to notify you; that isn't in the
|
|
protocols.</P>
|
|
<P>The solution that is in the protocols is fairly simple. Cacheable
|
|
records are marked with Time To Live (TTL) information. When the time
|
|
expires, the caching server discards the record. The next time someone
|
|
asks for it, the server fetches a fresh copy. Of course, a server may
|
|
also discard records before their TTL expires if it is running out of
|
|
cache space.</P>
|
|
<P>This implies that there will be some delay before the new version of
|
|
a changed record propagates around the net. Until the TTLs on all
|
|
copies of the old record expire, some users will see it because that is
|
|
what is in their cache. Other users may see the new record immediately
|
|
because they don't have an old one cached.</P>
|
|
<H2><A name="MTU.trouble">Problems with packet fragmentation</A></H2>
|
|
<P>It seems, from mailing list reports, to be moderately common for
|
|
problems to crop up in which small packets pass through the IPsec
|
|
tunnels just fine but larger packets fail.</P>
|
|
<P>These problems are caused by various devices along the way
|
|
mis-handling either packet fragments or<A href="#pathMTU"> path MTU
|
|
discovery</A>.</P>
|
|
<P>IPsec makes packets larger by adding an ESP or AH header. This can
|
|
tickle assorted bugs in fragment handling in routers and firewalls, or
|
|
in path MTU discovery mechanisms, and cause a variety of symptoms which
|
|
are both annoying and, often, quite hard to diagnose.</P>
|
|
<P>An explanation from project technical lead Henry Spencer:</P>
|
|
<PRE>The problem is IP fragmentation; more precisely, the problem is that the
|
|
second, third, etc. fragments of an IP packet are often difficult for
|
|
filtering mechanisms to classify.
|
|
|
|
Routers cannot rely on reassembling the packet, or remembering what was in
|
|
earlier fragments, because the fragments may be out of order or may even
|
|
follow different routes. So any general, worst-case filtering decision
|
|
pretty much has to be made on each fragment independently. (If the router
|
|
knows that it is the only route to the destination, so all fragments
|
|
*must* pass through it, reassembly would be possible... but most routers
|
|
don't want to bother with the complications of that.)
|
|
|
|
All fragments carry roughly the original IP header, but any higher-level
|
|
header is (for IP purposes) just the first part of the packet data... so
|
|
only the first fragment carries that. So, for example, on examining the
|
|
second fragment of a TCP packet, you could tell that it's TCP, but not
|
|
what port number it is destined for -- that information is in the TCP
|
|
header, which appears in the first fragment only.
|
|
|
|
The result of this classification difficulty is that stupid routers and
|
|
over-paranoid firewalls may just throw fragments away. To get through
|
|
them, you must reduce your MTU enough that fragmentation will not occur.
|
|
(In some cases, they might be willing to attempt reassembly, but have very
|
|
limited resources to devote to it, meaning that packets must be small and
|
|
fragments few in number, leading to the same conclusion: smaller MTU.)</PRE>
|
|
<P>In addition to the problem Henry describes, you may also have trouble
|
|
with<A href="#pathMTU"> path MTU discovery</A>.</P>
|
|
<P>By default, FreeS/WAN uses a large<A href="#MTU"> MTU</A> for the
|
|
ipsec device. This avoids some problems, but may complicate others.
|
|
Here's an explanation from Claudia:</P>
|
|
<PRE>Here are a couple of pieces of background information. Apologies if you
|
|
have seen these already. An excerpt from one of my old posts:
|
|
|
|
An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this
|
|
high MTU so that it does not fragment incoming packets before encryption
|
|
and encapsulation. If after IPSec processing packets are larger than 1500,
|
|
[ie. the mtu of eth0] then eth0 will fragment them.
|
|
|
|
Adding IPSec headers adds a certain number of bytes to each packet.
|
|
The MTU of the IPSec interface refers to the maximum size of the packet
|
|
before the IPSec headers are added. In some cases, people find it helpful
|
|
to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.
|
|
|
|
That way, the resulting encapsulated packets don't exceed 1500. On most
|
|
networks, packets less than 1500 will not need to be fragmented.
|
|
|
|
and... (from Henry Spencer)
|
|
|
|
The way it *ought* to work is that the MTU advertised by the ipsecN
|
|
interface should be that of the underlying hardware interface, less a
|
|
pinch for the extra headers needed.
|
|
|
|
Unfortunately, in certain situations this breaks many applications.
|
|
There is a widespread implicit assumption that the smallest MTUs are
|
|
at the ends of paths, not in the middle, and another that MTUs are
|
|
never less than 1500. A lot of code is unprepared to handle paths
|
|
where there is an "interior minimum" in the MTU, especially when it's
|
|
less than 1500. So we advertise a big MTU and just let the resulting
|
|
big packets fragment.
|
|
|
|
This usually works, but we do get bitten in cases where some intermediate
|
|
point can't handle all that fragmentation. We can't win on this one.</PRE>
|
|
<P>The MTU can be changed with an<VAR> overridemtu=</VAR> statement in
|
|
the<VAR> config setup</VAR> section of<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf.5</A>.</P>
|
|
<P>For a discussion of MTU issues and some possible solutions using
|
|
Linux advanced routing facilities, see the<A href="http://www.linuxguruz.org/iptables/howto/2.4routing-15.html#ss15.6">
|
|
Linux 2.4 Advanced Routing HOWTO</A>. For a discussion of MTU and NAT
|
|
(Network Address Translation), see<A HREF="http://harlech.math.ucla.edu/services/ipsec.html">
|
|
James Carter's MTU notes</A>.</P>
|
|
<H2><A name="nat.background">Network address translation (NAT)</A></H2>
|
|
<P><STRONG>N</STRONG>etwork<STRONG> A</STRONG>ddress<STRONG> T</STRONG>
|
|
ranslation is a service provided by some gateway machines. Calling it
|
|
NAPT (adding the word<STRONG> P</STRONG>ort) would be more precise, but
|
|
we will follow the widespread usage.</P>
|
|
<P>A gateway doing NAT rewrites the headers of packets it is forwarding,
|
|
changing one or more of:</P>
|
|
<UL>
|
|
<LI>source address</LI>
|
|
<LI>source port</LI>
|
|
<LI>destination address</LI>
|
|
<LI>destination port</LI>
|
|
</UL>
|
|
<P>On Linux 2.4, NAT services are provided by the<A href="http://netfilter.samba.org">
|
|
netfilter(8)</A> firewall code. There are several<A href="http://netfilter.samba.org/documentation/index.html#HOWTO">
|
|
Netfilter HowTos</A> including one on NAT.</P>
|
|
<P>For older versions of Linux, this was referred to as "IP masquerade"
|
|
and different tools were used. See this<A href="http://www.e-infomax.com/ipmasq/">
|
|
resource page</A>.</P>
|
|
<P>Putting an IPsec gateway behind a NAT gateway is not recommended. See
|
|
our<A href="#NAT"> firewalls document</A>.</P>
|
|
<H3><A NAME="17_3_1">NAT to non-routable addresses</A></H3>
|
|
<P>The most common application of NAT uses private<A href="#non-routable">
|
|
non-routable</A> addresses.</P>
|
|
<P>Often a home or small office network will have:</P>
|
|
<UL>
|
|
<LI>one connection to the Internet</LI>
|
|
<LI>one assigned publicly visible IP address</LI>
|
|
<LI>several machines that all need access to the net</LI>
|
|
</UL>
|
|
<P>Of course this poses a problem since several machines cannot use one
|
|
address. The best solution might be to obtain more addresses, but often
|
|
this is impractical or uneconomical.</P>
|
|
<P>A common solution is to have:</P>
|
|
<UL>
|
|
<LI><A href="#non-routable">non-routable</A> addresses on the local
|
|
network</LI>
|
|
<LI>the gateway machine doing NAT</LI>
|
|
<LI>all packets going outside the LAN rewritten to have the gateway as
|
|
their source address</LI>
|
|
</UL>
|
|
<P>The client machines are set up with reserved<A href="#non-routable">
|
|
non-routable</A> IP addresses defined in RFC 1918. The masquerading
|
|
gateway, the machine with the actual link to the Internet, rewrites
|
|
packet headers so that all packets going onto the Internet appear to
|
|
come from one IP address, that of its Internet interface. It then gets
|
|
all the replies, does some table lookups and more header rewriting, and
|
|
delivers the replies to the appropriate client machines.</P>
|
|
<P>As far as anyone else on the Internet is concerned, the systems
|
|
behind the gateway are completely hidden. Only one machine with one IP
|
|
address is visible.</P>
|
|
<P>For IPsec on such a gateway, you can entirely ignore the NAT in:</P>
|
|
<UL>
|
|
<LI><A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></LI>
|
|
<LI>firewall rules affecting your Internet-side interface</LI>
|
|
</UL>
|
|
<P>Those can be set up exactly as they would be if your gateway had no
|
|
other systems behind it.</P>
|
|
<P>You do, however, have to take account of the NAT in firewall rules
|
|
which affect packet forwarding.</P>
|
|
<H3><A NAME="17_3_2">NAT to routable addresses</A></H3>
|
|
<P>NAT to routable addresses is also possible, but is less common and
|
|
may make for rather tricky routing problems. We will not discuss it
|
|
here. See the<A href="http://netfilter.samba.org/documentation/index.html#HOWTO">
|
|
Netfilter HowTos</A>.</P>
|
|
<HR>
|
|
<H1><A name="user.examples">FreeS/WAN script examples</A></H1>
|
|
This file is intended to hold a collection of user-written example
|
|
scripts or configuration files for use with FreeS/WAN.
|
|
<P> So far it has only one entry.</P>
|
|
<H2><A name="poltorak">Poltorak's Firewall script</A></H2>
|
|
<PRE>
|
|
From: Poltorak Serguei <[email protected]>
|
|
Subject: [Users] Using FreeS/WAN
|
|
Date: Tue, 16 Oct 2001
|
|
|
|
Hello.
|
|
|
|
I'm using FreeS/WAN IPsec for half a year. I learned a lot of things about
|
|
it and I think it would be interesting for someone to see the result of my
|
|
experiments and usage of FreeS/WAN. If you find a mistake in this
|
|
file, please e-mail me. And excuse me for my english... I'm learning.. :)
|
|
|
|
I'll talk about vary simple configuration:
|
|
|
|
addresses prefix = 192.168
|
|
|
|
lan1 sgw1 .0.0/24 (Internet) sgw2 lan2
|
|
.1.0/24---[ .1.1 ; .0.1 ]===================[ .0.10 ; . 2.10 ]---.2.0/24
|
|
|
|
|
|
We need to let lan1 see lan2 across Internet like it is behind sgw1. The
|
|
same for lan2. And we need to do IPX bridge for Novel Clients and NDS
|
|
synchronization.
|
|
|
|
my config:
|
|
------------------- ipsec.conf -------------------
|
|
conn lan1-lan2
|
|
type=tunnel
|
|
compress=yes
|
|
#-------------------
|
|
left=192.168.0.1
|
|
leftsubnet=192.168.1.0/24
|
|
#-------------------
|
|
right=192.168.0.10
|
|
rightsubnet=192.168.2.0/24
|
|
#-------------------
|
|
auth=esp
|
|
authby=secret
|
|
--------------- end of ipsec.conf ----------------
|
|
|
|
ping .2.x from .1.y (y != 1)
|
|
It works?? Fine. Let's continue...
|
|
|
|
Why y != 1 ?? Because kernel of sgw1 have 2 IP addresses and it will choose
|
|
the first IP (which is used to go to Internet) .0.1 and the packet won't go
|
|
through IPsec tunnel :( But if do ping on .1.1 kernel will respond from
|
|
that address (.1.1) and the packet will be tunneled. The same problem occurred then
|
|
.2.x sends a packet to .1.2 which is down at the moment. What happens? .1.1
|
|
sends ARP requesting .1.2... after 3 tries it send to .2.x an destunreach,
|
|
but from his "natural" IP or .0.1 . So the error message won't be delivered!
|
|
It's a big problem...
|
|
|
|
Resolution... One can manipulate with ipsec0 or ipsec0:0 to solve the
|
|
problem (if ipsec0 has .1.1 kernel will send packets correctly), but there
|
|
are powerful and elegant iproute2 :) We simply need to change source address
|
|
of packet that goes to other secure lan. This is done with
|
|
|
|
ip route replace 192.168.2.0/24 via 192.168.0.10 dev ipsec0 src 192.168.1.1
|
|
|
|
Cool!! Now it works!!
|
|
|
|
The second step. We want install firewall on sgw1 and sgw2. Encryption of
|
|
traffic without security isn't a good idea. I don't use {left|right}firewall,
|
|
because I'm running firewall from init scripts.
|
|
|
|
We want IPsec data between lan1-lan2, some ICMP errors (destination
|
|
unreachable, TTL exceeded, parameter problem and source quench), replying on
|
|
pings from both lans and Internet, ipxtunnel data for IPX and of course SSH
|
|
between sgw1 and sgw2 and from/to one specified host.
|
|
|
|
I'm using ipchains. With iptables there are some changes.
|
|
|
|
---------------- rc.firewall ---------------------
|
|
#!/bin/sh
|
|
#
|
|
# Firewall for IPsec lan1-lan2
|
|
#
|
|
|
|
IPC=/sbin/ipchains
|
|
ANY=0.0.0.0/0
|
|
|
|
# left
|
|
SGW1_EXT=192.168.0.1
|
|
SGW1_INT=192.168.1.1
|
|
LAN1=192.168.1.0/24
|
|
|
|
# right
|
|
SGW2_EXT=192.168.0.10
|
|
SGW2_INT=192.168.2.10
|
|
LAN2=192.168.2.0/24
|
|
|
|
# SSH from and to this host
|
|
SSH_PEER_HOST=_SOME_HOST_
|
|
|
|
# this is for left. exchange these values for right.
|
|
MY_EXT=$SGW1_EXT
|
|
MY_INT=$SGW1_INT
|
|
PEER_EXT=$SGW2_EXT
|
|
PEER_INT=$SGW2_INT
|
|
INT_IF=eth1
|
|
EXT_IF=eth0
|
|
IPSEC_IF=ipsec0
|
|
MY_LAN=$LAN1
|
|
PEER_LAN=$LAN2
|
|
|
|
$IPC -F
|
|
$IPC -P input DENY
|
|
$IPC -P forward DENY
|
|
$IPC -P output DENY
|
|
|
|
# Loopback traffic
|
|
$IPC -A input -i lo -j ACCEPT
|
|
$IPC -A output -i lo -j ACCEPT
|
|
|
|
# for IPsec SGW1-SGW2
|
|
## IKE
|
|
$IPC -A input -p udp -s $PEER_EXT 500 -d $MY_EXT 500 -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p udp -s $MY_EXT 500 -d $PEER_EXT 500 -i $EXT_IF -j ACCEPT
|
|
## ESP
|
|
$IPC -A input -p 50 -s $PEER_EXT -d $MY_EXT -i $EXT_IF -j ACCEPT
|
|
### we don't need this line ### $IPC -A output -p 50 -s $MY_EXT -d $PEER_EXT -i $EXT_IF -j ACCEPT
|
|
## forward LAN1-LAN2
|
|
$IPC -A forward -s $MY_LAN -d $PEER_LAN -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A forward -s $PEER_LAN -d $MY_LAN -i $INT_IF -j ACCEPT
|
|
$IPC -A output -s $PEER_LAN -d $MY_LAN -i $INT_IF -j ACCEPT
|
|
$IPC -A input -s $PEER_LAN -d $MY_LAN -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A input -s $MY_LAN -d $PEER_LAN -i $INT_IF -j ACCEPT
|
|
$IPC -A output -s $MY_LAN -d $PEER_LAN -i $IPSEC_IF -j ACCEPT
|
|
|
|
# ICMP
|
|
#
|
|
## Dest unreachable
|
|
### from/to Internet
|
|
$IPC -A input -p icmp --icmp-type destination-unreachable -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type destination-unreachable -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
|
|
### from/to Lan
|
|
$IPC -A input -p icmp --icmp-type destination-unreachable -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type destination-unreachable -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
|
|
### from/to Peer Lan
|
|
$IPC -A input -p icmp --icmp-type destination-unreachable -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type destination-unreachable -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
|
|
#
|
|
## Source quench
|
|
### from/to Internet
|
|
$IPC -A input -p icmp --icmp-type source-quench -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type source-quench -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
|
|
### from/to Lan
|
|
$IPC -A input -p icmp --icmp-type source-quench -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type source-quench -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
|
|
### from/to Peer Lan
|
|
$IPC -A input -p icmp --icmp-type source-quench -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type source-quench -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
|
|
#
|
|
## Parameter problem
|
|
### from/to Internet
|
|
$IPC -A input -p icmp --icmp-type parameter-problem -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type parameter-problem -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
|
|
### from/to Lan
|
|
$IPC -A input -p icmp --icmp-type parameter-problem -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type parameter-problem -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
|
|
### from/to Peer Lan
|
|
$IPC -A input -p icmp --icmp-type parameter-problem -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type parameter-problem -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
|
|
#
|
|
## Time To Live exceeded
|
|
### from/to Internet
|
|
$IPC -A input -p icmp --icmp-type time-exceeded -s $ANY -d $MY_EXT -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type time-exceeded -s $MY_EXT -d $ANY -i $EXT_IF -j ACCEPT
|
|
### to Lan
|
|
$IPC -A input -p icmp --icmp-type time-exceeded -s $ANY -d $MY_INT -i $INT_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type time-exceeded -s $MY_INT -d $ANY -i $INT_IF -j ACCEPT
|
|
### to Peer Lan
|
|
$IPC -A input -p icmp --icmp-type time-exceeded -s $ANY -d $MY_INT -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A output -p icmp --icmp-type time-exceeded -s $MY_INT -d $ANY -i $IPSEC_IF -j ACCEPT
|
|
|
|
# ICMP PINGs
|
|
## from Internet
|
|
$IPC -A input -p icmp -s $ANY -d $MY_EXT --icmp-type echo-request -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p icmp -s $MY_EXT -d $ANY --icmp-type echo-reply -i $EXT_IF -j ACCEPT
|
|
## from LAN
|
|
$IPC -A input -p icmp -s $ANY -d $MY_INT --icmp-type echo-request -i $INT_IF -j ACCEPT
|
|
$IPC -A output -p icmp -s $MY_INT -d $ANY --icmp-type echo-reply -i $INT_IF -j ACCEPT
|
|
## from Peer LAN
|
|
$IPC -A input -p icmp -s $ANY -d $MY_INT --icmp-type echo-request -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A output -p icmp -s $MY_INT -d $ANY --icmp-type echo-reply -i $IPSEC_IF -j ACCEPT
|
|
|
|
# SSH
|
|
## from SSH_PEER_HOST
|
|
$IPC -A input -p tcp -s $SSH_PEER_HOST -d $MY_EXT 22 -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p tcp \! -y -s $MY_EXT 22 -d $SSH_PEER_HOST -i $EXT_IF -j ACCEPT
|
|
## to SSH_PEER_HOST
|
|
$IPC -A input -p tcp \! -y -s $SSH_PEER_HOST 22 -d $MY_EXT -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p tcp -s $MY_EXT -d $SSH_PEER_HOST 22 -i $EXT_IF -j ACCEPT
|
|
## from PEER
|
|
$IPC -A input -p tcp -s $PEER_EXT -d $MY_EXT 22 -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p tcp \! -y -s $MY_EXT 22 -d $PEER_EXT -i $EXT_IF -j ACCEPT
|
|
## to PEER
|
|
$IPC -A input -p tcp \! -y -s $PEER_EXT 22 -d $MY_EXT -i $EXT_IF -j ACCEPT
|
|
$IPC -A output -p tcp -s $MY_EXT -d $PEER_EXT 22 -i $EXT_IF -j ACCEPT
|
|
|
|
# ipxtunnel
|
|
$IPC -A input -p udp -s $PEER_INT 2005 -d $MY_INT 2005 -i $IPSEC_IF -j ACCEPT
|
|
$IPC -A output -p udp -s $MY_INT 2005 -d $PEER_INT 2005 -i $IPSEC_IF -j ACCEPT
|
|
|
|
---------------- end of rc.firewall ----------------------
|
|
|
|
To understand this we need to look on this scheme:
|
|
|
|
++-----------------------<----------------------------+
|
|
|| ipsec0 |
|
|
\/ |
|
|
eth0 +--------+ /---------/ yes /---------/ yes +-----------------------+
|
|
------>| INPUT |-->/ ?local? /----->/ ?IPsec? /----->| decrypt decapsulate |
|
|
eth1 +--------+ /---------/ /---------/ +-----------------------+
|
|
|| no || no
|
|
\/ \/
|
|
+----------+ +---------+ +-------+
|
|
| routing | | local | | local |
|
|
| decision | | deliver | | send |
|
|
+----------+ +---------+ +-------+
|
|
|| ||
|
|
\/ \/
|
|
+---------+ +----------+
|
|
| forward | | routing |
|
|
+---------+ | decision |
|
|
|| +----------+
|
|
|| ||
|
|
++----------------<-----------------++
|
|
||
|
|
\/
|
|
+--------+ eth0
|
|
| OUTPUT | eth1
|
|
+--------+ ipsec0
|
|
||
|
|
\/
|
|
/---------/ yes +-----------------------+
|
|
/ ?IPsec? /----->| encrypt encapsulate |
|
|
/---------/ +-----------------------+
|
|
|| no ||
|
|
|| ||
|
|
|| \/ eth0, eth1
|
|
++-----------------------++-------------->
|
|
|
|
This explain how a packet traverse TCP/IP stack in IPsec capable kernel.
|
|
|
|
FIX ME, please, if there are any errors
|
|
|
|
Test the new firewall now.
|
|
|
|
|
|
Now about IPX. I tried 3 programs for tunneling IPX: tipxd, SIB and ipxtunnel
|
|
|
|
tipxd didn't send packets.. :(
|
|
SIB and ipxtunnel worked fine :)
|
|
With ipxtunnel there was a little problem. In sources there are an error.
|
|
|
|
--------------------- in main.c ------------------------
|
|
< bytes += p.len;
|
|
---
|
|
> bytes += len;
|
|
--------------------------------------------------------
|
|
|
|
After this FIX everything goes right...
|
|
|
|
------------------- /etc/ipxtunnel.conf ----------------
|
|
port 2005
|
|
remote 192.168.101.97 2005
|
|
interface eth1
|
|
--------------- end of /etc/ipxtunnel.conf -------------
|
|
|
|
I use IPX tunnel between .1.1 and .2.10 so we don't need to encrypt nor
|
|
authenticate encapsulated IPX packets, it is done with IPsec.
|
|
|
|
If you don't wont to use iproute2 to change source IP you need to use SIB
|
|
(it is able to bind local address) or establish tunnel between .0.1 and
|
|
.0.10 (external IPs, you need to do encryption in the program, but it isn't
|
|
strong).
|
|
|
|
For now I'm using ipxtunnel.
|
|
|
|
I think that's all for the moment. If there are any error, please e-mail me:
|
|
[email protected] . It would be cool if someone puts the scheme of TCP/IP in
|
|
kernel and firewall example on FreeS/WAN's manual pages.
|
|
|
|
PoltoS
|
|
</PRE>
|
|
<HR>
|
|
<H1><A name="makecheck">How to configure to use "make check"</A></H1>
|
|
<H2><A NAME="19_1">What is "make check"</A></H2>
|
|
<P> "make check" is a target in the top level makefile. It takes care of
|
|
running a number of unit and system tests to confirm that FreeSWAN has
|
|
been compiled correctly, and that no new bugs have been introduced.</P>
|
|
<P> As FreeSWAN contains both kernel and userspace components, doing
|
|
testing of FreeSWAN requires that the kernel be simulated. This is
|
|
typically difficult to do as a kernel requires that it be run on bare
|
|
hardware. A technology has emerged that makes this simpler. This is<A HREF="http://user-mode-linux.sourceforge.net">
|
|
User Mode Linux</A>.</P>
|
|
<P> User-Mode Linux is a way to build a Linux kernel such that it can
|
|
run as a process under another Linux (or in the future other) kernel.
|
|
Presently, this can only be done for 2.4 guest kernels. The host kernel
|
|
can be 2.2 or 2.4.</P>
|
|
<P> "make check" expects to be able to build User-Mode Linux kernels
|
|
with FreeSWAN included. To do this it needs to have some files
|
|
downloaded and extracted prior to running "make check". This is
|
|
described in the<A HREF="umltesting.html"> UML testing</A> document.</P>
|
|
<P> After having run the example in the UML testing document and
|
|
successfully brought up the four machine combination, you are ready to
|
|
use "make check"</P>
|
|
<H2><A NAME="19_2">Running "make check"</A></H2>
|
|
<P> "make check" works by walking the FreeSWAN source tree invoking the
|
|
"check" target at each node. At present there are tests defined only
|
|
for the <CODE>klips</CODE> directory. These tests will use the UML
|
|
infrastructure to test out pieces of the <CODE>klips</CODE> code.</P>
|
|
<P> The results of the tests can be recorded. If the environment
|
|
variable <CODE>$REGRESSRESULTS</CODE> is non-null, then the results of
|
|
each test will be recorded. This can be used as part of a nightly
|
|
regression testing system, see<A HREF="nightly.html"> Nightly testing</A>
|
|
for more details.</P>
|
|
<P> "make check" otherwise prints a minimal amount of output for each
|
|
test, and indicates pass/fail status of each test as they are run.
|
|
Failed tests do not cause failure of the target in the form of exit
|
|
codes.</P>
|
|
<H1><A NAME="20">How to write a "make check" test</A></H1>
|
|
<H2><A NAME="20_1">Structure of a test</A></H2>
|
|
<P> Each test consists of a set of directories under <CODE>testing/</CODE>
|
|
. There are directories for <CODE>klips</CODE>, <CODE>pluto</CODE>, <CODE>
|
|
packaging</CODE> and <CODE>libraries</CODE>. Each directory has a list
|
|
of tests to run is stored in a file called <CODE>TESTLIST</CODE> in
|
|
that directory. e.g. <CODE>testing/klips/TESTLIST</CODE>.</P>
|
|
<H2 NAME="TESTLIST"><A NAME="20_2">The TESTLIST</A></H2>
|
|
<P> This isn't actually a shell script. It just looks like one. Some
|
|
tools other than /bin/sh process it. Lines that start with # are
|
|
comments.</P>
|
|
<PRE>
|
|
# test-kind directory-containing-test expectation [PR#]
|
|
</PRE>
|
|
<P>The first word provides the test type, detailed below.</P>
|
|
<P> The second word is the name of the test to run. This the directory
|
|
in which the test case is to be found..</P>
|
|
<P>The third word may be one of:</P>
|
|
<DL>
|
|
<DT> blank/good</DT>
|
|
<DD>the test is believed to function, report failure</DD>
|
|
<DT> bad</DT>
|
|
<DD> the test is known to fail, report unexpected success</DD>
|
|
<DT> suspended</DT>
|
|
<DD> the test should not be run</DD>
|
|
</DL>
|
|
<P> The fourth word may be a number, which is a PR# if the test is
|
|
failing.</P>
|
|
<H2><A NAME="20_3">Test kinds</A></H2>
|
|
The test types are:
|
|
<DL>
|
|
<DT>skiptest</DT>
|
|
<DD>means run no test.</DD>
|
|
<DT>ctltest</DT>
|
|
<DD>means run a single system without input/output.</DD>
|
|
<DT>klipstest</DT>
|
|
<DD>means run a single system with input/output networks</DD>
|
|
<DT><A HREF="#umlplutotest">umlplutotest</A></DT>
|
|
<DD>means run a pair of systems</DD>
|
|
<DT><A HREF="#umlXhost">umlXhost</A></DT>
|
|
<DD>run an arbitrary number of systems</DD>
|
|
<DT>suntest (TBD)</DT>
|
|
<DD>means run a quad of east/west/sunrise/sunset</DD>
|
|
<DT>roadtest (TBD)</DT>
|
|
<DD>means run a trio of east-sunrise + warrior</DD>
|
|
<DT>extrudedtest (TBD)</DT>
|
|
<DD>means run a quad of east-sunrise + warriorsouth + park</DD>
|
|
<DT>mkinsttest</DT>
|
|
<DD>a test of the "make install" machinery.</DD>
|
|
<DT>kernel_test_patch</DT>
|
|
<DD>a test of the "make kernelpatch" machinery.</DD>
|
|
</DL>
|
|
Tests marked (TBD) have yet to be fully defined.
|
|
<P> Each test directory has a file in it called <CODE>testparams.sh</CODE>
|
|
. This file sets a number of environment variables to define the
|
|
parameters of the test.</P>
|
|
<H2><A NAME="20_4">Common parameters</A></H2>
|
|
<DL>
|
|
<DT>TESTNAME</DT>
|
|
<DD>the name of the test (repeated for checking purposes)</DD>
|
|
<DT>TEST_TYPE</DT>
|
|
<DD>the type of the test (repeat of type type above)</DD>
|
|
<DT>TESTHOST</DT>
|
|
<DD>the name of the UML machine to run for the test, typically "east" or
|
|
"west"</DD>
|
|
<DT>TEST_PURPOSE</DT>
|
|
<DD>The purpose of the test is one of:
|
|
<DL>
|
|
<DT>goal</DT>
|
|
<DD>The goal purpose is where a test is defined for code that is not yet
|
|
finished. The test indicates when the goals have in fact been reached.</DD>
|
|
<DT>regress</DT>
|
|
<DD>This is a test to determine that a previously existing bug has been
|
|
repaired. This test will initially be created to reproduce the bug in
|
|
isolation, and then the bug will be fixed.</DD>
|
|
<DT>exploit</DT>
|
|
<DD>This is a set of packets/programs that causes a vulnerability to be
|
|
exposed. It is a specific variation of the regress option.</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>TEST_GOAL_ITEM</DT>
|
|
<DT></DT>
|
|
<DD>in the case of a goal test, this is a reference to the requirements
|
|
document</DD>
|
|
<DT>TEST_PROB_REPORT</DT>
|
|
<DD>in the case of regression test, this the problem report number from
|
|
GNATS</DD>
|
|
<DT>TEST_EXPLOIT_URL</DT>
|
|
<DD>in the case of an exploit, this is a URL referencing the paper
|
|
explaining the origin of the test and the origin of exploit software</DD>
|
|
<DT>REF_CONSOLE_OUTPUT</DT>
|
|
<DD>a file in the test directory that contains the sanitized console
|
|
output against which to compare the output of the actual test.</DD>
|
|
<DT>REF_CONSOLE_FIXUPS</DT>
|
|
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
|
|
to sanitize the console output of the machine under test. These are
|
|
typically perl, awk or sed scripts that remove things in the kernel
|
|
output that change each time the test is run and/or compiled.</DD>
|
|
<DT>INIT_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode prior to starting the tests. This file will usually
|
|
set up any eroute's and SADB entries that are required for the test.</P>
|
|
<P>Lines beginning with # are skipped. Blank lines are skipped.
|
|
Otherwise, a shell prompted is waited for each time (consisting of <CODE>
|
|
\n#</CODE>) and then the command is sent. Note that the prompt is waited
|
|
for before the command and not after, so completion of the last command
|
|
in the script is not required. This is often used to invoke a program
|
|
to monitor the system, e.g. <CODE>ipsec pf_key</CODE>.</P>
|
|
</DD>
|
|
<DT>RUN_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, before the packets are sent. On single machine tests,
|
|
this script doesn't provide any more power than INIT_SCRIPT, but is
|
|
implemented for consistency's sake.</P>
|
|
</DD>
|
|
<DT>FINAL_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode after the final packet is sent. Similar to
|
|
INIT_SCRIPT, above. If not specified, then the single command "halt" is
|
|
sent. If specified, then the script should end with a halt command to
|
|
nicely shutdown the UML.</P>
|
|
</DD>
|
|
<DT>CONSOLEDIFFDEBUG</DT>
|
|
<DD>If set to "true" then the series of console fixups (see
|
|
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
|
|
be set to "false", or unset otherwise)</DD>
|
|
<DT>NETJIGDEBUG</DT>
|
|
<DD>If set to "true" then the series of console fixups (see
|
|
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
|
|
be set to "false", or unset otherwise)</DD>
|
|
<DT>NETJIGTESTDEBUG</DT>
|
|
<DD> If set to "netjig", then the results of talking to the <CODE>
|
|
uml_netjig</CODE> will be printed to stderr during the test. In
|
|
addition, the jig will be invoked with --debug, which causes it to log
|
|
its process ID, and wait 60 seconds before continuing. This can be used
|
|
if you are trying to debug the <CODE>uml_netjig</CODE> program itself.</DD>
|
|
<DT>HOSTTESTDEBUG</DT>
|
|
<DD> If set to "hosttest", then the results of taling to the consoles of
|
|
the UMLs will be printed to stderr during the test.</DD>
|
|
<DT>NETJIGWAITUSER</DT>
|
|
<DD> If set to "waituser", then the scripts will wait forever for user
|
|
input before they shut the tests down. Use this is if you are debugging
|
|
through the kernel.</DD>
|
|
<DT>PACKETRATE</DT>
|
|
<DD> A number, in miliseconds (default is 500ms) at which packets will
|
|
be replayed by the netjig.</DD>
|
|
</DL>
|
|
<H2><A NAME="20_5">KLIPStest paramaters</A></H2>
|
|
<P> The klipstest function starts a program (<CODE>
|
|
testing/utils/uml_netjig/uml_netjig</CODE>) to setup a bunch of I/O
|
|
sockets (that simulate network interfaces). It then exports the
|
|
references to these sockets to the environment and invokes (using
|
|
system()) a given script. It waits for the script to finish.</P>
|
|
|
|
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
|
|
<P> The script invoked (<CODE>testing/utils/host-test.tcl</CODE>) is a
|
|
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
|
|
to start the UML and configure it appropriately for the test. The
|
|
configuration is done with the script given above for<VAR> INIT_SCRIPT</VAR>
|
|
. The TCL script then forks, leaves the UML in the background and exits.
|
|
uml_netjig continues. It then starts listening to the simulated network
|
|
answering ARPs and inserting packets as appropriate.</P>
|
|
<P> The klipstest function invokes <CODE>uml_netjig</CODE> with
|
|
arguments to capture output from network interface(s) and insert
|
|
packets as appropriate:</P>
|
|
<DL>
|
|
<DT>PUB_INPUT</DT>
|
|
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
|
|
public (encrypted) interface. (typically, eth1)</DD>
|
|
<DT>PRIV_INPUT</DT>
|
|
<DD>a pcap file to feed in on the private (plain-text) interface
|
|
(typically, eth0).</DD>
|
|
<DT>REF_PUB_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the public (eth1)
|
|
interface are captured to a<A HREF="http://www.tcpdump.org/"> pcap</A>
|
|
file by <CODE>uml_netjig</CODE>. The klipstest function then uses
|
|
tcpdump on the file to produce text output, which is compared to the
|
|
file given.</DD>
|
|
<DT>REF_PUB_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>REF_PRIV_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the private (eth0)
|
|
interface are captured and compared after conversion by tcpdump, as
|
|
with<VAR> REFPUBOUTPUT</VAR>.</DD>
|
|
<DT>REF_PRIV_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>EXITONEMPTY</DT>
|
|
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain
|
|
"--exitonempty" of uml_netjig should exit when all of the input (<VAR>
|
|
PUBINPUT</VAR>,<VAR>PRIVINPUT</VAR>) packets have been injected.</DD>
|
|
<DT>ARPREPLY</DT>
|
|
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain "--arpreply"
|
|
if <CODE>uml_netjig</CODE> should reply to ARP requests. One will
|
|
typically set this to avoid having to fudge the ARP cache manually.</DD>
|
|
<DT>TCPDUMPFLAGS</DT>
|
|
<DD>a set of flags for the tcpdump used when converting captured output.
|
|
Typical values will include "-n" to turn off DNS, and often "-E" to set
|
|
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
|
|
"-t" flag (turn off timestamps) is provided automatically</DD>
|
|
<DT>NETJIG_EXTRA</DT>
|
|
<DD>additional comments to be sent to the netjig. This may arrange to
|
|
record or create additional networks, or may toggle options.</DD>
|
|
</DL>
|
|
<H2><A NAME="20_6">mkinsttest paramaters</A></H2>
|
|
<P> The basic concept of the <CODE>mkinsttest</CODE> test type is that
|
|
it performs a "make install" to a temporary $DESTDIR. The resulting
|
|
tree can then be examined to determine if it was done properly. The
|
|
files can be uninstalled to determine if the file list was correct, or
|
|
the contents of files can be examined more precisely.</P>
|
|
<DL>
|
|
<DT>INSTALL_FLAGS</DT>
|
|
<DD>If set, then an install will be done. This provides the set of flags
|
|
to provide for the install. The target to be used (usually "install")
|
|
must be among the flags.</DD>
|
|
<DT>POSTINSTALL_SCRIPT</DT>
|
|
<DD>If set, a script to run after initial "make install". Two arguments
|
|
are provided: an absolute path to the root of the FreeSWAN src tree,
|
|
and an absolute path to the temporary installation area.</DD>
|
|
<DT>INSTALL2_FLAGS</DT>
|
|
<DD>If set, a second install will be done using these flags. Similarly
|
|
to INSTALL_FLAGS, the target must be among the flags.</DD>
|
|
<DT>UNINSTALL_FLAGS</DT>
|
|
<DD>If set, an uninstall will be done using these flags. Similarly to
|
|
INSTALL_FLAGS, the target (usually "uninstall") must be among the
|
|
flags.</DD>
|
|
<DT>REF_FIND_f_l_OUTPUT</DT>
|
|
<DD>If set, a <CODE>find $ROOT ( -type f -or -type -l )</CODE> will be
|
|
done to get a list of a real files and symlinks. The resulting file
|
|
will be compared to the file listed by this option.</DD>
|
|
<DT>REF_FILE_CONTENTS</DT>
|
|
<DD>If set, it should point to a file containing records for the form:
|
|
<PRE>
|
|
|
|
<!--VARIABLE-->
|
|
reffile</(null)>
|
|
<!--VARIABLE-->
|
|
samplefile</(null)>
|
|
</PRE>
|
|
one record per line. A diff between the provided reference file, and
|
|
the sample file (located in the temporary installation root) will be
|
|
done for each record.</DD>
|
|
</DL>
|
|
<H2><A NAME="20_7">rpm_build_install_test paramaters</A></H2>
|
|
<P> The <CODE>rpm_build_install_test</CODE> type is to verify that the
|
|
proper packing list is produced by "make rpm", and that the mechanisms
|
|
for building the kernel modules produce consistent results.</P>
|
|
<DL>
|
|
<DT>RPM_KERNEL_SOURCE</DT>
|
|
<DD>Point to an extracted copy of the RedHat kernel source code.
|
|
Variables from the environment may be used.</DD>
|
|
<DT>REF_RPM_CONTENTS</DT>
|
|
<DD>This is a file containing one record per line. Each record consists
|
|
of a RPM name (may contain wildcards) and a filename to compare the
|
|
contents to. The RPM will be located and a file list will be produced
|
|
with rpm2cpio.</DD>
|
|
</DL>
|
|
<H2><A NAME="20_8">libtest paramaters</A></H2>
|
|
<P> The libtest test is for testing library routines. The library file
|
|
is expected to provided an <CODE>#ifdef</CODE> by the name of<VAR>
|
|
library</VAR>
|
|
<!--CODE_MAIN</CODE-->
|
|
. The libtest type invokes the C compiler to compile this
|
|
file, links it against <CODE>libfreeswan.a</CODE> (to resolve any other
|
|
dependancies) and runs the test with the <CODE>-r</CODE> argument to
|
|
invoke a regression test.</(null)></P>
|
|
<P>The library test case is expected to do a self-test, exiting with
|
|
status code 0 if everything is okay, and with non-zero otherwise. A
|
|
core dump (exit code greater than 128) is noted specifically.</P>
|
|
<P> Unlike other tests, there are no subdirectories required, or other
|
|
parameters to set.</P>
|
|
<H2 NAME="umlplutotest"><A NAME="20_9">umlplutotest paramaters</A></H2>
|
|
<P> The umlplutotest function starts a pair of user mode line processes.
|
|
This is a 2-host version of umlXhost. The "EAST" and "WEST" slots are
|
|
defined.</P>
|
|
<H2 NAME="umlXhost"><A NAME="20_10">umlXhost parameters</A></H2>
|
|
<P> The umlXtest function starts an arbitrary number of user mode line
|
|
processes.</P>
|
|
|
|
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
|
|
<P> The script invoked (<CODE>testing/utils/Xhost-test.tcl</CODE>) is a
|
|
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
|
|
to start each UML and configure it appropriately for the test. It then
|
|
starts listening (using uml_netjig) to the simulated network answering
|
|
ARPs and inserting packets as appropriate.</P>
|
|
<P> umlXtest has a series of slots, each of which should be filled by a
|
|
host. The list of slots is controlled by the variable, XHOST_LIST. This
|
|
variable should be set to a space seperated list of slots. The former
|
|
umlplutotest is now implemented as a variation of the umlXhost test,
|
|
with XHOST_LIST="EAST WEST".</P>
|
|
<P> For each host slot that is defined, a series of variables should be
|
|
filled in, defining what configuration scripts to use for that host.</P>
|
|
<P> The following are used to control the console input and output to
|
|
the system. Where the string ${host} is present, the host slot should
|
|
be filled in. I.e. for the two host system with XHOST_LIST="EAST WEST",
|
|
then the variables: EAST_INIT_SCRIPT and WEST_INIT_SCRIPT will exist.</P>
|
|
<DL>
|
|
<DT>${host}HOST</DT>
|
|
<DD>The name of the UML host which will fill this slot</DD>
|
|
<DT>${host}_INIT_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode prior to starting the tests. This file will usually
|
|
set up any eroute's and SADB entries that are required for the test.
|
|
Similar to INIT_SCRIPT, above.</P>
|
|
</DD>
|
|
<DT>${host}_RUN_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, before the packets are sent. This set of commands is
|
|
run after all of the virtual machines are initialized. I.e. after
|
|
EAST_INIT_SCRIPT<B> AND</B> WEST_INIT_SCRIPT. This script can therefore
|
|
do things that require that all machines are properly configured.</P>
|
|
</DD>
|
|
<DT>${host}_RUN2_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, after the packets are sent. This set of commands is
|
|
run before any of the virtual machines have been shut down. (I.e.
|
|
before EAST_FINAL_SCRIPT<B> AND</B> WEST_FINAL_SCRIPT.) This script can
|
|
therefore catch post-activity status reports.</P>
|
|
</DD>
|
|
<DT>${host}_FINAL_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode after the final packet is sent. Similar to
|
|
INIT_SCRIPT, above. If not specified, then the single command "halt" is
|
|
sent. Note that when this script is run, the other virtual machines may
|
|
already have been killed. If specified, then the script should end with
|
|
a halt command to nicely shutdown the UML.</P>
|
|
</DD>
|
|
<DT>REF_${host}_CONSOLE_OUTPUT</DT>
|
|
<DD>Similar to REF_CONSOLE_OUTPUT, above.</DD>
|
|
</DL>
|
|
<P>Some additional flags apply to all hosts:</P>
|
|
<DL>
|
|
<DT>REF_CONSOLE_FIXUPS</DT>
|
|
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
|
|
to sanitize the console output of the machine under test. These are
|
|
typically perl, awk or sed scripts that remove things in the kernel
|
|
output that change each time the test is run and/or compiled.</DD>
|
|
</DL>
|
|
<P> In addition to input to the console, the networks may have input fed
|
|
to them:</P>
|
|
<DL>
|
|
<DT>EAST_INPUT/WEST_INPUT</DT>
|
|
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
|
|
private network side of each network. The "EAST" and "WEST" here refer
|
|
to the networks, not the hosts.</DD>
|
|
<DT>REF_PUB_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>REF_EAST_FILTER/REF_WEST_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<
|
|
<DT>TCPDUMPFLAGS</DT>
|
|
<DD>a set of flags for the tcpdump used when converting captured output.
|
|
Typical values will include "-n" to turn off DNS, and often "-E" to set
|
|
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
|
|
"-t" flag (turn off timestamps) is provided automatically</DD>
|
|
<DT>REF_EAST_OUTPUT/REF_WEST_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the private (eth0)
|
|
interface are captured and compared after conversion by tcpdump, as
|
|
with<VAR> REF_PUB_OUTPUT</VAR>.</DD>
|
|
<P> There are two additional environment variables that may be set on
|
|
the command line:</P>
|
|
<DL>
|
|
<DT> NETJIGVERBOSE=verbose export NETJIGVERBOSE</DT>
|
|
<DD> If set, then the test output will be "chatty", and let you know
|
|
what commands it is running, and as packets are sent. Without it set,
|
|
the output is limited to success/failure messages.</DD>
|
|
<DT> NETJIGTESTDEBUG=netjig export NETJIGTESTDEBUG</DT>
|
|
<DD> This will enable debugging of the communication with uml_netjig,
|
|
and turn on debugging in this utility. This does not imply
|
|
NETJIGVERBOSE.</DD>
|
|
</DL>
|
|
<DT> HOSTTESTDEBUG=hosttest export HOSTTESTDEBUG</DT>
|
|
<DD> This will show all interactions with the user-mode-linux consoles</DD>
|
|
</DL>
|
|
<H2 NAME="kernelpatch"><A NAME="20_11">kernel_patch_test paramaters</A></H2>
|
|
<P> The kernel_patch_test function takes some kernel source, copies it
|
|
with lndir, and then applies the patch as produced by "make
|
|
kernelpatch".</P>
|
|
<P> The following are used to control the input and output to the
|
|
system:</P>
|
|
<DL>
|
|
<DT>KERNEL_NAME</DT>
|
|
<DD>the kernel name, typically something like "linus" or "rh"</DD>
|
|
<DT>KERNEL_VERSION</DT>
|
|
<DD>the kernel version number, as in "2.2" or "2.4".</DD>
|
|
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
|
|
<DD>This variable should set in the environment, probably in
|
|
~/freeswan-regress-env.sh. Examples of this variables would be
|
|
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
|
|
an extracted copy of the kernel source in question.</DD>
|
|
<DT>REF_PATCH_OUTPUT</DT>
|
|
<DD>a copy of the patch output to compare against</DD>
|
|
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
|
|
<DD>If set to a non-empty string, then the patched kernel source is not
|
|
removed at the end of the test. This will typically be set in the
|
|
environment while debugging.</DD>
|
|
</DL>
|
|
<H2 NAME="modtest"><A NAME="20_12">module_compile paramaters</A></H2>
|
|
<P> The module_compile test attempts to build the KLIPS module against a
|
|
given set of kernel source. This is also done by the RPM tests, but in
|
|
a very specific manner.</P>
|
|
<P> There are two variations of this test - one where the kernel either
|
|
doesn't need to be configured, or is already done, and tests were there
|
|
is a local configuration file.</P>
|
|
<P> Where the kernel doesn't need to be configured, the kernel source
|
|
that is found is simply used. It may be a RedHat-style kernel, where
|
|
one can cause it to configure itself via rhconfig.h-style definitions.
|
|
Or, it may just be a kernel tree that has been configured.</P>
|
|
<P> If the variable KERNEL_CONFIG_FILE is set, then a new directory is
|
|
created for the kernel source. It is populated with lndir(1). The
|
|
referenced file is then copied in as .config, and "make oldconfig" is
|
|
used to configure the kernel. This resulting kernel is then used as the
|
|
reference source.</P>
|
|
<P> In all cases, the kernel source is found the same was for the
|
|
kernelpatch test, i.e. via KERNEL_VERSION/KERNEL_NAME and
|
|
KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC.</P>
|
|
<P> Once there is kernel source, the module is compiled using the
|
|
top-level "make module" target.</P>
|
|
<P> The test is considered successful if an executable is found in
|
|
OUTPUT/module/ipsec.o at the end of the test.</P>
|
|
<DL>
|
|
<DT>KERNEL_NAME</DT>
|
|
<DD>the kernel name, typically something like "linus" or "rh"</DD>
|
|
<DT>KERNEL_VERSION</DT>
|
|
<DD>the kernel version number, as in "2.2" or "2.4".</DD>
|
|
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
|
|
<DD>This variable should set in the environment, probably in
|
|
~/freeswan-regress-env.sh. Examples of this variables would be
|
|
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
|
|
an extracted copy of the kernel source in question.</DD>
|
|
<DT>KERNEL_CONFIG_FILE</DT>
|
|
<DD>The configuration file for the kernel.</DD>
|
|
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
|
|
<DD>If set to a non-empty string, then the configured kernel source is
|
|
not removed at the end of the test. This will typically be set in the
|
|
environment while debugging.</DD>
|
|
<DT>MODULE_DEF_INCLUDE</DT>
|
|
<DD>The include file that will be used to configure the KLIPS module,
|
|
and possibly the kernel source.</DD>
|
|
</DL>
|
|
<H1><A NAME="21">Current pitfalls</A></H1>
|
|
<DL>
|
|
<DT> "tcpdump dissector" not available.</DT>
|
|
<DD> This is a non-fatal warning. If uml_netjig is invoked with the -t
|
|
option, then it will attempt to use tcpdump's dissector to decode each
|
|
packet that it processes. The dissector is presently not available, so
|
|
this option it normally turned off at compile time. The dissector
|
|
library will be released with tcpdump version 4.0.</DD>
|
|
</DL>
|
|
<HR>
|
|
<H1><A name="umltesting">User-Mode-Linux Testing guide</A></H1>
|
|
<P> User mode linux is a way to compile a linux kernel such that it can
|
|
run as a process in another linux system (potentially as a *BSD or
|
|
Windows process later). See<A HREF="http://user-mode-linux.sourceforge.net/">
|
|
http://user-mode-linux.sourceforge.net/</A></P>
|
|
<P> UML is a good platform for testing and experimenting with FreeS/WAN.
|
|
It allows several network nodes to be simulated on a single machine.
|
|
Creating, configuring, installing, monitoring, and controling these
|
|
nodes is generally easier and easier to script with UML than real
|
|
hardware.</P>
|
|
<P> You'll need about 500Mb of disk space for a full
|
|
sunrise-east-west-sunset setup. You can possibly get this down by 130Mb
|
|
if you remove the sunrise/sunset kernel build. If you just want to run,
|
|
then you can even remove the east/west kernel build.</P>
|
|
<P> Nothing need be done as super user. In a couple of steps, we note
|
|
where super user is required to install commands in system-wide
|
|
directories, but ~/bin could be used instead. UML seems to use a
|
|
system-wide /tmp/uml directory so different users may interfere with
|
|
one another. Later UMLs use ~/.uml instead, so multiple users running
|
|
UML tests should not be a problem, but note that a single user running
|
|
the UML tests will only be able run one set. Further, UMLs sometimes
|
|
get stuck and hang around. These "zombies" (most will actually be in
|
|
the "T" state in the process table) will interfere with subsequent
|
|
tests.</P>
|
|
<H2><A NAME="22_1">Preliminary Notes on BIND</A></H2>
|
|
<P> As of 2003/3/1, the Light-Weight Resolver is used by pluto. This
|
|
requires that BIND9 be running. It also requires that BIND9 development
|
|
libraries be present in the build environment. The DNSSEC code is only
|
|
truly functional in BIND9 snapshots. The library code could be 9.2.2,
|
|
we believe. We are using BIND9 20021115 snapshot code from<A HREF="ftp://ftp.isc.org/isc/bind9/snapshots">
|
|
ftp://ftp.isc.org/isc/bind9/snapshots</A>.</P>
|
|
<P> FreeS/WAN may well require a newer BIND than is on your system. Many
|
|
distributions have moved to BIND9.2.2 recently due to a security
|
|
advisory. BIND is five components.</P>
|
|
<OL>
|
|
<LI> named</LI>
|
|
<LI> dnssec-*</LI>
|
|
<LI> client side resolver libraries</LI>
|
|
<LI> client side utility libraries I thought there were lib and named
|
|
parts to dnsssec...</LI>
|
|
<LI> dynamic DNS update utilities</LI>
|
|
</OL>
|
|
<P> The only piece that we need for *building* is #4. That's the only
|
|
part that has to be on the build host. What is the difference between
|
|
resolver and util libs? If you want to edit
|
|
testing/baseconfigs/all/etc/bind, you'll need a snapshot version. The
|
|
resolver library contains the resolver. FreeS/WAN has its own copy of
|
|
that in lib/liblwres.</P>
|
|
<H2><A NAME="22_2">Steps to Install UML for FreeS/WAN</A></H2>
|
|
<OL>
|
|
<LI> Get the following files:
|
|
<OL type="a">
|
|
<LI> from<A HREF="http://www.sandelman.ottawa.on.ca/freeswan/uml/">
|
|
http://www.sandelman.ottawa.on.ca/freeswan/uml/</A>
|
|
umlfreeroot-15.1.tar.gz (or highest numbered one). This is a debian
|
|
potato root file system. You can use this even on a Redhat host, as it
|
|
has the newer GLIBC2.2 libraries as well.
|
|
<!-- If you are using
|
|
Redhat 7.2 or newer as your development machine, you can create the
|
|
image from your installation media. See <A HREF="uml-rhroot.html">Building a RedHat root"></A>.
|
|
A future document will explain how to build this from .DEB files as well.
|
|
-->
|
|
|
|
<!--
|
|
<LI> umlfreesharemini.tar.gz (or umlfreeshareall.tar.gz).
|
|
If you are a Debian potato user, you don't need it you can use your
|
|
native /usr/share.
|
|
</UL>
|
|
-->
|
|
</LI>
|
|
<LI> From<A HREF="ftp://ftp.xs4all.nl/pub/crypto/freeswan/">
|
|
ftp://ftp.xs4all.nl/pub/crypto/freeswan/</A> a snapshot or release
|
|
(1.92 or better)</LI>
|
|
<LI> From a<A HREF="http://www.kernel.org/mirrors/">
|
|
http://www.kernel.org mirror</A>, the virgin 2.4.19 kernel. Please
|
|
realize that we have defaults in our tree for kernel configuration. We
|
|
try to track the latest UML kernels. If you use a newer kernel, you may
|
|
have faults in the kernel build process. You can see what the latest
|
|
that is being regularly tested by visiting<A HREF="http://bugs.freeswan.org:81/regress/HEAD/lastgood/freeswan-regress-env.sh">
|
|
freeswan-regress-env.sh</A>.</LI>
|
|
<LI>
|
|
<!-- Note: this step is refered to as "step 1d" below. -->
|
|
Get<A HREF="http://ftp.nl.linux.org/uml/">
|
|
http://ftp.nl.linux.org/uml/</A> uml-patch-2.4.19-47.bz2 or the one
|
|
associated with your kernel. As of 2003/03/05, uml-patch-2.4.19-47.bz2
|
|
works for us.<STRONG> More recent versions of the patch have not been
|
|
tested by us.</STRONG></LI>
|
|
<LI> You'll probably want to visit<A HREF="http://user-mode-linux.sourceforge.net">
|
|
http://user-mode-linux.sourceforge.net</A> and get the UML utilities.
|
|
These are not needed for the build or interactive use (but
|
|
recommended). They are necessary for the regression testing procedures
|
|
used by "make check". We currently use uml_utilities_20020212.tar.bz2.</LI>
|
|
<LI> You need tcpdump version 3.7.1 or better. This is newer than the
|
|
version included in most LINUX distributions. You can check the version
|
|
of an installed tcpdump with the --version flag. If you need a newer
|
|
tcpdump fetch both tcpdump and libpcap source tar files from<A HREF="http://www.tcpdump.org/">
|
|
http://www.tcpdump.org/</A> or a mirror.</LI>
|
|
</OL>
|
|
</LI>
|
|
<LI> Pick a suitable place, and extract the following files:
|
|
<OL type="a">
|
|
<LI>
|
|
<!-- Note: this step is refered to as "step 2a" later. -->
|
|
2.4.19 kernel. For instance:
|
|
<PRE>
|
|
<CODE> cd /c2/kernel
|
|
tar xzvf ../download/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> extract the umlfreeroot file
|
|
<!-- (unless you <A HREF="uml-rhroot.html">built your own from RPMs</A>) -->
|
|
|
|
<PRE>
|
|
<CODE> mkdir -p /c2/user-mode-linux/basic-root
|
|
cd /c2/user-mode-linux/basic-root
|
|
tar xzvf ../download/umlfreeroot-15.1.tar.gz
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> FreeSWAN itself (or checkout "all" from CVS)
|
|
<PRE>
|
|
<CODE> mkdir -p /c2/freeswan/sandbox
|
|
cd /c2/freeswan/sandbox
|
|
tar xzvf ../download/snapshot.tar.gz
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
</OL>
|
|
</LI>
|
|
<LI> If you need to build a newer tcpdump:
|
|
<UL>
|
|
<LI> Make sure you have OpenSSL installed -- it is needed for
|
|
cryptographic routines.</LI>
|
|
<LI> Unpack libpcap and tcpdump source in parallel directories (the
|
|
tcpdump build procedures look for libpcap next door).</LI>
|
|
<LI> Change directory into the libpcap source directory and then build
|
|
the library:
|
|
<PRE>
|
|
<CODE> ./configure
|
|
make
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> Change into the tcpdump source directory, build tcpdump, and
|
|
install it.
|
|
<PRE>
|
|
<CODE> ./configure
|
|
make
|
|
# Need to be superuser to install in system directories.
|
|
# Installing in ~/bin would be an alternative.
|
|
su -c "make install"
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI> If you need the uml utilities, unpack them somewhere then build and
|
|
install them:
|
|
<PRE>
|
|
<CODE> cd tools
|
|
make all
|
|
# Need to be superuser to install in system directories.
|
|
# Installing in ~/bin would be an alternative.
|
|
su -c "make install BIN_DIR=/usr/local/bin"
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> set up the configuration file
|
|
<UL>
|
|
<LI> <CODE>cd /c2/freeswan/sandbox/freeswan-1.97/testing/utils</CODE></LI>
|
|
<LI> copy umlsetup-sample.sh to ../../umlsetup.sh: <CODE> cp
|
|
umlsetup-sample.sh ../../umlsetup.sh</CODE></LI>
|
|
<LI> open up ../../umlsetup.sh in your favorite editor.</LI>
|
|
<LI> change POOLSPACE= to point to the place with at least 500Mb of
|
|
disk. Best if it is on the same partition as the "umlfreeroot"
|
|
extraction, as it will attempt to use hard links if possible to save
|
|
disk space.</LI>
|
|
<LI> Set TESTINGROOT if you intend to run the script outside of the
|
|
sandbox/snapshot/release directory. Otherwise, it will configure
|
|
itself.</LI>
|
|
<LI> KERNPOOL should point to the directory with your 2.4.19 kernel
|
|
tree. This tree should be unconfigured! This is the directory you used
|
|
in step 2a.</LI>
|
|
<LI> UMLPATCH should point at the bz2 file you downloaded at 1d. If
|
|
using a kernel that already includes the patch, set this to /dev/null.</LI>
|
|
<LI> FREESWANDIR should point at the directory where you unpacked the
|
|
snapshot/release. Include the "freeswan-snap2001sep16b" or whatever in
|
|
it. If you are running from CVS, then you point at the directory where
|
|
top, klips, etc. are. The script will fix up the directory so that it
|
|
can be used.</LI>
|
|
<LI> BASICROOT should be set to the directory used in 2b, or to the
|
|
directory that you created with RPMs.</LI>
|
|
<LI> SHAREDIR should be set to the directory used in 2c, to /usr/share
|
|
for Debian potato users, or to $BASICROOT/usr/share.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>
|
|
<PRE> <CODE>cd $TESTINGROOT/utils
|
|
sh make-uml.sh
|
|
</CODE></PRE>
|
|
It will grind for awhile. If there are errors it will bail. If so, run
|
|
it under "script" and send the output to [email protected].</LI>
|
|
<LI> You will have a bunch of stuff under $POOLSPACE. Open four xterms:
|
|
<PRE> <CODE> for i in sunrise sunset east west
|
|
do
|
|
xterm -name $i -title $i -e $POOLSPACE/$i/start.sh done
|
|
</CODE></PRE>
|
|
</LI>
|
|
<LI> Login as root. Password is "root" (Note, these virtual machines are
|
|
networked together, but are not configured to talk to the rest of the
|
|
world.)</LI>
|
|
<LI> verify that pluto started on east/west, run "ipsec look"</LI>
|
|
<LI> login to sunrise. run "ping sunset"</LI>
|
|
<LI> login to west. run "tcpdump -p -i eth1 -n" (tcpdump must be version
|
|
3.7.1 or newer)</LI>
|
|
<LI> Closing a console xterm will shut down that UML.</LI>
|
|
<LI> You can "make check", if you want to. It is run from
|
|
/c2/freeswan/sandbox/freeswan-1.97.</LI>
|
|
</OL>
|
|
<H1><A NAME="23">Debugging the kernel with GDB</A></H1>
|
|
<P> With User-Mode-Linux, you can debug the kernel using GDB. See
|
|
<!--HREF="http://user-mode-linux.sourceforge.net/debugging.html"-->
|
|
|
|
http://user-mode-linux.sourceforge.net/debugging.html.</(null)></P>
|
|
<P> Typically, one will want to address a test case for a failing
|
|
situation. Running GDB from Emacs, or from other front ends is
|
|
possible. First start GDB.</P>
|
|
<P> Tell it to open the UMLPOOL/swan/linux program.</P>
|
|
<P> Note the PID of GDB:</P>
|
|
<PRE>
|
|
marajade-[projects/freeswan/mgmt/planning] mcr 1029 %ps ax | grep gdb
|
|
1659 pts/9 SN 0:00 /usr/bin/gdb -fullname -cd /mara4/freeswan/kernpatch/UMLPOOL/swan/ linux
|
|
</PRE>
|
|
<P> Set the following in the environment:</P>
|
|
<PRE>
|
|
UML_east_OPT="debug gdb-pid=1659"
|
|
</PRE>
|
|
<P> Then start the user-mode-linux in the test scheme you wish:</P>
|
|
<PRE>
|
|
marajade-[kernpatch/testing/klips/east-icmp-02] mcr 1220 %../../utils/runme.sh
|
|
</PRE>
|
|
The user-mode-linux will stop on boot, giving you a chance to attach to
|
|
the process:
|
|
<PRE>
|
|
(gdb) file linux
|
|
Reading symbols from linux...done.
|
|
(gdb) attach 1
|
|
Attaching to program: /mara4/freeswan/kernpatch/UMLPOOL/swan/linux, process 1
|
|
0xa0118bc1 in kill () at hostfs_kern.c:770
|
|
</PRE>
|
|
<P> At this point, break points should be created as appropriate.</P>
|
|
<H2><A NAME="23_1">Other notes about debugging</A></H2>
|
|
<P> If you are running a standard test, after all the packets are sent,
|
|
the UML will be shutdown. This can cause problems, because the UML may
|
|
get terminated while you are debugging.</P>
|
|
<P> The environment variable <CODE>NETJIGWAITUSER</CODE> can be set to
|
|
"waituser". If so, then the testing system will prompt before exiting
|
|
the test.</P>
|
|
<H1><A NAME="24">User-Mode-Linux mysteries</A></H1>
|
|
<UL>
|
|
<LI> running more than one UML of the same name (e.g. "west") can cause
|
|
problems.</LI>
|
|
<LI> running more than one UML from the same root file system is not a
|
|
good idea.</LI>
|
|
<LI> all this means that running "make check" twice on the same machine
|
|
is probably not a good idea.</LI>
|
|
<LI> occationally, UMLs will get stuck. This can happen like:
|
|
<!--BLOCK-->
|
|
15134 ? T
|
|
0:00 /spare/hugh/uml/uml2.4.18-sept5/umlbuild/east/linux (east)
|
|
[/bin/sh] 15138 ? T 0:00
|
|
/spare/hugh/uml/uml2.4.18-sept5/umlbuild/east/linux (east) [halt]</(null)>
|
|
these will need to be killed. Note that they are in "T"racing mode.</LI>
|
|
<LI> UMLs can also hang, and will report "Tracing myself and I can't get
|
|
out". This is a bug in UML. There are ways to find out what is going on
|
|
and report this to the UML people, but we don't know the magic right
|
|
now.</LI>
|
|
</UL>
|
|
<H1><A NAME="25">Getting more info from uml_netjig</A></H1>
|
|
<P> uml_netjig can be compiled with a built-in tcpdump. This uses
|
|
not-yet-released code from<A HREF="http://www.tcpdump.org/">
|
|
www.tcpdump.org</A>. Please see the instructions in <CODE>
|
|
testing/utils/uml_netjig/Makefile</CODE>.</P>
|
|
<HR>
|
|
<H1><A name="politics">History and politics of cryptography</A></H1>
|
|
<P>Cryptography has a long and interesting history, and has been the
|
|
subject of considerable political controversy.</P>
|
|
<H2><A name="intro.politics">Introduction</A></H2>
|
|
<H3><A NAME="26_1_1">History</A></H3>
|
|
<P>The classic book on the history of cryptography is David Kahn's<A href="#Kahn">
|
|
The Codebreakers</A>. It traces codes and codebreaking from ancient
|
|
Egypt to the 20th century.</P>
|
|
<P>Diffie and Landau<A href="#diffie"> Privacy on the Line: The Politics
|
|
of Wiretapping and Encryption</A> covers the history from the First
|
|
World War to the 1990s, with an emphasis on the US.</P>
|
|
<H4><A NAME="26_1_1_1">World War II</A></H4>
|
|
<P>During the Second World War, the British "Ultra" project achieved one
|
|
of the greatest intelligence triumphs in the history of warfare,
|
|
breaking many Axis codes. One major target was the Enigma cipher
|
|
machine, a German device whose users were convinced it was unbreakable.
|
|
The American "Magic" project had some similar triumphs against Japanese
|
|
codes.</P>
|
|
<P>There are many books on this period. See our bibliography for
|
|
several. Two I particularly like are:</P>
|
|
<UL>
|
|
<LI>Andrew Hodges has done a superb<A href="http://www.turing.org.uk/book/">
|
|
biography</A> of Alan Turing, a key player among the Ultra
|
|
codebreakers. Turing was also an important computer pioneer. The terms<A
|
|
href="http://www.abelard.org/turpap/turpap.htm"> Turing test</A> and<A href="http://plato.stanford.edu/entries/turing-machine/">
|
|
Turing machine</A> are named for him, as is the<A href="http://www.acm.org">
|
|
ACM</A>'s highest technical<A href="http://www.acm.org/awards/taward.html">
|
|
award</A>.</LI>
|
|
<LI>Neal Stephenson's<A href="#neal"> Cryptonomicon</A> is a novel with
|
|
cryptography central to the plot. Parts of it take place during WW II,
|
|
other parts today.</LI>
|
|
</UL>
|
|
<P>Bletchley Park, where much of the Ultra work was done, now has a
|
|
museum and a<A href="http://www.bletchleypark.org.uk/"> web site</A>.</P>
|
|
<P>The Ultra work introduced three major innovations.</P>
|
|
<UL>
|
|
<LI>The first break of Enigma was achieved by Polish Intelligence in
|
|
1931. Until then most code-breakers had been linguists, but a different
|
|
approach was needed to break machine ciphers. Polish Intelligence
|
|
recruited bright young mathematicians to crack the "unbreakable"
|
|
Enigma. When war came in 1939, the Poles told their allies about this,
|
|
putting Britain on the road to Ultra. The British also adopted a
|
|
mathematical approach.</LI>
|
|
<LI>Machines were extensively used in the attacks. First the Polish
|
|
"Bombe" for attacking Enigma, then British versions of it, then
|
|
machines such as Collosus for attacking other codes. By the end of the
|
|
war, some of these machines were beginning to closely resemble digital
|
|
computers. After the war, a team at Manchester University, several old
|
|
Ultra hands included, built one of the world's first actual
|
|
general-purpose digital computers.</LI>
|
|
<LI>Ultra made codebreaking a large-scale enterprise, producing
|
|
intelligence on an industrial scale. This was not a "black chamber",
|
|
not a hidden room in some obscure government building with a small crew
|
|
of code-breakers. The whole operation -- from wholesale interception of
|
|
enemy communications by stations around the world, through large-scale
|
|
code-breaking and analysis of the decrypted material (with an enormous
|
|
set of files for cross-referencing), to delivery of intelligence to
|
|
field commanders -- was huge, and very carefully managed.</LI>
|
|
</UL>
|
|
<P>So by the end of the war, Allied code-breakers were expert at
|
|
large-scale mechanised code-breaking. The payoffs were enormous.</P>
|
|
<H4><A name="postwar">Postwar and Cold War</A></H4>
|
|
<P>The wartime innovations were enthusiastically adopted by post-war and
|
|
Cold War signals intelligence agencies. Presumably many nations now
|
|
have some agency capable of sophisticated attacks on communications
|
|
security, and quite a few engage in such activity on a large scale.</P>
|
|
<P>America's<A href="#NSA"> NSA</A>, for example, is said to be both the
|
|
world's largest employer of mathematicians and the world's largest
|
|
purchaser of computer equipment. Such claims may be somewhat
|
|
exaggerated, but beyond doubt the NSA -- and similar agencies in other
|
|
countries -- have some excellent mathematicians, lots of powerful
|
|
computers, sophisticated software, and the organisation and funding to
|
|
apply them on a large scale. Details of the NSA budget are secret, but
|
|
there are some published<A href="http://www.fas.org/irp/nsa/nsabudget.html">
|
|
estimates</A>.</P>
|
|
<P>Changes in the world's communications systems since WW II have
|
|
provided these agencies with new targets. Cracking the codes used on an
|
|
enemy's military or diplomatic communications has been common practice
|
|
for centuries. Extensive use of radio in war made large-scale attacks
|
|
such as Ultra possible. Modern communications make it possible to go
|
|
far beyond that. Consider listening in on cell phones, or intercepting
|
|
electronic mail, or tapping into the huge volumes of data on new media
|
|
such as fiber optics or satellite links. None of these targets existed
|
|
in 1950. All of them can be attacked today, and almost certainly are
|
|
being attacked.</P>
|
|
<P>The Ultra story was not made public until the 1970s. Much of the
|
|
recent history of codes and code-breaking has not been made public, and
|
|
some of it may never be. Two important books are:</P>
|
|
<UL>
|
|
<LI>Bamford's<A href="#puzzle"> The Puzzle Palace</A>, a history of the
|
|
NSA</LI>
|
|
<LI>Hager's<A href="http://www.fas.org/irp/eprint/sp/index.html"> Secret
|
|
Power</A>, about the<A href="http://sg.yahoo.com/government/intelligence/echelon_network/">
|
|
Echelon</A> system -- the US, UK, Canada, Australia and New Zealand
|
|
co-operating to monitor much of the world's communications.</LI>
|
|
</UL>
|
|
<P>Note that these books cover only part of what is actually going on,
|
|
and then only the activities of nations open and democratic enough that
|
|
(some of) what they are doing can be discovered. A full picture,
|
|
including:</P>
|
|
<UL>
|
|
<LI>actions of the English-speaking democracies not covered in those
|
|
books</LI>
|
|
<LI>actions of other more-or-less sane governments</LI>
|
|
<LI>the activities of various more-or-less insane governments</LI>
|
|
<LI>possibilities for unauthorized action by government employees</LI>
|
|
<LI>possible actions by large non-government organisations:
|
|
corporations, criminals, or conspiracies</LI>
|
|
</UL>
|
|
<P>might be really frightening.</P>
|
|
<H4><A name="recent">Recent history -- the crypto wars</A></H4>
|
|
<P>Until quite recently, cryptography was primarily a concern of
|
|
governments, especially of the military, of spies, and of diplomats.
|
|
Much of it was extremely secret.</P>
|
|
<P>In recent years, that has changed a great deal. With computers and
|
|
networking becoming ubiquitous, cryptography is now important to almost
|
|
everyone. Among the developments since the 1970s:</P>
|
|
<UL>
|
|
<LI>The US gov't established the Data Encryption Standard,<A href="#DES">
|
|
DES</A>, a<A href="#block"> block cipher</A> for cryptographic
|
|
protection of unclassfied documents.</LI>
|
|
<LI>DES also became widely used in industry, especially regulated
|
|
industries such as banking.</LI>
|
|
<LI>Other nations produced their own standards, such as<A href="glossary.html#GOST">
|
|
GOST</A> in the Soviet Union.</LI>
|
|
<LI><A href="#public">Public key</A> cryptography was invented by Diffie
|
|
and Hellman.</LI>
|
|
<LI>Academic conferences such as<A href="http://www-cse.ucsd.edu/users/mihir/crypto2k.html">
|
|
Crypto</A> and<A href="http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/">
|
|
Eurocrypt</A> began.</LI>
|
|
<LI>Several companies began offerring cryptographic products:<A href="#RSAco">
|
|
RSA</A>,<A href="#PGPI"> PGP</A>, the many vendors with<A href="#PKI">
|
|
PKI</A> products, ...</LI>
|
|
<LI>Cryptography appeared in other products: operating systems, word
|
|
processors, ...</LI>
|
|
<LI>Network protocols based on crypto were developed:<A href="#ssh"> SSH</A>
|
|
,<A href="#SSL"> SSL</A>,<A href="#IPSEC"> IPsec</A>, ...</LI>
|
|
<LI>Crytography came into widespread use to secure bank cards,
|
|
terminals, ...</LI>
|
|
<LI>The US government replaced<A href="#DES"> DES</A> with the much
|
|
stronger Advanced Encryption Standard,<A href="#AES"> AES</A></LI>
|
|
</UL>
|
|
<P>This has led to a complex ongoing battle between various mainly
|
|
government groups wanting to control the spread of crypto and various
|
|
others, notably the computer industry and the<A href="http://online.offshore.com.ai/security/">
|
|
cypherpunk</A> crypto advocates, wanting to encourage widespread use.</P>
|
|
<P>Steven Levy has written a fine history of much of this, called<A href="#crypto">
|
|
Crypto: How the Code rebels Beat the Government -- Saving Privacy in
|
|
the Digital Age</A>.</P>
|
|
<P>The FreeS/WAN project is to a large extent an outgrowth of cypherpunk
|
|
ideas. Our reasons for doing the project can be seen in these quotes
|
|
from the<A href="http://www.eff.org/pub/Privacy/Crypto_misc/cypherpunk.manifesto">
|
|
Cypherpunk Manifesto</A>:</P>
|
|
<BLOCKQUOTE> Privacy is necessary for an open society in the electronic
|
|
age. ...
|
|
<P>We cannot expect governments, corporations, or other large, faceless
|
|
organizations to grant us privacy out of their beneficence. It is to
|
|
their advantage to speak of us, and we should expect that they will
|
|
speak. ...</P>
|
|
<P>We must defend our own privacy if we expect to have any. ...</P>
|
|
<P>Cypherpunks write code. We know that someone has to write software to
|
|
defend privacy, and since we can't get privacy unless we all do, we're
|
|
going to write it. We publish our code so that our fellow Cypherpunks
|
|
may practice and play with it. Our code is free for all to use,
|
|
worldwide. We don't much care if you don't approve of the software we
|
|
write. We know that software can't be destroyed and that a widely
|
|
dispersed system can't be shut down.</P>
|
|
<P>Cypherpunks deplore regulations on cryptography, for encryption is
|
|
fundamentally a private act. ...</P>
|
|
<P>For privacy to be widespread it must be part of a social contract.
|
|
People must come and together deploy these systems for the common good.
|
|
...</P>
|
|
</BLOCKQUOTE>
|
|
<P>To quote project leader John Gilmore:</P>
|
|
<BLOCKQUOTE> We are literally in a race between our ability to build and
|
|
deploy technology, and their ability to build and deploy laws and
|
|
treaties. Neither side is likely to back down or wise up until it has
|
|
definitively lost the race.</BLOCKQUOTE>
|
|
<P>If FreeS/WAN reaches its goal of making<A href="#opp.intro">
|
|
opportunistic encryption</A> widespread so that secure communication
|
|
can become the default for a large part of the net, we will have struck
|
|
a major blow.</P>
|
|
<H3><A name="intro.poli">Politics</A></H3>
|
|
<P>The political problem is that nearly all governments want to monitor
|
|
their enemies' communications, and some want to monitor their citizens.
|
|
They may be very interested in protecting some of their own
|
|
communications, and often some types of business communication, but not
|
|
in having everyone able to communicate securely. They therefore attempt
|
|
to restrict availability of strong cryptography as much as possible.</P>
|
|
<P>Things various governments have tried or are trying include:</P>
|
|
<UL>
|
|
<LI>Echelon, a monitor-the-world project of the US, UK, NZ, Australian
|
|
and Canadian<A href="#SIGINT"> signals intelligence</A> agencies. See
|
|
this<A href="http://sg.yahoo.com/government/intelligence/echelon_network/">
|
|
collection</A> of links and this<A href="http://www.zdnet.com/zdnn/stories/news/0,4586,2640682,00.html">
|
|
story</A> on the French Parliament's reaction.</LI>
|
|
<LI>Others governments may well have their own Echelon-like projects. To
|
|
quote the Dutch Minister of Defense, as reported in a German<A href="http://www.heise.de/tp/english/inhalt/te/4729/1.html">
|
|
magazine</A>:<BLOCKQUOTE> The government believes not only the
|
|
governments associated with Echelon are able to intercept communication
|
|
systems, but that it is an activity of the investigative authorities
|
|
and intelligence services of many countries with governments of
|
|
different political signature.</BLOCKQUOTE> Even if they have nothing
|
|
on the scale of Echelon, most intelligence agencies and police forces
|
|
certainly have some interception capability.</LI>
|
|
<LI><A href="#NSA">NSA</A> tapping of submarine communication cables,
|
|
described in<A href="http://www.zdnet.com/zdnn/stories/news/0,4586,2764372,00.html">
|
|
this article</A></LI>
|
|
<LI>A proposal for international co-operation on<A href="http://www.heise.de/tp/english/special/enfo/4306/1.html">
|
|
Internet surveillance</A>.</LI>
|
|
<LI>Alleged<A href="http://cryptome.org/nsa-sabotage.htm"> sabotage</A>
|
|
of security products by the<A href="#NSA"> NSA</A> (the US signals
|
|
intelligence agency).</LI>
|
|
<LI>The German armed forces and some government departments will stop
|
|
using American software for fear of NSA "back doors", according to this<A
|
|
href="http://www.theregister.co.uk/content/4/17679.html"> news story</A>
|
|
.</LI>
|
|
<LI>The British Regulation of Investigatory Powers bill. See this<A href="http://www.fipr.org/rip/index.html">
|
|
web page.</A> and perhaps this<A href="http://ars.userfriendly.org/cartoons/?id=20000806&mode=classic">
|
|
cartoon</A>.</LI>
|
|
<LI>A Russian<A href="http://www.eff.org/pub/Privacy/Foreign_and_local/Russia/russian_crypto_ban_english.edict">
|
|
ban</A> on cryptography</LI>
|
|
<LI>Chinese<A href="http://www.eff.org/pub/Misc/Publications/Declan_McCullagh/www/global/china">
|
|
controls</A> on net use.</LI>
|
|
<LI>The FBI's carnivore system for covert searches of email. See this<A href="http://www.zdnet.com/zdnn/stories/news/0,4586,2601502,00.html">
|
|
news coverage</A> and this<A href="http://www.crypto.com/papers/carnivore-risks.html">
|
|
risk assessment</A>. The government had an external review of some
|
|
aspects of this system done. See this<A href="http://www.crypto.com/papers/carnivore_report_comments.html">
|
|
analysis</A> of that review. Possible defenses against Carnivore
|
|
include:
|
|
<UL>
|
|
<LI><A href="#PGP">PGP</A> for end-to-end mail encryption</LI>
|
|
<LI><A href="http://www.home.aone.net.au/qualcomm/">secure sendmail</A>
|
|
for server-to-server encryption</LI>
|
|
<LI>IPsec encryption on the underlying IP network</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>export laws restricting strong cryptography as a munition. See<A href="#exlaw">
|
|
discussion</A> below.</LI>
|
|
<LI>various attempts to convince people that fundamentally flawed
|
|
cryptography, such as encryption with a<A href="#escrow"> back door</A>
|
|
for government access to data or with<A href="#shortkeys"> inadequate
|
|
key lengths</A>, was adequate for their needs.</LI>
|
|
</UL>
|
|
<P>Of course governments are by no means the only threat to privacy and
|
|
security on the net. Other threats include:</P>
|
|
<UL>
|
|
<LI>industrial espionage, as for example in this<A href="http://www.zdnet.com/zdnn/stories/news/0,4586,2626931,00.html">
|
|
news story</A></LI>
|
|
<LI>attacks by organised criminals, as in this<A href="http://www.sans.org/newlook/alerts/NTE-bank.htm">
|
|
large-scale attack</A></LI>
|
|
<LI>collection of personal data by various companies.
|
|
<UL>
|
|
<LI>for example, consider the various corporate winners of Privacy
|
|
International's<A href="http://www.privacyinternational.org/bigbrother/">
|
|
Big Brother Awards</A>.</LI>
|
|
<LI><A href="http://www.zeroknowledge.com">Zero Knowledge</A> sell tools
|
|
to defend against this</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>individuals may also be a threat in a variety of ways and for a
|
|
variety of reasons</LI>
|
|
<LI>in particular, an individual with access to government or industry
|
|
data collections could do considerable damage using that data in
|
|
unauthorized ways.</LI>
|
|
</UL>
|
|
<P>One<A href="http://www.zdnet.com/zdnn/stories/news/0,4586,2640674,00.html">
|
|
study</A> enumerates threats and possible responses for small and
|
|
medium businesses. VPNs are a key part of the suggested strategy.</P>
|
|
<P>We consider privacy a human right. See the UN's<A href="http://www.un.org/Overview/rights.html">
|
|
Universal Declaration of Human Rights</A>, article twelve:</P>
|
|
<BLOCKQUOTE> No one shall be subjected to arbitrary interference with
|
|
his privacy, family, home or correspondence, nor to attacks upon his
|
|
honor and reputation. Everyone has the right to the protection of the
|
|
law against such interference or attacks.</BLOCKQUOTE>
|
|
<P>Our objective is to help make privacy possible on the Internet using
|
|
cryptography strong enough not even those well-funded government
|
|
agencies are likely to break it. If we can do that, the chances of
|
|
anyone else breaking it are negliible.</P>
|
|
<H3><A NAME="26_1_3">Links</A></H3>
|
|
<P>Many groups are working in different ways to defend privacy on the
|
|
net and elsewhere. Please consider contributing to one or more of these
|
|
groups:</P>
|
|
<UL>
|
|
<LI>the EFF's<A href="http://www.eff.org/crypto/"> Privacy Now!</A>
|
|
campaign</LI>
|
|
<LI>the<A href="http://www.gilc.org"> Global Internet Liberty Campaign</A>
|
|
</LI>
|
|
<LI><A href="http://www.cpsr.org/program/privacy/privacy.html">Computer
|
|
Professionals for Social Responsibility</A></LI>
|
|
</UL>
|
|
<P>For more on these issues see:</P>
|
|
<UL>
|
|
<LI>Steven Levy (Newsweek's chief technology writer and author of the
|
|
classic "Hackers") new book<A href="#crypto"> Crypto: How the Code
|
|
Rebels Beat the Government--Saving Privacy in the Digital Age</A></LI>
|
|
<LI>Simson Garfinkel (Boston Globe columnist and author of books on<A href="#PGP">
|
|
PGP</A> and<A href="#practical"> Unix Security</A>) book<A href="#Garfinkel">
|
|
Database Nation: the death of privacy in the 21st century</A></LI>
|
|
</UL>
|
|
<P>There are several collections of<A href="#quotes"> crypto quotes</A>
|
|
on the net.</P>
|
|
<P>See also the<A href="biblio.html"> bibliography</A> and our list of<A href="#policy">
|
|
web references</A> on cryptography law and policy.</P>
|
|
<H3><A NAME="26_1_4">Outline of this section</A></H3>
|
|
<P>The remainder of this section includes two pieces of writing by our
|
|
project leader</P>
|
|
<UL>
|
|
<LI>his<A href="#gilmore"> rationale</A> for starting this</LI>
|
|
<LI>another<A href="#policestate"> discussion</A> of project goals</LI>
|
|
</UL>
|
|
<P>and discussions of:</P>
|
|
<UL>
|
|
<LI><A href="#desnotsecure">why we do not use DES</A></LI>
|
|
<LI><A href="#exlaw">cryptography export laws</A></LI>
|
|
<LI>why<A href="#escrow"> government access to keys</A> is not a good
|
|
idea</LI>
|
|
<LI>the myth that<A href="#shortkeys"> short keys</A> are adequate for
|
|
some security requirements</LI>
|
|
</UL>
|
|
<P>and a section on<A href="#press"> press coverage of FreeS/WAN</A>.</P>
|
|
<H2><A name="leader">From our project leader</A></H2>
|
|
<P>FreeS/WAN project founder John Gilmore wrote a web page about why we
|
|
are doing this. The version below is slightly edited, to fit this
|
|
format and to update some links. For a version without these edits, see
|
|
his<A href="http://www.toad.com/gnu/"> home page</A>.</P>
|
|
<CENTER>
|
|
<H3><A name="gilmore">Swan: Securing the Internet against Wiretapping</A>
|
|
</H3>
|
|
</CENTER>
|
|
<P>My project for 1996 was to<B> secure 5% of the Internet traffic
|
|
against passive wiretapping</B>. It didn't happen in 1996, so I'm still
|
|
working on it in 1997, 1998, and 1999! If we get 5% in 1999 or 2000, we
|
|
can secure 20% the next year, against both active and passive attacks;
|
|
and 80% the following year. Soon the whole Internet will be private and
|
|
secure. The project is called S/WAN or S/Wan or Swan for Secure Wide
|
|
Area Network; since it's free software, we call it FreeSwan to
|
|
distinguish it from various commercial implementations.<A href="http://www.rsa.com/rsa/SWAN/">
|
|
RSA</A> came up with the term "S/WAN". Our main web site is at<A href="http://www.freeswan.org/">
|
|
http://www.freeswan.org/</A>. Want to help?</P>
|
|
<P>The idea is to deploy PC-based boxes that will sit between your local
|
|
area network and the Internet (near your firewall or router) which
|
|
opportunistically encrypt your Internet packets. Whenever you talk to a
|
|
machine (like a Web site) that doesn't support encryption, your traffic
|
|
goes out "in the clear" as usual. Whenever you connect to a machine
|
|
that does support this kind of encryption, this box automatically
|
|
encrypts all your packets, and decrypts the ones that come in. In
|
|
effect, each packet gets put into an "envelope" on one side of the net,
|
|
and removed from the envelope when it reaches its destination. This
|
|
works for all kinds of Internet traffic, including Web access, Telnet,
|
|
FTP, email, IRC, Usenet, etc.</P>
|
|
<P>The encryption boxes are standard PC's that use freely available
|
|
Linux software that you can download over the Internet or install from
|
|
a cheap CDROM.</P>
|
|
<P>This wasn't just my idea; lots of people have been working on it for
|
|
years. The encryption protocols for these boxes are called<A href="#IPSEC">
|
|
IPSEC (IP Security)</A>. They have been developed by the<A href="http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html">
|
|
IP Security Working Group</A> of the<A href="http://www.ietf.org/">
|
|
Internet Engineering Task Force</A>, and will be a standard part of the
|
|
next major version of the Internet protocols (<A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">
|
|
IPv6</A>). For today's (IP version 4) Internet, they are an option.</P>
|
|
<P>The<A href="http://www.iab.org/iab"> Internet Architecture Board</A>
|
|
and<A href="http://www.ietf.org/"> Internet Engineering Steering Group</A>
|
|
have taken a<A href="iab-iesg.stmt"> strong stand</A> that the Internet
|
|
should use powerful encryption to provide security and privacy. I think
|
|
these protocols are the best chance to do that, because they can be
|
|
deployed very easily, without changing your hardware or software or
|
|
retraining your users. They offer the best security we know how to
|
|
build, using the Triple-DES, RSA, and Diffie-Hellman algorithms.</P>
|
|
<P>This "opportunistic encryption box" offers the "fax effect". As each
|
|
person installs one for their own use, it becomes more valuable for
|
|
their neighbors to install one too, because there's one more person to
|
|
use it with. The software automatically notices each newly installed
|
|
box, and doesn't require a network administrator to reconfigure it.
|
|
Instead of "virtual private networks" we have a "REAL private network";
|
|
we add privacy to the real network instead of layering a
|
|
manually-maintained virtual network on top of an insecure Internet.</P>
|
|
<H4><A NAME="26_2_1_1">Deployment of IPSEC</A></H4>
|
|
<P>The US government would like to control the deployment of IP Security
|
|
with its<A href="#exlaw"> crypto export laws</A>. This isn't a problem
|
|
for my effort, because the cryptographic work is happening outside the
|
|
United States. A foreign philanthropist, and others, have donated the
|
|
resources required to add these protocols to the Linux operating
|
|
system.<A href="http://www.linux.org/"> Linux</A> is a complete, freely
|
|
available operating system for IBM PC's and several kinds of
|
|
workstation, which is compatible with Unix. It was written by Linus
|
|
Torvalds, and is still maintained by a talented team of expert
|
|
programmers working all over the world and coordinating over the
|
|
Internet. Linux is distributed under the<A href="#GPL"> GNU Public
|
|
License</A>, which gives everyone the right to copy it, improve it,
|
|
give it to their friends, sell it commercially, or do just about
|
|
anything else with it, without paying anyone for the privilege.</P>
|
|
<P>Organizations that want to secure their network will be able to put
|
|
two Ethernet cards into an IBM PC, install Linux on it from a $30 CDROM
|
|
or by downloading it over the net, and plug it in between their
|
|
Ethernet and their Internet link or firewall. That's all they'll have
|
|
to do to encrypt their Internet traffic everywhere outside their own
|
|
local area network.</P>
|
|
<P>Travelers will be able to run Linux on their laptops, to secure their
|
|
connection back to their home network (and to everywhere else that they
|
|
connect to, such as customer sites). Anyone who runs Linux on a
|
|
standalone PC will also be able to secure their network connections,
|
|
without changing their application software or how they operate their
|
|
computer from day to day.</P>
|
|
<P>There will also be numerous commercially available firewalls that use
|
|
this technology.<A href="http://www.rsa.com/"> RSA Data Security</A> is
|
|
coordinating the<A href="http://www.rsa.com/rsa/SWAN"> S/Wan (Secure
|
|
Wide Area Network)</A> project among more than a dozen vendors who use
|
|
these protocols. There's a<A href="http://www.rsa.com/rsa/SWAN/swan_test.htm">
|
|
compatability chart</A> that shows which vendors have tested their
|
|
boxes against which other vendors to guarantee interoperatility.</P>
|
|
<P>Eventually it will also move into the operating systems and
|
|
networking protocol stacks of major vendors. This will probably take
|
|
longer, because those vendors will have to figure out what they want to
|
|
do about the export controls.</P>
|
|
<H4><A NAME="26_2_1_2">Current status</A></H4>
|
|
<P>My initial goal of securing 5% of the net by Christmas '96 was not
|
|
met. It was an ambitious goal, and inspired me and others to work hard,
|
|
but was ultimately too ambitious. The protocols were in an early stage
|
|
of development, and needed a lot more protocol design before they could
|
|
be implemented. As of April 1999, we have released version 1.0 of the
|
|
software (<A href="ftp://ftp.xs4all.nl/freeswan/freeswan-1.0.tar.gz">
|
|
freeswan-1.0.tar.gz</A>), which is suitable for setting up Virtual
|
|
Private Networks using shared secrets for authentication. It does not
|
|
yet do opportunistic encryption, or use DNSSEC for authentication;
|
|
those features are coming in a future release.</P>
|
|
<DL>
|
|
<DT>Protocols</DT>
|
|
<DD>The low-level encrypted packet formats are defined. The system for
|
|
publishing keys and providing secure domain name service is defined.
|
|
The IP Security working group has settled on an NSA-sponsored protocol
|
|
for key agreement (called ISAKMP/Oakley), but it is still being worked
|
|
on, as the protocol and its documentation is too complex and
|
|
incomplete. There are prototype implementations of ISAKMP. The protocol
|
|
is not yet defined to enable opportunistic encryption or the use of
|
|
DNSSEC keys.</DD>
|
|
<DT>Linux Implementation</DT>
|
|
<DD>The Linux implementation has reached its first major release and is
|
|
ready for production use in manually-configured networks, using Linux
|
|
kernel version 2.0.36.</DD>
|
|
<DT>Domain Name System Security</DT>
|
|
<DD>There is now a release of BIND 8.2 that includes most DNS Security
|
|
features.
|
|
<P>The first prototype implementation of Domain Name System Security was
|
|
funded by<A href="#DARPA"> DARPA</A> as part of their<A href="http://www.darpa.mil/ito/research/is/index.html">
|
|
Information Survivability program</A>.<A href="http://www.tis.com">
|
|
Trusted Information Systems</A> wrote a modified version of<A href="http://www.isc.org/bind.html">
|
|
BIND</A>, the widely-used Berkeley implementation of the Domain Name
|
|
System.</P>
|
|
<P>TIS, ISC, and I merged the prototype into the standard version of
|
|
BIND. The first production version that supports KEY and SIG records is<B>
|
|
bind-4.9.5</B>. This or any later version of BIND will do for
|
|
publishing keys. It is available from the<A href="http://www.isc.org/bind.html">
|
|
Internet Software Consortium</A>. This version of BIND is not
|
|
export-controlled since it does not contain any cryptography. Later
|
|
releases starting with BIND 8.2 include cryptography for authenticating
|
|
DNS records, which is also exportable. Better documentation is needed.</P>
|
|
</DD>
|
|
</DL>
|
|
<H4><A NAME="26_2_1_3">Why?</A></H4>
|
|
<P>Because I can. I have made enough money from several successful
|
|
startup companies, that for a while I don't have to work to support
|
|
myself. I spend my energies and money creating the kind of world that
|
|
I'd like to live in and that I'd like my (future) kids to live in.
|
|
Keeping and improving on the civil rights we have in the United States,
|
|
as we move more of our lives into cyberspace, is a particular goal of
|
|
mine.</P>
|
|
<H4><A NAME="26_2_1_4">What You Can Do</A></H4>
|
|
<DL>
|
|
<DT>Install the latest BIND at your site.</DT>
|
|
<DD>You won't be able to publish any keys for your domain, until you
|
|
have upgraded your copy of BIND. The thing you really need from it is
|
|
the new version of<I> named</I>, the Name Daemon, which knows about the
|
|
new KEY and SIG record types. So, download it from the<A href="http://www.isc.org/bind.html">
|
|
Internet Software Consortium</A> and install it on your name server
|
|
machine (or get your system administrator, or Internet Service
|
|
Provider, to install it). Both your primary DNS site and all of your
|
|
secondary DNS sites will need the new release before you will be able
|
|
to publish your keys. You can tell which sites this is by running the
|
|
Unix command "dig MYDOMAIN ns" and seeing which sites are mentioned in
|
|
your NS (name server) records.</DD>
|
|
<DT>Set up a Linux system and run a 2.0.x kernel on it</DT>
|
|
<DD>Get a machine running Linux (say the 5.2 release from<A href="http://www.redhat.com">
|
|
Red Hat</A>). Give the machine two Ethernet cards.</DD>
|
|
<DT>Install the Linux IPSEC (Freeswan) software</DT>
|
|
<DD>If you're an experienced sysadmin or Linux hacker, install the
|
|
freeswan-1.0 release, or any later release or snapshot. These releases
|
|
do NOT provide automated "opportunistic" operation; they must be
|
|
manually configured for each site you wish to encrypt with.</DD>
|
|
<DT>Get on the linux-ipsec mailing list</DT>
|
|
<DD>The discussion forum for people working on the project, and testing
|
|
the code and documentation, is: [email protected]. To join this
|
|
mailing list, send email to<A href="mailto:[email protected]">
|
|
[email protected]</A> containing a line of text that says
|
|
"subscribe linux-ipsec". (You can later get off the mailing list the
|
|
same way -- just send "unsubscribe linux-ipsec").</DD>
|
|
<P></P>
|
|
<DT>Check back at this web page every once in a while</DT>
|
|
<DD>I update this page periodically, and there may be new information in
|
|
it that you haven't seen. My intent is to send email to the mailing
|
|
list when I update the page in any significant way, so subscribing to
|
|
the list is an alternative.</DD>
|
|
</DL>
|
|
<P>Would you like to help? I can use people who are willing to write
|
|
documentation, install early releases for testing, write cryptographic
|
|
code outside the United States, sell pre-packaged software or systems
|
|
including this technology, and teach classes for network administrators
|
|
who want to install this technology. To offer to help, send me email at
|
|
[email protected]. Tell me what country you live in and what your
|
|
citizenship is (it matters due to the export control laws; personally I
|
|
don't care). Include a copy of your resume and the URL of your home
|
|
page. Describe what you'd like to do for the project, and what you're
|
|
uniquely qualified for. Mention what other volunteer projects you've
|
|
been involved in (and how they worked out). Helping out will require
|
|
that you be able to commit to doing particular things, meet your
|
|
commitments, and be responsive by email. Volunteer projects just don't
|
|
work without those things.</P>
|
|
<H4><A NAME="26_2_1_5">Related projects</A></H4>
|
|
<DL>
|
|
<DT>IPSEC for NetBSD</DT>
|
|
<DD>This prototype implementation of the IP Security protocols is for
|
|
another free operating system.<A href="ftp://ftp.funet.fi/pub/unix/security/net/ip/BSDipsec.tar.gz">
|
|
Download BSDipsec.tar.gz</A>.</DD>
|
|
<DT>IPSEC for<A href="http://www.openbsd.org"> OpenBSD</A></DT>
|
|
<DD>This prototype implementation of the IP Security protocols is for
|
|
yet another free operating system. It is directly integrated into the
|
|
OS release, since the OS is maintained in Canada, which has freedom of
|
|
speech in software.</DD>
|
|
</DL>
|
|
<H3><A name="policestate">Stopping wholesale monitoring</A></H3>
|
|
<P>From a message project leader John Gilmore posted to the mailing
|
|
list:</P>
|
|
<PRE>John Denker wrote:
|
|
|
|
> Indeed there are several ways in which the documentation overstates the
|
|
> scope of what this project does -- starting with the name
|
|
> FreeS/WAN. There's a big difference between having an encrypted IP tunnel
|
|
> versus having a Secure Wide-Area Network. This software does a fine job of
|
|
> the former, which is necessary but not sufficient for the latter.
|
|
|
|
The goal of the project is to make it very hard to tap your wide area
|
|
communications. The current system provides very good protection
|
|
against passive attacks (wiretapping and those big antenna farms).
|
|
Active attacks, which involve the intruder sending packets to your
|
|
system (like packets that break into sendmail and give them a root
|
|
shell :-) are much harder to guard against. Active attacks that
|
|
involve sending people (breaking into your house and replacing parts
|
|
of your computer with ones that transmit what you're doing) are also
|
|
much harder to guard against. Though we are putting effort into
|
|
protecting against active attacks, it's a much bigger job than merely
|
|
providing strong encryption. It involves general computer security,
|
|
and general physical security, which are two very expensive problems
|
|
for even a site to solve, let alone to build into a whole society.
|
|
|
|
The societal benefit of building an infrastructure that protects
|
|
well against passive attacks is that it makes it much harder to do
|
|
undetected bulk monitoring of the population. It's a defense against
|
|
police-states, not against policemen.
|
|
|
|
Policemen can put in the effort required to actively attack sites that
|
|
they have strong suspicions about. But police states won't be able to
|
|
build systems that automatically monitor everyone's communications.
|
|
Either they will be able to monitor only a small subset of the
|
|
populace (by targeting those who screwed up their passive security),
|
|
or their monitoring activities will be detectable by those monitored
|
|
(active attacks leave packet traces or footprints), which can then be
|
|
addressed through the press and through political means if they become
|
|
too widespread.
|
|
|
|
FreeS/WAN does not protect very well against traffic analysis, which
|
|
is a kind of widespread police-state style monitoring that still
|
|
reveals significant information (who's talking to who) without
|
|
revealing the contents of what was said. Defenses against traffic
|
|
analysis are an open research problem. Zero Knowledge Systems is
|
|
actively deploying a system designed to thwart it, designed by Ian
|
|
Goldberg. The jury is out on whether it actually works; a lot more
|
|
experience with it will be needed.</PRE>
|
|
<P>Notes on things mentioned in that message:</P>
|
|
<UL>
|
|
<LI>Denker is a co-author of a<A href="#applied"> paper</A> on a large
|
|
FreeS/WAN application.</LI>
|
|
<LI>Information on Zero Knowledge is on their<A href="http://www.zks.net/">
|
|
web site</A>. Their Freedom product, designed to provide untracable
|
|
pseudonyms for use on the net, is no longer marketed.</LI>
|
|
<LI>Another section of our documentation discusses ways to<A href="#traffic.resist">
|
|
resist traffic analysis</A>.</LI>
|
|
</UL>
|
|
<H2><A name="weak">Government promotion of weak crypto</A></H2>
|
|
<P>Various groups, especially governments and especially the US
|
|
government, have a long history of advocating various forms of bogus
|
|
security.</P>
|
|
<P>We regard bogus security as extremely dangerous. If users are
|
|
deceived into relying on bogus security, then they may be exposed to
|
|
large risks. They would be better off having no security and knowing
|
|
it. At least then they would be careful about what they said.</P>
|
|
<P><STRONG>Avoiding bogus security is a key design criterion for
|
|
everything we do in FreeS/WAN</STRONG>. The most conspicuous example is
|
|
our refusal to support<A href="#desnotsecure"> single DES</A>. Other
|
|
IPsec "features" which we do not implement are discussed in our<A href="#dropped">
|
|
compatibility</A> document.</P>
|
|
<H3><A name="escrow">Escrowed encryption</A></H3>
|
|
<P>Various governments have made persistent attempts to encourage or
|
|
mandate "escrowed encrytion", also called "key recovery", or GAK for
|
|
"government access to keys". The idea is that cryptographic keys be
|
|
held by some third party and turned over to law enforcement or security
|
|
agencies under some conditions.</P>
|
|
<PRE> Mary had a little key - she kept it in escrow,
|
|
and every thing that Mary said,
|
|
the feds were sure to know.</PRE>
|
|
<P>A<A href="#quotes"> crypto quotes</A> page attributes this to<A href="http://www.scramdisk.clara.net/">
|
|
Sam Simpson</A>.</P>
|
|
<P>There is an excellent paper available on<A href="http://www.cdt.org/crypto/risks98/">
|
|
Risks of Escrowed Encryption</A>, from a group of cryptographic
|
|
luminaries which included our project leader.</P>
|
|
<P>Like any unnecessary complication, GAK tends to weaken security of
|
|
any design it infects. For example:</P>
|
|
<UL>
|
|
<LI>Matt Blaze found a fatal flaw in the US government's Clipper chip
|
|
shortly after design information became public. See his paper "Protocol
|
|
Failure in the Escrowed Encryption Standard" on his<A href="http://www.crypto.com/papers/">
|
|
papers</A> page.</LI>
|
|
<LI>a rather<A href="http://www.pgp.com/other/advisories/adk.asp"> nasty
|
|
bug</A> was found in the "additional decryption keys" "feature" of some
|
|
releases of<A href="#PGP"> PGP</A></LI>
|
|
</UL>
|
|
<P>FreeS/WAN does not support escrowed encryption, and never will.</P>
|
|
<H3><A name="shortkeys">Limited key lengths</A></H3>
|
|
<P>Various governments, and some vendors, have also made persistent
|
|
attempts to convince people that:</P>
|
|
<UL>
|
|
<LI>weak systems are sufficient for some data</LI>
|
|
<LI>strong cryptography should be reserved for cases where the extra
|
|
overheads are justified</LI>
|
|
</UL>
|
|
<P><STRONG>This is utter nonsense</STRONG>.</P>
|
|
<P>Weak systems touted include:</P>
|
|
<UL>
|
|
<LI>the ludicrously weak (deliberately crippled) 40-bit ciphers that
|
|
until recently were all various<A href="#exlaw"> export laws</A>
|
|
allowed</LI>
|
|
<LI>56-bit single DES, discussed<A href="#desnotsecure"> below</A></LI>
|
|
<LI>64-bit symmetric ciphers and 512-bit RSA, the maximums for
|
|
unrestricted export under various current laws</LI>
|
|
</UL>
|
|
<P>The notion that choice of ciphers or keysize should be determined by
|
|
a trade-off between security requirements and overheads is pure
|
|
bafflegab.</P>
|
|
<UL>
|
|
<LI>For most<A href="#symmetric"> symmetric ciphers</A>, it is simply a
|
|
lie. Any block cipher has some natural maximum keysize inherent in the
|
|
design -- 128 bits for<A href="#IDEA"> IDEA</A> or<A href="#CAST128">
|
|
CAST-128</A>, 256 for Serpent or Twofish, 448 for<A href="#Blowfish">
|
|
Blowfish</A> and 2048 for<A href="#RC4"> RC4</A>. Using a key size
|
|
smaller than that limit gives<EM> exactly zero</EM> savings in
|
|
overhead. The crippled 40-bit or 64-bit version of the cipher provides<EM>
|
|
no advantage whatsoever</EM>.</LI>
|
|
<LI><A href="#AES">AES</A> uses 10 rounds with 128-bit keys, 12 rounds
|
|
for 192-bit and 14 rounds for 256-bit, so there actually is a small
|
|
difference in overhead, but not enough to matter in most applications.</LI>
|
|
<LI>For<A href="#3DES"> triple DES</A> there is a grain of truth in the
|
|
argument. 3DES is indeed three times slower than single DES. However,
|
|
the solution is not to use the insecure single DES, but to pick a
|
|
faster secure cipher.<A href="#CAST128"> CAST-128</A>,<A href="#Blowfish">
|
|
Blowfish</A> and the<A href="#AES"> AES candidate</A> ciphers are are
|
|
all considerably faster in software than DES (let alone 3DES!), and
|
|
apparently secure.</LI>
|
|
<LI>For<A href="#public"> public key</A> techniques, there are extra
|
|
overheads for larger keys, but they generally do not affect overall
|
|
performance significantly. Practical public key applications are
|
|
usually<A href="#hybrid"> hybrid</A> systems in which the bulk of the
|
|
work is done by a symmetric cipher. The effect of increasing the cost
|
|
of the public key operations is typically negligible because the public
|
|
key operations use only a tiny fraction of total resources.
|
|
<P>For example, suppose public key operations use use 1% of the time in
|
|
a hybrid system and you triple the cost of public key operations. The
|
|
cost of symmetric cipher operations is unchanged at 99% of the original
|
|
total cost, so the overall effect is a jump from 99 + 1 = 100 to 99 + 3
|
|
= 102, a 2% rise in system cost.</P>
|
|
</LI>
|
|
</UL>
|
|
<P>In short,<STRONG> there has never been any technical reason to use
|
|
inadequate ciphers</STRONG>. The only reason there has ever been for
|
|
anyone to use such ciphers is that government agencies want weak
|
|
ciphers used so that they can crack them. The alleged savings are
|
|
simply propaganda.</P>
|
|
<PRE> Mary had a little key (It's all she could export),
|
|
and all the email that she sent was opened at the Fort.</PRE>
|
|
<P>A<A href="#quotes"> crypto quotes</A> page attributes this to<A href="http://theory.lcs.mit.edu:80/~rivest/">
|
|
Ron Rivest</A>. NSA headquarters is at Fort Meade, Maryland.</P>
|
|
<P>Our policy in FreeS/WAN is to use only cryptographic components with
|
|
adequate keylength and no known weaknesses.</P>
|
|
<UL>
|
|
<LI>We do not implement single DES because it is clearly<A href="#desnotsecure">
|
|
insecure</A>, so implemeting it would violate our policy of avoiding
|
|
bogus security. Our default cipher is<A href="#3DES"> 3DES</A></LI>
|
|
<LI>Similarly, we do not implement the 768-bit Group 1 for<A href="#DH">
|
|
Diffie-Hellman</A> key negotiation. We provide only the 1024-bit Group
|
|
2 and 1536-bit Group 5.</LI>
|
|
</UL>
|
|
<P>Detailed discussion of which IPsec features we implement or omit is
|
|
in out<A href="compat.html"> compatibility document</A>.</P>
|
|
<P>These decisions imply that we cannot fully conform to the IPsec RFCs,
|
|
since those have DES as the only required cipher and Group 1 as the
|
|
only required DH group. (In our view, the standards were subverted into
|
|
offerring bogus security.) Fortunately, we can still interoperate with
|
|
most other IPsec implementations since nearly all implementers provide
|
|
at least 3DES and Group 2 as well.</P>
|
|
<P>We hope that eventually the RFCs will catch up with our (and others')
|
|
current practice and reject dubious components. Some of our team and a
|
|
number of others are working on this in<A href="#ietf"> IETF</A>
|
|
working groups.</P>
|
|
<H4><A NAME="26_3_2_1">Some real trade-offs</A></H4>
|
|
<P>Of course, making systems secure does involve costs, and trade-offs
|
|
can be made between cost and security. However, the real trade-offs
|
|
have nothing to do with using weaker ciphers.</P>
|
|
<P>There can be substantial hardware and software costs. There are often
|
|
substantial training costs, both to train administrators and to
|
|
increase user awareness of security issues and procedures. There are
|
|
almost always substantial staff or contracting costs.</P>
|
|
<P>Security takes staff time for planning, implementation, testing and
|
|
auditing. Some of the issues are subtle; you need good (hence often
|
|
expensive) people for this. You also need people to monitor your
|
|
systems and respond to problems. The best safe ever built is insecure
|
|
if an attacker can work on it for days without anyone noticing. Any
|
|
computer is insecure if the administrator is "too busy" to check the
|
|
logs.</P>
|
|
<P>Moreover, someone in your organisation (or on contract to it) needs
|
|
to spend considerable time keeping up with new developments. EvilDoers<EM>
|
|
will</EM> know about new attacks shortly after they are found. You need
|
|
to know about them before your systems are attacked. If your vendor
|
|
provides a patch, you need to apply it. If the vendor does nothing, you
|
|
need to complain or start looking for another vendor.</P>
|
|
<P>For a fairly awful example, see this<A href="http://www.sans.org/newlook/alerts/NTE-bank.htm">
|
|
report</A>. In that case over a million credit card numbers were taken
|
|
from e-commerce sites, using security flaws in Windows NT servers.
|
|
Microsoft had long since released patches for most or all of the flaws,
|
|
but the site administrators had not applied them.</P>
|
|
<P>At an absolute minimum, you must do something about such issues<EM>
|
|
before</EM> an exploitation tool is posted to the net for downloading
|
|
by dozens of "script kiddies". Such a tool might appear at any time
|
|
from the announcement of the security hole to several months later.
|
|
Once it appears, anyone with a browser and an attitude can break any
|
|
system whose administrators have done nothing about the flaw.</P>
|
|
<P>Compared to those costs, cipher overheads are an insignificant factor
|
|
in the cost of security.</P>
|
|
<P>The only thing using a weak cipher can do for you is to cause all
|
|
your other investment to be wasted.</P>
|
|
<H2><A name="exlaw">Cryptography Export Laws</A></H2>
|
|
<P>Many nations restrict the export of cryptography and some restrict
|
|
its use by their citizens or others within their borders.</P>
|
|
<H3><A name="USlaw">US Law</A></H3>
|
|
<P>US laws, as currently interpreted by the US government, forbid export
|
|
of most cryptographic software from the US in machine-readable form
|
|
without government permission. In general, the restrictions apply even
|
|
if the software is widely-disseminated or public-domain and even if it
|
|
came from outside the US originally. Cryptography is legally a munition
|
|
and export is tightly controlled under the<A href="#EAR"> EAR</A>
|
|
Export Administration Regulations.</P>
|
|
<P>If you are a US citizen, your brain is considered US territory no
|
|
matter where it is physically located at the moment. The US believes
|
|
that its laws apply to its citizens everywhere, not just within the US.
|
|
Providing technical assistance or advice to foreign "munitions"
|
|
projects is illegal. The US government has very little sense of humor
|
|
about this issue and does not consider good intentions to be sufficient
|
|
excuse. Beware.</P>
|
|
<P>The<A href="http://www.bxa.doc.gov/Encryption/"> official website</A>
|
|
for these regulations is run by the Commerce Department's Bureau of
|
|
Export Administration (BXA).</P>
|
|
<P>The<A href="http://www.eff.org/bernstein/"> Bernstein case</A>
|
|
challenges the export restrictions on Constitutional grounds. Code is
|
|
speech so restrictions on export of code violate the First Amendment's
|
|
free speech provisions. This argument has succeeded in two levels of
|
|
court so far. It is quite likely to go on to the Supreme Court.</P>
|
|
<P>The regulations were changed substantially in January 2000,
|
|
apparently as a government attempt to get off the hook in the Bernstein
|
|
case. It is now legal to export public domain source code for
|
|
encryption, provided you notify the<A href="#BXA"> BXA</A>.</P>
|
|
<P>There are, however, still restrictions in force. Moreover, the
|
|
regulations can still be changed again whenever the government chooses
|
|
to do so. Short of a Supreme Court ruling (in the Berstein case or
|
|
another) that overturns the regulations completely, the problem of
|
|
export regulation is not likely to go away in the forseeable future.</P>
|
|
<H4><A name="UScontrib">US contributions to FreeS/WAN</A></H4>
|
|
<P>The FreeS/WAN project<STRONG> cannot accept software contributions,<EM>
|
|
not even small bug fixes</EM>, from US citizens or residents</STRONG>.
|
|
We want it to be absolutely clear that our distribution is not subject
|
|
to US export law. Any contribution from an American might open that
|
|
question to a debate we'd prefer to avoid. It might also put the
|
|
contributor at serious legal risk.</P>
|
|
<P>Of course Americans can still make valuable contributions (many
|
|
already have) by reporting bugs, or otherwise contributing to
|
|
discussions, on the project<A href="mail.html"> mailing list</A>. Since
|
|
the list is public, this is clearly constitutionally protected free
|
|
speech.</P>
|
|
<P>Note, however, that the export laws restrict Americans from providing
|
|
technical assistance to foreign "munitions" projects. The government
|
|
might claim that private discussions or correspondence with FreeS/WAN
|
|
developers were covered by this. It is not clear what the courts would
|
|
do with such a claim, so we strongly encourage Americans to use the
|
|
list rather than risk the complications.</P>
|
|
<H3><A name="wrong">What's wrong with restrictions on cryptography</A></H3>
|
|
<P>Some quotes from prominent cryptography experts:</P>
|
|
<BLOCKQUOTE> The real aim of current policy is to ensure the continued
|
|
effectiveness of US information warfare assets against individuals,
|
|
businesses and governments in Europe and elsewhere.
|
|
<BR><A href="http://www.cl.cam.ac.uk/users/rja14"> Ross Anderson,
|
|
Cambridge University</A></BLOCKQUOTE><BLOCKQUOTE> If the government
|
|
were honest about its motives, then the debate about crypto export
|
|
policy would have ended years ago.
|
|
<BR><A href="http://www.counterpane.com"> Bruce Schneier, Counterpane
|
|
Systems</A></BLOCKQUOTE><BLOCKQUOTE> The NSA regularly lies to people
|
|
who ask it for advice on export control. They have no reason not to;
|
|
accomplishing their goal by any legal means is fine by them. Lying by
|
|
government employees is legal.
|
|
<BR> John Gilmore.</BLOCKQUOTE>
|
|
<P>The Internet Architecture Board (IAB) and the Internet Engineering
|
|
Steering Group (IESG) made a<A href="iab-iesg.stmt"> strong statement</A>
|
|
in favour of worldwide access to strong cryptography. Essentially the
|
|
same statement is in the appropriately numbered<A href="ftp://ftp.isi.edu/in-notes/rfc1984.txt">
|
|
RFC 1984</A>. Two critical paragraphs are:</P>
|
|
<BLOCKQUOTE> ... various governments have actual or proposed policies on
|
|
access to cryptographic technology ...
|
|
<P>(a) ... export controls ...
|
|
<BR> (b) ... short cryptographic keys ...
|
|
<BR> (c) ... keys should be in the hands of the government or ...
|
|
<BR> (d) prohibit the use of cryptology ...</P>
|
|
<P>We believe that such policies are against the interests of consumers
|
|
and the business community, are largely irrelevant to issues of
|
|
military security, and provide only a marginal or illusory benefit to
|
|
law enforcement agencies, ...</P>
|
|
<P>The IAB and IESG would like to encourage policies that allow ready
|
|
access to uniform strong cryptographic technology for all Internet
|
|
users in all countries.</P>
|
|
</BLOCKQUOTE>
|
|
<P>Our goal in the FreeS/WAN project is to build just such "strong
|
|
cryptographic technology" and to distribute it "for all Internet users
|
|
in all countries".</P>
|
|
<P>More recently, the same two bodies (IESG and IAB) have issued<A href="ftp://ftp.isi.edu/in-notes/rfc2804.txt">
|
|
RFC 2804</A> on why the IETF should not build wiretapping capabilities
|
|
into protocols for the convenience of security or law enforcement
|
|
agenicies. The abstract from that document is:</P>
|
|
<BLOCKQUOTE> The Internet Engineering Task Force (IETF) has been asked
|
|
to take a position on the inclusion into IETF standards-track documents
|
|
of functionality designed to facilitate wiretapping.
|
|
<P>This memo explains what the IETF thinks the question means, why its
|
|
answer is "no", and what that answer means.</P>
|
|
</BLOCKQUOTE> A quote from the debate leading up to that RFC:<BLOCKQUOTE>
|
|
We should not be building surveillance technology into standards. Law
|
|
enforcement was not supposed to be easy. Where it is easy, it's called
|
|
a police state.
|
|
<BR> Jeff Schiller of MIT, in a discussion of FBI demands for wiretap
|
|
capability on the net, as quoted by<A href="http://www.wired.com/news/politics/0,1283,31895,00.html">
|
|
Wired</A>.</BLOCKQUOTE>
|
|
<P>The<A href="http://www.ietf.org/mailman/listinfo/raven"> Raven</A>
|
|
mailing list was set up for this IETF discussion.</P>
|
|
<P>Our goal is to go beyond that RFC and prevent Internet wiretapping
|
|
entirely.</P>
|
|
<H3><A name="Wassenaar">The Wassenaar Arrangement</A></H3>
|
|
<P>Restrictions on the export of cryptography are not just US policy,
|
|
though some consider the US at least partly to blame for the policies
|
|
of other nations in this area.</P>
|
|
<P>A number of countries:</P>
|
|
<P>Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech
|
|
Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland,
|
|
Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland,
|
|
Portugal, Republic of Korea, Romania, Russian Federation, Slovak
|
|
Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom
|
|
and United States</P>
|
|
<P>have signed the Wassenaar Arrangement which restricts export of
|
|
munitions and other tools of war. Cryptographic sofware is covered
|
|
there.</P>
|
|
<P>Wassenaar details are available from the<A href="http://www.wassenaar.org/">
|
|
Wassenaar Secretariat</A>, and elsewhere in a more readable<A href="http://www.fitug.de/news/wa/index.html">
|
|
HTML version</A>.</P>
|
|
<P>For a critique see the<A href="http://www.gilc.org/crypto/wassenaar">
|
|
GILC site</A>:</P>
|
|
<BLOCKQUOTE> The Global Internet Liberty Campaign (GILC) has begun a
|
|
campaign calling for the removal of cryptography controls from the
|
|
Wassenaar Arrangement.
|
|
<P>The aim of the Wassenaar Arrangement is to prevent the build up of
|
|
military capabilities that threaten regional and international security
|
|
and stability . . .</P>
|
|
<P>There is no sound basis within the Wassenaar Arrangement for the
|
|
continuation of any export controls on cryptographic products.</P>
|
|
</BLOCKQUOTE>
|
|
<P>We agree entirely.</P>
|
|
<P>An interesting analysis of Wassenaar can be found on the<A href="http://www.cyber-rights.org/crypto/wassenaar.htm">
|
|
cyber-rights.org</A> site.</P>
|
|
<H3><A name="status">Export status of Linux FreeS/WAN</A></H3>
|
|
<P>We believe our software is entirely exempt from these controls since
|
|
the Wassenaar<A href="http://www.wassenaar.org/list/GTN%20and%20GSN%20-%2099.pdf">
|
|
General Software Note</A> says:</P>
|
|
<BLOCKQUOTE> The Lists do not control "software" which is either:
|
|
<OL>
|
|
<LI>Generally available to the public by . . . retail . . . or</LI>
|
|
<LI>"In the public domain".</LI>
|
|
</OL>
|
|
</BLOCKQUOTE>
|
|
<P>There is a note restricting some of this, but it is a sub-heading
|
|
under point 1, so it appears not to apply to public domain software.</P>
|
|
<P>Their glossary defines "In the public domain" as:</P>
|
|
<BLOCKQUOTE> . . . "technology" or "software" which has been made
|
|
available without restrictions upon its further dissemination.
|
|
<P>N.B. Copyright restrictions do not remove "technology" or "software"
|
|
from being "in the public domain".</P>
|
|
</BLOCKQUOTE>
|
|
<P>We therefore believe that software freely distributed under the<A href="#GPL">
|
|
GNU Public License</A>, such as Linux FreeS/WAN, is exempt from
|
|
Wassenaar restrictions.</P>
|
|
<P>Most of the development work is being done in Canada. Our
|
|
understanding is that the Canadian government accepts this
|
|
interpretation.</P>
|
|
<UL>
|
|
<LI>A web statement of<A href="http://www.dfait-maeci.gc.ca/~eicb/notices/ser113-e.htm">
|
|
Canadian policy</A> is available from the Department of Foreign Affairs
|
|
and International Trade.</LI>
|
|
<LI>Another document from that department states that<A href="http://www.dfait-maeci.gc.ca/~eicb/export/gr1_e.htm">
|
|
public domain software</A> is exempt from the export controls.</LI>
|
|
<LI>A researcher's<A href="http://insight.mcmaster.ca/org/efc/pages/doc/crypto-export.html">
|
|
analysis</A> of Canadian policy is also available.</LI>
|
|
</UL>
|
|
<P>Recent copies of the freely modifiable and distributable source code
|
|
exist in many countries. Citizens all over the world participate in its
|
|
use and evolution, and guard its ongoing distribution. Even if Canadian
|
|
policy were to change, the software would continue to evolve in
|
|
countries which do not restrict exports, and would continue to be
|
|
imported from there into unfree countries. "The Net culture treats
|
|
censorship as damage, and routes around it."</P>
|
|
<H3><A name="help">Help spread IPsec around</A></H3>
|
|
<P>You can help. If you don't know of a Linux FreeS/WAN archive in your
|
|
own country, please download it now to your personal machine, and
|
|
consider making it publicly accessible if that doesn't violate your own
|
|
laws. If you have the resources, consider going one step further and
|
|
setting up a mirror site for the whole<A href="#munitions"> munitions</A>
|
|
Linux crypto software archive.</P>
|
|
<P>If you make Linux CD-ROMs, please consider including this code, in a
|
|
way that violates no laws (in a free country, or in a domestic-only CD
|
|
product).</P>
|
|
<P>Please send a note about any new archive mirror sites or CD
|
|
distributions to [email protected] so we can update the
|
|
documentation.</P>
|
|
<P>Lists of current<A href="#sites"> mirror sites</A> and of<A href="#distwith">
|
|
distributions</A> which include FreeS/WAN are in our introduction
|
|
section.</P>
|
|
<H2><A name="desnotsecure">DES is Not Secure</A></H2>
|
|
<P>DES, the<STRONG> D</STRONG>ata<STRONG> E</STRONG>ncryption<STRONG> S</STRONG>
|
|
tandard, can no longer be considered secure. While no major flaws in its
|
|
innards are known, it is fundamentally inadequate because its<STRONG>
|
|
56-bit key is too short</STRONG>. It is vulnerable to<A href="#brute">
|
|
brute-force search</A> of the whole key space, either by large
|
|
collections of general-purpose machines or even more quickly by
|
|
specialized hardware. Of course this also applies to<STRONG> any other
|
|
cipher with only a 56-bit key</STRONG>. The only reason anyone could
|
|
have for using a 56 or 64-bit key is to comply with various<A href="exportlaw.html">
|
|
export laws</A> intended to ensure the use of breakable ciphers.</P>
|
|
<P>Non-government cryptologists have been saying DES's 56-bit key was
|
|
too short for some time -- some of them were saying it in the 70's when
|
|
DES became a standard -- but the US government has consistently
|
|
ridiculed such suggestions.</P>
|
|
<P>A group of well-known cryptographers looked at key lengths in a<A href="http://www.counterpane.com/keylength.html">
|
|
1996 paper</A>. They suggested a<EM> minimum</EM> of 75 bits to
|
|
consider an existing cipher secure and a<EM> minimum of 90 bits for new
|
|
ciphers</EM>. More recent papers, covering both<A href="#symmetric">
|
|
symmetric</A> and<A href="#public"> public key</A> systems are at<A href="http://www.cryptosavvy.com/">
|
|
cryptosavvy.com</A> and<A href="http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html">
|
|
rsa.com</A>. For all algorithms, the minimum keylengths recommended in
|
|
such papers are significantly longer than the maximums allowed by
|
|
various export laws.</P>
|
|
<P>In a<A href="http://www.privacy.nb.ca/cryptography/archives/cryptography/html/1998-09/0095.html">
|
|
1998 ruling</A>, a German court described DES as "out-of-date and not
|
|
safe enough" and held a bank liable for using it.</P>
|
|
<H3><A name="deshware">Dedicated hardware breaks DES in a few days</A></H3>
|
|
<P>The question of DES security has now been settled once and for all.
|
|
In early 1998, the<A href="http://www.eff.org/"> Electronic Frontier
|
|
Foundation</A> built a<A href="http://www.eff.org/descracker.html">
|
|
DES-cracking machine</A>. It can find a DES key in an average of a few
|
|
days' search. The details of all this, including complete code listings
|
|
and complete plans for the machine, have been published in<A href="#EFF">
|
|
<CITE> Cracking DES</CITE></A>, by the Electronic Frontier Foundation.</P>
|
|
<P>That machine cost just over $200,000 to design and build. "Moore's
|
|
Law" is that machines get faster (or cheaper, for the same speed) by
|
|
roughly a factor of two every 18 months. At that rate, their $200,000
|
|
in 1998 becomes $50,000 in 2001.</P>
|
|
<P>However, Moore's Law is not exact and the $50,000 estimate does not
|
|
allow for the fact that a copy based on the published EFF design would
|
|
cost far less than the original. We cannot say exactly what such a
|
|
cracker would cost today, but it would likely be somewhere between
|
|
$10,000 and $100,000.</P>
|
|
<P>A large corporation could build one of these out of petty cash. The
|
|
cost is low enough for a senior manager to hide it in a departmental
|
|
budget and avoid having to announce or justify the project. Any
|
|
government agency, from a major municipal police force up, could afford
|
|
one. Or any other group with a respectable budget -- criminal
|
|
organisations, political groups, labour unions, religious groups, ...
|
|
Or any millionaire with an obsession or a grudge, or just strange taste
|
|
in toys.</P>
|
|
<P>One might wonder if a private security or detective agency would have
|
|
one for rent. They wouldn't need many clients to pay off that
|
|
investment.</P>
|
|
<H3><A name="spooks">Spooks may break DES faster yet</A></H3>
|
|
<P>As for the security and intelligence agencies of various nations,
|
|
they may have had DES crackers for years, and theirs may be much
|
|
faster. It is difficult to make most computer applications work well on
|
|
parallel machines, or to design specialised hardware to accelerate
|
|
them. Cipher-cracking is one of the very few exceptions. It is entirely
|
|
straightforward to speed up cracking by just adding hardware. Within
|
|
very broad limits, you can make it as fast as you like if you have the
|
|
budget. The EFF's $200,000 machine breaks DES in a few days. An<A href="http://www.planepage.com/">
|
|
aviation website</A> gives the cost of a B1 bomber as $200,000,000.
|
|
Spending that much, an intelligence agency could break DES in an
|
|
average time of<EM> six and a half minutes</EM>.</P>
|
|
<P>That estimate assumes they use the EFF's 1998 technology and just
|
|
spend more money. They may have an attack that is superior to brute
|
|
force, they quite likely have better chip technology (Moore's law, a
|
|
bigger budget, and whatever secret advances they may have made) and of
|
|
course they may have spent the price of an aircraft carrier, not just
|
|
one aircraft.</P>
|
|
<P>In short, we have<EM> no idea</EM> how quickly these organisations
|
|
can break DES. Unless they're spectacularly incompetent or horribly
|
|
underfunded, they can certainly break it, but we cannot guess how
|
|
quickly. Pick any time unit between days and milliseconds; none is
|
|
entirely unbelievable. More to the point, none of them is of any
|
|
comfort if you don't want such organisations reading your
|
|
communications.</P>
|
|
<P>Note that this may be a concern even if nothing you do is a threat to
|
|
anyone's national security. An intelligence agency might well consider
|
|
it to be in their national interest for certain companies to do well.
|
|
If you're competing against such companies in a world market and that
|
|
agency can read your secrets, you have a serious problem.</P>
|
|
<P>One might wonder about technology the former Soviet Union and its
|
|
allies developed for cracking DES during the Cold War. They must have
|
|
tried; the cipher was an American standard and widely used. Certainly
|
|
those countries have some fine mathematicians, and those agencies had
|
|
budget. How well did they succeed? Is their technology now for sale or
|
|
rent?</P>
|
|
<H3><A name="desnet">Networks break DES in a few weeks</A></H3>
|
|
<P>Before the definitive EFF effort, DES had been cracked several times
|
|
by people using many machines. See this<A href="http://www.distributed.net/pressroom/DESII-1-PR.html">
|
|
press release</A> for example.</P>
|
|
<P>A major corporation, university, or government department could break
|
|
DES by using spare cycles on their existing collection of computers, by
|
|
dedicating a group of otherwise surplus machines to the problem, or by
|
|
combining the two approaches. It might take them weeks or months,
|
|
rather than the days required for the EFF machine, but they could do
|
|
it.</P>
|
|
<P>What about someone working alone, without the resources of a large
|
|
organisation? For them, cracking DES will not be easy, but it may be
|
|
possible. A few thousand dollars buys a lot of surplus workstations. A
|
|
pile of such machines will certainly heat your garage nicely and might
|
|
break DES in a few months or years. Or enroll at a university and use
|
|
their machines. Or use an employer's machines. Or crack security
|
|
somewhere and steal the resources to crack a DES key. Or write a virus
|
|
that steals small amounts of resources on many machines. Or . . .</P>
|
|
<P>None of these approaches are easy or break DES really quickly, but an
|
|
attacker only needs to find one that is feasible and breaks DES quickly
|
|
enough to be dangerous. How much would you care to bet that this will
|
|
be impossible if the attacker is clever and determined? How valuable is
|
|
your data? Are you authorised to risk it on a dubious bet?</P>
|
|
<H3><A name="no_des">We disable DES</A></H3>
|
|
<P>In short, it is now absolutely clear that<STRONG> DES is not secure</STRONG>
|
|
against</P>
|
|
<UL>
|
|
<LI>any<STRONG> well-funded opponent</STRONG></LI>
|
|
<LI>any opponent (even a penniless one) with access (even stolen access)
|
|
to<STRONG> enough general purpose computers</STRONG></LI>
|
|
</UL>
|
|
<P>That is why<STRONG> Linux FreeS/WAN disables all transforms which use
|
|
plain DES</STRONG> for encryption.</P>
|
|
<P>DES is in the source code, because we need DES to implement our
|
|
default encryption transform,<A href="#3DES"> Triple DES</A>.<STRONG>
|
|
We urge you not to use single DES</STRONG>. We do not provide any easy
|
|
way to enable it in FreeS/WAN, and our policy is to provide no
|
|
assistance to anyone wanting to do so.</P>
|
|
<H3><A name="40joke">40-bits is laughably weak</A></H3>
|
|
<P>The same is true, in spades, of ciphers -- DES or others -- crippled
|
|
by 40-bit keys, as many ciphers were required to be until recently
|
|
under various<A href="#exlaw"> export laws</A>. A brute force search of
|
|
such a cipher's keyspace is 2<SUP>16</SUP> times faster than a similar
|
|
search against DES. The EFF's machine can do a brute-force search of a
|
|
40-bit key space in<EM> seconds</EM>. One contest to crack a 40-bit
|
|
cipher was won by a student<A href="http://catless.ncl.ac.uk/Risks/18.80.html#subj1">
|
|
using a few hundred idle machines at his university</A>. It took only
|
|
three and half hours.</P>
|
|
<P>We do not, and will not, implement any 40-bit cipher.</P>
|
|
<H3><A name="altdes">Triple DES is almost certainly secure</A></H3>
|
|
<P><A href="#3DES">Triple DES</A>, usually abbreviated 3DES, applies DES
|
|
three times, with three different keys. DES seems to be basically an
|
|
excellent cipher design; it has withstood several decades of intensive
|
|
analysis without any disastrous flaws being found. It's only major flaw
|
|
is that the small keyspace allows brute force attacks to succeeed.
|
|
Triple DES enlarges the key space to 168 bits, making brute-force
|
|
search a ridiculous impossibility.</P>
|
|
<P>3DES is currently the only block cipher implemented in FreeS/WAN.
|
|
3DES is, unfortunately, about 1/3 the speed of DES, but modern CPUs
|
|
still do it at quite respectable speeds. Some<A href="#benchmarks">
|
|
speed measurements</A> for our code are available.</P>
|
|
<H3><A name="aes.ipsec">AES in IPsec</A></H3>
|
|
<P>The<A href="#AES"> AES</A> project has chosen a replacement for DES,
|
|
a new standard cipher for use in non-classified US government work and
|
|
in regulated industries such as banking. This cipher will almost
|
|
certainly become widely used for many applications, including IPsec.</P>
|
|
<P>The winner, announced in October 2000 after several years of analysis
|
|
and discussion, was the<A href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael/">
|
|
Rijndael</A> cipher from two Belgian designers.</P>
|
|
<P>It is almost certain that FreeS/WAN will add AES support.<A href="#patch">
|
|
AES patches</A> are already available.</P>
|
|
<H2><A name="press">Press coverage of Linux FreeS/WAN:</A></H2>
|
|
<H3><A NAME="26_6_1">FreeS/WAN 1.0 press</A></H3>
|
|
<UL>
|
|
<LI><A href="http://www.wired.com/news/news/technology/story/19136.html">
|
|
Wired</A> "Linux-Based Crypto Stops Snoops", James Glave April 15 1999</LI>
|
|
<LI><A href="http://slashdot.org/articles/99/04/15/1851212.shtml">
|
|
Slashdot</A></LI>
|
|
<LI><A href="http://dgl.com/itinfo/1999/it990415.html">DGL</A>, Damar
|
|
Group Limited; looking at FreeS/WAN from a perspective of business
|
|
computing</LI>
|
|
<LI><A href="http://linuxtoday.com/stories/5010.html">Linux Today</A></LI>
|
|
<LI><A href="http://www.tbtf.com/archive/1999-04-21.html#Tcep">TBTF</A>,
|
|
Tasty Bits from the Technology Front</LI>
|
|
<LI><A href="http://www.salonmagazine.com/tech/log/1999/04/16/encryption/index.html">
|
|
Salon Magazine</A> "Free Encryption Takes a Big Step"</LI>
|
|
</UL>
|
|
<H3><A name="release">Press release for version 1.0</A></H3>
|
|
<PRE> Strong Internet Privacy Software Free for Linux Users Worldwide
|
|
|
|
Toronto, ON, April 14, 1999 -
|
|
|
|
The Linux FreeS/WAN project today released free software to protect
|
|
the privacy of Internet communications using strong encryption codes.
|
|
FreeS/WAN automatically encrypts data as it crosses the Internet, to
|
|
prevent unauthorized people from receiving or modifying it. One
|
|
ordinary PC per site runs this free software under Linux to become a
|
|
secure gateway in a Virtual Private Network, without having to modify
|
|
users' operating systems or application software. The project built
|
|
and released the software outside the United States, avoiding US
|
|
government regulations which prohibit good privacy protection.
|
|
FreeS/WAN version 1.0 is available immediately for downloading at
|
|
http://www.xs4all.nl/~freeswan/.
|
|
|
|
"Today's FreeS/WAN release allows network administrators to build
|
|
excellent secure gateways out of old PCs at no cost, or using a cheap
|
|
new PC," said John Gilmore, the entrepreneur who instigated the
|
|
project in 1996. "They can build operational experience with strong
|
|
network encryption and protect their users' most important
|
|
communications worldwide."
|
|
|
|
"The software was written outside the United States, and we do not
|
|
accept contributions from US citizens or residents, so that it can be
|
|
freely published for use in every country," said Henry Spencer, who
|
|
built the release in Toronto, Canada. "Similar products based in the
|
|
US require hard-to-get government export licenses before they can be
|
|
provided to non-US users, and can never be simply published on a Web
|
|
site. Our product is freely available worldwide for immediate
|
|
downloading, at no cost."
|
|
|
|
FreeS/WAN provides privacy against both quiet eavesdropping (such as
|
|
"packet sniffing") and active attempts to compromise communications
|
|
(such as impersonating participating computers). Secure "tunnels" carry
|
|
information safely across the Internet between locations such as a
|
|
company's main office, distant sales offices, and roaming laptops. This
|
|
protects the privacy and integrity of all information sent among those
|
|
locations, including sensitive intra-company email, financial transactions
|
|
such as mergers and acquisitions, business negotiations, personal medical
|
|
records, privileged correspondence with lawyers, and information about
|
|
crimes or civil rights violations. The software will be particularly
|
|
useful to frequent wiretapping targets such as private companies competing
|
|
with government-owned companies, civil rights groups and lawyers,
|
|
opposition political parties, and dissidents.
|
|
|
|
FreeS/WAN provides privacy for Internet packets using the proposed
|
|
standard Internet Protocol Security (IPSEC) protocols. FreeS/WAN
|
|
negotiates strong keys using Diffie-Hellman key agreement with 1024-bit
|
|
keys, and encrypts each packet with 168-bit Triple-DES (3DES). A modern
|
|
$500 PC can set up a tunnel in less than a second, and can encrypt
|
|
6 megabits of packets per second, easily handling the whole available
|
|
bandwidth at the vast majority of Internet sites. In preliminary testing,
|
|
FreeS/WAN interoperated with 3DES IPSEC products from OpenBSD, PGP, SSH,
|
|
Cisco, Raptor, and Xedia. Since FreeS/WAN is distributed as source code,
|
|
its innards are open to review by outside experts and sophisticated users,
|
|
reducing the chance of undetected bugs or hidden security compromises.
|
|
|
|
The software has been in development for several years. It has been
|
|
funded by several philanthropists interested in increased privacy on
|
|
the Internet, including John Gilmore, co-founder of the Electronic
|
|
Frontier Foundation, a leading online civil rights group.
|
|
|
|
Press contacts:
|
|
Hugh Daniel, +1 408 353 8124, [email protected]
|
|
Henry Spencer, +1 416 690 6561, [email protected]
|
|
|
|
* FreeS/WAN derives its name from S/WAN, which is a trademark of RSA Data
|
|
Security, Inc; used by permission.</PRE>
|
|
<HR>
|
|
<H1><A name="ipsec.detail">The IPsec protocols</A></H1>
|
|
<P>This section provides information on the IPsec protocols which
|
|
FreeS/WAN implements. For more detail, see the<A href="rfc.html"> RFCs</A>
|
|
.</P>
|
|
<P>The basic idea of IPsec is to provide security functions,<A href="#authentication">
|
|
authentication</A> and<A href="#encryption"> encryption</A>, at the IP
|
|
(Internet Protocol) level. This requires a higher-level protocol (IKE)
|
|
to set things up for the IP-level services (ESP and AH).</P>
|
|
<H2><A NAME="27_1">Protocols and phases</A></H2>
|
|
<P>Three protocols are used in an IPsec implementation:</P>
|
|
<DL>
|
|
<DT>ESP, Encapsulating Security Payload</DT>
|
|
<DD>Encrypts and/or authenticates data</DD>
|
|
<DT>AH, Authentication Header</DT>
|
|
<DD>Provides a packet authentication service</DD>
|
|
<DT>IKE, Internet Key Exchange</DT>
|
|
<DD>Negotiates connection parameters, including keys, for the other two</DD>
|
|
</DL>
|
|
<P>The term "IPsec" (also written as IPSEC) is slightly ambiguous. In
|
|
some contexts, it includes all three of the above but in other contexts
|
|
it refers only to AH and ESP.</P>
|
|
<P>There is more detail below, but a quick summary of how the whole
|
|
thing works is:</P>
|
|
<DL>
|
|
<DT>Phase one IKE (main mode exchange)</DT>
|
|
<DD>sets up a keying channel (ISAKMP SA) between the two gateways</DD>
|
|
<DT>Phase two IKE (quick mode exchange)</DT>
|
|
<DD>sets up data channels (IPsec SAs)</DD>
|
|
<DT>IPsec proper</DT>
|
|
<DD>exchanges data using AH or ESP</DD>
|
|
</DL>
|
|
<P>Both phases of IKE are repeated periodically to automate re-keying.</P>
|
|
<H2><A name="others">Applying IPsec</A></H2>
|
|
<P>Authentication and encryption functions for network data can, of
|
|
course, be provided at other levels. Many security protocols work at
|
|
levels above IP.</P>
|
|
<UL>
|
|
<LI><A href="#PGP">PGP</A> encrypts and authenticates mail messages</LI>
|
|
<LI><A href="#ssh">SSH</A> authenticates remote logins and then encrypts
|
|
the session</LI>
|
|
<LI><A href="#SSL">SSL</A> or<A href="#TLS"> TLS</A> provides security
|
|
at the sockets layer, e.g. for secure web browsing</LI>
|
|
</UL>
|
|
<P>and so on. Other techniques work at levels below IP. For example,
|
|
data on a communications circuit or an entire network can be encrypted
|
|
by specialised hardware. This is common practice in high-security
|
|
applications.</P>
|
|
<H3><A name="advantages">Advantages of IPsec</A></H3>
|
|
<P>There are, however, advantages to doing it at the IP level instead
|
|
of, or as well as, at other levels.</P>
|
|
<P>IPsec is the<STRONG> most general way to provide these services for
|
|
the Internet</STRONG>.</P>
|
|
<UL>
|
|
<LI>Higher-level services protect a<EM> single protocol</EM>; for
|
|
example PGP protects mail.</LI>
|
|
<LI>Lower level services protect a<EM> single medium</EM>; for example a
|
|
pair of encryption boxes on the ends of a line make wiretaps on that
|
|
line useless unless the attacker is capable of breaking the encryption.</LI>
|
|
</UL>
|
|
<P>IPsec, however, can protect<EM> any protocol</EM> running above IP
|
|
and<EM> any medium</EM> which IP runs over. More to the point, it can
|
|
protect a mixture of application protocols running over a complex
|
|
combination of media. This is the normal situation for Internet
|
|
communication; IPsec is the only general solution.</P>
|
|
<P>IPsec can also provide some security services "in the background",
|
|
with<STRONG> no visible impact on users</STRONG>. To use<A href="#PGP">
|
|
PGP</A> encryption and signatures on mail, for example, the user must
|
|
at least:</P>
|
|
<UL>
|
|
<LI>remember his or her passphrase,</LI>
|
|
<LI>keep it secure</LI>
|
|
<LI>follow procedures to validate correspondents' keys</LI>
|
|
</UL>
|
|
<P>These systems can be designed so that the burden on users is not
|
|
onerous, but any system will place some requirements on users. No such
|
|
system can hope to be secure if users are sloppy about meeting those
|
|
requirements. The author has seen username and password stuck on
|
|
terminals with post-it notes in an allegedly secure environment, for
|
|
example.</P>
|
|
<H3><A name="limitations">Limitations of IPsec</A></H3>
|
|
<P>IPsec is designed to secure IP links between machines. It does that
|
|
well, but it is important to remember that there are many things it
|
|
does not do. Some of the important limitations are:</P>
|
|
<DL>
|
|
<DT><A name="depends">IPsec cannot be secure if your system isn't</A></DT>
|
|
<DD>System security on IPsec gateway machines is an essential
|
|
requirement if IPsec is to function as designed. No system can be
|
|
trusted if the underlying machine has been subverted. See books on Unix
|
|
security such as<A href="#practical"> Garfinkel and Spafford</A> or our
|
|
web references for<A href="#linsec"> Linux security</A> or more general<A
|
|
href="#compsec"> computer security</A>.
|
|
<P>Of course, there is another side to this. IPsec can be a powerful
|
|
tool for improving system and network security. For example, requiring
|
|
packet authentication makes various spoofing attacks harder and IPsec
|
|
tunnels can be extremely useful for secure remote administration of
|
|
various things.</P>
|
|
</DD>
|
|
<DT><A name="not-end-to-end">IPsec is not end-to-end</A></DT>
|
|
<DD>IPsec cannot provide the same end-to-end security as systems working
|
|
at higher levels. IPsec encrypts an IP connection between two machines,
|
|
which is quite a different thing than encrypting messages between users
|
|
or between applications.
|
|
<P>For example, if you need mail encrypted from the sender's desktop to
|
|
the recipient's desktop and decryptable only by the recipient, use<A href="#PGP">
|
|
PGP</A> or another such system. IPsec can encrypt any or all of the
|
|
links involved -- between the two mail servers, or between either
|
|
server and its clients. It could even be used to secure a direct IP
|
|
link from the sender's desktop machine to the recipient's, cutting out
|
|
any sort of network snoop. What it cannot ensure is end-to-end
|
|
user-to-user security. If only IPsec is used to secure mail, then
|
|
anyone with appropriate privileges on any machine where that mail is
|
|
stored (at either end or on any store-and-forward servers in the path)
|
|
can read it.</P>
|
|
<P>In another common setup, IPsec encrypts packets at a security gateway
|
|
machine as they leave the sender's site and decrypts them on arrival at
|
|
the gateway to the recipient's site. This does provide a useful
|
|
security service -- only encrypted data is passed over the Internet --
|
|
but it does not even come close to providing an end-to-end service. In
|
|
particular, anyone with appropriate privileges on either site's LAN can
|
|
intercept the message in unencrypted form.</P>
|
|
</DD>
|
|
<DT><A name="notpanacea">IPsec cannot do everything</A></DT>
|
|
<DD>IPsec also cannot provide all the functions of systems working at
|
|
higher levels of the protocol stack. If you need a document
|
|
electronically signed by a particular person, then you need his or her<A
|
|
href="#signature"> digital signature</A> and a<A href="#public"> public
|
|
key cryptosystem</A> to verify it with.
|
|
<P>Note, however, that IPsec authentication of the underlying
|
|
communication can make various attacks on higher-level protocols more
|
|
difficult. In particular, authentication prevents<A href="#middle">
|
|
man-in-the-middle attacks</A>.</P>
|
|
</DD>
|
|
<DT><A name="no_user">IPsec authenticates machines, not users</A></DT>
|
|
<DD>IPsec uses strong authentication mechanisms to control which
|
|
messages go to which machines, but it does not have the concept of user
|
|
ID, which is vital to many other security mechansims and policies. This
|
|
means some care must be taken in fitting the various security
|
|
mechansims on a network together. For example, if you need to control
|
|
which users access your database server, you need some non-IPsec
|
|
mechansim for that. IPsec can control which machines connect to the
|
|
server, and can ensure that data transfer to those machines is done
|
|
securely, but that is all. Either the machines themselves must control
|
|
user access or there must be some form of user authentication to the
|
|
database, independent of IPsec.</DD>
|
|
<DT><A name="DoS">IPsec does not stop denial of service attacks</A></DT>
|
|
<DD><A href="#DOS">Denial of service</A> attacks aim at causing a system
|
|
to crash, overload, or become confused so that legitimate users cannot
|
|
get whatever services the system is supposed to provide. These are
|
|
quite different from attacks in which the attacker seeks either to use
|
|
the service himself or to subvert the service into delivering incorrect
|
|
results.
|
|
<P>IPsec shifts the ground for DoS attacks; the attacks possible against
|
|
systems using IPsec are different than those that might be used against
|
|
other systems. It does not, however, eliminate the possibility of such
|
|
attacks.</P>
|
|
</DD>
|
|
<DT><A name="traffic">IPsec does not stop traffic analysis</A></DT>
|
|
<DD><A href="#traffic">Traffic analysis</A> is the attempt to derive
|
|
intelligence from messages without regard for their contents. In the
|
|
case of IPsec, it would mean analysis based on things visible in the
|
|
unencrypted headers of encrypted packets -- source and destination
|
|
gateway addresses, packet size, et cetera. Given the resources to
|
|
acquire such data and some skill in analysing it (both of which any
|
|
national intelligence agency should have), this can be a very powerful
|
|
technique.
|
|
<P>IPsec is not designed to defend against this. Partial defenses are
|
|
certainly possible, and some are<A href="#traffic.resist"> described
|
|
below</A>, but it is not clear that any complete defense can be
|
|
provided.</P>
|
|
</DD>
|
|
</DL>
|
|
<H3><A name="uses">IPsec is a general mechanism for securing IP</A></H3>
|
|
<P>While IPsec does not provide all functions of a mail encryption
|
|
package, it can encrypt your mail. In particular, it can ensure that
|
|
all mail passing between a pair or a group of sites is encrypted. An
|
|
attacker looking only at external traffic, without access to anything
|
|
on or behind the IPsec gateway, cannot read your mail. He or she is
|
|
stymied by IPsec just as he or she would be by<A href="#PGP"> PGP</A>.</P>
|
|
<P>The advantage is that IPsec can provide the same protection for<STRONG>
|
|
anything transmitted over IP</STRONG>. In a corporate network example,
|
|
PGP lets the branch offices exchange secure mail with head office. SSL
|
|
and SSH allow them to securely view web pages, connect as terminals to
|
|
machines, and so on. IPsec can support all those applications, plus
|
|
database queries, file sharing (NFS or Windows), other protocols
|
|
encapsulated in IP (Netware, Appletalk, ...), phone-over-IP,
|
|
video-over-IP, ... anything-over-IP. The only limitation is that IP
|
|
Multicast is not yet supported, though there are Internet Draft
|
|
documents for that.</P>
|
|
<P>IPsec creates<STRONG> secure tunnels through untrusted networks</STRONG>
|
|
. Sites connected by these tunnels form VPNs,<A href="#VPN"> Virtual
|
|
Private Networks</A>.</P>
|
|
<P>IPsec gateways can be installed wherever they are required.</P>
|
|
<UL>
|
|
<LI>One organisation might choose to install IPsec only on firewalls
|
|
between their LANs and the Internet. This would allow them to create a
|
|
VPN linking several offices. It would provide protection against anyone
|
|
outside their sites.</LI>
|
|
<LI>Another might install IPsec on departmental servers so everything on
|
|
the corporate backbone net was encrypted. This would protect messages
|
|
on that net from everyone except the sending and receiving department.</LI>
|
|
<LI>Another might be less concerned with information secrecy and more
|
|
with controlling access to certain resources. They might use IPsec
|
|
packet authentication as part of an access control mechanism, with or
|
|
without also using the IPsec encryption service.</LI>
|
|
<LI>It is even possible (assuming adequate processing power and an IPsec
|
|
implementation in each node) to make every machine its own IPsec
|
|
gateway so that everything on a LAN is encrypted. This protects
|
|
information from everyone outside the sending and receiving machine.</LI>
|
|
<LI>These techniques can be combined in various ways. One might, for
|
|
example, require authentication everywhere on a network while using
|
|
encryption only for a few links.</LI>
|
|
</UL>
|
|
<P>Which of these, or of the many other possible variants, to use is up
|
|
to you.<STRONG> IPsec provides mechanisms; you provide the policy</STRONG>
|
|
.</P>
|
|
<P><STRONG>No end user action is required</STRONG> for IPsec security to
|
|
be used; they don't even have to know about it. The site
|
|
administrators, of course, do have to know about it and to put some
|
|
effort into making it work. Poor administration can compromise IPsec as
|
|
badly as the post-it notes mentioned above. It seems reasonable,
|
|
though, for organisations to hope their system administrators are
|
|
generally both more security-conscious than end users and more able to
|
|
follow computer security procedures. If not, at least there are fewer
|
|
of them to educate or replace.</P>
|
|
<P>IPsec can be, and often should be, used with along with security
|
|
protocols at other levels. If two sites communicate with each other via
|
|
the Internet, then IPsec is the obvious way to protect that
|
|
communication. If two others have a direct link between them, either
|
|
link encryption or IPsec would make sense. Choose one or use both.
|
|
Whatever you use at and below the IP level, use other things as
|
|
required above that level. Whatever you use above the IP level,
|
|
consider what can be done with IPsec to make attacks on the higher
|
|
levels harder. For example,<A href="#middle"> man-in-the-middle attacks</A>
|
|
on various protocols become difficult if authentication at packet level
|
|
is in use on the potential victims' communication channel.</P>
|
|
<H3><A name="authonly">Using authentication without encryption</A></H3>
|
|
<P>Where appropriate, IPsec can provide authentication without
|
|
encryption. One might do this, for example:</P>
|
|
<UL>
|
|
<LI>where the data is public but one wants to be sure of getting the
|
|
right data, for example on some web sites</LI>
|
|
<LI>where encryption is judged unnecessary, for example on some company
|
|
or department LANs</LI>
|
|
<LI>where strong encryption is provided at link level, below IP</LI>
|
|
<LI>where strong encryption is provided in other protocols, above IP
|
|
<BR> Note that IPsec authentication may make some attacks on those
|
|
protocols harder.</LI>
|
|
</UL>
|
|
<P>Authentication has lower overheads than encryption.</P>
|
|
<P>The protocols provide four ways to build such connections, using
|
|
either an AH-only connection or ESP using null encryption, and in
|
|
either manually or automatically keyed mode. FreeS/WAN supports only
|
|
one of these, manually keyed AH-only connections, and<STRONG> we do not
|
|
recommend using that</STRONG>. Our reasons are discussed under<A href="#traffic.resist">
|
|
Resisting traffic analysis</A> a few sections further along.</P>
|
|
<H3><A name="encnoauth">Encryption without authentication is dangerous</A>
|
|
</H3>
|
|
<P>Originally, the IPsec encryption protocol<A href="#ESP"> ESP</A>
|
|
didn't do integrity checking. It only did encryption. Steve Bellovin
|
|
found many ways to attack ESP used without authentication. See his
|
|
paper<A href="http://www.research.att.com/~smb/papers/badesp.ps">
|
|
Problem areas for the IP Security Protocols</A>. To make a secure
|
|
connection, you had to add an<A href="#AH"> AH</A> Authentication
|
|
Header as well as ESP. Rather than incur the overhead of several layers
|
|
(and rather than provide an ESP layer that didn't actually protect the
|
|
traffic), the IPsec working group built integrity and replay checking
|
|
directly into ESP.</P>
|
|
<P>Today, typical usage is one of:</P>
|
|
<UL>
|
|
<LI>ESP for encryption and authentication</LI>
|
|
<LI>AH for authentication alone</LI>
|
|
</UL>
|
|
<P>Other variants are allowed by the standard, but not much used:</P>
|
|
<DL>
|
|
<DT>ESP encryption without authentication</DT>
|
|
<DD><STRONG>Bellovin has demonstrated fatal flaws in this. Do not use.</STRONG>
|
|
</DD>
|
|
<DT>ESP encryption with AH authentication</DT>
|
|
<DD>This has higher overheads than using the authentication in ESP, and
|
|
no obvious benefit in most cases. The exception might be a network
|
|
where AH authentication was widely or universally used. If you're going
|
|
to do AH to conform with network policy, why authenticate again in the
|
|
ESP layer?</DD>
|
|
<DT>Authenticate twice, with AH and with ESP</DT>
|
|
<DD>Why? Of course, some folk consider "belt and suspenders" the
|
|
sensible approach to security. If you're among them, you might use both
|
|
protocols here. You might also use both to satisfy different parts of a
|
|
security policy. For example, an organisation might require AH
|
|
authentication everywhere but two users within the organisation might
|
|
use ESP as well.</DD>
|
|
<DT>ESP authentication without encryption</DT>
|
|
<DD>The standard allows this, calling it "null encryption". FreeS/WAN
|
|
does not support it. We recommend that you use AH instead if
|
|
authentication is all you require. AH authenticates parts of the IP
|
|
header, which ESP-null does not do.</DD>
|
|
</DL>
|
|
<P>Some of these variants cannot be used with FreeS/WAN because we do
|
|
not support ESP-null and do not support automatic keying of AH-only
|
|
connections.</P>
|
|
<P>There are fairly frequent suggestions that AH be dropped entirely
|
|
from the IPsec specifications since ESP and null encryption can handle
|
|
that situation. It is not clear whether this will occur. My guess is
|
|
that it is unlikely.</P>
|
|
<H3><A name="multilayer">Multiple layers of IPsec processing are
|
|
possible</A></H3>
|
|
<P>The above describes combinations possible on a single IPsec
|
|
connection. In a complex network you may have several layers of IPsec
|
|
in play, with any of the above combinations at each layer.</P>
|
|
<P>For example, a connection from a desktop machine to a database server
|
|
might require AH authentication. Working with other host, network and
|
|
database security measures, AH might be just the thing for access
|
|
control. You might decide not to use ESP encryption on such packets,
|
|
since it uses resources and might complicate network debugging. Within
|
|
the site where the server is, then, only AH would be used on those
|
|
packets.</P>
|
|
<P>Users at another office, however, might have their whole connection
|
|
(AH headers and all) passing over an IPsec tunnel connecting their
|
|
office to the one with the database server. Such a tunnel should use
|
|
ESP encryption and authentication. You need authentication in this
|
|
layer because without authentication the encryption is vulnerable and
|
|
the gateway cannot verify the AH authentication. The AH is between
|
|
client and database server; the gateways aren't party to it.</P>
|
|
<P>In this situation, some packets would get multiple layers of IPsec
|
|
applied to them, AH on an end-to-end client-to-server basis and ESP
|
|
from one office's security gateway to the other.</P>
|
|
<H3><A name="traffic.resist">Resisting traffic analysis</A></H3>
|
|
<P><A href="#traffic">Traffic analysis</A> is the attempt to derive
|
|
useful intelligence from encrypted traffic without breaking the
|
|
encryption.</P>
|
|
<P>Is your CEO exchanging email with a venture capital firm? With
|
|
bankruptcy trustees? With an executive recruiting agency? With the
|
|
holder of some important patents? If an eavesdropper learns about any
|
|
of those, then he has interesting intelligence on your company, whether
|
|
or not he can read the messages themselves.</P>
|
|
<P>Even just knowing that there is network traffic between two sites may
|
|
tell an analyst something useful, especially when combined with
|
|
whatever other information he or she may have. For example, if you know
|
|
Company A is having cashflow problems and Company B is looking for
|
|
aquisitions, then knowing that packets are passing between the two is
|
|
interesting. It is more interesting if you can tell it is email, and
|
|
perhaps yet more if you know the sender and recipient.</P>
|
|
<P>Except in the simplest cases, traffic analysis is hard to do well. It
|
|
requires both considerable resources and considerable analytic skill.
|
|
However, intelligence agencies of various nations have been doing it
|
|
for centuries and many of them are likely quite good at it by now.
|
|
Various commercial organisations, especially those working on "targeted
|
|
marketing" may also be quite good at analysing certain types of
|
|
traffic.</P>
|
|
<P>In general, defending against traffic analysis is also difficult.
|
|
Inventing a really good defense could get you a PhD and some
|
|
interesting job offers.</P>
|
|
<P>IPsec is not designed to stop traffic analysis and we know of no
|
|
plausible method of extending it to do so. That said, there are ways to
|
|
make traffic analysis harder. This section describes them.</P>
|
|
<H4><A name="extra">Using "unnecessary" encryption</A></H4>
|
|
<P>One might choose to use encryption even where it appears unnecessary
|
|
in order to make analysis more difficult. Consider two offices which
|
|
pass a small volume of business data between them using IPsec and also
|
|
transfer large volumes of Usenet news. At first glance, it would seem
|
|
silly to encrypt the newsfeed, except possibly for any newsgroups that
|
|
are internal to the company. Why encrypt data that is all publicly
|
|
available from many sites?</P>
|
|
<P>However, if we encrypt a lot of news and send it down the same
|
|
connection as our business data, we make<A href="#traffic"> traffic
|
|
analysis</A> much harder. A snoop cannot now make inferences based on
|
|
patterns in the volume, direction, sizes, sender, destination, or
|
|
timing of our business messages. Those messages are hidden in a mass of
|
|
news messages encapsulated in the same way.</P>
|
|
<P>If we're going to do this we need to ensure that keys change often
|
|
enough to remain secure even with high volumes and with the adversary
|
|
able to get plaintext of much of the data. We also need to look at
|
|
other attacks this might open up. For example, can the adversary use a
|
|
chosen plaintext attack, deliberately posting news articles which, when
|
|
we receive and encrypt them, will help break our encryption? Or can he
|
|
block our business data transmission by flooding us with silly news
|
|
articles? Or ...</P>
|
|
<P>Also, note that this does not provide complete protection against
|
|
traffic analysis. A clever adversary might still deduce useful
|
|
intelligence from statistical analysis (perhaps comparing the input
|
|
newsfeed to encrypted output, or comparing the streams we send to
|
|
different branch offices), or by looking for small packets which might
|
|
indicate establishment of TCP connections, or ...</P>
|
|
<P>As a general rule, though, to improve resistance to traffic analysis,
|
|
you should<STRONG> encrypt as much traffic as possible, not just as
|
|
much as seems necessary.</STRONG></P>
|
|
<H4><A name="multi-encrypt">Using multiple encryption</A></H4>
|
|
<P>This also applies to using multiple layers of encryption. If you have
|
|
an IPsec tunnel between two branch offices, it might appear silly to
|
|
send<A href="#PGP"> PGP</A>-encrypted email through that tunnel.
|
|
However, if you suspect someone is snooping your traffic, then it does
|
|
make sense:</P>
|
|
<UL>
|
|
<LI>it protects the mail headers; they cannot even see who is mailing
|
|
who</LI>
|
|
<LI>it protects against user bungles or software malfunctions that
|
|
accidentally send messages in the clear</LI>
|
|
<LI>it makes any attack on the mail encryption much harder; they have to
|
|
break IPsec or break into your network before they can start on the
|
|
mail encryption</LI>
|
|
</UL>
|
|
<P>Similar arguments apply for<A href="#SSL"> SSL</A>-encrypted web
|
|
traffic or<A href="#ssh"> SSH</A>-encrypted remote login sessions, even
|
|
for end-to-end IPsec tunnels between systems in the two offices.</P>
|
|
<H4><A name="fewer">Using fewer tunnels</A></H4>
|
|
<P>It may also help to use fewer tunnels. For example, if all you
|
|
actually need encrypted is connections between:</P>
|
|
<UL>
|
|
<LI>mail servers at branch and head offices</LI>
|
|
<LI>a few branch office users and the head office database server</LI>
|
|
</UL>
|
|
<P>You might build one tunnel per mail server and one per remote
|
|
database user, restricting traffic to those applications. This gives
|
|
the traffic analyst some information, however. He or she can
|
|
distinguish the tunnels by looking at information in the ESP header
|
|
and, given that distinction and the patterns of tunnel usage, might be
|
|
able to figure out something useful. Perhaps not, but why take the
|
|
risk?</P>
|
|
<P>We suggest instead that you build one tunnel per branch office,
|
|
encrypting everything passing from head office to branches. This has a
|
|
number of advantages:</P>
|
|
<UL>
|
|
<LI>it is easier to build and administer</LI>
|
|
<LI>it resists traffic analysis somewhat better</LI>
|
|
<LI>it provides security for whatever you forgot. For example, if some
|
|
user at a remote office browses proprietary company data on some head
|
|
office web page (that the security people may not even know about!),
|
|
then that data is encrypted before it reaches the Internet.</LI>
|
|
</UL>
|
|
<P>Of course you might also want to add additional tunnels. For example,
|
|
if some of the database data is confidential and should not be exposed
|
|
even within the company, then you need protection from the user's
|
|
desktop to the database server. We suggest you do that in whatever way
|
|
seems appropriate -- IPsec, SSH or SSL might fit -- but, whatever you
|
|
choose, pass it between locations via a gateway-to-gateway IPsec tunnel
|
|
to provide some resistance to traffic analysis.</P>
|
|
<H2><A name="primitives">Cryptographic components</A></H2>
|
|
<P>IPsec combines a number of cryptographic techniques, all of them
|
|
well-known and well-analyzed. The overall design approach was
|
|
conservative; no new or poorly-understood components were included.</P>
|
|
<P>This section gives a brief overview of each technique. It is intended
|
|
only as an introduction. There is more information, and links to
|
|
related topics, in our<A href="glossary.html"> glossary</A>. See also
|
|
our<A href="biblio.html"> bibliography</A> and cryptography<A href="#crypto.link">
|
|
web links</A>.</P>
|
|
<H3><A name="block.cipher">Block ciphers</A></H3>
|
|
<P>The<A href="#encryption"> encryption</A> in the<A href="#ESP"> ESP</A>
|
|
encapsulation protocol is done with a<A href="#block"> block cipher</A>
|
|
.</P>
|
|
<P>We do not implement<A href="#DES"> single DES</A>. It is<A href="#desnotsecure">
|
|
insecure</A>. Our default, and currently only, block cipher is<A href="#3DES">
|
|
triple DES</A>.</P>
|
|
<P>The<A href="#rijndael"> Rijndael</A> block cipher has won the<A href="#AES">
|
|
AES</A> competition to choose a relacement for DES. It will almost
|
|
certainly be added to FreeS/WAN and to other IPsec implementations.<A href="#patch">
|
|
Patches</A> are already available.</P>
|
|
<H3><A name="hash.ipsec">Hash functions</A></H3>
|
|
<H4><A name="hmac.ipsec">The HMAC construct</A></H4>
|
|
<P>IPsec packet authentication is done with the<A href="#HMAC"> HMAC</A>
|
|
construct. This is not just a hash of the packet data, but a more
|
|
complex operation which uses both a hashing algorithm and a key. It
|
|
therefore does more than a simple hash would. A simple hash would only
|
|
tell you that the packet data was not changed in transit, or that
|
|
whoever changed it also regenerated the hash. An HMAC also tells you
|
|
that the sender knew the HMAC key.</P>
|
|
<P>For IPsec HMAC, the output of the hash algorithm is truncated to 96
|
|
bits. This saves some space in the packets. More important, it prevents
|
|
an attacker from seeing all the hash output bits and perhaps creating
|
|
some sort of attack based on that knowledge.</P>
|
|
<H4><A NAME="27_3_2_2">Choice of hash algorithm</A></H4>
|
|
<P>The IPsec RFCs require two hash algorithms --<A href="#MD5"> MD5</A>
|
|
and<A href="#SHA"> SHA-1</A> -- both of which FreeS/WAN implements.</P>
|
|
<P>Various other algorithms -- such as RIPEMD and Tiger -- are listed in
|
|
the RFCs as optional. None of these are in the FreeS/WAN distribution,
|
|
or are likely to be added, although user<A href="#patch"> patches</A>
|
|
exist for several of them.</P>
|
|
<P>Additional hash algorithms --<A href="#SHA-256"> SHA-256, SHA-384 and
|
|
SHA-512</A> -- may be required to give hash strength matching the
|
|
strength of<A href="#AES"> AES</A>. These are likely to be added to
|
|
FreeS/WAN along with AES.</P>
|
|
<H3><A name="DH.keying">Diffie-Hellman key agreement</A></H3>
|
|
<P>The<A href="#DH"> Diffie-Hellman</A> key agreement protocol allows
|
|
two parties (A and B or<A href="#alicebob"> Alice and Bob</A>) to agree
|
|
on a key in such a way that an eavesdropper who intercepts the entire
|
|
conversation cannot learn the key.</P>
|
|
<P>The protocol is based on the<A href="#dlog"> discrete logarithm</A>
|
|
problem and is therefore thought to be secure. Mathematicians have been
|
|
working on that problem for years and seem no closer to a solution,
|
|
though there is no proof that an efficient solution is impossible.</P>
|
|
<H3><A name="RSA.auth">RSA authentication</A></H3>
|
|
<P>The<A href="#RSA"> RSA</A> algorithm (named for its inventors --
|
|
Rivest, Shamir and Adleman) is a very widely used<A href="glossary.html#">
|
|
public key</A> cryptographic technique. It is used in IPsec as one
|
|
method of authenticating gateways for Diffie-Hellman key negotiation.</P>
|
|
<H2><A name="structure">Structure of IPsec</A></H2>
|
|
<P>There are three protocols used in an IPsec implementation:</P>
|
|
<DL>
|
|
<DT>ESP, Encapsulating Security Payload</DT>
|
|
<DD>Encrypts and/or authenticates data</DD>
|
|
<DT>AH, Authentication Header</DT>
|
|
<DD>Provides a packet authentication service</DD>
|
|
<DT>IKE, Internet Key Exchange</DT>
|
|
<DD>Negotiates connection parameters, including keys, for the other two</DD>
|
|
</DL>
|
|
<P>The term "IPsec" is slightly ambiguous. In some contexts, it includes
|
|
all three of the above but in other contexts it refers only to AH and
|
|
ESP.</P>
|
|
<H3><A name="IKE.ipsec">IKE (Internet Key Exchange)</A></H3>
|
|
<P>The IKE protocol sets up IPsec (ESP or AH) connections after
|
|
negotiating appropriate parameters (algorithms to be used, keys,
|
|
connection lifetimes) for them. This is done by exchanging packets on
|
|
UDP port 500 between the two gateways.</P>
|
|
<P>IKE (RFC 2409) was the outcome of a long, complex process in which
|
|
quite a number of protocols were proposed and debated. Oversimplifying
|
|
mildly, IKE combines:</P>
|
|
<DL>
|
|
<DT>ISAKMP (RFC 2408)</DT>
|
|
<DD>The<STRONG> I</STRONG>nternet<STRONG> S</STRONG>ecurity<STRONG> A</STRONG>
|
|
ssociation and<STRONG> K</STRONG>ey<STRONG> M</STRONG>anagement<STRONG>
|
|
P</STRONG>rotocol manages negotiation of connections and defines<A href="#SA">
|
|
SA</A>s (Security Associations) as a means of describing connection
|
|
properties.</DD>
|
|
<DT>IPsec DOI for ISAKMP (RFC 2407)</DT>
|
|
<DD>A<STRONG> D</STRONG>omain<STRONG> O</STRONG>f<STRONG> I</STRONG>
|
|
nterpretation fills in the details necessary to turn the rather abstract
|
|
ISAKMP protocol into a more tightly specified protocol, so it becomes
|
|
applicable in a particular domain.</DD>
|
|
<DT>Oakley key determination protocol (RFC 2412)</DT>
|
|
<DD>Oakley creates keys using the<A href="#DH"> Diffie-Hellman</A> key
|
|
agreement protocol.</DD>
|
|
</DL>
|
|
<P>For all the details, you would need to read the four<A href="rfc.html">
|
|
RFCs</A> just mentioned (over 200 pages) and a number of others. We
|
|
give a summary below, but it is far from complete.</P>
|
|
<H4><A name="phases">Phases of IKE</A></H4>
|
|
<P>IKE negotiations have two phases.</P>
|
|
<DL>
|
|
<DT>Phase one</DT>
|
|
<DD>The two gateways negotiate and set up a two-way ISAKMP SA which they
|
|
can then use to handle phase two negotiations. One such SA between a
|
|
pair of gateways can handle negotiations for multiple tunnels.</DD>
|
|
<DT>Phase two</DT>
|
|
<DD>Using the ISAKMP SA, the gateways negotiate IPsec (ESP and/or AH)
|
|
SAs as required. IPsec SAs are unidirectional (a different key is used
|
|
in each direction) and are always negotiated in pairs to handle two-way
|
|
traffic. There may be more than one pair defined between two gateways.</DD>
|
|
</DL>
|
|
<P>Both of these phases use the UDP protocol and port 500 for their
|
|
negotiations.</P>
|
|
<P>After both IKE phases are complete, you have IPsec SAs to carry your
|
|
encrypted data. These use the ESP or AH protocols. These protocols do
|
|
not have ports. Ports apply only to UDP or TCP.</P>
|
|
<P>The IKE protocol is designed to be extremely flexible. Among the
|
|
things that can be negotiated (separately for each SA) are:</P>
|
|
<UL>
|
|
<LI>SA lifetime before rekeying</LI>
|
|
<LI>encryption algorithm used. We currently support only<A href="#3DES">
|
|
triple DES</A>. Single DES is<A href="#desnotsecure"> insecure</A>. The
|
|
RFCs say you MUST do DES, SHOULD do 3DES and MAY do various others. We
|
|
do not do any of the others.</LI>
|
|
<LI>authentication algorithms. We support<A href="#MD5"> MD5</A> and<A href="#SHA">
|
|
SHA</A>. These are the two the RFCs require.</LI>
|
|
<LI>choice of group for<A href="#DH"> Diffie-Hellman</A> key agreement.
|
|
We currently support Groups 2 and 5 (which are defined modulo primes of
|
|
various lengths) and do not support Group 1 (defined modulo a shorter
|
|
prime, and therefore cryptographically weak) or groups 3 and 4 (defined
|
|
using elliptic curves). The RFCs require only Group 1.</LI>
|
|
</UL>
|
|
<P>The protocol also allows implementations to add their own encryption
|
|
algorithms, authentication algorithms or Diffie-Hellman groups. We do
|
|
not support any such extensions, but there are some<A href="#patch">
|
|
patches</A> that do.</P>
|
|
<P>There are a number of complications:</P>
|
|
<UL>
|
|
<LI>The gateways must be able to authenticate each other's identities
|
|
before they can create a secure connection. This host authentication is
|
|
part of phase one negotiations, and is a required prerequisite for
|
|
packet authentication used later. Host authentication can be done in a
|
|
variety of ways. Those supported by FreeS/WAN are discussed in our<A href="#auto-auth">
|
|
advanced configuration</A> document.</LI>
|
|
<LI>Phase one can be done in two ways.
|
|
<UL>
|
|
<LI>Main Mode is required by the RFCs and supported in FreeS/WAN. It
|
|
uses a 6-packet exzchange.</LI>
|
|
<LI>Aggressive Mode is somewhat faster (only 3 packets) but reveals more
|
|
to an eavesdropper. This is optional in the RFCs, not currently
|
|
supported by FreeS/WAN, and not likely to be.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>A new group exchange may take place after phase one but before phase
|
|
two, defining an additional group for use in the<A href="#DH">
|
|
Diffie-Hellman</A> key agreement part of phase two. FreeS/WAN does not
|
|
currently support this.</LI>
|
|
<LI>Phase two always uses Quick Mode, but there are two variants of
|
|
that:
|
|
<UL>
|
|
<LI>One variant provides<A href="#PFS"> Perfect Forward Secrecy (PFS)</A>
|
|
. An attacker that obtains your long-term host authentication key does
|
|
not immediately get any of your short-term packet encryption of packet
|
|
authentication keys. He must conduct another successful attack each
|
|
time you rekey to get the short-term keys. Having some short-term keys
|
|
does not help him learn others. In particular, breaking your system
|
|
today does not let him read messages he archived yestarday, assuming
|
|
you've changed short-term keys in the meanwhile. We enable PFS as the
|
|
default.</LI>
|
|
<LI>The other variant disables PFS and is therefore slightly faster. We
|
|
do not recommend this since it is less secure, but FreeS/WAN does
|
|
support it. You can enable it with a<VAR> pfs=no</VAR> statement in<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A>.</LI>
|
|
<LI>The protocol provides no way to negotiate which variant will be
|
|
used. If one gateway is set for PFS and the other is not, the
|
|
negotiation fails. This has proved a fairly common source of
|
|
interoperation problems.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Several types of notification message may be sent by either side
|
|
during either phase, or later. FreeS/WAN does not currently support
|
|
these, but they are a likely addition in future releases.</LI>
|
|
<LI>There is a commit flag which may optionally be set on some messages.
|
|
The<A href="http://www.lounge.org/ike_doi_errata.html"> errata</A> page
|
|
for the RFCs includes two changes related to this, one to clarify the
|
|
description of its use and one to block a<A href="#DOS"> denial of
|
|
service</A> attack which uses it. We currently do not implement this
|
|
feature.</LI>
|
|
</UL>
|
|
<P>These complications can of course lead to problems, particularly when
|
|
two different implementations attempt to interoperate. For example, we
|
|
have seen problems such as:</P>
|
|
<UL>
|
|
<LI>Some implementations (often products crippled by<A href="#exlaw">
|
|
export laws</A>) have the insecure DES algorithm as their only
|
|
supported encryption method. Other parts of our documentation discuss
|
|
the<A href="#desnotsecure"> reasons we do not implement single DES</A>,
|
|
and<A href="interop.html#noDES"> how to cope with crippled products</A>
|
|
.</LI>
|
|
<LI>Windows 2000 IPsec tries to negotiate using Aggressive Mode, which
|
|
we don't support. Later on, it uses the commit bit, which we also don't
|
|
support.</LI>
|
|
<LI>Various implementations disable PFS by default, and therefore will
|
|
not talk to FreeS/WAN until you either turn on PFS on their end or turn
|
|
it off in FreeS/WAN with a<VAR> pfs=no</VAR> entry in the connection
|
|
description.</LI>
|
|
<LI>FreeS/WAN's interaction with PGPnet is complicated by their use of
|
|
notification messages we do not yet support.</LI>
|
|
</UL>
|
|
<P>Despite this, we do interoperate successfully with many
|
|
implementations, including both Windows 2000 and PGPnet. Details are in
|
|
our<A href="interop.html"> interoperability</A> document.</P>
|
|
<H4><A name="sequence">Sequence of messages in IKE</A></H4>
|
|
<P>Each phase (see<A href="#phases"> previous section</A>)of IKE
|
|
involves a series of messages. In Pluto error messages, these are
|
|
abbreviated using:</P>
|
|
<DL>
|
|
<DT>M</DT>
|
|
<DD><STRONG>M</STRONG>ain mode, settting up the keying channel (ISAKMP
|
|
SA)</DD>
|
|
<DT>Q</DT>
|
|
<DD><STRONG>Q</STRONG>uick mode, setting up the data channel (IPsec SA)</DD>
|
|
<DT>I</DT>
|
|
<DD><STRONG>I</STRONG>nitiator, the machine that starts the negotiation</DD>
|
|
<DT>R</DT>
|
|
<DD><STRONG>R</STRONG>esponder</DD>
|
|
</DL>
|
|
<P>For example, the six messages of a main mode negotiation, in
|
|
sequence, are labelled:</P>
|
|
<PRE> MI1 ---------->
|
|
<---------- MR1
|
|
MI2 ---------->
|
|
<---------- MR2
|
|
MI3 ---------->
|
|
<---------- MR3</PRE>
|
|
<H4><A name="struct.exchange">Structure of IKE messages</A></H4>
|
|
<P>Here is our Pluto developer explaining some of this on the mailing
|
|
list:</P>
|
|
<PRE>When one IKE system (for example, Pluto) is negotiating with another
|
|
to create an SA, the Initiator proposes a bunch of choices and the
|
|
Responder replies with one that it has selected.
|
|
|
|
The structure of the choices is fairly complicated. An SA payload
|
|
contains a list of lists of "Proposals". The outer list is a set of
|
|
choices: the selection must be from one element of this list.
|
|
|
|
Each of these elements is a list of Proposals. A selection must be
|
|
made from each of the elements of the inner list. In other words,
|
|
*all* of them apply (that is how, for example, both AH and ESP can
|
|
apply at once).
|
|
|
|
Within each of these Proposals is a list of Transforms. For each
|
|
Proposal selected, one Transform must be selected (in other words,
|
|
each Proposal provides a choice of Transforms).
|
|
|
|
Each Transform is made up of a list of Attributes describing, well,
|
|
attributes. Such as lifetime of the SA. Such as algorithm to be
|
|
used. All the Attributes apply to a Transform.
|
|
|
|
You will have noticed a pattern here: layers alternate between being
|
|
disjunctions ("or") and conjunctions ("and").
|
|
|
|
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
|
|
cut back. There must be exactly one Proposal. So this degenerates to
|
|
a list of Transforms, one of which must be chosen.</PRE>
|
|
<H3><A name="services">IPsec Services, AH and ESP</A></H3>
|
|
<P>IPsec offers two services,<A href="#authentication"> authentication</A>
|
|
and<A href="#encryption"> encryption</A>. These can be used separately
|
|
but are often used together.</P>
|
|
<DL>
|
|
<DT>Authentication</DT>
|
|
<DD>Packet-level authentication allows you to be confident that a packet
|
|
came from a particular machine and that its contents were not altered
|
|
en route to you. No attempt is made to conceal or protect the contents,
|
|
only to assure their integrity. Packet authentication can be provided
|
|
separately using an<A href="#AH"> Authentication Header</A>, described
|
|
just below, or it can be included as part of the<A href="#ESP"> ESP</A>
|
|
(Encapsulated Security Payload) service, described in the following
|
|
section. That service offers encryption as well as authentication. In
|
|
either case, the<A href="#HMAC"> HMAC</A> construct is used as the
|
|
authentication mechanism.
|
|
<P>There is a separate authentication operation at the IKE level, in
|
|
which each gateway authenticates the other. This can be done in a
|
|
variety of ways.</P>
|
|
</DD>
|
|
<DT>Encryption</DT>
|
|
<DD>Encryption allows you to conceal the contents of a message from
|
|
eavesdroppers.
|
|
<P>In IPsec this is done using a<A href="#block"> block cipher</A>
|
|
(normally<A href="#3DES"> Triple DES</A> for Linux). In the most used
|
|
setup, keys are automatically negotiated, and periodically
|
|
re-negotiated, using the<A href="#IKE"> IKE</A> (Internet Key Exchange)
|
|
protocol. In Linux FreeS/WAN this is handled by the Pluto Daemon.</P>
|
|
<P>The IPsec protocol offering encryption is<A href="#ESP"> ESP</A>,
|
|
Encapsulated Security Payload. It can also include a packet
|
|
authentication service.</P>
|
|
</DD>
|
|
</DL>
|
|
<P>Note that<STRONG> encryption should always be used with some packet
|
|
authentication service</STRONG>. Unauthenticated encryption is
|
|
vulnerable to<A href="#middle"> man-in-the-middle attacks</A>. Also
|
|
note that encryption does not prevent<A href="#traffic"> traffic
|
|
analysis</A>.</P>
|
|
<H3><A name="AH.ipsec">The Authentication Header (AH)</A></H3>
|
|
<P>Packet authentication can be provided separately from encryption by
|
|
adding an authentication header (AH) after the IP header but before the
|
|
other headers on the packet. This is the subject of this section.
|
|
Details are in RFC 2402.</P>
|
|
<P>Each of the several headers on a packet header contains a "next
|
|
protocol" field telling the system what header to look for next. IP
|
|
headers generally have either TCP or UDP in this field. When IPsec
|
|
authentication is used, the packet IP header has AH in this field,
|
|
saying that an Authentication Header comes next. The AH header then has
|
|
the next header type -- usually TCP, UDP or encapsulated IP.</P>
|
|
<P>IPsec packet authentication can be added in transport mode, as a
|
|
modification of standard IP transport. This is shown in this diagram
|
|
from the RFC:</P>
|
|
<PRE> BEFORE APPLYING AH
|
|
----------------------------
|
|
IPv4 |orig IP hdr | | |
|
|
|(any options)| TCP | Data |
|
|
----------------------------
|
|
|
|
AFTER APPLYING AH
|
|
---------------------------------
|
|
IPv4 |orig IP hdr | | | |
|
|
|(any options)| AH | TCP | Data |
|
|
---------------------------------
|
|
||
|
|
except for mutable fields</PRE>
|
|
<P>Athentication can also be used in tunnel mode, encapsulating the
|
|
underlying IP packet beneath AH and an additional IP header.</P>
|
|
<PRE> ||
|
|
IPv4 | new IP hdr* | | orig IP hdr* | | |
|
|
|(any options)| AH | (any options) |TCP | Data |
|
|
------------------------------------------------
|
|
||
|
|
| in the new IP hdr |</PRE>
|
|
<P>This would normally be used in a gateway-to-gateway tunnel. The
|
|
receiving gateway then strips the outer IP header and the AH header and
|
|
forwards the inner IP packet.</P>
|
|
<P>The mutable fields referred to are things like the time-to-live field
|
|
in the IP header. These cannot be included in authentication
|
|
calculations because they change as the packet travels.</P>
|
|
<H4><A name="keyed">Keyed MD5 and Keyed SHA</A></H4>
|
|
<P>The actual authentication data in the header is typically 96 bits and
|
|
depends both on a secret shared between sender and receiver and on
|
|
every byte of the data being authenticated. The technique used is<A href="#HMAC">
|
|
HMAC</A>, defined in RFC 2104.</P>
|
|
<P>The algorithms involved are the<A href="#MD5"> MD5</A> Message Digest
|
|
Algorithm or<A href="#SHA"> SHA</A>, the Secure Hash Algorithm. For
|
|
details on their use in this application, see RFCs 2403 and 2404
|
|
respectively.</P>
|
|
<P>For descriptions of the algorithms themselves, see RFC 1321 for MD5
|
|
and<A href="#FIPS"> FIPS</A> (Federal Information Processing Standard)
|
|
number 186 from<A href="#NIST"> NIST</A>, the US National Institute of
|
|
Standards and Technology for SHA.<A href="#schneier"><CITE> Applied
|
|
Cryptography</CITE></A> covers both in some detail, MD5 starting on
|
|
page 436 and SHA on 442.</P>
|
|
<P>These algorithms are intended to make it nearly impossible for anyone
|
|
to alter the authenticated data in transit. The sender calculates a
|
|
digest or hash value from that data and includes the result in the
|
|
authentication header. The recipient does the same calculation and
|
|
compares results. For unchanged data, the results will be identical.
|
|
The hash algorithms are designed to make it extremely difficult to
|
|
change the data in any way and still get the correct hash.</P>
|
|
<P>Since the shared secret key is also used in both calculations, an
|
|
interceptor cannot simply alter the authenticated data and change the
|
|
hash value to match. Without the key, he or she (or even the dreaded
|
|
They) cannot produce a usable hash.</P>
|
|
<H4><A name="sequence">Sequence numbers</A></H4>
|
|
<P>The authentication header includes a sequence number field which the
|
|
sender is required to increment for each packet. The receiver can
|
|
ignore it or use it to check that packets are indeed arriving in the
|
|
expected sequence.</P>
|
|
<P>This provides partial protection against<A href="#replay"> replay
|
|
attacks</A> in which an attacker resends intercepted packets in an
|
|
effort to confuse or subvert the receiver. Complete protection is not
|
|
possible since it is necessary to handle legitmate packets which are
|
|
lost, duplicated, or delivered out of order, but use of sequence
|
|
numbers makes the attack much more difficult.</P>
|
|
<P>The RFCs require that sequence numbers never cycle, that a new key
|
|
always be negotiated before the sequence number reaches 2^32-1. This
|
|
protects both against replays attacks using packets from a previous
|
|
cyclce and against<A href="#birthday"> birthday attacks</A> on the the
|
|
packet authentication algorithm.</P>
|
|
<P>In Linux FreeS/WAN, the sequence number is ignored for manually keyed
|
|
connections and checked for automatically keyed ones. In manual mode,
|
|
there is no way to negotiate a new key, or to recover from a sequence
|
|
number problem, so we don't use sequence numbers.</P>
|
|
<H3><A name="ESP.ipsec">Encapsulated Security Payload (ESP)</A></H3>
|
|
<P>The ESP protocol is defined in RFC 2406. It provides one or both of
|
|
encryption and packet authentication. It may be used with or without AH
|
|
packet authentication.</P>
|
|
<P>Note that<STRONG> some form of packet authentication should<EM>
|
|
always</EM> be used whenever data is encrypted</STRONG>. Without
|
|
authentication, the encryption is vulnerable to active attacks which
|
|
may allow an enemy to break the encryption. ESP should<STRONG> always</STRONG>
|
|
either include its own authentication or be used with AH
|
|
authentication.</P>
|
|
<P>The RFCs require support for only two mandatory encryption algorithms
|
|
--<A href="#DES"> DES</A>, and null encryption -- and for two
|
|
authentication methods -- keyed MD5 and keyed SHA. Implementers may
|
|
choose to support additional algorithms in either category.</P>
|
|
<P>The authentication algorithms are the same ones used in the IPsec<A href="#AH">
|
|
authentication header</A>.</P>
|
|
<P>We do not implement single DES since<A href="#desnotsecure"> DES is
|
|
insecure</A>. Instead we provide<A href="#3DES"> triple DES or 3DES</A>
|
|
. This is currently the only encryption algorithm supported.</P>
|
|
<P>We do not implement null encryption since it is obviously insecure.</P>
|
|
<H2><A name="modes">IPsec modes</A></H2>
|
|
<P>IPsec can connect in two modes. Transport mode is a host-to-host
|
|
connection involving only two machines. In tunnel mode, the IPsec
|
|
machines act as gateways and trafiic for any number of client machines
|
|
may be carried.</P>
|
|
<H3><A name="tunnel.ipsec">Tunnel mode</A></H3>
|
|
<P>Security gateways are required to support tunnel mode connections. In
|
|
this mode the gateways provide tunnels for use by client machines
|
|
behind the gateways. The client machines need not do any IPsec
|
|
processing; all they have to do is route things to gateways.</P>
|
|
<H3><A name="transport.ipsec">Transport mode</A></H3>
|
|
<P>Host machines (as opposed to security gateways) with IPsec
|
|
implementations must also support transport mode. In this mode, the
|
|
host does its own IPsec processing and routes some packets via IPsec.</P>
|
|
<H2><A name="parts">FreeS/WAN parts</A></H2>
|
|
<H3><A name="KLIPS.ipsec">KLIPS: Kernel IPsec Support</A></H3>
|
|
<P>KLIPS is<STRONG> K</STRONG>erne<STRONG>L</STRONG><STRONG> IP</STRONG>
|
|
SEC<STRONG> S</STRONG>upport, the modifications necessary to support
|
|
IPsec within the Linux kernel. KILPS does all the actual IPsec
|
|
packet-handling, including</P>
|
|
<UL>
|
|
<LI>encryption</LI>
|
|
<LI>packet authentication calculations</LI>
|
|
<LI>creation of ESP and AH headers for outgoing packets</LI>
|
|
<LI>interpretation of those headers on incoming packets</LI>
|
|
</UL>
|
|
<P>KLIPS also checks all non-IPsec packets to ensure they are not
|
|
bypassing IPsec security policies.</P>
|
|
<H3><A name="Pluto.ipsec">The Pluto daemon</A></H3>
|
|
<P><A href="manpage.d/ipsec_pluto.8.html">Pluto(8)</A> is a daemon which
|
|
implements the IKE protocol. It</P>
|
|
<UL>
|
|
<LI>handles all the Phase one ISAKMP SAs</LI>
|
|
<LI>performs host authentication and negotiates with other gateways</LI>
|
|
<LI>creates IPsec SAs and passes the data required to run them to KLIPS</LI>
|
|
<LI>adjust routing and firewall setup to meet IPsec requirements. See
|
|
our<A href="firewall.html"> IPsec and firewalling</A> document for
|
|
details.</LI>
|
|
</UL>
|
|
<P>Pluto is controlled mainly by the<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> configuration file.</P>
|
|
<H3><A name="command">The ipsec(8) command</A></H3>
|
|
<P>The<A href="manpage.d/ipsec.8.html"> ipsec(8)</A> command is a front
|
|
end shellscript that allows control over IPsec activity.</P>
|
|
<H3><A name="ipsec.conf">Linux FreeS/WAN configuration file</A></H3>
|
|
<P>The configuration file for Linux FreeS/WAN is</P>
|
|
<PRE> /etc/ipsec.conf</PRE>
|
|
<P>For details see the<A href="manpage.d/ipsec.conf.5.html">
|
|
ipsec.conf(5)</A> manual page .</P>
|
|
<H2><A name="key">Key management</A></H2>
|
|
<P>There are several ways IPsec can manage keys. Not all are implemented
|
|
in Linux FreeS/WAN.</P>
|
|
<H3><A name="current">Currently Implemented Methods</A></H3>
|
|
<H4><A name="manual">Manual keying</A></H4>
|
|
<P>IPsec allows keys to be manually set. In Linux FreeS/WAN, such keys
|
|
are stored with the connection definitions in /etc/ipsec.conf.</P>
|
|
<P><A href="#manual">Manual keying</A> is useful for debugging since it
|
|
allows you to test the<A href="#KLIPS"> KLIPS</A> kernel IPsec code
|
|
without the<A href="#Pluto"> Pluto</A> daemon doing key negotiation.</P>
|
|
<P>In general, however, automatic keying is preferred because it is more
|
|
secure.</P>
|
|
<H4><A name="auto">Automatic keying</A></H4>
|
|
<P>In automatic keying, the<A href="#Pluto"> Pluto</A> daemon negotiates
|
|
keys using the<A href="#IKE"> IKE</A> Internet Key Exchange protocol.
|
|
Connections are automatically re-keyed periodically.</P>
|
|
<P>This is considerably more secure than manual keying. In either case
|
|
an attacker who acquires a key can read every message encrypted with
|
|
that key, but automatic keys can be changed every few hours or even
|
|
every few minutes without breaking the connection or requiring
|
|
intervention by the system administrators. Manual keys can only be
|
|
changed manually; you need to shut down the connection and have the two
|
|
admins make changes. Moreover, they have to communicate the new keys
|
|
securely, perhaps with<A href="#PGP"> PGP</A> or<A href="#ssh"> SSH</A>
|
|
. This may be possible in some cases, but as a general solution it is
|
|
expensive, bothersome and unreliable. Far better to let<A href="#Pluto">
|
|
Pluto</A> handle these chores; no doubt the administrators have enough
|
|
to do.</P>
|
|
<P>Also, automatic keying is inherently more secure against an attacker
|
|
who manages to subvert your gateway system. If manual keying is in use
|
|
and an adversary acquires root privilege on your gateway, he reads your
|
|
keys from /etc/ipsec.conf and then reads all messages encrypted with
|
|
those keys.</P>
|
|
<P>If automatic keying is used, an adversary with the same privileges
|
|
can read /etc/ipsec.secrets, but this does not contain any keys, only
|
|
the secrets used to authenticate key exchanges. Having an adversary
|
|
able to authenticate your key exchanges need not worry you overmuch.
|
|
Just having the secrets does not give him any keys. You are still
|
|
secure against<A href="#passive"> passive</A> attacks. This property of
|
|
automatic keying is called<A href="#PFS"> perfect forward secrecy</A>,
|
|
abbreviated PFS.</P>
|
|
<P>Unfortunately, having the secrets does allow an<A href="#active">
|
|
active attack</A>, specifically a<A href="#middle"> man-in-the-middle</A>
|
|
attack. Losing these secrets to an attacker may not be quite as
|
|
disastrous as losing the actual keys, but it is<EM> still a serious
|
|
security breach</EM>. These secrets should be guarded as carefully as
|
|
keys.</P>
|
|
<H3><A name="notyet">Methods not yet implemented</A></H3>
|
|
<H4><A name="noauth">Unauthenticated key exchange</A></H4>
|
|
<P>It would be possible to exchange keys without authenticating the
|
|
players. This would support<A href="#carpediem"> opportunistic
|
|
encryption</A> -- allowing any two systems to encrypt their
|
|
communications without requiring a shared PKI or a previously
|
|
negotiated secret -- and would be secure against<A href="#passive">
|
|
passive attacks</A>. It would, however, be highly vulnerable to active<A
|
|
href="#middle"> man-in-the-middle</A> attacks. RFC 2408 therefore
|
|
specifies that all<A href="#ISAKMP"> ISAKMP</A> key management
|
|
interactions<EM> must</EM> be authenticated.</P>
|
|
<P>There is room for debate here. Should we provide immediate security
|
|
against<A href="#passive"> passive attacks</A> and encourage widespread
|
|
use of encryption, at the expense of risking the more difficult<A href="#active">
|
|
active attacks</A>? Or should we wait until we can implement a solution
|
|
that can both be widespread and offer security against active attacks?</P>
|
|
<P>So far, we have chosen the second course, complying with the RFCs and
|
|
waiting for secure DNS (see<A href="#DNS"> below</A>) so that we can do<A
|
|
href="#carpediem"> opportunistic encryption</A> right.</P>
|
|
<H4><A name="DNS">Key exchange using DNS</A></H4>
|
|
<P>The IPsec RFCs allow key exchange based on authentication services
|
|
provided by<A href="#SDNS"> Secure DNS</A>. Once Secure DNS service
|
|
becomes widely available, we expect to make this the<EM> primary key
|
|
management method for Linux FreeS/WAN</EM>. It is the best way we know
|
|
of to support<A href="#carpediem"> opportunistic encryption</A>,
|
|
allowing two systems without a common PKI or previous negotiation to
|
|
secure their communication.</P>
|
|
<P>We currently have code to acquire RSA keys from DNS but do not yet
|
|
have code to validate Secure DNS signatures.</P>
|
|
<H4><A name="PKI">Key exchange using a PKI</A></H4>
|
|
<P>The IPsec RFCs allow key exchange based on authentication services
|
|
provided by a<A href="#PKI"> PKI</A> or Public Key Infrastructure. With
|
|
many vendors selling such products and many large organisations
|
|
building these infrastructures, this will clearly be an important
|
|
application of IPsec and one Linux FreeS/WAN will eventually support.</P>
|
|
<P>On the other hand, this is not as high a priority for Linux FreeS/WAN
|
|
as solutions based on<A href="#SDNS"> secure DNS</A>. We do not expect
|
|
any PKI to become as universal as DNS.</P>
|
|
<P>Some<A href="#patch"> patches</A> to handle authentication with X.509
|
|
certificates, which most PKIs use, are available.</P>
|
|
<H4><A name="photuris">Photuris</A></H4>
|
|
<P><A href="#photuris">Photuris</A> is another key management protocol,
|
|
an alternative to IKE and ISAKMP, described in RFCs 2522 and 2523 which
|
|
are labelled "experimental". Adding Photuris support to Linux FreeS/WAN
|
|
might be a good project for a volunteer. The likely starting point
|
|
would be the OpenBSD photurisd code.</P>
|
|
<H4><A name="skip">SKIP</A></H4>
|
|
<P><A href="#SKIP">SKIP</A> is yet another key management protocol,
|
|
developed by Sun. At one point it was fairly widely used, but it now
|
|
seems moribund, displaced by IKE. Sun now (as of Solaris 8.0) ship an
|
|
IPsec implementation using IKE. We have no plans to implement SKIP. If
|
|
a user were to implement it, we would almost certainly not want to add
|
|
the code to our distribution.</P>
|
|
<HR>
|
|
<H1><A name="lists">Mailing lists and newsgroups</A></H1>
|
|
<H2><A name="list.fs">Mailing lists about FreeS/WAN</A></H2>
|
|
<H3><A name="projlist">The project mailing lists</A></H3>
|
|
<P>The Linux FreeS/WAN project has several email lists for user support,
|
|
bug reports and software development discussions.</P>
|
|
<P>We had a single list on clinet.fi for several years (Thanks, folks!),
|
|
then one list on freeswan.org, but now we've split into several lists:</P>
|
|
<DL>
|
|
<DT><A href="mailto:[email protected]?body=subscribe">
|
|
users</A></DT>
|
|
<DD>
|
|
<UL>
|
|
<LI>The general list for discussing use of the software</LI>
|
|
<LI>The place for seeking<STRONG> help with problems</STRONG> (but
|
|
please check the<A href="faq.html"> FAQ</A> first).</LI>
|
|
<LI>Anyone can post.</LI>
|
|
</UL>
|
|
</DD>
|
|
<DT><A href="mailto:[email protected]?body=subscribe">bugs</A>
|
|
</DT>
|
|
<DD>
|
|
<UL>
|
|
<LI>For<STRONG> bug reports</STRONG>.</LI>
|
|
<LI>If you are not certain what is going on -- could be a bug, a
|
|
configuration error, a network problem, ... -- please post to the users
|
|
list instead.</LI>
|
|
<LI>Anyone can post.</LI>
|
|
</UL>
|
|
</DD>
|
|
<DT><A href="mailto:[email protected]?body=subscribe">
|
|
design</A></DT>
|
|
<DD>
|
|
<UL>
|
|
<LI><STRONG>Design discussions</STRONG>, for people working on FreeS/WAN
|
|
development or others with an interest in design and security issues.</LI>
|
|
<LI>It would be a good idea to read the existing design papers (see this<A
|
|
href="#applied"> list</A>) before posting.</LI>
|
|
<LI>Anyone can post.</LI>
|
|
</UL>
|
|
</DD>
|
|
<DT><A href="mailto:[email protected]?body=subscribe">
|
|
announce</A></DT>
|
|
<DD>
|
|
<UL>
|
|
<LI>A<STRONG> low-traffic</STRONG> list.</LI>
|
|
<LI><STRONG>Announcements</STRONG> about FreeS/WAN and related software.</LI>
|
|
<LI>All posts here are also sent to the users list. You need not
|
|
subscribe to both.</LI>
|
|
<LI>Only the FreeS/WAN team can post.</LI>
|
|
<LI>If you have something you feel should go on this list, send it to<VAR>
|
|
[email protected]</VAR>. Unless it is obvious, please
|
|
include a short note explaining why we should post it.</LI>
|
|
</UL>
|
|
</DD>
|
|
<DT><A href="mailto:[email protected]?body=subscribe">
|
|
briefs</A></DT>
|
|
<DD>
|
|
<UL>
|
|
<LI>A<STRONG> low-traffic</STRONG> list.</LI>
|
|
<LI><STRONG>Weekly summaries</STRONG> of activity on the users list.</LI>
|
|
<LI>All posts here are also sent to the users list. You need not
|
|
subscribe to both.</LI>
|
|
<LI>Only the FreeS/WAN team can post.</LI>
|
|
</UL>
|
|
</DD>
|
|
</DL>
|
|
<P>To subscribe to any of these, you can:</P>
|
|
<UL>
|
|
<LI>just follow the links above</LI>
|
|
<LI>use our<A href="http://www.freeswan.org/mail.html"> web interface</A>
|
|
</LI>
|
|
<LI>send mail to<VAR> listname</VAR>[email protected] with a
|
|
one-line message body "subscribe"</LI>
|
|
</UL>
|
|
<P>Archives of these lists are available via the<A href="http://www.freeswan.org/mail.html">
|
|
web interface</A>.</P>
|
|
<H4><A name="which.list">Which list should I use?</A></H4>
|
|
<P>For most questions, please check the<A href="faq.html"> FAQ</A>
|
|
first, and if that does not have an answer, ask on the users list. "My
|
|
configuration doesn't work." does not belong on the bugs list, and "Can
|
|
FreeS/WAN do such-and-such" or "How do I configure it to..." do not
|
|
belong in design discussions.</P>
|
|
<P>Cross-posting the same message to two or more of these lists is
|
|
discouraged. Quite a few people read more than one list and getting
|
|
multiple copies is annoying.</P>
|
|
<H4><A name="policy.list">List policies</A></H4>
|
|
<P><STRONG>US citizens or residents are asked not to post code to the
|
|
lists, not even one-line bug fixes</STRONG>. The project cannot accept
|
|
code which might entangle it in US<A href="#exlaw"> export restrictions</A>
|
|
.</P>
|
|
<P>Non-subscribers can post to some of these lists. This is necessary;
|
|
someone working on a gateway install who encounters a problem may not
|
|
have access to a subscribed account.</P>
|
|
<P>Some spam turns up on these lists from time to time. For discussion
|
|
of why we do not attempt to filter it, see the<A href="#spam"> FAQ</A>.
|
|
Please do not clutter the lists with complaints about this.</P>
|
|
<H3><A name="archive">Archives of the lists</A></H3>
|
|
<P>Searchable archives of the old single list have existed for some
|
|
time. At time of writing, it is not yet clear how they will change for
|
|
the new multi-list structure.</P>
|
|
<UL>
|
|
<LI><A href="http://www.sandelman.ottawa.on.ca/linux-ipsec">Canada</A></LI>
|
|
<LI><A href="http://www.nexial.com">Holland</A></LI>
|
|
</UL>
|
|
<P>Note that these use different search engines. Try both.</P>
|
|
<P>Archives of the new lists are available via the<A href="http://www.freeswan.org/mail.html">
|
|
web interface</A>.</P>
|
|
<H2><A name="indexes">Indexes of mailing lists</A></H2>
|
|
<P><A href="http://paml.net/">PAML</A> is the standard reference for<STRONG>
|
|
P</STRONG>ublicly<STRONG> A</STRONG>ccessible<STRONG> M</STRONG>ailing<STRONG>
|
|
L</STRONG>ists. When we last checked, it had over 7500 lists on an
|
|
amazing variety of topics. It also has FAQ information and a search
|
|
engine.</P>
|
|
<P>There is an index of<A href="http://oslab.snu.ac.kr/~djshin/linux/mail-list/index.shtml">
|
|
Linux mailing lists</A> available.</P>
|
|
<P>A list of<A href="http://xforce.iss.net/maillists/otherlists.php">
|
|
computer security mailing lists</A>, with descriptions.</P>
|
|
<H2><A name="otherlists">Lists for related software and topics</A></H2>
|
|
<P>Most links in this section point to subscription addresses for the
|
|
various lists. Send the one-line message "subscribe<VAR> list_name</VAR>
|
|
" to subscribe to any of them.</P>
|
|
<H3><A NAME="28_3_1">Products that include FreeS/WAN</A></H3>
|
|
<P>Our introduction document gives a<A href="#products"> list of
|
|
products that include FreeS/WAN</A>. If you have, or are considering,
|
|
one of those, check the supplier's web site for information on mailing
|
|
lists for their users.</P>
|
|
<H3><A name="linux.lists">Linux mailing lists</A></H3>
|
|
<UL>
|
|
<LI><A href="mailto:[email protected]">
|
|
[email protected]</A>, for Linux system administrators</LI>
|
|
<LI><A href="mailto:[email protected]">
|
|
[email protected]</A>, about Netfilter, which replaces IPchains
|
|
in kernels 2.3.15 and later</LI>
|
|
<LI><A href="mailto:[email protected]">
|
|
[email protected]</A>, for people working on security
|
|
audits of various Linux programs</LI>
|
|
<LI><A href="mailto:[email protected]">
|
|
[email protected]</A>, for discussion of issues common to
|
|
all the half dozen projects working on secure Linux distributions.</LI>
|
|
</UL>
|
|
<P>Each of the scure distribution projects also has its own web site and
|
|
mailing list. Some of the sites are:</P>
|
|
<UL>
|
|
<LI><A href="http://bastille-linux.org/">Bastille Linux</A> scripts to
|
|
harden Redhat, e.g. by changing permissions and modifying inialisation
|
|
scripts</LI>
|
|
<LI><A href="http://immunix.org/">Immunix</A> take a different approach,
|
|
using a modified compiler to build kernel and utilities with better
|
|
resistance to various types of overflow and exploit</LI>
|
|
<LI>the<A href="#NSA"> NSA</A> have contractors working on a<A href="#SElinux">
|
|
Security Enhanced Linux</A>, primarily adding stronger access control
|
|
mechanisms. You can download the current version (which interestingly
|
|
is under GPL and not export resrtricted) or subscribe to the mailing
|
|
list from the<A href="http://www.nsa.gov/selinux"> project web page</A>
|
|
.</LI>
|
|
</UL>
|
|
<H3><A name="ietf">Lists for IETF working groups</A></H3>
|
|
<P>Each<A href="#ietf"> IETF</A> working group has an associated mailing
|
|
list where much of the work takes place.</P>
|
|
<UL>
|
|
<LI><A href="mailto:[email protected]">[email protected]</A>
|
|
, the IPsec<A href="http://www.ietf.org/html.charters/ipsec-charter.html">
|
|
working group</A>. This is where the protocols are discussed, new
|
|
drafts announced, and so on. By now, the IPsec working group is winding
|
|
down since the work is essentially complete. A<A href="http://www.sandelman.ottawa.on.ca/ipsec/">
|
|
list archive</A> is available.</LI>
|
|
<LI><A href="mailto:[email protected]">IPsec policy</A>
|
|
list, and its<A href="http://www.vpnc.org/ipsec-policy/"> archive</A></LI>
|
|
<LI><A href="mailto:[email protected]">IP secure remote access</A>
|
|
list, and its<A href="http://www.vpnc.org/ietf-ipsra/mail-archive/">
|
|
archive</A></LI>
|
|
</UL>
|
|
<H3><A name="other">Other mailing lists</A></H3>
|
|
<UL>
|
|
<LI><A href="mailto:[email protected]">
|
|
[email protected]</A> a low-traffic list with announcements of
|
|
developments in privacy, encryption and online civil rights</LI>
|
|
<LI>a VPN mailing list's<A href="http://kubarb.phsx.ukans.edu/~tbird/vpn.html">
|
|
home page</A></LI>
|
|
</UL>
|
|
<H2><A name="newsgroups">Usenet newsgroups</A></H2>
|
|
<UL>
|
|
<LI>sci.crypt</LI>
|
|
<LI>sci.crypt.research</LI>
|
|
<LI>comp.dcom.vpn</LI>
|
|
<LI>talk.politics.crypto</LI>
|
|
</UL>
|
|
<HR>
|
|
<H1><A name="weblink">Web links</A></H1>
|
|
<H2><A name="freeswan">The Linux FreeS/WAN Project</A></H2>
|
|
<P>The main project web site is<A href="http://www.freeswan.org/">
|
|
www.freeswan.org</A>.</P>
|
|
<P>Links to other project-related<A href="#sites"> sites</A> are
|
|
provided in our introduction section.</P>
|
|
<H3><A name="patch">Add-ons and patches for FreeS/WAN</A></H3>
|
|
<P>Some user-contributed patches have been integrated into the FreeS/WAN
|
|
distribution. For a variety of reasons, those listed below have not.</P>
|
|
<P>Note that not all patches are a good idea.</P>
|
|
<UL>
|
|
<LI>There are a number of "features" of IPsec which we do not implement
|
|
because they reduce security. See this<A href="#dropped"> discussion</A>
|
|
. We do not recommend using patches that implement these. One example is
|
|
aggressive mode.</LI>
|
|
<LI>We do not recommend adding "features" of any sort unless they are
|
|
clearly necessary, or at least have clear benefits. For example,
|
|
FreeS/WAN would not become more secure if it offerred a choice of 14
|
|
ciphers. If even one was flawed, it would certainly become less secure
|
|
for anyone using that cipher. Even with 14 wonderful ciphers, it would
|
|
be harder to maintain and administer, hence more vulnerable to various
|
|
human errors.</LI>
|
|
</UL>
|
|
<P>This is not to say that patches are necessarily bad, only that using
|
|
them requires some deliberation. For example, there might be perfectly
|
|
good reasons to add a specific cipher in your application: perhaps GOST
|
|
to comply with government standards in Eastern Europe, or AES for
|
|
performance benefits.</P>
|
|
<H4><A NAME="29_1_1_1">Current patches</A></H4>
|
|
<P>Patches believed current::</P>
|
|
<UL>
|
|
<LI>patches for<A href="http://www.strongsec.com/freeswan/"> X.509
|
|
certificate support</A>, also available from a<A href="http://www.twi.ch/~sna/strongsec/freeswan/">
|
|
mirror site</A></LI>
|
|
<LI>patches to add<A href="http://www.irrigacion.gov.ar/juanjo/ipsec">
|
|
AES and other ciphers</A>. There is preliminary data indicating AES
|
|
gives a substantial<A href="#perf.more"> performance gain</A>.</LI>
|
|
</UL>
|
|
<P>There is also one add-on that takes the form of a modified FreeS/WAN
|
|
distribution, rather than just patches to the standard distribution:</P>
|
|
<UL>
|
|
<LI><A href="http://www.ipv6.iabg.de/downloadframe/index.html">IPv6
|
|
support</A></LI>
|
|
</UL>
|
|
<P>Before using any of the above,, check the<A href="mail.html"> mailing
|
|
lists</A> for news of newer versions and to see whether they have been
|
|
incorporated into more recent versions of FreeS/WAN.</P>
|
|
<H4><A NAME="29_1_1_2">Older patches</A></H4>
|
|
<UL>
|
|
<LI><A href="http://sources.colubris.com/en/projects/FreeSWAN/">hardware
|
|
acceleration</A></LI>
|
|
<LI>a<A href="http://tzukanov.narod.ru/"> series</A> of patches that
|
|
<UL>
|
|
<LI>provide GOST, a Russian gov't. standard cipher, in MMX assembler</LI>
|
|
<LI>add GOST to OpenSSL</LI>
|
|
<LI>add GOST to the International kernel patch</LI>
|
|
<LI>let FreeS/WAN use International kernel patch ciphers</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Neil Dunbar's patches for<A href="ftp://hplose.hpl.hp.com/pub/nd/pluto-openssl.tar.gz">
|
|
certificate support</A>, using code from<A href="http://www.openssl.org">
|
|
Open SSL</A>.</LI>
|
|
<LI>Luc Lanthier's<A href="ftp://ftp.netwinder.org/users/f/firesoul/">
|
|
patches</A> for<A href="#PKIX"> PKIX</A> support.</LI>
|
|
<LI><A href="ftp://ftp.heise.de/pub/ct/listings/9916-180.tgz">patches</A>
|
|
to add<A href="#Blowfish"> Blowfish</A>,<A href="#IDEA"> IDEA</A> and<A href="#CAST128">
|
|
CAST-128</A> to FreeS/WAN</LI>
|
|
<LI>patches for FreeS/WAN 1.3, Pluto support for<A href="http://alcatraz.webcriminals.com/~bastiaan/ipsec/">
|
|
external authentication</A>, for example with a smartcard or SKEYID.</LI>
|
|
<LI><A href="http://www.zengl.net/freeswan/download/">patches and
|
|
utilities</A> for using FreeS/WAN with PGPnet</LI>
|
|
<LI><A href="http://www.freelith.com/lithworks/crypto/freeswan_patch.htm">
|
|
Blowfish encryption and Tiger hash</A></LI>
|
|
<LI><A href="http://www.cendio.se/~bellman/aggressive-pluto.snap.tar.gz">
|
|
patches</A> for aggressive mode support</LI>
|
|
</UL>
|
|
<P>These patches are for older versions of FreeS/WAN and will likely not
|
|
work with the current version. Older versions of FreeS/WAN may be
|
|
available on some of the<A href="#sites"> distribution sites</A>, but
|
|
we recommend using the current release.</P>
|
|
<H4><A name="VPN.masq">VPN masquerade patches</A></H4>
|
|
<P>Finally, there are some patches to other code that may be useful with
|
|
FreeS/WAN:</P>
|
|
<UL>
|
|
<LI>a<A href="ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html">
|
|
patch</A> to make IPsec, PPTP and SSH VPNs work through a Linux
|
|
firewall with<A href="#masq"> IP masquerade</A>.</LI>
|
|
<LI><A href="http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO.html">
|
|
Linux VPN Masquerade HOWTO</A></LI>
|
|
</UL>
|
|
<P>Note that this is not required if the same machine does IPsec and
|
|
masquerading, only if you want a to locate your IPsec gateway on a
|
|
masqueraded network. See our<A href="#NAT"> firewalls</A> document for
|
|
discussion of why this is problematic.</P>
|
|
<P>At last report, this patch could not co-exist with FreeS/WAN on the
|
|
same machine.</P>
|
|
<H3><A name="dist">Distributions including FreeS/WAN</A></H3>
|
|
<P>The introductory section of our document set lists several<A href="#distwith">
|
|
Linux distributions</A> which include FreeS/WAN.</P>
|
|
<H3><A name="used">Things FreeS/WAN uses or could use</A></H3>
|
|
<UL>
|
|
<LI><A href="http://openpgp.net/random">/dev/random</A> support page,
|
|
discussion of and code for the Linux<A href="#random"> random number
|
|
driver</A>. Out-of-date when we last checked (January 2000), but still
|
|
useful.</LI>
|
|
<LI>other programs related to random numbers:
|
|
<UL>
|
|
<LI><A href="http://www.mindrot.org/audio-entropyd.html">audio entropy
|
|
daemon</A> to gather noise from a sound card and feed it into
|
|
/dev/random</LI>
|
|
<LI>an<A href="http://www.lothar.com/tech/crypto/"> entropy-gathering
|
|
daemon</A></LI>
|
|
<LI>a driver for the random number generator in recent<A href="http://sourceforge.net/projects/gkernel/">
|
|
Intel chipsets</A>. This driver is included as standard in 2.4 kernels.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>a Linux<A href="http://www.marko.net/l2tp/"> L2TP Daemon</A> which
|
|
might be useful for communicating with Windows 2000 which builds L2TP
|
|
tunnels over its IPsec connections</LI>
|
|
<LI>to use opportunistic encryption, you need a recent version of<A href="#BIND">
|
|
BIND</A>. You can get one from the<A href="http://www.isc.org">
|
|
Internet Software Consortium</A> who maintain BIND.</LI>
|
|
</UL>
|
|
<H3><A name="alternatives">Other approaches to VPNs for Linux</A></H3>
|
|
<UL>
|
|
<LI>other Linux<A href="#linuxipsec"> IPsec implementations</A></LI>
|
|
<LI><A href="http://www.tik.ee.ethz.ch/~skip/">ENskip</A>, a free
|
|
implementation of Sun's<A href="#SKIP"> SKIP</A> protocol</LI>
|
|
<LI><A href="http://sunsite.auc.dk/vpnd/">vpnd</A>, a non-IPsec VPN
|
|
daemon for Linux which creates tunnels using<A href="#Blowfish">
|
|
Blowfish</A> encryption</LI>
|
|
<LI><A href="http://www.winton.org.uk/zebedee/">Zebedee</A>, a simple
|
|
GPLd tunnel-building program with Linux and Win32 versions. The name is
|
|
from<STRONG> Z</STRONG>lib compression,<STRONG> B</STRONG>lowfish
|
|
encryption and<STRONG> D</STRONG>iffie-Hellman key exchange.</LI>
|
|
<LI>There are at least two PPTP implementations for Linux
|
|
<UL>
|
|
<LI>Moreton Bay's<A href="http://www.moretonbay.com/vpn/pptp.html">
|
|
PoPToP</A></LI>
|
|
<LI><A href="http://cag.lcs.mit.edu/~cananian/Projects/PPTP/">PPTP-Linux</A>
|
|
</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="http://sites.inka.de/sites/bigred/devel/cipe.html">CIPE</A>
|
|
(crypto IP encapsulation) project, using their own lightweight protocol
|
|
to encrypt between routers</LI>
|
|
<LI><A href="http://tinc.nl.linux.org/">tinc</A>, a VPN Daemon</LI>
|
|
</UL>
|
|
<P>There is a list of<A href="http://www.securityportal.com/lskb/10000000/kben10000005.html">
|
|
Linux VPN</A> software in the<A href="http://www.securityportal.com/lskb/kben00000001.html">
|
|
Linux Security Knowledge Base</A>.</P>
|
|
<H2><A name="ipsec.link">The IPsec Protocols</A></H2>
|
|
<H3><A name="general">General IPsec or VPN information</A></H3>
|
|
<UL>
|
|
<LI>The<A href="http://www.vpnc.org"> VPN Consortium</A> is a group for
|
|
vendors of IPsec products. Among other things, they have a good
|
|
collection of<A href="http://www.vpnc.org/white-papers.html"> IPsec
|
|
white papers</A>.</LI>
|
|
<LI>A VPN mailing list with a<A href="http://kubarb.phsx.ukans.edu/~tbird/vpn.html">
|
|
home page</A>, a FAQ, some product comparisons, and many links.</LI>
|
|
<LI><A href="http://www.opus1.com/vpn/index.html">VPN pointer page</A></LI>
|
|
<LI>a<A href="http://www.epm.ornl.gov/~dunigan/vpn.html"> collection</A>
|
|
of VPN links, and some explanation</LI>
|
|
</UL>
|
|
<H3><A name="overview">IPsec overview documents or slide sets</A></H3>
|
|
<UL>
|
|
<LI>the FreeS/WAN<A href="ipsec.html"> document section</A> on these
|
|
protocols</LI>
|
|
</UL>
|
|
<H3><A name="otherlang">IPsec information in languages other than
|
|
English</A></H3>
|
|
<UL>
|
|
<LI><A href="http://www.imib.med.tu-dresden.de/imib/Internet/Literatur/ipsec-docu.html">
|
|
German</A></LI>
|
|
<LI><A href="http://www.kame.net/index-j.html">Japanese</A></LI>
|
|
<LI>Feczak Szabolcs' thesis in<A href="http://feczo.koli.kando.hu/vpn/">
|
|
Hungarian</A></LI>
|
|
<LI>Davide Cerri's thesis and some presentation slides<A href="http://www.linux.it/~davide/doc/">
|
|
Italian</A></LI>
|
|
</UL>
|
|
<H3><A name="RFCs1">RFCs and other reference documents</A></H3>
|
|
<UL>
|
|
<LI><A href="rfc.html">Our document</A> listing the RFCs relevant to
|
|
Linux FreeS/WAN and giving various ways of obtaining both RFCs and
|
|
Internet Drafts.</LI>
|
|
<LI><A href="http://www.vpnc.org/vpn-standards.html">VPN Standards</A>
|
|
page maintained by<A href="#VPNC"> VPNC</A>. This covers both RFCs and
|
|
Drafts, and classifies them in a fairly helpful way.</LI>
|
|
<LI><A href="http://www.rfc-editor.org">RFC archive</A></LI>
|
|
<LI><A href="http://www.ietf.org/ids.by.wg/ipsec.html">Internet Drafts</A>
|
|
related to IPsec</LI>
|
|
<LI>US government<A href="http://www.itl.nist.gov/div897/pubs"> site</A>
|
|
with their<A href="#FIPS"> FIPS</A> standards</LI>
|
|
<LI>Archives of the [email protected] mailing list where discussion of
|
|
drafts takes place.
|
|
<UL>
|
|
<LI><A href="http://www.sandelman.ottawa.on.ca/ipsec">Eastern Canada</A></LI>
|
|
<LI><A href="http://www.vpnc.org/ietf-ipsec">California</A>.</LI>
|
|
</UL>
|
|
</LI>
|
|
</UL>
|
|
<H3><A name="analysis">Analysis and critiques of IPsec protocols</A></H3>
|
|
<UL>
|
|
<LI>Counterpane's<A href="http://www.counterpane.com/ipsec.pdf">
|
|
evaluation</A> of the protocols</LI>
|
|
<LI>Simpson's<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00319.html">
|
|
IKE Considered Dangerous</A> paper. Note that this is a link to an
|
|
archive of our mailing list. There are several replies in addition to
|
|
the paper itself.</LI>
|
|
<LI>Fate Labs<A href="http://www.fatelabs.com/loki-vpn.pdf"> Virual
|
|
Private Problems: the Broken Dream</A></LI>
|
|
<LI>Catherine Meadows' paper<CITE> Analysis of the Internet Key Exchange
|
|
Protocol Using the NRL Protocol Analyzer</CITE>, in<A href="http://chacs.nrl.navy.mil/publications/CHACS/1999/1999meadows-IEEE99.pdf">
|
|
PDF</A> or<A href="http://chacs.nrl.navy.mil/publications/CHACS/1999/1999meadows-IEEE99.ps">
|
|
Postscript</A>.</LI>
|
|
<LI>Perlman and Kaufmnan
|
|
<UL>
|
|
<LI><A href="http://snoopy.seas.smu.edu/ee8392_summer01/week7/perlman2.pdf">
|
|
Key Exchange in IPsec</A></LI>
|
|
<LI>a newer<A href="http://sec.femto.org/wetice-2001/papers/radia-paper.pdf">
|
|
PDF paper</A>,<CITE> Analysis of the IPsec Key Exchange Standard</CITE>
|
|
.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Bellovin's<A href="http://www.research.att.com/~smb/papers/index.html">
|
|
papers</A> page including his:
|
|
<UL>
|
|
<LI><CITE>Security Problems in the TCP/IP Protocol Suite</CITE> (1989)</LI>
|
|
<LI><CITE>Problem Areas for the IP Security Protocols</CITE> (1996)</LI>
|
|
<LI><CITE>Probable Plaintext Cryptanalysis of the IP Security Protocols</CITE>
|
|
(1997)</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>An<A href="http://www.lounge.org/ike_doi_errata.html"> errata list</A>
|
|
for the IPsec RFCs.</LI>
|
|
</UL>
|
|
<H3><A name="IP.background">Background information on IP</A></H3>
|
|
<UL>
|
|
<LI>An<A href="http://ipprimer.windsorcs.com/"> IP tutorial</A> that
|
|
seems to be written mainly for Netware or Microsoft LAN admins entering
|
|
a new world</LI>
|
|
<LI><A href="http://www.iana.org">IANA</A>, Internet Assigned Numbers
|
|
Authority</LI>
|
|
<LI><A href="http://public.pacbell.net/dedicated/cidr.html">CIDR</A>,
|
|
Classless Inter-Domain Routing</LI>
|
|
<LI>Also see our<A href="biblio.html"> bibliography</A></LI>
|
|
</UL>
|
|
<H2><A name="implement">IPsec Implementations</A></H2>
|
|
<H3><A name="linuxprod">Linux products</A></H3>
|
|
<P>Vendors using FreeS/WAN in turnkey firewall or VPN products are
|
|
listed in our<A href="#turnkey"> introduction</A>.</P>
|
|
<P>Other vendors have Linux IPsec products which, as far as we know, do
|
|
not use FreeS/WAN</P>
|
|
<UL>
|
|
<LI><A href="http://www.redcreek.com/products/shareware.html">Redcreek</A>
|
|
provide an open source Linux driver for their PCI hardware VPN card.
|
|
This card has a 100 Mbit Ethernet port, an Intel 960 CPU plus more
|
|
specialised crypto chips, and claimed encryption performance of 45
|
|
Mbit/sec. The PC sees it as an Ethernet board.</LI>
|
|
<LI><A href="http://linuxtoday.com/stories/8428.html?nn">Paktronix</A>
|
|
offer a Linux-based VPN with hardware encryption</LI>
|
|
<LI><A href="http://www.watchguard.com/">Watchguard</A> use Linux in
|
|
their Firebox product.</LI>
|
|
<LI><A href="http://www.entrust.com">Entrust</A> offer a developers'
|
|
toolkit for using their<A href="#PKI"> PKI</A> for IPsec authentication</LI>
|
|
<LI>According to a report on our mailing list,<A href="http://www.axent.com">
|
|
Axent</A> have a Linux version of their product.</LI>
|
|
</UL>
|
|
<H3><A name="router">IPsec in router products</A></H3>
|
|
<P>All the major router vendors support IPsec, at least in some models.</P>
|
|
<UL>
|
|
<LI><A href="http://www.cisco.com/warp/public/707/16.html">Cisco</A>
|
|
IPsec information</LI>
|
|
<LI>Ascend, now part of<A href="http://www.lucent.com/"> Lucent</A>,
|
|
have some IPsec-based products</LI>
|
|
<LI><A href="http://www.nortelnetworks.com/">Bay Networks</A>, now part
|
|
of Nortel, use IPsec in their Contivity switch product line</LI>
|
|
<LI><A href="http://www.3com.com/products/enterprise.html">3Com</A> have
|
|
a number of VPN products, some using IPsec</LI>
|
|
</UL>
|
|
<H3><A name="fw.web">IPsec in firewall products</A></H3>
|
|
<P>Many firewall vendors offer IPsec, either as a standard part of their
|
|
product, or an optional extra. A few we know about are:</P>
|
|
<UL>
|
|
<LI><A href="http://www.borderware.com/">Borderware</A></LI>
|
|
<LI><A href="http://www.ashleylaurent.com/vpn/ipsec_vpn.htm">Ashley
|
|
Laurent</A></LI>
|
|
<LI><A href="http://www.watchguard.com">Watchguard</A></LI>
|
|
<LI><A href="http://www.fx.dk/firewall/ipsec.html">Injoy</A> for OS/2</LI>
|
|
</UL>
|
|
<P>Vendors using FreeS/WAN in turnkey firewall products are listed in
|
|
our<A href="#turnkey"> introduction</A>.</P>
|
|
<H3><A name="ipsecos">Operating systems with IPsec support</A></H3>
|
|
<P>All the major open source operating systems support IPsec. See below
|
|
for details on<A href="#BSD"> BSD-derived</A> Unix variants.</P>
|
|
<P>Among commercial OS vendors, IPsec players include:</P>
|
|
<UL>
|
|
<LI><A href="http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/backgrnd/html/msdn_ip_security.htm">
|
|
Microsoft</A> have put IPsec in their Windows 2000 and XP products</LI>
|
|
<LI><A href="http://www.s390.ibm.com/stories/1999/os390v2r8_pr.html">IBM</A>
|
|
announce a release of OS390 with IPsec support via a crypto
|
|
co-processor</LI>
|
|
<LI><A href="http://www.sun.com/solaris/ds/ds-security/ds-security.pdf">
|
|
Sun</A> include IPsec in Solaris 8</LI>
|
|
<LI><A href="http://www.hp.com/security/products/extranet-security.html">
|
|
Hewlett Packard</A> offer IPsec for their Unix machines</LI>
|
|
<LI>Certicom have IPsec available for the<A href="http://www.certicom.com/products/movian/movianvpn_tech.html">
|
|
Palm</A>.</LI>
|
|
<LI>There were reports before the release that Apple's Mac OS X would
|
|
have IPsec support built in, but it did not seem to be there when we
|
|
last checked. If you find, it please let us know via the<A href="mail.html">
|
|
mailing list</A>.</LI>
|
|
</UL>
|
|
<H3><A NAME="29_3_5">IPsec on network cards</A></H3>
|
|
<P>Network cards with built-in IPsec acceleration are available from at
|
|
least Intel, 3Com and Redcreek.</P>
|
|
<H3><A name="opensource">Open source IPsec implementations</A></H3>
|
|
<H4><A name="linuxipsec">Other Linux IPsec implementations</A></H4>
|
|
<P>We like to think of FreeS/WAN as<EM> the</EM> Linux IPsec
|
|
implementation, but it is not the only one. Others we know of are:</P>
|
|
<UL>
|
|
<LI><A href="http://www.enst.fr/~beyssac/pipsec/">pipsecd</A>, a
|
|
lightweight implementation of IPsec for Linux. Does not require kernel
|
|
recompilation.</LI>
|
|
<LI>Petr Novak's<A href="ftp://ftp.eunet.cz/icz/ipnsec/"> ipnsec</A>,
|
|
based on the OpenBSD IPsec code and using<A href="#photuris"> Photuris</A>
|
|
for key management</LI>
|
|
<LI>A now defunct project at<A href="http://www.cs.arizona.edu/security/hpcc-blue/linux.html">
|
|
U of Arizona</A> (export controlled)</LI>
|
|
<LI><A href="http://snad.ncsl.nist.gov/cerberus">NIST Cerebus</A>
|
|
(export controlled)</LI>
|
|
</UL>
|
|
<H4><A name="BSD">IPsec for BSD Unix</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.kame.net/project-overview.html">KAME</A>,
|
|
several large Japanese companies co-operating on IPv6 and IPsec</LI>
|
|
<LI><A href="http://web.mit.edu/network/isakmp">US Naval Research Lab</A>
|
|
implementation of IPv6 and of IPsec for IPv4 (export controlled)</LI>
|
|
<LI><A href="http://www.openbsd.org">OpenBSD</A> includes IPsec as a
|
|
standard part of the distribution</LI>
|
|
<LI><A href="http://www.r4k.net/ipsec">IPsec for FreeBSD</A></LI>
|
|
<LI>a<A href="http://www.netbsd.org/Documentation/network/ipsec/"> FAQ</A>
|
|
on NetBSD's IPsec implementation</LI>
|
|
</UL>
|
|
<H4><A name="misc">IPsec for other systems</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.tcm.hut.fi/Tutkimus/IPSEC/">Helsinki U of
|
|
Technolgy</A> have implemented IPsec for Solaris, Java and Macintosh</LI>
|
|
</UL>
|
|
<H3><A name="interop.web">Interoperability</A></H3>
|
|
<P>The IPsec protocols are designed so that different implementations
|
|
should be able to work together. As they say "the devil is in the
|
|
details". IPsec has a lot of details, but considerable success has been
|
|
achieved.</P>
|
|
<H4><A name="result">Interoperability results</A></H4>
|
|
<P>Linux FreeS/WAN has been tested for interoperability with many other
|
|
IPsec implementations. Results to date are in our<A href="interop.html">
|
|
interoperability</A> section.</P>
|
|
<P>Various other sites have information on interoperability between
|
|
various IPsec implementations:</P>
|
|
<UL>
|
|
<LI><A href="http://www.opus1.com/vpn/atl99display.html">interop results</A>
|
|
from a bakeoff in Atlanta, September 1999.</LI>
|
|
<LI>a French company, HSC's,<A href="http://www.hsc.fr/ressources/presentations/ipsec99/index.html.en">
|
|
interoperability</A> test data covers FreeS/WAN, Open BSD, KAME, Linux
|
|
pipsecd, Checkpoint, Red Creek Ravlin, and Cisco IOS</LI>
|
|
<LI><A href="http://www.icsa.net/">ICSA</A> offer certification programs
|
|
for various security-related products. See their list of<A href="http://www.icsa.net/html/communities/ipsec/certification/certified_products/index.shtml">
|
|
certified IPsec</A> products. Linux FreeS/WAN is not currently on that
|
|
list, but several products with which we interoperate are.</LI>
|
|
<LI>VPNC have a page on why they are not yet doing<A href="http://www.vpnc.org/interop.html">
|
|
interoperability</A> testing and a page on the<A href="http://www.vpnc.org/conformance.html">
|
|
spec conformance</A> testing that they are doing</LI>
|
|
<LI>a<A href="http://www.commweb.com/article/COM20000912S0009"> review</A>
|
|
comparing a dozen commercial IPsec implemetations. Unfortunately, the
|
|
reviewers did not look at Open Source implementations such as FreeS/WAN
|
|
or OpenBSD.</LI>
|
|
<LI><A href="http://www.tanu.org/~sakane/doc/public/report-ike-interop0007.html">
|
|
results</A> from interoperability tests at a conference. FreeS/WAN was
|
|
not tested there.</LI>
|
|
<LI>test results from the<A href="http://www.hsc.fr/ressources/veille/ipsec/ipsec2000/">
|
|
IPSEC 2000</A> conference</LI>
|
|
</UL>
|
|
<H4><A name="test1">Interoperability test sites</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.tahi.org/">TAHI</A>, a Japanese IPv6 testing
|
|
project with free IPsec validation software</LI>
|
|
<LI><A href="http://ipsec-wit.antd.nist.gov">National Institute of
|
|
Standards and Technology</A></LI>
|
|
<LI><A href="http://isakmp-test.ssh.fi/">SSH Communications Security</A></LI>
|
|
</UL>
|
|
<H2><A name="linux.link">Linux links</A></H2>
|
|
<H3><A name="linux.basic">Basic and tutorial Linux information</A></H3>
|
|
<UL>
|
|
<LI>Linux<A href="http://linuxcentral.com/linux/LDP/LDP/gs/gs.html">
|
|
Getting Started</A> HOWTO document</LI>
|
|
<LI>A getting started guide from the<A href="http://darkwing.uoregon.edu/~cchome/linuxgettingstarted.html">
|
|
U of Oregon</A></LI>
|
|
<LI>A large<A href="http://www.herring.org/techie.html"> link collection</A>
|
|
which includes a lot of introductory and tutorial material on Unix,
|
|
Linux, the net, . . .</LI>
|
|
</UL>
|
|
<H3><A name="general">General Linux sites</A></H3>
|
|
<UL>
|
|
<LI><A href="http://www.freshmeat.net">Freshmeat</A> Linux news</LI>
|
|
<LI><A href="http://slashdot.org">Slashdot</A> "News for Nerds"</LI>
|
|
<LI><A href="http://www.linux.org">Linux Online</A></LI>
|
|
<LI><A href="http://www.linuxhq.com">Linux HQ</A></LI>
|
|
<LI><A href="http://www.tux.org">tux.org</A></LI>
|
|
</UL>
|
|
<H3><A name="docs.ldp">Documentation</A></H3>
|
|
<P>Nearly any Linux documentation you are likely to want can be found at
|
|
the<A href="http://metalab.unc.edu/LDP"> Linux Documentation Project</A>
|
|
or LDP.</P>
|
|
<UL>
|
|
<LI><A href="http://metalab.unc.edu/LDP/HOWTO/META-FAQ.html">Meta-FAQ</A>
|
|
guide to Linux information sources</LI>
|
|
<LI>The LDP's HowTo documents are a standard Linux reference. See this<A href="http://www.linuxdoc.org/docs.html#howto">
|
|
list</A>. Documents there most relevant to a FreeS/WAN gateway are:
|
|
<UL>
|
|
<LI><A href="http://metalab.unc.edu/LDP/HOWTO/Kernel-HOWTO.html">Kernel
|
|
HOWTO</A></LI>
|
|
<LI><A href="http://metalab.unc.edu/LDP/HOWTO/Networking-Overview-HOWTO.html">
|
|
Networking Overview HOWTO</A></LI>
|
|
<LI><A href="http://metalab.unc.edu/LDP/HOWTO/Security-HOWTO.html">
|
|
Security HOWTO</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>The LDP do a series of Guides, book-sized publications with more
|
|
detail (and often more "why do it this way?") than the HowTos. See this<A
|
|
href="http://www.linuxdoc.org/guides.html"> list</A>. Documents there
|
|
most relevant to a FreeS/WAN gateway are:
|
|
<UL>
|
|
<LI><A href="http://www.tml.hut.fi/~viu/linux/sag/">System
|
|
Administrator's Guide</A></LI>
|
|
<LI><A href="http://www.linuxdoc.org/LDP/nag2/index.html">Network
|
|
Adminstrator's Guide</A></LI>
|
|
<LI><A href="http://www.seifried.org/lasg/">Linux Administrator's
|
|
Security Guide</A></LI>
|
|
</UL>
|
|
</LI>
|
|
</UL>
|
|
<P>You may not need to go to the LDP to get this material. Most Linux
|
|
distributions include the HowTos on their CDs and several include the
|
|
Guides as well. Also, most of the Guides and some collections of HowTos
|
|
are available in book form from various publishers.</P>
|
|
<P>Much of the LDP material is also available in languages other than
|
|
English. See this<A href="http://www.linuxdoc.org/links/nenglish.html">
|
|
LDP page</A>.</P>
|
|
<H3><A name="advroute.web">Advanced routing</A></H3>
|
|
<P>The Linux IP stack has some new features in 2.4 kernels. Some HowTos
|
|
have been written:</P>
|
|
<UL>
|
|
<LI>several HowTos for the<A href="http://netfilter.samba.org/unreliable-guides/">
|
|
netfilter</A> firewall code in newer kernels</LI>
|
|
<LI><A href="http://www.ds9a.nl/2.4Networking/HOWTO//cvs/2.4routing/output/2.4networking.html">
|
|
2.4 networking</A> HowTo</LI>
|
|
<LI><A href="http://www.ds9a.nl/2.4Networking/HOWTO//cvs/2.4routing/output/2.4routing.html">
|
|
2.4 routing</A> HowTo</LI>
|
|
</UL>
|
|
<H3><A name="linsec">Security for Linux</A></H3>
|
|
<P>See also the<A href="#docs.ldp"> LDP material</A> above.</P>
|
|
<UL>
|
|
<LI><A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
|
|
Trinity OS guide to setting up Linux</A></LI>
|
|
<LI><A href="http://www.deter.com/unix">Unix security</A> page</LI>
|
|
<LI><A href="http://linux01.gwdg.de/~alatham/">PPDD</A> encrypting
|
|
filesystem</LI>
|
|
<LI><A href="http://EncryptionHOWTO.sourceforge.net/">Linux Encryption
|
|
HowTo</A> (outdated when last checked, had an Oct 2000 revision date in
|
|
March 2002)</LI>
|
|
</UL>
|
|
<H3><A name="firewall.linux">Linux firewalls</A></H3>
|
|
<P>Our<A href="firewall.html"> FreeS/WAN and firewalls</A> document
|
|
includes links to several sets of<A href="#examplefw"> scripts</A>
|
|
known to work with FreeS/WAN.</P>
|
|
<P>Other information sources:</P>
|
|
<UL>
|
|
<LI><A href="http://ipmasq.cjb.net/">IP Masquerade resource page</A></LI>
|
|
<LI><A href="http://netfilter.samba.org/unreliable-guides/">netfilter</A>
|
|
firewall code in 2.4 kernels</LI>
|
|
<LI>Our list of general<A href="#firewall.web"> firewall references</A>
|
|
on the web</LI>
|
|
<LI><A href="http://users.dhp.com/~whisper/mason/">Mason</A>, a tool for
|
|
automatically configuring Linux firewalls</LI>
|
|
<LI>the web cache software<A href="http://www.squid-cache.org/"> squid</A>
|
|
and<A href="http://www.squidguard.org/"> squidguard</A> which turns
|
|
Squid into a filtering web proxy</LI>
|
|
</UL>
|
|
<H3><A name="linux.misc">Miscellaneous Linux information</A></H3>
|
|
<UL>
|
|
<LI><A href="http://lwn.net/current/dists.php3">Linux distribution
|
|
vendors</A></LI>
|
|
<LI><A href="http://www.linux.org/groups/">Linux User Groups</A></LI>
|
|
</UL>
|
|
<H2><A name="crypto.link">Crypto and security links</A></H2>
|
|
<H3><A name="security">Crypto and security resources</A></H3>
|
|
<H4><A name="std.links">The standard link collections</A></H4>
|
|
<P>Two enormous collections of links, each the standard reference in its
|
|
area:</P>
|
|
<DL>
|
|
<DT>Gene Spafford's<A href="http://www.cerias.purdue.edu/coast/hotlist/">
|
|
COAST hotlist</A></DT>
|
|
<DD>Computer and network security.</DD>
|
|
<DT>Peter Gutmann's<A href="http://www.cs.auckland.ac.nz/~pgut001/links.html">
|
|
Encryption and Security-related Resources</A></DT>
|
|
<DD>Cryptography.</DD>
|
|
</DL>
|
|
<H4><A name="FAQ">Frequently Asked Question (FAQ) documents</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.faqs.org/faqs/cryptography-faq/">Cryptography
|
|
FAQ</A></LI>
|
|
<LI><A href="http://www.interhack.net/pubs/fwfaq">Firewall FAQ</A></LI>
|
|
<LI><A href="http://www.whitefang.com/sup/secure-faq.html">Secure Unix
|
|
Programming FAQ</A></LI>
|
|
<LI>FAQs for specific programs are listed in the<A href="#tools"> tools</A>
|
|
section below.</LI>
|
|
</UL>
|
|
<H4><A name="cryptover">Tutorials</A></H4>
|
|
<UL>
|
|
<LI>Gary Kessler's<A href="http://www.garykessler.net/library/crypto.html">
|
|
Overview of Cryptography</A></LI>
|
|
<LI>Terry Ritter's<A href="http://www.ciphersbyritter.com/LEARNING.HTM">
|
|
introduction</A></LI>
|
|
<LI>Peter Gutman's<A href="http://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html">
|
|
cryptography</A> tutorial (500 slides in PDF format)</LI>
|
|
<LI>Amir Herzberg of IBM's sildes for his course<A href="http://www.hrl.il.ibm.com/mpay/course.html">
|
|
Introduction to Cryptography and Electronic Commerce</A></LI>
|
|
<LI>the<A href="http://www.gnupg.org/gph/en/manual/c173.html"> concepts
|
|
section</A> of the<A href="#GPG"> GNU Privacy Guard</A> documentation</LI>
|
|
<LI>Bruce Schneier's self-study<A href="http://www.counterpane.com/self-study.html">
|
|
cryptanalysis</A> course</LI>
|
|
</UL>
|
|
<P>See also the<A href="#interesting"> interesting papers</A> section
|
|
below.</P>
|
|
<H4><A name="standards">Crypto and security standards</A></H4>
|
|
<UL>
|
|
<LI><A href="http://csrc.nist.gov/cc">Common Criteria</A>, new
|
|
international computer and network security standards to replace the
|
|
"Rainbow" series</LI>
|
|
<LI>AES<A href="http://csrc.nist.gov/encryption/aes/aes_home.htm">
|
|
Advanced Encryption Standard</A> which will replace DES</LI>
|
|
<LI><A href="http://grouper.ieee.org/groups/1363">IEEE P-1363 public key
|
|
standard</A></LI>
|
|
<LI>our collection of links for the<A href="#ipsec.link"> IPsec</A>
|
|
standards</LI>
|
|
<LI>history of<A href="http://www.visi.com/crypto/evalhist/index.html">
|
|
formal evaluation</A> of security policies and implementation</LI>
|
|
</UL>
|
|
<H4><A name="quotes">Crypto quotes</A></H4>
|
|
<P>There are several collections of cryptographic quotes on the net:</P>
|
|
<UL>
|
|
<LI><A href="http://www.eff.org/pub/EFF/quotes.eff">the EFF</A></LI>
|
|
<LI><A href="http://www.samsimpson.com/cquotes.php">Sam Simpson</A></LI>
|
|
<LI><A href="http://www.amk.ca/quotations/cryptography/page-1.html">AM
|
|
Kutchling</A></LI>
|
|
</UL>
|
|
<H3><A name="policy">Cryptography law and policy</A></H3>
|
|
<H4><A name="legal">Surveys of crypto law</A></H4>
|
|
<UL>
|
|
<LI>International survey of<A href="http://cwis.kub.nl/~FRW/PEOPLE/koops/lawsurvy.htm">
|
|
crypto law</A>.</LI>
|
|
<LI>International survey of<A href="http://rechten.kub.nl/simone/ds-lawsu.htm">
|
|
digital signature law</A></LI>
|
|
</UL>
|
|
<H4><A name="oppose">Organisations opposing crypto restrictions</A></H4>
|
|
<UL>
|
|
<LI>The<A href="#EFF"> EFF</A>'s archives on<A href="http://www.eff.org/pub/Privacy/">
|
|
privacy</A> and<A href="http://www.eff.org/pub/Privacy/ITAR_export/">
|
|
export control</A>.</LI>
|
|
<LI><A href="http://www.gilc.org">Global Internet Liberty Campaign</A></LI>
|
|
<LI><A href="http://www.cdt.org/crypto">Center for Democracy and
|
|
Technology</A></LI>
|
|
<LI><A href="http://www.privacyinternational.org/">Privacy International</A>
|
|
, who give out<A href="http://www.bigbrotherawards.org/"> Big Brother
|
|
Awards</A> to snoopy organisations</LI>
|
|
</UL>
|
|
<H4><A name="other.policy">Other information on crypto policy</A></H4>
|
|
<UL>
|
|
<LI><A href="ftp://ftp.isi.edu/in-notes/rfc1984.txt">RFC 1984</A>, the<A href="#IAB">
|
|
IAB</A> and<A href="#IESG"> IESG</A> Statement on Cryptographic
|
|
Technology and the Internet.</LI>
|
|
<LI>John Young's collection of<A href="http://cryptome.org/"> documents</A>
|
|
of interest to the cryptography, open government and privacy movements,
|
|
organized chronologically</LI>
|
|
<LI>AT&T researcher Matt Blaze's Encryption, Privacy and Security<A href="http://www.crypto.com">
|
|
Resource Page</A></LI>
|
|
<LI>A good<A href="http://cryptome.org/crypto97-ne.htm"> overview</A> of
|
|
the issues from Australia.</LI>
|
|
</UL>
|
|
<P>See also our documentation section on the<A href="politics.html">
|
|
history and politics</A> of cryptography.</P>
|
|
<H3><A name="crypto.tech">Cryptography technical information</A></H3>
|
|
<H4><A name="cryptolinks">Collections of crypto links</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.counterpane.com/hotlist.html">Counterpane</A></LI>
|
|
<LI><A href="http://www.cs.auckland.ac.nz/~pgut001/links.html">Peter
|
|
Gutman's links</A></LI>
|
|
<LI><A href="http://www.pca.dfn.de/eng/team/ske/pem-dok.html">PKI links</A>
|
|
</LI>
|
|
<LI><A href="http://crypto.yashy.com/www/">Robert Guerra's links</A></LI>
|
|
</UL>
|
|
<H4><A name="papers">Lists of online cryptography papers</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.counterpane.com/biblio">Counterpane</A></LI>
|
|
<LI><A href="http://www.cryptography.com/resources/papers">
|
|
cryptography.com</A></LI>
|
|
<LI><A href="http://www.cryptosoft.com/html/secpub.htm">Cryptosoft</A></LI>
|
|
</UL>
|
|
<H4><A name="interesting">Particularly interesting papers</A></H4>
|
|
<P>These papers emphasize important issues around the use of
|
|
cryptography, and the design and management of secure systems.</P>
|
|
<UL>
|
|
<LI><A href="http://www.counterpane.com/keylength.html">Key length
|
|
requirements for security</A></LI>
|
|
<LI><A href="http://www.cl.cam.ac.uk/users/rja14/wcf.html">Why
|
|
Cryptosystems Fail</A></LI>
|
|
<LI><A href="http://www.cdt.org/crypto/risks98/">Risks of escrowed
|
|
encryption</A></LI>
|
|
<LI><A href="http://www.counterpane.com/pitfalls.html">Security pitfalls
|
|
in cryptography</A></LI>
|
|
<LI><A href="http://www.acm.org/classics/sep95">Reflections on Trusting
|
|
Trust</A>, Ken Thompson on Trojan horse design</LI>
|
|
<LI><A href="http://www.apache-ssl.org/disclosure.pdf">Security against
|
|
Compelled Disclosure</A>, how to maintain privacy in the face of legal
|
|
or other coersion</LI>
|
|
</UL>
|
|
<H3><A name="compsec">Computer and network security</A></H3>
|
|
<H4><A name="seclink">Security links</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.cs.purdue.edu/coast/hotlist">COAST Hotlist</A></LI>
|
|
<LI>DMOZ open directory project<A href="http://dmoz.org/Computers/Security/">
|
|
computer security</A> links</LI>
|
|
<LI><A href="http://www-cse.ucsd.edu/users/bsy/sec.html">Bennet Yee</A></LI>
|
|
<LI>Mike Fuhr's<A href="http://www.fuhr.org/~mfuhr/computers/security.html">
|
|
link collection</A></LI>
|
|
<LI><A href="http://www.networkintrusion.co.uk/">links</A> with an
|
|
emphasis on intrusion detection</LI>
|
|
</UL>
|
|
<H4><A name="firewall.web">Firewall links</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.cs.purdue.edu/coast/firewalls">COAST firewalls</A>
|
|
</LI>
|
|
<LI><A href="http://www.zeuros.co.uk">Firewalls Resource page</A></LI>
|
|
</UL>
|
|
<H4><A name="vpn">VPN links</A></H4>
|
|
<UL>
|
|
<LI><A href="http://www.vpnc.org">VPN Consortium</A></LI>
|
|
<LI>First VPN's<A href="http://www.firstvpn.com/research/rhome.html">
|
|
white paper</A> collection</LI>
|
|
</UL>
|
|
<H4><A name="tools">Security tools</A></H4>
|
|
<UL>
|
|
<LI>PGP -- mail encryption
|
|
<UL>
|
|
<LI><A href="http://www.pgp.com/">PGP Inc.</A> (part of NAI) for
|
|
commercial versions</LI>
|
|
<LI><A href="http://web.mit.edu/network/pgp.html">MIT</A> distributes
|
|
the NAI product for non-commercial use</LI>
|
|
<LI><A href="http://www.pgpi.org/">international</A> distribution site</LI>
|
|
<LI><A href="http://gnupg.org">GNU Privacy Guard (GPG)</A></LI>
|
|
<LI><A href="http://www.dk.pgp.net/pgpnet/pgp-faq/">PGP FAQ</A></LI>
|
|
</UL>
|
|
A message in our mailing list archive has considerable detail on<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00029.html">
|
|
available versions</A> of PGP and on IPsec support in them.
|
|
<P><STRONG>Note:</STRONG> A fairly nasty bug exists in all commercial
|
|
PGP versions from 5.5 through 6.5.3. If you have one of those,<STRONG>
|
|
upgrade now</STRONG>.</P>
|
|
</LI>
|
|
<LI>SSH -- secure remote login
|
|
<UL>
|
|
<LI><A href="http://www.ssh.fi">SSH Communications Security</A>, for the
|
|
original software. It is free for trial, academic and non-commercial
|
|
use.</LI>
|
|
<LI><A href="http://www.openssh.com/">Open SSH</A>, the Open BSD team's
|
|
free replacement</LI>
|
|
<LI><A href="http://www.freessh.org/">freessh.org</A>, links to free
|
|
implementations for many systems</LI>
|
|
<LI><A href="http://www.uni-karlsruhe.de/~ig25/ssh-faq">SSH FAQ</A></LI>
|
|
<LI><A href="http://www.chiark.greenend.org.uk/~sgtatham/putty/">Putty</A>
|
|
, an SSH client for Windows</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>Tripwire saves message digests of your system files. Re-calculate
|
|
the digests and compare to saved values to detect any file changes.
|
|
There are several versions available:
|
|
<UL>
|
|
<LI><A href="http://www.tripwiresecurity.com/">commercial version</A></LI>
|
|
<LI><A href="http://www.tripwire.org/">Open Source</A></LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="http://www.snort.org">Snort</A> and<A href="http://www.lids.org">
|
|
LIDS</A> are intrusion detection system for Linux</LI>
|
|
<LI><A href="http://www.fish.com/~zen/satan/satan.html">SATAN</A> System
|
|
Administrators Tool for Analysing Networks</LI>
|
|
<LI><A href="http://www.insecure.org/nmap/">NMAP</A> Network Mapper</LI>
|
|
<LI><A href="ftp://ftp.porcupine.org/pub/security/index.html">Wietse
|
|
Venema's page</A> with various tools</LI>
|
|
<LI><A href="http://ita.ee.lbl.gov/index.html">Internet Traffic Archive</A>
|
|
, various tools to analyze network traffic, mostly scripts to organise
|
|
and format tcpdump(8) output for specific purposes</LI>
|
|
<LI><A name="ssmail">ssmail -- sendmail patched to do</A><A href="#carpediem">
|
|
opportunistic encryption</A>
|
|
<UL>
|
|
<LI><A href="http://www.home.aone.net.au/qualcomm/">web page</A> with
|
|
links to code and to a Usenix paper describing it, in PDF</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI><A href="http://www.openca.org/">Open CA</A> project to develop a
|
|
freely distributed<A href="#CA"> Certification Authority</A> for
|
|
building a open<A href="#PKI"> Public Key Infrastructure</A>.</LI>
|
|
</UL>
|
|
<H3><A name="people">Links to home pages</A></H3>
|
|
<P>David Wagner at Berkeley provides a set of links to<A href="http://www.cs.berkeley.edu/~daw/people/crypto.html">
|
|
home pages</A> of cryptographers, cypherpunks and computer security
|
|
people.</P>
|
|
<HR>
|
|
<H1><A name="ourgloss">Glossary for the Linux FreeS/WAN project</A></H1>
|
|
<P>Entries are in alphabetical order. Some entries are only one line or
|
|
one paragraph long. Others run to several paragraphs. I have tried to
|
|
put the essential information in the first paragraph so you can skip
|
|
the other paragraphs if that seems appropriate.</P>
|
|
<HR>
|
|
<H2><A name="jump">Jump to a letter in the glossary</A></H2>
|
|
<CENTER> <BIG><B><A href="#0">numeric</A><A href="#A"> A</A><A href="#B">
|
|
B</A><A href="#C"> C</A><A href="#D"> D</A><A href="#E"> E</A><A href="#F">
|
|
F</A><A href="#G"> G</A><A href="#H"> H</A><A href="#I"> I</A><A href="#J">
|
|
J</A><A href="#K"> K</A><A href="#L"> L</A><A href="#M"> M</A><A href="#N">
|
|
N</A><A href="#O"> O</A><A href="#P"> P</A><A href="#Q"> Q</A><A href="#R">
|
|
R</A><A href="#S"> S</A><A href="#T"> T</A><A href="#U"> U</A><A href="#V">
|
|
V</A><A href="#W"> W</A><A href="#X"> X</A><A href="#Y"> Y</A><A href="#Z">
|
|
Z</A></B></BIG></CENTER>
|
|
<HR>
|
|
<H2><A name="gloss">Other glossaries</A></H2>
|
|
<P>Other glossaries which overlap this one include:</P>
|
|
<UL>
|
|
<LI>The VPN Consortium's glossary of<A href="http://www.vpnc.org/terms.html">
|
|
VPN terms</A>.</LI>
|
|
<LI>glossary portion of the<A href="http://www.rsa.com/rsalabs/faq/B.html">
|
|
Cryptography FAQ</A></LI>
|
|
<LI>an extensive crytographic glossary on<A href="http://www.ciphersbyritter.com/GLOSSARY.HTM">
|
|
Terry Ritter's</A> page.</LI>
|
|
<LI>The<A href="#NSA"> NSA</A>'s<A href="http://www.sans.org/newlook/resources/glossary.htm">
|
|
glossary of computer security</A> on the<A href="http://www.sans.org">
|
|
SANS Institute</A> site.</LI>
|
|
<LI>a small glossary for Internet Security at<A href="http://www5.zdnet.com/pcmag/pctech/content/special/glossaries/internetsecurity.html">
|
|
PC magazine</A></LI>
|
|
<LI>The<A href="http://www.visi.com/crypto/inet-crypto/glossary.html">
|
|
glossary</A> from Richard Smith's book<A href="#Smith"> Internet
|
|
Cryptography</A></LI>
|
|
</UL>
|
|
<P>Several Internet glossaries are available as RFCs:</P>
|
|
<UL>
|
|
<LI><A href="http://www.rfc-editor.org/rfc/rfc1208.txt">Glossary of
|
|
Networking Terms</A></LI>
|
|
<LI><A href="http://www.rfc-editor.org/rfc/rfc1983.txt">Internet User's
|
|
Glossary</A></LI>
|
|
<LI><A href="http://www.rfc-editor.org/rfc/rfc2828.txt">Internet
|
|
Security Glossary</A></LI>
|
|
</UL>
|
|
<P>More general glossary or dictionary information:</P>
|
|
<UL>
|
|
<LI>Free Online Dictionary of Computing (FOLDOC)
|
|
<UL>
|
|
<LI><A href="http://www.nightflight.com/foldoc">North America</A></LI>
|
|
<LI><A href="http://wombat.doc.ic.ac.uk/foldoc/index.html">Europe</A></LI>
|
|
<LI><A href="http://www.nue.org/foldoc/index.html">Japan</A></LI>
|
|
</UL>
|
|
<P>There are many more mirrors of this dictionary.</P>
|
|
</LI>
|
|
<LI>The Jargon File, the definitive resource for hacker slang and
|
|
folklore
|
|
<UL>
|
|
<LI><A href="http://www.netmeg.net/jargon">North America</A></LI>
|
|
<LI><A href="http://info.wins.uva.nl/~mes/jargon/">Holland</A></LI>
|
|
<LI><A href="http://www.tuxedo.org/~esr/jargon">home page</A></LI>
|
|
</UL>
|
|
<P>There are also many mirrors of this. See the home page for a list.</P>
|
|
</LI>
|
|
<LI>A general<A href="http://www.trinity.edu/~rjensen/245glosf.htm#Navigate">
|
|
technology glossary</A></LI>
|
|
<LI>An<A href="http://www.yourdictionary.com/"> online dictionary
|
|
resource page</A> with pointers to many dictionaries for many languages</LI>
|
|
<LI>A<A href="http://www.onelook.com/"> search engine</A> that accesses
|
|
several hundred online dictionaries</LI>
|
|
<LI>O'Reilly<A href="http://www.ora.com/reference/dictionary/">
|
|
Dictionary of PC Hardware and Data Communications Terms</A></LI>
|
|
<LI><A href="http://www.FreeSoft.org/CIE/index.htm">Connected</A>
|
|
Internet encyclopedia</LI>
|
|
<LI><A href="http://www.whatis.com/">whatis.com</A></LI>
|
|
</UL>
|
|
<HR>
|
|
<H2><A name="definitions">Definitions</A></H2>
|
|
<DL>
|
|
<DT><A name="0">0</A></DT>
|
|
<DT><A name="3DES">3DES (Triple DES)</A></DT>
|
|
<DD>Using three<A href="#DES"> DES</A> encryptions on a single data
|
|
block, with at least two different keys, to get higher security than is
|
|
available from a single DES pass. The three-key version of 3DES is the
|
|
default encryption algorithm for<A href="#FreeSWAN"> Linux FreeS/WAN</A>
|
|
.
|
|
<P><A href="#IPSEC">IPsec</A> always does 3DES with three different
|
|
keys, as required by RFC 2451. For an explanation of the two-key
|
|
variant, see<A href="#2key"> two key triple DES</A>. Both use an<A href="#EDE">
|
|
EDE</A> encrypt-decrypt-encrpyt sequence of operations.</P>
|
|
<P>Single<A href="#DES"> DES</A> is<A href="#desnotsecure"> insecure</A>
|
|
.</P>
|
|
<P>Double DES is ineffective. Using two 56-bit keys, one might expect an
|
|
attacker to have to do 2<SUP>112</SUP> work to break it. In fact, only
|
|
2<SUP>57</SUP> work is required with a<A href="#meet">
|
|
meet-in-the-middle attack</A>, though a large amount of memory is also
|
|
required. Triple DES is vulnerable to a similar attack, but that just
|
|
reduces the work factor from the 2<SUP>168</SUP> one might expect to 2<SUP>
|
|
112</SUP>. That provides adequate protection against<A href="#brute">
|
|
brute force</A> attacks, and no better attack is known.</P>
|
|
<P>3DES can be somewhat slow compared to other ciphers. It requires
|
|
three DES encryptions per block. DES was designed for hardware
|
|
implementation and includes some operations which are difficult in
|
|
software. However, the speed we get is quite acceptable for many uses.
|
|
See our<A href="performance.html"> performance</A> document for
|
|
details.</P>
|
|
</DD>
|
|
<DT><A name="A">A</A></DT>
|
|
<DT><A name="active">Active attack</A></DT>
|
|
<DD>An attack in which the attacker does not merely eavesdrop (see<A href="#passive">
|
|
passive attack</A>) but takes action to change, delete, reroute, add,
|
|
forge or divert data. Perhaps the best-known active attack is<A href="#middle">
|
|
man-in-the-middle</A>. In general,<A href="#authentication">
|
|
authentication</A> is a useful defense against active attacks.</DD>
|
|
<DT><A name="AES">AES</A></DT>
|
|
<DD>The<B> A</B>dvanced<B> E</B>ncryption<B> S</B>tandard -- a new<A href="#block">
|
|
block cipher</A> standard to replace<A href="#desnotsecure"> DES</A> --
|
|
developed by<A href="#NIST"> NIST</A>, the US National Institute of
|
|
Standards and Technology. DES used 64-bit blocks and a 56-bit key. AES
|
|
ciphers use a 128-bit block and 128, 192 or 256-bit keys. The larger
|
|
block size helps resist<A href="#birthday"> birthday attacks</A> while
|
|
the large key size prevents<A href="#brute"> brute force attacks</A>.
|
|
<P>Fifteen proposals meeting NIST's basic criteria were submitted in
|
|
1998 and subjected to intense discussion and analysis, "round one"
|
|
evaluation. In August 1999, NIST narrowed the field to five "round two"
|
|
candidates:</P>
|
|
<UL>
|
|
<LI><A href="http://www.research.ibm.com/security/mars.html">Mars</A>
|
|
from IBM</LI>
|
|
<LI><A href="http://www.rsa.com/rsalabs/aes/">RC6</A> from RSA</LI>
|
|
<LI><A href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael/">Rijndael</A>
|
|
from two Belgian researchers</LI>
|
|
<LI><A href="http://www.cl.cam.ac.uk/~rja14/serpent.html">Serpent</A>, a
|
|
British-Norwegian-Israeli collaboration</LI>
|
|
<LI><A href="http://www.counterpane.com/twofish.html">Twofish</A> from
|
|
the consulting firm<A href="http://www.counterpane.com"> Counterpane</A>
|
|
</LI>
|
|
</UL>
|
|
<P>Three of the five finalists -- Rijndael, Serpent and Twofish -- have
|
|
completely open licenses.</P>
|
|
<P>In October 2000, NIST announced the winner -- Rijndael.</P>
|
|
<P>For more information, see:</P>
|
|
<UL>
|
|
<LI>NIST's<A href="http://csrc.nist.gov/encryption/aes/aes_home.htm">
|
|
AES home page</A></LI>
|
|
<LI>the Block Cipher Lounge<A href="http://www.ii.uib.no/~larsr/aes.html">
|
|
AES page</A></LI>
|
|
<LI>Brian Gladman's<A href="http://fp.gladman.plus.com/cryptography_technology/index.htm">
|
|
code and benchmarks</A></LI>
|
|
<LI>Helger Lipmaa's<A href="http://www.tcs.hut.fi/~helger/aes/"> survey
|
|
of implementations</A></LI>
|
|
</UL>
|
|
<P>AES will be added to a future release of<A href="#FreeSWAN"> Linux
|
|
FreeS/WAN</A>. Likely we will add all three of the finalists with good
|
|
licenses. User-written<A href="#patch"> AES patches</A> are already
|
|
available.</P>
|
|
<P>Adding AES may also require adding stronger hashes,<A href="#SHA-256">
|
|
SHA-256, SHA-384 and SHA-512</A>.</P>
|
|
</DD>
|
|
<DT><A name="AH">AH</A></DT>
|
|
<DD>The<A href="#IPSEC"> IPsec</A><B> A</B>uthentication<B> H</B>eader,
|
|
added after the IP header. For details, see our<A href="#AH.ipsec">
|
|
IPsec</A> document and/or RFC 2402.</DD>
|
|
<DT><A name="alicebob">Alice and Bob</A></DT>
|
|
<DD>A and B, the standard example users in writing on cryptography and
|
|
coding theory. Carol and Dave join them for protocols which require
|
|
more players.
|
|
<P>Bruce Schneier extends these with many others such as Eve the
|
|
Eavesdropper and Victor the Verifier. His extensions seem to be in the
|
|
process of becoming standard as well. See page 23 of<A href="#schneier">
|
|
Applied Cryptography</A></P>
|
|
<P>Alice and Bob have an amusing<A href="http://www.conceptlabs.co.uk/alicebob.html">
|
|
biography</A> on the web.</P>
|
|
</DD>
|
|
<DT>ARPA</DT>
|
|
<DD>see<A href="#DARPA"> DARPA</A></DD>
|
|
<DT><A name="ASIO">ASIO</A></DT>
|
|
<DD>Australian Security Intelligence Organisation.</DD>
|
|
<DT>Asymmetric cryptography</DT>
|
|
<DD>See<A href="#public"> public key cryptography</A>.</DD>
|
|
<DT><A name="authentication">Authentication</A></DT>
|
|
<DD>Ensuring that a message originated from the expected sender and has
|
|
not been altered on route.<A href="#IPSEC"> IPsec</A> uses
|
|
authentication in two places:
|
|
<UL>
|
|
<LI>peer authentication, authenticating the players in<A href="#IKE">
|
|
IKE</A>'s<A href="#DH"> Diffie-Hellman</A> key exchanges to prevent<A href="#middle">
|
|
man-in-the-middle attacks</A>. This can be done in a number of ways.
|
|
The methods supported by FreeS/WAN are discussed in our<A href="#choose">
|
|
advanced configuration</A> document.</LI>
|
|
<LI>packet authentication, authenticating packets on an established<A href="#SA">
|
|
SA</A>, either with a separate<A href="#AH"> authentication header</A>
|
|
or with the optional authentication in the<A href="#ESP"> ESP</A>
|
|
protocol. In either case, packet authentication uses a<A href="#HMAC">
|
|
hashed message athentication code</A> technique.</LI>
|
|
</UL>
|
|
<P>Outside IPsec, passwords are perhaps the most common authentication
|
|
mechanism. Their function is essentially to authenticate the person's
|
|
identity to the system. Passwords are generally only as secure as the
|
|
network they travel over. If you send a cleartext password over a
|
|
tapped phone line or over a network with a packet sniffer on it, the
|
|
security provided by that password becomes zero. Sending an encrypted
|
|
password is no better; the attacker merely records it and reuses it at
|
|
his convenience. This is called a<A href="#replay"> replay</A> attack.</P>
|
|
<P>A common solution to this problem is a<A href="#challenge">
|
|
challenge-response</A> system. This defeats simple eavesdropping and
|
|
replay attacks. Of course an attacker might still try to break the
|
|
cryptographic algorithm used, or the<A href="#random"> random number</A>
|
|
generator.</P>
|
|
</DD>
|
|
<DT><A name="auto">Automatic keying</A></DT>
|
|
<DD>A mode in which keys are automatically generated at connection
|
|
establisment and new keys automaically created periodically thereafter.
|
|
Contrast with<A href="#manual"> manual keying</A> in which a single
|
|
stored key is used.
|
|
<P>IPsec uses the<A href="#DH"> Diffie-Hellman key exchange protocol</A>
|
|
to create keys. An<A href="#authentication"> authentication</A>
|
|
mechansim is required for this. FreeS/WAN normally uses<A href="#RSA">
|
|
RSA</A> for this. Other methods supported are discussed in our<A href="#choose">
|
|
advanced configuration</A> document.</P>
|
|
<P>Having an attacker break the authentication is emphatically not a
|
|
good idea. An attacker that breaks authentication, and manages to
|
|
subvert some other network entities (DNS, routers or gateways), can use
|
|
a<A href="#middle"> man-in-the middle attack</A> to break the security
|
|
of your IPsec connections.</P>
|
|
<P>However, having an attacker break the authentication in automatic
|
|
keying is not quite as bad as losing the key in manual keying.</P>
|
|
<UL>
|
|
<LI>An attacker who reads /etc/ipsec.conf and gets the keys for a
|
|
manually keyed connection can, without further effort, read all
|
|
messages encrypted with those keys, including any old messages he may
|
|
have archived.</LI>
|
|
<LI>Automatic keying has a property called<A href="#PFS"> perfect
|
|
forward secrecy</A>. An attacker who breaks the authentication gets
|
|
none of the automatically generated keys and cannot immediately read
|
|
any messages. He has to mount a successful<A href="#middle">
|
|
man-in-the-middle attack</A> in real time before he can read anything.
|
|
He cannot read old archived messages at all and will not be able to
|
|
read any future messages not caught by man-in-the-middle tricks.</LI>
|
|
</UL>
|
|
<P>That said, the secrets used for authentication, stored in<A href="manpage.d/ipsec.secrets.5.html">
|
|
ipsec.secrets(5)</A>, should still be protected as tightly as
|
|
cryptographic keys.</P>
|
|
</DD>
|
|
<DT><A name="B">B</A></DT>
|
|
<DT><A href="http://www.nortelnetworks.com">Bay Networks</A></DT>
|
|
<DD>A vendor of routers, hubs and related products, now a subsidiary of
|
|
Nortel. Interoperation between their IPsec products and Linux FreeS/WAN
|
|
was problematic at last report; see our<A href="interop.html#bay">
|
|
interoperation</A> section.</DD>
|
|
<DT><A name="benchmarks">benchmarks</A></DT>
|
|
<DD>Our default block cipher,<A href="#3DES"> triple DES</A>, is slower
|
|
than many alternate ciphers that might be used. Speeds achieved,
|
|
however, seem adequate for many purposes. For example, the assembler
|
|
code from the<A href="#LIBDES"> LIBDES</A> library we use encrypts 1.6
|
|
megabytes per second on a Pentium 200, according to the test program
|
|
supplied with the library.
|
|
<P>For more detail, see our document on<A href="performance.html">
|
|
FreeS/WAN performance</A>.</P>
|
|
</DD>
|
|
<DT><A name="BIND">BIND</A></DT>
|
|
<DD><B>B</B>erkeley<B> I</B>nternet<B> N</B>ame<B> D</B>aemon, a widely
|
|
used implementation of<A href="#DNS"> DNS</A> (Domain Name Service).
|
|
See our bibliography for a<A href="#DNS"> useful reference</A>. See the<A
|
|
href="http://www.isc.org/bind.html"> BIND home page</A> for more
|
|
information and the latest version.</DD>
|
|
<DT><A name="birthday">Birthday attack</A></DT>
|
|
<DD>A cryptographic attack based on the mathematics exemplified by the<A href="#paradox">
|
|
birthday paradox</A>. This math turns up whenever the question of two
|
|
cryptographic operations producing the same result becomes an issue:
|
|
<UL>
|
|
<LI><A href="#collision">collisions</A> in<A href="#digest"> message
|
|
digest</A> functions.</LI>
|
|
<LI>identical output blocks from a<A href="#block"> block cipher</A></LI>
|
|
<LI>repetition of a challenge in a<A href="#challenge">
|
|
challenge-response</A> system</LI>
|
|
</UL>
|
|
<P>Resisting such attacks is part of the motivation for:</P>
|
|
<UL>
|
|
<LI>hash algorithms such as<A href="#SHA"> SHA</A> and<A href="#RIPEMD">
|
|
RIPEMD-160</A> giving a 160-bit result rather than the 128 bits of<A href="#MD4">
|
|
MD4</A>,<A href="#MD5"> MD5</A> and<A href="#RIPEMD"> RIPEMD-128</A>.</LI>
|
|
<LI><A href="#AES">AES</A> block ciphers using a 128-bit block instead
|
|
of the 64-bit block of most current ciphers</LI>
|
|
<LI><A href="#IPSEC">IPsec</A> using a 32-bit counter for packets sent
|
|
on an<A href="#auto"> automatically keyed</A><A href="#SA"> SA</A> and
|
|
requiring that the connection always be rekeyed before the counter
|
|
overflows.</LI>
|
|
</UL>
|
|
</DD>
|
|
<DT><A name="paradox">Birthday paradox</A></DT>
|
|
<DD>Not really a paradox, just a rather counter-intuitive mathematical
|
|
fact. In a group of 23 people, the chance of a least one pair having
|
|
the same birthday is over 50%.
|
|
<P>The second person has 1 chance in 365 (ignoring leap years) of
|
|
matching the first. If they don't match, the third person's chances of
|
|
matching one of them are 2/365. The 4th, 3/365, and so on. The total of
|
|
these chances grows more quickly than one might guess.</P>
|
|
</DD>
|
|
<DT><A name="block">Block cipher</A></DT>
|
|
<DD>A<A href="#symmetric"> symmetric cipher</A> which operates on
|
|
fixed-size blocks of plaintext, giving a block of ciphertext for each.
|
|
Contrast with<A href="#stream"> stream cipher</A>. Block ciphers can be
|
|
used in various<A href="#mode"> modes</A> when multiple block are to be
|
|
encrypted.
|
|
<P><A href="#DES">DES</A> is among the the best known and widely used
|
|
block ciphers, but is now obsolete. Its 56-bit key size makes it<A href="#desnotsecure">
|
|
highly insecure</A> today.<A href="#3DES"> Triple DES</A> is the
|
|
default block cipher for<A href="#FreeSWAN"> Linux FreeS/WAN</A>.</P>
|
|
<P>The current generation of block ciphers -- such as<A href="#Blowfish">
|
|
Blowfish</A>,<A href="#CAST128"> CAST-128</A> and<A href="#IDEA"> IDEA</A>
|
|
-- all use 64-bit blocks and 128-bit keys. The next generation,<A href="#AES">
|
|
AES</A>, uses 128-bit blocks and supports key sizes up to 256 bits.</P>
|
|
<P>The<A href="http://www.ii.uib.no/~larsr/bc.html"> Block Cipher Lounge</A>
|
|
web site has more information.</P>
|
|
</DD>
|
|
<DT><A name="Blowfish">Blowfish</A></DT>
|
|
<DD>A<A href="#block"> block cipher</A> using 64-bit blocks and keys of
|
|
up to 448 bits, designed by<A href="#schneier"> Bruce Schneier</A> and
|
|
used in several products.
|
|
<P>This is not required by the<A href="#IPSEC"> IPsec</A> RFCs and not
|
|
currently used in<A href="#FreeSWAN"> Linux FreeS/WAN</A>.</P>
|
|
</DD>
|
|
<DT><A name="brute">Brute force attack (exhaustive search)</A></DT>
|
|
<DD>Breaking a cipher by trying all possible keys. This is always
|
|
possible in theory (except against a<A href="#OTP"> one-time pad</A>),
|
|
but it becomes practical only if the key size is inadequate. For an
|
|
important example, see our document on the<A href="#desnotsecure">
|
|
insecurity of DES</A> with its 56-bit key. For an analysis of key sizes
|
|
required to resist plausible brute force attacks, see<A href="http://www.counterpane.com/keylength.html">
|
|
this paper</A>.
|
|
<P>Longer keys protect against brute force attacks. Each extra bit in
|
|
the key doubles the number of possible keys and therefore doubles the
|
|
work a brute force attack must do. A large enough key defeats<STRONG>
|
|
any</STRONG> brute force attack.</P>
|
|
<P>For example, the EFF's<A href="#EFF"> DES Cracker</A> searches a
|
|
56-bit key space in an average of a few days. Let us assume an attacker
|
|
that can find a 64-bit key (256 times harder) by brute force search in
|
|
a second (a few hundred thousand times faster). For a 96-bit key, that
|
|
attacker needs 2<SUP>32</SUP> seconds, about 135 years. Against a
|
|
128-bit key, he needs 2<SUP>32</SUP> times that, over 500,000,000,000
|
|
years. Your data is then obviously secure against brute force attacks.
|
|
Even if our estimate of the attacker's speed is off by a factor of a
|
|
million, it still takes him over 500,000 years to crack a message.</P>
|
|
<P>This is why</P>
|
|
<UL>
|
|
<LI>single<A href="#DES"> DES</A> is now considered<A href="#desnotsecure">
|
|
dangerously insecure</A></LI>
|
|
<LI>all of the current generation of<A href="#block"> block ciphers</A>
|
|
use a 128-bit or longer key</LI>
|
|
<LI><A href="#AES">AES</A> ciphers support keysizes 128, 192 and 256
|
|
bits</LI>
|
|
<LI>any cipher we add to Linux FreeS/WAN will have<EM> at least</EM> a
|
|
128-bit key</LI>
|
|
</UL>
|
|
<P><STRONG>Cautions:</STRONG>
|
|
<BR><EM> Inadequate keylength always indicates a weak cipher</EM> but it
|
|
is important to note that<EM> adequate keylength does not necessarily
|
|
indicate a strong cipher</EM>. There are many attacks other than brute
|
|
force, and adequate keylength<EM> only</EM> guarantees resistance to
|
|
brute force. Any cipher, whatever its key size, will be weak if design
|
|
or implementation flaws allow other attacks.</P>
|
|
<P>Also,<EM> once you have adequate keylength</EM> (somewhere around 90
|
|
or 100 bits),<EM> adding more key bits make no practical difference</EM>
|
|
, even against brute force. Consider our 128-bit example above that
|
|
takes 500,000,000,000 years to break by brute force. We really don't
|
|
care how many zeroes there are on the end of that, as long as the
|
|
number remains ridiculously large. That is, we don't care exactly how
|
|
large the key is as long as it is large enough.</P>
|
|
<P>There may be reasons of convenience in the design of the cipher to
|
|
support larger keys. For example<A href="#Blowfish"> Blowfish</A>
|
|
allows up to 448 bits and<A href="#RC4"> RC4</A> up to 2048, but beyond
|
|
100-odd bits it makes no difference to practical security.</P>
|
|
</DD>
|
|
<DT>Bureau of Export Administration</DT>
|
|
<DD>see<A href="#BXA"> BXA</A></DD>
|
|
<DT><A name="BXA">BXA</A></DT>
|
|
<DD>The US Commerce Department's<B> B</B>ureau of E<B>x</B>port<B> A</B>
|
|
dministration which administers the<A href="#EAR"> EAR</A> Export
|
|
Administration Regulations controling the export of, among other
|
|
things, cryptography.</DD>
|
|
<DT><A name="C">C</A></DT>
|
|
<DT><A name="CA">CA</A></DT>
|
|
<DD><B>C</B>ertification<B> A</B>uthority, an entity in a<A href="#PKI">
|
|
public key infrastructure</A> that can certify keys by signing them.
|
|
Usually CAs form a hierarchy. The top of this hierarchy is called the<A href="#rootCA">
|
|
root CA</A>.
|
|
<P>See<A href="#web"> Web of Trust</A> for an alternate model.</P>
|
|
</DD>
|
|
<DT><A name="CAST128">CAST-128</A></DT>
|
|
<DD>A<A href="#block"> block cipher</A> using 64-bit blocks and 128-bit
|
|
keys, described in RFC 2144 and used in products such as<A href="#Entrust">
|
|
Entrust</A> and recent versions of<A href="#PGP"> PGP</A>.
|
|
<P>This is not required by the<A href="#IPSEC"> IPsec</A> RFCs and not
|
|
currently used in<A href="#FreeSWAN"> Linux FreeS/WAN</A>.</P>
|
|
</DD>
|
|
<DT>CAST-256</DT>
|
|
<DD><A href="#Entrust">Entrust</A>'s candidate cipher for the<A href="#AES">
|
|
AES standard</A>, largely based on the<A href="#CAST128"> CAST-128</A>
|
|
design.</DD>
|
|
<DT><A name="CBC">CBC mode</A></DT>
|
|
<DD><B>C</B>ipher<B> B</B>lock<B> C</B>haining<A href="#mode"> mode</A>,
|
|
a method of using a<A href="#block"> block cipher</A> in which for each
|
|
block except the first, the result of the previous encryption is XORed
|
|
into the new block before it is encrypted. CBC is the mode used in<A href="#IPSEC">
|
|
IPsec</A>.
|
|
<P>An<A href="#IV"> initialisation vector</A> (IV) must be provided. It
|
|
is XORed into the first block before encryption. The IV need not be
|
|
secret but should be different for each message and unpredictable.</P>
|
|
</DD>
|
|
<DT><A name="CIDR">CIDR</A></DT>
|
|
<DD><B>C</B>lassless<B> I</B>nter-<B>D</B>omain<B> R</B>outing, an
|
|
addressing scheme used to describe networks not restricted to the old
|
|
Class A, B, and C sizes. A CIDR block is written<VAR> address</VAR>/<VAR>
|
|
mask</VAR>, where<VAR> address</VAR> is a 32-bit Internet address. The
|
|
first<VAR> mask</VAR> bits of<VAR> address</VAR> are part of the
|
|
gateway address, while the remaining bits designate other host
|
|
addresses. For example, the CIDR block 192.0.2.96/27 describes a
|
|
network with gateway 192.0.2.96, hosts 192.0.2.96 through 192.0.2.126
|
|
and broadcast 192.0.2.127.
|
|
<P>FreeS/WAN policy group files accept CIDR blocks of the format<VAR>
|
|
address</VAR>/[<VAR>mask</VAR>], where<VAR> address</VAR> may take the
|
|
form<VAR> name.domain.tld</VAR>. An absent<VAR> mask</VAR> is assumed
|
|
to be /32.</P>
|
|
</DD>
|
|
<DT>Certification Authority</DT>
|
|
<DD>see<A href="#CA"> CA</A></DD>
|
|
<DT><A name="challenge">Challenge-response authentication</A></DT>
|
|
<DD>An<A href="#authentication"> authentication</A> system in which one
|
|
player generates a<A href="#random"> random number</A>, encrypts it and
|
|
sends the result as a challenge. The other player decrypts and sends
|
|
back the result. If the result is correct, that proves to the first
|
|
player that the second player knew the appropriate secret, required for
|
|
the decryption. Variations on this technique exist using<A href="#public">
|
|
public key</A> or<A href="#symmetric"> symmetric</A> cryptography. Some
|
|
provide two-way authentication, assuring each player of the other's
|
|
identity.
|
|
<P>This is more secure than passwords against two simple attacks:</P>
|
|
<UL>
|
|
<LI>If cleartext passwords are sent across the wire (e.g. for telnet),
|
|
an eavesdropper can grab them. The attacker may even be able to break
|
|
into other systems if the user has chosen the same password for them.</LI>
|
|
<LI>If an encrypted password is sent, an attacker can record the
|
|
encrypted form and use it later. This is called a replay attack.</LI>
|
|
</UL>
|
|
<P>A challenge-response system never sends a password, either cleartext
|
|
or encrypted. An attacker cannot record the response to one challenge
|
|
and use it as a response to a later challenge. The random number is
|
|
different each time.</P>
|
|
<P>Of course an attacker might still try to break the cryptographic
|
|
algorithm used, or the<A href="#random"> random number</A> generator.</P>
|
|
</DD>
|
|
<DT><A name="mode">Cipher Modes</A></DT>
|
|
<DD>Different ways of using a block cipher when encrypting multiple
|
|
blocks.
|
|
<P>Four standard modes were defined for<A href="#DES"> DES</A> in<A href="#FIPS">
|
|
FIPS</A> 81. They can actually be applied with any block cipher.</P>
|
|
<TABLE><TBODY></TBODY>
|
|
<TR><TD></TD><TD><A href="#ECB">ECB</A></TD><TD>Electronic CodeBook</TD><TD>
|
|
encrypt each block independently</TD></TR>
|
|
<TR><TD></TD><TD><A href="#CBC">CBC</A></TD><TD>Cipher Block Chaining
|
|
<BR></TD><TD>XOR previous block ciphertext into new block plaintext
|
|
before encrypting new block</TD></TR>
|
|
<TR><TD></TD><TD>CFB</TD><TD>Cipher FeedBack</TD><TD></TD></TR>
|
|
<TR><TD></TD><TD>OFB</TD><TD>Output FeedBack</TD><TD></TD></TR>
|
|
</TABLE>
|
|
<P><A href="#IPSEC">IPsec</A> uses<A href="#CBC"> CBC</A> mode since
|
|
this is only marginally slower than<A href="#ECB"> ECB</A> and is more
|
|
secure. In ECB mode the same plaintext always encrypts to the same
|
|
ciphertext, unless the key is changed. In CBC mode, this does not
|
|
occur.</P>
|
|
<P>Various other modes are also possible, but none of them are used in
|
|
IPsec.</P>
|
|
</DD>
|
|
<DT><A name="ciphertext">Ciphertext</A></DT>
|
|
<DD>The encrypted output of a cipher, as opposed to the unencrypted<A href="#plaintext">
|
|
plaintext</A> input.</DD>
|
|
<DT><A href="http://www.cisco.com">Cisco</A></DT>
|
|
<DD>A vendor of routers, hubs and related products. Their IPsec products
|
|
interoperate with Linux FreeS/WAN; see our<A href="#cisco"> interop</A>
|
|
section.</DD>
|
|
<DT><A name="client">Client</A></DT>
|
|
<DD>This term has at least two distinct uses in discussing IPsec:
|
|
<UL>
|
|
<LI>The<STRONG> clients of an IPsec gateway</STRONG> are the machines it
|
|
protects, typically on one or more subnets behind the gateway. In this
|
|
usage, all the machines on an office network are clients of that
|
|
office's IPsec gateway. Laptop or home machines connecting to the
|
|
office, however, are<EM> not</EM> clients of that gateway. They are
|
|
remote gateways, running the other end of an IPsec connection. Each of
|
|
them is also its own client.</LI>
|
|
<LI><STRONG>IPsec client software</STRONG> is used to describe software
|
|
which runs on various standalone machines to let them connect to IPsec
|
|
networks. In this usage, a laptop or home machine connecting to the
|
|
office is a client, and the office gateway is the server.</LI>
|
|
</UL>
|
|
<P>We generally use the term in the first sense. Vendors of Windows
|
|
IPsec solutions often use it in the second. See this<A href="interop.html#client.server">
|
|
discussion</A>.</P>
|
|
</DD>
|
|
<DT><A name="cc">Common Criteria</A></DT>
|
|
<DD>A set of international security classifications which are replacing
|
|
the old US<A href="#rainbow"> Rainbow Book</A> standards and similar
|
|
standards in other countries.
|
|
<P>Web references include this<A href="http://csrc.nist.gov/cc"> US
|
|
government site</A> and this<A href="http://www.commoncriteria.org">
|
|
global home page</A>.</P>
|
|
</DD>
|
|
<DT>Conventional cryptography</DT>
|
|
<DD>See<A href="#symmetric"> symmetric cryptography</A></DD>
|
|
<DT><A name="collision">Collision resistance</A></DT>
|
|
<DD>The property of a<A href="#digest"> message digest</A> algorithm
|
|
which makes it hard for an attacker to find or construct two inputs
|
|
which hash to the same output.</DD>
|
|
<DT>Copyleft</DT>
|
|
<DD>see GNU<A href="#GPL"> General Public License</A></DD>
|
|
<DT><A name="CSE">CSE</A></DT>
|
|
<DD><A href="http://www.cse-cst.gc.ca/">Communications Security
|
|
Establishment</A>, the Canadian organisation for<A href="#SIGINT">
|
|
signals intelligence</A>.</DD>
|
|
<DT><A name="D">D</A></DT>
|
|
<DT><A name="DARPA">DARPA (sometimes just ARPA)</A></DT>
|
|
<DD>The US government's<B> D</B>efense<B> A</B>dvanced<B> R</B>esearch<B>
|
|
P</B>rojects<B> A</B>gency. Projects they have funded over the years
|
|
have included the Arpanet which evolved into the Internet, the TCP/IP
|
|
protocol suite (as a replacement for the original Arpanet suite), the
|
|
Berkeley 4.x BSD Unix projects, and<A href="#SDNS"> Secure DNS</A>.
|
|
<P>For current information, see their<A href="http://www.darpa.mil/ito">
|
|
web site</A>.</P>
|
|
</DD>
|
|
<DT><A name="DOS">Denial of service (DoS) attack</A></DT>
|
|
<DD>An attack that aims at denying some service to legitimate users of a
|
|
system, rather than providing a service to the attacker.
|
|
<UL>
|
|
<LI>One variant is a flooding attack, overwhelming the system with too
|
|
many packets, to much email, or whatever.</LI>
|
|
<LI>A closely related variant is a resource exhaustion attack. For
|
|
example, consider a "TCP SYN flood" attack. Setting up a TCP connection
|
|
involves a three-packet exchange:
|
|
<UL>
|
|
<LI>Initiator: Connection please (SYN)</LI>
|
|
<LI>Responder: OK (ACK)</LI>
|
|
<LI>Initiator: OK here too</LI>
|
|
</UL>
|
|
<P>If the attacker puts bogus source information in the first packet,
|
|
such that the second is never delivered, the responder may wait a long
|
|
time for the third to come back. If responder has already allocated
|
|
memory for the connection data structures, and if many of these bogus
|
|
packets arrive, the responder may run out of memory.</P>
|
|
</LI>
|
|
<LI>Another variant is to feed the system undigestible data, hoping to
|
|
make it sick. For example, IP packets are limited in size to 64K bytes
|
|
and a fragment carries information on where it starts within that 64K
|
|
and how long it is. The "ping of death" delivers fragments that say,
|
|
for example, that they start at 60K and are 20K long. Attempting to
|
|
re-assemble these without checking for overflow can be fatal.</LI>
|
|
</UL>
|
|
<P>The two example attacks discussed were both quite effective when
|
|
first discovered, capable of crashing or disabling many operating
|
|
systems. They were also well-publicised, and today far fewer systems
|
|
are vulnerable to them.</P>
|
|
</DD>
|
|
<DT><A name="DES">DES</A></DT>
|
|
<DD>The<B> D</B>ata<B> E</B>ncryption<B> S</B>tandard, a<A href="#block">
|
|
block cipher</A> with 64-bit blocks and a 56-bit key. Probably the most
|
|
widely used<A href="#symmetric"> symmetric cipher</A> ever devised. DES
|
|
has been a US government standard for their own use (only for
|
|
unclassified data), and for some regulated industries such as banking,
|
|
since the late 70's. It is now being replaced by<A href="#AES"> AES</A>
|
|
.
|
|
<P><A href="#desnotsecure">DES is seriously insecure against current
|
|
attacks.</A></P>
|
|
<P><A href="#FreeSWAN">Linux FreeS/WAN</A> does not include DES, even
|
|
though the RFCs specify it.<B> We strongly recommend that single DES
|
|
not be used.</B></P>
|
|
<P>See also<A href="#3DES"> 3DES</A> and<A href="#DESX"> DESX</A>,
|
|
stronger ciphers based on DES.</P>
|
|
</DD>
|
|
<DT><A name="DESX">DESX</A></DT>
|
|
<DD>An improved<A href="#DES"> DES</A> suggested by Ron Rivest of RSA
|
|
Data Security. It XORs extra key material into the text before and
|
|
after applying the DES cipher.
|
|
<P>This is not required by the<A href="#IPSEC"> IPsec</A> RFCs and not
|
|
currently used in<A href="#FreeSWAN"> Linux FreeS/WAN</A>. DESX would
|
|
be the easiest additional transform to add; there would be very little
|
|
code to write. It would be much faster than 3DES and almost certainly
|
|
more secure than DES. However, since it is not in the RFCs other IPsec
|
|
implementations cannot be expected to have it.</P>
|
|
</DD>
|
|
<DT>DH</DT>
|
|
<DD>see<A href="#DH"> Diffie-Hellman</A></DD>
|
|
<DT><A name="DHCP">DHCP</A></DT>
|
|
<DD><STRONG>D</STRONG>ynamic<STRONG> H</STRONG>ost<STRONG> C</STRONG>
|
|
onfiguration<STRONG> P</STRONG>rotocol, a method of assigning<A href="#dynamic">
|
|
dynamic IP addresses</A>, and providing additional information such as
|
|
addresses of DNS servers and of gateways. See this<A href="http://www.dhcp.org">
|
|
DHCP resource page.</A></DD>
|
|
<DT><A name="DH">Diffie-Hellman (DH) key exchange protocol</A></DT>
|
|
<DD>A protocol that allows two parties without any initial shared secret
|
|
to create one in a manner immune to eavesdropping. Once they have done
|
|
this, they can communicate privately by using that shared secret as a
|
|
key for a block cipher or as the basis for key exchange.
|
|
<P>The protocol is secure against all<A href="#passive"> passive attacks</A>
|
|
, but it is not at all resistant to active<A href="#middle">
|
|
man-in-the-middle attacks</A>. If a third party can impersonate Bob to
|
|
Alice and vice versa, then no useful secret can be created.
|
|
Authentication of the participants is a prerequisite for safe
|
|
Diffie-Hellman key exchange. IPsec can use any of several<A href="#authentication">
|
|
authentication</A> mechanisims. Those supported by FreeS/WAN are
|
|
discussed in our<A href="#choose"> configuration</A> section.</P>
|
|
<P>The Diffie-Hellman key exchange is based on the<A href="#dlog">
|
|
discrete logarithm</A> problem and is secure unless someone finds an
|
|
efficient solution to that problem.</P>
|
|
<P>Given a prime<VAR> p</VAR> and generator<VAR> g</VAR> (explained
|
|
under<A href="#dlog"> discrete log</A> below), Alice:</P>
|
|
<UL>
|
|
<LI>generates a random number<VAR> a</VAR></LI>
|
|
<LI>calculates<VAR> A = g^a modulo p</VAR></LI>
|
|
<LI>sends<VAR> A</VAR> to Bob</LI>
|
|
</UL>
|
|
<P>Meanwhile Bob:</P>
|
|
<UL>
|
|
<LI>generates a random number<VAR> b</VAR></LI>
|
|
<LI>calculates<VAR> B = g^b modulo p</VAR></LI>
|
|
<LI>sends<VAR> B</VAR> to Alice</LI>
|
|
</UL>
|
|
<P>Now Alice and Bob can both calculate the shared secret<VAR> s =
|
|
g^(ab)</VAR>. Alice knows<VAR> a</VAR> and<VAR> B</VAR>, so she
|
|
calculates<VAR> s = B^a</VAR>. Bob knows<VAR> A</VAR> and<VAR> b</VAR>
|
|
so he calculates<VAR> s = A^b</VAR>.</P>
|
|
<P>An eavesdropper will know<VAR> p</VAR> and<VAR> g</VAR> since these
|
|
are made public, and can intercept<VAR> A</VAR> and<VAR> B</VAR> but,
|
|
short of solving the<A href="#dlog"> discrete log</A> problem, these do
|
|
not let him or her discover the secret<VAR> s</VAR>.</P>
|
|
</DD>
|
|
<DT><A name="signature">Digital signature</A></DT>
|
|
<DD>Sender:
|
|
<UL>
|
|
<LI>calculates a<A href="#digest"> message digest</A> of a document</LI>
|
|
<LI>encrypts the digest with his or her private key, using some<A href="#public">
|
|
public key cryptosystem</A>.</LI>
|
|
<LI>attaches the encrypted digest to the document as a signature</LI>
|
|
</UL>
|
|
<P>Receiver:</P>
|
|
<UL>
|
|
<LI>calculates a digest of the document (not including the signature)</LI>
|
|
<LI>decrypts the signature with the signer's public key</LI>
|
|
<LI>verifies that the two results are identical</LI>
|
|
</UL>
|
|
<P>If the public-key system is secure and the verification succeeds,
|
|
then the receiver knows</P>
|
|
<UL>
|
|
<LI>that the document was not altered between signing and verification</LI>
|
|
<LI>that the signer had access to the private key</LI>
|
|
</UL>
|
|
<P>Such an encrypted message digest can be treated as a signature since
|
|
it cannot be created without<EM> both</EM> the document<EM> and</EM>
|
|
the private key which only the sender should possess. The<A href="#legal">
|
|
legal issues</A> are complex, but several countries are moving in the
|
|
direction of legal recognition for digital signatures.</P>
|
|
</DD>
|
|
<DT><A name="dlog">discrete logarithm problem</A></DT>
|
|
<DD>The problem of finding logarithms in a finite field. Given a field
|
|
defintion (such definitions always include some operation analogous to
|
|
multiplication) and two numbers, a base and a target, find the power
|
|
which the base must be raised to in order to yield the target.
|
|
<P>The discrete log problem is the basis of several cryptographic
|
|
systems, including the<A href="#DH"> Diffie-Hellman</A> key exchange
|
|
used in the<A href="#IKE"> IKE</A> protocol. The useful property is
|
|
that exponentiation is relatively easy but the inverse operation,
|
|
finding the logarithm, is hard. The cryptosystems are designed so that
|
|
the user does only easy operations (exponentiation in the field) but an
|
|
attacker must solve the hard problem (discrete log) to crack the
|
|
system.</P>
|
|
<P>There are several variants of the problem for different types of
|
|
field. The IKE/Oakley key determination protocol uses two variants,
|
|
either over a field modulo a prime or over a field defined by an
|
|
elliptic curve. We give an example modulo a prime below. For the
|
|
elliptic curve version, consult an advanced text such as<A href="#handbook">
|
|
Handbook of Applied Cryptography</A>.</P>
|
|
<P>Given a prime<VAR> p</VAR>, a generator<VAR> g</VAR> for the field
|
|
modulo that prime, and a number<VAR> x</VAR> in the field, the problem
|
|
is to find<VAR> y</VAR> such that<VAR> g^y = x</VAR>.</P>
|
|
<P>For example, let p = 13. The field is then the integers from 0 to 12.
|
|
Any integer equals one of these modulo 13. That is, the remainder when
|
|
any integer is divided by 13 must be one of these.</P>
|
|
<P>2 is a generator for this field. That is, the powers of two modulo 13
|
|
run through all the non-zero numbers in the field. Modulo 13 we have:</P>
|
|
<PRE> y x
|
|
2^0 == 1
|
|
2^1 == 2
|
|
2^2 == 4
|
|
2^3 == 8
|
|
2^4 == 3 that is, the remainder from 16/13 is 3
|
|
2^5 == 6 the remainder from 32/13 is 6
|
|
2^6 == 12 and so on
|
|
2^7 == 11
|
|
2^8 == 9
|
|
2^9 == 5
|
|
2^10 == 10
|
|
2^11 == 7
|
|
2^12 == 1</PRE>
|
|
<P>Exponentiation in such a field is not difficult. Given, say,<NOBR><VAR>
|
|
y = 11</VAR>,calculating<NOBR><VAR> x = 7</VAR>is straightforward. One
|
|
method is just to calculate<NOBR><VAR> 2^11 = 2048</VAR>,then<NOBR><VAR>
|
|
2048 mod 13 == 7</VAR>.When the field is modulo a large prime (say a
|
|
few 100 digits) you need a silghtly cleverer method and even that is
|
|
moderately expensive in computer time, but the calculation is still not
|
|
problematic in any basic way.</P>
|
|
<P>The discrete log problem is the reverse. In our example, given<NOBR><VAR>
|
|
x = 7</VAR>,find the logarithm<NOBR><VAR> y = 11</VAR>.When the field
|
|
is modulo a large prime (or is based on a suitable elliptic curve),
|
|
this is indeed problematic. No solution method that is not
|
|
catastrophically expensive is known. Quite a few mathematicians have
|
|
tackled this problem. No efficient method has been found and
|
|
mathematicians do not expect that one will be. It seems likely no
|
|
efficient solution to either of the main variants the discrete log
|
|
problem exists.</P>
|
|
<P>Note, however, that no-one has proven such methods do not exist. If a
|
|
solution to either variant were found, the security of any crypto
|
|
system using that variant would be destroyed. This is one reason<A href="#IKE">
|
|
IKE</A> supports two variants. If one is broken, we can switch to the
|
|
other.</P>
|
|
</DD>
|
|
<DT><A name="discretionary">discretionary access control</A></DT>
|
|
<DD>access control mechanisms controlled by the user, for example Unix
|
|
rwx file permissions. These contrast with<A href="#mandatory">
|
|
mandatory access controls</A>.</DD>
|
|
<DT><A name="DNS">DNS</A></DT>
|
|
<DD><B>D</B>omain<B> N</B>ame<B> S</B>ervice, a distributed database
|
|
through which names are associated with numeric addresses and other
|
|
information in the Internet Protocol Suite. See also the<A href="#dns.background">
|
|
DNS background</A> section of our documentation.</DD>
|
|
<DT>DOS attack</DT>
|
|
<DD>see<A href="#DOS"> Denial Of Service</A> attack</DD>
|
|
<DT><A name="dynamic">dynamic IP address</A></DT>
|
|
<DD>an IP address which is automatically assigned, either by<A href="#DHCP">
|
|
DHCP</A> or by some protocol such as<A href="#PPP"> PPP</A> or<A href="#PPPoE">
|
|
PPPoE</A> which the machine uses to connect to the Internet. This is
|
|
the opposite of a<A href="#static"> static IP address</A>, pre-set on
|
|
the machine itself.</DD>
|
|
<DT><A name="E">E</A></DT>
|
|
<DT><A name="EAR">EAR</A></DT>
|
|
<DD>The US government's<B> E</B>xport<B> A</B>dministration<B> R</B>
|
|
egulations, administered by the<A href="#BXA"> Bureau of Export
|
|
Administration</A>. These have replaced the earlier<A href="#ITAR">
|
|
ITAR</A> regulations as the controls on export of cryptography.</DD>
|
|
<DT><A name="ECB">ECB mode</A></DT>
|
|
<DD><B>E</B>lectronic<B> C</B>ode<B>B</B>ook mode, the simplest way to
|
|
use a block cipher. See<A href="#mode"> Cipher Modes</A>.</DD>
|
|
<DT><A name="EDE">EDE</A></DT>
|
|
<DD>The sequence of operations normally used in either the three-key
|
|
variant of<A href="#3DES"> triple DES</A> used in<A href="#IPSEC">
|
|
IPsec</A> or the<A href="#2key"> two-key</A> variant used in some other
|
|
systems.
|
|
<P>The sequence is:</P>
|
|
<UL>
|
|
<LI><B>E</B>ncrypt with key1</LI>
|
|
<LI><B>D</B>ecrypt with key2</LI>
|
|
<LI><B>E</B>ncrypt with key3</LI>
|
|
</UL>
|
|
<P>For the two-key version, key1=key3.</P>
|
|
<P>The "advantage" of this EDE order of operations is that it makes it
|
|
simple to interoperate with older devices offering only single DES. Set
|
|
key1=key2=key3 and you have the worst of both worlds, the overhead of
|
|
triple DES with the "security" of single DES. Since both the<A href="#desnotsecure">
|
|
security of single DES</A> and the overheads of triple DES are
|
|
seriously inferior to many other ciphers, this is a spectacularly
|
|
dubious "advantage".</P>
|
|
</DD>
|
|
<DT><A name="Entrust">Entrust</A></DT>
|
|
<DD>A Canadian company offerring enterprise<A href="#PKI"> PKI</A>
|
|
products using<A href="#CAST128"> CAST-128</A> symmetric crypto,<A href="#RSA">
|
|
RSA</A> public key and<A href="#X509"> X.509</A> directories.<A href="http://www.entrust.com">
|
|
Web site</A></DD>
|
|
<DT><A name="EFF">EFF</A></DT>
|
|
<DD><A href="http://www.eff.org">Electronic Frontier Foundation</A>, an
|
|
advocacy group for civil rights in cyberspace.</DD>
|
|
<DT><A name="encryption">Encryption</A></DT>
|
|
<DD>Techniques for converting a readable message (<A href="#plaintext">
|
|
plaintext</A>) into apparently random material (<A href="#ciphertext">
|
|
ciphertext</A>) which cannot be read if intercepted. A key is required
|
|
to read the message.
|
|
<P>Major variants include<A href="#symmetric"> symmetric</A> encryption
|
|
in which sender and receiver use the same secret key and<A href="#public">
|
|
public key</A> methods in which the sender uses one of a matched pair
|
|
of keys and the receiver uses the other. Many current systems,
|
|
including<A href="#IPSEC"> IPsec</A>, are<A href="#hybrid"> hybrids</A>
|
|
combining the two techniques.</P>
|
|
</DD>
|
|
<DT><A name="ESP">ESP</A></DT>
|
|
<DD><B>E</B>ncapsulated<B> S</B>ecurity<B> P</B>ayload, the<A href="#IPSEC">
|
|
IPsec</A> protocol which provides<A href="#encryption"> encryption</A>.
|
|
It can also provide<A href="#authentication"> authentication</A>
|
|
service and may be used with null encryption (which we do not
|
|
recommend). For details see our<A href="#ESP.ipsec"> IPsec</A> document
|
|
and/or RFC 2406.</DD>
|
|
<DT><A name="#extruded">Extruded subnet</A></DT>
|
|
<DD>A situation in which something IP sees as one network is actually in
|
|
two or more places.
|
|
<P>For example, the Internet may route all traffic for a particular
|
|
company to that firm's corporate gateway. It then becomes the company's
|
|
problem to get packets to various machines on their<A href="#subnet">
|
|
subnets</A> in various departments. They may decide to treat a branch
|
|
office like a subnet, giving it IP addresses "on" their corporate net.
|
|
This becomes an extruded subnet.</P>
|
|
<P>Packets bound for it are delivered to the corporate gateway, since as
|
|
far as the outside world is concerned, that subnet is part of the
|
|
corporate network. However, instead of going onto the corporate LAN (as
|
|
they would for, say, the accounting department) they are then
|
|
encapsulated and sent back onto the Internet for delivery to the branch
|
|
office.</P>
|
|
<P>For information on doing this with Linux FreeS/WAN, look in our<A href="#extruded.config">
|
|
advanced configuration</A> section.</P>
|
|
</DD>
|
|
<DT>Exhaustive search</DT>
|
|
<DD>See<A href="#brute"> brute force attack</A>.</DD>
|
|
<DT><A name="F">F</A></DT>
|
|
<DT><A name="FIPS">FIPS</A></DT>
|
|
<DD><B>F</B>ederal<B> I</B>nformation<B> P</B>rocessing<B> S</B>tandard,
|
|
the US government's standards for products it buys. These are issued by<A
|
|
href="#NIST"> NIST</A>. Among other things,<A href="#DES"> DES</A> and<A href="#SHA">
|
|
SHA</A> are defined in FIPS documents. NIST have a<A href="http://www.itl.nist.gov/div897/pubs">
|
|
FIPS home page</A>.</DD>
|
|
<DT><A name="FSF">Free Software Foundation (FSF)</A></DT>
|
|
<DD>An organisation to promote free software, free in the sense of these
|
|
quotes from their web pages</DD>
|
|
<DD><BLOCKQUOTE> "Free software" is a matter of liberty, not price. To
|
|
understand the concept, you should think of "free speech", not "free
|
|
beer."
|
|
<P>"Free software" refers to the users' freedom to run, copy,
|
|
distribute, study, change and improve the software.</P>
|
|
</BLOCKQUOTE>
|
|
<P>See also<A href="#GNU"> GNU</A>,<A href="#GPL"> GNU General Public
|
|
License</A>, and<A href="http://www.fsf.org"> the FSF site</A>.</P>
|
|
</DD>
|
|
<DT>FreeS/WAN</DT>
|
|
<DD>see<A href="#FreeSWAN"> Linux FreeS/WAN</A></DD>
|
|
<DT><A name="fullnet">Fullnet</A></DT>
|
|
<DD>The CIDR block containing all IPs of its IP version. The<A HREF="#IPv4">
|
|
IPv4</A> fullnet is written 0.0.0.0/0. Also known as "all" and
|
|
"default", fullnet may be used in a routing table to specify a default
|
|
route, and in a FreeS/WAN<A HREF="#policygroups"> policy group</A> file
|
|
to specify a default IPsec policy.</DD>
|
|
<DT>FSF</DT>
|
|
<DD>see<A href="#FSF"> Free software Foundation</A></DD>
|
|
<DT><A name="G">G</A></DT>
|
|
<DT><A name="GCHQ">GCHQ</A></DT>
|
|
<DD><A href="http://www.gchq.gov.uk">Government Communications
|
|
Headquarters</A>, the British organisation for<A href="#SIGINT">
|
|
signals intelligence</A>.</DD>
|
|
<DT>generator of a prime field</DT>
|
|
<DD>see<A href="#dlog"> discrete logarithm problem</A></DD>
|
|
<DT><A name="GILC">GILC</A></DT>
|
|
<DD><A href="http://www.gilc.org">Global Internet Liberty Campaign</A>,
|
|
an international organisation advocating, among other things, free
|
|
availability of cryptography. They have a<A href="http://www.gilc.org/crypto/wassenaar">
|
|
campaign</A> to remove cryptographic software from the<A href="#Wassenaar.gloss">
|
|
Wassenaar Arrangement</A>.</DD>
|
|
<DT>Global Internet Liberty Campaign</DT>
|
|
<DD>see<A href="#GILC"> GILC</A>.</DD>
|
|
<DT><A name="GTR">Global Trust Register</A></DT>
|
|
<DD>An attempt to create something like a<A href="#rootCA"> root CA</A>
|
|
for<A href="#PGP"> PGP</A> by publishing both<A href="#GTR"> as a book</A>
|
|
and<A href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register">
|
|
on the web</A> the fingerprints of a set of verified keys for
|
|
well-known users and organisations.</DD>
|
|
<DT><A name="GMP">GMP</A></DT>
|
|
<DD>The<B> G</B>NU<B> M</B>ulti-<B>P</B>recision library code, used in<A href="#FreeSWAN">
|
|
Linux FreeS/WAN</A> by<A href="#Pluto"> Pluto</A> for<A href="#public">
|
|
public key</A> calculations. See the<A href="http://www.swox.com/gmp">
|
|
GMP home page</A>.</DD>
|
|
<DT><A name="GNU">GNU</A></DT>
|
|
<DD><B>G</B>NU's<B> N</B>ot<B> U</B>nix, the<A href="#FSF"> Free
|
|
Software Foundation's</A> project aimed at creating a free system with
|
|
at least the capabilities of Unix.<A href="#Linux"> Linux</A> uses GNU
|
|
utilities extensively.</DD>
|
|
<DT><A name="#GOST">GOST</A></DT>
|
|
<DD>a Soviet government standard<A href="#block"> block cipher</A>.<A href="#schneier">
|
|
Applied Cryptography</A> has details.</DD>
|
|
<DT>GPG</DT>
|
|
<DD>see<A href="#GPG"> GNU Privacy Guard</A></DD>
|
|
<DT><A name="GPL">GNU General Public License</A>(GPL, copyleft)</DT>
|
|
<DD>The license developed by the<A href="#FSF"> Free Software Foundation</A>
|
|
under which<A href="#Linux"> Linux</A>,<A href="#FreeSWAN"> Linux
|
|
FreeS/WAN</A> and many other pieces of software are distributed. The
|
|
license allows anyone to redistribute and modify the code, but forbids
|
|
anyone from distributing executables without providing access to source
|
|
code. For more details see the file<A href="../COPYING"> COPYING</A>
|
|
included with GPLed source distributions, including ours, or<A href="http://www.fsf.org/copyleft/gpl.html">
|
|
the GNU site's GPL page</A>.</DD>
|
|
<DT><A name="GPG">GNU Privacy Guard</A></DT>
|
|
<DD>An open source implementation of Open<A href="#PGP"> PGP</A> as
|
|
defined in RFC 2440. See their<A href="http://www.gnupg.org"> web site</A>
|
|
</DD>
|
|
<DT>GPL</DT>
|
|
<DD>see<A href="#GPL"> GNU General Public License</A>.</DD>
|
|
<DT><A name="H">H</A></DT>
|
|
<DT><A name="hash">Hash</A></DT>
|
|
<DD>see<A href="#digest"> message digest</A></DD>
|
|
<DT><A name="HMAC">Hashed Message Authentication Code (HMAC)</A></DT>
|
|
<DD>using keyed<A href="#digest"> message digest</A> functions to
|
|
authenticate a message. This differs from other uses of these
|
|
functions:
|
|
<UL>
|
|
<LI>In normal usage, the hash function's internal variable are
|
|
initialised in some standard way. Anyone can reproduce the hash to
|
|
check that the message has not been altered.</LI>
|
|
<LI>For HMAC usage, you initialise the internal variables from the key.
|
|
Only someone with the key can reproduce the hash. A successful check of
|
|
the hash indicates not only that the message is unchanged but also that
|
|
the creator knew the key.</LI>
|
|
</UL>
|
|
<P>The exact techniques used in<A href="#IPSEC"> IPsec</A> are defined
|
|
in RFC 2104. They are referred to as HMAC-MD5-96 and HMAC-SHA-96
|
|
because they output only 96 bits of the hash. This makes some attacks
|
|
on the hash functions harder.</P>
|
|
</DD>
|
|
<DT>HMAC</DT>
|
|
<DD>see<A href="#HMAC"> Hashed Message Authentication Code</A></DD>
|
|
<DT>HMAC-MD5-96</DT>
|
|
<DD>see<A href="#HMAC"> Hashed Message Authentication Code</A></DD>
|
|
<DT>HMAC-SHA-96</DT>
|
|
<DD>see<A href="#HMAC"> Hashed Message Authentication Code</A></DD>
|
|
<DT><A name="hybrid">Hybrid cryptosystem</A></DT>
|
|
<DD>A system using both<A href="#public"> public key</A> and<A href="#symmetric">
|
|
symmetric cipher</A> techniques. This works well. Public key methods
|
|
provide key management and<A href="#signature"> digital signature</A>
|
|
facilities which are not readily available using symmetric ciphers. The
|
|
symmetric cipher, however, can do the bulk of the encryption work much
|
|
more efficiently than public key methods.</DD>
|
|
<DT><A name="I">I</A></DT>
|
|
<DT><A name="IAB">IAB</A></DT>
|
|
<DD><A href="http://www.iab.org/iab">Internet Architecture Board</A>.</DD>
|
|
<DT><A name="ICMP.gloss">ICMP</A></DT>
|
|
<DD><STRONG>I</STRONG>nternet<STRONG> C</STRONG>ontrol<STRONG> M</STRONG>
|
|
essage<STRONG> P</STRONG>rotocol. This is used for various IP-connected
|
|
devices to manage the network.</DD>
|
|
<DT><A name="IDEA">IDEA</A></DT>
|
|
<DD><B>I</B>nternational<B> D</B>ata<B> E</B>ncrypion<B> A</B>lgorithm,
|
|
developed in Europe as an alternative to exportable American ciphers
|
|
such as<A href="#DES"> DES</A> which were<A href="#desnotsecure"> too
|
|
weak for serious use</A>. IDEA is a<A href="#block"> block cipher</A>
|
|
using 64-bit blocks and 128-bit keys, and is used in products such as<A href="#PGP">
|
|
PGP</A>.
|
|
<P>IDEA is not required by the<A href="#IPSEC"> IPsec</A> RFCs and not
|
|
currently used in<A href="#FreeSWAN"> Linux FreeS/WAN</A>.</P>
|
|
<P>IDEA is patented and, with strictly limited exceptions for personal
|
|
use, using it requires a license from<A href="http://www.ascom.com">
|
|
Ascom</A>.</P>
|
|
</DD>
|
|
<DT><A name="IEEE">IEEE</A></DT>
|
|
<DD><A href="http://www.ieee.org">Institute of Electrical and Electronic
|
|
Engineers</A>, a professional association which, among other things,
|
|
sets some technical standards</DD>
|
|
<DT><A name="IESG">IESG</A></DT>
|
|
<DD><A href="http://www.iesg.org">Internet Engineering Steering Group</A>
|
|
.</DD>
|
|
<DT><A name="IETF">IETF</A></DT>
|
|
<DD><A href="http://www.ietf.org">Internet Engineering Task Force</A>,
|
|
the umbrella organisation whose various working groups make most of the
|
|
technical decisions for the Internet. The IETF<A href="http://www.ietf.org/html.charters/ipsec-charter.html">
|
|
IPsec working group</A> wrote the<A href="#RFC"> RFCs</A> we are
|
|
implementing.</DD>
|
|
<DT><A name="IKE">IKE</A></DT>
|
|
<DD><B>I</B>nternet<B> K</B>ey<B> E</B>xchange, based on the<A href="#DH">
|
|
Diffie-Hellman</A> key exchange protocol. For details, see RFC 2409 and
|
|
our<A href="ipsec.html"> IPsec</A> document. IKE is implemented in<A href="#FreeSWAN">
|
|
Linux FreeS/WAN</A> by the<A href="#Pluto"> Pluto daemon</A>.</DD>
|
|
<DT>IKE v2</DT>
|
|
<DD>A proposed replacement for<A href="#IKE"> IKE</A>. There are other
|
|
candidates, such as<A href="#JFK"> JFK</A>, and at time of writing
|
|
(March 2002) the choice between them has not yet been made and does not
|
|
appear imminent.</DD>
|
|
<DT><A name="iOE">iOE</A></DT>
|
|
<DD>See<A HREF="#initiate-only"> Initiate-only opportunistic encryption</A>
|
|
.</DD>
|
|
<DT><A name="IP">IP</A></DT>
|
|
<DD><B>I</B>nternet<B> P</B>rotocol.</DD>
|
|
<DT><A name="masq">IP masquerade</A></DT>
|
|
<DD>A mostly obsolete term for a method of allowing multiple machines to
|
|
communicate over the Internet when only one IP address is available for
|
|
their use. The more current term is Network Address Translation or<A href="#NAT.gloss">
|
|
NAT</A>.</DD>
|
|
<DT><A name="IPng">IPng</A></DT>
|
|
<DD>"IP the Next Generation", see<A href="#ipv6.gloss"> IPv6</A>.</DD>
|
|
<DT><A name="IPv4">IPv4</A></DT>
|
|
<DD>The current version of the<A href="#IP"> Internet protocol suite</A>
|
|
.</DD>
|
|
<DT><A name="ipv6.gloss">IPv6 (IPng)</A></DT>
|
|
<DD>Version six of the<A href="#IP"> Internet protocol suite</A>,
|
|
currently being developed. It will replace the current<A href="#IPv4">
|
|
version four</A>. IPv6 has<A href="#IPSEC"> IPsec</A> as a mandatory
|
|
component.
|
|
<P>See this<A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">
|
|
web site</A> for more details, and our<A href="#ipv6"> compatibility</A>
|
|
document for information on FreeS/WAN and the Linux implementation of
|
|
IPv6.</P>
|
|
</DD>
|
|
<DT><A name="IPSEC">IPsec</A> or IPSEC</DT>
|
|
<DD><B>I</B>nternet<B> P</B>rotocol<B> SEC</B>urity, security functions
|
|
(<A href="#authentication">authentication</A> and<A href="#encryption">
|
|
encryption</A>) implemented at the IP level of the protocol stack. It
|
|
is optional for<A href="#IPv4"> IPv4</A> and mandatory for<A href="#ipv6.gloss">
|
|
IPv6</A>.
|
|
<P>This is the standard<A href="#FreeSWAN"> Linux FreeS/WAN</A> is
|
|
implementing. For more details, see our<A href="ipsec.html"> IPsec
|
|
Overview</A>. For the standards, see RFCs listed in our<A href="#RFC">
|
|
RFCs document</A>.</P>
|
|
</DD>
|
|
<DT><A name="IPX">IPX</A></DT>
|
|
<DD>Novell's Netware protocol tunnelled over an IP link. Our<A href="#user.scripts">
|
|
firewalls</A> document includes an example of using this through an
|
|
IPsec tunnel.</DD>
|
|
<DT><A name="ISAKMP">ISAKMP</A></DT>
|
|
<DD><B>I</B>nternet<B> S</B>ecurity<B> A</B>ssociation and<B> K</B>ey<B>
|
|
M</B>anagement<B> P</B>rotocol, defined in RFC 2408.</DD>
|
|
<DT><A name="ITAR">ITAR</A></DT>
|
|
<DD><B>I</B>nternational<B> T</B>raffic in<B> A</B>rms<B> R</B>
|
|
egulations, US regulations administered by the State Department which
|
|
until recently limited export of, among other things, cryptographic
|
|
technology and software. ITAR still exists, but the limits on
|
|
cryptography have now been transferred to the<A href="#EAR"> Export
|
|
Administration Regulations</A> under the Commerce Department's<A href="#BXA">
|
|
Bureau of Export Administration</A>.</DD>
|
|
<DT>IV</DT>
|
|
<DD>see<A href="#IV"> Initialisation vector</A></DD>
|
|
<DT><A name="IV">Initialisation Vector (IV)</A></DT>
|
|
<DD>Some cipher<A href="#mode"> modes</A>, including the<A href="#CBC">
|
|
CBC</A> mode which IPsec uses, require some extra data at the
|
|
beginning. This data is called the initialisation vector. It need not
|
|
be secret, but should be different for each message. Its function is to
|
|
prevent messages which begin with the same text from encrypting to the
|
|
same ciphertext. That might give an analyst an opening, so it is best
|
|
prevented.</DD>
|
|
<DT><A name="initiate-only">Initiate-only opportunistic encryption (iOE)</A>
|
|
</DT>
|
|
<DD>A form of<A HREF="#carpediem"> opportunistic encryption</A> (OE) in
|
|
which a host proposes opportunistic connections, but lacks the reverse
|
|
DNS records necessary to support incoming opportunistic connection
|
|
requests. Common among hosts on cable or pppoe connections where the
|
|
system administrator does not have write access to the DNS reverse map
|
|
for the host's external IP.
|
|
<P>Configuring for initiate-only opportunistic encryption is described
|
|
in our<A href="#opp.client"> quickstart</A> document.</P>
|
|
</DD>
|
|
<DT><A name="J">J</A></DT>
|
|
<DT><A name="JFK">JFK</A></DT>
|
|
<DD><STRONG>J</STRONG>ust<STRONG> F</STRONG>ast<STRONG> K</STRONG>eying,
|
|
a proposed simpler replacement for<A href="#IKE"> IKE.</A></DD>
|
|
<DT><A name="K">K</A></DT>
|
|
<DT><A name="kernel">Kernel</A></DT>
|
|
<DD>The basic part of an operating system (e.g. Linux) which controls
|
|
the hardware and provides services to all other programs.
|
|
<P>In the Linux release numbering system, an even second digit as in 2.<STRONG>
|
|
2</STRONG>.x indicates a stable or production kernel while an odd number
|
|
as in 2.<STRONG>3</STRONG>.x indicates an experimental or development
|
|
kernel. Most users should run a recent kernel version from the
|
|
production series. The development kernels are primarily for people
|
|
doing kernel development. Others should consider using development
|
|
kernels only if they have an urgent need for some feature not yet
|
|
available in production kernels.</P>
|
|
</DD>
|
|
<DT>Keyed message digest</DT>
|
|
<DD>See<A href="#HMAC"> HMAC</A>.</DD>
|
|
<DT>Key length</DT>
|
|
<DD>see<A href="#brute"> brute force attack</A></DD>
|
|
<DT><A name="KLIPS">KLIPS</A></DT>
|
|
<DD><B>K</B>erne<B>l</B><B> IP</B><B> S</B>ecurity, the<A href="#FreeSWAN">
|
|
Linux FreeS/WAN</A> project's changes to the<A href="#Linux"> Linux</A>
|
|
kernel to support the<A href="#IPSEC"> IPsec</A> protocols.</DD>
|
|
<DT><A name="L">L</A></DT>
|
|
<DT><A name="LDAP">LDAP</A></DT>
|
|
<DD><B>L</B>ightweight<B> D</B>irectory<B> A</B>ccess<B> P</B>rotocol,
|
|
defined in RFCs 1777 and 1778, a method of accessing information stored
|
|
in directories. LDAP is used by several<A href="#PKI"> PKI</A>
|
|
implementations, often with X.501 directories and<A href="#X509"> X.509</A>
|
|
certificates. It may also be used by<A href="#IPSEC"> IPsec</A> to
|
|
obtain key certifications from those PKIs. This is not yet implemented
|
|
in<A href="#FreeSWAN"> Linux FreeS/WAN</A>.</DD>
|
|
<DT><A name="LIBDES">LIBDES</A></DT>
|
|
<DD>A publicly available library of<A href="#DES"> DES</A> code, written
|
|
by Eric Young, which<A href="#FreeSWAN"> Linux FreeS/WAN</A> uses in
|
|
both<A href="#KLIPS"> KLIPS</A> and<A href="#Pluto"> Pluto</A>.</DD>
|
|
<DT><A name="Linux">Linux</A></DT>
|
|
<DD>A freely available Unix-like operating system based on a kernel
|
|
originally written for the Intel 386 architecture by (then) student
|
|
Linus Torvalds. Once his 32-bit kernel was available, the<A href="#GNU">
|
|
GNU</A> utilities made it a usable system and contributions from many
|
|
others led to explosive growth.
|
|
<P>Today Linux is a complete Unix replacement available for several CPU
|
|
architectures -- Intel, DEC/Compaq Alpha, Power PC, both 32-bit SPARC
|
|
and the 64-bit UltraSPARC, SrongARM, . . . -- with support for multiple
|
|
CPUs on some architectures.</P>
|
|
<P><A href="#FreeSWAN">Linux FreeS/WAN</A> is intended to run on all
|
|
CPUs supported by Linux and is known to work on several. See our<A href="#CPUs">
|
|
compatibility</A> section for a list.</P>
|
|
</DD>
|
|
<DT><A name="FreeSWAN">Linux FreeS/WAN</A></DT>
|
|
<DD>Our implementation of the<A href="#IPSEC"> IPsec</A> protocols,
|
|
intended to be freely redistributable source code with<A href="#GPL"> a
|
|
GNU GPL license</A> and no constraints under US or other<A href="#exlaw">
|
|
export laws</A>. Linux FreeS/WAN is intended to interoperate with other<A
|
|
href="#IPSEC"> IPsec</A> implementations. The name is partly taken, with
|
|
permission, from the<A href="#SWAN"> S/WAN</A> multi-vendor IPsec
|
|
compatability effort. Linux FreeS/WAN has two major components,<A href="#KLIPS">
|
|
KLIPS</A> (KerneL IPsec Support) and the<A href="#Pluto"> Pluto</A>
|
|
daemon which manages the whole thing.
|
|
<P>See our<A href="ipsec.html"> IPsec section</A> for more detail. For
|
|
the code see our<A href="http://freeswan.org"> primary site</A> or one
|
|
of the mirror sites on<A href="#mirrors"> this list</A>.</P>
|
|
</DD>
|
|
<DT><A name="LSM">Linux Security Modules (LSM)</A></DT>
|
|
<DD>a project to create an interface in the Linux kernel that supports
|
|
plug-in modules for various security policies.
|
|
<P>This allows multiple security projects to take different approaches
|
|
to security enhancement without tying the kernel down to one particular
|
|
approach. As I understand the history, several projects were pressing
|
|
Linus to incorporate their changes, the various sets of changes were
|
|
incompatible, and his answer was more-or-less "a plague on all your
|
|
houses; I'll give you an interface, but I won't incorporate anything".</P>
|
|
<P>It seems to be working. There is a fairly active<A href="http://mail.wirex.com/mailman/listinfo/linux-security-module">
|
|
LSM mailing list</A>, and several projects are already using the
|
|
interface.</P>
|
|
</DD>
|
|
<DT>LSM</DT>
|
|
<DD>see<A href="#LSM"> Linux Security Modules</A></DD>
|
|
<DT><A name="M">M</A></DT>
|
|
<DT><A name="list">Mailing list</A></DT>
|
|
<DD>The<A href="#FreeSWAN"> Linux FreeS/WAN</A> project has several
|
|
public email lists for bug reports and software development
|
|
discussions. See our document on<A href="mail.html"> mailing lists</A>.</DD>
|
|
<DT><A name="middle">Man-in-the-middle attack</A></DT>
|
|
<DD>An<A href="#active"> active attack</A> in which the attacker
|
|
impersonates each of the legitimate players in a protocol to the other.
|
|
<P>For example, if<A href="#alicebob"> Alice and Bob</A> are negotiating
|
|
a key via the<A href="#DH"> Diffie-Hellman</A> key agreement, and are
|
|
not using<A href="#authentication"> authentication</A> to be certain
|
|
they are talking to each other, then an attacker able to insert himself
|
|
in the communication path can deceive both players.</P>
|
|
<P>Call the attacker Mallory. For Bob, he pretends to be Alice. For
|
|
Alice, he pretends to be Bob. Two keys are then negotiated,
|
|
Alice-to-Mallory and Bob-to-Mallory. Alice and Bob each think the key
|
|
they have is Alice-to-Bob.</P>
|
|
<P>A message from Alice to Bob then goes to Mallory who decrypts it,
|
|
reads it and/or saves a copy, re-encrypts using the Bob-to-Mallory key
|
|
and sends it along to Bob. Bob decrypts successfully and sends a reply
|
|
which Mallory decrypts, reads, re-encrypts and forwards to Alice.</P>
|
|
<P>To make this attack effective, Mallory must</P>
|
|
<UL>
|
|
<LI>subvert some part of the network in some way that lets him carry out
|
|
the deception
|
|
<BR> possible targets: DNS, router, Alice or Bob's machine, mail server,
|
|
...</LI>
|
|
<LI>beat any authentication mechanism Alice and Bob use
|
|
<BR> strong authentication defeats the attack entirely; this is why<A href="#IKE">
|
|
IKE</A> requires authentication</LI>
|
|
<LI>work in real time, delivering messages without introducing a delay
|
|
large enough to alert the victims
|
|
<BR> not hard if Alice and Bob are using email; quite difficult in some
|
|
situations.</LI>
|
|
</UL>
|
|
<P>If he manages it, however, it is devastating. He not only gets to
|
|
read all the messages; he can alter messages, inject his own, forge
|
|
anything he likes, . . . In fact, he controls the communication
|
|
completely.</P>
|
|
</DD>
|
|
<DT><A name="mandatory">mandatory access control</A></DT>
|
|
<DD>access control mechanisims which are not settable by the user (see<A href="#discretionary">
|
|
discretionary access control</A>), but are enforced by the system.
|
|
<P>For example, a document labelled "secret, zebra" might be readable
|
|
only by someone with secret clearance working on Project Zebra.
|
|
Ideally, the system will prevent any transfer outside those boundaries.
|
|
For example, even if you can read it, you should not be able to e-mail
|
|
it (unless the recipient is appropriately cleared) or print it (unless
|
|
certain printers are authorised for that classification).</P>
|
|
<P>Mandatory access control is a required feature for some levels of<A href="#rainbow">
|
|
Rainbow Book</A> or<A href="#cc"> Common Criteria</A> classification,
|
|
but has not been widely used outside the military and government. There
|
|
is a good discussion of the issues in Anderson's<A href="#anderson">
|
|
Security Engineering</A>.</P>
|
|
<P>The<A href="#SElinux"> Security Enhanced Linux</A> project is adding
|
|
mandatory access control to Linux.</P>
|
|
</DD>
|
|
<DT><A name="manual">Manual keying</A></DT>
|
|
<DD>An IPsec mode in which the keys are provided by the administrator.
|
|
In FreeS/WAN, they are stored in /etc/ipsec.conf. The alternative,<A href="#auto">
|
|
automatic keying</A>, is preferred in most cases. See this<A href="#man-auto">
|
|
discussion</A>.</DD>
|
|
<DT><A name="MD4">MD4</A></DT>
|
|
<DD><A href="#digest">Message Digest Algorithm</A> Four from Ron Rivest
|
|
of<A href="#RSAco"> RSA</A>. MD4 was widely used a few years ago, but
|
|
is now considered obsolete. It has been replaced by its descendants<A href="#MD5">
|
|
MD5</A> and<A href="#SHA"> SHA</A>.</DD>
|
|
<DT><A name="MD5">MD5</A></DT>
|
|
<DD><A href="#digest">Message Digest Algorithm</A> Five from Ron Rivest
|
|
of<A href="#RSAco"> RSA</A>, an improved variant of his<A href="#MD4">
|
|
MD4</A>. Like MD4, it produces a 128-bit hash. For details see RFC
|
|
1321.
|
|
<P>MD5 is one of two message digest algorithms available in IPsec. The
|
|
other is<A href="#SHA"> SHA</A>. SHA produces a longer hash and is
|
|
therefore more resistant to<A href="#birthday"> birthday attacks</A>,
|
|
but this is not a concern for IPsec. The<A href="#HMAC"> HMAC</A>
|
|
method used in IPsec is secure even if the underlying hash is not
|
|
particularly strong against this attack.</P>
|
|
<P>Hans Dobbertin found a weakness in MD5, and people often ask whether
|
|
this means MD5 is unsafe for IPsec. It doesn't. The IPsec RFCs discuss
|
|
Dobbertin's attack and conclude that it does not affect MD5 as used for
|
|
HMAC in IPsec.</P>
|
|
</DD>
|
|
<DT><A name="meet">Meet-in-the-middle attack</A></DT>
|
|
<DD>A divide-and-conquer attack which breaks a cipher into two parts,
|
|
works against each separately, and compares results. Probably the best
|
|
known example is an attack on double DES. This applies in principle to
|
|
any pair of block ciphers, e.g. to an encryption system using, say,
|
|
CAST-128 and Blowfish, but we will describe it for double DES.
|
|
<P>Double DES encryption and decryption can be written:</P>
|
|
<PRE> C = E(k2,E(k1,P))
|
|
P = D(k1,D(k2,C))</PRE>
|
|
<P>Where C is ciphertext, P is plaintext, E is encryption, D is
|
|
decryption, k1 is one key, and k2 is the other key. If we know a P, C
|
|
pair, we can try and find the keys with a brute force attack, trying
|
|
all possible k1, k2 pairs. Since each key is 56 bits, there are 2<SUP>
|
|
112</SUP> such pairs and this attack is painfully inefficient.</P>
|
|
<P>The meet-in-the middle attack re-writes the equations to calculate a
|
|
middle value M:</P>
|
|
<PRE> M = E(k1,P)
|
|
M = D(k2,C)</PRE>
|
|
<P>Now we can try some large number of D(k2,C) decryptions with various
|
|
values of k2 and store the results in a table. Then start doing E(k1,P)
|
|
encryptions, checking each result to see if it is in the table.</P>
|
|
<P>With enough table space, this breaks double DES with<NOBR> 2<SUP>56</SUP>
|
|
+ 2<SUP>56</SUP> = 2<SUP>57</SUP>work. Against triple DES, you need<NOBR>
|
|
2<SUP>56</SUP> + 2<SUP>112</SUP> ~= 2<SUP>112</SUP>.</P>
|
|
<P>The memory requirements for such attacks can be prohibitive, but
|
|
there is a whole body of research literature on methods of reducing
|
|
them.</P>
|
|
</DD>
|
|
<DT><A name="digest">Message Digest Algorithm</A></DT>
|
|
<DD>An algorithm which takes a message as input and produces a hash or
|
|
digest of it, a fixed-length set of bits which depend on the message
|
|
contents in some highly complex manner. Design criteria include making
|
|
it extremely difficult for anyone to counterfeit a digest or to change
|
|
a message without altering its digest. One essential property is<A href="#collision">
|
|
collision resistance</A>. The main applications are in message<A href="#authentication">
|
|
authentication</A> and<A href="#signature"> digital signature</A>
|
|
schemes. Widely used algorithms include<A href="#MD5"> MD5</A> and<A href="#SHA">
|
|
SHA</A>. In IPsec, message digests are used for<A href="#HMAC"> HMAC</A>
|
|
authentication of packets.</DD>
|
|
<DT><A name="MTU">MTU</A></DT>
|
|
<DD><STRONG>M</STRONG>aximum<STRONG> T</STRONG>ransmission<STRONG> U</STRONG>
|
|
nit, the largest size of packet that can be sent over a link. This is
|
|
determined by the underlying network, but must be taken account of at
|
|
the IP level.
|
|
<P>IP packets, which can be up to 64K bytes each, must be packaged into
|
|
lower-level packets of the appropriate size for the underlying
|
|
network(s) and re-assembled on the other end. When a packet must pass
|
|
over multiple networks, each with its own MTU, and many of the MTUs are
|
|
unknown to the sender, this becomes a fairly complex problem. See<A href="#pathMTU">
|
|
path MTU discovery</A> for details.</P>
|
|
<P>Often the MTU is a few hundred bytes on serial links and 1500 on
|
|
Ethernet. There are, however, serial link protocols which use a larger
|
|
MTU to avoid fragmentation at the ethernet/serial boundary, and newer
|
|
(especially gigabit) Ethernet networks sometimes support much larger
|
|
packets because these are more efficient in some applications.</P>
|
|
</DD>
|
|
<DT><A name="N">N</A></DT>
|
|
<DT><A name="NAI">NAI</A></DT>
|
|
<DD><A href="http://www.nai.com">Network Associates</A>, a conglomerate
|
|
formed from<A href="#PGPI"> PGP Inc.</A>, TIS (Trusted Information
|
|
Systems, a firewall vendor) and McAfee anti-virus products. Among other
|
|
things, they offer an IPsec-based VPN product.</DD>
|
|
<DT><A name="NAT.gloss">NAT</A></DT>
|
|
<DD><B>N</B>etwork<B> A</B>ddress<B> T</B>ranslation, a process by which
|
|
firewall machines may change the addresses on packets as they go
|
|
through. For discussion, see our<A href="#nat.background"> background</A>
|
|
section.</DD>
|
|
<DT><A name="NIST">NIST</A></DT>
|
|
<DD>The US<A href="http://www.nist.gov"> National Institute of Standards
|
|
and Technology</A>, responsible for<A href="#FIPS"> FIPS standards</A>
|
|
including<A href="#DES"> DES</A> and its replacement,<A href="#AES">
|
|
AES</A>.</DD>
|
|
<DT><A name="nonce">Nonce</A></DT>
|
|
<DD>A<A href="#random"> random</A> value used in an<A href="#authentication">
|
|
authentication</A> protocol.</DD>
|
|
<DT></DT>
|
|
<DT><A name="non-routable">Non-routable IP address</A></DT>
|
|
<DD>An IP address not normally allowed in the "to" or "from" IP address
|
|
field header of IP packets.
|
|
<P>Almost invariably, the phrase "non-routable address" means one of the
|
|
addresses reserved by RFC 1918 for private networks:</P>
|
|
<UL>
|
|
<LI>10.anything</LI>
|
|
<LI>172.x.anything with 16 <= x <= 31</LI>
|
|
<LI>192.168.anything</LI>
|
|
</UL>
|
|
<P>These addresses are commonly used on private networks, e.g. behind a
|
|
Linux machines doing<A href="#masq"> IP masquerade</A>. Machines within
|
|
the private network can address each other with these addresses. All
|
|
packets going outside that network, however, have these addresses
|
|
replaced before they reach the Internet.</P>
|
|
<P>If any packets using these addresses do leak out, they do not go far.
|
|
Most routers automatically discard all such packets.</P>
|
|
<P>Various other addresses -- the 127.0.0.0/8 block reserved for local
|
|
use, 0.0.0.0, various broadcast and network addresses -- cannot be
|
|
routed over the Internet, but are not normally included in the meaning
|
|
when the phrase "non-routable address" is used.</P>
|
|
</DD>
|
|
<DT><A name="NSA">NSA</A></DT>
|
|
<DD>The US<A href="http://www.nsa.gov"> National Security Agency</A>,
|
|
the American organisation for<A href="#SIGINT"> signals intelligence</A>
|
|
, the protection of US government messages and the interception and
|
|
analysis of other messages. For details, see Bamford's<A href="#puzzle">
|
|
"The Puzzle Palace"</A>.
|
|
<P>Some<A href="http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index.html">
|
|
history of NSA</A> documents were declassified in response to a FOIA
|
|
(Freedom of Information Act) request.</P>
|
|
</DD>
|
|
<DT><A name="O">O</A></DT>
|
|
<DT><A name="oakley">Oakley</A></DT>
|
|
<DD>A key determination protocol, defined in RFC 2412.</DD>
|
|
<DT>Oakley groups</DT>
|
|
<DD>The groups used as the basis of<A href="#DH"> Diffie-Hellman</A> key
|
|
exchange in the Oakley protocol, and in<A href="#IKE"> IKE</A>. Four
|
|
were defined in the original RFC, and a fifth has been<A href="http://www.lounge.org/ike_doi_errata.html">
|
|
added since</A>.
|
|
<P>Linux FreeS/WAN currently supports the three groups based on finite
|
|
fields modulo a prime (Groups 1, 2 and 5) and does not support the
|
|
elliptic curve groups (3 and 4). For a description of the difference of
|
|
the types, see<A href="#dlog"> discrete logarithms</A>.</P>
|
|
</DD>
|
|
<DT><A name="OTP">One time pad</A></DT>
|
|
<DD>A cipher in which the key is:
|
|
<UL>
|
|
<LI>as long as the total set of messages to be enciphered</LI>
|
|
<LI>absolutely<A href="#random"> random</A></LI>
|
|
<LI>never re-used</LI>
|
|
</UL>
|
|
<P>Given those three conditions, it can easily be proved that the cipher
|
|
is perfectly secure, in the sense that an attacker with intercepted
|
|
message in hand has no better chance of guessing the message than an
|
|
attacker who has not intercepted the message and only knows the message
|
|
length. No such proof exists for any other cipher.</P>
|
|
<P>There are, however, several problems with this "perfect" cipher.</P>
|
|
<P>First, it is<STRONG> wildly impractical</STRONG> for most
|
|
applications. Key management is at best difficult, often completely
|
|
impossible.</P>
|
|
<P>Second, it is<STRONG> extremely fragile</STRONG>. Small changes which
|
|
violate the conditions listed above do not just weaken the cipher
|
|
liitle. Quite often they destroy its security completely.</P>
|
|
<UL>
|
|
<LI>Re-using the pad weakens the cipher to the point where it can be
|
|
broken with pencil and paper. With a computer, the attack is trivially
|
|
easy.</LI>
|
|
<LI>Using<EM> anything</EM> less than truly<A href="#random"> random</A>
|
|
numbers<EM> completely</EM> invalidates the security proof.</LI>
|
|
<LI>In particular, using computer-generated pseudo-random numbers may
|
|
give an extremely weak cipher. It might also produce a good stream
|
|
cipher, if the pseudo-random generator is both well-designed and
|
|
properely seeded.</LI>
|
|
</UL>
|
|
<P>Marketing claims about the "unbreakable" security of various products
|
|
which somewhat resemble one-time pads are common. Such claims are one
|
|
of the surest signs of cryptographic<A href="#snake"> snake oil</A>;
|
|
most systems marketed with such claims are worthless.</P>
|
|
<P>Finally, even if the system is implemented and used correctly, it is<STRONG>
|
|
highly vulnerable to a substitution attack</STRONG>. If an attacker
|
|
knows some plaintext and has an intercepted message, he can discover
|
|
the pad.</P>
|
|
<UL>
|
|
<LI>This does not matter if the attacker is just a<A href="#passive">
|
|
passive</A> eavesdropper. It gives him no plaintext he didn't already
|
|
know and we don't care that he learns a pad which we will never re-use.</LI>
|
|
<LI>However, an<A href="#active"> active</A> attacker who knows the
|
|
plaintext can recover the pad, then use it to encode with whatever he
|
|
chooses. If he can get his version delivered instead of yours, this may
|
|
be a disaster. If you send "attack at dawn", the delivered message can
|
|
be anything the same length -- perhaps "retreat to east" or "shoot
|
|
generals".</LI>
|
|
<LI>An active attacker with only a reasonable guess at the plaintext can
|
|
try the same attack. If the guess is correct, this works and the
|
|
attacker's bogus message is delivered. If the guess is wrong, a garbled
|
|
message is delivered.</LI>
|
|
</UL>
|
|
<P>In general then, despite its theoretical perfection, the one-time-pad
|
|
has very limited practical application.</P>
|
|
<P>See also the<A href="http://pubweb.nfr.net/~mjr/pubs/otpfaq/"> one
|
|
time pad FAQ</A>.</P>
|
|
</DD>
|
|
<DT><A name="carpediem">Opportunistic encryption (OE)</A></DT>
|
|
<DD>A situation in which any two IPsec-aware machines can secure their
|
|
communications, without a pre-shared secret and without a common<A href="#PKI">
|
|
PKI</A> or previous exchange of public keys. This is one of the goals
|
|
of the Linux FreeS/WAN project, discussed in our<A href="#goals">
|
|
introduction</A> section.
|
|
<P>Setting up for opportunistic encryption is described in our<A href="#quickstart">
|
|
quickstart</A> document.</P>
|
|
</DD>
|
|
<DT><A name="responder">Opportunistic responder</A></DT>
|
|
<DD>A host which accepts, but does not initiate, requests for<A HREF="#carpediem">
|
|
opportunistic encryption</A> (OE). An opportunistic responder has
|
|
enabled OE in its<A HREF="#passive.OE"> passive</A> form (pOE) only. A
|
|
web server or file server may be usefully set up as an opportunistic
|
|
responder.
|
|
<P>Configuring passive OE is described in our<A href="#policygroups">
|
|
policy groups</A> document.</P>
|
|
</DD>
|
|
<DT><A name="orange">Orange book</A></DT>
|
|
<DD>the most basic and best known of the US government's<A href="#rainbow">
|
|
Rainbow Book</A> series of computer security standards.</DD>
|
|
<DT><A name="P">P</A></DT>
|
|
<DT><A name="P1363">P1363 standard</A></DT>
|
|
<DD>An<A href="#IEEE"> IEEE</A> standard for public key cryptography.<A href="http://grouper.ieee.org/groups/1363">
|
|
Web page</A>.</DD>
|
|
<DT><A name="pOE">pOE</A></DT>
|
|
<DD>See<A href="#passive.OE"> Passive opportunistic encryption</A>.</DD>
|
|
<DT><A name="passive">Passive attack</A></DT>
|
|
<DD>An attack in which the attacker only eavesdrops and attempts to
|
|
analyse intercepted messages, as opposed to an<A href="#active"> active
|
|
attack</A> in which he diverts messages or generates his own.</DD>
|
|
<DT><A name="passive.OE">Passive opportunistic encryption (pOE)</A></DT>
|
|
<DD>A form of<A HREF="#carpediem"> opportunistic encryption</A> (OE) in
|
|
which the host will accept opportunistic connection requests, but will
|
|
not initiate such requests. A host which runs OE in its passive form
|
|
only is known as an<A HREF="#responder"> opportunistic responder</A>.
|
|
<P>Configuring passive OE is described in our<A href="#policygroups">
|
|
policy groups</A> document.</P>
|
|
</DD>
|
|
<DT><A name="pathMTU">Path MTU discovery</A></DT>
|
|
<DD>The process of discovering the largest packet size which all links
|
|
on a path can handle without fragmentation -- that is, without any
|
|
router having to break the packet up into smaller pieces to match the<A href="#MTU">
|
|
MTU</A> of its outgoing link.
|
|
<P>This is done as follows:</P>
|
|
<UL>
|
|
<LI>originator sends the largest packets allowed by<A href="#MTU"> MTU</A>
|
|
of the first link, setting the DF (<STRONG>d</STRONG>on't<STRONG> f</STRONG>
|
|
ragment) bit in the packet header</LI>
|
|
<LI>any router which cannot send the packet on (outgoing MTU is too
|
|
small for it, and DF prevents fragmenting it to match) sends back an<A href="#ICMP.gloss">
|
|
ICMP</A> packet reporting the problem</LI>
|
|
<LI>originator looks at ICMP message and tries a smaller size</LI>
|
|
<LI>eventually, you settle on a size that can pass all routers</LI>
|
|
<LI>thereafter, originator just sends that size and no-one has to
|
|
fragment</LI>
|
|
</UL>
|
|
<P>Since this requires co-operation of many systems, and since the next
|
|
packet may travel a different path, this is one of the trickier areas
|
|
of IP programming. Bugs that have shown up over the years have
|
|
included:</P>
|
|
<UL>
|
|
<LI>malformed ICMP messages</LI>
|
|
<LI>hosts that ignore or mishandle these ICMP messages</LI>
|
|
<LI>firewalls blocking the ICMP messages so host does not see them</LI>
|
|
</UL>
|
|
<P>Since IPsec adds a header, it increases packet size and may require
|
|
fragmentation even where incoming and outgoing MTU are equal.</P>
|
|
</DD>
|
|
<DT><A name="PFS">Perfect forward secrecy (PFS)</A></DT>
|
|
<DD>A property of systems such as<A href="#DH"> Diffie-Hellman</A> key
|
|
exchange which use a long-term key (such as the shared secret in IKE)
|
|
and generate short-term keys as required. If an attacker who acquires
|
|
the long-term key<EM> provably</EM> can
|
|
<UL>
|
|
<LI><EM>neither</EM> read previous messages which he may have archived</LI>
|
|
<LI><EM>nor</EM> read future messages without performing additional
|
|
successful attacks</LI>
|
|
</UL>
|
|
<P>then the system has PFS. The attacker needs the short-term keys in
|
|
order to read the trafiic and merely having the long-term key does not
|
|
allow him to infer those. Of course, it may allow him to conduct
|
|
another attack (such as<A href="#middle"> man-in-the-middle</A>) which
|
|
gives him some short-term keys, but he does not automatically get them
|
|
just by acquiring the long-term key.</P>
|
|
<P>See also<A href="http://sandelman.ottawa.on.ca/ipsec/1996/08/msg00123.html">
|
|
Phil Karn's definition</A>.</P>
|
|
</DD>
|
|
<DT>PFS</DT>
|
|
<DD>see Perfect Forward Secrecy</DD>
|
|
<DT><A name="PGP">PGP</A></DT>
|
|
<DD><B>P</B>retty<B> G</B>ood<B> P</B>rivacy, a personal encryption
|
|
system for email based on public key technology, written by Phil
|
|
Zimmerman.
|
|
<P>The 2.xx versions of PGP used the<A href="#RSA"> RSA</A> public key
|
|
algorithm and used<A href="#IDEA"> IDEA</A> as the symmetric cipher.
|
|
These versions are described in RFC 1991 and in<A href="#PGP">
|
|
Garfinkel's book</A>. Since version 5, the products from<A href="#PGPI">
|
|
PGP Inc</A>. have used<A href="#DH"> Diffie-Hellman</A> public key
|
|
methods and<A href="#CAST128"> CAST-128</A> symmetric encryption. These
|
|
can verify signatures from the 2.xx versions, but cannot exchange
|
|
encryted messages with them.</P>
|
|
<P>An<A href="#IETF"> IETF</A> working group has issued RFC 2440 for an
|
|
"Open PGP" standard, similar to the 5.x versions. PGP Inc. staff were
|
|
among the authors. A free<A href="#GPG"> Gnu Privacy Guard</A> based on
|
|
that standard is now available.</P>
|
|
<P>For more information on PGP, including how to obtain it, see our
|
|
cryptography<A href="#tools"> links</A>.</P>
|
|
</DD>
|
|
<DT><A name="PGPI">PGP Inc.</A></DT>
|
|
<DD>A company founded by Zimmerman, the author of<A href="#PGP"> PGP</A>
|
|
, now a division of<A href="#NAI"> NAI</A>. See the<A href="http://www.pgp.com">
|
|
corporate website</A>. Zimmerman left in 2001, and early in 2002 NAI
|
|
announced that they would no longer sell PGP..
|
|
<P>Versions 6.5 and later of the PGP product include PGPnet, an IPsec
|
|
client for Macintosh or for Windows 95/98/NT. See our<A href="interop.html#pgpnet">
|
|
interoperation documen</A>t.</P>
|
|
</DD>
|
|
<DT><A name="photuris">Photuris</A></DT>
|
|
<DD>Another key negotiation protocol, an alternative to<A href="#IKE">
|
|
IKE</A>, described in RFCs 2522 and 2523.</DD>
|
|
<DT><A name="PPP">PPP</A></DT>
|
|
<DD><B>P</B>oint-to-<B>P</B>oint<B> P</B>rotocol, originally a method of
|
|
connecting over modems or serial lines, but see also PPPoE.</DD>
|
|
<DT><A name="PPPoE">PPPoE</A></DT>
|
|
<DD><B>PPP</B><B> o</B>ver<B> E</B>thernet, a somewhat odd protocol that
|
|
makes Ethernet look like a point-to-point serial link. It is widely
|
|
used for cable or ADSL Internet services, apparently mainly because it
|
|
lets the providers use access control and address assignmment
|
|
mechanisms developed for dialup networks.<A href="http://www.roaringpenguin.com">
|
|
Roaring Penguin</A> provide a widely used Linux implementation.</DD>
|
|
<DT><A name="PPTP">PPTP</A></DT>
|
|
<DD><B>P</B>oint-to-<B>P</B>oint<B> T</B>unneling<B> P</B>rotocol, used
|
|
in some Microsoft VPN implementations. Papers discussing weaknesses in
|
|
it are on<A href="http://www.counterpane.com/publish.html">
|
|
counterpane.com</A>. It is now largely obsolete, replaced by L2TP.</DD>
|
|
<DT><A name="PKI">PKI</A></DT>
|
|
<DD><B>P</B>ublic<B> K</B>ey<B> I</B>nfrastructure, the things an
|
|
organisation or community needs to set up in order to make<A href="#public">
|
|
public key</A> cryptographic technology a standard part of their
|
|
operating procedures.
|
|
<P>There are several PKI products on the market. Typically they use a
|
|
hierarchy of<A href="#CA"> Certification Authorities (CAs)</A>. Often
|
|
they use<A href="#LDAP"> LDAP</A> access to<A href="#X509"> X.509</A>
|
|
directories to implement this.</P>
|
|
<P>See<A href="#web"> Web of Trust</A> for a different sort of
|
|
infrastructure.</P>
|
|
</DD>
|
|
<DT><A name="PKIX">PKIX</A></DT>
|
|
<DD><B>PKI</B> e<B>X</B>change, an<A href="#IETF"> IETF</A> standard
|
|
that allows<A href="#PKI"> PKI</A>s to talk to each other.
|
|
<P>This is required, for example, when users of a corporate PKI need to
|
|
communicate with people at client, supplier or government
|
|
organisations, any of which may have a different PKI in place. I should
|
|
be able to talk to you securely whenever:</P>
|
|
<UL>
|
|
<LI>your organisation and mine each have a PKI in place</LI>
|
|
<LI>you and I are each set up to use those PKIs</LI>
|
|
<LI>the two PKIs speak PKIX</LI>
|
|
<LI>the configuration allows the conversation</LI>
|
|
</UL>
|
|
<P>At time of writing (March 1999), this is not yet widely implemented
|
|
but is under quite active development by several groups.</P>
|
|
</DD>
|
|
<DT><A name="plaintext">Plaintext</A></DT>
|
|
<DD>The unencrypted input to a cipher, as opposed to the encrypted<A href="#ciphertext">
|
|
ciphertext</A> output.</DD>
|
|
<DT><A name="Pluto">Pluto</A></DT>
|
|
<DD>The<A href="#FreeSWAN"> Linux FreeS/WAN</A> daemon which handles key
|
|
exchange via the<A href="#IKE"> IKE</A> protocol, connection
|
|
negotiation, and other higher-level tasks. Pluto calls the<A href="#KLIPS">
|
|
KLIPS</A> kernel code as required. For details, see the manual page
|
|
ipsec_pluto(8).</DD>
|
|
<DT><A name="public">Public Key Cryptography</A></DT>
|
|
<DD>In public key cryptography, keys are created in matched pairs.
|
|
Encrypt with one half of a pair and only the matching other half can
|
|
decrypt it. This contrasts with<A href="#symmetric"> symmetric or
|
|
secret key cryptography</A> in which a single key known to both parties
|
|
is used for both encryption and decryption.
|
|
<P>One half of each pair, called the public key, is made public. The
|
|
other half, called the private key, is kept secret. Messages can then
|
|
be sent by anyone who knows the public key to the holder of the private
|
|
key. Encrypt with the public key and you know that only someone with
|
|
the matching private key can decrypt.</P>
|
|
<P>Public key techniques can be used to create<A href="#signature">
|
|
digital signatures</A> and to deal with key management issues, perhaps
|
|
the hardest part of effective deployment of<A href="#symmetric">
|
|
symmetric ciphers</A>. The resulting<A href="#hybrid"> hybrid
|
|
cryptosystems</A> use public key methods to manage keys for symmetric
|
|
ciphers.</P>
|
|
<P>Many organisations are currently creating<A href="#PKI"> PKIs, public
|
|
key infrastructures</A> to make these benefits widely available.</P>
|
|
</DD>
|
|
<DT>Public Key Infrastructure</DT>
|
|
<DD>see<A href="#PKI"> PKI</A></DD>
|
|
<DT><A name="Q">Q</A></DT>
|
|
<DT><A name="R">R</A></DT>
|
|
<DT><A name="rainbow">Rainbow books</A></DT>
|
|
<DD>A set of US government standards for evaluation of "trusted computer
|
|
systems", of which the best known was the<A href="#orange"> Orange Book</A>
|
|
. One fairly often hears references to "C2 security" or a product
|
|
"evaluated at B1". The Rainbow books define the standards referred to
|
|
in those comments.
|
|
<P>See this<A href="http://www.fas.org/irp/nsa/rainbow.htm"> reference
|
|
page</A>.</P>
|
|
<P>The Rainbow books are now mainly obsolete, replaced by the
|
|
international<A href="#cc"> Common Criteria</A> standards.</P>
|
|
</DD>
|
|
<DT><A name="random">Random</A></DT>
|
|
<DD>A remarkably tricky term, far too much so for me to attempt a
|
|
definition here. Quite a few cryptosystems have been broken via attacks
|
|
on weak random number generators, even when the rest of the system was
|
|
sound.
|
|
<P>See<A href="http://nis.nsf.net/internet/documents/rfc/rfc1750.txt">
|
|
RFC 1750</A> for the theory.</P>
|
|
<P>See the manual pages for<A href="manpage.d/ipsec_ranbits.8.html">
|
|
ipsec_ranbits(8)</A> and ipsec_prng(3) for more on FreeS/WAN's use of
|
|
randomness. Both depend on the random(4) device driver..</P>
|
|
<P>A couple of years ago, there was extensive mailing list discussion
|
|
(archived<A href="http://www.openpgp.net/random/index.html"> here</A>
|
|
)of Linux /dev/random and FreeS/WAN. Since then, the design of the
|
|
random(4) driver has changed considerably. Linux 2.4 kernels have the
|
|
new driver..</P>
|
|
</DD>
|
|
<DT>Raptor</DT>
|
|
<DD>A firewall product for Windows NT offerring IPsec-based VPN
|
|
services. Linux FreeS/WAN interoperates with Raptor; see our<A href="#raptor">
|
|
interop</A> document for details. Raptor have recently merged with
|
|
Axent.</DD>
|
|
<DT><A name="RC4">RC4</A></DT>
|
|
<DD><B>R</B>ivest<B> C</B>ipher four, designed by Ron Rivest of<A href="#RSAco">
|
|
RSA</A> and widely used. Believed highly secure with adequate key
|
|
length, but often implemented with inadequate key length to comply with
|
|
export restrictions.</DD>
|
|
<DT><A name="RC6">RC6</A></DT>
|
|
<DD><B>R</B>ivest<B> C</B>ipher six,<A href="#RSAco"> RSA</A>'s<A href="#AES">
|
|
AES</A> candidate cipher.</DD>
|
|
<DT><A name="replay">Replay attack</A></DT>
|
|
<DD>An attack in which the attacker records data and later replays it in
|
|
an attempt to deceive the recipient.</DD>
|
|
<DT><A name="reverse">Reverse map</A></DT>
|
|
<DD>In<A href="#DNS"> DNS</A>, a table where IP addresses can be used as
|
|
the key for lookups which return a system name and/or other
|
|
information.</DD>
|
|
<DT>RFC</DT>
|
|
<DD><B>R</B>equest<B> F</B>or<B> C</B>omments, an Internet document.
|
|
Some RFCs are just informative. Others are standards.
|
|
<P>Our list of<A href="#IPSEC"> IPsec</A> and other security-related
|
|
RFCs is<A href="#RFC"> here</A>, along with information on methods of
|
|
obtaining them.</P>
|
|
</DD>
|
|
<DT><A name="rijndael">Rijndael</A></DT>
|
|
<DD>a<A href="#block"> block cipher</A> designed by two Belgian
|
|
cryptographers, winner of the US government's<A href="#AES"> AES</A>
|
|
contest to pick a replacement for<A href="#DES"> DES</A>. See the<A href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael">
|
|
Rijndael home page</A>.</DD>
|
|
<DT><A name="RIPEMD">RIPEMD</A></DT>
|
|
<DD>A<A href="#digest"> message digest</A> algorithm. The current
|
|
version is RIPEMD-160 which gives a 160-bit hash.</DD>
|
|
<DT><A name="rootCA">Root CA</A></DT>
|
|
<DD>The top level<A href="#CA"> Certification Authority</A> in a
|
|
hierachy of such authorities.</DD>
|
|
<DT><A name="routable">Routable IP address</A></DT>
|
|
<DD>Most IP addresses can be used as "to" and "from" addresses in packet
|
|
headers. These are the routable addresses; we expect routing to be
|
|
possible for them. If we send a packet to one of them, we expect (in
|
|
most cases; there are various complications) that it will be delivered
|
|
if the address is in use and will cause an<A href="#ICMP.gloss"> ICMP</A>
|
|
error packet to come back to us if not.
|
|
<P>There are also several classes of<A href="#non-routable">
|
|
non-routable</A> IP addresses.</P>
|
|
</DD>
|
|
<DT><A name="RSA">RSA algorithm</A></DT>
|
|
<DD><B>R</B>ivest<B> S</B>hamir<B> A</B>dleman<A href="#public"> public
|
|
key</A> algorithm, named for its three inventors. It is widely used and
|
|
likely to become moreso since it became free of patent encumbrances in
|
|
September 2000.
|
|
<P>RSA can be used to provide either<A href="#encryption"> encryption</A>
|
|
or<A href="#signature"> digital signatures</A>. In IPsec, it is used
|
|
only for signatures. These provide gateway-to-gateway<A href="#authentication">
|
|
authentication</A> for<A href="#IKE"> IKE</A> negotiations.</P>
|
|
<P>For a full explanation of the algorithm, consult one of the standard
|
|
references such as<A href="#schneier"> Applied Cryptography</A>. A
|
|
simple explanation is:</P>
|
|
<P>The great 17th century French mathematician<A href="http://www-groups.dcs.st-andrews.ac.uk/~history/Mathematicians/Fermat.html">
|
|
Fermat</A> proved that,</P>
|
|
<P>for any prime p and number x, 0 <= x < p:</P>
|
|
<PRE> x^p == x modulo p
|
|
x^(p-1) == 1 modulo p, non-zero x
|
|
</PRE>
|
|
<P>From this it follows that if we have a pair of primes p, q and two
|
|
numbers e, d such that:</P>
|
|
<PRE> ed == 1 modulo lcm( p-1, q-1)
|
|
</PRE>
|
|
where lcm() is least common multiple, then
|
|
<BR> for all x, 0 <= x < pq:
|
|
<PRE> x^ed == x modulo pq
|
|
</PRE>
|
|
<P>So we construct such as set of numbers p, q, e, d and publish the
|
|
product N=pq and e as the public key. Using c for<A href="#ciphertext">
|
|
ciphertext</A> and i for the input<A href="#plaintext"> plaintext</A>,
|
|
encryption is then:</P>
|
|
<PRE> c = i^e modulo N
|
|
</PRE>
|
|
<P>An attacker cannot deduce i from the cyphertext c, short of either
|
|
factoring N or solving the<A href="#dlog"> discrete logarithm</A>
|
|
problem for this field. If p, q are large primes (hundreds or thousands
|
|
of bits) no efficient solution to either problem is known.</P>
|
|
<P>The receiver, knowing the private key (N and d), can readily recover
|
|
the plaintext p since:</P>
|
|
<PRE> c^d == (i^e)^d modulo N
|
|
== i^ed modulo N
|
|
== i modulo N
|
|
</PRE>
|
|
<P>This gives an effective public key technique, with only a couple of
|
|
problems. It uses a good deal of computer time, since calculations with
|
|
large integers are not cheap, and there is no proof it is necessarily
|
|
secure since no-one has proven either factoring or discrete log cannot
|
|
be done efficiently. Quite a few good mathematicians have tried both
|
|
problems, and no-one has announced success, but there is no proof they
|
|
are insoluble.</P>
|
|
</DD>
|
|
<DT><A name="RSAco">RSA Data Security</A></DT>
|
|
<DD>A company founded by the inventors of the<A href="#RSA"> RSA</A>
|
|
public key algorithm.</DD>
|
|
<DT><A name="S">S</A></DT>
|
|
<DT><A name="SA">SA</A></DT>
|
|
<DD><B>S</B>ecurity<B> A</B>ssociation, the channel negotiated by the
|
|
higher levels of an<A href="#IPSEC"> IPsec</A> implementation (<A href="#IKE">
|
|
IKE</A>) and used by the lower (<A href="#ESP">ESP</A> and<A href="#AH">
|
|
AH</A>). SAs are unidirectional; you need a pair of them for two-way
|
|
communication.
|
|
<P>An SA is defined by three things -- the destination, the protocol (<A href="#AH">
|
|
AH</A> or<A href="#ESP">ESP</A>) and the<A href="SPI"> SPI</A>, security
|
|
parameters index. It is used as an index to look up other things such
|
|
as session keys and intialisation vectors.</P>
|
|
<P>For more detail, see our section on<A href="ipsec.html"> IPsec</A>
|
|
and/or RFC 2401.</P>
|
|
</DD>
|
|
<DT><A name="SElinux">SE Linux</A></DT>
|
|
<DD><STRONG>S</STRONG>ecurity<STRONG> E</STRONG>nhanced Linux, an<A href="#NSA">
|
|
NSA</A>-funded project to add<A href="#mandatory"> mandatory access
|
|
control</A> to Linux. See the<A href="http://www.nsa.gov/selinux">
|
|
project home page</A>.
|
|
<P>According to their web pages, this work will include extending
|
|
mandatory access controls to IPsec tunnels.</P>
|
|
<P>Recent versions of SE Linux code use the<A href="#LSM"> Linux
|
|
Security Module</A> interface.</P>
|
|
</DD>
|
|
<DT><A name="SDNS">Secure DNS</A></DT>
|
|
<DD>A version of the<A href="#DNS"> DNS or Domain Name Service</A>
|
|
enhanced with authentication services. This is being designed by the<A href="#IETF">
|
|
IETF</A> DNS security<A href="http://www.ietf.org/ids.by.wg/dnssec.html">
|
|
working group</A>. Check the<A href="http://www.isc.org/bind.html">
|
|
Internet Software Consortium</A> for information on implementation
|
|
progress and for the latest version of<A href="#BIND"> BIND</A>.
|
|
Another site has<A href="http://www.toad.com/~dnssec"> more information</A>
|
|
.
|
|
<P><A href="#IPSEC">IPsec</A> can use this plus<A href="#DH">
|
|
Diffie-Hellman key exchange</A> to bootstrap itself. This allows<A href="#carpediem">
|
|
opportunistic encryption</A>. Any pair of machines which can
|
|
authenticate each other via DNS can communicate securely, without
|
|
either a pre-existing shared secret or a shared<A href="#PKI"> PKI</A>.</P>
|
|
</DD>
|
|
<DT>Secret key cryptography</DT>
|
|
<DD>See<A href="#symmetric"> symmetric cryptography</A></DD>
|
|
<DT>Security Association</DT>
|
|
<DD>see<A href="#SA"> SA</A></DD>
|
|
<DT>Security Enhanced Linux</DT>
|
|
<DD>see<A href="#SElinux"> SE Linux</A></DD>
|
|
<DT><A name="sequence">Sequence number</A></DT>
|
|
<DD>A number added to a packet or message which indicates its position
|
|
in a sequence of packets or messages. This provides some security
|
|
against<A href="#replay"> replay attacks</A>.
|
|
<P>For<A href="#auto"> automatic keying</A> mode, the<A href="#IPSEC">
|
|
IPsec</A> RFCs require that the sender generate sequence numbers for
|
|
each packet, but leave it optional whether the receiver does anything
|
|
with them.</P>
|
|
</DD>
|
|
<DT><A name="SHA">SHA</A></DT>
|
|
<DT>SHA-1</DT>
|
|
<DD><B>S</B>ecure<B> H</B>ash<B> A</B>lgorithm, a<A href="#digest">
|
|
message digest algorithm</A> developed by the<A href="#NSA"> NSA</A>
|
|
for use in the Digital Signature standard,<A href="#FIPS"> FIPS</A>
|
|
number 186 from<A href="#NIST"> NIST</A>. SHA is an improved variant of<A
|
|
href="#MD4"> MD4</A> producing a 160-bit hash.
|
|
<P>SHA is one of two message digest algorithms available in IPsec. The
|
|
other is<A href="#MD5"> MD5</A>. Some people do not trust SHA because
|
|
it was developed by the<A href="#NSA"> NSA</A>. There is, as far as we
|
|
know, no cryptographic evidence that SHA is untrustworthy, but this
|
|
does not prevent that view from being strongly held.</P>
|
|
<P>The NSA made one small change after the release of the original SHA.
|
|
They did not give reasons. Iit may be a defense against some attack
|
|
they found and do not wish to disclose. Technically the modified
|
|
algorithm should be called SHA-1, but since it has replaced the
|
|
original algorithm in nearly all applications, it is generally just
|
|
referred to as SHA..</P>
|
|
</DD>
|
|
<DT><A name="SHA-256">SHA-256</A></DT>
|
|
<DT>SHA-384</DT>
|
|
<DT>SHA-512</DT>
|
|
<DD>Newer variants of SHA designed to match the strength of the 128, 192
|
|
and 256-bit keys of<A href="#AES"> AES</A>. The work to break an
|
|
encryption algorithm's strength by<A href="#brute"> brute force</A> is
|
|
2
|
|
<!--math xmlns="http://www.w3.org/1998/Math/MathML"-->
|
|
|
|
<!--msup-->
|
|
|
|
<!--mi-->
|
|
keylength</(null)></(null)></(null)> operations but a<A href="birthday">
|
|
birthday attack</A> on a hash needs only 2
|
|
<!--math xmlns="http://www.w3.org/1998/Math/MathML"-->
|
|
|
|
<!--msup-->
|
|
|
|
<!--mrow-->
|
|
|
|
<!--mi-->
|
|
hashlength</(null)>
|
|
<!--mo-->
|
|
/</(null)>
|
|
<!--mn-->
|
|
|
|
2</(null)></(null)></(null)></(null)> , so as a general rule you need a
|
|
hash twice the size of the key to get similar strength. SHA-256,
|
|
SHA-384 and SHA-512 are designed to match the 128, 192 and 256-bit key
|
|
sizes of AES, respectively.</DD>
|
|
<DT><A name="SIGINT">Signals intelligence (SIGINT)</A></DT>
|
|
<DD>Activities of government agencies from various nations aimed at
|
|
protecting their own communications and reading those of others.
|
|
Cryptography, cryptanalysis, wiretapping, interception and monitoring
|
|
of various sorts of signals. The players include the American<A href="#NSA">
|
|
NSA</A>, British<A href="#GCHQ"> GCHQ</A> and Canadian<A href="#CSE">
|
|
CSE</A>.</DD>
|
|
<DT><A name="SKIP">SKIP</A></DT>
|
|
<DD><B>S</B>imple<B> K</B>ey management for<B> I</B>nternet<B> P</B>
|
|
rotocols, an alternative to<A href="#IKE"> IKE</A> developed by Sun and
|
|
being marketed by their<A href="http://skip.incog.com"> Internet
|
|
Commerce Group</A>.</DD>
|
|
<DT><A name="snake">Snake oil</A></DT>
|
|
<DD>Bogus cryptography. See the<A href="http://www.interhack.net/people/cmcurtin/snake-oil-faq.html">
|
|
Snake Oil FAQ</A> or<A href="http://www.counterpane.com/crypto-gram-9902.html#snakeoil">
|
|
this paper</A> by Schneier.</DD>
|
|
<DT><A name="SPI">SPI</A></DT>
|
|
<DD><B>S</B>ecurity<B> P</B>arameter<B> I</B>ndex, an index used within<A
|
|
href="#IPSEC"> IPsec</A> to keep connections distinct. A<A href="#SA">
|
|
Security Association (SA)</A> is defined by destination, protocol and
|
|
SPI. Without the SPI, two connections to the same gateway using the
|
|
same protocol could not be distinguished.
|
|
<P>For more detail, see our<A href="ipsec.html"> IPsec</A> section
|
|
and/or RFC 2401.</P>
|
|
</DD>
|
|
<DT><A name="SSH">SSH</A></DT>
|
|
<DD><B>S</B>ecure<B> SH</B>ell, an encrypting replacement for the
|
|
insecure Berkeley commands whose names begin with "r" for "remote":
|
|
rsh, rlogin, etc.
|
|
<P>For more information on SSH, including how to obtain it, see our
|
|
cryptography<A href="#tools"> links</A>.</P>
|
|
</DD>
|
|
<DT><A name="SSHco">SSH Communications Security</A></DT>
|
|
<DD>A company founded by the authors of<A href="#SSH"> SSH</A>. Offices
|
|
are in<A href="http://www.ssh.fi"> Finland</A> and<A href="http://www.ipsec.com">
|
|
California</A>. They have a toolkit for developers of IPsec
|
|
applications.</DD>
|
|
<DT><A name="SSL">SSL</A></DT>
|
|
<DD><A href="http://home.netscape.com/eng/ssl3">Secure Sockets Layer</A>
|
|
, a set of encryption and authentication services for web browsers,
|
|
developed by Netscape. Widely used in Internet commerce. Also known as<A
|
|
href="#TLS"> TLS</A>.</DD>
|
|
<DT>SSLeay</DT>
|
|
<DD>A free implementation of<A href="#SSL"> SSL</A> by Eric Young (eay)
|
|
and others. Developed in Australia; not subject to US export controls.</DD>
|
|
<DT><A name="static">static IP address</A></DT>
|
|
<DD>an IP adddress which is pre-set on the machine itself, as opposed to
|
|
a<A href="#dynamic"> dynamic address</A> which is assigned by a<A href="#DHCP">
|
|
DHCP</A> server or obtained as part of the process of establishing a<A href="#PPP">
|
|
PPP</A> or<A href="#PPPoE"> PPPoE</A> connection</DD>
|
|
<DT><A name="stream">Stream cipher</A></DT>
|
|
<DD>A<A href="#symmetric"> symmetric cipher</A> which produces a stream
|
|
of output which can be combined (often using XOR or bytewise addition)
|
|
with the plaintext to produce ciphertext. Contrasts with<A href="#block">
|
|
block cipher</A>.
|
|
<P><A href="#IPSEC">IPsec</A> does not use stream ciphers. Their main
|
|
application is link-level encryption, for example of voice, video or
|
|
data streams on a wire or a radio signal.</P>
|
|
</DD>
|
|
<DT><A name="subnet">subnet</A></DT>
|
|
<DD>A group of IP addresses which are logically one network, typically
|
|
(but not always) assigned to a group of physically connected machines.
|
|
The range of addresses in a subnet is described using a subnet mask.
|
|
See next entry.</DD>
|
|
<DT>subnet mask</DT>
|
|
<DD>A method of indicating the addresses included in a subnet. Here are
|
|
two equivalent examples:
|
|
<UL>
|
|
<LI>101.101.101.0/24</LI>
|
|
<LI>101.101.101.0 with mask 255.255.255.0</LI>
|
|
</UL>
|
|
<P>The '24' is shorthand for a mask with the top 24 bits one and the
|
|
rest zero. This is exactly the same as 255.255.255.0 which has three
|
|
all-ones bytes and one all-zeros byte.</P>
|
|
<P>These indicate that, for this range of addresses, the top 24 bits are
|
|
to be treated as naming a network (often referred to as "the
|
|
101.101.101.0/24 subnet") while most combinations of the low 8 bits can
|
|
be used to designate machines on that network. Two addresses are
|
|
reserved; 101.101.101.0 refers to the subnet rather than a specific
|
|
machine while 101.101.101.255 is a broadcast address. 1 to 254 are
|
|
available for machines.</P>
|
|
<P>It is common to find subnets arranged in a hierarchy. For example, a
|
|
large company might have a /16 subnet and allocate /24 subnets within
|
|
that to departments. An ISP might have a large subnet and allocate /26
|
|
subnets (64 addresses, 62 usable) to business customers and /29 subnets
|
|
(8 addresses, 6 usable) to residential clients.</P>
|
|
</DD>
|
|
<DT><A name="SWAN">S/WAN</A></DT>
|
|
<DD>Secure Wide Area Network, a project involving<A href="#RSAco"> RSA
|
|
Data Security</A> and a number of other companies. The goal was to
|
|
ensure that all their<A href="#IPSEC"> IPsec</A> implementations would
|
|
interoperate so that their customers can communicate with each other
|
|
securely.</DD>
|
|
<DT><A name="symmetric">Symmetric cryptography</A></DT>
|
|
<DD>Symmetric cryptography, also referred to as conventional or secret
|
|
key cryptography, relies on a<EM> shared secret key</EM>, identical for
|
|
sender and receiver. Sender encrypts with that key, receiver decrypts
|
|
with it. The idea is that an eavesdropper without the key be unable to
|
|
read the messages. There are two main types of symmetric cipher,<A href="#block">
|
|
block ciphers</A> and<A href="#stream"> stream ciphers</A>.
|
|
<P>Symmetric cryptography contrasts with<A href="#public"> public key</A>
|
|
or asymmetric systems where the two players use different keys.</P>
|
|
<P>The great difficulty in symmetric cryptography is, of course, key
|
|
management. Sender and receiver<EM> must</EM> have identical keys and
|
|
those keys<EM> must</EM> be kept secret from everyone else. Not too
|
|
much of a problem if only two people are involved and they can
|
|
conveniently meet privately or employ a trusted courier. Quite a
|
|
problem, though, in other circumstances.</P>
|
|
<P>It gets much worse if there are many people. An application might be
|
|
written to use only one key for communication among 100 people, for
|
|
example, but there would be serious problems. Do you actually trust all
|
|
of them that much? Do they trust each other that much? Should they?
|
|
What is at risk if that key is compromised? How are you going to
|
|
distribute that key to everyone without risking its secrecy? What do
|
|
you do when one of them leaves the company? Will you even know?</P>
|
|
<P>On the other hand, if you need unique keys for every possible
|
|
connection between a group of 100, then each user must have 99 keys.
|
|
You need either 99*100/2 = 4950<EM> secure</EM> key exchanges between
|
|
users or a central authority that<EM> securely</EM> distributes 100 key
|
|
packets, each with a different set of 99 keys.</P>
|
|
<P>Either of these is possible, though tricky, for 100 users. Either
|
|
becomes an administrative nightmare for larger numbers. Moreover, keys<EM>
|
|
must</EM> be changed regularly, so the problem of key distribution
|
|
comes up again and again. If you use the same key for many messages
|
|
then an attacker has more text to work with in an attempt to crack that
|
|
key. Moreover, one successful crack will give him or her the text of
|
|
all those messages.</P>
|
|
<P>In short, the<EM> hardest part of conventional cryptography is key
|
|
management</EM>. Today the standard solution is to build a<A href="#hybrid">
|
|
hybrid system</A> using<A href="#public"> public key</A> techniques to
|
|
manage keys.</P>
|
|
</DD>
|
|
<DT><A name="T">T</A></DT>
|
|
<DT><A name="TIS">TIS</A></DT>
|
|
<DD>Trusted Information Systems, a firewall vendor now part of<A href="#NAI">
|
|
NAI</A>. Their Gauntlet product offers IPsec VPN services. TIS
|
|
implemented the first version of<A href="#SDNS"> Secure DNS</A> on a<A href="#DARPA">
|
|
DARPA</A> contract.</DD>
|
|
<DT><A name="TLS">TLS</A></DT>
|
|
<DD><B>T</B>ransport<B> L</B>ayer<B> S</B>ecurity, a newer name for<A href="#SSL">
|
|
SSL</A>.</DD>
|
|
<DT><A name="TOS">TOS field</A></DT>
|
|
<DD>The<STRONG> T</STRONG>ype<STRONG> O</STRONG>f<STRONG> S</STRONG>
|
|
ervice field in an IP header, used to control qualkity of service
|
|
routing.</DD>
|
|
<DT><A name="traffic">Traffic analysis</A></DT>
|
|
<DD>Deducing useful intelligence from patterns of message traffic,
|
|
without breaking codes or reading the messages. In one case during
|
|
World War II, the British guessed an attack was coming because all
|
|
German radio traffic stopped. The "radio silence" order, intended to
|
|
preserve security, actually gave the game away.
|
|
<P>In an industrial espionage situation, one might deduce something
|
|
interesting just by knowing that company A and company B were talking,
|
|
especially if one were able to tell which departments were involved, or
|
|
if one already knew that A was looking for acquisitions and B was
|
|
seeking funds for expansion.</P>
|
|
<P>In general, traffic analysis by itself is not very useful. However,
|
|
in the context of a larger intelligence effort where quite a bit is
|
|
already known, it can be very useful. When you are solving a complex
|
|
puzzle, every little bit helps.</P>
|
|
<P><A href="#IPSEC">IPsec</A> itself does not defend against traffic
|
|
analysis, but carefully thought out systems using IPsec can provide at
|
|
least partial protection. In particular, one might want to encrypt more
|
|
traffic than was strictly necessary, route things in odd ways, or even
|
|
encrypt dummy packets, to confuse the analyst. We discuss this<A href="#traffic.resist">
|
|
here</A>.</P>
|
|
</DD>
|
|
<DT><A name="transport">Transport mode</A></DT>
|
|
<DD>An IPsec application in which the IPsec gateway is the destination
|
|
of the protected packets, a machine acts as its own gateway. Contrast
|
|
with<A href="#tunnel"> tunnel mode</A>.</DD>
|
|
<DT>Triple DES</DT>
|
|
<DD>see<A href="#3DES"> 3DES</A></DD>
|
|
<DT><A name="TTL">TTL</A></DT>
|
|
<DD><STRONG>T</STRONG>ime<STRONG> T</STRONG>o<STRONG> L</STRONG>ive,
|
|
used to control<A href="#DNS"> DNS</A> caching. Servers discard cached
|
|
records whose TTL expires</DD>
|
|
<DT><A name="tunnel">Tunnel mode</A></DT>
|
|
<DD>An IPsec application in which an IPsec gateway provides protection
|
|
for packets to and from other systems. Contrast with<A href="#transport">
|
|
transport mode</A>.</DD>
|
|
<DT><A name="2key">Two-key Triple DES</A></DT>
|
|
<DD>A variant of<A href="#3DES"> triple DES or 3DES</A> in which only
|
|
two keys are used. As in the three-key version, the order of operations
|
|
is<A href="#EDE"> EDE</A> or encrypt-decrypt-encrypt, but in the
|
|
two-key variant the first and third keys are the same.
|
|
<P>3DES with three keys has 3*56 = 168 bits of key but has only 112-bit
|
|
strength against a<A href="#meet"> meet-in-the-middle</A> attack, so it
|
|
is possible that the two key version is just as strong. Last I looked,
|
|
this was an open question in the research literature.</P>
|
|
<P>RFC 2451 defines triple DES for<A href="#IPSEC"> IPsec</A> as the
|
|
three-key variant. The two-key variant should not be used and is not
|
|
implemented directly in<A href="#FreeSWAN"> Linux FreeS/WAN</A>. It
|
|
cannot be used in automatically keyed mode without major fiddles in the
|
|
source code. For manually keyed connections, you could make Linux
|
|
FreeS/WAN talk to a two-key implementation by setting two keys the same
|
|
in /etc/ipsec.conf.</P>
|
|
</DD>
|
|
<DT><A name="U">U</A></DT>
|
|
<DT><A name="V">V</A></DT>
|
|
<DT><A name="virtual">Virtual Interface</A></DT>
|
|
<DD>A<A href="#Linux"> Linux</A> feature which allows one physical
|
|
network interface to have two or more IP addresses. See the<CITE> Linux
|
|
Network Administrator's Guide</CITE> in<A href="#kirch"> book form</A>
|
|
or<A href="http://metalab.unc.edu/LDP/LDP/nag/node1.html"> on the web</A>
|
|
for details.</DD>
|
|
<DT>Virtual Private Network</DT>
|
|
<DD>see<A href="#VPN"> VPN</A></DD>
|
|
<DT><A name="VPN">VPN</A></DT>
|
|
<DD><B>V</B>irtual<B> P</B>rivate<B> N</B>etwork, a network which can
|
|
safely be used as if it were private, even though some of its
|
|
communication uses insecure connections. All traffic on those
|
|
connections is encrypted.
|
|
<P><A href="#IPSEC">IPsec</A> is not the only technique available for
|
|
building VPNs, but it is the only method defined by<A href="#RFC"> RFCs</A>
|
|
and supported by many vendors. VPNs are by no means the only thing you
|
|
can do with IPsec, but they may be the most important application for
|
|
many users.</P>
|
|
</DD>
|
|
<DT><A name="VPNC">VPNC</A></DT>
|
|
<DD><A href="http://www.vpnc.org">Virtual Private Network Consortium</A>
|
|
, an association of vendors of VPN products.</DD>
|
|
<DT><A name="W">W</A></DT>
|
|
<DT><A name="Wassenaar.gloss">Wassenaar Arrangement</A></DT>
|
|
<DD>An international agreement restricting export of munitions and other
|
|
tools of war. Unfortunately, cryptographic software is also restricted
|
|
under the current version of the agreement.<A href="#Wassenaar">
|
|
Discussion</A>.</DD>
|
|
<DT><A name="web">Web of Trust</A></DT>
|
|
<DD><A href="#PGP">PGP</A>'s method of certifying keys. Any user can
|
|
sign a key; you decide which signatures or combinations of signatures
|
|
to accept as certification. This contrasts with the hierarchy of<A href="#CA">
|
|
CAs (Certification Authorities)</A> used in many<A href="#PKI"> PKIs
|
|
(Public Key Infrastructures)</A>.
|
|
<P>See<A href="#GTR"> Global Trust Register</A> for an interesting
|
|
addition to the web of trust.</P>
|
|
</DD>
|
|
<DT><A name="WEP">WEP (Wired Equivalent Privacy)</A></DT>
|
|
<DD>The cryptographic part of the<A href="#IEEE"> IEEE</A> standard for
|
|
wireless LANs. As the name suggests, this is designed to be only as
|
|
secure as a normal wired ethernet. Anyone with a network conection can
|
|
tap it. Its advocates would claim this is good design, refusing to
|
|
build in complex features beyond the actual requirements.
|
|
<P>Critics refer to WEP as "Wire<EM>tap</EM> Equivalent Privacy", and
|
|
consider it a horribly flawed design based on bogus "requirements". You
|
|
do not control radio waves as you might control your wires, so the
|
|
metaphor in the rationale is utterly inapplicable. A security policy
|
|
that chooses not to invest resources in protecting against certain
|
|
attacks which can only be conducted by people physically plugged into
|
|
your LAN may or may not be reasonable. The same policy is completely
|
|
unreasonable when someone can "plug in" from a laptop half a block
|
|
away..</P>
|
|
<P>There has been considerable analysis indicating that WEP is seriously
|
|
flawed. A FAQ on attacks against WEP is available. Part of it reads:</P>
|
|
<BLOCKQUOTE> ... attacks are practical to mount using only inexpensive
|
|
off-the-shelf equipment. We recommend that anyone using an 802.11
|
|
wireless network not rely on WEP for security, and employ other
|
|
security measures to protect their wireless network. Note that our
|
|
attacks apply to both 40-bit and the so-called 128-bit versions of WEP
|
|
equally well.</BLOCKQUOTE>
|
|
<P>WEP appears to be yet another instance of governments, and
|
|
unfortunately some vendors and standards bodies, deliberately promoting
|
|
hopelessly flawed "security" products, apparently mainly for the
|
|
benefit of eavesdropping agencies. See this<A href="#weak"> discussion</A>
|
|
.</P>
|
|
</DD>
|
|
<DT><A name="X">X</A></DT>
|
|
<DT><A name="X509">X.509</A></DT>
|
|
<DD>A standard from the<A href="http://www.itu.int"> ITU (International
|
|
Telecommunication Union)</A>, for hierarchical directories with
|
|
authentication services, used in many<A href="#PKI"> PKI</A>
|
|
implementations.
|
|
<P>Use of X.509 services, via the<A href="#LDAP"> LDAP protocol</A>, for
|
|
certification of keys is allowed but not required by the<A href="#IPSEC">
|
|
IPsec</A> RFCs. It is not yet implemented in<A href="#FreeSWAN"> Linux
|
|
FreeS/WAN</A>.</P>
|
|
</DD>
|
|
<DT>Xedia</DT>
|
|
<DD>A vendor of router and Internet access products, now part of Lucent.
|
|
Their QVPN products interoperate with Linux FreeS/WAN; see our<A href="#xedia">
|
|
interop document</A>.</DD>
|
|
<DT><A name="Y">Y</A></DT>
|
|
<DT><A name="Z">Z</A></DT>
|
|
</DL>
|
|
<HR>
|
|
<H1><A name="biblio">Bibliography for the Linux FreeS/WAN project</A></H1>
|
|
<P>For extensive bibliographic links, see the<A href="http://liinwww.ira.uka.de/bibliography/index.html">
|
|
Collection of Computer Science Bibliographies</A></P>
|
|
<P>See our<A href="web.html"> web links</A> for material available
|
|
online.</P>
|
|
<HR><A name="adams"> Carlisle Adams and Steve Lloyd<CITE> Understanding
|
|
Public Key Infrastructure</CITE>
|
|
<BR></A> Macmillan 1999 ISBN 1-57870-166-x
|
|
<P>An overview, mainly concentrating on policy and strategic issues
|
|
rather than the technical details. Both authors work for<A href="#PKI">
|
|
PKI</A> vendor<A href="http://www.entrust.com/"> Entrust</A>.</P>
|
|
<HR><A name="DNS.book"> Albitz, Liu & Loukides<CITE> DNS & BIND</CITE>
|
|
3rd edition
|
|
<BR></A> O'Reilly 1998 ISBN 1-56592-512-2
|
|
<P>The standard reference on the<A href="#DNS"> Domain Name Service</A>
|
|
and<A href="#BIND"> Berkeley Internet Name Daemon</A>.</P>
|
|
<HR><A name="anderson"> Ross Anderson</A>,<CITE> Security Engineering -
|
|
a Guide to Building Dependable Distributed Systems</CITE>
|
|
<BR> Wiley, 2001, ISBN 0471389226
|
|
<P>Easily the best book for the security professional I have seen.<STRONG>
|
|
Highly recommended</STRONG>. See the<A href="http://www.cl.cam.ac.uk/~rja14/book.html">
|
|
book web page</A>.</P>
|
|
<P>This is quite readable, but Schneier's<A href="#secrets"> Secrets and
|
|
Lies</A> might be an easier introduction.</P>
|
|
<HR><A name="puzzle"> Bamford<CITE> The Puzzle Palace, A report on NSA,
|
|
Americas's most Secret Agency</CITE>
|
|
<BR> Houghton Mifflin 1982 ISBN 0-395-31286-8</A>
|
|
<HR> Bamford<CITE> Body of Secrets</CITE>
|
|
<P>The sequel.</P>
|
|
<HR><A name="bander"> David Bander</A>,<CITE> Linux Security Toolkit</CITE>
|
|
<BR> IDG Books, 2000, ISBN: 0764546902
|
|
<P>This book has a short section on FreeS/WAN and includes Caldera Linux
|
|
on CD.</P>
|
|
<HR><A name="CZR"> Chapman, Zwicky & Russell</A>,<CITE> Building
|
|
Internet Firewalls</CITE>
|
|
<BR> O'Reilly 1995 ISBN 1-56592-124-0
|
|
<HR><A name="firewall.book"> Cheswick and Bellovin</A><CITE> Firewalls
|
|
and Internet Security: Repelling the Wily Hacker</CITE>
|
|
<BR> Addison-Wesley 1994 ISBN 0201633574
|
|
<P>A fine book on firewalls in particular and security in general from
|
|
two of AT&T's system adminstrators.</P>
|
|
<P>Bellovin has also done a number of<A href="#papers"> papers</A> on
|
|
IPsec and co-authored a<A href="#applied"> paper</A> on a large
|
|
FreeS/WAN application.</P>
|
|
<HR><A name="comer"> Comer<CITE> Internetworking with TCP/IP</CITE>
|
|
<BR> Prentice Hall</A>
|
|
<UL>
|
|
<LI>Vol. I: Principles, Protocols, & Architecture, 3rd Ed. 1995
|
|
ISBN:0-13-216987-8</LI>
|
|
<LI>Vol. II: Design, Implementation, & Internals, 2nd Ed. 1994
|
|
ISBN:0-13-125527-4</LI>
|
|
<LI>Vol. III: Client/Server Programming & Applications
|
|
<UL>
|
|
<LI>AT&T TLI Version 1994 ISBN:0-13-474230-3</LI>
|
|
<LI>BSD Socket Version 1996 ISBN:0-13-260969-X</LI>
|
|
<LI>Windows Sockets Version 1997 ISBN:0-13-848714-6</LI>
|
|
</UL>
|
|
</LI>
|
|
</UL>
|
|
<P>If you need to deal with the details of the network protocols, read
|
|
either this series or the<A href="#stevens"> Stevens and Wright</A>
|
|
series before you start reading the RFCs.</P>
|
|
<HR><A name="diffie"> Diffie and Landau</A><CITE> Privacy on the Line:
|
|
The Politics of Wiretapping and Encryption</CITE>
|
|
<BR> MIT press 1998 ISBN 0-262-04167-7 (hardcover) or 0-262-54100-9
|
|
<BR>
|
|
<HR><A name="d_and_hark"> Doraswamy and Harkins<CITE> IP Sec: The New
|
|
Security Standard for the Internet, Intranets and Virtual Private
|
|
Networks</CITE>
|
|
<BR> Prentice Hall 1999 ISBN: 0130118982</A>
|
|
<HR><A name="EFF"> Electronic Frontier Foundation<CITE> Cracking DES:
|
|
Secrets of Encryption Research, Wiretap Politics and Chip Design</CITE>
|
|
<BR></A> O'Reilly 1998 ISBN 1-56592-520-3
|
|
<P>To conclusively demonstrate that DES is inadequate for continued use,
|
|
the<A href="#EFF"> EFF</A> built a machine for just over $200,000 that
|
|
breaks DES encryption in under five days on average, under nine in the
|
|
worst case.</P>
|
|
<P>The book provides details of their design and, perhaps even more
|
|
important, discusses why they felt the project was necessary.
|
|
Recommended for anyone interested in any of the three topics mentioned
|
|
in the subtitle.</P>
|
|
<P>See also the<A href="http://www.eff.org/descracker.html"> EFF page on
|
|
this project</A> and our discussion of<A href="#desnotsecure"> DES
|
|
insecurity</A>.</P>
|
|
<HR> Martin Freiss<CITE> Protecting Networks with SATAN</CITE>
|
|
<BR> O'Reilly 1998 ISBN 1-56592-425-8
|
|
<BR> translated from a 1996 work in German
|
|
<P>SATAN is a Security Administrator's Tool for Analysing Networks. This
|
|
book is a tutorial in its use.</P>
|
|
<HR> Gaidosch and Kunzinger<CITE> A Guide to Virtual Private Networks</CITE>
|
|
<BR> Prentice Hall 1999 ISBN: 0130839647
|
|
<HR><A name="Garfinkel"> Simson Garfinkel</A><CITE> Database Nation: the
|
|
death of privacy in the 21st century</CITE>
|
|
<BR> O'Reilly 2000 ISBN 1-56592-653-6
|
|
<P>A thoughtful and rather scary book.</P>
|
|
<HR><A name="PGP"> Simson Garfinkel</A><CITE> PGP: Pretty Good Privacy</CITE>
|
|
<BR> O'Reilly 1995 ISBN 1-56592-098-8
|
|
<P>An excellent introduction and user manual for the<A href="#PGP"> PGP</A>
|
|
email-encryption package. PGP is a good package with a complex and
|
|
poorly-designed user interface. This book or one like it is a must for
|
|
anyone who has to use it at length.</P>
|
|
<P>The book covers using PGP in Unix, PC and Macintosh environments,
|
|
plus considerable background material on both the technical and
|
|
political issues around cryptography.</P>
|
|
<P>The book is now seriously out of date. It does not cover recent
|
|
developments such as commercial versions since PGP 5, the Open PGP
|
|
standard or GNU PG..</P>
|
|
<HR><A name="practical"> Garfinkel and Spafford</A><CITE> Practical Unix
|
|
Security</CITE>
|
|
<BR> O'Reilly 1996 ISBN 1-56592-148-8
|
|
<P>A standard reference.</P>
|
|
<P>Spafford's web page has an excellent collection of<A href="http://www.cs.purdue.edu/coast/hotlist">
|
|
crypto and security links</A>.</P>
|
|
<HR><A name="Kahn"> David Kahn</A><CITE> The Codebreakers: the
|
|
Comprehensive History of Secret Communications from Ancient Times to
|
|
the Internet</CITE>
|
|
<BR> second edition Scribner 1996 ISBN 0684831309
|
|
<P>A history of codes and code-breaking from ancient Egypt to the 20th
|
|
century. Well-written and exhaustively researched.<STRONG> Highly
|
|
recommended</STRONG>, even though it does not have much on computer
|
|
cryptography.</P>
|
|
<HR> David Kahn<CITE> Seizing the Enigma, The Race to Break the German
|
|
U-Boat codes, 1939-1943</CITE>
|
|
<BR> Houghton Mifflin 1991 ISBN 0-395-42739-8
|
|
<HR><A name="kirch"> Olaf Kirch</A><CITE> Linux Network Administrator's
|
|
Guide</CITE>
|
|
<BR> O'Reilly 1995 ISBN 1-56592-087-2
|
|
<P>Now becoming somewhat dated in places, but still a good introductory
|
|
book and general reference.</P>
|
|
<HR><A name="LinVPN"> Kolesnikov and Hatch</A>,<CITE> Building Linux
|
|
Virtual Private Networks (VPNs)</CITE>
|
|
<BR> New Riders 2002
|
|
<P>This has had a number of favorable reviews, including<A href="http://www.slashdot.org/article.pl?sid=02/02/27/0115214&mode=thread&tid=172">
|
|
this one</A> on Slashdot. The book has a<A href="http://www.buildinglinuxvpns.net/">
|
|
web site</A>.</P>
|
|
<HR><A name="RFCs"> Pete Loshin<CITE> Big Book of IPsec RFCs</CITE>
|
|
<BR> Morgan Kaufmann 2000 ISBN: 0-12-455839-9</A>
|
|
<HR><A name="crypto"> Steven Levy<CITE> Crypto: How the Code Rebels Beat
|
|
the Government -- Saving Privacy in the Digital Age</CITE></A>
|
|
<BR> Penguin 2001, ISBN 0-670--85950-8
|
|
<P><STRONG>Highly recommended</STRONG>. A fine history of recent (about
|
|
1970-2000) developments in the field, and the related political
|
|
controversies. FreeS/WAN project founder and leader John Gilmore
|
|
appears several times.</P>
|
|
<P>The book does not cover IPsec or FreeS/WAN, but this project is very
|
|
much another battle in the same war. See our discussion of the<A href="politics.html">
|
|
politics</A>.</P>
|
|
<HR><A name="GTR"> Matyas, Anderson et al.</A><CITE> The Global Trust
|
|
Register</CITE>
|
|
<BR> Northgate Consultants Ltd 1998 ISBN: 0953239705
|
|
<BR> hard cover edition MIT Press 1999 ISBN 0262511053
|
|
<P>From<A href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register">
|
|
their web page:</A></P>
|
|
<BLOCKQUOTE> This book is a register of the fingerprints of the world's
|
|
most important public keys; it implements a top-level certification
|
|
authority (CA) using paper and ink rather than in an electronic system.</BLOCKQUOTE>
|
|
<HR><A name="handbook"> Menezies, van Oorschot and Vanstone<CITE>
|
|
Handbook of Applied Cryptography</CITE></A>
|
|
<BR> CRC Press 1997
|
|
<BR> ISBN 0-8493-8523-7
|
|
<P>An excellent reference. Read<A href="#schneier"> Schneier</A> before
|
|
tackling this.</P>
|
|
<HR> Michael Padlipsky<CITE> Elements of Networking Style</CITE>
|
|
<BR> Prentice-Hall 1985 ISBN 0-13-268111-0 or 0-13-268129-3
|
|
<P>Probably<STRONG> the funniest technical book ever written</STRONG>,
|
|
this is a vicious but well-reasoned attack on the OSI "seven layer
|
|
model" and all that went with it. Several chapters of it are also
|
|
available as RFCs 871 to 875.</P>
|
|
<HR><A name="matrix"> John S. Quarterman</A><CITE> The Matrix: Computer
|
|
Networks and Conferencing Systems Worldwide</CITE>
|
|
<BR> Digital Press 1990 ISBN 155558-033-5
|
|
<BR> Prentice-Hall ISBN 0-13-565607-9
|
|
<P>The best general treatment of computer-mediated communication we have
|
|
seen. It naturally has much to say about the Internet, but also covers
|
|
UUCP, Fidonet and so on.</P>
|
|
<HR><A name="ranch"> David Ranch</A><CITE> Securing Linux Step by Step</CITE>
|
|
<BR> SANS Institute, 1999
|
|
<P><A href="http://www.sans.org/">SANS</A> is a respected organisation,
|
|
this guide is part of a well-known series, and Ranch has previously
|
|
written the useful<A href=" http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
|
|
Trinity OS</A> guide to securing Linux, so my guess would be this is a
|
|
pretty good book. I haven't read it yet, so I'm not certain. It can be
|
|
ordered online from<A href="http://www.sans.org/"> SANS</A>.</P>
|
|
<P>Note (Mar 1, 2002): a new edition with different editors in the
|
|
works. Expect it this year.</P>
|
|
<HR><A name="schneier"> Bruce Schneier</A><CITE> Applied Cryptography,
|
|
Second Edition</CITE>
|
|
<BR> John Wiley & Sons, 1996
|
|
<BR> ISBN 0-471-12845-7 hardcover
|
|
<BR> ISBN 0-471-11709-9 paperback
|
|
<P>A standard reference on computer cryptography. For more recent
|
|
essays, see the<A href="http://www.counterpane.com/"> author's
|
|
company's web site</A>.</P>
|
|
<HR><A name="secrets"> Bruce Schneier</A><CITE> Secrets and Lies</CITE>
|
|
<BR> Wiley 2000, ISBN 0-471-25311-1
|
|
<P>An interesting discussion of security and privacy issues, written
|
|
with more of an "executive overview" approach rather than a narrow
|
|
focus on the technical issues.<STRONG> Highly recommended</STRONG>.</P>
|
|
<P>This is worth reading even if you already understand security issues,
|
|
or think you do. To go deeper, follow it with Anderson's<A href="#anderson">
|
|
Security Engineering</A>.</P>
|
|
<HR><A name="VPNbook"> Scott, Wolfe and Irwin<CITE> Virtual Private
|
|
Networks</CITE></A>
|
|
<BR> 2nd edition, O'Reilly 1999 ISBN: 1-56592-529-7
|
|
<P>This is the only O'Reilly book, out of a dozen I own, that I'm
|
|
disappointed with. It deals mainly with building VPNs with various
|
|
proprietary tools --<A href="#PPTP"> PPTP</A>,<A href="#ssh"> SSH</A>,
|
|
Cisco PIX, ... -- and touches only lightly on IPsec-based approaches.</P>
|
|
<P>That said, it appears to deal competently with what it does cover and
|
|
it has readable explanations of many basic VPN and security concepts.
|
|
It may be exactly what some readers require, even if I find the
|
|
emphasis unfortunate.</P>
|
|
<HR><A name="LASG"> Kurt Seifried<CITE> Linux Administrator's Security
|
|
Guide</CITE></A>
|
|
<P>Available online from<A href="http://www.securityportal.com/lasg/">
|
|
Security Portal</A>. It has fairly extensive coverage of IPsec.</P>
|
|
<HR><A name="Smith"> Richard E Smith<CITE> Internet Cryptography</CITE>
|
|
<BR></A> ISBN 0-201-92480-3, Addison Wesley, 1997
|
|
<P>See the book's<A href="http://www.visi.com/crypto/inet-crypto/index.html">
|
|
home page</A></P>
|
|
<HR><A name="neal"> Neal Stephenson<CITE> Cryptonomicon</CITE></A>
|
|
<BR> Hardcover ISBN -380-97346-4, Avon, 1999.
|
|
<P>A novel in which cryptography and the net figure prominently.<STRONG>
|
|
Highly recommended</STRONG>: I liked it enough I immediately went out
|
|
and bought all the author's other books.</P>
|
|
<P>There is also a paperback edition. Sequels are expected.</P>
|
|
<HR><A name="stevens"> Stevens and Wright</A><CITE> TCP/IP Illustrated</CITE>
|
|
<BR> Addison-Wesley
|
|
<UL>
|
|
<LI>Vol. I: The Protocols 1994 ISBN:0-201-63346-9</LI>
|
|
<LI>Vol. II: The Implementation 1995 ISBN:0-201-63354-X</LI>
|
|
<LI>Vol. III: TCP for Transactions, HTTP, NNTP, and the UNIX Domain
|
|
Protocols 1996 ISBN: 0-201-63495-3</LI>
|
|
</UL>
|
|
<P>If you need to deal with the details of the network protocols, read
|
|
either this series or the<A href="#comer"> Comer</A> series before you
|
|
start reading the RFCs.</P>
|
|
<HR><A name="Rubini"> Rubini</A><CITE> Linux Device Drivers</CITE>
|
|
<BR> O'Reilly & Associates, Inc. 1998 ISBN 1-56592-292-1
|
|
<HR><A name="Zeigler"> Robert Zeigler</A><CITE> Linux Firewalls</CITE>
|
|
<BR> Newriders Publishing, 2000 ISBN 0-7537-0900-9
|
|
<P>A good book, with detailed coverage of ipchains(8) firewalls and of
|
|
many related issues.</P>
|
|
<HR>
|
|
<H1><A name="RFC">IPsec RFCs and related documents</A></H1>
|
|
<H2><A name="RFCfile">The RFCs.tar.gz Distribution File</A></H2>
|
|
<P>The Linux FreeS/WAN distribution is available from<A href="http://www.xs4all.nl/~freeswan">
|
|
our primary distribution site</A> and various mirror sites. To give
|
|
people more control over their downloads, the RFCs that define IP
|
|
security are bundled separately in the file RFCs.tar.gz.</P>
|
|
<P>The file you are reading is included in the main distribution and is
|
|
available on the web site. It describes the RFCs included in the<A href="#RFCs.tar.gz">
|
|
RFCs.tar.gz</A> bundle and gives some pointers to<A href="#sources">
|
|
other ways to get them</A>.</P>
|
|
<H2><A name="sources">Other sources for RFCs & Internet drafts</A></H2>
|
|
<H3><A name="RFCdown">RFCs</A></H3>
|
|
<P>RFCs are downloadble at many places around the net such as:</P>
|
|
<UL>
|
|
<LI><A href="http://www.rfc-editor.org">http://www.rfc-editor.org</A></LI>
|
|
<LI><A href="http://nis.nsf.net/internet/documents/rfc">NSF.net</A></LI>
|
|
<LI><A href="http://sunsite.doc.ic.ac.uk/computing/internet/rfc">Sunsite
|
|
in the UK</A></LI>
|
|
</UL>
|
|
<P>browsable in HTML form at others such as:</P>
|
|
<UL>
|
|
<LI><A href="http://www.landfield.com/rfcs/index.html">landfield.com</A></LI>
|
|
<LI><A href="http://www.library.ucg.ie/Connected/RFC">Connected Internet
|
|
Encyclopedia</A></LI>
|
|
</UL>
|
|
<P>and some of them are available in translation:</P>
|
|
<UL>
|
|
<LI><A href="http://www.eisti.fr/eistiweb/docs/normes/">French</A></LI>
|
|
</UL>
|
|
<P>There is also a published<A href="#RFCs"> Big Book of IPSEC RFCs</A>.</P>
|
|
<H3><A name="drafts">Internet Drafts</A></H3>
|
|
<P>Internet Drafts, working documents which sometimes evolve into RFCs,
|
|
are also available.</P>
|
|
<UL>
|
|
<LI><A href="http://www.ietf.org/ID.html">Overall reference page</A></LI>
|
|
<LI><A href="http://www.ietf.org/ids.by.wg/ipsec.html">IPsec</A> working
|
|
group</LI>
|
|
<LI><A href="http://www.ietf.org/ids.by.wg/ipsra.html">IPSRA (IPsec
|
|
Remote Access)</A> working group</LI>
|
|
<LI><A href="http://www.ietf.org/ids.by.wg/ipsp.html">IPsec Policy</A>
|
|
working group</LI>
|
|
<LI><A href="http://www.ietf.org/ids.by.wg/kink.html">KINK (Kerberized
|
|
Internet Negotiation of Keys)</A> working group</LI>
|
|
</UL>
|
|
<P>Note: some of these may be obsolete, replaced by later drafts or by
|
|
RFCs.</P>
|
|
<H3><A name="FIPS1">FIPS standards</A></H3>
|
|
<P>Some things used by<A href="#IPSEC"> IPsec</A>, such as<A href="#DES">
|
|
DES</A> and<A href="#SHA"> SHA</A>, are defined by US government
|
|
standards called<A href="#FIPS"> FIPS</A>. The issuing organisation,<A href="#NIST">
|
|
NIST</A>, have a<A href="http://www.itl.nist.gov/div897/pubs"> FIPS
|
|
home page</A>.</P>
|
|
<H2><A name="RFCs.tar.gz">What's in the RFCs.tar.gz bundle?</A></H2>
|
|
<P>All filenames are of the form rfc*.txt, with the * replaced with the
|
|
RFC number.</P>
|
|
<PRE>RFC# Title</PRE>
|
|
<H3><A name="rfc.ov">Overview RFCs</A></H3>
|
|
<PRE>2401 Security Architecture for the Internet Protocol
|
|
2411 IP Security Document Roadmap</PRE>
|
|
<H3><A name="basic.prot">Basic protocols</A></H3>
|
|
<PRE>2402 IP Authentication Header
|
|
2406 IP Encapsulating Security Payload (ESP)</PRE>
|
|
<H3><A name="key.ike">Key management</A></H3>
|
|
<PRE>2367 PF_KEY Key Management API, Version 2
|
|
2407 The Internet IP Security Domain of Interpretation for ISAKMP
|
|
2408 Internet Security Association and Key Management Protocol (ISAKMP)
|
|
2409 The Internet Key Exchange (IKE)
|
|
2412 The OAKLEY Key Determination Protocol
|
|
2528 Internet X.509 Public Key Infrastructure</PRE>
|
|
<H3><A name="rfc.detail">Details of various things used</A></H3>
|
|
<PRE>2085 HMAC-MD5 IP Authentication with Replay Prevention
|
|
2104 HMAC: Keyed-Hashing for Message Authentication
|
|
2202 Test Cases for HMAC-MD5 and HMAC-SHA-1
|
|
2207 RSVP Extensions for IPSEC Data Flows
|
|
2403 The Use of HMAC-MD5-96 within ESP and AH
|
|
2404 The Use of HMAC-SHA-1-96 within ESP and AH
|
|
2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
|
|
2410 The NULL Encryption Algorithm and Its Use With IPsec
|
|
2451 The ESP CBC-Mode Cipher Algorithms
|
|
2521 ICMP Security Failures Messages</PRE>
|
|
<H3><A name="rfc.ref">Older RFCs which may be referenced</A></H3>
|
|
<PRE>1321 The MD5 Message-Digest Algorithm
|
|
1828 IP Authentication using Keyed MD5
|
|
1829 The ESP DES-CBC Transform
|
|
1851 The ESP Triple DES Transform
|
|
1852 IP Authentication using Keyed SHA</PRE>
|
|
<H3><A name="rfc.dns">RFCs for secure DNS service, which IPsec may use</A>
|
|
</H3>
|
|
<PRE>2137 Secure Domain Name System Dynamic Update
|
|
2230 Key Exchange Delegation Record for the DNS
|
|
2535 Domain Name System Security Extensions
|
|
2536 DSA KEYs and SIGs in the Domain Name System (DNS)
|
|
2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
|
|
2538 Storing Certificates in the Domain Name System (DNS)
|
|
2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</PRE>
|
|
<H3><A name="rfc.exp">RFCs labelled "experimental"</A></H3>
|
|
<PRE>2521 ICMP Security Failures Messages
|
|
2522 Photuris: Session-Key Management Protocol
|
|
2523 Photuris: Extended Schemes and Attributes</PRE>
|
|
<H3><A name="rfc.rel">Related RFCs</A></H3>
|
|
<PRE>1750 Randomness Recommendations for Security
|
|
1918 Address Allocation for Private Internets
|
|
1984 IAB and IESG Statement on Cryptographic Technology and the Internet
|
|
2144 The CAST-128 Encryption Algorithm</PRE>
|
|
<HR>
|
|
<H1><A name="roadmap">Distribution Roadmap: What's Where in Linux
|
|
FreeS/WAN</A></H1>
|
|
<P> This file is a guide to the locations of files within the FreeS/WAN
|
|
distribution. Everything described here should be on your system once
|
|
you download, gunzip, and untar the distribution.</P>
|
|
<P>This distribution contains two major subsystems</P>
|
|
<DL>
|
|
<DT><A href="#klips.roadmap">KLIPS</A></DT>
|
|
<DD>the kernel code</DD>
|
|
<DT><A href="#pluto.roadmap">Pluto</A></DT>
|
|
<DD>the user-level key-management daemon</DD>
|
|
</DL>
|
|
<P>plus assorted odds and ends.</P>
|
|
<H2><A name="top">Top directory</A></H2>
|
|
<P>The top directory has essential information in text files:</P>
|
|
<DL>
|
|
<DT>README</DT>
|
|
<DD>introduction to the software</DD>
|
|
<DT>INSTALL</DT>
|
|
<DD>short experts-only installation procedures. More detalied procedures
|
|
are in<A href="install.html"> installation</A> and<A href="config.html">
|
|
configuration</A> HTML documents.</DD>
|
|
<DT>BUGS</DT>
|
|
<DD>major known bugs in the current release.</DD>
|
|
<DT>CHANGES</DT>
|
|
<DD>changes from previous releases</DD>
|
|
<DT>CREDITS</DT>
|
|
<DD>acknowledgement of contributors</DD>
|
|
<DT>COPYING</DT>
|
|
<DD>licensing and distribution information</DD>
|
|
</DL>
|
|
<H2><A name="doc">Documentation</A></H2>
|
|
<P> The doc directory contains the bulk of the documentation, most of it
|
|
in HTML format. See the<A href="index.html"> index file</A> for
|
|
details.</P>
|
|
<H2><A name="klips.roadmap">KLIPS: kernel IP security</A></H2>
|
|
<P><A href="#KLIPS"> KLIPS</A> is<STRONG> K</STRONG>erne<STRONG>L</STRONG><STRONG>
|
|
IP</STRONG><STRONG> S</STRONG>ecurity. It lives in the klips directory,
|
|
of course.</P>
|
|
<DL>
|
|
<DT>klips/doc</DT>
|
|
<DD>documentation</DD>
|
|
<DT>klips/patches</DT>
|
|
<DD>patches for existing kernel files</DD>
|
|
<DT>klips/test</DT>
|
|
<DD>test stuff</DD>
|
|
<DT>klips/utils</DT>
|
|
<DD>low-level user utilities</DD>
|
|
<DT>klips/net/ipsec</DT>
|
|
<DD>actual klips kernel files</DD>
|
|
<DT>klips/src</DT>
|
|
<DD>symbolic link to klips/net/ipsec
|
|
<P>The "make insert" step of installation installs the patches and makes
|
|
a symbolic link from the kernel tree to klips/net/ipsec. The odd name
|
|
of klips/net/ipsec is dictated by some annoying limitations of the
|
|
scripts which build the Linux kernel. The symbolic-link business is a
|
|
bit messy, but all the alternatives are worse.</P>
|
|
<P></P>
|
|
</DD>
|
|
<DT>klips/utils</DT>
|
|
<DD>Utility programs:
|
|
<P></P>
|
|
<DL>
|
|
<DT>eroute</DT>
|
|
<DD>manipulate IPsec extended routing tables</DD>
|
|
<DT>klipsdebug</DT>
|
|
<DD>set Klips (kernel IPsec support) debug features and level</DD>
|
|
<DT>spi</DT>
|
|
<DD>manage IPsec Security Associations</DD>
|
|
<DT>spigrp</DT>
|
|
<DD>group/ungroup IPsec Security Associations</DD>
|
|
<DT>tncfg</DT>
|
|
<DD>associate IPsec virtual interface with real interface</DD>
|
|
</DL>
|
|
<P>These are all normally invoked by ipsec(8) with commands such as</P>
|
|
<PRE> ipsec tncfg <VAR>arguments</VAR></PRE>
|
|
There are section 8 man pages for all of these; the names have "ipsec_"
|
|
as a prefix, so your man command should be something like:
|
|
<PRE> man 8 ipsec_tncfg</PRE>
|
|
</DD>
|
|
</DL>
|
|
<H2><A name="pluto.roadmap">Pluto key and connection management daemon</A>
|
|
</H2>
|
|
<P><A href="#Pluto"> Pluto</A> is our key management and negotiation
|
|
daemon. It lives in the pluto directory, along with its low-level user
|
|
utility, whack.</P>
|
|
<P> There are no subdirectories. Documentation is a man page,<A href="manpage.d/ipsec_pluto.8.html">
|
|
pluto.8</A>. This covers whack as well.</P>
|
|
<H2><A name="utils">Utils</A></H2>
|
|
<P> The utils directory contains a growing collection of higher-level
|
|
user utilities, the commands that administer and control the software.
|
|
Most of the things that you will actually have to run yourself are in
|
|
there.</P>
|
|
<DL>
|
|
<DT>ipsec</DT>
|
|
<DD>invoke IPsec utilities
|
|
<P>ipsec(8) is normally the only program installed in a standard
|
|
directory, /usr/local/sbin. It is used to invoke the others, both those
|
|
listed below and the ones in klips/utils mentioned above.</P>
|
|
<P></P>
|
|
</DD>
|
|
<DT>auto</DT>
|
|
<DD>control automatically-keyed IPsec connections</DD>
|
|
<DT>manual</DT>
|
|
<DD>take manually-keyed IPsec connections up and down</DD>
|
|
<DT>barf</DT>
|
|
<DD>generate copious debugging output</DD>
|
|
<DT>look</DT>
|
|
<DD>generate moderate amounts of debugging output</DD>
|
|
</DL>
|
|
<P> There are .8 manual pages for these. look is covered in barf.8. The
|
|
man pages have an "ipsec_" prefix so your man command should be
|
|
something like:</P>
|
|
<PRE>
|
|
man 8 ipsec_auto
|
|
</PRE>
|
|
<P> Examples are in various files with names utils/*.eg</P>
|
|
<H2><A name="lib">Libraries</A></H2>
|
|
<H3><A name="fswanlib">FreeS/WAN Library</A></H3>
|
|
<P> The lib directory is the FreeS/WAN library, also steadily growing,
|
|
used by both user-level and kernel code.
|
|
<BR /> It includes section 3<A href="manpages.html"> man pages</A> for
|
|
the library routines.</P>
|
|
<H3><A name="otherlib">Imported Libraries</A></H3>
|
|
<H4><A NAME="33_6_2_1">LibDES</A></H4>
|
|
The libdes library, originally from SSLeay, is used by both Klips and
|
|
Pluto for<A href="#3DES"> Triple DES</A> encryption. Single DES is not
|
|
used because<A href="#desnotsecure"> it is insecure</A>.
|
|
<P> Note that this library has its own license, different from the<A href="#GPL">
|
|
GPL</A> used for other code in FreeS/WAN.</P>
|
|
<P> The library includes its own documentation.</P>
|
|
<H4><A NAME="33_6_2_2">GMP</A></H4>
|
|
The GMP (GNU multi-precision) library is used for multi-precision
|
|
arithmetic in Pluto's key-exchange code and public key code.
|
|
<P> Older versions (up to 1.7) of FreeS/WAN included a copy of this
|
|
library in the FreeS/WAN distribution.</P>
|
|
<P> Since 1.8, we have begun to rely on the system copy of GMP.</P>
|
|
<HR>
|
|
<H1><A name="umltesting">User-Mode-Linux Testing guide</A></H1>
|
|
<P> User mode linux is a way to compile a linux kernel such that it can
|
|
run as a process in another linux system (potentially as a *BSD or
|
|
Windows process later). See<A HREF="http://user-mode-linux.sourceforge.net/">
|
|
http://user-mode-linux.sourceforge.net/</A></P>
|
|
<P> UML is a good platform for testing and experimenting with FreeS/WAN.
|
|
It allows several network nodes to be simulated on a single machine.
|
|
Creating, configuring, installing, monitoring, and controling these
|
|
nodes is generally easier and easier to script with UML than real
|
|
hardware.</P>
|
|
<P> You'll need about 500Mb of disk space for a full
|
|
sunrise-east-west-sunset setup. You can possibly get this down by 130Mb
|
|
if you remove the sunrise/sunset kernel build. If you just want to run,
|
|
then you can even remove the east/west kernel build.</P>
|
|
<P> Nothing need be done as super user. In a couple of steps, we note
|
|
where super user is required to install commands in system-wide
|
|
directories, but ~/bin could be used instead. UML seems to use a
|
|
system-wide /tmp/uml directory so different users may interfere with
|
|
one another. Later UMLs use ~/.uml instead, so multiple users running
|
|
UML tests should not be a problem, but note that a single user running
|
|
the UML tests will only be able run one set. Further, UMLs sometimes
|
|
get stuck and hang around. These "zombies" (most will actually be in
|
|
the "T" state in the process table) will interfere with subsequent
|
|
tests.</P>
|
|
<H2><A NAME="34_1">Preliminary Notes on BIND</A></H2>
|
|
<P> As of 2003/3/1, the Light-Weight Resolver is used by pluto. This
|
|
requires that BIND9 be running. It also requires that BIND9 development
|
|
libraries be present in the build environment. The DNSSEC code is only
|
|
truly functional in BIND9 snapshots. The library code could be 9.2.2,
|
|
we believe. We are using BIND9 20021115 snapshot code from<A HREF="ftp://ftp.isc.org/isc/bind9/snapshots">
|
|
ftp://ftp.isc.org/isc/bind9/snapshots</A>.</P>
|
|
<P> FreeS/WAN may well require a newer BIND than is on your system. Many
|
|
distributions have moved to BIND9.2.2 recently due to a security
|
|
advisory. BIND is five components.</P>
|
|
<OL>
|
|
<LI> named</LI>
|
|
<LI> dnssec-*</LI>
|
|
<LI> client side resolver libraries</LI>
|
|
<LI> client side utility libraries I thought there were lib and named
|
|
parts to dnsssec...</LI>
|
|
<LI> dynamic DNS update utilities</LI>
|
|
</OL>
|
|
<P> The only piece that we need for *building* is #4. That's the only
|
|
part that has to be on the build host. What is the difference between
|
|
resolver and util libs? If you want to edit
|
|
testing/baseconfigs/all/etc/bind, you'll need a snapshot version. The
|
|
resolver library contains the resolver. FreeS/WAN has its own copy of
|
|
that in lib/liblwres.</P>
|
|
<H2><A NAME="34_2">Steps to Install UML for FreeS/WAN</A></H2>
|
|
<OL>
|
|
<LI> Get the following files:
|
|
<OL type="a">
|
|
<LI> from<A HREF="http://www.sandelman.ottawa.on.ca/freeswan/uml/">
|
|
http://www.sandelman.ottawa.on.ca/freeswan/uml/</A>
|
|
umlfreeroot-15.1.tar.gz (or highest numbered one). This is a debian
|
|
potato root file system. You can use this even on a Redhat host, as it
|
|
has the newer GLIBC2.2 libraries as well.
|
|
<!-- If you are using
|
|
Redhat 7.2 or newer as your development machine, you can create the
|
|
image from your installation media. See <A HREF="uml-rhroot.html">Building a RedHat root"></A>.
|
|
A future document will explain how to build this from .DEB files as well.
|
|
-->
|
|
|
|
<!--
|
|
<LI> umlfreesharemini.tar.gz (or umlfreeshareall.tar.gz).
|
|
If you are a Debian potato user, you don't need it you can use your
|
|
native /usr/share.
|
|
</UL>
|
|
-->
|
|
</LI>
|
|
<LI> From<A HREF="ftp://ftp.xs4all.nl/pub/crypto/freeswan/">
|
|
ftp://ftp.xs4all.nl/pub/crypto/freeswan/</A> a snapshot or release
|
|
(1.92 or better)</LI>
|
|
<LI> From a<A HREF="http://www.kernel.org/mirrors/">
|
|
http://www.kernel.org mirror</A>, the virgin 2.4.19 kernel. Please
|
|
realize that we have defaults in our tree for kernel configuration. We
|
|
try to track the latest UML kernels. If you use a newer kernel, you may
|
|
have faults in the kernel build process. You can see what the latest
|
|
that is being regularly tested by visiting<A HREF="http://bugs.freeswan.org:81/regress/HEAD/lastgood/freeswan-regress-env.sh">
|
|
freeswan-regress-env.sh</A>.</LI>
|
|
<LI>
|
|
<!-- Note: this step is refered to as "step 1d" below. -->
|
|
Get<A HREF="http://ftp.nl.linux.org/uml/">
|
|
http://ftp.nl.linux.org/uml/</A> uml-patch-2.4.19-47.bz2 or the one
|
|
associated with your kernel. As of 2003/03/05, uml-patch-2.4.19-47.bz2
|
|
works for us.<STRONG> More recent versions of the patch have not been
|
|
tested by us.</STRONG></LI>
|
|
<LI> You'll probably want to visit<A HREF="http://user-mode-linux.sourceforge.net">
|
|
http://user-mode-linux.sourceforge.net</A> and get the UML utilities.
|
|
These are not needed for the build or interactive use (but
|
|
recommended). They are necessary for the regression testing procedures
|
|
used by "make check". We currently use uml_utilities_20020212.tar.bz2.</LI>
|
|
<LI> You need tcpdump version 3.7.1 or better. This is newer than the
|
|
version included in most LINUX distributions. You can check the version
|
|
of an installed tcpdump with the --version flag. If you need a newer
|
|
tcpdump fetch both tcpdump and libpcap source tar files from<A HREF="http://www.tcpdump.org/">
|
|
http://www.tcpdump.org/</A> or a mirror.</LI>
|
|
</OL>
|
|
</LI>
|
|
<LI> Pick a suitable place, and extract the following files:
|
|
<OL type="a">
|
|
<LI>
|
|
<!-- Note: this step is refered to as "step 2a" later. -->
|
|
2.4.19 kernel. For instance:
|
|
<PRE>
|
|
<CODE> cd /c2/kernel
|
|
tar xzvf ../download/pub/linux/kernel/v2.4/linux-2.4.19.tar.gz
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> extract the umlfreeroot file
|
|
<!-- (unless you <A HREF="uml-rhroot.html">built your own from RPMs</A>) -->
|
|
|
|
<PRE>
|
|
<CODE> mkdir -p /c2/user-mode-linux/basic-root
|
|
cd /c2/user-mode-linux/basic-root
|
|
tar xzvf ../download/umlfreeroot-15.1.tar.gz
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> FreeSWAN itself (or checkout "all" from CVS)
|
|
<PRE>
|
|
<CODE> mkdir -p /c2/freeswan/sandbox
|
|
cd /c2/freeswan/sandbox
|
|
tar xzvf ../download/snapshot.tar.gz
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
</OL>
|
|
</LI>
|
|
<LI> If you need to build a newer tcpdump:
|
|
<UL>
|
|
<LI> Make sure you have OpenSSL installed -- it is needed for
|
|
cryptographic routines.</LI>
|
|
<LI> Unpack libpcap and tcpdump source in parallel directories (the
|
|
tcpdump build procedures look for libpcap next door).</LI>
|
|
<LI> Change directory into the libpcap source directory and then build
|
|
the library:
|
|
<PRE>
|
|
<CODE> ./configure
|
|
make
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> Change into the tcpdump source directory, build tcpdump, and
|
|
install it.
|
|
<PRE>
|
|
<CODE> ./configure
|
|
make
|
|
# Need to be superuser to install in system directories.
|
|
# Installing in ~/bin would be an alternative.
|
|
su -c "make install"
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI> If you need the uml utilities, unpack them somewhere then build and
|
|
install them:
|
|
<PRE>
|
|
<CODE> cd tools
|
|
make all
|
|
# Need to be superuser to install in system directories.
|
|
# Installing in ~/bin would be an alternative.
|
|
su -c "make install BIN_DIR=/usr/local/bin"
|
|
</CODE>
|
|
</PRE>
|
|
</LI>
|
|
<LI> set up the configuration file
|
|
<UL>
|
|
<LI> <CODE>cd /c2/freeswan/sandbox/freeswan-1.97/testing/utils</CODE></LI>
|
|
<LI> copy umlsetup-sample.sh to ../../umlsetup.sh: <CODE> cp
|
|
umlsetup-sample.sh ../../umlsetup.sh</CODE></LI>
|
|
<LI> open up ../../umlsetup.sh in your favorite editor.</LI>
|
|
<LI> change POOLSPACE= to point to the place with at least 500Mb of
|
|
disk. Best if it is on the same partition as the "umlfreeroot"
|
|
extraction, as it will attempt to use hard links if possible to save
|
|
disk space.</LI>
|
|
<LI> Set TESTINGROOT if you intend to run the script outside of the
|
|
sandbox/snapshot/release directory. Otherwise, it will configure
|
|
itself.</LI>
|
|
<LI> KERNPOOL should point to the directory with your 2.4.19 kernel
|
|
tree. This tree should be unconfigured! This is the directory you used
|
|
in step 2a.</LI>
|
|
<LI> UMLPATCH should point at the bz2 file you downloaded at 1d. If
|
|
using a kernel that already includes the patch, set this to /dev/null.</LI>
|
|
<LI> FREESWANDIR should point at the directory where you unpacked the
|
|
snapshot/release. Include the "freeswan-snap2001sep16b" or whatever in
|
|
it. If you are running from CVS, then you point at the directory where
|
|
top, klips, etc. are. The script will fix up the directory so that it
|
|
can be used.</LI>
|
|
<LI> BASICROOT should be set to the directory used in 2b, or to the
|
|
directory that you created with RPMs.</LI>
|
|
<LI> SHAREDIR should be set to the directory used in 2c, to /usr/share
|
|
for Debian potato users, or to $BASICROOT/usr/share.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>
|
|
<PRE> <CODE>cd $TESTINGROOT/utils
|
|
sh make-uml.sh
|
|
</CODE></PRE>
|
|
It will grind for awhile. If there are errors it will bail. If so, run
|
|
it under "script" and send the output to [email protected].</LI>
|
|
<LI> You will have a bunch of stuff under $POOLSPACE. Open four xterms:
|
|
<PRE> <CODE> for i in sunrise sunset east west
|
|
do
|
|
xterm -name $i -title $i -e $POOLSPACE/$i/start.sh done
|
|
</CODE></PRE>
|
|
</LI>
|
|
<LI> Login as root. Password is "root" (Note, these virtual machines are
|
|
networked together, but are not configured to talk to the rest of the
|
|
world.)</LI>
|
|
<LI> verify that pluto started on east/west, run "ipsec look"</LI>
|
|
<LI> login to sunrise. run "ping sunset"</LI>
|
|
<LI> login to west. run "tcpdump -p -i eth1 -n" (tcpdump must be version
|
|
3.7.1 or newer)</LI>
|
|
<LI> Closing a console xterm will shut down that UML.</LI>
|
|
<LI> You can "make check", if you want to. It is run from
|
|
/c2/freeswan/sandbox/freeswan-1.97.</LI>
|
|
</OL>
|
|
<H1><A NAME="35">Debugging the kernel with GDB</A></H1>
|
|
<P> With User-Mode-Linux, you can debug the kernel using GDB. See
|
|
<!--HREF="http://user-mode-linux.sourceforge.net/debugging.html"-->
|
|
|
|
http://user-mode-linux.sourceforge.net/debugging.html.</(null)></P>
|
|
<P> Typically, one will want to address a test case for a failing
|
|
situation. Running GDB from Emacs, or from other front ends is
|
|
possible. First start GDB.</P>
|
|
<P> Tell it to open the UMLPOOL/swan/linux program.</P>
|
|
<P> Note the PID of GDB:</P>
|
|
<PRE>
|
|
marajade-[projects/freeswan/mgmt/planning] mcr 1029 %ps ax | grep gdb
|
|
1659 pts/9 SN 0:00 /usr/bin/gdb -fullname -cd /mara4/freeswan/kernpatch/UMLPOOL/swan/ linux
|
|
</PRE>
|
|
<P> Set the following in the environment:</P>
|
|
<PRE>
|
|
UML_east_OPT="debug gdb-pid=1659"
|
|
</PRE>
|
|
<P> Then start the user-mode-linux in the test scheme you wish:</P>
|
|
<PRE>
|
|
marajade-[kernpatch/testing/klips/east-icmp-02] mcr 1220 %../../utils/runme.sh
|
|
</PRE>
|
|
The user-mode-linux will stop on boot, giving you a chance to attach to
|
|
the process:
|
|
<PRE>
|
|
(gdb) file linux
|
|
Reading symbols from linux...done.
|
|
(gdb) attach 1
|
|
Attaching to program: /mara4/freeswan/kernpatch/UMLPOOL/swan/linux, process 1
|
|
0xa0118bc1 in kill () at hostfs_kern.c:770
|
|
</PRE>
|
|
<P> At this point, break points should be created as appropriate.</P>
|
|
<H2><A NAME="35_1">Other notes about debugging</A></H2>
|
|
<P> If you are running a standard test, after all the packets are sent,
|
|
the UML will be shutdown. This can cause problems, because the UML may
|
|
get terminated while you are debugging.</P>
|
|
<P> The environment variable <CODE>NETJIGWAITUSER</CODE> can be set to
|
|
"waituser". If so, then the testing system will prompt before exiting
|
|
the test.</P>
|
|
<H1><A NAME="36">User-Mode-Linux mysteries</A></H1>
|
|
<UL>
|
|
<LI> running more than one UML of the same name (e.g. "west") can cause
|
|
problems.</LI>
|
|
<LI> running more than one UML from the same root file system is not a
|
|
good idea.</LI>
|
|
<LI> all this means that running "make check" twice on the same machine
|
|
is probably not a good idea.</LI>
|
|
<LI> occationally, UMLs will get stuck. This can happen like:
|
|
<!--BLOCK-->
|
|
15134 ? T
|
|
0:00 /spare/hugh/uml/uml2.4.18-sept5/umlbuild/east/linux (east)
|
|
[/bin/sh] 15138 ? T 0:00
|
|
/spare/hugh/uml/uml2.4.18-sept5/umlbuild/east/linux (east) [halt]</(null)>
|
|
these will need to be killed. Note that they are in "T"racing mode.</LI>
|
|
<LI> UMLs can also hang, and will report "Tracing myself and I can't get
|
|
out". This is a bug in UML. There are ways to find out what is going on
|
|
and report this to the UML people, but we don't know the magic right
|
|
now.</LI>
|
|
</UL>
|
|
<H1><A NAME="37">Getting more info from uml_netjig</A></H1>
|
|
<P> uml_netjig can be compiled with a built-in tcpdump. This uses
|
|
not-yet-released code from<A HREF="http://www.tcpdump.org/">
|
|
www.tcpdump.org</A>. Please see the instructions in <CODE>
|
|
testing/utils/uml_netjig/Makefile</CODE>.</P>
|
|
<HR>
|
|
<H1><A name="makecheck">How to configure to use "make check"</A></H1>
|
|
<H2><A NAME="38_1">What is "make check"</A></H2>
|
|
<P> "make check" is a target in the top level makefile. It takes care of
|
|
running a number of unit and system tests to confirm that FreeSWAN has
|
|
been compiled correctly, and that no new bugs have been introduced.</P>
|
|
<P> As FreeSWAN contains both kernel and userspace components, doing
|
|
testing of FreeSWAN requires that the kernel be simulated. This is
|
|
typically difficult to do as a kernel requires that it be run on bare
|
|
hardware. A technology has emerged that makes this simpler. This is<A HREF="http://user-mode-linux.sourceforge.net">
|
|
User Mode Linux</A>.</P>
|
|
<P> User-Mode Linux is a way to build a Linux kernel such that it can
|
|
run as a process under another Linux (or in the future other) kernel.
|
|
Presently, this can only be done for 2.4 guest kernels. The host kernel
|
|
can be 2.2 or 2.4.</P>
|
|
<P> "make check" expects to be able to build User-Mode Linux kernels
|
|
with FreeSWAN included. To do this it needs to have some files
|
|
downloaded and extracted prior to running "make check". This is
|
|
described in the<A HREF="umltesting.html"> UML testing</A> document.</P>
|
|
<P> After having run the example in the UML testing document and
|
|
successfully brought up the four machine combination, you are ready to
|
|
use "make check"</P>
|
|
<H2><A NAME="38_2">Running "make check"</A></H2>
|
|
<P> "make check" works by walking the FreeSWAN source tree invoking the
|
|
"check" target at each node. At present there are tests defined only
|
|
for the <CODE>klips</CODE> directory. These tests will use the UML
|
|
infrastructure to test out pieces of the <CODE>klips</CODE> code.</P>
|
|
<P> The results of the tests can be recorded. If the environment
|
|
variable <CODE>$REGRESSRESULTS</CODE> is non-null, then the results of
|
|
each test will be recorded. This can be used as part of a nightly
|
|
regression testing system, see<A HREF="nightly.html"> Nightly testing</A>
|
|
for more details.</P>
|
|
<P> "make check" otherwise prints a minimal amount of output for each
|
|
test, and indicates pass/fail status of each test as they are run.
|
|
Failed tests do not cause failure of the target in the form of exit
|
|
codes.</P>
|
|
<H1><A NAME="39">How to write a "make check" test</A></H1>
|
|
<H2><A NAME="39_1">Structure of a test</A></H2>
|
|
<P> Each test consists of a set of directories under <CODE>testing/</CODE>
|
|
. There are directories for <CODE>klips</CODE>, <CODE>pluto</CODE>, <CODE>
|
|
packaging</CODE> and <CODE>libraries</CODE>. Each directory has a list
|
|
of tests to run is stored in a file called <CODE>TESTLIST</CODE> in
|
|
that directory. e.g. <CODE>testing/klips/TESTLIST</CODE>.</P>
|
|
<H2 NAME="TESTLIST"><A NAME="39_2">The TESTLIST</A></H2>
|
|
<P> This isn't actually a shell script. It just looks like one. Some
|
|
tools other than /bin/sh process it. Lines that start with # are
|
|
comments.</P>
|
|
<PRE>
|
|
# test-kind directory-containing-test expectation [PR#]
|
|
</PRE>
|
|
<P>The first word provides the test type, detailed below.</P>
|
|
<P> The second word is the name of the test to run. This the directory
|
|
in which the test case is to be found..</P>
|
|
<P>The third word may be one of:</P>
|
|
<DL>
|
|
<DT> blank/good</DT>
|
|
<DD>the test is believed to function, report failure</DD>
|
|
<DT> bad</DT>
|
|
<DD> the test is known to fail, report unexpected success</DD>
|
|
<DT> suspended</DT>
|
|
<DD> the test should not be run</DD>
|
|
</DL>
|
|
<P> The fourth word may be a number, which is a PR# if the test is
|
|
failing.</P>
|
|
<H2><A NAME="39_3">Test kinds</A></H2>
|
|
The test types are:
|
|
<DL>
|
|
<DT>skiptest</DT>
|
|
<DD>means run no test.</DD>
|
|
<DT>ctltest</DT>
|
|
<DD>means run a single system without input/output.</DD>
|
|
<DT>klipstest</DT>
|
|
<DD>means run a single system with input/output networks</DD>
|
|
<DT><A HREF="#umlplutotest">umlplutotest</A></DT>
|
|
<DD>means run a pair of systems</DD>
|
|
<DT><A HREF="#umlXhost">umlXhost</A></DT>
|
|
<DD>run an arbitrary number of systems</DD>
|
|
<DT>suntest (TBD)</DT>
|
|
<DD>means run a quad of east/west/sunrise/sunset</DD>
|
|
<DT>roadtest (TBD)</DT>
|
|
<DD>means run a trio of east-sunrise + warrior</DD>
|
|
<DT>extrudedtest (TBD)</DT>
|
|
<DD>means run a quad of east-sunrise + warriorsouth + park</DD>
|
|
<DT>mkinsttest</DT>
|
|
<DD>a test of the "make install" machinery.</DD>
|
|
<DT>kernel_test_patch</DT>
|
|
<DD>a test of the "make kernelpatch" machinery.</DD>
|
|
</DL>
|
|
Tests marked (TBD) have yet to be fully defined.
|
|
<P> Each test directory has a file in it called <CODE>testparams.sh</CODE>
|
|
. This file sets a number of environment variables to define the
|
|
parameters of the test.</P>
|
|
<H2><A NAME="39_4">Common parameters</A></H2>
|
|
<DL>
|
|
<DT>TESTNAME</DT>
|
|
<DD>the name of the test (repeated for checking purposes)</DD>
|
|
<DT>TEST_TYPE</DT>
|
|
<DD>the type of the test (repeat of type type above)</DD>
|
|
<DT>TESTHOST</DT>
|
|
<DD>the name of the UML machine to run for the test, typically "east" or
|
|
"west"</DD>
|
|
<DT>TEST_PURPOSE</DT>
|
|
<DD>The purpose of the test is one of:
|
|
<DL>
|
|
<DT>goal</DT>
|
|
<DD>The goal purpose is where a test is defined for code that is not yet
|
|
finished. The test indicates when the goals have in fact been reached.</DD>
|
|
<DT>regress</DT>
|
|
<DD>This is a test to determine that a previously existing bug has been
|
|
repaired. This test will initially be created to reproduce the bug in
|
|
isolation, and then the bug will be fixed.</DD>
|
|
<DT>exploit</DT>
|
|
<DD>This is a set of packets/programs that causes a vulnerability to be
|
|
exposed. It is a specific variation of the regress option.</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>TEST_GOAL_ITEM</DT>
|
|
<DT></DT>
|
|
<DD>in the case of a goal test, this is a reference to the requirements
|
|
document</DD>
|
|
<DT>TEST_PROB_REPORT</DT>
|
|
<DD>in the case of regression test, this the problem report number from
|
|
GNATS</DD>
|
|
<DT>TEST_EXPLOIT_URL</DT>
|
|
<DD>in the case of an exploit, this is a URL referencing the paper
|
|
explaining the origin of the test and the origin of exploit software</DD>
|
|
<DT>REF_CONSOLE_OUTPUT</DT>
|
|
<DD>a file in the test directory that contains the sanitized console
|
|
output against which to compare the output of the actual test.</DD>
|
|
<DT>REF_CONSOLE_FIXUPS</DT>
|
|
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
|
|
to sanitize the console output of the machine under test. These are
|
|
typically perl, awk or sed scripts that remove things in the kernel
|
|
output that change each time the test is run and/or compiled.</DD>
|
|
<DT>INIT_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode prior to starting the tests. This file will usually
|
|
set up any eroute's and SADB entries that are required for the test.</P>
|
|
<P>Lines beginning with # are skipped. Blank lines are skipped.
|
|
Otherwise, a shell prompted is waited for each time (consisting of <CODE>
|
|
\n#</CODE>) and then the command is sent. Note that the prompt is waited
|
|
for before the command and not after, so completion of the last command
|
|
in the script is not required. This is often used to invoke a program
|
|
to monitor the system, e.g. <CODE>ipsec pf_key</CODE>.</P>
|
|
</DD>
|
|
<DT>RUN_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, before the packets are sent. On single machine tests,
|
|
this script doesn't provide any more power than INIT_SCRIPT, but is
|
|
implemented for consistency's sake.</P>
|
|
</DD>
|
|
<DT>FINAL_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode after the final packet is sent. Similar to
|
|
INIT_SCRIPT, above. If not specified, then the single command "halt" is
|
|
sent. If specified, then the script should end with a halt command to
|
|
nicely shutdown the UML.</P>
|
|
</DD>
|
|
<DT>CONSOLEDIFFDEBUG</DT>
|
|
<DD>If set to "true" then the series of console fixups (see
|
|
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
|
|
be set to "false", or unset otherwise)</DD>
|
|
<DT>NETJIGDEBUG</DT>
|
|
<DD>If set to "true" then the series of console fixups (see
|
|
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
|
|
be set to "false", or unset otherwise)</DD>
|
|
<DT>NETJIGTESTDEBUG</DT>
|
|
<DD> If set to "netjig", then the results of talking to the <CODE>
|
|
uml_netjig</CODE> will be printed to stderr during the test. In
|
|
addition, the jig will be invoked with --debug, which causes it to log
|
|
its process ID, and wait 60 seconds before continuing. This can be used
|
|
if you are trying to debug the <CODE>uml_netjig</CODE> program itself.</DD>
|
|
<DT>HOSTTESTDEBUG</DT>
|
|
<DD> If set to "hosttest", then the results of taling to the consoles of
|
|
the UMLs will be printed to stderr during the test.</DD>
|
|
<DT>NETJIGWAITUSER</DT>
|
|
<DD> If set to "waituser", then the scripts will wait forever for user
|
|
input before they shut the tests down. Use this is if you are debugging
|
|
through the kernel.</DD>
|
|
<DT>PACKETRATE</DT>
|
|
<DD> A number, in miliseconds (default is 500ms) at which packets will
|
|
be replayed by the netjig.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_5">KLIPStest paramaters</A></H2>
|
|
<P> The klipstest function starts a program (<CODE>
|
|
testing/utils/uml_netjig/uml_netjig</CODE>) to setup a bunch of I/O
|
|
sockets (that simulate network interfaces). It then exports the
|
|
references to these sockets to the environment and invokes (using
|
|
system()) a given script. It waits for the script to finish.</P>
|
|
|
|
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
|
|
<P> The script invoked (<CODE>testing/utils/host-test.tcl</CODE>) is a
|
|
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
|
|
to start the UML and configure it appropriately for the test. The
|
|
configuration is done with the script given above for<VAR> INIT_SCRIPT</VAR>
|
|
. The TCL script then forks, leaves the UML in the background and exits.
|
|
uml_netjig continues. It then starts listening to the simulated network
|
|
answering ARPs and inserting packets as appropriate.</P>
|
|
<P> The klipstest function invokes <CODE>uml_netjig</CODE> with
|
|
arguments to capture output from network interface(s) and insert
|
|
packets as appropriate:</P>
|
|
<DL>
|
|
<DT>PUB_INPUT</DT>
|
|
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
|
|
public (encrypted) interface. (typically, eth1)</DD>
|
|
<DT>PRIV_INPUT</DT>
|
|
<DD>a pcap file to feed in on the private (plain-text) interface
|
|
(typically, eth0).</DD>
|
|
<DT>REF_PUB_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the public (eth1)
|
|
interface are captured to a<A HREF="http://www.tcpdump.org/"> pcap</A>
|
|
file by <CODE>uml_netjig</CODE>. The klipstest function then uses
|
|
tcpdump on the file to produce text output, which is compared to the
|
|
file given.</DD>
|
|
<DT>REF_PUB_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>REF_PRIV_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the private (eth0)
|
|
interface are captured and compared after conversion by tcpdump, as
|
|
with<VAR> REFPUBOUTPUT</VAR>.</DD>
|
|
<DT>REF_PRIV_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>EXITONEMPTY</DT>
|
|
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain
|
|
"--exitonempty" of uml_netjig should exit when all of the input (<VAR>
|
|
PUBINPUT</VAR>,<VAR>PRIVINPUT</VAR>) packets have been injected.</DD>
|
|
<DT>ARPREPLY</DT>
|
|
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain "--arpreply"
|
|
if <CODE>uml_netjig</CODE> should reply to ARP requests. One will
|
|
typically set this to avoid having to fudge the ARP cache manually.</DD>
|
|
<DT>TCPDUMPFLAGS</DT>
|
|
<DD>a set of flags for the tcpdump used when converting captured output.
|
|
Typical values will include "-n" to turn off DNS, and often "-E" to set
|
|
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
|
|
"-t" flag (turn off timestamps) is provided automatically</DD>
|
|
<DT>NETJIG_EXTRA</DT>
|
|
<DD>additional comments to be sent to the netjig. This may arrange to
|
|
record or create additional networks, or may toggle options.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_6">mkinsttest paramaters</A></H2>
|
|
<P> The basic concept of the <CODE>mkinsttest</CODE> test type is that
|
|
it performs a "make install" to a temporary $DESTDIR. The resulting
|
|
tree can then be examined to determine if it was done properly. The
|
|
files can be uninstalled to determine if the file list was correct, or
|
|
the contents of files can be examined more precisely.</P>
|
|
<DL>
|
|
<DT>INSTALL_FLAGS</DT>
|
|
<DD>If set, then an install will be done. This provides the set of flags
|
|
to provide for the install. The target to be used (usually "install")
|
|
must be among the flags.</DD>
|
|
<DT>POSTINSTALL_SCRIPT</DT>
|
|
<DD>If set, a script to run after initial "make install". Two arguments
|
|
are provided: an absolute path to the root of the FreeSWAN src tree,
|
|
and an absolute path to the temporary installation area.</DD>
|
|
<DT>INSTALL2_FLAGS</DT>
|
|
<DD>If set, a second install will be done using these flags. Similarly
|
|
to INSTALL_FLAGS, the target must be among the flags.</DD>
|
|
<DT>UNINSTALL_FLAGS</DT>
|
|
<DD>If set, an uninstall will be done using these flags. Similarly to
|
|
INSTALL_FLAGS, the target (usually "uninstall") must be among the
|
|
flags.</DD>
|
|
<DT>REF_FIND_f_l_OUTPUT</DT>
|
|
<DD>If set, a <CODE>find $ROOT ( -type f -or -type -l )</CODE> will be
|
|
done to get a list of a real files and symlinks. The resulting file
|
|
will be compared to the file listed by this option.</DD>
|
|
<DT>REF_FILE_CONTENTS</DT>
|
|
<DD>If set, it should point to a file containing records for the form:
|
|
<PRE>
|
|
|
|
<!--VARIABLE-->
|
|
reffile</(null)>
|
|
<!--VARIABLE-->
|
|
samplefile</(null)>
|
|
</PRE>
|
|
one record per line. A diff between the provided reference file, and
|
|
the sample file (located in the temporary installation root) will be
|
|
done for each record.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_7">rpm_build_install_test paramaters</A></H2>
|
|
<P> The <CODE>rpm_build_install_test</CODE> type is to verify that the
|
|
proper packing list is produced by "make rpm", and that the mechanisms
|
|
for building the kernel modules produce consistent results.</P>
|
|
<DL>
|
|
<DT>RPM_KERNEL_SOURCE</DT>
|
|
<DD>Point to an extracted copy of the RedHat kernel source code.
|
|
Variables from the environment may be used.</DD>
|
|
<DT>REF_RPM_CONTENTS</DT>
|
|
<DD>This is a file containing one record per line. Each record consists
|
|
of a RPM name (may contain wildcards) and a filename to compare the
|
|
contents to. The RPM will be located and a file list will be produced
|
|
with rpm2cpio.</DD>
|
|
</DL>
|
|
<H2><A NAME="39_8">libtest paramaters</A></H2>
|
|
<P> The libtest test is for testing library routines. The library file
|
|
is expected to provided an <CODE>#ifdef</CODE> by the name of<VAR>
|
|
library</VAR>
|
|
<!--CODE_MAIN</CODE-->
|
|
. The libtest type invokes the C compiler to compile this
|
|
file, links it against <CODE>libfreeswan.a</CODE> (to resolve any other
|
|
dependancies) and runs the test with the <CODE>-r</CODE> argument to
|
|
invoke a regression test.</(null)></P>
|
|
<P>The library test case is expected to do a self-test, exiting with
|
|
status code 0 if everything is okay, and with non-zero otherwise. A
|
|
core dump (exit code greater than 128) is noted specifically.</P>
|
|
<P> Unlike other tests, there are no subdirectories required, or other
|
|
parameters to set.</P>
|
|
<H2 NAME="umlplutotest"><A NAME="39_9">umlplutotest paramaters</A></H2>
|
|
<P> The umlplutotest function starts a pair of user mode line processes.
|
|
This is a 2-host version of umlXhost. The "EAST" and "WEST" slots are
|
|
defined.</P>
|
|
<H2 NAME="umlXhost"><A NAME="39_10">umlXhost parameters</A></H2>
|
|
<P> The umlXtest function starts an arbitrary number of user mode line
|
|
processes.</P>
|
|
|
|
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
|
|
<P> The script invoked (<CODE>testing/utils/Xhost-test.tcl</CODE>) is a
|
|
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
|
|
to start each UML and configure it appropriately for the test. It then
|
|
starts listening (using uml_netjig) to the simulated network answering
|
|
ARPs and inserting packets as appropriate.</P>
|
|
<P> umlXtest has a series of slots, each of which should be filled by a
|
|
host. The list of slots is controlled by the variable, XHOST_LIST. This
|
|
variable should be set to a space seperated list of slots. The former
|
|
umlplutotest is now implemented as a variation of the umlXhost test,
|
|
with XHOST_LIST="EAST WEST".</P>
|
|
<P> For each host slot that is defined, a series of variables should be
|
|
filled in, defining what configuration scripts to use for that host.</P>
|
|
<P> The following are used to control the console input and output to
|
|
the system. Where the string ${host} is present, the host slot should
|
|
be filled in. I.e. for the two host system with XHOST_LIST="EAST WEST",
|
|
then the variables: EAST_INIT_SCRIPT and WEST_INIT_SCRIPT will exist.</P>
|
|
<DL>
|
|
<DT>${host}HOST</DT>
|
|
<DD>The name of the UML host which will fill this slot</DD>
|
|
<DT>${host}_INIT_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode prior to starting the tests. This file will usually
|
|
set up any eroute's and SADB entries that are required for the test.
|
|
Similar to INIT_SCRIPT, above.</P>
|
|
</DD>
|
|
<DT>${host}_RUN_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, before the packets are sent. This set of commands is
|
|
run after all of the virtual machines are initialized. I.e. after
|
|
EAST_INIT_SCRIPT<B> AND</B> WEST_INIT_SCRIPT. This script can therefore
|
|
do things that require that all machines are properly configured.</P>
|
|
</DD>
|
|
<DT>${host}_RUN2_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode, after the packets are sent. This set of commands is
|
|
run before any of the virtual machines have been shut down. (I.e.
|
|
before EAST_FINAL_SCRIPT<B> AND</B> WEST_FINAL_SCRIPT.) This script can
|
|
therefore catch post-activity status reports.</P>
|
|
</DD>
|
|
<DT>${host}_FINAL_SCRIPT</DT>
|
|
<DD>
|
|
<P>a file of commands that is fed into the virtual machine's console in
|
|
single user mode after the final packet is sent. Similar to
|
|
INIT_SCRIPT, above. If not specified, then the single command "halt" is
|
|
sent. Note that when this script is run, the other virtual machines may
|
|
already have been killed. If specified, then the script should end with
|
|
a halt command to nicely shutdown the UML.</P>
|
|
</DD>
|
|
<DT>REF_${host}_CONSOLE_OUTPUT</DT>
|
|
<DD>Similar to REF_CONSOLE_OUTPUT, above.</DD>
|
|
</DL>
|
|
<P>Some additional flags apply to all hosts:</P>
|
|
<DL>
|
|
<DT>REF_CONSOLE_FIXUPS</DT>
|
|
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
|
|
to sanitize the console output of the machine under test. These are
|
|
typically perl, awk or sed scripts that remove things in the kernel
|
|
output that change each time the test is run and/or compiled.</DD>
|
|
</DL>
|
|
<P> In addition to input to the console, the networks may have input fed
|
|
to them:</P>
|
|
<DL>
|
|
<DT>EAST_INPUT/WEST_INPUT</DT>
|
|
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
|
|
private network side of each network. The "EAST" and "WEST" here refer
|
|
to the networks, not the hosts.</DD>
|
|
<DT>REF_PUB_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<DT>REF_EAST_FILTER/REF_WEST_FILTER</DT>
|
|
<DD>a program that will filter the TCPDUMP output to do further
|
|
processing. Defaults to "cat".</DD>
|
|
<
|
|
<DT>TCPDUMPFLAGS</DT>
|
|
<DD>a set of flags for the tcpdump used when converting captured output.
|
|
Typical values will include "-n" to turn off DNS, and often "-E" to set
|
|
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
|
|
"-t" flag (turn off timestamps) is provided automatically</DD>
|
|
<DT>REF_EAST_OUTPUT/REF_WEST_OUTPUT</DT>
|
|
<DD>a text file containing tcpdump output. Packets on the private (eth0)
|
|
interface are captured and compared after conversion by tcpdump, as
|
|
with<VAR> REF_PUB_OUTPUT</VAR>.</DD>
|
|
<P> There are two additional environment variables that may be set on
|
|
the command line:</P>
|
|
<DL>
|
|
<DT> NETJIGVERBOSE=verbose export NETJIGVERBOSE</DT>
|
|
<DD> If set, then the test output will be "chatty", and let you know
|
|
what commands it is running, and as packets are sent. Without it set,
|
|
the output is limited to success/failure messages.</DD>
|
|
<DT> NETJIGTESTDEBUG=netjig export NETJIGTESTDEBUG</DT>
|
|
<DD> This will enable debugging of the communication with uml_netjig,
|
|
and turn on debugging in this utility. This does not imply
|
|
NETJIGVERBOSE.</DD>
|
|
</DL>
|
|
<DT> HOSTTESTDEBUG=hosttest export HOSTTESTDEBUG</DT>
|
|
<DD> This will show all interactions with the user-mode-linux consoles</DD>
|
|
</DL>
|
|
<H2 NAME="kernelpatch"><A NAME="39_11">kernel_patch_test paramaters</A></H2>
|
|
<P> The kernel_patch_test function takes some kernel source, copies it
|
|
with lndir, and then applies the patch as produced by "make
|
|
kernelpatch".</P>
|
|
<P> The following are used to control the input and output to the
|
|
system:</P>
|
|
<DL>
|
|
<DT>KERNEL_NAME</DT>
|
|
<DD>the kernel name, typically something like "linus" or "rh"</DD>
|
|
<DT>KERNEL_VERSION</DT>
|
|
<DD>the kernel version number, as in "2.2" or "2.4".</DD>
|
|
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
|
|
<DD>This variable should set in the environment, probably in
|
|
~/freeswan-regress-env.sh. Examples of this variables would be
|
|
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
|
|
an extracted copy of the kernel source in question.</DD>
|
|
<DT>REF_PATCH_OUTPUT</DT>
|
|
<DD>a copy of the patch output to compare against</DD>
|
|
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
|
|
<DD>If set to a non-empty string, then the patched kernel source is not
|
|
removed at the end of the test. This will typically be set in the
|
|
environment while debugging.</DD>
|
|
</DL>
|
|
<H2 NAME="modtest"><A NAME="39_12">module_compile paramaters</A></H2>
|
|
<P> The module_compile test attempts to build the KLIPS module against a
|
|
given set of kernel source. This is also done by the RPM tests, but in
|
|
a very specific manner.</P>
|
|
<P> There are two variations of this test - one where the kernel either
|
|
doesn't need to be configured, or is already done, and tests were there
|
|
is a local configuration file.</P>
|
|
<P> Where the kernel doesn't need to be configured, the kernel source
|
|
that is found is simply used. It may be a RedHat-style kernel, where
|
|
one can cause it to configure itself via rhconfig.h-style definitions.
|
|
Or, it may just be a kernel tree that has been configured.</P>
|
|
<P> If the variable KERNEL_CONFIG_FILE is set, then a new directory is
|
|
created for the kernel source. It is populated with lndir(1). The
|
|
referenced file is then copied in as .config, and "make oldconfig" is
|
|
used to configure the kernel. This resulting kernel is then used as the
|
|
reference source.</P>
|
|
<P> In all cases, the kernel source is found the same was for the
|
|
kernelpatch test, i.e. via KERNEL_VERSION/KERNEL_NAME and
|
|
KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC.</P>
|
|
<P> Once there is kernel source, the module is compiled using the
|
|
top-level "make module" target.</P>
|
|
<P> The test is considered successful if an executable is found in
|
|
OUTPUT/module/ipsec.o at the end of the test.</P>
|
|
<DL>
|
|
<DT>KERNEL_NAME</DT>
|
|
<DD>the kernel name, typically something like "linus" or "rh"</DD>
|
|
<DT>KERNEL_VERSION</DT>
|
|
<DD>the kernel version number, as in "2.2" or "2.4".</DD>
|
|
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
|
|
<DD>This variable should set in the environment, probably in
|
|
~/freeswan-regress-env.sh. Examples of this variables would be
|
|
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
|
|
an extracted copy of the kernel source in question.</DD>
|
|
<DT>KERNEL_CONFIG_FILE</DT>
|
|
<DD>The configuration file for the kernel.</DD>
|
|
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
|
|
<DD>If set to a non-empty string, then the configured kernel source is
|
|
not removed at the end of the test. This will typically be set in the
|
|
environment while debugging.</DD>
|
|
<DT>MODULE_DEF_INCLUDE</DT>
|
|
<DD>The include file that will be used to configure the KLIPS module,
|
|
and possibly the kernel source.</DD>
|
|
</DL>
|
|
<H1><A NAME="40">Current pitfalls</A></H1>
|
|
<DL>
|
|
<DT> "tcpdump dissector" not available.</DT>
|
|
<DD> This is a non-fatal warning. If uml_netjig is invoked with the -t
|
|
option, then it will attempt to use tcpdump's dissector to decode each
|
|
packet that it processes. The dissector is presently not available, so
|
|
this option it normally turned off at compile time. The dissector
|
|
library will be released with tcpdump version 4.0.</DD>
|
|
</DL>
|
|
<HR>
|
|
<H1><A name="nightly">Nightly regression testing</A></H1>
|
|
<P> The nightly regression testing system consists of several shell
|
|
scripts and some perl scripts. The goal is to check out a fresh tree,
|
|
run "make check" on it, record the results and summarize the results to
|
|
the team and to the web site.</P>
|
|
<P> Output can be found on<A HREF="http://bugs.freeswan.org:81/"> adams</A>
|
|
, although the tests are actually run on another project machine.</P>
|
|
<H1><A name="nightlyhowto">How to setup the nightly build</A></H1>
|
|
<P> The best way to do nightly testing is to setup a new account. We
|
|
call the account "build" - you could call it something else, but there
|
|
may still be some references to ~build in the scripts.</P>
|
|
<H2><A NAME="42_1"> Files you need to know about</A></H2>
|
|
<P> As few files as possible need to be extracted from the source tree -
|
|
files are run from the source tree whenever possible. However, there
|
|
are some bootstrap and configuration files that are necessary.</P>
|
|
<P> There are 7 files in testing/utils that are involved:</P>
|
|
<DL>
|
|
<DT> nightly-sample.sh</DT>
|
|
<DD> This is the root of the build process. This file should be copied
|
|
out of the CVS tree, to $HOME/bin/nightly.sh of the build account. This
|
|
file should be invoked from cron.</DD>
|
|
<DT> freeswan-regress-env-sample.sh</DT>
|
|
<DD> This file should be copied to $HOME/freeswan-regress-env.sh. It
|
|
should be edited to localize the values. See below.</DD>
|
|
<DT> regress-cleanup.pl</DT>
|
|
<DD> This file needs to be copied to $HOME/bin/regress-cleanup.pl. It is
|
|
invoked by the nightly file before doing anything else. It removes
|
|
previous nights builds in order to free up disk space for the build
|
|
about to be done.</DD>
|
|
<DT> teammail-sample.sh</DT>
|
|
<DD> A script used to send results email to the "team". This sample
|
|
script could be copied to $HOME/bin/teammail.sh. This version will PGP
|
|
encrypt all the output to the team members. If this script is used,
|
|
then PGP will have to be properly setup to have the right keys.</DD>
|
|
<DT> regress-nightly.sh</DT>
|
|
<DD> This is the first stage of the nightly build. This stage will call
|
|
other scripts as appropriate, and will extract the source code from
|
|
CVS. This script should be copied to $HOME/bin/regress-nightly.sh</DD>
|
|
<DT> regress-stage2.sh</DT>
|
|
<DD> This is the second stage of the nightly build. It is called in
|
|
place. It essentially sets up the UML setup in umlsetup.sh, and calls
|
|
"make check".</DD>
|
|
<DT> regress-summarize-results.pl</DT>
|
|
<DD> This script will summarize the results from the tests to a
|
|
permanent directory set by $REGRESSRESULTS. It is invoked from the
|
|
stage2 nightly script.</DD>
|
|
<DT> regress-chart.sh</DT>
|
|
<DD> This script is called at the end of the build process, and will
|
|
summarize each night's results (as saved into $REGRESSRESULTS by
|
|
regress-summarize-results.pl) as a chart using gnuplot. Note that this
|
|
requires at least gnuplot 3.7.2.</DD>
|
|
</DL>
|
|
<H2><A NAME="42_2">Configuring freeswan-regress-env.sh</A></H2>
|
|
<P>For more info on KERNPOOL, UMLPATCH, BASICROOT and SHAREDIR, see<A HREF="umltesting.html">
|
|
User-Mode-Linux testing guide</A>.</P>
|
|
<DL>
|
|
<DT> KERNPOOL</DT>
|
|
<DD> Extract copy of some kernel source to be used for UML builds</DD>
|
|
<DT> UMLPATCH</DT>
|
|
<DD> matching User-Mode-Linux patch.</DD>
|
|
<DT> BASICROOT</DT>
|
|
<DD> the root file system image (see<A HREF="umltesting.html">
|
|
User-Mode-Linux testing guide</A>).</DD>
|
|
<DT> SHAREDIR=${BASICROOT}/usr/share</DT>
|
|
<DD> The /usr/share to use.</DD>
|
|
<DT> REGRESSTREE</DT>
|
|
<DD> A directory in which to store the nightly regression results.
|
|
Directories will be created by date in this tree.</DD>
|
|
<DT> TCPDUMP=tcpdump-3.7.1</DT>
|
|
<DD> The path to the<A HREF="http://www.tcpdump.org/"> tcpdump</A> to
|
|
use. This must have crypto compiled in, and must be at least 3.7.1</DD>
|
|
<DT> KERNEL_RH7_2_SRC=/a3/kernel_sources/linux-2.4.9-13/</DT>
|
|
<DD> An extracted copy of the RedHat 7.2. kernel source. If set, then
|
|
the packaging/rpm-rh72-install-01 test will be run, and an RPM will be
|
|
built as a test.</DD>
|
|
<DT> KERNEL_RH7_3_SRC=/a3/kernel_sources/rh/linux-2.4.18-5</DT>
|
|
<DD> An extracted copy of the RedHat 7.3. kernel source. If set, then
|
|
the packaging/rpm-rh73-install-01 test will be run, and an RPM will be
|
|
built as a test.</DD>
|
|
<DT> NIGHTLY_WATCHERS="userid,userid,userid"</DT>
|
|
<DD> The list of people who should receive nightly output. This is used
|
|
by teammail.sh</DD>
|
|
<DT> FAILLINES=128</DT>
|
|
<DD> How many lines of failed test output to include in the nightly
|
|
output</DD>
|
|
<DT> PATH=$PATH:/sandel/bin export PATH</DT>
|
|
<DD> You can also override the path if necessary here.</DD>
|
|
<DT> CVSROOT=:pserver:[email protected]:/freeswan/MASTER</DT>
|
|
<DD> The CVSROOT to use. This example may work for anonymous CVS, but
|
|
will be 12 hours behind the primary, and is still experimental</DD>
|
|
<DT> SNAPSHOTSIGDIR=$HOME/snapshot-sig</DT>
|
|
<DD> For the release tools, where to put the generated per-snapshot
|
|
signature keys</DD>
|
|
<DT> LASTREL=1.97</DT>
|
|
<DD> the name of the last release branch (to find the right per-snapshot
|
|
signature</DD>
|
|
<DD></DD>
|
|
</DL>
|
|
</BODY>
|
|
</HTML>
|