draft-ietf-detnet-security-04.txt   draft-ietf-detnet-security-05.txt 
Internet Engineering Task Force T. Mizrahi Internet Engineering Task Force T. Mizrahi
Internet-Draft HUAWEI Internet-Draft HUAWEI
Intended status: Informational E. Grossman, Ed. Intended status: Informational E. Grossman, Ed.
Expires: September 3, 2019 DOLBY Expires: March 1, 2020 DOLBY
A. Hacker A. Hacker
MISTIQ MISTIQ
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
J. Dowdell J. Dowdell
Airbus Defence and Space Airbus Defence and Space
H. Austad H. Austad
Cisco Systems Cisco Systems
K. Stanton K. Stanton
INTEL INTEL
N. Finn N. Finn
HUAWEI HUAWEI
March 2, 2019 August 29, 2019
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-04 draft-ietf-detnet-security-05
Abstract Abstract
A deterministic network is one that can carry data flows for real- A deterministic network is one that can carry data flows for real-
time applications with extremely low data loss rates and bounded time applications with extremely low data loss rates and bounded
latency. Deterministic networks have been successfully deployed in latency. Deterministic networks have been successfully deployed in
real-time operational technology (OT) applications for some years real-time operational technology (OT) applications for some years
(for example [ARINC664P7]). However, such networks are typically (for example [ARINC664P7]). However, such networks are typically
isolated from external access, and thus the security threat from isolated from external access, and thus the security threat from
external attackers is low. IETF Deterministic Networking (DetNet) external attackers is low. IETF Deterministic Networking (DetNet)
skipping to change at page 1, line 45 skipping to change at page 1, line 45
of a corporate network) potentially bringing the OT network into of a corporate network) potentially bringing the OT network into
contact with Information Technology (IT) traffic and security threats contact with Information Technology (IT) traffic and security threats
that lie outside of a tightly controlled and bounded area (such as that lie outside of a tightly controlled and bounded area (such as
the internals of an aircraft). These DetNet technologies have not the internals of an aircraft). These DetNet technologies have not
previously been deployed together on a wide area IP-based network, previously been deployed together on a wide area IP-based network,
and thus can present security considerations that may be new to IP- and thus can present security considerations that may be new to IP-
based wide area network designers. This draft, intended for use by based wide area network designers. This draft, intended for use by
DetNet network designers, provides insight into these security DetNet network designers, provides insight into these security
considerations. In addition, this draft collects all security- considerations. In addition, this draft collects all security-
related statements from the various DetNet drafts (Architecture, Use related statements from the various DetNet drafts (Architecture, Use
Cases, etc) into a single location Section 7. Cases, etc) into a single location Section 8.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2019. This Internet-Draft will expire on March 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7 3.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 7 3.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 7
3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7 3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7
3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7 3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 8
3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 8
3.2.4. Packet Replication and Elimination . . . . . . . . . 8 3.2.4. Packet Replication and Elimination . . . . . . . . . 8
3.2.4.1. Replication: Increased Attack Surface . . . . . . 8 3.2.4.1. Replication: Increased Attack Surface . . . . . . 8
3.2.4.2. Replication-related Header Manipulation . . . . . 8 3.2.4.2. Replication-related Header Manipulation . . . . . 8
3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 8 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 9
3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 9
3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9 3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9
3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9 3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9
3.2.6.1. Control or Signaling Packet Modification . . . . 9 3.2.6.1. Control or Signaling Packet Modification . . . . 9
3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9
3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9
3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9
3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 10
3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 10
4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 11
4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13
4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 13 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 14
4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14
4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14
4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14
4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 15
4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15
4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15
4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15
4.4. Replication and Elimination . . . . . . . . . . . . . . . 15 4.4. Replication and Elimination . . . . . . . . . . . . . . . 16
4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 16
4.4.2. Header Manipulation at Elimination Bridges . . . . . 16 4.4.2. Header Manipulation at Elimination Bridges . . . . . 16
4.5. Control or Signaling Packet Modification . . . . . . . . 16 4.5. Control or Signaling Packet Modification . . . . . . . . 16
4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16
4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16
4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16
4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16
5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 16 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 17
5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17
5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17
5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17
5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18
5.4.1. Encryption Considerations for DetNet . . . . . . . . 18 5.4.1. Encryption Considerations for DetNet . . . . . . . . 18
5.5. Control and Signaling Message Protection . . . . . . . . 19 5.5. Control and Signaling Message Protection . . . . . . . . 19
5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 19 5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 19
5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 20 5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 20
6. Association of Attacks to Use Cases . . . . . . . . . . . . . 21 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 21
6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 21 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 22
6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22
6.1.2. Central Administration . . . . . . . . . . . . . . . 22 6.1.2. Central Administration . . . . . . . . . . . . . . . 22
6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 22 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 22
6.1.4. Data Flow Information Models . . . . . . . . . . . . 23 6.1.4. Data Flow Information Models . . . . . . . . . . . . 23
6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 23 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 23
6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 23 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 24
6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 24 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 24
6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 24 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 24
6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25
6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 25 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 25
6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 25 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 26
6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 26 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 26
6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 26 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 26
6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 26 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 27
6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27
6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 27 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 27
6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28
6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 28 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 28
6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 28 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 28
6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29
6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29
6.1.22. Reliability and Availability . . . . . . . . . . . . 29 6.1.22. Reliability and Availability . . . . . . . . . . . . 29
6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 29 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 30
6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30
6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 30 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 30
6.3. Security Considerations for OAM Traffic . . . . . . . . . 32 6.3. Security Considerations for OAM Traffic . . . . . . . . . 33
7. Appendix A: DetNet Draft Security-Related Statements . . . . 32 7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33
7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 33 7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 33 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 33 7.3. TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 34 8. Appendix A: DetNet Draft Security-Related Statements . . . . 34
7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 34 8.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 34
7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 34 8.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 34
7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 34 8.1.2. Security Considerations (sec 7) . . . . . . . . . . . 35
7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 35 8.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 36
7.4.1. (Utility Networks) Security Current Practices and 8.2.1. Security Considerations (sec 7) . . . . . . . . . . . 36
Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 35 8.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 36
7.4.2. (Utility Networks) Security Trends in Utility 8.3.1. Security Considerations (sec 5) . . . . . . . . . . . 36
Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 36 8.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 37
7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 38 8.4.1. (Utility Networks) Security Current Practices and
7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 38 Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 37
7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 39 8.4.2. (Utility Networks) Security Trends in Utility
7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 39 Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 8.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 40
10. Informative References . . . . . . . . . . . . . . . . . . . 39 8.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 8.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 41
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. Informative References . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
Security is of particularly high importance in DetNet networks Security is of particularly high importance in DetNet networks
because many of the use cases which are enabled by DetNet because many of the use cases which are enabled by DetNet [RFC8578]
[I-D.ietf-detnet-use-cases] include control of physical devices include control of physical devices (power grid components,
(power grid components, industrial controls, building controls) which industrial controls, building controls) which can have high
can have high operational costs for failure, and present potentially operational costs for failure, and present potentially attractive
attractive targets for cyber-attackers. targets for cyber-attackers.
This situation is even more acute given that one of the goals of 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 DetNet is to provide a "converged network", i.e. one that includes
both IT traffic and OT traffic, thus exposing potentially sensitive both IT traffic and OT traffic, thus exposing potentially sensitive
OT devices to attack in ways that were not previously common (usually OT devices to attack in ways that were not previously common (usually
because they were under a separate control system or otherwise because they were under a separate control system or otherwise
isolated from the IT network). Security considerations for OT isolated from the IT network). Security considerations for OT
networks is not a new area, and there are many OT networks today that networks is not a new area, and there are many OT networks today that
are connected to wide area networks or the Internet; this draft are connected to wide area networks or the Internet; this draft
focuses on the issues that are specific to the DetNet technologies focuses on the issues that are specific to the DetNet technologies
skipping to change at page 5, line 32 skipping to change at page 5, line 41
o Provide explicit routes for DetNet flows that do not rapidly o Provide explicit routes for DetNet flows that do not rapidly
change with the network topology change with the network topology
o Distribute data from DetNet flow packets over time and/or space to 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 ensure delivery of each packet's data' in spite of the loss of a
path path
This draft includes sections on threat modeling and analysis, threat This draft includes sections on threat modeling and analysis, threat
impact and mitigation, and the association of attacks with use cases impact and mitigation, and the association of attacks with use cases
based on the Use Case Common Themes section of the DetNet Use Cases based on the Use Case Common Themes section of the DetNet Use Cases
draft [I-D.ietf-detnet-use-cases]. draft [RFC8578].
This draft also provides context for the DetNet security This draft also provides context for the DetNet security
considerations by collecting into one place Section 7 the various considerations by collecting into one place Section 8 the various
remarks about security from the various DetNet drafts (Use Cases, remarks about security from the various DetNet drafts (Use Cases,
Architecture, etc). This text is duplicated here primarily because Architecture, etc). This text is duplicated here primarily because
the DetNet working group has elected not to produce a Requirements the DetNet working group has elected not to produce a Requirements
draft and thus collectively these statements are as close as we have draft and thus collectively these statements are as close as we have
to "DetNet Security Requirements". to "DetNet Security Requirements".
2. Abbreviations 2. Abbreviations
IT Information technology (the application of computers to IT Information technology (the application of computers to
store, study, retrieve, transmit, and manipulate data or information, store, study, retrieve, transmit, and manipulate data or information,
skipping to change at page 6, line 21 skipping to change at page 6, line 33
DREAD Compares and prioritizes risk represented by these threat DREAD Compares and prioritizes risk represented by these threat
categories: Damage potential, Reproducibility, Exploitability, how categories: Damage potential, Reproducibility, Exploitability, how
many Affected users, Discoverability. many Affected users, Discoverability.
PTP Precision Time Protocol [IEEE1588] PTP Precision Time Protocol [IEEE1588]
3. Security Threats 3. Security Threats
This section presents a threat model, and analyzes the possible This section presents a threat model, and analyzes the possible
threats in a DetNet-enabled network. threats in a DetNet-enabled network. The threats considered in this
section are independent of any specific technologies used to
implement the DetNet; Section 7) considers attacks that are
associated with the DetNet technologies encompassed by
[I-D.ietf-detnet-data-plane-framework].
We distinguish control plane threats from data plane threats. The We distinguish control plane threats from data plane threats. The
attack surface may be the same, but the types of attacks as well as attack surface may be the same, but the types of attacks as well as
the motivation behind them, are different. For example, a delay the motivation behind them, are different. For example, a delay
attack is more relevant to data plane than to control plane. There attack is more relevant to data plane than to control plane. There
is also a difference in terms of security solutions: the way you is also a difference in terms of security solutions: the way you
secure the data plane is often different than the way you secure the secure the data plane is often different than the way you secure the
control plane. control plane.
3.1. Threat Model 3.1. Threat Model
skipping to change at page 11, line 9 skipping to change at page 11, line 23
be measured in loss of confidentiality, integrity or availability of be measured in loss of confidentiality, integrity or availability of
information. information.
DetNet raises these stakes significantly for OT applications, DetNet raises these stakes significantly for OT applications,
particularly those which may have been designed to run in an OT-only 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 and thus may not have been designed for security in an IT
environment with its associated devices, services and protocols. environment with its associated devices, services and protocols.
The severity of various components of the impact of a successful The severity of various components of the impact of a successful
vulnerability exploit to use cases by industry is available in more vulnerability exploit to use cases by industry is available in more
detail in [I-D.ietf-detnet-use-cases]. Each of the use cases in the detail in [RFC8578]. Each of the use cases in the DetNet Use Cases
DetNet Use Cases draft is represented in the table below, including draft is represented in the table below, including Pro Audio,
Pro Audio, Electrical Utilities, Industrial M2M (split into two Electrical Utilities, Industrial M2M (split into two areas, M2M Data
areas, M2M Data Gathering and M2M Control Loop), and others. Gathering and M2M Control Loop), and others.
Components of Impact (left column) include Criticality of Failure, Components of Impact (left column) include Criticality of Failure,
Effects of Failure, Recovery, and DetNet Functional Dependence. Effects of Failure, Recovery, and DetNet Functional Dependence.
Criticality of failure summarizes the seriousness of the impact. The Criticality of failure summarizes the seriousness of the impact. The
impact of a resulting failure can affect many different metrics that impact of a resulting failure can affect many different metrics that
vary greatly in scope and severity. In order to reduce the number of vary greatly in scope and severity. In order to reduce the number of
variables, only the following were included: Financial, Health and variables, only the following were included: Financial, Health and
Safety, People well being, Affect on a single organization, and Safety, People well being, Affect on a single organization, and
affect on multiple organizations. Recovery outlines how long it affect on multiple organizations. Recovery outlines how long it
would take for an affected use case to get back to its pre-failure would take for an affected use case to get back to its pre-failure
skipping to change at page 21, line 36 skipping to change at page 21, line 45
Figure 3: Mapping Attacks to Impact and Mitigations Figure 3: Mapping Attacks to Impact and Mitigations
6. Association of Attacks to Use Cases 6. Association of Attacks to Use Cases
Different attacks can have different impact and/or mitigation Different attacks can have different impact and/or mitigation
depending on the use case, so we would like to make this association depending on the use case, so we would like to make this association
in our analysis. However since there is a potentially unbounded list in our analysis. However since there is a potentially unbounded list
of use cases, we categorize the attacks with respect to the common 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 themes of the use cases as identified in the Use Case Common Themes
section of the DetNet Use Cases draft [I-D.ietf-detnet-use-cases]. section of the DetNet Use Cases draft [RFC8578].
See also Figure 2 for a mapping of the impact of attacks per use case See also Figure 2 for a mapping of the impact of attacks per use case
by industry. by industry.
6.1. Use Cases by Common Themes 6.1. Use Cases by Common Themes
In this section we review each theme and discuss the attacks that are In this section we review each theme and discuss the attacks that are
applicable to that theme, as well as anything specific about the applicable to that theme, as well as anything specific about the
impact and mitigations for that attack with respect to that theme. impact and mitigations for that attack with respect to that theme.
The table Figure 5 then provides a summary of the attacks that are The table Figure 5 then provides a summary of the attacks that are
skipping to change at page 32, line 44 skipping to change at page 33, line 28
security considerations as any other DetNet data flow) and are security considerations as any other DetNet data flow) and are
thus not covered in this document. thus not covered in this document.
o OAM traffic generated by the customer. From a DetNet security o OAM traffic generated by the customer. From a DetNet security
point of view, DetNet security considerations for such traffic are point of view, DetNet security considerations for such traffic are
exactly the same as for any other customer data flows. exactly the same as for any other customer data flows.
Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet
security considerations. security considerations.
7. Appendix A: DetNet Draft Security-Related Statements 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.
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.
As noted in [I-D.ietf-detnet-architecture], 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 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.
Sections below discuss threats specific to IP, MPLS, and TSN 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.
7.2. MPLS
Editor's Note: To Be Written.
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 This section collects the various statements in the currently
existing DetNet Working Group drafts. For each draft, the section existing DetNet Working Group drafts. For each draft, the section
name and number of the quoted section is shown. The text shown here 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 is the work of the original draft authors, quoted verbatim from the
drafts. The intention is to explicitly quote all relevant text, not drafts. The intention is to explicitly quote all relevant text, not
to summarize it. to summarize it.
7.1. Architecture (draft 8) 8.1. Architecture (draft 8)
7.1.1. Fault Mitigation (sec 4.5) 8.1.1. Fault Mitigation (sec 4.5)
One key to building robust real-time systems is to reduce the One key to building robust real-time systems is to reduce the
infinite variety of possible failures to a number that can be infinite variety of possible failures to a number that can be
analyzed with reasonable confidence. DetNet aids in the process by analyzed with reasonable confidence. DetNet aids in the process by
providing filters and policers to detect DetNet packets received on providing filters and policers to detect DetNet packets received on
the wrong interface, or at the wrong time, or in too great a volume, 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, and to then take actions such as discarding the offending packet,
shutting down the offending DetNet flow, or shutting down the shutting down the offending DetNet flow, or shutting down the
offending interface. offending interface.
skipping to change at page 33, line 32 skipping to change at page 35, line 21
There exist techniques, at present and/or in various stages of There exist techniques, at present and/or in various stages of
standardization, that can perform these fault mitigation tasks that standardization, that can perform these fault mitigation tasks that
deliver a high probability that misbehaving systems will have zero deliver a high probability that misbehaving systems will have zero
impact on well-behaved DetNet flows, except of course, for the impact on well-behaved DetNet flows, except of course, for the
receiving interface(s) immediately downstream of the misbehaving receiving interface(s) immediately downstream of the misbehaving
device. Examples of such techniques include traffic policing device. Examples of such techniques include traffic policing
functions (e.g. [RFC2475]) and separating flows into per-flow rate- functions (e.g. [RFC2475]) and separating flows into per-flow rate-
limited queues. limited queues.
7.1.2. Security Considerations (sec 7) 8.1.2. Security Considerations (sec 7)
Security in the context of Deterministic Networking has an added Security in the context of Deterministic Networking has an added
dimension; the time of delivery of a packet can be just as important 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, as the contents of the packet, itself. A man-in-the-middle attack,
for example, can impose, and then systematically adjust, additional for example, can impose, and then systematically adjust, additional
delays into a link, and thus disrupt or subvert a real-time delays into a link, and thus disrupt or subvert a real-time
application without having to crack any encryption methods employed. application without having to crack any encryption methods employed.
See [RFC7384] for an exploration of this issue in a related context. See [RFC7384] for an exploration of this issue in a related context.
Furthermore, in a control system where millions of dollars of Furthermore, in a control system where millions of dollars of
skipping to change at page 34, line 11 skipping to change at page 36, line 5
accidental or intentional. accidental or intentional.
Security must cover: Security must cover:
o Protection of the signaling protocol o Protection of the signaling protocol
o Authentication and authorization of the controlling nodes o Authentication and authorization of the controlling nodes
o Identification and shaping of the flows o Identification and shaping of the flows
7.2. Data Plane Alternatives (draft 4) 8.2. Data Plane Alternatives (draft 4)
7.2.1. Security Considerations (sec 7) 8.2.1. Security Considerations (sec 7)
This document does not add any new security considerations beyond This document does not add any new security considerations beyond
what the referenced technologies already have. what the referenced technologies already have.
7.3. Problem Statement (draft 5) 8.3. Problem Statement (draft 5)
7.3.1. Security Considerations (sec 5) 8.3.1. Security Considerations (sec 5)
Security in the context of Deterministic Networking has an added Security in the context of Deterministic Networking has an added
dimension; the time of delivery of a packet can be just as important 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, as the contents of the packet, itself. A man-in-the-middle attack,
for example, can impose, and then systematically adjust, additional for example, can impose, and then systematically adjust, additional
delays into a link, and thus disrupt or subvert a real-time delays into a link, and thus disrupt or subvert a real-time
application without having to crack any encryption methods employed. application without having to crack any encryption methods employed.
See [RFC7384] for an exploration of this issue in a related context. See [RFC7384] for an exploration of this issue in a related context.
Typical control networks today rely on complete physical isolation to Typical control networks today rely on complete physical isolation to
skipping to change at page 35, line 4 skipping to change at page 36, line 46
individual flows which have no clue whether the resources are used by individual flows which have no clue whether the resources are used by
other flows at other times. other flows at other times.
Security must cover: Security must cover:
o Protection of the signaling protocol o Protection of the signaling protocol
o Authentication and authorization of the controlling nodes o Authentication and authorization of the controlling nodes
o Identification and shaping of the flows o Identification and shaping of the flows
o Isolation of flows from leakage and other influences from any o Isolation of flows from leakage and other influences from any
activity sharing physical resources activity sharing physical resources
7.4. Use Cases (draft 11) 8.4. Use Cases (draft 11)
7.4.1. (Utility Networks) Security Current Practices and Limitations 8.4.1. (Utility Networks) Security Current Practices and Limitations
(sec 3.2.1) (sec 3.2.1)
Grid monitoring and control devices are already targets for cyber Grid monitoring and control devices are already targets for cyber
attacks, and legacy telecommunications protocols have many intrinsic attacks, and legacy telecommunications protocols have many intrinsic
network-related vulnerabilities. For example, DNP3, Modbus, network-related vulnerabilities. For example, DNP3, Modbus,
PROFIBUS/PROFINET, and other protocols are designed around a common PROFIBUS/PROFINET, and other protocols are designed around a common
paradigm of request and respond. Each protocol is designed for a paradigm of request and respond. Each protocol is designed for a
master device such as an HMI (Human Machine Interface) system to send master device such as an HMI (Human Machine Interface) system to send
commands to subordinate slave devices to retrieve data (reading commands to subordinate slave devices to retrieve data (reading
inputs) or control (writing to outputs). Because many of these inputs) or control (writing to outputs). Because many of these
skipping to change at page 36, line 27 skipping to change at page 38, line 23
between IT an OT networks, make network-based attacks very between IT an OT networks, make network-based attacks very
feasible. feasible.
o Simple injection of malicious protocol commands provides control o Simple injection of malicious protocol commands provides control
over the target process. Altering legitimate protocol traffic can over the target process. Altering legitimate protocol traffic can
also alter information about a process and disrupt the legitimate also alter information about a process and disrupt the legitimate
controls that are in place over that process. A man-in-the-middle controls that are in place over that process. A man-in-the-middle
attack could provide both control over a process and attack could provide both control over a process and
misrepresentation of data back to operator consoles. misrepresentation of data back to operator consoles.
7.4.2. (Utility Networks) Security Trends in Utility Networks (sec 8.4.2. (Utility Networks) Security Trends in Utility Networks (sec
3.3.3) 3.3.3)
Although advanced telecommunications networks can assist in Although advanced telecommunications networks can assist in
transforming the energy industry by playing a critical role in transforming the energy industry by playing a critical role in
maintaining high levels of reliability, performance, and maintaining high levels of reliability, performance, and
manageability, they also introduce the need for an integrated manageability, they also introduce the need for an integrated
security infrastructure. Many of the technologies being deployed to security infrastructure. Many of the technologies being deployed to
support smart grid projects such as smart meters and sensors can support smart grid projects such as smart meters and sensors can
increase the vulnerability of the grid to attack. Top security increase the vulnerability of the grid to attack. Top security
concerns for utilities migrating to an intelligent smart grid concerns for utilities migrating to an intelligent smart grid
skipping to change at page 38, line 33 skipping to change at page 40, line 30
Digital Factory where workflows and protocols cross zones, segments, Digital Factory where workflows and protocols cross zones, segments,
and entities. IEC 62443 (ISA99) defines security for IACS, typically and entities. IEC 62443 (ISA99) defines security for IACS, typically
for installations in other critical infrastructure such as oil and for installations in other critical infrastructure such as oil and
gas. gas.
Availability and integrity are the most important security objectives Availability and integrity are the most important security objectives
for the lower layers of such networks; confidentiality and privacy for the lower layers of such networks; confidentiality and privacy
are relevant if customer or market data is involved, typically are relevant if customer or market data is involved, typically
handled by higher layers. handled by higher layers.
7.4.3. (BAS) Security Considerations (sec 4.2.4) 8.4.3. (BAS) Security Considerations (sec 4.2.4)
When BAS field networks were developed it was assumed that the field When BAS field networks were developed it was assumed that the field
networks would always be physically isolated from external networks networks would always be physically isolated from external networks
and therefore security was not a concern. In today's world many BASs 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 are managed remotely and are thus connected to shared IP networks and
so security is definitely a concern, yet security features are not so security is definitely a concern, yet security features are not
available in the majority of BAS field network deployments . available in the majority of BAS field network deployments .
The management network, being an IP-based network, has the protocols The management network, being an IP-based network, has the protocols
available to enable network security, but in practice many BAS available to enable network security, but in practice many BAS
systems do not implement even the available security features such as systems do not implement even the available security features such as
device authentication or encryption for data in transit. device authentication or encryption for data in transit.
7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) 8.4.4. (6TiSCH) Security Considerations (sec 5.3.3)
On top of the classical requirements for protection of control On top of the classical requirements for protection of control
signaling, it must be noted that 6TiSCH networks operate on limited signaling, it must be noted that 6TiSCH networks operate on limited
resources that can be depleted rapidly in a DoS attack on the system, 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 for instance by placing a rogue device in the network, or by
obtaining management control and setting up unexpected additional obtaining management control and setting up unexpected additional
paths. paths.
7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 8.4.5. (Cellular radio) Security Considerations (sec 6.1.5)
Establishing time-sensitive streams in the network entails reserving Establishing time-sensitive streams in the network entails reserving
networking resources for long periods of time. It is important that networking resources for long periods of time. It is important that
these reservation requests be authenticated to prevent malicious these reservation requests be authenticated to prevent malicious
reservation attempts from hostile nodes (or accidental reservation attempts from hostile nodes (or accidental
misconfiguration). This is particularly important in the case where misconfiguration). This is particularly important in the case where
the reservation requests span administrative domains. Furthermore, the reservation requests span administrative domains. Furthermore,
the reservation information itself should be digitally signed to the reservation information itself should be digitally signed to
reduce the risk of a legitimate node pushing a stale or hostile reduce the risk of a legitimate node pushing a stale or hostile
configuration into another networking node. configuration into another networking node.
Note: This is considered important for the security policy of the Note: This is considered important for the security policy of the
network, but does not affect the core DetNet architecture and design. network, but does not affect the core DetNet architecture and design.
7.4.6. (Industrial M2M) Communication Today (sec 7.2) 8.4.6. (Industrial M2M) Communication Today (sec 7.2)
Industrial network scenarios require advanced security solutions. Industrial network scenarios require advanced security solutions.
Many of the current industrial production networks are physically Many of the current industrial production networks are physically
separated. Preventing critical flows from be leaked outside a domain separated. Preventing critical flows from be leaked outside a domain
is handled today by filtering policies that are typically enforced in is handled today by filtering policies that are typically enforced in
firewalls. firewalls.
8. IANA Considerations 9. IANA Considerations
This memo includes no requests from IANA. This memo includes no requests from IANA.
9. Security Considerations 10. Security Considerations
The security considerations of DetNet networks are presented The security considerations of DetNet networks are presented
throughout this document. throughout this document.
10. Informative References 11. Informative References
[ARINC664P7] [ARINC664P7]
ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics
Full-Duplex Switched Ethernet Network", 2009. Full-Duplex Switched Ethernet Network", 2009.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-11 (work in progress), February 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-data-plane-framework]
Grossman, E., "Deterministic Networking Use Cases", draft- Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
ietf-detnet-use-cases-20 (work in progress), December Bryant, S., and J. Korhonen, "DetNet Data Plane
2018. Framework", draft-ietf-detnet-data-plane-framework-01
(work in progress), July 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-01 (work in progress), July 2019.
[I-D.ietf-detnet-ip-over-tsn]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time
Sensitive Networking (TSN)", draft-ietf-detnet-ip-over-
tsn-00 (work in progress), May 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-01 (work in progress), July 2019.
[I-D.varga-detnet-service-model] [I-D.varga-detnet-service-model]
Varga, B. and J. Farkas, "DetNet Service Model", draft- Varga, B. and J. Farkas, "DetNet Service Model", draft-
varga-detnet-service-model-02 (work in progress), May varga-detnet-service-model-02 (work in progress), May
2017. 2017.
[IEEE1588] [IEEE1588]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems Version 2", 2008. Control Systems Version 2", 2008.
[IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>.
[MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/ [MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/
hacked-cameras-dvrs-powered-todays-massive-internet- hacked-cameras-dvrs-powered-todays-massive-internet-
outage/", 2016. outage/", 2016.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>.
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
Email: tal.mizrahi.phd@gmail.com Email: tal.mizrahi.phd@gmail.com
Ethan Grossman (editor) Ethan Grossman (editor)
Dolby Laboratories, Inc. Dolby Laboratories, Inc.
1275 Market Street 1275 Market Street
 End of changes. 49 change blocks. 
82 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/