IoT security

joel jaeggli joelja at bogus.com
Tue Feb 7 00:14:54 UTC 2017


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.
self identification is privacy hostile and tantamount to indicating a
willingness to be subverted (this is why we disable lldp on external
interfaces) even if it would otherwise be rather useful. the use of
modified eui64 addresses as part of v6 address selection hash basically
gone away for similar reasons.
> Would have to cryptographically sign the fail message and let the
> device query the signer's reputation or something like that to avoid
> the obvious security issue. Obvious privacy issues to consider.
> Anyway, throwing it out there as a potential discussion starting
> point.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20170206/cbe737d6/attachment.sig>


More information about the NANOG mailing list