The whois protocol has been in use for 37 years now — it was first defined in RFC 812 in 1982, and has become the default method for accessing public registry databases that record the status of Internet name and number resources. The protocol grew as the Internet grew, being updated in RFC 954 in 1985 and again in RFC 3912 in 2004.
Whois has served the Internet community well for a long time, but as RFC 3912 itself tells us, “whois lacks many of the protocol design attributes, for example internationalisation and strong security, that would be expected from any recently-designed IETF protocol”. In addition, query and reply formats are not standardized in whois, which can make automation difficult.
RDAP: Designed for automation
With the growth in the amount of Internet resources in use worldwide, and our increasing reliance on automation to operate networks, recent years have seen a rapid evolution in the practice of linking an entity with a resource.
Enter Registration Data Access Protocol (RDAP), an API specification for accessing ‘whois’ data. Beginning in 2015, a suite of RFCs defined different aspects of RDAP, which cover the shortcomings of the old whois protocol, including:
- Easily programmable interaction via standardized query and response (JSON) formats.
- Internationalization, via support for Unicode and server or client-side language preference.
- A RESTful interface, which enables:
- Security and differentiated access via Authentication, Authorization and Accounting (AAA).
- Redirection for seamless referral to other registries.
RPKI: A cryptographically verifiable view of the registry
So now we can access information about Internet resources in a standardized way that is also easy to automate and internationalize — great! But how do we know that holders of resources are who they say they are?
Before accepting a BGP advertisement, it is crucially important to know that a peer has the authority to route the prefixes they are advertising. As we have frequently (and recently) seen, a BGP leak can have a large-scale impact on the Internet.
RPKI is a public key infrastructure framework based on X.509 standards. RPKI works by adding Internet Number Resource (INR) information to X.509 certificates, attesting custodianship and other status information regarding a particular INR.
RPKI offers a single authority model, with its certification hierarchy following that of INR delegation. So IANA acts as Certificate Authority (CA) for RIRs, which are in turn CAs for NIRs or ISPs.
Figure 1 — RPKI hierarchy.
The main and most widely known application of RPKI is for Route Origin Validation (ROV), which is performed using a Route Origin Authorization (ROA). A ROA lists the prefixes that an ASN is authorized to announce. Once validated, a ROA can be used to generate route filters.
RPKI is currently validating over 800,000 IPv4 prefix/origin pairs globally, with almost 200,000 of those in the APNIC region.
Figure 2 — RPKI Status — APNIC Region (Source: NIST RPKI Monitor).
Another application of RPKI is Resource Tagged Attestation, which allows RPKI certificates to be used to sign an arbitrary object. For example, RTAs could be used in place of a Letter of Authority (LoA), commonly used when interconnecting at an IXP.
Learn more at MyNOG 8
APNIC Deputy Director General, Sanjaya, will be sharing more about how to get started with RDAP and RPKI in his presentation, ‘Internet Number Registry Services: The Next Generation’ at MyNOG 8 in Petaling Jaya on Thursday, 4 July.
For those who aren’t attending, take a look at the APNIC website’s RDAP and RPKI pages.
APNIC Member Services will also be on hand at MyNOG 8 to assist with queries about APNIC Membership, resource delegation and other services, including RPKI and RDAP.
Contributor: Sanjaya.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.