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

Abstract

   This specification adds integrity protection and optional encryption
   of sensitive metadata 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 23, 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



Boucadair, et al.         Expires May 23, 2020                  [Page 1]


Internet-Draft        Integrity Protection for NSH         November 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Assumptions & Basic Requirements  . . . . . . . . . . . . . .   4
   4.  Design Overview . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Supported Security Services . . . . . . . . . . . . . . .   7
       4.1.1.  Encrypt All or a Subset of Context Headers  . . . . .   7
       4.1.2.  Integrity Protection  . . . . . . . . . . . . . . . .   8
     4.2.  One Secret Key, Two Security Services . . . . . . . . . .   9
     4.3.  Mandatory-to-Implement Authenticated Encryption and HMAC
           Algorithms  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Key Management  . . . . . . . . . . . . . . . . . . . . .  11
     4.5.  New NSH Variable-Length Context Headers . . . . . . . . .  11
     4.6.  Encapsulation of NSH within NSH . . . . . . . . . . . . .  12
   5.  New NSH Variable-Length Context Headers . . . . . . . . . . .  12
     5.1.  Key Identifier Context Header . . . . . . . . . . . . . .  12
     5.2.  Timestamp Context Header  . . . . . . . . . . . . . . . .  13
     5.3.  MAC and Encrypted Metadata Context Header . . . . . . . .  14
       5.3.1.  MAC#1 Context Header  . . . . . . . . . . . . . . . .  14
       5.3.2.  MAC#2 Context Header  . . . . . . . . . . . . . . . .  16
   6.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .  18
     6.1.  Generic Behavior  . . . . . . . . . . . . . . . . . . . .  18
     6.2.  MAC NSH Data Generation . . . . . . . . . . . . . . . . .  19
     6.3.  Encrypted NSH Metadata Generation . . . . . . . . . . . .  19
     6.4.  Timestamp for Replay Attack . . . . . . . . . . . . . . .  21
     6.5.  NSH Data Validation . . . . . . . . . . . . . . . . . . .  21
     6.6.  Decryption of NSH Metadata  . . . . . . . . . . . . . . .  22
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
     7.1.  MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . .  23
     7.2.  MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     10.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

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



Boucadair, et al.         Expires May 23, 2020                  [Page 2]


Internet-Draft        Integrity Protection for NSH         November 2019


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

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



Boucadair, et al.         Expires May 23, 2020                  [Page 3]


Internet-Draft        Integrity Protection for NSH         November 2019


   The document defines the following terms:

   o  SFC data plane 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: A key identifier or kerberos-like object used to
      identify and deliver keys to authorized entities.

   o  NSH data: The NSH is composed of a Base Header, a Service Path
      Header, and optional Context Headers.  NSH data refers to all the
      above headers and the packet or frame on which NSH is imposed to
      realize a Service Function Path (SFP).

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

   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 Function Path (SFP).

   o  Context Header(s): 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




Boucadair, et al.         Expires May 23, 2020                  [Page 4]


Internet-Draft        Integrity Protection for NSH         November 2019


      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,

   o  Classifiers, SFC-aware SFs, and SFC proxies are entitled to update
      the Context Header(s).

      Only these elements MUST be able to encrypt and decrypt a supplied
      Context Header.

   o  Only SFC-aware SFs and SFC proxies are entitled to update the
      Service Path Header.

      The solution MUST provide integrity protection for this header.

   o  SFFs are entitled to modify the Base Path header (TTL value, for
      example).  Nevertheless, SFFs are not supposed to act on the
      Context Headers or look into the content of the Context Headers.

      The solution MAY provide integrity protection for the Base Header.
      The implications of disabling such checks are discussed in
      Section 7.1.

         Discussion Note: This design decision should be discussed with
         the working group.












Boucadair, et al.         Expires May 23, 2020                  [Page 5]


Internet-Draft        Integrity Protection for NSH         November 2019


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

   o  No Context Header is inserted by the Classifier: it only proceeds
      with the NSH integrity protection.  The NSH encapsulated packet is
      then forwarded to the next hop following [RFC7665].

   o  Once the packet is received by SF1, and assuming integrity checks
      succeed, SF1 inserts two Context Headers M1 and M2 that it
      encrypts and recomputes the message integrity for the NSH data.

   o  Once the packet is received by SF2, and assuming integrity checks
      succeed, SF2 decrypts M1 and M2, strips M2 (because its instructed
      to do so via the SFC control plane), and then encrypts M1 and
      recomputes the message integrity for the NSH data.




Boucadair, et al.         Expires May 23, 2020                  [Page 6]


Internet-Draft        Integrity Protection for NSH         November 2019


   o  Once the packet is received by SF3, and assuming integrity checks
      succeed, SF3 decrypts M1, consumes the decrypted M1 data, and then
      strips it from the NSH.  The packet is then forwarded back to SFF3
      by SF3 after recomputing the message integrity for the NSH data.

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

                   Figure 2: SFC-enabled Domain Example

4.  Design Overview

4.1.  Supported Security Services

   This specification provides the functions described in the following
   sub-sections:

4.1.1.  Encrypt All or a Subset of Context Headers

   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      | Base and Service Headers     | Metadata         |
   | Element         | Encryption                   | Encryption       |
   +-----------------+------------------------------+------------------+
   | Classifier      | No                           | Yes              |
   | SFF             | No                           | No               |
   | SFC-aware SF    | No                           | Yes              |
   | SFC Proxy       | No                           | Yes              |
   | SFC-unaware SF  | No                           | No               |
   +-----------------+------------------------------+------------------+

     Table 1: Encryption Function Supported by SFC Data Plane Elements

   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.




Boucadair, et al.         Expires May 23, 2020                  [Page 7]


Internet-Draft        Integrity Protection for NSH         November 2019


   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.

4.1.2.  Integrity Protection

   The solution provides integrity protection for NSH data.  Two flavors
   are supported.

   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.

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









Boucadair, et al.         Expires May 23, 2020                  [Page 8]


Internet-Draft        Integrity Protection for NSH         November 2019


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

    Table 2: Integrity Protection Supported by SFC Data Plane Elements

4.2.  One Secret Key, Two Security Services

   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



Boucadair, et al.         Expires May 23, 2020                  [Page 9]


Internet-Draft        Integrity Protection for NSH         November 2019


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

4.3.  Mandatory-to-Implement Authenticated Encryption and HMAC
      Algorithms

   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.





Boucadair, et al.         Expires May 23, 2020                 [Page 10]


Internet-Draft        Integrity Protection for NSH         November 2019


4.4.  Key Management

   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:

   o  The same keying material is used for all the service functions
      used within an SFC-enabled domain.

   o  Distinct keying material is used per SFP.

   o  Per-tenant keys are used.

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

4.5.  New NSH Variable-Length Context Headers

   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.



Boucadair, et al.         Expires May 23, 2020                 [Page 11]


Internet-Draft        Integrity Protection for NSH         November 2019


4.6.  Encapsulation of NSH within NSH

   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.

5.  New NSH Variable-Length Context Headers

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

5.1.  Key Identifier Context Header

   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.



Boucadair, et al.         Expires May 23, 2020                 [Page 12]


Internet-Draft        Integrity Protection for NSH         November 2019


   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:

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

   o  Type: TBD1 (See Section 8)

   o  U: Unassigned bit [RFC8300].

   o  Length: Variable.

   o  Key Identifier: Carries the key identifier.

5.2.  Timestamp Context Header

   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:

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

   o  Type: TBD2 (See Section 8)



Boucadair, et al.         Expires May 23, 2020                 [Page 13]


Internet-Draft        Integrity Protection for NSH         November 2019


   o  U: Unassigned bit [RFC8300].

   o  Length: 8 bytes

   o  Timestamp: Carries an unsigned 64-bit integer value that is
      expressed in seconds relative to 1970-01-01T00:00Z in UTC time.

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

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




Boucadair, et al.         Expires May 23, 2020                 [Page 14]


Internet-Draft        Integrity Protection for NSH         November 2019


    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:

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

   o  Type: TBD3 (See Section 8)

   o  U: Unassigned bit [RFC8300].

   o  Length: Variable.

   o  IV Length: Carries the length of the IV (Section 5.2 of
      [RFC7518]).  If HMAC algorithm is used, IV length is set to zero.





Boucadair, et al.         Expires May 23, 2020                 [Page 15]


Internet-Draft        Integrity Protection for NSH         November 2019


   o  Initialization Vector: Carries the IV for authenticated encryption
      algorithm as discussed in Section 5.2 of [RFC7518].

   o  The Additional Authenticated Data (defined in [RFC7518]) MUST be
      the Service Path header, the unencrypted Context headers, and the
      inner packet on which NSH is imposed .

   o  Message Authentication Code covering the entire NSH data excluding
      the Base header.

5.3.2.  MAC#2 Context Header

   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.



































Boucadair, et al.         Expires May 23, 2020                 [Page 16]


Internet-Draft        Integrity Protection for NSH         November 2019


    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:

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

   o  Type: TBD4 (See Section 8)

   o  U: Unassigned bit [RFC8300].

   o  Length: Variable.

   o  IV Length: Carries the length of the IV (Section 5.2 of
      [RFC7518]).  If HMAC algorithm is used, IV length is set to zero.




Boucadair, et al.         Expires May 23, 2020                 [Page 17]


Internet-Draft        Integrity Protection for NSH         November 2019


   o  Initialization Vector: Carries the IV for authenticated encryption
      algorithms as discussed in Section 5.2 of [RFC7518].

   o  The Additional Authenticated Data (defined in [RFC7518]) MUST be
      the entire NSH data (i.e., including the Base Header) excluding
      the Context Headers to be encrypted.

   o  Message Authentication Code covering the entire NSH data and
      optional encrypted Context Headers.

6.  Processing Rules

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

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



Boucadair, et al.         Expires May 23, 2020                 [Page 18]


Internet-Draft        Integrity Protection for NSH         November 2019


   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.

6.2.  MAC NSH Data Generation

   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.

6.3.  Encrypted NSH Metadata Generation

   An NSH imposer can encrypt Context Headers carrying privacy-sensitive
   metadata, i.e., encrypted and unencrypted metadata may be carried
   simultaneously (Figure 11).










Boucadair, et al.         Expires May 23, 2020                 [Page 19]


Internet-Draft        Integrity Protection for NSH         November 2019


        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






Boucadair, et al.         Expires May 23, 2020                 [Page 20]


Internet-Draft        Integrity Protection for NSH         November 2019


   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.

6.4.  Timestamp for Replay Attack

   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.

   o  TODO: timestamp validation on the receiver needs further text
      refinement.

6.5.  NSH Data Validation

   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



Boucadair, et al.         Expires May 23, 2020                 [Page 21]


Internet-Draft        Integrity Protection for NSH         November 2019


   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.

6.6.  Decryption of NSH Metadata

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

7.  Security Considerations

   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:

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




Boucadair, et al.         Expires May 23, 2020                 [Page 22]


Internet-Draft        Integrity Protection for NSH         November 2019


   o  Attacker spoofing NSH data.

   o  Attacker capturing and replaying NSH data.

   o  Metadata in Context Headers revealing privacy-sensitive
      information to attackers.

   o  Attacker replacing the packet on which NSH is imposed with a bogus
      or malicious packet.

   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.

7.1.  MAC#1

   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.

7.2.  MAC#2

   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.

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



Boucadair, et al.         Expires May 23, 2020                 [Page 23]


Internet-Draft        Integrity Protection for NSH         November 2019


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

9.  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, Christian Jacquenet, and Dirk von Hugo for
   the comments.

10.  References

10.1.  Normative References

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

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
              June 2005, <https://www.rfc-editor.org/info/rfc4107>.

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

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/info/rfc7518>.

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




Boucadair, et al.         Expires May 23, 2020                 [Page 24]


Internet-Draft        Integrity Protection for NSH         November 2019


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

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

10.2.  Informative References

   [I-D.arkko-arch-internet-threat-model]
              Arkko, J., "Changes in the Internet Threat Model", draft-
              arkko-arch-internet-threat-model-01 (work in progress),
              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,
              <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>.

Authors' Addresses

   Mohamed Boucadair
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com







Boucadair, et al.         Expires May 23, 2020                 [Page 25]


Internet-Draft        Integrity Protection for NSH         November 2019


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

   Email: TirumaleswarReddy_Konda@McAfee.com


   Dan Wing
   Citrix Systems, Inc.
   USA

   Email: dwing-ietf@fuggles.com





































Boucadair, et al.         Expires May 23, 2020                 [Page 26]