Re: Spitballing IoT Security
On Fri, Nov 11, 2016 at 1:55 AM, Eliot Learwrote: > 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
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
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
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
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)
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
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
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
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
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