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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 04 Jan 2021 12:57:21 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-detnet-security-13: No Objection

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/

----------------------------------------------------------------------
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.

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

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?

   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.

---

From: "Ethan Grossman" <[email-masked]>
Date: Thu, 28 Jan 2021 13:48:03 -0800

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. 
Sincerely, 
Ethan (as Editor, DetNet Security Considerations draft)

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

---------------------------------------------------------------------
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. 

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

EAG: OK. 

	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
        network.</t>
      <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 ( https://tools.ietf.org/html/rfc8655 ) 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
   Plane.

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 =========================

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Jan 2021 17:13:44 -0500

Thanks for all this, Ethan; I appreciate your considering and
addressing my comments.  And thanks for sending me the message thread
about Magnus's DISCUSS.  I had seen most of it as it passed by, but
having it at the top of my inbox makes it easy for me to review it and
digest it!

Barry