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