idnits 2.17.1 draft-ietf-sidrops-bgpsec-rollover-04.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 (December 11, 2017) is 2327 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rtr-keying-14 == Outdated reference: A later version (-13) exists of draft-sriram-replay-protection-design-discussion-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Weis 3 Internet-Draft R. Gagliano 4 Intended status: Best Current Practice Cisco Systems 5 Expires: June 14, 2018 K. Patel 6 Arrcus, Inc. 7 December 11, 2017 9 BGPsec Router Certificate Rollover 10 draft-ietf-sidrops-bgpsec-rollover-04 12 Abstract 14 Certification Authorities (CAs) within the Resource Public Key 15 Infrastructure (RPKI) manage BGPsec router certificates as well as 16 RPKI certificates. The rollover of BGPsec router certificates must 17 be carefully performed in order to synchronize the distribution of 18 router public keys with BGPsec Update messages verified with those 19 router public keys. This document describes a safe rollover process, 20 as well as discussing when and why the rollover of BGPsec router 21 certificates are necessary. When this rollover process is followed 22 the rollover will be performed without routing information being 23 lost. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 14, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Key rollover in BGPsec . . . . . . . . . . . . . . . . . . . 3 62 3.1. Rollover Process . . . . . . . . . . . . . . . . . . . . 4 63 4. BGPsec router key rollover as a measure against replay 64 attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. BGP UPDATE window of exposure requirement . . . . . . . . 6 66 4.2. BGPsec key rollover as a mechanism to protect against 67 replay attacks . . . . . . . . . . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 8.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Requirements notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in BCP 81 14 [RFC2119] [RFC8174] when, and only when, they appear in all 82 capitals, as shown here. 84 2. Introduction 86 In BGPsec, a key rollover (or re-key) is the process of changing a 87 router's BGPsec key pair (or key pairs), issuing the corresponding 88 new BGPsec router certificate and (if the old certificate is still 89 valid) revoking the old certificate. This process will need to 90 happen at regular intervals, normally due to policies of the local 91 network. This document describes a safe rollover process that 92 results in a BGPsec receiver always having the needed verification 93 keys. Certificate Practice Statements (CPS) documents may reference 94 this memo. This memo only addresses changing of a router's BGPsec 95 key pair within the RPKI. Refer to [RFC6489] for a procedure to 96 rollover RPKI Certification Authority key pairs. 98 When a router receives or creates a new key pair (using a key 99 provisioning mechanism), this key pair will be used to sign new 100 BGPsec updates [RFC8205] that are originated or that transit through 101 the BGP speaker. Additionally, the BGP speaker will refresh its 102 outbound BGPsec Update messages to include a signature using the new 103 key (replacing the old key). When the rollover process finishes, the 104 old BGPsec router certificate (and its key) will no longer be valid, 105 and thus any BGPsec Update that includes a signature performed by the 106 old key will be invalid. Consequently, if the router does not 107 refresh its outbound BGPsec Update messages, previously sent routing 108 information may be treated as unauthenticated after the rollover 109 process is finished. It is therefore extremely important that new 110 BGPsec router certificates have been distributed throughout the RPKI 111 before the router begin signing BGPsec updates with a new private 112 key. 114 It is also important for an AS to minimize the BGPsec router key 115 rollover interval (i.e., the period between the time when an AS 116 distributes a BGPsec router certificate with a new public key and the 117 time a BGPsec router begins to use its new private key). This can be 118 due to a need for a BGPsec router to distribute BGPsec updates signed 119 with a new private key in order to invalidate BGPsec updates signed 120 with the old private key. In particular, if the AS suspects that a 121 stale BGPsec update is being distributed instead of the most recently 122 signed attribute it can cause the stale BGPsec updates to be 123 invalidated by completing a key rollover procedure. The BGPsec 124 router rollover interval can be minimized when an automated 125 certificate provisioning process such as Enrollment over Secure 126 Transport (EST) [RFC7030] is used. 128 The Security Requirements for BGP Path Validation [RFC7353] also 129 describes the need for protecting against suppression of BGP WITHDRAW 130 messages or replay of BGP UPDATE messages, such as controlling 131 BGPsec's window of exposure to such attacks. The BGPsec router 132 certificate rollover method in this document can be used to achieve 133 this goal. 135 In [I-D.ietf-sidr-rtr-keying], the "operator-driven" method is 136 introduced, in which a key pair can be shared among multiple BGP 137 speakers. In this scenario, the rollover of the correspondent BGPsec 138 router certificate will impact all the BGP speakers sharing the same 139 private key. 141 3. Key rollover in BGPsec 143 A BGPsec router certificate SHOULD be replaced when the following 144 events occur, and can be replaced for any other reason at the 145 discretion of the AS responsible for the BGPsec router certificate. 147 Scheduled rollover: BGPsec router certificates have an expiration 148 date (NotValidAfter) that requires a frequent rollover process 149 to refresh certificates or issue new certificates. The 150 validity period for these certificates is typically expressed 151 in the CA's CPS document. 153 Router certificate field changes: Information contained in a BGPsec 154 router certificate (such as the ASN or the Subject) may need to 155 be changed. 157 Emergency router key rollover: Some special circumstances (such as a 158 compromised key) may require the replacement of a BGPsec router 159 certificate. 161 Protection against withdrawal suppression and replay attacks: An AS 162 may determine that withdrawn BGPsec updates are being 163 propagated instead of the most recently propagated BGPsec 164 updates. Changing the BGPsec router signing key, distributing 165 a new BGPsec router certificate, and revoking the old BGPsec 166 router certificate will invalidate the replayed BGPsec updates. 168 In some of these cases it is possible to generate a new certificate 169 without changing the key pair. This practice simplifies the rollover 170 process as the BGP speakers receiving BGPsec Updates do not even need 171 to be aware of the change of certificate. However, not replacing the 172 certificate key for a long period of time increases the risk that a 173 compromised router private key may be used by an attacker to deliver 174 unauthorized or false BGPsec Updates. Distributing the old public 175 key in a new certificate is NOT RECOMMENDED when the rollover event 176 is due to a compromised key, or when it is suspected that withdrawn 177 BGPsec updates are being distributed. 179 3.1. Rollover Process 181 The key rollover process is dependent on the key provisioning 182 mechanisms adopted by an AS [I-D.ietf-sidr-rtr-keying]. An automatic 183 provisioning mechanism such as EST will allow router key management 184 procedures to include automatic re-keying methods with minimum 185 development cost. 187 A safe BGPsec router key rollover process is as follows. 189 1. New Certificate Publication: The first step in the rollover 190 mechanism is to publish the new certificate. If required, a new 191 key pair will be generated for the BGPsec router. A new 192 certificate will be generated and the certificate published at 193 the appropriate RPKI repository publication point. The details 194 of this process will vary as they depend on whether the keys are 195 assigned per-BGPsec speaker or shared among multiple BGPsec 196 speakers, whether the keys are generated on each BGPsec speaker 197 or in a central location, and whether the RPKI repository is 198 locally or externally hosted. 200 2. Staging Period: A staging period will be required from the time a 201 new certificate is published in the RPKI global repository until 202 the time it is fetched by RPKI caches around the globe. The 203 exact minimum staging time will be dictated by the conventional 204 interval chosen between repository fetches. If rollovers will be 205 done more frequently, an administrator can provision two 206 certificates for every router concurrently with different valid 207 start times. In this case when the rollover operation is needed, 208 the relying parties around the globe would already have the new 209 router public keys. However, if an administrator has not 210 previously provisioned the next certificate then a staging period 211 may not be possible to implement during emergency key rollover. 212 If there is no staging period, routing may be disrupted due to 213 the inability of a BGPsec router to validate BGPsec updates 214 signed with a new private key. 216 3. Twilight: At this moment, the BGPsec speaker holding the rolled- 217 over private key will stop using the old key for signing and 218 start using the new key. Also, the router will generate 219 appropriate refreshed BGPsec updates just as in the typical 220 operation of refreshing out-bound BGP polices. This operation 221 may generate a great number of BGPsec updates. A BGPsec speaker 222 may vary the Twilight moment for every peer in order to 223 distribute the system load (e.g., skewing the rollover for 224 different peers by a few minutes each would be sufficient and 225 effective). 227 4. Certificate Revocation: This is an optional step, but SHOULD be 228 taken when the goal is to invalidate BGPsec updates signed with 229 the old key. Reasons to invalidate old BGPsec updates include: 230 (a) the AS has reason to believe that the router signing key has 231 been compromised, and (b) the AS needs to invalidate already 232 propagated BGPsec updates signed with the old key. As part of 233 the rollover process, a CA MAY decide to revoke the old 234 certificate by publishing its serial number on the CA's CRL. 235 Alternatively, the CA will just let the old certificate expire 236 and not revoke it. This choice will depend on the reasons that 237 motivated the rollover process. 239 5. RPKI-Router Protocol Withdrawals: At the expiration of the old 240 certificate's validation, the RPKI relying parties around the 241 globe will need to communicate to their router peers that the old 242 certificate's public key is no longer valid (e.g., using the 243 RPKI-Router Protocol described in [RFC8210]). A router's 244 reaction to a message indicating withdrawal of a router key in 245 the RPKI-Router Protocol SHOULD include the removal of any RIB 246 entries (i.e., BGPsec updates) signed with that key and the 247 generation of the corresponding BGP WITHDRAWALs (either implicit 248 or explicit). 250 This rollover mechanism depends on the existence of an automatic 251 provisioning process for BGPsec router certificates. It requires a 252 staging mechanism based on the RPKI propagation time (typically a 24 253 hour period at the time this document was published), and an AS is 254 REQUIRED to re-sign all originated and transited BGPsec updates that 255 were previously signed with the old key. 257 The first two steps (New Certificate Publication and Staging Period) 258 may happen in advance of the rest of the process. This will allow a 259 network operator to perform its subsequent key rollover in an 260 efficient and timely manner. 262 When a new BGPsec router certificate is generated without changing 263 its key, steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals) 264 SHOULD NOT be executed. 266 4. BGPsec router key rollover as a measure against replay attacks 268 There are two typical generic measures to mitigate replay attacks in 269 any protocol: the addition of a timestamp or the addition of a serial 270 number. However, neither BGP nor BGPsec provide either measure. The 271 timestamp approach was originally proposed for BGPsec 272 [I-D.sriram-replay-protection-design-discussion] but later dropped in 273 favor of the key rollover approach. This section discusses the use 274 of using a key rollover as a measure to mitigate replay attacks. 276 4.1. BGP UPDATE window of exposure requirement 278 The need to limit the vulnerability to replay attacks is described in 279 [RFC7353] Section 4.3. One important comment is that during a window 280 of exposure, a replay attack is effective only in very specific 281 circumstances: there is a downstream topology change that makes the 282 signed AS path no longer current, and the topology change makes the 283 replayed route preferable to the route associated with the new 284 update. In particular, if there is no topology change at all, then 285 no security threat comes from a replay of a BGPsec update because the 286 signed information is still valid. 288 The BGPsec Operational Considerations document [RFC8207] gives some 289 idea of requirements for the size of the window of exposure to replay 290 attacks. It states that the requirement will be in the order of a 291 day or longer. 293 4.2. BGPsec key rollover as a mechanism to protect against replay 294 attacks 296 Since the window requirement is on the order of a day (as documented 297 in [RFC8207]) and the BGP speaker performing re-keying is the edge 298 router of the origin AS, it is feasible to use key rollover to 299 mitigate replays. In this case it is important to complete the full 300 process (i.e., the old and new certificates do not share the same 301 key). By re-keying, an AS is letting the BGPsec router certificate 302 validation time be a type of "timestamp" to mitigate replay attacks. 303 However, the use of frequent key rollovers comes with an additional 304 administrative cost and risks if the process fails. As documented 305 before, re-keying should be supported by automatic tools, and for the 306 great majority of the Internet it will be done with good lead time to 307 ensure that the public key corresponding to the new router 308 certificate will be available to validate the corresponding BGPsec 309 updates when received. 311 If a transit AS also originates BGPsec updates for its own prefixes 312 and it wishes to mitigate replay attacks on those prefixes, then the 313 transit AS SHOULD be provisioned with two unique key pairs and 314 certificates. One of the key pairs is used to sign BGPsec updates 315 for prefixes originated from the transit AS, and can have a replay 316 protection policy applied to it. The other key pair is used to sign 317 BGPsec updates in transit and SHOULD NOT have replay protection 318 policy applied to it. Because the transit AS is not likely to know 319 or care what is the policy of origin ASes elsewhere, there is no 320 value for the transit AS to perform key rollovers to mitigate replay 321 attacks against prefixes originated elsewhere. If the transit AS 322 were instead to perform replay protection for all updates that it 323 signs, its key rollover process would generate a large number of 324 BGPsec UPDATE messages, even in the complete Default Free Zone (DFZ). 325 Therefore, it is best to let each AS independently manage the replay 326 attack vulnerability window for the prefixes it originates. 328 Advantages to re-keying as replay attack protection mechanism are as 329 follows: 331 1. All expiration policies are maintained in the RPKI. 333 2. Much of the additional administrative cost is paid by the 334 provider that wants to protect its infrastructure, as it bears 335 the cost of creating and initiating distribution of new router 336 key pairs and BGPsec router certificates. (It is true that the 337 cost of relying parties will be affected by the new objects, but 338 their responses should be completely automated or otherwise 339 routine.) 341 3. The re-keying can be implemented in coordination with planned 342 topology changes by either origin ASes or transit ASes (e.g., if 343 an AS changes providers, it completes a key rollover). 345 Disadvantages to Re-keying as replay attack protection mechanism are 346 as follows: 348 1. Frequent rollovers add administrative and BGP processing loads, 349 although the required frequency is not clear. Some initial ideas 350 are found in [RFC8207]. 352 2. The minimum replay vulnerability is bounded by the propagation 353 time for RPKI caches to obtain the new certificate and CRL (2x 354 propagation time because first the new certificate and then the 355 CRL need to propagate through the RPKI system). If provisioning 356 is done ahead of time, the minimum replay vulnerability window 357 size is reduced to 1x propagation time (i.e., propagation of the 358 CRL). However, these bounds will be better understood when RPKI 359 and RPs are well deployed, as well as the propagation time for 360 objects in the RPKI is better understood. 362 3. Re-keying increases the dynamics and size of the RPKI repository. 364 5. IANA Considerations 366 There are no IANA considerations. This section may be removed upon 367 publication. 369 6. Security Considerations 371 This document does not contain a protocol update to either the RPKI 372 or BGPsec. It describes a process for managing BGPsec router 373 certificates within the RPKI. 375 Routers participating in BGPsec will need to rollover their signing 376 keys as part of conventional certificate management processes. 377 However, because rolling over signing keys will also have an effect 378 of invalidating BGPsec updates signatures, the rollover process must 379 be carefully orchestrated to ensure that valid BGPsec updates are not 380 treated as invalid. This situation could affect Internet routing. 381 This document describes a safe method for rolling over BGPsec router 382 certificates. It takes into account both normal and emergency key 383 rollover requirements. 385 Additionally, the key rollover method described in this document can 386 be used as a measure to mitigate BGP update replay attacks, in which 387 an entity in the routing system is suppressing current BGPsec updates 388 and replaying withdrawn updates. When the key used to sign the 389 withdrawn updates has been rolled over, the withdrawn updates will be 390 considered invalid. When certificates containing a new public key 391 are provisioned ahead of time, the minimum replay vulnerability 392 window size is reduced to the propagation time of a CRL invalidating 393 the certificate containing an old public key. For a discussion of 394 the difficulties deploying a more effectual replay protection 395 mechanism for BGPSEC, see 396 [I-D.sriram-replay-protection-design-discussion]. 398 7. Acknowledgments 400 Randy Bush, Kotikalapudi Sriram, Stephen Kent and Sandy Murphy each 401 provided valuable suggestions resulting in an improved document. 402 Kotikalapudi Sriram contributed valuable guidance regarding the use 403 of key rollovers to mitigate BGP update replay attacks. 405 8. References 407 8.1. Normative References 409 [I-D.ietf-sidr-rtr-keying] 410 Bush, R., Turner, S., and K. Patel, "Router Keying for 411 BGPsec", draft-ietf-sidr-rtr-keying-14 (work in progress), 412 October 2017. 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, 416 DOI 10.17487/RFC2119, March 1997, . 419 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 420 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 421 May 2017, . 423 8.2. Informative References 425 [I-D.sriram-replay-protection-design-discussion] 426 Sriram, K. and D. Montgomery, "Design Discussion and 427 Comparison of Protection Mechanisms for Replay Attack and 428 Withdrawal Suppression in BGPsec", draft-sriram-replay- 429 protection-design-discussion-09 (work in progress), 430 October 2017. 432 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 433 Authority (CA) Key Rollover in the Resource Public Key 434 Infrastructure (RPKI)", BCP 174, RFC 6489, 435 DOI 10.17487/RFC6489, February 2012, . 438 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 439 "Enrollment over Secure Transport", RFC 7030, 440 DOI 10.17487/RFC7030, October 2013, . 443 [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security 444 Requirements for BGP Path Validation", RFC 7353, 445 DOI 10.17487/RFC7353, August 2014, . 448 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 449 Specification", RFC 8205, DOI 10.17487/RFC8205, September 450 2017, . 452 [RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, 453 RFC 8207, DOI 10.17487/RFC8207, September 2017, 454 . 456 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 457 Infrastructure (RPKI) to Router Protocol, Version 1", 458 RFC 8210, DOI 10.17487/RFC8210, September 2017, 459 . 461 Authors' Addresses 463 Brian Weis 464 Cisco Systems 465 170 W. Tasman Drive 466 San Jose, CA 95134 467 US 469 Email: bew@cisco.com 471 Roque Gagliano 472 Cisco Systems 473 Avenue des Uttins 5 474 Rolle, VD 1180 475 Switzerland 477 Email: rogaglia@cisco.com 478 Keyur Patel 479 Arrcus, Inc. 481 Email: keyur@arrcus.com