idnits 2.17.1 draft-ietf-sidr-arch-00.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 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 711. 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 (February 23, 2007) is 6272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3280 (ref. '3') (Obsoleted by RFC 5280) == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-03 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Inter-Domain Routing R. Barnes 2 Working Group S. Kent 3 Internet Draft BBN Technologies 4 Intended status: Informational February 23, 2007 5 Expires: August 2007 7 An Infrastructure to Support Secure Internet Routing 8 draft-ietf-sidr-arch-00.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 August 23, 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 In examples, "C:" and "S:" indicate lines sent by the client and 58 server respectively. 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119 [1]. 64 Table of Contents 66 1. Introduction...................................................3 67 2. PKI for Internet Number Resources..............................4 68 2.1. Role in the overall architecture..........................4 69 2.2. CA Certificates...........................................5 70 2.3. End-Entity Certificates...................................5 71 2.4. Trust Anchors.............................................6 72 3. Route Origination Authorizations...............................6 73 3.1. Role in the overall architecture..........................7 74 3.2. Syntax and semantics......................................7 75 3.3. Revocation................................................8 76 4. Repository system..............................................8 77 4.1. Role in the overall architecture..........................9 78 4.2. Contents and structure....................................9 79 4.3. Access protocols.........................................10 80 4.4. Access control...........................................10 81 5. Common Operations.............................................11 82 5.1. Certificate issuance.....................................11 83 5.2. ROA management...........................................12 84 5.2.1. Single-homed subscribers (without portable allocations) 85 ...........................................................12 86 5.2.2. Multi-homing........................................13 87 5.2.3. Portable allocations................................13 88 5.3. Route filter construction................................13 89 6. Security Considerations.......................................14 90 7. IANA Considerations...........................................14 91 8. Acknowledgments...............................................14 92 9. References....................................................15 93 9.1. Normative References.....................................15 94 9.2. Informative References...................................15 95 Author's Addresses...............................................15 96 Intellectual Property Statement..................................16 97 Disclaimer of Validity...........................................16 99 1. Introduction 101 This document describes an architecture for an infrastructure to 102 support improved security for BGP routing [2] for the Internet. The 103 architecture described by this document supports, at a minimum, two 104 types of routing security: It enables an entity to verifiably assert 105 that it is the legitimate holder of a set IP addresses or a set of 106 Autonomous System (AS) numbers, and it allows the holder of IP 107 address space to explicitly and verifiably authorize an AS to 108 originate routes to that address space. In addition to these initial 109 applications, however, this architecture could also support, without 110 extension, more advanced security protocols such as S-BGP [7] or 111 soBGP [8]. This architecture is applicable to routing of both IPv4 112 and IPv6 datagrams. 114 In order to facilitate deployment, the architecture takes advantage 115 of existing technologies and practices. The structure of the 116 architecture corresponds to the existing resource allocation 117 structure, so that management of this architecture is a natural 118 extension of the resource-management functions of organizations that 119 are already responsible for IP address and AS number resource 120 allocation. Likewise, existing resource allocation and revocation 121 practices have well-defined correspondents in this architecture. To 122 ease implementation, existing IETF standards are used wherever 123 possible; for example, extensive use is made of the X.509 certificate 124 profile defined by PKIX [3] and the extensions for IP Addresses and 125 AS numbers defined in RFC 3779 [4]. 127 The architecture is comprised of three main components: An X.509 128 public-key infrastructure (PKI) where certificates attest to holdings 129 of IP address space and AS numbers; signed objects called Route 130 Origination Authorizations (ROAs) that enable an address space holder 131 to explicitly authorize an AS to originate routes to portions of the 132 IP address space; and a distributed repository system that makes 133 these objects available for use by ISPs in making routing decisions. 134 These three basic components enable several security functions; this 135 document describes how they can be used to improve route filter 136 generation, and to perform several other common operations in such a 137 way as to make them cryptographically verifiable. 139 2. PKI for Internet Number Resources 141 Because the holder of a block IP address space is entitled to define 142 the topological destination of IP datagrams whose destinations fall 143 within that block, decisions about inter-domain routing are 144 inherently based on knowledge the allocation of the IP address space. 145 Thus, a basic function of this architecture is to provide 146 cryptographically verifiable attestations as to these allocations. In 147 current practice, the allocation of IP address is hierarchic: The 148 holder of a set of IP addresses may sub-allocate portions of that 149 set, either to itself (e.g., to a particular unit of the same 150 organization), or to another organization. Because of this 151 structure, IP address allocations can be described naturally by a 152 hierarchic public-key infrastructure, in which each certificate 153 attests to an allocation of IP addresses, and signing of subordinate 154 certificates corresponds to sub-allocation of IP addresses. The 155 above reasoning holds true for AS number resources as well, with the 156 difference that, by convention, AS numbers may not be sub-allocated 157 except by registries. Thus allocations of both IP addresses and AS 158 numbers can be expressed by the same PKI. Such a PKI is a central 159 component of this architecture. 161 2.1. Role in the overall architecture 163 Certificates in this PKI are called Resource Certificate, and conform 164 to the certificate profile for such certificates [5]. Resource 165 certificates attest to the allocation by the (certificate) issuer of 166 IP addresses or AS numbers to the subject. They do this by binding 167 the public key contained in the Resource Certificate to the IP 168 addresses or AS numbers included in the certificate's IP Address 169 Delegation or AS Identifier Delegation Extensions. An important 170 property of this PKI is that the names assigned to certificate 171 issuers and subjects are not intended to be meaningful; this is in 172 contrast to most PKIs where considerable effort is expended to ensure 173 that the subject name in a certificate is properly associated with 174 the entity that holds the private key corresponding to the public key 175 in the certificate. This PKI is different because it is an 176 authorization PKI, not an authentication PKI. Because issuers need 177 not verify the right of an entity to use a subject name in a 178 certificate, they avoid the costs and liabilities of such 179 verification. This makes it easier for these entities to take on the 180 additional role of CA. Only the basic PKI requirement, that a CA not 181 associate the same name with two distinct subjects to whom it issues 182 certificates, is imposed. 184 The certificates in the PKI assert the basic facts on which the rest 185 of the infrastructure operates. Certificates within the CA hierarchy 186 attest to IP address space and AS number holdings. End-entity 187 certificates are issued by resource holders to delegate the authority 188 attested by their allocation certificates, the primary use for this 189 being the signing of ROAs. These certificates and corresponding 190 certificate revocation lists will comprise a significant portion of 191 the data stored in the repository system. 193 2.2. CA Certificates 195 Any holder of Internet Number Resources who is authorized to sub- 196 allocate them must be able to issue Resource Certificates to 197 correspond to these sub-allocations. Thus, for example, CA 198 certificates will be associated with each of the Regional Internet 199 Registries, National Internet Registries, and Local Internet 200 Registries, as well as with all ISPs. A CA certificate is also 201 necessary for a resource holder to issue ROAs (because it must also 202 issue the corresponding end-entity certificates used to validate 203 ROAs), so many subscribers also will need to have CA certificates for 204 their allocations (in particular, multi-homed subscribers, and 205 subscribers with portable allocations). 207 Each Resource Certificate attests to an allocation of resources to 208 its holder, so entities that have allocations from multiple sources 209 will have multiple CA certificates. (A CA also may issue distinct 210 certificates for each distinct allocation to the same entity, if the 211 issuer and the resource holder agree that such an arrangement will 212 facilitate management and use of the certificates.) 214 2.3. End-Entity Certificates 216 Although the private key corresponding to public key contained in an 217 end-entity certificate is not used to sign other certificates in the 218 PKI, the primary function of end-entity certificates in this PKI is 219 the verification of signed objects that relate to the usage of the 220 resources described in the certificate, e.g., ROAs. For this 221 purpose, there is a one-to-one correspondence between end-entity 222 certificates and signed objects, i.e., the private key corresponding 223 to each end-entity certificate is used to sign exactly one object, 224 and each object is signed with one key. This property allows the PKI 225 itself to be used to revoke these signed objects. When the end-entity 226 certificate used to sign an object has been revoked, the signature on 227 that object (and any corresponding assertions) will be considered 228 invalid, so a signed object can be effectively revoked by revoking 229 the end-entity certificate used to sign it. 231 A secondary advantage to this one-to-one correspondence is that the 232 private key corresponding to the public key in a certificate is used 233 exactly once in its lifetime, and thus can be destroyed after it has 234 been used to sign its one object. This fact should simplify key 235 management, since only the public portions of end-entity certificates 236 will need to be retained for any significant length of time. 238 Although this document defines only one use for end-entity 239 certificates, additional uses will likely be defined in the future. 240 For example, end-entity certificates could be used as a more general 241 authorization for their subjects to act on behalf of the holder of 242 the indicated resources. This could facilitate authentication of 243 inter-ISP interactions, or authentication of interactions with the 244 repository system. These additional uses for end-entity 245 certificates, however, may require retention of the corresponding 246 private keys, even though this is not required for the private keys 247 associated with end-entity certificates keys used for verification of 248 ROAs, as described above. 250 2.4. Trust Anchors 252 In any PKI, each relying party (RP) is free to choose its own set of 253 trust anchors. In this case, the hierarchy of this PKI is structured 254 according to the IP address space and AS number allocation hierarchy, 255 so since administrative control of the IP address space (the root of 256 the allocation hierarchy) rests with IANA and the RIRs , these 257 entities form a natural set of default trust anchors for this PKI. 258 Nonetheless, every relying party is free to choose a different set of 259 trust anchors to use for certificate validation operations. 261 For example, an RP could create one or more self-signed certificates 262 to which all address space and/or all AS numbers are assigned, and 263 for which the RP knows the corresponding private key. The RP could 264 then issue certificates under these trust anchors to whatever 265 entities in the PKI it wishes, with the result that the certificate 266 paths terminating at these locally-installed trust anchors will 267 satisfy the RFC 3779 validation requirements. 269 An RP who elects to create and manage its own set of trust anchors 270 may fail to detect allocation errors that arise under such 271 circumstances, but the resulting vulnerability is local to the RP. 273 3. Route Origination Authorizations 275 The information on IP address allocation provided by the PKI is not 276 in itself sufficient to guide routing decisions. In particular, BGP 277 is based on the assumption that the AS that originates routes for a 278 particular block of IP address space is authorized to do so by the 279 holder of that block; the PKI contains no information about these 280 authorizations. A Route Origination Authorization (ROA) make such 281 authorization explicit, allowing a holder of address space to create 282 an object that explicitly and verifiably asserts that an AS is 283 authorized originate routes to that address space. 285 3.1. Role in the overall architecture 287 A ROA is an attestation that the holder of a set of IP addresses has 288 authorized an autonomous system to originate routes for that set of 289 IP addresses. A ROA is structured according to format described in 290 [6]. The validity of this authorization depends on the issuer of the 291 ROA being the owner of the set of IP addresses in the ROA; this fact 292 is asserted by an end-entity certificate from the PKI, whose 293 corresponding private key is used to sign the ROA. The repository 294 system will be the primary mechanism for disseminating ROAs, since 295 the operators of repositories already provide other types routing 296 information. In addition, ROAs could also be distributed in BGP 297 UPDATE messages or via other communication paths, since route 298 filtering is their primary application. 300 3.2. Syntax and semantics 302 A ROA constitutes an explicit authorization for a single AS to 303 originate routes to one or more prefixes, and is signed by the holder 304 of those prefixes. A ROA thus have three essential components: 306 1. An AS number 308 2. One or more IP address prefixes 310 3. A digital signature 312 In addition, a ROA has a version number, to accommodate changes in 313 syntax (or semantics) over time. The AS number contained in a ROA is 314 that of an AS authorized to originate routes for the indicated IP 315 address prefixes. Only one AS number is contained in a ROA in order 316 to simplify ROA management, e.g., to avoid the complexity that might 317 arise is AS numbers for multiple ISPs were referenced from a single 318 ROA. If an ISP serving a subscriber has multiple AS numbers, and 319 wants the address space holder to authorize advertisement of the same 320 set of prefixes by any of these ASes, the ISP should request the 321 subscriber to issue multiple ROAs, each specifying a distinct AS 322 number. Similarly, a multi-homed address space holder must generate 323 multiple ROAs, one for each ISP that will originate routes for it. 325 A ROA is signed using the private key whose public key is contained 326 in an end-entity certificate in the PKI, from which the ROA inherits 327 two properties. First, The IP prefixes listed in the ROA are the 328 ones that the indicated AS is authorized to originate; in order for 329 this authorization (i.e., the ROA) to be valid, the prefixes 330 contained in a ROA must be exactly the same as the set of IP 331 addresses in the IP Address Delegation Extension of the end-entity 332 certificate used to sign the ROA. Second, the ROA is valid only as 333 long as the certificate used to sign it is valid; a ROA is 334 invalidated by revoking the end-entity certificate corresponding to 335 the public key used to verify it, and the validity interval of the 336 ROA is implicitly that of the validity interval of the corresponding 337 certificate. 339 Address holders that have allocations from multiple sources must 340 issue multiple ROAs. If an address holder has allocations from 341 multiple sources, then these allocations will be described by 342 multiple CA certificates in the PKI, each issued by the provider of 343 the respective allocation; the sets of IP addresses contained in end- 344 entity certificates issued by this address holder are required to be 345 subsets of these allocations. Because end-entity certificates are in 346 one-to-one correspondence with ROAs, this means that the set of IP 347 addresses contained in a ROA must be drawn from an allocation by a 348 single source; hence ROAs cannot combine allocations from multiple 349 sources. 351 3.3. Revocation 353 If an address holder decides that an AS should no longer originate 354 routes for addresses that it holds (e.g., if the address holder 355 transfers from one ISP to another), then it will be necessary to 356 invalidate the ROAs that attest to any such authorization. Since 357 ROAs are in one-to-one correspondence with end-entity certificates, 358 the standard method for revoking a ROA is to revoke the corresponding 359 end-entity certificate in the PKI. There is no independent 360 revocation mechanism for ROAs. 362 4. Repository system 364 In order for ROAs (and other objects to be verified using 365 certificates from the PKI) to be validated, the objects necessary to 366 validate them must be universally accessible. The primary function 367 of the distributed repository system described here is to store these 368 objects and to make them available for download. The repository 369 system is also a point of enforcement for access controls for the 370 signed objects stored in it, e.g., ensuring that records related to 371 an allocation of resources can be manipulated only by authorized 372 parties. This requirement exists to prevent denial of service attacks 373 based on deletion of or tampering with repository objects. Although 374 any unauthorized modification is detectable by relying parties, 375 because all the objects are digitally signed, it is preferable that 376 the repository system prevent unauthorized modifications. 378 4.1. Role in the overall architecture 380 The repository system is the central clearing-house for the objects 381 required for validation of signed objects like ROAs. When 382 certificates and CRLs are created, they are uploaded to this 383 repository, and then downloaded for use by relying parties. In 384 addition, signed objects that require universal distribution can also 385 be made accessible through the repository system; ROAs are the only 386 such objects defined by this document, but other types of signed 387 objects may be added to this architecture in the future. The 388 repository system also must ensure the integrity of the data it 389 contains by enforcing appropriate controls on access to the 390 repository and on modifications to entries in it. This document 391 describes the controls necessary for PKI objects and ROAs, but does 392 not assume that they are applicable to other types of objects; if 393 other types of objects are to be included in the repository system in 394 the future, any necessary controls on them must be defined. 396 4.2. Contents and structure 398 The primary function of the repository system is to provide universal 399 distribution of objects necessary for the function of this 400 architecture. First among these are the objects that comprise the 401 PKI, namely Resource Certificates and their corresponding CRLs; these 402 objects require universal distribution so that all relying parties 403 have access to the PKI components required to validate signed objects 404 used by this architecture. In addition, it may be necessary to make 405 other types of signed objects available through the repository 406 system. ROAs are a prime example of such a type, since routes whose 407 origination is authorized by a ROA are distributed through the entire 408 routing infrastructure, any component of which may, by local policy, 409 examine the route origin for consistency with the ROA. 411 Although there is a single repository system that is accessed by 412 relying parties, it is comprised of multiple databases. These 413 databases will be distributed among RIRs and ISPs that participate in 414 the architecture. At a minimum, the database operated by each RIR 415 will contain certificates and CRLs issued by that RIR; it may also 416 contain repository objects submitted by holders of addresses that 417 fall within that RIR's scope or copies of data from other RIRs, 418 according to local policy. 420 4.3. Access protocols 422 Repository operators will choose one or more access protocols that 423 relying parties can use to access the repository system. These 424 protocols will be used by numerous participants in the infrastructure 425 (e.g., all registries, ISPs, and multi-homed subscribers) to maintain 426 their respective portions of it. In order to support these 427 activities, certain basic functionality is required of the suite of 428 access protocols, as described below. No single access protocol need 429 implement all of these functions (although this may be the case), but 430 each function must be implemented by at least one access protocol. 432 Download: Access protocols MUST support the bulk download of 433 repository contents and subsequent download of changes to the 434 downloaded contents, since this will be the most common way in which 435 relying parties interact with the repository system. Other types of 436 download interactions (e.g., download of a single object) MAY also be 437 supported. 439 Upload/change/delete: Access protocols MUST also support mechanisms 440 for the issuers of certificates, CRLs, and other signed objects to 441 add them to the repository, and to remove them. Mechanisms for 442 modifying objects in the repository MAY also be provided. All access 443 protocols that allow modification to the repository (through 444 addition, deletion, or modification of its contents) MUST support 445 verification of the authorization of the entity performing the 446 modification, so that appropriate access controls can be applied (see 447 Section 4.4). 449 Current efforts to implement a repository system use RSYNC [9] as the 450 single access protocol. RSYNC, as used in this implementation, 451 provides all of the above functionality. 453 4.4. Access control 455 In order to maintain the integrity of information in the repository, 456 controls must be put in place to prevent addition, deletion, or 457 modification of objects in the repository by unauthorized parties. 458 The identities of parties attempting to make such changes can be 459 authenticated through the relevant access protocols. Although 460 specific access control policies are subject to the local control of 461 repository operators, it is recommended that repositories allow only 462 the issuers of signed objects to add, delete, or modify them. 463 Alternatively, it may be advantageous in the future to define a 464 formal delegation mechanism to allow resource holders to authorize 465 other parties to act on their behalf, as is suggested in Section 2.3 466 above. 468 5. Common Operations 470 Creating and maintaining the infrastructure described above will 471 entail the addition of security operations to normal resource 472 allocation and routing authorization procedures. For example, a 473 multi-homed subscriber entering a relationship with a new ISP will 474 need to issue one or more ROAs to that ISP, in addition to conducting 475 any other necessary technical or business procedures. The current 476 primary use of this infrastructure is for route filter construction; 477 using ROAs, route filters can be constructed in an automated fashion 478 with high assurance that the holder of the advertised prefix has 479 authorized the first- hop AS to originate an advertised route. 481 5.1. Certificate issuance 483 In order to participate in this infrastructure, resource holders will 484 require certificates in the PKI that attest to their allocations. 485 Each such certificate will show the issuer of the allocation as the 486 certificate issuer, the recipient of the allocation as subject, and a 487 description of the allocated resources in the appropriate RFC 3779 488 extensions. The two operations defined in this architecture that 489 require a resource holder to have resource certificates for his 490 allocations are (1) issuance of certificates for sub-allocations and 491 (2) management of ROAs (and corresponding end-entity certificates). 493 In particular, there are several operational scenarios that require 494 certificates to be issued. Any allocation that may be sub-allocated 495 requires a CA certificate so that certificates can be issued as 496 necessary for sub-allocations. Multi-homed subscribers require 497 certificates for their allocations so that they can issue ROAs to 498 their ISPs. Holders of "portable" address allocations must have 499 certificates, so that a ROA can be issued to each ISP that is 500 authorized to originate a route to the allocation, since the 501 allocation does not come from any ISP. 503 As a resource holder receives multiple allocations over time, it will 504 accrue a collection of resource certificates to attest to them. It 505 may be the case that multiple of a resource holder's allocations are 506 from the same source. A set of resource certificates that are all 507 issued by the same CA could be combined into a single resource 508 certificate by consolidating their IP Address Delegation and AS 509 Identifier Delegation Extensions into a single extension of each 510 type. However, if the certificates for these allocations contain 511 different validity intervals, creating a certificate that combines 512 them might create problems, and thus is NOT RECOMMENDED. If a 513 resource holder's allocations come from different sources, they will 514 be signed by different CAs, and cannot be combined. When a set of 515 resources is no longer allocated to a resource holder, any 516 certificates attesting to such an allocation must be revoked. A 517 resource holder MAY choose to use the same public key in multiple CA 518 certificates that issued by the same or differing authorities, 519 although such reuse of a key pair does complicate path construction. 521 5.2. ROA management 523 Whenever a holder of IP address space wants to authorize an AS to 524 originate routes for a prefix within his holdings, he must issue an 525 end-entity certificate containing that prefix and use the 526 corresponding private key to sign a ROA containing the designated 527 prefix and an AS number identifying the designated AS. As a 528 prerequisite, then, any address holder that issues ROAs for a prefix 529 must have a resource certificate for an allocation containing that 530 prefix. The standard procedure for issuing a ROA is as follows: 532 1. Create an end-entity certificate containing the prefixes to be 533 authorized in the ROA 535 2. Construct the payload of the ROA, including the prefixes in the 536 end-entity certificate and the AS number to be authorized 538 3. Sign the ROA using the private key corresponding to the end-entity 539 certificate (the ROA is comprised of the payload encapsulated in a 540 CMS signed message [ROA format I-D]) 542 4. Upload the end-entity certificate and the ROA to the repository 543 system 545 The standard procedure for revoking a ROA is to revoke the 546 corresponding end-entity certificate by creating an appropriate CRL 547 and uploading it to the repository system. The revoked ROA and end- 548 entity certificate SHOULD BE removed from the repository system. 550 5.2.1. Single-homed subscribers (without portable allocations) 552 In BGP, a single-homed subscriber with a non-portable allocation does 553 not need to explicitly authorize routes to be originated for the 554 prefix (or prefixes) it is using, since its ISP will already 555 advertise a more general prefix and route traffic for the 556 subscriber's prefix as an internal function. Since no routes are 557 originated specifically for prefixes held by these subscribers, no 558 ROAs need to be issued under their allocations; rather, the 559 subscriber's ISP will issue any necessary ROAs for its more general 560 prefixes under resource certificates its own allocation. Thus, 561 single-homed subscribers with non-portable allocations do not need to 562 issue (or otherwise manage) ROAs. 564 5.2.2. Multi-homing 566 If a multi-homed subscriber wants multiple ASes to originate routes 567 for prefixes that it holds, then it must explicitly authorize each of 568 them to do so by issuing a ROA for each AS in question. 570 5.2.3. Portable allocations 572 A resource holder is said to have a portable allocation if the 573 resource holder received its allocation from a registry. Because 574 these allocations are not taken from any larger allocations held by 575 an ISP, there is no ISP that holds and advertises a more general 576 prefix. If the holder of a portable allocation wants to authorize an 577 ISP to originate routes to its allocation, then it must issue a ROA 578 to this ISP; none of the ISP's existing ROAs authorize it to 579 originate routes to that portable allocation. 581 5.3. Route filter construction 583 The goal of this architecture is to support improved routing 584 security. One way to do this is to use ROAs to construct route 585 filters that reject routes that conflict with the origination 586 authorizations asserted by current ROAs, which can be accomplished 587 with the following procedure: 589 1. Obtain current certificates, CRLs, and ROAs from the repository 590 system (e.g., update a previous download) 592 2. Verify each end-entity certificate by constructing and verifying 593 a certification path for the certificate (including checking 594 relevant CRLs). 596 3. Verify each ROA by verifying that it is signed by a valid end- 597 entity certificate that matches the address allocation in the ROA. 599 4. Based on validated ROAs, construct a table of prefixes and 600 corresponding authorized origin ASes (or vice versa). 602 In addition to this basic route-filtering technique, the 603 infrastructure can be used to support more advanced routing-security 604 systems, such as S-BGP [7] and soBGP [8]. 606 The first three steps in the above procedure would incur a 607 prohibitive amount of overhead if all objects in the repository 608 system were downloaded and validated every time a route filter was 609 constructed. Instead, it will be more efficient for users of the 610 infrastructure to initially download all of the objects 611 (certificates, CRLs, and ROAs), perform necessary validations, then 612 perform incremental downloads and validations on a regular basis. A 613 typical ISP using the infrastructure might have a daily schedule to 614 download updates from the repository, upload any modifications it has 615 made, and construct route filters. 617 6. Security Considerations 619 The focus of this document is security; hence security considerations 620 permeate this specification. 622 The security mechanisms provided by and enabled by this architecture 623 depend on the integrity and availability of the infrastructure it 624 describes. The integrity of objects within the infrastructure is 625 ensured by appropriate controls on the repository system, as 626 described in Section 4.4. Likewise, because the repository system is 627 structured as a distributed database, it should be inherently 628 resistant to denial of service attacks; nonetheless, appropriate 629 precautions should also be taken, both through replication and backup 630 of the constituent databases and through the physical security of 631 database servers 633 7. IANA Considerations 635 This document makes no request of IANA. 637 Note to RFC Editor: this section may be removed on publication as an 638 RFC 640 8. Acknowledgments 642 This document was prepared using 2-Word-v2.0.template.dot. 644 9. References 646 9.1. Normative References 648 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 649 Levels", BCP 14, RFC 2119, March 1997. 651 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 652 (BGP-4)", RFC 4271, January 2006 654 [3] Housley, R., et al., "Internet X.509 Public Key Infrastructure 655 Certificate and Certificate Revocation List (CRL) Profile", RFC 656 3280, April 2002. 658 [4] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 659 Addresses and AS Identifiers", RFC 3779, June 2004. 661 [5] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 662 X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- 663 03, February 2007. 665 [6] Kong, D., and Kent, S., " A Profile for Route Origin 666 Authorizations (ROA)", draft-ietf-sidr-roa-format-00, February 667 2007. 669 9.2. Informative References 671 [7] [S-BGP] 673 [8] [soBGP] 675 [9] [rsync] 677 Author's Addresses 679 Richard Barnes 680 BBN Technologies 682 Email: rbarnes@bbn.com 684 Stephen Kent 685 BBN Technologies 687 Email: kent@bbn.com 689 Intellectual Property Statement 691 The IETF takes no position regarding the validity or scope of any 692 Intellectual Property Rights or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; nor does it represent that it has 696 made any independent effort to identify any such rights. Information 697 on the procedures with respect to rights in RFC documents can be 698 found in BCP 78 and BCP 79. 700 Copies of IPR disclosures made to the IETF Secretariat and any 701 assurances of licenses to be made available, or the result of an 702 attempt made to obtain a general license or permission for the use of 703 such proprietary rights by implementers or users of this 704 specification can be obtained from the IETF on-line IPR repository at 705 http://www.ietf.org/ipr. 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights that may cover technology that may be required to implement 710 this standard. Please address the information to the IETF at 711 ietf-ipr@ietf.org. 713 Disclaimer of Validity 715 This document and the information contained herein are provided on an 716 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 717 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 718 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 719 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 720 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 721 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 723 Copyright Statement 725 Copyright (C) The IETF Trust (2007). 727 This document is subject to the rights, licenses and restrictions 728 contained in BCP 78, and except as set forth therein, the authors 729 retain all their rights. 731 Acknowledgment 733 Funding for the RFC Editor function is currently provided by the 734 Internet Society.