[要約] RFC 9192は、Network Service Header (NSH)の固定長コンテキストヘッダー割り当てに関する文書です。この文書の目的は、ネットワークサービスチェーン内でのメタデータの効率的な伝達を可能にするための標準化された方法を提供することです。利用場面としては、サービス指向のネットワークアーキテクチャにおいて、異なるネットワーク機能間でのメタデータの交換をサポートする場合に適用されます。
Independent Submission T. Mizrahi
Request for Comments: 9192 Huawei
Category: Informational I. Yerushalmi
ISSN: 2070-1721 D. Melman
Marvell
R. Browne
Intel
February 2022
Network Service Header (NSH) Fixed-Length Context Header Allocation
ネットワークサービスヘッダ（NSH）固定長コンテキストヘッダ割り当て
Abstract
概要
The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 0x1 uses a fixed-length Context Header. The allocation of this Context Header, i.e., its structure and semantics, has not been standardized. This memo defines the Timestamp Context Header, which is an NSH fixed-length Context Header that incorporates the packet's timestamp, a sequence number, and a source interface identifier.
ネットワークサービスヘッダ（NSH）仕様は、メタデータ（MD）を含める2つの可能なメソッドを定義します.MDタイプ0x1とMDタイプ0x2。MDタイプ0x1は固定長コンテキストヘッダを使用します。このコンテキストヘッダ、すなわちその構造および意味論の割り当ては、標準化されていない。このメモは、パケットのタイムスタンプ、シーケンス番号、およびソースインターフェイス識別子を組み込んだNSH固定長コンテキストヘッダーであるTimesTampコンテキストヘッダーを定義します。
Although the definition of the Context Header presented in this document has not been standardized by the IETF, it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability.
この文書に提示されたコンテキストヘッダの定義はIETFによって標準化されていないが、それはいくつかの製造業者によってシリコン内に実装されており、そして相互運用性を促進するためにここで公開されている。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディタは、この文書をその判断で公開することを選択し、実装または展開の値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補ではありません。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/rfc9192.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/frfc9192で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Requirements Language
2.2. Abbreviations
3. NSH Timestamp Context Header Allocation
4. Timestamping Use Cases
4.1. Network Analytics
4.2. Alternate Marking
4.3. Consistent Updates
5. Synchronization Considerations
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
The Network Service Header (NSH), defined in [RFC8300], is an encapsulation header that is used as the service encapsulation in the Service Function Chaining (SFC) architecture [RFC7665].
[RFC8300]で定義されているネットワークサービスヘッダ（NSH）は、サービス関数連鎖（SFC）アーキテクチャ[RFC7665]のサービスカプセル化として使用されるカプセル化ヘッダーです。
In order to share metadata (MD) along a service path, the NSH specification [RFC8300] supports two methods: a fixed-length Context Header (MD Type 0x1) and a variable-length Context Header (MD Type 0x2). When using MD Type 0x1, the NSH includes 16 octets of Context Header fields.
サービスパスに沿ってメタデータ（MD）を共有するために、NSH仕様[RFC8300]は、固定長コンテキストヘッダ（MDタイプ0x1）と可変長コンテキストヘッダ（MDタイプ0x2）の2つの方法をサポートしています。MD Type 0x1を使用すると、NSHは16オクテットのコンテキストヘッダーフィールドを含みます。
The NSH specification [RFC8300] has not defined the semantics of the 16-octet Context Header, nor does it specify how the Context Header is used by NSH-aware Service Functions (SFs), Service Function Forwarders (SFFs), and proxies. Several Context Header formats are defined in [NSH-TLV]. Furthermore, some allocation schemes were proposed in the past to accommodate specific use cases, e.g., [NSH-DC-ALLOC], [NSH-BROADBAND-ALLOC], and [RFC8592].
NSH仕様[RFC8300]は、16 OCTETコンテキストヘッダーのセマンティクスを定義していません。また、NSH対応サービス関数（SFS）、サービス機能フォワーダ（SFF）、およびプロキシでコンテキストヘッダーの使用方法を指定していません。[NSH-TLV]でいくつかのコンテキストヘッダーフォーマットが定義されています。さらに、特定のユースケース、例えば[NSH-DC-ALLOC]、[NSH-BOADBAND-ALOW]、および[RFC8592]、および[RFC8592]、および[RFC8592]、いくつかの割り当て方式が過去に提案されています。
This memo presents an allocation for the MD Type 0x1 Context Header, which incorporates the timestamp of the packet, a sequence number, and a source interface identifier. Note that other allocation schema for MD Type 0x1 might be specified in the future. Although such schema are currently not being standardized by the SFC Working Group, a consistent format (allocation schema) should be used in an SFC-enabled domain in order to allow interoperability.
このメモは、パケットのタイムスタンプ、シーケンス番号、およびソースインターフェイス識別子を組み込んだMDタイプ0x1コンテキストヘッダの割り当てを示しています。MDタイプ0x1の他の割り当てスキーマは、将来指定される可能性があります。そのようなスキーマは現在SFCワーキンググループによって標準化されていませんが、相互運用性を可能にするために、一貫したフォーマット（割り当てスキーマ）をSFC対応ドメインで使用する必要があります。
In a nutshell, packets that enter the SFC-enabled domain are timestamped by a classifier [RFC7665]. Thus, the timestamp, sequence number, and source interface are incorporated in the NSH Context Header. As discussed in [RFC8300], if reclassification is used, it may result in an update to the NSH metadata. Specifically, when the Timestamp Context Header is used, a reclassifier may either leave it unchanged or update the three fields: Timestamp, Sequence Number, and Source Interface.
NutShellでは、SFC対応ドメインに入るパケットは、分類子[RFC7665]によってタイムスタンプされます。したがって、タイムスタンプ、シーケンス番号、およびソースインタフェースは、NSHコンテキストヘッダに組み込まれています。[RFC8300]で説明したように、再分類が使用されている場合、それはNSHメタデータを更新する可能性があります。具体的には、タイムスタンプコンテキストヘッダを使用すると、再分類器はそれを変更しなくても、タイムスタンプ、シーケンス番号、およびソースインタフェースの3つのフィールドを変更したり更新したりすることがあります。
The Timestamp Context Header includes three fields that may be used for various purposes. The Timestamp field may be used for logging, troubleshooting, delay measurement, packet marking for performance monitoring, and timestamp-based policies. The source interface identifier indicates the interface through which the packet was received at the classifier. This identifier may specify a physical interface or a virtual interface. The sequence numbers can be used by SFs to detect out-of-order delivery or duplicate transmissions. Note that out-of-order and duplicate packet detection is possible when packets are received by the same SF but is not necessarily possible when there are multiple instances of the same SF and multiple packets are spread across different instances of the SF. The sequence number is maintained on a per-source-interface basis.
タイムスタンプコンテキストヘッダには、さまざまな目的に使用できる3つのフィールドが含まれています。タイムスタンプフィールドは、ロギング、トラブルシューティング、遅延測定、パフォーマンスモニタリングのパケットマーキング、およびタイムスタンプベースのポリシーに使用できます。ソースインタフェース識別子は、パケットが分類子で受信されたインターフェースを示す。この識別子は、物理インターフェースまたは仮想インターフェイスを指定できます。シーケンス番号はSFSによって使用されて、順序外の配信または重複した送信を検出することができます。パケットが同じSFによって受信されるが、同じSFのインスタンスが複数ある場合には必ずしも可能ではなく、異なるSFの異なるインスタンスにわたってパケットが複数ある場合には必ずしも不可能である。シーケンス番号は、ソースごとのインタフェースごとに維持されます。
This document presents the Timestamp Context Header but does not specify the functionality of the SFs that receive the Context Header. Although a few possible use cases are described in this document, the SF behavior and application are outside the scope of this document.
このドキュメントはタイムスタンプコンテキストヘッダを提示しますが、コンテキストヘッダーを受信するSFSの機能を指定しません。この文書にはいくつかの可能なユースケースが記載されていますが、SFの動作とアプリケーションはこの文書の範囲外です。
Key Performance Indicator (KPI) stamping [RFC8592] defines an NSH timestamping mechanism that uses the MD Type 0x2 format. This memo defines a compact MD Type 0x1 Context Header that does not require the packet to be extended beyond the NSH. Furthermore, the mechanisms described in [RFC8592] and this memo can be used in concert, as further discussed in Section 4.1.
キーパフォーマンスインジケータ（KPI）スタンプ[RFC8592] MDタイプ0x2フォーマットを使用するNSHタイムスタンプメカニズムを定義します。このメモは、NSHを超えてパケットを拡張する必要がないコンパクトMDタイプ0x1コンテキストヘッダを定義します。さらに、セクション4.1でさらに議論されているように、[RFC8592]に記載されているメカニズムをコンサートで使用することができる。
Although the definition of the Context Header presented in this document has not been standardized by the IETF, it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability.
この文書に提示されたコンテキストヘッダの定義はIETFによって標準化されていないが、それはいくつかの製造業者によってシリコン内に実装されており、そして相互運用性を促進するためにここで公開されている。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following abbreviations are used in this document:
この文書では、以下の略語が使用されています。
KPI Key Performance Indicator [RFC8592]
KPI鍵パフォーマンスインジケーター[RFC8592]
MD Metadata [RFC8300]
MDメタデータ[RFC8300]
NSH Network Service Header [RFC8300]
NSHネットワークサービスヘッダ[RFC8300]
SF Service Function [RFC7665]
SFサービス機能[RFC7665]
SFC Service Function Chaining [RFC7665]
SFCサービス機能チェーン[RFC7665]
SFF Service Function Forwarder [RFC8300]
SFFサービス機能フォワーダ[RFC8300]
This memo defines the following fixed-length Context Header allocation, as presented in Figure 1.
このメモは、図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NSH Timestamp Allocation
図1：NSHタイムスタンプの割り当て
The NSH Timestamp allocation defined in this memo MUST include the following fields:
このメモに定義されているNSHタイムスタンプ割り当てには、次のフィールドを含める必要があります。
Sequence Number: A 32-bit sequence number. The sequence number is maintained on a per-source-interface basis. Sequence numbers can be used by SFs to detect out-of-order delivery or duplicate transmissions. The classifier increments the sequence number by 1 for each packet received through the source interface. This requires the classifier to maintain a per-source-interface counter. The sequence number is initialized to a random number on startup. After it reaches its maximal value (2^32-1), the sequence number wraps around back to zero.
シーケンス番号：32ビットシーケンス番号。シーケンス番号は、ソースごとのインタフェースごとに維持されます。シーケンス番号はSFSによって使用され、順序の順序の配信または重複送信を検出できます。分類器は、ソースインタフェースを介して受信された各パケットについてシーケンス番号を1だけインクリメントします。これは、ソースインターフェイスカウンタを維持するために分類子を必要とする。シーケンス番号は起動時に乱数に初期化されます。最大値に達すると（2 ^ 32-1）、シーケンス番号はゼロに戻ります。
Source Interface: A 32-bit source interface identifier that is assigned by the classifier. The combination of the source interface and the classifier identity is unique within the context of an SFC-enabled domain. Thus, in order for an SF to be able to use the source interface as a unique identifier, the identity of the classifier needs to be known for each packet. The source interface is unique in the context of the given classifier.
ソースインタフェース：分類子によって割り当てられている32ビットのソースインターフェイス識別子。ソースインタフェースと分類子IDの組み合わせは、SFC対応ドメインのコンテキスト内で一意です。したがって、SFがソースインタフェースを一意の識別子として使用できるようにするためには、分類器の識別情報は各パケットについて知る必要がある。ソースインタフェースは、指定された分類子のコンテキスト内で一意です。
Timestamp: A 64-bit field that specifies the time at which the packet was received by the classifier. Two possible timestamp formats can be used for this field: the two 64-bit recommended formats specified in [RFC8877]. One of the formats is based on the timestamp format defined in [IEEE1588], and the other is based on the format defined in [RFC5905].
タイムスタンプ：パケットが分類子によって受信された時刻を指定する64ビットフィールド。このフィールドには、2つのタイムスタンプ形式を使用できます。[RFC8877]に指定されている2つの64ビット推奨フォーマット。フォーマットの1つは[IEEE1588]で定義されているタイムスタンプ形式に基づいており、もう1つは[RFC5905]で定義されている形式に基づいています。
The NSH specification [RFC8300] does not specify the possible coexistence of multiple MD Type 0x1 Context Header formats in a single SFC-enabled domain. It is assumed that the Timestamp Context Header will be deployed in an SFC-enabled domain that uniquely uses this Context Header format. Thus, operators SHOULD ensure that either a consistent Context Header format is used in the SFC-enabled domain or there is a clear policy that allows SFs to know the Context Header format of each packet. Specifically, operators are expected to ensure the consistent use of a timestamp format across the whole SFC-enabled domain.
NSH仕様[RFC8300]は、単一のSFC対応ドメイン内の複数のMDタイプ0x1コンテキストヘッダーフォーマットの可能な可能な共存を指定しません。このコンテキストヘッダフォーマットを一意に使用するSFC対応ドメインにタイムスタンプコンテキストヘッダがデプロイされると仮定する。したがって、演算子は、SFC対応ドメインで一貫したコンテキストヘッダフォーマットが使用されているか、SFSが各パケットのコンテキストヘッダフォーマットを知ることを可能にするクリアポリシーがあることを確認する必要があります。具体的には、演算子は、SFC対応ドメイン全体でタイムスタンプフォーマットを一貫した使用することを保証することが期待されています。
The two timestamp formats that can be used in the Timestamp field are as follows:
TimesTampフィールドで使用できる2つのタイムスタンプフォーマットは次のとおりです。
Truncated Timestamp Format [IEEE1588]: This format is specified in Section 4.3 of [RFC8877]. For the reader's convenience, this format is illustrated in Figure 2.
切り捨てられたタイムスタンプフォーマット[IEEE1588]：[RFC8877]のセクション4.3で指定されています。読者の利便性については、このフォーマットを図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Truncated Timestamp Format (IEEE 1588)
図2：切り捨てられたタイムスタンプ形式（IEEE 1588）
NTP 64-bit Timestamp Format [RFC5905]: This format is specified in Section 4.2.1 of [RFC8877]. For the reader's convenience, this format is illustrated in Figure 3.
NTP 64ビットタイムスタンプフォーマット[RFC5905]：このフォーマットは[RFC8877]の4.2.1項で指定されています。読者の利便性については、このフォーマットを図3に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP 64-Bit Timestamp Format (RFC 5905)
図3：NTP 64ビットタイムスタンプフォーマット（RFC 5905）
Synchronization aspects of the timestamp format in the context of the NSH Timestamp allocation are discussed in Section 5.
NSHタイムスタンプ割り当てのコンテキストにおけるタイムスタンプフォーマットの同期態様は、セクション5で説明されています。
Per-packet timestamping enables coarse-grained monitoring of network delays along the Service Function Chain. Once a potential problem or bottleneck is detected (for example, when the delay exceeds a certain policy), a highly granular monitoring mechanism can be triggered (for example, using the hop-by-hop measurement data defined in [RFC8592] or [IOAM-DATA]), allowing analysis and localization of the problem.
パケットごとのタイムスタンプ化により、サービス機能チェーンに沿ったネットワーク遅延の粗粒監視が可能になります。潜在的な問題またはボトルネックが検出されると（例えば、遅延があるポリシーを超えると）、非常に粒状の監視メカニズムをトリガすることができます（たとえば、[RFC8592]または[IOAMで定義されているホップごとの測定データを使用して）。-Data]）、問題の分析とローカライズを可能にします。
Timestamping is also useful for logging, troubleshooting, and flow analytics. It is often useful to maintain the timestamp of the first and last packet of the flow. Furthermore, traffic mirroring and sampling often require a timestamp to be attached to analyzed packets. Attaching the timestamp to the NSH provides an in-band common time reference that can be used for various network analytics applications.
タイムスタンプ化は、ロギング、トラブルシューティング、およびフロー分析にも役立ちます。フローの最初と最後のパケットのタイムスタンプを維持することはしばしば有用です。さらに、交通ミラーリングとサンプリングは、分析されたパケットにタイムスタンプを取り付けることを必要とします。タイムスタンプをNSHに接続すると、さまざまなネットワーク分析アプリケーションに使用できるインバンドの共通時間参照があります。
A possible approach for passive performance monitoring is to use an Alternate-Marking Method [RFC8321]. This method requires data packets to carry a field that marks (colors) the traffic, and enables passive measurement of packet loss, delay, and delay variation. The value of this marking field is periodically toggled between two values.
受動的性能監視の可能なアプローチは、代替マーキング方法[RFC8321]を使用することです。この方法では、データパケットがトラフィックをマーク（色）するフィールドを運ぶために、パケット損失、遅延、および遅延変動のパッシブ測定を可能にします。このマーキングフィールドの値は、2つの値の間で周期的に切り替わります。
When the timestamp is incorporated in the NSH, it can intrinsically be used for Alternate Marking. For example, the least significant bit of the timestamp Seconds field can be used for this purpose, since the value of this bit is inherently toggled every second.
タイムスタンプがNSHに組み込まれると、代替マーキングに本質的に使用できます。例えば、このビットの値は本質的に毎秒切り替えられるので、この目的のためにタイムスタンプ秒フィールドの最下位ビットを使用することができる。
The timestamp can be used for making policy decisions, such as 'Perform action A if timestamp>=T_0'. This can be used for enforcing time-of-day policies or periodic policies in SFs. Furthermore, timestamp-based policies can be used for enforcing consistent network updates, as discussed in [DPT]. It should be noted that, as in the case of Alternate Marking, this use case alone does not require a full 64-bit timestamp but could be implemented with a significantly smaller number of bits.
タイムスタンプは、「TimesTamp> = T_0」の場合は「アクションAの実行」など、ポリシーの決定を行うために使用できます。これは、SFSの日時ポリシーまたは定期的なポリシーを強制するために使用できます。さらに、[DPT]で説明したように、一貫したネットワークアップデートを強制するためにタイムスタンプベースのポリシーを使用できます。代替マーキングの場合のように、このユースケースだけでは全64ビットのタイムスタンプを必要としないが、かなり少ないビット数で実装することができることに留意されたい。
Some of the applications that make use of the timestamp require the classifier and SFs to be synchronized to a common time reference -- for example, using the Network Time Protocol [RFC5905] or the Precision Time Protocol [IEEE1588]. Although it is not a requirement to use a clock synchronization mechanism, it is expected that, depending on the applications that use the timestamp, such synchronization mechanisms will be used in most deployments that use the Timestamp allocation.
タイムスタンプを利用するアプリケーションのいくつかは、ネットワークタイムプロトコル[RFC5905]または精度時間プロトコル[IEEE1588]を使用して、分類子とSFSを共通の時間基準に同期させる必要があります。クロック同期メカニズムを使用する必要性ではありませんが、タイムスタンプを使用するアプリケーションに応じて、そのような同期メカニズムがタイムスタンプ割り当てを使用するほとんどの展開で使用されます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The security considerations for the NSH in general are discussed in [RFC8300]. The NSH is typically run within a confined trust domain. However, if a trust domain is not enough to provide the operator with protection against the timestamp threats as described below, then the operator SHOULD use transport-level protection between SFC processing nodes as described in [RFC8300].
NSHのセキュリティ上の考慮事項一般は[RFC8300]で説明されています。NSHは通常、限られた信頼ドメイン内で実行されます。ただし、信頼ドメインが以下のようにタイムスタンプの脅威に対する保護を伴うオペレータに十分ではない場合、オペレータは[RFC8300]に記載されているようにSFC処理ノード間のトランスポートレベルの保護を使用する必要があります。
The security considerations of in-band timestamping in the context of the NSH are discussed in [RFC8592]; this section is based on that discussion.
NSHの文脈におけるインバンドタイムスタンプのセキュリティ上の考慮事項は[RFC8592]で説明されています。このセクションはその議論に基づいています。
In-band timestamping, as defined in this document and [RFC8592], can be used as a means for network reconnaissance. By passively eavesdropping on timestamped traffic, an attacker can gather information about network delays and performance bottlenecks. An on-path attacker can maliciously modify timestamps in order to attack applications that use the timestamp values, such as performance-monitoring applications.
この文書で定義されているように、帯域内タイムスタンプ化、および[RFC8592]は、ネットワーク偵察の手段として使用できます。タイムスタンプ付きトラフィックを受動的に盗聴することで、攻撃者はネットワーク遅延とパフォーマンスのボトルネックに関する情報を収集できます。パフォーマンス監視アプリケーションなどのタイムスタンプ値を使用するアプリケーションを攻撃するために、オンパス攻撃者が悪質なタイムスタンプを故意に変更できます。
Since the timestamping mechanism relies on an underlying time synchronization protocol, by attacking the time protocol an attack can potentially compromise the integrity of the NSH Timestamp. A detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC7384].
タイムスタンプメカニズムは、時間プロトコルを攻撃することによって、攻撃がNSHタイムスタンプの完全性を損なう可能性がある可能性があるため、攻撃に依存しているためです。時間プロトコルに対する脅威とそれらを軽減する方法についての詳細な説明が[RFC7384]に提示されます。
[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>。
[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>。
[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>。
[DPT] Mizrahi, T. and Y. Moses, "The Case for Data Plane Timestamping in SDN", IEEE INFOCOM Workshop on Software-Driven Flexible and Agile Networking (SWFAN), DOI 10.1109/INFCOMW.2016.7562197, 2016, <https://ieeexplore.ieee.org/document/7562197>.
[DPT] Mizrahi、T.およびY.モーセ、「SDNにおけるデータプレーンのタイムスタンプの場合は、SDNでのTIMESTANGINGの場合」、ソフトウェア駆動型フレキシブルおよびアジャイルネットワーキング（SWFAN）、DOI 10.1109 / INFCOMW.2016.7562197,2016、<https：///ieeexplore.ieee.org/document/7562197>。
[IEEE1588] IEEE, "IEEE 1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", DOI 10.1109/IEEESTD.2008.4579760, <https://standards.ieee.org/standard/1588-2008.html>.
[IEEE1588] IEEE、「IEEE 1588-2008 - ネットワーク測定システム用精密クロック同期プロトコルのためのIEEE規格」、DOI 10.1109 / IEEESTD.2008.4579760、<https：//tandards.ieee.org/standard/1588-2008.html>。
[IOAM-DATA] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-17, 13 December 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-17>.
[IOAM-DATA]ブロック、F、ED。、Bhandari、S.、Ed。、およびT.Mizrahi、ed。、「その場OAMのデータフィールド」、進行中の作業、インターネットドラフト、ドラフトIETF-ippm-ioam-data-17、2021年12月13日、<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-17>。
[NSH-BROADBAND-ALLOC] Napper, J., Kumar, S., Muley, P., Hendericks, W., and M. Boucadair, "NSH Context Header Allocation for Broadband", Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-broadband-allocation-01, 19 June 2018, <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-broadband-allocation-01>.
[NSH-Broadband-Alloc] Napper、J.、Kumar、S.、M. Boucadair、W.およびM. Boucadair、「ブロードバンドのためのNSHコンテキストヘッダー割り当て」、進行中、インターネットドラフト、ドラフト-ietf-sfc-nsh-broadband-allocation-01、<https：//datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-broadband-allocation-01>。
[NSH-DC-ALLOC] Guichard, J., Ed., Smith, M., Kumar, S., Majee, S., and T. Mizrahi, "Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)", Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25 September 2018, <https://datatracker.ietf.org/doc/html/ draft-ietf-sfc-nsh-dc-allocation-02>.
[NSH-DC-alloc] Guichard、J.、Ed。、Smith、M.、Kumar、S.、Majee、S.、およびT.Mizrahi、 "Network Service Header（NSH）MDタイプ1：コンテキストヘッダの割り当て（データセンター）「、進行中の作業、インターネットドラフト、草案-IETF-SFC-NSH-DC-DC-ALLOCACTION-02,25,25、<https：//datatracker.ietf.org/doc/html/ romft-ietf-SFC-NSH-DC割り当て-02>。
[NSH-TLV] Wei, Y., Ed., Elzur, U., Majee, S., Pignataro, C., and D. Eastlake, "Network Service Header Metadata Type 2 Variable-Length Context Headers", Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-tlv-13, 26 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-13>.
[NSH-TLV] Wei、Y.、ED。、Elzur、U.、Majee、S.、Pignataro、C.、およびD.イーストレイク、「ネットワークサービスヘッダメタデータタイプ2可変長コンテキストヘッダ」、進行中の作業、インターネットドラフト、ドラフト - IETF-SFC-NSH-TLV-13,26 1月26日、<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv--13>。
[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>。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384] Mizrahi、T.、「パケット交換ネットワークにおける時間プロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https：//www.rfc-editor.org/info/rfc7384>。
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8321] Fioccola、G.、Ed。、Capello、A.、Cociglio、M.、Castaldelli、L.、Chen、M.、Zheng、L.、Mirsky、G.、T.Mizrahi、 "代替マーキングパッシブおよびハイブリッド性能監視方法、RFC 8321、DOI 10.17487 / RFC8321、2018年1月、<https：//www.rfc-editor.org/info/rfc8321>。
[RFC8592] Browne, R., Chilikin, A., and T. Mizrahi, "Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH)", RFC 8592, DOI 10.17487/RFC8592, May 2019, <https://www.rfc-editor.org/info/rfc8592>.
[RFC8592] Browne、R.、Chilikin、A。、およびT.Mizrahi、「ネットワークサービスヘッダ（NSH）」、RFC 8592、DOI 10.17487 / RFC8592、2019年5月、<HTTPS：//www.rfc-editor.org/info/rfc8592>。
Acknowledgments
謝辞
The authors thank Mohamed Boucadair and Greg Mirsky for their thorough reviews and detailed comments.
著者らは徹底的なレビューと詳細なコメントのためにMohamed BoucadairとGreg Mirskyに感謝します。
Authors' Addresses
著者の住所
Tal Mizrahi Huawei Israel Email: tal.mizrahi.phd@gmail.com
Tal Mizrahi Huaweiイスラエルメール：tal.mizrahi.phd@gmail.com
Ilan Yerushalmi Marvell 6 Hamada Yokneam 2066721 Israel Email: yilan@marvell.com
Ilan Yerushalmi Marvell 6浜田Yokneam 2066721イスラエルメール：yilan@marvell.com
David Melman Marvell 6 Hamada Yokneam 2066721 Israel Email: davidme@marvell.com
David Melman Marvell 6浜田Yokneam 2066721イスラエルメール：davidme@marvell.com
Rory Browne Intel Dromore House Shannon Co. Clare Ireland Email: rory.browne@intel.com
Rory Browne Intel Dromore House Shannon Co. Clareアイルランドメール：Rory.browne@intel.com