73
● IPsec プロトコルスイート
● IPsec が提供するサービス
●トランスポートモードとトンネルモード
● セキュリティポリシー
● セキュリティアソシエーション
● IPsec 処理の流れ
● IPsec の実装
5章
IPsec のアーキテクチャ
IPsec は、セキュリティ機能のない現在の IPv4 と、次世代の IP である IPv6 の両方のセキュリ
ティを確保するプロトコルです。特に、IPv6ではIPsecの実装が必須とされており、標準で使用
することができます。
IPsecをホストに実装することによって、ホスト間のIPによる通信を保護することが可能とな
ります。また、ゲートウェイにIPsecを実装することによって、VPNを構築することが可能とな
り、拠点間の IP による通信を保護することが可能となります。
IPsecの最初の仕様は、1995年に発表されました。そして、1998年にその改訂版が発表されて
います。この章では、1998 年に発表された改訂版の仕様 [1] を基に IPsec のアーキテクチャに
ついて解説します。
5.1 IPsec プロトコルスイート
IPsecは、複数のプロトコルから構成されるプロトコルの集合（プロトコルスイート）です。こ
こでは、IPsec を構成するプロトコルとその仕様との関係や IPsec に特有の用語について説明し
ます。
5.1.1 IPsec を構成するプロトコル
表5-1にIPsecで使用されるプロトコルをまとめます。IPsecは、認証ヘッダ
（AH：Authentication
Header）および暗号ペイロード（ESP：Encapsulating Security Payload）の 2 つのプロトコルから
なります。また、IPsecと共に使用されるプロトコルとして、IPComp（IP Payload Compression
Protocol）とIKE（Internet Key Exchange）があります。IPCompとIKEは、IPsecとは独立したプ
74 ● 5 章 IPsec のアーキテクチャ
表 5-1 IPsec で使用されるプロトコル
プロトコル名称
プロトコル番号など
認証ヘッダ（AH：Authentication Header）
プロトコル番号 51
暗号ペイロード（ESP：Encapsulating Security Payload）
プロトコル番号 50
IPComp（IP Payload Compression Protocol）
プロトコル番号 108
IKE（Internet Key Exchange）
500/UDP
ロトコルですが、通常は IPsec と組み合わせて使用されるため、AH、ESP、IPComp、IKE の 4
つのプロトコルをまとめて IPsec と呼ぶ場合があります。
AHは、IPパケットの完全性を確保するセキュリティプロトコルであり、プロトコル番号51が
使用されます。また、ESP は、IP パケットの機密性と完全性を確保するセキュリティプロトコ
ルであり、プロトコル番号 50 が使用されます。そして、IPComp は、IP パケットの圧縮を行う
プロトコルであり、プロトコル番号108が使用されます。これらの3つのプロトコルは、組み合
わせて使用することも、単独で使用することも可能です。
IKE は、AH や ESP、IPComp で使用するアルゴリズムの種類や鍵などの情報を交換するため
コラム：「IPsec」？「IPSec」？「IPSEC」？
実は、IP Security Protocolの省略形には複数の表記法があります。最近では、
「IPSec」と
いうように S を大文字にして表記されることが多いようですが、RFC では「IPsec」と表記
されています。果たして、どちらの表記法が正しいのでしょうか。この議論は、IETF の
IPSEC WGのメーリングリストにおいても話題になりました。RFC 2401、RFC 2402、RFC
2406 の共著者である Stephen Kent は、メーリングリストで「IPsec」と表記するのが正し
いと主張しています。あるときに、「IPSec」と間違えて記述してしまったことが原因とな
り、マスメディアを中心に
「IPSec」
という表記で広まってしまったようです。IETFのIPSEC
WGでは、
「IPsec」という表記にするべきという意見で落ち着いているようですが、中には
IP Security Protocol の略なのだから S は大文字にすべきだという意見もあります。本書で
は、Stephen Kent の主張のとおりに「IPsec」と表記することにしますが、同じ「アイピー
セック」を指すものですからどちらでもよいでしょう。なお、最近では、「IPSEC」とすべ
て大文字にする表記法も多くなってきました。本書では、WG の名称を記述する場合のみ
「IPSEC」とすべて大文字で記述しています。
5.1 IPsec プロトコルスイート ● 75
のプロトコルです。AHや ESP、IPCompは、対象となる IPパケットにヘッダを挿入する形で実
現されますが、IKE は、独立したパケット（UDP のポート 500 番）を使用します。
5.1.2 IPsecドキュメント体系
IPsecでは、前節で紹介したプロトコルの仕様や、そのプロトコルで使用されるアルゴリズム
の仕様など、非常に多くの文書が存在します。RFC 2411 [2] では、IPsecに関する文書の関係を
整理しています。IPsec に関する主な RFC の関係をまとめると図 5-1 のようになります。
IPsec に関連する RFC は、主に、IPsec 全般に関する RFC と、AH および ESP の各セキュリ
ティプロトコルに関する RFC、自動鍵管理に関する RFC、IPComp に関する RFC に分類するこ
とができます（表 5-2 ∼表 5-5）。
また、RFC以外にも、インターネットドラフトの段階の文書が多く存在します。これらのイン
ターネットドラフトの文書は、近いうちにRFCとなることが予想されます。IPsecの仕様を確認
する際には、最新の RFC の発行状況を確認しておく必要があります。
ISAKMP（RFC 2408）
鍵管理プロトコル
IKE（RFC 2409）
Oakley（RFC 2412）
IPsec DOI（RFC 2407）
アルゴリズム
認証アルゴリズム
（RFC 2403、2404、2857）
暗号化アルゴリズム
（RFC 2405、2410、2451）
圧縮アルゴリズム
（RFC 2394、2395、3051）
セキュリティ
プロトコル
AH（RFC 2402）
ESP（RFC 2406）
IPComp（RFC 3173）
IPsec アーキテクチャ（RFC 2401）
図 5-1 IPsec ドキュメント体系
76 ● 5 章 IPsec のアーキテクチャ
表 5-2 IPsec 全般に関する RFC
RFC 2401
（PS）
RFC 2411
（I）
インターネットプロトコルのためのセキュリティアーキテクチャ
（Security Architecture for the Internet Protocol）
IP セキュリティ文書体系
（IP Security Document Roadmap）
PS：Proposed Standard（標準提案） I：Informational（情報提供）
表 5-3 AH および ESP に関する RFC
RFC 2402
（PS）
IP 認証ヘッダ
（IP Authentication Header）
RFC 2406
（PS）
IP 暗号ペイロード（ESP）
（IP Encapsulating Security Payload（ESP））
RFC 2403
（PS）
ESP および AH での HMAC-MD5-96 の使用法
（The Use of HMAC-MD5-96 within ESP and AH）
RFC 2404
（PS）
ESP および AH での HMAC-SHA-1-96 の使用法
（The Use of HMAC-SHA-1-96 within ESP and AH）
RFC 2857
（PS）
ESP および AH での HMAC-RIPEMD-160-96 の使用法
（The Use of HMAC-RIPEMD-160-96 within ESP and AH）
RFC 2405
（PS）
明示的 IV を伴う ESP DES-CBC 暗号アルゴリズム
（The ESP DES-CBC Cipher Algorithm With Explicit IV）
RFC 2410
（PS）
NULL 暗号化アルゴリズムと IPsec でのその使用法
（The NULL Encryption Algorithm and Its Use With IPsec）
RFC 2451
（PS）
ESP CBC モード暗号アルゴリズム
（ESP CBC-Mode Cipher Algorithms）
PS：Proposed Standard（標準提案）
表 5-4 IKE に関する RFC
RFC 2407
（PS）
ISAKMP における IP セキュリティ翻訳ドメイン
（The Internet IP Security Domain of Interpretation for ISAKMP）
RFC 2408
（PS）
インターネットセキュリティアソシエーションおよび鍵管理プロトコル（ISAKMP）
（Internet Security Association and Key Management Protocol（ISAKMP）
）
RFC 2409
（PS）
インターネット鍵交換（IKE）
（The Internet Key Exchange（IKE）
）
RFC 2412
（I）
OAKLEY 鍵決定プロトコル
（The OAKLEY Key Determination Protocol）
PS：Proposed Standard（標準提案） I：Informational（情報提供）
5.1 IPsec プロトコルスイート ● 77
表 5-5 IPComp に関する RFC
RFC 3173
IP ペイロード圧縮プロトコル（IPComp）
（PS）
（IP Payload Compression Protocol（IPComp）
）
RFC 2394
（I）
DEFLATE を用いた IP ペイロード圧縮
（IP Payload Compression Using DEFLATE）
RFC 2395
（I）
LZS を用いた IP ペイロード圧縮
（IP Payload Compression Using LZS）
RFC 3051
（I）
ITU-T V.44 パケット方式を用いた IP ペイロード圧縮
（IP Payload Compression Using ITU-T V.44 Packet Method）
PS：Proposed Standard（標準提案） I：Informational（情報提供）
5.1.3 IPsec で使用される用語
IPsec の仕様では、IPsec 特有の用語が多く使用されています。ここでは、本書においても使
用されている IPsec 特有の用語についてまとめます。
IPsec ホスト
IPsec が実装されたホストを IPsec ホストと呼びます。
セキュリティゲートウェイ
IPsec が実装された中継機器をセキュリティゲートウェイと呼びます。通常のパケットに
IPsec を適用して転送する機能や、IPsec が適用されたパケットを元の状態に戻して転送す
る機能を持ちます。
IPsec 機器
IPsecホストやセキュリティゲートウェイなどのIPsecが実装された機器をまとめてIPsec機
器と呼びます。
IPsec プロトコル
IPsec は複数のプロトコルから構成されています。IPsec で使用されている個々のプロトコ
ルを IPsec プロトコルと呼びます。
セキュリティポリシー
IP パケットに対して IPsec を適用するかどうか、IPsec を適用する場合はどのような機能を
使用するかということを記述したポリシーをセキュリティポリシーと呼びます。一般に使用
されているセキュリティポリシーという用語と区別するために、IPsecポリシーと呼ぶ場合
78 ● 5 章 IPsec のアーキテクチャ
もあります。セキュリティポリシーは、セキュリティポリシーデータベース
（SPD）
に格納さ
れます。
セキュリティアソシエーション
（SA）
IPsecなどのセキュリティプロトコルによって保護されたコネクションをセキュリティアソ
シエーション（SA：Security Association）と呼びます。特にIPsecによって保護されたSAは、
IPsec SA と呼びます。SA に関する情報は、セキュリティアソシエーションデータベース
（SAD）に格納されます。
5.2 IPsec が提供するサービス
IPsecは、アクセス制御、データの完全性確保、データ送信元の認証、リプレイ防御、データ
の機密性確保、トラフィック情報の機密性確保の機能を提供します（表5-6）。これらのセキュリ
ティ機能を IP層で提供することによって、IP の上位層プロトコルのセキュリティを確保するこ
とが可能となります。ここでは、IPsec が提供するセキュリティ機能について紹介します。
表 5-6 IPsec が提供するサービス
提供サービス
サービスを実現する技術
サービスを実現するプロトコル
アクセス制御
セキュリティポリシーにしたがった
パケットフィルタリング
AH または ESP
データの完全性確保
メッセージ認証コード（MAC）
AH または ESP
データ送信元の認証
メッセージ認証コード（MAC）
AH または ESP
リプレイ防御
シーケンス番号のチェック
AH または ESP
データの機密性確保
共通鍵暗号による暗号化
ESP
トラフィック情報の
機密性確保
共通鍵暗号による暗号化と
トンネリング
ESP
5.2.1 アクセス制御
IPsecでは、セキュリティポリシーという概念を持ちます。セキュリティポリシーでは、どの
ようなパケットに対してIPsecを適用するのか、どのようなパケットを通常のパケットとして処
理するのか、また、どのようなパケットを破棄するのかということを記述します。IPsecが実装
された機器では、このセキュリティポリシーにしたがってパケットのフィルタリング（アクセス
制御）を行います。セキュリティポリシーについては、「5.4 セキュリティポリシー」で詳しく説
5.2 IPsec が提供するサービス ● 79
明します。
5.2.2 データの完全性確保
IPsecでは、メッセージ認証コード
（MAC）
を使用することにより、データの完全性を確保しま
す。ただし、IP はコネクションレスのプロトコルであるため、IPsec では前後の IP パケットの
関係を考慮して完全性を確保することができません。このため、IPsecで確保する完全性はコネ
クションレス完全性と呼ばれます。データの完全性を確保する機能は、AHまたはESPによって
提供されます。
5.2.3 データ送信元の認証
IPsecでは、メッセージ認証コード
（MAC）
を使用することにより、受信されたデータが同じ共
有秘密鍵を持つ相手から送信されたものであることを確認します。
MACで使用する秘密鍵を共有する際には、相手の認証を行います。秘密鍵は、手動で共有す
ることも可能ですが、IKEを使用して自動的に共有することができます。IKEでは、秘密鍵を共
有する相手をデジタル署名などを利用して認証します。データの送信元を認証する機能は、AH
または ESP によって提供されます。
5.2.4 リプレイ防御
なりすましや改ざんを防止するための機能が備わっていたとしても、正当な相手が送信したパ
ケットを悪意のある第三者がコピーし、それを後から送信することにより、正当な相手が以前と
同じリクエストを行っているように見せかけることが可能となります。これをリプレイ攻撃（再
送攻撃）と呼びます。リプレイ攻撃を行うことにより、正当な相手が以前に行ったオンライン
ショッピングの注文を何度も成立させてしまったり、インターネットバンキングで何度も振り込
みを行ったりすることが可能となる場合があります。
このような被害を防止するために、IPsecにはリプレイ防御機能が備わっています。送信側は、
パケットにシーケンス番号を付与して送信し、受信側で同じシーケンス番号が付与されたパケッ
トが重複していないかどうかをチェックすることで、再送されたパケットを検出することが可能
となります。リプレイ防御の機能は、AH または ESP によってオプションで提供されます。
5.2.5 データの機密性確保
IPsecには、IPのデータを暗号化する機能があります。データを暗号化することによって、パ
ケットの配送中にデータが盗聴されたとしても、そのデータを解読することができないようにす
ることが可能です。「5.3 トランスポートモードとトンネルモード」
で説明するカプセル化モード
80 ● 5 章 IPsec のアーキテクチャ
によって、IP パケット全体を暗号化することも、IP ペイロード部のみ（IP ヘッダを含まない）を
暗号化することも可能です。
データは共通鍵暗号を使用して暗号化されます。IPsecでは、既存の暗号化アルゴリズムに加
えて、新しい暗号化アルゴリズムを後から組み込むことができるような仕様になっています。
データの機密性を確保する機能は、ESP によって提供されます。
5.2.6 トラフィック情報の機密性確保
「トラフィック情報の機密性を確保する」とは、どのノードからどのノードへ、どのような種
類のアクセスが、いつ、どの程度
（頻度、データ量など）
行われたのかということを第三者に知ら
れないようにすることを言います。IPsecではデータを暗号化する際に、上位層プロトコルの情
報も隠蔽します。つまり、どのようなサービス
（WWW、電子メールなど）
を利用しているのかと
いうことを第三者に知られないようにすることが可能となります。また、IPsecのトンネルモー
ドにより実現されるトンネリング機能を利用することによって、始点IPアドレスと終点IPアド
レスを隠蔽することも可能となります。ただし、アクセスの時間やアクセスの頻度までは隠すこ
とができません。トラフィック情報の機密性を確保する機能は、ESP によって提供されます。
5.3 トランスポートモードとトンネルモード
IPsecでは、カプセル化モード
（IPsecプロトコルモードとも呼ばれます）として、トランスポー
トモードとトンネルモードが用意されています。セキュリティゲートウェイでは、トンネルモー
ドを実装する必要があります。また、IPsecホストでは、トランスポートモードとトンネルモー
ドの両方を実装する必要があります。
5.3.1 トランスポートモード
ホスト間で IPsec を使用する場合には、トランスポートモードを使用します（図 5-2）。トラン
スポートモードでは、主に IP ペイロード部のセキュリティを確保します。
トランスポートモード
IPsec 出力処理
トランスポートモード
IPsec 入力処理
トランスポートモード IPsec
ホストA
ホストB
図 5-2 ホスト間におけるトランスポートモード IPsec
5.3 トランスポートモードとトンネルモード ● 81
トランスポートモードのヘッダ構成（ IPv4 ）
IPv4 では、IPv4 ヘッダとトランスポート層プロトコルヘッダの間に IPsec で使用するヘッダ
（AH ヘッダまたは ESP ヘッダ）を挿入します（図 5-3）。
IPv4
ヘッダ
TCP
ヘッダ
データ
（a）IPsec 適用前の IPv4 パケット
IPv4
AH
ヘッダ ヘッダ
TCP
ヘッダ
データ
（b）AH 適用後の IPv4 パケット
IPv4
ESP
ヘッダ ヘッダ
TCP
ヘッダ
データ
ESP
トレーラ
ESP
認証
データ
（c）ESP 適用後の IPv4 パケット
IPv4
AH
ESP
TCP
ヘッダ ヘッダ ヘッダ ヘッダ
データ
ESP
トレーラ
（d）ESP および AH 適用後の IPv4 パケット
図 5-3 トランスポートモード IPsec を適用した IPv4 パケット（網掛部は暗号化）
トランスポートモードのヘッダ構成（IPv6）
IPv6 では、IPsec の AH ヘッダおよび ESP ヘッダは IPv6 拡張ヘッダとして定義されています。
IPv6 の場合も IPv4 の場合と同様に、IPv6 ヘッダとトランスポート層プロトコルヘッダの間（終
点オプションヘッダが存在する場合には、終点オプションヘッダの前）に IPsec で使用するヘッ
ダ（AH ヘッダまたは ESP ヘッダ）を挿入します（図 5-4）。
5.3.2 トンネルモード
トンネルモードは、主にセキュリティゲートウェイ間でIPsecトンネルを構築する場合に使用
されます。トンネルモードでは、IPパケット全体に対してセキュリティ機能を適用します。そし
て、セキュリティゲートウェイが新たにトンネル配送用のIPヘッダを追加して、相手側のセキュ
リティゲートウェイに送信します。こうすることで、セキュリティゲートウェイ間で安全なトン
82 ● 5 章 IPsec のアーキテクチャ
経路
終点
IPv6
TCP
制御 オプション
ヘッダ
ヘッダ
ヘッダ ヘッダ
データ
（a）IPsec 適用前の IPv6 パケット
経路
終点
IPv6
AH
TCP
制御
オプション
ヘッダ
ヘッダ
ヘッダ
ヘッダ
ヘッダ
データ
（b）AH 適用後の IPv6 パケット
経路
終点
ESP
IPv6
TCP
制御
オプション
ヘッダ
ヘッダ
ヘッダ
ヘッダ
ヘッダ
ESP
ESP
認証
トレーラ
データ
データ
（c）ESP 適用後の IPv6 パケット
経路
終点
ESP
IPv6
AH
TCP
制御
オプション
ヘッダ
ヘッダ ヘッダ
ヘッダ
ヘッダ
ヘッダ
ESP
トレーラ
データ
（d）ESP および AH 適用後の IPv6 パケット
図 5-4 トランスポートモード IPsec を適用した IPv6 パケット（網掛部は暗号化）
ネル（VPN）を構築することが可能となります。
セキュリティゲートウェイ間でトンネルモードを使用する場合は、パケットを送信するホスト
はIPsecを実装する必要は無く、トンネルの始点および終点となるセキュリティゲートウェイが
IPsecの機能を実現します
（図5-5）
。また、セキュリティゲートウェイ間では、ホストが送信した
IP パケットがカプセル化されるため、ホストのアドレスを隠すことが可能です。このため、セ
キュリティゲートウェイで守られたネットワークでは、プライベートアドレスを利用することが
トンネルモード
IPsec 入力処理
トンネルモード
IPsec 出力処理
トンネルモード IPsec
ホスト A
セキュリティ
ゲートウェイ A
セキュリティ
ゲートウェイ B
図 5-5 セキュリティゲートウェイ間におけるトンネルモード IPsec
ホスト B
5.3 トランスポートモードとトンネルモード ● 83
可能となります。
また、セキュリティゲートウェイ間だけでなく、セキュリティゲートウェイとホストとの間に
おいてもトンネルモードを使用することが可能です。例えば、送信側にトンネルモードのIPsec
処理を行うセキュリティゲートウェイを設置し、受信側のホストが直接IPsecパケットを受信す
る場合は、受信側のホストがトンネルモードの IPsec 入力処理を行う必要があります（図 5-6）。
同様に、受信側のみにセキュリティゲートウェイを設置した場合は、送信側のホストがトンネ
ルモードの IPsec 出力処理を行う必要があります（図 5-7）。
また、ホスト間でトンネルモードを利用することも可能です（図5-8）。ただし、トンネルモー
トンネルモード
IPsec 出力処理
トンネルモード
IPsec 入力処理
トンネルモード IPsec
ホストA
ホスト B
セキュリティ
ゲートウェイ A
図 5-6 セキュリティゲートウェイからホストへのトンネルモード IPsec
トンネルモード
IPsec 出力処理
トンネルモード
IPsec 入力処理
トンネルモード IPsec
ホスト A
セキュリティ
ゲートウェイ B
ホスト B
図 5-7 ホストからセキュリティゲートウェイへのトンネルモード IPsec
トンネルモード
IPsec 出力処理
トンネルモード
IPsec 入力処理
トンネルモード IPsec
ホスト A
ホスト B
図 5-8 ホスト間におけるトンネルモード IPsec
84 ● 5 章 IPsec のアーキテクチャ
ドでは、トンネル配送用に新たに付与する IP ヘッダのオーバーヘッドが発生するため、ホスト
間の場合は、通常トランスポートモードを使用します。
IPv4 パケットに IPv4トンネルモード IPsec を適用する場合のヘッダ構成
IPv4 パケットに対してトンネルモード IPsec を適用する場合は、図 5-9 に示すように、オリジ
ナルの IPv4 パケット全体に対して IPsec のセキュリティ機能を適用し、そのパケットをトンネ
ルの終点まで運ぶための IPv4 ヘッダ（トンネル配送用 IPv4 ヘッダ）と IPsec で使用するヘッダ
（AH ヘッダまたは ESP ヘッダ）を新たに追加します。オリジナルの IPv4 ヘッダは、トンネル上
を配送される間は参照されることはありません。
IPv4
TCP
ヘッダ ヘッダ
データ
（a）IPsec 適用前の IPv4 パケット
トンネル
AH
IPv4
TCP
IPv4
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
（b）AH 適用後の IPv4 パケット
トンネル
ESP
IPv4
TCP
IPv4
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
ESP
認証
トレーラ
データ
（c）ESP 適用後の IPv4 パケット
トンネル
IPv4
AH
ESP
TCP
IPv4
ヘッダ ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
トレーラ
（d）ESP および AH 適用後の IPv4 パケット
図 5-9 トンネルモード IPsec（IPv4）を適用した IPv4 パケット（網掛部は暗号化）
IPv6 パケットに IPv6トンネルモード IPsec を適用する場合のヘッダ構成
IPv6 パケットに対してトンネルモード IPsec を適用する場合は、図 5-10 に示すように、オリ
ジナルの IPv6 パケット全体に対して IPsec のセキュリティ機能を適用し、そのパケットをトン
ネルの終点まで運ぶための IPv6 ヘッダ（トンネル配送用 IPv6 ヘッダ）と IPsec で使用するヘッダ
（AH ヘッダまたは ESP ヘッダ）を新たに追加します。オリジナルの IPv6 ヘッダは、トンネル上
5.3 トランスポートモードとトンネルモード ● 85
IPv6
TCP
ヘッダ ヘッダ
データ
（a）IPsec 適用前の IPv6 パケット
トンネル
AH
IPv6
TCP
IPv6
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
（b）AH 適用後の IPv6 パケット
トンネル
ESP
IPv6
TCP
IPv6
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
ESP
認証
トレーラ
データ
（c）ESP 適用後の IPv6 パケット
トンネル
IPv6
AH
ESP
TCP
IPv6
ヘッダ ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
トレーラ
（d）ESP および AH 適用後の IPv6 パケット
図 5-10 トンネルモード IPsec（IPv6）を適用した IPv6 パケット（網掛部は暗号化）
を配送される間は参照されることはありません。
IPv6 パケットに IPv4トンネルモード IPsec を適用する場合のヘッダ構成
IPv6 パケットに対してトンネルモード IPsec を適用し、IPv4 ネットワーク上を配送することも
可能です。この場合は、図 5-11 に示すように、オリジナルの IPv6 パケット全体に対して IPsec の
セキュリティ機能を適用し、そのパケットをトンネルの終点まで運ぶためのIPv4ヘッダ
（トンネル
配送用IPv4ヘッダ）
とIPsecで使用するヘッダ
（AHヘッダまたはESPヘッダ）
を新たに追加します。
オリジナルの IPv6 ヘッダは、トンネル上を配送される間は参照されることはありません。
IPv4 パケットに IPv6トンネルモード IPsec を適用する場合のヘッダ構成
IPv4 パケットに対してトンネルモード IPsec を適用し、IPv6 ネットワーク上を配送することも
可能です。この場合は、図 5-12 に示すように、オリジナルの IPv4 パケット全体に対して IPsec の
セキュリティ機能を適用し、そのパケットをトンネルの終点まで運ぶためのIPv6ヘッダ
（トンネル
配送用IPv6ヘッダ）
とIPsecで使用するヘッダ
（AHヘッダまたはESPヘッダ）
を新たに追加します。
オリジナルの IPv4 ヘッダは、トンネル上を配送される間は参照されることはありません。
86 ● 5 章 IPsec のアーキテクチャ
IPv6
TCP
ヘッダ ヘッダ
データ
（a）IPsec 適用前の IPv6 パケット
トンネル
AH
IPv6
TCP
IPv4
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
（b）AH 適用後の IPv6 パケット
トンネル
ESP
IPv6
TCP
IPv4
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
ESP
認証
トレーラ
データ
（c）ESP 適用後の IPv6 パケット
トンネル
IPv6
AH
ESP
TCP
IPv4
ヘッダ ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
トレーラ
（d）ESP および AH 適用後の IPv6 パケット
図 5-11 トンネルモード IPsec（IPv4）を適用した IPv6 パケット（網掛部は暗号化）
IPv4
TCP
ヘッダ ヘッダ
データ
（a）IPsec 適用前の IPv4 パケット
トンネル
AH
IPv4
TCP
IPv6
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
（b）AH 適用後の IPv4 パケット
トンネル
ESP
IPv4
TCP
IPv6
ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
ESP
認証
トレーラ
データ
（c）ESP 適用後の IPv4 パケット
トンネル
AH
ESP
TCP
IPv4
IPv6
ヘッダ ヘッダ ヘッダ ヘッダ
ヘッダ
データ
ESP
トレーラ
（d）ESP および AH 適用後の IPv4 パケット
図 5-12 トンネルモード IPsec（IPv6）を適用した IPv4 パケット（網掛部は暗号化）
5.4 セキュリティポリシー ● 87
5.4 セキュリティポリシー
IPsec を実装したノードでは、IP パケットの処理の方法を記述したセキュリティポリシー
（IPsec ポリシー）が必要となります。ここでは、IPsec におけるセキュリティポリシーについて
説明します。
5.4.1 セキュリティポリシーによるパケットの処理
IPsec におけるセキュリティポリシー（IPsec ポリシー）では、IP パケットに対して、次のうち
どの処理を行うのかを記述します（図 5-13）。
1.
パケットを破棄する（discard）
2.
IPsec を適用せずに通常の処理を行う（bypass IPsec）
3.
IPsec を適用する（apply IPsec）
IPsec 機器を通過してはならないパケットに対しては、「破棄（discard）」を指定します。IPsec
を適用せずに通常の処理を行うパケットに対しては、「IPsecを適用しない（bypass IPsec）」を指
定します。そして、IPsec で保護するパケットに対しては「IPsec を適用（apply IPsec）」を指定
します。この場合には、適用するIPsecプロトコル（AHまたはESP）
やカプセル化モード（トンネ
ルモードまたはトランスポートモード）などについても指定します。
IPsec ホスト
ルータ
（discard）
セキュリティ
ポリシー
（bypass IPsec）
（apply IPsec）
× 破棄
IPsec を適用しないで送信
IPsec を適用して送信
図 5-13 ホストにおける IPsec 出力処理
5.4.2 セレクタ
セキュリティポリシーにおいて処理対象となるパケットを指定するために利用する情報をセレ
クタと呼びます。セレクタには、パケットの始点IPアドレス、終点IPアドレス、トランスポー
ト層プロトコル、送信元ポート番号、宛先ポート番号などが使用されます。
88 ● 5 章 IPsec のアーキテクチャ
5.4.3 セキュリティポリシーデータベース（ SPD ）
IPsecのセキュリティポリシーは、セキュリティポリシーデータベース
（SPD）
に登録されます。
SPDには、出力パケットに対するセキュリティポリシーが格納された出力用SPDと、入力パケッ
トに対するセキュリティポリシーが格納された入力用SPDの2種類が存在します。セキュリティ
ポリシーの適用対象となるパケットは、セレクタによって指定します。
表 5-7 に SPD の例を示します。この SPD は、図 5-14 における 10.1.1.1 というアドレスを持つ
セキュリティゲートウェイが保持する出力用SPDの例です。このセキュリティポリシーでは、セ
キュリティゲートウェイの背後の10.1.1.0/24というアドレスを持つネットワークと、10.2.1.0/24
というアドレスを持つ別のネットワークとの間でトンネルモードIPsecを適用し、10.2.1.0/24以
外の宛先に対しては、IPsec を適用しないという指定をしています。
表 5-7 出力用セキュリティポリシーデータベース（SPD）の例
評価
順序
セレクタ
始点 IP アドレス
終点 IP アドレス
プロトコル
1
10.1.1.0/24
10.2.1.0/24
Any
Any
2
Any
Any
Any
Any
IPsec を適用
しないで送信
適用する処理
宛先ポート
“apply IPsec”
[ESP]
トンネルモード
トンネルの始点：
10.1.1.1
トンネルの終点：
10.2.1.1
暗号化アルゴリズム：
DES-CBC
認証アルゴリズム：
HMAC-SHA-1
“bypass IPsec”
その他の
ネットワーク
10.1.1.0/24
10.2.1.0/24
10.1.1.1
トンネルモード IPsec
10.2.1.1
図 5-14 セキュリティゲートウェイにおける出力セキュリティポリシーの例
5.5 セキュリティアソシエーション ● 89
5.5 セキュリティアソシエーション
IPsecでは、セキュリティアソシエーション（SA：Security Association）という概念を導入して
います。ここでは、SA の概念について説明します。
5.5.1 セキュリティアソシエーションの概念
セキュリティアソシエーション（SA）は、あるトラフィックのセキュリティを確保する単方向
のコネクションです。SA におけるセキュリティは、AH や ESP などのセキュリティプロトコル
によって確保されます。
SAはセキュリティプロトコルごとに確立されます。つまり、AHによってあるSAが確立され、
ESPによって別のSAが確立されます。また、SAは単方向のコネクションであるため、実際の通
信では、各セキュリティプロトコルに対して方向の異なる2本のSAが使用されます。例えば、2
つのホストの間で、AH と ESP を両方向に対して使用した場合には、計 4 本の SA が使用されま
す（図 5-15）。
SA を識別するための情報として、終点 IP アドレス、AH や ESP などのセキュリティプロトコ
ル（IPsecプロトコル）の種別、そしてセキュリティパラメータインデックス（SPI）の3つが使用さ
れます。つまり、終点やセキュリティプロトコルが異なると、別のSAが使用されます。SPIは、
終点とセキュリティプロトコルが同じ SA を多重化するための識別子として使用されます。
SAでは、カプセル化モード（トランスポートモードまたはトンネルモード）
、使用するIPsecプ
ロトコルの種別（AHまたはESP）、AHやESPで使用するアルゴリズム（暗号化アルゴリズムや認
証アルゴリズム）
、アルゴリズムで使用するさまざまなパラメータ（鍵など）などが決められてい
ます。これらの情報は手動で設定することもできますが、9 章「SA 管理と鍵管理」で説明する
IKE などの SA を管理するプロトコルによって自動で折衝することも可能です。
AH 用の SA（A → B）
AH 用の SA（B → A）
ホスト A
ESP 用の SA（A → B）
ホスト B
ESP 用の SA（B → A）
図 5-15 ホスト間に確立されるセキュリティアソシエーション（AH と ESP を使用した場合）
90 ● 5 章 IPsec のアーキテクチャ
SAは、セキュリティポリシーにしたがって生成されます。つまり、あるIPパケットに対する
処理が発生した場合には、最初にセキュリティポリシーが格納されているSPDが参照されます。
セキュリティポリシーで IPsec を適用するように指定されていた場合には、次に SA が格納され
ているデータベースである SAD（Security Association Database）から、該当する SA の情報が検
索されます。該当するSAが存在しなかった場合には、IKEなどの自動SA管理プロトコルによっ
てSAが生成されます。SAの生成の際には、セキュリティポリシーで記述された情報を基に相手
側と条件が折衝されます。つまり、セキュリティポリシーに、
「ESPのトンネルモードを適用し、
AES で暗号化する」と記述されている場合には、この条件が受信側に提案されます。受信側は、
提案の内容を受信側が持つセキュリティポリシーと比較し、この内容で良ければ、送信側が提案
した内容のSAが生成されます。送信側は、複数の内容を受信側に提案することも可能です。こ
の場合は、受信側は、複数の提案から 1 つを選択することにより、SA の内容が確定します。
5.5.2 セキュリティアソシエーションのパラメータ
セキュリティアソシエーション（SA）には表5-8のようなパラメータが存在します。ただし、す
表 5-8 セキュリティアソシエーションのパラメータ
SAパラメータ
SAパラメータ値の例
外側ヘッダの終点IPアドレス*
10.2.1.1
IPsecプロトコル種別*
ESP
SPI値*
0x32f9a7c6
カプセル化モード
トンネルモード
認証アルゴリズム
HMAC-SHA-1-96
ユーザ設定
認証鍵
0x83f5a7635c8f7eb1232382d7eba9817d7eb38df3
パラメータ
暗号化アルゴリズム
AES-CBC
暗号化鍵
0x7d5e837ad6f5ea9d8e713287d63bcbe8
ECNトンネル
無効（Forbidden）
シーケンス番号カウンタ
1（オーバーフローした場合はSA無効）
オーバーフローフラグ
SAの有効期間
ソフト有効期間：3,570秒
ハード有効期間：3,600秒
システム
パラメータ
シーケンス番号カウンタ
83
リプレイ防御ウィンドウ
11111111111111111111111111111101
パケット総転送量
54,302バイト
経路MTU値
1,472バイト
暗号化アルゴリズムで使用するIV
0x7df3655cabdf7263018cb092627adf8e
* SAを検索する際にキーとして使用されるパラメータ。
5.5 セキュリティアソシエーション ● 91
べてのパラメータが必須というわけではありません。AHやESPの認証機能を使用しない場合に
は、認証アルゴリズムや認証鍵は必要ありません。また、ESPの暗号化機能を使用しない場合に
は、暗号化アルゴリズムや暗号化鍵は必要ありません。
外側ヘッダの終点 IP アドレス
SAを検索する際のキーとして使用される必須のパラメータです。このパラメータには、トラ
ンスポートモードの場合はIPヘッダの終点IPアドレスが記述され、トンネルモードの場合はト
ンネルの終点 IP アドレス（トンネル配送用 IP ヘッダの終点 IP アドレス）が記述されます。
IPsec プロトコル種別
SAを検索する際のキーとして使用される必須のパラメータです。IPsecプロトコルとは、AH
または ESP を指します。SA は、IPsec プロトコルごとに生成され、AH または ESP のどちらか
一方の属性を持ちます。
セキュリティパラメータインデックス（SPI）値
SAを検索する際のキーとして使用される必須のパラメータです。SPIは、SAを識別するため
の 32 ビットの値です。AH および ESP のヘッダには、この SPI 値を記述するための SPI フィー
ルドが存在します。受信側では、この SPI 値と IPsec プロトコルの種類（AH または ESP）、そし
て終点 IP アドレスをもとに SA が識別されます。
カプセル化モード
トンネルモードまたはトランスポートモードのどちらかが記述されます。
ECNトンネル
IPsecトンネルでECN（Explicit Congestion Notification）機能を有効にするかどうかを記述しま
す。有効にする場合には「Allowed」と記述し、無効にする場合には「Forbidden」と記述します
[3]。このSAパラメータはオプションです。存在しない場合には、「無効（Forbidden）」として扱
われます。
シーケンス番号カウンタオーバーフローフラグ
シーケンス番号カウンタオーバーフローフラグは、IPsec 出力処理で使用されます。IPsec で
は、パケットにSAごとに管理されるシーケンス番号を付与して送信しますが、このシーケンス
番号が32ビットで表現できる数を超えた（オーバーフローした）場合に、そのSAを無効とするか
92 ● 5 章 IPsec のアーキテクチャ
どうかをこのシーケンス番号カウンタオーバーフローフラグに記述します。デフォルトでは、
シーケンス番号がオーバーフローした場合に SA が無効となり、新しい SA が折衝され、シーケ
ンス番号のカウンタが0に戻されます。しかし、受信側でリプレイ防御機能が無効とされている
ことがあらかじめ判明している場合
（SAが手動で設定されている場合など）
には、オーバーフロー
した場合でも引き続き SA を使用することができます。
セキュリティアソシエーションの有効期間
IKE による自動鍵交換を行う場合には、SA の有効期間（鍵の更新間隔）を設定します。有効期
間には、SAを更新する時期を指定するソフト有効期間と、SAを無効とする時期を指定するハー
ド有効期間の 2 種類があります。ソフト有効期間が過ぎると新しい SA が折衝されますが、それ
まで使用されていたSAはハード有効期間が過ぎるまでは引き続き使用することが可能です（図516）
。これは、SAが無効になってから新しいSAの折衝を行うと、折衝が完了するまでの間はIPsec
が適用できない状態となるため、新しい SA の折衝を現在の SA が無効となる前に行い、実際に
SAの有効期間が過ぎて無効となると同時に新しいSAを使用してIPsecによる通信を継続するこ
とができるようにするためです。有効期間は、時間（秒単位）
での指定と、送信するデータ量
（キ
ロバイト単位）での指定が可能です。両方が指定された場合には、どちらか一方の有効期間が過
ぎた時点で SA が無効となります。
ハード有効期間
ソフト有効期間
SA の有効期間
新しい SA の有効期間
×
新しい SA の折衝
時間
図 5-16 ソフト有効期間とハード有効期間
シーケンス番号カウンタ
シーケンス番号カウンタは、IPsec出力処理で使用されます。シーケンス番号は、リプレイ攻
撃から防御するための 32 ビットの値です。AH および ESP のヘッダには、このシーケンス番号
を保持するためのシーケンス番号フィールドが存在します。SADでは、SAごとにシーケンス番
号のカウンタが用意され、パケットを送信する度にカウンタが 1 ずつ増加されます。
5.5 セキュリティアソシエーション ● 93
リプレイ防御ウィンドウ
リプレイ防御ウィンドウは、IPsec入力処理で使用されます。このパラメータは、受信側でシー
ケンス番号を検証する場合にのみ使用されます。リプレイ防御機能を使用するかどうかは受信側
によって決定されます。リプレイ防御機能を使用しない場合は、このリプレイ防御ウィンドウは
使用されません。
経路 MTU 値
経路MTU値は、IPsec出力処理で使用されます。このパラメータには、SAの終点までの経路
上でフラグメントを発生させずに IPsec を適用して運ぶことの可能な最大 IP パケットサイズ
（MTU：Maximum Transmission Unit）が入ります。この経路 MTU 値には、IPsec の適用によっ
て増加するヘッダの量を考慮して計算された値が入ります。
5.5.3 セキュリティアソシエーションデータベース（SAD ）
SAに関する情報は、セキュリティアソシエーションデータベース
（SAD）
に格納されます。SAD
は手動で管理することも可能ですが、IKEを使用することによって自動で管理することができま
す。IKEを使用した場合には、SAの有効期間が過ぎた場合などに自動的にSADが更新されます。
SADには、出力パケットの処理の際に参照される出力用SADと、入力パケットの処理の際に
参照される入力用 SAD があります。
SADの各エントリには、キーとなる終点IPアドレス、IPsecプロトコルの種類、SPI値の他に、
SA に関するさまざまな情報が記述されます（表 5-9）。
表 5-9 セキュリティアソシエーションデータベース（ SAD）の例
キーとなる SA パラメータ
終点 IP アドレス
IPsec プロトコル
SPI
10.2.1.1
ESP
3000
その他の SA パラメータ
カプセル化モード：トンネルモード
暗号化アルゴリズム：Blowfish-CBC
暗号化鍵：1048ea648 . . . 246a5f7
IV：a7323d1278f12ba2
認証アルゴリズム：HMAC-SHA-1-96
認証鍵：826170af1 .. . 288e8da
シーケンス番号：882
10.2.2.1
ESP
3010
カプセル化モード：トンネルモード
暗号化アルゴリズム：3DES -CBC
暗号化鍵：a430e05f 2 .. . 5a4fe24
94 ● 5 章 IPsec のアーキテクチャ
表 5-9 セキュリティアソシエーションデータベース（ SAD）の例（つづき）
キーとなる SA パラメータ
終点 IP アドレス
IPsec プロトコル
SPI
その他の SA パラメータ
IV：42df 7d386ae8f1a2
認証アルゴリズム：HMAC-SHA-1-96
認証鍵：3d17ef471 . . . 24ca590
シーケンス番号：258
5.6 IPsec 処理の流れ
IPsec 機器では、IP パケットを送信する場合や、IP パケットを受信した場合に IPsec 処理が発
生します。ここでは、IPsec処理を出力処理と入力処理に分けて、その処理の流れを説明します。
5.6.1 IPsec 機器での出力処理
IP パケットが IPsec 機器から出力される場合には、次のような IPsec 出力処理を適用します。
1.
対象となるIP パケットの始点 IP アドレス、終点 IP アドレス、上位層プロトコル、ポー
ト番号などのセレクタをキーとして、出力用 SPD からセキュリティポリシーを検索し
ます。
2.
検索されたセキュリティポリシーが、「破棄（discard）」であった場合には、そのIPパケッ
トを破棄します。また、「IPsec を適用しない（bypass IPsec）」であった場合には、IPsec
を適用せずに、通常の処理を行います
（図5-17）。そして、「IPsecを適用（apply IPsec）」で
①処理方法の
問い合わせ
IPsec
処理部
ポリシー
管理部
③処理方法（破棄また
は通常処理）を返答
② SPD の検索
出力用 SPD
出力用 SAD
図 5-17 IP パケットを破棄または通常処理する場合の処理の流れ
5.6 IPsec 処理の流れ ● 95
あった場合には、次の IPsec 処理に進みます。
3.
出力用 SAD から該当する SA の情報を検索します。
4.
該当する SA の情報が存在しない場合は、新しい SA を生成します（図 5-18）。該当する SA
の情報が存在した場合には、その SA に関する情報を取り出します（図 5-19）。AH と ESP
の両方のプロトコルを組み合わせて使用する場合には、2 つの SA の情報を検索します。
①処理方法の
問い合わせ
⑤ SA の生成
を依頼
ポリシー
管理部
IPsec
処理部
⑥受信側 IKE と SA を
ネゴシエーション
受信側
IKE
IKE
④処理方法（破棄）
を返答
⑦ SA を登録
② SPD の検索
③ SAD の検索
（存在しない）
出力用 SPD
出力用 SAD
図 5-18 IPsec を適用する場合
（ SA が存在しなかった場合）の処理の流れ
①処理方法の
問い合わせ
IPsec
処理部
ポリシー
管理部
④処理方法（IPsec を適
用）と必要なパラメータ
を返答
② SPD の検索
③ SAD の検索
出力用 SPD
出力用 SAD
図 5-19 IPsec を適用する場合（SA が存在した場合）の処理の流れ
5.
AH と ESP の両方のプロトコルを組み合わせて使用する場合には、最初に ESP の処理を
行います。この時、ESP用のSAパラメータとして記述されている暗号化アルゴリズムや
暗号化用の共有秘密鍵、IV などを使用して ESP 処理を行います。ESP 処理が終了したら
96 ● 5 章 IPsec のアーキテクチャ
同様に AH 処理を行います。
6.
IPsec 処理が適用されたパケットを送信します。
5.6.2 IPsec 機器での入力処理
IP パケットが IPsec 機器に入力された場合には、次の IPsec 入力処理を適用します。
非 IPsec パケットの入力処理
IPsec が適用されていない IP パケットが入力された場合には、次の処理を行います。
1.
IPパケットの始点IPアドレス、終点IPアドレス、上位層プロトコル、ポート番号などの
セレクタをキーとして入力用 SPD からセキュリティポリシーを検索します（図 5-20）。
① IPsec ポリシーの
問い合わせ
ポリシー
管理部
IPsec
処理部
③ IPsec ポリシー
を返答
② SPD の検索
入力用 SPD
入力用 SAD
図 5-20 非 IPsec パケットが入力された場合の処理の流れ
2.
検索されたセキュリティポリシーが「破棄（discard）」であった場合には、IP パケットを
破棄します。また、「IPsec を適用（apply IPsec）」であった場合には、この IP パケットに
はIPsecが適用されていないため、このパケットを破棄します。そして、「IPsecを適用し
ない（bypass IPsec）」であった場合には、入力された IP パケットの状態と条件が合致す
るため、IP パケットを受信し、通常の処理を行います。
IPsec パケットの入力処理
IPsec が適用されているパケットが入力された場合には、次の処理を行います。
5.6 IPsec 処理の流れ ● 97
1.
入力された IPsec パケットに AH が適用されている場合には、AH ヘッダに含まれている
SPI 値と終点 IP アドレス（トンネルモードの場合は外側 IP ヘッダの終点 IP アドレス）、そ
して IPsec プロトコルの種類（AH）をキーとして、入力用 SAD から該当する SA の情報を
検索します。AHが適用されずにESPが適用されている場合には、ESPヘッダに含まれて
いるSPI値と終点IPアドレス（トンネルモードの場合は外側IPヘッダの終点IPアドレス）
、
そして IPsec プロトコルの種類（ESP）をキーとして、入力用 SAD から該当するSA の情報
を検索します（図 5-21）。
① 処理方法の
問い合わせ
ポリシー
管理部
IPsec
処理部
③ 処理に必要なパラ
メータを返答
② SADの検索
入力用SPD
入力用SAD
図 5-21 IPsec パケットが入力された場合の SAD 検索
2.
該当する SA の情報が存在しなかった場合には、IPsec パケットを破棄します。該当する
SA が存在した場合には、アルゴリズムや鍵を取り出して、AH または ESP の入力処理を
行います。AH と ESP の両方が適用されている場合には、AH の入力処理後に、ESP の入
力処理を行います。
3.
AH や ESP の入力処理が行われた後の IP パケットの始点 IP アドレス、終点 IP アドレス、
上位層プロトコル、ポート番号などのセレクタをキーとして入力用 SPD から該当するセ
キュリティポリシーを検索します
（図5-22）
。そして、検索されたセキュリティポリシーの
内容と適用されていたIPsec処理の内容が合致していることを確認します。セキュリティ
ポリシーの内容と適用されていたIPsec処理の内容が合致しない場合には、パケットを破
棄します。
4.
自身宛のIPパケットである場合には、データをトランスポート層に渡します。また、別
のホスト宛の IP パケットである場合には、そのホストに IP パケットを転送します。
98 ● 5 章 IPsec のアーキテクチャ
① IPsec ポリシーの
問い合わせ
ポリシー
管理部
IPsec
処理部
③ IPsec ポリシー
を返答
② SPD の検索
入力用 SPD
入力用 SAD
図 5-22 IPsec パケットが入力された場合の SPD 検索
5.6.3 トンネリング処理
ここでは、トンネルモード IPsec が使用された場合に追加するトンネル配送用 IP ヘッダの生
成方法とオリジナル IP ヘッダの処理方法について説明します。
カプセル化処理（トンネルモード IPsec 出力処理）
トンネルモードの IPsec 出力処理では、表 5-10 に示した規則にしたがってトンネル配送用 IP
ヘッダが生成され、オリジナル IP ヘッダが処理されます。ECN フィールドは、該当する SA の
ECN トンネル属性の内容（Forbidden または Allowed）によって処理方法が異なります†。
表 5-10 カプセル化時のオリジナル IP ヘッダおよびトンネル配送用ヘッダの処理
IPv4 ヘッダ
フィールド
IPv6 ヘッダ
フィールド
バージョン
バージョン
変更なし
（IPv4）
4
または 6
（IPv6）
ヘッダ長
─
変更なし
新たに作成
DS
DS
変更なし
オリジナル IP ヘッダの値をコピー
†
オリジナルIPヘッダ トンネル配送用 IP ヘッダ
（内側 IP ヘッダ） （外側 IP ヘッダ）
RFC 2401 では、トンネル配送用 IP ヘッダの TOS フィールド（IPv4 の場合）またはトラフィッククラ
スフィールド（IPv6 の場合）には、オリジナル IP ヘッダの内容をコピーするとなっていましたが、こ
れらのフィールドの上位 6 ビットが DS（Differentiated Services）フィールド、下位 2 ビットが ECN
（Explicit Congestion Notification）
フィールドとして再定義されたため、IPsecにおけるこれらのフィー
ルドの処理方法が変更されました [3]。
5.6 IPsec 処理の流れ ● 99
表 5-10 カプセル化時のオリジナル IP ヘッダおよびトンネル配送用ヘッダの処理（つづき）
IPv4 ヘッダ
フィールド
IPv6 ヘッダ
フィールド
オリジナルIPヘッダ トンネル配送用 IP ヘッダ
（内側 IP ヘッダ） （外側 IP ヘッダ）
ECN トンネル＝ Forbidden
（デフォルト）
ECN
ECN
変更なし
→“00”
にセット
ECN トンネル＝ Allowed
→“11”
以外の場合はオリジナル IP ヘッ
ダの値をコピー
→“11”
の場合は
“10”
にセット
パケット全体長
ペイロード長
変更なし
新たに作成
識別子
─
変更なし
新たに作成
フラグ
─
変更なし
MF フラグと予約フラグは 0
DF フラグの設定は実装依存
フラグメント
─
変更なし
新たに作成
（0 をセット）
TTL
中継限界数
1 減らす
新たに作成
プロトコル番号
次ヘッダ番号
変更なし
新たに作成
ヘッダチェックサム
─
再計算
新たに作成
始点 IP アドレス
始点 IP アドレス
変更なし
新たに作成
（トンネルの始点）
終点 IP アドレス
終点 IP アドレス
変更なし
新たに作成
（トンネルの終点）
─
フローラベル
変更なし
オリジナルの内容をコピー
または新たに作成
オフセット
カプセル解放処理（トンネルモード IPsec 入力処理）
トンネルモードのIPsec入力処理では、トンネル配送用IPヘッダは単に削除されます。また、
カプセル化されていたオリジナル IP ヘッダの各フィールドは表 5-11 のように処理されます。
ECNフィールドは、該当するSA のECNトンネル属性の内容（ForbiddenまたはAllowed）によっ
て処理方法が異なります。
表 5-11 カプセル解放時のオリジナル IP ヘッダの処理
IPv4 ヘッダ
フィールド
IPv6 ヘッダ
フィールド
オリジナル IP ヘッダ
（内側 IP ヘッダ）
バージョン
バージョン
変更なし
ヘッダ長
─
変更なし
100 ● 5 章 IPsec のアーキテクチャ
表 5-11 カプセル解放時のオリジナル IP ヘッダの処理（つづき）
IPv4 ヘッダ
フィールド
IPv6 ヘッダ
フィールド
DS
DS
オリジナル IP ヘッダ
（内側 IP ヘッダ）
変更なし
ECN トンネル＝ Forbidden（デフォルト）
ECN
ECN
→ 変更なし
ECN トンネル＝ Allowed
→ トンネル配送用ヘッダの値が "11" で、
オリジナル IP
ヘッダの値が "01" または "10" の場合は "11" をセット
→ それ以外の場合は変更なし
パケット全体長
ペイロード長
変更なし
識別子
─
変更なし
フラグ
─
変更なし
フラグメント
オフセット
─
変更なし
TTL
中継限界数
1 減らす
プロトコル番号
次ヘッダ番号
変更なし
ヘッダチェックサム
─
再計算
始点 IP アドレス
始点 IP アドレス
変更なし
終点 IP アドレス
終点 IP アドレス
変更なし
─
フローラベル
変更なし
5.6.4 リプレイ防御処理
IPsecでは、シーケンス番号とリプレイ防御ウィンドウを使用することで、リプレイ攻撃に対
する防御を行います。送信側ではパケットにシーケンス番号を付与して送信し、受信側ではリプ
レイ防御ウィンドウを使用して、受信されたパケットのシーケンス番号と既に受信されたパケッ
トのシーケンス番号を確認し、重複があった場合にはパケットを破棄します（図 5-23）。
リプレイ防御機能を有効とするかどうかは、受信側で決定されます。ただし、手動でSAを設
定する場合には、リプレイ防御機能は無効となります。また、リプレイ防御機能を有効にする場
合は、AH を使用するか、または ESP の認証機能を有効にすることによって、AH または ESP の
ヘッダを保護する必要があります。
5.6 IPsec 処理の流れ ● 101
受信可能パケット
#5
#4
受信済パケット
#3
#1
#2
送信側ホスト
受信側ホスト
#2
再送パケット
同じシーケンス番号
のため受信拒否
攻撃側ホスト
図 5-23 リプレイ攻撃からの防御
シーケンス番号
AH および ESP のヘッダには、32 ビットのシーケンス番号フィールドが存在します。新たに
SAが生成されると、シーケンス番号カウンタは0にセットされます。送信側は、IPsecパケット
を送信する際に、このシーケンス番号カウンタを1 増加させてから、AHヘッダまたはESP ヘッ
ダのシーケンス番号フィールドにその値をセットします（つまりSAが生成されてから最初に送信
する IPsec パケットのシーケンス番号フィールドには 1 がセットされることになります）。この
32
シーケンス番号カウンタは 2 でオーバーフローが発生するため、その前に新しく SA を生成す
る必要があります。ただし、受信側でリプレイ防御機能が無効とされていることがあらかじめ判
明している場合は、オーバーフローしてカウンタが一巡した場合でも引き続きSAを使用するこ
とができます。
リプレイ防御ウィンドウ
受信側では、シーケンス番号を検証するために、リプレイ防御ウィンドウを使用します。送信
側におけるシーケンス番号カウンタの管理とパケットへのシーケンス番号の付与は必須ですが、
受信側でのシーケンス番号の検証処理は必須ではなく、受信側の判断に任されます。
リプレイ防御ウィンドウは、図 5-24 に示すような 32 ビット以上のビットマスクとなります
（AH および ESP では 64 ビットが推奨されています）。リプレイ防御ウィンドウのビット位置は
シーケンス番号と対応しており、最近到着した IPsec パケットのシーケンス番号が一番右側の
ビット位置に対応します。つまり、IPsecパケットが到着する度に、リプレイ防御ウィンドウが
右にスライドしていくことになります。例えば、シーケンス番号がN+31のパケットが到着した
場合は、リプレイ防御ウィンドウの一番右側のビットに対応するシーケンス番号がN+31となり、
そのビットの値が 1 となります（図 5-24 の（a））。次に、シーケンス番号が N+34 の IPsec パケッ
102 ● 5 章 IPsec のアーキテクチャ
シーケンス番号
N
N+3
N+31
1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
（a） シーケンス番号が N+31 のパケットまでが到着している状態のリプレイ防御ウィンドウ
（シーケンス番号が N+3 のパケットは到着していない）
N
N+3
N+31
N+34
1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1
（b） シーケンス番号が N+34 のパケットが到着した場合のリプレイ防御ウィンドウ
（シーケンス番号が N+3、N+32、N+33 のパケットは到着していない）
N
N+4
N+31
N+35
1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 1
（c） シーケンス番号が N+35 のパケットが到着した場合のリプレイ防御ウィンドウ
（シーケンス番号が N+3、N+32、N+33 のパケットは到着していない）
図 5-24 リプレイ防御ウィンドウの例
（32 ビットの場合）
トが到着した場合には、リプレイ防御ウィンドウが3つ右側にスライドし、一番右側のビットに
対応するシーケンス番号はN+34となります（図5-24の（b））。この場合、シーケンス番号がN+32
および N+33 の IPsec パケットはまだ到着していないため、それに対応するリプレイ防御ウィン
ドウのビットの値は0のままとなります。リプレイ防御ウィンドウのビットの値が0となってい
るシーケンス番号の IPsec パケットが到着した場合は、その IPsec パケットは受理され、対応す
るビットは1となります。ただし、リプレイ防御ウィンドウのビットが1となっているシーケン
ス番号の IPsec パケットが到着した場合は、その IPsec パケットはすでに受信されていると解釈
し、受信を拒否します。このようにしてリプレイ攻撃からの防御を実現しています。
ここで、シーケンス番号がN+3のIPsecパケットが到着していない状態でシーケンス番号N+35
のIPsecパケットが到着した場合を考えてみます。この場合、リプレイ防御ウィンドウは右にス
ライドし、一番右側のビットに対応するシーケンス番号がN+35となりますが、このリプレイ防
御ウィンドウは 32 ビットであるため、シーケンス番号 N+3 に対応するビットは、リプレイ防御
ウィンドウの範囲から外れてしまいます（図5-24の（c））。このようにシーケンス番号がリプレイ
防御ウィンドウの範囲外になった場合は、そのシーケンス番号の IPsec パケットが到着しても、
受信を拒否します。
このリプレイ防御ウィンドウのC言語によるサンプルコードがRFC 2401に付属していますの
5.6 IPsec 処理の流れ ● 103
で参考にするとよいと思います。
シーケンス番号フィールドの保護
シーケンス番号とリプレイ防御ウィンドウによってリプレイ攻撃からの防御が可能となります
が、リプレイ攻撃を行う者が、再送するIPsecパケットのシーケンス番号を、まだ受信されてい
ないシーケンス番号に改ざんした場合には、受信側がリプレイ防御機能を有効にしていても、そ
の再送パケットが受信されてしまう可能性があります。特に、攻撃者が非常に大きなシーケンス
番号を持った IPsec パケットを送信した場合には、受信側がその IPsec パケットを受信してしま
うばかりでなく、そのシーケンス番号にあわせてリプレイ防御ウィンドウが大きくスライドして
しまうため、その後に到着した正規のIPsecパケットの持つシーケンス番号がリプレイ防御ウィ
ンドウ内に収まらなくなり、受信側でこの正規のIPsecパケットを破棄してしまう可能性があり
ます。
このような事態を防ぐために、シーケンス番号が改ざんされないようにシーケンス番号フィー
ルドを保護する必要があります。AH を使用した場合や ESP で認証機能を有効にした場合には、
シーケンス番号フィールドが保護されますが、ESPを単独で使用した場合で、ESPの認証機能を
有効にしない場合には、シーケンス番号を保護することができません。これは非常に危険な状態
です。ESPを使用する場合には、ESPの認証機能を利用するか、またはAHを組み合わせてシー
ケンス番号を保護する必要があります。
コラム： シーケンス番号は 32 ビットで十分か？
現在の仕様では、自動鍵交換プロトコルを使用する場合は、シーケンス番号がオーバーフ
ローする前に新しい SA を生成しなければならないことになっています。シーケンス番号
フィールドは32ビットと定義されているため、（232−1）個のパケットを送信するとSAを再
生成しなければならないことになります。果たして、このシーケンス番号フィールドの長さ
は妥当なのでしょうか。現在のネットワークではこの値は妥当かもしれません。しかし、将
来使用されると予想される 10Gbps クラスの超高速ネットワークで 64 バイト程度の小さい
パケットを送信し続けた場合を想定すると、数分でシーケンス番号がオーバーフローしてい
まい、短い時間でSAを再生成しなければならない計算になります。このため、IETFのIPSEC
WGでは、32ビットのシーケンス番号を48ビットや64ビットに拡張できるようにするため
の議論が行われています。
104 ● 5 章 IPsec のアーキテクチャ
コラム： DS フィールドのトンネルヘッダへのコピー
現在の IPsec の仕様 [1, 3] では、トンネルモード IPsec を適用する場合に、トンネル配送
用の IP ヘッダにオリジナルの IP ヘッダの DS（Differentiated Services）フィールド（IPv4 の
TOS フィールドの上位 6 ビットまたは IPv6 のトラフィッククラスフィールドの上位 6 ビッ
ト）の内容をコピーすることになっています。DSフィールドには、DiffServ（Differentiated
Services）で使用するIPパケットの転送に関する品質を制御するための値が入ります。この
フィールドをトンネルIPヘッダにコピーすることにより、IPsecでカプセル化されたパケッ
トにもオリジナルのパケットと同様の QoS 制御を行うことが可能となりますが、これに反
対する意見もあります。
IPsecにはESPのトンネルモードを利用することによって、トラフィックフローの機密性
を確保することができるという特徴がありますが、これらのフィールドをトンネル配送用の
IP ヘッダにコピーすることによって、カプセル化された IP パケットに求められるトラ
フィック品質がトンネル配送中に外部に露呈してしまうという問題が発生します。また、さ
らに深刻なのは、同じSAのパケットに対して異なるQoS制御が行われると、大きいシーケ
ンス番号を持つパケットが先に送信された小さいシーケンス番号を持つパケットよりも先に
到着してしまい、最悪の場合には、遅く到着したパケットの持つシーケンス番号が受信者の
持つリプレイ防御ウィンドウ内に収まらず、パケットが破棄されてしまう可能性があること
です。このため、この DS フィールドをトンネル配送用の IP ヘッダにコピーするという現
在の仕様は、次回の仕様では改定されるものと思われます。
5.6.5 IPsec におけるフラグメント処理
IPsec では、通常の IP パケットに AH ヘッダや ESP ヘッダ（および ESP トレーラ）などを付加
するため、IPパケットのサイズが大きくなります（トンネルモードを利用した場合にはトンネル
用の IP ヘッダも加わるため、さらに大きくなります）。このため、IPsec 処理を適用した後の IP
パケットの大きさがMTU値を超えてしまい、フラグメントが発生する可能性があります。フラ
グメントが発生すると、フラグメントの分割や再構成に費やす処理が負担となり、全体のスルー
プットが低下してしまうため、なるべくフラグメントを発生させないようにする必要があります。
IPsec 処理とフラグメント処理の順序
フラグメントされたパケットに IPsec 処理を適用する場合には、IPsec 処理の前にフラグメン
ト再構成処理が行われます。また、フラグメント分割が必要な場合はIPsec処理の後にフラグメ
5.6 IPsec 処理の流れ ● 105
ント分割処理が行われます
（図5-25）
。このため、フラグメント再構成処理やフラグメント分割処
理をなるべく発生させないようにするためには、セキュリティゲートウェイなどのトンネルモー
ド IPsec 処理を行う機器に、フラグメントされた状態のパケットや、IPsec 処理によってフラグ
メントされてしまうようなサイズのパケットを送信しないことが必要となってきます。
IPsec 層
IP 層
トンネルモード IPsec 処理
フラグメント
再構成処理
フラグメント
分割処理
フラグメントパケット
フラグメントパケット
図 5-25 セキュリティゲートウェイにおけるフラグメント処理
経路 MTU 探索
イーサネットに接続されている場合の MTU 値は、通常 1,500 バイトとなりますが、宛先にパ
ケットが届くまでの間に、MTU値がさらに小さいネットワークを通る可能性があります。この
場合には、1,500バイト以下のパケットでもフラグメントが発生する可能性があります。このた
め、宛先に到達するまでの経路上で最も小さい MTU 値（経路 MTU 値：Path MTU）を調べるた
めに、経路 MTU 探索が行われます。
経路 MTU 探索には、ICMP 経路 MTU メッセージが使用されます。ICMP 経路 MTU メッセー
ジには、IPv4 では、ICMP タイプ 3（終点到達不能）のコード 4（分割必要かつ DF フラグセット）
メッセージが使用され、IPv6 では、ICMPv6 タイプ 2（パケット過大）のコード 0（分割必要）メッ
セージが使用されます。パケットの配送中にフラグメント処理が必要になった場合には、ICMP
経路 MTU メッセージが送信元に返されます。ICMP 経路 MTU メッセージには、次中継点 MTU
値と該当するパケットの情報が含まれているため、送信元ホストはこの情報によって該当する宛
先に送信する場合の経路 MTU 値を知ることが可能となります。
IPsec が適用されたパケットに対する経路 MTU 探索
IPsec を適用したパケットによって、ICMP 経路 MTU メッセージが発生した場合には、IPsec
処理されたパケットの一部と次中継点 MTU 値が IPsec 機器に返されます。IPsec 機器がセキュ
リティゲートウェイである場合には、この情報を送信元であるホストに転送する必要があります
106 ● 5 章 IPsec のアーキテクチャ
が、ICMP 経路MTU メッセージには、暗号化されたパケットのデータが含まれているため、送
信元ホストを簡単に特定することができません。しかし、ICMP 経路MTU メッセージの仕様で
は、フラグメントを必要としたパケットのIPヘッダに加えて最低64バイトのデータを含むこと
になっているため、AH および ESP のどちらの場合でも、SPI フィールドまでは必ず含まれるこ
とになります。そこで、トンネルの終点IPアドレスとIPsecプロトコルの種類、SPI値をキーと
して、SADから該当するSAの情報を検索し、送信元ホストを絞り込みます。送信元ホストが絞
り込めた場合は、IPsec が追加するヘッダの量を考慮して経路 MTU 値を計算し、当該ホストへ
ICMP 経路 MTUメッセージを送信します。送信元ホストと考えられるホストが複数存在する場
合は、その可能性のあるホストのすべてにICMP経路MTUメッセージを送信します。送信元ホ
ストを特定できなかった場合は、経路MTU値をSADの該当するエントリに保存します（SAパラ
メータには経路 MTU 値を設定するための属性が存在します）。セキュリティゲートウェイに到
着した IP パケットの大きさが、該当する SA の経路 MTU 値を超えていた場合には、その送信元
ホストへ ICMP 経路 MTU メッセージが送信されます。
IPsec 機器における経路 MTU 情報の管理
これまでに説明したように、IPsec機器では、SAごとに経路MTU値を更新し、保持する必要
があります。しかし、この経路MTU値は変化する可能性があるため、SAごとに経路MTU値の
エージング（古くなったら無効とすること）を行います。
また、トンネルモードIPsecでは、トンネル配送用IPヘッダのDFフラグ
（Don’t Fragment Flag：
フラグメント禁止フラグ）をどのように設定するかは実装依存となっています。この DF フラグ
の扱いは次のいずれかになります。
DF フラグをセットする
DF フラグをセットしない
オリジナル IP ヘッダの DF フラグの内容をコピーする
IPsec 機器で DF フラグをセットする場合は、経路 MTU 値を送信元ホストまで伝播させる仕
組みが必要となります。途中のファイアウォールなどでICMP経路MTUメッセージが破棄され
た場合や、セキュリティゲートウェイでICMP経路MTUメッセージを正しく処理できない場合
には、ICMP 経路MTU メッセージが送信元ホストまで伝播されないため、永久にパケットが宛
先に届かない状態となってしまいます。また、IPsec 機器で DF フラグをセットしない設定にし
た場合は、ICMP経路 MTU メッセージが生成されず、フラグメントが発生してしまい、スルー
プットが低下してしまう可能性があります。オリジナルのIPヘッダのDFフラグの内容をコピー
する設定にした場合には、両方の問題が発生します。
5.7 IPsec の実装 ● 107
5.7 IPsec の実装
IPsec は、IP 層で動作するプロトコルであるため、IPsec を既存のシステムに実装する場合に
は、IP 処理部を修正する必要があります。しかし、実際には IP 処理部を修正するのは困難な場
合も多いため、さまざまな実装法が提案されています。
ネイティブ IP スタックへの統合
TCP/IP スタックのソースコードにアクセスし、IP 処理のコードに IPsec 処理のコードを加え
る方式です（図5-26）。ソースコードを保持するOSの開発元が実装する場合や、オープンソース
の OS に対して第三者がパッチを開発する場合などがあります。
アプリケーション
アプリケーション
TCP/UDP
TCP/UDP
IP
IP+IPsec
データリンク層
データリンク層
IPsec 処理部
を統合
図 5-26 ネイティブ IP スタックへの統合
Bump-in-the-stack（BITS）
Bump-in-the-stack
（BITS）
は、IPsec処理部をIP処理部とデータリンク層処理部の間に実装する
方式です
（図5-27）
。この方式では、オリジナルのIP処理部に手を加えることはしないため、ソー
スコードにアクセスする必要はなく、ソースコードの修正による動作上のトラブルを抑えること
が可能となります。
Bump-in-the-wire（BITW）
Bump-in-the-wire（BITW）
は、ホストとは別の機器上でIPsec処理を適用する方式です
（図5-28）
。
この方式を利用すると、ホストの TCP/IP スタックやアプリケーションを変更することなく、
IPsec を利用できるようになります。
108 ● 5 章 IPsec のアーキテクチャ
アプリケーション
アプリケーション
TCP/UDP
TCP/UDP
IP
IP
データリンク層
IPsec
IPsec 処理部
を挿入
データリンク層
図 5-27 Bump-in-the-stack（BITS）実装
IPsec 対応機器
IPsec 対応機器
図 5-28 Bump-in-the-wire（BITW）実装
参考文献
[1] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401,
November 1998.
[2] R. Thayer, N. Doraswamy, and R. Glenn, “IP Security Document Roadmap”, RFC 2411,
November 1998.
[3] K. Ramakrishnan, S. Floyd, and D. Black, “The Addition of Explicit Congestion Notification
(ECN) to IP”, RFC 3168, September 2001.
109
6章
● AH の機能
● AH プロトコルフォーマット
● 認証アルゴリズム
● AH 処理の流れ
認証ヘッダ（AH）
認証ヘッダ（AH：Authentication Header）は、機密性の確保が必要とされない IP パケットに対
して、送信元の認証と完全性を確保するセキュリティプロトコルです。多くの場合、機密性を確
保することが可能な暗号ペイロード（ESP：Encapsulating Security Payload）が使用されますが、
AHには、ESPにはないパケット配送用のIPヘッダを保護できるという特徴があります。この章
では、AH の機能と処理の詳細について説明します。
6.1 AH の機能
認証ヘッダ（AH）[1] は、IP パケットのコネクションレス完全性を確保し、送信元を認証する
機能を提供します。また、オプションでリプレイ攻撃からの防御機能を提供します。
7 章「暗号ペイロード（ESP）」で説明する暗号ペイロード（ESP）には、暗号化によるデータの
機密性の確保に加えて、完全性の確保と送信元の認証の機能がありますが、AHには、完全性を
確保できる範囲が ESP よりも広いという特徴があります。
コネクションレス完全性の確保
AH ヘッダに含まれている完全性チェック値（ICV：Integrity Check Value）を検証することで、
IP ヘッダ（トンネルモードの場合にはトンネル配送用の IP ヘッダ）の一部と IP ペイロード部（ト
ンネルモードの場合はカプセル化されたIPパケット）全体の完全性を確保することが可能となり
ます。ここで、IPヘッダの一部というのは、配送中に中間のルータなどによって変更されないIP
ヘッダのフィールドを指します。中間のルータなどによって変更されてしまうフィールドには、
TTL（IPv6では中継限界数）や TOS（IPv6ではトラフィッククラスおよびフローラベル）、チェッ
110 ● 6 章 認証ヘッダ（AH）
クサムなどがありますが、これらのフィールドは AH で保護することはできません。
データ送信元の認証
AH ヘッダに含まれている ICV を検証すると、その IP パケットが、事前に安全な方法で共有
された共有秘密鍵を持つ相手から送信されたものであることを確認することができます。
リプレイ防御
AHヘッダに含まれているシーケンス番号をチェックすることで、再送されたパケットの受信
を拒否することが可能となります。このリプレイ防御の機能はオプションです。
6.2 AH プロトコルフォーマット
ここでは、AH のヘッダフォーマットと AH ヘッダが挿入される位置について説明します。
6.2.1 AH のヘッダフォーマット
AH のヘッダフォーマットは図 6-1 のようになっています。
次ヘッダ番号フィールド
次ヘッダ番号フィールドは、8 ビットの固定長フィールドです。このフィールドには、AH
の次に挿入されるヘッダの IP プロトコル番号が入ります。
0
8
次ヘッダ番号
16
ペイロード長
31
予約
セキュリティパラメータインデックス（SPI）
シーケンス番号
認証データ（可変長：32ビットの倍数）
図 6-1 AH のヘッダフォーマット
6.2 AH プロトコルフォーマット ● 111
ペイロード長フィールド
ペイロード長フィールドは、8ビットの固定長フィールドです。このフィールドには、32ビッ
トワード単位（1 ワードは 32 ビット）での AH ヘッダの長さから2 を引いた値が入ります。例
えば、96ビットの認証データが使用される場合には、AHヘッダの長さは192ビットとなる
ため、32 ビットワード単位では 6 ワードとなります。この値から 2 が引かれるため、ペイ
ロード長フィールドには 4 が入ります。
予約フィールド
予約フィールドは、16 ビットの固定長フィールドです。このフィールドは将来の利用のた
めに予約されており、すべてのビットが 0 にセットされている必要があります。
セキュリティパラメータインデックス
（SPI）
フィールド
セキュリティパラメータインデックス（SPI）
フィールドは、32ビットの固定長フィールドで
す。このフィールドには、SA を識別するための SPI 値が入ります。
表6 -1に、SPI値の範囲とその用途を示します。256以上の値であれば、手動でのSA設定お
よびIKEなどによる自動でのSA設定のどちらでも使用することができますが、実装によっ
ては、256 ∼ 4,095 を手動設定用、4,096 以上を自動設定用に使用している場合があります。
1 ∼ 255 の SPI 値は将来の利用のために予約されているため、現時点ではこれらの値を使用
することはできません。また、SPI値0は、ローカルでの利用のために予約されているため、
この値も通常は使用することができません。
表 6-1 SPI 値の範囲と用途
SPI値
用途
0
ローカルでの利用
1∼255
予約
256∼
手動および自動設定用
シーケンス番号フィールド
シーケンス番号フィールドは、32ビットの固定長フィールドです。このフィールドには、パ
ケットを送信する際に1ずつ増加するシーケンス番号が入ります。このシーケンス番号は、
SAが生成された際に0に初期化されるため、SA生成後の最初のパケットに含まれるシーケ
ンス番号は 1 となります。
112 ● 6 章 認証ヘッダ（AH）
認証データフィールド
認証データフィールドには、このパケットに対する完全性チェック値
（ICV）
が入ります。こ
のフィールドは可変長ですが、AHヘッダ全体の長さは、IPv4の場合は32ビットの整数倍、
IPv6 の場合は 64 ビットの整数倍である必要があるため、ICV の後に必要に応じてパディン
グを挿入してAHヘッダ全体の長さを調整します。このパディングに使用される値は、送信
者が任意に決定することが可能です。ただし、現在までに定義されている認証アルゴリズム
は、96 ビットの ICV を出力するため、この場合には、AH ヘッダ全体の長さが 64 ビットの
整数倍となり、IPv4 および IPv6 のどちらでもパディングは必要とされません。
6.2.2 AH ヘッダが挿入される位置
表 6 -2 に、AH ヘッダが挿入される位置を示します。AH ヘッダは、IPv4 では IPv4 ヘッダの後
トランスポート層ヘッダの前に挿入されます。IPv6 では、AH ヘッダは終点間ペイロード（IP パ
ケットの終点でのみ使用され、途中のルータなどでは使用されない）
であるため、経路制御ヘッダ
などの配送途中で使用される拡張ヘッダの後に挿入されます。
表 6-2 IPv6 および IPv4 における AH ヘッダの位置
ヘッダ番号
IPv6 におけるヘッダ順序
IPv4 におけるヘッダ順序
−
IPv6 ヘッダ
IPv4 ヘッダ
0
中継点オプションヘッダ
─
60
終点オプションヘッダ
─
43
経路制御ヘッダ
─
44
フラグメントヘッダ
─
51
認証ヘッダ
（AH）
50
暗号ペイロード
（ESP）
108
IPComp ヘッダ
60
6、17 など
終点オプションヘッダ
─
トランスポート層ヘッダ
（TCP、UDP など）
※ 終点オプションヘッダは、通常はIPv6拡張ヘッダの最後（トランスポート層ヘッダの前）
に現れますが、経路制御ヘッダの前に現れる場合もあります。
6.3 認証アルゴリズム ● 113
6.3 認証アルゴリズム
AH では、認証アルゴリズムとして HMAC-MD5-96 と HMAC-SHA-1-96 の実装が必須となって
います。この他の認証アルゴリズムには、HMAC-RIPEMD-160-96、DES-MAC、Keyed-MD5 な
どがあります。ここでは、これらの認証アルゴリズムを紹介します。これらのアルゴリズムの詳
しい仕組みについては、「2.5 メッセージ認証コード（MAC）」なども参考にしてください。
6.3.1 HMAC-MD5-96
HMAC-MD5-96 は、ハッシュ関数として MD5 を使用した HMAC の出力（128 ビット）の最初の
96 ビット分を認証データ（ICV）として使用する認証アルゴリズムです。図 6-2 に、HMAC-MD596 による ICV の計算法を示します。HMAC-MD5-96 では、128 ビットの共有秘密鍵を使用しま
す。HMAC-MD5-96は実装上必須の認証アルゴリズムであるため、すべての実装で利用可能とな
ります。HMAC-MD5-96 の使用法は、RFC 2403 [2] に記述されています。
共有秘密鍵 K
（128 ビット）
ipad との XOR
opad との XOR
共有秘密鍵 K1
（64 バイト）
共有秘密鍵 K2
（64 バイト）
直前に付加
直前に付加
IP ヘッダ
AH ヘッダ
MD5
ハッシュ値
を計算
データ
MD5
ハッシュ値 H1
（128 ビット）
ハッシュ値 H2
（128 ビット）
ICV
（96 ビット）
ハッシュ値
を計算
ipad : 0x36363636…36（64 バイトの定数）
opad : 0x5c5c5c5c…5c（64 バイトの定数）
図 6-2 HMAC-MD5-96 による ICV の計算
6.3.2 HMAC-SHA-1-96
HMAC-SHA-1-96 は、ハッシュ関数として SHA-1 を使用した HMACの出力（160 ビット）の最初
の 96 ビット分を認証データ（ICV）として使用する認証アルゴリズムです。ICV の計算の手順は
HMAC-MD5-96と同様です。ただし、HMAC-SHA-1-96では160ビットの共有秘密鍵が使用され、
ハッシュ値も 160 ビットとなります。HMAC-SHA-1-96 は実装上必須の認証アルゴリズムである
ため、すべての実装で利用可能となります。HMAC-SHA-1-96の使用法は、RFC 2404 [3] に記述
114 ● 6 章 認証ヘッダ（AH）
されています。
6.3.3 HMAC-RIPEMD-160-96
HMAC-RIPEMD-160-96 は、ハッシュ関数として RIPEMD-160 を使用した HMAC の出力（160
ビット）の最初の96ビット分を認証データ（ICV）として使用する認証アルゴリズムです。ICVの
計算の手順は HMAC-MD5-96 と同様です。ただし、HMAC-RIPEMD-160-96 では 160 ビットの共
有秘密鍵が使用され、ハッシュ値も 160 ビットとなります。HMAC-RIPEMD-160-96 は実装上必
須の認証アルゴリズムではないため、すべての実装で利用可能であるとは限りません。HMACRIPEMD-160-96 の使用法は、RFC 2857 [4] に記述されています。
6.3.4 DES-MAC
DES -MACは、認証対象となるデータをDESで暗号化し、暗号文の最後の1ブロック分
（64ビッ
ト）
を認証データ
（ICV）として使用する認証アルゴリズムです。DES -MACは実装上必須の認証ア
ルゴリズムではなく、現在は使用されていません。この DES -MAC についての詳細は、以前イン
ターネットドラフトとして発行されましたが、現在は文書化されていません。
6.3.5 AES-MAC
暗号化に高速な AES が使用されるようになると、HMAC-MD5 や HMAC-SHA-1 などの認証ア
ルゴリズムの処理速度が問題となってきます。そこで、高速処理が可能なAES -MACが提案され
ています。AES -MAC は、DES -MAC と同様の手順で ICV を計算します（ただし、AES -MAC の
出力は 128 ビットであるため、おそらく HMAC-MD5-96 や HMAC-SHA-1-96 と同様に 96 ビット
まで省略されると思われます）。AES -MAC は、実質的に AES -CBC の暗号化処理と同じ速度で
計算することができるため、AESによる暗号化処理が使用された場合でも認証処理がボトルネッ
クとなることはありません。AES -MACは、本書執筆時点ではまだ仕様が確定しているわけでは
ありませんが、AESが暗号化に使用される際には、共に使用されることになる認証アルゴリズム
となると考えられています。
6.3.6 Keyed-MD5（KPDK）
IPsec バージョン 1 では、AH の必須の認証アルゴリズムとして、Keyed-MD5 が指定されてい
ました。図6-3に示すように、Keyed-MD5では、認証鍵
（Key）
、パディング
（Pad）
、データ
（Data）
、
認証鍵
（Key）の順番で配置したデータに対してMD5によりハッシュを計算し（このためそれぞれ
の頭文字を順番につなげてKPDKと呼ばれます）、その結果をICVとして使用します。このアル
ゴリズムは、互換性を保つためにIKEにおいて折衝できるようになっていますが、現在は使用さ
6.3 認証アルゴリズム ● 115
共有秘密鍵 K
+ パディング
（512 ビット）
直前に付加
IP ヘッダ
AH ヘッダ
MD5
ICV
（128 ビット）
ハッシュ値
を計算
データ
直後に付加
共有秘密鍵 K
図 6-3 Keyed-MD5（KPDK）による ICV の計算
コラム： 認証データの省略
実装上必須とされている HMAC-MD5-96やHMAC-SHA-1-96は、それぞれ128ビットおよ
び 160 ビットのハッシュ関数の出力を 96 ビットにまで省略しています。実はこれには理由
があります。古いバージョンのAH（RFC 1826）では、シーケンス番号フィールドが存在しな
かったため、AHヘッダの認証データフィールド以外の部分は64ビットでした。これにMD5
の出力である 128 ビットを足すと AH ヘッダ全体の長さが 192 ビットとなり、ちょうど 64
ビットの整数倍となります。しかし、新しいバージョンのAH（RFC 2402）では、32 ビット
のシーケンス番号フィールドが追加されたため、128 ビットの出力をそのまま使用すると
AHヘッダ全体の長さが224ビットとなり、64ビット境界に収まりません。IPv6では、拡張
ヘッダの長さは64ビット境界に収まることが条件となっているため、この条件を満たすた
めには、認証データに 32 ビットのパディングを足して AH ヘッダ全体の長さを 256 ビット
にする必要があります。しかし、これでは余分なデータによってヘッダが大きくなってしま
います。そこで、新しいバージョンの AH では MD5 の出力を 32 ビット分削り、96 ビット
とすることで、ヘッダ全体が64ビット境界に収まるようにしています。SHA-1やRIPEMD160を使用した場合は160ビットの認証データを出力するため、そのまま利用してもヘッダ
全体は 64 ビット境界に収まるのですが、160 ビットの認証データをそのまま利用するより
も、ある程度データを削った方が逆に攻撃者に与える情報が少なくなり、安全になる（そし
てヘッダの量も少なくて済む）という理由もあって、MD5 と同様に 96 ビットまで削るよう
にしています。
116 ● 6 章 認証ヘッダ（AH）
れません。Keyed-MD5 についての詳細は、RFC 1828 [5] に記述されています。
6.4 AH 処理の流れ
ここでは、送信側および受信側における AH の処理について説明します。
6.4.1 送信側における処理（AH 出力処理）
パケットに AH を適用して送信する場合には、次の順序で AH 出力処理を行います。
セキュリティポリシーの検索
送信するパケットの始点IPアドレス、終点IPアドレス、プロトコルなどのセレクタをキーと
して出力用 SPD から該当するセキュリティポリシーを検索します。
セキュリティアソシエーションの検索
セキュリティポリシーで AH を使用するように指定されている場合には、出力用 SAD から、
該当する SA を検索します。有効な SA が存在しない場合には、IKE によって新たに SA を生成
します。
AH ヘッダの挿入
トランスポートモードが使用されている場合には、IPヘッダとトランスポート層ヘッダの間の
指定された位置に AH ヘッダを挿入します。また、トンネルモードが使用されている場合には、
トンネル配送用の新しい IP ヘッダと AH ヘッダを作成し、その後にカプセル化される IP パケッ
トを続けます。AHヘッダの認証データフィールドの長さは、SAで指定された認証アルゴリズム
が出力する認証データの長さに合わせて確保されます。そして、AH ヘッダの次ヘッダ番号
フィールド、ペイロード長フィールド、予約フィールド、SPIフィールドに適切な値を入れます。
また、トンネルモードの場合は、カプセル化される IP パケットの IP ヘッダの TTL（IPv6 の場合
は中継限界数）を 1 減少させ、チェックサムを再計算します。
シーケンス番号の生成
該当する SA のシーケンス番号カウンタを 1 増加し、増加した値を AH ヘッダのシーケンス番
号フィールドに入れます。
シーケンス番号カウンタを増加させた際にカウンタが一巡した場合は、パケットを送信する前
にIKEによって新しいSAを生成する必要があります。ただし、手動鍵管理の場合のように、リ
6.4 AH 処理の流れ ● 117
プレイ防御機能が無効である場合は、カウンタが一巡した場合でも、引き続きそのSAを使用す
ることが可能です。
完全性チェック値（ICV）の計算
該当する SA で指定されている認証アルゴリズムと鍵を使用して、AH ヘッダを挿入した後の
IPパケットに対する完全性チェック値（ICV）を計算します。しかし、AHヘッダよりも前（下位）
に位置するヘッダには、配送中にその値が変更されるフィールドが存在する可能性があります。
これらのフィールドも含めて ICV を計算してしまうと、途中でその値が変更された場合には、
ICVの検証に失敗してしまいます。このため、ICVの計算時には、これらのフィールドにすべて
0が含まれているとして計算します。配送中に変更される可能性のあるフィールドは、IPv4基本
ヘッダ、IPv4 オプション、IPv6 ヘッダ、IPv6 拡張ヘッダに存在します。
AHヘッダ自身もICVの計算に含まれます。ICVの計算時には、AHヘッダの認証データフィー
ルドはすべて0であるとして計算します。しかし、ICVの後にパディングが付加される場合には、
そのパディングはICVの計算に含めるようにします。このパディングに使用される値は送信側が
任意に決定することが可能です。トランスポートモードAHにおける認証の範囲を図6 - 4に、ト
ンネルモード AH における認証の範囲を図 6 -5 に示します。
ICV の計算に含める IPv4 基本ヘッダのフィールドを図 6 - 6 に示します。バージョン、ヘッダ
長、識別子、プロトコル、始点IPアドレスの各フィールドは、配送中も不変であるため、ICVの
計算に含めます。また、パケット全体長は、配送中にフラグメントが生じた場合は、そのフラグ
プロトコル 次ヘッダ
=AH
=TCP
IPv4
ヘッダ
AH
ヘッダ
TCP
ヘッダ
データ
認証の範囲
次ヘッダ 次ヘッダ
=AH
= 終点オプション
IPv6
ヘッダ
経路制御
ヘッダ
AH
ヘッダ
終点
オプション
ヘッダ
TCP
ヘッダ
データ
認証の範囲
図 6-4 トランスポートモード AH の認証の範囲（網掛部は配送中不変）
118 ● 6 章 認証ヘッダ（AH）
プロトコル 次ヘッダ
=AH
=IPv4
トンネル
IPv4
ヘッダ
AH
ヘッダ
IPv4
ヘッダ
TCP
ヘッダ
データ
認証の範囲
次ヘッダ
=AH
次ヘッダ
=IPv6
トンネル
IPv6
ヘッダ
AH
ヘッダ
IPv6
ヘッダ
終点
経路制御
オプション
ヘッダ
ヘッダ
TCP
ヘッダ
データ
認証の範囲
図 6-5 トンネルモード AH の認証の範囲（網掛部は配送中不変）
0
4
8
バージョン ヘッダ長
14
DS
19
31
パケット全体長
ECN
識別子
TTL
16
フラグ
プロトコル番号
フラグメントオフセット
ヘッダチェックサム
始点 IP アドレス
終点 IP アドレス
図 6-6 ICV の計算に含まれる IPv4 基本ヘッダのフィールド（網掛部）
メントパケットの長さに調整されますが、終点でのAH処理の前にフラグメントが再構成される
ため、このパケット全体長フィールドの値は元の値に戻ります。このため、パケット全体長
フィールドも ICV の計算に含めます。また、終点 IP アドレスは、経路制御オプションが使用さ
れている場合には、配送中に変更されますが、終点ノードに到着した時点では、終点の IP アド
レスとなることが予測できるため、ICVの計算時には終点のIPアドレスを入れて計算します。DS
フィールドおよびECNフィールド（サービスタイプ（TOS）フィールド）は、ルータによって変更
される可能性があるため、ICV の計算には含めません。また、MF フラグ（フラグメント継続フ
ラグ）やフラグメントオフセットは、終点での AH 処理の際には必ず 0 となるため、ICV の計算
には含めません。DFフラグ（フラグメント禁止フラグ）、TTL、ヘッダチェックサムの各フィー
6.4 AH 処理の流れ ● 119
表 6-3 ICV の計算時における IPv4 オプションの扱い
オプション番号
IPv4 オプション
値の変化
ICV の計算
0
End of Options List
配送中不変
含まれる
1
No Operation
配送中不変
含まれる
2
Security
配送中不変
含まれる
3
Loose Source Route
配送中変更される
含まれない
4
Time Stamp
配送中変更される
含まれない
5
Extended Security
配送中不変
含まれる
6
Commertial Security
配送中不変
含まれる
7
Record Route
配送中変更される
含まれない
9
Strict Source Route
配送中変更される
含まれない
18
Traceroute
配送中変更される
含まれない
20
Router Alert
配送中不変
含まれる
21
Sender Directed Multi-Destination Delivery
配送中不変
含まれる
ルドは、配送途中で変更される可能性があり、終点での値を予測することができないため、ICV
の計算には含めません。
また、IPv4 のオプションに関しては、配送中に変更されるものと変更されないものがありま
す。しかし、それを見分けるためのフラグなどは存在しないため、ICV の計算に含まれるオプ
ションは、あらかじめ AH の仕様で表 6-3 のように決められています。
ICV の計算に含まれる IPv6 ヘッダのフィールドは図 6-7 のようになります。バージョン、次
ヘッダ、始点IPアドレスの各フィールドは、配送中も不変であるため、ICVの計算に含めます。
また、ペイロード長は、配送中にフラグメントが生じた場合は、そのフラグメントパケットの長
さに変更されますが、終点でのAH処理の前にフラグメントが再構成されるため、このペイロー
ド長フィールドの値は元の値に戻ります。このため、ペイロード長フィールドもICVの計算に含
めます。また、終点 IP アドレスは、経路制御オプションが使用されている場合には、配送中に
変更されますが、終点ノードに到着した時点では、終点の IP アドレスとなることが予測できる
ため、ICVの計算時には終点のIPアドレスを入れて計算します。DSフィールドおよびECNフィー
ルド
（トラフィッククラスフィールド）
、フローラベルフィールド、中継限界数フィールドは、途
中のルータによって変更される可能性があり、終点での値を予測することができないため、ICV
の計算には含めません。
120 ● 6 章 認証ヘッダ（AH）
0
バージョン
4
10
DS
ペイロード長
12
16
24
31
フローラベル
ECN
次ヘッダ番号
中継限界数
始点 IP アドレス
終点 IP アドレス
図 6-7 ICV の計算に含まれる IPv6 ヘッダのフィールド（網掛部）
IPv6拡張ヘッダは、配送中に変更されるものと変更されないものが存在します。ICVの計算に
含まれるIPv6拡張ヘッダは表6-4のようになります。中継点オプションヘッダや終点オプション
ヘッダは、次ヘッダ番号フィールドと拡張ヘッダ長フィールドのほかに、1つ以上のオプション
を含みます。各オプションには、
「配送中変更可能ビット」
（オプション番号フィールドの上位3
ビットめ）が含まれており、このビットが 1 となっている場合には、そのオプションのデータが
配送中に変更される可能性があります。このため、配送中変更可能ビットが0の場合は、そのオ
プション全体をICVの計算に含めますが、配送中変更可能ビットが1の場合には、そのオプショ
ンのオプションデータフィールドはすべて 0 であるとして ICV を計算します（オプション番号
フィールドやオプションデータ長フィールドは計算に含めます）
。また、フラグメントヘッダは、
終点での AH の処理時には存在しないため、ICV の計算にも含まれません。
ICV の計算に含める AH ヘッダのフィールドは図 6-8 のようになります。認証データフィール
ドにはすべて0が入っているものとしてICVを計算します。そして、計算されたICVを認証デー
タフィールドに入れます。
6.4 AH 処理の流れ ● 121
表 6-4 ICV の計算時における IPv6 拡張ヘッダの扱い
ヘッダ番号
0
IPv6 拡張ヘッダ
値の変化
ICV の計算
中継点オプションヘッダ
配送中に変更される可能性
配送中変更可能ビットにし
がある
たがう
43
経路制御ヘッダ（タイプ 0） 配送中に変更されるが予測
可能
含まれる
44
フラグメントヘッダ
配送中に変更される可能性
がある
AH 処理時には存在しない
50
暗号ペイロード
配送中不変
含まれる
51
認証ヘッダ
配送中不変
含まれる（ICV 以外）
60
終点オプションヘッダ
配送中に変更される可能性
がある
配送中変更可能ビットにし
たがう
108
IPComp ヘッダ
配送中不変
含まれる
0
8
次ヘッダ番号
16
ペイロード長
31
予約
セキュリティパラメータインデックス（SPI）
シーケンス番号
認証データ（可変長）
パディング（必要に応じて存在）
図 6-8 ICV の計算に含まれる認証ヘッダのフィールド（網掛部）
フラグメント分割処理
AHを適用したパケットの大きさがMTU値を超えている場合には、AH処理の後にフラグメン
ト分割処理を行います。
122 ● 6 章 認証ヘッダ（AH）
6.4.2 受信側における処理（ AH 入力処理）
AH が適用されたパケットを受信した場合には、次の順序で AH 入力処理を行います。
フラグメント再構成処理
受信されたIPパケットがフラグメントされている場合には、AH処理の前にフラグメント再構
成処理を行います。つまり、AH処理には、必ずフラグメントされていない状態のIPパケットが
渡されることになります。
セキュリティアソシエーションの検索
受信側は、パケット配送用の IP ヘッダ（外側 IP ヘッダ）の終点 IP アドレス、セキュリティプ
ロトコルの種類（AH）、AHヘッダに含まれるSPIをキーとして入力用SADから該当するSA の情
報を検索します。該当する SA の情報が存在しない場合にはパケットを破棄します。
シーケンス番号の検証（オプション）
受信側がリプレイ防御機能を有効にしている場合には、受信されたパケットのAHヘッダに含
まれるシーケンス番号を検証します。シーケンス番号の検証には、32ビット以上（デフォルトは
64ビット）
のリプレイ防御ウィンドウを使用します。シーケンス番号が、このリプレイ防御ウィ
ンドウの左端より小さい場合は、そのパケットを破棄します。また、シーケンス番号がリプレイ
防御ウィンドウの範囲内に収まっている場合であっても、該当するビットが1である場合（過去
に受信されている場合）はパケットを破棄します。これ以外の場合は、次の完全性チェック値
（ICV）の検証に進みます。
完全性チェック値（ICV）の検証
受信側は、該当するSAで指定された認証アルゴリズムと鍵を使用して、送信側と同様にIPパ
ケット全体に対してICVを計算します。そして、計算されたICVがAHヘッダの認証データフィー
ルドのICVと一致することを確認します。値が一致しない場合には、認証に失敗したことになる
ため、そのパケットを破棄します。
リプレイ防御ウィンドウの更新（オプション）
受信側がリプレイ防御機能を有効にしている場合には、ICVの検証の後にリプレイ防御ウィン
ドウを更新します。受信されたパケットのシーケンス番号がリプレイ防御ウィンドウの範囲内に
収まり、該当するビットが0である場合
（過去に受信されていない場合）
は、そのシーケンス番号
に該当するビットを 1 とします。また、受信されたパケットのシーケンス番号がリプレイ防御
6.4 AH 処理の流れ ● 123
ウィンドウの右端より大きい場合には、リプレイ防御ウィンドウを右にスライドして内容を更新
します。
AH ヘッダの削除
トランスポートモードが使用されている場合には、AHヘッダを削除し、その直前のヘッダ
の次ヘッダ番号フィールド（IPv4ヘッダの場合はプロトコルフィールド）の値を調整します。ト
ンネルモードが使用されている場合には、トンネル配送用の外側IPヘッダとAHヘッダを削除
します。
セキュリティポリシーの検証
AH 入力処理が完了したパケットの始点 IP アドレス、終点 IP アドレス、上位層プロトコル、
ポート番号などのセレクタをキーとして入力用SPDからセキュリティポリシーを検索します。そ
して、検索されたセキュリティポリシーの内容と入力処理の内容が合致していることを確認し
ます。
コラム： AH の必要性
当初AHは、暗号の使用が禁止されている国においても、認証機能を利用することができ
るように、暗号化を実現する ESP とは別のプロトコルとして定義されました。認証用のプ
ロトコルと暗号化用のプロトコルを別のプロトコルとすることで、暗号の使用が禁止されて
いる国では、ESPは実装できなくても、認証機能のみを有するAHを実装することが可能と
なります。このような目的のために、IPsecの最初のバージョンでは、認証機能は AHが提
供し、暗号化機能は ESP が提供するという分担になりました。しかし、認証なしで暗号化
を行った場合には危険であることが Steve Bellovin によって示されたため[6]、IPsec バー
ジョン2ではESPにも認証機能が加わるようになりました。このため、AHを使用しなくて
もESPのみで暗号化機能と認証機能を利用することができるようになり、AHの利用価値が
薄れてきました。
では、AHの利用価値はどのような点にあるのでしょうか。1 つは、当初から考えられて
いたように、暗号の使用が禁止されている国での利用です。そして、もう1つは、AHとESP
における認証の範囲の違いから生じる利用法です。AHはESPと異なり、パケット配送に利
用されるIPヘッダやIPv6拡張ヘッダを可能な範囲で保護する機能を持っています。例えば、
IPv6拡張ヘッダの経路制御ヘッダは、ESPでは保護することはできませんが、AHによって
124 ● 6 章 認証ヘッダ（AH）
保護することが可能です。実際に、経路制御ヘッダなどのIPv6拡張ヘッダを保護するため
に AH を利用するプロトコルが存在します。
参考文献
[1] S. Kent and R. Atkinson, “IP Authentication Header”, RFC 2402, November 1998.
[2] C. Madson and R. Glenn, “The Use of HMAC-MD5-96 within ESP and AH”, RFC 2403,
November 1998.
[3] C. Madson and R. Glenn, “The Use of HMAC-SHA-1-96 within ESP and AH”, RFC 2404,
November 1998.
[4] A. Keromytis and N. Provos, “The Use of HMAC-RIPEMD-160-96 within ESP and AH”,
RFC 2857, June 2000.
[5] P. Metzger and W. Simpson, “IP Authentication using Keyed MD5”, RFC 1828, August
1995.
[6] S. Bellovin, “Problem Areas for the IP Security Protocols”, Proceedings of the Sixth
Usenix UNIX Security Symposium, July 22-25, 1996, San Jose, CA. ftp://ftp.research.att.com/
dist/smb/badesp.ps
125
7章
● ESP の機能
● ESP プロトコルフォーマット
● 暗号化アルゴリズム
● 認証アルゴリズム
● ESP 処理の流れ
暗号ペイロード
（ESP）
暗号ペイロード（ESP：Encapsulating Security Payload）は、IPパケットの機密性の確保と完全
性の確保、および送信元の認証を行うセキュリティプロトコルです。この章では、ESPの機能と
処理の詳細について説明します。
7.1 ESP の機能
暗号ペイロード（ESP）[1] は、データの機密性とトラフィック情報の機密性を暗号化によって
確保し、オプションでIPパケットのコネクションレス完全性の確保と送信元の認証、そして、リ
プレイ攻撃からの防御の機能を提供します。
データの機密性確保
ESP のメインとなる機能がデータの暗号化機能です。トンネルモードの場合は IP パケット全
体を暗号化し、トランスポートモードの場合は IP ペイロード部を暗号化することにより、デー
タの機密性を確保します。
コネクションレス完全性の確保
ESPで認証機能を有効にした場合に含まれる完全性チェック値を検証することで、IPペイロー
ド部（トンネルモードの場合はカプセル化された IP パケット）の完全性を確保することが可能と
なります。ただし、AHと異なり、パケット配送用のIPヘッダなどの完全性を確保することはで
きません。ESP では、この機能はオプションとして用意されています。
126 ● 7 章 暗号ペイロード（ESP）
データ送信元の認証
ESP で認証機能を有効にした場合に含まれる ICV を検証することで、その IP パケットが、共
有秘密鍵を持つ相手から送信されたものであることを確認することが可能となります。ESP で
は、この機能はオプションとして用意されています。
リプレイ防御
認証機能を有効にしている場合は、リプレイ防御機能を有効にすることが可能です。ESPヘッ
ダに含まれるシーケンス番号をチェックすることで、過去に受信した IP パケットを再び受信す
ることを防ぐことが可能です。ESP では、この機能はオプションとして用意されています。
トラフィック情報の機密性確保
トンネルモードを使用してIPパケット全体を暗号化することにより、データの送信元、宛先、
利用プロトコルなどの情報を隠蔽することが可能です。また、暗号化の前にパディングをある程
度付加して送信量を多くすることで、実際のデータ量をある程度隠蔽することも可能です。
7.2 ESP プロトコルフォーマット
ここでは、ESP のプロトコルフォーマットと ESP が挿入される位置について説明します。
7.2.1 ESP のパケットフォーマット
ESP のパケットフォーマットを図 7-1 に示します。
ESP のフィールドは、暗号化されたペイロードデータ部と、その前後に付加される ESP ヘッ
ダおよび ESP トレーラ、そして、認証機能が使用された場合に付加される認証データ部に分か
れます。ESPヘッダにはSPI（セキュリティパラメータインデックス）値とシーケンス番号が含ま
れます。ESPトレーラはパディングとパディング長フィールド、次ヘッダ番号フィールドから構
成されますが、これらのフィールドはペイロードデータ部とともに暗号化されています。つまり、
第三者には SPI 値とシーケンス番号しか知られることはありません。
7.2 ESP プロトコルフォーマット ● 127
0
8
16
24
31
セキュリティパラメータインデックス（SPI）
ESP
ヘッダ
シーケンス番号
データ
ペイロードデータ（可変長）
パディング（0 ∼ 255 バイト）
パディング長
次ヘッダ番号
ESP
トレーラ
認証データ（可変長）
図 7-1 ESP のパケットフォーマット（網掛部は暗号化）
セキュリティパラメータインデックス
（SPI）
フィールド
セキュリティパラメータインデックス（SPI）
フィールドは、32ビットの固定長フィールドで
す。このフィールドには、SA を識別するための SPI 値が入ります。
表 7-1 に、SPI 値の範囲とその用途を示します。256 以上の値であれば、手動での設定およ
びIKEなどによる自動でのSA設定のどちらでも使用することができますが、実装によって
は、256 ∼ 4,095 を手動設定用、4,096 以上を自動設定用に使用している場合があります。1
∼255のSPI値は将来の利用のために予約されているため、現時点では、これらの値を使用
してはいけません。また、SPI値0は、ローカルでの利用のために予約されているため、こ
表 7-1 SPI 値の範囲と用途
SPI値
用途
0
ローカルでの利用
1∼255
予約
256∼
手動および自動設定用
128 ● 7 章 暗号ペイロード（ESP）
の値も通常は使用することができません。
シーケンス番号フィールド
シーケンス番号フィールドは、32ビットの固定長フィールドです。このフィールドには、パ
ケットを送信する際に1ずつ増加するシーケンス番号が入ります。このシーケンス番号は、
SAが生成された際に0に初期化されるため、SA生成後の最初のパケットに含まれるシーケ
ンス番号は 1 となります。
ペイロードデータフィールド
（暗号化）
ペイロードデータフィールドは、整数バイト長の可変長フィールドです。トランスポート
モードの場合は、このペイロードデータフィールドには暗号化された IP ペイロード部が入
ります。また、トンネルモードの場合には、暗号化された IPパケット全体が入ります。暗
号化アルゴリズムで初期ベクトル
（IV）
を必要とする場合は、このペイロードデータフィール
ド中で暗号化されていない状態で運ばれます。
パディングフィールド
（暗号化）
ペイロードデータフィールドとパディング長フィールドの間にパディングフィールドが挿入
されます。このパディングの目的は、次のとおりです。
パディング長フィールドと次ヘッダ番号フィールドが4バイト境界の右端に位置するよ
うに調整する
IVを除いたペイロードデータフィールドとパディングフィールド、パディング長フィー
ルド、次ヘッダ番号フィールドの合計の長さが、使用する暗号化アルゴリズムのブロッ
ク長の整数倍となるように調整する
トラフィック情報の機密性を確保するため、送信するデータの量を実際のデータ量より
も多くする
パディングの値が暗号化アルゴリズムで指定されない場合は、デフォルトで1バイトごとに
1、2、3…と増加する整数値（最初のパディングの値は1、2つめのパディングの値は2）が入
ります。
パディング長フィールド
（暗号化）
パディング長フィールドは、8ビットの固定長フィールドです。このフィールドには、直前
のパディングの長さがバイト単位で入ります。
7.2 ESP プロトコルフォーマット ● 129
次ヘッダ番号フィールド
（暗号化）
次ヘッダ番号フィールドは、8ビットの固定長フィールドです。このフィールドには、ペイ
ロードデータフィールドを復号化した際に最初に現れるヘッダのIP プロトコル番号が入り
ます。
認証データフィールド
認証データフィールドは、可変長フィールドです。このフィールドは、認証機能を有効にし
た場合のみ存在します。このフィールドには、ESP ヘッダ、暗号化されたデータ、ESP ト
レーラに対する完全性チェック値
（ICV）
が入ります。認証データフィールドの長さは、SAで
指定された認証アルゴリズムの出力の長さによって決定されます。
7.2.2 ESP が挿入される位置
表 7-2 に ESP が挿入される位置を示します。ESP は、IPv4 では、IPv4 ヘッダの後、トランス
ポート層ヘッダの前に挿入されます。IPv6では、ESPは終点間ペイロード（IPパケットの終点で
のみ使用され、途中のルータなどでは使用されない）であるため、経路制御ヘッダなどの配送途
中で使用される拡張ヘッダの後に挿入されます。
表 7-2 IPv6 および IPv4 における ESP の位置
ヘッダ番号
IPv6 におけるヘッダ順序
IPv4 におけるヘッダ順序
−
IPv6 ヘッダ
IPv4 ヘッダ
0
中継点オプションヘッダ
─
60
終点オプションヘッダ
─
43
経路制御ヘッダ
─
44
フラグメントヘッダ
─
51
認証ヘッダ
（AH）
50
暗号ペイロード
（ESP）
108
IPComp ヘッダ
60
6、17 など
終点オプションヘッダ
─
トランスポート層ヘッダ（TCP、UDP など）
※ 終点オプションヘッダは、通常はIPv6拡張ヘッダの最後（トランスポート層ヘッダの前）
に現れますが、経路制御ヘッダの前に現れる場合もあります。
130 ● 7 章 暗号ペイロード（ESP）
7.3 暗号化アルゴリズム
ESPでは、暗号化アルゴリズムとしてDES -CBCとNULL暗号化アルゴリズムの実装が必須と
なっています。この他にも多くの暗号化アルゴリズムを使用することが可能です。暗号化アルゴ
リズムの詳細については、「2.2 共通鍵暗号」を参考にしてください。
7.3.1 DES-CBC
ESPでは、暗号化アルゴリズムとしてDES -CBCを実装することが必須とされています。図72 に、DES -CBC を使用した場合の ESP のパケットフォーマットを示します。DES -CBC で使用
する64ビットのIVは、送信側が任意に生成し、ESPのペイロードデータフィールドにて明示的
に運ばれます。また、DES -CBC のブロックサイズは 64 ビットであるため、暗号化対象となる
データは64ビットの整数倍である必要があります。このため、暗号化対象となるデータ
（トラン
スポートモードの場合は上位層プロトコルデータ、トンネルモードの場合はIPパケット全体）
と
0
8
16
24
31
セキュリティパラメータインデックス
（SPI）
シーケンス番号
初期ベクトル
（IV）
ペイロードデータ
（可変長）
64 ビット
の整数倍
パディング
（0 ∼ 255 バイト）
パディング長
次ヘッダ番号
認証データ
（可変長）
図 7-2 DES-CBC を使用した場合の ESP フォーマット（網掛部は暗号化）
7.3 暗号化アルゴリズム ● 131
パディング、パディング長フィールド、次ヘッダ番号フィールドを合わせた長さが64 ビットの
整数倍となるようにパディングの量が調整されます。ESPでのDES -CBCの使用法は、RFC 2405
[2] に記述されています。
7.3.2 その他の CBC モード暗号化アルゴリズム
ESP で使用可能な暗号化アルゴリズムとしては、DES-CBC の他に 3DES -CBC、RC5-CBC、
IDEA-CBC、CAST-128-CBC、Blowfish-CBCなどがあります。実装上必須とされているDES-CBC
は、すでに暗号強度が弱いため、現在は、DES -CBCではなく、3DES -CBCなどの暗号化アルゴ
リズムが一般的に使用されています。
これらの暗号化アルゴリズムでは、DES -CBCと同様にブロックサイズと同じ長さのIVを使用
します。3DES -CBC、RC5-CBC、IDEA-CBC、CAST-128 - CBC、Blowfish-CBC の各アルゴリズム
のブロックサイズは64ビットであるため、IVの長さは64ビットとなります。IVはDES - CBCと
同様に送信側で生成され、ペイロードデータフィールド中で運ばれます。また、暗号化対象とな
るデータの長さは 64 ビットの整数倍となるようにパディングが調整されます。ESP におけるこ
れらの暗号化アルゴリズムの使用法は、RFC 2451 [3] に記述されています。
7.3.3 NULL 暗号化アルゴリズム
NULL 暗号化アルゴリズムは、実際には暗号化を行いません。NULL 暗号化アルゴリズムは、
ESPで機密性の確保を必要としない場合に、認証と完全性を確保するために使用されます。この
ため、NULL暗号化アルゴリズムを指定した場合には、必ず認証アルゴリズムを指定する必要が
あります。
NULL暗号化アルゴリズムでは、IVを必要としません。また、ブロックサイズは1バイトであ
るため、データの長さをパディングで調整する必要はありません。ただし、パディング長フィー
ルドと次ヘッダ番号フィールドが 32ビット境界の右端に位置するようにパディングを行う必要
があります。ESP での NULL 暗号化アルゴリズムの使用法は、RFC 2410 [4] に記述されてい
ます。
7.3.4 AES-CBC
ESP では、実装が対応していれば AES -CBC を利用することも可能です。また、NIST による
AESの選考過程で最終候補となったTwofish、RC6、MARS、Serpentの各暗号も、実装が対応し
ていれば利用することが可能です。
これらのアルゴリズムでは、DES-CBCと同様にIVを使用しますが、AES -CBC、Twofish-CBC、
RC6-CBC、MARS -CBC、Serpent-CBCの各アルゴリズムのブロックサイズは128ビットであるた
132 ● 7 章 暗号ペイロード（ESP）
め、IVの長さは128ビットとなります。IVはDES - CBCと同様に、送信側で生成され、ペイロー
ドデータフィールド中で運ばれます。また、暗号化対象となるデータの長さは128ビットの整数
倍となるようにパディングが調整されます。ESP での AES-CBC の使用法は、RFC 3602 [5] に
記述されています。
7.4 認証アルゴリズム
ESPで認証機能を有効にした場合には、AHと同様の認証アルゴリズムが使用されます。ESP
においても、AH と同様に HMAC-MD5-96 と HMAC-SHA-1-96 が実装上必須の認証アルゴリズム
となっています。ただし、ESPにおける認証機能はオプションであるため、認証機能を使用しな
い場合には、認証アルゴリズムは指定されません。ただし、暗号化アルゴリズムとしてNULL暗
号化アルゴリズムを指定した場合は、認証アルゴリズムを指定する必要があります。
7.5 ESP 処理の流れ
ここでは、送信側および受信側における ESP の処理について説明します。
7.5.1 送信側における処理（ ESP 出力処理）
パケットに ESP を適用して送信する場合には、次の順序で ESP 出力処理を行います。
セキュリティポリシーの検索
送信するパケットの始点IPアドレス、終点IPアドレス、プロトコルなどのセレクタをキーと
して出力用 SPD から該当するセキュリティポリシーを検索します。
セキュリティアソシエーションの検索
セキュリティポリシーで ESP を使用するように指定されている場合には、出力用 SAD から
該当する SA を検索します。有効な SA が存在しない場合には、IKE によって新たに SA を生成
します。
IV の生成
NULL 暗号化アルゴリズムを除いて、多くの暗号化アルゴリズムでは IV が使用されます。異
なるパケットで同じIVが使用された場合や、単純なカウンタのようなものによってIVが生成さ
れている場合には、鍵が容易に解読されてしまう危険性があります。このため、IV はパケット
7.5 ESP 処理の流れ ● 133
ごとに異なる乱数である必要があります。
図 7-3 に、IV の生成手順を示します。SA が生成されてから最初のパケットに対しては、送信
側で生成した乱数をIV として使用します。以降のパケットでは、前のパケットを暗号化して得
られた暗号文の最終ブロック（DESや3DESなどの64ビットブロックで動作する暗号化アルゴリ
ズムの場合は8バイト、AESなどの128ビットブロックで動作する暗号化アルゴリズムの場合は
16 バイト）を IV として使用します。
乱数
ESP ヘッダ
ESP ヘッダ
ESP ヘッダ
IV
IV
IV
暗号化データ
暗号化データ
暗号化データ
最終ブロック
最終ブロック
最終ブロック
1 パケットめ
2 パケットめ
3 パケットめ
図 7-3 ESP における CBC モード暗号の IV の生成法
パケットの暗号化
トランスポートモードを使用する場合は、IP ペイロード部を暗号化します。また、トンネル
モードを使用する場合は、IPパケット全体を暗号化します。ただし、暗号化対象となる平文デー
タに、必要な長さのパディングとパディング長フィールド、次ヘッダ番号フィールドを追加して
から暗号化します。暗号化はSAで指定された暗号化アルゴリズムと共有秘密鍵を使用して行い
ます。
シーケンス番号の生成
該当する SA のシーケンス番号カウンタを 1 つ増加し、増加した値を ESP ヘッダのシーケンス
番号フィールドに入れます。
シーケンス番号カウンタを増加させた際にカウンタが一巡した場合は、パケットを送信する前
にIKEによって新しいSAを生成する必要があります。ただし、手動鍵管理の場合のように、リ
プレイ防御機能が無効である場合は、カウンタが一巡した場合でも引き続きそのSAを使用する
ことが可能です。
134 ● 7 章 暗号ペイロード（ESP）
完全性チェック値（ICV）の計算（オプション）
認証機能を有効にしている場合には、該当するSAで指定された認証アルゴリズムと共有秘密
鍵を使用して、ESPパケットに対する完全性チェック値（ICV）
を計算します。しかし、認証デー
タフィールドに含まれる ICV はまだ計算されていないため、ESP パケットの認証データフィー
ルドを除いた残りの部分に対して ICV が計算されます（図 7-4）。
0
8
16
24
31
セキュリティパラメータインデックス（SPI）
シーケンス番号
ペイロードデータ
パディング
パディング長
次ヘッダ番号
認証データ
図 7-4 ICV の計算に含まれる ESP フィールド（網掛部）
トランスポートモード ESP における認証の範囲を図 7-5 に示します。また、トンネルモード
ESP における認証の範囲を図 7-6 に示します。
トランスポートモードとトンネルモードのどちらの場合でも、ESP パケットの ESP ヘッダと
暗号化されたペイロードデータフィールドおよび ESP トレーラが、ESP における認証の範囲と
なります。AHとは異なり、パケット配送用のIPヘッダなどのESPヘッダより前に位置するヘッ
ダは、ESP の認証の範囲には含まれません。
7.5 ESP 処理の流れ ● 135
プロトコル
=ESP
IPv4
ヘッダ
次ヘッダ
=TCP
ESP
ヘッダ
TCP
ヘッダ
データ
ESP
トレーラ
ESP
認証
データ
認証の範囲
次ヘッダ
=ESP
IPv6
ヘッダ
経路制御
ヘッダ
次ヘッダ
= 終点オプション
ESP
ヘッダ
終点
オプション
ヘッダ
TCP
ヘッダ
データ
ESP
トレーラ
ESP
認証
データ
認証の範囲
図 7-5 トランスポートモード ESP の認証の範囲（網掛部は暗号化）
プロトコル
=ESP
トンネル
IPv4
ヘッダ
次ヘッダ
=IPv4
ESP
ヘッダ
IPv4
ヘッダ
TCP
ヘッダ
データ
ESP
トレーラ
ESP
認証
データ
認証の範囲
次ヘッダ
=ESP
トンネル
IPv6
ヘッダ
次ヘッダ
=IPv6
ESP
ヘッダ
IPv6
ヘッダ
終点
経路制御
オプション
ヘッダ
ヘッダ
TCP
ヘッダ
データ
ESP
トレーラ
ESP
認証
データ
認証の範囲
図 7-6 トンネルモード ESP の認証の範囲（網掛部は暗号化）
フラグメント分割処理
ESPを適用したパケットの大きさがMTU値を超えている場合には、ESP処理の後にフラグメ
ント分割処理を行います。
7.5.2 受信側における処理（ ESP 入力処理）
ESP が適用されたパケットを受信した場合には、次の順序で ESP 入力処理を行います。
136 ● 7 章 暗号ペイロード（ESP）
フラグメント再構成処理
受信された IP パケットがフラグメントされている場合には、ESP 処理の前にフラグメントを
再構成します。つまり、ESP 処理には、必ずフラグメントされていない状態の IP パケットが渡
されることになります。
セキュリティアソシエーションの検索
受信側は、外側IPヘッダの終点IPアドレス、セキュリティプロトコルの種類
（ESP）
、ESPヘッ
ダに含まれる SPI をキーとして入力用 SAD から該当する SA の情報を検索します。該当する SA
の情報が存在しない場合には、パケットを破棄します。
シーケンス番号の検証（オプション）
認証機能が使用されており、受信側がリプレイ防御機能を有効にしている場合には、受信され
たパケットのESPヘッダに含まれるシーケンス番号を検証します。シーケンス番号の検証には、
32ビット以上（デフォルトは64ビット）のリプレイ防御ウィンドウを使用します。シーケンス番
号が、このリプレイ防御ウィンドウの左端より小さい場合は、そのパケットを破棄します。また、
シーケンス番号がリプレイ防御ウィンドウの範囲内に収まっている場合であっても、該当する
ビットが1である場合
（過去に受信されている場合）
はパケットを破棄します。これ以外の場合は、
次の完全性チェック値（ICV）の検証に進みます。
完全性チェック値（ICV）の検証（オプション）
認証機能を有効にしている場合には、該当するSAで指定された認証アルゴリズムと鍵を使用
して、送信側と同様に認証データフィールドを除いたESPパケットに対してICVを計算します。
そして、計算された ICV が ESP の認証データフィールドの ICV と一致することを確認します。
値が一致しない場合には、認証に失敗したことになるため、そのパケットを破棄します。
リプレイ防御ウィンドウの更新（オプション）
認証機能が使用されており、受信側がリプレイ防御機能を有効にしている場合には、ICVの検
証の後にリプレイ防御ウィンドウを更新します。受信されたパケットのシーケンス番号がリプレ
イ防御ウィンドウの範囲内に収まり、該当するビットが0 である場合（過去に受信されていない
場合）
は、そのシーケンス番号に該当するビットを1とします。また、受信されたパケットのシー
ケンス番号がリプレイ防御ウィンドウの右端より大きい場合には、リプレイ防御ウィンドウを右
にスライドして内容を更新します。
7.5 ESP 処理の流れ ● 137
パケットの復号化
該当するSAで指定された暗号化アルゴリズムと鍵を使用して、ESPパケットを復号化します。
復号化の際にIVを必要とする場合には、暗号化アルゴリズムの仕様で指定された方法でIVを取
り出して使用します（明示的 IV の場合は、IV は平文の状態でペイロードフィールド中において
運ばれます）。
復号化された平文の最後尾の1バイトが次ヘッダ番号フィールドとなり、その前の1バイトが
パディング長フィールドとなります。このパディング長フィールドで指定された長さのパディン
グを削除し、ペイロードデータフィールドを取り出します。
トランスポートモードが使用されている場合には、ESP ヘッダや ESP トレーラ、認証データ
フィールドを取り除き、送信されたIPヘッダと組み合わせてIPパケットを復元します。この場
合は、IPヘッダのプロトコルフィールド
（IPv6の場合は次ヘッダ番号フィールド）
に、ESPトレー
ラの次ヘッダ番号フィールドの内容をコピーします。トンネルモードが使用されている場合には、
復号化されたペイロードフィールドが IP パケットとなります。
セキュリティポリシーの検証
ESP入力処理が完了したパケットの始点IPアドレス、終点IPアドレス、上位層プロトコル、
ポート番号などのセレクタをキーとして入力用SPDからセキュリティポリシーを検索します。
そして、検索されたセキュリティポリシーの内容と入力処理の内容が合致していることを確認
します。
参考文献
[1] S. Kent and R. Atkinson, “IP Encapsulating Security Payload (ESP)”, RFC 2406, November
1998.
[2] C. Madson and N. Draswamy, “The ESP DES-CBC Cipher Algorithm With Explicit IV”,
RFC 2405, November 1998.
[3] R. Pereira and R. Adams, “The ESP CBC-Mode Cipher Algorithms”, RFC 2451, November
1998.
[4] R. Glenn and S. Kent, “The NULL Encryption Algorithm and Its Use With IPsec”, RFC
2410, November 1998.
[5] S. Frankel, S. Kelly, and R. Glenn, “The AES-CBC Cipher Algorithm and Its Use with
IPsec”, RFC 3602, September 2003.
139
● IP レベルでの圧縮の必要性
● IPComp アソシエーション（ IPCA）
● IPComp プロトコルフォーマット
● 拡大防止ポリシー
● 圧縮アルゴリズム
● IPComp 処理の流れ
8章
IPペイロード圧縮（IPComp）
IPComp（IP Payload Compression Protocol）は、IPのレベルでデータを圧縮するプロトコルで
す。IPCompは、IPsecとは独立したプロトコルですが、IPsecを使用する際にIPCompを組み合
わせることによって、高いパフォーマンスを得ることが可能となります。この章では、IPComp
の仕組みとその有効性について説明します。なお、IPComp の仕様は、RFC 2393 [1] に記述さ
れていましたが、新しい仕様が RFC 3173 [2]として発行されています。この章では、この新し
い仕様を基に説明します。
8.1 IP レベルでの圧縮の必要性
データの圧縮は、さまざまな層で行われます。例えば、LHA や ZIP などの圧縮ツールを使用
してファイル自身を圧縮したり、PPP Compression Control Protocolなどを使用してデータリン
ク層レベルで圧縮したりすることも可能です。データを圧縮することによって、データ転送のス
ループットを高めることが可能となります。
しかし、どのような場合でも圧縮が有効に機能するとは限りません。圧縮は、データの規則的
な並びを、ある法則にしたがって短い情報で表すことによってデータ量を削減しています。つま
り、データに規則的な並びが多いほど、圧縮率がよくなりますが、規則的な並びが少ないと圧縮
率が悪くなり、逆にデータが増えてしまう場合もあります。特に、暗号化されたデータには規則
的な並びがほとんど発生しません。このため、ESP が適用されたパケットを PPP Compression
Control Protocolなどを使用してデータリンク層レベルで圧縮しようとすると、圧縮対象となる
データは暗号化されているため、圧縮率が非常に悪くなってしまいます。
そこで、ESPによってデータが暗号化される前に圧縮を行う必要があります。これを実現する
140 ● 8 章 IP ペイロード圧縮（IPComp）
プロトコルが IPComp（IP Payload Compression Protocol）です。IPComp は ESP による暗号化処
理の前にデータを圧縮するため、効率よく圧縮を行うことが可能です。
特に、IPパケットにIPsecを適用することによって、データ量が多くなり、フラグメントが発
生してしまう場合がありますが、IPCompによってデータを圧縮することにより、フラグメント
の発生を抑えることが可能となります（ただし GIF 画像や JPEG 画像などのあらかじめ圧縮され
ているデータの場合には効果がない場合があります）。
ただし、IPCompは、IPレベルで圧縮を行うため、圧縮の単位はIPパケットごととなります。
IP は到着順序の保証されないステートレスなプロトコルであるため、他の IP パケットの圧縮履
歴
（ヒストリ）
を利用することができません。このため、履歴に基づく圧縮が利用可能な上位層で
の圧縮よりも一般的に圧縮率は悪くなります。
8.2 IPComp アソシエーション（IPCA）
IPComp を使用するためには、事前に送信側と受信側との間で IPComp アソシエーション
（IPCA：IPComp Association）を確立する必要があります。IPCA は、IPsec のセキュリティアソ
シエーション（SA）と似ており、次の内容が定義されます。
複数のIPCAを識別するためのCPI（Compression Parameter Index：圧縮パラメータインデッ
クス）
使用する圧縮アルゴリズムの種類
カプセル化モード（トンネルモードまたはトランスポートモード）
IPCA の有効期間
IPCAのパラメータは手動で設定することも可能ですが、IKEによって自動的に折衝すること
が可能です。IKEによるIPCAパラメータの折衝は、IPsec SAの折衝と同時に行われます。IPCA
は、IPsec SA と同様に単方向であるため、方向によって異なる圧縮アルゴリズムを選択するこ
とが可能です。IPsec SA と IPCA の違いを表 8-1 にまとめます。
表 8-1 IPsec SA と IPCA の違い
IPsec SA
IPCA
プロトコル
IPsec（AH、ESP）
IPComp
方向
単方向
単方向
識別子
SPI（4 バイト）
CPI（2 バイト）
8.3 IPComp プロトコルフォーマット ● 141
8.3 IPComp プロトコルフォーマット
ここでは、IPCompのヘッダフォーマットとIPCompヘッダが挿入される位置について説明し
ます。
8.3.1 IPComp のヘッダフォーマット
IPComp が適用されたパケットには、図 8-1 に示す 4 バイトの IPComp ヘッダが挿入されます。
0
8
次ヘッダ番号
16
予約
24
31
CPI（圧縮パラメータインデックス）
図 8-1 IPComp ヘッダの構成
次ヘッダ番号フィールド
次ヘッダ番号フィールドは、8ビットの固定長フィールドです。このフィールドには、圧縮
されたデータにおける最初のプロトコルヘッダの番号が入ります。トランスポートモードの
場合には、このフィールドには、多くの場合、TCPやUDPなどのトランスポート層プロト
コルヘッダのプロトコル番号が入ります。また、トンネルモードの場合には、IP パケット
全体がカプセル化されるため、IPv4 ヘッダや IPv6 ヘッダのプロトコル番号が入ります。
予約フィールド
予約フィールドは、8ビットの固定長フィールドです。このフィールドは将来の利用のため
に予約されており、すべてのビットが 0 にセットされている必要があります。
（圧縮パラメータインデックス）
フィールド
CPI
CPI（Compression Parameter Index：圧縮パラメータインデックス）フィールドは、CPI 値
が入る 16 ビットの固定長フィールドです。表 8-2 に、CPI 値の範囲とその用途を示します。
0 ∼ 63 は、すでに定義されている圧縮アルゴリズム用の番号として用意されています。こ
の値は、IPsec DOI で定義されている IPComp トランスフォーム ID と同じ値となります
（「9.7.2 IPsec SA パラメータ」を参照）。例えば、DEFLATE 圧縮アルゴリズムを使用する場
合には 2 が、LZS 圧縮アルゴリズムを使用する場合には 3 が使用されます。64 ∼ 255 は、将
来の使用のために予約されています。256∼61,439は、IKEによって自動的に折衝される場
合に使用されます。61,440∼65,535は、プライベートでの利用のために用意されています。
142 ● 8 章 IP ペイロード圧縮（IPComp）
表 8-2 CPI 値の範囲と用途
CPI 値
用途
0 ∼ 63
定義済みの圧縮アルゴリズム用
（0 は予約）
64 ∼ 255
予約
256 ∼ 61,439
自動設定用
61,440 ∼ 65,535
プライベートでの利用
8.3.2 IPComp ヘッダが挿入される位置
表8-3にIPCompヘッダが挿入される位置を示します。IPCompヘッダは、IPv4では、IPv4ヘッ
ダの後、トランスポート層ヘッダの前に挿入されます。IPv6では、IPCompヘッダは終点間ペイ
ロード
（IPパケットの終点でのみ使用され、途中のルータなどでは使用されない）
であるため、経
路制御ヘッダなどの配送途中で使用される拡張ヘッダの後に挿入されます。
表 8-3 IPv6 および IPv4 における IPComp ヘッダの位置
ヘッダ番号
IPv6 におけるヘッダ順序
IPv4 におけるヘッダ順序
−
IPv6 ヘッダ
IPv4 ヘッダ
0
中継点オプションヘッダ
─
60
終点オプションヘッダ
─
43
経路制御ヘッダ
─
44
フラグメントヘッダ
─
51
認証ヘッダ
（AH）
50
暗号ペイロード
（ESP）
108
IPComp ヘッダ
60
6、17 など
終点オプションヘッダ
─
トランスポート層ヘッダ（TCP、UDP など）
※ 終点オプションヘッダは、通常はIPv6拡張ヘッダの最後（トランスポート層ヘッダの前）
に現れますが、経路制御ヘッダの前に現れる場合もあります。
8.4 拡大防止ポリシー ● 143
8.4 拡大防止ポリシー
IPComp を使用してデータを圧縮した場合でも 4 バイトの IPComp ヘッダが新たに追加される
ため、データの圧縮効率が悪い場合には、オリジナルの IP パケットよりも IPComp 適用後の IP
パケットの方が逆に大きくなってしまう可能性があります。そこでIPCompでは、IPComp適用
後の IP パケットがオリジナルの IP パケットよりも大きくなってしまった場合には、IPComp を
適用する前のオリジナルの IP パケットを使用します（図 8-2）。
IPComp 適用前
IP パケット
IPComp 処理
長さを比較
IPComp 適用後
IP パケット
IPComp 適用後
IP パケット
短い方を採用
図 8-2 IPComp 適用後の長さの比較
しかし、一度圧縮を試みてから長さを比較するのでは、その圧縮に要した時間が無駄になって
しまう可能性があります。そこで、圧縮をしても効果がないと予想される場合には、圧縮を行わ
ずにオリジナルの IP パケットをそのまま使用します。
通常は、小さいデータの場合は圧縮率が悪くなるため、IPCompでは、経験から判断されたあ
る一定の長さより短いデータに対しては圧縮を行いません（図 8-3）。このように、IPComp を適
用するデータの長さにスレッショルドを設けることにより、IPCompを適用してから長さを比較
するという処理の時間を省くことが可能となります。このスレッショルド値は圧縮アルゴリズム
ごとに異なりますが、DEFLATE や LZS では 90 バイト、LZJH では 50 バイトとされています。
また、すでに圧縮されているデータ
（GIF画像やJPEG画像など）
や暗号化されているデータ
（暗
号化メールなど）の場合には、圧縮しても効果のないIPパケットが連続して送信されることが予
想されます。このため、IPCompでは、あるIPパケットを圧縮しても効果がなかった場合には、
そのIPパケットやその後に続くIPパケットは圧縮または暗号化されていると予想し、その後の
いくつかの IP パケットは、圧縮を行いません（図 8-4）。
144 ● 8 章 IP ペイロード圧縮（IPComp）
IP ペイロード
（90 バイト未満）
IPComp を適用しない
IP ヘッダ
IP ペイロード
（90 バイト以上）
IPComp を適用
IP ヘッダ
図 8-3 圧縮対象データの長さによる IPComp 適用の判断
ある IPComp アソシエーションにおけるIP パケットの流れ
圧縮済？
圧縮済？
圧縮済？
圧縮済
圧縮しない
圧縮しない
圧縮しない
圧縮失敗
圧縮再開
圧縮処理をスキップ
図 8-4 圧縮失敗時の処理
8.5 圧縮アルゴリズム
IPCompで使用可能な圧縮アルゴリズムとしては、本書執筆時点ではDEFLATEとLZS、LZJH
の3つがあります。IPCompは特定の圧縮アルゴリズムに依存しないように設計されているため、
この他の圧縮アルゴリズムが将来追加される可能性もあります。
8.5.1 DEFLATE
DEFLATE は、Phil Katz（PKZIP の開発者で PKWARE 社の創立者）によって開発された圧縮ア
ルゴリズムであり、PKZIPやgzip、zlibライブラリなどで使用されています。IPCompでDEFLATE
を使用する場合は、90バイト未満のデータに対しては圧縮を行いません。IPCompでのDEFLATE
の使用法は、RFC 2394 [3] に記述されています。
8.5.2 LZS
LZS（Lempel-Ziv-Stac）は、Stac Electronics 社（現在の Hifn 社の前身）によって開発された圧縮
8.6 IPComp 処理の流れ ● 145
アルゴリズムです。IPComp で LZS を使用する場合は、90 バイト未満のデータに対しては圧縮
を行いません。LZSは圧縮履歴（ヒストリ）が利用できる圧縮アルゴリズムですが、IPCompでは
他の IP パケットの圧縮履歴は使用できないため、IP パケットごとに圧縮履歴をリセットする必
要があります。IPComp での LZS の使用法は、RFC 2395 [4] に記述されています。LZS 圧縮ア
ルゴリズムは、Hifn 社が特許を保有しています。
8.5.3 LZJH
LZJH（Lempel-Ziv-Jeff-Heath）は、Hughes Network Systems 社の Jeff Heath によって開発され
た圧縮アルゴリズムです。LZJHは、モデムにおける圧縮の規格であるITU-T V.44勧告に採用さ
れています。IPCompでLZJHを使用する場合には、50バイト未満のデータに対しては圧縮を行
いません。IPComp での LZJH の使用法は、RFC 3051 [5] に記述されています。LZJH 圧縮アル
ゴリズムは、Hughes Network Systems 社が特許を保有しています。
8.6 IPComp 処理の流れ
ここでは、IP パケットに IPComp を適用する場合の処理の手順について説明します。
8.6.1 送信側における処理（IPComp 出力処理）
1.
最初に圧縮対象となるデータの長さを調べます。これは、トンネルモードの場合は、IPパ
ケット全体の長さとなります。また、トランスポートモードの場合は、IPv4 ではトラン
スポート層ヘッダ以降の部分の長さとなり、IPv6 では、終点オプションヘッダ以降の部
分の長さとなります（図 8-5）。
IPv4
ヘッダ
TCP
ヘッダ
データ
圧縮対象範囲
IPv6
ヘッダ
終点
経路制御
オプション
ヘッダ
ヘッダ
TCP
ヘッダ
データ
圧縮対象範囲
図 8-5 IPv4 および IPv6 における IPComp の圧縮対象範囲
（トランスポートモード）
146 ● 8 章 IP ペイロード圧縮（IPComp）
2.
圧縮対象となるデータの長さが、圧縮アルゴリズムの仕様で指定されたスレッショルド値
（DEFLATEやLZSの場合は90バイト、LZJHの場合は50バイト）
未満の場合には、IPComp
を適用しないで次の処理
（ESPやAHの処理）を行います。圧縮対象となるデータの長さが
スレッショルド値以上の場合には、そのデータをIPCAで指定された圧縮アルゴリズムを
使用して圧縮します。
3.
圧縮したデータの前にIPCompヘッダを追加します。このIPCompヘッダの次ヘッダ番号
フィールドには、圧縮されたデータに含まれている最初のプロトコルヘッダの番号
（トラ
ンスポートモードの場合はTCPやUDPなどのプロトコル番号、トンネルモードの場合は
IPv4 または IPv6 のプロトコル番号）を入れます。IPComp ヘッダの CPI フィールドには、
IPCA の CPI 値を入れます。
4.
トランスポートモードの場合は、オリジナルの IPv4 ヘッダおよび IPv6 ヘッダを IPComp
ヘッダの前に追加し、その情報を更新します
（図8-6）
。IPv4ヘッダの場合は、全体長フィー
ルドに IPv4 ヘッダ、IPComp ヘッダ、そして圧縮後のデータの長さを足した値が入るよ
うに修正します。また、プロトコルフィールドに IPComp ヘッダの番号（108）を入れ、
チェックサムを再計算します。IPv6 ヘッダの場合は、ペイロード長フィールドに、IPv6
拡張ヘッダ、IPCompヘッダ、そして圧縮後のデータの長さを足した値が入るように修正
します。また、圧縮されていない最後のプロトコルヘッダの次ヘッダ番号フィールドに、
IPCompヘッダの番号
（108）
を入れます。トンネルモードの場合は、IPCompヘッダの前に
トンネル配送用の IP ヘッダを追加します（図 8-7）。
5.
ESP や AH の処理を行い、受信側に送信します。
プロトコル 次ヘッダ
=IPComp
=TCP
IPv4
ヘッダ
IPComp
ヘッダ
TCP
ヘッダ
データ
圧縮済みデータ
次ヘッダ 次ヘッダ
=IPComp
= 終点オプション
IPv6
ヘッダ
経路制御
ヘッダ
IPComp
ヘッダ
終点
オプション
ヘッダ
TCP
ヘッダ
データ
圧縮済みデータ
図 8-6 IPv4 および IPv6 における IPComp ヘッダの挿入位置（トランスポートモード）
8.6 IPComp 処理の流れ ● 147
プロトコル 次ヘッダ
=IPComp
=IPv4
トンネル
IPv4
ヘッダ
IPComp
ヘッダ
IPv4
ヘッダ
TCP
ヘッダ
データ
圧縮済みデータ
次ヘッダ
=IPComp
次ヘッダ
=IPv6
トンネル
IPv6
ヘッダ
IPComp
ヘッダ
IPv6
ヘッダ
終点
経路制御
オプション
ヘッダ
ヘッダ
TCP
ヘッダ
データ
圧縮済みデータ
図 8-7 IPv4 および IPv6 における IPComp ヘッダの挿入位置（トンネルモード）
8.6.2 受信側における処理（IPComp 入力処理）
1.
IP パケットを受信し、IPsec 処理が適用されている場合には、ESP や AH の入力処理を行
います。
2.
IPCompヘッダが存在する場合は、そのCPIフィールドより、使用されている圧縮アルゴ
リズムを判断します。
3.
圧縮済みデータを復元します。
4.
トンネルモードの場合は、復元されたIPパケットを該当ホストへ転送します。トランス
ポートモードの場合は、復元したデータを次のプロトコル処理に渡します。
参考文献
[1] A. Shacham, B. Monsour, R. Pereira, and M. Thomas, “IP Payload Compression Protocol
(IPComp)”, RFC 2393, December 1998.
[2] A. Shacham, B. Monsour, R. Pereira, and M. Thomas, “IP Payload Compression Protocol
(IPComp)”, RFC 3173, September 2001.
[3] R. Pereira, “IP Payload Compression Using DEFLATE”, RFC 2394, December 1998.
[4] R. Friend and R. Monsour, “IP Payload Compression Using LZS”, RFC 2395, December
1998.
[5] J. Heath and J. Border, “IP Payload Compression Using ITU-T V.44 Packet Method”, RFC
3051, January 2001.
149
9章
● 自動鍵管理プロトコルの必要性
● 鍵管理プロトコルの決定経緯
● IPsec における鍵管理プロトコルの構成
● IKE の持つ機能
● ISAKMP メッセージフォーマット
● IKE の動作
● IKE による折衝パラメータ
SA管理と鍵管理
IPsecでは、データの暗号化に共通鍵暗号を使用し、メッセージ認証にメッセージ認証コード
（MAC）を使用します。共通鍵暗号やMACでは二者の間で事前に秘密鍵を共有しておく必要があ
ります。また、暗号化や認証のためのアルゴリズムなどについても合意しておく必要があります。
IKE（Internet Key Exchange）[1]は、共有秘密鍵と SA の折衝と管理を自動で行うプロトコル
です。この章では、IKE の機能と動作について説明します。
9.1 自動鍵管理プロトコルの必要性
強度の高い暗号を使用していたとしても、時間をかければいつかは解読されてしまいます。暗
号が解読されるということは、暗号で使用している秘密鍵が知られてしまうということです。こ
のため、解読された場合の被害を最小限に抑えるために、普段からこの秘密鍵を頻繁に変更して
おく必要があります。しかし、秘密鍵の変更を手動で行うのは現実的ではないため、自動で鍵の
変更を行う鍵管理プロトコルが必要となります。
9.2 鍵管理プロトコルの決定経緯
IPsec で使用する鍵管理プロトコルの標準化作業は非常に難航しました。1994 年に Phil Karn
によってPhoturis
（ギリシャ語で蛍を意味します）
が、Sun Microsystems社によってSKIP
（Simple
Key-Management for Internet Protocols）がIPsecで使用する鍵管理プロトコルとして提案されま
した。また、1995 年に NSA によって ISAKMP（Internet Security Association and Key Management Protocol）が、1996 年にアリゾナ大学の Hilarie Orman によって Oakley が提案されました。
150 ● 9 章 SA 管理と鍵管理
NSAによって提案されたISAKMPは、SAと鍵の管理を行うためのプロトコルですが、実際の鍵
交換方式については定めていません。これに対して Oakley は鍵交換に特化したプロトコルで
†
あったため、ISAKMP と Oakley を組み合わせた ISAKMP/Oakley が提案されました。これに
より、IPsecで使用される鍵管理プロトコルとしてPhoturisとSKIP、そしてISAKMP/Oakleyの
3候補が争うことになりました。その後、Photurisの仕様の改定が進まなくなったため、候補は
ISAKMP/Oakley と SKIP の 2 つに絞られたのですが、IPSEC WG では、どちらを IPsec で使用
する鍵管理プロトコルとするのかを決定することができず、1996 年の 9 月に IETF のセキュリ
ティエリア長のJeffrey Schillerによって、ISAKMP/OakleyをIPv6では必須、IPv4ではオプショ
ンの鍵管理プロトコルとすることが発表されました。
その後、ISAKMP/Oakley は名称を IKE（Internet Key Exchange）と改め、1998 年 11 月に Proposed Standard（標準提案）の RFC 2409 [1] として公開されました。同時に、ISAKMP は、Proposed Standard（標準提案）の RFC 2408 [2] として、Oakley は、Informational（情報提供）の RFC
2412 [3] として公開されました（図 9-1）。
1994
1995
1996
1997
1998
Photuris
RFC 2522
RFC 2523
SKIP
ISAKMP
RFC 2408
Oakley
Oakley
ISAKMP/Oakley
ISAKMP/Oakley
RFC 2412
IKE
RFC 2409
図 9-1 鍵管理プロトコルの提案の歴史
9.3 IPsec における鍵管理プロトコルの構成
IPsec では、SA と共有秘密鍵を管理するためのフレームワークとして ISAKMP を、ISAKMP
フレームワーク上で動作する鍵管理プロトコルとして IKE（Internet Key Exchange）を定めまし
た（IKEとは別に、現在では、Kerberos を利用する鍵管理プロトコルであるKINK の開発が進め
られています）。IKE は IPsec での使用に特化したものではなく、汎用的に利用できるプロトコ
† 「アイサカンプオークレイ」と読みます。
9.3 IPsec における鍵管理プロトコルの構成 ● 151
ルとして開発されたため、セキュリティプロトコルに特有の部分はDOI（Domain of Interpretation）
として別に定義されています。このため、鍵管理プロトコルの仕様は、ISAKMP、IKE、DOIと
3 つに分かれており、複雑になってしまっています。このセキュリティプロトコルと ISAKMP、
IKE、DOI の関係を図 9-2 に示します。
セキュリティプロトコル
DOI
鍵管理プロトコル
TLS
TLS
DOI
KINK
SA 管理および鍵管理
フレームワーク
ISAKMP
AH
ESP
IPsec
DOI
IKE
IPComp
図 9-2 SA 管理および鍵管理における各仕様の関係（破線部は現在未定義）
9.3.1 ISAKMP
ISAKMP
（Internet Security Association and Key Management Protocol）
[2] は、セキュリティプ
ロトコルのSAと鍵の管理を行うためのプロトコルのフレームワークです。このフレームワーク
では、プロトコルのフォーマットやメッセージ交換の手順について定めていますが、実際の鍵交
換の仕組みについては定めていません。
9.3.2 IKE
実際の鍵交換の方法を定めたものとしては、Oakley [3] などがあります。この Oakley を
ISAKMP のフレームワーク上で動作させるようにしたものが、IKE（Internet Key Exchange）[1]
です。実際は IKE の仕様は、Oakley の機能の一部と、Hugo Krawczyk が提案した鍵交換プロト
コルであるSKEME（Secure Key Exchange Mechanism for Internet）[4] の機能の一部を取り入れ
て作られています。
152 ● 9 章 SA 管理と鍵管理
9.3.3 DOI
DOI（Domain of Interpretation）では、セキュリティプロトコルのSAで使用されるパラメータ
などを定めています。IPsec の SA と IPComp の IPCA（IPComp Association）を折衝するためのパ
ラメータは、IPsec DOI [5] において定義されており、次のものが含まれます。
ESP において使用する暗号化アルゴリズム
AH および ESP において使用する認証アルゴリズム
IPComp において使用する圧縮アルゴリズム
SA の有効期間
カプセル化モード（トンネルモードまたはトランスポートモード）
共有秘密鍵の長さ
など
9.3.4 ISAKMP SA
IPsec SAで使用されるパラメータの折衝を保護するために、ISAKMPセキュリティアソシエー
ション（ISAKMP SA）が使用されます。ISAKMP SA は IPsec SA と似ていますが、IPsec SA は単
方向であるのに対して ISAKMP の SA は双方向であるという点が大きく異なります。また、
ISAKMP SA には IPsec SAで使用される SPI 値の代わりに ISAKMPヘッダに存在する始動者クッ
キーと応答者クッキーの組（計16バイト）が使用されます。ISAKMP SAは、セキュリティプロト
コルの SA を折衝する際に使用されるメッセージの機密性と完全性の確保や、通信相手の認証、
リプレイ防御などのセキュリティ機能を提供します。
IKEでは、最初にISAKMP SAを確立します（このフェーズをフェーズ1と呼びます）。そして、
ISAKMP SAで保護された通信路を使用してセキュリティプロトコル用のSAを確立します（この
フェーズをフェーズ2と呼びます）。一度確立されたISAKMP SAは、その有効期間内であれば、
複数のフェーズ 2 の保護に利用することが可能です。表 9-1 に ISAKMP SA と IPsec SA の違いを
表 9-1 IKE で折衝される SA
IKE のフェーズ
フェーズ 1
フェーズ 2
折衝対象 SA
ISAKMP SA
IPsec SA（AH、ESP）、IPCA
方向
双方向
単方向
折衝 SA 本数
1本
セキュリティプロトコルごとに 2 本ずつ
SA の識別子
始動者クッキーと応答者クッキーの組
SPI 値または CPI 値を、フェーズ 2 折衝時
に始動者と応答者がそれぞれ指定
保護対象
IKE メッセージ
IP による通信
9.4 IKE の持つ機能 ● 153
まとめます。
9.4 IKE の持つ機能
ここでは IKE の持つ機能について説明します。
9.4.1 相手認証
秘密鍵を共有する際には、相手を認証する必要があります。IKEでは、AHまたはESPで使用
する秘密鍵を共有する前に相手を認証します。相手認証は、IKE のフェーズ 1 で行われます。
IKE では次の 4 種類の相手認証方式をサポートしています。
1.
事前共有秘密鍵認証方式
2.
デジタル署名認証方式（RSA、DSA、ECDSA）
3.
公開鍵暗号化認証方式（RSA または ElGamal）
4.
改良型公開鍵暗号化認証方式（RSA または ElGamal）
事前共有秘密鍵認証方式
事前共有秘密鍵認証方式では、あらかじめ何らかの方法で秘密の鍵を取り決めておき、互いに
同じ鍵を持っていることを確認することで相手を認証します。この秘密の鍵を事前共有秘密鍵と
呼びます。この方式では、あらかじめ事前共有秘密鍵を手動で設定しておく必要があります。
デジタル署名認証方式
デジタル署名認証方式では、互いに相手のデジタル署名を検証することによって相手を認証し
ます。デジタル署名のアルゴリズムには、RSA、DSA、ECDSA [6] などを使用します。
公開鍵暗号化認証方式
公開鍵暗号化認証方式では、乱数値を相手の公開鍵によって暗号化して送信し、その乱数値が
相手側で正しく復号化されたことを確認することによって相手を認証します。この方式で使用す
る公開鍵暗号には、RSA や ElGamal などがあります。
改良型公開鍵暗号化認証方式
公開鍵暗号化認証方式では、時間のかかる公開鍵暗号の処理を 4 回（暗号化 2 回、復号化 2 回）
行う必要があります。そこで、その回数を減らすように考え出されたのが、この改良型公開鍵暗
号化認証方式です。この改良型公開鍵暗号化認証方式では、公開鍵暗号による処理を 2 回（暗号
154 ● 9 章 SA 管理と鍵管理
化 1 回、復号化 1 回）で済ますことが可能です。この方式はオリジナルの公開鍵暗号化認証方式
を置き換えるものですが、オリジナルの公開鍵暗号化認証方式は、古い実装との互換性を維持す
るために残されています。
9.4.2 SA の折衝と管理
IKEでは、IPsecなどのセキュリティプロトコルのSAを折衝します。この折衝の内容はセキュ
リティプロトコルごとに異なり、それぞれのセキュリティプロトコルのDOIで定義されます。例
えば、IPsec の ESP を使用する場合には、IKE によって暗号化アルゴリズムの種類や SA の有効
期間などが折衝されますが、この折衝内容は IPsec DOI で定義されています。
SA の折衝は、IKE を開始する始動者（Initiator）が複数の SA パラメータの組み合わせを提案し
（これをプロポーザルと呼びます）、それに対して、応答者（Responder）がその中から1つの組み
合わせを選択することで行われます。
IKE のフェーズ 1 では、1 本の ISAKMP SA（ISAKMP SA は双方向）が生成されます。これに対
して、IKE のフェーズ 2 では、1 つのセキュリティプロトコルに対して 2 本の IPsec SA（それぞ
れの方向に 1 本ずつ）が生成されます。この 2 本の IPsec SA の方向や SPI 値は異なりますが、使
用するアルゴリズムや有効期間などは同じとなります。また、フェーズ2では、同時に複数のセ
キュリティプロトコルの折衝を行うことが可能です。例えば、ESP と AH を同時に使用する場
合には、フェーズ 2 において ESP の SA と AH の SA を同時に折衝します。この場合は、それぞ
れの方向に 2 本ずつ計 4 本の SA が確立されます。
プロポーザルの例
SA 折衝時のプロポーザルの例を表 9-2 に示します。この例では、プロポーザル番号 1 として、
ESP と IPComp の組み合わせを提案しています。また、この ESP と IPComp の組み合わせが拒
否された場合のために、プロポーザル番号 2 として ESP のみの使用を提案しています。ESP で
使用する暗号化アルゴリズムには、128 ビットの鍵を使用する AES -CBC または 3DES -CBC を提
案しており、ESP で使用する認証アルゴリズムには、HMAC-SHA（HMAC-SHA-1-96）または
HMAC-MD5（HMAC-MD5-96）を提案しています。このプロポーザルでは、3DES-CBCよりAES CBC が優先され、HMAC-MD5-96 より HMAC-SHA-1-96 が優先されます。また、IPComp の圧縮
アルゴリズムでは、DEFLATE より LZS が優先されます。
応答者は、これらの中から1つの組み合わせのみを選択し、始動者に返します。応答者が始動
者の第 1 希望の組み合わせを了解すれば、AES と HMAC-SHA-1-96 を使用する ESP と、LZS を使
用する IPComp の組み合わせが選択されることになります。
9.4 IKE の持つ機能 ● 155
表 9-2 IKE における IPsec SA プロポーザルの例
プロポーザル番号
プロトコル ID
トランスフォーム ID
SA 属性
1
IPSEC_ESP
ESP_AES
トンネルモード、鍵長 128 ビット、
HMAC-SHA による認証
IPCOMP
2
IPSEC_ESP
ESP_AES
トンネルモード、鍵長 128 ビット、
HMAC-MD5 による認証
ESP_3DES
トンネルモード、
HMAC-SHA による認証
ESP_3DES
トンネルモード、
HMAC-MD5 による認証
IPCOMP_LZS
トンネルモード
IPCOMP_DEFLATE
トンネルモード
ESP_AES
トンネルモード、鍵長 128 ビット、
HMAC-SHA による認証
ESP_AES
トンネルモード、鍵長 128 ビット、
HMAC-MD5 による認証
ESP_3DES
トンネルモード、
HMAC-SHA による認証
ESP_3DES
トンネルモード、
HMAC-MD5 による認証付
9.4.3 共有秘密鍵の管理
IKEの重要な機能の1つが共有秘密鍵の管理です。IKEでは、定期的に共有秘密鍵を変更しま
す。鍵の変更は Diffie-Hellman 鍵共有アルゴリズムによって行われます。
PFS（Perfect Forward Secrecy）
PFSとは、ある鍵が解読されたとしても、その解読された鍵情報からは、その後に生成された
別の鍵を解読することができない性質のことを言います（図9-3）。PFSを保証するためには、あ
る鍵の生成に使用された値を別の鍵の生成に使用してはいけません。PFSを有効にするとより安
全になりますが、鍵の生成にかかる処理が多くなります。IKEでは、PFSを有効にするかどうか
を選択することができるようになっています。
156 ● 9 章 SA 管理と鍵管理
解読した鍵 A の情報を使用
して他の鍵の解読を試みる
鍵 A を解読
鍵 B で暗号化されたパケット
（PFS が有効であれば安全）
鍵 A で暗号化されたパケット
（解読されてしまう）
送信側ホスト
受信側ホスト
図 9-3 PFS の有効性
9.5 ISAKMP メッセージフォーマット
ここでは、ISAKMP のメッセージフォーマットについて紹介します。図 9-4 に示すように、
ISAKMP はトランスポートプロトコルとして UDP（ポート 500）を使用し、ISAKMP ヘッダの後
に複数のISAKMPペイロードが続く構造になっています。ISAKMPペイロードには、表9-3に示
すようなペイロードが定義されています。ISAKMPのメッセージフォーマットは、ISAKMPの仕
様 [2] に記述されています。
IP ヘッダ
UDP ヘッダ
ISAKMP ヘッダ
ISAKMP ペイロード
ISAKMP ペイロード
図 9-4 ISAKMP プロトコル構造
9.5 ISAKMP メッセージフォーマット ● 157
表 9-3 ISAKMP ペイロードの種類
ペイロード番号
ペイロードの種類
0
予約（次ペイロードなしを示す）
1
SA（セキュリティアソシエーション）ペイロード
2
プロポーザルペイロード
3
トランスフォームペイロード
4
鍵交換ペイロード
5
ID ペイロード
6
証明書ペイロード
7
証明書要求ペイロード
8
ハッシュペイロード
9
署名ペイロード
10
乱数ペイロード
11
通知ペイロード
12
削除ペイロード
13
ベンダ ID ペイロード
14
属性ペイロード
15 ∼ 127
予約（未割り当て）
128 ∼ 255
プライベート用
†
† 属性ペイロードは ISAKMP-Config の仕様 [7] に記述されています。
9.5.1 ISAKMP ヘッダフォーマット
IKE を含む ISAKMP フレームワークを使用するプロトコルでは、UDP ヘッダの後に図 9-5 に
示す 28 バイトの ISAKMP ヘッダが続きます。この ISAKMP ヘッダの後に ISAKMP ペイロード
が続きます。
始動者クッキーフィールドおよび応答者クッキーフィールドには、それぞれ始動者または応答
者が生成したクッキー（0以外の乱数値）が入ります。IKE（ISAKMP）による折衝の間は必ずこの
2 つのクッキーが存在しますが、始動者から応答者へ送信される最初のメッセージには応答者
クッキーは存在せず、すべてのビットに 0 が入ります。
次ペイロード番号フィールドには、ISAKMP ヘッダに続く ISAKMP ペイロードのペイロード
番号が入ります。例えば、SAペイロードが続く場合には、このフィールドにはSAペイロードの
ペイロード番号である 1 が入ります。
158 ● 9 章 SA 管理と鍵管理
0
8
12
16
24
31
始動者クッキー
応答者クッキー
次ペイロード番号
メジャー
マイナー
バージョン バージョン
交換タイプ
フラグ
メッセージ ID
全メッセージ長
図 9-5 ISAKMP ヘッダのフォーマット
メジャーバージョン番号フィールドおよびマイナーバージョン番号フィールドには、ISAKMP
のプロトコルバージョンが入ります。RFC 2408 で示される ISAKMP のバージョンは 1.0 である
ため、メジャーバージョン番号フィールドには1、マイナーバージョン番号フィールドには0が
入ります。
交換タイプフィールドには、このメッセージが使用されている ISAKMP 交換の種類を示す値
が入ります。ISAKMP交換とは、SAの折衝やエラーの通知などの際に利用するメッセージの交
換の手順を定めたものです。この ISAKMP 交換の種類は表 9-4のように定義されています。IKE
ではこれらのうち、ID保護交換（IKEではメインモードと呼ばれます）、アグレッシブ交換（IKE
†
ではアグレッシブモードと呼ばれます）
、情報提供交換、トランザクション交換 、そしてIKEの
仕様で独自に定義されたクイックモードおよび新グループモードが使用されます。
フラグフィールドは、暗号化ビット
（E）
、コミットビット
（C）
、認証のみビット
（A）
からなりま
す（図 9-6）。ISAKMP ペイロードが ISAKMP SA によって暗号化されている場合は、暗号化ビッ
ト
（E）
が1となります。コミットビット（C）は、自ノードでのSAのセットアップが完了するまで、
暗号化されたメッセージの送信を待つように相手に伝える場合に使用されます。また、認証のみ
ビット
（A）は、ISAKMPペイロードを暗号化せずに、メッセージ認証のみを行う場合にセットさ
れます。通常は ISAKMP SA によって ISAKMP ペイロード部の暗号化とメッセージ認証の両方
が行われます。しかし、何らかの理由で暗号化せずに ISAKMP ペイロードのメッセージ認証の
†
トランザクション交換は ISAKMP-Config 拡張仕様 [7] で定義されています。
9.5 ISAKMP メッセージフォーマット ● 159
0
1
2
E
C
A
3
4
5
6
7
予約（全て 0）
図 9-6 フラグフィールドのフォーマット
表 9-4 ISAKMP 交換タイプ
値
ISAKMP 交換タイプ
0
予約
1
ベース交換
2
ID 保護交換（メインモード）
3
認証のみ交換
4
アグレッシブ交換（アグレッシブモード）
5
情報提供交換
6
トランザクション交換
7 ∼ 31
予約（未割り当て）
32 ∼ 239
DOI 特有の交換用
（32
クイックモード）
（33
新グループモード）
240 ∼ 255
プライベート用
みを行って送信する必要がある場合は、この認証のみビットを 1 とします。
メッセージ ID フィールドは、フェーズ 2 の折衝を識別するための値が入ります。このフィー
ルドには、フェーズ 1 の折衝中には 0 が、フェーズ 2 の折衝中にはフェーズ 2 の始動者によって
生成された値が入ります。
全メッセージ長フィールドには、ISAKMP ヘッダとすべての ISAKMP ペイロードを含むメッ
セージ全体の長さがバイト単位で入ります。
9.5.2 ISAKMP ペイロードフォーマット
ここでは、ISAKMPヘッダに続く、ISAKMPペイロードのフォーマットについてそれぞれ説明
します。
160 ● 9 章 SA 管理と鍵管理
SA ペイロードフォーマット
セキュリティアソシエーションペイロード（SA ペイロード）は、ISAKMP SA または IPsec SA
で使用されるパラメータの折衝のために使用されます。SA ペイロードには 1 つ以上のプロポー
ザルペイロードが含まれ、さらにプロポーザルペイロードには1つ以上のトランスフォームペイ
ロードが含まれます。
図 9-7 に示すように、始動者から応答者への SA の提案時には、優先順位をつけて複数の提案
（プロポーザル）を行うことが可能です。また、異なるセキュリティプロトコル（図 9-7 の例では
ESPとIPComp）のSAパラメータをまとめて折衝することも可能です。異なるセキュリティプロ
トコルの SA パラメータを同時に折衝する場合には、1 つの SA ペイロードの中に、複数のプロ
ポーザルペイロードが存在します。
応答者は、始動者が提案した複数の SA パラメータの組み合わせから、1 つの組み合わせを選
択して始動者に返します。
基本的なSAペイロードヘッダのフォーマットは、ISAKMPで定義されていますが、このヘッ
ダにはDOIで定義されるセキュリティプロトコル特有のフィールドが含まれています。図9-8に、
ISAKMP ヘッダ
SA ペイロードヘッダ
プロポーザルペイロードヘッダ
（プロポーザル番号 1：ESP）
第 1 希望の
ESP SA パラメータ
トランスフォームペイロード
（トランスフォーム番号 1）
第 2 希望の
ESP SA パラメータ
トランスフォームペイロード
（トランスフォーム番号 2）
プロポーザル
ペイロード
（ESP 用）
SA ペイロード
プロポーザルペイロードヘッダ
（プロポーザル番号 1：IPComp）
第 1 希望の
IPCA パラメータ
トランスフォームペイロード
（トランスフォーム番号 1）
第 2 希望の
IPCA パラメータ
トランスフォームペイロード
（トランスフォーム番号 2）
図 9-7 SA ペイロードの構成
プロポーザル
ペイロード
（IPComp 用）
9.5 ISAKMP メッセージフォーマット ● 161
0
8
16
次ペイロード番号
予約
24
31
ペイロード長
DOI（IPsec DOI）
シチュエーション
ラベル付ドメイン識別子
機密性長
予約
機密性レベル
（可変長）
機密性カテゴリ長
予約
機密性カテゴリビットマップ
（可変長）
インテグリティ長
予約
インテグリティレベル
（可変長）
インテグリティカテゴリ長
予約
インテグリティカテゴリビットマップ
（可変長）
図 9-8 SA ペイロードヘッダのフォーマット（IPsec DOI）
IPsec DOI で定義されている SA ペイロードヘッダのフォーマットを示します。
次ペイロード番号フィールドには、このSAペイロードに続くISAKMPペイロードのペイロー
ド番号が入ります。ただし、次ペイロード番号フィールドには、SAペイロードヘッダの後に続
くプロポーザルペイロードやトランスフォームペイロードのペイロード番号ではなく、SAペイ
ロード全体（プロポーザルペイロードおよびトランスフォームペイロードを含む）の後に続く
ISAKMPペイロード（例えば乱数ペイロードなど）の番号が入ります。SAペイロードに続くペイ
ロードが存在しない場合には 0 が入ります。
ペイロード長フィールドには、このSAペイロードヘッダと、その後に続くプロポーザルペイ
ロードヘッダ、トランスフォームペイロードを合わせたSAペイロード全体の長さがバイト単位
で入ります。
DOIフィールドには、折衝する対象となるセキュリティプロトコルのDOI値が入ります。IPsec
SA を折衝する場合は、IPsec DOI を示す 1 が入ります。
162 ● 9 章 SA 管理と鍵管理
シチュエーションフィールドには、必要なセキュリティサービスを決定するために使用される
値が入ります。IPsec DOI で定義されているシチュエーションは表 9-5 のようになります。
表 9-5 IPsec DOI シチュエーション
値
シチュエーション
1
SIT_IDENTITY_ONLY
2
SIT_SECRECY
4
SIT_INTEGRITY
シチュエーションフィールドの値が、IDペイロードの情報によってのみSAを確認することを
示すSIT_IDENTITY_ONLYであった場合には、SAペイロードヘッダのシチュエーションフィー
ルドの後には他のフィールドは存在せず、図 9-9 のようになります。
0
8
次ペイロード番号
16
予約
24
31
ペイロード長
DOI（IPsec DOI）
シチュエーション（SIT_IDENTITY_ONLY）
図 9-9 SIT_IDENTITY_ONLY の場合の SA ペイロードヘッダ
SAペイロードヘッダの後にはプロポーザルペイロードが続きます。プロポーザルペイロード
は、使用するセキュリティプロトコルの種類やSPI、そして、そのセキュリティプロトコルで使
用するアルゴリズム
（トランスフォーム）
を記述するためのペイロードです。ただし、実際のアル
ゴリズム
（トランスフォーム）
は、プロポーザルペイロード内のトランスフォームペイロードで記
述され、プロポーザルペイロードヘッダにはセキュリティプロトコルの種類とSPI、そしてその
プロポーザルの優先順位が記述されます。つまり、1つのプロポーザルペイロードには1つのセ
キュリティプロトコルの情報が記述されるため、異なるセキュリティプロトコルを同時に使用す
る場合（例えばESPとIPCompを同時に使用する場合）や、優先順位を付けて異なるセキュリティ
プロトコルを提案したい場合（例えば ESP を第 1 希望にして AH を第 2 希望とする場合）には、1
つの SA ペイロード内に複数のプロポーザルペイロードが存在することになります。
図 9-10 にプロポーザルペイロードヘッダのフォーマットを示します。
9.5 ISAKMP メッセージフォーマット ● 163
0
8
16
次ペイロード番号
予約
プロポーザル番号
プロトコルID
24
31
ペイロード長
SPI長
トランスフォーム数
セキュリティパラメータインデックス（SPI）
（可変長）
図 9-10 プロポーザルペイロードヘッダのフォーマット
次ペイロード番号フィールドには、このプロポーザルペイロードの後に続く同一SAペイロー
ド内のISAKMPペイロードのペイロード番号が入ります。ただし、プロポーザルペイロードヘッ
ダの次ペイロード番号フィールドには、後に続くトランスフォームペイロードのペイロード番号
ではなく、プロポーザルペイロード全体（プロポーザルペイロードヘッダと後に続くトランス
フォームペイロードを含む）
の後に続くISAKMPペイロードのペイロード番号が入ることに注意
してください。つまり、後に別のプロポーザルペイロードが続けば 2 が、後に別のプロポーザル
ペイロードが存在しなければ 0 が入り、それ以外のペイロード番号が入ることはありません。
ペイロード長フィールドには、このプロポーザルペイロードヘッダと後に続くトランスフォー
ムペイロードを合わせたプロポーザルペイロード全体の長さがバイト単位で入ります。
プロポーザル番号フィールドには、プロポーザルの優先順位が入ります。例えば、ESP と
IPComp の使用が第 1 希望であり、ESP のみの使用が第 2 希望であった場合には、前者の ESP お
よびIPCompを提案しているプロポーザルペイロードヘッダのプロポーザル番号フィールドには
それぞれ 1 が、後者の ESP を提案しているプロポーザルペイロードヘッダのプロポーザル番号
フィールドには 2 が入ります。
プロトコルIDフィールドには、ISAKMP SAの折衝時
（フェーズ1）
であればPROTO_ISAKMP
（1）
が、IPsec SA の折衝時（フェーズ 2）であれば、折衝するセキュリティプロトコルに応じて
PROTO_IPSEC_AH
（2）
、PROTO_IPSEC_ESP
（3）
、PROTO_IPCOMP
（4）
のいずれかが入ります。
SPI長フィールドには、SPIフィールドの長さがバイト単位で入ります。ISAKMP SAの折衝時
（フェーズ 1）には通常 0 が入り、SPI フィールドは存在しません。IPsec SA の折衝時（フェーズ
2）には SPI 長は 4 バイトとなります。また、IPComp の IPCA の折衝時には、この SPI 長フィー
ルドには、通常 CPI（Compression Parameter Index）の長さを示す 2 が入ります（4 が入る場合も
あります）。
トランスフォーム数フィールドには、このプロポーザルペイロードに含まれるトランスフォー
ムペイロードの数が入ります。トランスフォームペイロードにはプロポーザルペイロードヘッダ
164 ● 9 章 SA 管理と鍵管理
で指定したセキュリティプロトコルで使用するアルゴリズム（トランスフォーム）や、SAで使用
するパラメータ（有効期間など）が記述されます。
SPI フィールドには、指定したセキュリティプロトコルの SA を識別するための SPI 値が入り
ます。ただし、ISAKMP SA の折衝時（フェーズ 1）には、通常 SPI フィールドは存在せず、存在
したとしても、その値は無視されます。これは、フェーズ 1 で折衝される ISAKMP SA の SPI と
して、始動者クッキーと応答者クッキーを組み合わせた値が使用されるためです。また、IPComp
の IPCA を折衝する場合には、SPI フィールドに 2 バイトの CPI 値が入ります（SPI 長が 4 バイト
となっている場合には、2 バイトの CPI の前に 2 バイトの 0 のフィールドを追加して全体として
4 バイトとします）。IPsec SA の折衝時（フェーズ 2）には、プロポーザルペイロードを送信する
側（始動者および応答者）が生成した SPI 値が入ります。この SPI 値は自ノード宛の IPsec SA の
SPI として使用されます。
プロポーザルペイロードヘッダの後には、トランスフォームペイロードが続きます。トランス
フォームペイロードには、プロポーザルペイロードヘッダで指定したセキュリティプロトコルで
使用するアルゴリズム（トランスフォーム）
やSAで使用するその他のパラメータが記述されます。
このトランスフォームペイロードは、1つのプロポーザルペイロード中に複数存在することが可
能です。トランスフォームペイロードが複数存在する場合には、前に存在する方が優先的に評価
されます。つまり、あるセキュリティプロトコル
（例えばESP）
で複数のアルゴリズムを提案する
場合に、1 つめのトランスフォームペイロードで AES -CBC を指定し、2 つめのトランスフォー
ムペイロードで 3DES -CBC を指定した場合には、AES -CBC が第 1 希望となり、3DES -CBC は
第 2 希望となります。
図 9-11 に、トランスフォームペイロードのフォーマットを示します。
次ペイロード番号フィールドには、後に別のトランスフォームペイロードが続けば 3 が、後に
別のトランスフォームペイロードが存在しなければ 0 が入ります。
0
8
16
24
次ペイロード番号
予約
ペイロード長
トランスフォーム番号
トランスフォーム ID
予約
セキュリティアソシエーション属性（可変長）
図 9-11 トランスフォームペイロードのフォーマット
31
9.5 ISAKMP メッセージフォーマット ● 165
ペイロード長フィールドには、トランスフォームペイロード全体（次ペイロード番号フィール
ドからセキュリティアソシエーション属性フィールドまで）の長さがバイト単位で入ります。
トランスフォーム番号フィールドには、同一プロポーザルペイロード内におけるこのトランス
フォームペイロードの内容の優先順位が記述されます。最も優先順位が高いトランスフォームペ
イロードのトランスフォーム番号は 1 となります。
トランスフォーム ID フィールドには、プロポーザルペイロードヘッダで指定したセキュリ
ティプロトコルで使用するアルゴリズム（トランスフォーム）のID番号が記述されます。フェー
ズ1の折衝時であれば、KEY_IKE（1）が、フェーズ2のESPの折衝時であれば、ESP_AES（12）や
ESP_3DES（3）などが入ります（詳しくは「9.7 IKEによる折衝パラメータ」を参照してください）。
セキュリティアソシエーション属性フィールド（SA属性フィールド）には、1つ以上のSAパラ
メータ（SA 属性）に関する情報が入ります。SA 属性フィールド内で SA 属性情報を記述するため
のフォーマットは、SA 属性値が 16 ビット固定長の場合は図 9-12 のように、SA 属性値が可変長
の場合は図 9-13 のようになります。
0
8
A
F
属性タイプ
16
24
31
属性値
図 9-12 SA 属性フォーマット（属性値が固定長の場合： AF=1）
0
8
A
F
属性タイプ
16
24
31
属性長
属性値（可変長）
図 9-13 SA 属性フォーマット（属性値が可変長の場合： AF=0）
属性タイプフィールドには、フェーズ 1 の ISAKMP SA の折衝時には表 9-6 に示す属性タイプ
値が、フェーズ 2 の IPsec SA の折衝時には表 9-7 に示す属性タイプ値がそれぞれ指定されます。
これらの属性値の長さが固定長である場合には AF（Attribute Format）=1 となり、図 9-12 に示す
SA 属性フォーマットが使用されます。また、属性値の長さが可変長である場合には AF=0 とな
り、図 9-13 に示す SA 属性フォーマットが使用されます。
168 ページの図 9-14 に、フェーズ 1 メインモードにおける ISAKMP SA のプロポーザルの例を
示します。この例では、2つのトランスフォームペイロードを使用して2種類の提案を行ってい
166 ● 9 章 SA 管理と鍵管理
表 9-6 属性タイプ（ISAKMP SA）
属性タイプ値
属性タイプ
長さ
0
予約
−
1
暗号化アルゴリズム
固定長
2
ハッシュアルゴリズム
固定長
3
相手認証方式
固定長
4
Oakley グループ
固定長
5
グループタイプ
固定長
6
グループ素数 / 既約多項式
可変長
7
グループ原始元 1
可変長
8
グループ原始元 2
可変長
9
グループカーブ A
可変長
10
グループカーブ B
可変長
11
有効期間タイプ
固定長
12
有効期間
可変長
13
PRF（擬似乱数発生関数）
固定長
14
鍵長
固定長
15
有限体サイズ
固定長
16
グループオーダー
可変長
17 ∼ 16,383
予約（未割り当て）
―
16,384 ∼ 32,767
プライベート用
―
属性タイプ値
属性タイプ
長さ
0
予約
−
1
SA 有効期間タイプ
固定長
2
SA 有効期間
可変長
3
Oakley グループ
固定長
4
カプセル化モード
固定長
5
認証アルゴリズム
固定長
6
鍵長
固定長
7
鍵ラウンド
固定長
8
圧縮辞書サイズ
固定長
表 9-7 属性タイプ（IPsec SA）
9.5 ISAKMP メッセージフォーマット ● 167
表 9-7 属性タイプ（IPsec SA）
（つづき）
属性タイプ値
属性タイプ
長さ
9
圧縮プライベートアルゴリズム
可変長
10
ECN トンネル
固定長
11 ∼ 32,000
予約（未割り当て）
―
32,001 ∼ 32,767
プライベート用
―
ます。この場合は、AES -CBCによる暗号化（トランスフォーム1）が第1希望となり、3DES -CBC
による暗号化（トランスフォーム 2）が第 2 希望となります。
また、図 9-15 に、フェーズ 2 クイックモードにおける IPsec SA のプロポーザルの例を示しま
す。この例では、最初に ESP と IPComp の組み合わせが折衝されます（プロポーザル 1）。1 つめ
のプロポーザルペイロードでは、ESPのアルゴリズム（トランスフォーム）として2つ提案されて
います。1 つめは AES -CBC による暗号化（ESP のトランスフォーム 1）で、2 つめは 3DES -CBC
による暗号化（ESPのトランスフォーム2）です。IPCompのアルゴリズム（トランスフォーム）と
しては DEFLATE のみが提案されています。この ESP と IPComp の組み合わせ（プロポーザル 1）
の折衝に失敗した場合は、次の ESP 単独での使用が折衝されます（プロポーザル 2）。このプロ
ポーザルペイロードではアルゴリズム（トランスフォーム）は 1 つだけ提案されており、3DES CBC による暗号化が折衝されます。
鍵交換ペイロード
xi
xr
鍵交換ペイロードは、Diffie-Hellman鍵共有アルゴリズムで使用する公開値
（g およびg ）
を運
ぶために使用されます。鍵交換ペイロードのフォーマットを図 9-16（170 ページ）に示します。
ID ペイロード
ID ペイロードは、自分の身元を示す ID を相手に通知するために使用されます。ID ペイロー
ドの基本的なフィールドは ISAKMP で定義されていますが、DOI で定義されるセキュリティプ
ロトコル特有のフィールドも存在します。図 9-17 に、IPsec DOI で定義されている ID ペイロー
ドのフォーマットを示します。
IDタイプフィールドには表9-8に示す IDタイプが入ります。プロトコルIDフィールドとポー
トフィールドには、折衝するSAで運ばれるトラフィックのプロトコル番号とポート番号が入り
ます。折衝する SA で運ばれるトラフィックのプロトコルに制限を設けない場合には、「any」で
あることを示す 0 が入ります。フェーズ 1 では、ISAKMP SA で運ばれる IKE パケットのプロト
コル番号（UDP：17）とポート番号（500）が入るか、またはどちらにも 0 が入ります。
168 ● 9 章 SA 管理と鍵管理
0
8
12
16
31
24
始動者クッキー≠ 0
応答者クッキー =0
ISAKMP ヘッダ
次ペイロード =1
1
0
メインモード
0 0 0
予約
メッセージ ID=0
全メッセージ長 =120 バイト
次ペイロード =0
予約
SA ペイロード長 =92 バイト
SA ペイロード
ヘッダ
DOI=IPsec DOI
シチュエーション =SIT_IDENTITY_ONLY
プロポーザルペイロード長 =80 バイト
次ペイロード =0
予約
プロポーザル #1
PROTO_ISAKMP
次ペイロード =3
予約
トランスフォームペイロード長 =36 バイト
トランスフォーム #1
KEY_IKE
予約
SPI 長 =0
トランスフォーム数 =2
1
暗号化アルゴリズム
AES-CBC
1
ハッシュアルゴリズム
SHA
1
相手認証方式
RSA 署名
1
Oakley グループ
1,536 ビット MODP グループ
1
有効期間タイプ
秒
0
有効期間
属性長 =4 バイト
プロポーザル
ペイロードヘッダ
トランスフォーム
ペイロード 1
43,200（秒）
次ペイロード =0
予約
トランスフォームペイロード長 =36 バイト
トランスフォーム #2
KEY_IKE
予約
1
暗号化アルゴリズム
3DES-CBC
1
ハッシュアルゴリズム
SHA
1
相手認証方式
RSA 署名
1
Oakley グループ
1,024 ビット MODP グループ
1
有効期間タイプ
秒
0
有効期間
属性長 =4 バイト
トランスフォーム
ペイロード 2
43,200（秒）
図 9-14 ISAKMP SA プロポーザルの例（メインモード）
9.5 ISAKMP メッセージフォーマット ● 169
0
8
12
16
31
24
始動者クッキー≠ 0
応答者クッキー≠ 0
ISAKMPヘッダ
次ペイロード =1
1
0
クイックモード
1 0 0
予約
メッセージ ID ≠ 0
全メッセージ長 =228 バイト
次ペイロード =0
予約
SA ペイロード長 =200 バイト
SAペイロード
ヘッダ
DOI=IPsec DOI
シチュエーション =SIT_IDENTITY_ONLY
次ペイロード =2
予約
プロポーザルペイロード長 =76 バイト
プロポーザル #1
PROTO_IPSEC_ESP
SPI 長 =4 バイト トランスフォーム数 =2
プロポーザル
ペイロードヘッダ
SPI
次ペイロード =3
予約
トランスフォームペイロード長 =32 バイト
トランスフォーム #1
ESP_AES
予約
トランスフォーム
ペイロード
ESP SA 属性
次ペイロード =0
予約
トランスフォームペイロード長 =32 バイト
トランスフォーム #2
ESP_3DES
予約
トランスフォーム
ペイロード
ESP SA 属性
次ペイロード =2
予約
プロポーザルペイロード長 =36 バイト
プロポーザル #1
PROTO_IPCOMP
SPI 長 =4 バイト トランスフォーム数 =1
プロポーザル
ペイロードヘッダ
CPI
次ペイロード =0
予約
トランスフォームペイロード長 =24 バイト
トランスフォーム #1
IPCOMP_DEFLATE
予約
トランスフォーム
ペイロード
IPComp IPCA 属性
次ペイロード =0
予約
プロポーザルペイロード長 =44 バイト
プロポーザル #2
PROTO_IPSEC_ESP
SPI 長 =4 バイト トランスフォーム数 =1
プロポーザル
ペイロードヘッダ
SPI
次ペイロード =0
予約
トランスフォームペイロード長 =32 バイト
トランスフォーム #1
ESP_3DES
予約
トランスフォーム
ペイロード
ESP SA 属性
図 9-15 IPsec SA プロポーザルの例（クイックモード）
170 ● 9 章 SA 管理と鍵管理
0
8
16
次ペイロード番号
24
予約
31
ペイロード長
鍵交換データ（可変長）
図 9-16 鍵交換ペイロードのフォーマット
0
8
16
24
次ペイロード番号
予約
ペイロード長
ID タイプ
プロトコルID
ポート
31
ID データ（可変長）
図 9-17 ID ペイロードのフォーマット（IPsec DOI）
表 9-8 ID タイプフィールドの値（IPsec DOI）
値
ID タイプ
長さ
説明
0
予約
─
使用されない
1
ID_IPV4_ADDR
4 バイト
IPv4 アドレス
2
ID_FQDN
可変長
ホスト名（FQDN）
3
ID_USER_FQDN
可変長
ユーザ名（ユーザ FQDN）
4
ID_IPV4_ADDR_SUBNET
8 バイト
IPv4 アドレス＋ネットマスク
5
ID_IPV6_ADDR
16 バイト
IPv6 アドレス
6
ID_IPV6_ADDR_SUBNET
32 バイト
IPv6 アドレス＋ネットマスク
7
ID_IPV4_ADDR_RANGE
8 バイト
範囲指定した IPv4 アドレス
8
ID_IPV6_ADDR_RANGE
32 バイト
範囲指定した IPv6 アドレス
9
ID_DER_ASN1_DN
可変長
X.500 Distinguished Name
10
ID_DER_ASN1_GN
可変長
X.500 General Name
9.5 ISAKMP メッセージフォーマット ● 171
表 9-8 ID タイプフィールドの値（IPsec DOI）
（つづき）
値
ID タイプ
長さ
説明
11
ID_KEY_ID
可変長
バイトストリーム
12 ∼ 248
予約（未割り当て）
─
─
249 ∼ 255
プライベート用
─
─
証明書ペイロード
証明書ペイロードは、認証のために使用される公開鍵証明書を運ぶために使用されます。証明
書ペイロードのフォーマットを図 9-18 に示します。
0
8
次ペイロード番号
16
予約
24
31
ペイロード長
証明書タイプ
証明書データ（可変長）
図 9-18 証明書ペイロードのフォーマット
証明書タイプフィールドには、X.509公開鍵証明書やPGP証明書などの証明書データフィール
ドに格納されている証明書の種別が入ります。この証明書ペイロードや次に説明する証明書要求
ペイロードにおいて使用可能な証明書タイプは表 9-9 のとおりです。
証明書要求ペイロード
証明書要求ペイロードは、証明書を送信するように相手に要求する場合に使用されます。証明
書要求ペイロードのフォーマットを図 9-19 に示します。
証明書タイプフィールドには、表 9-9 に示す証明書の種別（X.509 公開鍵証明書や PGP 証明書
など）
が入ります。また、CAフィールドには、要求者が受け入れることのできる証明書の発行者
（認証局）
のDN（Distinguished Name）
が入ります。ただし、特定の認証局を必要としない場合は、
このフィールドを含めてはいけません。
172 ● 9 章 SA 管理と鍵管理
表 9-9 証明書タイプフィールドの値
値
証明書の種類
0
予約
1
X.509 公開鍵証明書（PKCS #7 形式†）
2
PGP 証明書
3
DNS 署名鍵
4
X.509 公開鍵証明書（署名）
5
X.509 公開鍵証明書（鍵交換）
6
Kerberos トークン
7
CRL（Certificate Revocation List：証明書失効リスト）
8
ARL（Authority Revocation List：認証局失効リスト）
9
SPKI（Simple Public Key Infrastructure）証明書††
10
X.509 属性証明書
11 ∼ 255
予約（未割り当て）
† Public Key Cryptography Standards #7 - Cryptographic Message Syntax Standard：RSA Security社が規定した証明
書配布形式
†† Experimental（実験的仕様）としてRFC 2692およびRFC 2693に記述されています。
0
8
次ペイロード番号
16
予約
24
ペイロード長
証明書タイプ
CA（可変長）
図 9-19 証明書要求ペイロードのフォーマット
31
9.5 ISAKMP メッセージフォーマット ● 173
ハッシュペイロード
ハッシュペイロードは、ISAKMPメッセージの完全性の確保やメッセージの送信元認証のため
に使用される認証データを運ぶために使用されます。ハッシュペイロードのフォーマットを
図 9-20 に示します。
0
8
次ペイロード番号
16
予約
24
31
ペイロード長
ハッシュデータ（可変長）
図 9-20 ハッシュペイロードのフォーマット
署名ペイロード
署名ペイロードは、相手認証方式としてデジタル署名認証方式を選択した場合にフェーズ1で
使用されます。署名ペイロードのフォーマットを図 9-21 に示します。
0
8
次ペイロード番号
16
予約
24
31
ペイロード長
署名データ（可変長）
図 9-21 署名ペイロードのフォーマット
署名データフィールドには、ISAKMP SAで折衝されたデジタル署名アルゴリズム
（RSA、DSS、
ECDSA）によって生成された署名データが入ります。
乱数ペイロード
乱数ペイロードは、セッションの維持を確認し、リプレイ攻撃から防御するために使用される
乱数データを相手に送信するために使用されます。乱数ペイロードのフォーマットを図 9-22 に
示します。
174 ● 9 章 SA 管理と鍵管理
0
8
次ペイロード番号
16
予約
24
31
ペイロード長
乱数データ（可変長）
図 9-22 乱数ペイロードのフォーマット
通知ペイロード
通知ペイロードは、IKEの処理中にエラーが生じた場合のエラー内容や、自ノードの状態を相
手に通知するために使用されます。この通知ペイロードは、「9.6.3 その他のメッセージ交換」
で
説明する ISAKMP 情報提供交換で使用されます。通知ペイロードのフォーマットを図 9-23 に示
します。
0
8
次ペイロード番号
16
予約
24
31
ペイロード長
DOI
プロトコル ID
SPI長
通知メッセージタイプ
セキュリティパラメータインデックス（SPI）
（可変長）
通知データ（可変長）
図 9-23 通知ペイロードのフォーマット
DOI（Domain of Interpretation）フィールドには、IPsec DOIの場合には1が入ります。プロト
コルIDフィールドには、ISAKMP SAの場合にはPROTO_ISAKMP（1）が、IPsec SA（AH、ESP、
IPComp）の場合には、PROTO_IPSEC_AH
（2）、PROTO_IPSEC_ESP（3）、PROTO_IPCOMP（4）
が入ります。また、SPI長フィールドには、SPIフィールドの長さがバイト単位で入り、ISAKMP
SA の場合は 0 ∼ 16（バイト）、IPsec SA の場合は 4（バイト）となります（ISAKMP の場合は、SPI
は始動者クッキーと応答者クッキーの組になります）。
通知メッセージタイプフィールドには、使用するメッセージの種類に応じた値が入ります。通
9.5 ISAKMP メッセージフォーマット ● 175
知メッセージは、エラータイプとステータスタイプの2つに分けられます。通知メッセージとそ
の通知メッセージタイプの値は表 9-10、表 9-11 のとおりです。
表 9-10 通知メッセージタイプ（エラータイプ）
値
通知メッセージ
意味
1
INVALID-PAYLOAD-TYPE
不正ペイロードタイプ
2
DOI-NOT-SUPPORTED
サポート外 DOI
3
SITUATION-NOT-SUPPORTED
サポート外シチュエーション
4
INVALID-COOKIE
不正クッキー値
5
INVALID-MAJOR-VERSION
不正メジャーバージョン値
6
INVALID-MINOR-VERSION
不正マイナーバージョン値
7
INVALID-EXCHANGE-TYPE
不正交換タイプ
8
INVALID-FLAGS
不正フラグ値
9
INVALID-MESSAGE-ID
不正メッセージ ID
10
INVALID-PROTOCOL-ID
不正プロトコル ID
11
INVALID-SPI
不正 SPI 値
12
INVALID-TRANSFORM-ID
不正トランスフォーム ID
13
ATTRIBUTES-NOT-SUPPORTED
サポート外属性タイプ
14
NO-PROPOSAL-CHOSEN
プロポーザル選択不可
15
BAD-PROPOSAL-SYNTAX
不正プロポーザルフォーマット
16
PAYLOAD-MALFORMED
不正ペイロードフォーマット
17
INVALID-KEY-INFORMATION
不正鍵情報
18
INVALID-ID-INFORMATION
不正 ID
19
INVALID-CERT-ENCODING
不正証明書タイプ
20
INVALID-CERTIFICATE
不正証明書フォーマット
21
CERT-TYPE-UNSUPPORTED
サポート外証明書タイプ
22
INVALID-CERT-AUTHORITY
不正認証局情報
23
INVALID-HASH-INFORMATION
不正ハッシュ値
24
AUTHENTICATION-FAILED
認証失敗
25
INVALID-SIGNATURE
不正署名
26
ADDRESS-NOTIFICATION
アドレス通知
27
NOTIFY-SA-LIFETIME
SA 有効期間通知
28
CERTIFICATE-UNAVAILABLE
証明書利用不可
176 ● 9 章 SA 管理と鍵管理
（つづき）
表 9-10 通知メッセージタイプ（エラータイプ）
値
通知メッセージ
意味
29
UNSUPPORTED-EXCHANGE-TYPE
サポート外交換タイプ
30
UNEQUAL-PAYLOAD-LENGTHS
ペイロード長不一致
31 ∼ 8,191
予約（未割り当て）
─
8,192 ∼ 16,383
プライベート用
─
表 9-11 通知メッセージタイプ（ステータスタイプ）
値
通知メッセージ
意味
16,384
CONNECTED
SA のセットアップの完了通知
16,385 ∼ 24,575
予約（未割り当て）
─
24,576 ∼ 32,767
DOI 特有コード
─
24,576
RESPONDER-LIFETIME （IPsec DOI）
応答者が選択した IPsec SA の
有効期間の通知
24,577
REPLAY-STATUS （IPsec DOI）
リプレイ防御機能の有無の通知
24,578
INITIAL-CONTACT （IPsec DOI）
交換情報の初期化通知
32,768 ∼ 40,959
プライベート用
─
40,960 ∼ 65,535
予約
─
削除ペイロード
削除ペイロードは、送信側が SAD から削除して無効となった SA の情報を相手に通知します。
これにより、受信側は該当する SA を自身の SAD から削除します。1 つの削除ペイロード中に、
複数のSAの情報を記述することが可能です。この削除ペイロードは、ISAKMP情報提供交換で
使用されます。削除ペイロードのフォーマットを図 9-24 に示します。
DOI（Domain of Interpretation）フィールドには、IPsec DOIの場合は1 が入ります。プロトコ
ル ID フィールドには、ISAKMP SA の場合には PROTO_ISAKMP（1）が、IPsec SA（AH、ESP、
I P C o m p ）の場合には、それぞれ P R O T O _ I P S E C _ A H（2 ）、P R O T O _ I P S E C _ E S P（3 ）、
PROTO_IPCOMP（4）が入ります。また、SPI長フィールドには、SPIフィールドの長さがバイト
単位で入り、ISAKMP SAの場合は16
（バイト）
、IPsec SAの場合は4（バイト）
となります
（ISAKMP
SA の場合は、SPI は始動者クッキーと応答者クッキーの組になります）。
9.5 ISAKMP メッセージフォーマット ● 177
0
8
16
次ペイロード番号
予約
24
31
ペイロード長
DOI
プロトコル ID
SPI 長
SPI 数
セキュリティパラメータインデックス（SPI）
（可変長）
・・・
セキュリティパラメータインデックス（SPI）
（可変長）
図 9-24 削除ペイロードのフォーマット
ベンダ ID ペイロード
ベンダ ID ペイロードは、自ノードの実装の持つ機能を相手に通知するために使用されます。
ベンダ ID ペイロードのフォーマットを図 9-25 に示します。
0
8
次ペイロード番号
16
予約
24
31
ペイロード長
ベンダID（可変長）
図 9-25 ベンダ ID ペイロードのフォーマット
ベンダ ID フィールドには、ベンダが自身の実装を識別するために独自に定義した文字列や、
IKE の拡張仕様で定義した文字列に対するハッシュ値などが入ります。例えば、Windows 2000
の場合には、ベンダIDフィールドには “MS NT5 ISAKMPOAKLEY” という文字列をMD5でハッ
シュした結果 “1e2b 5169 0599 1c7d 7c96 fcbf b587 e461”（16 バイト）と、バージョン番号（4 バイ
ト）の計 20 バイトが入ります。
178 ● 9 章 SA 管理と鍵管理
9.6 IKE の動作
ここでは、IKE のプロトコル動作について説明します。IKE は主に 2 つのフェーズ（フェーズ
1 およびフェーズ 2）からなり、その他にいくつかの交換が用意されています（表 9-12）。IKE の
フェーズ 1 では ISAKMP SA を確立し、フェーズ 2 では IPsec などのセキュリティプロトコルの
SA を確立します。フェーズ2 では、フェーズ 1 で折衝された ISAKMP SAによってセキュリティ
が確保されます。
表 9-12 IKE で使用される交換
フェーズ
交換の種類
内容
フェーズ 1
メインモード
アグレッシブモード
ISAKMP SA の折衝を行う
フェーズ 2
クイックモード
セキュリティプロトコルの SA（IPsec SA など）の
折衝を行う
その他
新グループモード
新しい Oakley グループの折衝を行う
その他
ISAKMP 情報提供交換
折衝中のエラーの通知や SA の消去に関する通知を
行う
その他
トランザクション交換
ISAKMP-Config や XAUTH で使用する情報を交換
する
9.6.1 ISAKMP SA の確立（フェーズ 1 ）
IKE のフェーズ 1 の目的は、ISAKMP SA を確立することです。フェーズ 1 では次のことを行
います。
1.
ISAKMP SA の折衝
2.
ISAKMP SA で使用される共有秘密鍵の生成
3.
相手の認証
フェーズ 1 によって信頼できる相手との間に ISAKMP SA が確立され、安全な通信路が生成さ
れます。フェーズ 1 では、IKE メッセージを暗号化するための暗号化アルゴリズムや IKE メッ
セージの完全性を確保するためのハッシュアルゴリズムなどの折衝、これらのアルゴリズムで使
用する共有秘密鍵の交換、相手の認証などが行われます。
フェーズ1には、メインモードとアグレッシブモードの2つのモードが存在します。どちらの
モードを使用しても同じ結果となりますが、使用されるメッセージの数や折衝に関する制限など
9.6 IKE の動作 ● 179
が異なります。アグレッシブモードは、メインモードよりも通信の回数が少なくて済むという特
徴がありますが、ID の保護や折衝の範囲に制限があります。また、フェーズ 1 では、相手認証
方式によって使用されるメッセージの内容が異なります。つまり、メインモードとアグレッシブ
モードの 2 種類のモードがあり、さらに相手認証方式が 4 種類あるため、フェーズ 1 におけるメッ
セージの交換には計 8 種類の方式が存在することになります。
メインモードとアグレッシブモードの違いを表 9-13 に、相手認証方式の違いによるフェーズ
1 交換の特徴を表 9-14 にまとめます。
表 9-13 メインモードとアグレッシブモードの比較
メインモード
アグレッシブモード
メッセージの数
6
3
ID の保護
保護される
公開鍵暗号化認証方式または改良型公開
鍵暗号化認証方式を使用した場合は保護
されるが、その他の場合は保護されない
SA の折衝に関する制限
なし
Oakley グループの折衝ができない
リモートアクセス時の
認証に関する制限
認証に事前共有秘密鍵が
使用できない
なし
実装上の条件
実装上必須
オプション
表 9-14 認証方式の違いによるフェーズ 1 交換の特徴
事前共有
秘密鍵認証
デジタル署名認証
公開鍵暗号化認証
改良型公開鍵
暗号化認証
ID の保護
メインモードの
み保護される
メインモードの
み保護される
保護される
保護される
認証情報
事前に秘密鍵を
共有しておく
公開鍵証明書を署
名と同時に送信
事前に相手の公開
鍵を取得しておく
始動者は事前に応
答者の公開鍵を取
得しておく
第三者に対する
アクセス否認
可
不可
可
可
交換に必要な公開
鍵暗号処理
なし
2回
（署名処理 1 回
検証処理 1 回）
4回
（暗号化処理 2 回
復号化処理 2 回）
2回
（暗号化処理 1 回
復号化処理 1 回）
180 ● 9 章 SA 管理と鍵管理
鍵およびハッシュの生成法
フェーズ 1 では、次のように鍵を計算します。
xy
SKEYID_d = prf (SKEYID, g | CKY-I | CKY-R | 0)
xy
SKEYID_a = prf (SKEYID, SKEYID_d | g | CKY-I | CKY-R | 1)
xy
SKEYID_e = prf (SKEYID, SKEYID_a | g | CKY-I | CKY-R | 2)
SKEYID_d は、IPsec SA などの ISAKMP SA 以外の SA で使用される共有秘密鍵を生成するた
めの鍵素材として使用します。SKEYID_a は、ISAKMP SA においてメッセージを認証するため
の共有秘密鍵として使用します。また、SKEYID_eは、ISAKMP SA においてメッセージの暗号
化を行うための共有秘密鍵として使用します。
prf（ ）は、ISAKMP SAの PRF 属性で指定された擬似乱数発生関数です。擬似乱数発生関数が
指定されない場合には、フェーズ 1 で折衝されたハッシュアルゴリズムを使用した HMAC が擬
似乱数発生関数として使用されます。prf（key, msg）は、key を鍵として msg に対して擬似乱数
発生関数（HMAC）を適用することを示します。ここで、“|”は、前後のメッセージを連結するこ
とを示します。つまり、SKEYID_d、SKEYID_a、SKEYID_e は、SKEYID を鍵として、その後
に指定するさまざまな値を連結したメッセージに対して擬似乱数発生関数
（HMAC）
を適用するこ
xy
とにより計算されます。g は、Diffie-Hellman鍵共有アルゴリズムによる鍵交換で生成された共
有値を示します。CKY-I は、始動者クッキー（8 バイト）を、CKY-R は応答者クッキー（8 バイト）
を示します。最後の0、1、2という値は1バイトの数値で表されます。擬似乱数発生関数の鍵と
して使用される SKEYID は、認証方式の種類に応じてそれぞれ次のように計算されます。
事前共有秘密鍵認証方式：SKEYID = prf (事前共有秘密鍵 , Ni_b | Nr_b)
xy
デジタル署名認証方式：SKEYID = prf (Ni_b | Nr_b, g )
公開鍵暗号化認証方式：SKEYID = prf (hash(Ni_b | Nr_b), CKY-I | CKY-R)
改良型公開鍵暗号化認証方式：SKEYID = prf (hash(Ni_b | Nr_b), CKY-I | CKY-R)
ここで、Ni_b および Nr_b は、それぞれ始動者または応答者が送信した乱数ペイロードの
ISAKMP共通ペイロードヘッダ部
（最初の4バイト）を除いた部分を示します。hash（ ）
は、フェー
ズ 1 で折衝されたハッシュアルゴリズムを適用することを示します。
しかし、HMAC の出力は MD5 などを使用した場合は 128 ビット、SHA-1 を使用した場合でも
160ビットであるため、使用する暗号化アルゴリズムによっては鍵の長さが足りない可能性があ
ります。生成された鍵の長さが短い場合には、次のように新たに鍵 Ka を生成します。
Ka = K1 | K2 | K3
K1 = prf (SKEYID_e, 0)
9.6 IKE の動作 ● 181
K2 = prf (SKEYID_e, K1)
K3 = prf (SKEYID_e, K2)
また、ハッシュペイロード中で運ばれるハッシュ値は、次のように計算します。
ハッシュ（始動者）= prf (SKEYID, gxi | gxr | CKY-I | CKY-R | SAi_b | IDii_b)
ハッシュ（応答者）= prf (SKEYID, gxr | gxi | CKY-R | CKY-I | SAi_b | IDir_b)
xi
xr
ここで、g およびg は、それぞれ鍵交換ペイロードで運ばれる始動者または応答者のDiffieHellman 公開値を示します。また、SAi_b は、始動者が送信した SA ペイロードの ISAKMP 共通
ペイロードヘッダ部（最初の 4 バイト）を除いた部分を示します。IDii_b および IDir_b は、それ
ぞれ始動者または応答者が送信した ID ペイロードの ISAKMP 共通ペイロードヘッダ部（最初の
4 バイト）を除いた部分を示します。
メインモード
メインモードは、ISAKMP における ID 保護交換を IKE において具体化したものであり、始動
者および応答者のID情報を保護することが可能です。メインモードでは6つのメッセージによっ
て ISAKMP SA を確立します。最初の 2 つのメッセージで SA の内容を折衝し、次の 2 つのメッ
セージで秘密鍵を共有します。そして最後の2つのメッセージを使用して、互いに相手の認証を
行います。メインモードの間は、ISAKMPヘッダの交換タイプフィールドに、メインモードであ
ることを示す 2 が入ります。
このメインモードのメッセージの内容は、相手認証方式によって異なります。事前共有秘密鍵認
証方式、デジタル署名認証方式、公開鍵暗号化認証方式、改良型公開鍵暗号化認証方式の4種類の
相手認証方式を使用したメインモードにおけるメッセージの流れについてそれぞれ説明します。
事前共有秘密鍵認証方式を使用した場合のメインモード
図 9-26 に、事前共有秘密鍵認証方式を使用した場合のメインモードにおけるメッセージの流
れと、使用される ISAKMP ペイロードを示します。
始動者および応答者は、あらかじめ入手済みの事前共有秘密鍵に加えて、3つめと4つめのメッ
セージの交換によって、始動者および応答者の Diffie-Hellman 公開値（gxi および gxr）、始動者お
よび応答者の乱数値（Ni_bおよびNr_b）、始動者および応答者のクッキー（CKY-IおよびCKY-R）
を共有します。始動者と応答者はそれぞれ、これらの値から共有秘密鍵（SKEYID、SKEYID_d、
SKEYID_a、SKEYID_e）
を計算します。5つめと6つめのメッセージでは、この生成されたSKEYID
を鍵として計算したハッシュ値を含むハッシュペイロードを付加し、S K E Y I D _ e によって
ISAKMPペイロード全体を暗号化します。これにより始動者と応答者のIDを保護することが可
182 ● 9 章 SA 管理と鍵管理
始動者
応答者
SA パラメータの提案
ISAKMP ヘッダ
SA
②
ISAKMP ヘッダ
鍵交換
乱数（始動者）
SA パラメータの選択
始動者の鍵情報
④
⑥
ISAKMP ヘッダ
SA
③
ISAKMP ヘッダ
鍵交換
乱数（応答者）
応答者の鍵情報
始動者の ID
始動者の認証情報
ISAKMP ヘッダ
ID（始動者）
ハッシュ（始動者）
①
応答者の ID
応答者の認証情報
⑤
ISAKMP ヘッダ
ID（応答者）
ハッシュ（応答者）
図 9-26 事前共有秘密鍵認証方式を使用したメインモード（網掛部は暗号化）
能となります。5 つめと 6 つめのメッセージでは、SKEYID_e によって ISAKMP ペイロード全体
を暗号化し、ISAKMP ヘッダのフラグフィールドの暗号化ビットを 1 とします。
事前共有秘密鍵は、通常、通信相手ごとに異なるものを使用します。しかし、メインモードで
は、相手を識別するIDは最後に交換されるため、その前に相手を識別する情報はIPアドレスし
かありません。つまり、この方式では、事前共有秘密鍵と通信相手とを結びつけるための情報と
してIPアドレスが使用されます。このため、この方式では、リモートアクセスのようにIPアド
レスが変わるような環境では利用できないので注意が必要です（リモートアクセス環境で事前共
有秘密鍵を使用する場合には、メインモードではなくアグレッシブモードを使用します）。
デジタル署名認証方式を使用した場合のメインモード
図 9-27 に、デジタル署名認証方式を使用した場合のメインモードにおけるメッセージの流れ
と、使用される ISAKMP ペイロードを示します。
デジタル署名認証方式では、事前共有秘密鍵認証方式で交換されるハッシュペイロードの代わ
りに署名ペイロードが使用されます。この方式では、3つめと4つめのメッセージの鍵交換ペイ
9.6 IKE の動作 ● 183
始動者
応答者
SA パラメータの提案
ISAKMP ヘッダ
SA
②
ISAKMP ヘッダ
鍵交換
乱数（始動者）
SA パラメータの選択
始動者の鍵情報
④
⑥
ISAKMP ヘッダ
SA
③
ISAKMP ヘッダ
鍵交換
乱数（応答者）
応答者の鍵情報
始動者の ID
始動者の認証情報
ISAKMP ヘッダ
ID（始動者）
［証明書（始動者）
］
署名（始動者）
①
応答者の ID
応答者の認証情報
⑤
ISAKMP ヘッダ
ID（応答者）
［証明書（応答者）
］
署名（応答者）
［ ］で示したペイロードはオプション
図 9-27 デジタル署名認証方式を使用したメインモード（網掛部は暗号化）
xi
xr
ロードで交換される始動者および応答者の Diffie-Hellman 公開値（g および g ）、乱数ペイロー
ドで交換される始動者および応答者の乱数値（Ni_b および Nr_b）、始動者および応答者のクッ
キー（CKY-IおよびCKY-R）
から共有秘密鍵
（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計
算します。5つめと6つめのメッセージで交換される署名ペイロードには、事前共有秘密鍵認証
方式と同じようにして計算された始動者および応答者のハッシュ値に対して、折衝されたデジタ
ル署名方式
（RSA署名、DSS署名、ECDSA署名など）
によって署名した結果が入ります。つまり、
ハッシュアルゴリズムとしてMD5が折衝され、認証方式としてRSAによるデジタル署名認証方
式が折衝された場合には、最初に事前共有秘密鍵認証方式の場合と同様にHMAC-MD5によって
ハッシュ値を計算します。そして、そのハッシュを RSA によって私有秘密鍵を使用して暗号化
し、その結果を署名とします
（図9-28）
。ただし、DSS署名の場合は、署名用のハッシュアルゴリ
ズムとしてSHA-1を使用しなければならないため、ハッシュアルゴリズムとしてMD5が折衝さ
184 ● 9 章 SA 管理と鍵管理
私有秘密鍵
SKEYID
gxi
gxr
CKY-I
CKY-R
SAi_b
IDii_b
ハッシュ
（始動者）
HMAC-MD5
署名
（始動者）
RSA
図 9-28 MD5 を使用した RSA デジタル署名の生成
れたとしても、署名に使用されるハッシュ値は HMAC-SHA-1 を使用して計算します。
5 つめと 6 つめのメッセージでは、SKEYID_e によって ISAKMP ペイロード全体を暗号化し、
ISAKMP ヘッダのフラグフィールドの暗号化ビットを 1 とします。
また、署名を検証するために相手の公開鍵が必要となりますが、この方式では事前に公開鍵を
保持しておく必要はなく、証明書ペイロードによって公開鍵証明書を送信することが可能です。
互いの証明書をすでに持っている場合には、証明書の要求や証明書の送信は必要ありません。
この方式の利点は、あらかじめ特別な認証用の情報を保持しておかなくても、公開鍵証明書を
検証できる環境さえあれば認証が行える点にあります。ただし、デジタル署名を利用しているた
め、第三者に対してアクセスの否認を行うことはできません。
公開鍵暗号化認証方式を使用した場合のメインモード
図 9-29 に、公開鍵暗号化認証方式を使用した場合のメインモードにおけるメッセージの流れ
と、使用される ISAKMP ペイロードを示します。
事前共有秘密鍵認証方式の場合と異なるのは、ID ペイロードを 3 つめのメッセージと 4 つめ
のメッセージで交換し、IDペイロードと乱数ペイロードを相手の公開鍵で暗号化して送信する
点です。このため、この方式では、始動者および応答者の両者が相手の公開鍵を事前に入手して
おく必要があります。また、IDペイロードと乱数ペイロードをまとめて暗号化せず、ペイロー
ドごとに暗号化します。この時、実際に暗号化するのは各ペイロードのボディ部のみで、
ISAKMP共通ペイロードヘッダ部
（ISAKMPペイロードの最初の4バイト）
は暗号化しません。こ
の公開鍵による暗号化によって、ID を保護することが可能となります。
この方式では、3つめと4つめのメッセージの鍵交換ペイロードで交換される始動者および応
xi
xr
答者の Diffie-Hellman 公開値（g および g ）、乱数ペイロードで交換される始動者および応答者
の乱数値（Ni_bおよびNr_b）、始動者および応答者のクッキー（CKY-IおよびCKY-R）から共有秘
密鍵（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計算します。5 つめと6 つめのメッセー
9.6 IKE の動作 ● 185
始動者
応答者
SA パラメータの提案
ISAKMP ヘッダ
SA
②
ISAKMP ヘッダ
鍵交換
［ハッシュ（1）］
ID（始動者）
乱数（始動者）
SA パラメータの選択
始動者の鍵情報
始動者の ID
④
⑥
ISAKMP ヘッダ
SA
③
応答者の鍵情報
応答者の ID
始動者の認証情報
ISAKMP ヘッダ
ハッシュ（始動者）
①
ISAKMP ヘッダ
鍵交換
ID（応答者）
乱数（応答者）
⑤
応答者の認証情報
［ ］で示したペイロードはオプション
ISAKMP ヘッダ
ハッシュ（応答者）
＊ ID ペイロードおよび乱数ペイロードは
相手の公開鍵（ ）でペイロード
毎に暗号化
図 9-29 公開鍵暗号化認証方式を使用したメインモード（網掛部は暗号化）
ジで交換されるハッシュペイロード中のハッシュ値は、SKEYIDを鍵として生成します。また、
SKEYID_e によって、このハッシュペイロードを暗号化します。
3 つめのメッセージにおけるハッシュペイロード（ハッシュ（1））には、始動者が乱数ペイロー
ドとIDペイロードのボディ部を暗号化するために使用した公開鍵証明書のハッシュ値が入りま
す。このハッシュペイロードはオプションです。
この公開鍵暗号化認証方式では、誰でも入手可能な相手の公開鍵を使用するため、デジタル署
名認証方式と異なり、第三者に対してアクセスを否認することができるという特徴があります。
改良型公開鍵暗号化認証方式を使用した場合のメインモード
公開鍵暗号化認証方式では、公開鍵暗号による暗号化と復号化の処理を2回ずつ（IDペイロー
ドと乱数ペイロードの暗号化と復号化）行う必要があるため、処理に時間がかかります。このた
186 ● 9 章 SA 管理と鍵管理
め、公開鍵暗号による暗号化と復号化の処理を1回ずつで済ますように改良された改良型公開鍵
暗号化認証方式が提案されました。図 9-30 に、改良型公開鍵暗号化認証方式を使用した場合の
メインモードにおけるメッセージの流れと、使用される ISAKMP ペイロードを示します。
この方式では、3つめと4つめのメッセージの乱数ペイロードのみを公開鍵暗号によって暗号
化します。公開鍵暗号を使用するため、始動者はあらかじめ応答者の公開鍵を入手しておく必要
があります。しかし、公開鍵暗号化認証方式と異なり、この方式では始動者の公開鍵証明書を証
明書ペイロードによって応答者に送信することができるため、応答者はあらかじめ始動者の公開
鍵を入手していなくても処理を行うことが可能です。そして、鍵交換ペイロード、IDペイロー
ド、証明書ペイロードは、公開鍵暗号ではなく、共通鍵暗号によって暗号化します（この場合も
始動者
応答者
SA パラメータの提案
ISAKMP ヘッダ
SA
②
ISAKMP ヘッダ
［ハッシュ（1）
］
乱数（始動者）
鍵交換
ID（始動者）
［証明書
（始動者）
］
SA パラメータの選択
始動者の鍵情報
始動者の ID
④
⑥
ISAKMP ヘッダ
SA
③
応答者の鍵情報
応答者の ID
始動者の認証情報
ISAKMP ヘッダ
ハッシュ（始動者）
①
応答者の認証情報
ISAKMP ヘッダ
乱数（応答者）
鍵交換
ID（応答者）
⑤
ISAKMP ヘッダ
ハッシュ（応答者）
［ ］で示したペイロードはオプション
＊乱数ペイロードは相手の公開鍵（ ）でペイロード毎に暗号化
鍵交換ペイロード、ID ペイロード、証明書ペイロードは
共通鍵暗号（ ）によりペイロード毎に暗号化
図 9-30 改良型公開鍵暗号化認証方式を使用したメインモード（網掛部は暗号化）
9.6 IKE の動作 ● 187
暗号化するのは各ペイロードのボディ部のみで、最初の4バイトのISAKMP共通ペイロードヘッ
ダ部は暗号化しません）
。このペイロードごとの暗号化に使用する共通鍵暗号用の共有秘密鍵は、
始動者と応答者のそれぞれが生成した乱数とクッキーから次のように計算します。
Ne_i = prf (Ni_b, CKY-I)
Ne_r = prf (Nr_b, CKY-R)
ここで、Ne_iおよびNe_rは、それぞれ始動者または応答者が送信するメッセージを暗号化す
るための共有秘密鍵を示します。生成された鍵の長さが短い場合には、新しい共有秘密鍵Kを次
のように計算します（応答者が送信するメッセージを暗号化するための共有秘密鍵を生成する場
合は、Ne_i を Ne_r に置き換えて計算します）。
K = K1 | K2 | K3
K1 = prf (Ne_i, 0)
K2 = prf (Ne_i, K1)
K3 = prf (Ne_i, K2)
ここで、3つめと4つめのメッセージにおける処理の流れを追ってみます。最初に、始動者は
乱数（Ni_b）を生成し、その乱数と始動者クッキー（CKY-I）から共有秘密鍵（Ne_i）を生成します。
乱数ペイロードのボディ部はあらかじめ入手しておいた応答者の公開鍵を使用して公開鍵暗号に
より暗号化し、鍵交換ペイロード、IDペイロード、証明書ペイロードのボディ部は生成した共
有秘密鍵
（Ne_i）
を使用して共通鍵暗号により暗号化します。応答者は、受信した乱数ペイロード
を自身の私有秘密鍵により復号化し、得られた乱数
（Ni_b）から共有秘密鍵
（Ne_i）
を生成します。
そして、その共有秘密鍵（Ne_i）を使用して、共通鍵暗号により鍵交換ペイロード、IDペイロー
ド、証明書ペイロードのボディ部を復号化します。応答者は、受信した証明書ペイロードから公
開鍵証明書を取り出し、その正当性を検証します。そして、乱数（Nr_b）を生成し、その乱数と
応答者クッキー
（CKY-R）
から共有秘密鍵
（Ne_r）
を生成します。乱数ペイロードのボディ部はあら
かじめ入手しておいた応答者の公開鍵か、始動者から証明書ペイロードにより入手した公開鍵を
使用して公開鍵暗号により暗号化し、鍵交換ペイロード、IDペイロード、証明書ペイロードの
ボディ部は生成した共有秘密鍵（Ne_r）を使用して共通鍵暗号により暗号化します。
この方式では、3つめと4つめのメッセージの鍵交換ペイロードで交換される始動者および応
答者の Diffie-Hellman 公開値（gxi および gxr）、乱数ペイロードで交換される始動者および応答者
の乱数値（Ni_bおよびNr_b）、始動者および応答者のクッキー（CKY-IおよびCKY-R）から共有秘
密鍵（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計算します。5 つめと6 つめのメッセー
ジで交換されるハッシュペイロード中のハッシュ値は、SKEYIDを鍵として生成します。また、
188 ● 9 章 SA 管理と鍵管理
SKEYID_e によって、このハッシュペイロードを暗号化します。
3 つめのメッセージのハッシュペイロード（ハッシュ（1））には、始動者が乱数ペイロードのボ
ディ部を暗号化するために使用した公開鍵証明書のハッシュ値が入ります。このハッシュペイ
ロードはオプションです。
この改良型公開鍵暗号化認証方式では、公開鍵暗号化認証方式と同様に誰でも入手可能な相手
の公開鍵を使用するため、第三者に対してアクセスを否認することができるという特徴がありま
す。また、他の方式と異なり、鍵交換ペイロードが暗号化されるため、より安全に鍵交換を行う
ことが可能となります。
アグレッシブモード
メインモードでは、6つのメッセージを使用する必要がありますが、アグレッシブモードでは、
3つのメッセージでフェーズ1を完了することが可能です。このアグレッシブモードでは、SAペ
イロード、鍵交換ペイロード、IDペイロードなどを最初のメッセージでまとめて送信します。こ
のため、折衝できるDiffie-Hellman鍵共有アルゴリズムのパラメータが制限されるという問題や、
事前共有秘密鍵認証方式またはデジタル署名認証方式を使用した場合にはID情報が保護されな
いなどの欠点があります。
アグレッシブモードの間は、ISAKMPヘッダの交換タイプフィールドに、アグレッシブモード
であることを示す 4 が入ります。
事前共有秘密鍵認証方式を使用した場合のアグレッシブモード
図 9-31 に、事前共有秘密鍵認証方式を使用した場合のアグレッシブモードにおけるメッセー
ジの流れと、使用される ISAKMP ペイロードを示します。
xr
最初のメッセージを受信した応答者は、Diffie-Hellman公開値
（g ）
と応答者クッキー
（CKY-R）
、
乱数（Nr_b）を生成し、あらかじめ入手済みの事前共有秘密鍵に加えて、始動者および応答者の
xi
xr
Diffie-Hellman公開値（g およびg ）、始動者および応答者の乱数値（Ni_bおよびNr_b）、始動者
および応答者のクッキー（CKY-I および CKY-R ）から共有秘密鍵（SKEYID、SKEYID_d、
SKEYID_a、SKEYID_e）
を計算します。そして、このSKEYIDを使用してハッシュを計算し、生
xr
成したDiffie-Hellman公開値（g ）
や乱数
（Nr_b）
とともに、始動者に送信します
（2つめのメッセー
ジ）。これを受信した始動者は、応答者と同じように共有秘密鍵（S K E Y I D 、S K E Y I D _ d 、
SKEYID_a、SKEYID_e）を計算します。そして、SKEYIDを使用してハッシュを計算し、応答者
に送信します（3 つめのメッセージ）。
メインモードの場合は、IPアドレスを基に事前共有秘密鍵を検索していましたが、アグレッシ
ブモードでは、最初のメッセージでIDを送信するため、このIDを基に事前共有秘密鍵を検索す
9.6 IKE の動作 ● 189
始動者
応答者
SA パラメータの提案
始動者の鍵情報
始動者の ID
ISAKMP ヘッダ
SA
鍵交換
乱数（始動者）
ID（始動者）
②
ISAKMP ヘッダ
ハッシュ（始動者）
①
SA パラメータの選択
応答者の鍵情報
応答者の ID
応答者の認証情報
始動者の認証情報
ISAKMP ヘッダ
SA
鍵交換
乱数（応答者）
ID（応答者）
ハッシュ（応答者）
③
図 9-31 事前共有秘密鍵認証方式を使用したアグレッシブモード（網掛部は暗号化）
ることが可能です。つまり、IPアドレス以外のユーザFQDN（メールアドレス）などのユーザID
を利用することが可能であるため、リモートアクセスのような IP アドレスが変わるような環境
でも、事前共有秘密鍵を利用することが可能となります。
また、最後のメッセージ（3つめのメッセージ）では、SKEYID_eによりハッシュペイロードを
暗号化します。このメッセージでは、ISAKMPヘッダの暗号化ビットが1となり、ISAKMPペイ
ロード部が暗号化されていることを示します。
この方式では、事前共有秘密鍵認証方式を使用したメインモードと比較して、3メッセージで
折衝を完了することができるという利点がありますが、Oakley グループを折衝することができ
ないという欠点や、ID が暗号化されないという欠点があります。
デジタル署名認証方式を使用した場合のアグレッシブモード
図 9-32 に、デジタル署名認証方式を使用した場合のアグレッシブモードにおけるメッセージ
の流れと、使用される ISAKMP ペイロードを示します。
デジタル署名認証方式では、事前共有秘密鍵認証方式で交換されるハッシュペイロードの代わ
りに署名ペイロードが使用されます。この方式では、1つめと2つめのメッセージの鍵交換ペイ
ロードで交換される始動者および応答者の Diffie-Hellman 公開値（gxi および gxr）、乱数ペイロー
ドで交換される始動者および応答者の乱数値（Ni_b および Nr_b）、始動者および応答者のクッ
キー（CKY-IおよびCKY-R）
から共有秘密鍵
（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計
190 ● 9 章 SA 管理と鍵管理
始動者
応答者
SA パラメータの提案
始動者の鍵情報
始動者の ID
ISAKMP ヘッダ
SA
鍵交換
乱数（始動者）
ID（始動者）
②
ISAKMP ヘッダ
［証明書（始動者）］
署名（始動者）
①
SA パラメータの選択
応答者の鍵情報
応答者の ID
応答者の認証情報
始動者の認証情報
ISAKMP ヘッダ
SA
鍵交換
乱数（応答者）
ID（応答者）
［証明書（応答者）］
署名（応答者）
③
［ ］で示したペイロードはオプション
図 9-32 デジタル署名認証方式を使用したアグレッシブモード
算します。2つめと3つめのメッセージで交換される署名ペイロードには、事前共有秘密鍵認証
方式と同じように計算された始動者および応答者のハッシュ値に対して、折衝されたデジタル署
名方式（RSA 署名、DSS 署名、ECDSA 署名など）によって署名した結果が入ります。
また、署名を検証するために相手の公開鍵が必要となりますが、この方式では、事前に公開鍵
を保持しておく必要はなく、証明書ペイロードを使用して公開鍵証明書を入手することが可能で
す。互いの証明書をすでに持っている場合には、証明書の要求や証明書の送信は必要ありません。
この方式では、デジタル署名認証方式を使用したメインモードと比較して、3メッセージで折
衝を完了することができるという利点がありますが、Oakley グループを折衝することができな
いという欠点や、ID が暗号化されないという欠点があります。
公開鍵暗号化認証方式を使用した場合のアグレッシブモード
図 9-33 に、公開鍵暗号化認証方式を使用した場合のアグレッシブモードにおけるメッセージ
の流れと使用される ISAKMP ペイロードを示します。
公開鍵暗号化認証方式が事前共有秘密鍵認証方式やデジタル署名認証方式と決定的に異なるの
は、IDを暗号化することができるという点にあります。この方式では、最初のメッセージと2つ
9.6 IKE の動作 ● 191
始動者
応答者
ISAKMP ヘッダ
SA
［ハッシュ（1）］
鍵交換
ID（始動者）
乱数（始動者）
SA パラメータの提案
始動者の鍵情報
始動者の ID
②
SA パラメータの選択
応答者の鍵情報
応答者の ID
応答者の認証情報
始動者の認証情報
ISAKMP ヘッダ
ハッシュ（始動者）
①
［ ］で示したペイロードはオプション
ISAKMP ヘッダ
SA
鍵交換
ID（応答者）
乱数（応答者）
ハッシュ（応答者）
③
＊ ID ペイロードおよび乱数ペイロードは
相手の公開鍵（ ）でペイロード
毎に暗号化
図 9-33 公開鍵暗号化認証方式を使用したアグレッシブモード（網掛部は暗号化）
めのメッセージで交換されるIDペイロードと乱数ペイロードを相手の公開鍵を使用して公開鍵
暗号により暗号化して送信します。このため、この方式では、あらかじめ相手の公開鍵を入手し
ておく必要があります。また、IDペイロードと乱数ペイロードをまとめて暗号化せず、ペイロー
ドごとに暗号化します（実際に暗号化するのは各ペイロードのボディ部のみで、ISAKMP共通ペ
イロードヘッダ部は暗号化しません）。
この方式では、1つめと2つめのメッセージの鍵交換ペイロードで交換される始動者および応
xi
xr
答者の Diffie-Hellman 公開値（g および g ）、乱数ペイロードで交換される始動者および応答者
の乱数値（Ni_bおよびNr_b）、始動者および応答者のクッキー（CKY-IおよびCKY-R）から共有秘
密鍵（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計算します。2 つめのメッセージと3つ
めのメッセージで交換されるハッシュペイロード中のハッシュ値は、SKEYIDを鍵として生成し
ます。
最初のメッセージのハッシュペイロード
（ハッシュ（1）
）
には、始動者がIDペイロードと乱数ペ
イロードのボディ部を暗号化するために使用した公開鍵証明書のハッシュ値が入ります。この
ハッシュペイロードはオプションです。
192 ● 9 章 SA 管理と鍵管理
改良型公開鍵暗号化認証方式を使用した場合のアグレッシブモード
メインモードの場合と同様に、アグレッシブモードの場合でも公開鍵暗号化認証方式では、公
開鍵暗号による暗号化と復号化の処理を2回ずつ行う必要があります。改良型公開鍵暗号化認証
方式では、この公開鍵暗号による暗号化と復号化の処理を1回ずつで済ますように改良されてい
ます。図 9-34 に、改良型公開鍵暗号化認証方式を使用した場合のアグレッシブモードにおける
メッセージの流れと、使用される ISAKMP ペイロードを示します。
この方式では、1つめと2つめのメッセージの乱数ペイロードのみを公開鍵によって公開鍵暗
号により暗号化します。公開鍵暗号を使用するため、始動者はあらかじめ応答者の公開鍵を入手
しておく必要があります。しかし、この方式では、自身の公開鍵証明書を証明書ペイロードに
よって応答者に送信することができるため、応答者はあらかじめ始動者の公開鍵を入手していな
くても処理を行うことが可能です。また、鍵交換ペイロード、IDペイロード、証明書ペイロー
ドは、公開鍵暗号ではなく、共通鍵暗号によって暗号化します（この場合も暗号化するのは各ペ
イロードのボディ部のみで、最初の 4 バイトの ISAKMP 共通ペイロードヘッダ部は暗号化しま
始動者
応答者
ISAKMP ヘッダ
SA
［ハッシュ（1）］
乱数（始動者）
鍵交換
ID（始動者）
［証明書（始動者）］
SA パラメータの提案
始動者の鍵情報
始動者の ID
②
ISAKMP ヘッダ
ハッシュ（始動者）
①
SA パラメータの選択
応答者の鍵情報
応答者の ID
応答者の認証情報
始動者の認証情報
ISAKMP ヘッダ
SA
乱数（応答者）
鍵交換
ID（応答者）
ハッシュ（応答者）
③
［ ］で示したペイロードはオプション
＊乱数ペイロードは相手の公開鍵（ ）でペイロード毎に暗号化
鍵交換ペイロード、ID ペイロード、証明書ペイロードは
共通鍵暗号（ ）によりペイロード毎に暗号化
図 9-34 改良型公開鍵暗号化認証方式を使用したアグレッシブモード
（網掛部は暗号化）
9.6 IKE の動作 ● 193
せん）
。このペイロードごとの暗号化に使用する共通鍵暗号用の共有秘密鍵は、メインモードの
場合と同様に計算します。
この方式では、1つめと2つめのメッセージの鍵交換ペイロードで交換される始動者および応
xi
xr
答者の Diffie-Hellman 公開値（g および g ）、乱数ペイロードで交換される始動者および応答者
の乱数値（Ni_bおよびNr_b）、始動者および応答者のクッキー（CKY-IおよびCKY-R）から共有秘
密鍵（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計算します。2 つめと3 つめのメッセー
ジで交換されるハッシュペイロード中のハッシュ値は、SKEYID を鍵として生成します。
最初のメッセージのハッシュペイロード
（ハッシュ
（1）
）
には、始動者が乱数ペイロードのボディ
部を暗号化するために使用した公開鍵証明書のハッシュ値が入ります。このハッシュペイロード
はオプションです。
9.6.2 セキュリティプロトコルの SA の確立（フェーズ 2 ）
フェーズ 2 では、フェーズ 1 で確立された ISAKMP SA を使用して、IPsec の AH や ESP など
のセキュリティプロトコルの SA を確立します。フェーズ 2 で行うことは次のとおりです。
1.
セキュリティプロトコルの SA の折衝
2.
セキュリティプロトコルの SA で使用される共有秘密鍵の生成
クイックモード
IKEのフェーズ2では、クイックモードと呼ばれるモードでAH、ESP、IPCompなどのセキュ
リティプロトコルのSAパラメータが折衝されます。IPsec SAは単方向ですが、クイックモード
ではセキュリティプロトコルやアルゴリズム、SAの有効期間、カプセル化モードなどについて
合意すると、これらの SA パラメータを使用して両方向（つまり 2 本）の SA を生成します（SPI 値
は、SA の受信者がそれぞれ決定します）。フェーズ 2 の交換情報は、フェーズ 1 で確立された
ISAKMP SAによってメッセージが保護されます。クイックモードの間は、ISAKMPヘッダの交
換タイプフィールドにクイックモードであることを示す 32 が入ります。
図 9-35 に、クイックモードにおけるメッセージの流れと使用される ISAKMP ペイロードを示
します。クイックモードでは、フェーズ1で折衝された暗号化アルゴリズムとフェーズ1で生成
された SKEYID_e を使用して、ISAKMP ペイロード全体を暗号化します。
PFS
（Perfect Forward Secrecy）が無効の場合は、鍵交換ペイロードは使用されません。この場
合は、IPsec SA で使用する鍵（KEYMAT）を次のように計算します。
KEYMAT = prf (SKEYID_d, protocol | SPI | Ni_b | Nr_b)
194 ● 9 章 SA 管理と鍵管理
始動者
応答者
SA パラメータの提案
（始動者の鍵情報）
（始動側クライアント ID）
（応答側クライアント ID）
ISAKMP ヘッダ
ハッシュ（1）
SA
乱数（始動者）
［鍵交換］
［ID（始動側クライアント）］
［ID（応答側クライアント）］
②
①
SA パラメータの選択
（応答者の鍵情報）
（始動側クライアント ID）
（応答側クライアント ID）
ISAKMP ヘッダ
ハッシュ（2）
SA
乱数（応答者）
［鍵交換］
［ID（始動側クライアント）］
［ID（応答側クライアント）］
③
ISAKMP ヘッダ
ハッシュ（3）
［ ］で示したペイロードはオプション
図 9-35 クイックモード（網掛部は暗号化）
また、PFSを有効にしている場合には、鍵交換ペイロードが使用されます。この場合は、IPsec
で使用する鍵（KEYMAT）を次のように計算します。
xy
KEYMAT = prf (SKEYID_d, g(qm) | protocol | SPI | Ni_b | Nr_b)
xy
ここで、SKEYID_d は、IKE のフェーズ 1 で生成された鍵素材であり、g(qm) は、フェーズ
2 のクイックモードの鍵交換で生成された Diffie-Hellman 共有値を示します。また、protocol と
SPI は、プロポーザルペイロードヘッダのプロトコル IDフィールド（1 バイト）とSPIフィールド
（4 バイト）を示します。Ni_b およびNr_bは、それぞれ始動者または応答者の乱数ペイロードの
ISAKMP共通ペイロードヘッダ部
（最初の4バイト）を除いた部分を示します。生成された鍵が短
い場合には、次のように連結して長い鍵を生成します。
KEYMAT = K1 | K2 | K3 | ...
K1 = prf (SKEYID_d, [ g(qm)xy | ] protocol | SPI | Ni_b | Nr_b)
K2 = prf (SKEYID_d, K1 | [ g(qm)xy | ] protocol | SPI | Ni_b | Nr_b)
K3 = prf (SKEYID_d, K2 | [ g(qm)xy | ] protocol | SPI | Ni_b | Nr_b)
9.6 IKE の動作 ● 195
ハッシュペイロードで運ばれるハッシュ値は、フェーズ1で生成されたSKEYID_aを認証鍵と
して次の式により計算します。このハッシュペイロードによって、メッセージの完全性の確保と
リプレイ攻撃からの防御を実現します。
ハッシュ（1）= prf (SKEYID_a, メッセージ ID | ハッシュ以外のペイロード)
ハッシュ（2）= prf (SKEYID_a, メッセージ ID | Ni_b | ハッシュ以外のペイロード)
ハッシュ（3）= prf (SKEYID_a, 0 | メッセージ ID | Ni_b | Nr_b)
また、ID ペイロードは、フェーズ 2 で折衝された SA を使用するホスト（クライアント）の ID
を示すために使用します。例えば、ISAKMPの始動者または応答者がセキュリティゲートウェイ
であり、トンネルモードが使用される場合には、セキュリティゲートウェイの背後のネットワー
クアドレスをIDとして使用します。この場合は、IDとして示したネットワークに所属するすべ
てのホストが SA を利用することが可能となります。セキュリティゲートウェイの背後にある 1
台のホストのみが SA を利用する場合には、そのホストの IP アドレスを ID として使用すること
も可能です。この場合は、IDで示したアドレスを持つホストのみがSAを利用することが可能と
なります。IDペイロードを使用しない場合には、始動側クライアントIDおよび応答側クライア
ント ID は、それぞれ ISAKMP の始動者または応答者の IP アドレスとなります（利用するプロト
コルやポートの制限はありません）
。交換されたIDがローカルのセキュリティポリシーと合致し
ない場合には、通知ペイロードのINVALID-ID-INFORMATIONメッセージ（メッセージ番号18）
を使用して、ID が不正であることを相手側に通知します。
次に、IKE フェーズ 1 の折衝（事前共有秘密鍵認証方式によるメインモード）から、フェーズ 2
の折衝（クイックモード）、そして IPsec による通信と続くパケットの流れを TCPDUMP の出力
形式で示します。この例では、192.168.1.20 が始動者、192.168.1.30 が応答者となっています
（TCPDUMP の出力の見方については付録 A「IPsec プロトコルの解析」を参照してください）。
[IKE フェーズ 1 メインモード]
20:06:10.355324 192.168.1.20.isakmp > 192.168.1.30.isakmp: isakmp: phase 1 I ident:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=2
(t: #1 id=ike (type=enc value=3des)
(type=hash value=sha1)
(type=groupdesc value=modp1024)
(type=auth value=preshared)
(type=lifetype value=sec)
(type=lifeduration len=4 value=00007080))
(t: #2 id=ike (type=enc value=3des)
(type=hash value=md5)
196 ● 9 章 SA 管理と鍵管理
(type=groupdesc value=modp1024)
(type=auth value=preshared)
(type=lifetype value=sec)
(type=lifeduration len=4 value=00007080))
20:06:10.489414 192.168.1.30.isakmp > 192.168.1.20.isakmp: isakmp: phase 1 R ident:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=1
(t: #1 id=ike (type=enc value=3des)
(type=hash value=sha1)
(type=groupdesc value=modp1024)
(type=auth value=preshared)
(type=lifetype value=sec)
(type=lifeduration len=4 value=00007080))))
20:06:10.646390 192.168.1.20.isakmp > 192.168.1.30.isakmp: isakmp: phase 1 I ident:
(ke: key len=128)
(nonce: n len=20)
20:06:10.691015 192.168.1.30.isakmp > 192.168.1.20.isakmp: isakmp: phase 1 R ident:
(ke: key len=128)
(nonce: n len=20)
20:06:10.735744 192.168.1.20.isakmp > 192.168.1.30.isakmp: isakmp: phase 1 I ident[E]:
[|id]
20:06:10.737336 192.168.1.30.isakmp > 192.168.1.20.isakmp: isakmp: phase 1 R ident[E]:
[|id]
[IKE フェーズ 2 クイックモード]
20:06:10.739370 192.168.1.20.isakmp > 192.168.1.30.isakmp: isakmp: phase 2/others I oakleyquick[E]: [|hash]
20:06:10.741183 192.168.1.30.isakmp > 192.168.1.20.isakmp: isakmp: phase 2/others R oakleyquick[E]: [|hash]
20:06:10.742020 192.168.1.20.isakmp > 192.168.1.30.isakmp: isakmp: phase 2/others I oakleyquick[E]: [|hash]
[IPsec ESP による通信]
20:06:10.744992
20:06:10.745240
20:06:15.356927
20:06:15.357404
192.168.1.20
192.168.1.30
192.168.1.20
192.168.1.30
>
>
>
>
192.168.1.30:
192.168.1.20:
192.168.1.30:
192.168.1.20:
ESP(spi=1523517648,seq=0x1)
ESP(spi=4193667392,seq=0x1)
ESP(spi=1523517648,seq=0x2)
ESP(spi=4193667392,seq=0x2)
9.6.3 その他のメッセージ交換
IKEでは、フェーズ1のメインモード、アグレッシブモード、およびフェーズ2のクイックモー
ドの他に、新たなOakleyグループの折衝を行う新グループモードやISAKMP情報提供交換があ
ります。
9.6 IKE の動作 ● 197
新グループモード
新グループモードは、Diffie-Hellman鍵共有アルゴリズムで使用するOakleyグループを新たに
作成し、合意するためのモードです。新たに合意されたOakleyグループには、プライベートグ
ループIDが付与されます。新グループモードは、必ずフェーズ1の後で行われ、ISAKMP SAに
よってセキュリティが確保されます。新グループモードの間は、ISAKMP ヘッダの交換タイプ
フィールドに、新グループモードであることを示す 33 が入ります。
すでに定義されている Oakley グループ（Diffie-Hellman グループ）では、RFC によって素数
（prime）や原始元
（generator）
などのパラメータの値が決められているため、これらの値について
折衝する必要はありません。しかし、新たにOakleyグループを作成する場合には、これらのパ
ラメータの値についても折衝する必要があります。新グループモードでは、Oakley グループ
（Group Description）、グループタイプ（MODP、ECP、EC2N など）、グループ素数 / 既約多項
式（Group Prime/Irreducible Polynomial）、グループ原始元 1（Group Generator1）、グループ原
始元 2（Group Generator2）、グループカーブ A、グループカーブ B、有限体サイズ（Field Size）、
グループオーダーなどの ISAKMP SA 属性を使用して新たな Oakley グループを折衝します。
図 9-36 に、新グループモードにおけるメッセージの流れと、使用される ISAKMP ペイロード
を示します。ハッシュペイロード中のハッシュ値は次のように計算します。
ハッシュ = prf (SKEYID_a, メッセージ ID | SA ペイロード)
始動者
ISAKMP ヘッダ
ハッシュ
SA
応答者
新グループの提案
新グループの選択
ISAKMP ヘッダ
ハッシュ
SA
図 9-36 新グループモード（網掛部は暗号化）
ISAKMP 情報提供交換
ISAKMP情報提供交換を使用して、ISAKMP SAの状態やエラーに関する情報を相手に通知し
ます。ISAKMP情報提供交換の間は、ISAKMPヘッダの交換タイプフィールドに、ISAKMP情報
提供交換であることを示す 5 が入ります。
ISAKMP 情報提供交換では、ISAKMP 通知ペイロードまたは ISAKMP 削除ペイロードを使用
198 ● 9 章 SA 管理と鍵管理
します（図9-37）。ISAKMP情報提供交換がISAKMP SAによって保護されている場合はハッシュ
ペイロードが存在し、次のようにハッシュ値を計算します。
ハッシュ = prf (SKEYID_a, メッセージ ID | 通知または削除ペイロード)
始動者
応答者
ISAKMP ヘッダ
ハッシュ
通知／削除
エラーやステータスの通知
または SA の削除
図 9-37 ISAKMP 情報提供交換（網掛部は暗号化）
図 9-38 に、フェーズ 1 において SA の折衝に失敗した場合に使用される ISAKMP 情報提供交換
の例を示します。フェーズ1の折衝に失敗した場合には、ISAKMP SAは確立されていないため、
ISAKMP 情報提供交換で使用される通知ペイロードは暗号化されません。
始動者
ISAKMP ヘッダ
SA
SA パラメータの提案
（フェーズ 1 メインモード）
SA 選択不可
（ISAKMP 情報提供交換）
応答者
ISAKMP ヘッダ
通知ペイロード
NO-PROPOSAL-CHOSEN
図 9-38 フェーズ 1 の折衝失敗の通知
この場合の TCPDUMP の出力は次のようになります（始動者は 192.168.1.50、応答者は
192.168.1.30）。
19:02:50.673825 192.168.1.50.isakmp > 192.168.1.30.isakmp: isakmp: phase 1 I ident:
(sa: doi=ipsec situation=identity
(p: #0 protoid=isakmp transform=2
(t: #0 id=ike (type=lifetype value=sec)
(type=lifeduration value=0e10)
(type=enc value=3des)
(type=hash value=sha1)
(type=auth value=preshared)
(type=group desc value=modp1024))
(t: #1 id=ike (type=lifetype value=sec)
9.6 IKE の動作 ● 199
(type=lifeduration value=0e10)
(type=enc value=3des)
(type=hash value=md5)
(type=auth value=preshared)
(type=group desc value=modp1024)))) (DF)
19:02:50.678040 192.168.1.30.isakmp > 192.168.1.50.isakmp: isakmp: phase 2/others R inf:
(n: doi=ipsec proto=isakmp type=NO-PROPOSAL-CHOSEN
spi=689a8ed6a8206e6e3695bd8e693d902b orig=( [|sa]))
フェーズ 2（クイックモード）での折衝に失敗した場合の ISAKMP 情報提供交換は図 9-39 のよ
うになります。この場合は、ISAKMP SAはすでに確立されているため、ISAKMP情報提供交換
で使用されるペイロードは暗号化されます。
始動者
応答者
ISAKMP ヘッダ
ハッシュ（1）
SA
乱数（始動者）
SA パラメータの提案
（フェーズ 2 クイックモード）
SA 選択不可
（ISAKMP 情報提供交換）
ISAKMP ヘッダ
ハッシュ
通知ペイロード
NO-PROPOSAL-CHOSEN
図 9-39 フェーズ 2 の折衝失敗の通知（網掛部は暗号化）
この場合の TCPDUMP の出力は次のようになります（始動者は 192.168.1.50、応答者は
192.168.1.30）
。ペイロード部が暗号化され、ISAKMPヘッダの後にハッシュペイロードが含まれ
ていることがわかります。
18:57:41.248769 192.168.1.50.isakmp > 192.168.1.30.isakmp: isakmp: phase
2/others I
oakley-quick[E]: [|hash] (DF)
18:57:41.251233 192.168.1.30.isakmp > 192.168.1.50.isakmp: isakmp: phase
2/others R
inf[E]: [|hash]
200 ● 9 章 SA 管理と鍵管理
9.7 IKE による折衝パラメータ
ここでは、IKEのフェーズ1およびフェーズ2で折衝されるSAパラメータについて説明します。
9.7.1 ISAKMP SA パラメータ
ここでは IKE のフェーズ 1 で折衝される ISAKMP SA に関するパラメータについて説明しま
す。それぞれのパラメータで使用される値は、IANA（Internet Assigned Numbers Authority）
によって割り当てられています。最新の情報については、IANAの割り当て状況 [8] を確認し
てください。
セキュリティプロトコル ID
フェーズ 1 の ISAKMP SA の折衝ではプロトコル ID に PROTO_ISAKMP（1）を指定します。
ISAKMP トランスフォーム ID
鍵管理プロトコルとして IKE を使用するため、ISAKMPトランスフォーム ID に KEY_IKE（1）
を指定します。
暗号化アルゴリズム
ISAKMP SAの暗号化アルゴリズム属性（Encryption Algorithm）において、ISAKMP SAで使用
する暗号化アルゴリズムを指定します。表9-15に、本書執筆時点で定義されているISAKMP SA
暗号化アルゴリズム属性の属性値を示します。
表 9-15 ISAKMP SA 暗号化アルゴリズム属性値
属性値
暗号化アルゴリズム
0
予約
1
DES-CBC（実装必須）
2
IDEA-CBC
3
Blowfish-CBC
4
RC5-R16-B64-CBC
5
3DES-CBC
6
CAST-CBC
7
AES-CBC
9.7 IKE による折衝パラメータ ● 201
表 9-15 ISAKMP SA 暗号化アルゴリズム属性値（つづき）
属性値
暗号化アルゴリズム
8 ∼ 65,000
予約（未割り当て）
65,001 ∼ 65,535
プライベート用
ハッシュアルゴリズム
ISAKMP SA のハッシュアルゴリズム属性（Hash Algorithm）において、ISAKMP SA で使用す
るハッシュアルゴリズムを指定します。表9-16に、本書執筆時点で定義されているISAKMP SA
ハッシュアルゴリズム属性の属性値を示します。
表 9-16 ISAKMP SA ハッシュアルゴリズム属性値
属性値
ハッシュアルゴリズム
0
予約
1
MD5（実装必須）
2
SHA（実装必須）
3
Tiger
4
SHA2-256
5
SHA2-384
6
SHA2-512
7 ∼ 65,000
予約（未割り当て）
65,001 ∼ 65,535
プライベート用
相手認証方式
IKE では、フェーズ 1 で相手の認証を行います。このため、ISAKMP SA の相手認証方式属性
（Authentication Method）において相手認証方式を指定します。相手認証方式には、事前共有秘
密鍵による方法と、X.509公開鍵証明書を使用した署名による方法と、公開鍵暗号による暗号化、
公開鍵暗号による暗号化の改良型の4種類があります。表9-17に、本書執筆時点で定義されてい
る ISAKMP SA 相手認証方式属性の属性値を示します。
202 ● 9 章 SA 管理と鍵管理
表 9-17 ISAKMP SA 相手認証方式属性値
属性値
相手認証方式（Authentication Method）
0
予約
1
事前共有秘密鍵（実装必須）
2
DSS 署名
3
RSA 署名
4
RSA 暗号化
5
改良型 RSA 暗号化
6
ElGamal 暗号化
7
改良型 ElGamal 暗号化
8
ECDSA 署名
9 ∼ 65,000
予約（未割り当て）
65,001 ∼ 65,535
プライベート用
Oakley グループ
ISAKMP SA で使用する共有秘密鍵を確立するために、Diffie-Hellman 鍵共有アルゴリズムを
使用します。Diffie-Hellman 鍵共有アルゴリズムで使用される Oakley グループには、MODP グ
ループ（Modular Exponentiation Group）とEC2Nグループ（Elliptic Curve Group over Galois Field
N
GF[2 ]）
があります。IKEでは、これらのどちらのグループを使用するのか、また、MODPグルー
プの場合は素数（prime）の長さをどうするのか、EC2Nグループの場合はフィールドの大きさを
どうするのかということを ISAKMP SA の Oakley グループ属性（Group Description）を使用して
折衝します。Oakley 鍵交換プロトコルでは、これらの組み合わせや公開するパラメータ（素数、
原始元など）の値をあらかじめOakleyグループとして定義しており、IKEでもこの機能を引き継
いでいます。本書執筆時点では、Oakley グループは表 9-18 のように定義されています。また、
Diffie-Hellman鍵共有アルゴリズムの計算に必要な公開パラメータ値はグループごとにRFCなど
で決められています [1, 9, 10]。
表 9-18 ISAKMP SA Oakley グループ属性値
属性値（グループ番号）
Oakley グループの種類（Group Description）
0
予約
1
768 ビット MODP グループ（実装必須）
9.7 IKE による折衝パラメータ ● 203
表 9-18 ISAKMP SA Oakley グループ属性値
（つづき）
属性値（グループ番号）
Oakley グループの種類（Group Description）
2
1,024 ビット MODP グループ
3
155 ビット EC2N グループ
4
185 ビット EC2N グループ
5
1,536 ビット MODP グループ
6
163 ビット EC2N グループ（ランダムシード）
7
163 ビット EC2N グループ（Koblitz 曲線）
8
283 ビット EC2N グループ（ランダムシード）
9
283 ビット EC2N グループ（Koblitz 曲線）
10
409 ビット EC2N グループ（ランダムシード）
11
409 ビット EC2N グループ（Koblitz 曲線）
12
571 ビット EC2N グループ（ランダムシード）
13
571 ビット EC2N グループ（Koblitz 曲線）
14 ∼ 32,767
予約（未割り当て）
32,768 ∼ 65,535
プライベート用
ISAKMP SA の有効期間
ISAKMP SAの有効期間の単位をISAKMP SAの有効期間タイプ属性（Life Type）で指定します。
表9-19に、本書執筆時点で定義されているISAKMP SA有効期間タイプ属性の属性値を示します。
有効期間は、「時間（秒）」または「転送量（キロバイト）」で指定することができます。これらを
同時に指定した場合には、どちらかの一方の有効期間が過ぎた場合に SA が無効となります。
また、実際の有効期間の値は、ISAKMP SA の有効期間属性（Life Duration）によって指定し
ます。
表 9-19 ISAKMP SA 有効期間タイプ属性値
属性値
有効期間タイプ（Life Type）
0
予約
1
秒
2
キロバイト
204 ● 9 章 SA 管理と鍵管理
表 9-19 ISAKMP SA 有効期間タイプ属性値（つづき）
属性値
有効期間タイプ（Life Type）
3 ∼ 65,000
予約（未割り当て）
65,001 ∼ 65,535
プライベート用
9.7.2 IPsec SA パラメータ
ここではIKEのフェーズ2で折衝されるIPsec SA（AHおよびESPのSA）およびIPCompのIPCA
に関するパラメータについて説明します。それぞれのパラメータで使用される値は、IANA に
よって割り当てられています。最新の情報については、IANA の割り当て状況 [11] を確認して
ください。
セキュリティプロトコル ID
セキュリティプロトコル ID は、本書執筆時点では、表 9-20 のように割り当てられています。
フェーズ 2 で A H の S A パラメータを折衝する場合は、セキュリティプロトコル I D として
PROTO_IPSEC_AHを指定します。ESPのSAパラメータを折衝する場合は、PROTO_IPSEC_ESP
を指定します。また、IPComp の IPCA パラメータを折衝する場合は、PROTO_IPCOMP を指定
します。
表 9-20 セキュリティプロトコル ID
ID 番号
セキュリティプロトコル ID
0
予約
1
PROTO_ISAKMP
2
PROTO_IPSEC_AH
3
PROTO_IPSEC_ESP
4
PROTO_IPCOMP
5 ∼ 248
予約（未割り当て）
249 ∼ 255
プライベート用
AH トランスフォーム ID
表 9-21 に、本書執筆時点で定義されている AH トランスフォーム ID を示します。AH トラン
スフォーム ID は、AH で使用する認証アルゴリズムを指定するパラメータです。ただし、この
9.7 IKE による折衝パラメータ ● 205
トランスフォームIDのみで認証アルゴリズムが決定するわけではなく、SA属性として定義され
ている認証アルゴリズム属性を共に指定する必要があります。例えば、認証アルゴリズムとして
HMAC-MD5-96を指定する場合には、トランスフォームIDにAH_MD5を指定し、認証アルゴリ
ズム属性に HMAC-MD5 を指定します。
表 9-21 AH トランスフォーム ID
ID 番号
トランスフォーム ID
用途
0、1
予約
使用されない
2
AH_MD5（実装必須）
MD5 を使用する認証アルゴリズム
3
AH_SHA（実装必須）
SHA-1 を使用する認証アルゴリズム
4
AH_DES
DES を使用する認証アルゴリズム
5
AH_SHA2-256
SHA-256 を使用する認証アルゴリズム
6
AH_SHA2-384
SHA-384 を使用する認証アルゴリズム
7
AH_SHA2-512
SHA-512 を使用する認証アルゴリズム
8
AH_RIPEMD
RIPEMD を使用する認証アルゴリズム
9
AH_AES-XCBC-MAC
AES-XCBC-MAC を使用する認証アルゴリズム
10 ∼ 248
予約（未割り当て）
未割り当て
249 ∼ 255
プライベート用
プライベートでの使用
ESP トランスフォーム ID
表 9-22 に、本書執筆時点で定義されている ESP トランスフォームID を示します。ESP トラン
スフォーム ID では、ESP で使用する暗号化アルゴリズムを指定します。
表 9-22 ESP トランスフォーム ID
ID 番号
トランスフォーム ID
用途
0
予約
使用されない
1
ESP_DES_IV64
64 ビット IV を伴う DES-CBC（RFC 1829）
2
ESP_DES（実装必須）
DES-CBC（RFC 2405）
3
ESP_3DES
3DES-CBC（RFC 2451）
4
ESP_RC5
RC5-R16-B64-CBC（RFC 2451）
206 ● 9 章 SA 管理と鍵管理
表 9-22 ESP トランスフォーム ID（つづき）
ID 番号
トランスフォーム ID
用途
5
ESP_IDEA
IDEA-CBC（RFC 2451）
6
ESP_CAST
CAST-128-CBC（RFC 2451）
7
ESP_BLOWFISH
Blowfish-CBC（RFC 2451）
8
ESP_3IDEA
3IDEA のために予約
9
ESP_DES_IV32
32 ビット IV を伴う DES-CBC（RFC 1829）
10
ESP_RC4
RC4 のために予約
11
ESP_NULL（実装必須）
NULL 暗号化アルゴリズム（RFC 2410）
12
ESP_AES-CBC
AES-CBC（RFC 3602）
13
ESP_AES-CTR
AES-CTR（draft-ietf-ipsec-ciph-aes-ctr-05.txt）
14 ∼ 248
予約（未割り当て）
未割り当て
249 ∼ 255
プライベート用
プライベート用に使用
IPComp トランスフォーム ID
表9-23に、本書執筆時点で定義されているIPCompトランスフォームIDを示します。IPComp
トランスフォーム ID では、IPComp で使用する圧縮アルゴリズムを指定します。
表 9-23 IPComp トランスフォーム ID
ID 番号
トランスフォーム ID
用途
0
予約
使用されない
1
IPCOMP_OUI
独自の圧縮アルゴリズム用
2
IPCOMP_DEFLATE
DEFLATE（RFC 2394）
3
IPCOMP_LZS
LZS（RFC 2395）
4
IPCOMP_LZJH
LZJH（RFC 3051）
5 ∼ 47
予約（未割り当て）
未割り当て
48 ∼ 63
プライベート用
プライベートでの使用
64 ∼ 255
予約
将来のために予約
9.7 IKE による折衝パラメータ ● 207
認証アルゴリズム
AHでは、IPsec SAの認証アルゴリズム属性
（Authentication Algorithm）で認証アルゴリズムを
指定する必要があります。表 9-24 に本書執筆時点で定義されている IPsec SA 認証アルゴリズム
属性値と、その属性値を指定するために必要な AH トランスフォーム ID を示します。
ESPでは、認証アルゴリズム属性の指定はオプションです。ESPで認証機能を利用する場合に
は、この認証アルゴリズム属性で、認証アルゴリズムを指定します。
表 9-24 IPsec SA 認証アルゴリズム属性値
属性値
認証アルゴリズム
AH トランス
フォーム ID
用途
0
予約
―
使用されない
1
HMAC-MD5（実装必須）
AH_MD5
HMAC-MD5-96（RFC 2403）
2
HMAC-SHA（実装必須）
AH_SHA
HMAC-SHA-1-96（RFC 2404）
3
DES-MAC
AH_DES
DES-MAC
4
KPDK
AH_MD5
Keyed-MD5（RFC 1828）
5
HMAC-SHA2-256
AH_SHA2-256
HMAC-SHA-256
6
HMAC-SHA2-384
AH_SHA2-384
HMAC-SHA-384
7
HMAC-SHA2-512
AH_SHA2-512
HMAC-SHA-512
8
HMAC-RIPEMD
AH_RIPEMD
HMAC-RIPEMD-160-96（RFC 2857）
9
AES-XCBC-MAC
AH_AESXCBC-MAC
AES-XCBC-MAC-96（RFC 3566）
10 ∼ 61,439
予約（未割り当て）
―
未割り当て
61,440 ∼ 65,535
プライベート用
―
プライベートでの使用
Oakley グループ
IPsec SA（AH または ESP）で PFS を有効にする場合には、IPsec SA の Oakley グループ属性
（Group Description）でOakleyグループを指定します。表9-25に、本書執筆時点で定義されてい
る Oakley グループを示します。
208 ● 9 章 SA 管理と鍵管理
表 9-25 IPsec SA Oakley グループ属性値
属性値（グループ番号）
Oakley グループの種類（Group Description）
0
予約
1
768 ビット MODP グループ（実装必須）
2
1,024 ビット MODP グループ
3
155 ビット EC2N グループ
4
185 ビット EC2N グループ
5
1,536 ビット MODP グループ
6
163 ビット EC2N グループ（ランダムシード）
7
163 ビット EC2N グループ（Koblitz 曲線）
8
283 ビット EC2N グループ（ランダムシード）
9
283 ビット EC2N グループ（Koblitz 曲線）
10
409 ビット EC2N グループ（ランダムシード）
11
409 ビット EC2N グループ（Koblitz 曲線）
12
571 ビット EC2N グループ（ランダムシード）
13
571 ビット EC2N グループ（Koblitz 曲線）
14 ∼ 32,767
予約（未割り当て）
32,768 ∼ 65,535
プライベート用
IPsec SA の有効期間
IPsec SAの有効期間の単位をIPsec SAの有効期間タイプ属性（SA Life Type）で指定します。表
9-26 に、本書執筆時点で定義されている IPsec SA 有効期間タイプ属性の属性値を示します。有
効期間は、「時間（秒）」または「転送量（キロバイト）」で指定することができます。これらを同
時に指定した場合には、どちらかの一方の有効期間が過ぎた場合に SA が無効となります。
また、実際の有効期間の値は、IPsec SAの有効期間属性（SA Life Duration）によって指定しま
す。有効期間属性が指定されない場合には、IPsec SA の有効期間は、デフォルトで 28,800 秒（8
時間）に設定されます。
9.7 IKE による折衝パラメータ ● 209
表 9-26 IPsec SA 有効期間タイプ属性値
属性値
有効期間タイプ（SA Life Type）
0
予約
1
秒
2
キロバイト
3 ∼ 61,439
予約（未割り当て）
61,440 ∼ 65,535
プライベート用
カプセル化モード
IPsec SA のカプセル化モード属性（Encapsulation Mode）によって、使用する IPsec のモード
（トンネルモードまたはトランスポートモード）を指定します。表 9-27 に、本書執筆時点で定義
されている IPsec SA カプセル化モード属性の属性値を示します。
表 9-27 IPsec SA カプセル化モード属性値
属性値
カプセル化モード（Encapsulation Mode）
0
予約
1
トンネルモード
2
トランスポートモード
3 ∼ 61,439
予約（未割り当て）
61,440 ∼ 65,535
プライベート用
ECN トンネル
IPsec SA の ECN トンネル属性（ECN Tunnel）によって、ECN を IPsec トンネルで有効とする
か（Allowed）、無効とするか（Forbidden）を指定します。この属性はオプションです。表9-28に、
本書執筆時点で定義されているIPsec SA ECNトンネル属性の属性値を示します。属性が存在し
ない場合や、属性値が指定されない場合には、無効（Forbidden）であるとみなされます。
210 ● 9 章 SA 管理と鍵管理
表 9-28 IPsec SA ECN トンネル属性値
属性値
ECN トンネル（ECN Tunnel）
0
予約
1
有効（Allowed）
2
無効（Forbidden）
3 ∼ 61,439
予約（未割り当て）
61,440 ∼ 65,535
プライベート用
参考文献
[1] D. Harkins and D. Carrel, “The Internet Key Exchange (IKE)”, RFC 2409, November
1998.
[2] D. Maughan, M. Schertler, M. Schneider, and J. Turner, “Internet Security Association
and Key Management Protocol (ISAKMP)”, RFC 2408, November 1998.
[3] H. Orman, “The OAKLEY Key Determination Protocol”, RFC 2412, November 1998.
[4] H. Krawczyk, “SKEME: A Versatile Secure Key Exchange Mechanism for Internet”, ISOC
Secure Networks and Distributed Systems Symposium, San Diego, 1996.
[5] D. Piper, “The Internet IP Security Domain of Interpretation for ISAKMP”, RFC 2407,
November 1998.
[6] S. Blake-Wilson and P. Fahn, “IKE Authentication Using ECDSA”, draft-ietf-ipsec-ikeauth-ecdsa-02.txt, March 2001, Work in Progress.
[7] D. Dukes and R. Pereira, “The ISAKMP Configuration Method”, draft-dukes-ike-modecfg-02.txt, September 2001, Work in Progress.
[8] ”From RFC 2409 (IKE) Attribute Assigned Numbers”, http://www.iana.org/assignments/
ipsec-registry
[9] T. Kivinen and M. Kojo, “More Modular Exponential (MODP) Diffie-Hellman groups for
Internet Key Exchange (IKE)”, RFC 3526, May 2003.
[10] S. Blake-Wilson, D. Brown, Y. Poeluev, and M. Salter, “Additional ECC Groups For IKE”,
draft-ietf-ipsec-ike-ecc-groups-04.txt, July 2002, Work in Progress.
[11] “FROM RFC 2407 and RFC 2408 “Magic Numbers” for ISAKMP Protocol”, http://
www.iana.org/assignments/isakmp-registry

IPv6対応 組み込み向けTCP／IPプロトコルスタック

レセプトのオンライン請求を行うには

FortiOS5.2 - 次世代ファイアウォール向け

総合脅威管理（UTM）

日照が Primetals Technologies が納入した Arvedi ESP プラントで最初

PDFファイル - 医薬品医療機器情報提供ホームページ

IPv4/IPv6