Secure Inter-Domain Routing R. Barnes
Working Group S. Kent
Internet Draft BBN Technologies
Intended status: Informational February 23, 2007
Expires: August 2007
An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes an architecture for an infrastructure to
support secure Internet routing. The foundation of this architecture
is a public key infrastructure (PKI) that represents the allocation
hierarchy of IP address space and Autonomous System Numbers;
Barnes & Kent Expires August 23, 2007 [Page 1]
Internet-Draft Secure Routing Architecture February 2007
certificates from this PKI are used to verify signed objects that
authorize autonomous systems to originate routes for specified IP
address prefixes. The data objects that comprise the PKI, as well as
other signed objects necessary for secure routing, are stored and
disseminated through a distributed repository system. This document
also describes at a high level how this architecture can be used to
add security features to common operations such as IP address space
allocation and route filter construction.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction...................................................3
2. PKI for Internet Number Resources..............................4
2.1. Role in the overall architecture..........................4
2.2. CA Certificates...........................................5
2.3. End-Entity Certificates...................................5
2.4. Trust Anchors.............................................6
3. Route Origination Authorizations...............................6
3.1. Role in the overall architecture..........................7
3.2. Syntax and semantics......................................7
3.3. Revocation................................................8
4. Repository system..............................................8
4.1. Role in the overall architecture..........................9
4.2. Contents and structure....................................9
4.3. Access protocols.........................................10
4.4. Access control...........................................10
5. Common Operations.............................................11
5.1. Certificate issuance.....................................11
5.2. ROA management...........................................12
5.2.1. Single-homed subscribers (without portable allocations)
...........................................................12
5.2.2. Multi-homing........................................13
5.2.3. Portable allocations................................13
5.3. Route filter construction................................13
6. Security Considerations.......................................14
7. IANA Considerations...........................................14
8. Acknowledgments...............................................14
Barnes & Kent Expires August 23, 2007 [Page 2]
Internet-Draft Secure Routing Architecture February 2007
9. References....................................................15
9.1. Normative References.....................................15
9.2. Informative References...................................15
Author's Addresses...............................................15
Intellectual Property Statement..................................16
Disclaimer of Validity...........................................16
1. Introduction
This document describes an architecture for an infrastructure to
support improved security for BGP routing [2] for the Internet. The
architecture described by this document supports, at a minimum, two
types of routing security: It enables an entity to verifiably assert
that it is the legitimate holder of a set IP addresses or a set of
Autonomous System (AS) numbers, and it allows the holder of IP
address space to explicitly and verifiably authorize an AS to
originate routes to that address space. In addition to these initial
applications, however, this architecture could also support, without
extension, more advanced security protocols such as S-BGP [7] or
soBGP [8]. This architecture is applicable to routing of both IPv4
and IPv6 datagrams.
In order to facilitate deployment, the architecture takes advantage
of existing technologies and practices. The structure of the
architecture corresponds to the existing resource allocation
structure, so that management of this architecture is a natural
extension of the resource-management functions of organizations that
are already responsible for IP address and AS number resource
allocation. Likewise, existing resource allocation and revocation
practices have well-defined correspondents in this architecture. To
ease implementation, existing IETF standards are used wherever
possible; for example, extensive use is made of the X.509 certificate
profile defined by PKIX [3] and the extensions for IP Addresses and
AS numbers defined in RFC 3779 [4].
The architecture is comprised of three main components: An X.509
public-key infrastructure (PKI) where certificates attest to holdings
of IP address space and AS numbers; signed objects called Route
Origination Authorizations (ROAs) that enable an address space holder
to explicitly authorize an AS to originate routes to portions of the
IP address space; and a distributed repository system that makes
these objects available for use by ISPs in making routing decisions.
These three basic components enable several security functions; this
document describes how they can be used to improve route filter
generation, and to perform several other common operations in such a
way as to make them cryptographically verifiable.
Barnes & Kent Expires August 23, 2007 [Page 3]
Internet-Draft Secure Routing Architecture February 2007
2. PKI for Internet Number Resources
Because the holder of a block IP address space is entitled to define
the topological destination of IP datagrams whose destinations fall
within that block, decisions about inter-domain routing are
inherently based on knowledge the allocation of the IP address space.
Thus, a basic function of this architecture is to provide
cryptographically verifiable attestations as to these allocations. In
current practice, the allocation of IP address is hierarchic: The
holder of a set of IP addresses may sub-allocate portions of that
set, either to itself (e.g., to a particular unit of the same
organization), or to another organization. Because of this
structure, IP address allocations can be described naturally by a
hierarchic public-key infrastructure, in which each certificate
attests to an allocation of IP addresses, and signing of subordinate
certificates corresponds to sub-allocation of IP addresses. The
above reasoning holds true for AS number resources as well, with the
difference that, by convention, AS numbers may not be sub-allocated
except by registries. Thus allocations of both IP addresses and AS
numbers can be expressed by the same PKI. Such a PKI is a central
component of this architecture.
2.1. Role in the overall architecture
Certificates in this PKI are called Resource Certificate, and conform
to the certificate profile for such certificates [5]. Resource
certificates attest to the allocation by the (certificate) issuer of
IP addresses or AS numbers to the subject. They do this by binding
the public key contained in the Resource Certificate to the IP
addresses or AS numbers included in the certificate's IP Address
Delegation or AS Identifier Delegation Extensions. An important
property of this PKI is that the names assigned to certificate
issuers and subjects are not intended to be meaningful; this is in
contrast to most PKIs where considerable effort is expended to ensure
that the subject name in a certificate is properly associated with
the entity that holds the private key corresponding to the public key
in the certificate. This PKI is different because it is an
authorization PKI, not an authentication PKI. Because issuers need
not verify the right of an entity to use a subject name in a
certificate, they avoid the costs and liabilities of such
verification. This makes it easier for these entities to take on the
additional role of CA. Only the basic PKI requirement, that a CA not
associate the same name with two distinct subjects to whom it issues
certificates, is imposed.
The certificates in the PKI assert the basic facts on which the rest
of the infrastructure operates. Certificates within the CA hierarchy
Barnes & Kent Expires August 23, 2007 [Page 4]
Internet-Draft Secure Routing Architecture February 2007
attest to IP address space and AS number holdings. End-entity
certificates are issued by resource holders to delegate the authority
attested by their allocation certificates, the primary use for this
being the signing of ROAs. These certificates and corresponding
certificate revocation lists will comprise a significant portion of
the data stored in the repository system.
2.2. CA Certificates
Any holder of Internet Number Resources who is authorized to sub-
allocate them must be able to issue Resource Certificates to
correspond to these sub-allocations. Thus, for example, CA
certificates will be associated with each of the Regional Internet
Registries, National Internet Registries, and Local Internet
Registries, as well as with all ISPs. A CA certificate is also
necessary for a resource holder to issue ROAs (because it must also
issue the corresponding end-entity certificates used to validate
ROAs), so many subscribers also will need to have CA certificates for
their allocations (in particular, multi-homed subscribers, and
subscribers with portable allocations).
Each Resource Certificate attests to an allocation of resources to
its holder, so entities that have allocations from multiple sources
will have multiple CA certificates. (A CA also may issue distinct
certificates for each distinct allocation to the same entity, if the
issuer and the resource holder agree that such an arrangement will
facilitate management and use of the certificates.)
2.3. End-Entity Certificates
Although the private key corresponding to public key contained in an
end-entity certificate is not used to sign other certificates in the
PKI, the primary function of end-entity certificates in this PKI is
the verification of signed objects that relate to the usage of the
resources described in the certificate, e.g., ROAs. For this
purpose, there is a one-to-one correspondence between end-entity
certificates and signed objects, i.e., the private key corresponding
to each end-entity certificate is used to sign exactly one object,
and each object is signed with one key. This property allows the PKI
itself to be used to revoke these signed objects. When the end-entity
certificate used to sign an object has been revoked, the signature on
that object (and any corresponding assertions) will be considered
invalid, so a signed object can be effectively revoked by revoking
the end-entity certificate used to sign it.
A secondary advantage to this one-to-one correspondence is that the
private key corresponding to the public key in a certificate is used
Barnes & Kent Expires August 23, 2007 [Page 5]
Internet-Draft Secure Routing Architecture February 2007
exactly once in its lifetime, and thus can be destroyed after it has
been used to sign its one object. This fact should simplify key
management, since only the public portions of end-entity certificates
will need to be retained for any significant length of time.
Although this document defines only one use for end-entity
certificates, additional uses will likely be defined in the future.
For example, end-entity certificates could be used as a more general
authorization for their subjects to act on behalf of the holder of
the indicated resources. This could facilitate authentication of
inter-ISP interactions, or authentication of interactions with the
repository system. These additional uses for end-entity
certificates, however, may require retention of the corresponding
private keys, even though this is not required for the private keys
associated with end-entity certificates keys used for verification of
ROAs, as described above.
2.4. Trust Anchors
In any PKI, each relying party (RP) is free to choose its own set of
trust anchors. In this case, the hierarchy of this PKI is structured
according to the IP address space and AS number allocation hierarchy,
so since administrative control of the IP address space (the root of
the allocation hierarchy) rests with IANA and the RIRs , these
entities form a natural set of default trust anchors for this PKI.
Nonetheless, every relying party is free to choose a different set of
trust anchors to use for certificate validation operations.
For example, an RP could create one or more self-signed certificates
to which all address space and/or all AS numbers are assigned, and
for which the RP knows the corresponding private key. The RP could
then issue certificates under these trust anchors to whatever
entities in the PKI it wishes, with the result that the certificate
paths terminating at these locally-installed trust anchors will
satisfy the RFC 3779 validation requirements.
An RP who elects to create and manage its own set of trust anchors
may fail to detect allocation errors that arise under such
circumstances, but the resulting vulnerability is local to the RP.
3. Route Origination Authorizations
The information on IP address allocation provided by the PKI is not
in itself sufficient to guide routing decisions. In particular, BGP
is based on the assumption that the AS that originates routes for a
particular block of IP address space is authorized to do so by the
holder of that block; the PKI contains no information about these
Barnes & Kent Expires August 23, 2007 [Page 6]
Internet-Draft Secure Routing Architecture February 2007
authorizations. A Route Origination Authorization (ROA) make such
authorization explicit, allowing a holder of address space to create
an object that explicitly and verifiably asserts that an AS is
authorized originate routes to that address space.
3.1. Role in the overall architecture
A ROA is an attestation that the holder of a set of IP addresses has
authorized an autonomous system to originate routes for that set of
IP addresses. A ROA is structured according to format described in
[6]. The validity of this authorization depends on the issuer of the
ROA being the owner of the set of IP addresses in the ROA; this fact
is asserted by an end-entity certificate from the PKI, whose
corresponding private key is used to sign the ROA. The repository
system will be the primary mechanism for disseminating ROAs, since
the operators of repositories already provide other types routing
information. In addition, ROAs could also be distributed in BGP
UPDATE messages or via other communication paths, since route
filtering is their primary application.
3.2. Syntax and semantics
A ROA constitutes an explicit authorization for a single AS to
originate routes to one or more prefixes, and is signed by the holder
of those prefixes. A ROA thus have three essential components:
1. An AS number
2. One or more IP address prefixes
3. A digital signature
In addition, a ROA has a version number, to accommodate changes in
syntax (or semantics) over time. The AS number contained in a ROA is
that of an AS authorized to originate routes for the indicated IP
address prefixes. Only one AS number is contained in a ROA in order
to simplify ROA management, e.g., to avoid the complexity that might
arise is AS numbers for multiple ISPs were referenced from a single
ROA. If an ISP serving a subscriber has multiple AS numbers, and
wants the address space holder to authorize advertisement of the same
set of prefixes by any of these ASes, the ISP should request the
subscriber to issue multiple ROAs, each specifying a distinct AS
number. Similarly, a multi-homed address space holder must generate
multiple ROAs, one for each ISP that will originate routes for it.
A ROA is signed using the private key whose public key is contained
in an end-entity certificate in the PKI, from which the ROA inherits
Barnes & Kent Expires August 23, 2007 [Page 7]
Internet-Draft Secure Routing Architecture February 2007
two properties. First, The IP prefixes listed in the ROA are the
ones that the indicated AS is authorized to originate; in order for
this authorization (i.e., the ROA) to be valid, the prefixes
contained in a ROA must be exactly the same as the set of IP
addresses in the IP Address Delegation Extension of the end-entity
certificate used to sign the ROA. Second, the ROA is valid only as
long as the certificate used to sign it is valid; a ROA is
invalidated by revoking the end-entity certificate corresponding to
the public key used to verify it, and the validity interval of the
ROA is implicitly that of the validity interval of the corresponding
certificate.
Address holders that have allocations from multiple sources must
issue multiple ROAs. If an address holder has allocations from
multiple sources, then these allocations will be described by
multiple CA certificates in the PKI, each issued by the provider of
the respective allocation; the sets of IP addresses contained in end-
entity certificates issued by this address holder are required to be
subsets of these allocations. Because end-entity certificates are in
one-to-one correspondence with ROAs, this means that the set of IP
addresses contained in a ROA must be drawn from an allocation by a
single source; hence ROAs cannot combine allocations from multiple
sources.
3.3. Revocation
If an address holder decides that an AS should no longer originate
routes for addresses that it holds (e.g., if the address holder
transfers from one ISP to another), then it will be necessary to
invalidate the ROAs that attest to any such authorization. Since
ROAs are in one-to-one correspondence with end-entity certificates,
the standard method for revoking a ROA is to revoke the corresponding
end-entity certificate in the PKI. There is no independent
revocation mechanism for ROAs.
4. Repository system
In order for ROAs (and other objects to be verified using
certificates from the PKI) to be validated, the objects necessary to
validate them must be universally accessible. The primary function
of the distributed repository system described here is to store these
objects and to make them available for download. The repository
system is also a point of enforcement for access controls for the
signed objects stored in it, e.g., ensuring that records related to
an allocation of resources can be manipulated only by authorized
parties. This requirement exists to prevent denial of service attacks
based on deletion of or tampering with repository objects. Although
Barnes & Kent Expires August 23, 2007 [Page 8]
Internet-Draft Secure Routing Architecture February 2007
any unauthorized modification is detectable by relying parties,
because all the objects are digitally signed, it is preferable that
the repository system prevent unauthorized modifications.
4.1. Role in the overall architecture
The repository system is the central clearing-house for the objects
required for validation of signed objects like ROAs. When
certificates and CRLs are created, they are uploaded to this
repository, and then downloaded for use by relying parties. In
addition, signed objects that require universal distribution can also
be made accessible through the repository system; ROAs are the only
such objects defined by this document, but other types of signed
objects may be added to this architecture in the future. The
repository system also must ensure the integrity of the data it
contains by enforcing appropriate controls on access to the
repository and on modifications to entries in it. This document
describes the controls necessary for PKI objects and ROAs, but does
not assume that they are applicable to other types of objects; if
other types of objects are to be included in the repository system in
the future, any necessary controls on them must be defined.
4.2. Contents and structure
The primary function of the repository system is to provide universal
distribution of objects necessary for the function of this
architecture. First among these are the objects that comprise the
PKI, namely Resource Certificates and their corresponding CRLs; these
objects require universal distribution so that all relying parties
have access to the PKI components required to validate signed objects
used by this architecture. In addition, it may be necessary to make
other types of signed objects available through the repository
system. ROAs are a prime example of such a type, since routes whose
origination is authorized by a ROA are distributed through the entire
routing infrastructure, any component of which may, by local policy,
examine the route origin for consistency with the ROA.
Although there is a single repository system that is accessed by
relying parties, it is comprised of multiple databases. These
databases will be distributed among RIRs and ISPs that participate in
the architecture. At a minimum, the database operated by each RIR
will contain certificates and CRLs issued by that RIR; it may also
contain repository objects submitted by holders of addresses that
fall within that RIR's scope or copies of data from other RIRs,
according to local policy.
Barnes & Kent Expires August 23, 2007 [Page 9]
Internet-Draft Secure Routing Architecture February 2007
4.3. Access protocols
Repository operators will choose one or more access protocols that
relying parties can use to access the repository system. These
protocols will be used by numerous participants in the infrastructure
(e.g., all registries, ISPs, and multi-homed subscribers) to maintain
their respective portions of it. In order to support these
activities, certain basic functionality is required of the suite of
access protocols, as described below. No single access protocol need
implement all of these functions (although this may be the case), but
each function must be implemented by at least one access protocol.
Download: Access protocols MUST support the bulk download of
repository contents and subsequent download of changes to the
downloaded contents, since this will be the most common way in which
relying parties interact with the repository system. Other types of
download interactions (e.g., download of a single object) MAY also be
supported.
Upload/change/delete: Access protocols MUST also support mechanisms
for the issuers of certificates, CRLs, and other signed objects to
add them to the repository, and to remove them. Mechanisms for
modifying objects in the repository MAY also be provided. All access
protocols that allow modification to the repository (through
addition, deletion, or modification of its contents) MUST support
verification of the authorization of the entity performing the
modification, so that appropriate access controls can be applied (see
Section 4.4).
Current efforts to implement a repository system use RSYNC [9] as the
single access protocol. RSYNC, as used in this implementation,
provides all of the above functionality.
4.4. Access control
In order to maintain the integrity of information in the repository,
controls must be put in place to prevent addition, deletion, or
modification of objects in the repository by unauthorized parties.
The identities of parties attempting to make such changes can be
authenticated through the relevant access protocols. Although
specific access control policies are subject to the local control of
repository operators, it is recommended that repositories allow only
the issuers of signed objects to add, delete, or modify them.
Alternatively, it may be advantageous in the future to define a
formal delegation mechanism to allow resource holders to authorize
other parties to act on their behalf, as is suggested in Section 2.3
above.
Barnes & Kent Expires August 23, 2007 [Page 10]
Internet-Draft Secure Routing Architecture February 2007
5. Common Operations
Creating and maintaining the infrastructure described above will
entail the addition of security operations to normal resource
allocation and routing authorization procedures. For example, a
multi-homed subscriber entering a relationship with a new ISP will
need to issue one or more ROAs to that ISP, in addition to conducting
any other necessary technical or business procedures. The current
primary use of this infrastructure is for route filter construction;
using ROAs, route filters can be constructed in an automated fashion
with high assurance that the holder of the advertised prefix has
authorized the first- hop AS to originate an advertised route.
5.1. Certificate issuance
In order to participate in this infrastructure, resource holders will
require certificates in the PKI that attest to their allocations.
Each such certificate will show the issuer of the allocation as the
certificate issuer, the recipient of the allocation as subject, and a
description of the allocated resources in the appropriate RFC 3779
extensions. The two operations defined in this architecture that
require a resource holder to have resource certificates for his
allocations are (1) issuance of certificates for sub-allocations and
(2) management of ROAs (and corresponding end-entity certificates).
In particular, there are several operational scenarios that require
certificates to be issued. Any allocation that may be sub-allocated
requires a CA certificate so that certificates can be issued as
necessary for sub-allocations. Multi-homed subscribers require
certificates for their allocations so that they can issue ROAs to
their ISPs. Holders of "portable" address allocations must have
certificates, so that a ROA can be issued to each ISP that is
authorized to originate a route to the allocation, since the
allocation does not come from any ISP.
As a resource holder receives multiple allocations over time, it will
accrue a collection of resource certificates to attest to them. It
may be the case that multiple of a resource holder's allocations are
from the same source. A set of resource certificates that are all
issued by the same CA could be combined into a single resource
certificate by consolidating their IP Address Delegation and AS
Identifier Delegation Extensions into a single extension of each
type. However, if the certificates for these allocations contain
different validity intervals, creating a certificate that combines
them might create problems, and thus is NOT RECOMMENDED. If a
resource holder's allocations come from different sources, they will
be signed by different CAs, and cannot be combined. When a set of
Barnes & Kent Expires August 23, 2007 [Page 11]
Internet-Draft Secure Routing Architecture February 2007
resources is no longer allocated to a resource holder, any
certificates attesting to such an allocation must be revoked. A
resource holder MAY choose to use the same public key in multiple CA
certificates that issued by the same or differing authorities,
although such reuse of a key pair does complicate path construction.
5.2. ROA management
Whenever a holder of IP address space wants to authorize an AS to
originate routes for a prefix within his holdings, he must issue an
end-entity certificate containing that prefix and use the
corresponding private key to sign a ROA containing the designated
prefix and an AS number identifying the designated AS. As a
prerequisite, then, any address holder that issues ROAs for a prefix
must have a resource certificate for an allocation containing that
prefix. The standard procedure for issuing a ROA is as follows:
1. Create an end-entity certificate containing the prefixes to be
authorized in the ROA
2. Construct the payload of the ROA, including the prefixes in the
end-entity certificate and the AS number to be authorized
3. Sign the ROA using the private key corresponding to the end-entity
certificate (the ROA is comprised of the payload encapsulated in a
CMS signed message [ROA format I-D])
4. Upload the end-entity certificate and the ROA to the repository
system
The standard procedure for revoking a ROA is to revoke the
corresponding end-entity certificate by creating an appropriate CRL
and uploading it to the repository system. The revoked ROA and end-
entity certificate SHOULD BE removed from the repository system.
5.2.1. Single-homed subscribers (without portable allocations)
In BGP, a single-homed subscriber with a non-portable allocation does
not need to explicitly authorize routes to be originated for the
prefix (or prefixes) it is using, since its ISP will already
advertise a more general prefix and route traffic for the
subscriber's prefix as an internal function. Since no routes are
originated specifically for prefixes held by these subscribers, no
ROAs need to be issued under their allocations; rather, the
subscriber's ISP will issue any necessary ROAs for its more general
prefixes under resource certificates its own allocation. Thus,
Barnes & Kent Expires August 23, 2007 [Page 12]
Internet-Draft Secure Routing Architecture February 2007
single-homed subscribers with non-portable allocations do not need to
issue (or otherwise manage) ROAs.
5.2.2. Multi-homing
If a multi-homed subscriber wants multiple ASes to originate routes
for prefixes that it holds, then it must explicitly authorize each of
them to do so by issuing a ROA for each AS in question.
5.2.3. Portable allocations
A resource holder is said to have a portable allocation if the
resource holder received its allocation from a registry. Because
these allocations are not taken from any larger allocations held by
an ISP, there is no ISP that holds and advertises a more general
prefix. If the holder of a portable allocation wants to authorize an
ISP to originate routes to its allocation, then it must issue a ROA
to this ISP; none of the ISP's existing ROAs authorize it to
originate routes to that portable allocation.
5.3. Route filter construction
The goal of this architecture is to support improved routing
security. One way to do this is to use ROAs to construct route
filters that reject routes that conflict with the origination
authorizations asserted by current ROAs, which can be accomplished
with the following procedure:
1. Obtain current certificates, CRLs, and ROAs from the repository
system (e.g., update a previous download)
2. Verify each end-entity certificate by constructing and verifying
a certification path for the certificate (including checking
relevant CRLs).
3. Verify each ROA by verifying that it is signed by a valid end-
entity certificate that matches the address allocation in the ROA.
4. Based on validated ROAs, construct a table of prefixes and
corresponding authorized origin ASes (or vice versa).
In addition to this basic route-filtering technique, the
infrastructure can be used to support more advanced routing-security
systems, such as S-BGP [7] and soBGP [8].
Barnes & Kent Expires August 23, 2007 [Page 13]
Internet-Draft Secure Routing Architecture February 2007
The first three steps in the above procedure would incur a
prohibitive amount of overhead if all objects in the repository
system were downloaded and validated every time a route filter was
constructed. Instead, it will be more efficient for users of the
infrastructure to initially download all of the objects
(certificates, CRLs, and ROAs), perform necessary validations, then
perform incremental downloads and validations on a regular basis. A
typical ISP using the infrastructure might have a daily schedule to
download updates from the repository, upload any modifications it has
made, and construct route filters.
6. Security Considerations
The focus of this document is security; hence security considerations
permeate this specification.
The security mechanisms provided by and enabled by this architecture
depend on the integrity and availability of the infrastructure it
describes. The integrity of objects within the infrastructure is
ensured by appropriate controls on the repository system, as
described in Section 4.4. Likewise, because the repository system is
structured as a distributed database, it should be inherently
resistant to denial of service attacks; nonetheless, appropriate
precautions should also be taken, both through replication and backup
of the constituent databases and through the physical security of
database servers
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Barnes & Kent Expires August 23, 2007 [Page 14]
Internet-Draft Secure Routing Architecture February 2007
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006
[3] Housley, R., et al., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[4] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[5] Huston, G., Michaelson, G., and Loomans, R., "A Profile for
X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-
03, February 2007.
[6] Kong, D., and Kent, S., " A Profile for Route Origin
Authorizations (ROA)", draft-ietf-sidr-roa-format-00, February
2007.
9.2. Informative References
[7] [S-BGP]
[8] [soBGP]
[9] [rsync]
Author's Addresses
Richard Barnes
BBN Technologies
Email: rbarnes@bbn.com
Stephen Kent
BBN Technologies
Email: kent@bbn.com
Barnes & Kent Expires August 23, 2007 [Page 15]
Internet-Draft Secure Routing Architecture February 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Barnes & Kent Expires August 23, 2007 [Page 16]
