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

[Roman Danyliw via Datatracker <[e-mail]>]

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/