draft-ietf-detnet-security-04.txt		draft-ietf-detnet-security-05.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: September 3, 2019 DOLBY		Expires: March 1, 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		Cisco Systems
	K. Stanton		K. Stanton
	INTEL		INTEL
	N. Finn		N. Finn
	HUAWEI		HUAWEI
	March 2, 2019		August 29, 2019
	Deterministic Networking (DetNet) Security Considerations		Deterministic Networking (DetNet) Security Considerations
	draft-ietf-detnet-security-04		draft-ietf-detnet-security-05
	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 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	of a corporate network) potentially bringing the OT network into		of a corporate network) potentially bringing the OT network into
	contact with Information Technology (IT) traffic and security threats		contact with Information Technology (IT) traffic and security threats
	that lie outside of a tightly controlled and bounded area (such as		that lie outside of a tightly controlled and bounded area (such as
	the internals of an aircraft). These DetNet technologies have not		the internals of an aircraft). These DetNet technologies have not
	previously been deployed together on a wide area IP-based network,		previously been deployed together on a wide area IP-based network,
	and thus can present security considerations that may be new to IP-		and thus can present security considerations that may be new to IP-
	based wide area network designers. This draft, intended for use by		based wide area network designers. This draft, intended for use by
	DetNet network designers, provides insight into these security		DetNet network designers, provides insight into these security
	considerations. In addition, this draft collects all security-		considerations. In addition, this draft collects all security-
	related statements from the various DetNet drafts (Architecture, Use		related statements from the various DetNet drafts (Architecture, Use
	Cases, etc) into a single location Section 7.		Cases, etc) into a 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 September 3, 2019.		This Internet-Draft will expire on March 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . 7		3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 8
	3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7		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 . . . . . . . . . . . . . . . . . . . . . 8		3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 9
	3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . 9		3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 10
	3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9		3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 10
	4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10		4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 11
	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 . . . . . . . . . . . . . 16
	4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16		4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16
	5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 16		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 . . . . . . . . . . . . . . . 17		5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17
	5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18		5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18
	5.4.1. Encryption Considerations for DetNet . . . . . . . . 18		5.4.1. Encryption Considerations for DetNet . . . . . . . . 18
	5.5. Control and Signaling Message Protection . . . . . . . . 19		5.5. Control and Signaling Message Protection . . . . . . . . 19
	5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 19		5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 19
	5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 20		5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 20
	6. Association of Attacks to Use Cases . . . . . . . . . . . . . 21		6. Association of Attacks to Use Cases . . . . . . . . . . . . . 21
	6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 21		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 . . . . . . . . . . . . . . . 22
	6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 22		6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 22
	6.1.4. Data Flow Information Models . . . . . . . . . . . . 23		6.1.4. Data Flow Information Models . . . . . . . . . . . . 23
	6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 23		6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 23
	6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 23		6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 24
	6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 24		6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 24
	6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 24		6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 24
	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 . . . . . . . . . . . . . . . . . 25
	6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 25		6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 26
	6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 26		6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 26
	6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 26		6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 26
	6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 26		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 . . . . . . . . . . . . . . . . . . . . 27
	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 . . . . . . . . . . . . . . . . . . . 28
	6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 28		6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 28
	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 . . . . . . . . . . . . 29
	6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 29		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 . . . . . . . . . . 30
	6.3. Security Considerations for OAM Traffic . . . . . . . . . 32		6.3. Security Considerations for OAM Traffic . . . . . . . . . 33
	7. Appendix A: DetNet Draft Security-Related Statements . . . . 32		7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33
	7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 33		7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 33		7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 33		7.3. TSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 34		8. Appendix A: DetNet Draft Security-Related Statements . . . . 34
	7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 34		8.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 34
	7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 34		8.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 34
	7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 34		8.1.2. Security Considerations (sec 7) . . . . . . . . . . . 35
	7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 35		8.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 36
	7.4.1. (Utility Networks) Security Current Practices and		8.2.1. Security Considerations (sec 7) . . . . . . . . . . . 36
	Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 35		8.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 36
	7.4.2. (Utility Networks) Security Trends in Utility		8.3.1. Security Considerations (sec 5) . . . . . . . . . . . 36
	Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 36		8.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 37
	7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 38		8.4.1. (Utility Networks) Security Current Practices and
	7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 38		Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 37
	7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 39		8.4.2. (Utility Networks) Security Trends in Utility
	7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 39		Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 38
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39		8.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 40
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 39		8.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 40
	10. Informative References . . . . . . . . . . . . . . . . . . . 39		8.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40		8.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 41
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
			10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
			11. Informative References . . . . . . . . . . . . . . . . . . . 41
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
	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 [RFC8578]
	[I-D.ietf-detnet-use-cases] include control of physical devices		include control of physical devices (power grid components,
	(power grid components, industrial controls, building controls) which		industrial controls, building controls) which can have high
	can have high operational costs for failure, and present potentially		operational costs for failure, and present potentially attractive
	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). Security considerations for OT
	networks is not a new area, and there are many OT networks today that		networks is not a new area, and there are many OT networks today that
	are connected to wide area networks or the Internet; this draft		are connected to wide area networks or the Internet; this draft
	focuses on the issues that are specific to the DetNet technologies		focuses on the issues that are specific to the DetNet technologies
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 41 ¶
	o Provide explicit routes for DetNet flows that do not rapidly		o Provide explicit routes for DetNet flows that do not rapidly
	change with the network topology		change with the network topology
	o Distribute data from DetNet flow packets over time and/or space to		o Distribute data from DetNet flow packets over time and/or space to
	ensure delivery of each packet's data' in spite of the loss of a		ensure delivery of each packet's data' in spite of the loss of a
	path		path
	This draft includes sections on threat modeling and analysis, threat		This draft includes sections on threat modeling and analysis, threat
	impact and mitigation, and the association of attacks with use cases		impact and mitigation, and the association of attacks with use cases
	based on the Use Case Common Themes section of the DetNet Use Cases		based on the Use Case Common Themes section of the DetNet Use Cases
	draft [I-D.ietf-detnet-use-cases].		draft [RFC8578].
	This draft also provides context for the DetNet security		This draft also provides context for the DetNet security
	considerations by collecting into one place Section 7 the various		considerations by collecting into one place Section 8 the various
	remarks about security from the various DetNet drafts (Use Cases,		remarks about security from the various DetNet drafts (Use Cases,
	Architecture, etc). This text is duplicated here primarily because		Architecture, etc). This text is duplicated here primarily because
	the DetNet working group has elected not to produce a Requirements		the DetNet working group has elected not to produce a Requirements
	draft and thus collectively these statements are as close as we have		draft and thus collectively these statements are as close as we have
	to "DetNet Security Requirements".		to "DetNet Security Requirements".
	2. Abbreviations		2. Abbreviations
	IT Information technology (the application of computers to		IT Information technology (the application of computers to
	store, study, retrieve, transmit, and manipulate data or information,		store, study, retrieve, transmit, and manipulate data or information,
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 33 ¶
	DREAD Compares and prioritizes risk represented by these threat		DREAD Compares and prioritizes risk represented by these threat
	categories: Damage potential, Reproducibility, Exploitability, how		categories: Damage potential, Reproducibility, Exploitability, how
	many Affected users, Discoverability.		many Affected users, Discoverability.
	PTP Precision Time Protocol [IEEE1588]		PTP Precision Time Protocol [IEEE1588]
	3. Security Threats		3. Security Threats
	This section presents a threat model, and analyzes the possible		This section presents a threat model, and analyzes the possible
	threats in a DetNet-enabled network.		threats in a DetNet-enabled network. The threats considered in this
			section are independent of any specific technologies used to
			implement the DetNet; Section 7) considers attacks that are
			associated with the DetNet technologies encompassed by
			[I-D.ietf-detnet-data-plane-framework].
	We distinguish control plane threats from data plane threats. The		We distinguish control plane threats from data plane threats. The
	attack surface may be the same, but the types of attacks as well as		attack surface may be the same, but the types of attacks as well as
	the motivation behind them, are different. For example, a delay		the motivation behind them, are different. For example, a delay
	attack is more relevant to data plane than to control plane. There		attack is more relevant to data plane than to control plane. There
	is also a difference in terms of security solutions: the way you		is also a difference in terms of security solutions: the way you
	secure the data plane is often different than the way you secure the		secure the data plane is often different than the way you secure the
	control plane.		control plane.
	3.1. Threat Model		3.1. Threat Model
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 23 ¶
	be measured in loss of confidentiality, integrity or availability of		be measured in loss of confidentiality, integrity or availability of
	information.		information.
	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 [I-D.ietf-detnet-use-cases]. Each of the use cases in the		detail in [RFC8578]. Each of the use cases in the DetNet Use Cases
	DetNet Use Cases draft is represented in the table below, including		draft is represented in the table below, including Pro Audio,
	Pro Audio, Electrical Utilities, Industrial M2M (split into two		Electrical Utilities, Industrial M2M (split into two areas, M2M Data
	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, Affect on a single organization, and
	affect on multiple organizations. Recovery outlines how long it		affect on multiple organizations. Recovery outlines how long it
	would take for an affected use case to get back to its pre-failure		would take for an affected use case to get back to its pre-failure
	skipping to change at page 21, line 36 ¶		skipping to change at page 21, line 45 ¶
	Figure 3: Mapping Attacks to Impact and Mitigations		Figure 3: Mapping Attacks to Impact and Mitigations
	6. Association of Attacks to Use Cases		6. Association of Attacks to Use Cases
	Different attacks can have different impact and/or mitigation		Different attacks can have different impact and/or mitigation
	depending on the use case, so we would like to make this association		depending on the use case, so we would like to make this association
	in our analysis. However since there is a potentially unbounded list		in our analysis. However since there is a potentially unbounded list
	of use cases, we categorize the attacks with respect to the common		of use cases, we categorize the attacks with respect to the common
	themes of the use cases as identified in the Use Case Common Themes		themes of the use cases as identified in the Use Case Common Themes
	section of the DetNet Use Cases draft [I-D.ietf-detnet-use-cases].		section of the DetNet Use Cases draft [RFC8578].
	See also Figure 2 for a mapping of the impact of attacks per use case		See also Figure 2 for a mapping of the impact of attacks per use case
	by industry.		by industry.
	6.1. Use Cases by Common Themes		6.1. Use Cases by Common Themes
	In this section we review each theme and discuss the attacks that are		In this section we review each theme and discuss the attacks that are
	applicable to that theme, as well as anything specific about the		applicable to that theme, as well as anything specific about the
	impact and mitigations for that attack with respect to that theme.		impact and mitigations for that attack with respect to that theme.
	The table Figure 5 then provides a summary of the attacks that are		The table Figure 5 then provides a summary of the attacks that are
	skipping to change at page 32, line 44 ¶		skipping to change at page 33, line 28 ¶
	security considerations as any other DetNet data flow) and are		security considerations as any other DetNet data flow) and are
	thus not covered in this document.		thus not covered in this document.
	o OAM traffic generated by the customer. From a DetNet security		o OAM traffic generated by the customer. From a DetNet security
	point of view, DetNet security considerations for such traffic are		point of view, DetNet security considerations for such traffic are
	exactly the same as for any other customer data flows.		exactly the same as for any other customer data flows.
	Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet		Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet
	security considerations.		security considerations.
	7. Appendix A: DetNet Draft Security-Related Statements		7. DetNet Technology-Specific Threats
			Section 3 described threats which are independent of the DetNet
			implementation. This section considers threats related to the
			specific technologies referenced in
			[I-D.ietf-detnet-data-plane-framework] which have not already been
			enumerated in Section 3.
			As in this document in general, this section only enumerates security
			aspects which are unique to providing the specific quality of service
			aspects of DetNet, which are primarily to deliver data flows with
			extremely low packet loss rates and bounded end-to-end delivery
			latency. The primary considerations for the data plane specifically
			are to maintain integrity of data and delivery of the associated
			DetNet service traversing the DetNet network.
			As noted in [I-D.ietf-detnet-architecture], DetNet operates at the IP
			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
			Time-Sensitive Networking (TSN) ([I-D.ietf-detnet-ip-over-tsn]).
			Application flows can be protected through whatever means is provided
			by the underlying technology. For example, technology-specific
			encryption may be used, such as that provided by IPSec [RFC4301] for
			IP flows and/or by an underlying sub-net using MACSec
			[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.
			Sections below discuss threats specific to IP, MPLS, and TSN in more
			detail.
			7.1. IP
			The IP protocol has a long history of security considerations and
			architectural protection mechanisms. From a data plane perspective
			DetNet does not add or modify any IP header information, and its use
			as a DetNet Data Plane does not introduce any new security issues
			that were not there before, apart from those already described in the
			data-plane-independent threats section Section 3.
			Thus the security considerations for a DetNet based on an IP data
			plane are purely inherited from the rich IP Security literature and
			code/application base, and the data-plane-independent section of this
			document.
			7.2. MPLS
			Editor's Note: To Be Written.
			7.3. TSN
			Editor's Note: To Be Written.
			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
	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)		8.1. Architecture (draft 8)
	7.1.1. Fault Mitigation (sec 4.5)		8.1.1. Fault Mitigation (sec 4.5)
	One key to building robust real-time systems is to reduce the		One key to building robust real-time systems is to reduce the
	infinite variety of possible failures to a number that can be		infinite variety of possible failures to a number that can be
	analyzed with reasonable confidence. DetNet aids in the process by		analyzed with reasonable confidence. DetNet aids in the process by
	providing filters and policers to detect DetNet packets received on		providing filters and policers to detect DetNet packets received on
	the wrong interface, or at the wrong time, or in too great a volume,		the wrong interface, or at the wrong time, or in too great a volume,
	and to then take actions such as discarding the offending packet,		and to then take actions such as discarding the offending packet,
	shutting down the offending DetNet flow, or shutting down the		shutting down the offending DetNet flow, or shutting down the
	offending interface.		offending interface.
	skipping to change at page 33, line 32 ¶		skipping to change at page 35, line 21 ¶
	There exist techniques, at present and/or in various stages of		There exist techniques, at present and/or in various stages of
	standardization, that can perform these fault mitigation tasks that		standardization, that can perform these fault mitigation tasks that
	deliver a high probability that misbehaving systems will have zero		deliver a high probability that misbehaving systems will have zero
	impact on well-behaved DetNet flows, except of course, for the		impact on well-behaved DetNet flows, except of course, for the
	receiving interface(s) immediately downstream of the misbehaving		receiving interface(s) immediately downstream of the misbehaving
	device. Examples of such techniques include traffic policing		device. Examples of such techniques include traffic policing
	functions (e.g. [RFC2475]) and separating flows into per-flow rate-		functions (e.g. [RFC2475]) and separating flows into per-flow rate-
	limited queues.		limited queues.
	7.1.2. Security Considerations (sec 7)		8.1.2. Security Considerations (sec 7)
	Security in the context of Deterministic Networking has an added		Security in the context of Deterministic Networking has an added
	dimension; the time of delivery of a packet can be just as important		dimension; the time of delivery of a packet can be just as important
	as the contents of the packet, itself. A man-in-the-middle attack,		as the contents of the packet, itself. A man-in-the-middle attack,
	for example, can impose, and then systematically adjust, additional		for example, can impose, and then systematically adjust, additional
	delays into a link, and thus disrupt or subvert a real-time		delays into a link, and thus disrupt or subvert a real-time
	application without having to crack any encryption methods employed.		application without having to crack any encryption methods employed.
	See [RFC7384] for an exploration of this issue in a related context.		See [RFC7384] for an exploration of this issue in a related context.
	Furthermore, in a control system where millions of dollars of		Furthermore, in a control system where millions of dollars of
	skipping to change at page 34, line 11 ¶		skipping to change at page 36, line 5 ¶
	accidental or intentional.		accidental or intentional.
	Security must cover:		Security must cover:
	o Protection of the signaling protocol		o Protection of the signaling protocol
	o Authentication and authorization of the controlling nodes		o Authentication and authorization of the controlling nodes
	o Identification and shaping of the flows		o Identification and shaping of the flows
	7.2. Data Plane Alternatives (draft 4)		8.2. Data Plane Alternatives (draft 4)
	7.2.1. Security Considerations (sec 7)		8.2.1. Security Considerations (sec 7)
	This document does not add any new security considerations beyond		This document does not add any new security considerations beyond
	what the referenced technologies already have.		what the referenced technologies already have.
	7.3. Problem Statement (draft 5)		8.3. Problem Statement (draft 5)
	7.3.1. Security Considerations (sec 5)		8.3.1. Security Considerations (sec 5)
	Security in the context of Deterministic Networking has an added		Security in the context of Deterministic Networking has an added
	dimension; the time of delivery of a packet can be just as important		dimension; the time of delivery of a packet can be just as important
	as the contents of the packet, itself. A man-in-the-middle attack,		as the contents of the packet, itself. A man-in-the-middle attack,
	for example, can impose, and then systematically adjust, additional		for example, can impose, and then systematically adjust, additional
	delays into a link, and thus disrupt or subvert a real-time		delays into a link, and thus disrupt or subvert a real-time
	application without having to crack any encryption methods employed.		application without having to crack any encryption methods employed.
	See [RFC7384] for an exploration of this issue in a related context.		See [RFC7384] for an exploration of this issue in a related context.
	Typical control networks today rely on complete physical isolation to		Typical control networks today rely on complete physical isolation to
	skipping to change at page 35, line 4 ¶		skipping to change at page 36, line 46 ¶
	individual flows which have no clue whether the resources are used by		individual flows which have no clue whether the resources are used by
	other flows at other times.		other flows at other times.
	Security must cover:		Security must cover:
	o Protection of the signaling protocol		o Protection of the signaling protocol
	o Authentication and authorization of the controlling nodes		o Authentication and authorization of the controlling nodes
	o Identification and shaping of the flows		o Identification and shaping of the flows
	o Isolation of flows from leakage and other influences from any		o Isolation of flows from leakage and other influences from any
	activity sharing physical resources		activity sharing physical resources
	7.4. Use Cases (draft 11)		8.4. Use Cases (draft 11)
	7.4.1. (Utility Networks) Security Current Practices and Limitations		8.4.1. (Utility Networks) Security Current Practices and Limitations
	(sec 3.2.1)		(sec 3.2.1)
	Grid monitoring and control devices are already targets for cyber		Grid monitoring and control devices are already targets for cyber
	attacks, and legacy telecommunications protocols have many intrinsic		attacks, and legacy telecommunications protocols have many intrinsic
	network-related vulnerabilities. For example, DNP3, Modbus,		network-related vulnerabilities. For example, DNP3, Modbus,
	PROFIBUS/PROFINET, and other protocols are designed around a common		PROFIBUS/PROFINET, and other protocols are designed around a common
	paradigm of request and respond. Each protocol is designed for a		paradigm of request and respond. Each protocol is designed for a
	master device such as an HMI (Human Machine Interface) system to send		master device such as an HMI (Human Machine Interface) system to send
	commands to subordinate slave devices to retrieve data (reading		commands to subordinate slave devices to retrieve data (reading
	inputs) or control (writing to outputs). Because many of these		inputs) or control (writing to outputs). Because many of these
	skipping to change at page 36, line 27 ¶		skipping to change at page 38, line 23 ¶
	between IT an OT networks, make network-based attacks very		between IT an OT networks, make network-based attacks very
	feasible.		feasible.
	o Simple injection of malicious protocol commands provides control		o Simple injection of malicious protocol commands provides control
	over the target process. Altering legitimate protocol traffic can		over the target process. Altering legitimate protocol traffic can
	also alter information about a process and disrupt the legitimate		also alter information about a process and disrupt the legitimate
	controls that are in place over that process. A man-in-the-middle		controls that are in place over that process. A man-in-the-middle
	attack could provide both control over a process and		attack could provide both control over a process and
	misrepresentation of data back to operator consoles.		misrepresentation of data back to operator consoles.
	7.4.2. (Utility Networks) Security Trends in Utility Networks (sec		8.4.2. (Utility Networks) Security Trends in Utility Networks (sec
	3.3.3)		3.3.3)
	Although advanced telecommunications networks can assist in		Although advanced telecommunications networks can assist in
	transforming the energy industry by playing a critical role in		transforming the energy industry by playing a critical role in
	maintaining high levels of reliability, performance, and		maintaining high levels of reliability, performance, and
	manageability, they also introduce the need for an integrated		manageability, they also introduce the need for an integrated
	security infrastructure. Many of the technologies being deployed to		security infrastructure. Many of the technologies being deployed to
	support smart grid projects such as smart meters and sensors can		support smart grid projects such as smart meters and sensors can
	increase the vulnerability of the grid to attack. Top security		increase the vulnerability of the grid to attack. Top security
	concerns for utilities migrating to an intelligent smart grid		concerns for utilities migrating to an intelligent smart grid
	skipping to change at page 38, line 33 ¶		skipping to change at page 40, line 30 ¶
	Digital Factory where workflows and protocols cross zones, segments,		Digital Factory where workflows and protocols cross zones, segments,
	and entities. IEC 62443 (ISA99) defines security for IACS, typically		and entities. IEC 62443 (ISA99) defines security for IACS, typically
	for installations in other critical infrastructure such as oil and		for installations in other critical infrastructure such as oil and
	gas.		gas.
	Availability and integrity are the most important security objectives		Availability and integrity are the most important security objectives
	for the lower layers of such networks; confidentiality and privacy		for the lower layers of such networks; confidentiality and privacy
	are relevant if customer or market data is involved, typically		are relevant if customer or market data is involved, typically
	handled by higher layers.		handled by higher layers.
	7.4.3. (BAS) Security Considerations (sec 4.2.4)		8.4.3. (BAS) Security Considerations (sec 4.2.4)
	When BAS field networks were developed it was assumed that the field		When BAS field networks were developed it was assumed that the field
	networks would always be physically isolated from external networks		networks would always be physically isolated from external networks
	and therefore security was not a concern. In today's world many BASs		and therefore security was not a concern. In today's world many BASs
	are managed remotely and are thus connected to shared IP networks and		are managed remotely and are thus connected to shared IP networks and
	so security is definitely a concern, yet security features are not		so security is definitely a concern, yet security features are not
	available in the majority of BAS field network deployments .		available in the majority of BAS field network deployments .
	The management network, being an IP-based network, has the protocols		The management network, being an IP-based network, has the protocols
	available to enable network security, but in practice many BAS		available to enable network security, but in practice many BAS
	systems do not implement even the available security features such as		systems do not implement even the available security features such as
	device authentication or encryption for data in transit.		device authentication or encryption for data in transit.
	7.4.4. (6TiSCH) Security Considerations (sec 5.3.3)		8.4.4. (6TiSCH) Security Considerations (sec 5.3.3)
	On top of the classical requirements for protection of control		On top of the classical requirements for protection of control
	signaling, it must be noted that 6TiSCH networks operate on limited		signaling, it must be noted that 6TiSCH networks operate on limited
	resources that can be depleted rapidly in a DoS attack on the system,		resources that can be depleted rapidly in a DoS attack on the system,
	for instance by placing a rogue device in the network, or by		for instance by placing a rogue device in the network, or by
	obtaining management control and setting up unexpected additional		obtaining management control and setting up unexpected additional
	paths.		paths.
	7.4.5. (Cellular radio) Security Considerations (sec 6.1.5)		8.4.5. (Cellular radio) Security Considerations (sec 6.1.5)
	Establishing time-sensitive streams in the network entails reserving		Establishing time-sensitive streams in the network entails reserving
	networking resources for long periods of time. It is important that		networking resources for long periods of time. It is important that
	these reservation requests be authenticated to prevent malicious		these reservation requests be authenticated to prevent malicious
	reservation attempts from hostile nodes (or accidental		reservation attempts from hostile nodes (or accidental
	misconfiguration). This is particularly important in the case where		misconfiguration). This is particularly important in the case where
	the reservation requests span administrative domains. Furthermore,		the reservation requests span administrative domains. Furthermore,
	the reservation information itself should be digitally signed to		the reservation information itself should be digitally signed to
	reduce the risk of a legitimate node pushing a stale or hostile		reduce the risk of a legitimate node pushing a stale or hostile
	configuration into another networking node.		configuration into another networking node.
	Note: This is considered important for the security policy of the		Note: This is considered important for the security policy of the
	network, but does not affect the core DetNet architecture and design.		network, but does not affect the core DetNet architecture and design.
	7.4.6. (Industrial M2M) Communication Today (sec 7.2)		8.4.6. (Industrial M2M) Communication Today (sec 7.2)
	Industrial network scenarios require advanced security solutions.		Industrial network scenarios require advanced security solutions.
	Many of the current industrial production networks are physically		Many of the current industrial production networks are physically
	separated. Preventing critical flows from be leaked outside a domain		separated. Preventing critical flows from be leaked outside a domain
	is handled today by filtering policies that are typically enforced in		is handled today by filtering policies that are typically enforced in
	firewalls.		firewalls.
	8. IANA Considerations		9. IANA Considerations
	This memo includes no requests from IANA.		This memo includes no requests from IANA.
	9. Security Considerations		10. Security Considerations
	The security considerations of DetNet networks are presented		The security considerations of DetNet networks are presented
	throughout this document.		throughout this document.
	10. 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]		[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-11 (work in progress), February 2019.		detnet-architecture-13 (work in progress), May 2019.
	[I-D.ietf-detnet-use-cases]		[I-D.ietf-detnet-data-plane-framework]
	Grossman, E., "Deterministic Networking Use Cases", draft-		Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
	ietf-detnet-use-cases-20 (work in progress), December		Bryant, S., and J. Korhonen, "DetNet Data Plane
	2018.		Framework", draft-ietf-detnet-data-plane-framework-01
			(work in progress), July 2019.
			[I-D.ietf-detnet-ip]
			Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
			Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
			draft-ietf-detnet-ip-01 (work in progress), July 2019.
			[I-D.ietf-detnet-ip-over-tsn]
			Varga, B., Farkas, J., Malis, A., Bryant, S., and J.
			Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time
			Sensitive Networking (TSN)", draft-ietf-detnet-ip-over-
			tsn-00 (work in progress), May 2019.
			[I-D.ietf-detnet-mpls]
			Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
			Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
			draft-ietf-detnet-mpls-01 (work in progress), July 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]
			IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
			Security (MACsec)", 2018,
			<https://ieeexplore.ieee.org/document/8585421>.
	[MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/		[MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/
	hacked-cameras-dvrs-powered-todays-massive-internet-		hacked-cameras-dvrs-powered-todays-massive-internet-
	outage/", 2016.		outage/", 2016.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[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>.
			[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
			Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
			December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[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",
			RFC 8578, DOI 10.17487/RFC8578, May 2019,
			<https://www.rfc-editor.org/info/rfc8578>.
	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
End of changes. 49 change blocks.
	82 lines changed or deleted		173 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/