Resource Public Key Infrastructure (RPKI)
Introduction
The operational staff of every Internet Service Provider must have a good idea of the security challenges facing the internet and how the limitations of BGP play a role in this. To make this simple let us focus on the following questions:
- What are the limitations of BGP4?
Unfortunately, when BGP was developed no one had a foresight as to what the security problems BGP4 was would pose for Internet Infrastructure. BGP as a routing protocol was never designed keeping routing security in mind. Some of the problems of BGP4 will become evident as we discuss further in this section.
- How does one make sure that the route advertised by a customer or an upstream is a valid route or an invalid route?
Understanding what is a valid route/prefix and what is an invalid route is important.
Valid Routes:
- Routes that confirms to the allocations policies of the Regional Internet Registries
- The route is not from a private address block that is not routable on the Internet.
- The route is not from an address space that is still not allocated by any of the Regional Internet Registries.
- Routes that confirm to the peering agreements such as peer to peer and peer to customer.
Unfortunately, BGP4 has no mechanisms to address this and hence needs to be addressed externally.
For example, APNIC provides a specified range of IPv4/IPv6/ASN No resource ISP/enterprise the authority to use the IPv4/IPv6 address block for use in their network and the AS number for BGP Advertisements as a legitimate entity. In more simple terms APNIC authorizes the ISP/Enterprise the use of the IPv4/IPv6 address block and the AS number.
It is imperative for the ISP/Enterprises to follow this strictly. As there are no mechanisms that can restrict misuse.
RPKI Addresses this via Route Origin Authorization (ROA). Authorization of a BGP Route ensures that an ISP/Enterprises cannot misuse
- How do we make sure that a route origin is from the right owner of the IPv4/IPV6 address resource (IPv4/IPv6 address block, AS number)?
A BGP prefix does not carry any information about the owner of the prefix. This is beyond the scope of the protocol.
Even though filtering of prefixes can address these problems. Filtering is a not easy way to address this problem as it requires human intervention. With the global routing table size increasing continuously, this is not an option in an operational environment.
RPKI Address this problem by enabling the Internet Service provider to validate this. This will be discussed in detail.
Incidents that explain the basic limitations of BGP Routing
- April 1997: The “AS 7007 incident” UU/Sprint for 2 days
https://en.wikipedia.org/wiki/AS_7007_incident
- February 24, 2008: Pakistan’s attempt to block YouTube access within their country takes down YouTube entirely
- November 11, 2008: The Brazilian ISP CTBC – Companhia de Telecomunicações do Brasil Central leaked their internal table into the global BGP table.
https://en.wikipedia.org/wiki/BGP_hijacking#cite_note-12
- April 8, 2010: China Telecom originated 37,000 prefixes not belonging to them in 15 minutes, causing massive outage of services globally.
https://en.wikipedia.org/wiki/BGP_hijacking#cite_note-13
Note the above issues can happen due to
- Human mistakes and not attacks
- Anything possible through human error is also possible through human intent and some were deliberate
Route Leaking
A BGP prefix advertisement or announcement from a BGP AS which is beyond the intend scope as defined in RFC 7908. Some of the common example
- BGP AS A is advertising a prefixes/routes to other Autonomous Systems that were learned from another BGP AS B that fails to comply with the filtering policies of incoming and outgoing prefixes of BGP neighbor B.
- BGP AS (owner) advertising the prefixes/routes only with the purpose of seeking exchange of local traffic and not announce the prefixes beyond the autonomous system.
- A BGP AS that exchange’s prefixes/routes with a neighboring as only with the intention of provide transit.
Example of Route Leaking
The above figure describes how route leaking happens.
- The original agreement between AS 4 and AS 5 was only to exchange locally originated prefixes and customers of AS 4 and AS 5.
- The original agreement between AS 4 and AS 3 was only to exchange locally originated prefixes and customers of AS 4 and AS 3.
AS 5 and AS 3 announce routes/prefixes that were not intended as per the commercial agreements with AS 4 resulting in route leakage.
Route Hijacking
A BGP AS that announces prefixes (IPv4 or IPv6) that do not belong to it resulting traffic being diverted and dropped as it was never intended to that destination. This causes outages leading to poisoning of the routing tables at the core of the Internet.
Route Hijacking can also involve the passage through specific Autonomous systems to reach the announced address block. The rerouting via specific ASes is mainly done with a malicious intent intercept or disrupt services. Though some of these can be accidently also.
Example of Route Hijacking
The above diagram shows how AS 119 is able to announce the prefix that belongs to AS 6 and divert traffic that can result in large scale outages.
Such advertisements can result in the compromised router advertising to other peers in a short period of time resulting in poisoning of the routing information in the routers with legitimate routing information. This could lead to further propagation which leads to large scale outages.
What is RPKI?
RPKI stands for Resource Public Key Infrastructure. RPKI enables an Internet Service Provider to implement a secure internet infrastructure using a hierarchical framework to address the security issues as discussed in the above section. RPKI is standardized in the IETF through the Secure Internet Domain Routing working group. It has produced RFCs 6480 – 6492 to standardize RPKI.
RPKI (Resource Public Key Infrastructure) allows the ISP/Enterprise
- Right to use of a certain resource (IPv4, IPv6, ASN) uniquely.
- Validate the prefixes announced by another Internet Service Provider and apply policies as needed
- Publish its own prefixes resources to others to ensure secure Internet routing.
It is important to note that to understand RPKI, one must have some basic knowledge of the following:
- Basic Knowledge of Internet Routing (specially BGP)
- Familiar with any IRR Database and its uses and challenges
- Knowledge of Cryptography is not needed however a basic Understanding
- Basic knowledge of PKI (Public Key Infrastructure)
RPKI relies heavily on Public Key Infrastructure for establishing a hierarchical framework for securing the Internet Infrastructure.
RPKI combines the hierarchy of the Internet resource assignment model through RIRs with the use of digital certificates based on standard X.509. X.509 is a standard how digital certificates are created, maintained, and distributed. X.509 requires a trust anchors or Certificate Authorities.
The Trust Anchors here are the Regional Internet Registries as shown below:
(Source: Ripe NCC)
To simplify the operations due to the large scale of operations ISPs need not maintain their own trust anchors and can rely on the RIRs or LIRs for their operations. Since RIRs and LIRs allocate Internet Resources. The role of a trust anchor is perfectly suited to scale for RIRs.
RIRs play the role of Trust Anchors allowing members to create X.509 based digital certificates as a digital proof as to the holder of the resource. RIRs in addition allow these functions for the digital certificates.
- Create X.509 base PKI certificates for their Internet Resources (IPv4, IPv6 and AS number).
- Provide attestations to the PKI Certificates for the Internet Resources
- Allowing the publishing of these Digital PKI Certificates for others to validate
By RIRs performing this ISP benefit through
- Make the registry more robust
- Making Internet Routing more secure
- Added value comes with validation
Route Origin Authorizations
The attestations of the Digital Certificates for Internet Resources held by an ISP by RIRs is called a Route Origin Authorization.
Route Origin Authorization normally states which Autonomous System is allowed to originate prefixes along with the maximum prefix length for holder of the resource.
ROA can be in one of the three states:
- Valid: The route announcement is from a valid holder and confirms to the policy of RIRs.
- Invalid: Announcement could be from an unauthorized AS, ROA for this prefix is from some other AS
- Unknown: Prefix in this announcement and the status of having a valid ROA is not known.
Route Origin Validation
Though ISPs can create ROAs and make choices, however this requires the ISP to validate the ROAs on announcements from up streams and customers. They would need to make preferences either to drop or allow these announcements.
ISPs can deploy Route Origin Validators to make preferences. The diagram given below describes the overall flow:
Validation can be performed via
- Every digital certificate and ROA is signed using the private key of the issuer
- The public keys in the repository allow you to verify the signature was made using the correct private key
- The whole RPKI tree structure up to the Root Certificates of the RIRs can be verified via Route Origin Validation workflow.
Conclusion
Some of the above challenges are due to the fact that Global Internet runs in a cooperative mode defined by best practices to address the challenges. Some initial approaches by ISPs and RIRs put in solutions based on Internet Routing Registries, however, they do not address some of the above concerns effectively resulting in a more robust approach.
Secure Internet Domain Routing working group has come up with an approach address this while keeping in mind the long-term solution with small steps. RPKI was one of the first step towards achieving this goal.
It is recommended that ISPs and enterprises adopt RPKI to make the Internet infrastructure more secure and reliable.
Click here to go back to the RPKI section.