Orange

Rennes 35000 France mohamed.boucadair@orange.com

Akamai

Embassy Golf Link Business Park Bangalore Karnataka 560071 India kondtir@gmail.com

Citrix Systems, Inc.

USA dwing-ietf@fuggles.com

SFC Security Resilience Automation Service delivery Providers Differentiated services Traffic Engineering Attack mitigation This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows for the encryption of sensitive metadata (MD) that is carried in the NSH.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Terminology
• .  Assumptions and Basic Requirements
• .  Design Overview
  • .  Supported Security Services
    • .  Encrypt All or a Subset of Context Headers
    • .  Integrity Protection
  • .  One Secret Key, Two Security Services
  • .  Mandatory-to-Implement Authenticated Encryption and HMAC Algorithms
  • .  Key Management
  • .  New NSH Variable-Length Context Headers
  • .  Encapsulation of NSH within NSH
• .  New NSH Variable-Length Context Headers
  • .  MAC#1 Context Header
  • .  MAC#2 Context Header
• .  Timestamp Format
• .  Processing Rules
  • .  Generic Behavior
  • .  MAC NSH Data Generation
  • .  Encrypted NSH Metadata Generation
  • .  Timestamp for Replay Attack Prevention
  • .  NSH Data Validation
  • .  Decryption of NSH Metadata
• .  MTU Considerations
• .  Security Considerations
  • .  MAC#1
  • .  MAC#2
  • .  Time Synchronization
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction Many advanced Service Functions (SFs) are enabled for the delivery of value-added services. Typically, SFs are used to meet various service objectives such as IP address sharing, avoiding covert channels, detecting Denial-of-Service (DoS) attacks and protecting network infrastructures against them, network slicing, etc. Because of the proliferation of such advanced SFs together with complex service deployment constraints that demand more agile service delivery procedures, operators need to rationalize their service delivery logic and control its complexity while optimizing service activation time cycles. The overall problem space is described in . presents a data plane architecture addressing the problematic aspects of existing service deployments, including topological dependence and configuration complexity. It also describes an architecture for the specification, creation, and maintenance of Service Function Chains (SFCs) within a network, that is, how to define an ordered set of SFs and ordering constraints that must be applied to packets/flows selected as a result of traffic classification. specifies the SFC encapsulation: Network Service Header (NSH). The NSH data is unauthenticated and unencrypted, forcing a service topology that requires security and privacy to use a transport encapsulation that supports such features (). Note that some transport encapsulations (e.g., IPsec) only provide hop-by-hop security between two SFC data plane elements (e.g., two Service Function Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF security of NSH metadata. For example, if IPsec is used, SFFs or SFs within a Service Function Path (SFP) that are not authorized to access the sensitive metadata (e.g., privacy-sensitive information) will have access to the metadata. As a reminder, the metadata referred to is information that is inserted by Classifiers or intermediate SFs and shared with downstream SFs; such information is not visible to the communication endpoints (). The lack of such capability was reported during the development of and . The reader may refer to for a discussion on the need for more awareness about attacks from within closed domains. This specification fills that gap for SFC (that is, it defines the "NSH Variable Header-Based Integrity" option mentioned in ). Concretely, this document adds integrity protection and optional encryption of sensitive metadata directly to the NSH (). The integrity protection covers the packet payload and provides replay protection (). Thus, the NSH does not have to rely upon an underlying transport encapsulation for security. This specification introduces new Variable-Length Context Headers to carry fields necessary for integrity-protected NSH headers and encrypted Context Headers (). This specification is only applicable to NSH MD Type 0x02 (). MTU considerations are discussed in . This specification is not applicable to NSH MD Type 0x01 () because 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 message integrity of the NSH data. This specification limits access to NSH-supplied information along an SFP to entities that have a need to interpret it. The mechanism specified in this document does not preclude the use of transport security. Such considerations are deployment specific. It is out of the scope of this document to specify an NSH-aware control plane solution.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in and . The term "transport encapsulation" used in this document refers to the outer encapsulation (e.g., Generic Routing Encapsulation (GRE), IPsec, and Generic Protocol Extension for Virtual eXtensible Local Area Network (VXLAN-GPE)) that is used to carry NSH-encapsulated packets as per . The document defines the following terms:

SFC data plane element:

Refers to NSH-aware SF, SFF, the SFC Proxy, or the Classifier as defined in the SFC data plane architecture and further refined in .

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-enabled domain.

Key Identifier:

Is used to identify keys to authorized entities. See, for example, "kid" usage in .

NSH data:

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

NSH imposer:

Refers to an SFC data plane element that is entitled to impose the NSH with the Context Headers defined in this document.

Assumptions and Basic Requirements specifies that the NSH data can be spread over three headers:

Base Header:

Provides information about the service header and the payload protocol.

Service Path Header:

Provides path identification and location within an SFP.

Context Header(s):

Carries metadata (i.e., context data) along a service path.

The NSH allows sharing context information (a.k.a. metadata) with downstream NSH-aware data plane elements on a per-SFC/SFP basis. To that aim:

• The Classifier is instructed by an SFC control element about the set of context information to be supplied for a given service function chain.
• An NSH-aware SF is instructed by an SFC control element about any metadata it needs to attach to packets for a given service function chain. This instruction may occur any time during the validity lifetime of an SFC/SFP. For a given service function chain, the NSH-aware SF is also provided with an order for consuming a set of contexts supplied in a packet.
• An NSH-aware SF can also be instructed by an SFC control element about the behavior it should adopt after consuming context information that was supplied in the NSH. For example, the context information can be maintained, updated, or stripped.
• An SFC Proxy may be instructed by an SFC control element about the behavior it should adopt to process the context information that was supplied in the NSH on behalf of an NSH-unaware SF (e.g., the context information can be maintained or stripped). The SFC Proxy may also be instructed to add some new context information into the NSH on behalf of an NSH-unaware SF.

In reference to :

• Classifiers, NSH-aware SFs, and SFC proxies are entitled to update the Context Header(s).
• Only NSH-aware SFs and SFC proxies are entitled to update the Service Path Header.
• SFFs are entitled to modify the Base Header (TTL value, for example). Nevertheless, SFFs are not supposed to act on the Context Headers or look into the content of the Context Headers ().

Thus, the following requirements:

• Only Classifiers, NSH-aware SFs, and SFC proxies must be able to encrypt and decrypt a given Context Header.
• Both encrypted and unencrypted Context Headers may be included in the same NSH.
• The solution must provide integrity protection for the Service Path Header.
• The solution must provide optional integrity protection for the Base Header. The implications of disabling such checks are discussed in .

Summary of NSH Actions

SFC Data Plane Element	Insert, remove, or replace the NSH			Update the NSH
	Insert	Remove	Replace	Decrement Service Index	Update Context Header(s)
Classifier	+		+		+
Service Function Forwarder (SFF)		+
Service Function (SF)				+	+
Service Function Chaining (SFC) Proxy	+	+		+	+

Design Overview

Supported Security Services This specification provides the functions described in the following subsections.

Encrypt All or a Subset of Context Headers The solution allows encrypting all or a subset of NSH Context Headers by Classifiers, NSH-aware SFs, and SFC proxies. As depicted in , SFFs are not involved in data encryption. Encryption Function Supported by SFC Data Plane Elements

Data Plane Element	Base and Service Path Headers Encryption	Context Header Encryption
Classifier	No	Yes
SFF	No	No
NSH-aware SF	No	Yes
SFC Proxy	No	Yes
NSH-unaware SF	No	No

Classifier(s), NSH-aware SFs, and SFC proxies are instructed with the set of Context Headers (privacy-sensitive metadata, typically) that must be encrypted. Encryption keying material is only provided to these SFC data plane elements. The control plane may indicate the set of SFC data plane elements that are entitled to supply a given Context Header (e.g., in reference to their identifiers as assigned within the SFC-enabled domain). It is out of the scope of this document to elaborate on how such instructions are provided to the appropriate SFC data plane elements nor to detail the structure used to store the instructions. The Service Path Header () is not encrypted because SFFs use the Service Index (SI) in conjunction with the Service Path Identifier (SPI) for determining the next SF in the path.

Integrity Protection The solution provides integrity protection for the NSH data. Two levels of assurance (LoAs) are supported. The first level of assurance is where all NSH data except the Base Header are integrity protected (). In this case, the NSH imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. SFFs are not provided with authentication material. Further details are discussed in .

First Level of Assurance +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | Base Header | | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | | Service Path Header | S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | | Context Header(s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | | Original Packet | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +------Scope of integrity-protected data

The second level of assurance is where all NSH data, including the Base Header, are integrity protected (). In this case, the NSH imposer may be a Classifier, an NSH-aware SF, an SFF, or an SFC Proxy. Further details are provided in .

Second Level of Assurance +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Encapsulation | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | | Base Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | | Service Path Header | S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | | Context Header(s) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | | Original Packet | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +----Scope of integrity-protected data

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 (). In both levels of assurance, the Context Headers and the packet on which the NSH is imposed are subject to integrity protection. classifies the data plane elements as being involved or not involved in providing integrity protection for the NSH. Integrity Protection Supported by SFC Data Plane Elements

Data Plane Element	Integrity Protection
Classifier	Yes
SFF	No (first LoA); Yes (second LoA)
NSH-aware SF	Yes
SFC Proxy	Yes
NSH-unaware SF	No

One Secret Key, Two Security Services The Authenticated Encryption with Associated Data (AEAD) interface defined in is used to encrypt the Context Headers that carry sensitive metadata and to provide integrity protection for the encrypted Context Headers. The secondary keys "MAC_KEY" and "ENC_KEY" are generated from the 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. The MAC_KEY is used for calculating the message integrity of the NSH data. In other words, the integrity protection provided by the cryptographic mechanism is extended to also provide protection for the unencrypted Context Headers and the packet on which the NSH is imposed.

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 Context Headers.

The Hashed Message Authentication Code (HMAC) algorithm discussed in is used to protect the integrity of the NSH data. The algorithm for implementing and validating HMACs is provided in . The advantage of using both AEAD and HMAC algorithms (instead of just AEAD) is that NSH-aware SFs and SFC proxies only need to recompute the message integrity of the NSH data after decrementing the SI and do not have to recompute the ciphertext. The other advantage is that SFFs do not have access to the ENC_KEY and cannot act on the encrypted Context Headers, and (in the case of the second level of assurance) SFFs do have access to the MAC_KEY. Similarly, an NSH-aware SF or SFC Proxy not allowed to decrypt the Context Headers will not have access to the ENC_KEY. The authenticated encryption algorithm or HMAC algorithm to be used by SFC data plane elements is typically controlled using the SFC control plane. Mandatory-to-implement authenticated encryption and HMAC algorithms are listed in . The authenticated encryption process takes four inputs, each of which is an octet string: a secret key (ENC_KEY, referred to as "K" in ), a plaintext (P), associated data (A) (which contains the data to be authenticated but not encrypted), and a nonce (N). A ciphertext (C) is generated as an output as discussed in . In order to decrypt and verify, the cipher takes ENC_KEY, N, A, and C as input. The output is either the plaintext or an error indicating that the decryption failed as described in .

Mandatory-to-Implement Authenticated Encryption and HMAC Algorithms Classifiers, NSH-aware SFs, and SFC proxies MUST implement the AES_128_GCM algorithm and SHOULD implement the AES_192_GCM and AES_256_GCM algorithms. Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC-SHA-256-128 algorithm and SHOULD implement the HMAC-SHA-384-192 and HMAC-SHA-512-256 algorithms. SFFs MAY implement the aforementioned cipher suites and HMAC algorithms. Note: The use of the AES_128_CBC_HMAC_SHA_256 algorithm would have avoided the need for a second 128-bit authentication tag, but due to the nature of how Cipher Block Chaining (CBC) mode operates, AES_128_CBC_HMAC_SHA_256 allows for the malleability of plaintexts. This malleability allows for attackers that know the Message Authentication Code (MAC) key but not the encryption key to make changes in the ciphertext and, if parts of the plaintext are known, create arbitrary blocks of plaintext. This specification mandates the use of separate AEAD and MAC protections to prevent this type of attack.

Key Management The procedure for the allocation/provisioning of secret keys (K) and the authenticated encryption algorithm or MAC_KEY and HMAC algorithm is outside the scope of this specification. As such, this specification does not mandate the support of any specific mechanism. The document does not assume nor preclude the following:

• The same keying material is used for all the service functions used within an SFC-enabled domain.
• Distinct keying material is used per SFP by all involved SFC data path elements.
• Per-tenant keys are used.

In order to accommodate deployments relying upon keying material per SFC/SFP and also the need to update keys after encrypting NSH data for a certain amount of time, this document uses key identifiers to unambiguously identify the appropriate keying material and associated algorithms for MAC and encryption. This use of in-band identifiers addresses the problem of the synchronization of keying material. Additional information on manual vs. automated key management and when one should be used over the other can be found in . The risk involved in using a group-shared symmetric key increases with the size of the group to which it is shared. Additional security issues are discussed in .

New NSH Variable-Length Context Headers New NSH Variable-Length Context Headers are defined in for NSH data integrity protection and, optionally, encryption of Context Headers carrying sensitive metadata. Concretely, an NSH imposer includes (1) the key identifier to identify the keying material, (2) the timestamp to protect against replay attacks (), and (3) MAC for the target NSH data (depending on the integrity-protection scope) calculated using MAC_KEY and, optionally, Context Headers encrypted using ENC_KEY. An SFC data plane element that needs to check the integrity of the NSH data uses the MAC_KEY and HMAC algorithm for the key identifier being carried in the NSH. An NSH-aware SF or SFC Proxy that needs to decrypt some Context Headers uses ENC_KEY and the decryption algorithm for the key identifier being carried in the NSH. specifies the detailed procedure.

Encapsulation of NSH within NSH As discussed in , an SFC-enabled domain (called an upper-level domain) may be decomposed into many sub-domains (called lower-level domains). In order to avoid maintaining state to restore upper-level NSH information at the boundaries of lower-level domains, two NSH levels are used: an Upper-NSH that is imposed at the boundaries of the upper-level domain and a Lower-NSH that is pushed by the Classifier of a lower-level domain in front of the original NSH (). As such, the Upper-NSH information is carried along the lower-level chain without modification. The packet is forwarded in the top-level domain according to the Upper-NSH, while it is forwarded according to the Lower-NSH in a lower-level domain.

Encapsulation of NSH within NSH +---------------------------------+ | Transport Encapsulation | +->+---------------------------------+ | | Lower-NSH Header | | +---------------------------------+ | | Upper-NSH Header | | +---------------------------------+ | | Original Packet | +->+---------------------------------+ | | +----Scope of NSH security protection provided by a lower-level domain

SFC data plane elements of a lower-level domain include the Upper-NSH when computing the MAC. Keying material used at the upper-level domain SHOULD NOT be the same as the one used by a lower-level domain.

New NSH Variable-Length Context Headers This section specifies the format of new Variable-Length Context Headers that are used for NSH integrity protection and, optionally, Context Header encryption. In particular, this section defines two "MAC and Encrypted Metadata" Context Headers, each having specific deployment constraints. Unlike , the level of assurance provided in requires sharing MAC_KEY with SFFs. Both Context Headers have the same format as shown in .

MAC and Encrypted Metadata Context Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class | Type |U| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Id Len | Key Identifier (Variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Timestamp (8 bytes) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce Length | Nonce (Variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code and optional Encrypted | ~ Context Headers (Variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "MAC and Encrypted Metadata" Context Headers are padded out to a multiple of 4 bytes as per . The "MAC and Encrypted Metadata" Context Header, if included, MUST always be the last Context Header.

MAC#1 Context Header The MAC#1 Context Header is a Variable-Length Context Header that carries MAC for the Service Path Header, Context Headers, and the inner packet on which NSH is imposed, calculated using MAC_KEY and, optionally, Context Headers encrypted using ENC_KEY. The scope of the integrity protection provided by this Context Header is depicted in . This MAC scheme does not require sharing MAC_KEY with SFFs. It does not require recomputing the MAC by each SFF because of TTL processing. discusses the possible threat associated with this level of assurance.

Scope of MAC#1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ | Service Path Identifier | Service Index | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Variable-Length Unencrypted Context Headers (opt.) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Metadata Class | Type |U| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Key Id Len | Key Identifier (Variable) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Timestamp (8 bytes) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Nonce Length | Nonce (Variable) ~ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Encrypted Context Headers (opt.) ~ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Authentication Code ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | ~ Inner Packet on which NSH is imposed ~ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| | | | Integrity-Protection Scope ----+ +----Encrypted Data

In reference to , the description of the fields is as follows:

Metadata Class:

MUST be set to 0x0 ().

Type:

0x02 (see ).

U:

Unassigned bit ().

Length:

Indicates the length of the variable-length metadata in bytes. Padding considerations are discussed in .

Key Id Len:

Variable. Carries the length of the key identifier in octets.

Key Identifier:

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

Timestamp:

Refer to for more details about the structure of this field.

Nonce Length:

Carries the length of the Nonce. If the Context Headers are only integrity protected, "Nonce Length" is set to zero (that is, no "Nonce" is included).

Nonce:

Carries the Nonce for the authenticated encryption operation ().

Encrypted Context Headers:

Carries the optional encrypted Context Headers.

Message Authentication Code:

Covers the entire NSH data, excluding the Base Header.

MAC#2 Context Header The MAC#2 Context Header is a Variable-Length Context Header that carries the MAC for the entire NSH data calculated using MAC_KEY and, optionally, Context Headers encrypted using ENC_KEY. The scope of the integrity protection provided by this Context Header is depicted in .

Scope of MAC#2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--+ |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Service Path Identifier | Service Index | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Variable-Length Unencrypted Context Headers (opt.) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Metadata Class | Type |U| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Key Id Len | Key Identifier (Variable) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Timestamp (8 bytes) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Nonce Length | Nonce (Variable) ~ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Encrypted Context Headers (opt.) ~ | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Authentication Code ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | ~ Inner Packet on which NSH is imposed ~ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--| | | | Integrity-Protection Scope ----+ +----Encrypted Data

In reference to , the description of the fields is as follows:

Metadata Class:

MUST be set to 0x0 ().

Type:

0x03 (see ).

U:

Unassigned bit ().

Length:

Indicates the length of the variable-length metadata in bytes. Padding considerations are discussed in .

Key Id Len:

See .

Key Identifier:

See .

Timestamp:

See .

Nonce Length:

See .

Nonce:

See .

Encrypted Context Headers:

Carries the optional encrypted Context Headers.

Message Authentication Code:

Covers the entire NSH data.

Timestamp Format This section follows the template provided in . The format of the Timestamp field introduced in is depicted in .

Timestamp Field Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Timestamp field format:

Seconds:

Specifies the integer portion of the number of seconds since the epoch.

+ Size:

32 bits

+ Units:

Seconds

Fraction:

Specifies the fractional portion of the number of seconds since the epoch.

+ Size:

32 bits

+ Units:

The unit is 2^(-32) seconds, which is roughly equal to 233 picoseconds.

Epoch:

The epoch is 1970-01-01T00:00 in UTC time. Note that this epoch value is different from the one used in (which will wrap around in 2036).

Leap seconds:

This timestamp format is affected by leap seconds. The timestamp represents the number of seconds elapsed since the epoch minus the number of leap seconds.

Resolution:

The resolution is 2^(-32) seconds.

Wraparound:

This time format wraps around every 2³² seconds, which is roughly 136 years. The next wraparound will occur in the year 2106.

Synchronization aspects:

It is assumed that SFC data plane elements are synchronized to UTC using a synchronization mechanism that is outside the scope of this document. In typical deployments, SFC data plane elements use NTP for synchronization. Thus, the timestamp may be derived from the NTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of an NTP server. Since this time format is specified in terms of UTC, it is affected by leap seconds (in a manner analogous to the NTP time format, which is similar). Therefore, the value of a timestamp during or slightly after a leap second may be temporarily inaccurate.

Processing Rules The following subsections describe the processing rules for integrity-protected NSH and, optionally, encrypted Context Headers.

Generic Behavior This document adheres to the recommendations in for handling the Context Headers at both ingress and egress SFC boundary nodes (i.e., to strip the entire NSH, including Context Headers). Failures of a Classifier to inject the Context Headers defined in 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 validate the integrity of the NSH data MUST cause that packet to be discarded while a notification alarm MAY be sent to an SFC control element. The details of sending notification alarms (i.e., the parameters that affect the transmission of the notification alarms depending on the information in the Context Header such as frequency, thresholds, and content in the alarm) SHOULD be configurable. 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 next SF in the service function chain after processing the content of the Context Headers. If no instruction is provided, the default behavior for intermediary NSH-aware nodes is to maintain such Context Headers so that the information can be passed to the next NSH-aware hops. NSH-aware SFs and SFC proxies MUST reapply the integrity protection if any modification is made to the Context Headers (e.g., strip a Context Header, update the content of an existing Context Header, insert a new Context Header). 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. Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted Context Headers, for which it is not allowed to consume a specific Context Header it decrypts (but consumes others), MUST keep that Context Header unaltered when forwarding the packet upstream. Only one instance of a "MAC and Encrypted Metadata" Context Header () is allowed in an NSH level. If multiple instances of a "MAC and Encrypted Metadata" Context Header are included in an NSH level, the SFC data plane element MUST process the first instance and ignore subsequent instances and MAY log or increase a counter for this event as per . If NSH within NSH is used (), distinct LoAs may be used for each NSH level. MTU and fragmentation considerations are discussed in .

MAC NSH Data Generation After performing any Context Header encryption, the HMAC algorithm discussed in is used to integrity protect the target NSH data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context Header for integrity protection (). The NSH imposer sets the MAC field to zero and then computes the message integrity for the target NSH data (depending on the integrity-protection scope discussed in ) using the MAC_KEY and HMAC algorithm. It inserts the computed digest in the MAC field of the "MAC and Encrypted Metadata" Context Header. The length of the MAC is decided by the HMAC algorithm adopted for the particular key identifier. The Message Authentication Code (T) computation process for the target NSH data with HMAC-SHA-256-128() can be illustrated as follows: T = HMAC-SHA-256-128(MAC_KEY, target NSH data) An entity in the SFP that updates the NSH MUST follow the above behavior to maintain message integrity of the NSH for subsequent validations.

Encrypted NSH Metadata Generation An NSH imposer can encrypt Context Headers carrying sensitive metadata, i.e., encrypted and unencrypted metadata may be carried simultaneously in the same NSH packet (Sections and ). In order to prevent pervasive monitoring , it is RECOMMENDED to encrypt all Context Headers. All Context Headers carrying privacy-sensitive metadata MUST be encrypted; by doing so, privacy-sensitive metadata is not revealed to attackers. Privacy-specific threats are discussed in . Using the secret key (ENC_KEY) and authenticated encryption algorithm, the NSH imposer encrypts the Context Headers (as set, for example, in ) and inserts the resulting payload in the "MAC and Encrypted Metadata" Context Header (). The additional authenticated data input to the AEAD function is a zero-length byte string. The entire Context Header carrying sensitive metadata is encrypted (that is, including the MD Class, Type, Length, and associated metadata of each Context Header). More details about the exact encryption procedure are provided in . In this case, the associated data (A) input is zero length for AES Galois/Counter Mode (AES-GCM). An authorized entity in the SFP that updates the content of an encrypted Context Header or needs to add a new encrypted Context Header MUST also follow the aforementioned behavior.

Timestamp for Replay Attack Prevention The Timestamp imposed by an initial Classifier is left untouched along an SFP. However, it can be updated when reclassification occurs (). The same considerations for setting the Timestamp are followed in both initial classification and reclassification (). The received NSH is accepted by an NSH-aware node if the Timestamp (TS) in the NSH is recent enough to the reception time of the NSH (TSrt). The following formula is used for this check: -Delta < (TSrt - TS) < +Delta The Delta interval is a configurable parameter. The default value for the allowed Delta is 2 seconds. Special care should be taken when setting very low Delta values as this may lead to dropping legitimate traffic. If the timestamp is not within the boundaries, then the SFC data plane element receiving such packets MUST discard the NSH message. Replay attacks within the Delta window may be detected by an NSH-aware node by recording a unique value derived from the packet, such as a unique value from the MAC field value. Such an NSH-aware node will detect and reject duplicates. If for legitimate service reasons some flows have to be duplicated but still share a portion of an SFP with the original flow, legitimate duplicate packets will be tagged by NSH-aware nodes involved in that segment as replay packets unless sufficient entropy is added to the duplicate packet. How such an entropy is added is implementation specific. Note: Within the timestamp Delta window, defining a sequence number to protect against replay attacks may be considered. In such a mode, NSH-aware nodes must discard packets with duplicate sequence numbers within the timestamp Delta window. However, in deployments with several instances of the same SF (e.g., cluster or load-balanced SFs), a mechanism to coordinate among those instances to discard duplicate sequence numbers is required. Because the coordination mechanism to comply with this requirement is service specific, this document does not include this protection. All SFC data plane elements must be synchronized among themselves. These elements may be synchronized to a global reference time.

NSH Data Validation 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 "MAC and Encrypted Metadata" Context Header is included in a received 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 following is observed:

• the "MAC and Encrypted Metadata" Context Header is missing,
• the enclosed key identifier is unknown or invalid (e.g., the corresponding key expired), or
• the timestamp is invalid ().

If the timestamp check is successfully passed, the SFC data plane element proceeds with NSH data integrity validation. After storing the value of the MAC field in the "MAC and Encrypted Metadata" Context Header, the SFC data plane element fills the MAC field with zeros. Then, the SFC data plane element generates the message integrity for the target NSH data (depending on the integrity-protection scope discussed in ) using the MAC_KEY and HMAC algorithm. If the value of the newly generated digest is identical to the stored one, the SFC data plane element is certain that the NSH data has not been tampered with and validation is therefore successful. Otherwise, the NSH packet MUST be discarded. The comparison of the computed HMAC value to the stored value MUST be done in a constant-time manner to thwart timing attacks.

Decryption of NSH Metadata If entitled to consume a supplied encrypted Context Header, an NSH-aware SF or SFC Proxy decrypts metadata using (K) and a decryption algorithm for the key identifier in the NSH. The authenticated encryption algorithm has only a single output, either a plaintext or a special symbol (FAIL) that indicates that the inputs are not authentic ().

MTU Considerations The SFC architecture prescribes that additional information be added to packets to:

• Identify SFPs: this is typically the NSH Base Header and Service Path Header.
• Carry metadata such as that defined in .
• 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 along an SFP. Aligned with , it is RECOMMENDED that network operators increase the underlying MTU so that NSH traffic is forwarded within an SFC-enabled domain without fragmentation. The available underlying MTU should be taken into account by network operators when providing SFs with the required Context Headers to be injected per SFP and the size of the data to be carried in these Context Headers. If the underlying MTU cannot be increased to accommodate the NSH overhead, network operators may rely upon a transport encapsulation protocol with the required fragmentation handling. The impact of activating such features on SFFs should be carefully assessed by network operators (). When dealing with MTU issues, network operators should consider the limitations of various tunnel mechanisms such as those discussed in .

Security Considerations Data plane SFC-related security considerations, including privacy, are discussed in and . In particular, states that attached metadata (i.e., Context Headers) should be limited to that which is necessary for correct operation of the SFP. Also, that section indicates that discusses metadata considerations that operators can take into account when using NSH. The guidelines for cryptographic key management are discussed in . The group key management protocol-related security considerations discussed in need to be taken into consideration. The interaction between the SFC data plane elements and a key management system MUST NOT be transmitted unencrypted since this would completely destroy the security benefits of the integrity-protection solution defined in this document. The secret key (K) must have an expiration time assigned as the latest point in time before which the key may be used for integrity protection of NSH data and encryption of Context Headers. Prior to the expiration of the secret key, all participating NSH-aware nodes SHOULD have the control plane distribute a new key identifier and associated keying material so that when the secret key is expired, those nodes are prepared with the new secret key. This allows the NSH imposer to switch to the new key identifier as soon as necessary. It is RECOMMENDED that the next key identifier and associated keying material be distributed by the control plane well prior to the secret key expiration time. Additional guidance for users of AEAD functions about rekeying can be found in . The security and integrity of the key-distribution mechanism is vital to the security of the SFC system as a whole. NSH data is exposed to several threats:

• An on-path attacker modifying the NSH data.
• An attacker spoofing the NSH data.
• An attacker capturing and replaying the NSH data.
• Data carried in Context Headers revealing privacy-sensitive information to attackers.
• An attacker replacing the packet on which the NSH is imposed with a modified or bogus packet.

In an SFC-enabled domain where the above attacks are possible, (1) NSH data MUST be integrity protected and replay protected, and (2) privacy-sensitive NSH metadata MUST be encrypted for confidentiality preservation purposes. The Base and Service Path Headers are not encrypted. MACs with two levels of assurance are defined in . Considerations specific to each level of assurance are discussed in Sections and . The attacks discussed in are handled based on the solution specified in this document, with the exception of attacks dropping packets. Such attacks can be detected by relying upon statistical analysis; such analysis is out of the scope of this document. Also, if SFFs are not involved in the integrity checks, a misbehaving SFF that decrements SI while this should be done by an SF (SF bypass attack) will be detected by an upstream SF because the integrity check will fail. Some events are logged locally with notification alerts sent by NSH-aware nodes to a Control Element. These events SHOULD be rate limited. The solution specified in this document does not provide data origin authentication. In order to detect compromised nodes, it is assumed that appropriate mechanisms to monitor and audit an SFC-enabled domain to detect misbehavior and to deter misuse are in place. Compromised nodes can thus be withdrawn from active service function chains using appropriate control plane mechanisms.

MAC#1 An active attacker can potentially modify the Base Header (e.g., decrement the TTL so the next SFF in the SFP discards the NSH packet). An active attacker can typically also drop NSH packets. As such, this attack is not considered an attack against the security mechanism specified in the document. It is expected that specific devices in the SFC-enabled domain will be configured such that no device other than the Classifiers (when reclassification is enabled), NSH-aware SFs, and SFC proxies will be able to update the integrity-protected NSH data (), and no device other than the NSH-aware SFs and SFC proxies will be able to decrypt and update the Context Headers carrying sensitive metadata (). In other words, it is expected that the NSH-aware SFs and SFC proxies in the SFC-enabled domain are considered fully trusted to act on the NSH data. Only these elements can have access to sensitive NSH metadata and the keying material used to integrity protect NSH data and encrypt Context Headers.

MAC#2 SFFs can detect whether an illegitimate node has altered the content of the Base Header. Such messages must be discarded with appropriate logs and alarms generated (see ). Similar to , no device other than the NSH-aware SFs and SFC proxies in the SFC-enabled domain should be able to decrypt and update the Context Headers carrying sensitive metadata.

Time Synchronization describes best current practices to be considered in deployments where SFC data plane elements use NTP for time-synchronization purposes. Also, a mechanism to provide cryptographic security for NTP is specified in .

IANA Considerations IANA has added the following types to the "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry (0x0000 IETF Base NSH MD Class) at . Additions to the NSH IETF-Assigned Optional Variable-Length Metadata Types Registry

Value	Description	Reference
0x02	MAC and Encrypted Metadata #1	RFC 9145
0x03	MAC and Encrypted Metadata #2	RFC 9145

References Normative References This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK] This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665). Informative References ETH Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. Work in Progress Department of ICMCT School of Electronic Engineering Service Function Chaining (SFC) provides a special capability that defines an ordered list of network services as a virtual chain and makes a network more flexible and manageable. However, SFC is vulnerable to various attacks caused by compromised switches, especially the middlebox-bypass attack. In this document, we propose a security architecture that can detect not only middlebox-bypass attacks but also other incorrect forwarding actions by compromised switches. The existing solutions to protect SFC against compromised switches and middlebox-bypass attacks can only solve individual problems. The proposed architecture uses both probe-based and statistics-based methods to check the probe packets with random pre- assigned keys and collect statistics from middleboxes for detecting any abnormal actions in SFC. Work in Progress Independent consultant Cisco This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document are used to derive recommendations that update MTU and fragment issues in RFC 4459. Work in Progress Ericsson Trinity College Dublin Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This memo suggests that the existing RFC 3552 threat model, while important and still valid, is no longer alone sufficient to cater for the pressing security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken and we argue that investigation of these issues is warranted. It is particularly important to ensure that as we continue to develop Internet technology, non-communications security related threats, and privacy issues, are properly understood. Work in Progress This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community. The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK] This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy. This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents. This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata. Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators. The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905. Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

Acknowledgements This document was created as a follow-up to the discussion in IETF 104: (slide 7). Thanks to , , , , , , , and for the comments. Many thanks to for the valuable secdir review and for the opsdir review. Thanks to for the . Thanks to , , , , , , , , , and for the IESG review.

Authors' Addresses Orange

Rennes 35000 France mohamed.boucadair@orange.com

Akamai

Embassy Golf Link Business Park Bangalore Karnataka 560071 India kondtir@gmail.com

Citrix Systems, Inc.

USA dwing-ietf@fuggles.com