Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

IPsecの基本

このトピックでは、IPsec鍵管理、セキュリティプロトコル、トンネルネゴシエーション、IPsecおよびIKE標準について説明します。

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

プラットフォームに関連する注意事項については、「 プラットフォーム固有のIPsecトンネル動作」 セクションを参照してください。

詳細については、「 補足プラットフォーム情報 」セクションを参照してください。

IPsecの概要

IPsecは、IPパケット層での通信を暗号で保護するための関連プロトコルのスイートです。IPsec は、SA(セキュリティ アソシエーション)の手動および自動ネゴシエーションと鍵配布のための方法を提供します。解釈の領域(DOI)は、関連するすべての属性を収集します。IPsec DOIは、VPNトンネルネゴシエーションを成功させるために必要なすべてのセキュリティパラメーター(基本的にはSAおよびIKEネゴシエーションに必要なすべての属性)を定義するドキュメントです。詳細については、RFC 2407 および RFC 2408 を参照してください。

IPsecセキュリティサービスを使用するには、ホスト間でSAを作成します。SA は、2 つのホストが IPsec を使用して安全に相互に通信できるようにするシンプレックス接続です。IPsecは、手動と動的の2種類のSAをサポートします。

IPsec は、2 つのセキュリティ モード(トランスポート モードとトンネル モード)をサポートします。

セキュリティ アソシエーション

SA(セキュリティ アソシエーション)は、通信チャネルの保護に使用する方法とパラメーターに関する、VPN 参加者間の一方向契約です。完全な双方向通信を行うには、各方向に 1 つずつ、少なくとも 2 つの SA が必要です。SA を通じて、IPsec トンネルは以下のセキュリティ機能を提供できます。

  • プライバシー(暗号化を使用)

  • コンテンツの整合性(データ認証を使用)

  • 送信者認証と(証明書を使用する場合は)否認防止(データ送信元認証を使用)

採用するセキュリティ機能は、ニーズによって異なります。IP パケットの送信元とコンテンツの整合性のみを認証する必要がある場合は、暗号化を適用せずにパケットを認証できます。一方、プライバシーの維持のみに関心がある場合は、認証メカニズムを適用せずにパケットを暗号化することができます。オプションで、パケットを暗号化して認証することもできます。多くのネットワークセキュリティ設計者は、VPNトラフィックを暗号化し、認証し、リプレイして保護することを選択します。

IPsec トンネルは、一方向の SA のペア(トンネルの各方向に 1 つの SA)で構成されます。トンネルの方向ごとに 1 つの SA があります。SAは、SPI(セキュリティパラメーターインデックス)、宛先IPアドレス、AH(認証ヘッダー)やESP(Encapsulating セキュリティ ペイロード)などのセキュリティプロトコルを指定します。SA は、通信を保護するために以下のコンポーネントをグループ化します。

  • セキュリティアルゴリズムと鍵。

  • プロトコル モード(トランスポートまたはトンネル)。Junos OSデバイスは常にトンネルモードを使用します。 トンネルモードでのパケット処理を参照してください。

  • 鍵管理方法(手動鍵または AutoKey IKE)

  • SA ライフタイム。

インバウンド トラフィックの場合、Junos OS は以下の 3 つで SA を検索します。

  • 宛先IPアドレス。

  • セキュリティ プロトコル(AH または ESP)

  • SPI値。

アウトバウンド VPN トラフィックの場合、ポリシーは VPN トンネルに関連付けられた SA を呼び出します。

IPsec 鍵管理

VPN を正常に使用するには、鍵の配布と管理が不可欠です。フェーズ1およびフェーズ2のプロポーザル設定中に、キー作成メカニズム(認証方法とも呼ばれます)を選択できます。 「Internet Key Exchange」を参照してください。IPsec VPNは、以下のキー作成方法をサポートしています。

オートキー IKE

多数のトンネルを作成して管理する必要がある場合は、すべての要素を手動で設定しない方法が必要になります。IPsec は、Internet Key Exchange(IKE)プロトコルを使用した、鍵と SA の自動生成とネゴシエーションをサポートします。Junos OSでは、このような自動化されたトンネルネゴシエーションをAutoKey IKEと呼び、事前共有鍵を使用したAutoKey IKEと証明書を使用したAutoKey IKEをサポートします。

  • 事前共有鍵を使用した AutoKey IKE—事前共有鍵(PSK)を備えた AutoKey IKE を使用して、IKE セッションの参加者を認証する場合、各側は事前に PSK を設定し、安全に交換する必要があります。この点では、安全な鍵配布の問題は、手動鍵の場合と同様です。ただし、手動鍵とは異なり、AutoKey は一度配布されると、IKE プロトコルを使用して、あらかじめ決められた間隔で鍵を自動的に変更できます。頻繁に鍵が変更されることでセキュリティが大幅に向上し、変更が自動的に行われることで鍵管理の責任を大幅に削減できます。ただし、鍵を変更するとトラフィックのオーバーヘッドが増加します。そのため、キーを頻繁に変更すると、データ転送効率が低下する可能性があります。

    PSK は、暗号化と復号化の両方の鍵であり、両方の参加者が通信を開始する前にこれを持っている必要があります。

  • 証明書付き AutoKey IKE—AutoKey IKE ネゴシエーション中に証明書を使用して参加者を認証する場合、各側がパブリック プライベート キーペアを生成し、証明書を取得します。双方が発行認証機関(CA)を信頼する限り、参加者はピアの公開キーを取得し、ピアの署名を検証できます。キーと SA を追跡する必要はありません。IKEはそれを自動的に実行します。

Diffie-Hellman 交換

DH(Diffie-Hellman)交換により、参加者は共有の秘密値を生成できます。この手法の利点は、参加者が、通信を通して秘密値を渡さずに、安全でないメディアを介して秘密値を作成できることです。各グループの計算で使用される主な係数のサイズは、以下の表に示すように異なります。デバイスは、ソフトウェアまたはハードウェアのいずれかでDH交換操作を実行します。次の 表1 は、さまざまなDiffie Hellman(DH)グループをリストアップし、そのグループに対して実行される操作がハードウェアまたはソフトウェアのどちらにあるかを示しています。

表1:Diffie Hellman(DH)グループとその交換操作

Diffie-Hellman(DH)グループ

プライムモジュールサイズ

DHグループ1

768ビット

DHグループ2

102ビット

DHグループ5

1536ビット

DHグループ14

2048ビット

DHグループ15

3072ビット

DHグループ16

4096ビット

DHグループ19

256ビット楕円曲線

DHグループ20

384ビット楕円曲線

DHグループ21

521ビット楕円曲線

DHグループ24

2048ビットと256ビットプライム次数サブグループ

DH グループ 1、2、5 の使用は推奨されません。

各 DH グループの係数のサイズは異なるため、参加者は同じグループを使用することに同意する必要があります。

IPsec セキュリティ プロトコル

IPsec は 2 つのプロトコルを使用して、IP レイヤーでの通信を保護します。

  • AH(認証ヘッダー)—IP パケットの送信元を認証し、その内容の整合性を検証するためのセキュリティ プロトコル

  • カプセル化セキュリティペイロード(ESP)—IPパケット全体を暗号化し、その内容を認証するためのセキュリティプロトコル

セキュリティプロトコル( authentication and encryption algorithmsとも呼ばれます)は、フェーズ2のプロポーザル設定時に選択できます。 「Internet Key Exchange」を参照してください。

各 VPN トンネルでは、SPU(サービス処理ユニット)とコントロール プレーンに AH および ESP トンネル セッションの両方がインストールされます。ネゴシエーションが完了すると、デバイスはネゴシエートされたプロトコルでトンネルセッションを更新します。 show security flow session および show security flow cp-session 動作モードコマンドは、ESPおよびAHトンネルセッションの詳細を表示します。

このトピックでは、次のセクションについて説明します。

IPsec認証アルゴリズム(AHプロトコル)

AH(認証ヘッダー)プロトコルは、パケットの内容と送信元の信頼性と整合性を検証する手段を提供します。パケットは、秘密鍵とMD5またはSHAハッシュ関数を使用し、HMAC(ハッシュメッセージ認証コード)を介して計算されたチェックサムで認証できます。

  • MD5(メッセージダイジェスト5)—任意の長さのメッセージと16バイトの鍵から、128ビットのハッシュ( デジタル署名 または メッセージダイジェストとも呼ばれます)を生成するアルゴリズム。結果として得られるハッシュは、入力のフィンガープリントと同様に、内容とソースの信頼性と整合性を検証するために使用されます。

  • Secure Hash Algorithm(SHA)—任意の長さのメッセージと 20 バイトの鍵から 160 ビットのハッシュを生成するアルゴリズム。SHA は、生成するハッシュが大きいため、MD5 よりも安全です。ASICが計算処理を実行するため、パフォーマンスのコストは無視できません。

MD5 と SHA-1 の使用は推奨されません。

MD5 ハッシュ アルゴリズムの詳細については、RFC 1321 および RFC 2403 を参照してください。SHA ハッシュ アルゴリズムの詳細については、RFC 2404 を参照してください。HMAC の詳細については、RFC 2104 を参照してください。

IPsec暗号化アルゴリズム(ESPプロトコル)

ESP プロトコルは、プライバシー (暗号化)、送信元認証およびコンテンツの整合性 (認証) を保証する手段を提供します。トンネル モードの ESP は、IP パケット全体(ヘッダーとペイロード)をカプセル化し、新しい IP ヘッダーを暗号化済みのパケットに追加します。この新しいIPヘッダーには、保護されたデータをネットワーク経由でルーティングするために必要な宛先アドレスが含まれています。 トンネルモードでのパケット処理を参照してください。

ESP を使用すると、暗号化と認証の両方、暗号化のみ、または認証のみのいずれかを選択できます。暗号化には、以下の暗号化アルゴリズムのいずれかを選択できます。

  • DES(Data Encryption Standard)—56 ビット鍵を使用した暗号ブロック アルゴリズム。

  • トリプル DES(3DES)—168 ビット鍵を使用して、元の DES アルゴリズムが 3 つのラウンドで適用される、DES のより強力なバージョン。DES はパフォーマンスを大幅に節約しますが、多くの機密性の高いデータの転送では容認できません。

  • AES(Advanced Encryption Standard)—他のデバイスとの優れた相互運用性を提供する暗号化標準。Junos OSは、128ビット、192ビット、256ビットの各鍵でAESをサポートしています。

  • ChaCha20-Poly1305 Authenticated Encryption with Associated Data—Poly1305認証器を使用したAuthenticated Encryption with Associated Data(AEAD)をサポートするChaCha20ストリーム暗号。

DES と 3DES の使用は推奨されません。

暗号化に NULL を選択することもできますが、このような状況下では IPsec が攻撃に対して脆弱になる可能性があることが研究で示されています。そのため、最大限のセキュリティを実現する暗号化アルゴリズムを選択することをお勧めします。

IPsecトンネルネゴシエーション

次の 2 つの異なるモードによって、VPN によるトラフィックの交換方法が決まります。

  • トンネルモード—元のIPパケットをVPNトンネル内の別のパケット内にカプセル化して、トラフィックを保護します。このモードでは、IKEとの事前共有キーを使用してピアを認証するか、IKEでデジタル証明書を使用してピアを認証します。トンネルモードは、別のプライベートネットワーク内のホストがパブリックネットワークを介して通信したい場合に最も一般的に使用されます。VPNクライアントとVPNゲートウェイはどちらも、トンネルモードを使用して、非IPsecシステムとの間で送受信される通信を保護します。

  • トランスポートモード—IPsecトンネルを確立した2つのホスト間でパケットを直接送信して、トラフィックを保護します。つまり、通信エンドポイントと暗号化エンドポイントが同じ場合です。このモードでは、暗号化メカニズムによりIPパケットのデータ部分が保護されますが、IPヘッダーは暗号化されていないままです。保護されたホストに暗号化および復号化サービスを提供するVPNゲートウェイは、保護されたVPN通信にトランスポートモードを使用できません。パケットが傍受された場合、送信元または宛先のIPアドレスを変更できます。トランスポートモードは、その構造上、通信エンドポイントと暗号化エンドポイントが同じ場合にのみ使用できます。

サポートされているIPsecおよびIKE標準

1 つ以上の MS-MPC、MS-MIC、または DPC を装備したルーターでは、カナダおよび米国バージョンの Junos OS は、IPsec(IP セキュリティ)および IKE(Internet Key Exchange)の標準を定義する以下の RFC を実質的にサポートしています。

  • RFC 2085、 HMAC-MD5 IP 認証(リプレイ防御機能付き)

  • RFC 2401、 インターネットプロトコルのセキュリティアーキテクチャ (RFC 4301に置き換え)

  • RFC 2402、 IP認証ヘッダー (RFC 4302に置き換え)

  • RFC 2403、 ESPおよびAH内でのHMAC-MD5-96の使用

  • RFC 2404、 ESPおよびAH内でのHMAC-SHA-1-96の使用 (RFC 4305に置き換え)

  • RFC 2405、 明示的なIVを使用したESP DES-CBC暗号アルゴリズム

  • RFC 2406、 IPカプセル化セキュリティペイロード(ESP)( RFC 4303およびRFC 4305に置き換え)

  • RFC 2407、 ISAKMPの解釈のインターネットIPセキュリティドメイン (RFC 4306に置き換え)

  • RFC 2408、 インターネットセキュリティアソシエーションおよびキー管理プロトコル(ISAKMP)( RFC 4306 に置き換え)

  • RFC 2409、 The Internet Key Exchange (IKE)( RFC 4306 に置き換え)

  • RFC 2410、 NULL暗号化アルゴリズムとそのIPsecでの使用

  • RFC 2451、 ESP CBCモード暗号アルゴリズム

  • RFC 2560、 X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP

  • RFC 3193、 IPsecを使用したL2TPの保護

  • RFC 3280、 インターネットX.509公開キーインフラストラクチャ証明書および証明書失効リスト(CRL)プロファイル

  • RFC 3602、 AES-CBC暗号アルゴリズムとそのIPsecでの使用

  • RFC 3948、 IPsec ESPパケットのUDPカプセル化

  • RFC 4106、 IPsecカプセル化セキュリティペイロード(ESP)におけるガロア/カウンターモード(GCM)の使用

  • RFC 4210、 インターネットX.509公開キーインフラストラクチャ証明書管理プロトコル(CMP)

  • RFC 4211、 インターネットX.509公開鍵インフラストラクチャ証明書要求メッセージ形式(CRMF)

  • RFC 4301、 インターネットプロトコルのセキュリティアーキテクチャ

  • RFC 4302、 IP認証ヘッダー

  • RFC 4303、 IPカプセル化セキュリティペイロード(ESP)

  • RFC 4305、セキュリティペイ ロード(ESP)と認証ヘッダー(AH)をカプセル化するための暗号アルゴリズム実装要件

  • RFC 4306、 Internet Key Exchange(IKEv2)プロトコル

  • RFC 4307、 IKEv2(Internet Key Exchange Version 2)で使用するための暗号アルゴリズム

  • RFC 4308、 IPsec用暗号スイート

    Junos OS では、Suite VPN-A のみがサポートされています。

  • RFC 4754、 楕円曲線デジタル署名アルゴリズム(ECDSA)を使用したIKEおよびIKEv2認証

  • RFC 4835、セキュリティペイ ロード(ESP)および認証ヘッダー(AH)をカプセル化するための暗号アルゴリズム実装要件

  • RFC 5996、 Internet Key Exchange Protocol Version 2(IKEv2)( RFC 7296 に置き換え)

  • RFC 7296、 Internet Key Exchange Protocol バージョン 2(IKEv2)

  • RFC 7427、 Internet Key Exchange Version 2(IKEv2)での署名認証

  • RFC 7634、 ChaCha20、Poly1305、および Internet Key Exchange Protocol(IKE)および IPsec でのそれらの使用

  • RFC 8200、 インターネットプロトコル、バージョン6(IPv6)仕様

Junos OS は、IPsec と IKE に関する以下の RFC を部分的にサポートしています。

  • RFC 3526、 Internet Key Exchange(IKE)用のMore Modular Exponential(MODP)Diffie-Hellmanグループ

  • RFC 5114、 IETF標準で使用するための追加のDiffie-Hellmanグループ

  • RFC 5903、 IKEおよびIKEv2の楕円曲線グループモジュロAプライム(ECPグループ)

以下の RFC およびインターネット ドラフトでは、標準は定義されていませんが、IPsec、IKE、関連技術に関する情報が提供されています。IETF は、これらを「情報」として分類しています。

  • RFC 2104、 HMAC:メッセージ認証用のキーハッシュ

  • RFC 2412、 OAKLEY鍵決定プロトコル

  • RFC 3706、 デッドなInternet Key Exchange(IKE)ピアを検出するトラフィックベースの方法

  • インターネットドラフトdraft-eastlake-sha2-02.txt、 米国セキュアハッシュアルゴリズム(SHAおよびHMAC-SHA)( 2006年7月失効)

関連項目

プラットフォーム固有のIPsecトンネルの動作

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

お使いのプラットフォーム固有の動作を確認するには、以下の表を使用して下さい。

表2:プラットフォーム固有の動作

プラットフォーム

違い

SRXシリーズ

  • IPsec VPNをサポートするSRX5400、SRX5600、SRX5800デバイスの場合:

    • Junos OSは、アンカーSPUのトンネルセッション用にネゴシエートされたプロトコルを更新します。

    • 非アンカーSPUは、ESPおよびAHトンネルセッションを保持します。

補足プラットフォーム情報

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。追加のプラットフォームがサポートされる場合があります。

表3:補足プラットフォーム情報

機能

SRX300 SRX320 SRX340 SRX345SRX380

SRX400SRX440SRX440-2AC

SRX1500 SRX1600

SRX2300 SRX4120 SRX4100SRX4200SRX4300 SRX4600SRX4700

SRX5400 SRX5600 SRX5800

vSRX仮想ファイアウォール

DH グループ 15、16、21 のサポート

いいえ

はい

はい

はい

はい

vSRX 3.0( junos-ike パッケージ付き)の場合

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
24.2R1
Junos OS リリース 24.2R1 の SRX1600、SRX2300、SRX4300、SRX4600、SRX5400、SRX5600、SRX5800、および vSRX 3.0 に追加された ChaCha20-Poly1305 アルゴリズムのサポート。
20.3R1
Junos OSリリース20.3R1以降、vSRX仮想ファイアウォールはDHグループ15、16、21をサポートしています。
19.1R1
Junos OSリリース19.1R1以降、SRXシリーズファイアウォールはDHグループ15、16、21をサポートしています。