[lacnog] NTT now treats RPKI ROAs as IRR route(6)-objects
Alejandro Acosta
alejandroacostaalamo en gmail.com
Jue Jul 19 23:07:41 BRT 2018
Hello Job,
First, congratulations and thanks for the info. From my point of view
it’s a terrific approach.
Second, I got two questions while reading your email.
1. Since when are you doing this?, I mean, to know if you started
yesterday or maybe you already have being doing this for some weeks and
nothing strange have happened.
2. In case there is IRR and RPKI, which one has preference?
Thanks,
Alejandro,
El 19/7/18 a las 17:10, Job Snijders escribió:
> 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
Más información sobre la lista de distribución LACNOG