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

"Black, David" <David.Black@dell.com> Tue, 22 December 2020 17:19 UTC

Return-Path: <David.Black@dell.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 D82CD3A11A3; Tue, 22 Dec 2020 09:19:30 -0800 (PST)
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 (2048-bit key) header.d=dell.com header.b=AoLnAX0/; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=edh1ZB1Y
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 PVlHRQRdI8zR; Tue, 22 Dec 2020 09:19:29 -0800 (PST)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 E0BA63A11A2; Tue, 22 Dec 2020 09:19:28 -0800 (PST)
Received: from pps.filterd (m0170394.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BMHHnw4019007; Tue, 22 Dec 2020 12:19:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=e7HLgJYrgYIpIZc+/3sgzJbvEW6TZQf3lxXSVL1suGg=; b=AoLnAX0/5eK6jjqOKoKJymSOxOSH1ByhI5i+Vck44ipbZRbFvPi8DcXNSdW/QXffAe9E NnTUkEVag8jt+bIxpsgzgLDLQiDpwh/YWQg5Wb/8cEL52IKFg0Ks5R7vGSibS6wg8yec RGcrIkk2ucfD8OKQAaBtr+KMRprCWrhbVYraMWF0fDRm+dkGXlupcDB63Imowr4H3BNH /OgrBTAVOCdxC3J2nY0wRfLuF4csAerPyDWoPun1qwDh2NnRhQwEXCc/aNf7WwvoTjN3 8X5mCpkPErCMnot8gZLlGTDzZbgGNn9LEnoigdbXmhrl6gQiqy1lYUwMf/EB/r/Nym8T MQ==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 35k0eh3tx4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Dec 2020 12:19:19 -0500
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BMHG1vk160280; Tue, 22 Dec 2020 12:19:19 -0500
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47]) by mx0b-00154901.pphosted.com with ESMTP id 35kh5ukp7d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Dec 2020 12:19:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jD3lho6IQpDNN/5oJsv822DjkrVjj4tFi2+z2FT2xkhl03yJSD4QrumpZsOQ98sNvscWMeZvqiOaPZHJUnghVj4Pj/6J4OR5Tkkv11uJg4Iz5K6MCyKKtCLAIZ1mjyoCi8Ek64mbTVTFSdGNQAQHvijYR5SfxlePsQyIhHdSezN01zov+PDYfSDdSRePnJyO37cyC4p36S7a4WmdvVNwwLpB6RIr+wc4S7+IsIpaFBuT1JUUWDzm3BWOJqyCqZ8VgRFk+qNhcLYqj04Bw0o3+oqnwCsvFCGV9MtfkX6gBaB9RRlf/uVB3HnZbjOjNfwa3aXolgxkkJVisy/Y523U3A==
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=e7HLgJYrgYIpIZc+/3sgzJbvEW6TZQf3lxXSVL1suGg=; b=ThK9YSANKxm3CXcu2BrWuj5Yi3dncgrpYClZrs+CjvBbP2uvhazSK11bpNlLI/n6CZHbOFr3rpu8gRkb6Dia8TBnsf/xXjf8i5B0fdttbita6iUQzgStennGNzUZ3tSsHwdlZw9TrK5IJ1vpuUQUbjnEojml/lQVSiIGWQuIn2WPd3ewNsjf4fcp9F0f/ZNTPiO37dLraBcMHSWFkmX57pw4C9aBuKw9uOh9vM/NfhUlazviK10Guh1JgpAlsDoOAsL3C96Q4xLVjXMWRjBNGCCEAd8HnKpCf9rt/0tbA2SqGhrT9ShUG/gm56l2QM0xbz1Sx62GTmaOx4+Mn4h0wg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e7HLgJYrgYIpIZc+/3sgzJbvEW6TZQf3lxXSVL1suGg=; b=edh1ZB1YHwQws67j+3xxdjE7y0a6ok55tbVi0VEbZNnMKX/lRBGCp+/GXLYrDdrF5NXk7fw3iWohP3vRF+CCvy+dbSOKA49QECMDDgx29dGtowq5ylkAYnUBO8MEMV8fju1TGFp+GeFsJFJ42oKul9g1FF9lsZaMV89FqGblwS0=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3392.namprd19.prod.outlook.com (2603:10b6:208:154::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27; Tue, 22 Dec 2020 17:18:46 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::2853:5ccc:b023:dce4]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::2853:5ccc:b023:dce4%3]) with mapi id 15.20.3676.033; Tue, 22 Dec 2020 17:18:46 +0000
From: "Black, David" <David.Black@dell.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>
CC: "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-security@ietf.org" <draft-ietf-detnet-security@ietf.org>, "lberger@labn.net" <lberger@labn.net>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
Thread-Index: AQHW2Gx65CKEJ3jD60GmR28rIvWzq6oDWa1A
Date: Tue, 22 Dec 2020 17:18:46 +0000
Message-ID: <MN2PR19MB40456E5376B115C147B7E08C83DF0@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <160864632278.13800.15298127874258170906@ietfa.amsl.com>
In-Reply-To: <160864632278.13800.15298127874258170906@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-12-22T17:11:17.8791988Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=9464b3f4-208a-4b62-9ec5-320bf83b574b; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=dell.com;
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 06790f4d-3657-4761-6274-08d8a69da3e7
x-ms-traffictypediagnostic: MN2PR19MB3392:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB3392EBFFF60CCF457407EAB283DF0@MN2PR19MB3392.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Tff2aFQPNQaR1lYBGjkGH4cc/0P1sgOIIpM1vMaLnmwhlTlFUlPZ1Gweew56jzAWYYHmPh6/7nkyWxfj65tuFlgVb1LcivEzppWZqLwFAEL2rvL6vvPKfYGkilWbbkEMvSivv+X9KiEDFkZK6Rvm5mSjrHS4lfv6xyG08asWIFRBbqnhK5/FL3G9LwiMZIgm1CYuWlqaKLj4cdzEGk4MbQ7ZGt8yivlreFhHn2S9dqxsQg+IVjEsjYyYx+VGYgyE3b44vcV0qBE8YT1U8RoycYhjHMrwQG7ICE8S4KPYOwx4Z8NliteXLJUnWsEHsRxQlXgiF6vjO12O0amt/YUSoCAkNt+/SBpuYsr5ci/5o0BKJCFTuKcy26Elw6ebFwokUCVLBn4mg83nS4pawy/PVOBnO+QxxwgefRd5Dz1lg67pdsiWoTOGIW7/KmD5YbxJ5sHjUy9HDUjT+VJ9X6iVMg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(39860400002)(136003)(346002)(396003)(107886003)(8936002)(64756008)(66476007)(6506007)(66556008)(66946007)(53546011)(478600001)(2906002)(5660300002)(7696005)(26005)(33656002)(71200400001)(55016002)(9686003)(86362001)(8676002)(83380400001)(52536014)(54906003)(110136005)(15650500001)(76116006)(786003)(316002)(186003)(4326008)(66574015)(966005)(66446008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?SEIQ5mHuIp9Q/ZWberM33YnVcBo9qPf2DN3l3aMtPrGfP7bi+6e4ANW7rvt+?= =?us-ascii?Q?5cyNViVn8D6Sv3+DSFE7vku2O34OwgeLVDB0VkJZoKQWs28YM0059owWfzR2?= =?us-ascii?Q?FvLoguQmRo5CNEr10UPh2QhnmkJBWJXYxNqval2y/Us2gy6SJ3ROOIS8H1c5?= =?us-ascii?Q?w4LRSEl+Hi9yyO3STXGuZ2ysIPBFvh1YwhgtMu6NMPYoit+ZCe84L9RjYocK?= =?us-ascii?Q?2Eq+BU7xDwA5eFsrt+ViesaPWWkuGiqwI6y2O5LwLMcV2kpkFSbnGYmyLRAn?= =?us-ascii?Q?LjBvaQdGH3QJHSpujsw5OEAkae6Ttuf76xy3ut/7/0jlhnrAKLmDqQUk3rC6?= =?us-ascii?Q?cljQm1eudnSGRhMSY+GhUPnWjiuP09dh2HqRdlsxKOJRMa08CHqiRGZf2VuZ?= =?us-ascii?Q?LwXVgcEXF0fWrROztKtKBhTC3oRNQQ3o4L5nBdzOHERdmKCqVw74QoJL+t7I?= =?us-ascii?Q?UsoWiXmvvqleZx0bpJvUtXDCcVdrUK1sI5f4lNdDLiK8qEdYokJ8v0po4Yg0?= =?us-ascii?Q?m8fkuievyb3lcX5xzlPdZ6vESGSvmKwXiWDMiDqmyPdjuESztcBmn4o9CwKB?= =?us-ascii?Q?Ia6DrhRX9tpsZQDkWPFv1w0Df5Sn69IxAxUg+D5cfeHlo8On12cDdeY+5F2/?= =?us-ascii?Q?pNWicFCGkcJvdAPPy86vNftqfT41srQXVkeT1YfBuVWDoX9lHMQlYAiwi02O?= =?us-ascii?Q?4dCaB/OBz3hI4mqxmVDrUmQpsTzzlq6BXwQaF+bm9QwnqAr7NF0qTAMENe6o?= =?us-ascii?Q?QE/KjlaM00dgQOzQvpf7n2DZXYk3IkB9T5NW/uL0Q6Kk+s6ftLYwqOvXIRkE?= =?us-ascii?Q?ExwH4RKP24xYA2QWS3uKaFtHqHw0d1Bjvdp8X3uxSYTf+qf2mFxSaFy54YWA?= =?us-ascii?Q?LogJyduSqdaPE9Cuh2oyaVOV3AOScBT2r/JrF/moQxNK3vOgoRipPbwlHHYD?= =?us-ascii?Q?91jAMGoYbdVRfweDbpcBQhkd0ZacyBqKPHTBqkPB6ZU=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06790f4d-3657-4761-6274-08d8a69da3e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2020 17:18:46.1383 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: osEvcRK4FX/QqvRxrl8T9/7xUtIBixHC//aOUMxsO6I2MMoM5ZGWCCPipy9PPjfhSlC/UtDxQ8VgCbytOgoCBA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3392
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-22_09:2020-12-21, 2020-12-22 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxlogscore=999 spamscore=0 clxscore=1011 impostorscore=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012220128
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 spamscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012220128
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/91wUBynE0tMbxGeInLDKEzu_Nt4>
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 17:19:31 -0000

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