idnits 2.17.1 draft-ietf-sidrops-bgpsec-rollover-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 (October 27, 2017) is 2373 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) == 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: Standards Track Cisco Systems 5 Expires: April 30, 2018 K. Patel 6 Arrcus, Inc. 7 October 27, 2017 9 BGPsec Router Certificate Rollover 10 draft-ietf-sidrops-bgpsec-rollover-03 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 April 30, 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 81 [RFC2119]. 83 2. Introduction 85 In BGPsec, a key rollover (or re-key) is the process of changing a 86 router's BGPsec key pair (or key pairs), issuing the corresponding 87 new BGPsec router certificate and (if the old certificate is still 88 valid) revoking the old certificate. This process will need to 89 happen at regular intervals, normally due to policies of the local 90 network. This document describes a safe rollover process that 91 results in a BGPsec receiver always having the needed verification 92 keys. Certificate Practice Statements (CPS) documents may reference 93 this memo. This memo only addresses changing of a router's BGPsec 94 key pair within the RPKI. Refer to [RFC6489] for a procedure to 95 rollover RPKI Certification Authority key pairs. 97 When a router receives or creates a new key pair (using a key 98 provisioning mechanism), this key pair will be used to sign new 99 BGPsec updates [RFC8205] that are originated or that transit through 100 the BGP speaker. Additionally, the BGP speaker will refresh its 101 outbound BGPsec Update messages to include a signature using the new 102 key (replacing the old key). When the rollover process finishes, the 103 old BGPsec router certificate (and its key) will no longer be valid, 104 and thus any BGPsec Update that includes a signature performed by the 105 old key will be invalid. Consequently, if the router does not 106 refresh its outbound BGPsec Update messages, previously sent routing 107 information may be treated as unauthenticated after the rollover 108 process is finished. It is therefore extremely important that new 109 BGPsec router certificates have been distributed throughout the RPKI 110 before the router begin signing BGPsec updates with a new private 111 key. 113 It is also important for an AS to minimize the BGPsec router key 114 rollover interval (i.e., in between the time an AS distributes a 115 BGPsec router certificate with a new public key and the time a BGPsec 116 router begins to use its new private key). This can be due to a need 117 for a BGPsec router to distribute BGPsec updates signed with a new 118 private key in order to invalidate BGPsec updates signed with the old 119 private key. In particular, if the AS suspects that a stale BGPsec 120 updates is being distributed instead of the most recently signed 121 attribute it can cause the stale BGPsec updates to be invalidated by 122 completing a key rollover procedure. The BGPsec router rollover 123 interval can be minimized when an automated certificate provisioning 124 process such as Enrollment over Secure Transport (EST) [RFC7030] is 125 used. 127 The Security Requirements for BGP Path Validation [RFC7353] also 128 describes the need for protecting against suppression of BGP WITHDRAW 129 messages or replay of BGP UPDATE messages, such as controlling 130 BGPsec's window of exposure to such attacks. The BGPsec router 131 certificate rollover method in this document can be used to achieve 132 this goal. 134 In [I-D.ietf-sidr-rtr-keying], the "operator-driven" method is 135 introduced, in which a key pair can be shared among multiple BGP 136 speakers. In this scenario, the rollover of the correspondent BGPsec 137 router certificate will impact all the BGP speakers sharing the same 138 private key. 140 3. Key rollover in BGPsec 142 A BGPsec router certificate SHOULD be replaced when the following 143 events occur, and can be replaced for any other reason at the 144 discretion of the AS responsible for the BGPsec router certificate. 146 Scheduled rollover: BGPsec router certificates have an expiration 147 date (NotValidAfter) that requires a frequent rollover process 148 to refresh certificates or issue new certificates. The 149 validity period for these certificates is typically expressed 150 in the CA's CPS document. 152 Router certificate field changes: Information contained in a BGPsec 153 router certificate (such as the ASN or the Subject) may need to 154 be changed. 156 Emergency router key rollover: Some special circumstances (such as a 157 compromised key) may require the replacement of a BGPsec router 158 certificate. 160 Protection against withdrawal suppression and replay attacks: An AS 161 may determine withdrawn BGPsec updates are being propagated 162 instead of the most recently propagated BGPsec updates. 163 Changing the BGPsec router signing key, distributing a new 164 BGPsec router certificate, and revoking the old BGPsec router 165 certificate will invalidate the replayed BGPsec updates. 167 In some of these cases it is possible to generate a new certificate 168 without changing the key pair. This practice simplifies the rollover 169 process as the BGP speakers receiving BGPsec Updates do not even need 170 to be aware of the change of certificate. However, not replacing the 171 certificate key for a long period of time increases the risk that a 172 compromised router private key may be used by an attacker to deliver 173 unauthorized or false BGPsec Updates. Distributing the old public 174 key in a new certificate is NOT RECOMMENDED when the rollover event 175 is due to a compromised key, or when it is suspected that withdrawn 176 BGPsec updates are being distributed. 178 3.1. Rollover Process 180 The key rollover process is dependent on the key provisioning 181 mechanisms adopted by an AS [I-D.ietf-sidr-rtr-keying]. An automatic 182 provisioning mechanism such as EST will allow router key management 183 procedures to include automatic re-keying methods with minimum 184 development cost. 186 A safe BGPsec router key rollover process is as follows. 188 1. New Certificate Publication: The first step in the rollover 189 mechanism is to publish the new certificate. If required, a new 190 key pair will be generated for the BGPsec router. A new 191 certificate will be generated and the certificate published at 192 the appropriate RPKI repository publication point. The details 193 of this process will vary as they depend on whether the keys are 194 assigned per-BGPsec speaker or shared among multiple BGPsec 195 speakers, whether the keys are generated on each BGPsec speaker 196 or in a central location, and whether the RPKI repository is 197 locally or externally hosted. 199 2. Staging Period: A staging period will be required from the time a 200 new certificate is published in the RPKI global repository until 201 the time it is fetched by RPKI caches around the globe. The 202 exact minimum staging time will be dictated by the conventional 203 interval chosen between repository fetches. If rollovers will be 204 done more frequently, an administrator can provision two 205 certificates for every router concurrently with different valid 206 start times. In this case when the rollover operation is needed, 207 the relying parties around the globe would already have the new 208 router public keys. However, if an administrator has not 209 previously provisioned the next certificate then a staging period 210 may not be possible to implement during emergency key rollover. 211 If there is no staging period, routing may be disrupted due to 212 the inability of a BGPsec router to validate BGPsec updates 213 signed with a new private key. 215 3. Twilight: At this moment, the BGPsec speaker holding the rolled- 216 over private key will stop using the old key for signing and 217 start using the new key. Also, the router will generate 218 appropriate refreshed BGPsec updates just as in the typical 219 operation of refreshing out-bound BGP polices. This operation 220 may generate a great number of BGPsec updates. A BGPsec speaker 221 may vary the Twilight moment for every peer in order to 222 distribute the system load (e.g., skewing the rollover for 223 different peers by a few minutes each would be sufficient and 224 effective). 226 4. Certificate Revocation: This is an optional step, but SHOULD be 227 taken when the goal is to invalidate BGPsec updates signed with 228 the old key. Reasons to invalidate old BGPsec updates include: 229 (a) the AS has reason to believe that the router signing key has 230 been compromised, and (b) the AS needs to invalidate already 231 propagated BGPsec updates signed with the old key. As part of 232 the rollover process, a CA MAY decide to revoke the old 233 certificate by publishing its serial number on the CA's CRL. 234 Alternatively, the CA will just let the old certificate expire 235 and not revoke it. This choice will depend on the reasons that 236 motivated the rollover process. 238 5. RPKI-Router Protocol Withdrawals: At the expiration of the old 239 certificate's validation, the RPKI relying parties around the 240 globe will need to communicate to their router peers that the old 241 certificate's public key is no longer valid (e.g., using the 242 RPKI-Router Protocol described in [RFC8210]). A router's 243 reaction to a message indicating withdrawal of a router key in 244 the RPKI-Router Protocol SHOULD include the removal of any RIB 245 entries (i.e., BGPsec updates) signed with that key and the 246 generation of the corresponding BGP WITHDRAWALs (either implicit 247 or explicit). 249 This rollover mechanism depends on the existence of an automatic 250 provisioning process for BGPsec router certificates. It requires a 251 staging mechanism based on the RPKI propagation time (typically a 24 252 hour period at the time this document was published), and an AS is 253 REQUIRED to re-sign all originated and transited BGPsec updates that 254 were previously signed with the old key. 256 The first two steps (New Certificate Publication and Staging Period) 257 may happen in advance of the rest of the process. This will allow a 258 network operator to perform its subsequent key rollover in an 259 efficient and timely manner. 261 When a new BGPsec router certificate is generated without changing 262 its key, steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals) 263 SHOULD NOT be executed. 265 4. BGPsec router key rollover as a measure against replay attacks 267 There are two typical generic measures to mitigate replay attacks in 268 any protocol: the addition of a timestamp or the addition of a serial 269 number. However, neither BGP nor BGPsec provide either measure. The 270 timestamp approach was originally proposed for BGPsec 271 [I-D.sriram-replay-protection-design-discussion] but later dropped in 272 favor of the key rollover approach. This section discusses the use 273 of using a key rollover as a measure to mitigate replay attacks. 275 4.1. BGP UPDATE window of exposure requirement 277 The need to limit the vulnerability to replay attacks is described in 278 [RFC7353] Section 4.3. One important comment is that during a window 279 of exposure, a replay attack is effective only in very specific 280 circumstances: there is a downstream topology change that makes the 281 signed AS path no longer current, and the topology change makes the 282 replayed route preferable to the route associated with the new 283 update. In particular, if there is no topology change at all, then 284 no security threat comes from a replay of a BGPsec update because the 285 signed information is still valid. 287 The BGPsec Operational Considerations document [RFC8207] gives some 288 idea of requirements for the size of the window of exposure to replay 289 attacks. It states that the requirement will be in the order of a 290 day or longer. 292 4.2. BGPsec key rollover as a mechanism to protect against replay 293 attacks 295 Since the window requirement is on the order of a day (as documented 296 in [RFC8207]) and the BGP speaker performing re-keying is the edge 297 router of the origin AS, it is feasible to use key rollover to 298 mitigate replays. In this case it is important to complete the full 299 process (i.e., the old and new certificates do not share the same 300 key). By re-keying, an AS is letting the BGPsec router certificate 301 validation time be a type of "timestamp" to mitigate replay attacks. 302 However, the use of frequent key rollovers comes with an additional 303 administrative cost and risks if the process fails. As documented 304 before, re-keying should be supported by automatic tools, and for the 305 great majority of the Internet it will be done with good lead time to 306 ensure that the public key corresponding to the new router 307 certificate will be available to validate the corresponding BGPsec 308 updates when received. 310 For a transit AS that also originates BGPsec updates for its own 311 prefixes, the key rollover process may generate a large number of 312 UPDATE messages (even the complete Default Free Zone or DFZ). For 313 this reason, it is RECOMMENDED that routers in a transit AS that also 314 originate BGPsec updates be provisioned with two certificates: one to 315 sign BGPsec updates in transit and a second one to sign BGPsec 316 updates for prefixes originated from its AS. Only the second 317 certificate (for originating prefixes) should be rolled-over 318 frequently as a means of limiting replay attack windows. The router 319 certificate used for signing updates in transit is expected to live 320 longer than the one used for signing origination updates. 322 Advantages to re-keying as replay attack protection mechanism are as 323 follows: 325 1. All expiration policies are maintained in the RPKI. 327 2. Much of the additional administrative cost is paid by the 328 provider that wants to protect its infrastructure, as it bears 329 the cost of creating and initiating distribution of new router 330 key pairs and BGPsec router certificates. (It is true that the 331 cost of relying parties will be affected by the new objects, but 332 their responses should be completely automated or otherwise 333 routine.) 335 3. The re-keying can be implemented in coordination with planned 336 topology changes by either origin ASes or transit ASes (e.g., if 337 an AS changes providers, it completes a key rollover). 339 Disadvantages to Re-keying as replay attack protection mechanism are 340 as follows: 342 1. Frequent rollovers add administrative and BGP processing loads, 343 although the required frequency is not clear. Some initial ideas 344 are found in [RFC8207]. 346 2. The minimum replay vulnerability is bounded by the propagation 347 time for RPKI caches to obtain the new certificate and CRL (2x 348 propagation time because first the new certificate and then the 349 CRL need to propagate through the RPKI system). If provisioning 350 is done ahead of time, the minimum replay vulnerability window 351 size is reduced to 1x propagation time (i.e., propagation of the 352 CRL). However, these bounds will be better understood when RPKI 353 and RPs are well deployed, as well as the propagation time for 354 objects in the RPKI is better understood. 356 3. Re-keying increases the dynamics and size of the RPKI repository. 358 5. IANA Considerations 360 There are no IANA considerations. This section may be removed upon 361 publication. 363 6. Security Considerations 365 This document does not contain a protocol update to either the RPKI 366 or BGPsec. It describes a process for managing BGPsec router 367 certificates within the RPKI. 369 Routers participating in BGPsec will need to rollover their signing 370 keys as part of conventional certificate management processes. 371 However, because rolling over signing keys will also have an effect 372 of invalidating BGPsec updates signatures, the rollover process must 373 be carefully orchestrated to ensure that valid BGPsec updates are not 374 treated as invalid. This situation could affect Internet routing. 375 This document describes a safe method for rolling over BGPsec router 376 certificates. It takes into account both normal and emergency key 377 rollover requirements. 379 Additionally, the key rollover method described in this document can 380 be used as a measure to mitigate BGP update replay attacks, in which 381 an entity in the routing system is suppressing current BGPsec updates 382 and replaying withdrawn updates. When the key used to sign the 383 withdrawn updates has been rolled over, the withdrawn updates will be 384 considered invalid. When certificates containing a new public key 385 are provisioned ahead of time, the minimum replay vulnerability 386 window size is reduced to the propagation time of a CRL invalidating 387 the certificate containing an old public key. For a discussion of 388 the difficulties deploying a more effectual replay protection 389 mechanism for BGPSEC, see 390 [I-D.sriram-replay-protection-design-discussion]. 392 7. Acknowledgments 394 Randy Bush, Kotikalapudi Sriram, Stephen Kent and Sandy Murphy each 395 provided valuable suggestions resulting in an improved document. 397 8. References 399 8.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, . 406 8.2. Informative References 408 [I-D.ietf-sidr-rtr-keying] 409 Bush, R., Turner, S., and K. Patel, "Router Keying for 410 BGPsec", draft-ietf-sidr-rtr-keying-14 (work in progress), 411 October 2017. 413 [I-D.sriram-replay-protection-design-discussion] 414 Sriram, K. and D. Montgomery, "Design Discussion and 415 Comparison of Protection Mechanisms for Replay Attack and 416 Withdrawal Suppression in BGPsec", draft-sriram-replay- 417 protection-design-discussion-09 (work in progress), 418 October 2017. 420 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 421 Authority (CA) Key Rollover in the Resource Public Key 422 Infrastructure (RPKI)", BCP 174, RFC 6489, 423 DOI 10.17487/RFC6489, February 2012, . 426 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 427 "Enrollment over Secure Transport", RFC 7030, 428 DOI 10.17487/RFC7030, October 2013, . 431 [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security 432 Requirements for BGP Path Validation", RFC 7353, 433 DOI 10.17487/RFC7353, August 2014, . 436 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 437 Specification", RFC 8205, DOI 10.17487/RFC8205, September 438 2017, . 440 [RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, 441 RFC 8207, DOI 10.17487/RFC8207, September 2017, 442 . 444 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 445 Infrastructure (RPKI) to Router Protocol, Version 1", 446 RFC 8210, DOI 10.17487/RFC8210, September 2017, 447 . 449 Authors' Addresses 451 Brian Weis 452 Cisco Systems 453 170 W. Tasman Drive 454 San Jose, CA 95134 455 US 457 Email: bew@cisco.com 459 Roque Gagliano 460 Cisco Systems 461 Avenue des Uttins 5 462 Rolle, VD 1180 463 Switzerland 465 Email: rogaglia@cisco.com 467 Keyur Patel 468 Arrcus, Inc. 470 Email: keyur@arrcus.com