Re: Spitballing IoT Security

["Ronald F. Guilmette" <rfg () tristatelogic com>]

In message <20161026123043.GA10916 () thyrsus com>, 
"Eric S. Raymond" <esr () thyrsus com> wrote:

> There is, however, a chokepoint we have more hope of getting decent software
> deployed to.  I refer to home and small-business routers.  OpenWRT and kin
> are already minor but significant players here. And there's an NRE-minimization
> aregument we can make for router manufacturers to use rebranded versions
> rather than rolling their own crappy firmware.
>
> I think the anti-IoT-flood strategy that makes the most sense is:
>
> 1. Push open-source firmware that doesn't suck to the vendors with a
>   cost- and risk-minimization pitch.
>
> 2. Ship it with egress filters.  (And telnet blocked.)

So basically, this is a proposal to "fix" the problem for all IoT devices
that are behind SOHO routers.

I am compelled to note that the grand vision of the Home of the Future[tm],
as it has been presented to me at least, looks rather more like this:

    http://p.globalsources.com/IMAGES/PDT/BIG/053/B1088622053.jpg

i.e. a multitude of wall plates in every room, each one bristling with a
multitude of RJ11 sockets into which all manner of shiny new IoT things
will be directly plugged, thence to be issued their own IPv6 addresses
directly via DHCP from the local provider.

If I have misunderstood the general direction is which we are all heading,
then I will be only too happy to be disabused of my incorrect notions.

> It wouldn't be technically very difficult to make the firmware
> rate-limit outbound connections...

No, but if you do that to my desktop PeeCee, then I'm gonna be pretty mad
at you.

On the other hand, if you come up with a way for devices to somehow signal
to an associated SOHO router that they are either (a) desktop PeeCees or,
in the alternative, IoT devices, and if you should me that you method is
(a) simple and (b) fool-proof and (c) hack-proof, then I'll be the first
one to say that you're really on to something.


Regards,
rfg


P.S.  As noted in my prior post, the proplem of regulating IoT devices to
insure that they do not exceed their reasonably expected operational limits,
vis-a-vis outbound bandwidth usage, is in some ways reminicent of the FCC
regulations which, ideally, prevent SOHO WiFi routers from exceeding
reasonable power output limits designed to prevent them from interfering
with other devices.

Given that, and given that "OpenWRT and kin" often provide the end-user
with readily accessible dials and knobs via which the user can force the
device to *exceed* legal/FCC limits on power output, I am not persuaded
that open source WiFi router firmware actually represents a shining
example of a methodology to prevent inexpensive devices from behaving badly.