RFC 8634

BGPsec Router Certificate Rollover

📅 published August 2019, from ietf

RFC 8634: BGPsec Router Certificate Rollover 🎀

okay bestie, this one is a Best Current Practice (that's BCP 224 🌸), written by B. Weis (Independent), R. Gagliano (Cisco Systems), and K. Patel (Arrcus, Inc.). It came out in August 2019 and it's ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract ✨

Certification Authorities (CAs) inside the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates and RPKI certificates 🔐 Rolling over BGPsec router certificates has to be done super carefully so the router public keys get distributed at the same time as the BGPsec UPDATE messages that get verified with them. This doc walks through a safe rollover process and explains when and why you'd need a rollover in the first place. If you follow this process, the rollover happens without any routing information getting 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, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, check out Section 2 of RFC 7841.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8634 🔗

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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 🦋

okay so in BGPsec, a key rollover (also called a re-key) is when a router swaps out its BGPsec key pair (or key pairs) 🔑 You issue a brand new BGPsec router certificate for the new keys and, if the old certificate is still valid, you revoke it. This has to happen at regular intervals, usually because of the local network's policies. The whole point of this doc is a safe rollover process that makes sure a BGPsec receiver always has the verification keys it needs ✨ Certification Practice Statement (CPS) documents may reference this memo 📎 It only covers changing a router's BGPsec key pair inside the RPKI. If you want to roll over RPKI Certification Authority key pairs, see [RFC6489] instead.

When a router receives or creates a new key pair (using a key provisioning mechanism), that key pair gets used to sign new BGPsec UPDATE messages [RFC8205] that are originated at the BGP speaker or that transit through it 💅 The BGP speaker also refreshes its outbound BGPsec UPDATE messages so they carry a signature made with the new key, replacing the old one. Once the rollover finishes, the old BGPsec router certificate (and its key) stops being valid, so any BGPsec UPDATE message signed with the old key becomes invalid 💀 That means if the router doesn't refresh its outbound BGPsec UPDATE messages, the routing info it already sent could end up being treated as unauthenticated after the rollover is done. So it is extremely important that new BGPsec router certificates get distributed throughout the RPKI before the router starts signing BGPsec UPDATE messages with a new private key 🙈

It's also a big deal for an AS to keep the BGPsec router key-rollover interval short. That's the stretch of time between when an AS distributes a BGPsec router certificate with a new public key and when a BGPsec router starts using its new private key 🧚 Sometimes a router has to send BGPsec UPDATE messages signed with a new private key so it can invalidate BGPsec UPDATE messages signed with the old one. For example, if the AS suspects that a stale BGPsec UPDATE message is being distributed in place of the most recently signed attribute, completing a key-rollover procedure can invalidate those stale messages 🍓 The interval can be kept short when an automated certificate provisioning process, like Enrollment over Secure Transport (EST) [RFC7030], is used.

"Security Requirements for BGP Path Validation" [RFC7353] also talks about the need to protect against suppression of BGP UPDATE messages with Withdrawn Routes, and against replay of BGP UPDATE messages. This is about controlling BGPsec's window of exposure to those attacks 🛡️ The BGPsec router certificate rollover method in this document can be used to reach that goal 👑

In [RFC8635], the "operator-driven" method is introduced, where one key pair can be shared among multiple BGP speakers 👯 In that setup, rolling over the matching BGPsec router certificate affects all the BGP speakers sharing that same private key 😭

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. 🎀 Only the all-caps versions count, so lowercase "may" is just regular English, bestie.

3. Key Rollover in BGPsec 🔄

A BGPsec router certificate SHOULD be replaced when any of the following events happen. It can also be replaced for any other reason, at the discretion of the AS responsible for that certificate ✨

  • Scheduled rollover: BGPsec router certificates have an expiration date (NotValidAfter) that calls for a frequent rollover process to refresh certificates or issue new ones 📅 The validity period is usually written down in the CA's CPS document.
  • Router certificate field changes: Info inside a BGPsec router certificate, like the Autonomous System Number (ASN) or the Subject, may need to change 🔧
  • Emergency router key rollover: Some special situations, like a compromised key, may mean the BGPsec router certificate has to be replaced 🚨
  • Protection against withdrawal suppression and replay attacks: An AS may find out 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 🫶

Sometimes you can make a new certificate without changing the key pair. That simplifies the rollover, because BGP speakers receiving BGPsec UPDATE messages don't even need to know the certificate changed 🥳 But here's the catch: not replacing the certificate key for a long stretch of time raises the risk that an attacker could use a compromised router private key to send 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's suspected that withdrawn BGPsec UPDATE messages are being distributed. Don't do it in those cases, babe 🙅‍♀️

3.1. Rollover Process ✨

okay so the key-rollover process depends on how the AS handles key provisioning [RFC8635]. an automatic provisioning mechanism like EST lets router key management include automatic re-keying methods with minimum development cost 🧚 bestie, that's giving efficiency 💅

a safe BGPsec router key-rollover goes like this 🎀

  1. New Certificate Publication: step one is publishing the new certificate 📜 if needed, a new key pair gets generated for the BGPsec router. then a new certificate is made and published at the right RPKI repository publication point.

the details vary depending on 1) whether keys are assigned per-BGPsec speaker or shared among multiple BGPsec speakers, 2) whether keys are generated on each BGPsec speaker or in a central location, and 3) whether the RPKI repository is hosted locally or externally. it's a whole thing 😭

  1. Staging Period: there has to be a staging period from when the new certificate gets published in the global RPKI repository until RPKI caches around the globe fetch it 🌍 the exact minimum staging time depends on the usual interval chosen between repository fetches. if rollovers happen more often, an administrator can provision two certificates for every router at once, with different valid start times. then, when rollover time comes, relying parties everywhere already have the new router public keys 🙌

but if the administrator didn't provision the next certificate ahead of time, a staging period might not be possible during an emergency key rollover 💀 without a staging period, routing can get disrupted because a BGPsec router can't validate BGPsec UPDATE messages signed with a new private key.

  1. Twilight: here, the BGPsec speaker holding the rolled-over private key stops using the old key for signing and starts using the new one ✨ the router also generates refreshed BGPsec UPDATE messages, just like it does in typical operation when it refreshes outbound BGP polices. this can produce a great number of BGPsec UPDATE messages 😵 so a BGPsec speaker may vary how it distributes BGPsec UPDATE messages in this step for every peer, to spread out the system load. skewing the rollover for different peers by a few minutes each would be sufficient and effective 🦋
  2. Certificate Revocation: this step is optional, but it SHOULD be taken when the goal is to invalidate BGPsec UPDATE messages signed with the old key 🚫 there are two reasons to invalidate old BGPsec UPDATE messages: (a) the AS has reason to believe 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). otherwise, the CA just lets the old certificate expire and doesn't revoke it. which one it picks depends on what motivated the rollover in the first place 🤷‍♀️
  3. RPKI-Router Protocol Withdrawals: when the old certificate's validation expires, the RPKI relying parties around the globe need to tell their router peers that the old certificate's public key is no longer valid. they can do this with the RPKI-Router Protocol described in [RFC8210] 📡 a router's reaction to a message saying a router key is being withdrawn in the RPKI-Router Protocol SHOULD include removing any RIB entries (i.e., BGPsec updates) signed with that key, and generating the matching BGP UPDATE message with Withdrawn Routes (either implicit or explicit) 🧹

this rollover mechanism depends on an automatic provisioning process for BGPsec router certificates. it needs a staging mechanism based on RPKI propagation time (at the time of writing, that's 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. no skipping this part, bestie 🙅‍♀️

the first two steps (New Certificate Publication and Staging Period) can happen ahead of the rest of the process. that lets a network operator do its later 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 🙈

4. BGPsec Router Key Rollover as a Measure against Replay Attacks ✨

there are two typical generic measures to mitigate replay attacks in any protocol: adding a timestamp or adding a serial number. the problem is, 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 talks about using key rollover as a way to mitigate replay attacks 🔁

4.1. BGP UPDATE Window of Exposure Requirement 💜

the need to limit vulnerability to replay attacks is described in Section 4.3 of [RFC7353]. one important point: during a window of exposure, a replay attack only works in very specific circumstances. there has to be a downstream topology change that makes the signed AS path no longer current, and that topology change has to make the replayed route preferable to the route tied to the new update. so if there's no topology change at all, there's no security threat from replaying 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 says the requirement is on 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 doing the re-keying is the edge router of the origin AS, it's feasible to use key rollover to mitigate replays 🙌 in this case, it's important to complete the full process (i.e., the old and new certificates do not share the same key). by re-keying, an AS lets the BGPsec router certificate validation time act as a kind of "timestamp" to mitigate replay attacks ⏰ but frequent key rollovers come with extra administrative cost and risks if the process fails 😬 as documented in [RFC8207], re-keying should be supported by automatic tools. for the great majority of the Internet, it will be done with good lead time, so the public key for the new router certificate will be available to validate the matching BGPsec UPDATE messages when they're received 💅

if a transit AS also originates BGPsec UPDATE messages for its own prefixes and wants to mitigate replay attacks on those prefixes, then the transit AS SHOULD be provisioned with two unique key pairs and certificates. one key pair signs 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 signs BGPsec UPDATE messages in transit and SHOULD NOT have a replay protection policy applied to it 🔐 the transit AS probably doesn't know or care about the policies of origin ASes elsewhere, so there's no value in the transit AS doing key rollovers to mitigate replay attacks against prefixes originated somewhere else 🤷‍♀️ if the transit AS did replay protection for every update it signs, its key-rollover process would generate a huge number of BGPsec UPDATE messages, even across the whole Default-Free Zone (DFZ) 😱 so it's 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:

  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, since it bears the cost of creating and starting distribution of new router key pairs and BGPsec router certificates. (it's true that the cost for relying parties is affected by the new objects, but their responses should be completely automated or otherwise routine 🤖)
  3. Re-keying can be coordinated with planned topology changes by either origin ASes or transit ASes. for example, if an AS changes providers, it completes a key rollover 🔄

disadvantages to re-keying as a replay attack protection mechanism:

  1. Frequent rollovers add administrative and BGP processing loads, although the required frequency isn't clear. some initial ideas are found in [RFC8207] 😵‍💫
  2. The minimum replay vulnerability is bounded by the propagation time for RPKI caches to get the new certificate and CRL. that's 2x propagation time, because the new certificate has to propagate first and then the CRL has to propagate through the RPKI system 🐢 if provisioning is done ahead of time, the minimum replay vulnerability window size drops to 1x propagation time (i.e., propagation of the CRL). these bounds will be better understood once the RPKI and RPKI relying party software are well deployed, and that will also help us understand the propagation time for objects in the RPKI 📈
  3. Re-keying increases the dynamics and size of the RPKI repository. 📦

5. IANA Considerations 🌈

This document has no IANA actions. ✨

6. Security Considerations 🔐

okay bestie, this section is SO important and I need you to take it seriously 😭💅 no cap, this doc doesn't change the RPKI or BGPsec protocols at all. what it does is describe a process for managing BGPsec router certificates inside the RPKI 🎀

so here's the thing. routers in BGPsec have to roll over their signing keys as part of normal certificate management 🔑 but rolling over a key also invalidates the BGPsec UPDATE message signatures made with the old one 💀 which means the rollover has to be super carefully orchestrated so valid BGPsec UPDATE messages don't accidentally get treated as invalid 🙈 if that goes wrong it could mess with Internet routing, and that is NOT it bestie 😭🫶 this document describes a safe way to roll over BGPsec router certificates, and it covers both normal rollovers and emergency ones 🦋

also, the key-rollover method here can be used as a measure against BGP UPDATE replay attacks 🕵️‍♀️✨ that's when someone in the routing system suppresses current BGPsec UPDATE messages and replays withdrawn updates instead 👀 once the key that signed the withdrawn updates has been rolled over, those withdrawn updates count as invalid 🙅‍♀️💜 and if certificates with a new public key get provisioned ahead of time, the minimum replay vulnerability window shrinks to the propagation time of a CRL that invalidates the certificate with the old public key 🌈⭐ for a discussion of why a stronger replay protection mechanism for BGPsec is hard to deploy, see [PROTECTION-DESIGN-DISCUSSION] 🧚

7. References 📚

7.1. Normative References 💖

7.2. Informative References 🌸

Acknowledgments 🫶

Randy Bush, Kotikalapudi Sriram, Stephen Kent, and Sandy Murphy each provided valuable suggestions resulting in an improved document 🌈 Kotikalapudi Sriram also contributed valuable guidance about using 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

📦 where this page comes from