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

[Ethan Grossman <[e-mail]>]

Hello Roman,
Thank you for your review. I'm a bit curious about your comment "Thank you to Yaron Sheffer for the SECDIR review.  Please respond to it." We have already validated with Yaron via the DetNet list that all of the comments from his review were addressed in draft 13, with one exception ("please add additional specifics for each mitigation proposed, and consider each from the viewpoint of each data plane e.g. IP/MPLS/Ethernet") which we are working on this week. Am I missing something here? 

Anyway we expect to review and address your review comments starting next week. 

Thanks again for your help in improving our draft,
Sincerely,
Ethan (as DetNet Security draft editor)

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

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

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

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

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

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Yaron Sheffer for the SECDIR review.  Please respond to it.

** 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)?

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

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

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

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

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

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

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

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

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

** 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. 
Additionally, there is little mention of many of these impacts in the details of Section 6.*

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

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

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

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

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

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

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

** 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”?

** Section 8.1.3.  There might be rekeying issues to also manage when swapping of 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?

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

** 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).

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