Reviewer: Yaron Sheffer
Review result: Has Issues
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
