Service Function Chaining E. Wang
Internet-Draft K. Leung
Intended status: Informational Cisco Systems Inc.
Expires: April 28, 2017 October 25, 2016

Receive-Only Service Function and External Service in SFC
draft-wang-sfc-receive-only-01

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 April 28, 2017.

Copyright Notice

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.


Table of Contents

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.

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 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

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.

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:

  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
  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.

             +-------+                            +-------+
             |       |                            |       |
             | [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:

  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.

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.

  +-------------------+  
  |                   |  
  | 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.

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.

       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.

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", 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-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.

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", Internet-Draft draft-wang-sfc-ns-use-cases-01, March 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