Re: [Detnet] Barry Leiba's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

Ethan Grossman <> Thu, 28 January 2021 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACE9D3A0A1E for <>; Thu, 28 Jan 2021 13:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Status: No, score=-2.338 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cGg7FIeMKv_p for <>; Thu, 28 Jan 2021 13:48:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBB803A0C59 for <>; Thu, 28 Jan 2021 13:48:07 -0800 (PST)
Received: by with SMTP id md11so4658298pjb.0 for <>; Thu, 28 Jan 2021 13:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=reply-to:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=yu7htK/cXnpJoZsPaekx1GPTjUK3ORs9pU7HM46Qk+Q=; b=TlAo2KiwijhBbDkdF6TURB3vMWn4bfm33aGMum7cHirjsXJ+4KoBIIWwFZzXVdzh7N UH2dx7q1Nr3+4uP+34Bnjvurt6n8wRH3acNZHwIyfdXW95WKqsQ6/z9fbtLQXz0nq2ei lf9WPs2BVI6mI1/VrIM7VZZWFY/yfWqvZUCVo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=yu7htK/cXnpJoZsPaekx1GPTjUK3ORs9pU7HM46Qk+Q=; b=kMpZ3w+UPiLuDLJ7Z/4misfY8k3lDbWmefuxL3hNynNDSaEr7QatoNfary0yRCF70V S/5Q4UcwpH9XvvbxTwoGa17fjAAXxDD/bp3S+TD2CVN49QifeTfBS1eLUecWkIUST56o 5fPL1avEjl/3IT/+rb0VBBDSvOpGdMRy+8A4Cqlo/t8XgVjDcV89ylurSx/GRDvd9FXB TkyMj/sweztnIS0Sl54mbKzViyGTe2jRq5uI5SVedolKlWJ61DN1IqxuvK9PjxnBXtF3 M5sAFsUUY846Jxc4SCGrw2ox+Pj6mkGbqUDtQA/rrLEGXzmElsPIiCZqOYJj3iCXcx/1 boaQ==
X-Gm-Message-State: AOAM532hM4oD5YiQdtsyYUYJOw8MkgB/PkThgadkefecVX8SHcxyYe6q wY2m0xAelWCOmhw70GhOGuUPpg==
X-Google-Smtp-Source: ABdhPJyi6/yabi6RkZog/3G/1LmCjzt3hUmOwMYM5jq+9a4TaVulFAK7JQueykPD45GCwBcdDugsYQ==
X-Received: by 2002:a17:90a:8d84:: with SMTP id d4mr1374444pjo.56.1611870486950; Thu, 28 Jan 2021 13:48:06 -0800 (PST)
Received: from DESKTOPC435DDQ ( []) by with ESMTPSA id y67sm6491673pfb.211.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jan 2021 13:48:06 -0800 (PST)
Reply-To: <>
From: "Ethan Grossman" <>
To: "'Barry Leiba'" <>, "'The IESG'" <>
Cc: <>, <>, <>, "'Lou Berger'" <>
References: <>
In-Reply-To: <>
Date: Thu, 28 Jan 2021 13:48:03 -0800
Organization: Coast Computer Design
Message-ID: <011f01d6f5bf$4202d990$c6088cb0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQBvmrOpHmHHFyESQyQ4iHkESEObCa0MSKwg
Content-Language: en-us
Archived-At: <>
Subject: Re: [Detnet] Barry Leiba's No Objection on draft-ietf-detnet-security-13: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Jan 2021 21:48:13 -0000

Hi Barry, 
Thanks for your review comments. Below inline (marked EAG) are our dispositions for them. We expect to publish a new version of the draft within a week or so, which will include these changes as well as those addressing the other AD review comments. If you have any further thoughts on these dispositions, or on this draft, please don't hesitate to let us know. 
Ethan (as Editor, DetNet Security Considerations draft)

-----Original Message-----
From: Barry Leiba via Datatracker <> 
Sent: Monday, January 4, 2021 12:57 PM
To: The IESG <>
Cc:;;; Lou Berger <>;
Subject: Barry Leiba's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

	It's interesting to collect security considerations into one document.  
	We have to be careful that in doing so, we don't fall into the trap of not thinking enough about security 
	considerations specific to later documents, once this one is published and immutable.  Let's please watch for that.

EAG: Understood, thanks. 

	I'm also interested to see the discussion of Magnus's DISCUSS points.

EAG: OK I will send out the disposition notes to the DetNet list, and to you and the other AD reviewers. 

	And just a few editorial comments about the Introduction:
   	  A DetNet is one that can carry data flows for real-time applications
	  with extremely low data loss rates and bounded latency.

	I would spell it out first” “A Deterministic Network (DetNet) is one…”

   potentially bringing the OT
   network into contact with Information Technology (IT) traffic and
   security threats that lie outside of a tightly controlled and bounded
   area (such as the internals of an aircraft).

	It’s not clear from the sentence structure what “the internals of an aircraft”
	is meant to be an example of.  Is it an example of a tightly controlled and bounded area (as it seems it would be)?  
	Or is it outside that?  And if it’s not outside that, what’s the point of using it as an example?  
	Are you meaning to say that we have to deal with threats from outside that affect things inside the tight boundaries?
	Maybe it’s best to try to reword this?

EAG: OK, a lot of discussion has already ensued around this introduction text, but I'll risk giving it a refresh (this revision also addresses a comment from Robert Wilton (that we should remind the reader that DetNet is not TSN)). 

      <t>A deterministic IP network (IETF DetNet, <xref target="RFC8655"/>) can carry data flows for
        real-time applications with extremely low data loss rates and bounded latency. The bounds on
        latency defined by DetNet (as described in <xref
          target="I-D.ietf-detnet-flow-information-model"/>) include both worst case latency
        (Maximum Latency, Section 5.9.2) and worst case jitter (Maximum Latency Variation, Section
        5.9.3). Data flows with deterministic properties are well-established for Ethernet networks
        (see TSN, <xref target="IEEE802.1BA"/>); DetNet brings these capabilities to the IP
      <t>Deterministic networks have been successfully deployed in real-time Operational Technology
        (OT) applications for some years, however such networks are typically isolated from external
        access, and thus the security threat from external attackers is low. An example of such an
        isolated network is a network deployed within an aircraft, which is "air gapped" from the
        outside world. DetNet specifies a set of technologies that enable creation of deterministic
        flows on IP-based networks of potentially wide area (on the scale of a corporate network),
        potentially merging OT traffic with best-effort (Information Technology, IT) traffic, and
        placing OT network components into contact with IT network components, thereby exposing the
        OT traffic and components to security threats that were not present in an isolated OT
        network. </t>

	   following industry best practices for security at both the data plane  and controller plane;
	This should be “control plane”, shouldn't it?  Also in other places in the document.

EAG: Actually in the DetNet Architecture ( ) we have defined the term “Controller Plane” as follows: 
4.4.2.  The Controller Plane
   The Controller Plane corresponds to the aggregation of the Control
   and Management Planes in [RFC7426], though Common Control and
   Measurement Plane (CCAMP) (as defined by the CCAMP Working Group
   [CCAMP]) makes an additional distinction between management and
   measurement.  When the logical separation of the Control,
   Measurement, and other Management entities is not relevant, the term
   "Controller Plane" is used for simplicity to represent them all, and
   the term "Controller Plane Function (CPF)" refers to any device
   operating in that plane, whether it is a Path Computation Element
   (PCE) [RFC4655], a Network Management Entity (NME), or a distributed
   control protocol.  The CPF is a core element of a controller, in
   charge of computing deterministic paths to be applied in the Network

However since this term does seem to generate a lot of comments, I did add an entry in the Terminology section of the DetNet Security draft for Controller Plane, referencing RFC8655. 
==================== END =========================