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

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-detnet-architecture-11: 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:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I note that the DETNET WG is explicitly chartered with a work item for the
"overall architecture: This work encompasses ... and security aspects".
It seems incomplete to specify an architecture for a topic such as
deterministic networking without specifically considering what threats are
and are not in scope to be protected against.  Some easy questions should
be whether the system is expected to be robust in the face of an attacker
that generates non-DetNet traffic?  Or an attacker that generates DetNet
traffic in excess of reservations?  It can even be a fine engineering goal
to produce a solution that only protects against media corruption and
hardware crashes and leaves active attacks out of scope, but the actual
intended scope of the work needs to be clear.  At the other end of the
spectrum, protecting against as potent an attacker as a malicious traffic
policer is probably a lost cause, especially if the policer is authorized
to direct remote nodes to take action to terminate "misbehaving" flows.

The referenced draft-ietf-detnet-security is not at a comparable maturity
level to this document and also fails to present a clear threat model for
the DetNet architecture.  (The section entitled "Threat Model" reads as
more of a taxonomy of threats than a model for what threats are and are not
to be addressed.)  It also presents the usage of cryptographic mechanisms
as mitigation techniques without provisioning for the prerequisties of such
mechanisms (e.g., using HMAC for message integrity protection without
mention of infrastructure for distributing the keys for keying the HMAC).


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

I agree with Alexey that Informational would (also) be a fine status in
which to publish this document.

Abstract

                                 DetNet operates at the IP layer and
   delivers service over sub-network technologies such as MPLS and IEEE
   802.1 Time-Sensitive Networking (TSN).

I don't know what "sub-network technologies" means.  (Should I?  Is it
defined somewhere we can reference?)

More generally, is DetNet supposed to be a "sub-layer" and/or "sub-network"
that lies between specific layers or classes of layer?  Does DetNet
itself have component "sub-layers" that provide distinct DetNet
functionality?  These are good questions to address early on in the
document so the reader is familiar with the concepts as they progress
through the document.

Section 1

                          DetNet is for networks that are under a single
   administrative control or within a closed group of administrative
   control; these include campus-wide networks and private WANs.  DetNet
   is not for large groups of domains such as the Internet.

side note: Campus-wide networks at educational institutions are basically
guaranteed to have untrusted entities participating in them, just as a
backdrop for security considerations.

Section 3.1

                        This mechanism distributes the contents of
   DetNet flows over multiple paths in time and/or space, so that the
   loss of some of the paths does need not cause the loss of any

The failure models for which this statement is absolutely true as opposed
to probabilistically true seem rather unrealistic models of real physical
systems.

Section 3.2.1.1

   The primary means by which DetNet achieves its QoS assurances is to
   reduce, or even completely eliminate packet loss due to output packet
   contention within a DetNet node as a cause of packet loss.  [...]

editing error?

                                     Note that App-flows are generally
   not expected to be responsive to implicit [RFC2914] or explicit
   congestion notification [RFC3168].

I note that the word "implicit" does not appear in RFC 2914; it may be
worth a bit more detailed of a mapping from concept to reference.
(This text/reference also appears in Section 4.3.2.)

Section 3.2.1.2

                                                                   In
   general, users are encouraged to use, instead of, "do this when you
   get the packet," a combination of:

It seems that an architecture would be within its rights to *mandate* such
application design, rather than just encourage it.  What sorts of
exceptions would cause us to not want to mandate this design?

Section 3.2.2.2

Please expand SRLG (it is only used once, so the abbreviation itself may
not be needed at all).

Section 3.2.3

   Out-of-order packet delivery can be a side effect of distributing a
   single flow over multiple paths especially when there is a change
   from one path to another when combining the flow.  [...]

nit: comma before "especially".

   Resource allocation
           The DetNet forwarding sub-layer provides resource allocation.
           See Section 4.5.  The actual queuing and shaping mechanisms
           are typically provided by underlying subnet, these can be

nit: is this usage of "subnet" common?
Also, this comma looks to be a comma splice.

           closely associated with the means of providing paths for
           DetNet flows, the path and the resource allocation are
           conflated in this figure.

nit: Hmm, actually, is this comma *also* a comma splice?

   Operations, Administration, and Maintenance (OAM) leverages in-band
   and out-of-band signaling that validates whether the service is
   effectively obtained within QoS constraints.  [...]

nit: is there a singular/plural mismatch here ("the service"/"service" vs.
"effectively within"/"effectively obtained within")?

Section 4.1.1

This figure would have helped me a lot several sections earlier.

Section 4.1.2

   A "Deterministic Network" will be composed of DetNet enabled end
   systems, DetNet edge nodes, DetNet relay nodes and collectively
   deliver DetNet services.  DetNet relay and edge nodes are

Nit: I think this is intended to be:
A "Deterministic Network" will be composed of DetNet-enabled end
systems, DetNet edge nodes, and DetNet relay nodes, which collectively
deliver DetNet services.  DetNet relay and edge nodes are

                                                             Examples of
   sub-networks include MPLS TE, IEEE 802.1 TSN and OTN.  [...]

nit: are these sub-networks or protocols used by sub-networks?

   Distinguishing the function of two DetNet data plane sub-layers, the
   DetNet service sub-layer and the DetNet forwarding sub-layer, helps
   to explore and evaluate various combinations of the data plane
   solutions available, some are illustrated in Figure 4.  This

nit: this last comma is a comma splice.

   There are many valid options to create a data plane solution for
   DetNet traffic by selecting a technology approach for the DetNet
   service sub-layer and also selecting a technology approach for the
   DetNet forwarding sub-layer.  There are a high number of valid
   combinations.

nit: I think "large number" is more conventional prose.

Section 4.3.1

I think I'm confused about how, for these flows that "require the <foo>
feature", whether that means that the DetNet implementation must provide
<foo>, or that it is required for the application to have implemented the
<foo> feature.  A mapping (if it makes sense) to the categorization of end
systems in Section 4.2.1 would be a big help.

Section 4.3.2

   Asynchronous DetNet flows are characterized by:

   o  A maximum packet size;

   o  An observation interval; and

   o  A maximum number of transmissions during that observation
      interval.

Is there necessarily only a single tier of observation interval/rate?
(E.g., could there be a burst cap in a small interval and then a lower
overall baseline rate over large intervals?)

                     That is, while any useful application is written to
   expect a certain number of lost packets, the real-time applications
   of interest to DetNet demand that the loss of data due to the network
   is a rare event.

(I might even go with "vanishingly rare".)

Section 4.4.1

(Is there a standard reference for "Northbound"?  I know we're all used to
it, but it's probably best to have a reference if we can.)

Section 4.4.2

                                         The deterministic sequence can
   typically be more complex than a direct sequence and include
   redundancy path, with one or more packet replication and elimination
   points.  [...]

nit: "redundancy paths", plural?

Section 4.8

How does *provisioning* require knowledge of *dynamic* state?

Section 4.9

Does aggregation like this pose a risk of all the aggregatees getting
affected when one exceeds their allocation substantially (so as to also
cause the aggregate to exceed the aggregate's allocation)?

Section 6

The ability for an attacker to use QoS markings as part of traffic
correlation/inspection is not new with DetNet, but is probably still worth
mentioning explicitly.