Integrity Protection for Network Service Header (NSH) and Encryption of Sensitive Metadata
draft-rebo-sfc-nsh-integrity-01

Abstract

This specification adds integrity protection and optional encryption directly to Network Service Headers (NSH) used for Service Function Chaining (SFC).

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

Copyright Notice

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.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Assumptions & Basic Requirements
• 4. Solution Overview
• 5. Mandatory to Implement AEAD Algorithms
• 6. New NSH Variable-Length Context Headers
• 6.1. Key Identifier Context Header
• 6.2. Sequence Number Context Header
• 6.3. MAC and Encrypted Metadata Context Header
• 6.3.1. MAC#1 Context Header
• 6.3.2. MAC#2 Context Header
• 7. Processing Rules
• 7.1. Generic Behavior
• 7.2. MAC NSH Data Generation
• 7.3. Encrypted NSH Metadata Generation
• 7.4. Sequence Number Validation for Replay Attack
• 7.5. NSH Data Validation
• 7.6. Decryption of NSH Metadata
• 8. Security Considerations
• 8.1. MAC#1
• 8.2. MAC#2
• 9. IANA Considerations
• 10. Acknowledgements
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Appendix A. A Deployment Example with KMS
• Authors' Addresses

1. Introduction

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

This specification fills that gap. Concretely, this document adds integrity protection and optional encryption directly to NSH (Section 4). Thus, NSH data do not have to rely upon an underlying transport encapsulation for security and confidentiality. Note that the payload encapsulated by NSH is not part of the NSH data.

This specification introduces new Variable-Length Context Headers to carry fields necessary for integrity protected and encrypted NSH data (Section 6), and is therefore only applicable to NSH MD Type 0x02, as defined in Section 2.5 of [RFC8300].

2. Terminology

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:

• SFC data plane functional element: Refers to SFC-aware Service Function, Service Function Forwarder (SFF), SFC proxy, or classifier as defined in the SFC data plane architecture [RFC7665].
• SFC Control Element: A logical entity that instructs one or more SFC data plane functional elements on how to process NSH packets within an SFC-enabled domain.
• Key Identifier (or Ticket): A key identifier or kerberos-like object used to identify and deliver keys to authorized entities.
• NSH imposer: Refers to the SFC data plane element that is entitled to impose NSH with the Context headers defined in this document.

3. Assumptions & Basic Requirements

The NSH format is defined in Section 2 of [RFC8300]; the NSH data can be spread over three headers:

• Base Header: Provides information about the service header and the payload protocol.
• Service Path Header: Provides path identification and location within a service path.
• Context Header: Carries metadata (i.e., context data) along a service path.

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:

• The control plane is used to instruct the SFC classifier about the set of context information to be supplied in the context of a given chain.
• The control plane is also used to instruct an SFC-aware SF about any metadata it needs to attach to packets for a given SFC. This instruction may occur any time during the validity lifetime of an SFC/SFP. The control plane may indicate, for a given service function chain, an order for consuming a set of contexts supplied in a packet.
• An SFC-aware SF can also be instructed about the behavior it should adopt after consuming a context information that was supplied in the NSH header. For example, the context can be maintained, updated, or stripped.
• An SFC proxy may be instructed about the behavior it should adopt to process the context information that was supplied in the NSH header on behalf of an SFC-unaware SF, e.g., the context can be maintained or stripped.
• The SFC proxy may also be instructed to add some new context information into the NSH header on behalf of an SFC-unaware SF.

In reference to Figure 1,

• Classifiers, SFC-aware SFs, and SFC proxies are entitled to update the context header: Only these elements must be able to encrypt and decrypt a supplied context header.
• Only SFC-aware SFs and SFC proxies are entitled to update the Service Path header. The solution must provide integrity protection for this header.
• SFFs are entitled to modify the Base Path header (TTL value, for example). The solution may provide integrity protection for the base header.
  • Discussion Note: Check the level of this requirement with the WG.

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

The solution described in 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 metadata is inserted by the Classifier: it only proceeds with integrity protection.
• SF1 inserts two metadata M1 and M2 that it encrypts.
• SF2 decrypts M1 and M2, strips M2, and then encrypts M1
• SF3 decrypts M1 and then strips it.

             SF1            SF3
              |              |
Classifier---SFF1----SFF2---SFF3
                      |
                      SF2

Figure 2: SFC-enabled Domain Example

4. Solution Overview

The solution specified in the document allows for the following functions:

• Encrypt all or a subset of metadata by Classifiers, SFC-aware SFs, and SFC proxies:
  
  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.
  
  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.
• Provide integrity protection for NSH data:
  
  Two flavors are supported:
  1. A first flavor where only the Service Path and Context Headers are integrity protected.
     
     In this case, the NSH imposer may be a Classifier, an SFC-aware SF, or an SFC proxy.
  2. A second flavor where the Base, Service Path, and Context Headers are integrity protected.
     
     In this case, the NSH imposer may be a Classifier, an SFC-aware SF, an SFF, or an SFC proxy.
  
  
  In order to avoid the overhead of multiple authentication tags and multiple keys, and to prevent SFFs from acquiring the secret key to decrypt the metadata, the recommendation is not to integrity protect the base header. Such approach does not requrie to recompute the MAC each time TTL is decremented by an SFF. As a reminder, an SFF is not supposed to act on the metadata or look into the content of the metadata.
  
  The integrity scope is explicitly signaled in the NSH by means of a dedicated MD Type (Section 6.3).
  
  In both schemes, the unencrypted metadata is subject to integrity protection.

The Authenticated Encryption with Associated Data (AEAD) algorithm [RFC5116] is used to provide NSH data integrity and to encrypt privacy-sensitive metadata.

The AEAD algorithm to be used by SFC data plane elements may be controlled using the control plane or other means. Mandatory to implement AEAD algorithms are listed in Section 5.

AEAD algorithms take as input a single key (K), a Nonce, a plaintext (P) (which contains the data to be encrypted and authenticated), and "additional data" (A) (which contains the data to be authenticated, but not encrypted) as described in Section 2.1 of [RFC5116].

AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and vice versa. When the length of plaintext is zero, the AEAD algorithm acts as a Message Authentication Code (MAC) on the "additional data" input. The length of the AEAD output will generally be larger than the plaintext, but by a magnitude that varies with the AEAD algorithm.

In order to decrypt and verify, the cipher takes as input the key (K), Nonce, additional data, and the ciphertext. The output is either the plaintext or an error indicating that the decryption failed as described in Section 2.2 of [RFC5116].

The procedure for the allocation/provisioning of the secret key (K) and AEAD algorithm is outside the scope of this specification. As such, this specification does not mandate the support of any specific mechanism.

In order to accommodate deployments relying upon keying material per SFC/SFP and also the need to update keys after encrypting given amount of NSH data, 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. A (non-normative) sample deployment case to illustrate how kids are assigned is provided in Appendix A.

The NSH data is protected using K and optionally metadata is encrypted using K. New NSH Variable-Length Context Headers are defined in Section 6 for NSH integrity protection and, optionally, metadata encryption. Concretely, an NSH imposer includes (1) the key identifier in NSH using the Key Identifier Context Header (Section 6.1), (2) a Sequence Number in Sequence Number Context Header to protect against replay attacks (Section 7.4), and (3) the Message Authentication Code (MAC) for the NSH data (depending on the integrity protection scope) calculated using the secret key (K) and optionally metadata encrypted K in 'MAC and Encrypted Metadata Context' Header (Section 6.3).

An NSH data plane element that needs to check the integrity of the NSH data uses the secret key (K) and AEAD algorithm for the key identifier being carried in the NSH.

An SFC-aware SF or SFC proxy that needs to decrypt the metadata uses the secret key (K) and the decryption algorithm for the key identifier being carried in the NSH.

Section 7 specifies the detailed procedure.

5. Mandatory to Implement AEAD Algorithms

Classifiers, SFC-aware SFs, and SFC proxies MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites.

SFFs MAY implement the aforementioned cipher suites.

6. New NSH Variable-Length Context Headers

This section specifies the format of new Variable-Langth Context headers that are used for NSH integrity protection and, optionally, metadata encryption.

6.1. Key Identifier Context Header

Key Identifier Context Header is a variable length Key Identifier object used to identify and deliver keys to SFC data plane elements. This is a mandatory TLV that MUST be present if an integrity protected and encrypted NSH solution is desired.

This Context Header is helpful to accommodate deployments relying upon keying material per SFC/SFP. Also, the key needs to be updated after the encryption of a certain amount of NSH data. 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                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

The description of the fields is as follows:

• Metadata Class: MUST be set to 0x0 [RFC8300].
• Type: TBD1 (See Section 9)
• Length: Variable.
• Key Identifier: Carries the key identifier.

6.2. Sequence Number Context Header

Sequence Number Context Header conveys a 64-bit sequence number per key identifier. In this specification, a sequence number needs to be incremented every time NSH is included by the NSH imposer (for a given SFC/SFP). The sequence number SHOULD NOT be incremented if an existing NSH is being updated.

This is a mandatory TLV that MUST be present if an integrity protected and encrypted NSH solution is desired.

      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   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence                               |
     |                         Number                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The description of the fields is as follows:

• Metadata Class: MUST be set to 0x0 [RFC8300].
• Type: TBD2 (See Section 9)
• Length: 8 bytes
• Sequence Number: Carries the sequence number.

6.3. MAC and Encrypted Metadata Context Header

This section defines two MAC and Encrypted Metadata Context Headers; each having specific deployment constraints. Unlike the flavor discussed in Section 6.3.1, the scheme sketched in Section 6.3.2 requires sharing keying material with SFFs. Both TLVs have the same format as shown in Section 6.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   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Nonce Length  |                                               |
       +-+-+-+-+-+-+-+-+                  Nonce                        ~
       ~                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~  Message Authentication Code and optional Encrypted Metadata  ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: MAC and Encrypted Metadata Context Header

The description of the fields is provided in the following sub-sections.

6.3.1. MAC#1 Context Header

MAC#1 Context Header is a variable-length TLV that carries the Message Authentication Code (MAC) for the Service Path and unencrypted Context headers calculated using key K and optionally metadata encrypted K. The scope of this TLV is depicted in Figure 5.

        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                           ~    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       ~                      Sequence Number                          ~    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       |                                                               |    |
       ~       Variable-Length Unencrypted Context Headers  (opt.)     ~    |
       |                                                               |    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       |          Metadata Class       |      Type     |U|    Length   |    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       | Nonce Length  |                Nonce                          |    |
 +---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
 |     ~                    Metadata TLVs to encrypt                   ~    |
 +---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<---+ 
 |                                                                          |
 |                                                                          | 
 |                                           Integrity protected Portion----+
 +----Encrypted Portion                                                                

Figure 4: Scope of MAC#

In reference to Figure 3, the description of the fields is as follows:

• Metadata Class: MUST be set to 0x0 [RFC8300].
• Type: TBD3 (See Section 9)
• Nonce Length: Carries the length of the nonce (Section 4 of [RFC5116]).
• Nonce: Carries the nonce for AEAD algorithms as discussed in Section 3 of [RFC5116]. The associated data (defined in [RFC5116]) MUST be the Service Path and unencrypted Context headers.
• Message Authentication Code and optional Encrypted Metadata covering the Service Path and unencrypted context headers.

6.3.2. MAC#2 Context Header

MAC#2 Context Header is a variable-length TLV that carries the MAC for the entire NSH calculated using key K and optionally metadata encrypted key K. The scope of this TLV is depicted in Figure 5. This MAC flavor does not require sharing keying material with SFFs. It does not require to recompute the MAC by each SFF because of TTL processing (and potential change of the transport encapsulation protocol).

        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                           ~    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       ~                      Sequence Number                          ~    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       |                                                               |    |
       ~       Variable-Length Unencrypted Context Headers  (opt.)     ~    |
       |                                                               |    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       |          Metadata Class       |      Type     |U|    Length   |    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
       | Nonce Length  |                Nonce                          |    |
 +---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |
 |     ~                    Metadata TLVs to encrypt                   ~    |
 +---->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<---+ 
 |                                                                          |
 |                                                                          | 
 |                                           Integrity protected Portion----+
 +----Encrypted Portion                                                                

Figure 5: Scope of MAC#2

In reference to Figure 3, the description of the fields is as follows:

• Metadata Class: MUST be set to 0x0 [RFC8300].
• Type: TBD4 (See Section 9)
• Nonce Length: Carries the length of the nonce (Section 4 of [RFC5116]).
• Nonce: Carries the nonce for AEAD algorithms as discussed in Section 3 of [RFC5116]. The associated data (defined in [RFC5116] as A) MUST be the entire NSH data excluding the metadata to be encrypted.
• Message Authentication Code and optional Encrypted Metadata covering the entire NSH data excluding the metadata to be encrypted.

7. Processing Rules

The following sub-sections describe the processing rules for integrity protected NSH and optionally encrypted metadata.

7.1. Generic Behavior

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

An SFC-aware SF or SFC proxy that receive an encrypted metadata, for which it is not allowed to decrypt the data, SHOULD keep that data unaltered when forwarding the packet upstream.

• Notes: (1) add more text to handle multiple instances of the TLVs, (2) check which actual SFC element is doing what, ...

7.2. MAC NSH Data Generation

When the length of encrypted metadata is zero, the AEAD algorithm acts as a Message Authentication Code on the input A (defined in [RFC5116]). An NSH imposer inserts a "MAC and Encrypted Metadata" Context Header for integrity protection (Section 6.3).

The NSH imposer computes the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 6.3) using K, Nonce, and AEAD algorithm. It inserts the MAC in the "MAC and Encrypted Metadata" Context Header. The length of the MAC is decided by the AEAD algorithm adopted for the particular key identifier.

An entity in the service function path that intends to update NSH MUST follow the above behavior to maintain message integrity of the NSH for subsequent validations.

7.3. Encrypted NSH Metadata Generation

An NSH imposer can encrypt all NSH metadata or only a subset of metadata, i.e., encrypted and unencrypted metadata may be carried simultaneously (Figure 6).

      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                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                      Sequence Number                          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~       Variable-Length Unencrypted Context Headers  (opt.)     ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                   MAC and Encrypted Metadata                  ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: NSH with Encrypted and Unencrypted Metadata

In an SFC-enabled domain where pervasive monitoring [RFC7258] is possible, NSH 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 AEAD algorithm, the NSH imposer encrypts the metadata (as set by the control plane Section 3) and inserts the resulting payload in the "MAC and Encrypted Metadata" Context Header (Section 6.3). The entire TLV carrying the privacy-sensitive metadata is encrypted (that is, including the MD Class, Type, Length, and associated metadata).

An authorized entity in the SFP that intends to update encrypted metadata MUST also follow the aforementioned behavior.

7.4. Sequence Number Validation for Replay Attack

A Sequence Number is an unsigned 64-bit counter value that increases by one for each NSH created and is sent from the NSH imposer, i.e., a per-key identifier packet sequence number. The information is mandatory and MUST always be present.

Processing of the Sequence Number field is at the discretion of the receiver, but all implementations MUST be capable of validating that the Sequence Number that does not duplicate the Sequence Number of any other NSH received during the life of the key identifier.

The NSH imposer's counter is initialized to '0' when a new key identifier is to be used . The sender increments the Sequence Number counter for this key identifier and inserts the 64-bit value into the Sequence Number Context Header (Section 6.2). Thus, the first NSH message (for a given service function chain) sent using a given key identifier will contain a Sequence Number of 1. The imposer checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number Context Header. In other words, the sender MUST NOT send a packet with a key identifier if, by doing so, this would cause the Sequence Number to rollover.

Sequence Number counters of all participating nodes MUST be reset by establishing a new key identifier prior to the transmission of the 2^64th packet of NSH for a particular key identifier.

7.5. NSH Data Validation

When an SFC data plane element receives an NSH, it MUST first ensure that all mandatory TLVs required for NSH data integrity are included. It MUST discard the message, if mandatory TLVs are absent or if the Sequence Number is invalid (described in Section 7.4). Otherwise, the SFC data plane element should then proceed with data validation. The SFC data plane element computes the message integrity for the target NSH data (depending on the integrity protection scope discussed in Section 6.3) using K and AEAD algorithm for the key identifier being carried in NSH. 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 header has not been tampered and validation is therefore successful. Otherwise, the NSH message MUST be discarded.

7.6. Decryption of NSH Metadata

If entitled to consume a supplied encrypted metadata, an SFC-aware SF or SFC proxy decrypts metadata using K and decryption algorithm for the key identifier in NSH. AEAD algorithm has only a single output, either a plaintext or a special symbol FAIL that indicates that the inputs are not authentic (Section 2.2 of [RFC5116]).

There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. The NSH imposer SHOULD do a secret key update prior to reaching these limits.

8. Security Considerations

NSH security considerations are discussed in Section 8 of [RFC8300].

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 scheme defined in this document.

NSH data are exposed to from to four primary attacks:

• A man-in-the-middle attacker modifying NSH data.
• Attacker spoofing NSH data.
• Attacker capturing and replaying NSH data.
• NSH metadata revealing privacy sensitive information to attackers.

In an SFC-enabled domain where the above attacks are possible, NSH data MUST be integrity- and replay-protected, and privacy-sensitive NSH metadata MUST be encrypted for confidentiality preservation purposes.

The Base header is not encrypted. 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 is attack is not considered an attack against the security mechanism specified in the document.

The scope of the integrity protected data depends on the MAC flavor as discussed in the following sub-sections.

8.1. MAC#1

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 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 and encrypt metadata.

8.2. MAC#2

SFFs can detect whether an illegitimate node has altered the content of the Base header. Such messages are discarded with appropriate logs and alarms generated.

This approach requires SFFs to have access to the shared key (which is used also for encrypting sensitive metadata). This may be undesired.

A dedicated key may be used for authenticating the Base header, while another key is used for the Service Path and Context Headers. Nevertheless, such approach will induce an overhead of multiple authentication tags.

9. IANA Considerations

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  | Sequence Number               | [ThisDocument] |
| TBD3  | MAC and Encrypted Metadata#1  | [ThisDocument] |
| TBD4  | MAC and Encrypted Metadata#2  | [ThisDocument] |
+-------+-------------------------------+----------------+

10. Acknowledgements

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 and Christian Jacquenet for the comments.

11. References

11.1. Normative References

11.2. Informative References

Appendix A. A Deployment Example with KMS

SFC-aware SFs do not share any credentials; instead, they trust a third party, the KMS, with which they have or can establish shared credentials. These pre-established trust relations are used to establish a security association between SFC data plane elements within the context of a given service chain.

The NSH imposer requests a secret key and key identifier from the KMS. The request message also includes identities of the SFC data plane elements (including SFC-aware SFs and SFC proxies) authorized to receive the keying material associated with the key identifier. Each SFC-aware SF is referenced using an SF identifier that is unique within an SFC-enabled domain. If the request is authorized, then KMS generates the secret key (K), key identifier (kid), and returns them in a response message. The key identifier may be self-contained (key encrypted in the key identifier) or just a handle to some internal data structure within the KMS.

The NSH imposer includes the key identifier in NSH data. The NSH data is protected using K and optionally metadata is encrypted using K. SFC-aware SFs and SFC proxies in the SFP forward the key identifier to the KMS and request the KMS to retrieve the keying material. If the SFC data plane element is authorized and the key identifier is valid, then the KMS retrieves the secret key and AEAD algorithm associated with the key identifier and conveys them to the SFC data plane element. The other alternative approach is that KMS implicitly pushes the keying material to, particularly, SFC-aware SFs and SFC proxies authorized by the NSH imposer.

If the NSH imposer requests a new key and a new key identifier from KMS, the request message from NSH imposer to KMS also includes identities of SFC-aware SFs and SFC proxies authorized to receive the keying material associated with the new key identifier. For subsequent packets, the new key identifier will be conveyed in the NSH data, NSH data will be integrity protected using the new secret key and optionally NSH metadata is encrypted using the new secret key.

Figure 7 shows an example of an NSH imposer requesting a secret key and key identifier from the KMS. The request message includes identifiers of SF1 and SF2 Service Functions authorized to receive keying material associated with the key identifier. KMS returns the secret key (K) and key identifier in the response message. The NSH imposer includes the key identifier in the NSH data. In this example, SF1 in the SFP forwards the key identifier to the KMS and requests the KMS for keying material associated with the key identifier (In key resolve request message). If SF1 is authorized and the key identifier is valid then KMS retrieves the key and AEAD algorithm associated with the key identifier and conveys them to the SF1 (In Resolve response message). Similarly, SF2 retrieves the keying material associated with the key identifier from KMS.

• Note: Update the example with the SFF

The exchange with KMS is not required if the necessary information is pre-provisonned to the authorized SFC-aware SFs and SFC proxies.

+----------------+            +-------+        +------+       +------+
|   NSH Imposer  |            |  KMS  |        | SF1  |       | SF2  |
+----+-----------+            +----+--+        +----+-+       +--+---+
     |                             |                |            |    
     |                             |                |            |    
     |   Key Request               |                |            |    
     +---------------------------->|                |            |    
     |                             |                |            |    
     |   Key Response              |                |            |    
     |<----------------------------+                |            |    
     |                             |                |            |    
     | Key Identifier sent in NSH  |                |            |    
     +--------------------------------------------->+----------->|    
     |                             |                |            |    
     |                             | Key Resolve    |            |    
     |                             |<---------------+            |    
     |                             |                |            |    
     |                             | Resolve response            |    
     |                             +--------------->|            |    
     |                             |                |            |    
     |                             | Key resolve    |            |    
     |                             |<----------------------------+    
     |                             | Resolve response            |    
     |                             +---------------------------->|    
     |                             |                |            | 

Figure 7: Example of Interactions with KMS

Authors' Addresses