idnits 2.17.1 draft-ietf-detnet-security-00.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 (September 29, 2017) is 2391 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2475' is mentioned on line 1194, 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-12 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: April 2, 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 September 29, 2017 20 Deterministic Networking (DetNet) Security Considerations 21 draft-ietf-detnet-security-00 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 April 2, 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 Identification . . . . . . . . . . . . . 7 88 3.2.2.1. DetNet Flow Modification or Spoofing . . . . . . 7 89 3.2.3. Resource Segmentation or Slicing . . . . . . . . . . 7 90 3.2.3.1. Inter-segment Attack . . . . . . . . . . . . . . 7 91 3.2.4. Packet Replication and Elimination . . . . . . . . . 7 92 3.2.4.1. Replication: Increased Attack Surface . . . . . . 8 93 3.2.4.2. Replication-related Header Manipulation . . . . . 8 95 3.2.5. Path Choice . . . . . . . . . . . . . . . . . . . . . 8 96 3.2.5.1. Path Manipulation . . . . . . . . . . . . . . . . 8 97 3.2.5.2. Path Choice: Increased Attack Surface . . . . . . 8 98 3.2.6. Control Plane . . . . . . . . . . . . . . . . . . . . 9 99 3.2.6.1. Control or Signaling Packet Modification . . . . 9 100 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 101 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 102 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 103 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9 104 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 105 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 106 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 10 107 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 11 108 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 11 109 4.2. Flow Identification and Spoofing . . . . . . . . . . . . 11 110 4.2.1. Flow identification . . . . . . . . . . . . . . . . . 11 111 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 12 112 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 12 113 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 12 114 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 12 115 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 12 116 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 13 117 4.4. Replication and Elimination . . . . . . . . . . . . . . . 13 118 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 13 119 4.4.2. Header Manipulation at Elimination Bridges . . . . . 13 120 4.5. Impact of Attacks to Path Choice . . . . . . . . . . . . 13 121 4.6. Impact of Attacks by Use Case Industry . . . . . . . . . 13 122 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 15 123 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 16 124 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 16 125 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 16 126 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 17 127 5.5. Control and Signaling Message Protection . . . . . . . . 17 128 5.6. Dynamic Performance Analytics . . . . . . . . . . . . . . 17 129 5.7. Mitigation Summary . . . . . . . . . . . . . . . . . . . 18 130 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 19 131 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 19 132 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 19 133 6.1.2. Central Administration . . . . . . . . . . . . . . . 19 134 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 20 135 6.1.4. Data Flow Information Models . . . . . . . . . . . . 20 136 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 20 137 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 20 138 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 20 139 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 20 140 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 21 141 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 21 142 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 21 143 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 21 144 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 21 145 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 22 146 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 22 147 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 22 148 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 22 149 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 23 150 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 23 151 6.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 23 152 6.1.21. Reliability and Availability . . . . . . . . . . . . 23 153 6.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 24 154 6.1.23. Security Measures . . . . . . . . . . . . . . . . . . 24 155 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 24 156 7. Appendix A: DetNet Draft Security-Related Statements . . . . 26 157 7.1. Architecture (draft 8) . . . . . . . . . . . . . . . . . 27 158 7.1.1. Fault Mitigation (sec 4.5) . . . . . . . . . . . . . 27 159 7.1.2. Security Considerations (sec 7) . . . . . . . . . . . 27 160 7.2. Data Plane Alternatives (draft 4) . . . . . . . . . . . . 28 161 7.2.1. Security Considerations (sec 7) . . . . . . . . . . . 28 162 7.3. Problem Statement (draft 5) . . . . . . . . . . . . . . . 28 163 7.3.1. Security Considerations (sec 5) . . . . . . . . . . . 28 164 7.4. Use Cases (draft 11) . . . . . . . . . . . . . . . . . . 29 165 7.4.1. (Utility Networks) Security Current Practices and 166 Limitations (sec 3.2.1) . . . . . . . . . . . . . . . 29 167 7.4.2. (Utility Networks) Security Trends in Utility 168 Networks (sec 3.3.3) . . . . . . . . . . . . . . . . 30 169 7.4.3. (BAS) Security Considerations (sec 4.2.4) . . . . . . 32 170 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) . . . . 32 171 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 32 172 7.4.6. (Industrial M2M) Communication Today (sec 7.2) . . . 33 173 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 174 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 175 10. Informative References . . . . . . . . . . . . . . . . . . . 33 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 178 1. Introduction 180 Security is of particularly high importance in DetNet networks 181 because many of the use cases which are enabled by DetNet 182 [I-D.ietf-detnet-use-cases] include control of physical devices 183 (power grid components, industrial controls, building controls) which 184 can have high operational costs for failure, and present potentially 185 attractive targets for cyber-attackers. 187 This situation is even more acute given that one of the goals of 188 DetNet is to provide a "converged network", i.e. one that includes 189 both IT traffic and OT traffic, thus exposing potentially sensitive 190 OT devices to attack in ways that were not previously common (usually 191 because they were under a separate control system or otherwise 192 isolated from the IT network). Security considerations for OT 193 networks is not a new area, and there are many OT networks today that 194 are connected to wide area networks or the Internet; this draft 195 focuses on the issues that are specific to the DetNet technologies 196 and use cases. 198 The DetNet technologies include ways to: 200 o Reserve data plane resources for DetNet flows in some or all of 201 the intermediate nodes (e.g. bridges or routers) along the path of 202 the flow 204 o Provide explicit routes for DetNet flows that do not rapidly 205 change with the network topology 207 o Distribute data from DetNet flow packets over time and/or space to 208 ensure delivery of each packet's data' in spite of the loss of a 209 path 211 This draft includes sections on threat modeling and analysis, threat 212 impact and mitigation, and the association of various attacks with 213 various use cases both by industry and based on the Use Case Common 214 Themes section of the DetNet Use Cases draft 215 [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 238 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 are 256 different. For example, a delay attack is more relevant to data 257 plane than to control plane. There is also a difference in terms of 258 security solutions: the way you secure the data plane is often 259 different than the way you secure the control plane. 261 3.1. Threat Model 263 The threat model used in this memo is based on the threat model of 264 Section 3.1 of [RFC7384]. This model classifies attackers based on 265 two criteria: 267 o Internal vs. external: internal attackers either have access to a 268 trusted segment of the network or possess the encryption or 269 authentication keys. External attackers, on the other hand, do 270 not have the keys and have access only to the encrypted or 271 authenticated traffic. 273 o Man in the Middle (MITM) vs. packet injector: MITM attackers are 274 located in a position that allows interception and modification of 275 in-flight protocol packets, whereas a traffic injector can only 276 attack by generating protocol packets. 278 DetNet-Service, one of the service scenarios described in 279 [I-D.varga-detnet-service-model], is the case where a service 280 connects DetNet networking islands, i.e. two or more otherwise 281 independent DetNet network domains are connected via a link that is 282 not intrinsically part of either network. This implies that there 283 could be DetNet traffic flowing over a non-DetNet link, which may 284 provide an attacker with an advantageous opportunity to tamper with 285 DetNet traffic. The security properties of non-DetNet links are 286 outside of the scope of DetNet Security, but it should be noted that 287 use of non-DetNet services to interconnect DetNet networks merits 288 security analysis to ensure the integrity of the DetNet networks 289 involved. 291 3.2. Threat Analysis 293 3.2.1. Delay 295 3.2.1.1. Delay Attack 297 An attacker can maliciously delay DetNet data flow traffic. By 298 delaying the traffic, the attacker can compromise the service of 299 applications that are sensitive to high delays or to high delay 300 variation. 302 3.2.2. DetNet Flow Identification 304 3.2.2.1. DetNet Flow Modification or Spoofing 306 An attacker can modify some header fields of en route packets in a 307 way that causes the DetNet flow identification mechanisms to 308 misclassify the flow. Alternatively, the attacker can inject traffic 309 that is tailored to appear as if it belongs to a legitimate DetNet 310 flow. The potential consequence is that the DetNet flow resource 311 allocation cannot guarantee the performance that is expected when the 312 flow identification works correctly. 314 Note that in some cases there may be an explicit DetNet header, but 315 in some cases the flow identification may be based on fields from the 316 L3/L4 headers. If L3/L4 headers are involved, for purposes of this 317 draft we assume they are encrypted and/or integrity-protected from 318 external attackers. 320 3.2.3. Resource Segmentation or Slicing 322 3.2.3.1. Inter-segment Attack 324 An attacker can inject traffic, consuming network device resources, 325 thereby affecting DetNet flows. This can be performed using non- 326 DetNet traffic that affects DetNet traffic, or by using DetNet 327 traffic from one DetNet flow that affects traffic from different 328 DetNet flows. 330 3.2.4. Packet Replication and Elimination 331 3.2.4.1. Replication: Increased Attack Surface 333 Redundancy is intended to increase the robustness and survivability 334 of DetNet flows, and replication over multiple paths can potentially 335 mitigate an attack that is limited to a single path. However, the 336 fact that packets are replicated over multiple paths increases the 337 attack surface of the network, i.e., there are more points in the 338 network that may be subject to attacks. 340 3.2.4.2. Replication-related Header Manipulation 342 An attacker can manipulate the replication-related header fields 343 (R-TAG). This capability opens the door for various types of 344 attacks. For example: 346 o Forward both replicas - malicious change of a packet SN (Sequence 347 Number) can cause both replicas of the packet to be forwarded. 348 Note that this attack has a similar outcome to a replay attack. 350 o Eliminate both replicas - SN manipulation can be used to cause 351 both replicas to be eliminated. In this case an attacker that has 352 access to a single path can cause packets from other paths to be 353 dropped, thus compromising some of the advantage of path 354 redundancy. 356 o Flow hijacking - an attacker can hijack a DetNet flow with access 357 to a single path by systematically replacing the SNs on the given 358 path with higher SN values. For example, an attacker can replace 359 every SN value S with a higher value S+C, where C is a constant 360 integer. Thus, the attacker creates a false illusion that the 361 attacked path has the lowest delay, causing all packets from other 362 paths to be eliminated. Once the flow is hijacked the attacker 363 can either replace en route packets with malicious packets, or 364 simply injecting errors, causing the packets to be dropped at 365 their destination. 367 3.2.5. Path Choice 369 3.2.5.1. Path Manipulation 371 An attacker can maliciously change, add, or remove a path, thereby 372 affecting the corresponding DetNet flows that use the path. 374 3.2.5.2. Path Choice: Increased Attack Surface 376 One of the possible consequences of a path manipulation attack is an 377 increased attack surface. Thus, when the attack described in the 378 previous subsection is implemented, it may increase the potential of 379 other attacks to be performed. 381 3.2.6. Control Plane 383 3.2.6.1. Control or Signaling Packet Modification 385 An attacker can maliciously modify en route control packets in order 386 to disrupt or manipulate the DetNet path/resource allocation. 388 3.2.6.2. Control or Signaling Packet Injection 390 An attacker can maliciously inject control packets in order to 391 disrupt or manipulate the DetNet path/resource allocation. 393 3.2.7. Scheduling or Shaping 395 3.2.7.1. Reconnaissance 397 A passive eavesdropper can gather information about en route DetNet 398 flows, e.g., the number of DetNet flows, their bandwidths, and their 399 schedules. The gathered information can later be used to invoke 400 other attacks on some or all of the flows. 402 3.2.8. Time Synchronization Mechanisms 404 An attacker can use any of the attacks described in [RFC7384] to 405 attack the synchronization protocol, thus affecting the DetNet 406 service. 408 3.3. Threat Summary 410 A summary of the attacks that were discussed in this section is 411 presented in Figure 1. For each attack, the table specifies the type 412 of attackers that may invoke the attack. In the context of this 413 summary, the distinction between internal and external attacks is 414 under the assumption that a corresponding security mechanism is being 415 used, and that the corresponding network equipment takes part in this 416 mechanism. 418 +-----------------------------------------+----+----+----+----+ 419 | Attack | Attacker Type | 420 | +---------+---------+ 421 | |Internal |External | 422 | |MITM|Inj.|MITM|Inj.| 423 +-----------------------------------------+----+----+----+----+ 424 |Delay attack | + | | + | | 425 +-----------------------------------------+----+----+----+----+ 426 |DetNet Flow Modification or Spoofing | + | + | | | 427 +-----------------------------------------+----+----+----+----+ 428 |Inter-segment Attack | + | + | | | 429 +-----------------------------------------+----+----+----+----+ 430 |Replication: Increased Attack Surface | + | + | + | + | 431 +-----------------------------------------+----+----+----+----+ 432 |Replication-related Header Manipulation | + | | | | 433 +-----------------------------------------+----+----+----+----+ 434 |Path Manipulation | + | + | | | 435 +-----------------------------------------+----+----+----+----+ 436 |Path Choice: Increased Attack Surface | + | + | + | + | 437 +-----------------------------------------+----+----+----+----+ 438 |Control or Signaling Packet Modification | + | | | | 439 +-----------------------------------------+----+----+----+----+ 440 |Control or Signaling Packet Injection | | + | | | 441 +-----------------------------------------+----+----+----+----+ 442 |Reconnaissance | + | | + | | 443 +-----------------------------------------+----+----+----+----+ 444 |Attacks on Time Sync Mechanisms | + | + | + | + | 445 +-----------------------------------------+----+----+----+----+ 447 Figure 1: Threat Analysis Summary 449 4. Security Threat Impacts 451 This section describes the impact of the attacks described in 452 Section 3. Mitigations are discussed further in Section 5. 454 In computer security, the impact (or consequence) of an incident can 455 be measured in loss of confidentiality, integrity or availability of 456 information. In other words, this section describes the effect of a 457 successful attack. The scope is limited to the effect of a 458 successful attack on DetNet itself, not the applications that _use_ 459 Detnet as this is highly application specific. 461 4.1. Delay-Attacks 462 4.1.1. Data Plane Delay Attacks 464 Dropped messages can result in stream instability. If only a single 465 path is used, the entire stream can be disrupted. In a multipath 466 scenario, large delays on one stream can lead to increased buffer and 467 CPU resources on the elimination bridge. 469 If the attack is carried out on a sole link (i.e. no multipath), the 470 DetNet stream can be interrupted and result in outages. 472 4.1.2. Control Plane Delay Attacks 474 In and of itself, this is not directly a threat, the effects of 475 delaying control messages can have quite adverse effects later. 477 Delayed messages for tear-down can lead to resource leakage if a 478 stream is not torn down at the correct time. This can in turn result 479 in failure to allocate new streams giving rise to a denial of service 480 attack. 482 In the case where an End-point should be added to a multicast, 483 failure to deliver said signalling message will prevent the new EP 484 from receiving expected frames. 486 Likewise, when an EP should be removed from a multicast group, 487 delaying such messages can lead to loss of privacy as the EP will 488 continue to receive messages even after it is removed. 490 4.2. Flow Identification and Spoofing 492 4.2.1. Flow identification 494 Of all the attacks, this is one of the most difficult to detect and 495 counter. Often, an attacker will start out by observing the traffic 496 going through the network and use the knowledge gathered in this 497 phase to mount future attacks. 499 The attacker can, at their leisure, observe over time all aspects of 500 the messaging and signalling, learning the intent and purpose of all 501 traffic flows. At some later date, possibly at an important time in 502 an operational context, the attacker can launch a multi-faceted 503 attack, possibly in conjunction with some demand for ransom. 505 The flow-id in the header of the data plane-messages gives an 506 attacker a very reliable identifier for DetNet traffic, and this 507 traffic has a high probability of going to lucrative targets. 509 4.2.2. Spoofing 511 4.2.2.1. Dataplane Spoofing 513 Spoofing dataplane messages can result in increased resource 514 consumptions on the bridges throughout the network as it will 515 increase buffer usage and CPU utilization. This can lead to resource 516 exhaustion and/or increased delay. 518 If the attacker manages to create valid headers, the false messages 519 can be forwarded through the network, using part of the allocated 520 bandwidth. This in turn can cause legitimate messages to be dropped 521 when the budget has been exhausted. 523 Finally, the endpoint will have to deal with invalid messages being 524 delivered to the endpoint instead of (or in addition to) a valid 525 message. 527 4.2.2.2. Control Plane Spoofing 529 A successful control plane spoofing-attack has a very large 530 potential. It can do anything from modifying existing streams by 531 changing the available bandwidth, add or remove endpoints or drop the 532 stream altogether. It would also be possible to falsely create new 533 streams, which could give an attacker the ability to exhaust the 534 systems resources, or just enable a high quality DetNet stream 535 outside the Network engineer's control. 537 4.3. Segmentation attacks (injection) 539 4.3.1. Data Plane Segmentation 541 Injection of false messages in a DetNet stream could lead to 542 exhaustion of the available bandwidth for a stream if the bridges 543 accounts false messages to the stream's budget. 545 In a multipath scenario, injected messages will cause an increased 546 CPU utilization on elimination bridges and if enough paths are 547 subject to malicious injection, the legitimate messages could be 548 dropped. Likewise it can cause an increase in buffer usage. In 549 total, this will consume more resources on the bridges than normal, 550 giving rise to a potential resource exhaustion attack on the bridges. 552 If a stream is interrupted, the end application will be affected by 553 what is now a non-deterministic stream. 555 4.3.2. Control Plane segmentation 557 A successful Control Plane segmentation attack will cause control 558 messages to be interpreted by nodes in the network. This has the 559 potential to create new streams (exhausting resources), drop existing 560 (denial of service), add/remove end-stations to a multicast group 561 (loss of privacy) or modify the stream attributes (reducing available 562 bandwidth, or increasing it so that new streams cannot reserve a 563 path). 565 In short, this means that you cannot trust the stream reservation 566 properties or the network itself. 568 As with spoofing, if an attacker is able to inject control-plane 569 messages and the receiving end does not detect it, the receiving 570 station must be able to. 572 4.4. Replication and Elimination 574 The Replication and Elimination is relevant only to Data Plane 575 messages as Signalling is not subject to multipath routing. 577 4.4.1. Increased Attack Surface 579 Covered briefly in Section 4.3 581 4.4.2. Header Manipulation at Elimination Bridges 583 Covered briefly in Section 4.3 585 4.5. Impact of Attacks to Path Choice 587 This is covered in part in Section 4.3, and as with Replication and 588 Elimination (Section 4.4, this is relevant for DataPlane messages. 590 4.6. Impact of Attacks by Use Case Industry 592 This section rates the severity of various components of the impact 593 of a successful vulnerability exploit to use cases by industry as 594 described in [I-D.ietf-detnet-use-cases], including Pro Audio, 595 Electrical Utilities, Building Automation, Wireless for Industrial, 596 Cellular Radio, and Industrial M2M (split into two areas, M2M Data 597 Gathering and M2M Control Loop). 599 Components of Impact (left column) include Criticality of Failure, 600 Effects of Failure, Recovery, and DetNet Functional Dependence. 601 Criticality of failure summarizes the seriousness of the impact. The 602 impact of a resulting failure can affect many different metrics that 603 vary greatly in scope and severity. In order to reduce the number of 604 variables, the following were included: Financial, Health and Safety, 605 People well being, Affect on a single organization, and affect on 606 multiple organizations. Recovery outlines how long it would take for 607 an affected use case to get back to its pre-failure state (Recovery 608 time objective, RTO), and how much of the original service would be 609 lost in between the time of service failure and recovery to original 610 state (Recovery Point Objective, RPO). DetNET dependence maps how 611 much the following DetNet service objectives contribute to impact of 612 failure: Time dependency, data integrity, source node integrity, 613 availability, latency/jitter. 615 The scale of the Impact mappings is low, medium, and high. In some 616 use cases there may be a multitude of specific applications in which 617 DetNET is used. For simplicity this section attempts to average the 618 varied impacts of different applications. This section does not 619 address the overall risk of a certain impact which would require the 620 likelihood of a failure happening. 622 In practice any such ratings will vary from case to case; the ratings 623 shown here are given as examples. 625 +------------------+-----------------------------------------+-----+ 626 | | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M | 627 | | | | | less | |Data |Ctrl | 628 +------------------+-----------------------------------------+-----+ 629 | Criticality | Med | Hi | Low | Med | Med | Med | Med | 630 +------------------+-----------------------------------------+-----+ 631 | Effects 632 +------------------+-----------------------------------------+-----+ 633 | Financial | Med | Hi | Med | Med | Low | Med | Med | 634 +------------------+-----------------------------------------+-----+ 635 | Health/Safety | Med | Hi | Hi | Med | Med | Med | Med | 636 +------------------+-----------------------------------------+-----+ 637 | People WB | Med | Hi | Hi | Low | Hi | Low | Low | 638 +------------------+-----------------------------------------+-----+ 639 | Effect 1 org | Hi | Hi | Med | Hi | Med | Med | Med | 640 +------------------+-----------------------------------------+-----+ 641 | Effect >1 org | Med | Hi | Low | Med | Med | Med | Med | 642 +------------------+-----------------------------------------+-----+ 643 |Recovery 644 +------------------+-----------------------------------------+-----+ 645 | Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi | 646 +------------------+-----------------------------------------+-----+ 647 | Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi | 648 +------------------+-----------------------------------------+-----+ 649 |DetNet Dependence 650 +------------------+-----------------------------------------+-----+ 651 | Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi | 652 +------------------+-----------------------------------------+-----+ 653 | Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi | 654 +------------------+-----------------------------------------+-----+ 655 | Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Low | 656 +------------------+-----------------------------------------+-----+ 657 | Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi | 658 +------------------+-----------------------------------------+-----+ 659 | Availability | Hi | Hi | Med | Hi | Low | Hi | Hi | 660 +------------------+-----------------------------------------+-----+ 662 Figure 2: Impact of Attacks by Use Case Industry 664 5. Security Threat Mitigation 666 This section describes a set of measures that can be taken to 667 mitigate the attacks described in Section 3. These mitigations 668 should be viewed as a toolset that includes several different and 669 diverse tools. Each application or system will typically use a 670 subset of these tools, based on a system-specific threat analysis. 672 5.1. Path Redundancy 674 Description 676 A DetNet flow that can be forwarded simultaneously over multiple 677 paths. Path replication and elimination 678 [I-D.ietf-detnet-architecture] provides resiliency to dropped or 679 delayed packets. This redundancy improves the robustness to 680 failures and to man-in-the-middle attacks. 682 Related attacks 684 Path redundancy can be used to mitigate various man-in-the-middle 685 attacks, including attacks described in Section 3.2.1, 686 Section 3.2.2, Section 3.2.3, and Section 3.2.8. 688 5.2. Integrity Protection 690 Description 692 An integrity protection mechanism, such as a Hash-based Message 693 Authentication Code (HMAC) can be used to mitigate modification 694 attacks. Integrity protection can be used on the data plane 695 header, to prevent its modification and tampering. Integrity 696 protection in the control plane is discussed in Section 5.5. 698 Related attacks 700 Integrity protection mitigates attacks related to modification and 701 tampering, including the attacks described in Section 3.2.2 and 702 Section 3.2.4. 704 5.3. DetNet Node Authentication 706 Description 708 Source authentication verifies the authenticity of DetNet sources, 709 allowing to mitigate spoofing attacks. Note that while integrity 710 protection (Section 5.2) prevents intermediate nodes from 711 modifying information, authentication verfies the source of the 712 information. 714 Related attacks 716 DetNet node authentication is used to mitigate attacks related to 717 spoofing, including the attacks of Section 3.2.2, and 718 Section 3.2.4. 720 5.4. Encryption 722 Description 724 DetNet flows can be forwarded in encrypted form. 726 Related attacks 728 While confidentiality is not considered an important goal with 729 respect to DetNet, encryption can be used to mitigate recon 730 attacks (Section 3.2.7). 732 5.5. Control and Signaling Message Protection 734 Description 736 Control and sigaling messages can be protected using 737 authentication and integrity protection mechanisms. 739 Related attacks 741 These mechanisms can be used to mitigate various attacks on the 742 control plane, as described in Section 3.2.6, Section 3.2.8 and 743 Section 3.2.5. 745 5.6. Dynamic Performance Analytics 747 Description 749 Information about the network performance can be gathered in real- 750 time in order to detect anomalies and unusual behavior that may be 751 the symptom of a security attack. The gathered information can be 752 based, for example, on per-flow counters, bandwidth measurement, 753 and monitoring of packet arrival times. Unusual behavior or 754 potentially malicious nodes can be reported to a management 755 system, or can be used as a trigger for taking corrective actions. 756 The information can be tracked by DetNet end systems and transit 757 nodes, and exported to a management system, for example using 758 NETCONF. 760 Related attacks 762 Performance analytics can be used to mitigate various attacks, 763 including the ones described in Section 3.2.1, Section 3.2.3, and 764 Section 3.2.8. 766 5.7. Mitigation Summary 768 The following table maps the attacks of Section 3 to the impacts of 769 Section 4, and to the mitigations of the current section. Each row 770 specifies an attack, the impact of this attack if it is successfully 771 implemented, and possible mitigation methods. 773 +----------------------+---------------------+---------------------+ 774 | Attack | Impact | Mitigations | 775 +----------------------+---------------------+---------------------+ 776 |Delay Attack |-Non-deterministic |-Path redundancy | 777 | | delay |-Performance | 778 | |-Data disruption | analytics | 779 | |-Increased resource | | 780 | | consumption | | 781 +----------------------+---------------------+---------------------+ 782 |DetNet Flow Modificat-|-Increased resource |-Path redundancy | 783 |ion or Spoofing | consumption |-Integrity protection| 784 | |-Data disruption |-DetNet Node | 785 | | | authentication | 786 +----------------------+---------------------+---------------------+ 787 |Inter-Segment Attack |-Increased resource |-Path redundancy | 788 | | consumption |-Performance | 789 | |-Data disruption | analytics | 790 +----------------------+---------------------+---------------------+ 791 |Replication: Increased|-All impacts of other|-Integrity protection| 792 |attack surface | attacks |-DetNet Node | 793 | | | authentication | 794 +----------------------+---------------------+---------------------+ 795 |Replication-related |-Non-deterministic |-Integrity protection| 796 |Header Manipulation | delay |-DetNet Node | 797 | |-Data disruption | authentication | 798 +----------------------+---------------------+---------------------+ 799 |Path Manipulation |-Enabler for other |-Control message | 800 | | attacks | protection | 801 +----------------------+---------------------+---------------------+ 802 |Path Choice: Increased|-All impacts of other|-Control message | 803 |Attack Surface | attacks | protection | 804 +----------------------+---------------------+---------------------+ 805 |Control or Signaling |-Increased resource |-Control message | 806 |Packet Modification | consumption | protection | 807 | |-Non-deterministic | | 808 | | delay | | 809 | |-Data disruption | | 810 +----------------------+---------------------+---------------------+ 811 |Control or Signaling |-Increased resource |-Control message | 812 |Packet Injection | consumption | protection | 813 | |-Non-deterministic | | 814 | | delay | | 815 | |-Data disruption | | 816 +----------------------+---------------------+---------------------+ 817 |Reconnaissance |-Enabler for other |-Encryption | 818 | | attacks | | 819 +----------------------+---------------------+---------------------+ 820 |Attacks on Time Sync |-Non-deterministic |-Path redundancy | 821 |Mechanisms | delay |-Control message | 822 | |-Increased resource | protection | 823 | | consumption |-Performance | 824 | |-Data disruption | analytics | 825 +----------------------+---------------------+---------------------+ 827 Figure 3: Mapping Attacks to Impact and Mitigations 829 6. Association of Attacks to Use Cases 831 6.1. Use Cases by Common Themes 833 Different attacks can have different impact and/or mitigation 834 depending on the use case, so we would like to make this association 835 in our analysis. However since there is a potentially unbounded list 836 of use cases, we categorize the attacks with respect to the common 837 themes of the use cases as identified in the Use Case Common Themes 838 section of the DetNet Use Cases draft [I-D.ietf-detnet-use-cases]. 839 We describe each theme and its associated attacks, impacts and 840 mitigations. 842 6.1.1. Network Layer - AVB/TSN Ethernet 844 Presumably it will be possible to run DetNet over other underlying 845 network layers besides Ethernet, but Ethernet is explicitly 846 supported. Is the attack specific to the Ethernet AVB/TSN protocols? 847 Does the threat affect only Ethernet, or any underlying network 848 layer? 850 6.1.2. Central Administration 852 A DetNet network is expected to be controlled by a centralized 853 network configuration and control system. Such a system may be in a 854 single central location, or it may be distributed across multiple 855 control entities that function together as a unified control system 856 for the network. Is the attack directed at threat the central 857 control system of the network? Does it interfere with OAM? 859 6.1.3. Hot Swap 861 A DetNet network is not expected to be "plug and play" - it is 862 expected that there is some centralized network configuration and 863 control system. However, the ability to "hot swap" components (e.g. 864 due to malfunction) is similar enough to "plug and play" that this 865 kind of behavior may be expected in DetNet networks, depending on the 866 implementation. Does the attack target "hot swap" ("plug and play") 867 operation in the network? 869 6.1.4. Data Flow Information Models 871 Data Flow Information Models specific to DetNet networks are to be 872 specified by DetNet. Thus they are "new" and thus potentially 873 present a new attack surface. Does the threat take advantage of any 874 aspect of our new Data Flow Info Models? 876 6.1.5. L2 and L3 Integration 878 A DetNet network is intended to integrate between Layer 2 (bridged) 879 network(s) (e.g. AVB/TSN LAN) and Layer 3 (routed) network(s) (e.g. 880 using IP-based protocols). Does the attack target L2? L3? Both? 881 The interaction between the two? 883 6.1.6. End-to-End Delivery 885 Packets sent over DetNet are guaranteed not to be dropped by the 886 network due to congestion. (Packets may however be dropped for 887 intended reasons, e.g. per security measures). Does the attack 888 result in packets (which should be delivered) not being delivered? 889 Does it result in packets that should not be delivered being 890 delivered? 892 6.1.7. Proprietary Deterministic Ethernet Networks 894 There are many proprietary non-interoperable deterministic Ethernet- 895 based networks currently available; DetNet is intended to provide an 896 open-standards-based alternative to such networks. Does the threat 897 relate to a specific such network that is being "emulated" or 898 "replaced" by DetNet, for example by exploiting specific commands 899 specific to that network protocol? 901 6.1.8. Replacement for Proprietary Fieldbuses 903 There are many proprietary "field buses" used in today's industrial 904 and other industries; DetNet is intended to provide an open- 905 standards-based alternative to such buses. Does the threat relate to 906 a specific fieldbus that is being "emulated" or "replaced" by DetNet, 907 for example by exploiting specific commands specific to that network 908 protocol? 910 6.1.9. Deterministic vs Best-Effort Traffic 912 DetNet is intended to support coexistence of time-sensitive 913 operational (OT, deterministic) traffic and information (IT, "best 914 effort") traffic on the same ("unified") network. Does the attack 915 affect only IT or only OT or both types of traffic? Does the threat 916 affect any interaction between IT and OT traffic, e.g. by changing 917 relative priority or handling of IT vs. OT packets? 919 6.1.10. Deterministic Flows 921 Reserved bandwidth data flows (deterministic flows) must be isolated 922 from each other and from best-effort traffic, so that even if the 923 network is saturated with best-effort and/or reserved bandwidth 924 traffic the configured flows are not adversely affected. Does the 925 attack affect the isolation of one (reserved) flow from another? 927 6.1.11. Unused Reserved Bandwidth 929 If bandwidth reservations are made for a stream but the associated 930 bandwidth is not used at any point in time, that bandwidth is made 931 available on the network for best-effort traffic. If the owner of 932 the reserved stream then starts transmitting again, the bandwidth is 933 no longer available for best-effort traffic, on a moment-to-moment 934 basis. (Such "temporarily available" bandwidth is not available for 935 time-sensitive traffic, which must have its own reservation). Does 936 the attack affect the system's ability to allocate unused reserved BW 937 to best-effort traffic? 939 6.1.12. Interoperability 941 The DetNet network specifications are intended to enable an ecosystem 942 in which multiple vendors can create interoperable products, thus 943 promoting device diversity and potentially higher numbers of each 944 device manufactured. Does the threat take advantage of differences 945 in implementation of "interoperable" products made by different 946 vendors? 948 6.1.13. Cost Reductions 950 The DetNet network specifications are intended to enable an ecosystem 951 in which multiple vendors can create interoperable products, thus 952 promoting higher numbers of each device manufactured, promoting cost 953 reduction and cost competition among vendors. Does the threat take 954 advantage of "low cost" HW or SW components or other "cost-related 955 shortcuts" that might be present in devices? 957 6.1.14. Insufficiently Secure Devices 959 The DetNet network specifications are intended to enable an ecosystem 960 in which multiple vendors can create interoperable products, thus 961 promoting device diversity and potentially higher numbers of each 962 device manufactured. Does the threat attack "naivete" of SW, for 963 example SW that was not designed to be sufficiently secure (or secure 964 at all) but is deployed on a DetNet network that is intended to be 965 highly secure? (For example IoT exploits like the Mirai video-camera 966 botnet ([MIRAI]). 968 6.1.15. DetNet Network Size 970 DetNet networks range in size from very small, e.g. inside a single 971 industrial machine, to very large, for example a Utility Grid network 972 spanning a whole country, and involving many "hops" over various 973 kinds of links for example radio repeaters, microwave links, fiber 974 optic links, etc.. Does the attack affect DetNet networks of only 975 certain sizes, e.g. very large networks, or very small? This might 976 be related to how the attack is introduced into the network, for 977 example if the entire network is local, there is a threat that power 978 can be cut to the entire network. If the network is large, perhaps 979 only a part of the network is attacked. Does the threat take 980 advantage of attack vectors that are specific to network size? 982 6.1.16. Multiple Hops 984 DetNet networks range in size from very small, e.g. inside a single 985 industrial machine, to very large, for example a Utility Grid network 986 spanning a whole country, and involving many "hops" over various 987 kinds of links for example radio repeaters, microwave links, fiber 988 optic links, etc.. Does the attack exploit the presence of more than 989 one "hop"? Does the threat exploit the presence of more than one 990 type of "hop", e.g. between radio and microwave links? Does the 991 threat exploit a specific type of "hop", e.g. something specific to 992 a fiber optic link, or other type of link? 994 6.1.17. Level of Service 996 A DetNet is expected to provide means to configure the network that 997 include querying network path latency, requesting bounded latency for 998 a given stream, requesting worst case maximum and/or minimum latency 999 for a given path or stream, and so on. It is an expected case that 1000 the network cannot provide a given requested service level. In such 1001 cases the network control system should reply that the requested 1002 service level is not available (as opposed to accepting the parameter 1003 but then not delivering the desired behavior). Does the attack 1004 affect any querying or replying to such service-level-related 1005 traffic? Can the attack cause incorrect responses from the system 1006 regarding timing-related configuration? For example replying that a 1007 requested level of service is available when it isn't, or that the 1008 requested level of service is not available when it actually is 1009 available? 1011 6.1.18. Bounded Latency 1013 Does the threat affect the network's ability to deliver packets 1014 within the agreed-upon latency boundaries? 1016 6.1.19. Low Latency 1018 Applications may require "extremely low latency" however depending on 1019 the application these may mean very different latency values; for 1020 example "low latency" across a Utility grid network is on a different 1021 time scale than "low latency" in a motor control loop in a small 1022 machine. The intent is that the mechanisms for specifying desired 1023 latency include wide ranges, and that architecturally there is 1024 nothing to prevent arbitrarily low latencies from being implemented 1025 in a given network. Does the threat affect the network's ability to 1026 deliver packets within the agreed-upon low latency? 1028 6.1.20. Symmetrical Path Delays 1030 Some applications would like to specify that the transit delay time 1031 values be equal for both the transmit and return paths. Does the 1032 attack affect the network's ability to provide matched transmit and 1033 return path delays (latencies)? 1035 6.1.21. Reliability and Availability 1037 DetNet based systems are expected to be implemented with essentially 1038 arbitrarily high availability (for example 99.9999% up time, or even 1039 12 nines). The intent is that the DetNet designs should not make any 1040 assumptions about the level of reliability and availability that may 1041 be required of a given system, and should define parameters for 1042 communicating these kinds of metrics within the network. Does the 1043 attack affect the reliability of the DetNet network? Is it a large 1044 or small change, e.g. the difference between completely taking down 1045 the network for some period of time, vs reducing its reliability by 1046 just one "nine"? Does the threat affect the availability of the 1047 DetNet network? 1049 6.1.22. Redundant Paths 1051 DetNet based systems are expected to be implemented with essentially 1052 arbitrarily high reliability/availability. A strategy used by DetNet 1053 for providing such extraordinarily high levels of reliability is to 1054 provide redundant paths that can be seamlessly switched between, all 1055 the while maintaining the required performance of that system. Does 1056 the attack affect the configuration or operation of redundant paths? 1058 6.1.23. Security Measures 1060 A DetNet network must be made secure against devices failures, 1061 attackers, misbehaving devices, and so on. Does the threat affect 1062 such security measures themselves, e.g. by attacking SW designed to 1063 protect against device failure? 1065 6.2. Attack Types by Use Case Common Theme 1067 The following table lists the attacks of Section 3, assigning a 1068 number to each type of attack. That number is then used as a short 1069 form identifier for the attack in Figure 5. 1071 +--+----------------------------------------+----------------------+ 1072 | | Attack | Section | 1073 +--+----------------------------------------+----------------------+ 1074 | 1|Delay Attack | Section 3.2.1 | 1075 +--+----------------------------------------+----------------------+ 1076 | 2|DetNet Flow Modification or Spoofing | Section 3.2.2 | 1077 +--+----------------------------------------+----------------------+ 1078 | 3|Inter-Segment Attack | Section 3.2.3 | 1079 +--+----------------------------------------+----------------------+ 1080 | 4|Replication: Increased attack surface | Section 3.2.4.1 | 1081 +--+----------------------------------------+----------------------+ 1082 | 5|Replication-related Header Manipulation | Section 3.2.4.2 | 1083 +--+----------------------------------------+----------------------+ 1084 | 6|Path Manipulation | Section 3.2.5.1 | 1085 +--+----------------------------------------+----------------------+ 1086 | 7|Path Choice: Increased Attack Surface | Section 3.2.5.2 | 1087 +--+----------------------------------------+----------------------+ 1088 | 8|Control or Signaling Packet Modification| Section 3.2.6.1 | 1089 +--+----------------------------------------+----------------------+ 1090 | 9|Control or Signaling Packet Injection | Section 3.2.6.2 | 1091 +--+----------------------------------------+----------------------+ 1092 |10|Reconnaissance | Section 3.2.7 | 1093 +--+----------------------------------------+----------------------+ 1094 |11|Attacks on Time Sync Mechanisms | Section 3.2.8 | 1095 +--+----------------------------------------+----------------------+ 1097 Figure 4: List of Attacks 1099 The following table maps the use case themes presented in this memo 1100 to the attacks of Figure 4. Each row specifies a theme, and the 1101 attacks relevant to this theme are marked with a '+'. 1103 +----------------------------+--------------------------------+ 1104 | Theme | Attack | 1105 | +--+--+--+--+--+--+--+--+--+--+--+ 1106 | | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11| 1107 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1108 |Network Layer - AVB/TSN Eth.| +| +| +| +| +| +| +| +| +| +| +| 1109 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1110 |Central Administration | | | | | | +| +| +| +| +| +| 1111 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1112 |Hot Swap | | +| +| | | | | | | | +| 1113 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1114 |Data Flow Information Models| | | | | | | | | | | | 1115 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1116 |L2 and L3 Integration | | | | | +| +| | | | | | 1117 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1118 |End-to-end Delivery | | | | +| +| | | | | | | 1119 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1120 |Proprietary Deterministic | | | +| | | +| +| +| +| | | 1121 |Ethernet Networks | | | | | | | | | | | | 1122 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1123 |Replacement for Proprietary | | | +| | | +| +| +| +| | | 1124 |Fieldbuses | | | | | | | | | | | | 1125 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1126 |Deterministic vs. Best- | | | +| | | | | | | | | 1127 |Effort Traffic | | | | | | | | | | | | 1128 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1129 |Deterministic Flows | | | +| | | | | | | | | 1130 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1131 |Unused Reserved Bandwidth | | | +| | | | | | | | | 1132 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1133 |Interoperability | | | | | | | | | | | | 1134 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1135 |Cost Reductions | | | | | | | | | | | | 1136 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1137 |Insufficiently Secure | | | | | | | | | | | | 1138 |Devices | | | | | | | | | | | | 1139 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1140 |DetNet Network Size | +| | | | | +| +| | | | +| 1141 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1142 |Multiple Hops | +| +| | | | +| +| | | | +| 1143 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1144 |Level of Service | | | | | | | | +| +| +| | 1145 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1146 |Bounded Latency | +| | | | | | | | | | +| 1147 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1148 |Low Latency | +| | | | | | | | | | +| 1149 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1150 |Symmetric Path Delays | +| | | | | | | | | | +| 1151 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1152 |Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +| 1153 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1154 |Redundant Paths | | | | +| +| | | +| +| | | 1155 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1156 |Security Measures | | | | | | | | | | | | 1157 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 1159 Figure 5: Mapping Between Themes and Attacks 1161 7. Appendix A: DetNet Draft Security-Related Statements 1163 This section collects the various statements in the currently 1164 existing DetNet Working Group drafts. For each draft, the section 1165 name and number of the quoted section is shown. The text shown here 1166 is the work of the original draft authors, quoted verbatim from the 1167 drafts. The intention is to explicitly quote all relevant text, not 1168 to summarize it. 1170 7.1. Architecture (draft 8) 1172 7.1.1. Fault Mitigation (sec 4.5) 1174 One key to building robust real-time systems is to reduce the 1175 infinite variety of possible failures to a number that can be 1176 analyzed with reasonable confidence. DetNet aids in the process by 1177 providing filters and policers to detect DetNet packets received on 1178 the wrong interface, or at the wrong time, or in too great a volume, 1179 and to then take actions such as discarding the offending packet, 1180 shutting down the offending DetNet flow, or shutting down the 1181 offending interface. 1183 It is also essential that filters and service remarking be employed 1184 at the network edge to prevent non-DetNet packets from being mistaken 1185 for DetNet packets, and thus impinging on the resources allocated to 1186 DetNet packets. 1188 There exist techniques, at present and/or in various stages of 1189 standardization, that can perform these fault mitigation tasks that 1190 deliver a high probability that misbehaving systems will have zero 1191 impact on well-behaved DetNet flows, except of course, for the 1192 receiving interface(s) immediately downstream of the misbehaving 1193 device. Examples of such techniques include traffic policing 1194 functions (e.g. [RFC2475]) and separating flows into per-flow rate- 1195 limited queues. 1197 7.1.2. Security Considerations (sec 7) 1199 Security in the context of Deterministic Networking has an added 1200 dimension; the time of delivery of a packet can be just as important 1201 as the contents of the packet, itself. A man-in-the-middle attack, 1202 for example, can impose, and then systematically adjust, additional 1203 delays into a link, and thus disrupt or subvert a real-time 1204 application without having to crack any encryption methods employed. 1205 See [RFC7384] for an exploration of this issue in a related context. 1207 Furthermore, in a control system where millions of dollars of 1208 equipment, or even human lives, can be lost if the DetNet QoS is not 1209 delivered, one must consider not only simple equipment failures, 1210 where the box or wire instantly becomes perfectly silent, but bizarre 1211 errors such as can be caused by software failures. Because there is 1212 essential no limit to the kinds of failures that can occur, 1213 protecting against realistic equipment failures is indistinguishable, 1214 in most cases, from protecting against malicious behavior, whether 1215 accidental or intentional. 1217 Security must cover: 1219 o Protection of the signaling protocol 1221 o Authentication and authorization of the controlling nodes 1223 o Identification and shaping of the flows 1225 7.2. Data Plane Alternatives (draft 4) 1227 7.2.1. Security Considerations (sec 7) 1229 This document does not add any new security considerations beyond 1230 what the referenced technologies already have. 1232 7.3. Problem Statement (draft 5) 1234 7.3.1. Security Considerations (sec 5) 1236 Security in the context of Deterministic Networking has an added 1237 dimension; the time of delivery of a packet can be just as important 1238 as the contents of the packet, itself. A man-in-the-middle attack, 1239 for example, can impose, and then systematically adjust, additional 1240 delays into a link, and thus disrupt or subvert a real-time 1241 application without having to crack any encryption methods employed. 1242 See [RFC7384] for an exploration of this issue in a related context. 1244 Typical control networks today rely on complete physical isolation to 1245 prevent rogue access to network resources. DetNet enables the 1246 virtualization of those networks over a converged IT/OT 1247 infrastructure. Doing so, DetNet introduces an additional risk that 1248 flows interact and interfere with one another as they share physical 1249 resources such as Ethernet trunks and radio spectrum. The 1250 requirement is that there is no possible data leak from and into a 1251 deterministic flow, and in a more general fashion there is no 1252 possible influence whatsoever from the outside on a deterministic 1253 flow. The expectation is that physical resources are effectively 1254 associated with a given flow at a given point of time. In that 1255 model, Time Sharing of physical resources becomes transparent to the 1256 individual flows which have no clue whether the resources are used by 1257 other flows at other times. 1259 Security must cover: 1261 o Protection of the signaling protocol 1262 o Authentication and authorization of the controlling nodes 1264 o Identification and shaping of the flows 1266 o Isolation of flows from leakage and other influences from any 1267 activity sharing physical resources 1269 7.4. Use Cases (draft 11) 1271 7.4.1. (Utility Networks) Security Current Practices and Limitations 1272 (sec 3.2.1) 1274 Grid monitoring and control devices are already targets for cyber 1275 attacks, and legacy telecommunications protocols have many intrinsic 1276 network-related vulnerabilities. For example, DNP3, Modbus, 1277 PROFIBUS/PROFINET, and other protocols are designed around a common 1278 paradigm of request and respond. Each protocol is designed for a 1279 master device such as an HMI (Human Machine Interface) system to send 1280 commands to subordinate slave devices to retrieve data (reading 1281 inputs) or control (writing to outputs). Because many of these 1282 protocols lack authentication, encryption, or other basic security 1283 measures, they are prone to network-based attacks, allowing a 1284 malicious actor or attacker to utilize the request-and-respond system 1285 as a mechanism for command-and-control like functionality. Specific 1286 security concerns common to most industrial control, including 1287 utility telecommunication protocols include the following: 1289 o Network or transport errors (e.g. malformed packets or excessive 1290 latency) can cause protocol failure. 1292 o Protocol commands may be available that are capable of forcing 1293 slave devices into inoperable states, including powering-off 1294 devices, forcing them into a listen-only state, disabling 1295 alarming. 1297 o Protocol commands may be available that are capable of restarting 1298 communications and otherwise interrupting processes. 1300 o Protocol commands may be available that are capable of clearing, 1301 erasing, or resetting diagnostic information such as counters and 1302 diagnostic registers. 1304 o Protocol commands may be available that are capable of requesting 1305 sensitive information about the controllers, their configurations, 1306 or other need-to-know information. 1308 o Most protocols are application layer protocols transported over 1309 TCP; therefore it is easy to transport commands over non-standard 1310 ports or inject commands into authorized traffic flows. 1312 o Protocol commands may be available that are capable of 1313 broadcasting messages to many devices at once (i.e. a potential 1314 DoS). 1316 o Protocol commands may be available to query the device network to 1317 obtain defined points and their values (i.e. a configuration 1318 scan). 1320 o Protocol commands may be available that will list all available 1321 function codes (i.e. a function scan). 1323 o These inherent vulnerabilities, along with increasing connectivity 1324 between IT an OT networks, make network-based attacks very 1325 feasible. 1327 o Simple injection of malicious protocol commands provides control 1328 over the target process. Altering legitimate protocol traffic can 1329 also alter information about a process and disrupt the legitimate 1330 controls that are in place over that process. A man-in-the-middle 1331 attack could provide both control over a process and 1332 misrepresentation of data back to operator consoles. 1334 7.4.2. (Utility Networks) Security Trends in Utility Networks (sec 1335 3.3.3) 1337 Although advanced telecommunications networks can assist in 1338 transforming the energy industry by playing a critical role in 1339 maintaining high levels of reliability, performance, and 1340 manageability, they also introduce the need for an integrated 1341 security infrastructure. Many of the technologies being deployed to 1342 support smart grid projects such as smart meters and sensors can 1343 increase the vulnerability of the grid to attack. Top security 1344 concerns for utilities migrating to an intelligent smart grid 1345 telecommunications platform center on the following trends: 1347 o Integration of distributed energy resources 1349 o Proliferation of digital devices to enable management, automation, 1350 protection, and control 1352 o Regulatory mandates to comply with standards for critical 1353 infrastructure protection 1355 o Migration to new systems for outage management, distribution 1356 automation, condition-based maintenance, load forecasting, and 1357 smart metering 1359 o Demand for new levels of customer service and energy management 1361 This development of a diverse set of networks to support the 1362 integration of microgrids, open-access energy competition, and the 1363 use of network-controlled devices is driving the need for a converged 1364 security infrastructure for all participants in the smart grid, 1365 including utilities, energy service providers, large commercial and 1366 industrial, as well as residential customers. Securing the assets of 1367 electric power delivery systems (from the control center to the 1368 substation, to the feeders and down to customer meters) requires an 1369 end-to-end security infrastructure that protects the myriad of 1370 telecommunications assets used to operate, monitor, and control power 1371 flow and measurement. 1373 "Cyber security" refers to all the security issues in automation and 1374 telecommunications that affect any functions related to the operation 1375 of the electric power systems. Specifically, it involves the 1376 concepts of: 1378 o Integrity : data cannot be altered undetectably 1380 o Authenticity : the telecommunications parties involved must be 1381 validated as genuine 1383 o Authorization : only requests and commands from the authorized 1384 users can be accepted by the system 1386 o Confidentiality : data must not be accessible to any 1387 unauthenticated users 1389 When designing and deploying new smart grid devices and 1390 telecommunications systems, it is imperative to understand the 1391 various impacts of these new components under a variety of attack 1392 situations on the power grid. Consequences of a cyber attack on the 1393 grid telecommunications network can be catastrophic. This is why 1394 security for smart grid is not just an ad hoc feature or product, 1395 it's a complete framework integrating both physical and Cyber 1396 security requirements and covering the entire smart grid networks 1397 from generation to distribution. Security has therefore become one 1398 of the main foundations of the utility telecom network architecture 1399 and must be considered at every layer with a defense-in-depth 1400 approach. Migrating to IP based protocols is key to address these 1401 challenges for two reasons: 1403 o IP enables a rich set of features and capabilities to enhance the 1404 security posture 1406 o IP is based on open standards, which allows interoperability 1407 between different vendors and products, driving down the costs 1408 associated with implementing security solutions in OT networks. 1410 Securing OT (Operation technology) telecommunications over packet- 1411 switched IP networks follow the same principles that are foundational 1412 for securing the IT infrastructure, i.e., consideration must be given 1413 to enforcing electronic access control for both person-to-machine and 1414 machine-to-machine communications, and providing the appropriate 1415 levels of data privacy, device and platform integrity, and threat 1416 detection and mitigation. 1418 7.4.3. (BAS) Security Considerations (sec 4.2.4) 1420 When BAS field networks were developed it was assumed that the field 1421 networks would always be physically isolated from external networks 1422 and therefore security was not a concern. In today's world many BASs 1423 are managed remotely and are thus connected to shared IP networks and 1424 so security is definitely a concern, yet security features are not 1425 available in the majority of BAS field network deployments . 1427 The management network, being an IP-based network, has the protocols 1428 available to enable network security, but in practice many BAS 1429 systems do not implement even the available security features such as 1430 device authentication or encryption for data in transit. 1432 7.4.4. (6TiSCH) Security Considerations (sec 5.3.3) 1434 On top of the classical requirements for protection of control 1435 signaling, it must be noted that 6TiSCH networks operate on limited 1436 resources that can be depleted rapidly in a DoS attack on the system, 1437 for instance by placing a rogue device in the network, or by 1438 obtaining management control and setting up unexpected additional 1439 paths. 1441 7.4.5. (Cellular radio) Security Considerations (sec 6.1.5) 1443 Establishing time-sensitive streams in the network entails reserving 1444 networking resources for long periods of time. It is important that 1445 these reservation requests be authenticated to prevent malicious 1446 reservation attempts from hostile nodes (or accidental 1447 misconfiguration). This is particularly important in the case where 1448 the reservation requests span administrative domains. Furthermore, 1449 the reservation information itself should be digitally signed to 1450 reduce the risk of a legitimate node pushing a stale or hostile 1451 configuration into another networking node. 1453 Note: This is considered important for the security policy of the 1454 network, but does not affect the core DetNet architecture and design. 1456 7.4.6. (Industrial M2M) Communication Today (sec 7.2) 1458 Industrial network scenarios require advanced security solutions. 1459 Many of the current industrial production networks are physically 1460 separated. Preventing critical flows from be leaked outside a domain 1461 is handled today by filtering policies that are typically enforced in 1462 firewalls. 1464 8. IANA Considerations 1466 This memo includes no requests from IANA. 1468 9. Security Considerations 1470 The security considerations of DetNet networks are presented 1471 throughout this document. 1473 10. Informative References 1475 [ARINC664P7] 1476 ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics 1477 Full-Duplex Switched Ethernet Network", 2009. 1479 [I-D.ietf-detnet-architecture] 1480 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1481 "Deterministic Networking Architecture", draft-ietf- 1482 detnet-architecture-03 (work in progress), August 2017. 1484 [I-D.ietf-detnet-use-cases] 1485 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 1486 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 1487 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 1488 X., Mahmoodi, T., Spirou, S., and P. Vizarreta, 1489 "Deterministic Networking Use Cases", draft-ietf-detnet- 1490 use-cases-12 (work in progress), April 2017. 1492 [I-D.varga-detnet-service-model] 1493 Varga, B. and J. Farkas, "DetNet Service Model", draft- 1494 varga-detnet-service-model-02 (work in progress), May 1495 2017. 1497 [IEEE1588] 1498 IEEE, "IEEE 1588 Standard for a Precision Clock 1499 Synchronization Protocol for Networked Measurement and 1500 Control Systems Version 2", 2008. 1502 [MIRAI] krebsonsecurity.com, "https://krebsonsecurity.com/2016/10/ 1503 hacked-cameras-dvrs-powered-todays-massive-internet- 1504 outage/", 2016. 1506 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1507 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1508 October 2014, . 1510 Authors' Addresses 1512 Tal Mizrahi 1513 Marvell 1515 Email: talmi@marvell.com 1517 Ethan Grossman (editor) 1518 Dolby Laboratories, Inc. 1519 1275 Market Street 1520 San Francisco, CA 94103 1521 USA 1523 Phone: +1 415 645 4726 1524 Email: ethan.grossman@dolby.com 1525 URI: http://www.dolby.com 1527 Andrew J. Hacker 1528 MistIQ Technologies, Inc 1529 Harrisburg, PA 1530 USA 1532 Email: ajhacker@mistiqtech.com 1533 URI: http://www.mistiqtech.com 1535 Subir Das 1536 Applied Communication Sciences 1537 150 Mount Airy Road, Basking Ridge 1538 New Jersey, 07920 1539 USA 1541 Email: sdas@appcomsci.com 1542 John Dowdell 1543 Airbus Defence and Space 1544 Celtic Springs 1545 Newport NP10 8FZ 1546 United Kingdom 1548 Email: john.dowdell.ietf@gmail.com 1550 Henrik Austad 1551 Cisco Systems 1552 Philip Pedersens vei 1 1553 Lysaker 1366 1554 Norway 1556 Email: henrik@austad.us 1558 Kevin Stanton 1559 Intel 1561 Email: kevin.b.stanton@intel.com 1563 Norman Finn 1564 Huawei 1566 Email: norman.finn@mail01.huawei.com