Internet DRAFT - draft-vu-sfc-sf-access-control
draft-vu-sfc-sf-access-control
Service Function Chaining Vu Anh Vu
Internet-Draft Younghan Kim
Intended status: Informational Kyoungjae Sun
Expires: January 4, 2018 Van-Ca Nguyen
Soongsil University
July 3, 2017
Controlling Service Function Access to Network Service Header
draft-vu-sfc-sf-access-control-02
Abstract
This document describes a mechanism to control Service Function
access to the Network Service Header (NSH). It addresses the Service
Function trust issue and provide a method to enforce predefined
access control lists to limit Service Function access to Service
Function Chain information in the NSH in NSH-based Service Chaining.
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 September 12, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Vu Anh Vu, et al. Expires January 1, 2018 [Page 1]
Internet-Draft Controlling SF Access to NSH July 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 2
1.3. Definition Of Terms . . . . . . . . . . . . . . . . . . . 3
2. SF Access Control List . . . . . . . . . . . . . . . . . . . 4
3. Access Control Enforcing Mechanisms . . . . . . . . . . . . . 4
4. Consideration for NSH Concealment . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Problem Statement
SFC Architecture document [RFC7665] defines architectural concepts
and core components, including Service Functions (SFs), Service
Function Forwarder (SFF), Classifier (CF), SFC Proxy. These
terminologies will be used in this documents.
It is argued that whether or not we should trust the SFs in SFC. In
SFC general use cases, SFs vary from virtual services hosted in
general-purpose servers to legacy service functions with dedicated
hardware. Most of the time, these SFs are deployed and operated by
their service provider. Therefore they are highly trusted. Despite
being in private and relatively safe service provider networks, SFs
are not invulnerable to all security threats. Indeed, several
reasons cause the misbehavior of SFs. For instance, they can still
be manipulated by multiple types of malware. Furthermore,
malfunctioned and misconfigured SFs can have anomaly behaviors as
well.
Aside from their own SFs, service providers may use SFs from other
sources such as third party service providers (in case they want to
outsource their SFs), SFs on customer premise, and legacy black-box
Vu Anh Vu, et al. Expires January 1, 2018 [Page 2]
Internet-Draft Controlling SF Access to NSH July 2017
SFs. In addition, enterprises are also trying to outsource their SFs
to service providers, while still manage the SFC by themselves.
Although service providers always have some SLAs for each SF, these
SFs need to be verified and security checked frequently.
Even if the SFs are trusted and secured, we still need to concern
about the security of transportation layer. Traffic between SFs and
forwarding components (SFF, Classifier, SFC proxy) can be harmed by
other threats such as man-in-the-middle attacks and spoofing,
especially in geographically distributed data centers.
As described in [I-D.ietf-sfc-nsh], NSH can be used to encapsulate
SFC information to the packets in NSH-based Service Chaining. There
have been considerations about the security of this encapsulation.
Problem Statement for Service Function Chaining [RFC7498] and SFC
Architecture document [RFC7665] express concerns about SFC
Encapsulation Security, which emphasize the importance of securing
sensitive metadata carried by the encapsulation and state the
requirement of an "appropriate protective treatment of NSH
information". Specifically, the NSH document [I-D.ietf-sfc-nsh]
suggests some options (e.g. IP Sec) to provide NSH metadata
authenticity and confidentiality, most of them involve NSH
encryption.
As described in [I-D.ietf-sfc-control-plane], control-plane store
and manage the access policies for SFs. Classifiers follow the
policies to push/pop NSH for packets.
[I-D.mglt-sfc-security-environment-req] lists requirements for SFC
security, including data plane requirements, which emphasize the need
of preventing the privacy leakage in SFC metadata. The document also
recommends some solutions such as metadata encryption and replacing
metadata by its reference, which is our method in this document.
Certainly, NSH encryption can provide rather strong security for the
SFC metadata in an SFC-enabled domain, but it is also costly. Both
header encryption and key distribution require lots of resources and
probably cause performance penalties to the SFC. In this document,
we describe an inexpensive mechanism to protect the sensitive
metadata in NSH from either corrupted SFs or underlay networks
security threats in NSH-based Service Chaining.
1.3. Definition Of Terms
o Access-Controlled Segment (ACS): an ACS is an area/field within
NSH that carries a piece of sensitive SFC information needed to be
protected. The access to this information from SFs should be
limited and be controlled.
Vu Anh Vu, et al. Expires January 1, 2018 [Page 3]
Internet-Draft Controlling SF Access to NSH July 2017
o SF Access Control List (SF ACL): a list describes the access
permission of an SF to each ACS in the packet passing through it.
Each SF should have an SF ACL.
o Ingress Subsequent Classifier (Ingress S-CF): a logical classifier
located BEFORE an access-controlled SF. S-CFs are responsible for
classify packets going into the SF and update their NSH.
o Egress Subsequent Classifier (Egress S-CF): a logical classifier
located AFTER an access-controlled SF. S-CFs are responsible for
classify packets going out of the SF and update their NSH.
o NSH-state: a set of value/information stored in the NSH of a
packet at a particular moment. For example, the value of Service
Index, Service Path Index, Mandatory Context Header 1-4. An NSH-
state usually consists of some ACS values.
2. SF Access Control List
Currently, without packet encryption, all SFs have full access to the
packets they process and, in particular, the SFC information.
Consequently, an SF can read and modify any unencrypted information
within the NSH during its packet handling process. Depend on what
metadata stored in NSH, a corrupted SF can manipulate a part of
information for harmful purposes such as changing service path, SF
spoofing, gathering tenant information.
In most situations, a SF might not need to know all SFC
information to process its incoming packets. An Access Control List
(ACL) of an SF contains access permissions of the SF to each ACS in
the NSH, including NSH base header, Service Path Index (SPI),
Service Index (SI),and Metadata (MD). For MD type 1, each of the 4
Mandatory Context Header(MCH) can become an ACS. MD type 2 has
variable length MCH, therefore SF ACL should be defined according
to the MD structure. Wepropose three levels of permission to
access an ACS of NSH:
o Hidden: the SF cannot view the information in this ACS
o Read-only: the SF can view, but cannot modify the information in
this ACS
o Full access: the SF can view and modify the information in this
ACS
3. Access Control Enforcing Mechanisms
In this section, we propose a mechanism to enforce SF ACLs in SFC.
The mechanism has two principles:
Vu Anh Vu, et al. Expires January 1, 2018 [Page 4]
Internet-Draft Controlling SF Access to NSH July 2017
1. Only give SFs what information they need to access.
2. SFFs cannot control SFs not to modify SFC information, but they
can choose not to accept the modification.
Figure 1 shows the components involved in the mechanism.
Occasionally, an SF is attached to an SFF. However, according [I-
D.ietf-sfc-nsh], SFFs CANNOT perform NSH updating, which is the
essential requirement of this mechanism. Therefore, Ingress/Egress
S-CFs are added and coordinate with SFF to classify packets and
update NSH.
When a packet come to an SFF on its way to the next SF in the SFP,
the SFF will forward it to the ingress S-CF corresponds to the SF.
Next, the ingress S-CF will check the SF ACL to get the SF permission
to each ACS. If the SF has Hidden permission to an ACS, the data
contained in that ACS will be stored by the S-CF and erased from the
packet (i.e. set all byte to zero). As a result, sensitive
information will be obscured from the SF, hence reduce the
possibility of leaking information. Besides, the ingress S-CF does
not store only the erased ACS but also the ACSes that the SF has
read-only permission for later use.
After processing the packet, the SF forwards it back to an egress
S-CF, which could be the same one as the aforementioned ingress S-CF.
This S-CF checks the SF ACL and 1) With Hidden ACS, it gets the
stored NSH-state (consists of ACS values) from the ingress S-CF and
put it back to the packet, 2) With read-only ACS, it also gets the
value from the NSH-state stored in the ingress S-CF and compares to
the current value. If the value is changed, the SF has tried to
modify the ACS and egress S-CF would recover the ACS from the NSH-
state stored by ingress S-CF. Using this method, we can preserve the
original SFC information, as well as detect abnormal SF behaviors.
Vu Anh Vu, et al. Expires January 1, 2018 [Page 5]
Internet-Draft Controlling SF Access to NSH July 2017
+----------------------------+
| |
+----+ Control Plane +----+
| | | |
| +-+------------------------+-+ |
| | | |
| | | |
| | | |
| | | |
| | | |
v | | |
+---------+ +---+---+ | | +---v---+
| | | | | | | |
| Initial | ... | SFF | | | | SFF | ...
| CF | | | | | | |
+---------+ +---+---+ | | +---+---+
| | | ^
| v v |
| +----+----+ +------+ +----+----+ |
| | | | | | | |
+-> Ingress +---> SF +---> Egress +-+
| S-CF | | | | S-CF |
+---------+ +------+ +---------+
Figure 1: Controlling SFs access to NSH in SFC architecture
In this mechanism, the ingress and egress S-CF must exchange stored
ACS data in either way:
o Shared storage
o Send the data to the SFC control plane
Another key point of this mechanism is the method to track packets
between ingress and egress S-CFs to recover the appropriate NSH
metadata. In detail, a packet encapsulation (including NSH) and
payload might be changed after it traverses the SF between ingress
and egress S-CFs. The egress S-CF must know which NSH-state saved by
the ingress SFF corresponds with a packet it receives. Current
solutions for this include:
o Reclassification: The packet will be classified (i.e. Using
5-tuple) after it exits the SF and goes to the egress S-CF. The
appropriate NSH will be determined based on the classification
result. Nevertheless, this approach cannot work with SFs which
change 5-tuple (such as NAT)
Vu Anh Vu, et al. Expires January 1, 2018 [Page 6]
Internet-Draft Controlling SF Access to NSH July 2017
o Using Metadata: In this approach, the ingress S-CF put a unique ID
named NSH-state ID into the NSH metadata of the packets. The
egress S-CF get the ID from a packet and use it to determine the
packet's original NSH-state. Figure 2 presents an example of NSH
having Metadata type 1 with NSH-state ID. Also, NSH-state ID can
be defined per-flow or per-packet. Nevertheless, the disadvantage
is that we have to reserve a part of Metadata, which also can be
access by SFs, for NSH-state ID.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSH-State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NSH-state ID in NSH Metadata type 1
This mechanism guarantees the consistency of sensitive SFC data
within NSH when packets travel from an ingress SFF to an egress SFF
through an SF, which means it can eliminate potential threats from
the SF as well as the transportation networks between SFs and SFFs.
4. Consideration for NSH Concealment
In the previous section, we describe a mechanism to obscure ACS in
NSH from SFs. However, it is not limited to controlling the access
to NSH of only SFs but other components as well. Indeed, the
mechanism can be extended to conceal ACS between two any points on
the service function path of a packet. In other words, an ingress
and an egress SFFs can be any SFF on the SFP, not just the SFF which
is directly attached to an SF.
Moreover, the mechanism can be used to perform simple and low-cost
NSH encryptions. For example, the ingress SFF will save an ACS value
and replace it with another value. The mapping table which maps
those two values will be given to the egress SFF and the all
authorized SFs.
Vu Anh Vu, et al. Expires January 1, 2018 [Page 7]
Internet-Draft Controlling SF Access to NSH July 2017
5. Acknowledgements
TBD
6. IANA Considerations
This document does not require any IANA actions.
7. Security Considerations
Secure communications between SFC control plane and components is
required, as described in [I-D.ietf-sfc-control-plane], in order to
secure access control policies during policy propagation from the
control plane to enforcing components (such as SFFs and classifiers).
Furthermore, if the NSH state table of an ingress S-CF is leaked, the
controlling mechanism can be easily bypassed by spoofing. Therefore,
NSH state exchange process, which is either between CF-control plane
or CF-CF, should be secured as well.
8. Normative References
[I-D.ietf-sfc-control-plane]
Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", draft-ietf-sfc-control-
plane-08 (work in progress), October 2016.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-13 (work in progress), June 2017.
[I-D.mglt-sfc-security-environment-req]
Migault, D., Pignataro, C., Reddy, T., and C. Inacio, "SFC
environment Security requirements", draft-mglt-sfc-
security-environment-req-02 (work in progress), October
2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>.
Vu Anh Vu, et al. Expires January 1, 2018 [Page 8]
Internet-Draft Controlling SF Access to NSH July 2017
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Vu Anh Vu
Soongsil University
369 Sangdo-ro
Dongjak-gu, Seoul 06978
South Korea
Email: vuva@dcn.ssu.ac.kr
Younghan Kim
Soongsil University
369 Sangdo-ro
Dongjak-gu, Seoul 06978
South Korea
Email: younghak@ssu.ac.kr
Kyoungjae Sun
Soongsil University
369 Sangdo-ro
Dongjak-gu, Seoul 06978
South Korea
Email: gomjae@ssu.ac.kr
Van-Ca Nguyen
Soongsil University
369 Sangdo-ro
Dongjak-gu, Seoul 06978
South Korea
Email: canguyen@dcn.ssu.ac.kr
Vu Anh Vu, et al. Expires January 1, 2018 [Page 9]
