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