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