rfc9055xml2.original.xml		rfc9055.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	.2119.xml">
	<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2629.xml">
	<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3552.xml">
	<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5226.xml">
	<!ENTITY RFC7384 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7384.xml">
	]>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-detnet-secur
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>		ity-16"
	<?rfc strict="yes" ?>		number="9055" ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
	<?rfc toc="yes"?>		category="info"
	<?rfc tocdepth="4"?>		consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" s
	<?rfc symrefs="yes"?>		ortRefs="true"
	<?rfc sortrefs="yes" ?>		version="3">
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>
	<rfc category="info" docName="draft-ietf-detnet-security-16" ipr="trust200902">
	<front>		<front>
	<title abbrev="DetNet Security"> Deterministic Networking (DetNet) Security		<title abbrev="DetNet Security">Deterministic Networking (DetNet) Security C
	Considerations </title>		onsiderations </title>
	<author fullname="Ethan Grossman" initials="E.A." role="editor" surname="Gro		<seriesInfo name="RFC" value="9055"/>
	ssman">		<author fullname="Ethan Grossman" initials="E" role="editor" surname="Grossm
			an">
	<organization abbrev="DOLBY">Dolby Laboratories, Inc.</organization>		<organization abbrev="DOLBY">Dolby Laboratories, Inc.</organization>
	<address>		<address>
	<postal>		<postal>
	<street>1275 Market Street</street>		<street>1275 Market Street</street>
	<city>San Francisco</city>		<city>San Francisco</city>
	<region>CA</region>		<region>CA</region>
	<code>94103</code>		<code>94103</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<phone>+1 415 465 4339</phone>
	<email>ethan@ieee.org</email>		<email>ethan@ieee.org</email>
	<uri>http://www.dolby.com</uri>		<uri>https://www.dolby.com</uri>
	</address>		</address>
	</author>		</author>
	<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">		<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
	<organization abbrev="HUAWEI">Huawei Network.IO Innovation Lab</organizati on>		<organization abbrev="HUAWEI">Huawei</organization>
	<address>		<address>
	<email>tal.mizrahi.phd@gmail.com</email>		<email>tal.mizrahi.phd@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Andrew J. Hacker" initials="A.J." surname="Hacker">		<author fullname="Andrew J. Hacker" initials="A" surname="Hacker">
	<organization abbrev="MISTIQ">MistIQ Technologies, Inc</organization>		<organization abbrev="THOUGHT">Thought LLC</organization>
	<address>		<address>
	<postal>		<postal>
	<street/>		<street/>
	<city>Harrisburg</city>		<city>Harrisburg</city>
	<region>PA</region>		<region>PA</region>
	<code/>		<code/>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>ajhacker@mistiqtech.com</email>		<email>andrew@thought.live</email>
	</address>		</address>
	</author>		</author>
	<date year="2021"/>		<date year="2021" month="June"/>
	<area>Routing</area>		<area>Routing</area>
	<workgroup>Internet Engineering Task Force</workgroup>		<workgroup>Internet Engineering Task Force</workgroup>
	<keyword>DetNet, security</keyword>		<keyword>DetNet</keyword>
			<keyword>security</keyword>
	<abstract>		<abstract>
	<t>A DetNet (deterministic network) provides specific performance guarante		<t>A DetNet (deterministic network) provides specific performance
	es to its data		guarantees to its data flows, such as extremely low data loss rates and
	flows, such as extremely low data loss rates and bounded latency (includ		bounded latency (including bounded latency variation, i.e.,
	ing bounded latency		"jitter"). As a result, securing a DetNet requires that in addition to
	variation, i.e. "jitter"). As a result, securing a DetNet requires that		the best practice security measures taken for any mission-critical
	in addition to the		network, additional security measures may be needed to secure the
	best practice security measures taken for any mission-critical network,		intended operation of these novel service properties.</t>
	additional security		<t> This document addresses DetNet-specific security considerations from
	measures may be needed to secure the intended operation of these novel s		the perspectives of both the DetNet system-level designer and component
	ervice		designer. System considerations include a taxonomy of relevant threats
	properties.</t>		and attacks, and associations of threats versus use cases and service
	<t> This document addresses DetNet-specific security considerations from t		properties. Component-level considerations include ingress filtering and
	he perspectives of		packet arrival-time violation detection.</t>
	both the DetNet system-level designer and component designer. System con		<t>This document also addresses security considerations specific to the
	siderations include		IP and MPLS data plane technologies, thereby complementing the Security
	a taxonomy of relevant threats and attacks, and associations of threats		Considerations sections of those documents.</t>
	versus use cases and
	service properties. Component-level considerations include ingress filte
	ring and packet
	arrival time violation detection.</t>
	<t>This document also addresses security considerations specific to the IP
	and MPLS data plane
	technologies, thereby complementing the Security Considerations sections
	of those
	documents.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="Introduction" title="Introduction">		<section anchor="Introduction" numbered="true" toc="default">
	<t>A deterministic IP network (IETF DetNet, <xref target="RFC8655"/>) can		<name>Introduction</name>
	carry data flows for		<t>A deterministic IP network ("<xref target="RFC8655" format="title"/>" <
	real-time applications with extremely low data loss rates and bounded la		xref
	tency. The bounds on		target="RFC8655" format="default"/>) can carry data flows for real-tim
	latency defined by DetNet (as described in <xref		e applications with
	target="I-D.ietf-detnet-flow-information-model"/>) include both worst		extremely low data loss rates and bounded latency. The bounds on latency
	case latency		defined by DetNet
	(Maximum Latency, Section 5.9.2) and worst case jitter (Maximum Latency		(as described in <xref target="RFC9016" format="default"/>) include both
	Variation, Section		worst-case latency
	5.9.3). Data flows with deterministic properties are well-established fo		(Maximum Latency, <xref target="RFC9016" section="5.9.2"/>) and worst-ca
	r Ethernet networks		se jitter (Maximum
	(see TSN, <xref target="IEEE802.1BA"/>); DetNet brings these capabilitie		Latency Variation, <xref target="RFC9016" section="5.9.3"/>). Data flows
	s to the IP		with deterministic
			properties are well established for Ethernet networks (see Time-Sensitiv
			e Networking (TSN),
			<xref target="IEEE802.1BA" format="default"/>); DetNet brings these ca
			pabilities to the IP
	network.</t>		network.</t>
	<t>Deterministic IP networks have been successfully deployed in real-time Operational		<t>Deterministic IP networks have been successfully deployed in real-time Operational
	Technology (OT) applications for some years, however such networks are t ypically isolated		Technology (OT) applications for some years; however, such networks are typically isolated
	from external access, and thus the security threat from external attacke rs is low. An		from external access, and thus the security threat from external attacke rs is low. An
	example of such an isolated network is a network deployed within an airc raft, which is "air		example of such an isolated network is a network deployed within an airc raft, which is "air
	gapped" from the outside world. DetNet specifies a set of technologies t hat enable creation		gapped" from the outside world. DetNet specifies a set of technologies t hat enable creation
	of deterministic flows on IP-based networks of potentially wide area (on		of deterministic flows on IP-based networks of a potentially wide area (
	the scale of a		on the scale of a
	corporate network), potentially merging OT traffic with best-effort (Inf		corporate network), potentially merging OT traffic with best-effort Info
	ormation Technology,		rmation Technology
	IT) traffic, and placing OT network components into contact with IT netw		(IT) traffic, and placing OT network components into contact with IT net
	ork components,		work components,
	thereby exposing the OT traffic and components to security threats that were not present in		thereby exposing the OT traffic and components to security threats that were not present in
	an isolated OT network. </t>		an isolated OT network. </t>
	<t>These DetNet (OT-type) technologies may not have previously been deploy ed on a wide area		<t>These DetNet (OT-type) technologies may not have previously been deploy ed on a wide area
	IP-based network that also carries IT traffic, and thus can present secu		IP-based network that also carries IT traffic, and thus they can present
	rity considerations		security
	that may be new to IP-based wide area network designers; this document p		considerations that may be new to IP-based wide area network designers;
	rovides insight into		this document
	such system-level security considerations. In addition, designers of Det		provides insight into such system-level security considerations. In addi
	Net components (such		tion, designers of
	as routers) face new security-related challenges in providing DetNet ser		DetNet components (such as routers) face new security-related challenges
	vices, for example		in providing DetNet
	maintaining reliable isolation between traffic flows in an environment w		services, for example, maintaining reliable isolation between traffic fl
	here IT traffic		ows in an
	co-mingles with critical reserved-bandwidth OT traffic; this document al		environment where IT traffic co-mingles with critical reserved-bandwidth
	so examines security		OT traffic; this
	implications internal to DetNet components. </t>		document also examines security implications internal to DetNet componen
	<t>Security is of particularly high importance in DetNet because many of t		ts. </t>
	he use cases which		<t>Security is of particularly high importance in DetNet because many of t
	are enabled by DetNet <xref target="RFC8578"/> include control of physic		he use cases that
	al devices (power		are enabled by DetNet <xref target="RFC8578" format="default"/> include
	grid devices, industrial controls, building controls) which can have hig		control of physical
	h operational costs		devices (power grid devices, industrial controls, building controls, etc
	for failure, and present potentially attractive targets for cyber-attack		.) that can have
	ers. </t>		high operational costs for failure and present potentially attractive ta
			rgets for cyber
			attackers. </t>
	<t>This situation is even more acute given that one of the goals of DetNet is to provide a		<t>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 both IT traffic and OT traff ic, thus exposing		"converged network", i.e., one that includes both IT traffic and OT traf fic, thus exposing
	potentially sensitive OT devices to attack in ways that were not previou sly common (usually		potentially sensitive OT devices to attack in ways that were not previou sly common (usually
	because they were under a separate control system or otherwise isolated from the IT network,		because they were under a separate control system or otherwise isolated from the IT network,
	for example <xref target="ARINC664P7"/>). Security considerations for OT		for example <xref target="ARINC664P7" format="default"/>). Security cons
	networks are not a		iderations for OT
	new area, and there are many OT networks today that are connected to wid		networks are not a new area, and there are many OT networks today that a
	e area networks or		re connected to wide
	the Internet; this document focuses on the issues that are specific to t		area networks or the Internet; this document focuses on the issues that
	he DetNet		are specific to the
	technologies and use cases. </t>		DetNet technologies and use cases. </t>
	<t>Given the above considerations, securing a DetNet starts with a scrupul ously well-designed		<t>Given the above considerations, securing a DetNet starts with a scrupul ously well-designed
	and well-managed engineered network following industry best practices fo r security at both		and well-managed engineered network following industry best practices fo r security at both
	the data plane and controller plane, as well as for any OAM implementati		the data plane and controller plane, as well as for any Operations, Admi
	on; this is the		nistration, and
	assumed starting point for the considerations discussed herein. Such ass		Maintenance (OAM) implementation; this is the assumed starting point for
	umptions also depend		the considerations
	on the network components themselves upholding the security-related prop		discussed herein. Such assumptions also depend on the network components
	erties that are to		themselves
	be assumed by DetNet system-level designers; for example, the assumption		upholding the security-related properties that are to be assumed by DetN
	that network		et system-level
	traffic associated with a given flow can never affect traffic associated		designers; for example, the assumption that network traffic associated w
	with a different		ith a given flow can
	flow is only true if the underlying components make it so. Such properti		never affect traffic associated with a different flow is only true if th
	es, which may		e underlying
	represent new challenges to component designers, are also considered her		components make it so. Such properties, which may represent new challeng
	ein. </t>		es to component
			designers, are also considered herein. </t>
	<t>Starting with a "well-managed network" as noted above enables us to exc		<t>Starting with a "well-managed network", as noted above, enables us to e
	lude some of the		xclude some of the
	more powerful adversary capabilities from the Internet Threat Model of B		more powerful adversary capabilities from the Internet Threat Model of <
	CP 72 (<xref		xref target="BCP72"
	target="RFC3552"/>), such as the ability to arbitrarily drop or delay		format="default"/>, such as the ability to arbitrarily drop or delay a
	any or all traffic.		ny or all traffic.
	Given this reduced attacker capability, we can present security consider ations based on		Given this reduced attacker capability, we can present security consider ations based on
	attacker capabilities that are more directly relevant to a DetNet.</t>		attacker capabilities that are more directly relevant to a DetNet.</t>
			<t>In this context, we view the "conventional" (i.e., non-time-sensitive)
	<t>In this context we view the "traditional" (i.e. non-time-sensitive) net		network design and
	work design and		management aspects of network security as being primarily concerned with
	management aspects of network security as being primarily concerned with		preventing denial
	denial-of service		of service, i.e., they must ensure that DetNet traffic goes where it's s
	prevention, i.e. they must ensure that DetNet traffic goes where it's su		upposed to and that
	pposed to and that
	an external attacker can't inject traffic that disrupts the delivery tim ing assurance of the		an external attacker can't inject traffic that disrupts the delivery tim ing assurance of the
	DetNet. The time-specific aspects of DetNet security presented here take up where those		DetNet. The time-specific aspects of DetNet security presented here take up where those
	"traditional" design and management aspects leave off. </t>		"conventional" design and management aspects leave off. </t>
	<t>However note that "traditional" methods for mitigating (among all the o		<t>However, note that "conventional" methods for mitigating (among all the
	thers) denial-of		others)
	service attack (such as throttling) can only be effectively used in a De		denial-of-service attacks (such as throttling) can only be effectively u
	tNet when their use		sed in a DetNet when
	does not compromise the required time-sensitive or behavioral properties		their use does not compromise the required time-sensitive or behavioral
	required for the OT		properties required
	flows on the network. For example, a "retry" protocol is typically not g		for the OT flows on the network. For example, a "retry" protocol is typi
	oing to be		cally not going to
	compatible with a low-latency (worst-case maximum latency) requirement,		be compatible with a low-latency (worst-case maximum latency) requiremen
	however if in a		t; however, if in a
	specific use case and implementation such a retry protocol is able to me et the timing		specific use case and implementation such a retry protocol is able to me et the timing
	constraints, then it may well be used in that context. Similarly if comm on security		constraints, then it may well be used in that context. Similarly, if com mon security
	protocols such as TLS/DTLS or IPsec are to be used, it must be verified that their		protocols such as TLS/DTLS or IPsec are to be used, it must be verified that their
	implementations are able to meet the timing and behavioral requirements of the		implementations are able to meet the timing and behavioral requirements of the
	time-sensitive network as implemented for the given use case. An example of "behavioral		time-sensitive network as implemented for the given use case. An example of "behavioral
	properties" might be that dropping of more than a specific number of pac kets in a row is not		properties" might be that dropping of more than a specific number of pac kets in a row is not
	acceptable according to the service level agreement.</t>		acceptable according to the service level agreement.</t>
	<t>The exact security requirements for any given DetNet are necessarily sp ecific to the use		<t>The exact security requirements for any given DetNet are necessarily sp ecific to the use
	cases handled by that network. Thus the reader is assumed to be familiar		cases handled by that network. Thus, the reader is assumed to be familia
	with the specific		r with the specific
	security requirements of their use cases, for example those outlined in		security requirements of their use cases, for example, those outlined in
	the DetNet Use Cases		the DetNet Use
	<xref target="RFC8578"/> and the Security Considerations sections of t		Cases <xref target="RFC8578" format="default"/> and the Security Conside
	he DetNet documents		rations sections of
	applicable to the network technologies in use, for example <xref target=		the DetNet documents applicable to the network technologies in use, for
	"RFC8939"/> for an		example, <xref
	IP data plane and <xref target="RFC8964"/> for an MPLS data plane. Reade		target="RFC8939" format="default"/> for an IP data plane and <xref tar
	rs can find a		get="RFC8964"
	general introduction to the DetNet Architecture in <xref target="RFC8655		format="default"/> for an MPLS data plane. Readers can find a general
	"/>, the DetNet Data		introduction to the
	Plane in <xref target="RFC8938"/>, and the Flow Information Model in <xr		DetNet Architecture in <xref target="RFC8655" format="default"/>, the De
	ef		tNet Data Plane in
	target="I-D.ietf-detnet-flow-information-model"/>.</t>		<xref target="RFC8938" format="default"/>, and the Flow Information Mo
	<t>The DetNet technologies include ways to: <list style="symbols">		del in <xref
	<t> Assign data plane resources for DetNet flows in some or all of the		target="RFC9016" format="default"/>.</t>
	intermediate nodes		<t>The DetNet technologies include ways to: </t>
	(routers) along the path of the flow</t>		<ul spacing="normal">
	<t> Provide explicit routes for DetNet flows that do not dynamically c		<li> Assign data plane resources for DetNet flows in some or all of the
	hange with the		intermediate nodes
	network topology in ways that affect the quality of service received		(routers) along the path of the flow</li>
	by the affected		<li> Provide explicit routes for DetNet flows that do not dynamically ch
	flow(s) </t>		ange with the
	<t> Distribute data from DetNet flow packets over time and/or space to		network topology in ways that affect the quality of service received b
	ensure delivery of		y the affected
	the data in each packet in spite of the loss of a path.</t>		flow(s) </li>
	</list>		<li> Distribute data from DetNet flow packets over time and/or space to
	</t>		ensure delivery of
			the data in each packet in spite of the loss of a path</li>
			</ul>
	<t>This document includes sections considering DetNet component design as well as system		<t>This document includes sections considering DetNet component design as well as system
	design. The latter includes a taxonomy and analysis of threats, threat i mpacts and		design. The latter includes a taxonomy and analysis of threats, threat i mpacts and
	mitigations, and an association of attacks with use cases (based on the		mitigations, and an association of attacks with use cases (based on <xre
	Use Case Common		f target="RFC8578"
	Themes section of the DetNet Use Cases <xref target="RFC8578"/>). </t>		sectionFormat="of" section="11"/>). </t>
	<t>This document is based on the premise that there will be a very broad r ange of DetNet		<t>This document is based on the premise that there will be a very broad r ange of DetNet
	applications and use cases, ranging in size and scope from individual in dustrial machines to		applications and use cases, ranging in size and scope from individual in dustrial machines to
	networks that span an entire country (<xref target="RFC8578"/>). Thus no		networks that span an entire country <xref target="RFC8578" format="defa
	single set of		ult"/>. Thus, no
	prescriptions (such as exactly which mitigation should be applied to whi		single set of prescriptions (such as exactly which mitigation should be
	ch segment of a		applied to which
	DetNet) can be applicable to all of them, and indeed any single one that		segment of a DetNet) can be applicable to all of them, and indeed any si
	we might prescribe		ngle one that we
	would inevitably prove impractical for some use case, perhaps one that d		might prescribe would inevitably prove impractical for some use case, pe
	oes not even exist		rhaps one that does
	at the time of this writing. Thus we are not prescriptive here - we are		not even exist at the time of this writing. Thus, we are not prescriptiv
	stating the desired		e here; we are
	end result, with the understanding that most DetNet use cases will neces		stating the desired end result, with the understanding that most DetNet
	sarily differ from		use cases will
	each other, and there is no "one size fits all". </t>		necessarily differ from each other, and there is no "one size fits all".
	</section>		</t>
	<section title="Abbreviations and Terminology">		</section>
	<t>IT: Information Technology (the application of computers to store, stud		<section numbered="true" toc="default">
	y, retrieve,		<name>Abbreviations and Terminology</name>
	transmit, and manipulate data or information, often in the context of a
	business or other
	enterprise - <xref target="IT_DEF"/>). </t>
	<t>OT: Operational Technology (the hardware and software dedicated to dete
	cting or causing
	changes in physical processes through direct monitoring and/or control o
	f physical devices
	such as valves, pumps, etc. - <xref target="OT_DEF"/>) </t>
	<t>Component: A component of a DetNet system - used here to refer to any h
	ardware or software
	element of a DetNet which implements DetNet-specific functionality, for
	example all or part
	of a router, switch, or end system.</t>
	<t>Device: Used here to refer to a physical entity controlled by the DetNe
	t, for example a
	motor.</t>
	<t>Resource Segmentation: Used as a more general form for Network Segmenta
	tion (the act or
	practice of splitting a computer network into subnetworks, each being a
	network segment -
	<xref target="RS_DEF"/>) </t>
	<t>Controller Plane: In DetNet the Controller Plane corresponds to the agg
	regation of the
	Control and Management Planes (see <xref target="RFC8655"/> section 4.4.
	2). </t>
	</section>
	<section title="Security Considerations for DetNet Component Design">		<dl>
			<dt>Information Technology (IT): </dt>
			<dd>The application of computers to store, study, retrieve, transmit, an
			d manipulate data or
			information, often in the context of a business or other enterprise <x
			ref target="IT-DEF"
			format="default"/>. </dd>
			<dt>Operational Technology (OT): </dt>
			<dd>The hardware and software dedicated to detecting or causing changes
			in physical
			processes through direct monitoring and/or control of physical devices
			such as valves,
			pumps, etc. <xref target="OT-DEF" format="default"/>. </dd>
			<dt>Component: </dt>
			<dd>A component of a DetNet system -- used here to refer to any hardware
			or software element
			of a DetNet that implements DetNet-specific functionality, for example
			, all or part of a
			router, switch, or end system. </dd>
			<dt>Device: </dt>
			<dd>Used here to refer to a physical entity controlled by the DetNet, fo
			r example, a motor. </dd>
			<dt>Resource Segmentation: </dt>
			<dd>Used as a more general form for Network Segmentation (the act or pra
			ctice of splitting a
			computer network into sub-networks, each being a network segment <xref
			target="NS-DEF"
			format="default"/>). </dd>
			<dt>Controller Plane: </dt>
			<dd>In DetNet, the Controller Plane corresponds to the aggregation of th
			e Control and
			Management Planes (see <xref target="RFC8655" sectionFormat="comma" se
			ction="4.4.2"
			format="default"/>). </dd>
			</dl>
			</section>
			<section numbered="true" toc="default">
			<name>Security Considerations for DetNet Component Design</name>
	<t>This section provides guidance for implementers of components to be use d in a DetNet. </t>		<t>This section provides guidance for implementers of components to be use d in a DetNet. </t>
	<t>As noted above, DetNet provides resource allocation, explicit routes an d redundant path		<t>As noted above, DetNet provides resource allocation, explicit routes, a nd redundant path
	support. Each of these has associated security implications, which are d iscussed in this		support. Each of these has associated security implications, which are d iscussed in this
	section, in the context of component design. Detection, reporting and ap propriate action in		section, in the context of component design. Detection, reporting and ap propriate action in
	the case of packet arrival time violations are also discussed.</t>		the case of packet arrival-time violations are also discussed.</t>
			<section numbered="true" toc="default">
	<section title="Resource Allocation">		<name>Resource Allocation</name>
			<section numbered="true" toc="default">
	<section title="Inviolable Flows">		<name>Inviolable Flows</name>
	<t>A DetNet system security designer relies on the premise that any re sources allocated to		<t>A DetNet system security designer relies on the premise that any re sources allocated to
	a resource-reserved (OT-type) flow are inviolable; in other words th ere is no physical		a resource-reserved (OT-type) flow are inviolable; in other words, t here is no physical
	possibility within a DetNet component that resources allocated to a given DetNet flow		possibility within a DetNet component that resources allocated to a given DetNet flow
	can be compromised by any type of traffic in the network; this inclu des malicious		can be compromised by any type of traffic in the network. This inclu des malicious
	traffic as well as inadvertent traffic such as might be produced by a malfunctioning		traffic as well as inadvertent traffic such as might be produced by a malfunctioning
	component, or due to interactions between components that were not s ufficiently tested		component, or due to interactions between components that were not s ufficiently tested
	for interoperability. From a security standpoint this is a critical		for interoperability. From a security standpoint, this is a critical
	assumption, for		assumption, for
	example when designing against DOS attacks. In other words, with cor		example, when designing against DoS attacks. In other words, with co
	rectly designed		rrectly designed
	components and security mechanisms, one can prevent malicious activi ties from impacting		components and security mechanisms, one can prevent malicious activi ties from impacting
	other resources.</t>		other resources.</t>
	<t>However, achieving the goal of absolutely inviolable flows may not be technically or		<t>However, achieving the goal of absolutely inviolable flows may not be technically or
	economically feasible for any given use case, given the broad range of possible use		economically feasible for any given use case, given the broad range of possible use
	cases (e.g. [reference to DetNet Use Cases RFC8578]) and their assoc		cases (e.g., <xref target="RFC8578"/>) and their associated security
	iated security		considerations as
	considerations as outlined in this document. It can be viewed as a c		outlined in this document. It can be viewed as a continuum of securi
	ontinuum of security		ty requirements,
	requirements, from isolated ultra-low latency systems that may have		from isolated ultra-low latency systems that may have little securit
	little security		y vulnerability
	vulnerability (such as an industrial machine) to broadly distributed		(such as an industrial machine) to broadly distributed systems with
	systems with many		many possible attack
	possible attack vectors and OT security concerns (such as a utility		vectors and OT security concerns (such as a utility network). Given
	network). Given this		this continuum, the
	continuum, the design principle employed in this document is to spec		design principle employed in this document is to specify the desired
	ify the desired end		end results,
	results, without being overly prescriptive in how the results are ac		without being overly prescriptive in how the results are achieved, r
	hieved, reflecting		eflecting the
	the understanding that no individual implementation is likely to be		understanding that no individual implementation is likely to be appr
	appropriate for		opriate for every
	every DetNet use case. </t>		DetNet use case. </t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Design Trade-Off Considerations in the Use Cases Continu		<name>Design Trade-Off Considerations in the Use Cases Continuum</name
	um">		>
	<t>It is important for the DetNet system designer to understand, for a		<t>For any given DetNet use case and its associated security requireme
	ny given DetNet use		nts, it is important
	case and its associated security requirements, the interaction and d		for the DetNet system designer to understand the interaction and des
	esign trade-offs		ign trade-offs that
	that inevitably need to be reconciled between the desired end result		inevitably need to be reconciled between the desired end results and
	s and the DetNet		the DetNet
	protocols, as well as the DetNet system and component design. </t>		protocols, as well as the DetNet system and component design. </t>
	<t>For any given component, as designed for any given use case (or sco pe of use cases), it		<t>For any given component, as designed for any given use case (or sco pe of use cases), it
	is the responsibility of the component designer to ensure that the p remise of inviolable		is the responsibility of the component designer to ensure that the p remise of inviolable
	flows is supported, to the extent that they deem necessary to suppor t their target use		flows is supported to the extent that they deem necessary to support their target use
	cases. </t>		cases. </t>
	<t>For example, the component may include traffic shaping and policing		<t>For example, the component may include traffic shaping and policing
	at the ingress, to		at the ingress to
	prevent corrupted or malicious or excessive packets from entering th		prevent corrupted, malicious, or excessive packets from entering the
	e network, thereby		network, thereby
	decreasing the likelihood that any traffic will interfere with any D etNet OT flow. The		decreasing the likelihood that any traffic will interfere with any D etNet OT flow. The
	component may include integrity protection for some or all of the he ader fields such as		component may include integrity protection for some or all of the he ader fields such as
	those used for flow ID, thereby decreasing the likelihood that a pac ket whose flow ID		those used for flow ID, thereby decreasing the likelihood that a pac ket whose flow ID
	has been compromised might be directed into a different flow path. T he component may		has been compromised might be directed into a different flow path. T he component may
	verify every single packet header at every forwarding location, or o nly at certain		verify every single packet header at every forwarding location, or o nly at certain
	points. In any of these cases the component may use dynamic performa		points. In any of these cases, the component may use dynamic perform
	nce analytics (<xref		ance analytics
	target="DpaMitigation"/>) to cause action to be initiated to addre		(<xref target="DpaMitigation" format="default"/>) to cause action
	ss the situation in		to be initiated to
	an appropriate and timely manner, either at the data plane or contro		address the situation in an appropriate and timely manner, either at
	ller plane, or both		the data plane or
	in concert. The component's software and hardware may include measur		controller plane, or both in concert. The component's software and h
	es to ensure the		ardware may include
	integrity of the resource allocation/deallocation process. Other des		measures to ensure the integrity of the resource allocation/dealloca
	ign aspects of the		tion process. Other
	component may help ensure that the adverse effects of malicious traf		design aspects of the component may help ensure that the adverse eff
	fic are more		ects of malicious
	limited, for example by protecting network control interfaces, or mi		traffic are more limited, for example, by protecting network control
	nimizing cascade		interfaces or
	failures. The component may include features specific to a given use		minimizing cascade failures. The component may include features spec
	case, such as		ific to a given use
	configuration of the response to a given sequential packet loss coun		case, such as configuration of the response to a given sequential pa
	t. </t>		cket loss count. </t>
	<t>Ultimately, due to cost and complexity factors, the security proper ties of a component		<t>Ultimately, due to cost and complexity factors, the security proper ties of a component
	designed for low-cost systems may be (by design) far inferior to a c omponent with		designed for low-cost systems may be (by design) far inferior to a c omponent with
	similar intended functionality, but designed for highly secure or ot herwise critical		similar intended functionality, but designed for highly secure or ot herwise critical
	applications, perhaps at substantially higher cost. Any given compon ent is designed for		applications, perhaps at substantially higher cost. Any given compon ent is designed for
	some set of use cases and accordingly will have certain limitations on its security		some set of use cases and accordingly will have certain limitations on its security
	properties and vulnerabilities. It is thus the responsibility of the system designer to		properties and vulnerabilities. It is thus the responsibility of the system designer to
	assure themselves that the components they use in their design are c apable of satisfying		assure themselves that the components they use in their design are c apable of satisfying
	their overall system security requirements. </t>		their overall system security requirements. </t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Documenting the Security Properties of a Component">		<name>Documenting the Security Properties of a Component</name>
	<t>In order for the system designer to adequately understand the secur		<t>In order for the system designer to adequately understand the secur
	ity related behavior		ity-related behavior
	of a given component, the designer of any component intended for use with DetNet needs		of a given component, the designer of any component intended for use with DetNet needs
	to clearly document the security properties of that component. For e xample, to address		to clearly document the security properties of that component. For e xample, to address
	the case where a corrupted packet in which the flow identification i nformation is		the case where a corrupted packet in which the flow identification i nformation is
	compromised and thus may incidentally match the flow ID of another ( "victim") DetNet		compromised and thus may incidentally match the flow ID of another ( "victim") DetNet
	flow, resulting in additional unauthorized traffic on the victim, th e documentation		flow, resulting in additional unauthorized traffic on the victim, th e documentation
	might state that the component employs integrity protection on the f low identification		might state that the component employs integrity protection on the f low identification
	fields. </t>		fields. </t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Fail-Safe Component Behavior">		<name>Fail-Safe Component Behavior</name>
	<t>Even when the security properties of a component are understood and well specified, if		<t>Even when the security properties of a component are understood and well specified, if
	the component malfunctions, for example due to physical circumstance		the component malfunctions, for example, due to physical circumstanc
	s unpredicted by the		es unpredicted by
	component designer, it may be difficult or impossible to fully preve		the component designer, it may be difficult or impossible to fully p
	nt malfunction of		revent malfunction
	the network. The degree to which a component is hardened against var		of the network. The degree to which a component is hardened against
	ious types of		various types of
	failures is a distinguishing feature of the component and its design , and the overall		failures is a distinguishing feature of the component and its design , and the overall
	system design can only be as strong as its weakest link. </t>		system design can only be as strong as its weakest link. </t>
	<t>However, all networks are subject to this level of uncertainty; it is not unique to		<t>However, all networks are subject to this level of uncertainty; it is not unique to
	DetNet. Having said that, DetNet raises the bar by changing many add ed latency scenarios		DetNet. Having said that, DetNet raises the bar by changing many add ed latency scenarios
	from tolerable annoyances to unacceptable service violations. That i n turn underscores		from tolerable annoyances to unacceptable service violations. That i n turn underscores
	the importance of system integrity, as well as correct and stable co nfiguration of the		the importance of system integrity, as well as correct and stable co nfiguration of the
	network and its nodes, as discussed in <xref target="Introduction"/>		network and its nodes, as discussed in <xref target="Introduction" f
	. </t>		ormat="default"/>.
			</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Flow Aggregation Example">		<name>Flow Aggregation Example</name>
	<t>As another example regarding resource allocation implementation, co nsider the		<t>As another example regarding resource allocation implementation, co nsider the
	implementation of Flow Aggregation for DetNet flows (as discussed in <xref		implementation of Flow Aggregation for DetNet flows (as discussed in <xref
	target="RFC8938"/>). In this example say there are N flows that ar		target="RFC8938" format="default"/>). In this example, say there a
	e to be aggregated,		re N flows that are
	thus the bandwidth resources of the aggregate flow must be sufficien		to be aggregated; thus, the bandwidth resources of the aggregate flo
	t to contain the sum		w must be sufficient
	of the bandwidth reservation for the N flows. However if one of thos		to contain the sum of the bandwidth reservation for the N flows. How
	e flows were to		ever, if one of
	consume more than its individually allocated bandwidth, this could c		those flows were to consume more than its individually allocated ban
	ause starvation of		dwidth, this could
	the other flows. Thus simply providing and enforcing the calculated		cause starvation of the other flows. Thus, simply providing and enfo
	aggregate bandwidth		rcing the calculated
	may not be a complete solution - the bandwidth for each individual f		aggregate bandwidth may not be a complete solution; the bandwidth fo
	low must still be		r each individual
	guaranteed, for example via ingress policing of each flow (i.e. befo		flow must still be guaranteed, for example, via ingress policing of
	re it is		each flow (i.e.,
	aggregated). Alternatively, if by some other means each flow to be a		before it is aggregated). Alternatively, if by some other means each
	ggregated can be		flow to be
	trusted not to exceed its allocated bandwidth, the same goal can be		aggregated can be trusted not to exceed its allocated bandwidth, the
	achieved. </t>		same goal can be
			achieved. </t>
	</section>		</section>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Explicit Routes">		<name>Explicit Routes</name>
	<t>The DetNet-specific purpose for constraining the ability of the DetNe		<t>The DetNet-specific purpose for constraining the ability of the DetNe
	t to re-route OT		t to reroute OT
	traffic is to maintain the specified service parameters (such as upper and lower latency		traffic is to maintain the specified service parameters (such as upper and lower latency
	boundaries) for a given flow. For example if the network were to re-ro ute a flow (or some		boundaries) for a given flow. For example, if the network were to rero ute a flow (or some
	part of a flow) based exclusively on statistical path usage metrics, o r due to malicious		part of a flow) based exclusively on statistical path usage metrics, o r due to malicious
	activity, it is possible that the new path would have a latency that i s outside the		activity, it is possible that the new path would have a latency that i s outside the
	required latency bounds which were designed into the original TE-desig ned path, thereby		required latency bounds that were designed into the original TE-design ed path, thereby
	violating the quality of service for the affected flow (or part of tha t flow). </t>		violating the quality of service for the affected flow (or part of tha t flow). </t>
	<t>However, it is acceptable for the network to re-route OT traffic in s uch a way as to		<t>However, it is acceptable for the network to reroute OT traffic in su ch a way as to
	maintain the specified latency bounds (and any other specified service properties) for any		maintain the specified latency bounds (and any other specified service properties) for any
	reason, for example in response to a runtime component or path failure . </t>		reason, for example, in response to a runtime component or path failur e. </t>
	<t>So from a DetNet security standpoint, the DetNet system designer can expect that any		<t>So from a DetNet security standpoint, the DetNet system designer can expect that any
	component designed for use in a DetNet will deliver the packets within the agreed-upon		component designed for use in a DetNet will deliver the packets within the agreed-upon
	service parameters. For the component designer, this means that in ord er for a component		service parameters. For the component designer, this means that in ord er for a component
	to achieve that expectation, any component that is involved in control ling or implementing		to achieve that expectation, any component that is involved in control ling or implementing
	any change of the initially TE-configured flow routes must prevent re-		any change of the initially TE-configured flow routes must prevent rer
	routing of OT flows		outing of OT flows
	(whether malicious or accidental) which might adversely affect deliver		(whether malicious or accidental) that might adversely affect deliveri
	ing the traffic		ng the traffic
	within the specified service parameters.</t>		within the specified service parameters.</t>
	</section>		</section>
			<section numbered="true" toc="default">
			<name>Redundant Path Support</name>
			<t>The DetNet provision for redundant paths (i.e., PREOF, or "Packet Rep
			lication,
			Elimination, and Ordering Functions"), as defined in the DetNet Archit
			ecture <xref
			target="RFC8655" format="default"/>, provides the foundation for hig
			h reliability of a
			DetNet by virtually eliminating packet loss (i.e., to a degree that is
			implementation
			dependent) through hitless redundant packet delivery. </t>
			<aside>
			<t>Note: At the time of this writing, PREOF is not defined for the IP
			data plane.</t>
			</aside>
	<section title="Redundant Path Support">
	<t>The DetNet provision for redundant paths (PREOF) (as defined in the D
	etNet Architecture
	<xref target="RFC8655"/>) provides the foundation for high reliabili
	ty of a DetNet, by
	virtually eliminating packet loss (i.e. to a degree which is implement
	ation-dependent)
	through hitless redundant packet delivery. Note: At the time of this w
	riting, PREOF is not
	defined for the IP data plane. </t>
	<t>It is the responsibility of the system designer to determine the leve l of reliability		<t>It is the responsibility of the system designer to determine the leve l of reliability
	required by their use case, and to specify redundant paths sufficient to provide the		required by their use case and to specify redundant paths sufficient t o provide the
	desired level of reliability (in as much as that reliability can be pr ovided through the		desired level of reliability (in as much as that reliability can be pr ovided through the
	use of redundant paths). It is the responsibility of the component des igner to ensure that		use of redundant paths). It is the responsibility of the component des igner to ensure that
	the relevant PREOF operations are executed reliably and securely, to a void potentially		the relevant PREOF operations are executed reliably and securely to av oid potentially
	catastrophic situations for the operational technology relying on them . </t>		catastrophic situations for the operational technology relying on them . </t>
	<t>However, note that not all PREOF operations are necessarily implement ed in every network;		<t>However, note that not all PREOF operations are necessarily implement ed in every network;
	for example a packet re-ordering function may not be necessary if the		for example, a packet reordering function may not be necessary if the
	packets are either		packets are either
	not required to be in order, or if the ordering is performed in some o		not required to be in order or if the ordering is performed in some ot
	ther part of the		her part of the
	network.</t>		network.</t>
	<t>Ideally a redundant path for a flow could be specified from end to en		<t>Ideally, a redundant path for a flow could be specified from end to e
	d, however given		nd; however, given
	that this is not always possible (as described in <xref target="RFC865		that this is not always possible (as described in <xref target="RFC865
	5"/>) the system		5" format="default"
	designer will need to consider the resulting end-to-end reliability an		/>), the system designer will need to consider the resulting end-to-en
	d security resulting		d reliability and
	from any given arrangement of network segments along the path, each of		security resulting from any given arrangement of network segments alon
	which provides its		g the path, each of
	individual PREOF implementation and thus its individual level of relia		which provides its individual PREOF implementation and thus its indivi
	bility and security. </t>		dual level of
	<t>At the data plane the implementation of PREOF depends on the correct		reliability and security. </t>
	assignment and		<t>At the data plane, the implementation of PREOF depends on the correct
			assignment and
	interpretation of packet sequence numbers, as well as the actions take n based on them,		interpretation of packet sequence numbers, as well as the actions take n based on them,
	such as elimination (including elimination of packets with spurious se quence numbers).		such as elimination (including elimination of packets with spurious se quence numbers).
	Thus the integrity of these values must be maintained by the component		Thus, the integrity of these values must be maintained by the componen
	as they are		t as they are
	assigned by the DetNet Data Plane Service sub-layer, and transported b		assigned by the DetNet Data Plane Service sub-layer and transported by
	y the Forwarding		the Forwarding
	sub-layer. This is no different than the integrity of the values in an y header used by the		sub-layer. This is no different than the integrity of the values in an y header used by the
	DetNet (or any other) data plane, and is not unique to redundant paths		DetNet (or any other) data plane and is not unique to redundant paths.
	. The integrity		The integrity
	protection of header values is technology-dependent; for example, in L		protection of header values is technology dependent; for example, in L
	ayer 2 networks the		ayer 2 networks, the
	integrity of the header fields can be protected by using MACsec <xref		integrity of the header fields can be protected by using MACsec <xref
	target="IEEE802.1AE-2018"/>. Similarly, from the sequence number inj		target="IEEE802.1AE-2018" format="default"/>. Similarly, from the se
	ection perspective,		quence number
	it is no different from any other protocols that use sequence numbers.		injection perspective, it is no different from any other protocols tha
	In particular IPSec		t use sequence
	Authentication Header (<xref target="RFC4302"/>, Sec. 3 Authentication		numbers; for particulars of integrity protection via IPsec Authenticat
	Header (AH)		ion Headers, useful
	Processing) provides useful insights.</t>		insights are provided by <xref target="RFC4302" sectionFormat="of" sec
			tion="3"
			format="default"/>.</t>
	</section>		</section>
	<section title="Timing (or other) Violation Reporting">		<section numbered="true" toc="default">
			<name>Timing (or Other) Violation Reporting</name>
	<t>A task of the DetNet system designer is to create a network such that		<t>A task of the DetNet system designer is to create a network such
	for any incoming		that for any incoming packet that arrives with any timing or bandwidth
	packet which arrives with any timing or bandwidth violation, an approp		violation, an appropriate action can be taken in order to prevent
	riate action can be		damage to the system. The reporting step may be accomplished through
	taken in order to prevent damage to the system. The reporting step may		dynamic performance analysis (see <xref target="DpaMitigation"
	be accomplished		format="default"/>) or by any other means as implemented in one or
	through dynamic performance analysis (see <xref target="DpaMitigation"		more components. The action to be taken for any given circumstance
	/>) or by any other		within any given application will depend on the use case. The action
	means as implemented in one or more components. The action to be taken		may involve intervention from the controller plane, or it may be taken
	for any given		"immediately" by an individual component, for example, if a very fast
	circumstance within any given application will depend on the use case.		response is required. </t>
	The action may		<t>The definitions and selections of the actions that can be taken are
	involve intervention from the controller plane, or it may be taken "im		properties of the components. The component designer implements these
	mediately" by an		options according to their expected use cases, which may vary widely
	individual component, for example if very fast response is required. <		from component to component. Clearly, selecting an inappropriate
	/t>		response to a given condition may cause more problems than it is
			intending to mitigate; for example, a naive approach might be to have
	<t>The definitions and selections of the actions that can be taken are p		the component shut down the link if a packet arrives outside of its
	roperties of the		prescribed time window. However, such a simplistic action may serve
	components. The component designer implements these options according		the attacker better than it serves the network. Similarly, simple
	to their expected		logging of such issues may not be adequate since a delay in response
	use cases, which may vary widely from component to component. Clearly		could result in material damage, for example, to mechanical devices
	selecting an		controlled by the network. Thus, a breadth of possible and effective
	inappropriate response to a given condition may cause more problems th		security-related actions and their configuration is a positive
	an it is intending		attribute for a DetNet component.</t>
	to mitigate; for example, a naive approach might be to have the compon		<t>Some possible violations that warrant detection include cases where
	ent shut down the		a packet arrives: </t>
	link if a packet arrives outside of its prescribed time window; howeve		<ul spacing="normal">
	r such a simplistic		<li>Outside of its prescribed time window</li>
	action may serve the attacker better than it serves the network. Simil		<li>Within its time window but with a compromised timestamp that
	arly, simple logging		makes it appear that it is not within its window</li>
	of such issues may not be adequate, since a delay in response could re		<li>Exceeding the reserved flow bandwidth</li>
	sult in material		</ul>
	damage, for example to mechanical devices controlled by the network. T
	hus a breadth of
	possible and effective security-related actions and their configuratio
	n is a positive
	attribute for a DetNet component.</t>
	<t>Some possible violations that warrant detection include cases where a
	packet arrives: </t>
	<t>
	<list style="symbols">
	<t>Outside of its prescribed time window</t>
	<t>Within its time window but with a compromised time stamp that mak
	es it appear that it
	is not within its window</t>
	<t>Exceeding the reserved flow bandwidth</t>
	</list>
	</t>
	<t>Some possible direct actions that may be taken at the data plane incl ude traffic policing		<t>Some possible direct actions that may be taken at the data plane incl ude traffic policing
	and shaping functions (e.g., those described in <xref target="RFC2475"		and shaping functions (e.g., those described in <xref target="RFC2475"
	/>), separating		format="default"
	flows into per-flow rate-limited queues, and potentially applying acti		/>), separating flows into per-flow rate-limited queues, and potential
	ve queue management		ly applying active
	<xref target="RFC7567"/>. However if those (or any other) actions ar		queue management <xref target="RFC7567" format="default"/>. However, i
	e to be taken, the		f those (or any
	system designer must ensure that the results of such actions do not co		other) actions are to be taken, the system designer must ensure that t
	mpromise the		he results of such
	continued safe operation of the system. For example, the network (i.e.		actions do not compromise the continued safe operation of the system.
	the controller		For example, the
	plane and data plane working together) must mitigate in a timely fashi		network (i.e., the controller plane and data plane working together) m
	on any potential		ust mitigate in a
	adverse effect on mechanical devices controlled by the network. </t>		timely fashion any potential adverse effect on mechanical devices cont
			rolled by the
			network. </t>
	</section>		</section>
	</section>		</section>
	<section title="DetNet Security Considerations Compared With DiffServ Securi		<section numbered="true" toc="default">
	ty Considerations">		<name>DetNet Security Considerations Compared with Diffserv Security Consi
	<t>DetNet is designed to be compatible with DiffServ <xref target="RFC2474		derations</name>
	"/> as applied to IT		<t>DetNet is designed to be compatible with Diffserv <xref target="RFC2474
	traffic in the DetNet. DetNet also incorporates the use of the 6-bit val		" format="default"/>
	ue of the DCSP field		as applied to IT traffic in the DetNet. DetNet also incorporates the use
	of the Type of Service (IPv4) and Traffic Class (IPv6) bytes for flow id		of the 6-bit value
	entification.		of the Differentiated Services Code Point (DSCP) field of the Type of Se
	However, the DetNet interpretation of the DSCP value for OT traffic is n		rvice (IPv4) and
	ot equivalent to the		Traffic Class (IPv6) bytes for flow identification. However, the DetNet
	PHB selection behavior as defined by DiffServ. </t>		interpretation of
			the DSCP value for OT traffic is not equivalent to the per-hop behavior
	<t>Thus security consideration for DetNet have some aspects in common with		(PHB) selection
	DiffServ, in fact		behavior as defined by Diffserv. </t>
			<t>Thus, security considerations for DetNet have some aspects in common wi
			th Diffserv, in fact
	overlapping 100% with respect to IP IT traffic. Security considerations for these aspects		overlapping 100% with respect to IP IT traffic. Security considerations for these aspects
	are part of the existing literature on IP network security, specifically the Security		are part of the existing literature on IP network security, specifically the Security
	Considerations sections of <xref target="RFC2474"/> and <xref target="RF		Considerations sections of <xref target="RFC2474" format="default"/> and
	C2475"/>. However,		<xref
	DetNet also introduces timing and other considerations which are not pre		target="RFC2475" format="default"/>. However, DetNet also introduces t
	sent in DiffServ, so		iming and other
	the DiffServ security considerations are a subset of the DetNet security		considerations that are not present in Diffserv, so the Diffserv securit
	considerations. </t>		y considerations are
			a subset of the DetNet security considerations. </t>
	<t>In the case of DetNet OT traffic, the DSCP value is interpreted differe ntly than in		<t>In the case of DetNet OT traffic, the DSCP value is interpreted differe ntly than in
	DiffServ and contribute to determination of the service provided to the		Diffserv and contributes to determination of the service provided to the
	packet. In DetNet,		packet. In DetNet,
	there are similar consequences to DiffServ for lack of detection of, or		there are similar consequences to Diffserv for lack of detection of, or
	incorrect handling		incorrect handling
	of, packets with mismarked DSCP values, and many of the points made in t		of, packets with mismarked DSCP values, and many of the points made in t
	he DiffServ Security		he Diffserv Security
	discussions (<xref target="RFC2475"/> Sec. 6.1 , <xref target="RFC2474"/		discussions (<xref target="RFC2475" sectionFormat="of" section="6.1" for
	> Sec. 7 and <xref		mat="default"/>,
	target="RFC6274"/> Sec 3.3.2.1) are also relevant to DetNet OT traffic		<xref target="RFC2474" sectionFormat="of" section="7" format="default"
	, though perhaps in		/>, and <xref
	modified form. For example, in DetNet the effect of an undetected or inc		target="RFC6274" sectionFormat="of" section="3.3.2.1" format="default"
	orrectly handled		/>) are also
	maliciously mismarked DSCP field in an OT packet is not identical to aff		relevant to DetNet OT traffic though perhaps in modified form. For examp
	ecting the PHB of		le, in DetNet, the
	that packet, since DetNet does not use the PHB concept for OT traffic; b		effect of an undetected or incorrectly handled maliciously mismarked DSC
	ut nonetheless the		P field in an OT
	service provided to the packet could be affected, so mitigation measures		packet is not identical to affecting the PHB of that packet, since DetNe
	analogous to those		t does not use the
	prescribed by DiffServ would be appropriate for DetNet. For example, mis		PHB concept for OT traffic. Nonetheless, the service provided to the pac
	marked DSCP values		ket could be
	should not cause failure of network nodes. The remarks in <xref target="		affected, so mitigation measures analogous to those prescribed by Diffse
	RFC2474"/> regarding		rv would be
	IPsec and Tunnelling Interactions are also relevant (though this is not		appropriate for DetNet. For example, mismarked DSCP values should not ca
	to say that other		use failure of
	sections are less relevant). </t>		network nodes. The remarks in <xref target="RFC2474" format="default"/>
			regarding IPsec and
			Tunneling Interactions are also relevant (though this is not to say that
			other sections are
			less relevant). </t>
	<t>In this discussion, interpretation (and any possible intentional re-mar king) of the DSCP		<t>In this discussion, interpretation (and any possible intentional re-mar king) of the DSCP
	values of packets destined for DetNet OT flows is expected to occur at t he ingress to the		values of packets destined for DetNet OT flows is expected to occur at t he ingress to the
	DetNet domain; once inside the domain, maintaining the integrity of the DSCP values is		DetNet domain; once inside the domain, maintaining the integrity of the DSCP values is
	subject to the same handling considerations as any other field in the pa cket.</t>		subject to the same handling considerations as any other field in the pa cket.</t>
	</section>		</section>
	<section anchor="ThreatSection" title="Security Threats">		<section anchor="ThreatSection" numbered="true" toc="default">
	<t>This section presents a taxonomy of threats, and analyzes the possible		<name>Security Threats</name>
	threats in a		<t>This section presents a taxonomy of threats and analyzes the possible t
			hreats in a
	DetNet-enabled network. The threats considered in this section are indep endent of any		DetNet-enabled network. The threats considered in this section are indep endent of any
	specific technologies used to implement the DetNet; <xref target="Techno logySpecificThreats"		specific technologies used to implement the DetNet; <xref target="Techno logySpecificThreats"
	/> considers attacks that are associated with the DetNet technologies en		format="default"/> considers attacks that are associated with the DetN
	compassed by <xref		et technologies
	target="RFC8938"/>. </t>		encompassed by <xref target="RFC8938" format="default"/>. </t>
	<t> We distinguish controller plane threats from data plane threats. The a ttack surface may be		<t> We distinguish controller plane threats from data plane threats. The a ttack surface may be
	the same, but the types of attacks as well as the motivation behind them		the same, but the types of attacks, as well as the motivation behind the
	, are different. For		m, are different.
	example, a delay attack is more relevant to data plane than to controlle		For example, a Delay attack is more relevant to the data plane than to t
	r plane. There is		he controller plane.
	also a difference in terms of security solutions: the way you secure the		There is also a difference in terms of security solutions; the way you s
	data plane is often		ecure the data plane
	different than the way you secure the controller plane. </t>		is often different than the way you secure the controller plane. </t>
	<section title="Threat Taxonomy">		<section numbered="true" toc="default">
			<name>Threat Taxonomy</name>
	<t>This document employs organizational elements of the threat models of <xref		<t>This document employs organizational elements of the threat models of <xref
	target="RFC7384"/> and <xref target="RFC7835"/>. This model classifi		target="RFC7384" format="default"/> and <xref target="RFC7835" forma
	es attackers based		t="default"/>. This
	on two criteria: </t>		model classifies attackers based on two criteria: </t>
	<t>
	<list style="symbols">		<dl newline="true">
	<t>Internal vs. external: internal attackers either have access to a		<dt>Internal vs. external:</dt>
	trusted segment of		<dd> Internal attackers either have access to a trusted segment of the
	the network or possess the encryption or authentication keys. Exte		network or possess
	rnal attackers, on		the encryption or authentication keys. External attackers, on the ot
	the other hand, do not have the keys and have access only to the e		her hand, do not
	ncrypted or		have the keys and have access only to the encrypted or authenticated
	authenticated traffic.</t>		traffic. </dd>
	<t>On-path vs. off-path: on-path attackers are located in a position
	that allows		<dt>On-path vs. off-path:</dt>
	interception, modification, or dropping of in-flight protocol pack		<dd> On-path attackers are located in a position that allows intercept
	ets, whereas		ion, modification,
	off-path attackers can only attack by generating protocol packets.		or dropping of in-flight protocol packets, whereas off-path attacker
	</t>		s can only attack by
	</list>		generating protocol packets. </dd>
	</t>		</dl>
	<t>Regarding the boundary between internal vs. external attackers as def
	ined above, please		<t>Regarding the boundary between internal vs. external attackers as def
	note that in this document we do not make concrete recommendations reg		ined above, note
	arding which		that in this document we do not make concrete recommendations regardin
	specific segments of the network are to be protected in any specific w		g which specific
	ay, for example via		segments of the network are to be protected in any specific way, for e
			xample, via
	encryption or authentication. As a result, the boundary as defined abo ve is not		encryption or authentication. As a result, the boundary as defined abo ve is not
	unequivocally specified here. Given that constraint, the reader can vi ew an internal		unequivocally specified here. Given that constraint, the reader can vi ew an internal
	attacker as one who can operate within the perimeter defined by the De tNet Edge Nodes (as		attacker as one who can operate within the perimeter defined by the De tNet Edge Nodes (as
	defined in the DetNet Architecture <xref target="RFC8655"/>), allowing		defined in the DetNet Architecture <xref target="RFC8655" format="defa
	that the specifics		ult"/>), allowing
	of what is encrypted or authenticated within this perimeter will vary		that the specifics of what is encrypted or authenticated within this p
	depending on the		erimeter will vary
	implementation. </t>		depending on the implementation. </t>
	<t>Care has also been taken to adhere to Section 5 of <xref target="RFC3		<t>Care has also been taken to adhere to <xref target="RFC3552" sectionF
	552"/>, both with		ormat="of"
	respect to which attacks are considered out-of-scope for this document		section="5" format="default"/>, both with respect to which attacks a
	, but also which are		re considered out of
	considered to be the most common threats (explored further in <xref		scope for this document, and also which are considered to be the most
	target="ThreatAnalysis"/>, Threat Analysis). Most of the direct thre		common threats
	ats to DetNet are		(explored further in <xref target="ThreatAnalysis" format="default"/>)
	active attacks (i.e. attacks that modify DetNet traffic), but it is hi		. Most of the direct
	ghly suggested that		threats to DetNet are active attacks (i.e., attacks that modify DetNet
	DetNet application developers take appropriate measures to protect the		traffic), but it is
	content of the		highly suggested that DetNet application developers take appropriate m
	DetNet flows from passive attacks (i.e. attacks that observe but do no		easures to protect
	t modify DetNet		the content of the DetNet flows from passive attacks (i.e., attacks th
	traffic) for example through the use of TLS or DTLS. </t>		at observe but do
			not modify DetNet traffic), for example, through the use of TLS or DTL
			S. </t>
	<t>DetNet-Service, one of the service scenarios described in <xref		<t>DetNet-Service, one of the service scenarios described in <xref
	target="I-D.varga-detnet-service-model"/>, is the case where a servi		target="I-D.varga-detnet-service-model" format="default"/>, is the c
	ce connects DetNet		ase where a service
	islands, i.e. two or more otherwise independent DetNets are connected		connects DetNet islands, i.e., two or more otherwise independent DetNe
	via a link that is		ts are connected via
	not intrinsically part of either network. This implies that there coul		a link that is not intrinsically part of either network. This implies
	d be DetNet traffic		that there could be
	flowing over a non-DetNet link, which may provide an attacker with an		DetNet traffic flowing over a non-DetNet link, which may provide an at
	advantageous		tacker with an
	opportunity to tamper with DetNet traffic. The security properties of		advantageous opportunity to tamper with DetNet traffic. The security p
	non-DetNet links are		roperties of
	outside of the scope of DetNet Security, but it should be noted that u		non-DetNet links are outside of the scope of DetNet Security, but it s
	se of non-DetNet		hould be noted that
	services to interconnect DetNets merits security analysis to ensure th		use of non-DetNet services to interconnect DetNets merits security ana
	e integrity of the		lysis to ensure the
	networks involved. </t>		integrity of the networks involved. </t>
	</section>		</section>
	<section anchor="ThreatAnalysis" title="Threat Analysis">		<section anchor="ThreatAnalysis" numbered="true" toc="default">
	<section anchor="DelayThreat" title="Delay">		<name>Threat Analysis</name>
			<section anchor="DelayThreat" numbered="true" toc="default">
			<name>Delay</name>
	<t>An attacker can maliciously delay DetNet data flow traffic. By dela ying the traffic,		<t>An attacker can maliciously delay DetNet data flow traffic. By dela ying the traffic,
	the attacker can compromise the service of applications that are sen sitive to high		the attacker can compromise the service of applications that are sen sitive to high
	delays or to high delay variation. The delay may be constant or modu lated.</t>		delays or to high delay variation. The delay may be constant or modu lated.</t>
	</section>		</section>
	<section anchor="ModificationThreat" title="DetNet Flow Modification or		<section anchor="ModificationThreat" numbered="true" toc="default">
	Spoofing">		<name>DetNet Flow Modification or Spoofing</name>
	<t>An attacker can modify some header fields of en route packets in a way that causes the		<t>An attacker can modify some header fields of en route packets in a way that causes the
	DetNet flow identification mechanisms to misclassify the flow. Alter natively, the		DetNet flow identification mechanisms to misclassify the flow. Alter natively, the
	attacker can inject traffic that is tailored to appear as if it belo ngs to a legitimate		attacker can inject traffic that is tailored to appear as if it belo ngs to a legitimate
	DetNet flow. The potential consequence is that the DetNet flow resou rce allocation		DetNet flow. The potential consequence is that the DetNet flow resou rce allocation
	cannot guarantee the performance that is expected when the flow iden tification works		cannot guarantee the performance that is expected when the flow iden tification works
	correctly.</t>		correctly.</t>
	</section>		</section>
	<section anchor="SegmentThreat"		<section anchor="SegmentThreat" numbered="true" toc="default">
	title="Resource Segmentation (Inter-segment Attack) Vulnerability">		<name>Resource Segmentation (Inter-segment Attack) Vulnerability</name
			>
	<t>DetNet components are expected to split their resources between Det Net flows in a way		<t>DetNet components are expected to split their resources between Det Net flows in a way
	that prevents traffic from one DetNet flow from affecting the perfor mance of other		that prevents traffic from one DetNet flow from affecting the perfor mance of other
	DetNet flows, and also prevents non-DetNet traffic from affecting De tNet flows. However,		DetNet flows and also prevents non-DetNet traffic from affecting Det Net flows. However,
	perhaps due to implementation constraints, some resources may be par tially shared, and		perhaps due to implementation constraints, some resources may be par tially shared, and
	an attacker may try to exploit this property. For example, an attack er can inject		an attacker may try to exploit this property. For example, an attack er can inject
	traffic in order to exhaust network resources such that DetNet packe ts which share		traffic in order to exhaust network resources such that DetNet packe ts that share
	resources with the injected traffic may be dropped or delayed. Such injected traffic may		resources with the injected traffic may be dropped or delayed. Such injected traffic may
	be part of DetNet flows or non-DetNet traffic.</t>		be part of DetNet flows or non-DetNet traffic.</t>
	<t>Another example of a resource segmentation attack is the case in wh		<t>Another example of a Resource Segmentation attack is the case in wh
	ich an attacker is		ich an attacker is
	able to overload the exception path queue on the router, i.e. a "slo		able to overload the exception path queue on the router, i.e., a "sl
	w path" typically		ow path" typically
	taken by control or OAM packets which are diverted from the data pla		taken by control or OAM packets that are diverted from the data plan
	ne because they		e because they
	require processing by a CPU. DetNet OT flows are typically configure d to take the "fast		require processing by a CPU. DetNet OT flows are typically configure d to take the "fast
	path" through the data plane, to minimize latency. However if there		path" through the data plane to minimize latency. However, if there
	is only one queue		is only one queue
	from the forwarding ASIC to the exception path, and for some reason		from the forwarding Application-Specific Integrated Circuit (ASIC) t
	the system is		o the exception
	configured such that any DetNet packets must be handled on this exce		path, and for some reason the system is configured such that any Det
	ption path, then		Net packets must be
	saturating the exception path could result in delaying or dropping o		handled on this exception path, then saturating the exception path c
	f DetNet packets.		ould result in the
	</t>		delaying or dropping of DetNet packets. </t>
	</section>		</section>
	<section anchor="ReplicationThreat" title="Packet Replication and Elimin		<section anchor="ReplicationThreat" numbered="true" toc="default">
	ation">		<name>Packet Replication and Elimination</name>
	<section title="Replication: Increased Attack Surface">		<section numbered="true" toc="default">
			<name>Replication: Increased Attack Surface</name>
	<t>Redundancy is intended to increase the robustness and survivabili ty of DetNet flows,		<t>Redundancy is intended to increase the robustness and survivabili ty of DetNet flows,
	and replication over multiple paths can potentially mitigate an at tack that is limited		and replication over multiple paths can potentially mitigate an at tack that is limited
	to a single path. However, the fact that packets are replicated ov er multiple paths		to a single path. However, the fact that packets are replicated ov er multiple paths
	increases the attack surface of the network, i.e., there are more points in the		increases the attack surface of the network, i.e., there are more points in the
	network that may be subject to attacks.</t>		network that may be subject to attacks.</t>
	</section>		</section>
	<section title="Replication-related Header Manipulation">		<section numbered="true" toc="default">
			<name>Replication-Related Header Manipulation</name>
	<t>An attacker can manipulate the replication-related header fields. This capability		<t>An attacker can manipulate the replication-related header fields. This capability
	opens the door for various types of attacks. For example:</t>		opens the door for various types of attacks. For example:</t>
	<t>
	<list style="symbols">		<dl newline="true">
	<t>Forward both replicas - malicious change of a packet SN (Sequ
	ence Number) can		<dt>Forward both replicas: </dt>
	cause both replicas of the packet to be forwarded. Note that t		<dd>Malicious change of a packet SN (Sequence Number) can cause bo
	his attack has a		th replicas of the
	similar outcome to a replay attack.</t>		packet to be forwarded. Note that this attack has a similar outc
	<t>Eliminate both replicas - SN manipulation can be used to caus		ome to a replay
	e both replicas to		attack. </dd>
	be eliminated. In this case an attacker that has access to a s
	ingle path can cause		<dt>Eliminate both replicas: </dt>
	packets from other paths to be dropped, thus compromising some		<dd>SN manipulation can be used to cause both replicas to be elimi
	of the advantage of		nated. In this case,
	path redundancy.</t>		an attacker that has access to a single path can cause packets f
	<t>Flow hijacking - an attacker can hijack a DetNet flow with ac		rom other paths to
	cess to a single		be dropped, thus compromising some of the advantage of path redu
	path by systematically replacing the SNs on the given path wit		ndancy. </dd>
	h higher SN values.
	For example, an attacker can replace every SN value S with a h		<dt>Flow hijacking: </dt>
	igher value S+C,		<dd>An attacker can hijack a DetNet flow with access to a single p
	where C is a constant integer. Thus, the attacker creates a fa		ath by
	lse illusion that		systematically replacing the SNs on the given path with higher S
	the attacked path has the lowest delay, causing all packets fr		N values. For
	om other paths to be		example, an attacker can replace every SN value S with a higher
	eliminated in favor of the attacked path. Once the flow from t		value S+C, where C
	he compromised path		is a constant integer. Thus, the attacker creates a false illusi
	is favored by the eliminating bridge, the flow has effectively		on that the attacked
	been hijacked by		path has the lowest delay, causing all packets from other paths
	the attacker. It is now possible for the attacker to either re		to be eliminated in
	place en route		favor of the attacked path. Once the flow from the compromised p
	packets with malicious packets, or to simply inject errors int		ath is favored by
	o the packets,		the eliminating bridge, the flow has effectively been hijacked b
	causing the packets to be dropped at their destination.</t>		y the attacker. It
	<t>Amplification - an attacker who injects packets into a flow t		is now possible for the attacker to either replace en route pack
	hat is to be		ets with malicious
	replicated will have their attack amplified through the replic		packets, or to simply inject errors into the packets, causing th
	ation process. This		e packets to be
	is no different than any attacker who injects packets that are		dropped at their destination. </dd>
	delivered through
	multicast, broadcast, or other point-to-multi-point mechanisms		<dt>Amplification: </dt>
	. </t>		<dd>An attacker who injects packets into a flow that is to be repl
	</list>		icated will have
	</t>		their attack amplified through the replication process. This is
			no different than
			any attacker who injects packets that are delivered through mult
			icast, broadcast, or
			other point-to-multi-point mechanisms. </dd>
			</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="ControllerThreat" title="Controller Plane">		<section anchor="ControllerThreat" numbered="true" toc="default">
	<section anchor="PathThreat" title="Path Choice Manipulation">		<name>Controller Plane</name>
	<section title="Control or Signaling Packet Modification">		<section anchor="PathThreat" numbered="true" toc="default">
			<name>Path Choice Manipulation</name>
			<section numbered="true" toc="default">
			<name>Control or Signaling Packet Modification</name>
	<t>An attacker can maliciously modify en route control packets in order to disrupt or		<t>An attacker can maliciously modify en route control packets in order to disrupt or
	manipulate the DetNet path/resource allocation.</t>		manipulate the DetNet path/resource allocation.</t>
	</section>		</section>
	<section title="Control or Signaling Packet Injection">		<section numbered="true" toc="default">
			<name>Control or Signaling Packet Injection</name>
	<t>An attacker can maliciously inject control packets in order to disrupt or		<t>An attacker can maliciously inject control packets in order to disrupt or
	manipulate the DetNet path/resource allocation.</t>		manipulate the DetNet path/resource allocation.</t>
	</section>		</section>
	<section title="Increased Attack Surface">		<section numbered="true" toc="default">
	<t>One of the possible consequences of a path manipulation attack		<name>Increased Attack Surface</name>
	is an increased		<t>One of the possible consequences of a Path Manipulation attack
			is an increased
	attack surface. Thus, when the attack described in the previous subsection is		attack surface. Thus, when the attack described in the previous subsection is
	implemented, it may increase the potential of other attacks to b e performed.</t>		implemented, it may increase the potential of other attacks to b e performed.</t>
	</section>		</section>
	</section>		</section>
	<section title="Compromised Controller">		<section numbered="true" toc="default">
			<name>Compromised Controller</name>
	<t>An attacker can subvert a legitimate controller (or subvert anoth er component such		<t>An attacker can subvert a legitimate controller (or subvert anoth er component such
	that it represents itself as a legitimate controller) with the res ult that the network		that it represents itself as a legitimate controller) with the res ult that the network
	nodes incorrectly believe it is authorized to instruct them. </t>		nodes incorrectly believe it is authorized to instruct them. </t>
	<t>The presence of a compromised node or controller in a DetNet is n ot a threat that		<t>The presence of a compromised node or controller in a DetNet is n ot a threat that
	arises as a result of determinism or time sensitivity; the same te chniques used to		arises as a result of determinism or time sensitivity; the same te chniques used to
	prevent or mitigate against compromised nodes in any network are e qually applicable in		prevent or mitigate against compromised nodes in any network are e qually applicable in
	the DetNet case. The act of compromising a controller may not even be within the		the DetNet case. The act of compromising a controller may not even be within the
	capabilities of our defined attacker types - in other words it may		capabilities of our defined attacker types -- in other words, it m
	not be achievable		ay not be achievable
	via packet traffic at all, whether internal or external, on-path o		via packet traffic at all, whether internal or external, on path o
	r off-path. It might		r off path. It might
	be accomplished for example by a human with physical access to the		be accomplished, for example, by a human with physical access to t
	component, who		he component, who
	could upload bogus firmware to it via a USB stick. All of this und erscores the		could upload bogus firmware to it via a USB stick. All of this und erscores the
	requirement for careful overall system security design in a DetNet , given that the		requirement for careful overall system security design in a DetNet , given that the
	effects of even one bad actor on the network can be potentially ca tastrophic. </t>		effects of even one bad actor on the network can be potentially ca tastrophic. </t>
	<t>Security concerns specific to any given controller plane technolo gy used in DetNet		<t>Security concerns specific to any given controller plane technolo gy used in DetNet
	will be addressed by the DetNet documents associated with that tec hnology. </t>		will be addressed by the DetNet documents associated with that tec hnology. </t>
	</section>		</section>
	</section>		</section>
	<section anchor="ReconnaissanceThreat" title="Reconnaissance">		<section anchor="ReconnaissanceThreat" numbered="true" toc="default">
			<name>Reconnaissance</name>
	<t>A passive eavesdropper can identify DetNet flows and then gather in formation about en		<t>A passive eavesdropper can identify DetNet flows and then gather in formation about en
	route DetNet flows, e.g., the number of DetNet flows, their bandwidt hs, their schedules,		route DetNet flows, e.g., the number of DetNet flows, their bandwidt hs, their schedules,
	or other temporal or statistical properties. The gathered informatio n can later be used		or other temporal or statistical properties. The gathered informatio n can later be used
	to invoke other attacks on some or all of the flows.</t>		to invoke other attacks on some or all of the flows.</t>
	<t>DetNet flows are typically uniquely identified by their 6-tuple, i.		<t>DetNet flows are typically uniquely identified by their 6-tuple, i.
	e. fields within the		e., fields within
	L3 or L4 header, however in some implementations the flow ID may als		the L3 or L4 header. However, in some implementations, the flow ID m
	o be augmented by		ay also be augmented
	additional per-flow attributes known to the system, e.g. above L4. F		by additional per-flow attributes known to the system, e.g., above L
	or the purpose of		4. For the purpose
	this document we assume any such additional fields used for flow ID		of this document, we assume any such additional fields used for flow
	are encrypted and/or		ID are encrypted
	integrity-protected from external attackers. Note however that exist		and/or integrity protected from external attackers. Note however tha
	ing OT protocols		t existing OT
	designed for use on dedicated secure networks may not intrinsically		protocols designed for use on dedicated secure networks may not intr
	provide such		insically provide
	protection, in which case IPsec or transport layer security mechanis		such protection, in which case IPsec or transport-layer security mec
	ms may be		hanisms may be
	needed.</t>		needed.</t>
	</section>		</section>
	<section anchor="SyncThreat" title="Time Synchronization Mechanisms">		<section anchor="SyncThreat" numbered="true" toc="default">
	<t>An attacker can use any of the attacks described in <xref target="R		<name>Time-Synchronization Mechanisms</name>
	FC7384"/> to attack		<t>An attacker can use any of the attacks described in <xref target="R
	the synchronization protocol, thus affecting the DetNet service. </t		FC7384"
	>		format="default"/> to attack the synchronization protocol, thus af
			fecting the DetNet
			service. </t>
	</section>		</section>
	</section>		</section>
	<section title="Threat Summary">
			<section numbered="true" toc="default">
			<name>Threat Summary</name>
	<t>A summary of the attacks that were discussed in this section is prese nted in <xref		<t>A summary of the attacks that were discussed in this section is prese nted in <xref
	target="ThreatSummary"/>. For each attack, the table specifies the t		target="ThreatSummary" format="default"/>. For each attack, the tabl
	ype of attackers		e specifies the type
	that may invoke the attack. In the context of this summary, the distin		of attackers that may invoke the attack. In the context of this summar
	ction between		y, the distinction
	internal and external attacks is under the assumption that a correspon		between internal and external attacks is under the assumption that a c
	ding security		orresponding
	mechanism is being used, and that the corresponding network equipment		security mechanism is being used, and that the corresponding network e
	takes part in this		quipment takes part
	mechanism. </t>		in this mechanism. </t>
	<figure align="center" anchor="ThreatSummary" title="Threat Analysis Sum
	mary">		<table anchor="ThreatSummary">
	<artwork align="left">		<name>Threat Analysis Summary</name>
	<![CDATA[		<thead>
	+-------------------------------------------+----+-----+----+-----+		<tr>
	| Attack | Attacker Type |		<th align="center" colspan="1" rowspan="3">Attack</th>
	| +----------+----------+		<th align="center" colspan="4" rowspan="1">Attacker Type</th>
	| | Internal | External |		</tr>
	| |On-P|Off-P|On-P|Off-P|		<tr>
	+-------------------------------------------+----+-----+----+-----+		<th align="center" colspan="2" rowspan="1">Internal</th>
	|Delay attack | + | | + | |		<th align="center" colspan="2" rowspan="1"> External</th>
	+-------------------------------------------+----+-----+----+-----+		</tr>
	|DetNet Flow Modification or Spoofing | + | + | | |		<tr>
	+-------------------------------------------+----+-----+----+-----+		<th align="center" colspan="1" rowspan="1">On-Path</th>
	|Inter-segment Attack | + | + | + | + |		<th align="center" colspan="1" rowspan="1">Off-Path</th>
	+-------------------------------------------+----+-----+----+-----+		<th align="center" colspan="1" rowspan="1">On-Path</th>
	|Replication: Increased Attack Surface | + | + | + | + |		<th align="center" colspan="1" rowspan="1">Off-Path</th>
	+-------------------------------------------+----+-----+----+-----+		</tr>
	|Replication-related Header Manipulation | + | | | |		</thead>
	+-------------------------------------------+----+-----+----+-----+		<tbody>
	|Path Manipulation | + | + | | |		<tr>
	+-------------------------------------------+----+-----+----+-----+		<td>Delay Attack </td>
	|Path Choice: Increased Attack Surface | + | + | + | + |		<td align="center">+</td>
	+-------------------------------------------+----+-----+----+-----+		<td/>
	|Control or Signaling Packet Modification | + | | | |		<td align="center">+</td>
	+-------------------------------------------+----+-----+----+-----+		<td/>
	|Control or Signaling Packet Injection | + | + | | |		</tr>
	+-------------------------------------------+----+-----+----+-----+		<tr>
	|Reconnaissance | + | | + | |		<td>DetNet Flow Modification or Spoofing</td>
	+-------------------------------------------+----+-----+----+-----+		<td align="center">+</td>
	|Attacks on Time Synchronization Mechanisms | + | + | + | + |		<td align="center">+</td>
	+-------------------------------------------+----+-----+----+-----+		<td/>
	]]></artwork>		<td/>
	</figure>		</tr>
			<tr>
			<td>Inter-segment Attack</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			</tr>
			<tr>
			<td>Replication: Increased Attack Surface</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			</tr>
			<tr>
			<td>Replication-Related Header Manipulation</td>
			<td align="center">+</td>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Path Manipulation </td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Path Choice: Increased Attack Surface</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			</tr>
			<tr>
			<td>Control or Signaling Packet Modification</td>
			<td align="center">+</td>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Control or Signaling Packet Injection</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Reconnaissance</td>
			<td align="center">+</td>
			<td/>
			<td align="center">+</td>
			<td/>
			</tr>
			<tr>
			<td>Attacks on Time-Synchronization Mechanisms</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			<td align="center">+</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</section>		</section>
	<!-- Section: Security Threats -->
	<section anchor="ThreatImpact" title="Security Threat Impacts">		<section anchor="ThreatImpact" numbered="true" toc="default">
			<name>Security Threat Impacts</name>
	<t>When designing security for a DetNet, as with any network, it may be pr ohibitively		<t>When designing security for a DetNet, as with any network, it may be pr ohibitively
	expensive or technically infeasible to thoroughly protect against every possible threat.		expensive or technically infeasible to thoroughly protect against every possible threat.
	Thus the security designer must be informed (for example by an applicati on domain expert		Thus, the security designer must be informed (for example, by an applica tion domain expert
	such as a product manager) regarding the relative significance of the va rious threats and		such as a product manager) regarding the relative significance of the va rious threats and
	their impact if a successful attack is carried out. In this section we p		their impact if a successful attack is carried out. In this section, we
	resent an example of		present an example
	a possible template for such a communication, culminating in a table (<x		of a possible template for such a communication, culminating in a table
	ref		(<xref
	target="ThreatIndustryMapping"/>) which lists a set of threats under c		target="ThreatIndustryMapping" format="default"/>) that lists a set of
	onsideration, and		threats under
	some values characterizing their relative impact in the context of a giv		consideration, and some values characterizing their relative impact in t
	en industry. The		he context of a
	specific threats, industries, and impact values in the table are provide		given industry. The specific threats, industries, and impact values in t
	d only as an example		he table are
	of this kind of assessment and its communication; they are not intended		provided only as an example of this kind of assessment and its communica
	to be taken		tion; they are not
	literally.</t>		intended to be taken literally.</t>
	<t>This section considers assessment of the relative impacts of the attack s described in <xref		<t>This section considers assessment of the relative impacts of the attack s described in <xref
	target="ThreatSection"/>, Security Threats. In this section, the impac ts as described		target="ThreatSection" format="default"/>. In this section, the impact s as described
	assume that the associated mitigation is not present or has failed. Miti gations are		assume that the associated mitigation is not present or has failed. Miti gations are
	discussed in <xref target="ThreatMitigation"/>, Security Threat Mitigati on. </t>		discussed in <xref target="ThreatMitigation" format="default"/>.</t>
	<t> In computer security, the impact (or consequence) of an incident can b e measured in loss		<t> In computer security, the impact (or consequence) of an incident can b e measured in loss
	of confidentiality, integrity or availability of information. In the cas		of confidentiality, integrity, or availability of information. In the ca
	e of time sensitive		se of OT or time
	or OT networks (though not to the exclusion of IT or non-time-sensitive		sensitive networks (though not to the exclusion of IT or non-time-sensit
	networks) the impact		ive networks), the
	of an exploit can also include failure or malfunction of mechanical and/		impact of an exploit can also include failure or malfunction of mechanic
	or other physical		al and/or other
	systems. </t>		physical systems. </t>
	<t>DetNet raises these stakes significantly for OT applications, particula		<t>DetNet raises these stakes significantly for OT applications, particula
	rly those which may		rly those that may
	have been designed to run in an OT-only environment and thus may not hav e been designed for		have been designed to run in an OT-only environment and thus may not hav e been designed for
	security in an IT environment with its associated components, services a nd protocols. </t>		security in an IT environment with its associated components, services, and protocols. </t>
	<t>The extent of impact of a successful vulnerability exploit varies consi derably by use case		<t>The extent of impact of a successful vulnerability exploit varies consi derably by use case
	and by industry; additional insights regarding the individual use cases		and by industry; additional insight regarding the individual use cases i
	is available from		s available from
	<xref target="RFC8578"/>, DetNet Use Cases. Each of those use cases is		"<xref target="RFC8578" format="title"/>" <xref target="RFC8578" forma
	represented in		t="default"/>. Each
	<xref target="ThreatIndustryMapping"/>, including Pro Audio, Electrica		of those use cases is represented in <xref target="ThreatIndustryMapping
	l Utilities,		" format="default"
	Industrial M2M (split into two areas, M2M Data Gathering and M2M Control		/>, including Pro Audio, Electrical Utilities, Industrial M2M (split int
	Loop), and others. </t>		o two areas: M2M
			Data Gathering and M2M Control Loop), and others. </t>
	<t>Aspects of Impact (left column) include Criticality of Failure, Effects of Failure,		<t>Aspects of Impact (left column) include Criticality of Failure, Effects of Failure,
	Recovery, and DetNet Functional Dependence. Criticality of failure summa rizes the		Recovery, and DetNet Functional Dependence. Criticality of failure summa rizes the
	seriousness of the impact. The impact of a resulting failure can affect many different		seriousness of the impact. The impact of a resulting failure can affect many different
	metrics that vary greatly in scope and severity. In order to reduce the number of variables,		metrics that vary greatly in scope and severity. In order to reduce the number of variables,
	only the following were included: Financial, Health and Safety, Effect o n a Single		only the following were included: Financial, Health and Safety, Effect o n a Single
	Organization, and Effect on Multiple Organizations. Recovery outlines ho w long it would take		Organization, and Effect on Multiple Organizations. Recovery outlines ho w long it would take
	for an affected use case to get back to its pre-failure state (Recovery		for an affected use case to get back to its pre-failure state (Recovery
	time objective,		Time Objective, RTO)
	RTO), and how much of the original service would be lost in between the		and how much of the original service would be lost in between the time o
	time of service		f service failure
	failure and recovery to original state (Recovery Point Objective, RPO).		and recovery to original state (Recovery Point Objective, RPO). DetNet d
	DetNet dependence		ependence maps how
	maps how much the following DetNet service objectives contribute to impa		much the following DetNet service objectives contribute to impact of fai
	ct of failure: Time		lure: time
	dependency, data integrity, source node integrity, availability, latency		dependency, data integrity, source node integrity, availability, and lat
	/jitter.</t>		ency/jitter.</t>
	<t>The scale of the Impact mappings is low, medium, and high. In some use		<t>The scale of the Impact mappings is low, medium, and high. In some use
	cases there may be a		cases, there may be
	multitude of specific applications in which DetNet is used. For simplici		a multitude of specific applications in which DetNet is used. For simpli
	ty this section		city, this section
	attempts to average the varied impacts of different applications. This s ection does not		attempts to average the varied impacts of different applications. This s ection does not
	address the overall risk of a certain impact which would require the lik elihood of a failure		address the overall risk of a certain impact that would require the like lihood of a failure
	happening. </t>		happening. </t>
	<t>In practice any such ratings will vary from case to case; the ratings s hown here are given		<t>In practice, any such ratings will vary from case to case; the ratings shown here are given
	as examples.</t>		as examples.</t>
	<figure align="center" anchor="ThreatIndustryMapping"
	title="Impact of Attacks by Use Case Industry">		<table anchor="ThreatIndustryMapping">
	<artwork align="left">		<name>Impact of Attacks by Use Case Industry</name>
	<![CDATA[		<thead>
	Table		<tr>
	+------------------+-----------------------------------------+-----+		<th/>
	| | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M |		<th>PRO A</th>
	| | | | | less | |Data |Ctrl |		<th>Util</th>
	+------------------+-----------------------------------------+-----+		<th>Bldg</th>
	| Criticality | Med | Hi | Low | Med | Med | Med | Med |		<th>Wireless</th>
	+------------------+-----------------------------------------+-----+		<th>Cell</th>
	| Effects		<th>M2M Data</th>
	+------------------+-----------------------------------------+-----+		<th>M2M Ctrl</th>
	| Financial | Med | Hi | Med | Med | Low | Med | Med |		</tr>
	+------------------+-----------------------------------------+-----+		</thead>
	| Health/Safety | Med | Hi | Hi | Med | Med | Med | Med |		<tbody>
	+------------------+-----------------------------------------+-----+		<tr>
	| Affects 1 org | Hi | Hi | Med | Hi | Med | Med | Med |		<td>Criticality</td>
	+------------------+-----------------------------------------+-----+		<td>Med</td>
	| Affects >1 org | Med | Hi | Low | Med | Med | Med | Med |		<td>Hi</td>
	+------------------+-----------------------------------------+-----+		<td>Low</td>
	|Recovery		<td>Med</td>
	+------------------+-----------------------------------------+-----+		<td>Med</td>
	| Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi |		<td>Med</td>
	+------------------+-----------------------------------------+-----+		<td>Med</td>
	| Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi |		</tr>
	+------------------+-----------------------------------------+-----+		<tr>
	|DetNet Dependence		<th colspan="8">Effects</th>
	+------------------+-----------------------------------------+-----+		</tr>
	| Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi |		<tr>
	+------------------+-----------------------------------------+-----+		<td>Financial</td>
	| Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi |		<td>Med</td>
	+------------------+-----------------------------------------+-----+		<td>Hi</td>
	| Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Hi |		<td>Med</td>
	+------------------+-----------------------------------------+-----+		<td>Med</td>
	| Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi |		<td>Low</td>
	+------------------+-----------------------------------------+-----+		<td>Med</td>
	| Availability | Hi | Hi | Med | Hi | Low | Hi | Hi |		<td>Med</td>
	+------------------+-----------------------------------------+-----+		</tr>
	]]></artwork>		<tr>
	</figure>		<td>Health/Safety</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Med</td>
			<td>Med</td>
			<td>Med</td>
			</tr>
			<tr>
			<td>Affects 1 org</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Med</td>
			<td>Med</td>
			</tr>
			<tr>
			<td>Affects >1 org</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Low</td>
			<td>Med</td>
			<td>Med</td>
			<td>Med</td>
			<td>Med</td>
			</tr>
			<tr>
			<th colspan="8">Recovery</th>
			</tr>
			<tr>
			<td>Recov Time Obj</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Hi</td>
			</tr>
			<tr>
			<td>Recov Point Obj</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Low</td>
			<td>Med</td>
			<td>Low</td>
			<td>Hi</td>
			<td>Hi</td>
			</tr>
			<tr>
			<th colspan="8">DetNet Dependence</th>
			</tr>
			<tr>
			<td>Time Dependence</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Low</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Low</td>
			<td>Hi</td>
			</tr>
			<tr>
			<td>Latency/Jitter</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Med</td>
			<td>Low</td>
			<td>Low</td>
			<td>Hi</td>
			</tr>
			<tr>
			<td>Data Integrity</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Low</td>
			<td>Hi</td>
			<td>Hi</td>
			</tr>
			<tr>
			<td>Src Node Integ</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Hi</td>
			</tr>
			<tr>
			<td>Availability</td>
			<td>Hi</td>
			<td>Hi</td>
			<td>Med</td>
			<td>Hi</td>
			<td>Low</td>
			<td>Hi</td>
			<td>Hi</td>
			</tr>
			</tbody>
			</table>
	<t>The rest of this section will cover impact of the different groups in m ore detail.</t>		<t>The rest of this section will cover impact of the different groups in m ore detail.</t>
	<section anchor="DelayImpact" title="Delay-Attacks">		<section anchor="DelayImpact" numbered="true" toc="default">
	<!-- <xref target="DelayThreat"/> -->		<name>Delay Attacks</name>
	<section title="Data Plane Delay Attacks">
	<t>Note that 'delay attack' also includes the possibility of a 'negati		<section numbered="true" toc="default">
	ve delay' or early		<name>Data Plane Delay Attacks</name>
			<t>Note that "Delay attack" also includes the possibility of a "negati
			ve delay" or early
	arrival of a packet, or possibly adversely changing the timestamp va lue. </t>		arrival of a packet, or possibly adversely changing the timestamp va lue. </t>
	<t> Delayed messages in a DetNet link can result in the same behavior as dropped messages		<t> Delayed messages in a DetNet link can result in the same behavior as dropped messages
	in ordinary networks, since the services attached to the DetNet flow are likely to have		in ordinary networks, since the services attached to the DetNet flow are likely to have
	strict delivery time requirements.</t>		strict delivery time requirements.</t>
	<t>For a single path scenario, disruption within the single flow is a real possibility. In		<t>For a single-path scenario, disruption within the single flow is a real possibility. In
	a multipath scenario, large delays or instabilities in one DetNet fl ow can also lead to		a multipath scenario, large delays or instabilities in one DetNet fl ow can also lead to
	increased buffer and processor resource consumption at the eliminati ng router.</t>		increased buffer and processor resource consumption at the eliminati ng router.</t>
	<t>A data-plane delay attack on a system controlling substantial movin		<t>A data plane Delay attack on a system controlling substantial movin
	g devices, for		g devices, for
	example in industrial automation, can cause physical damage. For exa		example, in industrial automation, can cause physical damage. For ex
	mple, if the network		ample, if the
	promises a bounded latency of 2ms for a flow, yet the machine receiv		network promises a bounded latency of 2 ms for a flow, yet the machi
	es it with 5ms		ne receives it with
	latency, the control loop of the machine may become unstable. </t>		5 ms latency, the control loop of the machine may become unstable. <
			/t>
	</section>		</section>
	<section title="Controller Plane Delay Attacks">
			<section numbered="true" toc="default">
			<name>Controller Plane Delay Attacks</name>
	<t>In and of itself, this is not directly a threat to the DetNet servi ce, but the effects		<t>In and of itself, this is not directly a threat to the DetNet servi ce, but the effects
	of delaying control messages can have quite adverse effects later.</ t>		of delaying control messages can have quite adverse effects later.</ t>
	<t>		<ul spacing="normal">
	<list style="symbols">		<li>Delayed teardown can lead to resource leakage, which in turn can
	<t>Delayed tear-down can lead to resource leakage, which in turn c		result in failure
	an result in failure		to allocate new DetNet flows, finally giving rise to a denial-of-s
	to allocate new DetNet flows, finally giving rise to a denial of		ervice attack.</li>
	service attack.</t>		<li>Failure to deliver, or severely delaying, controller plane messa
	<t>Failure to deliver, or severely delaying, controller plane mess		ges adding an
	ages adding an		endpoint to a multicast group will prevent the new endpoint from r
	endpoint to a multicast-group will prevent the new endpoint from		eceiving expected
	receiving expected		frames thus disrupting expected behavior.</li>
	frames thus disrupting expected behavior.</t>		<li>Delaying messages that remove an endpoint from a group can lead
	<t>Delaying messages removing an endpoint from a group can lead to		to loss of privacy,
	loss of privacy as		as the endpoint will continue to receive messages even after it is
	the endpoint will continue to receive messages even after it is		supposedly
	supposedly		removed.</li>
	removed.</t>		</ul>
	</list>
	</t>
	</section>		</section>
	</section>		</section>
	<section anchor="SpoofingImpact" title="Flow Modification and Spoofing">		<section anchor="SpoofingImpact" numbered="true" toc="default">
	<section title="Flow Modification">		<name>Flow Modification and Spoofing</name>
			<section numbered="true" toc="default">
			<name>Flow Modification</name>
	<t>If the contents of a packet header or body can be modified by the a ttacker, this can		<t>If the contents of a packet header or body can be modified by the a ttacker, this can
	cause the packet to be routed incorrectly or dropped, or the payload to be corrupted or		cause the packet to be routed incorrectly or dropped, or the payload to be corrupted or
	subtly modified. Thus, the potential impact of a modification attack includes disrupting		subtly modified. Thus, the potential impact of a Modification attack includes disrupting
	the application as well as the network equipment.</t>		the application as well as the network equipment.</t>
	</section>		</section>
	<section title="Spoofing">		<section numbered="true" toc="default">
	<section title="Dataplane Spoofing">		<name>Spoofing</name>
	<t>Spoofing dataplane messages can result in increased resource cons		<section numbered="true" toc="default">
	umptions on the		<name>Data Plane Spoofing</name>
			<t>Spoofing data plane messages can result in increased resource con
			sumption on the
	routers throughout the network as it will increase buffer usage an d processor		routers throughout the network as it will increase buffer usage an d processor
	utilization. This can lead to resource exhaustion and/or increased delay.</t>		utilization. This can lead to resource exhaustion and/or increased delay.</t>
	<t>If the attacker manages to create valid headers, the false messag es can be forwarded		<t>If the attacker manages to create valid headers, the false messag es can be forwarded
	through the network, using part of the allocated bandwidth. This i n turn can cause		through the network, using part of the allocated bandwidth. This i n turn can cause
	legitimate messages to be dropped when the resource budget has bee n exhausted.</t>		legitimate messages to be dropped when the resource budget has bee n exhausted.</t>
	<t>Finally, the endpoint will have to deal with invalid messages bei ng delivered to the		<t>Finally, the endpoint will have to deal with invalid messages bei ng delivered to the
	endpoint instead of (or in addition to) a valid message.</t>		endpoint instead of (or in addition to) a valid message.</t>
	</section>		</section>
	<section title="Controller Plane Spoofing">		<section numbered="true" toc="default">
	<t>A successful controller plane spoofing-attack will potentially ha		<name>Controller Plane Spoofing</name>
	ve adverse effects.		<t>A successful Controller Plane Spoofing attack will potentially ha
			ve adverse effects.
	It can do virtually anything from:</t>		It can do virtually anything from:</t>
	<t>		<ul spacing="normal">
	<list style="symbols">		<li>modifying existing DetNet flows by changing the available band
	<t>modifying existing DetNet flows by changing the available ban		width</li>
	dwidth</t>		<li>adding or removing endpoints from a DetNet flow</li>
	<t>add or remove endpoints from a DetNet flow</t>		<li>dropping DetNet flows completely</li>
	<t>drop DetNet flows completely</t>		<li>falsely creating new DetNet flows (exhausting the systems reso
	<t>falsely create new DetNet flows (exhaust the systems resource		urces or enabling
	s, or to enable		DetNet flows that are outside the control of the network enginee
	DetNet flows that are outside the control of the Network Engin		r)</li>
	eer)</t>		</ul>
	</list>
	</t>
	</section>		</section>
	<!-- Controller Plane Spoofing -->
	</section>		</section>
	<!-- spoofing-->
	</section>		</section>
	<!-- Flow Modification and Spoofing impact -->
	<section anchor="SegmentationImpact" title="Segmentation Attacks (injectio		<section anchor="SegmentationImpact" numbered="true" toc="default">
	n)">		<name>Segmentation Attacks (Injection)</name>
	<section title="Data Plane Segmentation">		<section numbered="true" toc="default">
			<name>Data Plane Segmentation</name>
	<t>Injection of false messages in a DetNet flow could lead to exhausti on of the available		<t>Injection of false messages in a DetNet flow could lead to exhausti on of the available
	bandwidth for that flow if the routers attribute these false message s to the resource		bandwidth for that flow if the routers attribute these false message s to the resource
	budget of that flow. </t>		budget of that flow. </t>
	<t>In a multipath scenario, injected messages will cause increased pro cessor utilization		<t>In a multipath scenario, injected messages will cause increased pro cessor utilization
	in elimination routers. If enough paths are subject to malicious inj ection, the		in elimination routers. If enough paths are subject to malicious inj ection, the
	legitimate messages can be dropped. Likewise it can cause an increas e in buffer usage.		legitimate messages can be dropped. Likewise, it can cause an increa se in buffer usage.
	In total, it will consume more resources in the routers than normal, giving rise to a		In total, it will consume more resources in the routers than normal, giving rise to a
	resource exhaustion attack on the routers.</t>		resource-exhaustion attack on the routers.</t>
	<t>If a DetNet flow is interrupted, the end application will be affect ed by what is now a		<t>If a DetNet flow is interrupted, the end application will be affect ed by what is now a
	non-deterministic flow. Note that there are many possible sources of flow interruptions,		non-deterministic flow. Note that there are many possible sources of flow interruptions,
	for example, but not limited to, such physical layer conditions as a		for example, but not limited to, such physical-layer conditions as a
	broken wire or a		broken wire or a
	radio link which is compromised by interference. </t>		radio link that is compromised by interference. </t>
	</section>		</section>
	<section title="Controller Plane Segmentation">		<section numbered="true" toc="default">
	<t> In a successful controller plane segmentation attack, control mess		<name>Controller Plane Segmentation</name>
	ages are acted on by		<t> In a successful Controller Plane Segmentation attack, control mess
			ages are acted on by
	nodes in the network, unbeknownst to the central controller or the n etwork engineer.		nodes in the network, unbeknownst to the central controller or the n etwork engineer.
	This has the potential to: </t>		This has the potential to: </t>
	<t>		<ul spacing="normal">
	<list style="symbols">		<li>create new DetNet flows (exhausting resources)</li>
	<t>create new DetNet flows (exhausting resources)</t>		<li>drop existing DetNet flows (denial of service)</li>
	<t>drop existing DetNet flows (denial of service)</t>		<li>add end stations to a multicast group (loss of privacy)</li>
	<t>add end-stations to a multicast group (loss of privacy)</t>		<li>remove end stations from a multicast group (reduction of service
	<t>remove end-stations from a multicast group (reduction of servic		)</li>
	e)</t>		<li>modify the DetNet flow attributes (affecting available bandwidth
	<t>modify the DetNet flow attributes (affecting available bandwidt		)</li>
	h)</t>		</ul>
	</list>
	</t>
	<t>If an attacker can inject control messages without the central cont roller knowing, then		<t>If an attacker can inject control messages without the central cont roller knowing, then
	one or more components in the network may get into a state that is n ot expected by the		one or more components in the network may get into a state that is n ot expected by the
	controller. At that point, if the controller initiates a command, th e effect of that		controller. At that point, if the controller initiates a command, th e effect of that
	command may not be as expected, since the target of the command may have started from a		command may not be as expected, since the target of the command may have started from a
	different initial state. </t>		different initial state. </t>
	</section>		</section>
	<!-- cp segment impact -->
	</section>		</section>
	<!-- SegmentationImpact -->
	<section anchor="ReplicationImpact" title="Replication and Elimination">		<section anchor="ReplicationImpact" numbered="true" toc="default">
	<t> The Replication and Elimination is relevant only to data plane messa		<name>Replication and Elimination</name>
	ges as controller		<t>The Replication and Elimination functions are relevant only to data p
			lane messages as controller
	plane messages are not subject to multipath routing. </t>		plane messages are not subject to multipath routing. </t>
	<section title="Increased Attack Surface">		<section numbered="true" toc="default">
			<name>Increased Attack Surface</name>
	<t>The impact of an increased attack surface is that it increases the probability that the		<t>The impact of an increased attack surface is that it increases the probability that the
	network can be exposed to an attacker. This can facilitate a wide ra nge of specific		network can be exposed to an attacker. This can facilitate a wide ra nge of specific
	attacks, and their respective impacts are discussed in other subsect ions of this		attacks, and their respective impacts are discussed in other subsect ions of this
	section.</t>		section.</t>
	</section>		</section>
	<section title="Header Manipulation at Elimination Routers">		<section numbered="true" toc="default">
			<name>Header Manipulation at Elimination Routers</name>
	<t>This attack can potentially cause DoS to the application that uses the attacked DetNet		<t>This attack can potentially cause DoS to the application that uses the attacked DetNet
	flows or to the network equipment that forwards them. Furthermore, i t can allow an		flows or to the network equipment that forwards them. Furthermore, i t can allow an
	attacker to manipulate the network paths and the behavior of the net work layer.</t>		attacker to manipulate the network paths and the behavior of the net work layer.</t>
	</section>		</section>
	</section>		</section>
	<section title="Control or Signaling Packet Modification">		<section numbered="true" toc="default">
			<name>Control or Signaling Packet Modification</name>
	<t>If control packets are subject to manipulation undetected, the networ k can be severely		<t>If control packets are subject to manipulation undetected, the networ k can be severely
	compromised.</t>		compromised.</t>
	</section>		</section>
	<section title="Control or Signaling Packet Injection">		<section numbered="true" toc="default">
			<name>Control or Signaling Packet Injection</name>
	<t>If an attacker can inject control packets undetected, the network can be severely		<t>If an attacker can inject control packets undetected, the network can be severely
	compromised.</t>		compromised.</t>
	</section>		</section>
	<section title="Reconnaissance" anchor="Reconnaissance">		<section anchor="Reconnaissance" numbered="true" toc="default">
			<name>Reconnaissance</name>
	<t> Of all the attacks, this is one of the most difficult to detect and counter. </t>		<t> Of all the attacks, this is one of the most difficult to detect and counter. </t>
	<t> An attacker can, at their leisure, observe over time various aspects of the messaging		<t> An attacker can, at their leisure, observe over time various aspects of the messaging
	and signalling, learning the intent and purpose of the traffic flows. Then at some later		and signaling, learning the intent and purpose of the traffic flows. T hen at some later
	date, possibly at an important time in the operational context, they m ight launch an		date, possibly at an important time in the operational context, they m ight launch an
	attack based on that knowledge. </t>		attack based on that knowledge. </t>
	<t> The flow-id in the header of the data plane messages gives an attack er a very reliable		<t> The flow ID in the header of the data plane messages gives an attack er a very reliable
	identifier for DetNet traffic, and this traffic has a high probability of going to		identifier for DetNet traffic, and this traffic has a high probability of going to
	lucrative targets. </t>		lucrative targets. </t>
	<t>Applications which are ported from a private OT network to the higher visibility DetNet		<t>Applications that are ported from a private OT network to the higher visibility DetNet
	environment may need to be adapted to limit distinctive flow propertie s that could make		environment may need to be adapted to limit distinctive flow propertie s that could make
	them susceptible to reconnaissance. </t>		them susceptible to reconnaissance. </t>
	</section>		</section>
	<section title="Attacks on Time Synchronization Mechanisms">		<section numbered="true" toc="default">
	<t>DetNet relies on an underlying time synchronization mechanism, and th		<name>Attacks on Time-Synchronization Mechanisms</name>
	erefore a		<t>DetNet relies on an underlying time-synchronization mechanism; theref
	compromised synchronization mechanism may cause DetNet nodes to malfun		ore, a compromised
	ction. Specifically,		synchronization mechanism may cause DetNet nodes to malfunction. Speci
	DetNet flows may fail to meet their latency requirements and determini		fically, DetNet
	stic behavior, thus		flows may fail to meet their latency requirements and deterministic be
	causing DoS to DetNet applications. </t>		havior, thus causing
			DoS to DetNet applications. </t>
	</section>		</section>
	<section title="Attacks on Path Choice" anchor="PathChoiceImpact">		<section anchor="PathChoiceImpact" numbered="true" toc="default">
	<t>This is covered in part in <xref target="SegmentationImpact"/>, Segme		<name>Attacks on Path Choice</name>
	ntation Attacks, and		<t>This is covered in part in <xref target="SegmentationImpact" format="
	as with Replication and Elimination ( <xref target="ReplicationImpact"		default"/> (<xref
	/>), this is		target="SegmentationImpact" format="title"/>) and, as with Replicati
	relevant for DataPlane messages. </t>		on and Elimination
			(see <xref target="ReplicationImpact" format="default"/>), this is rel
			evant for data plane
			messages. </t>
	</section>		</section>
	</section>		</section>
	<!-- Section: Security Threat Impacts-->
	<section anchor="ThreatMitigation" title="Security Threat Mitigation">		<section anchor="ThreatMitigation" numbered="true" toc="default">
			<name>Security Threat Mitigation</name>
	<t>This section describes a set of measures that can be taken to mitigate the attacks		<t>This section describes a set of measures that can be taken to mitigate the attacks
	described in <xref target="ThreatSection"/>, Security Threats. These mit igations should be		described in <xref target="ThreatSection" format="default"/>. These miti gations should be
	viewed as a set of tools, any of which can be used individually or in co ncert. The DetNet		viewed as a set of tools, any of which can be used individually or in co ncert. The DetNet
	component and/or system and/or application designer can apply these tool		component and/or system and/or application designer can apply these tool
	s, as necessary		s as necessary based
	based on a system-specific threat analysis. </t>		on a system-specific threat analysis. </t>
	<t>Some of the technology-specific security considerations and mitigation approaches are		<t>Some of the technology-specific security considerations and mitigation approaches are
	further discussed in the DetNet data plane solution documents, such as <		further discussed in DetNet data plane solution documents, such as <xref
	xref		target="RFC8938"
	target="RFC8938"/>, <xref target="RFC8939"/>, <xref target="RFC8964"/>		format="default"/>, <xref target="RFC8939" format="default"/>, <xref t
	, <xref		arget="RFC8964"
	target="I-D.ietf-detnet-mpls-over-udp-ip"/>, and <xref		format="default"/>, <xref target="RFC9025" format="default"/>, and <xr
	target="I-D.ietf-detnet-ip-over-mpls"/>. </t>		ef target="RFC9056"
	<section title="Path Redundancy">		format="default"/>. </t>
	<t>Description <list hangIndent="10" style="empty">		<section numbered="true" toc="default">
	<t>A DetNet flow that can be forwarded simultaneously over multiple		<name>Path Redundancy</name>
	paths. Packet		<dl>
	replication and elimination <xref target="RFC8655"/> provides resi
	liency to dropped or		<dt>Description: </dt>
	delayed packets. This redundancy improves the robustness to failur		<dd>
	es and to on-path		<t>Path redundancy is a DetNet flow that can be forwarded simultaneo
	attacks. Note: At the time of this writing, PREOF is not defined f		usly over multiple
	or the IP data		paths. Packet Replication and Elimination <xref target="RFC8655" f
	plane. </t>		ormat="default"/>
	</list>		provide resiliency to dropped or delayed packets. This redundancy
	</t>		improves the
	<t>Related attacks <list hangIndent="10" style="empty">		robustness to failures and to on-path attacks. </t>
			<aside>
			<t> Note: At the time of this writing, PREOF is not defined for th
			e IP data plane.
			</t>
			</aside>
			</dd>
			<dt>Related attacks: </dt>
			<dd>
	<t>Path redundancy can be used to mitigate various on-path attacks, including attacks		<t>Path redundancy can be used to mitigate various on-path attacks, including attacks
	described in <xref target="DelayThreat"/>, <xref target="Modificat		described in Sections <xref target="DelayThreat" format="counter"/
	ionThreat"/>, <xref		>, <xref
	target="SegmentThreat"/>, and <xref target="SyncThreat"/>. Howev		target="ModificationThreat" format="counter"/>, <xref target="Se
	er it is also		gmentThreat"
	possible that multiple paths may make it more difficult to locate		format="counter"/>, and <xref target="SyncThreat" format="counte
	the source of an		r"/>. However, it is
	on-path attacker. </t>		also possible that multiple paths may make it more difficult to lo
	<t>A delay modulation attack could result in extensively exercising		cate the source of
	parts of the code		an on-path attacker.</t>
	that wouldn't normally be extensively exercised and thus might exp
	ose flaws in the		<t>A Delay Modulation attack could result in extensively exercising otherwise
	system that might otherwise not be exposed. </t>		unused code paths to expose hidden flaws. Subtle race conditions and memory
	</list>		allocation bugs in error-handling paths are classic examples of this.
	</t>		</t>
			</dd>
			</dl>
	</section>		</section>
	<section anchor="IntegritySection" title="Integrity Protection">		<section anchor="IntegritySection" numbered="true" toc="default">
	<t>Description <list hangIndent="10" style="empty">
	<t>Integrity Protection in the scope of DetNet is the ability to det		<name>Integrity Protection</name>
	ect if a packet
			<dl>
			<dt>Description: </dt>
			<dd>
			<t>Integrity protection in the scope of DetNet is the ability to det
			ect if a packet
	header has been modified (maliciously or otherwise) and if so, tak e some appropriate		header has been modified (maliciously or otherwise) and if so, tak e some appropriate
	action (as discussed in <xref target="DpaMitigation"/>). The decis		action (as discussed in <xref target="DpaMitigation" format="defau
	ion on where in the		lt"/>). The decision
	network to apply integrity protection is part of the DetNet system		on where in the network to apply integrity protection is part of t
	design, and the		he DetNet system
	implementation of the protection method itself is a part of a DetN		design, and the implementation of the protection method itself is
	et component		a part of a DetNet
	design.</t>		component design.</t>
	<t>The most common technique for detecting header modification is th e use of a Message		<t>The most common technique for detecting header modification is th e use of a Message
	Authentication Code (MAC) (for examples see <xref target="Technolo		Authentication Code (MAC) (see <xref target="TechnologySpecificThr
	gySpecificThreats"		eats"
	/>). The MAC can be distributed either in-line (included in the sa		format="default"/> for examples). The MAC can be distributed eit
	me packet) or via a		her in line
	side channel. Of these, the in-line method is generally preferred		(included in the same packet) or via a side channel. Of these, the
	due to the low		in-line method is
	latency that may be required on DetNet flows and the relative comp		generally preferred due to the low latency that may be required on
	lexity and		DetNet flows and
	computational overhead of a sideband approach. </t>		the relative complexity and computational overhead of a sideband a
			pproach. </t>
	<t> There are different levels of security available for integrity p rotection, ranging		<t> There are different levels of security available for integrity p rotection, ranging
	from the basic ability to detect if a header has been corrupted in transit (no		from the basic ability to detect if a header has been corrupted in transit (no
	malicious attack) to stopping a skilled and determined attacker ca pable of both subtly		malicious attack) to stopping a skilled and determined attacker ca pable of both subtly
	modifying fields in the headers as well as updating an unkeyed che cksum. Common for		modifying fields in the headers as well as updating an unkeyed che cksum. Common for
	all are the 2 steps that need to be performed in both ends. The fi rst is computing the		all are the 2 steps that need to be performed in both ends. The fi rst is computing the
	checksum or MAC. The corresponding verification step must perform the same steps		checksum or MAC. The corresponding verification step must perform the same steps
	before comparing the provided with the computed value. Only then c an the receiver be		before comparing the provided with the computed value. Only then c an the receiver be
	reasonably sure that the header is authentic. </t>		reasonably sure that the header is authentic.</t>
	<t> The most basic protection mechanism consists of computing a simp le checksum of the		<t> The most basic protection mechanism consists of computing a simp le checksum of the
	header fields and provide it to the next entity in the packets pat		header fields and providing it to the next entity in the packets p
	h for verification.		ath for
	Using a MAC combined with a secret key provides the best protectio		verification. Using a MAC combined with a secret key provides the
	n against		best protection
	modification and replication attacks (see <xref target="Modificati		against Modification and Replication attacks (see Sections <xref
	onThreat"/> and		target="ModificationThreat" format="counter"/> and <xref target=
	<xref target="ReplicationThreat"/>). This MAC usage needs to be		"ReplicationThreat"
	part of a security		format="counter"/>). This MAC usage needs to be part of a securi
	association that is established and managed by a security associat		ty association that
	ion protocol (such		is established and managed by a security association protocol (suc
	as IKEv2 for IPsec security associations). Integrity protection in		h as IKEv2 for IPsec
	the controller		security associations). Integrity protection in the controller pla
	plane is discussed in <xref target="ControllerProtectSection"/>. T		ne is discussed in
	he secret key,		<xref target="ControllerProtectSection" format="default"/>. The
	regardless of MAC used, must be protected from falling into the ha		secret key,
	nds of unauthorized		regardless of the MAC used, must be protected from falling into th
	users. Once key management becomes a topic, it is important to und		e hands of
	erstand that this is		unauthorized users. Once key management becomes a topic, it is imp
	a delicate process and should not be undertaken lightly. BCP 107 <		ortant to understand
	xref		that this is a delicate process and should not be undertaken light
	target="RFC4107"/> provides best practices in this regard.</t>		ly. BCP 107 <xref
			target="BCP107" format="default"/> provides best practices in th
			is regard.</t>
	<t> DetNet system and/or component designers need to be aware of the se distinctions and		<t> DetNet system and/or component designers need to be aware of the se distinctions and
	enforce appropriate integrity protection mechanisms as needed base		enforce appropriate integrity-protection mechanisms as needed base
	d on a threat		d on a threat
	analysis. Note that adding integrity protection mechanisms may int		analysis. Note that adding integrity-protection mechanisms may int
	roduce latency, thus		roduce latency;
	many of the same considerations in <xref target="EncryptionConside		thus, many of the same considerations in <xref target="EncryptionC
	rations"/> also		onsiderations"
	apply here. </t>		format="default"/> also apply here.</t>
	</list>		</dd>
	</t>
	<t>Packet Sequence Number Integrity Considerations <list hangIndent="10"		<dt>Packet Sequence Number Integrity Considerations: </dt>
	style="empty">		<dd>
	<t>The use of PREOF in a DetNet implementation implies the use of a sequence number for		<t>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 component t hat adds the		each packet. There is a trust relationship between the component t hat adds the
	sequence number and the component that removes the sequence number . The sequence		sequence number and the component that removes the sequence number . The sequence
	number may be end-to-end source to destination, or may be added/de leted by network		number may be end-to-end source to destination, or it may be added /deleted by network
	edge components. The adder and remover(s) have the trust relations hip because they are		edge components. The adder and remover(s) have the trust relations hip because they are
	the ones that ensure that the sequence numbers are not modifiable. Thus, sequence		the ones that ensure that the sequence numbers are not modifiable. Thus, sequence
	numbers can be protected by using authenticated encryption, or by a MAC without using		numbers can be protected by using authenticated encryption or by a MAC without using
	encryption. Between the adder and remover there may or may not be replication and		encryption. Between the adder and remover there may or may not be replication and
	elimination functions. The elimination functions must be able to s ee the sequence		elimination functions. The elimination functions must be able to s ee the sequence
	numbers. Therefore, if encryption is done between adders and remov ers it must not		numbers. Therefore, if encryption is done between adders and remov ers, it must not
	obscure the sequence number. If the sequence removers and the elim inators are in the		obscure the sequence number. If the sequence removers and the elim inators are in the
	same physical component, it may be possible to obscure the sequenc		same physical component, it may be possible to obscure the sequenc
	e number, however		e number; however,
	that is a layer violation, and is not recommended practice. Note:		that is a layer violation and is not recommended practice. </t>
	At the time of this		<aside>
	writing, PREOF is not defined for the IP data plane.</t>		<t> Note: At the time of this writing, PREOF is not defined for th
	</list>		e IP data plane.
	</t>		</t>
	<t>Related attacks <list hangIndent="10" style="empty">		</aside>
			</dd>
			<dt>Related attacks: </dt>
			<dd>
	<t>Integrity protection mitigates attacks related to modification an d tampering,		<t>Integrity protection mitigates attacks related to modification an d tampering,
	including the attacks described in <xref target="ModificationThrea		including the attacks described in Sections <xref target="Modifica
	t"/> and <xref		tionThreat"
	target="ReplicationThreat"/>. </t>		format="counter"/> and <xref target="ReplicationThreat" format="
	</list>		counter"/>.</t>
	</t>		</dd>
			</dl>
	</section>		</section>
	<section title="DetNet Node Authentication">		<section numbered="true" toc="default">
	<t>Description <list hangIndent="10" style="empty">		<name>DetNet Node Authentication</name>
	<t>Authentication verifies the identity of DetNet nodes (including D
	etNet Controller		<dl>
	Plane nodes), and this enables mitigation of spoofing attacks. Whi
	le integrity		<dt>Description:</dt>
	protection ( <xref target="IntegritySection"/>) prevents intermedi		<dd>Authentication verifies the identity of DetNet nodes (including De
	ate nodes from		tNet Controller
	modifying information, authentication can provide traffic origin v		Plane nodes), and this enables mitigation of Spoofing attacks. While
	erification, i.e. to		integrity
	verify that each packet in a DetNet flow is from a known source. A		protection (<xref target="IntegritySection" format="default"/>) prev
	lthough node		ents intermediate
	authentication and integrity protection are two different goals of		nodes from modifying information, authentication can provide traffic
	a security		origin
	protocol, in most cases a common protocol (such as IPsec <xref tar		verification, i.e., to verify that each packet in a DetNet flow is f
	get="RFC4301"/> or		rom a known source.
	MACsec <xref target="IEEE802.1AE-2018"/>) is used for achieving bo		Although node authentication and integrity protection are two differ
	th purposes.</t>		ent goals of a
	</list>		security protocol, in most cases, a common protocol (such as IPsec <
	</t>		xref
	<t>Related attacks <list hangIndent="10" style="empty">		target="RFC4301" format="default"/> or MACsec <xref target="IEEE80
	<t>DetNet node authentication is used to mitigate attacks related to		2.1AE-2018"
	spoofing, including		format="default"/>) is used for achieving both purposes. </dd>
	the attacks of <xref target="ModificationThreat"/>, and <xref
	target="ReplicationThreat"/>. </t>		<dt>Related attacks: </dt>
	</list>		<dd>DetNet node authentication is used to mitigate attacks related to
	</t>		spoofing, including
			the attacks of Sections <xref target="ModificationThreat" format="co
			unter"/> and <xref
			target="ReplicationThreat" format="counter"/>. </dd>
			</dl>
	</section>		</section>
	<section title="Dummy Traffic Insertion">		<section numbered="true" toc="default">
	<t>Description <list hangIndent="10" style="empty">		<name>Synthetic Traffic Insertion</name>
	<t>With some queueing methods such as <xref target="IEEE802.1Qch-201
	7"/> it is possible		<dl>
	to introduce dummy traffic in order to regularize the timing of pa
	cket transmission.		<dt>Description: </dt>
	This will subsequently reduce the value of passive monitoring from		<dd>With some queuing methods such as <xref
	internal threats		target="IEEE802.1Qch-2017" format="default"/>, it is possible to
	(see <xref target="ThreatSection"/>) as it will be much more diffi		introduce synthetic traffic in order to regularize the timing of
	cult to associate		packet transmission. (Synthetic traffic typically consists of randomly
	discrete events with particular network packets. </t>		generated packets injected in the network to mask observable
	</list>		transmission patterns in the flows, which may allow an attacker to
	</t>		gain insight into the content of the flows). This can subsequently
	<t>Related attacks <list hangIndent="10" style="empty">		reduce the value of passive monitoring from internal threats (see
	<t>Removing distinctive temporal properties of individual packets or		<xref target="ThreatSection" format="default"/>) as it will be much
	flows can be used		more difficult to associate discrete events with particular network
	to mitigate against reconnaissance attacks <xref target="Reconnais		packets. </dd>
	sanceThreat"/>. For
	example, dummy traffic can be used to synthetically maintain const		<dt>Related attacks: </dt>
	ant traffic rate		<dd>Removing distinctive temporal properties of individual packets
	even when no user data is transmitted, thus making it difficult to		or flows can be used to mitigate against reconnaissance attacks
	collect information		(<xref target="ReconnaissanceThreat" format="default"/>). For
	about the times at which users are active, and the times at which		example, synthetic traffic can be used to maintain
	DetNet flows are		constant traffic rate even when no user data is transmitted, thus
	added or removed.</t>		making it difficult to collect information about the times at which
	</list>		users are active and the times at which DetNet flows are added or
	</t>		removed. </dd>
	<t>Traffic Insertion Challenges <list hangIndent="10" style="empty">
	<t>Once an attacker is able to monitor the frames traversing a netwo		<dt>Traffic Insertion Challenges: </dt>
	rk to such a degree		<dd>
	that they can differentiate between best-effort traffic and traffi		<t>Once an attacker is able to monitor the frames traversing a
	c belonging to a		network to such a degree that they can differentiate between
	specific DetNet flow, it becomes difficult to not reveal to the at		best-effort traffic and traffic belonging to a specific DetNet
	tacker whether a		flow, it becomes difficult to not reveal to the attacker whether a
	given frame is valid traffic or an inserted frame. Thus, having th		given frame is valid traffic or an inserted frame. Thus, having
	e DetNet components		the DetNet components generate and remove the synthetic traffic may
	generate and remove the dummy traffic may or may not be a viable o		or
	ption, unless		may not be a viable option unless certain challenges are solved;
	certain challenges are solved; for example, but not limited to:</t		for example, but not limited to:</t>
	>
	</list>		<ul>
	<list style="symbols">
	<t>Inserted traffic must be indistinguishable from valid stream traf		<li>Inserted traffic must be indistinguishable from valid stream t
	fic from the		raffic from the
	viewpoint of the attacker.</t>		viewpoint of the attacker. </li>
	<t>DetNet components must be able to safely identify and remove all
	inserted traffic		<li>DetNet components must be able to safely identify and remove
	(and only inserted traffic).</t>		all inserted traffic (and only inserted traffic). </li>
	<t>The controller plane must manage where to insert and remove dummy
	traffic, but this		<li>
	information must not be revealed to an attacker.</t>		<t>The controller plane must manage where to insert and remove
	</list>		synthetic traffic, but this information must not be revealed to
	<list hangIndent="10" style="empty">		an
	<t>An alternative design is to have the insertion and removal of dum		attacker. </t>
	my traffic be		<t>An alternative design is to have the insertion and removal
	performed at the application layer, rather than by the DetNet itse		of synthetic traffic be performed at the application layer rathe
	lf. Further		r
	discussions and reading about how sRTP handles this can be found i		than by the DetNet itself. For example, the use of RTP padding
	n <xref		to reduce information leakage from variable-bit-rate audio
	target="RFC6562"/></t>		transmission via the Secure Real-time Transport Protocol
	</list>		(SRTP) is discussed in <xref target="RFC6562"
	</t>		format="default"/>. </t>
			</li>
			</ul>
			</dd>
			</dl>
	</section>		</section>
			<section numbered="true" toc="default">
			<name>Encryption</name>
			<dl>
			<dt>Description: </dt>
			<dd>
			<t>Reconnaissance attacks (<xref target="ReconnaissanceThreat" forma
			t="default"/>) can
			be mitigated to some extent through the use of encryption, thereby
			preventing the
			attacker from accessing the packet header or contents. Specific en
			cryption protocols
			will depend on the lower layers that DetNet is forwarded over. For
			example, IP flows
			may be forwarded over IPsec <xref target="RFC4301" format="default
			"/>, and Ethernet
			flows may be secured using MACsec <xref target="IEEE802.1AE-2018"
			format="default"/>. </t>
	<section title="Encryption">
	<t>Description <list hangIndent="10" style="empty">
	<t>Reconnaissance attacks (<xref target="ReconnaissanceThreat"/>) ca
	n be mitigated to
	some extent through the use of encryption, thereby preventing the
	attacker from
	accessing the packet header or contents. Specific encryption proto
	cols will depend on
	the lower layers that DetNet is forwarded over. For example, IP fl
	ows may be forwarded
	over IPsec <xref target="RFC4301"/>, and Ethernet flows may be sec
	ured using MACsec
	<xref target="IEEE802.1AE-2018"/>.</t>
	<t>However, despite the use of encryption, a reconnaissance attack c an provide the		<t>However, despite the use of encryption, a reconnaissance attack c an provide the
	attacker with insight into the network, even without visibility in to the packet. For		attacker with insight into the network, even without visibility in to the packet. For
	example, an attacker can observe which nodes are communicating wit h which other nodes,		example, an attacker can observe which nodes are communicating wit h which other nodes,
	including when, how often, and with how much data. In addition, th e timing of packets		including when, how often, and with how much data. In addition, th e timing of packets
	may be correlated in time with external events such as action of a n external device.		may be correlated in time with external events such as action of a n external device.
	Such information may be used by the attacker, for example in mappi		Such information may be used by the attacker, for example, in mapp
	ng out specific		ing out specific
	targets for a different type of attack at a different time.</t>		targets for a different type of attack at a different time. </t>
	<t>DetNet nodes do not have any need to inspect the payload of any D etNet packets,		<t>DetNet nodes do not have any need to inspect the payload of any D etNet packets,
	making them data-agnostic. This means that end-to-end encryption a t the application		making them data agnostic. This means that end-to-end encryption a t the application
	layer is an acceptable way to protect user data. </t>		layer is an acceptable way to protect user data. </t>
	<t>Note that reconnaissance is a threat that is not specific to DetN		<t>Note that reconnaissance is a threat that is not specific to DetN
	et flows, and		et flows; therefore,
	therefore reconnaissance mitigation will typically be analyzed and		reconnaissance mitigation will typically be analyzed and provided
	provided by a		by a network
	network operator regardless of whether DetNet flows are deployed.		operator regardless of whether DetNet flows are deployed. Thus, en
	Thus, encryption		cryption
	requirements will typically not be defined in DetNet technology-sp ecific		requirements will typically not be defined in DetNet technology-sp ecific
	specifications, but considerations of using DetNet in encrypted en vironments will be		specifications, but considerations of using DetNet in encrypted en vironments will be
	discussed in these specifications. For example, Section 5.1.2.3. o		discussed in these specifications. For example, <xref target="RFC8
	f <xref		939"
	target="RFC8939"/> discusses flow identification of DetNet flows		sectionFormat="of" section="5.1.2.3" format="default"/> discusse
	running over		s flow
	IPsec.</t>		identification of DetNet flows running over IPsec. </t>
	</list>		</dd>
	</t>
	<t>Related attacks <list hangIndent="10" style="empty">		<dt>Related attacks: </dt>
	<t>As noted above, encryption can be used to mitigate reconnaissance		<dd>As noted above, encryption can be used to mitigate reconnaissance
	attacks ( <xref		attacks (<xref
	target="ReconnaissanceThreat"/>). However, for a DetNet to provi		target="ReconnaissanceThreat" format="default"/>). However, for a
	de differentiated		DetNet to provide
	quality of service on a flow-by-flow basis, the network must be ab		differentiated quality of service on a flow-by-flow basis, the netwo
	le to identify the		rk must be able to
	flows individually. This implies that in a reconnaissance attack t		identify the flows individually. This implies that in a reconnaissan
	he attacker may also		ce attack, the
	be able to track individual flows to learn more about the system.		attacker may also be able to track individual flows to learn more ab
	</t>		out the system. </dd>
	</list>
	</t>		</dl>
	<section anchor="EncryptionConsiderations" title="Encryption Considerati
	ons for DetNet">		<section anchor="EncryptionConsiderations" numbered="true" toc="default"
	<t>Any compute time which is required for encryption and decryption pr		>
	ocessing ('crypto')		<name>Encryption Considerations for DetNet</name>
	must be included in the flow latency calculations. Thus, crypto algo		<t>Any compute time that is required for encryption and decryption pro
	rithms used in a		cessing ("crypto")
			must be included in the flow latency calculations. Thus, cryptograph
			ic algorithms used in a
	DetNet must have bounded worst-case execution times, and these value s must be used in		DetNet must have bounded worst-case execution times, and these value s must be used in
	the latency calculations. Fortunately, encryption and decryption ope rations typically		the latency calculations. Fortunately, encryption and decryption ope rations typically
	are designed to have constant execution times, in order to avoid sid		are designed to have constant execution times in order to avoid side
	e channel leakage. </t>		channel leakage. </t>
	<t>Some crypto algorithms are symmetric in encode/decode time (such as		<t>Some cryptographic algorithms are symmetric in encode/decode time (
	AES) and others are		such as AES), and others
	asymmetric (such as public key algorithms). There are advantages and		are asymmetric (such as public key algorithms). There are advantages
	disadvantages to		and disadvantages
	the use of either type in a given DetNet context. The discussion in		to the use of either type in a given DetNet context. The discussion
	this document		in this document
	relates to the timing implications of crypto for DetNet; it is assum ed that integrity		relates to the timing implications of crypto for DetNet; it is assum ed that integrity
	considerations are covered elsewhere in the literature.</t>		considerations are covered elsewhere in the literature.</t>
	<t>Asymmetrical crypto is typically not used in networks on a packet-b y-packet basis due		<t>Asymmetrical crypto is typically not used in networks on a packet-b y-packet basis due
	to its computational cost. For example, if only endpoint checks or c hecks at a small		to its computational cost. For example, if only endpoint checks or c hecks at a small
	number of intermediate points are required, asymmetric crypto can be used to		number of intermediate points are required, asymmetric crypto can be used to
	authenticate distribution or exchange of a secret symmetric crypto k ey; a successful		authenticate distribution or exchange of a secret symmetric crypto k ey; a successful
	check based on that key will provide traffic origin verification, as		check based on that key will provide traffic origin verification as
	long as the key is		long as the key is
	kept secret by the participants. TLS (v1.3 <xref target="RFC8446"/>,		kept secret by the participants. TLS (v1.3 <xref target="RFC8446" fo
	in particular		rmat="default"/>, in
	section 4.1 "Key exchange") and IKEv2 <xref target="RFC6071"/>) are		particular, Section <xref target="RFC8446" sectionFormat="bare" sect
	examples of this for		ion="4.1">"Key
	endpoint checks.</t>		Exchange Messages"</xref>) and IKEv2 <xref target="RFC6071" format
	<t>However, if secret symmetric keys are used for this purpose the key		="default"/> are
	must be given to		examples of this for endpoint checks.</t>
			<t>However, if secret symmetric keys are used for this purpose, the ke
			y must be given to
	all relays, which increases the probability of a secret key being le aked. Also, if any		all relays, which increases the probability of a secret key being le aked. Also, if any
	relay is compromised or faulty then it may inject traffic into the f low. Group key		relay is compromised or faulty, then it may inject traffic into the flow. Group key
	management protocols can be used to automate management of such symm etric keys; for an		management protocols can be used to automate management of such symm etric keys; for an
	example in the context of IPsec, see <xref target="I-D.ietf-ipsecme-		example in the context of IPsec, see <xref target="I-D.ietf-ipsecme-
	g-ikev2"/>. </t>		g-ikev2"
			format="default"/>. </t>
	<t>Alternatively, asymmetric crypto can provide traffic origin verific ation at every		<t>Alternatively, asymmetric crypto can provide traffic origin verific ation at every
	intermediate node. For example, a DetNet flow can be associated with an (asymmetric)		intermediate node. For example, a DetNet flow can be associated with an (asymmetric)
	keypair, such that the private key is available to the source of the flow and the public		keypair, such that the private key is available to the source of the flow and the public
	key is distributed with the flow information, allowing verification at every node for		key is distributed with the flow information, allowing verification at every node for
	every packet. However, this is more computationally expensive. </t>		every packet. However, this is more computationally expensive. </t>
	<t>In either case, origin verification also requires replay detection as part of the		<t>In either case, origin verification also requires replay detection as part of the
	security protocol to prevent an attacker from recording and resendin g traffic, e.g., as		security protocol to prevent an attacker from recording and resendin g traffic, e.g., as
	a denial of service attack on flow forwarding resources.</t>		a denial-of-service attack on flow forwarding resources.</t>
	<t>In the general case, cryptographic hygiene requires the generation of new keys during		<t>In the general case, cryptographic hygiene requires the generation of new keys during
	the lifetime of an encrypted flow (e.g. see <xref target="RFC4253"/>		the lifetime of an encrypted flow (e.g., see <xref target="RFC4253"
	section 9), and any		sectionFormat="of"
	such key generation (or key exchange) requires additional computing		section="9" format="default"/>), and any such key generation (or k
	time which must be		ey exchange)
	accounted for in the latency calculations for that flow. For modern		requires additional computing time, which must be accounted for in t
	ECDH (Elliptical		he latency
	Curve Diffie-Hellman) key-exchange operations (such as x25519, see <		calculations for that flow. For modern ECDH (Elliptical Curve Diffie
	xref		-Hellman)
	target="RFC7748"/>) these operations can be performed in constant		key-exchange operations (such as x25519 <xref target="RFC7748" forma
	(predictable) time,		t="default"/>),
	however this is not universally true (for example for legacy RSA key		these operations can be performed in constant (predictable) time; ho
	exchange, <xref		wever, this is not
	target="RFC4432"/>). Thus implementers should be aware of the time		universally true (for example, for legacy RSA key exchange <xref tar
	properties of these		get="RFC4432"
	algorithms and avoid algorithms that make constant-time implementati		format="default"/>). Thus, implementers should be aware of the tim
	on difficult or		e properties of
	impossible.</t>		these algorithms and avoid algorithms that make constant-time implem
	</section>		entation difficult
	</section>		or impossible.</t>
	<section anchor="ControllerProtectSection" title="Control and Signaling Me		</section>
	ssage Protection">		</section>
	<t>Description <list hangIndent="10" style="empty">		<section anchor="ControllerProtectSection" numbered="true" toc="default">
	<t>Control and signaling messages can be protected through the use o		<name>Control and Signaling Message Protection</name>
	f any or all of
	encryption, authentication, and integrity protection mechanisms. C		<dl>
	ompared with
	data-flows, the timing constraints for controller and signaling me		<dt>Description: </dt>
	ssages may be less
	strict, and the number of such packets may be fewer. If that is th		<dd>Control and signaling messages can be protected through the use of
	e case in a given		any or all of
	application, then it may enable the use of asymmetric cryptography		encryption, authentication, and integrity-protection mechanisms. Com
	for signing of both		pared with data
	payload and headers for such messages, as well as encrypting the p		flows, the timing constraints for controller and signaling messages
	ayload. Given that a		may be less strict,
	DetNet is managed by a central controller, the use of a shared pub		and the number of such packets may be fewer. If that is the case in
	lic key approach for		a given application,
	these processes is well-proven. This is further discussed in <xref		then it may enable the use of asymmetric cryptography for the signin
	target="EncryptionConsiderations"/>. </t>		g of both payload
	</list>		and headers for such messages, as well as encrypting the payload. Gi
	</t>		ven that a DetNet is
	<t>Related attacks <list hangIndent="10" style="empty">		managed by a central controller, the use of a shared public key appr
	<t>These mechanisms can be used to mitigate various attacks on the c		oach for these
	ontroller plane, as		processes is well proven. This is further discussed in <xref
	described in <xref target="ControllerThreat"/>, <xref target="Sync		target="EncryptionConsiderations" format="default"/>. </dd>
	Threat"/> and <xref
	target="PathThreat"/>. </t>		<dt>Related attacks: </dt>
	</list>		<dd>These mechanisms can be used to mitigate various attacks on the co
	</t>		ntroller plane, as
			described in Sections <xref target="ControllerThreat" format="counte
			r"/>, <xref
			target="SyncThreat" format="counter"/>, and <xref target="PathThre
			at" format="counter"
			/>. </dd>
			</dl>
	</section>		</section>
	<section anchor="DpaMitigation" title="Dynamic Performance Analytics">		<section anchor="DpaMitigation" numbered="true" toc="default">
	<t>Description <list hangIndent="10" style="empty">
	<t>Incorporating Dynamic Performance Analytics ("DPA") implies that		<name>Dynamic Performance Analytics</name>
	the DetNet design
			<dl>
			<dt>Description: </dt>
			<dd>
			<t>Incorporating Dynamic Performance Analytics (DPA) implies that th
			e DetNet design
	includes a performance monitoring system to validate that timing g uarantees are being		includes a performance monitoring system to validate that timing g uarantees are being
	met and to detect timing violations or other anomalies that may be the symptom of a		met and to detect timing violations or other anomalies that may be the symptom of a
	security attack or system malfunction. If this monitoring system d etects unexpected		security attack or system malfunction. If this monitoring system d etects unexpected
	behavior, it must then cause action to be initiated to address the situation in an		behavior, it must then cause action to be initiated to address the situation in an
	appropriate and timely manner, either at the data plane or control		appropriate and timely manner, either at the data plane or control
	ler plane, or both		ler plane or both in
	in concert. </t>		concert. </t>
	<t>The overall DPA system can thus be decomposed into the "detection " and "notification"		<t>The overall DPA system can thus be decomposed into the "detection " and "notification"
	functions. Although the time-specific DPA performance indicators a nd their		functions. Although the time-specific DPA performance indicators a nd their
	implementation will likely be specific to a given DetNet, and as s uch are nascent		implementation will likely be specific to a given DetNet, and as s uch are nascent
	technology at the time of this writing, DPA is commonly used in ex isting networks so		technology at the time of this writing, DPA is commonly used in ex isting networks so
	we can make some observations on how such a system might be implem ented for a DetNet,		we can make some observations on how such a system might be implem ented for a DetNet
	given that it would need to be adapted to address the time-specifi c performance		given that it would need to be adapted to address the time-specifi c performance
	indicators. </t>		indicators. </t>
	</list>
	</t>		</dd>
	<t>Detection Mechanisms <list hangIndent="10" style="empty">
			<dt>Detection Mechanisms: </dt>
			<dd>
	<t>Measurement of timing performance can be done via "passive" or "a ctive" monitoring,		<t>Measurement of timing performance can be done via "passive" or "a ctive" monitoring,
	as discussed below. </t>		as discussed below. </t>
	<t>Examples of passive monitoring strategies include</t>		<t>Examples of passive monitoring strategies include:</t>
	<t>
	<list style="symbols">		<ul>
	<t>Monitoring of queue and buffer levels, e.g. via Active Queue		<li>Monitoring of queue and buffer levels, e.g., via active queue
	Management (e.g.		management (e.g.,
	<xref target="RFC7567"/></t>		<xref target="RFC7567" format="default"/>). </li>
	<t>Monitoring of per-flow counters</t>
	<t>Measurement of link statistics such as traffic volume, bandwi		<li>Monitoring of per-flow counters. </li>
	dth, and QoS</t>
	<t>Detection of dropped packets</t>		<li>Measurement of link statistics such as traffic volume, bandwid
	<t>Use of commercially available Network Monitoring tools</t>		th, and QoS. </li>
	</list>
	</t>		<li>Detection of dropped packets. </li>
	<t>Examples of active monitoring include</t>
	<t>		<li>Use of commercially available Network Monitoring tools. </li>
	<list style="symbols">		</ul>
	<t>In-band timing measurements (such as packet arrival times) e.
	g. by timestamping		<t>Examples of active monitoring include: </t>
	and packet inspection</t>
	<t>Use of OAM. For DetNet-specific OAM considerations see <xref		<ul>
	target="I-D.ietf-detnet-ip-oam"/>, <xref target="I-D.ietf-de
	tnet-mpls-oam"/>.		<li>In-band timing measurements (such as packet arrival times), e.
	Note: At the time of this writing, specifics of DPA have not b		g., by timestamping
	een developed for		and packet inspection. </li>
	the DetNet OAM, but could be a subject for future investigatio
	n</t>		<li>
	<t>For OAM for Ethernet specifically, see also Connectivity Faul		<t>Use of OAM. For DetNet-specific OAM considerations, see
	t Management (CFM,		<xref target="I-D.ietf-detnet-ip-oam" format="default"/> and
	<xref target="IEEE802.1Q"/>) which defines protocols and pra		<xref target="I-D.ietf-detnet-mpls-oam"
	ctices for OAM for		format="default"/>. Note: At the time of this writing,
	paths through 802.1 bridges and LANs</t>		specifics of DPA have not been developed for the DetNet OAM
	<t>Out-of-band detection. following the data path or parts of a		but could be a subject for future investigation.</t>
	data path, for
	example Bidirectional Forwarding Detection (BFD, e.g. <xref ta		<ul>
	rget="RFC5880"		<li>For OAM for Ethernet specifically, see also
	/>)</t>		Connectivity Fault Management (CFM <xref
	</list>		target="IEEE802.1Q" format="default"/>), which defines
	</t>		protocols and practices for OAM for paths through 802.1
	<t>Note that for some measurements (e.g. packet delay) it may be nec		bridges and LANs.
	essary to make and		</li>
	reconcile measurements from more than one physical location (e.g.		</ul>
	a source and
			</li>
			<li>Out-of-band detection. Following the data path or parts of a d
			ata path, for
			example, Bidirectional Forwarding Detection (BFD, e.g., <xref ta
			rget="RFC5880"
			format="default"/>). </li>
			</ul>
			<t>Note that for some measurements (e.g., packet delay), it may be n
			ecessary to make and
			reconcile measurements from more than one physical location (e.g.,
			a source and
	destination), possibly in both directions, in order to arrive at a given performance		destination), possibly in both directions, in order to arrive at a given performance
	indicator value. </t>		indicator value. </t>
	</list>
	</t>		</dd>
	<t>Notification Mechanisms <list hangIndent="10" style="empty">
			<dt>Notification Mechanisms: </dt>
			<dd>
	<t>Making DPA measurement results available at the right place(s) an d time(s) to effect		<t>Making DPA measurement results available at the right place(s) an d time(s) to effect
	timely response can be challenging. Two notification mechanisms th at are in general		timely response can be challenging. Two notification mechanisms th at are in general
	use are Netconf/YANG Notifications (e.g. <xref target="RFC5880"/>)		use are NETCONF/YANG Notifications and the proprietary local telem
	and the proprietary		etry interfaces
	local telemetry interfaces provided with components from some vend		provided with components from some vendors. The Constrained Applic
	ors. The CoAP		ation Protocol
	Observe Option (<xref target="RFC7641"/>) could also be relevant t		(CoAP) Observe Option <xref target="RFC7641" format="default"/> co
	o such scenarios. </t>		uld also be relevant
	<t>At the time of this writing YANG Notifications are not addressed		to such scenarios. </t>
	by the DetNet YANG
	drafts, however this may be a topic for future work. It is possibl		<t>At the time of this writing, YANG Notifications are not addressed
	e that some of the		by the DetNet YANG
	passive mechanisms could be covered by notifications from non-DetN		documents; however, this may be a topic for future work. It is pos
	et-specific YANG		sible that some of
	modules; for example if there is OAM or other performance monitori		the passive mechanisms could be covered by notifications from non-
	ng that can monitor		DetNet-specific YANG
	delay bounds then that could have its own associated YANG model wh		modules; for example, if there is OAM or other performance monitor
	ich could be		ing that can monitor
	relevant to DetNet, for example some "threshold" values for timing		delay bounds, then that could have its own associated YANG data mo
	measurement		del, which could be
			relevant to DetNet, for example, some "threshold" values for timin
			g measurement
	notifications. </t>		notifications. </t>
	<t>At the time of this writing there is an IETF Working Group for ne
	twork/performance		<t>At the time of this writing, there is an IETF Working Group for n
	monitoring (IP Performance Measurement, ippm). See also previous w		etwork/performance
	ork by the completed		monitoring (IP Performance Metrics (IPPM)). See also previous work
	Remote Network Monitoring Working Group (rmonmib). See also <xref		by the completed
	target="RFC6632"/>,		Remote Network Monitoring Working Group (RMONMIB). See also "<xref
	An Overview of the IETF Network Management Standards. </t>		target="RFC6632"
			format="title"/>", <xref target="RFC6632" format="default"/>. </
			t>
	<t>Vendor-specific local telemetry may be available on some commerci ally available		<t>Vendor-specific local telemetry may be available on some commerci ally available
	systems, whereby the system can be programmed (via a proprietary d edicated port and		systems, whereby the system can be programmed (via a proprietary d edicated port and
	API) to monitor and report on specific conditions, based on both p assive and active		API) to monitor and report on specific conditions, based on both p assive and active
	measurements.</t>		measurements. </t>
	</list>
	</t>		</dd>
			<dt>Related attacks: </dt>
			<dd>
	<t>Related attacks <list hangIndent="10" style="empty">
	<t>Performance analytics can be used to detect various attacks, incl uding the ones		<t>Performance analytics can be used to detect various attacks, incl uding the ones
	described in <xref target="DelayThreat"/> (Delay Attack), <xref ta		described in <xref target="DelayThreat" format="default"/> (Delay
	rget="SegmentThreat"		attack), <xref
	/> (Resource Segmentation Attack), and <xref target="SyncThreat"/>		target="SegmentThreat" format="default"/> (Resource Segmentation
	(Time		attack), and <xref
	Synchronization Attack). Once detection and notification have occu		target="SyncThreat" format="default"/> (Time-Synchronization att
	rred, the		ack). Once detection
	appropriate action can be taken to mitigate the threat. </t>		and notification have occurred, the appropriate action can be take
	<t>For example, in the case of data plane delay attacks, one possibl		n to mitigate the
	e mitigation is to		threat. </t>
	timestamp the data at the source, and timestamp it again at the de
	stination, and if		<t>For example, in the case of data plane Delay attacks, one possibl
	the resulting latency does not meet the service agreement, take ap		e mitigation is to
	propriate action.		timestamp the data at the source and timestamp it again at the des
	Note that DetNet specifies packet sequence numbering, however it d		tination, and if the
	oes not specify use		resulting latency does not meet the service agreement, take approp
	of packet timestamps, although they may be used by the underlying		riate action. Note
	transport (for		that DetNet specifies packet sequence numbering; however, it does
	example TSN, <xref target="IEEE802.1BA"/>) to provide the service.		not specify use of
	</t>		packet timestamps, although they may be used by the underlying tra
	</list>		nsport (for example,
	</t>		TSN <xref target="IEEE802.1BA" format="default"/>) to provide the
			service. </t>
			</dd>
			</dl>
	</section>		</section>
	<section title="Mitigation Summary">		<section numbered="true" toc="default">
	<t>The following table maps the attacks of <xref target="ThreatSection"/		<name>Mitigation Summary</name>
	>, Security Threats,		<t>The following table maps the attacks of <xref target="ThreatSection"
	to the impacts of <xref target="ThreatImpact"/>, Security Threat Impac		format="default"/>
	ts, and to the		(<xref target="ThreatSection" format="title"/>) to the impacts of <x
	mitigations of the current section. Each row specifies an attack, the		ref
	impact of this		target="ThreatImpact" format="default"/> (<xref target="ThreatImpact
	attack if it is successfully implemented, and possible mitigation meth		" format="title"/>)
	ods. </t>		and to the mitigations of the current section. Each row specifies an a
	<figure align="center" anchor="ThreatMapping"		ttack, the impact of
	title="Mapping Attacks to Impact and Mitigations">		this attack if it is successfully implemented, and possible mitigation
	<artwork align="left">		methods. </t>
	<![CDATA[
	+----------------------+---------------------+---------------------+		<table anchor="ThreatMapping">
	| Attack | Impact | Mitigations |		<name>Mapping Attacks to Impact and Mitigations</name>
	+----------------------+---------------------+---------------------+		<thead>
	|Delay Attack |-Non-deterministic |-Path redundancy |		<tr>
	| | delay |-Performance |		<th>Attack</th>
	| |-Data disruption | analytics |		<th>Impact</th>
	| |-Increased resource | |		<th>Mitigations</th>
	| | consumption | |		</tr>
	+----------------------+---------------------+---------------------+		</thead>
	|Reconnaissance |-Enabler for other |-Encryption |		<tbody>
	| | attacks |-Dummy traffic |		<tr>
	| | | insertion |		<td>Delay Attack</td>
	+----------------------+---------------------+---------------------+
	|DetNet Flow Modificat-|-Increased resource |-Path redundancy |		<td>
	|ion or Spoofing | consumption |-Integrity protection|		<ul>
	| |-Data disruption |-DetNet Node |		<li> Non-deterministic delay </li>
	| | | authentication |		<li>Data disruption </li>
	+----------------------+---------------------+---------------------+		<li> Increased resource consumption </li>
	|Inter-Segment Attack |-Increased resource |-Path redundancy |		</ul>
	| | consumption |-Performance |		</td>
	| |-Data disruption | analytics |		<td>
	+----------------------+---------------------+---------------------+
	|Replication: Increased|-All impacts of other|-Integrity protection|		<ul>
	|attack surface | attacks |-DetNet Node |		<li>Path redundancy</li>
	| | | authentication |		<li>Performance analytics </li>
	| | |-Encryption |		</ul>
	+----------------------+---------------------+---------------------+		</td>
	|Replication-related |-Non-deterministic |-Integrity protection|
	|Header Manipulation | delay |-DetNet Node |		</tr>
	| |-Data disruption | authentication |
	+----------------------+---------------------+---------------------+		<tr>
	|Path Manipulation |-Enabler for other |-Control and |		<td>Reconnaissance</td>
	| | attacks | signaling message |		<td>
	| | | protection |		<ul>
	+----------------------+---------------------+---------------------+		<li>Enabler for other attacks</li>
	|Path Choice: Increased|-All impacts of other|-Control and |		</ul>
	|Attack Surface | attacks | signaling message |		</td>
	| | | protection |		<td>
	+----------------------+---------------------+---------------------+		<ul>
	|Control or Signaling |-Increased resource |-Control and |		<li>Encryption</li>
	|Packet Modification | consumption | signaling message |		<li>Synthetic traffic insertion</li>
	| |-Non-deterministic | protection |		</ul>
	| | delay | |
	| |-Data disruption | |		</td>
	+----------------------+---------------------+---------------------+		</tr>
	|Control or Signaling |-Increased resource |-Control and |
	|Packet Injection | consumption | signaling message |		<tr>
	| |-Non-deterministic | protection |		<td>DetNet Flow Modification or Spoofing</td>
	| | delay | |		<td>
	| |-Data disruption | |		<ul>
	+----------------------+---------------------+---------------------+		<li>Increased resource consumption</li>
	|Attacks on Time |-Non-deterministic |-Path redundancy |		<li>Data disruption</li>
	|Synchronization | delay |-Control and |		</ul>
	|Mechanisms |-Increased resource | signaling message |
	| | consumption | protection |		</td>
	| |-Data disruption |-Performance |
	| | | analytics |		<td>
	+----------------------+---------------------+---------------------+
	]]></artwork>		<ul>
	</figure>		<li>Path redundancy</li>
			<li>Integrity protection</li>
			<li>DetNet Node authentication</li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Inter-segment Attack</td>
			<td>
			<ul>
			<li>Increased resource consumption</li>
			<li>Data disruption</li>
			</ul>
			</td>
			<td>
			<ul>
			<li>Path redundancy</li>
			<li>Performance analytics</li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Replication: Increased Attack Resource</td>
			<td>
			<ul>
			<li>All impacts of other attacks</li>
			</ul>
			</td>
			<td>
			<ul>
			<li>Integrity protection </li>
			<li>DetNet Node authentication</li>
			<li>Encryption</li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Replication-Related Header Manipulation</td>
			<td>
			<ul>
			<li> Non-deterministic delay </li>
			<li>Data disruption</li>
			</ul>
			</td>
			<td>
			<ul>
			<li>Integrity protection</li>
			<li>DetNet Node authentication</li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Path Manipulation</td>
			<td>
			<ul>
			<li>Enabler for other attacks</li>
			</ul>
			</td>
			<td>
			<ul>
			<li>Control and signaling message protection</li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Path Choice: Increased Attack Surface</td>
			<td>
			<ul>
			<li>All impacts of other attacks</li>
			</ul>
			</td>
			<td>
			<ul>
			<li> Control and signaling message protection </li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Control or Signaling Packet Modification</td>
			<td>
			<ul>
			<li>Increased resource consumption</li>
			<li>Non-deterministic delay</li>
			<li>Data disruption</li>
			</ul>
			</td>
			<td>
			<ul>
			<li>Control and signaling message protection</li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Control or Signaling Packet Injection</td>
			<td>
			<ul>
			<li>Increased resource consumption</li>
			<li> Non-deterministic delay </li>
			<li>Data disruption</li>
			</ul>
			</td>
			<td>
			<ul>
			<li>Control and signaling message protection</li>
			</ul>
			</td>
			</tr>
			<tr>
			<td>Attacks on Time-Synchronization Mechanisms</td>
			<td>
			<ul>
			<li>Non-deterministic delay</li>
			<li>Increased resource consumption</li>
			<li>Data disruption</li>
			</ul>
			</td>
			<td>
			<ul>
			<li>Path redundancy</li>
			<li>Control and signaling message protection</li>
			<li>Performance analytics</li>
			</ul>
			</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</section>		</section>
	<section title="Association of Attacks to Use Cases">		<section numbered="true" toc="default">
			<name>Association of Attacks to Use Cases</name>
	<t>Different attacks can have different impact and/or mitigation depending on the use case, so		<t>Different attacks can have different impact and/or mitigation depending on the use case, so
	we would like to make this association in our analysis. However since th		we would like to make this association in our analysis. However, since t
	ere is a potentially		here is a
	unbounded list of use cases, we categorize the attacks with respect to t		potentially unbounded list of use cases, we categorize the attacks with
	he common themes of		respect to the
	the use cases as identified in the Use Case Common Themes section of the		common themes of the use cases as identified in <xref target="RFC8578" s
	DetNet Use Cases		ectionFormat="of"
	<xref target="RFC8578"/>. </t>		section="11"/>. </t>
	<t>See also <xref target="ThreatIndustryMapping"/> for a mapping of the im		<t>See also <xref target="ThreatIndustryMapping" format="default"/> for a
	pact of attacks per		mapping of the
	use case by industry. </t>		impact of attacks per use case by industry. </t>
	<section title="Association of Attacks to Use Case Common Themes">		<section numbered="true" toc="default">
	<t>In this section we review each theme and discuss the attacks that are		<name>Association of Attacks to Use Case Common Themes</name>
	applicable to that		<t>In this section, we review each theme and discuss the attacks that ar
			e applicable to that
	theme, as well as anything specific about the impact and mitigations f or that attack with		theme, as well as anything specific about the impact and mitigations f or that attack with
	respect to that theme. The table <xref target="ThemeAttackMapping"/>,		respect to that theme. <xref target="ThemeAttackMapping" format="defau
	Mapping Between		lt"/>, Mapping
	Themes and Attacks, then provides a summary of the attacks that are ap		between Themes and Attacks, then provides a summary of the attacks tha
	plicable to each		t are applicable to
	theme. </t>		each theme. </t>
	<section title="Sub-Network Layer">		<section numbered="true" toc="default">
			<name>Sub-network Layer</name>
	<t>DetNet is expected to run over various transmission mediums, with E thernet being the		<t>DetNet is expected to run over various transmission mediums, with E thernet being the
	first identified. Attacks such as Delay or Reconnaissance might be i mplemented		first identified. Attacks such as Delay or Reconnaissance might be i mplemented
	differently on a different transmission medium, however the impact o n the DetNet as a		differently on a different transmission medium; however, the impact on the DetNet as a
	whole would be essentially the same. We thus conclude that all attac ks and impacts that		whole would be essentially the same. We thus conclude that all attac ks and impacts that
	would be applicable to DetNet over Ethernet (i.e. all those named in this document)		would be applicable to DetNet over Ethernet (i.e., all those named i n this document)
	would also be applicable to DetNet over other transmission mediums. </t>		would also be applicable to DetNet over other transmission mediums. </t>
	<t>With respect to mitigations, some methods are specific to the Ether net medium, for		<t>With respect to mitigations, some methods are specific to the Ether net medium, for
	example time-aware scheduling using 802.1Qbv <xref target="IEEE802.1		example, time-aware scheduling using 802.1Qbv <xref target="IEEE802.
	Qbv-2015"/> can		1Qbv-2015"
	protect against excessive use of bandwidth at the ingress - for othe		format="default"/> can protect against excessive use of bandwidth
	r mediums, other		at the ingress --
	mitigations would have to be implemented to provide analogous protec		for other mediums, other mitigations would have to be implemented to
	tion. </t>		provide analogous
			protection. </t>
	</section>		</section>
	<section title="Central Administration">
			<section numbered="true" toc="default">
			<name>Central Administration</name>
	<t>A DetNet network can be controlled by a centralized network configu ration and control		<t>A DetNet network can be controlled by a centralized network configu ration and control
	system. Such a system may be in a single central location, or it may be distributed		system. Such a system may be in a single central location, or it may be distributed
	across multiple control entities that function together as a unified control system for		across multiple control entities that function together as a unified control system for
	the network. </t>		the network. </t>
	<t>All attacks named in this document which are relevant to controller plane packets (and		<t>All attacks named in this document that are relevant to controller plane packets (and
	the controller itself) are relevant to this theme, including Path Ma nipulation, Path		the controller itself) are relevant to this theme, including Path Ma nipulation, Path
	Choice, Control Packet Modification or Injection, Reconnaissance and		Choice, Control Packet Modification or Injection, Reconnaissance, an
	Attacks on Time		d Attacks on
	Synchronization Mechanisms. </t>		Time-Synchronization Mechanisms. </t>
	</section>		</section>
	<section title="Hot Swap">		<section numbered="true" toc="default">
	<t>A DetNet network is not expected to be "plug and play" - it is expe		<name>Hot Swap</name>
	cted that there is		<t>A DetNet network is not expected to be "plug and play"; it is expec
			ted that there is
	some centralized network configuration and control system. However, the ability to "hot		some centralized network configuration and control system. However, the ability to "hot
	swap" components (e.g. due to malfunction) is similar enough to "plu g and play" that		swap" components (e.g., due to malfunction) is similar enough to "pl ug and play" that
	this kind of behavior may be expected in DetNet networks, depending on the		this kind of behavior may be expected in DetNet networks, depending on the
	implementation. </t>		implementation. </t>
	<t>An attack surface related to Hot Swap is that the DetNet network mu st at least consider		<t>An attack surface related to hot swap is that the DetNet network mu st at least consider
	input at runtime from components that were not part of the initial c onfiguration of the		input at runtime from components that were not part of the initial c onfiguration of the
	network. Even a "perfect" (or "hitless") replacement of a component at runtime would not		network. Even a "perfect" (or "hitless") replacement of a component at runtime would not
	necessarily be ideal, since presumably one would want to distinguish it from the		necessarily be ideal, since presumably one would want to distinguish it from the
	original for OAM purposes (e.g. to report hot swap of a failed compo		original for OAM purposes (e.g., to report hot swap of a failed comp
	nent). </t>		onent). </t>
	<t>This implies that an attack such as Flow Modification, Spoofing or
	Inter-segment (which		<t>This implies that an attack such as Flow Modification, Spoofing, or
	could introduce packets from a "new" component, i.e. one heretofore		Inter-segment
	unknown on the		(which could introduce packets from a "new" component, i.e., one her
	network) could be used to exploit the need to consider such packets		etofore unknown on
	(as opposed to		the network) could be used to exploit the need to consider such pack
			ets (as opposed to
	rejecting them out of hand as one would do if one did not have to co nsider introduction		rejecting them out of hand as one would do if one did not have to co nsider introduction
	of a new component).</t>		of a new component).</t>
	<t>To mitigate this situation, deployments should provide a method for dynamic and secure		<t>To mitigate this situation, deployments should provide a method for dynamic and secure
	registration of new components, and (possibly manual) deregistration and re-keying of		registration of new components, and (possibly manual) deregistration and re-keying of
	retired components. This would avoid the situation in which the netw ork must accommodate		retired components. This would avoid the situation in which the netw ork must accommodate
	potentially insecure packet flows from unknown components. </t>		potentially insecure packet flows from unknown components. </t>
	<t>Similarly if the network was designed to support runtime replacemen t of a clock		<t>Similarly, if the network was designed to support runtime replaceme nt of a clock
	component, then presence (or apparent presence) and thus considerati on of packets from a		component, then presence (or apparent presence) and thus considerati on of packets from a
	new such component could affect the network, or the time synchroniza tion of the network,		new such component could affect the network, or the time synchroniza tion of the network,
	for example by initiating a new Best Master Clock selection process.		for example, by initiating a new Best Master Clock selection process
	These types of		. These types of
	attacks should therefore be considered when designing hot swap type		attacks should therefore be considered when designing hot-swap-type
	functionality (see		functionality (see
	<xref target="RFC7384"/>). </t>		<xref target="RFC7384" format="default"/>). </t>
	</section>		</section>
	<section title="Data Flow Information Models">		<section numbered="true" toc="default">
	<t> DetNet specifies new YANG models (<xref target="I-D.ietf-detnet-ya		<name>Data Flow Information Models</name>
	ng"/>)which may		<t> DetNet specifies new YANG data models <xref target="I-D.ietf-detne
	present new attack surfaces. Per IETF guidelines, security considera		t-yang"
	tions for any YANG		format="default"/> that may present new attack surfaces. Per IETF
	model are expected to be part of the YANG model specification, as de		guidelines, security
	scribed in <xref		considerations for any YANG data model are expected to be part of th
	target="IETF_YANG_SEC"/>.</t>		e YANG data model
			specification, as described in <xref target="IETF-YANG-SEC" format="
			default"/>.</t>
	</section>		</section>
	<section title="L2 and L3 Integration">		<section numbered="true" toc="default">
	<t>A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TS		<name>L2 and L3 Integration</name>
	N LAN) and Layer 3		<t>A DetNet network integrates Layer 2 (bridged) networks (e.g., AVB/T
	(routed) networks (e.g. IP) via the use of well-known protocols such		SN LAN) and Layer 3
	as IP, MPLS		(routed) networks (e.g., IP) via the use of well-known protocols suc
	Pseudowire, and Ethernet. Various DetNet drafts address many specifi		h as IP, MPLS
	c aspects of Layer 2		Pseudowire, and Ethernet. Various DetNet documents address many spec
	and Layer 3 integration within a DetNet, and these are not individua		ific aspects of
	lly referenced here;		Layer 2 and Layer 3 integration within a DetNet, and these are not i
	security considerations for those aspects are covered within those d		ndividually
	rafts or within the		referenced here; security considerations for those aspects are cover
	related subsections of the present document. </t>		ed within those
			documents or within the related subsections of the present document.
			</t>
	<t>Please note that although there are no entries in the L2 and L3 Int egration line of the		<t>Please note that although there are no entries in the L2 and L3 Int egration line of the
	Mapping Between Themes and Attacks table <xref target="ThreatList"/>		Mapping between Themes and Attacks table (<xref target="ThemeAttackM
	, this does not		apping"
	imply that there could be no relevant attacks related to L2-L3 integ		format="default"/>), this does not imply that there could be no re
	ration.</t>		levant attacks
			related to L2-L3 integration.</t>
	</section>		</section>
	<section title="End-to-End Delivery">		<section numbered="true" toc="default">
			<name>End-to-End Delivery</name>
	<t>Packets that are part of a resource-reserved DetNet flow are not to be dropped by the		<t>Packets that are part of a resource-reserved DetNet flow are not to be dropped by the
	DetNet due to congestion. Packets may however be dropped for intende d reasons, for		DetNet due to congestion. Packets may however be dropped for intende d reasons, for
	example security measures. For example, consider the case in which a packet becomes		example, security measures. For example, consider the case in which a packet becomes
	corrupted (whether incidentally or maliciously) such that the result ing flow ID		corrupted (whether incidentally or maliciously) such that the result ing flow ID
	incidentally matches the flow ID of another DetNet flow, potentially resulting in		incidentally matches the flow ID of another DetNet flow, potentially resulting in
	additional unauthorized traffic on the latter. In such a case it may be a security		additional unauthorized traffic on the latter. In such a case, it ma y be a security
	requirement that the system report and/or take some defined action, perhaps when a		requirement that the system report and/or take some defined action, perhaps when a
	packet drop count threshold has been reached (see also <xref target=		packet drop count threshold has been reached (see also <xref target=
	"DpaMitigation"/>). </t>		"DpaMitigation"
	<t>A data plane attack may force packets to be dropped, for example as		format="default"/>). </t>
	a result of a Delay		<t>A data plane attack may force packets to be dropped, for example, a
	attack, Replication/Elimination attack, or Flow Modification attack.		s a result of a
	</t>		Delay attack, Replication/Elimination attack, or Flow Modification a
	<t>The same result might be obtained by a controller plane attack, e.g		ttack. </t>
	. Path Manipulation		<t>The same result might be obtained by a Controller plane attack, e.g
			., Path Manipulation
	or Signaling Packet Modification.</t>		or Signaling Packet Modification.</t>
	<t>An attack may also cause packets that should not be delivered to be delivered, such as		<t>An attack may also cause packets that should not be delivered to be delivered, such as
	by forcing packets from one (e.g. replicated) path to be preferred o		by forcing packets from one (e.g., replicated) path to be preferred
	ver another path		over another path
	when they should not be (Replication attack), or by Flow Modificatio		when they should not be (Replication attack), or by Flow Modificatio
	n, or by Path Choice		n, or Path Choice or
	or Packet Injection. A Time Synchronization attack could cause a sys		Packet Injection. A Time-Synchronization attack could cause a system
	tem that was		that was expecting
	expecting certain packets at certain times to accept unintended pack		certain packets at certain times to accept unintended packets based
	ets based on		on compromised
	compromised system time or time windowing in the scheduler. </t>		system time or time windowing in the scheduler. </t>
	</section>		</section>
	<section title="Replacement for Proprietary Fieldbuses and Ethernet-base
	d Networks">		<section numbered="true" toc="default">
	<t>There are many proprietary "field buses" used in Industrial and oth		<name>Replacement for Proprietary Fieldbuses and Ethernet-Based Networ
	er industries, as		ks</name>
			<t>There are many proprietary "fieldbuses" used in Industrial and othe
			r industries, as
	well as proprietary non-interoperable deterministic Ethernet-based n etworks. DetNet is		well as proprietary non-interoperable deterministic Ethernet-based n etworks. DetNet is
	intended to provide an open-standards-based alternative to such buse s/networks. In cases		intended to provide an open-standards-based alternative to such buse s/networks. In cases
	where a DetNet intersects with such fieldbuses/networks or their pro tocols, such as by		where a DetNet intersects with such fieldbuses/networks or their pro tocols, such as by
	protocol emulation or access via a gateway, new attack surfaces can be opened.</t>		protocol emulation or access via a gateway, new attack surfaces can be opened.</t>
	<t>For example an Inter-Segment or Controller plane attack such as Pat		<t>For example, an Inter-segment or Controller plane attack such as Pa
	h Manipulation, Path		th Manipulation,
	Choice or Control Packet Modification/Injection could be used to exp		Path Choice, or Control Packet Modification/Injection could be used
	loit commands		to exploit commands
	specific to such a protocol, or that are interpreted differently by		specific to such a protocol or that are interpreted differently by t
	the different		he different
	protocols or gateway. </t>		protocols or gateway. </t>
	</section>		</section>
	<section title="Deterministic vs Best-Effort Traffic">		<section numbered="true" toc="default">
	<t>Most of the themes described in this document address OT (reserved)		<name>Deterministic vs. Best-Effort Traffic</name>
	DetNet flows - this		<t>Most of the themes described in this document address OT (reserved)
	item is intended to address issues related to IT traffic on a DetNet		DetNet flows --
	.</t>		this item is intended to address issues related to IT traffic on a D
			etNet.</t>
	<t>DetNet is intended to support coexistence of time-sensitive operati onal (OT,		<t>DetNet is intended to support coexistence of time-sensitive operati onal (OT,
	deterministic) traffic and information (IT, "best effort") traffic o n the same		deterministic) traffic and informational (IT, "best effort") traffic on the same
	("unified") network. </t>		("unified") network. </t>
	<t>With DetNet, this coexistence will become more common, and mitigati ons will need to be		<t>With DetNet, this coexistence will become more common, and mitigati ons will need to be
	established. The fact that the IT traffic on a DetNet is limited to		established. The fact that the IT traffic on a DetNet is limited to
	a corporate		a
	controlled network makes this a less difficult problem compared to b		corporate-controlled network makes this a less difficult problem com
	eing exposed to the		pared to being
	open Internet, however this aspect of DetNet security should not be		exposed to the open Internet; however, this aspect of DetNet securit
	underestimated. </t>		y should not be
			underestimated. </t>
	<t>An Inter-segment attack can flood the network with IT-type traffic with the intent of		<t>An Inter-segment attack can flood the network with IT-type traffic with the intent of
	disrupting handling of IT traffic, and/or the goal of interfering wi		disrupting the handling of IT traffic and/or the goal of interfering
	th OT traffic.		with OT traffic.
	Presumably if the DetNet flow reservation and isolation of the DetNe		Presumably, if the DetNet flow reservation and isolation of the DetN
	t is well-designed		et is well designed
	(better-designed than the attack) then interference with OT traffic		(better-designed than the attack), then interference with OT traffic
	should not result		should not result
	from an attack that floods the network with IT traffic. </t>		from an attack that floods the network with IT traffic. </t>
	<t>The handling of IT traffic (i.e. traffic which by definition is not guaranteed any		<t>The handling of IT traffic (i.e., traffic that by definition is not guaranteed any
	given deterministic service properties) by the DetNet will by defini tion not be given		given deterministic service properties) by the DetNet will by defini tion not be given
	the DetNet-specific protections provided to DetNet (resource-reserve d) flows. The		the DetNet-specific protections provided to DetNet (resource-reserve d) flows. The
	implication is that the IT traffic on the DetNet network will necess arily have its own		implication is that the IT traffic on the DetNet network will necess arily have its own
	specific set of product (component or system) requirements for prote ction against		specific set of product (component or system) requirements for prote ction against
	attacks such as DOS; presumably they will be less stringent than tho		attacks such as DoS; presumably they will be less stringent than tho
	se for OT flows, but		se for OT flows, but
	nonetheless component and system designers must employ whatever miti		nonetheless, component and system designers must employ whatever mit
	gations will meet		igations will meet
	the specified security requirements for IT traffic for the given com ponent or DetNet. </t>		the specified security requirements for IT traffic for the given com ponent or DetNet. </t>
	<t>The network design as a whole also needs to consider possible appli cation-level		<t>The network design as a whole also needs to consider possible appli cation-level
	dependencies of "OT"-type applications on services provided by the "		dependencies of OT-type applications on services provided by the IT
	IT part" of the		part of the network;
	network; for example, does the OT application depend on IT network s		for example, does the OT application depend on IT network services s
	ervices such as DNS		uch as DNS or OAM?
	or OAM? If such dependencies exist, how are malicious packet flows h		If such dependencies exist, how are malicious packet flows handled?
	andled? Such		Such considerations
	considerations are typically outside the scope of DetNet proper, but		are typically outside the scope of DetNet proper, but nonetheless ne
	nonetheless need to		ed to be addressed
	be addressed in the overall DetNet network design for a given use ca		in the overall DetNet network design for a given use case.</t>
	se.</t>
	</section>		</section>
	<section title="Deterministic Flows">
			<section numbered="true" toc="default">
			<name>Deterministic Flows</name>
	<t>Reserved bandwidth data flows (deterministic flows) must provide th e allocated		<t>Reserved bandwidth data flows (deterministic flows) must provide th e allocated
	bandwidth, and must be isolated from each other. </t>		bandwidth and must be isolated from each other. </t>
	<t>A Spoofing or Inter-segment attack which adds packet traffic to a b		<t>A Spoofing or Inter-segment attack that adds packet traffic to a ba
	andwidth-reserved		ndwidth-reserved
	DetNet flow could cause that flow to occupy more bandwidth than it w as allocated,		DetNet flow could cause that flow to occupy more bandwidth than it w as allocated,
	resulting in interference with other DetNet flows.</t>		resulting in interference with other DetNet flows.</t>
	<t>A Flow Modification or Spoofing or Header Manipulation or Control P acket Modification		<t>A Flow Modification, Spoofing, Header Manipulation, or Control Pack et Modification
	attack could cause packets from one flow to be directed to another f low, thus breaching		attack could cause packets from one flow to be directed to another f low, thus breaching
	isolation between the flows.</t>		isolation between the flows.</t>
	</section>		</section>
	<section title="Unused Reserved Bandwidth">		<section numbered="true" toc="default">
			<name>Unused Reserved Bandwidth</name>
	<t>If bandwidth reservations are made for a DetNet flow but the associ ated bandwidth is		<t>If bandwidth reservations are made for a DetNet flow but the associ ated bandwidth is
	not used at any point in time, that bandwidth is made available on t he network for		not used at any point in time, that bandwidth is made available on t he network for
	best-effort traffic. However, note that security considerations for best-effort traffic		best-effort traffic. However, note that security considerations for best-effort traffic
	on a DetNet network is out of scope of the present document, provide d that any such		on a DetNet network is out of scope of the present document, provide d that any such
	attacks on best-effort traffic do not affect performance for DetNet OT traffic. </t>		attacks on best-effort traffic do not affect performance for DetNet OT traffic. </t>
	</section>		</section>
	<section title="Interoperability">		<section numbered="true" toc="default">
			<name>Interoperability</name>
	<t>The DetNet specifications as a whole are intended to enable an ecos ystem in which		<t>The DetNet specifications as a whole are intended to enable an ecos ystem in which
	multiple vendors can create interoperable products, thus promoting c omponent diversity		multiple vendors can create interoperable products, thus promoting c omponent diversity
	and potentially higher numbers of each component manufactured. Towar d that end, the		and potentially higher numbers of each component manufactured. Towar d that end, the
	security measures and protocols discussed in this document are inten ded to encourage		security measures and protocols discussed in this document are inten ded to encourage
	interoperability.</t>		interoperability.</t>
	<t>Given that the DetNet specifications are unambiguously written and that the		<t>Given that the DetNet specifications are unambiguously written and that the
	implementations are accurate, the property of interoperability shoul d not in and of		implementations are accurate, the property of interoperability shoul d not in and of
	itself cause security concerns; however, flaws in interoperability b etween components		itself cause security concerns; however, flaws in interoperability b etween components
	could result in security weaknesses. The network operator as well as		could result in security weaknesses. The network operator, as well a
	system and		s system and
	component designer can all contribute to reducing such weaknesses th		component designers, can all contribute to reducing such weaknesses
	rough		through
	interoperability testing. </t>		interoperability testing. </t>
	</section>		</section>
	<section title="Cost Reductions">		<section numbered="true" toc="default">
			<name>Cost Reductions</name>
	<t>The DetNet network specifications are intended to enable an ecosyst em in which multiple		<t>The DetNet network specifications are intended to enable an ecosyst em in which multiple
	vendors can create interoperable products, thus promoting higher num bers of each		vendors can create interoperable products, thus promoting higher num bers of each
	component manufactured, promoting cost reduction and cost competitio n among vendors. </t>		component manufactured, promoting cost reduction and cost competitio n among vendors. </t>
	<t>This envisioned breadth of DetNet-enabled products is in general a		<t>This envisioned breadth of DetNet-enabled products is in general a
	positive factor,		positive factor;
	however implementation flaws in any individual component can present		however, implementation flaws in any individual component can presen
	an attack surface.		t an attack surface.
	In addition, implementation differences between components from diff erent vendors can		In addition, implementation differences between components from diff erent vendors can
	result in attack surfaces (resulting from their interaction) which m ay not exist in any		result in attack surfaces (resulting from their interaction) that ma y not exist in any
	individual component. </t>		individual component. </t>
	<t>Network operators can mitigate such concerns through sufficient pro duct and		<t>Network operators can mitigate such concerns through sufficient pro duct and
	interoperability testing.</t>		interoperability testing.</t>
	</section>		</section>
	<section title="Insufficiently Secure Components">		<section numbered="true" toc="default">
			<name>Insufficiently Secure Components</name>
	<t>The DetNet network specifications are intended to enable an ecosyst em in which multiple		<t>The DetNet network specifications are intended to enable an ecosyst em in which multiple
	vendors can create interoperable products, thus promoting component diversity and		vendors can create interoperable products, thus promoting component diversity and
	potentially higher numbers of each component manufactured. However t his raises the		potentially higher numbers of each component manufactured. However, this raises the
	possibility that a vendor might repurpose for DetNet applications a hardware or software		possibility that a vendor might repurpose for DetNet applications a hardware or software
	component that was originally designed for operation in an isolated OT network, and thus		component that was originally designed for operation in an isolated OT network and thus
	may not have been designed to be sufficiently secure, or secure at a ll, against the		may not have been designed to be sufficiently secure, or secure at a ll, against the
	sorts of attacks described in this document. Deployment of such a co mponent on a DetNet		sorts of attacks described in this document. Deployment of such a co mponent on a DetNet
	network that is intended to be highly secure may present an attack s urface; thus the		network that is intended to be highly secure may present an attack s urface; thus, the
	DetNet network operator may need to take specific actions to protect such components,		DetNet network operator may need to take specific actions to protect such components,
	for example by implementing a secure interface (such as a firewall) to isolate the		for example, by implementing a secure interface (such as a firewall) to isolate the
	component from the threats that may be present in the greater networ k. </t>		component from the threats that may be present in the greater networ k. </t>
	</section>		</section>
	<section title="DetNet Network Size" anchor="NetworkSize">		<section anchor="NetworkSize" numbered="true" toc="default">
	<t>DetNet networks range in size from very small, e.g. inside a single		<name>DetNet Network Size</name>
	industrial machine,		<t>DetNet networks range in size from very small, e.g., inside a singl
	to very large, for example a Utility Grid network spanning a whole c		e industrial
	ountry. </t>		machine, to very large, e.g., a Utility Grid network spanning a whol
			e country. </t>
	<t>The size of the network might be related to how the attack is intro duced into the		<t>The size of the network might be related to how the attack is intro duced into the
	network, for example if the entire network is local, there is a thre		network. For example, if the entire network is local, there is a thr
	at that power can be		eat that power can
	cut to the entire network. If the network is large, perhaps only a p		be cut to the entire network. If the network is large, perhaps only
	art of the network		a part of the
	is attacked. </t>		network is attacked. </t>
	<t>A Delay attack might be as relevant to a small network as to a larg e network, although		<t>A Delay attack might be as relevant to a small network as to a larg e network, although
	the amount of delay might be different. </t>		the amount of delay might be different. </t>
	<t>Attacks sourced from IT traffic might be more likely in large netwo		<t>Attacks sourced from IT traffic might be more likely in large netwo
	rks, since more		rks since more
	people might have access to the network, presenting a larger attack		people might have access to the network, presenting a larger attack
	surface. Similarly		surface. Similarly,
	Path Manipulation, Path Choice and Time Synchronization attacks seem		Path Manipulation, Path Choice, and Time-Synchronization attacks see
	more likely		m more likely
	relevant to large networks.</t>		relevant to large networks.</t>
	</section>		</section>
	<section title="Multiple Hops">		<section numbered="true" toc="default">
	<t>Large DetNet networks (e.g. a Utility Grid network) may involve man		<name>Multiple Hops</name>
	y "hops" over		<t>Large DetNet networks (e.g., a Utility Grid network) may involve ma
	various kinds of links for example radio repeaters, microwave links,		ny "hops" over
	fiber optic links,		various kinds of links, for example, radio repeaters, microwave link
	etc. </t>		s, fiber optic
			links, etc. </t>
	<t>An attacker who has knowledge of the operation of a component or de vice's internal		<t>An attacker who has knowledge of the operation of a component or de vice's internal
	software (such as "device drivers") may be able to take advantage of this knowledge to		software (such as "device drivers") may be able to take advantage of this knowledge to
	design an attack that could exploit flaws (or even the specifics of normal operation) in		design an attack that could exploit flaws (or even the specifics of normal operation) in
	the communication between the various links. </t>		the communication between the various links. </t>
	<t>It is also possible that a large scale DetNet topology containing v arious kinds of		<t>It is also possible that a large-scale DetNet topology containing v arious kinds of
	links may not be in as common use as other more homogeneous topologi es. This situation		links may not be in as common use as other more homogeneous topologi es. This situation
	may present more opportunity for attackers to exploit software and/o r protocol flaws in		may present more opportunity for attackers to exploit software and/o r protocol flaws in
	or between these components, because these components or configurati		or between these components because these components or configuratio
	ons may not have		ns may not have been
	been sufficiently tested for interoperability (in the way they would		sufficiently tested for interoperability (in the way they would be a
	be as a result of		s a result of broad
	broad usage). This may be of particular concern to early adopters of		usage). This may be of particular concern to early adopters of new D
	new DetNet		etNet components or
	components or technologies.</t>		technologies.</t>
	<t>Of the attacks we have defined, the ones identified in <xref target		<t>Of the attacks we have defined, the ones identified in <xref target
	="NetworkSize"/> as		="NetworkSize"
	germane to large networks are the most relevant. </t>		format="default"/> as germane to large networks are the most relev
			ant. </t>
	</section>		</section>
	<section title="Level of Service" anchor="LevelOfServiceTheme">		<section anchor="LevelOfServiceTheme" numbered="true" toc="default">
			<name>Level of Service</name>
	<t>A DetNet is expected to provide means to configure the network that include querying		<t>A DetNet is expected to provide means to configure the network that include querying
	network path latency, requesting bounded latency for a given DetNet flow, requesting		network path latency, requesting bounded latency for a given DetNet flow, requesting
	worst case maximum and/or minimum latency for a given path or DetNet flow, and so on. It		worst-case maximum and/or minimum latency for a given path or DetNet flow, and so on. It
	is an expected case that the network cannot provide a given requeste d service level. In		is an expected case that the network cannot provide a given requeste d service level. In
	such cases the network control system should reply that the requeste d service level is		such cases, the network control system should reply that the request ed service level is
	not available (as opposed to accepting the parameter but then not de livering the desired		not available (as opposed to accepting the parameter but then not de livering the desired
	behavior). </t>		behavior). </t>
	<t>Controller plane attacks such as Signaling Packet Modification and Injection could be		<t>Controller plane attacks such as Signaling Packet Modification and Injection could be
	used to modify or create control traffic that could interfere with t he process of a user		used to modify or create control traffic that could interfere with t he process of a user
	requesting a level of service and/or the reply from the network.</t>		requesting a level of service and/or the reply from the network.</t>
	<t>Reconnaissance could be used to characterize flows and perhaps targ et specific flows		<t>Reconnaissance could be used to characterize flows and perhaps targ et specific flows
	for attack via the controller plane as noted in <xref target="Reconn		for attack via the controller plane as noted in <xref target="Reconn
	aissance"/>. </t>		aissance"
			format="default"/>. </t>
	</section>		</section>
	<section title="Bounded Latency" anchor="BoundedLatencyTheme">		<section anchor="BoundedLatencyTheme" numbered="true" toc="default">
			<name>Bounded Latency</name>
	<t>DetNet provides the expectation of guaranteed bounded latency. </t>		<t>DetNet provides the expectation of guaranteed bounded latency. </t>
	<t>Delay attacks can cause packets to miss their agreed-upon latency b oundaries.</t>		<t>Delay attacks can cause packets to miss their agreed-upon latency b oundaries.</t>
	<t>Time Synchronization attacks can corrupt the time reference of the system, resulting in		<t>Time-Synchronization attacks can corrupt the time reference of the system, resulting in
	missed latency deadlines (with respect to the "correct" time referen ce).</t>		missed latency deadlines (with respect to the "correct" time referen ce).</t>
	</section>		</section>
	<section title="Low Latency">		<section numbered="true" toc="default">
	<t>Applications may require "extremely low latency" however depending		<name>Low Latency</name>
	on the application		<t>Applications may require "extremely low latency"; however, dependin
	these may mean very different latency values; for example "low laten		g on the
	cy" across a Utility		application, these may mean very different latency values. For examp
	grid network is on a different time scale than "low latency" in a mo		le, "low latency"
	tor control loop in		across a Utility Grid network is on a different time scale than "low
	a small machine. The intent is that the mechanisms for specifying de		latency" in a motor
	sired latency		control loop in a small machine. The intent is that the mechanisms f
	include wide ranges, and that architecturally there is nothing to pr		or specifying
	event arbitrarily		desired latency include wide ranges, and that architecturally there
	low latencies from being implemented in a given network. </t>		is nothing to
	<t>Attacks on the controller plane (as described in the Level of Servi		prevent arbitrarily low latencies from being implemented in a given
	ce theme <xref		network. </t>
			<t>Attacks on the controller plane (as described in the Level of Servi
			ce theme; see <xref
	target="LevelOfServiceTheme"/>) and Delay and Time attacks (as des cribed in the		target="LevelOfServiceTheme"/>) and Delay and Time attacks (as des cribed in the
	Bounded Latency theme <xref target="BoundedLatencyTheme"/>) both app		Bounded Latency theme; see <xref target="BoundedLatencyTheme" format
	ly here. </t>		="default"/>) both
			apply here. </t>
	</section>		</section>
	<section title="Bounded Jitter (Latency Variation)">
	<t>DetNet is expected to provide bounded jitter (packet to packet late		<section numbered="true" toc="default">
	ncy variation).</t>		<name>Bounded Jitter (Latency Variation)</name>
	<t>Delay attacks can cause packets to vary in their arrival times, res		<t>DetNet is expected to provide bounded jitter (packet-to-packet late
	ulting in packet to		ncy variation).</t>
	packet latency variation, thereby violating the jitter specification		<t>Delay attacks can cause packets to vary in their arrival times, res
	.</t>		ulting in
			packet-to-packet latency variation, thereby violating the jitter spe
			cification.</t>
	</section>		</section>
	<section title="Symmetrical Path Delays">		<section numbered="true" toc="default">
			<name>Symmetrical Path Delays</name>
	<t>Some applications would like to specify that the transit delay time values be equal for		<t>Some applications would like to specify that the transit delay time values be equal for
	both the transmit and return paths. </t>		both the transmit and return paths. </t>
	<t>Delay attacks can cause path delays to materially differ between pa ths.</t>		<t>Delay attacks can cause path delays to materially differ between pa ths.</t>
	<t>Time Synchronization attacks can corrupt the time reference of the system, resulting in		<t>Time-Synchronization attacks can corrupt the time reference of the system, resulting in
	path delays that may be perceived to be different (with respect to t he "correct" time		path delays that may be perceived to be different (with respect to t he "correct" time
	reference) even if they are not materially different.</t>		reference) even if they are not materially different.</t>
	</section>		</section>
	<section title="Reliability and Availability">		<section numbered="true" toc="default">
	<t>DetNet based systems are expected to be implemented with essentiall		<name>Reliability and Availability</name>
	y arbitrarily high		<t>DetNet-based systems are expected to be implemented with essentiall
	availability (for example 99.9999% up time, or even 12 nines). The i		y arbitrarily high
	ntent is that the		availability (for example, 99.9999% up time, or even 12 nines). The
			intent is that the
	DetNet designs should not make any assumptions about the level of re liability and		DetNet designs should not make any assumptions about the level of re liability and
	availability that may be required of a given system, and should defi ne parameters for		availability that may be required of a given system and should defin e parameters for
	communicating these kinds of metrics within the network. </t>		communicating these kinds of metrics within the network. </t>
	<t>Any attack on the system, of any type, can affect its overall relia bility and		<t>Any attack on the system, of any type, can affect its overall relia bility and
	availability, thus in the mapping table <xref target="ThreatList"/>		availability; thus, in the mapping table (<xref target="ThemeAttackM
	we have marked every		apping"
	attack. Since every DetNet depends to a greater or lesser degree on		format="default"/>), we have marked every attack. Since every DetN
	reliability and		et depends to a
	availability, this essentially means that all networks have to mitig		greater or lesser degree on reliability and availability, this essen
	ate all attacks,		tially means that
	which to a greater or lesser degree defeats the purpose of associati		all networks have to mitigate all attacks, which to a greater or les
	ng attacks with use		ser degree defeats
	cases. It also underscores the difficulty of designing "extremely hi		the purpose of associating attacks with use cases. It also underscor
	gh reliability"		es the difficulty of
	networks. </t>		designing "extremely high reliability" networks. </t>
	<t>In practice, network designers can adopt a risk-based approach, in		<t>In practice, network designers can adopt a risk-based approach in w
	which only those		hich only those
	attacks are mitigated whose potential cost is higher than the cost o f mitigation.</t>		attacks are mitigated whose potential cost is higher than the cost o f mitigation.</t>
	</section>		</section>
	<section title="Redundant Paths">		<section numbered="true" toc="default">
			<name>Redundant Paths</name>
	<t>This document expects that each DetNet system will be implemented t o some essentially		<t>This document expects that each DetNet system will be implemented t o some essentially
	arbitrary level of reliability and/or availability, depending on the use case. A		arbitrary level of reliability and/or availability, depending on the use case. A
	strategy used by DetNet for providing extraordinarily high levels of reliability when		strategy used by DetNet for providing extraordinarily high levels of reliability when
	justified is to provide redundant paths between which traffic can be seamlessly		justified is to provide redundant paths between which traffic can be seamlessly
	switched, all the while maintaining the required performance of that system. </t>		switched, all the while maintaining the required performance of that system. </t>
	<t>Replication-related attacks are by definition applicable here. Cont roller plane attacks		<t>Replication-related attacks are by definition applicable here. Cont roller plane attacks
	can also interfere with the configuration of redundant paths.</t>		can also interfere with the configuration of redundant paths.</t>
	</section>		</section>
	<section title="Security Measures">		<section numbered="true" toc="default">
	<t>If any of the security mechanisms which protect the DetNet are atta		<name>Security Measures</name>
	cked or subverted,		<t>If any of the security mechanisms that protect the DetNet are attac
	this can result in malfunction of the network. Thus the security sys		ked or subverted,
	tems themselves		this can result in malfunction of the network. Thus, the security sy
	needs to be robust against attacks.</t>		stems themselves
			need to be robust against attacks.</t>
	<t>The general topic of protection of security mechanisms is not uniqu e to DetNet; it is		<t>The general topic of protection of security mechanisms is not uniqu e to DetNet; it is
	identical to the case of securing any security mechanism for any net work. This document		identical to the case of securing any security mechanism for any net work. This document
	addresses these concerns only to the extent that they are unique to DetNet.</t>		addresses these concerns only to the extent that they are unique to DetNet.</t>
	</section>		</section>
	</section>		</section>
	<section title="Summary of Attack Types per Use Case Common Theme">		<section numbered="true" toc="default">
	<t>The List of Attacks table <xref target="ThreatList"/> lists the attac		<name>Summary of Attack Types per Use Case Common Theme</name>
	ks of <xref		<t>The List of Attacks table (<xref target="ThreatList" format="default"
	target="ThreatSection"/>, Security Threats, assigning a number to ea		/>) lists the
	ch type of attack.		attacks described in <xref target="ThreatSection" format="default"/>,
	That number is then used as a short form identifier for the attack in		<xref
	<xref		target="ThreatSection" format="title"/>, assigning a number to each
	target="ThemeAttackMapping"/>, Mapping Between Themes and Attacks. <		type of attack. That
	/t>		number is then used as a short form identifier for the attack in <xref
	<figure align="center" anchor="ThreatList" title="List of Attacks">		target="ThemeAttackMapping" format="default"/>, Mapping between Them
	<artwork align="left">		es and Attacks.</t>
	<![CDATA[
	+----+-------------------------------------------+		<table anchor="ThreatList">
	| | Attack |		<name>List of Attacks</name>
	+----+-------------------------------------------+		<thead>
	| 1 |Delay Attack |		<tr>
	+----+-------------------------------------------+		<th/>
	| 2 |DetNet Flow Modification or Spoofing |		<th>Attack</th>
	+----+-------------------------------------------+		</tr>
	| 3 |Inter-Segment Attack |		</thead>
	+----+-------------------------------------------+		<tbody>
	| 4 |Replication: Increased attack surface |		<tr>
	+----+-------------------------------------------+		<td>1</td>
	| 5 |Replication-related Header Manipulation |		<td>Delay Attack</td>
	+----+-------------------------------------------+		</tr>
	| 6 |Path Manipulation |
	+----+-------------------------------------------+		<tr>
	| 7 |Path Choice: Increased Attack Surface |		<td>2</td>
	+----+-------------------------------------------+		<td>DetNet Flow Modification or Spoofing</td>
	| 8 |Control or Signaling Packet Modification |		</tr>
	+----+-------------------------------------------+		<tr>
	| 9 |Control or Signaling Packet Injection |		<td>3</td>
	+----+-------------------------------------------+		<td>Inter-segment Attack </td>
	| 10 |Reconnaissance |		</tr>
	+----+-------------------------------------------+		<tr>
	| 11 |Attacks on Time Synchronization Mechanisms |		<td>4</td>
	+----+-------------------------------------------+		<td>Replication: Increased Attack Surface</td>
	]]></artwork>		</tr>
	</figure>		<tr>
	<t>The Mapping Between Themes and Attacks table <xref target="ThemeAttac		<td>5</td>
	kMapping"/> maps the		<td>Replication-Related Header Manipulation</td>
	use case themes of <xref target="RFC8578"/> (as also enumerated in thi		</tr>
	s document) to the		<tr>
	attacks of <xref target="ThreatList"/>. Each row specifies a theme, an		<td>6</td>
	d the attacks		<td>Path Manipulation</td>
	relevant to this theme are marked with a '+'. The row items which have		</tr>
	no threats
	associated with them are included in the table for completeness of the		<tr>
	list of Use Case		<td>7</td>
	Common Themes, and do not have DetNet-specific threats associated with		<td>Path Choice: Increased Attack Surface</td>
	them. </t>		</tr>
	<figure align="center" anchor="ThemeAttackMapping"
	title="Mapping Between Themes and Attacks">		<tr>
	<artwork align="left">		<td>8</td>
	<![CDATA[		<td>Control or Signaling Packet Modification</td>
	+----------------------------+--------------------------------+		</tr>
	| Theme | Attack |		<tr>
	| +--+--+--+--+--+--+--+--+--+--+--+		<td>9</td>
	| | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|		<td>Control or Signaling Packet Injection</td>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		</tr>
	|Network Layer - AVB/TSN Eth.| +| +| +| +| +| +| +| +| +| +| +|		<tr>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<td>10</td>
	|Central Administration | | | | | | +| +| +| +| +| +|		<td>Reconnaissance</td>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		</tr>
	|Hot Swap | | +| +| | | | | | | | +|		<tr>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<td>11</td>
	|Data Flow Information Models| | | | | | | | | | | |		<td>Attacks on Time-Synchronization Mechanisms</td>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		</tr>
	|L2 and L3 Integration | | | | | | | | | | | |		</tbody>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		</table>
	|End-to-end Delivery | +| +| +| +| +| +| +| +| +| | +|
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<t>The Mapping between Themes and Attacks table (<xref target="ThemeAtta
	|Proprietary Deterministic | | | +| | | +| +| +| +| | |		ckMapping"
	|Ethernet Networks | | | | | | | | | | | |		format="default"/>) maps the use case themes of <xref target="RFC857
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		8" format="default"
	|Replacement for Proprietary | | | +| | | +| +| +| +| | |		/> (as also enumerated in this document) to the attacks of <xref targe
	|Fieldbuses | | | | | | | | | | | |		t="ThreatList"
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		format="default"/>. Each row specifies a theme, and the attacks rele
	|Deterministic vs. Best- | | | +| | | | | | | | |		vant to this theme
	|Effort Traffic | | | | | | | | | | | |		are marked with a "+". The row items that have no threats associated w
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		ith them are
	|Deterministic Flows | +| +| +| | +| +| | +| | | |		included in the table for completeness of the list of Use Case Common
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		Themes and do not
	|Unused Reserved Bandwidth | | +| +| | | | | +| +| | |		have DetNet-specific threats associated with them. </t>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+
	|Interoperability | | | | | | | | | | | |		<table anchor="ThemeAttackMapping">
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<name>Mapping between Themes and Attacks</name>
	|Cost Reductions | | | | | | | | | | | |		<thead>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<tr>
	|Insufficiently Secure | | | | | | | | | | | |		<th align="center" colspan="1" rowspan="2">Theme</th>
	|Components | | | | | | | | | | | |		<th align="center" colspan="11" rowspan="1">Attack</th>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		</tr>
	|DetNet Network Size | +| | | | | +| +| | | | +|
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<tr>
	|Multiple Hops | +| +| | | | +| +| | | | +|		<th align="center" colspan="1" rowspan="1">1</th>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<th align="center" colspan="1" rowspan="1">2</th>
	|Level of Service | | | | | | | | +| +| +| |		<th align="center" colspan="1" rowspan="1">3</th>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<th align="center" colspan="1" rowspan="1">4</th>
	|Bounded Latency | +| | | | | | | | | | +|		<th align="center" colspan="1" rowspan="1">5</th>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<th align="center" colspan="1" rowspan="1">6</th>
	|Low Latency | +| | | | | | | +| +| | +|		<th align="center" colspan="1" rowspan="1">7</th>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<th align="center" colspan="1" rowspan="1">8</th>
	|Bounded Jitter | +| | | | | | | | | | |		<th align="center" colspan="1" rowspan="1">9</th>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<th align="center" colspan="1" rowspan="1">10</th>
	|Symmetric Path Delays | +| | | | | | | | | | +|		<th align="center" colspan="1" rowspan="1">11</th>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		</tr>
	|Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +|		</thead>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<tbody>
	|Redundant Paths | | | | +| +| | | +| +| | |		<tr>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<td>Network Layer - AVB/TSN Eth.</td>
	|Security Measures | | | | | | | | | | | |		<td>+</td>
	+----------------------------+--+--+--+--+--+--+--+--+--+--+--+		<td>+</td>
	]]></artwork>		<td>+</td>
	</figure>		<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			</tr>
			<tr>
			<td>Central Administration</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			</tr>
			<tr>
			<td>Hot Swap</td>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			</tr>
			<tr>
			<td>Data Flow Information Models</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>L2 and L3 Integration</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>End-to-End Delivery</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td/>
			<td>+</td>
			<td/>
			</tr>
			<tr>
			<td>Proprietary Deterministic Ethernet Networks</td>
			<td/>
			<td/>
			<td>+</td>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Replacement for Proprietary Fieldbuses</td>
			<td/>
			<td/>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Deterministic vs. Best-Effort Traffic</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Deterministic Flows</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Unused Reserved Bandwidth</td>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Interoperability</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Cost Reductions</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Insufficiently Secure Components</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>DetNet Network Size</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			</tr>
			<tr>
			<td>Multiple Hops</td>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			</tr>
			<tr>
			<td>Level of Service</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td/>
			</tr>
			<tr>
			<td>Bounded Latency</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			</tr>
			<tr>
			<td>Low Latency</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td>+</td>
			</tr>
			<tr>
			<td>Bounded Jitter</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Symmetric Path Delays</td>
			<td>+</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			</tr>
			<tr>
			<td>Reliability and Availability</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			<td>+</td>
			</tr>
			<tr>
			<td>Redundant Paths</td>
			<td/>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			<td>+</td>
			<td>+</td>
			<td/>
			<td/>
			</tr>
			<tr>
			<td>Security Measures</td>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			<td/>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</section>		</section>
	<section title="Security Considerations for OAM Traffic">		<section numbered="true" toc="default">
			<name>Security Considerations for OAM Traffic</name>
	<t>This section considers DetNet-specific security considerations for pack et traffic that is		<t>This section considers DetNet-specific security considerations for pack et traffic that is
	generated and transmitted over a DetNet as part of OAM (Operations, Admi nistration, and		generated and transmitted over a DetNet as part of OAM (Operations, Admi nistration, and
	Maintenance). For the purposes of this discussion, OAM traffic falls int o one of two basic		Maintenance). For the purposes of this discussion, OAM traffic falls int o one of two basic
	types:</t>		types:</t>
	<t>		<ul spacing="normal">
	<list style="symbols">		<li>OAM traffic generated by the network itself. The additional bandwidt
	<t>OAM traffic generated by the network itself. The additional bandwid		h required for such
	th required for such		packets is added by the network administration, presumably transparent
	packets is added by the network administration, presumably transpare		to the customer.
	nt to the customer.		Security considerations for such traffic are not DetNet specific (apar
	Security considerations for such traffic are not DetNet-specific (ap		t from such traffic
	art from such		being subject to the same DetNet-specific security considerations as a
	traffic being subject to the same DetNet-specific security considera		ny other DetNet data
	tions as any other		flow) and are thus not covered in this document.</li>
	DetNet data flow) and are thus not covered in this document.</t>		<li>OAM traffic generated by the customer. From a DetNet security point
	<t>OAM traffic generated by the customer. From a DetNet security point		of view, DetNet
	of view, DetNet		security considerations for such traffic are exactly the same as for a
	security considerations for such traffic are exactly the same as for		ny other customer
	any other customer		data flows.</li>
	data flows.</t>		</ul>
	</list>		<t>From the perspective of an attack, OAM traffic is indistinguishable fro
	</t>		m DetNet traffic,
	<t>From the perspective of an attack, OAM traffic is indistinguishable fro		and the network needs to be secure against injection, removal, or modifi
	m DetNet traffic and		cation of traffic of
	the network needs to be secure against injection, removal, or modificati		any kind, including OAM traffic. A DetNet is sensitive to any form of pa
	on of traffic of any		cket injection,
	kind, including OAM traffic. A DetNet is sensitive to any form of packet		removal, or manipulation, and in this respect DetNet OAM traffic is no d
	injection, removal		ifferent. Techniques
	or manipulation and in this respect DetNet OAM traffic is no different.		for securing a DetNet against these threats have been discussed elsewher
	Techniques for		e in this
	securing a DetNet against these threats have been discussed elsewhere in		document.</t>
	this document.</t>
	</section>		</section>
	<section anchor="TechnologySpecificThreats" title="DetNet Technology-Specifi		<section anchor="TechnologySpecificThreats" numbered="true" toc="default">
	c Threats">		<name>DetNet Technology-Specific Threats</name>
	<t>		<t>
	<xref target="ThreatSection"/>, Security Threats, described threats whic		<xref target="ThreatSection" format="default"/>, <xref
	h are independent of		target="ThreatSection" format="title" />, describes threats that are
	a DetNet implementation. This section considers threats specifically rel		independent of a DetNet implementation. This section considers threats
	ated to the IP- and		specifically related to the IP- and MPLS-specific aspects of DetNet
	MPLS-specific aspects of DetNet implementations. </t>		implementations. </t>
	<t>The primary security considerations for the data plane specifically are		<t>The primary security considerations for the data plane specifically
	to maintain the		are to maintain the integrity of the data and the delivery of the
	integrity of the data and the delivery of the associated DetNet service		associated DetNet service traversing the DetNet network. </t>
	traversing the		<t>The primary relevant differences between IP and MPLS implementations
	DetNet network. </t>		are in flow identification and OAM methodologies.</t>
	<t>The primary relevant differences between IP and MPLS implementations ar		<t>As noted in <xref target="RFC8655" format="default"/>, DetNet
	e in flow		operates at the IP layer <xref target="RFC8939" format="default"/> and
	identification and OAM methodologies.</t>		delivers service over sub-layer technologies such as MPLS <xref
	<t>As noted in <xref target="RFC8655"/>, DetNet operates at the IP layer (		target="RFC8964" format="default"/> and IEEE 802.1 Time-Sensitive
	<xref		Networking (TSN) <xref target="RFC9023" format="default"/>. Application
	target="RFC8939"/>) and delivers service over sub-layer technologies s		flows can be protected through whatever means are provided by the layer
	uch as MPLS (<xref		and sub-layer technologies. For example, technology-specific encryption
	target="RFC8964"/>) and IEEE 802.1 Time-Sensitive Networking (TSN) (<x		may be used for IP flows (IPsec <xref target="RFC4301"
	ref		format="default"/>). For IP-over-Ethernet (Layer 2) flows using an
	target="I-D.ietf-detnet-ip-over-tsn"/>). Application flows can be prot		underlying sub-net, MACsec <xref target="IEEE802.1AE-2018"
	ected through		format="default"/> may be appropriate. For some use cases, packet
	whatever means are provided by the layer and sub-layer technologies. For		integrity protection without encryption may be sufficient. </t>
	example,		<t>However, if the DetNet nodes cannot decrypt IPsec traffic, then
	technology-specific encryption may be used, for example for IP flows, IP		DetNet flow identification for encrypted IP traffic flows must be
	Sec <xref		performed in a different way than it would be for unencrypted IP DetNet
	target="RFC4301"/>. For IP over Ethernet (Layer 2) flows using an unde		flows. The DetNet IP data plane identifies unencrypted flows via a
	rlying sub-net,		6-tuple that consists of two IP addresses, the transport protocol ID,
	MACSec <xref target="IEEE802.1AE-2018"/> may be appropriate. For some us		two transport protocol port numbers, and the DSCP in the IP header. When
	e cases packet		IPsec is used, the transport header is encrypted and the next protocol
	integrity protection without encryption may be sufficient. </t>		ID is an IPsec protocol, usually Encapsulating Security Payload (ESP),
	<t>However, if the DetNet nodes cannot decrypt IPsec traffic, then DetNet		and not a transport protocol, leaving only three components of the
	flow identification		6-tuple, which are the two IP addresses and the DSCP. If the IPsec
	for encrypted IP traffic flows must be performed in a different way than		sessions are established by a controller, then this controller could
	it would be for		also transmit (in the clear) the Security Parameter Index (SPI) and thus
	unencrypted IP DetNet flows. The DetNet IP Data Plane identifies unencry		the SPI could be used (in addition to the pair of IP addresses) for flow
	pted flows via a		identification. Identification of DetNet flows over IPsec is further
	6-tuple that consists of two IP addresses, the transport protocol ID, tw		discussed in <xref target="RFC8939" sectionFormat="of" section="5.1.2.3"
	o transport protocol		format="default"/>.</t>
	port numbers and the DSCP in the IP header. When IPsec is used, the tran
	sport header is
	encrypted and the next protocol ID is an IPsec protocol, usually ESP, an
	d not a transport
	protocol, leaving only three components of the 6-tuple, which are the tw
	o IP addresses and
	the DSCP. If the IPsec sessions are established by a controller, then th
	is controller could
	also transmit (in the clear) the Security Parameter Index (SPI) and thus
	the SPI could be
	used (in addition to the pair of IP addresses) for flow identification.
	Identification of
	DetNet flows over IPsec is further discussed in Section 5.1.2.3. of <xre
	f target="RFC8939"
	/>.</t>
	<t>Sections below discuss threats specific to IP and MPLS in more detail.< /t>		<t>Sections below discuss threats specific to IP and MPLS in more detail.< /t>
	<section title="IP">
	<t>The IP protocol has a long history of security considerations and arc		<section numbered="true" toc="default">
	hitectural		<name>IP</name>
	protection mechanisms. From a data plane perspective DetNet does not a		<t>IP has a long history of security considerations and architectural pr
	dd or modify any IP		otection mechanisms.
	header information, so the carriage of DetNet traffic over an IP data		From a data plane perspective, DetNet does not add or modify any IP he
	plane does not		ader information, so
	introduce any new security issues that were not there before, apart fr		the carriage of DetNet traffic over an IP data plane does not introduc
	om those already		e any new security
	described in the data-plane-independent threats section <xref target="		issues that were not there before, apart from those already described
	ThreatSection"/>,		in the
	Security Threats. </t>		data-plane-independent threats section (<xref target="ThreatSection" f
	<t>Thus the security considerations for a DetNet based on an IP data pla		ormat="default"/>). </t>
	ne are purely		<t>Thus, the security considerations for a DetNet based on an IP data pl
	inherited from the rich IP Security literature and code/application ba		ane are purely
	se, and the		inherited from the rich IP security literature and code/application ba
			se, and the
	data-plane-independent section of this document. </t>		data-plane-independent section of this document. </t>
	<t>Maintaining security for IP segments of a DetNet may be more challeng ing than for the		<t>Maintaining security for IP segments of a DetNet may be more challeng ing than for the
	MPLS segments of the network, given that the IP segments of the networ		MPLS segments of the network given that the IP segments of the network
	k may reach the		may reach the edges
	edges of the network, which are more likely to involve interaction wit		of the network, which are more likely to involve interaction with pote
	h potentially		ntially malevolent
	malevolent outside actors. Conversely MPLS is inherently more secure t		outside actors. Conversely, MPLS is inherently more secure than IP sin
	han IP since it is		ce it is internal to
	internal to routers and it is well-known how to protect it from outsid		routers and it is well known how to protect it from outside influence.
	e influence. </t>		</t>
	<t>Another way to look at DetNet IP security is to consider it in the li		<t>Another way to look at DetNet IP security is to consider it in the li
	ght of VPN security;		ght of VPN security.
	as an industry we have a lot of experience with VPNs running through n		As an industry, we have a lot of experience with VPNs running through
	etworks with other		networks with other
	VPNs, it is well known how to secure the network for that. However for		VPNs -- it is well known how to secure the network for that. However,
	a DetNet we have		for a DetNet, we
	the additional subtlety that any possible interaction of one packet wi		have the additional subtlety that any possible interaction of one pack
	th another can have		et with another can
	a potentially deleterious effect on the time properties of the flows.		have a potentially deleterious effect on the time properties of the fl
	So the network must		ows. So the network
	provide sufficient isolation between flows, for example by protecting		must provide sufficient isolation between flows, for example, by prote
	the forwarding		cting the forwarding
	bandwidth and related resources so that they are available to detnet t		bandwidth and related resources so that they are available to DetNet t
	raffic, by whatever		raffic, by whatever
	means are appropriate for the data plane of that network, for example		means are appropriate for the data plane of that network, for example,
	through the use of		through the use of
	queueing mechanisms. </t>		queuing mechanisms. </t>
	<t>In a VPN, bandwidth is generally guaranteed over a period of time, wh		<t>In a VPN, bandwidth is generally guaranteed over a period of time whe
	ereas in DetNet it		reas in DetNet, it
	is not aggregated over time. This implies that any VPN-type protection mechanism must also		is not aggregated over time. This implies that any VPN-type protection mechanism must also
	maintain the DetNet timing constraints. </t>		maintain the DetNet timing constraints. </t>
	</section>		</section>
	<section title="MPLS">		<section numbered="true" toc="default">
			<name>MPLS</name>
	<t>An MPLS network carrying DetNet traffic is expected to be a "well-man aged" network. Given		<t>An MPLS network carrying DetNet traffic is expected to be a "well-man aged" network. Given
	that this is the case, it is difficult for an attacker to pass a raw M PLS encoded packet		that this is the case, it is difficult for an attacker to pass a raw M PLS-encoded packet
	into a network because operators have considerable experience at exclu ding such packets at		into a network because operators have considerable experience at exclu ding such packets at
	the network boundaries, as well as excluding MPLS packets being insert		the network boundaries as well as excluding MPLS packets being inserte
	ed through the use		d through the use of
	of a tunnel.</t>		a tunnel.</t>
	<t>MPLS security is discussed extensively in <xref target="RFC5920"/> ("		<t>MPLS security is discussed extensively in <xref target="RFC5920" form
	Security Framework		at="default"/>
	for MPLS and GMPLS Networks") to which the reader is referred. </t>		("<xref target="RFC5920" format="title"/>") to which the reader is r
	<t>		eferred. </t>
	<xref target="RFC6941"/> builds on <xref target="RFC5920"/> by providi
	ng additional
	security considerations that are applicable to the MPLS-TP extensions
	appropriate to the
	MPLS Transport Profile <xref target="RFC5921"/>, and thus to the opera
	tion of DetNet over
	some types of MPLS network. </t>
	<t>		<t>
	<xref target="RFC5921"/> introduces to MPLS new Operations, Administra		<xref target="RFC6941" format="default"/> builds on <xref target="RFC5
	tion, and		920"
	Maintenance (OAM) capabilities, a transport-oriented path protection m		format="default"/> by providing additional security considerations t
	echanism, and strong		hat are applicable
	emphasis on static provisioning supported by network management system		to the MPLS-TP extensions appropriate to the MPLS Transport Profile <x
	s. </t>		ref target="RFC5921"
			format="default"/> and thus to the operation of DetNet over some typ
			es of MPLS network. </t>
			<t>
			<xref target="RFC5921" format="default"/> introduces to MPLS new Opera
			tions,
			Administration, and Maintenance (OAM) capabilities; a transport-orient
			ed path protection
			mechanism; and strong emphasis on static provisioning supported by net
			work management
			systems. </t>
	<t>The operation of DetNet over an MPLS network builds on MPLS and pseud owire encapsulation.		<t>The operation of DetNet over an MPLS network builds on MPLS and pseud owire encapsulation.
	Thus for guidance on securing the DetNet elements of DetNet over MPLS		Thus, for guidance on securing the DetNet elements of DetNet over MPLS
	the reader is also		, the reader is also
	referred to the security considerations of <xref target="RFC4385"/>, <		referred to the security considerations of <xref target="RFC4385" form
	xref		at="default"/>,
	target="RFC5586"/>, <xref target="RFC3985"/>, <xref target="RFC6073"		<xref target="RFC5586" format="default"/>, <xref target="RFC3985" fo
	/>, and <xref		rmat="default"/>,
	target="RFC6478"/>. </t>		<xref target="RFC6073" format="default"/>, and <xref target="RFC6478
			" format="default"
	<t>Having attended to the conventional aspects of network security it is		/>. </t>
	necessary to attend		<t>Having attended to the conventional aspects of network security, it i
	to the dynamic aspects. The closest experience that the IETF has with		s necessary to
	securing protocols		attend to the dynamic aspects. The closest experience that the IETF ha
	that are sensitive to manipulation of delay are the two way time trans		s with securing
	fer protocols		protocols that are sensitive to manipulation of delay are the two-way
	(TWTT), which are NTP <xref target="RFC5905"/> and Precision Time Prot		time transfer (TWTT)
	ocol <xref		protocols, which are NTP <xref target="RFC5905" format="default"/> and
	target="IEEE1588"/>. The security requirements for these are describ		the Precision Time
	ed in <xref		Protocol <xref target="IEEE1588" format="default"/>. The security requ
	target="RFC7384"/>. </t>		irements for these
			are described in <xref target="RFC7384" format="default"/>. </t>
	<t>One particular problem that has been observed in operational tests of TWTT protocols is		<t>One particular problem that has been observed in operational tests of TWTT protocols is
	the ability for two closely but not completely synchronized flows to b eat and cause a		the ability for two closely but not completely synchronized flows to b eat and cause a
	sudden phase hit to one of the flows. This can be mitigated by the car eful use of a		sudden phase hit to one of the flows. This can be mitigated by the car eful use of a
	scheduling system in the underlying packet transport. </t>		scheduling system in the underlying packet transport. </t>
	<t>Some investigations into protection of MPLS systems against dynamic a ttacks exist, such		<t>Some investigations into protection of MPLS systems against dynamic a ttacks exist, such
	as <xref target="I-D.ietf-mpls-opportunistic-encrypt"/>; perhaps deplo		as <xref target="I-D.ietf-mpls-opportunistic-encrypt" format="default"
	yment of DetNets		/>; perhaps
	will encourage additional such investigations.</t>		deployment of DetNets will encourage additional such investigations.</
			t>
	</section>		</section>
	</section>		</section>
	<!-- Section: Technology Specific Attacks -->
	<!-- Possibly a 'Contributors' section ... -->		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">		<name>IANA Considerations</name>
	<t>This document includes no requests from IANA.</t>		<t>This document has no IANA actions.</t>
	</section>		</section>
	<section anchor="Security" title="Security Considerations">		<section anchor="Security" numbered="true" toc="default">
			<name>Security Considerations</name>
	<t>The security considerations of DetNet networks are presented throughout this document. </t>		<t>The security considerations of DetNet networks are presented throughout this document. </t>
	</section>		</section>
	<section anchor="Privacy" title="Privacy Considerations">		<section anchor="Privacy" numbered="true" toc="default">
			<name>Privacy Considerations</name>
	<t>Privacy in the context of DetNet is maintained by the base technologies specific to the		<t>Privacy in the context of DetNet is maintained by the base technologies specific to the
	DetNet and user traffic. For example TSN can use MACsec, IP can use IPse		DetNet and user traffic. For example, TSN can use MACsec, IP can use IPs
	c, applications can		ec, and applications
	use IP transport protocol-provided methods e.g. TLS and DTLS. MPLS typic		can use IP transport protocol-provided methods, e.g., TLS and DTLS. MPLS
	ally uses L2/L3 VPNs		typically uses
	combined with the previously mentioned privacy methods. </t>		L2/L3 VPNs combined with the previously mentioned privacy methods. </t>
	<t>However, note that reconnaissance threats such as traffic analysis and monitoring of		<t>However, note that reconnaissance threats such as traffic analysis and monitoring of
	electrical side channels can still cause there to be privacy considerati ons even when		electrical side channels can still cause there to be privacy considerati ons even when
	traffic is encrypted.</t>		traffic is encrypted.</t>
	</section>		</section>
	<section title="Contributors">
	<t>The Editor would like to recognize the contributions of the following i
	ndividuals to this
	draft. </t>
	<figure>
	<artwork><![CDATA[
	Subir Das (Applied Communication Sciences)		</middle>
	150 Mount Airy Road, Basking Ridge, New Jersey, 07920, USA
	email sdas@appcomsci.com
	John Dowdell (Airbus Defence and Space)		<back>
	Celtic Springs, Newport, NP10 8FZ, United Kingdom
	email john.dowdell.ietf@gmail.com
	Henrik Austad (SINTEF Digital)		<displayreference target="I-D.ietf-detnet-ip-oam" to="DETNET-IP-OAM"/>
	Klaebuveien 153, Trondheim, 7037, Norway		<displayreference target="I-D.ietf-detnet-mpls-oam" to="DETNET-MPLS-OAM"/>
	email henrik@austad.us		<displayreference target="I-D.ietf-detnet-yang" to="DETNET-YANG"/>
			<displayreference target="I-D.varga-detnet-service-model" to="DETNET-SERVICE
			-MODEL"/>
			<displayreference target="I-D.ietf-mpls-opportunistic-encrypt" to="MPLS-OPP-
			ENCRYPT"/>
			<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="IPSECME-G-IKEV2"/>
	Norman Finn (Huawei)		<references>
	3101 Rio Way, Spring Valley, California 91977, USA		<name>References</name>
	email nfinn@nfinnconsulting.com		<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8939.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8964.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8938.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8655.xml"/>
			</references>
			<references>
			<name>Informative References</name>
	Stewart Bryant (Futurewei Technologies)		<xi:include
			href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-detn
			et-ip-oam.xml"/>
	email: stewart.bryant@gmail.com		<xi:include
			href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-detn
			et-mpls-oam.xml"/>
	David Black (Dell EMC)		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	176 South Street, Hopkinton, MA 01748, USA		FC.9025.xml"/>
	email: david.black@dell.com
	Carsten Bormann (Universitat Bremen TZI)		<reference anchor="RFC9056" target="https://www.rfc-editor.org/info/rfc9
	Postfach 330440, D-28359 Bremen, Germany		056">
	email: cabo@tzi.org		<front>
			<title>Deterministic Networking (DetNet) Data Plane: IP over MPLS</t
			itle>
	]]></artwork>		<author initials="B" surname="Varga" fullname="Balazs Varga" role="e
	</figure>		ditor">
	</section>		<organization/>
	</middle>		</author>
	<!-- *****BACK MATTER ***** -->
	<back>
	<references title="Normative References">
	<?rfc include='reference.RFC.8939.xml'?>
	<?rfc include='reference.RFC.8964.xml'?>
	<?rfc include='reference.RFC.8938.xml'?>
	<?rfc include='reference.RFC.8655.xml'?>
	</references>
	<references title="Informative References">
	<?rfc include='reference.I-D.ietf-detnet-ip-oam.xml'?>
	<?rfc include='reference.I-D.ietf-detnet-mpls-oam.xml'?>
	<?rfc include='reference.I-D.ietf-detnet-mpls-over-udp-ip.xml'?>
	<?rfc include='reference.I-D.ietf-detnet-ip-over-mpls.xml'?>
	<?rfc include='reference.I-D.ietf-detnet-yang.xml'?>
	<!-- <?rfc include='reference.I-D.ietf-tictoc-1588overmpls'?> -->
	<?rfc include='reference.I-D.varga-detnet-service-model.xml'?>
	<?rfc include='reference.I-D.ietf-detnet-flow-information-model.xml'?>
	<?rfc include='reference.I-D.ietf-detnet-ip-over-tsn.xml'?>
	<?rfc include='reference.I-D.ietf-mpls-opportunistic-encrypt.xml'?>
	<?rfc include='reference.I-D.ietf-ipsecme-g-ikev2.xml'?>
	<?rfc include='reference.RFC.2474.xml'?>
	<?rfc include='reference.RFC.2475.xml'?>
	<?rfc include='reference.RFC.3552.xml'?>
	<?rfc include='reference.RFC.3985.xml'?>
	<?rfc include='reference.RFC.4107.xml'?>
	<?rfc include='reference.RFC.4301.xml'?>
	<?rfc include='reference.RFC.4302.xml'?>
	<?rfc include='reference.RFC.5880.xml'?>
	<?rfc include='reference.RFC.5905.xml'?>
	<?rfc include='reference.RFC.5920.xml'?>
	<?rfc include='reference.RFC.5921.xml'?>
	<?rfc include='reference.RFC.6071.xml'?>
	<?rfc include='reference.RFC.6073.xml'?>
	<?rfc include='reference.RFC.6274.xml'?>
	<?rfc include='reference.RFC.6478.xml'?>
	<?rfc include='reference.RFC.6562.xml'?>
	<?rfc include='reference.RFC.6632.xml'?>
	<?rfc include='reference.RFC.6941.xml'?>
	<?rfc include='reference.RFC.7384.xml'?>
	<?rfc include='reference.RFC.7567.xml'?>
	<?rfc include='reference.RFC.7641.xml'?>
	<?rfc include='reference.RFC.7835.xml'?>
	<?rfc include='reference.RFC.8446.xml'?>
	<?rfc include='reference.RFC.8578.xml'?>
	<?rfc include='reference.RFC.4253.xml'?>
	<?rfc include='reference.RFC.7748.xml'?>
	<?rfc include='reference.RFC.4432.xml'?>
	<?rfc include='reference.RFC.4385.xml'?>
	<?rfc include='reference.RFC.5586.xml'?>
	<reference anchor="IETF_YANG_SEC"		<author initials="L" surname="Berger" fullname="Lou Berger">
	target="https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines">		<organization/>
	<front>		</author>
	<title>YANG Module Security Considerations</title>
	<author>		<author initials="D" surname="Fedyk" fullname="Don Fedyk">
	<organization>IETF</organization>		<organization/>
	</author>		</author>
	<date year="2018"/>
	</front>		<author initials="S" surname="Bryant" fullname="Stewart Bryant">
	</reference>		<organization/>
	<reference anchor="IEEE1588">		</author>
	<front>
	<title>IEEE 1588 Standard for a Precision Clock Synchronization Protoc		<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
	ol for Networked		<organization/>
	Measurement and Control Systems Version 2 </title>		</author>
	<author>
	<organization>IEEE</organization>		<date month="June" year="2021"/>
	</author>
	<date year="2008"/>		</front>
	</front>		<seriesInfo name="RFC" value="9056"/>
	</reference>		<seriesInfo name="DOI" value="10.17487/RFC9056"/>
	<reference anchor="ARINC664P7">		</reference>
	<front>
	<title>ARINC 664 Aircraft Data Network, Part 7, Avionics Full-Duplex S		<xi:include
	witched Ethernet		href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-detn
	Network </title>		et-yang.xml"/>
	<author>
	<organization>ARINC</organization>		<reference anchor="I-D.varga-detnet-service-model">
	</author>		<front>
	<date year="2009"/>		<title>DetNet Service Model</title>
	</front>
	</reference>		<author initials="B" surname="Varga" fullname="Balazs Varga" role="e
	<reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org/d		ditor">
	ocument/8585421">		<organization/>
	<front>		</author>
	<title>IEEE Std 802.1AE-2018 MAC Security (MACsec)</title>
	<author>		<author initials="J" surname="Farkas" fullname="Janos Farkas">
	<organization>IEEE Standards Association</organization>		<organization/>
	</author>		</author>
	<date year="2018"/>
	</front>		<date month="May" year="2017"/>
	</reference>		</front>
	<reference anchor="IEEE802.1Qch-2017" target="https://ieeexplore.ieee.org/		<seriesInfo name="Internet-Draft" value="draft-varga-detnet-service-mo
	document/7961303">		del-02"/>
	<front>		</reference>
	<title>IEEE Standard for Local and metropolitan area networks--Bridges
	and Bridged		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	Networks--Amendment 29: Cyclic Queuing and Forwarding</title>		FC.9016.xml"/>
	<author>
	<organization>IEEE Standards Association</organization>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9023.
	</author>		xml"/>
	<date year="2017"/>
	</front>		<xi:include
	</reference>		href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-mpls
	<reference anchor="IEEE802.1Qbv-2015" target="https://ieeexplore.ieee.org/		-opportunistic-encrypt.xml"/>
	document/8613095">
	<front>		<xi:include
	<title>IEEE Standard for Local and metropolitan area networks -- Bridg		href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ipse
	es and Bridged		cme-g-ikev2.xml"/>
	Networks - Amendment 25: Enhancements for Scheduled Traffic</title>
	<author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<organization>IEEE Standards Association</organization>		FC.2474.xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<date year="2015"/>		FC.2475.xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>		FC.3985.xml"/>
	<reference anchor="IEEE802.1BA" target="https://ieeexplore.ieee.org/docume		<referencegroup anchor="BCP107" target="https://www.rfc-editor.org/info/
	nt/6032690">		bcp107">
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference
	<title>IEEE Standard for Local and Metropolitan Area Networks -- Audio		.RFC.4107.xml"/>
	Video Bridging		</referencegroup>
	(AVB) Systems</title>
	<author>		<referencegroup anchor="BCP72" target="https://www.rfc-editor.org/info/b
	<organization>IEEE Standards Association</organization>		cp72">
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference
	<date year="2011"/>		.RFC.3552.xml"/>
	</front>		</referencegroup>
	</reference>
	<reference anchor="IT_DEF" target="https://en.wikiquote.org/wiki/Informati		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	on_technology">		FC.4301.xml"/>
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<title>IT Definition</title>		FC.4302.xml"/>
	<author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<organization>Wikipedia</organization>		FC.5880.xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<date year="2020"/>		FC.5905.xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>		FC.5920.xml"/>
	<reference anchor="OT_DEF" target="https://en.wikipedia.org/wiki/Operation		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	al_technology">		FC.5921.xml"/>
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<title>OT Definition</title>		FC.6071.xml"/>
	<author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<organization>Wikipedia</organization>		FC.6073.xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<date year="2020"/>		FC.6274.xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>		FC.6478.xml"/>
	<reference anchor="RS_DEF" target="https://en.wikipedia.org/wiki/Network_s		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	egmentation">		FC.6562.xml"/>
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<title>RS Definition</title>		FC.6632.xml"/>
	<author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<organization>Wikipedia</organization>		FC.6941.xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<date year="2020"/>		FC.7384.xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>		FC.7567.xml"/>
	<reference anchor="IEEE802.1Q" target="https://ieeexplore.ieee.org/documen		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	t/6991462">		FC.7641.xml"/>
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<title>IEEE Standard for Local and metropolitan area networks--Bridges		FC.7835.xml"/>
	and Bridged		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	Networks - Annex J - Connectivity Fault Management </title>		FC.8446.xml"/>
	<author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<organization>IEEE Standards Association</organization>		FC.8578.xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<date year="2014"/>		FC.4253.xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>		FC.7748.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4432.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4385.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5586.xml"/>
			<reference anchor="IETF-YANG-SEC"
			target="https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines">
			<front>
			<title>YANG module security considerations</title>
			<author>
			<organization>IETF</organization>
			</author>
			<date year="2018" month="October"/>
			</front>
			</reference>
			<reference anchor="IEEE1588">
			<front>
			<title>IEEE 1588 Standard for a Precision Clock Synchronization Prot
			ocol for Networked
			Measurement and Control Systems</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date month="July" year="2008"/>
			</front>
			<seriesInfo name="IEEE Std." value="1588-2008"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
			</reference>
			<reference anchor="ARINC664P7">
			<front>
			<title>Aircraft Data Network Part 7 Avionics Full-Duplex Switched Et
			hernet
			Network</title>
			<author>
			<organization>ARINC</organization>
			</author>
			<date month="September" year="2009"/>
			</front>
			<seriesInfo name="ARINC" value="664 P7"/>
			</reference>
			<reference anchor="IEEE802.1AE-2018" target="https://ieeexplore.ieee.org
			/document/8585421">
			<front>
			<title>IEEE Standard for Local and metropolitan area networks-Media
			Access Control (MAC)
			Security</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date year="2018" month="December"/>
			</front>
			<seriesInfo name="IEEE Std." value="802.1AE-2018"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
			</reference>
			<reference anchor="IEEE802.1Qch-2017" target="https://ieeexplore.ieee.or
			g/document/7961303">
			<front>
			<title>IEEE Standard for Local and metropolitan area networks--Bridg
			es and Bridged
			Networks--Amendment 29: Cyclic Queuing and Forwarding</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date year="2017" month="June"/>
			</front>
			<seriesInfo name="IEEE Std." value="802.1Qch-2017"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.7961303"/>
			</reference>
			<reference anchor="IEEE802.1Qbv-2015" target="https://ieeexplore.ieee.or
			g/document/8613095">
			<front>
			<title>IEEE Standard for Local and metropolitan area networks -- Bri
			dges and Bridged
			Networks - Amendment 25: Enhancements for Scheduled Traffic</title
			>
			<author>
			<organization>IEEE</organization>
			</author>
			<date year="2016" month="March"/>
			</front>
			<seriesInfo name="IEEE Std." value="802.1Qbv-2015"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.8613095"/>
			</reference>
			<reference anchor="IEEE802.1BA" target="https://ieeexplore.ieee.org/docu
			ment/6032690">
			<front>
			<title>IEEE Standard for Local and metropolitan area networks--Audio
			Video Bridging
			(AVB) Systems</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date year="2011" month="September"/>
			</front>
			<seriesInfo name="IEEE Std." value="802.1BA-2011"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2011.6032690"/>
			</reference>
			<reference anchor="IT-DEF"
			target="https://en.wikiquote.org/w/index.php?title=Information_technol
			ogy&amp;oldid=2749907">
			<front>
			<title>Information technology</title>
			<author>
			<organization>Wikipedia</organization>
			</author>
			<date year="2020" month="March"/>
			</front>
			</reference>
			<reference anchor="OT-DEF"
			target="https://en.wikipedia.org/w/index.php?title=Operational_technol
			ogy&amp;oldid=1011704361">
			<front>
			<title>Operational technology</title>
			<author>
			<organization>Wikipedia</organization>
			</author>
			<date year="2021" month="March"/>
			</front>
			</reference>
			<reference anchor="NS-DEF"
			target="https://en.wikipedia.org/w/index.php?title=Network_segmentatio
			n&amp;oldid=993163264">
			<front>
			<title>Network segmentation</title>
			<author>
			<organization>Wikipedia</organization>
			</author>
			<date year="2020" month="December"/>
			</front>
			</reference>
			<reference anchor="IEEE802.1Q" target="https://ieeexplore.ieee.org/docum
			ent/6991462">
			<front>
			<title>IEEE Standard for Local and metropolitan area networks--Bridg
			es and Bridged
			Networks</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date year="2014" month="December"/>
			</front>
			<seriesInfo name="IEEE Std." value="802.1Q-2014"/>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6991462"/>
			</reference>
			</references>
	</references>		</references>
	<!-- Change Log
	v00 2017-02-22 TM Initial version
	v00 2017-03-09 EAG Edited for clarity, incorporated comments from sdt review.
	v01 2017-06-26 EAG Added Impact, Mitigation and Use Case Associations text.
	v01 2017-06-29 EAG Integrated review input and Association by Use Case Industr
	y text.
	v00 2017-10-04 EAG First post-WG-adoption (draft-ietf-detnet) version, version
	reset to 00.
	Clarify text regarding "Flow Identification" vs "Flow Modif
	ication..."
	1) Remove spurious "DetNet Flow Identification" section he
	ader,
	2) Move 4.2.1. Flow identification text to a new Impact -
	Reconnaissance section.
	Add missing sections to Impact section - even if empty, mar
	k as ToDo.
	Mention that impacts as described assume that mitigation is
	not present or has failed.
	v00 2017-10-09 EAG Rewrite use case themes questions as statements. Update use
	cases/threats table.
	v00 2017-10-25 EAG Add text for new use cases - to Intro, Industry table, Indu
	stry text, etc.
	v02 2018-04-23 EAG Just bump revision to keep draft alive.
	v03 2018-10-16 EAG Add OAM considerations section. Update Tal affiliation. Add
	new Commmon Theme: Bounded Jitter.
	v04 2019-02-11 EAG Add possible impact of DP delay on physical device e.g. Ind
	ustrial per Rodney. Add Maik text to use case appendix.
	v04 2019-03-02 EAG Added Encryption Considerations section per list discussion
	.
	v05 2019-08-29 EAG Add sections for dataplane-specific considerations (IP, MPL
	S, TSN).
	Update Use Cases references to RFC 8578.
	v06 2019-11-02 EAG Add placeholder text from Stewart for MPLS dataplane-specif
	ic considerations.
	Removed Kevin Stanton as author.
	Added "dummy traffic insertion" based on Norm's comment.
	Clarified that authentication is used for traffic origin ve
	rification (not encryption) per Henrik.
	Added Packet Sequence Number Integrity Considerations per N
	orm comment.
	Occasional auto-reformat changes.
	v07 2020-01-10 EAG
	Cut "security statements from drafts" (Appendix A). Add "Re
	ader is assumed to be familiar with the other drafts".
	Limit scope to IP and MPLS. (i.e. cut TSN and references to
	future data planes)
	Incorporate comment from IETF 106 that flow ID and OAM are
	the relevant differentiators between MPLS and IP data planes.
	Note that MPLS is inherently more secure than IP since it is
	internal to routers.
	Add assumption of a "very well managed network (both data pl
	ane and control plane)" as a starting place for this draft.
	Incorporate some items from Stewart's review of 12/17/2019 a
	nd Henrik's comments 10Jan20.
	Replace "draft" with "document" where appropriate.
	Put in trivial text for "todo" sections.
	v08 2020-02-03 EAG
	Incorporate more review items from Stewart's review of 12/17
	/2019 (expanded via phone call of 3Feb20).
	v09 2020-03-17 EAG, Henrik
	Address review items from Lou, email dated 16Mar20
	v10 2020-05-30 EAG
	Address review items from David Black, email dated 21Apr20;
	this included creating new sections Component Design and DiffServ.
	v11 2020-08-14 EAG
	Address the "simple" review items from Adrian Farrel IESG Ro
	uting Area review. Another pass will be required to address the deeper comments.
	v12 2020-10-01 EAG
	Address remaining items from Adrian Farrel IESG Routing Area
	review, and from Ben Kaduk, thanks to David, Stewart, Lou.
	Move Andrew Hacker back to Author role. Move EAG to first au
	thor.
	v13 2020-12-11 EAG
	Addressed secdir AD review items from Russ Housely (done) an
	d Yaron (still one more to go, but it is significant).
	v14 2021-02-01 EAG
	Addressed remaining AD comment from Yaron. Addressed secdir
	AD review items from
	Magnus Westerlund, Murray Kucherawy, Eric Vyncke, Roman Dany
	liw, Benjamin Kaduk,
	Robert Wilton, and Barry Leiba.
	v15 2021-02-22 EAG
	Fix "RSA key pairs generated on the fly" text per Yaron and B
	en.
	v16 2021-02-26 EAG
	Address draft 15 comments from Ben Kaduk.
	Fix typo: Move sec 8.3. Security Considerations for OAM Traff
	ic out from under 8. Association of Attacks to Use Cases.
	-->		<section numbered="false" toc="default">
			<name>Contributors</name>
			<t>The Editor would like to recognize the contributions of the following
			individuals to this document. </t>
			<author fullname="Stewart Bryant" initials="S" surname="Bryant">
			<organization abbrev="">Futurewei Technologies</organization>
			<address>
			<postal>
			<street/>
			<city/>
			<region/>
			<code/>
			<country/>
			</postal>
			<phone/>
			<email>sb@stewartbryant.com</email>
			<uri/>
			</address>
			</author>
			<author fullname="David Black" initials="D" surname="Black">
			<organization abbrev="">Dell EMC</organization>
			<address>
			<postal>
			<street>176 South Street</street>
			<city>Hopkinton</city>
			<region>Massachusetts</region>
			<code>01748</code>
			<country>United States of America</country>
			</postal>
			<phone/>
			<email/>
			<uri/>
			</address>
			</author>
			<author fullname="Henrik Austad" initials="H" surname="Austad">
			<organization abbrev="">SINTEF Digital</organization>
			<address>
			<postal>
			<street>Klaebuveien 153</street>
			<city>Trondheim</city>
			<region/>
			<code>7037</code>
			<country>Norway</country>
			</postal>
			<phone/>
			<email>henrik@austad.us</email>
			<uri/>
			</address>
			</author>
			<author fullname="John Dowdell" initials="J" surname="Dowdell">
			<organization abbrev="">Airbus Defence and Space</organization>
			<address>
			<postal>
			<street/>
			<city>Celtic Springs</city>
			<region/>
			<code>Newport, NP10 8FZ</code>
			<country>United Kingdom</country>
			</postal>
			<phone/>
			<email>john.dowdell.ietf@gmail.com</email>
			<uri/>
			</address>
			</author>
			<author fullname="Norman Finn" initials="N" surname="Finn">
			<organization abbrev=""/>
			<address>
			<postal>
			<street>3101 Rio Way</street>
			<city>Spring Valley</city>
			<region>California</region>
			<code>91977</code>
			<country>United States of America</country>
			</postal>
			<phone/>
			<email>nfinn@nfinnconsulting.com</email>
			<uri/>
			</address>
			</author>
			<author fullname="Subir Das" initials="S" surname="Das">
			<organization abbrev="">Applied Communication Sciences</organization>
			<address>
			<postal>
			<street>150 Mount Airy Road</street>
			<city>Basking Ridge</city>
			<region>New Jersey</region>
			<code>07920</code>
			<country>United States of America</country>
			</postal>
			<phone/>
			<email>sdas@appcomsci.com</email>
			<uri/>
			</address>
			</author>
			<author fullname="Carsten Bormann" initials="C" surname="Bormann">
			<organization abbrev="">Universitat Bremen TZI</organization>
			<address>
			<postal>
			<street/>
			<city>D-28359 Bremen</city>
			<region/>
			<code>Postfach 330440</code>
			<country>Germany</country>
			</postal>
			<phone/>
			<email>cabo@tzi.org</email>
			<uri/>
			</address>
			</author>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 283 change blocks.
	2245 lines changed or deleted		3242 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/