Enclosed below is my submission for the conference. --Steve Bellovin ---- Security for the NGI Steven M. Bellovin smb@research.att.com AT&T Labs -- Research Room 2B-104 600 Mountain Avenue Murray Hill, NJ 07974 908-582-5886 908-582-3063 (fax) There is no doubt that a next generation Internet will need to have security designed in from the beginning. It should be noted, though, that for the most part, the problem today is not with the design of the protocols or the net. With minor exceptions, any replacement of comparable power would face many of the same issues. That said, there are areas for improvement. The most obvious is the need for cryptography. The Next Generation Internet can and should be designed so that cryptography is ubiquitous, largely transparent, and used universally where appropriate for authentication and/or privacy. Even at a more abstract level, it is not clear that today's cryptographic primitives are adequate. If nothing else, encryption, hashing, and authentication algorithms are quite expensive. Given the limited line speeds in today's long-haul nets, client hosts can easily keep up; as line speeds increase, the load will become more of a burden, especially for servers. But cryptography cannot solve ``the'' Internet security problem. An analysis of the CERT advisories for the last 18 months shows that two or three, out of about 30, would be moot if cryptography were universally deployed. Most of the problems are due to buggy software, bad administration, or both. We do not have a magic wand big enough to solve that problem. Nor have several decades of research produced any silver bullets. Nevertheless, we must continue to pursue it; without correct software, we will never have a secure net. There are several possible approaches. One, of course, is a Next Generation Orange Book. While not a bad idea per se, the philosophical approach has to change. The Orange Book is predicated on the idea that there is one central security model and one security kernel whose job it is to enforce the model. That approach doesn't scale well to today's Internet. Consider the case of a service bureau machine running Web servers on behalf of several mutually suspicious companies. The isolation between companies -- an administratively-decreed structure -- can probably be accomodated within the constraints of the traditional model. The network interface, however, is open to all; there is no barrier to sending anything out, or receiving anything. The individual server programs have their own trust structure. Credit cards numbers -- that is, data only a few bytes long -- must be rigorously protected. But the card number verification process may require that the numbers be sent to a bank. Some merchants even store credit card numbers in a long-term database, so that they need not be entered each time. How can this fine-grained protection be implemented? Another consequence of buggy code is that firewalls will continue to be needed. However, their nature will change. First, as there is more and more interconnectivity, we need more firewalls, with finer-grained protection. The big corporate design won't work. Second, we need better policy controls on what can pass through a firewall. This may imply more application proxies, but they have to be much faster and much more flexible. Third, there are some firewall-hostile protocols out there. We need newer protocols that can co-exist better with simple firewalls. To give just one example, TCP is much more easily passwd by a firewall, because header bits can differentiate, in a context-independent fashion, between incoming and outgoing calls. This doesn't work with UDP. But in reality, despite its datagram nature, most of the useful applications built on top of UDP use a query-response protocol. A different design would have permitted easy firewall filtering of such messages. There are certainly other security challenges facing the NGI. Here I've identified three that are easily forseeable, but must be dealt with if the new net is to be secure.