draft-ietf-detnet-security-10.txt   draft-ietf-detnet-security-11.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: December 1, 2020 DOLBY Expires: February 15, 2021 DOLBY
May 30, 2020 August 14, 2020
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-10 draft-ietf-detnet-security-11
Abstract Abstract
A DetNet (deterministic network) provides specific performance A DetNet (deterministic network) provides specific performance
guarantees to its data flows, such as extremely low data loss rates guarantees to its data flows, such as extremely low data loss rates
and bounded latency. As a result, securing a DetNet implies that in and bounded latency. As a result, securing a DetNet requires that in
addition to the best practice security measures taken for any addition to the best practice security measures taken for any
mission-critical network, additional security measures may be needed mission-critical network, additional security measures may be needed
whose purpose is exclusively to secure the intended operation of to secure the intended operation of these novel service properties.
these novel service properties.
Designers of DetNet components (such as routers) that provide these
unique DetNet properties have the responsibility to uphold certain
security-related properties that can be assumed by DetNet system-
level designers. For example, the assumption that network traffic
associated with a given flow can never affect traffic associated with
a different flow is only true if the underlying components make it
so.
This document addresses DetNet-specific security considerations from This document addresses DetNet-specific security considerations from
the perspective of both the DetNet component designer and the DetNet the perspectives of both the DetNet system-level designer and
system-level designer. It is assumed that both classes of reader are component designer. System considerations include a threat model,
already familiar with network security best practices for the data taxonomy of relevant attacks, and associations of threats versus use
plane technologies underlying a given DetNet implementation. cases and service properties. Component-level considerations include
Component-level considerations include isolation of data flows from ingress filtering and packet arrival time violation detection. This
each other, ingress filtering, and detection and reporting of packet document also addresses DetNet security considerations specific to
arrival time violations. System-level considerations include a the IP and MPLS data plane technologies thereby complementing the
threat model and a taxonomy of relevant attacks, including their
potential impacts and mitigations.
A given DetNet may require securing only certain aspects of DetNet
performance, for example extremely low data loss rates but not
necessarily bounded latency. Therefore this document provides an
association of threats against various use cases by industry, and
also against the individual service properties as defined in the
DetNet Use Cases.
This document also addresses common DetNet security considerations
related to the IP and MPLS data plane technologies (the first to be
identified as supported by DetNet), thereby complementing the
Security Considerations sections of the various DetNet Data Plane Security Considerations sections of the various DetNet Data Plane
(and other) DetNet documents. (and other) DetNet documents.
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 December 1, 2020. This Internet-Draft will expire on February 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 6
3. Security Considerations for DetNet Component Design . . . . . 7 3. Security Considerations for DetNet Component Design . . . . . 6
3.1. Resource Allocation . . . . . . . . . . . . . . . . . . . 7 3.1. Resource Allocation . . . . . . . . . . . . . . . . . . . 7
3.2. Explicit Routes . . . . . . . . . . . . . . . . . . . . . 7 3.2. Explicit Routes . . . . . . . . . . . . . . . . . . . . . 7
3.3. Redundant Path Support . . . . . . . . . . . . . . . . . 8 3.3. Redundant Path Support . . . . . . . . . . . . . . . . . 7
3.4. Timing Violation Reporting . . . . . . . . . . . . . . . 9 3.4. Timing (or other) Violation Reporting . . . . . . . . . . 8
4. DetNet Security Considerations Compared With DiffServ 4. DetNet Security Considerations Compared With DiffServ
Security Considerations . . . . . . . . . . . . . . . . . . . 9 Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Security Threats . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Threats . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 11 5.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 11
5.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 11 5.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 11
5.2.3. Resource Segmentation or Slicing . . . . . . . . . . 11 5.2.3. Resource Segmentation (Inter-segment Attack) . . . . 12
5.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 11
5.2.4. Packet Replication and Elimination . . . . . . . . . 12 5.2.4. Packet Replication and Elimination . . . . . . . . . 12
5.2.4.1. Replication: Increased Attack Surface . . . . . . 12 5.2.4.1. Replication: Increased Attack Surface . . . . . . 12
5.2.4.2. Replication-related Header Manipulation . . . . . 12 5.2.4.2. Replication-related Header Manipulation . . . . . 12
5.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 12 5.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 13
5.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 12 5.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 13
5.2.5.2. Path Choice: Increased Attack Surface . . . . . . 13 5.2.5.2. Path Choice: Increased Attack Surface . . . . . . 13
5.2.6. Controller Plane . . . . . . . . . . . . . . . . . . 13 5.2.6. Controller Plane . . . . . . . . . . . . . . . . . . 13
5.2.6.1. Control or Signaling Packet Modification . . . . 13 5.2.6.1. Control or Signaling Packet Modification . . . . 13
5.2.6.2. Control or Signaling Packet Injection . . . . . . 13 5.2.6.2. Control or Signaling Packet Injection . . . . . . 13
5.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 13 5.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 13
5.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 13 5.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 13
5.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 13 5.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 13
5.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 13 5.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 14
6. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 14 6. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 14
6.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 17
6.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 17 6.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 17
6.1.2. Controller Plane Delay Attacks . . . . . . . . . . . 18 6.1.2. Controller Plane Delay Attacks . . . . . . . . . . . 18
6.2. Flow Modification and Spoofing . . . . . . . . . . . . . 18 6.2. Flow Modification and Spoofing . . . . . . . . . . . . . 18
6.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 18 6.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 18
6.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 18 6.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 18
6.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 18 6.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 18
6.2.2.2. Controller Plane Spoofing . . . . . . . . . . . . 19 6.2.2.2. Controller Plane Spoofing . . . . . . . . . . . . 19
6.3. Segmentation Attacks (injection) . . . . . . . . . . . . 19 6.3. Segmentation Attacks (injection) . . . . . . . . . . . . 19
skipping to change at page 3, line 46 skipping to change at page 3, line 23
6.4. Replication and Elimination . . . . . . . . . . . . . . . 20 6.4. Replication and Elimination . . . . . . . . . . . . . . . 20
6.4.1. Increased Attack Surface . . . . . . . . . . . . . . 20 6.4.1. Increased Attack Surface . . . . . . . . . . . . . . 20
6.4.2. Header Manipulation at Elimination Routers . . . . . 20 6.4.2. Header Manipulation at Elimination Routers . . . . . 20
6.5. Control or Signaling Packet Modification . . . . . . . . 20 6.5. Control or Signaling Packet Modification . . . . . . . . 20
6.6. Control or Signaling Packet Injection . . . . . . . . . . 20 6.6. Control or Signaling Packet Injection . . . . . . . . . . 20
6.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 20 6.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 20
6.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 21 6.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 21
6.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 21 6.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 21
7. Security Threat Mitigation . . . . . . . . . . . . . . . . . 21 7. Security Threat Mitigation . . . . . . . . . . . . . . . . . 21
7.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 21 7.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 21
7.2. Integrity Protection . . . . . . . . . . . . . . . . . . 21 7.2. Integrity Protection . . . . . . . . . . . . . . . . . . 22
7.3. DetNet Node Authentication . . . . . . . . . . . . . . . 22 7.3. DetNet Node Authentication . . . . . . . . . . . . . . . 22
7.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 23 7.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 23
7.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 23 7.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 23
7.5.1. Encryption Considerations for DetNet . . . . . . . . 23 7.5.1. Encryption Considerations for DetNet . . . . . . . . 24
7.6. Control and Signaling Message Protection . . . . . . . . 24 7.6. Control and Signaling Message Protection . . . . . . . . 25
7.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 25 7.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 25
7.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 25 7.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 26
8. Association of Attacks to Use Cases . . . . . . . . . . . . . 27 8. Association of Attacks to Use Cases . . . . . . . . . . . . . 27
8.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 27 8.1. Association of Attacks to Use Case Common Themes . . . . 27
8.1.1. Sub-Network Layer . . . . . . . . . . . . . . . . . . 27 8.1.1. Sub-Network Layer . . . . . . . . . . . . . . . . . . 27
8.1.2. Central Administration . . . . . . . . . . . . . . . 28 8.1.2. Central Administration . . . . . . . . . . . . . . . 28
8.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 28 8.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 28
8.1.4. Data Flow Information Models . . . . . . . . . . . . 29 8.1.4. Data Flow Information Models . . . . . . . . . . . . 29
8.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 29 8.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 29
8.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 29 8.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 29
8.1.7. Proprietary Deterministic Ethernet Networks . . . . . 30 8.1.7. Replacement for Proprietary Fieldbuses and Ethernet-
8.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 30 based Networks . . . . . . . . . . . . . . . . . . . 30
8.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 30 8.1.8. Deterministic vs Best-Effort Traffic . . . . . . . . 30
8.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 31 8.1.9. Deterministic Flows . . . . . . . . . . . . . . . . . 31
8.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 31 8.1.10. Unused Reserved Bandwidth . . . . . . . . . . . . . . 31
8.1.12. Interoperability . . . . . . . . . . . . . . . . . . 31 8.1.11. Interoperability . . . . . . . . . . . . . . . . . . 31
8.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 32 8.1.12. Cost Reductions . . . . . . . . . . . . . . . . . . . 31
8.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 32 8.1.13. Insufficiently Secure Devices . . . . . . . . . . . . 32
8.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 32 8.1.14. DetNet Network Size . . . . . . . . . . . . . . . . . 32
8.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 33 8.1.15. Multiple Hops . . . . . . . . . . . . . . . . . . . . 33
8.1.17. Level of Service . . . . . . . . . . . . . . . . . . 33 8.1.16. Level of Service . . . . . . . . . . . . . . . . . . 33
8.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 33 8.1.17. Bounded Latency . . . . . . . . . . . . . . . . . . . 33
8.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 34 8.1.18. Low Latency . . . . . . . . . . . . . . . . . . . . . 34
8.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 34 8.1.19. Bounded Jitter (Latency Variation) . . . . . . . . . 34
8.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 34 8.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 34
8.1.22. Reliability and Availability . . . . . . . . . . . . 34 8.1.21. Reliability and Availability . . . . . . . . . . . . 34
8.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 35 8.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 35
8.1.24. Security Measures . . . . . . . . . . . . . . . . . . 35 8.1.23. Security Measures . . . . . . . . . . . . . . . . . . 35
8.2. Attack Types by Use Case Common Theme . . . . . . . . . . 35 8.2. Summary of Attack Types per Use Case Common Theme . . . . 35
8.3. Security Considerations for OAM Traffic . . . . . . . . . 38 8.3. Security Considerations for OAM Traffic . . . . . . . . . 38
9. DetNet Technology-Specific Threats . . . . . . . . . . . . . 38 9. DetNet Technology-Specific Threats . . . . . . . . . . . . . 38
9.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
13. Informative References . . . . . . . . . . . . . . . . . . . 42 13. Informative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
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.
However, such networks are typically isolated from external access, However, such networks are typically isolated from external access,
and thus the security threat from external attackers is low. IETF and thus the security threat from external attackers is low. IETF
Deterministic Networking (DetNet) specifies a set of technologies Deterministic Networking (DetNet, [RFC8655]) specifies a set of
that enable creation of deterministic networks on IP-based networks technologies that enable creation of deterministic networks on IP-
of potentially wide area (on the scale of a corporate network) based networks of potentially wide area (on the scale of a corporate
potentially bringing the OT network into contact with Information network) potentially bringing the OT network into contact with
Technology (IT) traffic and security threats that lie outside of a Information Technology (IT) traffic and security threats that lie
tightly controlled and bounded area (such as the internals of an outside of a tightly controlled and bounded area (such as the
aircraft). internals of an aircraft).
These DetNet technologies have not previously been deployed together These DetNet technologies have not previously been deployed together
on a wide area IP-based network, and thus can present security on a wide area IP-based network, and thus can present security
considerations that may be new to IP-based wide area network considerations that may be new to IP-based wide area network
designers; this document provides insight into such system-level designers; this document provides insight into such system-level
security considerations. In addition, designers of DetNet components security considerations. In addition, designers of DetNet components
(such as routers) face new security-related challenges in providing (such as routers) face new security-related challenges in providing
DetNet services, for example maintaining reliable isolation between DetNet services, for example maintaining reliable isolation between
traffic flows in an environment where IT traffic co-mingles with traffic flows in an environment where IT traffic co-mingles with
critical reserved-bandwidth OT traffic; this document also examines critical reserved-bandwidth OT traffic; this document also examines
skipping to change at page 6, line 21 skipping to change at page 5, line 47
management aspects leave off. management aspects leave off.
The exact security requirements for any given DetNet network are The exact security requirements for any given DetNet network are
necessarily specific to the use cases handled by that network. Thus necessarily specific to the use cases handled by that network. Thus
the reader is assumed to be familiar with the specific security the reader is assumed to be familiar with the specific security
requirements of their use cases, for example those outlined in the requirements of their use cases, for example those outlined in the
DetNet Use Cases [RFC8578] and the Security Considerations sections DetNet Use Cases [RFC8578] and the Security Considerations sections
of the DetNet documents applicable to the network technologies in of the DetNet documents applicable to the network technologies in
use, for example [I-D.ietf-detnet-ip]). A general introduction to use, for example [I-D.ietf-detnet-ip]). A general introduction to
the DetNet architecture can be found in [RFC8655] and it is also the DetNet architecture can be found in [RFC8655] and it is also
recommended to be familiar with the Data Plane model recommended to be familiar with the DetNet Data Plane
[I-D.ietf-detnet-data-plane-framework] and Flow Information Model [I-D.ietf-detnet-data-plane-framework] and Flow Information Model
[I-D.ietf-detnet-flow-information-model]. [I-D.ietf-detnet-flow-information-model].
The DetNet technologies include ways to: The DetNet technologies include ways to:
o Assign data plane resources for DetNet flows in some or all of the o Assign data plane resources for DetNet flows in some or all of the
intermediate nodes (routers) along the path of the flow intermediate nodes (routers) along the path of the flow
o Provide explicit routes for DetNet flows that do not dynamically o Provide explicit routes for DetNet flows that do not dynamically
change with the network topology in ways that affect the quality change with the network topology in ways that affect the quality
of service received by the affected flow(s) of service received by the affected flow(s)
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 document includes sections considering DetNet component design This document includes sections considering DetNet component design
as well as system design. The latter include threat modeling and as well as system design. The latter includes threat modeling and
analysis, threat impact and mitigation, and the association of analysis, threat impact and mitigation, and the association of
attacks with use cases (based on the Use Case Common Themes section attacks with use cases (based on the Use Case Common Themes section
of the DetNet Use Cases). of the DetNet Use Cases [RFC8578]).
The structure of the threat model and threat analysis sections were The structure of the threat model and threat analysis sections were
originally derived from [RFC7384], which also considers time-related originally derived from [RFC7384], which also considers time-related
security considerations in IP networks. security considerations in IP networks.
2. Abbreviations 2. Abbreviations and Terminology
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,
often in the context of a business or other enterprise - Wikipedia). often in the context of a business or other enterprise - [IT_DEF]).
OT Operational Technology (the hardware and software OT Operational Technology (the hardware and software
dedicated to detecting or causing changes in physical processes dedicated to detecting or causing changes in physical processes
through direct monitoring and/or control of physical devices such as through direct monitoring and/or control of physical devices such as
valves, pumps, etc. - Wikipedia) valves, pumps, etc. - [OT_DEF])
MITM Man in the Middle MITM Man in the Middle
Component A component of a DetNet system - used here to refer
to any hardware or software element of a DetNet network which
implements DetNet-specific functionality, for example all or part of
a router, switch, or end system.
Resource Segmentation Used as a more general form for Network
Segmentation (the act or practice of splitting a computer network
into subnetworks, each being a network segment - [RS_DEF])
3. Security Considerations for DetNet Component Design 3. Security Considerations for DetNet Component Design
As noted above, DetNet provides resource allocation, explicit routes As noted above, DetNet provides resource allocation, explicit routes
and redundant path support. Each of these have associated security and redundant path support. Each of these has associated security
implications, which are discussed in this section, in the context of implications, which are discussed in this section, in the context of
component design. Detection, reporting and appropriate action in the component design. Detection, reporting and appropriate action in the
case of packet arrival time violations are also discussed. case of packet arrival time violations are also discussed.
3.1. Resource Allocation 3.1. Resource Allocation
A DetNet system security designer relies on the premise that any A DetNet system security designer relies on the premise that any
resources allocated to a resource-reserved (OT-type) flow are resources allocated to a resource-reserved (OT-type) flow are
inviolable, in other words there is no physical possibility within a inviolable, in other words there is no physical possibility within a
DetNet component that resources allocated to a given flow can be DetNet component that resources allocated to a given flow can be
skipping to change at page 7, line 47 skipping to change at page 7, line 34
The DetNet-specific purpose for constraining the network's ability to The DetNet-specific purpose for constraining the network's ability to
re-route OT traffic is to maintain the specified service parameters re-route OT traffic is to maintain the specified service parameters
(such as upper and lower latency boundaries) for a given flow. For (such as upper and lower latency boundaries) for a given flow. For
example if the network were to re-route a flow (or some part of a example if the network were to re-route a flow (or some part of a
flow) based exclusively on statistical path usage metrics, or due to flow) based exclusively on statistical path usage metrics, or due to
malicious activity, it is possible that the new path would have a malicious activity, it is possible that the new path would have a
latency that is outside the required latency bounds which were latency that is outside the required latency bounds which were
designed into the original TE-designed path, thereby violating the designed into the original TE-designed path, thereby violating the
quality of service for the affected flow (or part of that flow). quality of service for the affected flow (or part of that flow).
(However, is acceptable for the network to re-route OT traffic in
However, it is acceptable for the network to re-route OT traffic in
such a way as to maintain the specified latency bounds (and any other such a way as to maintain the specified latency bounds (and any other
specified service properties) for any reason, for example in response specified service properties) for any reason, for example in response
to a runtime component or path failure). From a security standpoint, to a runtime component or path failure. From a security standpoint,
the system designer relies on the premise that the packets will be the system designer relies on the premise that the packets will be
delivered with the specified latency boundaries; thus any component delivered with the specified latency boundaries; thus any component
that is involved in controlling or implementing any change of the that is involved in controlling or implementing any change of the
initially TE-configured flow routes needs to prevent malicious or initially TE-configured flow routes needs to prevent malicious or
accidental re-routing of OT flows that might adversely affect accidental re-routing of OT flows that might adversely affect
delivering the traffic within the specified service parameters. delivering the traffic within the specified service parameters.
3.3. Redundant Path Support 3.3. Redundant Path Support
The DetNet provision for redundant paths (PREOF) (as defined in the The DetNet provision for redundant paths (PREOF) (as defined in the
skipping to change at page 8, line 30 skipping to change at page 8, line 19
redundant paths sufficient to provide the desired level of redundant paths sufficient to provide the desired level of
reliability (in as much as that reliability can be provided through reliability (in as much as that reliability can be provided through
the use of redundant paths). It is the responsibility of the the use of redundant paths). It is the responsibility of the
component designer to ensure that the relevant PREOF operations are component designer to ensure that the relevant PREOF operations are
executed reliably and securely. (However, note that not all PREOF executed reliably and securely. (However, note that not all PREOF
operations are necessarily implemented in every network; for example operations are necessarily implemented in every network; for example
a packet re-ordering function may not be necessary if the packets are a packet re-ordering function may not be necessary if the packets are
either not required to be in order, or if the ordering is performed either not required to be in order, or if the ordering is performed
in some other part of the network.) in some other part of the network.)
As noted in Section 7.2, Packet Sequence Number Integrity As noted in Section 7.2, Integrity Protection, there is a trust
Considerations, there is a trust relationship between the pair of relationship between the pair of devices that replicate and remove
devices that replicate and remove packets, so it is the packets, so it is the responsibility of the system designer to define
responsibility of the system designer to define these relationships these relationships with the appropriate security considerations, and
with the appropriate security considerations, and the components must the components must each uphold the security rights implied by these
each uphold the security rights implied by these relationships. relationships.
Ideally a redundant path could be specified from end to end of the Ideally a redundant path could be specified from end to end of the
flow's path, however given that this is not always possible (as flow's path, however given that this is not always possible (as
described in [RFC8655]) the system designer will need to consider the described in [RFC8655]) the system designer will need to consider the
resulting end-to-end reliability and security resulting from any resulting end-to-end reliability and security resulting from any
given arrangment of network segments along the path, each of which given arrangment of network segments along the path, each of which
provides its individual PREOF implementation and thus its individual provides its individual PREOF implementation and thus its individual
level of reliabiilty and security. level of reliabiilty and security.
At the data plane the implementation of PREOF depends on the correct At the data plane the implementation of PREOF depends on the correct
assignment and interpretation of packet sequence numbers, as well as assignment and interpretation of packet sequence numbers, as well as
the actions taken based on them, such as elimination. Thus the the actions taken based on them, such as elimination. Thus the
integrity of these values must be maintained by the component as they integrity of these values must be maintained by the component as they
are assigned by the DetNet data plane's Service sub-layer, and are assigned by the DetNet Data Plane's Service sub-layer, and
transported by the Forwarding sub-layer. transported by the Forwarding sub-layer.
3.4. Timing Violation Reporting 3.4. Timing (or other) Violation Reporting
Another fundamental assumption of a secure DetNet is that in any case Another fundamental assumption of a secure DetNet is that in any case
in which an incoming packet arrives outside of its prescribed time in which an incoming packet arrives with any timing or bandwidth
window or exceeding the reserved flow bandwidth, something can be violation, something can be done about it which doesn't cause damage
done about it. That means that the component's data plane must be to the system. For example having the network shut down a link if a
able to detect such cases, then at least alert the control plane, packet arrives outside of its prescribed time window may serve the
and/or drop the packet, and/or shut down the link if violations attacker better than it serves the network. That means that the
persist. Logging of such issues may not be adequate, since a delay component's data plane must be able to detect and act on a variety of
in response to the situation could result in material damage, for such violations, at least alerting the controller plane. Any action
example to mechanical devices controlled by the network. apart from that needs to be carefully considered in the context of
the specific system. Some possible violations that warrant detection
include cases where a packet arrives:
o Outside of its prescribed time window
o Within its time window but with a compromised time stamp that
makes it appear that it is not within its window
o Exceeding the reserved flow bandwidth
Logging of such issues is unlikely to be adequate, since a delay in
response to the situation could result in material damage, for
example to mechanical devices controlled by the network. Given that
the data plane component probably has no knowledge of the use case of
the network, or its applications and end systems, it would seem
useful for a data plane component to allow the system designer to
configure its actions in the face of such violations.
Possible direct actions that may be taken at the data plane include
dropping the packet and/or shutting down the link; however if any
such actions are configured to be taken, the system designer must
ensure that such actions do not compromise the continued safe
operation of the system. For example, the controller plane should
mitigate in a timely fashion any potential adverse effect on
mechanical devices controlled by the network.
4. DetNet Security Considerations Compared With DiffServ Security 4. DetNet Security Considerations Compared With DiffServ Security
Considerations Considerations
DetNet is designed to be compatible with DiffServ [RFC2474] as DetNet is designed to be compatible with DiffServ [RFC2474] as
applied to IT traffic in the DetNet. DetNet also incorporates the applied to IT traffic in the DetNet. DetNet also incorporates the
use of the 6-bit value of the DSCP field of the TOS field of the IP use of the 6-bit value of the DSCP field of the TOS field of the IP
header for flow identification for OT traffic, however the DetNet header for flow identification for OT traffic, however the DetNet
interpretation of the DSCP value for OT traffic is not equivalent to interpretation of the DSCP value for OT traffic is not equivalent to
the PHB selection behavior as defined by DiffServ. the PHB selection behavior as defined by DiffServ.
Thus security consideration for DetNet have some aspects in common Thus security consideration for DetNet have some aspects in common
with DiffServ, in fact overlapping 100% with respect to IP IT with DiffServ, in fact overlapping 100% with respect to IP IT
traffic. Security considerations for these aspects are part of the traffic. Security considerations for these aspects are part of the
existing literature on IP network security, specifically the Security existing literature on IP network security, specifically the Security
sections of [RFC2474] and [RFC2475]. However DetNet also introduce sections of [RFC2474] and [RFC2475]. However DetNet also introduces
timing and other considerations which are not present in DiffServ, so timing and other considerations which are not present in DiffServ, so
the DiffServ security considerations are necessary but not sufficient the DiffServ security considerations are necessary but not sufficient
for DetNet. for DetNet.
In the case of DetNet OT traffic, the DSCP value, although In the case of DetNet OT traffic, the DSCP value, although
interpreted differently than in DiffServ, does contribute to interpreted differently than in DiffServ, does contribute to
determination of the service provided to the packet. Thus in DetNet determination of the service provided to the packet. Thus in DetNet
there are similar consequences to DiffServ for lack of detection of, there are similar consequences to DiffServ for lack of detection of,
or incorrect handling of, packets with mismarked DSCP values, and or incorrect handling of, packets with mismarked DSCP values, and
thus many of the points made in the DiffServ draft Security thus many of the points made in the DiffServ draft Security
skipping to change at page 10, line 46 skipping to change at page 11, line 13
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 Care has also been taken to adhere to Section 5 of [RFC3552], both
with respect to which attacks are considered out-of-scope for this with respect to which attacks are considered out-of-scope for this
document, but also which are considered to be the most common threats document, but also which are considered to be the most common threats
(explored further in Section 5.2 (Threat Analysis). Most of the (explored further in Section 5.2, Threat Analysis). Most of the
direct threats to DetNet are active attacks, but it is highly direct threats to DetNet are active attacks, but it is highly
suggested that DetNet application developers take appropriate suggested that DetNet application developers take appropriate
measures to protect the content of the DetNet flows from passive measures to protect the content of the DetNet flows from passive
attacks. 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
skipping to change at page 11, line 22 skipping to change at page 11, line 36
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
security analysis to ensure the integrity of the DetNet networks security analysis to ensure the integrity of the DetNet networks
involved. involved.
5.2. Threat Analysis 5.2. Threat Analysis
5.2.1. Delay 5.2.1. Delay
5.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. The delay may be constant or modulated. variation. The delay may be constant or modulated.
5.2.2. DetNet Flow Modification or Spoofing 5.2.2. 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.
5.2.3. Resource Segmentation or Slicing 5.2.3. Resource Segmentation (Inter-segment Attack)
5.2.3.1. Inter-segment Attack
An attacker can inject traffic that will consume network resources An attacker can inject traffic that will consume network resources
such that it affects DetNet flows. This can be performed using non- such that it affects DetNet flows. This can be performed using non-
DetNet traffic that indirectly affects DetNet traffic (hardware DetNet traffic that indirectly affects DetNet traffic (hardware
resource exhaustion), or by using DetNet traffic from one DetNet flow resource exhaustion), or by using DetNet traffic from one DetNet flow
that directly affects traffic from different DetNet flows. that directly affects traffic from different DetNet flows.
5.2.4. Packet Replication and Elimination 5.2.4. Packet Replication and Elimination
5.2.4.1. Replication: Increased Attack Surface 5.2.4.1. Replication: Increased Attack Surface
Redundancy is intended to increase the robustness and survivability Redundancy is intended to increase the robustness and survivability
of DetNet flows, and replication over multiple paths can potentially of DetNet flows, and replication over multiple paths can potentially
mitigate an attack that is limited to a single path. However, the mitigate an attack that is limited to a single path. However, the
fact that packets are replicated over multiple paths increases the fact that packets are replicated over multiple paths increases the
attack surface of the network, i.e., there are more points in the attack surface of the network, i.e., there are more points in the
network that may be subject to attacks. network that may be subject to attacks.
5.2.4.2. Replication-related Header Manipulation 5.2.4.2. Replication-related Header Manipulation
An attacker can manipulate the replication-related header fields An attacker can manipulate the replication-related header fields.
(R-TAG). This capability opens the door for various types of This capability opens the door for various types of attacks. For
attacks. For example: example:
o Forward both replicas - malicious change of a packet SN (Sequence o Forward both replicas - malicious change of a packet SN (Sequence
Number) can cause both replicas of the packet to be forwarded. Number) can cause both replicas of the packet to be forwarded.
Note that this attack has a similar outcome to a replay attack. Note that this attack has a similar outcome to a replay attack.
o Eliminate both replicas - SN manipulation can be used to cause o Eliminate both replicas - SN manipulation can be used to cause
both replicas to be eliminated. In this case an attacker that has both replicas to be eliminated. In this case an attacker that has
access to a single path can cause packets from other paths to be access to a single path can cause packets from other paths to be
dropped, thus compromising some of the advantage of path dropped, thus compromising some of the advantage of path
redundancy. redundancy.
skipping to change at page 13, line 37 skipping to change at page 13, line 44
A passive eavesdropper can identify DetNet flows and then gather A passive eavesdropper can identify DetNet flows and then gather
information about en route DetNet flows, e.g., the number of DetNet information about en route DetNet flows, e.g., the number of DetNet
flows, their bandwidths, their schedules, or other temporal flows, their bandwidths, their schedules, or other temporal
properties. The gathered information can later be used to invoke properties. The gathered information can later be used to invoke
other attacks on some or all of the flows. other attacks on some or all of the flows.
Note that in some cases DetNet flows may be identified based on an Note that in some cases DetNet flows may be identified based on an
explicit DetNet header, but in some cases the flow identification may 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 be based on fields from the L3/L4 headers. If L3/L4 headers are
involved, for purposes of this document we assume they are encrypted involved, for the purposes of this document we assume they are
and/or integrity-protected from external attackers. encrypted and/or integrity-protected from external attackers.
5.2.8. Time Synchronization Mechanisms 5.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.
5.3. Threat Summary 5.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 14, line 13 skipping to change at page 14, line 21
under the assumption that a corresponding security mechanism is being under the assumption that a corresponding security mechanism is being
used, and that the corresponding network equipment takes part in this used, and that the corresponding network equipment takes part in this
mechanism. mechanism.
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
| Attack | Attacker Type | | Attack | Attacker Type |
| +---------+---------+ | +---------+---------+
| |Internal |External | | |Internal |External |
| |MITM|Inj.|MITM|Inj.| | |MITM|Inj.|MITM|Inj.|
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|Delay attack | + | + | + | + | |Delay attack | + | + | + | + |
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|DetNet Flow Modification or Spoofing | + | + | | | |DetNet Flow Modification or Spoofing | + | + | | |
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|Inter-segment Attack | + | + | | | |Inter-segment Attack | + | + | | |
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|Replication: Increased Attack Surface | + | + | + | + | |Replication: Increased Attack Surface | + | + | + | + |
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|Replication-related Header Manipulation | + | | | | |Replication-related Header Manipulation | + | | | |
+-----------------------------------------+----+----+----+----+ +-----------------------------------------+----+----+----+----+
|Path Manipulation | + | + | | | |Path Manipulation | + | + | | |
skipping to change at page 15, line 12 skipping to change at page 15, line 20
network exploit can also include failure or malfunction of mechanical network exploit can also include failure or malfunction of mechanical
and/or other OT systems. and/or other OT systems.
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 [RFC8578]. Each of the use cases in the DetNet Use Cases detail in the DetNet Use Cases [RFC8578]. Each of these use cases is
is represented in the table below, including Pro Audio, Electrical represented in the table below, including Pro Audio, Electrical
Utilities, Industrial M2M (split into two areas, M2M Data Gathering Utilities, Industrial M2M (split into two areas, M2M Data Gathering
and M2M Control Loop), and others. 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 (People WB), Affect on a single Safety, People well being (People WB), Affect on a single
skipping to change at page 19, line 50 skipping to change at page 20, line 9
In a successful controller plane segmentation attack, control In a successful controller plane segmentation attack, control
messages are acted on by nodes in the network, unbeknownst to the messages are acted on by nodes in the network, unbeknownst to the
central controller or the network engineer. This has the potential central controller or the network engineer. This has the potential
to: to:
o create new DetNet flows (exhausting resources) o create new DetNet flows (exhausting resources)
o drop existing DetNet flows (denial of service) o drop existing DetNet flows (denial of service)
o add/remove end-stations to a multicast group (loss of privacy) o add end-stations to a multicast group (loss of privacy)
o modify the DetNet flow attributes (affecting available bandwidth o remove end-stations from a multicast group (reduction of service)
o modify the DetNet flow attributes (affecting available bandwidth)
6.4. Replication and Elimination 6.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 controller plane messages are not subject to multipath messages as controller plane messages are not subject to multipath
routing. routing.
6.4.1. Increased Attack Surface 6.4.1. Increased Attack Surface
Covered briefly in Section 6.3, Segmentation Attacks. Covered briefly in Section 6.3, Segmentation Attacks.
6.4.2. Header Manipulation at Elimination Routers 6.4.2. Header Manipulation at Elimination Routers
Covered briefly in Section 6.3, Segmentation Attacks. Covered briefly in Section 6.3, Segmentation Attacks.
skipping to change at page 20, line 42 skipping to change at page 21, line 5
counter. Often, an attacker will start out by observing the traffic counter. Often, an attacker will start out by observing the traffic
going through the network and use the knowledge gathered in this going through the network and use the knowledge gathered in this
phase to mount future attacks. phase to mount future attacks.
The attacker can, at their leisure, observe over time all aspects of The attacker can, at their leisure, observe over time all aspects of
the messaging and signalling, learning the intent and purpose of all the messaging and signalling, learning the intent and purpose of all
traffic flows. At some later date, possibly at an important time in traffic flows. At some later date, possibly at an important time in
an operational context, the attacker can launch a multi-faceted an operational context, the attacker can launch a multi-faceted
attack, possibly in conjunction with some demand for ransom. attack, possibly in conjunction with some demand for ransom.
The flow-id in the header of the data plane-messages gives an The flow-id in the header of the data plane messages gives an
attacker a very reliable identifier for DetNet traffic, and this attacker a very reliable identifier for DetNet traffic, and this
traffic has a high probability of going to lucrative targets. traffic has a high probability of going to lucrative targets.
Applications which are ported from a private OT network to the higher Applications which are ported from a private OT network to the higher
visibility DetNet environment may need to be adapted to limit visibility DetNet environment may need to be adapted to limit
distinctive flow properties that could make them susceptible to distinctive flow properties that could make them susceptible to
reconnaissance. reconnaissance.
6.8. Attacks on Time Sync Mechanisms 6.8. Attacks on Time Sync Mechanisms
skipping to change at page 23, line 27 skipping to change at page 23, line 35
Section 5.2.7. Section 5.2.7.
7.5. Encryption 7.5. Encryption
Description Description
DetNet flows can in principle be forwarded in encrypted form at DetNet flows can in principle be forwarded in encrypted form at
the DetNet layer, however, regarding encryption of IP headers see the DetNet layer, however, regarding encryption of IP headers see
Section 9. Section 9.
Alternatively, if the payload is end-to-end encrypted at the DetNet nodes do not have any need to inspect the payload of any
application layer, the DetNet nodes should not have any need to DetNet packets, making them data-agnostic. This means that end-
inspect the payload itself, and thus the DetNet implementation can to- end encryption at the application layer is an acceptable way
be data-agnostic. to protect user data.
Encryption can also be applied at the subnet layer, for example Encryption can also be applied at the subnet layer, for example
for Ethernet using MACSec, as noted in Section 9. for Ethernet using MACSec, as noted in Section 9.
Related attacks Related attacks
Encryption can be used to mitigate recon attacks (Section 5.2.7). Encryption can be used to mitigate recon attacks (Section 5.2.7).
However, for a DetNet network to give differentiated quality of However, for a DetNet network to give differentiated quality of
service on a flow-by-flow basis, the network must be able to service on a flow-by-flow basis, the network must be able to
identify the flows individually. This implies that in a recon identify the flows individually. This implies that in a recon
skipping to change at page 27, line 24 skipping to change at page 27, line 34
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 [RFC8578]. section of the DetNet Use Cases [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.
8.1. Use Cases by Common Themes 8.1. Association of Attacks to Use Case 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, Mapping Between Themes and Attacks, then provides The table Figure 5, Mapping Between Themes and Attacks, then provides
a summary of the attacks that are applicable to each theme. a summary of the attacks that are applicable to each theme.
8.1.1. Sub-Network Layer 8.1.1. Sub-Network Layer
DetNet is expected to run over various transmission mediums, with DetNet is expected to run over various transmission mediums, with
Ethernet being the first identified. Attacks such as Delay or Ethernet being the first identified. Attacks such as Delay or
Reconnaissance might be implemented differently on a different Reconnaissance might be implemented differently on a different
transmission medium, however the impact on the DetNet as a whole transmission medium, however the impact on the DetNet as a whole
would be essentially the same. We thus conclude that all attacks and would be essentially the same. We thus conclude that all attacks and
impacts that would be applicable to DetNet over Ethernet (i.e. all impacts that would be applicable to DetNet over Ethernet (i.e. all
those named in this document) would also be applicable to DetNet over those named in this document) would also be applicable to DetNet over
other transmission mediums. other transmission mediums.
With respect to mitigations, some methods are specific to the With respect to mitigations, some methods are specific to the
Ethernet medium, for example time-aware scheduling using 802.1Qbv can Ethernet medium, for example time-aware scheduling using 802.1Qbv
protect against excessive use of bandwidth at the ingress - for other [IEEE802.1Qbv-2015] can protect against excessive use of bandwidth at
mediums, other mitigations would have to be implemented to provide the ingress - for other mediums, other mitigations would have to be
analogous protection. implemented to provide analogous protection.
8.1.2. Central Administration 8.1.2. Central Administration
A DetNet network can be controlled by a centralized network A DetNet network can be controlled by a centralized network
configuration and control system. Such a system may be in a single configuration and control system. Such a system may be in a single
central location, or it may be distributed across multiple control central location, or it may be distributed across multiple control
entities that function together as a unified control system for the entities that function together as a unified control system for the
network. network.
In this document we distinguish between attacks on the DetNet In this document we distinguish between attacks on the DetNet
Controller plane vs. Data plane. But is an attack affecting control Controller plane vs. Data Plane. But is an attack affecting
plane packets synonymous with an attack on the control plane itself? controller plane packets synonymous with an attack on the controller
For purposes of this document let us consider an attack on the plane itself? For the purposes of this document let us consider an
control system itself to be out of scope, and consider all attacks attack on the control system itself to be out of scope, and consider
named in this document which are relevant to controller plane packets all attacks named in this document which are relevant to controller
to be relevant to this theme, including Path Manipulation, Path plane packets to be relevant to this theme, including Path
Choice, Control Packet Modification or Injection, Reconaissance and Manipulation, Path Choice, Control Packet Modification or Injection,
Attacks on Time Sync Mechanisms. Reconaissance and Attacks on Time Sync Mechanisms.
8.1.3. Hot Swap 8.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. implementation.
skipping to change at page 29, line 17 skipping to change at page 29, line 23
8.1.4. Data Flow Information Models 8.1.4. Data Flow Information Models
Data Flow YANG models specific to DetNet networks are specified by Data Flow YANG models specific to DetNet networks are specified by
DetNet, and thus are 'new' and thus potentially present a new attack DetNet, and thus are 'new' and thus potentially present a new attack
surface. surface.
8.1.5. L2 and L3 Integration 8.1.5. L2 and L3 Integration
A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN
LAN) and Layer 3 (routed) networks via the use of well-known LAN) and Layer 3 (routed) networks via the use of well-known
protocols such as IP, MPLS-PW, and Ethernet. protocols such as IP, MPLS Pseudowire, and Ethernet.
There are no specific entries in our table, however that does not There are no specific entries in the mapping table Figure 4, however
imply that there could be no relevant attacks related to L2,L3 that does not imply that there could be no relevant attacks related
integration. to L2-L3 integration.
8.1.6. End-to-End Delivery 8.1.6. End-to-End Delivery
Packets sent over DetNet are not to be dropped by the network due to Packets sent over DetNet are not to be dropped by the network due to
congestion. (Packets may however intentionally be dropped for congestion. (Packets may however intentionally be dropped for
intended reasons, e.g. per security measures). intended reasons, e.g. per security measures).
A Data plane attack may force packets to be dropped, for example a A data plane attack may force packets to be dropped, for example a
"long" Delay or Replication/Elimination or Flow Modification attack. "long" Delay or Replication/Elimination or Flow Modification attack.
The same result might be obtained by a controller plane attack, e.g. The same result might be obtained by a controller plane attack, e.g.
Path Manipulation or Signaling Packet Modification. Path Manipulation or Signaling Packet Modification.
It may be that such attacks are limited to Internal MITM attackers, It may be that such attacks are limited to Internal MITM attackers,
but other possibilities should be considered. but other possibilities should be considered.
An attack may also cause packets that should not be delivered to be 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 delivered, such as by forcing packets from one (e.g. replicated) path
to be preferred over another path when they should not be to be preferred over another path when they should not be
(Replication attack), or by Flow Modification, or by Path Choice or (Replication attack), or by Flow Modification, or by Path Choice or
Packet Injection. A Time Sync attack could cause a system that was Packet Injection. A Time Sync attack could cause a system that was
expecting certain packets at certain times to accept unintended expecting certain packets at certain times to accept unintended
packets based on compromised system time or time windowing in the packets based on compromised system time or time windowing in the
scheduler. scheduler.
Packets may also be dropped due to malfunctioning software or 8.1.7. Replacement for Proprietary Fieldbuses and Ethernet-based
hardware. Networks
8.1.7. Proprietary Deterministic Ethernet Networks
There are many proprietary non-interoperable deterministic Ethernet-
based networks currently available; DetNet is intended to provide an
open-standards-based alternative to such networks. In cases where a
DetNet intersects with remnants of such networks or their protocols,
such as by protocol emulation or access to such a network via a
gateway, new attack surfaces can be opened.
For example an Inter-Segment or Controller 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.
8.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, as well as proprietary non-interoperable
standards-based alternative to such buses. In cases where a DetNet deterministic Ethernet-based networks. DetNet is intended to provide
intersects with such fieldbuses or their protocols, such as by an open-standards-based alternative to such buses/networks. In cases
protocol emulation or access via a gateway, new attack surfaces can where a DetNet intersects with such fieldbuses/networks or their
be opened. protocols, such as by protocol emulation or access via a gateway, new
attack surfaces can be opened.
For example an Inter-Segment or Controller plane attack such as Path For example an Inter-Segment or Controller plane attack such as Path
Manipulation, Path Choice or Control Packet Modification/Injection Manipulation, Path Choice or Control Packet Modification/Injection
could be used to exploit commands specific to such a protocol, or could be used to exploit commands specific to such a protocol, or
that are interpreted differently by the different protocols or that are interpreted differently by the different protocols or
gateway. gateway.
8.1.9. Deterministic vs Best-Effort Traffic 8.1.8. Deterministic vs Best-Effort Traffic
Most of the themes described in this document address OT (reserved) Most of the themes described in this document address OT (reserved)
DetNet flows - this item is intended to address issues related to IT DetNet flows - this item is intended to address issues related to IT
traffic on a DetNet. traffic on a DetNet.
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. effort") traffic on the same ("unified") network.
With DetNet, this coexistance will become more common, and With DetNet, this coexistance will become more common, and
skipping to change at page 31, line 16 skipping to change at page 31, line 5
with the intent of disrupting handling of IT traffic, and/or the goal with the intent of disrupting handling of IT traffic, and/or the goal
of interfering with OT traffic. Presumably if the DetNet flow of interfering with OT traffic. Presumably if the DetNet flow
reservation and isolation of the DetNet is well-designed (better- reservation and isolation of the DetNet is well-designed (better-
designed than the attack) then interference with OT traffic should designed than the attack) then interference with OT traffic should
not result from an attack that floods the network with IT traffic. 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 However the DetNet's handling of IT traffic may not (by design) be as
resilient to DOS attack, and thus designers must be otherwise resilient to DOS attack, and thus designers must be otherwise
prepared to mitigate DOS attacks on IT traffic in a DetNet. prepared to mitigate DOS attacks on IT traffic in a DetNet.
8.1.10. Deterministic Flows 8.1.9. Deterministic Flows
Reserved bandwidth data flows (deterministic flows) must provide the Reserved bandwidth data flows (deterministic flows) must provide the
allocated bandwidth, and must be isolated from each other. allocated bandwidth, and must be isolated from each other.
A Spoofing or Inter-segment attack which adds packet traffic to a A Spoofing or Inter-segment attack which adds packet traffic to a
bandwidth-reserved DetNet flow could cause that flow to occupy more bandwidth-reserved DetNet flow could cause that flow to occupy more
bandwidth than it was allocated, resulting in interference with other bandwidth than it was allocated, resulting in interference with other
DetNet flows. DetNet flows.
A Flow Modification or Spoofing or Header Manipulation or Control A Flow Modification or Spoofing or Header Manipulation or Control
Packet Modification attack could cause packets from one flow to be Packet Modification attack could cause packets from one flow to be
directed to another flow, thus breaching isolation between the flows. directed to another flow, thus breaching isolation between the flows.
8.1.11. Unused Reserved Bandwidth 8.1.10. Unused Reserved Bandwidth
If bandwidth reservations are made for a DetNet flow but the If bandwidth reservations are made for a DetNet flow but the
associated bandwidth is not used at any point in time, that bandwidth associated bandwidth is not used at any point in time, that bandwidth
is made available on the network for best-effort traffic. However, is made available on the network for best-effort traffic. However,
note that security considerations for best-effort traffic on a DetNet note that security considerations for best-effort traffic on a DetNet
network is out of scope of the present document, provided that such network is out of scope of the present document, provided that such
an attack does not affect performance for DetNet OT traffic. an attack does not affect performance for DetNet OT traffic.
8.1.12. Interoperability 8.1.11. 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. device manufactured.
Given that the DetNet specifications are unambiguously written and Given that the DetNet specifications are unambiguously written and
that the implementations are accurate, then this should not in and of that the implementations are accurate, then this should not in and of
itself cause a security concern; however, in the real world, it could itself cause a security concern; however, in the real world, it could
be. The network operator can mitigate this through sufficient be. The network operator can mitigate this through sufficient
interoperability testing. interoperability testing.
8.1.13. Cost Reductions 8.1.12. 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. Such "low cost" reduction and cost competition among vendors.
hardware or software components might present security concerns.
This envisioned breadth of DetNet-enabled products is in general a
positive factor, however implementation flaws in any individual
component can present an attack surface. In addition, implementation
differences between components from different vendors can result in
attack surfaces (resulting from their interaction) which may not
exist in any individual component.
Network operators can mitigate such concerns through sufficient Network operators can mitigate such concerns through sufficient
product testing. product and interoperability testing.
8.1.14. Insufficiently Secure Devices 8.1.13. 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. Software that was originally designed for device manufactured. However this raises the possibility that a
operation in isolated OT networks (and thus may not have been vendor might repurpose for DetNet applications a hardware or software
designed to be sufficiently secure, or secure at all) but is then component that was originally designed for operation in an isolated
deployed on a DetNet network that is intended to be highly secure may OT network, and thus may not have been designed to be sufficiently
present an attack surface. (For example IoT exploits like the Mirai secure, or secure at all. Deployment of such a device on a DetNet
video-camera botnet ([MIRAI]). network that is intended to be highly secure may present an attack
surface.
The DetNet network operator may need to take specific actions to The DetNet network operator may need to take specific actions to
protect such devices. protect such devices, such as implementing a dedicated security layer
around the device.
8.1.15. DetNet Network Size 8.1.14. 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. spanning a whole country.
The size of the network might be related to how the attack is The size of the network might be related to how the attack is
introduced into the network, for example if the entire network is introduced into the network, for example if the entire network is
local, there is a threat that power can be cut to the entire network. local, there is a threat that power can be cut to the entire network.
If the network is large, perhaps only a part of the network is If the network is large, perhaps only a part of the network is
attacked. attacked.
A Delay attack might be as relevant to a small network as to a large A Delay attack might be as relevant to a small network as to a large
network, although the amount of delay might be different. network, although the amount of delay might be different.
Attacks sourced from IT traffic might be more likely in large Attacks sourced from IT traffic might be more likely in large
networks, since more people might have access to the network, networks, since more people might have access to the network,
presenting a larger attack surface. Similarly Path Manipulation, presenting a larger attack surface. Similarly Path Manipulation,
Path Choice and Time Sync attacks seem more likely relevant to large Path Choice and Time Sync attacks seem more likely relevant to large
networks. networks.
8.1.16. Multiple Hops 8.1.15. Multiple Hops
Large DetNet networks (e.g. a Utility Grid network) may involve many Large DetNet networks (e.g. a Utility Grid network) may involve many
"hops" over various kinds of links for example radio repeaters, "hops" over various kinds of links for example radio repeaters,
microwave links, fiber optic links, etc. microwave links, fiber optic links, etc.
An attack that takes advantage of flaws (or even normal operation) in An attack that takes advantage of flaws (or even normal operation) in
the device drivers for the various links (through internal knowledge the device drivers for the various links (through internal knowledge
of how the individual driver or firmware operates, perhaps like the of how the individual driver or firmware operates) could take
Stuxnet attack) could take proportionately greater advantage of this proportionately greater advantage of this topology.
topology.
It is also possible that this DetNet topology will not be in as 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 common use as other more homogeneous topologies so there may be more
opportunity for attackers to exploit software and/or protocol flaws opportunity for attackers to exploit software and/or protocol flaws
in the implementations which have not been wrung out by extensive in the implementations which have not been tested through extensive
use, particularly in the case of early adopters. use, particularly in the case of early adopters.
Of the attacks we have defined, the ones identified above as relevant Of the attacks we have defined, the ones identified in Section 8.1.14
to "large" networks are the most relevant. as germane to large networks are the most relevant.
8.1.17. Level of Service 8.1.16. 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 DetNet flow, requesting worst case maximum and/or minimum a given DetNet flow, requesting worst case maximum and/or minimum
latency for a given path or DetNet flow, and so on. It is an latency for a given path or DetNet flow, and so on. It is an
expected case that the network cannot provide a given requested expected case that the network cannot provide a given requested
service level. In such cases the network control system should reply service level. In such cases the network control system should reply
that the requested service level is not available (as opposed to that the requested service level is not available (as opposed to
accepting the parameter but then not delivering the desired accepting the parameter but then not delivering the desired
behavior). behavior).
Controller plane attacks such as Signaling Packet Modification and Controller plane attacks such as Signaling Packet Modification and
Injection could be used to modify or create control traffic that Injection could be used to modify or create control traffic that
could interfere with the process of a user requesting a level of could interfere with the process of a user requesting a level of
service and/or the network's reply. service and/or the network's reply.
Reconnaissance could be used to characterize flows and perhaps target Reconnaissance could be used to characterize flows and perhaps target
specific flows for attack via the controller plane as noted above. specific flows for attack via the controller plane as noted in
Section 6.7.
8.1.18. Bounded Latency 8.1.17. Bounded Latency
DetNet provides the expectation of guaranteed bounded latency. DetNet provides the expectation of guaranteed bounded latency.
Delay attacks can cause packets to miss their agreed-upon latency Delay attacks can cause packets to miss their agreed-upon latency
boundaries. boundaries.
Time Sync attacks can corrupt the system's time reference, resulting Time Sync attacks can corrupt the system's time reference, resulting
in missed latency deadlines (with respect to the "correct" time in missed latency deadlines (with respect to the "correct" time
reference). reference).
8.1.19. Low Latency 8.1.18. 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. in a given network.
Attacks on the controller plane (as described in the Level of Service Attacks on the controller plane (as described in the Level of Service
theme) and Delay and Time attacks (as described in the Bounded theme Section 8.1.16) and Delay and Time attacks (as described in the
Latency theme) both apply here. Bounded Latency theme Section 8.1.17) both apply here.
8.1.20. Bounded Jitter (Latency Variation) 8.1.19. Bounded Jitter (Latency Variation)
DetNet is expected to provide bounded jitter (packet to packet DetNet is expected to provide bounded jitter (packet to packet
latency variation). latency variation).
Delay attacks can cause packets to vary in their arrival times, Delay attacks can cause packets to vary in their arrival times,
resulting in packet to packet latency variation, thereby violating resulting in packet to packet latency variation, thereby violating
the jitter specification. the jitter specification.
8.1.21. Symmetrical Path Delays 8.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. values be equal for both the transmit and return paths.
Delay attacks can cause path delays to materially differ between Delay attacks can cause path delays to materially differ between
paths. paths.
Time Sync attacks can corrupt the system's time reference, resulting Time Sync attacks can corrupt the system's time reference, resulting
in path delays that may be perceived to be different (with respect to in path delays that may be perceived to be different (with respect to
the "correct" time reference) even if they are not materially the "correct" time reference) even if they are not materially
different. different.
8.1.22. Reliability and Availability 8.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. communicating these kinds of metrics within the network.
Any attack on the system, of any type, can affect its overall Any attack on the system, of any type, can affect its overall
reliability and availability, thus in our table we have marked every reliability and availability, thus in the mapping table Figure 4 we
attack. Since every DetNet depends to a greater or lesser degree on have marked every attack. Since every DetNet depends to a greater or
reliability and availability, this essentially means that all lesser degree on reliability and availability, this essentially means
networks have to mitigate all attacks, which to a greater or lesser that all networks have to mitigate all attacks, which to a greater or
degree defeats the purpose of associating attacks with use cases. It lesser degree defeats the purpose of associating attacks with use
also underscores the difficulty of designing "extremely high cases. It also underscores the difficulty of designing "extremely
reliability" networks. high reliability" networks.
8.1.23. Redundant Paths 8.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. the while maintaining the required performance of that system.
Replication-related attacks are by definition applicable here. Replication-related attacks are by definition applicable here.
Controller plane attacks can also interfere with the configuration of Controller plane attacks can also interfere with the configuration of
redundant paths. redundant paths.
8.1.24. Security Measures 8.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 This is TBD, thus there are no specific entries in the mapping table
that does not imply that there could be no relevant attacks. Figure 4, however that does not imply that there could be no relevant
attacks.
8.2. Attack Types by Use Case Common Theme 8.2. Summary of Attack Types per Use Case Common Theme
The following table lists the attacks of Section 5, Security Threats, The List of Attacks table Figure 4 lists the attacks of Section 5,
assigning a number to each type of attack. That number is then used Security Threats, assigning a number to each type of attack. That
as a short form identifier for the attack in Figure 5, Mapping number is then used as a short form identifier for the attack in
Between Themes and Attacks. Figure 5, Mapping Between Themes and Attacks.
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| | Attack | Section | | | Attack | Section |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| 1|Delay Attack | Section 3.2.1 | | 1|Delay Attack | Section 3.2.1 |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| 2|DetNet Flow Modification or Spoofing | Section 3.2.2 | | 2|DetNet Flow Modification or Spoofing | Section 3.2.2 |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| 3|Inter-Segment Attack | Section 3.2.3 | | 3|Inter-Segment Attack | Section 3.2.3 |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
skipping to change at page 36, line 33 skipping to change at page 36, line 33
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| 9|Control or Signaling Packet Injection | Section 3.2.6.2 | | 9|Control or Signaling Packet Injection | Section 3.2.6.2 |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
|10|Reconnaissance | Section 3.2.7 | |10|Reconnaissance | Section 3.2.7 |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
|11|Attacks on Time Sync Mechanisms | Section 3.2.8 | |11|Attacks on Time Sync Mechanisms | Section 3.2.8 |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
Figure 4: List of Attacks Figure 4: List of Attacks
The following table maps the use case themes presented in this memo The Mapping Between Themes and Attacks table Figure 5 maps the use
to the attacks of Figure 4. Each row specifies a theme, and the case themes of [RFC8578] (as also enumerated in this document) to the
attacks relevant to this theme are marked with a '+'. attacks of Figure 4. Each row specifies a theme, and the attacks
relevant to this theme are marked with a '+'.
+----------------------------+--------------------------------+ +----------------------------+--------------------------------+
| Theme | Attack | | Theme | Attack |
| +--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+
| | 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 | | | | | | +| +| +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 38, line 9 skipping to change at page 38, line 9
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Security Measures | | | | | | | | | | | | |Security Measures | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
Figure 5: Mapping Between Themes and Attacks Figure 5: Mapping Between Themes and Attacks
8.3. Security Considerations for OAM Traffic 8.3. Security Considerations for OAM Traffic
This section considers DetNet-specific security considerations for This section considers DetNet-specific security considerations for
packet traffic that is generated and transmitted over a DetNet as packet traffic that is generated and transmitted over a DetNet as
part of OAM (Operations, Administration and Maintenance). For part of OAM (Operations, Administration, and Maintenance). For the
purposes of this discussion, OAM traffic falls into one of two basic purposes of this discussion, OAM traffic falls into one of two basic
types: types:
o OAM traffic generated by the network itself. The additional o OAM traffic generated by the network itself. The additional
bandwidth required for such packets is added by the network bandwidth required for such packets is added by the network
administration, presumably transparent to the customer. Security administration, presumably transparent to the customer. Security
considerations for such traffic are not DetNet-specific (apart considerations for such traffic are not DetNet-specific (apart
from such traffic being subject to the same DetNet-specific from such traffic being subject to the same DetNet-specific
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.
skipping to change at page 39, line 6 skipping to change at page 39, line 6
([I-D.ietf-detnet-ip]) and delivers service over sub-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 technologies such as MPLS ([I-D.ietf-detnet-mpls]) and IEEE 802.1
Time-Sensitive Networking (TSN) ([I-D.ietf-detnet-ip-over-tsn]). Time-Sensitive Networking (TSN) ([I-D.ietf-detnet-ip-over-tsn]).
Application flows can be protected through whatever means are Application flows can be protected through whatever means are
provided by the layer and sub-layer technologies. For example, provided by the layer and sub-layer technologies. For example,
technology-specific encryption may be used, such as that provided by technology-specific encryption may be used, such as that provided by
IPSec [RFC4301] for IP flows and/or by an underlying sub-net using IPSec [RFC4301] for IP flows and/or by an underlying sub-net using
MACSec [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. MACSec [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
However, if the DetNet nodes cannot decrypt IPsec traffic, IPSec may However, if the DetNet nodes cannot decrypt IPsec traffic, IPSec may
not be a valid option; this is because the DetNet IP data plane not be a valid option; this is because the DetNet IP Data Plane
identifies flows via a 6-tuple that consists of two IP addresses, the identifies flows via a 6-tuple that consists of two IP addresses, the
transport protocol ID, two transport protocol port numbers and the transport protocol ID, two transport protocol port numbers and the
DSCP in the IP header. When IPsec is used, the transport header is DSCP in the IP header. When IPsec is used, the transport header is
encrypted and the next protocol ID is an IPsec protocol, usually ESP, encrypted and the next protocol ID is an IPsec protocol, usually ESP,
and not a transport protocol (e.g., neither TCP nor UDP, etc.) and not a transport protocol (e.g., neither TCP nor UDP, etc.)
leaving only three components of the 6-tuple, which are the two IP leaving only three components of the 6-tuple, which are the two IP
addresses and the DSCP, which are in general not sufficient to addresses and the DSCP, which are in general not sufficient to
identify a DetNet flow. identify a DetNet flow.
Sections below discuss threats specific to IP and MPLS in more Sections below discuss threats specific to IP and MPLS in more
detail. detail.
9.1. IP 9.1. IP
The IP protocol has a long history of security considerations and The IP protocol has a long history of security considerations and
architectural protection mechanisms. From a data plane perspective architectural protection mechanisms. From a data plane perspective
DetNet does not add or modify any IP header information, and its use DetNet does not add or modify any IP header information, so the
as a DetNet Data Plane does not introduce any new security issues carriage of DetNet traffic over an IP data plane does not introduce
that were not there before, apart from those already described in the any new security issues that were not there before, apart from those
data-plane-independent threats section Section 5, Security Threats. already described in the data-plane-independent threats section
Section 5, Security Threats.
Thus the security considerations for a DetNet based on an IP data Thus the security considerations for a DetNet based on an IP data
plane are purely inherited from the rich IP Security literature and plane are purely inherited from the rich IP Security literature and
code/application base, and the data-plane-independent section of this code/application base, and the data-plane-independent section of this
document. document.
Maintaining security for IP segments of a DetNet may be more Maintaining security for IP segments of a DetNet may be more
challenging than for the MPLS segments of the network, given that the challenging than for the MPLS segments of the network, given that the
IP segments of the network may reach the edges of the network, which IP segments of the network may reach the edges of the network, which
are more likely to involve interaction with potentially malevolent are more likely to involve interaction with potentially malevolent
skipping to change at page 43, line 7 skipping to change at page 43, line 7
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-06 (work in progress), May 2020. data-plane-framework-06 (work in progress), May 2020.
[I-D.ietf-detnet-flow-information-model] [I-D.ietf-detnet-flow-information-model]
Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- Fedyk, "DetNet Flow Information Model", draft-ietf-detnet-
flow-information-model-10 (work in progress), May 2020. flow-information-model-10 (work in progress), May 2020.
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07
(work in progress), April 2020. (work in progress), July 2020.
[I-D.ietf-detnet-ip-over-tsn] [I-D.ietf-detnet-ip-over-tsn]
Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
Data Plane: IP over IEEE 802.1 Time Sensitive Networking Data Plane: IP over IEEE 802.1 Time Sensitive Networking
(TSN)", draft-ietf-detnet-ip-over-tsn-02 (work in (TSN)", draft-ietf-detnet-ip-over-tsn-03 (work in
progress), March 2020. progress), June 2020.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
detnet-mpls-06 (work in progress), April 2020. detnet-mpls-10 (work in progress), July 2020.
[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] [IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018, Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>. <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1Qbv-2015]
IEEE Standards Association, "IEEE Standard for Local and
metropolitan area networks -- Bridges and Bridged Networks
- Amendment 25: Enhancements for Scheduled Traffic", 2015,
<https://ieeexplore.ieee.org/document/8613095>.
[IEEE802.1Qch-2017] [IEEE802.1Qch-2017]
IEEE Standards Association, "IEEE Standard for Local and IEEE Standards Association, "IEEE Standard for Local and
metropolitan area networks--Bridges and Bridged Networks-- metropolitan area networks--Bridges and Bridged Networks--
Amendment 29: Cyclic Queuing and Forwarding", 2017, Amendment 29: Cyclic Queuing and Forwarding", 2017,
<https://ieeexplore.ieee.org/document/7961303>. <https://ieeexplore.ieee.org/document/7961303>.
[MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/ [IT_DEF] Wikipedia, "IT Definition", 2020,
hacked-cameras-dvrs-powered-todays-massive-internet- <https://en.wikiquote.org/wiki/Information_technology>.
outage/", 2016.
[OT_DEF] Wikipedia, "OT Definition", 2020,
<https://en.wikipedia.org/wiki/Operational_technology>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
skipping to change at page 45, line 28 skipping to change at page 45, line 38
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019, RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>. <https://www.rfc-editor.org/info/rfc8578>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RS_DEF] Wikipedia, "RS Definition", 2020,
<https://en.wikipedia.org/wiki/Network_segmentation>.
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
San Francisco, CA 94103 San Francisco, CA 94103
USA USA
Phone: +1 415 645 4726 Phone: +1 415 645 4726
Email: ethan.grossman@dolby.com Email: ethan.grossman@dolby.com
URI: http://www.dolby.com URI: http://www.dolby.com
 End of changes. 95 change blocks. 
235 lines changed or deleted 249 lines changed or added

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