Re: Gmail down

[Nicholas Suan]

I was having issues remaining connected to Gtalk but it seems to have
corrected itself.

On Tue, Jul 5, 2016 at 10:49 AM, Josh Luthman
 wrote:
> Web interface is broken, downdetector sure sees activity.  This attempt is
> from mobile.
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373

Re: Netflix VPN detection - actual engineer needed

[Nicholas Suan]

On Wednesday, June 8, 2016, Baldur Norddahl 
wrote:

>
>
> On 2016-06-08 07:27, Mark Andrews wrote:
>
>> In message <20160608070525.06fd5...@echo.ms.redpill-linpro.com>, Tore
>> Anderson writes:
>>
>>> * Davide Davini 
>>>
>>> Blocking access to Netflix via the tunnel seems like an obvious
>>> solution to me, for what it's worth.
>>>
>> And which set of prefixes is that?  How often do they change? etc.
>>
>>
> A start would be blocking 2620:108:700f::/64 as discovered by a simple DNS
> lookup on netflix.com. I am not running a HE tunnel (I got native IPv6)
> and I am not blocked from accessing Netflix over IPv6 so can't really try
> it. I am curious however that none of the vocal HE tunnel users here
> appears to have tried even simple counter measures such as a simple
> firewall rule to drop traffic to that one /64 prefix.
>

That's a start but Netflix has a few more prefixes than that:
http://bgp.he.net/AS2906#_prefixes6

Re: Netflix VPN detection - actual engineer needed

[Nicholas Suan]

On Sun, Jun 5, 2016 at 10:51 PM, Jon Lewis  wrote:
> On Sun, 5 Jun 2016, Owen DeLong wrote:
>
>> What is non-standard about an HE tunnel? It conforms to the relevant RFCs
>> and
>> is a very common configuration widely deployed to many thousands of
>> locations
>> around the internet.
>>
>> Itÿÿs not that Netflix happens to not work with these tunnels, the problem
>> is
>> that they are taking deliberate active steps to specifically block them.
>
>
> It's not a question of standard vs non-standard.  If Netflix is blocking HE
> IPv6 space (tunnel customers), I suspect they're doing so because this is
> effectively an IPv6 VPN service that masks the end-user's real IP making
> invalid any IP-based GEO assumptions Netflix would like to make about
> customer connections in order to satisfy their content licenses.
>

Yes, it's just Netflix being super aggressive about blocking VPNs.
They're basically removing access from any sort of service that can be
used to tunnel.

Re: G root not responding on UDP?

[Nicholas Suan]

I'm see the same thing from multiple networks.

$ dig  NS . @g.root-servers.net

; <<>> DiG 9.9.5 <<>> NS . @g.root-servers.net
;; global options: +cmd
;; connection timed out; no servers could be reached

On Thu, Apr 14, 2016 at 7:30 AM, Anurag Bhatia  wrote:
> Hello everyone
>
>
> I wonder if it's just me or anyone else also finding issues in g root
> reachability?
>
>
> ICMP, trace, UDP DNS queries all timing out. Only TCP seem to work.
>
>
> Trace is timing out on 208.46.37.38.
>
>
>
> traceroute to 192.112.36.4 (192.112.36.4), 64 hops max, 52 byte packets
>  1  router01.home (172.16.0.1)  4.926 ms  1.863 ms  1.845 ms
>  2  103.60.176.101 (103.60.176.101)  24.007 ms  24.507 ms  22.330 ms
>  3  nsg-static-137.49.75.182-airtel.com (182.75.49.137)  64.435 ms  64.359
> ms  66.108 ms
>  4  182.79.206.46 (182.79.206.46)  331.787 ms
> 182.79.206.53 (182.79.206.53)  228.497 ms
> 182.79.222.189 (182.79.222.189)  224.966 ms
>  5  ldn-brdr-01.qwest.net (195.66.225.34)  162.745 ms  162.139 ms  162.031
> ms
>  6  lon-ddos-01.inet.qwest.net (67.14.63.58)  162.138 ms  162.125 ms
>  162.916 ms
>  7  * * *
>  8  chp-edge-01.inet.qwest.net (208.46.37.37)  242.819 ms  242.793 ms
>  242.575 ms
>  9  208.46.37.38 (208.46.37.38)  253.176 ms  253.066 ms  252.807 ms
> 10  * * *
> 11  * * *
> 12  * * *
>
>
>
>
> dig @192.112.36.4 . ns
>
> ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
>
>
>
>
> dig @192.112.36.4 . ns  +tcp +noauth
>
> ; <<>> DiG 9.8.3-P1 <<>> @192.112.36.4 . ns +tcp +noauth
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29674
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 24
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;. IN NS
>
> ;; ANSWER SECTION:
> . 518400 IN NS g.root-servers.net.
> . 518400 IN NS l.root-servers.net.
> . 518400 IN NS f.root-servers.net.
> . 518400 IN NS h.root-servers.net.
> . 518400 IN NS k.root-servers.net.
> . 518400 IN NS b.root-servers.net.
> . 518400 IN NS c.root-servers.net.
> . 518400 IN NS e.root-servers.net.
> . 518400 IN NS j.root-servers.net.
> . 518400 IN NS i.root-servers.net.
> . 518400 IN NS m.root-servers.net.
> . 518400 IN NS a.root-servers.net.
> . 518400 IN NS d.root-servers.net.
>
> ;; ADDITIONAL SECTION:
> a.root-servers.net. 360 IN A 198.41.0.4
> b.root-servers.net. 360 IN A 192.228.79.201
> c.root-servers.net. 360 IN A 192.33.4.12
> d.root-servers.net. 360 IN A 199.7.91.13
> e.root-servers.net. 360 IN A 192.203.230.10
> f.root-servers.net. 360 IN A 192.5.5.241
> g.root-servers.net. 360 IN A 192.112.36.4
> h.root-servers.net. 360 IN A 198.97.190.53
> i.root-servers.net. 360 IN A 192.36.148.17
> j.root-servers.net. 360 IN A 192.58.128.30
> k.root-servers.net. 360 IN A 193.0.14.129
> l.root-servers.net. 360 IN A 199.7.83.42
> m.root-servers.net. 360 IN A 202.12.27.33
> a.root-servers.net. 360 IN  2001:503:ba3e::2:30
> b.root-servers.net. 360 IN  2001:500:84::b
> c.root-servers.net. 360 IN  2001:500:2::c
> d.root-servers.net. 360 IN  2001:500:2d::d
> f.root-servers.net. 360 IN  2001:500:2f::f
> h.root-servers.net. 360 IN  2001:500:1::53
> i.root-servers.net. 360 IN  2001:7fe::53
> j.root-servers.net. 360 IN  2001:503:c27::2:30
> k.root-servers.net. 360 IN  2001:7fd::1
> l.root-servers.net. 360 IN  2001:500:9f::42
> m.root-servers.net. 360 IN  2001:dc3::35
>
> ;; Query time: 259 msec
> ;; SERVER: 192.112.36.4#53(192.112.36.4)
> ;; WHEN: Thu Apr 14 16:59:09 2016
> ;; MSG SIZE  rcvd: 744
>
>
>
>
>
> Is UDP blocked recently or it has been like this from long?
>
>
>
> --
>
>
> Anurag Bhatia
> anuragbhatia.com

Re: Colo space at Cermak

[Nicholas Suan]

They made an announcement about it a while back:

http://boards.na.leagueoflegends.com/en/c/help-support/2uTrAyy8-na-server-roadmap-update-chicago-server-move-complete

On Sat, Nov 14, 2015 at 11:58 AM, Josh Reynolds  wrote:
> That's interesting news, how did you hear about that?
> On Nov 14, 2015 1:46 AM, "Ishmael Rufus"  wrote:
>
>> The company who has the worlds most played online multiplayer game moved
>> their servers to Chicago back in late August. Maybe that affected prices?
>>
>> On Fri, Nov 13, 2015, 12:45 PM Greg Sowell  wrote:
>>
>> > I would guess it has to do with competing with your landlord now.  I know
>> > it's starting to happen more and more.
>> >
>> > On Thu, Nov 12, 2015 at 8:32 PM, Mike Hammett  wrote:
>> >
>> > > Has something happened the past couple months to cause a quick shortage
>> > of
>> > > space at Cermak? I had an offer sent a few months ago (when I didn't
>> need
>> > > it) where a cab and five cross connects were cheaper than what five
>> cross
>> > > connects normally are, much less the cabinet value as well. Around that
>> > > time I think cabinets were going for $700 or so for basic
>> > primary\redundant
>> > > 20A. Now the cabinet is going for $1,800. It went from being the
>> cheapest
>> > > I've seen at Cermak to the most I've seen at Cermak in a matter of a
>> few
>> > > months. Two people with space in that building are citing an uptick in
>> > > demand. Really? That much of a demand increase with hundreds of
>> thousands
>> > > of square feet coming online in the Chicago metro?
>> > >
>> > > Can anyone corroborate that story or are they just making stuff up
>> hoping
>> > > I agree to inflated cabinet prices?
>> > >
>> > >
>> > >
>> > >
>> > > -
>> > > Mike Hammett
>> > > Intelligent Computing Solutions
>> > > http://www.ics-il.com
>> > >
>> > >
>> > >
>> > > Midwest Internet Exchange
>> > > http://www.midwest-ix.com
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> >
>> > GregSowell.com
>> > TheBrothersWISP.com
>> >
>>

Re: ARIN IPV4 Countdown

[Nicholas Suan]

On Tue, Jul 14, 2015 at 9:33 PM, Curtis Maurand cmaur...@xyonet.com wrote:

 Since IPV6 does not have NAT, it's going to be difficult for the layman to
 understand their firewall.  deployment of ipv4 is pretty simple.  ipv6 on
 the otherhand is pretty difficult at the network level.  yes, all the
 clients get everything automatically except for the router/firewall.

 -C

Enabling IPv6 on my CPE was extremely difficult, yes. It took three
extra clicks to enable connection sharing and then subsequently enable
incoming connections.

Re: Also Facebook (was: Re: Dual stack IPv6 for IPv4 depletion)

[Nicholas Suan]

You should elaborate on some of these 'holes' then.

On Fri, Jul 10, 2015 at 12:53 AM, Ricky Beam jfb...@gmail.com wrote:
 On Thu, 09 Jul 2015 21:48:06 -0400, John Curran jcur...@arin.net wrote:

 Both techniques indicate more than 20% of the US Internet users are
 connecting via IPv6.


 Interesting method that's full of holes (and they know it), but it's data
 nonetheless.

 Globally, it's still ~4.5%. Within my own pool of providers, I'm ZERO for 5.
 (I've not pinged TWC-BC lately, 'tho. And no one has gotten back to me that
 Earthlink has provided TWC with any prefixes, so us Earthlink cable internet
 customers are still dark.)

 (They’ve also observing a significant performance
 improvement with IPv6 connected users over IPv4 connected...


 IPv4 tends to be NAT'd and aggressively proxied. I also wouldn't rule out v6
 taking a different path, but that wouldn't explain the magnitude of
 difference those slides would suggest. (not really readable via youtube)

Re: Dual stack IPv6 for IPv4 depletion

[Nicholas Suan]

That's only an issue with airport devices and PPPoE. I can confirm it
does native DHCPv6-PD otherwise.

On Sun, Jul 5, 2015 at 5:32 AM, William Waites wwai...@tardis.ed.ac.uk wrote:
 On Sun, 5 Jul 2015 06:13:52 +, Mel Beckman m...@beckman.org said:

  In fact, I show just how to do this using a $99 Apple Airport
  Express in my three-hour online course “Build your own IPv6 Lab”

 An anectode about this, maybe out of date, maybe not. I was helping my
 friend who likes Apple things connect to the local community
 network. He wanted to use an Airport as his home gateway rather than
 the router that we normally use. Turns out these things can *only* do
 IPv6 with tunnels and cannot do IPv6 on PPPoE. Go figure. So there is
 not exactly a clear path to native IPv6 for your lab this way.

 -w

Re: leap second outage

[Nicholas Suan]

Correct, the leap second gets inserted at midnight UTC.

Leap seconds can be introduced in UTC at the end of the months of December

 or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every
 six months, either to announce a time step in UTC or to confirm that there
 will be no time step at the next possible date.

ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

On Tue, Jun 30, 2015 at 11:30 PM, Stefan netfort...@gmail.com wrote:
 This was supposed to have happened @midnight UTC, right? Meaning that we
 are past that event. Under which scenarios should people be concerned about
 midnight local time? Lots of confusing messages flying all over...
 On Jun 30, 2015 10:13 PM, frnk...@iname.com wrote:

 We experienced our first leap second outage -- our SHE (super head end) is
 using (old) Motorola encoders and we lost those video channels.  They
 restarted all those encoders to restore service.

 Frank

Re: quietly....

[Nicholas Suan]

On Thu, Feb 3, 2011 at 12:18 AM, Jay Ashworth j...@baylink.com wrote:

 Complexity of the configuration vastly increases the size of the
 attack surface: in a NATted edge network, *no packets can come in
 unless I explicitly configure for them*; there are any number of
 reasons why an equivalently simply assertion cannot be made concerning
 the configuration of firewalls, of whatever type or construction.

I've always wondered how many consumer routers aren't actually

Re: quietly....

[Nicholas Suan]

On Thu, Feb 3, 2011 at 12:18 AM, Jay Ashworth j...@baylink.com wrote:

 Complexity of the configuration vastly increases the size of the
 attack surface: in a NATted edge network, *no packets can come in
 unless I explicitly configure for them*; there are any number of
 reasons why an equivalently simply assertion cannot be made concerning
 the configuration of firewalls, of whatever type or construction.


I've always wondered how many consumer-grade routers aren't actually
doing this, and the fact that they don't do this is masked by the use
of RFC1918 addresses on the internal side of the router. (Linux with
netfilter won't, by default, unless you change the default ACCEPT
policy, or add a specific rule to block incoming packets.)

Re: Todd Underwood was a little late

[Nicholas Suan]

We've been seeing the same thing since 2010-06-10:

22:13:19.687981 IP 72.236.167.197.41789  72.236.167.138.domain: 38783+ A? 
jkl.cnr.cn. (28)
22:13:19.773076 IP 72.236.167.124.33327  72.236.167.138.domain: 38783+ A? 
i10.aliimg.com. (32)
22:13:19.855750 IP 72.236.167.169.33381  72.236.167.138.domain: 38783+ A? 
www.vrp3d.com. (31)
22:13:19.941155 IP 72.236.167.200.33005  72.236.167.138.domain: 38783+ A? 
www.51seer.com. (32)
22:13:20.026342 IP 72.236.167.141.36652  72.236.167.138.domain: 38783+ A? 
img1.kaixin001.com.cn. (39)
22:13:20.102540 IP 72.236.167.188.39525  72.236.167.138.domain: 38783+ A? 
pic.kaixin001.com.cn. (38)
22:13:20.204403 IP 72.236.167.103.37838  72.236.167.138.domain: 38783+ A? 
pic.kaixin001.com. (35)
22:13:20.791201 IP 72.236.167.186.38958  72.236.167.138.domain: 38783+ A? 
pic1.kaixin001.com. (36)
22:13:20.876527 IP 72.236.167.121.33000  72.236.167.138.domain: 38783+ A? 
pic1.kaixin001.com.cn. (39)
22:13:20.971393 IP 72.236.167.203.33726  72.236.167.138.domain: 38783+ A? 
logo.kaixin001.com.cn. (39)
22:13:21.051831 IP 72.236.167.120.35298  72.236.167.138.domain: 38783+ A? 
qqtest.cdn20.com. (34)
22:13:21.132215 IP 72.236.167.196.34862  72.236.167.138.domain: 38783+ A? 
upload.elle.cn. (32)
22:13:21.218372 IP 72.236.167.116.35073  72.236.167.138.domain: 38783+ A? 
www.elle.cn. (29)

Spoofed, all with a TTL of 3. Given that all of the domains in question appear 
to have nameservers in common, I assumed someone was trying to make us 
participate in a DDoS attack, and started dropping all of the traffic.

On Jun 16, 2010, at 9:01 PM, Jon Lewis wrote:

 I just took a closer look at something odd I'd noticed several days ago. One 
 of our DNS servers was sending crazy amounts of ARP requests for IPs in the 
 /24 its main IP is in.  What I've found is we're getting hit with DNS 
 requests that look like they're from typical internet traffic for someone in 
 China hitting this DNS server from IPs in its /24 which are currently not in 
 use (at least on our local network).  It would appear someone in China is 
 using our IP space, presumably behind a NAT router, and they're leaking some 
 traffic non-NAT'd.
 
 20:53:41.361734 IP 209.208.121.66.41755  209.208.121.126.53:  15939+ A? 
 ns5.z.lxdns.com. (33)
 20:53:43.523210 IP 209.208.121.95.39393  209.208.121.126.53:  15939+ A? 
 www.nanhutravel.com. (37)
 20:53:48.411805 IP 209.208.121.66.33390  209.208.121.126.53:  15939+ A? 
 test.csxm.cdn20.com. (37)
 20:53:50.557680 IP 209.208.121.135.40056  209.208.121.126.53:  15939+ A? 
 rextest2.lxdns.com. (36)
 20:53:56.918993 IP 209.208.121.135.37291  209.208.121.126.53:  15939+ A? 
 www.51seer.com. (32)
 20:54:20.033902 IP 209.208.121.95.37544  209.208.121.126.53:  15939+ A? 
 image.dhgate.cdn20.com. (40)
 20:54:21.900295 IP 209.208.121.66.35144  209.208.121.126.53:  15939+ A? 
 static.xn-app.com. (35)
 20:54:27.711853 IP 209.208.121.66.33518  209.208.121.126.53:  15939+ A? 
 oa.hanhe.com. (30)
 20:54:29.642938 IP 209.208.121.135.41723  209.208.121.126.53:  15939+ A? 
 pic1.kaixin001.com. (36)
 20:54:32.357414 IP 209.208.121.95.38564  209.208.121.126.53:  15939+ A? 
 rr.snyu.com. (29)
 20:54:38.901315 IP 209.208.121.95.37840  209.208.121.126.53:  15939+ A? 
 edu.163.com. (29)
 20:54:39.807385 IP 209.208.121.95.36069  209.208.121.126.53:  15939+ A? 
 image.dhgate.cdn20.com. (40)
 20:54:40.833778 IP 209.208.121.66.34949  209.208.121.126.53:  15939+ A? 
 uphn.snswall.com. (34)
 20:54:42.070294 IP 209.208.121.95.38405  209.208.121.126.53:  15939+ A? 
 zwgk.cma.gov.cn. (33)
 20:54:42.189939 IP 209.208.121.135.36637  209.208.121.126.53:  15939+ A? 
 btocdn.52yeyou.com. (36)
 20:54:45.767299 IP 209.208.121.95.41405  209.208.121.126.53:  15939+ A? 
 img1.kaixin001.com.cn. (39)
 20:54:48.595582 IP 209.208.121.66.40099  209.208.121.126.53:  15939+ A? 
 rextest2.cdn20.com. (36)
 20:54:49.480147 IP 209.208.121.95.42363  209.208.121.126.53:  15939+ A? 
 www.dameiren.com. (34)
 20:54:50.714200 IP 209.208.121.135.41497  209.208.121.126.53:  15939+ A? 
 pic1.kaixin001.com.cn. (39)
 20:54:54.116841 IP 209.208.121.135.36828  209.208.121.126.53:  15939+ A? 
 i.jstv.com. (28)
 
 I hope they got a good deal on the IP space...and a better deal on their 
 buggy router.
 
 --
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
 _ http://www.lewis.org/~jlewis/pgp for PGP public key_
 

Re: ingress SMTP

[Nicholas Suan]

On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote:


On Wed, Sep 03, 2008 at 09:40:20AM -0700, Michael Thomas wrote:
Allowing unfiltered public access to port 25 is one of the things  
that

increases everyone's spam load, and your ISP is trying to be a Good
Neighbor in blocking access to anyone's servers but their own;  
many ISPs
are moving towards this safer configuration. We're a good  
neighbor, as
well, and support Mail Submission Protocol on port 587, and here's  
how
you set it up -- and it will work from pretty much anywhere  
forever.


I think this all vastly underrates the agility of the bad guys. So  
lots of

ISP's have blocked port 25. Has it made any appreciable difference?
Not that I can tell. If you block port 25, they'll just use another  
port and

a relay if necessary.


You're forgetting that 587 *is authenticated, always*.



I'm not sure how that makes much of a difference since the usual spam  
vector is malware that has  (almost) complete control of the machine  
in the first place.

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Nicholas Suan]

On 6/5/07, David Schwartz [EMAIL PROTECTED] wrote:



Combined responses to save bandwidth and hassle (and number of times you
have to press 'd'):

--

 Just because it's behind NAT, does not mean it's unreahcable from the
internet:

Okay, so exactly how many times do you think we have to say in this thread
that by NAT/PAT, we mean NAT/PAT as typically implemented in the very
cheapest routers in their default configuration?



Even the cheapest routers have a 'DMZ' configuration option that adds
a rule that, by default, sends all the traffic to a particular host.
And using that is a fairly common solution to bypassing problems with
port forwarding and NAT.

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Nicholas Suan]

On 6/4/07, David Schwartz [EMAIL PROTECTED] wrote:


I can give you the root password to a Linux machine running telnetd and
sshd. If it's behind NAT/PAT, you will not get into it. Period.



Just because it's behind NAT, does not mean it's unreahcable from the internet:

Fenrir:~% telnet ipv4.nonexiste.net
[1028] 19:57:17
Trying 68.90.179.13...
Connected to ipv4.nonexiste.net.
Escape character is '^]'.
Password:
Last login: Sat Jun  2 14:26:58 2007 from inuyasha.nonexiste.net on pts/0
Linux nira 2.6.18-1-486 #1 Sat Oct 21 16:34:06 UTC 2006 i686 GNU/Linux

You have mail.
Last was Mon 04 Jun 2007 06:57:37 PM CDT on pts/8.

nira:~$ /sbin/ifconfig eth0
eth0  Link encap:Ethernet  HWaddr 00:20:78:03:F6:B0
 inet addr:172.16.16.8  Bcast:172.16.16.255  Mask:255.255.255.0

And no, that's not misconfigured.