[要約] RFC 4303は、IP Encapsulating Security Payload (ESP)に関する文書で、インターネットプロトコルセキュリティ(IPsec)アーキテクチャの一部を形成します。この文書の目的は、IPパケットのペイロード部分を暗号化および/または認証することにより、機密性、データの完全性、およびオプションでソース認証を提供することです。ESPは、VPNの構築やセキュアなリモートアクセスなど、セキュリティが必要な通信を保護する場面で利用されます。関連するRFCには、IPsecのアーキテクチャを定義するRFC 4301や、認証ヘッダ(AH)に関するRFC 4302などがあります。
Network Working Group S. Kent
Request for Comments: 4303 BBN Technologies
Obsoletes: 2406 December 2005
Category: Standards Track
IP Encapsulating Security Payload (ESP)
セキュリティペイロードをカプセル化するIP
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998).
このドキュメントでは、IPv4とIPv6でセキュリティサービスの組み合わせを提供するように設計されたカプセル化セキュリティペイロード（ESP）プロトコルの更新されたバージョンについて説明します。ESPは、機密性、データ起源認証、コネクションレスの完全性、アンチレプレイサービス（部分シーケンスの整合性の形式）、および限られたトラフィックフローの機密性を提供するために使用されます。このドキュメントは、RFC 2406を廃止します（1998年11月）。
Table of Contents
目次
1. Introduction ....................................................3
2. Encapsulating Security Payload Packet Format ....................5
2.1. Security Parameters Index (SPI) ...........................10
2.2. Sequence Number ...........................................12
2.2.1. Extended (64-bit) Sequence Number ..................12
2.3. Payload Data ..............................................13
2.4. Padding (for Encryption) ..................................14
2.5. Pad Length ................................................15
2.6. Next Header ...............................................16
2.7. Traffic Flow Confidentiality (TFC) Padding ................17
2.8. Integrity Check Value (ICV) ...............................17
3. Encapsulating Security Protocol Processing .....................18
3.1. ESP Header Location .......................................18
3.1.1. Transport Mode Processing ..........................18
3.1.2. Tunnel Mode Processing .............................19
3.2. Algorithms ................................................20
3.2.1. Encryption Algorithms ..............................21
3.2.2. Integrity Algorithms ...............................21
3.2.3. Combined Mode Algorithms ...........................22
3.3. Outbound Packet Processing ................................22
3.3.1. Security Association Lookup ........................22
3.3.2. Packet Encryption and Integrity Check Value
(ICV) Calculation ..................................22
3.3.2.1. Separate Confidentiality and
Integrity Algorithms ......................23
3.3.2.2. Combined Confidentiality and
Integrity Algorithms ......................24
3.3.3. Sequence Number Generation .........................25
3.3.4. Fragmentation ......................................26
3.4. Inbound Packet Processing .................................27
3.4.1. Reassembly .........................................27
3.4.2. Security Association Lookup ........................27
3.4.3. Sequence Number Verification .......................28
3.4.4. Integrity Check Value Verification .................30
3.4.4.1. Separate Confidentiality and
Integrity Algorithms ......................30
3.4.4.2. Combined Confidentiality and
Integrity Algorithms ......................32
4. Auditing .......................................................33
5. Conformance Requirements .......................................34
6. Security Considerations ........................................34
7. Differences from RFC 2406 ......................................34
8. Backward-Compatibility Considerations ..........................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A: Extended (64-bit) Sequence Numbers ....................38
A1. Overview ...................................................38
A2. Anti-Replay Window .........................................38
A2.1. Managing and Using the Anti-Replay Window ............39
A2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................40
A2.3. Pseudo-Code Example ..................................41
A3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................42
A3.1. Triggering Re-synchronization ........................43
A3.2. Re-synchronization Process ...........................43
This document assumes that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Ken-Arch], hereafter referred to as the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by the Encapsulating Security Payload (ESP) and the IP Authentication Header (AH), the concept of Security Associations, the ways in which ESP can be used in conjunction with AH, and the different key management options available for ESP and AH.
このドキュメントは、読者が「インターネットプロトコルのセキュリティアーキテクチャ」[Ken-Arch]に記載されている用語と概念に精通していることを前提としています。特に、読者は、セキュリティペイロード（ESP）とIP認証ヘッダー（AH）によって提供されるセキュリティサービスの定義、セキュリティ関連の概念、ESPをAHと併せて使用できる方法に精通している必要があります。、およびESPとAHが利用できるさまざまな主要な管理オプション。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
キーワードは、このドキュメントに表示される場合、RFC 2119 [bra97]に記載されているように解釈される場合、必要な、必須、必要は、推奨、推奨、勧めてはいけません。
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6 [DH98]. ESP may be applied alone, in combination with AH [Ken-AH], or in a nested fashion (see the Security Architecture document [Ken-Arch]). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [Ken-Arch].
カプセル化セキュリティペイロード（ESP）ヘッダーは、IPv4とIPv6 [DH98]でセキュリティサービスの組み合わせを提供するように設計されています。ESPは、AH [Ken-Ah]と組み合わせて、またはネストされた方法で単独で適用できます（セキュリティアーキテクチャドキュメント[Ken-Arch]を参照）。セキュリティサービスは、通信ホストのペア間、セキュリティゲートウェイの通信のペア、またはセキュリティゲートウェイとホストの間で提供できます。さまざまなネットワーク環境でESPとAHを使用する方法の詳細については、セキュリティアーキテクチャドキュメント[Ken-Arch]を参照してください。
The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below.
ESPヘッダーは、IPヘッダーの後、次のレイヤープロトコルヘッダー（トランスポートモード）の前、またはカプセル化されたIPヘッダー（トンネルモード）の前に挿入されます。これらのモードについては、以下で詳しく説明します。
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.
ESPを使用して、機密性、データ起源認証、コネクションレスの完全性、アンチレプレイサービス（部分シーケンスの整合性の形式）、および（限られた）トラフィックフローの機密性を提供することができます。提供されるサービスのセットは、セキュリティ協会（SA）の設立時に選択されたオプションと、ネットワークトポロジの実装の場所に依存します。
Using encryption-only for confidentiality is allowed by ESP. However, it should be noted that in general, this will provide defense only against passive attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may render the confidentiality service insecure against some forms of active attacks [Bel96, Kra01]. Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against active attackers [Kra01]. ESP allows encryption-only SAs because this may offer considerably better performance and still provide adequate security, e.g., when higher-layer authentication/integrity protection is offered independently. However, this standard does not require ESP implementations to offer an encryption-only service.
機密性のために暗号化のみを使用することは、ESPによって許可されます。ただし、一般に、これは受動的な攻撃者に対してのみ防御を提供することに注意する必要があります。その上に強い整合性メカニズムなしで暗号化を使用すると（ESPまたはAHを介して別々に）、いくつかの形式のアクティブな攻撃に対して機密性サービスを不安定にする可能性があります[BEL96、KRA01]。さらに、AHなどの基礎となる整合性サービスは、暗号化の前に適用され、必ずしもアクティブな攻撃者に対する暗号化のみの機密性を保護するわけではありません[KRA01]。ESPは、暗号化のみのSASを許可します。これは、かなり優れたパフォーマンスを提供し、適切なセキュリティを提供する可能性があるためです。ただし、この標準では、暗号化のみのサービスを提供するためにESP実装を必要としません。
Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity". (This term is employed because, on a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer. Typically, this binding is effected through the use of a shared, symmetric key.) Integrity-only ESP MUST be offered as a service selection option, e.g., it must be negotiable in SA management protocols and MUST be configurable via management interfaces. Integrity-only ESP is an attractive alternative to AH in many contexts, e.g., because it is faster to process and more amenable to pipelining in many implementations.
データ起源の認証とコネクションレスの完全性は共同サービスであり、以下では共同で「整合性」と呼ばれます。（この用語は、パケットごとに実行される計算が接続のない整合性を直接提供するため、この用語が採用されています。データオリジン認証は間接的に提供されます。、このバインディングは、共有された対称キーを使用して行われます。）整合性のみのESPは、サービス選択オプションとして提供する必要があります。IntegrityのみのESPは、多くのコンテキストでAHに代わる魅力的な代替品です。たとえば、処理が速く、多くの実装でのパイプライニングがより適切であるためです。
Although confidentiality and integrity can be offered independently, ESP typically will employ both services, i.e., packets will be protected with regard to confidentiality and integrity. Thus, there are three possible ESP security service combinations involving these services:
機密性と整合性は独立して提供できますが、ESPは通常、両方のサービスを採用します。つまり、パケットは機密性と完全性に関して保護されます。したがって、これらのサービスを含む3つの可能なESPセキュリティサービスの組み合わせがあります。
- confidentiality-only (MAY be supported) - integrity only (MUST be supported) - confidentiality and integrity (MUST be supported)
- 機密性のみ（サポートされる場合があります） - 整合性のみ（サポートする必要があります） - 機密性と整合性（サポートする必要があります）
The anti-replay service may be selected for an SA only if the integrity service is selected for that SA. The selection of this service is solely at the discretion of the receiver and thus need not be negotiated. However, to make use of the Extended Sequence Number feature in an interoperable fashion, ESP does impose a requirement on SA management protocols to be able to negotiate this feature (see Section 2.2.1 below).
Anti Replayサービスは、そのSAに対して整合性サービスが選択されている場合にのみ、SAに対して選択できます。このサービスの選択は、受信者の裁量だけであるため、交渉する必要はありません。ただし、拡張されたシーケンス番号機能を相互運用可能な方法で使用するために、ESPはこの機能を交渉できるようにSA管理プロトコルに要件を課します（以下のセクション2.2.1を参照）。
The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. (ESP may be employed as part of a higher-layer TFC system, e.g., Onion Routing [Syverson], but such systems are outside the scope of this standard.) New TFC features present in ESP facilitate efficient generation and discarding of dummy traffic and better padding of real traffic, in a backward-compatible fashion.
トラフィックフローの機密性（TFC）サービスは、一般に、ESPが特派員の究極のソースと宛先アドレスを隠している方法で採用されている場合にのみ有効です。当然、またはマスキングトラフィックの生成の結果として）特定の個々のサブスクライバートラフィックフローの特性を隠すため。（ESPは、高層TFCシステムの一部として採用される場合があります。たとえば、タマネギルーティング[Syverson]ですが、そのようなシステムはこの標準の範囲外です。）ESPが存在する新しいTFC機能により、効率的な生成とダミートラフィックの破棄が促進されます。後方互換性のある方法で、実際の交通のより良いパディング。
Section 7 provides a brief review of the differences between this document and RFC 2406.
セクション7では、このドキュメントとRFC 2406の違いの簡単なレビューを提供します。
The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web page at http://www.iana.org/assignments/protocol-numbers). Figure 1 illustrates the top-level format of an ESP packet. The packet begins with two 4-byte fields (Security Parameters Index (SPI) and Sequence Number). Following these fields is the Payload Data, which has substructure that depends on the choice of encryption algorithm and mode, and on the use of TFC padding, which is examined in more detail later. Following the Payload Data are Padding and Pad Length fields, and the Next Header field. The optional Integrity Check Value (ICV) field completes the packet.
ESPヘッダーの直前の（IPv4、IPv6、または拡張）（IPv4、IPv6、または拡張）には、そのプロトコル（IPv4）または次のヘッダー（IPv6、拡張）フィールドに値50が含まれます（http：//のIANA Webページを参照してください。www.iana.org/assignments/protocol-numbers）。図1は、ESPパケットのトップレベル形式を示しています。パケットは、2つの4バイトフィールド（セキュリティパラメーターインデックス（SPI）とシーケンス番号）で始まります。これらのフィールドに従うことは、暗号化アルゴリズムとモードの選択に依存する下部構造と、後で詳細に調査するTFCパディングの使用に依存するペイロードデータがあります。ペイロードデータに従うことは、パディングとパッドの長さフィールド、および次のヘッダーフィールドです。オプションの整合性チェック値（ICV）フィールドがパケットを完成させます。
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. Top-Level Format of an ESP Packet
図1. ESPパケットのトップレベル形式
* If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext.
* ペイロードフィールドに含まれる場合、暗号化ベクトル（IV、セクション2.3を参照）など、暗号化の同期データは通常、それ自体が暗号化されていませんが、多くの場合、暗号文の一部と呼ばれます。
The (transmitted) ESP trailer consists of the Padding, Pad Length, and Next Header fields. Additional, implicit ESP trailer data (which is not transmitted) is included in the integrity computation, as described below.
（送信）ESPトレーラーは、パディング、パッドの長さ、および次のヘッダーフィールドで構成されています。追加の暗黙のESPトレーラーデータ（送信されていません）は、以下で説明するように、整合性計算に含まれています。
If the integrity service is selected, the integrity computation encompasses the SPI, Sequence Number, Payload Data, and the ESP trailer (explicit and implicit).
整合性サービスが選択されている場合、整合性計算には、SPI、シーケンス番号、ペイロードデータ、およびESPトレーラー（明示的で暗黙的）が含まれます。
If the confidentiality service is selected, the ciphertext consists of the Payload Data (except for any cryptographic synchronization data that may be included) and the (explicit) ESP trailer.
機密性サービスが選択されている場合、暗号文はペイロードデータ（含まれる可能性のある暗号化同期データを除く）と（明示的な）ESPトレーラーで構成されています。
As noted above, the Payload Data may have substructure. An encryption algorithm that requires an explicit Initialization Vector (IV), e.g., Cipher Block Chaining (CBC) mode, often prefixes the Payload Data to be protected with that value. Some algorithm modes combine encryption and integrity into a single operation; this document refers to such algorithm modes as "combined mode algorithms". Accommodation of combined mode algorithms requires that the algorithm explicitly describe the payload substructure used to convey the integrity data.
上記のように、ペイロードデータには下部構造がある場合があります。明示的な初期化ベクトル（IV）を必要とする暗号化アルゴリズム、たとえば、暗号ブロックチェーン（CBC）モードなど、多くの場合、その値で保護されるペイロードデータをプレミックスします。一部のアルゴリズムモードは、暗号化と完全性を単一の操作に組み合わせています。このドキュメントは、「Combined Mode Algorithms」などのアルゴリズムモードを指します。複合モードアルゴリズムの調節には、アルゴリズムが整合性データの伝達に使用されるペイロード下部構造を明示的に説明する必要があります。
Some combined mode algorithms provide integrity only for data that is encrypted, whereas others can provide integrity for some additional data that is not encrypted for transmission. Because the SPI and Sequence Number fields require integrity as part of the integrity service, and they are not encrypted, it is necessary to ensure that they are afforded integrity whenever the service is selected, regardless of the style of combined algorithm mode employed.
いくつかの複合モードアルゴリズムは、暗号化されたデータに対してのみ整合性を提供しますが、送信用に暗号化されていないいくつかの追加データに整合性を提供できるものもあります。SPIおよびシーケンス番号フィールドは、整合性サービスの一部として整合性を必要とし、暗号化されていないため、採用された組み合わせアルゴリズムモードのスタイルに関係なく、サービスが選択されるたびに整合性を確保する必要があります。
When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) may be omitted. When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm to encode within the Payload Data an ICV-equivalent means of verifying the integrity of the packet.
複合モードアルゴリズムが採用されると、アルゴリズム自体は、復号化されたプレーンテキストと整合性チェックのパス/失敗の両方の表示を返すことが期待されます。複合モードアルゴリズムの場合、ESPパケットの最後に通常表示されるICV（整合性が選択されている場合）は省略できます。ICVが省略され、整合性が選択されると、パケットの完全性を検証するICV相当の手段をペイロードデータ内でエンコードするのは、結合モードアルゴリズムの責任です。
If a combined mode algorithm offers integrity only to data that is encrypted, it will be necessary to replicate the SPI and Sequence Number as part of the Payload Data.
結合されたモードアルゴリズムが暗号化されたデータに対してのみ整合性を提供する場合、ペイロードデータの一部としてSPIとシーケンス番号を複製する必要があります。
Finally, a new provision is made to insert padding for traffic flow confidentiality after the Payload Data and before the ESP trailer. Figure 2 illustrates this substructure for Payload Data. (Note: This diagram shows bits-on-the-wire. So even if extended sequence numbers are being used, only 32 bits of the Sequence Number will be transmitted (see Section 2.2.1).)
最後に、ペイロードデータの後およびESPトレーラーの前に、トラフィックフローの機密性のためにパディングを挿入するための新しい規定が作成されます。図2は、ペイロードデータのこの下部構造を示しています。（注：この図はワイヤーのビットを示しています。したがって、拡張されたシーケンス番号が使用されていても、シーケンス番号の32ビットのみが送信されます（セクション2.2.1を参照）。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Substructure of Payload Data
図2.ペイロードデータの下部構造
* If tunnel mode is being used, then the IPsec implementation can add Traffic Flow Confidentiality (TFC) padding (see Section 2.4) after the Payload Data and before the Padding (0-255 bytes) field.
* トンネルモードが使用されている場合、IPSECの実装は、ペイロードデータの後、パディング（0-255バイト）フィールドの前に、トラフィックフローの機密性（TFC）パディング（セクション2.4を参照）を追加できます。
If a combined algorithm mode is employed, the explicit ICV shown in Figures 1 and 2 may be omitted (see Section 3.3.2.2 below). Because algorithms and modes are fixed when an SA is established, the detailed format of ESP packets for a given SA (including the Payload Data substructure) is fixed, for all traffic on the SA.
組み合わせたアルゴリズムモードが採用されている場合、図1および2に示す明示的なICVは省略できます（以下のセクション3.3.2.2を参照）。SAが確立されるとアルゴリズムとモードが固定されるため、SAのすべてのトラフィックに対して、特定のSA（ペイロードデータの下部構造を含む）のESPパケットの詳細な形式が固定されています。
The tables below refer to the fields in the preceding figures and illustrate how several categories of algorithmic options, each with a different processing model, affect the fields noted above. The processing details are described in later sections.
以下の表は、前の図のフィールドを参照し、それぞれが異なる処理モデルを持つアルゴリズムオプションのいくつかのカテゴリが、上記のフィールドにどのように影響するかを示しています。処理の詳細については、後のセクションで説明します。
Table 1. Separate Encryption and Integrity Algorithms
表1.個別の暗号化と整合性アルゴリズム
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M Y plain
Seq# (low-order bits) 4 M Y plain p
------ a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher[3] |-l
TFC padding [4] variable O Y Y cipher[3] | o
------ a
Padding 0-255 M Y Y cipher[3] d
Pad Length 1 M Y Y cipher[3]
Next Header 1 M Y Y cipher[3]
Seq# (high-order bits) 4 if ESN [5] Y not xmtd
ICV Padding variable if need Y not xmtd
ICV variable M [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] ciphertext if encryption has been selected
[4] Can be used only if payload specifies its "real" length
[5] See section 2.2.1
[6] mandatory if a separate integrity algorithm is used
Table 2. Combined Mode Algorithms
表2.結合モードアルゴリズム
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M plain
Seq# (low-order bits) 4 M plain p
--- a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher |-l
TFC padding [3] variable O Y Y cipher | o
--- a
Padding 0-255 M Y Y cipher d
Pad Length 1 M Y Y cipher
Next Header 1 M Y Y cipher
Seq# (high-order bits) 4 if ESN [4] Y [5]
ICV Padding variable if need Y [5]
ICV variable O [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] Can be used only if payload specifies its "real" length
[4] See Section 2.2.1
[5] The algorithm choices determines whether these are
transmitted, but in either case, the result is invisible
to ESP
[6] The algorithm spec determines whether this field is
present
The following subsections describe the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an ICV (see Section 2.7). Whether or not an option is selected is determined as part of Security Association (SA) establishment. Thus, the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs.
次のサブセクションでは、ヘッダー形式のフィールドについて説明します。「オプション」とは、オプションが選択されていない場合、つまり、送信されたパケットにもICVの計算のためにフォーマットされていない場合も、フィールドが省略されることを意味します（セクション2.7を参照）。選択が選択されているかどうかは、セキュリティ協会（SA）施設の一部として決定されます。したがって、SAの期間中、特定のSAのESPパケットの形式が固定されています。対照的に、すべてのSAに対して、「必須」フィールドは常にESPパケット形式に存在します。
Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [Pos81]) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
注：IPSECで使用されるすべての暗号化アルゴリズムは、標準的なネットワークバイト順序での入力を期待し（RFC 791 [POS81]の付録を参照）、標準ネットワークバイト順序で出力を生成します。IPパケットもネットワークバイトの順序で送信されます。
ESP does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of ESP (e.g., Internet Key Exchange (IKEv2) [Kau05]) or an out-of-band configuration mechanism.
ESPにはバージョン番号が含まれていないため、後方互換性について懸念がある場合は、2つのIPSECピア間のシグナル伝達メカニズムを使用して、互換性のあるバージョンのESP（たとえば、インターネットキーエクスチェンジ（IKEV2）[KAU05]）を確保することで対処する必要があります。または帯域外構成メカニズム。
The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory.
SPIは、受信機が使用する任意の32ビット値であり、着信パケットがバインドされるSAを識別します。SPIフィールドは必須です。
For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Because the SPI value is generated by the receiver for a unicast SA, whether the value is sufficient to identify an SA by itself or whether it must be used in conjunction with the IPsec protocol value is a local matter. This mechanism for mapping inbound traffic to unicast SAs MUST be supported by all ESP implementations.
ユニキャストSAの場合、SPIはSAを指定するために単独で使用できます。または、IPSECプロトコルタイプ（この場合はESP）と組み合わせて使用できます。SPI値はUnicast SAのレシーバーによって生成されるため、値がSAを単独で識別するのに十分であるか、IPSECプロトコル値と併用する必要があるかどうかはローカルな問題です。インバウンドトラフィックをユニキャストSASにマッピングするためのこのメカニズムは、すべてのESP実装によってサポートされる必要があります。
If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
IPSECの実装がマルチキャストをサポートする場合、インバウンドIPSECデータグラムをSASにマッピングするために、以下のアルゴリズムを使用してマルチキャストSASをサポートする必要があります。ユニキャストトラフィックのみをサポートする実装では、この脱倍化アルゴリズムを実装する必要はありません。
In many secure multicast architectures (e.g., [RFC3740]), a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
多くの安全なマルチキャストアーキテクチャ（[RFC3740]など）では、中央グループコントローラー/キーサーバーがグループセキュリティ協会のSPIを一方的に割り当てます。このSPIの割り当ては、グループを構成する個々のエンドシステムに存在する主要な管理（IKE）サブシステムと交渉または調整されていません。その結果、グループセキュリティ協会とユニキャストセキュリティ協会が同時に同じSPIを使用できる可能性があります。マルチキャスト利用可能なIPSECの実装は、SPI衝突のコンテキストでも、インバウンドトラフィックを正しく脱化する必要があります。
Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
Security Association Database（SAD）[Ken-Arch]の各エントリは、SAルックアップがSPIに加えて宛先または宛先とソースのIPアドレスを利用するかどうかを示す必要があります。マルチキャストSASの場合、SAルックアップにはプロトコルフィールドが使用されていません。IPSECで保護された各パケットについて、実装は、「最も長い」SA識別子と一致するエントリを見つけるように、SADの検索を実施する必要があります。これに関連して、SPI値に基づいて2つ以上のSADエントリが一致する場合、宛先または宛先とソースに基づいて一致するエントリ（SADエントリに示されているように）が「最長」の一致です。これは、次のように悲しい検索の論理的な順序を意味します。
1. Search the SAD for a match on {SPI, destination address, source address}. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2.
1. {spi、宛先アドレス、ソースアドレス}の一致を悲しみを検索します。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドESPパケットを処理します。それ以外の場合は、ステップ2に進みます。
2. Search the SAD for a match on {SPI, destination address}. If the SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3.
2. {spi、宛先アドレス}の試合を悲しみを検索します。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドESPパケットを処理します。それ以外の場合は、ステップ3に進みます。
3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event.
3. ReceiverがAHとESPの単一のSPIスペースを維持するか、{SPI、プロトコル}で維持することを選択した場合、{SPI}のみの試合を検索してください。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドESPパケットを処理します。それ以外の場合は、パケットを破棄し、監査可能なイベントを記録します。
In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.
実際には、実装はこの検索を加速する方法を選択する場合がありますが、その外部的に表示される動作は、上記の順序でSADを検索することと機能的に同等でなければなりません。たとえば、ソフトウェアベースの実装は、SPIによってハッシュテーブルにインデックスを付けることができます。各ハッシュテーブルバケットのリンクリストの悲しいエントリは、そのリンクリストで最初に最初に最も長いSA識別子を持つこれらの悲しいエントリを持つように並べ替えられます。最短のSA識別子を持つこれらの悲しいエントリは、リンクリストの最後のエントリであるようにソートされます。ハードウェアベースの実装は、一般的に利用可能な3成分アドレス可能なメモリ（TCAM）機能を使用して、本質的に最長の一致検索に影響を与えることができる場合があります。
The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.
INBOUND IPSECトラフィックをSASにマッピングするためにソースと宛先アドレスのマッチングが必要かどうかを示すことは、SAマネジメントプロトコルなど、IKEまたはグループドメインの解釈（GDOI）を使用したネゴシエーションを使用して、マニュアルSA構成の副作用として設定する必要があります。[RFC3547]。通常、ソース固有のマルチキャスト（SSM）[HC03]グループは、SPI、宛先マルチキャストアドレス、およびソースアドレスで構成される3タプルSA識別子を使用します。任意のソースマルチキャストグループSAには、識別子としてSPIと宛先マルチキャストアドレスのみが必要です。
The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.)
範囲1〜255のSPI値のセットは、将来の使用のためにインターネットに割り当てられた数字の権限（IANA）によって予約されています。割り当てられたSPI値の使用がRFCで指定されていない限り、予約されたSPI値は通常IANAによって割り当てられません。ゼロ（0）のSPI値は、ローカルの実装固有の使用のために予約されており、ワイヤーに送信してはなりません。（たとえば、主要な管理実装では、ゼロSPI値を使用して、IPSECの実装が主要な管理エンティティが新しいSAを確立するように要求したが、SAはまだ確立されていない期間中に「セキュリティ協会が存在しない」ことを意味する場合があります。））
This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. Sharing an SA among multiple senders is permitted, though generally not recommended. ESP provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Thus, for a multi-sender SA, the anti-replay features of ESP are not available (see Sections 3.3.3 and 3.4.3.)
この署名されていない32ビットフィールドには、送信されるパケットごとに1つずつ増加するカウンター値、つまりSAあたりのパケットシーケンス番号が含まれています。ユニキャストSAまたはシングルセンダーマルチキャストSAの場合、送信者は、送信されたパケットごとにこのフィールドを増やす必要があります。複数の送信者間でSAを共有することは許可されていますが、一般的には推奨されません。ESPは、複数の送信者の間でパケットカウンターを同期させたり、複数の送信者のコンテキストで受信機パケットカウンターとウィンドウを有意義に管理したりする手段を提供しません。したがって、マルチセンダーSAの場合、ESPのアンチレプレイ機能は利用できません（セクション3.3.3および3.4.3を参照）。
The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, but all ESP implementations MUST be capable of performing the processing described in Sections 3.3.3 and 3.4.3. Thus, the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section (3.4.3) below).
フィールドは必須であり、受信者が特定のSAのアンチレプレイサービスを有効にすることを選択していなくても、常に存在する必要があります。シーケンス番号フィールドの処理は受信機の裁量にありますが、すべてのESP実装は、セクション3.3.3および3.4.3で説明されている処理を実行できる必要があります。したがって、送信者は常にこのフィールドを送信する必要がありますが、受信者はそれに作用する必要はありません（以下の「インバウンドパケット処理」セクション（3.4.3）のシーケンス番号検証の説明を参照）。
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.3 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.
送信者のカウンターとレシーバーのカウンターは、SAが確立されたときに0に初期化されます。（特定のSAを使用して送信された最初のパケットには1のシーケンス番号があります。シーケンス番号の生成方法の詳細については、セクション3.3.3を参照してください。）アンチレプレイが有効になっている場合（デフォルト）、送信されたシーケンス番号は必要です。自転車に乗ることを許可されないでください。したがって、送信者のカウンターとレシーバーのカウンターは、SAで2^32ndパケットを送信する前に（新しいSAと新しいキーを確立することにより）リセットする必要があります。
To support high-speed IPsec implementations, Extended Sequence Numbers (ESNs) SHOULD be implemented, as an extension to the current, 32-bit sequence number field. Use of an ESN MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit sequence numbers are explicitly negotiated. (The ESN feature is applicable to multicast as well as unicast SAs.) The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix A, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the plaintext ESP header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV (if the integrity service is selected). If a separate integrity algorithm is employed, the high order bits are included in the implicit ESP trailer, but are not transmitted, analogous to integrity algorithm padding bits. If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. See Section 3.3.2.2 for processing details.
高速IPSEC実装をサポートするには、現在の32ビットシーケンス番号フィールドへの拡張として、拡張シーケンス番号（ESN）を実装する必要があります。ESNの使用は、SA管理プロトコルによって交渉する必要があります。IKEV2では、この交渉は暗黙的であることに注意してください。32ビットシーケンス番号が明示的にネゴシエートされない限り、デフォルトはESNです。（ESN機能は、マルチキャストおよびユニキャストSASに適用できます。）ESN施設では、SAの64ビットシーケンス番号を使用できます。（詳細については、付録A、「拡張（64ビット）シーケンス番号」を参照してください。）シーケンス番号の32ビットのみが各パケットのプレーンテキストESPヘッダーに送信されるため、パケットオーバーヘッドを最小限に抑えます。高次の32ビットは、送信機と受信機の両方によってシーケンス番号カウンターの一部として維持され、ICVの計算に含まれています（整合性サービスが選択されている場合）。個別の整合性アルゴリズムが採用されている場合、高次ビットは暗黙のESPトレーラーに含まれていますが、整合性アルゴリズムのパディングビットに類似した送信はありません。複合モードアルゴリズムが採用されている場合、アルゴリズムの選択により、高次のESNビットが送信されるか、計算に暗黙的に含まれているかが決定されます。詳細については、セクション3.3.2.2を参照してください。
Payload Data is a variable-length field containing data (from the original IP packet) described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data is carried explicitly in the Payload field, but it is not called out as a separate field in ESP, i.e., the transmission of an explicit IV is invisible to ESP. (See Figure 2.) Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. (Typically, the IV immediately precedes the ciphertext. See Figure 2.) If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the algorithm definition RFC. (If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV), usually is not encrypted per se (see Tables 1 and 2), although it sometimes is referred to as being part of the ciphertext.)
ペイロードデータは、次のヘッダーフィールドで説明されているデータ（元のIPパケットから）を含む可変長さのフィールドです。ペイロードデータフィールドは必須であり、長さが不可欠なバイト数です。ペイロードを暗号化するために使用されるアルゴリズムには、初期化ベクトル（IV）などの暗号化の同期データ（IV）が必要な場合、このデータはペイロードフィールドで明示的に運ばれますが、ESP、つまり伝送では別のフィールドとして呼び出されません。明示的なIVのESPには見えません。（図2を参照）そのような明示的なパケットごとの同期データを必要とする暗号化アルゴリズムは、アルゴリズムがESPで使用される方法を指定するRFCの一部として、そのようなデータの長さ、そのようなデータの構造、およびこのデータの位置を示す必要があります。（通常、IVは暗号文の直前です。図2を参照してください。）そのような同期データが暗黙的である場合、データを導出するためのアルゴリズムはアルゴリズム定義RFCの一部でなければなりません。（ペイロードフィールドに含まれる場合、暗号化の同期データ、たとえば初期化ベクトル（IV）は、通常、それ自体が暗号化されていません（表1および2を参照）。
Note that the beginning of the next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes.
次のレイヤープロトコルヘッダーの開始は、次のようにESPヘッダーの開始に対して整列する必要があることに注意してください。IPv4の場合、このアライメントは4バイトの倍数です。IPv6の場合、アライメントは8バイトの倍数です。
With regard to ensuring the alignment of the (real) ciphertext in the presence of an IV, note the following:
IVの存在下で（実際の）暗号文のアラインメントを確保することに関して、次のことに注意してください。
o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver.
o 一部のIVベースの動作モードでは、受信機はIVを暗号文の開始として扱い、それをアルゴリズムに直接供給します。これらのモードでは、（実際の）暗号文の開始のアラインメントは、受信機では問題ではありません。
o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved.
o 場合によっては、受信機は暗号文から別々にIVを読み取ります。これらの場合、アルゴリズムの仕様は、（実際の）暗号文の調整を達成する方法に対処する必要があります。
Two primary factors require or motivate use of the Padding field.
2つの主要な要因が、パディングフィールドの使用を必要とするか、動機付けます。
o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Padding, Pad Length, and Next Header fields) to the size required by the algorithm.
o プレーンテキストが数倍のバイトの倍数であることを要求する暗号化アルゴリズムが採用されている場合、たとえばブロック暗号のブロックサイズ、パディングフィールドを使用してプレーンテキストを埋める（ペイロードデータ、パディング、パッドの長さで構成される、および次のヘッダーフィールド）アルゴリズムで必要なサイズに。
o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figures above, to ensure that the ICV field (if present) is aligned on a 4-byte boundary.
o 暗号化アルゴリズムの要件に関係なく、パディングも必要な場合があります。具体的には、上記のESPパケット形式の図に示されているように、4バイトの境界（存在する場合）が4バイトの境界に整列されていることを確認するために、パッドの長さと次のヘッダーフィールドを4バイトの単語内で右に揃える必要があります。
Padding beyond that required for the algorithm or alignment reasons cited above could be used to conceal the actual length of the payload, in support of TFC. However, the Padding field described is too limited to be effective for TFC and thus should not be used for that purpose. Instead, the separate mechanism described below (see Section 2.7) should be used when TFC is required.
上記のアルゴリズムまたはアライメントの理由に必要なパディングを使用して、TFCをサポートするために、ペイロードの実際の長さを隠すことができます。ただし、説明されているパディングフィールドは、TFCに効果がないため、制限されすぎるため、その目的に使用してはなりません。代わりに、TFCが必要な場合は、以下に説明する個別のメカニズム（セクション2.7を参照）を使用する必要があります。
The sender MAY add 0 to 255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, subject to the requirements noted above, but all implementations MUST support generation and consumption of padding.
送信者は、パディングの0〜255バイトを追加できます。ESPパケットにパディングフィールドを含めることはオプションであり、上記の要件を条件としていますが、すべての実装はパディングの生成と消費をサポートする必要があります。
o For the purpose of ensuring that the bits to be encrypted are a multiple of the algorithm's block size (first bullet above), the padding computation applies to the Payload Data exclusive of any IV, but including the ESP trailer fields. If a combined algorithm mode requires transmission of the SPI and Sequence Number to effect integrity, e.g., replication of the SPI and Sequence Number in the Payload Data, then the replicated versions of these data items, and any associated, ICV-equivalent data, are included in the computation of the pad length. (If the ESN option is selected, the high-order 32 bits of the ESN also would enter into the computation, if the combined mode algorithm requires their transmission for integrity.)
o 暗号化されるビットがアルゴリズムのブロックサイズ（上記の最初の箇条書き）の倍数であることを確認するために、パディング計算は、ESPトレーラーフィールドを含むIVを除くペイロードデータに適用されます。組み合わせたアルゴリズムモードでは、SPIとシーケンス番号の透過を必要とする場合、整合性、たとえばペイロードデータのSPIとシーケンス番号の複製、これらのデータ項目の複製バージョン、および関連するICV等価データの複製バージョンは、パッド長の計算に含まれています。（ESNオプションが選択されている場合、ESNの高次32ビットも計算に入ります。
o For the purposes of ensuring that the ICV is aligned on a 4-byte boundary (second bullet above), the padding computation applies to the Payload Data inclusive of the IV, the Pad Length, and Next Header fields. If a combined mode algorithm is used, any replicated data and ICV-equivalent data are included in the Payload Data covered by the padding computation.
o ICVが4バイトの境界（上記の2番目の弾丸）に並べられていることを保証する目的で、パディング計算は、IV、パッド長、および次のヘッダーフィールドを含むペイロードデータに適用されます。複合モードアルゴリズムを使用すると、再現されたデータとICV等価データがパディング計算でカバーされているペイロードデータに含まれています。
If Padding bytes are needed but the encryption algorithm does not
specify the padding contents, then the following default processing
MUST be used. The Padding bytes are initialized with a series of
(unsigned, 1-byte) integer values. The first padding byte appended
to the plaintext is numbered 1, with subsequent padding bytes making
up a monotonically increasing sequence: 1, 2, 3, .... When this
padding scheme is employed, the receiver SHOULD inspect the Padding
field. (This scheme was selected because of its relative simplicity,
ease of implementation in hardware, and because it offers limited
protection against certain forms of "cut and paste" attacks in the
absence of other integrity measures, if the receiver checks the
padding values upon decryption.)
If an encryption or combined mode algorithm imposes constraints on the values of the bytes used for padding, they MUST be specified by the RFC defining how the algorithm is employed with ESP. If the algorithm requires checking of the values of the bytes used for padding, this too MUST be specified in that RFC.
暗号化または結合モードアルゴリズムがパディングに使用されるバイトの値に制約を課す場合、アルゴリズムがESPで使用される方法を定義するRFCによって指定する必要があります。アルゴリズムがパディングに使用されるバイトの値をチェックする必要がある場合、これもそのRFCで指定する必要があります。
The Pad Length field indicates the number of pad bytes immediately preceding it in the Padding field. The range of valid values is 0 to 255, where a value of zero indicates that no Padding bytes are present. As noted above, this does not include any TFC padding bytes. The Pad Length field is mandatory.
パッドの長さフィールドは、パディングフィールドの直前のパッドバイトの数を示します。有効な値の範囲は0〜255で、ゼロの値はパディングバイトが存在しないことを示します。上記のように、これにはTFCパディングバイトは含まれていません。パッドの長さフィールドは必須です。
The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP.
次のヘッダーは、ペイロードデータフィールドに含まれるデータのタイプ、例えばIPv4またはIPv6パケット、または次のレイヤーヘッダーとデータを識別する必須の8ビットフィールドです。このフィールドの値は、IANAのWebページで定義されたIPプロトコル番号のセットから選択されます。たとえば、4の値はIPv4を示し、値41はIPv6を示し、6の値はTCPを示します。
To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality (see Section 2.4), the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet. A transmitter MUST be capable of generating dummy packets marked with this value in the next protocol field, and a receiver MUST be prepared to discard such packets, without indicating an error. All other ESP header and trailer fields (SPI, Sequence Number, Padding, Pad Length, Next Header, and ICV) MUST be present in dummy packets, but the plaintext portion of the payload, other than this Next Header field, need not be well-formed, e.g., the rest of the Payload Data may consist of only random bytes. Dummy packets are discarded without prejudice.
トラフィックフローの機密性をサポートするために、パディングトラフィックの迅速な発電と破棄を促進するには、プロトコル値59（「次のヘッダーなし」を意味する）を使用して「ダミー」パケットを指定する必要があります。トランスミッターは、次のプロトコルフィールドでこの値でマークされたダミーパケットを生成できる必要があり、エラーを示さずに受信機をそのようなパケットを破棄する準備ができている必要があります。他のすべてのESPヘッダーおよびトレーラーフィールド（SPI、シーケンス番号、パディング、パッドの長さ、次のヘッダー、およびICV）はダミーパケットに存在する必要がありますが、この次のヘッダーフィールド以外のペイロードのプレーンテキスト部分は、うまくいく必要はありません - たとえば、ペイロードデータの残りの部分は、ランダムバイトのみで構成されている場合があります。ダミーパケットは偏見なく廃棄されます。
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls; for example, the controls might allow an administrator to generate random-length or fixed-length dummy packets.
実装は、この機能を使用するためにローカル管理コントロールを提供する必要があります。コントロールは、ユーザーがこの機能を使用するかどうかを指定し、パラメトリックコントロールも提供できるようにする必要があります。たとえば、コントロールにより、管理者がランダムレングスまたは固定長のダミーパケットを生成できる場合があります。
DISCUSSION: Dummy packets can be inserted at random intervals to mask the absence of actual traffic. One can also "shape" the actual traffic to match some distribution to which dummy traffic is added as dictated by the distribution parameters. As with the packet length padding facility for Traffic Flow Security (TFS), the most secure approach would be to generate dummy packets at whatever rate is needed to maintain a constant rate on an SA. If packets are all the same size, then the SA presents the appearance of a constant bit rate data stream, analogous to what a link crypto would offer at layer 1 or 2. However, this is unlikely to be practical in many contexts, e.g., when there are multiple SAs active, because it would imply reducing the allowed bandwidth for a site, based on the number of SAs, and that would undermine the benefits of packet switching. Implementations SHOULD provide controls to enable local administrators to manage the generation of dummy packets for TFC purposes.
ディスカッション：ダミーパケットをランダムな間隔で挿入して、実際のトラフィックがないことをマスクできます。また、実際のトラフィックを「形作って」、配布パラメーターによって決定されるようにダミートラフィックが追加される分布を一致させることもできます。トラフィックフローセキュリティ（TFS）のパケット長パディング施設と同様に、最も安全なアプローチは、SAの一定の速度を維持するために必要なレートでダミーパケットを生成することです。パケットがすべて同じサイズである場合、SAは一定のビットレートデータストリームの外観を示します。これは、リンクCryptoがレイヤー1または2で提供するものに類似しています。ただし、これは多くのコンテキストで実用的ではありません。SASの数に基づいて、サイトの許可された帯域幅を減らすことを意味するため、複数のSASがアクティブになっている場合、パケットスイッチングの利点が損なわれるためです。実装は、ローカル管理者がTFCの目的でダミーパケットの生成を管理できるようにするためのコントロールを提供する必要があります。
As noted above, the Padding field is limited to 255 bytes in length. This generally will not be adequate to hide traffic characteristics relative to traffic flow confidentiality requirements. An optional field, within the payload data, is provided specifically to address the TFC requirement.
上記のように、パディングフィールドの長さは255バイトに制限されています。これは通常、トラフィックフローの機密性の要件に比べてトラフィックの特性を隠すのに十分ではありません。ペイロードデータ内のオプションのフィールドは、TFC要件に対処するために特別に提供されます。
An IPsec implementation SHOULD be capable of padding traffic by adding bytes after the end of the Payload Data, prior to the beginning of the Padding field. However, this padding (hereafter referred to as TFC padding) can be added only if the Payload Data field contains a specification of the length of the IP datagram. This is always true in tunnel mode, and may be true in transport mode depending on whether the next layer protocol (e.g., IP, UDP, ICMP) contains explicit length information. This length information will enable the receiver to discard the TFC padding, because the true length of the Payload Data will be known. (ESP trailer fields are located by counting back from the end of the ESP packet.) Accordingly, if TFC padding is added, the field containing the specification of the length of the IP datagram MUST NOT be modified to reflect this padding. No requirements for the value of this padding are established by this standard.
IPSECの実装は、パディングフィールドの開始前に、ペイロードデータの終了後にBYTEを追加することにより、トラフィックをパディングできる必要があります。ただし、このパディング（以下TFCパディングと呼ばれる）は、ペイロードデータフィールドにIPデータグラムの長さの仕様が含まれている場合にのみ追加できます。これはトンネルモードで常に真であり、次のレイヤープロトコル（IP、UDP、ICMPなど）に明示的な長さの情報が含まれているかどうかに応じて、輸送モードで真である可能性があります。この長さの情報により、ペイロードデータの真の長さがわかっているため、受信機がTFCパディングを破棄できます。（ESPトレーラーフィールドは、ESPパケットの端からカウントされることで配置されます。）したがって、TFCパディングが追加された場合、IPデータグラムの長さの仕様を含むフィールドをこのパディングを反映するように変更する必要はありません。このパディングの価値に関する要件は、この標準によって確立されていません。
In principle, existing IPsec implementations could have made use of this capability previously, in a transparent fashion. However, because receivers may not have been prepared to deal with this padding, the SA management protocol MUST negotiate this service prior to a transmitter employing it, to ensure backward compatibility. Combined with the convention described in Section 2.6 above, about the use of protocol ID 59, an ESP implementation is capable of generating dummy and real packets that exhibit much greater length variability, in support of TFC.
原則として、既存のIPSEC実装は、透明な方法で以前にこの機能を利用していた可能性があります。ただし、受信機はこのパディングに対処する準備ができていない可能性があるため、SA管理プロトコルは、送信機が使用する前にこのサービスを交渉して、後方互換性を確保する必要があります。Protocol ID 59の使用に関するセクション2.6で説明されている条約と組み合わせることで、ESP実装は、TFCをサポートする、はるかに大きな長さの変動性を示すダミーで実際のパケットを生成することができます。
Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls for the feature.
実装は、この機能を使用するためにローカル管理コントロールを提供する必要があります。コントロールにより、ユーザーはこの機能を使用するかどうかを指定し、機能にパラメトリックコントロールを提供できるようにする必要があります。
The Integrity Check Value is a variable-length field computed over the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer fields (integrity padding and high-order ESN bits, if applicable) are included in the ICV computation. The ICV field is optional. It is present only if the integrity service is selected and is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. The length of the field is specified by the integrity algorithm selected and associated with the SA. The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
整合性チェック値は、ESPヘッダー、ペイロード、およびESPトレーラーフィールドで計算される可変長さフィールドです。暗黙的なESPトレーラーフィールド（該当する場合は、整合性パディングと高次のESNビット）がICV計算に含まれています。ICVフィールドはオプションです。整合性サービスが選択され、ICVを使用する個別の整合性アルゴリズムまたは複合モードアルゴリズムのいずれかによって提供される場合にのみ存在します。フィールドの長さは、選択され、SAに関連付けられた整合性アルゴリズムによって指定されます。整合性アルゴリズムの仕様は、ICVの長さと、検証のための比較ルールと処理手順を指定する必要があります。
ESP may be employed in two ways: transport mode or tunnel mode.
ESPは、輸送モードまたはトンネルモードの2つの方法で採用される場合があります。
In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol. (If AH is also applied to a packet, it is applied to the ESP header, Payload, ESP trailer, and ICV, if present.) (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (This and subsequent diagrams in this section show the ICV field, the presence of which is a function of the security services and the algorithm/mode selected.)
トランスポートモードでは、ESPはIPヘッダーの後に挿入され、次のレイヤープロトコル（TCP、UDP、ICMPなど）がIPv4のコンテキストで挿入されます。）、しかし、次のレイヤープロトコルの前。（AHがパケットにも適用されている場合、ESPヘッダー、ペイロード、ESPトレーラー、およびICVに適用されます。UDP。）次の図は、「前後」ベースでの典型的なIPv4パケットのESP輸送モードの位置を示しています。（このセクションのこれと後続の図は、ICVフィールドを示しています。その存在は、セキュリティサービスと選択されたアルゴリズム/モードの関数です。）
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. Destination options extension header(s) could appear before, after, or both before and after the ESP header depending on the semantics desired. However, because ESP protects only fields after the ESP header, it generally will be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet.
IPv6コンテキストでは、ESPはエンドツーエンドのペイロードと見なされるため、ホップバイホップ、ルーティング、およびフラグメンテーション拡張ヘッダーの後に表示される必要があります。宛先オプション拡張ヘッダーは、必要なセマンティクスに応じて、ESPヘッダーの前、後、またはその両方に表示される可能性があります。ただし、ESPはESPヘッダーの後にフィールドのみを保護するため、通常、ESPヘッダーの後に宛先オプションヘッダーを配置することが望ましいでしょう。次の図は、典型的なIPv6パケットのESP輸送モードの位置を示しています。
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
* = if present, could be before ESP, after ESP, or both
* =存在する場合、ESPの前、ESPの後、またはその両方
Note that in transport mode, for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.
トランスポートモードでは、セキュリティアーキテクチャドキュメントで定義されているように、「バンプインザスタック」または「バンプインザワイヤ」実装の場合、インバウンドおよびアウトバウンドIPフラグメントが必要になる場合があることに注意してください。この仕様に適合し、透明なIPSECサポートを提供するために、再組み立て/断片化。複数のインターフェイスが使用されている場合、これらの実装内でそのような操作を実行するには、特別な注意が必要です。
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets.
トンネルモードでは、「内部」IPヘッダーには究極の（IP）ソースと宛先アドレスが搭載されていますが、「外側」IPヘッダーには、IPSECの「ピア」のアドレス、たとえばセキュリティゲートウェイのアドレスが含まれています。混合内のIPバージョン、つまりIPv4を介したIPv6およびIPv6を介してIPv6を混合しています。トンネルモードでは、ESPは内側のIPヘッダー全体を含む内側のIPパケット全体を保護します。外側のIPヘッダーと比較して、トンネルモードでのESPの位置は、ESPの輸送モードの場合と同じです。次の図は、典型的なIPv4およびIPv6パケットのESPトンネルモードの位置を示しています。
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
ESPを適用した後
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
ESPを適用した後
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
* = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed in the Security Architecture document.
* =存在する場合、外側のIP HDR/拡張機能の構築と内部IP HDR/拡張機能の変更については、セキュリティアーキテクチャドキュメントで説明します。
The mandatory-to-implement algorithms for use with ESP are described in a separate RFC, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported. Note that although both confidentiality and integrity are optional, at least one of these services MUST be selected, hence both algorithms MUST NOT be simultaneously NULL.
ESPで使用するための必須の実装アルゴリズムは、プロトコル自体とは独立してアルゴリズム要件の更新を容易にするために、別のRFCで説明されています。ESPに義務付けられているものを超えた追加のアルゴリズムがサポートされる場合があります。機密性と整合性の両方がオプションですが、これらのサービスの少なくとも1つを選択する必要があるため、両方のアルゴリズムが同時にnullであってはなりません。
The encryption algorithm employed to protect an ESP packet is specified by the SA via which the packet is transmitted/received. Because IP packets may arrive out of order, and not all packets may arrive (packet loss), each packet must carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the plaintext portions of the (outer IP or ESP) packet header. (Note that if plaintext header information is used to derive an IV, that information may become security critical and thus the protection boundary associated with the encryption process may grow. For example, if one were to use the ESP Sequence Number to derive an IV, the Sequence Number generation logic (hardware or software) would have to be evaluated as part of the encryption algorithm implementation. In the case of FIPS 140-2 [NIST01], this could significantly extend the scope of a cryptographic module evaluation.) Because ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Note that because encryption (confidentiality) MAY be an optional service (e.g., integrity-only ESP), this algorithm MAY be "NULL" [Ken-Arch].
ESPパケットを保護するために使用される暗号化アルゴリズムは、パケットが送信/受信されるSAによって指定されます。IPパケットが順に到着する可能性があり、すべてのパケットが到着するわけではないため（パケットの損失）、各パケットは、復号化のために暗号化の同期を確立できるようにするために必要なデータを搭載する必要があります。このデータは、IV（上記のように）として、ペイロードフィールド、たとえばペイロードフィールドで明示的に運ばれる場合があります。または、データは（外側IPまたはESP）パケットヘッダーのプレーンテキスト部分から導き出すことができます。（Plantextヘッダー情報を使用してIVを導出する場合、その情報はセキュリティが重要になる可能性があるため、暗号化プロセスに関連する保護境界が増加する可能性があることに注意してください。たとえば、ESPシーケンス番号を使用してIVを導出する場合、シーケンス番号生成ロジック（ハードウェアまたはソフトウェア）は、暗号化アルゴリズムの実装の一部として評価する必要があります。FIPS140-2[NIST01]の場合、暗号化モジュール評価の範囲を大幅に拡張できます。）ESPで採用されている暗号化アルゴリズムは、プレーンテキストのパディングを提供します。ブロックモードまたはストリームモードの特性を示す場合があります。暗号化（機密性）はオプションのサービス（整合性のみのESPなど）である可能性があるため、このアルゴリズムは「null」[Ken-arch]である可能性があることに注意してください。
To allow an ESP implementation to compute the encryption padding required by a block mode encryption algorithm, and to determine the MTU impact of the algorithm, the RFC for each encryption algorithm used with ESP must specify the padding modulus for the algorithm.
ESP実装がブロックモード暗号化アルゴリズムで必要な暗号化パディングを計算し、アルゴリズムのMTUへの影響を決定できるようにするには、ESPで使用される各暗号化アルゴリズムのRFCはアルゴリズムのパディングモジュールを指定する必要があります。
The integrity algorithm employed for the ICV computation is specified by the SA via which the packet is transmitted/received. As was the case for encryption algorithms, any integrity algorithm employed with ESP must make provisions to permit processing of packets that arrive out of order and to accommodate packet loss. The same admonition noted above applies to use of any plaintext data to facilitate receiver synchronization of integrity algorithms. Note that because the integrity service MAY be optional, this algorithm may be "NULL".
ICV計算に使用される整合性アルゴリズムは、パケットが送信/受信されるSAによって指定されます。暗号化アルゴリズムの場合と同様に、ESPで採用されている整合性アルゴリズムは、順番に到着し、パケットの損失に対応するための規定を作成する必要があります。上記の同じ警告は、整合性アルゴリズムの受信者の同期を容易にするために、プレーンテキストデータの使用に適用されます。整合性サービスはオプションである可能性があるため、このアルゴリズムは「null」である可能性があることに注意してください。
To allow an ESP implementation to compute any implicit integrity algorithm padding required, the RFC for each algorithm used with ESP must specify the padding modulus for the algorithm.
ESP実装が必要な暗黙の整合性アルゴリズムパディングを計算できるようにするには、ESPで使用される各アルゴリズムのRFCは、アルゴリズムのパディングモジュラスを指定する必要があります。
If a combined mode algorithm is employed, both confidentiality and integrity services are provided. As was the case for encryption algorithms, a combined mode algorithm must make provisions for per-packet cryptographic synchronization, to permit decryption of packets that arrive out of order and to accommodate packet loss. The means by which a combined mode algorithm provides integrity for the payload, and for the SPI and (Extended) Sequence Number fields, may vary for different algorithm choices. In order to provide a uniform, algorithm-independent approach to invocation of combined mode algorithms, no payload substructure is defined. For example, the SPI and Sequence Number fields might be replicated within the ciphertext envelope and an ICV may be appended to the ESP trailer. None of these details should be observable externally.
複合モードアルゴリズムが採用されている場合、機密性と整合性サービスの両方が提供されます。暗号化アルゴリズムの場合と同様に、結合されたモードアルゴリズムは、パケットごとの暗号化の同期の規定を作成し、故障して到着したパケットの復号化を可能にし、パケットの損失に対応する必要があります。複合モードアルゴリズムがペイロードの整合性を提供する手段、およびSPIおよび（拡張）シーケンス番号フィールドには、アルゴリズムの選択が異なる場合が異なります。複合モードアルゴリズムの呼び出しに均一なアルゴリズムに依存しないアプローチを提供するために、ペイロードの下部構造は定義されていません。たとえば、SPIおよびシーケンス番号フィールドはCiphertextエンベロープ内で複製され、ICVがESPトレーラーに追加される場合があります。これらの詳細はいずれも外部的に観察する必要はありません。
To allow an ESP implementation to determine the MTU impact of a combined mode algorithm, the RFC for each algorithm used with ESP must specify a (simple) formula that yields encrypted payload size, as a function of the plaintext payload and sequence number sizes.
ESPの実装が複合モードアルゴリズムのMTUの影響を決定できるようにするには、ESPで使用される各アルゴリズムのRFCは、プレーンテキストペイロード数とシーケンス数サイズの関数として、暗号化されたペイロードサイズを生成する（単純な）式を指定する必要があります。
In transport mode, the sender encapsulates the next layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be interrelated in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document.
トランスポートモードでは、送信者はESPヘッダーとESPトレーラーフィールド間の次のレイヤープロトコル情報をカプセル化し、指定されたIPヘッダー（およびIPv6コンテキストのIP拡張ヘッダー）を保持します。トンネルモードでは、外側および内側のIPヘッダー/拡張機能をさまざまな方法で相互に関連付けることができます。カプセル化プロセス中の外側IPヘッダー/拡張機能の構築については、セキュリティアーキテクチャドキュメントで説明します。
ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document.
ESPは、IPSECの実装により、パケットがESP処理を必要とするSAに関連付けられていると判断された後にのみ、アウトバウンドパケットに適用されます。IPSEC処理がアウトバウンドトラフィックに適用されるものを決定するプロセスは、セキュリティアーキテクチャドキュメントで説明されています。
In this section, we speak in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm (RFC 2410). There are several algorithmic options.
このセクションでは、フォーマットの意味合いのために、暗号化が常に適用されるという点で説明します。これは、null暗号化アルゴリズム（RFC 2410）を使用して「機密性なし」が提供されるという理解で行われます。いくつかのアルゴリズムオプションがあります。
If separate confidentiality and integrity algorithms are employed, the Sender proceeds as follows:
個別の機密性と整合性アルゴリズムが採用されている場合、送信者は次のように進行します。
1. Encapsulate (into the ESP Payload field): - for transport mode -- just the original next layer protocol information. - for tunnel mode -- the entire original IP datagram.
1. cancapsulate（ESPペイロードフィールドへ）： - 輸送モードの場合 - 元の次のレイヤープロトコル情報のみ。 - トンネルモードの場合 - 元のIPデータグラム全体。
2. Add any necessary padding -- Optional TFC padding and (encryption) Padding
2. 必要なパディングを追加 - オプションのTFCパディングと（暗号化）パディング
3. Encrypt the result using the key, encryption algorithm, and algorithm mode specified for the SA and using any required cryptographic synchronization data. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the encryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronization data is employed, it is constructed and input to the encryption algorithm as per the algorithm specification. - If integrity is selected, encryption is performed first, before the integrity algorithm is applied, and the encryption does not encompass the ICV field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service (DoS) attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with integrity checking. Note that because the ICV is not protected by encryption, a keyed integrity algorithm must be employed to compute the ICV.
3. SAに指定されたキー、暗号化アルゴリズム、およびアルゴリズムモードを使用して、必要な暗号化同期データを使用して結果を暗号化します。 - 明示的な暗号化同期データ、たとえばIVが示されている場合、アルゴリズムの仕様ごとの暗号化アルゴリズムへの入力であり、ペイロードフィールドに配置されます。 - 暗黙的な暗号化同期データが採用されている場合、アルゴリズムの仕様に従って構築され、暗号化アルゴリズムに入力されます。 - 整合性が選択されている場合、暗号化が最初に実行され、整合性アルゴリズムが適用され、暗号化がICVフィールドを網羅していません。この処理順序は、パケットを復号化する前に、受信機によるリプレイまたは偽のパケットの迅速な検出と拒否を促進するため、サービス拒否（DOS）攻撃の影響を潜在的に減少させる可能性があります。また、受信機でのパケットの並列処理の可能性を可能にします。つまり、復号化は整合性チェックと並行して行われます。ICVは暗号化によって保護されていないため、ICVを計算するためにキー付き整合性アルゴリズムを使用する必要があることに注意してください。
4. Compute the ICV over the ESP packet minus the ICV field. Thus, the ICV computation encompasses the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header. (Note that the last 4 fields will be in ciphertext form, because encryption is performed first.) If the ESN option is enabled for the SA, the high-order 32 bits of the sequence number are appended after the Next Header field for purposes of this computation, but are not transmitted.
4. ESPパケットからICVフィールドを差し引いてICVを計算します。したがって、ICV計算には、SPI、シーケンス番号、ペイロードデータ、パディング（存在する場合）、パッドの長さ、および次のヘッダーが含まれます。（暗号化が最初に実行されるため、最後の4つのフィールドは暗号文の形式であることに注意してください。）SAに対してESNオプションが有効になっている場合、シーケンス番号の高次32ビットは、次のヘッダーフィールドの後に追加されます。この計算ですが、送信されません。
For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a block size specified by the algorithm. If the length of ESP packet (as described above) does not match the block size requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet. (This padding is added after the Next Header field, or after the high-order 32 bits of the sequence number, if ESN is selected.) The block size (and hence the length of the padding) is specified by the integrity algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this question, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's block size.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
一部の整合性アルゴリズムの場合、ICV計算が実行されるバイト文字列は、アルゴリズムによって指定されたブロックサイズの倍数でなければなりません。ESPパケットの長さ（上記のように）がアルゴリズムのブロックサイズ要件と一致しない場合、暗黙のパディングはESPパケットの最後に追加する必要があります。（このパディングは、次のヘッダーフィールドの後、またはESNが選択されている場合、シーケンス番号の高次32ビットの後に追加されます。）ブロックサイズ（したがって、パディングの長さ）は、整合性アルゴリズムの仕様によって指定されます。このパディングはパケットで送信されません。整合性アルゴリズムを定義するドキュメントを参照して、暗黙のパディングが必要かどうかを判断するために相談する必要があります。ドキュメントがこの質問への回答を指定していない場合、デフォルトは、パッキングバイトが必要であるがアルゴリズムが指定していない場合、パケットの長さをアルゴリズムのブロックサイズに一致させるために必要に応じて、暗黙のパディングが必要であると仮定することです。パディングの内容、パディングオクテットの値はゼロでなければなりません。
If a combined confidentiality/integrity algorithm is employed, the Sender proceeds as follows:
組み合わせた機密性/整合性アルゴリズムが採用されている場合、送信者は次のように進行します。
1. Encapsulate into the ESP Payload Data field: - for transport mode -- just the original next layer protocol information. - for tunnel mode -- the entire original IP datagram.
1. ESPペイロードデータフィールドへのカプセル化： - トランスポートモードの場合 - 元の次のレイヤープロトコル情報のみ。 - トンネルモードの場合 - 元のIPデータグラム全体。
2. Add any necessary padding -- includes optional TFC padding and (encryption) Padding.
2. 必要なパディングを追加します - オプションのTFCパディングと（暗号化）パディングが含まれています。
3. Encrypt and integrity protect the result using the key and combined mode algorithm specified for the SA and using any required cryptographic synchronization data. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the combined mode algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronization data is employed, it is constructed and input to the encryption algorithm as per the algorithm specification. - The Sequence Number (or Extended Sequence Number, as appropriate) and the SPI are inputs to the algorithm, as they must be included in the integrity check computation. The means by which these values are included in this computation are a function of the combined mode algorithm employed and thus not specified in this standard. - The (explicit) ICV field MAY be a part of the ESP packet format when a combined mode algorithm is employed. If one is not used, an analogous field usually will be a part of the ciphertext payload. The location of any integrity fields, and the means by which the Sequence Number and SPI are included in the integrity computation, MUST be defined in an RFC that defines the use of the combined mode algorithm with ESP.
3. 暗号化と整合性は、SAに指定されたキーと結合モードのアルゴリズムを使用して、必要な暗号化同期データを使用して結果を保護します。 - 明示的な暗号化同期データ、たとえばIVが示されている場合、アルゴリズムの仕様ごとに複合モードアルゴリズムに入力され、ペイロードフィールドに配置されます。 - 暗黙的な暗号化同期データが採用されている場合、アルゴリズムの仕様に従って構築され、暗号化アルゴリズムに入力されます。 - 整合性チェック計算に含める必要があるため、シーケンス番号（または必要に応じて拡張シーケンス番号）とSPIはアルゴリズムへの入力です。これらの値がこの計算に含まれる手段は、採用されている結合モードアルゴリズムの関数であり、したがって、この標準では指定されていません。 - （明示的な）ICVフィールドは、複合モードアルゴリズムが採用されている場合、ESPパケット形式の一部である場合があります。使用されていない場合、類似のフィールドは通常、暗号文のペイロードの一部になります。整合性フィールドの位置、およびシーケンス番号とSPIが整合性計算に含まれる平均は、ESPを使用した複合モードアルゴリズムの使用を定義するRFCで定義する必要があります。
The sender's counter is initialized to 0 when an SA is established. The sender increments the sequence number (or ESN) counter for this SA and inserts the low-order 32 bits of the value into the Sequence Number field. Thus, the first packet sent using a given SA will contain a sequence number of 1.
送信者のカウンターは、SAが確立されたときに0に初期化されます。送信者は、このSAのシーケンス番号（またはESN）カウンターを増分し、値の32ビットをシーケンス番号フィールドに挿入します。したがって、特定のSAを使用して送信された最初のパケットには、1のシーケンス番号が含まれます。
If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the sequence number to cycle. An attempt to transmit a packet that would result in sequence number overflow is an auditable event. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID.
アンチレプレイが有効になっている場合（デフォルト）、送信者はシーケンス番号フィールドに新しい値を挿入する前にカウンターが循環していないことを確認します。言い換えれば、送信者は、SAにパケットを送信してはなりません。シーケンス数のオーバーフローをもたらすパケットを送信しようとする試みは、監査可能なイベントです。このイベントの監査ログエントリには、SPI値、現在の日付/時間、ソースアドレス、宛先アドレス、および（IPv6で）クリアテキストフローIDを含める必要があります。
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3). Thus, typical behavior of an ESP implementation calls for the sender to establish a new SA when the Sequence Number (or ESN) cycles, or in anticipation of this value cycling.
送信者は、レシーバーから特に通知されない限り、アンチレプレイがデフォルトとして有効になることを想定しています（セクション3.4.3を参照）。したがって、ESP実装の典型的な動作では、シーケンス番号（またはESN）サイクルのときに新しいSAを確立するために、またはこの値サイクリングを予想して送信者が新しいSAを確立する必要があります。
If the key used to compute an ICV is manually distributed, a compliant implementation SHOULD NOT provide anti-replay service. If a user chooses to employ anti-replay in conjunction with SAs that are manually keyed, the sequence number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced. (See Section 5.)
ICVの計算に使用されるキーが手動で分散されている場合、準拠した実装はレプレイ防止サービスを提供してはなりません。ユーザーが手動でキー付きのSASと組み合わせてアンチレプレイを使用することを選択した場合、キーが交換されるまで、送信者のシーケンス番号カウンターをローカル再起動などで正しく維持する必要があります。（セクション5を参照してください）
If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter. However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.)
アンチレプレイが無効になっている場合（上記のように）、送信者はカウンターを監視またはリセットする必要はありません。ただし、送信者は引き続きカウンターを増分し、最大値に達すると、カウンターはゼロに戻ります。（この標準の範囲外のアンチレプレイメカニズムが送信者と受信機の間で交渉されない限り、この動作はマルチセンダー、マルチキャストSASに推奨されます。）
If ESN (see Appendix) is selected, only the low-order 32 bits of the sequence number are transmitted in the Sequence Number field, although both sender and receiver maintain full 64-bit ESN counters. The high order 32 bits are included in the integrity check in an algorithm/mode-specific fashion, e.g., the high-order 32 bits may be appended after the Next Header field when a separate integrity algorithm is employed.
ESN（付録を参照）が選択されている場合、シーケンス番号フィールドに低次の32ビットのみがシーケンス番号フィールドに送信されますが、送信者と受信機の両方が完全な64ビットESNカウンターを維持しています。高次の32ビットは、アルゴリズム/モード固有のファッションでの整合性チェックに含まれています。たとえば、個別の整合性アルゴリズムが採用されている次のヘッダーフィールドの後に高次の32ビットが追加される場合があります。
Note: If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA.
注：レシーバーがSAのアンチレプレイを有効にしないことを選択した場合、レシーバーはSA管理プロトコルでESNをネゴシエートしてはなりません。ESNを使用すると、受信者がアンチレプレイウィンドウを管理する必要があります（ICV計算で使用されているESNの高次ビットの正しい値を決定するため）。これは一般に概念に反しています。SAのアンチレプレイを無効にする。
If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, which may be a fragment of an IP datagram. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments.
必要に応じて、IPSEC実装内でESP処理後に断片化が実行されます。したがって、Transport Mode ESPは、IPデータグラム全体（IPフラグメントではなく）にのみ適用されます。ESPが適用されているIPパケット自体は、ルーター自体が途中で断片化される可能性があり、そのようなフラグメントは、受信機でESP処理する前に再組み立てする必要があります。トンネルモードでは、ESPがIPパケットに適用されます。これは、IPデータグラムのフラグメントである可能性があります。たとえば、セキュリティゲートウェイまたは「スタックにぶつかる」または「ワイヤーにぶつかる」IPSEC実装（セキュリティアーキテクチャドキュメントで定義されているように）は、そのようなフラグメントにトンネルモードESPを適用する場合があります。
NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet.
注：輸送モードの場合 - セクション3.1.1の最後に述べたように、スタックの隆起と衝突の実装は、最初にローカルIPレイヤーによって断片化されたパケットを再組み立てし、次に適用する必要がある場合があります。IPSEC、そして結果のパケットをフラグメントします。
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
注：IPv6の場合 - バンプインスタックとワイヤーの実装の実装の場合、すべての拡張ヘッダーを調べて、フラグメンテーションヘッダーがあるかどうかを判断する必要があります。IPSEC処理に。
Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance. Moreover, the requirement for an ESP receiver to accept fragments for reassembly creates denial of service vulnerabilities. Thus, an ESP implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an ESP implementation MUST support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. Details of the support required for MTU management are contained in the Security Architecture document.
IPSECの実装によって実行されるか、IPSECピア間のパスに沿ったルーターによって実行されるかどうかにかかわらず、断片化はパフォーマンスを大幅に低下させます。さらに、ESPレシーバーが再組み立てのためにフラグメントを受け入れるための要件は、サービスの脆弱性の否定を生み出します。したがって、ESPの実装は、断片化をサポートしないことを選択し、PATH MTU（PMTU）の発見を促進するために、送信されたパケットをDFビットでマークする場合があります。いずれにせよ、ESPの実装は、断片化の可能性を最小限に抑えるために、ICMP PMTUメッセージ（またはネイティブホスト実装の同等の内部信号）の生成をサポートする必要があります。MTU管理に必要なサポートの詳細は、セキュリティアーキテクチャドキュメントに含まれています。
If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
必要に応じて、ESP処理前に再組み立てが実行されます。処理用にESPに提供されるパケットがIPフラグメントのように見える場合、つまりオフセットフィールドがゼロではないか、フラグメントフラグが設定されている場合、受信機はパケットを破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6で）フローIDを含める必要があります。
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zeroing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet.
注：パケットの再組み立ての場合、現在のIPv4仕様では、オフセットフィールドのゼロ化またはより多くのフラグメントフラグのクリアのいずれも必要ありません。IPSECによって再組み立てされたパケットを処理するために（見かけのフラグメントとして破棄するのではなく）、IPコードはパケットを再組み立てした後、これら2つのことを行う必要があります。
Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked, whether 32- or 64-bit sequence numbers are employed for the SA, and whether the (explicit) ICV field should be present (and if so, its size). Also, the SAD entry will specify the algorithms and keys to be employed for decryption and ICV computation (if applicable).
ESPヘッダーを含むパケットを受け取ると、受信者はSADのルックアップを介して適切な（単方向）SAを決定します。ユニキャストSAの場合、この決定は、セクション2.1で説明されているように、SPIまたはSPI Plusプロトコルフィールドに基づいています。実装がマルチキャストトラフィックをサポートする場合、宛先アドレスもルックアップで（SPIに加えて）採用され、セクション2.1で説明されているように、送信者アドレスも採用される場合があります。（このプロセスについては、セキュリティアーキテクチャドキュメントで詳細に説明しています。）SAの悲しいエントリは、SAに32ビットまたは64ビットのシーケンス番号が採用されているかどうか、シーケンス番号フィールドがチェックされるかどうか、および（明示的）ICVフィールドが存在する必要があります（もしそうなら、そのサイズ）。また、SADエントリは、復号化とICV計算（該当する場合）に使用するアルゴリズムとキーを指定します。
If no valid Security Association exists for this packet, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID.
このパケットに有効なセキュリティ協会が存在しない場合、受信者はパケットを破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6で）クリアテキストフローIDを含める必要があります。
(Note that SA management traffic, such as IKE packets, does not need to be processed based on SPI, i.e., one can demultiplex this traffic separately based on Next Protocol and Port fields, for example.)
（IKEパケットなどのSA管理トラフィックは、SPIに基づいて処理する必要はないことに注意してください。つまり、次のプロトコルとポートフィールドに基づいてこのトラフィックを個別に非難することができます。）
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below.
すべてのESP実装は、Anti Replayサービスをサポートする必要がありますが、その使用は、SAごとにレシーバーによって有効または無効にされる場合があります。SAのESP整合性サービスも有効になっていない限り、このサービスを有効にしてはなりません。アンチレプレイは、マルチキャストSASと同様にユニキャストに適用できます。ただし、この標準は、マルチセンダーSA（ユニキャストまたはマルチキャスト）にアンチレプレイを提供するためのメカニズムを指定していません。そのようなSAの反レプレイアンチレプレイメカニズムのネゴシエーション（または手動構成）がない場合、以下に示すように（ネゴシエーションまたは手動構成を介して）SA BEのシーケンス番号の送信者と受信者のチェックが推奨されます。
If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.3), if an SA establishment protocol is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection.
受信機がSAのアンチレプレイを有効にしない場合、シーケンス番号にインバウンドチェックは実行されません。ただし、送信者の観点から見ると、デフォルトはレシーバーでアンチレプレイが有効になっていると仮定することです。送信者に不必要なシーケンス番号の監視とSAセットアップを行わせないように（セクション3.3.3を参照）、SA設立プロトコルが採用されている場合、受信者はSA施設中に送信者に通知する必要があります。。
If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
受信者がこのSAのアンチレプレイサービスを有効にした場合、SAの受信パケットカウンターは、SAが確立されたときにゼロに初期化する必要があります。受信した各パケットについて、受信機は、このSAの存続期間中に受信した他のパケットのシーケンス番号を複製しないシーケンス番号が含まれていることを確認する必要があります。これは、重複パケットの拒否を速めるために、SAに一致した後にパケットに適用される最初のESPチェックである必要があります。
ESP permits two-stage verification of packet sequence numbers. This capability is important whenever an ESP implementation (typically the cryptographic module portion thereof) is not capable of performing decryption and/or integrity checking at the same rate as the interface(s) to unprotected networks. If the implementation is capable of such "line rate" operation, then it is not necessary to perform the preliminary verification stage described below.
ESPは、パケットシーケンス番号の2段階の検証を許可します。この機能は、ESP実装（通常、暗号化モジュールの部分）が、保護されていないネットワークに対してインターフェイスと同じレートで復号化や整合性チェックを実行できない場合に重要です。実装がこのような「ラインレート」操作が可能な場合、以下で説明する予備検証段階を実行する必要はありません。
The preliminary Sequence Number check is effected utilizing the Sequence Number value in the ESP Header and is performed prior to integrity checking and decryption. If this preliminary check fails, the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point.
予備シーケンス番号チェックは、ESPヘッダーのシーケンス番号値を使用して行われ、整合性チェックと復号化の前に実行されます。この予備的なチェックが失敗した場合、パケットは破棄されるため、受信者による暗号化操作の必要性が回避されます。予備チェックが成功した場合、この時点でシーケンス番号の整合性が検証されていないため、レシーバーはまだローカルカウンターを変更できません。
Duplicates are rejected through the use of a sliding receive window. How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.
重複は、スライド受信ウィンドウを使用して拒否されます。ウィンドウの実装方法はローカルの問題ですが、次のテキストは、実装が示す必要がある機能を説明しています。
The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain sequence numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted, but the receiver employs the full sequence number computed using the high-order 32 bits for the indicated SA (from his local counter) when checking the received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver sequence number counter MAY be employed, as described in the Appendix.)
ウィンドウの「右」の端は、このSAで受信した最高の検証されたシーケンス数値を表します。ウィンドウの「左」の端よりも低いシーケンス番号を含むパケットは拒否されます。ウィンドウ内にあるパケットは、ウィンドウ内の受信したパケットのリストに対してチェックされます。SAに対してESNオプションが選択されている場合、シーケンス番号の低次の32ビットのみが明示的に送信されますが、受信機は、指定されたSAの高次32ビットを使用して計算された完全なシーケンス番号を使用します（ローカルカウンターから）受信したシーケンス番号を受信ウィンドウに対してチェックするとき。完全なシーケンス番号の構築において、パケットに運ばれる低次の32ビットがレシーバーのシーケンス番号の低次の32ビットよりも値が低い場合、レシーバーは高次の32ビットが増加し、移動していると想定しています。新しいシーケンス番号サブスペースに。（このアルゴリズムは、2 ** 32-1パケットの大きな単一のSAの受信のギャップに対応します。大きなギャップが発生した場合、レシーバーシーケンス番号カウンターの再同期のための追加のヒューリスティックチェックが使用される場合があります。付録。）
If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, and if a separate integrity algorithm is employed, then the receiver proceeds to integrity verification. If a combined mode algorithm is employed, the integrity check is performed along with decryption. In either case, if the integrity check fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the integrity verification succeeds. (If a combined mode algorithm is being used, then the integrity protected Sequence Number must also match the Sequence Number used for anti-replay protection.)
受信したパケットがウィンドウ内に収まり、重複していない場合、またはパケットがウィンドウの右側にある場合、および個別の整合性アルゴリズムが使用されている場合、レシーバーは整合性の検証に進みます。複合モードアルゴリズムが採用されている場合、整合性チェックは復号化とともに実行されます。どちらの場合でも、整合性チェックが失敗した場合、受信者は受信したIPデータグラムを無効として破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6で）フローIDを含める必要があります。受信ウィンドウは、整合性の確認が成功した場合にのみ更新されます。（複合モードアルゴリズムが使用されている場合、整合性保護されたシーケンス番号も、レプレイ防止防止に使用されるシーケンス番号と一致する必要があります。）
A minimum window size of 32 packets MUST be supported when 32-bit sequence numbers are employed; a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The receive window size should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard.
32ビットシーケンス番号が使用されている場合、32パケットの最小ウィンドウサイズをサポートする必要があります。64のウィンドウサイズが推奨され、デフォルトとして使用する必要があります。別のウィンドウサイズ（最小よりも大きい）は、受信機によって選択される場合があります。（受信者は、ウィンドウサイズを送信者に通知しません。）保証の問題に関係なく、より高いスピード環境では、受信ウィンドウサイズを増やす必要があります。最小値と推奨される値は、非常に高速（マルチギガビット/秒）デバイスのウィンドウサイズを受信します。この標準では指定されていません。
As with outbound processing, there are several options for inbound processing, based on features of the algorithms employed.
アウトバウンド処理と同様に、採用されているアルゴリズムの機能に基づいて、インバウンド処理にはいくつかのオプションがあります。
If separate confidentiality and integrity algorithms are employed processing proceeds as follows:
別々の機密性と整合性アルゴリズムが採用されている場合、処理手続きは次のとおりです。
1. If integrity has been selected, the receiver computes the ICV over the ESP packet minus the ICV, using the specified integrity algorithm and verifies that it is the same as the ICV carried in the packet. Details of the computation are provided below.
1. 整合性が選択されている場合、受信機は、指定された整合性アルゴリズムを使用して、ESPパケットを除いてICVを除いてICVを計算し、パケットに運ばれたICVと同じであることを確認します。計算の詳細を以下に示します。
If the computed and received ICVs match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the cleartext Flow ID.
計算されたICVSと受信したICVが一致する場合、データグラムは有効であり、受け入れられます。テストが失敗した場合、受信者は受信したIPデータグラムを無効として破棄する必要があります。これは監査可能なイベントです。ログデータには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6の場合）がクリアテキストフローIDを含める必要があります。
Implementation Note:
実装注：
Implementations can use any set of steps that results in the same result as the following set of steps. Begin by removing and saving the ICV field. Next check the overall length of the ESP packet minus the ICV field. If implicit padding is required, based on the block size of the integrity algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field, or after the high-order 32 bits of the sequence number if ESN is selected. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification.
実装は、次の一連のステップと同じ結果をもたらす一連のステップを使用できます。ICVフィールドを削除および保存することから始めます。次に、ESPパケットの全体の長さをICVフィールドを差し引いて確認します。インテグリティアルゴリズムのブロックサイズに基づいて暗黙のパディングが必要な場合は、ESNフィールドの直後、またはESNのシーケンス番号の高次32ビットの直後にESPパケットの最後にゼロで満たされたバイトを追加します選択。ICV計算を実行し、アルゴリズムの仕様で定義された比較ルールを使用して、結果を保存された値と比較します。
2. The receiver decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. As in Section 3.3.2, we speak here in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm (RFC 2410).
2. 受信機は、SAで示されるキー、暗号化アルゴリズム、アルゴリズムモード、暗号化同期データ（存在する場合）を使用して、ESPペイロードデータ、パディング、パッドの長さ、および次のヘッダーを復号化します。セクション3.3.2と同様に、フォーマットの意味合いのために常に暗号化が適用されるという点でここで説明します。これは、null暗号化アルゴリズム（RFC 2410）を使用して「機密性なし」が提供されるという理解で行われます。
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification.
- 明示的な暗号化同期データ、たとえばIVが示されている場合、アルゴリズムの仕様に従って、ペイロードフィールドと復号化アルゴリズムへの入力から取得されます。
- If implicit cryptographic synchronization data is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification.
- 暗黙的な暗号化同期データが示されている場合、IVのローカルバージョンが構築され、アルゴリズムの仕様に従って復号化アルゴリズムに入力されます。
3. The receiver processes any Padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer.
3. 受信機は、暗号化アルゴリズムの仕様で指定されているパディングを処理します。デフォルトのパディングスキーム（セクション2.4を参照）が使用されている場合、受信者は、復号化されたデータを次のレイヤーに渡す前に、パディングを取り外す前にパディングフィールドを検査する必要があります。
4. The receiver checks the Next Header field. If the value is "59" (no next header), the (dummy) packet is discarded without further processing.
4. レシーバーは次のヘッダーフィールドをチェックします。値が「59」（次のヘッダーなし）の場合、（ダミー）パケットはさらに処理せずに破棄されます。
5. The receiver reconstructs the original IP datagram from:
5. レシーバーは、以下の元のIPデータグラムを再構築します。
- for transport mode -- outer IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- the entire IP datagram in the ESP Payload field.
- トランスポートモードの場合 - 外側のIPヘッダーとESPペイロードフィールドの元の次のレイヤープロトコル情報 - トンネルモード - ESPペイロードフィールドのIPデータグラム全体。
The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. This processing "discards" any (optional) TFC padding that has been added for traffic flow confidentiality. (If present, this will have been inserted after the IP datagram (or transport-layer frame) and before the Padding field (see Section 2.4).)
元のデータグラムを再構築するための正確な手順は、モード（トランスポートまたはトンネル）に依存し、セキュリティアーキテクチャドキュメントで説明されています。少なくとも、IPv6コンテキストでは、受信者は、次のヘッダーフィールドで識別されたプロトコルによる処理を容易にするために、復号化されたデータが8バイトのアライメントされていることを確認する必要があります。この処理は、トラフィックフローの機密性のために追加された（オプションの）TFCパディングを「破棄」します。（存在する場合、これはIPデータグラム（または輸送層フレーム）およびパディングフィールドの前に挿入されます（セクション2.4を参照）。）
If integrity checking and encryption are performed in parallel, integrity checking MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks.
整合性チェックと暗号化が並行して実行される場合、復号化されたパケットが渡される前に、整合性チェックを完了する必要があります。この処理の順序は、パケットを復号化する前に、受信機によるリプレイまたは偽のパケットの迅速な検出と拒否を促進するため、サービス攻撃の拒否の影響を減らす可能性があります。
Note: If the receiver performs decryption in parallel with integrity checking, care must be taken to avoid possible race conditions with regard to packet access and extraction of the decrypted packet.
注：受信機が整合性チェックと並行して復号化を実行する場合、パケットアクセスと復号化されたパケットの抽出に関して、可能な人種条件を避けるために注意する必要があります。
If a combined confidentiality and integrity algorithm is employed, then the receiver proceeds as follows:
組み合わせた機密性と整合性アルゴリズムが採用されている場合、レシーバーは次のように進行します。
1. Decrypts and integrity checks the ESP Payload Data, Padding, Pad Length, and Next Header, using the key, algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. The SPI from the ESP header, and the (receiver) packet counter value (adjusted as required from the processing described in Section 3.4.3) are inputs to this algorithm, as they are required for the integrity check.
1. 復号化と整合性は、SAで示されるキー、アルゴリズム、アルゴリズムモード、暗号化同期データ（存在する場合）を使用して、ESPペイロードデータ、パディング、パッドの長さ、および次のヘッダーをチェックします。ESPヘッダーからのSPI、および（受信機）パケットカウンター値（セクション3.4.3で説明した処理から必要に応じて調整）は、整合性チェックに必要なため、このアルゴリズムへの入力です。
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification.
- 明示的な暗号化同期データ、たとえばIVが示されている場合、アルゴリズムの仕様に従って、ペイロードフィールドと復号化アルゴリズムへの入力から取得されます。
- If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification.
- 暗黙的な暗号化同期データ、たとえばIVが示されている場合、ALGORITHM仕様に従ってIVのローカルバージョンが構築され、復号化アルゴリズムに入力されます。
2. If the integrity check performed by the combined mode algorithm fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID.
2. 複合モードアルゴリズムによって実行された整合性チェックが失敗した場合、受信者は受信したIPデータグラムを無効として破棄する必要があります。これは監査可能なイベントです。ログデータには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6で）クリアテキストフローIDを含める必要があります。
3. Process any Padding as specified in the encryption algorithm specification, if the algorithm has not already done so.
3. アルゴリズムがまだ行っていない場合は、暗号化アルゴリズムの仕様で指定されているパディングを処理します。
4. The receiver checks the Next Header field. If the value is "59" (no next header), the (dummy) packet is discarded without further processing.
4. レシーバーは次のヘッダーフィールドをチェックします。値が「59」（次のヘッダーなし）の場合、（ダミー）パケットはさらに処理せずに破棄されます。
5. Extract the original IP datagram (tunnel mode) or transport-layer frame (transport mode) from the ESP Payload Data field. This implicitly discards any (optional) padding that has been added for traffic flow confidentiality. (If present, the TFC padding will have been inserted after the IP payload and before the Padding field (see Section 2.4).)
5. ESPペイロードデータフィールドから元のIPデータグラム（トンネルモード）または輸送層フレーム（輸送モード）を抽出します。これは、トラフィックフローの機密性のために追加された（オプションの）パディングを暗黙的に破棄します。（存在する場合、TFCパディングは、IPペイロード後およびパディングフィールドの前に挿入されます（セクション2.4を参照）。）
Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined.
ESPを実装するすべてのシステムが監査を実装するわけではありません。ただし、ESPが監査をサポートするシステムに組み込まれている場合、ESP実装も監査をサポートする必要があり、システム管理者がESPの監査を有効または無効にすることを許可する必要があります。ほとんどの場合、監査の粒度は地元の問題です。ただし、この仕様でいくつかの監査可能なイベントが特定されており、これらの各イベントでは、監査ログに含まれるべき最小の情報セットが定義されています。
- No valid Security Association exists for a session. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- セッションには有効なセキュリティ協会は存在しません。このイベントの監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6の場合）がクリアテキストフローIDを含める必要があります。
- A packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
- 処理のためにESPに提供されるパケットはIPフラグメントのように見えます。つまり、オフセットフィールドはゼロではないか、フラグメントフラグが設定されています。このイベントの監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6で）フローIDを含める必要があります。
- Attempt to transmit a packet that would result in Sequence Number overflow. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- シーケンス数のオーバーフローをもたらすパケットを送信しようとします。このイベントの監査ログエントリには、SPI値、現在の日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6の場合）がクリアテキストフローIDを含める必要があります。
- The received packet fails the anti-replay checks. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID.
- 受信したパケットは、アンチレプレイチェックに失敗します。このイベントの監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6で）フローIDを含める必要があります。
- The integrity check fails. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the Flow ID.
- 整合性チェックが失敗します。このイベントの監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6の場合）フローIDを含める必要があります。
Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
追加情報は、これらの各イベントの監査ログにも含まれる場合があり、この仕様で明示的に呼び出されない追加のイベントは、監査ログエントリになる可能性があります。受信者が、そのようなアクションを介してサービスの拒否を誘導する可能性があるため、監査可能なイベントの検出に応じて、監視可能な送信者にメッセージを送信する必要はありません。
Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here for unicast traffic, and MUST comply with all additional packet processing requirements levied by the Security Architecture document [Ken-Arch]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service requires correct maintenance of the counter state at the sender (across local reboots, etc.), until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus, a compliant implementation SHOULD NOT provide anti-replay service in conjunction with SAs that are manually keyed.
この仕様への適合性またはコンプライアンスを主張する実装は、ユニキャストトラフィックのためにここで説明するESP構文と処理を実装する必要があり、セキュリティアーキテクチャドキュメント[Ken-Arch]に課されるすべての追加のパケット処理要件を遵守する必要があります。さらに、実装がマルチキャストトラフィックをサポートすると主張する場合、そのようなトラフィックのサポートのために指定された追加要件に準拠する必要があります。ICVの計算に使用されるキーが手動で分布している場合、アンチレプレイサービスの正しい提供には、送信者のカウンター状態の正しいメンテナンスが必要です（ローカル再起動など）、キーが交換されるまで、そしておそらくそこにありますカウンターオーバーフローが差し迫っていた場合、自動回復規定はありません。したがって、準拠した実装は、手動でキー化されたSASと組み合わせて、アンチレプレイサービスを提供してはなりません。
The mandatory-to-implement algorithms for use with ESP are described in a separate document [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for ESP, MAY be supported.
ESPで使用するための必須の実装アルゴリズムは、プロトコル自体とは独立してアルゴリズム要件の更新を容易にするために、別のドキュメント[EAS04]で説明されています。ESPに義務付けられているものを超えた追加のアルゴリズムがサポートされる場合があります。
Because use of encryption in ESP is optional, support for the "NULL" encryption algorithm also is required to maintain consistency with the way ESP services are negotiated. Support for the confidentiality-only service version of ESP is optional. If an implementation offers this service, it MUST also support the negotiation of the "NULL" integrity algorithm. NOTE that although integrity and encryption may each be "NULL" under the circumstances noted above, they MUST NOT both be "NULL".
ESPでの暗号化の使用はオプションであるため、ESPサービスの交渉方法との一貫性を維持するには、「null」暗号化アルゴリズムのサポートも必要です。ESPの機密のみのサービスバージョンのサポートはオプションです。実装がこのサービスを提供する場合、「null」整合性アルゴリズムの交渉もサポートする必要があります。上記の状況下では、それぞれ整合性と暗号化が「ヌル」になる可能性がありますが、両方とも「ヌル」であってはなりません。
Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
セキュリティはこのプロトコルの設計の中心であるため、セキュリティ上の考慮事項は仕様に浸透します。IPSECプロトコルの使用に関する追加のセキュリティ関連の側面については、セキュリティアーキテクチャドキュメントで説明します。
This document differs from RFC 2406 in a number of significant ways.
このドキュメントは、いくつかの重要な方法でRFC 2406とは異なります。
o Confidentiality-only service -- now a MAY, not a MUST.
o 機密性のみのサービス - 今では必須ではありません。
o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. o Extended Sequence Number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. o Payload data -- broadened model to accommodate combined mode algorithms. o Padding for improved traffic flow confidentiality -- added requirement to be able to add bytes after the end of the IP Payload, prior to the beginning of the Padding field. o Next Header -- added requirement to be able to generate and discard dummy padding packets (Next Header = 59) o ICV -- broadened model to accommodate combined mode algorithms. o Algorithms -- Added combined confidentiality mode algorithms. o Moved references to mandatory algorithms to a separate document. o Inbound and Outbound packet processing -- there are now two paths: (1) separate confidentiality and integrity algorithms and (2) combined confidentiality mode algorithms. Because of the addition of combined mode algorithms, the encryption/decryption and integrity sections have been combined for both inbound and outbound packet processing.
o SPI -UnicastおよびマルチキャストSASのSADルックアップのための均一なアルゴリズムを指定するように変更され、より広範なマルチキャストテクノロジーをカバーしています。ユニキャストの場合、SPIはSAを選択するために単独で使用されるか、レシーバーのオプションでプロトコルと組み合わせることができます。マルチキャストSASの場合、SPIは宛先アドレス、およびオプションでソースアドレスと組み合わされて、SAを選択します。o拡張シーケンス番号 - 非常に高速通信のために64ビットシーケンス番号の新しいオプションを追加しました。マルチキャストSASおよびマルチセンダーSASの送信者と受信機処理要件を明確にしました。oペイロードデータ - 複合モードアルゴリズムに対応するための拡張モデル。oトラフィックフローの機密性を改善するためのパディング - パディングフィールドの開始前に、IPペイロードの終了後にバイトを追加できる要件を追加しました。o次のヘッダー - ダミーパディングパケットを生成して破棄するための要件を追加しました（次のヘッダー= 59）o ICV-組み合わせモードアルゴリズムに対応するための拡大モデル。oアルゴリズム - 組み合わせた機密性モードアルゴリズムが追加されました。o必須アルゴリズムへの参照を別のドキュメントに移動しました。oインバウンドパケット処理とアウトバウンドパケット処理 - 現在、2つのパスがあります。（1）個別の機密性と整合性アルゴリズムと（2）整合された機密性モードアルゴリズム。結合されたモードアルゴリズムが追加されているため、インバウンドパケット処理とアウトバウンドパケット処理の両方で、暗号化/復号化と整合性セクションが組み合わされています。
There is no version number in ESP and no mechanism enabling IPsec peers to discover or negotiate which version of ESP each is using or should use. This section discusses consequent backward-compatibility issues.
ESPにはバージョン番号がなく、IPSECピアがそれぞれを使用または使用するESPのバージョンを発見または交渉できるメカニズムはありません。このセクションでは、結果として生じる後方互換性の問題について説明します。
First, if none of the new features available in ESP v3 are employed, then the format of an ESP packet is identical in ESP v2 and v3. If a combined mode encryption algorithm is employed, a feature supported only in ESP v3, then the resulting packet format may differ from the ESP v2 spec. However, a peer who implements only ESP v2 would never negotiate such an algorithm, as they are defined for use only in the ESP v3 context.
まず、ESP V3で利用可能な新機能が採用されていない場合、ESPパケットの形式はESP V2とV3で同一です。複合モード暗号化アルゴリズムが採用されている場合、ESP V3でのみサポートされる機能は、結果のパケット形式がESP V2仕様と異なる場合があります。ただし、ESP V2のみを実装するピアは、ESP V3コンテキストでのみ使用するために定義されているため、このようなアルゴリズムを交渉することはありません。
Extended Sequence Number (ESN) negotiation is supported by IKE v2 and has been addressed for IKE v1 by the ESN Addendum to the IKE v1 Domain of Interpretation (DOI).
拡張されたシーケンス番号（ESN）交渉はIKE V2によってサポートされており、IKE V1 domain of Intredation（DOI）のESN補遺によってIKE V1のために対処されています。
In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC):
新しいESP（V3）では、トラフィックフローの機密性を向上させるための2つの規定（TFC）を作成します。
- arbitrary padding after the end of an IP packet - a discard convention using Next Header = 59
- IPパケットの終了後の任意のパディング - 次のヘッダーを使用した廃棄条約= 59
The first feature is one that should not cause problems for a receiver, since the IP total length field indicates where the IP packet ends. Thus, any TFC padding bytes after the end of the packet should be removed at some point during IP packet processing, after ESP processing, even if the IPsec software does not remove such padding. Thus, this is an ESP v3 feature that a sender can employ irrespective of whether a receiver implements ESP v2 or ESP v3.
最初の機能は、IP合計長さフィールドがIPパケットの終了場所を示しているため、受信機に問題を引き起こすべきではない機能です。したがって、IPSECソフトウェアがそのようなパディングを削除しない場合でも、ESP処理後、IPパケット処理中のある時点で、パケットの終了後のTFCパディングバイテスを削除する必要があります。したがって、これは、受信者がESP V2またはESP V3を実装するかどうかに関係なく、送信者が使用できるESP V3機能です。
The second feature allows a sender to send a payload that is an arbitrary string of bytes that do not necessarily constitute a well-formed IP packet, inside of a tunnel, for TFC purposes. It is an open question as to what an ESP v2 receiver will do when the Next Header field in an ESP packet contains the value "59". It might discard the packet when it finds an ill-formed IP header, and log this event, but it certainly ought not to crash, because such behavior would constitute a DoS vulnerability relative to traffic received from authenticated peers. Thus this feature is an optimization that an ESP v3 sender can make use of irrespective of whether a receiver implements ESP v2 or ESP v3.
2番目の機能により、送信者は、TFCの目的のために、トンネルの内部にある適切に形成されたIPパケットを構成するとは限らない任意のバイト文字列であるペイロードを送信できます。ESPパケットの次のヘッダーフィールドに値「59」が含まれている場合、ESP V2レシーバーが何をするかについての未解決の質問です。不正なIPヘッダーを見つけたときにパケットを破棄し、このイベントを記録する可能性がありますが、そのような動作は認証されたピアから受け取ったトラフィックに比べてDOSの脆弱性を構成するため、クラッシュする必要はありません。したがって、この機能は、受信者がESP V2またはESP V3を実装するかどうかに関係なく、ESP V3送信者が使用できる最適化です。
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPSEC and MSEC working groups who have contributed to the development of this protocol specification.
著者は、最初のIPSECアクティビティで重要な役割を果たし、IPSEC標準の最初のシリーズであるRFCS 1825-1827を執筆したRan Atkinsonの貢献を認めたいと思います。Karen Seoは、この仕様の以前のバージョンの編集に支援を提供してくれたことに特に感謝します。著者はまた、このプロトコル仕様の開発に貢献したIPSECおよびMSECワーキンググループのメンバーにも感謝したいと思います。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[EAS04] 3rd EastLake、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Ken-Arch] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[POS81] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.
[Bel96] Steven M. Bellovin、「IPセキュリティプロトコルの問題領域」、第6回USENIX UNIXセキュリティシンポジウムの議事録、1996年7月。
[HC03] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress, November 3, 2002.
[HC03] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、2002年11月3日、Work in Progress。
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Kau05] Kaufman、C.、ed。、「The Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[Ken-AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[Ken-Ah] Kent、S。、「IP Authentication Header」、RFC 4302、2005年12月。
[Kra01] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)", CRYPTO' 2001.
[Kra01] Krawczyk、H。、「コミュニケーションを保護するための暗号化と認証の順序（または：SSLの安全性はどれくらいですか？）」、Crypto '2001。
[NIST01] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), "Security Requirements for Cryptographic Modules", Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
[NIST01]連邦情報処理基準出版140-2（FIPS Pub 140-2）、「暗号化モジュールのセキュリティ要件」、情報技術研究所、国立標準研究所、2001年5月25日。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[Syverson] P. Syverson, D. Goldschlag, and M. Reed, "Anonymous Connections and Onion Routing", Proceedings of the Symposium on Security and Privacy, Oakland, CA, May 1997, pages 44-54.
[Syverson] P. Syverson、D。Goldschlag、およびM. Reed、「匿名のつながりとオニオンルーティング」、セキュリティとプライバシーに関するシンポジウムの議事録、1997年5月、カリフォルニア州オークランド、44〜54ページ。
Appendix A: Extended (64-bit) Sequence Numbers
付録A：拡張（64ビット）シーケンス番号
A1. Overview
A1。概要
This appendix describes an extended sequence number (ESN) scheme for use with IPsec (ESP and AH) that employs a 64-bit sequence number, but in which only the low-order 32 bits are transmitted as part of each packet. It covers both the window scheme used to detect replayed packets and the determination of the high-order bits of the sequence number that are used both for replay rejection and for computation of the ICV. It also discusses a mechanism for handling loss of synchronization relative to the (not transmitted) high-order bits.
この付録では、64ビットシーケンス番号を使用するIPSEC（ESPおよびAH）で使用するための拡張シーケンス番号（ESN）スキームについて説明しますが、低次の32ビットのみが各パケットの一部として送信されます。再生されたパケットを検出するために使用されるウィンドウスキームと、リプレイ拒否とICVの計算の両方に使用されるシーケンス番号の高次ビットの決定の両方をカバーします。また、（送信されていない）高次ビットに対する同期の損失を処理するメカニズムについても説明しています。
A2. Anti-Replay Window
A2。アンチレプレイウィンドウ
The receiver will maintain an anti-replay window of size W. This window will limit how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (No requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. However, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) All 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace. The following table lists pertinent variables and their definitions.
受信機は、サイズWのアンチレプレイウィンドウを維持します。このウィンドウは、これまでに認証されている最高のシーケンス番号を持つパケットと比較して、パケットの距離を制限します。（このウィンドウの最小または推奨サイズの要件は、32ビットシーケンス番号ウィンドウに対して既に確立されている32パケットと64パケットの値を超えて確立されています。ただし、実装者は、サポートされているインターフェイス速度と一致するこれらの値をスケーリングすることをお勧めします。また、ESNオプションを使用する実装により。また、以下に説明するアルゴリズムは、ウィンドウが幅の2^31パケットに大きくないことを前提としています。）高次の32の固定値に関連付けられたすべての2^32シーケンス番号ビット（SEQH）は、今後シーケンス番号サブスペースと呼ばれます。次の表には、適切な変数とその定義を示します。
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seq
When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases:
アンチレプレイチェックを実行する場合、または着信パケットを認証するために使用する高次のビットを決定するとき、2つのケースがあります。
+ Case A: Tl >= (W - 1). In this case, the window is within one sequence number subspace. (See Figure 1) + Case B: Tl < (W - 1). In this case, the window spans two sequence number subspaces. (See Figure 2)
+ ケースA：tl> =（w -1）。この場合、ウィンドウは1つのシーケンス番号サブスペース内にあります。（図1を参照）ケースB：TL <（W -1）。この場合、ウィンドウは2つのシーケンス番号サブスペースに及びます。（図2を参照）
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
図1-ケースa
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
図2-ケースb
A2.1. Managing and Using the Anti-Replay Window
A2.1。レプレイ防止ウィンドウの管理と使用
The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected.
アンチレプレイウィンドウは、「w」が文字列の長さを定義する一連のビットと考えることができます。w = t -b 1で、値が2^32-1を超えることはできません。一番下のビットはbに対応し、最上部ビットはtに対応し、BLからTLからの各シーケンス番号は対応するビットで表されます。ビットの値は、そのシーケンス番号を含むパケットが受信および認証されたかどうかを示しているため、リプレイを検出して拒否することができます。
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated,
Tより大きい64ビットシーケンス番号（seq）を持つパケットが受信および検証された場合、
+ B is increased by (Seq - T) + (Seq - T) bits are dropped from the low end of the window + (Seq - T) bits are added to the high end of the window + The top bit is set to indicate that a packet with that sequence number has been received and authenticated + The new bits between T and the top bit are set to indicate that no packets with those sequence numbers have been received yet. + T is set to the new sequence number
+ bは（seq -t）（seq -t）ビットをウィンドウのローエンド（seq -t）ビットから窓のハイエンドに追加します。そのシーケンス番号が受信され、Tと上部ビットの間の新しいビットが設定されており、これらのシーケンス番号がまだ受信されていないことを示すように設定されています。Tは新しいシーケンス番号に設定されています
In checking for replayed packets,
再生されたパケットをチェックする際、
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix A2.2. below for determination of Seqh).
+ ケースa：seql> = bl（bl = tl -w 1）およびseql <= tlの場合、ウィンドウの対応するビットをチェックして、このseqlがすでに見られているかどうかを確認します。はいの場合、パケットを拒否します。いいえの場合は、整合性チェックを実行します（SEQHの決定については、付録A2.2を参照してください）。
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix A2.2. below for determination of Seqh).
+ ケースB：seql> = bl（bl = tl -w 1）またはseql <= tlの場合、ウィンドウの対応するビットを確認して、このseqlがすでに見られているかどうかを確認します。はいの場合、パケットを拒否します。いいえの場合は、整合性チェックを実行します（SEQHの決定については、付録A2.2を参照してください）。
A2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number
A2.2。シーケンス番号の高次ビット（SEQH）を決定する
Because only `Seql' will be transmitted with the packet, the receiver must deduce and track the sequence number subspace into which each packet falls, i.e., determine the value of Seqh. The following equations define how to select Seqh under "normal" conditions; see Section A3 for a discussion of how to recover from extreme packet loss.
パケットで「seql」のみが送信されるため、受信者は各パケットが落ちるシーケンス番号サブスペースを推定して追跡する必要があります。つまり、seqhの値を決定する必要があります。次の方程式は、「通常の」条件下でSEQHを選択する方法を定義します。極端なパケット損失から回復する方法についての議論については、セクションA3を参照してください。
+ Under Case A (Figure 1): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ ケースa（図1）：seql> = bl（bl = tl -w 1）の場合、seqh = thの場合はseql <bl（bl = tl -w 1）、seqh = th 1
+ Under Case B (Figure 2): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
+ ケースB（図2）：seql> = bl（bl = tl -w 1）の場合、seqh = th -1 seql <bl（bl = tl -w 1）、seqh = th
A2.3. Pseudo-Code Example
A2.3。擬似コードの例
The following pseudo-code illustrates the above algorithms for anti-replay and integrity checks. The values for `Seql', `Tl', `Th' and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32.
次の擬似コードは、アンチレプレイと整合性チェックの上記のアルゴリズムを示しています。「seql」、「tl」、「th」、および `w 'の値は、32ビットの符号なし整数です。算術はmod 2^32です。
If (Tl >= W - 1) Case A If (Seql >= Tl - W + 1) Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set bit corresponding to Seql Pass the packet on Else reject packet Else reject packet Else If (pass integrity check) Tl = Seql (shift bits) Set bit corresponding to Seql Pass the packet on Else reject packet Else Seqh = Th + 1 If (pass integrity check) Tl = Seql (shift bits) Th = Th + 1 Set bit corresponding to Seql Pass the packet on Else reject packet Else Case B If (Seql >= Tl - W + 1) Seqh = Th - 1 If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet Else Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet
if（tl> = w -1）case a if（seql> = tl -w 1）seqh = th if（seql <= tl）if（pass repray check）if（pass Integrity check）set set bitにseqlパスに対応するelseのパケット拒否パケットelse redject packet else else（パス整合性チェック）tl = seql（shift bits）set set set seet seql ass elsed packet else seqh = th 1 if（pass intecrity check）tl = seql（shift（shift（shift）bits）th = th = th 1 set seqlに対応するビット他のパケット拒否パケットのパケットパッケージelseケースb（seql> = tl -w 1）seqh = th -1 if（pass repray check）if（pass Integrity check）Setを設定しますseql passパケットに対応するビットelsejed packet else else redject packet packet else else seqh = th if（seql <= tl）if（pass repray check）if（pass Integrity check）はパケット
Else If (pass integrity check) Tl = Seql (shift bits) Set the bit corresponding to Seql Pass packet on Else reject packet
else（パス整合性チェック）tl =続編（シフトビット）elseのシールパスパケットに対応するビットを設定します
A3. Handling Loss of Synchronization due to Significant Packet Loss
A3。重大なパケット損失による同期の損失
If there is an undetected packet loss of 2^32 or more consecutive packets on a single SA, then the transmitter and receiver will lose synchronization of the high-order bits, i.e., the equations in Section A2.2. will fail to yield the correct value. Unless this problem is detected and addressed, subsequent packets on this SA will fail authentication checks and be discarded. The following procedure SHOULD be implemented by any IPsec (ESP or AH) implementation that supports the ESN option.
単一のSAで2^32以上の連続したパケットの検出されないパケット損失がある場合、トランスミッターとレシーバーは高次ビットの同期、つまりセクションA2.2の方程式を失います。正しい値をもたらすことができません。この問題が検出され、対処されない限り、このSAの後続のパケットは認証チェックに失敗し、破棄されます。以下の手順は、ESNオプションをサポートするIPSEC（ESPまたはAH）実装によって実装する必要があります。
Note that this sort of extended traffic loss is likely to be detected at higher layers in most cases, before IPsec would have to invoke the sort of re-synchronization mechanism described in A3.1 and A3.2. If any significant fraction of the traffic on the SA in question is TCP, the source would fail to receive ACKs and would stop sending long before 2^32 packets had been lost. Also, for any bi-directional application, even ones operating above UDP, such an extended outage would likely result in triggering some form of timeout. However, a unidirectional application, operating over UDP, might lack feedback that would cause automatic detection of a loss of this magnitude, hence the motivation to develop a recovery method for this case. Note that the above observations apply to SAs between security gateways, or between hosts, or between host and security gateways.
IPSECがA3.1およびA3.2に記載されている種類の再同期メカニズムを呼び出す必要がある前に、この種の拡張された交通量は、ほとんどの場合、より高い層で検出される可能性が高いことに注意してください。問題のSAのトラフィックのかなりの部分がTCPである場合、ソースはACKを受け取ることができず、2^32パケットが失われる前に長く送信を停止します。また、双方向のアプリケーションでも、UDPを超えて動作しているものでさえ、そのような拡張停止により、何らかの形のタイムアウトがトリガーされる可能性があります。ただし、UDPを介して動作する単方向用途には、この大きさの喪失の自動検出を引き起こすフィードバックがないため、この場合の回復方法を開発する動機があります。上記の観測は、セキュリティゲートウェイ間、ホスト間、またはホストとセキュリティゲートウェイの間のSASに当てはまることに注意してください。
The solution we've chosen was selected to:
私たちが選択したソリューションは、次のように選択されました。
+ minimize the impact on normal traffic processing
+ 通常の交通処理への影響を最小限に抑えます
+ avoid creating an opportunity for a new denial of service attack such as might occur by allowing an attacker to force diversion of resources to a re-synchronization process
+ 攻撃者がリソースの転用を再同期プロセスに強制することにより、発生する可能性のあるような、新しいサービス拒否攻撃の機会を作成しないでください
+ limit the recovery mechanism to the receiver -- because anti-replay is a service only for the receiver, and the transmitter generally is not aware of whether the receiver is using sequence numbers in support of this optional service, it is preferable for recovery mechanisms to be local to the receiver. This also allows for backward compatibility.
+ 回復メカニズムを受信機に制限します - アンチレプレイは受信機のみサービスであり、送信機はこのオプションサービスをサポートするためにシーケンス番号を使用しているかどうかを一般に認識していないため、回復メカニズムにはリカバリメカニズムが望ましいレシーバーにローカルになります。これにより、後方互換性も可能になります。
A3.1. Triggering Re-synchronization
A3.1。再同期のトリガー
For each SA, the receiver records the number of consecutive packets that fail authentication. This count is used to trigger the re-synchronization process, which should be performed in the background or using a separate processor. Receipt of a valid packet on the SA resets the counter to zero. The value used to trigger the re-synchronization process is a local parameter. There is no requirement to support distinct trigger values for different SAs, although an implementer may choose to do so.
各SAについて、受信機は認証に失敗する連続したパケットの数を記録します。このカウントは、再同期プロセスをトリガーするために使用されます。これは、バックグラウンドで実行するか、別のプロセッサを使用する必要があります。SAで有効なパケットを受信して、カウンターをゼロにリセットします。再同期プロセスをトリガーするために使用される値は、ローカルパラメーターです。実装者がそうすることを選択する場合は、異なるSAの異なるトリガー値をサポートする要件はありません。
A3.2. Re-synchronization Process
A3.2。再同期プロセス
When the above trigger point is reached, a "bad" packet is selected for which authentication is retried using successively larger values for the upper half of the sequence number (Seqh). These values are generated by incrementing by one for each retry. The number of retries should be limited, in case this is a packet from the "past" or a bogus packet. The limit value is a local parameter. (Because the Seqh value is implicitly placed after the ESP (or AH) payload, it may be possible to optimize this procedure by executing the integrity algorithm over the packet up to the endpoint of the payload, then compute different candidate ICVs by varying the value of Seqh.) Successful authentication of a packet via this procedure resets the consecutive failure count and sets the value of T to that of the received packet.
上記のトリガーポイントに到達すると、シーケンス番号（SEQH）の上半分の上半分の値がより大きな値を使用して認証が再試行される「悪い」パケットが選択されます。これらの値は、再試行ごとに1つずつ増加することによって生成されます。これが「過去」または偽のパケットからのパケットである場合、レトリの数を制限する必要があります。制限値はローカルパラメーターです。（SEQH値はESP（またはAH）ペイロードの後に暗黙的に配置されるため、パケットを介してペイロードのエンドポイントまで整合性アルゴリズムを実行することにより、この手順を最適化することが可能かもしれません。SEQHの。）この手順を介してパケットの認証を成功させると、連続障害カウントをリセットし、Tの値を受信パケットの値に設定します。
This solution requires support only on the part of the receiver, thereby allowing for backward compatibility. Also, because re-synchronization efforts would either occur in the background or utilize an additional processor, this solution does not impact traffic processing and a denial of service attack cannot divert resources away from traffic processing.
このソリューションでは、レシーバーの側でのみサポートが必要であり、それにより、後方互換性が可能になります。また、再同期の取り組みはバックグラウンドで発生するか、追加のプロセッサを利用するため、このソリューションはトラフィック処理に影響を与えず、サービス拒否攻撃はトラフィック処理から離れてリソースをそらすことはできません。
Author's Address
著者の連絡先
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton Street Cambridge、MA 02138 USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。