Security considerations for DetNet are described in detail in [DETNET-SECURITY
]. This section considers exclusively security considerations that are specific to the DetNet architecture.
Security aspects that are unique to DetNet are those whose aim is to provide the specific QoS aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency. A DetNet may be implemented using MPLS and/or IP (including both v4 and v6) technologies and thus inherits the security properties of those technologies at both the Data Plane and the Controller Plane.
Security considerations for DetNet are constrained (compared to, for example, the open Internet) because DetNet is defined to operate only within a single administrative domain (see Section 1
). The primary considerations are to secure the request and control of DetNet resources, maintain confidentiality of data traversing the DetNet, and provide the availability of the DetNet QoS.
To secure the request and control of DetNet resources, authentication and authorization can be used for each device connected to a DetNet domain, most importantly to network controller devices. Control of a DetNet network may be centralized or distributed (within a single administrative domain). In the case of centralized control, precedent for security considerations as defined for Abstraction and Control of Traffic Engineered Networks (ACTN) can be found in Section 9
of RFC 8453
. In the case of distributed control protocols, DetNet security is expected to be provided by the security properties of the protocols in use. In any case, the result is that manipulation of administratively configurable parameters is limited to authorized entities.
To maintain confidentiality of data traversing the DetNet, application flows can be protected through whatever means is provided by the underlying technology. For example, encryption may be used, such as that provided by IPsec [RFC 4301
], for IP flows and by MACSec [IEEE802.1AE
] for Ethernet (Layer 2) flows.
DetNet flows are identified on a per-flow basis, which may provide attackers with additional information about the data flows (when compared to networks that do not include per-flow identification). This is an inherent property of DetNet that has security implications that should be considered when determining if DetNet is a suitable technology for any given use case.
To provide uninterrupted availability of the DetNet QoS, 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 traffic admission control applied at the input of a DetNet domain as described in Section 3.2.1
and through the fault-mitigation methods described in Section 3.3.2
. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of man-in-the-middle attacks, for example, through use of authentication and authorization of devices within the DetNet domain.
Because DetNet mechanisms or applications that rely on DetNet can make heavy use of methods that require precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic can be found in [RFC 7384
DetNet use cases are known to have widely divergent security requirements. The intent of this section is to provide a baseline for security considerations that are common to all DetNet designs and implementations, without burdening individual designs with specifics of security infrastructure that may not be germane to the given use case. Designers and implementors of DetNet systems are expected to take use-case-specific considerations into account in their DetNet designs and implementations.