- •Table of Contents
- •Preface
- •What This Book Covers
- •What You Need for This Book
- •Conventions
- •Reader Feedback
- •Customer Support
- •Errata
- •Questions
- •The Need for Cryptography
- •Privacy
- •Security
- •A History of the Internet
- •Holding the Internet Together
- •The Creation of ICANN
- •ICANN Bypassed
- •The Root Name Servers
- •Running the Top-Level Domains
- •History of Internet Engineering
- •The Internet Engineering Task Force (IETF)
- •RFCs—Requests For Comments
- •IETF and Crypto
- •The War on Crypto
- •Dual Use
- •Public Cryptography
- •The Escrowed Encryption Standard
- •Export Laws
- •The Summer of '97
- •The EFF DES Cracker
- •Echelon
- •The End of the Export Restrictions
- •Free Software
- •Free as in Verifiable
- •The Open Source Movement
- •The History of Openswan
- •IETF Troubles over DNS
- •Super FreeS/WAN
- •The Arrival of Openswan
- •NETKEY
- •Further Reading
- •Using Openswan
- •Copyright and License Conditions
- •Writing and Contributing Code
- •Legality of Using Openswan
- •International Agreements
- •International Law and Hosting Openswan
- •Unrecognized International Claims
- •Patent Law
- •Expired and Bogus Patents
- •Useful Legal Links
- •Summary
- •A Very Brief Overview of Cryptography
- •Valid Packet Rewriting
- •Ciphers
- •Algorithms
- •Uniqueness
- •Public-Key Algorithms
- •Exchanging Public Keys
- •Digital Signatures
- •Diffie-Hellman Key Exchange
- •Avoiding the Man in the Middle
- •Session Keys
- •Crypto Requirements for IPsec
- •IPsec: A Suite of Protocols
- •Kernel Mode: Packet Handling
- •Authentication Header (AH)
- •Encapsulated Security Payload (ESP)
- •Transport and Tunnel Mode
- •Choosing the IPsec Mode and Type
- •The Kernel State
- •Encryption Details
- •Manual Keying
- •Final Note on Protocols and Ports
- •Usermode: Handling the Trust Relationships
- •The IKE Protocol
- •Phase 1: Creating the ISAKMP SA
- •Phase 2: Quick Mode
- •The NAT Problem
- •Summary
- •Linux Distributions
- •Debian
- •SuSE
- •Slackware
- •Gentoo
- •Linux 'Router' Distributions
- •Deciding on the Userland
- •Pluto
- •Racoon
- •Isakmpd
- •More Reasons to Pick Pluto
- •Choosing the Kernel IPsec Stack
- •KLIPS, the Openswan Stack
- •ipsecX Interfaces
- •First Packet Caching
- •Path MTU Discovery
- •KLIPS' Downside
- •NETKEY, the 2.6 IPsec Stack
- •The USAGI / SuSE IPsec Stack
- •Making the Choice
- •GPL Compliance and KLIPS
- •Binary Installation of the Openswan Userland
- •Checking for Old Versions
- •Installing the Binary Package for Openswan
- •Building from Source
- •Using RPM-based Distributions
- •Rebuilding the Openswan Userland
- •Building src.rpm from Scratch
- •Openswan Options
- •Building the Openswan Userland from Source
- •Downloading the Source Code
- •Configuring the Userland Tools
- •Optional Features
- •Compile Flags
- •File Path Options
- •Obscure Pluto Options
- •Compiling and Installing
- •Binary Installation of KLIPS
- •Building KLIPS from Source
- •Kernel Prerequisites
- •Identifying your Kernel's Abilities
- •Using Both KLIPS and NETKEY
- •The Kernel Build Options
- •Required Kernel Options
- •Desired Options
- •NETKEY Stack Options
- •KLIPS Stack Options
- •L2TP Options
- •Patching the Kernel
- •NAT-Traversal Patch
- •KLIPS Compile Shortcut
- •Activating KLIPS
- •Determining the Stack in Use
- •Building KLIPS into the Linux Kernel Source Tree
- •Building a Standard Kernel
- •NAT Traversal
- •Patching KLIPS into the Linux Kernel
- •Verifying the Installation
- •Summary
- •Manual versus Automatic
- •PSK versus RSA
- •Pitfalls of Debugging IPsec
- •Pre-Flight Check
- •The ipsec verify Command
- •NAT and Masquerading
- •Checking External Commands
- •Opportunistic Encryption
- •The ipsec livetest Command
- •Configuration of Openswan
- •The ipsec.conf File
- •Host-to-Host Tunnel
- •Left and Right
- •The type Options
- •The auto Option
- •The rsasigkey Options
- •Bringing Up the IPsec Tunnels
- •Listing IPsec Connections
- •Testing the IPsec Tunnel
- •Connecting Subnets Through an IPsec Connection
- •Testing Subnet Connections
- •Testing Properly
- •Encrypting the Host and the Network Behind It
- •Employing Advanced Routing
- •Creating More Tunnels
- •Avoiding Duplication
- •The Also Keyword
- •KLIPS and the ipsecX Interfaces
- •Pre-Shared Keys (PSKs)
- •Proper Secrets
- •Dynamic IP Addresses
- •Hostnames
- •Roadwarriors
- •Multiple Roadwarrior Connections
- •Dynamic IP and PSKs
- •Mixing PSK and RSA
- •Connection Management
- •Subnet Extrusion
- •NAT Traversal
- •Deprecated Syntax
- •Confirming a Functional NAT-T
- •Dead Peer Detection
- •DPD Works Both Ways
- •Configuring DPD
- •Buggy Cisco Routers
- •Ciphers and Algorithms
- •Using ike= to Specify Phase 1 Parameters
- •Using esp= to Specify Phase 2 Parameters
- •Defaults and Strictness
- •Unsupported Ciphers and Algorithms
- •Aggressive Mode
- •XAUTH
- •XAUTH Gateway (Server Side)
- •XAUTH Client (Supplicant Side)
- •Fine Tuning
- •Perfect Forward Secrecy
- •Rekeying
- •Key Rollover
- •Summary
- •X.509 Certificates Explained
- •X.509 Objects
- •X.509 Packing
- •Types of Certificates
- •Passphrases, PIN Codes, and Interactivity
- •IKE and Certificates
- •Using the Certificate DN as ID for Openswan
- •Generating Certificates with OpenSSL
- •Setting the Time
- •Configuring OpenSSL
- •Be Consistent with All Certificates
- •OpenSSL Commands for Common Certificate Actions
- •Configuring Apache for IPsec X.509 Files
- •Creating X.509-based Connections
- •Using a Certificate Authority
- •Using Multiple CAs
- •Sending and Receiving Certificate Information
- •Creating your own CA using OpenSSL
- •Creating Host Certificates with Your Own CA
- •Host Certificates for Microsoft Windows (PKCS#12)
- •Certificate Revocation
- •Dynamic CRL Fetching
- •Configuring CRL
- •Online Certificate Status Protocol (OCSP)
- •Summary
- •History of Opportunistic Encryption
- •Trusting Third Parties
- •Trusting the DNS?
- •OE in a Nutshell
- •An OE Security Gateway
- •DNS Key Records
- •Forward and Reverse Zones
- •The OE DNS Records
- •Different Types of OE
- •Policy Groups
- •Internal States
- •Configuring OE
- •Configuring Policies
- •Full OE or Initiate-Only
- •Generating Correct DNS Records
- •Name Server Updates
- •Verifying Your OE Setup
- •Testing Your OE Setup
- •The trap eroute
- •The pass eroute
- •The hold eroute
- •Manipulating OE Connections Manually
- •Advanced OE Setups
- •Caveats
- •Summary
- •Where to Firewall?
- •Allowing IPsec Traffic
- •NAT and IPsec Passthrough
- •Configuring the Firewall on the Openswan Host
- •Firewalling and KLIPS
- •Firewalling and NETKEY
- •Packet Size
- •Summary
- •Microsoft Windows
- •Layer 2 Tunneling Protocol (L2TP)
- •Assigning an IP for VPN Access
- •L2TP Properties
- •Pure IPsec versus L2TP/IPsec
- •Client and Server Configurations for L2TP/IPsec
- •The L2TP Openswan Server
- •Configuring Openswan for L2TP/IPsec
- •Linux Kernel Runtime Parameters for L2TP/IPsec
- •Protecting the L2TP Daemon with IPsec using iptables
- •Choosing an L2TP Daemon
- •Configuring L2TPD
- •Configuring User Authentication for pppd
- •Microsoft Windows XP L2TP Configuration
- •Microsoft Windows 2000 L2TP Configuration
- •Apple Mac OS X L2TP Configuration
- •Server Configuration for X.509 IPsec without L2TP
- •Openswan Configuration for X.509 without L2TP
- •Client Configuration for X.509 IPsec without L2TP
- •Microsoft's IKE Daemon
- •Microsoft's Certificate Store
- •Clients using Microsoft Native IPsec Implementation
- •The ipsec.exe Wrapper
- •The Linsys IPsec Tool (lsipsectool)
- •Securepoint IPsec Client
- •TauVPN (iVPN)
- •The WaveSEC Client
- •Third-Party Replacement Clients for Windows
- •The GreenBow VPN Client
- •Astaro Secure Client
- •Mac OS X IPSecuritas
- •VPNtracker
- •Manual Racoon Configuration
- •Importing X.509 Certificates into Windows
- •Importing X.509 Certificates on Mac OS X (Tiger)
- •Summary
- •Openswan as a Client to an Appliance
- •Preparing the Interop
- •The Human Factor
- •Terminology
- •Preparation
- •IPsec Passthrough
- •Tunnel Limitations
- •Anticipate Known Problems
- •Update the Firmware
- •GUI Issues
- •Keepalives
- •ISP Filtering
- •Frequently used VPN Gateways
- •Webmin with Openswan
- •Cisco VPN 3000
- •Cisco PIX Concentrator
- •Nortel Contivity
- •Checkpoint
- •WatchGuard Firebox
- •Symantec
- •Frequently used VPN Client Appliances
- •ZyXEL
- •DrayTek Vigor
- •The Vigor Web Interface
- •Windows Logon Issues
- •Other Vigorisms
- •Unresolved Issues
- •NetScreen
- •Known Issues
- •SonicWALL
- •BinTec
- •LANCOM
- •Linksys
- •Lucent Brick
- •NETGEAR
- •KAME/Racoon
- •Aftercare
- •Summary
- •Methods of Encryption
- •Host-to-Host Mesh
- •Host-to-Gateway Setup
- •Single IP Extrusiautomation or L2TP
- •Opportunistic Encryption in the LAN
- •Non-OE-Capable Machines
- •Designing a Solution for Encrypting the LAN
- •Design Goals
- •Separation of WiFi and Crypto
- •Link Layer Protection
- •The Logical Choice: IPsec
- •Hotspot
- •WaveSEC
- •Full WaveSEC
- •Catch 22 Traffic
- •Building a WaveSEC Server
- •DHCP Server Setup
- •DNS Server Setup
- •Openswan Server Setup
- •Catch 22 Traffic Setup
- •Building a WaveSEC Client
- •DH Client Setup
- •Openswan Setup
- •Testing the WaveSEC
- •Starting the WaveSEC Connection
- •Known Issues with WaveSEC
- •WaveSEC for Windows
- •Design Limitations
- •Building a WaveSEC for Windows Server
- •Obtaining the Certificate and Client Software
- •Our Prototype Experiences
- •Openswan Issues
- •Windows Kernel Issues
- •Summary
- •Cipher Performance
- •Handling Thousands of Tunnels
- •Managing Large Configuration Files
- •Standard Naming Convention
- •The also= Parameter
- •The include Parameter
- •Openswan Startup Time
- •Limitations of the Random Device
- •Other Performance-Enhancing Factors
- •Logging to Disk
- •Disable Dead Peer Detection
- •Reducing the Number of Tunnels
- •OSPF Setup
- •BGPv4 Setup
- •High Availability
- •Heartbeat
- •Xen Migration
- •Using Anycast
- •Summary
- •Do Not Lock Yourself Out!
- •Narrowing Down the Problem
- •Host Issues
- •Configuration Problems
- •Connection Names
- •Interoperability
- •Hunting Ghosts
- •Rekey Problems (After an Hour)
- •Openswan Error Messages
- •IKE: Unknown VendorIDs
- •Network Issues
- •Firewalls
- •MTU and Fragmentation Issues
- •Debugging IPsec on Apple Mac OS X
- •Debugging IPsec on Microsoft Windows
- •Oakley Debugging
- •Debugging ipsec.exe
- •Microsoft L2TP Errors
- •You Suddenly Cannot Log in Anymore over the VPN
- •Software Bugs
- •Userland Issues: Assertion Failed or Segmentation Faults
- •Kernel Issues: Crashes and Oopses
- •Memory Issues
- •Common IKE Error Messages
- •Common Kernel-Related Error Messages
- •Common Errors when Upgrading
- •Using tcpdump to Debug IPsec
- •Situation A: No Communication on Port 500
- •Situation B: Failure at Third Exchange
- •Situation C: QUICK Mode Initiates, but Never Completes
- •Situation D: All IKE Messages Occur, but no Traffic Flows
- •A Final tcpdump Example
- •User Mode Linux Testing
- •Preparing the Openswan for the UML Build Process
- •Running the UMLs
- •Writing a UML Test Case
- •Debugging the Kernel with GDB
- •Asking the Openswan Community for Help
- •Internet Relay Chat (IRC)
- •The Openswan Mailing Lists
- •Posting to the Lists
- •Research First, Ask Later
- •Free, as in Beer
- •Do not Anonymize
- •Summary
- •Linux Kernel Developments
- •Kernel API Changes between 2.6.12 and 2.6.14
- •Red Hat Kernel Developments
- •Fedora Kernel Source/Headers Packaging Change
- •MD5 Insecurities
- •Discontinuation of Openswan 1 by the End of 2005
- •Update on UML Testing Suite Installation
- •Openswan GIT Repositories
- •Openswan on Windows and Mac OS X Updates
- •Known Outstanding Bugs
- •Vulnerability Fixes in Openswan 2.4.4
- •The OSI Model and the IP Model
- •No Layers, Just Packets
- •The Protocol
- •IP Network Overview
- •IP Address Management
- •The Old IP Classes
- •Classless IP Networks
- •The Definition of a Subnet
- •Calculating with Subnets: The Subnet Mask
- •The Rest of the Network
- •Linux Networking Commands
- •Routing
- •Routing Decisions
- •Peering
- •Network Address Translation
- •Port Forwarding
- •Openswan Links
- •Community Documentation
- •Generic Linux Distributions Containing Openswan
- •Specialized Linux Distributions Containing Openswan
- •Overview RFCs
- •Basic Protocols
- •Key Management
- •Procedural and Operational RFCs
- •Detailed RFCs on Specific Cryptographic Algorithms and Ciphers
- •Dead Peer Detection RFCs
- •NAT-Traversal and UDP Encapsulation RFCs
- •RFCs for Secure DNS Service, which IPSEC May Use
- •RFCs Related to L2TP, Often Used in Combination with IPsec
- •RFCs on IPsec in Relation to Other Protocols
- •RFCs Not in Use or Implemented across Multiple Vendors
- •Index
Introduction
If you play the online game of World of Warcraft, every title bar your computer displays, including subjects and recipient names of your emails, will be sent to the vendor, Blizzard, to ensure you "do not cheat" in the game. Governments have made secret deals with printer vendors such as Canon, who secretly implemented a 'fingerprint' on pages produced by their color printers in almost invisible yellow dots that encode the printer's serial number, as well as the date and time the page was printed. Anonymity and privacy has never been so far away. Neighbors can easily watch what you do on your wireless network at home. We are leaving our digital footprints everywhere, for better or worse. The Big Brothers (and even more little ones) are here to stay. Everyone needs to take their precautions. They should, and now can, use strong cryptography.
However, this freedom for the good guys also means that organized crime, petty thieves, vandals, frauds, and terrorists can use cryptography. This fact is often cited by governments to justify regulations to limit the use of cryptography for private citizens and to increase surveillance. Unfortunately, the "privacy versus security" argument is a persuasive one, although it is in our opinion a fallacy at best, and a deliberate misrepresentation at worst. The argument is framed with manipulative questions such as, "Would you be willing to sacrifice some privacy to increase your security against terrorism?" However, the truth is that privacy and security are separate issues. One need not be sacrificed for the other.
We will never be able to hide the information needed for terrorists to do harm, but we can show potential terrorists what a true free world has to offer. And a free world is not one where governments and corporations look at and predict all your steps along the way so they can manipulate, intervene, or maximize profits. Privacy is essential to what makes us individuals. It is a Human Right.
Security
Cryptography does not just provide privacy; it also provides security. Using cryptography we can ensure that we are talking to whom or what we intend, whether it is a person or an ATM machine. We can ensure that no one else is eavesdropping on us, and that no one else is pretending to be us. By encrypting data, we prevent information leakage. We protect against manipulation of our data stream. The security works both ways. We can trust them, and they can trust us. Security gives us integrity.
A History of the Internet
The Internet was, in fact, not invented by Al Gore. If one could bestow the invention of the Internet onto a single person, this person would be Jon Postel. However, he is not considered as the inventor of the Internet. By most, he is considered the first Guardian of the Internet.
The key to the Internet's success is that these millions of computers are able to communicate to one another without disrupting the communications of other computers trying to accomplish the same thing. At the core of that success is the Internet Protocol (IP). Another essential part of the Internet is the lack of central control, and the absence of any third-party approval—be it governmental or corporate—before one may communicate.
6
Chapter 1
Holding the Internet Together
The Internet is an international network. It is not owned by any organization. And though some governments would like to believe otherwise, it is not under the control of any national or international governmental body either. No single individual or company dictates how the Internet should be run or evolve, and no single restrictive non-free patented technology is necessary to communicate using the Internet. For this to continue, many parties need to agree on protocols, and on top of that, need to recognize and adhere to these protocols. These protocols usually have many options, which all parties communicating need to agree upon. Compare this to the 'car driving' protocol, where everyone agrees to stop for a red light, and to continue on a green light.
These formal registrations used to be maintained by one man, Jon Postel. The task was later delegated to a more formal group of technology people, the Internet Assigned Number Authority, IANA. In 1998 the US Department of Commerce (DoC) released two policy documents that called for the creation of a new body to govern these core functions of the Internet, which led to the creation of the Internet Committee for Assigned Names and Numbers, ICANN.
The Creation of ICANN
ICANN's creation was not very well received internationally, as it gave the US full control over the root of the Internet. As such, worldwide engineers largely ignored this non-technical political organization. An attempt was made to gain more widespread acceptance by reforming ICANN. Though this process started in 1998, it took years to complete. A famous Green Paper and White Paper with recommendations were written, leading to a Memorandum of Understanding (MoU) between ICANN and the DoC.
The 'ICANN at large' program, which allowed every individual to participate with ICANN and elect three board members, took two years to set up and was launched in 2000.
Two of these newly elected directors—Karl Auerbach, a legal scholar and Internet veteran who had been involved with the Internet before the Internet Protocol existed and Andreas Mueller-Maguhn from the German hacker community Chaos Computer Club—tried to get a true reform going but they were instantly blocked by the directors that had not been elected by the public. They were not even allowed to see the books of the organization they represented, and for which they were formally held responsible for.
The Electronic Freedom Frontier (EFF), a digital rights organization, assisted Auerbach so he could sue the Board of Directors in 2002. After he won the case, ICANN squirmed until finally a judge ordered ICANN to allow all the directors to see the books. However, while ICANN stalled handing out this information, it changed its own rules and more or less fired the At Large elected directors instead. It was pretty much apparent that ICANN was to be kept a US-only affair, and the international Internet community responded in a way that became typical of the Internet. It started to collectively maneuver around ICANN.
7
Introduction
ICANN Bypassed
ICANN was supposed to handle three separate tasks: protocol registrations, IP address allocation, and top-level domain (TLD) management.
Protocol registrations are really done by the IETF and IANA, and ICANN just stamps its approval. It completely lacks the skill or desire to interfere with this process.
The IP address allocation is really done by the Regional Internet Registries (RIRs), which are pro-actively ignoring ICANN completely. This became painfully obvious when the three major RIRs, ARIN (for North America and South America), RIPE (for Europe, Africa, and the Middle East), and APNIC (Asia and the Southern Pacific), set up the Number Resource Organization (NRO). They no longer acknowledged ICANN as the central authority for handing out IP allocations to the RIRs. It was nothing less than a coup d'état.
The Root Name Servers
For technical reasons, there should not be more than thirteen name servers for any given domain, including the root. Otherwise, a DNS query answer would not fit into a single UDP packet, greatly delaying the answer of DNS requests. These name servers, eleven in the US and two in Europe, were historically placed at locations with the best Internet connectivity. They were run by volunteers, often at the big universities. When ICANN formally received control, they only actually got control of one of these root name servers, the so called 'A' root server, although this is the ultimate master root server. The other twelve servers are set up to pull data from the 'A' server. The 'A' server is currently run for ICANN by Verisign.
The reliance of the entire Internet on only thirteen servers has been a major concern for those involved in Internet design. A new protocol was created, called ANYCAST. In essence, it allows an IP address to exist at multiple places at once, and a computer requesting that IP address will be directed to the nearest ANYCAST IP address. The most important non-US root server, 'K', is run by RIPE-NCC, the operational branch of RIPE. Using ANYCAST, it currently resides in multiple places, including the two biggest conglomerations of Internet connections, LINX in London and the AMSIX in Amsterdam. An important side effect of ANYCAST was that the international community is no longer as dependent on the 11 of the 13 root servers that are based in the US and which are still in large part formally under government control. It has greatly reduced ICANN's influence over the root. The 'K' root server is a prime candidate to split off from the 'A' server if for some technical or political reason such a change becomes necessary.
Running the Top-Level Domains
ICANN is left with only the top-level domain management. This task is perhaps the most politically loaded task, and not as technologically neutral as handing out IP addresses or Internet protocol numbers or running the root name servers.
There are two kinds of TLDs, country code TLDs ("cc:tld") and generic TLDs ("gtld"). The cc:tlds are fairly straightforward. There are already international ISO procedures for this. Every country receives a two or three letter representation. The US has 'us', the Netherlands has 'nl', and China has 'ch'. These translate one to one to the top-level domains, .us, .nl, and .ch respectively.
8