ネットワークワーキンググループ
Request for Comments: 2406
廃止: 1827
分類: スタンダードトラック
S. Kent
BBN Corp
R. Atkinson
@Home Network
1998年11月

IP 暗号ペイロード(ESP)
(IP Encapsulating Security Payload (ESP))

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。
このメモの配布に制限はない。
著作権
Copyright (C) The Internet Society (1998). All Rights Reserved.
目次 
1. はじめに

2. 暗号ペイロードのパケットフォーマット

2.1 セキュリティパラメータインデックス
2.2 シーケンス番号
2.3 ペイロードデータ
2.4 パディング(暗号化用)
2.5 パディング長
2.6 次ヘッダ
2.7 認証データ
3. 暗号プロトコル処理
3.1 ESP ヘッダの位置
3.2 アルゴリズム
3.2.1 暗号化アルゴリズム
3.2.2 認証アルゴリズム
3.3 出力パケット処理
3.3.1 セキュリティアソシエーションの検索
3.3.2 パケットの暗号化
3.3.3 シーケンス番号の生成
3.3.4 インテグリティチェック値の計算
3.3.5 分割
3.4 入力パケット処理
3.4.1 再構成
3.4.2 セキュリティアソシエーションの検索
3.4.3 シーケンス番号の検証
3.4.4 インテグリティチェック値の検証
3.4.5 パケットの復号化
4. 監査

5. 準拠に関する要求事項

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

7. RFC 1827 との相違点

謝辞

参考文献

否認事項

著者の連絡先

著作権表示全文

1. はじめに 
暗号ペイロード(ESP)ヘッダは、IPv4 と IPv6 におけるセキュリティサービスを融合して提供するように設計されている。
ESP は、単独、あるいは、IP 認証ヘッダ(AH)と組み合わせて、または、例えばトンネルモード(「インターネットプロトコルのためのセキュリティアーキテクチャ (Security Architecture for the Internet Protocol)」 [KA97a] を参照のこと。以降「セキュリティアーキテクチャ文書」と呼ぶ)の使用による入れ子状態で適用される。
セキュリティサービスは、通信するホスト間、通信するセキュリティゲートウェイ間、またはセキュリティゲートウェイとホストの間に提供される。
様々なネットワーク環境での ESP と AH の使用方法についての詳細は、セキュリティアーキテクチャ文書 [KA97a] を参照のこと。

ESP ヘッダは、IP ヘッダの後、上位層プロトコルヘッダの前(トランスポートモードの場合)あるいはカプセル化された IP ヘッダの前(トンネルモードの場合)に挿入される。
これらのモードの詳細については以下に説明する。

ESP は機密性、データ送信元認証、コネクションレスインテグリティ、リプレイ防御サービス(部分的なシーケンスインテグリティの形式)、そして限定されたトラフィックフロー機密性を提供するために使用される。
提供されるサービスは、セキュリティアソシエーションの確立時に選択されたオプションとその実装の配置に依存する。
機密性は、他のどのサービスとも独立して選択してもよい。
ただし、(ESP 自身、または別に AH を使用することによって提供される)インテグリティや認証を伴わないで機密性を使用した場合、そのトラフィックは機密性サービスを弱めることになるある形態の積極的攻撃を受けやすくなる可能性がある([Bel96] を参照のこと)。
データ送信元認証とコネクションレスインテグリティは連携しているサービスであり(以降、まとめて「認証」と呼ぶ)、(オプションの)機密性と組み合わせてオプションとして提供される。
リプレイ防御サービスは、データ送信元認証が選択される場合にのみ選択され、これは完全に受信側の判断で選択される。
(デフォルトでは、送信側でリプレイ防御に使用されるシーケンス番号をインクリメントすることが要求されるが、このサービスは受信側がシーケンス番号をチェックする場合のみ有効となる)。
トラフィックフロー機密性のためにはトンネルモードを選択する必要があり、これは、トラフィックを集約することによって実際の送信元と宛先を隠すことが可能な、セキュリティ ゲートウェイに実装するのが最も効果的である。
ここで、機密性と認証はいずれもオプションではあるが、少なくともこのうち 1 つは選択されなければならない (MUST) ことに注意すること。

この文書では、読者がセキュリティアーキテクチャ文書で説明されている用語と概念に精通していることを前提としている。
特に読者は、AH および ESP が提供するセキュリティサービスの定義、セキュリティアソシエーションの概念、認証ヘッダ(AH)と組み合わせた ESP の使用方法、AH および ESP で利用できるそれぞれの鍵管理オプションに精通している必要がある。
(最後の項目に関しては、現在、AH と ESP の両方に要求される鍵管理オプションとして、マニュアル鍵管理と IKE による自動鍵管理が存在する [HC98])。

しなければならない (MUST)、してはならない (MUST NOT)、要求される (REQUIRED)、することになる (SHALL)、することはない (SHALL NOT)、する必要がある (SHOULD)、しないほうがよい (SHOULD NOT)、推奨される (RECOMMENDED)、してもよい (MAY)、選択できる (OPTIONAL) のキーワードが使用された場合は、RFC 2119 [Bra97] における定義に沿って解釈されるものとする。

2. 暗号ペイロードのパケットフォーマット 
ESP ヘッダの直前にくるプロトコルヘッダ(IPv4、IPv6、または拡張ヘッダ)のプロトコルフィールド(IPv4)または次ヘッダフィールド(IPv6、拡張ヘッダ)には、値 50 が含まれる [STD-2]。
 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)                 | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    Payload Data* (variable)                   | |   ^
~                                                               ~ |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     Padding (0-255 bytes)                     | |erage*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  Pad Length   | Next Header   | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|                 Authentication Data (variable)                |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * 暗号同期データ(例えば初期ベクトル(IV、2.3 章を参照のこと))
     がペイロードフィールドに含まれる場合、それはしばしば暗号文の一部
     としてみなされることがあるが、通常、実際には暗号化されない。
以下の章では、ヘッダフォーマットのフィールドについて定義する。
「選択できる (optional)」は、そのオプションが選択されない場合には、そのフィールドが省略されることを意味する。
すなわち、送信されるパケットにもインテグリティチェック値(ICV、2.7 章を参照のこと)の計算の際のパケットフォーマットにもそのフィールドは存在しない。
オプションは、セキュリティアソシエーション(SA)の確立の際に決定される。
従って、与えられた SA における ESP パケットのフォーマットは、SA の有効期間中は変化しない。
これとは対照的に、「必須」のフィールドは、すべての SA において、ESP パケットフォーマット中に常に存在する。
2.1 セキュリティパラメータインデックス(SPI) 
SPI は、宛先 IP アドレスとセキュリティプロトコル(ESP)と組み合わせることにより、そのデータグラムに対するセキュリティアソシエーションを一意に識別する、任意の 32 ビットの値である。
1 から 255 までの SPI 値は、Internet Assigned Numbers Authority (IANA) によって将来の利用のために予約されている。
割り当てられる SPI 値の使用が RFC で指定されない限り、通常、予約された SPI 値は IANA から割り当てられない。
SPI は、SA の確立時に宛先システムによって選択されるのが一般的である(詳細についてはセキュリティアーキテクチャ文書を参照のこと)。
SPI フィールドは必須である。

ゼロ(0)の SPI 値は、ローカルな、実装固有の利用のために予約されており、これを送信してはならない (MUST NOT)
例えば、IPsec の実装の鍵管理エンティティが新しい SA を確立することを IPsec 実装が要求したが、SA がまだ確立されていない間に、「セキュリティアソシエーションが存在しない」ことを意味するような場合に、このゼロの SPI 値を鍵管理実装が使用してもよい (MAY)

2.2 シーケンス番号 
この符号なし 32 ビットのフィールドには、単純に増加するカウンタ値(シーケンス番号)が含まれる。
これは必須であり、受信側がある特定の SA でリプレイ防御サービスの利用を選択しない場合でも常に存在する。
シーケンス番号フィールドの処理は受信側に任せられる。
すなわち、送信側は常にこのフィールドを送信しなければならないが (MUST)、受信側がそれを処理する必要はない(後の「入力パケット処理」の章の「シーケンス番号の検証」の議論を参照のこと)。

送信側のカウンタと受信側のカウンタは、SA の確立時に 0 に初期化される(ある SA を使用して送信される最初のパケットは、シーケンス番号 1 を持つ。シーケンス番号の生成方法についての詳細は 3.3.3 章を参照のこと)。
リプレイ防御が有効である場合(デフォルト)、送信されたシーケンス番号は絶対に一巡してはならない。
従って、送信側のカウンタと受信側のカウンタは、ある SA 上で 2^32 番目のパケットを送信する前に(新しい SA と、それにともなって新しい鍵を確立することによって)リセットされなければならない (MUST)

2.3 ペイロードデータ 
ペイロードデータフィールドは、次ヘッダフィールドで定義されるデータを含む可変長フィールドである。
このペイロードデータフィールドは必須であり、その長さは整数バイト数である。
ペイロードの暗号化に使用されるアルゴリズムが、暗号同期データ(例えば初期ベクトル(IV))を必要とする場合、このデータはペイロードフィールド内で明示的に運ばれてもよい (MAY)
このような明示的なパケット単位の同期データを必要とする暗号化アルゴリズムはすべて、このようなデータの長さと構造、およびデータの位置を、そのアルゴリズムの ESP での使用方法を指定する RFC の一部で示さなければならない (MUST)
このような同期データが暗黙的である場合には、そのデータを導出するアルゴリズムが RFC の一部で示されなければならない (MUST)

ここで、IV が存在する場合に(実際の)暗号文の整列状態を保証するために以下のことに注意すること。

2.4 パディング(暗号化用) 
パディングフィールドを使用する必要性、動機となる要因がいくつか存在する。
送信側は 0 から 255 バイトのパディングを追加して良い (MAY)
ESP パケットにパディングフィールドを含むことはオプションであるが、すべての実装ではパディングの生成と使用をサポートしなければならない (MUST)
  1. 暗号化されるビットがアルゴリズムのブロックサイズの整数倍であること(上記の 1 つ目のポイント)を保証するために、パディングの計算は、IV を除くペイロード データフィールド、パディング長フィールド、および次ヘッダフィールドに適用される。
  2. 認証データが 4 バイトの境界で整列すること(上記の 2 つめのポイント)を保証するために、パディングの計算は、IV を含むペイロードデータフィールド、パディング長フィールド、および次ヘッダフィールドに適用される。
パディングバイトが必要とされるが、そのパディングの中身を暗号化アルゴリズムが指定しない場合は、デフォルトで次の処理をしなければならない (MUST)
パディングバイトは(符号なし、1 バイトの)連続した整数値に初期化される。
平文に追加される最初のパディングバイトには 1 と番号付けされ、それに続くパディングバイトでは単純に 1、2、3 ... と増加していく。
このパディング規則が使用される場合、受信側はパディングフィールドを検査する必要がある (SHOULD)
(この規則が選ばれた理由は、比較的単純であること、ハードウェアでの実装が容易なこと、さらには、受信側で復号時にパディングがチェックされる場合、別にインテグリティへの対応がない場合に、ある形態の「カットアンドペースト」攻撃に対する限定された保護が提供されるためである)。

上で示したデフォルト以外の方法によるパディングを必要とする暗号化アルゴリズムでは、パディングの中身(例えば、ゼロ、乱数データ)と、受信側で必要とされるパディングバイトの処理について、そのアルゴリズムの ESP での使用方法を指定する RFC において定義しなければならない (MUST)
このような状況では、パディングフィールドの中身は、暗号化アルゴリズムと選択されたモードによって決定され、対応するアルゴリズムの RFC において定義される。
関連するアルゴリズムの RFC では、受信側がパディングフィールドを検査しなければならないこと (MUST) 、または受信側によるパディング フィールドの処理方法を送信側に通知しなければならないこと (MUST) を指定してもよい (MAY)

2.5 パディング長 
パディング長フィールドは、その直前のパディングバイトのバイト数を示す。
有効な値の範囲は 0 から 255 であり、値 0 はパディングバイトが存在しないことを示す。
パディング長フィールドは必須である。
2.6 次ヘッダ 
次ヘッダは、ペイロードデータフィールドに含まれるデータタイプ(例えば IPv6 の拡張ヘッダまたは上位層プロトコル識別子)を識別する 8 ビットのフィールドである。
このフィールドの値は、Internet Assigned Numbers Authority (IANA) から出されている RFC  「Assigned Numbers」 [STD-2] の最新版において定義される IP プロトコル番号のセットから選ばれる。
次ヘッダフィールドは必須である。
2.7 認証データ 
認証データは、ESP パケットから認証データを抜いたものから計算されたインテグリティチェック値(ICV)を含む可変長フィールドである。
このフィールドの長さは、選択される認証関数によって指定される。
認証データフィールドはオプションであり、認証サービスが当該 SA に対して選択された場合のみ、このフィールドが含まれる。
認証アルゴリズムは、ICV の長さと、検証時の比較ルールおよび処理ステップについて指定しなければならない (MUST)
3. 暗号プロトコル処理 
3.1 ESP ヘッダの位置 
AH と同じように、ESP は 2 つのモード、つまりトランスポートモードまたはトンネルモードで使用される。
前者のモードは、ホストでの実装にのみ適用可能であり、上位層プロトコルの保護を提供するが、IP ヘッダの保護は提供しない。
(このモードでは、セキュリティアーキテクチャ文書で定義される「bump-in-the-stack」または「bump-in-the-wire」実装の場合、入力および出力 IP 断片は、この仕様に準拠し、かつトランスペアレントな IPsec のサポートを提供するために、追加の IP 再構成/分割の処理を IPsec 実装に要求する場合がある。複数インタフェースを使用する場合、実装内でこのような処理を実行するために特別な配慮が要求される)。

トランスポートモードでは、ESP は IP ヘッダの後、かつ上位層プロトコル(例えば TCP、UDP、ICMP など)の前、または既に挿入されている他の IPsec ヘッダの前に挿入される。
IPv4 では、ESP を IP ヘッダ(および IP ヘッダが含むすべてのオプション)の後、上位層プロトコルの前に配置することが要求される。
(ここで、「トランスポート」モードという用語が、TCP および UDP の使用に限定されるという意味にとられるべきではないことに注意すること。例えば、ICMP メッセージは、「トランスポート」モードまたは「トンネル」モードのどちらを使用して送信しても良い (MAY))。
以下の図で、一般的な IPv4 パケットにおける ESP トランスポートモードの位置の「前後」関係を示す。
(「ESP トレーラ」にはすべてのパディングに加え、パディング長フィールド、次ヘッダフィールドが含まれる)。

                 ESP 適用前
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

                 ESP 適用後
            -------------------------------------------------
      IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
            |(any options)| Hdr | TCP | Data | Trailer |Auth|
            -------------------------------------------------
                                |<----- encrypted ---->|
                          |<------ authenticated ----->|
IPv6 では、ESP は終点間ペイロードと見なされるため、中継点 (hop-by-hop)、経路制御 (routing)、および断片 (fragmentation) 拡張ヘッダの後にあらわれる必要がある。
終点オプション (destination options) 拡張ヘッダは、希望する意味に応じて、ESP ヘッダの前または後に配置することができる。
ただし、ESP は ESP ヘッダの後のフィールドのみを保護するため、ESP ヘッダの後に終点オプションヘッダを配置するのが望ましい。
以下の図で、一般的な IPv6 パケットにおける ESP トランスポートモードの位置を示す。
                     ESP 適用前
            ---------------------------------------
      IPv6  |             | ext hdrs |     |      |
            | orig IP hdr |if present| TCP | Data |
            ---------------------------------------

                     ESP 適用後
            ---------------------------------------------------------
      IPv6  | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
            |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
            ---------------------------------------------------------
                                         |<---- encrypted ---->|
                                     |<---- authenticated ---->|

            * = 存在する場合、AH の前、AH の後、あるいはその両方に存在し得る
ESP および AH ヘッダは様々なモードで組み合わせることが可能である。
IPsec アーキテクチャ文書では、サポートしなければならないセキュリティアソシエーションの組み合わせが定義されている。
トンネルモード ESP は、ホストまたはセキュリティゲートウェイのどちらで使用しても良い。
(配送する加入者トラフィックを保護するために) ESP をセキュリティゲートウェイに実装する場合には、トンネルモードが使用されなければならない。
トンネルモードでは、「内側」 IP ヘッダには最終点である送信元アドレスと宛先アドレスが含まれ、「外側」 IP ヘッダにはそれとは別の IP アドレス(例えばセキュリティゲートウェイのアドレス)が含まれることがある。
トンネルモードでは、ESP は内側 IP ヘッダ全体を含む内側 IP パケット全体を保護する。
外側 IP ヘッダに関して言えば、トンネルモードにおける ESP の位置は、トランスポートモードにおける ESP のものと同様である。
以下の図で、一般的な IPv4 および IPv6 パケットにおける ESP トンネルモードの位置を示す。
            -----------------------------------------------------------
      IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
            |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
            -----------------------------------------------------------
                                |<--------- encrypted ---------->|
                          |<----------- authenticated ---------->|

            ------------------------------------------------------------
      IPv6  | new* |new ext |   | orig*|orig ext |   |    | ESP   | ESP|
            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer|Auth|
            ------------------------------------------------------------
                                |<--------- encrypted ----------->|
                            |<---------- authenticated ---------->|

            * = 存在する場合。外側 IP ヘッダ/拡張ヘッダの構成と
                内側 IP ヘッダ/拡張ヘッダの修正については後で説明する。
3.2 アルゴリズム 
実装に必須のアルゴリズムは、5 章の「準拠に関する要求事項」にて説明されている。
また、この他のアルゴリズムをサポートしてもよい (MAY)
ここで、機密性と認証はいずれもオプションであるが、少なくともこのうち 1 つのサービスを選択しなければならない (MUST)、つまり、両方同時に NULL となってはならない (MUST NOT) ことに注意すること。
3.2.1 暗号化アルゴリズム 
使用する暗号化アルゴリズムは SA によって指定される。
ESP は対称鍵暗号化アルゴリズムと共に使用するように設計されている。
IP パケットは異なる順番で到着することがあるため、それぞれのパケットで、受信側が復号化の際の暗号同期を行うために必要なデータを運ばなければならない。
このデータは、ペイロードフィールド内で明示的に、例えば(以前に説明した) IV として運ばれるか、またはパケットヘッダから導出される。
ESP が平文のパディングの準備を行うため、ESP で使用される暗号化アルゴリズムは、ブロックモードまたはストリームモード特性のどちらかを示す。
ここで、暗号化(機密性)はオプションであることから、このアルゴリズムは「NULL」となる可能性があることに注意すること。
3.2.2 認証アルゴリズム 
ICV の計算に使用する認証アルゴリズムは SA によって指定される。
2 点間での通信の場合に適切な認証アルゴリズムとして、対称鍵暗号化アルゴリズム(例えば DES)をもとにした鍵付きメッセージ認証コード(MAC)や一方向性ハッシュ関数(例えば MD5、SHA-1)があげられる。
マルチキャスト通信の場合には、非対称署名アルゴリズムと組み合わせた一方向性ハッシュアルゴリズムが適切であるが、その性能と空間を考慮すると、現在このようなアルゴリズムの使用は除外される。
ここで、認証はオプションであることから、このアルゴリズムは「NULL」となる可能性があることに注意すること。
3.3 出力パケット処理 
トランスポートモードでは、送信側は上位層プロトコル情報を ESP ヘッダ/トレーラにカプセル化し、指定された IP ヘッダ(および IPv6 におけるすべての IP 拡張ヘッダ)をそのまま保持する。
トンネルモードでは、外側と内側の IP ヘッダ/拡張ヘッダを様々な方法で相互に関連付けることが可能である。
カプセル化処理の際の外側 IP ヘッダ/拡張ヘッダの構造は、セキュリティアーキテクチャ文書にて説明されている。
セキュリティポリシーによって複数のヘッダ/拡張ヘッダが要求される場合、セキュリティヘッダの適用順序はセキュリティポリシーで定義されなければならない (MUST)
3.3.1 セキュリティアソシエーションの検索 
ESP は、ESP 処理を要求する SA とそのパケットが関連していることを IPsec の実装が判断した後でのみ、出力パケットに適用される。
どの IPsec 処理が出力トラフィックに適用されるかを判断する過程については、セキュリティアーキテクチャ文書において説明されている。
3.3.2 パケットの暗号化 
この章では、フォーマッティングのために常に適用される暗号化についてとりあげる。
「機密性なし」の状態は、NULL 暗号化アルゴリズムを使用することによって提供されることを理解して頂きたい。
従って、送信側は以下の処理を行う。
  1. (ESP ペイロードフィールドへの)カプセル化
    • トランスポートモード -- オリジナルの上位層プロトコル情報をカプセル化する。
    • トンネルモード -- オリジナルの IP データグラム全体をカプセル化する。
  2. 必要なパディングをすべて追加する。
  3. 鍵、暗号化アルゴリズム、SA が示すアルゴリズムモードおよび暗号同期データ(もしあれば)を使用して結果(ペイロードデータ、パディング、パディング長、次ヘッダの各フィールド)を暗号化する。
    • 明示的な暗号同期データ(例えば IV)が示された場合、それがアルゴリズムの仕様に従って暗号化アルゴリズムへ入力され、ペイロードフィールドに置かれる。
    • 暗黙的な暗号同期データ(例えば IV)が示された場合、それがアルゴリズムの仕様に従って構成され、暗号化アルゴリズムへ入力される。
外側 IP ヘッダを構成するための正確な過程は、モード(トランスポートモードまたはトンネルモード)に依存し、これはセキュリティアーキテクチャ文書にて定義されている。

認証が選択された場合は、暗号化が認証の前に最初に実行され、暗号化には認証データフィールドは含まれない。
この順序で処理することによって、受信側でリプレイパケットや偽パケットを迅速に発見して拒否することができ、サービス妨害攻撃の影響を潜在的に減らすことができる。
さらにこれにより、受信側でパケットを並列処理することができる。
すなわち、復号化と認証を並行して行うことができる。
ここで、認証データは暗号化によって保護されないため、ICV の計算に鍵付き認証アルゴリズムを使用しなければならないことに注意すること。

3.3.3 シーケンス番号の生成 
送信側のカウンタは、SA の確立時に 0 に初期化される。
送信側は、この SA 用のシーケンス番号をインクリメントして、その新しい値をシーケンス番号フィールドに挿入する。
従って、与えられた SA を使用して送信される最初のパケットはシーケンス番号として 1 を持つことになる。

リプレイ防御が有効である場合(デフォルト)、送信側では、新しい値をシーケンス番号フィールドに挿入する前に、カウンタが一巡していないことをチェックする。
つまり、送信側はシーケンス番号が一巡した場合はパケットを SA に送信してはならない (MUST NOT)
シーケンス番号のオーバーフローを引き起こすようなパケットを送信しようとする試みは、監査対象イベントとなる。
(ここで、シーケンス番号管理に関するこのアプローチは、モジュロ演算の使用を必要としないことに注意すること)。

受信側による通知がない限り、送信側はデフォルトでリプレイ防御が有効であると仮定する(3.4.3 章を参照のこと)。
従って、カウンタが一巡した場合、送信側は新しい SA と鍵をセットアップすることになる(SA がマニュアル鍵管理で設定されていない限り)。

リプレイ防御が無効の場合(例えばマニュアル鍵管理(5 章を参照のこと)の場合)には、送信側はカウンタの監視やリセットを行う必要がない。
ただし、送信側はカウンタをこれまでどおりインクリメントし、カウンタが最大値に到達した場合はゼロに戻す。

3.3.4 インテグリティチェック値の計算 
SA に対して認証が選択された場合には、送信側は ESP パケットから認証データを抜いたものに対して ICV を計算する。
従って、SPI、シーケンス番号、ペイロードデータ、パディング(存在すれば)、パディング長、次ヘッダの各フィールドがすべて ICV 計算に取り込まれる。
ここで、暗号化が認証の前に行われるため、最後の 4 つのフィールドは暗号文の形式となることに注意すること。

一部の認証アルゴリズムでは、ICV の計算の対象となるバイトストリングがアルゴリズムによって指定されるブロックサイズの整数倍でなければならない。
このバイトストリングの長さがアルゴリズムのブロックサイズの要求条件と一致しない場合は、ICV の計算の前に、暗黙的パディングが ESP パケットの最後(次ヘッダフィールドの後)に追加されなければならない (MUST)
パディングオクテットの値は 0 でなければならない (MUST)
ブロックサイズ(とパディング長)はアルゴリズムの仕様によって指定される。
ここで、MD5 と SHA-1 はその内部パディング規則のために、1 バイトのブロックサイズを持つとみなされることに注意すること。

3.3.5 分割 
必要であれば、IPsec実装内で ESP 処理の後に IP 分割が行われる。
従って、トランスポートモード ESP は、(IP の断片に対してではなく) IP データグラム全体に対してのみ適用される。
ESP が適用された IP パケット自身は、配送経路上のルータによって分割される可能性があり、これにより生じた断片は受信側で ESP 処理の前に再構成されなければならない。
トンネルモードでは、ESP はそのペイロードが分割された IP パケットの可能性のある IP パケットに適用される。
例えば、セキュリティゲートウェイ、または「bump-in-the-stack」および「bump-in-the-wire」 IPsec 実装では、トンネルモード ESP をこのような断片に対して適用する場合がある(詳細については、セキュリティアーキテクチャ文書を参照のこと)。
注釈:トランスポートモードの場合 -- 3.1 章のはじめに説明されているように、bump-in-the-stack および bump-in-the‐wire 実装では、ローカルの IP 層で分割されたパケットを最初に再構成してから IPsec を適用し、その結果生じるパケットを分割しなければならないことがある。
注釈: IPv6 の場合 -- bump-in-the-stack および bump-in-the‐wire 実装では、断片ヘッダが存在し、そしてその結果、パケットを IPsec 処理の前に再構成する必要があるかどうかを判断するために、すべての拡張ヘッダを読み通す必要があるだろう。
3.4 入力パケット処理 
3.4.1 再構成 
必要であれば、ESP 処理の前に再構成が行われる。
処理を行うために ESP に渡されるパケットが IP の断片である場合、つまり、オフセットフィールドがゼロでないか、断片継続 (MORE FRAGMENTS) フラグがセットされている場合、受信側はそのパケットを破棄しなければならず (MUST)、これは監査対象イベントとなる。
このイベントに対する監査ログエントリには、SPI 値、日付/時間、送信元アドレス、宛先アドレス、シーケンス番号、(IPv6 では)フロー ID が含まれる必要がある (SHOULD)
注釈:パケット再構成に関して言えば、現在の IPv4 の仕様では、オフセットフィールドをゼロにしたり、断片継続 (MORE FRAGMENTS) フラグをクリアすることは要求されていない。
再構成されるパケットを(明らかな断片として破棄するのとは対照的に) IPsec 処理させるために、IP のコードはパケットの再構成後に、これら 2 つの処理を行わなければならない。
3.4.2 セキュリティアソシエーションの検索 
ESP ヘッダを含む(再構成された)パケットを受信した際に、受信側は、宛先 IP アドレス、セキュリティプロトコル(ESP)、および SPI をもとに適切な(一方向) SA を決定する。(この過程は、セキュリティアーキテクチャ文書にてより詳細に説明されている)。
SA は、シーケンス番号フィールドをチェックするかどうか、認証データフィールドが存在するかどうかを示し、復号化と ICV の計算(適用可能であれば)に使用するアルゴリズムと鍵を指定する。

このセッションに対する有効なセキュリティアソシエーションが存在しない場合(例えば受信側が鍵を持っていない場合)、受信側はそのパケットを破棄しなければならず (MUST)、これは監査対象イベントとなる。
このイベントに対する監査ログエントリには、SPI 値、日付/時間、送信元アドレス、宛先アドレス、シーケンス番号、(IPv6 では)フロー ID が含まれる必要がある (SHOULD)

3.4.3 シーケンス番号の検証 
リプレイ防御サービスの利用は SA 毎に受信側によって無効とされる場合があるが、すべての ESP 実装はこのサービスをサポートしなければならない (MUST)
しかし、シーケンス番号フィールドのインテグリティは保護されないため、認証サービスがその SA に対して有効でない限り、このサービスを有効としてはならない (MUST NOT)
(ここで、トラフィックを 1 つの SA に送信する複数の送信側の間で、(宛先アドレスがユニキャスト、ブロードキャスト、あるいはマルチキャストであるかどうかに関係なく)送信されるシーケンス番号の値を管理するための規定がないことに注意すること)。
従って、リプレイ防御サービスは、1 つの SA を使用する送信者が複数存在する環境では使用しないほうがよい (SHOULD NOT)

受信側がある SA に対してリプレイ防御を無効にした場合は、シーケンス番号の入力チェックは行われない。
しかし、送信側から見た場合、デフォルトで受信側ではリプレイ防御が有効になっていると仮定される。
送信側に不必要なシーケンス番号の監視や SA のセットアップを行わせることを避けるために(3.3.3 章を参照のこと)、IKE のような SA 確立プロトコルが使用される場合は、受信側がリプレイ防御保護を提供しないのであれば、それを SA 確立中に受信側から送信側に通知する必要がある (SHOULD)

受信側がこの SA に対してリプレイ防御を有効にした場合、その SA に対する受信側のパケットカウンタは SA の確立時にゼロに初期化されなければならない (MUST)
受信されたそれぞれのパケットについて、受信側は、パケットに含まれるシーケンス番号が、この SA の有効期間中に受信された他のどのパケットのシーケンス番号とも重複しないことを確認しなければならない (MUST)
重複パケットを迅速に拒否するために、パケットが SA とマッチされた後の ESP 処理の最初にこのチェックを行う必要がある。

重複はスライディング受信ウィンドウを使用することによって防がれる。
(このウィンドウの実装方法はローカルの問題であるが、実装が持たなければならない機能を次に示す)。
最小ウィンドウサイズは 32 をサポートしなければならない (MUST)
しかし、ウィンドウサイズ 64 が望ましく、これをデフォルトとして使用する必要がある (SHOULD)
その他のウィンドウサイズ(最小よりも大きいサイズ)を受信側で選択してもよい (MAY)
(受信側は送信側にウィンドウサイズを通知しない)。

ウィンドウの「右」端は、この SA で受信した中で最も大きい有効シーケンス番号値を表す。
ウィンドウの「左」端より小さいシーケンス番号を含むパケットは拒否される。
ウィンドウ内に収まるパケットは、ウィンドウ内で受信したパケットのリストに対してチェックされる。
ビットマスクの利用をもとにしたこのチェックの効率的な実施法については、セキュリティアーキテクチャ文書にて説明されている。

受信されたパケットがウィンドウに収まり、かつ新しい場合、あるいは受信されたパケットがウィンドウの右側にある場合、受信側は ICV の検証に進む。
ICV の検証に失敗した場合、受信側は IP データグラムを無効として破棄しなければならず (MUST)、これは監査対象イベントとなる。
このイベントの監査ログエントリには、SPI 値、日付/時間、送信元アドレス、宛先アドレス、シーケンス番号、(IPv6 では)フロー ID が含まれる必要がある (SHOULD)
受信ウィンドウは、ICV の検証に成功した場合のみ更新される。

議論:

ここで、パケットがウィンドウ内に収まり、かつ新しい場合、あるいはウィンドウの「右」外側にある場合、受信側はシーケンス番号のウィンドウデータを更新する前にパケットを認証しなければならない (MUST) ことに注意すること。
3.4.4 インテグリティチェック値の検証 
認証が選択された場合、受信側は、指定された認証アルゴリズムを使用して、ESP パケットから認証データを抜いたものから ICV を計算するとともに、それがそのパケットの認証データフィールドに含まれている ICV と同一であることを確認する。
その計算に関しての詳細を次に示す。

計算された ICV と受信された ICV が一致した場合、そのデータグラムは有効となり受領される。
このテストに失敗した場合は、受信側は IP データグラムを無効として破棄しなければならず (MUST)、これは監査対象イベントとなる。
このイベントの監査ログエントリには、SPI 値、日付/時間、送信元アドレス、宛先アドレス、シーケンス番号、(IPv6 では)平文のフロー ID が含まれる必要がある (SHOULD)

議論:

まず ICV 値(認証データフィールド)の削除と保存を行う。
次に、ESP から認証データを抜いた分の全体の長さをチェックする。
認証アルゴリズムのブロックサイズに基づく暗黙的パディングが必要であれば、次ヘッダフィールドの直後の ESP パケットの最後にゼロで満たされたバイトを追加する。
ICV の計算を実行し、アルゴリズムの仕様で定義された比較ルールにより、その結果と保存されている値を比較する。
(例えば、電子署名と一方向性ハッシュが ICV の計算に使用される場合、マッチング処理はより複雑になる)。
3.4.5 パケットの復号化 
3.3.2 章の「パケットの暗号化」と同様に、この章では、フォーマッティングのために常に適用される暗号化についてとりあげる。
「機密性なし」の状態は、NULL 暗号化アルゴリズムを使用することによって提供されることを理解して頂きたい。
従って、受信側は以下の処理を行う。
  1. SA が示す鍵、暗号化アルゴリズム、アルゴリズムモード、暗号同期データ(もしあれば)を使用して、ESP ペイロードデータ、パディング、パディング長、次ヘッダの各フィールドを復号化する
    • 明示的な暗号同期データ(例えば IV)が示された場合、それがペイロードフィールドから取られ、アルゴリズムの仕様に従って復号化アルゴリズムに入力される。
    • 暗黙的な暗号同期データ(例えば IV)が示された場合、IV のローカルバージョンが構成され、アルゴリズムの仕様に従って復号化アルゴリズムに入力される。
  2. 暗号化アルゴリズムの仕様に指定されているように、すべてのパディングを処理する。
    デフォルトのパディング規則(2.4 章を参照のこと)が使用されている場合には、受信側は、復号化されたデータを次の層に渡す前に、パディングの削除の前にパディングフィールドを検査する必要がある (SHOULD)
  3. 以下のものからオリジナル IP データグラムを再構成する。
    • トランスポートモードの場合 -- オリジナル IP ヘッダに ESP ペイロードフィールド内のオリジナル上位層プロトコル情報を足したもの。
    • トンネルモードの場合 --  トンネル IP ヘッダに ESP ペイロードフィールド内の IP データグラム全体を足したもの。
オリジナルのデータグラムを再構成するための正確な過程は、モード(トランスポートモードまたはトンネルモード)に依存し、これはセキュリティアーキテクチャ文書にて定義されている。
最低でも IPv6 では、受信側は、次ヘッダフィールドで識別されるプロトコルの処理を迅速に行うために、復号化されたデータが 8 バイトで整列されていることを保証する必要がある (SHOULD)

認証が選択された場合は、検証と復号化を連続して、または並行して行ってもよい (MAY)
連続して行う場合は、ICV の検証を最初に行う必要がある (SHOULD)
並行して行う場合には、復号化されたパケットが次の処理に渡される前に、検証を完了しなければならない (MUST)
この順序で処理することによって、受信側で、パケットの復号化の前にリプレイパケットや偽パケットを迅速に発見して拒否することができ、サービス妨害攻撃の影響を潜在的に減らすことができる。

注釈:
受信側で、復号化と認証を並行して行う場合は、パケットアクセスと復号化されたパケットの再構成の競合の可能性を避けるようにしなければならない。

ここで、復号化に「失敗する」可能性がある場合がいくつかあることに注意すること。

  1. 選択された SA が正しくない --  SPI、宛先アドレス、IPsec プロトコル番号の各フィールドのどれかが改竄されている場合に、SA が誤って選択されることがある。
    そのパケットが存在する他の SA にマップされる場合、このようなエラーを損壊パケット(ケース c)と区別することは不可能となるだろう。
    SPI の改竄は、認証を使用することによって発見することができる。
    しかし、SA のミスマッチは、IP 宛先アドレスまたは IPsec プロトコル番号フィールドの改竄によって、引き続き発生することがあるだろう。
  2. パディング長またはパディング値に誤りがある -- 不正なパディング長およびパディング値は、認証の使用に関係なく発見することができる。
  3. 暗号化された ESP パケットが損壊 -- これは、その SA で認証が選択されていれば発見することができる。
ケース (a) または (c) では、誤った復号化処理の結果(無効な IP データグラムまたはトランスポート層フレーム)は、必ずしも IPsec によって発見される必要はなく、この場合、後のプロトコル処理に任せられる。
4. 監査 
ESP を実装するすべてのシステムが監査機能を実装するわけではない。
しかし、監査をサポートするシステムに ESP が取り込まれる場合には、ESP 実装も監査をサポートしなければならず (MUST)、システム管理者が ESP の監査を有効または無効にすることができるようにしなければならない (MUST)
たいていの場合、監査のグラニュラリティはローカルの問題である。
ただし、いくつかの監査対象イベントがこの仕様に記述されており、これらのイベントに対して、監査ログに含む必要のある (SHOULD) 情報の最小セットが定義されている。
また、各イベントの監査ログには、これに追加して他の情報を含んでもよい (MAY)
さらに、これに追加してこの仕様で明示的に取り上げられていない他のイベントも監査ログエントリに含んでもよい (MAY)
このアクションを介してサービス妨害を引き起こされる可能性があるため、監査対象イベントの発見に応じて、受信側が送信者を偽っている者に対してすべてのメッセージを送信してしまうような要求条件は存在しない。
5. 準拠に関する要求事項 
この仕様に準拠する実装は、ここで記述されている ESP の構文と処理を実装するとともに (MUST)、セキュリティアーキテクチャ文書のすべての要求条件を満たさなければならない (MUST)
ICV の計算に使用される鍵がマニュアル配送される場合には、リプレイ防御サービスを正確に提供するために、鍵が置換されるまで送信側でカウンタ状態を正確にメンテナンスすることが要求される。
さらにこの場合、カウンタのオーバーフローが起こったとしても、自動的なリカバリは提供されない。
従って準拠する実装は、マニュアルで鍵管理される SA で、このサービスを提供しないほうがよい (SHOULD NOT)
準拠する ESP 実装は、実装に必須のアルゴリズムとして以下のものをサポートしなければならない (MUST)
ESP の暗号化と認証はオプションであることから、2 つの「NULL」アルゴリズムのサポートが、これらのサービスをネゴシエートする方法との一貫性を維持するために必要である。
ここで、認証と暗号化はそれぞれ「NULL」となり得るが、両方が「NULL」であってはならない (MUST NOT) ことに注意すること。
6. セキュリティに関する考慮事項 
セキュリティはこのプロトコルの設計の中心的な事項であり、セキュリティに関する考慮事項は仕様全体に含まれている。
また、IPsec プロトコルの利用に対してこれに追加されるセキュリティ関連事項が、セキュリティアーキテクチャ文書で取り上げられている。
7. RFC 1827 との相違点 
この文書は RFC 1827 [ATK95] とは幾つかの重要な点で異なっている。
主な相違点は、この文書が ESP の完全なフレームワークと周辺関係を指定しようとしているのに対し、RFC 1827 では、変換の定義を通して完成される「外観」を提供していることにある。
変換の組み合わせの増加が、ESP の仕様を ESP において提供されるセキュリティサービスのオプションを含んだより完全な文書として再編する動機となっている。
従って、以前に変換に関する文書において定義されていたフィールドは、今回は ESP の仕様の一部となっている。
例えば、認証(およびリプレイ防御)をサポートするために必要なフィールドは、このサービスの提供はオプションであるが、今回ここで定義されている。
暗号化および次プロトコルの識別のためのパディングをサポートするために使用されるフィールドも同様にここで定義されている。
これらのフィールドの定義と一致するパケット処理についても今回の文書に含まれている。
謝辞 
この仕様に含まれている概念の多くは、米国政府の SP3 セキュリティプロトコル、ISO/IEC の NLSP、提案された swIPe セキュリティプロトコルから導出されたもの、または影響を受けたものである [SDNS89, ISO92, IB93] 。

3 年以上に渡って、この文書は様々なバージョンと繰り返しを経て発展してきた。
この間、多くの人々が重要なアイディアと熱意を作業と文書の両方に注いでくれた。
レビュー、編集、背景調査、およびコーディネーション作業で多大な貢献をしてくれた Karen Seo に感謝する。
また、IPsec および IPng ワーキンググループのメンバー、特に(アルファベット順で)、Steve Bellovin、Steve Deering、Phil Karn、Perry Metzger、David Mihelcic、Hilarie Orman、Norman Shulman、William Simpson、そして Nina Yuan の各氏の努力に感謝する。

参考文献 
[ATK95] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993.

[ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.

[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[KA97b] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[MD97] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.

[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html

[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990.

否認事項 
この文書において示された見解と仕様は著者によるものであり、必ずしもその雇い主によるものではない。
著者とその雇い主は、正確/不正確な実装、およびこの設計の利用から生じるどのような問題への責任も拒否する。
著者の連絡先 
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA

Phone: +1 (617) 873-3988
EMail: kent@bbn.com

Randall Atkinson
@Home Network
425 Broadway,
Redwood City, CA 94063
USA

Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
 

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

著作権表示全文 
Copyright (C) The Internet Society (1998). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。