Re: Spitballing IoT Security

[Marcel Plug]

On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear 
wrote:

> It is worth asking what protections are necessary for a device that
> regulates insulin.


Insulin pumps are an example of devices that have been over-regulated to
the point where any and all innovation has been stifled.  There have been
hardly any changes in the last 10+ years, during a time when all other
technology has advanced quite a bit.  Its off-topic for Nanog, but i
promise you this is very frustrating and annoying topic that hits me close
to home.

There has to be a middle ground.  I guarantee we do not want home
firewalls, and all the IoT devices to be regulated like insulin pumps and
other medical devices.  I think I'm starting to agree with those that want
to keep government regulation out of this arena...

Marcel


> Eliot
>
>
> On 11/8/16 6:05 AM, Ronald F. Guilmette wrote:
> > In message <20161108035148.2904b5970...@rock.dv.isc.org>,
> > Mark Andrews  wrote:
> >
> >> * Deploying regulation in one country means that it is less likely
> >>  to be a source of bad traffic.  Manufactures are lazy.  With
> >>  sensible regulation in single country everyone else benefits as
> >>  manufactures will use a single code base when they can.
> > I said that too, although not as concisely.
> >
> >> * Automated updates do reduce the numbers of vulnerable machines
> >>  to known issues.  There are risks but they are nowhere as bad as
> >>  not doing automated updating.
> > I still maintain, based upon the abundant evidence, that generallized
> > hopes that timely and effective updates for all manner of devices will
> > be available throughout the practical lifetime of any such IoT thingies
> > is a mirage.  We will just never be there, in practice.  And thus,
> > manufacturers should be encouraged, by force of law if necessary, to
> > design software with a belt-and-suspenders margin of safety built in
> > from the first day of shipping.
> >
> > You don't send out a spacecraft, or a medical radiation machine, without
> > such addtional constraints built in from day one.  You don't send out
> > such things and say "Oh, we can always send out of firmware update later
> > on if there is an issue."
> >
> > From a software perspective, building extra layers of constraints is not
> > that hard to do, and people have been doing this kind of thing already
> > for decades.  It's called engineering.  The problem isn't in anybody's
> > ability or inability to do safety engineering in the firmware of IoT
> > things.  The only problem is providing the proper motivation to cause
> > it to happen.
> >
> >
> > Regards,
> > rfg
> >
>
>
>

Re: RPKI and Trust Anchor question

[Marcel Plug]

Thanks for your detailed response John.  Further comments inline.

On Mon, Aug 5, 2013 at 9:58 PM, John Curran jcur...@arin.net wrote:


   So, Marcel, please allow me to turn the question around...  Do you
   do you believe that there should be an RPKI Global Trust Anchor?
   Are you concerned about the potential aggregation of control and
   risk that may result? (Feel free to answer me privately if you
   would prefer.)


Having a single root seems like the right way to go.  There will always be
the threat (real or imagined) of outside interference.  For that reason I'm
sure there will be a small droid army of independent systems monitoring and
studying every change the Global Trust Anchor makes - ready to sound the
alarm.  It's probably easier to keep an eye on one trust anchor than it is
to monitor 5 of them.

All the other arguments I've heard are in favour of a one-TA system so I
won't repeat them.



   At the point in time when we understand the technical architecture
   being proposed and its implications, we will formally poll the ARIN
   and NANOG community on the question of whether there is support for
   having an RPKI Global Trust Anchor.  My best estimate is that this
   will occur near the end of this year, but there's nothing wrong with
   having some discussion in the meantime if the mailing list is otherwise
   quiet.  :-)

 I hope this provides some insight - thank you for asking about it,
 as it has been too long since any status update on this project
 (I will work on that as well for the very near future.)


As I said, thanks for the update.



 Thanks!
 /John

 John Curran
 President and CEO
 ARIN



 Marcel

RPKI and Trust Anchor question

[Marcel Plug]

Hi Nanog,

Does anyone have any inside information what may be happening in the effort
to have a single trust anchor for RPKI?  Is ICANN still working on this?
 If so is there any timeline or published info of any kind?

Most of the information i can find is about 2 years old.

Any links or info of any kind would be much appreciated.

Thanks,

Marcel Plug

Re: IP allocations / bogon - verification

[Marcel Plug]

On Fri, Aug 2, 2013 at 2:28 PM, Leo Vegoda leo.veg...@icann.org wrote:


 But I'd be fascinated - if somewhat disturbed - to be proved wrong...


Team Cymru seems to think it was a Bogon, as recently as yesterday.
http://www.cymru.com/BGP/bogons.html  (search for 66.185.0.0/20, last seen
Aug 1st)

Probably the networks of the financial related websites were blocking due
to the Cymru Bogons list.



 Regards,

 Leo


-Marcel

Re: Windows 2008/2012 arp timeout process

[Marcel Plug]

Hi James,

Is your windows client seeing traffic from the 6500 with the real (Burned
in) MAC address of your 6500?  If so it may be re-arping to find out which
of the MAC addresses is the 'right' one to use, the real MAC or the  HSRP
MAC.

My memory is fuzzy, but I think I've seen issues like that before.  Sorry
its been a while so I can't remember anything more specific.

-Marcel


On Thu, Nov 29, 2012 at 5:22 PM, James Stoll eng.jsto...@yahoo.com wrote:

 Greetings Nanog,

 I apologize in advance if this should be directed towards a server/systems
 discussion list, but I've noticed some (what I think are) issues with the
 way windows 2008/2012 handles arp. I started noticing some high arp
 processes on some of our 6500s running sup720s, and after performing some
 captures of packets being punted to the cpu I found that there were quite a
 few repeat sources. After digging into the sources, it looks like windows
 2008/2012 systems are sending arp refresh requests quite frequently.

 According to this article ( http://support.microsoft.com/kb/949589 ), if
 the neighbor entry is in use for the IP it should not go stale.
 Specifically:

 If the entry is in the Reachable state, Windows Vista TCP/IP hosts do
 not send ARP requests to the network. Therefore, Windows Vista TCP/IP hosts
 use the information in the cache. If an entry is not used, and it stays in
 the Reachable state for longer than its Reachable Time value, the entry
 changes to the Stale state. If an entry is in the Stale state, the
 Windows Vista TCP/IP host must send an ARP request to reach that
 destination.

 I know that states Windows Vista, but the applies to section lists the
 other OSes.

 I've replicated this in my lab (server pinging its own gateway while
 capturing traffic), and I am seeing the same issue:

 222 10:05:18.462720Dell_a6:dc:52
 All-HSRP-routers_0a   ARPWho has 10.36.0.1?  Tell 10.36.0.31
 223 10:05:18.464759All-HSRP-routers_0a
 Dell_a6:dc:52 ARP10.36.0.1 is at 00:00:0c:07:ac:0a
 1886   10:06:31.962218Dell_a6:dc:52
 All-HSRP-routers_0a   ARPWho has 10.36.0.1?  Tell 10.36.0.31
 1887   10:06:31.963004All-HSRP-routers_0a
 Dell_a6:dc:52 ARP10.36.0.1 is at 00:00:0c:07:ac:0a
 3348   10:07:23.461682Dell_a6:dc:52
 All-HSRP-routers_0a   ARPWho has 10.36.0.1?  Tell 10.36.0.31
 3349   10:07:23.471003All-HSRP-routers_0a
 Dell_a6:dc:52 ARP10.36.0.1 is at 00:00:0c:07:ac:0a

 I've tried this on various devices, and the only place I don't see this
 behavior is on wireless interfaces.

 I'm more of a linux guy, and performing the same tests there I see the
 behavior stated in this article (which is what I would expect) -
 http://linux-ip.net/html/ether-arp.html . Specifically:

 Entries in the ARP cache are periodically and automatically verified
 unless continually used.

 Has anyone run into this issue before ? Have a fix ? Point me to any
 documentation or other distros that I should ask ?

 TIA,
 James

Re: last mile, regulatory incentives, etc (was: att fiber, et al)

[Marcel Plug]

This article from arstechnica is right on topic.  Its about how the
city of Amsterdam built an open-access fibre network.  It seems to me
this is the right way to do it, or at least very close to the right
way..

http://arstechnica.com/tech-policy/news/2010/03/how-amsterdam-was-wired-for-open-access-fiber.ars

-Marcel

On Fri, Mar 23, 2012 at 11:35 PM,  valdis.kletni...@vt.edu wrote:
 On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said:

 The indication of above average or below average is based on a comparison 
 of the actual test result to the current NTIA
 definition of broadband which is 768 kbps download and 200 kbps upload. Any 
 test result above the NTIA definition is
 considered above average, and any result below is considered below average.

 That's the national definition of broadband that we're stuck with.  To show
 how totally cooked the books are, consider that when they compute percent of
 people with access to residential broadband, they do it on a per-county basis
 - and if even *one* subscriber in one corner of the county has broadband, the
 entire county counts.

Re: Most energy efficient (home) setup

[Marcel Plug]

I've run a SheevaPlug at home for a few years now.  I don't do
anything fancy with it, but it does what I need it to do.  Mostly that
is file server, web server, jump-box for network testing.  Also
testing different linux software for this and that...  (Quagga runs
nicely, but won't hold a full BGP table :)

There are no moving parts in my home computer/networking gear, unless
my laptop is running.  That was the goal for me.  I recently grabbed a
couple of TPLink WR703N devices to mess around with as well, but I
haven't had a chance to dig into that much.

The internet tells me that the Sheeva uses about 5 Watts of power.
Along with my wireless router and DSL modem I might be under 10 Watts,
but I really don't know how much power a wireless modem uses.

Oh and I also have native IPv6 on my DSL.  I like to brag about that
whenever I can.

Marcel

On Wed, Feb 22, 2012 at 4:13 PM, Jeroen van Aart jer...@mompl.net wrote:
 After reading a number of threads where people list their huge and wasteful,
 but undoubtedly fun (and sometimes necessary?), home setups complete with
 dedicated rooms and aircos I felt inclined to ask who has attempted to make
 a really energy efficient setup?

 This may be an interesting read, it uses a plugcomputer:
 http://www.theregister.co.uk/2010/11/11/diy_zero_energy_home_server/page2.html

 Admittedly I don't have a need for a full blown home lab since I am not a
 network engineer, I'm more of a sysadmin/network admin/programmer kind of
 person... So I can make do with a somewhat minimal set up. But I *do* have
 tunneled IPv6 from home ;-)

 In my current apartment in addition to an el cheapo DSL modem that probably
 wastes about 10 watts and a sometimes on PC workstation I used to have an
 always on thinkpad (early 2000s model) as my main desktop system and an
 always on G4 system (pegasos2 in case you care) acting as a mail/web/ssh
 server. The thinkpad was a refurbished model and it was quite stable, up to
 500 days of uptime during its last years. But the hardware slowly
 disintegrated and when the gfx card died I retired it.

 Right now my always on server is a VIA artigo 1100 pico-itx system
 (replacing the G4 system) and my router/firewall/modem is still the el
 cheapo DSL modem (which runs busybox by the way). I have an upgraded
 workstation that's sometimes on, it has a mini itx form factor (AMD
 phenom2 CPU). I use debian on all systems.

 I haven't measured it but I think if the set up would use 30 watts
 continuously (only taking the always on systems into account) it'd be a lot.
 Of course it'll spike when I fire up the workstation.

 It's not extremely energy efficient but compared to some setups I read about
 it is. The next step would be to migrate to a plugcomputer or something
 similar (http://plugcomputer.org/).

 Any suggestions and ideas appreciated of course. :-)

 Thanks,
 Jeroen

 --
 Earthquake Magnitude: 3.0
 Date: Wednesday, February 22, 2012 13:57:33 UTC
 Location: Island of Hawaii, Hawaii
 Latitude: 19.4252; Longitude: -155.3207
 Depth: 3.90 km

Re: Most energy efficient (home) setup

[Marcel Plug]

On Wed, Feb 22, 2012 at 5:43 PM, Jeroen van Aart jer...@mompl.net wrote:

 I wonder how reliable the storage is in these things. Is it comparable to
 modern SSDs?

No issues so far.  As I said though, I don't push it too hard.  I
don't have any specs or stats off hand, so I can't get any more
detailed.

I use a SD card for extra storage, also seems to be working just fine.



 Oh and I also have native IPv6 on my DSL.  I like to brag about that
 whenever I can.


 So your ISP delivers IPv6 to your home? I wish mine did...

I'm pretty happy with them, I just wish my DLink would stop requiring reboots...




Marcel

Re: Common operational misconceptions

[Marcel Plug]

I often struggle with the concept of teaching someone how to
troubleshoot.  We have young guys coming in all the time and it is
often an area in which they need to hone their skills.  I found this
article a while back and I keep it bookmarked, its the best article
I've seen that lays it all out pretty clearly.

http://packetlife.net/blog/2010/mar/10/the-science-of-network-troubleshooting/

-Marcel

I'm guessing, but I believe the author would fall into the under 35 category ;-)

On Fri, Feb 17, 2012 at 10:51 AM, -Hammer- bhmc...@gmail.com wrote:
 Mario,
    I was kinda having fun and kinda not. My point is that the 40-50 year
 olds that were doing this 30 years ago grew up understanding things in
 order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those
 confused). Hex. etc. Move on to the OSI model and it's the same thing.
 Voltage. Amplitude. Binary. etc. I think that this generation that I'm
 referring to is a great generation because we were at the beginning of the
 Internet blooming. There are folks on this forum that go back further. Into
 DARPA. Before DARPA was just chapter 1 one every single Cisco Press book.
 They have a unique understanding of the layers. I had that understanding in
 my 20s. The technology is so complicated these days that many folks miss
 those fundamentals and go right into VSS on the 6500s or MPLS over Juniper.
 In the end, it all comes in time.


 -Hammer-

 I was a normal American nerd
 -Jack Herer



 On 2/17/2012 9:12 AM, Mario Eirea wrote:

 Well, I will argue this. I think the important factor in any
 troubleshooting is having a real understanding of how the system works. That
 is, how different things interact with each others to achieve a specific
 goal. The biggest problem I see is that many people understand understand
 the individual parts but when it comes to understanding the system as a
 whole they fall miserably short.

 A short example, probably not the best but the one that comes to mind
 right now:

 Someone replaces a device on the network with a new one. They give it the
 same IP address as the old device. They don't understand why the router cant
 communicate with it at first and then starts working. The people
 understand ARP, but cant correlate one event with another.

 I guess if your 35 you have seen this at least once and can fix it. But
 what happens if you have never seen this problem or a related one? At this
 point your going to have to really troubleshoot, not just go on experience.

 Mario Eirea
 
 From: -Hammer- [bhmc...@gmail.com]
 Sent: Friday, February 17, 2012 9:52 AM
 To: nanog@nanog.org
 Subject: Re: Common operational misconceptions

 Let me simplify that. If you are over 35 you know how to troubleshoot.

 Yes, I'm going to get flamed. Yes, there are exceptions in both
 directions.

 -Hammer-

 I was a normal American nerd
 -Jack Herer



 On 2/17/2012 8:29 AM, Leo Bicknell wrote:

 In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
 Graydon wrote:

 At the same time, it's shocking how many network people I come across
 with no real grasp of even what OSI means by each layer, even if it's
 only in theory.  Just having a grasp of that makes all the world of
 difference when it comes to troubleshooting.  Start at layer 1 and work
 upwards (unless you're able to make appropriate intuitive leaps.) Is it
 physically connected? Are the link lights flashing? Can traffic route to
 it, etc. etc.

 I wouldn't call it a misconception, but I want to echo Paul's
 comment.  I would venture over 90% of the engineers I work with
 have no idea how to troubleshoot properly.  Thinking back to my own
 education, I don't recall anyone in highschool or college attempting
 to teach troubleshooting skills.  Most classes teach you how to
 build things, not deal with them when they are broken.

 The basic skills are probably obvious to someone who might design
 course material if they sat down and thought about how to teach
 troubleshooting.  However, there is one area that may not be obvious.
 There's also a group management problem.  Many times troubleshooting
 is done with multiple folks on the phone (say, customer, ISP and
 vendor).  Not only do you have to know how to troubleshoot, but how
 to get everyone on the same page so every possible cause isn't
 tested 3 times.

 I think all college level courses should include a break/fix
 exercise/module after learning how to build something, and much of that
 should be done in a group enviornment.

Re: NIST IPv6 document

[Marcel Plug]

Perhaps we're reaching the point where we can say We don't need an ND
table for a /64 network.  If the ethernet MAC is embedded in the IPv6
address, we don't need to discover it because we already know it.  If
the IPv6 address has been manually configured on a host, perhaps that
host should now accept traffic directed to the MAC that the lower 64
bits of the IPv6 address would translate to.

Perhaps this idea has been discussed somewhere and discarded for its
flaws, but if not, perhaps it should be :-).

Marcel

(First post by the way, go easy on me :-)

On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates jba...@brightok.net wrote:

 On 1/6/2011 12:26 AM, Joe Greco wrote:

 A bunch of very smart people have worked on IPv6 for a very long
 time, and justification for /64's was hashed out at extended length
 over the period of years.

 NDP should have been better designed. It still has the same problems we had
 with ARP except the address pool has magnified it.

 Routers should have 1) better methods for keeping ND tables low (and
 maintaining only valid entries) or 2) better methods for learning valid
 entries than unsolicited NDP requests.

 This isn't to say the protocol itself is a waste, but it should have taken
 in the concerns and developed the mitigation controls necessary as
 recommendations to the implementers.


 Jack