[193591] in North American Network Operators' Group
Re: IoT security
daemon@ATHENA.MIT.EDU (Michael Thomas)
Mon Feb 6 19:10:16 2017
X-Original-To: nanog@nanog.org
To: nanog@nanog.org
From: Michael Thomas <mike@mtcc.com>
Date: Mon, 6 Feb 2017 16:10:01 -0800
In-Reply-To: <CAP-guGVC2jkUxQTdM1UinSKxK5UPZ42FeBBF1BmUBBHGbVaWUA@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
On 2/6/17 2:31 PM, William Herrin wrote:
> This afternoon's panel about IoT's lack of security got me thinking...
>
>
> On the issue of ISPs unable to act on insecure devices because they
> can't detect the devices until they're compromised and then only have
> the largest hammer (full account ban) to act...
>
> What about some kind of requirement or convention that upon boot and
> successful attachment to the network (and maybe once a month
> thereafter), any IoT device must _by default_ emit a UDP packet to an
> anycast address reserved for the purpose which identifies the device
> model and software build. The ISP can capture traffic to that anycast
> address, compare the data against a list of devices known to be
> defective and, if desired, respond with a fail message. If the IoT
> device receives the fail message, it must try to report the problem to
> its owner and remove its default route so that it can only communicate
> on the local lan. The user can override the fail and if desired
> configure the device not to emit the init messages at all. But by
> default the ISP is allowed to disable the device by responding to the
> init message.
Uh, yuck at many levels. Do you leak your cisco ios versions to the
internet?
Do you really want the responsibility for the remote kill switch for IoT
S&M gear?
And of course, you're depending on rfc 3514, right?
Mike
