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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 29 January 2021 15:07 UTC

Return-Path: <magnus.westerlund@ericsson.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 09CD23A1059; Fri, 29 Jan 2021 07:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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_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=ericsson.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 F6w3jgofuWgm; Fri, 29 Jan 2021 07:07:38 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30057.outbound.protection.outlook.com [40.107.3.57]) (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 59A6C3A1058; Fri, 29 Jan 2021 07:07:37 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y6VtAKtq8RipQYa593g1G+WwLj0ljnyCaPgJLKq2qMYI2ntmzVl/cG+WYXuF1CpMuKr4ZVGxdRKDqR/0luf4zrnX6ljgRoZMA+59LCEypg9eWI/0N7djiQmlCy/g41QOaItmc5HROz5vieHQhmN4DTazGX2unZOtzIgNoqSGoqaDdiyAakudYZZU6LILenf0kEqeuSWUrIJn9Hmx81tNNHF0qRvmyVMf6+/WScIEUWlSpHnQzGhpSPln7d6D0/8438DzXV/aoTNk58/E6/HVfhUphhyVRkCyN+IFcunhG+E3QMOjpE3HMDKKBo3RNP4jeEEw17d2xn+5RW+qVjYA4g==
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=eRONpQdla1kzPPpWNOayw46Nw7uGkYe622UH8ecyl1s=; b=eXPqKK2J6Zg2kJXo4lh1RepvgHWa+HjEgrm8K/1KCcLyEPXPp6bR6ZADAjjbERFvnwq2bMKaqVuJ9LKdO4dgfJ/tMXZUFyrMPDPvkxUTqjfn0IFnOay/ri9magno4zA/nrqSEdLBS87xwLF0nF7V6sa1VeBt75WyWLDNn6IQIG231mcHHGR7yn3kcM/XtKzW7o7QUTzETkUmofMpRQSBlXVleAoRPbEnfhidARDLMGJFHxyQyhe3hztVYbQ51zwDZMDVFUhjCVqdHmaiB58bqOrdaVQmmjTf/XGt9xqsjFhwqh8EXm7VgiVCFoM9Wb0UMkWLsogiD/eSxIQUHUX+dg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRONpQdla1kzPPpWNOayw46Nw7uGkYe622UH8ecyl1s=; b=NUZ60jeveeg+Yek26iUo12FqAPD8zcMUtziAsIxxwsi64RG4DEuRtRq2yFCkHrEEve2Yb4FCiOYOSbmbx/VE0RtDhj6WPNUXec8e2yS1OVGdEfMtp7GNm2enE4KjjFcwjfXXyoJCD8GnHYzRpfApzjBFnDsa/1krQYweUN/pDgY=
Received: from (2603:10a6:803:10::30) by VI1PR07MB4893.eurprd07.prod.outlook.com (2603:10a6:803:9b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.10; Fri, 29 Jan 2021 15:07:32 +0000
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::6cd2:247d:3389:381]) by VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::6cd2:247d:3389:381%6]) with mapi id 15.20.3805.007; Fri, 29 Jan 2021 15:07:32 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "ethan@ieee.org" <ethan@ieee.org>
CC: "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-security@ietf.org" <draft-ietf-detnet-security@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, "David.Black@dell.com" <David.Black@dell.com>
Thread-Topic: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
Thread-Index: AQHW2Gx8UD3yjueSTECZOXuaCTpEiqoDXCkAgBf7twCAALVmgIAA1vaAgCIL0wA=
Date: Fri, 29 Jan 2021 15:07:32 +0000
Message-ID: <430e475c2bc772b4dc02f5e3cc54519e9cf0f8ac.camel@ericsson.com>
References: <160864632278.13800.15298127874258170906@ietfa.amsl.com> <MN2PR19MB40456E5376B115C147B7E08C83DF0@MN2PR19MB4045.namprd19.prod.outlook.com> <0a5e01d6e484$5dbdbca0$193935e0$@ieee.org> <95c9bebe84acd87c157ae72420338e213c521ee6.camel@ericsson.com> <0bca01d6e54a$8be72410$a3b56c30$@ieee.org>
In-Reply-To: <0bca01d6e54a$8be72410$a3b56c30$@ieee.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: ieee.org; dkim=none (message not signed) header.d=none;ieee.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 88329ce8-1da7-4b01-ae49-08d8c4679a94
x-ms-traffictypediagnostic: VI1PR07MB4893:
x-microsoft-antispam-prvs: <VI1PR07MB489316EA48A0CA7006F7FAD295B99@VI1PR07MB4893.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1443;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: R3kRSkdBjb2fpw+QqN6ru1Rnro7EcbOYX55gnSCOG9DnWjQFQ6L1N/gVEpe0qz8n55/do1Q5JMzpH2YulHKriNf0FROpsymr744b62COjtIQYscKC5od1Q56lUZfaUL+rYGL5DjBoFMHyJJVCClFdKP7nyvqNUx6Zq3TJowf9OY+vGhHI7IF2KvzP/l7zS/YfTIiDeeJ60FoIs76hMUwxTOhyqBHUITvPCG3ZgIL3br4DqVr0gAHFHu5l8dNa54OzLY3R/GkbS9iV6TDzWyugDWZTXQ4ouUdabSklRdOImBKAlGnord1HwT5wwyJKFvHM6EONgphjxTm9moCfn94OljhgXhM+/TCXp2+t3WGqykIg+W+55lRHn2aWNb+w8R/SIZeN1xOUUjDPTbd8rMi/6cwNxzfXpj54MoCbzp4L+wyqsT7l5igztQZFUy0AVnyRD6/aPZcYWuSbRp3QUfU7i8KhgIeveyBYjMOafMc3E7VlfAZUOEJp/KNt+kSNYjlHU2wdMnTCK974zOg7lY8hv4KVAhTv/5Lmak1E2iOrLYdR6N8yUECwO9aD8TUcaBtjK7+IZpzk0/Ofup0Ol9sTB6srhGq4zBnI5oNGkkzr2xkBqhXNcKtpzN0l2Ql2dY/jq5yYA035aRsDoxl7LHL6Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(2906002)(83380400001)(2616005)(26005)(99936003)(186003)(15650500001)(44832011)(76116006)(53546011)(8936002)(86362001)(66574015)(316002)(8676002)(5660300002)(54906003)(66446008)(66556008)(30864003)(4326008)(36756003)(966005)(6506007)(64756008)(478600001)(66476007)(66946007)(66616009)(91956017)(6512007)(6486002)(6916009)(71200400001)(99106002)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?MWt0YzRPa0dpQWx6OGNjZzBpaVByVHpwV3FOdW9RK0xuR3I1a2NCSEhVdUh6?= =?utf-8?B?dXNUZWhkUXJOQmZwSlUwYk5vUFBWOXRvMnpGL2dGaWZqOExZS0x6MS9MTXlY?= =?utf-8?B?bTJtZ2E4N2UyNEIvMk8xUm5haDlYdG5PMWFnUHVqek1tdWFTQmNGblVaVmJF?= =?utf-8?B?TkhDMXIwaXBpUE9MVnArdDAwc1ZhcTM0SkpqQmFWMDlRK1VQblViRzA0QkY2?= =?utf-8?B?c1BNMmVoWkhEYnlBWTVtVXo0TWFEa0NrVzVoUkg4ZTZxSWsyOFhiRlBtanNq?= =?utf-8?B?OGtucUxWTGJUNG1Vd0pkOVBQMCtnWEp0OTkveHJNNFg2eiszKzVRcTFhb0xG?= =?utf-8?B?SzluMld0YzFiYVRQZEplb01CNjhLNTdlaUxGNHM3TUFQWUNSVjJXNEJvdHFX?= =?utf-8?B?TWYweUxtRnRnb3pvTnh6K1BVK0xqNy9scDJVZzBxV0tMQUQxWjgwNDltWngv?= =?utf-8?B?WHdEVi8yclZVVUJHWXdjQTdyQ29CMElLQWpOY2ZnQkViRHVJM0FoTGVOK0lj?= =?utf-8?B?UERZZEZqejdlTG5SSUgxSnQzVy9xakpnWElDNzV4d0hjYWFHV3dRWGVCOVFa?= =?utf-8?B?cDRVelhQRmxFWDJaVmZ2a3hTMGJMMk5mNzlSZ0lmQTVFR0dzQjQ4cXM5R011?= =?utf-8?B?WTRDbUUzME1mbGFFVG9hRllNQnJQcUpDaVBERTY0d3FkWHZab0tvZWtLWmt4?= =?utf-8?B?ZlUzajdYNS9FQlJVeHhjclZuaHBkS2pzTnhmNmNQYjRVY1ZZZFFrZ2dIelFv?= =?utf-8?B?UG95WHhNU1FaYjArcmgwL25qVXVqSGRDQ2t0Z3hYZ0E2bFljTUpGSy9QSEo2?= =?utf-8?B?VDVLNDhWdmZiMjA0bCtKdDdackFuN21aRW03ZmdVWmxzeDAyVHZUY3M5TGQ4?= =?utf-8?B?dGl6NXExdCtKaE5tcG1ZbVNFQ1N0OXJPZC80VjFzUEIwem9ObDBYQ1QvUXJG?= =?utf-8?B?ZGZUcGVqT1E3VDliaGNMekxRSHVXUDhUaFBoK3c4UW8waGdzRlh5UUNjOUNL?= =?utf-8?B?TktHL3RwRSt2Z1RlMXVBN3VRQWNxSXIxSjQ1RS9JWGZhUlA2TGx3dS8wa3JQ?= =?utf-8?B?VmJMcmhzWEFFWnY2cjlWTC93WjJoSFM1VnBLTnprSHJJZnFRYS91MEl6M3Ax?= =?utf-8?B?K2dRNFJtaFdUUHE1YTZQVmk0ZnVjYm9wcGZUZlpsallaRVp4RWlMQWlvRHkz?= =?utf-8?B?SnRYeDVsZU9Gc2ZOR1ZYcDNwZnl6R0dOOUlPWkxzcDl1eEN2TytCZDNxVVVQ?= =?utf-8?B?TXA3YnFCWVF0dm5aM1lUcUdRcXg1VUJ1bzBoZmYxT25OY2t0UnBkT0xIdWdV?= =?utf-8?B?NVZrb2xZbFpKRWRReHZ0elhRWWlDaWNLeUNVSXNyRzMyQlM0bXBVQUtnOElC?= =?utf-8?B?ejhnRFhNQ0RNZTNRck9pWjY5aHd4eGFRbkdRK3Z3Ky85K09wY0FXWXRZK2Z6?= =?utf-8?B?RWhWTWZ2bUR4UWhaKy9LVmVBdmk3aml1NkdnSTdRPT0=?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-cpLCF2qhvwBH7BnrLLvP"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR0702MB3775.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 88329ce8-1da7-4b01-ae49-08d8c4679a94
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2021 15:07:32.5926 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: H1t6XDoi/NrKDCWnyVce9xwjYfuUngH2xH59JuxVRUFYdZS7jZzvpYuuj17EitrNIH1GKno8yq9nNK8LdIlQh6DjtpUZ88N9tY4gYvBucic=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4893
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/EA8Smr9li1fY48zw5XkoN6WMIqw>
Subject: Re: [Detnet] Magnus Westerlund'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: Fri, 29 Jan 2021 15:07:42 -0000

Hi,

First, of all I am sorry to not have followed up earlier. 

I think Rev 2 was better and have multiple sections makes it easier to read. 

So I am ready to clear my discuss when the improved text in Section 3.1 is
avaialble. 

Cheers

Magnus



On Thu, 2021-01-07 at 15:12 -0800, Ethan Grossman wrote:
> Hello Magnus,
> Thank you again for your considered review, and this follow-up. I have
> refactored section 3.1 as shown below, in order to incorporate your thoughts.
> Please let us know what you think - I am committed to making this draft meet
> or exceed your standards, and I do appreciate your direction. 
> Sincerely,
> Ethan. 
> -----------REV2 START--------------------------------
> REV1 (the new OLD, i.e. yesterday's revision :- )  
> 3.1.  Resource Allocation
> 
> A DetNet system security designer relies on the premise that any resources
> allocated to a resource-reserved (OT-type) flow are inviolable; in other words
> there is no physical possibility within a DetNet component that resources
> allocated to a given flow can be compromised by any type of traffic in the
> network; this includes malicious traffic as well as inadvertent traffic such
> as might be produced by a malfunctioning component, or due to interactions
> between components that were not sufficiently tested for interoperability.
> From a security standpoint, this is a critical assumption, for example when
> designing against DOS attacks.  
> 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, for example through the use of traffic shaping and policing.
> However, this assumption on the part of the DetNet system designer must be
> tempered by the fact that any given component is designed for some set of use
> cases and accordingly will have certain limitations on its security properties
> and vulnerabilities. For example, due to cost and complexity factors, the
> security properties of a component designed for low-cost systems may be quite
> different from a component with similar intended functionality, but designed
> for highly secure or otherwise critical applications, perhaps at substantially
> higher cost. Thus, a significant responsibility of the designer of any
> component intended for use with DetNet is that they clearly document the
> security properties of the component. For example, to address the case where a
> corrupted packet in which the flow identification information is compromised
> and thus may incidentally match the flow ID of another (“victim”) DetNet flow,
> resulting in additional unauthorized traffic on the victim, the documentation
> might state that the component employs integrity protection on the flow
> identification fields. 
> Even in the case that the security properties of the component as designed are
> well specified and understood, if the component malfunctions, for example due
> to physical circumstances unpredicted by the component designer, it may be
> difficult or impossible to fully prevent malfunction of the network. However,
> all networks are subject to this level of uncertainty; it is not unique to
> DetNet. Having said that, DetNet raises the bar by changing many added latency
> scenarios from tolerable annoyances to unacceptable service violations.   That
> in turn underscores the importance of system integrity, as well as correct and
> stable configuration of the network and its nodes, as discussed in [reference
> to Introduction section].  
> . . .
> END
> 
> REV2: (Second Revision 7Jan21)
> 3.1.  Resource Allocation
> 
> 3.1.1 Inviolable Flows
> 
> A DetNet system security designer relies on the premise that any resources
> allocated to a resource-reserved (OT-type) flow are inviolable; in other words
> there is no physical possibility within a DetNet component that resources
> allocated to a given DetNet flow can be compromised by any type of traffic in
> the network; this includes malicious traffic as well as inadvertent traffic
> such as might be produced by a malfunctioning component, or due to
> interactions between components that were not sufficiently tested for
> interoperability. From a security standpoint this is a critical assumption,
> for example when designing against DOS attacks. In other words, with correctly
> designed components and security mechanisms, one can prevent malicious
> activities from impacting other resources.
> 
> However, achieving the goal of absolutely inviolable flows may not be
> technically or economically feasible for any given use case, given the broad
> range of possible use cases (e.g. [reference to DetNet Use Cases RFC8578]) and
> their associated security considerations as outlined in this document. It can
> be viewed as a continuum of security requirements, from isolated ultra-low
> latency systems that may have little security vulnerability (such as an
> industrial machine) to broadly distributed systems with many possible attack
> vectors and OT security concerns (such as a utility network). Given this
> continuum, the design principle employed in this document is to specify the
> desired end results, without being overly prescriptive in how the results are
> achieved, reflecting the understanding that no individual implementation is
> likely to be appropriate for every DetNet use case. 
> 
> 3.1.2 Design Trade-Off Considerations in the Use Cases Continuum
> 
> It is important for the DetNet system designer to understand, for any given
> DetNet use case and its associated security requirements, the interaction and
> design trade-offs that inevitably need to be reconciled between the desired
> end results and the DetNet protocols, as well as the DetNet system and
> component design. 
> For any given component, as designed for any given use case (or scope of use
> cases), it is the responsibility of the component designer to ensure that the
> premise of inviolable flows is supported, to the extent that they deem
> necessary to support their target use cases.  
> 
> For example, the component may include traffic shaping and policing at the
> ingress, to prevent corrupted or malicious or excessive packets from entering
> the network, thereby decreasing the likelihood that any traffic will interfere
> with any DetNet OT flow. The component may include integrity protection for
> some or all of the header fields such as those used for flow ID, thereby
> decreasing the likelihood that a packet whose flow ID has been compromised
> might be directed into a different flow path. The component may verify every
> single packet header at every forwarding location, or only at certain points.
> In any of these cases the component may use dynamic performance analytics [ref
> to DPA section] to cause action to be initiated to address the situation in an
> appropriate and timely manner, either at the data plane or controller plane,
> or both in concert. The component’s software and hardware may include measures
> to ensure the integrity of the resource allocation/deallocation process. Other
> design aspects of the component may help ensure that the adverse effects of
> malicious traffic are more limited, for example by protecting network control
> interfaces, or minimizing cascade failures. The component may include features
> specific to a given use case, such as configuration of the response to a given
> sequential packet loss count. 
> 
> Ultimately, due to cost and complexity factors, the security properties of a
> component designed for low-cost systems may be (by design) far inferior to a
> component with similar intended functionality, but designed for highly secure
> or otherwise critical applications, perhaps at substantially higher cost. Any
> given component is designed for some set of use cases and accordingly will
> have certain limitations on its security properties and vulnerabilities. It is
> thus the responsibility of the system designer to assure themselves that the
> components they use in their design are capable of satisfying their overall
> system security requirements. 
> 
> 3.1.3 Documenting the Security Properties of a Component
> 
> In order for the system designer to adequately understand the security related
> behavior of a given component, the designer of any component intended for use
> with DetNet needs to clearly document the security properties of that
> component. For example, to address the case where a corrupted packet in which
> the flow identification information is compromised and thus may incidentally
> match the flow ID of another (“victim”) DetNet flow, resulting in additional
> unauthorized traffic on the victim, the documentation might state that the
> component employs integrity protection on the flow identification fields. 
> 
> 3.1.4 Fail-Safe Component Behavior
> 
> Even when the security properties of a component are understood and well
> specified, if the component malfunctions, for example due to physical
> circumstances unpredicted by the component designer, it may be difficult or
> impossible to fully prevent malfunction of the network. The degree to which a
> component is hardened against various types of failures is a distinguishing
> feature of the component and its design, and the overall system design can
> only be as strong as its weakest link. 
> However, all networks are subject to this level of uncertainty; it is not
> unique to DetNet. Having said that, DetNet raises the bar by changing many
> added latency scenarios from tolerable annoyances to unacceptable service
> violations.   That in turn underscores the importance of system integrity, as
> well as correct and stable configuration of the network and its nodes, as
> discussed in [reference to Introduction section].  
> . . .
> END
> -----------REV2 END--------------------------------
> 
> -----Original Message-----
> From: Magnus Westerlund <magnus.westerlund@ericsson.com> 
> Sent: Thursday, January 7, 2021 2:23 AM
> To: ethan@ieee.org
> Cc: detnet@ietf.org; draft-ietf-detnet-security@ietf.org; iesg@ietf.org; 
> detnet-chairs@ietf.org; David.Black@dell.com
> Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-
> security-13: (with DISCUSS and COMMENT)
> 
> Hi,
> 
> So I think I did missinterpret the intention of the original sentence a bit.
> This longer text do help me understand and it might be useful for others.
> However, I do wonder if there are an even better description of this?
> 
> So to me there appear to be a design principle here that the resources for one
> flow are inviolable. That way one can keep the different flows and resource
> allocations independent. However, this design principle is only fulfilled if
> the
> individual components and the setup of the chain of components ensures this
> design priniciple. 
> 
> So with correctly designed components and security mechanisms one can prevent
> malious acitvities from impacting other resources. And this might be the
> simpler
> case at least on a theoreticall level as the malicous attacker can be limited
> in
> where it can impact traffic flows or network control interfaces through
> security
> mechanisms. 
> 
> For network internal malfunctions this design principle might not be as
> feasible
> to achive the total goal, but the design principle should lead to that impact
> is
> minimized to the diretly affected flows, i.e. avoid casade failures. For my
> case
> of rewritten flow-id then only the original and target flow should be
> affected.
> In addition this failure should rapidly be detected so the failure can be
> addressed. 
> 
> As you discuss to attempt to ensure this inviolable resource allocation, to
> detect my specific case, the system designer needs a component where each
> individual flow is verified to be within resource allocation as each single
> device where resource contention could occurr, i.e. in each router or switch
> on
> the path through the network. 
> 
> So taking my specific case of network internal rewrite of the flow-ids. With
> flow shapers in each forwarding instance one can prevent the flow to go beyond
> its resource allocation and cause impact outside of the directly impacted
> flows.
> However, the system and its protocols have not been built to prevent the
> impacted flow from being harmed here as this internal failure is unlikely
> enough
> that putting in the mechanism to verify each single packet belonging to each
> flow is deemed to expensive. Instead it is trade-off that a flow shaper would
> cause drops if over using the resources, raising an alarm that something is
> malfunctioning as these drops occurs. While having security mechanism to
> identify flows correctly at the ingress and prevent malicous attackers
> modified
> packets to join a flow is likely a necessary mechanism. 
> 
> So the whole point with this text was to verify if I have correctly understood
> what is attemtped to described here. And secondly maybe indicate that the
> proposed text maybe can be further improved by more accurately describe the
> principle and the fact that certain choices have been made on protocol level
> for
> what support is required. In addtion the implementor of each component as well
> as the system builder needs to consider how the set of chosen components
> interact to reach the security goals related to different aspects, in this
> case
> the resource allocation. 
> 
> Please consider if your text proposal can be further improved to more
> correctly
> describe what is relevant here. As the section is intended to be a high level
> requirement on individual components the hard question is how much requirement
> is necessary to be explicit about. I think the aggregation example in Section
> 3.1 do point to the challenges here to fulfill this design principle. As the
> goal of aggregating is to only need aggregate state in the middle which in its
> turn can violate the principle of inviolable for each component, as adding one
> flow to much to the aggregate through an error will potentially impact all the
> other component flows. 
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> On Wed, 2021-01-06 at 15:33 -0800, Ethan Grossman wrote:
> > Hi Magnus,
> > Thank you for your review comments, they are very helpful. We have
> > incorporated David's comments into our proposed new text for the two
> > sections referenced, as follows. Please let us know if this sufficiently
> > addresses your comments. 
> > Sincerely,
> > Ethan (as DetNet Security draft editor) 
> > 
> > ----------------START --------------------------------------------
> > OLD: 
> > 3.1.  Resource Allocation
> > A DetNet system security designer relies on the premise that any resources
> > allocated to a resource-reserved (OT-type) flow are inviolable, in other
> > words there is no physical possibility within a DetNet component that
> > resources allocated to a given flow can be compromised by any type of
> > traffic in the network; this includes both malicious traffic as well as
> > inadvertent traffic such as might be produced by a malfunctioning component,
> > for example one made by a different manufacturer.  From a security
> > standpoint, this is a critical assumption, for example when designing
> > against DOS attacks.
> > 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, for example through the use of traffic
> > shaping and policing.
> > . . .
> > NEW: 
> > 3.1.  Resource Allocation
> > A DetNet system security designer relies on the premise that any resources
> > allocated to a resource-reserved (OT-type) flow are inviolable; in other
> > words there is no physical possibility within a DetNet component that
> > resources allocated to a given flow can be compromised by any type of
> > traffic in the network; this includes malicious traffic as well as
> > inadvertent traffic such as might be produced by a malfunctioning component,
> > or due to interactions between components that were not sufficiently tested
> > for interoperability. From a security standpoint, this is a critical
> > assumption, for example when designing against DOS attacks.  
> > 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, for example through the use of traffic
> > shaping and policing.
> > However, this assumption on the part of the DetNet system designer must be
> > tempered by the fact that any given component is designed for some set of
> > use cases and accordingly will have certain limitations on its security
> > properties and vulnerabilities. For example, due to cost and complexity
> > factors, the security properties of a component designed for low-cost
> > systems may be quite different from a component with similar intended
> > functionality, but designed for highly secure or otherwise critical
> > applications, perhaps at substantially higher cost. Thus, a significant
> > responsibility of the designer of any component intended for use with DetNet
> > is that they clearly document the security properties of the component. For
> > example, to address the case where a corrupted packet in which the flow
> > identification information is compromised and thus may incidentally match
> > the flow ID of another ("victim") DetNet flow, resulting in additional
> > unauthorized traffic on the victim, the documentation might state that the
> > component employs integrity protection on the flow identification fields. 
> > Even in the case that the security properties of the component as designed
> > are well specified and understood, if the component malfunctions, for
> > example due to physical circumstances unpredicted by the component designer,
> > it may be difficult or impossible to fully prevent malfunction of the
> > network. However, all networks are subject to this level of uncertainty; it
> > is not unique to DetNet. Having said that, DetNet raises the bar by changing
> > many added latency scenarios from tolerable annoyances to unacceptable
> > service violations.   That in turn underscores the importance of system
> > integrity, as well as correct and stable configuration of the network and
> > its nodes, as discussed in [reference to Introduction section].  
> > . . .
> > END
> > 
> > OLD: 
> > 8.1.6.  End-to-End Delivery
> > Packets sent over DetNet are not to be dropped by the network due to
> > congestion.  (Packets may however intentionally be dropped for intended
> > reasons, e.g. per security measures).
> > . . .
> > NEW: 
> > 8.1.6.  End-to-End Delivery
> > Packets that are part of a resource-reserved DetNet flow are not to be
> > dropped by the DetNet due to congestion.  Packets may however be dropped for
> > intended reasons, for example security measures. For example, consider the
> > case in which a packet becomes corrupted (whether incidentally or
> > maliciously) such that the resulting flow ID incidentally matches the flow
> > ID of another DetNet flow, potentially resulting in additional unauthorized
> > traffic on the latter. In such a case it may be a security requirement that
> > the system report and/or take some defined action, perhaps when a packet
> > drop count threshold has been reached (see also [reference to Dynamic
> > Performance Analytics section]). 
> > . . .
> > END
> > 
> > -----------------------END-------------------------------------
> > 
> > -----Original Message-----
> > From: Black, David <David.Black@dell.com> 
> > Sent: Tuesday, December 22, 2020 9:19 AM
> > To: Magnus Westerlund <magnus.westerlund@ericsson.com>om>; The IESG
> > <iesg@ietf.org>
> > Cc: detnet@ietf.org; draft-ietf-detnet-security@ietf.org; lberger@labn.net;
> > detnet-chairs@ietf.org; Black, David <David.Black@dell.com>
> > Subject: RE: [Detnet] Magnus Westerlund's Discuss on
> > draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
> > 
> > Hi Magnus,
> > 
> > > Can we really ensure that a malfunctioning component can't compromise 
> > > the resources of another one. The most simple example I would have is 
> > > a router with a malfunction rewriting the destination address or flow 
> > > label of a packet causing the packet to change the flow it is 
> > > belonging too,
> > 
> > No, but ...
> > 
> > ... DetNet is fundamentally relying on system integrity and correct
> > configuration of the DetNet implementations.  This is not a new concept -
> > e.g., if an MPLS LSR fouls up the label switching, all manner of things can
> > go very wrong very quickly ... which is something that generally doesn't
> > happen in practice.  That said, DetNet raises the bar by changing many added
> > latency scenarios from tolerable annoyances to unacceptable service
> > violations.   That in turn increases the importance of system integrity and
> > correct/stable configuration of the network and its nodes.  I would suggest
> > a rewording along these lines if that's acceptable to you, as I don't think
> > this area of concern justifies additional defense mechanisms in the data
> > planes.
> > 
> > > I would also recommend that you don't indicate that a different 
> > > manufacturer can be blamed. Isn't a malfunction going to occur where 
> > > they occur, it is not like a single vendor network will be without 
> > > malfunctions due to hardware issue, nor have its set of software bugs.
> > 
> > +1
> > 
> > Thanks, --David (as Transport Technical Advisor to the detnet WG)
> > 
> > > -----Original Message-----
> > > From: detnet <detnet-bounces@ietf.org> On Behalf Of Magnus Westerlund 
> > > via Datatracker
> > > Sent: Tuesday, December 22, 2020 9:12 AM
> > > To: The IESG
> > > Cc: detnet@ietf.org; draft-ietf-detnet-security@ietf.org; 
> > > lberger@labn.net; detnet- chairs@ietf.org
> > > Subject: [Detnet] Magnus Westerlund's Discuss on
> > 
> > draft-ietf-detnet-security-13:
> > > (with DISCUSS and COMMENT)
> > > 
> > > 
> > > [EXTERNAL EMAIL]
> > > 
> > > Magnus Westerlund 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 3.1:
> > > 
> > >    A DetNet system security designer relies on the premise that any
> > >    resources allocated to a resource-reserved (OT-type) flow are
> > >    inviolable, in other words there is no physical possibility within a
> > >    DetNet component that resources allocated to a given flow can be
> > >    compromised by any type of traffic in the network; this includes both
> > >    malicious traffic as well as inadvertent traffic such as might be
> > >    produced by a malfunctioning component, for example one made by a
> > >    different manufacturer.
> > > 
> > > Can we really ensure that a malfunctioning component can't compromise 
> > > the resources of another one. The most simple example I would have is 
> > > a router with a malfunction rewriting the destination address or flow 
> > > label of a packet causing the packet to change the flow it is 
> > > belonging too, thus if occurring for any significant amount of packets 
> > > causing overflow in the next hop router when the original and the 
> > > remarked flow compete for the same resources assigned. The only way to 
> > > ensure that this happens is to verify a strong header integrity 
> > > protection at each point a decision on how to forward, classify or 
> > > remark the flow is done. So Section
> > > 3.3 indicate that this is an issue, but only discusses how it can be 
> > > solved over ethernet. This issue hasn't been well handled in either 
> > > the MPLS or IP detnet data planes as no additional mechanism was required
> > 
> > to ensure this criteria is meet.
> > > 
> > > So I think the requirement that also malfunctions in equipment don't 
> > > result in flow violations is hard, and will require that the already 
> > > approved data plane specification needs additional mechanism that 
> > > verify all data used on each occasion the data is used. Neither MPLS 
> > > nor IP as currently specified fulfill this, not even against 
> > > non-malicious malfunctions or corruption type malfunctions. Then we 
> > > have those malfunction that breaks the network or where control plane
> > 
> > information provided is being corrupted.
> > > 
> > > I have only looked a bit deeply on one type of malfunction that I know 
> > > that can occur. I convinced that this document will indicate a number 
> > > of additional potential ways things can go wrong that can't be 
> > > determined without additional mechanisms and likely additional per 
> > > packet fields. Thus, I think we need to discuss if the security 
> > > properties matches the actual approved data plane, or if the property is
> > 
> > so important that the data plane specification is moved back to the WG to be
> > fixed?
> > > 
> > > I would also recommend that you don't indicate that a different 
> > > manufacturer can be blamed. Isn't a malfunction going to occur where 
> > > they occur, it is not like a single vendor network will be without 
> > > malfunctions due to hardware issue, nor have its set of software bugs.
> > > 
> > > Section 9.1:
> > > 
> > >    The IP protocol has a long history of security considerations and
> > >    architectural protection mechanisms.  From a data plane perspective
> > >    DetNet does not add or modify any IP header information, so the
> > >    carriage of DetNet traffic over an IP data plane does not introduce
> > >    any new security issues that were not there before, apart from those
> > >    already described in the data-plane-independent threats section
> > >    Section 5, Security Threats.
> > > 
> > > The above requirement from Section 3.1 in regards to IP header fields 
> > > used for flow classification are not automatically fulfilled without 
> > > additional mechanisms. Thus, I would claim that DETNET unless Section 
> > > 3.1 requirement is minimized will require support for a strong 
> > > integrity mechanism over all headers. So if this needs to be keyed or 
> > > not is totally dependent on if malicious modifications of packet headers
> > 
> > needs to be taken into account or not.
> > > 
> > > Section 9.2:
> > > 
> > > Same as previous issue but for integrity over the MPLS headers.
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > > 
> > > 8.1.6.  End-to-End Delivery
> > > Packets sent over DetNet are not to be dropped by the network due to
> > >    congestion.  (Packets may however intentionally be dropped for
> > >    intended reasons, e.g. per security measures).
> > > Maybe it need to be stated that packets for a flow that are within 
> > > flow parameters are not to be dropped due to congestion.
> > > 
> > > The security aspects include packets being dropped due to corruption 
> > > malicious or not.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > detnet mailing list
> > > detnet@ietf.org
> > > https://www.ietf.org/mailman/listinfo/detnet
> > 
> > 
> 
>