[Detnet] Rtgdir last call review of draft-ietf-detnet-security-10

[Adrian Farrel via Datatracker <[e-mail]>]

Reviewer: Adrian Farrel
Review result: Has Issues

Hello, 

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other 
review comments that you receive, and strive to resolve them through
discussion or by updating the draft bearing in mind the consensus of the
working group.

Document: draft-ietf-detnet-security-10.txt
Reviewer: Adrian Farrel
Review Date: 2020-07-31
IETF LC End Date: Not yet scheduled
Intended Status: Informational

== Comments ==

I am not a security expert, and would hope that significant security
reviews are commissioned before this document goes to IETF last call.

It is really good to have such a substantial document describing
security considerations for a new technology/deployment. This is really
important, and I thank the authors and the working group.

I believe that this document is basically ready for publication (subject
to security reviews), but there are quite a few issues that should be
addressed first.

Best,
Adrian

== Medium Issues ==

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.

---

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) ..."

---

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.

---

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.

---

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.


== Minor Issues ==

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.

---

I think the first paragraph of the Introduction needs a reference to
RFC 8655 where term "DetNet" is introduced.

---

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.

---

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.

---

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.

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.

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.

---

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") 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). There is also the
issue of insertion of packets with spurious sequence numbers to be
handled.

---

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

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.

---

Should 5.2.4 specifically mention amplification?

---

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?

---

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.

---

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

---

Isn't 7.4 also an attack vector?

---

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.

---

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

---

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?

---

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.

---

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.

---

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.

---

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.

---

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.

---

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

---

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.

---

The section numbers in Figure 4 seem to be all wrong.

---

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.

---

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.


== Style Issues ==

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

---

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

---

Section 2 has two quotes you appear to attribute to Wikipedia. Please
include URL citations for these quotes.

---

I don't understand the choices of subsection indentation in 5.2.

---

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.

---

It seems to me that 8.1.7 and 8.1.8 are virtually identical text and you
might roll them into one section.

---

I'm ssurprised that you have no Normative references. Is it not 
necessary to understand some basic DetNet documents in order to 
understand this document?


== Nits ==

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

---

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?

---

You have both "data plane" and "Data Plane"

---

Why is "operational technology" lower case when "Information Technology"
is capitlaised? (Except when you reverse this!)

---

s/controller plane/control plane/ throughout

---

s/The latter include threat modeling/The latter includes threat modeling/

---

Introduction

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

Please include a reference to RFC 8578.

---

3.
s/Each of these have/Each of these has/

---

3.2
s/(However,  is acceptable/However, it is acceptable/
s/failure)./failure.

---

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

Section 7.2 has a different name.

---

4.
s/However DetNet also introduce/However DetNet also introduces/

---

5.1
OLD
(explored further in Section 5.2 (Threat Analysis)
NEW
(explored further in Section 5.2, Threat Analysis)
END

---

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.

---

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

   |Delay attack                             | +  |  + | +  |  + |

---

6.3.2
   o  modify the DetNet flow attributes (affecting available bandwidth

Missing close brace

---

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.

---

8.1.1 should have a citation for 802.1Qbv

---

8.1.5 

"MPLS-PW" is not a well known abbreviation

s/to L2,L3/to L2-L3/

---

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"?

---

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"?

---

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)?

---

8.3

OLD
OAM (Operations, Administration and Maintenance)
NEW
OAM (Operations, Administration, and Maintenance)
END

OLD
For purposes of this discussion
NEW
For the purposes of this discussion
END