| Service Function Chaining | E. Wang |
| Internet-Draft | K. Leung |
| Intended status: Informational | Cisco Systems Inc. |
| Expires: December 30, 2017 | June 28, 2017 |
Receive-Only Service Function and External Service in SFC
draft-wang-sfc-receive-only-02
A category of services such as Intrusion Detection Service and Packet Capture operates in "receive-only" mode. They are "packet sinks" which consume all packets sent to them. This document describes the proposals for such service to be part of the Service Function Chaining framework.
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 December 30, 2017.
Copyright (c) 2017 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.
Services in Service Function Chaining (SFC) usually operate in "inline" mode, where they process the received packets and return the packets to the Service Function Forwarder (SFF). Some services especially in the network security domain can buffer, inject or block certain packets, as well as proxy entire connections ([I-D.wang-sfc-ns-use-cases]). However, in general they still forward packets.
[I-D.wang-sfc-ns-use-cases] also describes a special set of services that consume all packets sent to them. We refer to such behavior as "receive-only". A receive-only service could be a Service Function (SF) participating in SFC ([RFC7665]), or it could be an External Service (ES) receiving packets from the SFF or another regular SF. This document describes proposals for designing SFC packet plane and control plane to incorporate receive-only services.
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.
This document uses the terms as defined in [RFC7498], [RFC7665] and [I-D.ietf-sfc-nsh].
In addition the following terms are defined.
A receive-only service may be a Service Function (SF) or External Service (ES) depending on whether the SFC administrator designs the service to be part of the SFC or not.
In the following example, the IDS service is located between "DDoS Mitigator" and "Firewall" as part of an integrated security solution to protect the server (S). Packets from the client (C) must be examined by a chain of services before they reach the server. The three service functions, DDoS, IDS and Firewall, compose an SFC. Each SF including the IDS SF is allocated with a Service Index (SI) in the SFP. The IDS SF is a fundamental part of the service chain with the only exception that it does not egress packets. We refer to the IDS service as a Receive-Only SF (RO SF).
There are other attributes for an RO SF. There is a limited number of location options for "IDS" to be deployed in an SFC. Once deployed, the location of "IDS" does not change usually unless the SFs are added to or removed from the SFC.
Extending the SFC framework to RO SF enables a common SFC policy model for SFC administrators. The administrator only needs to manage one set of policy that covers both RO and regular SFs, no matter how they handle packets.
.---. .---. .-------.
/ \ / \ / \
( DDoS ) ( [IDS] ) ( Firewall )
\ / \ / \ /
`-+-' `-+-' `---+---'
/|\ /|\ /|\
| | copy |
+---+ \|/ | \|/ +---+
| | ,--+-----------+-------------+----. | |
| C +----( SFF )----+ S |
| | `---------------------------------' | |
+---+ +---+
SFC - DDoS : [IDS] : Firewall
[ ] denotes receive-only
Figure 1: Receive-Only Service Function (RO SF) example
"Packet Capture" for troubleshooting represents the other type of receive-only services that do not participate in SFC.
The administrator may insert "Packet Capture" at any stage of an SFP. Packets may be captured before and/or after one or multiple SFs, which means there are many possible invocation points for "Packet Capture" in an SFP. The administrator may want to dynamically insert or remove "Packet Capture" based on the need for troubleshooting and threat analysis. When doing so, it is desired that the construction of the SFP is not affected. That is, the Service Path ID (SPID) and Service Index (SI) for each of the SFs in the SFP remain unchanged.
Services with the above attributes receive SFC packets but are not listed in an SFC. They do not consume an SI in the SFP. We refer to such a service as a Receive-Only External Service (RO ES).
An RO ES still requires support from SFC elements including SFF and SF for receiving packets. Because an RO ES does not send back packets, it must receive replication of the packets. Depending on the use cases and performance requirements, an SFF or SF may perform the packet replication for the RO ES. For example, a Packet Capture for troubleshooting purpose may tap on the SFF at one or more locations along the SFP (Figure 2).
This document describes the necessary enhancements to the SFC framework for supporting RO ES.
+------+
copy | | copy
...\....| [PC] |.../.......
. / | | \ .
. _.+------+ .
. .| .
. . copy +------+ .
. . | | .
. . | [FC] | .
. . | | .
. . _.+------+ .
. . .| .
. . . copy .
. . . .
. .---. . .----+--. .---. .
. / \ . / \ / \ .
. ( DDoS ) . ( Firewall ) ( WAF ) .
. \ / . \ / \ / .
. `-+-' . `---+---' `-+-' .
. /|\ . /|\ /|\ .
. | . | | .
+---+ . \|/ . \|/ \|/ . +---+
| | ,+-----+-----+-------+-------------+-----+--. | |
| C +----( SFF )----+ S |
| | `-------------------------------------------' | |
+---+ +---+
SFC - DDoS : Firewall : WAF
[ ] denotes receive-only
PC: Packet Capture
FC: File Capture
Figure 2: Receive-Only External Service (RO ES) examples
A Receive-Only SF behaves the same way as a regular SF except that it does not forward packets. As a result, it must receive a copy of the packets while the original packets travel through the rest of the SFs in the SFP. Because an RO SF occupies an SI in the SFP, the SI of the original packet must be decremented after the packet passes the RO SF.
Considering the fact that an RO SF does not forward packets and SFF is not designed to decrement SI, an Extended SFC Proxy is leveraged to perform the packet replication and SI decrement tasks on behalf of the RO SF. As shown in the Figure below, the Extended SFC Proxy makes a copy of the packet including the NSH and sends the copy to the RO SF-2. It decrements the SI of original packet and forwards that packet back to the SFF. This capability is an extension to the current SFC Proxy as defined in ([RFC7665]).
From the SFF's perspective, the combination of the Extended SFC Proxy and the RO SF behaves as a regular SF that processes and forwards packets with SI decremented. From the RO SF's perspective, the Extended SFC Proxy may be a logical component in the specific SFF implementation for efficiency.
.---. .---. .---.
/ \ / \ / \
( SF-1 ) ( [SF-2]) ( SF-3 )
\ / \ / \ /
`-+-' `-+-' `-+-'
| /.\ /|\
| . (3) |
| . SPID:10 |
| . SI:254 |
| . |
| . [copy] |
(1) | . |(5)
SPID:10| ,-----+-----. |SPID:10
SI:254 | ( Extended ) |SI:253
| ( SFC Proxy ) |
| ( ) |
| ( Replicator ) |
| `---+---+---' |
| /|\ |(4) |
| (2) | |SPID:10 |
| SPID:10| |SI:253 |
\|/ SI:254 | \|/ |
,----+----------+---+-----------+------.
( : : : : )
( : +---+ : : +---+ : )
( : | | : : | | : )
( :..+FWD+...: :...+FWD+...: )
( | | | | )
( +---+ +---+ )
( SFF )
`--------------------------------------'
FWD: Forwarding Table Lookup
Figure 3: Packet Replication and SI Decrement by Extended SFC Proxy for RO SF
A packet goes through the following steps in the above example:
A Receive-Only External Service still receives a copy of the packets designated to it even if it is not listed in the SFP.
For some use cases such as capturing a file content for sandbox analysis, packet data replication may be conducted by an SF capable of identifying file boundary in the packet stream. The RO ES would be associated with the SF and receives packet data from the SF directly.
Alternatively, for use cases such as generic packet capture for troubleshooting, the SFF may carry out the packet replication and forwarding work. Higher performance may be achieved with hardware based SFF.
+-------+ +-------+
| | | |
| [ES-1]| .| [ES-1]|.
| | . | | .
+---+---+ _. +---+---+ ._
. . .| /.\ |.copy
. . . copy .copy .
_. ._ . . .
.| |.copy . . .
. copy . . . .
. . . . .
.---. .---. . .---. . .---. .
/ \ / \ . / \ . / \ .
( SF-1 ) ( SF-2 ) . ( SF-1 ) . ( SF-2 ) .
\ / \ / . \ / . \ / .
`-+-' `-+-' . `-+-' . `-+-' .
/|\ /|\ . /|\ . /|\ .
| | . | . | .
\|/ \|/ . \|/ . \|/ .
,-------+--------------+-------. ,-+-----+------+------+-----+-.
( SFF ) ( SFF )
`------------------------------' `-----------------------------'
(a) Copy by SF (b) Copy by SFF
Figure 4: Packet replication options for RO ES
When an RO ES receives packets from the SFF, it may be attached to the SFF at multiple locations along the SFP. The location may be indicated by a (SPID, SI) pair and programmed into the SFF's forwarding table.
The SFF performs packet replication when the packet needs to be sent to the RO ES (SFC Proxy cannot be used because RO ES is not an SF). The SI of the original packet MUST NOT be affected by the fact that a copy is being sent to the RO ES. The following figure illustrates an example with SFF performing packet replication.
+-------+
| |
| [ES-1]|
| |
+---+---+
/.\
.---. . .---.
/ \ . / \
( SF-1 ) . ( SF-2 )
\ / . \ /
`-+-' . `-+-'
| . /|\
| .(2) |
|(1) .SPID:10 |(3)
|SPID:10 .SI:254 |SPID:10
|SI:254 . |SI:254
| .[copy] |
\|/ . |
,----+-----------+-----------+------.
( : : : )
( : +--+--+ : )
( : | REP | : )
( : +---+ +--+--+ : )
( : | | : : )
( :.+FWD+.....:...........: )
( | | )
( +---+ )
( SFF )
`-----------------------------------'
FWD: Forwarding Table Lookup
REP: Packet Replication
Figure 5: Packet Replication by SFF for RO ES
Here is a sample packet flow involving an Receive-Only External Service:
An RO SF such as IDS is specified the same way as a regular SF in the SFC Classification Policy. For example, the SFC in Figure 1 contains the following SFs:
SFC - DDoS : [IDS] : Firewall
When the SFC is converted to an SFP, the combination of Extended SFC Proxy and the IDS RO SF presents as a regular SF in the SFP as depicted in Figure 3. The SFP comprises of the following:
SFP - DDoS : SFC Proxy for [IDS] : Firewall
The SFC Control Plane also provisions the Extended SFC Proxy to send the replicated packet to the [IDS] SF. The provisioning message is outside the scope of this document.
An RO ES is not provisioned by SFC Classification Policy. Implementation may choose to use a dedicated policy for an RO ES such as "Packet Capture Policy".
The policy for RO ES may be configured into a regular SF when the SF performs replication for the RO ES.
In the scenario where SFF performs packet replication, the RO ES policy may be evaluated by the SFC Control Plane. The SFC Control Plane programs the replication locations into the SFF, as indicated by (SPID, SI) pairs. Figure 6 below illustrates a control plane flow for setting packet replication in the SFF for an RO ES.
+-------------------+
| |
| SFC Control Plane |
| |
| .--. |
| (1) : : |
| |'--'| |
| RO-ES | | |
| Policy| | |
| Eval '--' |
| |
+------+------------+ Control Plane
.........|................................
|
| +-------+ Packet Plane
| | |
| | RO ES |
|(2) | |
| +---+---+
|C2 /:\
| :packet
| :copy
v :
,--+---------+--+--+--.
( | REP | )
( SFF +-----+ )
( )
`---------------------'
Figure 6: Control flow for SFF replication for RO ES
An RO SF MUST NOT send received packets back to the Extended SFC Proxy.
The Extended SFC Proxy for an RO SF carries the following additional capabilities compared with a regular SFC Proxy:
The Extended SFC Proxy MUST discard any packets from the RO SF to prevent duplicated packets to the SFF. When preserved, the NSH SPID/SI in the packet copy sent to RO SF MUST not change. The NSH SI in the original packet forwarded back to the SFF MUST be decremented.
An RO ES should have proper transport with the data source, either the SF or SFF. If it receives replicated packets from the SFF, the RO ES should comply with the transport as specified for the SFC, similar to that between a regular SF and the SFF.
An RO ES MUST NOT send received packets back to the data source.
There is not any special requirement for the SFF to support an RO SF. The Extended SFC Proxy performs packet replication and other regular SF tasks on behalf of the RO SF.
The following figure illustrates a sample SFF forwarding table when the SFF carries out the packet replication task for RO ES. The "copy" column in the forwarding table is used to decide whether a copy or the original packet should be sent to the next hop (SF or ES). Entries for the RO ES have the "copy" field set.
SFF Forwarding Entries
+------+------+------+------+
| SPID | SI | Next | Copy |
| | | Hop | |
+------+------+------+------+
| ... | | | |
+------+------+------+------+
| | | SF-1 | |
| 10 | 254 +------+------+
| | | ES-1 | x |
+------+------+------+------+
| 10 | 253 | SF-2 | |
+------+------+------+------+
| 20 | 254 | SF-1 | |
+------+------+------+------+
| | | SF-3 | |
| 20 | 253 +------+------+
| | | ES-2 | x |
+------+------+------+------+
| 20 | 252 | SF-4 | |
+------+------+------+------+
| ... | | | |
+------+------+------+------+
Figure 7: Sample SFF forwarding table with RO ES entries
In order to support RO ES, implementation of an SFF SHOULD support the following capabilities:
Additional capabilities for receive-only support include the following:
Those capabilities are beyond the scope of this document.
Even if an RO SF is required not to send packets back to the Extended SFC Proxy, the implementation of Extended SFC Proxy SHOULD handle packets from an RO SF gracefully without causing exceptions or duplicated packets in the SFP.
Authors would like to thank Jeremy Felix and Jay Iyer for their contributions, and Jim Guichard, Paul Quinn and Joel Halpern for their review and comments.
This document includes no request to IANA.
| [I-D.ietf-sfc-control-plane] | Boucadair, M., "Service Function Chaining (SFC) Control Plane Components & Requirements", Internet-Draft draft-ietf-sfc-control-plane-08, October 2016. |
| [I-D.ietf-sfc-nsh] | Quinn, P. and U. Elzur, "Network Service Header", Internet-Draft draft-ietf-sfc-nsh-12, February 2017. |
| [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.wang-sfc-ns-use-cases] | Wang, E., Leung, K., Felix, J. and J. Iyer, "Service Function Chaining Use Cases for Network Security", Internet-Draft draft-wang-sfc-ns-use-cases-02, October 2016. |