a new source for authoritative routing data: ARIN WHOIS
hank at efes.iucc.ac.il
Wed Dec 20 06:21:42 CST 2017
On 20/12/2017 00:18, Job Snijders wrote:
Wow! This is great! I have just started using it and will need to set
aside a swath of time to delve deeper into this.
> 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:
> 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:
> 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 220.127.116.11/23"
> route: 18.104.22.168/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.
> 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,
More information about the NANOG