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

[Roman Danyliw via Datatracker <[e-mail]>]

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