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

IKEプロポーザルの認証アルゴリズムを設定するには、 階層レベルで ステートメントを含め authentication-algorithm ます [edit services ipsec-vpn ike proposal proposal-name] 。

認証アルゴリズムは、以下のいずれかです。

• md5- 128 ビットのダイジェストを生成します。

• sha1- 160 ビットのダイジェストを生成します。

• sha-256- 256 ビットのダイジェストを生成します。

  メモ：

  セキュア ハッシュ アルゴリズム (SHA) のリファレンス情報については、インターネット ドラフト draft-eastlake-sha2-02.txtのセキュア ハッシュ アルゴリズム (SHA および HMAC-SHA) ( 2006 年 7 月に終了) を参照してください。

IKEプロポーザルの認証方法を設定するには、 階層レベルで ステートメントを含め authentication-method ます [edit services ipsec-vpn ike proposal proposal-name] 。

メモ：

IKEv1 では、SA の認証方法は、IKE プロポーザルで構成された認証方法の種類に基づいて、リモート ピアとネゴシエートされます。IKEv2 では、このようなネゴシエーションはリモート ピアとは実行されません。代わりに、各IKEピアはローカルで設定されている認証方法を使用します。

IKEv2 の SA では、IKEプロポーザルで認証方法が構成されていない場合、認証方法はデフォルト値の IKEv1 になります。IKEv2 の認証方法を設定する場合は、ポリシーで参照されるすべてのプロポーザルに同じ認証方法を構成しておく必要があります。

認証方法は以下のいずれかです。

メモ：

Junos FIPSモードでは、Junos OSリリース17.3R1の認証方法にECDSAはサポートされていません。Junos OS Release 17.4R1以降、ECDSAはJunos FIPSモードでサポートされます。

• ecdsa-signatures-256- Junos OSリリース17.3R1以降、MS-MPCおよびMS-MIC向けに、256ビットモジュライ用の楕円曲線デジタル署名アルゴリズム(ECDSA)。

• ecdsa-signatures-384—Junos OSリリース17.3R1以降、MS-MPCおよびMS-MIC向け、384ビットモジュール用の楕円曲線デジタル署名アルゴリズム(ECDSA)。

• pre-shared-keys- 帯域外メカニズムから派生したキー。キーは交換を認証します。

• rsa-signatures- 公開キー アルゴリズム(暗号化とデジタル署名をサポート)。

Diffie-Hellman は、2 つの当事者が安全でない通信チャネルを介して共有シークレットを確立できるようにする公開キー暗号化スキームです。また、IKE 内でセッション キーを確立するためにも使用されます。

IKEプロポーザルにDiffie-Hellmanグループを設定するには、 階層レベルで ステートメントを含め dh-group ます [edit services ipsec-vpn ike proposal proposal-name] 。

グループは以下のいずれかになります。

• group1- IKE が新しい Diffie-Hellman 交換を実行する際に、768 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group2- IKE が新しい Diffie-Hellman 交換を実行する際に、1024 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group5- IKE が新しい Diffie-Hellman 交換を実行する際に、1536 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group14- IKE が新しい Diffie-Hellman 交換を実行する際に、2048 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group19- IKE が新しい Diffie-Hellman 交換を実行する際に、256 ビットのランダムな楕円曲線Diffie-Hellman グループを使用することを指定します。

• group20—-IKE が新しい Diffie-Hellman 交換を実行する際に、384 ビットのランダム楕円曲線Diffie-Hellman グループを使用することを指定します。

Junos OS リリース 17.4R1 以降では、グループ15、グループ 16、グループ 24 も使用できます。

• group15- IKE が新しい Diffie-Hellman 交換を実行する際に、3072 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group16- IKE が新しい Diffie-Hellman 交換を実行する際に、4096 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group24- IKE が新しい Diffie-Hellman 交換を実行するときに、256 ビットの素数サブグループで 2048 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

より多くのビットに基づいて Diffie-Hellman グループを使用すると、より少ないビットに基づいてグループを使用する場合よりも、より安全な IKE トンネルが得られます。ただし、この追加のセキュリティには、追加の処理時間が必要になる場合があります。

IKEプロポーザルの暗号化アルゴリズムを設定するには、 階層レベルで ステートメントを含め encryption-algorithm ます [edit services ipsec-vpn ike proposal proposal-name] 。

暗号化アルゴリズムは、以下のいずれかです。

• 3des-cbc- 鍵サイズ 24 バイトの暗号ブロック連鎖暗号化アルゴリズム。そのキー サイズは 192 ビット長です。

• des-cbc- 鍵サイズ8バイトの暗号ブロック連鎖暗号化アルゴリズム。そのキー サイズは 56 ビット長です。

• aes-128-cbc- 高度暗号化標準(AES)128ビット暗号化アルゴリズム。

• aes-192-cbc- 高度暗号化標準(AES)192ビット暗号化アルゴリズム。

• aes-256-cbc- 高度暗号化標準(AES)256ビット暗号化アルゴリズム。

メモ：

データ暗号化標準 (DES) 暗号化アルゴリズムの脆弱鍵および半鍵のリストについては、RFC 2409 、 インターネット鍵交換 (IKE) を参照してください。AES 暗号化アルゴリズムは、スループットがはるかに低いソフトウェア実装を使用するため、DES は引き続き推奨されるオプションです。

の場合 3des-cbc、最初の 8 バイトは 2 番目の 8 バイトと異なり、2 番目の 8 バイトは 3 番目の 8 バイトと同じである必要があります。

認証プロポーザルを設定しても、 ステートメントを含めない場合、encryptionNULL 暗号化が生成されます。特定のアプリケーションでは、この結果が予想されます。特定の認証値または暗号化値を設定しない場合、Junos OSは、認証と3des-cbc暗号化に のsha1デフォルト値を使用します。

ステートメントは lifetime-seconds 、IKE SAのライフタイムを設定します。IKE SA の有効期限が切れると、新しい SA(および SPI)に置き換えられるか、IPsec 接続が終了します。

IKE SAのライフタイムを構成するには、 ステートメントを [edit services ipsec-vpn ike proposal proposal-name] 階層レベルで記述しますlifetime-seconds。

デフォルトでは、IKE SAのライフタイムは3600秒です。範囲は 180 から 86,400 秒からです。

メモ：

IKEv1 では、SA のライフタイムは、IKE プロポーザルで設定されたライフタイムのタイプに基づいて、リモート ピアとネゴシエートされます。IKEv2 では、このようなネゴシエーションはリモート ピアとは実行されません。代わりに、各IKEピアはローカルに設定されているライフタイムを使用します。

IKEv2 の SA の場合、ライフタイムはデフォルト値の IKEv1 になるか(IKE プロポーザルで別のライフタイムが設定されていない場合)、IKE ポリシー内のすべての IKEv2 プロポーザルを同じライフタイム値で構成する必要があります。

メモ：

IKEプロポーザルの場合、Junos OSによって指定されたSAライフタイム値は1つだけです。 IPsecプロポーザルは、異なるメカニズムを使用します。

IKEプロポーザルを設定します。

Junos OSリリース11.4以降、IKEv1とIKEv2の両方が、すべてのM Series、MXシリーズ、T Seriesルーターでデフォルトでサポートされています。ネゴシエーションでサポートされる特定の IKE フェーズを設定できます。ただし、IKEv1 のみがサポートされている場合、Junos OS は IKEv2 ネゴシエーションを拒否します。同様に、IKEv2 のみがサポートされている場合、Junos OS はすべての IKEv1 ネゴシエーションを拒否します。

使用するIKEフェーズを設定するには、 階層レベルで ステートメントを含め version ます [edit services ipsec-vpn ike policy policy-name] 。

IKE ポリシーには、アグレッシブとメインの 2 つのモードがあります。デフォルトでは、メインモードは有効になっています。メイン モードでは、3 つの交換で 6 つのメッセージを使用して IKE SA を確立します。(これらの 3 つのステップは、IKE SA ネゴシエーション、Diffie-Hellman 交換、ピアの認証です)。メインモードでは、ピアがそのIDを隠すこともできます。

アグレッシブ モードでは、認証されたIKE SA と鍵も確立されます。ただし、アグレッシブ モードでは、半分のメッセージを使用し、ネゴシエーション能力が低く、ID 保護は提供されません。ピアは、アグレッシブ モードまたはメイン モードを使用して IKE ネゴシエーションを開始できます。リモートピアは、ピアから送信されたモードを受け入れます。

メモ：

モード設定は、 オプションが 1に設定されている場合にのみversion必要です。

IKEポリシーのモードを設定するには、 ステートメントを含めmode、 階層レベルで または main [edit services ipsec-vpn ike policy policy-name] を指定しますaggressive。

IKEポリシーには、IKEポリシーに関連付けられた1つ以上のプロポーザルのリストが含まれます。

IKEポリシーにプロポーザルを設定するには、 ステートメントを含め proposals 、階層レベルで1つ以上のプロポーザル名 [edit services ipsec-vpn ike policy policy-name] を指定します。

階層レベルで ステートメント[edit services ipsec-vpn ike proposal proposal-name]を含めるauthentication-method pre-shared-keysと、IKEポリシーの事前共有鍵がピアを認証します。事前共有キーは、ピアのキーと一致する必要があります。事前共有鍵には、ASCII テキスト(英数字)鍵または 16 進数鍵を使用できます。

IKEポリシーで事前共有キーを設定するには、 階層レベルで ステートメントとキーを含め pre-shared-key ます [edit services ipsec-vpn ike policy policy-name] 。

キーは次のいずれかです。

• ascii-text- ASCII テキスト キー。 des-cbc このオプションでは、キーには 8 文字の ASCII 文字が含まれます。 3des-cbc このオプションを使用すると、キーに 24 文字の ASCII 文字が含まれます。

• hexadecimal- 16 進数のキー。 des-cbc このオプションを使用すると、キーに 16 個の 16 進文字が含まれます。 3des-cbc このオプションを使用すると、キーには 48 個の 16 進文字が含まれます。

IKEポリシーのオプションのテキスト記述を指定するには、 階層レベルで ステートメントを含め description ます [edit services ipsec-vpn ike policy policy-name 。

オプションで、IKE フェーズ 1 ネゴシエーションで使用するローカル ID を指定できます。ステートメントを local-id 省略すると、ローカルゲートウェイアドレスが使用されます。

Junos OS リリース 19.1R1 以降、ローカル ID タイプの 1 つを識別名として設定し、リモート ID タイプの 1 つを識別名として設定できます。識別名フィールドは、コンテナー文字列値を含むコンテナー、またはワイルドカード文字列値を持つワイルドカードにすることができます。

識別名は、ユーザーを一意的に識別するためにデジタル証明書で使用される名前です。たとえば、識別名は次のようになります。

• CN=ユーザー

• DC = 例

• DC=com

コンテナー・ストリングの場合、フィールドの順序とその値は、ピアのデジタル証明書の識別名と正確に一致する必要があります。例： container ["C=US, ST=CA, L=Sunnyvale, O=Juniper, CN=local_neg, CN=test@juniper.net, OU=QA" "cn=admin, ou=eng, o=example, dc=net" ];

ワイルドカード文字列の場合、設定されたフィールドと値はピアのデジタル証明書の識別名と一致する必要がありますが、DNのフィールドの順序は関係ありません。例： wildcard [ "L=Sunnyvale, O=Juniper" "C=US, ST=CA" ];

1 つ以上のローカル ID を指定するには、 階層レベルで ステートメントを含め local-id ます [edit services ipsec-vpn ike policy policy-name] 。

IKEポリシーを使用するリモートゲートウェイ識別子を指定することもできます。このポリシーが定義されているリモートゲートウェイアドレスは、デフォルトで追加されます。

1 つ以上のリモート ID を指定するには、 階層レベルで ステートメントを含め remote-id ます [edit services ipsec-vpn ike policy policy-name] 。

オプションは any-remote-id 、任意のリモートアドレスの接続を許可します。このオプションは、動的エンドポイント構成でのみサポートされており、特定の値と共に構成することはできません。

SA(セキュリティ アソシエーション)のピアが同期しなくなると、無効なセキュリティ パラメーター インデックス(SPI)値を持つパケットが送信され、受信ピアはこれらのパケットをドロップします。たとえば、ピアの 1 つが再起動したときに発生する可能性があります。Junos OS リリース 14.2 以降では、SA を再同期することで、無効な SPI のパケットを受信したときにデバイスを回復できます。

無効な SPI 値からのリカバリーを有効にするには、 階層レベルで ステートメントを含め respond-bad-spi ます [edit services ipsec-vpn ike policy] policy-name 。

と の 2 つの IKE ポリシーを定義します。 policy 10.1.1.2 policy 10.1.1.1各ポリシーは、 と proposal-2に関連付けられていますproposal-1。以下の構成では、ネゴシエーションに IKEv1 のみを使用します。

メモ：

現在の IKE プロポーザルとポリシー構成に対する更新は、現在の IKE SA には適用されません。更新は新しいIKE SAに適用されます。

新しい更新を直ちに有効にするには、既存の IKE セキュリティ アソシエーションをクリアして、変更された構成で再確立されるようにする必要があります。現在の IKE セキュリティ アソシエーションをクリアする方法については、次を参照してください:クリア サービス ipsec-vpn IKE セキュリティアソシエーション。

IPsecプロポーザルの認証アルゴリズムを設定するには、 階層レベルで ステートメントを含め authentication-algorithm ます [edit services ipsec-vpn ipsec proposal proposal-name] 。

認証アルゴリズムは、以下のいずれかです。

• hmac-md5-96- パケット データを認証するハッシュ アルゴリズム。128 ビットのダイジェストが生成されます。認証に使用されるのは 96 ビットのみです。

• hmac-sha1-96- パケット データを認証するハッシュ アルゴリズム。160 ビットのダイジェストが生成されます。認証に使用されるのは 96 ビットのみです。

• hmac-sha-256-128- パケット データを認証するハッシュ アルゴリズム。256 ビットの認証子値を生成します。

メモ：

IPsecプロポーザルで認証アルゴリズムを設定する際は、以下の点に注意してください。

• IPsec VPN トンネルの両端に同じ IKE プロポーザルがあり、IPsec プロポーザルが異なる場合、エラーが発生し、このシナリオではトンネルが確立されません。例えば、トンネルの一方の端にhmac-sha- 256-128として認証アルゴリズムで設定されたルーター1が含まれ、トンネルの他方の端にhmac-md5-96として認証アルゴリズムで設定されたルーター2が含まれる場合、VPNトンネルは確立されません。

• IPsec VPN トンネルの両端に同じ IKE プロポーザルがあり、IPsec プロポーザルが異なる場合、トンネルの一方の端に、安全性の低いアルゴリズムが選択されていないかチェックするための 2 つの IPsec プロポーザルが含まれている場合、エラーが発生し、トンネルは確立されません。例えば、トンネルの一方の端(ルーター1)でIPsecプロポーザルの2つの認証アルゴリズムをhmac-sha-256-128とhmac-md5-96として設定し、トンネルのもう一方の端(ルーター2)でIPsecプロポーザルのアルゴリズムをhmac-md5-96として設定した場合、トンネルは確立されず、プロポーザルの数が一致しません。

• トンネルの両端に 2 つの IPsec プロポーザルを設定する場合、例えば、authentication-algorithm hmac-sha-256-128authentication- algorithm hmac-md5-96トンネルの一方の階層レベルにある [edit services ipsec-vpn ipsec proposal proposal-name] と のステートメント、ルーター 1(順序を指定するために連続する 2 つのステートメントにアルゴリズムを使用)、authentication-algorithm hmac-md5-96およびauthentication- algorithm hmac-sha-256-128トンネルの 1 つの階層レベルで と ステートメント[edit services ipsec-vpn ipsec proposal proposal-name]を設定すると、ルーター 2(順序を指定するために、 ルーター 1) の場合、プロポーザルの数が同じで、同じアルゴリズム セットが含まれているため、この組み合わせでトンネルが確立されます。ただし、選択された認証アルゴリズムは hmac-md5-96 であり、hmac-sha-256-128 のより強力なアルゴリズムではありません。このアルゴリズムの選択方法は、最初に一致するプロポーザルが選択されるために発生します。また、デフォルトプロポーザルでは、ルーターが高度暗号化標準(AES)暗号化アルゴリズムをサポートしているかどうかに関係なく、aes-cfbアルゴリズムではなく3des-cbcアルゴリズムが選択されます。これは、デフォルトプロポーザルの最初のアルゴリズムが選択されるためです。ここで説明するサンプル シナリオでは、ルーター 2 で、ルーター 1 で指定された順序と同じ順序になるようにプロポーザル内のアルゴリズム設定の順序を逆にすると、認証方法として hmac-sha-256-128 が選択されます。

• 2 つのピアの両方のポリシーにプロポーザルがある場合に、一致が行われたときに最も強いアルゴリズムが最初に考慮されるなど、プロポーザルのマッチングを特定の順序で行う場合は、設定時に IPsec ポリシーのプロポーザルの順序を認識しておく必要があります。

IPsecプロポーザルのオプションのテキスト記述を指定するには、 階層レベルで ステートメントを含め description ます [edit services ipsec-vpn ipsec proposal proposal-name] 。

IPsecプロポーザルの暗号化アルゴリズムを設定するには、 階層レベルで ステートメントを含め encryption-algorithm ます [edit services ipsec-vpn ipsec proposal proposal-name] 。

暗号化アルゴリズムは、以下のいずれかです。

• 3des-cbc- ブロック サイズが 24 バイトの暗号化アルゴリズム。そのキー サイズは 192 ビット長です。

• aes-128-cbc- 高度暗号化標準(AES)128ビット暗号化アルゴリズム。

• aes-192-cbc- 高度暗号化標準(AES)192ビット暗号化アルゴリズム。

• aes-256-cbc- 高度暗号化標準(AES)256ビット暗号化アルゴリズム。

メモ：

Junos FIPSモードでは、AES-GCMはJunos OSリリース17.3R1ではサポートされていません。Junos OS リリース 17.4R1 以降、AES-GCM は Junos FIPS モードでサポートされます。

• aes-128-gcm—Junos OSリリース17.3R1以降、MS-MPCおよびMS-MIC向け、ガロア/カウンターモードの高度暗号化規格(AES-GCM)128ビット暗号化アルゴリズム、16オクテット完全性チェック値(ICV)。

• aes-192-gcm- Junos OS リリース 17.3R1 以降、MS-MPC および MS-MIC 向けに、ガロア/カウンター モードの高度暗号化標準(AES-GCM)192 ビット暗号化アルゴリズム、16 オクテット完全性チェック値 ICV。

• aes-256-gcm—MS-MPCおよびMS-MIC向けのJunos OSリリース17.3R1以降、ガロア/カウンターモードの高度暗号化標準(AES-GCM)256ビット暗号化アルゴリズム、16オクテット完全性チェック値ICV。

• des-cbc- ブロック サイズが 8 バイトの暗号化アルゴリズム。そのキー サイズは 48 ビット長です。

メモ：

データ暗号化標準 (DES) 暗号化アルゴリズムの脆弱鍵および半鍵のリストについては、RFC 2409 、 インターネット鍵交換 (IKE) を参照してください。AES 暗号化アルゴリズムは、スループットがはるかに低いソフトウェア実装を使用するため、DES は引き続き推奨されるオプションです。

の場合 3des-cbc、最初の 8 バイトは 2 番目の 8 バイトと異なり、2 番目の 8 バイトは 3 番目の 8 バイトと同じである必要があります。

特定の認証または暗号化設定を行わない場合、Junos OSは、認証と3des-cbc暗号化にデフォルト値 を使用しますsha1。NULL 暗号化を有効にするには、他のシステム構成に関係なく、階層レベルで ステートメント[edit services ipsec-vpn ipsec proposal proposal-name]を含めてprotocol esp、NULL 暗号化アルゴリズムの ESP(カプセル化セキュリティ ペイロード)プロトコルを常に指定する必要があります。

動的IPsec SAを作成する際には、ハードとソフトの2種類のライフタイムが使用されます。ハードライフタイムは、SAのライフタイムを指定します。ハード ライフタイムから派生したソフト ライフタイムは、SA の有効期限が近づいていることを IPsec キー管理システムに通知します。これにより、鍵管理システムは、ハード ライフタイムが終了する前に新しい SA をネゴシエートすることができます。

メモ：

IKEv1 では、SA のライフタイムは、IPsec プロポーザルで設定されたライフタイムのタイプに基づいて、リモート ピアとネゴシエートされます。IKEv2 では、このようなネゴシエーションはリモート ピアとは実行されません。代わりに、各IKEピアはローカルに設定されているライフタイムを使用します。

IKEv2 の SA の場合、ライフタイムはデフォルト値の IKEv1 になるか(IPsec プロポーザルで別のライフタイムが設定されていない場合)、IPsec ポリシー内のすべての IKEv2 プロポーザルが同じライフタイム値で設定する必要があります。

ハードライフタイム値を設定するには、 ステートメントを含め lifetime-seconds 、 階層レベルで秒 [edit services ipsec-vpn ipsec proposal proposal-name] 数を指定します。

既定の有効期間は 28,800 秒です。範囲は 180 から 86,400 秒からです。

ソフトライフタイムを計算するには、最初にライフタイム差分を計算します。次に、ピアがイニシエーターかレスポンダかに基づいて、ソフトライフタイムが計算されます。

ライフタイム差分の計算は、次のように実行されます。

• (3*hard-lifetime)/10 が 850 秒より大きい場合、lifetime-diff = 850 秒 + 0 から 850 秒の間のジッター。

  メモ：

  ジッター値は、IPsec SAをインストールするたびに0から850まで増加し、0にリセットされます。

• (3*hard-lifetime)/10 が 600 秒より大きく 850 より小さい場合、lifetime-diff = 600 秒 + 0 から 45 秒の間のランダム ジッター。

• (3*hard-lifetime)/10 が 90 秒より大きく 600 より小さい場合、lifetime-diff = 90 秒 + 0 から 45 秒の間のランダム ジッター。

• (3*hard-lifetime)/10 が 90 秒未満の場合、lifetime-diff = 90 秒 + 0 から 10 秒の間のランダム ジッター。

ライフタイム差分に基づいて、ソフトライフタイムは以下のように計算されます。

• ライフタイム差分がハードライフタイムよりも大きい場合、ソフトライフタイム = (9*ハードライフタイム)/10

• イニシエータのソフトライフタイム = ハードライフタイム - ライフタイム差分

• レスポンダのソフトライフタイム = ハードライフタイム - ライフタイム差分 + 45秒

メモ：

イニシエータのソフトライフタイムは、常にレスポンダのソフトライフタイムより短くなります。これは、イニシエータのソフトライフタイムが最初に期限切れになり、キー更新プロセスを開始できるようにするためです。

例えば、IPSec SAのハードライフタイムが3600秒に設定されている場合:

• イニシエータの最大ソフト寿命:3600 - 850(ジッターは0)= 2750秒

• イニシエータの最小ソフト寿命:3600 - 850 - 850(ジッターは850に等しい)= 1900秒

• レスポンダの最大ソフト寿命は、3600 - 850(ジッターは0)+ 45 = 2795秒です。

• レスポンダの最小ソフト寿命:3600 - 850 - 850(ジッターは850に等しい)+ 45 = 1945秒

ステートメントは protocol 、動的SAのプロトコルを設定します。IPsec は、ESP と AH の 2 つのプロトコルを使用して IP トラフィックを保護します。ESP プロトコルは、認証、暗号化、またはその両方をサポートできます。強力な認証には、AH プロトコルが使用されます。AH は IP パケットも認証します。このオプションでは bundle 、AH 認証と ESP 暗号化を使用しますが、AH の方が IP パケットの認証を強化するため、ESP 認証は使用されません。

動的SAのプロトコルを設定するには、 ステートメントをインクルードprotocolし、 ahesp、 、または bundle のオプション[edit services ipsec-vpn ipsec proposal proposal-name]を 階層レベルで指定します。

IPsecポリシーのオプションのテキスト記述を指定するには、 階層レベルで ステートメントを含め description ます [edit services ipsec-vpn ipsec policy policy-name] 。

完全転送機密保持(PFS)は、Diffie-Hellman 共有の秘密値によってセキュリティを強化します。PFS では、1 つのキーが侵害されても、前後のキーは以前のキーから派生していないため、安全です。このステートメントはオプションです。

PFSを設定するには、 ステートメントを含め perfect-forward-secrecy 、 階層レベルでDiffie-Hellmanグループ [edit services ipsec-vpn ipsec policy policy-name] を指定します。

キーは次のいずれかです。

• group1- IKE が新しい Diffie-Hellman 交換を実行する際に、768 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group2- IKE が新しい Diffie-Hellman 交換を実行する際に、1024 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group5- IKE が新しい Diffie-Hellman 交換を実行する際に、1536 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group14- IKE が新しい Diffie-Hellman 交換を実行する際に、2048 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

Junos OSリリース17.4R1以降、グループ15、グループ16、グループ24もキーに使用できます。

• group15- IKE が新しい Diffie-Hellman 交換を実行する際に、3072 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group16- IKE が新しい Diffie-Hellman 交換を実行する際に、4096 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

• group24- IKE が新しい Diffie-Hellman 交換を実行するときに、256 ビットの素数サブグループで 2048 ビットの Diffie-Hellman 素数係数グループを使用することを指定します。

大きい番号のグループは、低い番号のグループよりも高いセキュリティを提供しますが、より多くの処理時間を必要とします。

IPsec ポリシーには、IPsec ポリシーに関連付けられた 1 つ以上のプロポーザルのリストが含まれます。

IPsecポリシーでプロポーザルを設定するには、 ステートメントを含め proposals 、階層レベルで1つ以上のプロポーザル名 [edit services ipsec-vpn ipsec policy policy-name] を指定します。

動的エンドポイントのIPsecポリシーは、トンネルのリモートエンドに静的に割り当てられたIPアドレスを持たない動的ピアセキュリティゲートウェイ間のIPsecネゴシエーション中に使用されるセキュリティパラメーター(IPsecプロポーザル)の組み合わせを定義します。IPsec ネゴシエーション中、IPsec ポリシーは、両方のピアで同じ IPsec プロポーザルを探します。ネゴシエーションを開始したピアは、そのすべてのポリシーをリモートピアに送信し、リモートピアは一致を見つけようとします。2 つのピアのポリシーに、同じ設定済み属性を含むプロポーザルがある場合、一致します。ライフタイムが同じでない場合は、(ホストとピアからの)2つのポリシー間の短い方のライフタイムが使用されます。

ポリシーが設定されていない場合は、動的ピアが提案するすべてのポリシーが受け入れられます。

2つのプロポーザル(およびdynamic-2)に関連付けられたIPsecポリシー dynamic policy-1を定義します。dynamic-1

メモ：

現在の IPsec プロポーザルとポリシー設定に対する更新は、現在の IPsec SA には適用されません。更新は新しいIPsec SAに適用されます。

新しい更新を直ちに有効にする場合は、既存の IPsec セキュリティ アソシエーションをクリアして、変更された構成で再確立されるようにする必要があります。現在のIPsecセキュリティアソシエーションをクリアする方法については、 Junos OSシステムの基本とサービスコマンドリファレンスを参照してください。