RFC 9333 - Minimal IP Encapsulating Security Payload (ESP) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9333.html
タイトル : RFC 9333 - セキュリティペイロードをカプセル化する最小IPカプセル（ESP）
翻訳編集 : 自動生成

[要約] RFC 9333 は、標準のESPとの互換性を保つために必要な最小限のIP Encapsulating Security Payload（ESP）の実装の特性を記述しています。最小実装は、制約のある環境に最適化されつつ、ESPの実装との互換性を維持することを目的としています。

Internet Engineering Task Force (IETF)                        D. Migault
Request for Comments: 9333                                      Ericsson
Category: Informational                                      T. Guggemos
ISSN: 2070-1721                                               LMU Munich
                                                            January 2023

Minimal IP Encapsulating Security Payload (ESP)

セキュリティペイロードをカプセル化する最小IPカプセル（ESP）

Abstract

概要

This document describes the minimal properties that an IP Encapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303. Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation.

このドキュメントでは、RFC 4303で定義されているように、標準ESPと相互運用可能なままにするために、セキュリティペイロード（ESP）の実装をカプセル化する必要がある最小プロパティについて説明しています。このような最小バージョンのESPは、RFC 4303のESPの代替品になることを意図していません。代わりに、ESPの実装と相互運用可能でありながら、最小限の実装が制約された環境に最適化されると予想されます。さらに、このドキュメントは、フラッシュの記述の数の制限、頻繁なウェイクアップおよび睡眠状態の処理、ウェイクアップ時間の制限、ランダム生成の使用の削減など、制約された環境で最小限のESPを実装するためのいくつかの考慮事項を提供します。

This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description.

このドキュメントは、RFC4303を更新または変更しません。そのプロトコルの最小バージョンを実装する方法のコンパクトな説明を提供します。RFC 4303は、権威ある説明のままです。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9333.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9333で取得できます。

著作権表示

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.

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。

Table of Contents

   1.  Introduction
   2.  Requirements Notation
   3.  Security Parameters Index (SPI)
     3.1.  Considerations for SPI Generation
   4.  Sequence Number (SN)
   5.  Padding
   6.  Next Header and "Dummy" Packets
   7.  ICV
   8.  Cryptographic Suites
   9.  IANA Considerations
   10. Security Considerations
   11. Privacy Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

ESP [RFC4303] is part of the IPsec protocol suite [RFC4301]. IPsec is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited Traffic Flow Confidentiality (TFC) padding.

ESP [RFC4303]は、IPSECプロトコルスイート[RFC4301]の一部です。IPSECは、機密性、データ起源認証、コネクションレスの完全性、アンチレプレイサービス、および限られたトラフィックフローの機密性（TFC）パディングを提供するために使用されます。

Figure 1 describes an ESP packet. Currently, ESP is implemented in the kernel of most major multipurpose Operating Systems (OSes). ESP is usually implemented with all of its features to fit the multipurpose usage of these OSes, at the expense of resources and with no considerations for code size. Constrained devices are likely to have their own implementation of ESP optimized and adapted to their specific use, such as limiting the number of flash writes (for each packet or across wake time), handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation. With the adoption of IPsec by Internet of Things (IoT) devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC) [EHC-DIET-ESP] [EHC-IKEv2], these ESP implementations MUST remain interoperable with standard ESP implementations. This document describes the minimal properties an ESP implementation needs to meet to remain interoperable with ESP [RFC4303]. In addition, this document provides advice to implementers for implementing ESP within constrained environments. This document does not update or modify [RFC4303].

図1は、ESPパケットを説明しています。現在、ESPは、ほとんどの主要な多目的オペレーティングシステム（OSES）のカーネルに実装されています。ESPは通常、リソースを犠牲にしてコードサイズを考慮せずに、これらのOSの多目的使用に適合するためにそのすべての機能を使用して実装されます。制約付きデバイスは、ESPの最適化され、特定の使用に適合した独自の実装を持つ可能性があります。たとえば、Flash Writeの数（各パケットまたはウェイクタイム全体）の制限、頻繁なウェイクアップおよび睡眠状態の取り扱い、ウェイクアップ時間の制限、減少などランダム生成の使用。IPSECのIPSEC（IoT）デバイスが最小限のIKEV2 [RFC7815]とESPヘッダー圧縮（EHC）[EHC-Diet-ESP] [EHC-Aikv2]を採用しているため、これらのESP実装は標準的なESP実装と相互運用可能でなければなりません。このドキュメントでは、ESP [RFC4303]と相互運用可能なままでいるために、ESP実装が満たす必要がある最小プロパティについて説明しています。さらに、このドキュメントは、制約された環境内でESPを実装するための実装者にアドバイスを提供します。このドキュメントでは、[RFC4303]を更新または変更しません。

For each field of the ESP packet represented in Figure 1, this document provides recommendations and guidance for minimal implementations. The primary purpose of minimal ESP is to remain interoperable with other nodes implementing ESP [RFC4303], while limiting the standard complexity of the implementation.

図1に示すESPパケットの各フィールドについて、このドキュメントは、最小限の実装に関する推奨事項とガイダンスを提供します。最小限のESPの主な目的は、実装の標準的な複雑さを制限しながら、ESP [RFC4303]を実装する他のノードと相互運用可能を維持することです。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|               Security Parameters Index (SPI)                 | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    Payload Data* (variable)                   | |   ^
~                                                               ~ |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     Padding (0-255 bytes)                     | |ered*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  Pad Length   | Next Header   | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|         Integrity Check Value (ICV) (variable)                |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: ESP Packet Description

図1：ESPパケットの説明

2. Requirements Notation

2. 要件表記

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]で説明されているように、すべて大文字の場合にのみ解釈されます。

3. Security Parameters Index (SPI)

3. セキュリティパラメーターインデックス（SPI）

[RFC4303] defines the SPI as a mandatory 32-bit field.

[RFC4303]は、SPIを必須の32ビットフィールドとして定義します。

The SPI has local significance to index the Security Association (SA). As described in Section 4.1 of [RFC4301], nodes supporting only unicast communications can index their SA using only the SPI. Nodes supporting multicast communications also require the use of IP addresses; thus, SA lookup needs to be performed using the longest match.

SPIには、セキュリティ協会（SA）にインデックスするための局所的な重要性があります。[RFC4301]のセクション4.1で説明されているように、ユニキャスト通信のみをサポートするノードは、SPIのみを使用してSAをインデックス化できます。マルチキャスト通信をサポートするノードには、IPアドレスの使用も必要です。したがって、SAルックアップは、最長の一致を使用して実行する必要があります。

For nodes supporting only unicast communications, indexing the SA using only the SPI is RECOMMENDED. The index may be based on the full 32 bits of the SPI or a subset of these bits. The node may require a combination of the SPI as well as other parameters (like the IP address) to index the SA.

ユニキャスト通信のみをサポートするノードの場合、SPIのみを使用してSAのインデックスを作成することをお勧めします。インデックスは、SPIの32ビットまたはこれらのビットのサブセットに基づいている場合があります。ノードは、SAにインデックスを作成するために、SPIと他のパラメーター（IPアドレスなど）の組み合わせが必要になる場合があります。

Values 0-255 MUST NOT be used. As per Section 2.1 of [RFC4303], values 1-255 are reserved, and 0 is only allowed to be used internally and MUST NOT be sent over the wire.

値0-255は使用してはなりません。[RFC4303]のセクション2.1によると、値1-255は予約されており、0は内部でのみ使用することが許可されており、ワイヤー上で送信してはなりません。

[RFC4303] does not require the 32-bit SPI to be randomly generated, although that is the RECOMMENDED way to generate SPIs as it provides some privacy and security benefits and avoids correlation between ESP communications. To obtain a usable random 32-bit SPI, the node generates a random 32-bit value and checks it does not fall within the 0-255 range. If the SPI has an acceptable value, it is used to index the inbound session. Otherwise, the generated value is discarded, and the process repeats until a valid value is found.

[RFC4303]は、32ビットSPIをランダムに生成する必要はありませんが、プライバシーとセキュリティの特典を提供し、ESPコミュニケーション間の相関を回避するため、SPIを生成する推奨方法です。使用可能なランダム32ビットSPIを取得するには、ノードがランダムな32ビット値を生成し、0〜255の範囲内に該当しないことを確認します。SPIに許容可能な値がある場合、インバウンドセッションのインデックスに使用されます。それ以外の場合、生成された値は破棄され、有効な値が見つかるまでプロセスが繰り返されます。

Some constrained devices are less concerned with the privacy properties associated with randomly generated SPIs. Examples of such devices might include sensors looking to reduce their code complexity. The use of a predictive function to generate the SPI might be preferred over the generation and handling of random values. An implementation of such predictable function could use the combination of a fixed value and the memory address of the Security Association Database (SAD) structure. For every incoming packet, the node will be able to point to the SAD structure directly from the SPI value. This avoids having a separate and additional binding and lookup function for the SPI to its SAD entry for every incoming packet.

一部の制約付きデバイスは、ランダムに生成されたSPIに関連するプライバシープロパティにあまり関心がありません。このようなデバイスの例には、コードの複雑さを減らすためのセンサーが含まれる場合があります。SPIを生成するための予測関数の使用は、ランダム値の生成と処理よりも好まれる可能性があります。このような予測可能な関数の実装は、固定値とセキュリティ協会データベース（SAD）構造のメモリアドレスの組み合わせを使用できます。着信パケットごとに、ノードはSPI値から直接悲しい構造を指すことができます。これにより、SPIの別の追加のバインディングおよびルックアップ関数が、すべての着信パケットの悲しいエントリを持つことを避けます。

3.1. Considerations for SPI Generation

3.1. SPI生成に関する考慮事項

SPIs that are not randomly generated over 32 bits may have privacy and security concerns. As a result, the use of alternative designs requires careful security and privacy reviews. This section provides some considerations for the adoption of alternative designs.

32ビットを超えてランダムに生成されていないSPIは、プライバシーとセキュリティの懸念を持っている可能性があります。その結果、代替設計を使用するには、慎重なセキュリティとプライバシーのレビューが必要です。このセクションでは、代替設計の採用に関するいくつかの考慮事項を提供します。

The SPI value is only looked up for inbound traffic. The SPI negotiated with IKEv2 [RFC7296] or minimal IKEv2 [RFC7815] by a peer is the value used by the remote peer when it sends traffic. The main advantage of using a rekeying mechanism is to enable a rekey, which is performed by replacing an old SA with a new SA, both indexed with distinct SPIs. The SPI is only used for inbound traffic by the peer, which allows each peer to manage the set of SPIs used for its inbound traffic. The necessary number of SPIs reflects the number of inbound SAs as well as the ability to rekey those SAs. Typically, rekeying an SA is performed by creating a new SA (with a dedicated SPI) before the old SA is deleted. This results in an additional SA and the need to support an additional SPI. Similarly, the privacy concerns associated with the generation of non-random SPIs is also limited to the incoming traffic.

SPI値は、インバウンドトラフィックに対してのみ検索されます。SPIは、ピアによってIKEV2 [RFC7296]または最小IKEV2 [RFC7815]と交渉したことは、トラフィックを送信するときにリモートピアが使用する値です。再キーイングメカニズムを使用することの主な利点は、再キーを有効にすることです。これは、古いSAを新しいSAに交換することで実行されます。SPIは、ピアによるインバウンドトラフィックにのみ使用されます。これにより、各ピアはインバウンドトラフィックに使用されるSPIのセットを管理できます。必要なスピスの数は、インバウンドSAの数とそれらのSASを再キーする能力を反映しています。通常、SAの再キーイングは、古いSAが削除される前に新しいSA（専用のSPIを使用）を作成することにより実行されます。これにより、追加のSAと追加のSPIをサポートする必要があります。同様に、非ランダムSPIの生成に関連するプライバシーの懸念も、入ってくるトラフィックに限定されています。

Alternatively, some constrained devices will not implement IKEv2 or minimal IKEv2 and, as such, will not be able to manage a rollover between two distinct SAs. In addition, some of these constrained devices are likely to have a limited number of SAs; for example, they are likely to be indexed over 3 bytes only. One possible way to enable a rekeying mechanism with these devices is to use the SPI where, for example, the first 3 bytes designates the SA while the remaining byte indicates a rekey index. SPI numbers can be used to implement tracking the inbound SAs when rekeying is taking place. When rekeying an SPI, the new SPI could use the SPI bytes to indicate the rekeying index.

あるいは、一部の制約されたデバイスはIKEV2または最小IKEV2を実装しないため、2つの異なるSAの間のロールオーバーを管理できません。さらに、これらの制約付きデバイスの一部は、限られた数のSAを持つ可能性があります。たとえば、それらは3バイトを超えてインデックス化される可能性があります。これらのデバイスで再キーイングメカニズムを有効にする可能性のある方法の1つは、SPIを使用することです。たとえば、最初の3バイトはSAを指定し、残りのバイトはRekeyインデックスを示します。SPI番号を使用して、再キーイングが行われているときにインバウンドSASの追跡を実装できます。SPIを再キューすると、新しいSPIはSPIバイトを使用して再キーイングインデックスを示すことができます。

The use of a small, limited set of SPI numbers across communications comes with privacy and security concerns. Some specific values or subsets of SPI values could reveal the model or manufacturer of the node implementing ESP or reveal a state such as "not yet rekeyed" or "rekeyed 10 times". If a constrained host uses a very limited number of applications, eventually a single one, the SPI itself could indicate what kind of traffic is transmitted (e.g., the kind of application typically running). This could also be correlated with encrypted data size to further leak information to an observer on the network. In addition, use of specific hardcoded SPI numbers could reveal a manufacturer or device version. If updated devices use different SPI numbers, an attacker could locate vulnerable devices by their use of specific SPI numbers.

通信全体でSPI番号の小さな限られたセットの使用には、プライバシーとセキュリティの懸念が伴います。SPI値のいくつかの特定の値またはサブセットは、ESPを実装するノードのモデルまたはメーカーを明らかにしたり、「まだ再キーリングされていない」または「10回再キーにした」などの状態を明らかにしたりする可能性があります。制約されたホストが非常に限られた数のアプリケーションを使用し、最終的に単一のアプリケーションを使用する場合、SPI自体はどの種類のトラフィックが送信されるかを示すことができます（たとえば、通常実行されているアプリケーションの種類）。これは、暗号化されたデータサイズと相関して、ネットワーク上のオブザーバーに情報をさらに漏らします。さらに、特定のハードコーディングされたSPI番号を使用すると、メーカーまたはデバイスバージョンが明らかになる可能性があります。更新されたデバイスが異なるSPI番号を使用している場合、攻撃者は特定のSPI番号を使用することで脆弱なデバイスを見つけることができます。

A privacy analysis should consider at least the type of information as well as the traffic pattern before deciding whether non-random SPIs are safe to use. Typically, temperature and wind sensors that are used outdoors do not leak privacy-sensitive information, and most of their traffic is expected to be outbound traffic. When used indoors, a sensor that reports an encrypted status of a door (closed or opened) every minute might not leak sensitive information outside the local network. In these examples, the privacy aspect of the information itself might be limited. Being able to determine the version of the sensor to potentially take control of it may also have some limited security consequences. Of course, this depends on the context in which these sensors are being used. If the risks associated to privacy and security are acceptable, a non-randomized SPI can be used.

プライバシー分析では、非ランダムSPIが安全に使用できるかどうかを決定する前に、少なくとも情報の種類とトラフィックパターンを考慮する必要があります。通常、屋外で使用される温度と風力センサーは、プライバシーに敏感な情報を漏らしません。ほとんどのトラフィックは、アウトバウンドトラフィックになると予想されます。屋内で使用すると、毎分ドアの暗号化されたステータス（閉じたり開いたりする）を報告するセンサーは、ローカルネットワークの外側に機密情報を漏らしない場合があります。これらの例では、情報自体のプライバシーの側面が制限される可能性があります。センサーのバージョンを潜在的に制御することができると判断できることも、セキュリティの結果が限られている可能性があります。もちろん、これはこれらのセンサーが使用されているコンテキストに依存します。プライバシーとセキュリティに関連するリスクが受け入れられる場合、非ランダム化されたSPIを使用できます。

4. Sequence Number (SN)

4. シーケンス番号（SN）

The Sequence Number (SN) in [RFC4303] is a mandatory 32-bit field in the packet.

[RFC4303]のシーケンス番号（SN）は、パケット内の必須の32ビットフィールドです。

The SN is set by the sender so the receiver can implement anti-replay protection. The SN is derived from any strictly increasing function that guarantees the following: if packet B is sent after packet A, then the SN of packet B is higher than the SN of packet A.

SNは送信者によって設定されているため、受信機がレプレイ防止保護を実装できます。SNは、以下を保証する厳密に増加する関数から導出されます。パケットBがパケットAの後に送信された場合、パケットBのSNはパケットAのSNよりも高くなります。

Some constrained devices may establish communication with specific devices where it is known whether or not the peer implements anti-replay protection. As per [RFC4303], the sender MUST still implement a strictly increasing function to generate the SN.

一部の制約されたデバイスは、ピアがレプレイ防止を実装するかどうかがわかっている特定のデバイスとの通信を確立する場合があります。[RFC4303]によると、送信者はSNを生成するために厳密に増加する関数を実装する必要があります。

It is RECOMMENDED that multipurpose ESP implementations increment a counter for each packet sent. However, a constrained device may avoid maintaining this context and use another source that is known to always increase. Typically, constrained devices use 802.15.4 Time Slotted Channel Hopping (TSCH). This communication is heavily dependent on time. A constrained device can take advantage of this clock mechanism to generate the SN. A lot of IoT devices are in a sleep state most of the time and wake up only to perform a specific operation before going back to sleep. These devices have separate hardware that allows them to wake up after a certain timeout and typically also have timers that start running when the device is booted up, so they might have a concept of time with certain granularity. This requires devices to store any information in stable storage that can be restored across sleeps (e.g., flash memory). Storing information associated with the SA (such as the SN) requires some read and write operations on stable storage after each packet is sent as opposed to an SPI number or cryptographic keys that are only written to stable storage at the creation of the SA. Write operations wear out the flash storage. Write operations also slow down the system significantly, as writing to flash is much slower than reading from flash. While these devices have internal clocks or timers that might not be very accurate, they are good enough to guarantee that each time the device wakes up from sleep, the time is greater than what it was before the device went to sleep. Using time for the SN would guarantee a strictly increasing function and avoid storing any additional values or context related to the SN on flash. In addition to the time value, a RAM-based counter can be used to ensure that the serial numbers are still increasing and unique if the device sends multiple packets over an SA within one wakeup period.

多目的ESP実装が送信される各パケットのカウンターを増やすことをお勧めします。ただし、制約されたデバイスは、このコンテキストの維持を避け、常に増加することが知られている別のソースを使用する場合があります。通常、制約付きデバイスは802.15.4時間スロット付きチャネルホッピング（TSCH）を使用します。この通信は、時間に大きく依存しています。制約付きデバイスは、このクロックメカニズムを利用してSNを生成できます。多くのIoTデバイスは、ほとんどの場合睡眠状態にあり、睡眠に戻る前に特定の操作を実行するためだけに目を覚まします。これらのデバイスには、特定のタイムアウト後に目覚めることができる個別のハードウェアがあり、通常、デバイスが起動したときに実行を開始するタイマーもあるため、特定の粒度で時間の概念がある可能性があります。これには、睡眠全体で復元できる安定したストレージに情報を保存するためのデバイスが必要です（たとえば、フラッシュメモリ）。SA（SNなど）に関連する情報を保存するには、SAの作成時に安定したストレージにのみ書き込まれるSPI番号または暗号化キーとは対照的に、各パケットが送信された後、安定したストレージの読み取りおよび書き込み操作が必要です。書き込み操作は、フラッシュストレージを摩耗させます。また、Flashへの書き込みはFlashからの読み取りよりもはるかに遅くなるため、操作の書き込みも大幅に減速します。これらのデバイスには、非常に正確ではない内部クロックまたはタイマーがありますが、デバイスが睡眠から目覚めるたびに、デバイスが睡眠になる前よりも時間が大きいことを保証するのに十分です。SNに時間を使用すると、厳密に増加する機能が保証され、フラッシュ上のSNに関連する追加の値またはコンテキストが保存されないようにします。時間値に加えて、RAMベースのカウンターを使用して、デバイスが1つのウェイクアップ期間内にSAを複数のパケットを送信する場合、シリアル番号がまだ増加していることを確認できます。

For inbound traffic, it is RECOMMENDED that receivers implement anti-replay protection. The size of the window should depend on the network characteristic to deliver packets out of order. In an environment where out-of-order packets are not possible, the window size can be set to one. An ESP implementation may choose to not implement anti-replay protection. An implementation of anti-replay protection may require the device to write the received SN for every packet to stable storage. This will have the same issues as discussed earlier with the SN. Some constrained device implementations may choose to not implement the optional anti-replay protection. A typical example is an IoT device such as a temperature sensor that sends a temperature measurement every 60 seconds and receives an acknowledgment from the receiver. In a case like this, the ability to spoof and replay an acknowledgement is of limited interest and might not justify the implementation of an anti-replay mechanism. Receiving peers may also use an ESP anti-replay mechanism adapted to a specific application. Typically, when the sending peer is using an SN based on time, anti-replay may be implemented by discarding any packets that present an SN whose value is too much in the past. Such mechanisms may consider clock drifting in various ways in addition to acceptable delay induced by the network to avoid the anti-replay windows rejecting legitimate packets. Receiving peers could accept any SN as long as it is higher than the previously received SN. Another mechanism could be used where only the received time on the device is used to consider a packet to be valid, without looking at the SN at all.

インバウンドトラフィックの場合、受信者はレプレイ防止防止を実装することをお勧めします。ウィンドウのサイズは、パケットを順番に配信するためにネットワーク特性に依存する必要があります。注文不足のパケットが不可能な環境では、ウィンドウサイズを1つに設定できます。ESP実装は、レプレイ防止防止を実装しないことを選択する場合があります。レプレイ防止防止の実装では、すべてのパケットから安定したストレージの受信SNを作成する必要がある場合があります。これには、SNで前述したのと同じ問題があります。一部の制約されたデバイスの実装は、オプションのアンチレプレイ保護を実装しないことを選択する場合があります。典型的な例は、60秒ごとに温度測定を送信し、受信機から確認を受信する温度センサーなどのIoTデバイスです。このような場合、承認を吸収して再生する能力は限られた関心のあるものであり、反レプレイメカニズムの実装を正当化しない可能性があります。受信ピアは、特定のアプリケーションに適応したESPアンチレプレイメカニズムを使用する場合もあります。通常、送信ピアが時間に基づいてSNを使用している場合、過去に値が多すぎるSNを提示するパケットを破棄することにより、アンチレプレイを実装できます。このようなメカニズムは、正当なパケットを拒否するアンチレプレイウィンドウを避けるために、ネットワークによって誘導される許容可能な遅延に加えて、さまざまな方法でクロックドリフトを考慮する場合があります。受信ピアは、以前に受信したSNよりも高い限り、SNを受け入れることができます。SNを見ずに、パケットが有効であると考えるためにデバイス上の受信時間のみが使用される場合、別のメカニズムを使用できます。

The SN can be represented as a 32-bit number or as a 64-bit number, known as an "Extended Sequence Number (ESN)". As per [RFC4303], support of ESN is not mandatory, and its use is negotiated via IKEv2 [RFC7296]. An ESN is used for high-speed links to ensure there can be more than 2^32 packets before the SA needs to be rekeyed to prevent the SN from rolling over. This assumes the SN is incremented by 1 for each packet. When the SN is incremented differently -- such as when time is used -- rekeying needs to happen based on how the SN is incremented to prevent the SN from rolling over. The security of all data protected under a given key decreases slightly with each message, and a node must ensure the limit is not reached, even though the SN would permit it. Estimation of the maximum number of packets to be sent by a node is not always predictable, and large margins should be used, especially as nodes could be online for much more time than expected. Even for constrained devices, it is RECOMMENDED to implement some rekeying mechanisms (see Section 10).

SNは、「拡張シーケンス番号（ESN）」として知られる32ビット数または64ビット数として表すことができます。[RFC4303]によると、ESNのサポートは必須ではなく、その使用はIKEV2 [RFC7296]を介して交渉されます。ESNは高速リンクに使用され、SNがロールオーバーを防ぐためにSAを再キーにする必要がある前に、2^32以上のパケットがあることを確認します。これは、パケットごとにSNが1ずつ増加することを前提としています。SNが時間を使用するときなど、SNが異なる方法で増加した場合、SNが転がさないようにSNがどのように増加するかに基づいて、再キーイングが発生する必要があります。特定のキーの下で保護されているすべてのデータのセキュリティは、各メッセージでわずかに減少し、ノードはSNが許可しても制限に達していないことを確認する必要があります。ノードによって送信されるパケットの最大数の推定は常に予測可能ではありません。特にノードは予想よりもはるかに多くの時間をオンラインにすることができるため、大きなマージンを使用する必要があります。制約されたデバイスであっても、いくつかの再キーキングメカニズムを実装することをお勧めします（セクション10を参照）。

5. Padding

5. パディング

Padding is required to keep the 32-bit alignment of ESP. It is also required for some encryption transforms that need a specific block size of input, such as ENCR_AES_CBC. ESP specifies padding in the Pad Length byte, followed by up to 255 bytes of padding.

ESPの32ビットアライメントを維持するには、パディングが必要です。また、ENCR_AES_CBCなどの特定のブロックサイズの入力が必要ないくつかの暗号化変換にも必要です。ESPは、パッドの長さバイトのパディングを指定し、その後に最大255バイトのパディングを指定します。

Checking the padding structure is not mandatory, so constrained devices may omit these checks on received ESP packets. For outgoing ESP packets, padding must be applied as required by ESP.

パディング構造をチェックすることは必須ではないため、制約付きデバイスは、受信したESPパケットでこれらのチェックを省略する可能性があります。発信ESPパケットの場合、ESPの要求に応じてパディングを適用する必要があります。

In some situations, the padding bytes may take a fixed value. This would typically be the case when the Payload Data is of fixed size.

状況によっては、パディングバイトが固定値を取得する場合があります。これは通常、ペイロードデータが固定サイズである場合に当てはまります。

ESP [RFC4303] additionally provides Traffic Flow Confidentiality (TFC) as a way to perform padding to hide traffic characteristics. TFC is not mandatory and is negotiated with the SA management protocol, such as IKEv2. TFC has been widely implemented, but it is not widely deployed for ESP traffic. It is NOT RECOMMENDED to implement TFC for minimal ESP.

ESP [RFC4303]は、トラフィックフローの機密性（TFC）をパディングを実行して交通特性を隠す方法として提供します。TFCは必須ではなく、IKEV2などのSA管理プロトコルと交渉されています。TFCは広く実装されていますが、ESPトラフィック用に広く展開されていません。最小限のESPでTFCを実装することはお勧めしません。

As a consequence, communication protection that relies on TFC would be more sensitive to traffic patterns without TFC. This can leak application information as well as the manufacturer or model of the device used to a passive monitoring attacker. Such information can be used, for example, by an attacker if a vulnerability is known for the specific device or application. In addition, some applications (such as health applications) could leak important privacy-oriented information.

結果として、TFCに依存する通信保護は、TFCなしでトラフィックパターンにより敏感になります。これにより、アプリケーション情報と、パッシブモニタリング攻撃者に使用されるデバイスのメーカーまたはモデルをリークできます。このような情報は、たとえば、特定のデバイスまたはアプリケーションで脆弱性が知られている場合、攻撃者が使用できます。さらに、一部のアプリケーション（健康アプリケーションなど）は、重要なプライバシー指向の情報を漏らす可能性があります。

Constrained devices that have a limited battery lifetime may prefer to avoid sending extra padding bytes. In most cases, the payload carried by these devices is quite small, and the standard padding mechanism can be used as an alternative to TFC. Alternatively, any information leak based on the size -- or presence -- of the packet can also be addressed at the application level before the packet is encrypted with ESP. If application packets vary between 1 to 30 bytes, the application could always send 32-byte responses to ensure all traffic sent is of identical length. To prevent leaking information that a sensor changed state, such as "temperature changed" or "door opened", an application could send this information at regular time intervals, rather than when a specific event is happening, even if the sensor state did not change.

バッテリーの寿命が限られている制約付きデバイスは、余分なパディングバイトを送ることを避けることを好むかもしれません。ほとんどの場合、これらのデバイスによって運ばれるペイロードは非常に小さく、標準のパディングメカニズムはTFCの代替として使用できます。あるいは、パケットのサイズまたは存在感に基づいた情報リークは、パケットがESPで暗号化される前に、アプリケーションレベルでアドレス指定することもできます。アプリケーションパケットが1〜30バイトの間で変化する場合、アプリケーションは常に32バイトの応答を送信して、送信されるすべてのトラフィックが同一の長さであることを確認できます。「温度が変更された」や「ドアが開いた」などのセンサーが状態を変更したという情報の漏れを防ぐために、アプリケーションは、センサー状態が変更されなくても、特定のイベントが発生している場合ではなく、定期的な時間間隔でこの情報を送信できます。。

6. Next Header and "Dummy" Packets

6. 次のヘッダーと「ダミー」パケット

ESP [RFC4303] defines the Next Header as a mandatory 8-bit field in the packet. The Next Header, only visible after decryption, specifies the data contained in the payload. In addition, the Next Header may carry an indication on how to process the packet [BEET-ESP]. The Next Header can point to a "dummy" packet, i.e., a packet with the Next Header value set to 59, meaning "no next header". The data following "no next header" is unstructured "dummy" data. (Note that this document uses the term "dummy" for consistency with [RFC4303].)

ESP [RFC4303]は、次のヘッダーをパケット内の必須8ビットフィールドとして定義します。次のヘッダーは、復号化後にのみ表示される、ペイロードに含まれるデータを指定します。さらに、次のヘッダーには、パケットの処理方法[BEET-ESP]の兆候が表示される場合があります。次のヘッダーは、「ダミー」パケット、つまり、次のヘッダー値が59に設定されたパケットを指すことができます。「No Next Header」に続くデータは、構造化されていない「ダミー」データです。（このドキュメントは、[RFC4303]との一貫性のために「ダミー」という用語を使用していることに注意してください。）

The ability to generate, receive, and ignore "dummy" packets is required by [RFC4303]. An implementation can omit ever generating and sending "dummy" packets. For interoperability, a minimal ESP implementation MUST be able to process and discard "dummy" packets without indicating an error.

[RFC4303]では、「ダミー」パケットを生成、受信、無視する機能が必要です。実装は、「ダミー」パケットの生成と送信を省略できます。相互運用性のために、最小限のESP実装は、エラーを示さずに「ダミー」パケットを処理および破棄できる必要があります。

In constrained environments, sending "dummy" packets may have too much impact on the device lifetime, in which case, "dummy" packets should not be generated and sent. On the other hand, constrained devices running specific applications that would leak too much information by not generating and sending "dummy" packets may implement this functionality or even implement something similar at the application layer. Note also that similarly to padding and TFC that can be used to hide some traffic characteristics (see Section 5), "dummy" packets may also reveal some patterns that can be used to identify the application. For example, an application may send "dummy" data to hide a traffic pattern. Suppose such an application sends a 1-byte data when a change occurs. This results in sending a packet notifying a change has occurred. "Dummy" packets may be used to prevent such information from being leaked by sending a 1-byte packet every second when the information is not changed. After an upgrade, the data becomes 2 bytes. At that point, the "dummy" packets do not hide anything, and having 1 byte regularly versus 2 bytes makes even the identification of the application version easier to identify. This generally makes the use of "dummy" packets more appropriate on high-speed links.

制約された環境では、「ダミー」パケットを送信すると、デバイスの寿命に大きな影響を与える可能性があります。その場合、「ダミー」パケットを生成して送信しないでください。一方、「ダミー」パケットを生成して送信することにより、あまりにも多くの情報を漏らし、この機能を実装したり、アプリケーションレイヤーに類似したものを実装したりすることで、あまりにも多くの情報を漏らす特定のアプリケーションを実行している制約付きデバイスがあります。また、いくつかのトラフィック特性を隠すために使用できるパディングとTFCと同様に（セクション5を参照）、「ダミー」パケットは、アプリケーションを識別するために使用できるいくつかのパターンを明らかにする可能性があることに注意してください。たとえば、アプリケーションは「ダミー」データを送信してトラフィックパターンを非表示にする場合があります。このようなアプリケーションが、変更が発生したときに1バイトのデータを送信するとします。これにより、変更が発生したパケットが送信されます。「ダミー」パケットは、情報が変更されないときに毎秒1バイトパケットを送信することで、そのような情報が漏れなくなるのを防ぐために使用できます。アップグレード後、データは2バイトになります。その時点で、「ダミー」パケットは何も非表示にせず、1バイトと2バイトを定期的に持つことで、アプリケーションバージョンの識別さえも識別しやすくなります。これにより、一般に、「ダミー」パケットの使用が高速リンクでより適切になります。

In some cases, devices are dedicated to a single application or a single transport protocol. In this case, the Next Header has a fixed value.

場合によっては、デバイスは単一のアプリケーションまたは単一の輸送プロトコル専用です。この場合、次のヘッダーには固定値があります。

Specific processing indications have not been standardized yet [BEET-ESP] and are expected to result from an agreement between the peers. As a result, they SHOULD NOT be part of a minimal implementation of ESP.

特定の処理適応症はまだ標準化されていない[BEET-ESP]であり、ピア間の合意から生じると予想されます。その結果、それらはESPの最小限の実装の一部であってはなりません。

7. ICV

The ICV depends on the cryptographic suite used. As detailed in [RFC8221], authentication or authenticated encryption is RECOMMENDED, and as such, the ICV field must be present with a size different from zero. Its length is defined by the security recommendations only.

ICVは、使用される暗号化スイートに依存します。[RFC8221]で詳述されているように、認証または認証された暗号化が推奨されるため、ICVフィールドはゼロとは異なるサイズで存在する必要があります。その長さは、セキュリティの推奨事項のみで定義されます。

8. Cryptographic Suites

8. 暗号スイート

The recommended algorithms to use are expected to evolve over time, and implementers SHOULD follow the recommendations provided by [RFC8221] and updates.

使用する推奨アルゴリズムは時間とともに進化すると予想され、実装者は[RFC8221]と更新によって提供される推奨事項に従う必要があります。

This section lists some of the criteria that may be considered to select an appropriate cryptographic suite. The list is not expected to be exhaustive and may also evolve over time.

このセクションには、適切な暗号化スイートを選択するために考慮される可能性のある基準の一部をリストします。リストは網羅的であるとは予想されておらず、時間の経過とともに進化する可能性もあります。

1. Security: Security is the criteria that should be considered first for the selection of encryption algorithm transforms. The security of encryption algorithm transforms is expected to evolve over time, and it is of primary importance to follow up-to-date security guidance and recommendations. The chosen encryption algorithm MUST NOT be vulnerable or weak (see [RFC8221] for outdated ciphers). ESP can be used to authenticate only (ENCR_NULL) or to encrypt the communication. In the latter case, Authenticated Encryption with Associated Data (AEAD) is RECOMMENDED [RFC8221].

1. セキュリティ：セキュリティは、暗号化アルゴリズム変換の選択に最初に考慮されるべき基準です。暗号化アルゴリズム変換のセキュリティは、時間とともに進化すると予想されており、最新のセキュリティガイダンスと推奨事項をフォローすることが主に重要です。選択した暗号化アルゴリズムは、脆弱または弱いことではありません（時代遅れの暗号については[RFC8221]を参照）。ESPを使用して（ENCR_NULL）または通信の暗号化のみを認証できます。後者の場合、関連データ（AEAD）を使用した認証された暗号化が推奨されます[RFC8221]。

2. Resilience to Nonce Reuse: Some transforms, including AES-GCM, are vulnerable to nonce collision with a given key. While the generation of the nonce may prevent such collision during a session, the mechanisms are unlikely to provide such protection across sleep states or reboot. This causes an issue for devices that are configured using static keys (called "manual keying"), and manual keying should not be used with these encryption algorithms. When the key is likely to be reused across reboots, algorithms that are resistant to nonce misuse (for example, AES-SIV [RFC5297], AES-GCM-SIV [RFC8452], and Deoxys-II [DeoxysII]) are RECOMMENDED. Note, however, that none of these are currently defined for use with ESP.

2. Nonce Reuseの回復力：AES-GCMを含む一部の変換は、特定のキーとのNonCe衝突に対して脆弱です。ノンセの生成はセッション中にそのような衝突を防ぐ可能性がありますが、メカニズムは睡眠状態全体でそのような保護を提供したり、再起動したりすることはほとんどありません。これにより、静的キー（「手動キーイング」と呼ばれる）を使用して構成されたデバイスの問題が発生し、これらの暗号化アルゴリズムでは手動キーイングを使用しないでください。キーが再起動全体で再利用される可能性が高い場合、NonCE誤用（たとえば、AES-SIV [RFC5297]、AES-GCM-SIV [RFC8452]、およびDeoxyS-II [deoxysii]）に耐性のあるアルゴリズムが推奨されます。ただし、これらのいずれもESPで使用するために現在定義されていないことに注意してください。

3. Interoperability: Constrained devices usually only implement one or very few different encryption algorithm transforms. [RFC8221] takes the life cycle of encryption algorithm transforms and device manufacturing into consideration in its recommendations for mandatory-to-implement (MTI) algorithms.

3. 相互運用性：制約されたデバイスは通常、1つまたは非常に少数の異なる暗号化アルゴリズム変換のみを実装します。[RFC8221]暗号化アルゴリズムのライフサイクルを、必須の実装（MTI）アルゴリズムに関する推奨事項において、デバイスの製造を考慮します。

4. Power Consumption and Cipher Suite Complexity: Complexity of the encryption algorithm transform and the energy cost associated with it are especially important considerations for devices that have limited resources or are battery powered. The battery life might determine the lifetime of the entire device. When choosing a cryptographic function, reusing specific libraries or taking advantage of hardware acceleration provided by the device should be considered. For example, if the device benefits from AES hardware modules and uses ENCR_AES_CTR, it may prefer AUTH_AES-XCBC for its authentication. In addition, some devices may embed radio modules with hardware acceleration for AES-CCM, in which case, this transform may be preferred.

4. 消費電力と暗号スイートの複雑さ：暗号化アルゴリズム変換の複雑さとそれに関連するエネルギーコストは、リソースが限られているかバッテリー駆動のデバイスにとって特に重要な考慮事項です。バッテリーの寿命は、デバイス全体の寿命を決定する可能性があります。暗号化機能を選択する場合、特定のライブラリを再利用したり、デバイスによって提供されるハードウェアアクセラレーションを活用することを考慮する必要があります。たとえば、デバイスがAESハードウェアモジュールから恩恵を受け、ENCR_AES_CTRを使用している場合、認証にはauth_aes-xcbcを好む場合があります。さらに、一部のデバイスは、AES-CCMのハードウェアアクセラレーションを備えた無線モジュールを埋め込む場合があります。その場合、この変換が好ましい場合があります。

5. Power Consumption and Bandwidth Consumption: Reducing the payload sent may significantly reduce the energy consumption of the device. Encryption algorithm transforms with low overhead are strongly preferred. To reduce the overall payload size, one may, for example:

5. 消費電力と帯域幅の消費：送信されるペイロードを減らすと、デバイスのエネルギー消費が大幅に減少する可能性があります。暗号化アルゴリズムは、オーバーヘッドが低い場合に変換されます。全体的なペイロードサイズを削減するには、たとえば次の場合があります。

* Use counter-based ciphers without fixed block length (e.g., AES-CTR or ChaCha20-Poly1305).

* 固定ブロック長のないカウンターベースの暗号（AES-CTRやChacha20-Poly1305など）を使用します。

* Use ciphers capable of using implicit Initialization Vectors (IVs) [RFC8750].

* 暗黙の初期化ベクトル（IV）[RFC8750]を使用できる暗号を使用します。

* Use ciphers recommended for IoT [RFC8221].

* IoT [RFC8221]に推奨される暗号を使用します。

* Avoid padding by sending payload data that are aligned to the cipher block length -- 2 bytes for the ESP trailer.

* 暗号ブロックの長さに並べられたペイロードデータを送信して、ESPトレーラーの2バイトを送信して、パディングを避けてください。

9. IANA Considerations

9. IANAの考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションがありません。

10. Security Considerations

10. セキュリティに関する考慮事項

The security considerations in [RFC4303] apply to this document as well. In addition, this document provides security recommendations and guidance for the implementation choices for each ESP field.

[RFC4303]のセキュリティ上の考慮事項は、このドキュメントにも適用されます。さらに、このドキュメントは、各ESPフィールドの実装選択に関するセキュリティの推奨事項とガイダンスを提供します。

The security of a communication provided by ESP is closely related to the security associated with the management of that key. This usually includes mechanisms to prevent a nonce from repeating, for example. When a node is provisioned with a session key that is used across reboot, the implementer MUST ensure that the mechanisms put in place remain valid across reboot as well.

ESPが提供する通信のセキュリティは、そのキーの管理に関連するセキュリティに密接に関連しています。これには通常、非CEが繰り返されるのを防ぐメカニズムが含まれます。ノードが再起動全体で使用されるセッションキーでプロビジョニングされている場合、実装者は、リブート全体で導入されたメカニズムも有効であることを確認する必要があります。

It is RECOMMENDED to use ESP in conjunction with key management protocols such as, for example, IKEv2 [RFC7296] or minimal IKEv2 [RFC7815]. Such mechanisms are responsible for negotiating fresh session keys as well as preventing a session key being used beyond its lifetime. When such mechanisms cannot be implemented, such as when the session key is provisioned, the device MUST ensure that keys are not used beyond their lifetime and that the key remains used in compliance with all security requirements across reboots (e.g., conditions on counters and nonces remain valid).

IKEV2 [RFC7296]や最小IKEV2 [RFC7815]などの主要な管理プロトコルと組み合わせてESPを使用することをお勧めします。このようなメカニズムは、新鮮なセッションキーの交渉と、その生涯を超えて使用されるセッションキーの防止に責任があります。セッションキーがプロビジョニングされたときなど、そのようなメカニズムを実装できない場合、デバイスはキーが生涯を超えて使用されず、キーが再起動全体ですべてのセキュリティ要件に準拠して使用されたままであることを確認する必要があります（例：カウンターやノンセスの条件など有効なまま）。

When a device generates its own key or when random values such as nonces are generated, the random generation MUST follow [RFC4086]. In addition, [SP-800-90A-Rev-1] provides guidance on how to build random generators based on deterministic random functions.

デバイスが独自のキーを生成する場合、または非セースなどのランダム値が生成された場合、ランダム生成は[RFC4086]に従う必要があります。さらに、[SP-800-90A-REV-1]は、決定論的なランダム関数に基づいてランダムジェネレーターを構築する方法に関するガイダンスを提供します。

11. Privacy Considerations

11. プライバシーに関する考慮事項

Preventing the leakage of privacy-sensitive information is a hard problem to solve and usually results in balancing the information potentially being leaked to the cost associated with the counter measures. This problem is not inherent to the minimal ESP described in this document and also concerns the use of ESP in general.

プライバシーに敏感な情報の漏れを防ぐことは、解決するのが難しい問題であり、通常、カウンター測定に関連するコストに漏れている可能性のある情報のバランスをとることになります。この問題は、このドキュメントで説明されている最小限のESPに固有のものではなく、一般的なESPの使用に関するものでもあります。

This document targets minimal implementations of ESP and, as such, describes a minimalistic way to implement ESP. In some cases, this may result in potentially revealing privacy-sensitive pieces of information. This document describes these privacy implications so the implementer can make the appropriate decisions given the specificities of a given environment and deployment.

このドキュメントは、ESPの最小限の実装をターゲットにしているため、ESPを実装する最小限の方法を説明します。場合によっては、これにより、プライバシーに敏感な情報が潜在的に明らかになる可能性があります。このドキュメントは、これらのプライバシーへの影響について説明しているため、特定の環境と展開の特異性を考慮して、実装者が適切な決定を下すことができます。

The main risk associated with privacy is the ability to identify an application or a device by analyzing the traffic, which is designated as "traffic shaping". As discussed in Section 3, the use in a very specific context of non-randomly generated SPIs might ease the determination of the device or the application in some cases. Similarly, padding provides limited capabilities to obfuscate the traffic compared to those provided by TFC. Such consequences on privacy are detailed in Section 5.

プライバシーに関連する主なリスクは、「トラフィックシェーピング」として指定されているトラフィックを分析することにより、アプリケーションまたはデバイスを識別する機能です。セクション3で説明したように、非ランダムに生成されたSPIの非常に特定のコンテキストでの使用は、場合によってはデバイスまたはアプリケーションの決定を緩和する可能性があります。同様に、パディングは、TFCが提供するものと比較してトラフィックを難読化するための限られた機能を提供します。プライバシーに対するこのような結果については、セクション5で詳しく説明しています。

12. References

12. 参考文献

12.1. Normative References

12.1. 引用文献

[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>。

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487/RFC4086、2005年6月、<https：//www.rfc-editor.org/info/rfc4086>。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487/RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC4303] Kent、S。、「セキュリティペイロード（ESP）をカプセル化するIP」、RFC 4303、DOI 10.17487/RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P.、およびT. Kivinen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、STD 79、RFC 7296、DOI 10.17487/RFC7296、2014年10月、<https://www.rfc-editor.org/info/rfc7296>。

[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, <https://www.rfc-editor.org/info/rfc7815>.

[RFC7815] Kivinen、T。、「Minimal Internet Key Exchangeバージョン2（IKEV2）イニシエーター実装」、RFC 7815、DOI 10.17487/RFC7815、2016年3月、<https://www.rfc-editor.org/info/rfc7815>。

[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>。

[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.

[RFC8221] Wouters、P.、Migault、D.、Mattsson、J.、Nir、Y.、およびT. Kivinen、「暗号化アルゴリズムの実装要件と、セキュリティペイロード（ESP）および認証ヘッダー（AH）（AH）、RFC 8221、DOI 10.17487/RFC8221、2017年10月、<https://www.rfc-editor.org/info/rfc8221>。

[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)", RFC 8750, DOI 10.17487/RFC8750, March 2020, <https://www.rfc-editor.org/info/rfc8750>.

[RFC8750] Migault、D.、Guggemos、T。、およびY. Nir、「セキュリティペイロードをカプセル化するカウンターベースの暗号の暗黙的初期化ベクター（IV）」、RFC 8750、DOI 10.17487/RFC8750、2020年3月、<https://www.rfc-editor.org/info/rfc8750>。

12.2. Informative References

12.2. 参考引用

[BEET-ESP] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel (BEET) mode for ESP", Work in Progress, Internet-Draft, draft-nikander-esp-beet-mode-09, 5 August 2008, <https://datatracker.ietf.org/doc/html/draft-nikander-esp-beet-mode-09>.

[Beet-esp] Nikander、P。and J. Melen、「ESP用のバインドエンドツーエンドトンネル（ビート）モード」、進行中の作業、インターネットドラフト、ドラフト-Nikander-ESP-Beet-Mode-09、2008年8月5日、<https://datatracker.ietf.org/doc/html/draft-nikander-esp-beet-mode-09>。

[DeoxysII] Jean, J., Nikoli, I., Peyrin, T., and Y. Seurin, "Deoxys v1.41", October 2016, <https://competitions.cr.yp.to/round3/deoxysv141.pdf>.

[Deoxysii] Jean、J.、Nikoli、I.、Peyrin、T。、およびY. Seurin、「Deoxys v1.41」、2016年10月、<https://competitions.cr.yp.to/round3/deoxysv141。pdf>。

[EHC-DIET-ESP] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP Header Compression and Diet-ESP", Work in Progress, Internet-Draft, draft-mglt-ipsecme-diet-esp-08, 13 May 2022, <https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp-08>.

[ehc-diet-esp] Migault、D.、Guggemos、T.、Bormann、C。、およびD. Schinazi、「ESPヘッダー圧縮とDiet-esp」、Work in Progress、Internet-Draft、Draft-MGLT-IPECME-diet-esp-08、2022年5月13日、<https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp-08>。

[EHC-IKEv2] Migault, D., Guggemos, T., and D. Schinazi, "Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) Strategy", Work in Progress, Internet-Draft, draft-mglt-ipsecme-ikev2-diet-esp-extension-02, 13 May 2022, <https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02>.

[EHC-Kikev2] Migault、D.、Guggemos、T。、およびD. Schinazi、「Internet Key Exchangeバージョン2（IKEV2）ESPヘッダー圧縮（EHC）戦略の拡張」、進行中の作業、インターネットドラフト、ドラフト-mglt-ipsecme-yikev2-diet-esp-extension-02、2022年5月13日、<https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extions-02>。

[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 2008, <https://www.rfc-editor.org/info/rfc5297>.

[RFC5297] Harkins、D。、「高度な暗号化標準（AES）を使用した合成初期化ベクター（SIV）認証された暗号化」、RFC 5297、DOI 10.17487/RFC5297、2008年10月、<https：//www.rfc-editor.org/info/rfc5297>。

[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2019, <https://www.rfc-editor.org/info/rfc8452>.

[RFC8452] Gueron、S.、Langley、A。、およびY. Lindell、「AES-GCM-SIV：NONCE誤用耐性認証暗号化」、RFC 8452、DOI 10.17487/RFC8452、2019年4月、<https：// wwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8452>。

[SP-800-90A-Rev-1] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST SP 800-90A Rev 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final>.

[SP-800-90A-REV-1] Barker、E。およびJ. Kelsey、「決定論的なランダムビットジェネレーターを使用した乱数生成の推奨」、Nist SP 800-90a Rev 1、doi 10.6028/nist.sp.800-90AR1、2015年6月、<https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final>。

Acknowledgments

謝辞

The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson, Thomas Peyrin, Eric Thormarker, Nancy Cam-Winget, and Bob Briscoe for their valuable comments. In particular, Scott Fluhrer suggested including the rekey index in the SPI. Tero Kivinen also provided multiple clarifications and examples of ESP deployment within constrained devices with their associated optimizations. Thomas Peyrin, Eric Thormarker, and Scott Fluhrer suggested and clarified the use of transform resilient to nonce misuse. The authors would also like to thank Mohit Sethi for his support as the LWIG Working Group Chair.

著者は、ダニエル・パロマレス、スコット・フルーラー、テロ・キビネン、ヴァレリー・スミースロフ、ヨーヴ・ニール、マイケル・リチャードソン、トーマス・ペイリン、エリック・ソーマーカー、ナンシー・カム・ウィンゲット、ボブ・ブリスコに貴重なコメントに感謝したいと思います。特に、Scott Fluhrerは、SPIにRekeyインデックスを含めることを提案しました。Tero Kivinenは、関連する最適化を備えた制約付きデバイス内のESP展開の複数の説明と例も提供しました。トーマス・ペイリン、エリック・トーマルカー、スコット・フルラーは、非cEの誤用に対する変換の使用を提案し、明らかにしました。著者はまた、Lwig Working Groupの議長としての彼の支援についてMohit Sethiに感謝したいと思います。

Authors' Addresses

著者のアドレス

Daniel Migault Ericsson 8275 Rte Transcanadienne Saint-Laurent QC H4S 0B6 Canada Email: daniel.migault@ericsson.com

Daniel Migault Ericsson 8275 Rte Transcanadienne Saint-Laurent QC H4S 0B6 Canada：daniel.migault@ericsson.com

Tobias Guggemos LMU Munich MNM-Team Oettingenstr. 67 80538 Munich Germany Email: guggemos@mnm-team.org

Tobias Guggemos LMU Munich MNM-Team Oettingenstr。67 80538ミュンヘンドイツメール：guggemos@mnm-team.org