199612: Securing the Internet


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. Want to help?
http://www.cygnus.com/~gnu/swan.html,
John Gilmore, gnu@toad.com

The Internet's packet switching technology is remarkably efficient, flexible, and robust. Unfortunately, it is also remarkably open to snooping, spoofing, and other anti-social activities. My email to Apple Computer (less than fifty miles away) passes through a dozen different machines. Any one of these machines is quite free to scan my packets, modify them on the fly, etc.

At the risk of sounding paranoid, I must admit that this makes me a bit nervous. PTF is probably too small to attract commercial espionage, and I don't think the FBI is watching my email, but there are other possibilities. Larceny is one: it wouldn't be all that hard to write a daemon that trolls for order forms, etc. You could pick up a few credit card numbers that way...

Using PGP (Pretty Good Privacy) for selected applications (e.g., email) is a good idea, but it is only a partial solution. What about all the other kinds of Internet traffic? A more radical solution would cause all Internet packets to be encrypted. That way, everything from email to WWW browsing would be covered. And, because everything would be encrypted, encrypted items would no longer attract attention.

IP Packets

The IP (Internet Protocol) packet is the basic unit of Internet communication. If we could make IP packets secure, all the higher-level protocols (TCP, UDP, etc.) and applications would immediately become far more secure.

Each IP packet consists of a header and some data. The header consists of source and destination IP addresses, a protocol type flag, and an options field. None of this can be encrypted; it is used in routing the packet. Consequently, any interested spook will be quite able to tell which machines are involved, etc.

The data, however, can be encrypted, compressed, signed, and otherwise munged. Assuming that the IP code in the receiving system can deal with these actions, the applications and users can ignore them. And, if the receiving system cannot deal with encryption, the sending system can use the old-style, insecure method.

Groundwork

Before we can encrypt IP packets, we need to ensure that we are talking to right machine. The Domain Name System (DNS), which takes care of this, is itself rather insecure at present. Consequently, the first step in securing the Internet is to secure DNS.

This step is already under way. As announced on John Gilmore's DNS Security mailing list:

Paul Vixie has made the first public test release of BIND [Berkeley Internet Name Domain service] that contains partial DNS Security support. ... DNS Security provides protection against the spoofing of DNS records by parties other than those to whom the name space was delegated. It also provides a convenient infrastructure for the publication of keys or certificates by any entity which desires to do so, for use in other protocols.

The current implementation of DNS Security uses no cryptography; thus, it should be completely exportable. Interested parties are invited to pick up a copy from http://www.isc.org/isc/. At this writing, the latest version is BIND 4.9.5-T3B.

By supporting the "publication of keys or certificates", the new BIND server paves the way for the exchange of cryptographic keys (needed for encrypted IP). And, to make these keys trustworthy, a more secure version of the DNS Security technology is under development. Because it employs cryptography, it must be cleared for export. This is already in process:

Trusted Information Systems has received an official determination that their product is not controlled by the State Department, because it only does authentication rather than information secrecy. The Commerce Department is still chewing on their request for general export to all destinations, which should be approved because the code is available for public distribution, and their regulations have a specific exemption for that.

John Gilmore will be working with TIS and Paul Vixie to merge TIS's prototype code into the production BIND release, once the export issue is resolved. In the interim, TIS' code is only available to US citizens. For details, see ftp://ftp.tis.com/pub/DNSSEC/README and http://www.tis.com/docs/research/network/iip.html.

The S/WAN (Secure Wide Area Network) page (http://www.cygnus.com/~gnu/swan.html) contains current project status and pointers to source code and documentation for both the DNS Security and the IP packet security work.

Further Reading

Schneier's "Applied Cryptography" (2nd. ed., Wiley, 1996) is an excellent introductory work. Chapman and Zwicky's "Building Internet Firewalls" (O/Reilly, 1995) provides a good introduction to Internet security issues. Pabrai's "UNIX Internetworking" (2nd. ed., Artech House, 1996) ties Internet definitions and issues to specific UNIX routines.

Finally, Denning's "Computers Under Attack" (ACM, 1990) is an excellent survey of computer-related security issues. If you haven't read Ken Thompson's "Reflections on Trusting Trust" (also available in "Communications of the ACM, August 1994, Vol. 27 Issue 8, p. 761), you've missed some excellent (and nicely twisted) reasoning.


This material was originally published in Rich Morin's column "The Internet Notebook" in UNIX
Review magazine (now known as Performance Computing magazine).

Send comments, inquiries, or trouble reports to webmaster@cfcl.com.

Copyright © 1993-1999 Rich Morin. All Rights Reserved.