Re: [Detnet] I-D Action: draft-ietf-detnet-security-11.txt

["Grossman, Ethan A." <[e-mail]>]

Here is the list of completed items in Security draft 11: 
Ethan.

== Minor Issues ==

M1) You make use of several terms that are not defined in this document. I suspect that they are inherited from the main DetNet work so that is not a problem, but it would be useful to have a pointer so that this document can be read with easy context.

For example, "resource segmentation" and "resource slicing", but there are probably others. Resource segmentation may be particularly important to clarify as the other use of "segmentation" is in 6.3 which is possibly a different concept.

Somewhere around section 2 would be a good place to add the pointer.
EAG: FWIW it seems the use of “segmentation” is intended to be the same everywhere. 
	 I removed the word “slicing” since never referenced. I added a def for resource segmentation as “Used as a more general form for Network Segmentation (the act or practice of splitting a computer network into subnetworks, each being a network segment – (ref))” since I couldn’t find an online def for “resource segmentation” (I didn’t happen to have introduced that term) 
---

M2)I think the first paragraph of the Introduction needs a reference to RFC 8655 where term "DetNet" is introduced.
	 Added ref. 
---

M8A) 3.3
   At the data plane the implementation of PREOF depends on the correct
   assignment and interpretation of packet sequence numbers, as well as
   the actions taken based on them, such as elimination.  Thus the
   integrity of these values must be maintained by the component as they
   are assigned by the DetNet data plane's Service sub-layer, and
   transported by the Forwarding sub-layer.

Depending on the meaning of "component" (a term you use without definition in this document - although you do give "such as routers") 
	Added def of term “component”: “A component of a DetNet system is used here to refer to any hardware or software element of a DetNet network which implements DetNet-specific functionality, for example all or part of a router, switch, or end system.”

---

M9) 3.4

Should this case also discuss the damage you can do if you can make it look like a packet violates the time window or reserved bandwidth? For example, it looks like you could make a link shut down
EAG: Shutting down a link in response to a packet arrival time violation is probably not a knee-jerk response in this kind of system, and part of the point of the wording was to indicate that, but I will make it clearer. 
	Revised text. 

M10) I also wonder at your use of "Logging of such issues *may* not be adequate." Shouldn't you turn this into stronger guidance since
(presumably) the DetNet component doesn't know about the applications that running are running data flows, it has to be the case that logging is never adequate.
	Revised text to make this point. 
---

Would be nice if the column headings from Figure 2 part 1 were expanded somewhere. Some of the row names are also a little terse.
EAG: I claim that they are sufficiently spelled out in the paragraph that is three paragraphs above the start of the table of Figure 2. If you didn’t just happen to miss that, and still disagree, please let me know. 
	No action taken. 
---

M13) 6.3.2
   o  add/remove end-stations to a multicast group (loss of privacy)

I think that 'remove' has a different result, i.e., not loss of privacy
	Created separate line for “remove” with impact “reduction of service” (anyone have a better phrase?) 
---

M14) Isn't 7.4 also an attack vector?
EAG: Yes, I would say that is covered by 6.3. Segmentation Attacks (injection), and 6.6. Control or Signaling Packet Injection. This is a different topic.
	No action taken. 
---

M16) 8.1.6

   Packets may also be dropped due to malfunctioning software or hardware.

It's true. But is it anything to do with the security considerations in this document?
	Yes, it’s obvious. Removed this line. 
---

M17) 8.1.13 seems to be to be derogatory and unnecessary! There is nothing to say that an expensive implementation from a bespoke vendor will be secure, and nothing to suggest that a high-cost product from an established vendor will be well implemented. I would suggest striking this section unless you want to rewite it as "substandard implementations" pointing out that implementations that are not well made amy include vulnerabilities and other defects that risk the security of the DetNet - the mitigation remains the same.
EAG: Agree, point taken, but the overall concept is still valid. 
	Refactored text. 
---

M18) 8.1.12, 8.1.13, and 8.1.14 seem to have a good chunk of text in common.
At best that is distracting, but it is probably a sign that you should ratoinalise the text.
	Rationalized text (IMHO). 
---

M19) I am personally not very keen on the mention of the Mirai exploit as an example here. I think you may be kaing some assumptions about why this attack was possible, and it might be better to not enter that debate.
The example does not, in any case have much of a bearing on DetNet.
	Removed reference. 
---

M20) 8.1.16 has ", perhaps like the Stuxnet attack)". If you keep this, it needs a citation. But I would suggest removing it without any loss of specificity in your text.
	Removed reference. 
---

M21) 8.1.16

   Of the attacks we have defined, the ones identified above as relevant
   to "large" networks are the most relevant.

I'm not sure, but I think the only mention of network size to this point was in 8.1.15. So I think you should reference that section rather than leave the reader to wonder whether they should search the document for other mentions of network size.
	Added section reference. 
---

---

M23) 8.2
In the text you should refer to your tables by figure number for clarity as the text may be moved around in the edit process.
	Done. 
---

== Style Issues ==

S1) Abstract is too long. You should aim for a maximum of 25 lines. I see
35 lines of text, and some blank lines.  I would remove:

   It is assumed that both classes of reader are
   already familiar with network security best practices for the data
   plane technologies underlying a given DetNet implementation.
   Component-level considerations include isolation of data flows from
   each other, ingress filtering, and detection and reporting of packet
   arrival time violations.  System-level considerations include a
   threat model and a taxonomy of relevant attacks, including their
   potential impacts and mitigations.

and

   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

EAG: OK I totally refactored the Abstract and condensed it into a single paragraph - here is the new text (as updated by Deborah): 
	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 requires that in addition to the best
        practice security measures taken for any mission-critical network, additional security
        measures may be needed to secure the intended operation of these novel service properties.

        This document addresses DetNet-specific security considerations from the perspectives of
        both the DetNet system-level designer and component designer. System considerations include
        a threat model, taxonomy of relevant attacks, and associations of threats versus use cases
        and service properties. Component-level considerations include ingress filtering and packet
        arrival time violation detection. This document also addresses DetNet security
        considerations specific to the IP and MPLS data plane technologies thereby complementing the
        Security Considerations sections of the various DetNet Data Plane (and other) DetNet
        documents.

---

S2) Abstract

   as defined in the DetNet Use Cases.

I suspect you are attemting to refer to RFC 8578. While you can't have
citations in the Abstract, you can mention documents by name. So I would
write:

   as defined in RFC 8578, "Deterministic Networking Use Cases".
	This text was removed in Abstract rewrite. 
---

S3) Section 2 has two quotes you appear to attribute to Wikipedia. Please
include URL citations for these quotes.
	Added refs. 
---

S4) I don't understand the choices of subsection indentation in 5.2.
EAG: The original intent was that there would be classes of attacks which then had subclasses, but now that the dust has settled, some classes had no subclasses, making it look awkward. 
	I consolidated the “lone” entries, but this may take another pass through to thoroughly resolve. 

---

S6) It seems to me that 8.1.7 and 8.1.8 are virtually identical text and you
might roll them into one section.
EAG: I have been maintaining these as separate sections because they correspond one-to-one with the specific “use case themes” that are baked into the Use Cases (RFC8578). But I agree it looks silly how it is. 
	I combined these two.
---


== Nits ==

N1) Does "DetNet" mean "deterministic networking" or "deterministic network"
You have both. I also found "DetNet-enabled network"

EAG: It seems both grammatical forms are used. The former is more common, e.g. as used in the WG’s name, but the latter is also used, e.g. in RFC8655 (DetNet Arch) : 
“4.1.2. DetNet Data-Plane Overview A "Deterministic Network" will be composed of DetNet-enabled end systems, “

	So I claim no change is in order here. 
---

N2) Abstract

   additional security measures may be needed whose purpose is exclusively to secure the intended operation

Why "exclusively"? Are we not allowed a security measure that does more than one thing?

EAG: OK, propose to loosen wording: 

	“additional security measures may be needed to secure the intended operation of these novel service properties”

---

N3) You have both "data plane" and "Data Plane"
EAG: Yes, both forms are needed grammatically, since the capitalized Data Plane needs to be used when it is used as a proper name. 
	However I did review all uses of the phrase and corrected several capitalization errors. 
---

N4) Why is "operational technology" lower case when "Information Technology" is capitlaised? (Except when you reverse this!)
EAG: No reason. 
	Enforced capitalized since used as proper name. 
---

N5) s/controller plane/control plane/ throughout
	Done.

---

N6) s/The latter include threat modeling/The latter includes threat modeling/
	Done.
---

N7) Introduction

   (based on the Use Case Common Themes section
   of the DetNet Use Cases).

Please include a reference to RFC 8578.
	Done.

---

N8) 3. s/Each of these have/Each of these has/
	Done. 

---

N9) 3.2
s/(However,  is acceptable/However, it is acceptable/
	Done

N10) 
s/failure)./failure.
	There was a matching previous paren but I removed both. 

---

N11) 3.3 has
   As noted in Section 7.2, Packet Sequence Number Integrity Considerations,

Section 7.2 has a different name.
	Updated name. 

---

4.
s/However DetNet also introduce/However DetNet also introduces/
	Done. 
---

N12) 5.1
OLD
(explored further in Section 5.2 (Threat Analysis)
NEW
(explored further in Section 5.2, Threat Analysis)
END
	Done. 
---

N13) 5.2.4.2

   An attacker can manipulate the replication-related header fields
   (R-TAG).

Does "R-TAG" stand for "replication-related header fields"? Seems
improbable.
	Removed “(R-TAG)”

---

N14) In figure 1 you have one "+" out of alignment

   |Delay attack                             | +  |  + | +  |  + |
	Fixed. 
---

N15) 6.3.2
   o  modify the DetNet flow attributes (affecting available bandwidth

Missing close brace
	Fixed. 
---

N16) 7.5
      Alternatively, if the payload is end-to-end encrypted at the
      application layer, the DetNet nodes should not have any need to
      inspect the payload itself, and thus the DetNet implementation can
      be data-agnostic.

This paragraph might usefully be reworded to sort out the cause and
effect implications. Something like:

      DetNet nodes do not have any need to inspect the payload of any
      DetNet packets, making them data-agnostic.  This means that end-to-
      end encryption at the application layer is an acceptable way to 
      protect user data.
	Substituted recommended text. 
---

N17) 8.1.1 should have a citation for 802.1Qbv
	Added citation. 
---

N17) 8.1.5 

"MPLS-PW" is not a well known abbreviation
	Spelled out Pseudowire.

s/to L2,L3/to L2-L3/
	Done. 

---

N18) 8.1.17

   Reconnaissance could be used to characterize flows and perhaps target specific flows for attack via the controller plane as noted above.

Could you give a section reference rather than "above"?
	Added section ref to Reconnaissance section. 
---

N19) 8.1.19

   Attacks on the controller plane (as described in the Level of Service
   theme) and Delay and Time attacks (as described in the Bounded
   Latency theme) both apply here.

Maybe these "themes" could be section references, or are you refering to 
"the themes shown in Figure 5"?
	Added two section references. 
---

N20) 8.1.22
   Any attack on the system, of any type, can affect its overall reliability and availability, thus in our table we have marked every attack. 

Can you say which table (i.e., which Figure)?
	Added table reference (in 3 similar places). 
---

N20) 8.3

OLD
OAM (Operations, Administration and Maintenance)
NEW
OAM (Operations, Administration, and Maintenance)
END
	Done. 

N21) OLD
For purposes of this discussion
NEW
For the purposes of this discussion
END
	Done, also in 2 other analogous places. 


++++++++++++++++++++++++++++++++++++++++++++