idnits 2.17.1 draft-hyun-i2nsf-nsf-triggered-steering-06.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 209: '... classifier MUST use this identif...' RFC 2119 keyword, line 210: '... Control Nodes MUST use this identif...' RFC 2119 keyword, line 214: '... 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 2, 2018) is 2122 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenFlow' ** Downref: Normative reference to an Informational RFC: RFC 3378 ** Downref: Normative reference to an Informational RFC: RFC 7047 ** Downref: Normative reference to an Informational RFC: RFC 7665 -- Possible downref: Non-RFC (?) normative reference: ref. 'StEERING' Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hyun 3 Internet-Draft Chosun University 4 Intended status: Standards Track J. Jeong 5 Expires: January 3, 2019 Sungkyunkwan University 6 J. Park 7 ETRI 8 S. Hares 9 Huawei 10 July 2, 2018 12 Service Function Chaining-Enabled I2NSF Architecture 13 draft-hyun-i2nsf-nsf-triggered-steering-06 15 Abstract 17 This document describes an architecture of the I2NSF framework using 18 security function chaining for security policy enforcement. Security 19 function chaining enables composite inspection of network traffic by 20 steering the traffic through multiple types of network security 21 functions according to the information model for NSFs capabilities in 22 the I2NSF framework. This document explains the additional 23 components integrated into the I2NSF framework and their 24 functionalities to achieve security function chaining. 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 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). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 3, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. SFC Policy Manager . . . . . . . . . . . . . . . . . . . 8 67 4.2. SFC Catalog Manager . . . . . . . . . . . . . . . . . . . 8 68 4.3. Developer's Management System . . . . . . . . . . . . . . 9 69 4.4. Classifier . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.5. Service Function Forwarder (SFF) . . . . . . . . . . . . 10 71 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Dynamic Path Alternation . . . . . . . . . . . . . . . . 11 73 5.2. Enforcing Different SFPs Depending on Trust Levels . . . 12 74 5.3. Effective Load Balancing with Dynamic SF Instantiation . 13 75 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7. Implementation Considerations . . . . . . . . . . . . . . . . 14 77 7.1. SFC Policy Configuration and Management . . . . . . . . . 14 78 7.2. Placement of Classifiers . . . . . . . . . . . . . . . . 15 79 7.3. Forwarding Method of SFC . . . . . . . . . . . . . . . . 15 80 7.4. Implementation of Network Tunneling . . . . . . . . . . . 16 81 7.5. Implementation of SFC using Opendaylight Controller . . . 17 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 10.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Appendix A. Changes from draft-hyun-i2nsf-nsf-triggered- 88 steering-05 . . . . . . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 To effectively cope with emerging sophisticated network attacks, it 94 is necessary that various security functions cooperatively analyze 95 network traffic [RFC7498][i2nsf-problem][nsf-capability-im]. In 96 addition, depending on the characteristics of network traffic and 97 their suspiciousness level, the different types of network traffic 98 need to be analyzed through the different sets of security functions. 99 In order to meet such requirements, besides security policy rules for 100 individual security functions, we need an additional policy about 101 service function chaining (SFC) for network security which determines 102 a set of security functions through which network traffic packets 103 should pass for inspection. In addition, [nsf-capability-im] 104 proposes an information model for NSFs capabilities that enables a 105 security function to trigger further inspection by executing 106 additional security functions based on its own analysis results 107 [i2nsf-framework]. However, the current design of the I2NSF 108 framework does not consider network traffic steering fully in order 109 to enable such chaining between security functions. 111 In this document, we propose an architecture that integrates 112 additional components from Service Function Chaining (SFC) into the 113 I2NSF framework to support security function chaining. We extend the 114 security controller's functionalities such that it can interpret a 115 high-level policy of security function chaining into a low-level 116 policy and manage them. It also keeps the track of the available 117 service function (SF) instances for security functions and their 118 information (e.g., network information and workload), and makes a 119 decision on which SF instances to use for a given security function 120 chain/path. Based on the forwarding information provided by the 121 security controller, the service function forwarder (SFF) performs 122 network traffic steering through various required security functions. 123 A classifier is deployed for the enforcement of SFC policies given by 124 the security controller. It performs traffic classification based on 125 the polices so that the traffic passes through the required security 126 function chain/path by the SFF. 128 2. Objective 130 o Policy configuration for security function chaining: SFC-enabled 131 I2NSF architecture allows policy configuration and management of 132 security function chaining. Based on the chaining policy, 133 relevant network traffic can be analyzed through various security 134 functions in a composite, cooperative manner. 136 o Network traffic steering for security function chaining: SFC- 137 enabled I2NSF architecture allows network traffic to be steered 138 through multiple required security functions based on the SFC 139 policy. Moreover, the I2NSF information model for NSFs 140 capabilities [nsf-capability-im] requires a security function to 141 call another security function for further inspection based on its 142 own inspection result. To meet this requirement, SFC-enabled 143 I2NSF architecture also enables traffic forwarding from one 144 security function to another security function. 146 o Load balancing over security function instances: SFC-enabled I2NSF 147 architecture provides load balancing of incoming traffic over 148 available security function instances by leveraging the flexible 149 traffic steering mechanism. For this objective, it also performs 150 dynamic instantiation of a security function when there are an 151 excessive amount of requests for that security function. 153 3. Terminology 155 This document uses the following terminology described in [RFC7665], 156 [RFC7665][i2nsf-terminology][ONF-SFC-Architecture]. 158 o Service Function/Security Function (SF): A function that is 159 responsible for specific treatment of received packets. A Service 160 Function can act at various layers of a protocol stack (e.g., at 161 the network layer or other OSI layers) [RFC7665]. In this 162 document, SF is used to represent both Service Function and 163 Security Function. Sample Security Service Functions are as 164 follows: Firewall, Intrusion Prevention/Detection System (IPS/ 165 IDS), Deep Packet Inspection (DPI), Application Visibility and 166 Control (AVC), network virus and malware scanning, sandbox, Data 167 Loss Prevention (DLP), Distributed Denial of Service (DDoS) 168 mitigation and TLS proxy. 170 o Classifier: An element that performs Classification. It uses a 171 given policy from SFC Policy Manager. 173 o Service Function Chain (SFC): A service function chain defines an 174 ordered set of abstract service functions and ordering constraints 175 that must be applied to packets and/or frames and/or flows 176 selected as a result of classification [RFC7665]. 178 o Service Function Forwarder (SFF): A service function forwarder is 179 responsible for forwarding traffic to one or more connected 180 service functions according to information carried in the SFC 181 encapsulation, as well as handling traffic coming back from the 182 SF. Additionally, an SFF is responsible for delivering traffic to 183 a classifier when needed and supported, transporting traffic to 184 another SFF (in the same or the different type of overlay), and 185 terminating the Service Function Path (SFP) [RFC7665]. 187 o Service Function Path (SFP): The service function path is a 188 constrained specification of where packets assigned to a certain 189 service function path must be forwarded. While it may be so 190 constrained as to identify the exact locations for packet 191 processing, it can also be less specific for such locations 192 [RFC7665]. 194 o SFC Policy Manager: It is responsible for translating a high-level 195 policy into a low-level policy, and performing the configuration 196 for SFC-aware nodes, passing the translated policy and 197 configuration to SFC-aware nodes, and maintaining a stabilized 198 network. 200 o SFC Catalog Manager: It is responsible for keeping the track of 201 the information of available SF instances. For example, the 202 information includes the supported transport protocols, IP 203 addresses, and locations for the SF instances. 205 o Control Nodes: It collectively refer to SFC Policy Manager, SFC 206 Catalog Manager, SFF, and Classifier. 208 o Service Path Identifier (SPI): It identifies a service path. The 209 classifier MUST use this identifier for path selection and the 210 Control Nodes MUST use this identifier to find the next hop 211 [RFC8300]. 213 o Service Index (SI): It provides a location within the service 214 path. SI MUST be decremented by service functions or proxy nodes 215 after performing the required services [RFC8300]. 217 o Network Service Header (NSH): The header is used to carry SFC 218 related information. Basically, SPI and SI should be conveyed to 219 the Control Nodes of SFC via this header. 221 o SF Forwarding Table: SFC Policy Manager maintains this table. It 222 contains all the forwarding information on SFC-enabled I2NSF 223 architecture. Each entry includes SFF identifier, SPI, SI, and 224 next hop information. For example, an entry ("SFF: 1", "SPI: 1", 225 "SI: 1", "IP: 192.168.xx.xx") is interpreted as follows: "SFF 1" 226 should forword the traffic containing "SPI 1" and "SI 1" to 227 "IP=192.168.xx.xx". 229 4. Architecture 231 This section describes an SFC-enabled I2NSF architecture and the 232 basic operations of service chaining. It also includes details about 233 each component of the architecture. 235 Figure 1 describes the components of SFC-enabled I2NSF architecture. 236 Our architecture is designed to support a composite inspection of 237 traffic packets in transit. According to the inspection result of 238 each SF, the traffic packets could be steered to another SF for 239 futher detailed analysis. It is also possible to reflect a high- 240 level SFC-related policy and a configuration from I2NSF Client on the 241 components of the original I2NSF framwork. Moreover, the proposed 242 architecture provides load balancing, auto supplementary SF 243 generation, and the elimination of unused SFs. In order to achieve 244 these design purposes, we integrate several components to the 245 original I2NSF framwork. In the following sections, we explain the 246 details of each component. 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | I2NSF User | 250 | +-+-+-+-+-+-+-+-+ | 251 | |I2NSF User | | 252 | | | | 253 | +-+-+-+^+-+-+-+-+ | 254 | | | 255 | | | 256 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Consumer-Facing Interface 258 | 259 +-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Security Management System | 261 | | | 262 | +-+-+-+-+-+-+-v-+-+-+-+-+ | 263 | |Security Controller | | 264 | | +-+-+-+-+ +-+-+-+-+ | Registration | 265 | | |SFC | |SFC | | Interface +-+-+-+-++-+-+-+-+ | 266 | | |Policy | |Catalog| |<----------->| Developer's | | 267 | | |Manager| |Manager| | | Mgnt System | | 268 | | +-+-+-+-+ +-+-+-+-+ | +-+-+-+-++-+-+-+-+ | 269 | +-+-+-+-+-+-^-+-+-+-+-+-+ | 270 +-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | NSF-Facing Interface 272 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |Security Network | | 275 | +------------------------------------------------+ | 276 | | | | | 277 | | +-+-+-v-+-+-+ +-+-+-+-+v+-+-+ | 278 | +-+-+-v-++-+ | +-+-+-+ | | +-+-+-+ | | 279 | | | | |SFF1 |<-|---------------->| SF1 | | | 280 | |Classifier|<------> | +-+-+-+< | | +-+-+-+ | | 281 | | | | \| | +-+-+-+ | | 282 | +-+-+-+-++-+ | +-+-+-+ \---------------->| SF2 | | | 283 | | |SFF2 |<-|---------------/ +-+-+-+ | | 284 | | +-+-+-+<-|-------------\ +-+-+-+ | | 285 | +-+-+-+-+-+-+ \->| SF3 | | | 286 | | +-+-+-+ | | 287 | +-+-+-+-+-+-+-+ | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 1: SFC-enabled I2NSF 292 4.1. SFC Policy Manager 294 SFC Policy Manager is a core component in our system. It is 295 responsible for the following two things: (1) Interpreting a high- 296 level SFC policy (or configuration) into a low-level SFC policy (or 297 configuration), which is given by I2NSF Client, and delivering the 298 interpreted policy to Classifiers for security function chaining. (2) 299 Generating an SF forwarding table and distributing the fowarding 300 information to SFF(s) by consulting with SFC Catalog Manager. As 301 Figure 1 describes, SFC Policy Manager performs these additional 302 functionalities through Consumer-Facing Interface and NSF-Facing 303 Interface. 305 Given a high-level SFC policy/configuration from I2NSF Client via 306 Consumer-Facing Interface, SFC Policy Manager interprets it into a 307 low-level policy/configuration comprehensible to Classifier(s), and 308 then delivers the resulting low-level policy to them. Moreover, SFC 309 Policy Manager possibly generates new policies for the flexible 310 change of traffic steering to rapidly react to the current status of 311 SFs. For instance, it could generate new rules to forward all 312 subsequent packets to "Firewall Instance 2" instead of "Firewall 313 Instance 1" in the case where "Firewall Instance 1" is under 314 congestion. 316 SFC Policy Manager gets information about SFs from SFC Catalog 317 Manager to generate SF forwarding table. In the table generation 318 process, SFC Policy Manager considers various criteria such as SFC 319 policies, SF load status, SF physical location, and supported 320 transport protocols. An entry of the SF forwarding table consists of 321 SFF Identifier, SFP, SI, and next hop information. The examples of 322 next hop information includes the IP address and supported transport 323 protocols (e.g., VxLAN and GRE). These forwarding table updates are 324 distributed to SFFs with either push or pull methods. 326 4.2. SFC Catalog Manager 328 In Figure 1, SFC Catalog Manager is a component integrated into 329 Security Controller. It is responsible for the following three 330 things: (1) Maintaining the information of every available SF 331 instance such as IP address, supported transport protocol, service 332 name, and load status. (2) Responding to the queries of available SF 333 instances from SFC Policy Manager so as to help to generate a 334 forwarding table entry relevant to a given SFP. (3) Requesting 335 Developer's Management System to dynamically instantiate 336 supplementary SF instances to avoid service congestion or the 337 elimination of an existing SF instance to avoid resource waste. 339 Whenever a new SF instance is registered, Developer's Management 340 System passes the information of the registered SF instance to SFC 341 Catalog Manager, so SFC Catalog Manager maintains a list of the 342 information of every available SF instance. Once receiving a query 343 of a certain SFP from SFC Policy Manager, SFC Catalog Manager 344 searches for all the available SF instances applicable for that SFP 345 and then returns the search result to SFC Policy Manager. 347 In our system, each SF instance periodically reports its load status 348 to SFC Catalog Manager. Based on such reports, SFC Catalog Manager 349 updates the information of the SF instances and manages the pool of 350 SF instances by requesting Developer's Management System for the 351 additional instantiation or elimination of the SF instances. 352 Consequently, SFC Catalog Manager enables efficient resource 353 utilization by avoiding congestion and resource waste. 355 4.3. Developer's Management System 357 We extend Developer's Management System for additional 358 functionalities as follows. As mentioned above, the SFC Catalog 359 Manager requests the Developer's Management System to create 360 additional SF instances when the existing instances of that service 361 function are congested. On the other hand, when there are an 362 excessive number of instances for a certain service function, the SFC 363 Policy Manager requests the Developer's Management System to 364 eliminate some of the SF instances. As a response to such requests, 365 the Developer's Management System creates and/or removes SF 366 instances. Once it creates a new SF instance or removes an existing 367 SF instance, the changes must be notified to the SFC Catalog Manager. 369 4.4. Classifier 371 Classifier is a logical component that may exist as a standalone 372 component or a submodule of another component. In our system, the 373 initial classifier is typically located at an entry point like a 374 border router of the network domain, and performs the initial 375 classification of all incoming packets according to the SFC policies, 376 which are given by SFC policy manager. The classification means 377 determining the SFP through which a given packet should pass. Once 378 the SFP is decided, the classifier constructs an NSH that specifies 379 the corresponding SPI and SI, and attaches it to the packet. The 380 packet will then be forwarded through the determined SFP on the basis 381 of the NSH information. 383 4.5. Service Function Forwarder (SFF) 385 It is responsible for the following two functionalities: (1) 386 Forwarding the packets to the next SFF/SF. (2) Handling re- 387 classification request from SF. 389 An SFF basically takes forwarding functionality, so it needs to find 390 the next SF/SFF for the incoming traffic. It will search its 391 forwarding table to find the next hop information that corresponds to 392 the given traffic. In the case where the SFF finds a target entry on 393 its forwarding table, it just forwards the traffic to the next SF/SFF 394 specified in the next hop information. If an SFF does not have an 395 entry for a given packet, it will request the next hop information to 396 SFC Policy Manager with SFF identifier, SPI, and SI information. The 397 SFC Policy Manager will respond to the SFF with next hop information, 398 and then the SFF updates its forwarding table with the response, 399 forwarding the traffic to the next hop. 401 Sometimes an SF may want to forward a packet, which is highly 402 suspicious, to another SF for futher security inspection. This is 403 referred to as advanced security action in I2NSF. In this situation, 404 if the next SF may not be the one on the current SFP of the packet, 405 re-classification is required to change the SFP of the packet. If 406 the current SF is capable of re-classifying the packet by itself, the 407 SF updates the SPI field in the NSH in the packet to serve the 408 advanced secuity action. Otherwise, if the classifier exists as a 409 standalone, the SF appends the inspection result of the packet to the 410 MetaData field of the NSH and delivers it to the source SFF. The 411 attached MetaData includes a re-classification request to change the 412 SFP of the packet to another SFP for stronger inspection. When the 413 SFF receives the traffic requiring re-classification, it forwards the 414 traffic to the Classifier where re-classification will be eventually 415 performed. 417 SFC defines Rendered Service Path (RSP), which represents the 418 sequence of actual visits by a packet to SFFs and SFs [RFC7665]. If 419 the RSP information of a packet is available, the SFF could check 420 this RSP information to detect whether undesired looping happened on 421 the packet. If the SFF detects looping, it could notify the Security 422 Controller of this looping, and the Security Controller could modify 423 relevant security policy rules to resolve this looping. 425 5. Use Cases 427 This section introduces three use cases for the SFC-enabled I2NSF 428 architecture : (1) Dynamic Path Alternation, (2) Enforcing Different 429 SFPs Depending on Trust Levels, and (3) Effective Load Balancing with 430 Dynamic SF Instantiation. 432 5.1. Dynamic Path Alternation 434 In SFC-enabled I2NSF architecture, a Classifier determines the 435 initial SFP of incoming traffic according to the SFC policies. The 436 classifier then attaches an NSH specifying the determined SFP of the 437 packets, and they are analyzed through the SFs of the initial SFP. 438 However, SFP is not a static property, so it could be changed 439 dynamically through re-classification. A typical example is for a 440 certain SF in the initial SFP to detect that the traffic is highly 441 suspicious (likely to be malicious). In this case, the traffic needs 442 to take stronger inspection through a different SFP which consists of 443 more sophisticated SFs. 445 Figure 2 illustrates an example of such dynamic SFP alternation in a 446 DDoS attack scenario. SFP-1 represents the default Service Function 447 Path that the traffic initially follows, and SFP-1 consists of AVC, 448 Firewall, and IDS/IPS. If the IDS/IPS suspects that the traffic is 449 attempting DDoS attacks, it will change the SFP of the traffic from 450 the default to SFP-2 so that the DDoS attack mitigator can execute a 451 proper countermeasure against the attack. 453 Such SFP alternation is possible in the proposed architecture with 454 re-classification. In Figure 1, to initiate re-classification, the 455 IDS/IPS appends its own inspection result to the MetaData field of 456 NSH and deliver it to the SFF from which it has originally received 457 the traffic. The SFF then forwards the received traffic including 458 the inspection result from the IDS/IPS to Classifier for re- 459 classification. Classifier checks the inspection result and 460 determines the new SFP (SFP-2) associated with the inspection result 461 in the SFC policy, and updates the NSH with the SPI of SFP-2. The 462 traffic is forwarded to the DDoS attack mitigator. 464 SFP-1. AVC:Firewall:IDS/IPS 465 ------------------------------------------------------------------> 466 +-+-+-+-+ +-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 467 | Source|---| AVC |---| Firewall|-----| IDS/IPS |---| Destination | 468 +-+-+-+-+ +-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 469 ----------------------------------------, ,------> 470 \ +-+-+-+-+ / 471 \ | DDoS | / 472 \ +-+-+-+-+ / 473 '----------' 474 SFP-2. AVC:Firewall:DDoS:IDS/IPS 476 Figure 2: Dynamic SFP Alternation Example 478 5.2. Enforcing Different SFPs Depending on Trust Levels 480 Because the traffic coming from a trusted source is highly likely to 481 be harmless, it does not need to be inspected excessively. On the 482 other hand, the traffic coming from an untrusted source requires an 483 in-depth inspection. By applying minimum required security functions 484 to the traffic from a trusted source, it is possible to prevent the 485 unnecessary waste of resources. In addition, we can concentrate more 486 resources on potential malicious traffic. In the SFC-enabled I2NSF 487 architecture, by configuring an SFC Policy to take into account the 488 levels of trust of traffic sources, we can apply different SFPs to 489 the traffic coming from different sources. 491 Figure 3(a) and Figure 3(b) represent SFPs applicable to traffic from 492 trusted and untrusted sources, respectively. In Figure 3(a), we 493 assume a lightweight IDS/IPS which is configured to perform packet 494 header inspection only. In this scenario, when receiving the traffic 495 from a trusted source, the classifier determines the SFP in 496 Figure 3(a) such that the traffic passes through just a simple 497 analysis by the lightweight IDS/IPS. On the other hand, traffic from 498 an untrusted source passes more thorough examination through the SFP 499 in Figure 3(b) which consists of three different types of SFs. 501 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 502 | Source |----------->| IDS/IPS |----------->| Destination | 503 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ 505 (a) Traffic flow of trusted source 507 +-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 508 | Source | | Anti-Spoofing | | Destination | 509 +-+-+-+-+-+ | function | +-+-+-+^+-+-+-+ 510 | +-+^+-+-+-+-+-+-+ | 511 | | | | 512 | +-+-+-+-+-+-+ | | +-+-+-+-+-+ | 513 ------->| Firewall |-- ---->| DPI |-- 514 +-+-+-+-+-+-+ +-+-+-+-+-+ 516 (b) Traffic flow of untrusted source 518 Figure 3: Different path allocation depending on source of traffic 520 5.3. Effective Load Balancing with Dynamic SF Instantiation 522 In a large-scale network domain, there typically exist a large number 523 of SF instances that provide various security services. It is 524 possible that a specific SF instance experiences an excessive amount 525 of traffic beyond its capacity. In this case, it is required to 526 allocate some of the traffic to another available instance of the 527 same security function. If there are no additional instances of the 528 same security function available, we need to create a new SF instance 529 and then direct the subsequent traffic to the new instance. In this 530 way, we can avoid service congestion and achieve more efficient 531 resource utilization. This process is commonly called load 532 balancing. 534 In the SFC-enabled I2NSF architecture, SFC Catalog Manager performs 535 periodic monitoring of the load status of available SF instances. In 536 addition, it is possible to dynamically generate a new SF instance 537 through Developer's Management System. With these functionalities 538 along with the flexible traffic steering mechanism, we can eventually 539 provide load balancing service. 541 The following describes the detailed process of load balancing when 542 congestion occurs at the firewall instance: 544 1. SFC Catalog Manager detects that the firewall instance is 545 receiving too much requests. Currently, there are no additional 546 firewall instances available. 548 2. SFC Catalog Manager requests Developer's Management System to 549 create a new firewall instance. 551 3. Developer's Management System creates a new firewall instance and 552 then registers the information of the new firewall instance to 553 SFC Catalog Manager. 555 4. SFC Catalog Manager updates the SFC Information Table to reflect 556 the new firewall instance, and notifies SFC Policy Manager of 557 this update. 559 5. Based on the received information, SFC Policy Manager updates the 560 forwarding information for traffic steering and sends the new 561 forwarding information to the SFF. 563 6. According to the new forwarding information, the SFF forwards the 564 subsequent traffic to the new firewall instance. As a result, we 565 can effecively alleviate the burden of the existing firewall 566 instance. 568 6. Discussion 570 The information model and data model of security policy rules in the 571 I2NSF framework defines an advanced security action as a type of 572 action to be taken on a packet 573 [nsf-capability-im][nsf-facing-inf-dm]. Through the advanced 574 security action, a basic NSF (e.g., firewall) can call a different 575 type of NSF for more in-depth security analysis of a packet. If an 576 NSF triggers an advanced security action on a given packet, the 577 packet should be forwarded to the NSF dedicated to the advanced 578 action. That is, the advanced action dynamically determines the next 579 NSF where the packet should go through. So if a forwarding component 580 is configured with the network access information (e.g., IP address, 581 port number) of the next required NSF, it can forward the packet to 582 the NSF. With this advanced security action, it is possible to avoid 583 the overhead for configuring and managing the information of security 584 function chains and paths. 586 In SFC, re-classification is required to support the situation where 587 the security function path of a packet changes dynamically, and the 588 classifier is responsible for re-classification tasks to change the 589 security function path of a packet. But if the classifier exists as 590 a separate component from an NSF, the packet should be first 591 delivered from the NSF to the classifier for re-classification, and 592 this introduces an additional delay. As already mentioned, the 593 advanced security action in the i2nsf framework can omit the 594 requirement of pre-defined security function chain configuration. If 595 there exists no security function chain/path configurations, there is 596 no need of re-classification as well. That is, the forwarder can 597 simply forward the packet to the next required NSF according to the 598 advanced action determiend by the predesessor NSF, without re- 599 classification through the classifier. 601 7. Implementation Considerations 603 7.1. SFC Policy Configuration and Management 605 In the SFC-enabled I2NSF architecture, SFC policy configuration and 606 management should be considered to realize NSF chaining for packets. 607 According to the given SFC policy, a classifier is configured with 608 the corresponding NSF chain/path information, and also an SFF is 609 configured with a forwarding information table. 611 The following three interfaces need to be considered for SFC policy 612 configuration and management. First of all, the network 613 administrator, typically an I2NSF user, needs to send SFC policy 614 configuration information that should be enforced in the system to 615 the security controller. Thus an interface between the network 616 administrator and the security controller should be set up for this 617 objective. By analyzing the given SFC policy configuration 618 information, the security controller generates NSF chain/path 619 information required for classifiers and forwarding information table 620 of NSFs that SFFs require for packet forwarding. An interface 621 between the security controller and classifier is required to deliver 622 NSF chain/path information to the classifier. In addition, an 623 interface between the security controller and SFF is also required to 624 deliver forwarding information table of NSFs to SFFs. 626 When there are multiple instances of classifiers and SFFs, 627 synchronizing the configuration information over them is important 628 for them to have a consistent view of the configuration information. 629 Therefore it should be considered how to synchronize the 630 configuration information over the classifiers and SFFs. 632 7.2. Placement of Classifiers 634 To implement the SFC-enabled I2NSF architecture, it needs to be 635 considered where to place the classifier. There are three possible 636 options: NSF, SFF, and a separate component. The first option is 637 integrating a classifier into every NSF. This approach is good for 638 re-classification, because each NSF itself can perform re- 639 classification without introducing any additional network overhead. 640 On the other hand, configuring every NSF with NSF chain/path 641 information and maintaining their consistency introduce an extra 642 overhead. The second option is integrating a classifier into a SFF. 643 In general, since the number of SFFs is much smaller than the number 644 of NSFs, the overhead for configuring and managing NSF chain/path 645 information would be smaller than the first option. In this case, 646 re-classification of a packet should be done at a SFF rather than an 647 NSF. The third option is that a classifier operates as a standalone 648 entity. In this case, whenever re-classification is required for a 649 packet, the packet should first stop by the classifier before going 650 through a SFF, and this is likely to increase packet delivery 651 latency. 653 7.3. Forwarding Method of SFC 655 Tunneling protocols can be utilized to support packet forwarding 656 between SFF and NSF or SFC proxy [RFC7665] . In this case, it needs 657 to be considered which tunneling protocol to use, and both SFF and 658 NSF/SFC proxy should support the same tunneling protocols. If an NSF 659 itself should handle the tunneling protocol, it is required to modify 660 the NSF implementation to make it understand the tunneling protocol. 661 When there are diverse NSFs developed by different vendors, how to 662 modify efficiently those NSFs to support the tunneling protocol is an 663 critical issue to reduce the maintenance cost of NSFs after 664 deployment. 666 Network Tunneling in SFC is achieved through protocols such as 667 [RFC8300], [RFC3032], [StEERING], and so on. To implement the SFC- 668 enabled I2NSF architecture, it needs to be considered what to use 669 something for the network tunneling. 671 [RFC8300] is a data plane protocol to deliver the information between 672 entity of sfc-enabled domain; it sends the service path 673 identification and metadata. Its protocol is an independent 674 transport protocol. Therefore, another tunneling protocol([RFC2890] 675 [RFC2003] [RFC3378] [vxlan-gpe]) should be inserted over the NSH 676 header and encapsulation for forwarding within the network. 677 [RFC3032] construct the routing mechanism based on the MPLS label 678 stack. When an MPLS-label packet enters the SFC-enabled domain, a 679 classifier encapsulates the mpls label stack into a packet based on 680 the SFC information. [StEERING] is a traffic triggered steering 681 framework based on software defined network. An SDN controller 682 defines policy control traffic using the subscriber information and 683 requirements, traffic type, and so on. And propagate that control 684 traffic between SFC-enabled domain entities. 686 7.4. Implementation of Network Tunneling 688 We implemented network tunnleing based on GRE (Generic Routing 689 Encapsulation) protocol to support packet forwarding between SFF and 690 SFC proxy. For the NSH encapsulation with GRE protocol in layer 3, 691 we referred to the header format defined in [RFC8300]. Figure 4 692 shows the format of an entire packet in our implementation, and 693 Figure 5 shows the mapping table of service path identifiers used in 694 our implementation. 696 +----------+----------------------+-------------+ 697 |L2 header | L3 header(Outer IP), | GRE header, | 698 | | protocol=47 | PT=0x894F | 699 | | | | 700 +----------+----------------------+-------------+ 701 -----------+----------------+ 702 NSH, NP=0x1| | 703 SPI=1 |original packet | 704 SI=1 | | 705 -----------+----------------+ 707 Figure 4: Entire packet format for network tunneling based on GRE 708 protocol 710 +------+-------------------------------+ 711 | SPI | Network security function | 712 +------+-------------------------------+ 713 | 1 | Firewall | 714 +------+-------------------------------+ 715 | 2 | Firewall->DPI | 716 +------+-------------------------------+ 717 | 3 | Firewall->DPI->DDoS metigation| 718 +------+-------------------------------+ 720 Figure 5: Mapping table of service path identifiers 722 7.5. Implementation of SFC using Opendaylight Controller 724 Traffic steering in I2NSF framework can be implemented by using 725 Opendaylight that supports service function chaining. In such a 726 system where Opendaylight is integrated into I2NSF framework, traffic 727 steering can be performed with three functions as follows. 1) I2NSF 728 Security Controller Function 2) SDN Switch Controller Function 3) SDN 729 Switch Traffic Steering Function. The following describes each of 730 these functions. 732 What service function chains (SFC) are needed can be determined 733 according to security policy rules of NSFs in I2NSF framework. I2NSF 734 Security Controller Function identifies NSF chains that are required 735 in the system by comprehensively analyzing security policy rules of 736 NSFs. I2NSF Security Controller Function then generates the policies 737 of the identified NSF chains, and requests SDN Switch Controller to 738 enforce the policies of NSF chains. 740 SDN Switch Controller Function is responsible for creating, updating, 741 and deleting SFCs, while Switch Controller operates to support 742 service function chaining. Opendaylight Switch Controller is able to 743 create key elements for SFC such as SF, SFF, SFC, SFP, and RSP. Once 744 receiving the SFC policies from I2NSF Security Controller Function, 745 SDN Switch Controller Function generates traffic forwarding rules 746 that need to be configured on SFFs and switches, in order for the 747 requested SFC policies to be enforced to relevant traffic. The 748 generated traffic forwarding rules are delivered to relevant SFFs and 749 switches using a data plane protocol ([OpenFlow], 750 [RFC7047],[RFC6241]). 752 SFFs and switches perform forwarding traffic based on the traffic 753 forwarding rules received from SDN Switch Controller. SDN Switch 754 Traffic Steering Function refers to the Data Plane Elements processes 755 running on SFFs and switches for steering traffic to the destination 756 according to the traffic forwarding rules. To steer packets over 757 NSFs, the packets are encapsulated with Network Service Header (NSH) 758 [RFC8300]. 760 8. Security Considerations 762 To enable security function chaining in the I2NSF framework, we adopt 763 the additional components in the SFC architecture. Thus, this 764 document shares the security considerations of the SFC architecture 765 that are specified in [RFC7665] for the purpose of achieving secure 766 communication among components in the proposed architecture. 768 9. Acknowledgments 770 This work was supported by Institute for Information and 771 communications Technology Promotion(IITP) grant funded by the Korea 772 government(MSIP) (No.R-20160222-002755, Cloud based Security 773 Intelligence Technology Development for the Customized Security 774 Service Provisioning). This document has greatly benefited from 775 inputs by Sanguk Woo, Yunsuk Yeo, Taekyun Roh, and Sarang Wi. 777 10. References 779 10.1. Normative References 781 [OpenFlow] 782 Open Networking Foundation, "The OpenFlow Switch 783 Specification, Version 1.4.0", 784 OpenFlow https://www.opennetworking.org/images/stories/ 785 downloads/sdn-resources/onf-specifications/openflow/ 786 openflow-spec-v1.4.0.pdf, October 2013. 788 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 789 October 1996. 791 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 792 RFC 2890, September 2000. 794 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 795 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 796 Encoding", RFC 3032, January 2001. 798 [RFC3378] Housley, R. and S. Hollenbeck, "EtherIP: Tunneling 799 Ethernet Frames in IP Datagrams", RFC 3378, September 800 2002. 802 [RFC6241] Enns, R. and M. Bjorklund, "Network Configuration Protocol 803 (NETCONF)", RFC 6241, June 2011. 805 [RFC7047] Pfaff, B. and B. Davie, "The Open vSwitch Database 806 Management Protocol", RFC 7047, December 2013. 808 [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining 809 (SFC) Architecture", RFC 7665, October 2015. 811 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 812 Header (NSH)", RFC 8300, January 2018. 814 [StEERING] 815 Zhang, Y., Beheshti, N., Beliveau, L., Lefebvret, G., 816 Manghirmalani, R., Mishra, R., Patney, R., Shirazipour, 817 M., Subrahmaniam, R., Truchan, C., and M. Tatipamula, 818 "StEERING: A Software-Defined Networking for Inline 819 Service Chaining", October 2013. 821 [vxlan-gpe] 822 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 823 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 824 in progress), April 2018. 826 10.2. Informative References 828 [i2nsf-framework] 829 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 830 Kumar, "Framework for Interface to Network Security 831 Functions", RFC 8329, February 2018. 833 [i2nsf-problem] 834 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 835 and J. Jeong, "I2NSF Problem Statement and Use cases", 836 RFC 8192, July 2017. 838 [i2nsf-terminology] 839 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 840 Birkholz, "Interface to Network Security Functions (I2NSF) 841 Terminology", draft-ietf-i2nsf-terminology-05 (work in 842 progress), January 2018. 844 [nsf-capability-im] 845 Xia, L., Strassner, J., Basile, C., and D. Lopez, 846 "Information Model of NSFs Capabilities", draft-ietf- 847 i2nsf-capability-01 (work in progress), April 2018. 849 [nsf-facing-inf-dm] 850 Kim, J., Jeong, J., Park, J., Hares, S., and L. Xia, 851 "I2NSF Network Security Functions-Facing Interface YANG 852 Data Model", draft-kim-i2nsf-nsf-facing-interface-data- 853 model-04 (work in progress), October 2017. 855 [ONF-SFC-Architecture] 856 ONF, "L4-L7 Service Function Chaining Solution 857 Architecture", June 2015. 859 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 860 Function Chaining", RFC 7498, April 2015. 862 Appendix A. Changes from draft-hyun-i2nsf-nsf-triggered-steering-05 864 The following changes have been made from draft-hyun-i2nsf-nsf- 865 triggered-steering-05: 867 o Section 7.3 has been added to discuss an forwarding method that 868 supports SFC. 870 o The references have been updated to reflect the latest documents. 872 Authors' Addresses 874 Sangwon Hyun 875 Department of Computer Engineering 876 Chosun University 877 309, Pilmun-daero, Dong-gu 878 Gwangju, Jeollanam-do 61452 879 Republic of Korea 881 EMail: shyun@chosun.ac.kr 883 Jaehoon Paul Jeong 884 Department of Software 885 Sungkyunkwan University 886 2066 Seobu-Ro, Jangan-Gu 887 Suwon, Gyeonggi-Do 16419 888 Republic of Korea 890 Phone: +82 31 299 4957 891 Fax: +82 31 290 7996 892 EMail: pauljeong@skku.edu 893 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 895 Jung-Soo Park 896 Electronics and Telecommunications Research Institute 897 218 Gajeong-Ro, Yuseong-Gu 898 Daejeon 305-700 899 Republic of Korea 901 Phone: +82 42 860 6514 902 EMail: pjs@etri.re.kr 903 Susan Hares 904 Huawei 905 7453 Hickory Hill 906 Saline, MI 48176 907 USA 909 Phone: +1 734 604 0332 910 EMail: shares@ndzh.com