Network Working Group S. Kent
Request for Comments: 4303 BBN Technologies
Obsoletes: 2406 December 2005
Category: Standards Track
IP Encapsulating Security Payload (ESP)
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).
著作権（C）インターネット協会（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.
この文書は、読者が「インターネットプロトコルのためのセキュリティアーキテクチャ」[ケン-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]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
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 [ケン-AH]と組み合わせて、またはネストされた様式で、単独で適用されてもよいです。セキュリティサービスは、セキュリティゲートウェイを通信する対の間、またはセキュリティゲートウェイとホストとの間で、ホストと通信する一対の間に設けることができます。さまざまなネットワーク環境でのESPとAHを使用する方法の詳細については、セキュリティアーキテクチャ文書[ケン-アーチ]を参照してください。
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は、暗号化のみのSAを可能にします。しかし、この標準は、暗号化のみのサービスを提供するために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.
データ発信元認証とコネクションレスインテグリティは、以下に共同で「整合性」と呼ぶ、共同サービスです。パケット単位で、実行される計算は、直接コネクションレス完全性を提供するため（この用語が使用され、データ発信元認証は、IPsecピアのアイデンティティに完全性を検証するために使用されるキーを結合した結果として間接的に提供される典型的。この結合は、共有対称鍵を使用することによって達成される。整合性のみESP例えば、サービス選択のオプションとして提供されなければならない）、それはSA管理プロトコルに交渉でなければならず、管理インターフェイスを介して設定可能でなければなりません。処理するより速く、多くの実装では、パイプライン処理により適しているため、整合性のみ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は一般的に、すなわち、パケットは機密性と完全性に関して保護されます、両方のサービスを利用します。したがって、これらのサービスを含む三つの可能な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).
アンチリプレイサービスは、整合性サービスがそのSAのために選択されている場合にのみ、SAのために選択することができます。このサービスの選択は、受信機の裁量であり、したがって、交渉される必要はありません。ただし、相互運用可能な方法で拡張シーケンス番号の機能を利用するために、ESPは、（下記のセクション2.2.1を参照）、この機能を交渉できるようにするにはSA管理プロトコル上の要件を課します。
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は、セキュリティゲートウェイとの間のトンネルモードでは、例えば、特派員の最終的な発信元アドレスと宛先アドレスを隠す方法で使用されている場合にのみ、十分なトラフィックがいずれかのIPsecピア（間を流れる場合にのみ有効です天然またはトラフィックマスキングの発生の結果としての）特定の特性を隠すために、個々の加入者トラフィックが流れます。 （ESPはオニオン・ルーティング[Syverson]、例えば、上位層TFCシステムの一部として使用することができるが、このようなシステムは、この規格の範囲外である。）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の拡張）フィールドに値50を含まなければならない前に（外側）プロトコルヘッダ（IPv4の、IPv6の、または拡張）は、（HTTPでIANAのウェブページを参照：// 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
ESPパケットの図1.トップ・レベル・フォーマット
* 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）モードを必要とする暗号化アルゴリズムは、多くの場合、その値を用いて保護されるべきペイロードデータを接頭辞。いくつかのアルゴリズムモードは、単一の操作に暗号化と整合性を兼ね備え、この文書では、「合成モードアルゴリズム」などのアルゴリズムモードを指します。コンバインモードアルゴリズムの宿泊は、アルゴリズムが明示的に整合性のデータを伝達するために使用されるペイロード下部構造を記述する必要があります。
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バイト）フィールドの前に（2.4節を参照）トラフィックフローの機密性（TFC）パディングを追加することができます。
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.
合わせアルゴリズムモードが使用される場合、明示的なICVは、図1に示す2は、（以下のセクション3.3.2.2を参照）を省略してもよいです。 SAが確立されると、アルゴリズムおよびモードが固定されているので、（ペイロードデータ部分構造を含む）与えられたSAのESPパケットの詳細なフォーマットは、SA上のすべてのトラフィックのために、固定されています。
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のESPパケットのフォーマットは、SAの期間中、固定されています。これとは対照的に、「必須」のフィールドは、すべての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は、バージョン番号が含まれていない、下位互換性についての懸念がある場合は、それゆえ、彼らはESPの互換性のあるバージョン（例えば、インターネット鍵交換（IKEv2の）[Kau05]）を確保するために、2つのIPsecピア間のシグナリングメカニズムを使用することによって対処しなければなりませんまたはアウトオブバンド構成機構。
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は、着信パケットがバインドされているSAを識別するために受信機によって使用される任意の32ビット値です。 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を指定するために単独で使用することができ、またはそれは（この場合ESP）にIPsecプロトコルタイプと組み合わせて使用することができます。 SPI値は、ユニキャストSAのために受信機によって生成されるので、値が十分であるかどうかをそれ自体でSAを識別するか、IPsecプロトコル値と一緒に使用する必要があるかどうかローカルの問題であることができます。ユニキャストのSAへのインバウンドトラフィックをマッピングするためのこのメカニズムは、すべての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実装がマルチキャストをサポートしている場合、それは、SASへのインバウンドのIPsecデータグラムをマッピングするための以下のアルゴリズムを使用してマルチキャストSAをサポートしなければなりません。ユニキャストトラフィックだけをサポートする実装は、この逆多重化アルゴリズムを実装する必要がありません。
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:
セキュリティアソシエーションデータベース（SAD）[ケン-ARCH]の各エントリは、SA検索がSPIに加えて、宛先、または宛先や送信元、IPアドレスを使用するかどうかを示す必要があります。マルチキャストSAのために、プロトコルフィールドは、SAの検索に採用されていません。それは「最長」SA識別子と一致するエントリが見つかったことを各インバウンド、IPsecで保護されたパケットの場合、実装は、SADなどの検索を行わなければなりません。二つ以上のSADエントリがSPI値に基づいて、一致した場合、この文脈では、次に、宛先、または宛先およびソース、アドレス比較（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.
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、宛先アドレス}に一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンド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.
受信機は、AHとESPのための単一のSPI空間を維持するために選択され、または{SPIプロトコル}に別段た場合3.のみ{SPI}に一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンド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によりハッシュテーブルへのインデックスできました。各ハッシュ・テーブル・バケットのリンクリストでSADエントリは、最初にそのリンクリストの中で最も長いSA識別子を持つものSADエントリを持つようにソートされ保持されます。彼らはリンクリスト内の最後のエントリになるように最短SA識別子を有するものSADエントリがソートされています。ハードウェアベースの実装は、一般的に入手可能な三元連想メモリ（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.
送信元および宛先アドレスマッチングをSAのにインバウンドIPsecトラフィックをマップするために必要であるかどうかの指示は、SA管理プロトコルを使用して手動SA設定の副作用として、または交渉を介してのいずれかで設定しなければなりません、例えば、IKE又は解釈のグループドメイン（GDOI） [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.)
255までの範囲1にSPI値のセットは、将来の使用のためInternet Assigned Numbers Authority（IANA）によって予約されています。割り当てられたSPI値の使用は、RFCで指定されていない限り、予約SPI値は、通常、IANAによって割り当てられません。 （0）ゼロのSPI値は、ローカル、実装に固有の使用のために予約されており、ワイヤ上で送信してはいけません。 （例えば、鍵管理の実装は、IPsec実装がその鍵管理エンティティが新しいSAを確立することを要求しましたが、SAがまだ確立されていない期間中に「いいえセキュリティアソシエーションが存在する」ことを意味するゼロSPI値を使用する場合があります。 ）
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に初期化されています。 （1のシーケンス番号を持つことになります与えられたSAを使用して送信された最初のパケットは、シーケンス番号の生成方法についての詳細は、セクション3.3.3を参照してください。）抗リプレイが（デフォルト）有効になっている場合は、送信シーケンス番号が必要サイクルに許されることはありません。したがって、送信側のカウンタと受信側のカウンタは、SAに2 ^ 32パケットの送信に先立って（従って新しい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.)
高速IPsec実装をサポートするために、拡張シーケンス番号（のESN）は、現在、32ビットのシーケンス番号フィールドの拡張機能として、実装されるべきです。 ESNの使用はSA管理プロトコルによって交渉しなければなりません。 IKEv2の中で、この交渉は暗黙的であることに注意してください。 32ビットのシーケンス番号が明示的に交渉されない限り、デフォルトでESNです。 （ESN機能は、同様に、ユニキャストSAをマルチキャストに適用可能です。）
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.
ESN機能はSAのための64ビットのシーケンス番号の使用を可能にします。 （詳細については、「拡張（64ビット）シーケンス番号」は、付録Aを参照。）のみのシーケンス番号の下位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）、暗号同期データが必要な場合は、このデータはペイロードフィールド内で明示的に行われているが、それは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 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.
二つの主な要因は、パディングフィールドの使用を必要とするか、または動機。
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パディングはまた、得られた暗号文が4バイト境界で終了することを確実にするために関係なく、暗号化アルゴリズムの要件、必要とされ得ます。 ICVフィールドは（存在する場合）は、4バイト境界で整列されることを保証するために、上記ESPパケットフォーマットの図に示すように、具体的には、パッドの長さと次ヘッダフィールドは右、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、パディングの計算は任意IVのペイロードデータに排他的に適用されるが、ESPトレーラフィールドを含みます。複合アルゴリズムモードがペイロードデータに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バイト境界（上記第二弾）上に整列されることを保証する目的のために、パディングの計算は、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.)
パディングバイトが必要とされますが、暗号化アルゴリズムは、パディングの内容を指定しない場合は、次のデフォルトの処理を使用しなければなりません。パディングバイトは（符号なし、1バイト）の整数値の系列で初期化されます。 、1、2、3 ....本パディング方式を採用する場合、受信機はパディングフィールドを検査する必要があります。平文に付加最初のパディングバイトは、後続のパディングバイトが単調に増加するシーケンスを構成すると、1と番号付けされています。 （このスキームは、その相対的なシンプルさ、ハードウェアでの実装の容易さのために選択し、受信機が復号時にパディング値をチェックする場合には、他の整合性対策が存在しない場合に「カットアンドペースト」攻撃の特定の形態に対する限定的な保護を提供していますので、 。）
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.
次ヘッダは、ペイロードデータフィールドに含まれるデータのタイプを識別する必須の、8ビットのフィールドであり、例えば、IPv4またはIPv6パケット、又は次の層のヘッダとデータ。このフィールドの値はIANAのウェブページ上で定義された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.
（セクション2.4を参照）トラフィックフローの機密性をサポートするためにパディングトラフィックの急速な生成と破棄を容易にするために、（「なし次ヘッダ」を意味しない）プロトコル値59は、「ダミー」パケットを指定するために使用されなければなりません。送信機は、次のプロトコル・フィールドにこの値でマークされ、そして受信機がエラーを示すことなく、そのようなパケットを廃棄するように調製されなければならないダミーパケットを生成できなければなりません。他のすべてのESPヘッダとトレーラフィールド（SPI、シーケンス番号、パディング、パディング長、次ヘッダ、及びICV）ダミーパケット内に存在していなければなりませんが、この次ヘッダーフィールド以外のペイロードの平文部分は、十分である必要はありません-formed、例えば、ペイロードデータの残りの部分は、ランダムなバイトからなるものであってもよいです。ダミーパケットは、偏見なく廃棄されています。
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.
実装はSA毎に、この機能の使用を可能にするために、ローカルの管理コントロールを提供する必要があります。コントロールは、この機能を使用し、またパラメトリック制御を提供する場合、ユーザが指定できるようにすべきです。例えば、コントロールは、管理者がランダム長又は固定長のダミーパケットを生成することを可能にするかもしれません。
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は、リンク暗号しかしレイヤ1または2に提供するであろうものに類似した一定のビットレートのデータ・ストリームの外観を提示し、それから、これは例えば、多くの状況では実用的ではないようで、それはSAの数に基づいて、サイトの許容帯域幅を削減暗示する、そしてそれはパケット交換の利点を損なうため、複数のSAは、アクティブがあるとき。実装は、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実装は、前パディングフィールドの先頭に、ペイロード・データの終了後にバイトを追加することにより、パディングトラフィックのできるものでなければなりません。しかしながら、（以下TFCパディングと呼ぶ）は、このパディングは、ペイロードデータフィールドは、IPデータグラムの長さの仕様が含まれている場合にのみ追加することができます。これは常にトンネルモードでは真であり、次の層のプロトコル（例えば、IP、UDP、ICMP）は、明示的な長さ情報が含まれているかどうかに応じて、トランスポートモードで真であってもよいです。この長さ情報は、ペイロードデータの真の長さが知られているであろうため、TFCパディングを廃棄するために受信機を可能にします。 TFCパディングが追加された場合（ESPトレーラフィールドはバックESPパケットの端から数えることによって配置されている。）従って、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管理プロトコルは、下位互換性を確保するために、それを用いた送信に先立って、このサービスを交渉しなければなりません。プロトコル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.
実装はSA毎に、この機能の使用を可能にするために、ローカルの管理コントロールを提供する必要があります。コントロールは、この機能は使用しても機能のパラメトリックコントロールを提供する場合は、ユーザが指定できるようにする必要があります。
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は、IPv4のの文脈では、例えば等、TCP、UDP、ICMP、IPヘッダの後、次の層のプロトコルの前に挿入され、これは、IPヘッダの後にESPを配置することに変換（及びそれに含まれる任意のオプション）が、次の層のプロトコルの前に。 （AHは、パケットに適用される場合、それは、存在する場合にESPヘッダ、ペイロード、ESPトレーラ、及びICVに適用される。）（用語「トランスポート」モードはTCPとするためのその使用を制限するように誤解されるべきではないことに注意してください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.
「bump-in-the-スタック」または「バンプ・イン・ザ・ワイヤー」の実装のために、トランスポートモードでなお、セキュリティアーキテクチャ文書で定義されているように、インバウンドとアウトバウンドのIPフラグメントは、余分なIPを実行するためにIPsec実装が必要な場合がありますこの仕様に準拠し、透明な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ヘッダはIPsecの「ピア」、例えば、セキュリティゲートウェイのアドレスのアドレスを含んでいるが、トンネルモードでは、「内側」IPヘッダは、究極（IP）送信元アドレスと宛先アドレスを運びます。混合内側および外側IPバージョンは、すなわち、IPv6のIPv4およびIPv6のIPv4の上の上、許されます。トンネルモードでは、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.
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のために義務付けられたものを超えて、サポートされるかもしれません。機密性と整合性の両方がオプションであるが、これらのサービスのうちの少なくとも一つを選択しなければならないこと、したがって、両方のアルゴリズムが同時にヌルにはできません注意してください。
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）パケットヘッダの平文部分から誘導することができます。 （平文ヘッダ情報はIVを導出するために使用されている場合、その情報はセキュリティ上重要なと成長する可能性が暗号化プロセスに関連付けられているので、保護境界になる場合があります。たとえば、1はIVを導出するESPシーケンス番号を使用した場合、シーケンス番号生成論理（ハードウェアまたはソフトウェア）は、暗号化アルゴリズムの実装の一部として評価されなければならない。FIPS 140-2〔NIST01]の場合には、これはかなり暗号モジュール評価の範囲を広げることができた。）ESPため平文のパディングのための準備を行い、ESPで使用される暗号化アルゴリズムは、ブロックまたはストリームモード特性のいずれかを示すことができます。暗号化（機密性）オプションのサービス（例えば、整合性のみESP）される可能性があるため、このアルゴリズムは「NULL」であってもよいことを[ケン-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.
ブロックモード暗号化アルゴリズムによって必要とされる暗号化パディングを計算する、及びアルゴリズムのMTUの影響を決定するために、ESPの実装を可能にするために、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およびシーケンス番号フィールドは、暗号文のエンベロープ内で複製されるかもしれないと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.
2. Add any necessary padding -- Optional TFC padding and (encryption) Padding
オプションのTFCパディングと（暗号化）パディング - 2.任意の必要なパディングを追加します。
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、シーケンス番号、ペイロードデータ、パディング（存在する場合）、パッド長、次ヘッダを包含する。 ESNオプションがSAで有効になっている場合、シーケンス番号の上位32ビットがの目的のための次のヘッダフィールドの後に付加される（暗号化が最初に実行されるので、最後の4つのフィールドは、暗号文の形態であろう。なお）しかし、この計算は、送信されていません。
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.
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値、現在の日付/時刻、送信元アドレス、宛先アドレス、および平文のフローID（IPv6では）を含むべきです。
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項を参照してください）受信機によって通知されない限りアンチリプレイは、デフォルトで有効になっている前提としています。送信者が時にシーケンス番号（またはESN）サイクル、またはこの値サイクリングを見越して新しいSAを確立するためにこのように、ESPの実装の典型的な動作が呼び出されます。
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を計算するために使用されるキーを手動で配布される場合は、準拠した実装は、リプレイ防止サービスを提供すべきではありません。ユーザが手動でキー入力されたSAと一緒にリプレイを使用することを選択した場合、キーが交換されるまで、送信側でシーケンス番号カウンタが正しく、等ローカルリブートにわたって維持されなければなりません。 （第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は（付録を参照）を選択した場合、送信側と受信側の両方が完全な64ビットESNカウンタを維持するが、シーケンス番号の唯一の下位32ビットは、シーケンス番号フィールドで送信されます。上位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処理の後に行われます。このように、トランスポートモード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の実装は断片化をサポートし、DFビットで送信されたパケットをマークして、パスMTU（PMTU）の発見を容易にするためではないことを選択できます。いずれの場合においても、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の仕様では、オフセットフィールドをゼロ化またはMORE FRAGMENTSフラグのクリアのいずれかを必要としません。それは、パケットを再構成した後に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を決定します。セクション2.1で説明したように、ユニキャストSAのために、この決意は、SPIまたはSPIプラスプロトコルフィールドに基づいています。実装はマルチキャストトラフィックをサポートしている場合、宛先アドレスは、（SPIに加えて）、ルックアップで使用され、セクション2.1で説明したように送信元アドレスも、使用することができます。 （このプロセスはセキュリティアーキテクチャ文書においてより詳細に記載されている。）SAのSADエントリはまた、シーケンス番号フィールドは、32ビットまたは64ビットのシーケンス番号はSAのために使用されているかどうか、チェックし、かどうかをするかどうかを示します（明示的）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値、日付/時刻が受信、送信元アドレス、宛先アドレス、シーケンス番号、および平文のフローID（IPv6では）を含むべきです。
(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.
その使用はSA毎に受信側によって有効または無効にすることができるものの、すべてのESP実装は、アンチリプレイサービスをサポートしなければなりません。それ以外の場合はシーケンス番号フィールドは、整合性が保護されていないため、ESPの整合性サービスはまた、SAのために有効にされていない限り、このサービスを有効にすることはできません。アンチリプレイは、マルチキャストのSAだけでなく、ユニキャストに適用可能です。しかし、この規格は、マルチ送信者SA（ユニキャストまたはマルチキャスト）するためのアンチリプレイを提供するための機構を指定しません。そのようなSAのためのアンチリプレイ機構のネゴシエーション（または手動設定）の非存在下では、以下に記載のようにSAのシーケンス番号の送信者と受信者チェックは、（ネゴシエーションまたは手動設定を介して）無効にすることが推奨されます。
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確立プロトコルが使用される場合、不必要なシーケンス番号監視およびSAのセットアップ（セクション3.3.3を参照）を行うことを回避するために、受信機は、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は、パケットシーケンス番号の二段階の検証が可能になります。 ESPの実装（その典型的暗号モジュール部）復号化を行うこと、および/または完全性が保護されていないネットワークへのインタフェース（S）と同じ速度で確認することができないときはいつでも、この機能は重要です。インプリメンテーションは、「回線速度」動作が可能である場合、以下に記載の予備検証段階を行う必要がありません。
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で受信した最高の、検証済みのシーケンス番号値を表しています。ウィンドウの「左」端より小さいシーケンス番号を含むパケットは拒否されます。ウィンドウ内に入るパケットは、ウィンドウ内で受信したパケットのリストと照合されます。 ESNオプションがSAのために選択された場合、シーケンス番号の唯一の下位32ビットは、明示的に送信するが、受信機は、彼のローカルカウンタから指示SAのための上位32ビットを使用して計算フルシーケンス番号を（採用されています）受信ウィンドウに対して受信したシーケンス番号を確認するとき。パケットで運ばれた下位32ビットが受信側のシーケンス番号の下位32ビットより値が低い場合、フルシーケンス番号を構築する際に、受信機は、移動、上位32ビットがインクリメントされていることを前提と新しいシーケンス番号部分空間へ。 （このアルゴリズムは、単一のSAとして大32-1 ** 2としてパケットの受信のギャップを収容している。大きなギャップが発生した場合で説明したように、受信シーケンス番号カウンタの再同期のための追加、ヒューリスティックチェックは、使用することができます付録。）
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値、日付/時刻が受信、送信元アドレス、宛先アドレス、シーケンス番号、およびフローID（IPv6では）を含むべきです。受信ウィンドウは、整合性の検証が成功した場合にのみ更新されます。 （複合モードのアルゴリズムが使用されている場合は、完全性保護されたシーケンス番号はまた、アンチリプレイ保護のために使用されるシーケンス番号と一致する必要があります。）
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.
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.
計算されたICVの一致を受け取った場合、データグラムは有効であり、そしてそれが受け入れられています。テストが失敗した場合、受信機は無効として、受信したIPデータグラムを捨てなければなりません。これは監査対象イベントとなります。ログデータは、SPI値、日付/時刻が受信、送信元アドレス、宛先アドレス、シーケンス番号、および平文のフローID（IPv6用）を含むべきです。
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である場合、そのまま次のヘッダフィールドの後、またはシーケンス番号の上位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.
- 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.
前記受信機は、暗号化アルゴリズムの仕様で指定され、任意のパディングを処理します。デフォルトのパディング方式は（セクション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.
前記受信機は、次ヘッダフィールドをチェックします。値が「59」（NO次ヘッダ）である場合、（ダミー）パケットをさらに処理することなく破棄されます。
- 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.
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パディングを「破棄します」。 （存在する場合、これは（）セクション2.4を参照してくださいIPデータグラム（またはトランスポート層フレーム）の後とパディングフィールドの前に挿入されています。）
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.
- 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.
- 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が示された場合、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値、日付/時刻が受信、送信元アドレス、宛先アドレス、シーケンス番号、および平文のフローID（IPv6では）を含むべきです。
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.
前記受信機は、次ヘッダフィールドをチェックします。値が「59」（NO次ヘッダ）である場合、（ダミー）パケットをさらに処理することなく破棄されます。
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.
- 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値、現在の日付/時刻、送信元アドレス、宛先アドレス、シーケンス番号、および平文のフローID（IPv6用）を含むべきです。
- 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値、日付/時刻が受信、送信元アドレス、宛先アドレス、シーケンス番号、およびフローID（IPv6では）を含むべきです。
- 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値、日付/時刻が受信、送信元アドレス、宛先アドレス、シーケンス番号、およびフローID（IPv6用）を含むべきです。
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の構文と処理を実装しなければならない、とセキュリティアーキテクチャ文書[ケン-ARCH]によって課さすべての追加のパケット処理の要件を遵守しなければなりません。実装は、マルチキャストトラフィックをサポートするために主張した場合また、そのようなトラフィックのサポートのために指定された追加要求事項を遵守しなければなりません。 ICVを計算するために使用されるキーを手動で配布される場合、アンチリプレイサービスの正確な規定は、鍵が交換されるまで、（ローカルリブートなど横切って）送信側のカウンタ状態の正確なメンテナンスを必要とし、可能性があるであろうカウンタのオーバーフローが差し迫った場合は何も自動回復の提供はありません。このように、準拠した実装は、手動で鍵管理されるSAで、アンチリプレイサービスを提供すべきではありません。
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での暗号化の使用は任意であるため、「NULL」暗号化アルゴリズムのサポートもESPサービスが交渉されている方法との整合性を維持するために必要とされます。 ESPの機密性のみのサービスバージョンのサポートはオプションです。実装はこのサービスを提供する場合、それはまた、「NULL」の整合性アルゴリズムのネゴシエーションをサポートしなければなりません。整合性と暗号化は、それぞれ、上記の状況の下で、「NULL」、かもしれないが、彼らは「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機密専用サービス - 今MAY、してはなりません。
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.
SPI○ - マルチキャスト技術の広い範囲をカバーし、ユニキャストおよびマルチキャストSAのSADルックアップのために均一なアルゴリズムを指定するように変更。ユニキャストのために、SPIは、SAを選択するために単独で用いてもよく、または受信機のオプションで、プロトコルと組み合わせることができます。マルチキャストSAの、SPIは、宛先アドレスと組み合わされ、そしてSAを選択するために、送信元アドレスを任意。 O拡張シーケンス番号は、 - 非常に高速通信用の64ビットのシーケンス番号の新しいオプションを追加しました。マルチキャストSASおよびマルチ送信者SAの明らかに送信側と受信側の処理要件。 Oペイロードデータ - 複合モードアルゴリズムに対応するために広げモデル。 Oの改善トラフィックフローの機密性のためのパディング - 追加要件は、前パディングフィールドの先頭に、IPペイロードの終了後にバイトを追加することができるようにします。次ヘッダO - 複合モードのアルゴリズムを収容するように広げモデル - 要求ダミーパディングパケットを生成し、廃棄することができるようにする（次ヘッダ= 59）O ICVが追加されました。 Oアルゴリズム - 組み合わせ機密モードアルゴリズムを追加しました。 O別の文書に必須のアルゴリズムへの参照を移動しました。 Oインバウンドおよびアウトバウンドパケット処理 - 二つのパス今ある：（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にはバージョン番号と発見したり、それぞれが使用しているか、使用すべきESPのバージョンを交渉するIPSecピアを有効にするメカニズムはありません。このセクションでは、その結果としての下位互換性の問題について説明します。
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 V2の仕様と異なる場合があり、唯一のESP V3でサポート。彼らは唯一のESP v3のコンテキストで使用するために定義されているようしかし、唯一のESP V2を実装したピアは、このようなアルゴリズムを交渉することはありません。
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のドメイン（DOI）にESNの補遺でIKE v1のために対処されてきました。
In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC):
新しいESP（V3）では、私たちはより良いサポートトラフィックフローの機密性（TFC）には、2つの規定を行います。
- arbitrary padding after the end of an IP packet
- a discard convention using Next Header = 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.
第1の特徴は、IPパケットの終了位置IP全長フィールドが示しているため、受信機のために問題を起こすべきではないものです。このように、パケットの終了後に任意のTFCパディングバイトは、IPsecソフトウェアは、このようなパディングを削除しない場合でも、ESP処理の後、IPパケット処理中のある時点で削除する必要があります。したがって、これは送信者は、受信機が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.
第二の特徴は、必ずしもTFCのために、トンネルの内部に、十分に形成されたIPパケットを構成しない任意のバイト列であるペイロードを送信する送信者を可能にします。これは、ESPパケット内の次のヘッダーフィールドが値「59」が含まれている場合、ESP v2の受信機は何をするかのよう未解決の問題です。それは病気に形成されたIPヘッダを見つけたときに、パケットを破棄し、このイベントをログに記録しますが、そのような行動は、認証されたピアから受信したトラフィックへのDoS脆弱性の相対を構成するであろうので、それは確かに、クラッシュするべきではないかもしれません。したがって、この機能は、ESP v3の送信者は、受信機がESP v2または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.
RFCの1825-1827：著者は、最初のIPsec活動に重要な役割を果たし、およびIPsec規格の最初のシリーズを執筆蘭アトキンソンの貢献を認めたいと思います。カレンソはこれを編集し、この仕様の以前のバージョンでヘルプを提供するための特別な感謝に値します。著者はまた、このプロトコル仕様の発展に貢献したIPSECとMSECワーキンググループのメンバーに感謝したいと思います。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97]ブラドナーの、S.、BCP 14、RFC 2119、1997年3月 "のRFCsにおける使用のためのキーワードは、要求レベルを示すために"。
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98]デアリング、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]第三イーストレイク、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[ケン-アーチ]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81]ポステル、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]スティーブンM. Bellovin氏、「IPセキュリティプロトコルの問題領域」、第六のUsenix Unixのセキュリティシンポジウム、1996年7月。
[HC03] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress, November 3, 2002.
[HC03]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、進歩、2002年11月3日で働いています。
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Kau05]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[Ken-AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[ケン-AH]ケント、S.、 "IP認証ヘッダー"、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.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、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.リード、 "匿名接続とオニオン・ルーティング"、セキュリティとプライバシー、オークランド、CA、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ビットのシーケンス番号を使用するが、これだけ下位32ビットは、各パケットの一部として送信されたIPsec（ESPおよびAH）で使用するための拡張シーケンス番号（ESN）方式が記載されています。これは、リプレイパケットを検出するために使用されるウィンドウ方式及び再生拒絶および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.のアンチリプレイウィンドウを維持します。 （NO要件が既に32ビットのシーケンス番号のウィンドウのために確立さ32および64のパケット値を超えて、このウィンドウの最小値または推奨サイズのために確立されていない。しかし、実装規模がインタフェース速度と一致して、これらの値がサポートすることが示唆されていますESNオプションを利用して実装することにより、また、以下に説明するアルゴリズムは、ウィンドウの幅が大きくない31 ^ 2よりもパケットであることを前提としている。）上位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）。この場合、ウィンドウは、一つのシーケンス番号の部分空間内にあります。 +ケースB（図1参照）：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 + 1 *********
Th =======*****
第======= *****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
図1 - ケースA
Th ====**************
第==== **************
Th-1 ===
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に対応し、TlのスルーBLから各シーケンス番号は、対応するビットによって表されます。リプレイを検出して排除することができるように、ビットの値は、そのシーケンス番号を持つパケットを受信し、認証されたか否かを示します。
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated,
場合、64ビットのシーケンス番号（SEQ）Tより大きいが受信され検証されたパケット、
+ 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（配列 - T）だけ増加させる+（配列 - T）ビットがウィンドウ+の下端から落下（配列 - 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（ここでB1を= Tlの - W + 1）AND Seql <= T1が、このSeqlが既に見られているかどうかを見るためにウィンドウ内の対応するビットをチェックします。 yesの場合、パケットを拒否します。いいえ、整合性チェックを実行する場合（付録A2.2を参照してください。以下SEQHの決意のため）。
+ 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（ここでB1を= Tlの - W + 1）場合、またはSeql <= T1は、このSeqlが既に見られているかどうかを見るためにウィンドウ内の対応するビットをチェックします。 yesの場合、パケットを拒否します。いいえ、整合性チェックを実行する場合（付録A2.2を参照してください。以下SEQHの決意のため）。
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（ここでB1を= Tlの - W + 1）、次いでSEQH = Thの場合Seql <BL（ここでB1を= 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（ここでB1を= Tlの - W + 1）、次いでSEQH = Thの - 1 Seql <BL（ここでB1を= 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.
次の擬似コードは、アンチリプレイおよび整合性チェックのために上記のアルゴリズムを示します。 'Wと `` Seql ' 'Tlの'、 'のThの値は32ビットの符号なし整数です。算術演算は、2 ^ 32のmodです。
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
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
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上で動作し、したがって、この場合の復旧方法を開発する動機をこの大きさの喪失の自動検出の原因となるフィードバックが欠けているかもしれません。上記の観察は、セキュリティゲートウェイの間、またはホスト間、あるいはホストとセキュリティゲートウェイ間のSAに適用されることに留意されたいです。
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）ペイロードの後に配置されているので（それはペイロードのエンドポイントまでのパケットにわたって完全性アルゴリズムを実行することによって、この手順を最適化することが可能であってもよいし、その値を変化させることによって、異なる候補たICVを計算します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
スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジ、MA 02138 USA
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
電話：+1（617）873-3988 Eメール：kent@bbn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。