IoT security

William Herrin bill at herrin.us
Mon Feb 6 22:31:10 UTC 2017


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.

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.



The presentation on bandwidth policers...

Seems like we could use some form of ICMP message similar to
destination unreachable that provides some kind of arbitrary string
plus the initial part of the dropped packet. One of the potential
strings would be an explicit notice to the sender that packets were
dropped and the bandwidth available.

Yes, we already have ECN, but ECN tells the receiver about congestion,
not the sender. More to the point, ECN can only be flagged on packets
that are passed, not the packets that are dropped, so the policer
would have to be complicated enough to note on the next packet that
the prior packet was dropped. Also, ECN only advises that you're close
to the limit not any information about the policer's target limit.

This thought is not fully baked. Throwing it out for conversation purposes.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>



More information about the NANOG mailing list