idnits 2.17.1 draft-ietf-detnet-security-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ARINC664P7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2367 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2475' is mentioned on line 1434, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-03 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-13 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Mizrahi 3 Internet-Draft MARVELL 4 Intended status: Informational E. Grossman, Ed. 5 Expires: May 3, 2018 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 Cisco Systems 14 K. Stanton 15 INTEL 16 N. Finn 17 HUAWEI 18 October 30, 2017 20 Deterministic Networking (DetNet) Security Considerations 21 draft-ietf-detnet-security-01 23 Abstract 25 A deterministic network is one that can carry data flows for real- 26 time applications with extremely low data loss rates and bounded 27 latency. Deterministic networks have been successfully deployed in 28 real-time operational technology (OT) applications for some years 29 (for example [ARINC664P7]). However, such networks are typically 30 isolated from external access, and thus the security threat from 31 external attackers is low. IETF Deterministic Networking (DetNet) 32 specifies a set of technologies that enable creation of deterministic 33 networks on IP-based networks of potentially wide area (on the scale 34 of a corporate network) potentially bringing the OT network into 35 contact with Information Technology (IT) traffic and security threats 36 that lie outside of a tightly controlled and bounded area (such as 37 the internals of an aircraft). These DetNet technologies have not 38 previously been deployed together on a wide area IP-based network, 39 and thus can present security considerations that may be new to IP- 40 based wide area network designers. This draft, intended for use by 41 DetNet network designers, provides insight into these security 42 considerations. In addition, this draft collects all security- 43 related statements from the various DetNet drafts (Architecture, Use 44 Cases, etc) into a single location Section 7. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on May 3, 2018. 63 Copyright Notice 65 Copyright (c) 2017 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6 83 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 6 84 3.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7 85 3.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 86 3.2.1.1. Delay Attack . . . . . . . . . . . . . . . . . . 7 87 3.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 7 88 3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7 89 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7 90 3.2.4. Packet Replication and Elimination . . . . . . . . . 8 91 3.2.4.1. Replication: Increased Attack Surface . . . . . . 8 92 3.2.4.2. Replication-related Header Manipulation . . . . . 8 93 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 8 94 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8 95 3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 9 96 3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9 97 3.2.6.1. Control or Signaling Packet Modification . . . . 9 98 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 99 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 100 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 101 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9 102 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 103 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 104 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13 105 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13 106 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 13 107 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14 108 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14 109 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14 110 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14 111 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14 112 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15 113 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15 114 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15 115 4.4. Replication and Elimination . . . . . . . . . . . . . . . 15 116 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15 117 4.4.2. Header Manipulation at Elimination Bridges . . . . . 15 118 4.5. Control or Signaling Packet Modification . . . . . . . . 16 119 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 120 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 121 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 122 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 123 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 16 124 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 16 125 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 126 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 17 127 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 17 128 5.5. Control and Signaling Message Protection . . . . . . . . 18 129 5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 18 130 5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 18 131 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 20 132 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 20 133 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 20 134 6.1.2. Central Administration . . . . . . . . . . . . . . . 21 135 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 21 136 6.1.4. Data Flow Information Models . . . . . . . . . . . . 22 137 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 22 138 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 22 139 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 23 140 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 23 141 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 23 142 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 24 143 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 24 144 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 24 145 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 25 146 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 25 147 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 25 148 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 26 149 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 26 150 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 27 151 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 27 152 6.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 27 153 6.1.21. Reliability and Availability . . . . . . . . . . . . 27 154 6.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 28 155 6.1.23. Security Measures . . . . . . . . . . . . . . . . . . 28 156 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 28 157 7. Appendix A: DetNet Draft Security-Related Statements . . . . 30 158 7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 31 159 7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 31 160 7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 31 161 7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 32 162 7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 32 163 7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 32 164 7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 32 165 7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 33 166 7.4.1. (Utility Networks) Security Current Practices and 167 Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 33 168 7.4.2. (Utility Networks) Security Trends in Utility 169 Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 34 170 7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 36 171 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 36 172 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 36 173 7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 37 174 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 175 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 176 10. Informative References . . . . . . . . . . . . . . . . . . . 37 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 179 1. Introduction 181 Security is of particularly high importance in DetNet networks 182 because many of the use cases which are enabled by DetNet 183 [I-D.ietf-detnet-use-cases] include control of physical devices 184 (power grid components, industrial controls, building controls) which 185 can have high operational costs for failure, and present potentially 186 attractive targets for cyber-attackers. 188 This situation is even more acute given that one of the goals of 189 DetNet is to provide a "converged network", i.e. one that includes 190 both IT traffic and OT traffic, thus exposing potentially sensitive 191 OT devices to attack in ways that were not previously common (usually 192 because they were under a separate control system or otherwise 193 isolated from the IT network). Security considerations for OT 194 networks is not a new area, and there are many OT networks today that 195 are connected to wide area networks or the Internet; this draft 196 focuses on the issues that are specific to the DetNet technologies 197 and use cases. 199 The DetNet technologies include ways to: 201 o Reserve data plane resources for DetNet flows in some or all of 202 the intermediate nodes (e.g. bridges or routers) along the path of 203 the flow 205 o Provide explicit routes for DetNet flows that do not rapidly 206 change with the network topology 208 o Distribute data from DetNet flow packets over time and/or space to 209 ensure delivery of each packet's data' in spite of the loss of a 210 path 212 This draft includes sections on threat modeling and analysis, threat 213 impact and mitigation, and the association of attacks with use cases 214 based on the Use Case Common Themes section of the DetNet Use Cases 215 draft [I-D.ietf-detnet-use-cases]. 217 This draft also provides context for the DetNet security 218 considerations by collecting into one place Section 7 the various 219 remarks about security from the various DetNet drafts (Use Cases, 220 Architecture, etc). This text is duplicated here primarily because 221 the DetNet working group has elected not to produce a Requirements 222 draft and thus collectively these statements are as close as we have 223 to "DetNet Security Requirements". 225 2. Abbreviations 227 IT Information technology (the application of computers to 228 store, study, retrieve, transmit, and manipulate data or information, 229 often in the context of a business or other enterprise - Wikipedia). 231 OT Operational Technology (the hardware and software 232 dedicated to detecting or causing changes in physical processes 233 through direct monitoring and/or control of physical devices such as 234 valves, pumps, etc. - Wikipedia) 236 MITM Man in the Middle 237 SN Sequence Number 239 STRIDE Addresses risk and severity associated with threat 240 categories: Spoofing identity, Tampering with data, Repudiation, 241 Information disclosure, Denial of service, Elevation of privilege. 243 DREAD Compares and prioritizes risk represented by these threat 244 categories: Damage potential, Reproducibility, Exploitability, how 245 many Affected users, Discoverability. 247 PTP Precision Time Protocol [IEEE1588] 249 3. Security Threats 251 This section presents a threat model, and analyzes the possible 252 threats in a DetNet-enabled network. 254 We distinguish control plane threats from data plane threats. The 255 attack surface may be the same, but the types of attacks as well as 256 the motivation behind them, are different. For example, a delay 257 attack is more relevant to data plane than to control plane. There 258 is also a difference in terms of security solutions: the way you 259 secure the data plane is often different than the way you secure the 260 control plane. 262 3.1. Threat Model 264 The threat model used in this memo is based on the threat model of 265 Section 3.1 of [RFC7384]. This model classifies attackers based on 266 two criteria: 268 o Internal vs. external: internal attackers either have access to a 269 trusted segment of the network or possess the encryption or 270 authentication keys. External attackers, on the other hand, do 271 not have the keys and have access only to the encrypted or 272 authenticated traffic. 274 o Man in the Middle (MITM) vs. packet injector: MITM attackers are 275 located in a position that allows interception and modification of 276 in-flight protocol packets, whereas a traffic injector can only 277 attack by generating protocol packets. 279 Care has also been taken to adhere to Section 5 of [RFC3552], both 280 with respect to what attacks are considered out-of-scope for this 281 document, but also what is considered to be the most common threats 282 (explored furhter in Section 3.2. Most of the direct threats to 283 DetNet are Active attacks, but it is highly suggested that DetNet 284 application developers take appropriate measures to protect the 285 content of the streams from passive attacks. 287 DetNet-Service, one of the service scenarios described in 288 [I-D.varga-detnet-service-model], is the case where a service 289 connects DetNet networking islands, i.e. two or more otherwise 290 independent DetNet network domains are connected via a link that is 291 not intrinsically part of either network. This implies that there 292 could be DetNet traffic flowing over a non-DetNet link, which may 293 provide an attacker with an advantageous opportunity to tamper with 294 DetNet traffic. The security properties of non-DetNet links are 295 outside of the scope of DetNet Security, but it should be noted that 296 use of non-DetNet services to interconnect DetNet networks merits 297 security analysis to ensure the integrity of the DetNet networks 298 involved. 300 3.2. Threat Analysis 302 3.2.1. Delay 304 3.2.1.1. Delay Attack 306 An attacker can maliciously delay DetNet data flow traffic. By 307 delaying the traffic, the attacker can compromise the service of 308 applications that are sensitive to high delays or to high delay 309 variation. 311 3.2.2. DetNet Flow Modification or Spoofing 313 An attacker can modify some header fields of en route packets in a 314 way that causes the DetNet flow identification mechanisms to 315 misclassify the flow. Alternatively, the attacker can inject traffic 316 that is tailored to appear as if it belongs to a legitimate DetNet 317 flow. The potential consequence is that the DetNet flow resource 318 allocation cannot guarantee the performance that is expected when the 319 flow identification works correctly. 321 3.2.3. Resource Segmentation or Slicing 323 3.2.3.1. Inter-segment Attack 325 An attacker can inject traffic, consuming network device resources, 326 thereby affecting DetNet flows. This can be performed using non- 327 DetNet traffic that affects DetNet traffic, or by using DetNet 328 traffic from one DetNet flow that affects traffic from different 329 DetNet flows. 331 3.2.4. Packet Replication and Elimination 333 3.2.4.1. Replication: Increased Attack Surface 335 Redundancy is intended to increase the robustness and survivability 336 of DetNet flows, and replication over multiple paths can potentially 337 mitigate an attack that is limited to a single path. However, the 338 fact that packets are replicated over multiple paths increases the 339 attack surface of the network, i.e., there are more points in the 340 network that may be subject to attacks. 342 3.2.4.2. Replication-related Header Manipulation 344 An attacker can manipulate the replication-related header fields 345 (R-TAG). This capability opens the door for various types of 346 attacks. For example: 348 o Forward both replicas - malicious change of a packet SN (Sequence 349 Number) can cause both replicas of the packet to be forwarded. 350 Note that this attack has a similar outcome to a replay attack. 352 o Eliminate both replicas - SN manipulation can be used to cause 353 both replicas to be eliminated. In this case an attacker that has 354 access to a single path can cause packets from other paths to be 355 dropped, thus compromising some of the advantage of path 356 redundancy. 358 o Flow hijacking - an attacker can hijack a DetNet flow with access 359 to a single path by systematically replacing the SNs on the given 360 path with higher SN values. For example, an attacker can replace 361 every SN value S with a higher value S+C, where C is a constant 362 integer. Thus, the attacker creates a false illusion that the 363 attacked path has the lowest delay, causing all packets from other 364 paths to be eliminated. Once the flow is hijacked the attacker 365 can either replace en route packets with malicious packets, or 366 simply injecting errors, causing the packets to be dropped at 367 their destination. 369 3.2.5. Path Choice 371 3.2.5.1. Path Manipulation 373 An attacker can maliciously change, add, or remove a path, thereby 374 affecting the corresponding DetNet flows that use the path. 376 3.2.5.2. Path Choice: Increased Attack Surface 378 One of the possible consequences of a path manipulation attack is an 379 increased attack surface. Thus, when the attack described in the 380 previous subsection is implemented, it may increase the potential of 381 other attacks to be performed. 383 3.2.6. Control Plane 385 3.2.6.1. Control or Signaling Packet Modification 387 An attacker can maliciously modify en route control packets in order 388 to disrupt or manipulate the DetNet path/resource allocation. 390 3.2.6.2. Control or Signaling Packet Injection 392 An attacker can maliciously inject control packets in order to 393 disrupt or manipulate the DetNet path/resource allocation. 395 3.2.7. Scheduling or Shaping 397 3.2.7.1. Reconnaissance 399 A passive eavesdropper can identify DetNet flows and then gather 400 information about en route DetNet flows, e.g., the number of DetNet 401 flows, their bandwidths, and their schedules. The gathered 402 information can later be used to invoke other attacks on some or all 403 of the flows. 405 Note that in some cases DetNet flows may be identified based on an 406 explicit DetNet header, but in some cases the flow identification may 407 be based on fields from the L3/L4 headers. If L3/L4 headers are 408 involved, for purposes of this draft we assume they are encrypted 409 and/or integrity-protected from external attackers. 411 3.2.8. Time Synchronization Mechanisms 413 An attacker can use any of the attacks described in [RFC7384] to 414 attack the synchronization protocol, thus affecting the DetNet 415 service. 417 3.3. Threat Summary 419 A summary of the attacks that were discussed in this section is 420 presented in Figure 1. For each attack, the table specifies the type 421 of attackers that may invoke the attack. In the context of this 422 summary, the distinction between internal and external attacks is 423 under the assumption that a corresponding security mechanism is being 424 used, and that the corresponding network equipment takes part in this 425 mechanism. 427 +-----------------------------------------+----+----+----+----+ 428 | Attack | Attacker Type | 429 | +---------+---------+ 430 | |Internal |External | 431 | |MITM|Inj.|MITM|Inj.| 432 +-----------------------------------------+----+----+----+----+ 433 |Delay attack | + | | + | | 434 +-----------------------------------------+----+----+----+----+ 435 |DetNet Flow Modification or Spoofing | + | + | | | 436 +-----------------------------------------+----+----+----+----+ 437 |Inter-segment Attack | + | + | | | 438 +-----------------------------------------+----+----+----+----+ 439 |Replication: Increased Attack Surface | + | + | + | + | 440 +-----------------------------------------+----+----+----+----+ 441 |Replication-related Header Manipulation | + | | | | 442 +-----------------------------------------+----+----+----+----+ 443 |Path Manipulation | + | + | | | 444 +-----------------------------------------+----+----+----+----+ 445 |Path Choice: Increased Attack Surface | + | + | + | + | 446 +-----------------------------------------+----+----+----+----+ 447 |Control or Signaling Packet Modification | + | | | | 448 +-----------------------------------------+----+----+----+----+ 449 |Control or Signaling Packet Injection | | + | | | 450 +-----------------------------------------+----+----+----+----+ 451 |Reconnaissance | + | | + | | 452 +-----------------------------------------+----+----+----+----+ 453 |Attacks on Time Sync Mechanisms | + | + | + | + | 454 +-----------------------------------------+----+----+----+----+ 456 Figure 1: Threat Analysis Summary 458 4. Security Threat Impacts 460 This section describes and rates the impact of the attacks described 461 in Section 3. In this section, the impacts as described assume that 462 the associated mitigation is not present or has failed. Mitigations 463 are discussed in Section 5. 465 In computer security, the impact (or consequence) of an incident can 466 be measured in loss of confidentiality, integrity or availability of 467 information. 469 DetNet raises these stakes significantly for OT applications, 470 particularly those which may have been designed to run in an OT-only 471 environment and thus may not have been designed for security in an IT 472 environment with its associated devices, services and protocols. 474 The severity of various components of the impact of a successful 475 vulnerability exploit to use cases by industry is available in more 476 detail in [I-D.ietf-detnet-use-cases]. Each of the use cases in the 477 DetNet Use Cases draft is represented in the table below, including 478 Pro Audio, Electrical Utilities, Industrial M2M (split into two 479 areas, M2M Data Gathering and M2M Control Loop), and others. 481 Components of Impact (left column) include Criticality of Failure, 482 Effects of Failure, Recovery, and DetNet Functional Dependence. 483 Criticality of failure summarizes the seriousness of the impact. The 484 impact of a resulting failure can affect many different metrics that 485 vary greatly in scope and severity. In order to reduce the number of 486 variables, only the following were included: Financial, Health and 487 Safety, People well being, Affect on a single organization, and 488 affect on multiple organizations. Recovery outlines how long it 489 would take for an affected use case to get back to its pre-failure 490 state (Recovery time objective, RTO), and how much of the original 491 service would be lost in between the time of service failure and 492 recovery to original state (Recovery Point Objective, RPO). DetNet 493 dependence maps how much the following DetNet service objectives 494 contribute to impact of failure: Time dependency, data integrity, 495 source node integrity, availability, latency/jitter. 497 The scale of the Impact mappings is low, medium, and high. In some 498 use cases there may be a multitude of specific applications in which 499 DetNet is used. For simplicity this section attempts to average the 500 varied impacts of different applications. This section does not 501 address the overall risk of a certain impact which would require the 502 likelihood of a failure happening. 504 In practice any such ratings will vary from case to case; the ratings 505 shown here are given as examples. 507 Table, Part One (of Two) 508 +------------------+-----------------------------------------+-----+ 509 | | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M | 510 | | | | | less | |Data |Ctrl | 511 +------------------+-----------------------------------------+-----+ 512 | Criticality | Med | Hi | Low | Med | Med | Med | Med | 513 +------------------+-----------------------------------------+-----+ 514 | Effects 515 +------------------+-----------------------------------------+-----+ 516 | Financial | Med | Hi | Med | Med | Low | Med | Med | 517 +------------------+-----------------------------------------+-----+ 518 | Health/Safety | Med | Hi | Hi | Med | Med | Med | Med | 519 +------------------+-----------------------------------------+-----+ 520 | People WB | Med | Hi | Hi | Low | Hi | Low | Low | 521 +------------------+-----------------------------------------+-----+ 522 | Effect 1 org | Hi | Hi | Med | Hi | Med | Med | Med | 523 +------------------+-----------------------------------------+-----+ 524 | Effect >1 org | Med | Hi | Low | Med | Med | Med | Med | 525 +------------------+-----------------------------------------+-----+ 526 |Recovery 527 +------------------+-----------------------------------------+-----+ 528 | Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi | 529 +------------------+-----------------------------------------+-----+ 530 | Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi | 531 +------------------+-----------------------------------------+-----+ 532 |DetNet Dependence 533 +------------------+-----------------------------------------+-----+ 534 | Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi | 535 +------------------+-----------------------------------------+-----+ 536 | Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi | 537 +------------------+-----------------------------------------+-----+ 538 | Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Low | 539 +------------------+-----------------------------------------+-----+ 540 | Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi | 541 +------------------+-----------------------------------------+-----+ 542 | Availability | Hi | Hi | Med | Hi | Low | Hi | Hi | 543 +------------------+-----------------------------------------+-----+ 545 Table, Part Two (of Two) 546 +------------------+--------------------------+ 547 | | Mining | Block | Network | 548 | | | Chain | Slicing | 549 +------------------+--------------------------+ 550 | Criticality | Hi | Med | Hi | 551 +------------------+--------------------------+ 552 | Effects 553 +------------------+--------------------------+ 554 | Financial | Hi | Hi | Hi | 555 +------------------+--------------------------+ 556 | Health/Safety | Hi | Low | Med | 557 +------------------+--------------------------+ 558 | People WB | Hi | Low | Med | 559 +------------------+--------------------------+ 560 | Effect 1 org | Hi | Hi | Hi | 561 +------------------+--------------------------+ 562 | Effect >1 org | Hi | Low | Hi | 563 +------------------+--------------------------+ 564 |Recovery 565 +------------------+--------------------------+ 566 | Recov Time Obj | Hi | Low | Hi | 567 +------------------+--------------------------+ 568 | Recov Point Obj | Hi | Low | Hi | 569 +------------------+--------------------------+ 570 |DetNet Dependence 571 +------------------+--------------------------+ 572 | Time Dependency | Hi | Low | Hi | 573 +------------------+--------------------------+ 574 | Latency/Jitter | Hi | Low | Hi | 575 +------------------+--------------------------+ 576 | Data Integrity | Hi | Hi | Hi | 577 +------------------+--------------------------+ 578 | Src Node Integ | Hi | Hi | Hi | 579 +------------------+--------------------------+ 580 | Availability | Hi | Hi | Hi | 581 +------------------+--------------------------+ 583 Figure 2: Impact of Attacks by Use Case Industry 585 The rest of this section will cover impact of the different groups in 586 more detail. 588 4.1. Delay-Attacks 590 4.1.1. Data Plane Delay Attacks 592 Severely delayed messages in a DetNet link can result in the same 593 behavior as dropped messages in ordinary networks as the services 594 attached to the stream has strict deterministic requirements. 596 For a single path scenario, disruption is a real possibility, whereas 597 in a multipath scenario, large delays or instabilities in one stream 598 can lead to increased buffer and CPU resources on the elimination 599 bridge. 601 4.1.2. Control Plane Delay Attacks 603 In and of itself, this is not directly a threat to the DetNet 604 service, but the effects of delaying control messages can have quite 605 adverse effects later. 607 o Delayed tear-down can lead to resource leakage, which in turn can 608 result in failure to allocate new streams finally giving rise to a 609 denial of service attack. 611 o Failure to deliver, or severely delaying, signalling messages 612 adding an end-point to a multicast-group will prevent the new EP 613 from receiving expected frames thus disrupting expected behavior. 615 o Delaying messages removing an EP from a group can lead to loss of 616 privacy as the EP will continue to receive messages even after it 617 is supposedly removed. 619 4.2. Flow Modification and Spoofing 621 4.2.1. Flow Modification 623 ToDo. 625 4.2.2. Spoofing 627 4.2.2.1. Dataplane Spoofing 629 Spoofing dataplane messages can result in increased resource 630 consumptions on the bridges throughout the network as it will 631 increase buffer usage and CPU utilization. This can lead to resource 632 exhaustion and/or increased delay. 634 If the attacker manages to create valid headers, the false messages 635 can be forwarded through the network, using part of the allocated 636 bandwidth. This in turn can cause legitimate messages to be dropped 637 when the budget has been exhausted. 639 Finally, the endpoint will have to deal with invalid messages being 640 delivered to the endpoint instead of (or in addition to) a valid 641 message. 643 4.2.2.2. Control Plane Spoofing 645 A successful control plane spoofing-attack will potentionally have 646 adverse effects. It can do virtually anything from: 648 o modifying existing streams by changing the available bandwidth 650 o add or remove endpoints from a stream 652 o drop streams completly 654 o falsely create new streams (exhaust the systems resources, or to 655 enable streams outside the Network engineer's control) 657 4.3. Segmentation attacks (injection) 659 4.3.1. Data Plane Segmentation 661 Injection of false messages in a DetNet stream could lead to 662 exhaustion of the available bandwidth for a stream if the bridges 663 accounts false messages to the stream's budget. 665 In a multipath scenario, injected messages will cause increased CPU 666 utilization in elimination bridges. If enough paths are subject to 667 malicious injection, the legitimate messages can be dropped. 668 Likewise it can cause an increase in buffer usage. In total, it will 669 consume more resources in the bridges than normal, giving rise to a 670 resource exhaustion attack on the bridges. 672 If a stream is interrupted, the end application will be affected by 673 what is now a non-deterministic stream. 675 4.3.2. Control Plane segmentation 677 A successful Control Plane segmentation attack control messages to be 678 interpreted by nodes in the network, unbeknownst to the central 679 controller or the network engineer. This has the potential to create 681 o new streams (exhausting resources) 683 o drop existing (denial of service) 685 o add/remove end-stations to a multicast group (loss of privacy) 687 o modify the stream attributes (affecting available bandwidth 689 4.4. Replication and Elimination 691 The Replication and Elimination is relevant only to Data Plane 692 messages as Signalling is not subject to multipath routing. 694 4.4.1. Increased Attack Surface 696 Covered briefly in Section 4.3 698 4.4.2. Header Manipulation at Elimination Bridges 700 Covered briefly in Section 4.3 702 4.5. Control or Signaling Packet Modification 704 ToDo. 706 4.6. Control or Signaling Packet Injection 708 ToDo. 710 4.7. Reconnaissance 712 Of all the attacks, this is one of the most difficult to detect and 713 counter. Often, an attacker will start out by observing the traffic 714 going through the network and use the knowledge gathered in this 715 phase to mount future attacks. 717 The attacker can, at their leisure, observe over time all aspects of 718 the messaging and signalling, learning the intent and purpose of all 719 traffic flows. At some later date, possibly at an important time in 720 an operational context, the attacker can launch a multi-faceted 721 attack, possibly in conjunction with some demand for ransom. 723 The flow-id in the header of the data plane-messages gives an 724 attacker a very reliable identifier for DetNet traffic, and this 725 traffic has a high probability of going to lucrative targets. 727 4.8. Attacks on Time Sync Mechanisms 729 ToDo. 731 4.9. Attacks on Path Choice 733 This is covered in part in Section 4.3, and as with Replication and 734 Elimination (Section 4.4, this is relevant for DataPlane messages. 736 5. Security Threat Mitigation 738 This section describes a set of measures that can be taken to 739 mitigate the attacks described in Section 3. These mitigations 740 should be viewed as a toolset that includes several different and 741 diverse tools. Each application or system will typically use a 742 subset of these tools, based on a system-specific threat analysis. 744 5.1. Path Redundancy 746 Description 748 A DetNet flow that can be forwarded simultaneously over multiple 749 paths. Path replication and elimination 751 [I-D.ietf-detnet-architecture] provides resiliency to dropped or 752 delayed packets. This redundancy improves the robustness to 753 failures and to man-in-the-middle attacks. 755 Related attacks 757 Path redundancy can be used to mitigate various man-in-the-middle 758 attacks, including attacks described in Section 3.2.1, 759 Section 3.2.2, Section 3.2.3, and Section 3.2.8. 761 5.2. Integrity Protection 763 Description 765 An integrity protection mechanism, such as a Hash-based Message 766 Authentication Code (HMAC) can be used to mitigate modification 767 attacks. Integrity protection can be used on the data plane 768 header, to prevent its modification and tampering. Integrity 769 protection in the control plane is discussed in Section 5.5. 771 Related attacks 773 Integrity protection mitigates attacks related to modification and 774 tampering, including the attacks described in Section 3.2.2 and 775 Section 3.2.4. 777 5.3. DetNet Node Authentication 779 Description 781 Source authentication verifies the authenticity of DetNet sources, 782 allowing to mitigate spoofing attacks. Note that while integrity 783 protection (Section 5.2) prevents intermediate nodes from 784 modifying information, authentication verfies the source of the 785 information. 787 Related attacks 789 DetNet node authentication is used to mitigate attacks related to 790 spoofing, including the attacks of Section 3.2.2, and 791 Section 3.2.4. 793 5.4. Encryption 795 Description 797 DetNet flows can be forwarded in encrypted form. 799 Related attacks 801 While confidentiality is not considered an important goal with 802 respect to DetNet, encryption can be used to mitigate recon 803 attacks (Section 3.2.7). 805 5.5. Control and Signaling Message Protection 807 Description 809 Control and sigaling messages can be protected using 810 authentication and integrity protection mechanisms. 812 Related attacks 814 These mechanisms can be used to mitigate various attacks on the 815 control plane, as described in Section 3.2.6, Section 3.2.8 and 816 Section 3.2.5. 818 5.6. Dynamic Performance Analytics 820 Description 822 Information about the network performance can be gathered in real- 823 time in order to detect anomalies and unusual behavior that may be 824 the symptom of a security attack. The gathered information can be 825 based, for example, on per-flow counters, bandwidth measurement, 826 and monitoring of packet arrival times. Unusual behavior or 827 potentially malicious nodes can be reported to a management 828 system, or can be used as a trigger for taking corrective actions. 829 The information can be tracked by DetNet end systems and transit 830 nodes, and exported to a management system, for example using 831 NETCONF. 833 Related attacks 835 Performance analytics can be used to mitigate various attacks, 836 including the ones described in Section 3.2.1, Section 3.2.3, and 837 Section 3.2.8. 839 5.7. Mitigation Summary 841 The following table maps the attacks of Section 3 to the impacts of 842 Section 4, and to the mitigations of the current section. Each row 843 specifies an attack, the impact of this attack if it is successfully 844 implemented, and possible mitigation methods. 846 +----------------------+---------------------+---------------------+ 847 | Attack | Impact | Mitigations | 848 +----------------------+---------------------+---------------------+ 849 |Delay Attack |-Non-deterministic |-Path redundancy | 850 | | delay |-Performance | 851 | |-Data disruption | analytics | 852 | |-Increased resource | | 853 | | consumption | | 854 +----------------------+---------------------+---------------------+ 855 |Reconnaissance |-Enabler for other |-Encryption | 856 | | attacks | | 857 +----------------------+---------------------+---------------------+ 858 |DetNet Flow Modificat-|-Increased resource |-Path redundancy | 859 |ion or Spoofing | consumption |-Integrity protection| 860 | |-Data disruption |-DetNet Node | 861 | | | authentication | 862 +----------------------+---------------------+---------------------+ 863 |Inter-Segment Attack |-Increased resource |-Path redundancy | 864 | | consumption |-Performance | 865 | |-Data disruption | analytics | 866 +----------------------+---------------------+---------------------+ 867 |Replication: Increased|-All impacts of other|-Integrity protection| 868 |attack surface | attacks |-DetNet Node | 869 | | | authentication | 870 +----------------------+---------------------+---------------------+ 871 |Replication-related |-Non-deterministic |-Integrity protection| 872 |Header Manipulation | delay |-DetNet Node | 873 | |-Data disruption | authentication | 874 +----------------------+---------------------+---------------------+ 875 |Path Manipulation |-Enabler for other |-Control message | 876 | | attacks | protection | 877 +----------------------+---------------------+---------------------+ 878 |Path Choice: Increased|-All impacts of other|-Control message | 879 |Attack Surface | attacks | protection | 880 +----------------------+---------------------+---------------------+ 881 |Control or Signaling |-Increased resource |-Control message | 882 |Packet Modification | consumption | protection | 883 | |-Non-deterministic | | 884 | | delay | | 885 | |-Data disruption | | 886 +----------------------+---------------------+---------------------+ 887 |Control or Signaling |-Increased resource |-Control message | 888 |Packet Injection | consumption | protection | 889 | |-Non-deterministic | | 890 | | delay | | 891 | |-Data disruption | | 892 +----------------------+---------------------+---------------------+ 893 |Attacks on Time Sync |-Non-deterministic |-Path redundancy | 894 |Mechanisms | delay |-Control message | 895 | |-Increased resource | protection | 896 | | consumption |-Performance | 897 | |-Data disruption | analytics | 898 +----------------------+---------------------+---------------------+ 900 Figure 3: Mapping Attacks to Impact and Mitigations 902 6. Association of Attacks to Use Cases 904 Different attacks can have different impact and/or mitigation 905 depending on the use case, so we would like to make this association 906 in our analysis. However since there is a potentially unbounded list 907 of use cases, we categorize the attacks with respect to the common 908 themes of the use cases as identified in the Use Case Common Themes 909 section of the DetNet Use Cases draft [I-D.ietf-detnet-use-cases]. 911 See also Figure 2 for a mapping of the impact of attacks per use case 912 by industry. 914 6.1. Use Cases by Common Themes 916 In this section we review each theme and discuss the attacks that are 917 applicable to that theme, as well as anything specific about the 918 impact and mitigations for that attack with respect to that theme. 919 The table Figure 5 then provides a summary of the attacks that are 920 applicable to each theme. 922 6.1.1. Network Layer - AVB/TSN Ethernet 924 DetNet is expected to run over various transmission mediums, with 925 Ethernet being explicitly supported. Attacks such as Delay or 926 Reconnaissance might be implemented differently on a different 927 transmission medium, however the impact on the DetNet as a whole 928 would be essentially the same. We thus conclude that all attacks and 929 impacts that would be applicable to DetNet over Ethernet (i.e. all 930 those named in this draft) would also be applicable to DetNet over 931 other transmission mediums. 933 With respect to mitigations, some methods are specific to the 934 Ethernet medium, for example time-aware scheduling using 802.1Qbv can 935 protect against excessive use of bandwidth at the ingress - for other 936 mediums, other mitigations would have to be implemented to provide 937 analogous protection. 939 6.1.2. Central Administration 941 A DetNet network is expected to be controlled by a centralized 942 network configuration and control system (CNC). Such a system may be 943 in a single central location, or it may be distributed across 944 multiple control entities that function together as a unified control 945 system for the network. 947 In this draft we distinguish between attacks on the DetNet Control 948 plane vs. Data plane. But is an attack affecting control plane 949 packets synonymous with an attack on the CNC itself? For purposes of 950 this draft let us consider an attack on the CNC itself to be out of 951 scope, and consider all attacks named in this draft which are 952 relevant to control plane packets to be relevant to this theme, 953 including Path Manipulation, Path Choice, Control Packet Modification 954 or Injection, Reconaissance and Attacks on Time Sync Mechanisms. 956 6.1.3. Hot Swap 958 A DetNet network is not expected to be "plug and play" - it is 959 expected that there is some centralized network configuration and 960 control system. However, the ability to "hot swap" components (e.g. 961 due to malfunction) is similar enough to "plug and play" that this 962 kind of behavior may be expected in DetNet networks, depending on the 963 implementation. 965 An attack surface related to Hot Swap is that the DetNet network must 966 at least consider input at runtime from devices that were not part of 967 the initial configuration of the network. Even a "perfect" (or 968 "hitless") replacement of a device at runtime would not necessarily 969 be ideal, since presumably one would want to distinguish it from the 970 original for OAM purposes (e.g. to report hot swap of a failed 971 device). 973 This implies that an attack such as Flow Modification, Spoofing or 974 Inter-segment (which could introduce packets from a "new" device 975 (i.e. one heretofore unknown on the network) could be used to exploit 976 the need to consider such packets (as opposed to rejecting them out 977 of hand as one would do if one did not have to consider introduction 978 of a new device). 980 Similarly if the network was designed to support runtime replacement 981 of a clock device, then presence (or apparent presence) and thus 982 consideration of packets from a new such device could affect the 983 network, or the time sync of the network, for example by initiating a 984 new Best Master Clock selection process. Thus attacks on time sync 985 should be considered when designing hot swap type functionality. 987 6.1.4. Data Flow Information Models 989 Data Flow Information Models specific to DetNet networks are to be 990 specified by DetNet. Thus they are "new" and thus potentially 991 present a new attack surface. Does the threat take advantage of any 992 aspect of our new Data Flow Info Models? 994 This is TBD, thus there are no specific entries in our table, however 995 that does not imply that there could be no relevant attacks. 997 6.1.5. L2 and L3 Integration 999 A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN 1000 LAN) and Layer 3 (routed) networks via the use of well-known 1001 protocols such as IPv6, MPLS-PW, and Ethernet. Presumably security 1002 considerations applicable directly to those individual protocols is 1003 not specific to DetNet, and thus out of scope for this draft. 1004 However enabling DetNet to coordinate Layer 2 and Layer 3 behavior 1005 will require some additions to existing protocols (see draft-dt- 1006 detnet-dp-alt) and any such new work can introduce new attack 1007 surfaces. 1009 This is TBD, thus there are no specific entries in our table, however 1010 that does not imply that there could be no relevant attacks. 1012 6.1.6. End-to-End Delivery 1014 Packets sent over DetNet are guaranteed not to be dropped by the 1015 network due to congestion. (Packets may however be dropped for 1016 intended reasons, e.g. per security measures). 1018 A Data plane attack may force packets to be dropped, for example a 1019 "long" Delay or Replication/Elimination or Flow Modification attack. 1021 The same result might be obtained by a Control plane attack, e.g. 1022 Path Manipulation or Signaling Packet Modification. 1024 It may be that such attacks are limited to Internal MITM attackers, 1025 but other possibilities should be considered. 1027 An attack may also cause packets that should not be delivered to be 1028 delivered, such as by forcing packets from one (e.g. replicated) path 1029 to be preferred over another path when they should not be 1030 (Replication attack), or by Flow Modification, or by Path Choice or 1031 Packet Injection. A Time Sync attack could cause a system that was 1032 expecting certain packets at certain times to accept unintended 1033 packets based on compromised system time or time windowing in the 1034 scheduler. 1036 6.1.7. Proprietary Deterministic Ethernet Networks 1038 There are many proprietary non-interoperable deterministic Ethernet- 1039 based networks currently available; DetNet is intended to provide an 1040 open-standards-based alternative to such networks. In cases where a 1041 DetNet intersects with remnants of such networks or their protocols, 1042 such as by protocol emulation or access to such a network via a 1043 gateway, new attack surfaces can be opened. 1045 For example an Inter-Segment or Control plane attack such as Path 1046 Manipulation, Path Choice or Control Packet Modification/Injection 1047 could be used to exploit commands specific to such a protocol, or 1048 that are interpreted differently by the different protocols or 1049 gateway. 1051 6.1.8. Replacement for Proprietary Fieldbuses 1053 There are many proprietary "field buses" used in today's industrial 1054 and other industries; DetNet is intended to provide an open- 1055 standards-based alternative to such buses. In cases where a DetNet 1056 intersects with such fieldbuses or their protocols, such as by 1057 protocol emulation or access via a gateway, new attack surfaces can 1058 be opened. 1060 For example an Inter-Segment or Control plane attack such as Path 1061 Manipulation, Path Choice or Control Packet Modification/Injection 1062 could be used to exploit commands specific to such a protocol, or 1063 that are interpreted differently by the different protocols or 1064 gateway. 1066 6.1.9. Deterministic vs Best-Effort Traffic 1068 DetNet is intended to support coexistence of time-sensitive 1069 operational (OT, deterministic) traffic and information (IT, "best 1070 effort") traffic on the same ("unified") network. 1072 The presence of IT traffic on a network carrying OT traffic has long 1073 been considered insecure design [reference needed here]. With 1074 DetNet, this coexistance will become more common, and mitigations 1075 will need to be established. The fact that the IT traffic on a 1076 DetNet is limited to a corporate controlled network makes this a less 1077 difficult problem compared to being exposed to the open Internet, 1078 however this aspect of DetNet security should not be underestimated. 1080 Most of the themes described in this draft address OT (reserved) 1081 streams - this item is intended to address issues related to IT 1082 traffic on a DetNet. 1084 An Inter-segment attack can flood the network with IT-type traffic 1085 with the intent of disrupting handling of IT traffic, and/or the goal 1086 of interfering with OT traffic. Presumably if the stream reservation 1087 and isolation of the DetNet is well-designed (better-designed than 1088 the attack) then interference with OT traffic should not result from 1089 an attack that floods the network with IT traffic. 1091 However the DetNet's handling of IT traffic may not (by design) be as 1092 resilient to DOS attack, and thus designers must be otherwise 1093 prepared to mitigate DOS attacks on IT traffic in a DetNet. 1095 6.1.10. Deterministic Flows 1097 Reserved bandwidth data flows (deterministic flows) must provide the 1098 allocated bandwidth, and must be isolated from each other. 1100 A Spoofing or Inter-segment attack which adds packet traffic to a 1101 bandwidth-reserved stream could cause that stream to occupy more 1102 bandwidth than it is allocated, resulting in interference with other 1103 deterministic flows. 1105 A Flow Modification or Spoofing or Header Manipulation or Control 1106 Packet Modification attack could cause packets from one flow to be 1107 directed to another flow, thus breaching isolation between the flows. 1109 6.1.11. Unused Reserved Bandwidth 1111 If bandwidth reservations are made for a stream but the associated 1112 bandwidth is not used at any point in time, that bandwidth is made 1113 available on the network for best-effort traffic. If the owner of 1114 the reserved stream then starts transmitting again, the bandwidth is 1115 no longer available for best-effort traffic, on a moment-to-moment 1116 basis. (Such "temporarily available" bandwidth is not available for 1117 time-sensitive traffic, which must have its own reservation). 1119 An Inter-segment attack could flood the network with IT traffic, 1120 interfering with the intended IT traffic. 1122 A Flow Modification or Spoofing or Control Packet Modification or 1123 Injection attack could cause extra bandwidth to be reserved by a new 1124 or existing stream, thus making it unavailable for use by best-effort 1125 traffic. 1127 6.1.12. Interoperability 1129 The DetNet network specifications are intended to enable an ecosystem 1130 in which multiple vendors can create interoperable products, thus 1131 promoting device diversity and potentially higher numbers of each 1132 device manufactured. Does the threat take advantage of differences 1133 in implementation of "interoperable" products made by different 1134 vendors? 1136 This is TBD, thus there are no specific entries in our table, however 1137 that does not imply that there could be no relevant attacks. 1139 6.1.13. Cost Reductions 1141 The DetNet network specifications are intended to enable an ecosystem 1142 in which multiple vendors can create interoperable products, thus 1143 promoting higher numbers of each device manufactured, promoting cost 1144 reduction and cost competition among vendors. Does the threat take 1145 advantage of "low cost" HW or SW components or other "cost-related 1146 shortcuts" that might be present in devices? 1148 This is TBD, thus there are no specific entries in our table, however 1149 that does not imply that there could be no relevant attacks. 1151 6.1.14. Insufficiently Secure Devices 1153 The DetNet network specifications are intended to enable an ecosystem 1154 in which multiple vendors can create interoperable products, thus 1155 promoting device diversity and potentially higher numbers of each 1156 device manufactured. Does the threat attack "naivete" of SW, for 1157 example SW that was not designed to be sufficiently secure (or secure 1158 at all) but is deployed on a DetNet network that is intended to be 1159 highly secure? (For example IoT exploits like the Mirai video-camera 1160 botnet ([MIRAI]). 1162 This is TBD, thus there are no specific entries in our table, however 1163 that does not imply that there could be no relevant attacks. 1165 6.1.15. DetNet Network Size 1167 DetNet networks range in size from very small, e.g. inside a single 1168 industrial machine, to very large, for example a Utility Grid network 1169 spanning a whole country. 1171 The size of the network might be related to how the attack is 1172 introduced into the network, for example if the entire network is 1173 local, there is a threat that power can be cut to the entire network. 1174 If the network is large, perhaps only a part of the network is 1175 attacked. 1177 A Delay attack might be as relevant to a small network as to a large 1178 network, although the amount of delay might be different. 1180 Attacks sourced from IT traffic might be more likely in large 1181 networks, since more people might have access to the network. 1182 Similarly Path Manipulation, Path Choice and Time Sync attacks seem 1183 more likely relevant to large networks. 1185 6.1.16. Multiple Hops 1187 Large DetNet networks (e.g. a Utility Grid network) may involve many 1188 "hops" over various kinds of links for example radio repeaters, 1189 microwave links, fiber optic links, etc.. 1191 An attack that takes advantage of flaws (or even normal operation) in 1192 the device drivers for the various links (through internal knowledge 1193 of how the individual driver or firmware operates, perhaps like the 1194 Stuxnet attack) could take proportionately greater advantage of this 1195 topology. We don't currently have an attack like this defined; we 1196 have only "protocol" (time or packet) based attacks. Perhaps we need 1197 to define an attack like this? Or is that out of scope for DetNet? 1199 It is also possible that this DetNet topology will not be in as 1200 common use as other more homogeneous topologies so there may be more 1201 opportunity for attackers to exploit software and/or protocol flaws 1202 in the implementations which have not been wrung out by extensive 1203 use, particularly in the case of early adopters. 1205 Of the attacks we have defined, the ones identified above as relevant 1206 to "large" networks seem to be most relevant. 1208 6.1.17. Level of Service 1210 A DetNet is expected to provide means to configure the network that 1211 include querying network path latency, requesting bounded latency for 1212 a given stream, requesting worst case maximum and/or minimum latency 1213 for a given path or stream, and so on. It is an expected case that 1214 the network cannot provide a given requested service level. In such 1215 cases the network control system should reply that the requested 1216 service level is not available (as opposed to accepting the parameter 1217 but then not delivering the desired behavior). 1219 Control plane attacks such as Signaling Packet Modification and 1220 Injection could be used to modify or create control traffic that 1221 could interfere with the process of a user requesting a level of 1222 service and/or the network's reply. 1224 Reconnaissance could be used to characterize flows and perhaps target 1225 specific flows for attack via the Control plane as noted above. 1227 6.1.18. Bounded Latency 1229 DetNet provides the expectation of guaranteed bounded latency. 1231 Delay attacks can cause packets to miss their agreed-upon latency 1232 boundaries. 1234 Time Sync attacks can corrupt the system's time reference, resulting 1235 in missed latency deadlines (with respect to the "correct" time 1236 reference). 1238 6.1.19. Low Latency 1240 Applications may require "extremely low latency" however depending on 1241 the application these may mean very different latency values; for 1242 example "low latency" across a Utility grid network is on a different 1243 time scale than "low latency" in a motor control loop in a small 1244 machine. The intent is that the mechanisms for specifying desired 1245 latency include wide ranges, and that architecturally there is 1246 nothing to prevent arbitrarily low latencies from being implemented 1247 in a given network. 1249 Attacks on the Control plane (as described in the Level of Service 1250 theme) and Delay and Time attacks (as described in the Bounded 1251 Latency theme) both apply here. 1253 6.1.20. Symmetrical Path Delays 1255 Some applications would like to specify that the transit delay time 1256 values be equal for both the transmit and return paths. 1258 Delay attacks can cause path delays to differ. 1260 Time Sync attacks can corrupt the system's time reference, resulting 1261 in differing path delays (with respect to the "correct" time 1262 reference). 1264 6.1.21. Reliability and Availability 1266 DetNet based systems are expected to be implemented with essentially 1267 arbitrarily high availability (for example 99.9999% up time, or even 1268 12 nines). The intent is that the DetNet designs should not make any 1269 assumptions about the level of reliability and availability that may 1270 be required of a given system, and should define parameters for 1271 communicating these kinds of metrics within the network. 1273 Any attack on the system, of any type, can affect its overall 1274 reliability and availability, thus in our table we have marked every 1275 attack. Since every DetNet depends to a greater or lesser degree on 1276 reliability and availability, this essentially means that all 1277 networks have to mitigate all attacks, which to a greater or lesser 1278 degree defeats the purpose of associating attacks with use cases. It 1279 also underscores the difficulty of designing "extremely high 1280 reliability" networks. I hope that in future drafts we can say 1281 something more useful here. 1283 6.1.22. Redundant Paths 1285 DetNet based systems are expected to be implemented with essentially 1286 arbitrarily high reliability/availability. A strategy used by DetNet 1287 for providing such extraordinarily high levels of reliability is to 1288 provide redundant paths that can be seamlessly switched between, all 1289 the while maintaining the required performance of that system. 1291 Replication-related attacks are by definition applicable here. 1292 Control plane attacks can also interfere with the configuration of 1293 redundant paths. 1295 6.1.23. Security Measures 1297 A DetNet network must be made secure against devices failures, 1298 attackers, misbehaving devices, and so on. Does the threat affect 1299 such security measures themselves, e.g. by attacking SW designed to 1300 protect against device failure? 1302 This is TBD, thus there are no specific entries in our table, however 1303 that does not imply that there could be no relevant attacks. 1305 6.2. Attack Types by Use Case Common Theme 1307 The following table lists the attacks of Section 3, assigning a 1308 number to each type of attack. That number is then used as a short 1309 form identifier for the attack in Figure 5. 1311 +--+----------------------------------------+----------------------+ 1312 | | Attack | Section | 1313 +--+----------------------------------------+----------------------+ 1314 | 1|Delay Attack | Section 3.2.1 | 1315 +--+----------------------------------------+----------------------+ 1316 | 2|DetNet Flow Modification or Spoofing | Section 3.2.2 | 1317 +--+----------------------------------------+----------------------+ 1318 | 3|Inter-Segment Attack | Section 3.2.3 | 1319 +--+----------------------------------------+----------------------+ 1320 | 4|Replication: Increased attack surface | Section 3.2.4.1 | 1321 +--+----------------------------------------+----------------------+ 1322 | 5|Replication-related Header Manipulation | Section 3.2.4.2 | 1323 +--+----------------------------------------+----------------------+ 1324 | 6|Path Manipulation | Section 3.2.5.1 | 1325 +--+----------------------------------------+----------------------+ 1326 | 7|Path Choice: Increased Attack Surface | Section 3.2.5.2 | 1327 +--+----------------------------------------+----------------------+ 1328 | 8|Control or Signaling Packet Modification| Section 3.2.6.1 | 1329 +--+----------------------------------------+----------------------+ 1330 | 9|Control or Signaling Packet Injection | Section 3.2.6.2 | 1331 +--+----------------------------------------+----------------------+ 1332 |10|Reconnaissance | Section 3.2.7 | 1333 +--+----------------------------------------+----------------------+ 1334 |11|Attacks on Time Sync Mechanisms | Section 3.2.8 | 1335 +--+----------------------------------------+----------------------+ 1337 Figure 4: List of Attacks 1339 The following table maps the use case themes presented in this memo 1340 to the attacks of Figure 4. Each row specifies a theme, and the 1341 attacks relevant to this theme are marked with a '+'. 1343 +----------------------------+--------------------------------+ 1344 | Theme | Attack | 1345 | +--+--+--+--+--+--+--+--+--+--+--+ 1346 | | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11| 1347 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1348 |Network Layer - AVB/TSN Eth.| +| +| +| +| +| +| +| +| +| +| +| 1349 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1350 |Central Administration | | | | | | +| +| +| +| +| +| 1351 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1352 |Hot Swap | | +| +| | | | | | | | +| 1353 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1354 |Data Flow Information Models| | | | | | | | | | | | 1355 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1356 |L2 and L3 Integration | | | | | | | | | | | | 1357 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1358 |End-to-end Delivery | +| +| +| +| +| +| +| +| +| | +| 1359 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1360 |Proprietary Deterministic | | | +| | | +| +| +| +| | | 1361 |Ethernet Networks | | | | | | | | | | | | 1362 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1363 |Replacement for Proprietary | | | +| | | +| +| +| +| | | 1364 |Fieldbuses | | | | | | | | | | | | 1365 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1366 |Deterministic vs. Best- | | | +| | | | | | | | | 1367 |Effort Traffic | | | | | | | | | | | | 1368 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1369 |Deterministic Flows | | +| +| | +| +| | +| | | | 1370 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1371 |Unused Reserved Bandwidth | | +| +| | | | | +| +| | | 1372 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1373 |Interoperability | | | | | | | | | | | | 1374 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1375 |Cost Reductions | | | | | | | | | | | | 1376 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1377 |Insufficiently Secure | | | | | | | | | | | | 1378 |Devices | | | | | | | | | | | | 1379 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1380 |DetNet Network Size | +| | | | | +| +| | | | +| 1381 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1382 |Multiple Hops | +| +| | | | +| +| | | | +| 1383 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1384 |Level of Service | | | | | | | | +| +| +| | 1385 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1386 |Bounded Latency | +| | | | | | | | | | +| 1387 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1388 |Low Latency | +| | | | | | | +| +| +| +| 1389 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1390 |Symmetric Path Delays | +| | | | | | | | | | +| 1391 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1392 |Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +| 1393 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1394 |Redundant Paths | | | | +| +| | | +| +| | | 1395 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1396 |Security Measures | | | | | | | | | | | | 1397 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1399 Figure 5: Mapping Between Themes and Attacks 1401 7. Appendix A: DetNet Draft Security-Related Statements 1403 This section collects the various statements in the currently 1404 existing DetNet Working Group drafts. For each draft, the section 1405 name and number of the quoted section is shown. The text shown here 1406 is the work of the original draft authors, quoted verbatim from the 1407 drafts. The intention is to explicitly quote all relevant text, not 1408 to summarize it. 1410 7.1. Architecture (draft 8) 1412 7.1.1. Fault Mitigation (sec 4.5) 1414 One key to building robust real-time systems is to reduce the 1415 infinite variety of possible failures to a number that can be 1416 analyzed with reasonable confidence. DetNet aids in the process by 1417 providing filters and policers to detect DetNet packets received on 1418 the wrong interface, or at the wrong time, or in too great a volume, 1419 and to then take actions such as discarding the offending packet, 1420 shutting down the offending DetNet flow, or shutting down the 1421 offending interface. 1423 It is also essential that filters and service remarking be employed 1424 at the network edge to prevent non-DetNet packets from being mistaken 1425 for DetNet packets, and thus impinging on the resources allocated to 1426 DetNet packets. 1428 There exist techniques, at present and/or in various stages of 1429 standardization, that can perform these fault mitigation tasks that 1430 deliver a high probability that misbehaving systems will have zero 1431 impact on well-behaved DetNet flows, except of course, for the 1432 receiving interface(s) immediately downstream of the misbehaving 1433 device. Examples of such techniques include traffic policing 1434 functions (e.g. [RFC2475]) and separating flows into per-flow rate- 1435 limited queues. 1437 7.1.2. Security Considerations (sec 7) 1439 Security in the context of Deterministic Networking has an added 1440 dimension; the time of delivery of a packet can be just as important 1441 as the contents of the packet, itself. A man-in-the-middle attack, 1442 for example, can impose, and then systematically adjust, additional 1443 delays into a link, and thus disrupt or subvert a real-time 1444 application without having to crack any encryption methods employed. 1445 See [RFC7384] for an exploration of this issue in a related context. 1447 Furthermore, in a control system where millions of dollars of 1448 equipment, or even human lives, can be lost if the DetNet QoS is not 1449 delivered, one must consider not only simple equipment failures, 1450 where the box or wire instantly becomes perfectly silent, but bizarre 1451 errors such as can be caused by software failures. Because there is 1452 essential no limit to the kinds of failures that can occur, 1453 protecting against realistic equipment failures is indistinguishable, 1454 in most cases, from protecting against malicious behavior, whether 1455 accidental or intentional. 1457 Security must cover: 1459 o Protection of the signaling protocol 1461 o Authentication and authorization of the controlling nodes 1463 o Identification and shaping of the flows 1465 7.2. Data Plane Alternatives (draft 4) 1467 7.2.1. Security Considerations (sec 7) 1469 This document does not add any new security considerations beyond 1470 what the referenced technologies already have. 1472 7.3. Problem Statement (draft 5) 1474 7.3.1. Security Considerations (sec 5) 1476 Security in the context of Deterministic Networking has an added 1477 dimension; the time of delivery of a packet can be just as important 1478 as the contents of the packet, itself. A man-in-the-middle attack, 1479 for example, can impose, and then systematically adjust, additional 1480 delays into a link, and thus disrupt or subvert a real-time 1481 application without having to crack any encryption methods employed. 1482 See [RFC7384] for an exploration of this issue in a related context. 1484 Typical control networks today rely on complete physical isolation to 1485 prevent rogue access to network resources. DetNet enables the 1486 virtualization of those networks over a converged IT/OT 1487 infrastructure. Doing so, DetNet introduces an additional risk that 1488 flows interact and interfere with one another as they share physical 1489 resources such as Ethernet trunks and radio spectrum. The 1490 requirement is that there is no possible data leak from and into a 1491 deterministic flow, and in a more general fashion there is no 1492 possible influence whatsoever from the outside on a deterministic 1493 flow. The expectation is that physical resources are effectively 1494 associated with a given flow at a given point of time. In that 1495 model, Time Sharing of physical resources becomes transparent to the 1496 individual flows which have no clue whether the resources are used by 1497 other flows at other times. 1499 Security must cover: 1501 o Protection of the signaling protocol 1502 o Authentication and authorization of the controlling nodes 1504 o Identification and shaping of the flows 1506 o Isolation of flows from leakage and other influences from any 1507 activity sharing physical resources 1509 7.4. Use Cases (draft 11) 1511 7.4.1. (Utility Networks) Security Current Practices and Limitations 1512 (sec 3.2.1) 1514 Grid monitoring and control devices are already targets for cyber 1515 attacks, and legacy telecommunications protocols have many intrinsic 1516 network-related vulnerabilities. For example, DNP3, Modbus, 1517 PROFIBUS/PROFINET, and other protocols are designed around a common 1518 paradigm of request and respond. Each protocol is designed for a 1519 master device such as an HMI (Human Machine Interface) system to send 1520 commands to subordinate slave devices to retrieve data (reading 1521 inputs) or control (writing to outputs). Because many of these 1522 protocols lack authentication, encryption, or other basic security 1523 measures, they are prone to network-based attacks, allowing a 1524 malicious actor or attacker to utilize the request-and-respond system 1525 as a mechanism for command-and-control like functionality. Specific 1526 security concerns common to most industrial control, including 1527 utility telecommunication protocols include the following: 1529 o Network or transport errors (e.g. malformed packets or excessive 1530 latency) can cause protocol failure. 1532 o Protocol commands may be available that are capable of forcing 1533 slave devices into inoperable states, including powering-off 1534 devices, forcing them into a listen-only state, disabling 1535 alarming. 1537 o Protocol commands may be available that are capable of restarting 1538 communications and otherwise interrupting processes. 1540 o Protocol commands may be available that are capable of clearing, 1541 erasing, or resetting diagnostic information such as counters and 1542 diagnostic registers. 1544 o Protocol commands may be available that are capable of requesting 1545 sensitive information about the controllers, their configurations, 1546 or other need-to-know information. 1548 o Most protocols are application layer protocols transported over 1549 TCP; therefore it is easy to transport commands over non-standard 1550 ports or inject commands into authorized traffic flows. 1552 o Protocol commands may be available that are capable of 1553 broadcasting messages to many devices at once (i.e. a potential 1554 DoS). 1556 o Protocol commands may be available to query the device network to 1557 obtain defined points and their values (i.e. a configuration 1558 scan). 1560 o Protocol commands may be available that will list all available 1561 function codes (i.e. a function scan). 1563 o These inherent vulnerabilities, along with increasing connectivity 1564 between IT an OT networks, make network-based attacks very 1565 feasible. 1567 o Simple injection of malicious protocol commands provides control 1568 over the target process. Altering legitimate protocol traffic can 1569 also alter information about a process and disrupt the legitimate 1570 controls that are in place over that process. A man-in-the-middle 1571 attack could provide both control over a process and 1572 misrepresentation of data back to operator consoles. 1574 7.4.2. (Utility Networks) Security Trends in Utility Networks (sec 1575 3.3.3) 1577 Although advanced telecommunications networks can assist in 1578 transforming the energy industry by playing a critical role in 1579 maintaining high levels of reliability, performance, and 1580 manageability, they also introduce the need for an integrated 1581 security infrastructure. Many of the technologies being deployed to 1582 support smart grid projects such as smart meters and sensors can 1583 increase the vulnerability of the grid to attack. Top security 1584 concerns for utilities migrating to an intelligent smart grid 1585 telecommunications platform center on the following trends: 1587 o Integration of distributed energy resources 1589 o Proliferation of digital devices to enable management, automation, 1590 protection, and control 1592 o Regulatory mandates to comply with standards for critical 1593 infrastructure protection 1595 o Migration to new systems for outage management, distribution 1596 automation, condition-based maintenance, load forecasting, and 1597 smart metering 1599 o Demand for new levels of customer service and energy management 1601 This development of a diverse set of networks to support the 1602 integration of microgrids, open-access energy competition, and the 1603 use of network-controlled devices is driving the need for a converged 1604 security infrastructure for all participants in the smart grid, 1605 including utilities, energy service providers, large commercial and 1606 industrial, as well as residential customers. Securing the assets of 1607 electric power delivery systems (from the control center to the 1608 substation, to the feeders and down to customer meters) requires an 1609 end-to-end security infrastructure that protects the myriad of 1610 telecommunications assets used to operate, monitor, and control power 1611 flow and measurement. 1613 "Cyber security" refers to all the security issues in automation and 1614 telecommunications that affect any functions related to the operation 1615 of the electric power systems. Specifically, it involves the 1616 concepts of: 1618 o Integrity : data cannot be altered undetectably 1620 o Authenticity : the telecommunications parties involved must be 1621 validated as genuine 1623 o Authorization : only requests and commands from the authorized 1624 users can be accepted by the system 1626 o Confidentiality : data must not be accessible to any 1627 unauthenticated users 1629 When designing and deploying new smart grid devices and 1630 telecommunications systems, it is imperative to understand the 1631 various impacts of these new components under a variety of attack 1632 situations on the power grid. Consequences of a cyber attack on the 1633 grid telecommunications network can be catastrophic. This is why 1634 security for smart grid is not just an ad hoc feature or product, 1635 it's a complete framework integrating both physical and Cyber 1636 security requirements and covering the entire smart grid networks 1637 from generation to distribution. Security has therefore become one 1638 of the main foundations of the utility telecom network architecture 1639 and must be considered at every layer with a defense-in-depth 1640 approach. Migrating to IP based protocols is key to address these 1641 challenges for two reasons: 1643 o IP enables a rich set of features and capabilities to enhance the 1644 security posture 1646 o IP is based on open standards, which allows interoperability 1647 between different vendors and products, driving down the costs 1648 associated with implementing security solutions in OT networks. 1650 Securing OT (Operation technology) telecommunications over packet- 1651 switched IP networks follow the same principles that are foundational 1652 for securing the IT infrastructure, i.e., consideration must be given 1653 to enforcing electronic access control for both person-to-machine and 1654 machine-to-machine communications, and providing the appropriate 1655 levels of data privacy, device and platform integrity, and threat 1656 detection and mitigation. 1658 7.4.3. (BAS) Security Considerations (sec 4.2.4) 1660 When BAS field networks were developed it was assumed that the field 1661 networks would always be physically isolated from external networks 1662 and therefore security was not a concern. In today's world many BASs 1663 are managed remotely and are thus connected to shared IP networks and 1664 so security is definitely a concern, yet security features are not 1665 available in the majority of BAS field network deployments . 1667 The management network, being an IP-based network, has the protocols 1668 available to enable network security, but in practice many BAS 1669 systems do not implement even the available security features such as 1670 device authentication or encryption for data in transit. 1672 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) 1674 On top of the classical requirements for protection of control 1675 signaling, it must be noted that 6TiSCH networks operate on limited 1676 resources that can be depleted rapidly in a DoS attack on the system, 1677 for instance by placing a rogue device in the network, or by 1678 obtaining management control and setting up unexpected additional 1679 paths. 1681 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 1683 Establishing time-sensitive streams in the network entails reserving 1684 networking resources for long periods of time. It is important that 1685 these reservation requests be authenticated to prevent malicious 1686 reservation attempts from hostile nodes (or accidental 1687 misconfiguration). This is particularly important in the case where 1688 the reservation requests span administrative domains. Furthermore, 1689 the reservation information itself should be digitally signed to 1690 reduce the risk of a legitimate node pushing a stale or hostile 1691 configuration into another networking node. 1693 Note: This is considered important for the security policy of the 1694 network, but does not affect the core DetNet architecture and design. 1696 7.4.6. (Industrial M2M) Communication Today (sec 7.2) 1698 Industrial network scenarios require advanced security solutions. 1699 Many of the current industrial production networks are physically 1700 separated. Preventing critical flows from be leaked outside a domain 1701 is handled today by filtering policies that are typically enforced in 1702 firewalls. 1704 8. IANA Considerations 1706 This memo includes no requests from IANA. 1708 9. Security Considerations 1710 The security considerations of DetNet networks are presented 1711 throughout this document. 1713 10. Informative References 1715 [ARINC664P7] 1716 ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics 1717 Full-Duplex Switched Ethernet Network", 2009. 1719 [I-D.ietf-detnet-architecture] 1720 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1721 "Deterministic Networking Architecture", draft-ietf- 1722 detnet-architecture-03 (work in progress), August 2017. 1724 [I-D.ietf-detnet-use-cases] 1725 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 1726 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 1727 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 1728 X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D., 1729 Geng, X., Dujovne, D., and M. Seewald, "Deterministic 1730 Networking Use Cases", draft-ietf-detnet-use-cases-13 1731 (work in progress), September 2017. 1733 [I-D.varga-detnet-service-model] 1734 Varga, B. and J. Farkas, "DetNet Service Model", draft- 1735 varga-detnet-service-model-02 (work in progress), May 1736 2017. 1738 [IEEE1588] 1739 IEEE, "IEEE 1588 Standard for a Precision Clock 1740 Synchronization Protocol for Networked Measurement and 1741 Control Systems Version 2", 2008. 1743 [MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/ 1744 hacked-cameras-dvrs-powered-todays-massive-internet- 1745 outage/", 2016. 1747 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1748 Text on Security Considerations", BCP 72, RFC 3552, 1749 DOI 10.17487/RFC3552, July 2003, 1750 . 1752 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1753 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1754 October 2014, . 1756 Authors' Addresses 1758 Tal Mizrahi 1759 Marvell 1761 Email: talmi@marvell.com 1763 Ethan Grossman (editor) 1764 Dolby Laboratories, Inc. 1765 1275 Market Street 1766 San Francisco, CA 94103 1767 USA 1769 Phone: +1 415 645 4726 1770 Email: ethan.grossman@dolby.com 1771 URI: http://www.dolby.com 1773 Andrew J. Hacker 1774 MistIQ Technologies, Inc 1775 Harrisburg, PA 1776 USA 1778 Email: ajhacker@mistiqtech.com 1779 URI: http://www.mistiqtech.com 1780 Subir Das 1781 Applied Communication Sciences 1782 150 Mount Airy Road, Basking Ridge 1783 New Jersey, 07920 1784 USA 1786 Email: sdas@appcomsci.com 1788 John Dowdell 1789 Airbus Defence and Space 1790 Celtic Springs 1791 Newport NP10 8FZ 1792 United Kingdom 1794 Email: john.dowdell.ietf@gmail.com 1796 Henrik Austad 1797 Cisco Systems 1798 Philip Pedersens vei 1 1799 Lysaker 1366 1800 Norway 1802 Email: henrik@austad.us 1804 Kevin Stanton 1805 Intel 1807 Email: kevin.b.stanton@intel.com 1809 Norman Finn 1810 Huawei 1812 Email: norman.finn@mail01.huawei.com