That’s a big improvement, Éric. Thanks! > On Feb 12, 2021, at 10:31 AM, Eric Vyncke (evyncke) <[email protected]> wrote: > > Ted, > > As you guessed in your email : we, the authors, do not want to prevent > multi-homing ;-) E.g., we already have several ‘do not apply in all cases’ > for several mitigation techniques include the RA-guard one for obvious reason. > > Just to be clear, we have used your suggestion to modify the abstract and add > an applicability statement in a -24 version (yet to be published). We would > appreciate it if you reviewed the proposed change below. > > --- start of abstract --- > Knowledge and experience on how to operate IPv4 securely is > available: whether it is the Internet or an enterprise internal > network. However, IPv6 presents some new security challenges. RFC > 4942 describes the security issues in the protocol, but network > managers also need a more practical, operations-minded document to > enumerate advantages and/or disadvantages of certain choices. > > This document analyzes the operational security issues associated > with several types of network and proposes technical and procedural > mitigation techniques. This document is only applicable to managed > networks, such as enterprise building networks. The recommendations > in this document are not applicable to residential user cases, even > in cases where a Service Provider may be managing the home gateway. > > --- end of abstract --- > > --- start of applicability statement (sub-section of introduction) --- > 1.1. Applicability Statement > > This document is applicable to managed networks, i.e., when the > network is operated by the user organization itself. Indeed, many of > the recommended mitigation techniques must be configured with the > detailed knowledge of the network (which are the default router, > which are the switch trunk ports, etc.). This covers Service > Provider (SP), enterprise networks and some knowledgeable-home-user- > managed residential network. This applicability statement especially > applies to Section 2.3 and Section 2.5.4. > > For example, an exception to the generic recommendations of this > document is when a residential or enterprise network is multi-homed. > > > --- end of applicability statement (sub-section of introduction) --- > > Regards > > -éric > > From: Ted Lemon <[email protected]> > Date: Tuesday, 9 February 2021 at 16:59 > To: Eric Vyncke <[email protected]> > Cc: Merike Kaeo <[email protected]>, Kiran Kumar Chittimaneni > <[email protected]>, Enno Rey <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 > > Éric, to be clear, your latest changes do not successfully address my > comments. For example, you talk about a managed ISP router, and say that it’s > okay for such a router to do all kinds of blocking on the home network. It’s > not—what does the ISP know of the home network? How is the ISP qualified to > set security and reachability policy on the home network? > > This will cause major operational problems. Any network on which this is > deployed will break stub networks, such as are used by the HomePod Mini and > Google’s Nest gateway to provide reachability to Thread networks. > > The text that I think you added to address my concerns is this: > > The residential users case assumes a managed ISP CPE > device. Some very specific types of networks such as the Internet of > Things (IoT) and unmanaged home networks are not discussed in this > document. > > This is not helping. The text should read this way: > > This document is only applicable to managed networks, such as enterprise > building networks. The recommendations in this document are not applicable > to residential user cases, even in cases where an ISP may be managing the > home gateway. > > If you really want this to apply to the ISP-managed home network router, it > should only be in the case where the ISP is providing a value-added > service—where the home user is actually paying for a person to manage their > network, not just to have an ISP-owned router that maybe gets regular > firmware updates and some centrally-managed malware site blocking. If you > were to address this use case (which I think is really unnecessary), this > document needs to talk about what an ISP would have to do to avoid creating > interop problems for IoT networks in the home. This needs to be very explicit > and needs to be mentioned in the sections where you talk about RA filtering > and ND filtering. > > Sorry to be a sticky wicket, but I am afraid I failed to fully communicate > the seriousness of this problem back in 2019. > > Also, I don’t mean to minimize the problem you are trying to address. I’m > just saying that we don’t have the technology to address it right now, and > trying to address it on an effectively unmanaged network with existing > technology will create serious interoperability problems. > > In addition to the IoT stub networks issue, following this document on a home > network would also eliminate multi-homing, which I hope is not something that > we are proposing to do. > > >> On Feb 9, 2021, at 8:04 AM, Eric Vyncke (evyncke) <[email protected] >> <mailto:[email protected]>> wrote: >> >> Ted, >> >> Just to confirm that the revision -23 should have all your review items >> addressed except the 3 cited by Merike. >> >> The section 2.3.2 has been revised extensively. >> >> Thank you again for this review >> >> -éric >> >> >> -----Original Message----- >> From: Merike Kaeo <[email protected] >> <mailto:[email protected]>> >> Date: Thursday, 5 December 2019 at 20:13 >> To: Ted Lemon <[email protected] <mailto:[email protected]>>, Eric Vyncke >> <[email protected] <mailto:[email protected]>>, Kiran Kumar Chittimaneni >> <[email protected] <mailto:[email protected]>>, Enno Rey >> <[email protected] <mailto:[email protected]>> >> Cc: <[email protected] <mailto:[email protected]>> >> Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 >> >> Hello Ted. >> >> Very much appreciate the thorough review of the document. All 4 authors >> agree with most of your comments which will be incorporated >> in the next revision (also includes the discussion between yourself, Gyan >> and Suresh re DHCPv6). For the comment re section 2.3.2 and >> RAs, can you point us to the relevant specifications for the TBR (Threat >> Boarder Route) so that we can come up with a potential addition that >> discusses the (non-) applicability of RA for certain scenarios? >> >> For 3 comments the authors want to preserve the existing language for >> reasons stated below. >> >> 2.1.1 on ULA: The very first draft had some specific language on ULA use >> and the topic of ULAs has been a major contention area to get to working >> group last call. Some individuals felt for years that the discussion on ULA >> should be to state that they are not required and not recommended while >> others wanted to be more explicit on recommended language *if* ULAs are >> used. The current language on ULAs reflects working group rough consensus >> after many iterations of language. Te authors would recommend that the >> language not be changed at this point. >> >> 2.1.7 re /64s. The section references rfc8273 and the working group felt >> that re-iterating even in more detail that work, which provides the added >> context, was not necessary in the document itself >> >> Last comment on Isolation of Networks - While we did not discuss varying >> network configurations, usually more explicit details are provided in the >> rfcs we reference. rfc8273 referenced in Section 2.1.7 and rfc7721 >> referenced in section 2.1.8 are some examples. >> >> - merike >> >> >>> >>> --- >>> >>> 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. >>> >>> >>> _______________________________________________ >>> OPSEC mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/opsec >>>
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
