[Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 07 January 2021 15:02 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: detnet@ietf.org
Delivered-To: detnet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 612A43A11D7; Thu, 7 Jan 2021 07:02:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-security@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <161003177336.17207.9873492659985883272@ietfa.amsl.com>
Date: Thu, 07 Jan 2021 07:02:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/HvIYQtTRzjSSZ-LhuzIrjuMEoII>
Subject: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 15:02:53 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-detnet-security-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- We say that we adhere to the guidelines of RFC 3552, yet we do not mention that it may be impossible to achieve our goals "in the face of a highly capable adversary, such as the one envisioned by the Internet Threat Model of BCP 72 [RFC3552] that can arbitrarily drop or delay any or all traffic" (to quote from a recent DetNet RFC that does cover this topic, RFC 8939). I think that in order to fully adhere to RFC 3552, we need to be more explicit about how we have to assume a reduced attacker capability set in order to make any progress at all. A good place for this discussion would be near where we state that security a DetNet starts with a scrupulously well-designed and well-managed engineered network in Section 1 -- the goal of having the well-managed network is to exclude some of the more powerful adversary capabilities from the Internet Threat Model. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the secdir reviewer that additional linkage between threats that the potential mitigations for them would be useful, albeit somewhat time-consuming to add. This is much-improved from the last time I looked at it; thank you for continuing to make improvements! I do still have a sizeable number of comments, though; hopefully they will help to make further improvements. I suspect that we would do well to reiterate the theme that has appeared in the security considerations of the several most recent detnet RFCs, along the lines of "achieving the goals of detnet may not be possible in the face of a highly capable adversary, such as the one envisioned by the Internet Threat Model of BCP 72 [RFC3552] that can arbitrarily drop or delay any or all traffic", especially since we say that we otherwise adhere to RFC 3552's guidelines. A good place for this discussion would be near where we state that security a DetNet starts with a scrupulously well-designed and well-managed engineered network in Section 1 -- the goal of having the well-managed network is to exclude some of the more powerful adversary capabilities from the Internet Threat Model. We should say that explicitly. Section 2 Resource Segmentation Used as a more general form for Network nit: missing colon Section 3.3 be protected by using MACsec [IEEE802.1AE-2018]. Similary, from the sequence number injection perspective, it is no different from any other protocols that use sequence numbers. Many other protocols that use sequence numbers are in practice vulnerable to sequence number injection. Having specific references to other protocols that are protected against such injection seems like it would be useful. Section 4 However DetNet also introduces timing and other considerations which are not present in DiffServ, so the DiffServ security considerations are necessary but not sufficient for DetNet. In my experience, security considerations are typically statements of fact about the properties of a protocol/system, as opposed to requirements for secure operation; in that context it is better to say that the diffserv security considerations are a subset of the detnet security considerations, as opposed to the current "necessary but not sufficient" phrasing. In DetNet, there are similar consequences to DiffServ for lack of detection of, or incorrect handling of, packets with mismarked DSCP values, and many of the If I understand correctly, the detection/handling in question here is specifically at ingress to the domain? Section 5.1 [I'll note for completeness that I still would prefer this to be called a taxonomy of threats rather than a threat model, but we've had the conversation about how this formulation is analogous to that of RFC 7384 and there's nothing left to say. No response needed; I'm just recording that we agreed to disagree.] o Internal vs. external: internal attackers either have access to a trusted segment of the network or possess the encryption or authentication keys. External attackers, on the other hand, do not have the keys and have access only to the encrypted or authenticated traffic. I think it is common to use "external" to refer to attackers that are entirely outside of a domain and are limited to attmping to send packets into the domain, with no visibility into legitimate traffic inside the domain. The description here suggests that the boundary between "internal" and 'external" is more of a logical one, perhaps relating to access to physical packets (in encrypted form) vs unprotected packts (as available to internal systems), but perhaps there is intended to also be a "secure network" where the physical packets contain the logical data but are physically inaccessible to the attacker. Section 5.3 alludes to the existence of some "security mechanism" that provides the boundary between external and internal attackers, but leaves the actual nature of the boundary unclear, for me. [This looks like it's basically the same as Roman's first discuss point, which I support.] o On-path vs. off-path: on-path attackers are located in a position that allows interception and modification of in-flight protocol packets, whereas off-path attackers can only attack by generating protocol packets. We sometimes differentiate between (e.g.) "active" or "passive" on-path attackers, where interception/viewing is done in either form but modification only done in the "active" form. Section 5.2.3 I don't understand why the section title includes "Resource Segmentation"; the scenario being described seems to discuss risks that are present when resources are *not* properly segmented. Resource Segmentation by itself should not be a threat in this regard. An attacker can inject traffic that will consume network resources such that it affects DetNet flows. This can be performed using non- DetNet traffic that indirectly affects DetNet traffic (hardware resource exhaustion), or by using DetNet traffic from one DetNet flow that directly affects traffic from different DetNet flows. I don't understand what is meant by "detnet traffic from one flow that directly affects traffic from different detnet flows". How might this happen? Section 5.2.4.2 bridge, the flow is hijacked by the attacker. It is now posible to either replace en route packets with malicious packets, or simply injecting errors, causing the packets to be dropped at their destination. nit: s/injecting/inject/ Section 5.2.5.2 An attacker can subvert a controller, or enable a compromised controller to falsely represent itself as a controller so that the network nodes believe it to be authorized to instruct them. I can't tell if "compromised controller" was a typo that was supposed to refer to some non-controller class of entity, so that the false representation as a controller is a significant change in node capability. Section 5.2.6 A passive eavesdropper can identify DetNet flows and then gather information about en route DetNet flows, e.g., the number of DetNet flows, their bandwidths, their schedules, or other temporal properties. [...] I suggest "other temporal or statistical properties" to encompass things like latency and jitter, which are only in some limited sense temporal properties. DetNet flows are typically uniquely identified by their 6-tuple, i.e. fields within the IP header, however in some implementations the flow ID may also be augmented by additional per-flow attributes known to the system, e.g. above the IP-layer. [...] pedantically, the ports in the 6-tuple are also above the IP layer. For the purpose of this document we assume any such additional fields used for flow ID are encrypted and/or integrity-protected from external attackers. I suggest adding a note that existing OT protocols designed for use on dedicated secure networks may not intrinsically provide such protection, in which case IPsec or transport layer security mechanisms may be needed. (I do see a note on a similar or more generic topic already in §6, but don't think there is harm in having another one.) Section 5.3 How can an off-path attacker perform a delay attack? Section 6 What is the distinction between "Health and Safety" and "People Well Being"? Safety, People well being (People WB), Affect on a single organization, and affect on multiple organizations. Recovery nit: s/Affect/Effect/ in both lower and upper case forms (the table, fortunately, is already correct) Why is M2M control listed as only having low impact from data integrity? I would have thought that integrity of the control plane information would be pretty important. Section 6.1.1 For a single path scenario, disruption is a real possibility, whereas in a multipath scenario, large delays or instabilities in one DetNet flow can lead to increased buffer and processor resources at the eliminating router. nit: I think s/resources/resource consumption/ Section 6.2.1 I think it might be more interesting to mention the scope of potential harm when the corrupted or modified payloads are interpreted, rather than just saying that they could be modified. Drvyion 6.3.2 I think the primary concern here is that there will be skew between the "reality" in the individual nodes and the expected state known to the controller, such that when the controller attempts to make changes in the future the actual actions will differ. The specifics of how the initial skew occurs is less interesting, and essentially equivalent to the spoofing case. Section 6.4.x I think the referenced coverage is perhaps too brief to be useful. Section 6.8 In the context of this section, we should be talking about the discussion or description of the impact of attacks; how attacks are "addressed" would be analogous to the mitigations that we cover in §7. Section 7.2 An integrity protection mechanism is designed to counteract header modification attacks where a Message Authentication Code (MAC) is the most common. [...] nit: the "a MAC is most common" seems to bind to "header modification attacks", not "integrity protection mechanism; I suggest NEW: An integrity protection mechanism is designed to counteract header modification attacks. A Message Authentication Code (MAC) is the most common such mechanism. The MAC can be distributed either in-line (included in the same packet) or via a side channel. Due to the nature of DetNet traffic. [...] nit: incomplete sentence? replication attacks (see Section 5.2.2 and Section 5.2.4). This MAC usage needs to be part of a security association that is established and managed by a security association protocol (such as IKEv2 for IPsec security associations). Integrity protection BCP 107 might be a good reference here. sequence numbers are not modifiable. Thus, sequence numbers can be protected by using encryption, or by a MAC without using I suggest s/encryption/authenticated encryption/; an unqualified "encryption" is easy to interpret as something like a stream or block cipher mode without integrity protection, which is malleable without detection. encryption. Between the adder and remover there may or may not be replication and elimination functions. The elimination functions must be able to see the sequence numbers. Therefore, if encryption is done between adders and removers it must not obscure the sequence number. If the sequence removers and the eliminators are in the same physical component, it may be possible to obscure the sequence number, however that is a layer violation, and is not recommended practice. [...] It would also be technically feasible (but very ill-advised) to share the encryption key with the elimination function and continue to use encrypted sequence numbers. This is ill-advised because two-party security with a shared symmetric secret provides much stronger peer authentication than group seciryt with a shared symmetric secret. Section 7.4 I suggest reiterating that it is expected that cryptographic confidentiality protection is applied to traffic; dummy traffic is generally ineffectual when the plaintext is visible to the attacker. Section 7.5 Note that reconnaissance is a threat that is not specific to DetNet flows, and therefore reconnaissance mitigation will typically be analyzed and addressed by a network operator regardless of whether DetNet flows are deployed. [...] nit: I suggest s/addressed/provided/ since "addressed" usually implies that the thing in question is a problem that needs to be mitigated, but we are describing the mitigation itself. Section 7.5.1 Any compute time which is required for encryption and decryption processing ('crypto') must be included in the flow latency calculations. Thus, crypto algorithms used in a DetNet must have bounded worst-case execution times, and these values must be used in the latency calculations. (In general, crypto operations should have constant execution times, to avoid side channel leakage.) If crypto keys are to be regenerated over the duration of the flow then the time required to accomplish this must be accounted for in the latency calculations. [In contrast to my previous comment, key generation is a cryptographic operation that is frequently not possible to implement in constant time, most notably thoguh not exclusively for RSA key pairs.] Section 7.7 Making DPA measurement results available at the right place(s) and time(s) to effect timely response can be challenging. Two notification mechanisms that are in general use are Netconf/YANG Notifications (e.g. [RFC5880]) and the proprietary local telemetry interfaces provided with components from some vendors. I think that CoAP Observe (RFC 7641) could also apply to such scenarios, but I don't have enough information to be able to say whether it is "in general use" for this purpose. Performance analytics can be used to mitigate various attacks, including the ones described in Section 5.2.1 (Delay Attack), Section 5.2.3 (Resource Segmentation Attack), and Section 5.2.7 (Time Synchronization Attack). Mitigate, or just detect? (May also affect Figure 3.) Section 7.8 In my mind the "Replication: increased attack surface" attack included the potential for the replicated data stream to be available (and thus subject to reconnaissance) in more places, in addition to there being more devices relevant to a given flow and susceptible to attack. In that case, encryption would also be a relevant mitigation, but it is not currently listed as one. We list "control message protection" as a potential mitigation for several rows in the table, but I do not see where there is prose discussing what that mitigation entails. Section 8.1.1 Some subnetwork layers other than ethernet might have additional attacks and impacts that are not relevant to ethernet. A prominent example would be radio technologies, where the broadcast domain is "anyone with an antenna", though this is probably not the only example of affected subnetwork technology or additional attack/impact. Section 8.1.3 To mitigate this situation, deployments should provide a method for dynamic and secure registration of new components, and (possibly manual) deregistration of retired components. This would avoid the situation in which the network must accommodate potentially insecure packet flows from unknown components. [The IETF has specified a number of enrolment and bootstrapping protocols (EST, BRSKI, SZTP, CMC, CMP, etc.), though it's not clear that it's helpful to informatively reference any particular ones, here.] Section 8.1.5 Please note that although there are no entries in the L2 and L3 Integration line of the Mapping Between Themes and Attacks table Figure 4, this does not imply that there could be no relevant attacks related to L2-L3 integration. Very true -- thank you! Section 8.1.6 It may be that such attacks are limited to Internal on-path attackers, but other possibilities should be considered. Why is this listed as "may be"? What factors influence whether it can or cannot be the case? Section 8.1.8 However the handling of IT traffic by the DetNet may not (by design) be as resilient to DOS attack, and thus designers must be otherwise prepared to mitigate DOS attacks on IT traffic in a DetNet. I don't think I understand what this is trying to say. Both for what behavior is "by design" and what designers are expected to do. Section 8.1.10 is made available on the network for best-effort traffic. However, note that security considerations for best-effort traffic on a DetNet network is out of scope of the present document, provided that such an attack does not affect performance for DetNet OT traffic. nit: there's no antecedent for "such an attack" that I can see. Section 8.1.13 The usage of 'secure" and "security layer" in this section are pretty vague as to what properties are implied. Can we be more precise? Section 8.1.15 An attack that takes advantage of flaws (or even normal operation) in the device drivers for the various links (through internal knowledge of how the individual driver or firmware operates) could take proportionately greater advantage of this topology. I don't really understand what is meant by "proportionately greater advantage of this topology"? What is being compared to? Section 8.2 Is a delay attack relevant for deterministic flows? How is a reconnissance attack relevant for low latency? Section 9.2 The operation of DetNet over an MPLS network is modeled on the operation of multi-segment pseudowires (MS-PW). Thus for guidance on securing the DetNet elements of DetNet over MPLS the reader is referred to the MS-PW security mechanisms as defined in [RFC8077], [RFC3931], [RFC3985], [RFC6073], and [RFC6478]. I'm not sure I saw which security mechanisms are supposed to be provided by RFC 3985 and/or RFC 6478 (though I only very quickly skimmed through them). Further consideration of protection against dynamic attacks is work in progress. New work on MPLS security may also be applicable, for example [I-D.ietf-mpls-opportunistic-encrypt]. I got excited by the draft-ietf-mpls-opportunistic-encrypt reference, but following the link suggests that the draft has been expired for three years. Is it still appropriate to refer to it as "new work" or "work in progress"? Section 12 Traffic analysis and similar side channels can still cause there to be privacy considerations even when traffic is encrypted.
- [Detnet] Benjamin Kaduk's Discuss on draft-ietf-d… Benjamin Kaduk via Datatracker
- Re: [Detnet] Benjamin Kaduk's Discuss on draft-ie… Ethan Grossman
- Re: [Detnet] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [Detnet] Benjamin Kaduk's Discuss on draft-ie… Ethan Grossman