- NANOG - lists.nanog.org

Re: Syn flood to TCP port 21 from priveleged port (80)
by Oleg A. Arkhangelsky 01 Nov '16

01 Nov '16

01.11.2016, 22:06, "Eric Tykwinski" <eric-list(a)truenet.com>: > Oleg, > > I'm seeing the same to a single client here source IPs seem to be matching up as well. > I attached a pcap, just so you can compare. > And the same sources: 141.138.128.0 - 141.138.135.255 194.73.173.0 - 194.73.173.127 95.131.184.0 - 95.131.191.255 Massive DDoS against William Hill Organization Ltd? -- wbr, Oleg. "Anarchy is about taking complete responsibility for yourself." Alan Moore.

1 0

Help interpret a strange traceroute?
by Randy 01 Nov '16

01 Nov '16

Happy monday all! Any idea how a traceroute (into my network) could end up this fubar'd? Discovered this wierd routing while investigating horrendously slow speeds (albeit no packet loss) to a particular ISP abroad. It's like - coming into us - the packets are taking every available path, simultaniously. Tracing back to him looks perfectly normal. Thank you in advance for any comments on or off list. Him to us: traceroute to mirror.ash.fastserv.com (208.85.240.29), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 1.552 ms 1.522 ms 1.261 ms 2 br1.l.hiweb.ir (46.224.0.12) 17.750 ms 18.932 ms 18.811 ms 3 172.16.5.65 (172.16.5.65) 18.505 ms 20.044 ms 18.414 ms 4 int.gr1.s.hiweb.ir (46.224.0.125) 19.096 ms 18.447 ms 18.752 ms 5 int.gr1.l.hiweb.ir (46.224.0.117) 18.454 ms 18.768 ms 103.441 ms 6 10.21.252.166 (10.21.252.166) 66.308 ms 18.728 ms 18.867 ms 7 * * * 8 185.100.209.139 (185.100.209.139) 162.126 ms ae5.istanbul1.ist.seabone.net (93.186.132.212) 210.124 ms 126.208 ms 9 et7-1-0.franco71.fra.seabone.net (195.22.214.131) 102.694 ms if-ae-9-3.tcore1.pvu-paris.as6453.net (195.219.87.14) 189.955 ms 185.100.209.197 (185.100.209.197) 218.539 ms 10 te0-3-0-4.rcr21.b023101-0.lon01.atlas.cogentco.com (149.14.144.89) 201.223 ms 215.996 ms 185.100.209.1 (185.100.209.1) 164.381 ms 11 if-ae-2-2.tcore2.av2-amsterdam.as6453.net (195.219.194.6) 199.161 ms be2950.ccr22.lon01.atlas.cogentco.com (130.117.2.109) 216.648 ms if-ae-3-6.tcore1.l78-london.as6453.net (80.231.130.85) 271.750 ms 12 if-ae-4-2.thar1.njy-newark.as6453.net (80.231.130.34) 183.984 ms * be2814.ccr42.ams03.atlas.cogentco.com (130.117.0.141) 109.045 ms 13 if-ae-1-3.thar2.njy-newark.as6453.net (216.6.57.2) 207.371 ms be2870.ccr41.lon13.atlas.cogentco.com (154.54.58.173) 186.804 ms be12488.ccr42.lon13.atlas.cogentco.com (130.117.51.41) 190.236 ms 14 if-ae-14-14.tcore2.nto-new-york.as6453.net (66.198.111.126) 203.156 ms if-ae-9-2.tcore1.n75-new-york.as6453.net (63.243.128.122) 273.177 ms be2807.ccr42.dca01.atlas.cogentco.com (154.54.40.110) 235.632 ms 15 66.110.96.134 (66.110.96.134) 182.695 ms be2806.ccr41.dca01.atlas.cogentco.com (154.54.40.106) 278.593 ms 240.075 ms 16 66.110.96.142 (66.110.96.142) 245.454 ms be3084.ccr41.iad02.atlas.cogentco.com (154.54.30.66) 191.973 ms be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54) 240.740 ms 17 te0-0-0-0.nr13.b023801-0.iad01.atlas.cogentco.com (154.24.36.18) 257.027 ms be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54) 236.617 ms hu-1-3-0-2-cr02.newyork.ny.ibone.comcast.net (68.86.83.97) 221.186 ms 18 be-10102-cr02.ashburn.va.ibone.comcast.net (68.86.85.161) 194.766 ms 250.493 ms be-10203-cr01.newark.nj.ibone.comcast.net (68.86.85.185) 191.052 ms 19 be-10102-cr02.ashburn.va.ibone.comcast.net (68.86.85.161) 197.694 ms te0-0-2-0.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.2) 266.914 ms 235.444 ms 20 te0-0-2-3.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.6) 255.756 ms 38.88.249.210 (38.88.249.210) 216.677 ms te0-0-2-0.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.2) 211.364 ms 21 208.85.240.29 (208.85.240.29) 274.692 ms 212.896 ms ash01-mls-dc-core-a.latisys.net (67.217.175.37) 208.976 ms And back to him: traceroute to 46.224.145.65 (46.224.145.65), 30 hops max, 60 byte packets 1 104.153.64.146 (104.153.64.146) 22.067 ms 22.049 ms * 2 xe-3-1-1.er1.iad10.us.above.net (208.185.24.1) 0.398 ms 0.392 ms 0.420 ms 3 zayo-tata.iad10.us.zip.zayo.com (64.125.13.170) 0.708 ms 0.580 ms 0.623 ms 4 if-ae-11-2.thar2.NJY-Newark.as6453.net (216.6.87.138) 92.900 ms if-ae-11-3.thar2.NJY-Newark.as6453.net (216.6.87.242) 92.802 ms if-ae-11-4.thar2.NJY-Newark.as6453.net (216.6.87.169) 97.177 ms 5 if-ae-1-3.thar1.NJY-Newark.as6453.net (216.6.57.1) 92.940 ms 93.008 ms 89.431 ms 6 if-ae-8-2.tcore1.LDN-London.as6453.net (66.198.70.174) 97.315 ms 96.049 ms 95.855 ms 7 if-ae-17-2.tcore1.L78-London.as6453.net (80.231.130.129) 98.074 ms if-ae-3-6.tcore1.PYE-Paris.as6453.net (80.231.130.86) 92.733 ms 92.898 ms 8 if-ae-2-2.tcore1.PVU-Paris.as6453.net (80.231.154.17) 93.636 ms if-ae-3-6.tcore1.PYE-Paris.as6453.net (80.231.130.86) 97.917 ms 98.363 ms 9 if-ae-2-2.tcore1.PVU-Paris.as6453.net (80.231.154.17) 100.909 ms if-ae-9-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.13) 92.055 ms 93.173 ms 10 195.219.87.46 (195.219.87.46) 208.894 ms 209.042 ms if-ae-9-2.tcore2.FNM-Frankfurt.as6453.net (195.219.87.9) 94.718 ms 11 * 195.219.87.46 (195.219.87.46) 209.640 ms int.gr1.s.hiweb.ir (46.224.0.118) 202.201 ms 12 int.cr1.s.hiweb.ir (46.224.0.126) 205.150 ms * * 13 * * * 14 int.gr1.s.hiweb.ir (46.224.0.118) 201.803 ms 201.799 ms int.cr1.s.hiweb.ir (46.224.0.126) 201.819 ms 15 int.cr1.s.hiweb.ir (46.224.0.126) 204.952 ms 198.969 ms * 16 46.224.145.65 (46.224.145.65) 210.507 ms 211.144 ms 206.998 ms

7 6

RE: IPv6 automatic reverse DNS
by Woodworth, John R 01 Nov '16

01 Nov '16

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of White, Andrew > > There are two competing drafts for synthetic rule-based PTR responses > for IPv6 rDNS: > > Howard Lee, Time Warner Cable (now Charter) > https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08 > > J. Woodworth, CenturyLink > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ > > Nominum and Xerocole/Akamai also have proprietary solutions to this > in their Vantio AuthServ and AuthX products, respectively. > > It seems to me that it is still an open question whether the > recommendations in RFC-1912 that any IP address that accesses the > Internet should have a PTR and matching forward record. My personal > thoughts are that the best solution would be an OPTIONAL standards-based > method of generating DNS responses based on a ruleset if a specific zone > record is not present, and that implementation of that requirement > should be left to the developers of the auth nameserver software. Greetings Andrew, I am new to the group but one of the authors referenced above. My colleagues and I are glad to see the discussion around this issue see some recent movement. As indicated by one of our esteemed WG chairs elsewhere in this thread, I am currently working to provide additional clarity for some of the more difficult concepts in the draft and have not yet requested the next step. Once these changes are complete we will enthusiastically move forward with this request. As I am new to this forum, for the moment I wanted to simply state: synthesized records based on the proposed "bulk rr" method can _only_exist_where_zone_records_do_not_already_. One critical goal of the draft is to make the "intent" of synthesized records easy to transfer between nameservers in authoritative roles. Examples for implementing the draft using fairly straightforward regex manipulation are included but are more of a guideline for making the pattern substitution easier for the implementor and provide a reference for the accompanying examples. Ultimately, as you recommend, the auth nameserver software vendor would be free to provide their own pattern substitution logic (so long as the intent is not lost). DNSSEC for synthesized records also poses its own obvious set of… complications for which we've outlined a number of solutions to help satisfy this challenge. Admittedly, it is a bit of a hefty read but we would love the feedback (directly or in the IETF DNSOP mailing list of course). Thanks, John Woodworth > > Andrew > > Caveat: These thoughts are mine personally and do not represent > any official position of Charter Communications. > > > Ληdrеw Whiте > Charter Network Operations - DAS DNS > Desk: 314-394-9594 ? Cell: 314-452-4386 > andrew.white2(a)charter.com > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

2 2

Re: Help interpret a strange traceroute?
by Larry Sheldon 01 Nov '16

01 Nov '16

On 10/31/2016 14:42, William Herrin wrote: > On Mon, Oct 31, 2016 at 3:33 PM, Randy <amps(a)djlab.com> wrote: >> Any idea how a traceroute (into my network) could end up this fubar'd? >> Discovered this wierd routing while investigating horrendously slow speeds >> (albeit no packet loss) to a particular ISP abroad. > > Hi Randy, > > This is per-packet load balancing. In the forward path the alternates > are different lengths but the traceroute stops as soon as at least one > of the paths reaches the destination. > > The return path is also engaged in per-packet load balancing but the > paths are all the same length. Seems like a lot of bandwidth trying to save bandwidth. Or does that only happen to ICMP? -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account.

1 0

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24
by Selphie Keller 31 Oct '16

31 Oct '16

Hi, I noticed this thread and wanted to provide some information, subnet 103.11.67.0/24 is not an illicit squat this subnet is apart of 103.11.64.0/22 which was transferred from APNIC to ARIN back this last February and is listed publicly at https://www.arin.net/knowledge/statistics/transfers.html within the "Inter-RIR Transfers to the ARIN Region", also WebNX AS18450 does have the LOA's on file for the subnet. I do agree with the others in this thread about the lack of WHOIS as looking up 103.11.67.0/24 does indeed provide very little information to go on so I can see how this could be misunderstood as a squat of the subnet due to the lack of whois information which is an updating issue ARIN/APNIC's part, hopefully can get this resolved so that ARIN shows the chain: APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would show the full chain and a proper abuse contact for this subnet. As for the spamming/spam email part of this thread, please send the said spam email/emails with headers in question to abuse(a)webnx.com, this way we can investigate and sort it out. We do take spamming seriously and will work quickly to get it resolved. -Selphie K

2 2

Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24
by Ronald F. Guilmette 31 Oct '16

31 Oct '16

I just got a spam from 103.11.67.105. The containing /24 appears to be unallocated APNIC space. RIPE tools seem to say that AS18450 has been routing this block since around May 23rd. I see this kind of stuff almost every day now, it seems. And you know, there are days when I really do start to wonder "Has the Internet gone mad?" I'm going to call these turkeys right now and just ask them, point blank, what the bleep they think they're doing, routing unallocated APNIC space. But if history is any guide, this is probably going to turn out to be another one of these "absentee landlord" kinds of ASes, where all they have is an answering machine. I have to either laugh or cry when I see people posting here about the non-functionality of abuse@ email addresses, and then see other people saying "Well, this is why all ASes also have phone numbers." I wish I had a dollar for every AS I had ever tried to contact where -neither- the abuse@ address -nor- the phone number got me to any actual human being. Regards, rfg

12 27

AS6461 (Zayo) LAS->ORD Packet Loss
by Brandon Yarnell 31 Oct '16

31 Oct '16

Seeing some packet loss between LAS and ORD on the Zayo backbone. Long wait times / no answer on the ncc line, no auto-response/ticket creation after sending email. Anybody know whats up? Alerts cleared after taking the peers out of route. -- =========================== Brandon Yarnell Senior Network Engineer | Technical Operations O: (720) 515-3376

2 1

FYI: Net Neutrality in Canada
by Jean-Francois Mezei 30 Oct '16

30 Oct '16

This is a heads up, the CRTC (Canada's FCC) is holding a week long hearing on net neutrality in Canada ("differential pricing" is the used). Canada has had its "ITMP" (Internet Traffic Management Practices) policy since 2009 which deals with unfair throttling, and now, we are arguing on zero rating and sponsored content stuff). It will be broadcasted at http://www.cpac.ca (at bottom of home page there should be a selection for the CRTC hearing). Note: you can choose between english, french of floor (untranslated). Days generally start at 09:00. Can end at any time. Either @CRTCeng or @CRTChearings will be tweeting links to presentations as each presentation begins. hashtag: #CRTC #Diffpricing Facebook did not wish to appear but was "invited". Last time the CRTC did that, it was with Netflix and Google and sparks flew ("you don't regulate us, we don't have to answer"). (It appears on Tuesday right after me, so they should be roughly ~ 10:30 or 11:00.) The agenda: http://www.crtc.gc.ca/Telecom/eng/HEARINGS/2016/ag31_10.htm The original Notice of Consultation: > http://crtc.gc.ca/eng/archive/2016/2016-192.htm?_ga=1.136052530.24154879.14… And the record of the consultation: > https://services.crtc.gc.ca/pub/instances-proceedings/Default-defaut.aspx?E… Note: this started with a different proceeding in September 2015 2 parts 1 filings against Vidéotron who started zero rated music on its wireless service for music services that Vidéotron approved/selected. > https://services.crtc.gc.ca/pub/instances-proceedings/Default-Defaut.aspx?l…

2 3

IPv6 automatic reverse DNS
by Baldur Norddahl 30 Oct '16

30 Oct '16

Hello Many service providers have IPv4 reverse DNS for all their IP addresses. If nothing is more relevant, this will often just be the IPv4 address hashed somehow and tagged to the ISP domain name. For some arcane reason it is important to have the forward DNS match the reverse DNS or some mail servers might reject your mails. However with IPv6 it is not practical to build such a complete reverse DNS zone. You could do a star entry but that would fail the reverse/forward match test. It should be simple to build a DNS server that will automatically generate a hostname value for every reverse lookup received, and also be able to parse that hostname value to return the correct IPv6 address on forward lookups. Does any DNS server have that feature? Should we have it? Why not? I know of some arguments for: 1a) mail servers like it 1b) anti spam filters believe in the magic of checking forward/reverse match. 2) traceroute will be nicer 3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was what got me going on this post) 4) Output from "who" command on Unix will look nicer (maybe). Regards, Baldur

9 12

Yet another NTP security bug we fixed before the CVE issued
by Eric S. Raymond 29 Oct '16

29 Oct '16

http://forums.theregister.co.uk/forum/1/2016/10/28/researchers_tag_new_brac… That'd be another CVE that NTPsec dodges before it's issued. We removed interleaved mode months ago because the code smelled bad and turned out to have an implementation error in the timestamp handling. On past performance, there'll be about a 75% chance each that we've pre-fixed the other new security bugs. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

2 2