diff options
Diffstat (limited to 'doc/rfc/rfc8634.txt')
| -rw-r--r-- | doc/rfc/rfc8634.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc8634.txt b/doc/rfc/rfc8634.txt new file mode 100644 index 0000000..9f9f496 --- /dev/null +++ b/doc/rfc/rfc8634.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Weis +Request for Comments: 8634 Independent +BCP: 224 R. Gagliano +Category: Best Current Practice Cisco Systems +ISSN: 2070-1721 K. Patel + Arrcus, Inc. + August 2019 + + + BGPsec Router Certificate Rollover + +Abstract + + Certification Authorities (CAs) within the Resource Public Key + Infrastructure (RPKI) manage BGPsec router certificates as well as + RPKI certificates. The rollover of BGPsec router certificates must + be carefully performed in order to synchronize the distribution of + router public keys with BGPsec UPDATE messages verified with those + router public keys. This document describes a safe rollover process, + and it discusses when and why the rollover of BGPsec router + certificates is necessary. When this rollover process is followed, + the rollover will be performed without routing information being + lost. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8634. + + + + + + + + + + + + + + +Weis, et al. Best Current Practice [Page 1] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 + 3. Key Rollover in BGPsec . . . . . . . . . . . . . . . . . . . 4 + 3.1. Rollover Process . . . . . . . . . . . . . . . . . . . . 5 + 4. BGPsec Router Key Rollover as a Measure against Replay + Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. BGP UPDATE Window of Exposure Requirement . . . . . . . . 7 + 4.2. BGPsec Key Rollover as a Mechanism to Protect against + Replay Attacks . . . . . . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 10 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + +1. Introduction + + In BGPsec, a key rollover (or re-key) is the process of changing a + router's BGPsec key pair (or key pairs), issuing the corresponding + new BGPsec router certificate, and (if the old certificate is still + valid) revoking the old certificate. This process will need to + happen at regular intervals, normally due to policies of the local + network. This document describes a safe rollover process that + results in a BGPsec receiver always having the needed verification + keys. Certification Practice Statement (CPS) documents may reference + this memo. This memo only addresses changing of a router's BGPsec + key pair within the RPKI. Refer to [RFC6489] for a procedure to roll + over RPKI Certification Authority key pairs. + + + + +Weis, et al. Best Current Practice [Page 2] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + + When a router receives or creates a new key pair (using a key + provisioning mechanism), this key pair will be used to sign new + BGPsec UPDATE messages [RFC8205] that are originated at or that + transit through the BGP speaker. Additionally, the BGP speaker will + refresh its outbound BGPsec UPDATE messages to include a signature + using the new key (replacing the old key). When the rollover process + finishes, the old BGPsec router certificate (and its key) will no + longer be valid; thus, any BGPsec UPDATE message that includes a + signature performed by the old key will be invalid. Consequently, if + the router does not refresh its outbound BGPsec UPDATE messages, + previously sent routing information may be treated as unauthenticated + after the rollover process is finished. Therefore, it is extremely + important that new BGPsec router certificates have been distributed + throughout the RPKI before the router begins signing BGPsec UPDATE + messages with a new private key. + + It is also important for an AS to minimize the BGPsec router key- + rollover interval (i.e., the period between the time when an AS + distributes a BGPsec router certificate with a new public key and the + time a BGPsec router begins to use its new private key). This can be + due to a need for a BGPsec router to distribute BGPsec UPDATE + messages signed with a new private key in order to invalidate BGPsec + UPDATE messages signed with the old private key. In particular, if + the AS suspects that a stale BGPsec UPDATE message is being + distributed instead of the most recently signed attribute, it can + cause the stale BGPsec UPDATE messages to be invalidated by + completing a key-rollover procedure. The BGPsec router rollover + interval can be minimized when an automated certificate provisioning + process such as Enrollment over Secure Transport (EST) [RFC7030] is + used. + + "Security Requirements for BGP Path Validation" [RFC7353] also + describes the need for protecting against suppression of BGP UPDATE + messages with Withdrawn Routes or replay of BGP UPDATE messages, such + as controlling BGPsec's window of exposure to such attacks. The + BGPsec router certificate rollover method in this document can be + used to achieve this goal. + + In [RFC8635], the "operator-driven" method is introduced, in which a + key pair can be shared among multiple BGP speakers. In this + scenario, the rollover of the corresponding BGPsec router certificate + will impact all the BGP speakers sharing the same private key. + + + + + + + + + +Weis, et al. Best Current Practice [Page 3] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Key Rollover in BGPsec + + A BGPsec router certificate SHOULD be replaced when the following + events occur, and it can be replaced for any other reason at the + discretion of the AS responsible for the BGPsec router certificate. + + Scheduled rollover: BGPsec router certificates have an expiration + date (NotValidAfter) that requires a frequent rollover process + to refresh certificates or issue new certificates. The + validity period for these certificates is typically expressed + in the CA's CPS document. + + Router certificate field changes: Information contained in a BGPsec + router certificate (such as the Autonomous System Number (ASN) + or the Subject) may need to be changed. + + Emergency router key rollover: Some special circumstances (such as a + compromised key) may require the replacement of a BGPsec router + certificate. + + Protection against withdrawal suppression and replay attacks: An AS + may determine that withdrawn BGPsec UPDATE messages are being + propagated instead of the most recently propagated BGPsec + UPDATE messages. Changing the BGPsec router signing key, + distributing a new BGPsec router certificate, and revoking the + old BGPsec router certificate will invalidate the replayed + BGPsec UPDATE messages. + + In some of these cases, it is possible to generate a new certificate + without changing the key pair. This practice simplifies the rollover + process as the BGP speakers receiving BGPsec UPDATE messages do not + even need to be aware of the change of certificate. However, not + replacing the certificate key for a long period of time increases the + risk that a compromised router private key may be used by an attacker + to deliver unauthorized or false BGPsec UPDATE messages. + Distributing the old public key in a new certificate is NOT + RECOMMENDED when the rollover event is due to a compromised key or + when it is suspected that withdrawn BGPsec UPDATE messages are being + distributed. + + + + +Weis, et al. Best Current Practice [Page 4] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + +3.1. Rollover Process + + The key-rollover process is dependent on the key provisioning + mechanisms adopted by an AS [RFC8635]. An automatic provisioning + mechanism such as EST will allow procedures for router key management + to include automatic re-keying methods with minimum development cost. + + A safe BGPsec router key-rollover process is as follows. + + 1. New Certificate Publication: The first step in the rollover + mechanism is to publish the new certificate. If required, a new + key pair will be generated for the BGPsec router. A new + certificate will be generated and the certificate will be + published at the appropriate RPKI repository publication point. + + The details of this process will vary as they depend on 1) + whether the keys are assigned per-BGPsec speaker or shared among + multiple BGPsec speakers, 2) whether the keys are generated on + each BGPsec speaker or in a central location, and 3) whether the + RPKI repository is locally or externally hosted. + + 2. Staging Period: A staging period will be required from the time a + new certificate is published in the global RPKI repository until + the time it is fetched by RPKI caches around the globe. The + exact minimum staging time will be dictated by the conventional + interval chosen between repository fetches. If rollovers will be + done more frequently, an administrator can provision two + certificates for every router concurrently with different valid + start times. In this case, when the rollover operation is + needed, the relying parties around the globe would already have + the new router public keys. However, if an administrator has not + previously provisioned the next certificate, implementing a + staging period may not be possible during emergency key rollover. + If there is no staging period, routing may be disrupted due to + the inability of a BGPsec router to validate BGPsec UPDATE + messages signed with a new private key. + + 3. Twilight: In this step, the BGPsec speaker holding the rolled- + over private key will stop using the old key for signing and will + start using the new key. Also, the router will generate + appropriate refreshed BGPsec UPDATE messages, just as in the + typical operation of refreshing outbound BGP polices. This + operation may generate a great number of BGPsec UPDATE messages. + A BGPsec speaker may vary the distribution of BGPsec UPDATE + messages in this step for every peer in order to distribute the + system load (e.g., skewing the rollover for different peers by a + few minutes each would be sufficient and effective). + + + + +Weis, et al. Best Current Practice [Page 5] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + + 4. Certificate Revocation: This is an optional step, but it SHOULD + be taken when the goal is to invalidate BGPsec UPDATE messages + signed with the old key. Reasons to invalidate old BGPsec UPDATE + messages include (a) the AS has reason to believe that the router + signing key has been compromised, and (b) the AS needs to + invalidate already-propagated BGPsec UPDATE messages signed with + the old key. As part of the rollover process, a CA MAY decide to + revoke the old certificate by publishing its serial number on the + CA's Certificate Revocation List (CRL). Alternatively, the CA + will just let the old certificate expire and not revoke it. This + choice will depend on the reasons that motivated the rollover + process. + + 5. RPKI-Router Protocol Withdrawals: At the expiration of the old + certificate's validation, the RPKI relying parties around the + globe will need to communicate to their router peers that the old + certificate's public key is no longer valid (e.g., using the + RPKI-Router Protocol described in [RFC8210]). A router's + reaction to a message indicating withdrawal of a router key in + the RPKI-Router Protocol SHOULD include the removal of any RIB + entries (i.e., BGPsec updates) signed with that key and the + generation of the corresponding BGP UPDATE message with Withdrawn + Routes (either implicit or explicit). + + This rollover mechanism depends on the existence of an automatic + provisioning process for BGPsec router certificates. It requires a + staging mechanism based on the RPKI propagation time (at the time of + writing, this is typically a 24-hour period), and an AS is REQUIRED + to re-sign all originated and transited BGPsec UPDATE messages that + were previously signed with the old key. + + The first two steps (New Certificate Publication and Staging Period) + may happen in advance of the rest of the process. This will allow a + network operator to perform its subsequent key rollover in an + efficient and timely manner. + + When a new BGPsec router certificate is generated without changing + its key, steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals) + SHOULD NOT be executed. + + + + + + + + + + + + +Weis, et al. Best Current Practice [Page 6] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + +4. BGPsec Router Key Rollover as a Measure against Replay Attacks + + There are two typical generic measures to mitigate replay attacks in + any protocol: the addition of a timestamp or the addition of a serial + number. However, neither BGP nor BGPsec provides these measures. + The timestamp approach was originally proposed for BGPsec + [PROTECTION-DESIGN-DISCUSSION] but was later dropped in favor of the + key-rollover approach. This section discusses the use of key + rollover as a measure to mitigate replay attacks. + +4.1. BGP UPDATE Window of Exposure Requirement + + The need to limit the vulnerability to replay attacks is described in + Section 4.3 of [RFC7353]. One important comment is that during a + window of exposure, a replay attack is effective only in very + specific circumstances: there is a downstream topology change that + makes the signed AS path no longer current, and the topology change + makes the replayed route preferable to the route associated with the + new update. In particular, if there is no topology change at all, + then no security threat comes from a replay of a BGPsec UPDATE + message because the signed information is still valid. + + "BGPsec Operational Considerations" [RFC8207] gives some idea of + requirements for the size of the window of exposure to replay + attacks. It states that the requirement will be in the order of a + day or longer. + +4.2. BGPsec Key Rollover as a Mechanism to Protect against Replay + Attacks + + Since the window requirement is on the order of a day (as documented + in [RFC8207]) and the BGP speaker performing re-keying is the edge + router of the origin AS, it is feasible to use key rollover to + mitigate replays. In this case, it is important to complete the full + process (i.e., the old and new certificates do not share the same + key). By re-keying, an AS is letting the BGPsec router certificate + validation time be a type of "timestamp" to mitigate replay attacks. + However, the use of frequent key rollovers comes with an additional + administrative cost and risks if the process fails. As documented in + [RFC8207], re-keying should be supported by automatic tools, and for + the great majority of the Internet, it will be done with good lead + time to ensure that the public key corresponding to the new router + certificate will be available to validate the corresponding BGPsec + UPDATE messages when received. + + If a transit AS also originates BGPsec UPDATE messages for its own + prefixes and it wishes to mitigate replay attacks on those prefixes, + then the transit AS SHOULD be provisioned with two unique key pairs + + + +Weis, et al. Best Current Practice [Page 7] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + + and certificates. One of the key pairs is used to sign BGPsec UPDATE + messages for prefixes originated from the transit AS, and it can have + a replay protection policy applied to it. The other key pair is used + to sign BGPsec UPDATE messages in transit and SHOULD NOT have a + replay protection policy applied to it. Because the transit AS is + not likely to know or care about the policy of origin ASes elsewhere, + there is no value gained by the transit AS performing key rollovers + to mitigate replay attacks against prefixes originated elsewhere. If + the transit AS were instead to perform replay protection for all + updates that it signs, its process for key rollovers would generate a + large number of BGPsec UPDATE messages, even in the complete Default- + Free Zone (DFZ). Therefore, it is best to let each AS independently + manage the replay attack vulnerability window for the prefixes it + originates. + + Advantages to re-keying as a replay attack protection mechanism are + as follows: + + 1. All expiration policies are maintained in the RPKI. + + 2. Much of the additional administrative cost is paid by the + provider that wants to protect its infrastructure, as it bears + the cost of creating and initiating distribution of new router + key pairs and BGPsec router certificates. (It is true that the + cost of relying parties will be affected by the new objects, but + their responses should be completely automated or otherwise + routine.) + + 3. The re-keying can be implemented in coordination with planned + topology changes by either origin ASes or transit ASes (e.g., if + an AS changes providers, it completes a key rollover). + + Disadvantages to re-keying as replay attack protection mechanism are + as follows: + + 1. Frequent rollovers add administrative and BGP processing loads, + although the required frequency is not clear. Some initial ideas + are found in [RFC8207]. + + 2. The minimum replay vulnerability is bounded by the propagation + time for RPKI caches to obtain the new certificate and CRL (2x + propagation time because first the new certificate and then the + CRL need to propagate through the RPKI system). If provisioning + is done ahead of time, the minimum replay vulnerability window + size is reduced to 1x propagation time (i.e., propagation of the + CRL). However, these bounds will be better understood when the + + + + + +Weis, et al. Best Current Practice [Page 8] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + + RPKI and RPKI relying party software are well deployed; this will + also contribute to the propagation time for objects in the RPKI + being better understood. + + 3. Re-keying increases the dynamics and size of the RPKI repository. + +5. IANA Considerations + + This document has no IANA actions. + +6. Security Considerations + + This document does not contain a protocol update to either the RPKI + or BGPsec. It describes a process for managing BGPsec router + certificates within the RPKI. + + Routers participating in BGPsec will need to roll over their signing + keys as part of conventional processing of certificate management. + However, because rolling over signing keys will also have the effect + of invalidating BGPsec UPDATE message signatures, the rollover + process must be carefully orchestrated to ensure that valid BGPsec + UPDATE messages are not treated as invalid. This situation could + affect Internet routing. This document describes a safe method for + rolling over BGPsec router certificates. It takes into account both + normal and emergency key-rollover requirements. + + Additionally, the key-rollover method described in this document can + be used as a measure to mitigate BGP UPDATE replay attacks, in which + an entity in the routing system is suppressing current BGPsec UPDATE + messages and replaying withdrawn updates. When the key used to sign + the withdrawn updates has been rolled over, the withdrawn updates + will be considered invalid. When certificates containing a new + public key are provisioned ahead of time, the minimum replay + vulnerability window size is reduced to the propagation time of a CRL + invalidating the certificate containing an old public key. For a + discussion of the difficulties deploying a more effectual replay + protection mechanism for BGPSEC, see [PROTECTION-DESIGN-DISCUSSION]. + + + + + + + + + + + + + + +Weis, et al. Best Current Practice [Page 9] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for + BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, + <https://www.rfc-editor.org/info/rfc8635>. + +7.2. Informative References + + [PROTECTION-DESIGN-DISCUSSION] + Sriram, K. and D. Montgomery, "Design Discussion and + Comparison of Protection Mechanisms for Replay Attack and + Withdrawal Suppression in BGPsec", Work in Progress, + draft-sriram-replay-protection-design-discussion-12, April + 2019. + + [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification + Authority (CA) Key Rollover in the Resource Public Key + Infrastructure (RPKI)", BCP 174, RFC 6489, + DOI 10.17487/RFC6489, February 2012, + <https://www.rfc-editor.org/info/rfc6489>. + + [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., + "Enrollment over Secure Transport", RFC 7030, + DOI 10.17487/RFC7030, October 2013, + <https://www.rfc-editor.org/info/rfc7030>. + + [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security + Requirements for BGP Path Validation", RFC 7353, + DOI 10.17487/RFC7353, August 2014, + <https://www.rfc-editor.org/info/rfc7353>. + + [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol + Specification", RFC 8205, DOI 10.17487/RFC8205, September + 2017, <https://www.rfc-editor.org/info/rfc8205>. + + + + + + +Weis, et al. Best Current Practice [Page 10] + +RFC 8634 BGPsec Certificate Rollover August 2019 + + + [RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, + RFC 8207, DOI 10.17487/RFC8207, September 2017, + <https://www.rfc-editor.org/info/rfc8207>. + + [RFC8210] Bush, R. and R. Austein, "The Resource Public Key + Infrastructure (RPKI) to Router Protocol, Version 1", + RFC 8210, DOI 10.17487/RFC8210, September 2017, + <https://www.rfc-editor.org/info/rfc8210>. + +Acknowledgments + + Randy Bush, Kotikalapudi Sriram, Stephen Kent, and Sandy Murphy each + provided valuable suggestions resulting in an improved document. + Kotikalapudi Sriram contributed valuable guidance regarding the use + of key rollovers to mitigate BGP UPDATE replay attacks. + +Authors' Addresses + + Brian Weis + Independent + + Email: bew.stds@gmail.com + + + Roque Gagliano + Cisco Systems + Avenue des Uttins 5 + Rolle, VD 1180 + Switzerland + + Email: rogaglia@cisco.com + + + Keyur Patel + Arrcus, Inc. + + Email: keyur@arrcus.com + + + + + + + + + + + + + + +Weis, et al. Best Current Practice [Page 11] + |