October 2019 - Test - lists.nanog.org

Re: IP Geolocation
by Paul Farag 16 Oct '19

16 Oct '19

Is this an indication of a prefix that was highjacked? Sent from my iPhone > On Oct 14, 2019, at 9:19 AM, Ben Cannon <ben(a)6by7.net> wrote: >

4 3

Anyone noticing any odd latency/bandwidth congestion going on in Seattle?
by Brielle 16 Oct '19

16 Oct '19

Hi all, I've suddenly started showing high latency in Seattle off of CenturyLink in Boise going to Comcast in Denver. Boise fiber to Denver... traceroute to 50.239.215.xxx (50.239.215.xxx), 30 hops max, 60 byte packets <trimmed> 4 sea-brdr-02.inet.qwest.net (67.14.41.194) 12.394 ms 12.348 ms 12.369 ms 5 be-203-pe02.seattle.wa.ibone.comcast.net (96.87.10.117) 109.073 ms 109.530 ms 109.476 ms 6 be-10847-cr01.seattle.wa.ibone.comcast.net (68.86.86.225) 110.906 ms 111.427 ms 110.642 ms 7 be-10820-cr01.champa.co.ibone.comcast.net (68.86.84.206) 125.245 ms 126.605 ms 126.492 ms 8 68.86.92.130 (68.86.92.130) 124.478 ms 124.533 ms 124.518 ms 9 ae-1-rur02.wheatridge.co.denver.comcast.net (162.151.51.18) 125.846 ms 126.010 ms 126.353 ms 10 ae-11-sur02.wheatridge.co.denver.comcast.net (162.151.51.146) 125.630 ms 125.480 ms 125.397 ms 11 * * * 12 * * * Reverse path from Denver Comcast to Boise CenturyLink... traceroute to xxxxxxxxxxxxx (205.xxx.xx.xx), 30 hops max, 38 byte packets <trimmed> 6 be-12176-pe02.910fifteenth.co.ibone.comcast.net (68.86.83.94) 0.916 ms 0.983 ms 1.021 ms 7 dvr3-brdr-01.inet.qwest.net (72.164.247.149) 0.864 ms 8.534 ms 0.805 ms 8 * * * 9 63-224-242-xx.dia.static.qwest.net (63.224.242.xx) 125.355 ms 125.681 ms 125.404 ms 10 63.147.164.xx (63.147.164.xx) 125.006 ms 125.590 ms 125.817 ms 11 * * * 12 * * * I've got two CL fiber connections here in Boise - one with BGP for my own block, the other with a CL provided IP block. Both showing same results. Also have a CL fiber connection in Cheyenne, and it does not show any issues going to Boise or Denver. Are we still seeing after-effects from the gaming thing last night? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org

1 0

Video Streaming Wars
by Rod Beck 15 Oct '19

15 Oct '19

https://www.lightreading.com/video/ott/whats-at-stake-as-the-streaming-batt… [https://img.lightreading.com/2019/10/754841/3383.jpg]<https://www.lightreading.com/video/ott/whats-at-stake-as-the-streaming-batt…> What's at Stake as the Streaming Battle Builds | Light Reading<https://www.lightreading.com/video/ott/whats-at-stake-as-the-streaming-batt…> Netflix, Amazon and Hulu have staked out their turf in the subscription VoD market, but will they be able to hold that coveted ground as Disney, Apple, WarnerMedia and NBCU enter the streaming fray? www.lightreading.com Roderick Beck VP of Business Development United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com 36-70-605-5144 [1467221477350_image005.png]

3 2

lots of traffic starting at 3 a.m. central time
by Aaron Gould 15 Oct '19

15 Oct '19

Anyone else see lots of traffic coming down starting at 3 a.m. central time ? all of my internet connections showed strangely larger load for a few early morning hours. I have some info that tells me what it was but wanted to hear it from others too. -Aaron

7 6

Problems sending emails to AT&T
by Grzegorz Janoszka 15 Oct '19

15 Oct '19

Hi, Whenever I try to send something to emails in @att.net I get a reply: host ff-ip4-mx-vip1.prodigy.net[144.160.159.21] said: 553 5.3.0 flph831 DNSBL:RBL 521< MY.IP4.ADD.RES >_is_blocked.For assistance forward this error to abuse_rbl(a)abuse-att.net (in reply to MAIL FROM command) Of course emails to abuse_rbl go unanswered. My IP turns clean on https://www.dnsbl.info/ (all green and one blue timeout). Anyone had such issues? Any working contacts to AT&T email? Any help appreciated. -- Grzegorz Janoszka

1 0

APRICOT 2020 Call for PC Volunteers
by Mark Tinka 14 Oct '19

14 Oct '19

Hi everyone, The APRICOT 2020 Programme Committee is responsible for the solicitation and selection of suitable presentation and tutorial content for the APRICOT 2020 conference (https://2020.apricot.net/) The APRICOT PC Chairs are now seeking nominations from the community to join the APRICOT 2020 PC to assist with the development of the programme for APRICOT 2020. Eligible PC candidates are those who have attended APRICOT conferences in the recent past, have broad technical knowledge of Internet operations, and have reasonable familiarity with the format of APRICOT conferences. Having constructive opinions and ideas about how the programme content might be improved is of high value too. PC members are expected to work actively to solicit content and review submissions for technical merit. The PC meets by conference call, weekly in frequency during the three months prior to APRICOT. If you are interested in joining the PC and meet the above eligibility criteria, please send a brief note to "pc-chairs at apricot.net". The note should include affiliation (if any) and contact details (including e-mail address), and a brief description of why you would make a good addition to the PC. PC members who are active, successfully solicit content, contribute to regular PC meetings and submit reviews receive complimentary registration for APRICOT 2020. The PC Chairs will accept nominations received by 17:00 UTC+8 on Monday 21st October, 2019, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka, Marijana Novakovic & Philip Smith APRICOT 2020 PC Chairs

1 0

.COM Zone DNSSEC Operational Update -- ZSK length change
by Wessels, Duane 14 Oct '19

14 Oct '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, Verisign is in the process of increasing the size and strength of the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that it operates. As part of this process, the ZSK for the .COM zone will be increased in size from 1024 to 1280 bits. On October 10, 2019 the 1280 bit ZSK was pre-published in the .COM zone. On October 15, we plan to sign the .COM zone with the 1280 bit ZSK. On October 20, we plan to remove the old 1024 bit ZSK from the zone. We do not anticipate any problems from this upgrade. In accordance with our normal operating procedures we have a rollback process should it become necessary to revert to the 1024 bit ZSK. DW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJdpL5zAAoJEGyZpGmowJiNKZsH/3D1uNJ959pOoZjiRWHd/bZ5 V6mNXkKA34jKudC0ugPt1RQGEExspsNHBTjSK//SO+nayKl8GQUdrnL5AINJKQjU C61nhFORQXxhrE7JTbbbLeiVWVMwBhWmefi9zNIi/2MANWhX0UzuKREfsAnUgyVL 9mbfxxFCmAC6HPVkE3wZS5Z8h+3AP4zkctLOWQv/wi0aCd6o6/k9fejpmN2YhFQy 7OrFqKpTq0wa7K1zx8xXyBNPstWlH0709zn3Cm6aYkQ7mLoCNl2H6ODJCmvtTZeo BYVKGojABUWXAurOiPSaljGHRAEC1sN5cV5rkeWmXjoRo+dGPOA60bzbdNsTfss= =J3+s -----END PGP SIGNATURE-----

1 0

New telemetry system ideas
by Chris Misa 14 Oct '19

14 Oct '19

I am a researcher working on developing a new switch-based on-the-fly telemetry system that takes a flow chart as input to describe a particular detection task (rather than just features or information elements as in IPFIX). For an example of what I mean by "flow chart" see the figure here: https://ieeexplore.ieee.org/mediastore_new/IEEE/content/media/8048782/80488…. Might anyone have pointers to a source of more such flow charts? The other issue I'm worried about is that it might take a couple rounds before an event is detected (since the system has to step through the flow chart and possibly look at different traffic features in the process). What is a typical duration of the types of events people might want to catch with a telemetry system like this? Do these kind of events generate the same type of traffic throughout their durations, or do traffic features change as the event progresses? Thanks! Chris

1 0

IP Geolocation
by Travis Garrison 14 Oct '19

14 Oct '19

Anyone else have issues where their IP block gets randomly set to China? We have been trying to track down this issue for months and our customers are starting to get upset. We get a /29 from our upstream provider that we CGNAT (yeah I know, working on implementing IPV6) to all of our customers at 1 particular site. No other sites have any issues. We had our upstream provider allocate us a new IP block from a different subnet which fixed the issue for a while but now it's back. The state and town are correct but the country states China. This is having issues with Speedtests, NetFlix and others. The upstream is claiming that we are purposely using a proxy or VPN to china which causes this. We have checked all our configurations and even replaced all hardware in case something was hacked. Any ideas? Thanks Travis Garrison

4 3

Cogent & FDCServers: Knowingly aiding and abetting fraud and theft?
by Vivek Nigam 12 Oct '19

12 Oct '19

Hi Ronald, APNIC has contacted the custodians of 139.44.0.0/16 and 168.198.0.0/16 and brought this matter to their attention. Regards, Vivek Member Services Manager, APNIC From: Ronald F. Guilmette <rfg(a)tristatelogic.com> Date: Fri, Sep 6, 2019 at 6:30 PM Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? To: <nanog(a)nanog.org> Few of you here probably know about this, but nearly a week ago now an article appeared in South Africa's largest and most popular online tech publication, MyBroadband.co.za. It detailed many, but certainly not all of the results of my multi-month investigation of a massive and ongoing fraud involving the theft of large numbers of large (generally /16 or larger) abandoned legacy blocks, taken from the AFRINIC region and beyond: https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-add… For various editorial reasons, the article that was published actually downplayed the magnitude of the of the thefts quite dramatically. The totality of the IPv4 space that has been stolen or squatted, primarily but not exclusively, from South African companies and South African national goverment agencies and departments is actually at least 5x bigger than what was reported in the MyBroadband.co.za article. The overwhelming majority of this stolen and squatted IPv4 space has been helpfully routed by Cogent (AS174), to their customer, FDCServers of Chicago, and then on to the prefered destinations of a certain Mr. Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have saved traceroutes up the wazoo that prove the involvement of FDCServers, in particular, in all of this.) Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting activities, basically grabbing everything that wasn't nailed down, both within the AFRINIC region and also within the APNIC region. In order to try to legitimize all of these thefts and squats, Mr. Cohen created quite a sizable number of fradulent route: objects within the Merit/RADB data base which, as most here should already know, has essentially zero authentication of any kind before it allows J. Random Luser to add pretty much any any route: object he wants to the RADB. Here's a full listing of all of Mr. Cohen's RADB route: objects as they existed as recently as August 17th: https://pastebin.com/raw/ZNgNuvtt And here is the short summary version showing just all of the prefixes/CIDRs that Mr. Cohen was effectively claiming rights and/or title to as of that same date: https://pastebin.com/raw/4LTaCg5R Plese do note the numerous blocks of size /16 or greater. The bottom line is that this one tiny little Israeli company was effectively claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of August 17th, 2019. (Not too shabby for one lone guy who teaches programming classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, and generally consists of blocks having sizes of /16 or larger. Some of Mr. Cohen claims in his RADB entries are as humorous as they are pathetically fradulent. For example, Mr. Cohen has effectively claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port Authority of the City of Melbourne, Australia. But hell! That's merely city property! Mr. Cohen's limitless appetite for other people's IPv4 space is more vividly on display in his claims to ownerhip over the 168.198.0.0/16 block, which actually belongs to the Department of Finance of the Australian national government. And I haven't even mentioned yet another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, which he did not see fit to create an RADB entry for, but which he's been squatting on for for quite some time now, quite clearly with the aid and assistance of both Cogent and FDCServers. That one belongs to th City of Cape Town, South Africa. That city's engineers have been struggling to regain control of their block back from Cogent, from FDCServers, and from Mr. Cohen for some time now. I know because I've personally spoken to them about it. Cogent, in its infinite wisdom, is continuing to fight the city for control over property that clearly and righfully belongs to the City of Cape Town, even as we speak: https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view When asked for LOAs attesting to his legitimate authority to route at least a few of these blocks, Mr. Cohen has produced blatantly forged documents, many of which appeared in the MyBroadband.co.za story. And when I say "blatant" that's a gross understatement. Any half-way decent forger would consider these documents an embarrasment. The documents all bear identical signatures, and identical and vaguely official looking stamps, and purport to actually be sales reciepts attesting to the alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell company, Afri Holdings, Ltd., of various /16 blocks from a mysterious company called Afrivestment, Ltd., which may actually exist in some faraway galaxy, or in Mr. Cohen's active imagination, but which both Google and OpenCorporates.com seem to agree exists exactly noplace on this planet. Here are the manufactured LOAs supplied by Mr. Cohen: https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view Recently, Cohen started to move some, but not all, of his stolen and squatted IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, coincidently, just happen to be owned by the exact same pair of Dutch gentlemen who previously owned the notorious Ecatel, follwed by the notorious Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly all of its legitimately assigned IP space from its predecessor entities, Ecatel and Quasi Networks.) Despite these relocations, many of Mr. Cohen's stolen and squatted blocks are still helpfully being routed to Mr. Cohen's preferred desitnations by his good friends at Cogent and FDCServers, even as we speak. The current set of such routes that Cogent is maintaining, at the moment, apparently on behalf of their customer, Mr. Cohen, consists of the prefixes listed here: https://pastebin.com/raw/EA3xJVLF When I noticed two days ago that all of these routes were still up I was deeply confused. Did both Cogent and FDCServrs not get the memo?? Do they not know yet that Cohen is stealing stuff, left, right, and sideways? Did nobody even tell them about the MyBroadband.co.za article which was published this past Sunday? I decided that it was incumbant upon me to find out. Thus, more that 48 hours ago now I sent the following polite but firm inquiry to Cogent, and a separate nearly identical one directly to the CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net) https://pastebin.com/raw/ztipqE96 A full forty eight hours later, I have received no reply whatsoever from either Cogent or FDCServers, not even a "Go pound sand" type of response. More importantly, most of the stolen IPv4 space that I called out, very specifically, to both Cogent and FDCservers two+ days ago now is still being routed by Cogent/FDCservers to their fun-loving and, I'm sure, promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers still do not know now that Mr. Cohen is a crook, and that he has glommed onto quite a lot of stolen and squatted IPv4 space... which they have been helpfully routing for him, no doubt in exchange for some handsome payments... then I am foreced to say that it appears to be a reasonable conclusion that it must be because neither Cogent nor FDCServers really wants to know what sort of a character Cohen is, or what he has been up to, specifically with their ongoing and material assistance. But you all be the judges. What does it look like to you? Regards, rfg

7 11