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.
Regards, Hank > 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@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: j...@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 >
