[UKUUG Logo] Copyright © 1995-2004 UKUUG Ltd



Newsletter Section 8

From the Net

Swan: Securing 5% of the Internet against Wiretapping in 1996

(John Gilmore)

My project for 1996 is to secure 5% of the Internet traffic against passive wiretapping. If we get 5% this year, we can secure 20% next year, against both active and passive attacks; and 80% in 1998. Soon the whole Internet will be private and secure. It's called S/WAN or S/Wan or Swan for Secure Wide Area Network; RSA came up with the term. Want to help?

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, IRC, Usenet, etc.

This wasn't just my idea; lots of people have been working on it for years. The encryption protocols for these boxes are called IPSEC (IP Security). They have been developed by the IP Security Working Group of the Internet Engineering Task Force and will be a standard part of the next major version of the Internet protocols (Ipv6). For today's (IP version 4) Internet, they are an option. The Internet Architecture Board and Internet Engineering Steering Group have taken a strong stand 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.

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.


The US government would like to control the deployment of IP Security with the crypto export laws. This isn't a problem for my effort, because the cryptographic work is happening outside the United States. A foreign philanthropist has donated the resources required to add these protocols to the Linux operating system.

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.

Travellers 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.

There will also be numerous commercially available firewalls that use this technology. RSA Data Security is coordinating the S/Wan (Secure Wide Area Network) project among more than a dozen vendors who use these protocols. There's a compatability chart that shows which vendors have tested their boxes against which other vendors to guarantee interoperatility.

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. I've had discussions with several other operating system and protocol stack vendors, but none is ready to announce their product or direction yet.

Current status

My goal of securing 5% of the net by Christmas 1996 will not be met. It was an ambitious goal and inspired me and others to work, but was ultimately too ambitious. I've backed down; the current goal is to get the first set of complete and working software released by Christmas.


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 pretty much 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.

Linux Implementation

The Linux implementation of the low-level packets is in alpha test and is exchanging encrypted packets with itself.

Domain Name System Security

The first prototype implementation of Domain Name System Security was funded by DARPA as part of their Information Survivability program. Trusted Information Systems wrote a modified version of BIND, the widely-used Berkeley implementation of the Domain Name System, and it is now available for worldwide FTP. (The State and Commerce departments have OK'd its export - it only does authentication, not information-hiding.)

I am merging the prototype into the standard version of BIND. The first production version that supports KEY and SIG records is bind-4.9.5. This or any later version of BIND will do for publishing keys. It is available from the Internet Software Consortium FTP site. This version of BIND is not export-controlled since it does not contain any cryptography. Future releases with more and more DNS Security features, eventually

including cryptographic validation, will also appear there; all versions will be exportable.


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.

What You Can Do

Install the latest BIND at your site.
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 named, the Name Daemon, which knows about the new KEY and SIG record types. So, download it ( ftp://ftp.vix.com/pub/bind/
) from the Internet Software Consortium 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.

Set up a Linux system and run a 2.x kernel on it
Get a machine running Linux (say the 4.0 release from Red Hat). Give the machine two Ethernet cards.

Install and test the kernel changes manually
If you're an experienced system administrator or Linux hacker, install these changes. You can test them in your local environment by manually configuring an encrypted tunnel with another test site. This set of changes does NOT provide automated “opportunistic” operation; it must be manually configured for each site you wish to encrypt with. Also, it only uses DES at the moment (3DES is in the works). This is an alpha-test release to shake out some of the early bugs and to start getting the Linux and IPSEC communities familiar with the code.

Get on the linux-ipsec mailing list
The discussion forum for people working on the project is linux-ipsec@clinet.fi . To join this mailing list, send email to linux-ipsec-REQUEST@clinet.fi containing a line of text that says “subscribe linux-ipsec”.

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 e- mail at gnu@toad.com . 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 CV 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 e-mail.
Volunteer projects just don't work without those things.

Tel: 01763 273 475
Fax: 01763 273 255
Web: Webmaster
Queries: Ask Here
Join UKUUG Today!

UKUUG Secretariat