idnits 2.17.1 draft-ietf-sidr-arch-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5296 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '10' is defined on line 981, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (ref. '4') (Obsoleted by RFC 5652) == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-17 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-06 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-05 == Outdated reference: A later version (-07) exists of draft-ietf-sidr-ta-02 == Outdated reference: A later version (-05) exists of draft-ietf-sidr-rpki-algs-00 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-03 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-roa-validation-03 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Inter-Domain Routing M. Lepinski 2 Working Group S. Kent 3 Internet Draft BBN Technologies 4 Intended status: Informational October 26, 2009 5 Expires: April 26, 2010 7 An Infrastructure to Support Secure Internet Routing 8 draft-ietf-sidr-arch-09.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 26, 20010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes an architecture for an infrastructure to 47 support improved security of Internet routing. The foundation of this 48 architecture is a public key infrastructure (PKI) that represents the 49 allocation hierarchy of IP address space and Autonomous System 50 Numbers; and a distributed repository system for storing and 51 disseminating the data objects that comprise the PKI, as well as 52 other signed objects necessary for improved routing security. As an 53 initial application of this architecture, the document describes how 54 a legitimate holder of IP address space can explicitly and verifiably 55 authorize one or more ASes to originate routes to that address space. 56 Such verifiable authorizations could be used, for example, to more 57 securely construct BGP route filters. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Terminology...............................................4 63 2. PKI for Internet Number Resources..............................5 64 2.1. Role in the overall architecture..........................5 65 2.2. CA Certificates...........................................6 66 2.3. End-Entity (EE) Certificates..............................7 67 2.4. Trust Anchors.............................................8 68 3. Route Origination Authorizations...............................9 69 3.1. Role in the overall architecture..........................9 70 3.2. Syntax and semantics.....................................10 71 4. Repositories..................................................11 72 4.1. Role in the overall architecture.........................12 73 4.2. Contents and structure...................................12 74 4.3. Access protocols.........................................14 75 4.4. Access control...........................................14 76 5. Manifests.....................................................15 77 5.1. Syntax and semantics.....................................15 78 6. Local Cache Maintenance.......................................16 79 7. Common Operations.............................................17 80 7.1. Certificate issuance.....................................17 81 7.2. ROA management...........................................18 82 7.2.1. Single-homed subscribers (with PA address space)....19 83 7.2.2. Multi-homed subscribers (with PA address space).....19 84 7.2.3. Provider-Independent Address Space..................20 85 8. Security Considerations.......................................20 86 9. IANA Considerations...........................................21 87 10. Acknowledgments..............................................21 88 11. References...................................................22 89 11.1. Normative References....................................22 90 11.2. Informative References..................................22 91 Authors' Addresses...............................................23 92 Pre-5378 Material Disclaimer.....................................23 94 1. Introduction 96 This document describes an architecture for an infrastructure to 97 support improved security for BGP routing [2] for the Internet. The 98 architecture encompasses three principle elements: 100 . a public key infrastructure (PKI) 102 . digitally-signed routing objects to support routing security 104 . a distributed repository system to hold the PKI objects and the 105 signed routing objects 107 The architecture described by this document enables an entity to 108 verifiably assert that it is the legitimate holder of a set of IP 109 addresses or a set of Autonomous System (AS) numbers. As an initial 110 application of this architecture, the document describes how a 111 legitimate holder of IP address space can explicitly and verifiably 112 authorize one or more ASes to originate routes to that address space. 113 Such verifiable authorizations could be used, for example, to more 114 securely construct BGP route filters. In addition to this initial 115 application, the infrastructure defined by this architecture also is 116 intended to provide future support for security protocols such as S- 117 BGP [12] or soBGP [13]. This architecture is applicable to the 118 routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently 119 the only address families supported by this architecture. Thus, for 120 example, use of this architecture with MPLS labels is beyond the 121 scope of this document. 123 In order to facilitate deployment, the architecture takes advantage 124 of existing technologies and practices. The structure of the PKI 125 element of the architecture corresponds to the existing resource 126 allocation structure. Thus management of this PKI is a natural 127 extension of the resource-management functions of the organizations 128 that are already responsible for IP address and AS number resource 129 allocation. Likewise, existing resource allocation and revocation 130 practices have well-defined correspondents in this architecture. Note 131 that while the initial focus of this architecture is routing security 132 applications, the PKI described in this document could be used to 133 support other applications that make use of attestations of IP 134 address or AS number resource holdings. 136 To ease implementation, existing IETF standards are used wherever 137 possible; for example, extensive use is made of the X.509 certificate 138 profile defined by PKIX [3] and the extensions for IP Addresses and 139 AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is 140 used as the syntax for the newly-defined signed objects required by 141 this infrastructure. 143 As noted above, the architecture is comprised of three main 144 components: an X.509 PKI in which certificates attest to holdings of 145 IP address space and AS numbers; non-certificate/CRL signed objects 146 (including route origination authorizations and manifests) used by 147 the infrastructure; and a distributed repository system that makes 148 all of these signed objects available for use by ISPs in making 149 routing decisions. These three basic components enable several 150 security functions; this document describes how they can be used to 151 improve route filter generation, and to perform several other common 152 operations in such a way as to make them cryptographically 153 verifiable. 155 1.1. Terminology 157 It is assumed that the reader is familiar with the terms and concepts 158 described in "Internet X.509 Public Key Infrastructure Certificate 159 and Certificate Revocation List (CRL) Profile" [3], and "X.509 160 Extensions for IP Addresses and AS Identifiers" [5]. 162 Throughout this document we use the terms "address space holder" or 163 "holder of IP address space" interchangeably to refer to a legitimate 164 holder of IP address space who has received this address space 165 through the standard IP address allocation hierarchy. That is, the 166 address space holder has either directly received the address space 167 as an allocation from a Regional Internet Registry (RIR) or IANA; or 168 else the address space holder has received the address space as a 169 sub-allocation from a National Internet Registry (NIR) or Local 170 Internet Registry (LIR). We use the term "resource holder" to refer 171 to a legitimate holder of either IP address or AS number resources. 173 Throughout this document we use the terms "registry" and ISP to refer 174 to an entity that has an IP address space and/or AS number allocation 175 that it is permitted to sub-allocate its resources. We use the term 176 "subscriber" to refer to an entity (e.g., an enterprise) that 177 receives an IP address space and/or AS number assignment, and does 178 not sub-allocate its resources. 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC-2119 [1]. 184 2. PKI for Internet Number Resources 186 Because the holder of a block IP address space is entitled to define 187 the topological destination of IP datagrams whose destinations fall 188 within that block, decisions about inter-domain routing are 189 inherently based on knowledge of the allocation of the IP address 190 space. Thus, a basic function of this architecture is to provide 191 cryptographically verifiable attestations as to these allocations. In 192 current practice, the allocation of IP addresses is hierarchic. The 193 root of the hierarchy is IANA. Below IANA are five Regional Internet 194 Registries (RIRs), each of which manages address and AS number 195 allocation within a defined geopolitical region. In some regions the 196 third tier of the hierarchy includes National Internet Registries 197 (NIRs) as well as Local Internet Registries (LIRs) and subscribers 198 with so-called provider-independent ("portable") allocations. (The 199 term LIR is used in some regions to refer to what other regions 200 define as an ISP. Throughout the rest of this document we will use 201 the term LIR/ISP to simplify references to these entities.) In other 202 regions the third tier consists only of LIRs/ISPs and subscribers 203 with provider-independent allocations. 205 In general, the holder of a block of IP address space may sub- 206 allocate portions of that block, either to itself (e.g., to a 207 particular unit of the same organization), or to another 208 organization, subject to contractual constraints established by the 209 registries. Because of this structure, IP address allocations can be 210 described naturally by a hierarchic public-key infrastructure, in 211 which each certificate attests to an allocation of IP addresses, and 212 issuance of subordinate certificates corresponds to sub-allocation of 213 IP addresses. The above reasoning holds true for AS number resources 214 as well, with the difference that, by convention, AS numbers may not 215 be sub-allocated except by RIRs or NIRs. Thus allocations of both IP 216 addresses and AS numbers can be expressed by the same PKI. Such a 217 PKI is a central component of this architecture. 219 2.1. Role in the overall architecture 221 Certificates in this PKI are called Resource Certificates, and 222 conform to the certificate profile for such certificates [6]. 223 Resource certificates attest to the allocation by the (certificate) 224 issuer of IP addresses or AS numbers to the subject. They do this by 225 binding the public key contained in the Resource Certificate to the 226 IP addresses or AS numbers included in the certificate's IP Address 227 Delegation or AS Identifier Delegation Extensions, respectively, as 228 defined in RFC 3779 [5]. 230 An important property of this PKI is that certificates do not attest 231 to the identity of the subject. Therefore, the subject names used in 232 certificates are not intended to be "descriptive." That is, the 233 resource PKI is intended to provide authorization, but not 234 authentication. This is in contrast to most PKIs where the issuer 235 ensures that the descriptive subject name in a certificate is 236 properly associated with the entity that holds the private key 237 corresponding to the public key in the certificate. Because issuers 238 need not verify the right of an entity to use a subject name in a 239 certificate, they avoid the costs and liabilities of such 240 verification. This makes it easier for these entities to take on the 241 additional role of Certificate Authority (CA). 243 Most of the certificates in the PKI assert the basic facts on which 244 the rest of the infrastructure operates. CA certificates within the 245 PKI attest to IP address space and AS number holdings. End-entity 246 (EE) certificates are issued by resource holder CAs to delegate the 247 authority attested by their allocation certificates. The primary use 248 for EE certificates is the validation of Route Origination 249 Authorizations (ROAs). Additionally, signed objects called manifests 250 will be used to help ensure the integrity of the repository system, 251 and the signature on each manifest will be verified via an EE 252 certificate. 254 2.2. CA Certificates 256 Any resource holder who is authorized to sub-allocate these resources 257 must be able to issue Resource Certificates to correspond to these 258 sub-allocations. Thus, for example, CA certificates will be 259 associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. A CA 260 certificate also is required to enable a resource holder to issue 261 ROAs, because it must issue the corresponding end-entity certificate 262 used to validate each ROA. Thus some entities that do not sub- 263 allocate their resources also will need to have CA certificates for 264 their allocations, e.g., a multi-homed subscriber with a provider- 265 independent allocation, to enable them to issue ROAs. (A subscriber 266 who is not multi-homed, whose allocation comes from an LIR/ISP, and 267 who has not moved to a different LIR/ISP, need not be represented in 268 the PKI. Moreover, a multi-homed subscriber with an allocation from 269 an LIR/ISP may or may not need to be explicitly represented, as 270 discussed in Section 7.2.2) 272 Unlike in most PKIs, the distinguished name of the subject in a CA 273 certificate is chosen by the certificate issuer. The subject's 274 distinguished name must not attempt to convey the identity of the 275 subject in a descriptive fashion. The subject's distinguished name 276 must include the common name attribute and may additionally include 277 the serial attribute. 279 In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, 280 is not in the business of verifying the legal right of the subject to 281 assert a particular identity. Therefore, selecting a distinguished 282 name that does not convey the identity of the subject in a 283 descriptive fashion minimizes the opportunity for the subject to 284 misuse the certificate to assert an identity, and thus minimizes the 285 legal liability of the issuer. Since all CA certificates are issued 286 to subjects with whom the issuer has an existing relationship, it is 287 recommended that the issuer select a subject name that enables the 288 issuer to easily link the certificate to existing database records 289 associated with the subject. For example, an authority may use 290 internal database keys or subscriber IDs as the subject common name 291 in issued certificates. 293 Although the subject's common name in a certificate does not convey 294 identity, it is still the case that the common name must be unique 295 among all subjects to whom a certification authority issues 296 certificates. That is, a CA must not issue certificates to two 297 different entities which use the same common name for the subject. 299 Each Resource Certificate attests to an allocation of resources to a 300 resource holder, so entities that have allocations from multiple 301 sources will have multiple CA certificates. Note that when an entity 302 receives multiple certificates from different issuers that the 303 subject names in these certificates will generally be different. A CA 304 also may issue distinct certificates for each distinct allocation to 305 the same entity, if the CA and the resource holder agree that such an 306 arrangement will facilitate management and use of the certificates. 307 For example, an LIR/ISP may have several certificates issued to it by 308 one registry, each describing a distinct set of address blocks, 309 because the LIR/ISP desires to treat the allocations as separate. 311 2.3. End-Entity (EE) Certificates 313 The private key corresponding to public key contained in an EE 314 certificate is not used to sign other certificates in a PKI. The 315 primary function of end-entity certificates in this PKI is the 316 verification of signed objects that relate to the usage of the 317 resources described in the certificate, e.g., ROAs and manifests. 318 For ROAs and manifests there will be a one-to-one correspondence 319 between end-entity certificates and signed objects, i.e., the private 320 key corresponding to each end-entity certificate is used to sign 321 exactly one object, and each object is signed with only one key. 322 This property allows the PKI to be used to revoke these signed 323 objects, rather than creating a new revocation mechanism. When the 324 end-entity certificate used to sign an object has been revoked, the 325 signature on that object (and any corresponding assertions) will be 326 considered invalid, so a signed object can be effectively revoked by 327 revoking the end-entity certificate used to sign it. 329 A secondary advantage to this one-to-one correspondence is that the 330 private key corresponding to the public key in a certificate is used 331 exactly once in its lifetime, and thus can be destroyed after it has 332 been used to sign its one object. This fact should simplify key 333 management, since there is no requirement to protect these private 334 keys for an extended period of time. 336 Although this document describes only two uses for end-entity 337 certificates, additional uses will likely be defined in the future. 338 For example, end-entity certificates could be used as a more general 339 authorization for their subjects to act on behalf of the specified 340 resource holder. This could facilitate authentication of inter-ISP 341 interactions, or authentication of interactions with the repository 342 system. These additional uses for end-entity certificates may 343 require retention of the corresponding private keys, even though this 344 is not required for the private keys associated with end-entity 345 certificates keys used for verification of ROAs and manifests, as 346 described above. 348 2.4. Trust Anchors 350 In any PKI, each relying party (RP) chooses its own set of trust 351 anchors. This general property of PKIs applies here as well. There is 352 an extant IP address space and AS number allocation hierarchy, and 353 thus IANA and/or the five RIRs are obvious candidates to be default 354 TAs here. Nonetheless, each RP ultimately chooses the set of trust 355 anchors it will use for certificate validation. 357 For example, a RP (e.g., an LIR/ISP) could create a trust anchor to 358 which all address space and/or all AS numbers are assigned, and for 359 which the RP knows the corresponding private key. The RP could then 360 issue certificates under this trust anchor to whatever entities in 361 the PKI it wishes, with the result that the certification paths 362 terminating at this locally-installed trust anchor will satisfy the 363 RFC 3779 validation requirements. A large ISP that uses private 364 (i.e., RFC 1918) IP address space and runs BGP internally will need 365 to create this sort of trust anchor to accommodate a CA to which all 366 private (RFC 1918) address space is assigned. The RP could then issue 367 certificates under this CA that correspond to the RP's internal use 368 of private address space. 370 Note that a RP who elects to create and manage its own set of trust 371 anchors may fail to detect allocation errors that arise under such 372 circumstances, but the resulting vulnerability is local to the RP. 374 It is expected that some parties within the extant IP address space 375 and AS number allocation hierarchy may wish to publish trust anchor 376 material for possible use by relying parties. A standard profile for 377 the publication of trust anchor material for this public key 378 infrastructure can be found in [9]. 380 3. Route Origination Authorizations 382 The information on IP address allocation provided by the PKI is not, 383 in itself, sufficient to guide routing decisions. In particular, BGP 384 is based on the assumption that the AS that originates routes for a 385 particular prefix is authorized to do so by the holder of that prefix 386 (or an address block encompassing the prefix); the PKI contains no 387 information about these authorizations. A Route Origination 388 Authorization (ROA) makes such authorization explicit, allowing a 389 holder of IP address space to create an object that explicitly and 390 verifiably asserts that an AS is authorized originate routes to a 391 given set of prefixes. 393 3.1. Role in the overall architecture 395 A ROA is an attestation that the holder of a set of prefixes has 396 authorized an autonomous system to originate routes for those 397 prefixes. A ROA is structured according to the format described in 398 [7]. The validity of this authorization depends on the signer of the 399 ROA being the holder of the prefix(es) in the ROA; this fact is 400 asserted by an end-entity certificate from the PKI, whose 401 corresponding private key is used to sign the ROA. 403 ROAs may be used by relying parties to verify that the AS that 404 originates a route for a given IP address prefix is authorized by the 405 holder of that prefix to originate such a route. For example, an ISP 406 might use validated ROAs as inputs to route filter construction for 407 use by its BGP routers. (See [15] for information on the use of ROAs 408 to validate the origination of BGP routes.) 410 Initially, the repository system will be the primary mechanism for 411 disseminating ROAs, since these repositories will hold the 412 certificates and CRLs needed to verify ROAs. In addition, ROAs also 413 could be distributed in BGP UPDATE messages or via other 414 communication paths, if needed to meet timeliness requirements. 416 3.2. Syntax and semantics 418 A ROA constitutes an explicit authorization for a single AS to 419 originate routes to one or more prefixes, and is signed by the holder 420 of those prefixes. A detailed specification of the ROA syntax can be 421 found in [7] but, at a high level, a ROA consists of (1) an AS 422 number; (2) a list of IP address prefixes; and, optionally, (3) for 423 each prefix, the maximum length of more specific (longer) prefixes 424 that the AS is also authorized to advertise. (This last element 425 facilitates a compact authorization to advertise, for example, any 426 prefixes of length 20 to 24 contained within a given length 20 427 prefix.) 429 Note that a ROA contains only a single AS number. Thus, if an ISP has 430 multiple AS numbers that will be authorized to originate routes to 431 the prefix(es) in the ROA, an address space holder will need to issue 432 multiple ROAs to authorize the ISP to originate routes from any of 433 these ASes. 435 A ROA is signed using the private key corresponding to the public key 436 in an end-entity certificate in the PKI. In order for a ROA to be 437 valid, its corresponding end-entity (EE) certificate must be valid 438 and the IP address prefixes of the ROA must exactly match the IP 439 address prefix(es) specified in the EE certificate's RFC 3779 440 extension. Therefore, the validity interval of the ROA is implicitly 441 the validity interval of its corresponding certificate. A ROA is 442 revoked by revoking the corresponding EE certificate. There is no 443 independent method of invoking a ROA. One might worry that this 444 revocation model could lead to long CRLs for the CA certification 445 that is signing the EE certificates. However, routing announcements 446 on the public internet are generally quite long lived. Therefore, as 447 long as the EE certificates used to verify a ROA are given a validity 448 interval of several months, the likelihood that many ROAs would need 449 to revoked within that time is quite low. 451 --------- --------- 452 | RIR | | NIR | 453 | CA | | CA | 454 --------- --------- 455 | | 456 | | 457 | | 458 --------- --------- 459 | ISP | | ISP | 460 | CA 1 | | CA 2 | 461 --------- --------- 462 | \ | 463 | ----- | 464 | \ | 465 ---------- ---------- ---------- 466 | ISP | | ISP | | ISP | 467 | EE 1a | | EE 1b | | EE 2 | 468 ---------- ---------- ---------- 469 | | | 470 | | | 471 | | | 472 ---------- ---------- ---------- 473 | ROA 1a | | ROA 1b | | ROA 2 | 474 ---------- ---------- ---------- 476 FIGURE 2: This figure illustrates an ISP with allocations from two 477 sources (and RIR and an NIR). It needs two CA certificates due to RFC 478 3779 rules. 480 Because each ROA is associated with a single end-entity certificate, 481 the set of IP prefixes contained in a ROA must be drawn from an 482 allocation by a single source, i.e., a ROA cannot combine allocations 483 from multiple sources. Address space holders who have allocations 484 from multiple sources, and who wish to authorize an AS to originate 485 routes for these allocations, must issue multiple ROAs to the AS. 487 4. Repositories 489 Initially, an LIR/ISP will make use of the resource PKI by acquiring 490 and validating every ROA, to create a table of the prefixes for which 491 each AS is authorized to originate routes. To validate all ROAs, an 492 LIR/ISP needs to acquire all the certificates and CRLs. The primary 493 function of the distributed repository system described here is to 494 store these signed objects and to make them available for download by 495 LIRs/ISPs. Note that this repository system provides a mechanism by 496 which relying parties can pull fresh data at whatever frequency they 497 deem appropriate. However, it does not provide a mechanism for 498 pushing fresh data to relying parties (e.g. by including resource PKI 499 objects in BGP or other protocol messages) and such a mechanism is 500 beyond the scope of the current document. 502 The digital signatures on all objects in the repository ensure that 503 unauthorized modification of valid objects is detectable by relying 504 parties. Additionally, the repository system uses manifests (see 505 Section 5) to ensure that relying parties can detect the deletion of 506 valid objects and the insertion of out of date, valid signed objects. 508 The repository system is also a point of enforcement for access 509 controls for the signed objects stored in it, e.g., ensuring that 510 records related to an allocation of resources can be manipulated only 511 by authorized parties. The use of access controls prevents denial of 512 service attacks based on deletion of or tampering to repository 513 objects. Indeed, although relying parties can detect tampering with 514 objects in the repository, it is preferable that the repository 515 system prevent such unauthorized modifications to the greatest extent 516 possible. 518 4.1. Role in the overall architecture 520 The repository system is the central clearing-house for all signed 521 objects that must be globally accessible to relying parties. When 522 certificates and CRLs are created, they are uploaded to this 523 repository, and then downloaded for use by relying parties (primarily 524 LIRs/ISPs). ROAs and manifests are additional examples of such 525 objects, but other types of signed objects may be added to this 526 architecture in the future. This document briefly describes the way 527 signed objects (certificates, CRLs, ROAs and manifests) are managed 528 in the repository system. As other types of signed objects are added 529 to the repository system it will be necessary to modify the 530 description, but it is anticipated that most of the design principles 531 will still apply. The repository system is described in detail in 532 [11]. 534 4.2. Contents and structure 536 Although there is a single repository system that is accessed by 537 relying parties, it is comprised of multiple databases. These 538 databases will be distributed among registries (RIRs, NIRs, 539 LIRs/ISPs). At a minimum, the database operated by each registry will 540 contain all CA and EE certificates, CRLs, and manifests signed by the 541 CA(s) associated with that registry. Repositories operated by 542 LIRs/ISPs also will contain ROAs. Registries are encouraged to 543 maintain copies of repository data from their customers, and their 544 customer's customers (etc.), to facilitate retrieval of the whole 545 repository contents by relying parties. Ideally, each RIR will hold 546 PKI data from all entities within its geopolitical scope. 548 For every certificate in the PKI, there will be a corresponding file 549 system directory in the repository that is the authoritative 550 publication point for all objects (certificates, CRLs, ROAs and 551 manifests) verifiable via this certificate. A certificate's Subject 552 Information Authority (SIA) extension provides a URI that references 553 this directory. Additionally, a certificate's Authority Information 554 Authority (AIA) extension contains a URI that references the 555 authoritative location for the CA certificate under which the given 556 certificate was issued. That is, if certificate A is used to verify 557 certificate B, then the AIA extension of certificate B points to 558 certificate A, and the SIA extension of certificate A points to a 559 directory containing certificate B (see Figure 2). 561 +--------+ 562 +--------->| Cert A |<----+ 563 | | CRLDP | | +---------+ 564 | | AIA | | +-->| A's CRL |<-+ 565 | +--------- SIA | | | +---------+ | 566 | | +--------+ | | | 567 | | | | | 568 | | +---+----+ | 569 | | | | | 570 | | +---------------|---|-----------------+ | 571 | | | | | | | 572 | +->| +--------+ | | +--------+ | | 573 | | | Cert B | | | | Cert C | | | 574 | | | CRLDP ----+ | | CRLDP -+--------+ 575 +----------- AIA | +----- AIA | | 576 | | SIA | | SIA | | 577 | +--------+ +--------+ | 578 | | 579 +-------------------------------------+ 581 FIGURE 3: In this example, certificates B and C are issued under 582 certificate A. Therefore, the AIA extensions of certificates B and C 583 point to A, and the SIA extension of certificate A points to the 584 directory containing certificates B and C. 586 If a CA certificate is reissued with the same public key, it should 587 not be necessary to reissue (with an updated AIA URI) all 588 certificates signed by the certificate being reissued. Therefore, a 589 certification authority SHOULD use a persistent URI naming scheme for 590 issued certificates. That is, reissued certificates should use the 591 same publication point as previously issued certificates having the 592 same subject and public key, and should overwrite such certificates. 594 4.3. Access protocols 596 Repository operators will choose one or more access protocols that 597 relying parties can use to access the repository system. These 598 protocols will be used by numerous participants in the infrastructure 599 (e.g., all registries, ISPs, and multi-homed subscribers) to maintain 600 their respective portions of it. In order to support these 601 activities, certain basic functionality is required of the suite of 602 access protocols, as described below. No single access protocol need 603 implement all of these functions (although this may be the case), but 604 each function must be implemented by at least one access protocol. 606 Download: Access protocols MUST support the bulk download of 607 repository contents and subsequent download of changes to the 608 downloaded contents, since this will be the most common way in which 609 relying parties interact with the repository system. Other types of 610 download interactions (e.g., download of a single object) MAY also be 611 supported. 613 Upload/change/delete: Access protocols MUST also support mechanisms 614 for the issuers of certificates, CRLs, and other signed objects to 615 add them to the repository, and to remove them. Mechanisms for 616 modifying objects in the repository MAY also be provided. All access 617 protocols that allow modification to the repository (through 618 addition, deletion, or modification of its contents) MUST support 619 verification of the authorization of the entity performing the 620 modification, so that appropriate access controls can be applied (see 621 Section 4.4). 623 Current efforts to implement a repository system use RSYNC [14] as 624 the single access protocol. RSYNC, as used in this implementation, 625 provides all of the above functionality. A document specifying the 626 conventions for use of RSYNC in the PKI will be prepared. 628 4.4. Access control 630 In order to maintain the integrity of information in the repository, 631 controls must be put in place to prevent addition, deletion, or 632 modification of objects in the repository by unauthorized parties. 633 The identities of parties attempting to make such changes can be 634 authenticated through the relevant access protocols. Although 635 specific access control policies are subject to the local control of 636 repository operators, it is recommended that repositories allow only 637 the issuers of signed objects to add, delete, or modify them. 639 Alternatively, it may be advantageous in the future to define a 640 formal delegation mechanism to allow resource holders to authorize 641 other parties to act on their behalf, as suggested in Section 2.3 642 above. 644 5. Manifests 646 A manifest is a signed object listing of all of the signed objects 647 issued by an authority responsible for a publication in the 648 repository system. For each certificate, CRL, or ROA issued by the 649 authority, the manifest contains both the name of the file containing 650 the object, and a hash of the file content. 652 As with ROAs, a manifest is signed by a private key, for which the 653 corresponding public key appears in an end-entity certificate. This 654 EE certificate, in turn, is signed by the CA in question. The EE 655 certificate private key may be used to issue one for more manifests. 656 If the private key is used to sign only a single manifest, then the 657 manifest can be revoked by revoking the EE certificate. In such a 658 case, to avoid needless CRL growth, the EE certificate used to 659 validate a manifest SHOULD expire at the same time that the manifest 660 expires. If an EE certificate is used to issue multiple (sequential) 661 manifests for the CA in question, then there is no revocation 662 mechanism for these individual manifests. 664 Manifests may be used by relying parties when constructing a local 665 cache (see Section 6) to mitigate the risk of an attacker who deletes 666 files from a repository or replaces current signed objects with stale 667 versions of the same object. Such protection is needed because 668 although all objects in the repository system are signed, the 669 repository system itself is untrusted. 671 5.1. Syntax and semantics 673 A manifest constitutes a list of (the hashes of) all the files in a 674 repository point at a particular point in time. A detailed 675 specification of manifest syntax is provided in [8] but, at a high 676 level, a manifest consists of (1) a manifest number; (2) the time the 677 manifest was issued; (3) the time of the next planned update; and (4) 678 a list of filename and hash value pairs. 680 The manifest number is a sequence number that is incremented each 681 time a manifest is issued by the authority. An authority is required 682 to issue a new manifest any time it alters any of its items in the 683 repository, or when the specified time of the next update is reached. 684 A manifest is thus valid until the specified time of the next update 685 or until a manifest is issued with a greater manifest number, 686 whichever comes first. (Note that when an EE certificate is used to 687 sign only a single manifest, whenever the authority issues the new 688 manifest, the CA MUST also issue a new CRL which includes the EE 689 certificate corresponding to the old manifest. The revoked EE 690 certificate for the old manifest will be removed from the CRL when it 691 expires, thus this procedure ought not to result in significant CRLs 692 growth.) 694 6. Local Cache Maintenance 696 In order to utilize signed objects issued under this PKI, a relying 697 party must first obtain a local copy of the valid EE certificates for 698 the PKI. To do so, the relying party performs the following steps: 700 1. Query the registry system to obtain a copy of all certificates, 701 manifests and CRLs issued under the PKI. 703 2. For each CA certificate in the PKI, verify the signature on the 704 corresponding manifest. Additionally, verify that the current 705 time is earlier than the time indicated in the nextUpdate field 706 of the manifest. 708 3. For each manifest, verify that certificates and CRLs issued 709 under the corresponding CA certificate match the hash values 710 contained in the manifest. Additionally, verify that no 711 certificate or manifest listed on the manifest is missing from 712 the repository. If the hash values do not match, or if any 713 certificate or CRL is missing, notify the appropriate repository 714 administrator that the repository data has been corrupted. 716 4. Validate each EE certificate by constructing and verifying a 717 certification path for the certificate (including checking 718 relevant CRLs) to the locally configured set of TAs. (See [6] 719 for more details.) 721 Note that since relying parties will perform these operations 722 regularly, it is more efficient for the relying party to request from 723 the repository system only those objects that have changed since the 724 relying party last updated its local cache. A relying party may 725 choose any frequency it desires for downloading and validating 726 updates from the repository. However, any relying party that uses 727 RPKI data as an input to operational routing decisions (e.g., ISPs, 728 RIRs, NIRs) SHOULD download and validate updates at least once every 729 three hours. 731 Note also that by checking all issued objects against the appropriate 732 manifest, the relying party can be certain that it is not missing an 733 updated version of any object. 735 7. Common Operations 737 Creating and maintaining the infrastructure described above will 738 entail additional operations as "side effects" of normal resource 739 allocation and routing authorization procedures. For example, a 740 subscriber with provider-independent ("portable") address space who 741 enters a relationship with an ISP will need to issue one or more ROAs 742 identifying that ISP, in addition to conducting any other necessary 743 technical or business procedures. The current primary use of this 744 infrastructure is for route filter construction; using ROAs, route 745 filters can be constructed in an automated fashion with high 746 assurance that the holder of the advertised prefix has authorized the 747 origin AS to originate an advertised route. 749 7.1. Certificate issuance 751 There are several operational scenarios that require certificates to 752 be issued. Any allocation that may be sub-allocated requires a CA 753 certificate, e.g., so that certificates can be issued as necessary 754 for the sub-allocations. Holders of provider-independent IP address 755 space allocations also must have certificates, so that a ROA can be 756 issued to each ISP that is authorized to originate a route to the 757 allocation (since the allocation does not come from any ISP). 758 Additionally, multi-homed subscribers may require certificates for 759 their allocations if they intend to issue the ROAs for their 760 allocations (see Section 7.2.2). Other resource holders need not be 761 issued CA certificates within the PKI. 763 In the long run, a resource holder will not request resource 764 certificates, but rather receive a certificate as a side effect of 765 the allocation process for the resource. However, initial deployment 766 of the RPKI will entail issuance of certificates to existing resource 767 holders as an explicit event. Note that in all cases, the authority 768 issuing a CA certificate will be the entity who allocates resources 769 to the subject. This differs from most PKIs in which a subject can 770 request a certificate from any certification authority. 772 If a resource holder receives multiple allocations over time, it may 773 accrue a collection of resource certificates to attest to them. If a 774 resource holder receives multiple allocations from the same source, 775 the set of resource certificates may be combined into a single 776 resource certificate, if both the issuer and the resource holder 777 agree. This is accomplished by consolidating the IP Address 778 Delegation and AS Identifier Delegation Extensions into a single 779 extension (of each type) in a new certificate. However, if the 780 certificates for these allocations contain different validity 781 intervals, creating a certificate that combines them might create 782 problems, and thus is NOT RECOMMENDED. 784 If a resource holder's allocations come from different sources, they 785 will be signed by different CAs, and cannot be combined. When a set 786 of resources is no longer allocated to a resource holder, any 787 certificates attesting to such an allocation MUST be revoked. A 788 resource holder SHOULD NOT use the same public key in multiple CA 789 certificates that are issued by the same or differing authorities, as 790 reuse of a key pair complicates path construction. Note that since 791 the subject's distinguished name is chosen by the issuer, a subject 792 who receives allocations from two sources generally will receive 793 certificates with different subject names. 795 7.2. ROA management 797 Whenever a holder of IP address space wants to authorize an AS to 798 originate routes for a prefix within his holdings, he MUST issue an 799 end-entity certificate containing that prefix in an IP Address 800 Delegation extension. He then uses the corresponding private key to 801 sign a ROA containing the designated prefix and the AS number for the 802 AS. The resource holder MAY include more than one prefix in the EE 803 certificate and corresponding ROA if desired. As a prerequisite, 804 then, any address space holder that issues ROAs for a prefix must 805 have a resource certificate for an allocation containing that prefix. 806 The standard procedure for issuing a ROA is as follows: 808 1. Create an end-entity certificate containing the prefix(es) to be 809 authorized in the ROA. 811 2. Construct the payload of the ROA, including the prefixes in the 812 end-entity certificate and the AS number to be authorized. 814 3. Sign the ROA using the private key corresponding to the end- 815 entity certificate (the ROA is comprised of the payload 816 encapsulated in a CMS signed message [7]). 818 4. Upload the end-entity certificate and the ROA to the repository 819 system. 821 The standard procedure for revoking a ROA is to revoke the 822 corresponding end-entity certificate by creating an appropriate CRL 823 and uploading it to the repository system. The revoked ROA and end- 824 entity certificate SHOULD BE removed from the repository system. 826 Care must be taken when revoking ROAs in that revoking a ROA may 827 cause a relying party to treat routing advertisements corresponding 828 to the prefixes and origin AS number in the ROA as unauthorized (and 829 potentially even change routing behavior to no longer forward packets 830 based on those advertisements). In particular, resource holders 831 should adhere to the principle of "make before break" as follows. 832 Before revoking a ROA corresponding to a prefix which the resource 833 holder wishes to be routable on the Internet, it is very important 834 for the resource holder to ensure that there exists another valid 835 alternative ROA that lists the same prefix (possibly indicating a 836 different AS number). Additionally, the resource holder should ensure 837 that the AS indicated in the valid alternative ROA is actually 838 originating routing advertisements to the prefixes in question. 839 Furthermore, a relying party must fetch new ROAs from the repository 840 system before taking any routing action in response to a ROA 841 revocation. 843 7.2.1. Single-homed subscribers (with PA address space) 845 In BGP, a single-homed subscriber with provider aggregatable (non- 846 portable) address space does not need to explicitly authorize routes 847 to be originated for the prefix(es) it is using, since its ISP will 848 already advertise a more general prefix and route traffic for the 849 subscriber's prefix as an internal function. Since no routes are 850 originated specifically for prefixes held by these subscribers, no 851 ROAs need to be issued under their allocations; rather, the 852 subscriber's ISP will issue any necessary ROAs for its more general 853 prefixes under resource certificates from its own allocation. Thus, a 854 single-homed subscriber with an IP address allocation from his 855 service provider is not included in the RPKI, i.e., it does not 856 receive a CA certificate, nor issue EE certificates or ROAs. 858 7.2.2. Multi-homed subscribers (with PA address space) 860 Here we consider a subscriber who receives provider aggregatable IP 861 address space from a primary ISP (i.e., the IP addresses used by the 862 subscriber are a subset of ISP A's IP address space allocation) and 863 receives redundant upstream connectivity from one or more secondary 864 ISPs, in addition to the primary ISP. The preferred option for such a 865 multi-homed subscriber is for the subscriber to obtain an AS number 866 (from an RIR or NIR) and run BGP with each of its upstream providers. 867 In such a case, there are two ways for ROA management to be handled. 868 The first is that the primary ISP issues a CA certificate to the 869 subscriber, and the subscriber issues a ROA to containing the 870 subscriber's AS number and the subscriber's IP address prefixes. The 871 second possibility is that the primary ISP does not issue a CA 872 certificate to the subscriber, and instead issues a ROA on the 873 subscriber's behalf that contains the subscriber's AS number and the 874 subscriber's IP address prefixes. 876 If the subscriber is unable or unwilling to obtain an AS number and 877 run BGP, the other option is that the multi-homed subscriber can 878 request that the primary ISP create a ROA for each secondary ISP that 879 authorizes the secondary ISP to originate routes to the subscriber's 880 prefixes. The primary ISP will also create a ROA containing its own 881 AS number and the subscriber's prefixes, as it is likely in such a 882 case that the primary ISP wishes to advertise precisely the 883 subscriber's prefixes and not an encompassing aggregate. Note that 884 this approach results in inconsistent origin AS numbers for the 885 subscriber's prefixes which are considered undesirable on the public 886 Internet; thus this approach is NOT RECOMMENDED. 888 7.2.3. Provider-Independent Address Space 890 A resource holder is said to have provider-independent (portable) 891 address space if the resource holder received its allocation directly 892 from a RIR or NIR. Because the prefixes represented in such 893 allocations are not taken from an allocation held by an ISP, there is 894 no ISP that holds and advertises a more general prefix. A holder of a 895 portable IP address space allocation MUST authorize one or more ASes 896 to originate routes to these prefixes. Thus the resource holder MUST 897 generate one or more EE certificates and associated ROAs to enable 898 the AS(es) to originate routes for the prefix(es) in question. This 899 ROA is required because none of the ISP's existing ROAs authorize it 900 to originate routes to the subscriber's provider-idependent 901 allocation. 903 8. Security Considerations 905 The focus of this document is security; hence security considerations 906 permeate this specification. 908 The security mechanisms provided by and enabled by this architecture 909 depend on the integrity and availability of the infrastructure it 910 describes. The integrity of objects within the infrastructure is 911 ensured by appropriate controls on the repository system, as 912 described in Section 4.4. Likewise, because the repository system is 913 structured as a distributed database, it should be inherently 914 resistant to denial of service attacks; nonetheless, appropriate 915 precautions should also be taken, both through replication and backup 916 of the constituent databases and through the physical security of 917 database servers. 919 9. IANA Considerations 921 This document requests that the IANA issue RPKI Certificates for the 922 resources for which it is authoritative, i.e., reserved IPv4 923 addresses, IPv6 ULAs, and address space not yet allocated by IANA to 924 the RIRs. IANA SHOULD make available trust anchor material in the 925 format defined in [9] in support of these functions. 927 10. Acknowledgments 929 The architecture described in this draft is derived from the 930 collective ideas and work of a large group of individuals. This work 931 would not have been possible without the intellectual contributions 932 of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of 933 APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim 934 Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy 935 Bush of IIJ. 937 Although we are indebted to everyone who has contributed to this 938 architecture, we would like to especially thank Rob Austein for the 939 concept of a manifest, Geoff Huston for the concept of managing 940 object validity through single-use EE certificate key pairs, and 941 Richard Barnes for help in preparing an early version of this 942 document. 944 11. References 946 11.1. Normative References 948 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 949 Levels", BCP 14, RFC 2119, March 1997. 951 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 952 (BGP-4)", RFC 4271, January 2006 954 [3] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 955 R., and W. Polk, "Internet X.509 Public Key Infrastructure 956 Certificate and Certificate Revocation List (CRL) Profile", RFC 957 5280, May 2008. 959 [4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 960 2004. 962 [5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 963 Addresses and AS Identifiers", RFC 3779, June 2004. 965 [6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 966 X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- 967 17, September 2009. 969 [7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route 970 Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-06, 971 October 2009. 973 [8] Austein, R., et al., "Manifests for the Resource Public Key 974 Infrastructure", draft-ietf-sidr-rpki-manifests-05, August 975 2009. 977 [9] Michaelson, G., Kent, S., and Huston, G., "A Profile for Trust 978 Anchor Material for the Resource Certificate PKI", draft-ietf- 979 sidr-ta-02, September 2009. 981 [10] Huston, G., "A Profile for Algorithms and Key Sizes for use in 982 the Resource Public Key Infrastructure", draft-ietf-sidr-rpki- 983 algs-00, August 2009. 985 11.2. Informative References 987 [11] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 988 Resource Certificate Repository Structure", draft-ietf-sidr- 989 repos-struct-03, August 2009. 991 [12] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway 992 Protocol (Secure-BGP)", IEEE Journal on Selected Areas in 993 Communications Vol. 18, No. 4, April 2000. 995 [13] White, R., "soBGP", May 2005, 998 [14] Tridgell, A., "rsync", April 2006, 999 1001 [15] Huston, G., Michaelson, G., "Validation of Route Origination in 1002 BGP using the Resource Certificate PKI", draft-ietf-sidr-roa- 1003 validation-03, August 2009. 1005 Authors' Addresses 1007 Matt Lepinski 1008 BBN Technologies 1009 10 Moulton St. 1010 Cambridge, MA 02138 1012 Email: mlepinski@bbn.com 1014 Stephen Kent 1015 BBN Technologies 1016 10 Moulton St. 1017 Cambridge, MA 02138 1019 Email: kent@bbn.com 1021 Pre-5378 Material Disclaimer 1023 This document may contain material from IETF Documents or IETF 1024 Contributions published or made publicly available before November 1025 10, 2008. The person(s) controlling the copyright in some of this 1026 material may not have granted the IETF Trust the right to allow 1027 modifications of such material outside the IETF Standards Process. 1028 Without obtaining an adequate license from the person(s) controlling 1029 the copyright in such materials, this document may not be modified 1030 outside the IETF Standards Process, and derivative works of it may 1031 not be created outside the IETF Standards Process, except to format 1032 it for publication as an RFC or to translate it into languages other 1033 than English.