| SFC | M. Boucadair |
| Internet-Draft | Orange |
| Intended status: Standards Track | T. Reddy |
| Expires: May 23, 2020 | McAfee |
| D. Wing | |
| Citrix | |
| November 20, 2019 |
Integrity Protection for Network Service Header (NSH) and Encryption of Sensitive Context Headers
draft-rebo-sfc-nsh-integrity-02
This specification adds integrity protection and optional encryption of sensitive metadata directly to Network Service Headers (NSH) used for Service Function Chaining (SFC).
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 https://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 23, 2020.
Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Many advanced Service Functions (e.g., Performance Enhancement Proxies, NATs, firewalls, etc.) are invoked for the delivery of value-added services, particularly to meet various service objectives such as IP address sharing, avoiding covert channels, detecting Denial-of-Service (DoS) attacks and protecting network infrastructures against them, network slicing, etc. Because of the proliferation of such advanced SFs together with complex service deployment constraints that demand more agile service delivery procedures, operators need to rationalize their service delivery logics and master their complexity while optimising service activation time cycles. The overall problem space is described in [RFC7498].
[RFC7665] presents an architecture addressing the problematic aspects of existing service deployments, including topological dependence and configuration complexity. It also describes an architecture for the specification, creation, and maintenance of Service Function Chains (SFC) within a network. That is, how to define an ordered set of SFs and ordering constraints that must be applied to packets/flows selected as a result of traffic classification. [RFC8300] specifies the SFC encapsulation: Network Service Header (NSH).
NSH data is unauthenticated and unencrypted [RFC8300], forcing a service topology that requires security and privacy to use a transport encapsulation that supports such features (e.g., IPsec). The lack of such capability was reported during the development of [RFC8300] and [RFC8459]. The reader may refer to Section 4.2.1 of [I-D.arkko-arch-internet-threat-model] for a discussion on the need for more awareness about attacks from within closed domains.
This specification fills that gap. Concretely, this document adds integrity protection and optional encryption of sensitive metadata directly to NSH (Section 4); integrity protects the packet payload, and provides relay protection. Thus, the NSH do not have to rely upon an underlying transport encapsulation for security and confidentiality.
This specification introduces new Variable-Length Context Headers to carry fields necessary for integrity protected NSH headers and encrypted Context Headers (Section 5), and is therefore only applicable to NSH MD Type 0x02, as defined in Section 2.5 of [RFC8300].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.
This document makes use of the terms defined in [RFC7665] and [RFC8300].
The document defines the following terms:
The NSH format is defined in Section 2 of [RFC8300]; the NSH data can be spread over three headers:
NSH allows to share context information (a.k.a., metadata) with upstream SFC-aware data elements on a per SFC/SFP basis. To that aim:
In reference to Figure 1,
+---------------+-----------------------+---------------+ | | Insert, remove, or | Update | | | replace the NSH | the NSH | | | | | |SFC Data Plane +-------+-------+-------+-------+-------+ | Element | | | |Dec. |Update | | |Insert |Remove |Replace|Service|Context| | | | | |Index |Header | +---------------+-------+-------+-------+-------+-------+ | | + | | + | | + | |Classifier | | | | | | +---------------+-------+-------+-------+-------+-------+ |Service | | + | | | | |Function | | | | | | |Forwarder (SFF)| | | | | | +---------------+-------+-------+-------+-------+-------+ |Service | | | | + | + | |Function (SF) | | | | | | +---------------+-------+-------+-------+-------+-------+ | | + | + | | + | + | |SFC Proxy | | | | | | +---------------+-------+-------+-------+-------+-------+
Figure 1: NSH Actions
This document does not make any assumption about the service function chains to be instantiated nor adds any constraint about how NSH can be used within a domain. For example, in reference to Figure 2, the solution accommodates deployment schemes such as: no Context Header is inserted by the Classifier, a first SF inserts two Context Headers that it encrypts, a second SF is entitled to access that encrypted data but it is instructed to strip one particular Context Header, and a third SF is instructed to strip the remaining Context Header. The following behavior will thus be observed:
SF1 SF3
| |
Classifier---SFF1----SFF2---SFF3
|
SF2
Figure 2: SFC-enabled Domain Example
This specification provides the functions described in the following sub-sections:
The solution allows to encrypt all or a subset of metadata (that is carried in NSH Context Headers) by Classifiers, SFC-aware SFs, and SFC proxies. As depicted in Table 1, SFFs are not involved in data encryption. This memo enforces this design approach by encrypting the Context Header with keys that are not supplied to SFFs, thus enforcing this limitation by protocol (rather than requirements language).
| Data Plane Element | Base and Service Headers Encryption | Metadata Encryption |
|---|---|---|
| Classifier | No | Yes |
| SFF | No | No |
| SFC-aware SF | No | Yes |
| SFC Proxy | No | Yes |
| SFC-unaware SF | No | No |
The control plane is assumed to instruct the Classifier, SFC-aware SFs, and SFC proxy with the set of Context Headers (privacy-sensitive metadata, typically) that must be encrypted. Encryption keying material is only provided to these SFC data elements.
The control plane may also indicate the set of SFC data plane elements that are entitled to supply a given context header (e.g., in reference to their identifiers as assigned within the SFC-enabled domain). It is out of the scope of this document to elaborate on how such instructions are provided to the appropriate SFC data plane elements, nor to detail the structure used to store the instructions.
The Service Path Header is not encrypted because SFFs use Service Index (SI) in conjunction with Service Path Identifier (SPI) for determining the next SF in the path.
The solution provides integrity protection for NSH data. Two flavors are supported.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | Base Header | | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | | Service Path Header | S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | | Context Header(s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | | Original Packet | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +------Scope of integrity protected data
Figure 3: First Integrity Flavor
A first flavor where all NSH data except the Base Header are integrity protected (Figure 3). In this case, the NSH imposer may be a Classifier, an SFC-aware SF, or an SFC proxy. SFFs are not thus provided with authentication material. Further details are discussed in Section 5.3.1.
A second flavor where all NSH data, including the Base Header, are integrity protected (Figure 4). In this case, the NSH imposer may be a Classifier, an SFC-aware SF, an SFF, or an SFC proxy. Further details are discussed in Section 5.3.2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Encapsulation |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Base Header | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| | Service Path Header | S
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| | Context Header(s) | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Original Packet |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+----Scope of integrity protected data
Figure 4: Second Integrity Flavor
The integrity protection scope is explicitly signaled to SFC-aware SFs and SFC proxies in the NSH by means of a dedicated MD Type (Section 5.3).
In both flavors, the unencrypted metadata and the packet on which NSH is imposed are subject to integrity protection.
Table 2 lists the roles of SFC data plane elements in providing integrity protection for the NSH.
| Data Plane Element | Integrity Protection |
|---|---|
| Classifier | Yes |
| SFF | No (first flavor); Yes (second flavor) |
| SFC-aware SF | Yes |
| SFC Proxy | Yes |
| SFC-unaware SF | No |
The authenticated encryption algorithm defined in [RFC7518] is used to provide NSH data integrity and to encrypt Context Headers carrying privacy-sensitive metadata.
The authenticated encryption algorithm provides a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and vice versa. The generation of secondary keys MAC_KEY and ENC_KEY from the secret key K is discussed in Section 5.2.2.1 of [RFC7518]. The ENC_KEY is used for encrypting the Context Headers and the message integrity of the NSH data is calculated using the MAC_KEY. If the Context Headers are not encrypted, the Hashed Message Authentication Mode (HMAC) algorithm discussed in [RFC4868] is used to integrity protect the NSH data.
The advantage of using the authenticated encryption algorithm is that SFC-aware SFs and SFC proxies only need to re-compute the message integrity of the NSH data after decrementing the Service Index (SI) and do not have to re-compute the ciphertext. The other advantage is in both the flavors discussed above is SFFs do not have access to the ENC_KEY and cannot act on the encrypted Context Headers and, only in case of the second flavor, SFFs do have access to the MAC_KEY. Similarly, an SFC-aware SF or SFC proxy not allowed to decrypt the Context Headers will not have access to the ENC_KEY.
The authenticated encryption algorithm or HMAC algorithm to be used by SFC data plane elements is typically controlled using the SFC control plane. Mandatory to implement authenticated encryption and HMAC algorithms are listed in Section 4.3.
The authenticated encryption process takes as input four octet strings: a secret key (K), a plaintext (P), Additional Authenticated Data (A) (which contains the data to be authenticated, but not encrypted), and an Initialization Vector (IV). The ciphertext value (E) and the Authentication Tag value (T) are provided as outputs.
In order to decrypt and verify, the cipher takes as input K, IV, A, T, and E. The output is either the plaintext or an error indicating that the decryption failed as described in Section 5.2.2.2 of [RFC7518].
Classifiers, SFC-aware SFs, and SFC proxies MUST implement the AES_128_CBC_HMAC_SHA_256 algorithm and SHOULD implement the AES_192_CBC_HMAC_SHA_384 and AES_256_CBC_HMAC_SHA_512 algorithms.
Classifiers, SFC-aware SFs, and SFC proxies MUST implement the HMAC-SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and HMAC-SHA-512-256 algorithms.
SFFs MAY implement the aforementioned cipher suites and HMAC algorithms.
The procedure for the allocation/provisioning of secret keys (K) and authenticated encryption algorithm or MAC_KEY and HMAC algorithm is outside the scope of this specification. As such, this specification does not mandate the support of any specific mechanism.
The documents does not assume nor preclude the following:
In order to accommodate deployments relying upon keying material per SFC/SFP and also the need to update keys after encrypting NSH data for certain amount of time, this document uses key identifier (kid) to unambiguously identify the appropriate keying material. Doing so allows to address the problem of synchronization of keying material.
Additional information on manual vs. automated key management and when one should be used over the other can be found in [RFC4107].
New NSH Variable-Length Context Headers are defined in Section 5 for NSH data integrity protection and, optionally, encryption of Context Headers carrying privacy-sensitive metadata. Concretely, an NSH imposer includes (1) the key identifier in NSH using the Key Identifier Context Header (Section 5.1), (2) the timestamp in Timestamp Context Header to protect against replay attacks (Section 6.4), and (3) the Message Authentication Code (MAC) for the target NSH data (depending on the integrity protection scope) calculated using the MAC_KEY and optionally Context Headers encrypted using ENC_KEY in 'MAC and Encrypted Metadata Context' Header (Section 5.3).
An NSH data plane element that needs to check the integrity of the NSH data uses the MAC_KEY and the HMAC algorithm for the key identifier being carried in the NSH.
An SFC-aware SF or SFC proxy that needs to decrypt the metadata uses ENC_Key and the decryption algorithm for the key identifier being carried in the NSH.
Section 6 specifies the detailed procedure.
As discussed in [RFC8459], an SFC-enabled domain (called, upper-level domain) may be decomposed into many sub-domains (called, lower-level domains). In order to avoid maintaining state to restore back upper-lower NSH information at the boundaries of lower-level domains, two NSH levels are used: an Upper-NSH which imposed at the boundaries of the upper-level domain, and a Lower-NSH that is pushed by the Classifier of a lower-level domain in front of the original NSH (Figure 5). As such, the Upper-NSH information is carried along the lower-level chain without modification. The packet is forwarded in the top-level domain according to the Upper-NSH, while it is forwarded according to the Lower-NSH in a lower-level SFC domain.
+---------------------------------+
| Transport Encapsulation |
+->+---------------------------------+
| | Lower-NSH Header |
| +---------------------------------+
| | Upper-NSH Header |
| +---------------------------------+
| | Original Packet |
+->+---------------------------------+
|
|
+----Scope of NSH security protection
provided by a lower-level domain
Figure 5: Encapsulation of NSH within NSH
SFC data plane elements of a lower-level domain includes the Upper-NSH when computing the MAC.
Keying material used at the upper-level domain should not the same as the one used by a lower-level domain.
This section specifies the format of new Variable-Length Context headers that are used for NSH integrity protection and, optionally, Context Headers encryption.
The Key Identifier Context Header (Figure 6) is a variable length Key Identifier object used to identify and deliver keys to SFC data plane elements. Sending this Context Header is REQUIRED for compliance with this specification.
This Context Header is helpful to accommodate deployments relying upon keying material per SFC/SFP. The key identifier helps in resolving the problem of synchronization of keying material.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Key Identifier Context Header
The description of the fields is as follows:
The Timestamp Context Header (Figure 7) conveys a 64-bit timestamp value. Sending this Context Header is REQUIRED for compliance with this specification.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Timestamp Context Header
The description of the fields is as follows:
This section defines two MAC and Encrypted Metadata Context Headers; each having specific deployment constraints. Unlike the flavor discussed in Section 5.3.1, the flavor sketched in Section 5.3.2 requires sharing MAC_KEY with SFFs. Both TLVs have the same format as shown in Section 5.3.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV Length | |
+-+-+-+-+-+-+-+-+ Initialization Vector ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Authentication Code and optional Encrypted |
~ Context Headers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MAC and Encrypted Metadata Context Header
The description of the fields is provided in the following sub-sections.
MAC#1 Context Header is a variable-length TLV that carries the Message Authentication Code (MAC) for the Service Path Header, Context Headers, and the inner packet on which NSH is imposed, calculated using MAC_KEY and optionally Context Headers encrypted using ENC_KEY. The scope of this TLV is depicted in Figure 9.
This MAC flavor does not require sharing MAC_KEY with SFFs. It does not require to re-compute the MAC by each SFF because of TTL processing. Section 7.1 discusses the possible threat associated with this flavor.
0 1 2 3
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|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+
| Service Path Identifier | Service Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Key Identifier ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Timestamp ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
~ Variable-Length Unencrypted Context Headers (opt.) ~ |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Metadata Class | Type |U| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IV Length | Initialization Vector | |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ Context Header TLVs to encrypt ~ |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| ~ Inner Packet on which NSH is imposed ~ |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--|
| |
| |
| |
| Integrity protected Portion----+
+----Encrypted Portion
Figure 9: Scope of MAC#1
In reference to Figure 8, the description of the fields is as follows:
MAC#2 Context Header is a variable-length TLV that carries the MAC for the entire NSH data calculated using MAC_KEY and optionally Context Headers encrypted using ENC_KEY. The scope of this TLV is depicted in Figure 10.
0 1 2 3
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|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Service Path Identifier | Service Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Key Identifier ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Timestamp ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
~ Variable-Length Unencrypted Context Headers (opt.) ~ |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Metadata Class | Type |U| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IV Length | Initialization Vector | |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ Context Header TLVs to encrypt ~ |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| ~ Inner Packet on which NSH is imposed ~ |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--|
| |
| |
| |
| Integrity protected Portion----+
+----Encrypted Portion
Figure 10: Scope of MAC#2
In reference to Figure 8, the description of the fields is as follows:
The following sub-sections describe the processing rules for integrity protected NSH and optionally encrypted Context Headers.
This document adheres to the recommendations in [RFC8300] for handling the Context Headers at both ingress and egress SFC boundary nodes. That is, to strip such context headers.
Failures to inject or validate the Context Headers defined in this document SHOULD be logged locally while a notification alarm MAY be sent to an SFC Control Element. Similarly, failure to validate the integrity of the NSH data MUST cause that packet to be discarded while a notification alarm MAY be sent to an SFC Control Element. The details of sending notification alarms (i.e., the parameters affecting the transmission of the notification alarms depend on the information in the context header such as frequency, thresholds, and content in the alarm) SHOULD be configurable by the SFC control plane.
SFC-aware SFs and SFC proxies MAY be instructed to strip some encrypted Context Headers from the packet or to pass the data to the next SF in the service function chain after processing the content of the Context Headers. If no instruction is provided, the default behavior for intermediary SFC-aware nodes is to maintain such Context Headers so that the information can be passed to next SFC-aware hops. SFC-aware SFs and SFC proxies must re-apply the integrity protection if any modification is made to the Context Headers (strip a Context Header, update the content of an existing Context Header, insert a new Context Header).
An SFC-aware SF or SFC proxy that is not allowed to decrypt any Context Headers MUST NOT be given access to the ENC_KEY.
Otherwise, an SFC-aware SF or SFC proxy that receives encrypted Context Headers, for which it is not allowed to consume a specific Context Header it decrypts (but consumes others), MUST keep that Context Header unaltered when forwarding the packet upstream.
Only one instance of Key Identifier (or Timestamp, MAC and Encrypted Metadata) Context Header is allowed. If multiple instances of Key Identifier (or Timestamp, MAC and Encrypted Metadata) Context Header are included in an NSH packet, the SFC data element must process the first instance and ignore subsequent instances, and may log or increase a counter for this event as per Section 2.5.1 of [RFC8300].
MTU and fragmentation considerations are discussed in Section 5 of [RFC8300]. Those considerations are not reiterated here.
If the Context Headers are not encrypted, the HMAC algorithm discussed in [RFC4868] is used to integrity protect the target NSH data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context Header for integrity protection (Section 5.3).
The NSH imposer computes the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 5.3) using MAC_KEY and HMAC algorithm. It inserts the MAC in the "MAC and Encrypted Metadata" Context Header. The length of the MAC is decided by the HMAC algorithm adopted for the particular key identifier.
The Message Authentication Code T computation process can be illustrated as follows:
T = HMAC-SHA-256-128(MAC_KEY, A)
An entity in the SFP that intends to update NSH MUST follow the above behavior to maintain message integrity of the NSH for subsequent validations.
An NSH imposer can encrypt Context Headers carrying privacy-sensitive metadata, i.e., encrypted and unencrypted metadata may be carried simultaneously (Figure 11).
0 1 2 3
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|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Timestamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable-Length Unencrypted Context Headers (opt.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC and Encrypted Metadata ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NSH with Encrypted and Unencrypted Metadata
In an SFC-enabled domain where pervasive monitoring [RFC7258] is possible, Context Headers carrying privacy-sensitive metadata MUST be encrypted and MUST NOT reveal privacy-sensitive metadata to attackers. Privacy specific threats are discussed in Section 5.2 of [RFC6973].
Using K and authenticated encryption algorithm, the NSH imposer encrypts the Context Headers (as set by the control plane Section 3), computes the message integrity for the target NSH data and inserts the resulting payload in the "MAC and Encrypted Metadata" Context Header (Section 5.3). The entire TLV carrying the privacy-sensitive metadata is encrypted (that is, including the MD Class, Type, Length, and associated metadata).
The message Authentication Tag (T) and ciphertext (E) computation process can be illustrated as follows:
MAC_KEY = initial MAC_KEY_LEN octets of K,
ENC_KEY = final ENC_KEY_LEN octets of K,
E = CBC-PKCS7-ENC(ENC_KEY, P),
M = MAC(MAC_KEY, A || IV || E || AL),
T = initial T_LEN octets of M.
MAC and Encrypted Metadata = E || T
As specified in [RFC7518], the octet string (AL) is equal to the number of bits in the Additional Authenticated Data (A) expressed as a 64-bit unsigned big-endian integer.
An authorized entity in the SFP that intends to update the content of an encrypted Context Header or needs to add a new encrypted Context Header MUST also follow the aforementioned behavior.
An SFF or SFC-aware SF or SFC proxy that only has access to the MAC_KEY but not the ENC_KEY computes the message Authentication Tag (T) after decrementing the TTL (by the SFF) or SI (SF or SFC proxy) and replaces the authentication tag in the NSH with the computed authentication tag. Similarly, an SFC-aware SF or SFC proxy that does not modify the encrypted Context headers also follows the aforementioned behavior.
The message Authentication Tag (T) computation process can be illustrated as follows:
M = MAC(MAC_KEY, A || IV || E || AL),
T = initial T_LEN octets of M.
A Timestamp is an unsigned 64-bit integer value and is expressed in seconds relative to 1970-01-01T00:00Z in UTC time. The information MUST always be present. The received NSH is accepted if the Timestamp (TS) in the NSH is recent enough to the reception time of the NSH (TSrt). The following formula is used for this check:
-Delta < (TSrt ? TS) < +Delta
The RECOMMENDED value for the allowed Delta is 2 seconds. If the timestamp is not within the boundaries, then the SFC data plane element receiving such packet MUST discard the NSH message.
All SFC data plane elements must be synchronized among themselves. These elements may be synchronized to a global reference time.
When an SFC data plane element receives an NSH packet, it MUST first ensure that all mandatory Context Headers required for NSH data integrity are included. It MUST silently discard the message if one of these mandatory Context Headers is missing or if the timestamp is invalid (described in Section 6.4). It MUST log an error at least once per the SPI for which the mandatory metadata is missing.
If all mandatory Context Headers are present, the SFC data plane element should then proceed with NSH data integrity validation. The SFC data plane element computes the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 5.3) using the MAC_KEY and HMAC algorithm for the key identifier. If the value of the newly generated digest is identical to the one enclosed in NSH, the SFC data plane element is certain that the NSH data has not been tampered and validation is therefore successful. Otherwise, the NSH packet MUST be discarded.
If entitled to consume a supplied encrypted Context Header, an SFC-aware SF or SFC proxy decrypts metadata using K and decryption algorithm for the key identifier in NSH.
Authenticated encryption algorithm has only a single output, either a plaintext or a special symbol FAIL that indicates that the inputs are not authentic (Section 5.2.2.2 of [RFC7518]).
NSH security considerations are discussed in Section 8 of [RFC8300]. The guidelines for cryptographic key management are discussed in [RFC4107].
The interaction between the SFC-aware data plane elements and a key management system MUST NOT be transmitted in clear since this would completely destroy the security benefits of the integrity protection solution defined in this document. The secret key K must have an expiration time assigned as the latest point in time before which the key may be used for integrity protection of NSH data and encryption of Context Headers. Prior to the expiration of the secret key, all participating service function nodes SHOULD have the control plane distribute an new key identifier and associated keying material, so that when the secret key is expired those nodes are prepared with the new secret key. This allows the NSH Imposer to switch to the new key identifier as soon as necessary. It is RECOMMENDED that the next key identifier be distributed by the control plane well prior to the secret key expiration time.
NSH data are exposed to several threats:
In an SFC-enabled domain where the above attacks are possible, NSH data MUST be integrity-protected and replay-protected, and privacy-sensitive NSH metadata MUST be encrypted for confidentiality preservation purposes. The Base and Service Path headers are not encrypted.
Two MAC flavors are defined in Section 5.3. Considerations specific to each flavor are discussed in the following sub-sections.
An active attacker can potentially modify the Base header (e.g., decrement the TTL so the next SFF in the SFP discards the NSH packet). In the meantime, an active attacker can also drop NSH packets. As such, this attack is not considered an attack against the security mechanism specified in the document.
No device other than the SFC-aware SFs in the SFC-enabled domain should be able to update the integrity protected NSH data. Similarly, no device other than the SFC-aware SFs and SFC proxies in the SFC-enabled domain be able to decrypt and update the Context Headers carrying privacy-sensitive metadata. In other words, if the SFC-aware SFs and SFC proxies in the SFC-enabled domain are considered fully trusted to act on the NSH data, only they can have access to privacy-sensitive NSH metadata and the keying material used to integrity protect NSH data and encrypt Context Headers.
SFFs can detect whether an illegitimate node has altered the content of the Base header. Such messages MUST be discarded with appropriate logs and alarms generated.
This document requests IANA to assign the following types from the "NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 IETF Base NSH MD Class) registry available at: https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types.
+-------+-------------------------------+----------------+ | Value | Description | Reference | +-------+-------------------------------+----------------+ | TBD1 | Key Identifier | [ThisDocument] | | TBD2 | Timestamp | [ThisDocument] | | TBD3 | MAC and Encrypted Metadata#1 | [ThisDocument] | | TBD4 | MAC and Encrypted Metadata#2 | [ThisDocument] | +-------+-------------------------------+----------------+
This document was edited as a follow up to the discussion in IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01 (slide 7).
Thanks to Joel Halpern, Christian Jacquenet, and Dirk von Hugo for the comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4107] | Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005. |
| [RFC4868] | Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007. |
| [RFC7518] | Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. |
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8300] | Quinn, P., Elzur, U. and C. Pignataro, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018. |
| [I-D.arkko-arch-internet-threat-model] | Arkko, J., "Changes in the Internet Threat Model", Internet-Draft draft-arkko-arch-internet-threat-model-01, July 2019. |
| [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. |
| [RFC7258] | Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014. |
| [RFC7498] | Quinn, P. and T. Nadeau, "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015. |
| [RFC8459] | Dolson, D., Homma, S., Lopez, D. and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 10.17487/RFC8459, September 2018. |