idnits 2.17.1 draft-ietf-sidr-bgpsec-rollover-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When a new BGPSEC certificate is generated without changing its key, steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals) SHOULD not be executed. -- The document date (April 15, 2013) is 4022 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) == Unused Reference: 'RFC6489' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pkix-cmc-serverkeygeneration' is defined on line 340, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pkix-est-02 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-bgpsec-ops-05 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-bgpsec-reqs-03 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rtr-keying-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R.G.M. Gagliano 3 Internet-Draft K.P. Patel 4 Intended status: Standards Track B.W. Weis 5 Expires: October 17, 2013 Cisco Systems 6 April 15, 2013 8 BGPSEC router key rollover as an alternative to beaconing 9 draft-ietf-sidr-bgpsec-rollover-02 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). This document 17 provides general recommendations for that process and specifies how 18 this process is used to control BGPSEC's window of exposure to replay 19 attacks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 17, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Key rollover in BGPSEC . . . . . . . . . . . . . . . . . . . 3 58 3.1. A proposed process for BGPSEC key rollover . . . . . . . 3 59 4. BGPSEC key rollover as a measure against replays attacks in 60 BGPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. BGPSEC Replay attack window requirement . . . . . . . . . 5 62 4.2. BGPSEC key rollover as a mechanism to protect against 63 replay attacks . . . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Requirements notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 In BGPSEC, a key rollover (or re-keying) is the process of changing a 81 router's key pair (or pairs), issuing the corresponding new End- 82 Entity certificate and (if the old certificate is still valid) 83 revoking the old certificate. This process will need to happen at 84 regular intervals, normally due to local policies at each network. 85 This document provides general recommendations for that process that 86 Certificate Practice Statements (CPS) documents MAY reference. 88 When a router receives (or creates depending of the key provisioning 89 mechanism to be selected) a new key pair, this key pair will be used 90 to sign new BGP UPDATE messages that are originated or that transit 91 through the BGP speaker. Additionally, the BGP speaker MUST refresh 92 its outbound BGP UPDATE messages to update its respective BGPSEC 93 attribute by including the correspondent signature performed with the 94 new key. When the rollover process finishes, the old BGPSEC 95 certificate (and its key) will not longer be valid and thus any BGP 96 UPDATE that includes a BGPSEC attribute with a signature performed by 97 the old key will be invalid. Consequently, if the router do not 98 refresh its outbound BGP UPDATE messages, routing information may be 99 lost after the rollover process is finished. 101 As a key rollover process invalidates BGP UPDATE messages signed with 102 the old key, frequent key rollover processes could be used to control 103 BGPSEC's window of exposure to replay attacks as required by 104 [I-D.ietf-sidr-bgpsec-reqs]. This document explores the operational 105 environment to achieve this goal. 107 In [I-D.ietf-sidr-rtr-keying], the "operator-driven" method is 108 introduced and it enables that a key pair could be shared among 109 different BGP Speakers. In this scenario, the roll-over of the 110 correspondent BGPSEC certificate will impact all the BGP Speakers 111 sharing the same private key. 113 3. Key rollover in BGPSEC 115 A BGPSEC EE certificate (as any X.509 certificate) will required a 116 rollover process due to causes such as: 118 BGPSEC scheduled rollover: BGPSEC certificates have an expiration 119 date (NotValidAfter) that requires a frequent rollover process. 120 The validity period for these certificates is typically 121 expressed at the CA's CPS document. 123 BGPSEC certificate fields changes: Information contained in a BGPSEC 124 certificate (such as the ASN or the Subject) may need to be 125 changed. 127 BGPSEC emergency rollover Some special circumstances (such as a 128 compromised key) may require the replacement of a BGPSEC 129 certificate. 131 In most of these cases (probably excepting when the key has been 132 compromised), it is possible to generate a new certificate without 133 changing the key pair. This practice simplifies the rollover process 134 as the correspondent BGP speakers do not even need to be aware of the 135 changes to its correspondent certificate. However, not replacing the 136 certificate key for a long period of time increases the risk that the 137 certificate key may be compromised. 139 3.1. A proposed process for BGPSEC key rollover 141 The BGPSEC key rollover process should be dependent of the key 142 provisioning mechanisms that would be in place. The key provisioning 143 mechanisms for BGPSEC are not yet fully documented (see 144 [I-D.ietf-sidr-rtr-keying] as a work in progress document). We will 145 assume that an automatic provisioning mechanism will be in place. (A 146 possible provisioning mechanism is the Enrollment over Secure 147 Transport (EST) [I-D.ietf-pkix-est]). That protocol will allow 148 BGPSEC code to include automatic re-keying scripts with minimum 149 development cost. 151 If we work under the assumption that an automatic mechanism will 152 exist to rollover a BGPSEC certificate, a possible process could be: 154 1. New Certificate Pre-Publication: The first step in the rollover 155 mechanism is to pre-publish the new public key in a new 156 certificate. In order to accomplish this goal, the new key pair 157 and certificate will need to be generated and published at the 158 appropriate RPKI repository publication point. The details of 159 this process will vary as they depend on whether the keys are 160 assigned per-BGP speaker or shared, whether the keys are 161 generated on each BGP speaker or in a central location and wether 162 the RPKI repository is locally or externally hosted. 164 2. Staging Period: A staging period will be required from the time a 165 new certificate is published in the RPKI global repository until 166 the time it is fetched by RPKI caches around the globe. The 167 exact minimum staging time is not clear and will require 168 experimental results from RPKI operations. RPKI repository 169 design documents mention a lower limit of 24 hours (NOTE: need 170 reference only one I found is the ops document). If rollovers 171 will be done frequently and we want to avoid the stage period, an 172 administrator can always provision two certificate for every 173 router. In this case when the rollover operation is needed, the 174 relying parties around the globe would already have the new keys. 175 A staging period may not be possible to implement during 176 emergency key rollover, in which case routing information may be 177 lost. 179 3. Twilight: At this moment, the BGP speaker that hold the private 180 key that has been rolled-over will stop using the OLD key for 181 signing and start using the NEW key. Also, the router will 182 generate appropriate BGP UPDATES just as in the typical operation 183 of refreshing out-bound BGP polices. This operation may generate 184 a great number of BGP UPDATE messages (due to the need to refresh 185 BGP outbound policies). In any given BGP SPEAKER, the Twilight 186 moment may be different for every peer in order to distribute the 187 system load (probably in the order of minutes to avoid reaching 188 any expiration time). 190 4. Certificate Revocation: This is an optional step. As part of the 191 rollover process, a CA MAY decide to revoke the OLD certificate 192 by publishing its serial number on the CA's CRL. On the other 193 side, the CA will just let the OLD certificate to expire and not 194 revoke it. This chose will depend on the reasons that motivated 195 the rollover process. 197 5. RPKI-Router Protocol Withdrawals: Either due to the revocation of 198 the OLD certificate or to the expiration of the OLD certificate's 199 validation, the RPKI relying parties around the globe will need 200 to communicate to their RTR peers that the OLD certificate's 201 public key is not longer valid (rtr withdrawal message). It is 202 not documented yet what will be a router's reaction to a RTR 203 withdrawal message but it should include the removal of any RIB 204 entry that includes a BGPSEC attribute signed with that key and 205 the generation of the correspondent BGP WITHDRAWALs (either 206 implicit or explicit). 208 The proposed rollover mechanism will depend on the existence of an 209 automatic provisioning process for BGPSEC certificates. It will 210 require a staging mechanism based on the RPKI propagation time of 211 around 24hours, and it will generate BGP UPDATES for all prefixes in 212 the router been re-keyed. 214 The first two steps (New Certificate Pre-Publication and Staging 215 Period) could happen ahead of time from the rest of the process as 216 each network operators could prepare itself to accelerate a future 217 key roll-over. 219 When a new BGPSEC certificate is generated without changing its key, 220 steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals) SHOULD 221 not be executed. 223 4. BGPSEC key rollover as a measure against replays attacks in BGPSEC 225 There are two typical generic measures to mitigate replay attacks in 226 any protocol: the addition of a timestamp or the addition of a serial 227 number. Currently BGPSEC offers a timestamp (expiration time) as a 228 protection against re-play attacks of BGPSEC attributes. The process 229 requires all BGP Speakers that originate a BGP UPDATE to re-advertise 230 ("beacon") the message before it expires. This requirement changes a 231 long standing BGP operational practice and the community has been 232 searching for alternatives. 234 4.1. BGPSEC Replay attack window requirement 236 In [I-D.ietf-sidr-bgpsec-reqs] Section 4.3, the need to limit the 237 vulnerability to replay attacks is described. One important comment 238 is that during a windows of exposure, a replay attack is effective 239 only if there was a downstream topology change that makes the signed 240 AS path not longer current. In other words, if there have been no 241 topology changes, no security threat comes from a replay of a BGP 242 UPDATE message (the signed information is still valid) 244 The BGPSEC Ops document [I-D.ietf-sidr-bgpsec-ops] gives some ideas 245 of requirements for the size of the BGPSEC windows of exposure to 246 replay attacks. At that document, it is stated that for the vast 247 majority of the prefixes, the requirement will be in the order of 248 days or weeks. For a very small but critical fraction of the 249 prefixes, the requirement may be in the order of hours. 251 4.2. BGPSEC key rollover as a mechanism to protect against replay 252 attacks 254 The question we would like to ask is: can the key rollover process 255 earlier described provide a similar protection against replay attacks 256 without the need for beaconing? 258 The answer is that YES when the window requirement is in the order of 259 days and the BGP speaker re-keying is the edge router of the origin 260 AS and the full process is completed (i.e. the OLD and NEW 261 certificate do not share the same key). By using re-keying, you are 262 letting the BGPSEC certificate validation time as your timestamp 263 against replay attacks. However, the use of frequent key rollovers 264 comes with an additional administrative cost and risks if the process 265 fails. As documented before, re-keying should be supported by 266 automatic tools and for the great majority of the Internet it will be 267 done with good lead time to correct any risk. 269 For a transit AS that also originates BGP UPDATES for its own 270 prefixes, the key rollover process may generate a large number of 271 UPDATE messages (even the complete Default Free Zone or DFZ). For 272 this reason, it is recommended that routers in this scenario been 273 provisioned with two certificates: one to sign BGP UPDATES in transit 274 and a second one to sign BGP UPDATE for prefixes originated in its 275 AS. Only the second certificate (for prefixes originated in its AS) 276 should be rolled-over frequently as a means of limiting replay attach 277 windows. The transit BGPSEC certificate is expected to be longer 278 living than the origin BGPSEC certificate. 280 Advantage of Re-keying as replay attack protection mechanism: 282 1. Does not require beaconing 284 2. All expiration policies are maintained in RPKI 286 3. Most of the additional administrative cost is paid by the 287 provider that wants to protect its infrastructure (RP load will 288 increase as there is a need to validate more BGPSEC certificates) 290 4. Can be implemented in coordination with planned topology changes 291 by either origin ASes or transit ASes (if I am changing 292 providers, I rollover) 294 5. Eliminates the discussion on who has the authority over the 295 expiration time 297 Disadvantage of Re-keying as replay attack protection mechanism: 299 1. More administrative load due to frequent rollover, although how 300 frequent is still not clear. Some initial ideas in 301 [I-D.ietf-sidr-bgpsec-ops] 303 2. Minimum window size bounded by RPKI propagation time to RPKI 304 caches for new certificate and CRL (2x propagation time). If 305 pre-provisioning done ahead of time the minimum windows size is 306 reduced (to 1x propagation time for the CRL). However, more 307 experimentation is needed when RPKI and RPs are more massively 308 deployed. 310 3. Increases dynamics and size of RPKI repository. 312 4. More load on RPKI caches, but they are meant to do this work. 314 5. IANA Considerations 316 No IANA considerations 318 6. Security Considerations 320 No security considerations. 322 7. Acknowledgements 324 We would like to acknowledge Randy Bush, Sriram Kotikalapudi, Stephen 325 Kent and Sandy Murphy. 327 8. References 329 8.1. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 335 Authority (CA) Key Rollover in the Resource Public Key 336 Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012. 338 8.2. Informative References 340 [I-D.ietf-pkix-cmc-serverkeygeneration] 341 Schaad, J., Timmel, P., and S. Turner, "CMC Extensions: 342 Server Key Generation", draft-ietf-pkix-cmc- 343 serverkeygeneration-00 (work in progress), January 2012. 345 [I-D.ietf-pkix-est] 346 Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 347 Secure Transport", draft-ietf-pkix-est-02 (work in 348 progress), July 2012. 350 [I-D.ietf-sidr-bgpsec-ops] 351 Bush, R., "BGPsec Operational Considerations", draft-ietf- 352 sidr-bgpsec-ops-05 (work in progress), May 2012. 354 [I-D.ietf-sidr-bgpsec-reqs] 355 Bellovin, S., Bush, R., and D. Ward, "Security 356 Requirements for BGP Path Validation", draft-ietf-sidr- 357 bgpsec-reqs-03 (work in progress), March 2012. 359 [I-D.ietf-sidr-rtr-keying] 360 Turner, S., Patel, K., and R. Bush, "Router Keying for 361 BGPsec", draft-ietf-sidr-rtr-keying-00 (work in progress), 362 May 2012. 364 Authors' Addresses 366 Roque Gagliano 367 Cisco Systems 368 Avenue des Uttins 5 369 Rolle, VD 1180 370 Switzerland 372 Email: rogaglia@cisco.com 374 Keyur Patel 375 Cisco Systems 376 170 W. Tasman Driv 377 San Jose, CA 95134 378 CA 380 Email: keyupate@cisco.com 381 Brian Weis 382 Cisco Systems 383 170 W. Tasman Driv 384 San Jose, CA 95134 385 CA 387 Email: bew@cisco.com