idnits 2.17.1 draft-nguyen-sfc-security-architecture-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.) 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 (November 24, 2019) is 1587 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 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: May 27, 2020 November 24, 2019 7 A Security Architecture Against Service Function Chaining Threats 8 draft-nguyen-sfc-security-architecture-00 10 Abstract 12 Service Function Chaining (SFC) provides a special capability that 13 defines an ordered list of network services as a virtual chain and 14 makes a network more flexible and manageable. However, SFC is 15 vulnerable to various attacks caused by compromised switches, 16 especially the middlebox-bypass attack. In this document, we propose 17 a security architecture that can detect not only middlebox-bypass 18 attacks but also other incorrect forwarding actions by compromised 19 switches. The existing solutions to protect SFC against compromised 20 switches and middlebox-bypass attacks can only solve individual 21 problems. The proposed architecture uses both probe-based and 22 statistics-based methods to check the probe packets with random pre- 23 assigned keys and collect statistics from middleboxes for detecting 24 any abnormal actions in SFC. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 27, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Compromised Switches . . . . . . . . . . . . . . . . . . . . 3 63 4. Architecture Design . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Proposed Architecture . . . . . . . . . . . . . . . . . . 5 66 4.3. Probe Packet Processing . . . . . . . . . . . . . . . . . 6 67 4.4. Statistics Checking . . . . . . . . . . . . . . . . . . . 7 68 5. Informative References . . . . . . . . . . . . . . . . . . . 8 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 In recent years, Service Function Chaining (SFC) has emerged with the 75 robust development of Software Defined Networking (SDN) and Network 76 Function Virtualization (NFV). SFC defines ordered virtual chains of 77 service functions (e.g., firewalls, load balancing, network address 78 translation, etc.) and steers the network traffic through them, which 79 brings many benefits from virtualized software-defined 80 infrastructure. Service functions are provided by specialized 81 network entities called middleboxes. One middlebox is commonly 82 connected to a switch, and SFC connects switches to make a chain with 83 the required services. Middleboxes are responsible for processing 84 packet and forwarding packet to the attached switches in the service 85 chain. 87 However, there are some security vulnerabilities for packets traverse 88 in SFC, especially with compromised switches. A special attack 89 called "middlebox-bypass attack" was proposed, which happens when 90 compromised switches forward packets to the next-hop middlebox in the 91 SFC without sending them to its attached middlebox. This means that 92 packets are not processed by all service functions inside 93 middleboxes, which does not meet the original goal of SFC. 94 Attackers, therefore, can bypass some important service functions, 95 e.g., firewall or IDS, and perform more attack cases. Furthermore, 96 compromised switches can drop, duplicate, forward incorrectly or 97 modify the packet without notifying the controller. Packets and all 98 network information can be sent to attackers, and all of these 99 problems breach the policy of SFC. 101 Various countermeasures have been proposed to protect SFC from these 102 attacks. They prevents the middlebox-bypass attack by adding special 103 tags to packets in the same flow and verify these tags on every 104 middlebox and egress switches. For the compromised switches attacks, 105 there are two main categories of the solution: probe-based and 106 statistics-based method. Probe-based mechanisms inject probe packet 107 in networks and check the integrity of these packets, while 108 statistics-based mechanisms collect and compare all of the statistics 109 from network components to find out any abnormality. However, these 110 solutions still have some limitations, which are described in detail 111 in the next section. 113 In this document, we propose a security architecture that can 114 simultaneously detect middlebox-bypass attacks and compromised 115 switches in SFC. The proposed architecture uses the hybrid of probe- 116 based and statistics-based methods, which surmounts the disadvantages 117 of each solution above. The probe-based method uses probe packets to 118 investigate the operation of network components in SFC. Middleboxes 119 are programmed to handle the random pre-assigned key in the probe 120 packet and forward back to the attached switch. If the next-hop 121 middlebox defines incorrect handled key verification, which means the 122 middlebox-bypass attack happened, an alarm is triggered. The 123 statistics-based method helps the controller to find out the 124 irregularities by monitoring every information of the packets which 125 pass the middlebox (e.g., packet type, packet size, processing time, 126 number of packets, etc.). 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Compromised Switches 136 The compromised switch is a serious issue for SDN in general and SFC 137 in particular. There are many types of compromised switches attack: 138 packet dropping, packet duplicating, packet manipulating, incorrect 139 forwarding, eavesdropping, weight adjusting, man-in-the-middle, 140 state-spoofing, control-channel hijacking, etc. These attacks happen 141 when compromised switches perform some attack actions besides 142 forwarding the packets as the commands from controllers. By 143 controlling the compromised switches to do one or all of these 144 attacks, attackers can bring serious problems to the whole network. 146 Take the SFC chain in Figure 1 as an example. Packets in this chain 147 should follow this path: Source Host-S1-Firewall-S1-S2-IDS-S2-S3-LB- 148 S3-Destination Host. When compromised switch S1 receives a packet, 149 it can drop the packet, forward the packet multiple times to S2, 150 modify the packet, or even send that packet to an attacker, etc. S2 151 becomes the victim and this can ruin the operation of the network 152 because S2 typically belongs to multiple SFC chains. Furthermore, if 153 S2 is also compromised and confederate with S1, they can spoof 154 information and breach all of the detecting mechanisms. 156 Compromised 157 Switch 158 +--------+ +======+ +----+ +----+ +------+ 159 | Src | || S1 || | S2 | | S3 | | Dst | 160 | Host | ---> || || ---> | | ---> | | ---> | Host | 161 +--------+ +======+ +----+ +----+ +------+ 162 | ^ | ^ | ^ 163 | | | | | | 164 v | v | v | 165 +----------+ +-----+ +----+ 166 | Firewall | | IDS | | LB | 167 +----------+ +-----+ +----+ 169 Figure 1: Simple service function chain example with 01 compromised 170 switch S1 172 Current solutions for these attacks were well investigated by other 173 proposals. The probe-based method sends probe packets to each flow 174 or specific switch, then checks the path and the integrity of those 175 packets. This method can be disabled if compromised switches can 176 recognize the probe packets and forward them as commanded. The 177 statistics-based method tries to collect all the information from the 178 data plane (e.g., the number of transmitted/received/dropped packets, 179 packet type, packet size, arrived/departed time,etc.) then compares 180 them to find out the compromised switches. This method does not 181 support real-time detection because it needs time to gather data and 182 only works after packets are forwarded. Moreover, packets can be 183 forwarded without being sent to middleboxes, which bring us to the 184 middlebox-bypass attack in the next subsection. 186 In this document, the proposed architecture detects compromised 187 switches in SFC by combining probe-based and statistics-based 188 methods. We assume that there is no collaboration between 189 compromised switches. There are few proposed solutions to detect 190 this type of attack but with high delay and low accuracy, or they try 191 to prevent this collaboration from the beginning. Most of existing 192 solutions also try to avoid this collaboration case because it is 193 hard to detect when compromised switches can help each other to spoof 194 the statistics and share information. 196 4. Architecture Design 198 4.1. Methodology 200 The architecture detects compromised switches and middlebox-bypass 201 attacks by sending probe packets for each SFC chain (probe-based 202 method) and collects information from middleboxes continuously 203 (statistics-based method). Middleboxes alert the controller whenever 204 it receives a probe packet without a correct processed key. By 205 monitoring every information of the packets which pass the middlebox 206 also, the controller can find out the irregularity. The detailed 207 architecture and detecting procedures are described in the next 208 subsections. 210 4.2. Proposed Architecture 212 The detailed system architecture is illustrated in Figure 2. For 213 ease of understanding, we assume a system with a single SFC chain 214 (contains hosts, switches, and middleboxes, each middlebox connects 215 to one switch) and a single controller. The system architecture 216 contains 03 components as follows: 218 Controller: consists of 03 modules. (1) Controller Module: defines 219 the service function chains in the network. This module installs the 220 flow rules on switches as well as connects them to middleboxes and 221 sends the updated network topology to Key Generator Module and 222 Statistics Analyzing Module. (2) Key Generator Module: based on the 223 most up-to-date network topology, this module creates and assigns new 224 key lists to middleboxes. These key lists are used to check the 225 integrity of probe packets in the service chains. (3) Statistics 226 Analyzing Module: based on the most up-to-date network topology, this 227 module analyzes statistics from middleboxes to find out abnormal 228 actions. 230 Switches: follow the command from the controller to connect 231 middleboxes to make service function chains. 233 Middleboxes: check every received packet from switches, record the 234 packet information to make statistics, process the probe packet and 235 send statistics to the controller. 237 +------------+ 238 +---------->| Controller |<------+ 239 | +------------+ | 240 | ^ | 241 | | | 242 v v v 243 +------+ +----+ +----+ +----+ +------+ 244 | Src | | S1 | | S2 | | Sn | | Dst | 245 | Host | ---> | | ---- > | | --> ... --> | |--->| Host | 246 +------+ +----+ +----+ +----+ +------+ 247 | ^ | ^ | ^ 248 Probe packet | | | | | | 249 path v | v | v | 250 +-----------+ +-----------+ +-----------+ 251 | Middlebox | | Middlebox | | Middlebox | 252 | 1 | | 2 | | n | 253 +-----------+ +-----------+ +-----------+ 255 Figure 2: System Architecture 257 4.3. Probe Packet Processing 259 Probe packets are processed by middleboxes. At first, middleboxes 260 receive pre-assigned key lists from the controller. Each middlebox 261 only knows the compatible processed key list of the previous 262 middlebox in the chain. By creating a key list and randomly assign 263 different keys for each probe packet in the same flow, we reduce the 264 probability that an attacker can guess the exact key and spoof the 265 probe packet. Furthermore, the numerical order and the key value of 266 the probe packet are also monitored by the controller, which 267 restricts other guessing methods. Refreshing key lists periodically 268 or whenever find out an abnormal action is also a solution to this 269 problem. 271 Take the SFC chain in Figure 2 as an example. The packet path is 272 Source Host-S1-Middlebox1-S1-S2-Middlebox2-S2-...-Destination Host. 273 If we set the chain so that packets are sent from the controller and 274 come back to the controller, compromised switches can realize this 275 and operate like normal switches. From the beginning, Middlebox-2 276 receives the key list K1 = {Key_1, Key_2...} which belongs to 277 Middlebox-1. The key list K1 contains the exact output keys that 278 Middlebox-1 must give after processing packets. When Middlebox-2 279 receives a new packet from the attached switch S2, it first checks if 280 this is the probe packet or normal packet. We use an unused bit in 281 the header to help middleboxes recognizes the probe packet. If this 282 is a probe packet, Middlebox-2 needs to check whether it was 283 processed correctly or not by referring to the pre-assigned key list. 284 For example, after receiving a probe packet with the key named Key_X, 285 Middlebox-2 defines the integrity of this packet by checking whether 286 the Key_X is in the key list K1 or not. If this probe packet is 287 correctly processed, Middlebox-2 will replace the Key_X by Key_Y, 288 which is calculated by hash function. After this process, 289 Middlebox-2 forwards the packet back to the attached switch (S2) to 290 transfer to the next-hop middlebox (Middlebox-3). 292 If the probe packet is not correct, Middlebox-2 triggers an alarm to 293 the controller by sending the statistics. For other packet types, 294 the information of those packets (e.g., packet type, packet size, 295 processing time, number of packets, etc.) is recorded to make the 296 statistics report. Finally, Middlebox-2 sends the report to the 297 controller and waits for new packets. 299 In practice, we do not need an additional method to check the 300 integrity of the last switch in the chain. As mentioned above in 301 subsection \ref{CS}, a switch typically belongs to multiple SFC 302 chains, which means that it can be checked through the operation of 303 other chains. In the case of only one chain as the example above, we 304 run a program on the Destination Host to check the probe packets from 305 Sn just like other middleboxes. 307 4.4. Statistics Checking 309 To detect other compromised switches attack cases (e.g., packet 310 dropping, packet duplicating, packet manipulating, weight adjusting, 311 etc.), the Statistics Processing Module always listens to statistics 312 sent from middleboxes. The statistics contain the information of the 313 packets which pass the middlebox (e.g., the number of 314 transmitted/received/dropped packet, packet type, packet size, 315 processing time, arrived/departed time, alert signal raised by 316 middleboxes in probe packet processing, etc.). By comparing these 317 statistics between middleboxes and checking the alert signal, this 318 module can detect the compromised switches and middlebox-bypass 319 attacks. 321 Take the SFC chain in Figure 2 as an example again. If Middlebox-1 322 reports that it forwarded 100 packets to S1 (75 normal packets and 25 323 probe packets) in a period (calculated by the controller) so that 324 Middlebox-2 should report that it also received 100 packets with the 325 same number of normal and probe packet in the same period. We set a 326 threshold for the difference of statistics (because of packet 327 processing latency, transmission delay or other reasons). For 328 example, if the threshold is 5\%, it means that Middlebox-2 should 329 receive at least 95 packets in the same period. If Middlebox-2's 330 report shows that it only gets 90 packets, this means that the switch 331 S2 does not forward all of the packets to Middlebox-2 (missing at 332 least 5 packets), and this can be a middlebox-bypass attack or packet 333 dropping attack. The Statistics Processing Module will raise an 334 alert in this case. In another case, if Middlebox-2 reports that it 335 received 150 packets in that period, this means that an attack is 336 happening (packet duplicating or weight adjusting attack) and an 337 alert is also triggered. 339 5. Informative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", RFC 2119, March 1997. 344 Appendix A. Acknowledgements 346 This work was supported by Institute of Information & communications 347 Technology Planning & Evaluation (IITP) grant funded by the Korea 348 government (MSIT) (No.2018-0-00254, SDN security technology 349 development). 351 Authors' Addresses 353 NGUYEN CANH THANG 354 Department of ICMCT 355 Soongsil University 356 369, Sangdo-ro, Dongjak-gu 357 Seoul, Seoul 06978 358 Republic of Korea 360 Phone: +82 10 3408 0483 361 EMail: nct@soongsil.ac.kr 363 Minho Park 364 School of Electronic Engineering 365 Soongsil University 366 369, Sangdo-ro, Dongjak-gu 367 Seoul, Seoul 06978 368 Republic of Korea 370 Phone: +82 2 828 7176 371 EMail: mhp@ssu.ac.kr