draft-ietf-detnet-security-02.txt   draft-ietf-detnet-security-03.txt 
Internet Engineering Task Force T. Mizrahi Internet Engineering Task Force T. Mizrahi
Internet-Draft MARVELL Internet-Draft HUAWEI
Intended status: Informational E. Grossman, Ed. Intended status: Informational E. Grossman, Ed.
Expires: October 25, 2018 DOLBY Expires: April 19, 2019 DOLBY
A. Hacker A. Hacker
MISTIQ MISTIQ
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
J. Dowdell J. Dowdell
Airbus Defence and Space Airbus Defence and Space
H. Austad H. Austad
Cisco Systems Cisco Systems
K. Stanton K. Stanton
INTEL INTEL
N. Finn N. Finn
HUAWEI HUAWEI
April 23, 2018 October 16, 2018
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-02 draft-ietf-detnet-security-03
Abstract Abstract
A deterministic network is one that can carry data flows for real- A deterministic network is one that can carry data flows for real-
time applications with extremely low data loss rates and bounded time applications with extremely low data loss rates and bounded
latency. Deterministic networks have been successfully deployed in latency. Deterministic networks have been successfully deployed in
real-time operational technology (OT) applications for some years real-time operational technology (OT) applications for some years
(for example [ARINC664P7]). However, such networks are typically (for example [ARINC664P7]). However, such networks are typically
isolated from external access, and thus the security threat from isolated from external access, and thus the security threat from
external attackers is low. IETF Deterministic Networking (DetNet) external attackers is low. IETF Deterministic Networking (DetNet)
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2018. This Internet-Draft will expire on April 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 4, line 14 skipping to change at page 4, line 14
6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 24 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 24
6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 24 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 24
6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 24 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 24
6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 25 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 25
6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 25 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 25
6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 25 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 25
6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 26 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 26
6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 26 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 26
6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 27 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 27
6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 27 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 27
6.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 27 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 27
6.1.21. Reliability and Availability . . . . . . . . . . . . 27 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 27
6.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 28 6.1.22. Reliability and Availability . . . . . . . . . . . . 28
6.1.23. Security Measures . . . . . . . . . . . . . . . . . . 28 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 28
6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 28
6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 28 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 28
7. Appendix A: DetNet Draft Security-Related Statements . . . . 30 6.3. Security Considerations for OAM Traffic . . . . . . . . . 31
7. Appendix A: DetNet Draft Security-Related Statements . . . . 31
7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 31 7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 31
7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 31 7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 31
7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 31 7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 32
7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 32 7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 32
7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 32 7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 32
7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 32 7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 33
7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 32 7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 33
7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 33 7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 33
7.4.1. (Utility Networks) Security Current Practices and 7.4.1. (Utility Networks) Security Current Practices and
Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 33 Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 33
7.4.2. (Utility Networks) Security Trends in Utility 7.4.2. (Utility Networks) Security Trends in Utility
Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 34 Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 35
7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 36 7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 36
7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 36 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 37
7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 36 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 37
7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 37 7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Informative References . . . . . . . . . . . . . . . . . . . 37 10. Informative References . . . . . . . . . . . . . . . . . . . 38
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 because many of the use cases which are enabled by DetNet
[I-D.ietf-detnet-use-cases] include control of physical devices [I-D.ietf-detnet-use-cases] include control of physical devices
(power grid components, industrial controls, building controls) which (power grid components, industrial controls, building controls) which
can have high operational costs for failure, and present potentially can have high operational costs for failure, and present potentially
attractive targets for cyber-attackers. attractive targets for cyber-attackers.
skipping to change at page 27, line 31 skipping to change at page 27, line 31
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 Control plane (as described in the Level of Service Attacks on the Control plane (as described in the Level of Service
theme) and Delay and Time attacks (as described in the Bounded theme) and Delay and Time attacks (as described in the Bounded
Latency theme) both apply here. Latency theme) both apply here.
6.1.20. Symmetrical Path Delays 6.1.20. Bounded Jitter (Latency Variation)
DetNet is expected to provide bounded jitter (packet to packet
latency variation).
Delay attacks can cause packets to vary in their arrival times,
resulting in packet to packet latency variation, thereby violating
the jitter specification.
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 differ.
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 differing path delays (with respect to the "correct" time
reference). reference).
6.1.21. 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.
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 our table we have marked every
attack. Since every DetNet depends to a greater or lesser degree on attack. Since every DetNet depends to a greater or lesser degree on
reliability and availability, this essentially means that all reliability and availability, this essentially means that all
networks have to mitigate all attacks, which to a greater or lesser networks have to mitigate all attacks, which to a greater or lesser
degree defeats the purpose of associating attacks with use cases. It degree defeats the purpose of associating attacks with use cases. It
also underscores the difficulty of designing "extremely high also underscores the difficulty of designing "extremely high
reliability" networks. I hope that in future drafts we can say reliability" networks. I hope that in future drafts we can say
something more useful here. something more useful here.
6.1.22. Redundant Paths 6.1.23. 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.
Control plane attacks can also interfere with the configuration of Control plane attacks can also interfere with the configuration of
redundant paths. redundant paths.
6.1.23. Security Measures 6.1.24. 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 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
skipping to change at page 30, line 36 skipping to change at page 30, line 36
|DetNet Network Size | +| | | | | +| +| | | | +| |DetNet Network Size | +| | | | | +| +| | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Multiple Hops | +| +| | | | +| +| | | | +| |Multiple Hops | +| +| | | | +| +| | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Level of Service | | | | | | | | +| +| +| | |Level of Service | | | | | | | | +| +| +| |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Bounded Latency | +| | | | | | | | | | +| |Bounded Latency | +| | | | | | | | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Low Latency | +| | | | | | | +| +| +| +| |Low Latency | +| | | | | | | +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Bounded Jitter | +| | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Symmetric Path Delays | +| | | | | | | | | | +| |Symmetric Path Delays | +| | | | | | | | | | +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +| |Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +|
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Redundant Paths | | | | +| +| | | +| +| | | |Redundant Paths | | | | +| +| | | +| +| | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
|Security Measures | | | | | | | | | | | | |Security Measures | | | | | | | | | | | |
+----------------------------+--+--+--+--+--+--+--+--+--+--+--+ +----------------------------+--+--+--+--+--+--+--+--+--+--+--+
Figure 5: Mapping Between Themes and Attacks Figure 5: Mapping Between Themes and Attacks
6.3. Security Considerations for OAM Traffic
This section considers DetNet-specific security considerations for
packet traffic that is generated and transmitted over a DetNet as
part of OAM (Operations, Administration and Maintenance). For
purposes of this discussion, OAM traffic falls into one of two basic
types:
o OAM traffic generated by the network itself. The additional
bandwidth required for such packets is added by the network
administration, presumably transparent to the customer. Security
considerations for such traffic are not DetNet-specific (apart
from such traffic being subject to the same DetNet-specific
security considerations as any other DetNet data flow) and are
thus not covered in this document.
o OAM traffic generated by the customer. From a DetNet security
point of view, DetNet security considerations for such traffic are
exactly the same as for any other customer data flows.
Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet
security considerations.
7. Appendix A: DetNet Draft Security-Related Statements 7. Appendix A: DetNet Draft Security-Related Statements
This section collects the various statements in the currently This section collects the various statements in the currently
existing DetNet Working Group drafts. For each draft, the section existing DetNet Working Group drafts. For each draft, the section
name and number of the quoted section is shown. The text shown here name and number of the quoted section is shown. The text shown here
is the work of the original draft authors, quoted verbatim from the is the work of the original draft authors, quoted verbatim from the
drafts. The intention is to explicitly quote all relevant text, not drafts. The intention is to explicitly quote all relevant text, not
to summarize it. to summarize it.
7.1. Architecture (draft 8) 7.1. Architecture (draft 8)
skipping to change at page 37, line 36 skipping to change at page 38, line 19
10. Informative References 10. Informative References
[ARINC664P7] [ARINC664P7]
ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics
Full-Duplex Switched Ethernet Network", 2009. Full-Duplex Switched Ethernet Network", 2009.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-04 (work in progress), October 2017. detnet-architecture-08 (work in progress), September 2018.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-15 (work in progress), April 2018. ietf-detnet-use-cases-18 (work in progress), September
2018.
[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.
skipping to change at page 38, line 21 skipping to change at page 39, line 8
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Marvell Huawei Network.IO Innovation Lab
Email: talmi@marvell.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. 22 change blocks. 
27 lines changed or deleted 64 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/