- Test - lists.nanog.org

Amazon warehouse WAN contact
by Derek Dolan 29 Oct '19

29 Oct '19

I know this is a long shot, but if anyone from Amazon here would be willing to talk to me about your warehouse WAN connectivity in the Dallas-Fort Worth area, I would appreciate it. Working with the DFW Airport District is impossible, and I'd like to chat with someone with the power to make them do things (like Amazon) and how they pulled it off. Thanks, Derek

1 0

Verizon help
by JASON BOTHE 29 Oct '19

29 Oct '19

Hi all Is there anyone on from Verizon that could contact me off list in regards to provisioning for 701? Being here at NANOG77 and sorting face to face is a bonus. Thanks Jason

1 0

California network infrastructure status (FCC)
by Sean Donelan 29 Oct '19

29 Oct '19

>From the DIRS FCC report for October 29, 2019 https://www.fcc.gov/document/ca-power-shutoff-communications-status-report-… Cable and wireline services (combined): 223,937 subscribers out of service, down from 454,722 yesterday. I assume this only includes outages due to loss of outside plant and hub offices. It does not included Customer Premise Equipment (CPE) outages due to loss of power at the subscriber's premises. Broadcast services: 21 FM radio stations reported out of service, with 2 FM radio stations programming carried on another station 3 AM radio stations reported out of service No TV stations reported out of service (I have seen twitter reports of at least one TV station off the air) Most broadcasters are not reporting (up or down). Wireless services 463 cell sites out of service of 26,120 sites in all reporting counties. Top 5 counties by percentage out of service: 1. Marin County: 35.4% out of service (95 out of 268 sites) 2. Calaveras County: 32.6% out of service (14 out of 43 sites) 3. Sonoma County: 22.4% out of service (95 out of 424 sites) 4. Napa County: 15.6% out of service (20 out of 128 sites) 5. Lake County: 13.0% out of service (7 out of 54 sites)

1 0

Re: SP 800-189 (Draft), Resilient Interdomain Traffic Exchange
by Sriram, Kotikalapudi (Fed) 29 Oct '19

29 Oct '19

I think Doug has already pointed to this: Email for comments: sp800-189(a)nist.gov mentioned in the link: https://csrc.nist.gov/publications/detail/sp/800-189/draft We are thankful that many helpful comments/suggestions were received from ISPs, other organizations and individuals earlier on the 1st (initial) public draft. For anyone interested to peruse .... those comments and authors' responses are compiled here: https://csrc.nist.gov/CSRC/media/Publications/sp/800-189/archive/2018-12-17… We are now welcoming comments on 2nd draft. Sriram -------------------------------------------------------------------------- Date: Mon, 28 Oct 2019 16:09:54 -0500 From: Job Snijders <job(a)ntt.net> ... Dear Douglas, Thanks for sharing the link. This is an impressive effort! Can you share with the group what the best way is to share feedback to effect changes in the document? Is there a difference between just emailing you or are there official channels to be considered? Kind regards, Job

1 0

fuzzy subnet aggregation
by Joe Maimon 29 Oct '19

29 Oct '19

Does anyone have or seen any such tool? I have a script that seems to work, but its terribly slow. Currently I can produce aggregated subnets that can be mising up to a specified number of individual addresses. Which can be fed back in for multiple passes. Doing RTBH on individual /32 does not scale well, if you are eyeing collaboration with external lists. I have found likely sources that could produce another 100k prefixes easily. Joe

8 13

SP 800-189 (Draft), Resilient Interdomain Traffic Exchange
by Montgomery, Douglas C. (Fed) 28 Oct '19

28 Oct '19

https://csrc.nist.gov/publications/detail/sp/800-189/draft / This document provides technical guidance and recommendations for technologies that improve the security and robustness of interdomain traffic exchange. Technologies recommended in this document for securing the interdomain routing control traffic include Resource Public Key Infrastructure (RPKI), BGP origin validation (BGP-OV), and prefix filtering. Additionally, technologies recommended for mitigating DoS and DDoS attacks include prevention of IP address spoofing using source address validation with access control lists (ACLs) and unicast Reverse Path Forwarding (uRPF). Other technologies such as remotely triggered black hole (RTBH) filtering, flow specification (Flowspec), and response rate limiting (RRL) are also recommended as part of the overall security mechanisms. dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST

2 2

Unable to email anyone from my primary domain name; thanks Google Mail and G Suite.
by Constantine A. Murenin 28 Oct '19

28 Oct '19

Dear NANOG@, I'm not sure where else to post this, and this is not really new, either, but I think I have a new take here. I use my own personal domain name for various UNIX stuff, including sending log-related things to myself out of cron, which end up in my own Gmail.com account, either directly, or through forwarding (w/o SRS). (I do not use G Suite for my own domain name, for obvious reasons; just the consumer-based gmail.com email address from the old times of invitation-based registrations.) Over the years, I sometimes had certain messages rejected by Gmail, but it was a very low rate of rejection (less than 5% for any mail I cared about), and wasn't a major problem (usually only some automated messages would be rejected). A couple of months ago, I setup some new scripts that would send me new nightly emails. It's all plain text, but had a few dozen of domain names present (it's logs). Absolutely no links, just plenty of domains which I don't control. So, Gmail has been presenting most of these messages with their red warning label that the email contains malicious links, even though all of these emails contained zero links, zero URLs to any of these unknown domain names, zero URL schemes, zero "http://", zero "https://" etc. You get the idea. Since about a few weeks ago, I am now seeing at least a 95% rejection rate for my domain name, for ALL email, including the forwards. Including emails which I send to myself from within Google, and which get forwarded back to Gmail by my UNIX machine (which is not known to break Gmail's DKIM, either, although it's also difficult to test, because when it does get through, it's automatically marked as a duplicate by Gmail, so, you don't get DKIM status from Gmail by looking at the headers, since you only get to examine the original copy that was sent, not the forwarded duplicate that was subsequently accepted). I.e., emails with a passing DMARC still get rejected. The funny thing is, Google doesn't actually blacklist my primary IPv6 address in my own /48 from which all of my messages originate; even though the rDNS resolves to a subdomain on the very same domain name which they've blacklisted "due to the very low reputation". They've blacklisted just the main domain name that I use for my own non-Gmail-hosted mail. Sending the same messages into my Gmail.com from a different domain name in MAIL FROM, which is served from the same zone file DNS-wise (e.g., an SPF pass), through sendmail's `-f` option, or with Mutt, makes the messages go through (even with rDNS being "low reputation"); sending it from my primary domain name in MAIL FROM results in the following: >>> DATA <<< 550-5.7.1 [2001:470:xxxx:: 19] Our system has detected that this message is <<< 550-5.7.1 likely suspicious due to the very low reputation of the sending <<< 550-5.7.1 domain. To best protect our users from spam, the message has been <<< 550-5.7.1 blocked. Please visit <<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more information. 135si403977wma.43 - gsmtp 554 5.0.0 Service unavailable The support article suggests using Postmaster Tools; great, never heard of it, sounds cool; let's verify our domain, and try it out, hopefully, there's a solution right there. However, after verifying my domain name through DNS for Postmaster Tools, it is revealed that Postmaster Tools cannot tell me anything at all, with all tabs and screens being 100% blank, allegedly because I'm not actually a mass email sender (I don't send hundreds of emails a day or whatnot), and they're too afraid that I'll figure out why my mail doesn't actually go through, instead of signing up for G Suite. Right now, I've had a business need to reply to a work-related email from some other business. This is what I got after sending my reply from my primary domain name through mutt — a nice double rejection by both the G Suite and Gmail in a single bounce generated by my server: ----- Transcript of session follows ----- ... while talking to aspmx.l.google.com.: >>> DATA <<< 550-5.7.1 [2001:470:xxxx:: 19] Our system has detected that this message is <<< 550-5.7.1 likely suspicious due to the very low reputation of the sending <<< 550-5.7.1 domain. To best protect our users from spam, the message has been <<< 550-5.7.1 blocked. Please visit <<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more information. z11si12494671wrw.137 - gsmtp 554 5.0.0 Service unavailable ... while talking to gmail-smtp-in.l.google.com.: >>> DATA <<< 550-5.7.1 [2001:470:xxxx:: 19] Our system has detected that this message is <<< 550-5.7.1 likely suspicious due to the very low reputation of the sending <<< 550-5.7.1 domain. To best protect our users from spam, the message has been <<< 550-5.7.1 blocked. Please visit <<< 550 5.7.1 https://support.google.com/mail/answer/188131 for more information. 135si403977wma.43 - gsmtp 554 5.0.0 Service unavailable Changing MAIL FROM into a non-primary domain name (served out of an identical zone file, basically) gets the message accepted, without DKIM, without the 4-minute delay that many "suspicious" messages have had for months now, from the very same IPv6 address with the rDNS pointing to the domain name with "the very low reputation", and it shows up in both my own Gmail as well as, presumably, in the G Suite account of the business partner I was replying to. (Note that this trick where the rDNS domain gets ignored works only for new emails with a passing SPF; I presume the rDNS still prevails in bringing the "low reputation of the sending domain" for forwards, as they don't seem to succeed any longer now.) There are a number of possible tl;dr: takeaways here: * don't spread the monoculture — don't use G Suite for your organisation; * don't send crontab output to your Gmail from your primary domain name; * don't use Gmail. What is my own takeaway here? * Without being an anti-Google zealot, from a purely practical perspective, since my Gmail account no longer contains the mail I care most about, as it gets rejected on the SMTP layer, I'll have fewer reasons to use it. * I'll now have no other choice but to modify my setup to stop forwarding to Gmail, because my business contacts don't need to see all these bounces that are now taking place. * Since so many businesses are G Suite useds, I'm still looking for a solution to get rid of the "the very low reputation of the sending domain" from a domain name I've been using since 2007, and which I'm 100% convinced was blacklisted by Google entirely for me sending crontab with system logs (zero HTML, zero URLs) to my own Gmail. I have SPF and DMARC all setup and passing since years ago, which doesn't stop this issue from occurring. Merely switching the name of the domain in From and MAIL FROM to any other domain I own (which points to the very same MX) appears to be my workaround for now. Some possible suggestions for Google, if I may: * Maybe don't convert schemeless domain names which are non-URLs into "malicious" URLs? (They already do seem to block them from being presented as links in the UI in such an instance, but there's little reason for trying to convert these domain names into links in the first place.) * Maybe don't consider harmless plain text emails with a bunch of domain names to contain malicious links when they don't? * Maybe don't assume everyone with a domain name runs a G Suite? (Their whole troubleshooting guide is built around it.) * Maybe don't assume everyone with a domain name sends hundreds of emails from their domain name per day? (They seem to limit Postmaster Tools based on such a criterion.) * Maybe don't blacklist a domain name for sending harmless logs to a Gmail account that lists said domain name as an alternative From address? Cheers, Constantine.

14 18

IPv4 and Auctions
by Matt Hoppes 28 Oct '19

28 Oct '19

A thought crossed my mind the other day as I was having a discussion with someone. Every entity is suppose to justify their need for IPv4 address space from ARIN. This was always (in recent history) the case. No entity is suppose to be given more IPv4 space until they have nearly exhausted their previous space. How is it, then, that we daily for the last 2-3 years have places like Hilco that have sometimes 15-20 large IPv4 blocks up for auction? Supposedly we are completely out of IPv4 space, yet every day large blocks are being sold for money, yet they were never returned because they weren’t needed. Another thought: being that IPv4 address space is essentially leased to you from ARIN, can you even legally auction your space to someone else? I know it’s happening, but it would almost be like me auctioning my apartment to another random person.

14 20

California network infrastructure report (FCC)
by Sean Donelan 28 Oct '19

28 Oct '19

According to reporting to the FCC: https://www.fcc.gov/document/ca-power-shutoff-communications-status-report-… Cell sites out of service: overall 2.4% (630 out of 25,893) Marin County: 49.6% out of service (105 out of 270) Lake County: 19.3% out of service (11 out of 57) Calaveras County: 18.6% out of service (8 out of 43) Sonoma County: 17.1% out of service (73 out of 427) Santa Cruz County: 16.4% out of service (35 out of 213) Cable and Wireline systems (combined) 393,735 subscribers out of service. Only Outside Plant and Hub locations. Likely does not include loss of Customer Premise Equipment (CPE) power. Broadcast 4 FM radio stations out of service, 2 FM stations with programming sent to another station.

2 1

U.S. Senate: READI Act 2019 re-introducted
by Sean Donelan 28 Oct '19

28 Oct '19

U.S. Senators Brian Schatz (D-Hawaii) and John Thune (R-S.D.) reintroduced the Reliable Emergency Alert Distribution Improvement (READI) Act today (October 24, 2019). The READI Act would: [...] Explore establishing a system to offer emergency alerts to audio and video online streaming services, such as Netflix and Spotify; [...] The READI Act is support by NCTA – The Internet and Television Association, the National Association of Broadcasters (NAB), the Internet Association, CTIA – The Wireless Association, and the Wireless Infrastructure Association. Due to its bi-partisan co-sponsors and industry support, this bill is likely to pass. As I've stated before, I think network emergency alerts should be built into the underlying smart assistant layer (i.e. apple siri, amazon echo/fire, roku, google/nest home, etc.) instead of each content provider or internet provider.

4 11