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

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

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

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

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

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

  手記：

  Secure Hash Algorithms (SHA) のリファレンス情報については、Internet draft draft-eastlake-sha2-02.txt, Secure Hash Algorithms (SHA and HMAC-SHA) (expires July 2006) を参照してください。

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

手記：

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

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

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

手記：

Junos FIPSモードでは、ECDSAはJunos OS リリース17.3R1の認証方法ではサポートされていません。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—IKE が新しい Diffie-Hellman 交換を実行するときに、1024 ビットの Diffie-Hellman プライム係数グループを使用することを指定します。

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

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

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

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

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

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

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

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

より多くのビット数に基づく 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)192ビット暗号化アルゴリズム。

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

手記：

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

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

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

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 以降、すべての M Series、MXシリーズ、T Series ルーターで、IKEv1 と IKEv2 の両方がデフォルトでサポートされています。ネゴシエーションでサポートされる特定の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ポリシーでプロポーザルを設定するには、 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 タイプの 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を指定するには、[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 セキュリティ アソシエーションをクリアして、変更された設定で再確立する必要があります。現在の 有効期間を選択します.有効な範囲は 180 をクリアする方法については、「 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として設定した場合、トンネルは確立されず、プロポーザルの数は一致しません。

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

• たとえば、2つのピアの両方から両方のポリシーにプロポーザルがある場合に、一致が行われたときに最強のアルゴリズムを最初に考慮するなど、特定の優先順序でプロポーザルのマッチングを行う場合は、設定時にIPsecポリシーのプロポーザルの順序に注意する必要があります。

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)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以降、Galois/CounterモードのAdvanced Encryption Standard(AES-GCM)16オクテット整合性チェック値(ICV)を備えた128ビット暗号化アルゴリズム。

• aes-192-gcm—MS-MPCおよびMS-MIC向けJunos OS リリース17.3R1以降、AES-GCM(Galois/Counter Mode)の高度な暗号化標準と16オクテットの整合性チェック値ICVを備えた192ビット暗号化アルゴリズム。

• aes-256-gcm—MS-MPC および MS-MIC 向け Junos OS リリース 17.3R1 以降、AES-GCM(Galois/Counter Mode)の高度な暗号化標準と 16 オクテット整合性チェック値 ICV を持つ 256 ビットの暗号化アルゴリズム。

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

手記：

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

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

特定の認証または暗号化設定を構成しない場合、Junos OS は認証にデフォルト値の sha1 を使用し、暗号化に 3des-cbc を使用します。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 秒からです。

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

lifetime-diff の計算は、次のように実行されます。

• (3*ハードライフタイム)/10 が 850 秒より大きい場合、ライフタイム差分 = 850 秒 + 0 から 850 秒の間のジッター。

  手記：

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

• (3*ハードライフタイム)/10 が 600 秒より大きく 850 未満の場合、ライフタイム差分 = 600 秒 + 0 から 45 秒のランダム ジッター。

• (3*ハードライフタイム)/10 が 90 秒より大きく 600 未満の場合、ライフタイム差分 = 90 秒 + 0 〜 45 秒のランダム ジッター。

• (3*ハードライフタイム)/10 が 90 秒未満の場合、ライフタイム差分 = 90 秒 + 0 から 10 秒の間のランダム ジッター。

lifetime-diff に基づいて、ソフト ライフタイムは次のように計算されます。

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

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

Perfect Forward Secrecy(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—IKE が新しい Diffie-Hellman 交換を実行するときに、1536 ビットの Diffie-Hellman プライム係数グループを使用することを指定します。

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

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

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

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

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

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

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

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

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

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

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

手記：

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

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