Re: [Detnet] DetNet Security - Items for Work Session 28Aug20

"Grossman, Ethan A." <eagros@dolby.com> Fri, 28 August 2020 17:12 UTC

Return-Path: <eagros@dolby.com>
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 92B963A0E6B for <detnet@ietfa.amsl.com>; Fri, 28 Aug 2020 10:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com
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 UyLDuxooD8fh for <detnet@ietfa.amsl.com>; Fri, 28 Aug 2020 10:12:25 -0700 (PDT)
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2137.outbound.protection.outlook.com [40.107.100.137]) (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 026373A0E65 for <detnet@ietf.org>; Fri, 28 Aug 2020 10:12:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BxAaoLnQiIiVDBhKv3uQp+DUEJrZgx9k3yhKBOQeiyySHFUPI3PZK1cZ6fKWrCxuoCn/h6eS652qMhub/gG+MFano/SdlWOqq+Nj0wQ4D9CYf+M1b+QxigNQPfaL6dpgYHmwfQqDjvS8NJcVefESOFQ6rq00QlRYIFJsbfCKkZdi1CjhLX0nA4bgB5EufMXjJJyWgCoxZFOU9Am7+uAks6yQHL83kW4JgCgEzCj2HssFBLI3S3d7+1owSsIjGEcqhxSZvtGqH+4XejZikGUWjmIWjN5kCHfnFmVWMMs/GlQW3us9dp8wHHdINc+5wNJvTXQq85NdOYn0j0p2nvwb5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WWrwB2DPleP/m3PnLAwdtx5O/FSG3iOz6IdRtw67Bxk=; b=VuAEUQVedQAdQ7rEh2P2slo231jQvjAxxAQ7aRNV97JXz8sAyZFWMZ9d/y1mvZMCZQuDYLKRHrO359dTZCN+oQJyF7Tx7egrNz/OzbL4w3irq5EV6PleyiKW4srvzrmFn5YLqjoKkCeL0b9y/RltdpQvORX3aVMPuT6Cfg0e+6T2gRAdKN0QrPy30EKpg5Ww4Q0fqZBFNtJl7zSMVpRIS54jxpd8GbXTYqWJxen4uEgXPjZKpvBXS2Ddedoigy4qRvm1OmNMH3EHjGh7l+Vq0uTiAtbBRR4EFkKyG22i1Xuyul8R2Tl6rK97nQT55FLOycmzVSqOHZpq5CuZ5AU58Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dolby.com; dmarc=pass action=none header.from=dolby.com; dkim=pass header.d=dolby.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WWrwB2DPleP/m3PnLAwdtx5O/FSG3iOz6IdRtw67Bxk=; b=GKEOo1ZwuJKoSvACFAHn43Y3o1695FNkP8XtNPaLEfQhN6w4IH1iuk157bQSILkflC3ir5ElISbG0LWRkEr8ctC5Prv0mzfX0owjiFuv04TPURxo320pnZvk3AH1yD8bsu3kM9GsilI93a3tBZlIwhPCF1o5SDYW/I0eSwY1Lg4=
Received: from BY5PR06MB6611.namprd06.prod.outlook.com (2603:10b6:a03:23d::20) by BYAPR06MB4325.namprd06.prod.outlook.com (2603:10b6:a03:14::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Fri, 28 Aug 2020 17:12:22 +0000
Received: from BY5PR06MB6611.namprd06.prod.outlook.com ([fe80::59d0:9610:aeb8:ca84]) by BY5PR06MB6611.namprd06.prod.outlook.com ([fe80::59d0:9610:aeb8:ca84%4]) with mapi id 15.20.3305.032; Fri, 28 Aug 2020 17:12:21 +0000
From: "Grossman, Ethan A." <eagros@dolby.com>
To: "Grossman, Ethan A." <eagros@dolby.com>, "detnet@ietf.org" <detnet@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, Lou Berger <lberger@labn.net>, Janos Farkas <Janos.Farkas@ericsson.com>, "Black, David" <David.Black@dell.com>
CC: Deborah Brungard <db3546@att.com>
Thread-Topic: DetNet Security - Items for Work Session 28Aug20
Thread-Index: AdZ8J9fgFrGmzAucSYu4Mgoe1v65IgBJOV0w
Date: Fri, 28 Aug 2020 17:12:21 +0000
Message-ID: <BY5PR06MB6611902B93963F486DD2FD27C4520@BY5PR06MB6611.namprd06.prod.outlook.com>
References: <BY5PR06MB6611F981FC02DD57197CC342C4550@BY5PR06MB6611.namprd06.prod.outlook.com>
In-Reply-To: <BY5PR06MB6611F981FC02DD57197CC342C4550@BY5PR06MB6611.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dolby.com; dkim=none (message not signed) header.d=none;dolby.com; dmarc=none action=none header.from=dolby.com;
x-originating-ip: [104.129.202.58]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 88c23131-a58f-4d7e-60b4-08d84b7586d3
x-ms-traffictypediagnostic: BYAPR06MB4325:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR06MB4325B994435585FC9082D3E1C4520@BYAPR06MB4325.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cK6pzBQsBO4px32vtK9c/w0IdtoV/XGSRQJa4qS7fwPDsVL8fSwqayIN0HUPWjQ6vMUXnd5nyKEBWzNL5Jr0PR5t9IVvDQnXE5Q664RCi4oUroVlAuvdmWOMNMAoK5ylf28BaKIk1MPXMKcE5A43JmKLYh5cM/jW8xbrhlEjUzCf1h7/uawCAmXNZZiuTO+j1WYVEafwnGvXEZw7o4EOrJ/MnQ/ujJyjDwkPVfW30znaiJJFcKF3PGHNqG+2/C4LTk6ReZoAOszTcjvTQ3xklAxrK52fWqCIvjl3BXm4xUVlBTRW8z7yIpDyMpB6TVeVPf+dFVZVWzRmm3sco9opoVMH1MSU0ydW5uurpkyOwuyQ/ZqMwu0k6SWYsUjA04ucpKayksJz8niGXcazmpg+Pg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6611.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(376002)(346002)(366004)(39850400004)(8936002)(83380400001)(6506007)(55016002)(66574015)(186003)(9686003)(86362001)(478600001)(26005)(53546011)(316002)(66476007)(30864003)(110136005)(33656002)(8676002)(4326008)(5660300002)(7696005)(2906002)(15650500001)(66556008)(66946007)(55236004)(66446008)(64756008)(52536014)(76116006)(966005)(71200400001)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 6BgI8YxuVjVc+kmZY1UpsldgU1fGPFnESUZP9uAR/BLqytOWoOWhVHOTPq/0+0sw/5DlEOlPbfN7tQL9hcVXbTCkLYo2lgh/BT6DJmwWP01Th1qOnYcMivFbBLDDbpJKSx909X63LElpysN2hoGQVmANhrzJZW5cnVJncElNOo9gX7s6QHTUvNEbh/Z+WON8dMYKxuuD2o+9Phc2/3lKhKWybfNz5iaUZM4saMH0voFE1BXVyHzzLxQOS1b32qeq21td0zO4ixm+yi/Oc/5ngviSY21B5yxx4zWGcp8taurTXtWkfno+09y1zkowAFVq8LxqcGTH86eRhCm3WDFBU2ZkxvBesnfKGUe1+o49RW2XXZp/P4t9VkFdLEiSiyUS4M4ZaV1owgMCtGrHDPqocgyjJso70vBISvROTfPfs3otHhlVophFfrakG/4qpcdLRQcmw8/4GjoUB3T46iwKuZjFSG/f3uFMlEImfhOSKQd9G+rku8RVXKwvof+9F0WxwBFJ6mzZkYoT2JzoMXS7nuBqtO+9VtvQQTZK5eBO8HqNmudTkrGXCqtt4+iAXP85JfJQKXWjtNVQGDcSXdq/aJ5x0MFnIFAxlE0BOX3GVLKCWUYj2DQziotDQ9XLyhCREf3iqAww89oa3KA5zSqFiw==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR06MB6611.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 88c23131-a58f-4d7e-60b4-08d84b7586d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 17:12:21.6479 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FpVJJ498OVhBLJqQlCBb833ycKbJ/pKr+xQUrLBq/8ZxlaTwJo80nA2oBdOxOygBhLx0/GDOBb21WjmK8ZKH0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4325
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Ef4I44KNjCluc9YMqle5WGk2WiE>
Subject: Re: [Detnet] DetNet Security - Items for Work Session 28Aug20
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: Fri, 28 Aug 2020 17:12:29 -0000

Notes from DetNet Security draft work session 28Aug20. 
Thank you Stewart, Lou and Janos for your help in this review session. Our proposed resolutions for the comments that we addressed are shown inline below (marked with "-->") for review by the WG. 
Our current plan is to continue through the last few remaining items next Friday morning (Ethan to request Webex from Lou for that time, or reschedule if necessary). 
After that, and factoring in any additional WG input, I will revise the draft accordingly. 

Ethan (as Editor, DetNet Security draft)

-----Original Message-----
From: detnet <detnet-bounces@ietf.org> On Behalf Of Grossman, Ethan A.
Sent: Wednesday, August 26, 2020 9:37 PM
To: detnet@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>; Lou Berger <lberger@labn.net>; Janos Farkas <Janos.Farkas@ericsson.com>; Black, David <David.Black@dell.com>
Subject: [Detnet] DetNet Security - Items for Work Session 28Aug20

Hi All (read: anyone interested in helping resolve review comments on the DetNet Security draft),

I have listed below the remaining 25 or so open comments from Adrian's review, plus another 6 left over from Ben Kaduk's earlier informal review. I figure if we could get through 10 of them in this session that would be solid progress, but I haven't pre-selected any; we can just go through and see how many we can do. 

I added an identifier prefix to each of Adrian's comments, like "M3", so we can at least refer to them. They all say "EAG HOLD" on them, a hold-over from my last triage of them. 

The "MITM" item generated some dialog on the list - I included that dialog below so as to have it in one place for our review - the sequence of those emails is earliest statement at the top. 
 
Thanks for your help with this, 
Hope to see you Friday,
Ethan (as DetNet Security Draft Editor) 

+++++++++++++++++++++ Start ++++++++++++++++++++++++++++++++

I1) It's a security document, so I searched for the word "privacy" and found it in just two places.  Is it possible that these are the only two examples of privacy-impacting issues with DetNet?  If so, I suggest adding a section ("Privacy Considerations") where you point to these two cases and explain that there are no other privacy concerns. But, more likely, there is more you can say on the tpoic and should call out with additional text. You may find RFC 6973 to be useful.

FWIW, only 5.2.7.1/6.7 seemed immediately relevant to privacy.
--> Add new Section for Privacy
Privacy is maintained by the base technologies specific to the DetNet and user traffic. For example TSN can use MACsec, IP can use IPsec, Applications can use IP transport protocol-provided methods e.g. TLS and DTLS.  MPLS typically uses L2/L3 VPNs combined with the previously mentioned privacy methods. 

================Start MITM================================
--> Prefer on-path and off-path - on-path should be substitute for MITM. 

I2) It would be nice to avoid the term "man-in-the-middle" (and coresponding
"MITM") in favour of the term "on-path attacker". It is less problematic as a term, and no less accurate.

Although "man-in-the-middle" is well established, I think you could easily avoid it and if you feel necessary you could use "An on-path attacker (formerly known as a man-in-the-middle) ..."

Then Stewart wrote: 
I sort of understand why you want to change MITM, although given that the man you have in mind is evil I am not sure whether it is that objectionable in this context. However I am not sure on-path is the right term. MITM normally implies an entity that can modify traffic in flight, whereas an on path attacker may simply be an observer.

Maybe AITM (attacker ....) would be a better gender neutral term.

Then Eric Gray wrote: 

	Actually, in addition to the many things that are strange about this entire conversation, your observation about the "thing in the middle" (I mean, let's face it, the "entity" in the middle - EITM? - has been gender-neutral for a long time, given that any human participation in the role could be detected by an idiot) being necessarily _active_ is not quite correct.

	It seems to me to be quite reasonable that the middle position could as easily be used to passively collect information for use in other activities - including a few fairly well known attacks.

Then Stewart wrote: 

We are talking about the threats in DN. 

I think we should be focusing on the things that are special to DN which is a technology that adds certain properties to a general network. I assume the protection of the general network using the normal techniques is a given.

Passively looking at the contents is about privacy and technical surveillance to intervene more effectively.

Privacy obviously applies to a general network, and I take it as read that we protect against this. However this document is about DN, and I cannot see what the privacy concerns are about the DN specifics.

Then Eric Gray wrote: 
	I am not certain that your "active attacker" assumption is correct even in this limited case, but you were responding on the subject of "gender neutrality" and whether or not it is appropriate to use "MITM" (presumably in general).

	That topic is no longer in the realm of "DetNet specific."  So your response should probably not be written (or read) as if it were.

	In your own words, however, one reason for passive listening is "technical surveillance to intervene more effectively" - which would seem to apply to DetNet at least as much as to anything else.

	This is not necessarily a generic privacy concern, as a passive MITM could be waiting for some specific activity (or activities) to occur in what would clearly be a "special class" of communications (such as DetNet would be)

Then Adrian wrote: 

My review said, "It would be nice to avoid," not, "You must avoid."
The review is principally for the AD, and they will tell you whether you need to action this.
I made a constructive suggestion of an alternative phrase, but you are allowed to choose others.

The thing about the term "man-in-the-middle" is not that it is directly making a specific man appear evil, it is that it associates the word "man" with the concept "evil" and therefore subtly changes the long-term perception of "man". There is, in fact, nothing about this type of attack that is specific to a man, and not all attackers are men, nor are all men attackers.

This is a minor issue for me, and (to some extent) I wanted to experiment with draft-knodel-terminology to see what reaction it would get if the changes it suggests were made as a request rather than as an order.


Then Deborah wrote: 
Without getting into the debate on the term itself, I don't think MITM is concise enough. In RFC3552, MITM is just one of multiple active attack possibilities. Same for Injector, it also is an active attack. It's not simply MITM vs. injector. Stewart is correct - on-path can be an observer (passive). I think we need to define per RFC3552, not the Network Time Protocol threat model.  It would be better to align with the security terms and use on-path /off-path vs. internal/external. I think this is part of the confusion as the definition of internal in the document is mixing with the definition of MITM in RFC3552.

The checked items in Figure 1 are not MITM (they could be done by a MITM), they are basically message modification (RFC3552). So I'm actually not sure the value of this breakdown of MITM vs. Injector? These terms are only used in 5.1 and Figure 1, they are not used in the rest of the document. Suggest it would be more accurate to simply say "active" (document already has the term in 5.1) and remove these terms/breakdown in Figure 1. Same for internal/external, they are not used in the rest of the document.

Section 5.1 has the terms "active" and "passive" but doesn't define them. Need to define.

================== End MITM ==============================
--> Any compromised node that participates in the network can cause harm to the network. 
Section 5.3 summary of attacks: do we have a new attack? No. No different than a non-DetNet network. 
But where describe threats, say that compromised router, control plane node or controller can affect that particular threat. Go through section 5 and add line as appropriate.
Mitigation for compromised nodes are not impacted by the introduction of deterministic networking. The same techniques used to mitigate compromised nodes are equally applicable in the DetNet case. 

I3) I looked for, but didn't find issues of bogus or compromised central controllers. This ranges from a node falsely representing itself as a controller so that the network nodes believe it to be authorised to instruct them (and that includes both being discovered as a controller and impersonating a real controller), to software subversion of the real controller. It might even include malicious acts by a network operator.

Much, but not all, of this is hard to protect against. Some of it can be mitigated by monitoring and logging.
---

I4) 8.1.2
-> Remove statements that say we're not addressing controller plane - above additions should address controller plane. 
Attacks on a DetNet controller plane are identical to attacks on any other network control plane and are mitigated using the same strategies. Any future DetNet controller plane documents are expected to provide details and references specific to that document. 

I'm not really comfortable with your choice stated in this section to exclude attacks on the control plane from consideration. It seems to me that a network can be rendered entirely dysfunctional by attacking the control plane so that control packets are delayed, reordered, lost, or misdelivered. I don't see why you consider manipulation or inspection of control plane packets as in scope (I agree they should be in scope), but attacks on the control plane itself as out of scope. In fact, I don't see how you attack a control plane packet without attacking the control plane.

Furthermore, I don't think that this "reveal" should be tucked away in this section: the statement is not specific to the subject of this section.

EAG: I think this stems from the original charter of DetNet WG to address data plane only. Now that the WG is re-chartered to address controller plane, given that this Security draft is still in progress, it probably is time to reconsider that limitation. 
---

I5) In general I support you not wasting any time discussing the concern of a "subverted" node within the DetNet. That is, a router that has been attacked so that it "lies" about conditions in the network, or harvests data in some way. However, this is a concern that is repeatedly expressed by the security community.

Thus, I think it is worth adding a section to describe:
- How extremely bad this situation would be for the whole DetNet (viz.
  it is a closed system in which one bad actor can immediately break the
  whole in very many bad ways)

--> Covered by text added above. 

- How protection against such issues is not just a DetNet concern but
  applies to all routing sub-system

--> Same. 

s
- What measures (outside the scope of DetNet) may be taken to protect
  and verify software loads (signing of software loads, etc.)

--> This is beyond the scope of a protocol specification, and is not introduced by DetNet.  

Note that you do talk about "plug-and-play" in the context of not allowing rogue devices to be added to the network, and that is a good part of the solution, but does not approach protecting against subverted nodes.

--> Already covered above. 

== Minor Issues ==

M3) I struggled a little with determining the value of section 3 given the existence of section 5. In many cases, I found that section 3 started the conversation, but left a lot of open questions about threat models that are not answered until section 5.

--> Agree this is a valid stylistic comment, however others have requested that they want this section to be present, and that they like the section, so we will leave it. 

---

M4) In 3.1 you have

   It is the responsibility of the component designer to ensure that
   this condition is met; this implies protection against excess traffic
   from adjacent flows, and against compromises to the resource
   allocation/deallocation process.

This is good, but I feel it dodges what measures a component designer should take to protect against attacks on / failures by other components in the network.

--> For example through the use of traffic shaping and policing. 

---

M5) 3.3

--> There is nothing unique to redundant path support from an integrity perspective, therefore this paragraph will be deleted. 

   responsibility of the system designer to define these relationships
   with the appropriate security considerations

The word "appropriate" should be a red flag for you. How is the reader to determine what is appropriate unless you tell them? Either include a pointer to the relevant sections of this document, or explain what would be appropriate.

M6) Similarly in 5.1

   Most of the
   direct threats to DetNet are active attacks, but it is highly
   suggested that DetNet application developers take appropriate
   measures to protect the content of the DetNet flows from passive
   attacks.

-->    "Most of the direct threats to DetNet are active attacks, but it is highly suggested that DetNet application developers take appropriate measures to protect the content of the DetNet flows from passive attacks, for example through the use of TLS or DTLS."

M7) 9.1 has
   So the network must provide sufficient
   isolation between flows, for example by protecting the forwarding
   bandwidth and related resources so that they are available to detnet
   traffic, by whatever means are appropriate for that network's data
   plane.
That's a little more excusable, but it is still a bit hard for the reader to know what to do.


-->    So the network must provide sufficient
   isolation between flows, for example by protecting the forwarding
   bandwidth and related resources so that they are available to detnet
   traffic, by whatever means are appropriate for that network's data
   plane, for example through the use of queueing mechanisms. 

---

M8A) 3.3
   At the data plane the implementation of PREOF depends on the correct
   assignment and interpretation of packet sequence numbers, as well as
   the actions taken based on them, such as elimination.  Thus the
   integrity of these values must be maintained by the component as they
   are assigned by the DetNet data plane's Service sub-layer, and
   transported by the Forwarding sub-layer.

Depending on the meaning of "component" (a term you use without definition in this document - although you do give "such as routers") 


--> 	Added def of term “component”: “A component of a DetNet system is used here to refer to any hardware or software element of a DetNet network which implements DetNet-specific functionality, for example all or part of a router, switch, or end system.”

M8B) I should think you have exposed an issue that is not clear to me. You seem to be saying that it is a component's responsibility to maintain the integrity of the packet sequence number values as they are transported across the network. This is at least the responsibility of a pair of adjacent components in cooperation (for example, if the packet is hashed in some way to prevent the value being tampered with). 
M8C) There is also the issue of insertion of packets with spurious sequence numbers to be handled.

-->    In the data plane the implementation of PREOF depends on the correct
   assignment and interpretation of packet sequence numbers, as well as
   the actions taken based on them, such as elimination.  Thus the
   integrity of these values must be maintained by the component as they
   are assigned by the DetNet data plane's Service sub-layer, and
   transported by the Forwarding sub-layer. This is no different than the integrity of the values in any header used by the DetNet (or any other) data plane, and is not unique to redundant paths. From the sequence number injection perspective, it is no different from any other protocols that use sequence numbers. 

---

M11) Should 5.2.4 specifically mention amplification?
EAG: I think this is a good idea, but I will defer to WG on this. Here is what I find for a definition (https://security.radware.com/ddos-knowledge-center/ddospedia/amplification-attack/): 
Amplification Attack: An Amplification Attack is any attack where an attacker is able to use an amplification factor to multiply its power. Amplification attacks are "asymmetric", meaning that a relatively small number or low level of resources is required by an attacker to cause a significantly greater number or higher level of target resources to malfunction or fail.

--> Add bullet to 5.2.4.2 : 
* Amplification - an attacker who injects packets into a flow that is to be replicated will have their attack amplified through the replication process. This is no different than any attacker who injects packets that are delivered through multicast, broadcast, or other point-to-multi-point mechanisms. 
---

M12) In 5.2 I was looking for how DetNet's choice of paths is based on the recorded properties of those paths (e.g., latency, jitter, loss) and how the choice of path can be manipuated by causing short-term changes to the properties of individual links in the network.

--> This topic is not discussing manipulation of latency (Sec 5.2.1, Delay), it is about manipulation of paths. Path choice is a controller plane function, which is already covered in section 5.2.6, Controller Plane.  
so this should be included in the next section which is Controller Plane 5.2.6. 
--> So text of 5.2.5.1 is duplicative and will be removed. Text in 5.2.5.2 will be moved to the end of 5.2.6.2

---

Shouldn't 7.7 (or somewhere else) discuss the security issues introduced by the monitoring mechanisms? For example, if the reporting mechanism is attacked or subverted, or if the monitoring system is tricked. It seems you have introduced a mechanism that can be used to detect attacks, but not acknowledged that this mechanism can, itself, be attacked giving flase positives or hiding negatives.

--> This is not unique to DetNet; it is identical to the case of any monitoring mechanism. 
--> Add: " If the monitoring or reporting mechanism is attacked or subverted, this can result in malfunction of the network. The design of the monitoring system needs to take this into account based on the specifics of the monitoring or reporting system being considered". 

---

M15) 8.1.4 is, perhaps, a little brief. What attacks can be achieved using this new surface?

--> This is no different than for any other protocol which introduces a new YANG model; there is no DetNet specific consideration here. 

---

M22) 8.1.24 (actually 8.1.23) 

I think the reader looks to this document to answer the qustion you pose and not simply say that it is TBD. (By the way, you would need to expand 'TBD' and say which table/figure you are referring to.)
	Yes that text is an unresolved holdover from my initial pass at these sections, which phrased them all as questions, which were eventually substituted with “answers”. We didn’t have any answers for this one, but it still is a valid question, I would say. In a way it is the same question as the “watchman” item above (M14). 

--> Rewrite section 8.1.23: 

A DetNet network must be made secure against devices failures,
 attackers, misbehaving devices, and so on. Does the threat affect
 such security measures themselves, e.g. by attacking SW designed to
 protect against device failure?
 This is TBD, thus there are no specific entries in the mapping table
 Figure 4, however that does not imply that there could be no relevant
 attacks.

--> A DetNet network must be made secure against devices failures, attackers, misbehaving component, and so on. If the security mechanisms protecting the DetNet are attacked or subverted, this can result in malfunction of the network. The design of the security system itself needs to take this into account based on the specifics of the security system being considered. The general topic of protection of security mechanisms is not unique to DetNet; it is identical to the case of securing any security mechanism for any network. The text of this document addresses these concerns to the extent that they are relevant to DetNet. 

---

M24) The section numbers in Figure 4 seem to be all wrong.
EAG: And so it is. This is a bad implementation of a table that contains references, since it is done as “artwork” with “manual text” for the section numbers. Does anyone have a clever idea how to do this? Maybe reformat as a bullet list? 
--> Delete the Section column. 
---

M25) Figure 5 shows six themes that have no vulnerability to any attack. Is that really right? It seems remarkable enough that you might add a note to help the reader know that this is indeed what you intended the table to show, and possibly to give a reason.

--> "The row items which have no threats associated with them are included in the table for completeness of the list of Use Case Common Themes, and do not have DetNet-specific threats associated with them". 
---

M26) 8.3

   Thus OAM traffic presents no additional (i.e.  OAM-specific) DetNet security considerations.

Isn't it the case that if an attacker is able to engineer a situation where there is a massive increase in OAM traffic, this can have a negative impact on the ability of the DetNet to deliver its services.
There are three ways such an attack can have an effect:
- the OAM traffic impedes the user plane traffic (such as consuming
  bandwidth, requiring critical processing, impeding timely delivery)
- the additional OAM traffic masks other OAM traffic that reports a
  genuine network issue
- the OAM traffic clogs up the control/management plane bandwidth of
  processing so that the operator is not able to properly control the
  network

There are various ways in which an attacker can stimulate the network to generate excess OAM traffic.
Additionally, of course, fake or modified OAM can lead the management system to believe that there are faults in the network causing traffic to be rerouted onto othe paths resulting in lower levels of service or interception of traffic.
And finally, modified or filtered OAM packets may lead the system to fail to notice real network problems.

--> Rewrite paragraph: 
Replace: "Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet security considerations." With:

--> "From the perspective of an attack, OAM traffic is indistinguishable from DetNet traffic and the network needs to be secure against injection, removal, or modification of traffic of any kind, including OAM traffic. A DetNet is sensitive to any form of packet injection, removal or manipulation and in this respect DetNet OAM traffic is no different. Techniques for securing a DetNet against these threats have been discussed elsewhere in this document."

M27 (from Adrian email of 31Jul20)) I noticed in section 9 that there is discussion of the sub-layer security measures for IP and Ethernet networks, but (of course?) no mention of security for MPLS encapsulations.
In that context I wondered if Detnet has any interest in https://www.ietf.org/archive/id/draft-ietf-mpls-opportunistic-encrypt-03.txt

--> Add "New work on MPLS security may be applicable, for example [add reference to draft-ietf-mpls-opportunistic-encrypt-03.txt] 

== Style Issues ==

S7) I'm surprised that you have no Normative references. Is it not necessary to understand some basic DetNet documents in order to understand this document?

--> Agree to put all standards track documents into normative references section (not non-normative ones). 

++++++++++++++++++++++  End of Work Session 28Aug20 Review ++++++++++++++++++++++++++++++++++++++++
REVIEW TO BE CONTINUED STARTING HERE


S5) I didn't understand the practicality of node authenticaiton as described in 7.3. Is this intended as a check on entry into the network (only authenticated sources can introduce traffic to the network), a check at the destiantion (only authenticated sources can send to this destination), or a per-hop check (is this traffic authenticated to be in the network? Furthermore, are the checks per packet or per flow?

There are obvious scaling and and key exchange issues involved.
EAG HOLD
---


From Ben Kaduk: 

1) "security considerations for when flow aggregation is in play, namely that misbehavior from one component flow can affect sibling flows as collateral damage."
2) "the use of HMAC without a co-located discussion of the need for key distribution "
3) "having a taxonomy of threats titled "threat model"".
4) Re:    "The primary considerations for the data plane is to maintain integrity of data and delivery of the associated DetNet service
   traversing the DetNet network.  Application flows can be protected" - "I'd suggest leading in to this with "As for all communications protocols," to be clear that this paragraph is not trying to cover the bits that are "unique to DetNet" as much as remind the reader of general best practices."

These I don't know what to do with: 

5) "This might also be a good place to note that correct operation of the PREOF functions is pretty critical, and failures there could lead to pretty catastrophic situations for the operational technology relying on them.  I don't think there are ways for an attacker to try to attack them directly, but Murphy's Law can be a pretty effective attacker, too."

6) Re:  "At the management and control level DetNet flows are identified on a
   per-flow basis, which may provide controller plane attackers with
   additional information about the data flows (when compared to
   controller planes that do not include per-flow identification).  This
   is an inherent property of DetNet which has security implications
   that should be considered when determining if DetNet is a suitable
   technology for any given use case." - "I might also note that attackers with access to the controller plan already have pretty significant attacks available to them."
 
+++++++++++++++++ End ++++++++++++++++++++++++
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet