idnits 2.17.1 draft-ietf-detnet-security-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2020) is 1567 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2475' is defined on line 1719, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-03 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-04 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-04 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Mizrahi 3 Internet-Draft HUAWEI 4 Intended status: Informational E. Grossman, Ed. 5 Expires: July 13, 2020 DOLBY 6 A. Hacker 7 MISTIQ 8 S. Das 9 Applied Communication Sciences 10 J. Dowdell 11 Airbus Defence and Space 12 H. Austad 13 SINTEF Digital 14 N. Finn 15 HUAWEI 16 January 10, 2020 18 Deterministic Networking (DetNet) Security Considerations 19 draft-ietf-detnet-security-07 21 Abstract 23 A deterministic network is one that can carry data flows for real- 24 time applications with extremely low data loss rates and bounded 25 latency. Deterministic networks have been successfully deployed in 26 real-time operational technology (OT) applications for some years. 27 However, such networks are typically isolated from external access, 28 and thus the security threat from external attackers is low. IETF 29 Deterministic Networking (DetNet) specifies a set of technologies 30 that enable creation of deterministic networks on IP-based networks 31 of potentially wide area (on the scale of a corporate network) 32 potentially bringing the OT network into contact with Information 33 Technology (IT) traffic and security threats that lie outside of a 34 tightly controlled and bounded area (such as the internals of an 35 aircraft). These DetNet technologies have not previously been 36 deployed together on a wide area IP-based network, and thus can 37 present security considerations that may be new to IP-based wide area 38 network designers. This document, intended for use by DetNet network 39 designers, provides insight into these security considerations. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on July 13, 2020. 58 Copyright Notice 60 Copyright (c) 2020 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 6 79 3.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7 80 3.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 7 82 3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7 83 3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7 84 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7 85 3.2.4. Packet Replication and Elimination . . . . . . . . . 8 86 3.2.4.1. Replication: Increased Attack Surface . . . . . . 8 87 3.2.4.2. Replication-related Header Manipulation . . . . . 8 88 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 8 89 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8 90 3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9 91 3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9 92 3.2.6.1. Control or Signaling Packet Modification . . . . 9 93 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 94 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 95 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 97 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9 98 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 99 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 100 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13 101 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13 102 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 13 103 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14 104 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14 105 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14 106 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14 107 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14 108 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15 109 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15 110 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15 111 4.4. Replication and Elimination . . . . . . . . . . . . . . . 15 112 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15 113 4.4.2. Header Manipulation at Elimination Bridges . . . . . 16 114 4.5. Control or Signaling Packet Modification . . . . . . . . 16 115 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 116 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 117 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 118 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 119 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 17 120 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17 121 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 122 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 18 123 5.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 18 124 5.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18 125 5.5.1. Encryption Considerations for DetNet . . . . . . . . 19 126 5.6. Control and Signaling Message Protection . . . . . . . . 20 127 5.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 20 128 5.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 21 129 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 22 130 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 22 131 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22 132 6.1.2. Central Administration . . . . . . . . . . . . . . . 23 133 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 23 134 6.1.4. Data Flow Information Models . . . . . . . . . . . . 24 135 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 24 136 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 24 137 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 25 138 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 25 139 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25 140 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 26 141 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 26 142 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 27 143 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 27 144 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 27 145 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27 146 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 28 147 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28 148 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 29 149 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 29 150 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29 151 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29 152 6.1.22. Reliability and Availability . . . . . . . . . . . . 30 153 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 30 154 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30 155 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 31 156 6.3. Security Considerations for OAM Traffic . . . . . . . . . 33 157 7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33 158 7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 159 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 35 160 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 161 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 162 10. Informative References . . . . . . . . . . . . . . . . . . . 36 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 165 1. Introduction 167 Security is of particularly high importance in DetNet networks 168 because many of the use cases which are enabled by DetNet [RFC8578] 169 include control of physical devices (power grid components, 170 industrial controls, building controls) which can have high 171 operational costs for failure, and present potentially attractive 172 targets for cyber-attackers. 174 This situation is even more acute given that one of the goals of 175 DetNet is to provide a "converged network", i.e. one that includes 176 both IT traffic and OT traffic, thus exposing potentially sensitive 177 OT devices to attack in ways that were not previously common (usually 178 because they were under a separate control system or otherwise 179 isolated from the IT network, for example [ARINC664P7]). Security 180 considerations for OT networks are not a new area, and there are many 181 OT networks today that are connected to wide area networks or the 182 Internet; this document focuses on the issues that are specific to 183 the DetNet technologies and use cases. 185 Given the above considerations, securing a DetNet starts with a 186 scrupulously well-designed and well-managed engineered network 187 following industry best practices for security at both the data plane 188 and control plane; this is the assumed starting point for the 189 considerations discussed herein. In this context we view the network 190 design and managment aspects of network security as being primarily 191 concerned with denial-of service prevention by ensuring that DetNet 192 traffic goes where it's supposed to and that an external attacker 193 can't inject traffic that disrupts the DetNet's delivery timing 194 assurance. The time-specific aspects of DetNet security presented 195 here take up where the design and management aspects leave off. 197 The security requirements for any given DetNet network are 198 necessarily specific to the use cases handled by that network. Thus 199 the reader is assumed to be familiar with the specific security 200 requirements of their use cases, for example those outlined in the 201 DetNet Use Cases [RFC8578] and the Security Considerations sections 202 of the DetNet documents applicable to the network technologies in 203 use, for example [I-D.ietf-detnet-ip]). 205 The DetNet technologies include ways to: 207 o Reserve data plane resources for DetNet flows in some or all of 208 the intermediate nodes (e.g. bridges or routers) along the path of 209 the flow 211 o Provide explicit routes for DetNet flows that do not rapidly 212 change with the network topology 214 o Distribute data from DetNet flow packets over time and/or space to 215 ensure delivery of each packet's data' in spite of the loss of a 216 path 218 This document includes sections on threat modeling and analysis, 219 threat impact and mitigation, and the association of attacks with use 220 cases based on the Use Case Common Themes section of the DetNet Use 221 Cases [RFC8578]. 223 2. Abbreviations 225 IT Information technology (the application of computers to 226 store, study, retrieve, transmit, and manipulate data or information, 227 often in the context of a business or other enterprise - Wikipedia). 229 OT Operational Technology (the hardware and software 230 dedicated to detecting or causing changes in physical processes 231 through direct monitoring and/or control of physical devices such as 232 valves, pumps, etc. - Wikipedia) 234 MITM Man in the Middle 236 SN Sequence Number 238 STRIDE Addresses risk and severity associated with threat 239 categories: Spoofing identity, Tampering with data, Repudiation, 240 Information disclosure, Denial of service, Elevation of privilege. 242 DREAD Compares and prioritizes risk represented by these threat 243 categories: Damage potential, Reproducibility, Exploitability, how 244 many Affected users, Discoverability. 246 PTP Precision Time Protocol [IEEE1588] 248 3. Security Threats 250 This section presents a threat model, and analyzes the possible 251 threats in a DetNet-enabled network. The threats considered in this 252 section are independent of any specific technologies used to 253 implement the DetNet; Section 7) considers attacks that are 254 associated with the DetNet technologies encompassed by 255 [I-D.ietf-detnet-data-plane-framework]. 257 We distinguish control plane threats from data plane threats. The 258 attack surface may be the same, but the types of attacks as well as 259 the motivation behind them, are different. For example, a delay 260 attack is more relevant to data plane than to control plane. There 261 is also a difference in terms of security solutions: the way you 262 secure the data plane is often different than the way you secure the 263 control plane. 265 3.1. Threat Model 267 The threat model used in this memo is based on the threat model of 268 Section 3.1 of [RFC7384]. This model classifies attackers based on 269 two criteria: 271 o Internal vs. external: internal attackers either have access to a 272 trusted segment of the network or possess the encryption or 273 authentication keys. External attackers, on the other hand, do 274 not have the keys and have access only to the encrypted or 275 authenticated traffic. 277 o Man in the Middle (MITM) vs. packet injector: MITM attackers are 278 located in a position that allows interception and modification of 279 in-flight protocol packets, whereas a traffic injector can only 280 attack by generating protocol packets. 282 Care has also been taken to adhere to Section 5 of [RFC3552], both 283 with respect to which attacks are considered out-of-scope for this 284 document, but also which are considered to be the most common threats 285 (explored further in Section 3.2. Most of the direct threats to 286 DetNet are Active attacks, but it is highly suggested that DetNet 287 application developers take appropriate measures to protect the 288 content of the streams from passive attacks. 290 DetNet-Service, one of the service scenarios described in 291 [I-D.varga-detnet-service-model], is the case where a service 292 connects DetNet networking islands, i.e. two or more otherwise 293 independent DetNet network domains are connected via a link that is 294 not intrinsically part of either network. This implies that there 295 could be DetNet traffic flowing over a non-DetNet link, which may 296 provide an attacker with an advantageous opportunity to tamper with 297 DetNet traffic. The security properties of non-DetNet links are 298 outside of the scope of DetNet Security, but it should be noted that 299 use of non-DetNet services to interconnect DetNet networks merits 300 security analysis to ensure the integrity of the DetNet networks 301 involved. 303 3.2. Threat Analysis 305 3.2.1. Delay 307 3.2.1.1. Delay Attack 309 An attacker can maliciously delay DetNet data flow traffic. By 310 delaying the traffic, the attacker can compromise the service of 311 applications that are sensitive to high delays or to high delay 312 variation. The delay may be constant or modulated. 314 3.2.2. DetNet Flow Modification or Spoofing 316 An attacker can modify some header fields of en route packets in a 317 way that causes the DetNet flow identification mechanisms to 318 misclassify the flow. Alternatively, the attacker can inject traffic 319 that is tailored to appear as if it belongs to a legitimate DetNet 320 flow. The potential consequence is that the DetNet flow resource 321 allocation cannot guarantee the performance that is expected when the 322 flow identification works correctly. 324 3.2.3. Resource Segmentation or Slicing 326 3.2.3.1. Inter-segment Attack 328 An attacker can inject traffic, consuming network device resources, 329 thereby affecting DetNet flows. This can be performed using non- 330 DetNet traffic that affects DetNet traffic, or by using DetNet 331 traffic from one DetNet flow that affects traffic from different 332 DetNet flows. 334 3.2.4. Packet Replication and Elimination 336 3.2.4.1. Replication: Increased Attack Surface 338 Redundancy is intended to increase the robustness and survivability 339 of DetNet flows, and replication over multiple paths can potentially 340 mitigate an attack that is limited to a single path. However, the 341 fact that packets are replicated over multiple paths increases the 342 attack surface of the network, i.e., there are more points in the 343 network that may be subject to attacks. 345 3.2.4.2. Replication-related Header Manipulation 347 An attacker can manipulate the replication-related header fields 348 (R-TAG). This capability opens the door for various types of 349 attacks. For example: 351 o Forward both replicas - malicious change of a packet SN (Sequence 352 Number) can cause both replicas of the packet to be forwarded. 353 Note that this attack has a similar outcome to a replay attack. 355 o Eliminate both replicas - SN manipulation can be used to cause 356 both replicas to be eliminated. In this case an attacker that has 357 access to a single path can cause packets from other paths to be 358 dropped, thus compromising some of the advantage of path 359 redundancy. 361 o Flow hijacking - an attacker can hijack a DetNet flow with access 362 to a single path by systematically replacing the SNs on the given 363 path with higher SN values. For example, an attacker can replace 364 every SN value S with a higher value S+C, where C is a constant 365 integer. Thus, the attacker creates a false illusion that the 366 attacked path has the lowest delay, causing all packets from other 367 paths to be eliminated. Once the flow is hijacked the attacker 368 can either replace en route packets with malicious packets, or 369 simply injecting errors, causing the packets to be dropped at 370 their destination. 372 3.2.5. Path Choice 374 3.2.5.1. Path Manipulation 376 An attacker can maliciously change, add, or remove a path, thereby 377 affecting the corresponding DetNet flows that use the path. 379 3.2.5.2. Path Choice: Increased Attack Surface 381 One of the possible consequences of a path manipulation attack is an 382 increased attack surface. Thus, when the attack described in the 383 previous subsection is implemented, it may increase the potential of 384 other attacks to be performed. 386 3.2.6. Control Plane 388 3.2.6.1. Control or Signaling Packet Modification 390 An attacker can maliciously modify en route control packets in order 391 to disrupt or manipulate the DetNet path/resource allocation. 393 3.2.6.2. Control or Signaling Packet Injection 395 An attacker can maliciously inject control packets in order to 396 disrupt or manipulate the DetNet path/resource allocation. 398 3.2.7. Scheduling or Shaping 400 3.2.7.1. Reconnaissance 402 A passive eavesdropper can identify DetNet flows and then gather 403 information about en route DetNet flows, e.g., the number of DetNet 404 flows, their bandwidths, their schedules, or other temporal 405 properties. The gathered information can later be used to invoke 406 other attacks on some or all of the flows. 408 Note that in some cases DetNet flows may be identified based on an 409 explicit DetNet header, but in some cases the flow identification may 410 be based on fields from the L3/L4 headers. If L3/L4 headers are 411 involved, for purposes of this document we assume they are encrypted 412 and/or integrity-protected from external attackers. 414 3.2.8. Time Synchronization Mechanisms 416 An attacker can use any of the attacks described in [RFC7384] to 417 attack the synchronization protocol, thus affecting the DetNet 418 service. 420 3.3. Threat Summary 422 A summary of the attacks that were discussed in this section is 423 presented in Figure 1. For each attack, the table specifies the type 424 of attackers that may invoke the attack. In the context of this 425 summary, the distinction between internal and external attacks is 426 under the assumption that a corresponding security mechanism is being 427 used, and that the corresponding network equipment takes part in this 428 mechanism. 430 +-----------------------------------------+----+----+----+----+ 431 | Attack | Attacker Type | 432 | +---------+---------+ 433 | |Internal |External | 434 | |MITM|Inj.|MITM|Inj.| 435 +-----------------------------------------+----+----+----+----+ 436 |Delay attack | + | + | + | + | 437 +-----------------------------------------+----+----+----+----+ 438 |DetNet Flow Modification or Spoofing | + | + | | | 439 +-----------------------------------------+----+----+----+----+ 440 |Inter-segment Attack | + | + | | | 441 +-----------------------------------------+----+----+----+----+ 442 |Replication: Increased Attack Surface | + | + | + | + | 443 +-----------------------------------------+----+----+----+----+ 444 |Replication-related Header Manipulation | + | | | | 445 +-----------------------------------------+----+----+----+----+ 446 |Path Manipulation | + | + | | | 447 +-----------------------------------------+----+----+----+----+ 448 |Path Choice: Increased Attack Surface | + | + | + | + | 449 +-----------------------------------------+----+----+----+----+ 450 |Control or Signaling Packet Modification | + | | | | 451 +-----------------------------------------+----+----+----+----+ 452 |Control or Signaling Packet Injection | | + | | | 453 +-----------------------------------------+----+----+----+----+ 454 |Reconnaissance | + | | + | | 455 +-----------------------------------------+----+----+----+----+ 456 |Attacks on Time Sync Mechanisms | + | + | + | + | 457 +-----------------------------------------+----+----+----+----+ 459 Figure 1: Threat Analysis Summary 461 4. Security Threat Impacts 463 This section describes and rates the impact of the attacks described 464 in Section 3. In this section, the impacts as described assume that 465 the associated mitigation is not present or has failed. Mitigations 466 are discussed in Section 5. 468 In computer security, the impact (or consequence) of an incident can 469 be measured in loss of confidentiality, integrity or availability of 470 information. 472 DetNet raises these stakes significantly for OT applications, 473 particularly those which may have been designed to run in an OT-only 474 environment and thus may not have been designed for security in an IT 475 environment with its associated devices, services and protocols. 477 The severity of various components of the impact of a successful 478 vulnerability exploit to use cases by industry is available in more 479 detail in [RFC8578]. Each of the use cases in the DetNet Use Cases 480 is represented in the table below, including Pro Audio, Electrical 481 Utilities, Industrial M2M (split into two areas, M2M Data Gathering 482 and M2M Control Loop), and others. 484 Components of Impact (left column) include Criticality of Failure, 485 Effects of Failure, Recovery, and DetNet Functional Dependence. 486 Criticality of failure summarizes the seriousness of the impact. The 487 impact of a resulting failure can affect many different metrics that 488 vary greatly in scope and severity. In order to reduce the number of 489 variables, only the following were included: Financial, Health and 490 Safety, People well being (People WB), Affect on a single 491 organization, and affect on multiple organizations. Recovery 492 outlines how long it would take for an affected use case to get back 493 to its pre-failure state (Recovery time objective, RTO), and how much 494 of the original service would be lost in between the time of service 495 failure and recovery to original state (Recovery Point Objective, 496 RPO). DetNet dependence maps how much the following DetNet service 497 objectives contribute to impact of failure: Time dependency, data 498 integrity, source node integrity, availability, latency/jitter. 500 The scale of the Impact mappings is low, medium, and high. In some 501 use cases there may be a multitude of specific applications in which 502 DetNet is used. For simplicity this section attempts to average the 503 varied impacts of different applications. This section does not 504 address the overall risk of a certain impact which would require the 505 likelihood of a failure happening. 507 In practice any such ratings will vary from case to case; the ratings 508 shown here are given as examples. 510 Table, Part One (of Two) 511 +------------------+-----------------------------------------+-----+ 512 | | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M | 513 | | | | | less | |Data |Ctrl | 514 +------------------+-----------------------------------------+-----+ 515 | Criticality | Med | Hi | Low | Med | Med | Med | Med | 516 +------------------+-----------------------------------------+-----+ 517 | Effects 518 +------------------+-----------------------------------------+-----+ 519 | Financial | Med | Hi | Med | Med | Low | Med | Med | 520 +------------------+-----------------------------------------+-----+ 521 | Health/Safety | Med | Hi | Hi | Med | Med | Med | Med | 522 +------------------+-----------------------------------------+-----+ 523 | People WB | Med | Hi | Hi | Low | Hi | Low | Low | 524 +------------------+-----------------------------------------+-----+ 525 | Effect 1 org | Hi | Hi | Med | Hi | Med | Med | Med | 526 +------------------+-----------------------------------------+-----+ 527 | Effect >1 org | Med | Hi | Low | Med | Med | Med | Med | 528 +------------------+-----------------------------------------+-----+ 529 |Recovery 530 +------------------+-----------------------------------------+-----+ 531 | Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi | 532 +------------------+-----------------------------------------+-----+ 533 | Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi | 534 +------------------+-----------------------------------------+-----+ 535 |DetNet Dependence 536 +------------------+-----------------------------------------+-----+ 537 | Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi | 538 +------------------+-----------------------------------------+-----+ 539 | Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi | 540 +------------------+-----------------------------------------+-----+ 541 | Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Low | 542 +------------------+-----------------------------------------+-----+ 543 | Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi | 544 +------------------+-----------------------------------------+-----+ 545 | Availability | Hi | Hi | Med | Hi | Low | Hi | Hi | 546 +------------------+-----------------------------------------+-----+ 548 Table, Part Two (of Two) 549 +------------------+--------------------------+ 550 | | Mining | Block | Network | 551 | | | Chain | Slicing | 552 +------------------+--------------------------+ 553 | Criticality | Hi | Med | Hi | 554 +------------------+--------------------------+ 555 | Effects 556 +------------------+--------------------------+ 557 | Financial | Hi | Hi | Hi | 558 +------------------+--------------------------+ 559 | Health/Safety | Hi | Low | Med | 560 +------------------+--------------------------+ 561 | People WB | Hi | Low | Med | 562 +------------------+--------------------------+ 563 | Effect 1 org | Hi | Hi | Hi | 564 +------------------+--------------------------+ 565 | Effect >1 org | Hi | Low | Hi | 566 +------------------+--------------------------+ 567 |Recovery 568 +------------------+--------------------------+ 569 | Recov Time Obj | Hi | Low | Hi | 570 +------------------+--------------------------+ 571 | Recov Point Obj | Hi | Low | Hi | 572 +------------------+--------------------------+ 573 |DetNet Dependence 574 +------------------+--------------------------+ 575 | Time Dependency | Hi | Low | Hi | 576 +------------------+--------------------------+ 577 | Latency/Jitter | Hi | Low | Hi | 578 +------------------+--------------------------+ 579 | Data Integrity | Hi | Hi | Hi | 580 +------------------+--------------------------+ 581 | Src Node Integ | Hi | Hi | Hi | 582 +------------------+--------------------------+ 583 | Availability | Hi | Hi | Hi | 584 +------------------+--------------------------+ 586 Figure 2: Impact of Attacks by Use Case Industry 588 The rest of this section will cover impact of the different groups in 589 more detail. 591 4.1. Delay-Attacks 593 4.1.1. Data Plane Delay Attacks 595 Delayed messages in a DetNet link can result in the same behavior as 596 dropped messages in ordinary networks as the services attached to the 597 stream has strict deterministic requirements. 599 For a single path scenario, disruption is a real possibility, whereas 600 in a multipath scenario, large delays or instabilities in one stream 601 can lead to increased buffer and CPU resources on the elimination 602 bridge. 604 A data-plane delay attack on a system controlling substantial moving 605 devices, for example in industrial automation, can cause physical 606 damage. For example, if the network promises a bounded latency of 607 2ms for a flow, yet the machine receives it with 5ms latency, the 608 machine's control loop can become unstable. 610 4.1.2. Control Plane Delay Attacks 612 In and of itself, this is not directly a threat to the DetNet 613 service, but the effects of delaying control messages can have quite 614 adverse effects later. 616 o Delayed tear-down can lead to resource leakage, which in turn can 617 result in failure to allocate new streams finally giving rise to a 618 denial of service attack. 620 o Failure to deliver, or severely delaying, signalling messages 621 adding an end-point to a multicast-group will prevent the new EP 622 from receiving expected frames thus disrupting expected behavior. 624 o Delaying messages removing an EP from a group can lead to loss of 625 privacy as the EP will continue to receive messages even after it 626 is supposedly removed. 628 4.2. Flow Modification and Spoofing 630 4.2.1. Flow Modification 632 If the contents of a packet header or body can be modified by the 633 attacker, this can cause the packet to be routed incorrectly or 634 dropped, or the payload to be corrupted or subtly modified. 636 4.2.2. Spoofing 638 4.2.2.1. Dataplane Spoofing 640 Spoofing dataplane messages can result in increased resource 641 consumptions on the bridges throughout the network as it will 642 increase buffer usage and CPU utilization. This can lead to resource 643 exhaustion and/or increased delay. 645 If the attacker manages to create valid headers, the false messages 646 can be forwarded through the network, using part of the allocated 647 bandwidth. This in turn can cause legitimate messages to be dropped 648 when the budget has been exhausted. 650 Finally, the endpoint will have to deal with invalid messages being 651 delivered to the endpoint instead of (or in addition to) a valid 652 message. 654 4.2.2.2. Control Plane Spoofing 656 A successful control plane spoofing-attack will potentionally have 657 adverse effects. It can do virtually anything from: 659 o modifying existing streams by changing the available bandwidth 661 o add or remove endpoints from a stream 663 o drop streams completly 664 o falsely create new streams (exhaust the systems resources, or to 665 enable streams outside the Network engineer's control) 667 4.3. Segmentation attacks (injection) 669 4.3.1. Data Plane Segmentation 671 Injection of false messages in a DetNet stream could lead to 672 exhaustion of the available bandwidth for a stream if the bridges 673 accounts false messages to the stream's budget. 675 In a multipath scenario, injected messages will cause increased CPU 676 utilization in elimination bridges. If enough paths are subject to 677 malicious injection, the legitimate messages can be dropped. 678 Likewise it can cause an increase in buffer usage. In total, it will 679 consume more resources in the bridges than normal, giving rise to a 680 resource exhaustion attack on the bridges. 682 If a stream is interrupted, the end application will be affected by 683 what is now a non-deterministic stream. 685 4.3.2. Control Plane segmentation 687 A successful Control Plane segmentation attack control messages to be 688 interpreted by nodes in the network, unbeknownst to the central 689 controller or the network engineer. This has the potential to create 691 o new streams (exhausting resources) 693 o drop existing (denial of service) 695 o add/remove end-stations to a multicast group (loss of privacy) 697 o modify the stream attributes (affecting available bandwidth 699 4.4. Replication and Elimination 701 The Replication and Elimination is relevant only to Data Plane 702 messages as Signalling is not subject to multipath routing. 704 4.4.1. Increased Attack Surface 706 Covered briefly in Section 4.3 708 4.4.2. Header Manipulation at Elimination Bridges 710 Covered briefly in Section 4.3 712 4.5. Control or Signaling Packet Modification 714 If the control plane packets are subject to manipulation undetected, 715 the network can be severely compromised. 717 4.6. Control or Signaling Packet Injection 719 If an attacker can inject control plane packets undetected, the 720 network can be severely compromised. 722 4.7. Reconnaissance 724 Of all the attacks, this is one of the most difficult to detect and 725 counter. Often, an attacker will start out by observing the traffic 726 going through the network and use the knowledge gathered in this 727 phase to mount future attacks. 729 The attacker can, at their leisure, observe over time all aspects of 730 the messaging and signalling, learning the intent and purpose of all 731 traffic flows. At some later date, possibly at an important time in 732 an operational context, the attacker can launch a multi-faceted 733 attack, possibly in conjunction with some demand for ransom. 735 The flow-id in the header of the data plane-messages gives an 736 attacker a very reliable identifier for DetNet traffic, and this 737 traffic has a high probability of going to lucrative targets. 739 Applications which are ported from a private OT network to the higher 740 visibility DetNet environment may need to be adapted to limit 741 distinctive flow properties that could make them susceptible to 742 reconnaissance. 744 4.8. Attacks on Time Sync Mechanisms 746 Attacks on time sync mechanisms are addressed in [RFC7384]. 748 4.9. Attacks on Path Choice 750 This is covered in part in Section 4.3, and as with Replication and 751 Elimination (Section 4.4), this is relevant for DataPlane messages. 753 5. Security Threat Mitigation 755 This section describes a set of measures that can be taken to 756 mitigate the attacks described in Section 3. These mitigations 757 should be viewed as a toolset that includes several different and 758 diverse tools. Each application or system will typically use a 759 subset of these tools, based on a system-specific threat analysis. 761 5.1. Path Redundancy 763 Description 765 A DetNet flow that can be forwarded simultaneously over multiple 766 paths. Path replication and elimination [RFC8655] provides 767 resiliency to dropped or delayed packets. This redundancy 768 improves the robustness to failures and to man-in-the-middle 769 attacks. 771 Related attacks 773 Path redundancy can be used to mitigate various man-in-the-middle 774 attacks, including attacks described in Section 3.2.1, 775 Section 3.2.2, Section 3.2.3, and Section 3.2.8. However it is 776 also possible that multiple paths may make it more difficult to 777 locate the source of a MITM attacker. 779 5.2. Integrity Protection 781 Description 783 An integrity protection mechanism, such as a Hash-based Message 784 Authentication Code (HMAC) can be used to mitigate modification 785 attacks on IP packets. Integrity protection in the control plane 786 is discussed in Section 5.6. 788 Packet Sequence Number Integrity Considerations 790 The use of PREOF in a DetNet implementation implies the use of a 791 sequence number for each packet. There is a trust relationship 792 between the device that adds the sequence number and the device 793 that removes the sequence number. The sequence number may be end- 794 to-end source to destination, or may be added/deleted by network 795 edge devices. The adder and remover(s) have the trust 796 relationship because they are the ones that ensure that the 797 sequence numbers are not modifiable. Between those two points, 798 there may or may not be replication and elimination functions. 799 The elimination functions must be able to see the sequence 800 numbers. Therefore any encryption that is done between adders and 801 removers must not obscure the sequence number. If the sequence 802 removers and the eliminators are in the same physical device, it 803 may be possible to obscure the sequence number, however that is a 804 layer violation, and is not recommended practice. 806 Related attacks 808 Integrity protection mitigates attacks related to modification and 809 tampering, including the attacks described in Section 3.2.2 and 810 Section 3.2.4. 812 5.3. DetNet Node Authentication 814 Description 816 Source authentication verifies the authenticity of DetNet sources, 817 enabling mitigation of spoofing attacks. Note that while 818 integrity protection (Section 5.2) prevents intermediate nodes 819 from modifying information, authentication can provide traffic 820 origin verification, i.e. to verify that each packet in a DetNet 821 flow is from a trusted source. Authentication may be implemented 822 as part of ingress filtering, for example. 824 Related attacks 826 DetNet node authentication is used to mitigate attacks related to 827 spoofing, including the attacks of Section 3.2.2, and 828 Section 3.2.4. 830 5.4. Dummy Traffic Insertion 832 Description 834 With some queueing methods such as [IEEE802.1Qch-2017] it is 835 possible to introduce dummy traffic in order to regularize the 836 timing of packet transmission. 838 Related attacks 840 Removing distinctive temporal properties of individual packets or 841 flows can be used to mitigate against reconnaissance attacks 842 Section 3.2.7. 844 5.5. Encryption 846 Description 847 DetNet flows can be forwarded in encrypted form at the DetNet 848 layer. Alternatively, if the payload is end-to-end encrypted at 849 the application layer, the DetNet nodes should not have any need 850 to inspect the payload itself, and thus the DetNet implementation 851 can be data-agnostic. 853 Related attacks 855 Encryption can be used to mitigate recon attacks (Section 3.2.7). 856 However, for a DetNet network to give differentiated quality of 857 service on a flow-by-flow basis, the network must be able to 858 identify the flows individually. This implies that in a recon 859 attack the attacker may also be able to track individual flows to 860 learn more about the system. 862 5.5.1. Encryption Considerations for DetNet 864 Any compute time which is required for encryption and decryption 865 processing ('crypto') must be included in the flow latency 866 calculations. Thus, crypto algorithms used in a DetNet must have 867 bounded worst-case execution times, and these values must be used in 868 the latency calculations. 870 Some crypto algorithms are symmetric in encode/decode time (such as 871 AES) and others are asymmetric (such as public key algorithms). 872 There are advantages and disadvantages to the use of either type in a 873 given DetNet context. 875 Asymmetrical crypto is typically not used in networks on a packet-by- 876 packet basis due to its computational cost. For example, if only 877 endpoint checks or checks at a small number of intermediate points 878 are required, asymmetric crypto can be used to authenticate 879 distribution or exchange of a secret symmetric crypto key; a 880 successful check based on that key will provide traffic origin 881 verification, as long as the key is kept secret by the participants. 882 TLS and IKE (for IPsec) are examples of this for endpoint checks. 884 However, if secret symmetrical keys are used for this purpose the key 885 must be given to all relays, which increases the probability of a 886 secret key being leaked. Also, if any relay is compromised or 887 misbehaving it may inject traffic into the flow. 889 Alternatively, asymmetric crypto can provide traffic origin 890 verification at every intermediate node. For example, a DetNet flow 891 can be associated with an (asymmetric) keypair, such that the private 892 key is available to the source of the flow and the public key is 893 distributed with the flow information, allowing verification at every 894 node for every packet. However, this is more computationally 895 expensive. 897 In either case, origin verification also requires replay detection as 898 part of the security protocol to prevent an attacker from recording 899 and resending traffic, e.g., as a denial of service attack on flow 900 forwarding resources. 902 If crypto keys are to be regenerated over the duration of the flow 903 then the time required to accomplish this must be accounted for in 904 the latency calculations. 906 5.6. Control and Signaling Message Protection 908 Description 910 Control and sigaling messages can be protected using 911 authentication and integrity protection mechanisms. 913 Related attacks 915 These mechanisms can be used to mitigate various attacks on the 916 control plane, as described in Section 3.2.6, Section 3.2.8 and 917 Section 3.2.5. 919 5.7. Dynamic Performance Analytics 921 Description 923 Information about the network performance can be gathered in real- 924 time in order to detect anomalies and unusual behavior that may be 925 the symptom of a security attack. The gathered information can be 926 based, for example, on per-flow counters, bandwidth measurement, 927 and monitoring of packet arrival times. Unusual behavior or 928 potentially malicious nodes can be reported to a management 929 system, or can be used as a trigger for taking corrective actions. 930 The information can be tracked by DetNet end systems and transit 931 nodes, and exported to a management system, for example using 932 NETCONF. 934 Related attacks 936 Performance analytics can be used to mitigate various attacks, 937 including the ones described in Section 3.2.1 (Delay Attack), 938 Section 3.2.3 (Resource Segmentation Attack), and Section 3.2.8 939 (Time Sync Attack). 941 For example, in the case of data plane delay attacks, one possible 942 mitigation is to timestamp the data at the source, and timestamp 943 it again at the destination, and if the resulting latency exceeds 944 the promised bound, discard that data and warn the operator (and/ 945 or enter a fail-safe mode). 947 5.8. Mitigation Summary 949 The following table maps the attacks of Section 3 to the impacts of 950 Section 4, and to the mitigations of the current section. Each row 951 specifies an attack, the impact of this attack if it is successfully 952 implemented, and possible mitigation methods. 954 +----------------------+---------------------+---------------------+ 955 | Attack | Impact | Mitigations | 956 +----------------------+---------------------+---------------------+ 957 |Delay Attack |-Non-deterministic |-Path redundancy | 958 | | delay |-Performance | 959 | |-Data disruption | analytics | 960 | |-Increased resource | | 961 | | consumption | | 962 +----------------------+---------------------+---------------------+ 963 |Reconnaissance |-Enabler for other |-Encryption | 964 | | attacks |-Dummy traffic | 965 | | | insertion | 966 +----------------------+---------------------+---------------------+ 967 |DetNet Flow Modificat-|-Increased resource |-Path redundancy | 968 |ion or Spoofing | consumption |-Integrity protection| 969 | |-Data disruption |-DetNet Node | 970 | | | authentication | 971 +----------------------+---------------------+---------------------+ 972 |Inter-Segment Attack |-Increased resource |-Path redundancy | 973 | | consumption |-Performance | 974 | |-Data disruption | analytics | 975 +----------------------+---------------------+---------------------+ 976 |Replication: Increased|-All impacts of other|-Integrity protection| 977 |attack surface | attacks |-DetNet Node | 978 | | | authentication | 979 +----------------------+---------------------+---------------------+ 980 |Replication-related |-Non-deterministic |-Integrity protection| 981 |Header Manipulation | delay |-DetNet Node | 982 | |-Data disruption | authentication | 983 +----------------------+---------------------+---------------------+ 984 |Path Manipulation |-Enabler for other |-Control message | 985 | | attacks | protection | 986 +----------------------+---------------------+---------------------+ 987 |Path Choice: Increased|-All impacts of other|-Control message | 988 |Attack Surface | attacks | protection | 989 +----------------------+---------------------+---------------------+ 990 |Control or Signaling |-Increased resource |-Control message | 991 |Packet Modification | consumption | protection | 992 | |-Non-deterministic | | 993 | | delay | | 994 | |-Data disruption | | 995 +----------------------+---------------------+---------------------+ 996 |Control or Signaling |-Increased resource |-Control message | 997 |Packet Injection | consumption | protection | 998 | |-Non-deterministic | | 999 | | delay | | 1000 | |-Data disruption | | 1001 +----------------------+---------------------+---------------------+ 1002 |Attacks on Time Sync |-Non-deterministic |-Path redundancy | 1003 |Mechanisms | delay |-Control message | 1004 | |-Increased resource | protection | 1005 | | consumption |-Performance | 1006 | |-Data disruption | analytics | 1007 +----------------------+---------------------+---------------------+ 1009 Figure 3: Mapping Attacks to Impact and Mitigations 1011 6. Association of Attacks to Use Cases 1013 Different attacks can have different impact and/or mitigation 1014 depending on the use case, so we would like to make this association 1015 in our analysis. However since there is a potentially unbounded list 1016 of use cases, we categorize the attacks with respect to the common 1017 themes of the use cases as identified in the Use Case Common Themes 1018 section of the DetNet Use Cases [RFC8578]. 1020 See also Figure 2 for a mapping of the impact of attacks per use case 1021 by industry. 1023 6.1. Use Cases by Common Themes 1025 In this section we review each theme and discuss the attacks that are 1026 applicable to that theme, as well as anything specific about the 1027 impact and mitigations for that attack with respect to that theme. 1028 The table Figure 5 then provides a summary of the attacks that are 1029 applicable to each theme. 1031 6.1.1. Network Layer - AVB/TSN Ethernet 1033 DetNet is expected to run over various transmission mediums, with 1034 Ethernet being explicitly supported. Attacks such as Delay or 1035 Reconnaissance might be implemented differently on a different 1036 transmission medium, however the impact on the DetNet as a whole 1037 would be essentially the same. We thus conclude that all attacks and 1038 impacts that would be applicable to DetNet over Ethernet (i.e. all 1039 those named in this document) would also be applicable to DetNet over 1040 other transmission mediums. 1042 With respect to mitigations, some methods are specific to the 1043 Ethernet medium, for example time-aware scheduling using 802.1Qbv can 1044 protect against excessive use of bandwidth at the ingress - for other 1045 mediums, other mitigations would have to be implemented to provide 1046 analogous protection. 1048 6.1.2. Central Administration 1050 A DetNet network is expected to be controlled by a centralized 1051 network configuration and control system (CNC). Such a system may be 1052 in a single central location, or it may be distributed across 1053 multiple control entities that function together as a unified control 1054 system for the network. 1056 In this document we distinguish between attacks on the DetNet Control 1057 plane vs. Data plane. But is an attack affecting control plane 1058 packets synonymous with an attack on the CNC itself? For purposes of 1059 this document let us consider an attack on the CNC itself to be out 1060 of scope, and consider all attacks named in this document which are 1061 relevant to control plane packets to be relevant to this theme, 1062 including Path Manipulation, Path Choice, Control Packet Modification 1063 or Injection, Reconaissance and Attacks on Time Sync Mechanisms. 1065 6.1.3. Hot Swap 1067 A DetNet network is not expected to be "plug and play" - it is 1068 expected that there is some centralized network configuration and 1069 control system. However, the ability to "hot swap" components (e.g. 1070 due to malfunction) is similar enough to "plug and play" that this 1071 kind of behavior may be expected in DetNet networks, depending on the 1072 implementation. 1074 An attack surface related to Hot Swap is that the DetNet network must 1075 at least consider input at runtime from devices that were not part of 1076 the initial configuration of the network. Even a "perfect" (or 1077 "hitless") replacement of a device at runtime would not necessarily 1078 be ideal, since presumably one would want to distinguish it from the 1079 original for OAM purposes (e.g. to report hot swap of a failed 1080 device). 1082 This implies that an attack such as Flow Modification, Spoofing or 1083 Inter-segment (which could introduce packets from a "new" device 1084 (i.e. one heretofore unknown on the network) could be used to exploit 1085 the need to consider such packets (as opposed to rejecting them out 1086 of hand as one would do if one did not have to consider introduction 1087 of a new device). 1089 Similarly if the network was designed to support runtime replacement 1090 of a clock device, then presence (or apparent presence) and thus 1091 consideration of packets from a new such device could affect the 1092 network, or the time sync of the network, for example by initiating a 1093 new Best Master Clock selection process. Thus attacks on time sync 1094 should be considered when designing hot swap type functionality. 1096 6.1.4. Data Flow Information Models 1098 Data Flow Information Models specific to DetNet networks are to be 1099 specified by DetNet. Thus they are "new" and thus potentially 1100 present a new attack surface. Does the threat take advantage of any 1101 aspect of our new Data Flow Info Models? 1103 This is TBD, thus there are no specific entries in our table, however 1104 that does not imply that there could be no relevant attacks. 1106 6.1.5. L2 and L3 Integration 1108 A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN 1109 LAN) and Layer 3 (routed) networks via the use of well-known 1110 protocols such as IP, MPLS-PW, and Ethernet. 1112 There are no specific entries in our table, however that does not 1113 imply that there could be no relevant attacks related to L2,L3 1114 integration. 1116 6.1.6. End-to-End Delivery 1118 Packets sent over DetNet are not to be dropped by the network due to 1119 congestion. (Packets may however intentionally be dropped for 1120 intended reasons, e.g. per security measures). 1122 A Data plane attack may force packets to be dropped, for example a 1123 "long" Delay or Replication/Elimination or Flow Modification attack. 1125 The same result might be obtained by a Control plane attack, e.g. 1126 Path Manipulation or Signaling Packet Modification. 1128 It may be that such attacks are limited to Internal MITM attackers, 1129 but other possibilities should be considered. 1131 An attack may also cause packets that should not be delivered to be 1132 delivered, such as by forcing packets from one (e.g. replicated) path 1133 to be preferred over another path when they should not be 1134 (Replication attack), or by Flow Modification, or by Path Choice or 1135 Packet Injection. A Time Sync attack could cause a system that was 1136 expecting certain packets at certain times to accept unintended 1137 packets based on compromised system time or time windowing in the 1138 scheduler. 1140 Packets may also be dropped due to malfunctioning software or 1141 hardware. 1143 6.1.7. Proprietary Deterministic Ethernet Networks 1145 There are many proprietary non-interoperable deterministic Ethernet- 1146 based networks currently available; DetNet is intended to provide an 1147 open-standards-based alternative to such networks. In cases where a 1148 DetNet intersects with remnants of such networks or their protocols, 1149 such as by protocol emulation or access to such a network via a 1150 gateway, new attack surfaces can be opened. 1152 For example an Inter-Segment or Control plane attack such as Path 1153 Manipulation, Path Choice or Control Packet Modification/Injection 1154 could be used to exploit commands specific to such a protocol, or 1155 that are interpreted differently by the different protocols or 1156 gateway. 1158 6.1.8. Replacement for Proprietary Fieldbuses 1160 There are many proprietary "field buses" used in today's industrial 1161 and other industries; DetNet is intended to provide an open- 1162 standards-based alternative to such buses. In cases where a DetNet 1163 intersects with such fieldbuses or their protocols, such as by 1164 protocol emulation or access via a gateway, new attack surfaces can 1165 be opened. 1167 For example an Inter-Segment or Control plane attack such as Path 1168 Manipulation, Path Choice or Control Packet Modification/Injection 1169 could be used to exploit commands specific to such a protocol, or 1170 that are interpreted differently by the different protocols or 1171 gateway. 1173 6.1.9. Deterministic vs Best-Effort Traffic 1175 DetNet is intended to support coexistence of time-sensitive 1176 operational (OT, deterministic) traffic and information (IT, "best 1177 effort") traffic on the same ("unified") network. 1179 With DetNet, this coexistance will become more common, and 1180 mitigations will need to be established. The fact that the IT 1181 traffic on a DetNet is limited to a corporate controlled network 1182 makes this a less difficult problem compared to being exposed to the 1183 open Internet, however this aspect of DetNet security should not be 1184 underestimated. 1186 Most of the themes described in this document address OT (reserved) 1187 streams - this item is intended to address issues related to IT 1188 traffic on a DetNet. 1190 An Inter-segment attack can flood the network with IT-type traffic 1191 with the intent of disrupting handling of IT traffic, and/or the goal 1192 of interfering with OT traffic. Presumably if the stream reservation 1193 and isolation of the DetNet is well-designed (better-designed than 1194 the attack) then interference with OT traffic should not result from 1195 an attack that floods the network with IT traffic. 1197 However the DetNet's handling of IT traffic may not (by design) be as 1198 resilient to DOS attack, and thus designers must be otherwise 1199 prepared to mitigate DOS attacks on IT traffic in a DetNet. 1201 6.1.10. Deterministic Flows 1203 Reserved bandwidth data flows (deterministic flows) must provide the 1204 allocated bandwidth, and must be isolated from each other. 1206 A Spoofing or Inter-segment attack which adds packet traffic to a 1207 bandwidth-reserved stream could cause that stream to occupy more 1208 bandwidth than it is allocated, resulting in interference with other 1209 deterministic flows. 1211 A Flow Modification or Spoofing or Header Manipulation or Control 1212 Packet Modification attack could cause packets from one flow to be 1213 directed to another flow, thus breaching isolation between the flows. 1215 6.1.11. Unused Reserved Bandwidth 1217 If bandwidth reservations are made for a stream but the associated 1218 bandwidth is not used at any point in time, that bandwidth is made 1219 available on the network for best-effort traffic. If the owner of 1220 the reserved stream then starts transmitting again, the bandwidth is 1221 no longer available for best-effort traffic, on a moment-to-moment 1222 basis. (Such "temporarily available" bandwidth is not available for 1223 time-sensitive traffic, which must have its own reservation). 1225 An Inter-segment attack could flood the network with IT traffic, 1226 interfering with the intended IT traffic. 1228 A Flow Modification or Spoofing or Control Packet Modification or 1229 Injection attack could cause extra bandwidth to be reserved by a new 1230 or existing stream, thus making it unavailable for use by best-effort 1231 traffic. 1233 6.1.12. Interoperability 1235 The DetNet network specifications are intended to enable an ecosystem 1236 in which multiple vendors can create interoperable products, thus 1237 promoting device diversity and potentially higher numbers of each 1238 device manufactured. Does the threat take advantage of differences 1239 in implementation of "interoperable" products made by different 1240 vendors? 1242 This is TBD, thus there are no specific entries in our table, however 1243 that does not imply that there could be no relevant attacks. 1245 6.1.13. Cost Reductions 1247 The DetNet network specifications are intended to enable an ecosystem 1248 in which multiple vendors can create interoperable products, thus 1249 promoting higher numbers of each device manufactured, promoting cost 1250 reduction and cost competition among vendors. Does the threat take 1251 advantage of "low cost" HW or SW components or other "cost-related 1252 shortcuts" that might be present in devices? 1254 This is TBD, thus there are no specific entries in our table, however 1255 that does not imply that there could be no relevant attacks. 1257 6.1.14. Insufficiently Secure Devices 1259 The DetNet network specifications are intended to enable an ecosystem 1260 in which multiple vendors can create interoperable products, thus 1261 promoting device diversity and potentially higher numbers of each 1262 device manufactured. Does the threat attack "naivete" of SW, for 1263 example SW that was not designed to be sufficiently secure (or secure 1264 at all) but is deployed on a DetNet network that is intended to be 1265 highly secure? (For example IoT exploits like the Mirai video-camera 1266 botnet ([MIRAI]). 1268 This is TBD, thus there are no specific entries in our table, however 1269 that does not imply that there could be no relevant attacks. 1271 6.1.15. DetNet Network Size 1273 DetNet networks range in size from very small, e.g. inside a single 1274 industrial machine, to very large, for example a Utility Grid network 1275 spanning a whole country. 1277 The size of the network might be related to how the attack is 1278 introduced into the network, for example if the entire network is 1279 local, there is a threat that power can be cut to the entire network. 1280 If the network is large, perhaps only a part of the network is 1281 attacked. 1283 A Delay attack might be as relevant to a small network as to a large 1284 network, although the amount of delay might be different. 1286 Attacks sourced from IT traffic might be more likely in large 1287 networks, since more people might have access to the network. 1288 Similarly Path Manipulation, Path Choice and Time Sync attacks seem 1289 more likely relevant to large networks. 1291 6.1.16. Multiple Hops 1293 Large DetNet networks (e.g. a Utility Grid network) may involve many 1294 "hops" over various kinds of links for example radio repeaters, 1295 microwave links, fiber optic links, etc.. 1297 An attack that takes advantage of flaws (or even normal operation) in 1298 the device drivers for the various links (through internal knowledge 1299 of how the individual driver or firmware operates, perhaps like the 1300 Stuxnet attack) could take proportionately greater advantage of this 1301 topology. We don't currently have an attack like this defined; we 1302 have only "protocol" (time or packet) based attacks. Perhaps we need 1303 to define an attack like this? Or is that out of scope for DetNet? 1305 It is also possible that this DetNet topology will not be in as 1306 common use as other more homogeneous topologies so there may be more 1307 opportunity for attackers to exploit software and/or protocol flaws 1308 in the implementations which have not been wrung out by extensive 1309 use, particularly in the case of early adopters. 1311 Of the attacks we have defined, the ones identified above as relevant 1312 to "large" networks seem to be most relevant. 1314 6.1.17. Level of Service 1316 A DetNet is expected to provide means to configure the network that 1317 include querying network path latency, requesting bounded latency for 1318 a given stream, requesting worst case maximum and/or minimum latency 1319 for a given path or stream, and so on. It is an expected case that 1320 the network cannot provide a given requested service level. In such 1321 cases the network control system should reply that the requested 1322 service level is not available (as opposed to accepting the parameter 1323 but then not delivering the desired behavior). 1325 Control plane attacks such as Signaling Packet Modification and 1326 Injection could be used to modify or create control traffic that 1327 could interfere with the process of a user requesting a level of 1328 service and/or the network's reply. 1330 Reconnaissance could be used to characterize flows and perhaps target 1331 specific flows for attack via the Control plane as noted above. 1333 6.1.18. Bounded Latency 1335 DetNet provides the expectation of guaranteed bounded latency. 1337 Delay attacks can cause packets to miss their agreed-upon latency 1338 boundaries. 1340 Time Sync attacks can corrupt the system's time reference, resulting 1341 in missed latency deadlines (with respect to the "correct" time 1342 reference). 1344 6.1.19. Low Latency 1346 Applications may require "extremely low latency" however depending on 1347 the application these may mean very different latency values; for 1348 example "low latency" across a Utility grid network is on a different 1349 time scale than "low latency" in a motor control loop in a small 1350 machine. The intent is that the mechanisms for specifying desired 1351 latency include wide ranges, and that architecturally there is 1352 nothing to prevent arbitrarily low latencies from being implemented 1353 in a given network. 1355 Attacks on the Control plane (as described in the Level of Service 1356 theme) and Delay and Time attacks (as described in the Bounded 1357 Latency theme) both apply here. 1359 6.1.20. Bounded Jitter (Latency Variation) 1361 DetNet is expected to provide bounded jitter (packet to packet 1362 latency variation). 1364 Delay attacks can cause packets to vary in their arrival times, 1365 resulting in packet to packet latency variation, thereby violating 1366 the jitter specification. 1368 6.1.21. Symmetrical Path Delays 1370 Some applications would like to specify that the transit delay time 1371 values be equal for both the transmit and return paths. 1373 Delay attacks can cause path delays to differ. 1375 Time Sync attacks can corrupt the system's time reference, resulting 1376 in differing path delays (with respect to the "correct" time 1377 reference). 1379 6.1.22. Reliability and Availability 1381 DetNet based systems are expected to be implemented with essentially 1382 arbitrarily high availability (for example 99.9999% up time, or even 1383 12 nines). The intent is that the DetNet designs should not make any 1384 assumptions about the level of reliability and availability that may 1385 be required of a given system, and should define parameters for 1386 communicating these kinds of metrics within the network. 1388 Any attack on the system, of any type, can affect its overall 1389 reliability and availability, thus in our table we have marked every 1390 attack. Since every DetNet depends to a greater or lesser degree on 1391 reliability and availability, this essentially means that all 1392 networks have to mitigate all attacks, which to a greater or lesser 1393 degree defeats the purpose of associating attacks with use cases. It 1394 also underscores the difficulty of designing "extremely high 1395 reliability" networks. 1397 6.1.23. Redundant Paths 1399 DetNet based systems are expected to be implemented with essentially 1400 arbitrarily high reliability/availability. A strategy used by DetNet 1401 for providing such extraordinarily high levels of reliability is to 1402 provide redundant paths that can be seamlessly switched between, all 1403 the while maintaining the required performance of that system. 1405 Replication-related attacks are by definition applicable here. 1406 Control plane attacks can also interfere with the configuration of 1407 redundant paths. 1409 6.1.24. Security Measures 1411 A DetNet network must be made secure against devices failures, 1412 attackers, misbehaving devices, and so on. Does the threat affect 1413 such security measures themselves, e.g. by attacking SW designed to 1414 protect against device failure? 1416 This is TBD, thus there are no specific entries in our table, however 1417 that does not imply that there could be no relevant attacks. 1419 6.2. Attack Types by Use Case Common Theme 1421 The following table lists the attacks of Section 3, assigning a 1422 number to each type of attack. That number is then used as a short 1423 form identifier for the attack in Figure 5. 1425 +--+----------------------------------------+----------------------+ 1426 | | Attack | Section | 1427 +--+----------------------------------------+----------------------+ 1428 | 1|Delay Attack | Section 3.2.1 | 1429 +--+----------------------------------------+----------------------+ 1430 | 2|DetNet Flow Modification or Spoofing | Section 3.2.2 | 1431 +--+----------------------------------------+----------------------+ 1432 | 3|Inter-Segment Attack | Section 3.2.3 | 1433 +--+----------------------------------------+----------------------+ 1434 | 4|Replication: Increased attack surface | Section 3.2.4.1 | 1435 +--+----------------------------------------+----------------------+ 1436 | 5|Replication-related Header Manipulation | Section 3.2.4.2 | 1437 +--+----------------------------------------+----------------------+ 1438 | 6|Path Manipulation | Section 3.2.5.1 | 1439 +--+----------------------------------------+----------------------+ 1440 | 7|Path Choice: Increased Attack Surface | Section 3.2.5.2 | 1441 +--+----------------------------------------+----------------------+ 1442 | 8|Control or Signaling Packet Modification| Section 3.2.6.1 | 1443 +--+----------------------------------------+----------------------+ 1444 | 9|Control or Signaling Packet Injection | Section 3.2.6.2 | 1445 +--+----------------------------------------+----------------------+ 1446 |10|Reconnaissance | Section 3.2.7 | 1447 +--+----------------------------------------+----------------------+ 1448 |11|Attacks on Time Sync Mechanisms | Section 3.2.8 | 1449 +--+----------------------------------------+----------------------+ 1451 Figure 4: List of Attacks 1453 The following table maps the use case themes presented in this memo 1454 to the attacks of Figure 4. Each row specifies a theme, and the 1455 attacks relevant to this theme are marked with a '+'. 1457 +----------------------------+--------------------------------+ 1458 | Theme | Attack | 1459 | +--+--+--+--+--+--+--+--+--+--+--+ 1460 | | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11| 1461 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1462 |Network Layer - AVB/TSN Eth.| +| +| +| +| +| +| +| +| +| +| +| 1463 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1464 |Central Administration | | | | | | +| +| +| +| +| +| 1465 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1466 |Hot Swap | | +| +| | | | | | | | +| 1467 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1468 |Data Flow Information Models| | | | | | | | | | | | 1469 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1470 |L2 and L3 Integration | | | | | | | | | | | | 1471 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1472 |End-to-end Delivery | +| +| +| +| +| +| +| +| +| | +| 1473 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1474 |Proprietary Deterministic | | | +| | | +| +| +| +| | | 1475 |Ethernet Networks | | | | | | | | | | | | 1476 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1477 |Replacement for Proprietary | | | +| | | +| +| +| +| | | 1478 |Fieldbuses | | | | | | | | | | | | 1479 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1480 |Deterministic vs. Best- | | | +| | | | | | | | | 1481 |Effort Traffic | | | | | | | | | | | | 1482 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1483 |Deterministic Flows | | +| +| | +| +| | +| | | | 1484 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1485 |Unused Reserved Bandwidth | | +| +| | | | | +| +| | | 1486 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1487 |Interoperability | | | | | | | | | | | | 1488 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1489 |Cost Reductions | | | | | | | | | | | | 1490 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1491 |Insufficiently Secure | | | | | | | | | | | | 1492 |Devices | | | | | | | | | | | | 1493 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1494 |DetNet Network Size | +| | | | | +| +| | | | +| 1495 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1496 |Multiple Hops | +| +| | | | +| +| | | | +| 1497 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1498 |Level of Service | | | | | | | | +| +| +| | 1499 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1500 |Bounded Latency | +| | | | | | | | | | +| 1501 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1502 |Low Latency | +| | | | | | | +| +| +| +| 1503 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1504 |Bounded Jitter | +| | | | | | | | | | | 1505 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1506 |Symmetric Path Delays | +| | | | | | | | | | +| 1507 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1508 |Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +| 1509 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1510 |Redundant Paths | | | | +| +| | | +| +| | | 1511 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1512 |Security Measures | | | | | | | | | | | | 1513 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1515 Figure 5: Mapping Between Themes and Attacks 1517 6.3. Security Considerations for OAM Traffic 1519 This section considers DetNet-specific security considerations for 1520 packet traffic that is generated and transmitted over a DetNet as 1521 part of OAM (Operations, Administration and Maintenance). For 1522 purposes of this discussion, OAM traffic falls into one of two basic 1523 types: 1525 o OAM traffic generated by the network itself. The additional 1526 bandwidth required for such packets is added by the network 1527 administration, presumably transparent to the customer. Security 1528 considerations for such traffic are not DetNet-specific (apart 1529 from such traffic being subject to the same DetNet-specific 1530 security considerations as any other DetNet data flow) and are 1531 thus not covered in this document. 1533 o OAM traffic generated by the customer. From a DetNet security 1534 point of view, DetNet security considerations for such traffic are 1535 exactly the same as for any other customer data flows. 1537 Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet 1538 security considerations. 1540 7. DetNet Technology-Specific Threats 1542 Section 3 described threats which are independent of a DetNet 1543 implementation. This section considers threats specifically related 1544 to the IP- and MPLS-specific aspects of DetNet implementations. 1546 The primary security considerations for the data plane specifically 1547 are to maintain the integrity of the data and the delivery of the 1548 associated DetNet service traversing the DetNet network. 1550 The primary relevant differences between IP and MPLS implementations 1551 are in flow identification and OAM methodologies. 1553 As noted in [RFC8655], DetNet operates at the IP layer 1554 ([I-D.ietf-detnet-ip]) and delivers service over sub-layer 1555 technologies such as MPLS ([I-D.ietf-detnet-mpls]) and IEEE 802.1 1556 Time-Sensitive Networking (TSN) ([I-D.ietf-detnet-ip-over-tsn]). 1557 Application flows can be protected through whatever means are 1558 provided by the layer and sub-layer technologies. For example, 1559 technology-specific encryption may be used, such as that provided by 1560 IPSec [RFC4301] for IP flows and/or by an underlying sub-net using 1561 MACSec [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. 1563 However, if the DetNet nodes cannot decrypt IPsec traffic, IPSec may 1564 not be a valid option; this is because the DetNet IP data plane 1565 identifies flows via a 6-tuple that consists of two IP addresses, the 1566 transport protocol ID, two transport protocol port numbers and the 1567 DSCP in the IP header. When IPsec is used, the transport header is 1568 encrypted and the next protocol ID is an IPsec protocol, usually ESP, 1569 and not a transport protocol (e.g., neither TCP nor UDP, etc.) 1570 leaving only three components of the 6-tuple, which are the two IP 1571 addresses and the DSCP, which are in general not sufficient to 1572 identify a DetNet flow. 1574 Sections below discuss threats specific to IP and MPLS in more 1575 detail. 1577 7.1. IP 1579 The IP protocol has a long history of security considerations and 1580 architectural protection mechanisms. From a data plane perspective 1581 DetNet does not add or modify any IP header information, and its use 1582 as a DetNet Data Plane does not introduce any new security issues 1583 that were not there before, apart from those already described in the 1584 data-plane-independent threats section Section 3. 1586 Thus the security considerations for a DetNet based on an IP data 1587 plane are purely inherited from the rich IP Security literature and 1588 code/application base, and the data-plane-independent section of this 1589 document. 1591 Maintaining security for IP segments of a DetNet may be more 1592 challenging than for the MPLS segments of the network, given that the 1593 IP segments of the network may reach the edges of the network, which 1594 are more likely to involve interaction with potentially malevolent 1595 outside actors. Conversely MPLS is inherently more secure than IP 1596 since it is internal to routers and it is well-known how to protect 1597 it from outside influence. 1599 Another way to look at DetNet IP security is to consider it in the 1600 light of VPN security; as an industry we have a lot of experience 1601 with VPNs running through networks with other VPNs, it is well known 1602 how to secure the network for that. However for a DetNet we have the 1603 additional subtlety that any possible interaction of one packet with 1604 another can have a potentially deleterious effect on the time 1605 properties of the flows. So the network must provide sufficient 1606 isolation between flows, for example by protecting the forwarding 1607 bandwidth and related resources so that they are available to detnet 1608 traffic, by whatever means are appropriate for that network's data 1609 plane. 1611 7.2. MPLS 1613 An MPLS network carrying DetNet traffic is expected to be a "well- 1614 managed" network. Given that this is the case, it is difficult for 1615 an attacker to pass a raw MPLS encoded packet into a network because 1616 operators have considerable experience at excluding such packets at 1617 the network boundaries, as well as excluding MPLS packets being 1618 inserted through the use of a tunnel. 1620 MPLS security is discussed extensively in [RFC5920] ("Security 1621 Framework for MPLS and GMPLS Networks") to which the reader is 1622 referred. 1624 [RFC6941] builds on [RFC5920] by providing additional security 1625 considerations that are applicable to the MPLS-TP extensions 1626 appropriate to the MPLS Transport Profile [RFC5921], and thus to the 1627 operation of DetNet over some types of MPLS network. 1629 [RFC5921] introduces to MPLS new Operations, Administration, and 1630 Maintenance (OAM) capabilities, a transport-oriented path protection 1631 mechanism, and strong emphasis on static provisioning supported by 1632 network management systems. 1634 The operation of DetNet over an MPLS network is modeled on the 1635 operation of multi-segment pseudowires (MS-PW). Thus for guidance on 1636 securing the DetNet elements of DetNet over MPLS the reader is 1637 referred to the MS-PW security mechanisms as defined in [RFC4447], 1638 [RFC3931], [RFC3985], [RFC6073], and [RFC6478]. 1640 Having attended to the conventional aspects of network security it is 1641 necessary to attend to the dynamic aspects. The closest experience 1642 that the IETF has with securing protocols that are sensitive to 1643 manipulation of delay are the two way time transfer protocols (TWTT), 1644 which are NTP [RFC5905] and Precision Time Protocol [IEEE1588]. The 1645 security requirements for these are described in [RFC7384]. 1647 One particular problem that has been observed in operational tests of 1648 TWTT protocols is the ability for two closely but not completely 1649 synchronized streams to beat and cause a sudden phase hit to one of 1650 the streams. This can be mitigated by the careful use of a 1651 scheduling system in the underlying packet transport. 1653 Further consideration of protection against dynamic attacks is work 1654 in progress. 1656 8. IANA Considerations 1658 This memo includes no requests from IANA. 1660 9. Security Considerations 1662 The security considerations of DetNet networks are presented 1663 throughout this document. 1665 10. Informative References 1667 [ARINC664P7] 1668 ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics 1669 Full-Duplex Switched Ethernet Network", 2009. 1671 [I-D.ietf-detnet-data-plane-framework] 1672 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1673 Bryant, S., and J. Korhonen, "DetNet Data Plane 1674 Framework", draft-ietf-detnet-data-plane-framework-03 1675 (work in progress), October 2019. 1677 [I-D.ietf-detnet-ip] 1678 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1679 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 1680 draft-ietf-detnet-ip-04 (work in progress), November 2019. 1682 [I-D.ietf-detnet-ip-over-tsn] 1683 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 1684 Data Plane: IP over IEEE 802.1 Time Sensitive Networking 1685 (TSN)", draft-ietf-detnet-ip-over-tsn-01 (work in 1686 progress), October 2019. 1688 [I-D.ietf-detnet-mpls] 1689 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1690 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 1691 draft-ietf-detnet-mpls-04 (work in progress), November 1692 2019. 1694 [I-D.varga-detnet-service-model] 1695 Varga, B. and J. Farkas, "DetNet Service Model", draft- 1696 varga-detnet-service-model-02 (work in progress), May 1697 2017. 1699 [IEEE1588] 1700 IEEE, "IEEE 1588 Standard for a Precision Clock 1701 Synchronization Protocol for Networked Measurement and 1702 Control Systems Version 2", 2008. 1704 [IEEE802.1AE-2018] 1705 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 1706 Security (MACsec)", 2018, 1707 . 1709 [IEEE802.1Qch-2017] 1710 IEEE Standards Association, "IEEE Standard for Local and 1711 metropolitan area networks--Bridges and Bridged Networks-- 1712 Amendment 29: Cyclic Queuing and Forwarding", 2017, 1713 . 1715 [MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/ 1716 hacked-cameras-dvrs-powered-todays-massive-internet- 1717 outage/", 2016. 1719 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1720 and W. Weiss, "An Architecture for Differentiated 1721 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1722 . 1724 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1725 Text on Security Considerations", BCP 72, RFC 3552, 1726 DOI 10.17487/RFC3552, July 2003, 1727 . 1729 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 1730 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 1731 RFC 3931, DOI 10.17487/RFC3931, March 2005, 1732 . 1734 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1735 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1736 DOI 10.17487/RFC3985, March 2005, 1737 . 1739 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1740 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1741 December 2005, . 1743 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 1744 G. Heron, "Pseudowire Setup and Maintenance Using the 1745 Label Distribution Protocol (LDP)", RFC 4447, 1746 DOI 10.17487/RFC4447, April 2006, 1747 . 1749 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1750 "Network Time Protocol Version 4: Protocol and Algorithms 1751 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1752 . 1754 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1755 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1756 . 1758 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 1759 L., and L. Berger, "A Framework for MPLS in Transport 1760 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 1761 . 1763 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1764 Aissaoui, "Segmented Pseudowire", RFC 6073, 1765 DOI 10.17487/RFC6073, January 2011, 1766 . 1768 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 1769 "Pseudowire Status for Static Pseudowires", RFC 6478, 1770 DOI 10.17487/RFC6478, May 2012, 1771 . 1773 [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., 1774 and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) 1775 Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 1776 2013, . 1778 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1779 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1780 October 2014, . 1782 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 1783 RFC 8578, DOI 10.17487/RFC8578, May 2019, 1784 . 1786 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1787 "Deterministic Networking Architecture", RFC 8655, 1788 DOI 10.17487/RFC8655, October 2019, 1789 . 1791 Authors' Addresses 1793 Tal Mizrahi 1794 Huawei Network.IO Innovation Lab 1796 Email: tal.mizrahi.phd@gmail.com 1797 Ethan Grossman (editor) 1798 Dolby Laboratories, Inc. 1799 1275 Market Street 1800 San Francisco, CA 94103 1801 USA 1803 Phone: +1 415 645 4726 1804 Email: ethan.grossman@dolby.com 1805 URI: http://www.dolby.com 1807 Andrew J. Hacker 1808 MistIQ Technologies, Inc 1810 Harrisburg, PA 1811 USA 1813 Phone: 1814 Email: ajhacker@mistiqtech.com 1815 URI: http://www.mistiqtech.com 1817 Subir Das 1818 Applied Communication Sciences 1819 150 Mount Airy Road, Basking Ridge 1820 New Jersey, 07920 1821 USA 1823 Email: sdas@appcomsci.com 1825 John Dowdell 1826 Airbus Defence and Space 1827 Celtic Springs 1828 Newport NP10 8FZ 1829 United Kingdom 1831 Email: john.dowdell.ietf@gmail.com 1833 Henrik Austad 1834 SINTEF Digital 1835 Klaebuveien 153 1836 Trondheim 7037 1837 Norway 1839 Email: henrik@austad.us 1840 Norman Finn 1841 Huawei 1843 Email: norman.finn@mail01.huawei.com