rfc9145xml2.original.xml   rfc9145.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
An alternate method (rfc include) is described in the references. -->
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<!-- For a complete list and description of processing instructions (PIs), tf-sfc-nsh-integrity-09" number="9145" ipr="trust200902" obsoletes="" updates="
please see http://xml.resource.org/authoring/README.html. --> " submissionType="IETF" xml:lang="en" consensus="true" tocInclude="true" tocDept
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds h="4" symRefs="true" sortRefs="true" version="3">
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 category="std" docName="draft-ietf-sfc-nsh-integrity-09"
ipr="trust200902">
<front> <front>
<title abbrev="Integrity Protection for the NSH">Integrity Protection for <title abbrev="Integrity Protection for the NSH">Integrity Protection for
the Network Service Header (NSH) and Encryption of Sensitive Context the Network Service Header (NSH) and Encryption of Sensitive Context
Headers</title> Headers</title>
<seriesInfo name="RFC" value="9145"/>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Akamai</organization> <organization>Akamai</organization>
<address> <address>
<postal> <postal>
<street>Embassy Golf Link Business Park</street> <street>Embassy Golf Link Business Park</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560071</code> <code>560071</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Dan Wing" initials="D." surname="Wing"> <author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization> <organization abbrev="Citrix">Citrix Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<country>USA</country> <country>USA</country>
</postal> </postal>
<email>dwing-ietf@fuggles.com</email> <email>dwing-ietf@fuggles.com</email>
</address> </address>
</author> </author>
<date month="December" year="2021"/>
<date />
<workgroup>SFC</workgroup> <workgroup>SFC</workgroup>
<keyword>Security</keyword> <keyword>Security</keyword>
<keyword>Resilience</keyword> <keyword>Resilience</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Service delivery</keyword> <keyword>Service delivery</keyword>
<keyword>Providers</keyword> <keyword>Providers</keyword>
<keyword>Differentiated services</keyword> <keyword>Differentiated services</keyword>
<keyword>Traffic Engineering</keyword> <keyword>Traffic Engineering</keyword>
<keyword>Attack mitigation</keyword> <keyword>Attack mitigation</keyword>
<abstract> <abstract>
<t>This specification presents an optional method to add integrity <t>This specification presents an optional method to add integrity
protection directly to the Network Service Header (NSH) used for Service protection directly to the Network Service Header (NSH) used for Service
Function Chaining (SFC). Also, this specification allows for the Function Chaining (SFC). Also, this specification allows for the
encryption of sensitive metadata that is carried in the NSH.</t> encryption of sensitive metadata (MD) that is carried in the NSH.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>Many advanced Service Functions (SFs) are enabled for the delivery of <t>Many advanced Service Functions (SFs) are enabled for the delivery of
value-added services. Typically, SFs are used to meet various service value-added services. Typically, SFs are used to meet various service
objectives such as IP address sharing, avoiding covert channels, objectives such as IP address sharing, avoiding covert channels,
detecting Denial-of-Service (DoS) attacks and protecting network detecting Denial-of-Service (DoS) attacks and protecting network
infrastructures against them, network slicing, etc. Because of the infrastructures against them, network slicing, etc. Because of the
proliferation of such advanced SFs together with complex service proliferation of such advanced SFs together with complex service
deployment constraints that demand more agile service delivery deployment constraints that demand more agile service delivery
procedures, operators need to rationalize their service delivery logic procedures, operators need to rationalize their service delivery logic
and control its complexity while optimising service activation time and control its complexity while optimizing service activation time
cycles. The overall problem space is described in <xref cycles. The overall problem space is described in <xref target="RFC7498" f
target="RFC7498"></xref>.</t> ormat="default"/>.</t>
<t><xref target="RFC7665" format="default"/> presents a data plane
<t><xref target="RFC7665"></xref> presents a data plane architecture architecture addressing the problematic aspects of existing service
addressing the problematic aspects of existing service deployments, deployments, including topological dependence and configuration
including topological dependence and configuration complexity. It also complexity. It also describes an architecture for the specification,
describes an architecture for the specification, creation, and creation, and maintenance of Service Function Chains (SFCs) within a
maintenance of Service Function Chains (SFCs) within a network. That is, network, that is, how to define an ordered set of SFs and ordering
how to define an ordered set of SFs and ordering constraints that must constraints that must be applied to packets/flows selected as a result
be applied to packets/flows selected as a result of traffic of traffic classification. <xref target="RFC8300" format="default"/>
classification. <xref target="RFC8300"></xref> specifies the SFC specifies the SFC encapsulation: Network Service Header (NSH).</t>
encapsulation: Network Service Header (NSH).</t>
<t>The NSH data is unauthenticated and unencrypted, forcing a service <t>The NSH data is unauthenticated and unencrypted, forcing a service
topology that requires security and privacy to use a transport topology that requires security and privacy to use a transport
encapsulation that supports such features (Section 8.2 of <xref encapsulation that supports such features (<xref target="RFC8300" section=
target="RFC8300"></xref>).</t> "8.2" sectionFormat="of"/>).</t>
<t>Note that some transport encapsulations (e.g., IPsec) only provide <t>Note that some transport encapsulations (e.g., IPsec) only provide
hop-by-hop security between two SFC data plane elements (e.g., two hop-by-hop security between two SFC data plane elements (e.g., two
Service Function Forwarders (SFFs), SFF to SF) and do not provide 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 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 or SFs within a Service Function Path (SFP) that are not authorized to
access the sensitive metadata (e.g., privacy-sensitive information) will access the sensitive metadata (e.g., privacy-sensitive information) will
have access to the metadata. As a reminder, the metadata referred to is have access to the metadata. As a reminder, the metadata referred to is
information that is inserted by Classifiers or intermediate SFs and information that is inserted by Classifiers or intermediate SFs and
shared with downstream SFs; such information is not visible to the shared with downstream SFs; such information is not visible to the
communication endpoints (Section 4.9 of <xref communication endpoints (<xref target="RFC7665" section="4.9"
target="RFC7665"></xref>).</t> sectionFormat="of"/>).</t>
<t>The lack of such capability was reported during the development of <t>The lack of such capability was reported during the development of
<xref target="RFC8300"></xref> and <xref target="RFC8459"></xref>. The <xref target="RFC8300" format="default"/> and <xref target="RFC8459"
reader may refer to Section 3.2.1 of <xref format="default"/>. The reader may refer to <xref
target="I-D.arkko-farrell-arch-model-t"></xref> for a discussion on the target="I-D.arkko-farrell-arch-model-t" section="3.2.1"
need for more awareness about attacks from within closed domains.</t> 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 <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 "NSH Variable Header-Based Integrity" option mentioned in <xref
of <xref target="RFC8300"></xref>). Concretely, this document adds target="RFC8300" section="8.2.1" sectionFormat="of"/>). Concretely, this
integrity protection and optional encryption of sensitive metadata document adds integrity protection and optional encryption of sensitive
directly to the NSH (<xref target="overview"></xref>). The integrity metadata directly to the NSH (<xref target="overview"
protection covers the packet payload and provides replay protection format="default"/>). The integrity protection covers the packet payload
(<xref target="time"></xref>). Thus, the NSH does not have to rely upon and provides replay protection (<xref target="time"
an underlying transport encapsulation for security.</t> 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 <t>This specification introduces new Variable-Length Context Headers to
carry fields necessary for integrity-protected NSH headers and encrypted carry fields necessary for integrity-protected NSH headers and encrypted
Context Headers (<xref target="new"></xref>). This specification is only Context Headers (<xref target="new" format="default"/>). This
applicable to NSH MD Type 0x02 (Section 2.5 of <xref specification is only applicable to NSH MD Type 0x02 (<xref
target="RFC8300"></xref>). MTU considerations are discussed in <xref target="RFC8300" section="2.5" sectionFormat="of"/>). MTU considerations
target="MTU"></xref>. This specification is not applicable to NSH MD are discussed in <xref target="MTU" format="default"/>. This
Type 0x01 (Section 2.4 of <xref target="RFC8300"></xref>) because that specification is not applicable to NSH MD Type 0x01 (<xref
MD Type only allows a Fixed-Length Context Header whose size is target="RFC8300" section="2.4" sectionFormat="of"/>) because that MD
16-bytes; that is not sufficient to accommodate both the metadata and Type only allows a Fixed-Length Context Header whose size is 16 bytes;
message integrity of the NSH data.</t> 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 <t>This specification limits access to NSH-supplied information along an
SFP to entities that have a need to interpret it.</t> SFP to entities that have a need to interpret it.</t>
<t>The mechanism specified in this document does not preclude the use of <t>The mechanism specified in this document does not preclude the use of
transport security. Such considerations are deployment-specific.</t> transport security. Such considerations are deployment specific.</t>
<t>It is out of the scope of this document to specify an NSH-aware <t>It is out of the scope of this document to specify an NSH-aware
control plane solution.</t> control plane solution.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="notation" title="Terminology"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
format="default"/> <xref target="RFC8174" format="default"/> when, and
only when, they appear in all capitals, as shown here.</t> only when, they appear in all capitals, as shown here.</t>
<t>This document makes use of the terms defined in <xref <t>This document makes use of the terms defined in <xref
target="RFC7665"></xref> and <xref target="RFC8300"></xref>. The term target="RFC7665" format="default"/> and <xref target="RFC8300"
"transport encapsulation" used in this document refers to the outer format="default"/>. The term "transport encapsulation" used in this
encapsulation (e.g., Generic Routing Encapsulation (GRE), IPsec, Generic document refers to the outer encapsulation (e.g., Generic Routing
Protocol Extension for VXLAN (VXLAN-GPE)) that is used to carry Encapsulation (GRE), IPsec, and Generic Protocol Extension for Virtual
NSH-encapsulated packets as per Section 4 of <xref eXtensible Local Area Network (VXLAN-GPE)) that is used to carry
target="RFC8300"></xref>.</t> NSH-encapsulated packets as per <xref target="RFC8300" section="4"
sectionFormat="of"/>.</t>
<t>The document defines the following terms:<list style="hanging">
<t hangText="SFC data plane element:">Refers to NSH-aware SF, SFF,
SFC Proxy, or Classifier as defined in the SFC data plane
architecture <xref target="RFC7665"></xref> and further refined in
<xref target="RFC8300"></xref>.</t>
<t hangText="SFC control element:">Is a logical entity that <t>The document defines the following terms:</t>
<dl newline="false" spacing="normal">
<dt>SFC data plane 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" format="default"/> and further ref
ined in
<xref target="RFC8300" format="default"/>.</dd>
<dt>SFC control element:</dt>
<dd>Is a logical entity that
instructs one or more SFC data plane elements on how to process NSH instructs one or more SFC data plane elements on how to process NSH
packets within an SFC-enabled domain.</t> packets within an SFC-enabled domain.</dd>
<dt>Key Identifier:</dt>
<t hangText="Key Identifier:">Is used to identify keys to authorized <dd>Is used to identify keys to authorized entities. See, for example,
entities. See, for example, 'kid' usage in <xref "kid" usage in <xref target="RFC7635" format="default"/>.</dd>
target="RFC7635"></xref>.</t> <dt>NSH data:</dt>
<dd>The NSH is composed of a Base Header, a
<t hangText="NSH data:">The NSH is composed of a Base Header, a
Service Path Header, and optional Context Headers. NSH data refers 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 to all the above headers and the packet or frame on which the NSH is
imposed to realize an SFP.</t> imposed to realize an SFP.</dd>
<dt>NSH imposer:</dt>
<t hangText="NSH imposer:">Refers to an SFC data plane element that <dd>Refers to an SFC data plane element that
is entitled to impose the NSH with the Context Headers defined in is entitled to impose the NSH with the Context Headers defined in
this document.</t> this document.</dd>
</list></t> </dl>
</section> </section>
<section anchor="req" numbered="true" toc="default">
<name>Assumptions and Basic Requirements</name>
<t><xref target="RFC8300" section="2" sectionFormat="of"/> specifies that
the NSH
data can be spread over three headers:</t>
<section anchor="req" title="Assumptions and Basic Requirements"> <dl>
<t>Section 2 of <xref target="RFC8300"></xref> specifies that the NSH
data can be spread over three headers:<list style="symbols">
<t>Base Header: Provides information about the service header and
the payload protocol.</t>
<t>Service Path Header: Provides path identification and location <dt>Base Header:
within an SFP.</t> </dt>
<dd>Provides information about the service header and the payload protoco
l.
</dd>
<t>Context Header(s): Carries metadata (i.e., context data) along a <dt>Service Path Header:
service path.</t> </dt>
</list></t> <dd>Provides path identification and location within an SFP.
</dd>
<t>The NSH allows sharing context information (a.k.a., metadata) with <dt>Context Header(s):
downstream NSH-aware data plane elements on a per SFC/SFP basis. To that </dt>
aim:<list style="empty"> <dd>Carries metadata (i.e., context data) along a service path.
<t>The Classifier is instructed by an SFC control element about the </dd>
set of context information to be supplied for a given service
function chain.</t>
<t>An NSH-aware SF is instructed by an SFC control element about any </dl>
<t>The NSH allows sharing context information (a.k.a. metadata) with
downstream NSH-aware data plane elements on a per-SFC/SFP basis. To that
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.</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 metadata it needs to attach to packets for a given service function
chain. This instruction may occur any time during the validity chain. This instruction may occur any time during the validity
lifetime of an SFC/SFP. For a given service function chain, the 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 NSH-aware SF is also provided with an order for consuming a set of
contexts supplied in a packet.</t> contexts supplied in a packet.</li>
<li>An NSH-aware SF can also be instructed by an SFC control element
<t>An NSH-aware SF can also be instructed by an SFC control element
about the behavior it should adopt after consuming context about the behavior it should adopt after consuming context
information that was supplied in the NSH. For example, the context information that was supplied in the NSH. For example, the context
information can be maintained, updated, or stripped.</t> information can be maintained, updated, or stripped.</li>
<li>An SFC Proxy may be instructed by an SFC control element about
<t>An SFC Proxy may be instructed by an SFC control element about
the behavior it should adopt to process the context information that 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 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 context information can be maintained or stripped). The SFC Proxy
may also be instructed to add some new context information into the may also be instructed to add some new context information into the
NSH on behalf of an NSH-unaware SF.</t> NSH on behalf of an NSH-unaware SF.</li>
</list></t> </ul>
<t>In reference to <xref target="NSH"/>:</t>
<t>In reference to Table 1, <list style="symbols"> <ul spacing="normal">
<t>Classifiers, NSH-aware SFs, and SFC proxies are entitled to <li>Classifiers, NSH-aware SFs, and SFC proxies are entitled to
update the Context Header(s).</t> update the Context Header(s).</li>
<li>Only NSH-aware SFs and SFC proxies are entitled to update the
<t>Only NSH-aware SFs and SFC proxies are entitled to update the Service Path Header.</li>
Service Path Header.</t> <li>SFFs are entitled to modify the Base Header (TTL value, for
<t>SFFs are entitled to modify the Base Header (TTL value, for
example). Nevertheless, SFFs are not supposed to act on the Context example). Nevertheless, SFFs are not supposed to act on the Context
Headers or look into the content of the Context Headers (Section 4.3 Headers or look into the content of the Context Headers (<xref target=
of <xref target="RFC7665"></xref>).</t> "RFC7665" section="4.3" sectionFormat="of"/>).</li>
</list></t> </ul>
<t>Thus, the following 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.</li>
<li>Both encrypted and unencrypted Context Headers may be included in
the same NSH.</li>
<li>The solution must provide integrity protection for the Service
Path 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" format="default"/>.</li>
</ul>
<t>Thus, the following requirements:<list style="symbols"> <table anchor="NSH">
<t>Only Classifiers, NSH-aware SFs, and SFC proxies must be able to <name>Summary of NSH Actions</name>
encrypt and decrypt a given Context Header.</t> <thead>
<tr>
<th rowspan="2" colspan="1" align="center">SFC Data Plane Element</th
>
<th colspan="3" align="center">Insert, remove, or replace the 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 Index</th>
<th align="center">Update Context Header(s)</th>
<t>Both encrypted and unencrypted Context Headers may be included in </tr>
the same NSH.</t>
<t>The solution must provide integrity protection for the Service </thead>
Path Header.</t> <tbody>
<tr>
<td>Classifier</td>
<td align="center">+</td>
<td></td>
<td align="center">+</td>
<td></td>
<td align="center">+</td>
</tr>
<t>The solution must provide optional integrity protection for the <tr>
Base Header. The implications of disabling such checks are discussed <td>Service Function Forwarder (SFF)</td>
in <xref target="mac1"></xref>.</t> <td></td>
</list></t> <td align="center">+</td>
<td></td>
<td></td>
<td></td>
</tr>
<t><figure align="center"> <tr>
<artwork align="center"><![CDATA[+----------------+------------------- <td>Service Function (SF)</td>
----------+-------------------+ <td></td>
| | Insert, remove, or replace | Update the NSH | <td></td>
| | the NSH | | <td></td>
| | | | <td align="center">+</td>
| SFC Data Plane +---------+---------+---------+---------+---------+ <td align="center">+</td>
| Element | | | |Decrement| Update | </tr>
| | Insert | Remove | Replace | Service | Context |
| | | | | Index |Header(s)|
+================+=========+=========+=========+=========+=========+
| | + | | + | | + |
| Classifier | | | | | |
+----------------+---------+---------+---------+---------+---------+
|Service Function| | + | | | |
|Forwarder (SFF) | | | | | |
+----------------+---------+---------+---------+---------+---------+
|Service Function| | | | + | + |
| (SF) | | | | | |
+----------------+---------+---------+---------+---------+---------+
| | + | + | | + | + |
| SFC Proxy | | | | | |
+----------------+---------+---------+---------+---------+---------+
Table 1: Summary of NSH Actions]]></artwork> <tr>
</figure></t> <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>
<t></t>
</section> </section>
<section anchor="overview" numbered="true" toc="default">
<name>Design Overview</name>
<section anchor="overview" title="Design Overview"> <section numbered="true" toc="default">
<t></t> <name>Supported Security Services</name>
<section title="Supported Security Services">
<t>This specification provides the functions described in the <t>This specification provides the functions described in the
following subsections.</t> following subsections.</t>
<section numbered="true" toc="default">
<section title="Encrypt All or a Subset of Context Headers"> <name>Encrypt All or a Subset of Context Headers</name>
<t>The solution allows encrypting all or a subset of NSH Context <t>The solution allows encrypting all or a subset of NSH Context
Headers by Classifiers, NSH-aware SFs, and SFC proxies.</t> Headers by Classifiers, NSH-aware SFs, and SFC proxies.</t>
<t>As depicted in <xref target="encryption"/>, SFFs are not involved i
<t>As depicted in Table 2, SFFs are not involved in data n data
encryption.</t> encryption.</t>
<t><figure> <table anchor="encryption">
<artwork><![CDATA[ +-----------------+-------------------------- <name>Encryption Function Supported by SFC Data Plane Elements</name>
----+------------------+ <thead>
| Data Plane | Base and Service Path | Context Header | <tr>
| Element | Headers Encryption | Encryption | <th> Data Plane Element</th>
+-----------------+------------------------------+------------------+ <th> Base and Service Path Headers Encryption</th>
| Classifier | No | Yes | <th>Context Header Encryption</th>
| SFF | No | No | </tr>
| NSH-aware SF | No | Yes | </thead>
| SFC Proxy | No | Yes |
| NSH-unaware SF | No | No |
+-----------------+------------------------------+------------------+
Table 2: Encryption Function Supported by SFC Data Plane Elements]]></artwo <tbody>
rk> <tr>
</figure></t> <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</td>
<td>No</td>
<td>Yes</td>
</tr><tr>
<td>SFC Proxy</td>
<td> No </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 <t>Classifier(s), NSH-aware SFs, and SFC proxies are instructed with
the set of Context Headers (privacy-sensitive metadata, typically) the set of Context Headers (privacy-sensitive metadata, typically)
that must be encrypted. Encryption keying material is only provided that must be encrypted. Encryption keying material is only provided
to these SFC data plane elements.</t> to these SFC data plane elements.</t>
<t>The control plane may indicate the set of SFC data plane elements <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 that are entitled to supply a given Context Header (e.g., in
reference to their identifiers as assigned within the SFC-enabled reference to their identifiers as assigned within the SFC-enabled
domain). It is out of the scope of this document to elaborate on how domain). It is out of the scope of this document to elaborate on how
such instructions are provided to the appropriate SFC data plane such instructions are provided to the appropriate SFC data plane
elements, nor to detail the structure used to store the elements nor to detail the structure used to store the
instructions.</t> instructions.</t>
<t>The Service Path Header (<xref target="RFC8300" section="2" section
<t>The Service Path Header (Section 2 of <xref Format="of"/>) is not encrypted because SFFs use the Service
target="RFC8300"></xref>) is not encrypted because SFFs use Service Index (SI) in conjunction with the Service Path Identifier (SPI) for
Index (SI) in conjunction with Service Path Identifier (SPI) for
determining the next SF in the path.</t> determining the next SF in the path.</t>
</section> </section>
<section title="Integrity Protection"> <section numbered="true" toc="default">
<name>Integrity Protection</name>
<t>The solution provides integrity protection for the NSH data. Two <t>The solution provides integrity protection for the NSH data. Two
levels of assurance (LoAs) are supported.</t> levels of assurance (LoAs) are supported.</t>
<t>The first level of assurance is where all NSH data except the <t>The first level of assurance is where all NSH data except the
Base Header are integrity protected (<xref target="first"></xref>). Base Header are integrity protected (<xref target="first" format="defa ult"/>).
In this case, the NSH imposer may be a Classifier, an NSH-aware SF, 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. or an SFC Proxy. SFFs are not provided with authentication material.
Further details are discussed in <xref target="enc1"></xref>.<figure Further details are discussed in <xref target="enc1" format="default"/
align="center" anchor="first" title="First Level of Assurance"> >.</t>
<artwork align="center"><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- <figure anchor="first">
+-+-+-+-+-+-+-+-+-+-+-+-+-+ <name>First Level of Assurance</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ +-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Encapsulation | | Transport Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Base Header | | | Base Header | |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| | Service Path Header | S | | Service Path Header | S
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| | Context Header(s) | | | | Context Header(s) | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Original Packet | | | Original Packet |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+------Scope of integrity protected data +------Scope of integrity-protected data
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The second level of assurance is where all NSH data, including <t>The second level of assurance is where all NSH data, including
the Base Header, are integrity protected (<xref the Base Header, are integrity protected (<xref target="sec" format="d
target="sec"></xref>). In this case, the NSH imposer may be a efault"/>). In this case, the NSH imposer may be a
Classifier, an NSH-aware SF, an SFF, or an SFC Proxy. Further Classifier, an NSH-aware SF, an SFF, or an SFC Proxy. Further
details are provided in <xref target="enc2"></xref>.</t> details are provided in <xref target="enc2" format="default"/>.</t>
<figure anchor="sec">
<t><figure align="center" anchor="sec" <name>Second Level of Assurance</name>
title="Second Level of Assurance"> <artwork align="center" name="" type="" alt=""><![CDATA[ +-+-+-+-+
<artwork align="center"><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Encapsulation | | Transport Encapsulation |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Base Header | | | | Base Header | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| | Service Path Header | S | | Service Path Header | S
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| | Context Header(s) | | | | Context Header(s) | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Original Packet | | | Original Packet |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+----Scope of integrity protected data +----Scope of integrity-protected data
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The integrity-protection scope is explicitly signaled to
<t>The integrity protection scope is explicitly signaled to
NSH-aware SFs, SFFs, and SFC proxies in the NSH by means of a NSH-aware SFs, SFFs, and SFC proxies in the NSH by means of a
dedicated MD Type (<xref target="new"></xref>).</t> dedicated MD Type (<xref target="new" format="default"/>).</t>
<t>In both levels of assurance, the Context Headers and the packet <t>In both levels of assurance, the Context Headers and the packet
on which the NSH is imposed are subject to integrity protection.</t> on which the NSH is imposed are subject to integrity protection.</t>
<t><xref target="integrity"/> classifies the data plane elements as be
ing involved or not involved in
providing integrity protection for the NSH.</t>
<t>Table 3 classifies the data plane elements as being involved in <table anchor="integrity">
providing integrity protection for the NSH or not.</t> <name>Integrity Protection Supported by SFC Data Plane Elements</name
>
<thead>
<tr>
<th>Data Plane Element</th>
<th>Integrity Protection</th>
</tr>
</thead>
<tbody>
<tr>
<t><figure> <td> Classifier</td>
<artwork><![CDATA[ +--------------------+----------------- <td> Yes</td>
-----------------+ </tr><tr>
| Data Plane Element | Integrity Protection |
+--------------------+----------------------------------+ <td> SFF</td>
| Classifier | Yes | <td> No (first LoA); Yes (second LoA)</td>
| SFF | No (first LoA); Yes (second LoA) | </tr><tr>
| NSH-aware SF | Yes |
| SFC Proxy | Yes | <td> NSH-aware SF</td>
| NSH-unaware SF | No | <td>Yes</td>
+--------------------+----------------------------------+ </tr><tr>
<td> SFC Proxy</td>
<td>Yes</td>
</tr><tr>
<td> NSH-unaware SF</td>
<td> No</td>
</tr>
</tbody>
</table>
Table 3: Integrity Protection Supported by SFC Data Plane Elements]]></artwo
rk>
</figure></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="One Secret Key, Two Security Services"> <name>One Secret Key, Two Security Services</name>
<t>The Authenticated Encryption with Associated Data (AEAD) interface <t>The Authenticated Encryption with Associated Data (AEAD) interface
defined in Section 5 of <xref target="RFC5116"></xref> is used to defined in <xref target="RFC5116" section="5" sectionFormat="of"/> is us ed to
encrypt the Context Headers that carry sensitive metadata and to encrypt the Context Headers that carry sensitive metadata and to
provide integrity protection for the encrypted Context Headers.</t> provide integrity protection for the encrypted Context Headers.</t>
<t>The secondary keys "MAC_KEY" and "ENC_KEY" are generated from the inp
<t>The secondary keys MAC_KEY and ENC_KEY are generated from the input ut
secret key (K) as follows; each of these two keys is an octet secret key (K) as follows; each of these two keys is an octet
string:<list style="hanging"> string:</t>
<t hangText="MAC_KEY:">consists of the initial MAC_KEY_LEN octets <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 of K, in order. The MAC_KEY is used for calculating the message
integrity of the NSH data. In other words, the integrity integrity of the NSH data. In other words, the integrity
protection provided by the cryptographic mechanism is extended to protection provided by the cryptographic mechanism is extended to
also provide protection for the unencrypted Context Headers and also provide protection for the unencrypted Context Headers and
the packet on which the NSH is imposed.</t> the packet on which the NSH is imposed.</dd>
<dt>ENC_KEY:</dt>
<t hangText="ENC_KEY:">consists of the final ENC_KEY_LEN octets of <dd>Consists of the final ENC_KEY_LEN octets of
K, in order. The ENC_KEY is used as the symmetric encryption key K, in order. The ENC_KEY is used as the symmetric encryption key
for encrypting the Context Headers.</t> for encrypting the Context Headers.</dd>
</list></t> </dl>
<t>The Hashed Message Authentication Code (HMAC) algorithm discussed
<t>The Hashed Message Authentication Mode (HMAC) algorithm discussed in <xref target="RFC4868" format="default"/> is used to protect the inte
in <xref target="RFC4868"></xref> is used to protect the integrity of grity of
the NSH data. The algorithm for implementing and validating HMACs is the NSH data. The algorithm for implementing and validating HMACs is
provided in <xref target="RFC2104"></xref>.</t> provided in <xref target="RFC2104" format="default"/>.</t>
<t>The advantage of using both AEAD and HMAC algorithms (instead of <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 just AEAD) is that NSH-aware SFs and SFC proxies only need to
re-compute the message integrity of the NSH data after decrementing recompute the message integrity of the NSH data after decrementing
the Service Index (SI) and do not have to re-compute the ciphertext. the SI and do not have to recompute the ciphertext.
The other advantage is that SFFs do not have access to the ENC_KEY and The other advantage is that SFFs do not have access to the ENC_KEY and
cannot act on the encrypted Context Headers and (in the case of the cannot act on the encrypted Context Headers, and (in the case of the
second level of assurance) SFFs do have access to the MAC_KEY. 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 Similarly, an NSH-aware SF or SFC Proxy not allowed to decrypt the
Context Headers will not have access to the ENC_KEY.</t> Context Headers will not have access to the ENC_KEY.</t>
<t>The authenticated encryption algorithm or HMAC algorithm to be used <t>The authenticated encryption algorithm or HMAC algorithm to be used
by SFC data plane elements is typically controlled using the SFC by SFC data plane elements is typically controlled using the SFC
control plane. Mandatory to implement authenticated encryption and control plane. Mandatory-to-implement authenticated encryption and
HMAC algorithms are listed in <xref target="mti"></xref>.</t> HMAC algorithms are listed in <xref target="mti" format="default"/>.</t>
<t>The authenticated encryption process takes four inputs, each of <t>The authenticated encryption process takes four inputs, each of
which is an octet string: a secret key (ENC_KEY, referred to as K in which is an octet string: a secret key (ENC_KEY, referred to as "K" in
<xref target="RFC5116"></xref>), a plaintext (P), associated data (A) <xref target="RFC5116" format="default"/>), a plaintext (P), associated
(which contains the data to be authenticated, but not encrypted), and data (A)
(which contains the data to be authenticated but not encrypted), and
a nonce (N). A ciphertext (C) is generated as an output as discussed a nonce (N). A ciphertext (C) is generated as an output as discussed
in Section 2.1 of <xref target="RFC5116"></xref>.</t> in <xref target="RFC5116" section="2.1" sectionFormat="of"/>.</t>
<t>In order to decrypt and verify, the cipher takes ENC_KEY,
<t>In order to decrypt and verify, the cipher takes as input ENC_KEY, N, A, and C as input. The output is either the plaintext or an error ind
N, A, and C. The output is either the plaintext or an error indicating icating
that the decryption failed as described in Section 2.2 of <xref that the decryption failed as described in <xref target="RFC5116" sectio
target="RFC5116"></xref>.</t> n="2.2" sectionFormat="of"/>.</t>
</section> </section>
<section anchor="mti" numbered="true" toc="default">
<section anchor="mti" <name>Mandatory-to-Implement Authenticated Encryption and HMAC Algorithm
title="Mandatory-to-Implement Authenticated Encryption and HMAC A s</name>
lgorithms"> <t>Classifiers, NSH-aware SFs, and SFC proxies <bcp14>MUST</bcp14> imple
<t>Classifiers, NSH-aware SFs, and SFC proxies MUST implement the ment the
AES_128_GCM <xref target="GCM"></xref><xref target="RFC5116"></xref> AES_128_GCM <xref target="GCM" format="default"/><xref target="RFC5116"
algorithm and SHOULD implement the AES_192_GCM and AES_256_GCM format="default"/>
algorithm and <bcp14>SHOULD</bcp14> implement the AES_192_GCM and AES_25
6_GCM
algorithms.</t> algorithms.</t>
<t>Classifiers, NSH-aware SFs, and SFC proxies <bcp14>MUST</bcp14> imple
<t>Classifiers, NSH-aware SFs, and SFC proxies MUST implement the ment the
HMAC- SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 HMAC- SHA-256-128 algorithm and <bcp14>SHOULD</bcp14> implement the HMAC
-SHA-384-192
and HMAC-SHA-512-256 algorithms.</t> and HMAC-SHA-512-256 algorithms.</t>
<t>SFFs <bcp14>MAY</bcp14> implement the aforementioned cipher suites an
d HMAC
algorithms.
</t>
<t>SFFs MAY implement the aforementioned cipher suites and HMAC <t indent="3"> Note: The use of the AES_128_CBC_HMAC_SHA_256 algorithm wo
algorithms.</t> uld
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 Message Authentication Co
de (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>
<t><list style="hanging">
<t hangText="Note:">The use of 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 malleability of
plaintexts. This malleability allows for attackers that know the
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>
</section> </section>
<section anchor="kms" numbered="true" toc="default">
<section anchor="kms" title="Key Management"> <name>Key Management</name>
<t>The procedure for the allocation/provisioning of secret keys (K) <t>The procedure for the allocation/provisioning of secret keys (K)
and authenticated encryption algorithm or MAC_KEY and HMAC algorithm and the authenticated encryption algorithm or MAC_KEY and HMAC algorithm
is outside the scope of this specification. As such, this is outside the scope of this specification. As such, this
specification does not mandate the support of any specific specification does not mandate the support of any specific
mechanism.</t> mechanism.</t>
<t>The document does not assume nor preclude the following:</t>
<t>The document does not assume nor preclude the following:<list <ul spacing="normal">
style="symbols"> <li>The same keying material is used for all the service functions
<t>The same keying material is used for all the service functions used within an SFC-enabled domain.</li>
used within an SFC-enabled domain.</t> <li>Distinct keying material is used per SFP by all involved SFC
data path elements.</li>
<t>Distinct keying material is used per SFP by all involved SFC <li>Per-tenant keys are used.</li>
data path elements.</t> </ul>
<t>Per-tenant keys are used.</t>
</list></t>
<t>In order to accommodate deployments relying upon keying material <t>In order to accommodate deployments relying upon keying material
per SFC/SFP and also the need to update keys after encrypting NSH data 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 for a certain amount of time, this document uses key identifiers to
unambiguously identify the appropriate keying material and associated unambiguously identify the appropriate keying material and associated
algorithms for MAC and encryption. This use of in-band identifiers algorithms for MAC and encryption. This use of in-band identifiers
addresses the problem of synchronization of keying material.</t> addresses the problem of the synchronization of keying material.</t>
<t>Additional information on manual vs. automated key management and <t>Additional information on manual vs. automated key management and
when one should be used over the other can be found in <xref when one should be used over the other can be found in <xref target="RFC
target="RFC4107"></xref>.</t> 4107" format="default"/>.</t>
<t>The risk involved in using a group-shared symmetric key increases <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 with the size of the group to which it is shared. Additional security
issues are discussed in <xref target="Security"></xref>.</t> issues are discussed in <xref target="Security" format="default"/>.</t>
</section> </section>
<section anchor="newch" numbered="true" toc="default">
<section anchor="newch" title="New NSH Variable-Length Context Headers"> <name>New NSH Variable-Length Context Headers</name>
<t>New NSH Variable-Length Context Headers are defined in <xref <t>New NSH Variable-Length Context Headers are defined in <xref target="
target="new"></xref> for NSH data integrity protection and, new" format="default"/> for NSH data integrity protection and,
optionally, encryption of Context Headers carrying sensitive metadata. optionally, encryption of Context Headers carrying sensitive metadata.
Concretely, an NSH imposer includes (1) the key identifier to identify Concretely, an NSH imposer includes (1) the key identifier to identify
the keying material, (2) the timestamp to protect against replay the keying material, (2) the timestamp to protect against replay
attacks (<xref target="time"></xref>), and (3) the Message attacks (<xref target="time" format="default"/>), and (3) MAC for the ta
Authentication Code (MAC) for the target NSH data (depending on the rget NSH data (depending on the
integrity protection scope) calculated using the MAC_KEY and integrity-protection scope) calculated using MAC_KEY and,
optionally Context Headers encrypted using ENC_KEY.</t> optionally, Context Headers encrypted using ENC_KEY.</t>
<t>An SFC data plane element that needs to check the integrity of the <t>An SFC data plane element that needs to check the integrity of the
NSH data uses MAC_KEY and the HMAC algorithm for the key identifier NSH data uses the MAC_KEY and HMAC algorithm for the key identifier
being carried in the NSH.</t> being carried in the NSH.</t>
<t>An NSH-aware SF or SFC Proxy that needs to decrypt some Context <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 Headers uses ENC_KEY and the decryption algorithm for the key
identifier being carried in the NSH.</t> identifier being carried in the NSH.</t>
<t><xref target="prorules" format="default"/> specifies the detailed
<t><xref target="prorules"></xref> specifies the detailed
procedure.</t> procedure.</t>
</section> </section>
<section anchor="nsh-in-nsh" numbered="true" toc="default">
<section anchor="nsh-in-nsh" title="Encapsulation of NSH within NSH"> <name>Encapsulation of NSH within NSH</name>
<t>As discussed in Section 3 of <xref target="RFC8459"></xref>, an <t>As discussed in <xref target="RFC8459" section="3" sectionFormat="of"
SFC-enabled domain (called, upper-level domain) may be decomposed into />, an
many sub-domains (called, lower-level domains). In order to avoid SFC-enabled domain (called an upper-level domain) may be decomposed into
maintaining state to restore back upper-level NSH information at the many sub-domains (called lower-level domains). In order to avoid
maintaining state to restore upper-level NSH information at the
boundaries of lower-level domains, two NSH levels are used: an boundaries of lower-level domains, two NSH levels are used: an
Upper-NSH which is imposed at the boundaries of the upper-level domain Upper-NSH 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 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>). As domain in front of the original NSH (<xref target="nest" format="default "/>). As
such, the Upper-NSH information is carried along the lower-level chain such, the Upper-NSH information is carried along the lower-level chain
without modification. The packet is forwarded in the top-level domain without modification. The packet is forwarded in the top-level domain
according to the Upper-NSH, while it is forwarded according to the according to the Upper-NSH, while it is forwarded according to the
Lower-NSH in a lower-level domain.</t> Lower-NSH in a lower-level domain.</t>
<figure anchor="nest">
<t><figure align="center" anchor="nest" <name>Encapsulation of NSH within NSH</name>
title="Encapsulation of NSH within NSH"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +------------------------------- +---------------------------------+
--+
| Transport Encapsulation | | Transport Encapsulation |
+->+---------------------------------+ +->+---------------------------------+
| | Lower-NSH Header | | | Lower-NSH Header |
| +---------------------------------+ | +---------------------------------+
| | Upper-NSH Header | | | Upper-NSH Header |
| +---------------------------------+ | +---------------------------------+
| | Original Packet | | | Original Packet |
+->+---------------------------------+ +->+---------------------------------+
| |
| |
+----Scope of NSH security protection +----Scope of NSH security protection
provided by a lower-level domain provided by a lower-level domain
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>SFC data plane elements of a lower-level domain include the <t>SFC data plane elements of a lower-level domain include the
Upper-NSH when computing the MAC.</t> Upper-NSH when computing the MAC.</t>
<t>Keying material used at the upper-level domain <bcp14>SHOULD NOT</bcp
<t>Keying material used at the upper-level domain SHOULD NOT be the 14> be the
same as the one used by a lower-level domain.</t> same as the one used by a lower-level domain.</t>
</section> </section>
</section> </section>
<section anchor="new" numbered="true" toc="default">
<section anchor="new" title="New NSH Variable-Length Context Headers"> <name>New NSH Variable-Length Context Headers</name>
<t>This section specifies the format of new Variable-Length Context <t>This section specifies the format of new Variable-Length Context
headers that are used for NSH integrity protection and, optionally, Headers that are used for NSH integrity protection and, optionally,
Context Headers encryption.</t> Context Header encryption.</t>
<t>In particular, this section defines two "MAC and Encrypted Metadata" <t>In particular, this section defines two "MAC and Encrypted Metadata"
Context Headers; each having specific deployment constraints. Unlike Context Headers, each having specific deployment constraints. Unlike
<xref target="enc1"></xref>, the level of assurance provided in <xref <xref target="enc1" format="default"/>, the level of assurance provided
target="enc2"></xref> requires sharing MAC_KEY with SFFs. Both Context in <xref target="enc2" format="default"/> requires sharing MAC_KEY with
headers have the same format as shown in <xref target="mac"></xref>.</t> SFFs. Both Context Headers have the same format as shown in <xref
target="mac" format="default"/>.</t>
<t><figure align="center" anchor="mac" <figure anchor="mac">
title="MAC and Encrypted Metadata Context Header"> <name>MAC and Encrypted Metadata Context Header</name>
<artwork align="center"><![CDATA[ 0 1 <artwork align="center" name="" type="" alt=""><![CDATA[ 0
2 3 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 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 | | Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Id Len | Key Identifier (Variable) ~ | Key Id Len | Key Identifier (Variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Timestamp (8 bytes) ~ ~ Timestamp (8 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Length | Nonce (Variable) ~ | Nonce Length | Nonce (Variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code and optional Encrypted | | Message Authentication Code and optional Encrypted |
~ Context Headers (Variable) ~ ~ Context Headers (Variable) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></art work> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></art work>
</figure></t> </figure>
<t>The "MAC and Encrypted Metadata" Context Headers are padded out to a <t>The "MAC and Encrypted Metadata" Context Headers are padded out to a
multiple of 4 bytes as per Section 2.2 of <xref multiple of 4 bytes as per <xref target="RFC8300" section="2.2" sectionFor
target="RFC8300"></xref>. The "MAC and Encrypted Metadata" Context mat="of"/>.
Header, if included, MUST always be the last Context Header.</t> The "MAC and Encrypted Metadata" Context
Header, if included, <bcp14>MUST</bcp14> always be the last Context Header
<section anchor="enc1" title="MAC#1 Context Header"> .</t>
<t>MAC#1 Context Header is a variable-length Context Header that <section anchor="enc1" numbered="true" toc="default">
carries the Message Authentication Code (MAC) for the Service Path <name>MAC#1 Context Header</name>
<t>The MAC#1 Context Header is a Variable-Length Context Header that
carries MAC for the Service Path
Header, Context Headers, and the inner packet on which NSH is imposed, Header, Context Headers, and the inner packet on which NSH is imposed,
calculated using MAC_KEY, and optionally Context Headers encrypted calculated using MAC_KEY and, optionally, Context Headers encrypted
using ENC_KEY. The scope of the integrity protection provided by this using ENC_KEY. The scope of the integrity protection provided by this
Context Header is depicted in <xref target="scope1"></xref>.</t> Context Header is depicted in <xref target="scope1" format="default"/>.<
/t>
<t>This MAC scheme does not require sharing MAC_KEY with SFFs. It does <t>This MAC scheme does not require sharing MAC_KEY with SFFs. It does
not require to re-compute the MAC by each SFF because of TTL not require recomputing the MAC by each SFF because of TTL
processing. <xref target="mac1"></xref> discusses the possible threat processing. <xref target="mac1" format="default"/> discusses the possibl
e threat
associated with this level of assurance.</t> associated with this level of assurance.</t>
<figure anchor="scope1">
<figure align="center" anchor="scope1" title="Scope of MAC#1"> <name>Scope of MAC#1</name>
<artwork align="center"><![CDATA[ 0 1 <artwork align="center" name="" type="" alt=""><![CDATA[ 0
2 3 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 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 | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+
| Service Path Identifier | Service Index | | | Service Path Identifier | Service Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Variable-Length Unencrypted Context Headers (opt.) ~ | ~ Variable-Length Unencrypted Context Headers (opt.) ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Metadata Class | Type |U| Length | | | Metadata Class | Type |U| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at line 714 skipping to change at line 702
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ Encrypted Context Headers (opt.) ~ | | ~ Encrypted Context Headers (opt.) ~ |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ Message Authentication Code ~ | | ~ Message Authentication Code ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | | | |
| ~ Inner Packet on which NSH is imposed ~ | | ~ Inner Packet on which NSH is imposed ~ |
| | | | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--|
| | | |
| Integrity Protection Scope ----+ | Integrity-Protection Scope ----+
+----Encrypted Data +----Encrypted Data
]]></artwork> ]]></artwork>
</figure> </figure>
<t></t> <t>In reference to <xref target="mac" format="default"/>, the descriptio
n of the
<t>In reference to <xref target="mac"></xref>, the description of the fields is as follows:</t>
fields is as follows:<list style="hanging"> <dl newline="false" spacing="normal" indent="12">
<t hangText="Metadata Class:">MUST be set to 0x0 (Section 2.5.1 of <dt>Metadata Class:</dt>
<xref target="RFC8300"></xref>).</t> <dd><bcp14>MUST</bcp14> be set to 0x0 (<xref target="RFC8300" section=
"2.2" sectionFormat="of"/>).</dd>
<t hangText="Type:">TBD1 (See <xref target="IANA"></xref>)</t> <dt>Type:</dt>
<dd>0x02 (see <xref target="IANA" format="default"/>).</dd>
<t hangText="U:">Unassigned bit (Section 2.5.1 of <xref <dt>U:</dt>
target="RFC8300"></xref>).</t> <dd>Unassigned bit (<xref target="RFC8300" section="2.5.1" sectionForm
at="of"/>).</dd>
<t hangText="Length:">Indicates the length of the variable-length <dt>Length:</dt>
metadata, in bytes. Padding considerations are discussed in <dd>Indicates the length of the variable-length
Section 2.5.1 of <xref target="RFC8300"></xref>.</t> metadata in bytes. Padding considerations are discussed in
<xref target="RFC8300" section="2.5.1" sectionFormat="of"/>.</dd>
<t hangText="Key Id Len:">Variable. Carries the length of the key <dt>Key Id Len:</dt>
identifier, in octets.</t> <dd>Variable. Carries the length of the key
identifier in octets.</dd>
<t hangText="Key Identifier:">Carries a variable-length Key <dt>Key Identifier:</dt>
<dd>Carries a variable-length Key
Identifier object used to identify and deliver keys to SFC data Identifier object used to identify and deliver keys to SFC data
plane elements. This identifier is helpful to accommodate plane elements. This identifier is helpful for accommodating
deployments relying upon keying material per SFC/SFP. The key deployments relying upon keying material per SFC/SFP. The key
identifier helps in resolving the problem of synchronization of identifier helps to resolve the problem of synchronization of
keying material. A single key identifier is used to lookup both keying material. A single key identifier is used to look up both
the ENC_KEY and the MAC_KEY associated with a key, and the the ENC_KEY and the MAC_KEY associated with a key, and the
corresponding encryption and MAC algorithms used with those corresponding encryption and MAC algorithms used with those
keys.</t> keys.</dd>
<dt>Timestamp:</dt>
<t hangText="Timestamp:">Refer to <xref target="timef"></xref> for <dd>Refer to <xref target="timef" format="default"/> for
more details about the structure of this field.</t> more details about the structure of this field.</dd>
<dt>Nonce Length:</dt>
<t hangText="Nonce Length:">Carries the length of the Nonce. If <dd>Carries the length of the Nonce. If
the Context Headers are only integrity protected, "Nonce Length" the Context Headers are only integrity protected, "Nonce Length"
is set to zero (that is, no "Nonce" is included).</t> is set to zero (that is, no "Nonce" is included).</dd>
<dt>Nonce:</dt>
<t hangText="Nonce:">Carries the Nonce for the authenticated <dd>Carries the Nonce for the authenticated
encryption operation (Section 3.1 of <xref encryption operation (<xref target="RFC5116" section="3.1" sectionFo
target="RFC5116"></xref>).</t> rmat="of"/>).</dd>
<dt>Encrypted Context Headers:</dt>
<t hangText="Encrypted Context Headers:">Carries the optional <dd>Carries the optional
encrypted Context Headers.</t> encrypted Context Headers.</dd>
<dt>Message Authentication Code: </dt>
<t hangText="Message Authentication Code: ">Covers the entire NSH <dd>Covers the entire NSH
data, excluding the Base header.</t> data, excluding the Base Header.</dd>
</list></t> </dl>
</section> </section>
<section anchor="enc2" numbered="true" toc="default">
<section anchor="enc2" title="MAC#2 Context Header"> <name>MAC#2 Context Header</name>
<t>MAC#2 Context Header is a variable-length Context Header that <t>The MAC#2 Context Header is a Variable-Length Context Header that
carries the MAC for the entire NSH data calculated using MAC_KEY and carries the MAC for the entire NSH data calculated using MAC_KEY and,
optionally Context Headers encrypted using ENC_KEY. The scope of the optionally, Context Headers encrypted using ENC_KEY. The scope of the
integrity protection provided by this Context Header is depicted in integrity protection provided by this Context Header is depicted in
<xref target="scope2"></xref>.</t> <xref target="scope2" format="default"/>.</t>
<figure anchor="scope2">
<figure align="center" anchor="scope2" title="Scope of MAC#2"> <name>Scope of MAC#2</name>
<artwork align="center"><![CDATA[ 0 1 <artwork align="center" name="" type="" alt=""><![CDATA[ 0
2 3 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 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 | | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Service Path Identifier | Service Index | | | Service Path Identifier | Service Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Variable-Length Unencrypted Context Headers (opt.) ~ | ~ Variable-Length Unencrypted Context Headers (opt.) ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Metadata Class | Type |U| Length | | | Metadata Class | Type |U| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at line 801 skipping to change at line 786
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ Encrypted Context Headers (opt.) ~ | | ~ Encrypted Context Headers (opt.) ~ |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ Message Authentication Code ~ | | ~ Message Authentication Code ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | | | |
| ~ Inner Packet on which NSH is imposed ~ | | ~ Inner Packet on which NSH is imposed ~ |
| | | | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--|
| | | |
| Integrity Protection Scope ----+ | Integrity-Protection Scope ----+
+----Encrypted Data +----Encrypted Data
]]></artwork> ]]></artwork>
</figure> </figure>
<t></t> <t>In reference to <xref target="mac" format="default"/>, the descriptio
n of the
<t>In reference to <xref target="mac"></xref>, the description of the fields is as follows:</t>
fields is as follows:<list style="hanging"> <dl newline="false" spacing="normal" indent="12">
<t hangText="Metadata Class:">MUST be set to 0x0 (Section 2.5.1 of <dt>Metadata Class:</dt>
<xref target="RFC8300"></xref>).</t> <dd><bcp14>MUST</bcp14> be set to 0x0 (<xref target="RFC8300" section=
"2.2" sectionFormat="of"/>).</dd>
<t hangText="Type:">TBD2 (See <xref target="IANA"></xref>)</t> <dt>Type:</dt>
<dd>0x03 (see <xref target="IANA" format="default"/>).</dd>
<t hangText="U:">Unassigned bit (Section 2.5.1 of <xref <dt>U:</dt>
target="RFC8300"></xref>).</t> <dd>Unassigned bit (<xref target="RFC8300" section="2.5.1" sectionForm
at="of"/>).</dd>
<t hangText="Length:">Indicates the length of the variable-length <dt>Length:</dt>
metadata, in bytes. Padding considerations are discussed in <dd>Indicates the length of the variable-length
Section 2.5.1 of <xref target="RFC8300"></xref>.</t> metadata in bytes. Padding considerations are discussed in
<xref target="RFC8300" section="2.5.1" sectionFormat="of"/>.</dd>
<t hangText="Key Id Len:">See <xref target="enc1"></xref>.</t> <dt>Key Id Len:</dt>
<dd>See <xref target="enc1" format="default"/>.</dd>
<t hangText="Key Identifier:">See <xref target="enc1"></xref>.</t> <dt>Key Identifier:</dt>
<dd>See <xref target="enc1" format="default"/>.</dd>
<t hangText="Timestamp:">See <xref target="timef"></xref>.</t> <dt>Timestamp:</dt>
<dd>See <xref target="timef" format="default"/>.</dd>
<t hangText="Nonce Length:">See <xref target="enc1"></xref>.</t> <dt>Nonce Length:</dt>
<dd>See <xref target="enc1" format="default"/>.</dd>
<t hangText="Nonce:">See <xref target="enc1"></xref>.</t> <dt>Nonce:</dt>
<dd>See <xref target="enc1" format="default"/>.</dd>
<t hangText="Encrypted Context Headers:">Carries the optional <dt>Encrypted Context Headers:</dt>
encrypted Context Headers.</t> <dd>Carries the optional
encrypted Context Headers.</dd>
<t hangText="Message Authentication Code:">Covers the entire NSH <dt>Message Authentication Code:</dt>
data.</t> <dd>Covers the entire NSH
</list></t> data.</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="timef" numbered="true" toc="default">
<section anchor="timef" title="Timestamp Format"> <name>Timestamp Format</name>
<t>This section follows the template provided in Section 3 of <xref <t>This section follows the template provided in <xref target="RFC8877" se
target="RFC8877"></xref>.</t> ction="3" sectionFormat="of"/>.</t>
<t>The format of the Timestamp field introduced in <xref target="new" form
<t>The format of the Timestamp field introduced in <xref at="default"/> is depicted in <xref target="tf" format="default"/>.</t>
target="new"></xref> is depicted in <xref target="tf"></xref>.</t> <figure anchor="tf">
<name>Timestamp Field Format</name>
<t><figure anchor="tf" title="Timestamp Field Format"> <artwork align="center" name="" type="" alt=""><![CDATA[ 0
<artwork align="center"><![CDATA[ 0 1 1 2 3
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 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 | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></art work> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></art work>
</figure>Timestamp field format:<list style="empty"> </figure>
<t>Seconds: specifies the integer portion of the number of seconds
since the epoch.</t>
<t>+ Size: 32 bits.</t>
<t>+ Units: seconds.</t> <dl spacing="normal" newline="true">
<dt>Timestamp field format:</dt>
<dd>
<dl>
<dt>Seconds:</dt><dd>Specifies the integer portion of the number of seco
nds
since the epoch.</dd>
<dt>+ Size:</dt><dd> 32 bits</dd>
<dt>+ Units:</dt><dd> Seconds</dd>
<dt>Fraction:</dt><dd> Specifies the fractional portion of the number of
seconds since the epoch.</dd>
<dt>+ Size:</dt><dd> 32 bits</dd>
<dt>+ Units:</dt><dd>The unit is 2<sup>(-32)</sup> seconds, which is rou
ghly equal to
233 picoseconds.</dd>
</dl>
</dd>
</dl>
<t>Fraction: specifies the fractional portion of the number of <dl newline="true">
seconds since the epoch.</t>
<t>+ Size: 32 bits.</t> <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 <xref target="RFC5905"
section="6" sectionFormat="of"/> (which will wrap around in
2036).</dd>
<t>+ Units: the unit is 2^(-32) seconds, which is roughly equal to <dt>Leap seconds:</dt>
233 picoseconds.</t> <dd>This timestamp format is affected by leap seconds. The timestamp
</list></t> represents the number of seconds elapsed since the epoch minus the
number of leap seconds.</dd>
<t>Epoch:<list style="empty"> <dt>Resolution:</dt>
<t>The epoch is 1970-01-01T00:00 in UTC time. Note this epoch value
is different from the one used in Section 6 of <xref
target="RFC5905"></xref> (which will wrap around in 2036).</t>
</list></t>
<t>Leap seconds:<list style="empty"> <dd>The resolution is 2<sup>(-32)</sup> seconds.</dd>
<t>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"> <dt>Wraparound:</dt>
<t>The resolution is 2^(-32) seconds.</t>
</list></t>
<t>Wraparound:<list style="empty"> <dd>This time format wraps around every 2<sup>32</sup> seconds, which is
<t>This time format wraps around every 2^32 seconds, which is
roughly 136 years. The next wraparound will occur in the year roughly 136 years. The next wraparound will occur in the year
2106.</t> 2106.</dd>
</list>Synchronization aspects:<list style="empty">
<t>It is assumed that SFC data plane elements are synchronized to <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 UTC using a synchronization mechanism that is outside the scope of
this document. In typical deployments, SFC data plane elements use this document. In typical deployments, SFC data plane elements use
NTP <xref target="RFC5905"></xref> for synchronization. Thus, the NTP <xref target="RFC5905" format="default"/> for synchronization. Thu s, the
timestamp may be derived from the NTP-synchronized clock, allowing timestamp may be derived from the NTP-synchronized clock, allowing
the timestamp to be measured with respect to the clock of an NTP 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 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 affected by leap seconds (in a manner analogous to the NTP time
format, which is similar). Therefore, the value of a timestamp format, which is similar). Therefore, the value of a timestamp
during or slightly after a leap second may be temporarily during or slightly after a leap second may be temporarily
inaccurate.</t> inaccurate.</dd>
</list></t> </dl>
</section> </section>
<section anchor="prorules" numbered="true" toc="default">
<section anchor="prorules" title="Processing Rules"> <name>Processing Rules</name>
<t>The following subsections describe the processing rules for integrity <t>The following subsections describe the processing rules for
protected NSH and optionally encrypted Context Headers.</t> integrity-protected NSH and, optionally, encrypted Context Headers.</t>
<section anchor="gen" numbered="true" toc="default">
<section anchor="gen" title="Generic Behavior"> <name>Generic Behavior</name>
<t>This document adheres to the recommendations in Section 8.1 of <t>This document adheres to the recommendations in <xref target="RFC8300
<xref target="RFC8300"></xref> for handling the Context Headers at " section="8.1" sectionFormat="of"/> for handling the Context Headers at
both ingress and egress SFC boundary nodes (i.e., to strip the entire both ingress and egress SFC boundary nodes (i.e., to strip the entire
NSH, including Context Headers).</t> NSH, including Context Headers).</t>
<t>Failures of a Classifier to inject the Context Headers defined in
<t>Failures of a classifier to inject the Context Headers defined in this document <bcp14>SHOULD</bcp14> be logged locally while a notificati
this document SHOULD be logged locally while a notification alarm MAY on alarm <bcp14>MAY</bcp14>
be sent to an SFC control element. Failures of an NSH-aware node to be sent to an SFC control element. Failures of an NSH-aware node to
validate the integrity of the NSH data MUST cause that packet to be validate the integrity of the NSH data <bcp14>MUST</bcp14> cause that pa
discarded while a notification alarm MAY be sent to an SFC control cket to be
discarded while a notification alarm <bcp14>MAY</bcp14> be sent to an SF
C control
element. The details of sending notification alarms (i.e., the element. The details of sending notification alarms (i.e., the
parameters that affect the transmission of the notification alarms parameters that affect the transmission of the notification alarms
depending on the information in the context header such as frequency, depending on the information in the Context Header such as frequency,
thresholds, and content in the alarm) SHOULD be configurable.</t> thresholds, and content in the alarm) <bcp14>SHOULD</bcp14> be configura
ble.</t>
<t>NSH-aware SFs and SFC proxies MAY be instructed to strip some <t>NSH-aware SFs and SFC proxies <bcp14>MAY</bcp14> be instructed to
encrypted Context Headers from the packet or to pass the data to the strip some encrypted Context Headers from the packet or to pass the
next SF in the service function chain after processing the content of data to the next SF in the service function chain after processing the
the Context Headers. If no instruction is provided, the default content of the Context Headers. If no instruction is provided, the
behavior for intermediary NSH-aware nodes is to maintain such Context default behavior for intermediary NSH-aware nodes is to maintain such
Headers so that the information can be passed to next NSH-aware hops. Context Headers so that the information can be passed to the next
NSH-aware SFs and SFC proxies MUST re-apply the integrity protection NSH-aware hops. NSH-aware SFs and SFC proxies <bcp14>MUST</bcp14>
if any modification is made to the Context Headers (e.g., strip a reapply the integrity protection if any modification is made to the
Context Header, update the content of an existing Context Header, Context Headers (e.g., strip a Context Header, update the content of
insert a new Context Header).</t> 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 <t>An NSH-aware SF or SFC Proxy that is not allowed to decrypt any
Context Headers MUST NOT be given access to the ENC_KEY.</t> Context Headers <bcp14>MUST NOT</bcp14> be given access to the ENC_KEY.<
/t>
<t>Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted <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 Headers, for which it is not allowed to consume a specific
Context Header it decrypts (but consumes others), MUST keep that Context Header it decrypts (but consumes others), <bcp14>MUST</bcp14> ke ep that
Context Header unaltered when forwarding the packet upstream.</t> Context Header unaltered when forwarding the packet upstream.</t>
<t>Only one instance of a "MAC and Encrypted Metadata" Context Header
<t>Only one instance of "MAC and Encrypted Metadata" Context Header (<xref target="new" format="default"/>) is allowed in an NSH level. If m
(<xref target="new"></xref>) is allowed in an NSH level. If multiple ultiple
instances of "MAC and Encrypted Metadata" Context Header are included instances of a "MAC and Encrypted Metadata" Context Header are included
in an NSH level, the SFC data plane element MUST process the first in an NSH level, the SFC data plane element <bcp14>MUST</bcp14> process
instance and ignore subsequent instances, and MAY log or increase a the first
counter for this event as per Section 2.5.1 of <xref instance and ignore subsequent instances and <bcp14>MAY</bcp14> log or i
target="RFC8300"></xref>. If NSH-in-NSH is used (<xref ncrease a
target="nsh-in-nsh"></xref>), distinct LoAs may be used for each NSH counter for this event as per <xref target="RFC8300" section="2.5.1" sec
tionFormat="of"/>. If NSH within NSH is used (<xref target="nsh-in-nsh" format="
default"/>), distinct LoAs may be used for each NSH
level.</t> level.</t>
<t>MTU and fragmentation considerations are discussed in <xref target="M
<t>MTU and fragmentation considerations are discussed in <xref TU" format="default"/>.</t>
target="MTU"></xref>.</t>
</section> </section>
<section title="MAC NSH Data Generation"> <section numbered="true" toc="default">
<t>After performing any Context Header encryption, the HMAC algorithm
discussed in <xref target="RFC4868"></xref> 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>
<name>MAC NSH Data Generation</name>
<t>After performing any Context Header encryption, the HMAC algorithm
discussed in <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" format="default"/>).</t>
<t>The NSH imposer sets the MAC field to zero and then computes the <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 message integrity for the target NSH data (depending on the
protection scope discussed in <xref target="new"></xref>) using integrity-protection scope discussed in <xref target="new"
MAC_KEY and HMAC algorithm. It inserts the computed digest in the MAC format="default"/>) using the MAC_KEY and HMAC algorithm. It inserts
field of the "MAC and Encrypted Metadata" Context Header. The length the computed digest in the MAC field of the "MAC and Encrypted
of the MAC is decided by the HMAC algorithm adopted for the particular Metadata" Context Header. The length of the MAC is decided by the HMAC
key identifier.</t> algorithm adopted for the particular key identifier.</t>
<t>The Message Authentication Code (T) computation process for the <t>The Message Authentication Code (T) computation process for the
target NSH data with HMAC-SHA-256-128() can be illustrated as target NSH data with HMAC-SHA-256-128() can be illustrated as
follows:</t> follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ T = HMAC-SHA
<figure> -256-128(MAC_KEY, target NSH data)
<artwork><![CDATA[ T = HMAC-SHA-256-128(MAC_KEY, target NSH data)
]]></artwork> ]]></artwork>
</figure>
<t></t> <t>An entity in the SFP that updates the NSH <bcp14>MUST</bcp14> follow
the above
<t>An entity in the SFP that updates the NSH MUST follow the above
behavior to maintain message integrity of the NSH for subsequent behavior to maintain message integrity of the NSH for subsequent
validations.</t> validations.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Encrypted NSH Metadata Generation"> <name>Encrypted NSH Metadata Generation</name>
<t>An NSH imposer can encrypt Context Headers carrying sensitive <t>An NSH imposer can encrypt Context Headers carrying sensitive
metadata, i.e., encrypted and unencrypted metadata may be carried metadata, i.e., encrypted and unencrypted metadata may be carried
simultaneously in the same NSH packet (Sections <xref format="counter" simultaneously in the same NSH packet (Sections <xref format="counter" t
target="scope1"></xref> and <xref format="counter" arget="scope1"/> and <xref format="counter" target="scope2"/>).</t>
target="scope2"></xref>).</t> <t>In order to prevent pervasive monitoring <xref target="RFC7258" forma
t="default"/>, it is <bcp14>RECOMMENDED</bcp14> to encrypt all Context
<t>In order to prevent pervasive monitoring <xref Headers. All Context Headers carrying privacy-sensitive metadata <bcp14>
target="RFC7258"></xref>, it is RECOMMENDED to encrypt all Context MUST</bcp14>
Headers. All Context Headers carrying privacy-sensitive metadata MUST
be encrypted; by doing so, privacy-sensitive metadata is not revealed be encrypted; by doing so, privacy-sensitive metadata is not revealed
to attackers. Privacy specific threats are discussed in Section 5.2 of to attackers. Privacy-specific threats are discussed in
<xref target="RFC6973"></xref>.</t> <xref target="RFC6973" section="5.2" sectionFormat="of"/>.</t>
<t>Using the secret key (ENC_KEY) and authenticated encryption <t>Using the secret key (ENC_KEY) and authenticated encryption
algorithm, the NSH imposer encrypts the Context Headers (as set, for algorithm, the NSH imposer encrypts the Context Headers (as set, for
example, in <xref target="req"></xref>) and inserts the resulting example, in <xref target="req" format="default"/>) and inserts the
payload in the "MAC and Encrypted Metadata" Context Header (<xref resulting payload in the "MAC and Encrypted Metadata" Context Header
target="new"></xref>). The additional authenticated data input to the (<xref target="new" format="default"/>). The additional authenticated
AEAD function is a zero-length byte string. The entire Context Header data input to the AEAD function is a zero-length byte string. The
carrying a sensitive metadata is encrypted (that is, including the MD entire Context Header carrying sensitive metadata is encrypted (that
Class, Type, Length, and associated metadata of each Context is, including the MD Class, Type, Length, and associated metadata of
Header).</t> each Context Header).</t>
<t>More details about the exact encryption procedure are provided in <t>More details about the exact encryption procedure are provided in
Section 2.1 of <xref target="RFC5116"></xref>. In this case, the <xref target="RFC5116" section="2.1" sectionFormat="of"/>. In this
associated data (A) input is zero-length for AES-GCM.</t> case, the associated data (A) input is zero length for AES
Galois/Counter Mode (AES-GCM).</t>
<t>An authorized entity in the SFP that updates the content of an <t>An authorized entity in the SFP that updates the content of an
encrypted Context Header or needs to add a new encrypted Context encrypted Context Header or needs to add a new encrypted Context
Header MUST also follow the aforementioned behavior.</t> Header <bcp14>MUST</bcp14> also follow the aforementioned behavior.</t>
</section> </section>
<section anchor="time" numbered="true" toc="default">
<section anchor="time" title="Timestamp for Replay Attack Prevention"> <name>Timestamp for Replay Attack Prevention</name>
<t>The Timestamp imposed by an initial Classifier is left untouched <t>The Timestamp imposed by an initial Classifier is left untouched
along an SFP. However, it can be updated when reclassification occurs along an SFP. However, it can be updated when reclassification occurs
(Section 4.8 of <xref target="RFC7665"></xref>). The same (<xref target="RFC7665" section="4.8" sectionFormat="of"/>). The same
considerations for setting the Timestamp are followed in both initial considerations for setting the Timestamp are followed in both initial
classification and reclassification (<xref classification and reclassification (<xref target="timef" format="defaul
target="timef"></xref>).</t> t"/>).</t>
<t>The received NSH is accepted by an NSH-aware node if the Timestamp <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 (TS) in the NSH is recent enough to the reception time of the NSH
(TSrt). The following formula is used for this check:</t> (TSrt). The following formula is used for this check:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ -Delta < (TS
<t><figure> rt - TS) < +Delta
<artwork><![CDATA[ -Delta < (TSrt - TS) < +Delta
]]></artwork> ]]></artwork>
</figure></t>
<t>The Delta interval is a configurable parameter. The default value <t>The Delta interval is a configurable parameter. The default value
for the allowed Delta is 2 seconds. Special care should be taken when 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 setting very low Delta values as this may lead to dropping legitimate
traffic. If the timestamp is not within the boundaries, then the SFC traffic. If the timestamp is not within the boundaries, then the SFC
data plane element receiving such packet MUST discard the NSH data plane element receiving such packets <bcp14>MUST</bcp14> discard th e NSH
message.</t> message.</t>
<t>Replay attacks within the Delta window may be detected by an <t>Replay attacks within the Delta window may be detected by an
NSH-aware node by recording a unique value derived from the packet, NSH-aware node by recording a unique value derived from the packet,
for example, a unique value from the MAC field value. Such an such as a unique value from the MAC field value. Such an NSH-aware
NSH-aware node will detect and reject duplicates. If for legitimate node will detect and reject duplicates. If for legitimate service
service reasons, some flows have to be duplicated but still share reasons some flows have to be duplicated but still share a portion of
portion of an SFP with the original flow, legitimate duplicate packets an SFP with the original flow, legitimate duplicate packets will be
will be tagged by NSH-aware nodes involved in that segment as replay tagged by NSH-aware nodes involved in that segment as replay packets
packets unless sufficient entropy is added to the duplicate packet. unless sufficient entropy is added to the duplicate packet. How such
How such an entropy is added is implementation-specific.</t> an entropy is added is implementation specific.</t>
<t><list style="empty"> <t indent="3">
<t>Note: Within the timestamp delta window, defining a sequence Note: Within the timestamp Delta window, defining a sequence number to protect
number to protect against replay attacks may be considered. In against replay attacks may be considered. In such a mode, NSH-aware nodes must
such mode, NSH-aware nodes must discard packets with duplicate discard packets with duplicate sequence numbers within the timestamp Delta
sequence numbers within the timestamp delta window. However, in window. However, in deployments with several instances of the same SF (e.g.,
deployments with several instances of the same SF (e.g., cluster cluster or load-balanced SFs), a mechanism to coordinate among those instances
or load-balanced SFs), a mechanism to coordinate among those to discard duplicate sequence numbers is required. Because the coordination
instances to discard duplicate sequence numbers is required. mechanism to comply with this requirement is service specific, this document
Because the coordination mechanism to comply with this requirement does not include this protection.
is service-specific, this document does not include this
protection.</t> </t>
</list></t>
<t>All SFC data plane elements must be synchronized among themselves. <t>All SFC data plane elements must be synchronized among themselves.
These elements may be synchronized to a global reference time.</t> These elements may be synchronized to a global reference time.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="NSH Data Validation"> <name>NSH Data Validation</name>
<t>When an SFC data plane element that conforms to this specification <t>When an SFC data plane element that conforms to this specification
needs to check the validity of the NSH data, it MUST ensure that a needs to check the validity of the NSH data, it <bcp14>MUST</bcp14> ensu re that a
"MAC and Encrypted Metadata" Context Header is included in a received "MAC and Encrypted Metadata" Context Header is included in a received
NSH packet. The imposer MUST silently discard the packet and MUST log NSH packet. The imposer <bcp14>MUST</bcp14> silently discard the packet and <bcp14>MUST</bcp14> log
an error at least once per the SPI if at least one of the following is an error at least once per the SPI if at least one of the following is
observed:<list style="symbols"> observed:</t>
<t>the "MAC and Encrypted Metadata" Context Header is missing,</t> <ul spacing="normal">
<li>the "MAC and Encrypted Metadata" Context Header is missing,</li>
<t>the enclosed key identifier is unknown or invalid (e.g., the <li>the enclosed key identifier is unknown or invalid (e.g., the
corresponding key expired),</t> corresponding key expired), or</li>
<li>the timestamp is invalid (<xref target="time" format="default"/>).
<t>the timestamp is invalid (<xref target="time"></xref>).</t> </li>
</list></t> </ul>
<t>If the timestamp check is successfully passed, the SFC data plane <t>If the timestamp check is successfully passed, the SFC data plane
element proceeds with NSH data integrity validation. After storing the element proceeds with NSH data integrity validation. After storing the
value of the MAC field in the "MAC and Encrypted Metadata" Context value of the MAC field in the "MAC and Encrypted Metadata" Context
Header, the SFC data plane element fills the MAC field with zeros. Header, the SFC data plane element fills the MAC field with zeros.
Then, the SFC data plane element generates the message integrity for Then, the SFC data plane element generates the message integrity for
the target NSH data (depending on the integrity protection scope the target NSH data (depending on the integrity-protection scope
discussed in <xref target="new"></xref>) using MAC_KEY and HMAC discussed in <xref target="new" format="default"/>) using the MAC_KEY an
algorithm. If the value of the newly generated digest is identical to d
the stored one, the SFC data plane element is certain that the NSH HMAC algorithm. If the value of the newly generated digest is
data has not been tampered and validation is therefore successful. identical to the stored one, the SFC data plane element is certain
Otherwise, the NSH packet MUST be discarded. The comparison of the that the NSH data has not been tampered with and validation is
computed HMAC value to the stored value MUST be done in a therefore successful. Otherwise, the NSH packet <bcp14>MUST</bcp14>
constant-time manner to thwart timing attacks.</t> be discarded. The comparison of the computed HMAC value to the stored
value <bcp14>MUST</bcp14> be done in a constant-time manner to thwart
timing attacks.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Decryption of NSH Metadata"> <name>Decryption of NSH Metadata</name>
<t>If entitled to consume a supplied encrypted Context Header, an <t>If entitled to consume a supplied encrypted Context Header, an
NSH-aware SF or SFC Proxy decrypts metadata using (K) and decryption NSH-aware SF or SFC Proxy decrypts metadata using (K) and a decryption
algorithm for the key identifier in the NSH.</t> algorithm for the key identifier in the NSH.</t>
<t>The authenticated encryption algorithm has only a single output, eith
<t>Authenticated encryption algorithm has only a single output, either er
a plaintext or a special symbol (FAIL) that indicates that the inputs a plaintext or a special symbol (FAIL) that indicates that the inputs
are not authentic (Section 2.2 of [RFC5116]).</t> are not authentic (<xref target="RFC5116" section="2.2" sectionFormat="o f"/>).</t>
</section> </section>
</section> </section>
<section anchor="MTU" numbered="true" toc="default">
<section anchor="MTU" title="MTU Considerations"> <name>MTU Considerations</name>
<t>The SFC architecture prescribes that additional information be added <t>The SFC architecture prescribes that additional information be added
to packets to: <list style="symbols"> to packets to: </t>
<t>Identify SFPs: this is typically the NSH Base Header and Service
Path Header.</t>
<t>Carry metadata such as those defined in <xref format="default"
target="new"></xref>.</t>
<t>Steer the traffic along the SFPs: transport encapsulation.</t>
</list></t>
<ul spacing="normal">
<li>Identify SFPs: this is typically the NSH Base Header and Service
Path Header.</li>
<li>Carry metadata such as that defined in <xref format="default" target
="new"/>.</li>
<li>Steer the traffic along the SFPs: This is realized by means of
transport encapsulation.</li>
</ul>
<t>This added information increases the size of the packet to be carried <t>This added information increases the size of the packet to be carried
along an SFP.</t> along an SFP.</t>
<t>Aligned with <xref target="RFC8300" section="5" sectionFormat="of"/>, i
<t>Aligned with Section 5 of <xref target="RFC8300"></xref>, it is t is
RECOMMENDED for network operators to increase the underlying MTU so that <bcp14>RECOMMENDED</bcp14> that network operators increase the underlying
MTU so that
NSH traffic is forwarded within an SFC-enabled domain without NSH traffic is forwarded within an SFC-enabled domain without
fragmentation. The available underlying MTU should be taken into account fragmentation. The available underlying MTU should be taken into account
by network operators when providing SFs with the required Context 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 Headers to be injected per SFP and the size of the data to be carried in
these Context Headers.</t> these Context Headers.</t>
<t>If the underlying MTU cannot be increased to accommodate the NSH <t>If the underlying MTU cannot be increased to accommodate the NSH
overhead, network operators may rely upon a transport encapsulation overhead, network operators may rely upon a transport encapsulation
protocol with the required fragmentation handling. The impact of protocol with the required fragmentation handling. The impact of
activating such feature on SFFs should be carefully assessed by network activating such features on SFFs should be carefully assessed by network
operators (Section 5.6 of <xref target="RFC7665"></xref>).</t> operators (<xref target="RFC7665" section="5.6" sectionFormat="of"/>).</t>
<t>When dealing with MTU issues, network operators should consider the <t>When dealing with MTU issues, network operators should consider the
limitations of various tunnel mechanisms such as those discussed in limitations of various tunnel mechanisms such as those discussed in
<xref target="I-D.ietf-intarea-tunnels"></xref>.</t> <xref target="I-D.ietf-intarea-tunnels" format="default"/>.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Data plane SFC-related security considerations, including privacy, <t>Data plane SFC-related security considerations, including privacy,
are discussed in Section 6 of <xref target="RFC7665"></xref> and Section are discussed in <xref target="RFC7665" section="6" sectionFormat="of"/>
8 of <xref target="RFC8300"></xref>. In particular, Section 8.2.2 of and <xref target="RFC8300" section="8" sectionFormat="of"/>. In
<xref target="RFC8300"></xref> states that attached metadata (i.e., particular, <xref target="RFC8300" section="8.2.2" sectionFormat="of"/>
Context Headers) should be limited to that necessary for correct states that attached metadata (i.e., Context Headers) should be limited
operation of the SFP. Also, that section indicates that <xref to that which is necessary for correct operation of the SFP. Also, that se
target="RFC8165"></xref> discusses metadata considerations that ction
operators can take into account when using NSH.</t> indicates that <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 <t>The guidelines for cryptographic key management are discussed in
<xref target="RFC4107"></xref>. The group key management protocol <xref target="RFC4107" format="default"/>. The group key management
related security considerations discussed in Section 8 of <xref protocol-related security considerations discussed in <xref
target="RFC4046"></xref> needs to be taken into consideration.</t> 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 <t>The interaction between the SFC data plane elements and a key
management system MUST NOT be transmitted in clear since this would management system <bcp14>MUST NOT</bcp14> be transmitted unencrypted since
completely destroy the security benefits of the integrity protection this would completely destroy the security benefits of the
solution defined in this document.</t> integrity-protection solution defined in this document.</t>
<t>The secret key (K) must have an expiration time assigned as the <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 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 protection of NSH data and encryption of Context Headers. Prior to the
expiration of the secret key, all participating NSH-aware nodes SHOULD expiration of the secret key, all participating NSH-aware nodes <bcp14>SHO ULD</bcp14>
have the control plane distribute a new key identifier and associated have the control plane distribute a new key identifier and associated
keying material so that when the secret key is expired, those nodes are 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 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 to the new key identifier as soon as necessary. It is <bcp14>RECOMMENDED</ bcp14> that
the next key identifier and associated keying material be distributed by the next key identifier and associated keying material be distributed by
the control plane well prior to the secret key expiration time. the control plane well prior to the secret key expiration time.
Additional guidance for users of AEAD functions about rekeying can be Additional guidance for users of AEAD functions about rekeying can be
found in <xref target="I-D.irtf-cfrg-aead-limits"></xref>.</t> found in <xref target="I-D.irtf-cfrg-aead-limits" format="default"/>.</t>
<t>The security and integrity of the key-distribution mechanism is vital <t>The security and integrity of the key-distribution mechanism is vital
to the security of the SFC system as a whole.</t> to the security of the SFC system as a whole.</t>
<t>NSH data is exposed to several threats:</t>
<t>NSH data are exposed to several threats:</t> <ul spacing="normal">
<li>An on-path attacker modifying the NSH data.</li>
<t><list style="symbols"> <li>An attacker spoofing the NSH data.</li>
<t>A on-path attacker modifying the NSH data.</t> <li>An attacker capturing and replaying the NSH data.</li>
<li>Data carried in Context Headers revealing privacy-sensitive
<t>Attacker spoofing the NSH data.</t> information to attackers.</li>
<li>An attacker replacing the packet on which the NSH is imposed with a
<t>Attacker capturing and replaying the NSH data.</t> modified or bogus packet.</li>
</ul>
<t>Data carried in Context Headers revealing privacy-sensitive
information to attackers.</t>
<t>Attacker replacing the packet on which the NSH is imposed with a
modified or bogus packet.</t>
</list></t>
<t>In an SFC-enabled domain where the above attacks are possible, (1) <t>In an SFC-enabled domain where the above attacks are possible, (1)
NSH data MUST be integrity-protected and replay-protected, and (2) NSH data <bcp14>MUST</bcp14> be integrity protected and
privacy-sensitive NSH metadata MUST be encrypted for confidentiality replay protected, and (2) privacy-sensitive NSH metadata
preservation purposes. The Base and Service Path headers are not <bcp14>MUST</bcp14> be encrypted for confidentiality preservation
encrypted.</t> purposes. The Base and Service Path Headers are not encrypted.</t>
<t>MACs with two levels of assurance are defined in <xref target="new"
<t>MACs with two levels of assurance are defined in <xref format="default"/>. Considerations specific to each level of assurance
target="new"></xref>. Considerations specific to each level of assurance are discussed in Sections <xref format="counter" target="mac1"/> and
are discussed in Sections <xref format="counter" target="mac1"></xref> <xref format="counter" target="mac2"/>.</t>
and <xref format="counter" target="mac2"></xref>.</t>
<t>The attacks discussed in <xref <t>The attacks discussed in <xref
target="I-D.nguyen-sfc-security-architecture"></xref> are handled owing target="I-D.nguyen-sfc-security-architecture" format="default"/> are
to the solution specified in this document, except for attacks dropping handled based on the solution specified in this document, with the
packets. Such attacks can be detected relying upon statistical analysis; exception of attacks dropping packets. Such attacks can be detected
such analysis is out of the scope of this document. Also, if SFFs are by relying upon statistical analysis; such analysis is out of the scope of
not involved in the integrity checks, a misbehaving SFF which decrements this document. Also, if SFFs are not involved in the integrity checks, a
SI while this should be done by an SF (SF bypass attack) will be misbehaving SFF that decrements SI while this should be done by an SF
detected by an upstream SF because the integrity check will fail.</t> (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 <t>Some events are logged locally with notification alerts sent by
NSH-aware nodes to a Control Element. These events SHOULD be NSH-aware nodes to a Control Element. These events <bcp14>SHOULD</bcp14> b
rate-limited.</t> e
rate limited.</t>
<t>The solution specified in this document does not provide data origin <t>The solution specified in this document does not provide data origin
authentication.</t> authentication.</t>
<t>In order to detect compromised nodes, it is assumed that appropriate <t>In order to detect compromised nodes, it is assumed that appropriate
mechanisms to monitor and audit an SFC-enabled domain to detect mechanisms to monitor and audit an SFC-enabled domain to detect
misbehavior and to deter misuse are in place. Compromised nodes can thus misbehavior and to deter misuse are in place. Compromised nodes can thus
be withdrawn from active service function chains using appropriate be withdrawn from active service function chains using appropriate
control plane mechanisms.</t> control plane mechanisms.</t>
<section anchor="mac1" numbered="true" toc="default">
<section anchor="mac1" title="MAC#1"> <name>MAC#1</name>
<t>An active attacker can potentially modify the Base header (e.g., <t>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). 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 An active attacker can typically also drop NSH packets. As such, this
attack is not considered an attack against the security mechanism attack is not considered an attack against the security mechanism
specified in the document.</t> specified in the document.</t>
<t>It is expected that specific devices in the SFC-enabled domain will <t>It is expected that specific devices in the SFC-enabled domain will
be configured such that no device other than the classifiers (when be configured such that no device other than the Classifiers (when
reclassification is enabled), NSH-aware SFs, and SFC proxies will be reclassification is enabled), NSH-aware SFs, and SFC proxies will be
able to update the integrity protected NSH data (<xref able to update the integrity-protected NSH data (<xref target="gen"
target="gen"></xref>), and also such that no device other than the format="default"/>), and no device other than the
NSH-aware SFs and SFC proxies will be able to decrypt and update the NSH-aware SFs and SFC proxies will be able to decrypt and update the
Context Headers carrying sensitive metadata (<xref Context Headers carrying sensitive metadata (<xref target="gen"
target="gen"></xref>). In other words, if the NSH-aware SFs and SFC format="default"/>). In other words, it is expected that the NSH-aware
proxies in the SFC-enabled domain are considered fully trusted to act SFs and SFC proxies in the SFC-enabled domain are considered fully
on the NSH data. Only these elements can have access to sensitive NSH trusted to act on the NSH data. Only these elements can have access to
metadata and the keying material used to integrity protect NSH data sensitive NSH metadata and the keying material used to integrity
and encrypt Context Headers.</t> protect NSH data and encrypt Context Headers.</t>
</section> </section>
<section anchor="mac2" numbered="true" toc="default">
<section anchor="mac2" title="MAC#2"> <name>MAC#2</name>
<t>SFFs can detect whether an illegitimate node has altered the <t>SFFs can detect whether an illegitimate node has altered the
content of the Base header. Such messages must be discarded with content of the Base Header. Such messages must be discarded with
appropriate logs and alarms generated (see <xref appropriate logs and alarms generated (see <xref target="gen" format="de
target="gen"></xref>).</t> fault"/>).</t>
<t>Similar to <xref target="mac1" format="default"/>, no device other th
<t>Similar to <xref target="mac1"></xref>, no device other than the an the
NSH-aware SFs and SFC proxies in the SFC-enabled domain should be able NSH-aware SFs and SFC proxies in the SFC-enabled domain should be able
to decrypt and update the Context Headers carrying sensitive to decrypt and update the Context Headers carrying sensitive
metadata.</t> metadata.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Time Synchronization"> <name>Time Synchronization</name>
<t><xref target="RFC8633"></xref> describes best current practices to <t><xref target="RFC8633" format="default"/> describes best current prac
tices to
be considered in deployments where SFC data plane elements use NTP for be considered in deployments where SFC data plane elements use NTP for
time synchronization purposes.</t> time-synchronization purposes.</t>
<t>Also, a mechanism to provide cryptographic security for NTP is <t>Also, a mechanism to provide cryptographic security for NTP is
specified in <xref target="RFC8915"></xref>.</t> specified in <xref target="RFC8915" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<t>This document requests IANA to assign the following types from the <name>IANA Considerations</name>
"NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 IETF <t>IANA has added the following types to the "NSH IETF-Assigned Optional
Base NSH MD Class) registry available at: Variable-Length Metadata Types" registry (0x0000 IETF Base NSH MD Class)
https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-me at <eref brackets="angle"
tadata-types.</t> target="https://www.iana.org/assignments/nsh"/>.
</t>
<t><figure> <table>
<artwork align="center"><![CDATA[+-------+---------------------------- <name>Additions to the NSH IETF-Assigned Optional Variable-Length Metadat
---+----------------+ a Types Registry</name>
| Value | Description | Reference | <thead>
+=======+===============================+================+ <tr>
| TBD1 | MAC and Encrypted Metadata #1 | [ThisDocument] | <th>Value</th>
| TBD2 | MAC and Encrypted Metadata #2 | [ThisDocument] | <th>Description</th>
+-------+-------------------------------+----------------+]]></artwork> <th>Reference</th>
</figure></t> </tr>
</section> </thead>
<tbody>
<section title="Acknowledgements"> <tr>
<t>This document was edited as a follow-up to the discussion in <td>0x02</td>
IETF#104: <td>MAC and Encrypted Metadata #1</td>
https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chai <td>RFC 9145</td>
r-slides-01 </tr>
(slide 7).</t> <tr>
<td>0x03</td>
<t>Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal <td>MAC and Encrypted Metadata #2</td>
Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody for <td>RFC 9145</td>
the comments.</t> </tr>
</tbody>
<t>Many thanks to Steve Hanna for the valuable secdir review and </table>
J&uuml;rgen Sch&ouml;nw&auml;lder for the opsdir review.</t>
<t>Thanks to Greg Mirsky for the 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 for the IESG review.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <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'?> <displayreference target="I-D.ietf-intarea-tunnels" to="INTERNET-IP-TUNNELS"
/>
<?rfc include='reference.RFC.4868'?> <displayreference target="I-D.arkko-farrell-arch-model-t" to="INTERNET-THREA
T-MODEL"/>
<?rfc include='reference.RFC.5116'?> <displayreference target="I-D.nguyen-sfc-security-architecture" to="ARCH-SFC
-THREATS"/>
<?rfc include='reference.RFC.4107'?> <displayreference target="I-D.irtf-cfrg-aead-limits" to="AEAD-LIMITS"/>
<?rfc include='reference.RFC.2104'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8300.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7665.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4868.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5116.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4107.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2104.xml"/>
<reference anchor="GCM"> <reference anchor="GCM">
<front> <front>
<title>Recommendation for Block Cipher Modes of Operation: <title>Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC</title> 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>
<author initials="M." surname="Dworkin"> </references>
<organization></organization> <references>
</author> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month="November" year="2007" /> FC.8459.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8877.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7498.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7258.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8165.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-in
tarea-tunnels.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-arkko-f
arrell-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-cf
rg-aead-limits.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7635.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8915.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8633.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4046.xml"/>
<seriesInfo name="NIST" value="Special Publication 800-38D" /> </references>
</reference>
</references> </references>
<references title="Informative References"> <section numbered="false" toc="default">
<?rfc include="reference.RFC.8459"?> <name>Acknowledgements</name>
<t>This document was created as a follow-up to the discussion in
<?rfc include='reference.RFC.8877'?> IETF 104:
<eref brackets="angle" target="https://datatracker.ietf.org/meeting/104/ma
<?rfc include='reference.RFC.7498'?> terials/slides-104-sfc-sfc-chair-slides-01"/>
(slide 7).</t>
<?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'?> <t>Thanks to <contact fullname="Joel Halpern"/>, <contact
fullname="Christian Jacquenet"/>, <contact fullname="Dirk von 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 <contact fullname="Steve Hanna"/> for the valuable secdi
r review and
<contact fullname="Juergen Schoenwaelder"/> for the opsdir review.</t>
<t>Thanks to <contact fullname="Greg Mirsky"/> for the <contact
fullname="Shepherd review"/>.</t>
<t>Thanks to <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>
<!---->
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 234 change blocks. 
901 lines changed or deleted 941 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/