FW: NTT now treats RPKI ROAs as IRR route(6)-objects
FYI ----- Forwarded message from Job Snijders <job@ntt.net> ----- Date: Thu, 19 Jul 2018 21:08:12 +0000 From: Job Snijders <job@ntt.net> To: routing-wg@ripe.net Subject: NTT now treats RPKI ROAs as IRR route(6)-objects Dear RIPE Routing-WG, [ 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 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@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@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@ntt.net 20180718 source: RPKI # Trust Anchor: RIPE NCC RPKI Root job@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@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.... 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 ----- End forwarded message -----
Hi Job, On 19/07/18 23:52, Job Snijders wrote:
FYI
----- Forwarded message from Job Snijders <job@ntt.net> -----
Date: Thu, 19 Jul 2018 21:08:12 +0000 From: Job Snijders <job@ntt.net> To: routing-wg@ripe.net Subject: NTT now treats RPKI ROAs as IRR route(6)-objects
Dear RIPE Routing-WG,
[ 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! ]
Cool. What do you do if someone registers in RPKI and IRR and the data does not match? Kind regards, Martin
Dear Martin, On Fri, Jul 20, 2018 at 11:27:18AM +0200, Martin Pels wrote:
On 19/07/18 23:52, Job Snijders wrote:
[ 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! ]
Cool. What do you do if someone registers in RPKI and IRR and the data does not match?
What was deployed here is what I'd call 'step 1'. RPKI now complements the IRR data. Just like when you mirror RIPE and RADB, with default settings both sources will be used to construct the list of prefixes when you issue a '!gAS15562' command to the IRRd server. The next step is to let RPKI ROAs 'drown out' or 'overwrite' conflicting IRR information, and have the IRRd instance supress the conflicting IRR information for all its outputs. This "RPKI supersedes IRR" approach has two benefits: A/ It would provide the industry with a method of signaling to IRRs that there are stale proxy route objects (perhaps as old as 20 years), and by issuing an RPKI ROA to me it is a clear signal that the route-object is outdated and should no longer be considered. B/ It prevents future IRR-based hijacks, because IRRd instances won't accept conflicting IRR information into their feasible output. We'll have to worry less about false IRR information popping up in one of the many IRRs because the RPKI ROA is leading. In short: "RPKI supersedes IRR" will be both help clean-up old data, and is security feature. The feature to facilitate this next step is tracked here: https://github.com/irrdnet/irrd4/issues/3 Kind regards, Job
participants (2)
-
Job Snijders -
Martin Pels