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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 07 Jan 2021 07:02:53 -0800

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.

---

From: "Ethan Grossman" <[email-masked]>
Date: Thu, 28 Jan 2021 15:07:59 -0800

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 <[email-masked]> 
Sent: Thursday, January 7, 2021 7:03 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Lou Berger <[email-masked]>; [email-masked]
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

--> 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

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”. 

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. 

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

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

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

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. 

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

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". 

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

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

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

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.

EAG and Henrik: Updated 7.2 to address all of these comments.

EAG and Henrik: Updated 7.2 to address all of these comments.

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.

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
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
(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
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. 

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
[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

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

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
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: 

Tal: Fixed these table entries. 
 
Section 9.2
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=========================