idnits 2.17.1 draft-ietf-detnet-security-15.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-detnet-ip-oam-01 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-05 == Outdated reference: A later version (-15) exists of draft-ietf-detnet-mpls-oam-02 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-09 == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-g-ikev2-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Grossman, Ed. 3 Internet-Draft DOLBY 4 Intended status: Informational T. Mizrahi 5 Expires: August 26, 2021 HUAWEI 6 A. Hacker 7 MISTIQ 8 February 22, 2021 10 Deterministic Networking (DetNet) Security Considerations 11 draft-ietf-detnet-security-15 13 Abstract 15 A DetNet (deterministic network) provides specific performance 16 guarantees to its data flows, such as extremely low data loss rates 17 and bounded latency (including bounded latency variation, i.e. 18 "jitter"). As a result, securing a DetNet requires that in addition 19 to the best practice security measures taken for any mission-critical 20 network, additional security measures may be needed to secure the 21 intended operation of these novel service properties. 23 This document addresses DetNet-specific security considerations from 24 the perspectives of both the DetNet system-level designer and 25 component designer. System considerations include a taxonomy of 26 relevant threats and attacks, and associations of threats versus use 27 cases and service properties. Component-level considerations include 28 ingress filtering and packet arrival time violation detection. 30 This document also addresses security considerations specific to the 31 IP and MPLS data plane technologies, thereby complementing the 32 Security Considerations sections of those documents. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 26, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 7 69 3. Security Considerations for DetNet Component Design . . . . . 8 70 3.1. Resource Allocation . . . . . . . . . . . . . . . . . . . 8 71 3.1.1. Inviolable Flows . . . . . . . . . . . . . . . . . . 8 72 3.1.2. Design Trade-Off Considerations in the Use Cases 73 Continuum . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.3. Documenting the Security Properties of a Component . 10 75 3.1.4. Fail-Safe Component Behavior . . . . . . . . . . . . 10 76 3.1.5. Flow Aggregation Example . . . . . . . . . . . . . . 10 77 3.2. Explicit Routes . . . . . . . . . . . . . . . . . . . . . 11 78 3.3. Redundant Path Support . . . . . . . . . . . . . . . . . 11 79 3.4. Timing (or other) Violation Reporting . . . . . . . . . . 12 80 4. DetNet Security Considerations Compared With DiffServ 81 Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 5. Security Threats . . . . . . . . . . . . . . . . . . . . . . 14 83 5.1. Threat Taxonomy . . . . . . . . . . . . . . . . . . . . . 15 84 5.2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 16 85 5.2.1. Delay . . . . . . . . . . . . . . . . . . . . . . . . 16 86 5.2.2. DetNet Flow Modification or Spoofing . . . . . . . . 16 87 5.2.3. Resource Segmentation (Inter-segment Attack) 88 Vulnerability . . . . . . . . . . . . . . . . . . . . 16 89 5.2.4. Packet Replication and Elimination . . . . . . . . . 17 90 5.2.4.1. Replication: Increased Attack Surface . . . . . . 17 91 5.2.4.2. Replication-related Header Manipulation . . . . . 17 92 5.2.5. Controller Plane . . . . . . . . . . . . . . . . . . 18 93 5.2.5.1. Path Choice Manipulation . . . . . . . . . . . . 18 94 5.2.5.2. Compromised Controller . . . . . . . . . . . . . 18 95 5.2.6. Reconnaissance . . . . . . . . . . . . . . . . . . . 19 96 5.2.7. Time Synchronization Mechanisms . . . . . . . . . . . 19 97 5.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 19 98 6. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 20 99 6.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 23 100 6.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 23 101 6.1.2. Controller Plane Delay Attacks . . . . . . . . . . . 23 102 6.2. Flow Modification and Spoofing . . . . . . . . . . . . . 23 103 6.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 24 104 6.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 24 105 6.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 24 106 6.2.2.2. Controller Plane Spoofing . . . . . . . . . . . . 24 107 6.3. Segmentation Attacks (injection) . . . . . . . . . . . . 24 108 6.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 25 109 6.3.2. Controller Plane Segmentation . . . . . . . . . . . . 25 110 6.4. Replication and Elimination . . . . . . . . . . . . . . . 25 111 6.4.1. Increased Attack Surface . . . . . . . . . . . . . . 26 112 6.4.2. Header Manipulation at Elimination Routers . . . . . 26 113 6.5. Control or Signaling Packet Modification . . . . . . . . 26 114 6.6. Control or Signaling Packet Injection . . . . . . . . . . 26 115 6.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 26 116 6.8. Attacks on Time Synchronization Mechanisms . . . . . . . 27 117 6.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 27 118 7. Security Threat Mitigation . . . . . . . . . . . . . . . . . 27 119 7.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 27 120 7.2. Integrity Protection . . . . . . . . . . . . . . . . . . 28 121 7.3. DetNet Node Authentication . . . . . . . . . . . . . . . 29 122 7.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 30 123 7.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 31 124 7.5.1. Encryption Considerations for DetNet . . . . . . . . 32 125 7.6. Control and Signaling Message Protection . . . . . . . . 33 126 7.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 33 127 7.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 36 128 8. Association of Attacks to Use Cases . . . . . . . . . . . . . 37 129 8.1. Association of Attacks to Use Case Common Themes . . . . 38 130 8.1.1. Sub-Network Layer . . . . . . . . . . . . . . . . . . 38 131 8.1.2. Central Administration . . . . . . . . . . . . . . . 38 132 8.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 38 133 8.1.4. Data Flow Information Models . . . . . . . . . . . . 39 134 8.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 39 135 8.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 40 136 8.1.7. Replacement for Proprietary Fieldbuses and Ethernet- 137 based Networks . . . . . . . . . . . . . . . . . . . 40 138 8.1.8. Deterministic vs Best-Effort Traffic . . . . . . . . 41 139 8.1.9. Deterministic Flows . . . . . . . . . . . . . . . . . 42 140 8.1.10. Unused Reserved Bandwidth . . . . . . . . . . . . . . 42 141 8.1.11. Interoperability . . . . . . . . . . . . . . . . . . 42 142 8.1.12. Cost Reductions . . . . . . . . . . . . . . . . . . . 43 143 8.1.13. Insufficiently Secure Components . . . . . . . . . . 43 144 8.1.14. DetNet Network Size . . . . . . . . . . . . . . . . . 43 145 8.1.15. Multiple Hops . . . . . . . . . . . . . . . . . . . . 44 146 8.1.16. Level of Service . . . . . . . . . . . . . . . . . . 44 147 8.1.17. Bounded Latency . . . . . . . . . . . . . . . . . . . 45 148 8.1.18. Low Latency . . . . . . . . . . . . . . . . . . . . . 45 149 8.1.19. Bounded Jitter (Latency Variation) . . . . . . . . . 45 150 8.1.20. Symmetrical Path Delays . . . . . . . . . . . . . . . 45 151 8.1.21. Reliability and Availability . . . . . . . . . . . . 46 152 8.1.22. Redundant Paths . . . . . . . . . . . . . . . . . . . 46 153 8.1.23. Security Measures . . . . . . . . . . . . . . . . . . 46 154 8.2. Summary of Attack Types per Use Case Common Theme . . . . 47 155 8.3. Security Considerations for OAM Traffic . . . . . . . . . 49 156 9. DetNet Technology-Specific Threats . . . . . . . . . . . . . 49 157 9.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 158 9.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 51 159 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 160 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 161 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 52 162 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 163 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 164 14.1. Normative References . . . . . . . . . . . . . . . . . . 53 165 14.2. Informative References . . . . . . . . . . . . . . . . . 54 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 168 1. Introduction 170 A deterministic IP network (IETF DetNet, [RFC8655]) can carry data 171 flows for real-time applications with extremely low data loss rates 172 and bounded latency. The bounds on latency defined by DetNet (as 173 described in [I-D.ietf-detnet-flow-information-model]) include both 174 worst case latency (Maximum Latency, Section 5.9.2) and worst case 175 jitter (Maximum Latency Variation, Section 5.9.3). Data flows with 176 deterministic properties are well-established for Ethernet networks 177 (see TSN, [IEEE802.1BA]); DetNet brings these capabilities to the IP 178 network. 180 Deterministic IP networks have been successfully deployed in real- 181 time Operational Technology (OT) applications for some years, however 182 such networks are typically isolated from external access, and thus 183 the security threat from external attackers is low. An example of 184 such an isolated network is a network deployed within an aircraft, 185 which is "air gapped" from the outside world. DetNet specifies a set 186 of technologies that enable creation of deterministic flows on IP- 187 based networks of potentially wide area (on the scale of a corporate 188 network), potentially merging OT traffic with best-effort 189 (Information Technology, IT) traffic, and placing OT network 190 components into contact with IT network components, thereby exposing 191 the OT traffic and components to security threats that were not 192 present in an isolated OT network. 194 These DetNet (OT-type) technologies may not have previously been 195 deployed on a wide area IP-based network that also carries IT 196 traffic, and thus can present security considerations that may be new 197 to IP-based wide area network designers; this document provides 198 insight into such system-level security considerations. In addition, 199 designers of DetNet components (such as routers) face new security- 200 related challenges in providing DetNet services, for example 201 maintaining reliable isolation between traffic flows in an 202 environment where IT traffic co-mingles with critical reserved- 203 bandwidth OT traffic; this document also examines security 204 implications internal to DetNet components. 206 Security is of particularly high importance in DetNet because many of 207 the use cases which are enabled by DetNet [RFC8578] include control 208 of physical devices (power grid devices, industrial controls, 209 building controls) which can have high operational costs for failure, 210 and present potentially attractive targets for cyber-attackers. 212 This situation is even more acute given that one of the goals of 213 DetNet is to provide a "converged network", i.e. one that includes 214 both IT traffic and OT traffic, thus exposing potentially sensitive 215 OT devices to attack in ways that were not previously common (usually 216 because they were under a separate control system or otherwise 217 isolated from the IT network, for example [ARINC664P7]). Security 218 considerations for OT networks are not a new area, and there are many 219 OT networks today that are connected to wide area networks or the 220 Internet; this document focuses on the issues that are specific to 221 the DetNet technologies and use cases. 223 Given the above considerations, securing a DetNet starts with a 224 scrupulously well-designed and well-managed engineered network 225 following industry best practices for security at both the data plane 226 and controller plane, as well as for any OAM implementation; this is 227 the assumed starting point for the considerations discussed herein. 228 Such assumptions also depend on the network components themselves 229 upholding the security-related properties that are to be assumed by 230 DetNet system-level designers; for example, the assumption that 231 network traffic associated with a given flow can never affect traffic 232 associated with a different flow is only true if the underlying 233 components make it so. Such properties, which may represent new 234 challenges to component designers, are also considered herein. 236 Starting with a "well-managed network" as noted above enables us to 237 exclude some of the more powerful adversary capabilities from the 238 Internet Threat Model of BCP 72 ([RFC3552]), such as the ability to 239 arbitrarily drop or delay any or all traffic. Given this reduced 240 attacker capability, we can present security considerations based on 241 attacker capabilities that are more directly relevant to a DetNet. 243 In this context we view the "traditional" (i.e. non-time-sensitive) 244 network design and management aspects of network security as being 245 primarily concerned with denial-of service prevention, i.e. they must 246 ensure that DetNet traffic goes where it's supposed to and that an 247 external attacker can't inject traffic that disrupts the delivery 248 timing assurance of the DetNet. The time-specific aspects of DetNet 249 security presented here take up where those "traditional" design and 250 management aspects leave off. 252 However note that "traditional" methods for mitigating (among all the 253 others) denial-of service attack (such as throttling) can only be 254 effectively used in a DetNet when their use does not compromise the 255 required time-sensitive or behavioral properties required for the OT 256 flows on the network. For example, a "retry" protocol is typically 257 not going to be compatible with a low-latency (worst-case maximum 258 latency) requirement, however if in a specific use case and 259 implementation such a retry protocol is able to meet the timing 260 constraints, then it may well be used in that context. Similarly if 261 common security protocols such as TLS/DTLS or IPsec are to be used, 262 it must be verified that their implementations are able to meet the 263 timing and behavioral requirements of the time-sensitive network as 264 implemented for the given use case. An example of "behavioral 265 properties" might be that dropping of more than a specific number of 266 packets in a row is not acceptable according to the service level 267 agreement. 269 The exact security requirements for any given DetNet are necessarily 270 specific to the use cases handled by that network. Thus the reader 271 is assumed to be familiar with the specific security requirements of 272 their use cases, for example those outlined in the DetNet Use Cases 273 [RFC8578] and the Security Considerations sections of the DetNet 274 documents applicable to the network technologies in use, for example 275 [RFC8939]). Readers can find a general introduction to the DetNet 276 Architecture in [RFC8655], the DetNet Data Plane in [RFC8938], and 277 the Flow Information Model in 278 [I-D.ietf-detnet-flow-information-model]. 280 The DetNet technologies include ways to: 282 o Assign data plane resources for DetNet flows in some or all of the 283 intermediate nodes (routers) along the path of the flow 285 o Provide explicit routes for DetNet flows that do not dynamically 286 change with the network topology in ways that affect the quality 287 of service received by the affected flow(s) 289 o Distribute data from DetNet flow packets over time and/or space to 290 ensure delivery of the data in each packet in spite of the loss of 291 a path. 293 This document includes sections considering DetNet component design 294 as well as system design. The latter includes a taxonomy and 295 analysis of threats, threat impacts and mitigations, and an 296 association of attacks with use cases (based on the Use Case Common 297 Themes section of the DetNet Use Cases [RFC8578]). 299 This document is based on the premise that there will be a very broad 300 range of DetNet applications and use cases, ranging in size scope 301 from individual industrial machines to networks that span an entire 302 country ([RFC8578]). Thus no single set of prescriptions (such as 303 exactly which mitigation should be applied to which segment of a 304 DetNet) can be applicable to all of them, and indeed any single one 305 that we might prescribe would inevitably prove impractical for some 306 use case, perhaps one that does not even exist at the time of this 307 writing. Thus we are not prescriptive here - we are stating the 308 desired end result, with the understanding that most DetNet use cases 309 will necessarily differ from each other, and there is no "one size 310 fits all". 312 2. Abbreviations and Terminology 314 IT: Information Technology (the application of computers to store, 315 study, retrieve, transmit, and manipulate data or information, often 316 in the context of a business or other enterprise - [IT_DEF]). 318 OT: Operational Technology (the hardware and software dedicated to 319 detecting or causing changes in physical processes through direct 320 monitoring and/or control of physical devices such as valves, pumps, 321 etc. - [OT_DEF]) 323 Component: A component of a DetNet system - used here to refer to any 324 hardware or software element of a DetNet which implements DetNet- 325 specific functionality, for example all or part of a router, switch, 326 or end system. 328 Device: Used here to refer to a physical entity controlled by the 329 DetNet, for example a motor. 331 Resource Segmentation: Used as a more general form for Network 332 Segmentation (the act or practice of splitting a computer network 333 into subnetworks, each being a network segment - [RS_DEF]) 335 Controller Plane: In DetNet the Controller Plane corresponds to the 336 aggregation of the Control and Management Planes (see [RFC8655] 337 section 4.4.2). 339 3. Security Considerations for DetNet Component Design 341 This section provides guidance for implementers of components to be 342 used in a DetNet. 344 As noted above, DetNet provides resource allocation, explicit routes 345 and redundant path support. Each of these has associated security 346 implications, which are discussed in this section, in the context of 347 component design. Detection, reporting and appropriate action in the 348 case of packet arrival time violations are also discussed. 350 3.1. Resource Allocation 352 3.1.1. Inviolable Flows 354 A DetNet system security designer relies on the premise that any 355 resources allocated to a resource-reserved (OT-type) flow are 356 inviolable; in other words there is no physical possibility within a 357 DetNet component that resources allocated to a given DetNet flow can 358 be compromised by any type of traffic in the network; this includes 359 malicious traffic as well as inadvertent traffic such as might be 360 produced by a malfunctioning component, or due to interactions 361 between components that were not sufficiently tested for 362 interoperability. From a security standpoint this is a critical 363 assumption, for example when designing against DOS attacks. In other 364 words, with correctly designed components and security mechanisms, 365 one can prevent malicious activities from impacting other resources. 367 However, achieving the goal of absolutely inviolable flows may not be 368 technically or economically feasible for any given use case, given 369 the broad range of possible use cases (e.g. [reference to DetNet Use 370 Cases RFC8578]) and their associated security considerations as 371 outlined in this document. It can be viewed as a continuum of 372 security requirements, from isolated ultra-low latency systems that 373 may have little security vulnerability (such as an industrial 374 machine) to broadly distributed systems with many possible attack 375 vectors and OT security concerns (such as a utility network). Given 376 this continuum, the design principle employed in this document is to 377 specify the desired end results, without being overly prescriptive in 378 how the results are achieved, reflecting the understanding that no 379 individual implementation is likely to be appropriate for every 380 DetNet use case. 382 3.1.2. Design Trade-Off Considerations in the Use Cases Continuum 384 It is important for the DetNet system designer to understand, for any 385 given DetNet use case and its associated security requirements, the 386 interaction and design trade-offs that inevitably need to be 387 reconciled between the desired end results and the DetNet protocols, 388 as well as the DetNet system and component design. 390 For any given component, as designed for any given use case (or scope 391 of use cases), it is the responsibility of the component designer to 392 ensure that the premise of inviolable flows is supported, to the 393 extent that they deem necessary to support their target use cases. 395 For example, the component may include traffic shaping and policing 396 at the ingress, to prevent corrupted or malicious or excessive 397 packets from entering the network, thereby decreasing the likelihood 398 that any traffic will interfere with any DetNet OT flow. The 399 component may include integrity protection for some or all of the 400 header fields such as those used for flow ID, thereby decreasing the 401 likelihood that a packet whose flow ID has been compromised might be 402 directed into a different flow path. The component may verify every 403 single packet header at every forwarding location, or only at certain 404 points. In any of these cases the component may use dynamic 405 performance analytics (Section 7.7) to cause action to be initiated 406 to address the situation in an appropriate and timely manner, either 407 at the data plane or controller plane, or both in concert. The 408 component's software and hardware may include measures to ensure the 409 integrity of the resource allocation/deallocation process. Other 410 design aspects of the component may help ensure that the adverse 411 effects of malicious traffic are more limited, for example by 412 protecting network control interfaces, or minimizing cascade 413 failures. The component may include features specific to a given use 414 case, such as configuration of the response to a given sequential 415 packet loss count. 417 Ultimately, due to cost and complexity factors, the security 418 properties of a component designed for low-cost systems may be (by 419 design) far inferior to a component with similar intended 420 functionality, but designed for highly secure or otherwise critical 421 applications, perhaps at substantially higher cost. Any given 422 component is designed for some set of use cases and accordingly will 423 have certain limitations on its security properties and 424 vulnerabilities. It is thus the responsibility of the system 425 designer to assure themselves that the components they use in their 426 design are capable of satisfying their overall system security 427 requirements. 429 3.1.3. Documenting the Security Properties of a Component 431 In order for the system designer to adequately understand the 432 security related behavior of a given component, the designer of any 433 component intended for use with DetNet needs to clearly document the 434 security properties of that component. For example, to address the 435 case where a corrupted packet in which the flow identification 436 information is compromised and thus may incidentally match the flow 437 ID of another ("victim") DetNet flow, resulting in additional 438 unauthorized traffic on the victim, the documentation might state 439 that the component employs integrity protection on the flow 440 identification fields. 442 3.1.4. Fail-Safe Component Behavior 444 Even when the security properties of a component are understood and 445 well specified, if the component malfunctions, for example due to 446 physical circumstances unpredicted by the component designer, it may 447 be difficult or impossible to fully prevent malfunction of the 448 network. The degree to which a component is hardened against various 449 types of failures is a distinguishing feature of the component and 450 its design, and the overall system design can only be as strong as 451 its weakest link. 453 However, all networks are subject to this level of uncertainty; it is 454 not unique to DetNet. Having said that, DetNet raises the bar by 455 changing many added latency scenarios from tolerable annoyances to 456 unacceptable service violations. That in turn underscores the 457 importance of system integrity, as well as correct and stable 458 configuration of the network and its nodes, as discussed in 459 Section 1. 461 3.1.5. Flow Aggregation Example 463 As another example regarding resource allocation implementation, 464 consider the implementation of Flow Aggregation for DetNet flows (as 465 discussed in [RFC8938]). In this example say there are N flows that 466 are to be aggregated, thus the bandwidth resources of the aggregate 467 flow must be sufficient to contain the sum of the bandwidth 468 reservation for the N flows. However if one of those flows were to 469 consume more than its individually allocated bandwidth, this could 470 cause starvation of the other flows. Thus simply providing and 471 enforcing the calculated aggregate bandwidth may not be a complete 472 solution - the bandwidth for each individual flow must still be 473 guaranteed, for example via ingress policing of each flow (i.e. 475 before it is aggregated). Alternatively, if by some other means each 476 flow to be aggregated can be trusted not to exceed its allocated 477 bandwidth, the same goal can be achieved. 479 3.2. Explicit Routes 481 The DetNet-specific purpose for constraining the ability of the 482 DetNet to re-route OT traffic is to maintain the specified service 483 parameters (such as upper and lower latency boundaries) for a given 484 flow. For example if the network were to re-route a flow (or some 485 part of a flow) based exclusively on statistical path usage metrics, 486 or due to malicious activity, it is possible that the new path would 487 have a latency that is outside the required latency bounds which were 488 designed into the original TE-designed path, thereby violating the 489 quality of service for the affected flow (or part of that flow). 491 However, it is acceptable for the network to re-route OT traffic in 492 such a way as to maintain the specified latency bounds (and any other 493 specified service properties) for any reason, for example in response 494 to a runtime component or path failure. 496 So from a DetNet security standpoint, the DetNet system designer can 497 expect that any component designed for use in a DetNet will deliver 498 the packets within the agreed-upon service parameters. For the 499 component designer, this means that in order for a component to 500 achieve that expectation, any component that is involved in 501 controlling or implementing any change of the initially TE-configured 502 flow routes must prevent re-routing of OT flows (whether malicious or 503 accidental) which might adversely affect delivering the traffic 504 within the specified service parameters. 506 3.3. Redundant Path Support 508 The DetNet provision for redundant paths (PREOF) (as defined in the 509 DetNet Architecture [RFC8655]) provides the foundation for high 510 reliability of a DetNet, by virtually eliminating packet loss (i.e. 511 to a degree which is implementation-dependent) through hitless 512 redundant packet delivery. Note: At the time of this writing, PREOF 513 is not defined for the IP data plane. 515 It is the responsibility of the system designer to determine the 516 level of reliability required by their use case, and to specify 517 redundant paths sufficient to provide the desired level of 518 reliability (in as much as that reliability can be provided through 519 the use of redundant paths). It is the responsibility of the 520 component designer to ensure that the relevant PREOF operations are 521 executed reliably and securely, to avoid potentially catastrophic 522 situations for the operational technology relying on them. 524 However, note that not all PREOF operations are necessarily 525 implemented in every network; for example a packet re-ordering 526 function may not be necessary if the packets are either not required 527 to be in order, or if the ordering is performed in some other part of 528 the network. 530 Ideally a redundant path for a flow could be specified from end to 531 end, however given that this is not always possible (as described in 532 [RFC8655]) the system designer will need to consider the resulting 533 end-to-end reliability and security resulting from any given 534 arrangement of network segments along the path, each of which 535 provides its individual PREOF implementation and thus its individual 536 level of reliability and security. 538 At the data plane the implementation of PREOF depends on the correct 539 assignment and interpretation of packet sequence numbers, as well as 540 the actions taken based on them, such as elimination (including 541 elimination of packets with spurious sequence numbers). Thus the 542 integrity of these values must be maintained by the component as they 543 are assigned by the DetNet Data Plane Service sub-layer, and 544 transported by the Forwarding sub-layer. This is no different than 545 the integrity of the values in any header used by the DetNet (or any 546 other) data plane, and is not unique to redundant paths. The 547 integrity protection of header values is technology-dependent; for 548 example, in Layer 2 networks the integrity of the header fields can 549 be protected by using MACsec [IEEE802.1AE-2018]. Similarly, from the 550 sequence number injection perspective, it is no different from any 551 other protocols that use sequence numbers. In particular IPSec 552 Authentication Header ([RFC4302], Sec. 3 Authentication Header (AH) 553 Processing) provides useful insights. 555 3.4. Timing (or other) Violation Reporting 557 A task of the DetNet system designer is to create a network such that 558 for any incoming packet which arrives with any timing or bandwidth 559 violation, an appropriate action can be taken in order to prevent 560 damage to the system. The reporting step may be accomplished through 561 dynamic performance analysis (see Section 7.7) or by any other means 562 as implemented in one or more components. The action to be taken for 563 any given circumstance within any given application will depend on 564 the use case. The action may involve intervention from the 565 controller plane, or it may be taken "immediately" by an individual 566 component, for example if very fast response is required. 568 The definitions and selections of the actions that can be taken are 569 properties of the components. The component designer implements 570 these options according to their expected use cases, which may vary 571 widely from component to component. Clearly selecting an 572 inappropriate response to a given condition may cause more problems 573 than it is intending to mitigate; for example, a naive approach might 574 be to have the component shut down the link if a packet arrives 575 outside of its prescribed time window; however such a simplistic 576 action may serve the attacker better than it serves the network. 577 Similarly, simple logging of such issues may not be adequate, since a 578 delay in response could result in material damage, for example to 579 mechanical devices controlled by the network. Thus a breadth of 580 possible and effective security-related actions and their 581 configuration is a positive attribute for a DetNet component. 583 Some possible violations that warrant detection include cases where a 584 packet arrives: 586 o Outside of its prescribed time window 588 o Within its time window but with a compromised time stamp that 589 makes it appear that it is not within its window 591 o Exceeding the reserved flow bandwidth 593 Some possible direct actions that may be taken at the data plane 594 include traffic policing and shaping functions (e.g., those described 595 in [RFC2475]), separating flows into per-flow rate-limited queues, 596 and potentially applying active queue management [RFC7567]. However 597 if those (or any other) actions are to be taken, the system designer 598 must ensure that the results of such actions do not compromise the 599 continued safe operation of the system. For example, the network 600 (i.e. the controller plane and data plane working together) must 601 mitigate in a timely fashion any potential adverse effect on 602 mechanical devices controlled by the network. 604 4. DetNet Security Considerations Compared With DiffServ Security 605 Considerations 607 DetNet is designed to be compatible with DiffServ [RFC2474] as 608 applied to IT traffic in the DetNet. DetNet also incorporates the 609 use of the 6-bit value of the DSCP field of the Type of Service (ToS) 610 byte of the IPv4 header (or the Traffic Class byte in IPv6) for flow 611 identification for OT traffic. However, the DetNet interpretation of 612 the DSCP value for OT traffic is not equivalent to the PHB selection 613 behavior as defined by DiffServ. 615 Thus security consideration for DetNet have some aspects in common 616 with DiffServ, in fact overlapping 100% with respect to IP IT 617 traffic. Security considerations for these aspects are part of the 618 existing literature on IP network security, specifically the Security 619 Considerations sections of [RFC2474] and [RFC2475]. However, DetNet 620 also introduces timing and other considerations which are not present 621 in DiffServ, so the DiffServ security considerations are a subset of 622 the DetNet security considerations. 624 In the case of DetNet OT traffic, the DSCP value is interpreted 625 differently than in DiffServ and contribute to determination of the 626 service provided to the packet. In DetNet, there are similar 627 consequences to DiffServ for lack of detection of, or incorrect 628 handling of, packets with mismarked DSCP values, and many of the 629 points made in the DiffServ Security discussions ([RFC2475] Sec. 6.1 630 , [RFC2474] Sec. 7 and [RFC6274] Sec 3.3.2.1) are also relevant to 631 DetNet OT traffic, though perhaps in modified form. For example, in 632 DetNet the effect of an undetected or incorrectly handled maliciously 633 mismarked DSCP field in an OT packet is not identical to affecting 634 the PHB of that packet, since DetNet does not use the PHB concept for 635 OT traffic; but nonetheless the service provided to the packet could 636 be affected, so mitigation measures analogous to those prescribed by 637 DiffServ would be appropriate for DetNet. For example, mismarked 638 DSCP values should not cause failure of network nodes. The remarks 639 in [RFC2474] regarding IPsec and Tunnelling Interactions are also 640 relevant (though this is not to say that other sections are less 641 relevant). 643 In this discussion, interpretation (and any possible intentional re- 644 marking) of the DSCP values of packets destined for DetNet OT flows 645 is expected to occur at the ingress to the DetNet domain; once inside 646 the domain, maintaining the integrity of the DSCP values is subject 647 to the same handling considerations as any other field in the packet. 649 5. Security Threats 651 This section presents a taxonomy of threats, and analyzes the 652 possible threats in a DetNet-enabled network. The threats considered 653 in this section are independent of any specific technologies used to 654 implement the DetNet; Section 9 considers attacks that are associated 655 with the DetNet technologies encompassed by [RFC8938]. 657 We distinguish controller plane threats from data plane threats. The 658 attack surface may be the same, but the types of attacks as well as 659 the motivation behind them, are different. For example, a delay 660 attack is more relevant to data plane than to controller plane. 661 There is also a difference in terms of security solutions: the way 662 you secure the data plane is often different than the way you secure 663 the controller plane. 665 5.1. Threat Taxonomy 667 This document employs organizational elements of the threat models of 668 [RFC7384] and [RFC7835]. This model classifies attackers based on 669 two criteria: 671 o Internal vs. external: internal attackers either have access to a 672 trusted segment of the network or possess the encryption or 673 authentication keys. External attackers, on the other hand, do 674 not have the keys and have access only to the encrypted or 675 authenticated traffic. 677 o On-path vs. off-path: on-path attackers are located in a position 678 that allows interception, modification, or dropping of in-flight 679 protocol packets, whereas off-path attackers can only attack by 680 generating protocol packets. 682 Regarding the boundary between internal vs. external attackers as 683 defined above, please note that in this document we do not make 684 concrete recommendations regarding which specific segments of the 685 network are to be protected in any specific way, for example via 686 encryption or authentication. As a result, the boundary as defined 687 above is not unequivocally specified here. Given that constraint, 688 the reader can view an internal attacker as one who can operate 689 within the perimeter defined by the DetNet Edge Nodes (as defined in 690 the DetNet Architecture [RFC8655]), allowing that the specifics of 691 what is encrypted or authenticated within this perimeter will vary 692 depending on the implementation. 694 Care has also been taken to adhere to Section 5 of [RFC3552], both 695 with respect to which attacks are considered out-of-scope for this 696 document, but also which are considered to be the most common threats 697 (explored further in Section 5.2, Threat Analysis). Most of the 698 direct threats to DetNet are active attacks (i.e. attacks that modify 699 DetNet traffic), but it is highly suggested that DetNet application 700 developers take appropriate measures to protect the content of the 701 DetNet flows from passive attacks (i.e. attacks that observe but do 702 not modify DetNet traffic) for example through the use of TLS or 703 DTLS. 705 DetNet-Service, one of the service scenarios described in 706 [I-D.varga-detnet-service-model], is the case where a service 707 connects DetNet islands, i.e. two or more otherwise independent 708 DetNets are connected via a link that is not intrinsically part of 709 either network. This implies that there could be DetNet traffic 710 flowing over a non-DetNet link, which may provide an attacker with an 711 advantageous opportunity to tamper with DetNet traffic. The security 712 properties of non-DetNet links are outside of the scope of DetNet 713 Security, but it should be noted that use of non-DetNet services to 714 interconnect DetNets merits security analysis to ensure the integrity 715 of the networks involved. 717 5.2. Threat Analysis 719 5.2.1. Delay 721 An attacker can maliciously delay DetNet data flow traffic. By 722 delaying the traffic, the attacker can compromise the service of 723 applications that are sensitive to high delays or to high delay 724 variation. The delay may be constant or modulated. 726 5.2.2. DetNet Flow Modification or Spoofing 728 An attacker can modify some header fields of en route packets in a 729 way that causes the DetNet flow identification mechanisms to 730 misclassify the flow. Alternatively, the attacker can inject traffic 731 that is tailored to appear as if it belongs to a legitimate DetNet 732 flow. The potential consequence is that the DetNet flow resource 733 allocation cannot guarantee the performance that is expected when the 734 flow identification works correctly. 736 5.2.3. Resource Segmentation (Inter-segment Attack) Vulnerability 738 DetNet components are expected to split their resources between 739 DetNet flows in a way that prevents traffic from one DetNet flow from 740 affecting the performance of other DetNet flows, and also prevents 741 non-DetNet traffic from affecting DetNet flows. However, perhaps due 742 to implementation constraints, some resources may be partially 743 shared, and an attacker may try to exploit this property. For 744 example, an attacker can inject traffic in order to exhaust network 745 resources such that DetNet packets which share resources with the 746 injected traffic may be dropped or delayed. Such injected traffic 747 may be part of DetNet flows or non-DetNet traffic. 749 Another example of a resource segmentation attack is the case in 750 which an attacker is able to overload the exception path queue on the 751 router, i.e. a "slow path" typically taken by control or OAM packets 752 which are diverted from the data plane because they require 753 processing by a CPU. DetNet OT flows are typically configured to 754 take the "fast path" through the data plane, to minimize latency. 755 However if there is only one queue from the forwarding ASIC to the 756 exception path, and for some reason the system is configured such 757 that DetNet packets must be handled on this exception path, then 758 saturating the exception path could result in delaying or dropping of 759 DetNet packets. 761 5.2.4. Packet Replication and Elimination 763 5.2.4.1. Replication: Increased Attack Surface 765 Redundancy is intended to increase the robustness and survivability 766 of DetNet flows, and replication over multiple paths can potentially 767 mitigate an attack that is limited to a single path. However, the 768 fact that packets are replicated over multiple paths increases the 769 attack surface of the network, i.e., there are more points in the 770 network that may be subject to attacks. 772 5.2.4.2. Replication-related Header Manipulation 774 An attacker can manipulate the replication-related header fields. 775 This capability opens the door for various types of attacks. For 776 example: 778 o Forward both replicas - malicious change of a packet SN (Sequence 779 Number) can cause both replicas of the packet to be forwarded. 780 Note that this attack has a similar outcome to a replay attack. 782 o Eliminate both replicas - SN manipulation can be used to cause 783 both replicas to be eliminated. In this case an attacker that has 784 access to a single path can cause packets from other paths to be 785 dropped, thus compromising some of the advantage of path 786 redundancy. 788 o Flow hijacking - an attacker can hijack a DetNet flow with access 789 to a single path by systematically replacing the SNs on the given 790 path with higher SN values. For example, an attacker can replace 791 every SN value S with a higher value S+C, where C is a constant 792 integer. Thus, the attacker creates a false illusion that the 793 attacked path has the lowest delay, causing all packets from other 794 paths to be eliminated in favor of the attacked path. Once the 795 flow from the compromised path is favored by the eliminating 796 bridge, the flow has effectively been hijacked by the attacker. 797 It is now possible for the attacker to either replace en route 798 packets with malicious packets, or to simply inject errors into 799 the packets, causing the packets to be dropped at their 800 destination. 802 o Amplification - an attacker who injects packets into a flow that 803 is to be replicated will have their attack amplified through the 804 replication process. This is no different than any attacker who 805 injects packets that are delivered through multicast, broadcast, 806 or other point-to-multi-point mechanisms. 808 5.2.5. Controller Plane 810 5.2.5.1. Path Choice Manipulation 812 5.2.5.1.1. Control or Signaling Packet Modification 814 An attacker can maliciously modify en route control packets in order 815 to disrupt or manipulate the DetNet path/resource allocation. 817 5.2.5.1.2. Control or Signaling Packet Injection 819 An attacker can maliciously inject control packets in order to 820 disrupt or manipulate the DetNet path/resource allocation. 822 5.2.5.1.3. Increased Attack Surface 824 One of the possible consequences of a path manipulation attack is an 825 increased attack surface. Thus, when the attack described in the 826 previous subsection is implemented, it may increase the potential of 827 other attacks to be performed. 829 5.2.5.2. Compromised Controller 831 An attacker can subvert a legitimate controller (or subvert another 832 component such that it represents itself as a legitimate controller) 833 with the result that the network nodes incorrectly believe it is 834 authorized to instruct them. 836 The presence of a compromised node or controller in a DetNet is not a 837 threat that arises as a result of determinism or time sensitivity; 838 the same techniques used to prevent or mitigate against compromised 839 nodes in any network are equally applicable in the DetNet case. The 840 act of compromising a controller may not even be within the 841 capabilities of our defined attacker types - in other words it may 842 not be achievable via packet traffic at all, whether internal or 843 external, on-path or off-path. It might be accomplished for example 844 by a human with physical access to the component, who could upload 845 bogus firmware to it via a USB stick. All of this underscores the 846 requirement for careful overall system security design in a DetNet, 847 given that the effects of even one bad actor on the network can be 848 potentially catastrophic. 850 Security concerns specific to any given controller plane technology 851 used in DetNet will be addressed by the DetNet documents associated 852 with that technology. 854 5.2.6. Reconnaissance 856 A passive eavesdropper can identify DetNet flows and then gather 857 information about en route DetNet flows, e.g., the number of DetNet 858 flows, their bandwidths, their schedules, or other temporal or 859 statistical properties. The gathered information can later be used 860 to invoke other attacks on some or all of the flows. 862 DetNet flows are typically uniquely identified by their 6-tuple, i.e. 863 fields within the L3 or L4 header, however in some implementations 864 the flow ID may also be augmented by additional per-flow attributes 865 known to the system, e.g. above L4. For the purpose of this document 866 we assume any such additional fields used for flow ID are encrypted 867 and/or integrity-protected from external attackers. Note however 868 that existing OT protocols designed for use on dedicated secure 869 networks may not intrinsically provide such protection, in which case 870 IPsec or transport layer security mechanisms may be needed. 872 5.2.7. Time Synchronization Mechanisms 874 An attacker can use any of the attacks described in [RFC7384] to 875 attack the synchronization protocol, thus affecting the DetNet 876 service. 878 5.3. Threat Summary 880 A summary of the attacks that were discussed in this section is 881 presented in Figure 1. For each attack, the table specifies the type 882 of attackers that may invoke the attack. In the context of this 883 summary, the distinction between internal and external attacks is 884 under the assumption that a corresponding security mechanism is being 885 used, and that the corresponding network equipment takes part in this 886 mechanism. 888 +-------------------------------------------+----+-----+----+-----+ 889 | Attack | Attacker Type | 890 | +----------+----------+ 891 | | Internal | External | 892 | |On-P|Off-P|On-P|Off-P| 893 +-------------------------------------------+----+-----+----+-----+ 894 |Delay attack | + | | + | | 895 +-------------------------------------------+----+-----+----+-----+ 896 |DetNet Flow Modification or Spoofing | + | + | | | 897 +-------------------------------------------+----+-----+----+-----+ 898 |Inter-segment Attack | + | + | + | + | 899 +-------------------------------------------+----+-----+----+-----+ 900 |Replication: Increased Attack Surface | + | + | + | + | 901 +-------------------------------------------+----+-----+----+-----+ 902 |Replication-related Header Manipulation | + | | | | 903 +-------------------------------------------+----+-----+----+-----+ 904 |Path Manipulation | + | + | | | 905 +-------------------------------------------+----+-----+----+-----+ 906 |Path Choice: Increased Attack Surface | + | + | + | + | 907 +-------------------------------------------+----+-----+----+-----+ 908 |Control or Signaling Packet Modification | + | | | | 909 +-------------------------------------------+----+-----+----+-----+ 910 |Control or Signaling Packet Injection | + | + | | | 911 +-------------------------------------------+----+-----+----+-----+ 912 |Reconnaissance | + | | + | | 913 +-------------------------------------------+----+-----+----+-----+ 914 |Attacks on Time Synchronization Mechanisms | + | + | + | + | 915 +-------------------------------------------+----+-----+----+-----+ 917 Figure 1: Threat Analysis Summary 919 6. Security Threat Impacts 921 When designing security for a DetNet, as with any network, it may be 922 prohibitively expensive or technically infeasible to thoroughly 923 protect against every possible threat. Thus the security designer 924 must be informed (for example by an application domain expert such as 925 a product manager) regarding the relative significance of the various 926 threats and their impact if a successful attack is carried out. In 927 this section we present an example of a possible template for such a 928 communication, culminating in a table (Figure 2) which lists a set of 929 threats under consideration, and some values characterizing their 930 relative impact in the context of a given industry. The specific 931 threats, industries, and impact values in the table are provided only 932 as an example of this kind of assessment and its communication; they 933 are not intended to be taken literally. 935 This section considers assessment of the relative impacts of the 936 attacks described in Section 5, Security Threats. In this section, 937 the impacts as described assume that the associated mitigation is not 938 present or has failed. Mitigations are discussed in Section 7, 939 Security Threat Mitigation. 941 In computer security, the impact (or consequence) of an incident can 942 be measured in loss of confidentiality, integrity or availability of 943 information. In the case of time sensitive or OT networks (though 944 not to the exclusion of IT or non-time-sensitive networks) the impact 945 of an exploit can also include failure or malfunction of mechanical 946 and/or other physical systems. 948 DetNet raises these stakes significantly for OT applications, 949 particularly those which may have been designed to run in an OT-only 950 environment and thus may not have been designed for security in an IT 951 environment with its associated components, services and protocols. 953 The extent of impact of a successful vulnerability exploit varies 954 considerably by use case and by industry; additional insights 955 regarding the individual use cases is available from [RFC8578], 956 DetNet Use Cases. Each of those use cases is represented in 957 Figure 2, including Pro Audio, Electrical Utilities, Industrial M2M 958 (split into two areas, M2M Data Gathering and M2M Control Loop), and 959 others. 961 Aspects of Impact (left column) include Criticality of Failure, 962 Effects of Failure, Recovery, and DetNet Functional Dependence. 963 Criticality of failure summarizes the seriousness of the impact. The 964 impact of a resulting failure can affect many different metrics that 965 vary greatly in scope and severity. In order to reduce the number of 966 variables, only the following were included: Financial, Health and 967 Safety, Effect on a Single Organization, and Effect on Multiple 968 Organizations. Recovery outlines how long it would take for an 969 affected use case to get back to its pre-failure state (Recovery time 970 objective, RTO), and how much of the original service would be lost 971 in between the time of service failure and recovery to original state 972 (Recovery Point Objective, RPO). DetNet dependence maps how much the 973 following DetNet service objectives contribute to impact of failure: 974 Time dependency, data integrity, source node integrity, availability, 975 latency/jitter. 977 The scale of the Impact mappings is low, medium, and high. In some 978 use cases there may be a multitude of specific applications in which 979 DetNet is used. For simplicity this section attempts to average the 980 varied impacts of different applications. This section does not 981 address the overall risk of a certain impact which would require the 982 likelihood of a failure happening. 984 In practice any such ratings will vary from case to case; the ratings 985 shown here are given as examples. 987 Table 988 +------------------+-----------------------------------------+-----+ 989 | | Pro A | Util | Bldg |Wire- | Cell |M2M |M2M | 990 | | | | | less | |Data |Ctrl | 991 +------------------+-----------------------------------------+-----+ 992 | Criticality | Med | Hi | Low | Med | Med | Med | Med | 993 +------------------+-----------------------------------------+-----+ 994 | Effects 995 +------------------+-----------------------------------------+-----+ 996 | Financial | Med | Hi | Med | Med | Low | Med | Med | 997 +------------------+-----------------------------------------+-----+ 998 | Health/Safety | Med | Hi | Hi | Med | Med | Med | Med | 999 +------------------+-----------------------------------------+-----+ 1000 | Affects 1 org | Hi | Hi | Med | Hi | Med | Med | Med | 1001 +------------------+-----------------------------------------+-----+ 1002 | Affects >1 org | Med | Hi | Low | Med | Med | Med | Med | 1003 +------------------+-----------------------------------------+-----+ 1004 |Recovery 1005 +------------------+-----------------------------------------+-----+ 1006 | Recov Time Obj | Med | Hi | Med | Hi | Hi | Hi | Hi | 1007 +------------------+-----------------------------------------+-----+ 1008 | Recov Point Obj | Med | Hi | Low | Med | Low | Hi | Hi | 1009 +------------------+-----------------------------------------+-----+ 1010 |DetNet Dependence 1011 +------------------+-----------------------------------------+-----+ 1012 | Time Dependency | Hi | Hi | Low | Hi | Med | Low | Hi | 1013 +------------------+-----------------------------------------+-----+ 1014 | Latency/Jitter | Hi | Hi | Med | Med | Low | Low | Hi | 1015 +------------------+-----------------------------------------+-----+ 1016 | Data Integrity | Hi | Hi | Med | Hi | Low | Hi | Hi | 1017 +------------------+-----------------------------------------+-----+ 1018 | Src Node Integ | Hi | Hi | Med | Hi | Med | Hi | Hi | 1019 +------------------+-----------------------------------------+-----+ 1020 | Availability | Hi | Hi | Med | Hi | Low | Hi | Hi | 1021 +------------------+-----------------------------------------+-----+ 1023 Figure 2: Impact of Attacks by Use Case Industry 1025 The rest of this section will cover impact of the different groups in 1026 more detail. 1028 6.1. Delay-Attacks 1030 6.1.1. Data Plane Delay Attacks 1032 Note that 'delay attack' also includes the possibility of a 'negative 1033 delay' or early arrival of a packet, or possibly adversely changing 1034 the timestamp value. 1036 Delayed messages in a DetNet link can result in the same behavior as 1037 dropped messages in ordinary networks, since the services attached to 1038 the DetNet flow are likely to have strict delivery time requirements. 1040 For a single path scenario, disruption within the single flow is a 1041 real possibility. In a multipath scenario, large delays or 1042 instabilities in one DetNet flow can also lead to increased buffer 1043 and processor resource consumption at the eliminating router. 1045 A data-plane delay attack on a system controlling substantial moving 1046 devices, for example in industrial automation, can cause physical 1047 damage. For example, if the network promises a bounded latency of 1048 2ms for a flow, yet the machine receives it with 5ms latency, control 1049 loop of the machine can become unstable. 1051 6.1.2. Controller Plane Delay Attacks 1053 In and of itself, this is not directly a threat to the DetNet 1054 service, but the effects of delaying control messages can have quite 1055 adverse effects later. 1057 o Delayed tear-down can lead to resource leakage, which in turn can 1058 result in failure to allocate new DetNet flows, finally giving 1059 rise to a denial of service attack. 1061 o Failure to deliver, or severely delaying, controller plane 1062 messages adding an endpoint to a multicast-group will prevent the 1063 new endpoint from receiving expected frames thus disrupting 1064 expected behavior. 1066 o Delaying messages removing an endpoint from a group can lead to 1067 loss of privacy as the endpoint will continue to receive messages 1068 even after it is supposedly removed. 1070 6.2. Flow Modification and Spoofing 1071 6.2.1. Flow Modification 1073 If the contents of a packet header or body can be modified by the 1074 attacker, this can cause the packet to be routed incorrectly or 1075 dropped, or the payload to be corrupted or subtly modified. Thus, 1076 the potential impact of a modification attack includes disrupting the 1077 application as well as the network equipment. 1079 6.2.2. Spoofing 1081 6.2.2.1. Dataplane Spoofing 1083 Spoofing dataplane messages can result in increased resource 1084 consumptions on the routers throughout the network as it will 1085 increase buffer usage and processor utilization. This can lead to 1086 resource exhaustion and/or increased delay. 1088 If the attacker manages to create valid headers, the false messages 1089 can be forwarded through the network, using part of the allocated 1090 bandwidth. This in turn can cause legitimate messages to be dropped 1091 when the resource budget has been exhausted. 1093 Finally, the endpoint will have to deal with invalid messages being 1094 delivered to the endpoint instead of (or in addition to) a valid 1095 message. 1097 6.2.2.2. Controller Plane Spoofing 1099 A successful controller plane spoofing-attack will potentially have 1100 adverse effects. It can do virtually anything from: 1102 o modifying existing DetNet flows by changing the available 1103 bandwidth 1105 o add or remove endpoints from a DetNet flow 1107 o drop DetNet flows completely 1109 o falsely create new DetNet flows (exhaust the systems resources, or 1110 to enable DetNet flows that are outside the control of the Network 1111 Engineer) 1113 6.3. Segmentation Attacks (injection) 1114 6.3.1. Data Plane Segmentation 1116 Injection of false messages in a DetNet flow could lead to exhaustion 1117 of the available bandwidth for that flow if the routers attribute 1118 these false messages to the resource budget of that flow. 1120 In a multipath scenario, injected messages will cause increased 1121 processor utilization in elimination routers. If enough paths are 1122 subject to malicious injection, the legitimate messages can be 1123 dropped. Likewise it can cause an increase in buffer usage. In 1124 total, it will consume more resources in the routers than normal, 1125 giving rise to a resource exhaustion attack on the routers. 1127 If a DetNet flow is interrupted, the end application will be affected 1128 by what is now a non-deterministic flow. Note that there are many 1129 possible sources of flow interruptions, for example, but not limited 1130 to, such physical layer conditions as a broken wire or a radio link 1131 which is compromised by interference. 1133 6.3.2. Controller Plane Segmentation 1135 In a successful controller plane segmentation attack, control 1136 messages are acted on by nodes in the network, unbeknownst to the 1137 central controller or the network engineer. This has the potential 1138 to: 1140 o create new DetNet flows (exhausting resources) 1142 o drop existing DetNet flows (denial of service) 1144 o add end-stations to a multicast group (loss of privacy) 1146 o remove end-stations from a multicast group (reduction of service) 1148 o modify the DetNet flow attributes (affecting available bandwidth) 1150 If an attacker can inject control messages without the central 1151 controller knowing, then one or more components in the network may 1152 get into a state that is not expected by the controller. At that 1153 point, if the controller initiates a command, the effect of that 1154 command may not be as expected, since the target of the command may 1155 have started from a different initial state. 1157 6.4. Replication and Elimination 1159 The Replication and Elimination is relevant only to data plane 1160 messages as controller plane messages are not subject to multipath 1161 routing. 1163 6.4.1. Increased Attack Surface 1165 The impact of an increased attack surface is that it increases the 1166 probability that the network can be exposed to an attacker. This can 1167 facilitate a wide range of specific attacks, and their respective 1168 impacts are discussed in other subsections of this section. 1170 6.4.2. Header Manipulation at Elimination Routers 1172 This attack can potentially cause DoS to the application that uses 1173 the attacked DetNet flows or to the network equipment that forwards 1174 them. Furthermore, it can allow an attacker to manipulate the 1175 network paths and the behavior of the network layer. 1177 6.5. Control or Signaling Packet Modification 1179 If control packets are subject to manipulation undetected, the 1180 network can be severely compromised. 1182 6.6. Control or Signaling Packet Injection 1184 If an attacker can inject control packets undetected, the network can 1185 be severely compromised. 1187 6.7. Reconnaissance 1189 Of all the attacks, this is one of the most difficult to detect and 1190 counter. 1192 An attacker can, at their leisure, observe over time various aspects 1193 of the messaging and signalling, learning the intent and purpose of 1194 the traffic flows. Then at some later date, possibly at an important 1195 time in the operational context, they might launch an attack based on 1196 that knowledge. 1198 The flow-id in the header of the data plane messages gives an 1199 attacker a very reliable identifier for DetNet traffic, and this 1200 traffic has a high probability of going to lucrative targets. 1202 Applications which are ported from a private OT network to the higher 1203 visibility DetNet environment may need to be adapted to limit 1204 distinctive flow properties that could make them susceptible to 1205 reconnaissance. 1207 6.8. Attacks on Time Synchronization Mechanisms 1209 DetNet relies on an underlying time synchronization mechanism, and 1210 therefore a compromised synchronization mechanism may cause DetNet 1211 nodes to malfunction. Specifically, DetNet flows may fail to meet 1212 their latency requirements and deterministic behavior, thus causing 1213 DoS to DetNet applications. 1215 6.9. Attacks on Path Choice 1217 This is covered in part in Section 6.3, Segmentation Attacks, and as 1218 with Replication and Elimination ( Section 6.4), this is relevant for 1219 DataPlane messages. 1221 7. Security Threat Mitigation 1223 This section describes a set of measures that can be taken to 1224 mitigate the attacks described in Section 5, Security Threats. These 1225 mitigations should be viewed as a set of tools, any of which can be 1226 used individually or in concert. The DetNet component and/or system 1227 and/or application designer can apply these tools, as necessary based 1228 on a system-specific threat analysis. 1230 Some of the technology-specific security considerations and 1231 mitigation approaches are further discussed in the DetNet data plane 1232 solution documents, such as [RFC8939], [RFC8938], 1233 [I-D.ietf-detnet-mpls-over-udp-ip], and 1234 [I-D.ietf-detnet-ip-over-mpls]. 1236 7.1. Path Redundancy 1238 Description 1240 A DetNet flow that can be forwarded simultaneously over multiple 1241 paths. Packet replication and elimination [RFC8655] provides 1242 resiliency to dropped or delayed packets. This redundancy 1243 improves the robustness to failures and to on-path attacks. Note: 1244 At the time of this writing, PREOF is not defined for the IP data 1245 plane. 1247 Related attacks 1249 Path redundancy can be used to mitigate various on-path attacks, 1250 including attacks described in Section 5.2.1, Section 5.2.2, 1251 Section 5.2.3, and Section 5.2.7. However it is also possible 1252 that multiple paths may make it more difficult to locate the 1253 source of an on-path attacker. 1255 A delay modulation attack could result in extensively exercising 1256 parts of the code that wouldn't normally be extensively exercised 1257 and thus might expose flaws in the system that might otherwise not 1258 be exposed. 1260 7.2. Integrity Protection 1262 Description 1264 Integrity Protection in the scope of DetNet is the ability to 1265 detect if a packet header has been modified (maliciously or 1266 otherwise) and if so, take some appropriate action (as discussed 1267 in Section 7.7). The decision on where in the network to apply 1268 integrity protection is part of the DetNet system design, and the 1269 implementation of the protection method itself is a part of a 1270 DetNet component design. 1272 The most common technique for detecting header modification is the 1273 use of a Message Authentication Code (MAC) (for examples see 1274 Section 9). The MAC can be distributed either in-line (included 1275 in the same packet) or via a side channel. Of these, the in-line 1276 method is generally preferred due to the low latency that may be 1277 required on DetNet flows and the relative complexity and 1278 computational overhead of a sideband approach. 1280 There are different levels of security available for integrity 1281 protection, ranging from the basic ability to detect if a header 1282 has been corrupted in transit (no malicious attack) to stopping a 1283 skilled and determined attacker capable of both subtly modifying 1284 fields in the headers as well as updating an unsigned MAC. Common 1285 for all are the 2 steps that need to be performed in both ends. 1286 The first is computing the checksum or MAC. The corresponding 1287 verification step must perform the same steps before comparing the 1288 provided with the computed value. Only then can the receiver be 1289 reasonably sure that the header is authentic. 1291 The most basic protection mechanism consists of computing a simple 1292 checksum of the header fields and provide it to the next entity in 1293 the packets path for verification. Using a MAC combined with a 1294 secret key provides the best protection against modification and 1295 replication attacks (see Section 5.2.2 and Section 5.2.4). This 1296 MAC usage needs to be part of a security association that is 1297 established and managed by a security association protocol (such 1298 as IKEv2 for IPsec security associations). Integrity protection 1299 in the controller plane is discussed in Section 7.6. The secret 1300 key, regardless of MAC used, must be protected from falling into 1301 the hands of unauthorized users. Once key management becomes a 1302 topic, it is important to understand that this is a delicate 1303 process and should not be undertaken lightly. BCP 107 [RFC4107] 1304 provides best practices in this regard. 1306 DetNet system and/or component designers need to be aware of these 1307 distinctions and enforce appropriate integrity protection 1308 mechanisms as needed based on a threat analysis. Note that adding 1309 integrity protection mechanisms may introduce latency, thus many 1310 of the same considerations in Section 7.5.1 also apply here. 1312 Packet Sequence Number Integrity Considerations 1314 The use of PREOF in a DetNet implementation implies the use of a 1315 sequence number for each packet. There is a trust relationship 1316 between the component that adds the sequence number and the 1317 component that removes the sequence number. The sequence number 1318 may be end-to-end source to destination, or may be added/deleted 1319 by network edge components. The adder and remover(s) have the 1320 trust relationship because they are the ones that ensure that the 1321 sequence numbers are not modifiable. Thus, sequence numbers can 1322 be protected by using authenticated encryption, or by a MAC 1323 without using encryption. Between the adder and remover there may 1324 or may not be replication and elimination functions. The 1325 elimination functions must be able to see the sequence numbers. 1326 Therefore, if encryption is done between adders and removers it 1327 must not obscure the sequence number. If the sequence removers 1328 and the eliminators are in the same physical component, it may be 1329 possible to obscure the sequence number, however that is a layer 1330 violation, and is not recommended practice. Note: At the time of 1331 this writing, PREOF is not defined for the IP data plane. 1333 Related attacks 1335 Integrity protection mitigates attacks related to modification and 1336 tampering, including the attacks described in Section 5.2.2 and 1337 Section 5.2.4. 1339 7.3. DetNet Node Authentication 1341 Description 1343 Authentication verifies the identity of DetNet nodes (including 1344 DetNet Controller Plane nodes), and this enables mitigation of 1345 spoofing attacks. While integrity protection ( Section 7.2) 1346 prevents intermediate nodes from modifying information, 1347 authentication can provide traffic origin verification, i.e. to 1348 verify that each packet in a DetNet flow is from a known source. 1349 Although node authentication and integrity protection are two 1350 different goals of a security protocol, in most cases a common 1351 protocol (such as IPsec [RFC4301] or MACsec [IEEE802.1AE-2018]) is 1352 used for achieving both purposes. 1354 Related attacks 1356 DetNet node authentication is used to mitigate attacks related to 1357 spoofing, including the attacks of Section 5.2.2, and 1358 Section 5.2.4. 1360 7.4. Dummy Traffic Insertion 1362 Description 1364 With some queueing methods such as [IEEE802.1Qch-2017] it is 1365 possible to introduce dummy traffic in order to regularize the 1366 timing of packet transmission. This will subsequently reduce the 1367 value of passive monitoring from internal threats (see Section 5) 1368 as it will be much more difficult to associate discrete events 1369 with particular network packets. 1371 Related attacks 1373 Removing distinctive temporal properties of individual packets or 1374 flows can be used to mitigate against reconnaissance attacks 1375 Section 5.2.6. For example, dummy traffic can be used to 1376 synthetically maintain constant traffic rate even when no user 1377 data is transmitted, thus making it difficult to collect 1378 information about the times at which users are active, and the 1379 times at which DetNet flows are added or removed. 1381 Traffic Insertion Challenges 1383 Once an attacker is able to monitor the frames traversing a 1384 network to such a degree that they can differentiate between best- 1385 effort traffic and traffic belonging to a specific DetNet flow, it 1386 becomes difficult to not reveal to the attacker whether a given 1387 frame is valid traffic or an inserted frame. Thus, having the 1388 DetNet components generate and remove the dummy traffic may or may 1389 not be a viable option, unless certain challenges are solved; for 1390 example, but not limited to: 1392 o Inserted traffic must be indistinguishable from valid stream 1393 traffic from the viewpoint of the attacker. 1395 o DetNet components must be able to safely identify and remove all 1396 inserted traffic (and only inserted traffic). 1398 o The controller plane must manage where to insert and remove dummy 1399 traffic, but this information must not be revealed to an attacker. 1401 An alternative design is to have the insertion and removal of 1402 dummy traffic be performed at the application layer, rather than 1403 by the DetNet itself. Further discussions and reading about how 1404 sRTP handles this can be found in [RFC6562] 1406 7.5. Encryption 1408 Description 1410 Reconnaissance attacks (Section 5.2.6) can be mitigated to some 1411 extent through the use of encryption, thereby preventing the 1412 attacker from accessing the packet header or contents. Specific 1413 encryption protocols will depend on the lower layers that DetNet 1414 is forwarded over. For example, IP flows may be forwarded over 1415 IPsec [RFC4301], and Ethernet flows may be secured using MACsec 1416 [IEEE802.1AE-2018]. 1418 However, despite the use of encryption, a reconnaissance attack 1419 can provide the attacker with insight into the network, even 1420 without visibility into the packet. For example, an attacker can 1421 observe which nodes are communicating with which other nodes, 1422 including when, how often, and with how much data. In addition, 1423 the timing of packets may be correlated in time with external 1424 events such as action of an external device. Such information may 1425 be used by the attacker, for example in mapping out specific 1426 targets for a different type of attack at a different time. 1428 DetNet nodes do not have any need to inspect the payload of any 1429 DetNet packets, making them data-agnostic. This means that end- 1430 to-end encryption at the application layer is an acceptable way to 1431 protect user data. 1433 Note that reconnaissance is a threat that is not specific to 1434 DetNet flows, and therefore reconnaissance mitigation will 1435 typically be analyzed and provided by a network operator 1436 regardless of whether DetNet flows are deployed. Thus, encryption 1437 requirements will typically not be defined in DetNet technology- 1438 specific specifications, but considerations of using DetNet in 1439 encrypted environments will be discussed in these specifications. 1440 For example, Section 5.1.2.3. of [RFC8939] discusses flow 1441 identification of DetNet flows running over IPsec. 1443 Related attacks 1444 As noted above, encryption can be used to mitigate reconnaissance 1445 attacks ( Section 5.2.6). However, for a DetNet to provide 1446 differentiated quality of service on a flow-by-flow basis, the 1447 network must be able to identify the flows individually. This 1448 implies that in a reconnaissance attack the attacker may also be 1449 able to track individual flows to learn more about the system. 1451 7.5.1. Encryption Considerations for DetNet 1453 Any compute time which is required for encryption and decryption 1454 processing ('crypto') must be included in the flow latency 1455 calculations. Thus, crypto algorithms used in a DetNet must have 1456 bounded worst-case execution times, and these values must be used in 1457 the latency calculations. Fortunately, encryption and decryption 1458 operations typically are designed to have constant execution times, 1459 in order to avoid side channel leakage. 1461 Some crypto algorithms are symmetric in encode/decode time (such as 1462 AES) and others are asymmetric (such as public key algorithms). 1463 There are advantages and disadvantages to the use of either type in a 1464 given DetNet context. The discussion in this document relates to the 1465 timing implications of crypto for DetNet; it is assumed that 1466 integrity considerations are covered elsewhere in the literature. 1468 Asymmetrical crypto is typically not used in networks on a packet-by- 1469 packet basis due to its computational cost. For example, if only 1470 endpoint checks or checks at a small number of intermediate points 1471 are required, asymmetric crypto can be used to authenticate 1472 distribution or exchange of a secret symmetric crypto key; a 1473 successful check based on that key will provide traffic origin 1474 verification, as long as the key is kept secret by the participants. 1475 TLS (v1.3 [RFC8446], in particular section 4.1 "Key exchange") and 1476 IKEv2 [RFC6071]) are examples of this for endpoint checks. 1478 However, if secret symmetric keys are used for this purpose the key 1479 must be given to all relays, which increases the probability of a 1480 secret key being leaked. Also, if any relay is compromised or faulty 1481 then it may inject traffic into the flow. Group key management 1482 protocols can be used to automate management of such symmetric keys; 1483 for an example in the context of IPsec, see 1484 [I-D.ietf-ipsecme-g-ikev2]. 1486 Alternatively, asymmetric crypto can provide traffic origin 1487 verification at every intermediate node. For example, a DetNet flow 1488 can be associated with an (asymmetric) keypair, such that the private 1489 key is available to the source of the flow and the public key is 1490 distributed with the flow information, allowing verification at every 1491 node for every packet. However, this is more computationally 1492 expensive. 1494 In either case, origin verification also requires replay detection as 1495 part of the security protocol to prevent an attacker from recording 1496 and resending traffic, e.g., as a denial of service attack on flow 1497 forwarding resources. 1499 In the general case, cryptographic hygiene requires the generation of 1500 new keys during the lifetime of an encrypted flow (e.g. see [RFC4253] 1501 section 9), and any such key generation (or key exchange) requires 1502 additional computing time which must be accounted for in the latency 1503 calculations for that flow. For modern ECDH (Elliptical Curve 1504 Diffie-Hellman) key-exchange operations (such as x25519, see 1505 [RFC7748]) these operations can be performed in constant 1506 (predictable) time, however this is not universally true (for example 1507 for legacy RSA key exchange, [RFC4432]). Thus implementers should be 1508 aware of the time properties of these algorithms and avoid algorithms 1509 that make constant-time implementation difficult or impossible. 1511 7.6. Control and Signaling Message Protection 1513 Description 1515 Control and signaling messages can be protected through the use of 1516 any or all of encryption, authentication, and integrity protection 1517 mechanisms. Compared with data-flows, the timing constraints for 1518 controller and signaling messages may be less strict, and the 1519 number of such packets may be fewer. If that is the case in a 1520 given application, then it may enable the use of asymmetric 1521 cryptography for signing of both payload and headers for such 1522 messages, as well as encrypting the payload. Given that a DetNet 1523 is managed by a central controller, the use of a shared public key 1524 approach for these processes is well-proven. This is further 1525 discussed in Section 7.5.1. 1527 Related attacks 1529 These mechanisms can be used to mitigate various attacks on the 1530 controller plane, as described in Section 5.2.5, Section 5.2.7 and 1531 Section 5.2.5.1. 1533 7.7. Dynamic Performance Analytics 1535 Description 1537 Incorporating Dynamic Performance Analytics ("DPA") implies that 1538 the DetNet design includes a performance monitoring system to 1539 validate that timing guarantees are being met and to detect timing 1540 violations or other anomalies that may be the symptom of a 1541 security attack or system malfunction. If this monitoring system 1542 detects unexpected behavior, it must then cause action to be 1543 initiated to address the situation in an appropriate and timely 1544 manner, either at the data plane or controller plane, or both in 1545 concert. 1547 The overall DPA system can thus be decomposed into the "detection" 1548 and "notification" functions. Although the time-specific DPA 1549 performance indicators and their implementation will likely be 1550 specific to a given DetNet, and as such are nascent technology at 1551 the time of this writing, DPA is commonly used in existing 1552 networks so we can make some observations on how such a system 1553 might be implemented for a DetNet, given that it would need to be 1554 adapted to address the time-specific performance indicators. 1556 Detection Mechanisms 1558 Measurement of timing performance can be done via "passive" or 1559 "active" monitoring, as discussed below. 1561 Examples of passive monitoring strategies include 1563 * Monitoring of queue and buffer levels, e.g. via Active Queue 1564 Management (e.g. [RFC7567] 1566 * Monitoring of per-flow counters 1568 * Measurement of link statistics such as traffic volume, 1569 bandwidth, and QoS 1571 * Detection of dropped packets 1573 * Use of commercially available Network Monitoring tools 1575 Examples of active monitoring include 1577 * In-band timing measurements (such as packet arrival times) e.g. 1578 by timestamping and packet inspection 1580 * Use of OAM. For DetNet-specific OAM considerations see 1581 [I-D.ietf-detnet-ip-oam], [I-D.ietf-detnet-mpls-oam]. Note: At 1582 the time of this writing, specifics of DPA have not been 1583 developed for the DetNet OAM, but could be a subject for future 1584 investigation 1586 * For OAM for Ethernet specifically, see also Connectivity Fault 1587 Management (CFM, [IEEE802.1Q]) which defines protocols and 1588 practices for OAM for paths through 802.1 bridges and LANs 1590 * Out-of-band detection. following the data path or parts of a 1591 data path, for example Bidirectional Forwarding Detection (BFD, 1592 e.g. [RFC5880]) 1594 Note that for some measurements (e.g. packet delay) it may be 1595 necessary to make and reconcile measurements from more than one 1596 physical location (e.g. a source and destination), possibly in 1597 both directions, in order to arrive at a given performance 1598 indicator value. 1600 Notification Mechanisms 1602 Making DPA measurement results available at the right place(s) and 1603 time(s) to effect timely response can be challenging. Two 1604 notification mechanisms that are in general use are Netconf/YANG 1605 Notifications (e.g. [RFC5880]) and the proprietary local 1606 telemetry interfaces provided with components from some vendors. 1607 The CoAP Observe Option ([RFC7641]) could also be relevant to such 1608 scenarios. 1610 At the time of this writing YANG Notifications are not addressed 1611 by the DetNet YANG drafts, however this may be a topic for future 1612 work. It is possible that some of the passive mechanisms could be 1613 covered by notifications from non-DetNet-specific YANG modules; 1614 for example if there is OAM or other performance monitoring that 1615 can monitor delay bounds then that could have its own associated 1616 YANG model which could be relevant to DetNet, for example some 1617 "threshold" values for timing measurement notifications. 1619 At the time of this writing there is an IETF Working Group for 1620 network/performance monitoring (IP Performance Measurement, ippm). 1621 See also previous work by the completed Remote Network Monitoring 1622 Working Group (rmonmib). See also [RFC6632], An Overview of the 1623 IETF Network Management Standards. 1625 Vendor-specific local telemetry may be available on some 1626 commercially available systems, whereby the system can be 1627 programmed (via a proprietary dedicated port and API) to monitor 1628 and report on specific conditions, based on both passive and 1629 active measurements. 1631 Related attacks 1633 Performance analytics can be used to detect various attacks, 1634 including the ones described in Section 5.2.1 (Delay Attack), 1635 Section 5.2.3 (Resource Segmentation Attack), and Section 5.2.7 1636 (Time Synchronization Attack). Once detection and notification 1637 have occurred, the appropriate action can be taken to mitigate the 1638 threat. 1640 For example, in the case of data plane delay attacks, one possible 1641 mitigation is to timestamp the data at the source, and timestamp 1642 it again at the destination, and if the resulting latency does not 1643 meet the service agreement, take appropriate action. Note that 1644 DetNet specifies packet sequence numbering, however it does not 1645 specify use of packet timestamps, although they may be used by the 1646 underlying transport (for example TSN, [IEEE802.1BA]) to provide 1647 the service. 1649 7.8. Mitigation Summary 1651 The following table maps the attacks of Section 5, Security Threats, 1652 to the impacts of Section 6, Security Threat Impacts, and to the 1653 mitigations of the current section. Each row specifies an attack, 1654 the impact of this attack if it is successfully implemented, and 1655 possible mitigation methods. 1657 +----------------------+---------------------+---------------------+ 1658 | Attack | Impact | Mitigations | 1659 +----------------------+---------------------+---------------------+ 1660 |Delay Attack |-Non-deterministic |-Path redundancy | 1661 | | delay |-Performance | 1662 | |-Data disruption | analytics | 1663 | |-Increased resource | | 1664 | | consumption | | 1665 +----------------------+---------------------+---------------------+ 1666 |Reconnaissance |-Enabler for other |-Encryption | 1667 | | attacks |-Dummy traffic | 1668 | | | insertion | 1669 +----------------------+---------------------+---------------------+ 1670 |DetNet Flow Modificat-|-Increased resource |-Path redundancy | 1671 |ion or Spoofing | consumption |-Integrity protection| 1672 | |-Data disruption |-DetNet Node | 1673 | | | authentication | 1674 +----------------------+---------------------+---------------------+ 1675 |Inter-Segment Attack |-Increased resource |-Path redundancy | 1676 | | consumption |-Performance | 1677 | |-Data disruption | analytics | 1678 +----------------------+---------------------+---------------------+ 1679 |Replication: Increased|-All impacts of other|-Integrity protection| 1680 |attack surface | attacks |-DetNet Node | 1681 | | | authentication | 1682 | | |-Encryption | 1683 +----------------------+---------------------+---------------------+ 1684 |Replication-related |-Non-deterministic |-Integrity protection| 1685 |Header Manipulation | delay |-DetNet Node | 1686 | |-Data disruption | authentication | 1687 +----------------------+---------------------+---------------------+ 1688 |Path Manipulation |-Enabler for other |-Control and | 1689 | | attacks | signaling message | 1690 | | | protection | 1691 +----------------------+---------------------+---------------------+ 1692 |Path Choice: Increased|-All impacts of other|-Control and | 1693 |Attack Surface | attacks | signaling message | 1694 | | | protection | 1695 +----------------------+---------------------+---------------------+ 1696 |Control or Signaling |-Increased resource |-Control and | 1697 |Packet Modification | consumption | signaling message | 1698 | |-Non-deterministic | protection | 1699 | | delay | | 1700 | |-Data disruption | | 1701 +----------------------+---------------------+---------------------+ 1702 |Control or Signaling |-Increased resource |-Control and | 1703 |Packet Injection | consumption | signaling message | 1704 | |-Non-deterministic | protection | 1705 | | delay | | 1706 | |-Data disruption | | 1707 +----------------------+---------------------+---------------------+ 1708 |Attacks on Time |-Non-deterministic |-Path redundancy | 1709 |Synchronization | delay |-Control and | 1710 |Mechanisms |-Increased resource | signaling message | 1711 | | consumption | protection | 1712 | |-Data disruption |-Performance | 1713 | | | analytics | 1714 +----------------------+---------------------+---------------------+ 1716 Figure 3: Mapping Attacks to Impact and Mitigations 1718 8. Association of Attacks to Use Cases 1720 Different attacks can have different impact and/or mitigation 1721 depending on the use case, so we would like to make this association 1722 in our analysis. However since there is a potentially unbounded list 1723 of use cases, we categorize the attacks with respect to the common 1724 themes of the use cases as identified in the Use Case Common Themes 1725 section of the DetNet Use Cases [RFC8578]. 1727 See also Figure 2 for a mapping of the impact of attacks per use case 1728 by industry. 1730 8.1. Association of Attacks to Use Case Common Themes 1732 In this section we review each theme and discuss the attacks that are 1733 applicable to that theme, as well as anything specific about the 1734 impact and mitigations for that attack with respect to that theme. 1735 The table Figure 5, Mapping Between Themes and Attacks, then provides 1736 a summary of the attacks that are applicable to each theme. 1738 8.1.1. Sub-Network Layer 1740 DetNet is expected to run over various transmission mediums, with 1741 Ethernet being the first identified. Attacks such as Delay or 1742 Reconnaissance might be implemented differently on a different 1743 transmission medium, however the impact on the DetNet as a whole 1744 would be essentially the same. We thus conclude that all attacks and 1745 impacts that would be applicable to DetNet over Ethernet (i.e. all 1746 those named in this document) would also be applicable to DetNet over 1747 other transmission mediums. 1749 With respect to mitigations, some methods are specific to the 1750 Ethernet medium, for example time-aware scheduling using 802.1Qbv 1751 [IEEE802.1Qbv-2015] can protect against excessive use of bandwidth at 1752 the ingress - for other mediums, other mitigations would have to be 1753 implemented to provide analogous protection. 1755 8.1.2. Central Administration 1757 A DetNet network can be controlled by a centralized network 1758 configuration and control system. Such a system may be in a single 1759 central location, or it may be distributed across multiple control 1760 entities that function together as a unified control system for the 1761 network. 1763 All attacks named in this document which are relevant to controller 1764 plane packets (and the controller itself) are relevant to this theme, 1765 including Path Manipulation, Path Choice, Control Packet Modification 1766 or Injection, Reconnaissance and Attacks on Time Synchronization 1767 Mechanisms. 1769 8.1.3. Hot Swap 1771 A DetNet network is not expected to be "plug and play" - it is 1772 expected that there is some centralized network configuration and 1773 control system. However, the ability to "hot swap" components (e.g. 1774 due to malfunction) is similar enough to "plug and play" that this 1775 kind of behavior may be expected in DetNet networks, depending on the 1776 implementation. 1778 An attack surface related to Hot Swap is that the DetNet network must 1779 at least consider input at runtime from components that were not part 1780 of the initial configuration of the network. Even a "perfect" (or 1781 "hitless") replacement of a component at runtime would not 1782 necessarily be ideal, since presumably one would want to distinguish 1783 it from the original for OAM purposes (e.g. to report hot swap of a 1784 failed component). 1786 This implies that an attack such as Flow Modification, Spoofing or 1787 Inter-segment (which could introduce packets from a "new" component, 1788 i.e. one heretofore unknown on the network) could be used to exploit 1789 the need to consider such packets (as opposed to rejecting them out 1790 of hand as one would do if one did not have to consider introduction 1791 of a new component). 1793 To mitigate this situation, deployments should provide a method for 1794 dynamic and secure registration of new components, and (possibly 1795 manual) deregistration and re-keying of retired components. This 1796 would avoid the situation in which the network must accommodate 1797 potentially insecure packet flows from unknown components. 1799 Similarly if the network was designed to support runtime replacement 1800 of a clock component, then presence (or apparent presence) and thus 1801 consideration of packets from a new such component could affect the 1802 network, or the time synchronization of the network, for example by 1803 initiating a new Best Master Clock selection process. These types of 1804 attacks should therefore be considered when designing hot swap type 1805 functionality (see [RFC7384]). 1807 8.1.4. Data Flow Information Models 1809 DetNet specifies new YANG models ([I-D.ietf-detnet-yang])which may 1810 present new attack surfaces. Per IETF guidelines, security 1811 considerations for any YANG model are expected to be part of the YANG 1812 model specification, as described in [IETF_YANG_SEC]. 1814 8.1.5. L2 and L3 Integration 1816 A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN 1817 LAN) and Layer 3 (routed) networks (e.g. IP) via the use of well- 1818 known protocols such as IP, MPLS Pseudowire, and Ethernet. Various 1819 DetNet drafts address many specific aspects of Layer 2 and Layer 3 1820 integration within a DetNet, and these are not individually 1821 referenced here; security considerations for those aspects are 1822 covered within those drafts or within the related subsections of the 1823 present document. 1825 Please note that although there are no entries in the L2 and L3 1826 Integration line of the Mapping Between Themes and Attacks table 1827 Figure 4, this does not imply that there could be no relevant attacks 1828 related to L2-L3 integration. 1830 8.1.6. End-to-End Delivery 1832 Packets that are part of a resource-reserved DetNet flow are not to 1833 be dropped by the DetNet due to congestion. Packets may however be 1834 dropped for intended reasons, for example security measures. For 1835 example, consider the case in which a packet becomes corrupted 1836 (whether incidentally or maliciously) such that the resulting flow ID 1837 incidentally matches the flow ID of another DetNet flow, potentially 1838 resulting in additional unauthorized traffic on the latter. In such 1839 a case it may be a security requirement that the system report and/or 1840 take some defined action, perhaps when a packet drop count threshold 1841 has been reached (see also Section 7.7). 1843 A data plane attack may force packets to be dropped, for example as a 1844 result of a Delay attack, Replication/Elimination attack, or Flow 1845 Modification attack. 1847 The same result might be obtained by a controller plane attack, e.g. 1848 Path Manipulation or Signaling Packet Modification. 1850 An attack may also cause packets that should not be delivered to be 1851 delivered, such as by forcing packets from one (e.g. replicated) path 1852 to be preferred over another path when they should not be 1853 (Replication attack), or by Flow Modification, or by Path Choice or 1854 Packet Injection. A Time Synchronization attack could cause a system 1855 that was expecting certain packets at certain times to accept 1856 unintended packets based on compromised system time or time windowing 1857 in the scheduler. 1859 8.1.7. Replacement for Proprietary Fieldbuses and Ethernet-based 1860 Networks 1862 There are many proprietary "field buses" used in Industrial and other 1863 industries, as well as proprietary non-interoperable deterministic 1864 Ethernet-based networks. DetNet is intended to provide an open- 1865 standards-based alternative to such buses/networks. In cases where a 1866 DetNet intersects with such fieldbuses/networks or their protocols, 1867 such as by protocol emulation or access via a gateway, new attack 1868 surfaces can be opened. 1870 For example an Inter-Segment or Controller plane attack such as Path 1871 Manipulation, Path Choice or Control Packet Modification/Injection 1872 could be used to exploit commands specific to such a protocol, or 1873 that are interpreted differently by the different protocols or 1874 gateway. 1876 8.1.8. Deterministic vs Best-Effort Traffic 1878 Most of the themes described in this document address OT (reserved) 1879 DetNet flows - this item is intended to address issues related to IT 1880 traffic on a DetNet. 1882 DetNet is intended to support coexistence of time-sensitive 1883 operational (OT, deterministic) traffic and information (IT, "best 1884 effort") traffic on the same ("unified") network. 1886 With DetNet, this coexistence will become more common, and 1887 mitigations will need to be established. The fact that the IT 1888 traffic on a DetNet is limited to a corporate controlled network 1889 makes this a less difficult problem compared to being exposed to the 1890 open Internet, however this aspect of DetNet security should not be 1891 underestimated. 1893 An Inter-segment attack can flood the network with IT-type traffic 1894 with the intent of disrupting handling of IT traffic, and/or the goal 1895 of interfering with OT traffic. Presumably if the DetNet flow 1896 reservation and isolation of the DetNet is well-designed (better- 1897 designed than the attack) then interference with OT traffic should 1898 not result from an attack that floods the network with IT traffic. 1900 The handling of IT traffic (i.e. traffic which by definition is not 1901 guaranteed any given deterministic service properties) by the DetNet 1902 will by definition not be given the DetNet-specific protections 1903 provided to DetNet (resource-reserved) flows. The implication is 1904 that the IT traffic on the DetNet network will necessarily have its 1905 own specific set of product (component or system) requirements for 1906 protection against attacks such as DOS; presumably they will be less 1907 stringent than those for OT flows, but nonetheless component and 1908 system designers must employ whatever mitigations will meet the 1909 specified security requirements for IT traffic for the given 1910 component or DetNet. 1912 The network design as a whole also needs to consider possible 1913 application-level dependencies of "OT"-type applications on services 1914 provided by the "IT part" of the network; for example, does the OT 1915 application depend on IT network services such as DNS or OAM? If 1916 such dependencies exist, how are malicious packet flows handled? 1917 Such considerations are typically outside the scope of DetNet proper, 1918 but nonetheless need to be addressed in the overall DetNet network 1919 design for a given use case. 1921 8.1.9. Deterministic Flows 1923 Reserved bandwidth data flows (deterministic flows) must provide the 1924 allocated bandwidth, and must be isolated from each other. 1926 A Spoofing or Inter-segment attack which adds packet traffic to a 1927 bandwidth-reserved DetNet flow could cause that flow to occupy more 1928 bandwidth than it was allocated, resulting in interference with other 1929 DetNet flows. 1931 A Flow Modification or Spoofing or Header Manipulation or Control 1932 Packet Modification attack could cause packets from one flow to be 1933 directed to another flow, thus breaching isolation between the flows. 1935 8.1.10. Unused Reserved Bandwidth 1937 If bandwidth reservations are made for a DetNet flow but the 1938 associated bandwidth is not used at any point in time, that bandwidth 1939 is made available on the network for best-effort traffic. However, 1940 note that security considerations for best-effort traffic on a DetNet 1941 network is out of scope of the present document, provided that any 1942 such attacks on best-effort traffic do not affect performance for 1943 DetNet OT traffic. 1945 8.1.11. Interoperability 1947 The DetNet specifications as a whole are intended to enable an 1948 ecosystem in which multiple vendors can create interoperable 1949 products, thus promoting component diversity and potentially higher 1950 numbers of each component manufactured. Toward that end, the 1951 security measures and protocols discussed in this document are 1952 intended to encourage interoperability. 1954 Given that the DetNet specifications are unambiguously written and 1955 that the implementations are accurate, the property of 1956 interoperability should not in and of itself cause security concerns; 1957 however, flaws in interoperability between components could result in 1958 security weaknesses. The network operator as well as system and 1959 component designer can all contribute to reducing such weaknesses 1960 through interoperability testing. 1962 8.1.12. Cost Reductions 1964 The DetNet network specifications are intended to enable an ecosystem 1965 in which multiple vendors can create interoperable products, thus 1966 promoting higher numbers of each component manufactured, promoting 1967 cost reduction and cost competition among vendors. 1969 This envisioned breadth of DetNet-enabled products is in general a 1970 positive factor, however implementation flaws in any individual 1971 component can present an attack surface. In addition, implementation 1972 differences between components from different vendors can result in 1973 attack surfaces (resulting from their interaction) which may not 1974 exist in any individual component. 1976 Network operators can mitigate such concerns through sufficient 1977 product and interoperability testing. 1979 8.1.13. Insufficiently Secure Components 1981 The DetNet network specifications are intended to enable an ecosystem 1982 in which multiple vendors can create interoperable products, thus 1983 promoting component diversity and potentially higher numbers of each 1984 component manufactured. However this raises the possibility that a 1985 vendor might repurpose for DetNet applications a hardware or software 1986 component that was originally designed for operation in an isolated 1987 OT network, and thus may not have been designed to be sufficiently 1988 secure, or secure at all, against the sorts of attacks described in 1989 this document. Deployment of such a component on a DetNet network 1990 that is intended to be highly secure may present an attack surface; 1991 thus the DetNet network operator may need to take specific actions to 1992 protect such components, for example by implementing a secure 1993 interface (such as a firewall) to isolate the component from the 1994 threats that may be present in the greater network. 1996 8.1.14. DetNet Network Size 1998 DetNet networks range in size from very small, e.g. inside a single 1999 industrial machine, to very large, for example a Utility Grid network 2000 spanning a whole country. 2002 The size of the network might be related to how the attack is 2003 introduced into the network, for example if the entire network is 2004 local, there is a threat that power can be cut to the entire network. 2005 If the network is large, perhaps only a part of the network is 2006 attacked. 2008 A Delay attack might be as relevant to a small network as to a large 2009 network, although the amount of delay might be different. 2011 Attacks sourced from IT traffic might be more likely in large 2012 networks, since more people might have access to the network, 2013 presenting a larger attack surface. Similarly Path Manipulation, 2014 Path Choice and Time Synchronization attacks seem more likely 2015 relevant to large networks. 2017 8.1.15. Multiple Hops 2019 Large DetNet networks (e.g. a Utility Grid network) may involve many 2020 "hops" over various kinds of links for example radio repeaters, 2021 microwave links, fiber optic links, etc. 2023 An attacker who has knowledge of the operation of a component or 2024 device's internal software (such as "device drivers") may be able to 2025 take advantage of this knowledge to design an attack that could 2026 exploit flaws (or even the specifics of normal operation) in the 2027 communication between the various links. 2029 It is also possible that a large scale DetNet topology containing 2030 various kinds of links may not be in as common use as other more 2031 homogeneous topologies. This situation may present more opportunity 2032 for attackers to exploit software and/or protocol flaws in or between 2033 these components, because these components or configurations may not 2034 have been sufficiently tested for interoperability (in the way they 2035 would be as a result of broad usage). This may be of particular 2036 concern to early adopters of new DetNet components or technologies. 2038 Of the attacks we have defined, the ones identified in Section 8.1.14 2039 as germane to large networks are the most relevant. 2041 8.1.16. Level of Service 2043 A DetNet is expected to provide means to configure the network that 2044 include querying network path latency, requesting bounded latency for 2045 a given DetNet flow, requesting worst case maximum and/or minimum 2046 latency for a given path or DetNet flow, and so on. It is an 2047 expected case that the network cannot provide a given requested 2048 service level. In such cases the network control system should reply 2049 that the requested service level is not available (as opposed to 2050 accepting the parameter but then not delivering the desired 2051 behavior). 2053 Controller plane attacks such as Signaling Packet Modification and 2054 Injection could be used to modify or create control traffic that 2055 could interfere with the process of a user requesting a level of 2056 service and/or the reply from the network. 2058 Reconnaissance could be used to characterize flows and perhaps target 2059 specific flows for attack via the controller plane as noted in 2060 Section 6.7. 2062 8.1.17. Bounded Latency 2064 DetNet provides the expectation of guaranteed bounded latency. 2066 Delay attacks can cause packets to miss their agreed-upon latency 2067 boundaries. 2069 Time Synchronization attacks can corrupt the time reference of the 2070 system, resulting in missed latency deadlines (with respect to the 2071 "correct" time reference). 2073 8.1.18. Low Latency 2075 Applications may require "extremely low latency" however depending on 2076 the application these may mean very different latency values; for 2077 example "low latency" across a Utility grid network is on a different 2078 time scale than "low latency" in a motor control loop in a small 2079 machine. The intent is that the mechanisms for specifying desired 2080 latency include wide ranges, and that architecturally there is 2081 nothing to prevent arbitrarily low latencies from being implemented 2082 in a given network. 2084 Attacks on the controller plane (as described in the Level of Service 2085 theme Section 8.1.16) and Delay and Time attacks (as described in the 2086 Bounded Latency theme Section 8.1.17) both apply here. 2088 8.1.19. Bounded Jitter (Latency Variation) 2090 DetNet is expected to provide bounded jitter (packet to packet 2091 latency variation). 2093 Delay attacks can cause packets to vary in their arrival times, 2094 resulting in packet to packet latency variation, thereby violating 2095 the jitter specification. 2097 8.1.20. Symmetrical Path Delays 2099 Some applications would like to specify that the transit delay time 2100 values be equal for both the transmit and return paths. 2102 Delay attacks can cause path delays to materially differ between 2103 paths. 2105 Time Synchronization attacks can corrupt the time reference of the 2106 system, resulting in path delays that may be perceived to be 2107 different (with respect to the "correct" time reference) even if they 2108 are not materially different. 2110 8.1.21. Reliability and Availability 2112 DetNet based systems are expected to be implemented with essentially 2113 arbitrarily high availability (for example 99.9999% up time, or even 2114 12 nines). The intent is that the DetNet designs should not make any 2115 assumptions about the level of reliability and availability that may 2116 be required of a given system, and should define parameters for 2117 communicating these kinds of metrics within the network. 2119 Any attack on the system, of any type, can affect its overall 2120 reliability and availability, thus in the mapping table Figure 4 we 2121 have marked every attack. Since every DetNet depends to a greater or 2122 lesser degree on reliability and availability, this essentially means 2123 that all networks have to mitigate all attacks, which to a greater or 2124 lesser degree defeats the purpose of associating attacks with use 2125 cases. It also underscores the difficulty of designing "extremely 2126 high reliability" networks. 2128 In practice, network designers can adopt a risk-based approach, in 2129 which only those attacks are mitigated whose potential cost is higher 2130 than the cost of mitigation. 2132 8.1.22. Redundant Paths 2134 This document expects that each DetNet system will be implemented to 2135 some essentially arbitrary level of reliability and/or availability, 2136 depending on the use case. A strategy used by DetNet for providing 2137 extraordinarily high levels of reliability when justified is to 2138 provide redundant paths between which traffic can be seamlessly 2139 switched, all the while maintaining the required performance of that 2140 system. 2142 Replication-related attacks are by definition applicable here. 2143 Controller plane attacks can also interfere with the configuration of 2144 redundant paths. 2146 8.1.23. Security Measures 2148 If any of the security mechanisms which protect the DetNet are 2149 attacked or subverted, this can result in malfunction of the network. 2150 Thus the security systems themselves needs to be robust against 2151 attacks. 2153 The general topic of protection of security mechanisms is not unique 2154 to DetNet; it is identical to the case of securing any security 2155 mechanism for any network. This document addresses these concerns 2156 only to the extent that they are unique to DetNet. 2158 8.2. Summary of Attack Types per Use Case Common Theme 2160 The List of Attacks table Figure 4 lists the attacks of Section 5, 2161 Security Threats, assigning a number to each type of attack. That 2162 number is then used as a short form identifier for the attack in 2163 Figure 5, Mapping Between Themes and Attacks. 2165 +----+-------------------------------------------+ 2166 | | Attack | 2167 +----+-------------------------------------------+ 2168 | 1 |Delay Attack | 2169 +----+-------------------------------------------+ 2170 | 2 |DetNet Flow Modification or Spoofing | 2171 +----+-------------------------------------------+ 2172 | 3 |Inter-Segment Attack | 2173 +----+-------------------------------------------+ 2174 | 4 |Replication: Increased attack surface | 2175 +----+-------------------------------------------+ 2176 | 5 |Replication-related Header Manipulation | 2177 +----+-------------------------------------------+ 2178 | 6 |Path Manipulation | 2179 +----+-------------------------------------------+ 2180 | 7 |Path Choice: Increased Attack Surface | 2181 +----+-------------------------------------------+ 2182 | 8 |Control or Signaling Packet Modification | 2183 +----+-------------------------------------------+ 2184 | 9 |Control or Signaling Packet Injection | 2185 +----+-------------------------------------------+ 2186 | 10 |Reconnaissance | 2187 +----+-------------------------------------------+ 2188 | 11 |Attacks on Time Synchronization Mechanisms | 2189 +----+-------------------------------------------+ 2191 Figure 4: List of Attacks 2193 The Mapping Between Themes and Attacks table Figure 5 maps the use 2194 case themes of [RFC8578] (as also enumerated in this document) to the 2195 attacks of Figure 4. Each row specifies a theme, and the attacks 2196 relevant to this theme are marked with a '+'. The row items which 2197 have no threats associated with them are included in the table for 2198 completeness of the list of Use Case Common Themes, and do not have 2199 DetNet-specific threats associated with them. 2201 +----------------------------+--------------------------------+ 2202 | Theme | Attack | 2203 | +--+--+--+--+--+--+--+--+--+--+--+ 2204 | | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11| 2205 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2206 |Network Layer - AVB/TSN Eth.| +| +| +| +| +| +| +| +| +| +| +| 2207 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2208 |Central Administration | | | | | | +| +| +| +| +| +| 2209 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2210 |Hot Swap | | +| +| | | | | | | | +| 2211 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2212 |Data Flow Information Models| | | | | | | | | | | | 2213 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2214 |L2 and L3 Integration | | | | | | | | | | | | 2215 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2216 |End-to-end Delivery | +| +| +| +| +| +| +| +| +| | +| 2217 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2218 |Proprietary Deterministic | | | +| | | +| +| +| +| | | 2219 |Ethernet Networks | | | | | | | | | | | | 2220 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2221 |Replacement for Proprietary | | | +| | | +| +| +| +| | | 2222 |Fieldbuses | | | | | | | | | | | | 2223 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2224 |Deterministic vs. Best- | | | +| | | | | | | | | 2225 |Effort Traffic | | | | | | | | | | | | 2226 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2227 |Deterministic Flows | +| +| +| | +| +| | +| | | | 2228 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2229 |Unused Reserved Bandwidth | | +| +| | | | | +| +| | | 2230 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2231 |Interoperability | | | | | | | | | | | | 2232 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2233 |Cost Reductions | | | | | | | | | | | | 2234 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2235 |Insufficiently Secure | | | | | | | | | | | | 2236 |Components | | | | | | | | | | | | 2237 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2238 |DetNet Network Size | +| | | | | +| +| | | | +| 2239 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2240 |Multiple Hops | +| +| | | | +| +| | | | +| 2241 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2242 |Level of Service | | | | | | | | +| +| +| | 2243 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2244 |Bounded Latency | +| | | | | | | | | | +| 2245 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2246 |Low Latency | +| | | | | | | +| +| | +| 2247 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2248 |Bounded Jitter | +| | | | | | | | | | | 2249 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2250 |Symmetric Path Delays | +| | | | | | | | | | +| 2251 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2252 |Reliability and Availability| +| +| +| +| +| +| +| +| +| +| +| 2253 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2254 |Redundant Paths | | | | +| +| | | +| +| | | 2255 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2256 |Security Measures | | | | | | | | | | | | 2257 +----------------------------+--+--+--+--+--+--+--+--+--+--+--+ 2259 Figure 5: Mapping Between Themes and Attacks 2261 8.3. Security Considerations for OAM Traffic 2263 This section considers DetNet-specific security considerations for 2264 packet traffic that is generated and transmitted over a DetNet as 2265 part of OAM (Operations, Administration, and Maintenance). For the 2266 purposes of this discussion, OAM traffic falls into one of two basic 2267 types: 2269 o OAM traffic generated by the network itself. The additional 2270 bandwidth required for such packets is added by the network 2271 administration, presumably transparent to the customer. Security 2272 considerations for such traffic are not DetNet-specific (apart 2273 from such traffic being subject to the same DetNet-specific 2274 security considerations as any other DetNet data flow) and are 2275 thus not covered in this document. 2277 o OAM traffic generated by the customer. From a DetNet security 2278 point of view, DetNet security considerations for such traffic are 2279 exactly the same as for any other customer data flows. 2281 From the perspective of an attack, OAM traffic is indistinguishable 2282 from DetNet traffic and the network needs to be secure against 2283 injection, removal, or modification of traffic of any kind, including 2284 OAM traffic. A DetNet is sensitive to any form of packet injection, 2285 removal or manipulation and in this respect DetNet OAM traffic is no 2286 different. Techniques for securing a DetNet against these threats 2287 have been discussed elsewhere in this document. 2289 9. DetNet Technology-Specific Threats 2291 Section 5, Security Threats, described threats which are independent 2292 of a DetNet implementation. This section considers threats 2293 specifically related to the IP- and MPLS-specific aspects of DetNet 2294 implementations. 2296 The primary security considerations for the data plane specifically 2297 are to maintain the integrity of the data and the delivery of the 2298 associated DetNet service traversing the DetNet network. 2300 The primary relevant differences between IP and MPLS implementations 2301 are in flow identification and OAM methodologies. 2303 As noted in [RFC8655], DetNet operates at the IP layer ( [RFC8939]) 2304 and delivers service over sub-layer technologies such as MPLS 2305 ([RFC8938]) and IEEE 802.1 Time-Sensitive Networking (TSN) 2306 ([I-D.ietf-detnet-ip-over-tsn]). Application flows can be protected 2307 through whatever means are provided by the layer and sub-layer 2308 technologies. For example, technology-specific encryption may be 2309 used, for example for IP flows, IPSec [RFC4301]. For IP over 2310 Ethernet (Layer 2) flows using an underlying sub-net, MACSec 2311 [IEEE802.1AE-2018] may be appropriate. For some use cases packet 2312 integrity protection without encryption may be sufficient. 2314 However, if the DetNet nodes cannot decrypt IPsec traffic, then 2315 DetNet flow identification for encrypted IP traffic flows must be 2316 performed in a different way than it would be for unencrypted IP 2317 DetNet flows. The DetNet IP Data Plane identifies unencrypted flows 2318 via a 6-tuple that consists of two IP addresses, the transport 2319 protocol ID, two transport protocol port numbers and the DSCP in the 2320 IP header. When IPsec is used, the transport header is encrypted and 2321 the next protocol ID is an IPsec protocol, usually ESP, and not a 2322 transport protocol, leaving only three components of the 6-tuple, 2323 which are the two IP addresses and the DSCP. If the IPsec sessions 2324 are established by a controller, then this controller could also 2325 transmit (in the clear) the Security Parameter Index (SPI) and thus 2326 the SPI could be used (in addition to the pair of IP addresses) for 2327 flow identification. Identification of DetNet flows over IPsec is 2328 further discussed in Section 5.1.2.3. of [RFC8939]. 2330 Sections below discuss threats specific to IP and MPLS in more 2331 detail. 2333 9.1. IP 2335 The IP protocol has a long history of security considerations and 2336 architectural protection mechanisms. From a data plane perspective 2337 DetNet does not add or modify any IP header information, so the 2338 carriage of DetNet traffic over an IP data plane does not introduce 2339 any new security issues that were not there before, apart from those 2340 already described in the data-plane-independent threats section 2341 Section 5, Security Threats. 2343 Thus the security considerations for a DetNet based on an IP data 2344 plane are purely inherited from the rich IP Security literature and 2345 code/application base, and the data-plane-independent section of this 2346 document. 2348 Maintaining security for IP segments of a DetNet may be more 2349 challenging than for the MPLS segments of the network, given that the 2350 IP segments of the network may reach the edges of the network, which 2351 are more likely to involve interaction with potentially malevolent 2352 outside actors. Conversely MPLS is inherently more secure than IP 2353 since it is internal to routers and it is well-known how to protect 2354 it from outside influence. 2356 Another way to look at DetNet IP security is to consider it in the 2357 light of VPN security; as an industry we have a lot of experience 2358 with VPNs running through networks with other VPNs, it is well known 2359 how to secure the network for that. However for a DetNet we have the 2360 additional subtlety that any possible interaction of one packet with 2361 another can have a potentially deleterious effect on the time 2362 properties of the flows. So the network must provide sufficient 2363 isolation between flows, for example by protecting the forwarding 2364 bandwidth and related resources so that they are available to detnet 2365 traffic, by whatever means are appropriate for the data plane of that 2366 network, for example through the use of queueing mechanisms. 2368 In a VPN, bandwidth is generally guaranteed over a period of time, 2369 whereas in DetNet it is not aggregated over time. This implies that 2370 any VPN-type protection mechanism must also maintain the DetNet 2371 timing constraints. 2373 9.2. MPLS 2375 An MPLS network carrying DetNet traffic is expected to be a "well- 2376 managed" network. Given that this is the case, it is difficult for 2377 an attacker to pass a raw MPLS encoded packet into a network because 2378 operators have considerable experience at excluding such packets at 2379 the network boundaries, as well as excluding MPLS packets being 2380 inserted through the use of a tunnel. 2382 MPLS security is discussed extensively in [RFC5920] ("Security 2383 Framework for MPLS and GMPLS Networks") to which the reader is 2384 referred. 2386 [RFC6941] builds on [RFC5920] by providing additional security 2387 considerations that are applicable to the MPLS-TP extensions 2388 appropriate to the MPLS Transport Profile [RFC5921], and thus to the 2389 operation of DetNet over some types of MPLS network. 2391 [RFC5921] introduces to MPLS new Operations, Administration, and 2392 Maintenance (OAM) capabilities, a transport-oriented path protection 2393 mechanism, and strong emphasis on static provisioning supported by 2394 network management systems. 2396 The operation of DetNet over an MPLS network is modeled on the 2397 operation of multi-segment pseudowires (MS-PW). Thus for guidance on 2398 securing the DetNet elements of DetNet over MPLS the reader is 2399 referred to the security considerations of [RFC8077], [RFC3931], 2400 [RFC3985], [RFC6073], and [RFC6478]. 2402 Having attended to the conventional aspects of network security it is 2403 necessary to attend to the dynamic aspects. The closest experience 2404 that the IETF has with securing protocols that are sensitive to 2405 manipulation of delay are the two way time transfer protocols (TWTT), 2406 which are NTP [RFC5905] and Precision Time Protocol [IEEE1588]. The 2407 security requirements for these are described in [RFC7384]. 2409 One particular problem that has been observed in operational tests of 2410 TWTT protocols is the ability for two closely but not completely 2411 synchronized flows to beat and cause a sudden phase hit to one of the 2412 flows. This can be mitigated by the careful use of a scheduling 2413 system in the underlying packet transport. 2415 Some investigations into protection of MPLS systems against dynamic 2416 attacks exist, such as [I-D.ietf-mpls-opportunistic-encrypt]; perhaps 2417 deployment of DetNets will encourage additional such investigations. 2419 10. IANA Considerations 2421 This document includes no requests from IANA. 2423 11. Security Considerations 2425 The security considerations of DetNet networks are presented 2426 throughout this document. 2428 12. Privacy Considerations 2430 Privacy in the context of DetNet is maintained by the base 2431 technologies specific to the DetNet and user traffic. For example 2432 TSN can use MACsec, IP can use IPsec, applications can use IP 2433 transport protocol-provided methods e.g. TLS and DTLS. MPLS 2434 typically uses L2/L3 VPNs combined with the previously mentioned 2435 privacy methods. 2437 However, note that reconnaissance threats such as traffic analysis 2438 and monitoring of electrical side channels can still cause there to 2439 be privacy considerations even when traffic is encrypted. 2441 13. Contributors 2443 The Editor would like to recognize the contributions of the following 2444 individuals to this draft. 2446 Subir Das (Applied Communication Sciences) 2447 150 Mount Airy Road, Basking Ridge, New Jersey, 07920, USA 2448 email sdas@appcomsci.com 2450 John Dowdell (Airbus Defence and Space) 2451 Celtic Springs, Newport, NP10 8FZ, United Kingdom 2452 email john.dowdell.ietf@gmail.com 2454 Henrik Austad (SINTEF Digital) 2455 Klaebuveien 153, Trondheim, 7037, Norway 2456 email henrik@austad.us 2458 Norman Finn (Huawei) 2459 3101 Rio Way, Spring Valley, California 91977, USA 2460 email nfinn@nfinnconsulting.com 2462 Stewart Bryant (Futurewei Technologies) 2464 email: stewart.bryant@gmail.com 2466 David Black (Dell EMC) 2467 176 South Street, Hopkinton, MA 01748, USA 2468 email: david.black@dell.com 2470 Carsten Bormann (Universitat Bremen TZI) 2471 Postfach 330440, D-28359 Bremen, Germany 2472 email: cabo@tzi.org 2474 14. References 2476 14.1. Normative References 2478 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 2479 "Deterministic Networking Architecture", RFC 8655, 2480 DOI 10.17487/RFC8655, October 2019, 2481 . 2483 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. 2484 Bryant, "Deterministic Networking (DetNet) Data Plane 2485 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, 2486 . 2488 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. 2489 Bryant, "Deterministic Networking (DetNet) Data Plane: 2490 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, 2491 . 2493 14.2. Informative References 2495 [ARINC664P7] 2496 ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics 2497 Full-Duplex Switched Ethernet Network", 2009. 2499 [I-D.ietf-detnet-flow-information-model] 2500 Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 2501 Fedyk, "DetNet Flow and Service Information Model", draft- 2502 ietf-detnet-flow-information-model-14 (work in progress), 2503 January 2021. 2505 [I-D.ietf-detnet-ip-oam] 2506 Mirsky, G., Chen, M., and D. Black, "Operations, 2507 Administration and Maintenance (OAM) for Deterministic 2508 Networks (DetNet) with IP Data Plane", draft-ietf-detnet- 2509 ip-oam-01 (work in progress), January 2021. 2511 [I-D.ietf-detnet-ip-over-mpls] 2512 Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. 2513 Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- 2514 detnet-ip-over-mpls-09 (work in progress), October 2020. 2516 [I-D.ietf-detnet-ip-over-tsn] 2517 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 2518 Data Plane: IP over IEEE 802.1 Time Sensitive Networking 2519 (TSN)", draft-ietf-detnet-ip-over-tsn-05 (work in 2520 progress), December 2020. 2522 [I-D.ietf-detnet-mpls-oam] 2523 Mirsky, G. and M. Chen, "Operations, Administration and 2524 Maintenance (OAM) for Deterministic Networks (DetNet) with 2525 MPLS Data Plane", draft-ietf-detnet-mpls-oam-02 (work in 2526 progress), January 2021. 2528 [I-D.ietf-detnet-mpls-over-udp-ip] 2529 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 2530 Bryant, "DetNet Data Plane: MPLS over UDP/IP", draft-ietf- 2531 detnet-mpls-over-udp-ip-08 (work in progress), December 2532 2020. 2534 [I-D.ietf-detnet-yang] 2535 Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and 2536 Z. Li, "Deterministic Networking (DetNet) Configuration 2537 YANG Model", draft-ietf-detnet-yang-09 (work in progress), 2538 November 2020. 2540 [I-D.ietf-ipsecme-g-ikev2] 2541 Smyslov, V. and B. Weis, "Group Key Management using 2542 IKEv2", draft-ietf-ipsecme-g-ikev2-02 (work in progress), 2543 January 2021. 2545 [I-D.ietf-mpls-opportunistic-encrypt] 2546 Farrel, A. and S. Farrell, "Opportunistic Security in MPLS 2547 Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work 2548 in progress), March 2017. 2550 [I-D.varga-detnet-service-model] 2551 Varga, B. and J. Farkas, "DetNet Service Model", draft- 2552 varga-detnet-service-model-02 (work in progress), May 2553 2017. 2555 [IEEE1588] 2556 IEEE, "IEEE 1588 Standard for a Precision Clock 2557 Synchronization Protocol for Networked Measurement and 2558 Control Systems Version 2", 2008. 2560 [IEEE802.1AE-2018] 2561 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 2562 Security (MACsec)", 2018, 2563 . 2565 [IEEE802.1BA] 2566 IEEE Standards Association, "IEEE Standard for Local and 2567 Metropolitan Area Networks -- Audio Video Bridging (AVB) 2568 Systems", 2011, 2569 . 2571 [IEEE802.1Q] 2572 IEEE Standards Association, "IEEE Standard for Local and 2573 metropolitan area networks--Bridges and Bridged Networks - 2574 Annex J - Connectivity Fault Management", 2014, 2575 . 2577 [IEEE802.1Qbv-2015] 2578 IEEE Standards Association, "IEEE Standard for Local and 2579 metropolitan area networks -- Bridges and Bridged Networks 2580 - Amendment 25: Enhancements for Scheduled Traffic", 2015, 2581 . 2583 [IEEE802.1Qch-2017] 2584 IEEE Standards Association, "IEEE Standard for Local and 2585 metropolitan area networks--Bridges and Bridged Networks-- 2586 Amendment 29: Cyclic Queuing and Forwarding", 2017, 2587 . 2589 [IETF_YANG_SEC] 2590 IETF, "YANG Module Security Considerations", 2018, 2591 . 2594 [IT_DEF] Wikipedia, "IT Definition", 2020, 2595 . 2597 [OT_DEF] Wikipedia, "OT Definition", 2020, 2598 . 2600 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2601 "Definition of the Differentiated Services Field (DS 2602 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2603 DOI 10.17487/RFC2474, December 1998, 2604 . 2606 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2607 and W. Weiss, "An Architecture for Differentiated 2608 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 2609 . 2611 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 2612 Text on Security Considerations", BCP 72, RFC 3552, 2613 DOI 10.17487/RFC3552, July 2003, 2614 . 2616 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 2617 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 2618 RFC 3931, DOI 10.17487/RFC3931, March 2005, 2619 . 2621 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 2622 Edge-to-Edge (PWE3) Architecture", RFC 3985, 2623 DOI 10.17487/RFC3985, March 2005, 2624 . 2626 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 2627 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 2628 June 2005, . 2630 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2631 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 2632 January 2006, . 2634 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2635 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2636 December 2005, . 2638 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2639 DOI 10.17487/RFC4302, December 2005, 2640 . 2642 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 2643 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 2644 March 2006, . 2646 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 2647 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 2648 . 2650 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 2651 "Network Time Protocol Version 4: Protocol and Algorithms 2652 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 2653 . 2655 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 2656 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 2657 . 2659 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 2660 L., and L. Berger, "A Framework for MPLS in Transport 2661 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 2662 . 2664 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 2665 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 2666 DOI 10.17487/RFC6071, February 2011, 2667 . 2669 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 2670 Aissaoui, "Segmented Pseudowire", RFC 6073, 2671 DOI 10.17487/RFC6073, January 2011, 2672 . 2674 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 2675 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 2676 . 2678 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 2679 "Pseudowire Status for Static Pseudowires", RFC 6478, 2680 DOI 10.17487/RFC6478, May 2012, 2681 . 2683 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 2684 Variable Bit Rate Audio with Secure RTP", RFC 6562, 2685 DOI 10.17487/RFC6562, March 2012, 2686 . 2688 [RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF 2689 Network Management Standards", RFC 6632, 2690 DOI 10.17487/RFC6632, June 2012, 2691 . 2693 [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., 2694 and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) 2695 Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2696 2013, . 2698 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 2699 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 2700 October 2014, . 2702 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 2703 Recommendations Regarding Active Queue Management", 2704 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 2705 . 2707 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2708 Application Protocol (CoAP)", RFC 7641, 2709 DOI 10.17487/RFC7641, September 2015, 2710 . 2712 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2713 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2714 2016, . 2716 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 2717 Separation Protocol (LISP) Threat Analysis", RFC 7835, 2718 DOI 10.17487/RFC7835, April 2016, 2719 . 2721 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 2722 Maintenance Using the Label Distribution Protocol (LDP)", 2723 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 2724 . 2726 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2727 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2728 . 2730 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 2731 RFC 8578, DOI 10.17487/RFC8578, May 2019, 2732 . 2734 [RS_DEF] Wikipedia, "RS Definition", 2020, 2735 . 2737 Authors' Addresses 2739 Ethan Grossman (editor) 2740 Dolby Laboratories, Inc. 2741 1275 Market Street 2742 San Francisco, CA 94103 2743 USA 2745 Phone: +1 415 465 4339 2746 Email: ethan@ieee.org 2747 URI: http://www.dolby.com 2749 Tal Mizrahi 2750 Huawei Network.IO Innovation Lab 2752 Email: tal.mizrahi.phd@gmail.com 2754 Andrew J. Hacker 2755 MistIQ Technologies, Inc 2756 Harrisburg, PA 2757 USA 2759 Email: ajhacker@mistiqtech.com