idnits 2.17.1 draft-park-sfc-malicious-middlebox-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 2, 2020) is 1212 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group CT. NGUYEN 3 Internet-Draft M. Park 4 Intended status: Informational Soongsil University 5 Expires: June 5, 2021 December 2, 2020 7 Detecting Malicious Middleboxes In Service Function Chaining 8 draft-park-sfc-malicious-middlebox-00 10 Abstract 12 This document addresses problems caused by malicious middleboxes and 13 proposes a scheme that can detect them in Service Function Chaining 14 (SFC) by combining two mechanisms: direct and indirect. The direct 15 mechanism injects a tool into the middleboxes to observe and report 16 the state of each middlebox. In contrast, the indirect mechanism 17 creates a probe service chain, which includes trustful middleboxes, 18 to investigate the operation of other middleboxes in the network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 5, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Attack Models . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Detection Methods . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Direct Method: Injection of Malicious Detecting Tool . . 4 60 5.2. Indirect Method: Probe Chain Generation . . . . . . . . . 5 61 6. Informative References . . . . . . . . . . . . . . . . . . . 5 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Service Function Chaining (SFC) creates on-demand ordered chains of 68 network services (e.g., the load balancer, firewalls, and network 69 address translation), and uses the chains to steer the network 70 traffic to ensure that the network is agile and effective. Service 71 functions run as middleboxes, which are connected to switches in the 72 network, and SFC connects these switches to create the required 73 virtual chains. 75 Because of the virtual attributes obtained from SDN and NFV, SFC is 76 prone to encounter various security vulnerabilities, especially 77 malicious middleboxes. In particular, attackers can modify the 78 service functions that run on the middlebox or inject malicious code 79 into the middlebox to perform harmful actions. Malicious middleboxes 80 can create various attack types that exploit the weaknesses of both 81 SDN and NFV to disrupt the operation and policy of SFC. With respect 82 to the SDN, malicious middleboxes can attack the control and data 83 plane by launching distributed denial-of-service (DDoS) attacks, 84 abusing computing resources, or incorrectly managing the network 85 traffic. With respect to the NFV, malicious middleboxes can attack 86 the infrastructure of other middleboxes, or even user equipment or 87 the network by injecting malware, spoofing or sniffing data, carrying 88 out denial-of-service (DoS) attacks, misusing shared resources, 89 violating the privacy and confidentiality, etc. 91 Many countermeasures have been proposed to protect the network from 92 these attacks, by either analyzing the network traffic or by 93 installing programs in virtual machines (VMs) to collect data 94 generated by the hardware to discover the attacks. However, in the 95 SFC environment, these solutions still have limitations and 96 vulnerabilities because they only focus on a specific type of attacks 97 and their mechanisms can be detected and compromised by attackers. 98 This document proposes a scheme that can detect malicious middleboxes 99 in SFC and is able to overcome the limitation of other methods. The 100 proposed scheme functions by two mechanisms: direct and indirect, 101 which make it possible to detect attacks launched both from the 102 inside and outside of middleboxes. The direct mechanism injects a 103 tool into the middleboxes to observe and report the state of each 104 middlebox. This tool can discover abnormal action by detecting high 105 resource consumption processes or determine whether an abnormal 106 process is installed. On the other hand, the indirect mechanism 107 creates a probe service chain, which includes trustful middleboxes, 108 to investigate the operation of other middleboxes in the network. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Attack Models 118 In a network, a middlebox is typically created with a fresh operating 119 system and service functions, except when the middlebox is created 120 from a malicious image. To perform attacks, attackers either need to 121 compromise the normal service functions or inject malicious programs 122 into middleboxes. The malicious middleboxes then acquire the ability 123 to drop received packets, duplicate them to place additional burden 124 on the next-hop middlebox (packet dropping, multiplying attack) or 125 forward packets incorrectly to other middleboxes or even to attackers 126 (eavesdropping, man-in-the-middle attacks). Furthermore, malicious 127 middleboxes can run redundant processes, which abuses the resources 128 of the middlebox and affects the operation of other service functions 129 inside the middlebox. This document focused on solving the following 130 attack situations: packet dropping, multiplying, eavesdropping, man- 131 in-the-middle, and resource abusing attacks as shown in Figure 1. We 132 assume that controllers, switches, and the connections between them 133 are trustful. Attackers who succeed in gaining access to controllers 134 or switches could exploit the network information and destroy all the 135 detection and prevention mechanisms. 137 +--------+ 50% +-----------+ +--------+ 200% +-----------+ 138 | switch |<-------| malicious | | switch |<-------| malicious | 139 | |------->| middlebox | | |------->| middlebox | 140 +--------+ 100% +-----------+ +--------+ 100% +-----------+ 142 (a) Packet dropping attack (b) Packet multiplying attack 144 +----------+ +----------------------------------+ 145 | attacker |<------+ | +-----------+ +---------+ | 146 +----------+ | | | malicious |-+ | normal | | 147 | | | | program | |-+ | service | | 148 +--------+ | +-----------+ | +-----------+ | | | function| | 149 | switch |<--+ | malicious | | +------------+ | +---------+ | 150 | |------->| middlebox | | +-------------+ | 151 +--------+ +-----------+ +----------------------------------+ 153 (c) Eavesdropping, (d) Packet multiplying attack 154 man-in-the-middle attack 156 Figure 1: Attack Models 158 4. Methodology 160 Our proposed scheme creates and injects a malicious tracking tool 161 into middleboxes to detect the attacks. By tracking the device 162 information (the number of processes, CPU and memory usage of each 163 process, network traffic on a network interface, etc.), the tool can 164 detect the above types of attacks. It contains the following three 165 components: (1) Resource Observation Module tracks the number of 166 processes and resources consumed by each process and sends the 167 results to the Analyzing Module.; (2) Packet Observation Module 168 tracks the network traffic on network interfaces (the number of 169 packets entering and exiting, transmission latency, etc.) and sends 170 the results to the Analyzing Module.; (3) Analyzing Module, which is 171 based on the tracking results from other modules, decides and raises 172 alarms to the controller about any irregularities in the operation of 173 middleboxes. 175 5. Detection Methods 177 5.1. Direct Method: Injection of Malicious Detecting Tool 179 As mentioned above, a middlebox is normally created or defined with a 180 fresh operating system. If attackers were to modify the service 181 function or inject malicious programs into middleboxes to perform 182 attacks, this action could leave a trace. For example, if an 183 abnormal process was installed on the middlebox, this process would 184 consume a significant amount of CPU and memory because of harmful 185 actions (e.g., packet handling or packet forwarding), which would be 186 easy to detect by observing the resource usage of the computer. On 187 the other hand, if the service functions were to be modified to 188 launch attacks, this action could also be detected by comparing the 189 typical resource consumption between similar middleboxes. Other 190 malicious actions could be discovered by observing the network 191 traffic on network interfaces (e.g., packet dropping or multiplying 192 attacks). Our proposed method is designed to inject and run the 193 malicious tracking tool on middleboxes to detect the above-mentioned 194 types of attacks. To reduce the overhead for middleboxes, we can run 195 this program either in a random period or run it consecutively to 196 perform real-time detection. All of the detection results are sent 197 to the controller. 199 5.2. Indirect Method: Probe Chain Generation 201 In the event of our malicious tracking tool being detected and even 202 compromised to spoof the detecting results, our direct method and 203 other proposed solutions would not be effective. We therefore 204 decided to use another approach to solve this problem. We created 205 two trustful middleboxes and connected them to another middlebox to 206 form a probe service chain. We also installed a malicious tracking 207 tool in the trustful middleboxes to observe the network traffic. 208 This approach entails using the malicious tracking tool to analyze 209 the network traffic to discover attacks. The trustful middleboxes 210 are regenerated periodically to prevent the potential protection from 211 being compromised, and the middlebox under testing is also chosen 212 randomly. 214 For example, in a chain including Middlebox_1, Middlebox_x, and 215 Middlebox_2 in a row, 100 packets are sent from trustful Middlebox_1 216 to under testing Middlebox_x. These packets are intended to be 217 processed by the service function inside Middlebox_x and then be 218 forwarded to next-hop trustful Middlebox_2. After a period, if 219 $Middlebox_2$ receives only 90 packets (packet dropping attack), or 220 150 packets (packet multiplying attack), or receives a packet after a 221 longer time than usual, this may be a man-in-the-middle or an 222 eavesdropping attack. The detection results are also sent to the 223 controller. 225 6. Informative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", RFC 2119, March 1997. 230 Appendix A. Acknowledgements 232 This work was supported by Institute for Information & communications 233 Technology Promotion(IITP) grant funded by the Korea government(MSIT) 234 (No.2018-0-00254, SDN security technology development). 236 Authors' Addresses 238 Canh Thang Nguyen 239 School of Electronic Engineering 240 Soongsil University 241 369, Sangdo-ro, Dongjak-gu 242 Seoul, Seoul 06978 243 Republic of Korea 245 Phone: +82 2 828 7175 246 EMail: nct@ssu.ac.kr 248 Minho Park 249 School of Electronic Engineering 250 Soongsil University 251 369, Sangdo-ro, Dongjak-gu 252 Seoul, Seoul 06978 253 Republic of Korea 255 Phone: +82 2 828 7175 256 EMail: mhp@ssu.ac.kr