| Service Function Chaining | E. Wang |
| Internet-Draft | K. Leung |
| Intended status: Informational | J. Felix |
| Expires: April 28, 2017 | J. Iyer |
| Cisco Systems Inc. | |
| October 25, 2016 |
Service Function Chaining Use Cases for Network Security
draft-wang-sfc-ns-use-cases-02
Enterprise networks deploy a variety of security devices to protect the network, hosts and endpoints. Network security devices, both hardware and virtual, operate at all OSI layers with scanning and analysis capabilities for application content. Multiple specific devices are often deployed together for breadth and depth of defense. This document describes use cases of Service Function Chaining (SFC) when deploying network security devices in the manner described above and also puts forth requirements for their effective operation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Network security service nodes participate in Service Function Chaining (SFC) to provide comprehensive solutions for securing campus and data center enterprise networks. Often, network operators deploy various types and instances of security service nodes. These nodes are complementary to one another for the purpose of coverage, depth of defense, scalability and availability.
In addition to packet forwarding, network security devices can buffer, inject or block certain packets, as well as proxy entire connections. Most of the network security devices maintain state at the connection, session or transaction levels. When used in a SFC environment these security Service Function actions and properties require careful design and extension including the Service Classifier and Service Function itself. This document attempts to describe the detailed use cases that lead to the requirements to support network security functions in SFC.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the terms as defined in RFC 7498 [RFC7498], RFC 665 [RFC7665] and [I-D.ietf-sfc-nsh].
In addition the following terms are defined.
Most Security Service Functions are stateful. They maintain state at the connection, session or transaction levels, depending on the OSI layers that they act on. Many Security Functions require receiving both directions of the client-server traffic in order to maintain state properly. Asymmetric traffic must be normalized before packets reach the Security Functions.
Security Service Functions operate on network layer data with specific behaviors. For example:
Security Functions also handle packets and examine data at higher OSI layers. For example:
Many Security Service Functions require receiving bi-directional traffic of a connection. For example, a DDoS mitigator may require to see the return traffic to maintain proper state.
Return traffic (i.e. server to client response) should be classified based on the forward traffic (i.e. the client to server request). This allows server's return traffic to be associated with the clients forward traffic. The forward and return traffic forms a single bi-directional connection and shares Service Function Paths with similar set of Service Functions.
In the figure below, the Service Classifier handling traffic from Host B must be able to identify return traffic (flow 2) and select the Service Function Path with “DDoS”. Flow 1 and 2 form a connection and traverse DDoS in both directions.
,--------------.
/ \
/ .--. \
/ / \ \
/ ( DDoS ) \
------------' / \ / \ `--(1) Forward Flow (A=>B)-->
/ `--' \
/ \
+---+ .--./ `-------. +---+
| | / \ / \ | |
| A +------( SC )-----------( Firewall )--------------------+ B |
| | \ / \ / | |
+---+ `--' `-------' +---+
(a) Flows from Host A
,------------.
/ \
/ .--. \
/ / \ \
/ ( DDoS ) \
<------------' / \ / \ `---(2) Return Flow (A<=B)----
/ `--' \
/ \
+---+ / `-------. .--. +---+
| | / / \ / \ | |
| A +----------+--------------( Firewall )------( SC )------+ B |
| | \ / \ / | |
+---+ `-------' `--' +---+
<-------------(3) Forward Flow (A<=B)----------------------------
(b) Flows from Host B
Figure 1: Forward and return flows between two hosts
Even if a Security Service Function requires receiving bi-directional traffic of a connection, it should not necessarily receive traffic initiated from all network segments for performance, availability, and scalability reasons. For example, a DDoS mitigator is configured to receive bi-directional traffic initiated from the Internet, but not for traffic initiated from the internal network.
Traffic initiated from a network segment should be classified independently. In Figure 1(b), the Service Classifier for Host B must identify traffic initiated by Host B (flow 3) and classify it independently. Such traffic bypasses the DDoS Service Function in this example.
The Service Classifier must distinguish between flow 2 and flow 3, both of which are from Host B to Host A. In other words, it must be able to identify the initiator and responder of a connection.
A Service Classifier that keeps certain state would be able to handle the above requirements. The state should be accessible by each Service Classifier if there are multiple instances handling traffic sources from various network segments.
The Service Classifier evaluates SFC Policies (i.e. Service Policies) in order to determine the traffic and associated Service Function Paths. In the case of Security Service Functions, the Service Policies can contain match criteria derived from all OSI layers of the packet.
SFC classification is often based on network data, including but not limited to: Network interface port, VLAN, source and destination IP addresses, source and destination TCP and UDP ports, IP protocol, etc. These properties can be derived from the packet headers and are consistent across every packet of a flow.
There are match criteria that are desired by Security Service Functions that are either not present in the first packet, or are not present in every packet.
Those criteria may comprise “application data” from above the network layer, referred to as "application criteria". For example, a policy rule may state:
Another example of an application layer policy rule is:
The Service Classifier for Security Service Functions needs to handle complex Service Policy. In some cases, this can be achieved by embedding the Service Classifier function into a Security Service Function, such that it can evaluate the application data as it becomes available.
Network data is likely to be available on the first packet of the flow. When only network data is used as Service Policy match criteria, a stateful Service Classifier will be able to determine the forward and reverse Service Function Paths from the first packet (initial classification). The forward and reverse Service Function Paths remain unchanged for the entire life of the flow for these types of policies.
When the Service Policy contains application criteria, the policy rule may not be fully evaluated until several packets have passed through the chain. For example, TLS traffic can be identified only after the TLS Client Hello handshake message is observed.
Multiple classifiers may be required to provide sufficient classification granularity and complete a full evaluation of the Service Policy. In many cases, classification will be co-located with a Security Service Function that has the ability to inspect and scan the application data.
A new Service Function Path may be selected by a non-initial classification, different from the one determined by the initial classification.
The selection of a new Service Function Path can be reflected in the NSH Service Path Header as a new Service Path ID for the Service Function Forwarder to direct the packet accordingly.
The decision of a new Service Function Path often needs to be stored in the Service Classifier to ensure that subsequent packets of the flow follow the new path. This is because the data that triggers a new Service Function Path may be available from one particular packet only. For example, the packet with the TLS Client Hello message is used to identify a TLS session. Subsequent packets may not contain information for identifying the TLS sessions. All subsequent packets, without being classified again, must travel through the path with the “TLS Proxy” Service Function.
The Service Function that is new in the packet path (as part of the new Service Function Path) has to be able to handle not seeing earlier packets in the flow. Refer to Section 4.2 for more discussions on Service Functions.
,-----.
/ \
/ .---. \
/ / \ \
/ ( TLS ) \
-----------' ( Proxy ) `-SFP-2. AVC:TLS Proxy:Firewall->
/\ / \
/ `---' \ .--.
+---+ .-./ .`------. ( )-. +---+
| | / \ / \ .' ) | |
| A +----( AVC )--------( Firewall )---( Internet )----+ B |
| | \ / \ / ( -' | |
+---+ `-' `-------' '-( ) +---+
'---'
--------------SFP-1. AVC:Firewall ------------------------->
Figure 2: Mid-stream service function path update
Figure 2 illustrates a simple set of Security Functions deployed at the Internet edge. The default Service Function Path is SFP-1, with Service Functions "AVC" and "Firewall". When a TLS session is detected (e.g. by detecting the TLS Client Hello in the AVC Service Function), packets of the flow from that point on are switched to SFP-2, which contains "TLS Proxy" between "AVC" and "Firewall" to decrypt the TLS traffic for inspection.
+--------------------+-------------------------------------+ | Packets | Service Function Path | +--------------------+-------------------------------------+ | TCP Handshake | SFP-1. AVC:Firewall | +--------------------+-------------------------------------+ | TLS Client Hello | SFP-1; Switched to SFP-2 after AVC | +--------------------+-------------------------------------+ | Rest of TLS HS | SFP-2. AVC:TLS Proxy:Firewall | +--------------------+-------------------------------------+ | HTTPS Data | SFP-2. AVC:TLS Proxy:Firewall | +--------------------+-------------------------------------+
Table 1: SFP taken by each packet in an HTTPS connection
Table 1 lists the Service Function Path for each packet in an HTTPS connection, from the TCP 3-way handshake to the HTTPS data packets. A new Service Function Path is selected in the middle of the connection after the TLS Client Hello is observed.
Service Functions that are capable of selecting a new Service Function Path must have the Service Classifier function integrated. Such Service Functions are often responsible for classification using their inspection and scanning results and updating Service Function Paths based on the Service Policy.
Certain Security Service Functions operate on L5 to L7 data. For example, a "TLS Proxy" consumes a TCP stream without retransmitted or overlapping TCP segments. A "Web Proxy" operates on TCP stream of HTTP traffic. The data consumed by such Service Functions may not be in the original packet frame format, and the data may not contain the original L2-L4 header information. Such Service Functions can obtain the session or flow information from the SFC metadata carried in NSH.
When a new Service Function Path is selected as a result of Service Policy re-evaluation with application layer policy metadata, a new Service Function may need to start handling packet frames in the middle of a flow. This is referred to as "mid-stream pick-up". Although this is mid-stream from a flow perspective, it is still a complete data stream from the Service Function perspective (e.g., although "TLS Proxy" Service Function may not see the prior TCP handshake packets, it still sees the entire TLS stream). Similarly, transaction based Service Functions only handle packets belonging to a particular transaction. Such Service Function may use the flow ID metadata carried in NSH to link the session back to the flow.
+--------------------+-----+-----------+----------+ | Packet | AVC | TLS Proxy | Firewall | +--------------------+-----+-----------+----------+ | TCP SYN | X | | X | +--------------------+-----+-----------+----------+ | TCP SYN/ACK | X | | X | +--------------------+-----+-----------+----------+ | TCP ACK | X | | X | +--------------------+-----+-----------+----------+ | TLS Client Hello | X | X | X | +--------------------+-----+-----------+----------+ | Rest of TLS HS | X | X | X | +--------------------+-----+-----------+----------+ | HTTPS Data | X | X | X | +--------------------+-----+-----------+----------+
Table 2: Service Functions visited by each packet in an HTTPS connection
Table 2 lists the Service Functions visited by each packet from an HTTPS connection. The first packet that the Service Function "TLS Proxy" receives is the TLS Client Hello, as opposed to the TCP handshake packets prior to it.
Certain Security Service Functions can be compute-intensive while only serving a particular task. It may be required to bypass such a Service Function in the middle of a flow. For example:
The decision to bypass a Service Function is made by the Service Function with its static policy, the inspection results and/or mid-stream evaluation of Service Policy.
Even if a flow is offloaded or bypassed, the Security Service Function may want to continue receiving critical packets for state tracking purposes. For example, "Firewall" may want to receive TCP control packets, and "HTTP Inspector" may want to track each transaction in the same flow.
.-------.
/ \
( HTTP )
( Inspector )
,---------------------------.
/ `---+---' \
/ | \
| | |
| .---+---. |
| / \ |
| ( Firewall ) |
| ,---------------. |
| / `---+---' \ |
| / | \ |
| | | | |
| | .---+---. |TCP |HTTP
| | / \ |control |Headers
| | ( SFF ) |packets |
| | ,-------------. | |
| | / `-------' \ | |
| | | | | |
| | |Offloaded | | |
| | |packets | | |
| | | | | |
v v v v v v
Figure 3: Service function bypass examples
A new Service Function Path may be selected to steer traffic to the path with the bypassed Service Function removed. The Service Function may update the NSH Service Path ID in the packet (in-band signaling) if the Service Function has knowledge of the relevant Service Function Paths. Alternatively, the Service Function may signal the Service Classifier (out-of-band) to update the Service Function Path for excluding the Service Function.
Service Function bypass may also follow the procedure described in "Service Function Simple Offloads" [I-D.kumar-sfc-offloads], where the Service Function signals the Service Function Forwarder to offload a flow, without selecting a new Service Function Path. The Service Function Forwarder caches the offload request and bypasses the Service Function in the service path for the remainder of the flow.
Certain Service Functions such as an IDS may operate in "receive-only" mode, i.e. they consume a packet instead of passing the packet through. The Service Function Forwarder should send copies of packets to receive-only Service Functions.
.---.
/ \
( [IDS] )
\ /
`-+-'
.---. /|\ .-------.
/ \ | / \
( DDoS ) | ( Firewall )
\ / | \ /
`-+-' |copy `---+---'
/|\ | /|\
| | |
+---+ \|/ | \|/ +---+
| | ,--+-----+-----------+----. | |
| C +----( SFF )----+ S |
| | `-------------------------' | |
+---+ +---+
[ ] denotes receive-only
Figure 4: Receive-only service functions in SFC
Figure 4 illustrates an example of receive-only Service Function and its insertion into a Service Function Chain. The IDS Service Function receives copies of packets from the Service Function Forwarder.
Security Service Functions may inject new packets into an existing flow in either direction. For example,
The Service Function or Service Classifier needs to conduct a lookup of the reverse Service Function Path and populate the NSH Service Path Header. The approaches described in [I-D.penno-sfc-packet] may be adopted to support this use case.
A Service Function may need to create its own connections that are not associated with any client connection. Use cases include probing of servers behind a web proxy. In such cases, there will be no existing metadata for the Service Function to use to establish this connection. Such connections should be classified just like any other connections traversing the Service Function Path, as there may be Service Functions that are required to perform operations such an NAT on such connections in order for it to reach its destination.
<------ SFC-1. Firewall:LB:IPS ------>
+---+ .-------. .--. .-. +---+
| | / \ / \ / \ | |
| C +---( Firewall )---( LB )---( IPS )---+ S |
| | \ / \ / \ / | |
+---+ `-------' `--' `-' +---+
<-- SFC-2. LB:IPS -->
Figure 5: SFC for service function initiated connection
Option 1: Service Classifier in Service Function. A Service Classifier-capable Service Function may conduct service classification to determine the Service Function Path for the Service Function initiated connection. It can add an NSH with the proper Service Path Headers to the packets, and the Service Function would be the first SF on the chain. Response traffic follows a reverse Service Function Path and terminates at the Service Function. The number of Service Path Identifiers increases with more Service Functions bearing such capability.
Option 2: Service Classifier external to Service Function. A Service Function may send native packets without NSH when it is not capable of service classification. Such traffic is handled by the Service Classifier, which will populate the traffic with the appropriate NSH.
Security Service Functions may generate security classification results (e.g. policy actions and inspection results) while processing the packet data. Certain actions such as packet drop and flow closure can be taken immediately.
However, Service Functions can choose not to take any action immediately. Instead, it may pass the classification results to the subsequent Service Functions or to a control point.
Security classification results may be carried in NSH metadata as a score value. The score can be relayed and refined by other Security Service Functions along the path. Figure 6 below depicts an example of accumulating the client's score based on the Service Function's classification result. The client's reputation score is 6 as reported by the Service Function "Reputation", and the score is then passed to the next Service Function "Web Proxy" as the initial score for the connection. "Web Proxy" reduces the score to 3 after detecting access to a low reputation website. The Service Function "File Scanner" is involved due to the low score so far. After the "File Scanner" conducts scanning on the downloaded file and identifies it to be a malware, it updates the score to be -5 which is below the threshold for the connection to be blocked.
.------.
+---+ .--------. .--------. / \ +---+
| | / \ / \ ( File ) | |
| C +---( Reputation )--( Web Proxy )--( Scanner )---+ S |
| | \ / \ / \ / | |
+---+ `--------' `--------' `------' +---+
| | |
V V V
+----------------------+--------------+-------------+
| | Client | Accessing | Malware |
| Reason | Reputation | website rep | found in |
| | score 6 | score 2 | download |
+--------+------+------+-------+------+-------+-----+
| | |
+---+---+ | |
| 6 | V |
+---+---+ | |
`------>-------+ V
| |
+---+---+ |
| 3 | |
+---+---+ |
`------>-------+
|
+---+---+
| -5 |
+---+---+
| /-------\
| | |
`------>| Block |
| |
\-------/
Figure 6: Security classification result with accumulated client score
Alternatively, each participating Service Function may send its own classification result to a central Service Function or control point for aggregation. Actions are then taken by a specific Service Function or control point based on the accumulated results. Figure 7 illustrates this option.
.------.
+---+ .--------. .--------. / \ +---+
| | / \ / \ ( File ) | |
| C +---( Reputation )--( Web Proxy )--( Scanner )---+ S |
| | \ / \ / \ / | |
+---+ `--------' `--------' `------' +---+
| | |
V V V
+--------+-------------+--------------+------------+
| SF | Client | Accessing | Malware |
|Classify| reputation | website rep | found in |
| Results| score 6 | score 2 | download |
+--------+------+------+-------+------+-----+------+
| | |
| | |
| | |
| | | +------+ /-------\
| | `->| | | |
| `-------------->| Eval +->+ Block |
`----------------------------->| | | |
+------+ \-------/
Figure 7: Aggregation of security classification results
The above use cases lead to the following requirements for applying SFC to security services on the data traffic.
Requirements that may need working group drafts:
Requirements for implementation driven by respective use cases:
This document describes use cases for Security Service Functions to participate in SFC. There are cases such as picking up traffic from the middle of a packet stream or handling packets without L2-L4 headers. Security Service Functions must process those types of traffic properly and associate them with the appropriate internal state.
While each Security Service Function applies its own implementation to secure the internal data, communications between Service Functions need to be secured as well. Measures must be taken to ensure metadata such as security classifications carried in NSH is not tampered.
The authors would like to thank Paul Quinn, Reinaldo Penno and Jim Guichard for their detailed review, comments and contributions.
This document includes no request to IANA.
| [I-D.ietf-sfc-nsh] | Quinn, P. and U. Elzur, "Network Service Header", Internet-Draft draft-ietf-sfc-nsh-10, September 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7498] | Quinn, P. and T. Nadeau, "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015. |
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |
| [I-D.kumar-sfc-offloads] | Surendra, S., Guichard, J., Quinn, P., Halpern, J. and S. Majee, "Service Function Simple Offloads", Internet-Draft draft-kumar-sfc-offloads-03, October 2016. |
| [I-D.penno-sfc-packet] | Penno, R., Pignataro, C., Yen, C., Wang, E., Leung, K. and D. Dolson, "Packet Generation in Service Function Chains", Internet-Draft draft-penno-sfc-packet-03, April 2016. |
| [RFC3022] | Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001. |