[Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 07 January 2021 15:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: detnet@ietf.org
Delivered-To: detnet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 612A43A11D7; Thu, 7 Jan 2021 07:02:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-detnet-security@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <161003177336.17207.9873492659985883272@ietfa.amsl.com>
Date: Thu, 07 Jan 2021 07:02:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/HvIYQtTRzjSSZ-LhuzIrjuMEoII>
Subject: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 15:02:53 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-detnet-security-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


We say that we adhere to the guidelines of RFC 3552, yet we do not
mention that it may be impossible to achieve our goals "in the face of a
highly capable adversary, such as the one envisioned by the Internet
Threat Model of BCP 72 [RFC3552] that can arbitrarily drop or delay any
or all traffic" (to quote from a recent DetNet RFC that does cover this
topic, RFC 8939).  I think that in order to fully adhere to RFC 3552, we
need to be more explicit about how we have to assume a reduced attacker
capability set in order to make any progress at all.  A good place for
this discussion would be near where we state that security a DetNet
starts with a scrupulously well-designed and well-managed engineered
network in Section 1 -- the goal of having the well-managed network is
to exclude some of the more powerful adversary capabilities from the
Internet Threat Model.


I agree with the secdir reviewer that additional linkage between threats
that the potential mitigations for them would be useful, albeit somewhat
time-consuming to add.

This is much-improved from the last time I looked at it; thank you for
continuing to make improvements!  I do still have a sizeable number of
comments, though; hopefully they will help to make further improvements.

I suspect that we would do well to reiterate the theme that has appeared
in the security considerations of the several most recent detnet RFCs,
along the lines of "achieving the goals of detnet may not be possible in
the face of a highly capable adversary, such as the one envisioned by
the Internet Threat Model of BCP 72 [RFC3552] that can arbitrarily drop
or delay any or all traffic", especially since we say that we otherwise
adhere to RFC 3552's guidelines.  A good place for this discussion would
be near where we state that security a DetNet starts with a scrupulously
well-designed and well-managed engineered network in Section 1 -- the
goal of having the well-managed network is to exclude some of the more
powerful adversary capabilities from the Internet Threat Model.  We
should say that explicitly.

Section 2

   Resource Segmentation Used as a more general form for Network

nit: missing colon

Section 3.3

   be protected by using MACsec [IEEE802.1AE-2018].  Similary, from the
   sequence number injection perspective, it is no different from any
   other protocols that use sequence numbers.

Many other protocols that use sequence numbers are in practice
vulnerable to sequence number injection.  Having specific references to
other protocols that are protected against such injection seems like it
would be useful.

Section 4

                                                        However DetNet
   also introduces timing and other considerations which are not present
   in DiffServ, so the DiffServ security considerations are necessary
   but not sufficient for DetNet.

In my experience, security considerations are typically statements of
fact about the properties of a protocol/system, as opposed to
requirements for secure operation; in that context it is better to say
that the diffserv security considerations are a subset of the detnet
security considerations, as opposed to the current "necessary but not
sufficient" phrasing.

                                    In DetNet, there are similar
   consequences to DiffServ for lack of detection of, or incorrect
   handling of, packets with mismarked DSCP values, and many of the

If I understand correctly, the detection/handling in question here is
specifically at ingress to the domain?

Section 5.1

[I'll note for completeness that I still would prefer this to be called
a taxonomy of threats rather than a threat model, but we've had the
conversation about how this formulation is analogous to that of RFC 7384
and there's nothing left to say.  No response needed; I'm just recording
that we agreed to disagree.]

   o  Internal vs. external: internal attackers either have access to a
      trusted segment of the network or possess the encryption or
      authentication keys.  External attackers, on the other hand, do
      not have the keys and have access only to the encrypted or
      authenticated traffic.

I think it is common to use "external" to refer to attackers that are
entirely outside of a domain and are limited to attmping to send packets
into the domain, with no visibility into legitimate traffic inside the
domain.  The description here suggests that the boundary between
"internal" and 'external" is more of a logical one, perhaps relating to
access to physical packets (in encrypted form) vs unprotected packts (as
available to internal systems), but perhaps there is intended to also be
a "secure network" where the physical packets contain the logical data
but are physically inaccessible to the attacker.  Section 5.3 alludes to
the existence of some "security mechanism" that provides the boundary
between external and internal attackers, but leaves the actual nature of
the boundary unclear, for me.
[This looks like it's basically the same as Roman's first discuss point,
which I support.]

   o  On-path vs. off-path: on-path attackers are located in a position
      that allows interception and modification of in-flight protocol
      packets, whereas off-path attackers can only attack by generating
      protocol packets.

We sometimes differentiate between (e.g.) "active" or "passive" on-path
attackers, where interception/viewing is done in either form but
modification only done in the "active" form.

Section 5.2.3

I don't understand why the section title includes "Resource
Segmentation"; the scenario being described seems to discuss risks that
are present when resources are *not* properly segmented.  Resource
Segmentation by itself should not be a threat in this regard.

   An attacker can inject traffic that will consume network resources
   such that it affects DetNet flows.  This can be performed using non-
   DetNet traffic that indirectly affects DetNet traffic (hardware
   resource exhaustion), or by using DetNet traffic from one DetNet flow
   that directly affects traffic from different DetNet flows.

I don't understand what is meant by "detnet traffic from one flow that
directly affects traffic from different detnet flows".  How might this


      bridge, the flow is hijacked by the attacker.  It is now posible
      to either replace en route packets with malicious packets, or
      simply injecting errors, causing the packets to be dropped at
      their destination.

nit: s/injecting/inject/


   An attacker can subvert a controller, or enable a compromised
   controller to falsely represent itself as a controller so that the
   network nodes believe it to be authorized to instruct them.

I can't tell if "compromised controller" was a typo that was supposed to
refer to some non-controller class of entity, so that the false
representation as a controller is a significant change in node

Section 5.2.6

   A passive eavesdropper can identify DetNet flows and then gather
   information about en route DetNet flows, e.g., the number of DetNet
   flows, their bandwidths, their schedules, or other temporal
   properties.  [...]

I suggest "other temporal or statistical properties" to encompass things
like latency and jitter, which are only in some limited sense temporal

   DetNet flows are typically uniquely identified by their 6-tuple, i.e.
   fields within the IP header, however in some implementations the flow
   ID may also be augmented by additional per-flow attributes known to
   the system, e.g. above the IP-layer.  [...]

pedantically, the ports in the 6-tuple are also above the IP layer.

                                         For the purpose of this
   document we assume any such additional fields used for flow ID are
   encrypted and/or integrity-protected from external attackers.

I suggest adding a note that existing OT protocols designed for use on
dedicated secure networks may not intrinsically provide such protection,
in which case IPsec or transport layer security mechanisms may be
needed.  (I do see a note on a similar or more generic topic already in
§6, but don't think there is harm in having another one.)

Section 5.3

How can an off-path attacker perform a delay attack?

Section 6

What is the distinction between "Health and Safety" and "People Well

   Safety, People well being (People WB), Affect on a single
   organization, and affect on multiple organizations.  Recovery

nit: s/Affect/Effect/ in both lower and upper case forms (the table,
fortunately, is already correct)

Why is M2M control listed as only having low impact from data integrity?
I would have thought that integrity of the control plane information
would be pretty important.

Section 6.1.1

   For a single path scenario, disruption is a real possibility, whereas
   in a multipath scenario, large delays or instabilities in one DetNet
   flow can lead to increased buffer and processor resources at the
   eliminating router.

nit: I think s/resources/resource consumption/

Section 6.2.1

I think it might be more interesting to mention the scope of potential
harm when the corrupted or modified payloads are interpreted, rather
than just saying that they could be modified.

Drvyion 6.3.2

I think the primary concern here is that there will be skew between the
"reality" in the individual nodes and the expected state known to the
controller, such that when the controller attempts to make changes in
the future the actual actions will differ.  The specifics of how the
initial skew occurs is less interesting, and essentially equivalent to
the spoofing case.

Section 6.4.x

I think the referenced coverage is perhaps too brief to be useful.

Section 6.8

In the context of this section, we should be talking about the
discussion or description of the impact of attacks; how attacks are
"addressed" would be analogous to the mitigations that we cover in §7.

Section 7.2

      An integrity protection mechanism is designed to counteract header
      modification attacks where a Message Authentication Code (MAC) is
      the most common.  [...]

nit: the "a MAC is most common" seems to bind to "header modification
attacks", not "integrity protection mechanism; I suggest
      An integrity protection mechanism is designed to counteract header
      modification attacks.  A Message Authentication Code (MAC) is
      the most common such mechanism.

                        The MAC can be distributed either in-line
      (included in the same packet) or via a side channel.  Due to the
      nature of DetNet traffic.  [...]

nit: incomplete sentence?

      replication attacks (see Section 5.2.2 and Section 5.2.4).  This
      MAC usage needs to be part of a security association that is
      established and managed by a security association protocol (such
      as IKEv2 for IPsec security associations).  Integrity protection

BCP 107 might be a good reference here.

      sequence numbers are not modifiable.  Thus, sequence numbers can
      be protected by using encryption, or by a MAC without using

I suggest s/encryption/authenticated encryption/; an unqualified
"encryption" is easy to interpret as something like a stream or block
cipher mode without integrity protection, which is malleable without

      encryption.  Between the adder and remover there may or may not be
      replication and elimination functions.  The elimination functions
      must be able to see the sequence numbers.  Therefore, if
      encryption is done between adders and removers it must not obscure
      the sequence number.  If the sequence removers and the eliminators
      are in the same physical component, it may be possible to obscure
      the sequence number, however that is a layer violation, and is not
      recommended practice.  [...]

It would also be technically feasible (but very ill-advised) to share
the encryption key with the elimination function and continue to use
encrypted sequence numbers.  This is ill-advised because two-party
security with a shared symmetric secret provides much stronger peer
authentication than group seciryt with a shared symmetric secret.

Section 7.4

I suggest reiterating that it is expected that cryptographic
confidentiality protection is applied to traffic; dummy traffic is
generally ineffectual when the plaintext is visible to the attacker.

Section 7.5

      Note that reconnaissance is a threat that is not specific to
      DetNet flows, and therefore reconnaissance mitigation will
      typically be analyzed and addressed by a network operator
      regardless of whether DetNet flows are deployed.  [...]

nit: I suggest s/addressed/provided/ since "addressed" usually implies
that the thing in question is a problem that needs to be mitigated, but
we are describing the mitigation itself.

Section 7.5.1

   Any compute time which is required for encryption and decryption
   processing ('crypto') must be included in the flow latency
   calculations.  Thus, crypto algorithms used in a DetNet must have
   bounded worst-case execution times, and these values must be used in
   the latency calculations.

(In general, crypto operations should have constant execution times, to
avoid side channel leakage.)

   If crypto keys are to be regenerated over the duration of the flow
   then the time required to accomplish this must be accounted for in
   the latency calculations.

[In contrast to my previous comment, key generation is a cryptographic
operation that is frequently not possible to implement in constant time,
most notably thoguh not exclusively for RSA key pairs.]

Section 7.7

      Making DPA measurement results available at the right place(s) and
      time(s) to effect timely response can be challenging.  Two
      notification mechanisms that are in general use are Netconf/YANG
      Notifications (e.g.  [RFC5880]) and the proprietary local
      telemetry interfaces provided with components from some vendors.

I think that CoAP Observe (RFC 7641) could also apply to such scenarios,
but I don't have enough information to be able to say whether it is "in
general use" for this purpose.

      Performance analytics can be used to mitigate various attacks,
      including the ones described in Section 5.2.1 (Delay Attack),
      Section 5.2.3 (Resource Segmentation Attack), and Section 5.2.7
      (Time Synchronization Attack).

Mitigate, or just detect?  (May also affect Figure 3.)

Section 7.8

In my mind the "Replication: increased attack surface" attack included
the potential for the replicated data stream to be available (and thus
subject to reconnaissance) in more places, in addition to there being
more devices relevant to a given flow and susceptible to attack.  In
that case, encryption would also be a relevant mitigation, but it is not
currently listed as one.

We list "control message protection" as a potential mitigation for
several rows in the table, but I do not see where there is prose
discussing what that mitigation entails.

Section 8.1.1

Some subnetwork layers other than ethernet might have additional attacks
and impacts that are not relevant to ethernet.  A prominent example
would be radio technologies, where the broadcast domain is "anyone with
an antenna", though this is probably not the only example of affected
subnetwork technology or additional attack/impact.

Section 8.1.3

   To mitigate this situation, deployments should provide a method for
   dynamic and secure registration of new components, and (possibly
   manual) deregistration of retired components.  This would avoid the
   situation in which the network must accommodate potentially insecure
   packet flows from unknown components.

[The IETF has specified a number of enrolment and bootstrapping
protocols (EST, BRSKI, SZTP, CMC, CMP, etc.), though it's not clear that
it's helpful to informatively reference any particular ones, here.]

Section 8.1.5

   Please note that although there are no entries in the L2 and L3
   Integration line of the Mapping Between Themes and Attacks table
   Figure 4, this does not imply that there could be no relevant attacks
   related to L2-L3 integration.

Very true -- thank you!

Section 8.1.6

   It may be that such attacks are limited to Internal on-path
   attackers, but other possibilities should be considered.

Why is this listed as "may be"?  What factors influence whether it can
or cannot be the case?

Section 8.1.8

   However the handling of IT traffic by the DetNet may not (by design)
   be as resilient to DOS attack, and thus designers must be otherwise
   prepared to mitigate DOS attacks on IT traffic in a DetNet.

I don't think I understand what this is trying to say.  Both for what
behavior is "by design" and what designers are expected to do.

Section 8.1.10

   is made available on the network for best-effort traffic.  However,
   note that security considerations for best-effort traffic on a DetNet
   network is out of scope of the present document, provided that such
   an attack does not affect performance for DetNet OT traffic.

nit: there's no antecedent for "such an attack" that I can see.

Section 8.1.13

The usage of 'secure" and "security layer" in this section are pretty
vague as to what properties are implied.  Can we be more precise?

Section 8.1.15

   An attack that takes advantage of flaws (or even normal operation) in
   the device drivers for the various links (through internal knowledge
   of how the individual driver or firmware operates) could take
   proportionately greater advantage of this topology.

I don't really understand what is meant by "proportionately greater
advantage of this topology"?  What is being compared to?

Section 8.2

Is a delay attack relevant for deterministic flows?

How is a reconnissance attack relevant for low latency?

Section 9.2

   The operation of DetNet over an MPLS network is modeled on the
   operation of multi-segment pseudowires (MS-PW).  Thus for guidance on
   securing the DetNet elements of DetNet over MPLS the reader is
   referred to the MS-PW security mechanisms as defined in [RFC8077],
   [RFC3931], [RFC3985], [RFC6073], and [RFC6478].

I'm not sure I saw which security mechanisms are supposed to be provided
by RFC 3985 and/or RFC 6478 (though I only very quickly skimmed through

   Further consideration of protection against dynamic attacks is work
   in progress.  New work on MPLS security may also be applicable, for
   example [I-D.ietf-mpls-opportunistic-encrypt].

I got excited by the draft-ietf-mpls-opportunistic-encrypt reference,
but following the link suggests that the draft has been expired for
three years.  Is it still appropriate to refer to it as "new work" or
"work in progress"?

Section 12

Traffic analysis and similar side channels can still cause there to be
privacy considerations even when traffic is encrypted.