--- 1/draft-ietf-detnet-security-06.txt 2020-01-10 20:13:14.264239730 -0800 +++ 2/draft-ietf-detnet-security-07.txt 2020-01-10 20:13:14.348241870 -0800 @@ -1,73 +1,70 @@ Internet Engineering Task Force T. Mizrahi Internet-Draft HUAWEI Intended status: Informational E. Grossman, Ed. -Expires: May 4, 2020 DOLBY +Expires: July 13, 2020 DOLBY A. Hacker MISTIQ S. Das Applied Communication Sciences J. Dowdell Airbus Defence and Space H. Austad SINTEF Digital N. Finn HUAWEI - November 1, 2019 + January 10, 2020 Deterministic Networking (DetNet) Security Considerations - draft-ietf-detnet-security-06 + draft-ietf-detnet-security-07 Abstract A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years. However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). 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 draft, intended for use by DetNet network - designers, provides insight into these security considerations. In - addition, this draft collects all security-related statements from - the various DetNet drafts (Architecture, Use Cases, etc) into a - single location Section 8. + network designers. This document, intended for use by DetNet network + designers, provides insight into these security considerations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 4, 2020. + This Internet-Draft will expire on July 13, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -77,56 +74,56 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 7 3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7 3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7 - 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 8 + 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7 3.2.4. Packet Replication and Elimination . . . . . . . . . 8 3.2.4.1. Replication: Increased Attack Surface . . . . . . 8 3.2.4.2. Replication-related Header Manipulation . . . . . 8 - 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 9 + 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8 3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9 3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9 3.2.6.1. Control or Signaling Packet Modification . . . . 9 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 - 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 + 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9 - 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13 - 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 14 + 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 13 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15 4.4. Replication and Elimination . . . . . . . . . . . . . . . 15 - 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 16 + 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15 4.4.2. Header Manipulation at Elimination Bridges . . . . . 16 4.5. Control or Signaling Packet Modification . . . . . . . . 16 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 - 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 16 + 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 17 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 18 5.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 18 5.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18 5.5.1. Encryption Considerations for DetNet . . . . . . . . 19 5.6. Control and Signaling Message Protection . . . . . . . . 20 5.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 20 5.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 21 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 22 @@ -152,89 +149,83 @@ 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 29 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29 6.1.22. Reliability and Availability . . . . . . . . . . . . 30 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 30 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 31 6.3. Security Considerations for OAM Traffic . . . . . . . . . 33 7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33 7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 7.3. TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 8. Appendix A: DetNet Draft Security-Related Statements . . . . 35 - 8.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 35 - 8.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 35 - 8.1.2. Security Considerations (sec 7) . . . . . . . . . . . 36 - 8.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 36 - 8.2.1. Security Considerations (sec 7) . . . . . . . . . . . 36 - 8.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 37 - 8.3.1. Security Considerations (sec 5) . . . . . . . . . . . 37 - 8.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 37 - 8.4.1. (Utility Networks) Security Current Practices and - Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 37 - 8.4.2. (Utility Networks) Security Trends in Utility - Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 39 - 8.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 41 - 8.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 41 - 8.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 41 - 8.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 42 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 - 11. Informative References . . . . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 + 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 10. Informative References . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction Security is of particularly high importance in DetNet networks because many of the use cases which are enabled by DetNet [RFC8578] include control of physical devices (power grid components, industrial controls, building controls) which can have high operational costs for failure, and present potentially attractive targets for cyber-attackers. This situation is even more acute given that one of the goals of DetNet is to provide a "converged network", i.e. one that includes both IT traffic and OT traffic, thus exposing potentially sensitive OT devices to attack in ways that were not previously common (usually because they were under a separate control system or otherwise isolated from the IT network, for example [ARINC664P7]). Security - considerations for OT networks is not a new area, and there are many + considerations for OT networks are not a new area, and there are many OT networks today that are connected to wide area networks or the - Internet; this draft focuses on the issues that are specific to the - DetNet technologies and use cases. + Internet; this document focuses on the issues that are specific to + the DetNet technologies and use cases. + + 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 control 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. + + The security requirements for any given DetNet network are + necessarily specific to the use cases handled by that network. Thus + the reader is assumed to be familiar with the specific security + requirements of their use cases, for example those outlined in the + DetNet Use Cases [RFC8578] and the Security Considerations sections + of the DetNet documents applicable to the network technologies in + use, for example [I-D.ietf-detnet-ip]). The DetNet technologies include ways to: o Reserve data plane resources for DetNet flows in some or all of the intermediate nodes (e.g. bridges or routers) along the path of the flow o Provide explicit routes for DetNet flows that do not rapidly change with the network topology o Distribute data from DetNet flow packets over time and/or space to ensure delivery of each packet's data' in spite of the loss of a path - This draft 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 - draft [RFC8578]. - - This draft also provides context for the DetNet security - considerations by collecting into one place Section 8 the various - remarks about security from the various DetNet drafts (Use Cases, - Architecture, etc). This text is duplicated here primarily because - the DetNet working group has elected not to produce a Requirements - draft and thus collectively these statements are as close as we have - to "DetNet Security Requirements". + 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 [RFC8578]. 2. Abbreviations IT Information technology (the application of computers to store, study, retrieve, transmit, and manipulate data or information, often in the context of a business or other enterprise - Wikipedia). OT Operational Technology (the hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as @@ -283,21 +275,21 @@ authenticated traffic. o Man in the Middle (MITM) vs. packet injector: MITM attackers are located in a position that allows interception and modification of in-flight protocol packets, whereas a traffic injector can only attack by generating protocol packets. Care has also been taken to adhere to Section 5 of [RFC3552], both with respect to which attacks are considered out-of-scope for this document, but also which are considered to be the most common threats - (explored furhter in Section 3.2. Most of the direct threats to + (explored further in Section 3.2. Most of the direct threats to DetNet are Active attacks, but it is highly suggested that DetNet application developers take appropriate measures to protect the content of the streams from passive attacks. DetNet-Service, one of the service scenarios described in [I-D.varga-detnet-service-model], is the case where a service connects DetNet networking islands, i.e. two or more otherwise independent DetNet network domains are connected via a link that is not intrinsically part of either network. This implies that there could be DetNet traffic flowing over a non-DetNet link, which may @@ -310,21 +302,21 @@ 3.2. Threat Analysis 3.2.1. Delay 3.2.1.1. Delay Attack An attacker can maliciously delay DetNet data flow traffic. By delaying the traffic, the attacker can compromise the service of applications that are sensitive to high delays or to high delay - variation. + variation. The delay may be constant or modulated. 3.2.2. DetNet Flow Modification or Spoofing An attacker can modify some header fields of en route packets in a way that causes the DetNet flow identification mechanisms to misclassify the flow. Alternatively, the attacker can inject traffic that is tailored to appear as if it belongs to a legitimate DetNet flow. The potential consequence is that the DetNet flow resource allocation cannot guarantee the performance that is expected when the flow identification works correctly. @@ -408,21 +401,21 @@ A passive eavesdropper can identify DetNet flows and then gather information about en route DetNet flows, e.g., the number of DetNet flows, their bandwidths, their schedules, or other temporal properties. The gathered information can later be used to invoke other attacks on some or all of the flows. Note that in some cases DetNet flows may be identified based on an explicit DetNet header, but in some cases the flow identification may be based on fields from the L3/L4 headers. If L3/L4 headers are - involved, for purposes of this draft we assume they are encrypted + involved, for purposes of this document we assume they are encrypted and/or integrity-protected from external attackers. 3.2.8. Time Synchronization Mechanisms An attacker can use any of the attacks described in [RFC7384] to attack the synchronization protocol, thus affecting the DetNet service. 3.3. Threat Summary @@ -433,21 +426,21 @@ under the assumption that a corresponding security mechanism is being used, and that the corresponding network equipment takes part in this mechanism. +-----------------------------------------+----+----+----+----+ | Attack | Attacker Type | | +---------+---------+ | |Internal |External | | |MITM|Inj.|MITM|Inj.| +-----------------------------------------+----+----+----+----+ - |Delay attack | + | | + | | + |Delay attack | + | + | + | + | +-----------------------------------------+----+----+----+----+ |DetNet Flow Modification or Spoofing | + | + | | | +-----------------------------------------+----+----+----+----+ |Inter-segment Attack | + | + | | | +-----------------------------------------+----+----+----+----+ |Replication: Increased Attack Surface | + | + | + | + | +-----------------------------------------+----+----+----+----+ |Replication-related Header Manipulation | + | | | | +-----------------------------------------+----+----+----+----+ |Path Manipulation | + | + | | | @@ -477,23 +470,23 @@ information. DetNet raises these stakes significantly for OT applications, particularly those which may have been designed to run in an OT-only environment and thus may not have been designed for security in an IT environment with its associated devices, services and protocols. The severity of various components of the impact of a successful vulnerability exploit to use cases by industry is available in more detail in [RFC8578]. Each of the use cases in the DetNet Use Cases - draft is represented in the table below, including Pro Audio, - Electrical Utilities, Industrial M2M (split into two areas, M2M Data - Gathering and M2M Control Loop), and others. + is represented in the table below, including Pro Audio, Electrical + Utilities, Industrial M2M (split into two areas, M2M Data Gathering + and M2M Control Loop), and others. Components of Impact (left column) include Criticality of Failure, Effects of Failure, Recovery, and DetNet Functional Dependence. Criticality of failure summarizes the seriousness of the impact. The impact of a resulting failure can affect many different metrics that vary greatly in scope and severity. In order to reduce the number of variables, only the following were included: Financial, Health and Safety, People well being (People WB), Affect on a single organization, and affect on multiple organizations. Recovery outlines how long it would take for an affected use case to get back @@ -592,23 +585,23 @@ Figure 2: Impact of Attacks by Use Case Industry The rest of this section will cover impact of the different groups in more detail. 4.1. Delay-Attacks 4.1.1. Data Plane Delay Attacks - Severely delayed messages in a DetNet link can result in the same - behavior as dropped messages in ordinary networks as the services - attached to the stream has strict deterministic requirements. + Delayed messages in a DetNet link can result in the same behavior as + dropped messages in ordinary networks as the services attached to the + stream has strict deterministic requirements. For a single path scenario, disruption is a real possibility, whereas in a multipath scenario, large delays or instabilities in one stream can lead to increased buffer and CPU resources on the elimination bridge. A data-plane delay attack on a system controlling substantial moving devices, for example in industrial automation, can cause physical damage. For example, if the network promises a bounded latency of 2ms for a flow, yet the machine receives it with 5ms latency, the @@ -629,21 +622,23 @@ from receiving expected frames thus disrupting expected behavior. o Delaying messages removing an EP from a group can lead to loss of privacy as the EP will continue to receive messages even after it is supposedly removed. 4.2. Flow Modification and Spoofing 4.2.1. Flow Modification - ToDo. + If the contents of a packet header or body can be modified by the + attacker, this can cause the packet to be routed incorrectly or + dropped, or the payload to be corrupted or subtly modified. 4.2.2. Spoofing 4.2.2.1. Dataplane Spoofing Spoofing dataplane messages can result in increased resource consumptions on the bridges throughout the network as it will increase buffer usage and CPU utilization. This can lead to resource exhaustion and/or increased delay. @@ -709,51 +704,58 @@ 4.4.1. Increased Attack Surface Covered briefly in Section 4.3 4.4.2. Header Manipulation at Elimination Bridges Covered briefly in Section 4.3 4.5. Control or Signaling Packet Modification - ToDo. + If the control plane packets are subject to manipulation undetected, + the network can be severely compromised. 4.6. Control or Signaling Packet Injection - ToDo. + If an attacker can inject control plane packets undetected, the + network can be severely compromised. 4.7. Reconnaissance Of all the attacks, this is one of the most difficult to detect and counter. Often, an attacker will start out by observing the traffic going through the network and use the knowledge gathered in this phase to mount future attacks. The attacker can, at their leisure, observe over time all aspects of the messaging and signalling, learning the intent and purpose of all traffic flows. At some later date, possibly at an important time in an operational context, the attacker can launch a multi-faceted attack, possibly in conjunction with some demand for ransom. The flow-id in the header of the data plane-messages gives an attacker a very reliable identifier for DetNet traffic, and this traffic has a high probability of going to lucrative targets. + Applications which are ported from a private OT network to the higher + visibility DetNet environment may need to be adapted to limit + distinctive flow properties that could make them susceptible to + reconnaissance. + 4.8. Attacks on Time Sync Mechanisms - ToDo. + Attacks on time sync mechanisms are addressed in [RFC7384]. 4.9. Attacks on Path Choice This is covered in part in Section 4.3, and as with Replication and - Elimination (Section 4.4, this is relevant for DataPlane messages. + Elimination (Section 4.4), this is relevant for DataPlane messages. 5. Security Threat Mitigation This section describes a set of measures that can be taken to mitigate the attacks described in Section 3. These mitigations should be viewed as a toolset that includes several different and diverse tools. Each application or system will typically use a subset of these tools, based on a system-specific threat analysis. 5.1. Path Redundancy @@ -763,31 +765,32 @@ A DetNet flow that can be forwarded simultaneously over multiple paths. Path replication and elimination [RFC8655] provides resiliency to dropped or delayed packets. This redundancy improves the robustness to failures and to man-in-the-middle attacks. Related attacks Path redundancy can be used to mitigate various man-in-the-middle attacks, including attacks described in Section 3.2.1, - Section 3.2.2, Section 3.2.3, and Section 3.2.8. + Section 3.2.2, Section 3.2.3, and Section 3.2.8. However it is + also possible that multiple paths may make it more difficult to + locate the source of a MITM attacker. 5.2. Integrity Protection Description An integrity protection mechanism, such as a Hash-based Message Authentication Code (HMAC) can be used to mitigate modification - attacks. Integrity protection can be used on the data plane - header, to prevent its modification and tampering. Integrity - protection in the control plane is discussed in Section 5.6. + attacks on IP packets. Integrity protection in the control plane + is discussed in Section 5.6. Packet Sequence Number Integrity Considerations The use of PREOF in a DetNet implementation implies the use of a sequence number for each packet. There is a trust relationship between the device that adds the sequence number and the device that removes the sequence number. The sequence number may be end- to-end source to destination, or may be added/deleted by network edge devices. The adder and remover(s) have the trust relationship because they are the ones that ensure that the @@ -1004,63 +1008,63 @@ Figure 3: Mapping Attacks to Impact and Mitigations 6. Association of Attacks to Use Cases Different attacks can have different impact and/or mitigation depending on the use case, so we would like to make this association in our analysis. However since there is a potentially unbounded list of use cases, we categorize the attacks with respect to the common themes of the use cases as identified in the Use Case Common Themes - section of the DetNet Use Cases draft [RFC8578]. + section of the DetNet Use Cases [RFC8578]. See also Figure 2 for a mapping of the impact of attacks per use case by industry. 6.1. Use Cases by Common Themes In this section we review each theme and discuss the attacks that are applicable to that theme, as well as anything specific about the impact and mitigations for that attack with respect to that theme. The table Figure 5 then provides a summary of the attacks that are applicable to each theme. 6.1.1. Network Layer - AVB/TSN Ethernet DetNet is expected to run over various transmission mediums, with Ethernet being explicitly supported. Attacks such as Delay or Reconnaissance might be implemented differently on a different transmission medium, however the impact on the DetNet as a whole would be essentially the same. We thus conclude that all attacks and impacts that would be applicable to DetNet over Ethernet (i.e. all - those named in this draft) would also be applicable to DetNet over + those named in this document) would also be applicable to DetNet over other transmission mediums. With respect to mitigations, some methods are specific to the Ethernet medium, for example time-aware scheduling using 802.1Qbv can protect against excessive use of bandwidth at the ingress - for other mediums, other mitigations would have to be implemented to provide analogous protection. 6.1.2. Central Administration A DetNet network is expected to be controlled by a centralized network configuration and control system (CNC). Such a system may be in a single central location, or it may be distributed across multiple control entities that function together as a unified control system for the network. - In this draft we distinguish between attacks on the DetNet Control + In this document we distinguish between attacks on the DetNet Control plane vs. Data plane. But is an attack affecting control plane packets synonymous with an attack on the CNC itself? For purposes of - this draft let us consider an attack on the CNC itself to be out of - scope, and consider all attacks named in this draft which are + this document let us consider an attack on the CNC itself to be out + of scope, and consider all attacks named in this document which are relevant to control plane packets to be relevant to this theme, including Path Manipulation, Path Choice, Control Packet Modification or Injection, Reconaissance and Attacks on Time Sync Mechanisms. 6.1.3. Hot Swap A DetNet network is not expected to be "plug and play" - it is expected that there is some centralized network configuration and control system. However, the ability to "hot swap" components (e.g. due to malfunction) is similar enough to "plug and play" that this @@ -1096,55 +1100,53 @@ present a new attack surface. Does the threat take advantage of any aspect of our new Data Flow Info Models? This is TBD, thus there are no specific entries in our table, however that does not imply that there could be no relevant attacks. 6.1.5. L2 and L3 Integration A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN LAN) and Layer 3 (routed) networks via the use of well-known - protocols such as IPv6, MPLS-PW, and Ethernet. Presumably security - considerations applicable directly to those individual protocols is - not specific to DetNet, and thus out of scope for this draft. - However enabling DetNet to coordinate Layer 2 and Layer 3 behavior - will require some additions to existing protocols (see draft-dt- - detnet-dp-alt) and any such new work can introduce new attack - surfaces. + protocols such as IP, MPLS-PW, and Ethernet. - This is TBD, thus there are no specific entries in our table, however - that does not imply that there could be no relevant attacks. + There are no specific entries in our table, however that does not + imply that there could be no relevant attacks related to L2,L3 + integration. 6.1.6. End-to-End Delivery - Packets sent over DetNet are guaranteed not to be dropped by the - network due to congestion. (Packets may however be dropped for + Packets sent over DetNet are not to be dropped by the network due to + congestion. (Packets may however intentionally be dropped for intended reasons, e.g. per security measures). A Data plane attack may force packets to be dropped, for example a "long" Delay or Replication/Elimination or Flow Modification attack. The same result might be obtained by a Control plane attack, e.g. Path Manipulation or Signaling Packet Modification. It may be that such attacks are limited to Internal MITM attackers, but other possibilities should be considered. An attack may also cause packets that should not be delivered to be delivered, such as by forcing packets from one (e.g. replicated) path to be preferred over another path when they should not be (Replication attack), or by Flow Modification, or by Path Choice or Packet Injection. A Time Sync attack could cause a system that was expecting certain packets at certain times to accept unintended packets based on compromised system time or time windowing in the scheduler. + Packets may also be dropped due to malfunctioning software or + hardware. + 6.1.7. Proprietary Deterministic Ethernet Networks There are many proprietary non-interoperable deterministic Ethernet- based networks currently available; DetNet is intended to provide an open-standards-based alternative to such networks. In cases where a DetNet intersects with remnants of such networks or their protocols, such as by protocol emulation or access to such a network via a gateway, new attack surfaces can be opened. For example an Inter-Segment or Control plane attack such as Path @@ -1167,29 +1169,28 @@ could be used to exploit commands specific to such a protocol, or that are interpreted differently by the different protocols or gateway. 6.1.9. Deterministic vs Best-Effort Traffic DetNet is intended to support coexistence of time-sensitive operational (OT, deterministic) traffic and information (IT, "best effort") traffic on the same ("unified") network. - The presence of IT traffic on a network carrying OT traffic has long - been considered insecure design [reference needed here]. With - DetNet, this coexistance will become more common, and mitigations - will need to be established. The fact that the IT traffic on a - DetNet is limited to a corporate controlled network makes this a less - difficult problem compared to being exposed to the open Internet, - however this aspect of DetNet security should not be underestimated. + With DetNet, this coexistance will become more common, and + mitigations will need to be established. The fact that the IT + traffic on a DetNet is limited to a corporate controlled network + makes this a less difficult problem compared to being exposed to the + open Internet, however this aspect of DetNet security should not be + underestimated. - Most of the themes described in this draft address OT (reserved) + Most of the themes described in this document address OT (reserved) streams - this item is intended to address issues related to IT traffic on a DetNet. An Inter-segment attack can flood the network with IT-type traffic with the intent of disrupting handling of IT traffic, and/or the goal of interfering with OT traffic. Presumably if the stream reservation and isolation of the DetNet is well-designed (better-designed than the attack) then interference with OT traffic should not result from an attack that floods the network with IT traffic. @@ -1384,22 +1385,21 @@ be required of a given system, and should define parameters for communicating these kinds of metrics within the network. Any attack on the system, of any type, can affect its overall reliability and availability, thus in our table we have marked every attack. Since every DetNet depends to a greater or lesser degree on reliability and availability, this essentially means that all networks have to mitigate all attacks, which to a greater or lesser degree defeats the purpose of associating attacks with use cases. It also underscores the difficulty of designing "extremely high - reliability" networks. I hope that in future drafts we can say - something more useful here. + reliability" networks. 6.1.23. Redundant Paths DetNet based systems are expected to be implemented with essentially arbitrarily high reliability/availability. A strategy used by DetNet for providing such extraordinarily high levels of reliability is to provide redundant paths that can be seamlessly switched between, all the while maintaining the required performance of that system. Replication-related attacks are by definition applicable here. @@ -1532,62 +1532,89 @@ o OAM traffic generated by the customer. From a DetNet security point of view, DetNet security considerations for such traffic are exactly the same as for any other customer data flows. Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet security considerations. 7. DetNet Technology-Specific Threats - Section 3 described threats which are independent of the DetNet - implementation. This section considers threats related to the - specific technologies referenced in - [I-D.ietf-detnet-data-plane-framework] which have not already been - enumerated in Section 3. + Section 3 described threats which are independent of a DetNet + implementation. This section considers threats specifically related + to the IP- and MPLS-specific aspects of DetNet implementations. - As in this document in general, this section only enumerates security - aspects which are unique to providing 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. The primary considerations for the data plane specifically - are to maintain integrity of data and delivery of the associated - DetNet service traversing the DetNet network. + The primary security considerations for the data plane specifically + are to maintain the integrity of the data and the delivery of the + associated DetNet service traversing the DetNet network. + + The primary relevant differences between IP and MPLS implementations + are in flow identification and OAM methodologies. As noted in [RFC8655], DetNet operates at the IP layer ([I-D.ietf-detnet-ip]) and delivers service over sub-layer technologies such as MPLS ([I-D.ietf-detnet-mpls]) and IEEE 802.1 Time-Sensitive Networking (TSN) ([I-D.ietf-detnet-ip-over-tsn]). + Application flows can be protected through whatever means are + provided by the layer and sub-layer technologies. For example, + technology-specific encryption may be used, such as that provided by + IPSec [RFC4301] for IP flows and/or by an underlying sub-net using + MACSec [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. - Application flows can be protected through whatever means is provided - by the underlying technology. For example, technology-specific - encryption may be used, such as that provided by IPSec [RFC4301] for - IP flows and/or by an underlying sub-net using MACSec - [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. + However, if the DetNet nodes cannot decrypt IPsec traffic, IPSec may + not be a valid option; this is because the DetNet IP data plane + identifies flows via a 6-tuple that consists of two IP addresses, the + transport protocol ID, two transport protocol port numbers and the + DSCP in the IP header. When IPsec is used, the transport header is + encrypted and the next protocol ID is an IPsec protocol, usually ESP, + and not a transport protocol (e.g., neither TCP nor UDP, etc.) + leaving only three components of the 6-tuple, which are the two IP + addresses and the DSCP, which are in general not sufficient to + identify a DetNet flow. - Sections below discuss threats specific to IP, MPLS, and TSN in more + Sections below discuss threats specific to IP and MPLS in more detail. 7.1. IP The IP protocol has a long history of security considerations and architectural protection mechanisms. From a data plane perspective DetNet does not add or modify any IP header information, and its use as a DetNet Data Plane does not introduce any new security issues that were not there before, apart from those already described in the data-plane-independent threats section Section 3. Thus the security considerations for a DetNet based on an IP data plane are purely inherited from the rich IP Security literature and code/application base, and the data-plane-independent section of this document. + Maintaining security for IP segments of a DetNet may be more + challenging than for the MPLS segments of the network, given that the + IP segments of the network may reach the edges of the network, which + are more likely to involve interaction with potentially malevolent + outside actors. Conversely MPLS is inherently more secure than IP + since it is internal to routers and it is well-known how to protect + it from outside influence. + + Another way to look at DetNet IP security is to consider it in the + light of VPN security; as an industry we have a lot of experience + with VPNs running through networks with other VPNs, it is well known + how to secure the network for that. However for a DetNet we have the + additional subtlety that any possible interaction of one packet with + another can have a potentially deleterious effect on the time + properties of the flows. So the network must provide sufficient + isolation between flows, for example by protecting the forwarding + bandwidth and related resources so that they are available to detnet + traffic, by whatever means are appropriate for that network's data + plane. + 7.2. MPLS An MPLS network carrying DetNet traffic is expected to be a "well- managed" network. Given that this is the case, it is difficult for an attacker to pass a raw MPLS encoded packet into a network because operators have considerable experience at excluding such packets at the network boundaries, as well as excluding MPLS packets being inserted through the use of a tunnel. MPLS security is discussed extensively in [RFC5920] ("Security @@ -1619,384 +1646,56 @@ One particular problem that has been observed in operational tests of TWTT protocols is the ability for two closely but not completely synchronized streams to beat and cause a sudden phase hit to one of the streams. This can be mitigated by the careful use of a scheduling system in the underlying packet transport. Further consideration of protection against dynamic attacks is work in progress. -7.3. TSN - - Editor's Note: To Be Written. - -8. Appendix A: DetNet Draft Security-Related Statements - - This section collects the various statements in the currently - existing DetNet Working Group drafts. For each draft, the section - name and number of the quoted section is shown. The text shown here - is the work of the original draft authors, quoted verbatim from the - drafts. The intention is to explicitly quote all relevant text, not - to summarize it. - -8.1. Architecture (draft 8) - -8.1.1. Fault Mitigation (sec 4.5) - - One key to building robust real-time systems is to reduce the - infinite variety of possible failures to a number that can be - analyzed with reasonable confidence. DetNet aids in the process by - providing filters and policers to detect DetNet packets received on - the wrong interface, or at the wrong time, or in too great a volume, - and to then take actions such as discarding the offending packet, - shutting down the offending DetNet flow, or shutting down the - offending interface. - - It is also essential that filters and service remarking be employed - at the network edge to prevent non-DetNet packets from being mistaken - for DetNet packets, and thus impinging on the resources allocated to - DetNet packets. - - There exist techniques, at present and/or in various stages of - standardization, that can perform these fault mitigation tasks that - deliver a high probability that misbehaving systems will have zero - impact on well-behaved DetNet flows, except of course, for the - receiving interface(s) immediately downstream of the misbehaving - device. Examples of such techniques include traffic policing - functions (e.g. [RFC2475]) and separating flows into per-flow rate- - limited queues. - -8.1.2. Security Considerations (sec 7) - - Security in the context of Deterministic Networking has an added - dimension; the time of delivery of a packet can be just as important - as the contents of the packet, itself. A man-in-the-middle attack, - for example, can impose, and then systematically adjust, additional - delays into a link, and thus disrupt or subvert a real-time - application without having to crack any encryption methods employed. - See [RFC7384] for an exploration of this issue in a related context. - - Furthermore, in a control system where millions of dollars of - equipment, or even human lives, can be lost if the DetNet QoS is not - delivered, one must consider not only simple equipment failures, - where the box or wire instantly becomes perfectly silent, but bizarre - errors such as can be caused by software failures. Because there is - essential no limit to the kinds of failures that can occur, - protecting against realistic equipment failures is indistinguishable, - in most cases, from protecting against malicious behavior, whether - accidental or intentional. - - Security must cover: - - o Protection of the signaling protocol - - o Authentication and authorization of the controlling nodes - - o Identification and shaping of the flows - -8.2. Data Plane Alternatives (draft 4) - -8.2.1. Security Considerations (sec 7) - - This document does not add any new security considerations beyond - what the referenced technologies already have. - -8.3. Problem Statement (draft 5) - -8.3.1. Security Considerations (sec 5) - - Security in the context of Deterministic Networking has an added - dimension; the time of delivery of a packet can be just as important - as the contents of the packet, itself. A man-in-the-middle attack, - for example, can impose, and then systematically adjust, additional - delays into a link, and thus disrupt or subvert a real-time - application without having to crack any encryption methods employed. - See [RFC7384] for an exploration of this issue in a related context. - - Typical control networks today rely on complete physical isolation to - prevent rogue access to network resources. DetNet enables the - virtualization of those networks over a converged IT/OT - infrastructure. Doing so, DetNet introduces an additional risk that - flows interact and interfere with one another as they share physical - resources such as Ethernet trunks and radio spectrum. The - requirement is that there is no possible data leak from and into a - deterministic flow, and in a more general fashion there is no - possible influence whatsoever from the outside on a deterministic - flow. The expectation is that physical resources are effectively - associated with a given flow at a given point of time. In that - model, Time Sharing of physical resources becomes transparent to the - individual flows which have no clue whether the resources are used by - other flows at other times. - - Security must cover: - - o Protection of the signaling protocol - - o Authentication and authorization of the controlling nodes - - o Identification and shaping of the flows - - o Isolation of flows from leakage and other influences from any - activity sharing physical resources - -8.4. Use Cases (draft 11) - -8.4.1. (Utility Networks) Security Current Practices and Limitations - (sec 3.2.1) - - Grid monitoring and control devices are already targets for cyber - attacks, and legacy telecommunications protocols have many intrinsic - network-related vulnerabilities. For example, DNP3, Modbus, - PROFIBUS/PROFINET, and other protocols are designed around a common - paradigm of request and respond. Each protocol is designed for a - master device such as an HMI (Human Machine Interface) system to send - commands to subordinate slave devices to retrieve data (reading - inputs) or control (writing to outputs). Because many of these - protocols lack authentication, encryption, or other basic security - measures, they are prone to network-based attacks, allowing a - malicious actor or attacker to utilize the request-and-respond system - as a mechanism for command-and-control like functionality. Specific - security concerns common to most industrial control, including - utility telecommunication protocols include the following: - - o Network or transport errors (e.g. malformed packets or excessive - latency) can cause protocol failure. - - o Protocol commands may be available that are capable of forcing - slave devices into inoperable states, including powering-off - devices, forcing them into a listen-only state, disabling - alarming. - - o Protocol commands may be available that are capable of restarting - communications and otherwise interrupting processes. - - o Protocol commands may be available that are capable of clearing, - erasing, or resetting diagnostic information such as counters and - diagnostic registers. - - o Protocol commands may be available that are capable of requesting - sensitive information about the controllers, their configurations, - or other need-to-know information. - - o Most protocols are application layer protocols transported over - TCP; therefore it is easy to transport commands over non-standard - ports or inject commands into authorized traffic flows. - - o Protocol commands may be available that are capable of - broadcasting messages to many devices at once (i.e. a potential - DoS). - - o Protocol commands may be available to query the device network to - obtain defined points and their values (i.e. a configuration - scan). - - o Protocol commands may be available that will list all available - function codes (i.e. a function scan). - - o These inherent vulnerabilities, along with increasing connectivity - between IT an OT networks, make network-based attacks very - feasible. - - o Simple injection of malicious protocol commands provides control - over the target process. Altering legitimate protocol traffic can - also alter information about a process and disrupt the legitimate - controls that are in place over that process. A man-in-the-middle - attack could provide both control over a process and - misrepresentation of data back to operator consoles. - -8.4.2. (Utility Networks) Security Trends in Utility Networks (sec - 3.3.3) - - Although advanced telecommunications networks can assist in - transforming the energy industry by playing a critical role in - maintaining high levels of reliability, performance, and - manageability, they also introduce the need for an integrated - security infrastructure. Many of the technologies being deployed to - support smart grid projects such as smart meters and sensors can - increase the vulnerability of the grid to attack. Top security - concerns for utilities migrating to an intelligent smart grid - telecommunications platform center on the following trends: - - o Integration of distributed energy resources - - o Proliferation of digital devices to enable management, automation, - protection, and control - - o Regulatory mandates to comply with standards for critical - infrastructure protection - - o Migration to new systems for outage management, distribution - automation, condition-based maintenance, load forecasting, and - smart metering - - o Demand for new levels of customer service and energy management - - This development of a diverse set of networks to support the - integration of microgrids, open-access energy competition, and the - use of network-controlled devices is driving the need for a converged - security infrastructure for all participants in the smart grid, - including utilities, energy service providers, large commercial and - industrial, as well as residential customers. Securing the assets of - electric power delivery systems (from the control center to the - substation, to the feeders and down to customer meters) requires an - end-to-end security infrastructure that protects the myriad of - telecommunications assets used to operate, monitor, and control power - flow and measurement. - - "Cyber security" refers to all the security issues in automation and - telecommunications that affect any functions related to the operation - of the electric power systems. Specifically, it involves the - concepts of: - - o Integrity : data cannot be altered undetectably - - o Authenticity : the telecommunications parties involved must be - validated as genuine - - o Authorization : only requests and commands from the authorized - users can be accepted by the system - - o Confidentiality : data must not be accessible to any - unauthenticated users - - When designing and deploying new smart grid devices and - telecommunications systems, it is imperative to understand the - various impacts of these new components under a variety of attack - situations on the power grid. Consequences of a cyber attack on the - grid telecommunications network can be catastrophic. This is why - security for smart grid is not just an ad hoc feature or product, - it's a complete framework integrating both physical and Cyber - security requirements and covering the entire smart grid networks - from generation to distribution. Security has therefore become one - of the main foundations of the utility telecom network architecture - and must be considered at every layer with a defense-in-depth - approach. Migrating to IP based protocols is key to address these - challenges for two reasons: - - o IP enables a rich set of features and capabilities to enhance the - security posture - - o IP is based on open standards, which allows interoperability - between different vendors and products, driving down the costs - associated with implementing security solutions in OT networks. - - Securing OT (Operation technology) telecommunications over packet- - switched IP networks follow the same principles that are foundational - for securing the IT infrastructure, i.e., consideration must be given - to enforcing electronic access control for both person-to-machine and - machine-to-machine communications, and providing the appropriate - levels of data privacy, device and platform integrity, and threat - detection and mitigation. - - Existing power automation security standards can inform network - security. For example the NERC CIP (North American Electric - Reliability Corporation Critical Infrastructure Protection) plan is a - set of requirements designed to secure the assets required for - operating North America's bulk electric system. Another standardized - security control technique is Segmentation (zones and conduits - including access control). - - The requirements in Industrial Automation and Control Systems (IACS) - are quite similar, especially in new scenarios such as Industry 4.0/ - Digital Factory where workflows and protocols cross zones, segments, - and entities. IEC 62443 (ISA99) defines security for IACS, typically - for installations in other critical infrastructure such as oil and - gas. - - Availability and integrity are the most important security objectives - for the lower layers of such networks; confidentiality and privacy - are relevant if customer or market data is involved, typically - handled by higher layers. - -8.4.3. (BAS) Security Considerations (sec 4.2.4) - - When BAS field networks were developed it was assumed that the field - networks would always be physically isolated from external networks - and therefore security was not a concern. In today's world many BASs - are managed remotely and are thus connected to shared IP networks and - so security is definitely a concern, yet security features are not - available in the majority of BAS field network deployments . - - The management network, being an IP-based network, has the protocols - available to enable network security, but in practice many BAS - systems do not implement even the available security features such as - device authentication or encryption for data in transit. - -8.4.4. (6TiSCH) Security Considerations (sec 5.3.3) - - On top of the classical requirements for protection of control - signaling, it must be noted that 6TiSCH networks operate on limited - resources that can be depleted rapidly in a DoS attack on the system, - for instance by placing a rogue device in the network, or by - obtaining management control and setting up unexpected additional - paths. - -8.4.5. (Cellular radio) Security Considerations (sec 6.1.5) - - Establishing time-sensitive streams in the network entails reserving - networking resources for long periods of time. It is important that - these reservation requests be authenticated to prevent malicious - reservation attempts from hostile nodes (or accidental - misconfiguration). This is particularly important in the case where - the reservation requests span administrative domains. Furthermore, - the reservation information itself should be digitally signed to - reduce the risk of a legitimate node pushing a stale or hostile - configuration into another networking node. - - Note: This is considered important for the security policy of the - network, but does not affect the core DetNet architecture and design. - -8.4.6. (Industrial M2M) Communication Today (sec 7.2) - - Industrial network scenarios require advanced security solutions. - Many of the current industrial production networks are physically - separated. Preventing critical flows from be leaked outside a domain - is handled today by filtering policies that are typically enforced in - firewalls. - -9. IANA Considerations +8. IANA Considerations This memo includes no requests from IANA. -10. Security Considerations +9. Security Considerations The security considerations of DetNet networks are presented throughout this document. -11. Informative References +10. Informative References [ARINC664P7] ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics Full-Duplex Switched Ethernet Network", 2009. [I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane - Framework", draft-ietf-detnet-data-plane-framework-02 - (work in progress), September 2019. + Framework", draft-ietf-detnet-data-plane-framework-03 + (work in progress), October 2019. [I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", - draft-ietf-detnet-ip-03 (work in progress), October 2019. + draft-ietf-detnet-ip-04 (work in progress), November 2019. [I-D.ietf-detnet-ip-over-tsn] Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)", draft-ietf-detnet-ip-over-tsn-01 (work in progress), October 2019. [I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", - draft-ietf-detnet-mpls-03 (work in progress), October + draft-ietf-detnet-mpls-04 (work in progress), November 2019. [I-D.varga-detnet-service-model] Varga, B. and J. Farkas, "DetNet Service Model", draft- varga-detnet-service-model-02 (work in progress), May 2017. [IEEE1588] IEEE, "IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and @@ -2101,23 +1799,25 @@ 1275 Market Street San Francisco, CA 94103 USA Phone: +1 415 645 4726 Email: ethan.grossman@dolby.com URI: http://www.dolby.com Andrew J. Hacker MistIQ Technologies, Inc + Harrisburg, PA USA + Phone: Email: ajhacker@mistiqtech.com URI: http://www.mistiqtech.com Subir Das Applied Communication Sciences 150 Mount Airy Road, Basking Ridge New Jersey, 07920 USA Email: sdas@appcomsci.com