August 2019 - Test - lists.nanog.org

FCC: December 27, 2018 CenturyLink Network Outage Report
by Sean Donelan 20 Aug '19

20 Aug '19

The FCC announced the release of a report detailing the cause and impact of a nationwide CenturyLink network outage that occurred last December, along with recommendations to help prevent similar outages from occurring in the future https://www.fcc.gov/document/fcc-issues-report-centurylink-network-outage December 27, 2018 CenturyLink Network Outage Report In the early morning of December 27, 2018, CenturyLink experienced a nationwide outage on its fiber network that lasted for almost 37 hours. This outage was caused by an equipment failure catastrophically exacerbated by a network configuration error. It affected communications service providers, business customers, and consumers who directly or indirectly relied upon CenturyLink’s transport services, which route communications traffic from various providers to locations across the country, resulting in extensive disruptions to phone service, including 911 calling. The effects included dropped calls, disconnected 911 call centers (known as “Public Safety Answering Points”), and fast-busy signals for people who called 911. As many as 22 million customers across 39 states were affected by the outage, including approximately 17 million customers across 29 states who lacked reliable access to 911. Indeed, at least 886 calls to 911 were not delivered.1 Fortunately, based on discussions with affected service providers and public safety officials from affected states, as well as a review of media reports, the Public Safety and Homeland Security Bureau (Bureau) is not aware of any harm to life or property resulting from the outage. [...]

1 0

SMF Tie Cable Standards for Data Center Applications
by Chris Costa 19 Aug '19

19 Aug '19

In our new data center builds we're transitioning from MMF to SMF for the tie cabling between networking gear in the MDF/IDF racks to the server racks. Today those interconnects are short (under 100 meters) 10GE and 40GE-LX4 over MMF. We’re transitioning to SMF to support services beyond that, such as 100GBASE-LR4. Would G.652.D be the right specification for the infrastructure tie cabling? Are there other considerations around this? Thank you

1 0

Re: syn flood attacks from NL-based netblocks
by Töma Gavrichenkov 19 Aug '19

19 Aug '19

On Mon, Aug 19, 2019, 9:24 PM Florian Brandstetter <florianb(a)squareflow.net> wrote: > Load balancing is done on Layer 4 or Layer 3 when routing, so your > ingress connection will have the same hash as the outgoing connection > (unless the source port of the connection changes on the ACK - which it > really should not). > If the hash is symmetric, yes. No wonder topology issues would have more impact, my point was that there are also other things to look at here. -- Töma >

1 0

syn flood attacks from NL-based netblocks
by Jim Shankland 19 Aug '19

19 Aug '19

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

12 25

Centurylink Looking Glass fail
by Ca By 19 Aug '19

19 Aug '19

Paging someone at Centurylink to fix your looking glass. https://lookingglass.centurylink.com None of the functions in any of the cities work Your network is kind of a big deal, so please try to provide visibility to your routing state so the rest of us can do our day-job, on Sunday

2 1

new BGP hijack & visibility tool “BGPalerter”
by Job Snijders 16 Aug '19

16 Aug '19

Dear NANOG, Recently NTT investigated how to best monitor the visibility of our own and our subsidiaries’ IP resources in the BGP Default-Free Zone. We were specifically looking how to get near real-time alerts funneled into an actionable pipeline for our NOC & Operations department when BGP hijacks happen. Previously we relied on a commercial “BGP Monitoring as a Service” offering, but with the advent of RIPE NCC’s “RIS Live” streaming API [1] we saw greater potential for a self-hosted approach designed specifically for custom integrations with various business processes. We decided to write our own tool “BGPalerter” and share the source code with the Internet community. BGPalerter allows operators to specify in great detail how to distribute meaningful information from the firehose from various BGP data sources (we call them “connectors”), through data processors (called “monitors”), finally outputted through “reports” into whatever mechanism is appropriate (Slack, IRC, email, or a call to your ticketing system’s API). The source code is available on Github, under a liberal open source license to foster community collaboration: https://github.com/nttgin/BGPalerter If you wish to contribute to the project, please use Github’s “issues” or “pull request” features. Any help is welcome! We’d love suggestions for new features, updates to the documentation, help with setting up a CI regression testing pipeline, or packaging for common platforms. Kind regards, Job & Massimo NTT Ltd [1]: https://ris-live.ripe.net/

8 10

really amazon?
by Dan Hollis 16 Aug '19

16 Aug '19

Amazon, you really should know better. Source ip: 54.240.4.4 https://search.arin.net/rdap/?query=54.240.4.4 Source Registry ARIN Kind Group Full Name Amazon SES Abuse Handle ASA152-ARIN Email email-abuse(a)amazon.com >>> RCPT To:<email-abuse(a)amazon.com> <<< 550 #5.1.0 Address rejected. 550 5.1.1 <email-abuse(a)amazon.com>... User unknown >>> DATA <<< 503 #5.5.1 RCPT first Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: to=<email-abuse(a)amazon.com>, ctladdr=<goemon(a)sasami.anime.net> (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown

30 56

ARIN Fantasy WHOIS: NET-216-179-183-0-1
by Ronald F. Guilmette 16 Aug '19

16 Aug '19

As if to underscore the point I just tried to make about the fundamental unreliability of ARIN WHOIS records, I just stumbled onto this rather curious entity which was apparently given a sub-allocation of 216.179.183.0/24 beneath the 216.179.128.0/17 (Azuki, Inc.) block as of 2012-01-10: OrgName: Rogers Communications Inc OrgId: RC-82 Address: E 2nd St,Campbell City: Gillette StateProv: WY PostalCode: 82716 Country: US RegDate: 2012-01-10 Updated: 2012-01-10 Ref: https://rdap.arin.net/registry/entity/RC-82 Other that the fact that it has an oddly similar name to one of Canada's largest and most well-known Internet and cell phone companies, the only other thing that's rather remarkable about it is that it was given the 216.179.183.0/24 block, by Azuki, Inc. in 2012. What's odd about that? Well, only the fact that this *Wyoming* incarnation of Rogers Communications had apparently already died and gone to Valhalla some 14 years earlier, in 1998: https://wyobiz.wy.gov/Business/FilingDetails.aspx?eFNum=0700232420041061300… Moral of the story: Don't ever let anybody tell you that ghosts... even ghosts of long dead companies... aren't real or that they do not walk among us. Their immortal auras pervade the very ether we breath. And they have their own IPs, apparently. But, you know, if your customers are getting hack attacks emmanating from 216.179.183.0/24... well... to quote the old Ghostbusters tag line "Who you gonna call?" (Hint: Don't waste your time calling the number in the WHOIS record. It's just some bloody preschool.) Regards, rfg

3 2

Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17
by Ronald F. Guilmette 16 Aug '19

16 Aug '19

Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ) Quite simply, a party bent on undertaking this ploy may just search the publicly available IP block WHOIS records, looking for abandoned and unrouted IPv4 address blocks belonging to companies or organizations which no longer exist. Upon finding any such, the thief may simply undertake to formally register, with relevant government authorities, a new corporate entity with the same or a very similar name as the now defunct entity that is still listed in the WHOIS records as the registrant of the coveted IPv4 address block(s). Note that so-called "legacy" address blocks, i.e. those which were assigned prior to the formation of ARIN in early 1997, are especially prized by IPv4 address thieves because such blocks may be less subject to effective control or regulation by Regional Internet Registries. Publicly available evidence strongly suggests that a corporate identity theft has occurred with respect to a former Delaware corporate entity known as Azuki, LLC and also with respect to its valuable legacy IPv4 address block, 216.179.128.0/17. The corporate search function of the Delaware Secretary of State's web site may be used to obtain records relevant to corporate entities registered in Delaware: https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx At present, the Delaware SoS's web site indicates that there are or have been two different corporate entities, both named Azuki, LLC, that have been registered in the State of Delaware. The file numbers for these entities are 2810116 and 4751384. The former entity was first registered in Delaware on or about 10/20/1997. It's current operating status cannot be known without paying a fee. My own personal speculation is that it most likely ceased operation well more than a decade ago. The latter entity was registered in Delaware on or about 11/9/2009. According to the current live ARIN WHOIS record for the 216.179.128.0/17 address block (NET-216-179-128-0-1), this block was first allocated by ARIN to Azuki, LLC on or about 1999-01-07. Quite obviously, this assignment must have been made by ARIN to the original 1997 Azuki, LLC because the one that was registered in Delaware in 2009 did not yet exist at that time. Nontheless the mailing address currently present in the ARIN WHOIS record for the 216.179.128.0/17 IPv4 address block, and the one which is also present in the ARIN WHOIS record for the 2009 vintage ASN, AS13389 (Azuki, LLC), i.e. 3500 South DuPont Hwy, Dover, DE, 19901, matches exactly with the address given in Delaware corporate records for the particular Azuki, LLC that was registered in Delaware in 2009. (The corporate address that is still on file in Delaware for the original 1997 Azuki, LLC is located in a different Delaware city altogether.) These evident inconsistancies, by themselves, are strongly indicative of a probable case of corporate identity theft. Additional indicators are however also present in this case. In particular, the contact email address for both the Azuki, LLC ASN (AS13389) and the Azuki, LLC IPv4 address block (216.179.128.0/17), i.e. tech_dep (at) azukinet.com, make reference to the azukinet.com domain which was, according to the relevant GoDaddy WHOIS record, registered anew on or about 2011-05-12, some twelve years -after- the original assignment, by ARIN, of the 216.179.128.0/17 block to Azuki, LLC. The absence of evidence of the contnuous registration of this one and only contact domain name since the original 1999 assignment, by ARIN, of the 216.179.128.0/17 address block also tends to support the theory that this valuable address block has been illicitly and perhaps illegally appropriated by some party or parties unknown, and specifically via the fradulent ruse of a corporate identity theft. Quite simply, my theory is that following the demise of the original Azuki, LLC, sometime in the 2000s, some enterprising crook registered the domain name azukinet.com in order to successfully impersonate the actual and original Azuki, LLC, specifically when interacting with ARIN staff members. This simple ruse appears to have worked successfully for its intended purpose. Additionally, attempts to call the contact phone number for Azuki, LLC, (+1-213-304-6809) as currently listed in both the relevant ASN and the relevant IP block WHOIS records, during normal business hours, Eastern Daylight Time, yield only an anonymous answering machine recording. (The recorded message does not even state the company name.) This is yet another indicator of possible deliberate deception. Last but not least, the widely-respected Spamhaus anti-spam organization has had the entirety of the 216.179.128.0/17 block listed on its anti-spam SBL list since 2019-06-08, i.e. two full months, dating backwards from today: https://www.spamhaus.org/sbl/query/SBL103083 This listing, together with additional data from passive DNS and reverse DNS scans suggest that the 216.179.128.0/17 block has been and is being used for less than entirely admirable purposes. This is yet another persuasive indicator of the possible/probable theft of the block. I will shortly be informing both hostmaster (at) arin.net and also the folks at Spamhaus of all of the above factual findings. I did however want to share this information also with the NANOG community. Some or all of you may wish to drop all packets from addresses currently announced by AS13389, and/or may wish to encourage the direct peers of AS13389 to review those peering arrangements. Of course, my exposition of all of the above facts and indicators may perhaps also serve to further educate members of the community regarding what to look for when and if suspicions are cast upon a particular IP block or ASN. In the 2008 case referenced above, which involved self-evident corporate identity theft as a ruse to steal IPv4 address assets, ARIN apparently elected not to actively seek the involvement of law enforcement, even though the multiple clearly fraudulent actions undertaken in that case were altogether apparent and were clearly perpetrated quite deliberately and directly against ARIN. In multiple more recent instances in which ARIN has, allegedly, been targeted and defrauded, ARIN appears to have become more proactive in seeking the involvement of criminal law enforcement. Specifically, in addition to the well-publicized, notorious, and ongoing "Micfo" case, a less well reported federal criminal case (3:18-cr-04683-GPC), filed the Southern District of California last year, is currently ongoing. This case also and likewise attempts to hold to account, criminally, a different set of actors who also are alleged to have perpetrated a rather elaborate fraud against ARIN for the purpose of illicitly obtaining control over a number of IPv4 address blocks. Personally, I am gratified that ARIN is nowadays taking this more forward leaning posture towards those criminal actors who would attempt to use fraud and deception to surreptitiously obtain IPv4 address blocks. I do also hope that if the tenative conclusions of this public report are borne out by subsequent investigation, that ARIN will again and likewise seek an appropriate response from elements of the criminal law enforcement community. We cannot have and should not have these kinds of events happening again and again. Some appropriate deterrence against ALL of these kinds of crooks is therefore no longer optional. Regards, rfg

17 38

AT&T Wireless Calls Failing to Level - 3 DID's
by Ahmed Jalal 15 Aug '19

15 Aug '19

Hi, I am trying to get in touch with someone at AT&T to look into call failures to our DID's in the southern Mississippi region. Please let me know if I am in the wrong list. Any help would be greatly appreciated. Best Regards

2 1