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

[Roman Danyliw <[e-mail]>]

Hi Ethan!

Thanks for detailed response explaining the edits in -14 and the motivation where a change doesn’t make sense.  In particular, I think the new Section 3.1.* language about trade-offs is nice addition. I've cleared by ballot.

Per the new text in Section 7.4, the clarifying text is appreciated.  IMO, it is still a bit underspecified and specified at the same time given that the approaches to insert dummy traffic don't have well tested operational practices (let alone in this context).  However, in the spirit of this being an informational document and the desired tone of the overall text to not be prescriptive, let's leave it as.

Again, thanks for the revisions!
Roman


> -----Original Message-----
> From: Ethan Grossman <[e-mail]>
> Sent: Thursday, January 28, 2021 5:39 PM
> To: Roman Danyliw <[e-mail]>; 'The IESG' <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; 'Lou Berger' <[e-mail]>
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-detnet-security-13: (with
> DISCUSS and COMMENT)
> 
> 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.
> -----------------------------------------------------------------------
>