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