NTT now treats RPKI ROAs as IRR route(6)-objects
job at ntt.net
Thu Jul 19 21:07:13 UTC 2018
[ TL:DR - From now on, NTT / AS 2914 allows customers to either register
their announcements in the IRR, or as RPKI ROAs. This is a convenience
service for relevant regions of the world where IRR is not the norm but
RPKI is commonly available. Previously NTT only accepted IRR and
ARIN-WHOIS. I hope competitors and partners will use this approach too! ]
As most of you know, the Resource Public Key Infrastructure (RPKI) is a
modern reimagination of the good ole' IRR system we have come to love
and hate. The main advantage of the RPKI is that a consumer of the data
can cryptographically verify whether it was the actual owner of the IP
prefix that created a so-called "RPKI ROA".
(more reading: https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure)
Given that RPKI ROAs are somewhat equivalent to IRR route-objects, but
more reliable in terms of authoritativeness, NTT now has an automated
nightly process that converts RPKI information into IRR format so that
our toolchain can consume the data as if it were just another IRR
Using RPKI ROAs as if they are IRR route(6)-objects is a transitional
step towards increased security in the routing ecosystem.
We are not the first to explore this method (see post-scriptum), but I
think we are the first to republish elements from RPKI ROAs via a
publicly accessible IRRd instance queryable with the RADB IRRd protocol.
This means that anyone that points their bgpq3 or peval programs at
rr.ntt.net can leverage this method without having to update anything
else in the pipeline.
An example can be inspected here:
job at eng0 ~$ whois -h rr.ntt.net 126.96.36.199
changed: unread at ripe.net 20000101
remarks: * THIS OBJECT IS MODIFIED
remarks: * Please note that all data that is generally regarded as personal
remarks: * data has been removed from this object.
remarks: * To view the original object, please query the RIPE Database at:
remarks: * http://www.ripe.net/whois
descr: RPKI ROA for 188.8.131.52/21
remarks: This route object represents routing data retrieved from the RPKI
remarks: The original data can be found here: https://rpki.gin.ntt.net/r/AS3333/184.108.40.206/21
remarks: This route object is the result of an automated RPKI-to-IRR conversion process.
remarks: maxLength 21
changed: job at ntt.net 20180718
source: RPKI # Trust Anchor: RIPE NCC RPKI Root
job at eng0 ~$
The first object is an actual IRR "route:" object from the RIPE NCC
operated IRR, the second object is a representation of the RPKI ROA in
RPSL format published via rr.ntt.net.
In general we can state that RPKI data is very good quality data,
however please keep in mind that it may not be /correct/ data. In this
context "Good Quality" means that it cannot easily be forged or tampered
with by adversaries (but of course that doesn't protect the legitimate
owner against making misconfigurations). Just like with IRR
route(6)-objects, owners may input the wrong origin ASN in this type of
object or configure the wrong MaxLength.
NTT operates a "RPKI Cache Validator" at https://rpki.gin.ntt.net/
Everyone is free to inspect and click around in this webinterface.
Instead of https://rpki.gin.ntt.net/, there also is a command line
interface available via BGPMon's whois service:
job at vurt ~$ whois -h whois.bgpmon.com 220.127.116.11/21
% This is the BGPmon.net whois Service
% You can use this whois gateway to retrieve information
% about an IP adress or prefix
% We support both IPv4 and IPv6 address.
% For more information visit:
Prefix description: RIPE-NCC
Country code: NL
Origin AS: 3333
Origin AS Name: Reseaux IP Europeens Network Coordination Centre (RIPE NCC)
RPKI status: ROA validation successful
First seen: 2011-10-19
Last seen: 2018-07-19
Seen by #peers: 77
Notice in the above output the "ROA validation successful".
Nota bene: the fact that NTT uses RPKI ROA information in the prefix
filter generation process - does _not_ mean that NTT does "RPKI Origin
Validation" for BGP updates (yet). RPKI Origin Validation is an
additional security layer that we hope to deploy in the not too distant
future. Using RPKI ROAs in this way is an important step forward in this
Post scriptum on prior work:
Dragon Research Labs implemented the idea in 2015:
RIPE NCC's RPKI Validator added RPSL export functionality in 2015:
Arouteserver added native support for this method in October 2017.
More information about the NANOG