draft-ietf-detnet-security-07.txt   draft-ietf-detnet-security-08.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: July 13, 2020 DOLBY Expires: August 6, 2020 DOLBY
A. Hacker A. Hacker
MISTIQ MISTIQ
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
J. Dowdell J. Dowdell
Airbus Defence and Space Airbus Defence and Space
H. Austad H. Austad
SINTEF Digital SINTEF Digital
N. Finn N. Finn
HUAWEI HUAWEI
January 10, 2020 February 3, 2020
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-07 draft-ietf-detnet-security-08
Abstract Abstract
A deterministic network is one that can carry data flows for real- A deterministic network is one that can carry data flows for real-
time applications with extremely low data loss rates and bounded time applications with extremely low data loss rates and bounded
latency. Deterministic networks have been successfully deployed in latency. Deterministic networks have been successfully deployed in
real-time operational technology (OT) applications for some years. real-time operational technology (OT) applications for some years.
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) specifies a set of technologies
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 July 13, 2020. This Internet-Draft will expire on August 6, 2020.
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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
3.2.6.1. Control or Signaling Packet Modification . . . . 9 3.2.6.1. Control or Signaling Packet Modification . . . . 9
3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9
3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9
3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9
3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9
3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9
4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10
4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13
4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 13 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 14
4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14
4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14
4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14
4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 15
4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15
4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15
4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15
4.4. Replication and Elimination . . . . . . . . . . . . . . . 15 4.4. Replication and Elimination . . . . . . . . . . . . . . . 16
4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 16
4.4.2. Header Manipulation at Elimination Bridges . . . . . 16 4.4.2. Header Manipulation at Elimination Bridges . . . . . 16
4.5. Control or Signaling Packet Modification . . . . . . . . 16 4.5. Control or Signaling Packet Modification . . . . . . . . 16
4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16
4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16
4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 17
4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 17
5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 17 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 17
5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17
5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17
5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 18 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 18
5.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 18 5.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 18
5.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18 5.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
5.5.1. Encryption Considerations for DetNet . . . . . . . . 19 5.5.1. Encryption Considerations for DetNet . . . . . . . . 19
5.6. Control and Signaling Message Protection . . . . . . . . 20 5.6. Control and Signaling Message Protection . . . . . . . . 20
5.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 20 5.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 21
5.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 21 5.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 21
6. Association of Attacks to Use Cases . . . . . . . . . . . . . 22 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 23
6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 22 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 23
6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 23
6.1.2. Central Administration . . . . . . . . . . . . . . . 23 6.1.2. Central Administration . . . . . . . . . . . . . . . 24
6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 23 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 24
6.1.4. Data Flow Information Models . . . . . . . . . . . . 24 6.1.4. Data Flow Information Models . . . . . . . . . . . . 25
6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 24 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 25
6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 24 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 25
6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 25 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 25
6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 25 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 26
6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 26
6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 26 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 27
6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 26 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 27
6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 27 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 27
6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 27 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 27
6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 27 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 28
6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 28
6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 28 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 28
6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 29
6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 29 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 29
6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 29 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 30
6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 30
6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 30
6.1.22. Reliability and Availability . . . . . . . . . . . . 30 6.1.22. Reliability and Availability . . . . . . . . . . . . 30
6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 30 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 31
6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 31
6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 31 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 31
6.3. Security Considerations for OAM Traffic . . . . . . . . . 33 6.3. Security Considerations for OAM Traffic . . . . . . . . . 34
7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33 7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 34
7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Informative References . . . . . . . . . . . . . . . . . . . 36 10. Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Security is of particularly high importance in DetNet networks Security is of particularly high importance in DetNet networks
because many of the use cases which are enabled by DetNet [RFC8578] because many of the use cases which are enabled by DetNet [RFC8578]
include control of physical devices (power grid components, include control of physical devices (power grid components,
industrial controls, building controls) which can have high industrial controls, building controls) which can have high
operational costs for failure, and present potentially attractive operational costs for failure, and present potentially attractive
targets for cyber-attackers. targets for cyber-attackers.
skipping to change at page 10, line 47 skipping to change at page 10, line 47
4. Security Threat Impacts 4. Security Threat Impacts
This section describes and rates the impact of the attacks described This section describes and rates the impact of the attacks described
in Section 3. In this section, the impacts as described assume that in Section 3. In this section, the impacts as described assume that
the associated mitigation is not present or has failed. Mitigations the associated mitigation is not present or has failed. Mitigations
are discussed in Section 5. are discussed in Section 5.
In computer security, the impact (or consequence) of an incident can In computer security, the impact (or consequence) of an incident can
be measured in loss of confidentiality, integrity or availability of be measured in loss of confidentiality, integrity or availability of
information. information. In the case of time sensitive networks, the impact of a
network exploit can also include failure or malfunction of mechanical
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 [RFC8578]. Each of the use cases in the DetNet Use Cases
is represented in the table below, including Pro Audio, Electrical is represented in the table below, including Pro Audio, Electrical
skipping to change at page 13, line 30 skipping to change at page 13, line 32
Figure 2: Impact of Attacks by Use Case Industry Figure 2: Impact of Attacks by Use Case Industry
The rest of this section will cover impact of the different groups in The rest of this section will cover impact of the different groups in
more detail. more detail.
4.1. Delay-Attacks 4.1. Delay-Attacks
4.1.1. Data Plane Delay Attacks 4.1.1. Data Plane Delay Attacks
Note that 'delay attack' also includes the possibility of a 'negative
delay' or early arrival of a packet, or possibly adversely changing
the timestamp value.
Delayed messages in a DetNet link can result in the same behavior as Delayed messages in a DetNet link can result in the same behavior as
dropped messages in ordinary networks as the services attached to the dropped messages in ordinary networks as the services attached to the
stream has strict deterministic requirements. stream has strict deterministic requirements.
For a single path scenario, disruption is a real possibility, whereas For a single path scenario, disruption is a real possibility, whereas
in a multipath scenario, large delays or instabilities in one stream in a multipath scenario, large delays or instabilities in one stream
can lead to increased buffer and CPU resources on the elimination can lead to increased buffer and CPU resources on the elimination
bridge. bridge.
A data-plane delay attack on a system controlling substantial moving A data-plane delay attack on a system controlling substantial moving
skipping to change at page 17, line 31 skipping to change at page 17, line 40
attacks. attacks.
Related attacks Related attacks
Path redundancy can be used to mitigate various man-in-the-middle Path redundancy can be used to mitigate various man-in-the-middle
attacks, including attacks described in Section 3.2.1, attacks, including attacks described in Section 3.2.1,
Section 3.2.2, Section 3.2.3, and Section 3.2.8. However it is Section 3.2.2, Section 3.2.3, and Section 3.2.8. However it is
also possible that multiple paths may make it more difficult to also possible that multiple paths may make it more difficult to
locate the source of a MITM attacker. locate the source of a MITM attacker.
A delay modulation attack could result in extensively exercising
parts of the code that wouldn't normally be extensively exercised
and thus might expose flaws in the system that might otherwise not
be exposed.
5.2. Integrity Protection 5.2. Integrity Protection
Description Description
An integrity protection mechanism, such as a Hash-based Message An integrity protection mechanism, such as a Hash-based Message
Authentication Code (HMAC) can be used to mitigate modification Authentication Code (HMAC) can be used to mitigate modification
attacks on IP packets. Integrity protection in the control plane attacks on IP packets. Integrity protection in the control plane
is discussed in Section 5.6. is discussed in Section 5.6.
Packet Sequence Number Integrity Considerations Packet Sequence Number Integrity Considerations
skipping to change at page 19, line 4 skipping to change at page 19, line 17
Related attacks Related attacks
Removing distinctive temporal properties of individual packets or Removing distinctive temporal properties of individual packets or
flows can be used to mitigate against reconnaissance attacks flows can be used to mitigate against reconnaissance attacks
Section 3.2.7. Section 3.2.7.
5.5. Encryption 5.5. Encryption
Description Description
DetNet flows can be forwarded in encrypted form at the DetNet
layer. Alternatively, if the payload is end-to-end encrypted at DetNet flows can in principle be forwarded in encrypted form at
the application layer, the DetNet nodes should not have any need the DetNet layer, however, regarding encryption of IP headers see
to inspect the payload itself, and thus the DetNet implementation Section 7.
can be data-agnostic.
Alternatively, if the payload is end-to-end encrypted at the
application layer, the DetNet nodes should not have any need to
inspect the payload itself, and thus the DetNet implementation can
be data-agnostic.
Related attacks Related attacks
Encryption can be used to mitigate recon attacks (Section 3.2.7). Encryption can be used to mitigate recon attacks (Section 3.2.7).
However, for a DetNet network to give differentiated quality of 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
attack the attacker may also be able to track individual flows to attack the attacker may also be able to track individual flows to
learn more about the system. learn more about the system.
skipping to change at page 19, line 30 skipping to change at page 19, line 47
Any compute time which is required for encryption and decryption Any compute time which is required for encryption and decryption
processing ('crypto') must be included in the flow latency processing ('crypto') must be included in the flow latency
calculations. Thus, crypto algorithms used in a DetNet must have calculations. Thus, crypto algorithms used in a DetNet must have
bounded worst-case execution times, and these values must be used in bounded worst-case execution times, and these values must be used in
the latency calculations. the latency calculations.
Some crypto algorithms are symmetric in encode/decode time (such as Some crypto algorithms are symmetric in encode/decode time (such as
AES) and others are asymmetric (such as public key algorithms). AES) and others are asymmetric (such as public key algorithms).
There are advantages and disadvantages to the use of either type in a There are advantages and disadvantages to the use of either type in a
given DetNet context. given DetNet context. The discussion in this document relates to the
timing implications of crypto for DetNet; it is assumed that
integrity considerations are covered elsewhere in the literature.
Asymmetrical crypto is typically not used in networks on a packet-by- Asymmetrical crypto is typically not used in networks on a packet-by-
packet basis due to its computational cost. For example, if only packet basis due to its computational cost. For example, if only
endpoint checks or checks at a small number of intermediate points endpoint checks or checks at a small number of intermediate points
are required, asymmetric crypto can be used to authenticate are required, asymmetric crypto can be used to authenticate
distribution or exchange of a secret symmetric crypto key; a distribution or exchange of a secret symmetric crypto key; a
successful check based on that key will provide traffic origin successful check based on that key will provide traffic origin
verification, as long as the key is kept secret by the participants. verification, as long as the key is kept secret by the participants.
TLS and IKE (for IPsec) are examples of this for endpoint checks. TLS and IKE (for IPsec) are examples of this for endpoint checks.
skipping to change at page 20, line 33 skipping to change at page 21, line 9
Related attacks Related attacks
These mechanisms can be used to mitigate various attacks on the These mechanisms can be used to mitigate various attacks on the
control plane, as described in Section 3.2.6, Section 3.2.8 and control plane, as described in Section 3.2.6, Section 3.2.8 and
Section 3.2.5. Section 3.2.5.
5.7. Dynamic Performance Analytics 5.7. Dynamic Performance Analytics
Description Description
Information about the network performance can be gathered in real- The expectation is that the network will have a way to monitor to
time in order to detect anomalies and unusual behavior that may be detect if timing guarantees are not being met, and a way to alert
the symptom of a security attack. The gathered information can be the control plane in that event. Information about the network
based, for example, on per-flow counters, bandwidth measurement, performance can be gathered in real-time in order to detect
and monitoring of packet arrival times. Unusual behavior or anomalies and unusual behavior that may be the symptom of a
security attack. The gathered information can be based, for
example, on per-flow counters, bandwidth measurement, and
monitoring of packet arrival times. Unusual behavior or
potentially malicious nodes can be reported to a management potentially malicious nodes can be reported to a management
system, or can be used as a trigger for taking corrective actions. system, or can be used as a trigger for taking corrective actions.
The information can be tracked by DetNet end systems and transit The information can be tracked by DetNet end systems and transit
nodes, and exported to a management system, for example using nodes, and exported to a management system, for example using
NETCONF. NETCONF.
Related attacks Related attacks
Performance analytics can be used to mitigate various attacks, Performance analytics can be used to mitigate various attacks,
including the ones described in Section 3.2.1 (Delay Attack), including the ones described in Section 3.2.1 (Delay Attack),
Section 3.2.3 (Resource Segmentation Attack), and Section 3.2.8 Section 3.2.3 (Resource Segmentation Attack), and Section 3.2.8
(Time Sync Attack). (Time Sync Attack).
For example, in the case of data plane delay attacks, one possible For example, in the case of data plane delay attacks, one possible
mitigation is to timestamp the data at the source, and timestamp mitigation is to timestamp the data at the source, and timestamp
it again at the destination, and if the resulting latency exceeds it again at the destination, and if the resulting latency exceeds
the promised bound, discard that data and warn the operator (and/ the promised bound, discard that data and warn the operator (and/
or enter a fail-safe mode). or enter a fail-safe mode). Note that DetNet specifies packet
sequence numbering, however it does not specify use of packet
timestamps, although they may be used by the underlying transport
(for example TSN) to provide the service.
5.8. Mitigation Summary 5.8. Mitigation Summary
The following table maps the attacks of Section 3 to the impacts of The following table maps the attacks of Section 3 to the impacts of
Section 4, and to the mitigations of the current section. Each row Section 4, and to the mitigations of the current section. Each row
specifies an attack, the impact of this attack if it is successfully specifies an attack, the impact of this attack if it is successfully
implemented, and possible mitigation methods. implemented, and possible mitigation methods.
Editor's note: Is this tabular summary of the above information
useful or necessary in this draft? If we opt to maintain the tables
then the WG needs to validate them for completeness and correctness
after all other draft comments have been addressed.
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Attack | Impact | Mitigations | | Attack | Impact | Mitigations |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Delay Attack |-Non-deterministic |-Path redundancy | |Delay Attack |-Non-deterministic |-Path redundancy |
| | delay |-Performance | | | delay |-Performance |
| |-Data disruption | analytics | | |-Data disruption | analytics |
| |-Increased resource | | | |-Increased resource | |
| | consumption | | | | consumption | |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Reconnaissance |-Enabler for other |-Encryption | |Reconnaissance |-Enabler for other |-Encryption |
skipping to change at page 24, line 14 skipping to change at page 24, line 51
(i.e. one heretofore unknown on the network) could be used to exploit (i.e. one heretofore unknown on the network) could be used to exploit
the need to consider such packets (as opposed to rejecting them out the need to consider such packets (as opposed to rejecting them out
of hand as one would do if one did not have to consider introduction of hand as one would do if one did not have to consider introduction
of a new device). of a new device).
Similarly if the network was designed to support runtime replacement Similarly if the network was designed to support runtime replacement
of a clock device, then presence (or apparent presence) and thus of a clock device, then presence (or apparent presence) and thus
consideration of packets from a new such device could affect the consideration of packets from a new such device could affect the
network, or the time sync of the network, for example by initiating a network, or the time sync of the network, for example by initiating a
new Best Master Clock selection process. Thus attacks on time sync new Best Master Clock selection process. Thus attacks on time sync
should be considered when designing hot swap type functionality. should be considered when designing hot swap type functionality (see
[RFC7384]).
6.1.4. Data Flow Information Models 6.1.4. Data Flow Information Models
Data Flow Information Models specific to DetNet networks are to be Data Flow Information Models specific to DetNet networks are
specified by DetNet. Thus they are "new" and thus potentially specified by DetNet, and thus are 'new' and thus potentially present
present a new attack surface. Does the threat take advantage of any a new attack surface.
aspect of our new Data Flow Info Models?
This is TBD, thus there are no specific entries in our table, however
that does not imply that there could be no relevant attacks.
6.1.5. L2 and L3 Integration 6.1.5. L2 and L3 Integration
A DetNet network 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-PW, and Ethernet.
There are no specific entries in our table, however that does not There are no specific entries in our table, however that does not
imply that there could be no relevant attacks related to L2,L3 imply that there could be no relevant attacks related to L2,L3
integration. integration.
skipping to change at page 25, line 49 skipping to change at page 26, line 31
be opened. be opened.
For example an Inter-Segment or Control plane attack such as Path For example an Inter-Segment or Control 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.
6.1.9. Deterministic vs Best-Effort Traffic 6.1.9. Deterministic vs Best-Effort Traffic
Most of the themes described in this document address OT (reserved)
streams - this item is intended to address issues related to IT
traffic on a DetNet.
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
mitigations will need to be established. The fact that the IT mitigations will need to be established. The fact that the IT
traffic on a DetNet is limited to a corporate controlled network traffic on a DetNet is limited to a corporate controlled network
makes this a less difficult problem compared to being exposed to the makes this a less difficult problem compared to being exposed to the
open Internet, however this aspect of DetNet security should not be open Internet, however this aspect of DetNet security should not be
underestimated. underestimated.
Most of the themes described in this document address OT (reserved)
streams - this item is intended to address issues related to IT
traffic on a DetNet.
An Inter-segment attack can flood the network with IT-type traffic An Inter-segment attack can flood the network with IT-type traffic
with the intent of disrupting handling of IT traffic, and/or the goal with the intent of disrupting handling of IT traffic, and/or the goal
of interfering with OT traffic. Presumably if the stream reservation of interfering with OT traffic. Presumably if the stream reservation
and isolation of the DetNet is well-designed (better-designed than and isolation of the DetNet is well-designed (better-designed than
the attack) then interference with OT traffic should not result from the attack) then interference with OT traffic should not result from
an attack that floods the network with IT traffic. 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.
skipping to change at page 26, line 45 skipping to change at page 27, line 27
deterministic flows. deterministic 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.
6.1.11. Unused Reserved Bandwidth 6.1.11. Unused Reserved Bandwidth
If bandwidth reservations are made for a stream but the associated If bandwidth reservations are made for a stream but the associated
bandwidth is not used at any point in time, that bandwidth is made bandwidth is not used at any point in time, that bandwidth is made
available on the network for best-effort traffic. If the owner of available on the network for best-effort traffic. However, note that
the reserved stream then starts transmitting again, the bandwidth is security considerations for best-effort traffic on a DetNet network
no longer available for best-effort traffic, on a moment-to-moment is out of scope of the present document, provided that such an attack
basis. (Such "temporarily available" bandwidth is not available for does not affect performance for DetNet OT traffic.
time-sensitive traffic, which must have its own reservation).
An Inter-segment attack could flood the network with IT traffic,
interfering with the intended IT traffic.
A Flow Modification or Spoofing or Control Packet Modification or
Injection attack could cause extra bandwidth to be reserved by a new
or existing stream, thus making it unavailable for use by best-effort
traffic.
6.1.12. Interoperability 6.1.12. Interoperability
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each promoting device diversity and potentially higher numbers of each
device manufactured. Does the threat take advantage of differences device manufactured.
in implementation of "interoperable" products made by different
vendors?
This is TBD, thus there are no specific entries in our table, however Given that the DetNet specifications are unambiguously written and
that does not imply that there could be no relevant attacks. that the implementations are accurate, then this should not in and of
itself cause a security concern; however, in the real world, it could
be. The network operator can mitigate this through sufficient
interoperability testing.
6.1.13. Cost Reductions 6.1.13. Cost Reductions
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting higher numbers of each device manufactured, promoting cost promoting higher numbers of each device manufactured, promoting cost
reduction and cost competition among vendors. Does the threat take reduction and cost competition among vendors. Such "low cost"
advantage of "low cost" HW or SW components or other "cost-related hardware or software components might present security concerns.
shortcuts" that might be present in devices?
This is TBD, thus there are no specific entries in our table, however Network operators can mitigate such concerns through sufficient
that does not imply that there could be no relevant attacks. product testing.
6.1.14. Insufficiently Secure Devices 6.1.14. Insufficiently Secure Devices
The DetNet network specifications are intended to enable an ecosystem The DetNet network specifications are intended to enable an ecosystem
in which multiple vendors can create interoperable products, thus in which multiple vendors can create interoperable products, thus
promoting device diversity and potentially higher numbers of each promoting device diversity and potentially higher numbers of each
device manufactured. Does the threat attack "naivete" of SW, for device manufactured. Software that was originally designed for
example SW that was not designed to be sufficiently secure (or secure operation in isolated OT networks (and thus may not have been
at all) but is deployed on a DetNet network that is intended to be designed to be sufficiently secure, or secure at all) but is then
highly secure? (For example IoT exploits like the Mirai video-camera deployed on a DetNet network that is intended to be highly secure may
botnet ([MIRAI]). present an attack surface. (For example IoT exploits like the Mirai
video-camera botnet ([MIRAI]).
This is TBD, thus there are no specific entries in our table, however The DetNet network operator may need to take specific actions to
that does not imply that there could be no relevant attacks. protect such devices.
6.1.15. DetNet Network Size 6.1.15. DetNet Network Size
DetNet networks range in size from very small, e.g. inside a single DetNet networks range in size from very small, e.g. inside a single
industrial machine, to very large, for example a Utility Grid network industrial machine, to very large, for example a Utility Grid network
spanning a whole country. 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,
Similarly Path Manipulation, Path Choice and Time Sync attacks seem presenting a larger attack surface. Similarly Path Manipulation,
more likely relevant to large networks. Path Choice and Time Sync attacks seem more likely relevant to large
networks.
6.1.16. Multiple Hops 6.1.16. 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, perhaps like the
skipping to change at page 30, line 5 skipping to change at page 30, line 34
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.
6.1.21. Symmetrical Path Delays 6.1.21. 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 differ. Delay attacks can cause path delays to materially differ between
paths.
Time Sync attacks can corrupt the system's time reference, resulting Time Sync attacks can corrupt the system's time reference, resulting
in differing path delays (with respect to the "correct" time in path delays that may be perceived to be different (with respect to
reference). the "correct" time reference) even if they are not materially
different.
6.1.22. Reliability and Availability 6.1.22. 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.
skipping to change at page 31, line 11 skipping to change at page 31, line 39
This is TBD, thus there are no specific entries in our table, however This is TBD, thus there are no specific entries in our table, however
that does not imply that there could be no relevant attacks. that does not imply that there could be no relevant attacks.
6.2. Attack Types by Use Case Common Theme 6.2. Attack Types by Use Case Common Theme
The following table lists the attacks of Section 3, assigning a The following table lists the attacks of Section 3, assigning a
number to each type of attack. That number is then used as a short number to each type of attack. That number is then used as a short
form identifier for the attack in Figure 5. form identifier for the attack in Figure 5.
Editor's note: Is this tabular summary of the above information
useful or necessary in this draft? If we opt to maintain the tables
then the WG needs to validate them for completeness and correctness
after all other draft comments have been addressed.
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| | 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 |
+--+----------------------------------------+----------------------+ +--+----------------------------------------+----------------------+
| 4|Replication: Increased attack surface | Section 3.2.4.1 | | 4|Replication: Increased attack surface | Section 3.2.4.1 |
skipping to change at page 35, line 7 skipping to change at page 35, line 50
with VPNs running through networks with other VPNs, it is well known with VPNs running through networks with other VPNs, it is well known
how to secure the network for that. However for a DetNet we have the how to secure the network for that. However for a DetNet we have the
additional subtlety that any possible interaction of one packet with additional subtlety that any possible interaction of one packet with
another can have a potentially deleterious effect on the time another can have a potentially deleterious effect on the time
properties of the flows. So the network must provide sufficient properties of the flows. So the network must provide sufficient
isolation between flows, for example by protecting the forwarding isolation between flows, for example by protecting the forwarding
bandwidth and related resources so that they are available to detnet bandwidth and related resources so that they are available to detnet
traffic, by whatever means are appropriate for that network's data traffic, by whatever means are appropriate for that network's data
plane. plane.
In a VPN, bandwidth is generally guaranteed over a period of time,
whereas in DetNet it is not aggregated over time. This implies that
any VPN-type protection mechanism must also maintain the DetNet
timing constraints.
7.2. MPLS 7.2. MPLS
An MPLS network carrying DetNet traffic is expected to be a "well- An MPLS network carrying DetNet traffic is expected to be a "well-
managed" network. Given that this is the case, it is difficult for managed" network. Given that this is the case, it is difficult for
an attacker to pass a raw MPLS encoded packet into a network because an attacker to pass a raw MPLS encoded packet into a network because
operators have considerable experience at excluding such packets at operators have considerable experience at excluding such packets at
the network boundaries, as well as excluding MPLS packets being the network boundaries, as well as excluding MPLS packets being
inserted through the use of a tunnel. inserted through the use of a tunnel.
MPLS security is discussed extensively in [RFC5920] ("Security MPLS security is discussed extensively in [RFC5920] ("Security
 End of changes. 41 change blocks. 
101 lines changed or deleted 131 lines changed or added

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