--- 1/draft-ietf-detnet-security-07.txt 2020-02-03 22:14:22.250329496 -0800 +++ 2/draft-ietf-detnet-security-08.txt 2020-02-03 22:14:22.342331828 -0800 @@ -1,29 +1,29 @@ Internet Engineering Task Force T. Mizrahi Internet-Draft HUAWEI Intended status: Informational E. Grossman, Ed. -Expires: July 13, 2020 DOLBY +Expires: August 6, 2020 DOLBY A. Hacker MISTIQ S. Das Applied Communication Sciences J. Dowdell Airbus Defence and Space H. Austad SINTEF Digital N. Finn HUAWEI - January 10, 2020 + February 3, 2020 Deterministic Networking (DetNet) Security Considerations - draft-ietf-detnet-security-07 + draft-ietf-detnet-security-08 Abstract A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years. However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies @@ -46,21 +46,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 13, 2020. + This Internet-Draft will expire on August 6, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -92,82 +92,82 @@ 3.2.6.1. Control or Signaling Packet Modification . . . . 9 3.2.6.2. Control or Signaling Packet Injection . . . . . . 9 3.2.7. Scheduling or Shaping . . . . . . . . . . . . . . . . 9 3.2.7.1. Reconnaissance . . . . . . . . . . . . . . . . . 9 3.2.8. Time Synchronization Mechanisms . . . . . . . . . . . 9 3.3. Threat Summary . . . . . . . . . . . . . . . . . . . . . 9 4. Security Threat Impacts . . . . . . . . . . . . . . . . . . . 10 4.1. Delay-Attacks . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Data Plane Delay Attacks . . . . . . . . . . . . . . 13 - 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 13 + 4.1.2. Control Plane Delay Attacks . . . . . . . . . . . . . 14 4.2. Flow Modification and Spoofing . . . . . . . . . . . . . 14 4.2.1. Flow Modification . . . . . . . . . . . . . . . . . . 14 4.2.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2.1. Dataplane Spoofing . . . . . . . . . . . . . . . 14 - 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 14 + 4.2.2.2. Control Plane Spoofing . . . . . . . . . . . . . 15 4.3. Segmentation attacks (injection) . . . . . . . . . . . . 15 4.3.1. Data Plane Segmentation . . . . . . . . . . . . . . . 15 4.3.2. Control Plane segmentation . . . . . . . . . . . . . 15 - 4.4. Replication and Elimination . . . . . . . . . . . . . . . 15 - 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 15 + 4.4. Replication and Elimination . . . . . . . . . . . . . . . 16 + 4.4.1. Increased Attack Surface . . . . . . . . . . . . . . 16 4.4.2. Header Manipulation at Elimination Bridges . . . . . 16 4.5. Control or Signaling Packet Modification . . . . . . . . 16 4.6. Control or Signaling Packet Injection . . . . . . . . . . 16 4.7. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 - 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 16 - 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 16 + 4.8. Attacks on Time Sync Mechanisms . . . . . . . . . . . . . 17 + 4.9. Attacks on Path Choice . . . . . . . . . . . . . . . . . 17 5. Security Threat Mitigation . . . . . . . . . . . . . . . . . 17 5.1. Path Redundancy . . . . . . . . . . . . . . . . . . . . . 17 5.2. Integrity Protection . . . . . . . . . . . . . . . . . . 17 5.3. DetNet Node Authentication . . . . . . . . . . . . . . . 18 5.4. Dummy Traffic Insertion . . . . . . . . . . . . . . . . . 18 - 5.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.5. Encryption . . . . . . . . . . . . . . . . . . . . . . . 19 5.5.1. Encryption Considerations for DetNet . . . . . . . . 19 5.6. Control and Signaling Message Protection . . . . . . . . 20 - 5.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 20 + 5.7. Dynamic Performance Analytics . . . . . . . . . . . . . . 21 5.8. Mitigation Summary . . . . . . . . . . . . . . . . . . . 21 - 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 22 - 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 22 - 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 22 - 6.1.2. Central Administration . . . . . . . . . . . . . . . 23 - 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 23 - 6.1.4. Data Flow Information Models . . . . . . . . . . . . 24 - 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 24 - 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 24 + 6. Association of Attacks to Use Cases . . . . . . . . . . . . . 23 + 6.1. Use Cases by Common Themes . . . . . . . . . . . . . . . 23 + 6.1.1. Network Layer - AVB/TSN Ethernet . . . . . . . . . . 23 + 6.1.2. Central Administration . . . . . . . . . . . . . . . 24 + 6.1.3. Hot Swap . . . . . . . . . . . . . . . . . . . . . . 24 + 6.1.4. Data Flow Information Models . . . . . . . . . . . . 25 + 6.1.5. L2 and L3 Integration . . . . . . . . . . . . . . . . 25 + 6.1.6. End-to-End Delivery . . . . . . . . . . . . . . . . . 25 6.1.7. Proprietary Deterministic Ethernet Networks . . . . . 25 - 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 25 - 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 25 - 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 26 - 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 26 + 6.1.8. Replacement for Proprietary Fieldbuses . . . . . . . 26 + 6.1.9. Deterministic vs Best-Effort Traffic . . . . . . . . 26 + 6.1.10. Deterministic Flows . . . . . . . . . . . . . . . . . 27 + 6.1.11. Unused Reserved Bandwidth . . . . . . . . . . . . . . 27 6.1.12. Interoperability . . . . . . . . . . . . . . . . . . 27 6.1.13. Cost Reductions . . . . . . . . . . . . . . . . . . . 27 - 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 27 - 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 27 + 6.1.14. Insufficiently Secure Devices . . . . . . . . . . . . 28 + 6.1.15. DetNet Network Size . . . . . . . . . . . . . . . . . 28 6.1.16. Multiple Hops . . . . . . . . . . . . . . . . . . . . 28 - 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 28 + 6.1.17. Level of Service . . . . . . . . . . . . . . . . . . 29 6.1.18. Bounded Latency . . . . . . . . . . . . . . . . . . . 29 - 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 29 - 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 29 - 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 29 + 6.1.19. Low Latency . . . . . . . . . . . . . . . . . . . . . 30 + 6.1.20. Bounded Jitter (Latency Variation) . . . . . . . . . 30 + 6.1.21. Symmetrical Path Delays . . . . . . . . . . . . . . . 30 6.1.22. Reliability and Availability . . . . . . . . . . . . 30 - 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 30 - 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 30 + 6.1.23. Redundant Paths . . . . . . . . . . . . . . . . . . . 31 + 6.1.24. Security Measures . . . . . . . . . . . . . . . . . . 31 6.2. Attack Types by Use Case Common Theme . . . . . . . . . . 31 - 6.3. Security Considerations for OAM Traffic . . . . . . . . . 33 - 7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 33 - 7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 10. Informative References . . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 + 6.3. Security Considerations for OAM Traffic . . . . . . . . . 34 + 7. DetNet Technology-Specific Threats . . . . . . . . . . . . . 34 + 7.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 7.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 10. Informative References . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction Security is of particularly high importance in DetNet networks because many of the use cases which are enabled by DetNet [RFC8578] include control of physical devices (power grid components, industrial controls, building controls) which can have high operational costs for failure, and present potentially attractive targets for cyber-attackers. @@ -460,21 +460,23 @@ 4. Security Threat Impacts This section describes and rates the impact of the attacks described in Section 3. In this section, the impacts as described assume that the associated mitigation is not present or has failed. Mitigations are discussed in Section 5. In computer security, the impact (or consequence) of an incident can be measured in loss of confidentiality, integrity or availability of - information. + information. In the case of time sensitive networks, the impact of a + network exploit can also include failure or malfunction of mechanical + and/or other OT systems. DetNet raises these stakes significantly for OT applications, particularly those which may have been designed to run in an OT-only environment and thus may not have been designed for security in an IT environment with its associated devices, services and protocols. The severity of various components of the impact of a successful vulnerability exploit to use cases by industry is available in more detail in [RFC8578]. Each of the use cases in the DetNet Use Cases is represented in the table below, including Pro Audio, Electrical @@ -585,20 +587,24 @@ Figure 2: Impact of Attacks by Use Case Industry The rest of this section will cover impact of the different groups in more detail. 4.1. Delay-Attacks 4.1.1. Data Plane Delay Attacks + Note that 'delay attack' also includes the possibility of a 'negative + delay' or early arrival of a packet, or possibly adversely changing + the timestamp value. + Delayed messages in a DetNet link can result in the same behavior as dropped messages in ordinary networks as the services attached to the stream has strict deterministic requirements. For a single path scenario, disruption is a real possibility, whereas in a multipath scenario, large delays or instabilities in one stream can lead to increased buffer and CPU resources on the elimination bridge. A data-plane delay attack on a system controlling substantial moving @@ -769,20 +776,25 @@ attacks. Related attacks Path redundancy can be used to mitigate various man-in-the-middle attacks, including attacks described in Section 3.2.1, Section 3.2.2, Section 3.2.3, and Section 3.2.8. However it is also possible that multiple paths may make it more difficult to locate the source of a MITM attacker. + A delay modulation attack could result in extensively exercising + parts of the code that wouldn't normally be extensively exercised + and thus might expose flaws in the system that might otherwise not + be exposed. + 5.2. Integrity Protection Description An integrity protection mechanism, such as a Hash-based Message Authentication Code (HMAC) can be used to mitigate modification attacks on IP packets. Integrity protection in the control plane is discussed in Section 5.6. Packet Sequence Number Integrity Considerations @@ -837,25 +848,29 @@ Related attacks Removing distinctive temporal properties of individual packets or flows can be used to mitigate against reconnaissance attacks Section 3.2.7. 5.5. Encryption Description - DetNet flows can be forwarded in encrypted form at the DetNet - layer. Alternatively, if the payload is end-to-end encrypted at - the application layer, the DetNet nodes should not have any need - to inspect the payload itself, and thus the DetNet implementation - can be data-agnostic. + + DetNet flows can in principle be forwarded in encrypted form at + the DetNet layer, however, regarding encryption of IP headers see + Section 7. + + Alternatively, if the payload is end-to-end encrypted at the + application layer, the DetNet nodes should not have any need to + inspect the payload itself, and thus the DetNet implementation can + be data-agnostic. Related attacks Encryption can be used to mitigate recon attacks (Section 3.2.7). However, for a DetNet network to give differentiated quality of service on a flow-by-flow basis, the network must be able to identify the flows individually. This implies that in a recon attack the attacker may also be able to track individual flows to learn more about the system. @@ -863,21 +878,23 @@ Any compute time which is required for encryption and decryption processing ('crypto') must be included in the flow latency calculations. Thus, crypto algorithms used in a DetNet must have bounded worst-case execution times, and these values must be used in the latency calculations. Some crypto algorithms are symmetric in encode/decode time (such as AES) and others are asymmetric (such as public key algorithms). There are advantages and disadvantages to the use of either type in a - given DetNet context. + given DetNet context. The discussion in this document relates to the + timing implications of crypto for DetNet; it is assumed that + integrity considerations are covered elsewhere in the literature. Asymmetrical crypto is typically not used in networks on a packet-by- packet basis due to its computational cost. For example, if only endpoint checks or checks at a small number of intermediate points are required, asymmetric crypto can be used to authenticate distribution or exchange of a secret symmetric crypto key; a successful check based on that key will provide traffic origin verification, as long as the key is kept secret by the participants. TLS and IKE (for IPsec) are examples of this for endpoint checks. @@ -913,51 +930,62 @@ Related attacks These mechanisms can be used to mitigate various attacks on the control plane, as described in Section 3.2.6, Section 3.2.8 and Section 3.2.5. 5.7. Dynamic Performance Analytics Description - Information about the network performance can be gathered in real- - time in order to detect anomalies and unusual behavior that may be - the symptom of a security attack. The gathered information can be - based, for example, on per-flow counters, bandwidth measurement, - and monitoring of packet arrival times. Unusual behavior or + The expectation is that the network will have a way to monitor to + detect if timing guarantees are not being met, and a way to alert + the control plane in that event. Information about the network + performance can be gathered in real-time in order to detect + anomalies and unusual behavior that may be the symptom of a + security attack. The gathered information can be based, for + example, on per-flow counters, bandwidth measurement, and + monitoring of packet arrival times. Unusual behavior or potentially malicious nodes can be reported to a management system, or can be used as a trigger for taking corrective actions. The information can be tracked by DetNet end systems and transit nodes, and exported to a management system, for example using NETCONF. Related attacks Performance analytics can be used to mitigate various attacks, including the ones described in Section 3.2.1 (Delay Attack), Section 3.2.3 (Resource Segmentation Attack), and Section 3.2.8 (Time Sync Attack). For example, in the case of data plane delay attacks, one possible mitigation is to timestamp the data at the source, and timestamp it again at the destination, and if the resulting latency exceeds the promised bound, discard that data and warn the operator (and/ - or enter a fail-safe mode). + or enter a fail-safe mode). Note that DetNet specifies packet + sequence numbering, however it does not specify use of packet + timestamps, although they may be used by the underlying transport + (for example TSN) to provide the service. 5.8. Mitigation Summary The following table maps the attacks of Section 3 to the impacts of Section 4, and to the mitigations of the current section. Each row specifies an attack, the impact of this attack if it is successfully implemented, and possible mitigation methods. + Editor's note: Is this tabular summary of the above information + useful or necessary in this draft? If we opt to maintain the tables + then the WG needs to validate them for completeness and correctness + after all other draft comments have been addressed. + +----------------------+---------------------+---------------------+ | Attack | Impact | Mitigations | +----------------------+---------------------+---------------------+ |Delay Attack |-Non-deterministic |-Path redundancy | | | delay |-Performance | | |-Data disruption | analytics | | |-Increased resource | | | | consumption | | +----------------------+---------------------+---------------------+ |Reconnaissance |-Enabler for other |-Encryption | @@ -1084,31 +1112,28 @@ (i.e. one heretofore unknown on the network) could be used to exploit the need to consider such packets (as opposed to rejecting them out of hand as one would do if one did not have to consider introduction of a new device). Similarly if the network was designed to support runtime replacement of a clock device, then presence (or apparent presence) and thus consideration of packets from a new such device could affect the network, or the time sync of the network, for example by initiating a new Best Master Clock selection process. Thus attacks on time sync - should be considered when designing hot swap type functionality. + should be considered when designing hot swap type functionality (see + [RFC7384]). 6.1.4. Data Flow Information Models - Data Flow Information Models specific to DetNet networks are to be - specified by DetNet. Thus they are "new" and thus potentially - present a new attack surface. Does the threat take advantage of any - aspect of our new Data Flow Info Models? - - This is TBD, thus there are no specific entries in our table, however - that does not imply that there could be no relevant attacks. + Data Flow Information Models specific to DetNet networks are + specified by DetNet, and thus are 'new' and thus potentially present + a new attack surface. 6.1.5. L2 and L3 Integration A DetNet network integrates Layer 2 (bridged) networks (e.g. AVB/TSN LAN) and Layer 3 (routed) networks via the use of well-known protocols such as IP, MPLS-PW, and Ethernet. There are no specific entries in our table, however that does not imply that there could be no relevant attacks related to L2,L3 integration. @@ -1165,35 +1190,35 @@ be opened. For example an Inter-Segment or Control plane attack such as Path Manipulation, Path Choice or Control Packet Modification/Injection could be used to exploit commands specific to such a protocol, or that are interpreted differently by the different protocols or gateway. 6.1.9. Deterministic vs Best-Effort Traffic + Most of the themes described in this document address OT (reserved) + streams - this item is intended to address issues related to IT + traffic on a DetNet. + DetNet is intended to support coexistence of time-sensitive operational (OT, deterministic) traffic and information (IT, "best effort") traffic on the same ("unified") network. With DetNet, this coexistance will become more common, and mitigations will need to be established. The fact that the IT traffic on a DetNet is limited to a corporate controlled network makes this a less difficult problem compared to being exposed to the open Internet, however this aspect of DetNet security should not be underestimated. - Most of the themes described in this document address OT (reserved) - streams - this item is intended to address issues related to IT - traffic on a DetNet. - An Inter-segment attack can flood the network with IT-type traffic with the intent of disrupting handling of IT traffic, and/or the goal of interfering with OT traffic. Presumably if the stream reservation and isolation of the DetNet is well-designed (better-designed than the attack) then interference with OT traffic should not result from an attack that floods the network with IT traffic. However the DetNet's handling of IT traffic may not (by design) be as resilient to DOS attack, and thus designers must be otherwise prepared to mitigate DOS attacks on IT traffic in a DetNet. @@ -1209,91 +1234,84 @@ deterministic flows. A Flow Modification or Spoofing or Header Manipulation or Control Packet Modification attack could cause packets from one flow to be directed to another flow, thus breaching isolation between the flows. 6.1.11. Unused Reserved Bandwidth If bandwidth reservations are made for a stream but the associated bandwidth is not used at any point in time, that bandwidth is made - available on the network for best-effort traffic. If the owner of - the reserved stream then starts transmitting again, the bandwidth is - no longer available for best-effort traffic, on a moment-to-moment - basis. (Such "temporarily available" bandwidth is not available for - time-sensitive traffic, which must have its own reservation). - - An Inter-segment attack could flood the network with IT traffic, - interfering with the intended IT traffic. - - A Flow Modification or Spoofing or Control Packet Modification or - Injection attack could cause extra bandwidth to be reserved by a new - or existing stream, thus making it unavailable for use by best-effort - traffic. + available on the network for best-effort traffic. However, note that + security considerations for best-effort traffic on a DetNet network + is out of scope of the present document, provided that such an attack + does not affect performance for DetNet OT traffic. 6.1.12. Interoperability The DetNet network specifications are intended to enable an ecosystem in which multiple vendors can create interoperable products, thus promoting device diversity and potentially higher numbers of each - device manufactured. Does the threat take advantage of differences - in implementation of "interoperable" products made by different - vendors? + device manufactured. - This is TBD, thus there are no specific entries in our table, however - that does not imply that there could be no relevant attacks. + Given that the DetNet specifications are unambiguously written and + that the implementations are accurate, then this should not in and of + itself cause a security concern; however, in the real world, it could + be. The network operator can mitigate this through sufficient + interoperability testing. 6.1.13. Cost Reductions The DetNet network specifications are intended to enable an ecosystem in which multiple vendors can create interoperable products, thus promoting higher numbers of each device manufactured, promoting cost - reduction and cost competition among vendors. Does the threat take - advantage of "low cost" HW or SW components or other "cost-related - shortcuts" that might be present in devices? + reduction and cost competition among vendors. Such "low cost" + hardware or software components might present security concerns. - This is TBD, thus there are no specific entries in our table, however - that does not imply that there could be no relevant attacks. + Network operators can mitigate such concerns through sufficient + product testing. 6.1.14. Insufficiently Secure Devices The DetNet network specifications are intended to enable an ecosystem in which multiple vendors can create interoperable products, thus promoting device diversity and potentially higher numbers of each - device manufactured. Does the threat attack "naivete" of SW, for - example SW that was not designed to be sufficiently secure (or secure - at all) but is deployed on a DetNet network that is intended to be - highly secure? (For example IoT exploits like the Mirai video-camera - botnet ([MIRAI]). + device manufactured. Software that was originally designed for + operation in isolated OT networks (and thus may not have been + designed to be sufficiently secure, or secure at all) but is then + deployed on a DetNet network that is intended to be highly secure may + present an attack surface. (For example IoT exploits like the Mirai + video-camera botnet ([MIRAI]). - This is TBD, thus there are no specific entries in our table, however - that does not imply that there could be no relevant attacks. + The DetNet network operator may need to take specific actions to + protect such devices. 6.1.15. DetNet Network Size DetNet networks range in size from very small, e.g. inside a single industrial machine, to very large, for example a Utility Grid network spanning a whole country. The size of the network might be related to how the attack is introduced into the network, for example if the entire network is local, there is a threat that power can be cut to the entire network. If the network is large, perhaps only a part of the network is attacked. A Delay attack might be as relevant to a small network as to a large network, although the amount of delay might be different. Attacks sourced from IT traffic might be more likely in large - networks, since more people might have access to the network. - Similarly Path Manipulation, Path Choice and Time Sync attacks seem - more likely relevant to large networks. + networks, since more people might have access to the network, + presenting a larger attack surface. Similarly Path Manipulation, + Path Choice and Time Sync attacks seem more likely relevant to large + networks. 6.1.16. Multiple Hops Large DetNet networks (e.g. a Utility Grid network) may involve many "hops" over various kinds of links for example radio repeaters, microwave links, fiber optic links, etc.. An attack that takes advantage of flaws (or even normal operation) in the device drivers for the various links (through internal knowledge of how the individual driver or firmware operates, perhaps like the @@ -1363,25 +1381,27 @@ Delay attacks can cause packets to vary in their arrival times, resulting in packet to packet latency variation, thereby violating the jitter specification. 6.1.21. Symmetrical Path Delays Some applications would like to specify that the transit delay time values be equal for both the transmit and return paths. - Delay attacks can cause path delays to differ. + Delay attacks can cause path delays to materially differ between + paths. Time Sync attacks can corrupt the system's time reference, resulting - in differing path delays (with respect to the "correct" time - reference). + in path delays that may be perceived to be different (with respect to + the "correct" time reference) even if they are not materially + different. 6.1.22. Reliability and Availability DetNet based systems are expected to be implemented with essentially arbitrarily high availability (for example 99.9999% up time, or even 12 nines). The intent is that the DetNet designs should not make any assumptions about the level of reliability and availability that may be required of a given system, and should define parameters for communicating these kinds of metrics within the network. @@ -1415,20 +1435,25 @@ This is TBD, thus there are no specific entries in our table, however that does not imply that there could be no relevant attacks. 6.2. Attack Types by Use Case Common Theme The following table lists the attacks of Section 3, assigning a number to each type of attack. That number is then used as a short form identifier for the attack in Figure 5. + Editor's note: Is this tabular summary of the above information + useful or necessary in this draft? If we opt to maintain the tables + then the WG needs to validate them for completeness and correctness + after all other draft comments have been addressed. + +--+----------------------------------------+----------------------+ | | Attack | Section | +--+----------------------------------------+----------------------+ | 1|Delay Attack | Section 3.2.1 | +--+----------------------------------------+----------------------+ | 2|DetNet Flow Modification or Spoofing | Section 3.2.2 | +--+----------------------------------------+----------------------+ | 3|Inter-Segment Attack | Section 3.2.3 | +--+----------------------------------------+----------------------+ | 4|Replication: Increased attack surface | Section 3.2.4.1 | @@ -1601,20 +1626,25 @@ with VPNs running through networks with other VPNs, it is well known how to secure the network for that. However for a DetNet we have the additional subtlety that any possible interaction of one packet with another can have a potentially deleterious effect on the time properties of the flows. So the network must provide sufficient isolation between flows, for example by protecting the forwarding bandwidth and related resources so that they are available to detnet traffic, by whatever means are appropriate for that network's data plane. + In a VPN, bandwidth is generally guaranteed over a period of time, + whereas in DetNet it is not aggregated over time. This implies that + any VPN-type protection mechanism must also maintain the DetNet + timing constraints. + 7.2. MPLS An MPLS network carrying DetNet traffic is expected to be a "well- managed" network. Given that this is the case, it is difficult for an attacker to pass a raw MPLS encoded packet into a network because operators have considerable experience at excluding such packets at the network boundaries, as well as excluding MPLS packets being inserted through the use of a tunnel. MPLS security is discussed extensively in [RFC5920] ("Security