idnits 2.17.1 draft-li-ietf-sfc-security-mimicry-defense-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 11 instances of too long lines in the document, the longest one being 2 characters 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 (March 12, 2021) is 1113 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 SFC C. Li 3 Internet-Draft Z. Tang 4 Intended status: Informational C. Chen 5 Expires: September 13, 2021 Zhejiang Gongshang University 6 March 12, 2021 8 SFC Security Mimicry Defense 9 draft-li-ietf-sfc-security-mimicry-defense-00 11 Abstract 13 With the increase of network threats, the Service Function Chain 14 (SFC) is vulnerable to various attacks, and as a key component of the 15 entire SFC, the security of the service function (SF) is more 16 critical. This document proposes a mimic SF security architecture 17 based on the dynamic heterogeneous redundancy model, which can 18 effectively protect the normal execution function of SF in SFC. The 19 security architecture adopts an active defense method to defend 20 against network attacks, and it can effectively defend against most 21 SF attacks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 13, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Security issues of SFC . . . . . . . . . . . . . . . . . . . 3 60 3.1. Tamper with Network Service Header . . . . . . . . . . . 3 61 3.2. Attack Service Function . . . . . . . . . . . . . . . . . 3 62 4. SFC Security Mimicry Defense . . . . . . . . . . . . . . . . 4 63 4.1. Mimicry Defense . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. SFC Mimicry Defense Architecture . . . . . . . . . . . . 5 65 4.3. Data Flow . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.4. Analysis of Attack and Defense . . . . . . . . . . . . . 7 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 6.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 SF is the most critical part of the entire SFC. The data flow in the 76 SFC domain must go through specific SFs to complete a specific 77 function. If the SF is controlled by the hacker, the hacker can 78 tamper with and discard the data by the hijacked SF, and even 79 paralyze the SFF by DOS attacks. It can not only result in the 80 failure of specified functioning when operating SF, but it may also 81 cause the collapse of the entire SFC domain, which completely 82 violates the original intention of SFC. 84 This document describes a mimic security architecture based on 85 Dynamic Heterogeneous Redundancy Model (DHRM), adopting a proactive 86 defense method to deal with the SFC security problems mentioned 87 above. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [1]. 95 3. Security issues of SFC 97 3.1. Tamper with Network Service Header 99 RFC 8300 [2] points out that the NSH (Network Service Header) is the 100 SFC encapsulation referenced in RFC 7665 [3].NSH contains path 101 identification information to implement service paths. Metadata 102 information is also included which enables service functions to share 103 initial and intermediate classification results with downstream 104 service functions. NSH provides functions to monitor and 105 troubleshoot the SFC. 107 RFC 8300 [2] mentions three methods of protecting NSH headers: SFF / 108 SF NSH Verification, Transport Security, NSH Variable Header-Based 109 Integrity. 111 However, the above three methods cannot solve the NSH tampering 112 problem effectively. If a hacker cracks the encryption mode of NSH 113 and obtained the permission successfully to change the header of a 114 certain SF, the hacker can change the NSH information, and the data 115 is therefore discarded when returns to SFF without finding the 116 mapping relationship. While in practical applications, it is 117 impossible for each SFF to belong to only a specific SFC. Thus, if a 118 hacker obtains the mapping relationship in the SFF, the hacker can 119 change the NSH information to make the packet taking another SFC 120 path, and the control plane cannot detect it. By changing the 121 metadata information, the hacker can even make all devices in the SFC 122 domain reach a wrong consensus. 124 3.2. Attack Service Function 126 If a hacker attacks the SF directly and successfully controls the SF, 127 obtaining all the permissions of the SF, the hacker can manipulate 128 the SF arbitrarily. SFC domain may leads to the following damage. 130 a. The packets passing through the SF may be tampered with, 131 discarded, or even diverted to the hacker server, thereby 132 intercepting the effective information in the network traffic. 133 For example, a hacker can tamper with the data fields of all data 134 packets flowing through the SF. 136 b. This will cause all the packets in the SFC domain that pass the 137 SF to be finally sent to the destination host with incorrect 138 information. Even if the destination host finds an error and 139 discards the packet, it will cause the waste of bandwidth and 140 normal SF resources. 142 c. The attacker can directly change the functions completed by the 143 SF, which is difficult to detect. Assuming that the firewall 144 function is to filter useful information, and due to the unknown 145 information that the firewall need to filter in the control 146 level, it seems that the firewall still completes the filtering 147 function, actually, it is the useful packet which is filtered. 148 Even if it notices a lot of information that should not be 149 present in the SFC, it is not easy to locate which specific part 150 has been attacked. 152 4. SFC Security Mimicry Defense 154 This document designs a mimic SF defense architecture based on a 155 Dynamic Heterogeneous Redundancy Model (DHRM). This framework 156 ensures the security of SF by setting up an SF executive pool 157 composed of M heterogeneous SFs, and the control plane manages the SF 158 executive pool. Assuming that the decision algorithm is perfectly 159 performed without any wrong outcome, the SF will be offline and 160 cleaned by the control plane once the execution result of the SF is 161 wrong, The following sub-chapter illustrates the architecture and 162 mimic defense process specifically. 164 4.1. Mimicry Defense 166 The mimic defense technology is an active defense strategy proposed 167 against the serious asymmetry of the defense cost and attack cost of 168 cyberspace. The redundancy and heterogeneity of the executive body 169 are introduced to change the unity and similarity of the system, and 170 the dynamic and randomness are adopted to change the stativity and 171 certainty of the system, and the non-similar redundancy space is used 172 to block or disrupt the network attack to meet the requirements of 173 controllable system security risks. 175 Specifically, the mimic security defense is composed of executive 176 bodies with equivalent functions but different composition structures 177 to form the core function. Based on the DHRM, randomness and 178 dynamicity are realized, and the heterogeneous executive bodies in 179 the heterogeneous executive pool are continuously changing, which 180 greatly improves the dynamics and uncertainty of functional 181 representation. It makes it difficult for a hacker to detect the 182 behavior and characteristics of the target system, increasing the 183 complexity of the system, and also makes it difficult for hackers to 184 exploit system vulnerabilities to make effective attacks. 186 The DHRM is the basic model of mimic defense. Heterogeneity is the 187 foundation of the dynamic heterogeneous redundancy architecture. It 188 is necessary to ensure that each heterogeneous executive has the 189 greatest difference in various characteristics and attributes. The 190 more heterogeneous attributes a heterogeneous executor has, the more 191 loopholes it can defend, and the higher the cost and price an 192 attacker will have to pay for an attack. Dynamicity means that 193 different sets of heterogeneous actuators can be generated in 194 different periods to replace the currently compromised set of 195 heterogeneous actuators. Dynamicity makes the system present 196 different characteristics to the outside world in different periods. 197 This brings uncertainty to the attacker's attack, which will further 198 increase the difficulty of the attacker's attack. Redundancy means 199 that multiple heterogeneous executors which have the same function 200 process the same business request. The collaborative work between 201 the heterogeneity and redundancy realizes the change of the single 202 environment on which the attack depends, increasing the attacker's 203 attack cost and difficulty, and improving the security and 204 reliability of the system. This concept was first proposed in 2013 205 and has been effectively applied in the field of cyberspace security, 206 such as mimic routers, mimic web servers, mimic DNS, mimic workflow 207 execution system, mimic blockchain, etc. In addition, some mimic 208 network devices have been produced and tested successfully. 210 4.2. SFC Mimicry Defense Architecture 212 +---------------------------------------------------------------------+ 213 | Control Plane | 214 +---------------------------------------------------------------------+ 215 | | | | | 216 | | +=====================+ |+======================+ 217 | | | Mimetic Control | || Mimetic Control | 218 | | | Plugin | || Plugin | 219 | | |+--------+ +--------+| || +--------+ +--------+| 220 | | ||Schedule| |Decision|| || |Schedule| |Decision|| 221 | | || Module | | Module || || | Module | | Module || 222 | | |+--------+ +--------+| || +--------+ +--------+| 223 | | +=====================+ |+======================+ 224 | | | | | | | 225 | | | | | | | 226 | | | +-------------+ | | +--------------+ 227 | | | |Heterogeneous| | | |Heterogeneous | 228 | | | | SF Executive| | | | SF Executive | 229 | | | | Pool | | | | Pool | 230 | | | +-------------+ | | +--------------+ 231 | | | | | | | 232 | | | | | | | 233 +-----+ +----------+ +-----------+ +----------------+ +------+ 234 |Users|-|Classifier|--| SFF1 | ......| SFFn |--|Target| 235 +-----+ +----------+ +-----------+ +----------------+ +------+ 236 Figure 1: SFC Mimicry Defense Architecture 238 The detailed system architecture is shown in Figure 1. For a better 239 understanding, it is assumed that the system has a single SFC 240 (including the host, SFF, SF, and independent servers with other 241 modules, each SF connected to an SFF) and a single control plane. 242 The system architecture contains 05 components as follows: 244 Control plane defines the SFC in the network. The control plane 245 installs the flow rules in the SFF, and delivers the classification 246 strategy to the classifier based on the information uploaded by the 247 classifier. According to the judgment result, the abnormal SF 248 executor is cleaned and be offline, and the next SFF in the SFC is 249 notified that data is coming when the data passes through the SFF. 251 Mimic control plug-in: composed of 02 modules. 253 a. Scheduling module: accept the running instruction of the control 254 plane, select N SF executives from the SF executive pool to 255 activate by using the scheduling algorithm. 257 b. Judgment module: Judge the execution result of the SF executive 258 body, and randomly select one from the correct results and send 259 it to the SFF. If an abnormal SF executor is judged, the 260 abnormal information will be transmitted to the control plane. 262 SF executive body pool: it consists of M heterogeneous SF executive 263 bodies, and N of them are activated by the scheduling module every 264 time when data passes. 266 SFF: forward the data according to the NSH information, copy the 267 packet into N copies and send the information to activate the 268 scheduling module. 270 Classifier: send the packet information to the control plane, and add 271 the corresponding NSH to the packet according to the classification 272 strategy issued by the control plane. 274 4.3. Data Flow 276 +-----+ +----------+ +----+ +----+ +----+ +------+ 277 |Users|--|Classifier|--|SFF1|-----|SFF2| ......|SFFn|--------|Target| 278 +-----+ +----------+ +----+ +----+ +----+ +------+ 279 | | | 280 | | | 281 +-----+ +-----+ +-----+ 282 | SF1 | | SF2 | | SFn | 283 +-----+ +-----+ +-----+ 284 Figure 2: SFC Use Case 286 Take the SFC in Figure 2 as an example, we assume that the packet 287 path is the source host-classifier-SFF1-SF1-SFF1-SFF2-SF2 ...- target 288 host. The data first reaches the classifier before entering the SFC 289 domain, and the classifier sends the data information to the control 290 plane. The controller sends a classification strategy to the 291 classifier based on the uploaded information, then the classifier 292 adds NSH to the data packet according to the strategy and forwards 293 the data packet to SFF1 based on the header information. When the 294 data arrives at SFF1, we need to judge whether the data packet needs 295 to go through SF1 according to the NSH of the data packet. 297 When the packet reaches SFF1 for the first time, it should be 298 forwarded to SF. Therefore, SFF1 first sends a running instruction 299 to the scheduling module. After the scheduling module receives the 300 instruction, it uses a scheduling algorithm to select N activations 301 from the SF executive pool. Then, the information for activating the 302 SF actuator is forwarded to SFF1. SFF1 copies the packet into N 303 copies and sends the data to N SF actuators according to the 304 information provided by the scheduling module. Each SF performs its 305 designated network function and sends the execution result to the 306 decision module. After the judgment module accepts the execution 307 result, it judges whether there is an abnormal SF executive body by 308 using a judgment algorithm. If there is an abnormal execution body, 309 the abnormal information is sent to the control plane, and the 310 abnormal SF will be cleaned and offline by the control plane, then 311 the decision module selects one from the correct results and sends it 312 to SFF1. If there is no abnormal execution body, it will directly 313 select one from the correct results and send it to SFF1. SFF1 judges 314 whether to forward to SF1 according to the NSH of the returned 315 packet. 317 In this case, the packet should be forwarded to SFF2. After the 318 packet reaches SFF2, the same judgment and operation are performed 319 until it leaves the SFC domain. 321 4.4. Analysis of Attack and Defense 323 The SF executive pool is the foundation of the security of this 324 framework. By configuring M heterogeneous SF execution bodies to 325 form an SF execution body pool and using a scheduling algorithm to 326 select N activation methods from the M SF execution bodies to improve 327 the heterogeneity and dynamicity of the architecture, which increases 328 the difficulty of the hacker's attacks. Assuming that the packet 329 path is the source host-classifier-SFF1-SF1-SFF1-SFF2-SF2 ...- target 330 host. For a traditional SFC, if a hacker hijacks SF1, it can 331 manipulate SF1 to tamper with NSH so that traffic cannot reach SFF2. 332 Furthermore, if the attacker intercepts the mapping table of SFF2, 333 the hacker can tamper with the NSH header to make the traffic go 334 through a completely different SFC link. Any device in the SFC 335 domain, including the controller, will not find any abnormalities. A 336 hacker can also directly tamper with the service functions of SF, for 337 instance, the original SF performs load-balancing function. The 338 hacker can tamper with all the data to the same link, which may 339 paralyze the entire link. 341 If the security framework of this document is adopted, first, during 342 the SF attack detection phase, the hacker will find that there are M 343 SFs with the same function but different operating environments and 344 hardware devices mounted under the same SFF, which has caused certain 345 difficulty for the attack. If the hacker successfully controls one 346 SF executive in the M SF executive pool under SFF2. Before the data 347 is forwarded from the control module to the SF executive body, the 348 scheduling module uses a scheduling algorithm to activate N of the M 349 SF executive bodies. When M and N differ greatly, the probability of 350 selecting an abnormal SF execution body by random scheduling is 351 extremely low. It is further assumed that even if an abnormal 352 executor is selected, no matter whether the attacker tampers with the 353 packet or data function in the controlled SF executor, the decision 354 module can judge the exception when it judges the N execution 355 results, it can select the correct result and send abnormal 356 information to the control module for offline processing. Unless the 357 hacker successfully attacks more than half of the SF execution 358 bodies, the attack can be completely successful. While development 359 vendors and hardware equipment are different in different SFs 360 operating environment, which will cause great difficulty to the 361 hacker. 363 In another case, after the packet arrives at SFF1, it is not 364 forwarded to SF to complete the specified function but directly 365 forwarded to SFF2. When the packet arrives at SFF2, SFF2 will infer 366 from the NSH's SPI and SI information that the packet do not pass the 367 specified function in the previous SFF, and then report an error to 368 the control plane. 370 5. Acknowledgements 372 Thanks to Lei Rui and Chen Zebin for the first draft. 374 6. References 376 6.1. Normative References 378 [1] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997, 380 . 382 [2] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 383 "Network Service Header (NSH)", RFC 8300, 384 DOI 10.17487/RFC8300, January 2018, 385 . 387 6.2. Informative References 389 [3] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 390 Chaining (SFC) Architecture", RFC 7665, 391 DOI 10.17487/RFC7665, October 2015, 392 . 394 Authors' Addresses 396 Chuanhuang Li 397 Zhejiang Gongshang University 398 18 Xuezheng Str., Xiasha University Town 399 Hangzhou 310018 400 P.R.China 402 Phone: +86 571 28877723 403 Email: chuanhuang_li@zjsu.edu.cn 405 Zhongyun Tang 406 Zhejiang Gongshang University 407 18 Xuezheng Str., Xiasha University Town 408 Hangzhou 310018 409 P.R.China 411 Phone: +86 571 28877723 412 Email: tangzy@zjsu.edu.cn 414 Chao Chen 415 Zhejiang Gongshang University 416 18 Xuezheng Str., Xiasha University Town 417 Hangzhou 310018 418 P.R.China 420 Phone: +86 571 28877723 421 Email: eckio_491@zjgsu.edu.cn