BGPSec Router Key Certificates supported in the RPKI API
Dear colleagues, In response to previous requests from community members, the RIPE NCC has implemented support for creating and managing BGPsec Router Key Certificates (RFC 8209) through the RPKI API. Documentation on how to use the API is available at: https://github.com/RIPE-NCC/rpki-core/blob/main/Documentation/BGPSec%20API.m... In a nutshell, BGPsec allows holders of AS numbers to authorise a key for their router which can then be used to sign BGP updates. This allows BGPsec-aware routers to validate that the BGP path is unaltered (on BGPsec-enabled sessions). Please note that BGPsec is complementary to ROAs/ROV and ASPA. BGPsec focuses specifically on preventing spoofing of the path. It does not check the route origins, as ROAs/ROV do, or detect route leaks, as ASPA does. While BGPsec support in (hardware) routers is currently lagging, and there are challenges regarding incremental deployment and performance, we hope that enabling the support for BGPsec Router Key Certificates through RPKI API will help drive its development forward. Kind regards, Tim Bruijnzeels Principal Engineer RPKI RIPE NCC
Congrats to Ben Cartwright-Cox for being the first to use this API to publish a BGPsec router key certificate! :-) https://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/18/0ea2fc-a... ___________ .-"```'. '._==_==_=_.' __ , / ` .-\: /-. ,'\\'\\ | . _ _| | (|:. BGP |) | |` _\ \(\ 6 6 '-|:. Sec |-' /.\==/.\# | _\ | \::. / \_// \_/,) |\ = `/ '::. .' | `- | | '.___.' ) ( \ =' / .'` \ |_ _.' '._ `.__.-\ '-__ / `- `"""""""` | ^ ` Kind regards, Job ps. I'd like to suggest to RIPE NCC (as implementation detail) to use some kind of hash as the filename of the certificate (e.g., hash of the SPKI). The publication BCP recommends to use *SHORT* and unique filenames for each issuance. https://www.ietf.org/archive/id/draft-ietf-sidrops-publication-server-bcp-11... "U7MsWuoesSCyjxNNrLIARIHOD7E-hqQU9YRU78t0_oxvZ8ha0_6qAKY-bgpsec-00033d08-00033d08.cer" currently is the second longest filename in the global RPKI :-) pps. ASCII art from Joan G. Stark, mangled by me.
Hi, To save people from having to jump through hoops to figure out how to use this facility, here is a simple shell script that shows generation and publication of a BGPsec router key using RIPE NCC's API. Kind regards, Job -------------------------------------- #!/bin/sh set -euxo pipefail AS=YOUR_AS_NUMBER APIKEY="44444444-4444-4444-4444-444444444444" API="https://my.ripe.net/api/rpki/bgpsec" cat << EOF > bgpsec.cnf [ req ] distinguished_name = cnname string_mask = nombstr prompt = no [ cnname ] commonName = ROUTER-${AS} EOF openssl ecparam -genkey -name prime256v1 -out r0.key openssl req -new -key r0.key -sha256 -outform DER -out r0.csr -config bgpsec.cnf cat << EOF > data.json { "asn": "AS${AS}", "routerId": 0, "csr": "$(cat r0.csr | openssl base64 | tr -d '\n')" } EOF curl --data @data.json -v -X POST -H "Content-Type: application/json" \ -H "ncc-api-authorization: ${APIKEY}" \ ${API}
Hi, On Thu, Oct 22, 2026 at 09:50:37AM +0200, Tim Bruijnzeels wrote:
Please note that BGPsec is complementary to ROAs/ROV and ASPA. BGPsec focuses specifically on preventing spoofing of the path. It does not check the route origins, as ROAs/ROV do, or detect route leaks, as ASPA does.
My understanding is that BGPsec specifically allows signing of the origin, and crypto *validation* of the origin (= the spoofed-origin attacks against ROA/ROV get addressed by that). So benefit, even if the path might see still spoofery. But that might be a misunderstanding, which is one of the reasons why I asked the WG chairs for some more material on this @ the next WG session :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet GmbH Geschäftsführer: Sebastian v. Bomhard, Joseph-Dollinger-Bogen 14 Maja von Bomhard D-80807 München HRB: 317057 (AG München) Tel.: (089) 32356-0 USt-IdNr.: DE813185279
On Thu, Oct 29, 2026 at 11:11:24PM +0100, Gert Doering wrote:
On Thu, Oct 22, 2026 at 09:50:37AM +0200, Tim Bruijnzeels wrote:
Please note that BGPsec is complementary to ROAs/ROV and ASPA. BGPsec focuses specifically on preventing spoofing of the path. It does not check the route origins, as ROAs/ROV do, or detect route leaks, as ASPA does.
My understanding is that BGPsec specifically allows signing of the origin, and crypto *validation* of the origin (= the spoofed-origin attacks against ROA/ROV get addressed by that). So benefit, even if the path might see still spoofery.
What's cryptographically signed is the AS path: every AS hop along the path appends a signature (chain starts at the origin AS). https://www.rfc-editor.org/info/rfc8205/#section-3 I think what Tim meant to say is that BGPsec doesn't help to verify that a given AS was *authorized to originate a given prefix* (that aspect is addressed by ROAs). However, bgpsec _does_ help to verify that the AS_PATH isn't spoofed, so if one combines ROAs Origin Validation AND BGPsec AS path validation, you'd arrive at something quite robust. I hope this ASCII art helps a bit: +----------------------+ | out-of-band | | 2001:67c:208c::/48 | | | +---------------------------------|---------+ ROA | | AS_PATH in-band | | | | | | | | 1299 __ 8455 __ 51088 ____|_ 15562 | | | \....../\......./\......|../ | | | sig3 sig2 sig1 | | | | BGPsec | | | +---------------------------------|---------+ | | | +----------------------+ The ROA is signed by the prefix holder of 2001:67c:208c::/48. The BGP update from 15562 toward 51088 is signed by the AS holder of AS15562. The BGP update from 51088 toward 8455 is signed by the AS holder of AS51088. The BGP update from 8455 toward 1299 is signed by the AS holder of AS8455. Verifying "sig1" by itself doesn't tell you that 15562 actually is permitted to originate 2001:67c:208c::/48. The signature merely tells us that it really was 15562 that originated that prefix. When all four signatures are verified (the ROA signature inside the RPKI validator, and the bgpsec signatures inside the BGP router), one can establish not only that the AS path was authentic (not spoofed), but also that the right-side AS was authorized to originate the prefix. Kind regards, Job
participants (3)
-
Gert Doering -
Job Snijders -
Tim Bruijnzeels