Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Ethan (and Tal and Henrik),

My apologize for taking a month to get back to you -- it has been pretty
hectic around here.

The good news is that I don't have any further responses inline -- you did
well at handling my comments, and thank you!

I will go update my ballot position now (I have a few minor notes from
going through the diff and skimming the -15).

Thanks again for all your work on this; it has really come a long way.

-Ben

On Thu, Jan 28, 2021 at 03:07:59PM -0800, Ethan Grossman wrote:
> Hello Benjamin, 
> Thank you for your considered review comments. Our dispositions of them are below, inline, prefixed with the individual author's name who addressed them (EAG (me), Tal, or Henrik). If you have any further thoughts on our dispositions or the draft in general, please don't hesitate to let us know. 
> Sincerely,
> Ethan (as Editor, DetNet Security Considerations draft)
> 
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]> 
> Sent: Thursday, January 7, 2021 7:03 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Lou Berger <[e-mail]>; [e-mail]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
> 
> ----------------------------------------------------------------------
> 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.
> 
> --> EAG added text: 
> "Starting with a "well-managed network" as noted above enables us to exclude some of the
>  more powerful adversary capabilities from the Internet Threat Model of BCP 72 (<xref
>  target="RFC3552"/>), such as the ability to arbitrarily drop or delay any or all traffic.
>  Given this reduced attacker capability, we can present security considerations based on
>  attacker capabilities that are more directly relevant to a DetNet."
>  
> ----------------------------------------------------------------------
> 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.
> 
> EAG: We did spend some time on those sections as a result of Yaron's comments; these will be incorporated into the next draft version (14). 
> 
> 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.
> 
> EAG: Thank you for this contribution, much appreciated. 
> 
> 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.
> 
> --> EAG (added text as noted above). 
> 
> Section 2
>    Resource Segmentation Used as a more general form for Network
> nit: missing colon
> 
> --> EAG OK done. 
> 
> 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.
> 
> --> Henrik: Added reference to RFC4302, IPSec, Authentication Header, Section 3. 
> 
> 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.
> 
> --> EAG refactored text: 
> However, DetNet also introduces timing and other considerations which are not present in DiffServ, so
>  the DiffServ security considerations are a subset of the DetNet security considerations.
>  
> 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?
> 
> EAG: Yes, added clarifying text: 
> "In this discussion, interpretation (and any possible intentional re-marking)of the DSCP
> values of packets destined for DetNet OT flows is expected to occur at the ingress to the
> DetNet domain; once inside the domain, maintaining the integrity of the DSCP values is
> subject to the same handling considerations as any other field in the packet."
>  
> 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.]
> 
> EAG: We decided to agree with you – I changed it to “taxonomy of threats”. 
> 
>    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.]
> 
> EAG: – Agree – I already dealt with in Roman's comments. 
>  
>    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.
> 
> --> EAG - we don't use the term "passive" so I claim there is no need to include this distinction. 
>  
> 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.
> 
> Tal: Updated section title and explained that it is a vulnerability that can exploit poor resource segmentation:
>    "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?
> 
> Tal: Added text to explain: Might happen due to resources that are partially shared between multiple DetNet flows, which may allow the attacker to exploit that resource by using traffic belonging to the one flow to try to affect the other flow. 
> 
> 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/
> 
> EAG: OK, also edited text: 
> Once the flow from the compromised path is favored by the eliminating bridge, the flow has effectively been hijacked by
> the attacker. It is now possible for the attacker to either replace en route packets with malicious packets, or to simply inject errors into the packets, causing the packets to be dropped at their destination.
>  
> 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.
> 
> EAG: Adapted text to explain there that we mean either case: 
> "An attacker can subvert a legitimate controller (or subvert another component such
> that it represents itself as a legitimate controller) with the result that the network
> nodes incorrectly believe it is authorized to instruct them."
>  
> 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.
> 
> EAG: OK, I added that. 
> 
>    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.
> 
> EAG: Yes, corrected. 
> 
> 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.)
> 
> --> EAG Added that note.
> 
> Section 5.3
> How can an off-path attacker perform a delay attack?
> 
> Tal: Removed "plus sign" from table for that. 
> 
> Section 6
> What is the distinction between "Health and Safety" and "People Well Being"?
> 
> EAG agree, removed "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)
> EAG: Agree, fixed. 
> 
> 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.
> 
> EAG: Agree, changed to Hi. 
> 
> 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/
> 
> EAG: OK fixed. 
> 
> 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.
> 
> Tal: Added text to clarify potential impact of this attack. 
> 
> Section 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.
> 
> Henrik: Added explanation: 
> "If an attacker can inject control messages without the central controller knowing, then one or more components in the network may get into a state that is not expected by the controller, and at that point if the controller initiates a command, the effect of that command may not be as expected, since the target of the command may have started from a different initial state."
> EAG: Also added new bullet: Can force component into failure state if told to do conflicting actions. 
> 
> Section 6.4.x
> I think the referenced coverage is perhaps too brief to be useful.
> 
> Tal: Added additional details. 
> 
> 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.
> 
> Tal: Rephrased, added text with more detailed description. 
> 
> 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.
> 
> EAG and Henrik: Updated 7.2 to address all of these comments.
> 
>                         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?
> 
> EAG and Henrik: Updated 7.2 to address all of these comments.
> 
>       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.
> 
> EAG and Henrik: Updated 7.2 to address all of these comments.
> 
>       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.  [...]
> 
> EAG and Henrik: Updated 7.2 to address all of these comments.
> 
> 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.
> 
> EAG and Henrik: Updated 7.2 to address all of these comments. 
> 
> 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.
> 
> Henrik: Added text to include this. 
> 
> 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.
> 
> --> EAG agree, fixed. 
> 
> 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.)
> 
> EAG: Nice addition, added that info. 
> 
>    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.]
> 
> EAG: Very useful info, incorporated it. 
> 
> 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.
> 
> EAG: OK, added that reference. 
> 
>       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.)
> 
> EAG: Already fixed as part of Roman review. Leave Fig 3 since definition of “mitigation” does not imply a complete fix for the attack. 
> 
> 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.
> 
> Tal: Added encryption as potential mitigation in the table. 
> 
> 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.
> 
> Tal: updated table entry text to be same as body text: "Control and Signaling Message Protection". 
> 
> 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.
> 
> EAG: At time of writing, we defer deterministic wireless to the Reliable and Available Wireless (RAW) IETF Working Group, so we don’t address such things here. We already make the statement in our text about "for other mediums, other mitigations would have to be implemented to provide analogous protection" - we feel this is sufficient. 
> 
> 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.]
> 
> EAG: Such specific protocols are not unique to DetNet and thus we don't delve further into this topic here (such as providing such references). 
> 
> 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!
> 
> EAG:    ;- ) 
> 
> 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?
> 
> EAG: OK, eliminated that sentence. 
> 
> 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.
> 
> EAG: Refactored text: 
> "The handling of IT traffic (i.e. traffic which by definition is not guaranteed any
> given deterministic service properties) by the DetNet will by definition not be given
> the DetNet-specific protections provided to DetNet (resource-reserved) flows. The
> implication is that the IT traffic on the DetNet network will necessarily have its own
> specific set of product (component or system) requirements for protection against
> attacks such as DOS; presumably they will be less stringent than those for OT flows, but
> nonetheless component and system designers must employ whatever mitigations will meet
> the specified security requirements for IT traffic for the given component or DetNet."
>  
> 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.
> 
> EAG looks OK to me, but I refactored as: 
> "However, note that security considerations for best-effort traffic
> on a DetNet network is out of scope of the present document, provided that any such
> attacks on best-effort traffic do not affect performance for DetNet OT traffic."
>  
> 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?
> 
> EAG refactored as: 
> "Deployment of such a component on a DetNet
> network that is intended to be highly secure may present an attack surface; thus the
> DetNet network operator may need to take specific actions to protect such components,
> for example by implementing a secure interface (such as a firewall) to isolate the component
> from the threats that may be present in the greater network."
>  
> 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?
> 
> EAG: clarified: 
> "It is also possible that a large scale DetNet topology containing various kinds of
>  links may not be in as common use as other more homogeneous topologies. This situation
>  may present more opportunity for attackers to exploit software and/or protocol flaws in
>  or between these components, because these components or configurations may not have
>  been sufficiently tested for interoperability (in the way they would be as a result of
>  broad usage). This may be of particular concern to early adopters of new DetNet
>  components or technologies."
>  
> Section 8.2
> In the table Fig 5: 
> Is a delay attack relevant for deterministic flows?
> How is a reconnissance attack relevant for low latency?
> 
> Tal: Fixed these table entries. 
>  
> 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).
> 
> Tal: Reviewed the RFCs and rephrased the text to refer the reader to the Security Considerations sections of these RFCs. 
> 
>    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"?
> 
> EAG: Rephrased: 
> "Some investigations into protection of MPLS systems against dynamic attacks exist, such
> as <xref target="I-D.ietf-mpls-opportunistic-encrypt"/>; perhaps deployment of DetNets
> will encourage additional such investigations."
>  
> Section 12
> Traffic analysis and similar side channels can still cause there to be privacy considerations even when traffic is encrypted.
> 
> EAG: added: 
> However, note that reconnaissance threats such as traffic analysis and monitoring of
> electrical side channels can still cause there to be privacy considerations even when
> traffic is encrypted.
> =================== END=========================
>