SFC Working Group D. Migault, Ed.
Internet-Draft Ericsson
Intended status: Informational C. Pignataro
Expires: May 1, 2017 T. Reddy
Cisco
C. Inacio
CERT/SEI/CMU
October 28, 2016
SFC environment Security requirements
draft-mglt-sfc-security-environment-req-02.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 May 1, 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
Migault, et al. Expires May 1, 2017 [Page 1]
Internet-Draft SFC environment Security requirements October 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
4.1. Deployment of SFC Architecture . . . . . . . . . . . . . 6
5. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Attacks performed from the SFC Control Plane . . . . . . 8
5.2. Attacks performed from the SFC Management Plane . . . . . 9
5.3. Attacks performed from the Tenant's Users Plane . . . . . 9
5.4. Attacks performed from the SFC Data Plane . . . . . . . . 11
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 14
6.1. Plane Isolation Requirements . . . . . . . . . . . . . . 15
6.1.1. SFC Control Plane Isolation . . . . . . . . . . . . . 16
6.1.2. SFC Management Plane Isolation . . . . . . . . . . . 17
6.1.3. Tenant's Users Data Plane Isolation . . . . . . . . . 18
6.2. SFC Data Plane Requirements . . . . . . . . . . . . . . . 19
6.3. Additional Requirements . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
Migault, et al. Expires May 1, 2017 [Page 2]
Internet-Draft SFC environment Security requirements October 2016
can be securely deployed and operated. These security requirements
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] as well as the
Internet Security Glossary [RFC4949]
3. Terminology and Acronyms
In addition to the terminology defined in
[I-D.ietf-sfc-architecture], the document defines the following
terminology:
- 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 [RFC7498],
Migault, et al. Expires May 1, 2017 [Page 3]
Internet-Draft SFC environment Security requirements October 2016
[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.
SFC Control Plane
^ ^ ^
-------------------------|---------------|-------------|----|--------
| C1 | C3 | C2 | | C4
| | +-----+ | |
| | |SF_a | | |
| | +-----+ | |
| v | | |
| +------------+ +-----+ +-----+ |
| +->| SFC |---->| SFF |----->| SFF |------+
SFC | | | Classifier |<----| |<-----| | | |
Management | | +------------+ +-----+ +-----+ | |
Plane | | ^ | | |
| | | +-----------+ |
| | | | SFC Proxy | |
| | | +-----------+ |
| | | | |
| | | +------+ |
| | v | SF_b | |
| | +---------+ +------+ |
| | | SFP 2 | <------------ SFP 1 -------> |
| | +---------+ |
| | SFC Data Plane |
-----------------|-----------------------------------------------|--
SFC incoming | SFC outgoing |
Data traffic | Data traffic v
SFC Tenant's Users Data Plane
Figure 1: SFC Environment Overview
SFC defined a Service Function Path (SFP) which is an ordered set of
Service Functions (SF) applied to part of the packets. The figure
above represents two SFP: SFP1 and SFP2. SFP2 is not detailled but
SFP1 defines a path that goes through SF_a and SF_b. SFP is defined
at the SF level, which means the path does not consider the specific
instance of an SF for example. 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
Migault, et al. Expires May 1, 2017 [Page 4]
Internet-Draft SFC environment Security requirements October 2016
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
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 the four main
planes:
- SFC Management Plane and Control Plane are defined in
[I-D.ietf-sfc-control-plane]. The SFC MAnagement Plane can be
assimilated to the cloud infrastructure provider allocating
various resource to the various SF and eventually active the
various SF components. Typically management operations would
consist in setting the number of CPU, memory bandwidth
associated to the various SFs as well as specific configuration
parameters of the SFC components. It is expected that the
interface between the various SFC components configuration will
be vendor specific. These configurations may be provided by
the Cloud infrastructure provider or in the case of
multitenancy by the administrator of the virtual network, or by
each administrator of the SFC components. The SFC control
plane controls and configure the SFC related components. The
Control Plane differs from the Management Plane as it only
concerns a subset of the parameters and facilities associated
to the SF. In general, these parameters are expected to only
modify the internal states of the different elements. This
aspect confers programmability properties to the Control Plane
that are usually not provide to the Management Plane. It is
also expected that the SFP are elaborated in this plane before
being pushed into the SFC Data Plane, and more generally, the
SFP state in the SFF is expected to come from control rather
than management.
- 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
Migault, et al. Expires May 1, 2017 [Page 5]
Internet-Draft SFC environment Security requirements October 2016
associated metadata, the routing logic - similar to RIB - or SF
logic, i.e. what they retuned values are for example. In other
words, the SFC Data Plane can also be seen as all the elements
that interact with a packet provided by an end user. Of course
the end user is not expected to configure any of these element
through the SFC Data Plane. Instead it is expected to apply
the policies and configurations put in place by the SFC Tenant.
- 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.
4.1. Deployment of SFC Architecture
This section illustrates a deployment of SFC we consider in this
document.
A Cloud Provider provides an infrastructure that is shared by
multiple SFC Tenants. The Cloud Provider may also provide some
servers or hardware that have a dedicated function. Such hardware
may be provided to the SFC Tenants under the form of a SF. It may
thus be shared by multiple SFC Tenants. Such SF are designated as
third party SF. Another case of SF may also consider a local SF
proxying the traffic to a remote site or domain. The SF proxy
transparently to the SFC elements may forward the traffic out of the
boundaries of the Tenant. In some case this may be needed, but in
some other case this may be done unbeknownst to the Tenant's.
Each SFC Tenant is responsible of its domain, that is to administrate
or provision the necessary resource and control all its SFC elements
which include defining SFC Paths, configuring the elements...
Typically the coordination of the SFC elements is likely to be
performed by a SDN controller.
Protecting the deployed 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.
Migault, et al. Expires May 1, 2017 [Page 6]
Internet-Draft SFC environment Security requirements October 2016
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.
5. Threat Analysis
The SFC environment is composed of the following plans: SFC
Management Plane, SFC Control Plane, SFC Data Plane and SFC Tenant's
User Data Plane. The purpose of these planes is to group a given set
of functions while limiting the interactions between these planes.
Interactions between planes are only limited - in most cases
controlled - but these interactions still exist and so may be used by
an attcker. As a result, for each plane, the threat analysis is
performed by analysis the vulnerabilities present within each plane
as well as those performed via the other planes.
Threat analysis of the Management Plane and the Control Plane have
been described in [I-D.ietf-sfc-control-plane]. The SFC Tenant's
User Plane is out of the boundaries of the SFC administrator. As a
result attacks performed on SFC Tenant's User Plan are not considered
in this section and this section limits its analysis on teh SFC Data
Plan.
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.
Migault, et al. Expires May 1, 2017 [Page 7]
Internet-Draft SFC environment Security requirements October 2016
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].
The different interfaces between the SFC Control Plane and the SFC
Data Plane are exposed in [draft-ietf-sfc-control-plane]. It
includes:
- Updating the classification rule of the SFC Classifier (also
referred as interface C1).
- Updating the forwarding decision of the SFF (also refereed as
interface C2). This interface is also used to provide the SFC
Control Plane some information for example on the system load,
network load or the latency so appropriated SFP may be
computed.
- Updating SF's internal states (interface C3). This interface
is also used to provide the SFC Control Plane some information
for example on the system load, network load or the latency so
appropriated SFP may be computed.
- Updating SFC Proxy's internal states (interface C4). This
interface is also used to provide the SFC Control Plane some
information for example on the system load, network load or the
latency so appropriated SFP may be computed.
An attacker may change the SFC Classifier classification and
completely modify the services provided by the SFC. Such privileges
may be used to avoid some control over the tenant's traffic (like
firewalling service). An attacker may also modify the filtering or
classification rules to overload heavy processing functions with
traffic. In a pay-what-you-use model, this could result in extra
cost for the tenant or to trigger a DoS attack on the tenant SFC Data
Plane.
Attack performed on the SFC Control Plane mostly consists in tenant
impersonation or communication hijacking. This would enable an
attacker to control the SFC components associated to the tenant.
Similarly an attacker may also collect system or network load
information in order to better orchestrate a DoS attack for example.
An attacker may also inject instructions in order to perform a DoS
attack on a given SFC component or to prevent the tenant to control
other SFC components.
Migault, et al. Expires May 1, 2017 [Page 8]
Internet-Draft SFC environment Security requirements October 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 May 1, 2017 [Page 9]
Internet-Draft SFC environment Security requirements October 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. The best current practice to prevent such leaks are
usually ingress filtering for example, which prevents unlegitimate
flows to enter the network. Note that ingress filtering may also be
performed at higher layers such as at application layers to prevent
unexpected applications to enter the network. When possible, the
cost needs to be balanced with the risk by the SFC tenants.
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.
Migault, et al. Expires May 1, 2017 [Page 10]
Internet-Draft SFC environment Security requirements October 2016
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. Such attack is not SFC
specific, and may have occured with traditional cloud mechanisms.
However, the main difference between SFC and traditional cloud
mechanisms is that SFC is a standard way to interconnect SF. In that
sense, the use of SFC provides more details to the attack as non
standard mechanisms.
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
Migault, et al. Expires May 1, 2017 [Page 11]
Internet-Draft SFC environment Security requirements October 2016
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
layer, or an L3 transport layer using various encapsulation
techniques (vLAN, VxLAN, GRE, IPsec tunnels for example). Each of
these transport layer adds or remove attack vectors. 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
Migault, et al. Expires May 1, 2017 [Page 12]
Internet-Draft SFC environment Security requirements October 2016
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
fact, as NSH provides the ability to add metadata, some deployment
may end up with payloads carrying large metadata. Addition of such
overhead presents 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-
Migault, et al. Expires May 1, 2017 [Page 13]
Internet-Draft SFC environment Security requirements October 2016
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.
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 generalization of the threat
analysis described in Section 5. More specifically, the threat
analysis section was mostly illustrative, and its generalization
leads us to the following requirements.
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 deployment of the SFC
architecture can remain robust and stable.
The goal of this section is to provide some security requirements
that should be checked against any evolution of the deployment of SFC
architecture. The requirements should be understood and the risks of
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.
Migault, et al. Expires May 1, 2017 [Page 14]
Internet-Draft SFC environment Security requirements October 2016
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. Typically the SFC Control Plane configures the SFC
elements used by the SFC Data Plane. Similarly, access to the SFC
Control Plane may be performed remotely, in which case interaction
between the SFC Tenant's User and the SFC Control Plane may be
considered. 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
required level of isolation, a logical isolation may be
performed using different IP addresses or ports with network
Migault, et al. Expires May 1, 2017 [Page 15]
Internet-Draft SFC environment Security requirements October 2016
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 between planes SHOULD be monitored and regularly
audited. At least operations performed between the planes as
well as the source and destination should be logged. When
possible the identity of the identities shoudl also be logged.
Activity may be performed indepedently by the different planes
as well as by different actors such as the SFC Tenants, te
infrastructure provider. The level of information available
may also differ between planes and actors.
REQ3: Traffic and communications between planes SHOULD be filtered
traffic or rate-limited. 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. 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
privacy. The purpose of encryption in this case prevents an
attacker to be aware of the action performed by the SFC
Migault, et al. Expires May 1, 2017 [Page 16]
Internet-Draft SFC environment Security requirements October 2016
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. By protecting these
communications by design, the deployed SFC architecture is also ready
for future expansion of the Control Plane outside the initial trusted
domain. This coudl typically includes the evoluation to multiple
tenants as well as the inclusion of tenants that remotely access the
SFC Control Plane.
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.
Migault, et al. Expires May 1, 2017 [Page 17]
Internet-Draft SFC environment Security requirements October 2016
As a result, users of the SFC Management Plane are likely to have a
broader and wider control over the SFC component.
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.
REQ14: 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
Migault, et al. Expires May 1, 2017 [Page 18]
Internet-Draft SFC environment Security requirements October 2016
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 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.
REQ15: Communications within the SFC Data Plane SHOULD be
authenticated in order to prevent the traffic to be modified
or injected by an attacker. As a result, authentication
includes the SFC Encapsulation as well as the SFC payload.
REQ16: Communication MUST NOT reveal privacy sensitive metadata.
REQ17: The metadata provided in the communication MUST be limited in
in term of volume as to limit the amplification factor as well
as fragmentation.
REQ18: 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.
REQ19: 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.
Migault, et al. Expires May 1, 2017 [Page 19]
Internet-Draft SFC environment Security requirements October 2016
REQ20: 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
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
Migault, et al. Expires May 1, 2017 [Page 20]
Internet-Draft SFC environment Security requirements October 2016
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.
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:
REQ21: 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.
REQ22: 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
Migault, et al. Expires May 1, 2017 [Page 21]
Internet-Draft SFC environment Security requirements October 2016
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
these reasons, audit and monitoring facilities are expected
even in trusted environment.
REQ23: 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
REQ24: 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.
REQ25: Although this requirement is implementation specific, 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.
REQ26: SFC Encapsulation SHOULD be integrity protected to prevent
attackers from modifying the SFP ID. See Data Plane
communication Requirements and considerations)
7. Security Considerations
Migault, et al. Expires May 1, 2017 [Page 22]
Internet-Draft SFC environment Security requirements October 2016
8. Privacy Considerations
9. IANA Considerations
10. Acknowledgments
The authors would like to thank Joel Halpern, Mohamed Boucadair and
Linda Dunbar for their valuable comments. Similarly the authors
would also like to thank Martin Stiemerling for its careful review as
well as its recommendations.
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>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[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>.
[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>.
Migault, et al. Expires May 1, 2017 [Page 23]
Internet-Draft SFC environment Security requirements October 2016
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.
[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
Migault, et al. Expires May 1, 2017 [Page 24]
Internet-Draft SFC environment Security requirements October 2016
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 May 1, 2017 [Page 25]