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

[Barry Leiba <[e-mail]>]

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

On Thu, Jan 28, 2021 at 4:48 PM Ethan Grossman <[e-mail]> wrote:
>
> 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 <[e-mail]>
> Sent: Monday, January 4, 2021 12:57 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Lou Berger <[e-mail]>; [e-mail]
> 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.
>
>         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…”
> EAG: OK.
>
>    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
>         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 =========================
>
>
>