a new source for authoritative routing data: ARIN WHOIS

Wed Dec 20 12:09:06 UTC 2017

Shall we meet again, I owe you a beer. 

----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Job Snijders" <job at ntt.net> 
To: nanog at nanog.org 
Sent: Tuesday, December 19, 2017 4:18:20 PM 
Subject: a new source for authoritative routing data: ARIN WHOIS 

Dear NANOG, 

I'd like to share an update on some routing security activities that 
ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG 
Foundation, and the arouteserver project have been collaborating on. 
Quite some puzzles pieces were brought together! :) 

Traditionally, there are two commonly-used methods to signal to your 
peers or upstream providers what Origin ASN(s) are allowed to originate 
a given IP prefix. As an operator, you can either create a "route 
object" in the IRR, or you can compose a Letter Of Agency (LOA) and send 
that to your upstream providerfor manual verification. 

When it comes to manual verification of routing data (such a LOA), one 
of the big questions is "what data source is actually authoritative for 
the verification?". In the ARIN registry the so-called "OriginAS" 
attribute can be used for this purpose. The OriginAS attribute can only 
be set or modified by authorized accounts (such as the holder of the IP 
space). This makes the OriginAS attribute a very reliable source of 
truth! ARIN shared some notes on LOAs & OriginAS in the following article: 
https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters-of-authority/ 

That teamarin posting got me thinking: clearly there is a lot of 
valuable routing information in the ARIN WHOIS registry. What if we make 
the process such that you don't have to email in a LOA, and, have the 
recipient verify it against against the web interface output (which you 
updated before sending in the LOA). What if the prefix-filter generation 
software could just programmatically fetch all (CIDR, OriginAS) tuples 
from the ARIN WHOIS registry and load that into the list of prefixes a 
customer is allowed to announce. Just like we do with IRR objects! 

A few weeks ago I approached John Curran from ARIN asking whether we 
could work out a mechanism to somehow obtain a computer parsable 
rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path 
forward turned out to be an agreement between the NLNOG Foundation and 
ARIN, which authorises NLNOG to publish a subset of the bulk whois data 
in the convenient format (JSON) for operational purposes. The ARIN WHOIS 
(CIDR, OriginAS) tuples can be downloaded in JSON format here: 
http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 

Because of the JSON dump, the ARIN WHOIS data can now be easily consumed 
by software programs. For example, the JSON file is now loaded into IRR 
Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 
You can see the 'arin-whois' column which lists what ASN(s) are 
authorized to announce the blocks (this, in addition to what is signaled 
in IRR or RPKI). 

The novel thing here is that JSON file not only allows you to look up an 
OriginAS using the IP prefix as a lookup key, but the reverse can now 
also be done: lookup what IP prefixes an ASN is allowed to originate 
(based on ARIN WHOIS data). 

Deployment Experience YYCIX: 

At this point you may be wondering - what does any of the above have to 
do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/) 
or a python-based IXP Route Server management software from Italian 
origins (http://arouteserver.readthedocs.io/en/latest/) ? :-) 

As an experiment to explore real world use of the ARIN WHOIS data and 
prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo 
de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source 
in the prefix filter generation process governing the YYCIX route 
servers. The YYCIX route servers see roughly 80,000 prefixes. 

The results are fantastic: ~ 1,700 IPv4 prefixes that were previously 
rejected by the YYCIX route servers (because no IRR route object 
exists), are now accepted because those announcements can be verified 
against data from ARIN's WHOIS registry. This resolved roughly 23% of 
invalid path announcements sent to the YYCIX route servers. 

Deployment Experience NTT: 

Based on the above positive results, starting today, NTT is also 
accepting ARIN WHOIS OriginAS information in conjunction with IRR route 
objects. Our implementation fetches the ARIN WHOIS data, transforms it 
into RPSL format, and imports it into our IRRd instance at rr.ntt.net as 
IRR objects. This way we don't need to update our toolchain to make use 
of this new data source. An example is here: 

job at vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23" 
route: 204.209.252.0/23 
descr: NET-204-209-252-0-1 
origin: AS22512 
remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. 
remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1 
remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. 
mnt-by: MAINT-JOB 
changed: job at ntt.net 20090220 
source: ARIN-WHOIS 

NTT also observed a substantial number (similar to YYCIX) of BGP 
announcements from its customers that were previously rejected because 
of the lack of an IRR object, but now are validated via ARIN WHOIS. 

Conclusion: 

It is great to be able to offer network operators a choice: either 
register your BGP announcements as route objects in RPSL format in IRR, 
or use the ARIN WHOIS web interface, (or both) - either way, as IP 
transit carrier, we can now pick up your attestations in an automated 
fashion. This which improves accuracy and reduces red tape! :) 

Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source 
in their automation toolchain. The code & procedures to make use of this 
source are open. I'm happy to help you both on-list and off-list. 

Kind regards, 

Job 