Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Mohamed Boucadair , Tirumaleswar Reddy.K
Last updated 2019-10-31
Replaced by draft-ietf-sfc-nsh-integrity, RFC 9145
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rebo-sfc-nsh-integrity-00
SFC                                                         M. Boucadair
Internet-Draft                                                    Orange
Intended status: Standards Track                                T. Reddy
Expires: May 3, 2020                                              McAfee
                                                        October 31, 2019

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

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

Boucadair & Reddy          Expires May 3, 2020                  [Page 1]
Internet-Draft        Intgerity Protection for NSH          October 2019

Table of Contents

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

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 and
   protecting against ever increasing Denial-of-Service (DoS) attacks,
   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 ongoing 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

Boucadair & Reddy          Expires May 3, 2020                  [Page 2]
Internet-Draft        Intgerity Protection for NSH          October 2019

   selected as a result of 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 support such features (e.g., IPsec).
   The lack of such capability was reported during the development of
   [RFC8300] and [RFC8459].

   This specification fills that void.  Concretely, this document adds
   integrity protection and optional encryption directly to NSH
   (Section 4).  Thus, NSH data does not have to rely on 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
   (Section 6), and is hence only applicable to NSH MD Type 0x02 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:

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

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

   o  Key Identifier (or Ticket): A key identifier or kerberos like
      object used to identify and deliver keys to authorized entities.

   o  NSH imposer: Refers to the SFC data plane element that is entitled
      to impose NSH with the Context headers defined in this document.

Boucadair & Reddy          Expires May 3, 2020                  [Page 3]
Internet-Draft        Intgerity Protection for NSH          October 2019

      Such element may be a Classifier, an SFC-aware SF, an SFF, or an
      SFC proxy.

3.  Assumptions & Basic Requirements

   The NSH format is defined in Section 2 of [RFC8300]; the NSH data can
   be divided into three parts:

   o  Base Header: Provides information about the service header and the
      payload protocol.

   o  Service Path Header: Provides path identification and location
      within a service path.

   o  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:

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

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

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

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

   o  The SFC proxy may also be instructed to add some new context
      information into the NSH header on behalf of an SFC-unaware SF.

   o  The control plane is assumed to instruct the classifier, SFC-aware
      SFs, and SFC proxy the set of context headers (privacy-sensitive
      metadata, typically) that must be encrypted.  The control plane

Boucadair & Reddy          Expires May 3, 2020                  [Page 4]
Internet-Draft        Intgerity Protection for NSH          October 2019

      may also indicate the set of SFC data plane element 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 conveyed to the appropriate SFC data plane elements,
   nor to detail the structure used to store the instructions.

   In reference to Figure 1,

   o  Classifiers, SFC-aware SFs, and SFC proxies are entitled to update
      context header: Only these elements must be able to encrypt and
      decrypt a supplied context header.

   o  All SFC data plane elements are entitled to modify the context of
      the Base and Service Path headers (e.g., SI, TTL).  The solution
      must also provide integrity protection for these two headers.

         +---------------+-----------------------+---------------+
         |               | 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 in the document does not make any assumption about the
   service chains to be instantiated nor adds constraints to how NSH can
   be used within a domain.  For example, in reference to Figure 2, the
   solution accommodates deployment schemes such as:

Boucadair & Reddy          Expires May 3, 2020                  [Page 5]
Internet-Draft        Intgerity Protection for NSH          October 2019

   o  No metadata is inserted by the classifier: it only proceeds with
      integrity protection.

   o  SF1 inserts two metadata M1 and M2 that its encrypts.

   o  SF2 decrypts M1 and M2, strips M2, and then encrypts M1

   o  SF3 decrypts M1 and then strips it.

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

                   Figure 2: SFC-enabled Domain Example

4.  Solution Overview

   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 element 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, a nonce, a plaintext, and
   "additional data" to be included in the authentication check, as
   described in Section 2.1 of [RFC5116].

   AEAD functions provide a unified encryption and authentication
   operation which turns plaintext into authenticated ciphertext and
   back again.  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 an amount that varies with the AEAD algorithm.

   In order to decrypt and verify, the cipher takes as input the key,
   nonce, additional data, and the ciphertext.  The output is either the
   plaintext or an error indicating that the decryption failed.

   The procedure for establishment of the secret key and AEAD algorithm
   is outside the scope of this specification.  As such, this
   specification does not mandate support of any given mechanism.

   A (non-normative) sample deployment case is provided in Appendix A.
   Gene

Boucadair & Reddy          Expires May 3, 2020                  [Page 6]
Internet-Draft        Intgerity Protection for NSH          October 2019

5.  Mandatory to Implement AEAD Algorithms

   Classifiers, SFC-aware SFs, SFFs, 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.

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 encrypting certain number of NSH data, key identifier helps
   address 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:

   o  Metadata Class: MUST be set to 0x0 [RFC8300].

   o  Type: TBD1 (See Section 9)

   o  Length: Variable.

   o  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

Boucadair & Reddy          Expires May 3, 2020                  [Page 7]
Internet-Draft        Intgerity Protection for NSH          October 2019

   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:

   o  Metadata Class: MUST be set to 0x0 [RFC8300].

   o  Type: TBD2 (See Section 9)

   o  Length: 8 bytes

   o  Sequence Number: Carries the sequence number.

6.3.  MAC and Encrypted Metadata Context Header

   MAC and Encrypted Metadata Context Header is a variable-length TLV
   that carries the Message Authentication Code (MAC) for the entire NSH
   calculated using K and optionally metadata encrypted K.

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

   The description of the fields is as follows:

   o  Metadata Class: MUST be set to 0x0 [RFC8300].

Boucadair & Reddy          Expires May 3, 2020                  [Page 8]
Internet-Draft        Intgerity Protection for NSH          October 2019

   o  Type: TBD3 (See Section 9)

   o  Nonce Length: Carries the length of the nonce (Section 4 of
      [RFC5116]).

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

   o  Message Authentication Code and optional Encrypted Metadata

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 the
   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 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 maintain that
   data 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, ...

Boucadair & Reddy          Expires May 3, 2020                  [Page 9]
Internet-Draft        Intgerity Protection for NSH          October 2019

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 imposer
   computes the message integrity for the entire NSH data 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 do the above 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 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |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 3: 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].

Boucadair & Reddy          Expires May 3, 2020                 [Page 10]
Internet-Draft        Intgerity Protection for NSH          October 2019

   Using K and AEAD algorithm, the NSH imposer encrypts 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 will be 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 do the above.

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 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 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 on a key identifier if doing so 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 message with encrypted
   metadata, it MUST first ensure that all mandatory TLVs required for
   NSH data integrity exist.  It MUST discard the message, if mandatory
   TLVs are absent or if the sequence number is invalid (described in
   Section 7.4).  The node should then proceed with data validation.
   The SFC data plane element computes the message integrity for the
   entire NSH data 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

Boucadair & Reddy          Expires May 3, 2020                 [Page 11]
Internet-Draft        Intgerity Protection for NSH          October 2019

   certain that the header has not been tampered and validation
   succeeds.  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 is at risk from four primary attacks:

   o  A man-in-the-middle attacker modifying NSH data.

   o  Attacker spoofing NSH data.

   o  Attacker capturing and replaying NSH data.

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

   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.

Boucadair & Reddy          Expires May 3, 2020                 [Page 12]
Internet-Draft        Intgerity Protection for NSH          October 2019

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

11.  References

11.1.  Normative References

   [GCM]      Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC",
              NIST Special Publication 800-38D, November 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Boucadair & Reddy          Expires May 3, 2020                 [Page 13]
Internet-Draft        Intgerity Protection for NSH          October 2019

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
              <https://www.rfc-editor.org/info/rfc8439>.

11.2.  Informative References

   [AEAD-LIMITS]
              Luykx, A. and K. Paterson, "Limits on Authenticated
              Encryption Use in TLS", 2016,
              <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.

   [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,
              <https://www.rfc-editor.org/info/rfc6973>.

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

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <https://www.rfc-editor.org/info/rfc7498>.

   [RFC8459]  Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
              DOI 10.17487/RFC8459, September 2018,
              <https://www.rfc-editor.org/info/rfc8459>.

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.

Boucadair & Reddy          Expires May 3, 2020                 [Page 14]
Internet-Draft        Intgerity Protection for NSH          October 2019

   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 data plane elements 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 the SFC data plane elements (including 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 4 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.

Boucadair & Reddy          Expires May 3, 2020                 [Page 15]
Internet-Draft        Intgerity Protection for NSH          October 2019

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

                Figure 4: Example of Interactions with KMS

Authors' Addresses

   Mohamed Boucadair
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

   Tirumaleswar Reddy
   McAfee, Inc.
   Embassy Golf Link Business Park
   Bangalore, Karnataka  560071
   India

   Email: TirumaleswarReddy_Konda@McAfee.com

Boucadair & Reddy          Expires May 3, 2020                 [Page 16]