[Detnet] New DetNet Security Draft Text 23May20

["Grossman, Ethan A." <[e-mail]>]

Hi Lou, David, All,
I have made an attempt below to craft some new text to address David's issue around "we have to tell them what to do" in the DetNet Security draft (keeping in mind that it is an informational draft). There are two basic lines of reasoning that I have used here: the first is David's suggestion to incorporate the DiffServ RFCs' Security sections as appropriate, the second was following my own thought that the draft thus far has focused exclusively on system-level DetNet designers, but not component (such as router) designers, so I have attempted to say something useful there (or at least spark some discussion). Please let me know what you think, such as whether you feel this text addresses the current remaining concerns (given that there are a few editorial comments outstanding that I could fix in the same revision) and any other input you may have in order to get it to that point.

Thanks,
Ethan (as DetNet Security Consideration draft editor and co-author)

-------------------------------
Proposed changes to Abstract:

Was:

A DetNet (deterministic network) provides specific performance
   guarantees to its data flows, such as extremely low data loss rates
   and bounded latency.  As a result, securing a DetNet implies that in
   addition to the best practice security measures taken for any
   mission-critical network, additional security measures may be needed
   whose purpose is exclusively to secure the intended operation of
   these novel service properties.

This document addresses specifically
   those security considerations, with the assumption that the reader is
   already familiar with network security best practices for the data
   plane technologies underlying a given DetNet implementation.  This
   document defines a threat model and a taxonomy of relevant attacks,
   including their potential impacts and mitigations.


Is:

A DetNet (deterministic network) provides specific performance
   guarantees to its data flows, such as extremely low data loss rates
   and bounded latency. As a result, securing a DetNet implies that in
   addition to the best practice security measures taken for any
   mission-critical network, additional security measures may be needed
   whose purpose is exclusively to secure the intended operation of
   these novel service properties.

Designers of DetNet components (such as routers) that provide these unique DetNet properties have the responsibility to uphold certain security-related properties that can be assumed by DetNet system-level designers. For example, the assumption that network traffic associated with a given flow can never affect traffic associated with a different flow is only true if the underlying components make it so.

This document addresses DetNet-specific security considerations from the perspective of both the DetNet component designer and the DetNet system-level designer. It is assumed that both classes of reader are already familiar with network security best practices for the data plane technologies underlying a given DetNet implementation. Component-level considerations include isolation of data flows from each other, ingress filtering, and detection and reporting of packet arrival time violations. System-level considerations include a threat model and a taxonomy of relevant attacks, including their potential impacts and mitigations.


Proposed changes to Introduction:
Was:
These DetNet technologies have not previously been
   deployed together on a wide area IP-based network, and thus can
   present security considerations that may be new to IP-based wide area
   network designers.  This document, intended for use by DetNet network
   designers, provides insight into these security considerations.


Is:
... These DetNet technologies have not previously been
   deployed together on a wide area IP-based network, and thus can
   present security considerations that may be new to IP-based wide area
   network designers; this document provides insight into such system-level security considerations. In addition, designers of DetNet components (such as routers) face new security-related challenges in providing DetNet services, for example maintaining reliable isolation between traffic flows in an environment where IT traffic co-mingles with critical reserved-bandwidth OT traffic; this document examines security implications internal to DetNet components.


Was:
   Given the above considerations, securing a DetNet starts with a
   scrupulously well-designed and well-managed engineered network
   following industry best practices for security at both the data plane
   and controller plane; this is the assumed starting point for the
   considerations discussed herein.  In this context we view the network
   design and managment aspects of network security as being primarily
   concerned with denial-of service prevention by ensuring that DetNet
   traffic goes where it's supposed to and that an external attacker
   can't inject traffic that disrupts the DetNet's delivery timing
   assurance.  The time-specific aspects of DetNet security presented
   here take up where the design and management aspects leave off.

Is:

   Given the above considerations, securing a DetNet starts with a
   scrupulously well-designed and well-managed engineered network
   following industry best practices for security at both the data plane
   and controller plane; this is the assumed starting point for the
   considerations discussed herein. Such assumptions also depend on the network components themselves upholding the security-related properties that are to be assumed by DetNet system-level designers; for example, the assumption that network traffic associated with a given flow can never affect traffic associated with a different flow is only true if the underlying components make it so. Such properties, which may represent new challenges to component designers, are also considered herein.

In this context we view the network
   design and management aspects of network security as being primarily
   concerned with denial-of service prevention by ensuring that DetNet
   traffic goes where it's supposed to and that an external attacker
   can't inject traffic that disrupts the DetNet's delivery timing
   assurance.  The time-specific aspects of DetNet security presented
   here take up where the design and management aspects leave off.

Was:
   o  Provide explicit routes for DetNet flows that do not rapidly
      change with the network topology
Is:
   o  Provide explicit routes for DetNet flows that do not dynamically
      change with the network topology in ways that affect the quality of service received by the affected flow(s).

Was:
This document includes sections on threat modeling and analysis,
   threat impact and mitigation, and the association of attacks with use
   cases based on the Use Case Common Themes section of the DetNet Use
   Cases.

Is:
This document includes sections on component design considerations as well as system
considerations including threat modeling and analysis, threat impact and mitigation,
and the association of attacks with use cases based on the Use Case Common Themes
section of the DetNet Use Cases.

Proposed new section:

Security Considerations for DetNet Component Design
As noted above, DetNet provides resource allocation, explicit routes and redundant path support. Each of these have associated security implications, which are discussed in this section. Detection, reporting and appropriate action in the case of packet arrival time violations is also discussed.

Resource allocation
A DetNet system security designer relies on the premise that any resources allocated to a resource-reserved (OT-type) flow are inviolable, in other words there is no physical possibility within a DetNet component that resources allocated to a given flow can be compromised by any type of traffic in the network; this includes both malicious traffic as well as inadvertent traffic such as might be produced by a malfunctioning component, for example one made by a different manufacturer. From a security standpoint, this is a critical assumption, for example when designing against DOS attacks. It is the responsibility of the component designer to ensure that this condition is met; this implies protection against excess traffic from adjacent flows, and against compromises to the resource allocation/deallocation process.

Explicit Routes
The DetNet-specific purpose for constraining the network's ability to re-route OT traffic is to maintain the specified service parameters (such as upper and lower latency boundaries) for a given flow. For example if the network were to re-route a flow (or some part of a flow) based exclusively on statistical path usage metrics, or due to malicious activity, it is possible that the new path would have a latency that is outside the required latency bounds which were designed into the original TE-designed path, thereby violating the quality of service for the affected flow (or part of that flow). (However, is acceptable for the network to re-route OT traffic in such a way as to maintain the specified latency bounds (and any other specified service properties) for any reason, for example in response to a runtime component or path failure). From a security standpoint, the system designer relies on the premise that the packets will be delivered with the specified latency boundaries; thus any component that is involved in controlling or implementing any change of the initially TE-configured flow routes needs to prevent malicious or accidental re-routing of OT flows that might adversely affect delivering the traffic within the specified service parameters.

Redundant Path Support
Provision for redundant paths is one of the most complex areas of the DetNet design, with a number of subtleties that .

Timing Violation Reporting
Another fundamental assumption of a secure DetNet is that in any case in which an incoming packet arrives outside of its prescribed time window or exceeding the reserved flow bandwidth, something can be done about it. That means that the component's data plane must be able to detect such cases, then at least alert the control plane, and/or drop the packet, and/or shut down the link if violations persist. Logging of such issues may not be adequate, since a delay in response to the situation could result in material damage, for example to mechanical devices controlled by the network.

Proposed new section:

DetNet Security Considerations Compared With DiffServ Security Considerations
DetNet is designed to be compatible with DiffServ as applied to IT traffic in the DetNet. DetNet also incorporates the use of the 6-bit value of the DSCP field of the TOS field of the IP header for flow identification for OT traffic, however the DetNet interpretation of the DSCP value for OT traffic is not equivalent to the PHB selection behavior as defined by DiffServ.
Thus security consideration for DetNet have some aspects in common with DiffServ, in fact overlapping 100% with respect to IP IT traffic. Security considerations for these aspects are part of the existing literature on IP network security, specifically the Security sections of RFC 2474 (DiffServ Definition) and RFC 2475 (DiffServ Architecture).  However DetNet also introduce timing and other considerations which are not present in DiffServ, so the DiffServ security considerations are necessary but not sufficient for DetNet.

In the case of DetNet OT traffic, the DSCP value, although interpreted differently than in DiffServ, does contribute to determination of the service provided to the packet. Thus in DetNet there are similar consequences to DiffServ for lack of detection of, or incorrect handling of, packets with mismarked DSCP values, and thus many of the points made in the DiffServ draft Security discussions are also relevant to DetNet OT traffic, though perhaps in modified form. For example, in DetNet the effect of an undetected or incorrectly handled maliciously mismarked DSCP field in an OT packet is not identical to affecting that packet's PHB, since DetNet does not use the PHB concept for OT traffic, but nonetheless the service provided to the packet could be affected, so mitigation measures analogous to those prescribed by DiffServ would be appropriate for DetNet. For example, mismarked DSCP values should not cause failure of network nodes, and any internal link that cannot be adequately secured against modification of DSCP values should be treated as a boundary link (and hence any arriving traffic on that link is treated as if it were entering the domain at an ingress node). The remarks in RFC2474 regarding IPsec and Tunnelling Interactions are also relevant (though this is not to say that other sections are less relevant).
-------------------------------------------------