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/ > > >
- [Detnet] Roman Danyliw's Discuss on draft-ietf-de… Roman Danyliw via Datatracker
- Re: [Detnet] Roman Danyliw's Discuss on draft-iet… Ethan Grossman
- Re: [Detnet] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [Detnet] Roman Danyliw's Discuss on draft-iet… Ethan Grossman
- Re: [Detnet] Roman Danyliw's Discuss on draft-iet… Roman Danyliw