Subject: [Detnet] Pre LC comments on draft-ietf-detnet-security-08.txt

From: Lou Berger <[email-masked]>
Date: Mon, 16 Mar 2020 10:03:09 -0400

Hi,

In preparation for LC I have reviewed the above document and think there 
are some editorial changes that would be good to address before LC.  
Note, these are generally editorial in nature, also please feel free to 
push back if you disagree as some of the comments are stylistic.

1) Please reduced the number of authors on the front cover to the 5 
requested by the IESG policy.  I think just listing the editor is a fine 
solution, but certainly not the only option.

2) Please ensure that you are only covering protocol security issue. For 
example 6.1.4 and "flaws" in code that don't result in a security issues 
really don't belong in the document. The same goes for consumption of 
resources that are otherwise unused.

3) Please reread the document and see what text can now be 
removed/replaced with an appropriate reference to the other WG documents 
(architecture, information model, data plane docs, etc.)  The document 
should at least include references to the architecture and data plane 
framework.  -- if you think you need a protocol description, there 
should be a reference to where that description resides with minimal 
background text.

4) for consistency with other WG documents, I suggest:

s/control plane/controller plane

s/control messaging/controller plane messaging

s/signaling/controller plane

s/cpu/processing

s/bridges/routers

s/stream/DN flow

5) Abbreviations

Section 2 seems to contain an arbitrary subset of definitions used in 
the document. Rather than spend the time coming up with an exhaustive 
list, I suggest deleting this section and ensure to expand abbreviations 
the first time they are used.  Also consider if you really need to 
introduce an abbreviation at all, e.g., 'EP'.

6) Abstract

This reads like a nice background paragraph that certainly should be 
covered in the intro, but it should summarize the contents of the 
document -- which I don't think it does.

7) Remove editor's notes

8) Some nits:

in section 1: s/Reserve data plane/Assign data plane

section 3.2.3.1: it is unclear what security vulnerability is being 
described

Section 3.2.4.2: The flow hijacking description seems to be more about 
eliminating replicas, perhaps you can clarify so the two can't be conflated?

Section 4.2.2.1: s/ the budget/the resource budget

Section 5.5: I think it would be worth mentioning MACsec/802.1AE as a 
subnet encryption example.

Section 5.7: S/NETCONF/YANG

section 6.1.1: replace title with "Sub-Network Layer"

     also s/explicitly supported/the first identified

Section 6.1.2: s/is expected to/can

     Also just use controller vs CNC

Section 6.1.4: s/Information/YANG

That's it on this very nice bit of work!

Thank you,

Lou

(doc Shepherd)

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 17 Mar 2020 22:09:10 +0000

Thanks Lou. I will start in on fixing the easy ones, and if there are any left over I can ask the list. 
To the others (particularly those currently listed as co-authors): If you have any interest in participating in this edit pass please let me know. 
Ethan.

-----Original Message-----
From: Lou Berger <[email-masked]> 
Sent: Monday, March 16, 2020 7:03 AM
To: [email-masked]
Cc: DetNet Chairs <[email-masked]>; DetNet WG <[email-masked]>
Subject: Pre LC comments on draft-ietf-detnet-security-08.txt

Hi,

In preparation for LC I have reviewed the above document and think there are some editorial changes that would be good to address before LC. Note, these are generally editorial in nature, also please feel free to push back if you disagree as some of the comments are stylistic.

1) Please reduced the number of authors on the front cover to the 5 requested by the IESG policy.  I think just listing the editor is a fine solution, but certainly not the only option.

2) Please ensure that you are only covering protocol security issue. For example 6.1.4 and "flaws" in code that don't result in a security issues really don't belong in the document. The same goes for consumption of resources that are otherwise unused.

3) Please reread the document and see what text can now be removed/replaced with an appropriate reference to the other WG documents (architecture, information model, data plane docs, etc.)  The document should at least include references to the architecture and data plane framework.  -- if you think you need a protocol description, there should be a reference to where that description resides with minimal background text.

s/cpu/processing

s/bridges/routers

s/stream/DN flow

5) Abbreviations

Section 2 seems to contain an arbitrary subset of definitions used in the document. Rather than spend the time coming up with an exhaustive list, I suggest deleting this section and ensure to expand abbreviations the first time they are used.  Also consider if you really need to introduce an abbreviation at all, e.g., 'EP'.

6) Abstract

This reads like a nice background paragraph that certainly should be covered in the intro, but it should summarize the contents of the document -- which I don't think it does.

7) Remove editor's notes

8) Some nits:

section 3.2.3.1: it is unclear what security vulnerability is being described

Section 3.2.4.2: The flow hijacking description seems to be more about eliminating replicas, perhaps you can clarify so the two can't be conflated?

Section 5.5: I think it would be worth mentioning MACsec/802.1AE as a subnet encryption example.

Thank you,

Lou

(doc Shepherd)

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Mar 2020 18:17:49 -0400

Thank you!

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 18 Mar 2020 04:39:11 +0000

Hi All,
Per Lou's item #6 below, here is my attempt at a fresh new Abstract. (I also moved the pre-existing abstract down to be the first paragraph in the Introduction.) Please let me know what you think. 
Thanks,
Ethan (as DetNet Security draft editor)
----------------------------------------------------
    <abstract>
      <t> A DetNet (deterministic network) provides specific performance guarantees to its data
        flows, such as extremely low data loss rates and bounded latency. As a result, securing a
        DetNet implies that in addition to the best practice security measures taken for any
        mission-critical network, additional security measures may be needed whose purpose is
        exclusively to secure the intended operation of these novel service properties. This
        document addresses specifically those security considerations, with the assumption that the
        reader is already familiar with network security best practices for the data plane
        technologies underlying a given DetNet implementation (including IP and/or MPLS). This
        document defines a threat model and a taxonomy of relevant attacks, including their
        potential impacts and mitigations. </t>
      <t> A given DetNet may require securing only certain aspects of DetNet performance, for
        example extremely low data loss rates but not necessarily bounded latency. Therefore this
        document provides an association of threats against various use cases by industry, and also
        against the individual service properties as defined in the DetNet Use Cases (<xref
          target="RFC8578"/>). </t>
      <t>This document also addresses common DetNet security considerations related to the IP and
        MPLS data plane technologies (as explicitly supported by DetNet), thereby complementing the
        Security Considerations sections of the various DetNet Data Plane (and other) DetNet
        documents. </t>
    </abstract>
------------------------------------------------------------------------------
-----Original Message-----
From: Lou Berger <[email-masked]> 
Sent: Tuesday, March 17, 2020 3:18 PM
To: Grossman, Ethan A. <[email-masked]>; [email-masked]
Cc: DetNet Chairs <[email-masked]>; DetNet WG <[email-masked]>
Subject: Re: Pre LC comments on draft-ietf-detnet-security-08.txt

Thank you!

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 19 Mar 2020 01:50:54 +0000

Hi Lou, WG, 
Here is the current status of these items in the forthcoming version 09 as updated by Henrik and me (see below inline). 
Most items were addressed exactly as requested, however for the less concrete ones another review pass is suggested.
I suppose I will just submit version 09, as a "candidate" for WG LC, but by all means if we missed or misunderstood something, or anyone disagrees with our approach, please let me know and we can discuss further. 
Ethan.

-----Original Message-----
From: Lou Berger <[email-masked]> 
Sent: Monday, March 16, 2020 7:03 AM
To: [email-masked]
Cc: DetNet Chairs <[email-masked]>; DetNet WG <[email-masked]>
Subject: Pre LC comments on draft-ietf-detnet-security-08.txt

Hi,

EAG: I left Tal as author, me as editor, and moved everyone else to the Contributors section. If anyone else feels it is important and appropriate that they be listed as co-author, please let me know. 

EAG: I did not make any changes as a result of this comment. We have had variations of this comment in past reviews; section 6.1.4 is part of the section that is (at this point systematically and exhaustively) reviewing each of the "use case common themes", identifying for each theme the specific attacks that might be relevant to that theme (which I have now  referred to in the Abstract as "individual service properties"). Thus far I have resisted removing any of the items under the rationale that they collectively constitute a "set", so each needs to be at the very least represented. At minimum we note that thus far we haven't identified any specific threats related to that particular theme/property, but it doesn't mean that there are none. In the case of 6.1.4 (Data Flow Information Models) we just point out that this YANG model is new and thus a potential "new attack surface". I personally feel that pointing out non-specific things like this is in the spirit of the document, which is "considerations" - a laundry list of ideas to get the security implementer started in thinking about what they might need to do for their specific network. Ultimately the responsibility for securing their DetNet is theirs; we are just trying to help them consider what new things DetNet brings, and their possible implications for security; we can't promise to have found every possible security vulnerability, but we're trying to be as helpful as we can. 

EAG: Henrik reviewed the document and added text to address this comment. 

EAG: OK

EAG: No instances found

EAG: OK

s/cpu/processing

EAG: OK

s/bridges/routers

EAG: OK

s/stream/DN flow

EAG: OK

5) Abbreviations

EAG: I agree in most cases, and have addressed this (in the places I have found so far; there may be more, needs another review pass for this), however I ended up leaving a few in the Abbreviations sections that I feel make sense to be there since they are used in a few places that aren't near each other (these are: IT, OT, MITM). In places where all uses of the term are "near each other" (e.g. within the same sub-section), I agree that just defining it inline on first use is appropriate. 

6) Abstract

EAG: I wrote a whole new abstract and set to the list for review. Assuming no major objection I will go with that. 

7) Remove editor's notes
EAG: For reference, here are the notes removed: 
From section " Mitigation Summary" and " Attack Types by Use Case Common Theme":
(same note in both places) 
        <t>Editor's note: Is this tabular summary of the above information useful or necessary in
          this draft? If we opt to maintain the tables then the WG needs to validate them for
          completeness and correctness after all other draft comments have been addressed.</t>

Regarding the question raised (in both notes), I am interpreting this action as a vote for "at least for now we will keep the tabular summaries in both cases". We can look at validating them at the very end, perhaps even in IETF Editorial review. 

8) Some nits:

EAG: I fixed this instance, but I note that the term "reserved" is used in various other places - is that appropriate, e.g. do we still say "reserved bandwidth" as opposed to "assigned bandwidth"? 

EAG: Henrik submitted revised text for this section. 

EAG: Henrik submitted revised text for this section.

EAG: OK

EAG: FWIW this is already mentioned in section 7, DetNet Technology-Specific Threats; I added a reference to that section. 

EAG: OK

EAG: OK

EAG: OK

EAG: OK

EAG: OK

EAG: OK

Thank you,

Lou

(doc Shepherd)

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 19 Mar 2020 02:01:59 +0000

Well I already spotted one goof: my apologies Stewart and David - I forgot to add you as Contributors. So there will be a rev 10 for sure - please everyone pile on with your additional comments...
Ethan.

-----Original Message-----
From: Grossman, Ethan A. <[email-masked]> 
Sent: Wednesday, March 18, 2020 6:51 PM
To: Lou Berger <[email-masked]>; [email-masked]
Cc: DetNet Chairs <[email-masked]>; DetNet WG <[email-masked]>
Subject: RE: Pre LC comments on draft-ietf-detnet-security-08.txt

Hi Lou, WG, 

-----Original Message-----
From: Lou Berger <[email-masked]> 
Sent: Monday, March 16, 2020 7:03 AM
To: [email-masked]
Cc: DetNet Chairs <[email-masked]>; DetNet WG <[email-masked]>
Subject: Pre LC comments on draft-ietf-detnet-security-08.txt

Hi,

EAG: OK

EAG: No instances found

s/cpu/processing

EAG: OK

s/bridges/routers

EAG: OK

s/stream/DN flow

EAG: OK

5) Abbreviations

6) Abstract

7) Remove editor's notes

8) Some nits:

EAG: OK

EAG: OK

EAG: OK

EAG: OK

EAG: OK

EAG: OK

EAG: OK

Thank you,

Lou

(doc Shepherd)