サイト内関連リンク：
RFC 791 IP(日本語訳)
RFC 4301 IPsec (日本語訳)
RFC 4302 AH (日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc4303.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
2011/05/29 ver 0.1.0 初公開
ソーシャルブックマーク：
サイト内関連リンク：
RFC 791 IP(日本語訳)
RFC 4301 IPsec (日本語訳)
RFC 4302 AH (日本語訳)
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. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況については "Internet Official Protocol Standards" (STD 1)を参照してほしい。この文書の配布に制限はない。
Copyright (C) The Internet Society (2005).
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 においてセキュリティサービスの組み合わせ提供するために設計されたカプセル化セキュリティペイロード(Encapsulating Security Payload)(ESP)プロトコルの最新版を説明する。ESP は、機密性、データ発信元認証、コネクションレス完全性、アンチリプレイサービス(部分的シーケンス完全性の一種)、限定トラフィックフロー機密性を提供するために使用される。本文書は RFC 2406(1998年11月)を廃止する。
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. 本文書は、読者が "Security Architecture for the Internet Protocol" [Ken-Arch] (以降、セキュリティアーキテクチャ文書と呼ぶ)で説明されている用語と概念とに精通していることを前提としている。特にカプセル化セキュリティペイロード(ESP)[Ken-ESP] と IP 認証ヘッダ(AH)とによって提供されるセキュリティサービスの定義、セキュリティアソシエーションの概念、認証ヘッダ(AH)と同時に ESP を使用する方法、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]. 文書中のキーワード MUST、 MUST NOT、 REQUIRED、 SHALL、 SHALL NOT、 SHOULD、 SHOUL NOT、 RECOMMENDED、 MAY、 OPTIONAL は、それぞれ RFC 2119 [Bra97] で説明されている通りに解釈される。
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6 [DH98]. ESP may be applied alone, in combination with AH [Ken-AH], or in a nested fashion (see the Security Architecture document [Ken-Arch]). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [Ken-Arch]. カプセル化セキュリティペイロード(ESP)ヘッダは IPv4 および IPv6 [DH98] においてセキュリティサービスの組み合わせを提供するために設計されている。ESP は単独で、または AH [Ken-AH] と組み合わせて、またはネストさせて適用できる(セキュリティアーキテクチャ文書 [Ken-Arch] 参照)。セキュリティサービスは通信するホスト同士の間、通信するセキュリティゲートウェイ同士の間、セキュリティゲートウェイとホストとの間で提供できる。さまざまなネットワーク環境における AH および ESP の使用法の詳細については、セキュリティアーキテクチャ文書 [Ken-Arch] を参照してほしい。
The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP ヘッダは IP ヘッダの後、(トランスポートモードの場合)次レイヤプロトコルヘッダの前、または(トンネルモードの場合)カプセル化された IP ヘッダの前に挿入される。これらのモードの詳細は以降で詳細に説明する。
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology. ESP は機密性、データ発信元認証、コネクションレス完全性、アンチリプレイサービス(部分的シーケンス完全性の一種)、(限定的な)トラフィックフロー機密性を提供するために使用することができる。提供されるサービス一式は、セキュリティアソシエーション(SA)の確立時に選択されたオプションと、ネットワークトポロジーにおけるその実装の位置に依存する。
Using encryption-only for confidentiality is allowed by ESP. However, it should be noted that in general, this will provide defense only against passive attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may render the confidentiality service insecure against some forms of active attacks [Bel96, Kra01]. Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against active attackers [Kra01]. ESP allows encryption-only SAs because this may offer considerably better performance and still provide adequate security, e.g., when higher-layer authentication/integrity protection is offered independently. However, this standard does not require ESP implementations to offer an encryption-only service. ESP は機密性のための暗号化のみを使用することを許している。しかしながら、一般にこれは受動的攻撃者に対する保護のみを提供することに注意するべきである。(ESP の中で、または AH によって別途)強力な完全性メカニズムなしに暗号化を使用すると、ある種の能動的攻撃に対して機密性サービスを安全でないものにする可能性がある[Bel96, Kra01]。さらに、暗号化の前に適用される基本的な完全性サービス(AH など)は、能動的攻撃者に対する暗号化のみの機密性を必ずしも保護するわけではない。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. データ発信元認証とコネクションレス完全性とは共同サービスであり、これ以降は合わせて "完全性(integrity)" と呼ぶ。(この用語が採用された理由は、パケットごとの原則で実行される計算がコネクションレス完全性を直接提供するためである。データ発信元認証は IPsec ピアの身元に対する完全性を検証するために使用される鍵をバインドした結果として間接的に提供される。一般にこのバインドは共有対称鍵の使用を通して作用する。) 完全性のみの ESP はサービスの選択オプションとして提供されなければならず(MUST)(例えば SA 管理プロトコルにおいて交渉可能でなければならない)、管理インターフェイスを通して構成可能でなければならない(MUST)。多くの状況において完全性のみの 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 のセキュリティサービスの組み合わせは三つある：
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 に完全性サービスが選択されている場合にのみ選択できる。このサービスの選択は受信側の裁量だけであり、したがって交渉の必要はない。しかしながら、相互運用可能な方法で拡張シーケンス番号の機能を利用するために、ESP は SA 管理プロトコルに対してこの機能を交渉できることを要求する(セクション 2.2.1 参照)。
The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. (ESP may be employed as part of a higher-layer TFC system, e.g., Onion Routing [Syverson], but such systems are outside the scope of this standard.) New TFC features present in ESP facilitate efficient generation and discarding of dummy traffic and better padding of real traffic, in a backward- compatible fashion. 一般にトラフィックフロー機密性(TFC)サービスは、通信者の最終的な送信元・宛先のアドレスを隠すような方法で ESP が採用された場合にのみ効果を持つ。例えばセキュリティゲートウェイ間のトンネルモードにおいて、特定の個々の参加者のトラフィックフローの特徴を隠すために IPsec ピア間に十分なトラフィックが流れる場合などである。(上位層の TFC システム(例えば Onion Routing [Syverson])の一部として ESP が採用されてもよいが、そのようなシステムは本標準の範囲外である。) ESP における現在の新しい TFC 機能は、ダミートラフィックの効率的な生成と破棄、実際のトラフィックの優れたパディングを手助けする。
Section 7 provides a brief review of the differences between this document and RFC 2406. セクション 7 は本文書と RFC 2406 との間の差異の簡単なレビューを提供する。
The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web page at http://www.iana.org/assignments/protocol-numbers). Figure 1 illustrates the top-level format of an ESP packet. The packet begins with two 4-byte fields (Security Parameters Index (SPI) and Sequence Number). Following these fields is the Payload Data, which has substructure that depends on the choice of encryption algorithm and mode, and on the use of TFC padding, which is examined in more detail later. Following the Payload Data are Padding and Pad Length fields, and the Next Header field. The optional Integrity Check Value (ICV) field completes the packet. ESP ヘッダの直前の(外側の)プロトコルヘッダ(IPv4 または IPv6 または拡張)は、そのプロトコルフィールド(IPv4)または次ヘッダフィールド(IPv6、拡張)内に値 50 を含むべきである(SHALL)(IANA のウェブページ http://www.iana.org/assignments/protocol-numbers 参照)。図 1 は ESP パケットの最上位のフォーマットを説明している。パケットは二つの 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
* 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| セキュリティパラメータインデックス (SPI) | ^完全性
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |保護
| シーケンス番号 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| ペイロードデータ* (可変) | | ^
~ ~ | |
| | |機密性
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |保護*
| | パディング (0-255 バイト) | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | パディング長 | 次ヘッダ | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| 完全性検査値 - ICV (可変) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
図 1. ESP パケットの最上位フォーマット
* ペイロードフィールドに含まれる暗号同期データ(例えば初期ベクター(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)を必要とする暗号アルゴリズム(例えば Cipher Block Chaining (CBC) モード)は、しばしばその値で保護されるペイロードデータを前に置く。一部のアルゴリズムモードは暗号化と完全性とを単一のオペレーションに結合する。本文書はそのようなアルゴリズムモードを "結合モードアルゴリズム(combined mode algorithms)" と呼ぶ。結合モードアルゴリズムに適応するには、完全性データを運ぶために使用されるペイロードの下位構造をそのアルゴリズムが明確に説明することが必要である。
Some combined mode algorithms provide integrity only for data that is encrypted, whereas others can provide integrity for some additional data that is not encrypted for transmission. Because the SPI and Sequence Number fields require integrity as part of the integrity service, and they are not encrypted, it is necessary to ensure that they are afforded integrity whenever the service is selected, regardless of the style of combined algorithm mode employed. 一部の結合モードアルゴリズムは、他の結合モードアルゴリズムが送信のために暗号化されていない一部の付加データに完全性を提供できるのに対し、暗号化されるデータにのみ完全性を提供する。SPI およびシーケンス番号フィールドは完全性サービスの一部として完全性を要求し、かつそれらは暗号化されないため、結合アルゴリズムモードが採用されるスタイルにかかわらず、そのサービスが選択されたときには常に完全性が提供されることを保証する必要がある。
When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) may be omitted. When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm to encode within the Payload Data an ICV-equivalent means of verifying the integrity of the packet. 何らかの結合モードアルゴリズムが採用されたとき、そのアルゴリズム自体は復号された平文と完全性チェックの合否とを返すと期待される。結合モードアルゴリズムの場合、(完全性が選択されたときに)通常は ESP パケットの最後に現れるであろう ICV が省略されてもよい。ICV が省略され、かつ完全性が選択されたとき、パケットの完全性を検証する ICV と等価な手段をペイロードデータ内に符号化するのは、結合モードアルゴリズムの責任である。
If a combined mode algorithm offers integrity only to data that is encrypted, it will be necessary to replicate the SPI and Sequence Number as part of the Payload Data. 結合モードアルゴリズムが暗号化されたデータに完全性のみを提供する場合、ペイロードデータの一部として SPI とシーケンス番号とを複製する必要があるだろう。
Finally, a new provision is made to insert padding for traffic flow confidentiality after the Payload Data and before the ESP trailer. Figure 2 illustrates this substructure for Payload Data. (Note: This diagram shows bits-on-the-wire. So even if extended sequence numbers are being used, only 32 bits of the Sequence Number will be transmitted (see Section 2.2.1).) 最後に、ペイロードデータの後、ESP トレイラの前に、トラフィックフロー機密性のためのパディングを挿入するために、新しい規定が設けられている。図 2 はペイロードデータの下位構造を説明している。(注意: この図は通信回線上のビットを示している。そのため、たとえ拡張シーケンス番号が使用されている場合でも、シーケンス番号の 32 ビットのみが送信される(セクション 2.2.1 参照)。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Substructure of Payload Data
* 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| セキュリティパラメータインデックス(SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| シーケンス番号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (オプション) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ペ
| 残りのペイロードデータ (可変) | | イ
~ ~ | ロ
| | | ー
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ド
| | TFC パディング * (オプション, 可変) | v
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | パティング (0-255 バイト) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | パティング長 | 次ヘッダ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 完全性検査値 - ICV (可変) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
図 2. ペイロードデータの下位構造
* トンネルモードが使用されている場合、IPsec 実装はペイロードデー
タの後、パディング(0-255 バイト)フィールドの前に、トラフィック
フロー機密性(TFC)のパディング(セクション 2.4 参照)を追加するこ
とができる。
If a combined algorithm mode is employed, the explicit ICV shown in Figures 1 and 2 may be omitted (see Section 3.3.2.2 below). Because algorithms and modes are fixed when an SA is established, the detailed format of ESP packets for a given SA (including the Payload Data substructure) is fixed, for all traffic on the SA. 結合アルゴリズムモードを採用した場合、図 1・図 2 に示されている明示的な ICV を省略してもよい(セクション 3.3.2.2 参照)。アルゴリズムとモードとは SA の確立時に固定されるため、特定の SA のための 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
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
表 1. 暗号化/完全性の独立したアルゴリズム
バイト 必須 暗号 完全性 送信
数 [1] 保護 保護 内容
------ ------ ------ ------ ------
SPI 4 M Y 平文
シーケンス番号 4 M Y 平文
(下位ビット)
------ ペ
IV 可変 O Y 平文 | イ
IP データグラム [2] 可変 M or D Y Y 暗号文[3] |-ロ
TFC パディング [4] 可変 O Y Y 暗号文[3] | ー
------ ド
パディング 0-255 M Y Y 暗号文[3]
パディング長 1 M Y Y 暗号文[3]
次ヘッダ 1 M Y Y 暗号文[3]
シーケンス番号 4 ESNの場合[5] Y 送信されない
(上位ビット)
ICV パディング 可変 必要なら Y 送信されない
ICV 可変 M [6] 平文
[1] M = 必須; O = オプション; D = ダミー
[2] トンネルモードの場合 -> IP データグラム
トランスポートモードの場合 -> 次ヘッダおよびデータ
[3] 暗号化が選択されている場合は暗号文
[4] ペイロードが "正しい(real)" 長さを規定する場合にのみ
使用することができる
[5] セクション 2.2.1 参照
[6] 独立した完全性アルゴリズムが使用される場合は必須
Table 2. Combined Mode Algorithms
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
表 2. 結合モードアルゴリズム
バイト 必須 暗号 完全性 送信
数 [1] 保護 保護 内容
------ ------ ------ ------ ------
SPI 4 M 平文
シーケンス番号 4 M 平文
(下位ビット)
--- ペ
IV 可変 O Y 平文 | イ
IP データグラム [2] 可変 M or D Y Y 暗号文 |-ロ
TFC パディング [3] 可変 O Y Y 暗号文 | ー
--- ド
パディング 0-255 M Y Y 暗号文
パディング長 1 M Y Y 暗号文
次ヘッダ 1 M Y Y 暗号文
シーケンス番号 4 ESNの場合[4] Y [5]
(上位ビット)
ICV パディング 可変 必要なら Y [5]
ICV 可変 O [6] 平文
[1] M = 必須; O = オプション; D = ダミー
[2] トンネルモードの場合 -> IP データグラム
トランスポートモードの場合 -> 次ヘッダおよびデータ
[3] ペイロードが "正しい(real)" 長さを規定する場合にのみ
使用することができる
[4] セクション 2.2.1 参照
[5] これらが送信されるかどうかはアルゴリズムの選択により決まるが、
いずれにしても結果は ESP に見えない
[6] 現れるかどうかをアルゴリズム仕様が決定する
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. 以下のサブセクションではヘッダフォーマット内のフィールドを説明する。"オプション(optional)" は、そのフィールドが選択されていない場合にフィールドが省略されることを意味する(つまり送信されるパケットにも ICV 計算のための書式調整(セクション 2.7 参照)としても現れない)。オプションが選択されるかどうかは、セキュリティアソシエーション(SA)の確立の一部として決定される。したがって特定の SA のための ESP パケットのフォーマットは、その SA の持続期間中固定される。対照的に "必須(mandatory)" フィールドはすべての 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 のバージョンを保証するために、二つの IPsec ピア間での通知メカニズム(例えば Internet Key Exchange (IKEv2) [Kau05])、または帯域外の構成メカニズムを使用してそれに対処しなければならない(MUST)。
The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory. SPI は任意の 32 ビット値であり、入力パケットがひも付けられている SA を識別するために受信者によって使用される。SPI フィールドは必須である。
For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Because the SPI value is generated by the receiver for a unicast SA, whether the value is sufficient to identify an SA by itself or whether it must be used in conjunction with the IPsec protocol value is a local matter. This mechanism for mapping inbound traffic to unicast SAs MUST be supported by all ESP implementations. ユニキャスト SA の場合、SPI はそれだけで SA を特定するために使用可能だが、IPsec プロトコルタイプ(この場合は ESP)と組み合わせて使用してもよい。ユニキャスト SA のための SPI の値は受信者によって生成されるため、その値だけで SA を識別するのに十分かどうか、または IPsec プロトコル値と組み合わせて使用しなければならないかどうかは、ローカルの問題である。インバウンドトラフィックをユニキャスト SA にマッピングするためのこのメカニズムは、すべての ESP 実装がサポートしなければならない(MUST)。
If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm. マルチキャストをサポートする IPsec 実装は、入力 IPsec データグラムを複数の SA にマッピングするための後述のアルゴリズムを使用するマルチキャスト SA をサポートしなければならない(MUST)。ユニキャストトラフィックのみをサポートする実装は、この分離アルゴリズムを実装する必要はない。
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])の多くでは、中央の Group Controller/Key Server が一方的にグループセキュリティアソシエーションの SPI を割り当てる。この SPI の割り当ては、そのグループを構成する個々のエンドシステム上の鍵管理サブシステム(例えば IKE)と交渉したり協調したりすることはない。その結果として、グループセキュリティアソシエーションとユニキャストセキュリティアソシエーションとが同時に同じ SPI を使用する可能性がある。マルチキャスト能力を持つ IPsec 実装は、SPI がコリジョンを起こす状況であっても、インバウンドトラフィックを正しく分離しなければならない(MUST)。
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: SA データベース(SAD)[Ken-Arch]の各エントリは、SPI に加え、その SA の検索が宛先 IP アドレスを利用するのか、宛先/送信元 IP アドレスを使用するのかを示さなければならない。マルチキャスト SA の場合、SA 検索にプロトコルフィールドは採用されない。インバウンドの IPsec 保護されたパケットごとに、実装は "もっとも長い(longest)" SA 識別子と一致するエントリを見つけるために、SAD の検索を実行しなければならない。この状況において、SPI に基づいて検索したときに二つ以上の SAD エントリが一致した場合、(その SAD エントリ内で指定された通り)宛先アドレスまたは宛先/送信元アドレスに基づいて一致したエントリが、 "もっとも長い(longest)" 一致となる。これは、以下のような SAD 検索の論理的順序付けを意味している：
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 を検索するのと等価でなければならない(MUST)。例えばソフトウェアベースの実装は、SPI によりハッシュテーブルにインデックスを作成することができる。各ハッシュテーブル内の SAD エントリのリンクリストは、もっとも長い SA 識別子をリンクリスト内の最初に置くようにソートされた状態を維持する。もっとも短い SA 識別子を持つ SAD エントリは、リンクリスト内で最後のエントリになるように並べる。ハードウェアベースの実装は、一般的に利用可能な三値連想メモリ(Ternary Content-Addressable Memory)(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. インバウンド IPsec トラフィックを SA にマップするために送信元/宛先アドレスの一致が必要かどうかの指定は、手動 SA 構成の副作用として、または SA 管理プロトコル(例えば IKE や Group Domain of Interpretation (GDOI) [RFC3547] など)による交渉を通して設定されなければならない(MUST)。一般に Source-Specific Multicast (SSM) [HC03] グループは、SPI・宛先マルチキャストアドレス・送信元アドレスの三要素から成る SA 識別子を使用する。Any-Source Multicast グループの SA は、識別子として SPI と 宛先マルチキャストアドレスとだけを必要とする。
The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.) 1 ～ 255 の範囲の SPI 値は、Internet Assigned Numbers Authority (IANA) によって将来のために予約されている。通常、予約済みの SPI 値は RFC において規定されない限り IANA によって割り当てられることはない。ゼロ(0)の SPI 値はローカルの実装固有の用途に予約されており、送信されてはならない(MUST NOT)。(例えば鍵管理の実装は、IPsec 実装が自身の鍵管理エンティティが新しい SA の確立を要求したが、まだそれが確立されていない間に、"セキュリティアソシエーションが存在しない(No Security Association Exists)")ことを表すために、ゼロの 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 の場合、送信者はパケット送信ごとにこのフィールドをインクリメントしなければならない(MUST)。複数の送信者間で 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 のためにアンチリプレイサービスを有効にしていない場合でも、常に現れなければならない(MUST)。シーケンス番号フィールドの処理は受信者の裁量だが、すべての ESP 実装はセクション 3.3.3 およびセクション 3.4.3 で説明されている処理を実行する能力を持たなければならない(MUST)。したがって送信者は常にこのフィールドを送信しなければならない(MUST)が、受信者がそれに基づいて動作する必要はない("インバウンドパケットの処理(Inbound Packet Processing)" セクション(3.4.3)内のシーケンス番号の検証の議論を参照してほしい)。
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.3 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 送信側のカウンタと受信側のカウンタは、SA の確立時に 0 に初期化される。(ある SA を使用して送信される最初のパケットはシーケンス番号 1 を持つことになる。シーケンス番号の生成方法に付いての詳細はセクション 3.3.3 を参照してほしい。) アンチリプレイが有効な場合(デフォルトは有効である)、転送されるシーケンス番号は決して循環してはならない。したがって送信側のカウンタと受信側のカウンタは、ひとつの SA 上で 2^32 番目のパケットが転送される前に(新しい鍵で新しい SA を確立することで)リセットされなければならない(MUST)。
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 実装をサポートするために、現状の 32 ビットシーケンス番号フィールドの拡張として、拡張シーケンス番号(ESN)を実装するべきである(SHOULD)。ESN の使用は、SA 管理プロトコルによって交渉されなければならない(MUST)。IKEv2 ではこの交渉は暗黙的に行われ、32 ビットシーケンス番号が明示的に交渉されない限り、デフォルトで ESN が使用されることに注意してほしい。(ESN 機能はマルチキャスト SA にもユニキャスト 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 ビットシーケンス番号が使用可能になる。(詳細は付録 A "拡張(64 ビット)シーケンス番号"を参照してほしい。) 各パケットの平文 ESP ヘッダ内ではシーケンス番号の下位 32 ビットのみが転送されるため、パケットのオーバーヘッドは最小化される。上位 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 の一部として、長さ、データの任意の構造、そのデータの位置 を示さなければならない(MUST)。(一般に IV は暗号文の直前に置かれる。図 2 参照。) 同期データが暗黙の場合、データを抽出するためのアルゴリズムはそのアルゴリズムを定義する RFC の一部でなければならない(MUST)。(暗号同期データ(例えば初期化ベクター(IV))がペイロードフィールドに含まれる場合、それは時に暗号文の一部であるとして言及されるが、通常それ自体は暗号化されない。)
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 ヘッダの開始に対してアラインメントされなければならない(MUST)ことに注意してほしい。このアラインメントはIPv4 では 4 バイトの倍数、IPv6 では 8 バイトの倍数である。
With regard to ensuring the alignment of the (real) ciphertext in the presence of an IV, note the following: IV が存在する場合の(本当の)暗号文のアラインメントを保証することに関して、以下の事項に注意してほしい：
Two primary factors require or motivate use of the Padding field. パディングフィールドの使用を要求または動機付ける主な要因は二つある：
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 バイトのパディングを追加してよい(MAY)。ESP パケット内にパディングフィールドを含めることは、前述の要件に従うことを条件としてオプションだが、すべての実装はパディングの生成と消費とをサポートしなければならない(MUST)。
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.) パディングバイトが必要だが暗号アルゴリズムがパディングの内容を指定していない場合、以下のデフォルトの処理が使用されなければならない(MUST)。パディングバイトは連続する整数値(符号なし、1 バイト)で初期化される。平文に付加される先頭のパディングバイトは 1 とし、後続のパディングバイトは単調増加数列を作り上げる(1、2、3 ……)。このパディング方法を採用する場合、受信者はパディングフィールドを検査するべきである(SHOULD)。(この手法が選択された理由は、その相対的な簡潔性、ハードウェアへの実装の簡単さ、そして他の完全性対策がない場合に受信者が復号時にこのパディング値を確認すれば、特定の形式の "カットアンドペースト(cut and paste)" 攻撃に対する限定的な保護を提供するためである。)
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 によって規定されなければならない(MUST)。パディングに使用されるバイトの値の確認をアルゴリズムが要求する場合、それもその RFC において規定されなければならない(MUST。
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 参照)のサポートにおいてパディングトラフィックの迅速な生成と破棄とを促進するために、"ダミー(dummy)" パケットを表すプロトコル値 59("次ヘッダなし(no next header)" を意味する)を使用しなければならない(MUST)。送信者は次プロトコルフィールドにこの値を持つダミーパケットを生成する能力を持たなければならず(MUST)、受信者はそのようなパケットをエラーを発生させずに破棄する用意ができていなければならない(MUST)。ダミーパケットにはすべての ESP ヘッダフィールドおよびトレイラフィールド(SPI、シーケンス番号、パディング、パディング長、次ヘッダ、ICV)が現れなければならない(MUST)が、ペイロードの平文部(次ヘッダフィールドを除く)は厳密に形成される必要はない(例えばペイロードデータの残りはランダムなバイトから構成されてもよい)。ダミーパケットは偏見なく破棄される。
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 ごとに有効化するローカルの管理制御機構を提供するべきである(SHOULD)。この制御機構は、この機能が使用されるべきかどうかをユーザーが指定することを許可するべきであり、またパラメータによる制御も提供するべきである。例えばこの制御機構は、管理者がランダムな長さまたは固定長のダミーパケットを生成することを許可してもよい。
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. 考察： 実際のトラフィックがないことを隠すために、ダミーパケットを任意の間隔で挿入することができる。また、ダミートラフィックを追加される配布先に適するように、配布パラメータによって決定される通りに実際のトラフィックの "形を変える(shape)" ことも可能である。トラフィックフローセキュリティ(TFS)のためのパケット長パディング機能と同様、もっとも安全なアプローチは、SA 上で一定の流量を維持するのに必要となる割合でダミーパケットを生成することだろう。パケットがすべて同じサイズであれば、SA は見かけ上一定のビットレートのデータストリームになる(レイヤ 1 または 2 で回線暗号が提供するものに似ている)。しかしながら、これは多くの状況で実用的ではなさそうである。例えば複数の SA がアクティブなときがそうで、サイトに許される帯域が SA の数によって減るということを意味し、またパケット交換の利益を損ねるためである。実装は、TFC の目的のためのダミーパケットの生成をローカル管理者が管理することを可能にする制御機能を提供するべきである(SHOULD)。
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 実装は、ペイロードデータの終端の後、パディングフィールドの開始の前にバイトを追加することで、トラフィックにパディングを入れる能力を持つべきである(SHOULD)。しかしながらこのパディング(これ以降 TFC パディングと呼ぶ)は、ペイロードデータフィールドが IP データグラムの長さの指定を含む場合にのみ追加することができる。これはトンネルモードの場合には常に当てはまり、トランスポートモードの場合には次レイヤプロトコル(例えば IP、UDP、ICMP)が明示的な長さ情報を含むかどうかに依存して当てはまる場合がある。この長さ情報によりペイロードデータの本当の長さが分かるため、受信者は TFC パディングを破棄することが可能になる。(ESP トレイラフィールドは ESP パケットの終端から逆算して位置付けられる。) したがって TFC パディングが追加された場合、IP データグラムの長さの指定を含むフィールドはこのパディングの影響で変更されてはならない(MUST NOT)。本仕様はこのパディングの値のための要件を規定しない。
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 管理プロトコルは送信側がそれを採用するのに先立ってこのサービスを交渉しなければならない(MUST)。セクション 2.6 で説明されている習慣(プロトコル ID 59 を使用すること)と組み合わせて、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 の長さと比較規則、検証のための処理ステップを規定しなければならない(MUST)。
ESP may be employed in two ways: transport mode or tunnel mode. ESP は二つの方法で採用できる。トランスポートモード、またはトンネルモードである。
In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol. (If AH is also applied to a packet, it is applied to the ESP header, Payload, ESP trailer, and ICV, if present.) (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (This and subsequent diagrams in this section show the ICV field, the presence of which is a function of the security services and the algorithm/mode selected.) トランスポートモードの場合、ESP は IP ヘッダの後、次レイヤプロトコル(TCP、UDP、ICMP など)の前に挿入される。IPv4 環境の場合、これは IP ヘッダ(およびそれに含まれる任意のオプション)の後、次レイヤプロトコルの前と解釈される。(パケットに AH も適用されている場合、それは ESP ヘッダ・ペイロード・ESP トレイラ、そして(もしあれば)ICV にも適用される。) ("トランスポート(transport)" モードという用語を、TCP および UDP に制限されるものと誤解してはならない。) 以下の図は、典型的な IPv4 パケットのための ESP トランスポートモードの位置取りを "前後(before and after)" の原則で示している。(これと本セクションの以降の図とは 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 ------->|
ESP 適用前
---------------------------------
IPv4 |元の IP ヘッダ | | |
|(任意のオプション)| TCP |データ|
---------------------------------
ESP 適用後
--------------------------------------------------------
IPv4 |元の IP ヘッダ | ESP | | | ESP | ESP|
|(任意のオプション)| ヘッダ | TCP |データ|トレイラ| ICV|
--------------------------------------------------------
|<----- 暗号化 ------>|
|<----------- 完全性 --------->|
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 適用前
----------------------------------------
IPv6 | |もしあれば| | |
|元の IP ヘッダ|拡張ヘッダ| TCP |データ|
----------------------------------------
ESP 適用後
--------------------------------------------------------
IPv6 |元の |ホップバイホップ, 宛先*, | | 宛先 |...
|IP ヘッダ|ルーティング, フラグメント|ESP| オプション*|...
--------------------------------------------------------
|<----------
|<--------------
-------------------------
... | | ESP | ESP|
... TCP|データ|トレイラ| ICV|
--------------------------
---- 暗号化 ------------->|
---- 完全性 ------------->|
* = もし現れる場合、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-stack" または "bump-in-the-wire" の実装は、本仕様に従い、かつ透過的な IPsec サポートを提供するために、余分の IP 再構築/フラグメンテーションを実行する IPsec 実装を要求する可能性があることに注意してほしい。複数のインターフェイスを使用している場合、これらの実装内部でこれらの操作を実行するために特別な注意が必要である。
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. トンネルモードの場合、"内側の(inner)" IP ヘッダは最終的な(IP)送信元/宛先アドレスを伝え、"外側の(outer)" IP ヘッダは IPsec "ピア(peers)"のアドレス(例えばセキュリティゲートウェイのアドレス)を含む。内側および外側の IP バージョンの混在、つまり IPv4 上の IPv6、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
-----------------------------------------------------------
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
------------------------------------------------------------
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.
ESP 適用前
---------------------------------
IPv4 |元の IP ヘッダ | | |
|(任意のオプション)| TCP |データ|
---------------------------------
ESP 適用後
------------------------------------------------------------------
IPv4 |新しい IP ヘッダ*| |元の IP ヘッダ* | | |ESP |ESP|
|(任意のオプション|ESP|(任意のオプション)|TCP|データ|トレイラ|ICV|
------------------------------------------------------------------
|<---------------- 暗号化 -------------->|
|<-------------------- 完全性 ---------------->|
ESP 適用前
---------------------------------------
IPv6 | |もしあれば| | |
|元の IP ヘッダ|拡張ヘッダ| TCP |データ|
---------------------------------------
ESP 適用後
--------------------------------------------------------------
IPv6 |新しい |新しい | |元の |元の | | |...
|IP ヘッダ*|拡張ヘッダ*|ESP|IP ヘッダ*|拡張ヘッダ*|TCP|データ|...
--------------------------------------------------------------
|<--------- 暗号化 ----------------
|<------------ 完全性 -----------------
---------------
... ESP | ESP|
... トレイラ| ICV|
---------------
------------->|
------------->|
* = もし現れる場合、外側の IP ヘッダ/拡張の構築と内側の IP ヘッ
ダ/拡張の変更は、セキュリティアーキテクチャ文書において議論
される。
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 のために必須のアルゴリズムを超える追加のアルゴリズムがサポートされてもよい(MAY)。信頼性と完全性とはともにオプションだが、少なくともどちらか一方は選択されなければならず(MUST)、したがって両方のアルゴリズムが同時に NULL であってはならない(MUST NOT)ことに注意してほしい。
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 を導き出すために平文のヘッダ情報を使用する場合、その情報はセキュリティ問題になる可能性があるため、暗号化プロセスに関連する保護境界が増大する可能性がある。) 例えば IV を導き出すために ESP のシーケンス番号を使用する場合、そのシーケンス番号の生成ロジック(ハードウェアまたはソフトウェア)は暗号アルゴリズムの一部として評価される。FIPS 140-2 [NIST01] の場合、これは暗号化モジュール評価の範囲を著しく拡張する。ESP は平文のパディングに備えるため、ESP とともに採用される暗号アルゴリズムはブロックまたはストリームのどちらかのモードの特性を示す。暗号化(信頼性)はオプションのサービスであってよい(MAY)ため(例えば完全性のみの ESP)、このアルゴリズムが "NULL" であってもよい(MAY)ことに注意してほしい[Ken-Arch]。
To allow an ESP implementation to compute the encryption padding required by a block mode encryption algorithm, and to determine the MTU impact of the algorithm, the RFC for each encryption algorithm used with ESP must specify the padding modulus for the algorithm. ESP 実装がブロックモードの暗号アルゴリズムの要求する暗号化パディングを計算し、アルゴリズムの MTU への影響を決定できるようにするために、ESP とともに使用される各暗号アルゴリズムのための RFC はそのアルゴリズムのためのパディングモジュールを規定しなければならない。
The integrity algorithm employed for the ICV computation is specified by the SA via which the packet is transmitted/received. As was the case for encryption algorithms, any integrity algorithm employed with ESP must make provisions to permit processing of packets that arrive out of order and to accommodate packet loss. The same admonition noted above applies to use of any plaintext data to facilitate receiver synchronization of integrity algorithms. Note that because the integrity service MAY be optional, this algorithm may be "NULL". ICV 計算のために採用される完全性アルゴリズムは、パケットの送受信を通じて SA によって指定される。暗号アルゴリズムの場合と同じように、ESP とともに採用される任意の完全性アルゴリズムは、ばらばらに到着したパケットの処理を可能にし、パケット損失に対応する用意がなければならない。上記と同じ忠告は、受信側の完全性アルゴリズムの同期を手助けするための任意の平文データの使用にも適用される。完全性サービスはオプションであってよい(MAY)ため、このアルゴリズムが "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. 結合モードアルゴリズムの MTU への影響を ESP 実装が判断できるように、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 は、ESP 処理を要求した SA にパケットが関連すると IP 実装が判断した後にのみ出力パケットに適用される。アウトバウンドトラフィックに(もしあれば)どの 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)を使用することで "信頼性なし(no confidentiality)" が提供されるという理解のもとで行われる。アルゴリズム的選択肢がいくつか存在する。
If separate confidentiality and integrity algorithms are employed, the Sender proceeds as follows: 信頼性/完全性の独立したアルゴリズムを採用する場合、送信側は以下のように進める：
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 パケットの終わりに暗黙のパディングが付加されなければならない(MUST)。(このパディングは次ヘッダフィールドの後、または ESN が選択されている場合にはシーケンス番号の上位 32 ビットの後に追加される。) ブロックサイズ(したがってパディングの長さ)は、完全性アルゴリズム仕様によって規定される。このパディングはパケットとともに送信されない。上記の通りの暗黙のパディングが必要とされるかどうかを判断するために、完全性アルゴリズムを定義する文書を調べなければならない(MUST)。その文書がこの疑問の答えを規定していない場合、デフォルトは(パケット長がそのアルゴリズムのブロックサイズに一致するために必要となるだけの)暗黙のパディングが必要とされると仮定することである。パディングバイトが必要だが、アルゴリズムがパディングの内容を規定しない場合、パディングの内容は値ゼロでなければならない(MUST)。
If a combined confidentiality/integrity algorithm is employed, the Sender proceeds as follows: 信頼性/完全性を合わせ持つアルゴリズムを採用した場合、送信側は以下のように進める：
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 上で送信してはならない(MUST NOT)ということである。シーケンス番号のオーバーフローを引き起こすパケットの送信の試みは、監査可能なイベントである。このイベントのための監査ログエントリは、SPI 値・現在の日付/時刻・送信元アドレス・宛先アドレス・(IPv6 の場合)平文のフロー ID を含むべきである(SHOULD)。
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3). Thus, typical behavior of an ESP implementation calls for the sender to establish a new SA when the Sequence Number (or ESN) cycles, or in anticipation of this value cycling. 送信側は受信側から通知されない限り、デフォルトでアンチリプレイが有効化されていると仮定する(セクション 3.4.3. 参照)。したがって ESP 実装の典型的な振る舞いは、シーケンス番号(または ESN)が循環するとき、またはその値の循環を予想して、新しい SA の確立を送信者に要求するというものである。
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 を計算するために使用される鍵が手動で配布される場合、準拠する実装はアンチリプレイサービスを提供するべきではない(SHOULD NOT)。ユーザーが SA と連動して手動で鍵化されたアンチリプレイを採用することを選択した場合、その鍵が置き換えられるまで、送信側のシーケンス番号カウンタはローカルのリブートなどをまたいでも正しく保守されなければならない(MUST)(セクション 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.) アンチリプレイが無効化されている場合、送信側はカウンタを監視またはリセットする必要がない。しかしながら、それでも送信側はカウンタをインクリメントし、それが最大値に達したときにゼロに戻す。(送信側と受信側との間で本仕様の範囲外のアンチリプレイメカニズムが交渉されていない限り、この振る舞いは複数送信者のマルチキャスト SA に推奨される。)
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 を交渉するべきではない(SHOULD NOT)。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. ESP 処理の後、必要であれば IPsec 実装内部でフラグメンテーションが実行される。したがってトランスポートモード ESP は(IP フラグメントにではなく) IP データグラム全体にのみ適用される。ESP を適用された IP パケット自体が経路上のルータによってフラグメント化される可能性があり、そのようなフラグメントは受信側の ESP 処理に先立って再構築されなければならない。トンネルモードの場合、ESP が適用されるのは IP パケットであり、それは IP データグラムのフラグメントである可能性がある。例えば、セキュリティゲートウェイまたは "bump-in-the-stack" または "bump-in-the-wire" の 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 の終わりで述べた通り、bump-in-the-stack および bump-in-the-wire の実装は、ローカル 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 の場合 -- bump-in-the-stack および bump-in-the-wire の実装の場合、フラグメンテーションが存在するかどうか、つまりそのパケットが 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 実装はフラグメンテーションをサポートしないことを選択してもよく(MAY)、パス MTU(PMTU)探索を手助けするために、送信されるパケットに DF ビットを付けてもよい。いずれにしても ESP 実装はフラグメンテーションの可能性を最小化するために、ICMP PMTU メッセージ(またはネイティブホスト実装の場合はそれと等価な内部シグナル)の生成をサポートしなければならない(MUST)。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 フラグメントと思われる場合、つまり OFFSET フィールドが非ゼロまたは MORE FRAGMENTS フラグがセットされている場合、受信側はパケットを破棄しなければならない(MUST)。これは監査可能なイベントである。このイベントのための監査ログエントリは、SPI 値・受信した日付/時刻・送信元アドレス・宛先アドレス・シーケンス番号・(IPv6 の場合)フロー ID を含むべきである(SHOULD)。
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 仕様は、パケット再構築のために OFFSET フィールドをゼロにすることも、MORE FRAGMENTS フラグをクリアすることも要求しない。再構築されたパケットが(見掛け上フラグメントであるために破棄されるのではなく) IPsec によって処理されるように、IP コードはパケットを再構築した後にこれら二つのことを行わなければならない。
Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked, whether 32- or 64-bit sequence numbers are employed for the SA, and whether the (explicit) ICV field should be present (and if so, its size). Also, the SAD entry will specify the algorithms and keys to be employed for decryption and ICV computation (if applicable). ESP ヘッダを含むパケットを受信すると、受信側は SAD の検索によって適切な(単方向) SA を判断する。ユニキャスト SA の場合、この判断は SPI、または SPI とプロトコルフィールドとに基づく(セクション 2.1 で説明されている通り)。実装がマルチキャストトラフィックをサポートする場合、この検索に(SPI に加えて)宛先アドレスも採用され、さらに送信元アドレスが採用されてもよい(セクション 2.1 で説明されている通り)。(この処理はセキュリティアーキテクチャ文書においてより詳細に説明されている。) また SA のための SAD エントリは、シーケンス番号フィールドがチェックされるかどうか、その SA のために 32 ビットまたは 64 ビットのどちらのシーケンス番号が採用されるか、(明示的な) ICV フィールドが現れるかどうか(もし現れるならそのサイズも)を示す。また SAD エントリは、復号と(該当する場合) ICV 計算とに採用されるべきアルゴリズムと鍵とを指定するだろう。
If no valid Security Association exists for this packet, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID. パケットのために有効なセキュリティアソシエーションが存在しない場合、受信側はそのパケットを破棄しなければならない(MUST)。これは監査可能なイベントである。このイベントのための監査ログエントリは、SPI 値・受信した日付/時刻・送信元アドレス・宛先アドレス・シーケンス番号・(IPv6 の場合)平文のフロー ID を含むべきである(SHOULD)。
(Note that SA management traffic, such as IKE packets, does not need to be processed based on SPI, i.e., one can demultiplex this traffic separately based on Next Protocol and Port fields, for example.) (IKE パケットなどの SA 管理トラフィックは SPI に基づいて処理される必要がないことに注意してほしい。つまり、例えば次プロトコルフィールドとポートフィールドとに基づいてそのトラフィックを分離できるということである。)
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below. すべての ESP 実装はアンチリプレイサービスをサポートしなければならない(MUST)が、その使用は受信者によって SA ごとに有効化または無効化されてよい。このサービスは、その SA のために ESP の完全性が有効化されていない限り、有効化されてはならない(MUST NOT)。そうでなければシーケンス番号フィールドが完全性保護されないためである。アンチリプレイはユニキャストだけでなくマルチキャストの 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 の確立中にその旨を送信側に通知するべきである(SHOULD)。
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 の確立時にゼロに初期化されなければならない(MUST)。受信側は各受信パケットごとに、そのパケットが SA の寿命の間に受信した他のパケットのシーケンス番号と重複しないシーケンス番号を持つことを検証しなければならない(MUST)。重複パケットの拒否を高速化するために、パケットが SA に一致した後に適用される最初の ESP のチェックがこれであるべきである(SHOULD)。
ESP permits two-stage verification of packet sequence numbers. This capability is important whenever an ESP implementation (typically the cryptographic module portion thereof) is not capable of performing decryption and/or integrity checking at the same rate as the interface(s) to unprotected networks. If the implementation is capable of such "line rate" operation, then it is not necessary to perform the preliminary verification stage described below. ESP はパケットシーケンス番号の 2 段階の検証を許可している。この能力は、ESP 実装が非保護側ネットワークへのインターフェイスと同じ速度で復号や完全性チェックを実行する能力を持たない場合に重要である。実装がそのような "回線速度(line rate)" での動作能力を持つ場合、後述する事前検証のステップを実行する必要はない。
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.) ウィンドウの "右(right)" 端はその SA 上で受信した最大の有効なシーケンス番号を表す。ウィンドウの "左(left)" 端より小さいシーケンス番号を持つパケットは拒否される。ウィンドウの内側に含まれるパケットは、ウィンドウ内の受信済みパケットのリストに対して確認される。SA のために ESN オプションが選択されている場合、シーケンス番号の下位 32 ビットのみが明示的に送信されるが、受信側は受信したシーケンス番号を受信ウィンドウに対して確認するとき、指定された SA のための上位 32 ビットを使用して計算された完全なシーケンス番号を採用する。完全なシーケンス番号の生成において、パケット内で運ばれた下位 32 ビットが受信側のシーケンス番号の下位 32 ビットより小さい値の場合、受信側は、上位 32 ビットがインクリメントされ、新しいシーケンス番号の部分空間に移動したと仮定する。(このアルゴリズムは単一 SA のための 2**32-1 パケットと同じ受信間隔に適応する。それより大きい間隔が発生した場合、受信側シーケンス番号カウンタの再同期のための追加の発見的チェック(付録で説明されている)が採用されてもよい(MAY)。)
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 データグラムを無効として破棄しなければならない(MUST)。これは監査可能なイベントである。このイベントのための監査ログエントリは、SPI 値・受信した日付/時刻・送信元アドレス・宛先アドレス・シーケンス番号・(IPv6 の場合)フロー ID を含むべきである(SHOULD)。受信ウィンドウは完全性検証に成功した場合にのみ更新される。(結合モードアルゴリズムが使用されている場合、完全性保護されたシーケンス番号は、アンチリプレイ保護のために使用されるシーケンス番号にも一致しなければならない。)
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 パケットのウィンドウサイズをサポートしなければならない(MUST)。ウィンドウサイズは 64 が望ましく、デフォルトで採用されるべきである(SHOULD)。受信側は(最低より大きい)別のウィンドウサイズを選択してもよい(MAY)。(受信側は送信側にウィンドウサイズを通知しない。) 高速な環境では保証問題と関係なく受信ウィンドウサイズを増やすべきである。本仕様は非常に高速(例えば数ギガビット/秒)なデバイスのための最低および推奨される受信ウィンドウサイズを規定しない。
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: 信頼性/完全性の独立したアルゴリズムを採用した場合、以下のように処理を進める：
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 と受信した ICV とが一致した場合、そのデータグラムは有効であり、受け入れられる。このテストに失敗した場合、受信した IP データグラムを無効として破棄しなければならない(MUST)。これは監査可能なイベントである。このログ情報は、SPI 値・受信した日付/時刻・送信元アドレス・宛先アドレス・シーケンス番号・(IPv6 の場合)平文のフロー ID を含むべきである。
Implementation Note: 実装の注意：
Implementations can use any set of steps that results in the same result as the following set of steps. Begin by removing and saving the ICV field. Next check the overall length of the ESP packet minus the ICV field. If implicit padding is required, based on the block size of the integrity algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field, or after the high-order 32 bits of the sequence number if ESN is selected. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. 実装は次の手順と同じ結果になる任意の手順を使用することができる。最初に ICV フィールドを保存し取り除く。次に ICV フィールドを除く ESP パケット全体の長さを確認する。暗黙のパディングが必要な場合、完全性アルゴリズムのブロックサイズに基づいて、次ヘッダフィールドの直後または ESN が選択されている場合はシーケンス番号の上位 32 ビットの直後の ESP パケットの終端に、ゼロ埋めされたバイトを付加する。ICV 計算を実行し、そのアルゴリズム仕様が定義する比較規則を使用して、その結果を保存した値と比較する。
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 バイトにアラインメントされることを保証するべきである(SHOUD)。この処理は、トラフィックフロー信頼性のために追加された任意の(オプションの) TFC パディングを "切り捨てる(discards)"。(TFC パディングが現れる場合、IP データグラム(またはトランスポートレイヤフレーム)の後、パディングフィールドの前に挿入されているだろう(セクション 2.4 参照)。)
If integrity checking and encryption are performed in parallel, integrity checking MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. 完全性チェックと暗号化とが並行して実行される場合、復号されたパケットがさらなる処理に渡される前に、完全性チェックが完了しなければならない(MUST)。この処理順序は、リプレイパケットまたは偽装パケットを復号前に受信者が迅速に検出・拒否する手助けをし、したがってサービス不能(DoS)攻撃の影響を潜在的に縮小する。
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: 信頼性および完全性を合わせ持つアルゴリズムを採用した場合、受信側は以下の通り進める：
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 実装も監査をサポートしなければならず(MUST)、システム管理者が ESP のための監査を有効化または無効化することを許可しなければならない(MUST)。監査の粒度は大部分がローカルの問題である。しかしながら本仕様においていくつかの監査可能なイベントが特定されており、それらのイベントごとに監査ログに含まれるべき(SHOULD)最低限の情報の集合が定義されている。
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. これらの各イベントのための監査ログには追加の情報が含まれてもよい(MAY)し、本仕様において明示的に呼び出されていない追加のイベントが監査ログエントリを生成してもよい(MAY)。監査可能なイベントの検出に応えて送信者と思われる相手に受信側が何らかのメッセージを送信する要件はない。そのような動作はサービス不能を引き起こす可能性があるためである。
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 の構文と処理とを実装しなければならず(MUST)、セキュリティアーキテクチャ文書 [Ken-Arch] によって課されるすべての追加パケット処理の要求事項に従わなければならない(MUST)。さらにマルチキャストトラフィックのサポートを宣言する実装は、そのようなトラフィックのサポートのために規定されている追加要件に従わなければならない(MUST)。ICV の計算に使用される鍵が手動で配布される場合、アンチリプレイサービスの正しい提供は鍵が置き換えられるまで送信側のカウンタ状態の(ローカルのリブートなどをまたいでの)正しい維持を必要とする上に、カウンタオーバーフローが差し迫っている場合の自動的な復旧対策もないだろう。したがって適合実装は、手動で鍵化された SA と同時にはアンチリプレイサービスを提供しないべきである(SHOULD NOT)。
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 に必須の追加のアルゴリズムがサポートされてもよい(MAY)。
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" 完全性アルゴリズムの交渉もサポートしなければならない(MUST)。上記の状況下では完全性と暗号化のどちらか一方は "NULL" であってもよいが、両方が "NULL" であってはならない(MUST NOT)ことに注意してほしい。
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 と異なる。
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 v3 においてサポートされている機能である結合モードの暗号アルゴリズムが採用されている場合、結果として生じるパケットのフォーマットは ESP v2 仕様とは異なる可能性がある。しかしながらそれらは 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 の場合は IKE v1 Domain of Interpretation (DOI) への ESN 補遺によって対処されている。
In the new ESP (v3), we make two provisions to better support traffic flow confidentiality (TFC): 新しい ESP (v3) において、私たちはトラフィックフロー信頼性(TFC)のより優れたサポートのために、以下の 2 つを用意した：
The first feature is one that should not cause problems for a receiver, since the IP total length field indicates where the IP packet ends. Thus, any TFC padding bytes after the end of the packet should be removed at some point during IP packet processing, after ESP processing, even if the IPsec software does not remove such padding. Thus, this is an ESP v3 feature that a sender can employ irrespective of whether a receiver implements ESP v2 or ESP v3. ひとつ目の機能は、IP トータル長フィールドが IP パケットの終了位置を示すため、受信側に問題を起こさないはずだということである。つまりパケットの終端より後の任意の 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 v2 を実装しているか ESP v3 を実装しているかに関係なく、ESP v3 の送信者が利用できる最適化である。
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPSEC and MSEC working groups who have contributed to the development of this protocol specification. 最初の IPsec 活動において重要な役割を果たし、最初の IPsec 標準一式(RFC 1825-1827)を著した Run Atkinson の貢献に感謝したい。Karen Seo は、本仕様の本バージョンおよび以前のバージョンの編集における援助に付いて、特別な感謝に値する。また著者は、本プロトコル仕様の開発に貢献してくれた IPSEC および MSEC ワーキンググループのメンバーにも感謝したい。
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. この付録は拡張シーケンス番号(ESN)の仕組みを説明する。拡張シーケンス番号は 64 ビットのシーケンス番号を採用する IPsc (ESP および AH)と共に使用されるが、各パケットの一部としてその下位 32 ビットのみが送信される。この付録には、リプレイパケットの検出に使用されるウィンドウの仕組みと、リプレイ拒否と ICV 計算とに使用されるシーケンス番号の上位ビットの判断とを網羅する。また、(送信されない)上位ビットに対して同期を喪失した場合の扱いに付いても議論する。
The receiver will maintain an anti-replay window of size W. This window will limit how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (No requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. However, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) All 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace. The following table lists pertinent variables and their definitions. 受信側はサイズ W のアンチリプレイウィンドウを保持する。このウィンドウはすでに認証済みの最大のシーケンス番号を持つパケットに対して、パケットがどれほど外れられるかを制限する。(32 ビットのシーケンス番号ウィンドウ向けにすでに確立されている 32 および 64 パケットを超えるような、このウィンドウの最小または推奨されるサイズの要求事項はない。しかしながら実装者には、ESN オプションを利用する実装がサポートするインターフェイススピードに相応しい値を見積もることが推奨される。また、以下で説明されるアルゴリズムは、このウィンドウが 2^31 パケットを超える幅を持たないことを前提としている。) これ以降、上位 32 ビット(Seqh)のための任意の固定値に対応する 2^32 個のすべてのシーケンス番号を、シーケンス番号部分空間と呼ぶ。以下の表は関連する変数とその定義である。
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
変数 サイズ
名 (ビット) 意味
---- ------ ---------------------------
W 32 ウィンドウサイズ
T 64 これまでに認証済みの最大のシーケンス番号
ウィンドウの上限
Tl 32 T の下位 32 ビット
Th 32 T の上位 32 ビット
B 64 ウィンドウの下限
Bl 32 B の下位 32 ビット
Bh 32 B の上位 32 ビット
Seq 64 受信したパケットのシーケンス番号
Seql 32 Seq の下位 32 ビット
Seqh 32 Seq の上位 32 ビット
When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases: アンチリプレイのチェックを実行するとき、または入力パケットを認証するためにどの上位ビットを使用するかを判断するとき、二つのケースがある：
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
+ ケース A: Tl >= (W - 1). この場合、ウィンドウはひとつのシーケンス
番号部分空間内に収まる (図 1 参照)
+ ケース B: Tl < (W - 1). この場合、ウィンドウは二つのシーケンス
番号部分空間にまたがる (図 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). 以下の図において、最下行("----")は連続するシーケンス番号部分空間を表し、0 が各部分空間の先頭を表す。その上にある二つの短い線は適用される上位ビットを表す。"====" はウィンドウを表す。"****" は未来のシーケンス番号(つまり、現時点で認証済みの最大シーケンス番号を超えるシーケンス番号(ThTl))を表す。
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
図 1 -- ケース A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
図 2 -- ケース B
The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected. アンチリプレイウィンドウは、`W' がその長さを定義するビット列と考えることができる。W = T - B + 1 であり、値は 2^32 - 1 を超えられない。最下位ビットは B に対応し、最上位ビットは T に対応し、Bl から Tl までの各シーケンス番号が対応するビットで表される。ビットの値はそのシーケンス番号のパケットが受信済みかつ認証済みかどうかを表し、これによってリプレイを検出し、拒否することができる。
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated, T より大きい 64 ビットシーケンス番号(Seq)を持つパケットを受信し、その妥当性を確認したとき、
+ B is increased by (Seq - T)
+ (Seq - T) bits are dropped from the low end of the window
+ (Seq - T) bits are added to the high end of the window
+ The top bit is set to indicate that a packet with that sequence
number has been received and authenticated
+ The new bits between T and the top bit are set to indicate that
no packets with those sequence numbers have been received yet.
+ T is set to the new sequence number
+ B が (Seq - T) だけ増やされる
+ ウィンドウの下端から (Seq - T) ビットが捨てられる
+ ウィンドウの上端に (Seq - T) ビットが足される
+ そのシーケンス番号を持つパケットが受信・認証されたことを表すために、
最上位ビットがセットされる
+ T と最上位ビットとの間の新しいビットが、それらのシーケンス番号を持つ
パケットがまだ受信されていないことを表すためにセットされる。
+ T に新しいシーケンス番号がセットされる
In checking for replayed packets, リプレイパケットの確認において、
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' のみであるため、受信側は各パケットが含まれるシーケンス番号部分空間を推測および追跡しなければならない。以下の式は、"通常の(normal)" 状況下で Seqh を選択する方法を定義する。極度のパケット損失からの復旧方法に付いての議論は付録 B3 を参照してほしい。
+ 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
+ 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
+ ケース A(図 1) の場合：
Seql >= Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th
Seql < Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th + 1
+ ケース B(図 2) の場合：
Seql >= Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th - 1
Seql < Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th
The following pseudo-code illustrates the above algorithms for anti- replay and integrity checks. The values for `Seql', `Tl', `Th' and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32. 以下の擬似コードは、アンチリプレイと完全性チェックとのための前述のアルゴリズムを説明している。`Seql'、`Tl'、`Th'、`W' の値は 32 ビット符号なし整数である。計算能力は mod 2^32 である。
If (Tl >= W - 1) Case A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else
Seqh = Th + 1
If (pass integrity check)
Tl = Seql (shift bits)
Th = Th + 1
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else Case B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
If (Tl >= W - 1) ケース A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (リプレイチェックに合格)
If (完全性チェックに合格)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else パケットを拒否する
Else
If (完全性チェックに合格)
Tl = Seql (ビットシフトする)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else
Seqh = Th + 1
If (完全性チェックに合格)
Tl = Seql (ビットをシフトする)
Th = Th + 1
Seql に対応するビットをセットする
パケットを通す
Else パケットを通す
Else ケース B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (リプレイチェックに合格)
If (完全性チェックに合格)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else パケットを拒否する
Else
Seqh = Th
If (Seql <= Tl)
If (リプレイチェックに合格)
If (完全性チェックに合格)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else パケットを拒否する
Else
If (完全性チェックに合格)
Tl = Seql (ビットをシフトする)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
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 パケット以上の連続する検出されないパケットロスが発生した場合、送信側と受信側が上位ビットの同期を失う。つまり、付録 B2.2. の式が正しい値を生成することに失敗する。この問題が検出され解決されない限り、その SA 上の後続のパケットは認証に失敗し、破棄されることになる。ESN オプションをサポートするすべての IPsec (ESP または AH)実装は、以下の手続きを実装するべきである(SHOULD)。
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 の場合、2^32 個のパケットを失う前に送信元が ACK の受信に失敗し、送信を停止するだろう。また任意の双方向アプリケーションの場合、たとえそれが UDP 上で運用されていたとしても、このような大規模な障害は何らかのタイムアウトを生じると考えられる。しかしながら UDP 上で運用されている単方向アプリケーションは、このような規模の損失を自動的に検出するフィードバックを持たない可能性があり、復旧方法を作成する動機はそのような場合のためである。
The solution we've chosen was selected to: 私たちの解決策は、以下の目的のために選択された：
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 のために個別のトリガー値をサポートするという要件はないが、実装者がそうすることを選択してもよい。
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)に連続するより大きい値を使用して認証を再試行する "不正な(bad)" パケットを選択する。これらの値は各リトライごとに 1 だけ加算されることで生成される。再試行の回数は、それが "過去の(past)" パケットまたは偽装パケットであったときのために、制限されるべきである。この制限回数はローカルのパラメータである。(Seqh の値が AH(または ESP)の後に暗黙的に置かれるため、パケットのペイロードの終端までに渡って完全性アルゴリズムを実行し、その後 Seqh を変化させて別の ICV の候補を計算することで、この手続きを最適化できるだろう。) この手続きによるパケット認証の成功は、連続障害カウントをリセットし、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. この解決策は受信側でのサポートのみを必要とし、それによって下位互換性が保たれる。また、再同期の作業はバックグラウンドか追加プロセッサを利用して行われるであろうから、この解決策はトラフィック処理に影響を与えず、サービス不能攻撃がトラフィック処理からリソースを奪うことはできない。
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA Phone: +1 (617) 873-3988 EMail: kent@bbn.com
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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.
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.
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society. RFC 編集者の活動資金は、現在 Internet Society によって提供されている。