outing in the public Internet is based on a distributed system composed of many routers, grouped into management domains called Autonomous Systems (ASes). ASes are operated by Internet Service Providers (ISPs) and by multihomed subscribers. (Throughout the remainder of this article, for brevity, we will talk in terms of ISPs, usually omitting references to multihomed subscribers.) Routing information is exchanged between ASes using the Border Gateway Protocol (BGP)[1], R via UPDATE messages. BGP is used in two different contexts. External BGP (eBGP) propagates routes between ISPs. BGP also is used within an AS to propagate routes acquired from other ASes. This latter use is referred to as internal BGP (iBGP). eBGP is the primary focus of this article, because failures of eBGP can adversely affect large portions of the Internet, well beyond the administrative boundary of the source of the failure. Nonetheless,

Introduction In February 1999, we performed an evaluation of IPsec based on the November 1998 RFCs for IPsec [KA98c, KA98a, MG98a, MG98b, MD98, KA98b, Pip98, MSST98, HC98, GK98, TDG98, PA98]. Our evaluation focused primarily on the cryptographic properties of IPsec. We concentrated less on the integration aspects of IPsec, as neither of us is intimately familiar with typical IP implementations, IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. We are not alone in this opinion; from various discussions with the people involved, we learned that virtually nobody is satisfied with the process or the result. The development of IPsec seems to have been burdened by the committee process that it was forced to use, and it shows in the results. Even with all the serious critisisms that we have on IPsec, it is probably the best IP security protocol available at the moment. We hav

The Border Gateway Protocol (BGP) is a critical component of the Internet routing infrastructure, used to distribute routing information between autonomous systems (ASes). It is highly vulnerable to a variety of malicious attacks and benign operator errors. Under DARPA sponsorship, BBN has developed a secure version of BGP (S-BGP) that addresses most of BGP's architectural security problems. This paper reviews BGP vulnerabilities and their implications, derives security requirements based on the semantics of the protocol, and describes the S-BGP architecture. Refinements to the original S-BGP design, based on interactions with ISP operations personnel and further experience with a prototype implementation are presented, including a heuristic for significantly improving performance. The paper concludes with a comparison of S-BGP to other proposed approaches.

Virtual private networks (VPNs) allow two or more parties to communicate securely over a public network. Using cryptographic algorithms and protocols, VPNs provide security services such as confidentiality, host authentication and data integrity. The computation required to provide adequate security, however, can significantly degrade performance. In this paper, we characterize the extent to which data compression can alleviate this performance problem in a VPN implemented with the IP Security Protocol (IPsec).

Some high-speed IPsec hardware systems need to support many thousands of security associations. The cost of switching among different encryption keys can dramatically affect throughput, particularly for the very common case of small packets. Three of the AES finalists (Rijndael, Serpent, and Twofish) provide very high key agility, as is required for such applications. The other two candidates (MARS, RC6) exhibit low key agility and may not be appropriate for use in such equipment.

Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router. The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet. This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet

We present ISP, a novel architecture for Internet Service Providers suitable for installation in airports, hotels, conference centers, caf es, and office or apartment buildings. Users access a ISP via a low-cost, high-bandwidth LAN, e.g. Ethernet or WaveLAN. A router connects the ISP's LAN to a shared high-bandwidth access link (e.g., DSL or cable) to a conventional ISP. For this service, a ISP charges its clients. The architecture supports a variety of payment methods, both offline (e.g., cash, credit card, or billing to a hotel room account) and online (e.g., eCash, SET, IBM Micro Payments, or Millicent). ISPs use IPSec's IKE protocol for securely exchanging authentication keys with paying users. Paying users use IPSec's AH protocol in tunnel mode to authenticate each packet they send. Therefore, ISPs can easily detect and drop packets of nonpaying users. A ISP must present to users a certificate signed by a recognized authority, but a user may simply present a self-signed certificat...

As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making Internet Protocol version 6 (IPv6) mandatory in their specifications.

A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). Table of Contents 1

This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion, ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future.