rfc9145.original   rfc9145.txt 
SFC M. Boucadair Internet Engineering Task Force (IETF) M. Boucadair
Internet-Draft Orange Request for Comments: 9145 Orange
Intended status: Standards Track T. Reddy Category: Standards Track T. Reddy.K
Expires: March 24, 2022 Akamai ISSN: 2070-1721 Akamai
D. Wing D. Wing
Citrix Citrix
September 20, 2021 December 2021
Integrity Protection for the Network Service Header (NSH) and Encryption Integrity Protection for the Network Service Header (NSH) and Encryption
of Sensitive Context Headers of Sensitive Context Headers
draft-ietf-sfc-nsh-integrity-09
Abstract Abstract
This specification presents an optional method to add integrity This specification presents an optional method to add integrity
protection directly to the Network Service Header (NSH) used for protection directly to the Network Service Header (NSH) used for
Service Function Chaining (SFC). Also, this specification allows for Service Function Chaining (SFC). Also, this specification allows for
the encryption of sensitive metadata that is carried in the NSH. the encryption of sensitive metadata (MD) that is carried in the NSH.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on March 24, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9145.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Assumptions and Basic Requirements . . . . . . . . . . . . . 5 3. Assumptions and Basic Requirements
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 7 4. Design Overview
4.1. Supported Security Services . . . . . . . . . . . . . . . 7 4.1. Supported Security Services
4.1.1. Encrypt All or a Subset of Context Headers . . . . . 7 4.1.1. Encrypt All or a Subset of Context Headers
4.1.2. Integrity Protection . . . . . . . . . . . . . . . . 8 4.1.2. Integrity Protection
4.2. One Secret Key, Two Security Services . . . . . . . . . . 10 4.2. One Secret Key, Two Security Services
4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 11 Algorithms
4.4. Key Management . . . . . . . . . . . . . . . . . . . . . 11 4.4. Key Management
4.5. New NSH Variable-Length Context Headers . . . . . . . . . 12 4.5. New NSH Variable-Length Context Headers
4.6. Encapsulation of NSH within NSH . . . . . . . . . . . . . 12 4.6. Encapsulation of NSH within NSH
5. New NSH Variable-Length Context Headers . . . . . . . . . . . 13 5. New NSH Variable-Length Context Headers
5.1. MAC#1 Context Header . . . . . . . . . . . . . . . . . . 14 5.1. MAC#1 Context Header
5.2. MAC#2 Context Header . . . . . . . . . . . . . . . . . . 16 5.2. MAC#2 Context Header
6. Timestamp Format . . . . . . . . . . . . . . . . . . . . . . 18 6. Timestamp Format
7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 19 7. Processing Rules
7.1. Generic Behavior . . . . . . . . . . . . . . . . . . . . 19 7.1. Generic Behavior
7.2. MAC NSH Data Generation . . . . . . . . . . . . . . . . . 20 7.2. MAC NSH Data Generation
7.3. Encrypted NSH Metadata Generation . . . . . . . . . . . . 21 7.3. Encrypted NSH Metadata Generation
7.4. Timestamp for Replay Attack Prevention . . . . . . . . . 21 7.4. Timestamp for Replay Attack Prevention
7.5. NSH Data Validation . . . . . . . . . . . . . . . . . . . 22 7.5. NSH Data Validation
7.6. Decryption of NSH Metadata . . . . . . . . . . . . . . . 23 7.6. Decryption of NSH Metadata
8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. MTU Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations
9.1. MAC#1 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. MAC#1
9.2. MAC#2 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.2. MAC#2
9.3. Time Synchronization . . . . . . . . . . . . . . . . . . 26 9.3. Time Synchronization
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 11. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 28 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses
1. Introduction 1. Introduction
Many advanced Service Functions (SFs) are enabled for the delivery of Many advanced Service Functions (SFs) are enabled for the delivery of
value-added services. Typically, SFs are used to meet various value-added services. Typically, SFs are used to meet various
service objectives such as IP address sharing, avoiding covert service objectives such as IP address sharing, avoiding covert
channels, detecting Denial-of-Service (DoS) attacks and protecting channels, detecting Denial-of-Service (DoS) attacks and protecting
network infrastructures against them, network slicing, etc. Because network infrastructures against them, network slicing, etc. Because
of the proliferation of such advanced SFs together with complex of the proliferation of such advanced SFs together with complex
service deployment constraints that demand more agile service service deployment constraints that demand more agile service
delivery procedures, operators need to rationalize their service delivery procedures, operators need to rationalize their service
delivery logic and control its complexity while optimising service delivery logic and control its complexity while optimizing service
activation time cycles. The overall problem space is described in activation time cycles. The overall problem space is described in
[RFC7498]. [RFC7498].
[RFC7665] presents a data plane architecture addressing the [RFC7665] presents a data plane architecture addressing the
problematic aspects of existing service deployments, including problematic aspects of existing service deployments, including
topological dependence and configuration complexity. It also topological dependence and configuration complexity. It also
describes an architecture for the specification, creation, and describes an architecture for the specification, creation, and
maintenance of Service Function Chains (SFCs) within a network. That maintenance of Service Function Chains (SFCs) within a network, that
is, how to define an ordered set of SFs and ordering constraints that is, how to define an ordered set of SFs and ordering constraints that
must be applied to packets/flows selected as a result of traffic must be applied to packets/flows selected as a result of traffic
classification. [RFC8300] specifies the SFC encapsulation: Network classification. [RFC8300] specifies the SFC encapsulation: Network
Service Header (NSH). Service Header (NSH).
The NSH data is unauthenticated and unencrypted, forcing a service 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 [RFC8300]). encapsulation that supports such features (Section 8.2 of [RFC8300]).
Note that some transport encapsulations (e.g., IPsec) only provide Note that some transport encapsulations (e.g., IPsec) only provide
skipping to change at page 3, line 40 skipping to change at line 129
or SFs within a Service Function Path (SFP) that are not authorized or SFs within a Service Function Path (SFP) that are not authorized
to access the sensitive metadata (e.g., privacy-sensitive to access the sensitive metadata (e.g., privacy-sensitive
information) will have access to the metadata. As a reminder, the information) will have access to the metadata. As a reminder, the
metadata referred to is information that is inserted by Classifiers metadata referred to is information that is inserted by Classifiers
or intermediate SFs and shared with downstream SFs; such information or intermediate SFs and shared with downstream SFs; such information
is not visible to the communication endpoints (Section 4.9 of is not visible to the communication endpoints (Section 4.9 of
[RFC7665]). [RFC7665]).
The lack of such capability was reported during the development of The lack of such capability was reported during the development of
[RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of [RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of
[I-D.arkko-farrell-arch-model-t] for a discussion on the need for [INTERNET-THREAT-MODEL] for a discussion on the need for more
more awareness about attacks from within closed domains. awareness about attacks from within closed domains.
This specification fills that gap for SFC (that is, it defines the This specification fills that gap for SFC (that is, it defines the
"NSH Variable Header-Based Integrity" option mentioned in "NSH Variable Header-Based Integrity" option mentioned in
Section 8.2.1 of [RFC8300]). Concretely, this document adds Section 8.2.1 of [RFC8300]). Concretely, this document adds
integrity protection and optional encryption of sensitive metadata integrity protection and optional encryption of sensitive metadata
directly to the NSH (Section 4). The integrity protection covers the directly to the NSH (Section 4). The integrity protection covers the
packet payload and provides replay protection (Section 7.4). Thus, packet payload and provides replay protection (Section 7.4). Thus,
the NSH does not have to rely upon an underlying transport the NSH does not have to rely upon an underlying transport
encapsulation for security. encapsulation for security.
This specification introduces new Variable-Length Context Headers to This specification introduces new Variable-Length Context Headers to
carry fields necessary for integrity-protected NSH headers and carry fields necessary for integrity-protected NSH headers and
encrypted Context Headers (Section 5). This specification is only encrypted Context Headers (Section 5). This specification is only
applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU
considerations are discussed in Section 8. This specification is not considerations are discussed in Section 8. This specification is not
applicable to NSH MD Type 0x01 (Section 2.4 of [RFC8300]) because applicable to NSH MD Type 0x01 (Section 2.4 of [RFC8300]) because
that MD Type only allows a Fixed-Length Context Header whose size is that MD Type only allows a Fixed-Length Context Header whose size is
16-bytes; that is not sufficient to accommodate both the metadata and 16 bytes; that is not sufficient to accommodate both the metadata and
message integrity of the NSH data. message integrity of the NSH data.
This specification limits access to NSH-supplied information along an This specification limits access to NSH-supplied information along an
SFP to entities that have a need to interpret it. SFP to entities that have a need to interpret it.
The mechanism specified in this document does not preclude the use of The mechanism specified in this document does not preclude the use of
transport security. Such considerations are deployment-specific. transport security. Such considerations are deployment specific.
It is out of the scope of this document to specify an NSH-aware It is out of the scope of this document to specify an NSH-aware
control plane solution. control plane solution.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in [RFC7665] and This document makes use of the terms defined in [RFC7665] and
[RFC8300]. The term "transport encapsulation" used in this document [RFC8300]. The term "transport encapsulation" used in this document
refers to the outer encapsulation (e.g., Generic Routing refers to the outer encapsulation (e.g., Generic Routing
Encapsulation (GRE), IPsec, Generic Protocol Extension for VXLAN Encapsulation (GRE), IPsec, and Generic Protocol Extension for
(VXLAN-GPE)) that is used to carry NSH-encapsulated packets as per Virtual eXtensible Local Area Network (VXLAN-GPE)) that is used to
Section 4 of [RFC8300]. carry NSH-encapsulated packets as per Section 4 of [RFC8300].
The document defines the following terms: The document defines the following terms:
SFC data plane element: Refers to NSH-aware SF, SFF, SFC Proxy, or SFC data plane element: Refers to NSH-aware SF, SFF, the SFC Proxy,
Classifier as defined in the SFC data plane architecture [RFC7665] or the Classifier as defined in the SFC data plane architecture
and further refined in [RFC8300]. [RFC7665] and further refined in [RFC8300].
SFC control element: Is a logical entity that instructs one or more SFC control element: Is a logical entity that instructs one or more
SFC data plane elements on how to process NSH packets within an SFC data plane elements on how to process NSH packets within an
SFC-enabled domain. SFC-enabled domain.
Key Identifier: Is used to identify keys to authorized entities. Key Identifier: Is used to identify keys to authorized entities.
See, for example, 'kid' usage in [RFC7635]. See, for example, "kid" usage in [RFC7635].
NSH data: The NSH is composed of a Base Header, a Service Path NSH data: The NSH is composed of a Base Header, a Service Path
Header, and optional Context Headers. NSH data refers to all the Header, and optional Context Headers. NSH data refers to all the
above headers and the packet or frame on which the NSH is imposed above headers and the packet or frame on which the NSH is imposed
to realize an SFP. to realize an SFP.
NSH imposer: Refers to an SFC data plane element that is entitled to NSH imposer: Refers to an SFC data plane element that is entitled to
impose the NSH with the Context Headers defined in this document. impose the NSH with the Context Headers defined in this document.
3. Assumptions and Basic Requirements 3. Assumptions and Basic Requirements
Section 2 of [RFC8300] specifies that the NSH data can be spread over Section 2 of [RFC8300] specifies that the NSH data can be spread over
three headers: three headers:
o Base Header: Provides information about the service header and the Base Header: Provides information about the service header and the
payload protocol. payload protocol.
o Service Path Header: Provides path identification and location Service Path Header: Provides path identification and location
within an SFP. within an SFP.
o Context Header(s): Carries metadata (i.e., context data) along a Context Header(s): Carries metadata (i.e., context data) along a
service path. service path.
The NSH allows sharing context information (a.k.a., metadata) with The NSH allows sharing context information (a.k.a. metadata) with
downstream NSH-aware data plane elements on a per SFC/SFP basis. To downstream NSH-aware data plane elements on a per-SFC/SFP basis. To
that aim: that aim:
The Classifier is instructed by an SFC control element about the * The Classifier is instructed by an SFC control element about the
set of context information to be supplied for a given service set of context information to be supplied for a given service
function chain. function chain.
An NSH-aware SF is instructed by an SFC control element about any * An NSH-aware SF is instructed by an SFC control element about any
metadata it needs to attach to packets for a given service metadata it needs to attach to packets for a given service
function chain. This instruction may occur any time during the function chain. This instruction may occur any time during the
validity lifetime of an SFC/SFP. For a given service function validity lifetime of an SFC/SFP. For a given service function
chain, the NSH-aware SF is also provided with an order for chain, the NSH-aware SF is also provided with an order for
consuming a set of contexts supplied in a packet. consuming a set of contexts supplied in a packet.
An NSH-aware SF can also be instructed by an SFC control element * 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 information that was supplied in the NSH. For example, the
context information can be maintained, updated, or stripped. context information can be maintained, updated, or stripped.
An SFC Proxy may be instructed by an SFC control element about the * An SFC Proxy may be instructed by an SFC control element about the
behavior it should adopt to process the context information that 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 may also be instructed to add some new context information into
the NSH on behalf of an NSH-unaware SF. the NSH on behalf of an NSH-unaware SF.
In reference to Table 1, In reference to Table 1:
o Classifiers, NSH-aware SFs, and SFC proxies are entitled to update * Classifiers, NSH-aware SFs, and SFC proxies are entitled to update
the Context Header(s). the Context Header(s).
o Only NSH-aware SFs and SFC proxies are entitled to update the * Only NSH-aware SFs and SFC proxies are entitled to update the
Service Path Header. Service Path Header.
o SFFs are entitled to modify the Base Header (TTL value, for * SFFs are entitled to modify the Base Header (TTL value, for
example). Nevertheless, SFFs are not supposed to act on the example). Nevertheless, SFFs are not supposed to act on the
Context Headers or look into the content of the Context Headers Context Headers or look into the content of the Context Headers
(Section 4.3 of [RFC7665]). (Section 4.3 of [RFC7665]).
Thus, the following requirements: Thus, the following requirements:
o Only Classifiers, NSH-aware SFs, and SFC proxies must be able to * Only Classifiers, NSH-aware SFs, and SFC proxies must be able to
encrypt and decrypt a given Context Header. encrypt and decrypt a given Context Header.
o Both encrypted and unencrypted Context Headers may be included in * Both encrypted and unencrypted Context Headers may be included in
the same NSH. the same NSH.
o The solution must provide integrity protection for the Service * The solution must provide integrity protection for the Service
Path Header. Path Header.
o The solution must provide optional integrity protection for the * The solution must provide optional integrity protection for the
Base Header. The implications of disabling such checks are Base Header. The implications of disabling such checks are
discussed in Section 9.1. discussed in Section 9.1.
+----------------+-----------------------------+-------------------+ +=============+===========================+=======================+
| | Insert, remove, or replace | Update the NSH | | SFC Data | Insert, remove, or | Update the NSH |
| | the NSH | | | Plane | replace the NSH | |
| | | | | Element +========+========+=========+===========+===========+
| SFC Data Plane +---------+---------+---------+---------+---------+ | | Insert | Remove | Replace | Decrement | Update |
| Element | | | |Decrement| Update | | | | | | Service | Context |
| | Insert | Remove | Replace | Service | Context | | | | | | Index | Header(s) |
| | | | | Index |Header(s)| +=============+========+========+=========+===========+===========+
+================+=========+=========+=========+=========+=========+ | Classifier | + | | + | | + |
| | + | | + | | + | +-------------+--------+--------+---------+-----------+-----------+
| Classifier | | | | | | | Service | | + | | | |
+----------------+---------+---------+---------+---------+---------+ | Function | | | | | |
|Service Function| | + | | | | | Forwarder | | | | | |
|Forwarder (SFF) | | | | | | | (SFF) | | | | | |
+----------------+---------+---------+---------+---------+---------+ +-------------+--------+--------+---------+-----------+-----------+
|Service Function| | | | + | + | | Service | | | | + | + |
| (SF) | | | | | | | Function | | | | | |
+----------------+---------+---------+---------+---------+---------+ | (SF) | | | | | |
| | + | + | | + | + | +-------------+--------+--------+---------+-----------+-----------+
| SFC Proxy | | | | | | | Service | + | + | | + | + |
+----------------+---------+---------+---------+---------+---------+ | Function | | | | | |
| Chaining | | | | | |
| (SFC) Proxy | | | | | |
+-------------+--------+--------+---------+-----------+-----------+
Table 1: Summary of NSH Actions Table 1: Summary of NSH Actions
4. Design Overview 4. Design Overview
4.1. Supported Security Services 4.1. Supported Security Services
This specification provides the functions described in the following This specification provides the functions described in the following
subsections. subsections.
4.1.1. Encrypt All or a Subset of Context Headers 4.1.1. Encrypt All or a Subset of Context Headers
The solution allows encrypting all or a subset of NSH Context Headers The solution allows encrypting all or a subset of NSH Context Headers
by Classifiers, NSH-aware SFs, and SFC proxies. by Classifiers, NSH-aware SFs, and SFC proxies.
As depicted in Table 2, SFFs are not involved in data encryption. As depicted in Table 2, SFFs are not involved in data encryption.
+-----------------+------------------------------+------------------+ +====================+=======================+================+
| Data Plane | Base and Service Path | Context Header | | Data Plane Element | Base and Service Path | Context Header |
| Element | Headers Encryption | Encryption | | | Headers Encryption | Encryption |
+-----------------+------------------------------+------------------+ +====================+=======================+================+
| Classifier | No | Yes | | Classifier | No | Yes |
| SFF | No | No | +--------------------+-----------------------+----------------+
| NSH-aware SF | No | Yes | | SFF | No | No |
| SFC Proxy | No | Yes | +--------------------+-----------------------+----------------+
| NSH-unaware SF | No | No | | NSH-aware SF | No | Yes |
+-----------------+------------------------------+------------------+ +--------------------+-----------------------+----------------+
| SFC Proxy | No | Yes |
+--------------------+-----------------------+----------------+
| NSH-unaware SF | No | No |
+--------------------+-----------------------+----------------+
Table 2: Encryption Function Supported by SFC Data Plane Elements Table 2: Encryption Function Supported by SFC Data Plane
Elements
Classifier(s), NSH-aware SFs, and SFC proxies are instructed with the Classifier(s), NSH-aware SFs, and SFC proxies are instructed with the
set of Context Headers (privacy-sensitive metadata, typically) that set of Context Headers (privacy-sensitive metadata, typically) that
must be encrypted. Encryption keying material is only provided to must be encrypted. Encryption keying material is only provided to
these SFC data plane elements. these SFC data plane elements.
The control plane may indicate the set of SFC data plane elements 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 instructions. elements nor to detail the structure used to store the instructions.
The Service Path Header (Section 2 of [RFC8300]) is not encrypted The Service Path Header (Section 2 of [RFC8300]) is not encrypted
because SFFs use Service Index (SI) in conjunction with Service Path because SFFs use the Service Index (SI) in conjunction with the
Identifier (SPI) for determining the next SF in the path. Service Path Identifier (SPI) for determining the next SF in the
path.
4.1.2. Integrity Protection 4.1.2. Integrity Protection
The solution provides integrity protection for the NSH data. Two The solution provides integrity protection for the NSH data. Two
levels of assurance (LoAs) are supported. levels of assurance (LoAs) are supported.
The first level of assurance is where all NSH data except the Base The first level of assurance is where all NSH data except the Base
Header are integrity protected (Figure 1). In this case, the NSH Header are integrity protected (Figure 1). In this case, the NSH
imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs
are not provided with authentication material. Further details are are not provided with authentication material. Further details are
skipping to change at page 9, line 17 skipping to change at line 364
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| 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
Figure 1: First Level of Assurance Figure 1: First Level of Assurance
The second level of assurance is where all NSH data, including the The second level of assurance is where all NSH data, including the
Base Header, are integrity protected (Figure 2). In this case, the Base Header, are integrity protected (Figure 2). In this case, the
NSH imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC NSH imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC
Proxy. Further details are provided in Section 5.2. Proxy. Further details are provided in Section 5.2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Figure 2: Second Level of Assurance Figure 2: Second Level of Assurance
The integrity protection scope is explicitly signaled to NSH-aware The integrity-protection scope is explicitly signaled to NSH-aware
SFs, SFFs, and SFC proxies in the NSH by means of a dedicated MD Type SFs, SFFs, and SFC proxies in the NSH by means of a dedicated MD Type
(Section 5). (Section 5).
In both levels of assurance, the Context Headers and the packet on In both levels of assurance, the Context Headers and the packet on
which the NSH is imposed are subject to integrity protection. which the NSH is imposed are subject to integrity protection.
Table 3 classifies the data plane elements as being involved in Table 3 classifies the data plane elements as being involved or not
providing integrity protection for the NSH or not. involved in providing integrity protection for the NSH.
+--------------------+----------------------------------+ +====================+==================================+
| Data Plane Element | Integrity Protection | | Data Plane Element | Integrity Protection |
+--------------------+----------------------------------+ +====================+==================================+
| Classifier | Yes | | Classifier | Yes |
| SFF | No (first LoA); Yes (second LoA) | +--------------------+----------------------------------+
| NSH-aware SF | Yes | | SFF | No (first LoA); Yes (second LoA) |
| SFC Proxy | Yes | +--------------------+----------------------------------+
| NSH-unaware SF | No | | NSH-aware SF | Yes |
+--------------------+----------------------------------+ +--------------------+----------------------------------+
| SFC Proxy | Yes |
+--------------------+----------------------------------+
| NSH-unaware SF | No |
+--------------------+----------------------------------+
Table 3: Integrity Protection Supported by SFC Data Plane Elements Table 3: Integrity Protection Supported by SFC Data
Plane Elements
4.2. One Secret Key, Two Security Services 4.2. One Secret Key, Two Security Services
The Authenticated Encryption with Associated Data (AEAD) interface The Authenticated Encryption with Associated Data (AEAD) interface
defined in Section 5 of [RFC5116] is used to encrypt the Context defined in Section 5 of [RFC5116] is used to encrypt the Context
Headers that carry sensitive metadata and to provide integrity Headers that carry sensitive metadata and to provide integrity
protection for the encrypted Context Headers. protection for the encrypted Context Headers.
The secondary keys MAC_KEY and ENC_KEY are generated from the input The secondary keys "MAC_KEY" and "ENC_KEY" are generated from the
secret key (K) as follows; each of these two keys is an octet string: input secret key (K) as follows; each of these two keys is an octet
string:
MAC_KEY: consists of the initial MAC_KEY_LEN octets of K, in order. MAC_KEY: Consists of the initial MAC_KEY_LEN octets of K, in order.
The MAC_KEY is used for calculating the message integrity of the The MAC_KEY is used for calculating the message integrity of the
NSH data. In other words, the integrity protection provided by NSH data. In other words, the integrity protection provided by
the cryptographic mechanism is extended to also provide protection the cryptographic mechanism is extended to also provide protection
for the unencrypted Context Headers and the packet on which the for the unencrypted Context Headers and the packet on which the
NSH is imposed. NSH is imposed.
ENC_KEY: consists of the final ENC_KEY_LEN octets of K, in order. ENC_KEY: Consists of the final ENC_KEY_LEN octets of K, in order.
The ENC_KEY is used as the symmetric encryption key for encrypting The ENC_KEY is used as the symmetric encryption key for encrypting
the Context Headers. the Context Headers.
The Hashed Message Authentication Mode (HMAC) algorithm discussed in The Hashed Message Authentication Code (HMAC) algorithm discussed in
[RFC4868] is used to protect the integrity of the NSH data. The [RFC4868] is used to protect the integrity of the NSH data. The
algorithm for implementing and validating HMACs is provided in algorithm for implementing and validating HMACs is provided in
[RFC2104]. [RFC2104].
The advantage of using both AEAD and HMAC algorithms (instead of just The advantage of using both AEAD and HMAC algorithms (instead of just
AEAD) is that NSH-aware SFs and SFC proxies only need to re-compute AEAD) is that NSH-aware SFs and SFC proxies only need to recompute
the message integrity of the NSH data after decrementing the Service the message integrity of the NSH data after decrementing the SI and
Index (SI) and do not have to re-compute the ciphertext. The other do not have to recompute the ciphertext. The other advantage is that
advantage is that SFFs do not have access to the ENC_KEY and cannot SFFs do not have access to the ENC_KEY and cannot act on the
act on the encrypted Context Headers and (in the case of the second encrypted Context Headers, and (in the case of the second level of
level of assurance) SFFs do have access to the MAC_KEY. Similarly, assurance) SFFs do have access to the MAC_KEY. Similarly, an NSH-
an NSH-aware SF or SFC Proxy not allowed to decrypt the Context aware SF or SFC Proxy not allowed to decrypt the Context Headers will
Headers will not have access to the ENC_KEY. not have access to the ENC_KEY.
The authenticated encryption algorithm or HMAC algorithm to be used 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 Section 4.3. HMAC algorithms are listed in Section 4.3.
The authenticated encryption process takes four inputs, each of which The authenticated encryption process takes four inputs, each of which
is an octet string: a secret key (ENC_KEY, referred to as K in is an octet string: a secret key (ENC_KEY, referred to as "K" in
[RFC5116]), a plaintext (P), associated data (A) (which contains the [RFC5116]), a plaintext (P), associated data (A) (which contains the
data to be authenticated, but not encrypted), and a nonce (N). A data to be authenticated but not encrypted), and a nonce (N). A
ciphertext (C) is generated as an output as discussed in Section 2.1 ciphertext (C) is generated as an output as discussed in Section 2.1
of [RFC5116]. of [RFC5116].
In order to decrypt and verify, the cipher takes as input ENC_KEY, N, In order to decrypt and verify, the cipher takes ENC_KEY, N, A, and C
A, and C. The output is either the plaintext or an error indicating as input. The output is either the plaintext or an error indicating
that the decryption failed as described in Section 2.2 of [RFC5116]. that the decryption failed as described in Section 2.2 of [RFC5116].
4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 4.3. Mandatory-to-Implement Authenticated Encryption and HMAC
Algorithms Algorithms
Classifiers, NSH-aware SFs, and SFC proxies MUST implement the Classifiers, NSH-aware SFs, and SFC proxies MUST implement the
AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the
AES_192_GCM and AES_256_GCM algorithms. AES_192_GCM and AES_256_GCM algorithms.
Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC- Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC-
SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and
HMAC-SHA-512-256 algorithms. HMAC-SHA-512-256 algorithms.
SFFs MAY implement the aforementioned cipher suites and HMAC SFFs MAY implement the aforementioned cipher suites and HMAC
algorithms. algorithms.
Note: The use of AES_128_CBC_HMAC_SHA_256 algorithm would have Note: The use of the AES_128_CBC_HMAC_SHA_256 algorithm would have
avoided the need for a second 128-bit authentication tag, but due avoided the need for a second 128-bit authentication tag, but due
to the nature of how Cipher Block Chaining (CBC) mode operates, to the nature of how Cipher Block Chaining (CBC) mode operates,
AES_128_CBC_HMAC_SHA_256 allows for malleability of plaintexts. AES_128_CBC_HMAC_SHA_256 allows for the malleability of
This malleability allows for attackers that know the MAC key but plaintexts. This malleability allows for attackers that know the
not the encryption key to make changes in the ciphertext and, if Message Authentication Code (MAC) key but not the encryption key
parts of the plaintext are known, create arbitrary blocks of to make changes in the ciphertext and, if parts of the plaintext
plaintext. This specification mandates the use of separate AEAD are known, create arbitrary blocks of plaintext. This
and MAC protections to prevent this type of attack. specification mandates the use of separate AEAD and MAC
protections to prevent this type of attack.
4.4. Key Management 4.4. Key Management
The procedure for the allocation/provisioning of secret keys (K) and The procedure for the allocation/provisioning of secret keys (K) and
authenticated encryption algorithm or MAC_KEY and HMAC algorithm is the authenticated encryption algorithm or MAC_KEY and HMAC algorithm
outside the scope of this specification. As such, this specification is outside the scope of this specification. As such, this
does not mandate the support of any specific mechanism. specification does not mandate the support of any specific mechanism.
The document does not assume nor preclude the following: The document does not assume nor preclude the following:
o The same keying material is used for all the service functions * The same keying material is used for all the service functions
used within an SFC-enabled domain. used within an SFC-enabled domain.
o Distinct keying material is used per SFP by all involved SFC data * Distinct keying material is used per SFP by all involved SFC data
path elements. path elements.
o Per-tenant keys are used. * Per-tenant keys are used.
In order to accommodate deployments relying upon keying material per In order to accommodate deployments relying upon keying material per
SFC/SFP and also the need to update keys after encrypting NSH data 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. addresses the problem of the synchronization of keying material.
Additional information on manual vs. automated key management and Additional information on manual vs. automated key management and
when one should be used over the other can be found in [RFC4107]. when one should be used over the other can be found in [RFC4107].
The risk involved in using a group-shared symmetric key increases The risk involved in using a group-shared symmetric key increases
with the size of the group to which it is shared. Additional with the size of the group to which it is shared. Additional
security issues are discussed in Section 9. security issues are discussed in Section 9.
4.5. New NSH Variable-Length Context Headers 4.5. New NSH Variable-Length Context Headers
New NSH Variable-Length Context Headers are defined in Section 5 for New NSH Variable-Length Context Headers are defined in Section 5 for
NSH data integrity protection and, optionally, encryption of Context NSH data integrity protection and, optionally, encryption of Context
Headers carrying sensitive metadata. Concretely, an NSH imposer Headers carrying sensitive metadata. Concretely, an NSH imposer
includes (1) the key identifier to identify the keying material, (2) includes (1) the key identifier to identify the keying material, (2)
the timestamp to protect against replay attacks (Section 7.4), and the timestamp to protect against replay attacks (Section 7.4), and
(3) the Message Authentication Code (MAC) for the target NSH data (3) MAC for the target NSH data (depending on the integrity-
(depending on the integrity protection scope) calculated using the protection scope) calculated using MAC_KEY and, optionally, Context
MAC_KEY and optionally Context Headers encrypted using ENC_KEY. Headers encrypted using ENC_KEY.
An SFC data plane element that needs to check the integrity of the 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. being carried in the NSH.
An NSH-aware SF or SFC Proxy that needs to decrypt some Context 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. identifier being carried in the NSH.
Section 7 specifies the detailed procedure. Section 7 specifies the detailed procedure.
4.6. Encapsulation of NSH within NSH 4.6. Encapsulation of NSH within NSH
As discussed in Section 3 of [RFC8459], an SFC-enabled domain As discussed in Section 3 of [RFC8459], an SFC-enabled domain (called
(called, upper-level domain) may be decomposed into many sub-domains an upper-level domain) may be decomposed into many sub-domains
(called, lower-level domains). In order to avoid maintaining state (called lower-level domains). In order to avoid maintaining state to
to restore back upper-level NSH information at the boundaries of restore upper-level NSH information at the boundaries of lower-level
lower-level domains, two NSH levels are used: an Upper-NSH which is domains, two NSH levels are used: an Upper-NSH that is imposed at the
imposed at the boundaries of the upper-level domain and a Lower-NSH boundaries of the upper-level domain and a Lower-NSH that is pushed
that is pushed by the Classifier of a lower-level domain in front of by the Classifier of a lower-level domain in front of the original
the original NSH (Figure 3). As such, the Upper-NSH information is NSH (Figure 3). As such, the Upper-NSH information is carried along
carried along the lower-level chain without modification. The packet the lower-level chain without modification. The packet is forwarded
is forwarded in the top-level domain according to the Upper-NSH, in the top-level domain according to the Upper-NSH, while it is
while it is forwarded according to the Lower-NSH in a lower-level forwarded according to the Lower-NSH in a lower-level domain.
domain.
+---------------------------------+ +---------------------------------+
| Transport Encapsulation | | Transport Encapsulation |
+->+---------------------------------+ +->+---------------------------------+
| | Lower-NSH Header | | | Lower-NSH Header |
| +---------------------------------+ | +---------------------------------+
| | Upper-NSH Header | | | Upper-NSH Header |
| +---------------------------------+ | +---------------------------------+
| | Original Packet | | | Original Packet |
+->+---------------------------------+ +->+---------------------------------+
skipping to change at page 13, line 39 skipping to change at line 585
SFC data plane elements of a lower-level domain include the Upper-NSH SFC data plane elements of a lower-level domain include the Upper-NSH
when computing the MAC. when computing the MAC.
Keying material used at the upper-level domain SHOULD NOT be the same Keying material used at the upper-level domain SHOULD NOT be the same
as the one used by a lower-level domain. as the one used by a lower-level domain.
5. New NSH Variable-Length Context Headers 5. New NSH Variable-Length Context Headers
This section specifies the format of new Variable-Length Context 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. Context Header encryption.
In particular, this section defines two "MAC and Encrypted Metadata" 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
Section 5.1, the level of assurance provided in Section 5.2 requires Section 5.1, the level of assurance provided in Section 5.2 requires
sharing MAC_KEY with SFFs. Both Context headers have the same format sharing MAC_KEY with SFFs. Both Context Headers have the same format
as shown in Figure 4. as shown in Figure 4.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MAC and Encrypted Metadata Context Header Figure 4: MAC and Encrypted Metadata Context Header
The "MAC and Encrypted Metadata" Context Headers are padded out to a The "MAC and Encrypted Metadata" Context Headers are padded out to a
multiple of 4 bytes as per Section 2.2 of [RFC8300]. The "MAC and multiple of 4 bytes as per Section 2.2 of [RFC8300]. The "MAC and
Encrypted Metadata" Context Header, if included, MUST always be the Encrypted Metadata" Context Header, if included, MUST always be the
last Context Header. last Context Header.
5.1. MAC#1 Context Header 5.1. MAC#1 Context Header
MAC#1 Context Header is a variable-length Context Header that carries The MAC#1 Context Header is a Variable-Length Context Header that
the Message Authentication Code (MAC) for the Service Path Header, carries MAC for the Service Path Header, Context Headers, and the
Context Headers, and the inner packet on which NSH is imposed, inner packet on which NSH is imposed, calculated using MAC_KEY and,
calculated using MAC_KEY, and optionally Context Headers encrypted optionally, Context Headers encrypted using ENC_KEY. The scope of
using ENC_KEY. The scope of the integrity protection provided by the integrity protection provided by this Context Header is depicted
this Context Header is depicted in Figure 5. in Figure 5.
This MAC scheme does not require sharing MAC_KEY with SFFs. It does 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. Section 9.1 discusses the possible threat associated processing. Section 9.1 discusses the possible threat associated
with this level of assurance. with this level of assurance.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 15, line 31 skipping to change at line 657
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ 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
Figure 5: Scope of MAC#1 Figure 5: Scope of MAC#1
In reference to Figure 4, the description of the fields is as In reference to Figure 4, the description of the fields is as
follows: follows:
Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). Metadata Class: MUST be set to 0x0 (Section 2.2 of [RFC8300]).
Type: TBD1 (See Section 10) Type: 0x02 (see Section 10).
U: Unassigned bit (Section 2.5.1 of [RFC8300]). U: Unassigned bit (Section 2.5.1 of [RFC8300]).
Length: Indicates the length of the variable-length metadata, in Length: Indicates the length of the variable-length metadata in
bytes. Padding considerations are discussed in Section 2.5.1 of bytes. Padding considerations are discussed in
[RFC8300]. Section 2.5.1 of [RFC8300].
Key Id Len: Variable. Carries the length of the key identifier, in Key Id Len: Variable. Carries the length of the key identifier in
octets. octets.
Key Identifier: Carries a variable-length Key Identifier object used Key Identifier: Carries a variable-length Key Identifier object used
to identify and deliver keys to SFC data plane elements. This to identify and deliver keys to SFC data plane elements.
identifier is helpful to accommodate deployments relying upon This identifier is helpful for accommodating deployments
keying material per SFC/SFP. The key identifier helps in relying upon keying material per SFC/SFP. The key
resolving the problem of synchronization of keying material. A identifier helps to resolve the problem of
single key identifier is used to lookup both the ENC_KEY and the synchronization of keying material. A single key
MAC_KEY associated with a key, and the corresponding encryption identifier is used to look up both the ENC_KEY and the
and MAC algorithms used with those keys. MAC_KEY associated with a key, and the corresponding
encryption and MAC algorithms used with those keys.
Timestamp: Refer to Section 6 for more details about the structure Timestamp: Refer to Section 6 for more details about the structure
of this field. of this field.
Nonce Length: Carries the length of the Nonce. If the Context Nonce Length: Carries the length of the Nonce. If the Context
Headers are only integrity protected, "Nonce Length" is set to Headers are only integrity protected, "Nonce Length" is
zero (that is, no "Nonce" is included). set to zero (that is, no "Nonce" is included).
Nonce: Carries the Nonce for the authenticated encryption operation Nonce: Carries the Nonce for the authenticated encryption
(Section 3.1 of [RFC5116]). operation (Section 3.1 of [RFC5116]).
Encrypted Context Headers: Carries the optional encrypted Context Encrypted Context Headers: Carries the optional encrypted Context
Headers. Headers.
Message Authentication Code: Covers the entire NSH data, excluding Message Authentication Code: Covers the entire NSH data, excluding
the Base header. the Base Header.
5.2. MAC#2 Context Header 5.2. MAC#2 Context Header
MAC#2 Context Header is a variable-length Context Header that carries The MAC#2 Context Header is a Variable-Length Context Header that
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
integrity protection provided by this Context Header is depicted in the integrity protection provided by this Context Header is depicted
Figure 6. in Figure 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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.) ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 17, line 31 skipping to change at line 738
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ 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
Figure 6: Scope of MAC#2 Figure 6: Scope of MAC#2
In reference to Figure 4, the description of the fields is as In reference to Figure 4, the description of the fields is as
follows: follows:
Metadata Class: MUST be set to 0x0 (Section 2.5.1 of [RFC8300]). Metadata Class: MUST be set to 0x0 (Section 2.2 of [RFC8300]).
Type: TBD2 (See Section 10) Type: 0x03 (see Section 10).
U: Unassigned bit (Section 2.5.1 of [RFC8300]). U: Unassigned bit (Section 2.5.1 of [RFC8300]).
Length: Indicates the length of the variable-length metadata, in Length: Indicates the length of the variable-length metadata in
bytes. Padding considerations are discussed in Section 2.5.1 of bytes. Padding considerations are discussed in
[RFC8300]. Section 2.5.1 of [RFC8300].
Key Id Len: See Section 5.1. Key Id Len: See Section 5.1.
Key Identifier: See Section 5.1. Key Identifier: See Section 5.1.
Timestamp: See Section 6. Timestamp: See Section 6.
Nonce Length: See Section 5.1. Nonce Length: See Section 5.1.
Nonce: See Section 5.1. Nonce: See Section 5.1.
Encrypted Context Headers: Carries the optional encrypted Context Encrypted Context Headers: Carries the optional encrypted Context
Headers. Headers.
Message Authentication Code: Covers the entire NSH data. Message Authentication Code: Covers the entire NSH data.
6. Timestamp Format 6. Timestamp Format
This section follows the template provided in Section 3 of [RFC8877]. This section follows the template provided in Section 3 of [RFC8877].
The format of the Timestamp field introduced in Section 5 is depicted The format of the Timestamp field introduced in Section 5 is depicted
in Figure 7. in Figure 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Timestamp Field Format Figure 7: Timestamp Field Format
Timestamp field format: Timestamp field format:
Seconds: Specifies the integer portion of the number of seconds
since the epoch.
Seconds: specifies the integer portion of the number of seconds + Size: 32 bits
since the epoch.
+ Size: 32 bits.
+ Units: seconds. + Units: Seconds
Fraction: specifies the fractional portion of the number of Fraction: Specifies the fractional portion of the number of
seconds since the epoch. seconds since the epoch.
+ Size: 32 bits. + Size: 32 bits
+ Units: the unit is 2^(-32) seconds, which is roughly equal to + Units: The unit is 2^(-32) seconds, which is roughly equal to
233 picoseconds. 233 picoseconds.
Epoch: Epoch:
The epoch is 1970-01-01T00:00 in UTC time. Note that this epoch
The epoch is 1970-01-01T00:00 in UTC time. Note this epoch value value is different from the one used in Section 6 of [RFC5905]
is different from the one used in Section 6 of [RFC5905] (which (which will wrap around in 2036).
will wrap around in 2036).
Leap seconds: Leap seconds:
This timestamp format is affected by leap seconds. The timestamp This timestamp format is affected by leap seconds. The timestamp
represents the number of seconds elapsed since the epoch minus the represents the number of seconds elapsed since the epoch minus the
number of leap seconds. number of leap seconds.
Resolution: Resolution:
The resolution is 2^(-32) seconds. The resolution is 2^(-32) seconds.
Wraparound: Wraparound:
This time format wraps around every 2^32 seconds, which is roughly This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2106. 136 years. The next wraparound will occur in the year 2106.
Synchronization aspects: Synchronization aspects:
It is assumed that SFC data plane elements are synchronized to UTC It is assumed that SFC data plane elements are synchronized to UTC
using a synchronization mechanism that is outside the scope of using a synchronization mechanism that is outside the scope of
this document. In typical deployments, SFC data plane elements this document. In typical deployments, SFC data plane elements
use NTP [RFC5905] for synchronization. Thus, the timestamp may be use NTP [RFC5905] for synchronization. Thus, the timestamp may be
derived from the NTP-synchronized clock, allowing the timestamp to derived from the NTP-synchronized clock, allowing the timestamp to
be measured with respect to the clock of an NTP server. Since be measured with respect to the clock of an NTP server. Since
this time format is specified in terms of UTC, it is affected by this time format is specified in terms of UTC, it is affected by
leap seconds (in a manner analogous to the NTP time format, which leap seconds (in a manner analogous to the NTP time format, which
is similar). Therefore, the value of a timestamp during or is similar). Therefore, the value of a timestamp during or
slightly after a leap second may be temporarily inaccurate. slightly after a leap second may be temporarily inaccurate.
7. Processing Rules 7. Processing Rules
The following subsections describe the processing rules for integrity The following subsections describe the processing rules for
protected NSH and optionally encrypted Context Headers. integrity-protected NSH and, optionally, encrypted Context Headers.
7.1. Generic Behavior 7.1. Generic Behavior
This document adheres to the recommendations in Section 8.1 of This document adheres to the recommendations in Section 8.1 of
[RFC8300] for handling the Context Headers at both ingress and egress [RFC8300] for handling the Context Headers at both ingress and egress
SFC boundary nodes (i.e., to strip the entire NSH, including Context SFC boundary nodes (i.e., to strip the entire NSH, including Context
Headers). Headers).
Failures of a classifier to inject the Context Headers defined in Failures of a Classifier to inject the Context Headers defined in
this document SHOULD be logged locally while a notification alarm MAY this document SHOULD be logged locally while a notification alarm MAY
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 MUST cause that packet to be
discarded while a notification alarm MAY be sent to an SFC control discarded while a notification alarm MAY be sent to an SFC 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. thresholds, and content in the alarm) SHOULD be configurable.
NSH-aware SFs and SFC proxies MAY be instructed to strip some NSH-aware SFs and SFC proxies MAY be instructed to strip some
encrypted Context Headers from the packet or to pass the data to the encrypted Context Headers from the packet or to pass the data to the
next SF in the service function chain after processing the content of next SF in the service function chain after processing the content of
the Context Headers. If no instruction is provided, the default the Context Headers. If no instruction is provided, the default
behavior for intermediary NSH-aware nodes is to maintain such Context behavior for intermediary NSH-aware nodes is to maintain such Context
Headers so that the information can be passed to next NSH-aware hops. Headers so that the information can be passed to the next NSH-aware
NSH-aware SFs and SFC proxies MUST re-apply the integrity protection hops. NSH-aware SFs and SFC proxies MUST reapply the integrity
if any modification is made to the Context Headers (e.g., strip a protection if any modification is made to the Context Headers (e.g.,
Context Header, update the content of an existing Context Header, strip a Context Header, update the content of an existing Context
insert a new Context Header). Header, insert a new Context Header).
An NSH-aware SF or SFC Proxy that is not allowed to decrypt any 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. Context Headers MUST NOT be given access to the ENC_KEY.
Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted 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), MUST keep that
Context Header unaltered when forwarding the packet upstream. Context Header unaltered when forwarding the packet upstream.
Only one instance of "MAC and Encrypted Metadata" Context Header Only one instance of a "MAC and Encrypted Metadata" Context Header
(Section 5) is allowed in an NSH level. If multiple instances of (Section 5) is allowed in an NSH level. If multiple instances of a
"MAC and Encrypted Metadata" Context Header are included in an NSH "MAC and Encrypted Metadata" Context Header are included in an NSH
level, the SFC data plane element MUST process the first instance and level, the SFC data plane element MUST process the first instance and
ignore subsequent instances, and MAY log or increase a counter for ignore subsequent instances and MAY log or increase a counter for
this event as per Section 2.5.1 of [RFC8300]. If NSH-in-NSH is used this event as per Section 2.5.1 of [RFC8300]. If NSH within NSH is
(Section 4.6), distinct LoAs may be used for each NSH level. used (Section 4.6), distinct LoAs may be used for each NSH level.
MTU and fragmentation considerations are discussed in Section 8. MTU and fragmentation considerations are discussed in Section 8.
7.2. MAC NSH Data Generation 7.2. MAC NSH Data Generation
After performing any Context Header encryption, the HMAC algorithm After performing any Context Header encryption, the HMAC algorithm
discussed in [RFC4868] is used to integrity protect the target NSH discussed in [RFC4868] is used to integrity protect the target NSH
data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context
Header for integrity protection (Section 5). Header for integrity protection (Section 5).
The NSH imposer sets the MAC field to zero and then computes the 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 Section 5) using MAC_KEY and HMAC integrity-protection scope discussed in Section 5) using the MAC_KEY
algorithm. It inserts the computed digest in the MAC field of the and HMAC algorithm. It inserts the computed digest in the MAC field
"MAC and Encrypted Metadata" Context Header. The length of the MAC of the "MAC and Encrypted Metadata" Context Header. The length of
is decided by the HMAC algorithm adopted for the particular key the MAC is decided by the HMAC algorithm adopted for the particular
identifier. key identifier.
The Message Authentication Code (T) computation process for the 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: follows:
T = HMAC-SHA-256-128(MAC_KEY, target NSH data) T = HMAC-SHA-256-128(MAC_KEY, target NSH data)
An entity in the SFP that updates the NSH MUST follow the above 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. validations.
7.3. Encrypted NSH Metadata Generation 7.3. Encrypted NSH Metadata Generation
An NSH imposer can encrypt Context Headers carrying sensitive 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 5 and 6). simultaneously in the same NSH packet (Sections 5 and 6).
In order to prevent pervasive monitoring [RFC7258], it is RECOMMENDED In order to prevent pervasive monitoring [RFC7258], it is RECOMMENDED
to encrypt all Context Headers. All Context Headers carrying to encrypt all Context Headers. All Context Headers carrying
privacy-sensitive metadata MUST be encrypted; by doing so, privacy- privacy-sensitive metadata MUST be encrypted; by doing so, privacy-
sensitive metadata is not revealed to attackers. Privacy specific sensitive metadata is not revealed to attackers. Privacy-specific
threats are discussed in Section 5.2 of [RFC6973]. threats are discussed in Section 5.2 of [RFC6973].
Using the secret key (ENC_KEY) and authenticated encryption 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 Section 3) and inserts the resulting payload in the "MAC example, in Section 3) and inserts the resulting payload in the "MAC
and Encrypted Metadata" Context Header (Section 5). The additional and Encrypted Metadata" Context Header (Section 5). The additional
authenticated data input to the AEAD function is a zero-length byte authenticated data input to the AEAD function is a zero-length byte
string. The entire Context Header carrying a sensitive metadata is string. The entire Context Header carrying sensitive metadata is
encrypted (that is, including the MD Class, Type, Length, and encrypted (that is, including the MD Class, Type, Length, and
associated metadata of each Context Header). associated metadata of each Context Header).
More details about the exact encryption procedure are provided in More details about the exact encryption procedure are provided in
Section 2.1 of [RFC5116]. In this case, the associated data (A) Section 2.1 of [RFC5116]. In this case, the associated data (A)
input is zero-length for AES-GCM. input is zero length for AES Galois/Counter Mode (AES-GCM).
An authorized entity in the SFP that updates the content of an 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. Header MUST also follow the aforementioned behavior.
7.4. Timestamp for Replay Attack Prevention 7.4. Timestamp for Replay Attack Prevention
The Timestamp imposed by an initial Classifier is left untouched The Timestamp imposed by an initial Classifier is left untouched
along an SFP. However, it can be updated when reclassification along an SFP. However, it can be updated when reclassification
occurs (Section 4.8 of [RFC7665]). The same considerations for occurs (Section 4.8 of [RFC7665]). The same considerations for
setting the Timestamp are followed in both initial classification and setting the Timestamp are followed in both initial classification and
reclassification (Section 6). reclassification (Section 6).
The received NSH is accepted by an NSH-aware node if the Timestamp 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: (TSrt). The following formula is used for this check:
-Delta < (TSrt - TS) < +Delta -Delta < (TSrt - TS) < +Delta
The Delta interval is a configurable parameter. The default value The Delta interval is a configurable parameter. The default value
for the allowed Delta is 2 seconds. Special care should be taken for the allowed Delta is 2 seconds. Special care should be taken
when setting very low Delta values as this may lead to dropping when setting very low Delta values as this may lead to dropping
legitimate traffic. If the timestamp is not within the boundaries, legitimate traffic. If the timestamp is not within the boundaries,
then the SFC data plane element receiving such packet MUST discard then the SFC data plane element receiving such packets MUST discard
the NSH message. the NSH message.
Replay attacks within the Delta window may be detected by an NSH- Replay attacks within the Delta window may be detected by an NSH-
aware node by recording a unique value derived from the packet, for aware node by recording a unique value derived from the packet, such
example, a unique value from the MAC field value. Such an NSH-aware as a unique value from the MAC field value. Such an NSH-aware node
node will detect and reject duplicates. If for legitimate service will detect and reject duplicates. If for legitimate service reasons
reasons, some flows have to be duplicated but still share portion of some flows have to be duplicated but still share a portion of an SFP
an SFP with the original flow, legitimate duplicate packets will be with the original flow, legitimate duplicate packets will be tagged
tagged by NSH-aware nodes involved in that segment as replay packets by NSH-aware nodes involved in that segment as replay packets unless
unless sufficient entropy is added to the duplicate packet. How such sufficient entropy is added to the duplicate packet. How such an
an entropy is added is implementation-specific. entropy is added is implementation specific.
Note: Within the timestamp delta window, defining a sequence Note: Within the timestamp Delta window, defining a sequence
number to protect against replay attacks may be considered. In number to protect against replay attacks may be considered. In
such mode, NSH-aware nodes must discard packets with duplicate such a mode, NSH-aware nodes must discard packets with duplicate
sequence numbers within the timestamp delta window. However, in sequence numbers within the timestamp Delta window. However, in
deployments with several instances of the same SF (e.g., cluster deployments with several instances of the same SF (e.g., cluster
or load-balanced SFs), a mechanism to coordinate among those or load-balanced SFs), a mechanism to coordinate among those
instances to discard duplicate sequence numbers is required. instances to discard duplicate sequence numbers is required.
Because the coordination mechanism to comply with this requirement Because the coordination mechanism to comply with this requirement
is service-specific, this document does not include this is service specific, this document does not include this
protection. protection.
All SFC data plane elements must be synchronized among themselves. All SFC data plane elements must be synchronized among themselves.
These elements may be synchronized to a global reference time. These elements may be synchronized to a global reference time.
7.5. NSH Data Validation 7.5. NSH Data Validation
When an SFC data plane element that conforms to this specification 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 MUST ensure 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 NSH packet. The imposer MUST silently discard the packet and MUST
log an error at least once per the SPI if at least one of the log an error at least once per the SPI if at least one of the
following is observed: following is observed:
o the "MAC and Encrypted Metadata" Context Header is missing, * the "MAC and Encrypted Metadata" Context Header is missing,
o the enclosed key identifier is unknown or invalid (e.g., the * the enclosed key identifier is unknown or invalid (e.g., the
corresponding key expired), corresponding key expired), or
o the timestamp is invalid (Section 7.4). * the timestamp is invalid (Section 7.4).
If the timestamp check is successfully passed, the SFC data plane If the timestamp check is successfully passed, the SFC data plane
element proceeds with NSH data integrity validation. After storing element proceeds with NSH data integrity validation. After storing
the value of the MAC field in the "MAC and Encrypted Metadata" the value of the MAC field in the "MAC and Encrypted Metadata"
Context Header, the SFC data plane element fills the MAC field with Context Header, the SFC data plane element fills the MAC field with
zeros. Then, the SFC data plane element generates the message zeros. Then, the SFC data plane element generates the message
integrity for the target NSH data (depending on the integrity integrity for the target NSH data (depending on the integrity-
protection scope discussed in Section 5) using MAC_KEY and HMAC protection scope discussed in Section 5) using the MAC_KEY and HMAC
algorithm. If the value of the newly generated digest is identical algorithm. If the value of the newly generated digest is identical
to the stored one, the SFC data plane element is certain that the NSH to the stored one, the SFC data plane element is certain that the NSH
data has not been tampered and validation is therefore successful. data has not been tampered with and validation is therefore
Otherwise, the NSH packet MUST be discarded. The comparison of the successful. Otherwise, the NSH packet MUST be discarded. The
computed HMAC value to the stored value MUST be done in a constant- comparison of the computed HMAC value to the stored value MUST be
time manner to thwart timing attacks. done in a constant-time manner to thwart timing attacks.
7.6. Decryption of NSH Metadata 7.6. Decryption of NSH Metadata
If entitled to consume a supplied encrypted Context Header, an NSH- If entitled to consume a supplied encrypted Context Header, an NSH-
aware SF or SFC Proxy decrypts metadata using (K) and decryption aware SF or SFC Proxy decrypts metadata using (K) and a decryption
algorithm for the key identifier in the NSH. algorithm for the key identifier in the NSH.
Authenticated encryption algorithm has only a single output, either a The authenticated encryption algorithm has only a single output,
plaintext or a special symbol (FAIL) that indicates that the inputs either a plaintext or a special symbol (FAIL) that indicates that the
are not authentic (Section 2.2 of [RFC5116]). inputs are not authentic (Section 2.2 of [RFC5116]).
8. MTU Considerations 8. MTU Considerations
The SFC architecture prescribes that additional information be added The SFC architecture prescribes that additional information be added
to packets to: to packets to:
o Identify SFPs: this is typically the NSH Base Header and Service * Identify SFPs: this is typically the NSH Base Header and Service
Path Header. Path Header.
o Carry metadata such as those defined in Section 5. * Carry metadata such as that defined in Section 5.
o Steer the traffic along the SFPs: transport encapsulation. * Steer the traffic along the SFPs: This is realized by means of
transport encapsulation.
This added information increases the size of the packet to be carried This added information increases the size of the packet to be carried
along an SFP. along an SFP.
Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network Aligned with Section 5 of [RFC8300], it is RECOMMENDED that network
operators to increase the underlying MTU so that NSH traffic is operators increase the underlying MTU so that NSH traffic is
forwarded within an SFC-enabled domain without fragmentation. The forwarded within an SFC-enabled domain without fragmentation. The
available underlying MTU should be taken into account by network available underlying MTU should be taken into account by network
operators when providing SFs with the required Context Headers to be operators when providing SFs with the required Context Headers to be
injected per SFP and the size of the data to be carried in these injected per SFP and the size of the data to be carried in these
Context Headers. Context Headers.
If the underlying MTU cannot be increased to accommodate the NSH 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 activating such features on SFFs should be carefully assessed by
network operators (Section 5.6 of [RFC7665]). network operators (Section 5.6 of [RFC7665]).
When dealing with MTU issues, network operators should consider the 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
[I-D.ietf-intarea-tunnels]. [INTERNET-IP-TUNNELS].
9. Security Considerations 9. Security Considerations
Data plane SFC-related security considerations, including privacy, Data plane SFC-related security considerations, including privacy,
are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300].
In particular, Section 8.2.2 of [RFC8300] states that attached In particular, Section 8.2.2 of [RFC8300] states that attached
metadata (i.e., Context Headers) should be limited to that necessary metadata (i.e., Context Headers) should be limited to that which is
for correct operation of the SFP. Also, that section indicates that necessary for correct operation of the SFP. Also, that section
[RFC8165] discusses metadata considerations that operators can take indicates that [RFC8165] discusses metadata considerations that
into account when using NSH. operators can take into account when using NSH.
The guidelines for cryptographic key management are discussed in The guidelines for cryptographic key management are discussed in
[RFC4107]. The group key management protocol related security [RFC4107]. The group key management protocol-related security
considerations discussed in Section 8 of [RFC4046] needs to be taken considerations discussed in Section 8 of [RFC4046] need to be taken
into consideration. into consideration.
The interaction between the SFC data plane elements and a key The interaction between the SFC data plane elements and a key
management system MUST NOT be transmitted in clear since this would management system MUST NOT be transmitted unencrypted since this
completely destroy the security benefits of the integrity protection would completely destroy the security benefits of the integrity-
solution defined in this document. protection solution defined in this document.
The secret key (K) must have an expiration time assigned as the 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 protection of NSH data and encryption of Context Headers. Prior to
the expiration of the secret key, all participating NSH-aware nodes the expiration of the secret key, all participating NSH-aware nodes
SHOULD have the control plane distribute a new key identifier and SHOULD have the control plane distribute a new key identifier and
associated keying material so that when the secret key is expired, associated keying material so that when the secret key is expired,
those nodes are prepared with the new secret key. This allows the those nodes are prepared with the new secret key. This allows the
NSH imposer to switch to the new key identifier as soon as necessary. NSH imposer to switch to the new key identifier as soon as necessary.
It is RECOMMENDED that the next key identifier and associated keying It is RECOMMENDED that the next key identifier and associated keying
material be distributed by the control plane well prior to the secret material be distributed by the control plane well prior to the secret
key expiration time. Additional guidance for users of AEAD functions key expiration time. Additional guidance for users of AEAD functions
about rekeying can be found in [I-D.irtf-cfrg-aead-limits]. about rekeying can be found in [AEAD-LIMITS].
The security and integrity of the key-distribution mechanism is vital The security and integrity of the key-distribution mechanism is vital
to the security of the SFC system as a whole. to the security of the SFC system as a whole.
NSH data are exposed to several threats: NSH data is exposed to several threats:
o A on-path attacker modifying the NSH data. * An on-path attacker modifying the NSH data.
o Attacker spoofing the NSH data. * An attacker spoofing the NSH data.
o Attacker capturing and replaying the NSH data. * An attacker capturing and replaying the NSH data.
o Data carried in Context Headers revealing privacy-sensitive * Data carried in Context Headers revealing privacy-sensitive
information to attackers. information to attackers.
o Attacker replacing the packet on which the NSH is imposed with a * An attacker replacing the packet on which the NSH is imposed with
modified or bogus packet. a modified or bogus packet.
In an SFC-enabled domain where the above attacks are possible, (1) 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 MUST be integrity protected and replay protected, and (2)
privacy-sensitive NSH metadata MUST be encrypted for confidentiality privacy-sensitive NSH metadata MUST be encrypted for confidentiality
preservation purposes. The Base and Service Path headers are not preservation purposes. The Base and Service Path Headers are not
encrypted. encrypted.
MACs with two levels of assurance are defined in Section 5. MACs with two levels of assurance are defined in Section 5.
Considerations specific to each level of assurance are discussed in Considerations specific to each level of assurance are discussed in
Sections 9.1 and 9.2. Sections 9.1 and 9.2.
The attacks discussed in [I-D.nguyen-sfc-security-architecture] are The attacks discussed in [ARCH-SFC-THREATS] are handled based on the
handled owing to the solution specified in this document, except for solution specified in this document, with the exception of attacks
attacks dropping packets. Such attacks can be detected relying upon dropping packets. Such attacks can be detected by relying upon
statistical analysis; such analysis is out of the scope of this statistical analysis; such analysis is out of the scope of this
document. Also, if SFFs are not involved in the integrity checks, a document. Also, if SFFs are not involved in the integrity checks, a
misbehaving SFF which decrements SI while this should be done by an misbehaving SFF that decrements SI while this should be done by an SF
SF (SF bypass attack) will be detected by an upstream SF because the (SF bypass attack) will be detected by an upstream SF because the
integrity check will fail. integrity check will fail.
Some events are logged locally with notification alerts sent by NSH- Some events are logged locally with notification alerts sent by NSH-
aware nodes to a Control Element. These events SHOULD be rate- aware nodes to a Control Element. These events SHOULD be rate
limited. limited.
The solution specified in this document does not provide data origin The solution specified in this document does not provide data origin
authentication. authentication.
In order to detect compromised nodes, it is assumed that appropriate 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 misbehavior and to deter misuse are in place. Compromised nodes can
thus be withdrawn from active service function chains using thus be withdrawn from active service function chains using
appropriate control plane mechanisms. appropriate control plane mechanisms.
9.1. MAC#1 9.1. MAC#1
An active attacker can potentially modify the Base header (e.g., An active attacker can potentially modify the Base Header (e.g.,
decrement the TTL so the next SFF in the SFP discards the NSH decrement the TTL so the next SFF in the SFP discards the NSH
packet). An active attacker can typically also drop NSH packets. As packet). An active attacker can typically also drop NSH packets. As
such, this attack is not considered an attack against the security such, this attack is not considered an attack against the security
mechanism specified in the document. mechanism specified in the document.
It is expected that specific devices in the SFC-enabled domain will 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 (Section 7.1), and able to update the integrity-protected NSH data (Section 7.1), and no
also such that no device other than the NSH-aware SFs and SFC proxies device other than the NSH-aware SFs and SFC proxies will be able to
will be able to decrypt and update the Context Headers carrying decrypt and update the Context Headers carrying sensitive metadata
sensitive metadata (Section 7.1). In other words, if the NSH-aware (Section 7.1). In other words, it is expected that the NSH-aware SFs
SFs and SFC proxies in the SFC-enabled domain are considered fully and SFC proxies in the SFC-enabled domain are considered fully
trusted to act on the NSH data. Only these elements can have access trusted to act on the NSH data. Only these elements can have access
to sensitive NSH metadata and the keying material used to integrity to sensitive NSH metadata and the keying material used to integrity
protect NSH data and encrypt Context Headers. protect NSH data and encrypt Context Headers.
9.2. MAC#2 9.2. MAC#2
SFFs can detect whether an illegitimate node has altered the content SFFs can detect whether an illegitimate node has altered the content
of the Base header. Such messages must be discarded with appropriate of the Base Header. Such messages must be discarded with appropriate
logs and alarms generated (see Section 7.1). logs and alarms generated (see Section 7.1).
Similar to Section 9.1, no device other than the NSH-aware SFs and Similar to Section 9.1, no device other than the NSH-aware SFs and
SFC proxies in the SFC-enabled domain should be able to decrypt and SFC proxies in the SFC-enabled domain should be able to decrypt and
update the Context Headers carrying sensitive metadata. update the Context Headers carrying sensitive metadata.
9.3. Time Synchronization 9.3. Time Synchronization
[RFC8633] describes best current practices to be considered in [RFC8633] describes best current practices to be considered in
deployments where SFC data plane elements use NTP for time deployments where SFC data plane elements use NTP for time-
synchronization purposes. synchronization purposes.
Also, a mechanism to provide cryptographic security for NTP is Also, a mechanism to provide cryptographic security for NTP is
specified in [RFC8915]. specified in [RFC8915].
10. IANA Considerations 10. IANA Considerations
This document requests IANA to assign the following types from the IANA has added the following types to the "NSH IETF-Assigned Optional
"NSH IETF-Assigned Optional Variable-Length Metadata Types" (0x0000 Variable-Length Metadata Types" registry (0x0000 IETF Base NSH MD
IETF Base NSH MD Class) registry available at: Class) at <https://www.iana.org/assignments/nsh>.
https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-
length-metadata-types.
+-------+-------------------------------+----------------+
| Value | Description | Reference |
+=======+===============================+================+
| TBD1 | MAC and Encrypted Metadata #1 | [ThisDocument] |
| TBD2 | MAC and Encrypted Metadata #2 | [ThisDocument] |
+-------+-------------------------------+----------------+
11. Acknowledgements
This document was edited as a follow-up to the discussion in
IETF#104: https://datatracker.ietf.org/meeting/104/materials/slides-
104-sfc-sfc-chair-slides-01 (slide 7).
Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal
Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody
for the comments.
Many thanks to Steve Hanna for the valuable secdir review and Juergen
Schoenwaelder for the opsdir review.
Thanks to Greg Mirsky for the Shepherd review. +=======+===============================+===========+
| Value | Description | Reference |
+=======+===============================+===========+
| 0x02 | MAC and Encrypted Metadata #1 | RFC 9145 |
+-------+-------------------------------+-----------+
| 0x03 | MAC and Encrypted Metadata #2 | RFC 9145 |
+-------+-------------------------------+-----------+
Thanks to Alvaro Retana, Lars Eggert, Martin Duke, Erik Kline, Table 4: Additions to the NSH IETF-Assigned
Zaheduzzaman Sarker, Eric Vyncke, Roman Danyliw, Murray Kucherawy, Optional Variable-Length Metadata Types Registry
John Scudder, and Benjamin Kaduk for the IESG review.
12. References 11. References
12.1. Normative References 11.1. Normative References
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", Operation: Galois/Counter Mode (GCM) and GMAC",
NIST Special Publication 800-38D, November 2007. NIST Special Publication 800-38D,
DOI 10.6028/NIST.SP.800-38D, November 2007,
<https://doi.org/10.6028/NIST.SP.800-38D>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 28, line 28 skipping to change at line 1242
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
12.2. Informative References 11.2. Informative References
[I-D.arkko-farrell-arch-model-t] [AEAD-LIMITS]
Arkko, J. and S. Farrell, "Challenges and Changes in the Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
Internet Threat Model", draft-arkko-farrell-arch-model- AEAD Algorithms", Work in Progress, Internet-Draft, draft-
t-04 (work in progress), July 2020. irtf-cfrg-aead-limits-03, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aead-limits-03>.
[I-D.ietf-intarea-tunnels] [ARCH-SFC-THREATS]
Touch, J. and M. Townsley, "IP Tunnels in the Internet THANG, N. C. and M. Park, "A Security Architecture Against
Architecture", draft-ietf-intarea-tunnels-10 (work in Service Function Chaining Threats", Work in Progress,
progress), September 2019. Internet-Draft, draft-nguyen-sfc-security-architecture-00,
24 November 2019, <https://datatracker.ietf.org/doc/html/
draft-nguyen-sfc-security-architecture-00>.
[I-D.irtf-cfrg-aead-limits] [INTERNET-IP-TUNNELS]
Guenther, F., Thomson, M., and C. A. Wood, "Usage Limits Touch, J. and M. Townsley, "IP Tunnels in the Internet
on AEAD Algorithms", draft-irtf-cfrg-aead-limits-03 (work Architecture", Work in Progress, Internet-Draft, draft-
in progress), July 2021. ietf-intarea-tunnels-10, 12 September 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-10>.
[I-D.nguyen-sfc-security-architecture] [INTERNET-THREAT-MODEL]
THANG, N. C. and M. Park, "A Security Architecture Against Arkko, J. and S. Farrell, "Challenges and Changes in the
Service Function Chaining Threats", draft-nguyen-sfc- Internet Threat Model", Work in Progress, Internet-Draft,
security-architecture-00 (work in progress), November draft-arkko-farrell-arch-model-t-04, 13 July 2020,
2019. <https://datatracker.ietf.org/doc/html/draft-arkko-
farrell-arch-model-t-04>.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management "Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
<https://www.rfc-editor.org/info/rfc4046>. <https://www.rfc-editor.org/info/rfc4046>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
skipping to change at page 30, line 15 skipping to change at line 1327
[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for [RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", RFC 8877, Defining Packet Timestamps", RFC 8877,
DOI 10.17487/RFC8877, September 2020, DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/info/rfc8877>. <https://www.rfc-editor.org/info/rfc8877>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>. <https://www.rfc-editor.org/info/rfc8915>.
Acknowledgements
This document was created as a follow-up to the discussion in IETF
104: <https://datatracker.ietf.org/meeting/104/materials/slides-104-
sfc-sfc-chair-slides-01> (slide 7).
Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal
Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody
for the comments.
Many thanks to Steve Hanna for the valuable secdir review and Juergen
Schoenwaelder for the opsdir review.
Thanks to Greg Mirsky for the Shepherd review.
Thanks to Alvaro Retana, Lars Eggert, Martin Duke, Erik Kline,
Zaheduzzaman Sarker, Éric Vyncke, Roman Danyliw, Murray Kucherawy,
John Scudder, and Benjamin Kaduk for the IESG review.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy Tirumaleswar Reddy.K
Akamai Akamai
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore 560071
Karnataka
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Dan Wing Dan Wing
Citrix Systems, Inc. Citrix Systems, Inc.
USA United States of America
Email: dwing-ietf@fuggles.com Email: dwing-ietf@fuggles.com
 End of changes. 172 change blocks. 
405 lines changed or deleted 424 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/