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

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

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

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