RPKI secures BGP internet routing system

IP address blocks and autonomous systems

In order to understand how RPKI protects the BGP infrastructure, it's first necessary to understand how internet routing and the BGP protocol work. That begins with IANA, one of whose tasks is managing all IP addresses (both IPv4 addresses and IPv6 addresses). Blocks of addresses are assigned to the 5 Regional Internet Registries (RIRs), which in turn assign sub-blocks to their Local Internet Registries (LIRs). Our RIR is RIPE NCC, which covers Greater Europe and West Asia. LIRs are organisations such as internet access providers, major corporations and other large organisations.

To get its 'own' address block, an organisation has to be a member of an RIR. As an RIR member, the organisation is designated an LIR and can apply to the RIR for an autonomous system number (ASN). Scope also exists for smaller organisations to obtain ASNs from their LIRs. An officially numbered autonomous system (AS) is effectively a technically and administratively independent component of the internet. The address blocks held by an AS operator are linked to the operator's ASN by the RIR/LIR. Like IP addresses, ASNs are globally unique; they are also managed and assigned in much the same way as IP addresses.

BGP

The next component in the system is the Border Gateway Protocol (BGP), defined in RFC 4271. An organisation uses the protocol to tell its upstream (transit) providers and peers which IP addresses it owns, so that they can correctly deliver traffic bound for the organisation in question (or for other, subordinate networks). In technical terms: routers within an AS and connected routers in other ASs (border gateways) use BGP to exchange routes with one another. In this context, a route is an accessible address block (destination prefix) plus the path for reaching it (a list of interconnected ASNs, compiled progressively during the propagation of route information).

Inbound route information is first combined with pre-existing information and information about local routes, and then optimised where possible. Optimisation involves combining ('aggregating') prefixes that have the same starting elements (implying the same initial routing of network packets) to create a shorter prefix ('supernet'). Optimising route information prevents routing tables becoming unworkably large.

Each route is also provided with a 'distance': the administrative distances (network topological distances, e.g. the number of hops) and network metrics (e.g. bandwidth, reliability and cost) are combined into a definition of mutual priorities and preferences ('best path selection').

Finally, the router adds its own ASN as the first step on each path, so that the routes are suitable for sharing with other routers (propagation).

The end result is that, within a few minutes, the whole internet knows which subsequent hop offers the fastest and most reliable route for a network packet to take to its ultimate destination. In the default-free zone (the core of the internet where there are no default routes), a total of more than a million routes are defined.

At the operator level, BGP is considerably more complex and extensive than described above, but that summary should suffice in this context.

Attacks

The simplest form of attack on the system described above is route hijacking: taking control of someone else's route (i.e. their IP addresses). All that an attacker has to do is to use BGP to advertise a route with a higher techno-economical score for the relevant prefix. Often, that can be done by announcing a route with a longer (more specific) prefix. A malicious actor can therefore divert traffic intended for someone else to themselves, or abuse an address block for sending spam or mounting DoS attacks.

In 2014, for example, there was a high-profile incident in the Netherlands, when a then inactive address block belonging to the Ministry of Foreign Affairs was hijacked by Bulgarian criminals [1, 2]. Other notable attacks have targeted Amazon in 2018 (which is why Cloudflare advocates RPKI so strongly) and YouTube in 2008.

Accidental issues

Problems more commonly arise, however, when incorrect route information is announced accidentally, or when correct information is accidentally propagated more widely than intended (a 'route leak', discussed in detail in RFC 7908). An error or leak can lead to an entire network becoming unreachable.

In 2004, large parts of the internet were unreachable for many users for several hours, after Turkish access provider TTNET leaked its entire routing table to all its transit providers. Also, when the IP address of the L root name server was changed in 2007-2008, various unauthorised root servers were set up during the six-month transition period. Another case involved Google and Spotify in 2015.

RFC 4272 provides a detailed overview of BGP's vulnerabilities. Their implications for DNS in particular are considered in an ICANN-SSAC report.

Filtering

Attacks and accidents of the type described are possible because BGP was originally designed to be open for all route updates advertised by transit providers and peers. Although network operators keep a record of the routes that their partners and customers are allowed to advertise, it seems that there is no strict filtering on the basis of such agreements in practice.

Filtering on the basis of sender address is recommended in BCP38 (RFC 2827, ingress filtering to prevent address spoofing), BCP 84 (RFC 3704 and 8704, the reverse path forwarding (RPF) extension for multihoming) and BCP 194 (RFC 7454, operational security).

RPKI

RPKI takes the protection of internet routing one step further. The basic principle of this cryptographic security methodology (defined in RFC 6480) is essentially similar to that underpinning DNSSEC. With RPKI, the operator of an IP address or ASN attaches a digital signature to their route information, whose authenticity is validated by users (i.e. other routers) by referring to a certificate chain (chain of trust).

That system means that routers refuse any false route information that has been injected into the BGP system, making it much harder for malicious actors to hijack IP addresses or redirect internet traffic. At least equally importantly, it also prevents the propagation of innocent errors made by network operators, which could otherwise result in the disconnection of important components and services. The reason being that an operator cannot attach a valid signature to route information that they don't have authority to share.

It should be noted, however, that RPKI secures only the link between an ASN and a prefix (route origin validation, ROV). It is not yet possible to secure path information (path validation).

Route origin validation

An RPKI chain of trust begins with one of the five RIRs, each of which has its own trust anchor (the starting point for a chain of trust). An LIR obtains a digitally signed owner's certificate from their RIR, specific to the LIR's ASNs and prefixes. Using that certificate, the LIR can sign route information for those ASNs and prefixes.

ROV, which is defined in RFC 6811, makes use of a Route Origination Authorization (ROA) stating which ASNs are authorised to announce a particular route (permitted origins). Furthermore, a prefix owner can publish an ROA for other ASNs authorising other parties to announce routes for its prefixes. Conversely, if you have published an ROA, neither you nor anyone else can accidentally or deliberately announce routes for your prefixes on an unauthorised ASN.

Delegated or hosted RPKI

Where the ROAs are published depends on the owner-side configuration. RPKI is in principle a distributed system, implying that you can generate and publish your own certificates and ROAs. You then get the relevant RIR to point to your own infrastructure, thus extending the certificate chain to your systems (delegated RPKI).

However, all 5 RIRs will also publish ROAs for their LIRs (hosted RPKI). So, for example, a smaller LIR that uses only one RIR doesn't have to operate their own CA server.

Validation

The validation of route information by users ('relying parties') also begins with the RIRs. References to their self-signed root certificates are usually hard-coded into RPKI validator software in the form of trust anchor locators (TALs).

When a validator is launched, it retrieves all the certificates and ROAs (now usually using the RRDP protocol, defined in RFC 8182, although support for rsync remains mandatory). Where hosted RPKI is used, the validator can obtain validation directly from the RIRs. Where delegated RPKI is used, the validator follows the distributed chain of trust for the certificates down to the repository containing the ROAs and associated certificates.

RTR servers

All the certificates and ROAs are validated and collected in a cache (the VRP cache), after which updates are periodically retrieved and processed (e.g. on an hourly basis). The cache is then used to validate inbound route announcements. When forwarding, authenticated routes are preferred to routes for which no RPKI information is (yet) available. Announcements that prove to be bogus are simply dropped.

If in the future RPKI is ever adopted universally, the intention is that unsigned announcements will not be accepted either. However, it remains to be seen whether that will ever happen; Fastly suggests that the secure routing development and adoption phase may last decades.

Finally, a network operator can combine global RPKI information with their own (local) policies and exceptions. That involves use of the SLURM specification language (defined in RFC 8416).

The end result is then available to routers, which can retrieve route information from the RPKI validator using the RPKI-to-Router protocol (RTR, defined in RFC 8210). In the interest of resilience, a router should preferably be connected to multiple RTR servers.

The Internet Routing Registry

RPKI's ROV functionality is the replacement for the Internet Routing Registry (IRR). The IRR began with the publication of RADb [1], a central database of authoritative routing policies (specified in RPSL). It subsequently developed into a network of tens of similar registries, of which 2 dozen remain.

Users can query the databases using the Whois protocol, now superseded by RDAP – the same protocols that RIRs support for querying 'internet number' databases.

Although routers can use the IRR for filtering and for verifying the authenticity of route information, the network has no formal status, and the information is nowadays maintained less diligently than in the past. The RPSL specification language is suitable for defining extensive policies, but IRR is now used only for the publication of information about the owners.

Path validation

As indicated above, only the ROV functionality – the authenticated linking of authorised ASNs to prefixes – is currently implemented in RPKI. That functionality is now supported by all 5 RIRs, by all open-source router software and by all routers.

The next step is to enable path validation: the securing of BGP route updates, including paths compiled in stages along the way. An initial implementation has already been standardised in the form of BGPsec, in RFC 8205 to 8209, inclusive.

BGPsec

BGPsec is an extension to the BGP protocol, which provides for secure paths. It involves the addition of a new digital signature for each new node (ASN) added to a path. The new signature covers both the new ASN and the path leading to it, with its previously attached signatures. The receiving party's ASN is covered by the signature as well.

The system enables validators to verify that a BGP update message is intended for them, and that the compiled path from the origin is authentic. The ROV functionality described above is used to confirm that the origin itself is authorised to announce the route in question, thus completing the chain.

However, the implementation of secure paths as described places considerable strain on resolver resources, because of the need to verify a recursive cascade of digital signatures in order to validate a compiled path in its entirety. Moreover, BGPsec works only if supported by all the nodes along the route; if any node does not support the protocol, it's necessary to fall back on the original AS path system.

ASPA

Autonomous System Provider Authorization (ASPA), whose specification is currently still in progress [1, 2], applies the concepts of authenticated origins to the propagation of routes. An ASPA record states which ASNs are permitted to propagate route announcements for a given ASN in the same way that an ROA record states the ASNs that are authorised to announce a given route. The idea is to enable organisations to specify who their upstream providers and peers are (amounting to a statement of commercial relationships and the associated AS topology), and to publish that information globally in authenticated form via the RPKI infrastructure.

The ASPAs are published and distributed in the same way as the ROAs, enabling a validator to validate each individual link in the path directly from its validated ASPA cache. However, the methodology does not provide assurance regarding the path that will actually be followed, since that is compiled in transit. Validation confirms merely that the stated path is consistent with the AS topology. It this context, therefore, the phrase 'path plausibility' is used, not 'path validation'.

In addition to its simplicity and efficiency, ASPA has another important advantage over BGPsec: all the individual links for which ASPA records are published can be checked separately, enabling ASPA users to immediately improve the security and error-resilience of their BGP infrastructures.

Although ASPA has sometimes been presented as a more generic and efficient alternative to BGPsec [1, 2, 3, 4], the ASPA specification's co-author Job Snijders has stressed that ASPA is a standalone technology with its own security function, which can operate alongside BGPsec. Origin validation and path validation may secure the published and propagated route, but they do not protect against errors made by legitimate actors. ASPA's main function is therefore the prevention of route leaks.

Furthermore, Snijders (and his employer Fastly) assume that it is only a matter of time before router hardware has sufficient onboard resources for full BGPsec support [1]. He therefore believes that, in the future, both BGPsec and ASPA should be available to network operators, with the RIRs supporting both technologies.

RPKI as a generic security platform

Strictly speaking, ROV, BGPsec and ASPA are not elements of RPKI, but technologies that use RPKI as their foundation (as, for example, DANE uses DNSSEC). Similarly, RPKI provides a Public Key Infrastructure (PKI) for the owners of internet numbers, but one that is entirely separate from the BGP infrastructure itself (out-of-band). RPKI's distributed hierarchy of X.509 certificates forms a generic security platform on which applications such as ROV, BGPsec and ASPA can be built.

Although ROV and BGPsec may be complementary, each can in principle be used independently of the other. We currently use mainly RPKI with ROV, with the assumption that path validation will be added in due course. At a later stage, ASPA could be introduced alongside the other technologies. Another RPKI application, whose publication in RFC form is imminent, is RSC (RPKI Signed Checklists).

The value of RPKI plus ROV

Although path validation is not currently in use, it does not follow that RPKI plus ROV has no value. On the contrary: the transit networks at the core of the internet exchange so much traffic that a huge number of peering agreements are in effect, under which the networks in question are effectively immediate neighbours. As a result, it is very difficult for an external party to inject a higher-scoring route.

Consequently, ROV's main value is currently preventive: it protects against errors with potentially serious consequences made by network operators when specifying ASNs and prefixes.

The BGP Streamwebsite shows that there are a total of between 5 and 25 such incidents a day. On the basis of the aggregator's data, the OECD reports that there were more than 3000 incidents in 2021, but that the trend is strongly downward.

Figure 1: Screenshot of CISCO's BGP Stream-website.

Figure 2: Reporting on BGP leaks and possible hijackings (Source: OECD).

Open-source software

NLnet Labs has now developed 3 open-source RPKI packages, all written in the Rust programming language:

• Routinator: an RPKI client consisting of a validator and an RTR server

• RTRTR: an RTR proxy that enables the formation of an extra layer (cascade) of caching RTR servers for a large distributed network infrastructure

• Krill: an RPKI CA server for the independent creation of a Delegated RPKI system

More than a dozen packages created by other developers are also available, including:

• OctoRPKI: an RPKI validator/library (Cloudflare's RPKI Toolbox)

• StayRTR: an RTR server; a fork of GoRTR (Cloudflare, no longer maintained)

• rpki-client: an RPKI validator (OpenBSD, portable client)

• FORT Validator: an RPKI validator and RTR server (NIC.mx, as part of the FORT project)

• BGPalerter: a BGP/RPKI monitoring tool

Maarten Aertsen of NLnet Labs authored the RPKI extension for Internet.nl's test portal when he was working for the National Cyber Security Centre (NCSC). "The development of Routinator and many of the other RPKI tools dates back to the period when RPKI was itself still being developed," he recalls. "At that time, only experimental software was available, written by the people who were working on the standard and by the RIRs that were busy setting up their infrastructures. Our aim was to contribute to a diverse ecosystem of stable RPKI implementations. Krill is now actually the only open-source CA server that is being actively maintained. So we're plugging a gap, in line with our mission."

Adoption

According to our own statistics, nearly half of .nl domains are now using authoritative name servers running on networks secured with RPKI plus ROV. Taking into account partially secured domains (i.e. domains with some but not all name servers running on secure networks), overall adoption works out at roughly three quarters of the .nl domain. Adoption on web servers is broadly similar.

Figure 3: The number of .nl domain names secured with RPKI (Source: stats.sidnlabs.nl).

Figure 4: The number of .nl websites secured with RPKI (Source: stats.sidnlabs.nl).

We do not currently have plans to incentivise RPKI adoption, but the introduction of a financial incentive is something we will be discussing with the Registrars' Association (RA).

Naturally, our own infrastructure is protected by RPKI.

Dutch government organisations

Although RPKI has been on the Forum for Standardisation's 'use-or-explain' list (ptolu) since late 2019, no government-wide Joint Ambition Statement has been agreed defining an implementation target date, as was the case with DNSSEC, SPF/DKIM/DMARC, DANE and IPv6. "RPKI has been on the list for a while, and was previously promoted by the NCSC," says Bart Knubben, the Forum for Standardisation's Coordinating Advisor. "As a result, various government organisations, including Logius, SSC-ICT, DICTU and the Tax Service, have implemented RPKI."

"Now that Internet.nl features an RPKI test, we can make a baseline measurement of adoption in all government domains. Once that has been done, the Forum for Standardisation can decide whether a Joint Ambition Statement on RPKI is needed."

The most recent Open Standards Monitoring Report (November 2021) – the first to address the question of RPKI support by government service infrastructures – stated that the standard was relevant in 95 per cent of cases. Furthermore, 72 per cent of the 19 investigated services were found to have published RPKI ROAs.

More information

For more information about RPKI, see the RPKI documentation. Detailed technical information can be found in the various RFCs cited in the body of this article.

Anyone needing to secure their networks' routing is well advised to start by visiting the MANRS (Mutually Agreed Norms for Routing Security) website [primers]. For an exploration of the policy aspects of internet routing security for government bodies, we recommend the OECD report Routing security; BGP incidents, mitigation techniques and policy actions.

If you'd like to check whether your website or mail service currently supports RPKI, visit the Internet.nl test portal.