Hi Töma And it is phrased slightly awkwardly.  How about this: "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" ? Eliot On 12.02.21 14:42, Töma Gavrichenkov wrote:

Peace,

On Fri, Feb 12, 2021, 3:56 PM Constanze Dietrich <constanze.die@gmail.com <mailto:constanze.die@gmail.com>> wrote:

Since RIPE 81, the "BCOP" document was refined again and now declared DONE under the title: "Architectural Considerations for IoT Device Security in the Home" (document attached).

Section 4 sort of implies that there are only two Layer 4 protocols.  It'd be very nice if the final RIPE document doesn't have such implications.

-- Töma

_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg

JORDI PALET MARTINEZ via iot-wg <iot-wg@ripe.net> wrote: > I’m not sure if this should be considered in this document or other > future ones, or other foras. > 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. No, this document is not really about that. It's above our pay grade. This document is about getting a handle on how any control would work, rather than if, or under what regulation. > 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. point. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

Hi Elliot, all, Fine with most of the points, especially if there are changes for CHIP or ETSI to dig on those issues. Regarding the numbering, I fully understand that the final page numbering depends on the RIPE publication … however, because the “draft” document has an index/ToC, it should not be too much difficult, to improve readability when you forward the new version, to include pages numbers already. It helps to be able to follow the index and also to be able to refer to specific issues, etc. Finally, regarding terminology, in the BCOP WG we had this discussion several times, and it seems that in general people prefers to have a specific terminology section. See for example RIPE-690, last section. I’m personally fine either way. Regards, Jordi @jordipalet El 26/2/21 15:45, "iot-wg en nombre de Eliot Lear" <iot-wg-bounces@ripe.net en nombre de lear@lear.ch> escribió: 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. 2. 3. 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 _______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.