idnits 2.17.1 draft-wang-sfc-ns-use-cases-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2016) is 2740 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IDS' is mentioned on line 537, but not defined == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining E. Wang 3 Internet-Draft K. Leung 4 Intended status: Informational J. Felix 5 Expires: April 28, 2017 J. Iyer 6 Cisco Systems Inc. 7 October 25, 2016 9 Service Function Chaining Use Cases for Network Security 10 draft-wang-sfc-ns-use-cases-02 12 Abstract 14 Enterprise networks deploy a variety of security devices to protect 15 the network, hosts and endpoints. Network security devices, both 16 hardware and virtual, operate at all OSI layers with scanning and 17 analysis capabilities for application content. Multiple specific 18 devices are often deployed together for breadth and depth of defense. 19 This document describes use cases of Service Function Chaining (SFC) 20 when deploying network security devices in the manner described above 21 and also puts forth requirements for their effective operation. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 23, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3 60 3. Characteristics of Security Service Functions . . . . . . . . 4 61 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Service Classification Use Cases . . . . . . . . . . . . 5 63 4.1.1. Service classification for bi-directional traffic . . 5 64 4.1.2. Service Classifier to distinguish initiator and 65 responder . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.3. Service Classification based on network and 67 application criteria . . . . . . . . . . . . . . . . 7 68 4.1.4. Switching Service Function Paths based on inspection 69 and scanning results . . . . . . . . . . . . . . . . 8 70 4.2. Service Function Use Cases . . . . . . . . . . . . . . . 10 71 4.2.1. Service Classifier-capable Service Function . . . . . 10 72 4.2.2. Service Functions operating on L5 or L7 data . . . . 10 73 4.2.3. Service Function mid-stream pick-up . . . . . . . . . 10 74 4.2.4. Bypassing a particular Service Function . . . . . . . 11 75 4.2.5. Receive-only Service Functions . . . . . . . . . . . 13 76 4.3. Service Data Handling Use Cases . . . . . . . . . . . . . 13 77 4.3.1. Service Function injected new packet . . . . . . . . 13 78 4.3.2. Service Function initiated connections . . . . . . . 14 79 4.3.3. Security classification results . . . . . . . . . . . 15 80 5. General Requirements . . . . . . . . . . . . . . . . . . . . 17 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 9.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Network security service nodes participate in Service Function 92 Chaining (SFC) to provide comprehensive solutions for securing campus 93 and data center enterprise networks. Often, network operators deploy 94 various types and instances of security service nodes. These nodes 95 are complementary to one another for the purpose of coverage, depth 96 of defense, scalability and availability. 98 In addition to packet forwarding, network security devices can 99 buffer, inject or block certain packets, as well as proxy entire 100 connections. Most of the network security devices maintain state at 101 the connection, session or transaction levels. When used in a SFC 102 environment these security Service Function actions and properties 103 require careful design and extension including the Service Classifier 104 and Service Function itself. This document attempts to describe the 105 detailed use cases that lead to the requirements to support network 106 security functions in SFC. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Definition Of Terms 116 This document uses the terms as defined in RFC 7498 [RFC7498], RFC 117 665 [RFC7665] and [I-D.ietf-sfc-nsh]. 119 In addition the following terms are defined. 121 Security Service Function (Security SF): A Security Service Function 122 is a Service Function that carries out specific security tasks. 123 We limit the scope of security functions to network security in 124 this document (as opposed to functions such as endpoint 125 security). In addition to the general forwarding action, a 126 Security Service Function can buffer, proxy, inject or block 127 certain packets based on its policy. A Security Service Function 128 can maintain state at the connection, session or transaction 129 levels. Sample Security Service Functions are: Firewall, 130 Intrusion Prevention/Detection System (IPS/IDS), Deep Packet 131 Inspection (DPI), Application Visibility and Control (AVC), 132 network virus and malware scanning, sandbox, Data Loss Prevention 133 (DLP), Distributed Denial of Service (DDoS) mitigation and TLS 134 proxy. 136 Flow: A flow is a uni-directional traffic stream identified by 137 network layer attributes, specifically IP addresses and TCP/UDP 138 ports for TCP/UDP traffic. 140 Connection: A connection is a bi-directional traffic stream composed 141 of two flows sharing the same network layer attributes. 143 3. Characteristics of Security Service Functions 145 Most Security Service Functions are stateful. They maintain state at 146 the connection, session or transaction levels, depending on the OSI 147 layers that they act on. Many Security Functions require receiving 148 both directions of the client-server traffic in order to maintain 149 state properly. Asymmetric traffic must be normalized before packets 150 reach the Security Functions. 152 Security Service Functions operate on network layer data with 153 specific behaviors. For example: 155 1. A Firewall tracks TCP state between the TCP client and server. 156 TCP packets that do not correspond to the Firewall's maintained 157 state are likely to be dropped. 159 2. A Firewall can modify the L3/L4 headers for NAT [RFC3022]. The 160 flow attributes in the packet header may be changed after the 161 packet egresses the Firewall. 163 3. A Firewall can proxy a TCP connection by sending a TCP ACK on 164 behalf of the endpoint. From the SFC perspective, this results 165 in Service Function generated packets being injected into the 166 service path in the reverse direction. 168 4. A Firewall or DDoS mitigator can inject TCP layer challenges to 169 the originating client before the intended server receives a 170 packet from the client. 172 Security Functions also handle packets and examine data at higher OSI 173 layers. For example: 175 1. A Firewall can inspect the HTTP header and body data. Based on 176 the inspection results, the firewall can decide to drop the 177 packet and/or block the connection completely. 179 2. A Web proxy can inject an HTTP challenge page into an HTTP 180 transaction for the purposes of authentication and identity 181 collection. 183 3. At the enterprise edge, a TLS proxy, when authorized, operates as 184 a trusted Man-in-the-Middle to proxy the TLS handshake and 185 decrypt the packet data. The TCP payload may be completely 186 different between ingress and egress of TLS Proxy. 188 4. A stream scanning service examines a certain set of application 189 data. File scanning engines examine file streams of specific 190 types. 192 4. Use Cases 194 4.1. Service Classification Use Cases 196 4.1.1. Service classification for bi-directional traffic 198 Many Security Service Functions require receiving bi-directional 199 traffic of a connection. For example, a DDoS mitigator may require 200 to see the return traffic to maintain proper state. 202 Return traffic (i.e. server to client response) should be classified 203 based on the forward traffic (i.e. the client to server request). 204 This allows server's return traffic to be associated with the clients 205 forward traffic. The forward and return traffic forms a single bi- 206 directional connection and shares Service Function Paths with similar 207 set of Service Functions. 209 In the figure below, the Service Classifier handling traffic from 210 Host B must be able to identify return traffic (flow 2) and select 211 the Service Function Path with "DDoS". Flow 1 and 2 form a 212 connection and traverse DDoS in both directions. 214 ,--------------. 215 / \ 216 / .--. \ 217 / / \ \ 218 / ( DDoS ) \ 219 ------------' / \ / \ `--(1) Forward Flow (A=>B)--> 220 / `--' \ 221 / \ 222 +---+ .--./ `-------. +---+ 223 | | / \ / \ | | 224 | A +------( SC )-----------( Firewall )--------------------+ B | 225 | | \ / \ / | | 226 +---+ `--' `-------' +---+ 228 (a) Flows from Host A 230 ,------------. 231 / \ 232 / .--. \ 233 / / \ \ 234 / ( DDoS ) \ 235 <------------' / \ / \ `---(2) Return Flow (A<=B)---- 236 / `--' \ 237 / \ 238 +---+ / `-------. .--. +---+ 239 | | / / \ / \ | | 240 | A +----------+--------------( Firewall )------( SC )------+ B | 241 | | \ / \ / | | 242 +---+ `-------' `--' +---+ 244 <-------------(3) Forward Flow (A<=B)---------------------------- 246 (b) Flows from Host B 248 Figure 1: Forward and return flows between two hosts 250 4.1.2. Service Classifier to distinguish initiator and responder 252 Even if a Security Service Function requires receiving bi-directional 253 traffic of a connection, it should not necessarily receive traffic 254 initiated from all network segments for performance, availability, 255 and scalability reasons. For example, a DDoS mitigator is configured 256 to receive bi-directional traffic initiated from the Internet, but 257 not for traffic initiated from the internal network. 259 Traffic initiated from a network segment should be classified 260 independently. In Figure 1(b), the Service Classifier for Host B 261 must identify traffic initiated by Host B (flow 3) and classify it 262 independently. Such traffic bypasses the DDoS Service Function in 263 this example. 265 The Service Classifier must distinguish between flow 2 and flow 3, 266 both of which are from Host B to Host A. In other words, it must be 267 able to identify the initiator and responder of a connection. 269 A Service Classifier that keeps certain state would be able to handle 270 the above requirements. The state should be accessible by each 271 Service Classifier if there are multiple instances handling traffic 272 sources from various network segments. 274 4.1.3. Service Classification based on network and application criteria 276 The Service Classifier evaluates SFC Policies (i.e. Service 277 Policies) in order to determine the traffic and associated Service 278 Function Paths. In the case of Security Service Functions, the 279 Service Policies can contain match criteria derived from all OSI 280 layers of the packet. 282 SFC classification is often based on network data, including but not 283 limited to: Network interface port, VLAN, source and destination IP 284 addresses, source and destination TCP and UDP ports, IP protocol, 285 etc. These properties can be derived from the packet headers and are 286 consistent across every packet of a flow. 288 There are match criteria that are desired by Security Service 289 Functions that are either not present in the first packet, or are not 290 present in every packet. 292 Those criteria may comprise "application data" from above the network 293 layer, referred to as "application criteria". For example, a policy 294 rule may state: 296 for all TLS traffic, run the traffic through Service Function "TLS 297 Proxy" 299 Another example of an application layer policy rule is: 301 for all HTTP traffic with content containing file types of 302 interest, run the traffic through Service Function "File Stream 303 Scanner" 305 The Service Classifier for Security Service Functions needs to handle 306 complex Service Policy. In some cases, this can be achieved by 307 embedding the Service Classifier function into a Security Service 308 Function, such that it can evaluate the application data as it 309 becomes available. 311 4.1.4. Switching Service Function Paths based on inspection and 312 scanning results 314 Network data is likely to be available on the first packet of the 315 flow. When only network data is used as Service Policy match 316 criteria, a stateful Service Classifier will be able to determine the 317 forward and reverse Service Function Paths from the first packet 318 (initial classification). The forward and reverse Service Function 319 Paths remain unchanged for the entire life of the flow for these 320 types of policies. 322 When the Service Policy contains application criteria, the policy 323 rule may not be fully evaluated until several packets have passed 324 through the chain. For example, TLS traffic can be identified only 325 after the TLS Client Hello handshake message is observed. 327 Multiple classifiers may be required to provide sufficient 328 classification granularity and complete a full evaluation of the 329 Service Policy. In many cases, classification will be co-located 330 with a Security Service Function that has the ability to inspect and 331 scan the application data. 333 A new Service Function Path may be selected by a non-initial 334 classification, different from the one determined by the initial 335 classification. 337 The selection of a new Service Function Path can be reflected in the 338 NSH Service Path Header as a new Service Path ID for the Service 339 Function Forwarder to direct the packet accordingly. 341 The decision of a new Service Function Path often needs to be stored 342 in the Service Classifier to ensure that subsequent packets of the 343 flow follow the new path. This is because the data that triggers a 344 new Service Function Path may be available from one particular packet 345 only. For example, the packet with the TLS Client Hello message is 346 used to identify a TLS session. Subsequent packets may not contain 347 information for identifying the TLS sessions. All subsequent 348 packets, without being classified again, must travel through the path 349 with the "TLS Proxy" Service Function. 351 The Service Function that is new in the packet path (as part of the 352 new Service Function Path) has to be able to handle not seeing 353 earlier packets in the flow. Refer to Section 4.2 for more 354 discussions on Service Functions. 356 ,-----. 357 / \ 358 / .---. \ 359 / / \ \ 360 / ( TLS ) \ 361 -----------' ( Proxy ) `-SFP-2. AVC:TLS Proxy:Firewall-> 362 /\ / \ 363 / `---' \ .--. 364 +---+ .-./ .`------. ( )-. +---+ 365 | | / \ / \ .' ) | | 366 | A +----( AVC )--------( Firewall )---( Internet )----+ B | 367 | | \ / \ / ( -' | | 368 +---+ `-' `-------' '-( ) +---+ 369 '---' 370 --------------SFP-1. AVC:Firewall -------------------------> 372 Figure 2: Mid-stream service function path update 374 Figure 2 illustrates a simple set of Security Functions deployed at 375 the Internet edge. The default Service Function Path is SFP-1, with 376 Service Functions "AVC" and "Firewall". When a TLS session is 377 detected (e.g. by detecting the TLS Client Hello in the AVC Service 378 Function), packets of the flow from that point on are switched to 379 SFP-2, which contains "TLS Proxy" between "AVC" and "Firewall" to 380 decrypt the TLS traffic for inspection. 382 +--------------------+-------------------------------------+ 383 | Packets | Service Function Path | 384 +--------------------+-------------------------------------+ 385 | TCP Handshake | SFP-1. AVC:Firewall | 386 +--------------------+-------------------------------------+ 387 | TLS Client Hello | SFP-1; Switched to SFP-2 after AVC | 388 +--------------------+-------------------------------------+ 389 | Rest of TLS HS | SFP-2. AVC:TLS Proxy:Firewall | 390 +--------------------+-------------------------------------+ 391 | HTTPS Data | SFP-2. AVC:TLS Proxy:Firewall | 392 +--------------------+-------------------------------------+ 394 Table 1: SFP taken by each packet in an HTTPS connection 396 Table 1 lists the Service Function Path for each packet in an HTTPS 397 connection, from the TCP 3-way handshake to the HTTPS data packets. 398 A new Service Function Path is selected in the middle of the 399 connection after the TLS Client Hello is observed. 401 4.2. Service Function Use Cases 403 4.2.1. Service Classifier-capable Service Function 405 Service Functions that are capable of selecting a new Service 406 Function Path must have the Service Classifier function integrated. 407 Such Service Functions are often responsible for classification using 408 their inspection and scanning results and updating Service Function 409 Paths based on the Service Policy. 411 4.2.2. Service Functions operating on L5 or L7 data 413 Certain Security Service Functions operate on L5 to L7 data. For 414 example, a "TLS Proxy" consumes a TCP stream without retransmitted or 415 overlapping TCP segments. A "Web Proxy" operates on TCP stream of 416 HTTP traffic. The data consumed by such Service Functions may not be 417 in the original packet frame format, and the data may not contain the 418 original L2-L4 header information. Such Service Functions can obtain 419 the session or flow information from the SFC metadata carried in NSH. 421 4.2.3. Service Function mid-stream pick-up 423 When a new Service Function Path is selected as a result of Service 424 Policy re-evaluation with application layer policy metadata, a new 425 Service Function may need to start handling packet frames in the 426 middle of a flow. This is referred to as "mid-stream pick-up". 427 Although this is mid-stream from a flow perspective, it is still a 428 complete data stream from the Service Function perspective (e.g., 429 although "TLS Proxy" Service Function may not see the prior TCP 430 handshake packets, it still sees the entire TLS stream). Similarly, 431 transaction based Service Functions only handle packets belonging to 432 a particular transaction. Such Service Function may use the flow ID 433 metadata carried in NSH to link the session back to the flow. 435 +--------------------+-----+-----------+----------+ 436 | Packet | AVC | TLS Proxy | Firewall | 437 +--------------------+-----+-----------+----------+ 438 | TCP SYN | X | | X | 439 +--------------------+-----+-----------+----------+ 440 | TCP SYN/ACK | X | | X | 441 +--------------------+-----+-----------+----------+ 442 | TCP ACK | X | | X | 443 +--------------------+-----+-----------+----------+ 444 | TLS Client Hello | X | X | X | 445 +--------------------+-----+-----------+----------+ 446 | Rest of TLS HS | X | X | X | 447 +--------------------+-----+-----------+----------+ 448 | HTTPS Data | X | X | X | 449 +--------------------+-----+-----------+----------+ 451 Table 2: Service Functions visited by each packet in an HTTPS 452 connection 454 Table 2 lists the Service Functions visited by each packet from an 455 HTTPS connection. The first packet that the Service Function "TLS 456 Proxy" receives is the TLS Client Hello, as opposed to the TCP 457 handshake packets prior to it. 459 4.2.4. Bypassing a particular Service Function 461 Certain Security Service Functions can be compute-intensive while 462 only serving a particular task. It may be required to bypass such a 463 Service Function in the middle of a flow. For example: 465 o "Firewall" may request offloading of certain flows to fast 466 forwarding engine with minimal inspection 468 o "HTTP Inspector" may decide to not inspect video streams from a 469 site with a high reputation 471 o "TLS Proxy" may have to avoid decryption of banking traffic for 472 compliance reasons 474 The decision to bypass a Service Function is made by the Service 475 Function with its static policy, the inspection results and/or mid- 476 stream evaluation of Service Policy. 478 Even if a flow is offloaded or bypassed, the Security Service 479 Function may want to continue receiving critical packets for state 480 tracking purposes. For example, "Firewall" may want to receive TCP 481 control packets, and "HTTP Inspector" may want to track each 482 transaction in the same flow. 484 .-------. 485 / \ 486 ( HTTP ) 487 ( Inspector ) 488 ,---------------------------. 489 / `---+---' \ 490 / | \ 491 | | | 492 | .---+---. | 493 | / \ | 494 | ( Firewall ) | 495 | ,---------------. | 496 | / `---+---' \ | 497 | / | \ | 498 | | | | | 499 | | .---+---. |TCP |HTTP 500 | | / \ |control |Headers 501 | | ( SFF ) |packets | 502 | | ,-------------. | | 503 | | / `-------' \ | | 504 | | | | | | 505 | | |Offloaded | | | 506 | | |packets | | | 507 | | | | | | 508 v v v v v v 510 Figure 3: Service function bypass examples 512 A new Service Function Path may be selected to steer traffic to the 513 path with the bypassed Service Function removed. The Service 514 Function may update the NSH Service Path ID in the packet (in-band 515 signaling) if the Service Function has knowledge of the relevant 516 Service Function Paths. Alternatively, the Service Function may 517 signal the Service Classifier (out-of-band) to update the Service 518 Function Path for excluding the Service Function. 520 Service Function bypass may also follow the procedure described in 521 "Service Function Simple Offloads" [I-D.kumar-sfc-offloads], where 522 the Service Function signals the Service Function Forwarder to 523 offload a flow, without selecting a new Service Function Path. The 524 Service Function Forwarder caches the offload request and bypasses 525 the Service Function in the service path for the remainder of the 526 flow. 528 4.2.5. Receive-only Service Functions 530 Certain Service Functions such as an IDS may operate in "receive- 531 only" mode, i.e. they consume a packet instead of passing the packet 532 through. The Service Function Forwarder should send copies of 533 packets to receive-only Service Functions. 535 .---. 536 / \ 537 ( [IDS] ) 538 \ / 539 `-+-' 540 .---. /|\ .-------. 541 / \ | / \ 542 ( DDoS ) | ( Firewall ) 543 \ / | \ / 544 `-+-' |copy `---+---' 545 /|\ | /|\ 546 | | | 547 +---+ \|/ | \|/ +---+ 548 | | ,--+-----+-----------+----. | | 549 | C +----( SFF )----+ S | 550 | | `-------------------------' | | 551 +---+ +---+ 553 [ ] denotes receive-only 555 Figure 4: Receive-only service functions in SFC 557 Figure 4 illustrates an example of receive-only Service Function and 558 its insertion into a Service Function Chain. The IDS Service 559 Function receives copies of packets from the Service Function 560 Forwarder. 562 4.3. Service Data Handling Use Cases 564 4.3.1. Service Function injected new packet 566 Security Service Functions may inject new packets into an existing 567 flow in either direction. For example, 569 o "Web Proxy" inserts an HTTP page challenging the client to login, 570 in order to obtain the client's identity. This is in response to 571 a packet (likely HTTP Request) but in the opposite direction of 572 the flow. 574 o "Firewall" checks an idle TCP connection by sending TCP keepalives 575 to the client and/or server (known as "TCP dead connection 576 detection"). This is on existing flows but not responding to a 577 prior packet. 579 o "Firewall" sends ICMP error message after dropping a packet. This 580 is in response to the prior packet but on a new flow. 582 The Service Function or Service Classifier needs to conduct a lookup 583 of the reverse Service Function Path and populate the NSH Service 584 Path Header. The approaches described in [I-D.penno-sfc-packet] may 585 be adopted to support this use case. 587 4.3.2. Service Function initiated connections 589 A Service Function may need to create its own connections that are 590 not associated with any client connection. Use cases include probing 591 of servers behind a web proxy. In such cases, there will be no 592 existing metadata for the Service Function to use to establish this 593 connection. Such connections should be classified just like any 594 other connections traversing the Service Function Path, as there may 595 be Service Functions that are required to perform operations such an 596 NAT on such connections in order for it to reach its destination. 598 <------ SFC-1. Firewall:LB:IPS ------> 600 +---+ .-------. .--. .-. +---+ 601 | | / \ / \ / \ | | 602 | C +---( Firewall )---( LB )---( IPS )---+ S | 603 | | \ / \ / \ / | | 604 +---+ `-------' `--' `-' +---+ 606 <-- SFC-2. LB:IPS --> 608 Figure 5: SFC for service function initiated connection 610 Option 1: Service Classifier in Service Function. A Service 611 Classifier-capable Service Function may conduct service 612 classification to determine the Service Function Path for the Service 613 Function initiated connection. It can add an NSH with the proper 614 Service Path Headers to the packets, and the Service Function would 615 be the first SF on the chain. Response traffic follows a reverse 616 Service Function Path and terminates at the Service Function. The 617 number of Service Path Identifiers increases with more Service 618 Functions bearing such capability. 620 Option 2: Service Classifier external to Service Function. A Service 621 Function may send native packets without NSH when it is not capable 622 of service classification. Such traffic is handled by the Service 623 Classifier, which will populate the traffic with the appropriate NSH. 625 4.3.3. Security classification results 627 Security Service Functions may generate security classification 628 results (e.g. policy actions and inspection results) while processing 629 the packet data. Certain actions such as packet drop and flow 630 closure can be taken immediately. 632 However, Service Functions can choose not to take any action 633 immediately. Instead, it may pass the classification results to the 634 subsequent Service Functions or to a control point. 636 Security classification results may be carried in NSH metadata as a 637 score value. The score can be relayed and refined by other Security 638 Service Functions along the path. Figure 6 below depicts an example 639 of accumulating the client's score based on the Service Function's 640 classification result. The client's reputation score is 6 as 641 reported by the Service Function "Reputation", and the score is then 642 passed to the next Service Function "Web Proxy" as the initial score 643 for the connection. "Web Proxy" reduces the score to 3 after 644 detecting access to a low reputation website. The Service Function 645 "File Scanner" is involved due to the low score so far. After the 646 "File Scanner" conducts scanning on the downloaded file and 647 identifies it to be a malware, it updates the score to be -5 which is 648 below the threshold for the connection to be blocked. 650 .------. 651 +---+ .--------. .--------. / \ +---+ 652 | | / \ / \ ( File ) | | 653 | C +---( Reputation )--( Web Proxy )--( Scanner )---+ S | 654 | | \ / \ / \ / | | 655 +---+ `--------' `--------' `------' +---+ 656 | | | 657 V V V 658 +----------------------+--------------+-------------+ 659 | | Client | Accessing | Malware | 660 | Reason | Reputation | website rep | found in | 661 | | score 6 | score 2 | download | 662 +--------+------+------+-------+------+-------+-----+ 663 | | | 664 +---+---+ | | 665 | 6 | V | 666 +---+---+ | | 667 `------>-------+ V 668 | | 669 +---+---+ | 670 | 3 | | 671 +---+---+ | 672 `------>-------+ 673 | 674 +---+---+ 675 | -5 | 676 +---+---+ 677 | /-------\ 678 | | | 679 `------>| Block | 680 | | 681 \-------/ 683 Figure 6: Security classification result with accumulated client 684 score 686 Alternatively, each participating Service Function may send its own 687 classification result to a central Service Function or control point 688 for aggregation. Actions are then taken by a specific Service 689 Function or control point based on the accumulated results. Figure 7 690 illustrates this option. 692 .------. 693 +---+ .--------. .--------. / \ +---+ 694 | | / \ / \ ( File ) | | 695 | C +---( Reputation )--( Web Proxy )--( Scanner )---+ S | 696 | | \ / \ / \ / | | 697 +---+ `--------' `--------' `------' +---+ 698 | | | 699 V V V 700 +--------+-------------+--------------+------------+ 701 | SF | Client | Accessing | Malware | 702 |Classify| reputation | website rep | found in | 703 | Results| score 6 | score 2 | download | 704 +--------+------+------+-------+------+-----+------+ 705 | | | 706 | | | 707 | | | 708 | | | +------+ /-------\ 709 | | `->| | | | 710 | `-------------->| Eval +->+ Block | 711 `----------------------------->| | | | 712 +------+ \-------/ 714 Figure 7: Aggregation of security classification results 716 5. General Requirements 718 The above use cases lead to the following requirements for applying 719 SFC to security services on the data traffic. 721 Requirements that may need working group drafts: 723 1. SFC SHOULD allow packet frames carrying only L5 and upper layer 724 traffic data without L2-L4 headers. 726 2. SFC SHOULD support bypass of a Service Function in the middle of 727 a connection while allowing necessary control packets to reach 728 the Service Function. Possible extension to 729 [I-D.kumar-sfc-offloads] 731 3. SFC control plane and packet plane MUST support receive-only 732 Service Functions. 734 4. SFC MUST support packet injection to the opposite direction of a 735 Service Function Path. Possible extension to 736 [I-D.penno-sfc-packet] 738 5. SFC SHOULD allow metadata passing classification results. 740 Requirements for implementation driven by respective use cases: 742 1. SFC MUST support the use of stateful Service Classifiers and 743 Service Functions if present. 745 2. Service Classifiers MUST have the ability to classify forward and 746 the corresponding reverse Service Function Paths. 748 3. Service Classifiers MUST be able to distinguish between traffic 749 initiator and responder. 751 4. SFC MUST support the use of Service Policies with network and 752 application layer match criteria if supported by Service 753 Classifier. 755 5. SFC MUST support Service Function Path update or selection of a 756 new path by a Service Classifier in the middle of a flow. 758 6. Security Considerations 760 This document describes use cases for Security Service Functions to 761 participate in SFC. There are cases such as picking up traffic from 762 the middle of a packet stream or handling packets without L2-L4 763 headers. Security Service Functions must process those types of 764 traffic properly and associate them with the appropriate internal 765 state. 767 While each Security Service Function applies its own implementation 768 to secure the internal data, communications between Service Functions 769 need to be secured as well. Measures must be taken to ensure 770 metadata such as security classifications carried in NSH is not 771 tampered. 773 7. Acknowledgments 775 The authors would like to thank Paul Quinn, Reinaldo Penno and Jim 776 Guichard for their detailed review, comments and contributions. 778 8. IANA Considerations 780 This document includes no request to IANA. 782 9. References 783 9.1. Normative References 785 [I-D.ietf-sfc-nsh] 786 Quinn, P. and U. Elzur, "Network Service Header", draft- 787 ietf-sfc-nsh-10 (work in progress), September 2016. 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 795 Service Function Chaining", RFC 7498, 796 DOI 10.17487/RFC7498, April 2015, 797 . 799 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 800 Chaining (SFC) Architecture", RFC 7665, 801 DOI 10.17487/RFC7665, October 2015, 802 . 804 9.2. Informative References 806 [I-D.kumar-sfc-offloads] 807 Surendra, S., Guichard, J., Quinn, P., Halpern, J., and S. 808 Majee, "Service Function Simple Offloads", draft-kumar- 809 sfc-offloads-03 (work in progress), October 2016. 811 [I-D.penno-sfc-packet] 812 Penno, R., Pignataro, C., Yen, C., Wang, E., Leung, K., 813 and D. Dolson, "Packet Generation in Service Function 814 Chains", draft-penno-sfc-packet-03 (work in progress), 815 April 2016. 817 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 818 Address Translator (Traditional NAT)", RFC 3022, 819 DOI 10.17487/RFC3022, January 2001, 820 . 822 Authors' Addresses 824 Eric Wang 825 Cisco Systems Inc. 826 170 W Tasman Dr 827 San Jose, CA 95134 828 U.S.A. 830 Email: ejwang@cisco.com 831 Kent Leung 832 Cisco Systems Inc. 833 170 W Tasman Dr 834 San Jose, CA 95134 835 U.S.A. 837 Email: kleung@cisco.com 839 Jeremy Felix 840 Cisco Systems Inc. 841 170 W Tasman Dr 842 San Jose, CA 95134 843 U.S.A. 845 Email: jefelix@cisco.com 847 Jay Iyer 848 Cisco Systems Inc. 849 170 W Tasman Dr 850 San Jose, CA 95134 851 U.S.A. 853 Email: jiyer@cisco.com