RE: COVID-19 vs. our Networks

[Emille Blanc]

> Why should there be a license server at all? Why should an X-ray machine have 
> an external dependency like that in the first place, even if it’s a local 
> server?

In a world where you can license device performance by the megabit/sec/day, or 
even have to purchase per-use factory reset keys since the manufacture has 
stripped product owners of that right too, this doesn't totally surprise me.

There would have to be a flip side to that coin - I would have to guess (read: 
guess) it's a 'n' x-rays/day to "cut costs to the end user." Great practice on 
paper for little guys, but beyond that...

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Owen DeLong
Sent: Tuesday, March 17, 2020 11:06 AM
To: Mark Tinka
Cc: nanog@nanog.org
Subject: Re: COVID-19 vs. our Networks



> On Mar 17, 2020, at 02:20 , Mark Tinka  wrote:
> 
> 
> 
> On 16/Mar/20 16:54, Carsten Bormann wrote:
> 
>> I recently had to reschedule an X-ray because the license manager for the 
>> X-ray machine was acting up.  I don’t think people have a grasp for how much 
>> of the medical infrastructure no longer works when the Internet is down.
> 
> I get this, to some extent. But also, there is a reason hospitals,
> airports and military installations are either put on special power
> grids or invest plenty of money in backup power.

I don’t get this… X-Ray machines (and other critical medical equipment) should 
operate in a fail-safe mode where a license screw up doesn’t prevent the 
machine from operating.

If the hospital hasn’t paid up, find a way to go after the hospital, but don’t 
kill patients to collect your fee.

> If an x-ray machine won't work because the Internet is down, I'm not
> sure that is responsible. As inefficient as it may be to have a license
> server on-prem if there is an option to check against one in the public
> cloud, for a medical use-case, that would make more sense to me.

Why should there be a license server at all? Why should an X-ray machine have 
an external dependency like that in the first place, even if it’s a local 
server?

Owen

RE: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar

[Emille Blanc]

> I don’t know where you’re doing your licensing but I pay about $500 every 10 
> years for my license links.

I should have clarified - CA operator here.
I expect Industry Canada fees differ quite a bit, but that's about our average 
for licensing in the upper bands.

-Original Message-
From: Matt Hoppes [mailto:mattli...@rivervalleyinternet.net] 
Sent: Thursday, August 22, 2019 2:43 PM
To: Emille Blanc
Cc: Bradley Burch; Sean Donelan; nanog@nanog.org
Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather 
Radar

I don’t know where you’re doing your licensing but I pay about $500 every 10 
years for my license links.

And $25,000 is what you paid to use the link in legally possibly causing wanton 
endangerment to life, and then you have to stop using it.

> On Aug 22, 2019, at 5:31 PM, Emille Blanc  
> wrote:
> 
> $25k seems like a cheap fine, really. Have you seen the price of spectrum 
> these days?
> And links operating in a licensed spectrum tend to incur $1k per link per 
> year in usage fees.
> 
>> Most gear now will hop frequencies automatically if they receive a DFS 
>> interference.
>> If your gear supports this, turn it on.
> 
> Said gear almost always has an option to ignore it too, thanks to different 
> regulatory requirements.
> 
> North-American operator: Hey, you're actually in India, so don't do DFS on 
> those channels!
> Radio equipment: 'Kay.
> 
> Queue argument for doing it right and having a link in a non-DFS susceptible 
> channel to survive those many-minute long radar event triggered outages.
> And counter-argument for the increased costs, so what's the point in using 
> cheap 5GHz radios and spectrum in the first place?
> Counter-counter-argument that 5GHz gear is so cheap! Such throughput! Wow!
> 
> I've seen and heard these stories before, and that's usually how it goes.
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Bradley Burch
> Sent: Thursday, August 22, 2019 2:09 PM
> To: Sean Donelan
> Cc: nanog@nanog.org
> Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather 
> Radar
> 
> 
> Most gear now will hop frequencies automatically if they receive a DFS 
> interference.
> 
> If your gear supports this, turn it on.
> Brad,
> 
>> On Aug 22, 2019, at 3:42 PM, Sean Donelan  wrote:
>> 
>> I haven't been paying attention to the WISP market, so I'm not up to speed 
>> on these issues.
>> 
>> 
>> https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0
>> 
>> The Federal Communications Commission’s Enforcement Bureau today announced 
>> proposed fines and issued a formal industry warning related to devices that 
>> apparently caused interference to the Federal Aviation Administration’s 
>> terminal doppler weather radar station in San Juan, Puerto Rico. The 
>> Enforcement Bureau proposed three separate $25,000 fines against wireless 
>> Internet service providers Boom Solutions, Integra Wireless, and WinPR.
>> 
>> [...]
>> 
>> In addition to the proposed fines, the Bureau’s Enforcement Advisory warned 
>> operators, manufacturers, and marketers of Unlicensed National Information 
>> Infrastructure devices that these devices must be certified under FCC rules. 
>> Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 
>> GHz bands risk interfering with radar systems if not properly configured to 
>> share the spectrum
>> 
>> [...]
> 

RE: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar

[Emille Blanc]

$25k seems like a cheap fine, really. Have you seen the price of spectrum these 
days?
And links operating in a licensed spectrum tend to incur $1k per link per year 
in usage fees.

> Most gear now will hop frequencies automatically if they receive a DFS 
> interference.
> If your gear supports this, turn it on.

Said gear almost always has an option to ignore it too, thanks to different 
regulatory requirements.

North-American operator: Hey, you're actually in India, so don't do DFS on 
those channels!
Radio equipment: 'Kay.

Queue argument for doing it right and having a link in a non-DFS susceptible 
channel to survive those many-minute long radar event triggered outages.
And counter-argument for the increased costs, so what's the point in using 
cheap 5GHz radios and spectrum in the first place?
Counter-counter-argument that 5GHz gear is so cheap! Such throughput! Wow!

I've seen and heard these stories before, and that's usually how it goes.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Bradley Burch
Sent: Thursday, August 22, 2019 2:09 PM
To: Sean Donelan
Cc: nanog@nanog.org
Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather 
Radar


Most gear now will hop frequencies automatically if they receive a DFS 
interference.

If your gear supports this, turn it on.
Brad,

> On Aug 22, 2019, at 3:42 PM, Sean Donelan  wrote:
> 
> I haven't been paying attention to the WISP market, so I'm not up to speed on 
> these issues.
> 
> 
> https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0
> 
> The Federal Communications Commission’s Enforcement Bureau today announced 
> proposed fines and issued a formal industry warning related to devices that 
> apparently caused interference to the Federal Aviation Administration’s 
> terminal doppler weather radar station in San Juan, Puerto Rico. The 
> Enforcement Bureau proposed three separate $25,000 fines against wireless 
> Internet service providers Boom Solutions, Integra Wireless, and WinPR.
> 
> [...]
> 
> In addition to the proposed fines, the Bureau’s Enforcement Advisory warned 
> operators, manufacturers, and marketers of Unlicensed National Information 
> Infrastructure devices that these devices must be certified under FCC rules. 
> Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 
> GHz bands risk interfering with radar systems if not properly configured to 
> share the spectrum
> 
> [...]

RE: syn flood attacks from NL-based netblocks

[Emille Blanc]

Have been seeing these at $DAYJOB off and on for the past week.
First logged events began for on 2019-08-04, at approx 1500hrs PST.

Impact for us has been negligible, but some older ASA's were having trouble 
with the scan volume and their configured log levels which has since been 
remedied.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jim Shankland
Sent: Friday, August 16, 2019 3:05 PM
To: nanog@nanog.org
Subject: syn flood attacks from NL-based netblocks

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

RE: What are people using for IPAM these days?

[Emille Blanc]

+1 for PHPIPAM.
It's incredibly easy to modify and follow the code, and very lightweight.
The simple import and export options make managing large blocks very easy for 
us.

https://phpipam.net/

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Steve Mikulasik
Sent: Monday, June 11, 2018 7:08 AM
To: Mike Lyon; NANOG
Subject: RE: What are people using for IPAM these days?

PHPIpam, but I do find there to be a lack of current documentation.

RE: BGP Route Reflector - Route Server, Router, etc

[Emille Blanc]

> I am thinking things like OpenBGPd and BIRD could make a good route reflector 
> though they are most often discussed in the context of IXPs (ie eBGP 
> sessions).

We use openbgpd - well, the native OpenBSD equivalent - for route-reflection in 
a couple of places, as well as a full bgp feed for at least one site, using 
(old) Poweredge 1950 Gen2's. They were on-hand, so the price was right.
It's not caused us any grief to date. That said, neither have our 7204VXR's 
which do the same thing in some areas.
Needless to say, we don't use the reflectors to actually move the bits, but 
have at least on one occasion measured ~88,000pp/s out of one of the 1950's 
that takes a full feed, before interrupts were starting to look worrisome on 
old non-smp safe code. 
But switches with bgp or ospf support are cheap provided you're not feeding 
them with a full table.
Convergence times haven't been a problem for us, but we're only hovering around 
1500 routes at the moment.

Having something you can tcpdump on is nice for the few situations that call 
for it, pf is always extremely handy, re-distributing to/from ospfd is trivial 
(also in OpenBSD base).

As long as you can find hardware with memory enough to scale to your number of 
routes, it's been a perfectly valid and sound option for us.

My 5 cents.


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Justin Krejci
Sent: January-12-17 12:33 PM
To: NANOG ‎[nanog@nanog.org]‎
Subject: BGP Route Reflector - Route Server, Router, etc

Nanog,

I am working on some network designs and am adding some additional routers to a 
BGP network. I'd like to build a plan of changing all of the existing routers 
over from full iBGP mesh to something more scalable (ie route reflection). 
Fortunately, I am also going to be able to decommission some older routers from 
the network and so shrinking the existing iBGP full mesh is something I am all 
too happy to spend time and energy on.

For the purpose of this thread though, I am not really interested in the route 
reflector vs confederation discussion.

In doing some research[1][2][3][4][5] I see a lot of discussions, config 
examples, etc on using route reflectors but most suggest picking a router, or 
more appropriately a set of routers, to become route reflectors within an ASN. 
I have not found many resources discussing using a non-router box as a route 
reflector (ie a device not necessarily in the forwarding path of the through 
traffic). I am thinking things like OpenBGPd and BIRD could make a good route 
reflector though they are most often discussed in the context of IXPs (ie eBGP 
sessions).

I am wondering if people can point me in the direction to some good resource 
material on how to select a good BGP route reflector design. Should I just dust 
off some 7206VXR routers to act as route reflectors? Use a few existing live 
routers and just add the responsibility of being route reflectors, is there a 
performance hit? Install and run BIRD on new server hardware? Buy some newer 
purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors 
and add them to the iBGP topology? GNS3 running IOS on server hardware? 
Something else? How many reflectors should be implemented? Two? Four?

What are the pros and cons of one design over another? On list or private off 
list replies would be great; I'd welcome real world experiences (especially any 
big gotchas or caveats people learned the hard way) as well as just links to 
previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion 
that covers this topic would be appreciated.

[1] - iBGP-to-RR migration slideshow: 
http://meetings.ripe.net/ripe-42/presentations/ripe42-eof-bgp/sld015.html
[2] - General RR design issues: 
http://www.netcraftsmen.com/bgp-route-reflector-design-issues/
[3] - Video intro to RR from Cisco: 
http://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/qlm/CCIP/bgp/introducing-route-reflectors-2/player.html
[4] - Quagga and BIRD as RR example: 
https://bsdrp.net/documentation/examples/bgp_route_reflector_and_confederation_using_quagga_and_bird
[5] - Countless hours on youtube: 
https://www.youtube.com/results?search_query=bgp+route+reflector

Lots more data is out there of course as that is part of my problem.

Thanks!

Justin

RE: Recent NTP pool traffic increase

[Emille Blanc]

Ah, but who do you trust? Trump, Putin, or Xi's clock?

That said, we use a Stratum2 clock for our AS, which syncs using GPS at 
$dayjob. So... I guess we trust Trump's clock.

Perhaps there's a market for a device that takes GPS, GLONASS, and Beidou, and 
references the three for sanity checks in the event of $unforseen_circumstance. 
Assuming such a thing were possible - admittedly I know little about GLONASS, 
and even less about Beidou.

"Perhaps some kind of death clock?"

-Original Message-
From: NANOG [mailto:nanog-bounces+emille=abccommunications@nanog.org] On 
Behalf Of Allan Liska
Sent: December-30-16 11:09 AM
To: Majdi S. Abbas; Laurent Dumont
Cc: nanog@nanog.org
Subject: Re: Recent NTP pool traffic increase


On 12/30/2016 at 1:20 PM, "Majdi S. Abbas"  wrote:On Thu, Dec 22, 2016
at 11:31:08PM -0500, Laurent Dumont wrote:
> What I mostly meant is that there should be a regulated,
industry-wide
> effort in order to provide a stable and active pool program. With
the
> current models, a protocol that is widely used by commercial devices
is
> being supported by the time and effort of volunteers around the
world.

Who's authoritative for time? Even the national labs aren't --
UTC is figured well after the fact. 

In the United States that would the United States Naval Observatory
(USNO) Master Clock (http://tycho.usno.navy.mil/).  You can read more
about it here:
http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock

allan

RE: Recent NTP pool traffic increase

[Emille Blanc]

Perhaps the host OS' to which snapchat caters, don't all have a devent ntp 
subststem available?
I have vague recollections of some other software (I'm sure we all know which) 
implemented it's own malloc layer for every system it ran on, for less trivial 
reasons. ;)


From: NANOG [nanog-boun...@nanog.org] On Behalf Of Tim Raphael 
[raphael.timo...@gmail.com]
Sent: Tuesday, December 20, 2016 5:34 PM
To: Gary E. Miller
Cc: nanog@nanog.org
Subject: Re: Recent NTP pool traffic increase

This was my thought actually, Apple does offer some time services as part of 
the OS but it’s becoming common with larger / more popular apps to provide some 
of these services internally.
Look at the FB app for example, there are a lot of “system” things they do 
themselves due to the ability to control specifics. Users don’t want to have to 
install a second “specialised app” for this either.

With regard to an ephemeral chat app requiring time sync, I can think of quite 
a few use cases and mechanisms in the app that might require time services.

- Tim


> On 21 Dec. 2016, at 9:26 am, Gary E. Miller  wrote:
>
> Yo valdis.kletni...@vt.edu!
>
> On Tue, 20 Dec 2016 20:20:48 -0500
> valdis.kletni...@vt.edu wrote:
>
>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said:
>>> Mostly out of curiosity, what was the reason for the change in the
>>> Snapchat code, and what plans does Snap have for whatever reason
>>> the NTP change was put in place?
>>
>> From other comments in the thread, it sounds like the app was simply
>> linked against a broken version of a library
>
> But why is a chat app doing NTP at all?  it should rely on the OS, or
> a specialized app, to keep local time accurate.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>   g...@rellim.com  Tel:+1 541 382 8588

RE: Syn flood to TCP port 21 from priveleged port (80)

[Emille Blanc]

> Does the synflood have tcp option headers?

Not seeing any here. From this morning.

12:45:46.180665 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok] 
1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40)
12:45:46.180667 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok] 
1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40)
12:45:46.284617 141.138.128.137.80 > 216.57.182.18.21: S [tcp sum ok] 
2595766696:2595766696(0) win 8192 (DF) (ttl 69, id 6478, len 40)

From: Selphie Keller [mailto:selphie.kel...@gmail.com]
Sent: November-01-16 1:13 PM
To: Emille Blanc
Cc: Ken Chase; Oleg A. Arkhangelsky; nanog@nanog.org
Subject: Re: Syn flood to TCP port 21 from priveleged port (80)

Does the synflood have tcp option headers?

I am seeing this same activity at our forward observation system, however it's 
not showing any tcp options like mss,sack,timestamps etc, was curious if others 
were seeing the same

[root@oakridge-intercept(~)]> tcpdump -nn -i eth0 'tcp and (tcp[13] == 2)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:09:32.772506 IP 95.131.190.214.80 > 67.220.207.169.21: Flags [S], seq 
3599006989, win 8192, length 0
13:09:32.809446 IP 95.131.185.150.80 > 67.220.207.169.21: Flags [S], seq 
2409909072, win 8192, length 0
13:09:33.306737 IP 141.138.133.161.80 > 67.220.207.169.21: Flags [S], seq 
1006681302, win 8192, length 0
13:09:33.946427 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq 
3627295948, win 8192, length 0
13:09:33.946469 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq 
3627295948, win 8192, length 0
13:09:34.263905 IP 194.73.173.103.80 > 67.220.207.170.21: Flags [S], seq 
3818041920, win 8192, length 0
13:09:34.415558 IP 194.73.173.243.80 > 67.220.207.169.21: Flags [S], seq 
3584410928, win 8192, length 0




On 1 November 2016 at 13:52, Emille Blanc 
<emi...@abccommunications.com<mailto:emi...@abccommunications.com>> wrote:
Ditto. Same sources; 141.138.128.0/21<http://141.138.128.0/21> and 
95.131.184.0/21<http://95.131.184.0/21> (give or take).

Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at boundary, 502 
unique sources to 10 destination hosts on our AS.

Obligatory data should this be of use to anyone listening in.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org<mailto:nanog-boun...@nanog.org>] On 
Behalf Of Ken Chase
Sent: November-01-16 12:29 PM
To: Oleg A. Arkhangelsky
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: Syn flood to TCP port 21 from priveleged port (80)

seeing an awful lot of port 80 hitting port 21. (Why would port 80
ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts 
flickering
on and off as the service throttled itself at a couple client sites I manage.

I see 540 unique source IPs hitting 32 destinations on my network in just 1000
packets dumped on one router.

All from multiple sequential registered /24s in whois, but all from one
management company:

141.138.128.0/21<http://141.138.128.0/21> and 
95.131.184.0/21<http://95.131.184.0/21>

role:   William Hill Network Services
abuse-mailbox:  
networkservi...@williamhill.co.uk<mailto:networkservi...@williamhill.co.uk>
address:Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR

AS49061

course, synfloods can be spoofed... perhaps they're hoping for a retaliation
against WHNS.

/kc

On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said:
  >Hello,
  >
  >A couple of cuts from tcpdump output:
  >
  >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 
1376379765, win 8192, length 0
  >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 
2254756684, win 8192, length 0
  >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 
3619475318, win 8192, length 0
  >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 
2412690982, win 8192, length 0
  >
  >Does anyone seeing this right now (18:31 UTC)? I see this traffic
  >on at least two completely independent ISPs near Moscow. The
  >rate is about a few dozen PPS hitting all BGP-announced networks.
  >
  >--??
  >wbr, Oleg.
  >
  >"Anarchy is about taking complete responsibility for yourself."
  >?? ?? ?? Alan Moore.

--
Ken Chase - m...@sizone.org<mailto:m...@sizone.org> Guelph Canada

RE: Syn flood to TCP port 21 from priveleged port (80)

[Emille Blanc]

Ditto. Same sources; 141.138.128.0/21 and 95.131.184.0/21 (give or take).

Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at boundary, 502 
unique sources to 10 destination hosts on our AS.

Obligatory data should this be of use to anyone listening in.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ken Chase
Sent: November-01-16 12:29 PM
To: Oleg A. Arkhangelsky
Cc: nanog@nanog.org
Subject: Re: Syn flood to TCP port 21 from priveleged port (80)

seeing an awful lot of port 80 hitting port 21. (Why would port 80
ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts 
flickering
on and off as the service throttled itself at a couple client sites I manage.

I see 540 unique source IPs hitting 32 destinations on my network in just 1000
packets dumped on one router. 

All from multiple sequential registered /24s in whois, but all from one
management company:

141.138.128.0/21 and 95.131.184.0/21

role:   William Hill Network Services
abuse-mailbox:  networkservi...@williamhill.co.uk
address:Infrastructure Services 2 City Walk Sweet Street Leeds LS11 9AR

AS49061

course, synfloods can be spoofed... perhaps they're hoping for a retaliation
against WHNS.

/kc

On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said:
  >Hello,
  >
  >A couple of cuts from tcpdump output:
  >
  >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S], seq 
1376379765, win 8192, length 0
  >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S], seq 
2254756684, win 8192, length 0
  >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S], seq 
3619475318, win 8192, length 0
  >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq 
2412690982, win 8192, length 0
  >
  >Does anyone seeing this right now (18:31 UTC)? I see this traffic
  >on at least two completely independent ISPs near Moscow. The
  >rate is about a few dozen PPS hitting all BGP-announced networks.
  >
  >--??
  >wbr, Oleg.
  >
  >"Anarchy is about taking complete responsibility for yourself."
  >?? ?? ?? Alan Moore.

-- 
Ken Chase - m...@sizone.org Guelph Canada

RE: Spitballing IoT Security

[Emille Blanc]

>On Thu, 27 Oct 2016, Ronald F. Guilmette wrote:
>
>> My iPhone 3GS still works just fine,
>
>I still have a "functional" iPhone 3G (no S).  I don't think AT will 
>activate service on it at this point, and it's been relegated to iPod 
>service when I do yard work.
>
>> You can't *force* people to throw away or trade-in their old tech products,
>> especially when, from the user's point of view, there doesn't -seem- to be
>> anything wrong with them... like all of those pre- Sept. 2015 Internet video
>> cameras.
>
>Sure you can.  Just make the tech dependent on "the cloud" and when the 
>device is too old, force retirement by no longer supporting it.  That 
>doesn't force it off the network (unless the final command from the cloud 
>is "shut off [your network interface]?"), but it makes the user much more 
>likely to toss it and replace it with something newer if they still want 
>such a device.

Or shut down the network that the phone(s) support. Anyone remember the 
analogue cell network shutdown? Or am I already that old?
http://www.pcworld.com/article/142119/article.html

Granted there were other problems this presented. Decreased coverage in areas 
for example is my favourite, as it opened the doors for such revolutionary 
pay-as-you-go-licensing features for base stations such as 
range-by-the-kilometre.
But I think with this, I'm contributing to driving this thread off the topic of 
IoT security, and will now dive back into staring at some netflow data.

RE: Spitballing IoT Security

[Emille Blanc]

(deleted for ambiguity)

> > Which is the point.  These things stay out there...like those winXP
> > boxes.  There are 2 choices
> >
> > 1) manufacturers are responsible for the devices.  No longer caring for
> >them? Recall them.  Compensate the users.
> >
> > 2) stronger obsolescence.  eg kill switch/firmware tombstoning/network
> >connectivity function ending timebomb
> >
> > as a user of lots of legacy tech i find either option bad :/
> >
> > alan
> 
> Or Apple could release iOS 6.1.7.  There is nothing stopping Apple doing
> so.  Apple are the ones preventing people running iOS 10.x on the 3GS.
> This puts the responsibilty on them to supply security fixes.
>
> All of the PC's running XP could run a newer version of the Windows
> regardless of whether they could run the latest version.

Well, yes and no.  As $newer_better_faster_stronger gains market share, there's 
no drive to be backwards compatible.

iOS is no different from any other operating system in that regard, it's 
designed for hardware A, B, C, D's 1 through 4 (probably more, but I'm trying 
to be somewhat abstract).  If it has to support E through Z also, for 12+ years 
of backwards compatibility, bad things can happen (bloat, instability, bugs).
I don't get upset for example, when I transplant a Win2k or Win98 drive into a 
box built up with 3 year old hardware, of which not a single device is 
supported.
That's not even taking into account the challenge of developing for different 
architectures. ARM, x86, PPC, AMD64, PowerISA, SPARC, to name a few. I won't 
even get into microcontrollers.

Don't get me wrong. I'd love to update my 12 year old Macbook Pro to Sierra, 
but I've accepted that it, like most electronics, were almost certainly not 
engineered, let alone expected, to last even half that long.
I'm reminded of that fact every time I open Youtube, and Flash Player spins 
both of its 2.33ghz Core2 Duo cores to 100% for a 460p video.
Even then, I've had to stop updating Flash sometime around mid 2014, as any 
newer versions cease to function entirely.

RE: Death of the Internet, Film at 11

[Emille Blanc]

-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Richard Holbo
>Sent: October-23-16 11:23 PM
>To: John Weekes
>Cc: NANOG
>Subject: Re: Death of the Internet, Film at 11
>
>I run/manage the networks for several smallish (in the thousands of
>customers) eyeball ISP's and  I appreciate a nice "hey you've got a bot" or
>"someone is scanning" me notice to my abuse emails.  They are useful in
>identifying crap that's going on, so for those of you who have the
>resources to do that...  I appreciate it, we do read them at my networks
>and try to do something.
>
>That said... getting end users to actually fix the broken routers etc. etc.
>is NOT easy.Very often we'll notify customers, they will _take their
>stuff to the local computer repair guy_ ... or office depo and they
>will run whatever auto scan they have and say it's all fine.  Customer puts
>it back in, it's still broke, and they call customer support and want us to
>pay for the trip because _their_ expert says it's fine...

+1 a hundred times over.  Educating customers is difficult to do, assuming they 
even want to take the time to be educated.  I'm not just talking about the 
residential class here either. "Commercial IT shops" are not much better in 
most cases -staff tend to all but zone out when you try and explain anything 
more difficult than un-checking the NetBIOS box on their managed customer 
device(s), or try and explain why that DMZ checkbox is a bad idea.

This usually plays out one of two ways at $dayjob;
1) If you apply too much force to the "You have broken equipment" statement, 
the customer becomes frustrated and move their broken equipment to 
$competing-operator's network, and you wind up with a black customer service 
mark. 
2) Customer replaces the device at their expense (It's not _our_ CPE, so why 
would we?), so typically something cheaper and worse than what they replaced, 
and they still feel burned.  But at least their service gets re-activated.

I can recall at least a half-dozen scenarios where the customer actually takes 
up the problem with the manufacturer.  In each of those cases, and they're 
effectively told to push off because the devices are more than 12mo old and 
outside the warranty period (paraphrasing customer statements and all that), or 
similar canned response.  Hate to namedrop on a public list, but Linksys, 
D-Link, Buffalo, Netgear... "There's profit to be had."  Granted, It's been a 
while, at least ~18 months since I've had any such feedback, so perhaps things 
are better in the wake of all the media attention such vendors have seen from 
time to time.
One case with Asus ended positively after about a week of effort with 
phonecalls, so it's not all bad. But a week? Not a great turn-around assuming 
the volumes of devices that would potentially need to be 
patched/updated/whatever.

Only the truly tech-savvy appreciate the advice to repair the problem, but they 
are probably 1 in 1,000, if that.