<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-sfc-nsh-integrity-09"
     ipr="trust200902"> number="9145"  ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" consensus="true" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Integrity Protection for the NSH">Integrity Protection for
    the Network Service Header (NSH) and Encryption of Sensitive Context
    Headers</title>
    <seriesInfo name="RFC" value="9145"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Tirumaleswar Reddy" Reddy.K" initials="T." surname="Reddy"> surname="Reddy.K">
      <organization>Akamai</organization>
      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560071</code>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Citrix">Citrix Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <country>USA</country>
        </postal>
        <email>dwing-ietf@fuggles.com</email>
      </address>
    </author>
    <date /> month="December" year="2021"/>
    <workgroup>SFC</workgroup>
    <keyword>Security</keyword>
    <keyword>Resilience</keyword>
    <keyword>Automation</keyword>
    <keyword>Service delivery</keyword>
    <keyword>Providers</keyword>
    <keyword>Differentiated services</keyword>
    <keyword>Traffic Engineering</keyword>
    <keyword>Attack mitigation</keyword>
    <abstract>
      <t>This specification presents an optional method to add integrity
      protection directly to the Network Service Header (NSH) used for Service
      Function Chaining (SFC). Also, this specification allows for the
      encryption of sensitive metadata (MD) that is carried in the NSH.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Many advanced Service Functions (SFs) are enabled for the delivery of
      value-added services. Typically, SFs are used to meet various service
      objectives such as IP address sharing, avoiding covert channels,
      detecting Denial-of-Service (DoS) attacks and protecting network
      infrastructures against them, network slicing, etc. Because of the
      proliferation of such advanced SFs together with complex service
      deployment constraints that demand more agile service delivery
      procedures, operators need to rationalize their service delivery logic
      and control its complexity while optimising optimizing service activation time
      cycles. The overall problem space is described in <xref
      target="RFC7498"></xref>.</t> target="RFC7498" format="default"/>.</t>
      <t><xref target="RFC7665"></xref> target="RFC7665" format="default"/> presents a data plane
      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 (SFCs) within a network. That
      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. <xref target="RFC8300"></xref> target="RFC8300" format="default"/>
      specifies the SFC encapsulation: Network Service Header (NSH).</t>
      <t>The NSH data is unauthenticated and unencrypted, forcing a service
      topology that requires security and privacy to use a transport
      encapsulation that supports such features (Section 8.2 of <xref
      target="RFC8300"></xref>).</t> (<xref target="RFC8300" section="8.2" sectionFormat="of"/>).</t>
      <t>Note that some transport encapsulations (e.g., IPsec) only provide
      hop-by-hop security between two SFC data plane elements (e.g., two
      Service Function Forwarders (SFFs), SFF to SF) and do not provide
      SF-to-SF security of NSH metadata. For example, if IPsec is used, SFFs
      or SFs within a Service Function Path (SFP) that are not authorized to
      access the sensitive metadata (e.g., privacy-sensitive information) will
      have access to the metadata. As a reminder, the metadata referred to is
      information that is inserted by Classifiers or intermediate SFs and
      shared with downstream SFs; such information is not visible to the
      communication endpoints (Section 4.9 of <xref
      target="RFC7665"></xref>).</t> (<xref target="RFC7665" section="4.9"
      sectionFormat="of"/>).</t>
      <t>The lack of such capability was reported during the development of
      <xref target="RFC8300"></xref> target="RFC8300" format="default"/> and <xref target="RFC8459"></xref>. target="RFC8459"
      format="default"/>. The reader may refer to Section 3.2.1 of <xref
      target="I-D.arkko-farrell-arch-model-t"></xref>
      target="I-D.arkko-farrell-arch-model-t" section="3.2.1"
      sectionFormat="of"/> for a discussion on the need for more awareness
      about attacks from within closed domains.</t>
      <t>This specification fills that gap for SFC (that is, it defines the
      "NSH Variable Header-Based Integrity" option mentioned in Section 8.2.1
      of <xref target="RFC8300"></xref>).
      target="RFC8300" section="8.2.1" sectionFormat="of"/>). Concretely, this
      document adds integrity protection and optional encryption of sensitive
      metadata directly to the NSH (<xref target="overview"></xref>). target="overview"
      format="default"/>). The integrity protection covers the packet payload
      and provides replay protection (<xref target="time"></xref>). target="time"
      format="default"/>). Thus, the NSH does not have to rely upon an
      underlying transport encapsulation for security.</t>
      <t>This specification introduces new Variable-Length Context Headers to
      carry fields necessary for integrity-protected NSH headers and encrypted
      Context Headers (<xref target="new"></xref>). target="new" format="default"/>). This
      specification is only applicable to NSH MD Type 0x02 (Section 2.5 of <xref
      target="RFC8300"></xref>). (<xref
      target="RFC8300" section="2.5" sectionFormat="of"/>). MTU considerations
      are discussed in <xref
      target="MTU"></xref>. target="MTU" format="default"/>. This
      specification is not applicable to NSH MD Type 0x01 (Section 2.4 of <xref target="RFC8300"></xref>) (<xref
      target="RFC8300" section="2.4" sectionFormat="of"/>) because that MD
      Type only allows a Fixed-Length Context Header whose size is
      16-bytes; 16 bytes;
      that is not sufficient to accommodate both the metadata and message
      integrity of the NSH data.</t>
      <t>This specification limits access to NSH-supplied information along an
      SFP to entities that have a need to interpret it.</t>
      <t>The mechanism specified in this document does not preclude the use of
      transport security. Such considerations are deployment-specific.</t> deployment specific.</t>
      <t>It is out of the scope of this document to specify an NSH-aware
      control plane solution.</t>
    </section>
    <section anchor="notation" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
      NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
      to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"
      format="default"/> <xref target="RFC8174"></xref> target="RFC8174" format="default"/> when, and
      only when, they appear in all capitals, as shown here.</t>

      <t>This document makes use of the terms defined in <xref
      target="RFC7665"></xref>
      target="RFC7665" format="default"/> and <xref target="RFC8300"></xref>. target="RFC8300"
      format="default"/>. The term "transport encapsulation" used in this
      document refers to the outer encapsulation (e.g., Generic Routing
      Encapsulation (GRE), IPsec, and Generic Protocol Extension for VXLAN Virtual
      eXtensible Local Area Network (VXLAN-GPE)) that is used to carry
      NSH-encapsulated packets as per Section 4 of <xref
      target="RFC8300"></xref>.</t> target="RFC8300" section="4"
      sectionFormat="of"/>.</t>

      <t>The document defines the following terms:<list style="hanging">
          <t hangText="SFC terms:</t>
      <dl newline="false" spacing="normal">
        <dt>SFC data plane element:">Refers element:</dt>
        <dd>Refers to NSH-aware SF, SFF,
          the SFC Proxy, or the Classifier as defined in the SFC data plane
          architecture <xref target="RFC7665"></xref> target="RFC7665" format="default"/> and further refined in
          <xref target="RFC8300"></xref>.</t>

          <t hangText="SFC target="RFC8300" format="default"/>.</dd>
        <dt>SFC control element:">Is element:</dt>
        <dd>Is a logical entity that
          instructs one or more SFC data plane elements on how to process NSH
          packets within an SFC-enabled domain.</t>

          <t hangText="Key Identifier:">Is domain.</dd>
        <dt>Key Identifier:</dt>
        <dd>Is used to identify keys to authorized entities. See, for example, 'kid'
        "kid" usage in <xref
          target="RFC7635"></xref>.</t>

          <t hangText="NSH data:">The target="RFC7635" format="default"/>.</dd>
        <dt>NSH data:</dt>
        <dd>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 the NSH is
          imposed to realize an SFP.</t>

          <t hangText="NSH imposer:">Refers SFP.</dd>
        <dt>NSH imposer:</dt>
        <dd>Refers to an SFC data plane element that
          is entitled to impose the NSH with the Context Headers defined in
          this document.</t>
        </list></t> document.</dd>
      </dl>
    </section>
    <section anchor="req" title="Assumptions numbered="true" toc="default">
      <name>Assumptions and Basic Requirements">
      <t>Section 2 of <xref target="RFC8300"></xref> Requirements</name>
      <t><xref target="RFC8300" section="2" sectionFormat="of"/> specifies that the NSH
      data can be spread over three headers:<list style="symbols">
          <t>Base headers:</t>

      <dl>

	<dt>Base Header: Provides
	</dt>
	<dd>Provides information about the service header and the payload protocol.</t>

          <t>Service protocol.
	</dd>

	<dt>Service Path Header: Provides
	</dt>
	<dd>Provides path identification and location within an SFP.</t>

          <t>Context SFP.
	</dd>

	<dt>Context Header(s): Carries
	</dt>
	<dd>Carries metadata (i.e., context data) along a service path.</t>
        </list></t> path.
	</dd>

      </dl>

      <t>The NSH allows sharing context information (a.k.a., (a.k.a. metadata) with
      downstream NSH-aware data plane elements on a per SFC/SFP per-SFC/SFP basis. To that
      aim:<list style="empty">
          <t>The
      aim:</t>
      <ul spacing="normal">
        <li>The Classifier is instructed by an SFC control element about the
          set of context information to be supplied for a given service
          function chain.</t>

          <t>An chain.</li>
        <li>An NSH-aware SF is instructed by an SFC control element about any
          metadata it needs to attach to packets for a given service function
          chain. This instruction may occur any time during the validity
          lifetime of an SFC/SFP. For a given service function chain, the
          NSH-aware SF is also provided with an order for consuming a set of
          contexts supplied in a packet.</t>

          <t>An packet.</li>
        <li>An NSH-aware SF can also be instructed by an SFC control element
          about the behavior it should adopt after consuming context
          information that was supplied in the NSH. For example, the context
          information can be maintained, updated, or stripped.</t>

          <t>An stripped.</li>
        <li>An SFC Proxy may be instructed by an SFC control element about
          the behavior it should adopt to process the context information that
          was supplied in the NSH on behalf of an NSH-unaware SF (e.g., the
          context information can be maintained or stripped). The SFC Proxy
          may also be instructed to add some new context information into the
          NSH on behalf of an NSH-unaware SF.</t>
        </list></t> SF.</li>
      </ul>
      <t>In reference to Table 1, <list style="symbols">
          <t>Classifiers, <xref target="NSH"/>:</t>
      <ul spacing="normal">
        <li>Classifiers, NSH-aware SFs, and SFC proxies are entitled to
          update the Context Header(s).</t>

          <t>Only Header(s).</li>
        <li>Only NSH-aware SFs and SFC proxies are entitled to update the
          Service Path Header.</t>

          <t>SFFs Header.</li>
        <li>SFFs are entitled to modify the Base 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 (Section 4.3
          of <xref target="RFC7665"></xref>).</t>
        </list></t> (<xref target="RFC7665" section="4.3" sectionFormat="of"/>).</li>
      </ul>
      <t>Thus, the following requirements:<list style="symbols">
          <t>Only requirements:</t>
      <ul spacing="normal">
        <li>Only Classifiers, NSH-aware SFs, and SFC proxies must be able to
          encrypt and decrypt a given Context Header.</t>

          <t>Both Header.</li>
        <li>Both encrypted and unencrypted Context Headers may be included in
          the same NSH.</t>

          <t>The NSH.</li>
        <li>The solution must provide integrity protection for the Service
          Path Header.</t>

          <t>The Header.</li>
        <li>The solution must provide optional integrity protection for the
          Base Header. The implications of disabling such checks are discussed
          in <xref target="mac1"></xref>.</t>
        </list></t>

      <t><figure align="center">
          <artwork align="center"><![CDATA[+----------------+-----------------------------+-------------------+
|                | Insert, target="mac1" format="default"/>.</li>
      </ul>

      <table anchor="NSH">
	<name>Summary of NSH Actions</name>
	<thead>
	  <tr>
	    <th rowspan="2" colspan="1" align="center">SFC Data Plane Element</th>
	    <th colspan="3" align="center">Insert, remove, or replace  |  Update the NSH   |
|                | the NSH            |                   |
|                |                             |                   |
| SFC Data Plane +---------+---------+---------+---------+---------+
|   Element      |         |         |         |Decrement| Update  |
|                | Insert  | Remove  | Replace | NSH</th>
	    <th colspan="2" align="center">Update the NSH</th>
	  </tr>
	  <tr >
	    <th align="center">Insert</th>
	      <th align="center">Remove</th>
	      <th align="center">Replace</th>
	      <th align="center">Decrement Service | Context |
|                |         |         |         |  Index  |Header(s)|
+================+=========+=========+=========+=========+=========+
|                |    +    |         |    +    |         |    +    |
|   Classifier   |         |         |         |         |         |
+----------------+---------+---------+---------+---------+---------+
|Service Function|         |    +    |         |         |         |
|Forwarder (SFF) |         |         |         |         |         |
+----------------+---------+---------+---------+---------+---------+
|Service Function|         |         |         |    +    |    +    |
|      (SF)      |         |         |         |         |         |
+----------------+---------+---------+---------+---------+---------+
|                |    +    |    +    |         |    +    |    +    |
|   SFC Proxy    |         |         |         |         |         |
+----------------+---------+---------+---------+---------+---------+

                     Table 1: Summary of NSH Actions]]></artwork>
        </figure></t>

      <t></t> Index</th>
	      <th align="center">Update Context Header(s)</th>

	  </tr>

	</thead>
	<tbody>
	  <tr>
	    <td>Classifier</td>
	    <td align="center">+</td>
	    <td></td>
	    <td align="center">+</td>
	    <td></td>
	    <td align="center">+</td>
	  </tr>

	  <tr>
	    <td>Service Function Forwarder (SFF)</td>
	    <td></td>
	    <td align="center">+</td>
	    <td></td>
	    <td></td>
	    <td></td>
	  </tr>

	  <tr>
	    <td>Service Function (SF)</td>
	    <td></td>
	    <td></td>
	    <td></td>
	    <td align="center">+</td>
	    <td align="center">+</td>
	  </tr>

	  <tr>
	    <td>Service Function Chaining (SFC) Proxy</td>
	    <td align="center">+</td>
	    <td align="center">+</td>
	    <td></td>
	    <td align="center">+</td>
	    <td align="center">+</td>
	  </tr>
	</tbody>
	</table>

    </section>
    <section anchor="overview" title="Design Overview">
      <t></t> numbered="true" toc="default">
      <name>Design Overview</name>

      <section title="Supported numbered="true" toc="default">
        <name>Supported Security Services"> Services</name>
        <t>This specification provides the functions described in the
        following subsections.</t>
        <section title="Encrypt numbered="true" toc="default">
          <name>Encrypt All or a Subset of Context Headers"> Headers</name>
          <t>The solution allows encrypting all or a subset of NSH Context
          Headers by Classifiers, NSH-aware SFs, and SFC proxies.</t>
          <t>As depicted in Table 2, <xref target="encryption"/>, SFFs are not involved in data
          encryption.</t>

          <t><figure>
              <artwork><![CDATA[   +-----------------+------------------------------+------------------+
   |

	  <table anchor="encryption">
	    <name>Encryption Function Supported by SFC Data Plane      | Elements</name>
	    <thead>
	      <tr>
	      <th> Data Plane Element</th>
	      <th> Base and Service Path        | Context Header   |
   | Element         | Headers Encryption           | Encryption       |
   +-----------------+------------------------------+------------------+
   | Classifier      | No                           | Yes              |
   | SFF             | No                           | No               |
   | Encryption</th>
	      <th>Context Header Encryption</th>
	    </tr>
	    </thead>

	  <tbody>
	  <tr>
	    <td>Classifier</td>
	    <td>No</td><td>Yes</td>
	    </tr><tr>

	    <td>SFF</td>
	    <td>No</td>
	    <td>No</td>
	    </tr><tr>

	    <td> NSH-aware SF    | No                           | Yes              |
   | SFC Proxy       | No                           | Yes              |
   | NSH-unaware SF  | No                           | SF</td>
	    <td>No</td>
	    <td>Yes</td>
	    </tr><tr>

	    <td>SFC Proxy</td>
	    <td> No               |
   +-----------------+------------------------------+------------------+

     Table 2: Encryption Function Supported by SFC Data Plane Elements]]></artwork>
            </figure></t> </td><td>Yes</td>
	    </tr><tr>

	    <td>NSH-unaware SF</td>
	    <td>No</td>
	    <td>No</td>
	  </tr>
	</tbody>
      </table>

          <t>Classifier(s), NSH-aware SFs, and SFC proxies are instructed with
          the set of Context Headers (privacy-sensitive metadata, typically)
          that must be encrypted. Encryption keying material is only provided
          to these SFC data plane elements.</t>
          <t>The control plane may 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,
          elements nor to detail the structure used to store the
          instructions.</t>
          <t>The Service Path Header (Section 2 of <xref
          target="RFC8300"></xref>) (<xref target="RFC8300" section="2" sectionFormat="of"/>) is not encrypted because SFFs use the Service
          Index (SI) in conjunction with the Service Path Identifier (SPI) for
          determining the next SF in the path.</t>
        </section>

	<section title="Integrity Protection"> numbered="true" toc="default">
          <name>Integrity Protection</name>
          <t>The solution provides integrity protection for the NSH data. Two
          levels of assurance (LoAs) are supported.</t>
          <t>The first level of assurance is where all NSH data except the
          Base Header are integrity protected (<xref target="first"></xref>). target="first" format="default"/>).
          In this case, the NSH imposer may be a Classifier, an NSH-aware SF,
          or an SFC Proxy. SFFs are not provided with authentication material.
          Further details are discussed in <xref target="enc1"></xref>.<figure
              align="center" anchor="first" title="First target="enc1" format="default"/>.</t>
          <figure anchor="first">
            <name>First Level of Assurance"> Assurance</name>

            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Transport Encapsulation                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
   |                Base Header                            |  |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N
|  |                Service Path Header                    |  S
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  H
|  |                Context Header(s)                      |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|  |                Original Packet                        |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+------Scope of integrity protected integrity-protected data
]]></artwork>
            </figure></t>
          </figure>
          <t>The second level of assurance is where all NSH data, including
          the Base Header, are integrity protected (<xref
          target="sec"></xref>). target="sec" format="default"/>). In this case, the NSH imposer may be a
          Classifier, an NSH-aware SF, an SFF, or an SFC Proxy. Further
          details are provided in <xref target="enc2"></xref>.</t>

          <t><figure align="center" anchor="sec"
              title="Second target="enc2" format="default"/>.</t>
          <figure anchor="sec">
            <name>Second Level of Assurance"> Assurance</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Transport Encapsulation                |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|  |                Base Header                            |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  N
|  |                Service Path Header                    |  S
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  H
|  |                Context Header(s)                      |  |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|  |                Original Packet                        |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+----Scope of integrity protected integrity-protected data

]]></artwork>
            </figure></t>
          </figure>
          <t>The integrity protection integrity-protection scope is explicitly signaled to
          NSH-aware SFs, SFFs, and SFC proxies in the NSH by means of a
          dedicated MD Type (<xref target="new"></xref>).</t> target="new" format="default"/>).</t>
          <t>In both levels of assurance, the Context Headers and the packet
          on which the NSH is imposed are subject to integrity protection.</t>

          <t>Table 3
          <t><xref target="integrity"/> classifies the data plane elements as being involved or not involved in
          providing integrity protection for the NSH or not.</t>

          <t><figure>
              <artwork><![CDATA[         +--------------------+----------------------------------+
         | NSH.</t>

          <table anchor="integrity">
	    <name>Integrity Protection Supported by SFC Data Plane Element | Integrity Protection             |
         +--------------------+----------------------------------+
         | Classifier         | Yes                              |
         | SFF                | Elements</name>
	    <thead>
	      <tr>
		<th>Data Plane Element</th>
		<th>Integrity Protection</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>

 		<td> Classifier</td>
		<td> Yes</td>
		</tr><tr>

		<td> SFF</td>
		<td> No (first LoA); Yes (second LoA) |
         | LoA)</td>
		</tr><tr>

		<td> NSH-aware SF       | Yes                              |
         | SFC Proxy          | Yes                              |
         | SF</td>
		<td>Yes</td>
		</tr><tr>

		<td> SFC Proxy</td>
		<td>Yes</td>
		</tr><tr>

		<td> NSH-unaware SF     | No                               |
         +--------------------+----------------------------------+

    Table 3: Integrity Protection Supported by SFC Data Plane Elements]]></artwork>
            </figure></t> SF</td>
		<td> No</td>
	      </tr>
	    </tbody>
	  </table>

        </section>
      </section>
      <section title="One numbered="true" toc="default">
        <name>One Secret Key, Two Security Services"> Services</name>
        <t>The Authenticated Encryption with Associated Data (AEAD) interface
        defined in Section 5 of <xref target="RFC5116"></xref> target="RFC5116" section="5" sectionFormat="of"/> is used to
        encrypt the Context Headers that carry sensitive metadata and to
        provide integrity protection for the encrypted Context Headers.</t>
        <t>The secondary keys MAC_KEY "MAC_KEY" and ENC_KEY "ENC_KEY" are generated from the input
        secret key (K) as follows; each of these two keys is an octet
        string:<list style="hanging">
            <t hangText="MAC_KEY:">consists
        string:</t>
        <dl newline="false" spacing="normal">
          <dt>MAC_KEY:</dt>
          <dd>Consists of the initial MAC_KEY_LEN octets
            of K, in order. The MAC_KEY is used for calculating the message
            integrity of the NSH data. In other words, the integrity
            protection provided by the cryptographic mechanism is extended to
            also provide protection for the unencrypted Context Headers and
            the packet on which the NSH is imposed.</t>

            <t hangText="ENC_KEY:">consists imposed.</dd>
          <dt>ENC_KEY:</dt>
          <dd>Consists of the final ENC_KEY_LEN octets of
            K, in order. The ENC_KEY is used as the symmetric encryption key
            for encrypting the Context Headers.</t>
          </list></t> Headers.</dd>
        </dl>
        <t>The Hashed Message Authentication Mode Code (HMAC) algorithm discussed
        in <xref target="RFC4868"></xref> target="RFC4868" format="default"/> is used to protect the integrity of
        the NSH data. The algorithm for implementing and validating HMACs is
        provided in <xref target="RFC2104"></xref>.</t> target="RFC2104" format="default"/>.</t>
        <t>The advantage of using both AEAD and HMAC algorithms (instead of
        just AEAD) is that NSH-aware SFs and SFC proxies only need to
        re-compute
        recompute the message integrity of the NSH data after decrementing
        the Service Index (SI) SI and do not have to re-compute recompute the ciphertext.
        The other advantage is that SFFs do not have access to the ENC_KEY and
        cannot act on the encrypted Context Headers Headers, and (in the case of the
        second level of assurance) SFFs do have access to the MAC_KEY.
        Similarly, an NSH-aware SF or SFC Proxy not allowed to decrypt the
        Context Headers will not have access to the ENC_KEY.</t>
        <t>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 Mandatory-to-implement authenticated encryption and
        HMAC algorithms are listed in <xref target="mti"></xref>.</t> target="mti" format="default"/>.</t>
        <t>The authenticated encryption process takes four inputs, each of
        which is an octet string: a secret key (ENC_KEY, referred to as K "K" in
        <xref target="RFC5116"></xref>), target="RFC5116" format="default"/>), a plaintext (P), associated data (A)
        (which contains the data to be authenticated, authenticated but not encrypted), and
        a nonce (N). A ciphertext (C) is generated as an output as discussed
        in Section 2.1 of <xref target="RFC5116"></xref>.</t> target="RFC5116" section="2.1" sectionFormat="of"/>.</t>
        <t>In order to decrypt and verify, the cipher takes as input ENC_KEY,
        N, A, and C. C as input. The output is either the plaintext or an error indicating
        that the decryption failed as described in Section 2.2 of <xref
        target="RFC5116"></xref>.</t> target="RFC5116" section="2.2" sectionFormat="of"/>.</t>
      </section>
      <section anchor="mti"
               title="Mandatory-to-Implement numbered="true" toc="default">
        <name>Mandatory-to-Implement Authenticated Encryption and HMAC Algorithms"> Algorithms</name>
        <t>Classifiers, NSH-aware SFs, and SFC proxies MUST <bcp14>MUST</bcp14> implement the
        AES_128_GCM <xref target="GCM"></xref><xref target="RFC5116"></xref> target="GCM" format="default"/><xref target="RFC5116" format="default"/>
        algorithm and SHOULD <bcp14>SHOULD</bcp14> implement the AES_192_GCM and AES_256_GCM
        algorithms.</t>
        <t>Classifiers, NSH-aware SFs, and SFC proxies MUST <bcp14>MUST</bcp14> implement the
        HMAC- SHA-256-128 algorithm and SHOULD <bcp14>SHOULD</bcp14> implement the HMAC-SHA-384-192
        and HMAC-SHA-512-256 algorithms.</t>
        <t>SFFs MAY <bcp14>MAY</bcp14> implement the aforementioned cipher suites and HMAC
        algorithms.</t>

        <t><list style="hanging">
        algorithms.
	</t>

	<t hangText="Note:">The indent="3"> Note: The use of the AES_128_CBC_HMAC_SHA_256 algorithm would
	have avoided the need for a second 128-bit authentication tag, but due
	to the nature of how Cipher Block Chaining (CBC) mode operates,
	AES_128_CBC_HMAC_SHA_256 allows for the malleability of plaintexts. This
	malleability allows for attackers that know the
            MAC Message Authentication Code (MAC) key but not the
	encryption key to make changes in the ciphertext and, if parts of the
	plaintext are known, create arbitrary blocks of plaintext. This
	specification mandates the use of separate AEAD and MAC protections to
	prevent this type of
            attack.</t>
          </list></t> attack.
	</t>

      </section>
      <section anchor="kms" title="Key Management"> numbered="true" toc="default">
        <name>Key Management</name>
        <t>The procedure for the allocation/provisioning of secret keys (K)
        and the 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.</t>
        <t>The document does not assume nor preclude the following:<list
            style="symbols">
            <t>The following:</t>
        <ul spacing="normal">
          <li>The same keying material is used for all the service functions
            used within an SFC-enabled domain.</t>

            <t>Distinct domain.</li>
          <li>Distinct keying material is used per SFP by all involved SFC
            data path elements.</t>

            <t>Per-tenant elements.</li>
          <li>Per-tenant keys are used.</t>
          </list></t> used.</li>
        </ul>
        <t>In order to accommodate deployments relying upon keying material
        per SFC/SFP and also the need to update keys after encrypting NSH data
        for a certain amount of time, this document uses key identifiers to
        unambiguously identify the appropriate keying material and associated
        algorithms for MAC and encryption. This use of in-band identifiers
        addresses the problem of the synchronization of keying material.</t>
        <t>Additional information on manual vs. automated key management and
        when one should be used over the other can be found in <xref
        target="RFC4107"></xref>.</t> target="RFC4107" format="default"/>.</t>
        <t>The risk involved in using a group-shared symmetric key increases
        with the size of the group to which it is shared. Additional security
        issues are discussed in <xref target="Security"></xref>.</t> target="Security" format="default"/>.</t>
      </section>
      <section anchor="newch" title="New numbered="true" toc="default">
        <name>New NSH Variable-Length Context Headers"> Headers</name>
        <t>New NSH Variable-Length Context Headers are defined in <xref
        target="new"></xref> target="new" format="default"/> for NSH data integrity protection and,
        optionally, encryption of Context Headers carrying sensitive metadata.
        Concretely, an NSH imposer includes (1) the key identifier to identify
        the keying material, (2) the timestamp to protect against replay
        attacks (<xref target="time"></xref>), target="time" format="default"/>), and (3) the Message
        Authentication Code (MAC) MAC for the target NSH data (depending on the
        integrity protection
        integrity-protection scope) calculated using the MAC_KEY and
        optionally and,
        optionally, Context Headers encrypted using ENC_KEY.</t>
        <t>An SFC 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.</t>
        <t>An NSH-aware SF or SFC Proxy that needs to decrypt some Context
        Headers uses ENC_KEY and the decryption algorithm for the key
        identifier being carried in the NSH.</t>
        <t><xref target="prorules"></xref> target="prorules" format="default"/> specifies the detailed
        procedure.</t>
      </section>
      <section anchor="nsh-in-nsh" title="Encapsulation numbered="true" toc="default">
        <name>Encapsulation of NSH within NSH"> NSH</name>
        <t>As discussed in Section 3 of <xref target="RFC8459"></xref>, target="RFC8459" section="3" sectionFormat="of"/>, an
        SFC-enabled domain (called, (called an upper-level domain) may be decomposed into
        many sub-domains (called, (called lower-level domains). In order to avoid
        maintaining state to restore back upper-level NSH information at the
        boundaries of lower-level domains, two NSH levels are used: an
        Upper-NSH which that is 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 (<xref target="nest"></xref>). target="nest" format="default"/>). 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 domain.</t>

        <t><figure align="center" anchor="nest"
            title="Encapsulation
        <figure anchor="nest">
          <name>Encapsulation of NSH within NSH"> NSH</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   +---------------------------------+
   |     Transport Encapsulation     |
+->+---------------------------------+
|  |        Lower-NSH Header         |
|  +---------------------------------+
|  |        Upper-NSH Header         |
|  +---------------------------------+
|  |          Original Packet        |
+->+---------------------------------+
|
|
+----Scope of NSH security protection
     provided by a lower-level domain
]]></artwork>
          </figure></t>
        </figure>
        <t>SFC data plane elements of a lower-level domain include the
        Upper-NSH when computing the MAC.</t>
        <t>Keying material used at the upper-level domain SHOULD NOT <bcp14>SHOULD NOT</bcp14> be the
        same as the one used by a lower-level domain.</t>
      </section>
    </section>
    <section anchor="new" title="New numbered="true" toc="default">
      <name>New NSH Variable-Length Context Headers"> Headers</name>
      <t>This section specifies the format of new Variable-Length Context
      headers
      Headers that are used for NSH integrity protection and, optionally,
      Context Headers Header encryption.</t>
      <t>In particular, this section defines two "MAC and Encrypted Metadata"
      Context Headers; Headers, each having specific deployment constraints. Unlike
      <xref target="enc1"></xref>, target="enc1" format="default"/>, the level of assurance provided
      in <xref
      target="enc2"></xref> target="enc2" format="default"/> requires sharing MAC_KEY with
      SFFs. Both Context
      headers Headers have the same format as shown in <xref target="mac"></xref>.</t>

      <t><figure align="center" anchor="mac"
          title="MAC
      target="mac" format="default"/>.</t>
      <figure anchor="mac">
        <name>MAC and Encrypted Metadata Context Header"> Header</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[        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 Id Len  |         Key Identifier (Variable)               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                      Timestamp (8 bytes)                      ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Nonce Length  |           Nonce  (Variable)                   ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Message Authentication Code and optional Encrypted        |
       ~                  Context Headers (Variable)                   ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>
      </figure>

      <t>The "MAC and Encrypted Metadata" Context Headers are padded out to a
      multiple of 4 bytes as per Section 2.2 of <xref
      target="RFC8300"></xref>. target="RFC8300" section="2.2" sectionFormat="of"/>.
      The "MAC and Encrypted Metadata" Context
      Header, if included, MUST <bcp14>MUST</bcp14> always be the last Context Header.</t>
      <section anchor="enc1" title="MAC#1 numbered="true" toc="default">
        <name>MAC#1 Context Header">
        <t>MAC#1 Header</name>
        <t>The MAC#1 Context Header is a variable-length Variable-Length Context Header that
        carries the Message Authentication Code (MAC) MAC for the Service Path
        Header, Context Headers, and the inner packet on which NSH is imposed,
        calculated using MAC_KEY, and optionally MAC_KEY and, optionally, Context Headers encrypted
        using ENC_KEY. The scope of the integrity protection provided by this
        Context Header is depicted in <xref target="scope1"></xref>.</t> target="scope1" format="default"/>.</t>
        <t>This MAC scheme does not require sharing MAC_KEY with SFFs. It does
        not require to re-compute recomputing the MAC by each SFF because of TTL
        processing. <xref target="mac1"></xref> target="mac1" format="default"/> discusses the possible threat
        associated with this level of assurance.</t>
        <figure align="center" anchor="scope1" title="Scope anchor="scope1">
          <name>Scope of MAC#1"> MAC#1</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[    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 |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   ~       Variable-Length Unencrypted Context Headers  (opt.)     ~   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |          Metadata Class       |      Type     |U|    Length   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   | Key Id Len  |         Key Identifier (Variable)               ~   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   ~                      Timestamp (8 bytes)                      ~   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   | Nonce Length  |           Nonce  (Variable)                   ~   |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|  ~                Encrypted Context Headers (opt.)               ~   |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|  ~                 Message Authentication Code                   ~   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|  |                                                               |   |
|  ~               Inner Packet on which NSH is imposed            ~   |
|  |                                                               |   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--|
|                                                                      |
|                                       Integrity Protection                                       Integrity-Protection Scope ----+
+----Encrypted Data
]]></artwork>
        </figure>

        <t></t>

        <t>In reference to <xref target="mac"></xref>, target="mac" format="default"/>, the description of the
        fields is as follows:<list style="hanging">
            <t hangText="Metadata Class:">MUST follows:</t>
        <dl newline="false" spacing="normal" indent="12">
          <dt>Metadata Class:</dt>
          <dd><bcp14>MUST</bcp14> be set to 0x0 (Section 2.5.1 of
            <xref target="RFC8300"></xref>).</t>

            <t hangText="Type:">TBD1 (See (<xref target="RFC8300" section="2.2" sectionFormat="of"/>).</dd>
          <dt>Type:</dt>
          <dd>0x02 (see <xref target="IANA"></xref>)</t>

            <t hangText="U:">Unassigned target="IANA" format="default"/>).</dd>
          <dt>U:</dt>
          <dd>Unassigned bit (Section 2.5.1 of <xref
            target="RFC8300"></xref>).</t>

            <t hangText="Length:">Indicates (<xref target="RFC8300" section="2.5.1" sectionFormat="of"/>).</dd>
          <dt>Length:</dt>
          <dd>Indicates the length of the variable-length
            metadata,
            metadata in bytes. Padding considerations are discussed in
            Section 2.5.1 of
           <xref target="RFC8300"></xref>.</t>

            <t hangText="Key target="RFC8300" section="2.5.1" sectionFormat="of"/>.</dd>
          <dt>Key Id Len:">Variable. Len:</dt>
          <dd>Variable. Carries the length of the key
            identifier,
            identifier in octets.</t>

            <t hangText="Key Identifier:">Carries octets.</dd>
          <dt>Key Identifier:</dt>
          <dd>Carries a variable-length Key
            Identifier object used to identify and deliver keys to SFC data
            plane elements. This identifier is helpful to accommodate for accommodating
            deployments relying upon keying material per SFC/SFP. The key
            identifier helps in resolving to resolve the problem of synchronization of
            keying material. A single key identifier is used to lookup look up both
            the ENC_KEY and the MAC_KEY associated with a key, and the
            corresponding encryption and MAC algorithms used with those
            keys.</t>

            <t hangText="Timestamp:">Refer
            keys.</dd>
          <dt>Timestamp:</dt>
          <dd>Refer to <xref target="timef"></xref> target="timef" format="default"/> for
            more details about the structure of this field.</t>

            <t hangText="Nonce Length:">Carries field.</dd>
          <dt>Nonce Length:</dt>
          <dd>Carries the length of the Nonce. If
            the Context Headers are only integrity protected, "Nonce Length"
            is set to zero (that is, no "Nonce" is included).</t>

            <t hangText="Nonce:">Carries included).</dd>
          <dt>Nonce:</dt>
          <dd>Carries the Nonce for the authenticated
            encryption operation (Section 3.1 of <xref
            target="RFC5116"></xref>).</t>

            <t hangText="Encrypted (<xref target="RFC5116" section="3.1" sectionFormat="of"/>).</dd>
          <dt>Encrypted Context Headers:">Carries Headers:</dt>
          <dd>Carries the optional
            encrypted Context Headers.</t>

            <t hangText="Message Headers.</dd>
          <dt>Message Authentication Code: ">Covers </dt>
          <dd>Covers the entire NSH
            data, excluding the Base header.</t>
          </list></t> Header.</dd>
        </dl>
      </section>
      <section anchor="enc2" title="MAC#2 numbered="true" toc="default">
        <name>MAC#2 Context Header">
        <t>MAC#2 Header</name>
        <t>The MAC#2 Context Header is a variable-length Variable-Length Context Header that
        carries the MAC for the entire NSH data calculated using MAC_KEY and
        optionally and,
        optionally, Context Headers encrypted using ENC_KEY. The scope of the
        integrity protection provided by this Context Header is depicted in
        <xref target="scope2"></xref>.</t> target="scope2" format="default"/>.</t>
        <figure align="center" anchor="scope2" title="Scope anchor="scope2">
          <name>Scope of MAC#2"> MAC#2</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[    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 |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   ~       Variable-Length Unencrypted Context Headers  (opt.)     ~   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   |          Metadata Class       |      Type     |U|    Length   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   | Key Id Len  |         Key Identifier (Variable)               ~   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   ~                      Timestamp (8 bytes)                      ~   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   | Nonce Length  |           Nonce  (Variable)                   ~   |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|  ~                Encrypted Context Headers (opt.)               ~   |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|  ~                 Message Authentication Code                   ~   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|  |                                                               |   |
|  ~               Inner Packet on which NSH is imposed            ~   |
|  |                                                               |   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--|
|                                                                      |
|                                       Integrity Protection                                       Integrity-Protection Scope ----+
+----Encrypted Data
]]></artwork>
        </figure>

        <t></t>

        <t>In reference to <xref target="mac"></xref>, target="mac" format="default"/>, the description of the
        fields is as follows:<list style="hanging">
            <t hangText="Metadata Class:">MUST follows:</t>
        <dl newline="false" spacing="normal" indent="12">
          <dt>Metadata Class:</dt>
          <dd><bcp14>MUST</bcp14> be set to 0x0 (Section 2.5.1 of
            <xref target="RFC8300"></xref>).</t>

            <t hangText="Type:">TBD2 (See (<xref target="RFC8300" section="2.2" sectionFormat="of"/>).</dd>
          <dt>Type:</dt>
          <dd>0x03 (see <xref target="IANA"></xref>)</t>

            <t hangText="U:">Unassigned target="IANA" format="default"/>).</dd>
          <dt>U:</dt>
          <dd>Unassigned bit (Section 2.5.1 of <xref
            target="RFC8300"></xref>).</t>

            <t hangText="Length:">Indicates (<xref target="RFC8300" section="2.5.1" sectionFormat="of"/>).</dd>
          <dt>Length:</dt>
          <dd>Indicates the length of the variable-length
            metadata,
            metadata in bytes. Padding considerations are discussed in
            Section 2.5.1 of
            <xref target="RFC8300"></xref>.</t>

            <t hangText="Key target="RFC8300" section="2.5.1" sectionFormat="of"/>.</dd>
          <dt>Key Id Len:">See <xref target="enc1"></xref>.</t>

            <t hangText="Key Identifier:">See <xref target="enc1"></xref>.</t>

            <t hangText="Timestamp:">See <xref target="timef"></xref>.</t>

            <t hangText="Nonce Length:">See Len:</dt>
          <dd>See <xref target="enc1"></xref>.</t>

            <t hangText="Nonce:">See <xref target="enc1"></xref>.</t>

            <t hangText="Encrypted target="enc1" format="default"/>.</dd>
          <dt>Key Identifier:</dt>
          <dd>See <xref target="enc1" format="default"/>.</dd>
          <dt>Timestamp:</dt>
          <dd>See <xref target="timef" format="default"/>.</dd>
          <dt>Nonce Length:</dt>
          <dd>See <xref target="enc1" format="default"/>.</dd>
          <dt>Nonce:</dt>
          <dd>See <xref target="enc1" format="default"/>.</dd>
          <dt>Encrypted Context Headers:">Carries Headers:</dt>
          <dd>Carries the optional
            encrypted Context Headers.</t>

            <t hangText="Message Headers.</dd>
          <dt>Message Authentication Code:">Covers Code:</dt>
          <dd>Covers the entire NSH
            data.</t>
          </list></t>
            data.</dd>
        </dl>
      </section>
    </section>
    <section anchor="timef" title="Timestamp Format"> numbered="true" toc="default">
      <name>Timestamp Format</name>
      <t>This section follows the template provided in Section 3 of <xref
      target="RFC8877"></xref>.</t> target="RFC8877" section="3" sectionFormat="of"/>.</t>
      <t>The format of the Timestamp field introduced in <xref
      target="new"></xref> target="new" format="default"/> is depicted in <xref target="tf"></xref>.</t>

      <t><figure anchor="tf" title="Timestamp target="tf" format="default"/>.</t>
      <figure anchor="tf">
        <name>Timestamp Field Format"> Format</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Seconds                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Fraction                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>Timestamp
      </figure>

      <dl spacing="normal" newline="true">
	<dt>Timestamp field format:<list style="empty">
          <t>Seconds: specifies format:</dt>
	<dd>
        <dl>
        <dt>Seconds:</dt><dd>Specifies the integer portion of the number of seconds
          since the epoch.</t>

          <t>+ Size: epoch.</dd>
        <dt>+ Size:</dt><dd> 32 bits.</t>

          <t>+ Units: seconds.</t>

          <t>Fraction: specifies bits</dd>
        <dt>+ Units:</dt><dd> Seconds</dd>
        <dt>Fraction:</dt><dd> Specifies the fractional portion of the number of
          seconds since the epoch.</t>

          <t>+ Size: epoch.</dd>
        <dt>+ Size:</dt><dd> 32 bits.</t>

          <t>+ Units: the bits</dd>
        <dt>+ Units:</dt><dd>The unit is 2^(-32) 2<sup>(-32)</sup> seconds, which is roughly equal to
          233 picoseconds.</t>
        </list></t>

      <t>Epoch:<list style="empty">
          <t>The picoseconds.</dd>
	</dl>
      </dd>
    </dl>

    <dl newline="true">

      <dt>Epoch:</dt>
        <dd>The epoch is 1970-01-01T00:00 in UTC time. Note that this epoch
        value is different from the one used in Section 6 of <xref
          target="RFC5905"></xref> target="RFC5905"
        section="6" sectionFormat="of"/> (which will wrap around in 2036).</t>
        </list></t>

      <t>Leap seconds:<list style="empty">
          <t>This
        2036).</dd>

      <dt>Leap seconds:</dt>
        <dd>This timestamp format is affected by leap seconds. The timestamp
          represents the number of seconds elapsed since the epoch minus the
          number of leap seconds.</t>
        </list></t>

      <t>Resolution:<list style="empty">
          <t>The seconds.</dd>

      <dt>Resolution:</dt>

        <dd>The resolution is 2^(-32) seconds.</t>
        </list></t>

      <t>Wraparound:<list style="empty">
          <t>This 2<sup>(-32)</sup> seconds.</dd>

      <dt>Wraparound:</dt>

        <dd>This time format wraps around every 2^32 2<sup>32</sup> seconds, which is
          roughly 136 years. The next wraparound will occur in the year
          2106.</t>
        </list>Synchronization aspects:<list style="empty">
          <t>It
          2106.</dd>

      <dt>Synchronization aspects:</dt>

        <dd>It is assumed that SFC data plane elements are synchronized to
          UTC using a synchronization mechanism that is outside the scope of
          this document. In typical deployments, SFC data plane elements use
          NTP <xref target="RFC5905"></xref> target="RFC5905" format="default"/> for synchronization. Thus, the
          timestamp may be derived from the NTP-synchronized clock, allowing
          the timestamp to be measured with respect to the clock of an NTP
          server. Since this time format is specified in terms of UTC, it is
          affected by leap seconds (in a manner analogous to the NTP time
          format, which is similar). Therefore, the value of a timestamp
          during or slightly after a leap second may be temporarily
          inaccurate.</t>
        </list></t>
          inaccurate.</dd>
      </dl>
    </section>
    <section anchor="prorules" title="Processing Rules"> numbered="true" toc="default">
      <name>Processing Rules</name>
      <t>The following subsections describe the processing rules for integrity
      protected
      integrity-protected NSH and optionally and, optionally, encrypted Context Headers.</t>
      <section anchor="gen" title="Generic Behavior"> numbered="true" toc="default">
        <name>Generic Behavior</name>
        <t>This document adheres to the recommendations in Section 8.1 of <xref target="RFC8300"></xref> target="RFC8300" section="8.1" sectionFormat="of"/> for handling the Context Headers at
        both ingress and egress SFC boundary nodes (i.e., to strip the entire
        NSH, including Context Headers).</t>
        <t>Failures of a classifier Classifier to inject the Context Headers defined in
        this document SHOULD <bcp14>SHOULD</bcp14> be logged locally while a notification alarm MAY <bcp14>MAY</bcp14>
        be sent to an SFC control element. Failures of an NSH-aware node to
        validate the integrity of the NSH data MUST <bcp14>MUST</bcp14> cause that packet to be
        discarded while a notification alarm MAY <bcp14>MAY</bcp14> be sent to an SFC control
        element. The details of sending notification alarms (i.e., the
        parameters that affect the transmission of the notification alarms
        depending on the information in the context header Context Header such as frequency,
        thresholds, and content in the alarm) SHOULD <bcp14>SHOULD</bcp14> be configurable.</t>
        <t>NSH-aware SFs and SFC proxies MAY <bcp14>MAY</bcp14> 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 NSH-aware nodes is to maintain such
        Context Headers so that the information can be passed to the next
        NSH-aware hops.  NSH-aware SFs and SFC proxies MUST re-apply <bcp14>MUST</bcp14>
        reapply the integrity protection if any modification is made to the
        Context Headers (e.g., strip a Context Header, update the content of
        an existing Context Header, insert a new Context Header).</t>
        <t>An NSH-aware SF or SFC Proxy that is not allowed to decrypt any
        Context Headers MUST NOT <bcp14>MUST NOT</bcp14> be given access to the ENC_KEY.</t>
        <t>Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted
        Context Headers, for which it is not allowed to consume a specific
        Context Header it decrypts (but consumes others), MUST <bcp14>MUST</bcp14> keep that
        Context Header unaltered when forwarding the packet upstream.</t>
        <t>Only one instance of a "MAC and Encrypted Metadata" Context Header
        (<xref target="new"></xref>) target="new" format="default"/>) is allowed in an NSH level. If multiple
        instances of a "MAC and Encrypted Metadata" Context Header are included
        in an NSH level, the SFC data plane element MUST <bcp14>MUST</bcp14> process the first
        instance and ignore subsequent instances, instances and MAY <bcp14>MAY</bcp14> log or increase a
        counter for this event as per Section 2.5.1 of <xref
        target="RFC8300"></xref>. target="RFC8300" section="2.5.1" sectionFormat="of"/>. If NSH-in-NSH NSH within NSH is used (<xref
        target="nsh-in-nsh"></xref>), target="nsh-in-nsh" format="default"/>), distinct LoAs may be used for each NSH
        level.</t>
        <t>MTU and fragmentation considerations are discussed in <xref
        target="MTU"></xref>.</t> target="MTU" format="default"/>.</t>
      </section>

      <section title="MAC numbered="true" toc="default">

        <name>MAC NSH Data Generation"> Generation</name>
        <t>After performing any Context Header encryption, the HMAC algorithm
        discussed in <xref target="RFC4868"></xref> target="RFC4868" format="default"/> is used to
        integrity protect the target NSH data. An NSH imposer inserts a "MAC
        and Encrypted Metadata" Context Header for integrity protection (<xref
        target="new"></xref>).</t>
        target="new" format="default"/>).</t>
        <t>The NSH imposer sets the MAC field to zero and then computes the
        message integrity for the target NSH data (depending on the integrity
        protection
        integrity-protection scope discussed in <xref target="new"></xref>) target="new"
        format="default"/>) using the MAC_KEY and HMAC algorithm. It inserts
        the computed digest in the MAC field of the "MAC and Encrypted
        Metadata" Context Header. The length of the MAC is decided by the HMAC
        algorithm adopted for the particular key identifier.</t>
        <t>The Message Authentication Code (T) computation process for the
        target NSH data with HMAC-SHA-256-128() can be illustrated as
        follows:</t>

        <figure>
          <artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[      T = HMAC-SHA-256-128(MAC_KEY, target NSH data)
]]></artwork>
        </figure>

        <t></t>

        <t>An entity in the SFP that updates the NSH MUST <bcp14>MUST</bcp14> follow the above
        behavior to maintain message integrity of the NSH for subsequent
        validations.</t>
      </section>
      <section title="Encrypted numbered="true" toc="default">
        <name>Encrypted NSH Metadata Generation"> Generation</name>
        <t>An NSH imposer can encrypt Context Headers carrying sensitive
        metadata, i.e., encrypted and unencrypted metadata may be carried
        simultaneously in the same NSH packet (Sections <xref format="counter"
        target="scope1"></xref> target="scope1"/> and <xref format="counter"
        target="scope2"></xref>).</t> target="scope2"/>).</t>
        <t>In order to prevent pervasive monitoring <xref
        target="RFC7258"></xref>, target="RFC7258" format="default"/>, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to encrypt all Context
        Headers. All Context Headers carrying privacy-sensitive metadata MUST <bcp14>MUST</bcp14>
        be encrypted; by doing so, privacy-sensitive metadata is not revealed
        to attackers. Privacy specific Privacy-specific threats are discussed in Section 5.2 of
        <xref target="RFC6973"></xref>.</t> target="RFC6973" section="5.2" sectionFormat="of"/>.</t>
        <t>Using the secret key (ENC_KEY) and authenticated encryption
        algorithm, the NSH imposer encrypts the Context Headers (as set, for
        example, in <xref target="req"></xref>) target="req" format="default"/>) and inserts the
        resulting payload in the "MAC and Encrypted Metadata" Context Header
        (<xref
        target="new"></xref>). target="new" format="default"/>). The additional authenticated
        data input to the AEAD function is a zero-length byte string. The
        entire Context Header carrying a sensitive metadata is encrypted (that
        is, including the MD Class, Type, Length, and associated metadata of
        each Context Header).</t>
        <t>More details about the exact encryption procedure are provided in
        Section 2.1 of
        <xref target="RFC5116"></xref>. target="RFC5116" section="2.1" sectionFormat="of"/>. In this
        case, the associated data (A) input is zero-length zero length for AES-GCM.</t> AES
        Galois/Counter Mode (AES-GCM).</t>
        <t>An authorized entity in the SFP that updates the content of an
        encrypted Context Header or needs to add a new encrypted Context
        Header MUST <bcp14>MUST</bcp14> also follow the aforementioned behavior.</t>
      </section>
      <section anchor="time" title="Timestamp numbered="true" toc="default">
        <name>Timestamp for Replay Attack Prevention"> Prevention</name>
        <t>The Timestamp imposed by an initial Classifier is left untouched
        along an SFP. However, it can be updated when reclassification occurs
        (Section 4.8 of <xref target="RFC7665"></xref>).
        (<xref target="RFC7665" section="4.8" sectionFormat="of"/>). The same
        considerations for setting the Timestamp are followed in both initial
        classification and reclassification (<xref
        target="timef"></xref>).</t> target="timef" format="default"/>).</t>
        <t>The received NSH is accepted by an NSH-aware node 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:</t>

        <t><figure>
            <artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[      -Delta < (TSrt - TS) < +Delta
]]></artwork>
          </figure></t>
        <t>The Delta interval is a configurable parameter. The default value
        for the allowed Delta is 2 seconds. Special care should be taken when
        setting very low Delta values as this may lead to dropping legitimate
        traffic. If the timestamp is not within the boundaries, then the SFC
        data plane element receiving such packet MUST packets <bcp14>MUST</bcp14> discard the NSH
        message.</t>
        <t>Replay attacks within the Delta window may be detected by an
        NSH-aware node by recording a unique value derived from the packet,
        for example,
        such as a unique value from the MAC field value. Such an NSH-aware
        node will detect and reject duplicates. If for legitimate service reasons,
        reasons some flows have to be duplicated but still share a portion of
        an SFP with the original flow, legitimate duplicate packets will be
        tagged by NSH-aware nodes involved in that segment as replay packets
        unless sufficient entropy is added to the duplicate packet.  How such
        an entropy is added is implementation-specific.</t>

        <t><list style="empty">
            <t>Note: implementation specific.</t>

	  <t indent="3">
Note: Within the timestamp delta Delta window, defining a sequence number to protect
against replay attacks may be considered. In such a mode, NSH-aware nodes must
discard packets with duplicate sequence numbers within the timestamp delta Delta
window. However, in deployments with several instances of the same SF (e.g.,
cluster or load-balanced SFs), a mechanism to coordinate among those instances
to discard duplicate sequence numbers is required.  Because the coordination
mechanism to comply with this requirement is service-specific, service specific, this document
does not include this
            protection.</t>
          </list></t> protection.

	  </t>

        <t>All SFC data plane elements must be synchronized among themselves.
        These elements may be synchronized to a global reference time.</t>
      </section>
      <section title="NSH numbered="true" toc="default">
        <name>NSH Data Validation"> Validation</name>
        <t>When an SFC data plane element that conforms to this specification
        needs to check the validity of the NSH data, it MUST <bcp14>MUST</bcp14> ensure that a
        "MAC and Encrypted Metadata" Context Header is included in a received
        NSH packet. The imposer MUST <bcp14>MUST</bcp14> silently discard the packet and MUST <bcp14>MUST</bcp14> log
        an error at least once per the SPI if at least one of the following is
        observed:<list style="symbols">
            <t>the
        observed:</t>
        <ul spacing="normal">
          <li>the "MAC and Encrypted Metadata" Context Header is missing,</t>

            <t>the missing,</li>
          <li>the enclosed key identifier is unknown or invalid (e.g., the
            corresponding key expired),</t>

            <t>the expired), or</li>
          <li>the timestamp is invalid (<xref target="time"></xref>).</t>
          </list></t> target="time" format="default"/>).</li>
        </ul>
        <t>If the timestamp check is successfully passed, the SFC data plane
        element proceeds with NSH data integrity validation. After storing the
        value of the MAC field in the "MAC and Encrypted Metadata" Context
        Header, the SFC data plane element fills the MAC field with zeros.
        Then, the SFC data plane element generates the message integrity for
        the target NSH data (depending on the integrity protection integrity-protection scope
        discussed in <xref target="new"></xref>) target="new" format="default"/>) using the MAC_KEY and
        HMAC algorithm. If the value of the newly generated digest is
        identical to the stored one, the SFC data plane element is certain
        that the NSH data has not been tampered with and validation is
        therefore successful.  Otherwise, the NSH packet MUST <bcp14>MUST</bcp14>
        be discarded. The comparison of the computed HMAC value to the stored
        value MUST <bcp14>MUST</bcp14> be done in a constant-time manner to thwart
        timing attacks.</t>
      </section>
      <section title="Decryption numbered="true" toc="default">
        <name>Decryption of NSH Metadata"> Metadata</name>
        <t>If entitled to consume a supplied encrypted Context Header, an
        NSH-aware SF or SFC Proxy decrypts metadata using (K) and a decryption
        algorithm for the key identifier in the NSH.</t>

        <t>Authenticated
        <t>The 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 2.2 of [RFC5116]).</t> (<xref target="RFC5116" section="2.2" sectionFormat="of"/>).</t>
      </section>
    </section>
    <section anchor="MTU" title="MTU Considerations"> numbered="true" toc="default">
      <name>MTU Considerations</name>
      <t>The SFC architecture prescribes that additional information be added
      to packets to: <list style="symbols">
          <t>Identify </t>

      <ul spacing="normal">
        <li>Identify SFPs: this is typically the NSH Base Header and Service
          Path Header.</t>

          <t>Carry Header.</li>
        <li>Carry metadata such as those that defined in <xref format="default"
          target="new"></xref>.</t>

          <t>Steer target="new"/>.</li>
        <li>Steer the traffic along the SFPs: This is realized by means of
        transport encapsulation.</t>
        </list></t> encapsulation.</li>
      </ul>
      <t>This added information increases the size of the packet to be carried
      along an SFP.</t>
      <t>Aligned with Section 5 of <xref target="RFC8300"></xref>, target="RFC8300" section="5" sectionFormat="of"/>, it is
      RECOMMENDED for
      <bcp14>RECOMMENDED</bcp14> that network operators to increase the underlying MTU so that
      NSH traffic is forwarded within an SFC-enabled domain without
      fragmentation. The available underlying MTU should be taken into account
      by network operators when providing SFs with the required Context
      Headers to be injected per SFP and the size of the data to be carried in
      these Context Headers.</t>
      <t>If the underlying MTU cannot be increased to accommodate the NSH
      overhead, network operators may rely upon a transport encapsulation
      protocol with the required fragmentation handling. The impact of
      activating such feature features on SFFs should be carefully assessed by network
      operators (Section 5.6 of <xref target="RFC7665"></xref>).</t> (<xref target="RFC7665" section="5.6" sectionFormat="of"/>).</t>
      <t>When dealing with MTU issues, network operators should consider the
      limitations of various tunnel mechanisms such as those discussed in
      <xref target="I-D.ietf-intarea-tunnels"></xref>.</t> target="I-D.ietf-intarea-tunnels" format="default"/>.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Data plane SFC-related security considerations, including privacy,
      are discussed in Section 6 of <xref target="RFC7665"></xref> target="RFC7665" section="6" sectionFormat="of"/>
      and Section
      8 of <xref target="RFC8300"></xref>. target="RFC8300" section="8" sectionFormat="of"/>. In
      particular, Section 8.2.2 of <xref target="RFC8300"></xref> target="RFC8300" section="8.2.2" sectionFormat="of"/>
      states that attached metadata (i.e., Context Headers) should be limited
      to that which is necessary for correct operation of the SFP. Also, that section
      indicates that <xref
      target="RFC8165"></xref> target="RFC8165" format="default"/> discusses
      metadata considerations that operators can take into account when using
      NSH.</t>
      <t>The guidelines for cryptographic key management are discussed in
      <xref target="RFC4107"></xref>. target="RFC4107" format="default"/>. The group key management protocol
      related
      protocol-related security considerations discussed in Section 8 of <xref
      target="RFC4046"></xref> needs
      target="RFC4046" section="8" sectionFormat="of"/> need to be taken into
      consideration.</t>

      <t>The interaction between the SFC data plane elements and a key
      management system MUST NOT <bcp14>MUST NOT</bcp14> be transmitted in clear unencrypted since
      this would completely destroy the security benefits of the integrity protection
      integrity-protection solution defined in this document.</t>
      <t>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 NSH-aware nodes SHOULD <bcp14>SHOULD</bcp14>
      have the control plane distribute a 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 <bcp14>RECOMMENDED</bcp14> that
      the next key identifier and associated keying material be distributed by
      the control plane well prior to the secret key expiration time.
      Additional guidance for users of AEAD functions about rekeying can be
      found in <xref target="I-D.irtf-cfrg-aead-limits"></xref>.</t> target="I-D.irtf-cfrg-aead-limits" format="default"/>.</t>
      <t>The security and integrity of the key-distribution mechanism is vital
      to the security of the SFC system as a whole.</t>
      <t>NSH data are is exposed to several threats:</t>

      <t><list style="symbols">
          <t>A
      <ul spacing="normal">
        <li>An on-path attacker modifying the NSH data.</t>

          <t>Attacker data.</li>
        <li>An attacker spoofing the NSH data.</t>

          <t>Attacker data.</li>
        <li>An attacker capturing and replaying the NSH data.</t>

          <t>Data data.</li>
        <li>Data carried in Context Headers revealing privacy-sensitive
          information to attackers.</t>

          <t>Attacker attackers.</li>
        <li>An attacker replacing the packet on which the NSH is imposed with a
          modified or bogus packet.</t>
        </list></t> packet.</li>
      </ul>
      <t>In an SFC-enabled domain where the above attacks are possible, (1)
      NSH data MUST <bcp14>MUST</bcp14> be integrity-protected integrity protected and replay-protected,
      replay protected, and (2) privacy-sensitive NSH metadata MUST
      <bcp14>MUST</bcp14> be encrypted for confidentiality preservation
      purposes. The Base and Service Path headers Headers are not encrypted.</t>
      <t>MACs with two levels of assurance are defined in <xref
      target="new"></xref>. target="new"
      format="default"/>. Considerations specific to each level of assurance
      are discussed in Sections <xref format="counter" target="mac1"></xref> target="mac1"/> and
      <xref format="counter" target="mac2"></xref>.</t> target="mac2"/>.</t>

      <t>The attacks discussed in <xref
      target="I-D.nguyen-sfc-security-architecture"></xref>
      target="I-D.nguyen-sfc-security-architecture" format="default"/> are
      handled owing
      to based on the solution specified in this document, except for with the
      exception of attacks dropping packets. Such attacks can be detected
      by relying upon statistical analysis; such analysis is out of the scope of
      this document. Also, if SFFs are not involved in the integrity checks, a
      misbehaving SFF which that decrements SI while this should be done by an SF
      (SF bypass attack) will be detected by an upstream SF because the
      integrity check will fail.</t>
      <t>Some events are logged locally with notification alerts sent by
      NSH-aware nodes to a Control Element. These events SHOULD <bcp14>SHOULD</bcp14> be
      rate-limited.</t>
      rate limited.</t>
      <t>The solution specified in this document does not provide data origin
      authentication.</t>
      <t>In order to detect compromised nodes, it is assumed that appropriate
      mechanisms to monitor and audit an SFC-enabled domain to detect
      misbehavior and to deter misuse are in place. Compromised nodes can thus
      be withdrawn from active service function chains using appropriate
      control plane mechanisms.</t>
      <section anchor="mac1" title="MAC#1"> numbered="true" toc="default">
        <name>MAC#1</name>
        <t>An active attacker can potentially modify the Base header Header (e.g.,
        decrement the TTL so the next SFF in the SFP discards the NSH packet).
        An active attacker can typically also drop NSH packets. As such, this
        attack is not considered an attack against the security mechanism
        specified in the document.</t>
        <t>It is expected that specific devices in the SFC-enabled domain will
        be configured such that no device other than the classifiers Classifiers (when
        reclassification is enabled), NSH-aware SFs, and SFC proxies will be
        able to update the integrity protected integrity-protected NSH data (<xref
        target="gen"></xref>), target="gen"
        format="default"/>), and also such that no device other than the
        NSH-aware SFs and SFC proxies will be able to decrypt and update the
        Context Headers carrying sensitive metadata (<xref
        target="gen"></xref>). target="gen"
        format="default"/>). In other words, if it is expected that the NSH-aware
        SFs and SFC proxies in the SFC-enabled domain are considered fully
        trusted to act on the NSH data. Only these elements can have access to
        sensitive NSH metadata and the keying material used to integrity
        protect NSH data and encrypt Context Headers.</t>
      </section>
      <section anchor="mac2" title="MAC#2"> numbered="true" toc="default">
        <name>MAC#2</name>
        <t>SFFs can detect whether an illegitimate node has altered the
        content of the Base header. Header. Such messages must be discarded with
        appropriate logs and alarms generated (see <xref
        target="gen"></xref>).</t> target="gen" format="default"/>).</t>
        <t>Similar to <xref target="mac1"></xref>, target="mac1" format="default"/>, no device other than the
        NSH-aware SFs and SFC proxies in the SFC-enabled domain should be able
        to decrypt and update the Context Headers carrying sensitive
        metadata.</t>
      </section>
      <section title="Time Synchronization"> numbered="true" toc="default">
        <name>Time Synchronization</name>
        <t><xref target="RFC8633"></xref> target="RFC8633" format="default"/> describes best current practices to
        be considered in deployments where SFC data plane elements use NTP for
        time synchronization
        time-synchronization purposes.</t>
        <t>Also, a mechanism to provide cryptographic security for NTP is
        specified in <xref target="RFC8915"></xref>.</t> target="RFC8915" format="default"/>.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests IANA to assign numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has added the following types from to the "NSH IETF-Assigned Optional
      Variable-Length Metadata Types" registry (0x0000 IETF Base NSH MD Class) registry available at:
      https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types.</t>

      <t><figure>
          <artwork align="center"><![CDATA[+-------+-------------------------------+----------------+
| Value | Description                   | Reference      |
+=======+===============================+================+
| TBD1  | MAC
      at <eref brackets="angle"
      target="https://www.iana.org/assignments/nsh"/>.
      </t>
      <table>
	<name>Additions to the NSH IETF-Assigned Optional Variable-Length Metadata Types Registry</name>
	<thead>
	  <tr>
	    <th>Value</th>
	    <th>Description</th>
	    <th>Reference</th>
	  </tr>
	</thead>
	  <tbody>
	    <tr>
	      <td>0x02</td>
	      <td>MAC and Encrypted Metadata #1 | [ThisDocument] |
| TBD2  | MAC #1</td>
	      <td>RFC 9145</td>
	    </tr>
	    <tr>
	      <td>0x03</td>
	      <td>MAC and Encrypted Metadata #2 | [ThisDocument] |
+-------+-------------------------------+----------------+]]></artwork>
        </figure></t> #2</td>
	      <td>RFC 9145</td>
	    </tr>
	  </tbody>
	</table>
    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-intarea-tunnels" to="INTERNET-IP-TUNNELS"/>
    <displayreference target="I-D.arkko-farrell-arch-model-t" to="INTERNET-THREAT-MODEL"/>
    <displayreference target="I-D.nguyen-sfc-security-architecture" to="ARCH-SFC-THREATS"/>
    <displayreference target="I-D.irtf-cfrg-aead-limits" to="AEAD-LIMITS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4868.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4107.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>

        <reference anchor="GCM">
          <front>
            <title>Recommendation for Block Cipher Modes of Operation:
          Galois/Counter Mode (GCM) and GMAC</title>
            <author initials="M." surname="Dworkin">
              <organization/>
            </author>
            <date month="November" year="2007"/>
          </front>
          <seriesInfo name="NIST" value="Special Publication 800-38D"/>
	  <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
        </reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8459.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8877.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7498.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8165.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-intarea-tunnels.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-arkko-farrell-arch-model-t.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-nguyen-sfc-security-architecture.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-irtf-cfrg-aead-limits.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7635.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8633.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4046.xml"/>

    </references>
    </references>

    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>This document was edited created as a follow-up to the discussion in
      IETF#104:
      https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01
      IETF 104:
      <eref brackets="angle" target="https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01"/>
      (slide 7).</t>

      <t>Thanks to Joel Halpern, Christian Jacquenet, Dirk <contact fullname="Joel Halpern"/>, <contact
      fullname="Christian Jacquenet"/>, <contact fullname="Dirk von Hugo, Tal
      Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody Hugo"/>,
      <contact fullname="Tal Mizrahi"/>, <contact fullname="Daniel Migault"/>,
      <contact fullname="Diego Lopez"/>, <contact fullname="Greg Mirsky"/>,
      and <contact fullname="Dhruv Dhody"/> for the comments.</t>
      <t>Many thanks to Steve Hanna <contact fullname="Steve Hanna"/> for the valuable secdir review and
      J&uuml;rgen Sch&ouml;nw&auml;lder
      <contact fullname="Juergen Schoenwaelder"/> for the opsdir review.</t>
      <t>Thanks to Greg Mirsky <contact fullname="Greg Mirsky"/> for the Shepherd review.</t> <contact
      fullname="Shepherd review"/>.</t>
      <t>Thanks to Alvaro Retana, Lars Eggert, Martin Duke, Erik Kline,
      Zaheduzzaman Sarker, &Eacute;ric Vyncke, Roman Danyliw, Murray
      Kucherawy, John Scudder, and Benjamin Kaduk <contact fullname="Alvaro Retana"/>, <contact
      fullname="Lars Eggert"/>, <contact fullname="Martin Duke"/>, <contact
      fullname="Erik Kline"/>, <contact fullname="Zaheduzzaman Sarker"/>,
      <contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>,
      <contact fullname="Murray Kucherawy"/>, <contact fullname="John
      Scudder"/>, and <contact fullname="Benjamin Kaduk"/> for the IESG
      review.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.8300"?>

      <?rfc include='reference.RFC.7665'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.4868'?>

      <?rfc include='reference.RFC.5116'?>

      <?rfc include='reference.RFC.4107'?>

      <?rfc include='reference.RFC.2104'?>

      <reference anchor="GCM">
        <front>
          <title>Recommendation for Block Cipher Modes of Operation:
          Galois/Counter Mode (GCM) and GMAC</title>

          <author initials="M." surname="Dworkin">
            <organization></organization>
          </author>

          <date month="November" year="2007" />
        </front>

        <seriesInfo name="NIST" value="Special Publication 800-38D" />
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.8459"?>

      <?rfc include='reference.RFC.8877'?>

      <?rfc include='reference.RFC.7498'?>

      <?rfc include='reference.RFC.5905'?>

      <?rfc include="reference.RFC.7258"?>

      <?rfc include="reference.RFC.6973"?>

      <?rfc include='reference.RFC.8165'?>

      <?rfc include='reference.I-D.ietf-intarea-tunnels'?>

      <?rfc include='reference.I-D.arkko-farrell-arch-model-t'?>

      <?rfc include='reference.I-D.nguyen-sfc-security-architecture'?>

      <?rfc include='reference.I-D.irtf-cfrg-aead-limits'?>

      <?rfc include='reference.RFC.7635'?>

      <?rfc include='reference.RFC.8915'?>

      <?rfc include='reference.RFC.8633'?>

      <?rfc include='reference.RFC.4046'?>

      <!---->
    </references>

  </back>
</rfc>