インターネット鍵交換
IKE の紹介
インターネット鍵交換（IKE）は、2 つのデバイス間のセキュアで認証された通信チャネルを設定するのに使われるセキュアな鍵管理プロトコルです。
IKE は以下を実行します。
IKE および IPsec パラメータのネゴシエートおよび管理
セキュアな鍵交換の認証
パスワードではなく、共有された秘密鍵と公開鍵による相互ピア認証の提供
ID 保護の提供（メイン モード）
Diffie-Hellman 方式を採用しており、IPsec ではオプションとなっています（共有鍵はエンドポイントで手動で入力できます）。
IKE バージョン
IKE 標準には 2 つのバージョンがあります。
IKE バージョン 1 - RFC 2409 で定義された IKE プロトコル。
IKE バージョン 2 - IKE バージョン 2（IKEv2）は、RFC 7296 で定義された IKE プロトコルの最新バージョンです。
インターネット鍵交換バージョン 2（IKEv2）は、RFC 7296 で定義されたインターネット鍵交換（IKE）プロトコルの最新バージョンです。VPN ピアは、IKEv1 または IKEv2 のいずれかに構成されます。ピアが IKEv2 として構成されている場合、リモート ピアが IKEv1 のネゴシエーションを開始しても、IKEv1 にフォールバックすることはできません。
IKEv1 と比べて IKEv2 を使用する利点は以下の通りです。
8 つの初期交換を単一の 4 メッセージ交換に置き換えます。
IPsec SA 設定の遅延を短縮し、接続確立速度を向上させます。
DOS 攻撃に対する堅牢性が向上します。
シーケンス番号、確認応答、エラー訂正を使って信頼性を向上させます。
すべてのメッセージがリクエストまたは応答であるため、信頼性が向上します。応答を受信しない場合、開始側には再送信する責任があります。
IKE と IPSec 間のやり取り
IPsec は、以下のいずれかの方法で VPN を確立できます。
インターネット鍵交換（IKE）プロトコル — IPsec は、IKE プロトコルを使用して、鍵とセキュリティの関連付けの自動生成とネゴシエーションをサポートします。IKE を使用して 2 つのエンドポイント間の VPN をネゴシエートすると、手動での鍵交換よりも高いセキュリティが得られます。
手動での鍵の交換 — IPsec は、VPNを確立するために、双方が手動（例：電話や電子メールなど）で鍵を使用および交換することをサポートしています。
IKEv1 メッセージ交換
IKE ネゴシエーションには 2 つのフェーズがあります。
フェーズ1 — チャネルの認証とセキュリティ確保の方法に関する提案の交換をネゴシエートします。
フェーズ 2 — IPsec トンネルを通過するデータをセキュリティ保護するために、セキュリティ アソシエーション（SA）をネゴシエートします。
IKEトンネルネゴシエーションのフェーズ1
AutoKey IKE（インターネット鍵交換）トンネルネゴシエーションのフェーズ1は、チャネルの認証とセキュリティ確保の方法に関するプロポーザルの交換で構成されています。参加者は、以下のような許容可能なセキュリティ サービスのプロポーザルを交換します。
暗号化アルゴリズムーDES（データ暗号化規格）、3DES（トリプルデータ暗号化規格）、AES（次世代暗号化標準）。（「IPsec の概要」を参照してください。）
認証アルゴリズムーMD5（メッセージダイジェスト5）とSHA（セキュアハッシュアルゴリズム）。（「IPsec の概要」を参照してください。）
Diffie-Hellman（DH）グループ（「IPsec の概要」を参照してください。）
事前共有鍵または RSA/DSA 証明書（「IPsec の概要」を参照してください。）
フェーズ1のネゴシエーションが成功すると、トンネルの両端が提案されたフェーズ1セキュリティパラメーターの少なくとも1つのセットを受け入れ、それを処理することに同意した場合に終了します。ジュニパーネットワークスデバイスは、フェーズ1ネゴシエーションの最大4つのプロポーザルをサポートします。このため、受け入れる鍵ネゴシエーションのセキュリティパラメーターの範囲をどのように制限するかを定義できます。Junos OS は、定義済みの標準、互換、基本フェーズ 1 のプロポーザル セットを提供します。カスタムフェーズ1プロポーザルを定義することもできます。
フェーズ1の交換は、メインモードまたはアグレッシブモードのいずれかで実行できます。IKE ポリシーの設定中にモードを選択できます。
このトピックは、以下のセクションで構成されています。
メイン モード
メインモードでは、イニシエーターと受信者が3つの双方向交換（合計6つのメッセージ）を送信して、以下のサービスを実行します。
最初の交換（メッセージ1および2）—暗号化および認証アルゴリズムを提案して受け入れます。
2番目の交換（メッセージ3および4）—DH交換を実行し、イニシエーターと受信者がそれぞれ疑似乱数を提供します。
3番目の交換（メッセージ5および6）—イニシエーターと受信者のIDを送信および検証します。
3 番目のメッセージ交換で送信される情報は、最初の 2 つの交換で確立された暗号化アルゴリズムによって保護されます。したがって、参加者のIDは暗号化され、「クリアテキスト」では送信されません。
アグレッシブ モード
アグレッシブ モードでは、イニシエーターと受信者がメイン モードと同じ目的を達成しますが、2 つの交換だけで、合計 3 つのメッセージが送信されます。
最初のメッセージ—イニシエーターは、SA（セキュリティアソシエーション）を提案し、DH交換を開始し、疑似乱数とIKE IDを送信します。
フェーズ 1 ネゴシエーションで、複数のプロポーザルを使用してアグレッシブ モードを設定する場合は、DH グループはネゴシエートできないため、すべてのプロポーザルで同じ DH グループを使用します。最大 4 つのプロポーザルを設定できます。
2番目のメッセージ—受信者はSAを受け入れ、イニシエーターを認証し、疑似乱数、IKE IDを送信し、受信者の認定書（認定書を使用している場合）を送信します。
3番目のメッセージ—イニシーターは受信者を認証し、交換を確認した後、証明書を使用している場合は、イニシエーターの証明書を送信します。
参加者のIDは（最初の2つのメッセージでは）クリアテキストで交換されるため、アグレッシブモードではIDの保護は提供されません。
メイン モードおよびアグレッシブ モードは、IKEv1 プロトコルにのみ適用されます。IKEv2プロトコルは、メインモードおよびアグレッシブモードを使用してネゴシエートしません。
関連項目
IKEトンネルネゴシエーションのフェーズ 2
参加者は、セキュアで認証済みのチャネルを確立した後、フェーズ 2 に進み、IPsec トンネルを介して送信されるデータを保護するためにセキュリティアソシエーション (SA) をネゴシエートします。
フェーズ 1 のプロセスと同様、参加者は、SA で採用するセキュリティパラメーターを決定するプロポーザルを交換します。フェーズ2プロポーザルにも、カプセル化セキュリティペイロード（ESP）または認証ヘッダー（AH）のいずれかのセキュリティプロトコルと、一部の暗号化および認証アルゴリズムが含まれます。PFS（Perfect Forward Secrecy）が求められる場合には、プロポーザルで Diffie-hellman（DH）グループも指定できます。
フェーズ1で使用されるモードに関係なく、フェーズ2は常にクイックモードで動作し、3つのメッセージの交換が含まれます。
このトピックは、以下のセクションで構成されています。
プロキシ ID
フェーズ2では、ピアはプロキシIDを交換します。プロキシIDは、ローカルおよびリモートのIPアドレスプレフィックスで構成されています。両方のピアのプロキシー ID は一致しなければなりません。つまり、一方のピアに指定されたローカル IP アドレスは、他方のピアに指定されたリモート IP アドレスと同じでなければなりません。
Perfect Forward Secrecy
PFS は、先行する鍵から独立して、かつ先行するキーとは無関係にフェーズ 2 の鍵を導出する方法です。または、フェーズ 1 プロポーザルが、すべてのフェーズ 2 鍵が派生する鍵（SKEYID_d 鍵）を作成します。SKEYID_d 鍵は、最小限の CPU 処理でフェーズ 2 鍵を生成できます。残念ながら、許可されていない第三者がSKEYID_dキーへのアクセス権を得ると、すべての暗号化キーが危険にさらされることになります。
PFS は、各フェーズ 2 トントンネルに新しい DH鍵交換が発生するよう強制することにより、セキュリティリスクに対応します。このように PFS を使用するとセキュリティが強化されますが、PFS を有効にした状態だとフェーズ 2 での鍵更新手順かかる時間がわずかに長くなる可能性があります。
リプレイ防御
リプレイ攻撃は、許可されていない人物が一連のパケットを傍受し、これを使ってシステムを溢れさせ、DoS（サービス拒否）を引き起こしたり、信頼できるネットワークに侵入したりした場合に発生します。Junos OS では、デバイスがすべての IPsec パケットについて、以前に受信したことがあるかどうかをチェックできるようにするリプレイ防御機能を提供しています。パケットが指定されたシーケンス範囲外に到着すると、Junos OS はこれを拒否します。パケットは常にシーケンス番号を使用して送信されるため、この機能の使用においてネゴシエーションは不要です。シーケンス番号をチェックするか、しないかのみを選択できます。
関連項目
IKEv2 メッセージ交換
IKE バージョン 2 は、IKEv1 方式の後継です。これは、ピア VPN デバイス間のセキュアな VPN 通信チャネルを提供し、IPsec セキュリティ・アソシエーション (SA) のネゴシエーションと認証を保護された方法で定義しますす。
IKEv2 には IKEv1 のようなフェーズ 1 とフェーズ 2 はありませんが、IKEv2 で IPsec トンネルをネゴシエートする際には 4 つのメッセージ交換が行われます。IKEv2 のメッセージ交換は以下の通りです。
IPsec トンネルを確立するためのセキュリティ属性をネゴシエートします。これには、使用するプロトコル / パラメータの交換や、Diffie-Hellman グループの交換が含まれます。
IPsec トンネルが確立されている間、各ピアは自らの ID を確立または認証します。
ピア同士で追加のセキュリティ アソシエーションを作成します。
ピアは、ライブ性の検出、SA リレーションシップの削除、エラー メッセージのレポートを実行します。
IKEv2 構成ペイロード
構成ペイロードは、応答側から開始側へのプロビジョニング情報の伝送用に提供される IKEv2 オプションです。IKEv2 構成ペイロードは、ルートベース VPN でのみサポートされます。
RFC 5996、インターネット鍵交換プロトコル バージョン 2（IKEv2では、応答側が開始側に返すことのできる 15 種類の構成属性が定義されています。
IKEv2 鍵更新と再認証
IKEv2 では、鍵更新と再認証は別個のプロセスです。
鍵更新により、IKE セキュリティ アソシエーション（SA）用の新たな鍵が確立され、メッセージ ID カウンターがリセットされますが、ピアの再認証は行われません。
再認証は、VPN ピアが認証資格へのアクセスを保持していることを確認します。再認証は、IKE SA および子 SA 用に新たな鍵を確立し、保留中の IKE SA または子 SA の鍵更新は必要なくなります。新しい IKE と子 SA が作成された後、古い IKE と子 SA が削除されます。
IKEv2 の再認証は、デフォルトでは無効になっています。再認証を有効にするには、再認証の頻度を 1～100 の値に構成します。再認証の頻度とは、再認証が行われるまでに発生する IKE 鍵更新の回数のことです。例えば、再認証の頻度を 1 として構成した場合、IKE の鍵更新のたびに再認証が行われます。再認証の頻度を 2 として構成した場合、IKE 鍵更新 2 回につき再認証が 1 回行われます。再認証の頻度を 3 として構成すると、IKE 鍵更新 3 回ごとに再認証が行われる、という具合です。
IKEv2 フラグメント化
認定書ベースの認証を使用する場合、複数の認定書を送信すると IKEv2 パケットがパス MTU を超えることがあります。IKE メッセージのサイズがパス MTU を超える場合、メッセージは IP レベルでフラグメント化されます。NAT デバイスなどの一部のネットワーク機器は、IP フラグメントの通過を許可しないため、IPsec トンネルの確立ができません。
RFC 7383「インターネット鍵交換プロトコル バージョン 2（IKEv2）メッセージ フラグメント化」で説明されているように、IKEv2 メッセージ フラグメント化により、IP フラグメントがブロックされ、ピアが IPsec セキュリティ アソシエーション（SA）を確立できないような環境でも IKEv2 を動作させることができます。IKEv2 フラグメント化は、大きな IKEv2 メッセージを小さなメッセージに分割して、IP レベルでフラグメント化が発生しないようにします。フラグメント化は、元のメッセージが暗号化および認証される前に行われるため、各フラグメントは別個に暗号化および認証されます。受信側でフラグメントの収集、検証、復号化、統合が実行されて元のメッセージになります。
IKEv2 のトラフィック セレクター
IKEv2 では、IKE ネゴシエーション時に使用するトラフィック セレクターを構成できます。トラフィックセレクターとは、トラフィックが指定されたローカルアドレスとリモートアドレスのペアに一致する場合に、VPNトンネルを介したトラフィックを許可するというIKEピア間の合意です。トラフィックセレクターに適合したトラフィックのみが、関連するセキュリティアソシエーション（SA）を通じて許可されます。トラフィック セレクターは、トンネルの作成時に、トンネルを設定し、トンネルの通過を許可するトラフィックを決定するのに使用されます。
プロキシー ID
プロキシー ID は、インターネット鍵交換（IKE）仮想プライベート ネットワーク（VPN）ネゴシエーションのフェーズ 2 で使用されます。VPN トンネルの両端では、プロキシー ID が手動で構成されているか（ルートベース VPN）、トンネル ポリシーで送信元 IP、宛先 IP、サービスの組み合わせが単に使用されます。IKE のフェーズ 2 がネゴシエートされると、構成されたローカルおよびリモートのプロキシー ID と実際に受信したものが各端で比較されます。
トラフィック セレクター
プロキシー ID は、ルートベースとポリシーベースの両方の VPN でサポートされます。ただし、マルチプロキシー ID はルートベース VPN のみでサポートされます。マルチプロキシー ID は、トラフィック セレクターとも呼ばれます。トラフィック セレクターとは、トラフィックが指定されたローカル アドレスとリモート アドレスのペアに一致する場合に、トンネルを介したトラフィックを許可するという IKE ピア間の合意です。特定のルートベース VPN 内でトラフィック セレクターを定義すると、複数のフェーズ 2 IPsec SA が生成されることがあります。トラフィック セレクターに適合したトラフィックのみが SA を介して許可されます。トラフィック セレクターは、リモート ゲートウェイ デバイスがジュニパーネットワークス以外のデバイスである場合によく必要とされます。
ネットワーク アドレス変換トラバーサル（NAT-T）
ネットワーク アドレス変換トラバーサル（NAT-T）とは、IPsec で保護されたデータがアドレス変換のために NAT デバイスを通過する際に発生する IP アドレス変換の問題を回避するための手法です。
NAT の機能である IP アドレッシングの変更があった場合、IKE はパケットを破棄します。NAT-T は、フェーズ 1 交換時にデータ パスに沿って 1 つ以上の NAT デバイスを検出した後、IPsec パケットにユーザー・データグラム・プロトコル（UDP）カプセル化のレイヤーを追加し、アドレス変換後のパケットが廃棄されないようにします。NAT-T は、IKE と ESP の両方のトラフィックを UDP 内でカプセル化し、ポート 4500 を送信元と宛先の両方のポートとして使用します。NAT デバイスは古くなった UDP 変換を期限切れにするため、ピア間でキープアライブ メッセージが必要になります。
NAT デバイスの位置は、以下のようにできます。
IKEv1 または IKEv2 開始側のみが NAT デバイスの背後にあります。複数の開始側を別個の NAT デバイスの背後に置くことができます。開始側は、複数の NAT デバイスを介して応答側に接続することもできます。
IKEv1 または IKEv2 応答側のみが NAT デバイスの背後にあります。
IKEv1 または IKEv2 開始側と応答側の両方が NAT デバイスの後ろにあります。
スイート B と PRIME 暗号スイート
スイート B とは、米国国家安全保障局（NSA）が指定した暗号アルゴリズムのセットで、商用製品でも機密や極秘に分類されたトラフィックを保護することが可能です。スイート B プロトコルは、RFC 6379 IPsec 向けのスイート B 暗号スイートで定義されています。スイート B 暗号スイートは、カプセル化セキュリティペイロード（ESP）の完全性と機密性を提供するもので、ESP の完全性保護と暗号化の両方が必要な場合に使用されます。英国の Public Sector 向けに定義された IPsec プロファイルである IP モジュラー暗号化向けのプロトコル要件（PRIME）は、スイート B 暗号スイートをベースにしていますが、IKEv2 ネゴシエーションには AES-CBC ではなく AES-GCM を使用します。
以下の暗号スイートに対応しています。
Suite-B-GCM-128
ESP：ガロア カウンター モード（GCM）での 128 ビット鍵および 16 オクテット完全性チェック値（ICV）による高度暗号化標準（AES）暗号化
IKE：暗号ブロック連鎖（CBC）モードでの 128 ビット鍵による AES 暗号化、SHA-256 認証を使用した完全性、Diffie-Hellman（DH）グループ 19 を使用した鍵確立、楕円曲線デジタル署名アルゴリズム（ECDSA）256 ビット楕円曲線署名を使用した認証。
Suite-B-GCM-256
ESP：GCM における ESP 向けの 256 ビット鍵および 16 オクテット ICV を使用した AES 暗号化。
IKE：CBC モードでの 256 ビット鍵による AES 暗号化、SHA-384 認証を使用した完全性、DH グループ 20 を使用した鍵確立、ECDSA 384 ビット楕円曲線署名を使用した認証。
PRIME-128
ESP：GCMでの 128 ビット鍵と 16 オクテット ICV による AES 暗号化。
IKE：GCM での 128 ビット鍵による AES 暗号化、DH グループ 19 を使用した鍵確立、ECDSA 256 ビット楕円曲線署名を使用した認証。
PRIME-256
ESP：GCM における ESP 向けの 256 ビット鍵および 16 オクテット ICV を使用した AES 暗号化。
IKE：GCM での 256 ビット鍵による AES 暗号化、DH グループ 20 を使用した鍵確立、ECDSA 384 ビット楕円曲線署名を使用した認証。
Suite-B 暗号スイートは IKEv1 および IKEv2 に対応しています。PRIME 暗号スイートは IKEv2 のみに対応しています。