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

[Ethan Grossman <[e-mail]>]

Hi Roman,
Thanks again for your insightful 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: Roman Danyliw via Datatracker <[e-mail]> 
Sent: Wednesday, January 6, 2021 2:35 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Lou Berger <[e-mail]>; [e-mail]
Subject: Roman Danyliw's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
** Section 5.1 and Figure 1.  Thanks for separating the different kinds of attackers.  As it relates to “internal vs external” where are the details of what DetNet traffic is encrypted or authenticated to create a distinction between internal and external; and to rule out certain attack to external actors per Figure 1?

EAG: We have the definition as: 
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.

EAG Added text: 
        <t>Regarding the boundary between internal vs. external attackers as defined above, please
          note that in this document we do not make concrete recommendations regarding which
          specific segments of the network are to be protected in any specific way, for example via
          encryption or authentication. As a result, the boundary as defined above is not
          unequivocally specified here. Given that constraint, the reader can view an internal
          attacker as one who can operate within the perimeter defined by the DetNet Edge Nodes (as
          defined in the DetNet Architecture <xref target="RFC8655"/>), allowing that the specifics
          of what is encrypted or authenticated within this perimeter will vary depending on the
          implementation. </t>

** I may not fully understand the architecture, but these threats and mitigations didn’t seem to align:
--  Section 7.1.  Per path redundancy being able to mitigate Section 5.2.7 (time sync), which is just reference to RFC7384, how does a RFC8655 style PREOF mitigate a grandmaster time source attack per Section 3.2.10 of RFC7384?  Is the intent here that all RFC7384 attacks are mitigated?

Tal: Refactored this section to clarify.  

-- Section 7.5.  “Reconnaissance attacks (Section 5.2.6) can be mitigated by using encryption” seems like too strong of a statement.  Some traffic analysis should be still be possible.

EAG added text: 
"However, despite the use of encryption, a reconnaissance attack can provide the
attacker with insight into the network, even without visibility into the packet. For
example, an attacker can observe which nodes are communicating with which other nodes,
including when, how often, and with how much data. In addition, the timing of packets
may be correlated in time with external events such as action of an external device.
Such information may be used by the attacker, for example in mapping out specific
targets for a different type of attack at a different time."

-- Section 7.6.  Per “These mechanisms can be used to mitigate various attacks on the controller plane as described in Section 5.2.5 …”, can it be clarified how these security properties will protect against controller compromise (Section 5.2.5.2).

EAG: The text in 7.6 says "These mechanisms can be used to mitigate various attacks on the controller plane, as described in Section 5.2.5, Section 5.2.7 and Section 5.2.5.1". We intended to reference only sections 5.2.7. and 5.2.5.1, not everything under 5.2.5. so I just deleted the reference to Section 5.2.5. 

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Yaron Sheffer for the SECDIR review.  Please respond to it.
EAG: Done (almost all were completed in draft 13, remainder will be in draft 14). 

** Section 3.  I had difficulty extracting what security considerations are being conveyed and the assumptions being made in this section.  Specifically, what was assumed to be a prerequisite for DetNet (and out of scope), what is a required security property engineered into the DetNet protocols, and what might be a necessary behavior for operators of DetNets.  Put in another way:
-- Is this section documenting the properties of a DetNet that system security designer can assume if they deploy some combination of the protocols of the DetNet WG?
-- Is this section documenting the security properties of the protocols coming out of the drafts in the WG?
-- Is this section documenting requirements for implementers (component designers)?
-- Is it documenting the “assumed scrupulously well-designed and well-managed engineered network following industry best practices for security at both the data plane and controller plane; this is the assumed starting point for the considerations discussed herein” (per Section 1)?

EAG: The text in the top level Sec 3 "topic sentence" says: 
"As noted above, DetNet provides resource allocation, explicit routes and redundant path support.  Each of these has associated security implications, which are discussed in this section, in the context of component design."

EAG: I added a sentence at the start of the section: 
<t>This section provides guidance for implementers of components to be used in a DetNet. </t>

EAG: Also, Sec 3.1 was extensively rewritten as a result of Magnus' comments on it, which I believe further clarifies the section. 

Another example of my confusion is in Section 7.2.  Given the abstract text, it is unclear who is supposed to be using this guidance

EAG: This is a good point. The first text in Sec 7 says "This section describes a set of measures that can be taken to mitigate the attacks described in Section 5, Security Threats.  These mitigations should be viewed as a toolset that includes several different and diverse tools.  Each application or system will typically use a subset of these tools, based on a system-specific threat analysis."

EAG: I refactored that text and added: 
“The decision on where in the network to apply integrity protection is part of the DetNet system design, and the implementation of the protection method itself is a part of a DetNet component design.”

** Section 3.1.  I’m having difficulty reconciling:
(a) “in other words there is no physical possibility within a DetNet component that a resource allocated to a given flow can be compromised by any traffic in the network”
(b) “it is the responsibility of component designers to ensure that this condition is met … for example through the use of traffic shaping and policing”
To me,  (a) suggests formal verification or something that must burned in silicon since there is “no physical possibility”.  However, the example in (b) which seems like a means to implement that goal reads a lot weaker like standard operational practices even on IT networks.

EAG: Valid point; I claim this was already covered in my rewrite of Sec 3.1 (forthcoming in draft 14). 

** Section 3.2.  If the “[T]he system designer relies on the premise that the packets will be delivered with the specified latency boundaries” and this is an assumption, what security consideration is there?  The property seems to be either an out-of-scope article of faith or a requirement.

EAG: The implication is that it is up to the component designer to “make it so”. I refactored the text as:  
        <t>So from a DetNet security standpoint, the DetNet system designer can expect that any
          component designed for use in a DetNet will deliver the packets within the agreed-upon
          service parameters. For the component designer, this means that in order for a component
          to achieve that expectation, any component that is involved in controlling or implementing
          any change of the initially TE-configured flow routes must prevent re-routing of OT flows
          (whether malicious or accidental) which might adversely affect delivering the traffic
          within the specified service parameters.</t>

** Section 3.4.  This isn’t framed in terms of system or component designers like the other sub-sections of Section 3.  Can the actors be clarified?

EAG: OK I rewrote the first 2 paragraphs as: 
A task of the DetNet system designer is to create a network such that for any incoming
packet which arrives with any timing or bandwidth violation, an appropriate action can be
taken in order to prevent damage to the system. The reporting step may be accomplished
through dynamic performance analysis (see <xref target="DpaMitigation"/>) or by any other
means as implemented in one or more components. The action to be taken for any given
circumstance within any given application will depend on the use case. The action may
involve intervention from the controller plane, or it may be taken "immediately" by an
individual component, for example if very fast response is required. 

The definitions and selections of the actions that can be taken are properties of the
components. The component designer implements these options according to their expected
use cases, which may vary widely from component to component. Clearly selecting an
inappropriate response to a given condition may cause more problems than it is intending
to mitigate; for example, a naive approach might be to have the component shut down the
link if a packet arrives outside of its prescribed time window; however such a simplistic
action may serve the attacker better than it serves the network. Similarly, simple logging
of such issues may not be adequate, since a delay in response could result in material
damage, for example to mechanical devices controlled by the network. Thus a breadth of
possible and effective security-related actions and their configuration is a positive
attribute for a DetNet component.

** Section 5.1.  The more detailed text in Section 6 seems to note that traffic might get dropped by an attacker.  Therefore, it is likely worth:
OLD
On-path attackers are located in a position that allows interception and modification of in-flight protocol packets
NEW
On-path attackers are located in a position that allows interception, modification, or dropping of in-flight protocol packets

EAG: OK, will use this. 

** Section 5.2.5.2.  Is a compromised DetNet node in the control plane in scope?

EAG: I refactored the text as: 
The presence of a compromised node or controller in a DetNet is not a threat that
arises as a result of determinism or time sensitivity; the same techniques used to
prevent or mitigate against compromised nodes in any network are equally applicable in
the DetNet case. The act of compromising a controller may not even be within the
abilities of our defined attacker types - in other words it may not be achievable via
packet traffic at all, whether internal or external, on-path or off-path. It might be
accomplished for example by a human with physical access to the component, who could
upload bogus firmware to it via a USB stick. All of this underscores the requirement
for careful overall system security design in a DetNet, given that the effects of even
one bad actor on the network can be potentially catastrophic.

** Figure 1.  Is there a reason that the “Compromised Controller” isn’t listed?

EAG:  Yes that is intentional, because we are focusing on security concerns unique to DetNet, and our current feeling is that protecting against a compromised controller is more about “careful system security design” (as noted above) which is not unique to DetNet. 

** Section 6.  IHMO, the two part table doesn’t add much to the discussion and should be removed. It introduces a new taxonomy of impact without much explanation.  There is no tangible guidance to the “component designer” or “system designer” on how to parse the “low, medium, high”.  Ultimately, as the text says “[i]n practice any such ratings will vary from case to case; the ratings shown here are given as examples”.  Even as an example, there is no guidance on how the intended audience would use this information. 

EAG: We agree to keep part one of the table, with added explanation of its purpose; the justification is that it is user friendly to have a table, allows structure, e.g. to get an overview. What to keep in mind, what to prioritize. 
EAG: I added a paragraph of intro to the section: 
"When designing security for a DetNet, as with any network, it may be prohibitively
expensive or technically infeasible to thoroughly protect against every possible threat.
Thus the security designer must be informed (for example by an application domain expert
such as a product manager) regarding the relative significance of the various threats and
their impact if a successful attack is carried out. In this section we present an example of
a possible template for such a communication, culminating in a table ([Figure 2]) 
which lists a set of threats under consideration, and some values characterizing their relative impact in the 
context of a given industry. The specific threats, industries, and impact values in the table are provided only as an example
of this kind of assessment and its communication; they are not intended to be taken literally."

** Section 6.  Per “This section describes and rates the impact …”, what is the intuition on these low, medium, hi? What and who does something with these tables?  What does Lo, Med, Hi mean?

EAG: These are qualitative values that are intended to be used as a vague “template” by the reader; they do not have any meaningful significance. The new text (above) makes this clearer. 

** Section 6. Additionally, there is little mention of many of these impacts in the details of Section 6.*

EAG: Again the table is given as an example of how a “product designer” (or equivalent) might express to a “system security designer” (or equivalent) their priorities for the system. So the details of these items, most obviously the ones that are not DetNet specific, are immaterial. This was made clearer in the text as part of the above refactoring. 

** Section 6.  Per “In computer security,  the impact (or consequence) of an incident can be measured in loss of confidentiality, integrity or availability of information.  In the case of time sensitive networks, the impact of a network exploit can also include failure or malfunction of mechanical and/or other OT systems”, this reads like a very narrow view of IT network comprise suggestion that only OT system has “real-world” consequences.

EAG: I reworded this as follows; (if you have further suggestions, please let me know): 
"In computer security, the impact (or consequence) of an incident can be measured in loss
of confidentiality, integrity or availability of information. In the case of time sensitive
or OT networks (though not to the exclusion of IT or non-time-sensitive networks) the impact of an
exploit can also include failure or malfunction of mechanical and/or other physical systems."

** Section 6.7.  What is the basis for concluding that reconnaissance will lead to ransom attack as opposed to any of the other attacks mentioned in this section?

EAG: Agree. Remove phrase about ransom. 

** Section 7.1.  Per “Path replication and elimination [RFC8655] provides resiliency to dropped or delayed packets”, I found no reference to the “path replication” in RFC8655.  What Section 3.2.2.2 of RFC8655 does seem to talk about is packet replication.  Should the same words be used for consistency?

EAG: Agree, s/path/packet/

** Section 7.1.  Per path redundancy being able to mitigate Section 5.2.2 (flow modification or spoofing) where is the approach to reconciling the two packets, one modified and another not, per the notional PREOF functionality?

Tal: Refactored text to address use of more general path redundancy than PREOF as in earlier mentioned section. 

** Section 7.2.  Given the abstract nature of this text, should it be read as a requirement?  Who is this requirement for, adding a MAC to protocol is a design issue but rely only IPSec can be handled in operation

EAG: Following our “toolbox” model, integrity protection, by whatever means, might  (or might not) be used in one or more places in any given DetNet, depending on its importance in that use case. Perhaps, as of this writing/review, IPSec might be the only viable option, but in the future who can say – we don’t attempt to prescribe to that degree. 

** Section 7.4.  The use of [IEEE802.1Qch-2017] is remarkably specific reference without any guidance on implementation, either here the active DetNet drafts (I checked).  Please consider if this is realistic guidance without further citation on how this could be implemented.

Henrik: Refactored this section to address this: 

            <t>With some queueing methods such as <xref target="IEEE802.1Qch-2017"/> it is possible
              to introduce dummy traffic in order to regularize the timing of packet transmission.
              This will subsequently reduce the value of passive monitoring from internal threats
              (see <xref target="ThreatSection"/>) as it will be much more difficult to associate
              discrete events with particular network packets. </t>
        <t>Related attacks 
            <t>Removing distinctive temporal properties of individual packets or flows can be used
              to mitigate against reconnaissance attacks <xref target="ReconnaissanceThreat"/>. For
              example, dummy traffic can be used to synthetically maintain constant traffic rate
              even when no user data is transmitted, thus making it difficult to collect information
              about the times at which users are active, and the times at which DetNet flows are
              added or removed.</t>

        <t>Traffic Insertion Challenges 
            <t>Once an attacker is able to monitor the frames traversing a network to such a degree
              that they can differentiate between best-effort traffic and traffic belonging to a
              specific DetNet flow, it becomes difficult to not reveal to the attacker whether a
              given frame is valid traffic or an inserted frame. Thus, having the DetNet components
              generate and remove the dummy traffic may or may not be a viable option, unless
              certain challenges are solved; for example, but not limited to:</t>

            <t>Inserted traffic must be indistinguishable from valid stream traffic from the
              viewpoint of the attacker.</t>

            <t>DetNet components must be able to safely identify and remove all inserted traffic
              (and only inserted traffic).</t>

            <t>The controller plane must manage where to insert and remove dummy traffic, but this
              information must not be revealed to an attacker.</t>

            <t>An alternative design is to have the insertion and removal of dummy traffic be
              performed at the application layer, rather than by the DetNet itself. Further
              discussions and reading about how sRTP handles this can be found in <xref
                target="RFC6562"/></t>

** Section 7.5.1.  Will the intended audience of this section roll their own encryption primitives or invent their own protocol?  If not, it might be more useful to discuss concrete protocols that will secure the communication with the properties desired.

EAG: We have heard a number of review comments along this line. We need to add a statement in the Introduction stating that we are not trying to be prescriptive here – we are stating the desired end result, with the understanding that most DetNet use cases will necessarily differ from each other, and there is no “one size fits all”.

EAG: Added to Introduction: 
"This document is based on the premise that there will be a very broad range of DetNet
applications and use cases, ranging in size scope from individual industrial machines to
networks that span an entire country (<xref target="RFC8578"/>). Thus no single set of
prescriptions (such as exactly which mitigation should be applied to which segment of a
DetNet) can be applicable to all of them, and indeed any single one that we might prescribe
would inevitably prove impractical for some use case, perhaps one that does not even exist
at the time of this writing. Thus we are not prescriptive here - we are stating the desired
end result, with the understanding that most DetNet use cases will necessarily differ from
each other, and there is no "one size fits all"."

** Section 7.7.  Per “Performance analytics can be used to mitigate various attacks, including the ones described in Section 5.2.1   ...”, 
This language seems imprecise.  The DPA can likely detect the delay attack, but this text doesn’t describe it having the capability to mitigate it (i.e., the difference between a IDS and IPS system)

EAG: Agree. (“Performance analytics can be used to detect various attacks, including …” 

** Section 8.1.  What is the basis for the list in 8.1.*?  What is a “Use Case Common Theme”?  Why for example wouldn’t virtualization (of say the controller) be “a common theme”?

EAG: As stated immediately before Sec 8.1, in Sec 8, “since there is a potentially unbounded list of use cases, we categorize the attacks with respect to the common themes of the use cases as identified in the Use Case Common Themes section of the DetNet Use Cases [RFC8578].”
To me that’s pretty clear, I would claim it does not need to be changed. 

** Section 8.1.3.  There might be rekeying issues to also manage when swapping of components.

EAG: Good point. Added: "To mitigate this situation, deployments should provide a method for dynamic and secure
            registration of new components, and (possibly manual) deregistration and re-keying of
            retired components."

** Section 8.1.4.  Per “DetNet specifies new YANG models which may present new attack surfaces ”, what and where are these new YANG models?

EAG: Agree, added reference to [draft-ietf-detnet-yang]. 

** Section 8.1.6.  What is a “Flow Modification attack” (only time this term is used in the document) and how is that related to the threat analysis in Section 5.2?

EAG: Hmm, the term Flow Modification is used throughout the document, including Sec 5.2.2.  DetNet Flow Modification or Spoofing. The only difference here is the grammatical circumstance in which the word “attack” is used to characterize each of “a "long" Delay or Replication/Elimination or Flow Modification” (i.e. each is an “attack”). 
I refactored it slightly to clarify:  
 “A data plane attack may force packets to be dropped, for example as a result of a Delay
            attack, Replication/Elimination attack, or Flow Modification attack.”

** Section 8.1.23.  “A DetNet network must be made sufficiently secure against problematic component or traffic behavior, whether malicious or incidental, and whether affecting a single component or multiple components.”  IMO, this paragraph is so generic and the definition of a component per Section 2 is so expansive that this lacks meaning (beyond saying “security is needed”).  It doesn’t seem actionable to implementers (component or system designers).

EAG: The intent of the text here is “who is watching the watchman” – in other words “you must secure the security system itself”. I removed the first sentence (that you reference) since as you say it adds no value, and dilutes the message of the section (which was there, but since that sentence threw you off, I assume it would throw others off also). 

** Typos
Section 3.3. Typo. s/reliablity/reliability/
Section 3.3.  Typo. s/arrangment/arrangement/
Section 3.3. Typo. s/reliabiilty /reliability/
Section 3.3.  Typo. s/Similary/Similarly/
Section 5.2.4.2.  Typo. s/elminating/eliminating/
Section 5.2.4.2.  Typo. s/posible/possible/
Section 5.2.4.2.  Typo. s/elminating/eliminating/
Section 5.2.4.2.  Typo. s/posible/possible/
Table 2.  Typo. s/Effect 1/Affect 1/g
Section 6.2.2.2.  Typo. s/potentionally/potentially/
Section 8.1.2.  Typo. s/ Reconaissance/ Reconnaissance/
EAG: Accept all typos. 
-----------------------------------------------------------------------