Fwd: [routing-wg] a new source for authoritative routing data: ARIN WHOIS
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 <job@ntt.net> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg@ripe.net 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 <job@ntt.net> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job@ntt.net> To: nanog@nanog.org 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: job@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 ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu 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> ===============================================
This assumes that all prefixes advertised at MICE are issued by ARIN. Owen On Dec 19, 2017, at 14:54 , David Farmer <farmer@umn.edu<mailto:farmer@umn.edu>> 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 <job@ntt.net<mailto:job@ntt.net>> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg@ripe.net<mailto:routing-wg@ripe.net> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Y4pftSZzes20hlfBQteLLH_JFwZVKVUKD_ME4GpY9xs&e=> vs whois.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=U43cZVUZtHIIh-3GKN7ektdlfyv8-eKGxGke63nt7Cw&e=> - so I consider the following a significant improvement. Kind regards, Job ----- Forwarded message from Job Snijders <job@ntt.net<mailto:job@ntt.net>> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job@ntt.net<mailto:job@ntt.net>> To: nanog@nanog.org<mailto:nanog@nanog.org> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_07_origin-2Das-2Dan-2Deasier-2Dway-2Dto-2Dvalidate-2Dletters-2Dof-2Dauthority_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=9mayp5twv5hMZUH5mT3LRJhbTbjUoUnJ7ZcF0jDPrTo&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_static_dumps_arin-2Dwhois-2Doriginas.json.bz2&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Prf1XEOKD9lP5dw-Jq5823mCZyV2PDSb8Xp6aHKf9r0&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_search_AS22512&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=oQqTnkiGEDeQLNCfe_ES03M8qVANt8Oq7VbWoHnONXY&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=7nrxZSztBqPIkmm_4ikBXMHE65jZAusTVrJFdkLjw9I&e=>) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/<https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedocs.io_en_latest_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=KVuB_o05SHqiuecLrPoUfxvlbNMfyqCkblwgMKkWjOU&e=>) ? :-) 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> -- "-sARIN-WHOIS 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=>" route: 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_net_NET-2D204-2D209-2D252-2D0-2D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=d4z0ZsEvjHDXiFH88feEpNg7U-Yn0mCiptgGlBnfZbE&e=> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job@ntt.net<mailto:job@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 ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(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<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=e7_l4tQsQkfVl0cwo0rOuK3KIWODP_fuSHtoQOzsVhg&e=>
Not necessarily. Any sane IRR filtering solution would match against some sort of IRR DB that mirrors ARIN/RIPE/RADB/etc. I think David is getting at more about which IRR to use to register your objects. -- Andrew Hoyos hoyosa@gmail.com
On Dec 20, 2017, at 10:38 AM, DeLong, Owen <00000005a669d12e-dmarc-request@LISTS.IPHOUSE.NET> wrote:
This assumes that all prefixes advertised at MICE are issued by ARIN.
Owen
On Dec 19, 2017, at 14:54 , David Farmer <farmer@umn.edu> 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 <job@ntt.net> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg@ripe.net
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 <job@ntt.net> -----
Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job@ntt.net> To: nanog@nanog.org 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-...
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: job@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
----- End forwarded message -----
-- =============================================== David Farmer Email:farmer@umn.edu 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 ===============================================
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
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 < 00000005a669d12e-dmarc-request@lists.iphouse.net> wrote:
This assumes that all prefixes advertised at MICE are issued by ARIN.
Owen
On Dec 19, 2017, at 14:54 , David Farmer <farmer@umn.edu> 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 <job@ntt.net> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg@ripe.net
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Y4pftSZzes20hlfBQteLLH_JFwZVKVUKD_ME4GpY9xs&e=> vs whois.arin.net <https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=U43cZVUZtHIIh-3GKN7ektdlfyv8-eKGxGke63nt7Cw&e=> - so I consider the following a significant improvement.
Kind regards,
Job
----- Forwarded message from Job Snijders <job@ntt.net> -----
Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job@ntt.net> To: nanog@nanog.org 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/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_07_origin-2Das-2Dan-2Deasier-2Dway-2Dto-2Dvalidate-2Dletters-2Dof-2Dauthority_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=9mayp5twv5hMZUH5mT3LRJhbTbjUoUnJ7ZcF0jDPrTo&e=>
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_static_dumps_arin-2Dwhois-2Doriginas.json.bz2&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Prf1XEOKD9lP5dw-Jq5823mCZyV2PDSb8Xp6aHKf9r0&e=>
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_search_AS22512&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=oQqTnkiGEDeQLNCfe_ES03M8qVANt8Oq7VbWoHnONXY&e=> 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/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=7nrxZSztBqPIkmm_4ikBXMHE65jZAusTVrJFdkLjw9I&e=> ) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedocs.io_en_latest_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=KVuB_o05SHqiuecLrPoUfxvlbNMfyqCkblwgMKkWjOU&e=>) ? :-)
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> -- "-sARIN-WHOIS 204.209.252.0/23 <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=> " route: 204.209.252.0/23 <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=> 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_net_NET-2D204-2D209-2D252-2D0-2D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=d4z0ZsEvjHDXiFH88feEpNg7U-Yn0mCiptgGlBnfZbE&e=> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job@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
----- End forwarded message -----
-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=e7_l4tQsQkfVl0cwo0rOuK3KIWODP_fuSHtoQOzsVhg&e=>
------------------------------
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:farmer@umn.edu 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 ===============================================
If MICE starts building filters based on ARIN whois, that won’t include data from other IRRs or IRR data at all. If MICE is building filters from IRR databases, it won’t include the ARIN whois information. We’d have to merge data from both sources in order to have a workable solution that doesn’t ignore important data. Thus, David’s suggestion that we could “just use ARIN ONLINE” without using any IRR doesn’t match my understanding of Job’s message. Owen On Dec 20, 2017, at 08:52 , David Farmer <farmer@UMN.EDU<mailto:farmer@UMN.EDU>> wrote: 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 <00000005a669d12e-dmarc-request@lists.iphouse.net<mailto:00000005a669d12e-dmarc-request@lists.iphouse.net>> wrote: This assumes that all prefixes advertised at MICE are issued by ARIN. Owen On Dec 19, 2017, at 14:54 , David Farmer <farmer@umn.edu<mailto:farmer@umn.edu>> 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 <job@ntt.net<mailto:job@ntt.net>> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg@ripe.net<mailto:routing-wg@ripe.net> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Y4pftSZzes20hlfBQteLLH_JFwZVKVUKD_ME4GpY9xs&e=> vs whois.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=U43cZVUZtHIIh-3GKN7ektdlfyv8-eKGxGke63nt7Cw&e=> - so I consider the following a significant improvement. Kind regards, Job ----- Forwarded message from Job Snijders <job@ntt.net<mailto:job@ntt.net>> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job@ntt.net<mailto:job@ntt.net>> To: nanog@nanog.org<mailto:nanog@nanog.org> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_07_origin-2Das-2Dan-2Deasier-2Dway-2Dto-2Dvalidate-2Dletters-2Dof-2Dauthority_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=9mayp5twv5hMZUH5mT3LRJhbTbjUoUnJ7ZcF0jDPrTo&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_static_dumps_arin-2Dwhois-2Doriginas.json.bz2&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Prf1XEOKD9lP5dw-Jq5823mCZyV2PDSb8Xp6aHKf9r0&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_search_AS22512&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=oQqTnkiGEDeQLNCfe_ES03M8qVANt8Oq7VbWoHnONXY&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=7nrxZSztBqPIkmm_4ikBXMHE65jZAusTVrJFdkLjw9I&e=>) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/<https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedocs.io_en_latest_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=KVuB_o05SHqiuecLrPoUfxvlbNMfyqCkblwgMKkWjOU&e=>) ? :-) 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> -- "-sARIN-WHOIS 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=>" route: 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_net_NET-2D204-2D209-2D252-2D0-2D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=d4z0ZsEvjHDXiFH88feEpNg7U-Yn0mCiptgGlBnfZbE&e=> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job@ntt.net<mailto:job@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 ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3D2218-2BUniversity-2BAve-2BSE-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=hZ3HXBxU6JkXYN4Gm18T96ZpW6JuedBSwZ9ERqSEGVc&e=> Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(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<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=e7_l4tQsQkfVl0cwo0rOuK3KIWODP_fuSHtoQOzsVhg&e=> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=ujMggJMmdDn0Hs-eB-c_XCwvNoK8KkarnWK2b8cZDcI&e=> -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> 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 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=ujMggJMmdDn0Hs-eB-c_XCwvNoK8KkarnWK2b8cZDcI&e=>
I understood it as: A network could use just ARIN (or an IRR of their choice). MICE would look at multiple IRRs plus the ARIN-based data. -- Richard
I see the disconnect now. I said,"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." Richard's questions was "which IRR should we(MICE) recommend networks use, if they aren't already using one, not which IRR MICE should use." And the answer to that question is use ARIN ONLINE and not an IRR. And yes they would be to a network that received it's block from ARIN, which is the case for the vast majority of MICE connected networks. I wasn't suggesting the MICE could only use ARIN WHOIS info. MICE would have to generate filters based on ARIN WHOIS and all the IRRs. Hope that clarifies things. Thanks. On Wed, Dec 20, 2017 at 11:11 AM, DeLong, Owen < 00000005a669d12e-dmarc-request@lists.iphouse.net> wrote:
If MICE starts building filters based on ARIN whois, that won’t include data from other IRRs or IRR data at all.
If MICE is building filters from IRR databases, it won’t include the ARIN whois information.
We’d have to merge data from both sources in order to have a workable solution that doesn’t ignore important data.
Thus, David’s suggestion that we could “just use ARIN ONLINE” without using any IRR doesn’t match my understanding of Job’s message.
Owen
On Dec 20, 2017, at 08:52 , David Farmer <farmer@UMN.EDU> wrote:
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 <00000005a669d12e-dmarc- request@lists.iphouse.net> wrote:
This assumes that all prefixes advertised at MICE are issued by ARIN.
Owen
On Dec 19, 2017, at 14:54 , David Farmer <farmer@umn.edu> 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 <job@ntt.net> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg@ripe.net
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Y4pftSZzes20hlfBQteLLH_JFwZVKVUKD_ME4GpY9xs&e=> vs whois.arin.net <https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=U43cZVUZtHIIh-3GKN7ektdlfyv8-eKGxGke63nt7Cw&e=> - so I consider the following a significant improvement.
Kind regards,
Job
----- Forwarded message from Job Snijders <job@ntt.net> -----
Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job@ntt.net> To: nanog@nanog.org 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/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_07_origin-2Das-2Dan-2Deasier-2Dway-2Dto-2Dvalidate-2Dletters-2Dof-2Dauthority_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=9mayp5twv5hMZUH5mT3LRJhbTbjUoUnJ7ZcF0jDPrTo&e=>
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_static_dumps_arin-2Dwhois-2Doriginas.json.bz2&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Prf1XEOKD9lP5dw-Jq5823mCZyV2PDSb8Xp6aHKf9r0&e=>
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_search_AS22512&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=oQqTnkiGEDeQLNCfe_ES03M8qVANt8Oq7VbWoHnONXY&e=> 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/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=7nrxZSztBqPIkmm_4ikBXMHE65jZAusTVrJFdkLjw9I&e=> ) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedocs.io_en_latest_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=KVuB_o05SHqiuecLrPoUfxvlbNMfyqCkblwgMKkWjOU&e=>) ? :-)
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> -- "-sARIN-WHOIS 204.209.252.0/23 <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=> " route: 204.209.252.0/23 <https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=> 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_net_NET-2D204-2D209-2D252-2D0-2D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=d4z0ZsEvjHDXiFH88feEpNg7U-Yn0mCiptgGlBnfZbE&e=> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job@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
----- End forwarded message -----
-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3D2218-2BUniversity-2BAve-2BSE-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=hZ3HXBxU6JkXYN4Gm18T96ZpW6JuedBSwZ9ERqSEGVc&e=> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=e7_l4tQsQkfVl0cwo0rOuK3KIWODP_fuSHtoQOzsVhg&e=>
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=ujMggJMmdDn0Hs-eB-c_XCwvNoK8KkarnWK2b8cZDcI&e=>
-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=ujMggJMmdDn0Hs-eB-c_XCwvNoK8KkarnWK2b8cZDcI&e=>
------------------------------
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:farmer@umn.edu 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 ===============================================
Is there a toolset that could generate a filter based on several common IRR’s and ARIN information see what kind of coverage there would be? I just fixed up several of my $DAYJOB’s ARIN records tonight. Frank From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Wednesday, December 20, 2017 12:36 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [routing-wg] a new source for authoritative routing data: ARIN WHOIS I see the disconnect now. I said,"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." Richard's questions was "which IRR should we(MICE) recommend networks use, if they aren't already using one, not which IRR MICE should use." And the answer to that question is use ARIN ONLINE and not an IRR. And yes they would be to a network that received it's block from ARIN, which is the case for the vast majority of MICE connected networks. I wasn't suggesting the MICE could only use ARIN WHOIS info. MICE would have to generate filters based on ARIN WHOIS and all the IRRs. Hope that clarifies things. Thanks. On Wed, Dec 20, 2017 at 11:11 AM, DeLong, Owen <00000005a669d12e-dmarc-request@lists.iphouse.net<mailto:00000005a669d12e-dmarc-request@lists.iphouse.net>> wrote: If MICE starts building filters based on ARIN whois, that won’t include data from other IRRs or IRR data at all. If MICE is building filters from IRR databases, it won’t include the ARIN whois information. We’d have to merge data from both sources in order to have a workable solution that doesn’t ignore important data. Thus, David’s suggestion that we could “just use ARIN ONLINE” without using any IRR doesn’t match my understanding of Job’s message. Owen On Dec 20, 2017, at 08:52 , David Farmer <farmer@UMN.EDU<mailto:farmer@UMN.EDU>> wrote: 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 <00000005a669d12e-dmarc-request@lists.iphouse.net<mailto:00000005a669d12e-dmarc-request@lists.iphouse.net>> wrote: This assumes that all prefixes advertised at MICE are issued by ARIN. Owen On Dec 19, 2017, at 14:54 , David Farmer <farmer@umn.edu<mailto:farmer@umn.edu>> 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 <job@ntt.net<mailto:job@ntt.net>> Date: Tue, Dec 19, 2017 at 4:37 PM Subject: [routing-wg] a new source for authoritative routing data: ARIN WHOIS To: routing-wg@ripe.net<mailto:routing-wg@ripe.net> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Y4pftSZzes20hlfBQteLLH_JFwZVKVUKD_ME4GpY9xs&e=> vs whois.arin.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__whois.arin.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=U43cZVUZtHIIh-3GKN7ektdlfyv8-eKGxGke63nt7Cw&e=> - so I consider the following a significant improvement. Kind regards, Job ----- Forwarded message from Job Snijders <job@ntt.net<mailto:job@ntt.net>> ----- Date: Tue, 19 Dec 2017 22:18:20 +0000 From: Job Snijders <job@ntt.net<mailto:job@ntt.net>> To: nanog@nanog.org<mailto:nanog@nanog.org> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__teamarin.net_2016_07_07_origin-2Das-2Dan-2Deasier-2Dway-2Dto-2Dvalidate-2Dletters-2Dof-2Dauthority_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=9mayp5twv5hMZUH5mT3LRJhbTbjUoUnJ7ZcF0jDPrTo&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_static_dumps_arin-2Dwhois-2Doriginas.json.bz2&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=Prf1XEOKD9lP5dw-Jq5823mCZyV2PDSb8Xp6aHKf9r0&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__irrexplorer.nlnog.net_search_AS22512&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=oQqTnkiGEDeQLNCfe_ES03M8qVANt8Oq7VbWoHnONXY&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yycix.ca_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=7nrxZSztBqPIkmm_4ikBXMHE65jZAusTVrJFdkLjw9I&e=>) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/<https://urldefense.proofpoint.com/v2/url?u=http-3A__arouteserver.readthedocs.io_en_latest_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=KVuB_o05SHqiuecLrPoUfxvlbNMfyqCkblwgMKkWjOU&e=>) ? :-) 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rr.ntt.net&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=iRXTKlLxBwultI1iITpKcorWlvGhU3C5ZVOs9r07MpE&e=> -- "-sARIN-WHOIS 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=>" route: 204.209.252.0/23<https://urldefense.proofpoint.com/v2/url?u=http-3A__204.209.252.0_23&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=1MK6dJV9MZw7nUC25c8FIYsH9V8ZNtd-BAe5HjpiZ7A&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__whois.arin.net_rest_net_NET-2D204-2D209-2D252-2D0-2D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=d4z0ZsEvjHDXiFH88feEpNg7U-Yn0mCiptgGlBnfZbE&e=> remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job@ntt.net<mailto:job@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 ----- End forwarded message ----- -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3D2218-2BUniversity-2BAve-2BSE-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=hZ3HXBxU6JkXYN4Gm18T96ZpW6JuedBSwZ9ERqSEGVc&e=> Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(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<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=eW7LnriCezBPIK83AFHYZv5-QFEN6uxrxlukEnDoLw8&s=e7_l4tQsQkfVl0cwo0rOuK3KIWODP_fuSHtoQOzsVhg&e=> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=ujMggJMmdDn0Hs-eB-c_XCwvNoK8KkarnWK2b8cZDcI&e=> -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE<https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(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<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2Dbin_wa-3FSUBED1-3DMICE-2DDISCUSS-26A-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=6oowLdnPoV7UBU7PqRgFImPzDtMgK42G0kEkmJnih1M&s=ujMggJMmdDn0Hs-eB-c_XCwvNoK8KkarnWK2b8cZDcI&e=> ________________________________ 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:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> 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 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On Dec 29, 2017, at 8:43 PM, Frank Bulk <fbulk@mypremieronline.com> wrote:
Is there a toolset that could generate a filter based on several common IRR’s and ARIN information see what kind of coverage there would be?
IRR Explorer is your friend: http://irrexplorer.nlnog.net/ <http://irrexplorer.nlnog.net/> (search for your ASN, or whatever your AS-SET is) Also, IRRToolset: https://github.com/irrtoolset/irrtoolset <https://github.com/irrtoolset/irrtoolset> — Andrew Hoyos hoyosa@gmail.com
participants (5)
-
Andrew Hoyos
-
David Farmer
-
DeLong, Owen
-
Frank Bulk
-
Richard Laager