[lacnog] NTT now treats RPKI ROAs as IRR route(6)-objects

Jue Jul 19 18:23:17 BRT 2018

Job,
thank you for the heads up!
I believe this will be of *enormous* help in both encouraging the 
deployment of RPKI in the region and worldwide and in providing another 
alternative to the RIPE IRR.
I have one question though. Will your IRR (rr.ntt.net) available for 
querying from other networks different from NTT's ? Can we publicly 
recommend it to other carriers ?
Thank you for all your efforts!
/Carlos
via Newton Mail 
[https://cloudmagic.com/k/d/mailapp?ct=dw&cv=9.8.382&pv=10.0&source=email_footer_2]
On Thu, Jul 19, 2018 at 5:16pm, Job Snijders < job en ntt.net [job en ntt.net] > 
wrote: Dear LACNOG

[ 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 the South American region 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
source.

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 en eng0 ~$ whois -h rr.ntt.net 193.0.6.139
[Querying rr.ntt.net]
[rr.ntt.net]
route: 193.0.0.0/21
descr: RIPE-NCC
origin: AS3333
mnt-by: RIPE-NCC-MNT
changed: unread en ripe.net 20000101
source: RIPE
remarks: ****************************
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
remarks: ****************************

route: 193.0.0.0/21
descr: RPKI ROA for 193.0.0.0/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/193.0.0.0/21
remarks: This route object is the result of an automated RPKI-to-IRR 
conversion process.
remarks: maxLength 21
origin: AS3333
mnt-by: MAINT-JOB
changed: job en ntt.net 20180718
source: RPKI # Trust Anchor: RIPE NCC RPKI Root
job en 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 en vurt ~$ whois -h whois.bgpmon.com 193.0.0.0/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:
% https://portal.bgpmon.net/bgpmonapi.php

Prefix: 193.0.0.0/21
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
process.

Kind regards,

Job Snijders

Post scriptum on prior work:

Dragon Research Labs implemented the idea in 2015:
https://github.com/dragonresearch/rpki.net/blob/master/potpourri/roa-to-irr.py

RIPE NCC's RPKI Validator added RPSL export functionality in 2015:
https://mailman.nanog.org/pipermail/nanog/2015-May/075185.html

Arouteserver added native support for this method in October 2017.
https://github.com/pierky/arouteserver/issues/19
_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20180719/c53bb2d1/attachment-0003.html>