Last Call Review of draft-ietf-detnet-security-12

Request Review of draft-ietf-detnet-security
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-10-27
Requested 2020-10-13
Authors Ethan Grossman, Tal Mizrahi, Andrew Hacker
Draft last updated 2020-10-19
Completed reviews Rtgdir Last Call review of -10 by Adrian Farrel (diff)
Genart Last Call review of -12 by Russ Housley
Secdir Last Call review of -12 by Yaron Sheffer
Assignment Reviewer Russ Housley 
State Completed
Review review-ietf-detnet-security-12-genart-lc-housley-2020-10-19
Reviewed rev. 12
Review result Almost Ready
Review completed: 2020-10-19


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

Document: draft-ietf-detnet-security-12
Reviewer: Russ Housley
Review Date: 2020-10-19
IETF LC End Date: 2020-10-27
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns:

Abstract: Latency is discussed in the Abstract, but jitter does not
come up until much later in the document.

Section 1: Latency is discussed in the Introduction, but jitter does
not come up until much later in the document.

Section 4 says: "the DiffServ draft Security discussions".  A
reference is clearly missing.  Looking at the list of documents
associated with the DetNet WG, it is not clear what this is
supposed to point to.

Section 7.2 says: "hash-based Message Authentication Code (MAC)".
Any MAC is useful here, not just hash-based ones.  Please drop

Minor Concerns:

Section 5.1 says: "otherwise independent DetNet network domains are
connected", but "domain" is not defined.  I am guessing that a "domain"
is a DetNet that has one administrator, but I am not sure.  Also, I am
not sure this detail is even relevant to the point of the paragraph. 
Maybe "otherwise independent DetNet networks are connected" would be

Section 5.2.6 introduces the term "L3/L4 headers", and it is not really
defined.  Further this is not used outside of this section.  I suggest
that the section be reworded to avoid a new term that is not needed

Section 6, Figure 2: It is unclear to me how block chain fits with the
other things listed in this table.  Does this list come from another
document?  If so, please provide that reference.

Section 7.3 refers to "IPsec or MACsec".  Please add references for both
IPsec and MACsec.

Section 7.5.1 refers to "TLS and IKE".  Please add references for both
TLS and IKE.

Section 7.7 refers to "TSN".  Please add references for TSN.

Section 8.1.23 talks about "misbehaving component".  I think it should
be expanded to talk about more than one misbehaving component, and it
should be clear whether the misbehavior can come from an adjacent
component or it can be many hops away.

Section 9 says: "... not a transport protocol (e.g., neither TCP nor
UDP, etc.) ...".  The real point here is that the identifier for the
actual transport protocol that is being used is encrypted.  Listing
possible identifier values makes it harder to figure this out.

Section 13: Please provide the same information in the same format for
each of the contributors.


Throughout: s/DetNet network/DetNet/

Abstract says: "This document also addresses DetNet security
considerations specific to the IP and MPLS data plane technologies
thereby complementing the Security Considerations sections of the
various DetNet Data Plane (and other) DetNet documents."  The last part
of this sentence does not make sense to me; it has too many DetNets.

Section 1 says:
   A general introduction to
   the DetNet architecture can be found in [RFC8655] and it is also
   recommended to be familiar with the DetNet Data Plane
   [I-D.ietf-detnet-data-plane-framework] and Flow Information Model
To avoid confusion with "recommended", I suggest:
   Readers can find a general introduction to the DetNet
   architecture in [RFC8655], the DetNet Data Plane in
   [I-D.ietf-detnet-data-plane-framework], and the Flow
   Information Model in [I-D.ietf-detnet-flow-information-model].

Section 1: s/of each packet's data'/of the data in each packet/

Section 3.1: s/BW/bandwidth/

Section 4: s/Security sections/Security Considerations sections/

Section 5.1: s/DetNet networking islands/DetNet islands/

Section /"new"/new/

Section 5.3, Figure 1: Please fix the header of the table.

Section 6: s/in the table below/in Figure 2/

Section 6.8: please spell out "time sync".

Section 7.5: s/end-to- end encryption/end-to-end encryption/

Section 9: s/Layer-2/Layer 2/

IDnits reports:

  -- Obsolete informational reference (is this intentional?): RFC 4447
     (Obsoleted by RFC 8077)


Throughout: Avoid possessive to aid readers whose first language is
not English.  For example, I suggest changing "component's data plane"
to "data plane of the component".  As another example, please change
"flow's budget" to "budget for the flow".  As yet another example,
please change "the DetNet's handling of IT traffic" to "the handling
of IT traffic in the DetNet".  As a final example, please change "that
network's data plane" to "the network data plane".  There are many
more uses of possessive, and I hope you will consider each one.

Throughout: The authors use "this memo" and "this document".  Please
pick one and use it everywhere.