Subject: [Detnet] Eric Rescorla's No Objection on draft-ietf-detnet-use-cases-19: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 15:18:21 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-detnet-use-cases-19: 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/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-use-cases/

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

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3472

COMMENTS
S 3.1.1.1.5.
>      |          Availability          |             99.9999              |
>      |    precise timing required     |               Yes                |
>      | Recovery time on node failure  |     less than 50ms - hitless     |
>      |     performance management     |          Yes, Mandatory          |
>      |           Redundancy           |               Yes                |
>      |          Packet loss           |               0.1%               |

Where do these packet loss numbers come from? It seems like if you had
a .1% chance of systems damage, that would be bad,

S 3.3.2.2.
>      physical networks leveraging different technologies across the
>      country: an optical network and a microwave network for instance.
>      Each protection and automatism system between two points has two
>      telecommunications circuits, one on each network.  Path diversity
>      between two substations is key.  Regardless of the event type
>      (hurricane, ice storm, etc.), one path shall stay available so the

You may want to say "needs to"

S 3.3.3.
>      concepts of:
>   
>      o  Integrity : data cannot be altered undetectably
>   
>      o  Authenticity : the telecommunications parties involved must be
>         validated as genuine

FWIW, we typically refer to this as "data origin authentication" and
obviously it's kind of inseparable from integrity

S 5.1.
>      These networks may also contain very large numbers of devices, for
>      example for factories, "big data" acquisition, and the IoT.  Given
>      the large numbers of devices installed, and the potential
>      pervasiveness of the IoT, this is a huge and very cost-sensitive
>      market.  For example, a 1% cost reduction in some areas could save
>      $100B

This seems like a surprisingly high number given that 100B/.01 ~= 10
trillion and the entire US GDP is 20 trillion.

S 7.2.1.
>      "n", then the next cycle ("n+1") must be lossless).  After two or
>      more consecutive packet losses the network may be considered to be
>      "down" by the Application.
>   
>      As network downtime may impact the whole production system the
>      required network availability is rather high (99,999%).

Nit: you are using period-based decimals elswehre.

S 8.1.
>      where the final product (e.g.  Copper) is obtained.  Although the
>      operation is autonomous, the tracks are remotely monitored from a
>      central facility.
>   
>      In pit mines, the monitoring of the tailings or mine dumps is
>      critical in order to avoid any environmental pollution.  In the past,

Not a networking issue, but my understanding is that pit mines in
practice generate quite a bit of pollution.

S 9.1.1.
>   9.1.1.  Blockchain Operation
>   
>      A 'block' runs as a container of a batch of primary items such as
>      transactions, property records etc.  The blocks are chained in such a
>      way that the hash of the previous block works as the pointer header
>      of the new block, where confirmation of each block requires a

This is not maximally clear. The relevant point is that block N+1
transitively vouches for blocks N and before.

S 9.1.2.
>      items and the blocks to the other nodes.
>   
>      When a node initiates, it first requests the other nodes' address
>      from a specific entity such as DNS, then it creates persistent
>      connections each of with other nodes.  If node A confirms an item, it
>      sends the item to the other nodes via the persistent connections.

This is certainly one design, but it's not the only one.

S 9.3.
>   9.3.  Private Blockchain Future
>   
>      Blockchain system performance can be greatly improved through
>      deterministic networking service primarily because it would
>      accelerate the consensus process.  It would be valuable to be able to
>      design a private blockchain network with the following properties:

Hmm... I'm not sure how persuaded I am by this. Generally the rate of
block generation is quite low, compared to any plausible network.

S 11.1.8.
>   
>   11.1.8.  Mix of Deterministic and Best-Effort Traffic
>   
>      DetNet is intended to support coexistance of time-sensitive
>      operational (OT) traffic and information (IT) traffic on the same
>      ("unified") network.

This seems potentially inconsistent with 11.1.6. Perhaps you mean that
11.1.6 only applies to OT?

S 11.5.
>      addition to arriving with the data content as intended, the data must
>      also arrive at the expected time.  This may present "new" security
>      challenges to implementers, and must be addressed accordingly.  There
>      are other security implications, including (but not limited to) the
>      change in attack surface presented by packet replication and
>      elimination.

Do these requirements impose new requirements on the cryptographic
algorithms used to verify traffic?