idnits 2.17.1 draft-rogaglia-sidr-bgpsec-rollover-00.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 5, 2012) is 4434 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 290, but no explicit reference was found in the text == Unused Reference: 'RFC5101' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC5102' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-origin-validation-signaling' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-pfx-validate' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 321, 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 (-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 (~~), 9 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: July 4, 2012 Cisco Systems 6 March 5, 2012 8 BGPSEC router key roll-over as an alternative to beaconing 9 draft-rogaglia-sidr-bgpsec-rollover-00 11 Abstract 13 The current BGPSEC draft documents do not specifies a key roll-over 14 process for routers. This document describes a possible key roll- 15 over 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 July 4, 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 Roll-over in BGPSEC . . . . . . . . . . . . . . . . . . . 5 55 3.1. A proposed process for BGPSEC key roll-over . . . . . . . 5 56 4. BGPSEC key rollover as a measure against replays attacks 57 in BGPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. BGPSEC beaconing challenges . . . . . . . . . . . . . . . 7 59 4.2. BGPSEC Re-play attack window requirement . . . . . . . . . 7 60 4.3. BGPSEC key rollover as a mechanism to protect against 61 replay attacks . . . . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Requirements notation 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Introduction 78 In BGPSEC, a key roll-over (or re-keying) is the process of changing 79 the router's key pair, issuing the correspondent new End-Entity 80 certificates and revoke the old one. This process will need to 81 happen at regular intervals normally due to local policies at each 82 network. 84 During a roll-over process, a router needs to generate BGP UPDATE 85 messages in order to signal the new key to be used to its neighbors. 86 So, intuitively, a frequent key roll-over process has similar effects 87 as the beaconing process proposed by the BGPSEC base documents to 88 protect a BGPSEC attribute against a re-play attack. However, there 89 are a number of operational details to be considered if the expire 90 time field in the BGPSEC attribute is removed. 92 This document details a possible key roll-over process in BGPSEC and 93 explores the operational environment where key roll-overs could be 94 used as a protection against a re-play attach against BGPSEC 96 3. Key Roll-over in BGPSEC 98 The key roll-over process in BGPSEC has not been well defined yet. 99 However, this will be a mandatory process due to some of the 100 following causes: 102 BGPSEC scheduled roll-over: BGPSEC certificates have an expiration 103 date (NotValidAfter). Although it is possible to generate a 104 new certificate without changing the key pair, it is normally 105 good practice to adopt the policy of using a new key pair in 106 every roll-over event. 108 BGPSEC certificate fields changes: A BGPSEC certificate field's 109 information (such as the ASN or the Subject) may need to be 110 changed. The normal process requires the roll-over of the old 111 certificate with a new key pair and the revocation of the old 112 certificate. 114 BGPSEC emergency roll-over Some special circumstances (such as a 115 compromised key) may require the roll-over of a BGPSEC 116 certificate. 118 It should be clear at this point that a key roll-over process is 119 required for BGPSEC. The next section describes how this process may 120 be implemented. 122 3.1. A proposed process for BGPSEC key roll-over 124 The BGPSEC key roll-over process should be very tighten to the key 125 provisioning mechanisms that would be in place. The key provisioning 126 mechanisms for BGPSEC are not yet documented. We will assume that 127 such an automatic provisioning mechanism will be in place (a possible 128 provisioning mechanism when the private key lives only inside the BGP 129 speaker is the Enrollment over Secure Transport (EST). This protocol 130 will allow BGPSEC code to include automatic re-keying scripts with 131 minimum development cost. 133 When the same private key is shared by different routers, a mechanism 134 to distribute the private key will need to be implemented. A 135 possible solution may include the transmission of the private key 136 over a secure channel. The PKIX WG has started work on this sense by 137 adopting [I-D.ietf-pkix-cmc-serverkeygeneration] 139 If we work under the assumption that an automatic mechanism will 140 exist to rollover a BGPSEC certificate, a possible process could be: 142 1. New Certificate Pre-Publication: The first step in the rollover 143 mechanism is to pre-publish the new public key. In order to 144 accomplish this goal, the new key pair and certificate will need 145 to be generated and published on the correspondent RPKI 146 repository. This process will vary in every environment as it 147 will depend on where the keys are located (either in every router 148 or on a centralized server), if the RPKI CA is hosted at the ISP 149 or at an external party (i.e. needs to use the RPKI provisioning 150 protocol) and finally if the repository is also local or hosted 151 (i.e. will need to use the RPKI-Repository protocol.) 153 2. Stage Period: A stage period will be required from the time a new 154 certificate is published in the RPKI global repository until the 155 time it is fetched by RPKI caches around the globe. The exact 156 minimum staging time is not clear and will require experimental 157 results from RPKI. Design documents mention a lower limit of 24 158 hours. If rollovers will be done frequently and we want to avoid 159 the stage period in case of emergency rollover needs, an 160 administrator can always provision two certificate for every 161 router. In this case when the rollover operation is needed, the 162 cache servers around the globe would already have the new keys. 164 3. Twilight: At this moment, the BGP speaker that uses the key been 165 rolled-over will stop using the OLD key for signing and start 166 using the NEW key. Also, the router will generate appropriate 167 BGP UPDATES just as in the typical operation of refreshing out- 168 bound BGP polices. 170 4. CRL Publication: As part of the rollover process, a CA MAY decide 171 that it will publish the serial number of the OLD BGPSEC 172 certificate on its CRL. It may also be the case that the CA will 173 just let the certificate to expire and not update its CRL. 175 5. RPKI-Router Protocol Withdrawal: Either due to the inclusion of 176 the OLD certificate serial number or the expiration of the 177 certificate's validation, the RPKI cache servers around the globe 178 will need to communicate to its RTR peers that the OLD 179 certificate's public key is not longer valid (withdrawal 180 message). It is not documented yet what will be a router's 181 reaction to a RTR withdrawal message but it should include the 182 removal of any RIB entry that includes a BGPSEC attribute signed 183 with that key and the generation of the correspondent BGP 184 WITHDRAWS (either implicit or explicit). 186 To conclude this section, we can say that the proposed rollover 187 mechanism will depend on the existence of an automatic provisioning 188 process for BGPSEC certificates, that it will required a staging 189 mechanism given by RPKI propagation time of around 24hours and that 190 it will generate BGP UPDATES for all prefixes in the router been re- 191 keying. 193 4. BGPSEC key rollover as a measure against replays attacks in BGPSEC 195 There are two typical measures to mitigate replay attacks: addition 196 of a timestamp or addition of a serial number. Currently BGPSEC 197 offers a timestamp (expiration time) as a protection against re-play 198 attacks of BGPSEC messages. The process requires all BGP Speakers 199 that originate a BGP UPDATE to beaconing the message before its 200 expiration time. This requirement changes a long standing BGP 201 operation practice and the community have been searching for 202 alternatives. 204 4.1. BGPSEC beaconing challenges 206 To be completed 208 4.2. BGPSEC Re-play attack window requirement 210 The BGPSEC Ops document give some ideas of requirements for the re- 211 play attack in BGPSEC. For the vast majority of the prefixes, the 212 requirement will be in the order of days or weeks. For a very small 213 fraction, but critical, of the prefixes, the requirement may be in 214 the order of hours. 216 4.3. BGPSEC key rollover as a mechanism to protect against replay 217 attacks 219 The question we would like to ask is: can key rollover provide us a 220 similar protection against re-play attacks without the need for 221 beaconing? 223 The answer is that YES when the window requirement is in the order of 224 days and the router re-keying is the edge router of the origin AS. 225 By using re-keying, you are letting the BGPSEC certificate validation 226 time as your timestamp against replay attacks. However, the use of 227 frequent key rollovers comes with an additional administrative cost 228 and risks if the process fails. As documented before, re-keying 229 should be supported by automatic tools and for the great majority of 230 the Internet it will be done with good lead time to correct any 231 inconvenient in the process. 233 For a transit AS that also originates its BGP UPDATES for its own 234 prefixes, the key rollover process may generate a large number of 235 UPDATE messages (even the complete DFZ). For this reason, it is 236 recommended that routers in this scenario been provisioned with two 237 certificates: one to sign BGP UPDATES in transit and a second one to 238 sign BGP UPDATE for prefixes originated in its AS. Only the second 239 certificate should be frequently rolled-over. 241 Advantage of Re-keying as re-play attack protection mechanism: 243 1. Does not require beaconing 245 2. All timestamps policies are maintained in RPKI 247 3. Additional administrative cost is paid by the provider that wants 248 to protect its infrastructure 250 4. Can be implemented in coordination with planned topology changes 251 by either origin ASes or transit ASes (if I am changing 252 providers, I rollover) 254 5. Eliminates the discussion on who has the authority over the 255 expiration time 257 Disadvantage of Re-keying as re-play attack protection mechanism: 259 1. More administrative load due to frequent rollover, although how 260 frequent is still not clear. 262 2. Minimum window size bounded by RPKI propagation time to RPKI 263 caches. If pre-provisioning done ahead of time, it means 24 264 hours minimum in paper. However, more experimentation is needed 265 when RPKI and cache servers are more massively deployed. 267 3. Increases dynamic of RPKI repository 269 4. More load on RPKI caches, but they are meant to do this work. 271 5. IANA Considerations 273 No IANA considerations 275 6. Security Considerations 277 No security considerations. 279 7. Acknowledgements 281 None yet 283 8. References 285 8.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 291 Protocol 4 (BGP-4)", RFC 4271, January 2006. 293 [RFC5101] Claise, B., "Specification of the IP Flow Information 294 Export (IPFIX) Protocol for the Exchange of IP Traffic 295 Flow Information", RFC 5101, January 2008. 297 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 298 Meyer, "Information Model for IP Flow Information Export", 299 RFC 5102, January 2008. 301 8.2. Informative References 303 [I-D.ietf-pkix-cmc-serverkeygeneration] 304 Schaad, J., Timmel, P., and S. Turner, "CMC Extensions: 305 Server Key Generation", 306 draft-ietf-pkix-cmc-serverkeygeneration-00 (work in 307 progress), January 2012. 309 [I-D.ietf-sidr-origin-validation-signaling] 310 Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 311 Bush, "BGP Prefix Origin Validation State Extended 312 Community", draft-ietf-sidr-origin-validation-signaling-00 313 (work in progress), November 2010. 315 [I-D.ietf-sidr-pfx-validate] 316 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 317 Austein, "BGP Prefix Origin Validation", 318 draft-ietf-sidr-pfx-validate-01 (work in progress), 319 February 2011. 321 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 322 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 323 May 2008. 325 Authors' Addresses 327 Roque Gagliano 328 Cisco Systems 329 Avenue des Uttins 5 330 Rolle, VD 1180 331 Switzerland 333 Email: rogaglia@cisco.com 335 Keyur Patel 336 Cisco Systems 337 170 W. Tasman Driv 338 San Jose, CA 95134 339 CA 341 Email: keyupate@cisco.com 343 Brian Weis 344 Cisco Systems 345 170 W. Tasman Driv 346 San Jose, CA 95134 347 CA 349 Email: bew@cisco.com