This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for Relying Parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs.

We examine a form of an X.509 Public Key certificate that is used to bind IP address and AS number resources to a public/private key pair. These certificates are used to attest to resource allocation actions, so that digitally signed attestations relating to a party's right-of-use of IP addresses and AS numbers can be validated by relying parties, using a related Resource Certificate Public Key Infrastructure. This has particular application in the area of demonstrable attestations related to the right-of-use of IP addresses, and in the area of inter-domain routing security. The issues related to the application of this PKI to inter-domain routing security are considered, and the design, management and use of resource certificates, and the structure of the related Public Key Infrastructure are described in detail.

A PKI in support of secure Internet routing was first proposed in [1] and refined in later papers, e.g., [2]. In this “Resource” PKI (RPKI) the resources managed are IP address allocations and Autonomous System number (AS #) assignments. The RPKI presents a very different implementation challenge from a typical PKI,in that in the RPKI every relying party needs to validate every certificate and CRL at fairly frequent intervals (e.g., daily). In a fully deployed RPKI there will be several hundred thousand digital objects that require validation, so performance is a critical issue for any software implementation. This paper describes the software developed by BBN for use by relying parties in the RPKI, with a special focus on the means and methods used to realize a high performance design. Theoretical discussions are augmented with actual performance data. Highly favorable performance statistics for the BBN approach are concretely demonstrated.

X.509 Public Key certificates are typically used to validate attestations related to identity or role. The overwhelming number of large scale deployments seen in public networks serve this purpose. Here, we examine a different form of X.509 certificate that is used to describe IP address and AS number resources and bind them to a public/private key pair. These certificates are used to attest to resource allocation actions, so that digitally signed attestations relating to a party's right-of-use of IP addresses and AS numbers can be validated by relying parties, using a related Resource Certificate Public Key Infrastructure (RPKI). This has particular application in the area of demonstrable attestations related to the right-of-use of IP addresses, and in the area of inter-domain routing security. The issues related to the application of this RPKI to inter-domain routing security are considered, and the design, management and use of resource certificates, and the structure of the related Public Key Infrastructure are described in detail.

This paper presents an analysis of IPv6 and its support protocols from the point of view of Information Assurance. It describes the IPv6 protocol suite, compares and contrasts it to the IPv4 protocol suite, and identifies IA issues that will arise during a migration of core networks from IPv4 to IPv6. It identifies decisions that will have to be made by policymakers, and provides recommendations on the best way to proceed.

The Border Gateway Protocol (BGP) [1] is the foundation of inter-domain Internet routing. A number of papers have described how BGP is highly vulnerable to a wide range of attacks [2, 3], and several proposals have been offered to secure BGP [4, 5, 6, 7, 8]. Most of these proposed mechanisms rely on a PKI, to provide trusted inputs for routing security mechanisms, to enable BGP routers to reject bogus routing advertisements. This paper provides a detailed proposal for a PKI, including a repository system, representing IP address allocation and Autonomous System number assignment,. This infrastructure offers a near term opportunity to improve routing security, since it does not require changes to routers, while also setting the stage for more comprehensive BGP security initiatives in the future.

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.

The design of the IP protocol makes it difficult to reliably identify the originator of an IP packet. Even in the absence of any deliberate attempt to disguise a packet's origin, widespread packet forwarding techniques such as NAT and encapsulation may obscure the packet's true source. Techniques have been developed to determine the source of large packet flows, but, to date, no system has been presented to track individual packets in an efficient, scalable fashion. We present a hash-based technique for IP traceback that generates audit trails for traffic within the network, and can trace the origin of a single IP packet delivered by the network in the recent past. We demonstrate that the system is effective, space efficient (requiring approximately 0.5% of the link capacity per unit time in storage), and implementable in current or next-generation routing hardware. We present both analytic and simulation results showing the system's effectiveness.

Much of the literature related to public key infrastructure (PKI) uses terms such as “trust” extensively and assumes that certification authorities (CAs) are trusted third parties (TTPs). It is certainly true that the best known CAs today are commercial TTPs, and such CAs have played an important role in making the general public aware of PKIs. But, not all PKIs need adopt this sort of CA model, in which relying parties are required to make value judgments about the trustworthiness of the organizations that operate CAs. PKIs are not intrinsically valuable. They are infrastructures that, if successful, facilitate authentication and authorization services based on the use of public key cryptography. Thus it is appropriate to ask questions about these services:

The design of the IP protocol makes it difficult to reliably identify the originator of an IP packet. Even in the absence of any deliberate attempt to disguise a packet's origin, wide-spread packet forwarding techniques such as NAT and encapsulation may obscure the packet's true source. Techniques have been developed to determine the source of large packet flows, but, to date, no system has been presented to track individual packets in an efficient, scalable fashion.We present a hash-based technique for IP traceback that generates audit trails for traffic within the network, and can trace the origin of a single IP packet delivered by the network in the recent past. We demonstrate that the system is effective, space-efficient (requiring approximately 0.5% of the link capacity per unit time in storage), and implementable in current or next-generation routing hardware. We present both analytic and simulation results showing the system's effectiveness.

The Source Path Isolation Engine (SPIE) is a system capable of tracing a single IP packet to its point of origin or point of ingress into a network. SPIE supports tracing by scoring a few bits of unique information about each packet for a period of time as the packets traverse the network. Software implementations of SPIE can trace packets through networks comprised of slow-to-medium speed routers (up to OC-12), but higher-speed routers (OC-48 and faster) require hardware support. In this paper, we discuss these hardware design aspects of SPIE. Most of the hardware resides in a self-contained SPIE processing unit, which may be implemented in a line card form factor for insertion into the router itself or as a stand-alone unit that connects to the router through an external interface.

article Free AccessCrypto policy perspectives Authors: Susan Landau Univ. of Massachusetts, Amherst Univ. of Massachusetts, AmherstView Profile , Stephen Kent Bolt Beranek and Newman Inc. Bolt Beranek and Newman Inc.View Profile , Clinton C. Brooks National Security Agency National Security AgencyView Profile , Scott Charney Dept. of Justice Dept. of JusticeView Profile , Dorothy E. Denning Georgetown Univ., Washington, DC Georgetown Univ., Washington, DCView Profile , Whitfield Diffie Sun Microsystems Sun MicrosystemsView Profile , Anthony Lauck Digital Equipment Corp. Digital Equipment Corp.View Profile , Douglas Miller Software Publishers Assoc. Software Publishers Assoc.View Profile , Peter G. Neumann ACM Committee on Computers and Public Policy, New York, NY ACM Committee on Computers and Public Policy, New York, NYView Profile , David L. Sobel Electronic Privacy Information Center (EPIC) Electronic Privacy Information Center (EPIC)View Profile Authors Info & Claims Communications of the ACMVolume 37Issue 8Aug. 1994 pp 115–121https://doi.org/10.1145/179606.179726Published:01 August 1994Publication History 10citation239DownloadsMetricsTotal Citations10Total Downloads239Last 12 Months13Last 6 weeks4 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

article Free Access Share on Internet Privacy Enhanced Mail Author: Stephen T. Kent Bolt Beranek and Newman, Cambridge, MA Bolt Beranek and Newman, Cambridge, MAView Profile Authors Info & Claims Communications of the ACMVolume 36Issue 8Aug. 1993pp 48–60https://doi.org/10.1145/163381.163390Published:01 August 1993Publication History 71citation1,927DownloadsMetricsTotal Citations71Total Downloads1,927Last 12 Months98Last 6 weeks15 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

This RFC specifies the U.S. Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038 \"Revised IP Security Option\", dated January 1988.

This paper describes how the error detection and recovery mechanisms of the proposed National Bureau of Standards (NBS) transport layer protocol can be easily extended to provide secure transmission of information. The security mechanisms are based on the Data Encryption Standard (DES) of the NBS. Two distinct security architectures are described. In the first, the DES hardware is a peripheral I/O device of the computer in which the transport layer resides. In the other, encryption is performed by a hardware device located in the data path between the transport layer and the network layer. The paper argues that, in the long run, the transport layer should be implemented in a front end computer equipped with a DES peripheral. This isolates it from (possibly untrustworthy) host software, and greatly simplifies the job of certifying its correct behavior.