This is a review of draft-ietf-opsec-v6 from the IoT Directorate perspective. I am a volunteer on the IoT, and do not speak authoritatively for the IoT Directorate as a whole. My impression of this document is that it's useful, but could use some work. Some of my comments below are coming strictly from an IoT perspective; others are more general. --- The document doesn't talk about its intended audience. It appears to be the case based on my reading of it that the intended audience is enterprise operators and similar. This should be stated clearly and explicitly. Some of the advice in this document would be actively harmful if deployed on an unmanaged network (e.g. in a home). That doesn't mean that the document is bad—just that it needs to be scoped appropriately. I would suggest adding a brief statement of applicability in the abstract and a more detailed explanation in the introduction. It is important that this statement make clear that the advice in this document must not be followed by implementers of home routers and similar devices. E.g., this advice would utterly break a Thread (IPv6 over 802.15.4 mesh) Border Router. It's also not clear that this document lives up to its abstract. The abstract says: This document analyzes the operational security issues in several places of a network (enterprises, service providers and residential users) and proposes technical and procedural mitigations techniques. And yet if you look for example at section 2.1.1, there is no actual analysis of the use of ULAs, nor is any advice on their use provided. Section 2.1.4 doesn't mention using DHCP to provide hosts with obfuscated address that, since known to the operator, can be added to filter lists as appropriate, while still making probing mathematically challenging to an outside attacker. Section 2.1.6 incorrectly implies that DHCPv4 binds IP addresses to link-layer addresses. This is not true. I don't know that it really matters, but since it's not true, you should fix it. DHCPv4 uses a "client identifier," which is quite similar to a DUID. If no client identifier is offered, then the link-layer address is used, but this is not required, and the behavior described for DUIDs in this document is also applicable to client identifiers. 2.1.7 seems to be continuing a thought that was started in 2.1.4. It would be worth stating that explicitly, and comparing and contrasting these approaches. Although the abstract explicitly excludes applicability to IoT networks, the advice in this document will necessarily be taken as applicable in situations where IoT networks are leaf networks or even infrastructure that is present alongside the networks that _are_ covered by this document. This has some specific impacts that aren't talked about here and should be. For instance, Manufacturer Usage Descriptions (MUD) are not mentioned, and should be. MUD is applicable to infrastructure devices and really any special-purpose device; e.g., MUD would be highly appropriate for use in hospital environments where many devices are connected to the network that absolutely must have their accessibility controlled; MUD is a good candidate for doing this. The omission of this approach from section 2,1 is a major gap, since the issues discussed in section 2.1 directly impact the feasibility of using MUD (since MUD specifies firewall behavior for devices, and devices are necessarily identified by source address). The conclusion I'm drawing having gotten to the end of section 2.1, in addition to what I've said above, is that some of the issues introduced in subsections of section 2.1, like filterability of host addresses, really belong in the initial section 2.1 introduction, so that the subsections of 2.1 can refer back and give the reader a coherent picture, rather than requiring the reader to synthesize this as they read through the subsections. Section 2.3.2 talks about the threat of a MITM attack through the use of forged RAs, but doesn't actually describe how prevalent such on-link attacks are (this would be an on-link attack) nor does it talk about how such an on-link attack would be more effective than an attack the attacker could do without this capability. Without a threat model, this is somewhat hypothetical. Section 2.3.2 goes on to talk at length about how to make RA Guard work, without talking about when it is useful, what attacks it prevents, and what problems it causes when deployed incorrectly. We have actually run into serious problems working on the Thread Border Router specification because of uncertainty about whether RA Guard may be present on a network to which the TBR is attached. If it is, then the easiest way for the TBR to advertise reachability is gone, and we have to resort to bypasses such as ND Proxy, reverse NAT64, NAT66, or tunnels, just in order to ensure reachability of the leaf network. I think it's actively harmful to recommend the use of RA guard without talking about the problems it causes and how to mitigate them. This section should explicitly say that RA guard should never be enabled by default: it should be the case that the operator enables it explicitly, and that in cases where there is no operator with the authority to set routing policy for a link, RA guard should not be used on that link. SAVI is another extremely useful technology that can't really be deployed automatically without creating similar problems. To be clear, my goal here is not to say that the document shouldn't recommend RA guard or SAVI, but rather that it should be very clear about when to deploy it and when not to. In section 2.3.5, what is a "generic operating system?" I don't know what this term means. Can you use a term with a clearer meaning? One thing I didn't see discussed in section 2 that I think belongs there is the concept of isolation of networks. Networks that provide connectivity to general-purpose devices like phones and comouters may need to provide flexibility of addressing for privacy reasons. Infrastructure devices, particularly those for which MUD is applicable, may need to be on networks where filtering is present and addressing is tightly controlled. There's no discussion fo this kind of separation in the document, and I think it's a serious gap.