[iot-wg] Resolution of issues raised in onboarding document Re: To be published: Architectural Considerations for IoT Device Security in the Home

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: </ripe/mail/archives/iot-wg/attachments/20210226/c250be4a/attachment.html>