One document matched: draft-wang-sfc-ns-use-cases-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7498 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7498.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC7665 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7665.xml">
<!ENTITY I-D.draft-ietf-sfc-nsh SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-02.xml">
<!ENTITY I-D.draft-kumar-sfc-offloads SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kumar-sfc-offloads-02.xml">
<!ENTITY I-D.draft-penno-sfc-packet SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-penno-sfc-packet-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-wang-sfc-ns-use-cases-01"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="SFC Network Security Use Cases">Service Function Chaining
Use Cases for Network Security</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Eric Wang" initials="E." surname="Wang">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<street>170 W Tasman Dr</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>U.S.A.</country>
</postal>
<phone/>
<facsimile/>
<email>ejwang@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="Kent Leung" initials="K." surname="Leung">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<street>170 W Tasman Dr</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>U.S.A.</country>
</postal>
<phone/>
<facsimile/>
<email>kleung@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="Jeremy Felix" initials="J." surname="Felix">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<street>170 W Tasman Dr</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>U.S.A.</country>
</postal>
<phone/>
<facsimile/>
<email>jefelix@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="Jay Iyer" initials="J." surname="Iyer">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<street>170 W Tasman Dr</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>U.S.A.</country>
</postal>
<phone/>
<facsimile/>
<email>jiyer@cisco.com</email>
<uri/>
</address>
</author>
<date month="March" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Service Function Chaining</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>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.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Definition Of Terms">
<t>This document uses the terms as defined in <xref target="RFC7498">RFC
7498</xref>, <xref target="RFC7665">RFC 665</xref> and <xref
target="I-D.ietf-sfc-nsh"/>.</t>
<t>In addition the following terms are defined.</t>
<t><list hangIndent="4" style="hanging">
<t hangText="Security Service Function (Security SF):">A Security
Service Function is a Service Function that carries out specific
security tasks. We limit the scope of security functions to network
security in this document (as opposed to functions such as endpoint
security). In addition to the general forwarding action, a Security
Service Function can buffer, proxy, inject or block certain packets
based on its policy. A Security Service Function can maintain state
at the connection, session or transaction levels. Sample Security
Service Functions are: Firewall, Intrusion Prevention/Detection
System (IPS/IDS), Deep Packet Inspection (DPI), Application
Visibility and Control (AVC), network virus and malware scanning,
sandbox, Data Loss Prevention (DLP), Distributed Denial of Service
(DDoS) mitigation and TLS proxy.</t>
<t hangText="Flow:">A flow is a uni-directional traffic stream
identified by network layer attributes, specifically IP addresses
and TCP/UDP ports for TCP/UDP traffic.</t>
<t hangText="Connection:">A connection is a bi-directional traffic
stream composed of two flows sharing the same network layer
attributes.</t>
</list></t>
</section>
<section title="Characteristics of Security Service Functions">
<t>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.</t>
<t>Security Service Functions operate on network layer data with
specific behaviors. For example:</t>
<t><list hangIndent="4" style="numbers">
<t>A Firewall tracks TCP state between the TCP client and server.
TCP packets that do not correspond to the Firewall's maintained
state are likely to be dropped.</t>
<t>A Firewall can modify the L3/L4 headers for NAT <xref
target="RFC3022"/>. The flow attributes in the packet header may be
changed after the packet egresses the Firewall.</t>
<t>A Firewall can proxy a TCP connection by sending a TCP ACK on
behalf of the endpoint. From the SFC perspective, this results in
Service Function generated packets being injected into the service
path in the reverse direction.</t>
<t>A Firewall or DDoS mitigator can inject TCP layer challenges to
the originating client before the intended server receives a packet
from the client.</t>
</list>Security Functions also handle packets and examine data at
higher OSI layers. For example:</t>
<t><list hangIndent="4" style="numbers">
<t>A Firewall can inspect the HTTP header and body data. Based on
the inspection results, the firewall can decide to drop the packet
and/or block the connection completely.</t>
<t>A Web proxy can inject an HTTP challenge page into an HTTP
transaction for the purposes of authentication and identity
collection.</t>
<t>At the enterprise edge, a TLS proxy, when authorized, operates as
a trusted Man-in-the-Middle to proxy the TLS handshake and decrypt
the packet data. The TCP payload may be completely different between
ingress and egress of TLS Proxy.</t>
<t>A stream scanning service examines a certain set of application
data. File scanning engines examine file streams of specific
types.</t>
</list></t>
</section>
<section title="Use Cases">
<section title="Service Classification Use Cases">
<section title="Service classification for bi-directional traffic">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure align="center"
title="Figure 1: Forward and return flows between two hosts">
<artwork align="center"><![CDATA[ ,--------------.
/ \
/ .--. \
/ / \ \
/ ( 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]]></artwork>
</figure>
<t/>
</section>
<section title="Service Classifier to distinguish initiator and responder">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Service Classification based on network and application criteria">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Those criteria may comprise “application data” from
above the network layer, referred to as "application criteria". For
example, a policy rule may state:</t>
<t><list hangIndent="4" style="empty">
<t>for all TLS traffic, run the traffic through Service Function
"TLS Proxy"</t>
</list>Another example of an application layer policy rule is:</t>
<t><list hangIndent="4" style="empty">
<t>for all HTTP traffic with content containing file types of
interest, run the traffic through Service Function "File Stream
Scanner"</t>
</list></t>
<t>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.</t>
</section>
<section title="Switching Service Function Paths based on inspection and scanning results">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>A new Service Function Path may be selected by a non-initial
classification, different from the one determined by the initial
classification.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure align="center"
title="Figure 2: Mid-stream service function path update">
<artwork align="center"><![CDATA[ ,-----.
/ \
/ .---. \
/ / \ \
/ ( TLS ) \
-----------' ( Proxy ) `-SFP-2. AVC:TLS Proxy:Firewall->
/\ / \
/ `---' \ .--.
+---+ .-./ .`------. ( )-. +---+
| | / \ / \ .' ) | |
| A +----( AVC )--------( Firewall )---( Internet )----+ B |
| | \ / \ / ( -' | |
+---+ `-' `-------' '-( ) +---+
'---'
--------------SFP-1. AVC:Firewall ------------------------->]]></artwork>
</figure>
<t>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.</t>
<figure align="center"
title="Table 1: SFP taken by each packet in an HTTPS connection">
<artwork align="center"><![CDATA[+--------------------+-------------------------------------+
| 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 |
+--------------------+-------------------------------------+]]></artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Service Function Use Cases">
<section title="Service Classifier-capable Service Function">
<t>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.</t>
</section>
<section title="Service Functions operating on L5 or L7 data">
<t>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.</t>
</section>
<section title="Service Function mid-stream pick-up">
<t>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.</t>
<figure align="center"
title="Table 2: Service Functions visited by each packet in an HTTPS connection">
<artwork align="center"><![CDATA[+--------------------+-----+-----------+----------+
| 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 |
+--------------------+-----+-----------+----------+]]></artwork>
</figure>
<t>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.</t>
</section>
<section title="Bypassing a particular Service Function">
<t>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:</t>
<t><list hangIndent="4" style="symbols">
<t>"Firewall" may request offloading of certain flows to fast
forwarding engine with minimal inspection</t>
<t>"HTTP Inspector" may decide to not inspect video streams from
a site with a high reputation</t>
<t>"TLS Proxy" may have to avoid decryption of banking traffic
for compliance reasons</t>
</list>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.</t>
<t>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.</t>
<figure align="center"
title="Figure 3: Service function bypass examples">
<artwork align="center"><![CDATA[ .-------.
/ \
( HTTP )
( Inspector )
,---------------------------.
/ `---+---' \
/ | \
| | |
| .---+---. |
| / \ |
| ( Firewall ) |
| ,---------------. |
| / `---+---' \ |
| / | \ |
| | | | |
| | .---+---. |TCP |HTTP
| | / \ |control |Headers
| | ( SFF ) |packets |
| | ,-------------. | |
| | / `-------' \ | |
| | | | | |
| | |Offloaded | | |
| | |packets | | |
| | | | | |
v v v v v v]]></artwork>
</figure>
<t>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.</t>
<t>Service Function bypass may also follow the procedure described
in "Service Function Simple Offloads" <xref
target="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.</t>
</section>
<section title="Receive-only Service Functions">
<t>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.</t>
<figure align="center"
title="Figure 4: Receive-only service functions in SFC">
<artwork align="center"><![CDATA[ .---.
/ \
( [IDS] )
\ /
`-+-'
.---. /|\ .-------.
/ \ | / \
( DDoS ) | ( Firewall )
\ / | \ /
`-+-' |copy `---+---'
/|\ | /|\
| | |
+---+ \|/ | \|/ +---+
| | ,--+-----+-----------+----. | |
| C +----( SFF )----+ S |
| | `-------------------------' | |
+---+ +---+
[ ] denotes receive-only]]></artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Service Data Handling Use Cases">
<section title="Service Function injected new packet">
<t>Security Service Functions may inject new packets into an
existing flow in either direction. For example,</t>
<t><list hangIndent="4" style="symbols">
<t>"Web Proxy" inserts an HTTP page challenging the client to
login, in order to obtain the client's identity. This is in
response to a packet (likely HTTP Request) but in the opposite
direction of the flow.</t>
<t>“Firewall” checks an idle TCP connection by
sending TCP keepalives to the client and/or server (known as
“TCP dead connection detection”). This is on
existing flows but not responding to a prior packet.</t>
<t>“Firewall” sends ICMP error message after
dropping a packet. This is in response to the prior packet but
on a new flow.</t>
</list></t>
<t>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 <xref
target="I-D.penno-sfc-packet"/> may be adopted to support this use
case.</t>
</section>
<section title="Service Function initiated connections">
<t>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.</t>
<figure align="center"
title="Figure 5: SFC for service function initiated connection">
<artwork align="center"><![CDATA[ <------ SFC-1. Firewall:LB:IPS ------>
+---+ .-------. .--. .-. +---+
| | / \ / \ / \ | |
| C +---( Firewall )---( LB )---( IPS )---+ S |
| | \ / \ / \ / | |
+---+ `-------' `--' `-' +---+
<-- SFC-2. LB:IPS -->]]></artwork>
</figure>
<t>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.</t>
<t>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.</t>
</section>
<section title="Security classification results">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure align="center"
title="Figure 6: Security classification result with accumulated client score">
<artwork align="center"><![CDATA[ .------.
+---+ .--------. .--------. / \ +---+
| | / \ / \ ( 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 |
| |
\-------/]]></artwork>
</figure>
<t>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.</t>
<figure align="center"
title="Figure 7: Aggregation of security classification results">
<artwork align="center"><![CDATA[ .------.
+---+ .--------. .--------. / \ +---+
| | / \ / \ ( 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 |
`----------------------------->| | | |
+------+ \-------/]]></artwork>
</figure>
<t/>
</section>
</section>
</section>
<section title="General Requirements">
<t>The above use cases lead to the following requirements for applying
SFC to security services on the data traffic.</t>
<t>Requirements that may need working group drafts:</t>
<t><list hangIndent="4" style="numbers">
<t>SFC SHOULD allow packet frames carrying only L5 and upper layer
traffic data without L2-L4 headers.</t>
<t>SFC SHOULD support bypass of a Service Function in the middle of
a connection while allowing necessary control packets to reach the
Service Function. Possible extension to <xref
target="I-D.kumar-sfc-offloads"/></t>
<t>SFC control plane and packet plane MUST support receive-only
Service Functions.</t>
<t>SFC MUST support packet injection to the opposite direction of a
Service Function Path. Possible extension to <xref
target="I-D.penno-sfc-packet"/></t>
<t>SFC SHOULD allow metadata passing classification results.</t>
</list>Requirements for implementation driven by respective use
cases:</t>
<t><list hangIndent="4" style="numbers">
<t>SFC MUST support the use of stateful Service Classifiers and
Service Functions if present.</t>
<t>Service Classifiers MUST have the ability to classify forward and
the corresponding reverse Service Function Paths.</t>
<t>Service Classifiers MUST be able to distinguish between traffic
initiator and responder.</t>
<t>SFC MUST support the use of Service Policies with network and
application layer match criteria if supported by Service
Classifier.</t>
<t>SFC MUST support Service Function Path update or selection of a
new path by a Service Classifier in the middle of a flow.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>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.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Paul Quinn, Reinaldo Penno and Jim
Guichard for their detailed review, comments and contributions.</t>
</section>
<section title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<!-- -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7498.xml"?-->
&RFC7498;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.RFC.7665.xml"?-->
&RFC7665;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-02.xml"?-->
&I-D.draft-ietf-sfc-nsh;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kumar-sfc-offloads-02.xml"?-->
&I-D.draft-kumar-sfc-offloads;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-penno-sfc-packet-02.xml"?-->
&I-D.draft-penno-sfc-packet;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml"?-->
&RFC3022;
<!-- A reference written by by an organization not a person. -->
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:24 |