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

From: [email-masked]
Date: Fri, 14 Aug 2020 20:06:19 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Deterministic Networking WG of the IETF.

        Title           : Deterministic Networking (DetNet) Security Considerations
        Authors         : Tal Mizrahi
                          Ethan Grossman
	Filename        : draft-ietf-detnet-security-11.txt
	Pages           : 46
	Date            : 2020-08-14

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-security/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-detnet-security-11
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Sat, 15 Aug 2020 03:28:43 +0000

Hi All,
I made a pass through the Security draft to address as many of Adrian's comments as I could do single-handedly (45 comments). There remain 23 comments that I deferred for the next pass, to be completed with help from "the usual suspects" as Stewart said. I think this draft 11 makes a better starting place for that work compared to going from draft 10. 
I will send the two lists (comments completed in draft 11 (below), and those deferred to draft 12) via separate emails. 
As always, any WG input on any of the comments (complete or deferred) would be appreciated. 
Thanks,
Ethan (as Editor, DetNet Security Considerations draft)

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, August 14, 2020 8:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] I-D Action: draft-ietf-detnet-security-11.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Sat, 15 Aug 2020 03:34:08 +0000

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. 

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

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Sat, 15 Aug 2020 03:36:14 +0000

Here is the list of remaining items from Security draft 11. I also incorporated into the comments all related email thread discussion to date. 
Ethan.

== Medium Issues ==

I1) It's a security document, so I searched for the word "privacy" and found it in just two places.  Is it possible that these are the only two examples of privacy-impacting issues with DetNet?  If so, I suggest adding a section ("Privacy Considerations") where you point to these two cases and explain that there are no other privacy concerns. But, more likely, there is more you can say on the tpoic and should call out with additional text. You may find RFC 6973 to be useful.

FWIW, only 5.2.7.1/6.7 seemed immediately relevant to privacy.
EAG HOLD

================Start MITM================================

I2) It would be nice to avoid the term "man-in-the-middle" (and coresponding
"MITM") in favour of the term "on-path attacker". It is less problematic as a term, and no less accurate.

Although "man-in-the-middle" is well established, I think you could easily avoid it and if you feel necessary you could use "An on-path attacker (formerly known as a man-in-the-middle) ..."

Then Stewart wrote: 
I sort of understand why you want to change MITM, although given that the man you have in mind is evil I am not sure whether it is that objectionable in this context. However I am not sure on-path is the right term. MITM normally implies an entity that can modify traffic in flight, whereas an on path attacker may simply be an observer.

Maybe AITM (attacker ....) would be a better gender neutral term.

Then Eric Gray wrote: 

	Actually, in addition to the many things that are strange about this entire conversation, your observation about the "thing in the middle" (I mean, let's face it, the "entity" in the middle - EITM? - has been gender-neutral for a long time, given that any human participation in the role could be detected by an idiot) being necessarily _active_ is not quite correct.

	It seems to me to be quite reasonable that the middle position could as easily be used to passively collect information for use in other activities - including a few fairly well known attacks.

Then Stewart wrote: 

We are talking about the threats in DN. 

I think we should be focusing on the things that are special to DN which is a technology that adds certain properties to a general network. I assume the protection of the general network using the normal techniques is a given.

Passively looking at the contents is about privacy and technical surveillance to intervene more effectively.

Privacy obviously applies to a general network, and I take it as read that we protect against this. However this document is about DN, and I cannot see what the privacy concerns are about the DN specifics.

Then Eric Gray wrote: 
	I am not certain that your "active attacker" assumption is correct even in this limited case, but you were responding on the subject of "gender neutrality" and whether or not it is appropriate to use "MITM" (presumably in general).

	That topic is no longer in the realm of "DetNet specific."  So your response should probably not be written (or read) as if it were.

	In your own words, however, one reason for passive listening is "technical surveillance to intervene more effectively" - which would seem to apply to DetNet at least as much as to anything else.

	This is not necessarily a generic privacy concern, as a passive MITM could be waiting for some specific activity (or activities) to occur in what would clearly be a "special class" of communications (such as DetNet would be)

Then Adrian wrote: 

My review said, "It would be nice to avoid," not, "You must avoid."
The review is principally for the AD, and they will tell you whether you need to action this.
I made a constructive suggestion of an alternative phrase, but you are allowed to choose others.

The thing about the term "man-in-the-middle" is not that it is directly making a specific man appear evil, it is that it associates the word "man" with the concept "evil" and therefore subtly changes the long-term perception of "man". There is, in fact, nothing about this type of attack that is specific to a man, and not all attackers are men, nor are all men attackers.

This is a minor issue for me, and (to some extent) I wanted to experiment with draft-knodel-terminology to see what reaction it would get if the changes it suggests were made as a request rather than as an order.

Then Deborah wrote: 
Without getting into the debate on the term itself, I don't think MITM is concise enough. In RFC3552, MITM is just one of multiple active attack possibilities. Same for Injector, it also is an active attack. It's not simply MITM vs. injector. Stewart is correct - on-path can be an observer (passive). I think we need to define per RFC3552, not the Network Time Protocol threat model.  It would be better to align with the security terms and use on-path /off-path vs. internal/external. I think this is part of the confusion as the definition of internal in the document is mixing with the definition of MITM in RFC3552.

The checked items in Figure 1 are not MITM (they could be done by a MITM), they are basically message modification (RFC3552). So I'm actually not sure the value of this breakdown of MITM vs. Injector? These terms are only used in 5.1 and Figure 1, they are not used in the rest of the document. Suggest it would be more accurate to simply say "active" (document already has the term in 5.1) and remove these terms/breakdown in Figure 1. Same for internal/external, they are not used in the rest of the document.

Section 5.1 has the terms "active" and "passive" but doesn't define them. Need to define.

EAG HOLD
================== End MITM ==============================

I3) I looked for, but didn't find issues of bogus or compromised central controllers. This ranges from a node falsely representing itself as a controller so that the network nodes believe it to be authorised to instruct them (and that includes both being discovered as a controller and impersonating a real controller), to software subversion of the real controller. It might even include malicious acts by a network operator.

Much, but not all, of this is hard to protect against. Some of it can be mitigated by monitoring and logging.
EAG HOLD
---

I4) 8.1.2

I'm not really comfortable with your choice stated in this section to exclude attacks on the control plane from consideration. It seems to me that a network can be rendered entirely dysfunctional by attacking the control plane so that control packets are delayed, reordered, lost, or misdelivered. I don't see why you consider manipulation or inspection of control plane packets as in scope (I agree they should be in scope), but attacks on the control plane itself as out of scope. In fact, I don't see how you attack a control plane packet without attacking the control plane.

Furthermore, I don't think that this "reveal" should be tucked away in this section: the statement is not specific to the subject of this section.

EAG: I think this stems from the original charter of DetNet WG to address data plane only. Now that the WG is re-chartered to address controller plane, given that this Security draft is still in progress, it probably is time to reconsider that limitation. 
EAG HOLD
---

I5) In general I support you not wasting any time discussing the concern of a "subverted" node within the DetNet. That is, a router that has been attacked so that it "lies" about conditions in the network, or harvests data in some way. However, this is a concern that is repeatedly expressed by the security community.

Thus, I think it is worth adding a section to describe:
- How extremely bad this situation would be for the whole DetNet (viz.
  it is a closed system in which one bad actor can immediately break the
  whole in very many bad ways)
- How protection against such issues is not just a DetNet concern but
  applies to all routing sub-systems
- What measures (outside the scope of DetNet) may be taken to protect
  and verify software loads (signing of software loads, etc.)

Note that you do talk about "plug-and-play" in the context of not allowing rogue devices to be added to the network, and that is a good part of the solution, but does not approach protecting against subverted nodes.

EAG HOLD 
== Minor Issues ==

M3) I struggled a little with determining the value of section 3 given the existence of section 5. In many cases, I found that section 3 started the conversation, but left a lot of open questions about threat models that are not answered until section 5.
EAG: Section 3 was the most recently added section, to address a comment from David Black that we needed to “tell implementers what to do” which brought in the whole “component” vs “system” distinction. Adding the section satisfied David’s comment. I will defer to the WG on this one. 
EAG HOLD
---

M4) In 3.1 you have

   It is the responsibility of the component designer to ensure that
   this condition is met; this implies protection against excess traffic
   from adjacent flows, and against compromises to the resource
   allocation/deallocation process.

This is good, but I feel it dodges what measures a component designer should take to protect against attacks on / failures by other components in the network.
EAG HOLD
---

M5) 3.3
   responsibility of the system designer to define these relationships
   with the appropriate security considerations

The word "appropriate" should be a red flag for you. How is the reader to determine what is appropriate unless you tell them? Either include a pointer to the relevant sections of this document, or explain what would be appropriate.
EAG HOLD

M6) Similarly in 5.1
   Most of the
   direct threats to DetNet are active attacks, but it is highly
   suggested that DetNet application developers take appropriate
   measures to protect the content of the DetNet flows from passive
   attacks.
EAG HOLD 

M7) 9.1 has
   So the network must provide sufficient
   isolation between flows, for example by protecting the forwarding
   bandwidth and related resources so that they are available to detnet
   traffic, by whatever means are appropriate for that network's data
   plane.
That's a little more excusable, but it is still a bit hard for the reader to know what to do.
EAG HOLD
---

M8A) 3.3

M8B) I should think you have exposed an issue that is not clear to me. You seem to be saying that it is a component's responsibility to maintain the integrity of the packet sequence number values as they are transported across the network. This is at least the responsibility of a pair of adjacent components in cooperation (for example, if the packet is hashed in some way to prevent the value being tampered with). 

EAG HOLD

M8C) There is also the issue of insertion of packets with spurious sequence numbers to be handled.

EAG HOLD

---

M11) Should 5.2.4 specifically mention amplification?
EAG: I think this is a good idea, but I will defer to WG on this. Here is what I find for a definition (https://security.radware.com/ddos-knowledge-center/ddospedia/amplification-attack/): 
Amplification Attack: An Amplification Attack is any attack where an attacker is able to use an amplification factor to multiply its power. Amplification attacks are "asymmetric", meaning that a relatively small number or low level of resources is required by an attacker to cause a significantly greater number or higher level of target resources to malfunction or fail.
EAG HOLD
---

M12) In 5.2 I was looking for how DetNet's choice of paths is based on the recorded properties of those paths (e.g., latency, jitter, loss) and how the choice of path can be manipuated by causing short-term changes to the properties of individual links in the network.

Maybe this is 5.2.5.1?
EAG: Usually DetNet paths are “nailed up” and so path choices are not easily manipulated by short term property changes (however this is very much a topic in the RAW work). Defer. 
EAG HOLD
---

Shouldn't 7.7 (or somewhere else) discuss the security issues introduced by the monitoring mechanisms? For example, if the reporting mechanism is attacked or subverted, or if the monitoring system is tricked. It seems you have introduced a mechanism that can be used to detect attacks, but not acknowledged that this mechanism can, itself, be attacked giving flase positives or hiding negatives.
EAG: Yes, but who is watching the watchman that is watching the first watchman? I tried writing some text like “Any such monitoring system itself is a potential target for attack, so any such system must be adequately protected …”
But that drew the “adequately” (aka “appropriately”) flag, so I don’t know what to say here. 
EAG HOLD
---

M15) 8.1.4 is, perhaps, a little brief. What attacks can be achieved using this new surface?

EAG HOLD
---

M22) 8.1.24

I think the reader looks to this document to answer the qustion you pose and not simply say that it is TBD. (By the way, you would need to expand 'TBD' and say which table/figure you are referring to.)
	Yes that text is an unresolved holdover from my initial pass at these sections, which phrased them all as questions, which were eventually substituted with “answers”. We didn’t have any answers for this one, but it still is a valid question, I would say. In a way it is the same question as the “watchman” item above (M14). 
EAG HOLD
---

M24) The section numbers in Figure 4 seem to be all wrong.
EAG: And so it is. This is a bad implementation of a table that contains references, since it is done as “artwork” with “manual text” for the section numbers. Does anyone have a clever idea how to do this? Maybe reformat as a bullet list? 
EAG HOLD
---

M25) Figure 5 shows six themes that have no vulnerability to any attack. Is that really right? It seems remarkable enough that you might add a note to help the reader know that this is indeed what you intended the table to show, and possibly to give a reason.
EAG: Not intentional, they just never got filled in. I would like help with this. 
EAG HOLD
---

M26) 8.3

   Thus OAM traffic presents no additional (i.e.  OAM-specific) DetNet security considerations.

Isn't it the case that if an attacker is able to engineer a situation where there is a massive increase in OAM traffic, this can have a negative impact on the ability of the DetNet to deliver its services.
There are three ways such an attack can have an effect:
- the OAM traffic impedes the user plane traffic (such as consuming
  bandwidth, requiring critical processing, impeding timely delivery)
- the additional OAM traffic masks other OAM traffic that reports a
  genuine network issue
- the OAM traffic clogs up the control/management plane bandwidth of
  processing so that the operator is not able to properly control the
  network

There are various ways in which an attacker can stimulate the network to generate excess OAM traffic.

Additionally, of course, fake or modified OAM can lead the management system to believe that there are faults in the network causing traffic to be rerouted onto othe paths resulting in lower levels of service or interception of traffic.

And finally, modified or filtered OAM packets may lead the system to fail to notice real network problems.

EAG: I will leave this to the OAM experts to consider. The logic used so far is as stated in this section, but apparently you aren’t buying it, so we need to discuss further. 
EAG HOLD

M27 (from Adrian email of 31Jul20)) I noticed in section 9 that there is discussion of the sub-layer security measures for IP and Ethernet networks, but (of course?) no mention of security for MPLS encapsulations.
In that context I wondered if Detnet has any interest in https://www.ietf.org/archive/id/draft-ietf-mpls-opportunistic-encrypt-03.txt
EAG HOLD

== Style Issues ==

S5) I didn't understand the practicality of node authenticaiton as described
in 7.3. Is this intended as a check on entry into the network (only
authenticated sources can introduce traffic to the network), a check at
the destiantion (only authenticated sources can send to this
destination), or a per-hop check (is this traffic authenticated to be in
the network? Furthermore, are the checks per packet or per flow?

There are obvious scaling and and key exchange issues involved.
EAG HOLD
---

S7) I'm surprised that you have no Normative references. Is it not necessary to understand some basic DetNet documents in order to understand this document?
EAG: There were at one point normative references, but at one point we decided to make them all informative. I will review this with the WG. 
EAG HOLD

== Nits ==
(All done) 
+++++++++++++++++ End ++++++++++++++++++++++++