付録B

実験の手順

相互接続性確認 基本試験
Pre-Shared 接続試験
【試験目的】
IKE 相互認証方式で、Pre-Shard を使用した際の接続性の確認を行う。
【手順】※IKE ネゴシエーションは、IKE View にて Capture し保存する。
1） パラメータパターン１ 接続性確認①A，B 2 台の異なる IPSec 装置に、以下のパラメータを設定。
(ア) 暗号アルゴリズム：DES-CBC(イ) Hash アルゴリズム：MD5(ウ) ペイロード：ESP(エ) 認証アルゴリズム：HMAC-MD5(オ) Group Description：Group1(カ) Shard Secret key：任意 （文字数制限等を確認）(キ) その他のパラメータ：Key Life Time や ID タイプ等のパラメータは任意②A の暗号対象ネットワーク上のクライアントから、B の暗号対象ネットワーク上のクライ
アントに Ping を行い SA が確立され、IPSec 通信が正常に行える事を確認する。
③IPSec 機器の再起動等を行い、②で確立した SA を削除する。
④B の暗号対象ネットワーク上のクライアントから、A の暗号対象ネットワーク上のクライアントに Ping を行い S が確立され、IPSec 通信が正常に行える事を確認する。

2） パラメータパターン 2 接続性確認① A，B 2 台の異なる IPSec 装置に、以下のパラメータを設定。
(ア) 暗号アルゴリズム ：DES-CBC(イ) Hash アルゴリズム：SHA-1(ウ) ペイロード：ESP(エ) 認証アルゴリズム ：HMAC-SHA(オ) Group Description：Group1(カ) Shard Secret key ：任意（文字数制限等確認）(キ) その他のパラメータ：Key Life Time や ID タイプ等のパラメータは任意② 上記（1）-②〜④を繰返す。

【結果】以下の試験結果マトリックスに試験結果を記入

１．Pre-Shared接続試験
試験実施日時：製品 A：
Version ：Platform ：担当：
製品 B ：
Version ：Platform ：担当：1）パラメータパターン1 接続性確認
Initiater
製品AResponder

結果LOGファイル名

製品 A
製品 B

○

製品 B
結果

LOGファイル名○

1-1-B-A.log

備考

1-1-A-B.log

2）パラメータパターン2 接続性確認
Initiater
製品AResponder

結果

LOGファイル名

製品 A
製品 B

○

製品 B
結果

LOGファイル名○

1-2-B-A.log

1-2-A-B.log

記入方法
試験結果/ LOGファイル名 の形式で記入
試験結果は下記参照
正常にSA確立し、IPSec通信が行えた場合は、○を記入
SA確立に失敗し、IPSec通信が不能の場合 ×を記入

備考

ID ペイロードサポート確認【試験目的】
各製品がサポートする Phase2 の ID ペイロードタイプを確認し、異なる ID ペイロードタイプを設定した時の接続性を確認する。
【手順】※IKE ネゴシエーションは、IKE View にて Capture し保存する。
1）Phase2 ID ペイロードタイプの確認①各製品がサポートする ID ペイロードタイプを確認し、下記のマトリックスに記入する。
2）異なる ID ペイロードタイプ使用時の接続性確認
一般的に使用される「ID_IPV4_ADDR」と「ID_IPV4_ADDR_SUBNET 」の２つを例にし手順を示す。
①製品 A の ID ペイロードタイプに 「ID_IPV4_ADDR」を設定。製品 B の ID ペイロード
タイプに「ID_IPV4_ADDR_SUBNET」を設定する。
（相互認証は Pre-Shard を使用し、その他のパラメータは任意の値を使用する。
）②A の暗号対象ネットワーク上のクライアントから、B の暗号対象ネットワーク上のクライ
アントに Ping を行い SA が確立され、IPSec 通信が正常に行える事を確認し、その際にどちらのパラメータが有効になっているかを確認する。
③IPSec 機器の再起動等を行い、②で確立した SA を削除する。
④B の暗号対象ネットワーク上のクライアントから、B の暗号対象ネットワーク上のクライ
アントに Ping を行い SA が確立され、IPSec 通信が正常に行える事を確認し、その際にどちらのパラメータが有効になっているかを確認する。
⑤製品 B の ID ペイロードタイプに「 ID_IPV4_ADDR_SUBNET」を設定。製品 B の ID ペ
イロードタイプに「ID_IPV4_ADDR」を設定する。

⑥ ②〜⑤を繰返す。

【結果】以下の試験結果マトリックスに試験結果を記入

１．Phase2 IDサポート確認試験
1）Phase2 IDペイロードタイプの確認
試験実施日時：

製品名 ：Version ：Platform ：担当：

IDペイロードタイプ

サポート

IPV4̲ADDR
IPV4̲ADDR̲SUBNET
IPV4̲ADDR̲RANGE

○○

備考

記入方法
サポートするIDペイロードタイプに ○ を記入
上記以外をサポートする場合は、IDペイロードタイプ欄にサポートするタイプを記入する。

2）異なるIDペイロードタイプ使用時の接続性確認
試験実施日時：製品 A：
Version ：Platform ：担当：

製品 B ：
Version ：Platform ：担当：

Initiater
製品A
IPV4̲ADDR
結果 LOGﾌｧｲﾙ名

IPV4＿Subnet
結果 LOGﾌｧｲﾙ名

製品B
IPV4̲ADDR
IPV4＿Subnet
結果 LOGﾌｧｲﾙ名 結果 LOGﾌｧｲﾙ名

Responder

IPV4̲ADDR○製品A
IPV4̲Subnet
IPV4̲ADDR○2-2-A-B.log

製品B
IPV4̲Subnet
記入方法
試験結果/ LOGファイル名 の形式で記入
試験結果は下記参照
正常にSA確立し、IPSec通信が行えた場合は、SA確立に失敗し、IPSec通信が不能の場合

○を記入
×を記入

2-2-B-A.log

通信中リキー動作確認【試験目的】
各製品がサポートする SA Life Type(SA 有効種類)を確認し、通信中に SA Duration（SA 有効期間）を迎えた際に、正常に Re-key が行われ通信が途絶えない事を確認する。
【手順】
1) SA Life Type の確認①製品サポートする SA Life Type を確認する。
②それぞれの SA Life Type の設定値の最小値，最大値を確認する。
2) 通信中 Re-key 動作の確認①製品 A の Life Duration を出来るだけ小さく設定。製品 B はそれよりも出来るだけ大きい値を設定。
②暗号対象ネットワーク上のクライアントから、Peer の暗号対象ネットワーク上のクライ
アントに Ping 等で通信を行い SA が確立され、IPSec 通信が正常に行える事を確認する。
③Ping 等で IPSec 通信を継続して行い通信中に Re-key を発生させ、通信が途絶えない事を確認④ftp 等の tcp で IPSec 通信を継続して行い通信中に Re-key を発生させ、通信が途絶えない事を確認⑤製品 B の Life Duration を出来るだけ小さく設定。製品 B は、それよりも出来るだけ大きい値を設定。
⑥ ②〜⑤を繰返す。

【結果】以下の試験結果マトリックスに試験結果を記入

3．通信中Re-key動作確認試験
1）SA Life Type確認
製品名：VPN-1
Version：v4.1 sp2
SA Duration
Phase1SA Life TypeSec

最小値10minPhase2
最大値10080min

記入方法
SA Life Typeには、「Sec」または、「Byte」を記入
SA Durationの単位は、任意の単位を記入

最小値
2min

最大値1440min

備考

運用性確認 基本試験
IP フラグメンテーション【試験目的】IPSEC 装置でフラグメンテーション発生時の IPsec 通信を確認する。IP フラグメンテーションが発生しても、IPsec 通信が可能であるかを確認する。
具体的には、平文では MTU 以下であるパケットが、ＥＳＰになったときに MTU を超える場合にフラグメントして通信可能であるか、以下２パターンで確認する。
１）平文に Don't Fragment ビットがセットされていない場合基本的なフラグメント処理を確認する
２）平文に Don't Fragment ビットがセット場合されている場合
DF をセットした際のデータの取り扱い判断を確認する
DF セットしたときのフラグメンテーション動作はさらに PMTU のサポートが確認項目として挙げられる｡ESP の経路に MTU が小さく設定された区間が存在した場合ゲートの外 (非安全)側より内側に対してアナウンスがなされなければならない｡今回設定された実験環境ではPMTU についての試験は行うことができない。次回以降への課題項目である｡【仕様確認】IPSEC 装置が RFC1191 PMTU（Path MTU Discovery）をサポートしているかをチックシートに記載する。
【手順】
1)DF フラグ OFF のとき端末(Windows のコマンドラインで説明 )のコマンドラインから ping コマンドでデータ長が1440byte*パケットを送信する。
>ping –l 1440 [相手ゲートの端末]*ESP 処理後に 1518byte となりフラグメンテーション処理が行なわれる通信が失敗した場合はパケットログ､製品から出力記録されるログより原因を分析し理由とともにチェックシートに記入する。
対向機器の端末からも同様の実験を行う。
2)DF フラグ ON のとき双方、または一方の機器が DF セット時に ESP 処理を行わない場合はこの試験を見送る｡ただし､どちらか一方でも DF セット時の動作を確認していない場合はこの手順を実行する。
端末のコマンドラインから ping コマンドでデータ長が 1440byte､DF がセットされたパケットを送信する。
>ping –l 1440 –f [相手ゲートの端末]
通信が失敗し､メッセージがタイムアウトであった場合は ESP が送信されて返信が無いことを確認する｡
通信が失敗し､メッセージ が「Packet needs to be fragmented but DF set.」であった場合は
ゲ ー ト と 端 末 の 間 の パ ケ ッ ト を 採 取 し ICMP(Destination Unreachable: fragmentationneeded and DF set) が返されていることを確認する
対向機器の端末からも同様の実験を行う。

【結果】
DATE：
チェックシート記載ベンダー、ご担当者名：：
IPSEC装置A 装置名：
ベンダー名：
ご担当者名：
装置バージョン：IPSEC装置B 装置名：
ベンダー名：
ご担当者名：
装置バージョン：（仕様確認）IPSEC装置A 装置名：

IPSEC装置B 装置名：

・
RFC1191サポート ○orNG

・
RFC1191サポート ○orNG・他の仕様の場合 サポート仕様、方法を記載

・
他の仕様の場合 サポート仕様、方法を記載

１）平文にDon't Fragmentビットがセットされていない場合
・
IPSEC装置A→B ping -t -l 1440
・
IPSEC装置B→A ping -t -l 1440
ping応答 ○orNG
ping応答 ○orNG
・
NGの場合の状況、データ等を記録
・NGの場合の状況、データ等を記録

２）平文にDon't Fragmentビットがセットされている場合
・
IPSEC装置A→B ping -t -l 1440 -f
・
IPSEC装置B→A ping -t -l 1440 -f
PMTU送出確認○orNG
PMTU送出確認○orNG
IKEVIEWファイル名
IKEVIEWファイル名
ping応答 ○orNG
ping応答 ○orNG
・
NGの場合の状況、データ等を記録

・NGの場合の状況、データ等を記録

SA 消失試験【目的】
IPsec 機器が故障あるいは停電などの理由で SA を消失した後に復旧する際の各製品の挙動､および復旧手順を確認する
まず、各々の SA を消去する機能を調査する。
前項の調査に基づき実際に機器を再起動やなどを行ながら通信回復の試験を行う。
【手順】
SA 削除の機能確認
Phase2 の SA のみを消去できるか､特定のセッションの SA を消去できるかを調査する
Phase1 の SA を消去できるか､特定の機器との SA を消去できるかを調査する
SA 消失後の復旧手順確認
次の 3 段階の組み合わせで行う。それぞれの指示は組み合わせリストに従う。
① 初期 SA 確立時の条件
イニシエータに指定された機器から SA を作成させる。
② SA 状態(操作)指定された機器の SA 情報をそのまま､またはフェーズ 2 SA を削除する。
③ 再確立の方法 1 -片側機器の再起動指定された機器を再起動する④ 再確立の方法 2 -ping コマンドによる SA 回復の試行指定された機器の配下に在る P C から ping コマンドでゲート間のトラフィックを発生させて反応を観察する。
組み合わせ表初期SA確立時の条件

SAの状態
製 品AのSAが残った状態

製 品Aのフェーズ２のみ削除
製品 Aが イニシエータ
製 品Bの SAが残った状態

再確立の方法
製品B をリブート後製品Aからping−（１）製品B をリブート後製品Bからping−（２）製品B をリブート後製品Aからping−（３）製品B をリブート後製品Bからping−（４）製品Aをリブート後製品Aからping −（５）製品Aをリブート後製品Bからping

製 品Bのフェーズ２のみ削除

製 品AのSAが残った状態

製 品Aのフェーズ２のみ削除−（６）

製品Aをリブート後製品Aからping −（７）製品Aをリブート後製品Bからping−（８）製品B をリブート後製品Aからping−（９）製品B をリブート後製品Bからping−（10）製品B をリブート後製品Aからping−（11）製品B をリブート後製品Bからping−（12）製品 Bがイニシエータ
製 品Bの SAが残った状態

製品Aをリブート後製品Aからping −（13）製品Aをリブート後製品Bからping

製 品Bのフェーズ２のみ削除−（14）

製品Aをリブート後製品Aからping −（15）製品Aをリブート後製品Bからping−（16）【結果】SA消失に関する試験の手順 （フォーム２）＜SA再構築試験＞
記録日
製品Aの名称
ベンダー名
製品Bの名称
ベンダー名
記録者名

2001年1月24日

初期SA確立時の条件

SAの状態
AのSAが残った状態
Aのフェーズ２のみ削除

Aがイニシエーター
BのSAが残った状態
Bのフェーズ２のみ削除

リブートした側 pingした側
Bをリブート Aからping
Bをリブート Bからping
Bをリブート Aからping
Bをリブート Bからping
Aをリブート Aからping
Aをリブート Bからping
Aをリブート Aからping
Aをリブート Bからping

結果

備考

Bをリブート Aからping
Bをリブート Bからping
Aのフェーズ２のみ削除 Bをリブート Aからping
Bをリブート Bからping
Bがイニシエーター
Aをリブート Aからping
BのSAが残った状態
Aをリブート Bからping
Bのフェーズ２のみ削除 Aをリブート Aからping
Aをリブート Bからping※ 「結果」には条件に相当する以下の記号を入れてください。
◎： おおよそ10秒でSAの再構築ができた。
○： 10〜60秒 かかってSAの再構築ができた。
△： 再確立まで60秒以上かかった。
×： 再確立できない。
−： 試験せず。（フェーズ２のみ消せないなどの理由で）※◎以外は「備考」欄に簡単に状況を記述ください。「何秒でつながった」「繰り返しエラーを発し結局再確立できなかった」など※気がついたことがあれば◎の場合でもコメントを記述ください。「エラーを何回発したら自動的にリブートして再確立した」「再確立した際、古いSAが残った。SA Life Time後古いSAは消えた」などAのSAが残った状態END to END 通信確認【目的】
試験手順を作成するにあたり試験の内容を考察する○TCP 通信試験
TCP/IP は経路上におけるデータの保護を行うためにセッションを維持している。また TCPのセッションを用いるアプリケーション(Telnet, FTP など)で取り扱われるデータは送信元と受信先で同じデータでにならなければならない。このため接続実験では FTP によるファイル転送を採用し、通信開始と完了を確認する。
○UDP 通信試験
UDP は TCP に比較してセッションを維持せずに通信を行う。使用するアプリケーションはLAN であることを前提条件にした TFTP など、データの完全な一致を必要としないストリーミング系などがある。今回の試験では TFTP をアプリケーションとして採用するが、将来的には電子会議室システムなど実際に使用される可能性の高いアプリケーションでテストを行うことが望ましいと考える。
【手順】
環境の確認
以下のアプリケーションをクライアント側サブネットのシステムに用意する。
FTP サーバ、FTP クライアント TFTP サーバ、TFTP クライアント
実験前の確認項目
IKEview は外側のセグメントに配置して IKE を収集する。ftp によるファイル転送中に re-keyが行われることを確認する(re-key は可能な条件すべて行う。行われた場合はその可否と Ph2 かPh1，2 両方であることを明記する)。
実験手順
TCP: ftp1.
製品 A の配下の PC (A) より製品 B の配下の PC(B) に対して ftp セッションを開始する。PC(B)のファイルを get コマンドで取り込む
2.
転送が終わったファイルのファイルサイズを確認して転送もとのファイルと同じことを確認する。IKEview のログで re-key が行われることを確認する。
3.
A、B の関係を入れ替えて１，２の手順を繰り返す。
UDP: tftp
1.
製品 A の配下の PC (A) より製品 B の配下の PC (B) に対して tftp セッションを開始する。PC(B)のファイルを put コマンドで取り込む
2.
転送が終了することを確認する。
3.
A，B の関係を入れ替えて１，２の手順を繰り返す。

【結果】6.END to END通信試験
製品A

機器名
プラットフォーム
バージョン［/プラットフォーム］
担当者名

製品B

機器名
プラットフォーム
バージョン［/プラットフォーム］
担当者名

initiator&Client

TCP[ftp]

UDP[tftp]

備考AB注)イニシエータはアプリケーションのクライアント側であること。レスポンダになる場合はそのことを明記する。
FTPによるファイル転送はファイルサイズを比較して一致した場合に○をつける。それ以外は×。
TFTPによるファイル転送は完了することのみを条件として○をつける。