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