draft-ietf-detnet-security-05.txt   draft-ietf-detnet-security-06.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: March 1, 2020 DOLBY Expires: May 4, 2020 DOLBY
A. Hacker A. Hacker
MISTIQ MISTIQ
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
J. Dowdell J. Dowdell
Airbus Defence and Space Airbus Defence and Space
H. Austad H. Austad
Cisco Systems SINTEF Digital
K. Stanton
INTEL
N. Finn N. Finn
HUAWEI HUAWEI
August 29, 2019 November 1, 2019
Deterministic Networking (DetNet) Security Considerations Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-05 draft-ietf-detnet-security-06
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 However, such networks are typically isolated from external access,
isolated from external access, and thus the security threat from and thus the security threat from external attackers is low. IETF
external attackers is low. IETF Deterministic Networking (DetNet) Deterministic Networking (DetNet) specifies a set of technologies
specifies a set of technologies that enable creation of deterministic that enable creation of deterministic networks on IP-based networks
networks on IP-based networks of potentially wide area (on the scale of potentially wide area (on the scale of a corporate network)
of a corporate network) potentially bringing the OT network into potentially bringing the OT network into contact with Information
contact with Information Technology (IT) traffic and security threats Technology (IT) traffic and security threats that lie outside of a
that lie outside of a tightly controlled and bounded area (such as tightly controlled and bounded area (such as the internals of an
the internals of an aircraft). These DetNet technologies have not aircraft). These DetNet technologies have not previously been
previously been deployed together on a wide area IP-based network, deployed together on a wide area IP-based network, and thus can
and thus can present security considerations that may be new to IP- present security considerations that may be new to IP-based wide area
based wide area network designers. This draft, intended for use by network designers. This draft, intended for use by DetNet network
DetNet network designers, provides insight into these security designers, provides insight into these security considerations. In
considerations. In addition, this draft collects all security- addition, this draft collects all security-related statements from
related statements from the various DetNet drafts (Architecture, Use the various DetNet drafts (Architecture, Use Cases, etc) into a
Cases, etc) into a single location Section 8. single location Section 8.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 1, 2020. This Internet-Draft will expire on May 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7 3.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 7 3.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 7
3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7 3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7
3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 8 3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7
3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 8 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 8
3.2.4. Packet Replication and Elimination . . . . . . . . . 8 3.2.4. Packet Replication and Elimination . . . . . . . . . 8
3.2.4.1. Replication: Increased Attack Surface . . . . . . 8 3.2.4.1. Replication: Increased Attack Surface . . . . . . 8
3.2.4.2. Replication-related Header Manipulation . . . . . 8 3.2.4.2. Replication-related Header Manipulation . . . . . 8
3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 9 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 9
3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 9 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 9
3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9 3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9
3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9 3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9
3.2.6.1. Control or Signaling Packet Modification . . . . 9 3.2.6.1. Control or Signaling Packet Modification . . . . 9
3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9
skipping to change at page 3, line 9 skipping to change at page 3, line 4
3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 8 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 8
3.2.4. Packet Replication and Elimination . . . . . . . . . 8 3.2.4. Packet Replication and Elimination . . . . . . . . . 8
3.2.4.1. Replication: Increased Attack Surface . . . . . . 8 3.2.4.1. Replication: Increased Attack Surface . . . . . . 8
3.2.4.2. Replication-related Header Manipulation . . . . . 8 3.2.4.2. Replication-related Header Manipulation . . . . . 8
3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 9 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 9
3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 9 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 9
3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9 3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9
3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9 3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9
3.2.6.1. Control or Signaling Packet Modification . . . . 9 3.2.6.1. Control or Signaling Packet Modification . . . . 9
3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9
3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9
3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9
3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 10 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9
3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 10 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 10
4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . 15 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . 16 4.4. Replication and Elimination . . . . . . . . . . . . . . . 15
4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 16 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 16
4.4.2. Header Manipulation at Elimination Bridges . . . . . 16 4.4.2. Header Manipulation at Elimination Bridges . . . . . 16
4.5. Control or Signaling Packet Modification . . . . . . . . 16 4.5. Control or Signaling Packet Modification . . . . . . . . 16
4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16
4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16
4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16
4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16
5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 17 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 16
5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17
5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17
5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 18
5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 18
5.4.1. Encryption Considerations for DetNet . . . . . . . . 18 5.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. Control and Signaling Message Protection . . . . . . . . 19 5.5.1. Encryption Considerations for DetNet . . . . . . . . 19
5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 19 5.6. Control and Signaling Message Protection . . . . . . . . 20
5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 20 5.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 20
6. Association of Attacks to Use Cases . . . . . . . . . . . . . 21 5.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 21
6. Association of Attacks to Use Cases . . . . . . . . . . . . . 22
6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 22 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 22
6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22
6.1.2. Central Administration . . . . . . . . . . . . . . . 22 6.1.2. Central Administration . . . . . . . . . . . . . . . 23
6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 22 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 23
6.1.4. Data Flow Information Models . . . . . . . . . . . . 23 6.1.4. Data Flow Information Models . . . . . . . . . . . . 24
6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 23 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 24
6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 24 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 24
6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 24 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 25
6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 24 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 25
6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25
6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 25 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 26
6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 26 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 26
6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 26 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 27
6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 26 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 27
6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 27 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 27
6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27
6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 27 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 28
6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28
6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 28 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 29
6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 28 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 29
6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29
6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29
6.1.22. Reliability and Availability . . . . . . . . . . . . 29 6.1.22. Reliability and Availability . . . . . . . . . . . . 30
6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 30 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 30
6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30
6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 30 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 31
6.3. Security Considerations for OAM Traffic . . . . . . . . . 33 6.3. Security Considerations for OAM Traffic . . . . . . . . . 33
7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33 7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33
7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3. TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.3. TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Appendix A: DetNet Draft Security-Related Statements . . . . 34 8. Appendix A: DetNet Draft Security-Related Statements . . . . 35
8.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 34 8.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 35
8.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 34 8.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 35
8.1.2. Security Considerations (sec 7) . . . . . . . . . . . 35 8.1.2. Security Considerations (sec 7) . . . . . . . . . . . 36
8.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 36 8.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 36
8.2.1. Security Considerations (sec 7) . . . . . . . . . . . 36 8.2.1. Security Considerations (sec 7) . . . . . . . . . . . 36
8.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 36 8.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 37
8.3.1. Security Considerations (sec 5) . . . . . . . . . . . 36 8.3.1. Security Considerations (sec 5) . . . . . . . . . . . 37
8.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 37 8.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 37
8.4.1. (Utility Networks) Security Current Practices and 8.4.1. (Utility Networks) Security Current Practices and
Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 37 Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 37
8.4.2. (Utility Networks) Security Trends in Utility 8.4.2. (Utility Networks) Security Trends in Utility
Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 38 Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 39
8.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 40 8.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 41
8.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 40 8.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 41
8.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 41 8.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 41
8.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 41 8.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11. Informative References . . . . . . . . . . . . . . . . . . . 41 11. Informative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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.
This situation is even more acute given that one of the goals of This situation is even more acute given that one of the goals of
DetNet is to provide a "converged network", i.e. one that includes DetNet is to provide a "converged network", i.e. one that includes
both IT traffic and OT traffic, thus exposing potentially sensitive both IT traffic and OT traffic, thus exposing potentially sensitive
OT devices to attack in ways that were not previously common (usually OT devices to attack in ways that were not previously common (usually
because they were under a separate control system or otherwise because they were under a separate control system or otherwise
isolated from the IT network). Security considerations for OT isolated from the IT network, for example [ARINC664P7]). Security
networks is not a new area, and there are many OT networks today that considerations for OT networks is not a new area, and there are many
are connected to wide area networks or the Internet; this draft OT networks today that are connected to wide area networks or the
focuses on the issues that are specific to the DetNet technologies Internet; this draft focuses on the issues that are specific to the
and use cases. DetNet technologies and use cases.
The DetNet technologies include ways to: The DetNet technologies include ways to:
o Reserve data plane resources for DetNet flows in some or all of o Reserve data plane resources for DetNet flows in some or all of
the intermediate nodes (e.g. bridges or routers) along the path of the intermediate nodes (e.g. bridges or routers) along the path of
the flow the flow
o Provide explicit routes for DetNet flows that do not rapidly o Provide explicit routes for DetNet flows that do not rapidly
change with the network topology change with the network topology
skipping to change at page 7, line 17 skipping to change at page 7, line 6
authentication keys. External attackers, on the other hand, do authentication keys. External attackers, on the other hand, do
not have the keys and have access only to the encrypted or not have the keys and have access only to the encrypted or
authenticated traffic. authenticated traffic.
o Man in the Middle (MITM) vs. packet injector: MITM attackers are o Man in the Middle (MITM) vs. packet injector: MITM attackers are
located in a position that allows interception and modification of located in a position that allows interception and modification of
in-flight protocol packets, whereas a traffic injector can only in-flight protocol packets, whereas a traffic injector can only
attack by generating protocol packets. attack by generating protocol packets.
Care has also been taken to adhere to Section 5 of [RFC3552], both Care has also been taken to adhere to Section 5 of [RFC3552], both
with respect to what attacks are considered out-of-scope for this with respect to which attacks are considered out-of-scope for this
document, but also what is considered to be the most common threats document, but also which are considered to be the most common threats
(explored furhter in Section 3.2. Most of the direct threats to (explored furhter in Section 3.2. Most of the direct threats to
DetNet are Active attacks, but it is highly suggested that DetNet DetNet are Active attacks, but it is highly suggested that DetNet
application developers take appropriate measures to protect the application developers take appropriate measures to protect the
content of the streams from passive attacks. content of the streams from passive attacks.
DetNet-Service, one of the service scenarios described in DetNet-Service, one of the service scenarios described in
[I-D.varga-detnet-service-model], is the case where a service [I-D.varga-detnet-service-model], is the case where a service
connects DetNet networking islands, i.e. two or more otherwise connects DetNet networking islands, i.e. two or more otherwise
independent DetNet network domains are connected via a link that is independent DetNet network domains are connected via a link that is
not intrinsically part of either network. This implies that there not intrinsically part of either network. This implies that there
skipping to change at page 9, line 41 skipping to change at page 9, line 37
An attacker can maliciously inject control packets in order to An attacker can maliciously inject control packets in order to
disrupt or manipulate the DetNet path/resource allocation. disrupt or manipulate the DetNet path/resource allocation.
3.2.7. Scheduling or Shaping 3.2.7. Scheduling or Shaping
3.2.7.1. Reconnaissance 3.2.7.1. Reconnaissance
A passive eavesdropper can 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, and their schedules. The gathered flows, their bandwidths, their schedules, or other temporal
information can later be used to invoke other attacks on some or all properties. The gathered information can later be used to invoke
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 draft we assume they are encrypted involved, for purposes of this draft we assume they are encrypted
and/or integrity-protected from external attackers. and/or integrity-protected from external attackers.
3.2.8. Time Synchronization Mechanisms 3.2.8. Time Synchronization Mechanisms
An attacker can use any of the attacks described in [RFC7384] to An attacker can use any of the attacks described in [RFC7384] to
skipping to change at page 11, line 34 skipping to change at page 11, line 27
draft is represented in the table below, including Pro Audio, draft is represented in the table below, including Pro Audio,
Electrical Utilities, Industrial M2M (split into two areas, M2M Data Electrical Utilities, Industrial M2M (split into two areas, M2M Data
Gathering and M2M Control Loop), and others. Gathering and M2M Control Loop), and others.
Components of Impact (left column) include Criticality of Failure, Components of Impact (left column) include Criticality of Failure,
Effects of Failure, Recovery, and DetNet Functional Dependence. Effects of Failure, Recovery, and DetNet Functional Dependence.
Criticality of failure summarizes the seriousness of the impact. The Criticality of failure summarizes the seriousness of the impact. The
impact of a resulting failure can affect many different metrics that impact of a resulting failure can affect many different metrics that
vary greatly in scope and severity. In order to reduce the number of vary greatly in scope and severity. In order to reduce the number of
variables, only the following were included: Financial, Health and variables, only the following were included: Financial, Health and
Safety, People well being, Affect on a single organization, and Safety, People well being (People WB), Affect on a single
affect on multiple organizations. Recovery outlines how long it organization, and affect on multiple organizations. Recovery
would take for an affected use case to get back to its pre-failure outlines how long it would take for an affected use case to get back
state (Recovery time objective, RTO), and how much of the original to its pre-failure state (Recovery time objective, RTO), and how much
service would be lost in between the time of service failure and of the original service would be lost in between the time of service
recovery to original state (Recovery Point Objective, RPO). DetNet failure and recovery to original state (Recovery Point Objective,
dependence maps how much the following DetNet service objectives RPO). DetNet dependence maps how much the following DetNet service
contribute to impact of failure: Time dependency, data integrity, objectives contribute to impact of failure: Time dependency, data
source node integrity, availability, latency/jitter. integrity, source node integrity, availability, latency/jitter.
The scale of the Impact mappings is low, medium, and high. In some The scale of the Impact mappings is low, medium, and high. In some
use cases there may be a multitude of specific applications in which use cases there may be a multitude of specific applications in which
DetNet is used. For simplicity this section attempts to average the DetNet is used. For simplicity this section attempts to average the
varied impacts of different applications. This section does not varied impacts of different applications. This section does not
address the overall risk of a certain impact which would require the address the overall risk of a certain impact which would require the
likelihood of a failure happening. likelihood of a failure happening.
In practice any such ratings will vary from case to case; the ratings In practice any such ratings will vary from case to case; the ratings
shown here are given as examples. shown here are given as examples.
skipping to change at page 17, line 18 skipping to change at page 17, line 12
mitigate the attacks described in Section 3. These mitigations mitigate the attacks described in Section 3. These mitigations
should be viewed as a toolset that includes several different and should be viewed as a toolset that includes several different and
diverse tools. Each application or system will typically use a diverse tools. Each application or system will typically use a
subset of these tools, based on a system-specific threat analysis. subset of these tools, based on a system-specific threat analysis.
5.1. Path Redundancy 5.1. Path Redundancy
Description Description
A DetNet flow that can be forwarded simultaneously over multiple A DetNet flow that can be forwarded simultaneously over multiple
paths. Path replication and elimination paths. Path replication and elimination [RFC8655] provides
[I-D.ietf-detnet-architecture] provides resiliency to dropped or resiliency to dropped or delayed packets. This redundancy
delayed packets. This redundancy improves the robustness to improves the robustness to failures and to man-in-the-middle
failures and to man-in-the-middle 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. Section 3.2.2, Section 3.2.3, and Section 3.2.8.
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. Integrity protection can be used on the data plane attacks. Integrity protection can be used on the data plane
header, to prevent its modification and tampering. Integrity header, to prevent its modification and tampering. Integrity
protection in the control plane is discussed in Section 5.5. protection in the control plane is discussed in Section 5.6.
Related attacks Packet Sequence Number Integrity Considerations
The use of PREOF in a DetNet implementation implies the use of a
sequence number for each packet. There is a trust relationship
between the device that adds the sequence number and the device
that removes the sequence number. The sequence number may be end-
to-end source to destination, or may be added/deleted by network
edge devices. The adder and remover(s) have the trust
relationship because they are the ones that ensure that the
sequence numbers are not modifiable. Between those two points,
there may or may not be replication and elimination functions.
The elimination functions must be able to see the sequence
numbers. Therefore any encryption that is done between adders and
removers must not obscure the sequence number. If the sequence
removers and the eliminators are in the same physical device, it
may be possible to obscure the sequence number, however that is a
layer violation, and is not recommended practice.
Related attacks
Integrity protection mitigates attacks related to modification and Integrity protection mitigates attacks related to modification and
tampering, including the attacks described in Section 3.2.2 and tampering, including the attacks described in Section 3.2.2 and
Section 3.2.4. Section 3.2.4.
5.3. DetNet Node Authentication 5.3. DetNet Node Authentication
Description Description
Source authentication verifies the authenticity of DetNet sources, Source authentication verifies the authenticity of DetNet sources,
allowing to mitigate spoofing attacks. Note that while integrity enabling mitigation of spoofing attacks. Note that while
protection (Section 5.2) prevents intermediate nodes from integrity protection (Section 5.2) prevents intermediate nodes
modifying information, authentication verfies the source of the from modifying information, authentication can provide traffic
information. origin verification, i.e. to verify that each packet in a DetNet
flow is from a trusted source. Authentication may be implemented
as part of ingress filtering, for example.
Related attacks Related attacks
DetNet node authentication is used to mitigate attacks related to DetNet node authentication is used to mitigate attacks related to
spoofing, including the attacks of Section 3.2.2, and spoofing, including the attacks of Section 3.2.2, and
Section 3.2.4. Section 3.2.4.
5.4. Encryption 5.4. Dummy Traffic Insertion
Description Description
DetNet flows can be forwarded in encrypted form. With some queueing methods such as [IEEE802.1Qch-2017] it is
possible to introduce dummy traffic in order to regularize the
timing of packet transmission.
Related attacks Related attacks
Removing distinctive temporal properties of individual packets or
flows can be used to mitigate against reconnaissance attacks
Section 3.2.7.
5.5. Encryption
Description
DetNet flows can be forwarded in encrypted form at the DetNet
layer. 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
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.
Encryption can also provide traffic origin verification, i.e. to 5.5.1. Encryption Considerations for DetNet
verify that each packet in a DetNet flow is from a trusted source,
for example as part of ingress filtering.
5.4.1. Encryption Considerations for DetNet
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
skipping to change at page 19, line 29 skipping to change at page 20, line 9
In either case, origin verification also requires replay detection as In either case, origin verification also requires replay detection as
part of the security protocol to prevent an attacker from recording part of the security protocol to prevent an attacker from recording
and resending traffic, e.g., as a denial of service attack on flow and resending traffic, e.g., as a denial of service attack on flow
forwarding resources. forwarding resources.
If crypto keys are to be regenerated over the duration of the flow If crypto keys are to be regenerated over the duration of the flow
then the time required to accomplish this must be accounted for in then the time required to accomplish this must be accounted for in
the latency calculations. the latency calculations.
5.5. Control and Signaling Message Protection 5.6. Control and Signaling Message Protection
Description Description
Control and sigaling messages can be protected using Control and sigaling messages can be protected using
authentication and integrity protection mechanisms. authentication and integrity protection mechanisms.
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.6. Dynamic Performance Analytics 5.7. Dynamic Performance Analytics
Description Description
Information about the network performance can be gathered in real- Information about the network performance can be gathered in real-
time in order to detect anomalies and unusual behavior that may be time in order to detect anomalies and unusual behavior that may be
the symptom of a security attack. The gathered information can be the symptom of a security attack. The gathered information can be
based, for example, on per-flow counters, bandwidth measurement, based, for example, on per-flow counters, bandwidth measurement,
and monitoring of packet arrival times. Unusual behavior or 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.
skipping to change at page 20, line 22 skipping to change at page 21, line 5
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).
5.7. 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.
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| 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 |
| | attacks | | | | attacks |-Dummy traffic |
| | | insertion |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|DetNet Flow Modificat-|-Increased resource |-Path redundancy | |DetNet Flow Modificat-|-Increased resource |-Path redundancy |
|ion or Spoofing | consumption |-Integrity protection| |ion or Spoofing | consumption |-Integrity protection|
| |-Data disruption |-DetNet Node | | |-Data disruption |-DetNet Node |
| | | authentication | | | | authentication |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
|Inter-Segment Attack |-Increased resource |-Path redundancy | |Inter-Segment Attack |-Increased resource |-Path redundancy |
| | consumption |-Performance | | | consumption |-Performance |
| |-Data disruption | analytics | | |-Data disruption | analytics |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
skipping to change at page 33, line 44 skipping to change at page 33, line 47
enumerated in Section 3. enumerated in Section 3.
As in this document in general, this section only enumerates security As in this document in general, this section only enumerates security
aspects which are unique to providing the specific quality of service aspects which are unique to providing the specific quality of service
aspects of DetNet, which are primarily to deliver data flows with aspects of DetNet, which are primarily to deliver data flows with
extremely low packet loss rates and bounded end-to-end delivery extremely low packet loss rates and bounded end-to-end delivery
latency. The primary considerations for the data plane specifically latency. The primary considerations for the data plane specifically
are to maintain integrity of data and delivery of the associated are to maintain integrity of data and delivery of the associated
DetNet service traversing the DetNet network. DetNet service traversing the DetNet network.
As noted in [I-D.ietf-detnet-architecture], DetNet operates at the IP As noted in [RFC8655], DetNet operates at the IP layer
layer ([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 is provided Application flows can be protected through whatever means is provided
by the underlying technology. For example, technology-specific by the underlying technology. For example, technology-specific
encryption may be used, such as that provided by IPSec [RFC4301] for encryption may be used, such as that provided by IPSec [RFC4301] for
IP flows and/or by an underlying sub-net using MACSec IP flows and/or by an underlying sub-net using MACSec
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
Sections below discuss threats specific to IP, MPLS, and TSN in more Sections below discuss threats specific to IP, MPLS, and TSN in more
skipping to change at page 34, line 26 skipping to change at page 34, line 30
that were not there before, apart from those already described in the that were not there before, apart from those already described in the
data-plane-independent threats section Section 3. data-plane-independent threats section Section 3.
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.
7.2. MPLS 7.2. MPLS
Editor's Note: To Be Written. An MPLS network carrying DetNet traffic is expected to be a "well-
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
operators have considerable experience at excluding such packets at
the network boundaries, as well as excluding MPLS packets being
inserted through the use of a tunnel.
MPLS security is discussed extensively in [RFC5920] ("Security
Framework for MPLS and GMPLS Networks") to which the reader is
referred.
[RFC6941] builds on [RFC5920] by providing additional security
considerations that are applicable to the MPLS-TP extensions
appropriate to the MPLS Transport Profile [RFC5921], and thus to the
operation of DetNet over some types of MPLS network.
[RFC5921] introduces to MPLS new Operations, Administration, and
Maintenance (OAM) capabilities, a transport-oriented path protection
mechanism, and strong emphasis on static provisioning supported by
network management systems.
The operation of DetNet over an MPLS network is modeled on the
operation of multi-segment pseudowires (MS-PW). Thus for guidance on
securing the DetNet elements of DetNet over MPLS the reader is
referred to the MS-PW security mechanisms as defined in [RFC4447],
[RFC3931], [RFC3985], [RFC6073], and [RFC6478].
Having attended to the conventional aspects of network security it is
necessary to attend to the dynamic aspects. The closest experience
that the IETF has with securing protocols that are sensitive to
manipulation of delay are the two way time transfer protocols (TWTT),
which are NTP [RFC5905] and Precision Time Protocol [IEEE1588]. The
security requirements for these are described in [RFC7384].
One particular problem that has been observed in operational tests of
TWTT protocols is the ability for two closely but not completely
synchronized streams to beat and cause a sudden phase hit to one of
the streams. This can be mitigated by the careful use of a
scheduling system in the underlying packet transport.
Further consideration of protection against dynamic attacks is work
in progress.
7.3. TSN 7.3. TSN
Editor's Note: To Be Written. Editor's Note: To Be Written.
8. Appendix A: DetNet Draft Security-Related Statements 8. Appendix A: DetNet Draft Security-Related Statements
This section collects the various statements in the currently This section collects the various statements in the currently
existing DetNet Working Group drafts. For each draft, the section existing DetNet Working Group drafts. For each draft, the section
name and number of the quoted section is shown. The text shown here name and number of the quoted section is shown. The text shown here
skipping to change at page 41, line 43 skipping to change at page 42, line 33
The security considerations of DetNet networks are presented The security considerations of DetNet networks are presented
throughout this document. throughout this document.
11. Informative References 11. Informative References
[ARINC664P7] [ARINC664P7]
ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics
Full-Duplex Switched Ethernet Network", 2009. Full-Duplex Switched Ethernet Network", 2009.
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-data-plane-framework] [I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane Bryant, S., and J. Korhonen, "DetNet Data Plane
Framework", draft-ietf-detnet-data-plane-framework-01 Framework", draft-ietf-detnet-data-plane-framework-02
(work in progress), July 2019. (work in progress), September 2019.
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
draft-ietf-detnet-ip-01 (work in progress), July 2019. draft-ietf-detnet-ip-03 (work in progress), October 2019.
[I-D.ietf-detnet-ip-over-tsn] [I-D.ietf-detnet-ip-over-tsn]
Varga, B., Farkas, J., Malis, A., Bryant, S., and J. Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet
Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time Data Plane: IP over IEEE 802.1 Time Sensitive Networking
Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- (TSN)", draft-ietf-detnet-ip-over-tsn-01 (work in
tsn-00 (work in progress), May 2019. progress), October 2019.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-01 (work in progress), July 2019. draft-ietf-detnet-mpls-03 (work in progress), October
2019.
[I-D.varga-detnet-service-model] [I-D.varga-detnet-service-model]
Varga, B. and J. Farkas, "DetNet Service Model", draft- Varga, B. and J. Farkas, "DetNet Service Model", draft-
varga-detnet-service-model-02 (work in progress), May varga-detnet-service-model-02 (work in progress), May
2017. 2017.
[IEEE1588] [IEEE1588]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems Version 2", 2008. Control Systems Version 2", 2008.
[IEEE802.1AE-2018] [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.1Qch-2017]
IEEE Standards Association, "IEEE Standard for Local and
metropolitan area networks--Bridges and Bridged Networks--
Amendment 29: Cyclic Queuing and Forwarding", 2017,
<https://ieeexplore.ieee.org/document/7961303>.
[MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/ [MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/
hacked-cameras-dvrs-powered-todays-massive-internet- hacked-cameras-dvrs-powered-todays-massive-internet-
outage/", 2016. outage/", 2016.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<https://www.rfc-editor.org/info/rfc3931>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/info/rfc3985>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<https://www.rfc-editor.org/info/rfc4447>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/info/rfc5921>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073,
DOI 10.17487/RFC6073, January 2011,
<https://www.rfc-editor.org/info/rfc6073>.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", RFC 6478,
DOI 10.17487/RFC6478, May 2012,
<https://www.rfc-editor.org/info/rfc6478>.
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
Security Framework", RFC 6941, DOI 10.17487/RFC6941, April
2013, <https://www.rfc-editor.org/info/rfc6941>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", [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,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
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
skipping to change at page 43, line 41 skipping to change at page 46, line 4
Email: ajhacker@mistiqtech.com Email: ajhacker@mistiqtech.com
URI: http://www.mistiqtech.com URI: http://www.mistiqtech.com
Subir Das Subir Das
Applied Communication Sciences Applied Communication Sciences
150 Mount Airy Road, Basking Ridge 150 Mount Airy Road, Basking Ridge
New Jersey, 07920 New Jersey, 07920
USA USA
Email: sdas@appcomsci.com Email: sdas@appcomsci.com
John Dowdell John Dowdell
Airbus Defence and Space Airbus Defence and Space
Celtic Springs Celtic Springs
Newport NP10 8FZ Newport NP10 8FZ
United Kingdom United Kingdom
Email: john.dowdell.ietf@gmail.com Email: john.dowdell.ietf@gmail.com
Henrik Austad Henrik Austad
Cisco Systems SINTEF Digital
Philip Pedersens vei 1 Klaebuveien 153
Lysaker 1366 Trondheim 7037
Norway Norway
Email: henrik@austad.us Email: henrik@austad.us
Kevin Stanton
Intel
Email: kevin.b.stanton@intel.com
Norman Finn Norman Finn
Huawei Huawei
Email: norman.finn@mail01.huawei.com Email: norman.finn@mail01.huawei.com
 End of changes. 60 change blocks. 
133 lines changed or deleted 259 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/