ipsecのアーキテクチャ - tatsuya baba personal website · 74 5章...

　　73

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とは独立したプ

● IPsecプロトコルスイート● IPsecが提供するサービス●トランスポートモードとトンネルモード●セキュリティポリシー●セキュリティアソシエーション● IPsec処理の流れ● IPsecの実装

74 ● 5章　IPsecのアーキテクチャ

ロトコルですが、通常は IPsecと組み合わせて使用されるため、AH、ESP、IPComp、IKEの 4

つのプロトコルをまとめて IPsecと呼ぶ場合があります。

　AHは、IPパケットの完全性を確保するセキュリティプロトコルであり、プロトコル番号51が

使用されます。また、ESPは、IPパケットの機密性と完全性を確保するセキュリティプロトコ

ルであり、プロトコル番号 50が使用されます。そして、IPCompは、IPパケットの圧縮を行う

プロトコルであり、プロトコル番号108が使用されます。これらの3つのプロトコルは、組み合

わせて使用することも、単独で使用することも可能です。

　IKEは、AHやESP、IPCompで使用するアルゴリズムの種類や鍵などの情報を交換するため

表 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」？「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の発行状況を確認しておく必要があります。

IPsec DOI（RFC 2407）

アルゴリズム認証アルゴリズム（RFC 2403、2404、2857）

暗号化アルゴリズム（RFC 2405、2410、2451）

鍵管理プロトコル

圧縮アルゴリズム（RFC 2394、2395、3051）

セキュリティプロトコル AH（RFC 2402） ESP（RFC 2406）

IKE（RFC 2409）

ISAKMP（RFC 2408）

Oakley（RFC 2412）

IPsecアーキテクチャ（RFC 2401）

IPComp（RFC 3173）

図 5-1　IPsecドキュメント体系


表 5-2　IPsec全般に関するRFC

RFC 2401 インターネットプロトコルのためのセキュリティアーキテクチャ

（PS）（Security Architecture for the Internet Protocol）

RFC 2411 IPセキュリティ文書体系（I）（IP Security Document Roadmap）

PS：Proposed Standard（標準提案） I：Informational（情報提供）

表 5-3　AHおよび ESPに関するRFC

RFC 2402 IP 認証ヘッダ（PS）（IP Authentication Header）

RFC 2406 IP暗号ペイロード（ESP）（PS）（IP Encapsulating Security Payload（ESP））

RFC 2403 ESPおよびAHでのHMAC-MD5-96の使用法（PS）（The Use of HMAC-MD5-96 within ESP and AH）

RFC 2404 ESPおよびAHでのHMAC-SHA-1-96の使用法（PS）（The Use of HMAC-SHA-1-96 within ESP and AH）

RFC 2857 ESPおよびAHでのHMAC-RIPEMD-160-96の使用法（PS）（The Use of HMAC-RIPEMD-160-96 within ESP and AH）

RFC 2405 明示的 IVを伴うESP DES-CBC暗号アルゴリズム（PS）（The ESP DES-CBC Cipher Algorithm With Explicit IV）

RFC 2410 NULL暗号化アルゴリズムと IPsecでのその使用法（PS）（The NULL Encryption Algorithm and Its Use With IPsec）

RFC 2451 ESP CBCモード暗号アルゴリズム（PS）（ESP CBC-Mode Cipher Algorithms）

PS：Proposed Standard（標準提案）

表 5-4　IKEに関するRFC

RFC 2407 ISAKMPにおける IPセキュリティ翻訳ドメイン（PS）（The Internet IP Security Domain of Interpretation for ISAKMP）

RFC 2408 インターネットセキュリティアソシエーションおよび鍵管理プロトコル（ISAKMP）（PS）（Internet Security Association and Key Management Protocol（ISAKMP））

RFC 2409 インターネット鍵交換（IKE）（PS）（The Internet Key Exchange（IKE））

RFC 2412 OAKLEY鍵決定プロトコル（I）（The OAKLEY Key Determination Protocol）


5.1　IPsecプロトコルスイート ● 77

表 5-5　IPCompに関するRFC

RFC 3173 IPペイロード圧縮プロトコル（IPComp）（PS）（IP Payload Compression Protocol（IPComp））

RFC 2394 DEFLATEを用いた IPペイロード圧縮（I）（IP Payload Compression Using DEFLATE）

RFC 2395 LZSを用いた IPペイロード圧縮（I）（IP Payload Compression Using LZS）

RFC 3051 ITU-T V.44パケット方式を用いた IPペイロード圧縮（I）（IP Payload Compression Using ITU-T V.44 Packet Method）


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ポリシーと呼ぶ場合


もあります。セキュリティポリシーは、セキュリティポリシーデータベース（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 トランスポートモードとトンネルモード」で説明するカプセル化モード


によって、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

ホストBホストA

トランスポートモードIPsec入力処理

トランスポートモードIPsec出力処理

図 5-2　ホスト間におけるトランスポートモード IPsec

5.3　トランスポートモードとトンネルモード ● 81

トランスポートモードのヘッダ構成（IPv4）　IPv4では、IPv4ヘッダとトランスポート層プロトコルヘッダの間に IPsecで使用するヘッダ

（AHヘッダまたは ESPヘッダ）を挿入します（図 5-3）。

AHヘッダ

IPv4ヘッダ

ESPヘッダ

ESPトレーラ

データTCPヘッダ

ESP認証データ

IPv4ヘッダ

ESPヘッダ

ESPトレーラ


IPv4ヘッダ

AHヘッダ


IPv4ヘッダ

データ

（a）IPsec適用前の IPv4パケット

（b）AH適用後の IPv4パケット

（c）ESP適用後の IPv4パケット

（d）ESPおよびAH適用後の IPv4パケット

TCPヘッダ

図 5-3　トランスポートモード IPsecを適用した IPv4パケット（網掛部は暗号化）

トランスポートモードのヘッダ構成（IPv6）　IPv6では、IPsecのAHヘッダおよびESPヘッダは IPv6拡張ヘッダとして定義されています。

IPv6の場合も IPv4の場合と同様に、IPv6ヘッダとトランスポート層プロトコルヘッダの間（終

点オプションヘッダが存在する場合には、終点オプションヘッダの前）に IPsecで使用するヘッ

ダ（AHヘッダまたは ESPヘッダ）を挿入します（図 5-4）。

5.3.2　トンネルモード　トンネルモードは、主にセキュリティゲートウェイ間でIPsecトンネルを構築する場合に使用

されます。トンネルモードでは、IPパケット全体に対してセキュリティ機能を適用します。そし

て、セキュリティゲートウェイが新たにトンネル配送用のIPヘッダを追加して、相手側のセキュ

リティゲートウェイに送信します。こうすることで、セキュリティゲートウェイ間で安全なトン


ネル（VPN）を構築することが可能となります。

　セキュリティゲートウェイ間でトンネルモードを使用する場合は、パケットを送信するホスト

はIPsecを実装する必要は無く、トンネルの始点および終点となるセキュリティゲートウェイが

IPsecの機能を実現します（図5-5）。また、セキュリティゲートウェイ間では、ホストが送信した

IPパケットがカプセル化されるため、ホストのアドレスを隠すことが可能です。このため、セ

キュリティゲートウェイで守られたネットワークでは、プライベートアドレスを利用することが

AHヘッダ

AHヘッダ

IPv6ヘッダ

経路制御ヘッダ

ESPヘッダ

ESPトレーラ


終点オプションヘッダ

IPv6ヘッダ


ESP認証データ

ESPヘッダ

ESPトレーラ



IPv6ヘッダ




IPv6ヘッダ








図 5-4　トランスポートモード IPsecを適用した IPv6パケット（網掛部は暗号化）

トンネルモード IPsec

ホストBセキュリティゲートウェイB

ホストAセキュリティゲートウェイA

トンネルモードIPsec入力処理

トンネルモードIPsec出力処理

図 5-5　セキュリティゲートウェイ間におけるトンネルモード IPsec


可能となります。

　また、セキュリティゲートウェイ間だけでなく、セキュリティゲートウェイとホストとの間に

おいてもトンネルモードを使用することが可能です。例えば、送信側にトンネルモードのIPsec

処理を行うセキュリティゲートウェイを設置し、受信側のホストが直接IPsecパケットを受信す

る場合は、受信側のホストがトンネルモードの IPsec入力処理を行う必要があります（図 5-6）。

　同様に、受信側のみにセキュリティゲートウェイを設置した場合は、送信側のホストがトンネ

ルモードの IPsec出力処理を行う必要があります（図 5-7）。

　また、ホスト間でトンネルモードを利用することも可能です（図5-8）。ただし、トンネルモー


ホストBホストAセキュリティゲートウェイA



図 5-6　セキュリティゲートウェイからホストへのトンネルモード IPsec


ホストBセキュリティゲートウェイB

ホストA



図 5-7　ホストからセキュリティゲートウェイへのトンネルモード IPsec





図 5-8　ホスト間におけるトンネルモード IPsec


ドでは、トンネル配送用に新たに付与する IPヘッダのオーバーヘッドが発生するため、ホスト

間の場合は、通常トランスポートモードを使用します。

IPv4パケットに IPv4トンネルモード IPsecを適用する場合のヘッダ構成　IPv4パケットに対してトンネルモード IPsecを適用する場合は、図5-9に示すように、オリジ

ナルの IPv4パケット全体に対して IPsecのセキュリティ機能を適用し、そのパケットをトンネ

ルの終点まで運ぶための IPv4ヘッダ（トンネル配送用 IPv4ヘッダ）と IPsecで使用するヘッダ

（AHヘッダまたは ESPヘッダ）を新たに追加します。オリジナルの IPv4ヘッダは、トンネル上

を配送される間は参照されることはありません。

AHヘッダ

AHヘッダ

IPv4ヘッダ

IPv4ヘッダ

トンネルIPv4ヘッダ


ESPヘッダ

ESPトレーラ


ESP認証データ

ESPヘッダ

ESPトレーラ


IPv4ヘッダ



IPv4ヘッダ






図5-9　トンネルモード IPsec（IPv4）を適用した IPv4パケット（網掛部は暗号化）

IPv6パケットに IPv6トンネルモード IPsecを適用する場合のヘッダ構成　IPv6パケットに対してトンネルモード IPsecを適用する場合は、図 5-10に示すように、オリ

ジナルの IPv6パケット全体に対して IPsecのセキュリティ機能を適用し、そのパケットをトン

ネルの終点まで運ぶための IPv6ヘッダ（トンネル配送用 IPv6ヘッダ）と IPsecで使用するヘッダ

（AHヘッダまたは ESPヘッダ）を新たに追加します。オリジナルの IPv6ヘッダは、トンネル上


AHヘッダ

AHヘッダ

IPv6ヘッダ

IPv6ヘッダ



ESPヘッダ

ESPトレーラ


ESP認証データ

ESPヘッダ

ESPトレーラ


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ヘッダは、トンネル上を配送される間は参照されることはありません。


AHヘッダ

AHヘッダ

IPv4ヘッダ

IPv4ヘッダ



ESPヘッダ

ESPトレーラ


ESP認証データ

ESPヘッダ

ESPトレーラ


IPv4ヘッダ



IPv4ヘッダ







AHヘッダ

AHヘッダ

IPv6ヘッダ

IPv6ヘッダ



ESPヘッダ

ESPトレーラ


ESP認証データ

ESPヘッダ

ESPトレーラ


IPv6ヘッダ



IPv6ヘッダ







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アドレス、トランスポー

ト層プロトコル、送信元ポート番号、宛先ポート番号などが使用されます。


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）の例

2 Any Any Any Any “bypass IPsec”

“apply IPsec”[ESP]トンネルモードトンネルの始点： 10.1.1.1トンネルの終点： 10.2.1.1暗号化アルゴリズム： DES-CBC認証アルゴリズム： HMAC-SHA-1

評価セレクタ適用する処理

順序始点 IPアドレス終点 IPアドレスプロトコル宛先ポート

1 10.1.1.0/24 10.2.1.0/24 Any Any

トンネルモード IPsec 10.2.1.1

10.2.1.0/2410.1.1.0/24

10.1.1.1

IPsecを適用しないで送信

その他のネットワーク

図 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）

ESP用の SA（A→ B）

ESP用の SA（B→ A）


図 5-15　ホスト間に確立されるセキュリティアソシエーション（AHと ESPを使用した場合）


　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　セキュリティアソシエーションのパラメータ

外側ヘッダの終点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パラメータ SAパラメータ値の例

* SAを検索する際にキーとして使用されるパラメータ。


べてのパラメータが必須というわけではありません。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を無効とするか


どうかをこのシーケンス番号カウンタオーバーフローフラグに記述します。デフォルトでは、

シーケンス番号がオーバーフローした場合に SAが無効となり、新しい SAが折衝され、シーケ

ンス番号のカウンタが0に戻されます。しかし、受信側でリプレイ防御機能が無効とされている

ことがあらかじめ判明している場合（SAが手動で設定されている場合など）には、オーバーフロー

した場合でも引き続き SAを使用することができます。

セキュリティアソシエーションの有効期間

　IKEによる自動鍵交換を行う場合には、SAの有効期間（鍵の更新間隔）を設定します。有効期

間には、SAを更新する時期を指定するソフト有効期間と、SAを無効とする時期を指定するハー

ド有効期間の2種類があります。ソフト有効期間が過ぎると新しいSAが折衝されますが、それ

まで使用されていたSAはハード有効期間が過ぎるまでは引き続き使用することが可能です（図5-

16）。これは、SAが無効になってから新しいSAの折衝を行うと、折衝が完了するまでの間はIPsec

が適用できない状態となるため、新しい SAの折衝を現在の SAが無効となる前に行い、実際に

SAの有効期間が過ぎて無効となると同時に新しいSAを使用してIPsecによる通信を継続するこ

とができるようにするためです。有効期間は、時間（秒単位）での指定と、送信するデータ量（キ

ロバイト単位）での指定が可能です。両方が指定された場合には、どちらか一方の有効期間が過

ぎた時点で SAが無効となります。

時間

新しい SAの有効期間

新しい SAの折衝

ソフト有効期間ハード有効期間

SAの有効期間

×

図 5-16　ソフト有効期間とハード有効期間

シーケンス番号カウンタ

　シーケンス番号カウンタは、IPsec出力処理で使用されます。シーケンス番号は、リプレイ攻

撃から防御するための 32ビットの値です。AHおよび ESPのヘッダには、このシーケンス番号

を保持するためのシーケンス番号フィールドが存在します。SADでは、SAごとにシーケンス番

号のカウンタが用意され、パケットを送信する度にカウンタが 1ずつ増加されます。


リプレイ防御ウィンドウ

　リプレイ防御ウィンドウは、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パラメータその他のSAパラメータ

終点IPアドレス IPsecプロトコル SPI

10.2.1.1 ESP 3000 カプセル化モード：トンネルモード

暗号化アルゴリズム：Blowfish-CBC

暗号化鍵：1048ea648 . . . 246a5f7

IV：a7323d1278f12ba2

認証アルゴリズム：HMAC-SHA-1-96

認証鍵：826170af1 . . . 288e8da

シーケンス番号：882

10.2.2.1 ESP 3010 カプセル化モード：トンネルモード

暗号化アルゴリズム：3DES-CBC

暗号化鍵：a430e05f2 . . . 5a4fe24


表5-9　セキュリティアソシエーションデータベース（SAD）の例（つづき）

キーとなるSAパラメータその他のSAパラメータ

終点IPアドレス IPsecプロトコル SPI

IV：42df7d386ae8f1a2

認証アルゴリズム：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）」で

①処理方法の問い合わせ

②SPDの検索

出力用SPD

③処理方法（破棄または通常処理）を返答

IPsec処理部

ポリシー管理部

出力用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の生成　を依頼

⑥受信側 IKEとSAを　ネゴシエーション

②SPDの検索③SADの検索　（存在しない）

⑦SAを登録

出力用SPD

④処理方法（破棄）　を返答

IPsec処理部


受信側IKE

IKE

出力用SAD

図 5-18　IPsecを適用する場合（SAが存在しなかった場合）の処理の流れ

①処理方法の　問い合わせ

②SPDの検索③SADの検索

出力用SPD

④処理方法（IPsecを適　用）と必要なパラメータ　を返答

IPsec処理部


出力用SAD

図 5-19　IPsecを適用する場合（SAが存在した場合）の処理の流れ

　5. AHと ESPの両方のプロトコルを組み合わせて使用する場合には、最初に ESPの処理を

行います。この時、ESP用のSAパラメータとして記述されている暗号化アルゴリズムや

暗号化用の共有秘密鍵、IVなどを使用してESP処理を行います。ESP処理が終了したら


同様に AH処理を行います。

　6. IPsec処理が適用されたパケットを送信します。

5.6.2　IPsec機器での入力処理IPパケットが IPsec機器に入力された場合には、次の IPsec入力処理を適用します。

非 IPsecパケットの入力処理　IPsecが適用されていない IPパケットが入力された場合には、次の処理を行います。

　1. IPパケットの始点IPアドレス、終点IPアドレス、上位層プロトコル、ポート番号などの

セレクタをキーとして入力用 SPDからセキュリティポリシーを検索します（図 5-20）。

① IPsecポリシーの問い合わせ

② SPDの検索

入力用SPD

③ IPsecポリシーを返答

IPsec処理部


入力用SAD

図 5-20　非 IPsecパケットが入力された場合の処理の流れ

　2. 検索されたセキュリティポリシーが「破棄（discard）」であった場合には、IPパケットを

破棄します。また、「IPsecを適用（apply IPsec）」であった場合には、この IPパケットに

はIPsecが適用されていないため、このパケットを破棄します。そして、「IPsecを適用し

ない（bypass IPsec）」であった場合には、入力された IPパケットの状態と条件が合致す

るため、IPパケットを受信し、通常の処理を行います。

IPsecパケットの入力処理　IPsecが適用されているパケットが入力された場合には、次の処理を行います。


　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）。

① 処理方法の問い合わせ

② SADの検索

入力用SPD

③ 処理に必要なパラメータを返答

IPsec処理部


入力用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パケットを転送します。


5.6.3　トンネリング処理　ここでは、トンネルモード IPsecが使用された場合に追加するトンネル配送用 IPヘッダの生

成方法とオリジナル IPヘッダの処理方法について説明します。

カプセル化処理（トンネルモード IPsec出力処理）　トンネルモードの IPsec出力処理では、表 5-10に示した規則にしたがってトンネル配送用 IP

ヘッダが生成され、オリジナル IPヘッダが処理されます。ECNフィールドは、該当する SAの

ECNトンネル属性の内容（ForbiddenまたはAllowed）によって処理方法が異なります†。

　† RFC 2401では、トンネル配送用 IPヘッダの TOSフィールド（IPv4の場合）またはトラフィッククラ

スフィールド（IPv6の場合）には、オリジナル IPヘッダの内容をコピーするとなっていましたが、これらのフィールドの上位 6ビットがDS（Differentiated Services）フィールド、下位 2ビットがECN（Explicit Congestion Notification）フィールドとして再定義されたため、IPsecにおけるこれらのフィールドの処理方法が変更されました [3]。

① IPsecポリシーの問い合わせ

② SPDの検索

入力用 SPD

③ IPsecポリシーを返答

IPsec処理部


入力用 SAD

図 5-22　IPsecパケットが入力された場合のSPD検索

表 5-10　カプセル化時のオリジナル IPヘッダおよびトンネル配送用ヘッダの処理

バージョンバージョン変更なし 4（IPv4）または 6（IPv6）

ヘッダ長 ─ 変更なし新たに作成

DS DS 変更なしオリジナル IPヘッダの値をコピー

IPv4ヘッダ IPv6ヘッダオリジナルIPヘッダトンネル配送用 IPヘッダフィールドフィールド（内側 IPヘッダ）（外側 IPヘッダ）


表 5-10　カプセル化時のオリジナル IPヘッダおよびトンネル配送用ヘッダの処理（つづき）

ECNトンネル＝Forbidden（デフォルト）　→ “00”にセット ECNトンネル＝Allowed ECN ECN 変更なし　→ “11”以外の場合はオリジナル IPヘッダの値をコピー

　→ “11”の場合は“10”にセット

パケット全体長ペイロード長変更なし新たに作成

識別子 ─ 変更なし新たに作成

フラグ ─ 変更なし MFフラグと予約フラグは 0 DFフラグの設定は実装依存

フラグメント ─ 変更なし新たに作成（0をセット）オフセット

TTL 中継限界数 1減らす新たに作成

プロトコル番号次ヘッダ番号変更なし新たに作成

ヘッダチェックサム ─ 再計算新たに作成

始点 IPアドレス始点 IPアドレス変更なし新たに作成（トンネルの始点）

終点 IPアドレス終点 IPアドレス変更なし新たに作成（トンネルの終点）

─ フローラベル変更なしオリジナルの内容をコピー

または新たに作成

IPv4ヘッダ IPv6ヘッダオリジナルIPヘッダトンネル配送用 IPヘッダフィールドフィールド（内側 IPヘッダ）（外側 IPヘッダ）

カプセル解放処理（トンネルモード IPsec入力処理）　トンネルモードのIPsec入力処理では、トンネル配送用IPヘッダは単に削除されます。また、

カプセル化されていたオリジナル IPヘッダの各フィールドは表 5-11のように処理されます。

ECNフィールドは、該当するSAのECNトンネル属性の内容（ForbiddenまたはAllowed）によっ

て処理方法が異なります。

表 5-11　カプセル解放時のオリジナル IPヘッダの処理

バージョンバージョン変更なし

ヘッダ長 ─ 変更なし

IPv4ヘッダ IPv6ヘッダオリジナルIPヘッダフィールドフィールド（内側IPヘッダ）


表 5-11　カプセル解放時のオリジナル IPヘッダの処理（つづき）

DS DS 変更なし

ECNトンネル＝Forbidden（デフォルト）　→ 変更なし

ECNトンネル＝Allowed ECN ECN 　→ トンネル配送用ヘッダの値が "11"で、オリジナル IP ヘッダの値が "01"または "10"の場合は "11"をセット　→ それ以外の場合は変更なし

パケット全体長ペイロード長変更なし

識別子 ─ 変更なし

フラグ ─ 変更なし

フラグメント ─ 変更なし

オフセット

TTL 中継限界数 1減らす

プロトコル番号次ヘッダ番号変更なし

ヘッダチェックサム ─ 再計算

始点 IPアドレス始点 IPアドレス変更なし

終点 IPアドレス終点 IPアドレス変更なし

─ フローラベル変更なし

IPv4ヘッダ IPv6ヘッダオリジナルIPヘッダフィールドフィールド（内側IPヘッダ）

5.6.4　リプレイ防御処理　IPsecでは、シーケンス番号とリプレイ防御ウィンドウを使用することで、リプレイ攻撃に対

する防御を行います。送信側ではパケットにシーケンス番号を付与して送信し、受信側ではリプ

レイ防御ウィンドウを使用して、受信されたパケットのシーケンス番号と既に受信されたパケッ

トのシーケンス番号を確認し、重複があった場合にはパケットを破棄します（図 5-23）。

　リプレイ防御機能を有効とするかどうかは、受信側で決定されます。ただし、手動でSAを設

定する場合には、リプレイ防御機能は無効となります。また、リプレイ防御機能を有効にする場

合は、AHを使用するか、またはESPの認証機能を有効にすることによって、AHまたはESPの

ヘッダを保護する必要があります。


受信可能パケット受信済パケット

再送パケット同じシーケンス番号のため受信拒否

受信側ホスト送信側ホスト

攻撃側ホスト

#4

#2

#1

#2

#5 #3

図 5-23　リプレイ攻撃からの防御

シーケンス番号

　AHおよび ESPのヘッダには、32ビットのシーケンス番号フィールドが存在します。新たに

SAが生成されると、シーケンス番号カウンタは0にセットされます。送信側は、IPsecパケット

を送信する際に、このシーケンス番号カウンタを1増加させてから、AHヘッダまたはESPヘッ

ダのシーケンス番号フィールドにその値をセットします（つまりSAが生成されてから最初に送信

する IPsecパケットのシーケンス番号フィールドには 1がセットされることになります）。この

シーケンス番号カウンタは 232でオーバーフローが発生するため、その前に新しく SAを生成す

る必要があります。ただし、受信側でリプレイ防御機能が無効とされていることがあらかじめ判

明している場合は、オーバーフローしてカウンタが一巡した場合でも引き続きSAを使用するこ

とができます。

リプレイ防御ウィンドウ

　受信側では、シーケンス番号を検証するために、リプレイ防御ウィンドウを使用します。送信

側におけるシーケンス番号カウンタの管理とパケットへのシーケンス番号の付与は必須ですが、

受信側でのシーケンス番号の検証処理は必須ではなく、受信側の判断に任されます。

　リプレイ防御ウィンドウは、図 5-24に示すような 32ビット以上のビットマスクとなります

（AHおよびESPでは 64ビットが推奨されています）。リプレイ防御ウィンドウのビット位置は

シーケンス番号と対応しており、最近到着した IPsecパケットのシーケンス番号が一番右側の

ビット位置に対応します。つまり、IPsecパケットが到着する度に、リプレイ防御ウィンドウが

右にスライドしていくことになります。例えば、シーケンス番号がN+31のパケットが到着した

場合は、リプレイ防御ウィンドウの一番右側のビットに対応するシーケンス番号がN+31となり、

そのビットの値が 1となります（図 5-24の（a））。次に、シーケンス番号が N+34の IPsecパケッ


トが到着した場合には、リプレイ防御ウィンドウが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に付属していますの


N N+3 N+31

（a）シーケンス番号がN+31のパケットまでが到着している状態のリプレイ防御ウィンドウ（シーケンス番号がN+3のパケットは到着していない）

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

N N+3 N+31 N+34

（b）シーケンス番号がN+34のパケットが到着した場合のリプレイ防御ウィンドウ（シーケンス番号がN+3、N+32、N+33のパケットは到着していない）

1 1 1 0 0 01 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

N N+4 N+31 N+35

（c）シーケンス番号がN+35のパケットが到着した場合のリプレイ防御ウィンドウ（シーケンス番号がN+3、N+32、N+33のパケットは到着していない）

1 1 1 0 0 01 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 1

図 5-24　リプレイ防御ウィンドウの例（32ビットの場合）


で参考にするとよいと思います。

シーケンス番号フィールドの保護

　シーケンス番号とリプレイ防御ウィンドウによってリプレイ攻撃からの防御が可能となります

が、リプレイ攻撃を行う者が、再送する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ビットに拡張できるようにするため

の議論が行われています。


　

コラム： 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-25）。このため、フラグメント再構成処理やフラグメント分割処

理をなるべく発生させないようにするためには、セキュリティゲートウェイなどのトンネルモー

ド IPsec処理を行う機器に、フラグメントされた状態のパケットや、IPsec処理によってフラグ

メントされてしまうようなサイズのパケットを送信しないことが必要となってきます。

フラグメントパケットフラグメントパケット

トンネルモード IPsec処理IPsec層

IP層フラグメント再構成処理

フラグメント分割処理

図 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機器がセキュ

リティゲートウェイである場合には、この情報を送信元であるホストに転送する必要があります


が、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に対して第三者がパッチを開発する場合などがあります。

IPsec処理部を統合

アプリケーション

TCP/UDP

IP

データリンク層


TCP/UDP

IP+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を利用できるようになります。


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.

IPsec処理部を挿入


TCP/UDP

IP IP



TCP/UDP

IPsec


図5-27　Bump-in-the-stack（BITS）実装

　　109

6章認証ヘッダ（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ではトラフィッククラスおよびフローラベル）、チェッ

● AHの機能● AHプロトコルフォーマット●認証アルゴリズム● AH処理の流れ

110 ● 6章　認証ヘッダ（AH）

クサムなどがありますが、これらのフィールドは AHで保護することはできません。

データ送信元の認証

　AHヘッダに含まれている ICVを検証すると、その IPパケットが、事前に安全な方法で共有

された共有秘密鍵を持つ相手から送信されたものであることを確認することができます。

リプレイ防御

　AHヘッダに含まれているシーケンス番号をチェックすることで、再送されたパケットの受信

を拒否することが可能となります。このリプレイ防御の機能はオプションです。

6.2　AHプロトコルフォーマット　ここでは、AHのヘッダフォーマットと AHヘッダが挿入される位置について説明します。

6.2.1　AHのヘッダフォーマット　AHのヘッダフォーマットは図 6-1のようになっています。

次ヘッダ番号フィールド

次ヘッダ番号フィールドは、8ビットの固定長フィールドです。このフィールドには、AH

の次に挿入されるヘッダの IPプロトコル番号が入ります。


セキュリティパラメータインデックス（SPI）

予約ペイロード長次ヘッダ番号

0 8 16 31

認証データ（可変長：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値の範囲と用途

0 ローカルでの利用

1～255 予約

256～手動および自動設定用

SPI値用途

シーケンス番号フィールド

シーケンス番号フィールドは、32ビットの固定長フィールドです。このフィールドには、パ

ケットを送信する際に1ずつ増加するシーケンス番号が入ります。このシーケンス番号は、

SAが生成された際に0に初期化されるため、SA生成後の最初のパケットに含まれるシーケ

ンス番号は 1となります。


認証データフィールド

認証データフィールドには、このパケットに対する完全性チェック値（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ヘッダ

0 中継点オプションヘッダ ─

60 終点オプションヘッダ ─

43 経路制御ヘッダ ─

44 フラグメントヘッダ ─

51 認証ヘッダ（AH）

50 暗号ペイロード（ESP）

108 IPCompヘッダ


6、17などトランスポート層ヘッダ（TCP、UDPなど）

※ 終点オプションヘッダは、通常はIPv6拡張ヘッダの最後（トランスポート層ヘッダの前）に現れますが、経路制御ヘッダの前に現れる場合もあります。

ヘッダ番号 IPv6におけるヘッダ順序 IPv4におけるヘッダ順序

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-MD5-

96による ICVの計算法を示します。HMAC-MD5-96では、128ビットの共有秘密鍵を使用しま

す。HMAC-MD5-96は実装上必須の認証アルゴリズムであるため、すべての実装で利用可能とな

ります。HMAC-MD5-96の使用法は、RFC 2403 [2] に記述されています。

ipad : 0x36363636…36（64バイトの定数）opad : 0x5c5c5c5c…5c（64バイトの定数）

ハッシュ値を計算

直前に付加

opadとの XORipadとの XOR

共有秘密鍵 K1（64バイト）

データ

直前に付加

共有秘密鍵 K2（64バイト）

共有秘密鍵 K（128ビット）

IPヘッダ

AHヘッダ

ハッシュ値 H1（128ビット）

MD5ハッシュ値を計算

ICV（96ビット）

ハッシュ値 H2（128ビット）

MD5

図 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] に記述


されています。

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は実装上必

須の認証アルゴリズムではないため、すべての実装で利用可能であるとは限りません。HMAC-

RIPEMD-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ヘッダ

共有秘密鍵 K

AHヘッダ

ICV（128ビット）

MD5

図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やRIPEMD-

160を使用した場合は160ビットの認証データを出力するため、そのまま利用してもヘッダ

全体は 64ビット境界に収まるのですが、160ビットの認証データをそのまま利用するより

も、ある程度データを削った方が逆に攻撃者に与える情報が少なくなり、安全になる（そし

てヘッダの量も少なくて済む）という理由もあって、MD5と同様に96ビットまで削るよう

にしています。


れません。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ヘッダ

IPv4ヘッダ


認証の範囲

プロトコル=AH

次ヘッダ=TCP

AHヘッダ




認証の範囲

次ヘッダ=AH

IPv6ヘッダ

次ヘッダ　　　=終点オプション

図 6-4　トランスポートモード AHの認証の範囲（網掛部は配送中不変）


メントパケットの長さに調整されますが、終点でのAH処理の前にフラグメントが再構成される

ため、このパケット全体長フィールドの値は元の値に戻ります。このため、パケット全体長

フィールドも ICVの計算に含めます。また、終点 IPアドレスは、経路制御オプションが使用さ

れている場合には、配送中に変更されますが、終点ノードに到着した時点では、終点の IPアド

レスとなることが予測できるため、ICVの計算時には終点のIPアドレスを入れて計算します。DS

フィールドおよびECNフィールド（サービスタイプ（TOS）フィールド）は、ルータによって変更

される可能性があるため、ICVの計算には含めません。また、MFフラグ（フラグメント継続フ

ラグ）やフラグメントオフセットは、終点での AH処理の際には必ず 0となるため、ICVの計算

には含めません。DFフラグ（フラグメント禁止フラグ）、TTL、ヘッダチェックサムの各フィー

IPv4ヘッダ


認証の範囲

プロトコル=AH

AHヘッダ

次ヘッダ=IPv4

AHヘッダ






認証の範囲

次ヘッダ=AH

IPv6ヘッダ

次ヘッダ=IPv6

図 6-5　トンネルモードAHの認証の範囲（網掛部は配送中不変）

ヘッダチェックサム

フラグメントオフセットフラグ

パケット全体長

プロトコル番号TTL

バージョンヘッダ長 DS ECN

識別子

0 4 8 1614 19 31

始点 IPアドレス

終点 IPアドレス

図 6-6　ICVの計算に含まれる IPv4基本ヘッダのフィールド（網掛部）


ルドは、配送途中で変更される可能性があり、終点での値を予測することができないため、ICV

の計算には含めません。

　また、IPv4のオプションに関しては、配送中に変更されるものと変更されないものがありま

す。しかし、それを見分けるためのフラグなどは存在しないため、ICVの計算に含まれるオプ

ションは、あらかじめ AHの仕様で表 6-3のように決められています。

　ICVの計算に含まれる IPv6ヘッダのフィールドは図 6-7のようになります。バージョン、次

ヘッダ、始点IPアドレスの各フィールドは、配送中も不変であるため、ICVの計算に含めます。

また、ペイロード長は、配送中にフラグメントが生じた場合は、そのフラグメントパケットの長

さに変更されますが、終点でのAH処理の前にフラグメントが再構成されるため、このペイロー

ド長フィールドの値は元の値に戻ります。このため、ペイロード長フィールドもICVの計算に含

めます。また、終点 IPアドレスは、経路制御オプションが使用されている場合には、配送中に

変更されますが、終点ノードに到着した時点では、終点の IPアドレスとなることが予測できる

ため、ICVの計算時には終点のIPアドレスを入れて計算します。DSフィールドおよびECNフィー

ルド（トラフィッククラスフィールド）、フローラベルフィールド、中継限界数フィールドは、途

中のルータによって変更される可能性があり、終点での値を予測することができないため、ICV

の計算には含めません。

表 6-3　ICVの計算時における IPv4オプションの扱い

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 配送中不変含まれる

オプション番号 IPv4オプション値の変化 ICVの計算


フローラベル

次ヘッダ番号中継限界数

バージョン DS ECN

ペイロード長

0 4 10 12 16 24 31

始点 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を認証デー

タフィールドに入れます。


次ヘッダ番号ペイロード長予約

0 8 16 31

パディング（必要に応じて存在）



認証データ（可変長）

図 6-8　ICVの計算に含まれる認証ヘッダのフィールド（網掛部）


　AHを適用したパケットの大きさがMTU値を超えている場合には、AH処理の後にフラグメン

ト分割処理を行います。

表 6-4　ICVの計算時における IPv6拡張ヘッダの扱い

0 中継点オプションヘッダ配送中に変更される可能性配送中変更可能ビットにし

があるたがう

43 経路制御ヘッダ（タイプ 0）配送中に変更されるが予測含まれる

可能

44 フラグメントヘッダ配送中に変更される可能性 AH処理時には存在しないがある

50 暗号ペイロード配送中不変含まれる

51 認証ヘッダ配送中不変含まれる（ICV以外）

60 終点オプションヘッダ配送中に変更される可能性配送中変更可能ビットにし

があるたがう

108 IPCompヘッダ配送中不変含まれる

ヘッダ番号 IPv6拡張ヘッダ値の変化 ICVの計算


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とします。また、受信されたパケットのシーケンス番号がリプレイ防御


ウィンドウの右端より大きい場合には、リプレイ防御ウィンドウを右にスライドして内容を更新

します。

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によって


保護することが可能です。実際に、経路制御ヘッダなどの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：Encapsulating Security Payload）は、IPパケットの機密性の確保と完全

性の確保、および送信元の認証を行うセキュリティプロトコルです。この章では、ESPの機能と

処理の詳細について説明します。

7.1　ESPの機能　暗号ペイロード（ESP） [1] は、データの機密性とトラフィック情報の機密性を暗号化によって

確保し、オプションでIPパケットのコネクションレス完全性の確保と送信元の認証、そして、リ

プレイ攻撃からの防御の機能を提供します。

データの機密性確保

　ESPのメインとなる機能がデータの暗号化機能です。トンネルモードの場合は IPパケット全

体を暗号化し、トランスポートモードの場合は IPペイロード部を暗号化することにより、デー

タの機密性を確保します。

コネクションレス完全性の確保

　ESPで認証機能を有効にした場合に含まれる完全性チェック値を検証することで、IPペイロー

ド部（トンネルモードの場合はカプセル化された IPパケット）の完全性を確保することが可能と

なります。ただし、AHと異なり、パケット配送用のIPヘッダなどの完全性を確保することはで

きません。ESPでは、この機能はオプションとして用意されています。

● ESPの機能● ESPプロトコルフォーマット●暗号化アルゴリズム●認証アルゴリズム● 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




ペイロードデータ（可変長）

パディング（0～ 255バイト）

ESPヘッダ

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値の範囲と用途

0 ローカルでの利用

1～255 予約

256～手動および自動設定用

SPI値用途


の値も通常は使用することができません。

シーケンス番号フィールド

シーケンス番号フィールドは、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の位置








108 IPCompヘッダ






7.3　暗号化アルゴリズム　ESPでは、暗号化アルゴリズムとしてDES -CBCとNULL暗号化アルゴリズムの実装が必須と

なっています。この他にも多くの暗号化アルゴリズムを使用することが可能です。暗号化アルゴ

リズムの詳細については、「2.2 共通鍵暗号」を参考にしてください。

7.3.1　DES-CBC　ESPでは、暗号化アルゴリズムとしてDES -CBCを実装することが必須とされています。図7-

2に、DES -CBCを使用した場合の ESPのパケットフォーマットを示します。DES -CBCで使用

する64ビットのIVは、送信側が任意に生成し、ESPのペイロードデータフィールドにて明示的

に運ばれます。また、DES -CBCのブロックサイズは 64ビットであるため、暗号化対象となる

データは64ビットの整数倍である必要があります。このため、暗号化対象となるデータ（トラン

スポートモードの場合は上位層プロトコルデータ、トンネルモードの場合はIPパケット全体）と


0 8 16 24 31




ペイロードデータ（可変長）

パディング（0～ 255バイト）

64ビットの整数倍

初期ベクトル（IV）

図 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ビットであるた


め、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として使用します。

最終ブロック

IV

ESPヘッダ

暗号化データ

最終ブロック

IV

ESPヘッダ

暗号化データ

最終ブロック

IV

ESPヘッダ

暗号化データ

乱数

2パケットめ1パケットめ 3パケットめ

図 7-3　ESPにおけるCBCモード暗号の IVの生成法

パケットの暗号化

　トランスポートモードを使用する場合は、IPペイロード部を暗号化します。また、トンネル

モードを使用する場合は、IPパケット全体を暗号化します。ただし、暗号化対象となる平文デー

タに、必要な長さのパディングとパディング長フィールド、次ヘッダ番号フィールドを追加して

から暗号化します。暗号化はSAで指定された暗号化アルゴリズムと共有秘密鍵を使用して行い

ます。

シーケンス番号の生成

　該当するSAのシーケンス番号カウンタを1つ増加し、増加した値をESPヘッダのシーケンス

番号フィールドに入れます。

　シーケンス番号カウンタを増加させた際にカウンタが一巡した場合は、パケットを送信する前

にIKEによって新しいSAを生成する必要があります。ただし、手動鍵管理の場合のように、リ

プレイ防御機能が無効である場合は、カウンタが一巡した場合でも引き続きそのSAを使用する

ことが可能です。


完全性チェック値（ICV）の計算（オプション）　認証機能を有効にしている場合には、該当するSAで指定された認証アルゴリズムと共有秘密

鍵を使用して、ESPパケットに対する完全性チェック値（ICV）を計算します。しかし、認証デー

タフィールドに含まれる ICVはまだ計算されていないため、ESPパケットの認証データフィー

ルドを除いた残りの部分に対して ICVが計算されます（図 7-4）。


0 8 16 24 31



認証データ

ペイロードデータ

パディング

図 7-4　ICVの計算に含まれる ESPフィールド（網掛部）

　トランスポートモード ESPにおける認証の範囲を図 7-5に示します。また、トンネルモード

ESPにおける認証の範囲を図 7-6に示します。

　トランスポートモードとトンネルモードのどちらの場合でも、ESPパケットのESPヘッダと

暗号化されたペイロードデータフィールドおよびESPトレーラが、ESPにおける認証の範囲と

なります。AHとは異なり、パケット配送用のIPヘッダなどのESPヘッダより前に位置するヘッ

ダは、ESPの認証の範囲には含まれません。



　ESPを適用したパケットの大きさがMTU値を超えている場合には、ESP処理の後にフラグメ

ント分割処理を行います。

7.5.2　受信側における処理（ESP入力処理）　ESPが適用されたパケットを受信した場合には、次の順序で ESP入力処理を行います。

ESPヘッダ

ESPヘッダ


ESPトレーラ

認証の範囲

プロトコル=ESP

IPv4ヘッダ

次ヘッダ=TCP



ESP認証データ

次ヘッダ=終点オプション

ESP認証データ

認証の範囲

次ヘッダ=ESP

IPv6ヘッダ


ESPトレーラ

図 7-5　トランスポートモード ESPの認証の範囲（網掛部は暗号化）

ESPヘッダ

ESPヘッダ

データIPv4ヘッダ

TCPヘッダ

ESPトレーラ

認証の範囲

プロトコル=ESP

次ヘッダ=IPv4



ESP認証データ



次ヘッダ=IPv6

ESP認証データ

認証の範囲

次ヘッダ=ESP

IPv6ヘッダ


ESPトレーラ

図 7-6　トンネルモード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とします。また、受信されたパケットのシー

ケンス番号がリプレイ防御ウィンドウの右端より大きい場合には、リプレイ防御ウィンドウを右

にスライドして内容を更新します。


パケットの復号化

　該当する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

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によってデータが暗号化される前に圧縮を行う必要があります。これを実現する

● IPレベルでの圧縮の必要性● IPCompアソシエーション（IPCA）● IPCompプロトコルフォーマット●拡大防止ポリシー●圧縮アルゴリズム● IPComp処理の流れ

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（AH、ESP） IPComp

方向単方向単方向

識別子 SPI（4バイト） CPI（2バイト）

IPsec SA IPCA

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は、プライベートでの利用のために用意されています。


表 8-2　CPI値の範囲と用途

0～ 63 定義済みの圧縮アルゴリズム用（0は予約）

64～ 255 予約

256～ 61,439 自動設定用

61,440～ 65,535 プライベートでの利用

CPI値用途

8.3.2　IPCompヘッダが挿入される位置　表8-3にIPCompヘッダが挿入される位置を示します。IPCompヘッダは、IPv4では、IPv4ヘッ

ダの後、トランスポート層ヘッダの前に挿入されます。IPv6では、IPCompヘッダは終点間ペイ

ロード（IPパケットの終点でのみ使用され、途中のルータなどでは使用されない）であるため、経

路制御ヘッダなどの配送途中で使用される拡張ヘッダの後に挿入されます。

表 8-3　IPv6および IPv4における IPCompヘッダの位置








108 IPCompヘッダ





8.4　拡大防止ポリシー ● 143

8.4　拡大防止ポリシー　IPCompを使用してデータを圧縮した場合でも4バイトの IPCompヘッダが新たに追加される

ため、データの圧縮効率が悪い場合には、オリジナルの IPパケットよりも IPComp適用後の IP

パケットの方が逆に大きくなってしまう可能性があります。そこでIPCompでは、IPComp適用

後の IPパケットがオリジナルの IPパケットよりも大きくなってしまった場合には、IPCompを

適用する前のオリジナルの IPパケットを使用します（図 8-2）。

短い方を採用

IPComp処理長さを比較

IPComp適用前IPパケット

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）。


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社の前身）によって開発された圧縮

IPCompを適用しないIPペイロード（90バイト未満）

IPヘッダ

IPCompを適用IPペイロード（90バイト以上）

IPヘッダ

図 8-3　圧縮対象データの長さによる IPComp適用の判断

ある IPCompアソシエーションにおける IPパケットの流れ

圧縮処理をスキップ

圧縮済？圧縮済？圧縮済圧縮済？

圧縮しない圧縮しない圧縮失敗圧縮しない

圧縮再開

図 8-4　圧縮失敗時の処理

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ヘッダ


圧縮対象範囲




圧縮対象範囲

IPv6ヘッダ

図 8-5　IPv4および IPv6における 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ヘッダ

IPCompヘッダ


IPv4ヘッダ

IPv6ヘッダ


圧縮済みデータ

プロトコル=IPComp

次ヘッダ=TCP


次ヘッダ　　　 =終点オプション


次ヘッダ=IPComp


図 8-6　IPv4および IPv6における IPCompヘッダの挿入位置（トランスポートモード）

8.6　IPComp処理の流れ ● 147

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.

IPv4ヘッダ



プロトコル=IPComp

IPCompヘッダ

IPCompヘッダ

次ヘッダ=IPv4







次ヘッダ=IPComp

IPv6ヘッダ

次ヘッダ=IPv6

図 8-7　IPv4および IPv6における IPCompヘッダの挿入位置（トンネルモード）

　　149

9章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 Manage-

ment Protocol）が、1996年にアリゾナ大学のHilarie OrmanによってOakleyが提案されました。

●自動鍵管理プロトコルの必要性●鍵管理プロトコルの決定経緯● IPsecにおける鍵管理プロトコルの構成● IKEの持つ機能● ISAKMPメッセージフォーマット● IKEの動作● IKEによる折衝パラメータ

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月にPro-

posed Standard（標準提案）の RFC 2409 [1] として公開されました。同時に、ISAKMPは、Pro-

posed Standard（標準提案）のRFC 2408 [2] として、Oakleyは、Informational（情報提供）のRFC

2412 [3] として公開されました（図 9-1）。

Photuris RFC 2522RFC 2523

RFC 2408

RFC 2412

RFC 2409

SKIP

ISAKMP

IKE

1994 1995 1996 1997 1998

OakleyOakleyOakley

ISAKMP/OakleyISAKMP/OakleyISAKMP/Oakley

図 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 鍵管理プロトコルSA管理および鍵管理フレームワーク

TLS

AH

ESP

IPComp

TLSDOI

IPsecDOI

KINK

IKE

ISAKMP

図 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] の機能の一部を取り入れ

て作られています。


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

折衝対象 SA ISAKMP SA IPsec SA（AH、ESP）、IPCA

方向双方向単方向

折衝 SA本数 1本セキュリティプロトコルごとに 2本ずつ

SAの識別子始動者クッキーと応答者クッキーの組 SPI値またはCPI値を、フェーズ 2折衝時に始動者と応答者がそれぞれ指定

保護対象 IKEメッセージ IPによる通信

IKEのフェーズフェーズ1 フェーズ2

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回（暗号


化 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プロポーザルの例

1 IPSEC_ESP ESP_AES トンネルモード、鍵長 128ビット、 HMAC-SHAによる認証

ESP_AES トンネルモード、鍵長 128ビット、 HMAC-MD5による認証

ESP_3DES トンネルモード、

HMAC-SHAによる認証


HMAC-MD5による認証

IPCOMP IPCOMP_LZS トンネルモード

IPCOMP_DEFLATE トンネルモード

2 IPSEC_ESP ESP_AES トンネルモード、鍵長 128ビット、 HMAC-SHAによる認証

ESP_AES トンネルモード、鍵長 128ビット、 HMAC-MD5による認証


HMAC-SHAによる認証


HMAC-MD5による認証付

プロポーザル番号プロトコル ID トランスフォーム ID SA属性

9.4.3　共有秘密鍵の管理　IKEの重要な機能の1つが共有秘密鍵の管理です。IKEでは、定期的に共有秘密鍵を変更しま

す。鍵の変更は Diffie-Hellman鍵共有アルゴリズムによって行われます。

PFS（Perfect Forward Secrecy）　PFSとは、ある鍵が解読されたとしても、その解読された鍵情報からは、その後に生成された

別の鍵を解読することができない性質のことを言います（図9-3）。PFSを保証するためには、あ

る鍵の生成に使用された値を別の鍵の生成に使用してはいけません。PFSを有効にするとより安

全になりますが、鍵の生成にかかる処理が多くなります。IKEでは、PFSを有効にするかどうか

を選択することができるようになっています。


鍵 Aを解読

鍵 Bで暗号化されたパケット（PFSが有効であれば安全）

解読した鍵 Aの情報を使用して他の鍵の解読を試みる

鍵 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が入ります。


　† トランザクション交換は ISAKMP-Config拡張仕様 [7] で定義されています。

フラグ次ペイロード番号交換タイプ

0 8 1612 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ペイロードのメッセージ認証の


みを行って送信する必要がある場合は、この認証のみビットを 1とします。

　メッセージ IDフィールドは、フェーズ2の折衝を識別するための値が入ります。このフィー

ルドには、フェーズ 1の折衝中には 0が、フェーズ 2の折衝中にはフェーズ 2の始動者によって

生成された値が入ります。

　全メッセージ長フィールドには、ISAKMPヘッダとすべての ISAKMPペイロードを含むメッ

セージ全体の長さがバイト単位で入ります。

9.5.2　ISAKMPペイロードフォーマット　ここでは、ISAKMPヘッダに続く、ISAKMPペイロードのフォーマットについてそれぞれ説明

します。

0 1 2 3 4 5 6 7

E C A 予約（全て 0）

図 9-6　フラグフィールドのフォーマット

表 9-4　ISAKMP交換タイプ

0 予約

1 ベース交換

2 ID保護交換（メインモード）

3 認証のみ交換

4 アグレッシブ交換（アグレッシブモード）

5 情報提供交換

6 トランザクション交換

7～ 31 予約（未割り当て）

32～ 239 DOI特有の交換用

（32 クイックモード）

（33 新グループモード）

240～ 255 プライベート用

値 ISAKMP交換タイプ


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に、

プロポーザルペイロード（ESP用）

プロポーザルペイロード（IPComp用）

SAペイロード

ISAKMPヘッダ

SAペイロードヘッダ

プロポーザルペイロードヘッダ（プロポーザル番号 1：ESP）

トランスフォームペイロード（トランスフォーム番号 1）


プロポーザルペイロードヘッダ（プロポーザル番号 1：IPComp）



第 1希望のESP SAパラメータ

第 2希望のESP SAパラメータ

第 1希望のIPCAパラメータ

第 2希望のIPCAパラメータ

図 9-7　SAペイロードの構成


IPsec DOIで定義されている SAペイロードヘッダのフォーマットを示します。

　次ペイロード番号フィールドには、このSAペイロードに続くISAKMPペイロードのペイロー

ド番号が入ります。ただし、次ペイロード番号フィールドには、SAペイロードヘッダの後に続

くプロポーザルペイロードやトランスフォームペイロードのペイロード番号ではなく、SAペイ

ロード全体（プロポーザルペイロードおよびトランスフォームペイロードを含む）の後に続く

ISAKMPペイロード（例えば乱数ペイロードなど）の番号が入ります。SAペイロードに続くペイ

ロードが存在しない場合には 0が入ります。

　ペイロード長フィールドには、このSAペイロードヘッダと、その後に続くプロポーザルペイ

ロードヘッダ、トランスフォームペイロードを合わせたSAペイロード全体の長さがバイト単位

で入ります。

　DOIフィールドには、折衝する対象となるセキュリティプロトコルのDOI値が入ります。IPsec

SAを折衝する場合は、IPsec DOIを示す 1が入ります。

予約インテグリティカテゴリ長

予約インテグリティ長

予約機密性カテゴリ長

0 8 16 24 31

インテグリティレベル（可変長）

機密性カテゴリビットマップ（可変長）

予約機密性長

ペイロード長予約次ペイロード番号

機密性レベル（可変長）

ラベル付ドメイン識別子

シチュエーション

DOI（IPsec DOI）

インテグリティカテゴリビットマップ（可変長）

図 9-8　SAペイロードヘッダのフォーマット（IPsec DOI）


　シチュエーションフィールドには、必要なセキュリティサービスを決定するために使用される

値が入ります。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


シチュエーション（SIT_IDENTITY_ONLY）

DOI（IPsec DOI）

図 9-9　SIT_IDENTITY_ONLYの場合の SAペイロードヘッダ

　SAペイロードヘッダの後にはプロポーザルペイロードが続きます。プロポーザルペイロード

は、使用するセキュリティプロトコルの種類やSPI、そして、そのセキュリティプロトコルで使

用するアルゴリズム（トランスフォーム）を記述するためのペイロードです。ただし、実際のアル

ゴリズム（トランスフォーム）は、プロポーザルペイロード内のトランスフォームペイロードで記

述され、プロポーザルペイロードヘッダにはセキュリティプロトコルの種類とSPI、そしてその

プロポーザルの優先順位が記述されます。つまり、1つのプロポーザルペイロードには1つのセ

キュリティプロトコルの情報が記述されるため、異なるセキュリティプロトコルを同時に使用す

る場合（例えばESPとIPCompを同時に使用する場合）や、優先順位を付けて異なるセキュリティ

プロトコルを提案したい場合（例えばESPを第 1希望にしてAHを第 2希望とする場合）には、1

つの SAペイロード内に複数のプロポーザルペイロードが存在することになります。

　図 9-10にプロポーザルペイロードヘッダのフォーマットを示します。


0 8 16 24 31


トランスフォーム数SPI長プロトコルIDプロポーザル番号

セキュリティパラメータインデックス（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が入る場合も

あります）。

　トランスフォーム数フィールドには、このプロポーザルペイロードに含まれるトランスフォー

ムペイロードの数が入ります。トランスフォームペイロードにはプロポーザルペイロードヘッダ


で指定したセキュリティプロトコルで使用するアルゴリズム（トランスフォーム）や、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 31

ペイロード長

予約

予約次ペイロード番号

トランスフォーム IDトランスフォーム番号

セキュリティアソシエーション属性（可変長）

図 9-11　トランスフォームペイロードのフォーマット


　ペイロード長フィールドには、トランスフォームペイロード全体（次ペイロード番号フィール

ドからセキュリティアソシエーション属性フィールドまで）の長さがバイト単位で入ります。

　トランスフォーム番号フィールドには、同一プロポーザルペイロード内におけるこのトランス

フォームペイロードの内容の優先順位が記述されます。最も優先順位が高いトランスフォームペ

イロードのトランスフォーム番号は 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 16 24 31

属性値属性タイプAF

図 9-12　SA属性フォーマット（属性値が固定長の場合：AF=1）

0 8 16 24 31

属性長

属性値（可変長）

属性タイプAF

図 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種類の提案を行ってい


表 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 プライベート用 ―

属性タイプ値属性タイプ長さ

表 9-7　属性タイプ（IPsec SA）


0 予約－

1 SA有効期間タイプ固定長

2 SA有効期間可変長

3 Oakleyグループ固定長

4 カプセル化モード固定長

5 認証アルゴリズム固定長

6 鍵長固定長

7 鍵ラウンド固定長

8 圧縮辞書サイズ固定長


ます。この場合は、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による暗号化が折衝されます。

鍵交換ペイロード

　鍵交換ペイロードは、Diffie-Hellman鍵共有アルゴリズムで使用する公開値（gxiおよびgxr）を運

ぶために使用されます。鍵交換ペイロードのフォーマットを図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が入ります。

表9-7　属性タイプ（IPsec SA）（つづき）


9 圧縮プライベートアルゴリズム可変長

10 ECNトンネル固定長

11～ 32,000 予約（未割り当て） ―

32,001～ 32,767 プライベート用 ―


43,200（秒）

43,200（秒）

シチュエーション =SIT_IDENTITY_ONLY

DOI=IPsec DOI

メッセージ ID=0

全メッセージ長 =120バイト

有効期間0 属性長 =4バイト

有効期間タイプ1 秒

Oakleyグループ1 1,024ビットMODPグループ

相手認証方式1 RSA署名

ハッシュアルゴリズム1 SHA

暗号化アルゴリズム1

0

1

1

1

1

1

3DES-CBC

有効期間タイプ秒

Oakleyグループ 1,536ビットMODPグループ

相手認証方式 RSA署名

ハッシュアルゴリズム SHA

暗号化アルゴリズム AES-CBC

KEY_IKEトランスフォーム #2 予約

予約次ペイロード =0 トランスフォームペイロード長 =36バイト

KEY_IKEトランスフォーム #1 予約

SAペイロード長 =92バイト


PROTO_ISAKMPプロポーザル #1 トランスフォーム数 =2SPI長 =0

予約次ペイロード =0


1 0 0 00 予約次ペイロード =1 メインモード

プロポーザルペイロード長 =80バイト

トランスフォームペイロード 2

トランスフォームペイロード 1

プロポーザルペイロードヘッダ


ISAKMPヘッダ

有効期間属性長 =4バイト

応答者クッキー =0

始動者クッキー≠ 0

0 8 12 16 24 31

図 9-14　ISAKMP SAプロポーザルの例（メインモード）


シチュエーション =SIT_IDENTITY_ONLY

DOI=IPsec DOI

メッセージ ID≠ 0

全メッセージ長 =228バイト

SPI

予約

SAペイロード長 =200バイト

PROTO_IPSEC_ESPプロポーザル #1 トランスフォーム数 =2SPI長 =4バイト

トランスフォーム数 =1SPI長 =4バイト



1 0 1 00 予約次ペイロード =1 クイックモード

プロポーザルペイロード長 =76バイト



ISAKMPヘッダ

SPI

PROTO_IPSEC_ESPプロポーザル #2 トランスフォーム数 =1SPI長 =4バイト

予約次ペイロード =0 プロポーザルペイロード長 =44バイト


ESP SA属性

ESP_AESトランスフォーム #1


トランスフォームペイロード

予約

ESP SA属性

ESP_3DESトランスフォーム #2



予約

IPComp IPCA属性

IPCOMP_DEFLATEトランスフォーム #1



CPI

PROTO_IPCOMPプロポーザル #1

予約次ペイロード =2 プロポーザルペイロード長 =36バイト

予約

ESP SA属性

ESP_3DESトランスフォーム #1




応答者クッキー≠ 0

始動者クッキー≠ 0

0 8 12 16 24 31

図 9-15　IPsec SAプロポーザルの例（クイックモード）


表 9-8　IDタイプフィールドの値（IPsec DOI）

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

値 IDタイプ長さ説明

0 8 16 24 31


鍵交換データ（可変長）

図 9-16　鍵交換ペイロードのフォーマット

0 8 16 24 31


ポートプロトコルIDIDタイプ

IDデータ（可変長）

図 9-17　IDペイロードのフォーマット（IPsec DOI）


証明書ペイロード

　証明書ペイロードは、認証のために使用される公開鍵証明書を運ぶために使用されます。証明

書ペイロードのフォーマットを図 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）が入ります。ただし、特定の認証局を必要としない場合は、

このフィールドを含めてはいけません。

表9-8　IDタイプフィールドの値（IPsec DOI）（つづき）

11 ID_KEY_ID 可変長バイトストリーム

12～ 248 予約（未割り当て） ─ ─

249～ 255 プライベート用 ─ ─

値 IDタイプ長さ説明


表 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属性証明書


値証明書の種類

†　 Public Key Cryptography Standards #7 - Cryptographic Message Syntax Standard：RSA Security社が規定した証明書配布形式

††　Experimental（実験的仕様）としてRFC 2692およびRFC 2693に記述されています。

0 8 16 24 31


CA（可変長）

証明書タイプ

図 9-19　証明書要求ペイロードのフォーマット


ハッシュペイロード

　ハッシュペイロードは、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に

示します。


0 8 16 24 31


乱数データ（可変長）

図 9-22　乱数ペイロードのフォーマット

通知ペイロード

　通知ペイロードは、IKEの処理中にエラーが生じた場合のエラー内容や、自ノードの状態を相

手に通知するために使用されます。この通知ペイロードは、「9.6.3 その他のメッセージ交換」で

説明する ISAKMP情報提供交換で使用されます。通知ペイロードのフォーマットを図 9-23に示

します。

0 8 16 24 31


通知メッセージタイプSPI長プロトコル ID

通知データ（可変長）

DOI


図 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

は始動者クッキーと応答者クッキーの組になります）。

　通知メッセージタイプフィールドには、使用するメッセージの種類に応じた値が入ります。通


知メッセージは、エラータイプとステータスタイプの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 証明書利用不可

値通知メッセージ意味


表 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、

IPComp）の場合には、それぞれ PROTO_IPSEC_AH（2）、PROTO_IPSEC_ESP（3）、

PROTO_IPCOMP（4）が入ります。また、SPI長フィールドには、SPIフィールドの長さがバイト

単位で入り、ISAKMP SAの場合は16（バイト）、IPsec SAの場合は4（バイト）となります（ISAKMP

SAの場合は、SPIは始動者クッキーと応答者クッキーの組になります）。


0 8 16 24 31


SPI数SPI長プロトコル ID

DOI


・・・


図 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バイトが入ります。


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回 4回 2回鍵暗号処理（署名処理 1回（暗号化処理 2回（暗号化処理 1回検証処理 1回）復号化処理 2回）復号化処理 1回）

事前共有デジタル署名認証公開鍵暗号化認証改良型公開鍵秘密鍵認証暗号化認証


鍵およびハッシュの生成法

　フェーズ 1では、次のように鍵を計算します。

SKEYID_d = prf (SKEYID, gxy | CKY-I | CKY-R | 0)

SKEYID_a = prf (SKEYID, SKEYID_d | gxy | CKY-I | CKY-R | 1)

SKEYID_e = prf (SKEYID, SKEYID_a | gxy | 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）を適用するこ

とにより計算されます。gxy は、Diffie-Hellman鍵共有アルゴリズムによる鍵交換で生成された共

有値を示します。CKY-Iは、始動者クッキー（8バイト）を、CKY-Rは応答者クッキー（8バイト）

を示します。最後の0、1、2という値は1バイトの数値で表されます。擬似乱数発生関数の鍵と

して使用される SKEYIDは、認証方式の種類に応じてそれぞれ次のように計算されます。

事前共有秘密鍵認証方式：SKEYID = prf (事前共有秘密鍵 , Ni_b | Nr_b)

デジタル署名認証方式：SKEYID = prf (Ni_b | Nr_b, gxy)

公開鍵暗号化認証方式：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)

　ここで、gxiおよびgxrは、それぞれ鍵交換ペイロードで運ばれる始動者または応答者のDiffie-

Hellman公開値を示します。また、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

を鍵として計算したハッシュ値を含むハッシュペイロードを付加し、SKEYID_e によって

ISAKMPペイロード全体を暗号化します。これにより始動者と応答者のIDを保護することが可


能となります。5つめと6つめのメッセージでは、SKEYID_eによって ISAKMPペイロード全体

を暗号化し、ISAKMPヘッダのフラグフィールドの暗号化ビットを 1とします。

　事前共有秘密鍵は、通常、通信相手ごとに異なるものを使用します。しかし、メインモードで

は、相手を識別するIDは最後に交換されるため、その前に相手を識別する情報はIPアドレスし

かありません。つまり、この方式では、事前共有秘密鍵と通信相手とを結びつけるための情報と

してIPアドレスが使用されます。このため、この方式では、リモートアクセスのようにIPアド

レスが変わるような環境では利用できないので注意が必要です（リモートアクセス環境で事前共

有秘密鍵を使用する場合には、メインモードではなくアグレッシブモードを使用します）。

デジタル署名認証方式を使用した場合のメインモード

　図 9-27に、デジタル署名認証方式を使用した場合のメインモードにおけるメッセージの流れ

と、使用される ISAKMPペイロードを示します。

　デジタル署名認証方式では、事前共有秘密鍵認証方式で交換されるハッシュペイロードの代わ

りに署名ペイロードが使用されます。この方式では、3つめと4つめのメッセージの鍵交換ペイ

SAパラメータの提案ISAKMPヘッダSA

始動者の鍵情報ISAKMPヘッダ鍵交換

乱数（始動者）

始動者の ID始動者の認証情報ISAKMPヘッダ

ID（始動者）ハッシュ（始動者）

応答者の ID応答者の認証情報 ISAKMPヘッダ

ID（応答者）ハッシュ（応答者）

始動者

SAパラメータの選択 ISAKMPヘッダ

応答者の鍵情報 ISAKMPヘッダ鍵交換

乱数（応答者）

SA

応答者

①

②

④

⑥

③

⑤

図 9-26　事前共有秘密鍵認証方式を使用したメインモード（網掛部は暗号化）

9.6　IKEの動作 ● 183


始動者の鍵情報ISAKMPヘッダ鍵交換


始動者の ID始動者の認証情報ISAKMPヘッダ

ID（始動者）［証明書（始動者）］署名（始動者）

応答者の ID応答者の認証情報 ISAKMPヘッダ

ID（応答者）［証明書（応答者）］署名（応答者）

始動者

SAパラメータの選択 ISAKMPヘッダ

応答者の鍵情報 ISAKMPヘッダ鍵交換


SA

応答者

①

②

④

⑥

③

⑤

［］で示したペイロードはオプション

図 9-27　デジタル署名認証方式を使用したメインモード（網掛部は暗号化）

ロードで交換される始動者および応答者のDiffie-Hellman公開値（gxiおよびgxr）、乱数ペイロー

ドで交換される始動者および応答者の乱数値（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が折衝さ


れたとしても、署名に使用されるハッシュ値はHMAC-SHA-1を使用して計算します。

　5つめと 6つめのメッセージでは、SKEYID_eによって ISAKMPペイロード全体を暗号化し、

ISAKMPヘッダのフラグフィールドの暗号化ビットを 1とします。

　また、署名を検証するために相手の公開鍵が必要となりますが、この方式では事前に公開鍵を

保持しておく必要はなく、証明書ペイロードによって公開鍵証明書を送信することが可能です。

互いの証明書をすでに持っている場合には、証明書の要求や証明書の送信は必要ありません。

　この方式の利点は、あらかじめ特別な認証用の情報を保持しておかなくても、公開鍵証明書を

検証できる環境さえあれば認証が行える点にあります。ただし、デジタル署名を利用しているた

め、第三者に対してアクセスの否認を行うことはできません。

公開鍵暗号化認証方式を使用した場合のメインモード

　図 9-29に、公開鍵暗号化認証方式を使用した場合のメインモードにおけるメッセージの流れ

と、使用される ISAKMPペイロードを示します。

　事前共有秘密鍵認証方式の場合と異なるのは、IDペイロードを 3つめのメッセージと 4つめ

のメッセージで交換し、IDペイロードと乱数ペイロードを相手の公開鍵で暗号化して送信する

点です。このため、この方式では、始動者および応答者の両者が相手の公開鍵を事前に入手して

おく必要があります。また、IDペイロードと乱数ペイロードをまとめて暗号化せず、ペイロー

ドごとに暗号化します。この時、実際に暗号化するのは各ペイロードのボディ部のみで、

ISAKMP共通ペイロードヘッダ部（ISAKMPペイロードの最初の4バイト）は暗号化しません。こ

の公開鍵による暗号化によって、IDを保護することが可能となります。

　この方式では、3つめと4つめのメッセージの鍵交換ペイロードで交換される始動者および応

答者のDiffie-Hellman公開値（gxiおよび gxr）、乱数ペイロードで交換される始動者および応答者

の乱数値（Ni_bおよびNr_b）、始動者および応答者のクッキー（CKY-IおよびCKY-R）から共有秘

密鍵（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計算します。5つめと6つめのメッセー

ハッシュ（始動者）署名（始動者）

SKEYID

gxi

gxr

CKY-ICKY-RSAi_bIDii_b

HMAC-MD5

私有秘密鍵

RSA

図 9-28　MD5を使用したRSAデジタル署名の生成

9.6　IKEの動作 ● 185


ISAKMPヘッダ鍵交換

［ハッシュ（1）］ID（始動者）乱数（始動者）

始動者の鍵情報始動者の ID

［］で示したペイロードはオプション＊ IDペイロードおよび乱数ペイロードは　相手の公開鍵（　　　）でペイロード　毎に暗号化

ISAKMPヘッダハッシュ（始動者）

ISAKMPヘッダハッシュ（応答者）

始動者

SAパラメータの選択

始動者の認証情報

応答者の認証情報

ISAKMPヘッダ

応答者の鍵情報応答者の ID

SA

応答者

①

②

④

⑥

③

⑤

ISAKMPヘッダ鍵交換

ID（応答者）乱数（応答者）

図 9-29　公開鍵暗号化認証方式を使用したメインモード（網掛部は暗号化）

ジで交換されるハッシュペイロード中のハッシュ値は、SKEYIDを鍵として生成します。また、

SKEYID_eによって、このハッシュペイロードを暗号化します。

　3つめのメッセージにおけるハッシュペイロード（ハッシュ（1））には、始動者が乱数ペイロー

ドとIDペイロードのボディ部を暗号化するために使用した公開鍵証明書のハッシュ値が入りま

す。このハッシュペイロードはオプションです。

　この公開鍵暗号化認証方式では、誰でも入手可能な相手の公開鍵を使用するため、デジタル署

名認証方式と異なり、第三者に対してアクセスを否認することができるという特徴があります。

改良型公開鍵暗号化認証方式を使用した場合のメインモード

　公開鍵暗号化認証方式では、公開鍵暗号による暗号化と復号化の処理を2回ずつ（IDペイロー

ドと乱数ペイロードの暗号化と復号化）行う必要があるため、処理に時間がかかります。このた


め、公開鍵暗号による暗号化と復号化の処理を1回ずつで済ますように改良された改良型公開鍵

暗号化認証方式が提案されました。図 9-30に、改良型公開鍵暗号化認証方式を使用した場合の

メインモードにおけるメッセージの流れと、使用される ISAKMPペイロードを示します。

　この方式では、3つめと4つめのメッセージの乱数ペイロードのみを公開鍵暗号によって暗号

化します。公開鍵暗号を使用するため、始動者はあらかじめ応答者の公開鍵を入手しておく必要

があります。しかし、公開鍵暗号化認証方式と異なり、この方式では始動者の公開鍵証明書を証

明書ペイロードによって応答者に送信することができるため、応答者はあらかじめ始動者の公開

鍵を入手していなくても処理を行うことが可能です。そして、鍵交換ペイロード、IDペイロー

ド、証明書ペイロードは、公開鍵暗号ではなく、共通鍵暗号によって暗号化します（この場合も


ISAKMPヘッダ

鍵交換

［ハッシュ（1）］

ID（始動者）


始動者の鍵情報始動者の ID


＊乱数ペイロードは相手の公開鍵（　　　）でペイロード毎に暗号化　鍵交換ペイロード、IDペイロード、証明書ペイロードは　共通鍵暗号（　　　）によりペイロード毎に暗号化


ISAKMPヘッダハッシュ（応答者）

始動者

SAパラメータの選択



ISAKMPヘッダ

応答者の鍵情報応答者の ID

SA

応答者

①

②

④

⑥

③

⑤

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）を使用して共通鍵暗号により暗号化します。





ジで交換されるハッシュペイロード中のハッシュ値は、SKEYIDを鍵として生成します。また、


SKEYID_eによって、このハッシュペイロードを暗号化します。

　3つめのメッセージのハッシュペイロード（ハッシュ（1））には、始動者が乱数ペイロードのボ

ディ部を暗号化するために使用した公開鍵証明書のハッシュ値が入ります。このハッシュペイ

ロードはオプションです。

　この改良型公開鍵暗号化認証方式では、公開鍵暗号化認証方式と同様に誰でも入手可能な相手

の公開鍵を使用するため、第三者に対してアクセスを否認することができるという特徴がありま

す。また、他の方式と異なり、鍵交換ペイロードが暗号化されるため、より安全に鍵交換を行う

ことが可能となります。

アグレッシブモード

　メインモードでは、6つのメッセージを使用する必要がありますが、アグレッシブモードでは、

3つのメッセージでフェーズ1を完了することが可能です。このアグレッシブモードでは、SAペ

イロード、鍵交換ペイロード、IDペイロードなどを最初のメッセージでまとめて送信します。こ

のため、折衝できるDiffie-Hellman鍵共有アルゴリズムのパラメータが制限されるという問題や、

事前共有秘密鍵認証方式またはデジタル署名認証方式を使用した場合にはID情報が保護されな

いなどの欠点があります。

　アグレッシブモードの間は、ISAKMPヘッダの交換タイプフィールドに、アグレッシブモード

であることを示す 4が入ります。

事前共有秘密鍵認証方式を使用した場合のアグレッシブモード

　図 9-31に、事前共有秘密鍵認証方式を使用した場合のアグレッシブモードにおけるメッセー

ジの流れと、使用される ISAKMPペイロードを示します。

　最初のメッセージを受信した応答者は、Diffie-Hellman公開値（gxr）と応答者クッキー（CKY-R）、

乱数（Nr_b）を生成し、あらかじめ入手済みの事前共有秘密鍵に加えて、始動者および応答者の

Diffie-Hellman公開値（gxiおよびgxr）、始動者および応答者の乱数値（Ni_bおよびNr_b）、始動者

および応答者のクッキー（CKY-I および CKY-R）から共有秘密鍵（SKEYID、SKEYID_d、

SKEYID_a、SKEYID_e）を計算します。そして、このSKEYIDを使用してハッシュを計算し、生

成したDiffie-Hellman公開値（gxr）や乱数（Nr_b）とともに、始動者に送信します（2つめのメッセー

ジ）。これを受信した始動者は、応答者と同じように共有秘密鍵（SKEYID、SKEYID_d、

SKEYID_a、SKEYID_e）を計算します。そして、SKEYIDを使用してハッシュを計算し、応答者

に送信します（3つめのメッセージ）。

　メインモードの場合は、IPアドレスを基に事前共有秘密鍵を検索していましたが、アグレッシ

ブモードでは、最初のメッセージでIDを送信するため、このIDを基に事前共有秘密鍵を検索す

9.6　IKEの動作 ● 189

ることが可能です。つまり、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）を計

SAパラメータの提案始動者の鍵情報始動者の ID

ISAKMPヘッダSA鍵交換

乱数（始動者）ID（始動者）

始動者の認証情報ISAKMPヘッダハッシュ（始動者）

始動者

SAパラメータの選択応答者の鍵情報応答者の ID



乱数（応答者）ID（応答者）

ハッシュ（応答者）

応答者

①

②

③

図 9-31　事前共有秘密鍵認証方式を使用したアグレッシブモード（網掛部は暗号化）


算します。2つめと3つめのメッセージで交換される署名ペイロードには、事前共有秘密鍵認証

方式と同じように計算された始動者および応答者のハッシュ値に対して、折衝されたデジタル署

名方式（RSA署名、DSS署名、ECDSA署名など）によって署名した結果が入ります。

　また、署名を検証するために相手の公開鍵が必要となりますが、この方式では、事前に公開鍵

を保持しておく必要はなく、証明書ペイロードを使用して公開鍵証明書を入手することが可能で

す。互いの証明書をすでに持っている場合には、証明書の要求や証明書の送信は必要ありません。

　この方式では、デジタル署名認証方式を使用したメインモードと比較して、3メッセージで折

衝を完了することができるという利点がありますが、Oakleyグループを折衝することができな

いという欠点や、IDが暗号化されないという欠点があります。

公開鍵暗号化認証方式を使用した場合のアグレッシブモード

　図 9-33に、公開鍵暗号化認証方式を使用した場合のアグレッシブモードにおけるメッセージ

の流れと使用される ISAKMPペイロードを示します。

　公開鍵暗号化認証方式が事前共有秘密鍵認証方式やデジタル署名認証方式と決定的に異なるの

は、IDを暗号化することができるという点にあります。この方式では、最初のメッセージと2つ



乱数（始動者）ID（始動者）

始動者の認証情報ISAKMPヘッダ［証明書（始動者）］署名（始動者）

始動者




乱数（応答者）ID（応答者）

［証明書（応答者）］署名（応答者）

応答者

①

②

③


図 9-32　デジタル署名認証方式を使用したアグレッシブモード

9.6　IKEの動作 ● 191

めのメッセージで交換されるIDペイロードと乱数ペイロードを相手の公開鍵を使用して公開鍵

暗号により暗号化して送信します。このため、この方式では、あらかじめ相手の公開鍵を入手し

ておく必要があります。また、IDペイロードと乱数ペイロードをまとめて暗号化せず、ペイロー

ドごとに暗号化します（実際に暗号化するのは各ペイロードのボディ部のみで、ISAKMP共通ペ

イロードヘッダ部は暗号化しません）。




密鍵（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e）を計算します。2つめのメッセージと3つ

めのメッセージで交換されるハッシュペイロード中のハッシュ値は、SKEYIDを鍵として生成し

ます。

　最初のメッセージのハッシュペイロード（ハッシュ（1））には、始動者がIDペイロードと乱数ペ

イロードのボディ部を暗号化するために使用した公開鍵証明書のハッシュ値が入ります。この

ハッシュペイロードはオプションです。


ISAKMPヘッダSA


鍵交換［ハッシュ（1）］

ID（始動者）乱数（始動者）


［］で示したペイロードはオプション＊ IDペイロードおよび乱数ペイロードは　相手の公開鍵（　　　）でペイロード　毎に暗号化

始動者



ISAKMPヘッダSA

応答者

①

②

③


鍵交換ID（応答者）乱数（応答者）

図 9-33　公開鍵暗号化認証方式を使用したアグレッシブモード（網掛部は暗号化）


改良型公開鍵暗号化認証方式を使用した場合のアグレッシブモード

　メインモードの場合と同様に、アグレッシブモードの場合でも公開鍵暗号化認証方式では、公

開鍵暗号による暗号化と復号化の処理を2回ずつ行う必要があります。改良型公開鍵暗号化認証

方式では、この公開鍵暗号による暗号化と復号化の処理を1回ずつで済ますように改良されてい

ます。図 9-34に、改良型公開鍵暗号化認証方式を使用した場合のアグレッシブモードにおける

メッセージの流れと、使用される ISAKMPペイロードを示します。

　この方式では、1つめと2つめのメッセージの乱数ペイロードのみを公開鍵によって公開鍵暗

号により暗号化します。公開鍵暗号を使用するため、始動者はあらかじめ応答者の公開鍵を入手

しておく必要があります。しかし、この方式では、自身の公開鍵証明書を証明書ペイロードに

よって応答者に送信することができるため、応答者はあらかじめ始動者の公開鍵を入手していな

くても処理を行うことが可能です。また、鍵交換ペイロード、IDペイロード、証明書ペイロー

ドは、公開鍵暗号ではなく、共通鍵暗号によって暗号化します（この場合も暗号化するのは各ペ

イロードのボディ部のみで、最初の 4バイトの ISAKMP共通ペイロードヘッダ部は暗号化しま


ISAKMPヘッダSA

鍵交換

［ハッシュ（1）］

ID（始動者）




＊乱数ペイロードは相手の公開鍵（　　　）でペイロード毎に暗号化　鍵交換ペイロード、IDペイロード、証明書ペイロードは　共通鍵暗号（　　　）によりペイロード毎に暗号化



始動者



ISAKMPヘッダSA

応答者

①

②

③

乱数（応答者）鍵交換

ID（応答者）

［証明書（始動者）］

図 9-34　改良型公開鍵暗号化認証方式を使用したアグレッシブモード（網掛部は暗号化）

9.6　IKEの動作 ● 193

せん）。このペイロードごとの暗号化に使用する共通鍵暗号用の共有秘密鍵は、メインモードの

場合と同様に計算します。





ジで交換されるハッシュペイロード中のハッシュ値は、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)


　また、PFSを有効にしている場合には、鍵交換ペイロードが使用されます。この場合は、IPsec

で使用する鍵（KEYMAT）を次のように計算します。

KEYMAT = prf (SKEYID_d, g(qm)xy | protocol | SPI | Ni_b | Nr_b)

　ここで、SKEYID_dは、IKEのフェーズ 1で生成された鍵素材であり、g(qm)xyは、フェーズ

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)

SAパラメータの提案（始動者の鍵情報）

（始動側クライアント ID）（応答側クライアント ID）

ISAKMPヘッダ

SA

［鍵交換］

ハッシュ（1）

［ID（始動側クライアント）］［ID（応答側クライアント）］



ISAKMPヘッダハッシュ（3）

始動者

SAパラメータの選択（応答者の鍵情報）

（始動側クライアント ID）（応答側クライアント ID）

応答者

①

②

③

ISAKMPヘッダ

SA

［鍵交換］

ハッシュ（2）

［ID（始動側クライアント）］［ID（応答側クライアント）］


図 9-35　クイックモード（網掛部は暗号化）

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)


(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 oakley-quick[E]: [|hash]20:06:10.741183 192.168.1.30.isakmp > 192.168.1.20.isakmp: isakmp: phase 2/others R oakley-quick[E]: [|hash]20:06:10.742020 192.168.1.20.isakmp > 192.168.1.30.isakmp: isakmp: phase 2/others I oakley-quick[E]: [|hash]

[IPsec ESPによる通信]

20:06:10.744992 192.168.1.20 > 192.168.1.30: ESP(spi=1523517648,seq=0x1)20:06:10.745240 192.168.1.30 > 192.168.1.20: ESP(spi=4193667392,seq=0x1)20:06:15.356927 192.168.1.20 > 192.168.1.30: ESP(spi=1523517648,seq=0x2)20:06:15.357404 192.168.1.30 > 192.168.1.20: 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削除ペイロードを使用


します（図9-37）。ISAKMP情報提供交換がISAKMP SAによって保護されている場合はハッシュ

ペイロードが存在し、次のようにハッシュ値を計算します。

　　ハッシュ = prf (SKEYID_a, メッセージ ID | 通知または削除ペイロード)

エラーやステータスの通知または SAの削除ISAKMPヘッダ

通知／削除ハッシュ

始動者応答者

図 9-37　ISAKMP情報提供交換（網掛部は暗号化）

　図9-38に、フェーズ1においてSAの折衝に失敗した場合に使用される ISAKMP情報提供交換

の例を示します。フェーズ1の折衝に失敗した場合には、ISAKMP SAは確立されていないため、

ISAKMP情報提供交換で使用される通知ペイロードは暗号化されません。

SAパラメータの提案（フェーズ 1メインモード）

SA選択不可（ISAKMP情報提供交換）

ISAKMPヘッダSA

始動者応答者

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情報提供交換

で使用されるペイロードは暗号化されます。

SAパラメータの提案（フェーズ 2クイックモード）

SA選択不可（ISAKMP情報提供交換）

ISAKMPヘッダ

SAハッシュ（1）

始動者応答者


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: phase2/others Ioakley-quick[E]: [|hash] (DF)18:57:41.251233 192.168.1.30.isakmp > 192.168.1.50.isakmp: isakmp: phase2/others Rinf[E]: [|hash]


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相手認証方式属性の属性値を示します。


表 9-17　ISAKMP SA相手認証方式属性値

0 予約

1 事前共有秘密鍵（実装必須）

2 DSS署名

3 RSA署名

4 RSA暗号化

5 改良型 RSA暗号化

6 ElGamal暗号化

7 改良型 ElGamal暗号化

8 ECDSA署名

9～ 65,000 予約（未割り当て）

65,001～ 65,535 プライベート用

属性値相手認証方式（Authentication Method）

Oakleyグループ　ISAKMP SAで使用する共有秘密鍵を確立するために、Diffie-Hellman鍵共有アルゴリズムを

使用します。Diffie-Hellman鍵共有アルゴリズムで使用されるOakleyグループには、MODPグ

ループ（Modular Exponentiation Group）とEC2Nグループ（Elliptic Curve Group over Galois Field

GF[2N]）があります。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グループ属性値

0 予約

1 768ビットMODPグループ（実装必須）

属性値（グループ番号） Oakleyグループの種類（Group Description）


表 9-18　ISAKMP SA Oakleyグループ属性値（つづき）

2 1,024ビットMODPグループ

3 155ビット EC2Nグループ



6 163ビット EC2Nグループ（ランダムシード）

7 163ビット 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有効期間タイプ属性値

0 予約

1 秒

2 キロバイト

属性値有効期間タイプ（Life Type）


表 9-19　ISAKMP SA有効期間タイプ属性値（つづき）

3～ 65,000 予約（未割り当て）

65,001～ 65,535 プライベート用

属性値有効期間タイプ（Life Type）

9.7.2　IPsec SAパラメータ　ここではIKEのフェーズ2で折衝されるIPsec SA（AHおよびESPのSA）およびIPCompのIPCA

に関するパラメータについて説明します。それぞれのパラメータで使用される値は、IANAに

よって割り当てられています。最新の情報については、IANAの割り当て状況 [11] を確認して

ください。

セキュリティプロトコル ID　セキュリティプロトコル IDは、本書執筆時点では、表 9-20のように割り当てられています。

フェーズ 2 で AH の SA パラメータを折衝する場合は、セキュリティプロトコル ID として

PROTO_IPSEC_AHを指定します。ESPのSAパラメータを折衝する場合は、PROTO_IPSEC_ESP

を指定します。また、IPCompの IPCAパラメータを折衝する場合は、PROTO_IPCOMPを指定

します。

表 9-20　セキュリティプロトコル ID

0 予約

1 PROTO_ISAKMP

2 PROTO_IPSEC_AH

3 PROTO_IPSEC_ESP

4 PROTO_IPCOMP


249～ 255 プライベート用

ID番号セキュリティプロトコル ID

AHトランスフォーム ID　表 9-21に、本書執筆時点で定義されている AHトランスフォーム IDを示します。AHトラン

スフォーム IDは、AHで使用する認証アルゴリズムを指定するパラメータです。ただし、この


トランスフォームIDのみで認証アルゴリズムが決定するわけではなく、SA属性として定義され

ている認証アルゴリズム属性を共に指定する必要があります。例えば、認証アルゴリズムとして

HMAC-MD5-96を指定する場合には、トランスフォームIDにAH_MD5を指定し、認証アルゴリ

ズム属性に HMAC-MD5を指定します。

表 9-21　AHトランスフォーム ID

0、1 予約使用されない

2 AH_MD5（実装必須） MD5を使用する認証アルゴリズム

3 AH_SHA（実装必須） SHA-1を使用する認証アルゴリズム

4 AH_DES DESを使用する認証アルゴリズム

5 AH_SHA2-256 SHA-256を使用する認証アルゴリズム



8 AH_RIPEMD RIPEMDを使用する認証アルゴリズム

9 AH_AES-XCBC-MAC AES-XCBC-MACを使用する認証アルゴリズム

10～ 248 予約（未割り当て）未割り当て

249～ 255 プライベート用プライベートでの使用

ID番号トランスフォーム ID 用途

ESPトランスフォーム ID　表9-22に、本書執筆時点で定義されているESPトランスフォームIDを示します。ESPトラン

スフォーム IDでは、ESPで使用する暗号化アルゴリズムを指定します。

表 9-22　ESPトランスフォーム 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）



表9-22　ESPトランスフォーム 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）


249～ 255 プライベート用プライベート用に使用


IPCompトランスフォーム ID　表9-23に、本書執筆時点で定義されているIPCompトランスフォームIDを示します。IPComp

トランスフォーム IDでは、IPCompで使用する圧縮アルゴリズムを指定します。

表 9-23　IPCompトランスフォーム ID

0 予約使用されない

1 IPCOMP_OUI 独自の圧縮アルゴリズム用

2 IPCOMP_DEFLATE DEFLATE（RFC 2394）

3 IPCOMP_LZS LZS（RFC 2395）

4 IPCOMP_LZJH LZJH（RFC 3051）


48～ 63 プライベート用プライベートでの使用

64～ 255 予約将来のために予約



認証アルゴリズム

　AHでは、IPsec SAの認証アルゴリズム属性（Authentication Algorithm）で認証アルゴリズムを

指定する必要があります。表 9-24に本書執筆時点で定義されている IPsec SA認証アルゴリズム

属性値と、その属性値を指定するために必要な AHトランスフォーム IDを示します。

　ESPでは、認証アルゴリズム属性の指定はオプションです。ESPで認証機能を利用する場合に

は、この認証アルゴリズム属性で、認証アルゴリズムを指定します。

表 9-24　IPsec SA認証アルゴリズム属性値

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



8 HMAC-RIPEMD AH_RIPEMD HMAC-RIPEMD-160-96（RFC 2857）

9 AES-XCBC-MAC AH_AES- AES-XCBC-MAC-96（RFC 3566） XCBC-MAC

10～ 61,439 予約（未割り当て） ― 未割り当て

61,440～ 65,535 プライベート用 ― プライベートでの使用

属性値認証アルゴリズム AHトランス用途フォーム ID

Oakleyグループ　IPsec SA（AHまたは ESP）で PFSを有効にする場合には、IPsec SAのOakleyグループ属性

（Group Description）でOakleyグループを指定します。表9-25に、本書執筆時点で定義されてい

る Oakleyグループを示します。


表 9-25　IPsec SA Oakleyグループ属性値

0 予約

1 768ビットMODPグループ（実装必須）













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-26　IPsec SA有効期間タイプ属性値

0 予約

1 秒

2 キロバイト

3～ 61,439 予約（未割り当て）

61,440～ 65,535 プライベート用

属性値有効期間タイプ（SA Life Type）

カプセル化モード

　IPsec SAのカプセル化モード属性（Encapsulation Mode）によって、使用する IPsecのモード

（トンネルモードまたはトランスポートモード）を指定します。表 9-27に、本書執筆時点で定義

されている IPsec SAカプセル化モード属性の属性値を示します。

表 9-27　IPsec SAカプセル化モード属性値

0 予約

1 トンネルモード

2 トランスポートモード

3～ 61,439 予約（未割り当て）

61,440～ 65,535 プライベート用

属性値カプセル化モード（Encapsulation Mode）

ECNトンネル　IPsec SAのECNトンネル属性（ECN Tunnel）によって、ECNを IPsecトンネルで有効とする

か（Allowed）、無効とするか（Forbidden）を指定します。この属性はオプションです。表9-28に、

本書執筆時点で定義されているIPsec SA ECNトンネル属性の属性値を示します。属性が存在し

ない場合や、属性値が指定されない場合には、無効（Forbidden）であるとみなされます。


表 9-28　IPsec SA ECNトンネル属性値

0 予約

1 有効（Allowed）

2 無効（Forbidden）

3～ 61,439 予約（未割り当て）

61,440～ 65,535 プライベート用

属性値 ECNトンネル（ECN Tunnel）

参考文献[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-ike-

auth-ecdsa-02.txt, March 2001, Work in Progress.

[7] D. Dukes and R. Pereira, “The ISAKMP Configuration Method”, draft-dukes-ike-mode-

cfg-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

ipsecのアーキテクチャ - tatsuya baba personal website · 74 5章...

Documents