Re: [Detnet] DetNet Security draft update strategy for tomorrow's update (3rd try, plain text format)

"Black, David" <David.Black@dell.com> Fri, 10 January 2020 23:53 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 CA790120120; Fri, 10 Jan 2020 15:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=I2n7cL97; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=i6gsrhR5
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 g0bYXP-NRS30; Fri, 10 Jan 2020 15:53:38 -0800 (PST)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.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 64EE3120047; Fri, 10 Jan 2020 15:53:38 -0800 (PST)
Received: from pps.filterd (m0170393.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00ANo6bt008114; Fri, 10 Jan 2020 18:53:31 -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=UZ1SLyo/+lv5V66Zrstg+LeJl8awwzkThw0mmVlw0so=; b=I2n7cL97EY0mRdhpG7oBeogjF5KebeTlrkWnXnI0j8hahzmDC8zG/YPiowgPYcy7wTxj 2QRWc6GPmAO6f1tWNbJYgLI1huar6nXBcd6Cd4a3V4AuLPxaIUvhoaDjhXMCW3nPkFZZ 0apjuj7lLVddPRA2t5J6uqaUm/ugo/MtBWRgEG0YrLIqqbpLZn2XoJByZi5KYmX/P9Fd aDNMLreHrTeNn4NyTP2VS4x70Z1fwBcPA8F/Mf4RnIzZFDXXgJ2EQP7GWOCtPYvXR+z3 AgbQ8+tA/Ffh80oq/6BNfjVJopSRxdVgNDyA50Hg1vSnV/2HmKngGQUk00ucQjjn/WwM /g==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2xe3e4y7fj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 18:53:30 -0500
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00ANrKlh082726; Fri, 10 Jan 2020 18:53:29 -0500
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2105.outbound.protection.outlook.com [104.47.58.105]) by mx0b-00154901.pphosted.com with ESMTP id 2xen6ebwht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Jan 2020 18:53:29 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a+c5YEtRkPPXVAXL+rFdRNkCtWDzgsexhp0sHeHJFwxULjOxrIYhikCN1Udp8tt/eBV3Z/E/e+O4UrWXtp2Hn5LYVJSvpFWhhHIhtQ6HQqjoilVuEvLtJYuzq5OcJs6z3UgVYRTePjcEEYV5s3PhwIJhNF6g/HvkhoDSfSAZurFTBehL3uHIX01Iwr9JXUMZMgccgvX+wBq3qaSI5QTMZeBHrsdcwu0v4MeuH17lv/vHMZr1N18vyKd5YMXuB64i0bwWpLmlsY9AL60met7Ta9VlLvlFo6az7e2ChOrqRxThzPDpsDYwSZZ/UOSdjWA0BSKbXi6m1HCfHfZmHbifkQ==
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=UZ1SLyo/+lv5V66Zrstg+LeJl8awwzkThw0mmVlw0so=; b=C6v5sqzAikwxZZ7BSoVSsIyCgbZPL/ikCsLn+jLyazrTy0gSKyQ8xuXMcaryrSpIWwe9tmtCrsub4pVwtm7zej49BPDozOlkTDENni3/xDn/fs06BOF2Btg2hv8dZm05jdpQAUE2d3huhCJO+irMwpdb6lVmXlLPNFYpKivCjkKs7UYUlRJ5PPmpWqVGlL8QvzKQ/oV+dEEawDxz+8+/E++haCiZHT6O6Bffj81hEkPEyfIoK+KioBawaZMaKLPw3m0c9CfeYAQj1IJVlyx8XeLTJwONh9rkfpsFnQO4qo/lPCG8Yb2AadrEjifn9bK1uWiPxx2nfV6f7T8NZm1Ssw==
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=UZ1SLyo/+lv5V66Zrstg+LeJl8awwzkThw0mmVlw0so=; b=i6gsrhR5YwhbGDJ3J3M2V2L1138oBXgioEIPDEzjWB/YVYriYDn2iLbcUYOhNGa19M+6PBWOGLoy145rvDbvbsPkOOe6VsT9IYfYTHuGcbmdPaJ8FzJpp3glWDXXxfw8mX+fsOteTWpRJbphEdlV6PnlKZeVhywf4YZxTxOY00U=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3358.namprd19.prod.outlook.com (20.179.151.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 10 Jan 2020 23:53:25 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c%5]) with mapi id 15.20.2623.013; Fri, 10 Jan 2020 23:53:24 +0000
From: "Black, David" <David.Black@dell.com>
To: Henrik Austad <henrik@austad.us>, "Grossman, Ethan A." <eagros@dolby.com>
CC: "detnet@ietf.org" <detnet@ietf.org>, "Le Boudec Jean-Yves (jean-yves.leboudec@epfl.ch)" <jean-yves.leboudec@epfl.ch>, "draft-ietf-detnet-security@ietf.org" <draft-ietf-detnet-security@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [Detnet] DetNet Security draft update strategy for tomorrow's update (3rd try, plain text format)
Thread-Index: AdXHNO1mjQrxU2YcSKSlFP7aSwEkxwAYIpSAAB5o31A=
Date: Fri, 10 Jan 2020 23:53:24 +0000
Message-ID: <MN2PR19MB4045B65981BC8CA7EB5BDF4483380@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <BYAPR06MB4325A49BA29805B949F04F7DC4390@BYAPR06MB4325.namprd06.prod.outlook.com> <CAM6o_m1S7Qa1GuOWr81Y378H7iYkY7E_TPF2bJH0SrMS1mUxCQ@mail.gmail.com>
In-Reply-To: <CAM6o_m1S7Qa1GuOWr81Y378H7iYkY7E_TPF2bJH0SrMS1mUxCQ@mail.gmail.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-01-10T23:53:01.0368592Z; 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_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [168.159.213.208]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: abd1e272-b749-4beb-973c-08d79628481f
x-ms-traffictypediagnostic: MN2PR19MB3358:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB3358FD90D3E1EA9805DC358D83380@MN2PR19MB3358.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02788FF38E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(366004)(396003)(199004)(189003)(7502003)(478600001)(76116006)(30864003)(15650500001)(110136005)(8676002)(8936002)(2906002)(7696005)(81166006)(81156014)(54906003)(966005)(52536014)(6506007)(26005)(53546011)(64756008)(66446008)(66476007)(66556008)(4326008)(786003)(66946007)(316002)(71200400001)(86362001)(55016002)(9686003)(5660300002)(107886003)(33656002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3358; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nx0ve7E+HN8V2AdyJTyJmGImDt0kmHLFRUIoEdUW+Hx82LRsxZnBi3hxguwSqBgrfX+6pB+Y3XXYWe7PhhKOmgr0zNMaCTeBGkwzzT3UgOLXuV38tZp2s8WUsfBrUDrOPigFoY7jNb2fnJSeltDlBCRZFZ5zP48R94ronvL9NEN9obbczPrp61P18gKibPAIBloyMWL4ShRDveQdgP8m0QdfU7B/gLq6hlNflV16RaTZIslJRoVVgeanCD+XCUPCoEuoIZwVN/T/i7jrBTo6lqwAnDsq1RBPglu5w+pn0Rkjd8FeFlsmeANHhJrYVGrq74SXKqqO0IAkYF6QG4NIOweOAZ2YorcIUi8HviRh3bCjXlKabPHp+utjUVQGwT/ez43Rmwcg1kO4sQJUOHKp0+YTeayv4rOUODsGFqFL/4rp3Nw1UUPsXNu0MbaOSk/H6TCIeI2Px9UXgT/i6N0nMW1qylKPMlKOqFNROmSS0K5GVOOnHV2QitZ5l6fWg5JH7D311V4bMcbh21iLbVw6pWi0hMNWE6aXuhXlu4Kmy9Frqcocqf8pn33gqDIIsGkH
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: abd1e272-b749-4beb-973c-08d79628481f
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 23:53:24.5000 (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: vhpyIHXIblU5kmzgWIkjJ+FVC64tx5ZXwZr9HDJMFohHdGO0C3SAMM7eKewjhTf3PP7CUc9H3IOPwF/vb+1rFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3358
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-10_04:2020-01-10, 2020-01-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 impostorscore=0 suspectscore=0 phishscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001100197
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 bulkscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 priorityscore=1501 phishscore=0 malwarescore=0 mlxscore=0 adultscore=0 impostorscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001100196
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Og73i8ARRfUrqyawOKu2Lb_6G44>
Subject: Re: [Detnet] DetNet Security draft update strategy for tomorrow's update (3rd try, plain text format)
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, 10 Jan 2020 23:53:42 -0000

Hi Henrik,

Comments inline on some of your points/thoughts ...

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
David.Black@dell.com
----------------------------------------------------------------

> -----Original Message-----
> From: detnet <detnet-bounces@ietf.org> On Behalf Of Henrik Austad
> Sent: Friday, January 10, 2020 4:08 AM
> To: Grossman, Ethan A.
> Cc: detnet@ietf.org; Le Boudec Jean-Yves (jean-yves.leboudec@epfl.ch);
> draft-ietf-detnet-security@ietf.org; detnet-chairs@ietf.org
> Subject: Re: [Detnet] DetNet Security draft update strategy for tomorrow's
> update (3rd try, plain text format)
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi all,
> 
> Some points/thoughts on the summary of last confcall. I added a number
> to each point from Ethans mail (in an attempt) to appear more coherent.
> 
> tl;dr: I agree with the sentiment, but I'm not fully on board with
> stripping out as much as what I understood the proposal wanted.
> 
> Detailed comments below.
> 
> 1. "On recommendation for using IPSec for DetNet IP - problem: Can't see
>     enough of the flow to do flow differentiation; e.g. need 6tuple but is
>     always hidden in IPSec. Lou wrote that section, need to check with him."
> 
> I think I missed this discussion. AFAIK, the only parts where we discuss
> IPSec is potentional ways an end-user can protect the content of its
> stream. Is the concern here that IPSec will hide too much of the header
> for DetNet bridges to be able to properly prioritize them?  I must
> confess I am not familiar with exactly how the headers of IPSec is
> constructed.

[David>] And the IPsec headers is where the problems are to be found.   The DetNet IP data plane identifies flows via a 6-tuple that consists of two IP addresses, the transport protocol ID, two transport protocol port numbers and the DSCP in the IP header.   When IPsec is used, the transport header is encrypted and the next protocol ID is an IPsec protocol, usually ESP, and not a transport protocol  (e.g., neither TCP nor UDP nor ...), leaving only three components of the 6-tuple, the two IP addresses and the DSCP.  This assumes that DetNet nodes cannot decrypt IPsec traffic.
 
> 2. "We want to set the initial expectation that the DetNet network to be
>     secured is already a well-designed and well-managed network (other
>     possible phrasing: "a traffic-managed, controlled environment" or "a
>     traffic-engineered network") following existing best practices. We
>     assume that all such relevant characteristics are in place as a
>     starting place for this DetNet Security Considerations
>     draft/discussion. We can thus simplify our draft by setting this
>     assumption. Having the draft be shorter is a positive step.
> 
> If we assume that the network is already well designed and well managed,
> then what does this document really provide? I.e. if I were to set up a
> DetNet network, I would come to *this* document to see what is relevant
> security-wise. I understand that this document should try to not dictate
> specific steps, but painting a threat landscape with a broad brush is
> not something I think we should leave out.

[David>] Well-designed and well-managed is primarily about denial-of service prevention by ensuring that DetNet traffic goes where it's supposed to and that an external attacker can't inject traffic that disrupts DetNet's delivery timing assurance.  Security involves a *LOT* more ...
> 
> 3. "Regarding control plane - we can state that every Control Plane has
>     to be well managed and secured by industry standard practice - this
>     removes the need to say a lot of the specific things we say in the
>     draft."
> 
> But this does not make sense, industry standard practice, would this not
> vary depending on what type of network you are setting up? I am
> reluctant to cut out things just because we can hide behind "industry
> standard practice", *this* document is supposed to help guide what is
> industry best practice wrt to DetNet.

[David>] Actually it does, see RFC 7510 (MPLS/UDP) and the TMCE (Traffic Managed Controlled Environment) scenario in RFC 8086 (GRE/UDP) for a couple of worked examples of this sort of approach.  RFC 8086 is also a good place to understand what differs between a scenario that makes this sort of assumption and a scenario that does not.

> 4. "We want to the initial expectation that the reader will be familiar
>     with the DetNet Use Cases draft, because that is where the
>     "expectations" (not saying "requirements") regarding security are
>     stated, since there is no DetNet Security Requirements
>     ("Expectations") draft. (As a result, our intention is to remove Sec
>     8. Appendix A: DetNet Draft Security-Related Statements from the
>     draft - any objections to that?) In review if someone says something
>     about lack of specific security "requirements" to review the draft
>     against, we can point to the Use Cases drafts. (This is normal in
>     IETF specs - each RFC is a chapter in the book, assumed reader will
>     read all of chapters. Contrast with other organization
>     specifications which are more self-contained)."
> 
> I agree that we should expect a reader to be familiar with RFC 8578
> Determinic Networking Use Cases.
> 
> *However*, in the Abstract of detnet-security we state that
>  determinsitic networks have been running "real-time operational
>  technology (OT) applications", and as of now, the only part of
>  detnet-security where we actually raise the concern for the impact a
>  disrupted DetNet service will have for RT-apps, is in appendix
>  A. Before dropping this, I would like to go through sec. 4 and see if
>  we stress this point enough.
> 
> 5. "An MPLS network is inherently more secure than an IP network,
>     because with MPLS it is difficult to introduce a rogue LSR or PE
>     into the network, compared with IP, in which a random device is less
>     difficult to introduce onto the network (and from there send packets
>     into the network). An MPLS network is highly managed by its
>     provider, e.g. BT, ATT, etc. Nothing gets in there."
> 
> Not very familiar with MPLS, but I assume this comment is aimed at Sec
> 7.2 "MPLS"?
> 
> 6. "In contrast to a PW model for MPLS, an IP model can be thought of as
>     an overlay model, so the goal is to protect the overlay forwarding
>     resources. To do that, we need to manage the network as tightly as
>     an MPLS network, equivalent to MPLS-TE. Need to have that as a
>     starting point - should be "this is a mega tight network, nothing
>     gets in that we don't allow in".
> 
> Yes, agree. But does this not conflict with the desire to leave more out
> from #2 (industry standard practice)? Or did I misunderstand the
> intention behind the cleanup in #2?

[David>]  This may be somewhat overstated, as many IP networks are not managed exactly as tightly as an MPLS network, but also see my comment on #2 above.
 
> 7. "Another way to phrase this is like "with a standard IT network, we
>     manage it at least as well as a VPN". We have a lot of experience
>     with VPNs running through networks with other VPNs, we know how to
>     do that. Perhaps this could be pointed out somewhere near the text
>     that says that legacy OT networks are "isolated" (meaning "air
>     gapped") (from e.g. the IT network) and are thus less susceptible to
>     attack.  Assume VPN characteristics, but note that any "bumping
>     into" (interference) of one packet with another can have an effect.
> 
> What part of the document does this apply to? Not sure if I fully grok
> this section.

[David>] VPN seems to be a better way to think about this than matching MPLS, and again, see my comment on #2 above.

> 8. "Network slicing - could this be used for DetNet? Or is it that
>     DetNet could be used to implement slicing? This is a meta-problem at
>     architecture level; Perhaps the world has changed since Arch doc was
>     written. Lots of people working on slicing now, e.g. for
>     3GPP. Perhaps Lou's work in TEAS on TE'd VPN is relevant? Two
>     strategies for this: Classical MPLS model vs SR model.. Issue of
>     stealing resources - we could describe this as an issue, or maybe
>     could even refer to slice drafts, but we don't want to be held up by
>     those drafts. Point is that others are thinking about this.
> 
> If a bridge allows an actor to inject so much traffic that it
> affects DetNet flows, it is an issue, so a bridge must adequately handle
> flooding. This also goes for control-traffic, the network must be
> configured to handle sudden floods without loosing DetNet flows *or*
> control frames as that is a pretty likely attack scenario.
> 
> 9. "Draft needs to set out principles, good quality abstract models,
>     rather than details; currently the draft has too many details. Not
>     enough focus on delay and packet loss considerations, which are the
>     core. Current draft focus is explicit on "now" technologies, as
>     opposed to setting considerations for any technology. Need to
>     establish what they need to do to conform to security
>     considerations. Current draft is drilled down into classical
>     existing world, perhaps not the world we will find in the
>     future. Need to review what we can assume is known, and what we have
>     to do to encompass various technologies.
> 
> Yes, I agree to this. I think we discussed this way back, we had a
> pretty lengthy discussion about likely threat vectors to a DetNet setup,
> some of them are a bit heavy on the details in an effort to explain the
> gist of them.
> 
> 10. "Section 3 - seems like a basic tutorial on security threats? Is
>      that level of tutorial needed, given the expectations set above?
>      For example Internal vs external, access to segments, all standard
>      in secured traffic engineered MPLS networks. Can assume that is
>      taken care of. But delaying a packet is more significant, can be
>      very subtle, need to focus more on that.
> 
> I'd like to keep a point about the significance of a successful
> injection attack. For an IT network, a replay-attack can do bad things
> to your RDBS, for DetNet you could harm physical things, physically
> harming humans.
> 
> I agree that we could focus more on delay-attacks, but we *should* keep
> some points about the other attacks simply to ensure that they are
> taken into consideration.
> 
> 11. "Regarding DetNet to transfer clocking - could be beneficial to
>      clock distribution, however if using PREOF then it could be
>      detrimental to clock sync and ranging. Need to teach people that
>      there are limitations - is this the place for that? We are clear
>      that we are not addressing how time is to be distributed in a
>      DetNet network, but maybe a caveat is in order? Clock xfer is
>      subtle, few understand it.
> 
> Perhaps this could be used as an example for why delay-attacks can be
> detrimental, help elaborate in #10? Apart from that, the finer details
> of clock distribution is best done elsewhere. I was not under the
> impression that we discussed clock distribution much though.
> 
> 12. "Not discussing what a data plane needs to do or how it would do it,
>      but describe properties it needs to have in order to conform to
>      security properties or expectations or needs. That is, we need to
>      state expectations of DP, how it would meet requirements, but if it
>      can't, how it would mitigate them. For example, consider a
>      requirement for "IT traffic must not affect DetNet traffic". So a
>      possible implementation, as one would do in a non-time-sensitive
>      network is to put them in their own VPNs or MPLS tunnels to ensure
>      they run independently. However DetNet special since packets
>      "bumping into" other packets can be a problem.  We need to say that
>      they have to provide this isolation, but not how to provide it. So
>      we can say something like "forwarding bandwidth (and related
>      resources) must be protected so that they are available to detnet
>      traffic". How they do it is up to the dataplane
>      designers. Otherwise we end up committing to solve an infinite
>      number of problems, and possibly limit options of designers to
>      innovate or otherwise solve problems.
> 
> Yes, we've discussed this and I was under the impression that that is
> what we were aiming at.
> 
> I read this as a summary of all the above points and infer that we need
> to clean up and strip down a bit in order to meet this goal. Was that
> the intention of #12, or did I read that wrong?
> 
> --
> Best regards,
> Henrik Austad
> 
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet