idnits 2.17.1 draft-ietf-sidr-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 (March 6, 2015) is 3331 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-bgpsec-ops-05 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-11 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rtr-keying-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gagliano 3 Internet-Draft K. Patel 4 Intended status: Standards Track B. Weis 5 Expires: September 7, 2015 Cisco Systems 6 March 6, 2015 8 BGPSEC Router Certificate Rollover 9 draft-ietf-sidr-bgpsec-rollover-03 11 Abstract 13 BGPSEC will need to address the impact from regular and emergency 14 rollover processes for the BGPSEC End-Entity (EE) certificates that 15 will be performed by Certificate Authorities (CAs) participating at 16 the Resource Public Key Infrastructure (RPKI). Rollovers of BGPSEC 17 EE certificates must be carefully managed in order to synchronize 18 distribution of router public keys and the usage of those pubic keys 19 by BGPSEC routers. This document provides general recommendations 20 for that process, as well as describing reasons why the rollover of 21 BGPSEC EE certificates might be necssary. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 7, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Key rollover in BGPSEC . . . . . . . . . . . . . . . . . . . . 6 60 3.1. A proposed process for BGPSEC key rollover . . . . . . . . 6 61 4. BGPSEC key rollover as a measure against replays attacks 62 in BGPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. BGPSEC Replay attack window requirement . . . . . . . . . 9 64 4.2. BGPSEC key rollover as a mechanism to protect against 65 replay attacks . . . . . . . . . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 In BGPSEC, a key rollover (or re-keying) is the process of changing a 83 router's key pair (or pairs), issuing the corresponding new End- 84 Entity certificate and (if the old certificate is still valid) 85 revoking the old certificate. This process will need to happen at 86 regular intervals, normally due to local policies at each network. 87 This document provides general recommendations for that process. 88 Certificate Practice Statements (CPS) documents MAY reference these 89 recommendations. This process is comceptually similar to the RPKI 90 Key Rollover process defined in [RFC6489]. 92 When a router receives or creates a new key pair (depending on the 93 key provisioning mechanism to be selected), this key pair will be 94 used to sign new BGPsec_Path attributes 95 [I-D.ietf-sidr-bgpsec-protocol] that are originated or that transit 96 through the BGP speaker. Additionally, the BGP speaker MUST refresh 97 its outbound BGPsec Update messages to include a signature using the 98 new key (replacing the replaced key). When the rollover process 99 finishes, the old BGPSEC certificate (and its key) will not longer be 100 valid and thus any BGPsec Update that includes a BGPsec_Path 101 attribute with a signature performed by the old key will be invalid. 102 Consequently, if the router does not refresh its outbound BGPsec 103 Update messages, routing information may be lost after the rollover 104 process is finished. It is therefore extremely important that the 105 BGPSEC router key rollover be performed such that the probability of 106 new router EE certificates have been distributed throughout the RPKI 107 before the router begin signing BGPsec_Path attributes with a new 108 private key. 110 It is also important for an AS to minimize the BGPSEC router key 111 rollover interval (i.e., in between the time an AS distributes an EE 112 certificate with a new public key and the time a BGPSEC router begins 113 to use its new private key). This can be due to a need for a BGPSEC 114 router to distribute BGPsec_Path attributes signed with a new private 115 key in order to invalidate BGPsec_Path attributes signed with the old 116 private key. In particular, if the AS suspects that a stale 117 BGPsec_Path attribute is being distributed instead of the most 118 recently signed attribute it can cause the stale BGPsec_Path 119 attribute to be invalidated by completing a key rollover procedure. 120 The BGPSEC rollover interval can be minimized when an automated 121 certificate provisioning process such as Enrollment over Secure 122 Transport (EST) [RFC7030]) is used. 124 The Security Requirements for BGP Path Validation [RFC7353] also 125 describes the need for protection against a replay attack, 126 necessitating controlling BGPSEC's window of exposure to replay 127 attacks. The BGPsec rollver method in this document can be used to 128 achieve this goal. 130 In [I-D.ietf-sidr-rtr-keying], the "operator-driven" method is 131 introduced and it enables that a key pair could be shared among 132 different BGP Speakers. In this scenario, the roll-over of the 133 correspondent BGPSEC certificate will impact all the BGP Speakers 134 sharing the same private key. 136 3. Key rollover in BGPSEC 138 A BGPSEC EE certificate (as any X.509 certificate) will required a 139 rollover process due to causes such as: 141 BGPSEC scheduled rollover: BGPSEC certificates have an expiration 142 date (NotValidAfter) that requires a frequent rollover process. 143 The validity period for these certificates is typically 144 expressed at the CA's CPS document. 146 BGPSEC certificate fields changes: Information contained in a BGPSEC 147 certificate (such as the ASN or the Subject) may need to be 148 changed. 150 BGPSEC emergency rollover Some special circumstances (such as a 151 compromised key) may require the replacement of a BGPSEC 152 certificate. 154 BGPSEC signature anti-replay protection An AS may determine stale 155 BGPsec_Path attributes continue to be propogated 157 In most of these cases (probably excepting when the key has been 158 compromised), it is possible to generate a new certificate without 159 changing the key pair. This practice simplifies the rollover process 160 as the correspondent BGP speakers do not even need to be aware of the 161 changes to its correspondent certificate. However, not replacing the 162 certificate key for a long period of time increases the risk that the 163 certificate key may be compromised. 165 3.1. A proposed process for BGPSEC key rollover 167 The BGPSEC key rollover process will be dependent on the key 168 provisioning mechanisms that would be in place. The key provisioning 169 mechanisms for BGPSEC are not yet fully documented (see 170 [I-D.ietf-sidr-rtr-keying] as a work in progress document). We will 171 assume that an automatic provisioning mechanism suchas EST will be in 172 place. The use of EST will allow BGPSEC code to include automatic 173 re-keying scripts with minimum development cost. 175 If we work under the assumption that an automatic mechanism will 176 exist to rollover a BGPSEC certificate, a possible process could be 177 as follows. 179 1. New Certificate Pre-Publication: The first step in the rollover 180 mechanism is to pre-publish the new public key in a new 181 certificate. In order to accomplish this goal, the new key pair 182 and certificate will need to be generated and published at the 183 appropriate RPKI repository publication point. The details of 184 this process will vary as they depend on whether the keys are 185 assigned per-BGP speaker or shared, whether the keys are 186 generated on each BGP speaker or in a central location and wether 187 the RPKI repository is locally or externally hosted. 189 2. Staging Period: A staging period will be required from the time a 190 new certificate is published in the RPKI global repository until 191 the time it is fetched by RPKI caches around the globe. The 192 exact minimum staging time is not clear and will require 193 experimental results from RPKI operations. RPKI repository 194 design documents mention a lower limit of 24 hours (NOTE: need 195 reference only one I found is the ops document). If rollovers 196 will be done frequently and we want to avoid the stage period, an 197 administrator can always provision two certificate for every 198 router. In this case when the rollover operation is needed, the 199 relying parties around the globe would already have the new keys. 200 A staging period may not be possible to implement during 201 emergency key rollover, in which case routing information may be 202 lost. 204 3. Twilight: At this moment, the BGP speaker that hold the private 205 key that has been rolled-over will stop using the OLD key for 206 signing and start using the NEW key. Also, the router will 207 generate appropriate BGPsec_Path attributes just as in the 208 typical operation of refreshing out-bound BGP polices. This 209 operation may generate a great number of BGPsec_Path attributes 210 (due to the need to refresh BGP outbound policies). In any given 211 BGP SPEAKER, the Twilight moment may be different for every peer 212 in order to distribute the system load (probably in the order of 213 minutes to avoid reaching any expiration time). 215 4. Certificate Revocation: This is an optional step. As part of the 216 rollover process, a CA MAY decide to revoke the OLD certificate 217 by publishing its serial number on the CA's CRL. On the other 218 side, the CA will just let the OLD certificate to expire and not 219 revoke it. This chose will depend on the reasons that motivated 220 the rollover process. 222 5. RPKI-Router Protocol Withdrawals: Either due to the revocation of 223 the OLD certificate or to the expiration of the OLD certificate's 224 validation, the RPKI relying parties around the globe will need 225 to communicate to their RTR peers that the OLD certificate's 226 public key is not longer valid (rtr withdrawal message). It is 227 not documented yet what will be a router's reaction to a RTR 228 withdrawal message but it should include the removal of any RIB 229 entry that includes a BGPSEC attribute signed with that key and 230 the generation of the correspondent BGP WITHDRAWALs (either 231 implicit or explicit). 233 The proposed rollover mechanism will depend on the existence of an 234 automatic provisioning process for BGPSEC certificates. It will 235 require a staging mechanism based on the RPKI propagation time of 236 around 24hours, and it will generate BGPsec_Path attributes for all 237 prefixes in the router been re-keyed. 239 The first two steps (New Certificate Pre-Publication and Staging 240 Period) could happen ahead of time from the rest of the process as 241 each network operators could prepare itself to accelerate a future 242 key roll-over. 244 When a new BGPSEC certificate is generated without changing its key, 245 steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals) SHOULD 246 NOT be executed. 248 4. BGPSEC key rollover as a measure against replays attacks in BGPSEC 250 There are two typical generic measures to mitigate replay attacks in 251 any protocol: the addition of a timestamp or the addition of a serial 252 number. However neither BGP nor BGPSEC provide either measure. This 253 section discusses the use of BGPSEC Rollover as a measure to mitigate 254 replay attacks. 256 4.1. BGPSEC Replay attack window requirement 258 In [RFC7353] Section 4.3, the need to limit the vulnerability to 259 replay attacks is described. One important comment is that during a 260 windows of exposure, a replay attack is effective only if there was a 261 downstream topology change that makes the signed AS path not longer 262 current. In other words, if there have been no topology changes, 263 then no security threat comes from a replay of a BGPsec_Path 264 attribute (the signed information is still valid). 266 The BGPSEC Ops document [I-D.ietf-sidr-bgpsec-ops] gives some ideas 267 of requirements for the size of the BGPSEC windows of exposure to 268 replay attacks. At that document, it is stated that for the vast 269 majority of the prefixes, the requirement will be in the order of 270 days or weeks. For a very small but critical fraction of the 271 prefixes, the requirement may be in the order of hours. 273 4.2. BGPSEC key rollover as a mechanism to protect against replay 274 attacks 276 Since the window requirement is in the order of days (as documented 277 in [I-D.ietf-sidr-bgpsec-ops]) and the BGP speaker re-keying is the 278 edge router of the origin AS, it is feasible for a BGPSEC Rollover to 279 mitigate mitigate. In this case it is important to complete the full 280 process (i.e. the OLD and NEW certificate do not share the same key). 281 By re-keying an AS is letting the BGPSEC certificate validation time 282 be a sort of "timestamp" against replay attacks. However, the use of 283 frequent key rollovers comes with an additional administrative cost 284 and risks if the process fails. As documented before, re-keying 285 should be supported by automatic tools and for the great majority of 286 the Internet it will be done with good lead time to correct any risk. 288 For a transit AS that also originates BGPsec_Path attributes for its 289 own prefixes, the key rollover process may generate a large number of 290 UPDATE messages (even the complete Default Free Zone or DFZ). For 291 this reason, it is recommended that routers in this scenario been 292 provisioned with two certificates: one to sign BGPsec_Path attributes 293 in transit and a second one to sign an BGPsec_Path attribute for 294 prefixes originated in its AS. Only the second certificate (for 295 prefixes originated in its AS) should be rolled-over frequently as a 296 means of limiting replay attach windows. The transit BGPSEC 297 certificate is expected to be longer living than the origin BGPSEC 298 certificate. 300 Advantage of Re-keying as replay attack protection mechanism: 302 1. All expiration policies are maintained in RPKI 304 2. Most of the additional administrative cost is paid by the 305 provider that wants to protect its infrastructure (RP load will 306 increase as there is a need to validate more BGPSEC certificates) 308 3. Can be implemented in coordination with planned topology changes 309 by either origin ASes or transit ASes (e.g., if an AS changes 310 providers, it completes a BGP Rollover) 312 Disadvantage of Re-keying as replay attack protection mechanism: 314 1. More administrative load due to frequent rollover, although how 315 frequent is still not clear. Some initial ideas in 316 [I-D.ietf-sidr-bgpsec-ops] 318 2. Minimum window size bounded by RPKI propagation time to RPKI 319 caches for new certificate and CRL (2x propagation time). If 320 pre-provisioning done ahead of time the minimum windows size is 321 reduced (to 1x propagation time for the CRL). However, more 322 experimentation is needed when RPKI and RPs are more massively 323 deployed. 325 3. Increases dynamics and size of RPKI repository. 327 4. More load on RPKI caches, but they are meant to do this work. 329 5. IANA Considerations 331 No IANA considerations 333 6. Security Considerations 335 Several possible reasons can cause routers participating in BGPSEC to 336 replace rollover their signing keys and/or signatures containing 337 their current signature verification key. Some reasons are due to 338 the usual key management operations reasons (e.g.,key exposure, 339 change of certificate attributes, due to policy). However BGPSEC 340 routers also may need to change their signing keys and associated 341 certificate as an anti-replay protection. 343 The BGPSEC Rollover method allows for an expedient rollover process 344 when router certificates are distributed through the RPKI, but 345 without causing routing failures due to a receiving router not being 346 able to validate a BGPsec_Path attribute created by a router that is 347 the subject of the rollover. 349 7. Acknowledgements 351 We would like to acknowledge Randy Bush, Sriram Kotikalapudi, Stephen 352 Kent and Sandy Murphy. 354 8. References 356 8.1. Normative References 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 362 Authority (CA) Key Rollover in the Resource Public Key 363 Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012. 365 8.2. Informative References 367 [I-D.ietf-sidr-bgpsec-ops] 368 Bush, R., "BGPsec Operational Considerations", 369 draft-ietf-sidr-bgpsec-ops-05 (work in progress), 370 May 2012. 372 [I-D.ietf-sidr-bgpsec-protocol] 373 Lepinski, M., "BGPsec Protocol Specification", 374 draft-ietf-sidr-bgpsec-protocol-11 (work in progress), 375 January 2015. 377 [I-D.ietf-sidr-rtr-keying] 378 Patel, K. and R. Bush, "Router Keying for BGPsec", 379 draft-ietf-sidr-rtr-keying-08 (work in progress), 380 January 2015. 382 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 383 Secure Transport", RFC 7030, October 2013. 385 [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security 386 Requirements for BGP Path Validation", RFC 7353, 387 August 2014. 389 Authors' Addresses 391 Roque Gagliano 392 Cisco Systems 393 Avenue des Uttins 5 394 Rolle, VD 1180 395 Switzerland 397 Email: rogaglia@cisco.com 399 Keyur Patel 400 Cisco Systems 401 170 W. Tasman Driv 402 San Jose, CA 95134 403 CA 405 Email: keyupate@cisco.com 407 Brian Weis 408 Cisco Systems 409 170 W. Tasman Driv 410 San Jose, CA 95134 411 CA 413 Email: bew@cisco.com