idnits 2.17.1 draft-kent-sidr-suspenders-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2013) is 3874 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 294 -- Looks like a reference, but probably isn't: '1' on line 295 -- Looks like a reference, but probably isn't: '2' on line 284 -- Looks like a reference, but probably isn't: '3' on line 277 -- Looks like a reference, but probably isn't: '4' on line 278 == Missing Reference: 'RFCxxxx' is mentioned on line 633, but not defined ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing S. Kent 3 Internet-Draft D. Mandelberg 4 Intended status: Standards Track BBN Technologies 5 Expires: March 14, 2014 September 10, 2013 7 Suspenders: A Fail-safe Mechanism for the RPKI 8 draft-kent-sidr-suspenders-00 10 Abstract 12 The Resource Public Key Infrastructure (RPKI) is an authorization 13 infrastructure that allows the holder of Internet Number Resources 14 (INRs) to make verifiable statements about those resources. The 15 certification authorities (CAs) in the RPKI issue certificates to 16 match their allocation of INRs. These entities are trusted to issue 17 certificates that accurately reflect the allocation state of 18 resources as per their databases. However, there is some risk that a 19 CA will make inappropriate changes to the RPKI, either accidentally 20 or deliberately (e.g., as a result of some form of "government 21 mandate"). The mechanisms described below, and referred to as 22 "Suspenders" are intended to address this risk. 24 Suspenders enables an INR holder to publish information about changes 25 to objects it signs and publishes in the RPKI repository system. 26 This information is made available via a file that is external to the 27 RPKI repository, so that Relying Parties (RPs) can detect erroneous 28 or malicious changes related to these objects. RPs can then decide, 29 individually, whether to accept changes that are not corroborated by 30 independent assertions by INR holders, or to revert to previously 31 verified RPKI data. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 14, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. The LOCK Record and INRD File . . . . . . . . . . . . . . . . 4 70 3.1. LOCK Record Format and Semantics . . . . . . . . . . . . 4 71 3.2. INRD File Format and Semantics . . . . . . . . . . . . . 6 72 4. Self-checking by RPs . . . . . . . . . . . . . . . . . . . . 9 73 5. Detection & Remediation . . . . . . . . . . . . . . . . . . . 10 74 6. INRD Management Scenarios . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Informative References . . . . . . . . . . . . . . . . . 14 80 10.2. Normative References . . . . . . . . . . . . . . . . . . 15 81 Appendix A. RPKI Object Whacking and Competition . . . . . . . . 15 82 Appendix B. Design Criteria (do we still need this section?) . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Overview 87 The Resource Public Key Infrastructure (RPKI) is an authorization 88 infrastructure that allows the holder of Internet number resources 89 (INRs) to make verifiable statements about those resources. For 90 example, the holder of a block of IP(v4 or v6) addresses can issue a 91 Route Origination Authorization (ROA) to authorize an autonomous 92 system to originate routes for that block. 94 The certification authorities (CAs) in the RPKI issue certificates to 95 match their allocation of INRs. These entities are trusted to issue 96 certificates that accurately reflect the allocation state of 97 resources as per their databases. However, there is some risk that a 98 CA will make inappropriate changes to the RPKI, either accidentally 99 or deliberately (e.g., as a result of some form of "government 100 mandate"). 102 Assertions by INR holders about their resources, and about bindings 103 among resources, are realized by publishing RPKI signed objects via 104 the RPKI repository system [RFC6481]. For example, authorization to 105 originate a route for a prefix is accomplished by issuing a ROA. 106 Changes in the RPKI can have an adverse impact on routing in the 107 Internet, by changing the set of (valid) signed objects for a 108 resource. Invalidating a ROA could cause the origin authorized by 109 the ROA in question to be less preferred; adding a ROA for a more 110 specific prefix could enable an unauthorized party to represent 111 itself as the legitimate origin for traffic for that prefix. 113 The goal of Suspenders is to minimize the likelihood that changes to 114 the RPKI will adversely affect INR holders, irrespective of whether 115 the changes are inadvertent or malicious. Suspenders should work 116 when an INR holder acts as its own CA (and manages its own 117 publication point), and when the INR holder has outsourced these 118 management functions. Suspenders allows each INR holder to assert a 119 "lock" on selected objects at its publication point, to protect the 120 bindings asserted by these objects. Changes to protected objects are 121 confirmed by the INR holder, via a file published outside the 122 repository system. Changes to the validity of protected objects, 123 effected by changes to any other objects in the RPKI, are presumed to 124 be unauthorized (and thus suspicious), unless independently confirmed 125 by the INR holder. 127 Detection of potentially adverse changes is carried out by each INR 128 holder for its own resources, and by each RP that elects to implement 129 Suspenders. It is critical that an INR holder be able to quickly 130 detect adverse changes that affect its own resources, so that it can 131 initiate actions to remedy the problem. RPs should be able to detect 132 potentially adverse changes, that are not authorized by INR holders, 133 so that they can (at their discretion) use cached, validated data in 134 lieu of such changes. The model adopted here is to assume that 135 changes to previously-validated data should not be accepted, unless 136 authorized by the relevant INR holder. Thus RPs who detect changes 137 need to be able to verify that these changes are authorized by the 138 INR holder. Because not all INR holders manage their own CAs and 139 publication points, an external mechanism is used to signal 140 authorized changes to RPs. 142 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. The LOCK Record and INRD File 149 An INR holder that elects to protect its resources and resource 150 bindings creates a LOCK record in its publication point. The INR 151 holder also generates and signs an Internet Number Resource 152 Declaration (INRD) file, and publishes it at a location independent 153 of the RPKI repository system. The LOCK record consists of a URL 154 that points to the INRD file, and a public key used to verify a 155 signature on the content of that file. (This public key is distinct 156 from any used by the INR holder in the RPKI context.) The INRD file 157 contains the date at which the most recent changes were made, and 158 enumerates those changes. The formats of the LOCK record and INRD 159 file are described below. 161 3.1. LOCK Record Format and Semantics 163 The LOCK record conforms to the signed object specification from 164 [RFC6488], which, in turn, uses the CMS [RFC5652] signed-data object 165 format. See [RFC6488] for the top-level signed-data format and the 166 constraints imposed on that format for use in the RPKI context. The 167 LOCK encapsulated content is defined below: 169 EncapsulatedContentInfo ::= SEQUENCE { 170 eContentType ContentType, 171 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 173 ContentType ::= OBJECT IDENTIFIER 175 The eContentType for an LOCK record is defined as id-ct-rpkiLOCK and 176 it has the numeric value 1.2.840.113549.1.9.16.1.XX. 178 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 179 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 181 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 183 id-ct-rpkiLOCK OBJECT IDENTIFIER ::= { id-ct XX } 185 The eContent for an LOCK record is defined by the following ASN.1 187 LOCK ::= SEQUENCE { 188 version [0] INTEGER DEFAULT 0, 189 outsourced BOOLEAN, 190 uRL IA5String, 191 publicKey SubjectPublicKeyInfo } 193 SubjectPublicKeyInfo ::= SEQUENCE { 194 algorithm AlgorithmIdentifier, 195 subjectPublicKey BIT STRING } 197 The EE certificate embedded in the LOCK record MUST use the inherit 198 flag in the [RFC3779] extensions. (The content of the LOCK is 199 independent of the 3779 extensions in the EE certificate, so it is 200 appropriate to use the inherit flag here.) 202 The version number of the LOCK record determines the set of RPKI 203 object types that it protects. Version 0 protects the LOCK record 204 itself, ROAs, (subordinate) CA certificates, and router certificates 205 (if present). 207 The algorithm and subjectPublicKey fields in the publicKey MUST 208 conform to the guidance in Section 3 of [RFC6485]. 210 If an RP elects to process a LOCK record, it verifies the signature 211 on the record using the procedure described in [RFC6488]. If the 212 signature verification fails, it ignores the record. (If the RP has 213 a previously validated LOCK record, it continues to use that record 214 instance.) 216 If the signature verification succeeds, the RP extracts the version 217 number and verifies that the RP is prepared to process this version 218 of the record. If not, it ignores the record. If it is prepared to 219 process this version, it extracts the URL and public key fields. The 220 URL is used to fetch the corresponding INRD file, and the public key 221 is used to verify the signature on that file. 223 If the RP has a copy of an INRD file for this publication point, and 224 if the RP detects no material changes to the protected records at the 225 publication point, the RP SHOULD NOT fetch the INRD file. (A 226 material change is one that affects the semantics of the object. For 227 example, for a ROA, only changes to the prefixes and/or ASN are 228 material.) If the RP does not hold a copy of the INRD file, or if a 229 protected record has changed, the RP fetches a new INRD file using 230 the URL, and proceeds as described in Section 3.2. 232 When an INR holder has outsourced management of its RPKI CA function 233 and publication point, it is susceptible to attacks in which the LOCK 234 record itself is changed. This is because the entity providing these 235 functions could create a new LOCK record containing a new URL and 236 public key, thus defeating the LOCK/INRD mechanism. An authorized 237 change to the content of a LOCK record should be very rare. A 238 location selected as a home for an INRD file should be stable, and 239 thus the URL should rarely change. The public key used to verify the 240 signature on an INRD file should also be constant for long intervals. 241 The LOCK record contains a flag that indicates whether the INR holder 242 has outsourced CA and publication point management. If this flag is 243 FALSE, an RP will accept changes to the LOCK record (see Section 5) 244 just as it would changes to any other object at a protected 245 publication point. If the flag is TRUE, then any change to a LOCK 246 record is regarded as suspicious by RPs. In such cases the RP delays 247 accepting the new LOCK record and associated INRD file, as discussed 248 in Section 5. 250 3.2. INRD File Format and Semantics 252 The INRD file is a DER-encoded ASN.1 file that contains data 253 associated with a single INR holder (publication point owner). The 254 file is encoded using ASN.1, since most of the values it holds will 255 be compared to data from RPKI objects that also are ASN.1 encoded, 256 and because it is a signed object. 258 INRD ::= SEQUENCE { 259 tbsINRD TBSINRD, 260 algorithm AlgorithmIdentifier, 261 signature OCTET STRING 262 } 264 TBSINRD ::= SEQUENCE { 265 version [0] INTEGER DEFAULT 0, 266 lastChange UTCTime, 267 changeWindow ENUMERATED 268 { 269 1week (7) DEFAULT 270 2week (14) 271 4week (28) 272 }, 273 additions [1] SEQUENCE SIZE (1..MAX) OF 274 ProtectedObject OPTIONAL, 275 deletions [2] SEQUENCE SIZE (1..MAX) OF 276 ProtectedObject OPTIONAL, 277 keyRollover [3] OCTET STRING OPTIONAL, 278 algRollover [4] OCTET STRING OPTIONAL 279 } 281 ProtectedObject ::= CHOICE { 282 cmsObject [0] EncapsulatedContentInfo, 283 rtrCert [1] RtrCertInfo, 284 cACert [2] CACertInfo 285 } 287 RtrCertInfo ::= SEQUENCE { 288 subjKeyId OCTET STRING, 289 aSNum INTEGER 290 } 292 CACertInfo ::= SEQUENCE { 293 subjKeyId OCTET STRING, 294 ipAddrBlocks [0] IPAddrBlocks OPTIONAL, 295 aSIdentifiers [1] ASIdentifiers OPTIONAL 296 } 298 -- See [RFC3779] for the definitions of IPAddrBlocks and 299 -- ASIdentifiers. 301 The lastChange and changeWindow values are used to bound the set of 302 additions and deletions stored in an INRD file. The default is a one 303 week window, but two and four week values also may be expressed. The 304 window determines the oldest time at which changes to protected 305 objects at the publication point are represented in the additions and 306 deletions portions of the file. 308 The additions element is used by an INR holder to list all protected 309 objects that have been added to the publication point over the 310 interval defined by the change window. If no objects have been added 311 during this interval, the element is omitted. Similarly, the 312 deletions element is used by an INR holder to list all protected 313 objects that have been removed from the publication point over the 314 interval defined by the change window. If no objects have been 315 removed during this interval, the element is omitted. 317 A LOCK or ROA is listed in the additions and/or deletions fields by 318 putting its EncapsulatedContentInfo in the cmsObject field of a 319 ProtectedObject. A router certificate is listed by putting its SKI 320 and AS number in the rtrCert field. A CA certificate is listed by 321 putting its SKI and [RFC3779] resources in the cACert field. If the 322 outsourced flag in the LOCK record is FALSE, then no CA certificates 323 should be included in the additions or deletions elements. If any CA 324 certificates are included in these elements, they are ignored. RPs 325 SHOULD accept all valid CA certificates issued at this publication 326 point when the outsourced flag is FALSE. 328 The key rollover element is present only during the time when a key 329 rollover [RFC6489] is taking place. It signals to RPs that an 330 additional set of objects exist that would ordinarily be viewed as 331 competing with the objects protected by this INRD file. The SKI 332 contained here is that of the CA for the "other" key. During key 333 rollover each CA will have its own LOCK record, that points to its 334 own INRD file. The old CA will list the new CA's SKI here; the new 335 CA will not include this field. Key rollover is a transient 336 condition, so the need for both LOCK records and INRD files ought not 337 be very long. 339 The algorithm rollover element is present during the time when an 340 algorithm rollover [RFC6916] is taking place. It signals to RPs that 341 an additional set of objects exist that would ordinarily be viewed as 342 competing with the objects protected by this INRD file. The SKI 343 contained here is that of the CA for the "other" algorithm. During 344 algorithm rollover each CA will have its own LOCK record, that points 345 to its own INRD file, and each of them will list the other CA's SKI 346 here. (Note that the SKI value is compared against the SKI in the CA 347 certificate in question. An RP does not compute an SKI. This means 348 that changes to the hash algorithm used to compute an SKI do not 349 affect how an RP processes this field. An RP MUST be prepared to 350 deal with an SKI length other than the 20 octet value in common use 351 today.) Algorithm transition is a long process, so both sets of LOCK 352 records and INRD files will persist for an extended period. 354 An RP fetches an INRD file using a URL from a LOCK record, as noted 355 above. If the file cannot be located, the RP software logs an error 356 and regards any changes to the publication point as suspicious. If 357 the file is located, the RP verifies the signature on the file using 358 the public key (and indicated algorithms) from the same LOCK record. 359 If the signature fails, the RP software logs an error and regards any 360 changes to the publication point as suspicious. If the signature is 361 valid, the RP extracts the data elements from the INRD file. 363 If this is the first time that an INRD file is fetched for this 364 publication point, the file is accepted, and its content is used to 365 populate the RP's expanded local cache. If the INRD file is 366 replacing a previously acquired instance for this publication point, 367 the content is used to confirm changes to protected objects at this 368 publication point. If an RP detects changes to protected publication 369 point objects that occurred after the lastChange time, these changes 370 are treated as suspicious. 372 Authorizing changes to subordinate CA certificates in an INRD file is 373 critical when an INR holder outsources CA and publication point 374 management. Listing these CAs and their associated 3779 extension 375 data enables an RP to detect creation of unauthorized CAs that could 376 then create competing ROAs or router certificates. However, if an 377 INR holder operates its own CA and manages its publication point, it 378 is not necessary to protect against such attacks. To signal this 379 situation, the "outsourced" flag in the LOCK record is set to FALSE. 380 Under this condition, an RP will not impose change control checks on 381 subordinate CA certificates for the publication point. 383 Some classes of INR holders need not publish a LOCK record and INRD 384 file. IANA, RIRs, and NIRs, are principally delegators of resources. 385 Each of these RPKI entities SHOULD create one publication point for 386 the resources used by the entity for its own networking needs, and a 387 separate publication point under which all resource delegations take 388 place. The first publication point MAY be protected by a LOCK 389 record, so that ROAs and router certificates associated with those 390 resources can be protected. However, the second publication point 391 OUGHT not include a LOCK record. If this convention is followed, 392 these classes of INR holders need not update an INRD file every time 393 a new subordinate CA is created or modified, as a result of 394 delegation. If an INR holder follows this convention, and includes a 395 LOCK record in its superior publication point, that record, and the 396 associated INRD file, conveys some degree of protection for the 397 subordinate CA resources, even if the INR holders of these resources 398 do not publish LOCK records. 400 4. Self-checking by RPs 402 It is easy for an INR holder, acting as an RP, to determine if any of 403 its resource bindings have been undermined via the RPKI. It knows 404 what resources it holds, and what assertions it has made relevant to 405 those resources. Any conflicting RPKI objects represent a problem! 406 It is more difficult for an RP to detect problems with another INR 407 holder's resources, because it lacks the knowledge that the other INR 408 holder has. The mechanisms described in Section 5 are designed to 409 enable RPs to detect these problems. This section describes the 410 procedures each RP executes to detect adverse changes to its own data 411 in the RPKI repository system. Note that the procedures in this 412 section do not require use of the LOCK record or INRD file. 414 When and INR downloads RPKI data, as it normally does, it SHOULD 415 perform the checks noted below, to detect problems. To enable such 416 checking, each INR holder's RP software MUST be configured with data 417 about the ROAs, and other protected objects, of this INR holder. If 418 any of these objects are missing or fail to validate, then the INR 419 holder has detected a problem, and is notified. 421 The semantics of ROAs require an additional check; if other ROAs for 422 the same or more specific prefixes are found anywhere in the RPKI 423 repository system, this too indicates a problem, and the INR holder 424 is notified. 426 The semantics of router certificates, require a separate, additional 427 check. A router certificate binds a public key (and a router ID) to 428 an ASN. Thus, if an INR holder discovers router certificates for its 429 ASN, that it did not authorize, this indicates a problem. 431 As additional objects are protected via this mechanism, it will be 432 necessary to perform additional checks to detect the latter sort of 433 adverse changes, based on the semantics of the protected objects. 435 In any case, RP software SHOULD inform the INR holder of the apparent 436 cause and source of the problem, e.g., a revoked or expired 437 certificate or a manifest problem, and guide the INR holder to the 438 responsible CAs (e.g., using Ghostbusters [RFC6493] records). 440 When an INR holder is alerted to a change adversely affecting its own 441 resources, it is expected to contact the appropriate RPKI entities to 442 rectify the error in a timely fashion. If the changes are determined 443 to be intentional (and not authorized by the INR holder), the INR 444 holder can inform the Internet operations community (via an out of 445 band mechanism), which can then decide, individually, how to respond. 447 Remedying a problem detected by an INR holder is not likely to be 448 instantaneous, even if the problem is just an error. To avoid 449 adversely affecting routing, the mechanisms described in Section 5 450 enable RPs to detect a change that adversely affects INR holders, and 451 to reject it, reverting to previously validated INR data. This gives 452 the INR holder time to resolve the problem. Reverting to an earlier 453 version of INR data is conceptually easy for RPs, because they 454 already cache RPKI data. The mechanisms described below require 455 augmenting the RPKI local cache maintained by each RP, to detect 456 adverse changes, making use of information gleaned from LOCK records 457 and INRD files. The next section describes how the LOCK and INRD 458 data is used. 460 5. Detection & Remediation 462 The design described in this section assumes that an RP has acquired 463 a snapshot of the RPKI repository, validated and extracted INR 464 holding and binding data, and considers this data to be "good". The 465 detection and remediation algorithm is initialized by acquiring a 466 complete download of RPKI repository data, and by fetching INRD files 467 for all publication points that contain a LOCK record. (Prior to 468 this initialization step, it is not possible for an RP to detect and 469 respond to adverse changes to the RPKI, using the technique described 470 below.) 472 Each RP already maintains a cache of RPKI data [RFC6480], [RFC6481]; 473 this document extends that cache. For every publication point that 474 contains a LOCK record, the content of that record, and the 475 corresponding INRD file content, become part of the data maintained 476 by each RP. 478 An RP acquires and validates all changed RPKI objects as usual. An 479 RP does not update its cache with the changes, until additional 480 checks, described below, are performed. Before accepting any changes 481 the RP MUST process every pub point where there is (or was) a LOCK 482 record. For each of these pub points, if there are changes to 483 protected objects, these changes must be confirmed by the 484 corresponding INRD file before they are accepted. If any of these 485 checks fail, the changes are held in escrow, waiting for a timeout 486 (or an updated INRD file?). After all protected pub point changes 487 have been processed, then changes for unprotected pub point can be 488 accepted. The checks will detect pending changes that would whack or 489 compete with protected objects, and place them in escrow. 491 After validating all changed objects downloaded from the RPKI 492 repository, an RP performs the following additional checks for every 493 publication point that has (or had) a LOCK record: 495 o ROA and router certificate whacking 497 o INR sub-delegation changes 499 o ROA competition 501 o router certificate competition 503 o LOCK record changes 505 A ROA or a router certificate has been whacked (see Appendix A) if it 506 was valid and is now missing or invalid, and if it is not indicated 507 as deleted in the INRD file of its issuer. Any previously valid ROA 508 that is no longer valid (or missing) is checked against the INRD file 509 for the ROA issuer, to determine if the ROA or (router certificate) 510 certificate has been legitimately revoked/removed. If the INRD file 511 confirms the action, the old ROA (or router certificate) is removed 512 from the local cache. If not, the old ROA (or router certificate) is 513 retained, but marked as suspicious. 515 Changes to INR sub-delegation occur when the INR holder issues a new 516 CA certificate, an existing child CA certificate expires, or any 517 other change affects the status of a child CA certificate. These 518 changes are accepted by an RP only if they are confirmed in the INR 519 holder's INRD file. 521 A newly issued ROA is in competition (see Appendix A) with an 522 existing ROA if the new ROA specifies the same or a more specific 523 prefix than the older ROA, the new ROA is not issued by one of the 524 existing ROA's issuer's descendants, and the new ROA was not 525 authorized by the INRD file of the existing ROA. A competing ROA is 526 not accepted as valid by an RP. 528 A newly-issued router certificate competes with an existing router 529 certificate, if the new certificate includes the same ASN and was not 530 authorized by the INRD file covering the existing router certificate. 531 A competing router certificate is not accepted as valid by an RP. 532 (Such a certificate would be accepted if the INRD file of the issuer 533 of the original certificate indicates that the old certificate has 534 been deleted, and not replaced with a new router certificate 535 associated with the same entity. In this case, the newly-issued 536 certificate would not be in competition.) 538 As noted above, any change to a LOCK record is viewed as suspicious 539 unless the outsourced flag is FALSE. If the record is for a 540 publication point that is not outsourced, then a changed LOCK record 541 is accepted as valid if the corresponding INRD file authorizes the 542 new record. (If the INR holder has changed the public key for the 543 INRD file, it is RECOMMENDED that the URL also change. This allows 544 the INR holder to publish a new INRD file that authorizes the new 545 LOCK record, minimizing the potential race condition between updating 546 an INRD file and a LOCK record.) 548 If the LOCK record shows that the publication point is outsourced, an 549 RP examines the changes made to the LOCK record. If the URL has 550 changed, but the public key and the outsource flag are unchanged, the 551 new LOCK record may be accepted, if the new INRD file authorizes the 552 change. If not, the new LOCK record is rejected. If the public key 553 has been changed, a delay is imposed on accepting the new LOCK 554 record, even if the INRD file authorizes the change. (should we 555 establish a global delay, or should each INR holder publish its own 556 delay preference in the INRD file?) 558 Remediation for all of the whacking and competition events consists 559 of NOT making a change in the local cache when an unconfirmed change 560 is encountered. 562 6. INRD Management Scenarios 564 Common wisdom notes that we cannot choose our parents, but we can 565 choose our friends, and we should do so wisely. In the RPKI context, 566 and INR holder cannot, generally choose its CA, but Suspenders allows 567 the INR holder to choose its INRD file server. It should do so 568 wisely. 570 An INRD file is published outside of the RPKI repository system, and 571 is verified using a public key that is also independent of the RPKI. 572 The motivation for these two measures is to insulate this part of the 573 Suspenders system from possible manipulation by an entity to whom CA 574 and publication point services have been outsourced. If an INR 575 holder acts as its own CA, and manages its own publication point, it 576 can publish its INRD file on the same machines as its publication 577 point, but not in the publication point. In this case the 578 independence features are not critical, but they also don't cause 579 harm for this class of INR holder. 581 Every INR holder needs to choose a location for the INRD file that is 582 highly available. When an INR holder has outsourced CA and 583 publication point management, independent publication of the INRD 584 file is critical. The INR holder needs to choose a location for the 585 INRD file that is highly available. It also is appropriate to 586 consider placing the file outside of the geopolitical region in which 587 the INR holder (and its RIR) operate. Here too the motivation is to 588 insulate the INR holder from a malicious action by the CA service 589 provider, or, perhaps, an RIR above it. 591 Organizations may arise to offer hosting for INRD files, as a service 592 for INR holders. They could offer just file storage, or they might 593 offer more extensive services. For example, an organization might 594 monitor an INR holder's publication point and create the INRD file 595 data, and even sign it for the INR holder. (In this case the 596 organization would provide the public key to the INR holder for 597 inclusion in the LOCK record.) Various other arrangements between 598 the INR holder and a organization that assists in managing INRD files 599 are possible, and are a local matter between the INR holder and the 600 organization. 602 A country might elect to mandate use of Suspenders, as a means to 603 protect the INRs of its ISPs and other organizations that run BGP 604 with in the country. The motivation is similar to that cited above, 605 i.e., protecting INRs against errors or malicious actions by RPKI 606 entities. In this case the country itself generally is not an INR 607 holder per se, so the relationship is somewhat different from that 608 discussed above. Nonetheless, the mechanisms described above apply. 610 For example, Elbonia might mandate that every INR holder within the 611 country make use of Suspenders. Every Elbonian INR holder will be 612 required to include a LOCK record in its publication point, no matter 613 where that publication point is realized. The URL in each LOCK 614 points to a file on a server managed by an Elbonian government 615 organization. Each Elbonian ISP would be required to follow the 616 procedures described in Section 5, when managing its local cache. 618 7. IANA Considerations 620 This document registers the following in the "RPKI Signed Object" 621 registry created by [RFC6488]: 623 Name: LOCK 624 OID: 1.2.840.113549.1.9.16.1.XX 625 Reference: [RFCxxxx] (this document) 627 This document also registers the following three-letter filename 628 extension in the "RPKI Repository Name Schemes" registry created by 629 [RFC6481]: 631 Filename extension: lck 632 RPKI Object: LOCK 633 Reference: [RFCxxxx] (this document) 635 8. Security Considerations 637 This document specifies Suspenders, a set of security-focused 638 mechanisms designed to protect INR holders against accidental and 639 malicious changes to RPKI repository data, and to enable RPs to 640 detect and respond to such changes. More text to be provided later. 642 9. Acknowledgements 644 Richard Barnes provided the motivation to develop Suspenders, after 645 he identified a problem with the LTAM [I-D.ietf-sidr-ltamgmt] design. 647 10. References 649 10.1. Informative References 651 [I-D.ietf-sidr-ltamgmt] 652 Reynolds, M., Kent, S., and M. Lepinski, "Local Trust 653 Anchor Management for the Resource Public Key 654 Infrastructure", draft-ietf-sidr-ltamgmt-08 (work in 655 progress), April 2013. 657 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 658 Secure Internet Routing", RFC 6480, February 2012. 660 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 661 Resource Certificate Repository Structure", RFC 6481, 662 February 2012. 664 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 665 Authority (CA) Key Rollover in the Resource Public Key 666 Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012. 668 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 669 Ghostbusters Record", RFC 6493, February 2012. 671 10.2. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 677 Addresses and AS Identifiers", RFC 3779, June 2004. 679 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 680 RFC 5652, September 2009. 682 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 683 Use in the Resource Public Key Infrastructure (RPKI)", RFC 684 6485, February 2012. 686 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 687 Template for the Resource Public Key Infrastructure 688 (RPKI)", RFC 6488, February 2012. 690 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 691 Procedure for the Resource Public Key Infrastructure 692 (RPKI)", BCP 182, RFC 6916, April 2013. 694 Appendix A. RPKI Object Whacking and Competition 696 There are two ways that an RPKI object can be adversely affected. We 697 term these actions "whacking" and "competition." 699 Any object in the RPKI can become invalid or inaccessible (to RPs) 700 via various actions by CAs and/or publication point maintainers along 701 the certificate path from the object's EE certificate to a trust 702 anchor (TA). Any action that causes an object to become invalid or 703 inaccessible is termed "whacking". Revocation of the EE certificate 704 for an object whacks it. Revocation of any CA certificate along the 705 certificate path for the object (without reissuance) has the same 706 effect. Reissuance of any CA certificate along the certificate path, 707 with changes in [RFC3779] extensions in any of these certificates to 708 exclude the resources cited in a targeted object, also constitutes 709 whacking. Changing a manifest along the certificate path might whack 710 an object (depending on how RPs deal with manifest changes), and 711 removing an object from the RPKI repository system also potentially 712 whacks it. Unless an action that causes an object to be whacked is 713 authorized by the creator of an object, whacking is an attack against 714 the INR holder that created the whacked object. 716 A different form of attack is termed object "competition". The 717 details of object competition are determined by the semantics of the 718 object. In the general case, one object competes with another object 719 (of the same type), if the newer object creates a binding that 720 adversely affects the binding expressed in the original object. So, 721 for example, a newly issued ROA competes with an existing ROA if the 722 new ROA contains the same or more specific prefixes than the older 723 ROA. Competition does not always indicate an attack; the transfer of 724 resources in a "make before break" model implies ROA competition. A 725 newly issued router certificate competes with a previously issued one 726 if the new certificate binds the same ASN to a public key issued by a 727 different entity. (If key rollover or algorithm transition is in 728 progress, such competition is explicitly authorized via the INRD 729 file.) 731 Competition that is not authorized by the issuer of the original 732 router certificate is viewed as an attack against that certificate. 734 Appendix B. Design Criteria (do we still need this section?) 736 Several criteria were employed in developing the mechanisms described 737 in this document. 739 1. It is anticipated that object whacking and competition, and 740 analogous forms of errors that adversely impact INR holders, will 741 be infrequent. Thus the detection mechanisms employed by RPs to 742 detect such anomalies ought to be efficient (in terms of data 743 fetching, processing, and storage) for the normal case. 745 2. RPs may elect to ignore/reject adverse changes to objects if they 746 perceive such changes as suspicious. If an RP elects to reject a 747 change to an object it must have access to previously validated 748 objects for the INR holder question. 750 3. Transfers of "live" address space will occur, although not 751 frequently. INR holders engaged in such transfers must be able 752 to signal to RPs that such transfers are authorized, so that the 753 transfers are not rejected as suspicious. 755 4. Routes for a prefix may be legitimately originated by more than 756 one AS (MOA). The design MUST enable an INR holder to inform RPs 757 when this situation is authorized. 759 5. Many INR holders may choose to outsource CA and publication point 760 management functions. INR holders who choose to outsource these 761 functions should be offered equivalent protection against ROA 762 invalidation and competition as INR holders who perform these 763 functions for themselves. 765 6. Any new RPKI repository objects used with the mechanisms defined 766 here MUST conform to the format specified in [RFC6488]. 768 7. The decision to process any additional data associated with the 769 mechanisms described in this document is local to each RP. RPs 770 that choose to not implement these mechanisms will incur minimal 771 additional data fetching, storage, and processing burdens. 773 8. The decision to employ the mechanisms described here to protect 774 INR holdings and binding is a local one made by each INR holder. 775 (INR holders who outsource CA and publication point management 776 functions will require the providers of these services to support 777 creation and publication of one new RPKI object. As a result, 778 all such providers must support generation and maintenance of the 779 new RPKI object so that their clients have the option to utilize 780 these capabilities.) 782 9. Revocation and expiration of RPKI object MUST continue to work as 783 they do currently, for all objects that have not been adversely 784 affected. 786 Authors' Addresses 788 Stephen Kent 789 BBN Technologies 790 10 Moulton St. 791 Camridge, MA 02138 792 US 794 Email: kent@bbn.com 796 David Mandelberg 797 BBN Technologies 798 10 Moulton St. 799 Camridge, MA 02138 800 US 802 Email: david@mandelberg.org