[Detnet] DetNet Security draft update strategy for tomorrow's update (2nd try)

"Grossman, Ethan A." <eagros@dolby.com> Thu, 09 January 2020 21:34 UTC

Return-Path: <eagros@dolby.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBBB12081C; Thu, 9 Jan 2020 13:34:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV2hB43t2_1u; Thu, 9 Jan 2020 13:34:46 -0800 (PST)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2138.outbound.protection.outlook.com [40.107.236.138]) (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 5F5C612080F; Thu, 9 Jan 2020 13:34:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xio6xZp81hWxEBXv2TYKv26v1mbiPjXsbsHyE70WQS7XRvCJYfZEmpmUd4QtRF6Cfp1hJNP1YMp1HSiw/IxMb2NZujUqth5hFFoYBi6wNclDJmRavuq5toCcG6Nv4ddybAQw/72az0hZ+zEkgI71rxXxUAS0wIEYijplPmSflG+jc6TI3lIN9EV4E1UuB+BvL7CK8atJRsOe+DKILQQjpX70H+I2SJlquTbwKDLEt38ViD7AeBlC8V2h50TXxUkvt5jZGoAGyGMMp2bY/5gem3YzizM/RVFYKYoLvhE34yr2Teqs63zR4NNmHw+24i5wWOlbElPbWCBvnL95zhuNJg==
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=obrqN9HANQUJg0Gf0mvfU+1o00TptmBhS/O8jzmxvx8=; b=FjRUI/t+0b75lThdhPZa1AG+U+nbrLjqARKUS2amHmtzojfHTTs91GiGXm55rOf75p7asK5PVG0GSPkX0XzMgZYfiokfX+MRDqo+8N5cYBEnbgTxiG+zYR3kZkTijKkz4+JpAzhyh1kYINDlufu2LTuZPXpKCeaDr7Ix5RfIpizx04bg65OdPIiQJK4l3B0KdYN3BTRmE4BLCLtd8dMnCd3NerRyIWUJNEr9lZwVVBpzQgxDoJtvXZD5aSsZqqHg018RuL5qtQkzpG3jODKBESkS4EybEQd+vs0/2Zh5C020CrKuwTCBIeiUN2MXbLncvkhkUq5PxI2Qf2goDPTq2Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dolby.com; dmarc=pass action=none header.from=dolby.com; dkim=pass header.d=dolby.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=obrqN9HANQUJg0Gf0mvfU+1o00TptmBhS/O8jzmxvx8=; b=YnF8PrKgATIDwMN9Em0LbnExn0xD8B3wXCsvLRoX+NgaFuJUztfsuJaABCdpvafD+/FQNH55DtggBgZCh7Qj+komOUEgQK3afdzhkxx3jNHXmGar5gVmVQOOu8MzcocEpMvdd/+Us0omYQPu9h59ImTXnyERXY3rpRHrlxMxAys=
Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB5094.namprd06.prod.outlook.com (20.177.185.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 21:34:43 +0000
Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::d4d3:b053:f4cd:48ce]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::d4d3:b053:f4cd:48ce%7]) with mapi id 15.20.2602.016; Thu, 9 Jan 2020 21:34:43 +0000
From: "Grossman, Ethan A." <eagros@dolby.com>
To: "detnet@ietf.org" <detnet@ietf.org>, "'detnet-chairs@ietf.org'" <detnet-chairs@ietf.org>
CC: "Le Boudec Jean-Yves (jean-yves.leboudec@epfl.ch)" <jean-yves.leboudec@epfl.ch>
Thread-Topic: DetNet Security draft update strategy for tomorrow's update (2nd try)
Thread-Index: AdXHNJpd/Ksm+N0xTFKa4T0s6S0n+w==
Date: Thu, 09 Jan 2020 21:34:42 +0000
Message-ID: <BYAPR06MB4325E43D7C99129E3E301B4DC4390@BYAPR06MB4325.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWQ4MDhhMzZjLTMzMjctMTFlYS1iOTEzLTg0ZmRkMTNjZDRjZlxhbWUtdGVzdFxkODA4YTM2ZS0zMzI3LTExZWEtYjkxMy04NGZkZDEzY2Q0Y2Zib2R5Lmh0bWwiIHN6PSIyMjU0NyIgdD0iMTMyMjMwNzkyODIwMDAxMzI1IiBoPSIzSmhyQkx4TXcrckVvOG5xazBXSi9NbzJiSzg9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+
x-dg-rorf:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com;
x-originating-ip: [8.39.141.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 04d94045-6c28-4eba-d9d1-08d7954bbd89
x-ms-traffictypediagnostic: BYAPR06MB5094:
x-microsoft-antispam-prvs: <BYAPR06MB5094537B2B1207A4942A5F55C4390@BYAPR06MB5094.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02778BF158
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(346002)(39860400002)(396003)(199004)(189003)(53754006)(15650500001)(71200400001)(4326008)(5660300002)(7696005)(478600001)(110136005)(2906002)(26005)(53546011)(6506007)(33656002)(52536014)(86362001)(55016002)(9686003)(81156014)(66946007)(76116006)(66556008)(64756008)(186003)(66476007)(66446008)(81166006)(8676002)(316002)(8936002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB5094; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LUOMJCzlZcT9GtPdsbR4SsRFyu4B27fIOqqACbp76jYwS+XvwlduSDrk/HtuF546DLXmQf87P2Rm3unnggUpYTyp/s+lOjtsC3C2w8DN3iGzX9v9GNERYIntTou26ldY8e+8V9p9w3WQwNa6MCHVc+YBy8oBRCy2r92ooy4Wnf1PW10vgztdUvRwyQoWeY3pdwMU2a/SrN+Clg9f0+/rDDXDQbOFB8W2vHizX6TQvK89p6ceHI67p1ih4WpieRcKdNO/Lw18obwsDr5FT9qC/1c4IRLgzYDDXUZ6MfZ89iQ709yhrlmQdLEd3Edi5MZ804Nlds6/6+lpQHDjyUL8LuQNz886nckr/TSm3CWvF++t52WD4x/czBariN/GH3PNngNji7IejIMB7zBCVgi5psZDtHkVcT8ABwZKN35jHelPMqPfKDY9/XmLL/YuYI2dDfQqoYLwEZhXBitW3SmdjnPknn6kAqehUGXQVr99gNJBICBqLcWgDOM0Mx2EeDmE
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4325E43D7C99129E3E301B4DC4390BYAPR06MB4325namp_"
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 04d94045-6c28-4eba-d9d1-08d7954bbd89
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 21:34:43.0158 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0lVrO/1fQPoIyRSAz/37Tbeh9sSpY5+VPbeGsRdxQ4cae4DN60C2JFJCEU+TYpWqAo6OH9SZ68Tq5LNm7dhh4g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB5094
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/OqGQyHC79z5Um2584EBSSse_1f0>
Subject: [Detnet] DetNet Security draft update strategy for tomorrow's update (2nd try)
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: Thu, 09 Jan 2020 21:34:50 -0000

Hi All (and calling out Lou specifically below),
I will have some time tomorrow to update the Security draft, but so far I am lacking any input from the WG regarding the notes from our last meet-up call (at bottom). So if you have any comments, now would be a good time to voice them.
The plan for the Security draft (as of IETF 106, i.e. modulo the results of the meeting below) was to make the very minor changes we knew of (limiting scope to MPLS and IP) and then do WG LC and simultaneously start a SecDir review. At this point I am inclined to make a few additional changes (specified below, based on some of the meeting notes) but not do any major surgery such as "removing tutorial material" (as suggested at that call); at this point, lacking other WG input, I would rather leave that in there and see if the SecDir reviewer likes it or not; I feel that the draft as written reflects various individual authors' contributions, and I don't want to toss any out wholesale unless there is a clear mandate to do so.
There is one question I would like to see answered today if possible:

  *   Is the suggestion of use of IPSec valid (or do we need to explain specific constraints) given the need for flow ID based on 6-tuple. Can anyone comment further on that, e.g. Lou?
Apart from that (if I get an answer) here is what I plan to change for this revision:

  *   Limit scope to IP and MPLS. (i.e. cut TSN and references to future data planes).
  *   Pull out the appendix with the "security statements from use case draft" and replace it with a statement that the reader is assumed to be familiar with the Use Cases draft (as suggested below).
  *   Incorporate comment from IETF 106 that flow ID and OAM are relevant significant differentiators between MPLS and IP data planes.
  *   Note that for our purpose MPLS is inherently more secure than IP since it is internal to routers and it is well-known how to protect it from outside influence.
  *   Add statements to the effect that we assume a "very well managed network (both data plane and control plane)" as a starting place for this draft.
We have another DetNet Security meet-up call scheduled for Tues Jan 21 at 10am PST. That would be within a 2-week WG LC period, if I were to start WG LC tomorrow, and also request the SecDir early review. At this point I am inclined to go that way. Any other (timely) input is welcome...
Thanks,
Ethan (as Editor of DetNet Security Draft)

From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On Behalf Of Grossman, Ethan A.
Sent: Wednesday, December 18, 2019 3:12 PM
To: detnet@ietf.org<mailto:detnet@ietf.org>; Le Boudec Jean-Yves (jean-yves.leboudec@epfl.ch<mailto:jean-yves.leboudec@epfl.ch>) <jean-yves.leboudec@epfl.ch<mailto:jean-yves.leboudec@epfl.ch>>
Subject: [Detnet] DetNet Security Considerations 17Dec19 call notes

Hi All,
Here are my notes on the DetNet Security call we had last week (attendees: Stewart Bryant, David Black and me). Thus far I have not made any changes to the draft, because the implications of the discussions below, if implemented, could result in a significant revision of the draft, and I would like to hear what y'all think about the proposed direction. So please put in your $0..02.
Jean-Yves, if you're out there, I would be particularly interested in your input since I know you have experience with observing non-DetNet-WG peoples' reactions to the draft in its current form.
Reminder that we have scheduled another call for Tuesday Jan 21, 2020, 10am.
Thanks,
Ethan (as DetNet Security Draft editor)
-----------------------------------------------------------------------

  *   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.
  *   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.
  *   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.
  *   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).
  *   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.
  *   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".
  *   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.
  *   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.
  *   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.
  *   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.
  *   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.
  *   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.
-----------------------------------------------------------------------