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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 22 December 2020 14:13 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 564653A10CB; Tue, 22 Dec 2020 06:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 vWg9Jw-KmoiO; Tue, 22 Dec 2020 06:13:21 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80041.outbound.protection.outlook.com [40.107.8.41]) (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 08B013A10C6; Tue, 22 Dec 2020 06:13:20 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G2XUIjBzOmbez7ODZGDuW5cjpyYZR4Mqdbwzi8OIfqxEDMJnB8WItnrMV5fTHSssaGQ8axpzRBmF4j6bQN7EaKb8cqw5ZVTJ/4ix4Y/fQ+8NcB+S7AsseSVaNpH6oUOlKhze354cLpQwuBljtqWk4BTZvdXXCXojwGJaIKWL4R9VSwcG3wtQOhB8JIi+9fqHhKgwJ7RRLPhmDGyOJ3E8vVIPDgtCJpMkYdjDHalm68h2k3OZf7NkhX1gkQwzsmt6oIEHO6Ea8KF8dZKfzQJahpVr0vIZXT/DxFY8bN0RP6zR0YFuLGu82GA69+zJbXR/8aaULpR230a0R+XXE8g4LQ==
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=2UmpoL21Pn/pMONtf4kfIUQrWqtO78GrMFj0IO4cEF0=; b=NVJnsSa7JnHzqNK7ggctt4c8v3DSn5TMAUMKIeBnmKpjt7EWGJb+fE7l1Lq5B80gAcI/2Hlw0bWkw39tvJ+scxlcat3Y/aQiDr2U7J/73EbWv5aABh3+mVrm0sJ4teelmk1AynNfOU5ivY5+dFPdRm/Z64sTxbNN1syW/H5Rwq66ZteJyiax0tX9qoTYbik4Y14NNgj3EBFzyRPnU23vntB42nPTG0IMuyDNbtI7FdjBibsskY4RVR3oq3+/KG+mZtsQBPAhS9E4O1oZ1EyR0r7wRyunCaA5GSp/LavYY8C/NV9EkXydPCAUYmbyR5XGQzSx/5YBDgalMD2P+EV2+g==
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=2UmpoL21Pn/pMONtf4kfIUQrWqtO78GrMFj0IO4cEF0=; b=Wr4VdxKUSrEb9fYedrjdOt4JDeKzAVu7kf/rgDBnzyDTrPh6Ip3hyAMePrKNjqLkiaRLa/C71ItD0ej4PsPJLou/V/oFqqzWAankGvFdJe+XK6Qxg3hKMFSH6PZ8oAfIXn5gPZaVP3CbTVLjASOzeyMDA+27714AUXFgBySRBfg=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2347.eurprd07.prod.outlook.com (2603:10a6:3:6f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.24; Tue, 22 Dec 2020 14:13:18 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%6]) with mapi id 15.20.3700.026; Tue, 22 Dec 2020 14:13:18 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>
CC: "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-security@ietf.org" <draft-ietf-detnet-security@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, "lberger@labn.net" <lberger@labn.net>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
Thread-Index: AQHW2Gx8UD3yjueSTECZOXuaCTpEiqoDKFUA
Date: Tue, 22 Dec 2020 14:13:17 +0000
Message-ID: <07ce41ccae465631fc8519187315368ceb6a30e7.camel@ericsson.com>
References: <160864632278.13800.15298127874258170906@ietfa.amsl.com>
In-Reply-To: <160864632278.13800.15298127874258170906@ietfa.amsl.com>
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: ietf.org; dkim=none (message not signed) header.d=none;ietf.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: e55748a2-d397-4976-acad-08d8a683baef
x-ms-traffictypediagnostic: HE1PR0701MB2347:
x-microsoft-antispam-prvs: <HE1PR0701MB2347B78E2E5FE00C595DB9F195DF0@HE1PR0701MB2347.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WBx3KmsS0RR7DKo5AY3ul62VcH/4FkgjKUXJyqCXSHoGq/7oNSPDIjlbLPNeNV/W56pUhkVmIRhwRKFAR4QpN04xgR5716806qU617cWuy5a5oPxLfGgnxUrETLxnm/0HwXPNeaQ61Z3AvjYLkcVPtT6R/qp5pji+lg+v5HXZlBktUbXJQwzDVu6lWLl+SJVJk3oI9vuBJ/ZM1XkDZu8V6lATgZD3y3SGfeF1HG4+YdABMR6LWZBgmB/OiZDZJ1WUUZyWuvNCYUQyBgc2iusVfkh4OPyK4y+13w/S3WxB0DE9L6FX8K1oUE4JTHamiiBM2RmgfphzVl9dF+7AK0e+dL9fzdNWPlDDy+iiZPUs8+kF4qPsk08v3+xYs0CMRL6lBGFwryeL86Y3DHaFLR6CFHgaIa9p4anOrqZqD73CATAmj87U40OPPkd1jvRUOtD74q07EYl7KEZgrYreQOKEo2x+fiu5rASrJwdyemBQNGhCLp05CN18i4Nnb1lKwmWXgXc8laapccngPhG0mHE9Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(39860400002)(346002)(396003)(366004)(26005)(76116006)(36756003)(66946007)(15650500001)(66616009)(186003)(83380400001)(66574015)(966005)(66476007)(44832011)(6512007)(66446008)(8676002)(2616005)(64756008)(6916009)(54906003)(6486002)(66556008)(5660300002)(71200400001)(478600001)(316002)(99936003)(2906002)(4001150100001)(6506007)(4326008)(86362001)(8936002)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Mkc4OHlnZ1ZwS3FGNTFlY1k1Rm5IN1JNcGRBZkR0US9qN2MrSGVrTitRdC90?= =?utf-8?B?amlvWmZmMnVFd0dvc0ZoSTQ0QzJOd0xPZnNmb2dBT1R1SzN3RnVnbU9NSkNu?= =?utf-8?B?c1R1ZnBvUGRQYWFKQVpqdGg2VXdBMGNhMUFGT29RR3RLRGp6c01ob3doamJZ?= =?utf-8?B?ekw0WTFBRG5vZ1AvY0RsenNDY0xWanB0SmNsYm1PZ2hhN3pDaGcwQXJaWVNQ?= =?utf-8?B?ZUxEYVppVE9xRE1YZElWeVZPVUMvYVlyd3NlM2VyTXplMEtEWTBxUlNpMGtn?= =?utf-8?B?N3hjdGYyVC9Pa2RMOWtFWkFmOG1wQnFveUdNQk9HMnh4RjlNR3g5TVU1U000?= =?utf-8?B?SzM1aW9MT1Z6ZW1xaWVKWUhmUmdIbldCdWxuQk1Lelo0UEpPdERjSFZ6TENB?= =?utf-8?B?ZGNhd2NKR3RlUXZRb1YwTDNZR2ZrTE5mSTd2TzdUdnBLV29rbUN3QzZ1bzNk?= =?utf-8?B?UVpPRlAyWW9QSlpYYUNmNmlLbHVObXlNWG5VVFBoazduWlg0bG9Lc0ZUZGZo?= =?utf-8?B?WDhuNytrM0lXQkxQYXJ5a0N1d0ZHVWlETVZKaytyMlQzZUt3aDBhaittTHdw?= =?utf-8?B?bzZ4elBLZVFpRHBNa3Y4K3ZBZ2ZnZEFLVklwc1VZSnJPUksvWjFPVGEzanBu?= =?utf-8?B?VDI1WHZqbFpPVXV5cndrUXAvNDZWZkZwTHIzcmJmbTJBbWVaWkFvQXdhSVNt?= =?utf-8?B?cDdsYnF2ajE1bTE2UFF4czFYOUJrTkwvTmVJZ1ZqLzZDb0lOOHo2N0xiTXJs?= =?utf-8?B?RktZTHY5M3doUkpsSkZFMFFhd1ZDMWpZUGdGK3EvbHpCTEp0NXBtTUNKcEkx?= =?utf-8?B?THc3RWFBMDczYzlHNGY5YnNnUkNrNWkzT3I3SGQwOGpXU1FVelQvZG9ZWmtD?= =?utf-8?B?U0tXYk1ybE9ZRUJtTEljV2hXZ2UwZ3RQdzg0WVFDVTYyMWVqZEhrbWVPenRV?= =?utf-8?B?UnZITk1RTEwrZG9KYm53K3g4b2NwVWloYjVXaS83VUt0UkMxcUt3T3Mzai9q?= =?utf-8?B?S3VJNkFiYjVyK1ZnR2owM0srV2tlOTFUcFQ3VXJHM2htZldIWFAwOUM2NVk3?= =?utf-8?B?TnkxNE9UbnFSb2xBaTdCcUJSNUVGMERoQUo5Y2xMUDlOYXNkaTIzNE5PTkw3?= =?utf-8?B?QVFqOWFmYW11M0djRzk2MklXTFJaVEE0K3cxckJ6WGY0aThzcEZaTm9naUFs?= =?utf-8?B?Y3J3RjB2Q0RyWGdwZEpIb3lScHdHRXNNbFNGQy9uQ21NcFEwMFRoUDQ2NklN?= =?utf-8?B?TW9XODdrSTdGWjZGWkZrUEpCVW1HSkxISW5IUFkyRytEclBMTzRuRTA4blI3?= =?utf-8?Q?Nqq8PzHKAlGGzI4RJnfELOT6n2+pi7U0KY?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-1zYrCvkyuOJsoeQWZr6h"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e55748a2-d397-4976-acad-08d8a683baef
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2020 14:13:17.9041 (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: jg3qAksY2FudYTfedy4D8dJatQji9cmfYj2zJZqFhPnHAOX4k0LFIfLO48Z34scfONsCCKJFdPq625RzxeyKGyVSLEw5DszRAsHJWzmgwTA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2347
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/LnJ7wJ5J1o1SVq15GO2nI4vt6hQ>
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: Tue, 22 Dec 2020 14:13:24 -0000

For your information,

I will have christmas vacation from now until the 7th of Jan so don't expect any
rapid response. 

Cheers

Magnus

On Tue, 2020-12-22 at 06:12 -0800, Magnus Westerlund via Datatracker wrote:
> 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.
> 
> 
>