Re: [Detnet] Benjamin Kaduk's No Objection on draft-ietf-detnet-data-plane-framework-04: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Balázs,

Not many things need a reply, so just a few notes inline...

On Tue, Apr 28, 2020 at 09:15:06AM +0000, Balázs Varga A wrote:
> Hi Benjamin,
> Thanks for the review. Comments inline marked with <BV>.
> Many thanks
> Bala'zs
> 
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]> 
> Sent: Friday, April 24, 2020 2:41 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Ethan Grossman <[e-mail]>; [e-mail]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-detnet-data-plane-framework-04: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-detnet-data-plane-framework-04: 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-data-plane-framework/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Other than some remarks on the security considerations, I basically just have a bunch of editorial comments.  I've tried to deduplicate with what was already reported by other ADs, but no doubt have kept a few things in that have already been mentioned.
> 
> Section 1
> 
>    The DetNet Architecture models the DetNet related data plane
>    functions decomposed into two sub-layers: a service sub-layer and a
>    forwarding sub-layer.  The service sub-layer is used to provide
> 
> nit: "models" needs two objects to act on/compare, so maybe "as being decomposed into".
> <BV> OK. I will fix this.
> 
>    replicated in other forwarding technologies.  Most of DetNet benefits
>    can be gained by running over a data link layer that has not been
>    specifically enhanced to support all TSN capabilities but for certain
>    networks and traffic mixes delay and jitter performance may vary due
>    to the forwarding sub-layer intrinsic properties.
> 
> nit: I think the "certain networks and traffic mixes" are supposed to be contingent on "a data link layer that [is not a TSN]" but the current text does not quite match that.  Perhaps "certain such networks" is the smallest fix, though it does conflate "data link layer" and "network" in an unfortunate manner.
> <BV> OK. I will fix this simple by "such networks".
> 
> Section 3
> 
>    connectivity function of the forwarding sub-layer.  An example of
>    this is Packet Replication, Elimination, and Ordering functions see
>    Section 4.3.  The ordering (POF) uses sequence numbers added to
> <BV> OK. I will fix this.
> 
> nit: the punctuation around the reference should be tweaked.
> 
>    The method of instantiating each of the layers is specific to the
>    particular DetNet data plane method, and more than one approach may
>    be applicable to a given bearer network type.
> 
> What is a "bearer network"?
> <BV> It means a network that support the DetNet data plane. 
> Agree, somewhat confusing term. I will fix this
> by simple dropping the confusing term "bearer".
> 
> Section 3.1.1
> 
>    applying existing standardized headers and/or encapsulations.  The
>    Detnet forwarding sub-layer may provide capabilities leveraging that
>    same header or encapsulation technology (e.g., DN IP or DN MPLS) or
>    it may be achieved by other technologies (e.g., Figure 2).  DetNet is
> 
> nit: Figure 2 is not a technology; maybe "as shown in Figure 2".
> <BV> OK. I will fix this.
> 
> Section 3.1.2
> 
>    number) in packets.  For example, in DetNet IP, zero encapsulation is
>    used and no sequence number is available, and in DetNet MPLS, DetNet
>    specific information may be added explicitly to the packets in the
>    format of S-label and d-CW [I-D.ietf-detnet-mpls] .
> 
> nit: s/format of/form of/
> <BV> OK. I will fix this.
> 
> Section 3.3
> 
>    Number (for PREOF) for each DetNet flow.  The DetNet Service sub-
>    layer requires both; the DetNet forwarding sub-layer requires only
>    Flow-ID.  Metadata can also be used for OAM indications and
> 
> nit(?): to say that "the service sublayer requires both" to me implies that it always and unconditionally requires both, but IIUC the PREOF functions are optional, and so for a given flow the service sublayer might not require the sequence number.  Perhaps swapping it around to be structured more like "the flow-ID is used by both the service and forwarding sub-layers, but the sequence number is only used by the service layer" would help?
> <BV> OK. I will fix this.
> 
>    Some MPLS examples of implicit metadata include the sequence number
>    for use by the PREOF function, or even all the essential information
>    being included into the DetNet over MPLS label stack (the DetNet
>    Control Word and the DetNet Service label).
> 
> I would have thought that the detnet elements in the label stack would be considered explicit metadata, but perhaps I'm just looking through the wrong lens.
> <BV> Yes, I think we need some fixing here. Sequence number is explicitly encoded in the d-CW. 
> Node local variable for sequence number has the same value. Flow-ID can be encoded in the label 
> stack using multiple labels (i.e., S-label + T-label(s)). Node local variable used as flow_id may differ 
> from values of the label(s). However the flow_id may be encoded in the S-label only and can have
> the same value.
> Proposed fix:
> OLD
>    Some MPLS examples of implicit metadata include the sequence number
>    for use by the PREOF function, or even all the essential information
>    being included into the DetNet over MPLS label stack (the DetNet
>    Control Word and the DetNet Service label).
> NEW
>    An MPLS example of explicit metadata is the sequence number
>    used by the PREOF function, or even the case where all the essential information
>    being included into the DetNet over MPLS label stack (the DetNet
>    Control Word and the DetNet Service label).
> END

This looks good to me, though I think there's a nit to s/being included/is
included/.

> Section 3.4
> 
>    One method of operating an IP DetNet data plane without encapsulation
>    is to use "6-tuple" based flow identification, where "6-tuple" refers
>    to information carried in IP and higher layer protocol headers.
>    General background on the use of IP headers, and "6-tuples", to
>    identify flows and support Quality of Service (QoS) can be found in
>    [RFC3670].  [RFC7657] provides useful background on differentiated
> 
> I did not see the explicit phrase "6-tuple" used in RFC 3670, so I don't think this text is quite right as written.  (7657 does talk about it, but is not currently being referenced for that purpose.)
> <BV> RFC 3670 refers to 5-tuple plus examine DSCP (at the boundary of the DiffServ domain), which is the 6-tuple.

Indeed.  I would suggest using both 3670 and 7657 as references for the
sentence in question, and then start the next one with a non-reference "RFC
7657", though I do not insist on it.

> Section 3.6.1.5
> 
> Is there a difference between "packet-by-packet distribution [of the same flow]" and "packet-by-packet load sharing"?
> <BV> No, they mean the same thing. I will fix text to use "packet-by-packet load sharing" only.

Thanks!

> Section 3.6.1.6
> 
>    as those in use by IP and MPLS networks.  At the Application layer a
>    client of a DetNet service can use existing techniques to detect and
>    monitor delay and loss.
> 
> [Is there a good reference for these "existing techniques"?  I recognize that we shouldn't go into extensive detail here, and absent a single consolidated reference, no-reference may be best.]
> <BV> Application layer techniques are out-of-scope. I would rather not add a reference here.
> 
> Section 3.6.2
> 
>    Service protection allow DetNet services to increase reliability and
>    maintain a DetNet Service Assurance in the case of network congestion
>    or network failure.  Detnet relies on the underlying technology
> 
> My understanding is that the whole point of DetNet was to provide reliability in the face of network congestion (e.g., by resource reservation).  So is it really only the "network failure" case that benefits from service protection?
> <BV> DetNet focus not only on network congestion. The target is bounded latency and extreme low loss.
> See 3.5.1.3 in the new version (draft-ietf-detnet-data-plane-framework-05).
> 
> Section 3.6.3.1
> 
>    IP aggregation has both data plane and controller plane aspects.  For
>    the data plane, flows may be aggregated for treatment based on shared
>    characteristics such as 6-tuple.  Alternatively, an IP encapsulation
> 
> In what way would 6-tuple be a "shared characteristic" for *different* flows?  I thought 6-tuple was typically used as a unique flow identifier...
> (I see in Section 4.2.1 we refer to flows that "share 6-tuple attributes".)
> <BV> DetNet flow aggregation may be enabled via the use of wildcards, masks, lists, prefixes and ranges.
> It is defined in draft-ietf-detnet-ip. I will add a reference here.
> 
> Section 4.1
> 
>    However, from a practical and implementation standpoint, they are not
>    equivalent at all.  Some approaches are more scalable than others in
>    terms of signaling load on the network.  Some can take advantage of
>    global tracking of resources in the DetNet domain for better overall
>    network resource optimization.  Some are more resilient than others
>    if link, node, or management equipment failures occur.  While a
>    detailed analysis of the control plane alternatives is out of the
>    scope of this document, the requirements from this document can be
>    used as the basis of a later analysis of the alternatives.
> 
> side note: using "some" so much requires the reader to know which are which ... that may be reasonable, but perhaps we want the reader's brainpower working on other things.
> <BV> OK. Adding "control plane" to some of the "some"s. :--)))
> 
> Section 4.2
> 
> nit: RestConf and YANG probably are best considered together as a single "management mechanism" for these purposes.
> <BV> OK. Controller plane aspects are for further study. They are in focus after the recent re-charter.
> 
> Section 4.2.2
> 
>    DetNet application with the required service.  A requirement for the
>    DetNet Controller Plane will be the ability to assign a particular
>    identified DetNet IP flow to a path through the DetNet domain that
>    has been assigned the required nodal resources.  This provides the
> 
> nit: I don't think that "nodal" is quite the right word, here, as it refers to a property of the (network) graph more than the specific element colocated with the node in the graph.  "per-node" seems like a better fit, to me.
> <BV> OK. I will fix this.
> 
> Section 4.3
> 
>    domain requires explicit support.  There may be capabilities that can
>    be used, or extended, for example GMPLS end-to-end recovery [RFC4872]
>    and GMPLS segment recovery [RFC4873].
> 
> nit: maybe this is "existing capabilities"?
> <BV> OK. I will fix this.
> 
> Section 5
> 
> I guess there's some standard security considerations for when flow aggregation is in play, namely that misbehavior from one component flow can affect sibling flows as collateral damage.
> 
>    Security considerations for DetNet are described in detail in
>    [I-D.ietf-detnet-security].  General security considerations are
> 
> The referenced document (now at -09) seems significantly improved from when I previously made an in-passing review of the -03 (https://mailarchive.ietf.org/arch/msg/detnet/jZLodXBmQa7ZFDbBIvDO_xCDD0E/),
> however, some of the issues I mentioned there remain, at least in part (e.g., mentioning the use of HMAC without a colocated discussion of the need for key distribution and having a taxonomy of threats titled "threat model").  I would like to know what the current maturity state of the detnet-security document is believed to be, so as to judge how appropriate it is for the data-plane-framework to refer to it in this manner.
> <BV> -09 is in WG Last Call phase.
> 
>    described in [RFC8655].  This section considers general security
> 
> I think this is more like "Architecture-level DetNet" than "Generic", as the current formulation sounds like it should be referring to BCP 72 :)
> <BV> OK. I will fix this.
> 
>    Security aspects which are unique to DetNet are those whose aim is to
>    provide the specific quality of service aspects of DetNet, which are
>    primarily to deliver data flows with extremely low packet loss rates
>    and bounded end-to-end delivery latency.
> 
> I can't find a way to read this other than "security aspects [...] whose aim is to provide the specific quality of service aspects", and I'm puzzling at why it's phrased in this way.  Specifically, I thought that *providing* the QoS aspects is the core role of DetNet, and thus that the *security* aspects would be protecting those aspects in the face of (some class of) attackers.
> Would it be appropriate to replace this with something like the following?
> 
> % Part of what makes DetNet unique is its ability to provide specific and % reliable quality of service (delivering data flows with extremely low % packet loss rates and bounded end-to-end delivery latency), and the % security-related aspects of protecting that quality of service are % similarly unique.
> <BV> OK. I will fix this.
> 
> This might also be a good place to note that correct operation of the PREOF functions is pretty critical, and failures there could lead to pretty catastrophic situations for the operational technology relying on them.  I don't think there are ways for an attacker to try to attack them directly, but Murphy's Law can be a pretty effective attacker, too.
> <BV> Yes, correct operation of PREOF functions is pretty critical, but it is more an implementation and operational question, not a security one.
> DetNet specific attacks are described in the security-09 draft.

I will defer to your judgment, but just wanted to clarify that one
potential way I saw it as a security problem was if the elimination
function failed and delivered zero or two copies of a given packet that the
higher-level protocol was expecting exactly one copy of.  Depending on the
semantics of the higher-level protocol this could lead to many
security-relevant failures such as incomplete or incorrect ACLs being used,
duplicated payment, etc.

>    The primary considerations for the data plane is to maintain
>    integrity of data and delivery of the associated DetNet service
>    traversing the DetNet network.  Application flows can be protected
> 
> I'd suggest leading in to this with "As for all communications protocols,"
> to be clear that this paragraph is not trying to cover the bits that are "unique to DetNet" as much as remind the reader of general best practices.
> <BV> OK. I will fix this.
> 
>    At the management and control level DetNet flows are identified on a
>    per-flow basis, which may provide controller plane attackers with
>    additional information about the data flows (when compared to
>    controller planes that do not include per-flow identification).  This
>    is an inherent property of DetNet which has security implications
>    that should be considered when determining if DetNet is a suitable
>    technology for any given use case.
> 
> I might also note that attackers with access to the controller plan already have pretty significant attacks available to them.
> <BV> Agree, however it is a controller plane discussion, what is out of scope here.
> 
>    To provide uninterrupted availability of the DetNet service,
>    provisions can be made against DOS attacks and delay attacks.  To
>    protect against DOS attacks, excess traffic due to malicious or
>    malfunctioning devices can be prevented or mitigated, for example
>    through the use of existing mechanism such as policing and shaping
>    applied at the input of a DetNet domain.  To prevent DetNet packets
> 
> In my head this would include things like disabling switch ports that are receiving traffic floods that might overload the switch CPU, in order to protect the DetNet traffic on other ports.  I don't see much value in saying that in the document, though, since it's more of an operational practice thing.
> <BV> Policing and shaping is a major tool to protect DetNet specific resources of a node.
> I have sympathy with your view, but I would leave this text, as it was result of a long-long discussion.

Understood.

Thanks for all the updates!

-Ben

> Section 9.1
> 
> RFC 3209 is cited only once, and it does not seem like a particularly normative one.  Similarly, RFC 3473 is cited only as a "such as" example (though several times).
> 
> <BV> OK. It will be fixed in the next version.
>