This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/iot-wg@ripe.net/
[iot-wg] New on RIPE Labs: Visualisations of Periodic IoT Traffic
- Previous message (by thread): [iot-wg] New on RIPE Labs: Visualisations of Periodic IoT Traffic
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Poonam Yadav
poonam.hiwal at gmail.com
Thu Mar 26 00:45:41 CET 2020
Thank you Eliot and Michael for this thoughtful discussion and sharing the draft. I agree with you regarding the security issue with shared cloud infrastructure and DNS. However on IoT device side, do you think, a hardware based authentication (e.g., quantum tunnelling - https://www.cryptoquantique.com/solution ) may solve some of these issues? Best regards, Poonam On Thu, Mar 19, 2020 at 5:47 PM Michael Richardson <mcr+ietf at sandelman.ca> wrote: > > Eliot Lear <lear at lear.ch> wrote: > > Thanks. The concern here is that the device could choose to > identify as > > something else through a set of false communications. It is indeed > an > > interesting area of research. I am not saying there is nothing to be > > done, but it is something that requires careful consideration as we > aim > > toward automating policy. I fear in particular that the cloud makes > > this quite a bit harder, and IOT manufacturer use of their own DNS > > infrastructure will make it yet more difficult, because we are all > using > > the same cloud infra. > > Manufacturers SHOULD avoid using their own DNS infrastructure in my > opinion. > > Operational Considerations for use of DNS in IoT devices > draft-richardson-opsawg-mud-iot-dns-considerations-01 > > Abstract > > This document details concerns about how Internet of Things devices > use IP addresses and DNS names. The issue becomes acute as network > operators begin deploying RFC8520 Manufacturer Usage Description > (MUD) definitions to control device access. > > This document explains the problem through a series of examples of > what can go wrong, and then provides some advice on how a device > manufacturer can best make deal with these issues. The > recommendations have an impact upon device and network protocol > design. > > ..co-authors, reviews, pull-requests and comments sought. > > {I'm annoyed that the DNSOP group declined to define "QuadX" as a term in > ietf-dnsop-terminology-ter. Actually, I don't care what it's called, as > along > as I have a term for such public recursive services} > > -- > Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > iot-wg mailing list > iot-wg at ripe.net > https://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/iot-wg/attachments/20200325/345ad599/attachment.html>
- Previous message (by thread): [iot-wg] New on RIPE Labs: Visualisations of Periodic IoT Traffic
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ iot-wg Archives ]