idnits 2.17.1 draft-rogaglia-sidr-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 (June 5, 2012) is 4336 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: 'RFC4271' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC5101' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC5102' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-bgpsec-threats' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-origin-validation-signaling' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-pfx-validate' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 345, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-12) exists of draft-ietf-sidr-bgpsec-reqs-03 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-bgpsec-threats-02 == Outdated reference: A later version (-11) exists of draft-ietf-sidr-origin-validation-signaling-00 == Outdated reference: A later version (-10) exists of draft-ietf-sidr-pfx-validate-01 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). 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: December 7, 2012 Cisco Systems 6 June 5, 2012 8 BGPSEC router key rollover as an alternative to beaconing 9 draft-rogaglia-sidr-bgpsec-rollover-01 11 Abstract 13 The current BGPSEC draft documents do not specifies a key rollover 14 process for routers. This document describes a possible key rollover 15 process and explores its impact to mitigate replay attacks and 16 eliminate the need for beaconing in BGPSEC. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 7, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Key rollover in BGPSEC . . . . . . . . . . . . . . . . . . . . 5 55 3.1. A proposed process for BGPSEC key rollover . . . . . . . . 5 56 4. BGPSEC key rollover as a measure against replays attacks 57 in BGPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.1. BGPSEC Re-play attack window requirement . . . . . . . . . 8 59 4.2. BGPSEC key rollover as a mechanism to protect against 60 replay attacks . . . . . . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 69 1. Requirements notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 In BGPSEC, a key rollover (or re-keying) is the process of changing 78 the router's key pair, issuing the correspondent new End-Entity 79 certificates and revoke the old certificate. This process will need 80 to happen at regular intervals normally due to local policies at each 81 network. 83 During a rollover process, a router needs to generate BGP UPDATE 84 messages in order to signal the new key to be used to its neighbors. 85 So, intuitively, a frequent key rollover process has similar effects 86 as the beaconing process proposed by the BGPSEC base documents to 87 protect a BGPSEC attribute against a re-play attack. However, there 88 are a number of operational details to be considered if the expire 89 time field in the BGPSEC attribute is removed. 91 This document details a possible key rollover process in BGPSEC and 92 explores the operational environment where key rollovers could be 93 used as a protection against a re-play attach against BGPSEC 95 3. Key rollover in BGPSEC 97 The key rollover process in BGPSEC has not been well defined yet. 98 However, this will be a mandatory process due to some of the 99 following causes: 101 BGPSEC scheduled rollover: BGPSEC certificates have an expiration 102 date (NotValidAfter). Although it is possible to generate a 103 new certificate without changing the key pair, it is normally 104 good practice to adopt the policy of using a new key pair in 105 every rollover event. 107 BGPSEC certificate fields changes: A BGPSEC certificate field's 108 information (such as the ASN or the Subject) may need to be 109 changed. The normal process requires the rollover of the old 110 certificate with a new key pair and the revocation of the old 111 certificate. 113 BGPSEC emergency rollover Some special circumstances (such as a 114 compromised key) may require the rollover of a BGPSEC 115 certificate. 117 It should be clear at this point that a key rollover process is 118 required for BGPSEC. The next section describes how this process may 119 be implemented. 121 3.1. A proposed process for BGPSEC key rollover 123 The BGPSEC key rollover process should be very tighten to the key 124 provisioning mechanisms that would be in place. The key provisioning 125 mechanisms for BGPSEC are not yet documented. We will assume that 126 such an automatic provisioning mechanism will be in place (a possible 127 provisioning mechanism when the private key lives only inside the BGP 128 speaker is the Enrollment over Secure Transport (EST). This protocol 129 will allow BGPSEC code to include automatic re-keying scripts with 130 minimum development cost. 132 When the same private key is shared by different routers, a mechanism 133 to distribute the private key will need to be implemented. A 134 possible solution may include the transmission of the private key 135 over a secure channel. The PKIX WG has started work on this sense by 136 adopting [I-D.ietf-pkix-cmc-serverkeygeneration] 138 If we work under the assumption that an automatic mechanism will 139 exist to rollover a BGPSEC certificate, a possible process could be: 141 1. New Certificate Pre-Publication: The first step in the rollover 142 mechanism is to pre-publish the new public key. In order to 143 accomplish this goal, the new key pair and certificate will need 144 to be generated and published on the correspondent RPKI 145 repository. This process will vary in every environment as it 146 will depend on where the keys are located (either in every router 147 or on a centralized server), if the RPKI CA is hosted at the ISP 148 or at an external party (i.e. needs to use the RPKI provisioning 149 protocol) and finally if the repository is also local or hosted 150 (i.e. will need to use the RPKI-Repository protocol.) 152 2. Stage Period: A stage period will be required from the time a new 153 certificate is published in the RPKI global repository until the 154 time it is fetched by RPKI caches around the globe. The exact 155 minimum staging time is not clear and will require experimental 156 results from RPKI. Design documents mention a lower limit of 24 157 hours. If rollovers will be done frequently and we want to avoid 158 the stage period in case of emergency rollover needs, an 159 administrator can always provision two certificate for every 160 router. In this case when the rollover operation is needed, the 161 cache servers around the globe would already have the new keys. 163 3. Twilight: At this moment, the BGP speaker that uses the key been 164 rolled-over will stop using the OLD key for signing and start 165 using the NEW key. Also, the router will generate appropriate 166 BGP UPDATES just as in the typical operation of refreshing out- 167 bound BGP polices. This operation may generate a great number of 168 BGP UPDATE messages. In any given BGP SPEAKER, the Twilight 169 moment may be different for every peer in order to distribute the 170 system load. 172 4. CRL Publication: As part of the rollover process, a CA MAY decide 173 that it will publish the serial number of the OLD BGPSEC 174 certificate on its CRL. It may also be the case that the CA will 175 just let the certificate to expire and not update its CRL. 177 5. RPKI-Router Protocol Withdrawal: Either due to the inclusion of 178 the OLD certificate serial number or the expiration of the 179 certificate's validation, the RPKI cache servers around the globe 180 will need to communicate to its RTR peers that the OLD 181 certificate's public key is not longer valid (rtr withdrawal 182 message). It is not documented yet what will be a router's 183 reaction to a RTR withdrawal message but it should include the 184 removal of any RIB entry that includes a BGPSEC attribute signed 185 with that key and the generation of the correspondent BGP 186 WITHDRAWS (either implicit or explicit). 188 The proposed rollover mechanism will depend on the existence of an 189 automatic provisioning process for BGPSEC certificates, it will 190 require a staging mechanism given by RPKI propagation time of around 191 24hours and it will generate BGP UPDATES for all prefixes in the 192 router been re-keying. 194 The first two steps (New Certificate Pre-Publication and Stage 195 Period) could happen ahead of time from the rest of the process as 196 network operators could prepare itself to accelerate a future key 197 roll-over. 199 4. BGPSEC key rollover as a measure against replays attacks in BGPSEC 201 There are two typical measures to mitigate replay attacks: addition 202 of a timestamp or addition of a serial number. Currently BGPSEC 203 offers a timestamp (expiration time) as a protection against re-play 204 attacks of BGPSEC messages. The process requires all BGP Speakers 205 that originate a BGP UPDATE to beaconing the message before its 206 expiration time. This requirement changes a long standing BGP 207 operation practice and the community have been searching for 208 alternatives. 210 4.1. BGPSEC Re-play attack window requirement 212 In [I-D.ietf-sidr-bgpsec-reqs] Sections 3.7 and 4.3, the replay 213 attack requirements are set. One important comment is that during 214 the windows of exposure, a replay attack is only effective if there 215 was a downstream topology change that makes the signed AS path not 216 longer current. In other words, if there has been no topology 217 changes, no security threat comes from a replay of a BGP UPDATE 218 message. 220 The BGPSEC Ops document give some ideas of requirements for the re- 221 play attack in BGPSEC. For the vast majority of the prefixes, the 222 requirement will be in the order of days or weeks. For a very small 223 fraction, but critical, of the prefixes, the requirement may be in 224 the order of hours. 226 4.2. BGPSEC key rollover as a mechanism to protect against replay 227 attacks 229 The question we would like to ask is: can key rollover provide us a 230 similar protection against re-play attacks without the need for 231 beaconing? 233 The answer is that YES when the window requirement is in the order of 234 days and the router re-keying is the edge router of the origin AS. 235 By using re-keying, you are letting the BGPSEC certificate validation 236 time as your timestamp against replay attacks. However, the use of 237 frequent key rollovers comes with an additional administrative cost 238 and risks if the process fails. As documented before, re-keying 239 should be supported by automatic tools and for the great majority of 240 the Internet it will be done with good lead time to correct any 241 inconvenient in the process. 243 For a transit AS that also originates its BGP UPDATES for its own 244 prefixes, the key rollover process may generate a large number of 245 UPDATE messages (even the complete DFZ). For this reason, it is 246 recommended that routers in this scenario been provisioned with two 247 certificates: one to sign BGP UPDATES in transit and a second one to 248 sign BGP UPDATE for prefixes originated in its AS. Only the second 249 certificate should be frequently rolled-over. Consequently, the 250 transit BGPSEC certificate is expected to be longer living than the 251 origin BGPSEC certificate. 253 Advantage of Re-keying as re-play attack protection mechanism: 255 1. Does not require beaconing 257 2. All timestamps policies are maintained in RPKI 259 3. Additional administrative cost is paid by the provider that wants 260 to protect its infrastructure 262 4. Can be implemented in coordination with planned topology changes 263 by either origin ASes or transit ASes (if I am changing 264 providers, I rollover) 266 5. Eliminates the discussion on who has the authority over the 267 expiration time 269 Disadvantage of Re-keying as re-play attack protection mechanism: 271 1. More administrative load due to frequent rollover, although how 272 frequent is still not clear. 274 2. Minimum window size bounded by RPKI propagation time to RPKI 275 caches. If pre-provisioning done ahead of time, it means 24 276 hours minimum in paper. However, more experimentation is needed 277 when RPKI and cache servers are more massively deployed. 279 3. Increases dynamic of RPKI repository 281 4. More load on RPKI caches, but they are meant to do this work. 283 5. IANA Considerations 285 No IANA considerations 287 6. Security Considerations 289 No security considerations. 291 7. Acknowledgements 293 We would like to acknowledge Randy Bush, Sriram Kotikalapudi, Stephen 294 Kent and Sandy Murphy. 296 8. References 298 8.1. Normative References 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 304 Protocol 4 (BGP-4)", RFC 4271, January 2006. 306 [RFC5101] Claise, B., "Specification of the IP Flow Information 307 Export (IPFIX) Protocol for the Exchange of IP Traffic 308 Flow Information", RFC 5101, January 2008. 310 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 311 Meyer, "Information Model for IP Flow Information Export", 312 RFC 5102, January 2008. 314 8.2. Informative References 316 [I-D.ietf-pkix-cmc-serverkeygeneration] 317 Schaad, J., Timmel, P., and S. Turner, "CMC Extensions: 318 Server Key Generation", 319 draft-ietf-pkix-cmc-serverkeygeneration-00 (work in 320 progress), January 2012. 322 [I-D.ietf-sidr-bgpsec-reqs] 323 Bellovin, S., Bush, R., and D. Ward, "Security 324 Requirements for BGP Path Validation", 325 draft-ietf-sidr-bgpsec-reqs-03 (work in progress), 326 March 2012. 328 [I-D.ietf-sidr-bgpsec-threats] 329 Kent, S. and A. Chi, "Threat Model for BGP Path Security", 330 draft-ietf-sidr-bgpsec-threats-02 (work in progress), 331 February 2012. 333 [I-D.ietf-sidr-origin-validation-signaling] 334 Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 335 Bush, "BGP Prefix Origin Validation State Extended 336 Community", draft-ietf-sidr-origin-validation-signaling-00 337 (work in progress), November 2010. 339 [I-D.ietf-sidr-pfx-validate] 340 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 341 Austein, "BGP Prefix Origin Validation", 342 draft-ietf-sidr-pfx-validate-01 (work in progress), 343 February 2011. 345 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 346 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 347 May 2008. 349 Authors' Addresses 351 Roque Gagliano 352 Cisco Systems 353 Avenue des Uttins 5 354 Rolle, VD 1180 355 Switzerland 357 Email: rogaglia@cisco.com 359 Keyur Patel 360 Cisco Systems 361 170 W. Tasman Driv 362 San Jose, CA 95134 363 CA 365 Email: keyupate@cisco.com 367 Brian Weis 368 Cisco Systems 369 170 W. Tasman Driv 370 San Jose, CA 95134 371 CA 373 Email: bew@cisco.com