In June 2020 Belnet has, as National Research and Education Network (NREN), decided to take an exemplary role and contribute in helping secure the internet by implementing a mechanism thwarting not only BGP route hijacking, but also badly configured network routes – both which can break the internet.
This mechanism is called Resource Public Key Infrastructure or RPKI – a security framework that helps network operators make more informed and secure routing decisions. Its essence is twofold:
- Organisations or networks can certify they are owners of their routes or prefixes.
- Internet Service Providers (ISPs) are supposed to reject or block illegal routes, i.e. routes which do not have a valid ownership certificate.
In the context of RPKI the internet will only be completely safe when every ISP or network operator implements it. Since begin 2020 there has been an increase in momentum and Belnet wanted to set the example in the Belgian community by being one of the first ISPs to implement RPKI.
RPKI is implemented since October 1st 2020
The basis of RPKI are Route Origin Authorisation (ROA) records. A ROA is a pair of IP prefix and AS number (ASN). This pair is cryptographically signed with the private key of the holder’s X.509 certificate (RFC 3779). The holder’s certificate is signed by a Certificate Authority (CA).
Belnet already holds since many years ROA records for its IPv4 and IPv6 prefixes, but until now we have not used the ROAs created by other organisations (resource holders) to verify the validity of a route’s origin, nor have we been rejecting any invalid prefix.
There are two RPKI models: hosted RPKI and delegated RPKI.
- Hosted RPKI is an infrastructure in which the Regional Internet Registry (RIR) hosts a CA and signs all ROAs for its resources. In this case the private key for generating the ROAs is hosted by the RIR.
- With delegated RPKI direct resource holders are allowed to host their own CA and sign ROAs themselves. Resources are then linked to the RIR’s RPKI repository.
At Belnet we chose to implement hosted RPKI
At the top of the certificate hierarchy there are five RIRs which act as Trust Anchors, who hold each for their region a self-signed root certificate.
All certificates, public keys and ROAs are publicly available in repositories. The routers themselves however don’t interact directly with these repositories. As routers are not really fit to perform these intensive cryptographic operations, these tasks are offloaded to local RPKI cache servers running a validator. These cache servers download the repositories, validate the ROAs and then feed the processed data to the routers over a light-weight protocol called the RPKI-RTR protocol (RFC 8210).
Routers connect with these RPKI cache servers in the form of a TCP session (port 8282) over which the RPKI-RTR protocol is run. Through this protocol route validation (RV) records are exported from the cache server to the router. These RV records are simple records free of any cryptographic information. This way the router can maintain a local route validation database containing RV records. The configuration of RPKI-RTR sessions only needs to be done on the route-validating routers.
For redundancy reasons Belnet implemented two local RPKI cache servers, each running different software.
At Belnet we are now dropping (reject) routes marked as invalid
Routes can have one of following validation states:
- Valid: Indicates that the prefix and AS pair are found cryptographically signed in the database
- Invalid: Indicates that the prefix is found, but either the corresponding AS received from the eBGP peer is not the AS that appears in the database, or the prefix length in the BGP update message is longer than the maximum length permitted in the database.
- Unknown: Indicates that the prefix is not among the prefixes or prefix ranges in the database.
Would you like to receive a document with more technical information?