idnits 2.17.1 draft-hyun-i2nsf-nsf-triggered-steering-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 207: '... classifier MUST use this identif...' RFC 2119 keyword, line 208: '... Control Nodes MUST use this identif...' RFC 2119 keyword, line 212: '... path. SI MUST be decremented by...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hyun 3 Internet-Draft J. Jeong 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: January 4, 2018 J. Park 6 ETRI 7 S. Hares 8 Huawei 9 July 3, 2017 11 Service Function Chaining-Enabled I2NSF Architecture 12 draft-hyun-i2nsf-nsf-triggered-steering-03 14 Abstract 16 This document describes an architecture of the I2NSF framework using 17 security function chaining for securiy policy enforcement. Security 18 function chaining enables composite inspection of network traffic by 19 steering the traffic through multiple types of network security 20 functions according to the information model for NSFs capabilities in 21 the I2NSF framework. This document explains the additional 22 components integrated into the I2NSF framework and their 23 functionalities to achieve security function chaining. It also 24 describes representative use cases to address major benefits from the 25 proposed architecture. 27 Status of This Memo 29 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on January 4, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. SFC Policy Manager . . . . . . . . . . . . . . . . . . . . 8 72 4.2. SFC Catalog Manager . . . . . . . . . . . . . . . . . . . 8 73 4.3. Developer's Management System . . . . . . . . . . . . . . 9 74 4.4. Classifier . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.5. Service Function Forwarder (SFF) . . . . . . . . . . . . . 9 76 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Dynamic Path Alternation . . . . . . . . . . . . . . . . . 10 78 5.2. Enforcing Different SFPs Depending on Trust Levels . . . . 11 79 5.3. Effective Load Balancing with Dynamic SF Instantiation . . 12 80 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. Changes from 87 draft-hyun-i2nsf-nsf-triggered-steering-02 . . . . . 16 89 1. Introduction 91 To effectively cope with emerging sophisticated network attacks, it 92 is necessary that various security functions cooperatively analyze 93 network traffic [RFC7498][i2nsf-problem][nsf-capability-im]. In 94 addition, depending on the characteristics of network traffic and 95 their suspiciousness level, the different types of network traffic 96 need to be analyzed through the different sets of security functions. 97 In order to meet such requirements, besides security policy rules for 98 individual security functions, we need an additional policy about 99 service function chaining (SFC) for network security which determines 100 a set of security functions through which network traffic packets 101 should pass for inspection. In addition, [nsf-capability-im] 102 proposes an information model for NSFs capabilities that enables a 103 security function to trigger further inspection by executing 104 additional security functions based on its own analysis results 105 [i2nsf-framework]. However, the current design of the I2NSF 106 framework does not consider network traffic steering fully in order 107 to enable such chaining between security functions. 109 In this document, we propose an architecture that integrates 110 additional components from Service Function Chaining (SFC) into the 111 I2NSF framework to support security function chaining. We extend the 112 security controller's functionalities such that it can interpret a 113 high-level policy of security function chaining into a low-level 114 policy and manage them. It also keeps the track of the available 115 service function (SF) instances for security functions and their 116 information (e.g., network information and workload), and makes a 117 decision on which SF instances to use for a given security function 118 chain/path. Based on the forwarding information provided by the 119 security controller, the service function forwarder (SFF) performs 120 network traffic steering through various required security functions. 121 A classifier is deployed for the enforcement of SFC policies given by 122 the security controller. It performs traffic classification based on 123 the polices so that the traffic passes through the required security 124 function chain/path by the SFF. 126 2. Objective 128 o Policy configuration for security function chaining: SFC-enabled 129 I2NSF architecture allows policy configuration and management of 130 security function chaining. Based on the chaining policy, 131 relevant network traffic can be analyzed through various security 132 functions in a composite, cooperative manner. 134 o Network traffic steering for security function chaining: SFC- 135 enabled I2NSF architecture allows network traffic to be steered 136 through multiple required security functions based on the SFC 137 policy. Moreover, the I2NSF information model for NSFs 138 capabilities [nsf-capability-im] requires a security function to 139 call another security function for further inspection based on its 140 own inspection result. To meet this requirement, SFC-enabled 141 I2NSF architecture also enables traffic forwarding from one 142 security function to another security function. 144 o Load balancing over security function instances: SFC-enabled I2NSF 145 architecture provides load balancing of incoming traffic over 146 available security function instances by leveraging the flexible 147 traffic steering mechanism. For this objective, it also performs 148 dynamic instantiation of a security function when there are an 149 excessive amount of requests for that security function. 151 3. Terminology 153 This document uses the following terminology described in [RFC7665], 154 [RFC7665][i2nsf-terminology][ONF-SFC-Architecture]. 156 o Service Function/Security Function (SF): A function that is 157 responsible for specific treatment of received packets. A Service 158 Function can act at various layers of a protocol stack (e.g., at 159 the network layer or other OSI layers) [RFC7665]. In this 160 document, SF is used to represent both Service Function and 161 Security Function. Sample Security Service Functions are as 162 follows: Firewall, Intrusion Prevention/Detection System (IPS/ 163 IDS), Deep Packet Inspection (DPI), Application Visibility and 164 Control (AVC), network virus and malware scanning, sandbox, Data 165 Loss Prevention (DLP), Distributed Denial of Service (DDoS) 166 mitigation and TLS proxy. 168 o Classifier: An element that performs Classification. It uses a 169 given policy from SFC Policy Manager. 171 o Service Function Chain (SFC): A service function chain defines an 172 ordered set of abstract service functions and ordering constraints 173 that must be applied to packets and/or frames and/or flows 174 selected as a result of classification [RFC7665]. 176 o Service Function Forwarder (SFF): A service function forwarder is 177 responsible for forwarding traffic to one or more connected 178 service functions according to information carried in the SFC 179 encapsulation, as well as handling traffic coming back from the 180 SF. Additionally, an SFF is responsible for delivering traffic to 181 a classifier when needed and supported, transporting traffic to 182 another SFF (in the same or the different type of overlay), and 183 terminating the Service Function Path (SFP) [RFC7665]. 185 o Service Function Path (SFP): The service function path is a 186 constrained specification of where packets assigned to a certain 187 service function path must be forwarded. While it may be so 188 constrained as to identify the exact locations for packet 189 processing, it can also be less specific for such locations 190 [RFC7665]. 192 o SFC Policy Manager: It is responsible for translating a high-level 193 policy into a low-level policy, and performing the configuration 194 for SFC-aware nodes, passing the translated policy and 195 configuration to SFC-aware nodes, and maintaining a stabilized 196 network. 198 o SFC Catalog Manager: It is responsible for keeping the track of 199 the information of available SF instances. For example, the 200 information includes the supported transport protocols, IP 201 addresses, and locations for the SF instances. 203 o Control Nodes: It collectively refer to SFC Policy Manager, SFC 204 Catalog Manager, SFF, and Classifier. 206 o Service Path Identifier (SPI): It identifies a service path. The 207 classifier MUST use this identifier for path selection and the 208 Control Nodes MUST use this identifier to find the next hop 209 [sfc-nsh]. 211 o Service Index (SI): It provides a location within the service 212 path. SI MUST be decremented by service functions or proxy nodes 213 after performing the required services [sfc-nsh]. 215 o Network Service Header (NSH): The header is used to carry SFC 216 related information. Basically, SPI and SI should be conveyed to 217 the Control Nodes of SFC via this header. 219 o SF Forwarding Table: SFC Policy Manager maintains this table. It 220 contains all the forwarding information on SFC-enabled I2NSF 221 architecture. Each entry includes SFF identifier, SPI, SI, and 222 next hop information. For example, an entry ("SFF: 1", "SPI: 1", 223 "SI: 1", "IP: 192.168.xx.xx") is interpreted as follows: "SFF 1" 224 should forword the traffic containing "SPI 1" and "SI 1" to 225 "IP=192.168.xx.xx". 227 4. Architecture 229 This section describes an SFC-enabled I2NSF architecture and the 230 basic operations of service chaining. It also includes details about 231 each component of the architecture. 233 Figure 1 describes the components of SFC-enabled I2NSF architecture. 234 Our architecture is designed to support a composite inspection of 235 traffic packets in transit. According to the inspection result of 236 each SF, the traffic packets could be steered to another SF for 237 futher detailed analysis. It is also possible to reflect a high- 238 level SFC-related policy and a configuration from I2NSF Client on the 239 components of the original I2NSF framwork. Moreover, the proposed 240 architecture provides load balancing, auto supplementary SF 241 generation, and the elimination of unused SFs. In order to achieve 242 these design purposes, we integrate several components to the 243 original I2NSF framwork. In the following sections, we explain the 244 details of each component. 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | I2NSF User | 248 | +-+-+-+-+-+-+-+-+ | 249 | |I2NSF User | | 250 | | | | 251 | +-+-+-+^+-+-+-+-+ | 252 | | | 253 | | | 254 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Consumer-Facing Interface 256 | 257 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Security Management System | 259 | | | 260 | +-+-+-+-+-+-+-v-+-+-+-+-+ | 261 | |Security Controller | | 262 | | +-+-+-+-+ +-+-+-+-+ | Registration | 263 | | |SFC | |SFC | | Interface +-+-+-+-++-+-+-+-+ | 264 | | |Policy | |Catalog| |<----------->| Developer's | | 265 | | |Manager| |Manager| | | Mgnt System | | 266 | | +-+-+-+-+ +-+-+-+-+ | +-+-+-+-++-+-+-+-+ | 267 | +-+-+-+-+-+-^-+-+-+-+-+-+ | 268 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | NSF-Facing Interface 270 | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |Security Network | | 273 | +------------------------------------------------+ | 274 | | | | | 275 | | +-+-+-v-+-+-+ +-+-+-+-+v+-+-+ | 276 | +-+-+-v-++-+ | +-+-+-+ | | +-+-+-+ | | 277 | | | | |SFF1 |<-|---------------->| SF1 | | | 278 | |Classifier|<------> | +-+-+-+< | | +-+-+-+ | | 279 | | | | \| | +-+-+-+ | | 280 | +-+-+-+-++-+ | +-+-+-+ \---------------->| SF2 | | | 281 | | |SFF2 |<-|---------------/ +-+-+-+ | | 282 | | +-+-+-+<-|-------------\ +-+-+-+ | | 283 | +-+-+-+-+-+-+ \->| SF3 | | | 284 | | +-+-+-+ | | 285 | +-+-+-+-+-+-+-+ | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 1: SFC-enabled I2NSF 290 4.1. SFC Policy Manager 292 SFC Policy Manager is a core component in our system. It is 293 responsible for the following two things: (1) Interpreting a high- 294 level SFC policy (or configuration) into a low-level SFC policy (or 295 configuration), which is given by I2NSF Client, and delivering the 296 interpreted policy to Classifiers for security function chaining. (2) 297 Generating an SF forwarding table and distributing the fowarding 298 information to SFF(s) by consulting with SFC Catalog Manager. As 299 Figure 1 describes, SFC Policy Manager performs these additional 300 functionalities through Consumer-Facing Interface and NSF-Facing 301 Interface. 303 Given a high-level SFC policy/configuration from I2NSF Client via 304 Consumer-Facing Interface, SFC Policy Manager interprets it into a 305 low-level policy/configuration comprehensible to Classifier(s), and 306 then delivers the resulting low-level policy to them. Moreover, SFC 307 Policy Manager possibly generates new policies for the flexible 308 change of traffic steering to rapidly react to the current status of 309 SFs. For instance, it could generate new rules to forward all 310 subsequent packets to "Firewall Instance 2" instead of "Firewall 311 Instance 1" in the case where "Firewall Instance 1" is under 312 congestion. 314 SFC Policy Manager gets information about SFs from SFC Catalog 315 Manager to generate SF forwarding table. In the table generation 316 process, SFC Policy Manager considers various criteria such as SFC 317 policies, SF load status, SF physical location, and supported 318 transport protocols. An entry of the SF forwarding table consists of 319 SFF Identifier, SFP, SI, and next hop information. The examples of 320 next hop information includes the IP address and supported transport 321 protocols (e.g., VxLAN and GRE). These forwarding table updates are 322 distributed to SFFs with either push or pull methods. 324 4.2. SFC Catalog Manager 326 In Figure 1, SFC Catalog Manager is a component integrated into 327 Security Controller. It is responsible for the following three 328 things: (1) Maintaining the information of every available SF 329 instance such as IP address, supported transport protocol, service 330 name, and load status. (2) Responding to the queries of available SF 331 instances from SFC Policy Manager so as to help to generate a 332 forwarding table entry relevant to a given SFP. (3) Requesting 333 Developer's Management System to dynamically instantiate 334 supplementary SF instances to avoid service congestion or the 335 elimination of an existing SF instance to avoid resource waste. 337 Whenever a new SF instance is registered, Developer's Management 338 System passes the information of the registered SF instance to SFC 339 Catalog Manager, so SFC Catalog Manager maintains a list of the 340 information of every available SF instance. Once receiving a query 341 of a certain SFP from SFC Policy Manager, SFC Catalog Manager 342 searches for all the available SF instances applicable for that SFP 343 and then returns the search result to SFC Policy Manager. 345 In our system, each SF instance periodically reports its load status 346 to SFC Catalog Manager. Based on such reports, SFC Catalog Manager 347 updates the information of the SF instances and manages the pool of 348 SF instances by requesting Developer's Management System for the 349 additional instantiation or elimination of the SF instances. 350 Consequently, SFC Catalog Manager enables efficient resource 351 utilization by avoiding congestion and resource waste. 353 4.3. Developer's Management System 355 We extend Developer's Management System for additional 356 functionalities as follows. As mentioned above, the SFC Catalog 357 Manager requests the Developer's Management System to create 358 additional SF instances when the existing instances of that service 359 function are congested. On the other hand, when there are an 360 excessive number of instances for a certain service function, the SFC 361 Policy Manager requests the Developer's Management System to 362 eliminate some of the SF instances. As a response to such requests, 363 the Developer's Management System creates and/or removes SF 364 instances. Once it creates a new SF instance or removes an existing 365 SF instance, the changes must be notified to the SFC Catalog Manager. 367 4.4. Classifier 369 Classifier is a logical component that may exist as a standalone 370 component or a submodule of another component. In our system, the 371 initial classifier is typically located at an entry point like a 372 border router of the network domain, and performs the initial 373 classification of all incoming packets according to the SFC policies, 374 which are given by SFC policy manager. The classification means 375 determining the SFP through which a given packet should pass. Once 376 the SFP is decided, the classifier constructs an NSH that specifies 377 the corresponding SPI and SI, and attaches it to the packet. The 378 packet will then be forwarded through the determined SFP on the basis 379 of the NSH information. 381 4.5. Service Function Forwarder (SFF) 383 It is responsible for the following two functionalities: (1) 384 Forwarding the packets to the next SFF/SF. (2) Handling re- 385 classification request from SF. 387 An SFF basically takes forwarding functionality, so it needs to find 388 the next SF/SFF for the incoming traffic. It will search its 389 forwarding table to find the next hop information that corresponds to 390 the given traffic. In the case where the SFF finds a target entry on 391 its forwarding table, it just forwards the traffic to the next SF/SFF 392 specified in the next hop information. If an SFF does not have an 393 entry for a given packet, it will request the next hop information to 394 SFC Policy Manager with SFF identifier, SPI, and SI information. The 395 SFC Policy Manager will respond to the SFF with next hop information, 396 and then the SFF updates its forwarding table with the response, 397 forwarding the traffic to the next hop. 399 Sometimes an SF may want to forward a packet, which is highly 400 suspicious, to another SF for futher security inspection. This is 401 referred to as advanced security action in I2NSF. In this situation, 402 if the next SF may not be the one on the current SFP of the packet, 403 re-classification is required to change the SFP of the packet. If 404 the current SF is capable of re-classifying the packet by itself, the 405 SF updates the SPI field in the NSH in the packet to serve the 406 advanced secuity action. Otherwise, if the classifier exists as a 407 standalone, the SF appends the inspection result of the packet to the 408 MetaData field of the NSH and delivers it to the source SFF. The 409 attached MetaData includes a re-classification request to change the 410 SFP of the packet to another SFP for stronger inspection. When the 411 SFF receives the traffic requiring re-classification, it forwards the 412 traffic to the Classifier where re-classification will be eventually 413 performed. 415 SFC defines Rendered Service Path (RSP), which represents the 416 sequence of actual visits by a packet to SFFs and SFs [RFC7665]. If 417 the RSP information of a packet is available, the SFF could check 418 this RSP information to detect whether undesired looping happened on 419 the packet. If the SFF detects looping, it could notify the Security 420 Controller of this looping, and the Security Controller could modify 421 relevant security policy rules to resolve this looping. 423 5. Use Cases 425 This section introduces three use cases for the SFC-enabled I2NSF 426 architecture : (1) Dynamic Path Alternation, (2) Enforcing Different 427 SFPs Depending on Trust Levels, and (3) Effective Load Balancing with 428 Dynamic SF Instantiation. 430 5.1. Dynamic Path Alternation 432 In SFC-enabled I2NSF architecture, a Classifier determines the 433 initial SFP of incoming traffic according to the SFC policies. The 434 classifier then attaches an NSH specifying the determined SFP of the 435 packets, and they are analyzed through the SFs of the initial SFP. 436 However, SFP is not a static property, so it could be changed 437 dynamically through re-classification. A typical example is for a 438 certain SF in the initial SFP to detect that the traffic is highly 439 suspicious (likely to be malicious). In this case, the traffic needs 440 to take stronger inspection through a different SFP which consists of 441 more sophisticated SFs. 443 Figure 2 illustrates an example of such dynamic SFP alternation in a 444 DDoS attack scenario. SFP-1 represents the default Service Function 445 Path that the traffic initially follows, and SFP-1 consists of AVC, 446 Firewall, and IDS/IPS. If the IDS/IPS suspects that the traffic is 447 attempting DDoS attacks, it will change the SFP of the traffic from 448 the default to SFP-2 so that the DDoS attack mitigator can execute a 449 proper countermeasure against the attack. 451 Such SFP alternation is possible in the proposed architecture with 452 re-classification. In Figure 1, to initiate re-classification, the 453 IDS/IPS appends its own inspection result to the MetaData field of 454 NSH and deliver it to the SFF from which it has originally received 455 the traffic. The SFF then forwards the received traffic including 456 the inspection result from the IDS/IPS to Classifier for re- 457 classification. Classifier checks the inspection result and 458 determines the new SFP (SFP-2) associated with the inspection result 459 in the SFC policy, and updates the NSH with the SPI of SFP-2. The 460 traffic is forwarded to the DDoS attack mitigator. 462 SFP-1. AVC:Firewall:IDS/IPS 463 ------------------------------------------------------------------> 464 +-+-+-+-+ +-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 465 | Source|---| AVC |---| Firewall|-----| IDS/IPS |---| Destination | 466 +-+-+-+-+ +-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 467 ----------------------------------------, ,------> 468 \ +-+-+-+-+ / 469 \ | DDoS | / 470 \ +-+-+-+-+ / 471 '----------' 472 SFP-2. AVC:Firewall:DDoS:IDS/IPS 474 Figure 2: Dynamic SFP Alternation Example 476 5.2. Enforcing Different SFPs Depending on Trust Levels 478 Because the traffic coming from a trusted source is highly likely to 479 be harmless, it does not need to be inspected excessively. On the 480 other hand, the traffic coming from an untrusted source requires an 481 in-depth inspection. By applying minimum required security functions 482 to the traffic from a trusted source, it is possible to prevent the 483 unnecessary waste of resources. In addition, we can concentrate more 484 resources on potential malicious traffic. In the SFC-enabled I2NSF 485 architecture, by configuring an SFC Policy to take into account the 486 levels of trust of traffic sources, we can apply different SFPs to 487 the traffic coming from different sources. 489 Figure 3(a) and Figure 3(b) represent SFPs applicable to traffic from 490 trusted and untrusted sources, respectively. In Figure 3(a), we 491 assume a lightweight IDS/IPS which is configured to perform packet 492 header inspection only. In this scenario, when receiving the traffic 493 from a trusted source, the classifier determines the SFP in 494 Figure 3(a) such that the traffic passes through just a simple 495 analysis by the lightweight IDS/IPS. On the other hand, traffic from 496 an untrusted source passes more thorough examination through the SFP 497 in Figure 3(b) which consists of three different types of SFs. 499 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 500 | Source |----------->| IDS/IPS |----------->| Destination | 501 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 503 (a) Traffic flow of trusted source 505 +-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 506 | Source | | Anti-Spoofing | | Destination | 507 +-+-+-+-+-+ | function | +-+-+-+^+-+-+-+ 508 | +-+^+-+-+-+-+-+-+ | 509 | | | | 510 | +-+-+-+-+-+-+ | | +-+-+-+-+-+ | 511 ------->| Firewall |-- ---->| DPI |-- 512 +-+-+-+-+-+-+ +-+-+-+-+-+ 514 (b) Traffic flow of untrusted source 516 Figure 3: Different path allocation depending on source of traffic 518 5.3. Effective Load Balancing with Dynamic SF Instantiation 520 In a large-scale network domain, there typically exist a large number 521 of SF instances that provide various security services. It is 522 possible that a specific SF instance experiences an excessive amount 523 of traffic beyond its capacity. In this case, it is required to 524 allocate some of the traffic to another available instance of the 525 same security function. If there are no additional instances of the 526 same security function available, we need to create a new SF instance 527 and then direct the subsequent traffic to the new instance. In this 528 way, we can avoid service congestion and achieve more efficient 529 resource utilization. This process is commonly called load 530 balancing. 532 In the SFC-enabled I2NSF architecture, SFC Catalog Manager performs 533 periodic monitoring of the load status of available SF instances. In 534 addition, it is possible to dynamically generate a new SF instance 535 through Developer's Management System. With these functionalities 536 along with the flexible traffic steering mechanism, we can eventually 537 provide load balancing service. 539 The following describes the detailed process of load balancing when 540 congestion occurs at the firewall instance: 542 1. SFC Catalog Manager detects that the firewall instance is 543 receiving too much requests. Currently, there are no additional 544 firewall instances available. 546 2. SFC Catalog Manager requests Developer's Management System to 547 create a new firewall instance. 549 3. Developer's Management System creates a new firewall instance and 550 then registers the information of the new firewall instance to 551 SFC Catalog Manager. 553 4. SFC Catalog Manager updates the SFC Information Table to reflect 554 the new firewall instance, and notifies SFC Policy Manager of 555 this update. 557 5. Based on the received information, SFC Policy Manager updates the 558 forwarding information for traffic steering and sends the new 559 forwarding information to the SFF. 561 6. According to the new forwarding information, the SFF forwards the 562 subsequent traffic to the new firewall instance. As a result, we 563 can effecively alleviate the burden of the existing firewall 564 instance. 566 6. Discussion 568 The information model and data model of security policy rules in the 569 I2NSF framework defines an advanced security action as a type of 570 action to be taken on a packet 571 [nsf-capability-im][nsf-facing-inf-dm]. Through the advanced 572 security action, a basic NSF (e.g., firewall) can call a different 573 type of NSF for more in-depth security analysis of a packet. If an 574 NSF triggers an advanced security action on a given packet, the 575 packet should be forwarded to the NSF dedicated to the advanced 576 action. That is, the advanced action dynamically determines the next 577 NSF where the packet should go through. So if a forwarding component 578 is configured with the network access information (e.g., IP address, 579 port number) of the next required NSF, it can forward the packet to 580 the NSF. With this advanced security action, it is possible to avoid 581 the overhead for configuring and managing the information of security 582 function chains and paths. 584 In SFC, re-classification is required to support the situation where 585 the security function path of a packet changes dynamically, and the 586 classifier is responsible for re-classification tasks to change the 587 security function path of a packet. But if the classifier exists as 588 a separate component from an NSF, the packet should be first 589 delivered from the NSF to the classifier for re-classification, and 590 this introduces an additional delay. As already mentioned, the 591 advanced security action in the i2nsf framework can omit the 592 requirement of pre-defined security function chain configuration. If 593 there exists no security function chain/path configurations, there is 594 no need of re-classification as well. That is, the forwarder can 595 simply forward the packet to the next required NSF according to the 596 advanced action determiend by the predesessor NSF, without re- 597 classification through the classifier. 599 7. Security Considerations 601 To enable security function chaining in the I2NSF framework, we adopt 602 the additional components in the SFC architecture. Thus, this 603 document shares the security considerations of the SFC architecture 604 that are specified in [RFC7665] for the purpose of achieving secure 605 communication among components in the proposed architecture. 607 8. Acknowledgements 609 This work was supported by Institute for Information and 610 communications Technology Promotion(IITP) grant funded by the Korea 611 government(MSIP) (No.R-20160222-002755, Cloud based Security 612 Intelligence Technology Development for the Customized Security 613 Service Provisioning). This document has greatly benefited from 614 inputs by Sanguk Woo, Yunsuk Yeo, Taekyun Roh, and Sarang Wee. 616 9. References 617 9.1. Normative References 619 [RFC7665] Halpern, J. and C. Pignataro, "Service 620 Function Chaining (SFC) Architecture", 621 RFC 7665, October 2015. 623 [sfc-nsh] Quinn, P. and U. Elzur, "Network Service 624 Header", draft-ietf-sfc-nsh-12 (work in 625 progress), February 2017. 627 9.2. Informative References 629 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement 630 for Service Function Chaining", RFC 7498, 631 April 2015. 633 [nsf-capability-im] Xia, L., Strassner, J., Basile, C., and D. 634 Lopez, "Information Model of NSFs 635 Capabilities", 636 draft-xibassnez-i2nsf-capability-01 (work in 637 progress), March 2017. 639 [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., and 640 L. Xia, "I2NSF Network Security Functions- 641 Facing Interface YANG Data Model", draft-kim- 642 i2nsf-nsf-facing-interface-data-model-02 643 (work in progress), July 2017. 645 [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., Strassner, 646 J., and R. Kumar, "Framework for Interface to 647 Network Security Functions", 648 draft-ietf-i2nsf-framework-05 (work in 649 progress), May 2017. 651 [i2nsf-problem] Hares, S., Lopez, D., Zarny, M., Jacquenet, 652 C., Kumar, R., and J. Jeong, "I2NSF Problem 653 Statement and Use cases", 654 draft-ietf-i2nsf-problem-and-use-cases-16 655 (work in progress), May 2017. 657 [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., 658 and H. Birkholz, "Interface to Network 659 Security Functions (I2NSF) Terminology", 660 draft-ietf-i2nsf-terminology-03 (work in 661 progress), March 2017. 663 [ONF-SFC-Architecture] ONF, "L4-L7 Service Function Chaining 664 Solution Architecture", June 2015. 666 Appendix A. Changes from draft-hyun-i2nsf-nsf-triggered-steering-02 668 The following changes have been made from 669 draft-hyun-i2nsf-nsf-triggered-steering-02: 671 o Sections 3, 4, and 5 have been revised to describe an 672 architecture, which integrates additional components of service 673 function chaining (SFC) into the I2NSF framework in order to 674 support packet forwarding between NSFs. 676 o Section 6 has been added to discuss some drawbacks when SFC is 677 used for packet forwarding between NSFs in the I2NSF framework. 679 Authors' Addresses 681 Sangwon Hyun 682 Department of Software 683 Sungkyunkwan University 684 2066 Seobu-Ro, Jangan-Gu 685 Suwon, Gyeonggi-Do 16419 686 Republic of Korea 688 Phone: +82 31 290 7222 689 Fax: +82 31 299 6673 690 EMail: swhyun77@skku.edu 691 URI: http://imtl.skku.ac.kr/ 693 Jaehoon Paul Jeong 694 Department of Software 695 Sungkyunkwan University 696 2066 Seobu-Ro, Jangan-Gu 697 Suwon, Gyeonggi-Do 16419 698 Republic of Korea 700 Phone: +82 31 299 4957 701 Fax: +82 31 290 7996 702 EMail: pauljeong@skku.edu 703 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 704 Jung-Soo Park 705 Electronics and Telecommunications Research Institute 706 218 Gajeong-Ro, Yuseong-Gu 707 Daejeon 305-700 708 Republic of Korea 710 Phone: +82 42 860 6514 711 EMail: pjs@etri.re.kr 713 Susan Hares 714 Huawei 715 7453 Hickory Hill 716 Saline, MI 48176 717 USA 719 Phone: +1 734 604 0332 720 EMail: shares@ndzh.com