idnits 2.17.1 draft-hyun-i2nsf-nsf-triggered-steering-02.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2594 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 ** Downref: Normative reference to an Informational RFC: RFC 7348 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 S. Woo 5 Expires: September 14, 2017 Y. Yeo 6 Sungkyunkwan University 7 J. Park 8 ETRI 9 March 13, 2017 11 NSF-triggered Traffic Steering Framework 12 draft-hyun-i2nsf-nsf-triggered-steering-02 14 Abstract 16 This document describes an architecture of the Interface to Network 17 Security Functions (I2NSF) framework which enables traffic steering 18 between Network Security Functions (NSFs) for security policy 19 enforcement. Such traffic steering enables the composite inspection 20 of network traffic by steering the traffic through multiple types of 21 security functions according to the information model for the NSF- 22 facing interface in the I2NSF framework. This document explains the 23 additional components integrated into the I2NSF framework and their 24 functionalities to achieve NSF-triggered traffic steering. It also 25 describes representative use cases to address major benefits from the 26 proposed architecture. 28 Status of This Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on September 14, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. NSF Operation Manager . . . . . . . . . . . . . . . . . . 7 73 4.2. Developer's Management System . . . . . . . . . . . . . . 7 74 4.3. Network Security Function Forwarder (NSFF) . . . . . . . . 8 75 5. Information for Traffic Steering . . . . . . . . . . . . . . . 8 76 5.1. Packet Forwarding Header . . . . . . . . . . . . . . . . . 9 77 5.2. NSF Forwarding Information . . . . . . . . . . . . . . . . 9 78 5.2.1. Query of NSF forwarding information . . . . . . . . . 10 79 5.2.2. Response of NSF forwarding information . . . . . . . . 10 80 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. Enforcing Different NSFs Depending on a Packet 82 Source's Trust Level . . . . . . . . . . . . . . . . . . . 11 83 6.2. Effective Load Balancing with Dynamic NSF Instantiation . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Appendix A. Changes from 90 draft-hyun-i2nsf-nsf-triggered-steering-01 . . . . . 15 92 1. Introduction 94 To effectively cope with emerging sophisticated network attacks, it 95 is necessary that various security functions cooperatively analyze 96 network traffic [sfc-ns-use-cases] [RFC7498] [i2nsf-problem] 97 [capability-im]. In addition, depending on the characteristics of 98 network traffic and their suspiciousness level, the different types 99 of network traffic need to be analyzed through the different sets of 100 security functions. [capability-im] proposes an information model for 101 the interface between a Security Controller and Network Security 102 Functions (NSFs) (called NSF-facing interface) in the Interface to 103 Network Security Functions (I2NSF) framework [i2nsf-framework]. This 104 NSF-facing interface enables an NSF to trigger further inspection by 105 calling another NSF based on its own analysis results. However, the 106 current design of the I2NSF framework does not consider network 107 traffic steering fully in order to enable such consecutive 108 inspections through multiple security functions. 110 In this document, we propose an architecture that integrates 111 additional components for traffic steering over NSFs into the I2NSF 112 framework. We extend the security controller's functionalities such 113 that it can interpret a high-level policy of NSF-triggered traffic 114 steering into a low-level policy and manage them. It also keeps 115 track of the available network security function instances and their 116 information (e.g., network information and workload), and makes a 117 decision on which NSF instances to use for a given network security 118 function. Based on the forwarding information provided by the 119 security controller, the security function forwarder performs network 120 traffic steering through required security functions. The security 121 function forwarder is also responsible for interpreting inspection 122 result from a network security function to enforce more advanced 123 inspection. We define an additional packet header format to specify 124 security inspection results and advanced inspection requests. 126 2. Objective 128 o Policy configuration for consecutive inspections: NSF-triggered 129 traffic steering architecture allows policy configuration and 130 management of network security function triggering. Based on the 131 triggering policy, relevant network traffic can be analyzed 132 through various security functions in a composite, cooperative 133 manner. 135 o Network traffic steering for consecutive inspection: NSF-triggered 136 traffic steering architecture allows network traffic to be steered 137 through multiple required network security functions based on the 138 triggering policy. Moreover, the I2NSF information model for NSF- 139 facing interface [capability-im] requires a security function to 140 call another security function for further inspection based on its 141 own inspection result. To meet this requirement, NSF-triggered 142 traffic steering architecture also enables traffic forwarding from 143 one security function to another security function. 145 o Load balancing over network security function instances: NSF- 146 triggered traffic steering architecture provides load balancing of 147 incoming traffic over available network security function 148 instances by leveraging the flexible traffic steering mechanism. 149 For this objective, it also performs dynamic instantiation of a 150 security function when there are an excessive amount of requests 151 for that network security function. 153 3. Terminology 155 This document uses the terminology described in [RFC7665], [RFC7665] 156 [sfc-ns-use-cases] [i2nsf-terminology][ONF-SFC-Architecture]. 158 o Network Security Function (NSF): A function that is responsible 159 for specific treatment of received packets. A Network Security 160 Function can act at various layers of a protocol stack (e.g., at 161 the network layer or other OSI layers) [RFC7665]. Sample Network 162 Security Service Functions are as follows: Firewall, Intrusion 163 Prevention/Detection System (IPS/IDS), Deep Packet Inspection 164 (DPI), Application Visibility and Control (AVC), network virus and 165 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 166 Denial of Service (DDoS) mitigation and TLS proxy. 168 o Advanced Inspection/Action: As like the I2NSF information model 169 for NSF-facing interface [capability-im], Advanced Inspection/ 170 Action means that a security function calls another security 171 function for further inspection based on its own inspection 172 result. 174 o Network Security Function Profile (NSF Profile): NSF Profile 175 represents NSF's inspection capabilities. Each NSF has its own 176 NSF Profile to specify the type of security service it provides 177 and its resource capacity etc. 179 o Network Security Function Operation Manager (NSF Operation 180 Manager): NSF Operation Manager consistently manages information 181 and state of NSF instances and provides NSF network access 182 information to support advanced inspection request. For example, 183 the information includes the supported transport protocols, IP 184 addresses, and locations for the NSF instances. Also, NSF 185 Operation Manager takes charge of dynamic management of a pool of 186 NSF instances by consulting with Developer's Management System and 187 load balancing over NSF instances. 189 o Packet Forwarding Header/Encapsulation: Packet Forwarding Header 190 is used to forward a packet from one NSF to another for further 191 inspection. The former NSF constructs a Packet Forwarding Header 192 with the NSF profile of the latter NSF and transmits it to a NSFF. 193 The required fields are the action code, the number of the 194 metadata, and the metadata. In this context, the metadata is a 195 part of NSF profile. 197 o Network Security Function Forwarder (NSFF): A security function 198 forwarder is responsible for forwarding traffic to one or more 199 connected network security functions according to the information 200 carried in the packet forwarding encapsulation when the traffic 201 comes back from an NSF. Additionally, an NSFF is responsible for 202 transporting traffic to another NSFF (in the same or the different 203 type of overlay), and terminating overlay inspection [RFC7665]. 205 4. Architecture 207 This section describes an NSF-triggered traffic steering architecture 208 and the basic operations of traffic steering. It also includes 209 details about each component of the architecture. 211 Figure 1 describes the components of NSF-triggered traffic steering 212 architecture. Our architecture enables support a composite 213 inspection of packets in transit. According to the inspection result 214 of each NSF, which is stored in the Packet Forwarding Header, the 215 traffic packets could be steered to another NSF for futher detailed 216 analysis. It is also possible to reflect a high-level advanced 217 inspection policy and a configuration from I2NSF User which is a 218 component of the original I2NSF framwork. Moreover, the proposed 219 architecture provides load balancing, auto supplementary NSF instance 220 generation, and the elimination of unused NSF instances. In order to 221 achieve these design purposes, we integrate several components to the 222 original I2NSF framwork. In the following sections, we explain the 223 details of each component. 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | I2NSF User | 227 | +-+-+-+-+-+-+-+-+ | 228 | |User/ | | 229 | |App Controller | | 230 | +-+-+-+^+-+-+-+-+ | 231 | | | 232 | | | 233 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Consumer Facing Interface 235 | 236 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Security Management System | 238 | | | 239 | +-+-+-+-+-+-+-v-+-+-+-+ | 240 | |Security Controller | | 241 | | +-+-+-+-+-+-+ | Registration | 242 | | | NSF | | Interface +-+-+-+-++-+-+-+-+ | 243 | | | Opeation | |<------------>| Developer's | | 244 | | | Manager | | | Mgnt System |<--+ | 245 | | +-+-+-+-+-+-+ | +-+-+-+-++-+-+-+-+ | | 246 | +-+-+-+-+-+-^-+-+-+-+-+ | | 247 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | NSF-facing interface | 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |Security Network | | | 252 | +-------------------------------------+ | | 253 | | | | | 254 | +-+-+-v-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 255 | | +---------+ +---------+ | | | | 256 | | | NSFF | ... | NSFF | | | | | 257 | | +---------+ +---------+ | | | | 258 | +-+-+-+-+-+-+-+-^-+-+-+-+-+-+-+-+-+ | | | 259 | | | | | 260 | +-+-+-+-+-+-+-+-+-+-+-v-+-+-+-+-+-+-+-+-+-+-+--+ | | | 261 | | +---------+ +---------+ +---------+ |<-+ | | 262 | | | NSF | | NSF | ... | NSF | | | | 263 | | +---------+ +---------+ +---------+ |<---------+ | 264 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 1: NSF-triggered Traffic Steering Architecture 269 4.1. NSF Operation Manager 271 NSF Operation Manager is a core component in our system. It is 272 responsible for the following three things: (1) Maintaining the 273 information of every available NSF instance such as IP address, 274 supported transport protocol, NSF profile, and load status. (2) 275 Responding the queries of available NSF instances from NSFF so as to 276 help to conduct advanced inspection relevant to a given NSF profile. 277 (3) Requesting Developer's Management System for the dynamic 278 instantiation of supplementary NSF instances to avoid service 279 congestion or the elimination of an existing NSF instance to avoid 280 resource waste. As Figure 1 describes, NSF Operation Manager is a 281 sub-module of Security Controller. 283 Whenever a new NSF instance is registered, Developer's Management 284 System passes the information of the registered NSF instance to NSF 285 Operation Manager, so NSF Operation Manager maintains a list of the 286 information of every available NSF instance. NSF Operation Manger 287 will receive the request packet containing NSF profile for advanced 288 inspection from NSFF. Once receiving a query of a certain NSF 289 profile from NSFF, NSF Operation Manager searches for all the 290 available NSF instances applicable for that NSF profile and then 291 finds the best instance with selection criteria like location and 292 load status. After finding the best instance, it returns the search 293 result to NSFF. 295 In our system, each NSF instance periodically reports its load status 296 to NSF Operation Manager. Based on such reports, NSF Operation 297 Manager updates the information of the NSF instances and manages the 298 pool of NSF instances by requesting Developer's Management System for 299 the additional instantiation or elimination of the NSF instances. 300 Consequently, NSF Operation Manager enables efficient resource 301 utilization by avoiding congestion and resource waste. 303 4.2. Developer's Management System 305 We extend Developer's Management System for additional 306 functionalities as follows. As mentioned above, NSF Operation 307 Manager requests Developer's Management System to create additional 308 NSF instances when the existing instances of that security function 309 are congested. On the other hand, when there are an excessive number 310 of instances for a certain security function, NSF Operation Manager 311 requests Developer's Management System to eliminate some of the NSF 312 instances. As a response to such requests, Developer's Management 313 System creates and/or removes NSF instances. Once it creates a new 314 NSF instance or removes an existing NSF instance, the changes must be 315 notified to NSF Operation Manager. 317 4.3. Network Security Function Forwarder (NSFF) 319 It is responsible for the following two functionalities: (1) 320 Initially forwarding the incoming traffic/packets to Network Security 321 Sub-Module, as described in the I2NSF information model for NSF- 322 facing interface [capability-im]. (2) Forwarding the traffic/packets 323 to the matched NSF with the NSF profile which is specified in a 324 Packet Forwarding Header. 326 An NSFF takes a gateway functionality, so it receives incoming 327 traffic/packets first and attaches outer encapsulation in order to 328 forward the traffic/packets to Network Sub-Module [capability-im]. 329 The example of Network Sub-Moudle is a firewall which performs packet 330 header inspection. This Network Security Sub-Module attaches a 331 Packet Forwarding Header between the outer encapsulation and the 332 original packet and specifies NSF Profile in that header so that it 333 can be forwarded to Content Security Sub-Module or Mitigate Sub- 334 Module for advanced inspection. 336 When receiving a packet attached with a packet forwarding header of a 337 specific NSF profile, an NSFF searches for an available NSF instance 338 which provides the network security service corresponding to 339 (matching with) the NSF profile and forward the packet to the NSF 340 instance. If an NSF decides that the packet requires further 341 inspection via another type of network security function, it 342 constructs a packet forwarding header specified with (including) the 343 NSF profile of the advanced network security function, attaches the 344 header to the packet, and then sends the resulting packet to the 345 NSFF. Once receiving the packet, the NSFF checks the NSF profile 346 specified in the packet forwarding header. Then it searches for an 347 NSF instance matching with the NSF profile by consulting with NSF 348 Operation Manager, and finally forwards the packet to the NSF 349 instance. 351 5. Information for Traffic Steering 353 This section describes the details of Packet Forwarding Header and 354 NSF Forwarding Information for traffic forwarding between NSFs in the 355 I2NSF system 357 5.1. Packet Forwarding Header 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Outer Encapsulation | Packet Forwarding Header| Origin Packet | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 / \ 363 +---------+ +-----------+ 364 / \ 365 / \ 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Action Code | SpecInfo Num| SpecInfo 0| ... | SpecInfo n| 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 2: Packet Forwarding Header Format 372 An NSF uses Packet Forwarding Header to inform an NSFF(NSF Forwarder) 373 of its inspection results and/or an advanced security inspection 374 which is further required. As shown in Figure 2, Packet Forwarding 375 Header consists of a single Action Code and a variable number of 376 SpecInfo fields. The Action Code field has a value out of "allow", 377 "deny", "advanced", and "mirror". SpecInfo Num field represents how 378 many SpecInfos are included in this Packet Forwarding Header, and 379 each SpecInfo includes a part of NSF Profile which describes the 380 capabilities of an NSF required for an advanced security inspection. 381 For instance, the value of SepcInfo can be "syn-flood-mitigate", 382 "udp-flood-mitigate" or "content-matching-tcp" etc., which describes 383 the service profile of an NSF. 385 5.2. NSF Forwarding Information 387 The NSF-facing interface takes charge of core functions for steering 388 packets in the I2NSF system. 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | NSF-facing interface | 392 | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 393 | | NSF Queru | |NSF Response | | 394 | | Sub-Model | | Sub-Model | | 395 | +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 3: NSF-facing interface Model Design 400 5.2.1. Query of NSF forwarding information 402 An NSF can request an NSFF to forward packets to another NSF for more 403 advanced security inspection of the packets. In this case, if the 404 NSFF fails to find an NSF that can provide the security capabilities 405 required for the advanced inspection in its forwarding information 406 table, it sends a query to NSF Operation Manager through NSF-facing 407 interface. The query contains an NSF profile which describes the 408 security required for the advanced inspection capabilities. We share 409 the definition of NSF profile in Section 4.4 of [i2nsf-reg-inf-im]. 411 +-+-+-+-+-+-+-+-+-+-+ 412 | NSF Query Message | 413 | | 414 +-+-+-+-+-^-+-+-+-+-+ 415 | 416 | 417 | 418 | 419 +-+-+-+-+-+-+-+-+-+-+ 420 | Inspection Result | 421 | | 422 +-+-+-+-+-+-+-+-+-+-+ 424 Figure 4: NSF Query Message 426 5.2.2. Response of NSF forwarding information 428 NSF Operation Manager maintains an information table of every NSF 429 running in the system. If it receives the query from an NSFF, NSF 430 Operation Manager searches the table for an NSF matching with the NSF 431 profile included in the query. If there are multiple candidate NSFs, 432 NSF Operation Manager could further consider the current workload 433 levels of those NSFs. After choosing an NSF, it notifies the NSFF of 434 the network forwarding information of the chosen NSF. The network 435 forwarding information consists of IPv4 address, IPv6 address, 436 supported transport protocols, and location information. 438 o IP address : As unique indetifier of an NSFs, IP address is the 439 basic network information that allows forwarding packets to the 440 NSF. 442 o Supported Transport Protocol : In order to forward packets to an 443 NSF, it is essential to figure out which transport protocol(s) the 444 NSF supports. Examples of the transport protocols are as follows: 445 Virtual Extensible LAN (VXLAN) [RFC7348], Generic Protocol 446 Extension for VXLAN (VXLAN-GPE) [nvo3-vxlan-gpe], Generic Route 447 Encapsulation (GRE), Ethernet). An NSFF performs encapsulation of 448 the packets to forward as defined in the transport protocol. 450 o Location Information : NSFs in the system can be distributed over 451 a wide physical region. Unlike IP address, location information 452 specifies the physical location of an NSF. Thus, NSF Operation 453 Manager can consider physical proximity as an additional factor to 454 select an NSF. 456 +-+-+-+-+-+-+-+-+-+-+ 457 | NSF Response | 458 | Message | 459 +-+-+-+-+-^-+-+-+-+-+ 460 | 461 +---------+----------------+ 462 | | 463 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 464 | NSF Profile | | NSF forwarding | 465 | | | Information | 466 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 467 | 468 +-----------------------+-----------------------+ 469 | | | 470 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 471 | IP Address | | Supported | | Location | 472 | | | Protocol | | Information | 473 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 475 Figure 5: NSF Response Message 477 6. Use Cases 479 This section introduces two use cases for the NSF-triggered Traffic 480 Steering Framework: (1) Enforcing Different NSFs Depending on a 481 Packet Source's Trust Level, (2) Effective Load Balancing with 482 Dynamic NSF Instantiation. 484 6.1. Enforcing Different NSFs Depending on a Packet Source's Trust 485 Level 487 In the proposed architecture, all incoming packets initially arrive 488 at the NSFF. We assume that the current security policy forces all 489 incoming packets to be by default inspected by a firewall in this 490 scenario. Thus the NSFF forwards the received packets to a firewall 491 instance. Then the firewall identifies the source of the traffic and 492 evaluates the trust level of the source. If the traffic comes from a 493 trusted source, it is likely to be benign. In this case, the traffic 494 is just forwarded to the destination without further detailed 495 inspection via different types of security functions as illustrated 496 in Figure 6-(a). Otherwise if the traffic comes from an untrusted 497 source, the firewall attaches a packet forwarding header including 498 the NSF profile corresponding to DPI to the packet and returns the 499 resulting packet to the NSFF. Once receiving the packet, the NSFF 500 forwards the packet to the DPI instance which will perform detailed 501 inspection for the packet payload. Figure 6-(b) illustrates this 502 case. 504 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 505 | Source |----------->| Firewall |----------->| Destination | 506 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 508 (a) Traffic flow of trusted source 510 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 511 | Source |---->|Firewall |---->| DPI |---->| Destination | 512 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 514 (b) Traffic flow of untrusted source 516 Figure 6: Different path allocation depending on source of traffic 518 6.2. Effective Load Balancing with Dynamic NSF Instantiation 520 In a large-scale network domain, there typically exist a large number 521 of NSF instances that provide various security services. It is 522 possible that a specific NSF 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 NSF 527 instance and then direct the subsequent traffic to the new instance. 528 In this way, we can avoid service congestion and achieve more 529 efficient resource utilization. 531 This process is commonly called load balancing. In our proposed 532 architecture, NSF Operation Manager performs periodic monitoring of 533 the load status of available NSF instances. In addition, it is 534 possible to dynamically generate a new NSF instance through 535 Developer's Management System. With these functionalities along with 536 the flexible traffic steering mechanism, we can eventually provide 537 load balancing service. 539 The following describes the detailed process of load balancing when 540 congestion occurs at the firewall instance: 542 1. NSF Operation Manager detects that the firewall instance is 543 receiving too much requests. Currently, there are no additional 544 firewall instances available. 546 2. NSF Operation 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 NSF Operation Manager. 553 4. NSF Operation Manager updates the SFC Information Table to 554 reflect the new firewall instance, and notifies NSF and NSFF of 555 this update. 557 5. According to the new forwarding information, the NSFF forwards 558 the subsequent traffic to the new firewall instance. As a 559 result, we can effectively alleviate the burden of the existing 560 firewall instance. 562 7. Security Considerations 564 To enable security function chaining in the I2NSF framework, we adopt 565 the additional components in the SFC architecture. Thus, this 566 document shares the security considerations of the SFC architecture 567 that are specified in [RFC7665] for the purpose of achieving secure 568 communication among components in the proposed architecture. 570 8. Acknowledgements 572 This work was supported by Institute for Information and 573 communications Technology Promotion(IITP) grant funded by the Korea 574 government(MSIP) (No.R-20160222-002755, Cloud based Security 575 Intelligence Technology Development for the Customized Security 576 Service Provisioning). 578 9. References 580 9.1. Normative References 582 [RFC7665] Boucadair, M. and C. Jacquenet, "Software- 583 Defined Networking: A Perspective from within 584 a Service Provider Environment", RFC 7665, 585 March 2014. 587 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, 588 P., Kreeger, L., Sridhar, T., Bursell, M., 589 and C. Wright, "Virtual eXtensible Local Area 590 Network (VXLAN): A Framework for Overlaying 591 Virtualized Layer 2 Networks over Layer 3 592 Networks", RFC 7348, August 2014. 594 [sfc-ns-use-cases] Wang, E., Leung, K., Felix, J., and J. Iyer, 595 "Service Function Chaining Use Cases for 596 Network Security", 597 draft-wang-sfc-ns-use-cases-02 , October 598 2016. 600 9.2. Informative References 602 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement 603 for Service Function Chaining", RFC 7498, 604 April 2015. 606 [capability-im] Xia, L., Strassner, J., Basile, C., and D. 607 Lopez, "Information Model of NSFs 608 Capabilities", 609 draft-xibassnez-i2nsf-capability-01 (work in 610 progress), March 2017. 612 [i2nsf-reg-inf-im] Hyun, S., Woo, S., Yeo, Y., Jeong, J., and J. 613 Park, "Registration Interface Information 614 Model", 615 draft-hyun-i2nsf-registration-interface-im-01 616 (work in progress), March 2017. 618 [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., Strassner, 619 J., and R. Kumar, "Framework for Interface to 620 Network Security Functions", 621 draft-ietf-i2nsf-framework-04 (work in 622 progress), October 2016. 624 [i2nsf-problem] Hares, S., Lopez, D., Zarny, M., Jacquenet, 625 C., Kumar, R., and J. Jeong, "I2NSF Problem 626 Statement and Use cases", 627 draft-ietf-i2nsf-problem-and-use-cases-11 628 (work in progress), March 2017. 630 [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., 631 and H. Birkholz, "Interface to Network 632 Security Functions (I2NSF) Terminology", 633 draft-ietf-i2nsf-terminology-03 (work in 634 progress), March 2017. 636 [ONF-SFC-Architecture] ONF, "L4-L7 Service Function Chaining 637 Solution Architecture", June 2015. 639 [nvo3-vxlan-gpe] Maino, F., Kreeger, L., and U. Elzur, 640 "Generic Protocol Extension for VXLAN", 641 draft-ietf-nvo3-vxlan-gpe-03 (work in 642 progress), October 2016. 644 Appendix A. Changes from draft-hyun-i2nsf-nsf-triggered-steering-01 646 The following changes are made from 647 draft-hyun-i2nsf-nsf-triggered-steering-01: 649 o Section 5 is added to explain more details of Packet Forwarding 650 Header and NSF Forwarding Information than the previous version. 652 o In Section 5.1, the explanation of Packet Forwarding Header is 653 clarified more clearly. 655 o In Section 5.2, we specify the details of NSF Forwarding 656 Information. 658 Authors' Addresses 660 Sangwon Hyun 661 Department of Software 662 Sungkyunkwan University 663 2066 Seobu-Ro, Jangan-Gu 664 Suwon, Gyeonggi-Do 16419 665 Republic of Korea 667 Phone: +82 31 290 7222 668 Fax: +82 31 299 6673 669 EMail: swhyun77@skku.edu 670 URI: http://imtl.skku.ac.kr/ 671 Jaehoon Paul Jeong 672 Department of Software 673 Sungkyunkwan University 674 2066 Seobu-Ro, Jangan-Gu 675 Suwon, Gyeonggi-Do 16419 676 Republic of Korea 678 Phone: +82 31 299 4957 679 Fax: +82 31 290 7996 680 EMail: pauljeong@skku.edu 681 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 683 SangUk Woo 684 Department of Software 685 Sungkyunkwan University 686 2066 Seobu-Ro, Jangan-Gu 687 Suwon, Gyeonggi-Do 16419 688 Republic of Korea 690 Phone: +82 31 290 7222 691 Fax: +82 31 299 6673 692 EMail: suwoo@imtl.skku.ac.kr, 693 URI: http://imtl.skku.ac.kr/index.php?mid=member_student 695 YunSuk Yeo 696 Department of Software 697 Sungkyunkwan University 698 2066 Seobu-Ro, Jangan-Gu 699 Suwon, Gyeonggi-Do 16419 700 Republic of Korea 702 Phone: +82 31 290 7222 703 Fax: +82 31 299 6673 704 EMail: yunsuk@imtl.skku.ac.kr, 705 URI: http://imtl.skku.ac.kr/index.php?mid=member_student 707 Jung-Soo Park 708 Electronics and Telecommunications Research Institute 709 218 Gajeong-Ro, Yuseong-Gu 710 Daejeon 305-700 711 Republic of Korea 713 Phone: +82 42 860 6514 714 EMail: pjs@etri.re.kr