--- 1/draft-ietf-detnet-security-03.txt 2019-03-02 17:13:09.271225542 -0800 +++ 2/draft-ietf-detnet-security-04.txt 2019-03-02 17:13:09.355227588 -0800 @@ -1,31 +1,31 @@ Internet Engineering Task Force T. Mizrahi Internet-Draft HUAWEI Intended status: Informational E. Grossman, Ed. -Expires: April 19, 2019 DOLBY +Expires: September 3, 2019 DOLBY A. Hacker MISTIQ S. Das Applied Communication Sciences J. Dowdell Airbus Defence and Space H. Austad Cisco Systems K. Stanton INTEL N. Finn HUAWEI - October 16, 2018 + March 2, 2019 Deterministic Networking (DetNet) Security Considerations - draft-ietf-detnet-security-03 + draft-ietf-detnet-security-04 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 (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) @@ -51,25 +51,25 @@ 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 April 19, 2019. + This Internet-Draft will expire on September 3, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 @@ -107,83 +107,84 @@ 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 . . . . . . . . . . . . . . 15 - 4.4.2. Header Manipulation at Elimination Bridges . . . . . 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.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17 - 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.5. Control and Signaling Message Protection . . . . . . . . 18 - 5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 18 - 5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 18 - 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 20 - 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 20 - 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 20 - 6.1.2. Central Administration . . . . . . . . . . . . . . . 21 - 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 21 - 6.1.4. Data Flow Information Models . . . . . . . . . . . . 22 - 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 22 - 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 22 - 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 23 - 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 23 - 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 23 - 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 24 - 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 24 - 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 24 - 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 25 - 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 25 - 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 25 - 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 26 - 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 26 - 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 27 - 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 27 - 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 27 - 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 27 - 6.1.22. Reliability and Availability . . . . . . . . . . . . 28 - 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 28 - 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 28 - 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 28 - 6.3. Security Considerations for OAM Traffic . . . . . . . . . 31 - 7. Appendix A: DetNet Draft Security-Related Statements . . . . 31 - 7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 31 - 7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 31 - 7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 32 - 7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 32 - 7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 32 - 7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 33 - 7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 33 - 7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 33 + 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.4.1. Encryption Considerations for DetNet . . . . . . . . 18 + 5.5. Control and Signaling Message Protection . . . . . . . . 19 + 5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 19 + 5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 20 + 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 21 + 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 21 + 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22 + 6.1.2. Central Administration . . . . . . . . . . . . . . . 22 + 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 22 + 6.1.4. Data Flow Information Models . . . . . . . . . . . . 23 + 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 23 + 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 23 + 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 24 + 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 24 + 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25 + 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 25 + 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 25 + 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 26 + 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 26 + 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 26 + 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27 + 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 27 + 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28 + 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 28 + 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 28 + 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29 + 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29 + 6.1.22. Reliability and Availability . . . . . . . . . . . . 29 + 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 29 + 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30 + 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 30 + 6.3. Security Considerations for OAM Traffic . . . . . . . . . 32 + 7. Appendix A: DetNet Draft Security-Related Statements . . . . 32 + 7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 33 + 7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 33 + 7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 33 + 7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 34 + 7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 34 + 7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 34 + 7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 34 + 7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 35 7.4.1. (Utility Networks) Security Current Practices and - Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 33 + Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 35 7.4.2. (Utility Networks) Security Trends in Utility - Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 35 - 7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 36 - 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 37 - 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 37 - 7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 37 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 - 10. Informative References . . . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 + Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 36 + 7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 38 + 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 38 + 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 39 + 7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 39 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 + 10. Informative References . . . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction Security is of particularly high importance in DetNet networks because many of the use cases which are enabled by DetNet [I-D.ietf-detnet-use-cases] 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. @@ -593,20 +594,26 @@ 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. 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 + machine's control loop can become unstable. + 4.1.2. Control Plane Delay Attacks In and of itself, this is not directly a threat to the DetNet service, but the effects of delaying control messages can have quite adverse effects later. o Delayed tear-down can lead to resource leakage, which in turn can result in failure to allocate new streams finally giving rise to a denial of service attack. @@ -793,23 +798,74 @@ Section 3.2.4. 5.4. Encryption Description DetNet flows can be forwarded in encrypted form. Related attacks - While confidentiality is not considered an important goal with - respect to DetNet, encryption can be used to mitigate recon - attacks (Section 3.2.7). + Encryption can be used to mitigate recon attacks (Section 3.2.7). + However, for a DetNet network to give differentiated quality of + service on a flow-by-flow basis, the network must be able to + identify the flows individually. This implies that in a recon + attack the attacker may also be able to track individual flows to + learn more about the system. + + Encryption can also provide traffic origin verification, i.e. to + verify that each packet in a DetNet flow is from a trusted source, + for example as part of ingress filtering. + +5.4.1. Encryption Considerations for DetNet + + Any compute time which is required for encryption and decryption + processing ('crypto') must be included in the flow latency + calculations. Thus, crypto algorithms used in a DetNet must have + bounded worst-case execution times, and these values must be used in + the latency calculations. + + Some crypto algorithms are symmetric in encode/decode time (such as + AES) and others are asymmetric (such as public key algorithms). + There are advantages and disadvantages to the use of either type in a + given DetNet context. + + Asymmetrical crypto is typically not used in networks on a packet-by- + packet basis due to its computational cost. For example, if only + endpoint checks or checks at a small number of intermediate points + are required, asymmetric crypto can be used to authenticate + distribution or exchange of a secret symmetric crypto key; a + successful check based on that key will provide traffic origin + verification, as long as the key is kept secret by the participants. + TLS and IKE (for IPsec) are examples of this for endpoint checks. + + However, if secret symmetrical keys are used for this purpose the key + must be given to all relays, which increases the probability of a + secret key being leaked. Also, if any relay is compromised or + misbehaving it may inject traffic into the flow. + + Alternatively, asymmetric crypto can provide traffic origin + verification at every intermediate node. For example, a DetNet flow + can be associated with an (asymmetric) keypair, such that the private + key is available to the source of the flow and the public key is + distributed with the flow information, allowing verification at every + node for every packet. However, this is more computationally + expensive. + + In either case, origin verification also requires replay detection as + part of the security protocol to prevent an attacker from recording + and resending traffic, e.g., as a denial of service attack on flow + forwarding resources. + + If crypto keys are to be regenerated over the duration of the flow + then the time required to accomplish this must be accounted for in + the latency calculations. 5.5. Control and Signaling Message Protection Description Control and sigaling messages can be protected using authentication and integrity protection mechanisms. Related attacks @@ -828,22 +884,29 @@ and monitoring of packet arrival times. Unusual behavior or potentially malicious nodes can be reported to a management system, or can be used as a trigger for taking corrective actions. The information can be tracked by DetNet end systems and transit nodes, and exported to a management system, for example using NETCONF. Related attacks Performance analytics can be used to mitigate various attacks, - including the ones described in Section 3.2.1, Section 3.2.3, and - Section 3.2.8. + including the ones described in Section 3.2.1 (Delay Attack), + Section 3.2.3 (Resource Segmentation Attack), and Section 3.2.8 + (Time Sync Attack). + + For example, in the case of data plane delay attacks, one possible + mitigation is to timestamp the data at the source, and timestamp + it again at the destination, and if the resulting latency exceeds + the promised bound, discard that data and warn the operator (and/ + or enter a fail-safe mode). 5.7. Mitigation Summary The following table maps the attacks of Section 3 to the impacts of Section 4, and to the mitigations of the current section. Each row specifies an attack, the impact of this attack if it is successfully implemented, and possible mitigation methods. +----------------------+---------------------+---------------------+ | Attack | Impact | Mitigations | @@ -1685,20 +1746,40 @@ 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. + 7.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 @@ -1749,25 +1830,25 @@ 10. Informative References [ARINC664P7] ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics Full-Duplex Switched Ethernet Network", 2009. [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- - detnet-architecture-08 (work in progress), September 2018. + detnet-architecture-11 (work in progress), February 2019. [I-D.ietf-detnet-use-cases] Grossman, E., "Deterministic Networking Use Cases", draft- - ietf-detnet-use-cases-18 (work in progress), September + ietf-detnet-use-cases-20 (work in progress), December 2018. [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