idnits 2.17.1 draft-ietf-sidr-arch-04.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 1174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1164. 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 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3852 (ref. '4') (Obsoleted by RFC 5652) == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-14 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-04 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-04 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-01 -- Obsolete informational reference (is this intentional?): RFC 4893 (ref. '13') (Obsoleted by RFC 6793) == Outdated reference: A later version (-10) exists of draft-ietf-sidr-roa-validation-01 Summary: 2 errors (**), 0 flaws (~~), 7 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 BBN Technologies 4 Intended status: Informational November 3, 2008 5 Expires: May 3, 2009 7 An Infrastructure to Support Secure Internet Routing 8 draft-ietf-sidr-arch-04.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 3, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes an architecture for an infrastructure to 43 support improved security of Internet routing. The foundation of this 44 architecture is a public key infrastructure (PKI) that represents the 45 allocation hierarchy of IP address space and Autonomous System 46 Numbers; and a distributed repository system for storing and 47 disseminating the data objects that comprise the PKI, as well as 48 other signed objects necessary for improved routing security. As an 49 initial application of this architecture, the document describes how 50 a holder of IP address space can explicitly and verifiably authorize 51 one or more ASes to originate routes to that address space. Such 52 verifiable authorizations could be used, for example, to more 53 securely construct BGP route filters. 55 Table of Contents 57 1. Introduction...................................................3 58 2. PKI for Internet Number Resources..............................4 59 2.1. Role in the overall architecture..........................5 60 2.2. CA Certificates...........................................5 61 2.3. End-Entity (EE) Certificates..............................7 62 2.4. Trust Anchors.............................................8 63 2.5. Default Trust Anchor Considerations.......................8 64 2.6. Representing Early-Registration Transfers (ERX)..........10 65 3. Route Origination Authorizations..............................10 66 3.1. Role in the overall architecture.........................11 67 3.2. Syntax and semantics.....................................11 68 4. Repositories..................................................13 69 4.1. Role in the overall architecture.........................14 70 4.2. Contents and structure...................................14 71 4.3. Access protocols.........................................16 72 4.4. Access control...........................................16 73 5. Manifests.....................................................17 74 5.1. Syntax and semantics.....................................17 75 6. Local Cache Maintenance.......................................18 76 7. Common Operations.............................................18 77 7.1. Certificate issuance.....................................19 78 7.2. ROA management...........................................20 79 7.2.1. Single-homed subscribers (without portable allocations) 80 ...........................................................20 81 7.2.2. Multi-homed subscribers.............................21 82 7.2.3. Portable allocations................................21 83 7.3. Route filter construction................................22 84 8. Security Considerations.......................................23 85 9. IANA Considerations...........................................24 86 10. Acknowledgments..............................................24 87 11. References...................................................25 88 11.1. Normative References....................................25 89 11.2. Informative References..................................25 90 Authors' Addresses...............................................26 91 Intellectual Property Statement..................................26 92 Disclaimer of Validity...........................................27 94 1. Introduction 96 This document describes an architecture for an infrastructure to 97 support improved security for BGP routing [2] for the Internet. The 98 architecture encompasses three principle elements: 100 . a public key infrastructure (PKI) 102 . digitally-signed routing objects to support routing security 104 . a distributed repository system to hold the PKI objects and the 105 signed routing objects 107 The architecture described by this document enables an entity to 108 verifiably assert that it is the legitimate holder of a set of IP 109 addresses or a set of Autonomous System (AS) numbers. As an initial 110 application of this architecture, the document describes how a holder 111 of IP address space can explicitly and verifiably authorize one or 112 more ASes to originate routes to that address space. Such verifiable 113 authorizations could be used, for example, to more securely construct 114 BGP route filters. In addition to this initial application, the 115 infrastructure defined by this architecture also is intended to 116 provide future support for security protocols such as S-BGP [10] or 117 soBGP [11]. This architecture is applicable to the routing of both 118 IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only address 119 families supported by this architecture. Thus, for example, use of 120 this architecture with MPLS labels is beyond the scope of this 121 document. 123 In order to facilitate deployment, the architecture takes advantage 124 of existing technologies and practices. The structure of the PKI 125 element of the architecture corresponds to the existing resource 126 allocation structure. Thus management of this PKI is a natural 127 extension of the resource-management functions of the organizations 128 that are already responsible for IP address and AS number resource 129 allocation. Likewise, existing resource allocation and revocation 130 practices have well-defined correspondents in this architecture. To 131 ease implementation, existing IETF standards are used wherever 132 possible; for example, extensive use is made of the X.509 certificate 133 profile defined by PKIX [3] and the extensions for IP Addresses and 134 AS numbers representation defined in RFC 3779 [5]. Also CMS [4] is 135 used as the syntax for the newly-defined signed objects required by 136 this infrastructure. 138 As noted above, the infrastructure is comprised of three main 139 components: an X.509 PKI in which certificates attest to holdings of 140 IP address space and AS numbers; non-certificate/CRL signed objects 141 (including route origination authorizations and manifests) used by 142 the infrastructure; and a distributed repository system that makes 143 all of these signed objects available for use by ISPs in making 144 routing decisions. These three basic components enable several 145 security functions; this document describes how they can be used to 146 improve route filter generation, and to perform several other common 147 operations in such a way as to make them cryptographically 148 verifiable. 150 1.1. Terminology 152 It is assumed that the reader is familiar with the terms and concepts 153 described in "Internet X.509 Public Key Infrastructure Certificate 154 and Certificate Revocation List (CRL) Profile" [3], and "X.509 155 Extensions for IP Addresses and AS Identifiers" [5]. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC-2119 [1]. 161 2. PKI for Internet Number Resources 163 Because the holder of a block IP address space is entitled to define 164 the topological destination of IP datagrams whose destinations fall 165 within that block, decisions about inter-domain routing are 166 inherently based on knowledge the allocation of the IP address space. 167 Thus, a basic function of this architecture is to provide 168 cryptographically verifiable attestations as to these allocations. In 169 current practice, the allocation of IP address is hierarchic. The 170 root of the hierarchy is IANA. Below IANA are five Regional Internet 171 Registries (RIRs), each of which manages address and AS number 172 allocation within a defined geopolitical region. In some regions the 173 third tier of the hierarchy includes National Internet Registries and 174 (NIRs) as well as Local Internet Registries (LIRs) and subscribers 175 with so-called ''portable'' (provider-independent) allocations. (The 176 term LIR is used in some regions to refer to what other regions 177 define as an ISP. Throughout the rest of this document we will use 178 the term LIR/ISP to simplify references to these entities.) In other 179 regions the third tier consists only of LIRs/ISPs and subscribers 180 with portable allocations. 182 In general, the holder of a set of IP addresses may sub-allocate 183 portions of that set, either to itself (e.g., to a particular unit of 184 the same organization), or to another organization, subject to 185 contractual constraints established by the registries. Because of 186 this structure, IP address allocations can be described naturally by 187 a hierarchic public-key infrastructure, in which each certificate 188 attests to an allocation of IP addresses, and issuance of subordinate 189 certificates corresponds to sub-allocation of IP addresses. The 190 above reasoning holds true for AS number resources as well, with the 191 difference that, by convention, AS numbers may not be sub-allocated 192 except by regional or national registries. Thus allocations of both 193 IP addresses and AS numbers can be expressed by the same PKI. Such a 194 PKI is a central component of this architecture. 196 2.1. Role in the overall architecture 198 Certificates in this PKI are called Resource Certificates, and 199 conform to the certificate profile for such certificates [6]. 200 Resource certificates attest to the allocation by the (certificate) 201 issuer of IP addresses or AS numbers to the subject. They do this by 202 binding the public key contained in the Resource Certificate to the 203 IP addresses or AS numbers included in the certificate's IP Address 204 Delegation or AS Identifier Delegation Extensions, respectively, as 205 defined in RFC 3779 [5]. 207 An important property of this PKI is that certificates do not attest 208 to the identity of the subject. Therefore, the subject names used in 209 certificates are not intended to be ''descriptive.'' That is, this 210 PKI is intended to provide authorization, but not authentication. 211 This is in contrast to most PKIs where the issuer ensures that the 212 descriptive subject name in a certificate is properly associated with 213 the entity that holds the private key corresponding to the public key 214 in the certificate. Because issuers need not verify the right of an 215 entity to use a subject name in a certificate, they avoid the costs 216 and liabilities of such verification. This makes it easier for these 217 entities to take on the additional role of CA. 219 Most of the certificates in the PKI assert the basic facts on which 220 the rest of the infrastructure operates. CA certificates within the 221 PKI attest to IP address space and AS number holdings. End-entity 222 (EE) certificates are issued by resource holder CAs to delegate the 223 authority attested by their allocation certificates. The primary use 224 for EE certificates is the validation of Route Origination 225 Authorizations (ROAs). Additionally, signed objects called manifests 226 will be used to help ensure the integrity of the repository system, 227 and the signature on each manifest will be verified via an EE 228 certificate. 230 2.2. CA Certificates 232 Any holder of Internet resources who is authorized to sub-allocate 233 them must be able to issue Resource Certificates to correspond to 234 these sub-allocations. Thus, for example, CA certificates will be 235 associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. A CA 236 certificate also is required to enable a resource holder to issue 237 ROAs, because it must issue the corresponding end-entity certificate 238 used to validate each ROA. Thus some subscribers also will need to 239 have CA certificates for their allocations, e.g., subscribers with 240 portable allocations, to enable them to issue ROAs. (A subscriber who 241 is not multi-homed, whose allocation comes from an LIR/ISP, and who 242 has not moved to a different LIR/ISP, need not be represented in the 243 PKI. Moreover, a multi-homed subscriber with an allocation from an 244 LIR/ISP may or may not need to be explicitly represented, as 245 discussed in Section 6.2.2) 247 Unlike in most PKIs, the distinguished name of the subject in a CA 248 certificate is chosen by the certificate issuer. If the subject of a 249 certificate is an RIR or IANA, then the distinguished name of the 250 subject will be chosen to convey the identity of the registry and 251 should consist of (a subset of) the following attributes: country, 252 organization, organizational unit, and common name. For example, an 253 appropriate subject name for the APNIC RIR might be: 255 . Country: AU 257 . Organization: Asia Pacific Network Information Centre 259 . Common Name: APNIC Resource Certification Authority 261 If the subject of a certificate is not an RIR or IANA, (e.g., the 262 subject is a NIR, or LIR/ISP) the distinguished name MUST consist 263 only of the common name attribute and must not attempt to convey the 264 identity of the subject in a descriptive fashion. Additionally, the 265 subject's distinguished name must be unique among all certificates 266 issued by a given authority. In this PKI, the certificate issuer, 267 being an internet registry or LIR/ISP, is not in the business of 268 verifying the legal right of the subject to assert a particular 269 identity. Therefore, selecting a distinguished name that does not 270 convey the identity of the subject in a descriptive fashion minimizes 271 the opportunity for the subject to misuse the certificate to assert 272 an identity, and thus minimizes the legal liability of the issuer. 273 Since all CA certificates are issued to subjects with whom the issuer 274 has an existing relationship, it is recommended that the issuer 275 select a subject name that enables the issuer to easily link the 276 certificate to existing database records associated with the subject. 277 For example, an authority may use internal database keys or 278 subscriber IDs as the subject common name in issued certificates. 280 Each Resource Certificate attests to an allocation of resources to 281 its holder, so entities that have allocations from multiple sources 282 will have multiple CA certificates. A CA also may issue distinct 283 certificates for each distinct allocation to the same entity, if the 284 CA and the resource holder agree that such an arrangement will 285 facilitate management and use of the certificates. For example, an 286 LIR/ISP may have several certificates issued to it by one registry, 287 each describing a distinct set of address blocks, because the LIR/ISP 288 desires to treat the allocations as separate. 290 2.3. End-Entity (EE) Certificates 292 The private key corresponding to public key contained in an EE 293 certificate is not used to sign other certificates in a PKI. The 294 primary function of end-entity certificates in this PKI is the 295 verification of signed objects that relate to the usage of the 296 resources described in the certificate, e.g., ROAs and manifests. 297 For ROAs and manifests there will be a one-to-one correspondence 298 between end-entity certificates and signed objects, i.e., the private 299 key corresponding to each end-entity certificate is used to sign 300 exactly one object, and each object is signed with only one key. 301 This property allows the PKI to be used to revoke these signed 302 objects, rather than creating a new revocation mechanism. When the 303 end-entity certificate used to sign an object has been revoked, the 304 signature on that object (and any corresponding assertions) will be 305 considered invalid, so a signed object can be effectively revoked by 306 revoking the end-entity certificate used to sign it. 308 A secondary advantage to this one-to-one correspondence is that the 309 private key corresponding to the public key in a certificate is used 310 exactly once in its lifetime, and thus can be destroyed after it has 311 been used to sign its one object. This fact should simplify key 312 management, since there is no requirement to protect these private 313 keys for an extended period of time. 315 Although this document describes only two uses for end-entity 316 certificates, additional uses will likely be defined in the future. 317 For example, end-entity certificates could be used as a more general 318 authorization for their subjects to act on behalf of the holder of 319 the specified resources. This could facilitate authentication of 320 inter-ISP interactions, or authentication of interactions with the 321 repository system. These additional uses for end-entity certificates 322 may require retention of the corresponding private keys, even though 323 this is not required for the private keys associated with end-entity 324 certificates keys used for verification of ROAs and manifests, as 325 described above. 327 2.4. Trust Anchors 329 In any PKI, each relying party (RP) is free to choose its own set of 330 trust anchors. This general property of PKIs applies here as well. 331 There is an extant IP address space and AS number allocation 332 hierarchy. IANA is the obvious candidate to be the TA, but 333 operational considerations may argue for a multi-TA PKI, e.g., one in 334 which both IANA and the RIRs form a default set of trust anchors. 335 Nonetheless, every relying party is free to choose a different set of 336 trust anchors to use for certificate validation operations. 338 For example, an RP (e.g., an LIR/ISP) could create a trust anchor to 339 which all address space and/or all AS numbers are assigned, and for 340 which the RP knows the corresponding private key. The RP could then 341 issue certificates under this trust anchor to whatever entities in 342 the PKI it wishes, with the result that the certificate paths 343 terminating at this locally-installed trust anchor will satisfy the 344 RFC 3779 validation requirements. 346 An RP who elects to create and manage its own set of trust anchors 347 may fail to detect allocation errors that arise under such 348 circumstances, but the resulting vulnerability is local to the RP. 350 2.5. Default Trust Anchors 352 The profile for resource certificates [6] specifies a format for a 353 putative trust anchor to distribute to relying parties trust anchor 354 material consisting of both a self-signed certificate (which would 355 form the root of certification paths in the PKI) along with an 356 additional 'trust anchor' certificate used to validate the self- 357 signed certificate. Any entity claiming authoritative information 358 regarding the allocation of a portion of IP address space may offer 359 itself up in the role of a putative trust anchor by distributing such 360 material (in an out-of-band fashion). Given the extant IP address 361 space and AS number allocation hierarchy, it is envisioned that IANA 362 and the five RIRs will provide trust anchor information to relying 363 parties and that relying parties will generally accept trust anchors 364 from this set. 366 IANA forms the root of the extant IP address space and AS number 367 allocation hierarchy. Therefore, it is expected that IANA will 368 provide to relying parties trust anchor material whose self-signed 369 certificate has RFC 3779 extensions corresponding either to the 370 entirety of IP address space, or alternatively that portion of IP 371 address space that has not been sub-allocated to any of the five 372 RIRs. 374 As an example of the use of IANA as a trust anchor, consider the use 375 of private IP address space (i.e., 10/8, 172.16/12, and 192.168/16 in 376 IPv4 and FC00::/7 in IPv6). IANA could issue a CA certificate for 377 these blocks of private address space and then destroy the private 378 key corresponding to the public key in the certificate. In this way, 379 any relying party who configured IANA as their sole trust anchor 380 would automatically reject any ROA containing private addresses, 381 appropriate behavior with regard to routing in the public Internet. 382 On the other hand, such an approach would not interfere with an 383 organization that wishes to use private address space in conjunction 384 with BGP and this PKI technology. Such an organization could 385 configure its relying parties with an additional, local trust anchor 386 that issues certificates for private addresses used within the 387 organization. In this manner, BGP advertisements for these private 388 addresses would be accepted within the organization but would be 389 rejected if mistakenly sent outside the private address space context 390 in question. 392 In the DNSSEC context, IANA (as the root of the DNS) is already 393 experimenting with the operational procedures needed to digitally 394 sign the root zone. This is very much analogous to the role it would 395 play if it were to act as the default trust anchor for the RPKI, even 396 though DNSSEC does not make use of X.509 certificates. Nonetheless, 397 it is appropriate consider alternative default trust anchor models, 398 if IANA does not act in this capacity. This motivates the 399 consideration of alternative default trust anchor options for RPKI 400 relying parties. 402 Essentially all allocated IP address and AS number resources are sub- 403 allocated by IANA to one of the five RIRs. Therefore, it is expected 404 that each of the five RIRs will provide trust anchor material provide 405 to relying parties trust anchor material whose self-signed 406 certificate has RFC 3779 extensions corresponding to the IP address 407 and AS number resources that they manage. 409 One issue that the RIRs will need to consider when providing trust 410 anchor material is how to handle the approximately 49 /8 prefixes 411 containing legacy IPv4 allocations that are not each allocated to a 412 single RIR. Currently, for the purpose of administering reverse DNS 413 zones, each of these prefixes is administered by a single RIR who 414 delegates authority for allocations within the prefix as appropriate. 415 This existing arrangement could be used as the template for the 416 assignment of administrative responsibility for the certification of 417 these address blocks in the RPKI. Such an arrangement would in no way 418 alter the administrative arrangements and the associated policies 419 that apply to the individual legacy allocations that have been made 420 from these address blocks. 422 2.6. Representing Early-Registration Transfers (ERX) 424 Currently, IANA allocates IPv4 address space to the RIRs at the level 425 of /8 prefixes. However, there exist allocations that cross these RIR 426 boundaries. For example, A LACNIC customer may have an allocation 427 that falls within a /8 prefix administered by ARIN. Therefore, the 428 resource PKI must be able to represent such transfers from one RIR to 429 another in a manner that permits the validation of certificates with 430 RFC 3779 extensions. 432 +-------------------------------+ 433 | | 434 | LACNIC Administrative | 435 | Boundary | 436 | | 437 +--------+ | +--------+ | +--------+ 438 | ARIN | | | LACNIC | | | RIPE | 439 | ROOT | | | ROOT | | | ROOT | 440 +--------+ | +--------+ | +--------+ 441 \ | | / 442 ------------ ------------ 443 | \ / | 444 | +--------+ +--------+ | 445 | | LACNIC | | LACNIC | | 446 | | CA | | CA | | 447 | +--------+ +--------+ | 448 | | 449 +-------------------------------+ 451 FIGURE 1: Representing EXR 453 To represent such transfers, RIRs will need to manage multiple CA 454 certificates, each with distinct public (and corresponding private) 455 keys. Each RIR will have a single ''root'' certificate (e.g., a self- 456 signed certificate or a certificate signed by IANA, see Section 2.5), 457 plus one additional CA certificate for each RIR from which it 458 receives a transfer. Each of these additional CA certificates will be 459 issued under the ''root'' certificate of the RIR from which the 460 transfer is received. This means that although the certificate is 461 bound to the RIR that receives the transfer, for the purposes of 462 certificate path construction and validation, it does not appear 463 under that RIR's ''root'' certificate (see Figure 1). 465 3. Route Origination Authorizations 467 The information on IP address allocation provided by the PKI is not, 468 in itself, sufficient to guide routing decisions. In particular, BGP 469 is based on the assumption that the AS that originates routes for a 470 particular prefix is authorized to do so by the holder of that prefix 471 (or an address block encompassing the prefix); the PKI contains no 472 information about these authorizations. A Route Origination 473 Authorization (ROA) makes such authorization explicit, allowing a 474 holder of address space to create an object that explicitly and 475 verifiably asserts that an AS is authorized originate routes to 476 prefixes. 478 3.1. Role in the overall architecture 480 A ROA is an attestation that the holder of a set of prefixes has 481 authorized an autonomous system to originate routes for those 482 prefixes. A ROA is structured according to the format described in 483 [7]. The validity of this authorization depends on the signer of the 484 ROA being the holder of the prefix(es) in the ROA; this fact is 485 asserted by an end-entity certificate from the PKI, whose 486 corresponding private key is used to sign the ROA. 488 ROAs may be used by relying parties to verify that the AS that 489 originates a route for a given IP address prefix is authorized by the 490 holder of that prefix to originate such a route. For example, an ISP 491 might use ROAs as inputs to route filter construction for use by its 492 BGP routers. These filters would prevent importation of any route in 493 which the origin AS of the AS-PATH attribute is not an AS that is 494 authorized (via a valid ROA) to originate the route. (See Section 6.3 495 for more details.) 497 Initially, the repository system will be the primary mechanism for 498 disseminating ROAs, since these repositories will hold the 499 certificates and CRLs needed to verify ROAs. In addition, ROAs also 500 could be distributed in BGP UPDATE messages or via other 501 communication paths, if needed to meet timeliness requirements. 503 3.2. Syntax and semantics 505 A ROA constitutes an explicit authorization for a single AS to 506 originate routes to one or more prefixes, and is signed by the holder 507 of those prefixes. A detailed specification of the ROA syntax can be 508 found in [7] but, at a high level, a ROA consists of (1) an AS 509 number; (2) a list of IP address prefixes; and, optionally, (3) for 510 each prefix, the maximum length of more specific (longer) prefixes 511 that the AS is also authorized to advertise. (This last element 512 facilitates a compact authorization to advertise, for example, any 513 prefixes of length 20 to 24 contained within a given length 20 514 prefix.) 515 Note that a ROA contains only a single AS number. Thus, if an ISP has 516 multiple AS numbers that will be authorized to originate routes to 517 the prefix(es) in the ROA, an address space holder will need to issue 518 multiple ROAs to authorize the ISP to originate routes from any of 519 these ASes. 521 A ROA is signed using the private key corresponding to the public key 522 in an end-entity certificate in the PKI. In order for a ROA to be 523 valid, its corresponding end-entity (EE) certificate must be valid 524 and the IP address prefixes of the ROA must exactly match the IP 525 address prefix(es) specified in the EE certificate's RFC 3779 526 extension. Therefore, the validity interval of the ROA is implicitly 527 the validity interval of its corresponding certificate. A ROA is 528 revoked by revoking the corresponding EE certificate. There is no 529 independent method of invoking a ROA. One might worry that this 530 revocation model could lead to long CRLs for the CA certification 531 that is signing the EE certificates. However, routing announcements 532 on the public internet are generally quite long lived. Therefore, as 533 long as the EE certificates used to verify a ROA are given a validity 534 interval of several months, the likelihood that many ROAs would need 535 to revoked within time that is quite low. 537 --------- --------- 538 | RIR | | NIR | 539 | CA | | CA | 540 --------- --------- 541 | | 542 | | 543 | | 544 --------- --------- 545 | ISP | | ISP | 546 | CA 1 | | CA 2 | 547 --------- --------- 548 | \ | 549 | ----- | 550 | \ | 551 ---------- ---------- ---------- 552 | ISP | | ISP | | ISP | 553 | EE 1a | | EE 1b | | EE 2 | 554 ---------- ---------- ---------- 555 | | | 556 | | | 557 | | | 558 ---------- ---------- ---------- 559 | ROA 1a | | ROA 1b | | ROA 2 | 560 ---------- ---------- ---------- 562 FIGURE 2: This figure illustrates an ISP with allocations from two 563 sources (and RIR and an NIR). It needs two CA certificates due to RFC 564 3779 rules. 566 Because each ROA is associated with a single end-entity certificate, 567 the set of IP prefixes contained in a ROA must be drawn from an 568 allocation by a single source, i.e., a ROA cannot combine allocations 569 from multiple sources. Address space holders who have allocations 570 from multiple sources, and who wish to authorize an AS to originate 571 routes for these allocations, must issue multiple ROAs to the AS. 573 4. Repositories 575 Initially, an LIR/ISP will make use of the resource PKI by acquiring 576 and validating every ROA, to create a table of the prefixes for which 577 each AS is authorized to originate routes. To validate all ROAs, an 578 LIR/ISP needs to acquire all the certificates and CRLs. The primary 579 function of the distributed repository system described here is to 580 store these signed objects and to make them available for download by 581 LIRs/ISPs. Note that this repository system provides a mechanism by 582 which relying parties can pull fresh data at whatever frequency they 583 deem appropriate. However, it does not provide a mechanism for 584 pushing fresh data to relying parties (e.g. by including resource PKI 585 objects in BGP or other protocol messages) and such a mechanism is 586 beyond the scope of the current document. 588 The digital signatures on all objects in the repository ensure that 589 unauthorized modification of valid objects is detectable by relying 590 parties. Additionally, the repository system uses manifests (see 591 Section 5) to ensure that relying parties can detect the deletion of 592 valid objects and the insertion of out of date, valid signed objects. 594 The repository system is also a point of enforcement for access 595 controls for the signed objects stored in it, e.g., ensuring that 596 records related to an allocation of resources can be manipulated only 597 by authorized parties. The use access controls prevents denial of 598 service attacks based on deletion of or tampering to repository 599 objects. Indeed, although relying parties can detect tampering with 600 objects in the repository, it is preferable that the repository 601 system prevent such unauthorized modifications to the greatest extent 602 possible. 604 4.1. Role in the overall architecture 606 The repository system is the central clearing-house for all signed 607 objects that must be globally accessible to relying parties. When 608 certificates and CRLs are created, they are uploaded to this 609 repository, and then downloaded for use by relying parties (primarily 610 LIRs/ISPs). ROAs and manifests are additional examples of such 611 objects, but other types of signed objects may be added to this 612 architecture in the future. This document briefly describes the way 613 signed objects (certificates, CRLs, ROAs and manifests) are managed 614 in the repository system. As other types of signed objects are added 615 to the repository system it will be necessary to modify the 616 description, but it is anticipated that most of the design principles 617 will still apply. The repository system is described in detail in 618 [9]. 620 4.2. Contents and structure 622 Although there is a single repository system that is accessed by 623 relying parties, it is comprised of multiple databases. These 624 databases will be distributed among registries (RIRs, NIRs, 625 LIRs/ISPs). At a minimum, the database operated by each registry will 626 contain all CA and EE certificates, CRLs, and manifests signed by the 627 CA(s) associated with that registry. Repositories operated by 628 LIRs/ISPs also will contain ROAs. Registries are encouraged maintain 629 copies of repository data from their customers, and their customer's 630 customers (etc.), to facilitate retrieval of the whole repository 631 contents by relying parties. Ideally, each RIR will hold PKI data 632 from all entities within its geopolitical scope. 634 For every certificate in the PKI, there will be a corresponding file 635 system directory in the repository that is the authoritative 636 publication point for all objects (certificates, CRLs, ROAs and 637 manifests) verifiable via this certificate. A certificate's Subject 638 Information Authority (SIA) extension provides a URI that references 639 this directory. Additionally, a certificate's Authority Information 640 Authority (AIA) extension contains a URI that references the 641 authoritative location for the CA certificate under which the given 642 certificate was issued. That is, if certificate A is used to verify 643 certificate B, then the AIA extension of certificate B points to 644 certificate A, and the SIA extension of certificate A points to a 645 directory containing certificate B (see Figure 2). 647 +--------+ 648 +--------->| Cert A |<----+ 649 | | CRLDP | | +---------+ 650 | | AIA | | +-->| A's CRL |<-+ 651 | +--------- SIA | | | +---------+ | 652 | | +--------+ | | | 653 | | | | | 654 | | +---+----+ | 655 | | | | | 656 | | +---------------|---|-----------------+ | 657 | | | | | | | 658 | +->| +--------+ | | +--------+ | | 659 | | | Cert B | | | | Cert C | | | 660 | | | CRLDP ----+ | | CRLDP -+--------+ 661 +----------- AIA | +----- AIA | | 662 | | SIA | | SIA | | 663 | +--------+ +--------+ | 664 | | 665 +-------------------------------------+ 667 FIGURE 3: In this example, certificates B and C are issued under 668 certificate A. Therefore, the AIA extensions of certificates B and C 669 point to A, and the SIA extension of certificate A points to the 670 directory containing certificates B and C. 672 If a CA certificate is reissued with the same public key, it should 673 not be necessary to reissue (with an updated AIA URI) all 674 certificates signed by the certificate being reissued. Therefore, a 675 certification authority SHOULD use a persistent URI naming scheme for 676 issued certificates. That is, reissued certificates should use the 677 same publication point as previously issued certificates having the 678 same subject and public key, and should overwrite such certificates. 680 4.3. Access protocols 682 Repository operators will choose one or more access protocols that 683 relying parties can use to access the repository system. These 684 protocols will be used by numerous participants in the infrastructure 685 (e.g., all registries, ISPs, and multi-homed subscribers) to maintain 686 their respective portions of it. In order to support these 687 activities, certain basic functionality is required of the suite of 688 access protocols, as described below. No single access protocol need 689 implement all of these functions (although this may be the case), but 690 each function must be implemented by at least one access protocol. 692 Download: Access protocols MUST support the bulk download of 693 repository contents and subsequent download of changes to the 694 downloaded contents, since this will be the most common way in which 695 relying parties interact with the repository system. Other types of 696 download interactions (e.g., download of a single object) MAY also be 697 supported. 699 Upload/change/delete: Access protocols MUST also support mechanisms 700 for the issuers of certificates, CRLs, and other signed objects to 701 add them to the repository, and to remove them. Mechanisms for 702 modifying objects in the repository MAY also be provided. All access 703 protocols that allow modification to the repository (through 704 addition, deletion, or modification of its contents) MUST support 705 verification of the authorization of the entity performing the 706 modification, so that appropriate access controls can be applied (see 707 Section 4.4). 709 Current efforts to implement a repository system use RSYNC [12] as 710 the single access protocol. RSYNC, as used in this implementation, 711 provides all of the above functionality. A document specifying the 712 conventions for use of RSYNC in the PKI will be prepared. 714 4.4. Access control 716 In order to maintain the integrity of information in the repository, 717 controls must be put in place to prevent addition, deletion, or 718 modification of objects in the repository by unauthorized parties. 719 The identities of parties attempting to make such changes can be 720 authenticated through the relevant access protocols. Although 721 specific access control policies are subject to the local control of 722 repository operators, it is recommended that repositories allow only 723 the issuers of signed objects to add, delete, or modify them. 725 Alternatively, it may be advantageous in the future to define a 726 formal delegation mechanism to allow resource holders to authorize 727 other parties to act on their behalf, as suggested in Section 2.3 728 above. 730 5. Manifests 732 A manifest is a signed object listing of all of the signed objects 733 issued by an authority responsible for a publication in the 734 repository system. For each certificate, CRL, or ROA issued by the 735 authority, the manifest contains both the name of the file containing 736 the object, and a hash of the file content. 738 As with ROAs, a manifest is signed by a private key, for which the 739 corresponding public key appears in an end-entity certificate. This 740 EE certificate, in turn, is signed by the CA in question. The EE 741 certificate private key may be used to issue one for more manifests. 742 If the private key is used to sign only a single manifest, then the 743 manifest can be revoked by revoking the EE certificate. In such a 744 case, to avoid needless CRL growth, the EE certificate used to 745 validate a manifest SHOULD expire at the same time that the manifest 746 expires. If an EE certificate is used to issue multiple (sequential) 747 manifests for the CA in question, then there is no revocation 748 mechanism for these individual manifests. 750 Manifests may be used by relying parties when constructing a local 751 cache (see Section 6) to mitigate the risk of an attacker who deletes 752 files from a repository or replaces current signed objects with stale 753 versions of the same object. Such protection is needed because 754 although all objects in the repository system are signed, the 755 repository system itself is untrusted. 757 5.1. Syntax and semantics 759 A manifest constitutes a list of (the hashes of) all the files in a 760 repository point at a particular point in time. A detailed 761 specification of manifest syntax is provided in [8] but, at a high 762 level, a manifest consists of (1) a manifest number; (2) the time the 763 manifest was issued; (3) the time of the next planned update; and (4) 764 a list of filename and hash value pairs. 766 The manifest number is a sequence number that is incremented each 767 time a manifest is issued by the authority. An authority is required 768 to issue a new manifest any time it alters any of its items in the 769 repository, or when the specified time of the next update is reached. 770 A manifest is thus valid until the specified time of the next update 771 or until a manifest is issued with a greater manifest number, 772 whichever comes first. (Note that when an EE certificate is used to 773 sign only a single manifest, whenever the authority issues the new 774 manifest, the CA MUST also issue a new CRL which includes the EE 775 certificate corresponding to the old manifest. The revoked EE 776 certificate for the old manifest will be removed from the CRL when it 777 expires, thus this procedure ought not result in significant CRLs 778 growth.) 780 6. Local Cache Maintenance 782 In order to utilize signed objects issued under this PKI (e.g. for 783 route filter construction, see Section 6.3), a relying party must 784 first obtain a local copy of the valid EE certificates for the PKI. 785 To do so, the relying party performs the following steps: 787 1. Query the registry system to obtain a copy of all certificates, 788 manifests and CRLs issued under the PKI. 790 2. For each CA certificate in the PKI, verify the signature on the 791 corresponding manifest. Additionally, verify that the current 792 time is earlier than the time indicated in the nextUpdate field 793 of the manifest. 795 3. For each manifest, verify that certificates and CRLs issued 796 under the corresponding CA certificate match the hash values 797 contained in the manifest. If the hash values do not match, use 798 an out-of-band mechanism to notify the appropriate repository 799 administrator that the repository data has been corrupted. 801 4. Validate each EE certificate by constructing and verifying a 802 certification path for the certificate (including checking 803 relevant CRLs) to the locally configured set of TAs. (See [6] 804 for more details.) 806 Note that when a relying party performs these operations regularly, 807 it is more efficient for the relying party to request from the 808 repository system only those objects that have changed since the 809 relying party last updated its local cache. Note also that by 810 checking all issued objects against the appropriate manifest, the 811 relying party can be certain that it is not missing an updated 812 version of any object. 814 7. Common Operations 816 Creating and maintaining the infrastructure described above will 817 entail additional operations as ''side effects'' of normal resource 818 allocation and routing authorization procedures. For example, a 819 subscriber with ''portable'' address space who entes a relationship 820 with an ISP will need to issue one or more ROAs identifying that ISP, 821 in addition to conducting any other necessary technical or business 822 procedures. The current primary use of this infrastructure is for 823 route filter construction; using ROAs, route filters can be 824 constructed in an automated fashion with high assurance that the 825 holder of the advertised prefix has authorized the first-hop AS to 826 originate an advertised route. 828 7.1. Certificate issuance 830 There are several operational scenarios that require certificates to 831 be issued. Any allocation that may be sub-allocated requires a CA 832 certificate, e.g., so that certificates can be issued as necessary 833 for the sub-allocations. Holders of ''portable'' address allocations 834 also must have certificates, so that a ROA can be issued to each ISP 835 that is authorized to originate a route to the allocation (since the 836 allocation does not come from any ISP). Additionally, multi-homed 837 subscribers may require certificates for their allocations if they 838 intend to issue the ROAs for their allocations (see Section 6.2.2). 839 Other holders of resources need not be issued CA certificates within 840 the PKI. 842 In the long run, a resource holder will not request resource 843 certificates, but rather receive a certificate as a side effect of 844 the allocation process for the resource. However, initial deployment 845 of the RPKI will entail issuance of certificates to existing resource 846 holders as an explicit event. Note that in all cases, the authority 847 issuing a CA certificate will be the entity who allocates resources 848 to the subject. This differs from most PKIs in which a subject can 849 request a certificate from any certification authority. 851 If a resource holder receives multiple allocations over time, it may 852 accrue a collection of resource certificates to attest to them. If a 853 resource holder receives multiple allocations from the same source, 854 the set of resource certificates may be combined into a single 855 resource certificate, if both the issuer and the resource holder 856 agree. This is effected by consolidating the IP Address Delegation 857 and AS Identifier Delegation Extensions into a single extension (of 858 each type) in a new certificate. However, if the certificates for 859 these allocations contain different validity intervals, creating a 860 certificate that combines them might create problems, and thus is NOT 861 RECOMMENDED. 863 If a resource holder's allocations come from different sources, they 864 will be signed by different CAs, and cannot be combined. When a set 865 of resources is no longer allocated to a resource holder, any 866 certificates attesting to such an allocation MUST be revoked. A 867 resource holder SHOULD NOT to use the same public key in multiple CA 868 certificates that are issued by the same or differing authorities, as 869 reuse of a key pair complicates path construction. Note that since 870 the subject's distinguished name is chosen by the issuer, a subject 871 who receives allocations from two sources generally will receive 872 certificates with different subject names. 874 7.2. ROA management 876 Whenever a holder of IP address space wants to authorize an AS to 877 originate routes for a prefix within his holdings, he MUST issue an 878 end-entity certificate containing that prefix in an IP Address 879 Delegation extension. He then uses the corresponding private key to 880 sign a ROA containing the designated prefix and the AS number for the 881 AS. The resource holder MAY include more than one prefix in the EE 882 certificate and corresponding ROA if desired. As a prerequisite, 883 then, any address holder that issues ROAs for a prefix must have a 884 resource certificate for an allocation containing that prefix. The 885 standard procedure for issuing a ROA is as follows: 887 1. Create an end-entity certificate containing the prefix(es) to be 888 authorized in the ROA. 890 2. Construct the payload of the ROA, including the prefixes in the 891 end-entity certificate and the AS number to be authorized. 893 3. Sign the ROA using the private key corresponding to the end- 894 entity certificate (the ROA is comprised of the payload 895 encapsulated in a CMS signed message [7]). 897 4. Upload the end-entity certificate and the ROA to the repository 898 system. 900 The standard procedure for revoking a ROA is to revoke the 901 corresponding end-entity certificate by creating an appropriate CRL 902 and uploading it to the repository system. The revoked ROA and end- 903 entity certificate SHOULD BE removed from the repository system. 905 7.2.1. Single-homed subscribers (without portable allocations) 907 In BGP, a single-homed subscriber with a non-portable allocation does 908 not need to explicitly authorize routes to be originated for the 909 prefix(es) it is using, since its ISP will already advertise a more 910 general prefix and route traffic for the subscriber's prefix as an 911 internal function. Since no routes are originated specifically for 912 prefixes held by these subscribers, no ROAs need to be issued under 913 their allocations; rather, the subscriber's ISP will issue any 914 necessary ROAs for its more general prefixes under resource 915 certificates its own allocation. Thus, a single-homed subscriber with 916 a non-portable allocation is not included in the RPKI, i.e., it does 917 not receive a CA certificate, nor issue EE certificates or ROAs. 919 7.2.2. Multi-homed subscribers 921 In order for multiple ASes to originate routers for prefixes held by 922 a multi-homed subscriber, each AS must have a ROA that explicitly 923 authorizes such route origination. There are two ways that this can 924 be accomplished. 926 One option is for the multi-homed subscriber to obtain a CA 927 certificate from the ISP who allocated the prefixes to the 928 subscriber. The multi-homed subscriber can then create a ROA (and 929 associated end-entity certificate) that authorizes a second ISP to 930 originate routes to the subscriber prefix(es). The ROA for the second 931 ISP generally SHOULD be set to require an exact match, if the intent 932 is to enable backup paths for the prefix. Note that the first ISP, 933 who allocated the prefixes, will want to advertise the more specific 934 prefix for this subscriber (vs. the encompassing prefix). Either the 935 subscriber or the first ISP will need to issue an EE certificate and 936 ROA for the (more specific) prefix, authorizing this ISP to advertise 937 this more specific prefix. 939 A second option is that the multi-homed subscriber can request that 940 the ISP that allocated the prefixes create a ROA that authorizes the 941 second ISP to originate routes to the subscriber's prefixes. (The ISP 942 also creates an EE certificate and ROA for its own advertisement of 943 the subscriber prefix, as above.) This option does not require that 944 the subscriber be issued a certificate or participate in ROA 945 management. Therefore, this option is simpler for the subscriber, and 946 is preferred if the option is supported by the ISP performing the 947 allocation. 949 7.2.3. Portable allocations 951 A resource holder is said to have a portable (provider independent) 952 allocation if the resource holder received its allocation from a 953 regional or national registry. Because the prefixes represented in 954 such allocations are not taken from an allocation held by an ISP, 955 there is no ISP that holds and advertises a more general prefix. A 956 holder of a portable allocation MUST authorize one or more ASes to 957 originate routes to these prefixes. Thus the resource holder MUST 958 generate one or more EE certificates and associated ROAs to enable 959 the AS(es) to originate routes for the prefix(es) in question. This 960 ROA is required because none of the ISP's existing ROAs authorize it 961 to originate routes to that portable allocation. 963 7.3. Route filter construction 965 The goal of this architecture is to support improved routing 966 security. One way to do this is to use ROAs to construct route 967 filters that reject routes that conflict with the origination 968 authorizations asserted by current ROAs. The following is intended to 969 provide a high-level description of how the architecture might be 970 used to construct a route filter. Additional guidance on the use of 971 ROAs to derive inferences about the validity of BGP UPDATE messages 972 is provided in [14]. The guidance in [14] is particularly important 973 during a transition period where not all ISPs implement this 974 architecture (and thus the filter described below which naively 975 rejects all UPDATES without a corresponding ROA would incorrectly 976 reject valid routes originated by ISPs that do not yet implement this 977 architecture). 979 1. Obtain a local copy of all currently valid EE certificates, as 980 specified in Section 5. 982 2. Query the repository system to obtain a local copy of all ROAs 983 issued under the PKI. 985 3. Verify that the each ROA matches the hash value contained in the 986 manifest of the CA certificate used to verify the EE certificate 987 that issued the ROA and that no ROAs are missing. 989 4. Validate each ROA by verifying that its signature is verifiable 990 by a valid end-entity certificate that matches the address 991 allocation in the ROA. (See [7] for more details.) 993 5. Based on the validated ROAs, construct a table of prefixes and 994 corresponding authorized origin ASes (or vice versa). 996 A BGP speaker that applies such a filter is thus guaranteed that for 997 a given IP address prefix, all routes that the BGP speaker accepts 998 for that prefix were originated by an AS that is authorized by the 999 owner of the prefix to authorize routes to that prefix. 1001 The first three steps in the above procedure might incur a 1002 substantial overhead if all objects in the repository system were 1003 downloaded and validated every time a route filter was constructed. 1004 Instead, it will be more efficient for users of the infrastructure to 1005 initially download all of the signed objects and perform the 1006 validation algorithm described above. Subsequently, a relying party 1007 need only perform incremental downloads and validations on a regular 1008 basis. A typical ISP using the infrastructure may choose any 1009 frequency it desires for downloading updates from the repository, 1010 uploading any modifications it has made, and constructing route 1011 filters. However, an ISP might reasonably choose to perform these 1012 actions on a daily schedule. 1014 It should be noted that the transition to 4-byte AS numbers (see RFC 1015 4893 [13]) weakens the security guarantees achieved by BGP speakers 1016 who do not support 4-byte AS numbers (referred to as OLD BGP 1017 speakers). RFC 4893 specifies that all 4-byte AS numbers (except 1018 those whose first two bytes are entirely zero) be mapped to the 1019 reserved value 23456 before being sent to a BGP speaker who does not 1020 understand 4-byte AS numbers. Therefore, when an ISP creates a route 1021 filter for use by an OLD BGP speaker, it must allow any 4-byte AS 1022 number to advertise routes for an IP address prefix if there exists a 1023 ROA that authorizes any 4-byte AS number to advertise routes to that 1024 prefix. This means that if an OLD BGP speaker accepts a route that 1025 was originated by an AS with a 4-byte AS number, there is no 1026 guarantee that it was originated by an authorized 4-byte AS number 1027 (unless the route was propagated by an intermediate NEW BGP speaker 1028 who performed route filtering as described above). 1030 8. Security Considerations 1032 The focus of this document is security; hence security considerations 1033 permeate this specification. 1035 The security mechanisms provided by and enabled by this architecture 1036 depend on the integrity and availability of the infrastructure it 1037 describes. The integrity of objects within the infrastructure is 1038 ensured by appropriate controls on the repository system, as 1039 described in Section 4.4. Likewise, because the repository system is 1040 structured as a distributed database, it should be inherently 1041 resistant to denial of service attacks; nonetheless, appropriate 1042 precautions should also be taken, both through replication and backup 1043 of the constituent databases and through the physical security of 1044 database servers 1046 9. IANA Considerations 1048 This document makes no request of IANA. 1050 Note to RFC Editor: this section may be removed on publication as an 1051 RFC 1053 10. Acknowledgments 1055 The architecture described in this draft is derived from the 1056 collective ideas and work of a large group of individuals. This work 1057 would not have been possible without the intellectual contributions 1058 of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of 1059 APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Time 1060 Christensen and Cathy Murphy of ARIN, Rob Austein of ISC and Randy 1061 Bush of IIJ. 1063 Although we are indebted to everyone who has contributed to this 1064 architecture, we would like to especially thank Rob Austein for the 1065 concept of a manifest, Geoff Huston for the concept of managing 1066 object validity through single-use EE certificate key pairs, and 1067 Richard Barnes for help in preparing an early version of this 1068 document. 1070 11. References 1072 11.1. Normative References 1074 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1075 Levels", BCP 14, RFC 2119, March 1997. 1077 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 1078 (BGP-4)", RFC 4271, January 2006 1080 [3] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 1081 R., and W. Polk, "Internet X.509 Public Key Infrastructure 1082 Certificate and Certificate Revocation List (CRL) Profile", RFC 1083 5280, May 2008. 1085 [4] Housley, R., ''Cryptographic Message Syntax'', RFC 3852, July 1086 2004. 1088 [5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1089 Addresses and AS Identifiers", RFC 3779, June 2004. 1091 [6] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 1092 X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs- 1093 14, October 2008. 1095 [7] Lepinski, M., Kent, S., and Kong, D., "A Profile for Route 1096 Origin Authorizations (ROA)", draft-ietf-sidr-roa-format-04, 1097 November 2008. 1099 [8] Austein, R., et al., ''Manifests for the Resource Public Key 1100 Infrastructure'', draft-ietf-sidr-rpki-manifests-04, October 1101 2008. 1103 11.2. Informative References 1105 [9] Huston, G., Michaelson, G., and Loomans, R., ''A Profile for 1106 Resource Certificate Repository Structure'', draft-ietf-sidr- 1107 repos-struct-01, October 2008. 1109 [10] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway 1110 Protocol (Secure-BGP)'', IEEE Journal on Selected Areas in 1111 Communications Vol. 18, No. 4, April 2000. 1113 [11] White, R., "soBGP", May 2005, 1116 [12] Tridgell, A., "rsync", April 2006, 1117 1119 [13] Vohra, Q., and Chen, E., ''BGP Support for Four-octet AS Number 1120 Space'', RFC 4893, May 2007. 1122 [14] Huston, G., Michaelson, G., ''Validation of Route Origination 1123 in BGP using the Resource Certificate PKI'', draft-ietf-sidr- 1124 roa-validation-01, October 2008. 1126 Authors' Addresses 1128 Matt Lepinski 1129 BBN Technologies 1130 10 Moulton St. 1131 Cambridge, MA 02138 1133 Email: mlepinski@bbn.com 1135 Stephen Kent 1136 BBN Technologies 1137 10 Moulton St. 1138 Cambridge, MA 02138 1140 Email: kent@bbn.com 1142 Intellectual Property Statement 1144 The IETF takes no position regarding the validity or scope of any 1145 Intellectual Property Rights or other rights that might be claimed to 1146 pertain to the implementation or use of the technology described in 1147 this document or the extent to which any license under such rights 1148 might or might not be available; nor does it represent that it has 1149 made any independent effort to identify any such rights. Information 1150 on the procedures with respect to rights in RFC documents can be 1151 found in BCP 78 and BCP 79. 1153 Copies of IPR disclosures made to the IETF Secretariat and any 1154 assurances of licenses to be made available, or the result of an 1155 attempt made to obtain a general license or permission for the use of 1156 such proprietary rights by implementers or users of this 1157 specification can be obtained from the IETF on-line IPR repository at 1158 http://www.ietf.org/ipr. 1160 The IETF invites any interested party to bring to its attention any 1161 copyrights, patents or patent applications, or other proprietary 1162 rights that may cover technology that may be required to implement 1163 this standard. Please address the information to the IETF at 1164 ietf-ipr@ietf.org. 1166 Disclaimer of Validity 1168 This document and the information contained herein are provided on an 1169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1171 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1172 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1173 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1176 Copyright Statement 1178 Copyright (C) The IETF Trust (2008). 1180 This document is subject to the rights, licenses and restrictions 1181 contained in BCP 78, and except as set forth therein, the authors 1182 retain all their rights.