RFC 8635

Router Keying for BGPsec

📅 published August 2019, from ietf

Router Keying for BGPsec 🎀

Okay bestie, let's get into it! 💖 This is RFC 8635, and it's all about how BGPsec routers get their keys. It came out in August 2019 as a Standards Track document, which means it's a real Internet standard, not just a vibe. ✨ It was written by R. Bush (IIJ Lab & Arrcus), S. Turner (sn3rd), and K. Patel (Arrcus, Inc.). 👑 Nothing in the title block says it obsoletes or updates any other RFC, so it stands on its own. 🦋

1. Introduction ✨

Abstract

Okay so the abstract is the quick pitch 💅 BGPsec-speaking routers get loaded up with private keys so they can sign BGPsec announcements. The matching public keys get published in the Global Resource Public Key Infrastructure (RPKI), so everyone can verify those messages. 🔥 This doc describes two ways to generate those key pairs: router-driven and operator-driven. Main character energy! 🌟

Status of This Memo

This is an Internet Standards Track document. 🎀

This is a product of the Internet Engineering Task Force (IETF), so it represents what the IETF community agreed on. ✨ It got public review and was approved by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841. 💜

Info about its current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8635. 🌸

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 stood on the date of publication. Please actually read these, bestie, because they explain your rights and restrictions. 🙈 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 with no warranty, as described in the Simplified BSD License. 💅

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
3.  Management/Router Communication . . . . . . . . . . . . . . .   3
4.  Exchange Certificates . . . . . . . . . . . . . . . . . . . .   4
5.  Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
6.  Generate PKCS#10  . . . . . . . . . . . . . . . . . . . . . .   5
  6.1.  Router-Driven Keys  . . . . . . . . . . . . . . . . . . .   5
  6.2.  Operator-Driven Keys  . . . . . . . . . . . . . . . . . .   6
    6.2.1.  Using PKCS#8 to Transfer Private Keys . . . . . . . .   6
7.  Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . .   7
8.  Install Certificate . . . . . . . . . . . . . . . . . . . . .   7
9.  Advanced Deployment Scenarios . . . . . . . . . . . . . . . .   8
10. Key Management  . . . . . . . . . . . . . . . . . . . . . . .   9
  10.1.  Key Validity . . . . . . . . . . . . . . . . . . . . . .  10
  10.2.  Key Rollover . . . . . . . . . . . . . . . . . . . . . .  10
  10.3.  Key Revocation . . . . . . . . . . . . . . . . . . . . .  11
  10.4.  Router Replacement . . . . . . . . . . . . . . . . . . .  11
11. Security Considerations . . . . . . . . . . . . . . . . . . .  12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  13
13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  13.1.  Normative References . . . . . . . . . . . . . . . . . .  13
  13.2.  Informative References . . . . . . . . . . . . . . . . .  14
Appendix A.  Management/Router Channel Security . . . . . . . . .  17
Appendix B.  An Introduction to BGPsec Key Management . . . . . .  18
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

Here's the map of the whole doc! 🧚 This is part 1, so the rest of the sections are coming in the next parts. 💜

1. Introduction 🌈

BGPsec-speaking routers get provisioned with private keys, which let them digitally sign BGPsec announcements. 🖊️ To verify the signature, the public key (in the form of a certificate [RFC8209]) gets published in the Resource Public Key Infrastructure (RPKI). 🔐 This document describes how to provision BGPsec-speaking routers with the right public-private key pairs. There are two methods: router-driven and operator-driven. 🎀

These two methods are different in where the keys get generated. In the router-driven method, it happens on the router. In the operator-driven method, it happens somewhere else. 🦋

They also differ in who makes the key pair. In the operator-driven method, the operator generates the pair and sends it to the router. In the router-driven method, the router makes its own pair. 💅

The router-driven method copies the model traditional PKI subscribers use. The private key never leaves trusted storage (for example, a Hardware Security Module (HSM)). 🔒 This is intentional, and it matches classic PKI Certification Policies for (often human) subscribers. Those policies require that only the subscriber ever controls the private key, so nobody can impersonate them. 🙈 For non-humans, though, this method doesn't always work. 🤖

The operator-driven method exists because keeping the network running is extremely important. In some deployments, the soon-to-be online router needs the same private key as the soon-to-be offline router it's replacing. 🔁 This "hot-swapping" can mean minimal downtime, especially compared with the normal RPKI procedures for propagating a new key, which can take a day or longer to converge. 😭

For example, if an operator wants hot-swappable routers, the same private key has to be installed in the soon-to-be online router that the soon-to-be offline router was using. ✨ That's the reason the operator-driven method was motivated. 💖

Sections 3 through 8 walk through the steps an operator takes to use the two methods to provision new and existing routers. These methods have the operator configure both endpoints (the management station and the router) and act as the middleman. 🧑‍💻 Section 9 covers another method that needs more-capable routers. 🚀

Useful References: [RFC8205] describes the details of BGPsec, [RFC8209] specifies the format for the PKCS#10 certification request, and [RFC8608] specifies the algorithms used to generate the PKCS#10 signature. 📚

2. Requirements Language 💜

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. Management/Router Communication 🛡️

Operators are free to use either the router-driven or the operator-driven method, as long as the platform supports it. 💅 Prudent security practice recommends router-generated keying, if the delay in replacing a router (or router engine) is acceptable to the operator. 🔐 No matter which method is chosen, operators first set up a protected channel between the management system and the router. 🫶 This channel prevents eavesdropping, tampering, and message forgery, and it also provides mutual authentication. ✨ How that channel gets established is router-specific and out of scope for this document. 🙈 Other configuration mechanisms might be used, for example the Network Configuration Protocol (NETCONF) (see [RFC6470]), but the protected channel between the management platform and the router is assumed to be an SSH-protected CLI. 💻 See Appendix A for security considerations for this protected channel. 🦋

The previous paragraph assumes the management-system-to-router communications happen over a network. When the management system has a direct physical connection to the router, for example via the craft port, there is no assumption that a protected channel exists between the two. 🔌

To be clear, for both of these methods, an initial leap of faith is required, because the router has no keying material it can use to protect communications with anyone or anything. 🪂 Because of that initial leap of faith, a direct physical connection is safer than a network connection, since there's less chance of a monkey in the middle. 🐒 Once keying material is set up on the router, the communications channel MUST prevent eavesdropping, tampering, and message forgery. 😭 This initial leap of faith will no longer be required once routers are delivered to operators with operator-trusted keying material. 🌟

4. Exchange Certificates 📮

A number of options exist for the operator's management station to exchange PKI-related information with routers and with the RPKI, including:

  • Using application/pkcs10 media type [RFC5967] to extract certificate requests and application/pkcs7-mime [RFC8551] to return the issued certificate,
  • Using FTP or HTTP per [RFC2585], and
  • Using the Enrollment over Secure Transport (EST) protocol per [RFC7030].

Despite the fact that certificates are integrity-protected and don't necessarily need extra protection, transports that also provide integrity protection are RECOMMENDED. 💖 Okay that's a lot of options, but the big takeaway is to pick something with integrity protection! 🫶

5. Setup 🧁

To start, the operator uses the protected channel to install the appropriate RPKI Trust Anchor's Certificate (TA Certificate) in the router. 🔑 This will later let the router validate the router certificate returned in the PKCS#7 certs-only message [RFC8551]. ✅

The operator configures the Autonomous System (AS) number to be used in the generated router certificate. 🌐 This may be the sole AS configured on the router, or an operator choice if the router is configured with multiple ASes. A router with multiple ASes can generate multiple router certificates by following the process described in this document for each desired certificate. 🎀 This configured AS number is also used during verification of keys, if generated by the operator (see Section 6.2), as well as during certificate verification steps (see Sections 7, 8, and 9). 🔍

The operator configures or extracts from the router the BGP Identifier [RFC6286] to be used in the generated router certificate. 🪪 If the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used. 🌸

The operator configures the router's access control mechanism to make sure only authorized users can later access the router's configuration. 🚪🔐

6. Generate PKCS#10 🦋

The private key, and therefore the PKCS#10 certification request (sometimes called a Certificate Signing Request (CSR)), may be generated by the router or by the operator. 🔑

Keeping the CSR lets you verify that the returned public key in the certificate matches the private key used to sign the CSR. 🧐

NOTE: The PKCS#10 certification request does not include the AS number or the BGP Identifier for the router certificate. Therefore, the operator transmits the AS it has chosen on the router, as well as the BGP Identifier, when it sends the CSR to the CA. 📝 Don't forget this part, bestie! 🙈

Part 1 of 5 is done! 🎉 Next up: Section 6.1 onward, including Router-Driven Keys and Operator-Driven Keys. 💜 Stay tuned, bestie! 🫶

6.1. Router-Driven Keys 🎀

okay so in the router-driven method, once the protected channel is set up and the initial setup (Section 5) is done, the operator tells the router to generate the public-private key pair, make the PKCS#10 certification request, and sign that request with the private key. 💅 Once the router has made the PKCS#10 certification request, it sends it back to the operator over the protected channel. 🦋

The operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA. 🌸

Even if the operator can't extract the private key from the router, this signature still links a private key to a router. ✨ So the operator can verify the proof of possession (POP), as required by [RFC6484]. 🔐

NOTE: the CA needs to know that the router-driven CSR is authorized. 🙈 The easiest way to do that is for the operator to mediate the communication with the CA. Other workflows are possible, e.g., where the router sends the CSR to the CA but the operator logs in to the CA on their own and sees a list of pending requests to approve. See Section 9 for an additional workflow. 🧚

If a router were to talk directly to a CA to get the CA to certify the PKCS#10 certification request, the CA would have no way to authenticate the router. 😭 Since the operator knows the router is authentic, the operator mediates the communication with the CA. 👑

6.2. Operator-Driven Keys 🍓

In the operator-driven method, the operator generates the public-private key pair on a management station and installs the private key into the router over the protected channel. 🌈 Beware: experience has shown that copy-and-paste from a management station to a router can be unreliable for long texts. 💀

The operator then creates and signs the PKCS#10 certification request with the private key. The operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA. 🫶

6.2.1. Using PKCS#8 to Transfer Private Keys 🔑

A private key can be wrapped in a PKCS#8 Asymmetric Key Package [RFC5958] and SHOULD be further encapsulated in Cryptographic Message Syntax (CMS) SignedData [RFC5652], signed with the operator's End Entity (EE) private key. ✨

The router SHOULD verify the signature of the encapsulated PKCS#8 to make sure the returned private key really did come from the operator. 🕵️ That does require the operator to also provision, via the CLI, or include in the SignedData, the RPKI CA certificate and the relevant operators' EE certificate(s). The router SHOULD inform the operator whether or not the signature validates to a trust anchor. This notification mechanism is out of scope. 🌸

7. Send PKCS#10 and Receive PKCS#7 💌

The operator uses RPKI management tools to talk to the Global RPKI system, so the appropriate CA can validate the PKCS#10 certification request, sign the key in the PKCS#10 (i.e., certify it), generate a PKCS#7 certs-only message, and publish the certificate in the Global RPKI. 🌐 External network connectivity may be needed if the certificate is going to be published in the Global RPKI. 🦋

After the CA certifies the key, it does two things:

  1. It publishes the certificate in the Global RPKI. The CA must have connectivity to the relevant publication point, which, in turn, must have external network connectivity since it's part of the Global RPKI. ✨
  2. It returns the certificate to the operator's management station, packaged in a PKCS#7 certs-only message, using the same method the certificate request came in on. It SHOULD include the certificate chain below the TA Certificate so the router can validate the router certificate. 🎀

In the operator-driven method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key the operator holds matches the returned public key in the PKCS#7 certs-only message. 🔍 If the operator saved the PKCS#10, they can check this by comparing the public key in the CSR to the public key in the returned certificate. If the operator didn't save the PKCS#10, they can check by regenerating the public key from the private key and then verifying that the regenerated public key matches the public key returned in the certificate. 🧠

In the operator-driven method, the operator has already installed the private key in the router (see Section 6.2). 🔐

8. Install Certificate 🏆

The operator provisions the PKCS#7 certs-only message into the router over the protected channel. 📦

The router SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key corresponds to the stored private key. 🗝️ If the router stored the PKCS#10, it can check this by comparing the public key in the CSR to the public key in the returned certificate. If the router did not store the PKCS#10, it can check by generating a signature on any data and then verifying that signature using the returned certificate. The router SHOULD inform the operator whether it successfully received the certificate and whether or not the keys correspond. The mechanism for that is out of scope. 📣

The router SHOULD also verify that the returned certificate validates back to the installed TA Certificate, i.e., the entire chain from the installed TA Certificate through subordinate CAs to the BGPsec certificate validates. 🔗 To do this verification, the CA certificate chain needs to come back along with the router's certificate in the PKCS#7 certs-only message. The router SHOULD inform the operator whether or not the signature validates to a trust anchor. This notification mechanism is out of scope. 🙌

NOTE: the signature on the PKCS#8 and the Certificate don't need to be made by the same entity. ✨ Signing the PKCS#8 allows more advanced configurations, where the entity that generates the keys is not the direct CA. 🧚

9. Advanced Deployment Scenarios 🚀

More PKI-capable routers can unlock extra functionality and lighten the operator's burden. 🫧 Typically, these routers come with either preinstalled manufacturer-driven certificates (e.g., IEEE 802.1 AR [IEEE802-1AR]) or preinstalled manufacturer-driven Pre-Shared Keys (PSKs), plus PKI-enrollment functionality and a transport protocol, e.g., CMC's "Secure Transport" [RFC7030] or the original CMC transport protocols [RFC5273]. 🔐 When the operator first sets up a protected channel between the management system and the router, this preinstalled key material is used to authenticate the router. 🤝

The operator's burden shifts to include:

  1. Securely communicating the router's authentication material to the CA before the operator starts the router's CSR. 🕊️ CAs use authentication material to decide whether the router is eligible to get a certificate. At a minimum, the authentication material includes the router's AS number and BGP Identifier as well as the router's key material, but it can include additional info too. The material can be communicated to the CA (i.e., CSRs signed by this key material are issued certificates with this AS and BGP Identifier) or to the router (i.e., the operator uses the vendor-supplied management interface to include the AS number and BGP Identifier in the router-driven CSR). The CA stores this authentication material in an account entry for the router so it can be compared against the CSR later, before the CA issues a certificate to the router. 📇
  2. Enabling the router to talk to the CA. The router-to-CA communications are operator-initiated, but the operator's management interface doesn't need to be in the communications path. 🛣️ Enabling router-to-CA connectivity may require connections to external networks (i.e., through firewalls, NATs, etc.). 🧱
  3. Making sure there's a cryptographic chain of custody from the manufacturer. For the preinstalled key material, the operator needs guarantees that either no one has accessed the private key, or an authenticated log of everyone who has accessed it MUST be provided to the operator. 🕵️‍♀️ This is the one non-negotiable here. 😤

Once everything is configured, the operator can start enrolling the router. 🎉 Because the router is talking directly to the CA, the operator doesn't need to retrieve the PKCS#10 certification request from the router as in Section 6, or send the PKCS#7 certs-only message back to the router as in Section 7. Note that the checks the router performs in Section 8 (namely, extracting the certificate from the PKCS#7 certs-only message, verifying that the public key corresponds to the private key, and verifying that the returned certificate validates back to an installed trust anchor) SHOULD be performed. 💯 Likewise, the router SHOULD notify the operator if any of these fail, but this notification mechanism is out of scope. 📬

When a router is set up this way, the communication with the CA SHOULD be automatically re-established by the router at future times to renew the certificate automatically when necessary (see Section 10). 🔄 That takes even more tasks off the operator's plate. 🥰

10. Key Management 🗝️

Key management doesn't just cover key generation, key provisioning, certificate issuance, and certificate distribution. 💫 It also covers assurance of key validity, key rollover, and key preservation during router replacement. 🔁 All of these responsibilities stick around for as long as the operator wants to run the BGPsec-speaking router. 👀

10.1. Key Validity ⏰

It is critical that a BGPsec-speaking router is signing with a valid private key at all times. 😱 To make that happen, the operator needs to make sure the router always has an unexpired certificate. In other words, the key used to sign BGPsec announcements always has an associated certificate whose expiry time is after the current time. 💖

Making sure of this isn't terribly difficult, but it does require that either:

  1. The router has a mechanism to notify the operator that the certificate is about to expire, and/or
  2. The operator notes the expiry time of the certificate and uses a calendaring program to remind them of it, and/or
  3. The RPKI CA warns the operator of pending expiration, and/or
  4. The operator uses some other kind of automated process to search for and track the expiry times of router certificates. 🤖

It is advisable that expiration warnings happen well before the actual expiry time. ⏳

No matter what technique is used to track router certificate expiry times, additional operators in the same organization should be notified as the expiry time approaches. 📣 That way, one forgetful operator doesn't end up affecting the entire organization. 🫠

Depending on inter-operator relationships, it may be helpful to notify a peer operator that one or more of their certificates are about to expire. 🤝 Looking out for each other is the whole vibe. 🌷

10.2. Key Rollover 🔄

Okay so routers that can hold more than one private key are a total game changer for staying online with BGPsec 💖 The new private key and certificate can be obtained and handed out before the operational key expires, so the router can switch over without a hiccup. The router still needs to know when to start using the new key, though. Once it's using that key, having the certificate already distributed is what keeps everything running smoothly ✨

If you want the full step-by-step on doing a key rollover, check out [RFC8634] 🦋

10.3. Key Revocation 💀

Sometimes a router's BGPsec certificate has to be revoked, and no, it's not a vibe 😭 When that happens, the operator has to go through the RPKI CA system to revoke the certificate by putting the router's BGPsec certificate on the Certificate Revocation List (CRL), and also re-keying the router's certificate.

Here's the rough flow for revoking an active router key: first you request the revocation from the CA, then the CA actually revokes the router's certificate, then the re-keying or renewing of the router's certificate happens (possibly with a new key and certificate getting sent to the router), and finally the status gets distributed. While all of this is going on, the operator has to figure out how to keep things running. They can either keep going with the compromised private key or without it, or they can just take the router offline to deal with the compromise 🙈

Honestly, keeping the router up and BGPsec-speaking is the dream 🌈 But if the operational practices don't allow that, then reconfiguring the router to turn off BGPsec is likely the preferred move instead of taking the whole thing offline.

Routers that hold more than one private key, where one is operational and the other(s) are soon-to-be-operational, make revocation events so much easier 👑 The operator can set the router to make a soon-to-be-operational key the operational one, request revocation of the compromised key, and then set up a next generation soon-to-be-operational key. Hopefully all of this can happen without taking the router offline or rebooting it ✨

For routers that only support one operational key, the operators should create or install the new private key first, and then request revocation of the certificate that matches the compromised private key 🫶

10.4. Router Replacement 🧚

At the time of writing, routers often generate private keys for things like Secure Shell (SSH), and those private keys may not be seen or exported from the router. That's super good for security, but it's a headache when a routing engine or a whole router has to be swapped out in the field, because all the software that talks to the router has to be updated with the new keys. Also, any network-based first contact with a new routing engine means you have to trust the public key that shows up on that first contact 😬

So that operators can swap routers quickly without having to update and distribute the matching public keys in the RPKI, routers SHOULD allow the private BGPsec key to be inserted through a protected channel, e.g., SSH, NETCONF (see [RFC6470]), and SNMP 🎀

This lets the operator escrow the old private key using the mechanism for operator-driven keys (see Section 6.2), so it can be put back into a replacement router 🔐 The router MAY allow the private key to be exported through the protected channel after key generation. If it does, this SHOULD be paired with functionality that sets the newly generated key into a permanent non-exportable state, so nobody can export it later through unauthorized operations 🚫

11. Security Considerations 🛡️

The router's manual will describe which of the key-generation options discussed in the earlier sections of this document a router supports, or whether it supports both. The manual will also cover other important security-related info (e.g., how to SSH to the router). Once you're familiar with what the router can do, an operator is encouraged to make sure the router is patched with the latest software updates from the manufacturer 💅

This document defines no protocols, so in a way it introduces no new security considerations. BUT it relies on a whole bunch of other protocols, and the security considerations in those referenced documents should be consulted. Notably, the documents listed in Section 1 should be consulted first 📚 PKI-relying protocols (BGPsec is one of them) have so many issues to think about that entire books have been written about them, so listing all the PKI-related security considerations here wouldn't be useful or helpful 💀 Still, there are some bootstrapping-related issues that are worth repeating, and here they are:

  • Public-private key pair generation: Mistakes here are, for all practical purposes, catastrophic, because PKIs rely on the pairing of a difficult-to-generate public-private key pair with a signer. All key pairs MUST be generated from a good source of non-deterministic random input [RFC4086] 🎲
  • Private key protection at rest: Mistakes here are, for all practical purposes, catastrophic, because disclosure of the private key allows another entity to masquerade as (i.e., impersonate) the signer. All private keys MUST be protected when at rest in a secure fashion. Obviously, how each router protects private keys is implementation specific. Likewise, the local storage format for the private key is just that: a local matter 🔒
  • Private key protection in transit: Mistakes here are, for all practical purposes, catastrophic, because disclosure of the private key allows another entity to masquerade as (i.e., impersonate) the signer. Therefore, transport security is strongly RECOMMENDED. The level of security provided by the transport layer's security mechanism SHOULD be at least as good as the strength of the BGPsec key. There's zero point in spending time and energy generating an excellent public-private key pair and then sending the private key in the clear or with a known-to-be-broken algorithm, because that just undermines trust that the private key has been kept private 😤 Additionally, operators SHOULD ensure the transport security mechanism is up to date, so that all known implementation bugs are addressed 🔥

Even though the CA's certificate is installed on the router and used to verify that the returned certificate really is signed by the CA, the revocation status of the CA's certificate is rarely checked. That's because the router may not have global connectivity or CRL-aware software 🙃 The operator MUST ensure that the installed CA certificate is valid ✨

12. IANA Considerations 🌸

This document has no IANA actions.

13. References 📖

13.1. Normative References

13.2. Informative References 📚💖

Here's the full informative reading list, bestie. Bookmark it 🔖

   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure Operational Protocols: FTP and HTTP",
              RFC 2585, DOI 10.17487/RFC2585, May 1999,
              <https://www.rfc-editor.org/info/rfc2585>.

   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
              RFC 3766, DOI 10.17487/RFC3766, April 2004,
              <https://www.rfc-editor.org/info/rfc3766>.

   [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC): Transport Protocols", RFC 5273,
              DOI 10.17487/RFC5273, June 2008,
              <https://www.rfc-editor.org/info/rfc5273>.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
              <https://www.rfc-editor.org/info/rfc5480>.

   [RFC5647]  Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
              Secure Shell Transport Layer Protocol", RFC 5647,
              DOI 10.17487/RFC5647, August 2009,
              <https://www.rfc-editor.org/info/rfc5647>.

   [RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
              Integration in the Secure Shell Transport Layer",
              RFC 5656, DOI 10.17487/RFC5656, December 2009,
              <https://www.rfc-editor.org/info/rfc5656>.

   [RFC5967]  Turner, S., "The application/pkcs10 Media Type", RFC 5967,
              DOI 10.17487/RFC5967, August 2010,
              <https://www.rfc-editor.org/info/rfc5967>.

   [RFC6187]  Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
              Shell Authentication", RFC 6187, DOI 10.17487/RFC6187,
              March 2011, <https://www.rfc-editor.org/info/rfc6187>.

   [RFC6470]  Bierman, A., "Network Configuration Protocol (NETCONF)
              Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
              February 2012, <https://www.rfc-editor.org/info/rfc6470>.

   [RFC6484]  Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
              Policy (CP) for the Resource Public Key Infrastructure
              (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February
              2012, <https://www.rfc-editor.org/info/rfc6484>.

   [RFC6668]  Bider, D. and M. Baushke, "SHA-2 Data Integrity
              Verification for the Secure Shell (SSH) Transport Layer
              Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012,
              <https://www.rfc-editor.org/info/rfc6668>.

   [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>.

   [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>.

   [SP800-57]
              National Institute of Standards and Technology (NIST),
              "Recommendation for Key Management - Part 1: General",
              NIST Special Publication 800-57 Revision 4,
              DOI 10.6028/NIST.SP.800-57pt1r4, January 2016,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-57pt1r4.pdf>.

Appendix A. Management/Router Channel Security 🔐✨

Okay, so the protected channel for management and router stuff needs to be just as strong as the BGPsec keys it's guarding, or stronger 💪 For the algorithm in [RFC8608], that means 128 bits. See [RFC5480] and [SP800-57] for info on this strength claim, and [RFC3766] for "how to determine the length of an asymmetric key as a function of a symmetric key strength requirement". 🧠

For encryption, the vibe is: do not use export grade crypto (40-56 bits of security), and do not use Triple-DES (112 bits of security) 🙅‍♀️ The suggested minimum is AES-128, specifically these:

  • aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for encryption,
  • hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] for integrity,
  • ecdsa-sha2-nistp256 [RFC5656] for authentication, and
  • ecdh-sha2-nistp256 [RFC5656] for key exchange.

Some routers support public key certificates and SSH 🔑 The SSH certs are different from the BGPsec certs, so don't mix them up, bestie 😭 The SSH certificates should also give a level of security at least as good as the BGPsec keys. x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for authentication.

Last but not least, the protected channel must provide confidentiality, authentication, and integrity and replay protection. Non-negotiable, periodt 👑🫶

Appendix B. An Introduction to BGPsec Key Management

This appendix is informative. It attempts to explain some of the PKI jargon.

BGPsec speakers send signed BGPsec updates that are verified by other BGPsec speakers. In PKI parlance, the senders are referred to as "signers", and the receivers are referred to as "relying parties". The signers with which we are concerned here are routers signing BGPsec updates. Signers use private keys to sign, and relying parties use the corresponding public keys, in the form of X.509 public key certificates, to verify signatures. The third party involved is the entity that issues the X.509 public key certificate, the Certification Authority (CA). Key management is all about making these key pairs and the certificates, as well as ensuring that the relying parties trust that the certified public keys in fact correspond to the signers' private keys.

The specifics of key management greatly depend on the routers as well as management interfaces provided by the routers' vendor. Because of these differences, it is hard to write a definitive "how to", but this guide is intended to arm operators with enough information to ask the right questions. The other aspect that makes this guide informative is that the steps for the do-it-yourself (DIY) approach involve arcane commands while the GUI-based vendor-assisted management console approach will likely hide all of those commands behind some button clicks. Regardless, the operator will end up with a BGPsec-enabled router. Initially, we focus on the DIY approach and then follow up with some information about the GUI-based approach.

The first step in the DIY approach is to generate a private key. However, in fact, what you do is create a key pair: one part (the private key) is kept very private, and the other part (the public key) is given out to verify whatever is signed. The two methods for how to create the key pair are the subject of this document, but it boils down to either doing it on-router (router-driven) or off-router (operator-driven).

If you are generating keys on the router (router-driven), then you will need to access the router. Again, how you access the router is router-specific, but generally the DIY approach involves using the CLI and accessing the router either directly via the router's craft port or over the network on an administrative interface. If accessing the router over the network, be sure to do it securely (i.e., use SSHv2). Once logged into the router, issue a command or a series of commands that will generate the key pair for the algorithms referenced in the main body of this document; consult your router's documentation for the specific commands. The key-generation process will yield one or more files containing the private key and the public key; the file format varies depending on, among other things, the arcane command the operator issued; however, the files are generally DER- or PEM-encoded.

The second step is to generate the certification request, which is often referred to as a Certificate Signing Request (CSR) or PKCS#10 certification request, and to send it to the CA to be signed. To generate the CSR, the operator issues some more arcane commands while logged into the router; using the private key just generated to sign the certification request with the algorithms referenced in the main body of this document; the CSR is signed to prove to the CA that the router has possession of the private key (i.e., the signature is the proof-of-possession). The output of the command is the CSR file; the file format varies depending on the arcane command you issued, but generally the files are DER- or PEM-encoded.

The third step is to retrieve the signed CSR from the router and send it to the CA. But before sending it, you need to also send the CA the subject name (i.e., "ROUTER-" followed by the AS number) and serial number (i.e., the 32-bit BGP Identifier) for the router. The CA needs this information to issue the certificate. How you get the CSR to the CA is beyond the scope of this document. While you are still connected to the router, install the trust anchor for the root of the PKI. At this point, you no longer need access to the router for BGPsec-related initiation purposes.

The fourth step is for the CA to issue the certificate based on the CSR you sent. The certificate will include the subject name, serial number, public key, and other fields; it will also be signed by the CA. After the CA issues the certificate, the CA returns the certificate and posts the certificate to the RPKI repository. Check that the certificate corresponds to the public key contained in the certificate by verifying the signature on the CSR sent to the CA; this is just a check to make sure that the CA issued a certificate that includes a public key that is the pair of the private key (i.e., the math will work when verifying a signature generated by the private key with the returned certificate).

If generating the keys off-router (operator-driven), then the same steps are used as with on-router key generation (possibly with the same arcane commands as those used in the on-router approach). However, no access to the router is needed, and the first three steps are done on an administrative workstation:

Step 1: Generate key pair. Step 2: Create CSR and sign CSR with private key. Step 3: Send CSR file with the subject name and serial number to CA.

After the CA has returned the certificate and you have checked the certificate, you need to put the private key and trust anchor in the router. Assuming the DIY approach, you will be using the CLI and accessing the router either directly via the router's craft port or over the network on an admin interface; if accessing the router over the network, make doubly sure it is done securely (i.e., use SSHv2) because the private key is being moved over the network. At this point, access to the router is no longer needed for BGPsec-related initiation purposes.

NOTE: Regardless of the approach taken, the first three steps could trivially be collapsed by a vendor-provided script to yield the private key and the signed CSR.

Given a GUI-based vendor-assisted management console, all of these steps will likely be hidden behind pointing and clicking the way through BGPsec-enabling the router.

The scenarios described above require the operator to access each router, which does not scale well to large networks. An alternative would be to create an image, perform the necessary steps to get the private key and trust anchor on the image, and then install the image via a management protocol.

One final word of advice: certificates include a notAfter field that unsurprisingly indicates when relying parties should no longer trust the certificate. To avoid having routers with expired certificates, follow the recommendations in the Certification Policy (CP) [RFC6484] and make sure to renew the certificate at least one week prior to the notAfter date. Set a calendar reminder in order not to forget!

Authors' Addresses

Randy Bush IIJ & Arrcus 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America

Email: randy@psg.com

Sean Turner sn3rd

Email: sean@sn3rd.com

Keyur Patel Arrcus, Inc.

Email: keyur@arrcus.com

📦 where this page comes from