draft-ietf-detnet-security-00.txt   draft-ietf-detnet-security-01.txt 
Internet Engineering Task Force T. Mizrahi Internet Engineering Task Force T. Mizrahi
Internet-Draft MARVELL Internet-Draft MARVELL
Intended status: Informational E. Grossman, Ed. Intended status: Informational E. Grossman, Ed.
Expires: April 2, 2018 DOLBY Expires: May 3, 2018 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
September 29, 2017 October 30, 2017
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-00 draft-ietf-detnet-security-01
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 2, line 20 skipping to change at page 2, line 20
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 April 2, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5
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 Identification . . . . . . . . . . . . . 7 3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7
3.2.2.1. DetNet Flow Modification or Spoofing . . . . . . 7
3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7 3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7
3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7
3.2.4. Packet Replication and Elimination . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 8
3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8
3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 8 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 . . . . . . . . . . . 9
3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9
4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10
4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 11 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13
4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 11 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 13
4.2. Flow Identification and Spoofing . . . . . . . . . . . . 11 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14
4.2.1. Flow identification . . . . . . . . . . . . . . . . . 11 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14
4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 12 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14
4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 12 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14
4.3. Segmentation attacks (injection) . . . . . . . . . . . . 12 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15
4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 12 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15
4.3.2. Control Plane segmentation . . . . . . . . . . . . . 13 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15
4.4. Replication and Elimination . . . . . . . . . . . . . . . 13 4.4. Replication and Elimination . . . . . . . . . . . . . . . 15
4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 13 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15
4.4.2. Header Manipulation at Elimination Bridges . . . . . 13 4.4.2. Header Manipulation at Elimination Bridges . . . . . 15
4.5. Impact of Attacks to Path Choice . . . . . . . . . . . . 13 4.5. Control or Signaling Packet Modification . . . . . . . . 16
4.6. Impact of Attacks by Use Case Industry . . . . . . . . . 13 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16
5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 16
5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 16 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17
5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 16 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17
5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Control and Signaling Message Protection . . . . . . . . 17 5.5. Control and Signaling Message Protection . . . . . . . . 18
5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 17 5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 18
5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 18 5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 18
6. Association of Attacks to Use Cases . . . . . . . . . . . . . 19 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 20
6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 19 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 20
6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 19 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 20
6.1.2. Central Administration . . . . . . . . . . . . . . . 19 6.1.2. Central Administration . . . . . . . . . . . . . . . 21
6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 20 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 21
6.1.4. Data Flow Information Models . . . . . . . . . . . . 20 6.1.4. Data Flow Information Models . . . . . . . . . . . . 22
6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 20 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 22
6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 20 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 22
6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 20 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 23
6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 20 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 23
6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 21 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 23
6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 21 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 24
6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 21 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 24
6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 21 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 24
6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 21 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 25
6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 22 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 25
6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 22 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 25
6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 22 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 26
6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 22 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 26
6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 23 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 27
6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 23 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 27
6.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 23 6.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 27
6.1.21. Reliability and Availability . . . . . . . . . . . . 23 6.1.21. Reliability and Availability . . . . . . . . . . . . 27
6.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 24 6.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 28
6.1.23. Security Measures . . . . . . . . . . . . . . . . . . 24 6.1.23. Security Measures . . . . . . . . . . . . . . . . . . 28
6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 24 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 28
7. Appendix A: DetNet Draft Security-Related Statements . . . . 26 7. Appendix A: DetNet Draft Security-Related Statements . . . . 30
7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 27 7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 31
7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 27 7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 31
7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 27 7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 31
7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 28 7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 32
7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 28 7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 32
7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 28 7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 32
7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 28 7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 32
7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 29 7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 33
7.4.1. (Utility Networks) Security Current Practices and 7.4.1. (Utility Networks) Security Current Practices and
Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 29 Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 33
7.4.2. (Utility Networks) Security Trends in Utility 7.4.2. (Utility Networks) Security Trends in Utility
Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 30 Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 34
7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 32 7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 36
7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 32 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 36
7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 32 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 36
7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 33 7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Informative References . . . . . . . . . . . . . . . . . . . 33 10. Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
[I-D.ietf-detnet-use-cases] include control of physical devices [I-D.ietf-detnet-use-cases] include control of physical devices
(power grid components, industrial controls, building controls) which (power grid components, industrial controls, building controls) which
can have high operational costs for failure, and present potentially can have high operational costs for failure, and present potentially
attractive targets for cyber-attackers. attractive targets for cyber-attackers.
skipping to change at page 5, line 25 skipping to change at page 5, line 27
the flow the flow
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 various attacks with impact and mitigation, and the association of attacks with use cases
various use cases both by industry and based on the Use Case Common based on the Use Case Common Themes section of the DetNet Use Cases
Themes section of the DetNet Use Cases draft draft [I-D.ietf-detnet-use-cases].
[I-D.ietf-detnet-use-cases].
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 7 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
skipping to change at page 6, line 20 skipping to change at page 6, line 22
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.
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 are attack surface may be the same, but the types of attacks as well as
different. For example, a delay attack is more relevant to data the motivation behind them, are different. For example, a delay
plane than to control plane. There is also a difference in terms of attack is more relevant to data plane than to control plane. There
security solutions: the way you secure the data plane is often is also a difference in terms of security solutions: the way you
different than the way you secure the control plane. secure the data plane is often different than the way you secure the
control plane.
3.1. Threat Model 3.1. Threat Model
The threat model used in this memo is based on the threat model of The threat model used in this memo is based on the threat model of
Section 3.1 of [RFC7384]. This model classifies attackers based on Section 3.1 of [RFC7384]. This model classifies attackers based on
two criteria: two criteria:
o Internal vs. external: internal attackers either have access to a o Internal vs. external: internal attackers either have access to a
trusted segment of the network or possess the encryption or trusted segment of the network or possess the encryption or
authentication keys. External attackers, on the other hand, do authentication keys. External attackers, on the other hand, do
not have the keys and have access only to the encrypted or not have the keys and have access only to the encrypted or
authenticated traffic. authenticated traffic.
o Man in the Middle (MITM) vs. packet injector: MITM attackers are o Man in the Middle (MITM) vs. packet injector: MITM attackers are
located in a position that allows interception and modification of located in a position that allows interception and modification of
in-flight protocol packets, whereas a traffic injector can only in-flight protocol packets, whereas a traffic injector can only
attack by generating protocol packets. attack by generating protocol packets.
Care has also been taken to adhere to Section 5 of [RFC3552], both
with respect to what attacks are considered out-of-scope for this
document, but also what is considered to be the most common threats
(explored furhter 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 DetNet-Service, one of the service scenarios described in
[I-D.varga-detnet-service-model], is the case where a service [I-D.varga-detnet-service-model], is the case where a service
connects DetNet networking islands, i.e. two or more otherwise connects DetNet networking islands, i.e. two or more otherwise
independent DetNet network domains are connected via a link that is independent DetNet network domains are connected via a link that is
not intrinsically part of either network. This implies that there not intrinsically part of either network. This implies that there
could be DetNet traffic flowing over a non-DetNet link, which may could be DetNet traffic flowing over a non-DetNet link, which may
provide an attacker with an advantageous opportunity to tamper with provide an attacker with an advantageous opportunity to tamper with
DetNet traffic. The security properties of non-DetNet links are DetNet traffic. The security properties of non-DetNet links are
outside of the scope of DetNet Security, but it should be noted that outside of the scope of DetNet Security, but it should be noted that
use of non-DetNet services to interconnect DetNet networks merits use of non-DetNet services to interconnect DetNet networks merits
skipping to change at page 7, line 19 skipping to change at page 7, line 31
3.2.1. Delay 3.2.1. Delay
3.2.1.1. Delay Attack 3.2.1.1. Delay Attack
An attacker can maliciously delay DetNet data flow traffic. By An attacker can maliciously delay DetNet data flow traffic. By
delaying the traffic, the attacker can compromise the service of delaying the traffic, the attacker can compromise the service of
applications that are sensitive to high delays or to high delay applications that are sensitive to high delays or to high delay
variation. variation.
3.2.2. DetNet Flow Identification 3.2.2. DetNet Flow Modification or Spoofing
3.2.2.1. DetNet Flow Modification or Spoofing
An attacker can modify some header fields of en route packets in a An attacker can modify some header fields of en route packets in a
way that causes the DetNet flow identification mechanisms to way that causes the DetNet flow identification mechanisms to
misclassify the flow. Alternatively, the attacker can inject traffic misclassify the flow. Alternatively, the attacker can inject traffic
that is tailored to appear as if it belongs to a legitimate DetNet that is tailored to appear as if it belongs to a legitimate DetNet
flow. The potential consequence is that the DetNet flow resource flow. The potential consequence is that the DetNet flow resource
allocation cannot guarantee the performance that is expected when the allocation cannot guarantee the performance that is expected when the
flow identification works correctly. flow identification works correctly.
Note that in some cases there may be 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 and/or integrity-protected from
external attackers.
3.2.3. Resource Segmentation or Slicing 3.2.3. Resource Segmentation or Slicing
3.2.3.1. Inter-segment Attack 3.2.3.1. Inter-segment Attack
An attacker can inject traffic, consuming network device resources, An attacker can inject traffic, consuming network device resources,
thereby affecting DetNet flows. This can be performed using non- thereby affecting DetNet flows. This can be performed using non-
DetNet traffic that affects DetNet traffic, or by using DetNet DetNet traffic that affects DetNet traffic, or by using DetNet
traffic from one DetNet flow that affects traffic from different traffic from one DetNet flow that affects traffic from different
DetNet flows. DetNet flows.
skipping to change at page 9, line 23 skipping to change at page 9, line 28
3.2.6.2. Control or Signaling Packet Injection 3.2.6.2. Control or Signaling Packet Injection
An attacker can maliciously inject control packets in order to An attacker can maliciously inject control packets in order to
disrupt or manipulate the DetNet path/resource allocation. disrupt or manipulate the DetNet path/resource allocation.
3.2.7. Scheduling or Shaping 3.2.7. Scheduling or Shaping
3.2.7.1. Reconnaissance 3.2.7.1. Reconnaissance
A passive eavesdropper can gather information about en route DetNet A passive eavesdropper can identify DetNet flows and then gather
flows, e.g., the number of DetNet flows, their bandwidths, and their information about en route DetNet flows, e.g., the number of DetNet
schedules. The gathered information can later be used to invoke flows, their bandwidths, and their schedules. The gathered
other attacks on some or all of the flows. 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
and/or integrity-protected from external attackers.
3.2.8. Time Synchronization Mechanisms 3.2.8. Time Synchronization Mechanisms
An attacker can use any of the attacks described in [RFC7384] to An attacker can use any of the attacks described in [RFC7384] to
attack the synchronization protocol, thus affecting the DetNet attack the synchronization protocol, thus affecting the DetNet
service. service.
3.3. Threat Summary 3.3. Threat Summary
A summary of the attacks that were discussed in this section is A summary of the attacks that were discussed in this section is
skipping to change at page 10, line 38 skipping to change at page 10, line 40
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|Reconnaissance | + | | + | | |Reconnaissance | + | | + | |
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|Attacks on Time Sync Mechanisms | + | + | + | + | |Attacks on Time Sync Mechanisms | + | + | + | + |
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
Figure 1: Threat Analysis Summary Figure 1: Threat Analysis Summary
4. Security Threat Impacts 4. Security Threat Impacts
This section describes the impact of the attacks described in This section describes and rates the impact of the attacks described
Section 3. Mitigations are discussed further in Section 5. in Section 3. In this section, the impacts as described assume that
the associated mitigation is not present or has failed. Mitigations
are discussed in Section 5.
In computer security, the impact (or consequence) of an incident can In computer security, the impact (or consequence) of an incident can
be measured in loss of confidentiality, integrity or availability of be measured in loss of confidentiality, integrity or availability of
information. In other words, this section describes the effect of a information.
successful attack. The scope is limited to the effect of a
successful attack on DetNet itself, not the applications that _use_ DetNet raises these stakes significantly for OT applications,
Detnet as this is highly application specific. 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 [I-D.ietf-detnet-use-cases]. 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.
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, 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 to its pre-failure
state (Recovery time objective, RTO), and how much of the original
service would be lost in between the time of service failure and
recovery to original state (Recovery Point Objective, RPO). DetNet
dependence maps how much the following DetNet service objectives
contribute to impact of failure: Time dependency, data integrity,
source node integrity, availability, latency/jitter.
The scale of the Impact mappings is low, medium, and high. In some
use cases there may be a multitude of specific applications in which
DetNet is used. For simplicity this section attempts to average the
varied impacts of different applications. This section does not
address the overall risk of a certain impact which would require the
likelihood of a failure happening.
In practice any such ratings will vary from case to case; the ratings
shown here are given as examples.
Table, Part One (of Two)
+------------------+-----------------------------------------+-----+
| | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M |
| | | | | less | |Data |Ctrl |
+------------------+-----------------------------------------+-----+
| Criticality | Med | Hi | Low | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| Effects
+------------------+-----------------------------------------+-----+
| Financial | Med | Hi | Med | Med | Low | Med | Med |
+------------------+-----------------------------------------+-----+
| Health/Safety | Med | Hi | Hi | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| People WB | Med | Hi | Hi | Low | Hi | Low | Low |
+------------------+-----------------------------------------+-----+
| Effect 1 org | Hi | Hi | Med | Hi | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| Effect >1 org | Med | Hi | Low | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
|Recovery
+------------------+-----------------------------------------+-----+
| Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi |
+------------------+-----------------------------------------+-----+
| Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi |
+------------------+-----------------------------------------+-----+
|DetNet Dependence
+------------------+-----------------------------------------+-----+
| Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi |
+------------------+-----------------------------------------+-----+
| Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi |
+------------------+-----------------------------------------+-----+
| Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Low |
+------------------+-----------------------------------------+-----+
| Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi |
+------------------+-----------------------------------------+-----+
| Availability | Hi | Hi | Med | Hi | Low | Hi | Hi |
+------------------+-----------------------------------------+-----+
Table, Part Two (of Two)
+------------------+--------------------------+
| | Mining | Block | Network |
| | | Chain | Slicing |
+------------------+--------------------------+
| Criticality | Hi | Med | Hi |
+------------------+--------------------------+
| Effects
+------------------+--------------------------+
| Financial | Hi | Hi | Hi |
+------------------+--------------------------+
| Health/Safety | Hi | Low | Med |
+------------------+--------------------------+
| People WB | Hi | Low | Med |
+------------------+--------------------------+
| Effect 1 org | Hi | Hi | Hi |
+------------------+--------------------------+
| Effect >1 org | Hi | Low | Hi |
+------------------+--------------------------+
|Recovery
+------------------+--------------------------+
| Recov Time Obj | Hi | Low | Hi |
+------------------+--------------------------+
| Recov Point Obj | Hi | Low | Hi |
+------------------+--------------------------+
|DetNet Dependence
+------------------+--------------------------+
| Time Dependency | Hi | Low | Hi |
+------------------+--------------------------+
| Latency/Jitter | Hi | Low | Hi |
+------------------+--------------------------+
| Data Integrity | Hi | Hi | Hi |
+------------------+--------------------------+
| Src Node Integ | Hi | Hi | Hi |
+------------------+--------------------------+
| Availability | Hi | Hi | Hi |
+------------------+--------------------------+
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. Delay-Attacks
4.1.1. Data Plane Delay Attacks 4.1.1. Data Plane Delay Attacks
Dropped messages can result in stream instability. If only a single Severely delayed messages in a DetNet link can result in the same
path is used, the entire stream can be disrupted. In a multipath behavior as dropped messages in ordinary networks as the services
scenario, large delays on one stream can lead to increased buffer and attached to the stream has strict deterministic requirements.
CPU resources on the elimination bridge.
If the attack is carried out on a sole link (i.e. no multipath), the For a single path scenario, disruption is a real possibility, whereas
DetNet stream can be interrupted and result in outages. in a multipath scenario, large delays or instabilities in one stream
can lead to increased buffer and CPU resources on the elimination
bridge.
4.1.2. Control Plane Delay Attacks 4.1.2. Control Plane Delay Attacks
In and of itself, this is not directly a threat, the effects of In and of itself, this is not directly a threat to the DetNet
delaying control messages can have quite adverse effects later. service, but the effects of delaying control messages can have quite
adverse effects later.
Delayed messages for tear-down can lead to resource leakage if a
stream is not torn down at the correct time. This can in turn result
in failure to allocate new streams giving rise to a denial of service
attack.
In the case where an End-point should be added to a multicast,
failure to deliver said signalling message will prevent the new EP
from receiving expected frames.
Likewise, when an EP should be removed from a multicast group, o Delayed tear-down can lead to resource leakage, which in turn can
delaying such messages can lead to loss of privacy as the EP will result in failure to allocate new streams finally giving rise to a
continue to receive messages even after it is removed. denial of service attack.
4.2. Flow Identification and Spoofing o Failure to deliver, or severely delaying, signalling messages
adding an end-point to a multicast-group will prevent the new EP
from receiving expected frames thus disrupting expected behavior.
4.2.1. Flow identification 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.
Of all the attacks, this is one of the most difficult to detect and 4.2. Flow Modification and Spoofing
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 4.2.1. Flow Modification
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 ToDo.
attacker a very reliable identifier for DetNet traffic, and this
traffic has a high probability of going to lucrative targets.
4.2.2. Spoofing 4.2.2. Spoofing
4.2.2.1. Dataplane Spoofing 4.2.2.1. Dataplane Spoofing
Spoofing dataplane messages can result in increased resource Spoofing dataplane messages can result in increased resource
consumptions on the bridges throughout the network as it will consumptions on the bridges throughout the network as it will
increase buffer usage and CPU utilization. This can lead to resource increase buffer usage and CPU utilization. This can lead to resource
exhaustion and/or increased delay. exhaustion and/or increased delay.
skipping to change at page 12, line 25 skipping to change at page 14, line 39
can be forwarded through the network, using part of the allocated can be forwarded through the network, using part of the allocated
bandwidth. This in turn can cause legitimate messages to be dropped bandwidth. This in turn can cause legitimate messages to be dropped
when the budget has been exhausted. when the budget has been exhausted.
Finally, the endpoint will have to deal with invalid messages being Finally, the endpoint will have to deal with invalid messages being
delivered to the endpoint instead of (or in addition to) a valid delivered to the endpoint instead of (or in addition to) a valid
message. message.
4.2.2.2. Control Plane Spoofing 4.2.2.2. Control Plane Spoofing
A successful control plane spoofing-attack has a very large A successful control plane spoofing-attack will potentionally have
potential. It can do anything from modifying existing streams by adverse effects. It can do virtually anything from:
changing the available bandwidth, add or remove endpoints or drop the
stream altogether. It would also be possible to falsely create new o modifying existing streams by changing the available bandwidth
streams, which could give an attacker the ability to exhaust the
systems resources, or just enable a high quality DetNet stream o add or remove endpoints from a stream
outside the Network engineer's control.
o drop streams completly
o falsely create new streams (exhaust the systems resources, or to
enable streams outside the Network engineer's control)
4.3. Segmentation attacks (injection) 4.3. Segmentation attacks (injection)
4.3.1. Data Plane Segmentation 4.3.1. Data Plane Segmentation
Injection of false messages in a DetNet stream could lead to Injection of false messages in a DetNet stream could lead to
exhaustion of the available bandwidth for a stream if the bridges exhaustion of the available bandwidth for a stream if the bridges
accounts false messages to the stream's budget. accounts false messages to the stream's budget.
In a multipath scenario, injected messages will cause an increased In a multipath scenario, injected messages will cause increased CPU
CPU utilization on elimination bridges and if enough paths are utilization in elimination bridges. If enough paths are subject to
subject to malicious injection, the legitimate messages could be malicious injection, the legitimate messages can be dropped.
dropped. Likewise it can cause an increase in buffer usage. In Likewise it can cause an increase in buffer usage. In total, it will
total, this will consume more resources on the bridges than normal, consume more resources in the bridges than normal, giving rise to a
giving rise to a potential resource exhaustion attack on the bridges. resource exhaustion attack on the bridges.
If a stream is interrupted, the end application will be affected by If a stream is interrupted, the end application will be affected by
what is now a non-deterministic stream. what is now a non-deterministic stream.
4.3.2. Control Plane segmentation 4.3.2. Control Plane segmentation
A successful Control Plane segmentation attack will cause control A successful Control Plane segmentation attack control messages to be
messages to be interpreted by nodes in the network. This has the interpreted by nodes in the network, unbeknownst to the central
potential to create new streams (exhausting resources), drop existing controller or the network engineer. This has the potential to create
(denial of service), add/remove end-stations to a multicast group
(loss of privacy) or modify the stream attributes (reducing available
bandwidth, or increasing it so that new streams cannot reserve a
path).
In short, this means that you cannot trust the stream reservation o new streams (exhausting resources)
properties or the network itself.
As with spoofing, if an attacker is able to inject control-plane o drop existing (denial of service)
messages and the receiving end does not detect it, the receiving
station must be able to. o add/remove end-stations to a multicast group (loss of privacy)
o modify the stream attributes (affecting available bandwidth
4.4. Replication and Elimination 4.4. Replication and Elimination
The Replication and Elimination is relevant only to Data Plane The Replication and Elimination is relevant only to Data Plane
messages as Signalling is not subject to multipath routing. messages as Signalling is not subject to multipath routing.
4.4.1. Increased Attack Surface 4.4.1. Increased Attack Surface
Covered briefly in Section 4.3 Covered briefly in Section 4.3
4.4.2. Header Manipulation at Elimination Bridges 4.4.2. Header Manipulation at Elimination Bridges
Covered briefly in Section 4.3 Covered briefly in Section 4.3
4.5. Impact of Attacks to Path Choice 4.5. Control or Signaling Packet Modification
This is covered in part in Section 4.3, and as with Replication and ToDo.
Elimination (Section 4.4, this is relevant for DataPlane messages.
4.6. Impact of Attacks by Use Case Industry 4.6. Control or Signaling Packet Injection
This section rates the severity of various components of the impact ToDo.
of a successful vulnerability exploit to use cases by industry as
described in [I-D.ietf-detnet-use-cases], including Pro Audio,
Electrical Utilities, Building Automation, Wireless for Industrial,
Cellular Radio, and Industrial M2M (split into two areas, M2M Data
Gathering and M2M Control Loop).
Components of Impact (left column) include Criticality of Failure, 4.7. Reconnaissance
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, the following were included: Financial, Health and Safety,
People well being, 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 to its pre-failure state (Recovery
time objective, RTO), and how much of the original service would be
lost in between the time of service failure and recovery to original
state (Recovery Point Objective, RPO). DetNET dependence maps how
much the following DetNet service objectives contribute to impact of
failure: Time dependency, data integrity, source node integrity,
availability, latency/jitter.
The scale of the Impact mappings is low, medium, and high. In some Of all the attacks, this is one of the most difficult to detect and
use cases there may be a multitude of specific applications in which counter. Often, an attacker will start out by observing the traffic
DetNET is used. For simplicity this section attempts to average the going through the network and use the knowledge gathered in this
varied impacts of different applications. This section does not phase to mount future attacks.
address the overall risk of a certain impact which would require the
likelihood of a failure happening.
In practice any such ratings will vary from case to case; the ratings The attacker can, at their leisure, observe over time all aspects of
shown here are given as examples. 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
| | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M | attacker a very reliable identifier for DetNet traffic, and this
| | | | | less | |Data |Ctrl | traffic has a high probability of going to lucrative targets.
+------------------+-----------------------------------------+-----+
| Criticality | Med | Hi | Low | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| Effects
+------------------+-----------------------------------------+-----+
| Financial | Med | Hi | Med | Med | Low | Med | Med |
+------------------+-----------------------------------------+-----+
| Health/Safety | Med | Hi | Hi | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| People WB | Med | Hi | Hi | Low | Hi | Low | Low |
+------------------+-----------------------------------------+-----+
| Effect 1 org | Hi | Hi | Med | Hi | Med | Med | Med |
+------------------+-----------------------------------------+-----+
| Effect >1 org | Med | Hi | Low | Med | Med | Med | Med |
+------------------+-----------------------------------------+-----+
|Recovery
+------------------+-----------------------------------------+-----+
| Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi |
+------------------+-----------------------------------------+-----+
| Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi |
+------------------+-----------------------------------------+-----+
|DetNet Dependence
+------------------+-----------------------------------------+-----+
| Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi |
+------------------+-----------------------------------------+-----+
| Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi |
+------------------+-----------------------------------------+-----+
| Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Low |
+------------------+-----------------------------------------+-----+
| Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi |
+------------------+-----------------------------------------+-----+
| Availability | Hi | Hi | Med | Hi | Low | Hi | Hi |
+------------------+-----------------------------------------+-----+
Figure 2: Impact of Attacks by Use Case Industry 4.8. Attacks on Time Sync Mechanisms
ToDo.
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.
5. Security Threat Mitigation 5. Security Threat Mitigation
This section describes a set of measures that can be taken to This section describes a set of measures that can be taken to
mitigate the attacks described in Section 3. These mitigations mitigate the attacks described in Section 3. These mitigations
should be viewed as a toolset that includes several different and should be viewed as a toolset that includes several different and
diverse tools. Each application or system will typically use a diverse tools. Each application or system will typically use a
subset of these tools, based on a system-specific threat analysis. subset of these tools, based on a system-specific threat analysis.
5.1. Path Redundancy 5.1. Path Redundancy
skipping to change at page 18, line 21 skipping to change at page 19, line 14
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Attack | Impact | Mitigations | | Attack | Impact | Mitigations |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Delay Attack |-Non-deterministic |-Path redundancy | |Delay Attack |-Non-deterministic |-Path redundancy |
| | delay |-Performance | | | delay |-Performance |
| |-Data disruption | analytics | | |-Data disruption | analytics |
| |-Increased resource | | | |-Increased resource | |
| | consumption | | | | consumption | |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Reconnaissance |-Enabler for other |-Encryption |
| | attacks | |
+----------------------+---------------------+---------------------+
|DetNet Flow Modificat-|-Increased resource |-Path redundancy | |DetNet Flow Modificat-|-Increased resource |-Path redundancy |
|ion or Spoofing | consumption |-Integrity protection| |ion or Spoofing | consumption |-Integrity protection|
| |-Data disruption |-DetNet Node | | |-Data disruption |-DetNet Node |
| | | authentication | | | | authentication |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Inter-Segment Attack |-Increased resource |-Path redundancy | |Inter-Segment Attack |-Increased resource |-Path redundancy |
| | consumption |-Performance | | | consumption |-Performance |
| |-Data disruption | analytics | | |-Data disruption | analytics |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Replication: Increased|-All impacts of other|-Integrity protection| |Replication: Increased|-All impacts of other|-Integrity protection|
skipping to change at page 19, line 8 skipping to change at page 19, line 52
| |-Non-deterministic | | | |-Non-deterministic | |
| | delay | | | | delay | |
| |-Data disruption | | | |-Data disruption | |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Control or Signaling |-Increased resource |-Control message | |Control or Signaling |-Increased resource |-Control message |
|Packet Injection | consumption | protection | |Packet Injection | consumption | protection |
| |-Non-deterministic | | | |-Non-deterministic | |
| | delay | | | | delay | |
| |-Data disruption | | | |-Data disruption | |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Reconnaissance |-Enabler for other |-Encryption |
| | attacks | |
+----------------------+---------------------+---------------------+
|Attacks on Time Sync |-Non-deterministic |-Path redundancy | |Attacks on Time Sync |-Non-deterministic |-Path redundancy |
|Mechanisms | delay |-Control message | |Mechanisms | delay |-Control message |
| |-Increased resource | protection | | |-Increased resource | protection |
| | consumption |-Performance | | | consumption |-Performance |
| |-Data disruption | analytics | | |-Data disruption | analytics |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
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
6.1. Use Cases by Common Themes
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 [I-D.ietf-detnet-use-cases].
We describe each theme and its associated attacks, impacts and
mitigations. 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 6.1.1. Network Layer - AVB/TSN Ethernet
Presumably it will be possible to run DetNet over other underlying DetNet is expected to run over various transmission mediums, with
network layers besides Ethernet, but Ethernet is explicitly Ethernet being explicitly supported. Attacks such as Delay or
supported. Is the attack specific to the Ethernet AVB/TSN protocols? Reconnaissance might be implemented differently on a different
Does the threat affect only Ethernet, or any underlying network transmission medium, however the impact on the DetNet as a whole
layer? 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
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 6.1.2. Central Administration
A DetNet network is expected to be controlled by a centralized A DetNet network is expected to be controlled by a centralized
network configuration and control system. Such a system may be in a network configuration and control system (CNC). Such a system may be
single central location, or it may be distributed across multiple in a single central location, or it may be distributed across
control entities that function together as a unified control system multiple control entities that function together as a unified control
for the network. Is the attack directed at threat the central system for the network.
control system of the network? Does it interfere with OAM?
In this draft 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
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 6.1.3. Hot Swap
A DetNet network is not expected to be "plug and play" - it is A DetNet network is not expected to be "plug and play" - it is
expected that there is some centralized network configuration and expected that there is some centralized network configuration and
control system. However, the ability to "hot swap" components (e.g. control system. However, the ability to "hot swap" components (e.g.
due to malfunction) is similar enough to "plug and play" that this due to malfunction) is similar enough to "plug and play" that this
kind of behavior may be expected in DetNet networks, depending on the kind of behavior may be expected in DetNet networks, depending on the
implementation. Does the attack target "hot swap" ("plug and play") implementation.
operation in the network?
An attack surface related to Hot Swap is that the DetNet network must
at least consider input at runtime from devices that were not part of
the initial configuration of the network. Even a "perfect" (or
"hitless") replacement of a device at runtime would not necessarily
be ideal, since presumably one would want to distinguish it from the
original for OAM purposes (e.g. to report hot swap of a failed
device).
This implies that an attack such as Flow Modification, Spoofing or
Inter-segment (which could introduce packets from a "new" device
(i.e. one heretofore unknown on the network) could be used to exploit
the need to consider such packets (as opposed to rejecting them out
of hand as one would do if one did not have to consider introduction
of a new device).
Similarly if the network was designed to support runtime replacement
of a clock device, then presence (or apparent presence) and thus
consideration of packets from a new such device could affect the
network, or the time sync of the network, for example by initiating a
new Best Master Clock selection process. Thus attacks on time sync
should be considered when designing hot swap type functionality.
6.1.4. Data Flow Information Models 6.1.4. Data Flow Information Models
Data Flow Information Models specific to DetNet networks are to be Data Flow Information Models specific to DetNet networks are to be
specified by DetNet. Thus they are "new" and thus potentially specified by DetNet. Thus they are "new" and thus potentially
present a new attack surface. Does the threat take advantage of any present a new attack surface. Does the threat take advantage of any
aspect of our new Data Flow Info Models? 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 6.1.5. L2 and L3 Integration
A DetNet network is intended to integrate between Layer 2 (bridged) A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN
network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g. LAN) and Layer 3 (routed) networks via the use of well-known
using IP-based protocols). Does the attack target L2? L3? Both? protocols such as IPv6, MPLS-PW, and Ethernet. Presumably security
The interaction between the two? 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.
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.6. End-to-End Delivery 6.1.6. End-to-End Delivery
Packets sent over DetNet are guaranteed not to be dropped by the Packets sent over DetNet are guaranteed not to be dropped by the
network due to congestion. (Packets may however be dropped for network due to congestion. (Packets may however be dropped for
intended reasons, e.g. per security measures). Does the attack intended reasons, e.g. per security measures).
result in packets (which should be delivered) not being delivered?
Does it result in packets that should not be delivered being A Data plane attack may force packets to be dropped, for example a
delivered? "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.
6.1.7. Proprietary Deterministic Ethernet Networks 6.1.7. Proprietary Deterministic Ethernet Networks
There are many proprietary non-interoperable deterministic Ethernet- There are many proprietary non-interoperable deterministic Ethernet-
based networks currently available; DetNet is intended to provide an based networks currently available; DetNet is intended to provide an
open-standards-based alternative to such networks. Does the threat open-standards-based alternative to such networks. In cases where a
relate to a specific such network that is being "emulated" or DetNet intersects with remnants of such networks or their protocols,
"replaced" by DetNet, for example by exploiting specific commands such as by protocol emulation or access to such a network via a
specific to that network protocol? gateway, new attack surfaces can be opened.
For example an Inter-Segment or Control plane attack such as Path
Manipulation, Path Choice or Control Packet Modification/Injection
could be used to exploit commands specific to such a protocol, or
that are interpreted differently by the different protocols or
gateway.
6.1.8. Replacement for Proprietary Fieldbuses 6.1.8. Replacement for Proprietary Fieldbuses
There are many proprietary "field buses" used in today's industrial There are many proprietary "field buses" used in today's industrial
and other industries; DetNet is intended to provide an open- and other industries; DetNet is intended to provide an open-
standards-based alternative to such buses. Does the threat relate to standards-based alternative to such buses. In cases where a DetNet
a specific fieldbus that is being "emulated" or "replaced" by DetNet, intersects with such fieldbuses or their protocols, such as by
for example by exploiting specific commands specific to that network protocol emulation or access via a gateway, new attack surfaces can
protocol? be opened.
For example an Inter-Segment or Control plane attack such as Path
Manipulation, Path Choice or Control Packet Modification/Injection
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 6.1.9. Deterministic vs Best-Effort Traffic
DetNet is intended to support coexistence of time-sensitive DetNet is intended to support coexistence of time-sensitive
operational (OT, deterministic) traffic and information (IT, "best operational (OT, deterministic) traffic and information (IT, "best
effort") traffic on the same ("unified") network. Does the attack effort") traffic on the same ("unified") network.
affect only IT or only OT or both types of traffic? Does the threat
affect any interaction between IT and OT traffic, e.g. by changing The presence of IT traffic on a network carrying OT traffic has long
relative priority or handling of IT vs. OT packets? 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.
Most of the themes described in this draft 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.
However the DetNet's handling of IT traffic may not (by design) be as
resilient to DOS attack, and thus designers must be otherwise
prepared to mitigate DOS attacks on IT traffic in a DetNet.
6.1.10. Deterministic Flows 6.1.10. Deterministic Flows
Reserved bandwidth data flows (deterministic flows) must be isolated Reserved bandwidth data flows (deterministic flows) must provide the
from each other and from best-effort traffic, so that even if the allocated bandwidth, and must be isolated from each other.
network is saturated with best-effort and/or reserved bandwidth
traffic the configured flows are not adversely affected. Does the A Spoofing or Inter-segment attack which adds packet traffic to a
attack affect the isolation of one (reserved) flow from another? bandwidth-reserved stream could cause that stream to occupy more
bandwidth than it is allocated, resulting in interference with other
deterministic flows.
A Flow Modification or Spoofing or Header Manipulation or Control
Packet Modification attack could cause packets from one flow to be
directed to another flow, thus breaching isolation between the flows.
6.1.11. Unused Reserved Bandwidth 6.1.11. Unused Reserved Bandwidth
If bandwidth reservations are made for a stream but the associated If bandwidth reservations are made for a stream but the associated
bandwidth is not used at any point in time, that bandwidth is made bandwidth is not used at any point in time, that bandwidth is made
available on the network for best-effort traffic. If the owner of available on the network for best-effort traffic. If the owner of
the reserved stream then starts transmitting again, the bandwidth is the reserved stream then starts transmitting again, the bandwidth is
no longer available for best-effort traffic, on a moment-to-moment no longer available for best-effort traffic, on a moment-to-moment
basis. (Such "temporarily available" bandwidth is not available for basis. (Such "temporarily available" bandwidth is not available for
time-sensitive traffic, which must have its own reservation). Does time-sensitive traffic, which must have its own reservation).
the attack affect the system's ability to allocate unused reserved BW
to best-effort traffic? An Inter-segment attack could flood the network with IT traffic,
interfering with the intended IT traffic.
A Flow Modification or Spoofing or Control Packet Modification or
Injection attack could cause extra bandwidth to be reserved by a new
or existing stream, thus making it unavailable for use by best-effort
traffic.
6.1.12. Interoperability 6.1.12. Interoperability
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each promoting device diversity and potentially higher numbers of each
device manufactured. Does the threat take advantage of differences device manufactured. Does the threat take advantage of differences
in implementation of "interoperable" products made by different in implementation of "interoperable" products made by different
vendors? vendors?
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.13. Cost Reductions 6.1.13. Cost Reductions
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting higher numbers of each device manufactured, promoting cost promoting higher numbers of each device manufactured, promoting cost
reduction and cost competition among vendors. Does the threat take reduction and cost competition among vendors. Does the threat take
advantage of "low cost" HW or SW components or other "cost-related advantage of "low cost" HW or SW components or other "cost-related
shortcuts" that might be present in devices? shortcuts" that might be present in devices?
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.14. Insufficiently Secure Devices 6.1.14. Insufficiently Secure Devices
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each promoting device diversity and potentially higher numbers of each
device manufactured. Does the threat attack "naivete" of SW, for device manufactured. Does the threat attack "naivete" of SW, for
example SW that was not designed to be sufficiently secure (or secure example SW that was not designed to be sufficiently secure (or secure
at all) but is deployed on a DetNet network that is intended to be at all) but is deployed on a DetNet network that is intended to be
highly secure? (For example IoT exploits like the Mirai video-camera highly secure? (For example IoT exploits like the Mirai video-camera
botnet ([MIRAI]). botnet ([MIRAI]).
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.15. DetNet Network Size 6.1.15. DetNet Network Size
DetNet networks range in size from very small, e.g. inside a single DetNet networks range in size from very small, e.g. inside a single
industrial machine, to very large, for example a Utility Grid network industrial machine, to very large, for example a Utility Grid network
spanning a whole country, and involving many "hops" over various spanning a whole country.
kinds of links for example radio repeaters, microwave links, fiber
optic links, etc.. Does the attack affect DetNet networks of only The size of the network might be related to how the attack is
certain sizes, e.g. very large networks, or very small? This might introduced into the network, for example if the entire network is
be related to how the attack is introduced into the network, for local, there is a threat that power can be cut to the entire network.
example if the entire network is local, there is a threat that power If the network is large, perhaps only a part of the network is
can be cut to the entire network. If the network is large, perhaps attacked.
only a part of the network is attacked. Does the threat take
advantage of attack vectors that are specific to network size? A Delay attack might be as relevant to a small network as to a large
network, although the amount of delay might be different.
Attacks sourced from IT traffic might be more likely in large
networks, since more people might have access to the network.
Similarly Path Manipulation, Path Choice and Time Sync attacks seem
more likely relevant to large networks.
6.1.16. Multiple Hops 6.1.16. Multiple Hops
DetNet networks range in size from very small, e.g. inside a single Large DetNet networks (e.g. a Utility Grid network) may involve many
industrial machine, to very large, for example a Utility Grid network "hops" over various kinds of links for example radio repeaters,
spanning a whole country, and involving many "hops" over various microwave links, fiber optic links, etc..
kinds of links for example radio repeaters, microwave links, fiber
optic links, etc.. Does the attack exploit the presence of more than An attack that takes advantage of flaws (or even normal operation) in
one "hop"? Does the threat exploit the presence of more than one the device drivers for the various links (through internal knowledge
type of "hop", e.g. between radio and microwave links? Does the of how the individual driver or firmware operates, perhaps like the
threat exploit a specific type of "hop", e.g. something specific to Stuxnet attack) could take proportionately greater advantage of this
a fiber optic link, or other type of link? topology. We don't currently have an attack like this defined; we
have only "protocol" (time or packet) based attacks. Perhaps we need
to define an attack like this? Or is that out of scope for DetNet?
It is also possible that this DetNet topology will not be in as
common use as other more homogeneous topologies so there may be more
opportunity for attackers to exploit software and/or protocol flaws
in the implementations which have not been wrung out by extensive
use, particularly in the case of early adopters.
Of the attacks we have defined, the ones identified above as relevant
to "large" networks seem to be most relevant.
6.1.17. Level of Service 6.1.17. Level of Service
A DetNet is expected to provide means to configure the network that A DetNet is expected to provide means to configure the network that
include querying network path latency, requesting bounded latency for include querying network path latency, requesting bounded latency for
a given stream, requesting worst case maximum and/or minimum latency a given stream, requesting worst case maximum and/or minimum latency
for a given path or stream, and so on. It is an expected case that for a given path or stream, and so on. It is an expected case that
the network cannot provide a given requested service level. In such the network cannot provide a given requested service level. In such
cases the network control system should reply that the requested cases the network control system should reply that the requested
service level is not available (as opposed to accepting the parameter service level is not available (as opposed to accepting the parameter
but then not delivering the desired behavior). Does the attack but then not delivering the desired behavior).
affect any querying or replying to such service-level-related
traffic? Can the attack cause incorrect responses from the system Control plane attacks such as Signaling Packet Modification and
regarding timing-related configuration? For example replying that a Injection could be used to modify or create control traffic that
requested level of service is available when it isn't, or that the could interfere with the process of a user requesting a level of
requested level of service is not available when it actually is service and/or the network's reply.
available?
Reconnaissance could be used to characterize flows and perhaps target
specific flows for attack via the Control plane as noted above.
6.1.18. Bounded Latency 6.1.18. Bounded Latency
Does the threat affect the network's ability to deliver packets DetNet provides the expectation of guaranteed bounded latency.
within the agreed-upon latency boundaries?
Delay attacks can cause packets to miss their agreed-upon latency
boundaries.
Time Sync attacks can corrupt the system's time reference, resulting
in missed latency deadlines (with respect to the "correct" time
reference).
6.1.19. Low Latency 6.1.19. Low Latency
Applications may require "extremely low latency" however depending on Applications may require "extremely low latency" however depending on
the application these may mean very different latency values; for the application these may mean very different latency values; for
example "low latency" across a Utility grid network is on a different example "low latency" across a Utility grid network is on a different
time scale than "low latency" in a motor control loop in a small time scale than "low latency" in a motor control loop in a small
machine. The intent is that the mechanisms for specifying desired machine. The intent is that the mechanisms for specifying desired
latency include wide ranges, and that architecturally there is latency include wide ranges, and that architecturally there is
nothing to prevent arbitrarily low latencies from being implemented nothing to prevent arbitrarily low latencies from being implemented
in a given network. Does the threat affect the network's ability to in a given network.
deliver packets within the agreed-upon low latency?
Attacks on the Control plane (as described in the Level of Service
theme) and Delay and Time attacks (as described in the Bounded
Latency theme) both apply here.
6.1.20. Symmetrical Path Delays 6.1.20. Symmetrical Path Delays
Some applications would like to specify that the transit delay time Some applications would like to specify that the transit delay time
values be equal for both the transmit and return paths. Does the values be equal for both the transmit and return paths.
attack affect the network's ability to provide matched transmit and
return path delays (latencies)? Delay attacks can cause path delays to differ.
Time Sync attacks can corrupt the system's time reference, resulting
in differing path delays (with respect to the "correct" time
reference).
6.1.21. Reliability and Availability 6.1.21. Reliability and Availability
DetNet based systems are expected to be implemented with essentially DetNet based systems are expected to be implemented with essentially
arbitrarily high availability (for example 99.9999% up time, or even arbitrarily high availability (for example 99.9999% up time, or even
12 nines). The intent is that the DetNet designs should not make any 12 nines). The intent is that the DetNet designs should not make any
assumptions about the level of reliability and availability that may assumptions about the level of reliability and availability that may
be required of a given system, and should define parameters for be required of a given system, and should define parameters for
communicating these kinds of metrics within the network. Does the communicating these kinds of metrics within the network.
attack affect the reliability of the DetNet network? Is it a large
or small change, e.g. the difference between completely taking down Any attack on the system, of any type, can affect its overall
the network for some period of time, vs reducing its reliability by reliability and availability, thus in our table we have marked every
just one "nine"? Does the threat affect the availability of the attack. Since every DetNet depends to a greater or lesser degree on
DetNet network? 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.
6.1.22. Redundant Paths 6.1.22. Redundant Paths
DetNet based systems are expected to be implemented with essentially DetNet based systems are expected to be implemented with essentially
arbitrarily high reliability/availability. A strategy used by DetNet arbitrarily high reliability/availability. A strategy used by DetNet
for providing such extraordinarily high levels of reliability is to for providing such extraordinarily high levels of reliability is to
provide redundant paths that can be seamlessly switched between, all provide redundant paths that can be seamlessly switched between, all
the while maintaining the required performance of that system. Does the while maintaining the required performance of that system.
the attack affect the configuration or operation of redundant paths?
Replication-related attacks are by definition applicable here.
Control plane attacks can also interfere with the configuration of
redundant paths.
6.1.23. Security Measures 6.1.23. Security Measures
A DetNet network must be made secure against devices failures, A DetNet network must be made secure against devices failures,
attackers, misbehaving devices, and so on. Does the threat affect attackers, misbehaving devices, and so on. Does the threat affect
such security measures themselves, e.g. by attacking SW designed to such security measures themselves, e.g. by attacking SW designed to
protect against device failure? protect against device failure?
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.2. Attack Types by Use Case Common Theme 6.2. Attack Types by Use Case Common Theme
The following table lists the attacks of Section 3, assigning a The following table lists the attacks of Section 3, assigning a
number to each type of attack. That number is then used as a short number to each type of attack. That number is then used as a short
form identifier for the attack in Figure 5. form identifier for the attack in Figure 5.
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| | Attack | Section | | | Attack | Section |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| 1|Delay Attack | Section 3.2.1 | | 1|Delay Attack | Section 3.2.1 |
skipping to change at page 25, line 50 skipping to change at page 29, line 50
| | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11| | | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Network Layer - AVB/TSN Eth.| +| +| +| +| +| +| +| +| +| +| +| |Network Layer - AVB/TSN Eth.| +| +| +| +| +| +| +| +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Central Administration | | | | | | +| +| +| +| +| +| |Central Administration | | | | | | +| +| +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Hot Swap | | +| +| | | | | | | | +| |Hot Swap | | +| +| | | | | | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Data Flow Information Models| | | | | | | | | | | | |Data Flow Information Models| | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|L2 and L3 Integration | | | | | +| +| | | | | | |L2 and L3 Integration | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|End-to-end Delivery | | | | +| +| | | | | | | |End-to-end Delivery | +| +| +| +| +| +| +| +| +| | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Proprietary Deterministic | | | +| | | +| +| +| +| | | |Proprietary Deterministic | | | +| | | +| +| +| +| | |
|Ethernet Networks | | | | | | | | | | | | |Ethernet Networks | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Replacement for Proprietary | | | +| | | +| +| +| +| | | |Replacement for Proprietary | | | +| | | +| +| +| +| | |
|Fieldbuses | | | | | | | | | | | | |Fieldbuses | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Deterministic vs. Best- | | | +| | | | | | | | | |Deterministic vs. Best- | | | +| | | | | | | | |
|Effort Traffic | | | | | | | | | | | | |Effort Traffic | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Deterministic Flows | | | +| | | | | | | | | |Deterministic Flows | | +| +| | +| +| | +| | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Unused Reserved Bandwidth | | | +| | | | | | | | | |Unused Reserved Bandwidth | | +| +| | | | | +| +| | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Interoperability | | | | | | | | | | | | |Interoperability | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Cost Reductions | | | | | | | | | | | | |Cost Reductions | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Insufficiently Secure | | | | | | | | | | | | |Insufficiently Secure | | | | | | | | | | | |
|Devices | | | | | | | | | | | | |Devices | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|DetNet Network Size | +| | | | | +| +| | | | +| |DetNet Network Size | +| | | | | +| +| | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Multiple Hops | +| +| | | | +| +| | | | +| |Multiple Hops | +| +| | | | +| +| | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Level of Service | | | | | | | | +| +| +| | |Level of Service | | | | | | | | +| +| +| |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Bounded Latency | +| | | | | | | | | | +| |Bounded Latency | +| | | | | | | | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Low Latency | +| | | | | | | | | | +| |Low Latency | +| | | | | | | +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Symmetric Path Delays | +| | | | | | | | | | +| |Symmetric Path Delays | +| | | | | | | | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +| |Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Redundant Paths | | | | +| +| | | +| +| | | |Redundant Paths | | | | +| +| | | +| +| | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Security Measures | | | | | | | | | | | | |Security Measures | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 33, line 42 skipping to change at page 37, line 42
[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-03 (work in progress), August 2017. detnet-architecture-03 (work in progress), August 2017.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y.,
Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana,
X., Mahmoodi, T., Spirou, S., and P. Vizarreta, X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D.,
"Deterministic Networking Use Cases", draft-ietf-detnet- Geng, X., Dujovne, D., and M. Seewald, "Deterministic
use-cases-12 (work in progress), April 2017. Networking Use Cases", draft-ietf-detnet-use-cases-13
(work in progress), September 2017.
[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.
[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
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[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>.
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Marvell Marvell
Email: talmi@marvell.com Email: talmi@marvell.com
 End of changes. 80 change blocks. 
327 lines changed or deleted 571 lines changed or added

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