Print

Print


No, it is simply another option to provide Prefix/ASN binding information
for address blocks registered with ARIN, you can still do it with an IRR if
you wish.

On Wed, Dec 20, 2017 at 10:38 AM, DeLong, Owen <
[log in to unmask]> wrote:

> This assumes that all prefixes advertised at MICE are issued by ARIN.
>
> Owen
>
> On Dec 19, 2017, at 14:54 , David Farmer <[log in to unmask]> wrote:
>
> FYI,
>
> A very interesting development in light of our discussions about doing
> route filtering at MICE.
>
> With this development I enthusiastically support moving forward with route
> filtering because it provides an easy answer to Richards question about
> which IRR to use, you don't have to use any of them you can do it all in
> ARIN ONLINE.
>
> Thanks.
>
> ---------- Forwarded message ----------
> From: Job Snijders <[log in to unmask]>
> Date: Tue, Dec 19, 2017 at 4:37 PM
> Subject: [routing-wg] a new source for authoritative routing data: ARIN
> WHOIS
> To: [log in to unmask]
>
>
> 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 <[log in to unmask]> -----
>
> Date: Tue, 19 Dec 2017 22:18:20 +0000
> From: Job Snijders <[log in to unmask]>
> To: [log in to unmask]
> 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-v
> alidate-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:    [log in to unmask] 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               Email:[log in to unmask]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> 
>       Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>
> ------------------------------
>
> To unsubscribe from the MICE-DISCUSS list, click the following link:
> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
> 
>
>
>
> ------------------------------
>
> To unsubscribe from the MICE-DISCUSS list, click the following link:
> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
>



-- 
===============================================
David Farmer               Email:[log in to unmask]
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
===============================================