Re: [Detnet] Secdir last call review of draft-ietf-detnet-security-12

[Ethan Grossman <[e-mail]>]

Hi All,
Yaron has proposed that we make the DetNet Security draft Normative rather
than Informational, and that we grade recommendations  as MAY/SHOULD/MUST.
Clearly this needs to be considered by the WG and Chairs, and the intent of
this email is to start that discussion. I personally don't have a strong
stance on it; I'm willing to take on the work of driving the requested
changes if the WG feels this is appropriate. Thoughts?
Thanks,
Ethan (as DetNet Security draft editor)

On Thu, Nov 5, 2020 at 6:21 AM Yaron Sheffer via Datatracker <
[e-mail]> wrote:

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