Router Keying for BGPsec
Extracted elements (26)
An initial leap of faith is required for both methods because the router has no keying material to protect communications before provisioning. A direct physical connection (craft port) is safer than a network connection because it reduces the risk of a man-in-the-middle attack.
The router-driven method mirrors traditional PKI subscriber practices where the private key never leaves trusted storage (e.g., an HSM), providing proof-of-possession to the CA. However, for non-human entities requiring hot-swap continuity, this model does not always work, motivating the operator-driven method.
Two key provisioning methods are defined — router-driven (key generated on-router, private key never leaves trusted storage) and operator-driven (key generated off-router and installed via protected channel). The operator-driven method exists because hot-swapping routers requires the same private key to be installed in a replacement router, minimizing downtime compared to the RPKI propagation delay of a day or longer for a new key.
For advanced deployments, routers may use preinstalled IEEE 802.1AR manufacturer-driven certificates or Pre-Shared Keys combined with PKI-enrollment protocols such as EST (RFC 7030) or CMC transport (RFC 5273) to authenticate directly to the CA, bypassing the operator as intermediary.
SSH certificates used for the management session are distinct from BGPsec router certificates. SSH session certificates should also provide at least 128-bit security equivalent to the BGPsec keys; x509v3-ecdsa-sha2-nistp256 is suggested for SSH authentication.
The protected management channel between the management system and router is assumed to be SSH-protected CLI, though NETCONF may also be used. Encryption, integrity, and key-exchange algorithms used SHOULD be of equal or greater strength (128-bit) than the BGPsec keys they protect; minimum recommended algorithms include AES-128, hmac-sha2-256, ecdsa-sha2-nistp256, and ecdh-sha2-nistp256.
A private key encapsulated in a PKCS#8 Asymmetric Key Package SHOULD be further encapsulated in CMS SignedData and signed with the operator's EE private key.
All key pairs MUST be generated from a good source of non-deterministic random input per RFC 4086. Mistakes in key-pair generation 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 private keys MUST be protected when at rest in a secure fashion. Disclosure of the private key allows another entity to masquerade as the signer.
For advanced deployment scenarios, an authenticated log of those who have accessed the preinstalled private key material MUST be provided to the operator, or the operator must have guarantees that no one has accessed the private key.
For router replacement scenarios, routers SHOULD allow the private BGPsec key to be inserted via a protected channel (e.g., SSH, NETCONF, SNMP). The router MAY allow the private key to be exported after key generation, but this SHOULD be paired with functionality that sets the key into a permanent non-exportable state.
The CA SHOULD include the certificate chain below the TA Certificate in the PKCS#7 certs-only message returned to the operator's management station, so the router can validate the router certificate.
The operator MUST ensure that the installed CA certificate is valid. The revocation status of the CA certificate is rarely checked on the router because the router may not have global connectivity or CRL-aware software.
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, then verify the certificate chain back to the installed TA Certificate.
The router SHOULD verify the signature of the encapsulated PKCS#8 to ensure the returned private key came from the operator. The router SHOULD inform the operator whether the signature validates to a trust anchor.
Transports used to exchange certificates SHOULD also provide integrity protection, even though certificates are themselves integrity-protected.
When a PKI-capable router communicates directly with a CA, the communication SHOULD be automatically re-established by the router at future times to renew the certificate automatically when necessary.
Certificate exchange between operator management stations, routers, and the RPKI uses PKCS#7 certs-only messages (RFC 8551). Three transport options are enumerated: application/pkcs10 + pkcs7-mime media types, FTP/HTTP per RFC 2585, or EST per RFC 7030.
Private keys are transferred to routers using PKCS#8 Asymmetric Key Package (RFC 5958), optionally wrapped in CMS SignedData (RFC 5652) and signed by the operator's EE private key to provide provenance.
The operator configures the router with an AS number and BGP Identifier (RFC 6286) to be used in the generated router certificate. In cases where unique per-router certificates are not used, a BGP Identifier of 0 MAY be used.
The PKCS#10 certification request (CSR) is the primary artifact exchanged between the router/operator and the CA. It does not include the AS number or BGP Identifier; these must be transmitted separately by the operator when sending the CSR to the CA.
The router certificate's subject name is 'ROUTER-' followed by the AS number, and the serial number is the 32-bit BGP Identifier. These fields are not contained in the PKCS#10 and must be communicated by the operator to the CA separately.
Key revocation requires placing the BGPsec certificate on the CA's CRL, re-keying the router's certificate, and deciding whether to keep the router operational with the compromised key or bring it offline. Routers supporting multiple simultaneous private keys facilitate revocation by allowing a spare key to become operational before the compromised key is revoked.
Operators must track certificate expiry times and renew certificates at least one week before the notAfter date. Multiple operators should be notified as expiry approaches to prevent a single operator's forgetfulness from affecting the organization's BGPsec operation.
Transport security for private keys is strongly RECOMMENDED, with transport security strength SHOULD be at least as good as the BGPsec key strength. Transmitting a private key in the clear or with a known-broken algorithm undermines the entire PKI trust model and enables impersonation of the BGPsec signer.
Key provisioning workflow: (1) establish protected channel and install TA certificate, (2) generate key pair via router-driven or operator-driven method producing a PKCS#10 CSR, (3) operator sends CSR with AS number and BGP Identifier to CA, (4) CA certifies and publishes to RPKI and returns PKCS#7, (5) operator installs PKCS#7 into router over protected channel.