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

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

[要約] RFC 9333は、リソース制約のある環境において標準ESP（RFC 4303）との相互運用性を維持しつつ、実装を最小限に抑えるための特性と考慮事項を定義したドキュメントです。フラッシュへの書き込み制限や乱数生成の削減など、制約下での具体的な実装指針を提示し、最小限の複雑さでパケットの秘匿性と整合性を確保する方法を解説しています。標準ESPを置き換えるものではなく、IoTデバイス等の特定用途に最適化された実装の提供を目的としています。

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)

最小限のカプセル化セキュリティペイロード（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との相互運用性を維持するために、IPカプセル化セキュリティペイロード（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は主要な多目的オペレーティングシステム（OS）のほとんどのカーネルに実装されています。ESPは通常、リソースを犠牲にし、コードサイズを考慮せずに、これらのOSの多目的な用途に適合するようにすべての機能を備えて実装されます。制約のあるデバイスは、フラッシュへの書き込み回数の制限（各パケットまたはウェイクタイム全体）、頻繁なウェイクアップおよびスリープ状態の処理、ウェイクアップ時間の制限、乱数生成の使用の削減など、特定の用途に合わせて最適化および適合された独自の実装を持つ可能性が高いです。Minimal IKEv2 [RFC7815] や ESP Header Compression (EHC) [EHC-DIET-ESP] [EHC-IKEv2] を備えたモノのインターネット（IoT）デバイスによるIPsecの採用に伴い、これらのESP実装は標準のESP実装との相互運用性を維持しなければなりません（MUST）。このドキュメントでは、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"、"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ルックアップは最長一致（longest match）を使用して実行する必要があります。

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のインデックスを作成することが推奨されます（RECOMMENDED）。インデックスは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は使用してはなりません（MUST NOT）。[RFC4303]のセクション2.1に従い、値1〜255は予約されており、0は内部でのみ使用が許可されており、ネットワーク上に送信してはなりません（MUST NOT）。

[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を生成する推奨される（RECOMMENDED）方法です。使用可能なランダムな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値からSAD構造を直接指し示すことができます。これにより、すべての着信パケットについて、SPIからSADエントリへの個別の追加のバインディングおよびルックアップ関数を持つことを回避できます。

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値はインバウンドトラフィックに対してのみ検索されます。ピアがIKEv2 [RFC7296] または minimal IKEv2 [RFC7815] で交渉したSPIは、リモートピアがトラフィックを送信する際に使用する値です。再キーイング（rekeying）メカニズムを使用する主な利点は、古いSAを新しいSA（それぞれ異なるSPIでインデックス化される）に置き換えることで、再キーを可能にすることです。SPIはピアによるインバウンドトラフィックにのみ使用されるため、各ピアは自身のインバウンドトラフィックに使用されるSPIのセットを管理できます。必要なSPIの数は、インバウンドSAの数と、それらのSAを再キーイングする能力を反映します。通常、SAの再キーイングは、古いSAを削除する前に、新しいSA（専用のSPIを持つ）を作成することで実行されます。これによりSAが1つ追加され、追加の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やminimal IKEv2を実装しないため、2つの異なるSA間のロールオーバーを管理できません。さらに、これらの制約のあるデバイスの中には、SAの数が限られているものもあり、例えば、3バイトのみでインデックス化されている場合があります。これらのデバイスで再キーイングメカニズムを有効にする1つの方法は、SPIを使用することです。例えば、最初の3バイトでSAを指定し、残りの1バイトで再キーインデックスを示すといった具合です。SPI番号を使用して、再キーイングが行われているときにインバウンドSAを追跡するように実装できます。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を安全に使用できるかどうかを決定する前に、プライバシー分析において少なくとも情報の種類とトラフィックパターンを考慮すべきです。通常、屋外で使用される温度センサーや風力センサーは、プライバシーに敏感な情報を漏洩させることはなく、そのトラフィックのほとんどはアウトバウンドトラフィックであると予想されます。屋内で使用する場合、ドアの暗号化されたステータス（閉または開）を1分ごとに報告するセンサーは、ローカルネットワーク外に機密情報を漏洩させない可能性があります。これらの例では、情報自体のプライバシーの側面は限定的かもしれません。センサーのバージョンを特定されて、潜在的にそれを制御される可能性があることは、限定的なセキュリティ上の影響を及ぼすかもしれません。もちろん、これはこれらのセンサーが使用されている文脈に依存します。プライバシーとセキュリティに関連するリスクが許容範囲内であれば、非ランダム化された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は送信者によって設定され、受信者がアンチリプレイ保護（anti-replay protection）を実装できるようにします。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を生成するために依然として厳密に増加する関数を実装しなければなりません（MUST）。

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実装では、送信されるパケットごとにカウンターをインクリメントすることが推奨されます（RECOMMENDED）。しかし、制約のあるデバイスでは、このコンテキストの維持を避け、常に増加することが分かっている別のソースを使用する場合があります。通常、制約のあるデバイスは 802.15.4 Time Slotted Channel Hopping (TSCH) を使用します。この通信は時間に大きく依存しています。制約のあるデバイスは、このクロックメカニズムを利用してSNを生成できます。多くのIoTデバイスはほとんどの時間スリープ状態にあり、特定の操作を実行するためだけに目を覚まし、その後再びスリープに戻ります。これらのデバイスは、特定のタイムアウト後にウェイクアップできる独立したハードウェアを備えており、通常、デバイスの起動時に動作を開始するタイマーも備えているため、特定の粒度で時間の概念を持っている可能性があります。これには、デバイスがスリープをまたいで復元できる安定したストレージ（フラッシュメモリなど）に情報を保存する必要があります。SAに関連する情報（SNなど）を保存するには、SAの作成時にのみ安定したストレージに書き込まれるSPI番号や暗号鍵とは対照的に、パケットを送信するたびに安定したストレージへの読み取りおよび書き込み操作が必要になります。書き込み操作はフラッシュストレージを摩耗させます。また、フラッシュへの書き込みはフラッシュからの読み取りよりもはるかに遅いため、書き込み操作はシステムを大幅に低速化させます。これらのデバイスが持つ内部クロックやタイマーはあまり正確ではないかもしれませんが、デバイスがスリープから目覚めるたびに、その時刻がスリープに入る前よりも進んでいることを保証するには十分です。SNに時間を使用すれば、厳密に増加する関数が保証され、フラッシュ上にSNに関連する追加の値やコンテキストを保存することを回避できます。時間値に加えて、デバイスが1回のウェイクアップ期間内に1つのSAで複数のパケットを送信する場合に、シーケンス番号が増加し続け、一意であることを保証するために、RAMベースのカウンターを使用することもできます。

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.

インバウンドトラフィックについて、受信者はアンチリプレイ保護を実装することが推奨されます（RECOMMENDED）。ウィンドウのサイズは、パケットが順序通りに届かないネットワーク特性に依存させるべきです。順序の入れ替わりが発生しない環境では、ウィンドウサイズを1に設定できます。ESP実装は、アンチリプレイ保護を実装しないことを選択してもよいです。アンチリプレイ保護の実装では、受信したすべてのパケットのSNを安定したストレージに書き込む必要がある場合があります。これには、前述のSNに関するものと同じ問題が伴います。一部の制約のあるデバイスの実装では、オプションのアンチリプレイ保護を実装しないことを選択する場合があります。典型的な例は、60秒ごとに温度測定値を送信し、受信者から確認応答（ACK）を受信する温度センサーなどの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は、32ビット数、または「拡張シーケンス番号（ESN）」として知られる64ビット数として表すことができます。[RFC4303]に従い、ESNのサポートは必須ではなく、その使用はIKEv2 [RFC7296] を介して交渉されます。ESNは高速リンクで使用され、SNのロールオーバーを防ぐためにSAを再キーイングする必要が生じるまでに、2^32個以上のパケットを送信できるようにします。これは、パケットごとにSNが1ずつインクリメントされることを前提としています。時間が使用される場合など、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では、Pad Lengthバイトでパディングを指定し、その後に最大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トラフィックに対して広く展開されているわけではありません。Minimal ESPにおいてTFCを実装することは推奨されません（NOT RECOMMENDED）。

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. Next Headerと「ダミー」パケット

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ビットフィールドとしてNext Headerを定義しています。Next Headerは復号後にのみ可視となり、ペイロードに含まれるデータの種類を指定します。さらに、Next Headerにはパケットの処理方法に関する指示が含まれる場合もあります [BEET-ESP]。Next Headerは「ダミー」パケット、すなわちNext Header値が59（「次ヘッダーなし」を意味する）に設定されたパケットを指すことができます。「次ヘッダーなし」に続くデータは、構造化されていない「ダミー」データです。（なお、このドキュメントでは [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] で要求されています。実装において、「ダミー」パケットの生成と送信を常に行わないようにすることは可能です。相互運用性のために、Minimal ESP実装は、エラーを表示することなく「ダミー」パケットを処理および破棄できなければなりません（MUST）。

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.

デバイスが単一のアプリケーションまたは単一のトランスポートプロトコル専用である場合もあります。この場合、Next Headerは固定値となります。

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]、ピア間の合意によって決定されることが期待されています。その結果、それらはMinimal ESP実装の一部に含めるべきではありません（SHOULD NOT）。

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. セキュリティ：セキュリティは、暗号アルゴリズム変換を選択する際に最初に考慮すべき基準です。暗号アルゴリズム変換のセキュリティは時間とともに進化することが予想されるため、最新のセキュリティガイダンスや推奨事項に従うことが極めて重要です。選択された暗号アルゴリズムは、脆弱であったり弱体化していたりしてはなりません（MUST NOT）（旧式の暗号については [RFC8221] を参照）。ESPは、認証のみ（ENCR_NULL）または通信の暗号化に使用できます。後者の場合、関連データ付き認証暗号（AEAD: Authenticated Encryption with Associated Data）が推奨されます（RECOMMENDED）[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. ノンス再利用に対する耐性：AES-GCMを含む一部の変換は、特定の鍵でのノンス衝突に対して脆弱です。ノンスの生成によってセッション中の衝突を防げる可能性はありますが、スリープ状態や再起動をまたいでそのような保護を提供できるメカニズムはほとんどありません。これは、静的鍵を使用して構成されたデバイス（「手動キーイング」と呼ばれる）で問題を引き起こすため、これらの暗号アルゴリズムで手動キーイングを使用すべきではありません。再起動後も鍵が再利用される可能性が高い場合は、ノンス誤用耐性のあるアルゴリズム（例：AES-SIV [RFC5297]、AES-GCM-SIV [RFC8452]、Deoxys-II [DeoxysII]）が推奨されます（RECOMMENDED）。ただし、これらはいずれも現時点で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: mandatory-to-implement）アルゴリズムを推奨しています。

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によって提供される通信のセキュリティは、その鍵の管理に関連するセキュリティに密接に関係しています。これには通常、例えばノンスの繰り返しを防ぐメカニズムなどが含まれます。再起動をまたいで使用されるセッション鍵がノードにプロビジョニングされている場合、実装者は、導入されたメカニズムが再起動後も有効であることを保証しなければなりません（MUST）。

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] や minimal IKEv2 [RFC7815] などの鍵管理プロトコルと組み合わせてESPを使用することが推奨されます（RECOMMENDED）。このようなメカニズムは、新しいセッション鍵の交渉や、セッション鍵がその有効期間を超えて使用されるのを防ぐ役割を担います。セッション鍵がプロビジョニングされている場合など、そのようなメカニズムを実装できない場合、デバイスは、鍵が有効期間を超えて使用されないこと、および再起動をまたいでもすべてのセキュリティ要件（例：カウンターやノンスに関する条件など）を遵守して鍵が使用され続けることを保証しなければなりません（MUST）。

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] に従わなければなりません（MUST）。さらに、[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.

プライバシーに敏感な情報の漏洩を防ぐことは解決が難しい問題であり、通常、漏洩する可能性のある情報と対策に伴うコストとのバランスを考慮することになります。この問題は、このドキュメントで説明されているMinimal 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., "Key words for use in RFCs to Indicate Requirement Levels", 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., and S. Crocker, "Randomness Requirements for Security", 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. and K. Seo, "Security Architecture for the Internet Protocol", 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., "IP Encapsulating Security Payload (ESP)", 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., and T. Kivinen, "Internet Key Exchange Protocol Version 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 Version 2 (IKEv2) Initiator Implementation", 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., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", 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., 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, 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., and Y. Nir, "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)", 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, "A Bound End-to-End Tunnel (BEET) mode for ESP", Work in Progress, Internet-Draft, draft-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., and 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., and D. Schinazi, "ESP Header Compression and Diet-ESP", Work in Progress, Internet-Draft, draft-mglt-ipsecme-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-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, 2022年5月13日, <https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-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., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", 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., and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, 2019年4月, <https://www.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. 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, 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.

著者は、貴重なコメントをいただいた Daniel Palomares, Scott Fluhrer, Tero Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson, Thomas Peyrin, Eric Thormarker, Nancy Cam-Winget, Bob Briscoe の各氏に感謝いたします。特に、Scott Fluhrer 氏は SPI に再キーインデックスを含めることを提案されました。Tero Kivinen 氏は、制約のあるデバイス内でのESP展開に関する複数の明確化と例、およびそれに関連する最適化を提供されました。Thomas Peyrin, Eric Thormarker, Scott Fluhrer の各氏は、ノンス誤用耐性のある変換の使用を提案および明確化されました。また、LWIG ワーキンググループのチェアとしてのサポートをいただいた 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, Email: 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 Munich, Germany, Email: guggemos@mnm-team.org