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