idnits 2.17.1 draft-ietf-sidr-arch-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2011) is 4789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 February 16, 2011 5 Expires: August 16, 2011 7 An Infrastructure to Support Secure Internet Routing 8 draft-ietf-sidr-arch-12.txt 10 Status of this Memo 12 This Internet-Draft is submitted 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 August 16, 2011. 33 Copyright Notice 35 Copyright (c) 2011 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. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 This document describes an architecture for an infrastructure to 51 support improved security of Internet routing. The foundation of this 52 architecture is a public key infrastructure (PKI) that represents the 53 allocation hierarchy of IP address space and Autonomous System (AS) 54 Numbers; and a distributed repository system for storing and 55 disseminating the data objects that comprise the PKI, as well as 56 other signed objects necessary for improved routing security. As an 57 initial application of this architecture, the document describes how 58 a legitimate holder of IP address space can explicitly and verifiably 59 authorize one or more ASes to originate routes to that address space. 60 Such verifiable authorizations could be used, for example, to more 61 securely construct BGP route filters. 63 Table of Contents 65 1. Introduction ............................................. 3 66 1.1. Terminology ......................................... 4 67 2. PKI for Internet Number Resources ........................ 5 68 2.1. Role in the overall architecture .................... 5 69 2.2. CA Certificates ..................................... 6 70 2.3. End-Entity (EE) Certificates ........................ 7 71 2.4. Trust Anchors ....................................... 8 72 3. Route Origination Authorizations ......................... 9 73 3.1. Role in the overall architecture .................... 9 74 3.2. Syntax and semantics ................................ 10 75 4. Repositories ............................................. 11 76 4.1. Role in the overall architecture .................... 12 77 4.2. Contents and structure .............................. 12 78 4.3. Access protocols .................................... 14 79 4.4. Access control ...................................... 15 80 5. Manifests ................................................ 15 81 5.1. Syntax and semantics ................................ 15 82 6. Local Cache Maintenance .................................. 16 83 7. Common Operations ........................................ 17 84 7.1. Certificate issuance ................................ 17 85 7.2. CA Key Rollover ..................................... 18 86 7.3. ROA management ...................................... 19 87 7.3.1. Single-homed subscribers ....................... 20 88 7.3.2. Multi-homed subscribers ........................ 20 89 7.3.3. Provider-Independent Address Space ............. 21 90 8. Security Considerations .................................. 21 91 9. IANA Considerations ...................................... 21 92 10. Acknowledgments ......................................... 22 93 11. References .............................................. 23 94 11.1. Normative References ............................... 23 95 11.2. Informative References ............................ 23 96 Authors' Addresses ......................................... 24 98 1. Introduction 100 This document describes an architecture for an infrastructure to 101 support improved security for BGP routing [RFC 4271] for the 102 Internet. The architecture encompasses three principle elements: 104 . a public key infrastructure (PKI) 106 . digitally-signed routing objects to support routing security 108 . a distributed repository system to hold the PKI objects and the 109 signed routing objects 111 The architecture described by this document enables an entity to 112 verifiably assert that it is the legitimate holder of a set of IP 113 addresses or a set of Autonomous System (AS) numbers. As an initial 114 application of this architecture, the document describes how a 115 legitimate holder of IP address space can explicitly and verifiably 116 authorize one or more ASes to originate routes to that address space. 117 Such verifiable authorizations could be used, for example, to more 118 securely construct BGP route filters. In addition to this initial 119 application, the infrastructure defined by this architecture also is 120 intended to provide future support for security protocols such as S- 121 BGP [S-BGP] or soBGP [soBGP]. This architecture is applicable to the 122 routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently 123 the only address families supported by this architecture. Thus, for 124 example, use of this architecture with MPLS labels is beyond the 125 scope of this document. 127 In order to facilitate deployment, the architecture takes advantage 128 of existing technologies and practices. The structure of the PKI 129 element of the architecture corresponds to the existing resource 130 allocation structure. Thus management of this PKI is a natural 131 extension of the resource-management functions of the organizations 132 that are already responsible for IP address and AS number resource 133 allocation. Likewise, existing resource allocation and revocation 134 practices have well-defined correspondents in this architecture. Note 135 that while the initial focus of this architecture is routing security 136 applications, the PKI described in this document could be used to 137 support other applications that make use of attestations of IP 138 address or AS number resource holdings. 140 To ease implementation, existing IETF standards are used wherever 141 possible; for example, extensive use is made of the X.509 certificate 142 profile defined by the Public Key Infrastructure using X.509 (PKIX) 143 working group [RFC 5280] and the extensions for IP Addresses and AS 144 numbers representation defined in RFC 3779 [RFC 3779]. Also 145 Cryptographic Message Syntax (CMS) [RFC 5652] is used as the syntax 146 for the newly-defined signed objects [SIGN-OBJ] required by this 147 infrastructure. 149 As noted above, the architecture is comprised of three main 150 components: an X.509 PKI in which certificates attest to holdings of 151 IP address space and AS numbers; non-certificate/CRL signed objects 152 (including route origination authorizations and manifests) used by 153 the infrastructure; and a distributed repository system that makes 154 all of these signed objects available for use by ISPs in making 155 routing decisions. These three basic components enable several 156 security functions; this document describes how they can be used to 157 improve route filter generation, and to perform several other common 158 operations in such a way as to make them cryptographically 159 verifiable. 161 1.1. Terminology 163 It is assumed that the reader is familiar with the terms and concepts 164 described in "Internet X.509 Public Key Infrastructure Certificate 165 and Certificate Revocation List (CRL) Profile" [RFC 5280], and "X.509 166 Extensions for IP Addresses and AS Identifiers" [RFC 3779]. 168 Throughout this document we use the terms "address space holder" or 169 "holder of IP address space" interchangeably to refer to a legitimate 170 holder of IP address space who has received this address space 171 through the standard IP address allocation hierarchy. That is, the 172 address space holder has either directly received the address space 173 as an allocation from a Regional Internet Registry (RIR) or IANA; or 174 else the address space holder has received the address space as a 175 sub-allocation from a National Internet Registry (NIR) or Local 176 Internet Registry (LIR). We use the term "resource holder" to refer 177 to a legitimate holder of either IP address or AS number resources. 179 Throughout this document we use the terms "registry" and ISP to refer 180 to an entity that has an IP address space and/or AS number allocation 181 that it is permitted to sub-allocate. 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in RFC 186 2119 [RFC 2119]. 188 2. PKI for Internet Number Resources 190 Because the holder of a block of IP address space is entitled to 191 define the topological destination of IP datagrams whose destinations 192 fall within that block, decisions about inter-domain routing are 193 inherently based on knowledge of the allocation of the IP address 194 space. Thus, a basic function of this architecture is to provide 195 cryptographically verifiable attestations as to these allocations. In 196 current practice, the allocation of IP addresses is hierarchical. The 197 root of the hierarchy is IANA. Below IANA are five Regional Internet 198 Registries (RIRs), each of which manages address and AS number 199 allocation within a defined geopolitical region. In some regions the 200 third tier of the hierarchy includes National Internet Registries 201 (NIRs) as well as Local Internet Registries (LIRs) and subscribers 202 with so-called provider-independent ("portable") allocations. (The 203 term LIR is used in some regions to refer to what other regions 204 define as an ISP. Throughout the rest of this document we will use 205 the term LIR/ISP to simplify references to these entities.) In other 206 regions the third tier consists only of LIRs/ISPs and subscribers 207 with provider-independent allocations. 209 In general, the holder of a block of IP address space may sub- 210 allocate portions of that block, either to itself (e.g., to a 211 particular unit of the same organization), or to another 212 organization, subject to contractual constraints established by the 213 registries. Because of this structure, IP address allocations can be 214 described naturally by a hierarchic public-key infrastructure, in 215 which each certificate attests to an allocation of IP addresses, and 216 issuance of subordinate certificates corresponds to sub-allocation of 217 IP addresses. The above reasoning holds true for AS number resources 218 as well, with the difference that, by convention, AS numbers may not 219 be sub-allocated except by RIRs or NIRs. Thus allocations of both IP 220 addresses and AS numbers can be expressed by the same PKI. Such a 221 PKI is a central component of this architecture. 223 2.1. Role in the overall architecture 225 Certificates in this PKI are called Resource Certificates, and 226 conform to the certificate profile for such certificates [RES-CERT]. 227 Resource certificates attest to the allocation by the (certificate) 228 issuer of IP addresses or AS numbers to the subject. They do this by 229 binding the public key contained in the Resource Certificate to the 230 IP addresses or AS numbers included in the certificate's IP Address 231 Delegation or AS Identifier Delegation Extensions, respectively, as 232 defined in RFC 3779 [RFC 3779]. 234 An important property of this PKI is that certificates do not attest 235 to the identity of the subject. Therefore, the subject names used in 236 certificates are not intended to be "descriptive." That is, the 237 resource PKI is intended to provide authorization, but not 238 authentication. This is in contrast to most PKIs where the issuer 239 ensures that the descriptive subject name in a certificate is 240 properly associated with the entity that holds the private key 241 corresponding to the public key in the certificate. Because issuers 242 need not verify the right of an entity to use a subject name in a 243 certificate, they avoid the costs and liabilities of such 244 verification. This makes it easier for these entities to take on the 245 additional role of Certificate Authority (CA). 247 Most of the certificates in the PKI assert the basic facts on which 248 the rest of the infrastructure operates. CA certificates within the 249 PKI attest to IP address space and AS number holdings. End-entity 250 (EE) certificates are issued by resource holder CAs to delegate the 251 authority attested by their allocation certificates. The primary use 252 for EE certificates is the validation of Route Origination 253 Authorizations (ROAs), signed objects which provide an explicit 254 authorization by an address holder that a given AS is permitted to 255 originate routes to a set of addresses (see Section 3). End Entity 256 certificates are also used to verify other signed objects, such as 257 manifests which will be used to help ensure the integrity of the 258 repository system (see Section 5). 260 2.2. CA Certificates 262 Any resource holder who is authorized to sub-allocate these resources 263 must be able to issue Resource Certificates to correspond to these 264 sub-allocations. Thus, for example, CA certificates will be 265 associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. A CA 266 certificate also is required to enable a resource holder to issue 267 ROAs, because it must issue the corresponding end-entity certificate 268 used to validate each ROA. Thus some entities that do not sub- 269 allocate their resources also will need to have CA certificates for 270 their allocations, e.g., a multi-homed subscriber with a provider- 271 independent allocation, to enable them to issue ROAs. (A subscriber 272 who is not multi-homed, whose allocation comes from an LIR/ISP, and 273 who has not moved to a different LIR/ISP, need not be represented in 274 the PKI. Moreover, a multi-homed subscriber with an allocation from 275 an LIR/ISP may or may not need to be explicitly represented, as 276 discussed in Section 7.2.2) 278 Unlike in most PKIs, the distinguished name of the subject in a CA 279 certificate is chosen by the certificate issuer. The subject's 280 distinguished name must not attempt to convey the identity of the 281 subject in a descriptive fashion. The subject's distinguished name 282 must include the common name attribute and may additionally include 283 the serial attribute. 285 In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, 286 is not in the business of verifying the legal right of the subject to 287 assert a particular identity. Therefore, selecting a distinguished 288 name that does not convey the identity of the subject in a 289 descriptive fashion minimizes the opportunity for the subject to 290 misuse the certificate to assert an identity, and thus minimizes the 291 legal liability of the issuer. Since all CA certificates are issued 292 to subjects with whom the issuer has an existing relationship, it is 293 recommended that the issuer select a subject name that enables the 294 issuer to easily link the certificate to existing database records 295 associated with the subject. For example, an authority may use 296 internal database keys or subscriber IDs as the subject common name 297 in issued certificates. 299 Although the subject's common name in a certificate does not convey 300 identity, it is still the case that the common name must be unique 301 among all subjects to whom a certification authority issues 302 certificates. That is, a CA must not issue certificates to two 303 different entities which use the same common name for the subject. 305 Each Resource Certificate attests to an allocation of resources to a 306 resource holder, so entities that have allocations from multiple 307 sources will have multiple CA certificates. Note that when an entity 308 receives multiple certificates from different issuers that the 309 subject names in these certificates will generally be different. A CA 310 also may issue distinct certificates for each distinct allocation to 311 the same entity, if the CA and the resource holder agree that such an 312 arrangement will facilitate management and use of the certificates. 313 For example, an LIR/ISP may have several certificates issued to it by 314 one registry, each describing a distinct set of address blocks, 315 because the LIR/ISP desires to treat the allocations as separate. 317 2.3. End-Entity (EE) Certificates 319 The private key corresponding to a public key contained in an EE 320 certificate is not used to sign other certificates in a PKI. The 321 primary function of end-entity certificates in this PKI is the 322 verification of signed objects that relate to the usage of the 323 resources described in the certificate, e.g., ROAs and manifests. 325 For ROAs and manifests there will be a one-to-one correspondence 326 between end-entity certificates and signed objects, i.e., the private 327 key corresponding to each end-entity certificate is used to sign 328 exactly one object, and each object is signed with only one key. 329 This property allows the PKI to be used to revoke these signed 330 objects, rather than creating a new revocation mechanism. When the 331 end-entity certificate used to sign an object has been revoked, the 332 signature on that object (and any corresponding assertions) will be 333 considered invalid, so a signed object can be effectively revoked by 334 revoking the end-entity certificate used to sign it. 336 A secondary advantage to this one-to-one correspondence is that the 337 private key corresponding to the public key in a certificate is used 338 exactly once in its lifetime, and thus can be destroyed after it has 339 been used to sign its one object. This fact should simplify key 340 management, since there is no requirement to protect these private 341 keys for an extended period of time. 343 The EE certificate used to verify a signed object appears in the 344 Cryptographic Message Syntax (CMS) wrapper (see [SIGN-OBJ]) of the 345 signed object. Therefore, it is not necessary to transmit the EE 346 certificate separately from the signed object. Likewise, it is not 347 necessary for the EE certificate to appear in the RPKI repository 348 system except as part of the corresponding signed object. 350 Although this document describes only two uses for end-entity 351 certificates, additional uses will likely be defined in the future. 352 For example, end-entity certificates could be used as a more general 353 authorization for their subjects to act on behalf of the specified 354 resource holder. This could facilitate authentication of inter-ISP 355 interactions, or authentication of interactions with the repository 356 system. These additional uses for end-entity certificates may 357 require retention of the corresponding private keys, even though this 358 is not required for the private keys associated with end-entity 359 certificates keys used for verification of ROAs and manifests, as 360 described above. 362 2.4. Trust Anchors 364 In any PKI, each relying party (RP) chooses its own set of trust 365 anchors. This general property of PKIs applies here as well. There is 366 an extant IP address space and AS number allocation hierarchy, and 367 thus IANA and/or the five RIRs are obvious candidates to be default 368 TAs here. Nonetheless, each RP ultimately chooses the set of trust 369 anchors it will use for certificate validation. 371 For example, a RP (e.g., an LIR/ISP) could create a trust anchor to 372 which all address space and/or all AS numbers are assigned, and for 373 which the RP knows the corresponding private key. The RP could then 374 issue certificates under this trust anchor to whatever entities in 375 the PKI it wishes, with the result that the certification paths 376 terminating at this locally-installed trust anchor will satisfy the 377 RFC 3779 validation requirements. A large ISP that uses private 378 (i.e., RFC 1918) IP address space and runs BGP internally will need 379 to create this sort of trust anchor to accommodate a CA to which all 380 private (RFC 1918) address space is assigned. The RP could then issue 381 certificates under this CA that correspond to the RP's internal use 382 of private address space. 384 Note that a RP who elects to create and manage its own set of trust 385 anchors may fail to detect allocation errors that arise under such 386 circumstances, but the resulting vulnerability is local to the RP. 388 It is expected that some parties within the extant IP address space 389 and AS number allocation hierarchy may wish to publish trust anchor 390 material for possible use by relying parties. A standard profile for 391 the publication of trust anchor material for this public key 392 infrastructure can be found in [SIDR-TA]. 394 3. Route Origination Authorizations 396 The information on IP address allocation provided by the PKI is not, 397 in itself, sufficient to guide routing decisions. In particular, BGP 398 is based on the assumption that the AS that originates routes for a 399 particular prefix is authorized to do so by the holder of that prefix 400 (or an address block encompassing the prefix); the PKI contains no 401 information about these authorizations. A Route Origination 402 Authorization (ROA) makes such authorization explicit, allowing a 403 holder of IP address space to create an object that explicitly and 404 verifiably asserts that an AS is authorized originate routes to a 405 given set of prefixes. 407 3.1. Role in the overall architecture 409 A ROA is an attestation that the holder of a set of prefixes has 410 authorized an autonomous system to originate routes for those 411 prefixes. A ROA is structured according to the format described in 412 [ROA-FORM]. The validity of this authorization depends on the signer 413 of the ROA being the holder of the prefix(es) in the ROA; this fact 414 is asserted by an end-entity certificate from the PKI, whose 415 corresponding private key is used to sign the ROA. 417 ROAs may be used by relying parties to verify that the AS that 418 originates a route for a given IP address prefix is authorized by the 419 holder of that prefix to originate such a route. For example, an ISP 420 might use validated ROAs as inputs to route filter construction for 421 use by its BGP routers. (See [ROA-VALID] for information on the use 422 of ROAs to validate the origination of BGP routes.) 424 Initially, the repository system will be the primary mechanism for 425 disseminating ROAs, since these repositories will hold the 426 certificates and CRLs needed to verify ROAs. In addition, ROAs also 427 could be distributed in BGP UPDATE messages or via other 428 communication paths, if needed to meet timeliness requirements. 430 3.2. Syntax and semantics 432 A ROA constitutes an explicit authorization for a single AS to 433 originate routes to one or more prefixes, and is signed by the holder 434 of those prefixes. Conceptually, the ROA syntax consists of two 435 parts, a general CMS template common to all RPKI signed objects 436 [SIGN-OBJ] and an encapsulated content specific to the ROA which 437 expresses the authorization [ROA-FORM]. 439 At a high level, the ROA's content contains (1) an AS number; (2) a 440 list of IP address prefixes; and, optionally, (3) for each prefix, 441 the maximum length of more specific (longer) prefixes that the AS is 442 also authorized to advertise. (This last element facilitates a 443 compact authorization to advertise, for example, any prefixes of 444 length 20 to 24 contained within a given length 20 prefix.) 446 Note that a ROA contains only a single AS number. Thus, if an ISP has 447 multiple AS numbers that will be authorized to originate routes to 448 the prefix(es) in the ROA, an address space holder will need to issue 449 multiple ROAs to authorize the ISP to originate routes from any of 450 these ASes. 452 A ROA is signed using the private key corresponding to the public key 453 in an end-entity certificate in the PKI. In order for a ROA to be 454 valid, its corresponding end-entity (EE) certificate must be valid 455 and the IP address prefixes of the ROA must exactly match the IP 456 address prefix(es) specified in the EE certificate's RFC 3779 457 extension. Therefore, the validity interval of the ROA is implicitly 458 the validity interval of its corresponding certificate. A ROA is 459 revoked by revoking the corresponding EE certificate. There is no 460 independent method of revoking a ROA. One might worry that this 461 revocation model could lead to long CRLs for the CA certification 462 that is signing the EE certificates. However, routing announcements 463 on the public internet are generally quite long lived. Therefore, as 464 long as the EE certificates used to verify a ROA are given a validity 465 interval of several months, the likelihood that many ROAs would need 466 to revoked within that time is quite low. 468 --------- --------- 469 | RIR | | NIR | 470 | CA | | CA | 471 --------- --------- 472 | | 473 | | 474 | | 475 --------- --------- 476 | ISP | | ISP | 477 | CA 1 | | CA 2 | 478 --------- --------- 479 | \ | 480 | ----- | 481 | \ | 482 ---------- ---------- ---------- 483 | ISP | | ISP | | ISP | 484 | EE 1a | | EE 1b | | EE 2 | 485 ---------- ---------- ---------- 486 | | | 487 | | | 488 | | | 489 ---------- ---------- ---------- 490 | ROA 1a | | ROA 1b | | ROA 2 | 491 ---------- ---------- ---------- 493 FIGURE 2: This figure illustrates an ISP with allocations from two 494 sources (an RIR and an NIR). It needs two CA certificates due to RFC 495 3779 rules. 497 Because each ROA is associated with a single end-entity certificate, 498 the set of IP prefixes contained in a ROA must be drawn from an 499 allocation by a single source, i.e., a ROA cannot combine allocations 500 from multiple sources. Address space holders who have allocations 501 from multiple sources, and who wish to authorize an AS to originate 502 routes for these allocations, must issue multiple ROAs to the AS. 504 4. Repositories 506 Initially, an LIR/ISP will make use of the resource PKI by acquiring 507 and validating every ROA, to create a table of the prefixes for which 508 each AS is authorized to originate routes. To validate all ROAs, an 509 LIR/ISP needs to acquire all the certificates and CRLs. The primary 510 function of the distributed repository system described here is to 511 store these signed objects and to make them available for download by 512 LIRs/ISPs. Note that this repository system provides a mechanism by 513 which relying parties can pull fresh data at whatever frequency they 514 deem appropriate. However, it does not provide a mechanism for 515 pushing fresh data to relying parties (e.g. by including resource PKI 516 objects in BGP or other protocol messages) and such a mechanism is 517 beyond the scope of the current document. 519 The digital signatures on all objects in the repository ensure that 520 unauthorized modification of valid objects is detectable by relying 521 parties. Additionally, the repository system uses manifests (see 522 Section 5) to ensure that relying parties can detect the deletion of 523 valid objects and the insertion of out of date, valid signed objects. 525 The repository system is also a point of enforcement for access 526 controls for the signed objects stored in it, e.g., ensuring that 527 records related to an allocation of resources can be manipulated only 528 by authorized parties. The use of access controls prevents denial of 529 service attacks based on deletion of or tampering to repository 530 objects. Indeed, although relying parties can detect tampering with 531 objects in the repository, it is preferable that the repository 532 system prevent such unauthorized modifications to the greatest extent 533 possible. 535 4.1. Role in the overall architecture 537 The repository system is the central clearing-house for all signed 538 objects that must be globally accessible to relying parties. When 539 certificates and CRLs are created, they are uploaded to this 540 repository, and then downloaded for use by relying parties (primarily 541 LIRs/ISPs). ROAs and manifests are additional examples of such 542 objects, but other types of signed objects may be added to this 543 architecture in the future. This document briefly describes the way 544 signed objects (certificates, CRLs, ROAs and manifests) are managed 545 in the repository system. As other types of signed objects are added 546 to the repository system it will be necessary to modify the 547 description, but it is anticipated that most of the design principles 548 will still apply. The repository system is described in detail in 549 [REPOS]. 551 4.2. Contents and structure 553 Although there is a single repository system that is accessed by 554 relying parties, it is comprised of multiple databases. These 555 databases will be distributed among registries (RIRs, NIRs, 556 LIRs/ISPs). At a minimum, the database operated by each registry will 557 contain all CA and EE certificates, CRLs, and manifests signed by the 558 CA(s) associated with that registry. Repositories operated by 559 LIRs/ISPs also will contain ROAs. Registries are encouraged to 560 maintain copies of repository data from their customers, and their 561 customer's customers (etc.), to facilitate retrieval of the whole 562 repository contents by relying parties. Ideally, each RIR will hold 563 PKI data from all entities within its geopolitical scope. 565 For every certificate in the PKI, there will be a corresponding file 566 system directory in the repository that is the authoritative 567 publication point for all objects (certificates, CRLs, ROAs and 568 manifests) verifiable via this certificate. A certificate's Subject 569 Information Authority (SIA) extension provides a URI that references 570 this directory. Additionally, a certificate's Authority Information 571 Authority (AIA) extension contains a URI that references the 572 authoritative location for the CA certificate under which the given 573 certificate was issued. That is, if certificate A is used to verify 574 certificate B, then the AIA extension of certificate B points to 575 certificate A, and the SIA extension of certificate A points to a 576 directory containing certificate B (see Figure 2). 578 +--------+ 579 +--------->| Cert A |<----+ 580 | | CRLDP | | 581 | | AIA | | 582 | +--------- SIA | | 583 | | +--------+ | 584 | | | 585 | | | 586 | | | 587 | | +-------------------|------------------+ 588 | | | | | 589 | +->| +--------+ | +--------+ | 590 | | | Cert B | | | Cert C | | 591 | | | CRLDP ----+ | | CRLDP -+-+ | 592 +----------- AIA | | +----- AIA | | | 593 | | SIA | | | SIA | | | 594 | +--------+ | +--------+ | | 595 | V | | 596 | +---------+ | | 597 | | A's CRL |<-----------+ | 598 | +---------+ | 599 | A's Repository Publication Directory | 600 +--------------------------------------+ 602 FIGURE 3: In this example, certificates B and C are issued by 603 certification authority A. Therefore, the AIA extensions of 604 certificates B and C point to the publication point where Certificate 605 A is published, and the SIA extension of certificate A points to the 606 repository publication point where the objects issued under authority 607 A, including certificates B and C and A's CRL, are published. 609 If a CA certificate is reissued with the same public key, it should 610 not be necessary to reissue (with an updated AIA URI) all 611 certificates signed by the certificate being reissued. Therefore, a 612 certification authority SHOULD use a persistent URI naming scheme for 613 issued certificates. That is, reissued certificates should use the 614 same publication point as previously issued certificates having the 615 same subject and public key, and should overwrite such certificates. 617 4.3. Access protocols 619 Repository operators will choose one or more access protocols that 620 relying parties can use to access the repository system. These 621 protocols will be used by numerous participants in the infrastructure 622 (e.g., all registries, ISPs, and multi-homed subscribers) to maintain 623 their respective portions of it. In order to support these 624 activities, certain basic functionality is required of the suite of 625 access protocols, as described below. No single access protocol need 626 implement all of these functions (although this may be the case), but 627 each function must be implemented by at least one access protocol. 629 Download: Access protocols MUST support the bulk download of 630 repository contents and subsequent download of changes to the 631 downloaded contents, since this will be the most common way in which 632 relying parties interact with the repository system. Other types of 633 download interactions (e.g., download of a single object) MAY also be 634 supported. 636 Upload/change/delete: Access protocols MUST also support mechanisms 637 for the issuers of certificates, CRLs, and other signed objects to 638 add them to the repository, and to remove them. Mechanisms for 639 modifying objects in the repository MAY also be provided. All access 640 protocols that allow modification to the repository (through 641 addition, deletion, or modification of its contents) MUST support 642 verification of the authorization of the entity performing the 643 modification, so that appropriate access controls can be applied (see 644 Section 4.4). 646 To ensure all relying parties are able to acquire all RPKI signed 647 objects, all publication points MUST be accessible via RSYNC (see 648 [RFC 5781] and [RSYNC]), although other download protocols also be 649 supported. A repository publication point may provide 650 update/change/delete functionality via (set of) access protocols that 651 it desires, provided that the supported protocols are clearly 652 communicated to all certification authorities publishing data at a 653 given publication point. 655 4.4. Access control 657 In order to maintain the integrity of information in the repository, 658 controls must be put in place to prevent addition, deletion, or 659 modification of objects in the repository by unauthorized parties. 660 The identities of parties attempting to make such changes can be 661 authenticated through the relevant access protocols. Although 662 specific access control policies are subject to the local control of 663 repository operators, it is RECOMMENDED that repositories allow only 664 the issuers of signed objects to add, delete, or modify them. 665 Alternatively, it may be advantageous in the future to define a 666 formal delegation mechanism to allow resource holders to authorize 667 other parties to act on their behalf, as suggested in Section 2.3 668 above. 670 5. Manifests 672 A manifest is a signed object listing of all of the signed objects 673 issued by an authority responsible for a publication in the 674 repository system. For each unexpired certificate, CRL, or ROA issued 675 by the authority, the manifest contains both the name of the file 676 containing the object, and a hash of the file content. 678 As with ROAs, a manifest is signed by a private key, for which the 679 corresponding public key appears in an end-entity certificate. This 680 EE certificate, in turn, is signed by the CA in question. Since the 681 private key in an EE certificate is used to sign only a single 682 manifest, then the manifest can be revoked by revoking the EE 683 certificate. In such a case, to avoid needless CRL growth, the EE 684 certificate used to validate a manifest SHOULD expire at the same 685 time that the manifest expires. 687 Manifests may be used by relying parties when constructing a local 688 cache (see Section 6) to mitigate the risk of an attacker who deletes 689 files from a repository or replaces current signed objects with stale 690 versions of the same object. Such protection is needed because 691 although all objects in the repository system are signed, the 692 repository system itself is untrusted. 694 5.1. Syntax and semantics 696 A manifest constitutes a list of (the hashes of) all the files in a 697 repository point at a particular point in time. A detailed 698 specification of the manifest's content is provided in [MANIFEST] 699 but, at a high level, a manifest consists of (1) a manifest number; 700 (2) the time the manifest was issued; (3) the time of the next 701 planned update; and (4) a list of filename and hash value pairs. 703 The manifest number is a sequence number that is incremented each 704 time a manifest is issued by the authority. An authority is required 705 to issue a new manifest any time it alters any of its items in the 706 repository, or when the specified time of the next update is reached. 707 A manifest is thus valid until the specified time of the next update 708 or until a manifest is issued with a greater manifest number, 709 whichever comes first. (Note that when an EE certificate is used to 710 sign only a single manifest, whenever the authority issues the new 711 manifest, the CA MUST also issue a new CRL which includes the EE 712 certificate corresponding to the old manifest. The revoked EE 713 certificate for the old manifest will be removed from the CRL when it 714 expires, thus this procedure ought not to result in significant CRLs 715 growth.) 717 6. Local Cache Maintenance 719 In order to utilize signed objects issued under this PKI, a relying 720 party must first obtain a local copy of the valid EE certificates for 721 the PKI. To do so, the relying party performs the following steps: 723 1. Query the registry system to obtain a copy of all certificates, 724 manifests and CRLs issued under the PKI. 726 2. For each CA certificate in the PKI, verify the signature on the 727 corresponding manifest. Additionally, verify that the current 728 time is earlier than the time indicated in the nextUpdate field 729 of the manifest. 731 3. For each manifest, verify that certificates and CRLs issued 732 under the corresponding CA certificate match the hash values 733 contained in the manifest. Additionally, verify that no 734 certificate or manifest listed on the manifest is missing from 735 the repository. If the hash values do not match, or if any 736 certificate or CRL is missing, notify the appropriate repository 737 administrator that the repository data has been corrupted. 739 4. Validate each EE certificate by constructing and verifying a 740 certification path for the certificate (including checking 741 relevant CRLs) to the locally configured set of TAs. (See [RES- 742 CERT] for more details.) 744 Note that since relying parties will perform these operations 745 regularly, it is more efficient for the relying party to request from 746 the repository system only those objects that have changed since the 747 relying party last updated its local cache. 749 Note also that by checking all issued objects against the appropriate 750 manifest, the relying party can be certain that it is not missing an 751 updated version of any object. 753 7. Common Operations 755 Creating and maintaining the infrastructure described above will 756 entail additional operations as "side effects" of normal resource 757 allocation and routing authorization procedures. For example, a 758 subscriber with provider-independent ("portable") address space who 759 enters a relationship with an ISP will need to issue one or more ROAs 760 identifying that ISP, in addition to conducting any other necessary 761 technical or business procedures. The current primary use of this 762 infrastructure is for route filter construction; using ROAs, route 763 filters can be constructed in an automated fashion with high 764 assurance that the holder of the advertised prefix has authorized the 765 origin AS to originate an advertised route. 767 7.1. Certificate issuance 769 There are several operational scenarios that require certificates to 770 be issued. Any allocation that may be sub-allocated requires a CA 771 certificate, e.g., so that certificates can be issued as necessary 772 for the sub-allocations. Holders of provider-independent IP address 773 space allocations also must have certificates, so that a ROA can be 774 issued to each ISP that is authorized to originate a route to the 775 allocation (since the allocation does not come from any ISP). 776 Additionally, multi-homed subscribers may require certificates for 777 their allocations if they intend to issue the ROAs for their 778 allocations (see Section 7.2.2). Other resource holders need not be 779 issued CA certificates within the PKI. 781 In the long run, a resource holder will not request resource 782 certificates, but rather receive a certificate as a side effect of 783 the allocation process for the resource. However, initial deployment 784 of the RPKI will entail issuance of certificates to existing resource 785 holders as an explicit event. Note that in all cases, the authority 786 issuing a CA certificate will be the entity who allocates resources 787 to the subject. This differs from most PKIs in which a subject can 788 request a certificate from any certification authority. 790 If a resource holder receives multiple allocations over time, it may 791 accrue a collection of resource certificates to attest to them. If a 792 resource holder receives multiple allocations from the same source, 793 the set of resource certificates may be combined into a single 794 resource certificate, if both the issuer and the resource holder 795 agree. This is accomplished by consolidating the IP Address 796 Delegation and AS Identifier Delegation Extensions into a single 797 extension (of each type) in a new certificate. However, if these 798 certificates attest to allocations which are valid for different 799 periods of time, creating a certificate that combines them might 800 create problems as the combined certificate can only express a single 801 validity interval. 803 If a resource holder's allocations come from different sources, they 804 will be signed by different CAs, and cannot be combined. When a set 805 of resources is no longer allocated to a resource holder, any 806 certificates attesting to such an allocation MUST be revoked. A 807 resource holder SHOULD NOT use the same public key in multiple CA 808 certificates that are issued by the same or differing authorities, as 809 reuse of a key pair complicates path construction. Note that since 810 the subject's distinguished name is chosen by the issuer, a subject 811 who receives allocations from two sources generally will receive 812 certificates with different subject names. 814 7.2. CA Key Rollover 816 Whenever a certification authority wishes to change the public key 817 (and corresponding private key) associated with its RPKI CA 818 certificate, it must perform a key rollover procedure. Key rollover 819 is typically performed on a periodic basis, where the frequency of 820 key rollovers is specified in the certification practice statement of 821 the given CA. Additionally, unscheduled rollovers may be required in 822 the event of suspected key compromises. 824 Note that rollover is only required when the CA's key actually 825 changes, it is not required in cases where a new CA certificate is 826 issued with the same key as the previous certificate for this CA. For 827 example, a new CA certificate must be issued if the CA gains or 828 relinquishes resource, or if the validity period of the resource 829 allocation is extended. However, in such a cases the new certificate 830 will generally use the same public (and private) key as the previous 831 certificate and thus key rollover is not required. 833 The document [KEY-ROLL] specifies a conservative key rollover 834 procedure that should be used by a certification authority when it 835 changes the public (and private) keys associated with its RPKI CA 836 certificate. At a high level, the two key properties of the rollover 837 procedure are as follows. First, as data from RPKI signed objects may 838 be used in routing operations, the procedure ensures that at any 839 point in the rollover procedure a relying party will never reach 840 incorrect conclusions about the validity of a signed object. Note in 841 particular, that the CA cannot assume that a relying party will use 842 any particular algorithm for constructing a certificate path from an 843 EE certificate to (one of) the relying party's trust anchor(s), 844 therefore, the key rollover procedure is designed to preserve the 845 integrity of the SIA and AIA points within the RPKI hierarchy to the 846 greatest extent possible. Second, the key rollover procedure is 847 design so that the reissuance of all certificates below the CA in the 848 RPKI hierarchy is not required. Of course, it is necessary to re-sign 849 all certificates issued directly under the CA whose key is changing. 850 However, the SIA and AIA pointers within the certificates are 851 populated so that no further re-issuance is required. 853 7.3. ROA management 855 Whenever a holder of IP address space wants to authorize an AS to 856 originate routes for a prefix within his holdings, he MUST issue an 857 end-entity certificate containing that prefix in an IP Address 858 Delegation extension. He then uses the corresponding private key to 859 sign a ROA containing the designated prefix and the AS number for the 860 AS. The resource holder MAY include more than one prefix in the EE 861 certificate and corresponding ROA if desired. As a prerequisite, 862 then, any address space holder that issues ROAs for a prefix must 863 have a resource certificate for an allocation containing that prefix. 864 The standard procedure for issuing a ROA is as follows: 866 1. Create an end-entity certificate containing the prefix(es) to be 867 authorized in the ROA. 869 2. Construct the payload of the ROA, including the prefixes in the 870 end-entity certificate and the AS number to be authorized. 872 3. Sign the ROA using the private key corresponding to the end- 873 entity certificate (the ROA is comprised of the payload 874 encapsulated in a CMS signed message [RFC 5652]). 876 4. Upload the end-entity certificate and the ROA to the repository 877 system. 879 The standard procedure for revoking a ROA is to revoke the 880 corresponding end-entity certificate by creating an appropriate CRL 881 and uploading it to the repository system. The revoked ROA and end- 882 entity certificate SHOULD be removed from the repository system. 884 Care must be taken when revoking ROAs in that revoking a ROA may 885 cause a relying party to treat routing advertisements corresponding 886 to the prefixes and origin AS number in the ROA as unauthorized (and 887 potentially even change routing behavior to no longer forward packets 888 based on those advertisements). In particular, resource holders 889 should adhere to the principle of "make before break" as follows. 891 Before revoking a ROA corresponding to a prefix which the resource 892 holder wishes to be routable on the Internet, it is very important 893 for the resource holder to ensure that there exists another valid 894 alternative ROA that lists the same prefix (possibly indicating a 895 different AS number). Additionally, the resource holder should ensure 896 that the AS indicated in the valid alternative ROA is actually 897 originating routing advertisements to the prefixes in question. 898 Furthermore, a relying party must fetch new ROAs from the repository 899 system before taking any routing action in response to a ROA 900 revocation. 902 7.3.1. Single-homed subscribers 904 In BGP, a single-homed subscriber with Provider Aggregatable (PA) 905 address space does not need to explicitly authorize routes to be 906 originated for the prefix(es) it is using, since its ISP will already 907 advertise a more general prefix and route traffic for the 908 subscriber's prefix as an internal function. Since no routes are 909 originated specifically for prefixes held by these subscribers, no 910 ROAs need to be issued under their allocations; rather, the 911 subscriber's ISP will issue any necessary ROAs for its more general 912 prefixes under resource certificates from its own allocation. Thus, a 913 single-homed subscriber with an IP address allocation from his 914 service provider is not included in the RPKI, i.e., it does not 915 receive a CA certificate, nor issue EE certificates or ROAs. 917 7.3.2. Multi-homed subscribers 919 Here we consider a subscriber who receives Provider Aggregatable (PA) 920 IP address space from a primary ISP (i.e., the IP addresses used by 921 the subscriber are a subset of ISP A's IP address space allocation) 922 and receives redundant upstream connectivity from one or more 923 secondary ISPs, in addition to the primary ISP. The preferred option 924 for such a multi-homed subscriber is for the subscriber to obtain an 925 AS number (from an RIR or NIR) and run BGP with each of its upstream 926 providers. In such a case, there are two ways for ROA management to 927 be handled. The first is that the primary ISP issues a CA certificate 928 to the subscriber, and the subscriber issues a ROA to containing the 929 subscriber's AS number and the subscriber's IP address prefixes. The 930 second possibility is that the primary ISP does not issue a CA 931 certificate to the subscriber, and instead issues a ROA on the 932 subscriber's behalf that contains the subscriber's AS number and the 933 subscriber's IP address prefixes. 935 If the subscriber is unable or unwilling to obtain an AS number and 936 run BGP, the other option is that the multi-homed subscriber can 937 request that the primary ISP create a ROA for each secondary ISP that 938 authorizes the secondary ISP to originate routes to the subscriber's 939 prefixes. The primary ISP will also create a ROA containing its own 940 AS number and the subscriber's prefixes, as it is likely in such a 941 case that the primary ISP wishes to advertise precisely the 942 subscriber's prefixes and not an encompassing aggregate. Note that 943 this approach results in inconsistent origin AS numbers for the 944 subscriber's prefixes which are considered undesirable on the public 945 Internet; thus this approach is NOT RECOMMENDED. 947 7.3.3. Provider-Independent Address Space 949 A resource holder is said to have provider-independent (portable) 950 address space if the resource holder received its allocation directly 951 from a RIR or NIR. Because the prefixes represented in such 952 allocations are not taken from an allocation held by an ISP, there is 953 no ISP that holds and advertises a more general prefix. A holder of a 954 portable IP address space allocation MUST authorize one or more ASes 955 to originate routes to these prefixes. Thus the resource holder MUST 956 generate one or more EE certificates and associated ROAs to enable 957 the AS(es) to originate routes for the prefix(es) in question. This 958 ROA is required because none of the ISP's existing ROAs authorize it 959 to originate routes to the subscriber's provider-idependent 960 allocation. 962 8. Security Considerations 964 The focus of this document is security; hence security considerations 965 permeate this specification. 967 The security mechanisms provided by and enabled by this architecture 968 depend on the integrity and availability of the infrastructure it 969 describes. The integrity of objects within the infrastructure is 970 ensured by appropriate controls on the repository system, as 971 described in Section 4.4. Likewise, because the repository system is 972 structured as a distributed database, it should be inherently 973 resistant to denial of service attacks; nonetheless, appropriate 974 precautions should also be taken, both through replication and backup 975 of the constituent databases and through the physical security of 976 database servers. 978 9. IANA Considerations 980 This document requests that the IANA issue RPKI Certificates for the 981 resources for which it is authoritative, i.e., reserved IPv4 982 addresses, IPv6 Unique Local Addresses (ULAs), and address space not 983 yet allocated by IANA to the RIRs. IANA SHOULD make available trust 984 anchor material in the format defined in [SIDR-TA] in support of 985 these functions. 987 10. Acknowledgments 989 The architecture described in this draft is derived from the 990 collective ideas and work of a large group of individuals. This work 991 would not have been possible without the intellectual contributions 992 of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of 993 APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim 994 Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy 995 Bush of IIJ. 997 Although we are indebted to everyone who has contributed to this 998 architecture, we would like to especially thank Rob Austein for the 999 concept of a manifest, Geoff Huston for the concept of managing 1000 object validity through single-use EE certificate key pairs, and 1001 Richard Barnes for help in preparing an early version of this 1002 document. 1004 11. References 1006 11.1. Normative References 1008 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1009 Requirement Levels", BCP 14, RFC 2119, March 1997. 1011 [RFC 4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1012 Protocol 4 (BGP-4)", RFC 4271, January 2006 1014 [RFC 5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1015 Housley, R., and W. Polk, "Internet X.509 Public Key 1016 Infrastructure Certificate and Certificate Revocation 1017 List (CRL) Profile", RFC 5280, May 2008. 1019 [RFC 5652] Housley, R., "Cryptographic Message Syntax", RFC 5652, 1020 September 2009. 1022 [RFC 3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1023 Addresses and AS Identifiers", RFC 3779, June 2004. 1025 [RES-CERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile 1026 for X.509 PKIX Resource Certificates", draft-ietf-sidr- 1027 res-certs, December 2010. 1029 [ROA-FORM] Lepinski, M., Kent, S., and Kong, D., "A Profile for 1030 Route Origin Authorizations (ROA)", draft-ietf-sidr-roa- 1031 format, February 2011. 1033 [SIGN-OBJ] Chi, A., Kent, S., and Lepinski, M., "Signed Object 1034 Template for the Resource Public Key Infrastructure", 1035 draft-ietf-sidr-signed-object, February 2010. 1037 [MANIFEST] Austein, R., et al., "Manifests for the Resource Public 1038 Key Infrastructure", draft-ietf-sidr-rpki-manifests, 1039 November 2010. 1041 [REPOS] Huston, G., Michaelson, G., and Loomans, R., "A Profile 1042 for Resource Certificate Repository Structure", draft- 1043 ietf-sidr-repos-struct, November 2010. 1045 11.2. Informative References 1047 [KEY-ROLL] Huston, G., Michaelson, G., and Kent, K., "CA Key 1048 Rollover in the RPKI", draft-huston-sidr-keyroll, 1049 December 2010. 1051 [ROA-VALID] Huston, G., Michaelson, G., "Validation of Route 1052 Origination in BGP using the Resource Certificate PKI", 1053 draft-ietf-sidr-roa-validation, November 2010. 1055 [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI 1056 Scheme", RFC 5781, February 2010. 1058 [SIDR-TA] Michaelson, G., Kent, S., and Huston, G., "A Profile for 1059 Trust Anchor Material for the Resource Certificate PKI", 1060 draft-ietf-sidr-ta, May 2010. 1062 [S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway 1063 Protocol (Secure-BGP)", IEEE Journal on Selected Areas in 1064 Communications Vol. 18, No. 4, April 2000. 1066 [soBGP] White, R., "soBGP", May 2005, 1069 [RSYNC] Tridgell, A., "rsync", March 2008, < 1070 http://rsync.samba.org/> 1072 Authors' Addresses 1074 Matt Lepinski 1075 BBN Technologies 1076 10 Moulton St. 1077 Cambridge, MA 02138 1079 Email: mlepinski@bbn.com 1081 Stephen Kent 1082 BBN Technologies 1083 10 Moulton St. 1084 Cambridge, MA 02138 1086 Email: kent@bbn.com