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

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

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

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

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

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

  注:

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

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

注:

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

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

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

注:

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

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

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

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

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

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

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

グループは次のいずれかです。

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

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

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

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

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

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

Junos OSリリース17.4R1以降では、group15、group16、group 24も使用できるようになりました。

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

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

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

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

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

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

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

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

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

• aes-192-cbc—AES(Advanced Encryption Standard)192ビット暗号化アルゴリズム。

• aes-256-cbc—AES(Advanced Encryption Standard)256ビット暗号化アルゴリズム。

注:

データ暗号化標準(DES)暗号化アルゴリズムの弱い鍵と半弱い鍵のリストについては、RFC 2409、 The Internet Key Exchange (IKE)を参照してください。AES 暗号化アルゴリズムは、スループットがはるかに低いソフトウェア実装を使用するため、DES が推奨されるオプションであることに変わりはありません。

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

認証プロポーザルを設定し、encryptionステートメントを含めない場合、結果はNULL暗号化になります。一部のアプリケーションでは、この結果が想定されます。特定の認証または暗号化値を設定しない場合、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プロポーザルで設定されたライフタイムのタイプに基づいて、リモートピアと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フェーズを設定するには、[edit services ipsec-vpn ike policy policy-name]階層レベルでversionステートメントを含めます。

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

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

注:

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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を指定するには、[edit services ipsec-vpn ike policy policy-name]階層レベルでlocal-idステートメントを含めます。

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

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

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

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

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

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

注:

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

新しい更新をすぐに有効にする場合は、既存の IKE セキュリティ アソシエーションをクリアして、変更した設定で再確立する必要があります。現在の IKE セキュリティ アソシエーションをクリアする方法については、「 clear services ipsec-vpn ike security-associations」を参照してください。

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

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

• 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プロポーザルが含まれて安全性の低いアルゴリズムが選択されているかどうかをチェックする場合、エラーが発生し、トンネルは確立されません。例えば、IPsecプロポーザル用の2つの認証アルゴリズムを、トンネルの片端(ルーター 1)にhmac-sha-256-128およびhmac-md5-96として設定し、IPsecプロポーザル用のアルゴリズムをトンネルのもう一方の端(ルーター 2)にhmac-md5-96として設定した場合、トンネルは確立されず、プロポーザルの数が一致しません。

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

• プロポーザルの一致を特定の優先順位で行うようにするには、設定時にIPsecポリシーのプロポーザルの順序を知っておく必要があります。たとえば、2つのピアの両方のポリシーにプロポーザルがある場合に一致したときに最強のアルゴリズムが最初に考慮されるようにします。

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

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

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

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

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

• aes-192-cbc—AES(Advanced Encryption Standard)192ビット暗号化アルゴリズム。

• aes-256-cbc—AES(Advanced Encryption Standard)256ビット暗号化アルゴリズム。

注:

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

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

• aes-192-gcm—MS-MPC および MS-MIC 向けの Junos OS リリース 17.3R1 以降、ガロア/カウンターモードの高度な暗号化標準(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、 The Internet Key Exchange (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(Encapsulating セキュリティ ペイロード)プロトコルを指定する必要があります。

動的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秒のランダムジッター。

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

• lifetime-diffがhard-lifetimeよりも大きい場合、soft lifetime = (9*hard-lifetime)/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ステートメントを含め、[edit services ipsec-vpn ipsec proposal proposal-name]階層レベルでah、esp、またはbundleオプションを指定します。

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

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

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

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

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

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

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

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

Junos OSリリース17.4R1以降では、group15、group16、group 24もキーに使用できるようになりました。

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

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

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

番号の高いグループは、番号の低いグループよりもセキュリティが高くなりますが、処理時間が長くなります。

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

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

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

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

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

注:

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

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