Comments: draft-ietf-detnet-security-12

The name says it all: this document is all about Deterministic Networking (DetNet) security.

To summarize my perspective on this document: you chose to publish this document as Informational and to not include any normative text. I understand the motivation, presumably all normative text should be included in the base documents. But it makes the document a lot less useful: network architects would be guided much better if you made specific recommendations (specifically, in Sec. 7, "Mitigation") and graded these recommendations as MAY/SHOULD/MUST. I think deployers and architects would expect much more specific treatment of security technologies and how they can/should be applied to DetNet rather than an open-ended discussion that they may be able to apply to their own network, but only after they have themselves gone through a deep dive into the technical options.

One way you may want to improve the "usability" of the document is by adding references from Sec. 7 ("mitigations") to the specific mitigations proposed in the various technology-specific documents: for IP, MPLS, Ethernet etc. That would make the discussion much more concrete. It would also allow users (as well as WG participants) to understand more clearly which security areas are addressed well and which are not. 

* 1. "These DetNet technologies have not previously been deployed together on a wide area IP-based network". Referring to the previous paragraph, I think you mean to say, "DetNet technologies have not previously been deployed together with a wide area IP-based network"

* "primarily concerned with denial-of service prevention" - this paragraph seems to assume orthogonality/composability of architectural elements that appears somewhat naive. Can we ensure basic security concerns (confidentiality, integrity) on DetNet networks using standard mechanisms, such as TLS/DTLS or IPsec while retaining the "deterministic" properties? Even if this is the case, it needs to be mentioned explicitly. For example, throttling or retry mechanisms might well interact badly between security protocols and the underlying transport.

* 3.3 "integrity of the values in any header" - please provide a reference to a recommendation on how to protect these values.

* 3.4: we punt the response of the network in the face of malicious actions (e.g., a replayed, out-of-time-window packet) to admin configuration. DetNet specifies (or at least refers to) queuing and shaping algorithms in RFC 8655, Sec. 4.5. I would expect a similar reference to attack-resistant algorithms, instead of having the admin choose from a menu of choices that appear to be simplistic - drop the packet or shut down the link.

* 4: Sec. 7.1 of the DiffServ RFC has a different threat model in mind. The introductory sections to the current document make it clear that we care about mixed IT/OT networks ("insider threat") whereas DiffServ assumes a secure network that can be policed on the perimeter, in boundary nodes. I think the reference to "internal link[s] that cannot be adequately secured against modification of DSCP values" is awkward - in a campus network, this would be *any* link, because there is no perimeter.

* 5.2.2: as well as simple elimination of packets from the flow.

* 5.3 (table): an Internal, on-path attacker can inject some signaling packets. Also, isn't a DDoS attack from the outside potentially an "inter-segment attack" by an External attacker?

* 7.2: the section on sequence number integrity appears to assume that this protection is achieved by using encryption. This is not necessarily true, protocols such as ESP-null (or the deprecated AH) integrity-protect packets without encrypting them. Similar solutions are available in MACsec.

* 7.4: if dummy packet insertion is presented as a mitigation against reconnaissance (e.g. now my flow doesn't look like VoIP any more), I would appreciate a reference to a proposed algorithm and a demonstration that this really works. Personally I am skeptical of that.

* 7.5.1: I suggest to add to the end of the paragraph "However, if secret symmetrical keys are used": Group key management protocols can be used to automate management of such symmetric keys, see [draft-ietf-ipsecme-g-ikev2-01] for an example in the context of IPsec.

* 7.6: and if we are worried about recon, then signaling needs to be encrypted, not just integrity-protected.

* 8.1.3: this is phrased in a negative way, essentially saying, "the network should accommodate insecure packet flows". A more positive way to address the same issue would be "deployments should allow for dynamic and secure registration of new devices, and possibly manual deregistration of retired devices."

* 8.1.4: this short section is totally opaque. What is the threat? What are deployers supposed to do about it? The same in fact applies to 8.1.5.

* 8.1.8: I would have liked to see treatment of the more complicated issues, such as IT packets that need to "cross the line" into OT. Are there application-level dependencies on the IT network? For example, does the OT network need to use the IT network for DNS or OAM services? If such dependencies exist, how are malicious packet flows handled?

* 8.1.11: this begs the question: are there unambiguous specifications of the DetNet security mechanisms, so as to enable interoperability?

* 8.1.21: This section ends on a pessimistic note. It doesn't have to be that way... One way to deal with your conclusions is for network designers to adopt a standard risk-based approach, where only those attacks are mitigated whose potential cost is higher than the cost of mitigation.

* Sec. 9, when discussing IPsec, again omits to mention that packet integrity protection *without* encryption is an option.