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

Roman Danyliw <rdd@cert.org> Tue, 12 January 2021 21:27 UTC

Return-Path: <rdd@cert.org>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E53A126A; Tue, 12 Jan 2021 13:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_ABOUTYOU=0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sc6B6jDlT6u; Tue, 12 Jan 2021 13:27:36 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4C13A1263; Tue, 12 Jan 2021 13:27:35 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10CLRWZK031621; Tue, 12 Jan 2021 16:27:33 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 10CLRWZK031621
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1610486853; bh=L9W9W5koFrhKiNwoCrVdT6cehpI+OSg6JJRiKlNqtwA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=BgqV/JgMHNBEQFa/he7mRCkpSGOsYtcdDlwxr7XPqs4GqJQYLEJz+R2E/WV2TSBzV u8suK+1UGSZlW09ja+5hmD+Nu6ARGgKkYQth9K2ler9BN6P6pgjMFBHVkCZxH/KsmB BvXN08nPKC2YqqZqBXNahV7N2vFjQEz4ktdm/1kw=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10CLRSBv008029; Tue, 12 Jan 2021 16:27:28 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 12 Jan 2021 16:27:28 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 12 Jan 2021 16:27:28 -0500
From: Roman Danyliw <rdd@cert.org>
To: "ethan@ieee.org" <ethan@ieee.org>
CC: "draft-ietf-detnet-security@ietf.org" <draft-ietf-detnet-security@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, 'Lou Berger' <lberger@labn.net>, 'The IESG' <iesg@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
Thread-Index: AQHW5HwyvJeYULDDQ0iWFHeJqM+7EKobmN8AgAjtZrA=
Date: Tue, 12 Jan 2021 21:27:27 +0000
Message-ID: <d9acbabf08d743d789fe0f1d3b509492@cert.org>
References: <160997248698.17463.4911050369396877811@ietfa.amsl.com> <0a8601d6e487$0432e310$0c98a930$@ieee.org>
In-Reply-To: <0a8601d6e487$0432e310$0c98a930$@ieee.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.203.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/2vz1FoKO0oIp-dBK3NlDkQZVJp8>
Subject: Re: [Detnet] Roman Danyliw's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2021 21:27:39 -0000

Hi Ethan!

Inline ...

> -----Original Message-----
> From: Ethan Grossman <ethan@ieee.org>
> Sent: Wednesday, January 6, 2021 6:53 PM
> To: Roman Danyliw <rdd@cert.org>
> Cc: draft-ietf-detnet-security@ietf.org; detnet-chairs@ietf.org;
> detnet@ietf.org; 'Lou Berger' <lberger@labn.net>; 'The IESG' <iesg@ietf.org>
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-detnet-security-13: (with
> DISCUSS and COMMENT)
> 
> 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?

Sorry for the confusion.  The datatracker pointed to Yaron's review's in the mailarchive.

LC: https://mailarchive.ietf.org/arch/msg/secdir/FfpnlExpMQmh3yDX_Lfy_wQvXZQ/

Telechat: https://mailarchive.ietf.org/arch/msg/secdir/xnBhl1GitXY3OKZnsmjAcB-jxoI/

However, it didn't show any response to these post.  I don't subscribe to the detnet list so I didn't realize discussions had occurred and you had closed the loop with him.

Thanks for checking.

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

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


Regards,
Roman

 
> -----Original Message-----
> From: Roman Danyliw via Datatracker <noreply@ietf.org>
> Sent: Wednesday, January 6, 2021 2:35 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-detnet-security@ietf.org; detnet-chairs@ietf.org;
> detnet@ietf.org; Lou Berger <lberger@labn.net>; lberger@labn.net
> 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/
> 
> 
>