idnits 2.17.1 draft-ietf-sidr-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1354. 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 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 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 (November 18, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 785, but not defined ** Obsolete normative reference: RFC 3280 (ref. '3') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (ref. '4') (Obsoleted by RFC 5652) == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-09 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-01 -- Obsolete informational reference (is this intentional?): RFC 4893 (ref. '11') (Obsoleted by RFC 6793) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 R. Barnes 4 Intended status: Informational BBN Technologies 5 Expires: May 2008 November 18, 2007 7 An Infrastructure to Support Secure Internet Routing 8 draft-ietf-sidr-arch-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on May 18, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes an architecture for an infrastructure to 43 support secure Internet routing. The foundation of this architecture 44 is a public key infrastructure (PKI) that represents the allocation 45 hierarchy of IP address space and Autonomous System Numbers; 46 certificates from this PKI are used to verify signed objects that 47 authorize autonomous systems to originate routes for specified IP 48 address prefixes. The data objects that comprise the PKI, as well as 49 other signed objects necessary for secure routing, are stored and 50 disseminated through a distributed repository system. This document 51 also describes at a high level how this architecture can be used to 52 add security features to common operations such as IP address space 53 allocation and route filter construction. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119 [1]. 61 Table of Contents 63 1. Introduction...................................................3 64 2. PKI for Internet Number Resources..............................4 65 2.1. Role in the overall architecture..........................5 66 2.2. CA Certificates...........................................5 67 2.3. End-Entity (EE) Certificates..............................7 68 2.4. Trust Anchors.............................................8 69 2.5. Default Trust Anchor Considerations.......................8 70 2.6. Representing Early-Registration Transfers (ERX)...........9 71 3. Route Origination Authorizations..............................10 72 3.1. Role in the overall architecture.........................11 73 3.2. Syntax and semantics.....................................11 74 4. Repositories..................................................13 75 4.1. Role in the overall architecture.........................14 76 4.2. Contents and structure...................................14 77 4.3. Access protocols.........................................16 78 4.4. Access control...........................................16 79 5. Manifests.....................................................17 80 5.1. Manifest Syntax..........................................17 81 5.2. Certificate Requests.....................................18 82 5.3. Publication Repositories.................................19 83 5.4. Relying Party processing of a Manifest...................19 84 5.4.1. The nominal good case:..............................20 85 5.4.2. The bad cases:......................................20 86 5.4.3. Warning List........................................21 87 6. Local Cache Maintenance.......................................22 88 7. Common Operations.............................................23 89 7.1. Certificate issuance.....................................23 90 7.2. ROA management...........................................24 91 7.2.1. Single-homed subscribers (without portable allocations) 92 ...........................................................25 93 7.2.2. Multi-homed subscribers.............................25 94 7.2.3. Portable allocations................................26 95 7.3. Route filter construction................................26 96 8. Security Considerations.......................................27 97 9. IANA Considerations...........................................27 98 10. Acknowledgments..............................................28 99 11. References...................................................29 100 11.1. Normative References....................................29 101 11.2. Informative References..................................29 102 Author's Addresses...............................................30 103 Intellectual Property Statement..................................30 104 Disclaimer of Validity...........................................31 106 1. Introduction 108 This document describes an architecture for an infrastructure to 109 support improved security for BGP routing [2] for the Internet. The 110 architecture encompasses three principle elements: 112 . a public key infrastructure (PKI) 114 . digitally-signed routing objects to support routing security 116 . a distributed repository system to hold the PKI objects and the 117 signed routing objects 119 The architecture described by this document supports, at a minimum, 120 two aspects of routing security; it enables an entity to verifiably 121 assert that it is the legitimate holder of a set of IP addresses or a 122 set of Autonomous System (AS) numbers, and it allows the holder of IP 123 address space to explicitly and verifiably authorize one or more ASes 124 to originate routes to that address space. In addition to these 125 initial applications, the infrastructure defined by this architecture 126 also is intended to be able to support security protocols such as S- 127 BGP [8] or soBGP [9]. This architecture is applicable to the routing 128 of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only 129 address families supported by this architecture. Thus, for example, 130 use of this architecture with MPLS labels is beyond the scope of this 131 document. 133 In order to facilitate deployment, the architecture takes advantage 134 of existing technologies and practices. The structure of the PKI 135 element of the architecture corresponds to the existing resource 136 allocation structure. Thus management of this PKI is a natural 137 extension of the resource-management functions of the organizations 138 that are already responsible for IP address and AS number resource 139 allocation. Likewise, existing resource allocation and revocation 140 practices have well-defined correspondents in this architecture. To 141 ease implementation, existing IETF standards are used wherever 142 possible; for example, extensive use is made of the X.509 certificate 143 profile defined by PKIX [3] and the extensions for IP Addresses and 144 AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is 145 used as the syntax for the newly-defined signed objects required by 146 this infrastructure. 148 As noted above, the infrastructure is comprised of three main 149 components: an X.509 PKI in which certificates attest to holdings of 150 IP address space and AS numbers; non-certificate/CRL signed objects 151 (Route Origination Authorizations and manifests) used by the 152 infrastructure; and a distributed repository system that makes all of 153 these signed objects available for use by ISPs in making routing 154 decisions. These three basic components enable several security 155 functions; this document describes how they can be used to improve 156 route filter generation, and to perform several other common 157 operations in such a way as to make them cryptographically 158 verifiable. 160 2. PKI for Internet Number Resources 162 Because the holder of a block IP address space is entitled to define 163 the topological destination of IP datagrams whose destinations fall 164 within that block, decisions about inter-domain routing are 165 inherently based on knowledge the allocation of the IP address space. 166 Thus, a basic function of this architecture is to provide 167 cryptographically verifiable attestations as to these allocations. In 168 current practice, the allocation of IP address is hierarchic. The 169 root of the hierarchy is IANA. Below IANA are five Regional Internet 170 Registries (RIRs), each of which manages address and AS number 171 allocation within a defined geopolitical region. In some regions the 172 third tier of the hierarchy includes National Internet Registries and 173 (NIRs) as well as Local Internet Registries (LIRs) and subscribers 174 with so-called "portable" (provider-independent) allocations. (The 175 term LIR is used in some regions to refer to what other regions 176 define as an ISP. Throughout the rest of this document we will use 177 the term LIR/ISP to simplify references to these entities.) In other 178 regions the third tier consists only of LIRs/ISPs and subscribers 179 with portable allocations. 181 In general, the holder of a set of IP addresses may sub-allocate 182 portions of that set, either to itself (e.g., to a particular unit of 183 the same organization), or to another organization, subject to 184 contractual constraints established by the registries. Because of 185 this structure, IP address allocations can be described naturally by 186 a hierarchic public-key infrastructure, in which each certificate 187 attests to an allocation of IP addresses, and issuance of subordinate 188 certificates corresponds to sub-allocation of IP addresses. The 189 above reasoning holds true for AS number resources as well, with the 190 difference that, by convention, AS numbers may not be sub-allocated 191 except by regional or national registries. Thus allocations of both 192 IP addresses and AS numbers can be expressed by the same PKI. Such a 193 PKI is a central component of this architecture. 195 2.1. Role in the overall architecture 197 Certificates in this PKI are called Resource Certificates, and 198 conform to the certificate profile for such certificates [6]. 199 Resource certificates attest to the allocation by the (certificate) 200 issuer of IP addresses or AS numbers to the subject. They do this by 201 binding the public key contained in the Resource Certificate to the 202 IP addresses or AS numbers included in the certificate's IP Address 203 Delegation or AS Identifier Delegation Extensions, respectively, as 204 defined in RFC 3779 [5]. 206 An important property of this PKI is that certificates do not attest 207 to the identity of the subject. Therefore, the subject names used in 208 certificates are not intended to be "descriptive." That is, this PKI 209 is intended to provide authorization, but not authentication. This is 210 in contrast to most PKIs where the issuer ensures that the 211 descriptive subject name in a certificate is properly associated with 212 the entity that holds the private key corresponding to the public key 213 in the certificate. Because issuers need not verify the right of an 214 entity to use a subject name in a certificate, they avoid the costs 215 and liabilities of such verification. This makes it easier for these 216 entities to take on the additional role of CA. 218 Most of the certificates in the PKI assert the basic facts on which 219 the rest of the infrastructure operates. CA certificates within the 220 PKI attest to IP address space and AS number holdings. End-entity 221 (EE) certificates are issued by resource holder CAs to delegate the 222 authority attested by their allocation certificates. The primary use 223 for EE certificates is the validation of Route Origination 224 Authorizations (ROAs). Additionally, signed objects called manifests 225 will be used to help ensure the integrity of the repository system, 226 and the signature on each manifest will be verified via an EE 227 certificate. 229 2.2. CA Certificates 231 Any holder of Internet resources who is authorized to sub-allocate 232 them must be able to issue Resource Certificates to correspond to 233 these sub-allocations. Thus, for example, CA certificates will be 234 associated with each of the RIRs, NIRs, and LIRs/ISPs. A CA 235 certificate also is required to enable a resource holder to issue 236 ROAs, because it must issue the corresponding end-entity certificate 237 used to validate each ROA. Thus some subscribers also will need to 238 have CA certificates for their allocations, e.g., subscribers with 239 portable allocations, to enable them to issue ROAs. (A subscriber who 240 is not multi-homed, whose allocation comes from an LIR/ISP, and who 241 has not moved to a different LIR/ISP, need not be represented in the 242 PKI. Moreover, a multi-homed subscriber with an allocation from an 243 LIR/ISP may or may not need to be explicitly represented, as 244 discussed in Section 6.2.2) 246 Unlike in most PKIs, the distinguished name of the subject in a CA 247 certificate is chosen by the certificate issuer. If the subject of a 248 certificate is an RIR, then the distinguished name of the subject 249 will be chosen to convey the identity of the registry and should 250 consist of (a subset of) the following attributes: country, 251 organization, organizational unit, and common name. For example, an 252 appropriate subject name for the APNIC RIR might be: 254 . Country: AU 256 . Organization: Asia Pacific Network Information Centre 258 . Common Name: APNIC Resource Certification Authority 260 If the subject of a certificate is not an RIR, (e.g., the subject is 261 a NIR, or LIR/ISP) the distinguished name MUST consist only of the 262 common name attribute and must not attempt to convey the identity of 263 the subject in a descriptive fashion. Additionally, the subject's 264 distinguished name must be unique among all certificates issued by a 265 given authority. In this PKI, the certificate issuer, being an 266 internet registry or LIR/ISP, is not in the business of verifying the 267 legal right of the subject to assert a particular identity. 268 Therefore, selecting a distinguished name that does not convey the 269 identity of the subject in a descriptive fashion minimizes the 270 opportunity for the subject to misuse the certificate to assert an 271 identity, and thus minimizes the legal liability of the issuer. Since 272 all CA certificates are issued to subjects with whom the issuer has 273 an existing relationship, it is recommended that the issuer select a 274 subject name that enables the issuer to easily link the certificate 275 to existing database records associated with the subject. For 276 example, an authority may use internal database keys or subscriber 277 IDs as the subject common name in issued certificates. 279 Each Resource Certificate attests to an allocation of resources to 280 its holder, so entities that have allocations from multiple sources 281 will have multiple CA certificates. A CA also may issue distinct 282 certificates for each distinct allocation to the same entity, if the 283 CA and the resource holder agree that such an arrangement will 284 facilitate management and use of the certificates. For example, an 285 LIR/ISP may have several certificates issued to it by one registry, 286 each describing a distinct set of address blocks, because the LIR/ISP 287 desires to treat the allocations as separate. 289 2.3. End-Entity (EE) Certificates 291 The private key corresponding to public key contained in an EE 292 certificate is not used to sign other certificates in a PKI. The 293 primary function of end-entity certificates in this PKI is the 294 verification of signed objects that relate to the usage of the 295 resources described in the certificate, e.g., ROAs and manifests. 296 For ROAs and manifests there will be a one-to-one correspondence 297 between end-entity certificates and signed objects, i.e., the private 298 key corresponding to each end-entity certificate is used to sign 299 exactly one object, and each object is signed with only one key. 300 This property allows the PKI to be used to revoke these signed 301 objects, rather than creating a new revocation mechanism. When the 302 end-entity certificate used to sign an object has been revoked, the 303 signature on that object (and any corresponding assertions) will be 304 considered invalid, so a signed object can be effectively revoked by 305 revoking the end-entity certificate used to sign it. 307 A secondary advantage to this one-to-one correspondence is that the 308 private key corresponding to the public key in a certificate is used 309 exactly once in its lifetime, and thus can be destroyed after it has 310 been used to sign its one object. This fact should simplify key 311 management, since there is no requirement to protect these private 312 keys for an extended period of time. 314 Although this document defines only two uses for end-entity 315 certificates, additional uses will likely be defined in the future. 316 For example, end-entity certificates could be used as a more general 317 authorization for their subjects to act on behalf of the holder of 318 the specified resources. This could facilitate authentication of 319 inter-ISP interactions, or authentication of interactions with the 320 repository system. These additional uses for end-entity certificates 321 may require retention of the corresponding private keys, even though 322 this is not required for the private keys associated with end-entity 323 certificates keys used for verification of ROAs and manifests, as 324 described above. 326 2.4. Trust Anchors 328 In any PKI, each relying party (RP) is free to choose its own set of 329 trust anchors. This general property of PKIs applies here as well. 330 There is an extant IP address space and AS number allocation 331 hierarchy. IANA is the obvious candidate to be the TA, but 332 operational considerations may argue for a multi-TA PKI, e.g., one in 333 which both IANA and the RIRs form a default set of trust anchors. 334 Nonetheless, every relying party is free to choose a different set of 335 trust anchors to use for certificate validation operations. 337 For example, an RP (e.g., an LIR/ISP) could create a self-signed 338 certificate to which all address space and/or all AS numbers are 339 assigned, and for which the RP knows the corresponding private key. 340 The RP could then issue certificates under this trust anchor to 341 whatever entities in the PKI it wishes, with the result that the 342 certificate paths terminating at this locally-installed trust anchor 343 will satisfy the RFC 3779 validation requirements. 345 An RP who elects to create and manage its own set of trust anchors 346 may fail to detect allocation errors that arise under such 347 circumstances, but the resulting vulnerability is local to the RP. 349 2.5. Default Trust Anchor Considerations 351 IANA forms the root of the extant IP address space and AS number 352 allocation hierarchy. Therefore, it is natural to consider a model in 353 which most relying parties have as their single trust anchor a self- 354 signed IANA certificate whose RFC 3779 extensions specify the 355 entirety of the AS number and IP address spaces. 357 As an example of such model, consider the use of private IP address 358 space (i.e., 10/8, 172.16/12, and 192.168/16 in IPv4 and FC00::/7 in 359 IPv6). IANA could issue a CA certificate for these blocks of private 360 address space and then destroy the private key corresponding to the 361 public key in the certificate. In this way, any relying party who 362 configured IANA as their sole trust anchor would automatically reject 363 any ROA containing private addresses, appropriate behavior with 364 regard to routing in the public Internet. On the other hand, such an 365 approach would not interfere with an organization that wishes to use 366 private address space in conjunction with BGP and this PKI 367 technology. Such an organization could configure its relying parties 368 with an additional, local trust anchor that issues certificates for 369 private addresses used within the organization. In this manner, BGP 370 advertisements for these private addresses would be accepted within 371 the organization but would be rejected if mistakenly sent outside the 372 private address space context in question. 374 In the DNSSEC context, IANA (as the root of the DNS) is already 375 experimenting with the operational procedures needed to digitally 376 sign the root zone. This is very much analogous to the role it would 377 play if it were to act as the default trust anchor for the RPKI, even 378 though DNSSEC does not make use of X.509 certificates. Nonetheless, 379 it is appropriate consider alternative default trust anchor models, 380 if IANA does not act in this capacity. This motivates the 381 consideration of alternative default trust anchor options for RPKI 382 relying parties. 384 Essentially all allocated IP address and AS number resources are sub- 385 allocated by IANA to one of the five RIRs. Therefore, one could 386 consider a model in which the default trust anchors are a set of five 387 self-signed certificates, one for each RIR. There are two 388 difficulties that such an approach must overcome. 390 The first difficulty is that IANA retains authority for 44 /8 391 prefixes in IPv4 and a /26 prefix in IPv6. Therefore, any approach 392 that recommends the RIRs as default trust anchors will also require 393 as a default trust anchor an IANA certificate who's RFC 3779 394 extensions correspond to this address space. Additionally, there are 395 about 49 /8 prefixes containing legacy allocations that are not each 396 allocated to a single RIR. Currently, for the purpose of 397 administering reverse DNS zones, each of these prefixes is 398 administered by a single RIR who delegates authority for allocations 399 within the prefix as appropriate. This existing arrangement could be 400 used as the template for the assignment of administrative 401 responsibility for the certification of these address blocks in the 402 RPKI. Such an arrangement would in no way alter the administrative 403 arrangements and the associated policies that apply to the individual 404 legacy allocations that have been made from these address blocks. 406 The second difficulty is that the resource allocations of the RIRs 407 may change several times a year. Typically in a PKI, trust anchors 408 are quite long-lived and distributed to relying parties via some out- 409 of-band mechanism. However, such out-of-band distribution of new 410 trust anchors is not feasible if the allocations change every few 411 months. Therefore, any approach that recommends the RIRs as default 412 trust anchors must provide an in-band mechanism for managing the 413 changes that will occur in the RIR allocations (as expressed via RFC 414 3779 extensions). 416 2.6. Representing Early-Registration Transfers (ERX) 418 Currently, IANA allocates IPv4 address space to the RIRs at the level 419 of /8 prefixes. However, there exist allocations that cross these RIR 420 boundaries. For example, A LACNIC customer may have an allocation 421 that falls within a /8 prefix administered by ARIN. Therefore, the 422 resource PKI must be able to represent such transfers from one RIR to 423 another in a manner that permits the validation of certificates with 424 RFC 3779 extensions. 426 --------------------------------- 427 | | 428 | LACNIC Administrative | 429 | Boundary | 430 | | 431 ---------- | ---------- | ---------- 432 | ARIN | | | LACNIC | | | RIPE | 433 | ROOT | | | ROOT | | | ROOT | 434 ---------- | ---------- | ---------- 435 \ | | / 436 ------------ ------------ 437 | \ / | 438 | ---------- ---------- | 439 | | LACNIC | | LACNIC | | 440 | | CA | | CA | | 441 | ---------- ---------- | 442 | | 443 --------------------------------- 445 FIGURE 1: Representing EXR 447 To represent such transfers, RIRs will need to manage multiple CA 448 certificates, each with distinct public (and corresponding private) 449 keys. Each RIR will have a single "root" certificate (e.g., a self- 450 signed certificate or a certificate signed by IANA, see Section 2.5), 451 plus one additional CA certificate for each RIR from which it 452 receives a transfer. Each of these additional CA certificates will be 453 issued under the "root" certificate of the RIR from which the 454 transfer is received. This means that although the certificate is 455 bound to the RIR that receives the transfer, for the purposes of 456 certificate path construction and validation, it does not appear 457 under that RIR's "root" certificate (see Figure 1). 459 3. Route Origination Authorizations 461 The information on IP address allocation provided by the PKI is not, 462 in itself, sufficient to guide routing decisions. In particular, BGP 463 is based on the assumption that the AS that originates routes for a 464 particular prefix is authorized to do so by the holder of that prefix 465 (or an address block encompassing the prefix); the PKI contains no 466 information about these authorizations. A Route Origination 467 Authorization (ROA) makes such authorization explicit, allowing a 468 holder of address space to create an object that explicitly and 469 verifiably asserts that an AS is authorized originate routes to 470 prefixes. 472 3.1. Role in the overall architecture 474 A ROA is an attestation that the holder of a set of prefixes has 475 authorized an autonomous system to originate routes for those 476 prefixes. A ROA is structured according to the format described in 477 [7]. The validity of this authorization depends on the signer of the 478 ROA being the holder of the prefix(es) in the ROA; this fact is 479 asserted by an end-entity certificate from the PKI, whose 480 corresponding private key is used to sign the ROA. 482 ROAs may be used by relying parties to verify that the AS that 483 originates a route for a given IP address prefix is authorized by the 484 holder of that prefix to originate such a route. For example, an ISP 485 might use ROAs as inputs to route filter construction for use by its 486 BGP routers. These filters would prevent importation of any route in 487 which the origin AS of the AS-PATH attribute is not an AS that is 488 authorized (via a valid ROA) to originate the route. (See Section 6.3 489 for more details.) 491 Initially, the repository system will be the primary mechanism for 492 disseminating ROAs, since these repositories will hold the 493 certificates and CRLs needed to verify ROAs. In addition, ROAs also 494 could be distributed in BGP UPDATE messages or via other 495 communication paths, if needed to meet timeliness requirements. 497 3.2. Syntax and semantics 499 A ROA constitutes an explicit authorization for a single AS to 500 originate routes to one or more prefixes, and is signed by the holder 501 of those prefixes. Syntactically, a ROA is a CMS signed-data object 502 whose content is defined as follows: 504 RouteOriginAttestation ::= SEQUENCE { 505 version [0] INTEGER DEFAULT 0, 506 asID ASID, 507 exactMatch BOOLEAN, 508 ipAddrBlocks ROAIPAddrBlocks } 510 ASID ::= INTEGER 512 ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily 514 ROAIPAddressFamily ::= SEQUENCE { 515 addressFamily OCTET STRING (SIZE (2..3)), 516 addresses SEQUENCE OF IPAddress } 517 -- Only two address families are allowed: IPv4 and IPv6 519 IPAddress ::= BIT STRING 521 That is, the signed data within the ROA consists of a version number, 522 the AS number that is being authorized, and a list of IP prefixes to 523 which the AS is authorized to originate routes. If the exactMatch 524 flag is set to TRUE, then the AS is authorized to originate routes 525 only for the specific prefix(es) listed in the ROA. If the exactMatch 526 flag is set to FALSE, the AS is authorized to originate routes to the 527 prefix(es) in the ROA as well as any longer (more specific) prefixes. 529 Note that a ROA contains only a single AS number. Thus, if an ISP has 530 multiple AS numbers that will be authorized to originate routes to 531 the prefix(es) in the ROA, an address space holder will need to issue 532 multiple ROAs to authorize the ISP to originate routes from any of 533 these ASes. 535 A ROA is signed using the private key corresponding to the public key 536 in an end-entity certificate in the PKI. In order for a ROA to be 537 valid, its corresponding end-entity (EE) certificate must be valid 538 and the IP address prefixes of the ROA must exactly match the IP 539 address prefix(es) specified in the EE certificate's RFC 3779 540 extension. Therefore, the validity interval of the ROA is implicitly 541 the validity interval of its corresponding certificate. A ROA is 542 revoked by revoking the corresponding EE certificate. There is no 543 independent method of invoking a ROA. One might worry that this 544 revocation model could lead to long CRLs for the CA certification 545 that is signing the EE certificates. However, routing announcements 546 on the public internet are generally quite long lived. Therefore, as 547 long as the EE certificates used to verify a ROA are given a validity 548 interval of several months, the likelihood that many ROAs would need 549 to revoked within time that is quite low. 551 --------- --------- 552 | RIR | | NIR | 553 | CA | | CA | 554 --------- --------- 555 | | 556 | | 557 | | 558 --------- --------- 559 | ISP | | ISP | 560 | CA 1 | | CA 2 | 561 --------- --------- 562 | \ | 563 | ----- | 564 | \ | 565 ---------- ---------- ---------- 566 | ISP | | ISP | | ISP | 567 | EE 1a | | EE 1b | | EE 2 | 568 ---------- ---------- ---------- 569 | | | 570 | | | 571 | | | 572 ---------- ---------- ---------- 573 | ROA 1a | | ROA 1b | | ROA 2 | 574 ---------- ---------- ---------- 576 FIGURE 2: This figure illustrates an ISP with allocations from two 577 sources (and RIR and an NIR). It needs two CA certificates due to RFC 578 3779 rules. 580 Because each ROA is associated with a single end-entity certificate, 581 the set of IP prefixes contained in a ROA must be drawn from an 582 allocation by a single source, i.e., a ROA cannot combine allocations 583 from multiple sources. Address space holders who have allocations 584 from multiple sources, and who wish to authorize an AS to originate 585 routes for these allocations, must issue multiple ROAs to the AS. 587 4. Repositories 589 Initially, an LIR/ISP will make use of the resource PKI by acquiring 590 and validating every ROA, to create a table of the prefixes for which 591 each AS is authorized to originate routes. To validate all ROAs, an 592 LIR/ISP needs to acquire all the certificates and CRLs. The primary 593 function of the distributed repository system described here is to 594 store these signed objects and to make them available for download by 595 LIRs/ISPs. The digital signatures on all objects in the repository 596 ensure that unauthorized modification of valid objects is detectable 597 by relying parties. Additionally, the repository system uses 598 manifests (see Section 5) to ensure that relying parties can detect 599 the deletion of valid objects and the insertion of out of date, valid 600 signed objects. 602 The repository system is also a point of enforcement for access 603 controls for the signed objects stored in it, e.g., ensuring that 604 records related to an allocation of resources can be manipulated only 605 by authorized parties. The use access controls prevents denial of 606 service attacks based on deletion of or tampering to repository 607 objects. Indeed, although relying parties can detect tampering with 608 objects in the repository, it is preferable that the repository 609 system prevent such unauthorized modifications to the greatest extent 610 possible. 612 4.1. Role in the overall architecture 614 The repository system is the central clearing-house for all signed 615 objects that must be globally accessible to relying parties. When 616 certificates and CRLs are created, they are uploaded to this 617 repository, and then downloaded for use by relying parties (primarily 618 LIRs/ISPs). ROAs and manifests are additional examples of such 619 objects, but other types of signed objects may be added to this 620 architecture in the future. This document briefly describes the way 621 signed objects (certificates, CRLs, ROAs and manifests) are managed 622 in the repository system. As other types of signed objects are added 623 to the repository system it will be necessary to modify the 624 description, but it is anticipated that most of the design principles 625 will still apply. The repository system is described in detail in 626 [??]. 628 4.2. Contents and structure 630 Although there is a single repository system that is accessed by 631 relying parties, it is comprised of multiple databases. These 632 databases will be distributed among registries (RIRs, NIRs, 633 LIRs/ISPs). At a minimum, the database operated by each registry will 634 contain all CA and EE certificates, CRLs, and manifests signed by the 635 CA(s) associated with that registry. Repositories operated by 636 LIRs/ISPs also will contain ROAs. Registries are encouraged maintain 637 copies of repository data from their customers, and their customer's 638 customers (etc.), to facilitate retrieval of the whole repository 639 contents by relying parties. Ideally, each RIR will hold PKI data 640 from all entities within its geopolitical scope. 642 For every certificate in the PKI, there will be a corresponding file 643 system directory in the repository that is the authoritative 644 publication point for all objects (certificates, CRLs, ROAs and 645 manifests) verifiable via this certificate. A certificate's Subject 646 Information Authority (SIA) extension provides a URI that references 647 this directory. Additionally, a certificate's Authority Information 648 Authority (AIA) extension contains a URI that references the 649 authoritative location for the CA certificate under which the given 650 certificate was issued. That is, if certificate A is used to verify 651 certificate B, then the AIA extension of certificate B points to 652 certificate A, and the SIA extension of certificate A points to a 653 directory containing certificate B (see Figure 2). 655 ---------- 656 ---------->| Cert A |<----- 657 | | CRLDP | | ----------- 658 | | AIA | | --->| A's CRL |<-- 659 | --------+- SIA | | | ----------- | 660 | | ---------- | | | 661 | | | | | 662 | | ----+----- | 663 | | | | | 664 | | ----------------|---|------------------ | 665 | | | | | | | 666 | -->| ---------- | | ---------- | | 667 | | | Cert B | | | | Cert C | | | 668 | | | CRLDP -+--- | | CRLDP -+----|---- 669 ----------+- AIA | ----+- AIA | | 670 | | SIA | | SIA | | 671 | ---------- ---------- | 672 | | 673 --------------------------------------- 675 FIGURE 3: In this example, certificates B and C are issued under 676 certificate A. Therefore, the AIA extensions of certificates B and C 677 point to A, and the SIA extension of certificate A points to the 678 directory containing certificates B and C. 680 If a CA certificate is reissued with the same public key, it should 681 not be necessary to reissue (with an updated AIA URI) all 682 certificates signed by the certificate being reissued. Therefore, a 683 certification authority SHOULD use a persistent URI naming scheme for 684 issued certificates. That is, reissued certificates should use the 685 same publication point as previously issued certificates having the 686 same subject and public key, and should overwrite such certificates. 688 4.3. Access protocols 690 Repository operators will choose one or more access protocols that 691 relying parties can use to access the repository system. These 692 protocols will be used by numerous participants in the infrastructure 693 (e.g., all registries, ISPs, and multi-homed subscribers) to maintain 694 their respective portions of it. In order to support these 695 activities, certain basic functionality is required of the suite of 696 access protocols, as described below. No single access protocol need 697 implement all of these functions (although this may be the case), but 698 each function must be implemented by at least one access protocol. 700 Download: Access protocols MUST support the bulk download of 701 repository contents and subsequent download of changes to the 702 downloaded contents, since this will be the most common way in which 703 relying parties interact with the repository system. Other types of 704 download interactions (e.g., download of a single object) MAY also be 705 supported. 707 Upload/change/delete: Access protocols MUST also support mechanisms 708 for the issuers of certificates, CRLs, and other signed objects to 709 add them to the repository, and to remove them. Mechanisms for 710 modifying objects in the repository MAY also be provided. All access 711 protocols that allow modification to the repository (through 712 addition, deletion, or modification of its contents) MUST support 713 verification of the authorization of the entity performing the 714 modification, so that appropriate access controls can be applied (see 715 Section 4.4). 717 Current efforts to implement a repository system use RSYNC [10] as 718 the single access protocol. RSYNC, as used in this implementation, 719 provides all of the above functionality. A document specifying the 720 conventions for use of RSYNC in the PKI will be prepared. 722 4.4. Access control 724 In order to maintain the integrity of information in the repository, 725 controls must be put in place to prevent addition, deletion, or 726 modification of objects in the repository by unauthorized parties. 727 The identities of parties attempting to make such changes can be 728 authenticated through the relevant access protocols. Although 729 specific access control policies are subject to the local control of 730 repository operators, it is recommended that repositories allow only 731 the issuers of signed objects to add, delete, or modify them. 732 Alternatively, it may be advantageous in the future to define a 733 formal delegation mechanism to allow resource holders to authorize 734 other parties to act on their behalf, as suggested in Section 2.3 735 above. 737 5. Manifests 739 A manifest is a signed object listing of all of the signed objects 740 issued by an authority responsible for a publication in the 741 repository system. For each certificate, CRL, or ROA issued by the 742 authority, the manifest contains both the name of the file containing 743 the object, and a hash of the file content. 745 As with ROAs, a manifest is signed by a private key, for which the 746 corresponding public key appears in an end-entity certificate. This 747 EE certificate, in turn, is signed by the CA in question. The EE 748 certificate private key may be used to sign one for more manifests. 749 If the private key is used to sign only a single manifest, then the 750 manifest can be revoked by revoking the EE certificate. In such a 751 case, to avoid needless CRL growth, the EE certificate used to 752 validate a manifest SHOULD expire at the same time that the manifest 753 expires, i.e., the notAfter value in the EE certificate should be the 754 same as the nextUpdate value in the manifest. If a private key 755 corresponding to a the public key in an EE certificate is used to 756 sign multiple (sequential) manifests for the CA in question, then 757 there is no revocation mechanism for these manifests. In such a case 758 a relying party will treat a manifest as valid until either (a) he 759 obtains a new manifest for the same CA having a higher 760 manifestNumber; or (b) the nextUpdate time is reached. 762 This EE certificate has an SIA extension access description field 763 with an accessMethod OID value of id-ad-signedobjectrepository where 764 the associated accessLocation references the publication point of the 765 manifest as an object URL. 767 5.1. Manifest Syntax 769 Syntactically, a manifest is a CMS signed-data object. As it is 770 intended that the manifest will be used in the context of assembling 771 a local copy of the entire RPKI repository, then the necessary 772 information to validate the certificate path for the manifest's 773 signature will be at hand for the relying party, thus duplication of 774 superior certificates and of CRLs in the CMS SignedData of the 775 manifest is not required. Only the EE certificate needed to directly 776 verify the signature on the manifest MUST be included in the CMS 777 SignedData; other certificates MUST NOT be included and CRLs MUST NOT 778 be included. 780 The CMS timestamp field MUST be included in the CMS SignedData. 782 The content of the CMS signed-data object is defined as follows: 784 Manifest ::= SEQUENCE { 785 version [0] INTEGER DEFAULT 0, 786 manifestNumber INTEGER, 787 thisUpdate GeneralizedTime, 788 nextUpdate GeneralizedTime, 789 fileHashAlg OBJECT IDENTIFIER, 790 fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash 791 } 793 FileAndHash ::=SEQUENCE { 794 file IA5String 795 hash BIT STRING 796 } 798 The manifestNumber field is a sequence number that is incremented 799 each time a manifest is issued by a authority. The thisUpdate field 800 contains the time when the manifest was created and the nextUpdate 801 field contains the time at which the next scheduled manifest will be 802 issued. If the authority alters any of its items in the repository, 803 then it MUST issue a new manifest before nextUpdate. A manifest is 804 valid until the time specified in nextUpdate or until a manifest is 805 issued with a greater manifest number, whichever comes first. (Note 806 that when an EE certificate is used to sign only a single manifest, 807 whenever the authority issues the new manifest, the CA MUST also 808 issue a new CRL which includes the EE certificate corresponding to 809 the old manifest. The revoked EE certificate for the old manifest 810 will be removed from the CRL when it expires, thus this procedure 811 ought not result in significant CRLs growth.) 813 The fileHashAlg field contains the OID of the hash algorithm used to 814 hash the files that the authority has placed into the repository. The 815 mandatory to implement hash algorithm is SHA-256 and its OID is 816 2.16.840.1.101.3.4.2.1. [12] 818 The fileList field contains a sequence of FileAndHash pairs, one for 819 each currently valid certificate, CRL and ROA that has been issued by 820 the authority. Each of the FileAndHash pairs contains the name of the 821 file in the repository that contains the object in question, and a 822 hash of the file's contents. 824 5.2. Certificate Requests 826 A request for a CA certificate MUST include in the SIA of the request 827 an accessMethod OID of id-ad-manifest, where the associated 828 accessLocation refers to the subject's published manifest object as 829 an object URL. The manifest refers to the list of all products of 830 this CA certificate (except of course the manifest itself) that are 831 published at the publication point referred to by the SIA repository 832 pointer. This implies that the name of the manifest object is known 833 in advance, requiring the manifest object name to be a PURL, i.e., a 834 URL that is unchanged across manifest generation cycles. 836 Certificate requests for EE certificates MUST include in the SIA of 837 the request an access method OID of id-ad-manifest, where the 838 associated access location refers to the publication point of the 839 object verified using this EE certificate. 841 This implies that all certificate issuance requests where there is an 842 SIA extension present should include the id-ad-manifest access method 843 and the associated access location in the request, and the issuer 844 should honour these values in the issued certificate. 846 5.3. Publication Repositories 848 The RPKI publication directory model requires that every publication 849 point be associated with a CA, and be non-empty. Upon creation of the 850 publication repository, the CA MUST create an manifest. The manifest 851 will contain at least one entry, the CRL issued by the CA. 853 For a CA-issuer who is digitally signing documents and publishing 854 these signed objects, the EE certifate used to verify the signing of 855 an object would use the id-ad-manifest SIA access method to refer to 856 the signed object itself. If the signing format is CMS and the EE 857 certificate is attached to the signed document, then there is no 858 requirement to publish the EE cert in the publication repository of 859 the CA. On the other hand, of the CA wants to ensure that relying 860 parties can assure themselves that they have the complete collection 861 of signed objects then publishing the EE cert in the CA's publication 862 repository would be sufficient. 864 5.4. Relying Party processing of a Manifest 866 In this section, we describe the recommended behavior of a relying 867 party when processing a manifest. We begin by describing the 868 scenario where the relying party is able to successfully validate a 869 manifest the corresponds to the contents of the repository. We then 870 describe the recommended behavior in the various cases where the 871 relying party is unable to validate such a manifest. 873 5.4.1. The nominal good case: 875 A manifest is present in the repository, is current (i.e., the 876 current time is bounded by the manifest validity interval), and its 877 signature can be verified. All files listed in the manifest are found 878 in the repository and the hashes match. Any files in the repository 879 that are NOT listed in the manifest but that validate anyway SHOUD be 880 ignored (since they could be older instances of objects covered by 881 the manifest). 883 5.4.2. The bad cases: 885 1. No manifest is found in the repository at the publication point. 886 In this case, the relying party cannot use the manifest in question. 888 a. If the relying party has a prior manifest for this publication 889 point, he should use most recent, verified manifest for the 890 publication point in question and generate warning A. 892 b. If no prior manifest for this publication point is available, 893 there is no basis for detecting missing files, so just process 894 certificate, CRL, and ROA files and generate warning B. 896 2. The Signature on manifest fetched from the repository cannot be 897 verified (or the format is bad). In this case, the relying party 898 cannot use the manifest in question. 900 a. If the relying party has a prior manifest for this publication 901 point, he should use most recent, verified manifest for the 902 publication point in question and generate warning A. 904 b. If no prior manifest for this publication point is available, 905 there is no basis for detecting missing files, so he should just 906 process certificate, CRL, and ROA files and generate warning B. 908 3. The manifest is present and current and its signature can be 909 verified using a matching EE certificate 911 a. If the EE certificate is valid (current and not revoked) and 912 all files listed in the manifest are found in the repository and the 913 hashes match, then the relying party should use the manifest as in 914 Section 5. 916 b. If the EE certificate is valid and one or more files listed in 917 the manifest have hashes that do not match the files in the 918 repository with the indicates names, then the corresponding files are 919 likely to be old and intended to be replaced, and thus SHOULD NOT be 920 used. The relying party should generate Warning C. 922 c. If the EE certificate is valid and one or more files listed in 923 the manifest are missing, the relying party should Generate Warning 924 D. 926 d. If the EE certificate is expired. (this says the issuer of the 927 manifest screwed up!), the relying party should generate warning E, 928 but proceed with processing. 930 e. If the EE certificate is revoked but not expired, then the 931 manifest SHOULD be ignored. The relying party should generate warning 932 F and proceed with processing as if no manifest is available (since 933 the CA explicitly revoked the certificate for the manifest.) 935 4. The manifest is present but expired. If the signature cannot be 936 verified, treat as case 1/2. If the manifest signature can be 937 verified using a matching EE certificate: 939 a. If the EE certificate is valid (current and not revoked), then 940 generate warning A and proceed. 942 b. If the EE certificate is expired. (this says the issuer of the 943 manifest screwed up!), then generate warning G and proceed. 945 c. If EE certificate is revoked but not expired, the manifest 946 SHOULD be ignored. Generate warning F and proceed with processing as 947 if no manifest is available (since the CA explicitly revoked the 948 certificate for the manifest.) 950 5.4.3. Warning List 952 Warning A: A current manifest is not available for . 953 A older manifest for this publication point will be used, but there 954 may be undetected deletions from the publication point. 956 Warning B: No manifest is available for , and thus 957 there may have been undetected deletions from the publication point. 959 Warning C: The following files at appear to be 960 SUPERCEDED and are NOT being processed. 962 Warning D: The following files that should have been present in the 963 repository at , are missing . This 964 indicates an attack against this publication point, or the 965 repository, or an error by the publisher. 967 Warning E: EE certificate for manifest verification for is expired. This indicates an error by the publisher, but 969 processing for this publication point will proceed using the current 970 manifest. 972 Warning F: The EE certificate for has been revoked. 973 The manifest will be ignored and all files found at this publication 974 point will be processed. 976 Warning G: EE certificate for manifest verification for is expired. This indicates an error by the publisher, but 978 processing for this publication point will proceed using the most 979 recent (but expired) manifest. 981 6. Local Cache Maintenance 983 In order to utilize signed objects issued under this PKI (e.g. for 984 route filter construction, see Section 6.3), a relying party must 985 first obtain a local copy of the valid EE certificates for the PKI. 986 To do so, the relying party performs the following steps: 988 1. Query the registry system to obtain a copy of all certificates, 989 manifests and CRLs issued under the PKI. 991 2. For each CA certificate in the PKI, verify the signature on the 992 corresponding manifest. Additionally, verify that the current 993 time is earlier than the time indicated in the nextUpdate field 994 of the manifest. 996 3. For each manifest, verify that certificates and CRLs issued 997 under the corresponding CA certificate match the hash values 998 contained in the manifest. If the hash values do not match, use 999 an out-of-band mechanism to notify the appropriate repository 1000 administrator that the repository data has been corrupted. 1002 4. Validate each EE certificate by constructing and verifying a 1003 certification path for the certificate (including checking 1004 relevant CRLs) to the locally configured set of TAs. (See [6] 1005 for more details.) 1007 Note that when a relying party performs these operations regularly, 1008 it is more efficient for the relying party to request from the 1009 repository system only those objects that have changed since the 1010 relying party last updated its local cache. Note also that by 1011 checking all issued objects against the appropriate manifest, the 1012 relying party can be certain that it is not missing an updated 1013 version of any object. 1015 7. Common Operations 1017 Creating and maintaining the infrastructure described above will 1018 entail additional operations as "side effects" of normal resource 1019 allocation and routing authorization procedures. For example, a 1020 subscriber with "portable" address space who entes a relationship 1021 with an ISP will need to issue one or more ROAs identifying that ISP, 1022 in addition to conducting any other necessary technical or business 1023 procedures. The current primary use of this infrastructure is for 1024 route filter construction; using ROAs, route filters can be 1025 constructed in an automated fashion with high assurance that the 1026 holder of the advertised prefix has authorized the first-hop AS to 1027 originate an advertised route. 1029 7.1. Certificate issuance 1031 There are several operational scenarios that require certificates to 1032 be issued. Any allocation that may be sub-allocated requires a CA 1033 certificate, e.g., so that certificates can be issued as necessary 1034 for the sub-allocations. Holders of "portable" address allocations 1035 also must have certificates, so that a ROA can be issued to each ISP 1036 that is authorized to originate a route to the allocation (since the 1037 allocation does not come from any ISP). Additionally, multi-homed 1038 subscribers may require certificates for their allocations if they 1039 intend to issue the ROAs for their allocations (see Section 6.2.2). 1040 Other holders of resources need not be issued CA certificates within 1041 the PKI. 1043 In the long run, a resource holder will not request resource 1044 certificates, but rather receive a certificate as a side effect of 1045 the allocation process for the resource. However, initial deployment 1046 of the RPKI will entail issuance of certificates to existing resource 1047 holders as an explicit event. Note that in all cases, the authority 1048 issuing a CA certificate will be the entity who allocates resources 1049 to the subject. This differs from most PKIs in which a subject can 1050 request a certificate from any certification authority. 1052 If a resource holder receives multiple allocations over time, it may 1053 accrue a collection of resource certificates to attest to them. If a 1054 resource holder receives multiple allocations from the same source, 1055 the set of resource certificates may be combined into a single 1056 resource certificate, if both the issuer and the resource holder 1057 agree. This is effected by consolidating the IP Address Delegation 1058 and AS Identifier Delegation Extensions into a single extension (of 1059 each type) in a new certificate. However, if the certificates for 1060 these allocations contain different validity intervals, creating a 1061 certificate that combines them might create problems, and thus is NOT 1062 RECOMMENDED. 1064 If a resource holder's allocations come from different sources, they 1065 will be signed by different CAs, and cannot be combined. When a set 1066 of resources is no longer allocated to a resource holder, any 1067 certificates attesting to such an allocation MUST be revoked. A 1068 resource holder SHOULD NOT to use the same public key in multiple CA 1069 certificates that are issued by the same or differing authorities, as 1070 reuse of a key pair complicates path construction. Note that since 1071 the subject's distinguished name is chosen by the issuer, a subject 1072 who receives allocations from two sources generally will receive 1073 certificates with different subject names. 1075 7.2. ROA management 1077 Whenever a holder of IP address space wants to authorize an AS to 1078 originate routes for a prefix within his holdings, he MUST issue an 1079 end-entity certificate containing that prefix in an IP Address 1080 Delegation extension. He then uses the corresponding private key to 1081 sign a ROA containing the designated prefix and the AS number for the 1082 AS. The resource holder MAY include more than one prefix in the EE 1083 certificate and corresponding ROA if desired. As a prerequisite, 1084 then, any address holder that issues ROAs for a prefix must have a 1085 resource certificate for an allocation containing that prefix. The 1086 standard procedure for issuing a ROA is as follows: 1088 1. Create an end-entity certificate containing the prefix(es) to be 1089 authorized in the ROA. 1091 2. Construct the payload of the ROA, including the prefixes in the 1092 end-entity certificate and the AS number to be authorized. 1094 3. Sign the ROA using the private key corresponding to the end- 1095 entity certificate (the ROA is comprised of the payload 1096 encapsulated in a CMS signed message [7]). 1098 4. Upload the end-entity certificate and the ROA to the repository 1099 system. 1101 The standard procedure for revoking a ROA is to revoke the 1102 corresponding end-entity certificate by creating an appropriate CRL 1103 and uploading it to the repository system. The revoked ROA and end- 1104 entity certificate SHOULD BE removed from the repository system. 1106 7.2.1. Single-homed subscribers (without portable allocations) 1108 In BGP, a single-homed subscriber with a non-portable allocation does 1109 not need to explicitly authorize routes to be originated for the 1110 prefix(es) it is using, since its ISP will already advertise a more 1111 general prefix and route traffic for the subscriber's prefix as an 1112 internal function. Since no routes are originated specifically for 1113 prefixes held by these subscribers, no ROAs need to be issued under 1114 their allocations; rather, the subscriber's ISP will issue any 1115 necessary ROAs for its more general prefixes under resource 1116 certificates its own allocation. Thus, a single-homed subscriber with 1117 a non-portable allocation is not included in the RPKI, i.e., it does 1118 not receive a CA certificate, nor issue EE certificates or ROAs. 1120 7.2.2. Multi-homed subscribers 1122 In order for multiple ASes to originate routers for prefixes held by 1123 a multi-homed subscriber, each AS must have a ROA that explicitly 1124 authorizes such route origination. There are two ways that this can 1125 be accomplished. 1127 One option is for the multi-homed subscriber to obtain a CA 1128 certificate from the ISP who allocated the prefixes to the 1129 subscriber. The multi-homed subscriber can then create a ROA (and 1130 associated end-entity certificate) that authorizes a second ISP to 1131 originate routes to the subscriber prefix(es). The ROA for the second 1132 ISP generally SHOULD be set to require an exact match, if the intent 1133 is to enable backup paths for the prefix. Note that the first ISP, 1134 who allocated the prefixes, will want to advertise the more specific 1135 prefix for this subscriber (vs. the encompassing prefix). Either the 1136 subscriber or the first ISP will need to issue an EE certificate and 1137 ROA for the (more specific) prefix, authorizing this ISP to advertise 1138 this more specific prefix. 1140 A second option is that the multi-homed subscriber can request that 1141 the ISP that allocated the prefixes create a ROA that authorizes the 1142 second ISP to originate routes to the subscriber's prefixes. (The ISP 1143 also creates an EE certificate and ROA for its own advertisement of 1144 the subscriber prefix, as above.) This option does not require that 1145 the subscriber be issued a certificate or participate in ROA 1146 management. Therefore, this option is simpler for the subscriber, and 1147 is preferred if the option is supported by the ISP performing the 1148 allocation. 1150 7.2.3. Portable allocations 1152 A resource holder is said to have a portable (provider independent) 1153 allocation if the resource holder received its allocation from a 1154 regional or national registry. Because the prefixes represented in 1155 such allocations are not taken from an allocation held by an ISP, 1156 there is no ISP that holds and advertises a more general prefix. A 1157 holder of a portable allocation MUST authorize one or more ASes to 1158 originate routes to these prefixes. Thus the resource holder MUST 1159 generate one or more EE certificates and associated ROAs to enable 1160 the AS(es) to originate routes for the prefix(es) in question. This 1161 ROA is required because none of the ISP's existing ROAs authorize it 1162 to originate routes to that portable allocation. 1164 7.3. Route filter construction 1166 The goal of this architecture is to support improved routing 1167 security. One way to do this is to use ROAs to construct route 1168 filters that reject routes that conflict with the origination 1169 authorizations asserted by current ROAs, which can be accomplished 1170 with the following procedure: 1172 1. Obtain a local copy of all currently valid EE certificates, as 1173 specified in Section 5. 1175 2. Query the repository system to obtain a local copy of all ROAs 1176 issued under the PKI. 1178 3. Verify that the each ROA matches the hash value contained in the 1179 manifest of the CA certificate used to verify the EE certificate 1180 that issued the ROA and that no ROAs are missing. (ROAs are 1181 contained in files with a ".roa" suffix, so missing ROAs are 1182 readily detected.) 1184 4. Validate each ROA by verifying that it's signature is verifiable 1185 by a valid end-entity certificate that matches the address 1186 allocation in the ROA. (See [7] for more details.) 1188 5. Based on the validated ROAs, construct a table of prefixes and 1189 corresponding authorized origin ASes (or vice versa). 1191 A BGP speaker that applies such a filter is thus guaranteed that for 1192 a given IP address prefix, all routes that the BGP speaker accepts 1193 for that prefix were originated by an AS that is authorized by the 1194 owner of the prefix to authorize routes to that prefix. 1196 The first three steps in the above procedure might incur a 1197 substantial overhead if all objects in the repository system were 1198 downloaded and validated every time a route filter was constructed. 1199 Instead, it will be more efficient for users of the infrastructure to 1200 initially download all of the signed objects and perform the 1201 validation algorithm described above. Subsequently, a relying party 1202 need only perform incremental downloads and validations on a regular 1203 basis. A typical ISP using the infrastructure might have a daily 1204 schedule to download updates from the repository, upload any 1205 modifications it has made, and construct route filters. 1207 It should be noted that the transition to 4-byte AS numbers (see RFC 1208 4893 [11]) weakens the security guarantees achieved by BGP speakers 1209 who do not support 4-byte AS numbers (referred to as OLD BGP 1210 speakers). RFC 4893 specifies that all 4-byte AS numbers (except 1211 those whose first two bytes are entirely zero) be mapped to the 1212 reserved value 23456 before being sent to a BGP speaker who does not 1213 understand 4-byte AS numbers. Therefore, when an ISP creates a route 1214 filter for use by an OLD BGP speaker, it must allow any 4-byte AS 1215 number to advertise routes for an IP address prefix if there exists a 1216 ROA that authorizes any 4-byte AS number to advertise routes to that 1217 prefix. This means that if an OLD BGP speaker accepts a route that 1218 was originated by an AS with a 4-byte AS number, there is no 1219 guarantee that it was originated by an authorized 4-byte AS number 1220 (unless the route was propagated by an intermediate NEW BGP speaker 1221 who performed route filtering as described above). 1223 8. Security Considerations 1225 The focus of this document is security; hence security considerations 1226 permeate this specification. 1228 The security mechanisms provided by and enabled by this architecture 1229 depend on the integrity and availability of the infrastructure it 1230 describes. The integrity of objects within the infrastructure is 1231 ensured by appropriate controls on the repository system, as 1232 described in Section 4.4. Likewise, because the repository system is 1233 structured as a distributed database, it should be inherently 1234 resistant to denial of service attacks; nonetheless, appropriate 1235 precautions should also be taken, both through replication and backup 1236 of the constituent databases and through the physical security of 1237 database servers 1239 9. IANA Considerations 1241 This document makes no request of IANA. 1243 Note to RFC Editor: this section may be removed on publication as an 1244 RFC 1246 10. Acknowledgments 1248 The architecture described in this draft is derived from the 1249 collective ideas and work of a large group of individuals. This work 1250 would not have been possible without the intellectual contributions 1251 of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of 1252 APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Time 1253 Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy 1254 Bush of IIJ. 1256 Although we are indebted to everyone who has contributed to this 1257 architecture, we would like to especially thank Rob Austein for the 1258 concept of a manifest, and Geoff Huston for the concept of managing 1259 object validity through single-use EE certificate key pairs. 1261 11. References 1263 11.1. Normative References 1265 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1266 Levels", BCP 14, RFC 2119, March 1997. 1268 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 1269 (BGP-4)", RFC 4271, January 2006 1271 [3] Housley, R., et al., "Internet X.509 Public Key Infrastructure 1272 Certificate and Certificate Revocation List (CRL) Profile", RFC 1273 3280, April 2002. 1275 [4] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 1276 2004. 1278 [5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1279 Addresses and AS Identifiers", RFC 3779, June 2004. 1281 [6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 1282 X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- 1283 09, November 2007. 1285 [7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route 1286 Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-01, 1287 July 2008. 1289 11.2. Informative References 1291 [8] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway 1292 Protocol (Secure-BGP)", IEEE Journal on Selected Areas in 1293 Communications Vol. 18, No. 4, April 2000. 1295 [9] White, R., "soBGP", May 2005, 1298 [10] Tridgell, A., "rsync", April 2006, 1299 1301 [11] Vohra, Q., and Chen, E., "BGP Support for Four-octet AS Number 1302 Space", RFC 4893, May 2007. 1304 [12] Schaad, J., Kaliski, B., Housley, R., "Additional Algorithms 1305 and Identifiers for RSA Cryptography for use in the Internet 1306 X.509 Public Key Infrastructure for use in the Internet X.509 1307 Public Key Infrastructure", RFC 4055, June 2005. 1309 Author's Addresses 1311 Matt Lepinski 1312 BBN Technologies 1313 10 Moulton St. 1314 Cambridge, MA 02138 1316 Email: mlepinski@bbn.com 1318 Stephen Kent 1319 BBN Technologies 1320 10 Moulton St. 1321 Cambridge, MA 02138 1323 Email: kent@bbn.com 1325 Richard Barnes 1326 BBN Technologies 1327 10 Moulton St. 1328 Cambridge, MA 02138 1330 Email: rbarnes@bbn.com 1332 Intellectual Property Statement 1334 The IETF takes no position regarding the validity or scope of any 1335 Intellectual Property Rights or other rights that might be claimed to 1336 pertain to the implementation or use of the technology described in 1337 this document or the extent to which any license under such rights 1338 might or might not be available; nor does it represent that it has 1339 made any independent effort to identify any such rights. Information 1340 on the procedures with respect to rights in RFC documents can be 1341 found in BCP 78 and BCP 79. 1343 Copies of IPR disclosures made to the IETF Secretariat and any 1344 assurances of licenses to be made available, or the result of an 1345 attempt made to obtain a general license or permission for the use of 1346 such proprietary rights by implementers or users of this 1347 specification can be obtained from the IETF on-line IPR repository at 1348 http://www.ietf.org/ipr. 1350 The IETF invites any interested party to bring to its attention any 1351 copyrights, patents or patent applications, or other proprietary 1352 rights that may cover technology that may be required to implement 1353 this standard. Please address the information to the IETF at 1354 ietf-ipr@ietf.org. 1356 Disclaimer of Validity 1358 This document and the information contained herein are provided on an 1359 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1360 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1361 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1362 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1363 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1366 Copyright Statement 1368 Copyright (C) The IETF Trust (2007). 1370 This document is subject to the rights, licenses and restrictions 1371 contained in BCP 78, and except as set forth therein, the authors 1372 retain all their rights. 1374 Acknowledgment 1376 Funding for the RFC Editor function is currently provided by the 1377 Internet Society.