[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
SFC Working Group                                        D. Migault, Ed.
Internet-Draft                                                  Ericsson
Intended status: Informational                              C. Pignataro
Expires: October 6, 2016                                        T. Reddy
                                                                   Cisco
                                                               C. Inacio
                                                            CERT/SEI/CMU
                                                           April 4, 2016


                 SFC environment Security requirements
             draft-mglt-sfc-security-environment-req-01.txt

Abstract

   This document provides environment security requirements for the SFC
   architecture.  Environment security requirements are independent of
   the protocols used for SFC - such as NSH for example.  As a result,
   the requirements provided in this document are intended to provide
   good security practices so SFC can be securely deployed and operated.
   These security requirements are designated as environment security
   requirements as opposed to the protocol security requirements.

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 October 6, 2016.

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



Migault, et al.          Expires October 6, 2016                [Page 1]


Internet-Draft    SFC environment Security requirements       April 2016


   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.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology and Acronyms  . . . . . . . . . . . . . . . . . .   3
   4.  SFC Environment Overview  . . . . . . . . . . . . . . . . . .   3
   5.  Threat Analysis . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Attacks performed from the SFC Control Plane  . . . . . .   5
     5.2.  Attacks performed from the SFC Management Plane . . . . .   6
     5.3.  Attacks performed from the Tenant's Users Plane . . . . .   6
     5.4.  Attacks performed from the SFC Data Plane . . . . . . . .   8
   6.  Security Requirements . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Plane Isolation Requirements  . . . . . . . . . . . . . .  12
       6.1.1.  SFC Control Plane Isolation . . . . . . . . . . . . .  13
       6.1.2.  SFC Management Plane Isolation  . . . . . . . . . . .  14
       6.1.3.  Tenant's Users Data Plane Isolation . . . . . . . . .  15
     6.2.  SFC Data Plane Requirements . . . . . . . . . . . . . . .  16
     6.3.  Additional Requirements . . . . . . . . . . . . . . . . .  19
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     11.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Requirements notation

   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 [RFC2119].

2.  Introduction

   This document provides environment security requirements for the SFC
   architecture [I-D.ietf-sfc-architecture].  Environment security
   requirements are independent of the protocols used for SFC - such as
   NSH [I-D.ietf-sfc-nsh].  As a result, the requirements provided in
   this document are intended to provide good security practice so SFC
   can be securely deployed and operated.  These security requirements



Migault, et al.          Expires October 6, 2016                [Page 2]


Internet-Draft    SFC environment Security requirements       April 2016


   are designated as environment security requirements as opposed to the
   protocol security requirements.  This document is built as follows.
   Section 4 provides an overall description of the SFC environment with
   the introduction of the different planes (SFC Control Plane, the SFC
   Management Plane, the Tenant's user Plane and the SFC Data Plane).
   Section 6 lists environment security requirements for the SFC.  These
   requirements are intended to prevent attacks, as well as network and
   SFC misconfigurations.  When such events happens, the security
   recommendations also aim at detecting and identifying the threats or
   misconfiguration as well as limiting their impact.  Recommendations
   also may apply differently depending on the infrastructure.  For
   example trusted environment may enforce lighter security
   recommendations than public and open SFC infrastructures.  However,
   one should also consider future evolution of their infrastructure,
   and consider the requirements as a way to maintain the SFC
   architecture stable during its complete life cycle.  For each
   requirement this document attempts to provide further guidance on the
   reasons to enforce it as well as what should be considered while
   enforcing it or the associated risks of not enforcing it.

   This document assumes the reader is familiar with the SFC
   architecture defined in [I-D.ietf-sfc-architecture].

3.  Terminology and Acronyms

   - Tenant:   A tenant is one organization that is using SFC.  A tenant
         may use SFC on one's own private infrastructure or on a shared
         infrastructure.

   - Tenant's User Data Plane:   The tenant may be using SFC to provide
         service to its customers or users.  The communication of these
         users is designated as Tenant's user Data Plane and includes
         all communications involving the tenant's users.  As a result,
         if a user is communicating with a server or a user from another
         domain, the communication with that tenant's user is part of
         the Tenant's Users Data Plane.

4.  SFC Environment Overview

   This section provides an overview of SFC.  It is not in the scope to
   this document to provide an explicit description of SFC.  Instead,
   the reader is expected to read [I-D.ietf-sfc-architecture],
   [I-D.ietf-sfc-control-plane] and other SFC related documents.

   Service Function Chaining (SFC) architecture is defined in
   [I-D.ietf-sfc-architecture].  This section briefly illustrates the
   main concepts of the SFC architecture and positions the architecture
   within an environment.



Migault, et al.          Expires October 6, 2016                [Page 3]


Internet-Draft    SFC environment Security requirements       April 2016


                       SFC Control Plane
                                            ^             ^    ^
   -------------------------|---------------|-------------|----|--------
               |         C1 |            C3 |          C2 |    | C4
               |            |            +-----+          |    |
               |            |            |  SF |          |    |
               |            |            +-----+          |    |
               |            v               |             |    |
               |       +------------+     +-----+      +-----+ |
               |    +->|    SFC     |---->| SFF |----->| SFF |------+
    SFC        |    |  | Classifier |<----|     |<-----|     | |    |
    Management |    |  +------------+     +-----+      +-----+ |    |
    Plane      |    |         ^                           |    |    |
               |    |         |                     +-----------+   |
               |    |         |                     | SFC Proxy |   |
               |    |         |                     +-----------+   |
               |    |         |                           |         |
               |    |         |                        +------+     |
               |    |         v                        |  SF  |     |
               |    |    +---------+                   +------+     |
               |    |    |  SFC 2  | <------------ SFC 1 ------->   |
               |    |    +---------+                                |
               |    |            SFC Data Plane                     |
   -----------------|-----------------------------------------------|--
       SFC incoming |                                  SFC outgoing |
       Data traffic |                                  Data traffic v

                         SFC Tenant's Users Data Plane

                         SFC Environment Overview

   SFC defined a Service Function Path (SFP) which is an ordered set of
   Service Functions (SF) applied to packets.  SFP is defined at the SF
   level.  A SF may be performed by different instances of SF located at
   different positions.  As a result, a specific packet may pass through
   different instances of SFC.  The ordered set of SF instances a packet
   goes through is called the Rendered SF Path (RSFP).

   Upon the receipt of an incoming packet from the tenant's user, the
   SFC Classifier determines, according to Classifiers, which SFP is
   associated to that packet.  The packet is forwarded from Service
   Function Forwarders (SFF) to SFF.  SFF are then in charge of
   forwarding the packet to the next SFF or to a SF.  Forwarding
   decisions may be performed using SFP information provided by the SFC
   Encapsulation.  As described in [I-D.ietf-sfc-nsh] the SFC
   Encapsulation contains SFP information such as the SFP ID and Service
   Index and eventually (especially for the MD-2 in NSH) some additional
   metadata.  SF may be SFC aware or not.  In the case the SFC functions



Migault, et al.          Expires October 6, 2016                [Page 4]


Internet-Draft    SFC environment Security requirements       April 2016


   are not SFC aware, a SFC Proxy performs the SFC Decapsulation (resp.
   SFC Encapsulation) before forwarding the packet to the SF (resp.
   after receiving the packet from the SF).

   The environment associated to SFC may be separated into three main
   planes:

   -     SFC Management Plane and Control Plane are defined in
         [I-D.ietf-sfc-control-plane].

   -     SFC Data Plane consists in all SF components as well as the
         data exchanged between the SF components.  Communications
         between SF components includes the packet themselves, their
         associated metadata, the routing logic - similar to RIB - or SF
         logic, i.e. what they retuned values are for example.

   -     SFC Tenant's Users Data Plane consists in the traffic data
         provided by the different users of the tenants.  When a user is
         communicating with a server or another user -eventually from
         another administrative domain - , the communication belongs to
         the SFC Tenant's Users Data Plane whenever packets are provided
         by the server of by the user.

5.  Threat Analysis

   This section describes potential threats the SFC Data Plane may be
   exposed.  The list of threats is not expected to be complete.  More
   especially, the threats mentioned are provided to illustrate some
   security requirements for the SFC architecture.  For simplicity, this
   document mostly considers that security breaches are performed by an
   attacker.  However, such breaches may also be non-intentional and may
   result from misconfiguration for example.

   Attacks may be performed from inside the SFC Data Plane or from
   outside the SFC Data plane, in which case, the attacker is in at
   least one of the following planes: SFC Control Plane, SFC Management
   Plane or SFC Tenants' Users Plane.  Some most sophisticated attacks
   may involve a coordination of attackers in multiple planes.

5.1.  Attacks performed from the SFC Control Plane

   Attacks related to the control plane have been detailed in section 5
   of [I-D.ietf-sfc-control-plane].








Migault, et al.          Expires October 6, 2016                [Page 5]


Internet-Draft    SFC environment Security requirements       April 2016


5.2.  Attacks performed from the SFC Management Plane

   Attacks performed on the SFC Management Plane are similar to those
   performed from the SFC Control Plane.  The main difference is that
   the SFC Management Plan provides usually a greater control of the SFC
   component that the SFC Control Plane.

   In addition, the actions performed by the SFC Management Plane have
   fewer restrictions, which means it may be harder to enforce strong
   control access policies.

5.3.  Attacks performed from the Tenant's Users Plane

   The SFC Tenant's User Plane is not expected to have fine access
   control policies on the packets sent or received by users.  Unless
   they are filtered, all packets are good candidate to the SFC
   Classifier.  This provides the user some opportunities to test the
   behavior of the SFC.

   In addition, the Tenant's Users Plane is not controlled by the SFC
   Tenant, and users may initiate communications where both ends - the
   client and the server- are under the control of the same user.  Such
   communications may be seen as user controlled communications (UCC).

   UCC may enable any user to monitor and measure the health of the SFC.
   This may be an useful information to infer information on the
   tenant's activity or to define when a DoS attack may cause more
   damage.  One way to measure the health or load of the tenant's SFC is
   to regularly send a packet and measure the time it takes to be
   received, in order to estimate the processing time within the SFC.

   UCC may enable any user to test the consistency of the SFC.  One
   example of inconsistency could be that SFC decapsulation is not
   performed - or inconsistently performed - before leaving the SFC,
   which could leak some metadata with private information.  For
   example, a user may send spoofed packet.  Suppose for example, that a
   request HTTP GET video.example.com/movie is received with some extra
   header information such as CLIENT_ID: 1234567890, or CLIENT_EMAIL:
   client@example.foo.  If these pieces of information are derived from
   the source IP address, the attacker may collect them by changing the
   IP address for example.  In this case, the spoofed packets as used to
   collect private and confidential information of the tenant's users.
   Note that such threat is not specific to SFC, and results from the
   combination of spoofed IP and non-authenticated IP address are used
   to identify a user.  What is specific to SFC is that metadata are
   likely to carry multiple pieces of information - potentially non-
   authenticated - associated to the user.  In the case above, meta-data
   is carried over the HTTP header.  Inserting the metadata in the HTTP



Migault, et al.          Expires October 6, 2016                [Page 6]


Internet-Draft    SFC environment Security requirements       April 2016


   header may be performed by a SF that takes its input from the SFC
   encapsulation.  In addition, SFC encapsulation may also leak this
   information directly to a malicious node if that node belongs to the
   SFC plane.  In this later case, the user builds on the top of and
   intrusion to the SFC Data Plane that is detailed later.

   In some case, spoofed packet may impersonate other's tenants.
   Suppose for example that the same infrastructure is used by multi
   tenants, and which are identified by the IP address of their users.
   In this case, spoofing an IP address associated to another tenant may
   be sufficient to collect the information confidential and private
   information.

   Similarly, UCC may enable any user to infer packet has been dropped
   or is in a loop.  Suppose a user send a spoofed packet and receives
   no response.  The attacker may infer that the packet has been dropped
   or is in a loop.  A loop is expect to load the system and sending a
   "well known packet" over the UCC and measuring the response time may
   determine whether the packet has been dropped or is in a loop.

   Correlation of time measurement and spoofed packet over a UCC may
   provide various type information that could be used by an attacker.

   -     The attacker may correlate spoofed packet and time measurement
         in order discover the SFC topology or the logic of the SFC
         Classifier.  Typically, it may infer when new SFs are placed in
         the SFC for example.  In addition, as metadata are placed in
         band, the time response may also provide an indication of the
         size of the metadata associated to the packet.  The combination
         of these pieces of information may help an attacker to
         orchestrate a future attack on a specific SF either to maximize
         the damages or to collect some metadata - like identification
         credentials.

   -     The attacker may also define the type of packets that require
         the SFC the more processing.  Additional processing may be due
         a large set of additional metadata that require fragmentation,
         some packets that are not treated in a coherent and consistent
         manner within the SFC.  Such information may be used for
         example to optimize a DoS attack.  In addition, it could also
         be used in order to artificially increase the necessary
         resource of the Tenant in order to increase the cost of
         operation for running its service.

   Time measurement and spoofed packet in combination with variable
   query rate over a UCC may provide information on the orchestration of
   the SFC itself.  For example, the user may be able to detect when
   elasticity mechanisms are triggered.



Migault, et al.          Expires October 6, 2016                [Page 7]


Internet-Draft    SFC environment Security requirements       April 2016


   An attacker may be able to leverage the knowledge that SFC is in use
   by specific carriers to effect the processing of data using the SFC
   system as a processor in the attack.  This leads to a number of
   potential weaknesses in the Internet ecosystem.

   An attacker may be able to characterize the type of client platforms
   using a web site by carefully crafting data streams that will be
   modified by the SFC system versus client systems that would view web
   data unmodified.  For example, leveraging SFC and carefully crafted
   data, a malicious web site operator may be able to create a
   particularly formatted common file that when modified by a cellular
   operator for bandwidth savings creates a file that may crash,
   (creating a DoS attack) on a select set of clients.  Clients not
   accessing that web site using the same RSFP would not experience any
   issues.  Additionally, external examination of the malicious site
   would not demonstrate any malicious content, relying on the SF to
   modify the content.

   A well crafted site could potentially leverage the variances of
   functionality from different RSFPs in order to GEO locate a user.  An
   example would be creating an image file which when recompressed
   creates image artifacts rendering the image unusable, but allowing
   the user to respond to such an event, thereby letting the web site
   operator know the user has potentially moved from a higher to lower
   bandwidth network location within the area of a specific network
   operator.

5.4.  Attacks performed from the SFC Data Plane

   This section considers an attacker has been able to take control of
   an SFC component.  As a result, the attacker may become able to
   modify the traffic and perform, on-path attacks, it may also be able
   to generate traffic, or redirect traffic to perform some kind of Man-
   in-the-middle attacks.  This is clearly a fault, and security
   policies should be set to avoid this situation.  This section
   analyses in case this intrusion occurs, the potential consequences on
   the SFC.  As mentioned earlier, this section assumes all these
   actions are performed by an attacker.  However, what is designated by
   an attack may also result from misconfigurations at various layer.  A
   SF or a SFF may become inadvertently configured or programed which
   may result in similar outcomes as an attack.  Whatever result in what
   we designate as an attack, the purpose of security requirements will
   be to detect, to analyse and mitigate such security breaches.

   The traffic within the SFC Data Plane is composed of multiple layers.
   The traffic is composed of communications between SFC components.
   The transport between the SFC component is the transport protocol and
   is not considered in the SFC.  It can typically be a L2 transport



Migault, et al.          Expires October 6, 2016                [Page 8]


Internet-Draft    SFC environment Security requirements       April 2016


   layer, or an L3 transport layer using various encapsulation
   techniques (vLAN, VxLAN, GRE, IPsec tunnels for example).  The
   transport layer carries SFC Encapsulated that are composed of an SFC
   Encapsulation envelope that carries metadata and a SFC payload that
   is the actual packet exchanged between the two end points.

   As a result, attacker may use the traffic to perform attacks at
   various layers.  More specifically, attacks may be performed at the
   transport layer, the SFC Encapsulation layer or the SFC payload
   layer.

   -     Attacks performed at the transport layer may be related to SFC
         in the sense that illegitimate SFC traffic could be provided to
         the SF.  Typically, a malicious node that is not expected to
         communicate with that SF may inject packets into the SFC, such
         malicious node may eventually spoof the IP address of
         legitimate SF, so the receiving SF may not be able to detect
         the packet is not legitimate.  Threats related to IP spoofing
         are described in [RFC6959] and may be addresses by
         authenticated traffic (e.g.  using IPsec).  Such threats are
         not related to SFC even though they may impact a given SF.

   -     the SFC Encapsulation as well as the SFC payload are usually
         considered as input by a SF.  As such they may represent
         efficient vector of attacks for the SF.  Attacks performed
         through SFC payload are similar as the ones described in the
         Tenant's Users Data Plane section.  As a result, such attacks
         are not considered in this section, and this section mostly
         considers attacks based on the SFC Encapsulation and malicious
         metadata.

   When an attacker is within the SFC Data Plane, it may have a full or
   partial control of one SF component in which case, the attacker is
   likely to compromise the associated SFCs.  It could for example,
   modify the expected operation of the SFC.  Note that in this case,
   the SFC may be appropriately provisioned and set, however, the SFC
   does not operate as expected this may only be detected by monitoring
   and auditing the SFC Data Plane.

   Although traffic authentication may be performed at various layers L2
   L3 or at the SFC Encapsulation layer, this section considers the SFC
   traffic.  As a result, the SFC traffic is authenticated if the SF is
   able to authenticate the incoming SFC packet.

   When SFC traffic is not authenticated, an attacker may inject spoofed
   packet in any SFC component.  The attacker may use spoofed packet to
   discover the logic of the SFC.  On the other hand, the attacker may
   also inject packet in order to perform DoS attack via reflection.  In



Migault, et al.          Expires October 6, 2016                [Page 9]


Internet-Draft    SFC environment Security requirements       April 2016


   fact, some SF may carry large metadata, which may provide a vector
   for amplification within the SFC Data Plane and thus either load the
   network or the next SF.  Note that amplification may be generated by
   metadata, the SFC payload, and the attacker may replay packets or
   completely craft new packets.  In addition, the attacker may choose a
   spoofed packet to increase the CPU load on the SFC components.  For
   example, it could insert additional metadata to generate
   fragmentation.  Similarly, it may also insert unnecessary metadata
   that may need to be decapsulated and analyzed even though they may
   not be considered for further actions.  Spoofed packet may not only
   be generated to attack the SFC component at the SFC layer.  In fact
   spoofed packet may also target applications of the SF.  For example
   an attacker may also forge packet for HTTP based application - like a
   L7 firewall - in order to perform a slowloris [SLOWLORIS] like
   attack.  Note that in this case, such attacks are addressed in the
   Tenant's Users Data Plane section.  The specificity here is that the
   attacker has a more advanced understanding of the processing of the
   SFC, and can thus be more efficient.

   When SFC traffic is not authenticated, an attacker may also modify
   on-path the packet.  By changing some metadata contained in the SFC
   Encapsulation, the attacker may test and discover the logic of the
   SFF.  Similarly, when the attacker is aware of the logic of a SFC
   component, the attacker may modify some metadata in order to modify
   the expected operation of the SFC.  Such example includes for example
   redirection to a SF which could result in overloading the SF and
   overall affect the complete SFC.  Similarly, the attacker may also
   create loops within the SFC.  Note that redirection may not occur
   only in a given SFC.  In fact, the attacker may use SFC branching to
   affect other SFC.  Another example would also include a redirection
   to a node owned by the attacker and which is completely outside the
   SFC.  Motivation for such redirection would be that the attacker has
   full administrator privileges on that node, whereas it only has
   limited capabilities on the corrupted node.  Such attack is a man-in-
   the-middle attack.  The important thing to note is that in this case
   the traffic is brought outside the legitimate SFC domain.  In fact,
   performing a man-in-the-middle attack as described above means that
   the SFC domain has been extended.  This can be easily performed in
   case all node of the data center or the tenant's virtual network is
   likely to host a SFC component.  A similar scenario may also consider
   that the traffic could be redirected outside the data center or the
   tenant's virtual network if the routing of firewall rule enables such
   policies.

   A direct consequence is that a corrupted SFC component may affect the
   whole SFC.  This also means that the trust of a given SFC decreases
   with the number of SF involved as each SF presents a surface of
   attack.



Migault, et al.          Expires October 6, 2016               [Page 10]


Internet-Draft    SFC environment Security requirements       April 2016


   An attacker may also perform passive attacks by listening to traffic
   exchanged throughout the SFC Data Plane.  Such attacks are described
   in [RFC7258].  Metadata are associated to each packet.  These
   metadata are additional pieces of information not carried in the
   packet and necessary for each SF to operate.  As a result, metadata
   may contain private information such as identifiers or credentials.
   In addition, observing the traffic may provide information on the
   tenant's activity.  Note that encryption only may not prevent such
   attacks, as activity may be inferred by the traffic load.

6.  Security Requirements

   This section aims at providing environment security requirements.
   These requirements are derived from the threat analysis provided in
   Section 5

   Although the security requirements are derived from described
   threats, the scope of security should be understood in a much broader
   way than addressing threats.  In fact the primary purpose of the
   security requirements is to ensure the SFC architecture can remain
   robust and stable.

   Protecting the SFC architecture from attacker is one goal of the
   security requirements.  Some could easily argue that such
   requirements are not needed for example in a private SFC deployment
   where SFC components may be considered in a trusted environment and
   administrated by a single entity.  However, even in a single
   administrative domain, inside attacks are possible.  (e.g. inside
   attacker sniffing the SFC metadata, sending spoofed packets etc.).
   Then, the trusted domain assumption may not remain valid over time.
   Suppose, for example, that the SFC architecture is now interconnected
   with some third party SF or SFF.  Such SFC component is now outside
   the initial trusted domain which has several security implications.
   Similarly, a single trusted domain with one tenant may evolve over
   time and become multitenants and share a SFC platform.  These
   tenants, may be trusted as in the case for example where each tenant
   represents a different department of a single company.
   Authentication is not sufficient, and relying only on a access
   control presents some risks.  If the tenants are not strongly
   isolated - with physical or logical networks isolation, they may
   share a common SFF and one tenant may update the SFP of the other
   tenant.  Such misconfiguration has similar impact as a redirecting
   attack.  This document provide guidance that result in limiting such
   risks and improve detection for further mitigation.

   As a result, the goal of this document is to provide some security
   requirements that should be checked against any evolution of the SFC
   architecture.  The requirements should be understand and the risks of



Migault, et al.          Expires October 6, 2016               [Page 11]


Internet-Draft    SFC environment Security requirements       April 2016


   not following them should be evaluated with the current deployment as
   well as the foreseen evolutions.

   Similarly, the document provides means to evaluate the consequences
   of a security breach, as well as means to detect them.

   The motivations for the security requirements are:

   a)  Preventing attacks

   b)  Preventing misconfigurations - as far as stability and security
       of the SFC architecture is concerned.

   c)  Providing means to evaluate the consequences of a security breach

   d)  Making possible to audit, and detect any misbehavior that may
       affect stability and security of the SFC.

6.1.  Plane Isolation Requirements

   Plane Isolation consists in limiting the surface of attack of the SFC
   Data Plane by controlling the interfaces between the SFC Data Plane
   and the other planes.

   Complete isolation of the planes is not possible, as there are still
   some communications that must be enabled in order to benefit from the
   benefits of SFC.  As a result, isolation should be understood as
   enabling communications between planes in a controlled way.

   This section lists the recommendations so communication between
   planes can be controlled.  This involves controlling communications
   between planes as well as controlling communication within a plane.

   The requirements listed below applies to all planes, whereas the
   following subsection are more specific to each plane, providing
   recommendations on the interface with the SFC Data Plane.

   REQ1:  In order to increase isolation every plane that communicates
          with another plane SHOULD use a dedicated interface.  In our
          case, the SFC Management Plane, the SFC Control Plane and the
          SFC Data Plane SHOULD use dedicated networks and dedicated
          interfaces.  Isolation of inter-plane communication may be
          enforced using different ways.  How isolation is enforced
          depends on the type of traffic, the network environment for
          example, and within a given SFC architecture different
          techniques may be used for the different planes.  One way to
          isolate communications is to use completely different network
          on dedicated NICS.  On the other hand, depending on the



Migault, et al.          Expires October 6, 2016               [Page 12]


Internet-Draft    SFC environment Security requirements       April 2016


          required level of isolation, a logical isolation may be
          performed using different IP addresses or ports with network
          logically isolated - that is using for example different
          VxLAN, or GRE tunnels.  In this case, isolation relies on the
          trust associated to the different switches and router.  In
          case of a lake of trust on the on-path elements, authenticated
          encryption may be used to provide a logical isolation.  With
          authenticated encryption, trust is placed on the end points.
          Note also that encryption can also be used in combination of
          other isolation mechanisms in order to increase the level of
          isolation.

   REQ2:  Activity on each interface between planes SHOULD be monitored
          and regularly audited.

   REQ3:  Each interface between planes SHOULD be provided means to
          filter traffic or rate-limit the traffic.  Filtering and rate-
          limiting policies may be finer grained and may apply for a
          subset of traffic.

   The above requirements mostly corresponds to the architecture best
   current practice.  Isolation is mostly motivated to avoid the planes
   to interact on each other.  For example the load on the SFC Data
   Plane should not affect the SFC Control Plane and SFC Management
   Plane communications.  The purpose of the encryption is to prevent
   the communication to be visible outside the SFC components involved
   and to be authenticated.

   The two remaining requirements provides means to be informed and to
   to protect the planes at their boundaries.  Such requirements are
   also current best practices.

   Such recommendations are thus strongly recommended even in the case
   the two planes are considered to belong to trusted environments.

6.1.1.  SFC Control Plane Isolation

   In order to limit the risks of an attack from the SFC Control Plane,
   effort should be made in order to restrict the capabilities and the
   information provided by the SFC Data Plane to the SFC Control Plane
   to the authorized tenants only.  In this case the authorized tenants
   are the users or organizations responsible for the SFC domain.

   REQ4:  Tenants of the SFC Control Plane SHOULD authenticate in order
          to prevent tenant's usurpation or communication hijacking.

   REQ5:  Communications between SFC Control Plane and the SFC Data
          Plane MUST be authenticated and encrypted in order to preserve



Migault, et al.          Expires October 6, 2016               [Page 13]


Internet-Draft    SFC environment Security requirements       April 2016


          privacy.  The purpose of encryption in this case prevents an
          attacker to be aware of the action performed by the SFC
          Control Plane.  Such information may be used to orchestrate an
          attack - especially when SFC component report their CPU/
          network load.

   REQ6:  Strong access control policies SHOULD be enforced.  Control
          SHOULD be performed on the engaged resource (e.g.  CPU,
          memory, disk access for example) and SHOULD be associated
          explicitly to authorized tenants.  By default, a tenant SHOULD
          be denied any access to resource, and access SHOULD be
          explicit.

   Given the SFC Control Plane traffic load that is expected to be light
   - at least compared to the SFC Tenant's Users Data Plane or the SFC
   Data Plane.  As a result, encryption is not expect to impact the
   performances of the SFC architecture.  Given the effort to migrate
   from an non authenticated (and non protected) communications to a
   protected communication, we recommend these requirements to be
   considered even in trusted environments.

   Access Control policies can be enforced in various ways.  One way
   could be to consider the systems of the SF to limit the resources
   associated to each tenants.  Other ways include the use of API in
   order to limit the scope of possible interactions between the SFC
   Control Plane and the SFC Data Plane.  This is one way to limit the
   possibilities of the tenants.  In addition, each of these actions
   should be associated an authorized tenant, as well as authorized
   parameters.  The use of API belongs to best practices and so is
   strongly recommended even in trusted environments.

   REQ7:  Audit SHOULD be performed regularly to check access control
          policies are still up-to-date and prevent non-authorized users
          to control the SFC Data Plane.

   The purpose of audits is to provide evidences when something went
   wrong.  As a result, audit facilities are expected to be provided
   even in trusted environments.

6.1.2.  SFC Management Plane Isolation

   The requirements for the SFC Control Plane and SFC Management Plane
   are similar.  The main difference of the interfaces between the SFC
   Management Plane and the SFC Control Plane is that it is less likely
   that APIs could be used to configure the different SFC components.
   As a result, users of the SFC Management Plane are likely to have a
   broader and wider control over the SFC component.




Migault, et al.          Expires October 6, 2016               [Page 14]


Internet-Draft    SFC environment Security requirements       April 2016


   REQ8:  it is RECOMMENDED to enforce stronger authentication
          mechanisms (for example relying on hardware tokens or keys)
          and to limit the scope of administrative roles on a per
          component basis.

   REQ9:  SFC Control Plane and SFC Management Plane may present some
          overlap.  Each SFC component MUST have clear policies in case
          these two planes enter in conflict.

6.1.3.  Tenant's Users Data Plane Isolation

   The Tenant's Users Data Plane is supposed to have less restricted
   access control than the other SFC Management Plane and SFC Control
   Planes.  A typical use case could be that each tenant are controlling
   and managing the SFC in order to provide services to their associated
   users.  The number of users interacting with the SFC Data Plane is
   expected to be larger than the number of tenants interacting with the
   SFC Control and SFC Management Planes.  In addition, the scope of
   communications initiated or terminating at the user end points is
   likely to be unlimited compared to the scope of communications
   between the tenants and the SFC Control Plane or SFC Management
   Plane.  In such cases, the tenant may be provided two roles.  One to
   grant access to the SFC, and another one to control and manage the
   SFC.  These two roles should be able to interact and communicate.

   REQ10: Users SHOULD be authenticated, and only being granted access
          to the SFC if authorized.  Authorization may be provided by
          the SFC itself or outside the SFC.

   REQ11: Filtering policies SHOULD prevent access to a user, or traffic
          when a malicious behavior is noticed.  A malicious activity
          may be noticed once a given behavioral pattern is detected or
          when unexpected load is monitored in the SFC Data Plane.

   REQ12: Tenant's User Plane SHOULD be monitored, in order to detect
          malicious behaviors.

   REQ13: When SFC is used by multiple tenants, each tenant's traffic
          SHOULD be isolated based on authenticated information.  More
          specifically, the use of a Classifier that can easily be
          spoofed like an IP address SHOULD NOT be used.

   It is RECOMMENDED that user's access authorization be performed
   outside the SFC.  In fact granting access and treating the traffic
   are two different functions, and we RECOMMEND they remain separated.
   Then, splitting these two functions makes it possible for a tester to
   perform tests of an potential attacker, without any contextual
   information.  More specifically, having a traffic identified as



Migault, et al.          Expires October 6, 2016               [Page 15]


Internet-Draft    SFC environment Security requirements       April 2016


   associated to test by the SFC reduces the scope of the tests simply
   because an attacker will not be considered as a tester.  For that
   reason, we RECOMMEND authorization is performed outside the SFC, and
   SFC deployment may not be designed to authenticate end users.

   The remaining requirements are associated to monitoring the network
   and providing interactions between the access and the SFC.  This
   interaction may be provided outside SFC itself.

6.2.  SFC Data Plane Requirements

   This section provides requirements and recommendation for the SFC
   Data Plane.

   REQ14: Communications within the SFC Data Plane SHOULD be
          authenticated in order to prevent the traffic to be modified
          by an attacker.  As a result, authentication includes the SFC
          Encapsulation as well as the SFC payload.

   REQ15: Communication MUST NOT reveal privacy sensitive metadata.

   REQ16: The metadata provided in the communication MUST be limited in
          in term of volume as to limit the amplification factor as well
          as fragmentation.

   REQ17: Metadata SHOULD NOT be considered by the SFF for forwarding
          decision.  In fact, the inputs considered for switching the
          packet to the next SFF or a SF should involve a minimum
          processing operation to be read.  More specifically, these
          inputs are expected fixed length value fields in the SFC
          Encapsulation header rather than any TLV format.

   REQ18: When multiple tenants share a given infrastructure, the
          traffic associated to each tenant MUST be authenticated and
          respective Tenant's Users Planes MUST remain isolated.  More
          specifically, if for example, a SFC Classifier is shared
          between multiple tenants.  The Classifier used to associate
          the SFC MUST be authenticated.  This is to limit the use of
          spoofed Classifiers.  In any case, the SFC component that
          receives traffic from multiple tenants is assumed to be
          trusted.

   REQ19: Being a member of a SFC domain SHOULD be explicitly mentioned
          by the node and means should be provided so the SFC domain the
          node belongs to may be checked.  Such requirement intends to
          prevent a packet to go outside a SFC domain, for example in
          the case of a man-in-the-middle attacks, where a redirection
          occurs outside the SFC domain.  It is expected that most



Migault, et al.          Expires October 6, 2016               [Page 16]


Internet-Draft    SFC environment Security requirements       April 2016


          deployment will rely on border / port mechanisms that prevent
          outsider users from injecting packets with spoofed metadata.
          Although such mechanisms are strongly recommended to deploy,
          in case of failure, they do not prevent man-in-the-middle
          attack outside the SFC domain.

   Authentication of the traffic within the SFC Data Plane is
   particularly recommended in an open environment where third party SF
   or SFF are involved.  It can also be recommended when a strong
   isolation of the traffic is crucial for the infrastructure or to meet
   some level of certification.  In addition, authentication may also be
   performed using various techniques.  The whole packet may be
   authenticated or limited to some parts (like the flow ID).
   Authenticating the traffic and how or what to authenticate is a trade
   off between the risk associated and the cost of encryption.  When
   possible we recommend to authenticate, but we also consider that the
   price may be too high in controlled and small trusted environment.

   Metadata is an important part of the SFC architecture, and their
   impact on security should be closely evaluated.  It is the
   responsibility of the SFC administrator to evaluate the privacy
   associated by the metadata - section 5.2.2 of [RFC6973] - and
   according to this evaluation to consider appropriated mechanisms to
   prevent the privacy leakage.  Mechanisms should be provided even
   though they may not be activated.

   As a general guidance exposing privacy sensitive metadata in any
   communications between two any SFC component should be avoided.  [One
   way, for example to avoid exposing privacy sensitive metadata is to
   include a reference to the metadata instead of the metadata itself.
   Another way could be to encrypt the metadata itself - but that is
   part of the solution space.]  Applying this principle prevents any
   private oriented data to be leaked.  This requirement is mandatory
   when the SFC is not deployed in a trusted environment.

   When exposition of the privacy sensitive metadata cannot be avoided
   and you are in a trusted domain, then exposing privacy sensitive
   metadata may be considered as long as they do not leak outside the
   boundaries of the trusted environment.  In this case, the security is
   delegated to the security policies of the trusted environment
   boundaries, that may be outside the scope of SFC.  More especially,
   the security policies may be for example enforced by a firewall.  In
   this specific case, the trusted environment MUST prevent leakage of
   the metadata out of the trusted environment and MUST ensure that
   untrusted node cannot access in any way the communications within the
   trusted environment.





Migault, et al.          Expires October 6, 2016               [Page 17]


Internet-Draft    SFC environment Security requirements       April 2016


   The reason this requirement is set to MUST is to specify that if one
   does not follow the requirement it is at its your own risk and must
   provide the necessary means to prevent any leak - in our case
   enforcing the necessary security policies that your environment /
   deployment needs.

   Similarly, it is the responsibility of the administrator to define
   what an acceptable size for metadata is.  Even in trusted
   environment, we recommend the SFC administrator be able to define and
   change this level.

   Processing metadata by the SFF seems also expensive, and it is the
   responsibility of the SFC administrator to evaluate whether
   processing metadata by the SFF may impact the SFC architecture.  In
   addition, metadata are expected to be associated to SF as opposed to
   the forwarding information that are associated to the SFF.  These
   inputs have different functions, are associated to different
   processing rules, and may be administrated by different parties.  It
   is thus part of the general good practise to split these
   functionalities.  Optimization may require to combine the analysis of
   metadata and forwarding information, but this should be handled
   cautiously.

   Assertion of belonging to a security domain, is especially
   recommended in open environments.  This may also partly be addressed
   by node authenticating.

   In addition, the following operational requirements have been
   identified:

   REQ20: SFC components SHOULD be uniquely identified and have their
          own cryptographic material.  In other words the use of a
          shared secret for all nodes SHOULD NOT be considered as one
          corrupted node would be able to impersonate any node of the
          SFC Data Plane.  This is especially useful for audit.

   REQ21: Activity in the SFC Data Plane MUST be monitored and audited
          regularly.  Audit and log analysis is especially useful to
          check that SFC architecture assessments.  They can be useful
          to detect a security breach for example before it is being
          discovered and exploited by a malicious user.  Monitoring the
          system is also complementary in order to provide alarms when a
          suspicious activity is detected.  Monitoring enables the
          system to react to unexpected behaviors in a dynamic way.
          Both activities are complementary as monitoring enables to
          counter suspicious behavior and audit may detect
          misconfiguration or deep causes of a malicious behavior.  For




Migault, et al.          Expires October 6, 2016               [Page 18]


Internet-Draft    SFC environment Security requirements       April 2016


          these reasons, audit and monitoring facilities are expected
          even in trusted environment.

   REQ22: Isolate the Plane with border and firewall to restrict access
          of SFC components to legitimate traffic.  More specifically,
          SFC components are supposed to be accessed only via dedicated
          interfaces.  Outside these interfaces, inbound or outbound
          traffic SHOULD be rejected.

6.3.  Additional Requirements

   REQ23: SFC Encapsulation SHOULD carry some identification so it can
          be associated to the appropriated SFP as well as its position
          within the SFC or SFP.  Indicating the SFP ID may be
          sufficient as long as a SFP can uniquely be associated to a
          single SFC.  Otherwise, the SFC should be also somehow
          indicated.  This is especially useful for audit and to avoid
          traffic coming from one SFC to mix with another SFC.
          Authentication of the SFP ID is one way to enforce SFP ID
          uniqueness.  This may not be mandatory, but large deployment
          or deployment that are involving multiple parties are expected
          enforce this.  In fact assuming SFP ID will have no collision
          is an hypothesis that may be hard to fulfill over time.

   REQ24: It is RECOMMENDED that SFF and SF keep separate roles.  SFF
          should be focused on SF forwarding.  As a result, they are
          expected to access a limited information from the packet -
          mostly fixed size information.  SF on the other hand are
          service oriented, and are likely to access all SFC information
          which includes metadata for example.  The reasons to keep
          these functions are clearly different and may involve
          different entities.  For example, SF management or SF
          configuration may involve different administrators as those
          orchestrating the SFC.

   REQ25: SFC Encapsulation SHOULD be integrity protected to prevent
          attackers from modifying the SFP ID.  See Data Plane
          communication Requirements and considerations)

7.  Security Considerations

8.  Privacy Considerations

9.  IANA Considerations







Migault, et al.          Expires October 6, 2016               [Page 19]


Internet-Draft    SFC environment Security requirements       April 2016


10.  Acknowledgments

   The authors would like to thank Joel Halpern, Mohamed Boucadair and
   Linda Dunbar for their valuable comments.

11.  References

11.1.  Normative References

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

   [RFC6959]  McPherson, D., Baker, F., and J. Halpern, "Source Address
              Validation Improvement (SAVI) Threat Scope", RFC 6959,
              DOI 10.17487/RFC6959, May 2013,
              <http://www.rfc-editor.org/info/rfc6959>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <http://www.rfc-editor.org/info/rfc6973>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <http://www.rfc-editor.org/info/rfc7258>.

11.2.  Informative References

   [I-D.ietf-sfc-nsh]
              Quinn, P. and U. Elzur, "Network Service Header", draft-
              ietf-sfc-nsh-01 (work in progress), July 2015.

   [I-D.ietf-sfc-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-11 (work
              in progress), July 2015.

   [I-D.ietf-sfc-control-plane]
              Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
              Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A.,
              Halpern, J., Reddy, T., and P. Patil, "Service Function
              Chaining (SFC) Control Plane Components & Requirements",
              draft-ietf-sfc-control-plane-00 (work in progress), August
              2015.




Migault, et al.          Expires October 6, 2016               [Page 20]


Internet-Draft    SFC environment Security requirements       April 2016


   [SLOWLORIS]
              Wikipedia, "Slowloris", <https://en.wikipedia.org/wiki/
              Slowloris_%28software%29>.

Authors' Addresses

   Daniel Migault (editor)
   Ericsson
   8400 boulevard Decarie
   Montreal, QC   H4P 2N2
   Canada

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com


   Carlos Pignataro
   Cisco Systems, Inc.
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   USA

   Phone: +1 919-392-7428
   Email: cpignata@cisco.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Bangalore, Karnataka  560103
   India

   Phone: +91 9886
   Email: tireddy@cisco.com


   Christopher Inacio
   CERT, Software Engineering Institute, Carnegie Mellon University
   4500 5th Ave
   Pittsburgh, PA  15213
   USA

   Phone: +1 412-268-3098
   Email: inacio@cert.org







Migault, et al.          Expires October 6, 2016               [Page 21]