December 2017 - Test - lists.nanog.org

IPSec SPI
by Mike Hammett 20 Dec '17

20 Dec '17

Is it possible for light packet loss (0.1% - 0.3%) to cause these errors: Dec 18 00:12:07.098: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=Z.Z.Z.Z, prot=50, spi=0x9E6D41B7(2657960375), srcaddr=B.B.B.B, input interface=GigabitEthernet0/2 Dec 18 00:20:47.848: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x430A8C9C(1124764828), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 Dec 18 00:28:39.781: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x8716502A(2266386474), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 I look it up and none of the pages I find say anything about connection quality and everything about configuration and timing. My client is insisting that it can't possibly be their problem and that it's entirely because of the packet loss. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

2 2

a new source for authoritative routing data: ARIN WHOIS
by Job Snijders 20 Dec '17

20 Dec '17

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(a)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

3 2

historic SWIP (or rwhois) data?
by Neal Rauhauser 20 Dec '17

20 Dec '17

Hello, I'm working on a forensics problem rather than a network operations issue. I've got a /28 that I can see is currently assigned to a certain company via rwhois. What I want to do is see this block's history over the last five years. It was involved in some problematic behavior back in 2012, I'd really like to know whose name was on it then. It would be ideal if this data were available in some sort of flat file format, or if a sensible API to it exists. I've been searching a little bit, just found this, not really seeing any place to download any of this data though. https://gist.github.com/NetwarSystem/eed78b65d881d0d384664ab713cf5e1f

4 4

Final Reminder to Re-Register DMCA Agents in Electronic System
by Sean Donelan 19 Dec '17

19 Dec '17

The U.S. Copyright Office has been moving DMCA registration from paper forms to an online registration system. All previously filed paper DMCA agent registration forms expire on December 31, 2017. U.S. ISPs and non-US ISPs doing business in the United States should have re-registered using the online DMCA electronic registration. If you've neglected to register using the online system, you have until December 31, 2017. https://www.copyright.gov/newsnet/2017/694.html

1 0

MSN/Azure
by Joe Carroll 19 Dec '17

19 Dec '17

Anyone have a clueful contact at Azure/MSN? We have a block of recently acquired address space being filtered.

2 1

Geolocate data for allocated blocks
by JASON BOTHE 19 Dec '17

19 Dec '17

I am seeking assistance in getting nets I’ve allocated (several months ago) to an office in another RIR region to properly update its geolocate data. In this particular case, I have a net in use in India, but currently reflects Houston as its address although the allocation indicates otherwise. Any databases I should contact or other info is appreciated. Cheers! Jason

3 2

40G and 100G optics options
by Baldur Norddahl 19 Dec '17

19 Dec '17

Hi What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km links? I see a lot of switches offered with QSFP+ and QSFP28. But I do not seem to find the necessary optics to build the links I want. For example, take a look at the options available at Fiberstore: https://www.fs.com/c/generic-40g-qsfp-891 Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC Transceiver for SMF $340 Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC Transceiver for SMF $1500 https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858 Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver $1999 Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver $7000 That is it. Four modules and the 40km are prohibitive expensive. The situation at other vendors appears to be similar. I need stronger modules that can do more than 10 km without being extremely expensive. Or DWDM modules in the 1550 nm band so I can use external amplifiers. Am I looking in the wrong place? Is this expected to be available in the near future? Regards, Baldur

6 7

contact for WCGDB routing registry?
by Christopher Rogers 19 Dec '17

19 Dec '17

Does anyone have a contact for the WCGDB RR? They've got an invalid object registered that is being mirrored to other providers, but I am unable to find any working poc. Also why is wcg.com running an RR that's being mirrored by t1s to begin with? (changed had wcg.com email addr.) cheers -chris

1 0

Eurofiber Contact
by Rod Beck 19 Dec '17

19 Dec '17

Please contact me ASAP concerning Amsterdam DF. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> 85 Király utca, 1077 Budapest rod.beck(a)unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png]

1 0

Multi lane optics
by Baldur Norddahl 19 Dec '17

19 Dec '17

Hello, Some optics are implemented with multiple lasers such as QSFP+ with 4x 10G = 40G or QSFP28 with 4x 25G = 100G. How is the ethernet traffic load balanced between those lanes? Is it bit by bit or more like LACP (packet by packet)? I need to make sure my solution will handle 10G streams correctly. We have a problem with N x 10G and LACP because our L2VPN MPLS endpoints are lacking the flow label support. If I sell a 10G circuit to a customer and uses a L2VPN to transport his port, everything may go on the same sub channel. LACP will not load balance correctly, because it only sees the outer MAC address for hashing, which is the same for all packets. Now we are worried that multi lane optics might have the exact same problem. Regards, Baldur

3 2