[要約] RFC 9145は、ネットワークサービスヘッダー（NSH）の完全性保護と、機密性の高いコンテキストヘッダーの暗号化に関する技術仕様です。この文書の目的は、データセンターやクラウド環境での仮想ネットワーク機能（VNF）間の通信の安全性を高めることにあります。利用場面としては、サービスチェーン内でのデータの保護が必要な場合に適用されます。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9145 Orange
Category: Standards Track T. Reddy.K
ISSN: 2070-1721 Akamai
D. Wing
Citrix
December 2021
Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers
ネットワークサービスヘッダ（NSH）の整合性保護（NSH）および敏感なコンテキストヘッダの暗号化
Abstract
概要
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.
本明細書は、サービス関数連鎖（SFC）に使用されるネットワークサービスヘッダ（NSH）に直接整合性保護を追加するためのオプションの方法を提示しています。また、この仕様では、NSHで運ばれる機密メタデータ（MD）の暗号化を可能にします。
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.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
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.
この文書の現在のステータス、任意のエラータ、およびフィードバックの提供方法は、https://www.rfc-editor.org/info/frfc9145で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Assumptions and Basic Requirements
4. Design Overview
4.1. Supported Security Services
4.1.1. Encrypt All or a Subset of Context Headers
4.1.2. Integrity Protection
4.2. One Secret Key, Two Security Services
4.3. Mandatory-to-Implement Authenticated Encryption and HMAC
Algorithms
4.4. Key Management
4.5. New NSH Variable-Length Context Headers
4.6. Encapsulation of NSH within NSH
5. New NSH Variable-Length Context Headers
5.1. MAC#1 Context Header
5.2. MAC#2 Context Header
6. Timestamp Format
7. Processing Rules
7.1. Generic Behavior
7.2. MAC NSH Data Generation
7.3. Encrypted NSH Metadata Generation
7.4. Timestamp for Replay Attack Prevention
7.5. NSH Data Validation
7.6. Decryption of NSH Metadata
8. MTU Considerations
9. Security Considerations
9.1. MAC#1
9.2. MAC#2
9.3. Time Synchronization
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
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 [RFC7498].
付加価値サービスの配信に対して、多くの高度なサービス機能（SFS）が有効になっています。典型的には、SFSは、IPアドレス共有、Covertチャネルを回避し、サービス拒否（DOS）攻撃を検出し、それらに対するネットワークインフラストラクチャ、ネットワークスライスなどの攻撃、ネットワークスライスなどのようなさまざまなサービス目標を満たすために使用されます。より機敏なサービス配信手順を要求する複雑なサービス展開制約と共に、事業者はサービスの有効化時間サイクルを最適化しながら、それらのサービス配信ロジックを合理化し、その複雑さを制御する必要があります。全体的な問題空間は[RFC7498]に記載されています。
[RFC7665] 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. [RFC8300] specifies the SFC encapsulation: Network Service Header (NSH).
[RFC7665]は、トポロジの依存と構成の複雑さを含む、既存のサービス展開の問題のある側面をアドレス指定するデータプレーンアーキテクチャを提示します。また、ネットワーク内のサービス機能チェーン（SFC）の仕様、作成、および保守のためのアーキテクチャ、つまり、結果として選択されたパケット/フローに適用する必要があるSFSの順序付けられたセットと順序付け制約の定義方法についても説明します。交通分類の[RFC8300] SFCカプセル化：ネットワークサービスヘッダー（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 (Section 8.2 of [RFC8300]).
NSHデータは、そのような機能をサポートするトランスポートカプセル化を使用するためのセキュリティとプライバシーを使用するために、保証およびプライバシーを必要とするサービストポロジを強制的に非認証および暗号化しています（[RFC8300]のセクション8.2）。
Note that some transport encapsulations (e.g., IPsec) only provide hop-by-hop security between two SFC data plane elements (e.g., two Service Function Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF security of NSH metadata. For example, if IPsec is used, SFFs or SFs within a Service Function Path (SFP) that are not authorized to access the sensitive metadata (e.g., privacy-sensitive information) will have access to the metadata. As a reminder, the metadata referred to is information that is inserted by Classifiers or intermediate SFs and shared with downstream SFs; such information is not visible to the communication endpoints (Section 4.9 of [RFC7665]).
一部のトランスポートカプセル化（例：IPsec）は、2つのSFCデータプレーン要素（たとえば、2つのサービス機能フォワーダ（SFFからSFまで）の間でホップバイホップセキュリティを提供し、SFからSFセキュリティを提供しないことに注意してください。nshメタデータたとえば、IPsecが使用されている場合、機密メタデータ（例えば、プライバシーに敏感な情報）にアクセスする権限がないサービス関数パス（SFP）内のSFFSまたはSFSがメタデータにアクセスできます。リマインダーとして、参照されているメタデータは、分類子または中間SFSによって挿入され、下流のSFSと共有される情報である。このような情報は通信エンドポイントには表示されません（[RFC7665]のセクション4.9）。
The lack of such capability was reported during the development of [RFC8300] and [RFC8459]. The reader may refer to Section 3.2.1 of [INTERNET-THREAT-MODEL] for a discussion on the need for more awareness about attacks from within closed domains.
[RFC8300]および[RFC8459]の開発中にそのような能力の欠如が報告された。リーダーは[インターネット脅威モデル]のセクション3.2.1を参照して、閉じたドメイン内からの攻撃についてのより多くの認識をもたらすことを参照することができます。
This specification fills that gap for SFC (that is, it defines the "NSH Variable Header-Based Integrity" option mentioned in Section 8.2.1 of [RFC8300]). Concretely, this document adds integrity protection and optional encryption of sensitive metadata directly to the NSH (Section 4). The integrity protection covers the packet payload and provides replay protection (Section 7.4). Thus, the NSH does not have to rely upon an underlying transport encapsulation for security.
この仕様は、SFCのギャップを埋める（つまり、RFC8300]のセクション8.2.1で説明した「NSH変数ヘッダベースの整合性」オプションを定義します。具体的には、この文書は整合性保護と機密メタデータのオプションの暗号化を直接NSHに追加します（セクション4）。完全性保護はパケットペイロードをカバーし、再生保護を提供します（7.4項）。したがって、NSHは、セキュリティのための基礎となるトランスポートカプセル化に頼る必要はありません。
This specification introduces new Variable-Length Context Headers to carry fields necessary for integrity-protected NSH headers and encrypted Context Headers (Section 5). This specification is only applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU considerations are discussed in Section 8. This specification is not 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 16 bytes; that is not sufficient to accommodate both the metadata and message integrity of the NSH data.
この仕様では、整合性保護されたNSHヘッダーと暗号化されたコンテキストヘッダーに必要なフィールドを伝送するための新しい可変長コンテキストヘッダーが紹介されています（セクション5）。この仕様はNSH MDタイプ0x02にのみ適用されます（[RFC8300]のセクション2.5）。MTUの考慮事項についてはセクション8で説明されています。この仕様は、NSH MDタイプ0x01（[RFC8300]のセクション2.4）には適用されません（[RFC8300]のセクション2.4）、サイズが16バイトの固定長コンテキストヘッダーのみを許可するためです。それは、NSHデータのメタデータとメッセージの整合性の両方に対応するのに十分ではありません。
This specification limits access to NSH-supplied information along an SFP to entities that have a need to interpret it.
この仕様は、それを解釈する必要があるエンティティへのSFPに沿ったNSH提供された情報へのアクセスを制限します。
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.
NSH対応のコントロールプレーンソリューションを指定するのはこの文書の範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document makes use of the terms defined in [RFC7665] and [RFC8300]. 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 Section 4 of [RFC8300].
この文書は[RFC7665]と[RFC8300]で定義されている用語を使用しています。この文書で使用されている「トランスポートカプセル化」という用語は、NSH-を伝送するために使用される仮想拡張ローカルエリアネットワーク（VXLAN-GPE）のための外部カプセル化（例えば、一般的なルーティングカプセル化（GRE）、IPsec、および一般的なプロトコル拡張を参照しています。[RFC8300]のセクション4に従ってカプセル化されたパケット。
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 [RFC7665] and further refined in [RFC8300].
SFCデータプレーン要素：SFCデータプレーンアーキテクチャ[RFC7665]で定義されている[RFC7665]で定義されているNSH対応SF、SFF、SFCプロキシ、または分類子を参照し、[RFC8300]でさらに洗練されています。
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.
SFC制御要素：SFC対応ドメイン内のNSHパケットを処理する方法について、1つまたは複数のSFCデータプレーン要素に指示する論理エンティティです。
Key Identifier: Is used to identify keys to authorized entities. See, for example, "kid" usage in [RFC7635].
キー識別子：承認されたエンティティへのキーを識別するために使用されます。「RFC7635」の「キッド」使用法を参照してください。
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データ：NSHは、ベースヘッダー、サービスパスヘッダー、およびオプションのコンテキストヘッダーで構成されています。NSHデータとは、上記のヘッダ全てとNSHがSFPを実現するためにNSHが課されるパケットまたはフレームを指す。
NSH imposer: Refers to an SFC data plane element that is entitled to impose the NSH with the Context Headers defined in this document.
NSH Impers：このドキュメントで定義されているコンテキストヘッダーとNSHを課す権利があるSFCデータプレーン要素を参照します。
Section 2 of [RFC8300] specifies that the NSH data can be spread over three headers:
[RFC 8300]のセクション2は、NHSデータを3つのヘッダーに拡散できることを指定します。
Base Header: Provides information about the service header and the payload protocol.
基本ヘッダー：サービスヘッダーとペイロードプロトコルに関する情報を提供します。
Service Path Header: Provides path identification and location within an SFP.
Service Pathヘッダー：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:
NSHは、SFC / SFPベースで、下流のNSH対応データプレーン要素を使用してコンテキスト情報（a.k.a.metadata）を共有することを可能にします。その目的に：
* The Classifier is instructed by an SFC control element about the set of context information to be supplied for a given service function chain.
* 分類器は、特定のサービス機能チェーンに対して供給されるコンテキスト情報のセットに関するSFC制御要素によって指示される。
* 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.
* NSH対応のSFは、特定のサービス機能チェーンのパケットに接続する必要があるメタデータに関するSFC制御要素によって指示されます。この命令は、SFC / SFPの有効性寿命の間にいつでも発生する可能性があります。特定のサービス機能チェーンでは、NSH対応SFは、パケットで提供されたコンテキストのセットを消費するための順序も提供される。
* 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.
* NSH対応SFは、NSHで提供されたコンテキスト情報を消費した後に採用されるべき動作に関するSFC制御要素によっても指示され得る。例えば、コンテキスト情報は、維持、更新、または削除することができる。
* 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.
* SFCプロキシは、NSH - NAWARE SF（例えば、コンテキスト情報を維持または削除することができる）に代わってNSHで供給されたコンテキスト情報を処理するために採用されるべき動作に関するSFC制御要素によって指示され得る。SFCプロキシは、NSH-NAWARE SFを代表してNSHにいくつかの新しいコンテキスト情報を追加するように指示されます。
In reference to Table 1:
表1を参照して：
* Classifiers, NSH-aware SFs, and SFC proxies are entitled to update the Context Header(s).
* 分類子、NSH対応SFS、およびSFCプロキシは、コンテキストヘッダを更新する権利があります。
* Only NSH-aware SFs and SFC proxies are entitled to update the Service Path Header.
* NSH対応のSFSおよびSFCプロキシだけが、Service Pathヘッダーを更新する権利があります。
* SFFs are entitled to modify the Base Header (TTL value, for example). Nevertheless, SFFs are not supposed to act on the Context Headers or look into the content of the Context Headers (Section 4.3 of [RFC7665]).
* SFFSは、ベースヘッダ（たとえばTTL値）を変更することができます。それにもかかわらず、SFFSはコンテキストヘッダに行動すること、またはコンテキストヘッダの内容を調べることは想定されていない（[RFC7665]のセクション4.3）。
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.
* 暗号化されていないコンテキストヘッダーの両方が同じ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 Section 9.1.
* ソリューションは、ベースヘッダーのオプションの整合性保護を提供する必要があります。そのようなチェックを無効にすることの意味は、9.1節で説明されています。
+=============+===========================+=======================+
| SFC Data | Insert, remove, or | Update the NSH |
| Plane | replace the NSH | |
| Element +========+========+=========+===========+===========+
| | Insert | Remove | Replace | Decrement | Update |
| | | | | Service | Context |
| | | | | Index | Header(s) |
+=============+========+========+=========+===========+===========+
| Classifier | + | | + | | + |
+-------------+--------+--------+---------+-----------+-----------+
| Service | | + | | | |
| Function | | | | | |
| Forwarder | | | | | |
| (SFF) | | | | | |
+-------------+--------+--------+---------+-----------+-----------+
| Service | | | | + | + |
| Function | | | | | |
| (SF) | | | | | |
+-------------+--------+--------+---------+-----------+-----------+
| Service | + | + | | + | + |
| Function | | | | | |
| Chaining | | | | | |
| (SFC) Proxy | | | | | |
+-------------+--------+--------+---------+-----------+-----------+
Table 1: Summary of NSH Actions
表1：NSHアクションの概要
This specification provides the functions described in the following subsections.
本明細書は以下のサブセクションに記載されている機能を提供します。
The solution allows encrypting all or a subset of NSH Context Headers by Classifiers, NSH-aware SFs, and SFC proxies.
このソリューションでは、分類子、NSH対応のSFS、およびSFCプロキシによって、NSHコンテキストヘッダの全部またはサブセットを暗号化することができます。
As depicted in Table 2, SFFs are not involved in data encryption.
表2に示すように、SFFSはデータ暗号化に関与していません。
+====================+=======================+================+
| Data Plane Element | Base and Service Path | Context Header |
| | Headers Encryption | Encryption |
+====================+=======================+================+
| Classifier | No | Yes |
+--------------------+-----------------------+----------------+
| SFF | 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
表2：SFCデータプレーン要素でサポートされている暗号化機能
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.
分類子、NSH対応SFS、およびSFCプロキシは、暗号化されなければならないコンテキストヘッダのセット（通常はプライバシーに敏感なメタデータ（通常は）で指示されます。暗号化キー化材料は、これらのSFCデータプレーン要素にのみ提供されます。
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.
制御平面は、所与のコンテキストヘッダを（例えば、SFC対応ドメイン内に割り当てられている識別子を参照させる）のSFCデータプレーン要素のセットを示すことができる。そのような命令が適切なSFCデータプレーン要素にどのように提供されても命令を格納するために使用される構造を詳述するのは、この文書の範囲外であり、その範囲外でも詳述する。
The Service Path Header (Section 2 of [RFC8300]) 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.
SFFSは、パス内の次のSFを決定するためにSFFSがサービスパス識別子（SPI）と組み合わせてサービスインデックス（SI）を使用するため、暗号化されていない。
The solution provides integrity protection for the NSH data. Two levels of assurance (LoAs) are supported.
このソリューションは、NSHデータの完全性保護を提供します。2つのレベルの保証（LOA）がサポートされています。
The first level of assurance is where all NSH data except the Base 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 are not provided with authentication material. Further details are discussed in Section 5.1.
最初のレベルの保証レベルは、基本ヘッダーを除くすべてのNSHデータが保護されている場合（図1）です。この場合、NSH Impersは、分類子、NSH対応SF、またはSFCプロキシであり得る。SFFSには認証素材が付属していません。詳細はセクション5.1で説明されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Base Header | |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| | Service Path Header | S
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| | Context Header(s) | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Original Packet |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+------Scope of integrity-protected data
Figure 1: First Level of Assurance
図1：保証の最初のレベル
The second level of assurance is where all NSH data, including 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 Proxy. Further details are provided in Section 5.2.
2番目のレベルの保証は、基本ヘッダーを含むすべてのNSHデータが完全性保護されている場所です（図2）。この場合、NSH Impersは、分類子、NSH対応SF、SFF、またはSFCプロキシであり得る。さらに詳細はセクション5.2で提供されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Encapsulation |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Base Header | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| | Service Path Header | S
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| | Context Header(s) | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| | Original Packet |
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+----Scope of integrity-protected data
Figure 2: Second Level of Assurance
図2：第2レベルの保証
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 (Section 5).
Integrity-Protectionスコープは、NSHのNSH対応のSFS、SFF、およびSFCプロキシに明示的にシグナリングされています（セクション5）。
In both levels of assurance, the Context Headers and the packet on which the NSH is imposed are subject to integrity protection.
両レベルの保証レベルでは、コンテキストヘッダーとNSHが課されているパケットは、完全性保護の対象となります。
Table 3 classifies the data plane elements as being involved or not involved in providing integrity protection for the NSH.
表3は、データプレーン要素を関与しているか、NSHの整合性保護を提供することに関与しているものとして分類します。
+====================+==================================+
| 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 |
+--------------------+----------------------------------+
Table 3: Integrity Protection Supported by SFC Data Plane Elements
表3：SFCデータプレーン要素によってサポートされている完全性保護
The Authenticated Encryption with Associated Data (AEAD) interface defined in Section 5 of [RFC5116] is used to encrypt the Context Headers that carry sensitive metadata and to provide integrity protection for the encrypted Context Headers.
[RFC5116]のセクション5で定義されている関連データ（AEAD）インターフェイスを持つ認証された暗号化は、機密メタデータを伝えるコンテキストヘッダーを暗号化し、暗号化されたコンテキストヘッダーの整合性保護を提供します。
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:
次のように、入力秘密鍵（k）から2次キー、 "enc_key"が生成されます。これら2つのキーはそれぞれオクテット文字列です。
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.
Mac_Key：kの最初のmac_key_lenオクテットで構成されています。MAC_Keyは、NSHデータのメッセージの整合性を計算するために使用されます。言い換えれば、暗号化メカニズムによって提供される完全性保護は、暗号化されていないコンテキストヘッダおよびNSHが課されるパケットに対する保護もまた提供されるように拡張されている。
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.
ENC_KEY：kの最後のENC_KEY_LENオクテットで構成されています。ENC_KEYは、コンテキストヘッダーを暗号化するための対称暗号化キーとして使用されます。
The Hashed Message Authentication Code (HMAC) algorithm discussed in [RFC4868] is used to protect the integrity of the NSH data. The algorithm for implementing and validating HMACs is provided in [RFC2104].
[RFC4868]で説明したハッシュメッセージ認証コード（HMAC）アルゴリズムは、NSHデータの整合性を保護するために使用されます。HMACを実装して検証するためのアルゴリズムは[RFC2104]に提供されています。
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.
AEDとHMACアルゴリズムの両方を使用することの利点（AEDだけではなく）NSH対応のSFSおよびSFCプロキシは、SIをデクリメントした後にNSHデータのメッセージの整合性を再計算するだけで、暗号文を再計算する必要がないことです。もう1つの利点は、SFFSがENC_KEYにアクセスできないものであり、暗号化されたコンテキストヘッダーには動作できず、（2番目のレベルの保証の場合）SFFSはMAC_KEYにアクセスできます。同様に、コンテキストヘッダーを復号化できないNSH対応のSFまたはSFCプロキシは、ENC_KEYにアクセスできません。
The authenticated encryption algorithm or HMAC algorithm to be used by SFC data plane elements is typically controlled using the SFC control plane. Mandatory-to-implement authenticated encryption and HMAC algorithms are listed in Section 4.3.
SFCデータプレーン要素によって使用される認証された暗号化アルゴリズムまたはHMACアルゴリズムは、通常、SFC制御プレーンを使用して制御される。義務的な認証された暗号化およびHMACアルゴリズムは、セクション4.3にリストされています。
The authenticated encryption process takes four inputs, each of which is an octet string: a secret key (ENC_KEY, referred to as "K" in [RFC5116]), 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 Section 2.1 of [RFC5116].
認証された暗号化プロセスは4つの入力を取り、その各々はオクテット文字列です.Secretキー（[RFC5116]で "k"と呼ばれる）、平文（P）、関連データ（A）（データを含む）認証されたが暗号化されていない）、およびnonce（n）。[RFC5116]のセクション2.1で説明したように、暗号文（C）が出力として生成されます。
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 Section 2.2 of [RFC5116].
復号化して検証するために、暗号はENC_KEY、N、A、およびCを入力として取ります。出力は、[RFC5116]のセクション2.2で説明されているように、復号化が失敗したことを示す平文またはエラーです。
4.3. Mandatory-to-Implement Authenticated Encryption and HMAC Algorithms
4.3. 認証された認証された暗号化とHMACアルゴリズム
Classifiers, NSH-aware SFs, and SFC proxies MUST implement the AES_128_GCM [GCM][RFC5116] algorithm and SHOULD implement the AES_192_GCM and AES_256_GCM algorithms.
分類子、NSH対応SFS、およびSFCプロキシは、AES_128_GCM [GCM] [RFC5116]アルゴリズムを実装し、AES_192_GCMおよびAES_256_GCMアルゴリズムを実装する必要があります。
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.
分類子、NSH対応SFS、およびSFCプロキシは、HMAC-SHA-256-128アルゴリズムを実装し、HMAC-SHA-384-192およびHMAC-SHA-512-256アルゴリズムを実装する必要があります。
SFFs MAY implement the aforementioned cipher suites and HMAC algorithms.
SFFSは、前述の暗号スイートおよびHMACアルゴリズムを実装することができる。
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.
注：AES_128_CBC_HMAC_SHA_256アルゴリズムの使用は、2番目の128ビット認証タグの必要性を回避しましたが、Cipher Block Chaining（CBC）モードがどのように動作するかの性質上、AES_128_CBC_HMAC_SHA_256は平文のムレビリティを可能にします。このマレアビリティは、メッセージ認証コード（MAC）キーを知っているが暗号化キーではなく暗号化キーではないが、平文の一部が既知である場合は、平文の任意のブロックを作成することができます。この仕様は、このタイプの攻撃を防ぐための別々のAEADおよびMAC保護の使用を義務付けています。
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.
秘密鍵（k）および認証された暗号化アルゴリズムまたはMAC_KeyおよびHMACアルゴリズムの割り当て/プロビジョニングの手順は、この仕様の範囲外です。そのため、この仕様は特定のメカニズムのサポートを義務付けていません。
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.
* SFC対応ドメイン内で使用されるすべてのサービス機能に同じキーイングマテリアルが使用されます。
* Distinct keying material is used per SFP by all involved SFC data path elements.
* 異なるキーイング材料は、すべての関与のSFCデータパス要素によってSFPごとに使用されます。
* 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.
SFC / SFPあたりのキー化材料に頼る展開に頼るために、またNSHデータを一定時間暗号化した後にキーを更新する必要性に対応するために、この文書は重要な識別子を使用して、適切なキーイング材料およびMACおよび暗号化のための関連するアルゴリズムを明確に識別するために使用されます。。帯域内識別子のこの使用は、キーイング材料の同期の問題に対処する。
Additional information on manual vs. automated key management and when one should be used over the other can be found in [RFC4107].
マニュアルと自動キー管理に関する追加情報、およびもう1つ以上使用する場合は、[RFC4107]にあります。
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 Section 9.
グループ共有対称鍵を使用することに関わるリスクは、共有されているグループのサイズによって増加します。追加のセキュリティ上の問題については、第9章で説明しています。
New NSH Variable-Length Context Headers are defined in Section 5 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 (Section 7.4), 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.
NSHデータの整合性保護、および任意選択で、敏感なメタデータを伝えるコンテキストヘッダの暗号化については、セクション5で新しいNSH可変長コンテキストヘッダが定義されています。具体的には、NSH IMPOSERには、（1）キーインピーダを識別するためのキー識別子、（2）再生攻撃から保護するタイムスタンプ（セクション7.4）、およびターゲットNSHデータのMAC（完全性保護に応じて）スコープ）MAC_KEYとオプションで、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.
NSHデータの整合性を確認する必要があるSFCデータプレーン要素は、NSHで実行されているキー識別子のMAC_KEYおよびHMACアルゴリズムを使用します。
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.
いくつかのコンテキストヘッダを復号化する必要があるNSH対応のSFまたはSFCプロキシは、NSHで実行されているキー識別子のrec_KEYと復号化アルゴリズムを使用します。
Section 7 specifies the detailed procedure.
セクション7詳細な手順を指定します。
As discussed in Section 3 of [RFC8459], 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 (Figure 3). 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.
[RFC8459]のセクション3で説明したように、SFC対応ドメイン（上位ドメインと呼ばれる）は、多くのサブドメイン（下位ドメインと呼ばれる）に分解できます。下位ドメインの境界で上位レベルのNSH情報を復元する状態を維持するために、2つのNSHレベルが使用されます。上位レベルのドメインの境界と低いNSHに課される上限NSHが使用されます。元のNSHの前に下位のドメインの分類子によってプッシュされます（図3）。そのため、上限情報は、変更なしで下位チェーンに沿って搬送されます。パケットは上位NSHに従って最上位ドメインで転送され、下位レベルのドメインの下部NSHに従って転送されます。
+---------------------------------+
| Transport Encapsulation |
+->+---------------------------------+
| | Lower-NSH Header |
| +---------------------------------+
| | Upper-NSH Header |
| +---------------------------------+
| | Original Packet |
+->+---------------------------------+
|
|
+----Scope of NSH security protection
provided by a lower-level domain
Figure 3: Encapsulation of NSH within NSH
図3：NSH内のNSHのカプセル化
SFC data plane elements of a lower-level domain include the Upper-NSH when computing the MAC.
下位レベルのドメインのSFCデータプレーン要素には、MACを計算するときの上限NSHが含まれます。
Keying material used at the upper-level domain SHOULD NOT be the same as the one used by a lower-level domain.
上位レベルのドメインで使用されるキーイング材料は、下位レベルのドメインによって使用されるものと同じであるべきではありません。
This section specifies the format of new Variable-Length Context Headers that are used for NSH integrity protection and, optionally, Context Header encryption.
このセクションでは、NSH完全性保護のために使用される新しい可変長コンテキストヘッダーの形式を指定して、必要に応じて、コンテキストヘッダーの暗号化。
In particular, this section defines two "MAC and Encrypted Metadata" Context Headers, each having specific deployment constraints. Unlike 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 as shown in Figure 4.
特に、このセクションでは、それぞれが特定の展開制約を持つ2つの「MACおよび暗号化されたメタデータ」コンテキストヘッダーを定義します。セクション5.1とは異なり、セクション5.2で提供されている保証レベルはSFFSでMAC_Keyを共有する必要があります。両方のコンテキストヘッダは、図4に示すと同じ形式を有する。
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MAC and Encrypted Metadata Context Header
図4：Macおよび暗号化されたメタデータコンテキストヘッダー
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 Encrypted Metadata" Context Header, if included, MUST always be the last Context Header.
「MACと暗号化されたメタデータ」コンテキストヘッダは、[RFC8300]のセクション2.2に従って4バイトの倍数に埋め込まれています。インクルードの場合は、「Macと暗号化されたメタデータ」コンテキストヘッダーは常に最後のコンテキストヘッダーになります。
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 Figure 5.
MAC＃1コンテキストヘッダは、Service Pathヘッダ、コンテキストヘッダ、およびNSHが課されている内部パケットを、MAC_Keyと、enc_keyを使用して暗号化されたコンテキストヘッダを使用して計算された内部パケットを搭載した可変長コンテキストヘッダです。このコンテキストヘッダによって提供される完全性保護の範囲は図5に示されている。
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. Section 9.1 discusses the possible threat associated with this level of assurance.
このMacスキームはSFFSを持つMAC_Keyを共有する必要はありません。TTL処理のため、各SFFでMACを再計算する必要はありません。セクション9.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
Figure 5: Scope of MAC#1
図5：MAC＃1の範囲
In reference to Figure 4, the description of the fields is as follows:
図4を参照して、フィールドの説明は次のとおりです。
Metadata Class: MUST be set to 0x0 (Section 2.2 of [RFC8300]).
メタデータクラス：0x0に設定する必要があります（[RFC8300]のセクション2.2）。
Type: 0x02 (see Section 10).
タイプ：0x02（セクション10を参照）。
U: Unassigned bit (Section 2.5.1 of [RFC8300]).
U：未割り当てビット（[RFC8300]のセクション2.5.1）。
Length: Indicates the length of the variable-length metadata in bytes. Padding considerations are discussed in Section 2.5.1 of [RFC8300].
長さ：可変長メタデータの長さをバイト単位で表示します。パディングの考慮事項については、[RFC8300]のセクション2.5.1で説明します。
Key Id Len: Variable. Carries the length of the key identifier in octets.
キーID LEN：変数。キー識別子の長さをオクテットの長さにします。
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.
キー識別子：キーをSFCデータプレーン要素に識別して配信するために使用される可変長キー識別子オブジェクトを搭載しています。この識別子は、SFC / SFP当たりのキー化材料に依存する展開を収容するのに役立ちます。キー識別子は、キーイング材料の同期の問題を解決するのに役立ちます。単一のキー識別子は、キーに関連付けられているENC_KEYとMAC_KEYの両方を検索し、それらのキーで使用されている対応する暗号化とMACアルゴリズムの両方を調べます。
Timestamp: Refer to Section 6 for more details about the structure of this field.
タイムスタンプ：このフィールドの構造について詳しくは、セクション6を参照してください。
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 Length：NONCEの長さを伝えます。コンテキストヘッダが整合性保護のみである場合は、「Nonce Length」がゼロに設定されます（つまり、「NONCE」は含まれません）。
Nonce: Carries the Nonce for the authenticated encryption operation (Section 3.1 of [RFC5116]).
Nonce：認証された暗号化操作のためのNonceを搭載しています（[RFC5116]のセクション3.1）。
Encrypted Context Headers: Carries the optional encrypted Context Headers.
暗号化されたコンテキストヘッダー：オプションの暗号化されたコンテキストヘッダーを搭載しています。
Message Authentication Code: Covers the entire NSH data, excluding the Base Header.
メッセージ認証コード：基本ヘッダーを除く、NSHデータ全体をカバーします。
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 Figure 6.
MAC＃2コンテキストヘッダは、MAC_KEYを使用して計算されたNSHデータ全体と、オプションでENC_KEYを使用して暗号化されたコンテキストヘッダを実行する可変長コンテキストヘッダです。このコンテキストヘッダによって提供される完全性保護の範囲を図6に示す。
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
Figure 6: Scope of MAC#2
図6：MAC＃2の範囲
In reference to Figure 4, the description of the fields is as follows:
図4を参照して、フィールドの説明は次のとおりです。
Metadata Class: MUST be set to 0x0 (Section 2.2 of [RFC8300]).
メタデータクラス：0x0に設定する必要があります（[RFC8300]のセクション2.2）。
Type: 0x03 (see Section 10).
タイプ：0x03（セクション10を参照）。
U: Unassigned bit (Section 2.5.1 of [RFC8300]).
U：未割り当てビット（[RFC8300]のセクション2.5.1）。
Length: Indicates the length of the variable-length metadata in bytes. Padding considerations are discussed in Section 2.5.1 of [RFC8300].
長さ：可変長メタデータの長さをバイト単位で表示します。パディングの考慮事項については、[RFC8300]のセクション2.5.1で説明します。
Key Id Len: See Section 5.1.
キーID LEN：セクション5.1を参照してください。
Key Identifier: See Section 5.1.
キー識別子：5.1を参照してください。
Timestamp: See Section 6.
タイムスタンプ：6セクション6を参照してください。
Nonce Length: See Section 5.1.
Nonce Length：セクション5.1を参照してください。
Nonce: See Section 5.1.
Nonce：5.1項を参照してください。
Encrypted Context Headers: Carries the optional encrypted Context Headers.
暗号化されたコンテキストヘッダー：オプションの暗号化されたコンテキストヘッダーを搭載しています。
Message Authentication Code: Covers the entire NSH data.
メッセージ認証コード：NSHデータ全体をカバーします。
This section follows the template provided in Section 3 of [RFC8877].
このセクションでは、[RFC8877]のセクション3に記載されているテンプレートに従います。
The format of the Timestamp field introduced in Section 5 is depicted in Figure 7.
セクション5で導入されたタイムスタンプ場のフォーマットを図7に示す。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Timestamp Field Format
図7：タイムスタンプフィールドフォーマット
Timestamp field format: Seconds: Specifies the integer portion of the number of seconds since the epoch.
タイムスタンプフィールド形式：秒：エポック以降の秒数の整数部分を指定します。
+ Size: 32 bits
+ サイズ：32ビット
+ Units: Seconds
+ 単位：秒数
Fraction: Specifies the fractional portion of the number of seconds since the epoch.
フラクション：エポック以降の秒数の小数部分を指定します。
+ Size: 32 bits
+ サイズ：32ビット
+ Units: The unit is 2^(-32) seconds, which is roughly equal to 233 picoseconds.
+ 単位：ユニットは2 ^（ - 32）秒です。これは、約233ピコ秒にほぼ同じです。
Epoch: The epoch is 1970-01-01T00:00 in UTC time. Note that this epoch value is different from the one used in Section 6 of [RFC5905] (which will wrap around in 2036).
EPOCH：EPOCHはUTC時期に1970-01-01T00：00です。このエポック値は、[RFC5905]のセクション6で使用されているものとは異なります（これは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.
Leap Seconds：このタイムスタンプ形式は、Leap Secondsの影響を受けます。タイムスタンプは、EpochからLeap Secondsの数を引いてから経過した秒数を表します。
Resolution: The resolution is 2^(-32) seconds.
解決策：解像度は2 ^（ - 32）秒です。
Wraparound: This time format wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2106.
ラップアラウンド：この時間フォーマットは2 32秒ごとにラップします。これはおおよそ136歳です。次のラップアラウンドは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 [RFC5905] 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.
同期の態様：この文書の範囲外の同期メカニズムを使用して、SFCデータプレーン要素がUTCに同期されていると仮定されています。一般的な展開では、SFCデータプレーン要素は同期のためにNTP [RFC5905]を使用します。したがって、タイムスタンプはNTP同期クロックから導出され、タイムスタンプがNTPサーバのクロックに対して測定されることを可能にする。この時間フォーマットはUTCに関して指定されているので、それはLeap秒の影響を受けます（NTPの時間形式と類似した方法で、類似している）。したがって、うるう2秒の間のタイムスタンプの値は一時的に不正確である可能性があります。
The following subsections describe the processing rules for integrity-protected NSH and, optionally, encrypted Context Headers.
次のサブセクションでは、完全性保護されたNSHの処理規則と、オプションで暗号化されたコンテキストヘッダーについて説明します。
This document adheres to the recommendations in Section 8.1 of [RFC8300] for handling the Context Headers at both ingress and egress SFC boundary nodes (i.e., to strip the entire NSH, including Context Headers).
この文書は、入力と出力SFC境界ノードと出力SFC境界ノードの両方でコンテキストヘッダを処理するための[RFC8300]の推奨事項（すなわち、コンテキストヘッダを含むNSH全体を削除する）の推奨事項を遵守します。
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.
このドキュメントで定義されているコンテキストヘッダーを注入するための分類子の失敗は、通知アラームがSFC制御要素に送信される可能性がある間にローカルに記録されるべきです。NSH対応ノードの障害NSHデータの整合性を検証するためには、通知アラームをSFC制御要素に送信することができますが、そのパケットを破棄する必要があります。通知アラームの送信の詳細（すなわち、周波数、しきい値、およびアラーム内のコンテンツなどのコンテキストヘッダ、およびコンテンツなどの情報に応じて、通知アラームの送信に影響するパラメータ）は設定可能であるべきである。
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).
NSH対応のSFSおよびSFCプロキシは、コンテキストヘッダのコンテンツを処理した後に、一部の暗号化されたコンテキストヘッダをパケットからストリップしたり、サービス機能チェーン内の次のSFにデータを渡すように指示されてもよい。命令が指定されていない場合、中間NSH対応ノードのデフォルトの動作はそのようなコンテキストヘッダーを維持することで、情報を次のNSH対応ホップに渡すことができるようにします。NSH対応のSFSおよびSFCプロキシは、コンテキストヘッダ（例えば、コンテキストヘッダをストリップし、既存のコンテキストヘッダのコンテンツを更新し、新しいコンテキストヘッダを挿入する）を変更すると、整合性保護を再適用する必要があります。
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.
コンテキストヘッダを復号化することを許可されていないNSH対応のSFまたはSFCプロキシは、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.
それ以外の場合は、暗号化されたコンテキストヘッダーを受信するNSH対応のSFまたはSFCプロキシは、それが復号化された特定のコンテキストヘッダーを復号化することが許可されていない（ただし、他のユーザーを消費する）、そのコンテキストヘッダーをアップストリームに転送するときにそのコンテキストヘッダーを変更してください。
Only one instance of a "MAC and Encrypted Metadata" Context Header (Section 5) 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 Section 2.5.1 of [RFC8300]. If NSH within NSH is used (Section 4.6), distinct LoAs may be used for each NSH level.
NSHレベルでは、「MACと暗号化されたメタデータ」コンテキストヘッダ（セクション5）の1つのインスタンスだけが許可されています。「MACおよび暗号化されたメタデータ」コンテキストヘッダの複数のインスタンスがNSHレベルに含まれている場合、SFCデータプレーン要素は最初のインスタンスを処理し、後続のインスタンスを無視し、セクション2.5.1に従ってこのイベントのカウンタをログまたは増やす必要があります。[RFC8300]の。NSH内のNSHが使用されている場合（セクション4.6）、各NSHレベルには異なるLOAを使用できます。
MTU and fragmentation considerations are discussed in Section 8.
MTUと断片化の考慮事項については、セクション8で説明します。
After performing any Context Header encryption, the HMAC algorithm discussed in [RFC4868] is used to integrity protect the target NSH data. An NSH imposer inserts a "MAC and Encrypted Metadata" Context Header for integrity protection (Section 5).
コンテキストヘッダ暗号化を実行した後、[RFC4868]で説明されているHMACアルゴリズムは、整合性を統合保護するために使用されます。NSH Impersは、整合性保護のために「MACおよび暗号化されたメタデータ」コンテキストヘッダを挿入します（セクション5）。
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 Section 5) 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.
NSH ImposerはMACフィールドをゼロに設定してから、MAC_KeyとHMACアルゴリズムを使用して、ターゲットNSHデータのメッセージ整合性（セクション5で説明した整合性保護範囲に応じて）を計算します。それは "Macおよび暗号化されたメタデータ"コンテキストヘッダーのMacフィールドに計算されたダイジェストを挿入します。MACの長さは、特定のキー識別子に採用されているHMACアルゴリズムによって決定されます。
The Message Authentication Code (T) computation process for the target NSH data with HMAC-SHA-256-128() can be illustrated as follows:
HMAC-SHA-256-128（）を持つターゲットNSHデータのメッセージ認証コード（T）計算プロセスは、次のように説明できます。
T = HMAC-SHA-256-128(MAC_KEY, target NSH data)
T = HMAC-SHA-256-128（MAC_KEY、ターゲットNSHデータ）
An entity in the SFP that updates the NSH MUST follow the above behavior to maintain message integrity of the NSH for subsequent validations.
NSHを更新するSFP内のエンティティは、後続の検証のためにNSHのメッセージの整合性を維持するために、上記の動作に従う必要があります。
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 5 and 6).
NSH Imposerは、機密メタデータを伝送するコンテキストヘッダを暗号化することができ、すなわち暗号化され、暗号化されていないメタデータは同じNSHパケット内で同時に実行されてもよい（セクション5および6）。
In order to prevent pervasive monitoring [RFC7258], 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 Section 5.2 of [RFC6973].
Pervasive Monitoring [RFC7258]を防ぐために、すべてのコンテキストヘッダーを暗号化することをお勧めします。プライバシーに敏感なメタデータを伝送するすべてのコンテキストヘッダーは暗号化されている必要があります。そうすることによって、プライバシーに敏感なメタデータは攻撃者に明らかにされません。プライバシー固有の脅威については、[RFC6973]のセクション5.2で説明します。
Using the secret key (ENC_KEY) and authenticated encryption algorithm, the NSH imposer encrypts the Context Headers (as set, for example, in Section 3) and inserts the resulting payload in the "MAC and Encrypted Metadata" Context Header (Section 5). 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).
秘密鍵（ENC_KEY）および認証された暗号化アルゴリズムを使用して、NSH Impersはコンテキストヘッダーを暗号化し（たとえばセクション3に設定されている）、結果のペイロードを「MACおよび暗号化されたメタデータ」コンテキストヘッダーに挿入します（セクション5）。AED関数に入力された追加の認証データは、長さゼロのバイト文字列です。機密メタデータを伝えるコンテキストヘッダ全体は暗号化されています（つまり、各コンテキストヘッダーのMDクラス、Type、Length、および関連メタデータ）。
More details about the exact encryption procedure are provided in Section 2.1 of [RFC5116]. In this case, the associated data (A) input is zero length for AES Galois/Counter Mode (AES-GCM).
正確な暗号化手順に関する詳細は、[RFC5116]のセクション2.1で提供されています。この場合、関連データ（A）入力は、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.
暗号化されたコンテキストヘッダーの内容を更新するSFP内の許可されたエンティティ、または新しい暗号化されたコンテキストヘッダーを追加する必要がある場合も、前述の動作に従う必要があります。
The Timestamp imposed by an initial Classifier is left untouched along an SFP. However, it can be updated when reclassification occurs (Section 4.8 of [RFC7665]). The same considerations for setting the Timestamp are followed in both initial classification and reclassification (Section 6).
初期分類器によって課されるタイムスタンプは、SFPに沿って手をとまっていない。ただし、再分類が発生したときに更新できます（[RFC7665]のセクション4.8）。タイムスタンプを設定するための同じ考察の後に、初期分類と再分類の両方が続きます（第6章）。
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:
NSH内のタイムスタンプ（TS）がNSHの受信時間に十分な最近の最近の場合、受信したNSHはNSH対応ノードによって受け入れられます（TSRT）。このチェックには次の式が使用されています。
-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.
デルタ間隔は設定可能なパラメータです。許可されたデルタのデフォルト値は2秒です。これが正当なトラフィックを落とす可能性があるため、非常に低いデルタ値を設定すると特別な注意が必要です。タイムスタンプが境界内にない場合、そのようなパケットを受信したSFCデータプレーン要素はNSHメッセージを破棄しなければなりません。
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.
デルタウィンドウ内のリプレイ攻撃は、MACフィールド値からの固有値など、パケットから派生した固有値を記録することによって、NSH対応ノードによって検出されてもよい。このようなNSH対応ノードは、重複を検出して拒否します。正当なサービスの理由から、いくつかのフローを複製する必要があるが、まだ元のフローでSFPの一部を共有する必要がある場合、正当な重複パケットは、複製に十分なエントロピーが追加されていない限り、リプレイパケットとしてのセグメントに含まれるNSH対応ノードによってタグ付けされます。パケット。そのようなエントロピーが追加される方法は実装固有です。
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.
注：TIMESTAMP DELTAウィンドウ内で、再生攻撃から保護するためのシーケンス番号を定義することが考えられます。このようなモードでは、NSH対応ノードは、タイムスタンプDeltaウィンドウ内の複製シーケンス番号を持つパケットを破棄する必要があります。ただし、同じSF（たとえば、クラスタまたはロードバランスのとれたSFS）のいくつかのインスタンスを持つ展開では、それらのインスタンス間で座標を整理するメカニズムが必要です。この要件に準拠するための調整メカニズムはサービス固有であるため、この文書にはこの保護は含まれていません。
All SFC data plane elements must be synchronized among themselves. These elements may be synchronized to a global reference time.
すべてのSFCデータプレーン要素は自分の間で同期されなければなりません。これらの要素は、グローバル基準時刻に同期されてもよい。
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:
この仕様に準拠したSFCデータプレーン要素がNSHデータの有効性を確認する必要がある場合は、「MACと暗号化されたメタデータ」コンテキストヘッダーが受信したNSHパケットに含まれていることを確認する必要があります。IMPOSERはパケットを静的に破棄し、少なくとも次のいずれかが観察されている場合、SPIに少なくとも1回エラーを記録する必要があります。
* the "MAC and Encrypted Metadata" Context Header is missing,
* 「Macと暗号化されたメタデータ」コンテキストヘッダーが見つからない
* the enclosed key identifier is unknown or invalid (e.g., the corresponding key expired), or
* 囲まれたキー識別子は不明であるか無効（例えば、対応するキーが期限切れになった）、または
* the timestamp is invalid (Section 7.4).
* タイムスタンプが無効です（7.4項）。
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 Section 5) 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.
タイムスタンプチェックが正常に渡された場合、SFCデータプレーン要素はNSHデータ整合性検証で進行します。「Macおよび暗号化されたメタデータ」コンテキストヘッダにMACフィールドの値を格納した後、SFCデータプレーン要素はMACフィールドをゼロに埋めます。次に、SFCデータプレーン要素は、MAC_KEYおよびHMACアルゴリズムを使用して、ターゲットNSHデータのメッセージ整合性（セクション5で説明した整合性保護範囲に応じて）を生成します。新しく生成されたダイジェストの値が保存されているものと同じである場合、SFCデータプレーン要素はNSHデータが改ざんされていないことが確実であり、したがって検証が成功しています。それ以外の場合は、NSHパケットを破棄する必要があります。計算されたHMAC値の格納値の比較は、Thwart Timing Attactsに一定の方法で行われなければなりません。
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.
提供された暗号化されたコンテキストヘッダーを消費する権利がある場合、NSH対応SFまたはSFCプロキシは（k）を使用してメタデータと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 (Section 2.2 of [RFC5116]).
認証された暗号化アルゴリズムには、入力が本物ではないことを示す平文または特別なシンボル（FAIL）のいずれかが単一の出力しかありません（[RFC5116]のセクション2.2）。
The SFC architecture prescribes that additional information be added to packets to:
SFCアーキテクチャは、追加情報がパケットに追加されることを規定しています。
* Identify SFPs: this is typically the NSH Base Header and Service Path Header.
* SFPSを識別する：これは通常NSHベースヘッダーおよびサービスパスヘッダーです。
* Carry metadata such as that defined in Section 5.
* セクション5で定義されているようなメタデータを運びます。
* Steer the traffic along the SFPs: This is realized by means of transport encapsulation.
* SFPに沿ってトラフィックを操縦します。これはトランスポートカプセル化によって実現されます。
This added information increases the size of the packet to be carried along an SFP.
この追加された情報は、SFPに沿って運ばれるパケットのサイズを増加させる。
Aligned with Section 5 of [RFC8300], 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.
[RFC8300]のセクション5と整列されているため、NSHトラフィックが断片化なしでSFC対応ドメイン内で転送されるように、ネットワークオペレータが基礎となるMTUを増やすことをお勧めします。利用可能な基礎となるMTUは、SFSをSFPごとに注入されるSFSとこれらのコンテキストヘッダーで実行されるデータのサイズを提供する場合に、ネットワーク事業者によって考慮されるべきです。
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 (Section 5.6 of [RFC7665]).
下にあるMTUをNSHオーバーヘッドに対応するために増やすことができない場合、ネットワーク事業者は必要な断片化処理を用いてトランスポートカプセル化プロトコルに頼ることがある。このような機能をSFFに起動することの影響は、ネットワーク事業者によって慎重に評価されるべきです（[RFC7665]のセクション5.6）。
When dealing with MTU issues, network operators should consider the limitations of various tunnel mechanisms such as those discussed in [INTERNET-IP-TUNNELS].
MTUの問題を扱う場合、ネットワーク事業者は[Internet-IP-Tunnels]で説明されているものなど、さまざまなトンネルメカニズムの制限を考慮する必要があります。
Data plane SFC-related security considerations, including privacy, are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. In particular, Section 8.2.2 of [RFC8300] 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 [RFC8165] discusses metadata considerations that operators can take into account when using NSH.
プライバシーを含むデータプレーンSFC関連のセキュリティ上の考慮事項については、[RFC7665]のセクション6と[RFC8300]のセクション8で説明しています。特に、[RFC8300]のセクション8.2.2は、接続されたメタデータ（すなわちコンテキストヘッダ）がSFPの正しい動作に必要なものに限定されるべきであると述べている。また、そのセクションは、[RFC8165]がNSHを使用するときにオペレータが考慮に入れることができるメタデータの考慮事項を説明することを示しています。
The guidelines for cryptographic key management are discussed in [RFC4107]. The group key management protocol-related security considerations discussed in Section 8 of [RFC4046] need to be taken into consideration.
暗号鍵管理のガイドラインは[RFC4107]で説明されています。[RFC4046]のセクション8で説明したグループ鍵管理プロトコル関連のセキュリティ上の考慮事項を考慮する必要があります。
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.
SFCデータプレーン要素と鍵管理システムとの間の相互作用は、この文書で定義されている整合性保護ソリューションのセキュリティ上の利点を完全に破壊するため、暗号化されていない必要はありません。
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 [AEAD-LIMITS].
秘密鍵（k）は、鍵がNSHデータの完全性保護およびコンテキストヘッダの暗号化のために鍵を使用することができる最新の時点として割り当てられた有効期限を有する必要がある。秘密鍵の有効期限が切れる前に、すべての参加NSH対応ノードは、秘密鍵が期限切れになると、それらのノードが新しい秘密鍵で準備されているように、管理プレーンが新しいキー識別子と関連するキーイング資料を配布する必要があります。これにより、NSH Imposerは必要に応じて早く新しいキー識別子に切り替えることができます。次のキー識別子と関連するキーイング材料は、秘密鍵の有効期限の前に、制御プレーンによって順調に配布されることをお勧めします。Rekingに関するAEAD機能のユーザーのための追加のガイダンスは[aead-limits]にあります。
The security and integrity of the key-distribution mechanism is vital to the security of the SFC system as a whole.
鍵配布メカニズムのセキュリティと完全性は、SFCシステム全体のセキュリティにとって不可欠です。
NSH data is exposed to several threats:
NSHデータはいくつかの脅威にさらされています。
* An on-path attacker modifying the NSH data.
* NSHデータを変更するオンパネル攻撃者。
* An attacker spoofing the NSH data.
* NSHデータを偽装する攻撃者。
* An attacker capturing and replaying the NSH data.
* 攻撃者はNSHデータをキャプチャして再生します。
* 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.
* 攻撃者は、NSHが修正されたまたは偽のパケットで課されるパケットを置き換えます。
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.
上記の攻撃が可能なSFC対応ドメインでは、（1）NSHデータは整合性保護されている必要があります。（2）プライバシーに敏感なNSHメタデータは、機密保持の目的で暗号化されている必要があります。ベースおよびサービスパスヘッダーは暗号化されていません。
MACs with two levels of assurance are defined in Section 5. Considerations specific to each level of assurance are discussed in Sections 9.1 and 9.2.
2レベルの保証を持つMACはセクション5で定義されています。保証の各レベルに固有の考慮事項は、セクション9.1および9.2で説明されています。
The attacks discussed in [ARCH-SFC-THREATS] 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.
[Arch-SFC-SFC-SFC-Threats]で説明されている攻撃は、パケットの削除を除いて、このドキュメントで指定されたソリューションに基づいて処理されます。そのような攻撃は統計分析に頼ることによって検出することができる。このような分析はこの文書の範囲外です。また、SFFSが整合性チェックに関与していない場合、完全性チェックが失敗するため、SF（SFバイパス攻撃）がSF（SFバイパス攻撃）によって行われるべきでは、SIを減らす不正行為SFFが検出されます。
Some events are logged locally with notification alerts sent by NSH-aware nodes to a Control Element. These events SHOULD be rate limited.
いくつかのイベントは、NSH対応ノードによって制御要素に送信された通知アラートでローカルに記録されます。これらのイベントはレート制限されるべきです。
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.
妥協されたノードを検出するためには、SFC対応ドメインを監視および監査するための適切なメカニズムが、不正行為を検出し、誤用を検出するために誤っていると仮定されます。したがって、適切な制御プレーンメカニズムを使用して、妥協されたノードをアクティブなサービス機能チェーンから引き出すことができます。
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.
アクティブな攻撃者は、ベースヘッダを潜在的に変更することができます（たとえば、SFPの次のSFFがNSHパケットを破棄するため、TTLを減少させるため）。アクティブな攻撃者は通常、NSHパケットも削除できます。このように、この攻撃は文書で指定されたセキュリティメカニズムに対する攻撃とは見なされません。
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 (Section 7.1), 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 (Section 7.1). 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.
SFC対応ドメイン内の特定のデバイスは、分類子以外のデバイス（再分類が有効になっている場合）、NSH対応のSFS、およびSFCプロキシが整合性保護されたNSHデータを更新できるように設定されます。セクション7.1）、およびNSH対応のSFSおよびSFCプロキシ以外のデバイスは、機密メタデータを伝えるコンテキストヘッダーを復号化して更新できません（セクション7.1）。つまり、SFC対応ドメイン内のNSH対応のSFSおよびSFCプロキシは、NSHデータに対して行動するために完全に信頼されていると見なされることが予想されます。これらの要素のみが敏感なNSHメタデータにアクセスできる場合があり、Integrityに使用されるキーイングマテリアルはNSHデータを保護し、コンテキストヘッダーを暗号化します。
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 Section 7.1).
SFFSは、不正なノードがベースヘッダーの内容を変更したかどうかを検出できます。そのようなメッセージは、適切なログと生成されたアラームで破棄されなければなりません（セクション7.1参照）。
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 update the Context Headers carrying sensitive metadata.
セクション9.1と同様に、SFC対応ドメイン内のNSH対応のSFSおよびSFCプロキシ以外のデバイスは、機密メタデータを伝えるコンテキストヘッダーを復号化および更新できるはずです。
[RFC8633] describes best current practices to be considered in deployments where SFC data plane elements use NTP for time-synchronization purposes.
[RFC8633]は、SFCデータプレーン要素が時刻同期の目的でNTPを使用する展開で考慮される最良の現在の方法を説明しています。
Also, a mechanism to provide cryptographic security for NTP is specified in [RFC8915].
また、[RFC8915]にNTPの暗号化セキュリティを提供するメカニズムが指定されています。
IANA has added the following types to the "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry (0x0000 IETF Base NSH MD Class) at <https://www.iana.org/assignments/nsh>.
IANAは、<https://www.iana.org/assignments/nsh>で、 "NSH IETF-割り当てられたオプションの可変長メタデータ型"レジストリ（0x0000 IETFベースNSH MDクラス）に次のタイプを追加しました。
+=======+===============================+===========+
| Value | Description | Reference |
+=======+===============================+===========+
| 0x02 | MAC and Encrypted Metadata #1 | RFC 9145 |
+-------+-------------------------------+-----------+
| 0x03 | MAC and Encrypted Metadata #2 | RFC 9145 |
+-------+-------------------------------+-----------+
Table 4: Additions to the NSH IETF-Assigned Optional Variable-Length Metadata Types Registry
表4：NSH IETFが割り当てられたオプションの可変長メタデータ型レジストリへの追加
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.
[GCM] DWICHIN、M。、「ブロック暗号化モードのための推奨：ガロア/カウンタモード（GCM）およびGMAC」、NIST特別出版物800-38D、DOI 10.6028 / NIST.SP.800-38D、2007年11月、<https://doi.org/10.6028/nist.sp.800-38D>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Belleare、M.、およびR. Canetti、 "HMAC：メッセージ認証のための鍵付きハッシング"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.org / info / rfc2104>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4107] Bellovin、S.およびR. Housley、「暗号鍵管理のためのガイドライン」、BCP 107、RFC 4107、DOI 10.17487 / RFC4107、2005年6月、<https://www.rfc-editor.org/info/rfc4107>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.
[RFC4868] Kelly、S.およびS. Frankel、「HMAC-SHA-256、HMAC-SHA-384、およびIPSecおよびHMAC-SHA-512を使用する」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<https：//www.rfc-editor.org/info/rfc4868>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116] MCGREW、D.、「認証済み暗号化のためのインタフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https://www.rfc-editor.org/info/rfc5116>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、ED。C. Pignataro、Ed。、「サービス機能連鎖（SFC）アーキテクチャ」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https：//www.rfc-editor.org/info/rfc7665>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300] Quinn、P.、Ed。、Elzur、U.、Ed。、およびC. Pignataro、Ed。、「ネットワークサービスヘッダ（NSH）」、RFC 8300、DOI 10.17487 / RFC8300、2018年1月、<https：//www.rfc-editor.org/info/rfc8300>。
[AEAD-LIMITS] Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-03, 12 July 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-03>.
[AEAD-LIMITS]Günther、F.、Thomson、M.、およびCA Wood、「AEDアルゴリズムの使用制限」、進行中の作業、インターネットドラフト、ドラフト-IRTF-CFRG-AEAD-LIMITS-03,2021、<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-03>。
[ARCH-SFC-THREATS] THANG, N. C. and M. Park, "A Security Architecture Against Service Function Chaining Threats", Work in Progress, Internet-Draft, draft-nguyen-sfc-security-architecture-00, 24 November 2019, <https://datatracker.ietf.org/doc/html/ draft-nguyen-sfc-security-architecture-00>.
[ARCH-SFC-SFC-SFC-SFC-SFC、M.公園、「サービス機能の連鎖脅威に対するセキュリティアーキテクチャ」、進捗状況、インターネットドラフト、ドラフト - NGUYEN-SFC - Security-Architecture-00,24月24日、<https://datatracker.ietf.org/doc/html/ romft-nguyen-sfc-security-archite-00>。
[INTERNET-IP-TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, Internet-Draft, draft-ietf-intarea-tunnels-10, 12 September 2019, <https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-10>.
[Internet-IP-Tunnels] Touch、J.およびM. Townsley、「インターネットアーキテクチャのIPトンネル」、進行中の作業、インターネットドラフト、ドラフト - IETF-Intarea-Tunnels-10,12,12、<HTTPS：//datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-10>。
[INTERNET-THREAT-MODEL] Arkko, J. and S. Farrell, "Challenges and Changes in the Internet Threat Model", Work in Progress, Internet-Draft, draft-arkko-farrell-arch-model-t-04, 13 July 2020, <https://datatracker.ietf.org/doc/html/draft-arkko-farrell-arch-model-t-04>.
[インターネット脅威モデル] Arkko、J.およびS. Farrell、「インターネット脅威モデルの課題と変化」、進行中の作業、インターネットドラフト、arkko-farrell-arch-model-t-04,132020年7月、<https://datatracker.ietf.org/doc/html/draft-arkko-farrell-arch-model-t-04>。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, <https://www.rfc-editor.org/info/rfc4046>.
[RFC4046] Baugher、M.、Canetti、R.、Dondeti、L.、およびF. Lindholm、「マルチキャストセキュリティ（MSEC）グループ鍵管理アーキテクチャ」、RFC 4046、DOI 10.17487 / RFC4046、2005年4月、<https：//www.rfc-editor.org/info/rfc4046>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルに関するプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S.およびH.Schofenig、「Pervasive Monitoringは攻撃である」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https：//www.rfc-editor.org/info/rfc7258>。
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7498] QUINN、P、ED。2015年4月、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc7498、<https://www.rfc-editor.org/info/rfc7498、<https://www.rfc-editor.org/info/rfc7498>。
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, <https://www.rfc-editor.org/info/rfc7635>.
[RFC7635] Reddy、T.、Patil、P.、Ravindranath、R.、およびJ.Uberti、「第三者承認のためのNAT（STUN）拡張（STUN）拡張のためのセッショントラバーサルユーティリティ、RFC 7635、DOI 10.17487 / RFC7635、2015年8月、<https://www.rfc-editor.org/info/rfc7635>。
[RFC8165] Hardie, T., "Design Considerations for Metadata Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, <https://www.rfc-editor.org/info/rfc8165>.
[RFC8165] hardie、T.、「メタデータ挿入の設計上の考慮事項」、RFC 8165、DOI 10.17487 / RFC8165、2017年5月、<https：//www.rfc-editor.org/info/rfc8165>。
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 10.17487/RFC8459, September 2018, <https://www.rfc-editor.org/info/rfc8459>.
[RFC8459] Dolson、D.、Homma、S.、Lopez、D.、およびM.Boucadair、「階層サービス機能連鎖（HSFC）」、RFC 8459、DOI 10.17487 / RFC8459、2018年9月、<HTTPS：// WWW.rfc-editor.org / info / rfc8459>。
[RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time Protocol Best Current Practices", BCP 223, RFC 8633, DOI 10.17487/RFC8633, July 2019, <https://www.rfc-editor.org/info/rfc8633>.
[RFC8633] REILLY、D.、STENN、H.、およびD.SIBOLD、「ネットワークタイムプロトコルの最良のプラクティス」、BCP 223、RFC 8633、DOI 10.17487 / RFC8633、2019年7月、<https：//www.rfc-editor.org/info/rfc8633>。
[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Defining Packet Timestamps", RFC 8877, DOI 10.17487/RFC8877, September 2020, <https://www.rfc-editor.org/info/rfc8877>.
[RFC8877] Mizrahi、T.、Fabini、J.、およびA.モートン、「パケットタイムスタンプを定義するためのガイドライン」、RFC 8877、DOI 10.17487 / RFC8877、2020年9月、<https://www.rfc-editor.org/情報/ RFC8877>。
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, <https://www.rfc-editor.org/info/rfc8915>.
[RFC8915] Franke、D.、Sibold、D.、Teichel、K.、Dansarie、M.、およびR.Sundblad、「ネットワークタイムプロトコルのためのネットワークタイムセキュリティ」、RFC 8915、DOI 10.17487 / RFC8915、2020年9月、<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).
この文書は、IETF 104での議論の後続として作成されました。）。
Thanks to Joel Halpern, Christian Jacquenet, Dirk von Hugo, Tal Mizrahi, Daniel Migault, Diego Lopez, Greg Mirsky, and Dhruv Dhody for the comments.
Joel Halpern、Christian Jacquenet、Dirk von Hugo、Tal Mizrahi、Daniel Migault、Diego Lopez、Greg Migrsky、Dhruv Dhodyのおかげで、コメントのためのDhruv Dhody。
Many thanks to Steve Hanna for the valuable secdir review and Juergen Schoenwaelder for the opsdir review.
貴重なSecdir ReviewとJuergen Schoenwaelder for opsdirレビューのためのSteve Hannaに感謝します。
Thanks to Greg Mirsky for the Shepherd review.
羊飼いのレビューのためのGreg Mirskyに感謝します。
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.
Alvaro retana、Lars Egger、Martin Duke、Martin Duke、Erik Kline、ザハドッサマンサルカー、エリックklincke、ローマのダニリワ、Murray Kucherawy、John Scudder、およびBenjamin Kadukのおかげで、IESGレビュー
Authors' Addresses
著者の住所
Mohamed Boucadair Orange 35000 Rennes France
Mohamed Boucadair Orange 35000 Rennesフランス
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K Akamai Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Tirumaleswar Reddy.kアカマイ大使館ゴルフリンクビジネスパークバンガロール560071カルナタカインド
Email: kondtir@gmail.com
Dan Wing Citrix Systems, Inc. United States of America
Dan Wing Citrix Systems、Inc。アメリカ合衆国
Email: dwing-ietf@fuggles.com