Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-16

I found this to be an interesting read.  Once you mentioned aircraft internals, I was even more into it.

This text in the Abstract caught my eye:

   This document also addresses security considerations specific to the
   IP and MPLS data plane technologies, thereby complementing the
   Security Considerations sections of those documents.

It almost seems appropriate for this one to formally update those if indeed they were left incomplete.  I realize, however, that's not possible for an Informational document if the others are Standards Track.

Besides that, some nits:

Section 8.1.8: s/coexistance/coexistence/

In Section 8.1.11, there's an instance of DETNET in all-caps, while it's "DetNet" everywhere else.

Section 8.1.22, a suggestion:

OLD:

   [...] A strategy used by DetNet
   for providing such extraordinarily high levels of reliability is to
   provide redundant paths that can be seamlessly switched between, all
   the while maintaining the required performance of that system.

NEW:

   [...] A strategy used by DetNet
   for providing such extraordinarily high levels of reliability is to
   provide redundant paths between which traffic can be seamlessly
   switched, all the while maintaining the required performance of that system.

Thank you to Yaron Sheffer for the SECDIR review.  Please respond to it.

Thanks for addressing my DISCUSS points and a number of my COMMENTs.


===

** Section 7.4.  The use of [IEEE802.1Qch-2017] is remarkably specific reference without any guidance on implementation, either here the active DetNet drafts (I checked).  Please consider if this is realistic guidance without further citation on how this could be implemented.

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Let's also try to address the COMMENT for section 4.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
In "best practices for security at both the data plane and controller plane", is there a reason why the management/telemetry plane(s) is not included? Of course, most of the time this plane is isolated from the others but anyway... Also, is is "controller plane" or "control plane" ? or is the 'controller plane' the plane connecting PCC to PCE ? (with an assumption that the ID is also relying on PCC/PCE ?).

Section 8.3 (OAM) is welcome but why not already including OAM in the above sentence ?

-- Section 5.2.3 & 6.3.1 --
May I assume that any layer-1 'jamming' (e.g., microwave link) is also covered by this section ? If so, then I suggest to state it.

-- Section 3.3 --
"(Note that PREOF is not defined for a DetNet IP data plane)." will this note be applicable forever ? Should the word 'currently' be used in this statement? I also do not see the point of using parenthesis. I prefer the wording used in section 7.1 "At the time of this writing, PREOF is not defined for the IP data plane."

-- Section 3.4 --
Probably due to my ignorance about DetNet, but, I fail to understand why "having the network shut down a link if a packet arrives outside of its prescribed time window" and the rest of the section. Again, probably due to my lack of context but you may want to explain the reasoning behind.

-- Section 4 --
There is no 'TOS' field in the IPv6 header, it is replaced by 'Traffic Class'. So, please mention both of the fields.

-- Section 6 --
On figure 2, there are mentions of blockchain and network slicing without any previous explanations (and I have hard time to see how blockchain traffic should be detnet).

-- Section 8.3 --
This section seems to consider only OAM traffic added to the DetNet traffic while there are a couple of in-band OAM techniques currently being specified at the IETF.

-- Section 9 --
If the IPsec sessions are established by a controller, then this controller could also send the Security Parameter Index (SPI) that is transmitted in the clear and use this SPI to in addition to the pair of IP addresses.

== NITS ==

-- Section 1 --
s/A DetNet is one that/A DetNet is a network that/

-- Section 8.2 --
s/Figure 5maps/Figure 5 maps/

-- Authors --
The URL for http://www.mistiqtech.com does not work for me

I did not have time to review this document in detail but I looked at the Gen-ART review and it seems that most of the points have been addressed, thanks. I agree with other ADs that the tables in Section 6 do not make much sense or add much value. At a minimum the block chain and networking slicing columns should be removed as they are provided with no explanation and do not seem to belong with the other columns.

It's interesting to collect security considerations into one document.  We have to be careful that in doing so, we don't fall into the trap of not thinking enough about security considerations specific to later documents, once this one is published and immutable.  Let's please watch for that.

I'm also interested to see the discussion of Magnus's DISCUSS points.

And just a few editorial comments about the Introduction:

   A DetNet is one that can carry data flows for real-time applications
   with extremely low data loss rates and bounded latency.

I would spell it out first” “A Deterministic Network (DetNet) is one…”

   potentially bringing the OT
   network into contact with Information Technology (IT) traffic and
   security threats that lie outside of a tightly controlled and bounded
   area (such as the internals of an aircraft).

It’s not clear from the sentence structure what “the internals of an aircraft” is meant to be an example of.  Is it an example of a tightly controlled and bounded area (as it seems it would be)?  Or is it outside that?  And if it’s not outside that, what’s the point of using it as an example?  Are you meaning to say that we have to deal with threats from outside that affect things inside the tight boundaries?

Maybe it’s best to try to reword this?

   following industry best practices for security at both the data plane
   and controller plane;

This should be “control plane”, shouldn't it?  Also in other places in the document.

There are probably a couple places that currently reference only RFC 8939
where it would be appropriate to reference both 8939 and 8964.

Section 1

   This document is based on the premise that there will be a very broad
   range of DetNet applications and use cases, ranging in size scope
   from individual industrial machines to networks that span an entire

nit: s/size scope/size and scope/

Section 4

   DetNet is designed to be compatible with DiffServ [RFC2474] as
   applied to IT traffic in the DetNet.  DetNet also incorporates the
   use of the 6-bit value of the DSCP field of the Type of Service (ToS)
   byte of the IPv4 header (or the Traffic Class byte in IPv6) for flow
   identification for OT traffic.  [...]

nit: I suggest "the use of the 6-bit value of the DCSP field of the Type
of Service (IPv4) and Traffic Class (IPv6) bytes for flow
identification", to avoid giving IPv4 preferred treatment.

Section 5.2.3

   However if there is only one queue from the forwarding ASIC to the
   exception path, and for some reason the system is configured such
   that DetNet packets must be handled on this exception path, then
   saturating the exception path could result in delaying or dropping of
   DetNet packets.

nit: I suggest "such that some DetNet packets" -- it is an issue if any
do, and doesn't require all of them to take the exception path.

Section 6.1.1

   A data-plane delay attack on a system controlling substantial moving
   devices, for example in industrial automation, can cause physical
   damage.  For example, if the network promises a bounded latency of
   2ms for a flow, yet the machine receives it with 5ms latency, control
   loop of the machine can become unstable.

nit: "the control loop".

Section 7.2

      There are different levels of security available for integrity
      protection, ranging from the basic ability to detect if a header
      has been corrupted in transit (no malicious attack) to stopping a
      skilled and determined attacker capable of both subtly modifying
      fields in the headers as well as updating an unsigned MAC.  [...]

I'd suggest s/unsigned MAC/unkeyed checksum/.

Section 9.2

It's a bit surprising to not see references to the (security
considerations of the) MPLS control word specs like RFCs 4385 and 5586.

Thanks for addressing my issues.

Thanks for this document.  Sorry, I've run out time to review this in detail, although I don't immediately see any manageability concerns when I scanned through the document.

A few minor comments for your consideration:

1) Perhaps it might be helpful to mention remind that DetNet isn't the same as TSN in the introduction?

I don't know if these are already covered, or if they are not valid problems, but I guess a couple of attacks that I would be concerned with are:

(2) Overloading the exception path queue on the router.  E.g., if any of the DetNet streams require/expect some packets to be punted to the control plane or software data plane for processing (OAM related perhaps), and there is a single queue from the forwarding ASIC to a control plane or software data plane, then it could be possible for Non Detnet flows to overload that shared queue such that punted packets on the DetNet flows would end up being dropped.

(2b) Related to (2), if an attacker was able to overload the router or linecard CPU, e.g., through excessive management API requests, then it may be plausible that it could also cause control plane processing of packets to be dropped, or slowed down.

(2c) If the control plane is being managed by a separate controller than presumably both (2) and (2b) could equally apply to getting traffic to a controller, or processing events on the controller.

(3) Is there any potential issue with traffic being carried over L2 load balanced links (e.g. LAG) that apply statistical QoS.  E.g., by crafting traffic on a non DetNet flow that overloads one LAG member but doesn't overload the statistical QoS guarantees.  Perhaps this is outside the considerations for DetNet, or already covered by TSN.

I'll leave it to the authors to determine whether any of these are valid and require further text, or if they are either already sufficiently covered, out of scope, or not valid concerns.

Regards,
Rob