Internet DRAFT - draft-wang-sfc-receive-only
draft-wang-sfc-receive-only
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
Abstract
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.
Status of This Memo
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 Notice
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.
Wang & Leung Expires December 30, 2017 [Page 1]
Internet-Draft SFC Receive-only June 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Receive-Only Service Function vs. External Service . . . . . 3
4. SFC Packet Plane . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Receive-Only Service Function . . . . . . . . . . . . . . 6
4.2. Receive-Only External Service . . . . . . . . . . . . . . 9
5. SFC Control Plane . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Receive-Only Service Function . . . . . . . . . . . . . . 12
5.2. Receive-Only External Service . . . . . . . . . . . . . . 12
6. SFC Element Considerations . . . . . . . . . . . . . . . . . 13
6.1. Receive-Only Service Function . . . . . . . . . . . . . . 13
6.2. Extended SFC Proxy . . . . . . . . . . . . . . . . . . . 14
6.3. Receive-Only External Service . . . . . . . . . . . . . . 14
6.4. Service Function Forwarder . . . . . . . . . . . . . . . 14
6.4.1. Receive-Only Service Function . . . . . . . . . . . . 14
6.4.2. Receive-Only External Service . . . . . . . . . . . . 14
6.4.3. SFF Capabilities Considerations . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
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.
Wang & Leung Expires December 30, 2017 [Page 2]
Internet-Draft SFC Receive-only June 2017
1.1. Requirements Language
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].
2. Definition Of Terms
This document uses the terms as defined in [RFC7498], [RFC7665] and
[I-D.ietf-sfc-nsh].
In addition the following terms are defined.
Receive-Only (RO): A service operational mode where the service does
not forward on packets that it receives. It is often known as
"packet sink" as well.
RO SF: A Receive-Only Service Function participating in SFC as
defined in [RFC7665], except that the SF operates in Receive-Only
mode.
RO ES: A Receive-Only External Service not participating in SFC.
Specifically, an RO ES is not an SF. It is not allocated with a
Service Index (SI) in the Service Function Path (SFP). However,
it receives packets from the SFF or an SF.
Extended SFC Proxy: An SFC Proxy ([RFC7665]) with extended
capability to support Receive-Only SF. The SFC Proxy replicates
and sends packets to the RO SF. The SFC encapsulation may be
preserved if the RO SF is SFC aware. The Proxy forwards the
original packets back to the SFF in the same way as a regular SF
(e.g., with Service Index (SI) decremented in NSH).
Flow: A unidirectional traffic stream identified by network layer
attributes, specifically IP addresses and TCP/UDP ports for TCP/
UDP traffic.
Connection: A bidirectional traffic stream composed of two flows
sharing the same network layer attributes.
3. Receive-Only Service Function vs. External Service
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
Wang & Leung Expires December 30, 2017 [Page 3]
Internet-Draft SFC Receive-only June 2017
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.
Wang & Leung Expires December 30, 2017 [Page 4]
Internet-Draft SFC Receive-only June 2017
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.
Wang & Leung Expires December 30, 2017 [Page 5]
Internet-Draft SFC Receive-only June 2017
+------+
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
4. SFC Packet Plane
4.1. Receive-Only Service Function
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.
Wang & Leung Expires December 30, 2017 [Page 6]
Internet-Draft SFC Receive-only June 2017
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.
Wang & Leung Expires December 30, 2017 [Page 7]
Internet-Draft SFC Receive-only June 2017
.---. .---. .---.
/ \ / \ / \
( 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:
1. SFF receives the packet from SF-1 with SPID=10 and SI=254
2. SFF looks up in its forwarding table and finds Extended SFC Proxy
for SF-2 to be the next hop. SFF sends the packet to SF-2's
Proxy.
3. Extended SFC Proxy replicates the packet and sends the copy to
SF-2 which is an RO SF. The copy has SI=254
Wang & Leung Expires December 30, 2017 [Page 8]
Internet-Draft SFC Receive-only June 2017
4. Extended SFC Proxy decrements the SI of the original packet and
sends the packet back to SFF. The packet now has SI=253
5. SFF looks up the next service function, SF-3, in its forwarding
table based on the SPID and SI from Extended SFC Proxy. SFF
sends the packet to SF-3.
4.2. Receive-Only External Service
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.
Wang & Leung Expires December 30, 2017 [Page 9]
Internet-Draft SFC Receive-only June 2017
+-------+ +-------+
| | | |
| [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.
Wang & Leung Expires December 30, 2017 [Page 10]
Internet-Draft SFC Receive-only June 2017
+-------+
| |
| [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:
1. SFF receives the packet from SF-1 with SPID=10 and SI=254
2. SFF looks up the next service function, SF-2, in its forwarding
table. The forwarding entry also indicates an RO ES at this
location. SFF replicates the packet and sends a copy of the
packet including NSH to ES-1. The original packet is not
changed.
3. SFF sends the original packet to SF-2.
Wang & Leung Expires December 30, 2017 [Page 11]
Internet-Draft SFC Receive-only June 2017
5. SFC Control Plane
5.1. Receive-Only Service Function
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.
5.2. Receive-Only External Service
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.
Wang & Leung Expires December 30, 2017 [Page 12]
Internet-Draft SFC Receive-only June 2017
+-------------------+
| |
| 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
1. SFC Control Plane evaluates the RO ES policy and determines the
location(s) for SFF to perform packet replication and send
packets to RO ES.
2. SFC Control Plane uses C2 Control Plane-SFF interface
([I-D.ietf-sfc-control-plane]) to update the SFF forwarding table
with replication entries to RO ES.
6. SFC Element Considerations
6.1. Receive-Only Service Function
An RO SF MUST NOT send received packets back to the Extended SFC
Proxy.
Wang & Leung Expires December 30, 2017 [Page 13]
Internet-Draft SFC Receive-only June 2017
6.2. Extended SFC Proxy
The Extended SFC Proxy for an RO SF carries the following additional
capabilities compared with a regular SFC Proxy:
1. Packet replication
2. Preserving the SFC encapsulation in the copy of the packet when
the RO SF is SFC aware
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.
6.3. Receive-Only External Service
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.
6.4. Service Function Forwarder
6.4.1. Receive-Only Service Function
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.
6.4.2. Receive-Only External Service
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.
Wang & Leung Expires December 30, 2017 [Page 14]
Internet-Draft SFC Receive-only June 2017
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
6.4.3. SFF Capabilities Considerations
In order to support RO ES, implementation of an SFF SHOULD support
the following capabilities:
1. Packer replication
2. Discarding any packets returned by an RO ES
Additional capabilities for receive-only support include the
following:
1. Replicating a portion of the packet (e.g. headers only)
2. Filtering selected packets to be replicated to receive-only
service
3. Sending collective statistics in place of raw packet data
4. Producing Netflow/IPFIX and other events
Those capabilities are beyond the scope of this document.
Wang & Leung Expires December 30, 2017 [Page 15]
Internet-Draft SFC Receive-only June 2017
7. Security Considerations
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.
8. Acknowledgments
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.
9. IANA Considerations
This document includes no request to IANA.
10. References
10.1. Normative References
[I-D.ietf-sfc-control-plane]
Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", draft-ietf-sfc-control-
plane-08 (work in progress), October 2016.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), 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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
Wang & Leung Expires December 30, 2017 [Page 16]
Internet-Draft SFC Receive-only June 2017
10.2. Informative References
[I-D.wang-sfc-ns-use-cases]
Wang, E., Leung, K., Felix, J., and J. Iyer, "Service
Function Chaining Use Cases for Network Security", draft-
wang-sfc-ns-use-cases-02 (work in progress), October 2016.
Authors' Addresses
Eric Wang
Cisco Systems Inc.
170 W Tasman Dr
San Jose, CA 95134
U.S.A.
Email: ejwang@cisco.com
Kent Leung
Cisco Systems Inc.
170 W Tasman Dr
San Jose, CA 95134
U.S.A.
Email: kleung@cisco.com
Wang & Leung Expires December 30, 2017 [Page 17]
