idnits 2.17.00 (12 Aug 2021) /tmp/idnits15577/draft-fink-coin-sec-priv-03.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (22 October 2021) is 205 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-opsawg-mud-tls-05 == Outdated reference: A later version (-02) exists of draft-irtf-coinrg-use-cases-00 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: 25 April 2022 22 October 2021 7 Enhancing Security and Privacy with In-Network Computing 8 draft-fink-coin-sec-priv-03 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, a thorough investigation of incidents is 19 essential for ultimate protection. Computing in the Network (COIN) 20 allows the processing of traffic and data directly in the network and 21 at line-rate. Thus, COIN presents a promising solution for 22 efficiently providing security and privacy mechanisms as well as 23 network monitoring. This document discusses select mechanisms to 24 demonstrate how COIN concepts can be applied to counter existing 25 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 25 April 2022. 44 Copyright Notice 46 Copyright (c) 2021 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Protection Mechanisms . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Encryption and Integrity Checks . . . . . . . . . . . . . 4 63 2.2. Authentication and Authorization . . . . . . . . . . . . 5 64 2.3. Policies . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. In-Network Vulnerability Patches . . . . . . . . . . . . 7 66 2.5. Anonymization . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Intrusion and Anomaly Detection . . . . . . . . . . . . . . . 8 68 3.1. Intrusion Detection . . . . . . . . . . . . . . . . . . . 8 69 3.2. Dead Man's Switch . . . . . . . . . . . . . . . . . . . . 9 70 4. Network Monitoring . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Informative References . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 With the ongoing digitalization, previously isolated devices and 80 systems are increasingly connected to the Internet, concerning all 81 aspects of life. In particular, in the context of Cyber-Physical 82 Systems (CPS) and the (Industrial) Internet of Things, machines and 83 infrastructure are equipped with additional sensors and CPUs to allow 84 for automatization and higher processing efficiency. The 85 entanglement of the sensors with the physical world leads to high 86 sensitivity of the transmitted and collected data. 88 Consequently, digitalization expands the attack surface and the 89 possible impacts of cyber attacks, increasing the importance of 90 proper protection mechanisms. 92 Devices in CPS are often resource-constrained and do not offer the 93 possibility to implement elaborate security mechanisms. Furthermore, 94 legacy devices and communication protocols are often still used in 95 industrial networks but were not designed to face the security and 96 privacy challenges the new interconnection brings. Thus, 97 communication and access are often unprotected. 99 Upgrading legacy devices with protection mechanisms is an effortful 100 and expensive procedure. A promising approach for retrofitting 101 security is the deployment of suitable mechanisms within the network. 102 To date, this is mainly realized using middle-boxes, leading to 103 overhead and the need for additional hardware. 105 One general and widespread security component is Intrusion Detection 106 Systems (IDS) to detect and, ideally, prevent undesired events in a 107 network. However, IDS are usually implemented in software, again 108 running on middle-boxes or edge devices in the same network. Thus, 109 their reaction time is limited as well as their information gain, 110 which is usually addressed by deploying additional IDS components for 111 traffic monitoring. 113 Last, the after-treatment of incidents in networks is critical to 114 detect exploited vulnerabilities and prevent future attacks. Network 115 forensics serves to retrace and comprehend the origin and course of 116 malicious events. However, to provide high performance, the 117 underlying monitoring of network traffic requires dedicated 118 networking devices and/or expensive subscriptions to respective 119 features, leading to high costs. 121 One common problem is that security is usually provided by software 122 solutions. These often require additional hardware and lead to 123 performance overhead, which is especially unfavorable in the context 124 of time-sensitive applications, e.g., in industry. Existing high- 125 performance solutions, e.g., running on traditional networking 126 devices, require dedicated, costly, and unsustainable hardware. 128 Computing in the Network (COIN) covers these shortfalls by using 129 programmable networking devices to conduct dynamic and custom 130 processing of network packets at line-rate. Thus, security-related 131 functions and packet inspection can be implemented and applied 132 centrally in the network, e.g., at a programmable switch. 134 This draft explores the opportunities of COIN for improving security 135 and privacy as follows: We first describe feasible mechanisms for 136 preventing attacks and intrusion in the first place. Then, we 137 present which mechanisms we can implement with COIN for detecting 138 intrusion and undesired behavior when it has already taken place. 139 Last, we explore how COIN can improve network monitoring for 140 detecting, analyzing and following up incidents, thus fixing 141 vulnerabilities. 143 2. Protection Mechanisms 145 The common ground for providing security and data privacy is to 146 protect against unauthorized access. That protection is primarily 147 provided by basic security mechanisms such as encryption, integrity 148 checks, authentication, and authorization. These are often missing 149 in resource-constrained environments or regarding legacy industrial 150 devices. [RFC7744] thoroughly discusses the need for authentication 151 and authorization in resource-restrained environments. [RFC8576] 152 presents security and privacy risks and challenges specific to the 153 IoT. In the following, we describe how COIN can help to retrofit 154 suitable mechanisms. 156 2.1. Encryption and Integrity Checks 158 Encryption is critical to preserve confidentiality when transmitting 159 data. Integrity checks prevent undetected manipulation, which can 160 remain unnoticed even despite encryption, e.g., in case of flipped 161 bits. Due to resource-constraints, many devices in CPS do not 162 provide encryption or calculation of check-sums. 164 By default, secure cryptographic functions are not supported by 165 current programmable switches either and hard to realize due to their 166 computational constraints. However, there are efforts by researchers 167 to implement AES encryption with scrambled lookup tables [CHEN] and 168 cryptographically secure keyed hash functions [YOO] on existing 169 programmable hardware switches. Furthermore, future generations of 170 programmable hardware switches might provide secure cryptographic 171 functions by design. 173 With secure cryptography at hand, COIN would allow to encrypt and 174 hash packet contents efficiently while passing a respective 175 programmable networking device. Concretely, data could be encrypted 176 and supplemented with a check-sum directly at the first networking 177 device passed by a packet before forwarding it through the Internet 178 to its designated destination. Subsequent decryption and integrity 179 checks could be executed at the last networking device before the 180 destination. Alternatively, this could be implemented at the 181 destination if supported by the respective device. This approach 182 does not require deployment of or forwarding to additional middle- 183 boxes. Thus, no additional attack surface or processing overhead is 184 introduced, presenting a promising foundation for retrofitting 185 security in time-sensitive scenarios such as industrial processes. 187 Another use-case is the implementation of whole standards for secure 188 communication on programmable networking devices, offering new 189 flexibility. For example, researchers examined the benefits of 190 deploying IPsec and MACsec on programmable switches 191 [HAUSER-IPsec],[HAUSER-MACsec] but their implementations only target 192 software switches due to the missing cryptographic capabilities of 193 existing programmable hardware switches. 195 Future research is needed to clarify if and at which costs hardware 196 for enabling cryptographic calculations could and should be embedded 197 in future generations of programmable networking devices. 199 2.2. Authentication and Authorization 201 Authentication and authorization mechanisms are needed to avoid 202 unauthorized access to devices and their manipulation in the first 203 place. With COIN, networking devices can flexibly decide whether to 204 forward packets, thus offer efficient and fine-granular access 205 control. 207 One possibility is to conduct a handshake between the sender and 208 networking device before starting the communication with industrial 209 devices. Cryptographic calculations (e.g. required for certificate- 210 based authentication) can be offloaded to the control plane if not 211 feasible in the data plane of the networking device due to 212 computational constraints. Existing research also proposed and 213 implemented authentication in the data plane, e.g., using port- 214 knocking [ALMAINI]. Authorization information can be stored in 215 tables in the data plane or requested from the control plane. Since 216 authentication and authorization is only needed when starting or 217 refreshing a connection, the necessity and overhead for consulting 218 the control plane are limited. Subsequent to the authentication and 219 authorization process, the respective decisions can be flexibly 220 enforced by the networking device. For example, different fine- 221 granular policies can be linked to different authorization levels and 222 different devices. In the case of unsuccessful authorization or 223 authentication, networking devices can inform the network 224 administrator about possible intrusion of the system. 226 Overall, COIN can realize efficient and flexible access control, 227 reducing overhead and attack surface. 229 2.3. Policies 231 Control processes can include communication between various parties. 232 Even despite authorization and authentication mechanisms, undesired 233 behavior can occur. For instance, malicious third-party software 234 might be installed on the approved device and thus implicitly gain 235 access. Depending on the involved devices and their capabilities, 236 proper authorization and authentication might not be possible at all. 237 An effective way to exclude malicious behavior nevertheless is 238 policy-based access control. 240 [RFC8520] proposes the Manufacturer Usage Description (MUD), a 241 standard for defining the communication behavior of IoT devices, 242 which use specific communication patterns. The definition is 243 primarily based on domain names, ports, and protocols (e.g., TCP and 244 UDP). Further characteristics as the TLS usage 245 [I-D.draft-ietf-opsawg-mud-tls-05] or the required bandwidth of a 246 device [I-D.draft-lear-opsawg-mud-bw-profile-01] can help to define 247 connections more narrowly. By defining the typical behavior, we can 248 exclude deviating communication, including undesired behavior. 249 Likewise to IoT devices, industrial devices usually serve a specific 250 purpose. Thus, applying MUD or similar policies is viable in 251 industrial scenarios as well. 253 The problem that remains is the efficient enforcement of such 254 policies through fine-granular and flexible traffic filtering. While 255 middle-boxes increase costs and processing overhead, primary SDN 256 approaches as OpenFlow allow only filtering based on match-action 257 rules regarding fixed protocol header fields. Evaluation of traffic 258 statistics for, e.g., limiting the bandwidth, requires consultation 259 of the remote controller. This leads to latency overheads, which are 260 not acceptable in time-sensitive scenarios. 262 In contrast, the COIN paradigm allows flexible filtering even 263 concerning the content of packets and connection metadata. 264 Furthermore, traffic filtering can be executed by programmable 265 networking devices at line-rate. 267 Last, not only network communication behavior of devices can be 268 defined in policies. For example, COIN can be also used to consider 269 additional (contextual) parameters, e.g., the time of day or activity 270 of other devices in the network [KANG]. 272 2.4. In-Network Vulnerability Patches 274 Resource-constrained devices are typically hard to update. Thus, 275 device vulnerabilities often cannot be fixed after deployment. As a 276 remedy and special case of policies, rules could be defined to 277 describe known attack signatures. By enforcing these rules at 278 programmable networking devices, e.g., by dropping matching traffic, 279 COIN would offer an efficient way to avoid exploitation of device 280 vulnerabilities. Another potential advantage is the easy and 281 extensive roll-out of such "in-network patches" in the form of 282 (automatic) software updates of the networking device. 284 Future research is needed to evaluate the potential and benefits of 285 in-network patches compared to traditional security measures, e.g., 286 firewalls, and provide proof of concepts using existing devices and 287 vulnerabilities. 289 2.5. Anonymization 291 Due to their interconnection with the physical world, the generation 292 of sensitive data is inherent to CPS. Smart infrastructure leads to 293 the collection of sensitive (user) data. In industrial networks, 294 information about confidential processes is gathered. Such data is 295 increasingly shared with other entities to increase production 296 efficiency or enable automatic processing. 298 Despite the benefits of data exchange, manufacturers and individuals 299 might not want to share sensitive information. While deployment of 300 privacy mechanisms is usually not possible at resource-constrained or 301 legacy devices, COIN has the potential to apply privacy mechanisms in 302 a flexible and comprehensive manner. 304 Data could be pseudonymized at networking devices by, e.g., 305 extracting and replacing specific values. Furthermore, elaborate 306 anonymization techniques could be implemented in the network by 307 sensibly decreasing the data accuracy. For example, concepts like 308 k-Anonymity could be applied by aggregating the values of multiple 309 packets before forwarding the result. Noise addition could be 310 implemented by adding a random number to values. Similarly, the 311 state-of-the-art technique differential privacy could be implemented 312 by adding noise to responses to statistical requests. 314 Indeed, recent research exploits programmable hardware switches to 315 implement performant and light-weight anonymization of communication 316 by rewriting source addresses and information and hiding path 317 information, e.g., using randomization [MOGHADDAM]. Similarly, 318 [WANG] realizes traffic obfuscation by encrypting IPv4 addresses in 319 the data plane. 321 Future research is needed to implement and evaluate further privacy 322 mechanisms and COIN's potential for this field. 324 3. Intrusion and Anomaly Detection 326 Ideally, attacks are prevented from the outset. However, in the case 327 of incidents, fast detection is critical for limiting damage. 328 Deployment of sensors, e.g., in industrial control systems, can help 329 to monitor the system state and detect anomalies. This can be used 330 in combination with COIN to detect intrusion and to provide advanced 331 safety measures, as described in the following. 333 3.1. Intrusion Detection 335 Data of sensors or monitored communication behavior can be compared 336 against expected patterns to detect intrusion. Even if intrusion 337 prevention is deployed and connections are allowed when taken 338 individually, subtle attacks might still be possible. For example, a 339 series of values might be out of line if put into context even though 340 the individual values are unobtrusive. Anomaly detection can be used 341 to detect such abnormalities and notify the network administrator for 342 further assessment. 344 While intrusion detection systems (IDS) are usually deployed at 345 middle-boxes or external servers, COIN provides the possibility to 346 detect anomalies at-line rate, e.g., by maintaining statistics about 347 traffic flows. This decreases costs and latency, which is valuable 348 for a prompt reaction. Another advantage is that one central 349 networking device can monitor traffic from multiple devices. In 350 contrast, multiple distributed middle boxes are usually needed to 351 achieve the same information gain. Last, programmable networking 352 devices can be used to preprocess traffic and reduce load on 353 subsequent in IDS components as examined by [LEWIS]. 355 Besides intrusion, anomalies can also imply safety risks. In the 356 following, we pick up the potential of COIN to support safety. 358 3.2. Dead Man's Switch 360 [I-D.draft-irtf-coinrg-use-cases-00] addresses the potential of COIN 361 for improving industrial safety. Detection of an anomaly in the 362 sensor data or operational flow can be used to automatically trigger 363 an emergency shutdown of a system or single system components if the 364 data indicates an actual hazard. Apart from that, other safety 365 measures like warning systems or isolation of areas can be 366 implemented. While we do not aim at replacing traditional dead man's 367 switches, we see the potential of COIN to accelerate the detection of 368 failures. Thus, COIN can valuably complement existing safety 369 measures. 371 4. Network Monitoring 373 After detecting an incident, it is essential to investigate its 374 origin and scope. The results of this analysis can be used to allow 375 for consistent recovery, to adapt protection mechanisms, and prevent 376 similar events in the future. For enabling potential investigation, 377 traffic is constantly captured (e.g., in the form of flow records), 378 which requires dedicated hardware in large networks. Furthermore, it 379 might be preferable to exclude traffic, e.g., from specific subnets, 380 from the analysis. Dynamic and fine-granular traffic filtering is 381 not possible with traditional networking devices, leading to storage 382 and processing overhead. 384 With COIN, networking devices can be programmed to export traffic 385 characteristics without significant overhead when forwarding a 386 packet. Furthermore, monitoring can be done more flexibly, e.g., by 387 applying fine-granular traffic filtering. Also, header fields of 388 particular interest can be efficiently extracted. Therefore, COIN 389 can considerably decrease the load and increase the efficiency of 390 security-related network monitoring. 392 The presented prospects are underlined by recent work. For example, 393 in [SONCHACK], flow records are created in the control plane of 394 programmable hardware switches while expensive packet preprocessing 395 is offloaded to the data plane. 397 5. Security Considerations 399 When implementing security and privacy measures in networking 400 devices, their security and failure resistance is critical. Related 401 research questions to clarify in the future are stated in 402 [I-D.draft-kutscher-coinrg-dir-02]. 404 6. IANA Considerations 406 N/A 408 7. Conclusion 410 COIN has the potential to improve and retrofit security and privacy, 411 especially with regard to resource-restrained and legacy devices. 413 First, COIN can provide intrusion prevention mechanisms like 414 authentication and efficient enforcement of (context-based) policies. 415 Easily deployable in-network patches of device vulnerabilities could 416 further improve security. Encryption and integrity checks are 417 limited by the current hardware but already targeted by recent 418 research. 420 Second, COIN allows examining packet contents at networking devices, 421 which can help implement fast and comprehensive anomaly and intrusion 422 detection. 424 Last, COIN can contribute to an efficient and targeted traffic 425 monitoring for incident analysis. 427 Further investigation of the feasibility and potential of the 428 presented mechanisms is subject to future research. 430 8. Informative References 432 [ALMAINI] Almaini, A., Al-Dubai, A., Romdhani, I., Schramm, M., and 433 A. Alsarhan, "Lightweight edge authentication for software 434 defined networks", Computing 103, 291-311 (2021), August 435 2020, . 438 [CHEN] Chen, X., "Implementing AES Encryption on Programmable 439 Switches via Scrambled Lookup Tables", In Proceedings of 440 the Workshop on Secure Programmable Network 441 Infrastructure, August 2020, 442 . 444 [HAUSER-IPsec] 445 Hauser, F., Häberle, M., Schmidt, M., and M. Menth, 446 "P4-IPsec: Site-to-Site and Host-to-Site VPN With IPsec in 447 P4-Based SDN", In IEEE Access, vol. 8, July 2020, 448 . 450 [HAUSER-MACsec] 451 Hauser, F., Häberle, M., Schmidt, M., and M. Menth, 452 "P4-MACsec: Dynamic Topology Monitoring and Data Layer 453 Protection With MACsec in P4-Based SDN", In IEEE Access, 454 vol. 8, March 2020, 455 . 457 [I-D.draft-ietf-opsawg-mud-tls-05] 458 Reddy, T., Wing, D., and B. Anderson, "Manufacturer Usage 459 Description (MUD) (D)TLS Profiles for IoT Devices", Work 460 in Progress, Internet-Draft, draft-ietf-opsawg-mud-tls-05, 461 27 July 2021, . 464 [I-D.draft-irtf-coinrg-use-cases-00] 465 Kunze, I., Wehrle, K., Trossen, D., and M.J. Montpetit, 466 "Use Cases for In-Network Computing", Work in Progress, 467 Internet-Draft, draft-irtf-coinrg-use-cases-00, 17 468 February 2021, . 471 [I-D.draft-kutscher-coinrg-dir-02] 472 Kutscher, D., Karkkainen, T., and J. Ott, "Directions for 473 Computing in the Network", Work in Progress, Internet- 474 Draft, draft-kutscher-coinrg-dir-02, 31 July 2020, 475 . 478 [I-D.draft-lear-opsawg-mud-bw-profile-01] 479 Lear, E. and O. Friel, "Bandwidth Profiling Extensions for 480 MUD", Work in Progress, Internet-Draft, draft-lear-opsawg- 481 mud-bw-profile-01, 8 July 2019, 482 . 485 [KANG] Kang, Q., Morrison, A., Tang, Y., Chen, A., and X. Luo, 486 "Programmable In-Network Security for Context-aware BYOD 487 Policies", In Proceedings of the 29th USENIX Security 488 Symposium (USENIX Security 20), August 2020, 489 . 492 [LEWIS] Lewis, B., Broadbent, A., and N. Race, "P4ID: P4 Enhanced 493 Intrusion Detection", 2019 IEEE Conference on Network 494 Function Virtualization and Software Defined Networks 495 (NFV-SDN), November 2019, 496 . 498 [MOGHADDAM] 499 Moghaddam, H. and A. Mosenia, "Programmable In-Network 500 Obfuscation of Traffic", arXiv:1911.09642 [cs.CR], 501 November 2019, . 503 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 504 and S. Kumar, "Use Cases for Authentication and 505 Authorization in Constrained Environments", RFC 7744, 506 DOI 10.17487/RFC7744, January 2016, 507 . 509 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 510 Description Specification", RFC 8520, 511 DOI 10.17487/RFC8520, March 2019, 512 . 514 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 515 Things (IoT) Security: State of the Art and Challenges", 516 RFC 8576, DOI 10.17487/RFC8576, April 2019, 517 . 519 [SONCHACK] Sonchack, J., Aviv, A., Keller, E., and J. Smith, 520 "Turboflow: Information Rich Flow Record Generation on 521 Commodity Switches", In Proceedings of the Thirteenth 522 EuroSys Conference, April 2018, 523 . 525 [WANG] Wang, L., Kim, H., Mittal, P., and J. Rexford, 526 "Programmable In-Network Obfuscation of Traffic", 527 arXiv:2006.00097 [cs.NI], 2020, 528 . 530 [YOO] Yoo, S. and X. Chen, "Secure Keyed Hashing on Programmable 531 Switches", In Proceedings of the ACM SIGCOMM 2021 Workshop 532 on Secure Programmable Network INfrastructure, August 533 2021, . 535 Authors' Addresses 537 Ina Berenice Fink 538 RWTH Aachen University 539 Ahornstr. 55 540 D-52062 Aachen 541 Germany 543 Phone: +49-241-80-21419 544 Email: fink@comsys.rwth-aachen.de 545 Klaus Wehrle 546 RWTH Aachen University 547 Ahornstr. 55 548 D-52062 Aachen 549 Germany 551 Phone: +49-241-80-21401 552 Email: wehrle@comsys.rwth-aachen.de