This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] NTT now treats RPKI ROAs as IRR route(6)-objects
- Previous message (by thread): [routing-wg] New on RIPE Labs: ARTEMIS: Neutralising BGP Hijacking Within a Minute
- Next message (by thread): [routing-wg] New on RIPE Labs: Detection of Peering Infrastructure Outages Based on BGP Communities
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at ntt.net
Thu Jul 19 23:08:12 CEST 2018
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 at 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 at 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 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 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
- Previous message (by thread): [routing-wg] New on RIPE Labs: ARTEMIS: Neutralising BGP Hijacking Within a Minute
- Next message (by thread): [routing-wg] New on RIPE Labs: Detection of Peering Infrastructure Outages Based on BGP Communities
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]