Swan: Securing the Internet against Wiretapping

My project for 1996 was to secure 5% of the Internet traffic against passive wiretapping. (It didn't happen in 1996, so I'm still working on it in 1997.) If we get 5% this year, we can secure 20% next year, against both active and passive attacks; and 80% the following year. 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, email, IRC, Usenet, etc. The encryption boxes will be standard PC's that use freely available software that you can download over the Internet.

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.

Deployment

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.

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.

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

Protocols

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.

Linux Implementation

The Linux implementation of the low-level packets is in its fourth alpha test release, and is reliably exchanging encrypted packets with itself. See below for how to obtain it.

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.

Why?

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 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.1 release from Red Hat). Give the machine two Ethernet cards.

Install and test the kernel changes manually

If you're an experienced sysadmin 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. 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.

Date: Wed, 29 Jan 1997 09:29:36 +0200
From: John Ioannidis 

A few days ago I released version 0.4 of my Linux IPSEC code. It can be found 
in ftp://ftp.funet.fi/pub/unix/security/net/ip/.

New in this release is support for all the currently defined transforms; of 
particular interest should be AH-HMAC-SHA1 and ESP-3DES-MD5.

Release 0.4 is by no means perfect; it still has to undergo a lot of work 
before it can be something a nonexpert user can just install and have work 
right out of the box. For that, I need your help. If you find bugs, please 
report them; if you can provide a fix, so much the better. The documentation 
file that comes with the release lists a whole bunch of areas that need work. 
If you can work on any of these, please tell me so.

Please note that in some countries such as the USA, it is unlawful for
a citizen of that country to provide technical assistance "with the
intent to aid a foreign person in the development or manufacture outside
the United States" of "Encryption Items". Also, in countries such as
France, it is unlawful to even use cryptography without notifying the
authorities. Naturally, I don't expect help from people in the USA or
France, but there must be *some* people in the rest of the world who
can offer some!

/ji

Get on the linux-ipsec mailing list

The discussion forum for people working on the project, and testing the code and documentation, 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". (You can later get off the mailing list the same way -- just send "unsubscribe linux-ipsec").

Check back at this web page every once in a while

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.

Related projects

IPSEC for NetBSD

This prototype implementation of the IP Security protocols is for another free operating system. Download BSDipsec.tar.gz.

IPSEC for OpenBSD

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.

Misc notes