[iot-wg] Resolution of issues raised in onboarding document Re: To be published: Architectural Considerations for IoT Device Security in the Home
- Previous message (by thread): [iot-wg] To be published: Architectural Considerations for IoT Device Security in the Home
- Next message (by thread): [iot-wg] To be published: Architectural Considerations for IoT Device Security in the Home
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Eliot Lear
lear at lear.ch
Fri Feb 26 15:44:35 CET 2021
Hi all, Here are the proposed resolutions to the comments raised: On 12.02.21 17:16, JORDI PALET MARTINEZ via iot-wg wrote: > > Hi all, > > I’m not sure if this should be considered in this document or other > future ones, or other foras. > > 1. Should IoT devices be allowed to send information to the cloud > “always” or the user must have the choice to disable that? I’ve > seen many devices, even CPEs, using OpenWRT or a derivative > firmware, sending stuff to the manufacturer, “hijacking DNS”, etc. > This may be even a regulatory issue. > As Michael alluded, this might be suitable for a different document, but ours is more focused on guidance for ISPs and firewall manufacturers, and less so toward IoT device manufacturers, particularly when it comes to regulatory compliance matters. > 1. > > > > 2. Should IoT devices have a standard API to be managed? Otherwise, > consumers are unprotected and they may need to throw to the trash > can hundreds of euros in case of a manufacturer Cloud failure, > vendor bankruptcy, vendor failure to provide security updates, > etc., etc. > While the authors agree that this is an important issue, it seems like one to be taken up in a different document for the reasons discussed above. This may be a better topic for ETSI. I will also note that there is the possibility that the Connected Home IP Alliance (CHIP) will be going right there very soon. > In my opinion both are related to device security in the Home. I’m > also not saying is in the scope of this WG, as said, it may come to > IETF, other standardizations foras, even regulation. It is like when > we regulate if a device complies with FCC, CE mark, UL, etc., etc., > but in terms of security or consumer protection. > Agree, but see above. > One last point. I think it will be very useful to have page numbers in > this (and every) document … also in other BCOP documents, we added an > annex with terminology. > Page numbering depends on the publication format, and that is up to RIPE NCC, not the authors. We do explain the terminology as we go, and this is not a lengthy document that risks bloating a bit. Unless people insist, we would rather not. Toma asked for some slight modifications to the text relating to there being only two L4 protocols. We propose the following changes: "Comparing internet layer and layer four information to known deny-lists ("blocklists")" and "Validating that the internet layer and layer four information matches an associated MUD profile" Martin asked for a reference to ntopng. We have added a footnote that points to ntop.org. We'll send an updated version shortly, assuming nobody objects to these resolutions. For the authors, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/iot-wg/attachments/20210226/c250be4a/attachment.html>
- Previous message (by thread): [iot-wg] To be published: Architectural Considerations for IoT Device Security in the Home
- Next message (by thread): [iot-wg] To be published: Architectural Considerations for IoT Device Security in the Home
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ iot-wg Archives ]