August 2019 - Test - lists.nanog.org

44/8
by Majdi S. Abbas 01 Sep '19

01 Sep '19

Apparently isn't 44/8 anymore: NetRange: 44.192.0.0 - 44.255.255.255 CIDR: 44.192.0.0/10 NetName: AT-88-Z NetHandle: NET-44-192-0-0-1 Parent: NET44 (NET-44-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Amazon Technologies Inc. (AT-88-Z) RegDate: 2019-07-18 Updated: 2019-07-18 Ref: https://rdap.arin.net/registry/ip/44.192.0.0 Some additional color is available at: https://www.ampr.org/amprnet/ What's interesting about this is it was not an ARIN allocation, and the ARDC folks are not the original registrant. This IANA /8 was initially delegated to a community, not an organization. So, to the individuals listed in the blog, that I've excerpted below, what do you have to say about this? Brian Kantor kc claffy Phil Karn Paul Vixie [I've omitted those I don't know to be NANOG familiar.] ARIN also appears to have a role here. Any comment, ARIN folks? --msa P.S. I've been licensed as a ham since prior to the organization of ARDC in 1992 -- where's my check?

54 133

Re: Weekly Routing Table Report
by Scott Weeks 31 Aug '19

31 Aug '19

From: Masataka Ohta <mohta(a)necom830.hpcl.titech.ac.jp> If you can't accept the following principle of the End to End argument: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. ------------------------------------------------------- I have been reading your posts on IETF and here regarding the above and I'm curious as to your thoughts on John Day's RINA. It tosses all this on its head. scott

2 1

Re: Weekly Routing Table Report
by Scott Weeks 31 Aug '19

31 Aug '19

--- web(a)typo.org wrote: "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???" --------------------------------------- Is that like the NANOG version of "get off my lawn"? :) scott bgp since ~50k

5 4

The Curious Case of 143.95.0.0/16
by Ronald F. Guilmette 28 Aug '19

28 Aug '19

Mel Beckman mel at beckman.org wrote: >I have one question, “of late”, regarding your post: Is it “Antia” or “Anita”? Yes. Sorry. There were multiple small typos in what I posted. Not surprising, since I am an utterly awful typist. The link I gave in my post provides enough redundant context to work out the correct answer in this case: https://infragard-boston.org/ The gentleman's name is Robert ("Bob") Antia. Unrelated to that small faux pas on my part, I also would just like to mention that I have only just now been pointed at an additional relevant online document that provides more clarity as regards to who, or what, ended up owning the original Athenix's intangible assets following its demise. https://patents.google.com/patent/US5119494 In the case of this patent, ownership seem to have untimately been assigned to: JACKSON, DAVID HOOK PARTNERS II C/O DAVID J. HOOK KLEINER PERKINS CAUFIELD & BYERS V C/O JAMES LALLY COMDISCO, INC. INSTITUTIONAL VENTURE MANAGEMENT V C/O PETER THOMAS GARROW, ROBERT A. INSTITUTIONAL VENTURE PARTNERS FUND V C/O PETER THOMAS SINGAPORE ECONOMIC DEVELOPMENT BOARD PACVEN INVESTMENT, LTD. C/O LIP-BU TAN Obviously, this is a more complete list of Athenix's heirs and assigns than I had included in my earlier post. Regards, rfg

1 0

Reflection DDoS last week (was: syn flood attacks from NL-based netblocks)
by Töma Gavrichenkov 28 Aug '19

28 Aug '19

Peace, Here's to confirm that the pattern reported before in NANOG was indeed a reflection DDoS attack. On Sunday, it also hit our customer, here's the report: https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-r… tl;dr: basically that was a rather massive reflected SYN/ACK carpet bombing against several datacenter prefixes (no particular target was identified). -- Töma On Sat, Aug 17, 2019, 1:06 AM Jim Shankland <nanog(a)shankland.org> wrote: > Greetings, > > I'm seeing slow-motion (a few per second, per IP/port pair) syn flood > attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 > , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, > and BCP 38 not yet fully adopted). > > Why is this syn flood different from all other syn floods? Well ... > > 1. Rate seems too slow to do any actual damage (is anybody really > bothered by a few bad SYN packets per second per service, at this > point?); but > > 2. IPs/port combinations with actual open services are being targeted > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs > with those services running), implying somebody checked for open > services first; > > 3. I'm seeing this in at least 2 locations, to addresses in different, > completely unrelated ASes, implying it may be pretty widespread. > > Is anybody else seeing the same thing? Any thoughts on what's going on? > Or should I just be ignoring this and getting on with the weekend? > > Jim >

4 6

Looking for a Google contact (peering frustrations)
by Jon Sands 27 Aug '19

27 Aug '19

AS397031 here, located in Telehouse (7 Teleport). We picked up a port on NYIIX specifically to peer with google and cloudflare. We were doing around 6gbps inbound from google over the NYIIX for some time then without warning google withdrew routes from us, I'm guessing because too much bandwidth over an IIX and they prefer a private interconnect at that point. So we requested to peer with them via a PNI and were denied, saying they can't do that either as they're not located in any Telehouse buildings. So I'm left with no Google peering A 10gb wave from where we are to the nearest google peering point is basically the same cost as 10gbps from HE, so trying to figure out my best options here. Open to suggestions! Ideally we would love to peer with google again over NYIIX if possible. -- Jon Sands MFI Labs https://fohdeesha.com/

2 3

Facebook launches alerts for local first responders
by Sean Donelan 27 Aug '19

27 Aug '19

Facebook announced its new Local Alerts feature. Potential uses include storm warnings and advisories for extreme temperatures, evacuations, road closures, active shooter situations, bomb threats, missing person reports, water main breaks and more. The aim is to keep its users “safe and in-the-know.” https://www.washingtonpost.com/weather/2019/08/27/facebook-launching-local-… The Facebook Local Alerts appears to be a closed, walled-garden system, requiring local emergency managers to setup and maintain Facebook accounts. Emergency managers have used multiple social media platforms for several years, but its always a bit hit&miss reaching the public using different platforms. Smart assistants like Alexia, Google Assistant, Apple Siri or streaming services like Netflix and Hulu don't don't proactively provide local emergency alerts like Cable, TV and radio broadcasters. If you need to ask Alexa if there is a tornado warning, you probably already know there is a tornado.

1 0

IP Route Hijacking Bad Actor: AS57129/RU-SERVERSGET-KRSK, RU/Optibit LLC
by Paul Ferguson 26 Aug '19

26 Aug '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Howdy, I'm soliciting any background information, anecdotes, shared experiences, previous evidence, etc. of bad behavior and/or IP route hijacking for this 'hijack factory', as I've heard it called privately. They are actively -- and illegitimately -- announcing prefixes which are (legitimately) allocated to other organizations, a couple of them are very large & well-known U.S. healthcare providers. I'd also be interesting in hearing suggestion on the course of action one of these organizations might take to make this stop.... Thanks in advance, - - ferg - -- Paul Ferguson Seattle, WA USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAl1i4CEACgkQKJasdVTchbJVHAEA0s7Ej73VPQth2Rho4xwTnv8e qQFJ6SB+qulM1HFHoUgA/RXAL1BFJC3wq9GsXYJ4sqLSrje/gPm1JzVMeEJMTGlQ =r3mY -----END PGP SIGNATURE-----

2 1

SLA language about monitoring route leaks and inter-connection issues
by Sean Donelan 26 Aug '19

26 Aug '19

Do any major ISPs have SLA language about monitoring inter-provider agreements for route hijacking, route leaks, address spoofing, and so on? I'm looking for something more proactive than waiting for a customer to notice a problem and open a trouble ticket.

3 3

DNS cache hold of SERVFAIL responses
by Stephen Satchell 25 Aug '19

25 Aug '19

This is for any Google admin on this list: When you receive a SERVFAIL from a name server listed as authoritative for a given domain, how long is that negative look-up cached? When you receive a SERVFAIL from the root servers, how long is that negative lookup cached? Does Google follow RFC 2308? Is there a common cache for all resolvers, or do each resolver in your DNS server corps maintain a local cache? When a SOA (when you see one) says 14400 for the minimum TTL (or negative cache TTL) does Google honor that hold time?

1 0