Internet2 Network Security SIG

[David Farmer <>]

I think this is an interesting development. I would encourage everyone to review the Origin AS field associated with each of your AIRN registered IP blocks, especially if you don't otherwise maintain IRR entries for your blocks.  For regional networks, it might be a good idea to review your downstream institutions blocks as well and let them know if anything needs to be corrected. 

Reviewing this is as simple as looking up the block in ARIN's WHOIS. If the Origin AS field is blank and you have other covering IRR entries providing that information your are fine. Otherwise, if Origin AS field is incorrect, or blank without other covering IRR entries, the can be easily be fixed in ARIN ONLINE.  

Please note that this doesn't only impact you if you peer at an IX or have a direct peer that uses IRR data, if networks upstream of you peer at an IX or have peers that uses IRR data, your prefixes could be filtered.  So, this applies to most of us, as most of us use ARIN as our registry and most of us participate in TR/CPS.

Thanks  

 

---------- Forwarded message ----------
From: Job Snijders <>
Date: Tue, Dec 19, 2017 at 4:37 PM
Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS
To:


Dear RIPE WG,

I'm sharing a copy of what I sent to NANOG. This is specifically of
interest to networks and route server operators that have customers who
also operate in the ARIN region.

In the RIPE region we've always had the convenience that the "WHOIS"
('inetnum') and "IRR" ('route/route6') components of the database were
interleaved. Only the IP block's owner can create or authorise others
regarding creation of route-objects. This coupling of WHOIS and IRR
doesn't exist at rr.arin.net vs whois.arin.net - so I consider the
following a significant improvement.

Kind regards,

Job

----- Forwarded message from Job Snijders <> -----

Date: Tue, 19 Dec 2017 22:18:20 +0000
From: Job Snijders <>
To:
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@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:    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

----- End forwarded message -----

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================