Subject: [Detnet] Roman Danyliw's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 06 Apr 2022 06:22:47 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-detnet-bounded-latency-09: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Watson Ladd for the SECDIR review.

** Section 8.  It wasn’t clear to me that outright control of a resource (e.g.,
relay) was needed impact the latency bound calculation.  Recommending a bit
more flexibility on what an attack would take:

OLD
   but may have the
   ability to control some resources within the boundary of the DetNet
   domain.

NEW

but may have the ability to control or change the behavior of some resources
within the boundary of the DetNet domain.

** Section 8.

An example of such attacks is to make some
   traffic sources under the control of the attacker send more traffic
   than their assumed T-SPECs.  This type of attack is typically avoided
   by ingress conditioning at the edge of a DetNet domain

If a traffic source _in the DetNet_ is induced to send more than their T-SPEC,
how does ingress conditioning at the edge help with mitigation?  This DetNet
node is already in the DetNet domain.

** Section 8.  Figure 1 presented a taxonomy of delays (#1 – 6) for the timing
model.  It would be helpful to explicitly extend this taxonomy to a threat
analysis, or to rule out that mitigating certain threats are out of scope.  For
example:

-- 1: Output delay: ?
-- 2: Link delay: somewhat covered by the discussion of timing; and violating
T-SPECs. -- 3: Frame preemption delay: ? -- 4: Processing delay: ? -- 5:
Regulation delay: ? -- 6: Queuing delay: covered by “Some queuing mechanisms
require time synchronization and operate correctly only if the time
synchronization works correctly ...”

---

From: Mohammadpour Ehsan <[email-masked]>
Date: Fri, 8 Apr 2022 14:44:41 +0000

Dear Roman,

Thanks for your comments. Please find my responses as follows.

OLD
  but may have the

NEW

We have changed the text according to your recommendation.

** Section 8.

Between any traffic source and the rest of DetNet, there is source policing (aka ingress conditioning). Therefore, the traffic generated by any DetNet source passes a traffic policer. If the source sends excessive traffic, it is not allowed to the network as it affects other DetNet flows (may cause QoS violation). Hence, such an attack, mentioned by you, is also mitigated.

-- 1: Output delay: ?
synchronization works correctly …”

The delays (1,3,4) are technology-dependent and changing them requires physical access to a DetNet node. This is covered in paragraph 3 of this section:
"Latency bound calculations use parameters that reflect physical quantities. If an attacker finds a way to change the physical quantities unknown to the control and management planes the latency calculations fail and may result in latency violation and/or congestion losses”

Also, an attacker can manipulate this information in the control plane (delays 1,3,4 as well as the parameter of the regulators_ delay 5); this may lead to wrong computation of delay bounds. Such security considerations should be taken care of by the control plane documents and are out of scope of this document.

Best,
Ehsan

--
Ehsan Mohammadpour
PhD candidate at Swiss Federal Institute of Technology (EPFL)
EPFL EDIC PhD student representative
IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
https://people.epfl.ch/ehsan.mohammadpour

On 6 Apr 2022, at 17:52, Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

OLD
  but may have the

NEW

** Section 8.

-- 1: Output delay: ?