idnits 2.17.1 draft-hyun-i2nsf-nsf-triggered-steering-04.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 206: '... classifier MUST use this identif...' RFC 2119 keyword, line 207: '... Control Nodes MUST use this identif...' RFC 2119 keyword, line 211: '... 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 (October 30, 2017) is 2371 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: May 3, 2018 J. Park 6 ETRI 7 S. Hares 8 Huawei 9 October 30, 2017 11 Service Function Chaining-Enabled I2NSF Architecture 12 draft-hyun-i2nsf-nsf-triggered-steering-04 14 Abstract 16 This document describes an architecture of the I2NSF framework using 17 security function chaining for security 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 in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. SFC Policy Manager . . . . . . . . . . . . . . . . . . . 7 66 4.2. SFC Catalog Manager . . . . . . . . . . . . . . . . . . . 7 67 4.3. Developer's Management System . . . . . . . . . . . . . . 8 68 4.4. Classifier . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.5. Service Function Forwarder (SFF) . . . . . . . . . . . . 9 70 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Dynamic Path Alternation . . . . . . . . . . . . . . . . 10 72 5.2. Enforcing Different SFPs Depending on Trust Levels . . . 11 73 5.3. Effective Load Balancing with Dynamic SF Instantiation . 12 74 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7. Implementation Considerations . . . . . . . . . . . . . . . . 13 76 7.1. SFC Policy Configuration and Management . . . . . . . . . 13 77 7.2. Placement of Classifiers . . . . . . . . . . . . . . . . 14 78 7.3. Implementation of Network Tunneling . . . . . . . . . . . 14 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 10.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Appendix A. Changes from draft-hyun-i2nsf-nsf-triggered- 85 steering-03 . . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 To effectively cope with emerging sophisticated network attacks, it 91 is necessary that various security functions cooperatively analyze 92 network traffic [RFC7498][i2nsf-problem][nsf-capability-im]. In 93 addition, depending on the characteristics of network traffic and 94 their suspiciousness level, the different types of network traffic 95 need to be analyzed through the different sets of security functions. 96 In order to meet such requirements, besides security policy rules for 97 individual security functions, we need an additional policy about 98 service function chaining (SFC) for network security which determines 99 a set of security functions through which network traffic packets 100 should pass for inspection. In addition, [nsf-capability-im] 101 proposes an information model for NSFs capabilities that enables a 102 security function to trigger further inspection by executing 103 additional security functions based on its own analysis results 104 [i2nsf-framework]. However, the current design of the I2NSF 105 framework does not consider network traffic steering fully in order 106 to enable such chaining between security functions. 108 In this document, we propose an architecture that integrates 109 additional components from Service Function Chaining (SFC) into the 110 I2NSF framework to support security function chaining. We extend the 111 security controller's functionalities such that it can interpret a 112 high-level policy of security function chaining into a low-level 113 policy and manage them. It also keeps the track of the available 114 service function (SF) instances for security functions and their 115 information (e.g., network information and workload), and makes a 116 decision on which SF instances to use for a given security function 117 chain/path. Based on the forwarding information provided by the 118 security controller, the service function forwarder (SFF) performs 119 network traffic steering through various required security functions. 120 A classifier is deployed for the enforcement of SFC policies given by 121 the security controller. It performs traffic classification based on 122 the polices so that the traffic passes through the required security 123 function chain/path by the SFF. 125 2. Objective 127 o Policy configuration for security function chaining: SFC-enabled 128 I2NSF architecture allows policy configuration and management of 129 security function chaining. Based on the chaining policy, 130 relevant network traffic can be analyzed through various security 131 functions in a composite, cooperative manner. 133 o Network traffic steering for security function chaining: SFC- 134 enabled I2NSF architecture allows network traffic to be steered 135 through multiple required security functions based on the SFC 136 policy. Moreover, the I2NSF information model for NSFs 137 capabilities [nsf-capability-im] requires a security function to 138 call another security function for further inspection based on its 139 own inspection result. To meet this requirement, SFC-enabled 140 I2NSF architecture also enables traffic forwarding from one 141 security function to another security function. 143 o Load balancing over security function instances: SFC-enabled I2NSF 144 architecture provides load balancing of incoming traffic over 145 available security function instances by leveraging the flexible 146 traffic steering mechanism. For this objective, it also performs 147 dynamic instantiation of a security function when there are an 148 excessive amount of requests for that security function. 150 3. Terminology 152 This document uses the following terminology described in [RFC7665], 153 [RFC7665][i2nsf-terminology][ONF-SFC-Architecture]. 155 o Service Function/Security Function (SF): A function that is 156 responsible for specific treatment of received packets. A Service 157 Function can act at various layers of a protocol stack (e.g., at 158 the network layer or other OSI layers) [RFC7665]. In this 159 document, SF is used to represent both Service Function and 160 Security Function. Sample Security Service Functions are as 161 follows: Firewall, Intrusion Prevention/Detection System (IPS/ 162 IDS), Deep Packet Inspection (DPI), Application Visibility and 163 Control (AVC), network virus and malware scanning, sandbox, Data 164 Loss Prevention (DLP), Distributed Denial of Service (DDoS) 165 mitigation and TLS proxy. 167 o Classifier: An element that performs Classification. It uses a 168 given policy from SFC Policy Manager. 170 o Service Function Chain (SFC): A service function chain defines an 171 ordered set of abstract service functions and ordering constraints 172 that must be applied to packets and/or frames and/or flows 173 selected as a result of classification [RFC7665]. 175 o Service Function Forwarder (SFF): A service function forwarder is 176 responsible for forwarding traffic to one or more connected 177 service functions according to information carried in the SFC 178 encapsulation, as well as handling traffic coming back from the 179 SF. Additionally, an SFF is responsible for delivering traffic to 180 a classifier when needed and supported, transporting traffic to 181 another SFF (in the same or the different type of overlay), and 182 terminating the Service Function Path (SFP) [RFC7665]. 184 o Service Function Path (SFP): The service function path is a 185 constrained specification of where packets assigned to a certain 186 service function path must be forwarded. While it may be so 187 constrained as to identify the exact locations for packet 188 processing, it can also be less specific for such locations 189 [RFC7665]. 191 o SFC Policy Manager: It is responsible for translating a high-level 192 policy into a low-level policy, and performing the configuration 193 for SFC-aware nodes, passing the translated policy and 194 configuration to SFC-aware nodes, and maintaining a stabilized 195 network. 197 o SFC Catalog Manager: It is responsible for keeping the track of 198 the information of available SF instances. For example, the 199 information includes the supported transport protocols, IP 200 addresses, and locations for the SF instances. 202 o Control Nodes: It collectively refer to SFC Policy Manager, SFC 203 Catalog Manager, SFF, and Classifier. 205 o Service Path Identifier (SPI): It identifies a service path. The 206 classifier MUST use this identifier for path selection and the 207 Control Nodes MUST use this identifier to find the next hop 208 [sfc-nsh]. 210 o Service Index (SI): It provides a location within the service 211 path. SI MUST be decremented by service functions or proxy nodes 212 after performing the required services [sfc-nsh]. 214 o Network Service Header (NSH): The header is used to carry SFC 215 related information. Basically, SPI and SI should be conveyed to 216 the Control Nodes of SFC via this header. 218 o SF Forwarding Table: SFC Policy Manager maintains this table. It 219 contains all the forwarding information on SFC-enabled I2NSF 220 architecture. Each entry includes SFF identifier, SPI, SI, and 221 next hop information. For example, an entry ("SFF: 1", "SPI: 1", 222 "SI: 1", "IP: 192.168.xx.xx") is interpreted as follows: "SFF 1" 223 should forword the traffic containing "SPI 1" and "SI 1" to 224 "IP=192.168.xx.xx". 226 4. Architecture 228 This section describes an SFC-enabled I2NSF architecture and the 229 basic operations of service chaining. It also includes details about 230 each component of the architecture. 232 Figure 1 describes the components of SFC-enabled I2NSF architecture. 233 Our architecture is designed to support a composite inspection of 234 traffic packets in transit. According to the inspection result of 235 each SF, the traffic packets could be steered to another SF for 236 futher detailed analysis. It is also possible to reflect a high- 237 level SFC-related policy and a configuration from I2NSF Client on the 238 components of the original I2NSF framwork. Moreover, the proposed 239 architecture provides load balancing, auto supplementary SF 240 generation, and the elimination of unused SFs. In order to achieve 241 these design purposes, we integrate several components to the 242 original I2NSF framwork. In the following sections, we explain the 243 details of each component. 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | I2NSF User | 247 | +-+-+-+-+-+-+-+-+ | 248 | |I2NSF User | | 249 | | | | 250 | +-+-+-+^+-+-+-+-+ | 251 | | | 252 | | | 253 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Consumer-Facing Interface 255 | 256 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Security Management System | 258 | | | 259 | +-+-+-+-+-+-+-v-+-+-+-+-+ | 260 | |Security Controller | | 261 | | +-+-+-+-+ +-+-+-+-+ | Registration | 262 | | |SFC | |SFC | | Interface +-+-+-+-++-+-+-+-+ | 263 | | |Policy | |Catalog| |<----------->| Developer's | | 264 | | |Manager| |Manager| | | Mgnt System | | 265 | | +-+-+-+-+ +-+-+-+-+ | +-+-+-+-++-+-+-+-+ | 266 | +-+-+-+-+-+-^-+-+-+-+-+-+ | 267 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | NSF-Facing Interface 269 | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 |Security Network | | 272 | +------------------------------------------------+ | 273 | | | | | 274 | | +-+-+-v-+-+-+ +-+-+-+-+v+-+-+ | 275 | +-+-+-v-++-+ | +-+-+-+ | | +-+-+-+ | | 276 | | | | |SFF1 |<-|---------------->| SF1 | | | 277 | |Classifier|<------> | +-+-+-+< | | +-+-+-+ | | 278 | | | | \| | +-+-+-+ | | 279 | +-+-+-+-++-+ | +-+-+-+ \---------------->| SF2 | | | 280 | | |SFF2 |<-|---------------/ +-+-+-+ | | 281 | | +-+-+-+<-|-------------\ +-+-+-+ | | 282 | +-+-+-+-+-+-+ \->| SF3 | | | 283 | | +-+-+-+ | | 284 | +-+-+-+-+-+-+-+ | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1: SFC-enabled I2NSF 289 4.1. SFC Policy Manager 291 SFC Policy Manager is a core component in our system. It is 292 responsible for the following two things: (1) Interpreting a high- 293 level SFC policy (or configuration) into a low-level SFC policy (or 294 configuration), which is given by I2NSF Client, and delivering the 295 interpreted policy to Classifiers for security function chaining. (2) 296 Generating an SF forwarding table and distributing the fowarding 297 information to SFF(s) by consulting with SFC Catalog Manager. As 298 Figure 1 describes, SFC Policy Manager performs these additional 299 functionalities through Consumer-Facing Interface and NSF-Facing 300 Interface. 302 Given a high-level SFC policy/configuration from I2NSF Client via 303 Consumer-Facing Interface, SFC Policy Manager interprets it into a 304 low-level policy/configuration comprehensible to Classifier(s), and 305 then delivers the resulting low-level policy to them. Moreover, SFC 306 Policy Manager possibly generates new policies for the flexible 307 change of traffic steering to rapidly react to the current status of 308 SFs. For instance, it could generate new rules to forward all 309 subsequent packets to "Firewall Instance 2" instead of "Firewall 310 Instance 1" in the case where "Firewall Instance 1" is under 311 congestion. 313 SFC Policy Manager gets information about SFs from SFC Catalog 314 Manager to generate SF forwarding table. In the table generation 315 process, SFC Policy Manager considers various criteria such as SFC 316 policies, SF load status, SF physical location, and supported 317 transport protocols. An entry of the SF forwarding table consists of 318 SFF Identifier, SFP, SI, and next hop information. The examples of 319 next hop information includes the IP address and supported transport 320 protocols (e.g., VxLAN and GRE). These forwarding table updates are 321 distributed to SFFs with either push or pull methods. 323 4.2. SFC Catalog Manager 325 In Figure 1, SFC Catalog Manager is a component integrated into 326 Security Controller. It is responsible for the following three 327 things: (1) Maintaining the information of every available SF 328 instance such as IP address, supported transport protocol, service 329 name, and load status. (2) Responding to the queries of available SF 330 instances from SFC Policy Manager so as to help to generate a 331 forwarding table entry relevant to a given SFP. (3) Requesting 332 Developer's Management System to dynamically instantiate 333 supplementary SF instances to avoid service congestion or the 334 elimination of an existing SF instance to avoid resource waste. 336 Whenever a new SF instance is registered, Developer's Management 337 System passes the information of the registered SF instance to SFC 338 Catalog Manager, so SFC Catalog Manager maintains a list of the 339 information of every available SF instance. Once receiving a query 340 of a certain SFP from SFC Policy Manager, SFC Catalog Manager 341 searches for all the available SF instances applicable for that SFP 342 and then returns the search result to SFC Policy Manager. 344 In our system, each SF instance periodically reports its load status 345 to SFC Catalog Manager. Based on such reports, SFC Catalog Manager 346 updates the information of the SF instances and manages the pool of 347 SF instances by requesting Developer's Management System for the 348 additional instantiation or elimination of the SF instances. 349 Consequently, SFC Catalog Manager enables efficient resource 350 utilization by avoiding congestion and resource waste. 352 4.3. Developer's Management System 354 We extend Developer's Management System for additional 355 functionalities as follows. As mentioned above, the SFC Catalog 356 Manager requests the Developer's Management System to create 357 additional SF instances when the existing instances of that service 358 function are congested. On the other hand, when there are an 359 excessive number of instances for a certain service function, the SFC 360 Policy Manager requests the Developer's Management System to 361 eliminate some of the SF instances. As a response to such requests, 362 the Developer's Management System creates and/or removes SF 363 instances. Once it creates a new SF instance or removes an existing 364 SF instance, the changes must be notified to the SFC Catalog Manager. 366 4.4. Classifier 368 Classifier is a logical component that may exist as a standalone 369 component or a submodule of another component. In our system, the 370 initial classifier is typically located at an entry point like a 371 border router of the network domain, and performs the initial 372 classification of all incoming packets according to the SFC policies, 373 which are given by SFC policy manager. The classification means 374 determining the SFP through which a given packet should pass. Once 375 the SFP is decided, the classifier constructs an NSH that specifies 376 the corresponding SPI and SI, and attaches it to the packet. The 377 packet will then be forwarded through the determined SFP on the basis 378 of the NSH information. 380 4.5. Service Function Forwarder (SFF) 382 It is responsible for the following two functionalities: (1) 383 Forwarding the packets to the next SFF/SF. (2) Handling re- 384 classification request from SF. 386 An SFF basically takes forwarding functionality, so it needs to find 387 the next SF/SFF for the incoming traffic. It will search its 388 forwarding table to find the next hop information that corresponds to 389 the given traffic. In the case where the SFF finds a target entry on 390 its forwarding table, it just forwards the traffic to the next SF/SFF 391 specified in the next hop information. If an SFF does not have an 392 entry for a given packet, it will request the next hop information to 393 SFC Policy Manager with SFF identifier, SPI, and SI information. The 394 SFC Policy Manager will respond to the SFF with next hop information, 395 and then the SFF updates its forwarding table with the response, 396 forwarding the traffic to the next hop. 398 Sometimes an SF may want to forward a packet, which is highly 399 suspicious, to another SF for futher security inspection. This is 400 referred to as advanced security action in I2NSF. In this situation, 401 if the next SF may not be the one on the current SFP of the packet, 402 re-classification is required to change the SFP of the packet. If 403 the current SF is capable of re-classifying the packet by itself, the 404 SF updates the SPI field in the NSH in the packet to serve the 405 advanced secuity action. Otherwise, if the classifier exists as a 406 standalone, the SF appends the inspection result of the packet to the 407 MetaData field of the NSH and delivers it to the source SFF. The 408 attached MetaData includes a re-classification request to change the 409 SFP of the packet to another SFP for stronger inspection. When the 410 SFF receives the traffic requiring re-classification, it forwards the 411 traffic to the Classifier where re-classification will be eventually 412 performed. 414 SFC defines Rendered Service Path (RSP), which represents the 415 sequence of actual visits by a packet to SFFs and SFs [RFC7665]. If 416 the RSP information of a packet is available, the SFF could check 417 this RSP information to detect whether undesired looping happened on 418 the packet. If the SFF detects looping, it could notify the Security 419 Controller of this looping, and the Security Controller could modify 420 relevant security policy rules to resolve this looping. 422 5. Use Cases 424 This section introduces three use cases for the SFC-enabled I2NSF 425 architecture : (1) Dynamic Path Alternation, (2) Enforcing Different 426 SFPs Depending on Trust Levels, and (3) Effective Load Balancing with 427 Dynamic SF Instantiation. 429 5.1. Dynamic Path Alternation 431 In SFC-enabled I2NSF architecture, a Classifier determines the 432 initial SFP of incoming traffic according to the SFC policies. The 433 classifier then attaches an NSH specifying the determined SFP of the 434 packets, and they are analyzed through the SFs of the initial SFP. 435 However, SFP is not a static property, so it could be changed 436 dynamically through re-classification. A typical example is for a 437 certain SF in the initial SFP to detect that the traffic is highly 438 suspicious (likely to be malicious). In this case, the traffic needs 439 to take stronger inspection through a different SFP which consists of 440 more sophisticated SFs. 442 Figure 2 illustrates an example of such dynamic SFP alternation in a 443 DDoS attack scenario. SFP-1 represents the default Service Function 444 Path that the traffic initially follows, and SFP-1 consists of AVC, 445 Firewall, and IDS/IPS. If the IDS/IPS suspects that the traffic is 446 attempting DDoS attacks, it will change the SFP of the traffic from 447 the default to SFP-2 so that the DDoS attack mitigator can execute a 448 proper countermeasure against the attack. 450 Such SFP alternation is possible in the proposed architecture with 451 re-classification. In Figure 1, to initiate re-classification, the 452 IDS/IPS appends its own inspection result to the MetaData field of 453 NSH and deliver it to the SFF from which it has originally received 454 the traffic. The SFF then forwards the received traffic including 455 the inspection result from the IDS/IPS to Classifier for re- 456 classification. Classifier checks the inspection result and 457 determines the new SFP (SFP-2) associated with the inspection result 458 in the SFC policy, and updates the NSH with the SPI of SFP-2. The 459 traffic is forwarded to the DDoS attack mitigator. 461 SFP-1. AVC:Firewall:IDS/IPS 462 ------------------------------------------------------------------> 463 +-+-+-+-+ +-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 464 | Source|---| AVC |---| Firewall|-----| IDS/IPS |---| Destination | 465 +-+-+-+-+ +-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 466 ----------------------------------------, ,------> 467 \ +-+-+-+-+ / 468 \ | DDoS | / 469 \ +-+-+-+-+ / 470 '----------' 471 SFP-2. AVC:Firewall:DDoS:IDS/IPS 473 Figure 2: Dynamic SFP Alternation Example 475 5.2. Enforcing Different SFPs Depending on Trust Levels 477 Because the traffic coming from a trusted source is highly likely to 478 be harmless, it does not need to be inspected excessively. On the 479 other hand, the traffic coming from an untrusted source requires an 480 in-depth inspection. By applying minimum required security functions 481 to the traffic from a trusted source, it is possible to prevent the 482 unnecessary waste of resources. In addition, we can concentrate more 483 resources on potential malicious traffic. In the SFC-enabled I2NSF 484 architecture, by configuring an SFC Policy to take into account the 485 levels of trust of traffic sources, we can apply different SFPs to 486 the traffic coming from different sources. 488 Figure 3(a) and Figure 3(b) represent SFPs applicable to traffic from 489 trusted and untrusted sources, respectively. In Figure 3(a), we 490 assume a lightweight IDS/IPS which is configured to perform packet 491 header inspection only. In this scenario, when receiving the traffic 492 from a trusted source, the classifier determines the SFP in 493 Figure 3(a) such that the traffic passes through just a simple 494 analysis by the lightweight IDS/IPS. On the other hand, traffic from 495 an untrusted source passes more thorough examination through the SFP 496 in Figure 3(b) which consists of three different types of SFs. 498 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 499 | Source |----------->| IDS/IPS |----------->| Destination | 500 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 502 (a) Traffic flow of trusted source 504 +-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 505 | Source | | Anti-Spoofing | | Destination | 506 +-+-+-+-+-+ | function | +-+-+-+^+-+-+-+ 507 | +-+^+-+-+-+-+-+-+ | 508 | | | | 509 | +-+-+-+-+-+-+ | | +-+-+-+-+-+ | 510 ------->| Firewall |-- ---->| DPI |-- 511 +-+-+-+-+-+-+ +-+-+-+-+-+ 513 (b) Traffic flow of untrusted source 515 Figure 3: Different path allocation depending on source of traffic 517 5.3. Effective Load Balancing with Dynamic SF Instantiation 519 In a large-scale network domain, there typically exist a large number 520 of SF instances that provide various security services. It is 521 possible that a specific SF instance experiences an excessive amount 522 of traffic beyond its capacity. In this case, it is required to 523 allocate some of the traffic to another available instance of the 524 same security function. If there are no additional instances of the 525 same security function available, we need to create a new SF instance 526 and then direct the subsequent traffic to the new instance. In this 527 way, we can avoid service congestion and achieve more efficient 528 resource utilization. This process is commonly called load 529 balancing. 531 In the SFC-enabled I2NSF architecture, SFC Catalog Manager performs 532 periodic monitoring of the load status of available SF instances. In 533 addition, it is possible to dynamically generate a new SF instance 534 through Developer's Management System. With these functionalities 535 along with the flexible traffic steering mechanism, we can eventually 536 provide load balancing service. 538 The following describes the detailed process of load balancing when 539 congestion occurs at the firewall instance: 541 1. SFC Catalog Manager detects that the firewall instance is 542 receiving too much requests. Currently, there are no additional 543 firewall instances available. 545 2. SFC Catalog Manager requests Developer's Management System to 546 create a new firewall instance. 548 3. Developer's Management System creates a new firewall instance and 549 then registers the information of the new firewall instance to 550 SFC Catalog Manager. 552 4. SFC Catalog Manager updates the SFC Information Table to reflect 553 the new firewall instance, and notifies SFC Policy Manager of 554 this update. 556 5. Based on the received information, SFC Policy Manager updates the 557 forwarding information for traffic steering and sends the new 558 forwarding information to the SFF. 560 6. According to the new forwarding information, the SFF forwards the 561 subsequent traffic to the new firewall instance. As a result, we 562 can effecively alleviate the burden of the existing firewall 563 instance. 565 6. Discussion 567 The information model and data model of security policy rules in the 568 I2NSF framework defines an advanced security action as a type of 569 action to be taken on a packet 570 [nsf-capability-im][nsf-facing-inf-dm]. Through the advanced 571 security action, a basic NSF (e.g., firewall) can call a different 572 type of NSF for more in-depth security analysis of a packet. If an 573 NSF triggers an advanced security action on a given packet, the 574 packet should be forwarded to the NSF dedicated to the advanced 575 action. That is, the advanced action dynamically determines the next 576 NSF where the packet should go through. So if a forwarding component 577 is configured with the network access information (e.g., IP address, 578 port number) of the next required NSF, it can forward the packet to 579 the NSF. With this advanced security action, it is possible to avoid 580 the overhead for configuring and managing the information of security 581 function chains and paths. 583 In SFC, re-classification is required to support the situation where 584 the security function path of a packet changes dynamically, and the 585 classifier is responsible for re-classification tasks to change the 586 security function path of a packet. But if the classifier exists as 587 a separate component from an NSF, the packet should be first 588 delivered from the NSF to the classifier for re-classification, and 589 this introduces an additional delay. As already mentioned, the 590 advanced security action in the i2nsf framework can omit the 591 requirement of pre-defined security function chain configuration. If 592 there exists no security function chain/path configurations, there is 593 no need of re-classification as well. That is, the forwarder can 594 simply forward the packet to the next required NSF according to the 595 advanced action determiend by the predesessor NSF, without re- 596 classification through the classifier. 598 7. Implementation Considerations 600 7.1. SFC Policy Configuration and Management 602 In the SFC-enabled I2NSF architecture, SFC policy configuration and 603 management should be considered to realize NSF chaining for packets. 604 According to the given SFC policy, a classifier is configured with 605 the corresponding NSF chain/path information, and also an SFF is 606 configured with a forwarding information table. 608 The following three interfaces need to be considered for SFC policy 609 configuration and management. First of all, the network 610 administrator, typically an I2NSF user, needs to send SFC policy 611 configuration information that should be enforced in the system to 612 the security controller. Thus an interface between the network 613 administrator and the security controller should be set up for this 614 objective. By analyzing the given SFC policy configuration 615 information, the security controller generates NSF chain/path 616 information required for classifiers and forwarding information table 617 of NSFs that SFFs require for packet forwarding. An interface 618 between the security controller and classifier is required to deliver 619 NSF chain/path information to the classifier. In addition, an 620 interface between the security controller and SFF is also required to 621 deliver forwarding information table of NSFs to SFFs. 623 When there are multiple instances of classifiers and SFFs, 624 synchronizing the configuration information over them is important 625 for them to have a consistent view of the configuration information. 626 Therefore it should be considered how to synchronize the 627 configuration information over the classifiers and SFFs. 629 7.2. Placement of Classifiers 631 To implement the SFC-enabled I2NSF architecture, it needs to be 632 considered where to place the classifier. There are three possible 633 options: NSF, SFF, and a separate component. The first option is 634 integrating a classifier into every NSF. This approach is good for 635 re-classification, because each NSF itself can perform re- 636 classification without introducing any additional network overhead. 637 On the other hand, configuring every NSF with NSF chain/path 638 information and maintaining their consistency introduce an extra 639 overhead. The second option is integrating a classifier into a SFF. 640 In general, since the number of SFFs is much smaller than the number 641 of NSFs, the overhead for configuring and managing NSF chain/path 642 information would be smaller than the first option. In this case, 643 re-classification of a packet should be done at a SFF rather than an 644 NSF. The third option is that a classifier operates as a standalone 645 entity. In this case, whenever re-classification is required for a 646 packet, the packet should first stop by the classifier before going 647 through a SFF, and this is likely to increase packet delivery 648 latency. 650 7.3. Implementation of Network Tunneling 652 Tunneling protocols can be utilized to support packet forwarding 653 between SFF and NSF or SFC proxy [RFC7665] . In this case, it needs 654 to be considered which tunneling protocol to use, and both SFF and 655 NSF/SFC proxy should support the same tunneling protocols. If an NSF 656 itself should handle the tunneling protocol, it is required to modify 657 the NSF implementation to make it understand the tunneling protocol. 658 When there are diverse NSFs developed by different vendors, how to 659 modify efficiently those NSFs to support the tunneling protocol is an 660 critical issue to reduce the maintenance cost of NSFs after 661 deployment. 663 We implemented network tunnleing based on GRE (Generic Routing 664 Encapsulation) protocol to support packet forwarding between SFF and 665 SFC proxy. For the NSH encapsulation with GRE protocol in layer 3, 666 we referred to the header format defined in [Network-Service-Header]. 667 Figure 4 shows the format of an entire packet in our implementation, 668 and Figure 5 shows the mapping table of service path identifiers used 669 in our implementation. 671 +----------+----------------------+-------------+ 672 |L2 header | L3 header(Outer IP), | GRE header, | 673 | | protocol=47 | PT=0x894F | 674 | | | | 675 +----------+----------------------+-------------+ 676 -----------+----------------+ 677 NSH, NP=0x1| | 678 SPI=1 |original packet | 679 SI=1 | | 680 -----------+----------------+ 682 Figure 4: Entire packet format for network tunneling based on GRE 683 protocol 685 +------+-------------------------------+ 686 | SPI | Network security function | 687 +------+-------------------------------+ 688 | 1 | Firewall | 689 +------+-------------------------------+ 690 | 2 | Firewall->DPI | 691 +------+-------------------------------+ 692 | 3 | Firewall->DPI->DDoS metigation| 693 +------+-------------------------------+ 695 Figure 5: Mapping table of service path identifiers 697 8. Security Considerations 699 To enable security function chaining in the I2NSF framework, we adopt 700 the additional components in the SFC architecture. Thus, this 701 document shares the security considerations of the SFC architecture 702 that are specified in [RFC7665] for the purpose of achieving secure 703 communication among components in the proposed architecture. 705 9. Acknowledgements 707 This work was supported by Institute for Information and 708 communications Technology Promotion(IITP) grant funded by the Korea 709 government(MSIP) (No.R-20160222-002755, Cloud based Security 710 Intelligence Technology Development for the Customized Security 711 Service Provisioning). This document has greatly benefited from 712 inputs by Sanguk Woo, Yunsuk Yeo, Taekyun Roh, and Sarang Wee. 714 10. References 716 10.1. Normative References 718 [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining 719 (SFC) Architecture", RFC 7665, October 2015. 721 [sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header (NSH)", 722 draft-ietf-sfc-nsh-27 (work in progress), October 2017. 724 10.2. Informative References 726 [i2nsf-framework] 727 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 728 Kumar, "Framework for Interface to Network Security 729 Functions", draft-ietf-i2nsf-framework-08 (work in 730 progress), October 2017. 732 [i2nsf-problem] 733 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 734 and J. Jeong, "I2NSF Problem Statement and Use cases", 735 RFC 8192, July 2017. 737 [i2nsf-terminology] 738 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 739 Birkholz, "Interface to Network Security Functions (I2NSF) 740 Terminology", draft-ietf-i2nsf-terminology-04 (work in 741 progress), July 2017. 743 [Network-Service-Header] 744 P. Quinn, Ed, Cisco Systems, Inc, and U. Elzur, Ed., 745 "Network Service Header", May 2016. 747 [nsf-capability-im] 748 Xia, L., Strassner, J., Basile, C., and D. Lopez, 749 "Information Model of NSFs Capabilities", draft-ietf- 750 i2nsf-capability-00 (work in progress), September 2017. 752 [nsf-facing-inf-dm] 753 Kim, J., Jeong, J., Park, J., Hares, S., and L. Xia, 754 "I2NSF Network Security Functions-Facing Interface YANG 755 Data Model", draft-kim-i2nsf-nsf-facing-interface-data- 756 model-03 (work in progress), October 2017. 758 [ONF-SFC-Architecture] 759 ONF, "L4-L7 Service Function Chaining Solution 760 Architecture", June 2015. 762 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 763 Function Chaining", RFC 7498, April 2015. 765 Appendix A. Changes from draft-hyun-i2nsf-nsf-triggered-steering-03 767 The following changes have been made from draft-hyun-i2nsf-nsf- 768 triggered-steering-03: 770 o Section 7 has been added to discuss implementation considerations 771 of the SFC-enabled I2NSF architecture. 773 o The references have been updated to reflect the latest documents. 775 Authors' Addresses 777 Sangwon Hyun 778 Department of Software 779 Sungkyunkwan University 780 2066 Seobu-Ro, Jangan-Gu 781 Suwon, Gyeonggi-Do 16419 782 Republic of Korea 784 Phone: +82 31 290 7222 785 Fax: +82 31 299 6673 786 EMail: swhyun77@skku.edu 787 URI: http://imtl.skku.ac.kr/ 789 Jaehoon Paul Jeong 790 Department of Software 791 Sungkyunkwan University 792 2066 Seobu-Ro, Jangan-Gu 793 Suwon, Gyeonggi-Do 16419 794 Republic of Korea 796 Phone: +82 31 299 4957 797 Fax: +82 31 290 7996 798 EMail: pauljeong@skku.edu 799 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 801 Jung-Soo Park 802 Electronics and Telecommunications Research Institute 803 218 Gajeong-Ro, Yuseong-Gu 804 Daejeon 305-700 805 Republic of Korea 807 Phone: +82 42 860 6514 808 EMail: pjs@etri.re.kr 809 Susan Hares 810 Huawei 811 7453 Hickory Hill 812 Saline, MI 48176 813 USA 815 Phone: +1 734 604 0332 816 EMail: shares@ndzh.com