idnits 2.17.1 draft-fink-coin-sec-priv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1508 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-kunze-coin-industrial-use-cases-01 == Outdated reference: A later version (-02) exists of draft-kutscher-coinrg-dir-01 == Outdated reference: A later version (-05) exists of draft-reddy-opsawg-mud-tls-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COINRG I. Fink 3 Internet-Draft K. Wehrle 4 Intended status: Informational RWTH Aachen University 5 Expires: September 10, 2020 March 9, 2020 7 Enhancing Security and Privacy with In-Network Computing 8 draft-fink-coin-sec-priv-00 10 Abstract 12 With the growing interconnection of devices, cyber-security and data 13 protection are of increasing importance. This is especially the case 14 regarding cyber-physical systems due to their close entanglement with 15 the physical world. Misbehavior and information leakage can lead to 16 financial and physical damage and endanger human lives and well- 17 being. Thus, hard security and privacy requirements are necessary to 18 be met. Furthermore, thorough investigation of incidents is 19 essential for ultimate protection. In-network computing allows the 20 processing of traffic and data directly in the network and at line- 21 rate. Thus, the in-network computing paradigm presents a promising 22 solution for efficiently providing security and privacy mechanisms as 23 well as event analysis. This document discusses select mechanisms to 24 demonstrate how in-network computing concepts can be applied to 25 encounter current shortcomings of cyber-security and data privacy. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 10, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Protection Mechanisms . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Encryption and Integrity Checking . . . . . . . . . . . . 4 64 2.2. Authorization and Authentication . . . . . . . . . . . . 4 65 2.3. Behavioral and Enterprise Policies . . . . . . . . . . . 5 66 2.4. Anonymization . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Intrusion and Anomaly Detection . . . . . . . . . . . . . . . 7 68 3.1. Intrusion Detection . . . . . . . . . . . . . . . . . . . 7 69 3.2. Dead man's switch . . . . . . . . . . . . . . . . . . . . 7 70 4. Incident Reappraisal . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Several deficiencies emerge from cyber-physical systems (CPS) such as 80 the (Industrial) Internet of Things (IoT). Everyday things are 81 equipped with sensors and CPUs to allow for automatization and make 82 life more comfortable. The deployment of additional sensors supports 83 the processing efficiency in Industrial Control Systems (ICS). The 84 entanglement of the sensors with the physical world leads to a high 85 sensitivity of the transmitted and collected data. At the same time, 86 devices are increasingly connected to the Internet to enable, e.g., 87 processing of data on cloud servers or exchange with other systems. 89 Devices in CPS are often resource-constrained and do not offer the 90 possibility to implement elaborate security mechanisms. Furthermore, 91 legacy devices and communication protocols are often still in use in 92 industrial networks but were not designed to face the security and 93 privacy challenges the new interconnection brings. Thus, 94 communication and access are often unprotected, providing new attack 95 surfaces with severe consequences: leakage of private data endangers 96 the users' privacy. The leakage of business secrets bears the risk 97 of severe financial damage. Manipulation of ICSs can lead to 98 downtimes in the best case or, financially worse, faulty production 99 results. Last, the failure of CPS can lead to personal injury or 100 even death. As a consequence of the described risks, we need 101 security and privacy measures tailored to the new situation. 102 Upgrading legacy devices with protection mechanisms is an effortful 103 and expensive procedure. A promising approach for retrofitting 104 security nevertheless is the deployment of suitable mechanisms within 105 the network. To date, this is mainly realized using middle-boxes, 106 leading to overhead and need for additional hardware. 108 While proper prevention and detection of attacks in the (Industrial) 109 IoT is an unresolved issue, the after-treatment of incidents in 110 networks offers room for improvement in general. We can use network 111 forensics to retrace and comprehend the origin and course of 112 malicious events. However, realization requires high effort and 113 costs in traditional networks. 115 The common problem of all shortcomings is that traditional networking 116 devices only allow for fixed-function deployment. Software-defined 117 networking (SDN) enables more flexible traffic handling in the 118 network by separating control and data plane. However, the use of 119 fixed-function switches still restricts primary approaches like 120 OpenFlow. Those switches match traffic against a fixed set of 121 protocol headers to decide if and where it should be forwarded. 122 Furthermore, consultation of the remote control plane leads to 123 communication overhead and delays, which is especially unfavorable in 124 the context of time-sensitive applications, e.g., in industry. 126 INC, in contrast, covers the shortfalls of traditional networks and 127 SDN by allowing actual programming of the switches. This 128 programmability leads to dynamic and custom processing of network 129 packets at line-rate. Thus, security-related functions and packet 130 inspection can be implemented and applied right at the switch. 132 This draft explores the opportunities of INC for improving security 133 and privacy as follows: we first describe feasible mechanisms for 134 preventing attacks and intrusion in the first place. Then, we 135 present which mechanisms we can implement with INC for detecting 136 intrusion and undesired behavior when it has already taken place. 137 Last, we explore how INC can improve network forensics for analyzing 138 and following up incidents, which helps to prevent future attacks. 140 2. Protection Mechanisms 142 The common ground for providing security and data privacy is to 143 protect against unauthorized access. That protection is primarily 144 provided by deploying the basic security mechanisms encryption, 145 integrity checking, authentication, and authorization. Those are 146 especially often missing in resource-constrained environments. 147 [RFC7744] thoroughly discusses the need for authentication and 148 authorization in resource-restrained environments. [RFC8576] 149 presents security and privacy risks and challenges specific to the 150 IoT. In the following, we describe how INC can help to retrofit 151 suitable mechanisms. 153 2.1. Encryption and Integrity Checking 155 Encryption is critical to preserve confidentiality when transmitting 156 data. Integrity checks prevent undetected manipulation, which can 157 remain unnoticed even despite encryption, e.g., in case of flipped 158 bits. Due to resource-constraints, many devices in CPS do not 159 provide encryption or calculation of check-sums. 161 Complex cryptography is not supported by current programmable 162 switches either. However, this might change in the future, which 163 would allow retrofitting encryption and integrity checks at 164 networking devices. Concretely, using INC with suitable hardware, 165 data could be encrypted and supplemented with a check-sum directly at 166 the first networking device passed by the respective data packet. 167 The packet is then forwarded through the network or Internet to its 168 designated destination. Decryption and integrity checks can be 169 executed at the last networking device before the destination. 170 Alternatively, this can be implemented at the destination if 171 supported by the respective device. This approach does not require 172 deployment or forwarding to additional middleboxes. Thus, no 173 additional attack surface or processing overhead is introduced, which 174 is essential for time-sensitive processes as often at hand in 175 industry. 177 Overall, INC has the potential to help maintain confidentiality and 178 integrity efficiently, and thus the availability of resource- 179 constrained or legacy devices. Questions to clarify are if and at 180 which costs hardware for enabling cryptographic calculations could 181 and should be embedded in future generations of programmable 182 networking devices. 184 2.2. Authorization and Authentication 186 Authorization and authentication mechanisms are needed to avoid 187 unauthorized access to devices and their manipulation in the first 188 place. With INC, networking devices can flexibly decide whether to 189 forward packets, thus enforce authorization and authentication 190 checks. 192 One possibility for authorization is to conduct a handshake between 193 the sender and networking device before starting the communication 194 with the industrial device. If not feasible in switch hardware, the 195 respective calculations can be conducted in the control plane. In 196 the case of success, the sender is added to a list of authorized 197 communication partners. The decision is then enforced by the switch. 198 Since authorization is only needed when starting or refreshing a 199 connection, the necessity and overhead for consulting the control 200 plane are limited. 202 The sender can append a secret token for authentication to packets 203 directed to an industrial device. Then, the last networking device 204 can authenticate the sender and forward the actual data only in case 205 of success and drop it otherwise. One possibility to avoid 206 eavesdropping of the token is the use of hash chains. Secure 207 reinitialization can again be done using the control plane, which 208 usually has the resources for conducting encrypted communication. 210 In the case of unsuccessful authorization or authentication, 211 networking devices can inform the network administrator about 212 possible intrusion of the system. 214 Undesired traffic can emerge even from authorized and authenticated 215 devices. A solution is to add policy-based access control, on which 216 we elaborate in the next subsection. 218 2.3. Behavioral and Enterprise Policies 220 Control processes can include communication between various parties. 221 Even despite authorization and authentication mechanisms, undesired 222 behavior can occur. For instance, malicious third-party software 223 might be installed at the approved device. Regarding communication 224 between two legacy devices, authentication might not be possible at 225 all. An effective way to exclude malicious behavior nevertheless is 226 policy-based access control. 228 [RFC8520] proposes the Manufacturer Usage Description (MUD), a 229 standard for defining the communication behavior of IoT devices, 230 which use specific communication patterns. The definition is 231 primarily based on domain names, ports, and use of protocols (e.g., 232 TCP and UDP). Further characteristics as the TLS usage 233 [I-D.draft-reddy-opsawg-mud-tls-03] or the required bandwidth of a 234 device [I-D.draft-lear-opsawg-mud-bw-profile-01] can help to define 235 connections more narrowly. 237 By defining the typical behavior, we can exclude deviating 238 communication, including undesired behavior. Likewise to IoT 239 devices, industrial devices usually serve a specific purpose. Thus, 240 the application of MUD or similar policies is possible in industrial 241 scenarios as well. 243 The problem that remains to date is the efficient enforcement of such 244 policies in the form of fine-granular and flexible traffic filtering. 245 While middle-boxes increase costs and processing overhead, primary 246 SDN approaches as OpenFlow allow only filtering based on match-action 247 rules regarding fixed protocol header fields. Evaluation of traffic 248 statistics for, e.g., limiting the bandwidth, requires consultation 249 of the remote controller. This leads to latency overheads, which are 250 not acceptable in time-sensitive scenarios. 252 In contrast, the INC paradigm allows flexible filtering even 253 concerning the content of packets and connection metadata. 254 Furthermore, traffic filtering can be executed at line-rate in the 255 switch. 257 Going one step further, not only network communication behavior of 258 devices can be defined in policies. As [KANG] shows, INC can be used 259 to consider additional (contextual) parameters, e.g., the time of day 260 or activity of other devices in the network. Furthermore, companies 261 can define advanced policies to, e.g., authorize specific users or 262 subnets. 264 Additional protection of data is needed to preserve business secrets 265 and the privacy of individuals. We show in the following subsection 266 how INC can contribute to data anonymization. 268 2.4. Anonymization 270 Due to its interconnection with the physical world, the generation of 271 sensitive data is inherent to CPS. Smart infrastructure leads to the 272 collection of sensitive user data. In industrial networks, 273 information about confidential processes is gathered. Such data is 274 increasingly shared with other entities to increase production 275 efficiency or enable automatic processing. 277 Despite the benefits of data exchange, manufacturers, as well as 278 individuals, might not want to share sensitive information. Again, 279 deployment of privacy mechanisms is usually not possible at resource- 280 constrained or legacy devices. INC has the potential to flexibly 281 apply privacy mechanisms at line-rate. 283 Data can be pseudonymized at networking devices by, e.g., extracting 284 and replacing specific values. Furthermore, elaborate anonymization 285 techniques can be implemented in the network by sensibly decreasing 286 the data accuracy. For example, concepts like k-Anonymity can be 287 applied by aggregating the values of multiple packets before 288 forwarding the result. Noise addition can be implemented by adding a 289 random number to values. Similarly, the state-of-the-art technique 290 differential privacy can be implemented by adding noise to responses 291 to statistical requests. 293 Even though the INC paradigm shows the potential to deploy described 294 privacy mechanisms within the network, research is needed to clarify 295 the feasibility of the proposed concepts. 297 3. Intrusion and Anomaly Detection 299 Ideally, attacks are prevented from the outset. However, in the case 300 of incidents, fast detection is critical for limiting damage. 301 Deployment of sensors, e.g., in industrial control systems, can help 302 to monitor the system state and detect anomalies. This can be used 303 in combination with INC to detect intrusion as well as to provide 304 advanced safety measures, as described in the following. 306 3.1. Intrusion Detection 308 Data of sensors or communication behavior can be compared against 309 expected patterns to detect intrusion. Even if intrusion prevention 310 is deployed and connections are allowed when taken individually, 311 subtle attacks might still be possible. In this case, e.g., a series 312 of values might be again out of line if considered at large. Anomaly 313 detection can be used to detect such abnormalities and notify the 314 network administrator for further assessment. 316 While anomaly detection is usually outsourced to middleboxes or 317 external servers, INC provides the possibility to detect anomalies 318 at-line rate, e.g., by maintaining statistics about traffic flows. 319 This decreases costs and latency, which is valuable for a prompt 320 reaction. 322 Besides intrusion, anomalies can also imply safety risks. In the 323 following, we pick up the potential of INC to support safety. 325 3.2. Dead man's switch 327 [I-D.draft-kunze-coin-industrial-use-cases-01] addresses the 328 potential of INC for improving industrial safety. Detection of an 329 anomaly in the sensor data or operational flow can be used to 330 automatically trigger an emergency shutdown of a system or single 331 components if the data indicates an actual hazard. Apart from that, 332 other safety measures like warning systems or isolation of areas can 333 be implemented. While we do not aim at replacing traditional dead 334 man's switches, we see the potential of INC to accelerate the 335 detection of failures. Thus, INC can valuably complement existing 336 safety measures. 338 4. Incident Reappraisal 340 After the detection and treatment of an incident, it is important to 341 conduct Network Forensics to investigate the origin and spreading of 342 the related activity. The results of this analysis can be used to 343 adapt protection mechanisms and prevent similar events in the future. 344 For enabling potential investigation, traffic records are constantly 345 collected for each flow in a network. This requires additional 346 hardware in traditional networks. Furthermore, it might be 347 preferable to exclude, e.g., specific subnets from the analysis. 348 This is not possible with traditional networking devices, leading to 349 storage and processing overhead. 351 With INC, flow records can be created directly at the switch when 352 forwarding a packet. Furthermore, record generation can be done more 353 flexibly, e.g., by applying fine-granular traffic filtering. Also, 354 header fields of particular interest can be efficiently extracted. 355 Therefore, INC can considerably decrease the load and increase the 356 efficiency of network forensics. This leads in turn to a better 357 understanding of attacks and security. 359 5. Security Considerations 361 When implementing security and privacy measures in networking 362 devices, security and failure resistance of the networking devices 363 themselves is critical. Related research questions to clarify in the 364 future are stated in [I-D.draft-kutscher-coinrg-dir-01]. 366 6. IANA Considerations 368 N/A 370 7. Conclusion 372 In-network computing has the potential to improve and retrofit 373 security and privacy, especially in concern of resource-restrained 374 and legacy devices. 376 First, INC can provide intrusion prevention mechanisms like 377 authentication and efficient enforcement of (context-based) policies. 378 Encryption and integrity checks are limited by the current hardware 379 but might be realizable in the future. 381 Second, INC allows examining packet contents at networking devices, 382 which can be used to implement fast anomaly and intrusion detection 383 in the network. 385 Last, INC can contribute to an efficient and targeted incident 386 analysis. 388 Investigation of the feasibility of the presented mechanisms is 389 subject to future research. 391 8. Informative References 393 [I-D.draft-kunze-coin-industrial-use-cases-01] 394 Kunze, I. and K. Wehrle, "Industrial Use Cases for In- 395 Network Computing", draft-kunze-coin-industrial-use- 396 cases-01 (work in progress), November 2019. 398 [I-D.draft-kutscher-coinrg-dir-01] 399 Kutscher, D., Karkkainen, T., and J. Ott, "Directions for 400 Computing in the Network", draft-kutscher-coinrg-dir-01 401 (work in progress), November 2019. 403 [I-D.draft-lear-opsawg-mud-bw-profile-01] 404 Lear, E. and O. Friel, "Bandwidth Profiling Extensions for 405 MUD", draft-lear-opsawg-mud-bw-profile-01 (work in 406 progress), July 2019. 408 [I-D.draft-reddy-opsawg-mud-tls-03] 409 Reddy, T., Wing, D., and B. Anderson, "MUD (D)TLS profiles 410 for IoT devices", draft-reddy-opsawg-mud-tls-03 (work in 411 progress), January 2019. 413 [KANG] Kang, Q., Morrison, A., Tang, Y., Chen, A., and X. Luo, 414 "Programmable In-Network Security for Context-aware BYOD 415 Policies", In Proceedings of the 29th USENIX Security 416 Symposium (USENIX Security 20), August 2020, 417 . 420 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 421 and S. Kumar, "Use Cases for Authentication and 422 Authorization in Constrained Environments", RFC 7744, 423 DOI 10.17487/RFC7744, January 2016, 424 . 426 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 427 Description Specification", RFC 8520, 428 DOI 10.17487/RFC8520, March 2019, 429 . 431 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 432 Things (IoT) Security: State of the Art and Challenges", 433 RFC 8576, DOI 10.17487/RFC8576, April 2019, 434 . 436 Authors' Addresses 438 Ina Berenice Fink 439 RWTH Aachen University 440 Ahornstr. 55 441 Aachen D-52062 442 Germany 444 Phone: +49-241-80-21419 445 Email: fink@comsys.rwth-aachen.de 447 Klaus Wehrle 448 RWTH Aachen University 449 Ahornstr. 55 450 Aachen D-52062 451 Germany 453 Phone: +49-241-80-21401 454 Email: wehrle@comsys.rwth-aachen.de