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

プロポーザルの認証アルゴリズムを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では、プロトコルプロポーザルで認証方法が設定されていない場合、認証方法は IKEv1 としてのデフォルト値IKEされます。IKEv2 の認証方法を設定する場合は、ポリシーで参照されるプロポーザルすべてについて、同じ認証方法を設定する必要があります。

認証方法は、以下のいずれかを実行できます。

メモ：

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

• ecdsa-signatures-256:MS-MPC Junos OS MS-MIC 17.3R1の新バージョン リリース 17.3R1、256 ビット係数用 ECDSA(Elliptic Curve Digital Signature Algorithm)から開始します。

• ecdsa-signatures-384:384 Junos OS係数17.3R1 MS-MPC および MS-MIC のリリース 17.3R1、ECDSA(Elliptic Curve Digital Signature Algorithm)から開始します。

• pre-shared-keys—アウトオブバンド メカニズムから派生した鍵。鍵が交換を認証します。

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

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

データ プロポーザルに対して Diffie-Hellman グループを設定IKE、 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、group15 17.4R1 16、グループ 24 も使用できます。

• group15—新IKE Diffie-Hellman 交換の実行時に、3072 ビット Diffie-Hellman 主係数グループを使用します。

• group16—新IKE Diffie-Hellman 交換の実行時に、4096 ビット Diffie-Hellman 主係数グループを使用します。

• group24—IKE新しい Diffie-Hellman 交換を実行する際に、2048 ビットの Diffie-Hellman 主係数グループと 256 ビット Prime Order サブグループを使用します。

ビット数の多い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(Advanced Encryption Standard)128 ビット暗号化アルゴリズム。

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

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

メモ：

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

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

認証プロポーザルを設定したが encryption ステートメントを含めがない場合、その結果は NULL 暗号化になります。特定のアプリケーションはこのような結果を期待します。特定の認証または暗号化値を設定 sha1 がない場合、デフォルト値Junos OS認証および暗号化にデフォルト値が 3des-cbc 使用されます。

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

IKE SA のライフタイムを設定するには、階層 lifetime-seconds レベルにステートメントを [edit services ipsec-vpn ike proposal proposal-name] 含てます。

デフォルトでは、saのIKE SAの寿命は3600秒です。範囲は180~86,400秒です。

メモ：

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

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

メモ：

プロポー IKEでは、sa ライフタイム値は 1 つしか指定されていません。Junos OS、IPsec プロポーザルは異なるメカニズムを使用します。

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

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

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

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

アグレッシブ モードは、SAとキーの認証IKE確立します。ただし、アグレッシブ モードではメッセージ数の半分を使用し、ネゴシエーションのパワーが少なく、ID 保護は提供されません。ピアはアグレッシブ モードまたはメイン モードを使用してネゴシエーションIKE開始できます。リモート ピアは、ピアによって送信されたモードを受け入れる。

メモ：

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

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

このIKEポリシーには、有効なポリシーに関連付けられた 1 つ以上のプロポーザルIKEされます。

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

階層レベルにステートメントを authentication-method pre-shared-keys 含める [edit services ipsec-vpn ike proposal proposal-name] 場合、ポリシーの事前共有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進数字が含まれています。オプションを使用 3des-cbc すると、鍵には 16 進数字 48 文字が含まれています。

ポリシー 適用ポリシーのオプションのテキスト説明を指定IKE、 description ステートメントを階層レベルに [edit services ipsec-vpn ike policy policy-name 含める:

フェーズ 1 ネゴシエーションで使用するローカル識別子IKE指定できます。ステートメントが 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 を指定するには、ステートメントを階層 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から、無効なSSPを持つパケットがSAを再同期して受信した場合にデバイスを復元できます。

無効な 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-1 けされています proposal-2。以下の設定では、ネゴシエーションに IKEv1 のみを使用します。

メモ：

現在のアプリケーション プロポーザルIKEポリシー設定の更新は、現在のポリシー SA にIKEされません。の更新が新しいSA IKEされます。

新しい更新を即座に有効にしたい場合は、既存の 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 プロポーザルが含まれている場合、エラーが発生し、このシナリオではトンネルが確立されません。たとえば、トンネルの一端に認証アルゴリズムで設定されたルーター1が hmac-sha- 256-128として設定され、もう一方のエンドのトンネルに、hmac-md5-96として設定されたルーター2が含まれている場合、VPNトンネルは確立されません。

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

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

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

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

メモ：

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

• aes-128-gcm:MS-MPC および MS-MIC 用の Junos OS リリース 17.3R1 から、Galois/Counter Mode(AES-GCM)の高度な暗号化標準(AES-GCM)128 ビット暗号化アルゴリズムと、16 オクテット I GAL(整合性チェック値)を使用します。

• aes-192-gcm:MS-MPC および MS-MIC 用の Junos OS リリース 17.3R1 から、Galois/Counter Mode(AES-GCM)の高度な暗号化標準(AES-GCM)192 ビット暗号化アルゴリズムと、16 オクテット整合性チェック値 I GAL を使用します。

• aes-256-gcm:MS-MPC および MS-MIC 用の Junos OS リリース 17.3R1 から、Galois/Counter Mode(AES-GCM)の高度な暗号化標準(AES-GCM)256 ビット暗号化アルゴリズムと 16 オクテット整合性チェック値 I GAL を使用します。

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

メモ：

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

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

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

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

メモ：

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

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

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

デフォルトのライフタイムは28,800秒です。範囲は180~86,400秒です。

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

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

• (3*ハードライフタイム)/10 が 850 秒を超える場合、ライフタイム-diff = 850 秒 + 0 ~850 秒のジッター。

  メモ：

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

• (3*ハードライフタイム)/10 が 600 秒を超え、850 未満の場合、ライフタイム-diff = 600 秒 + 0~45 秒の間のランダム ジッター。

• (3*ハードライフタイム)/10 が 90 秒を超え、600 未満の場合、ライフタイム-diff = 90 秒 + 0~45 秒のランダム ジッター。

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

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

• ライフタイム diff がハードライフタイムを超える場合、ソフト ライフタイム = (9*ハードライフタイム)/10

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

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

メモ：

イニシエーター ソフト ライフタイムは、レスポンダー ソフト ライフタイムよりも常に小さになります。イニシエーターのソフト ライフタイムが最初に期限切れし、再キー プロセスを開始できる必要があります。

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

• イニシエーターの最大ソフト ライフタイムは:3600~850(ジッターは 0 に等しい)= 2750 秒

• イニシエーターの最小ソフト ライフタイムは、3600~850~850(ジッターは 850 に等しい)= 1,900 秒

• レスポンダーの最大ソフト ライフタイムは、3600~850(ジッターは 0 に等しい)+ 45 = 2795 秒

• レスポンダーの最小ソフト ライフタイムは、3600~850~850(ジッターは 850 に等しい)+ 45 = 1945 秒

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

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

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

PFS(Perfect Forward Secrecy)は、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、group15 17.4R1 16、グループ 24 も、鍵に使用できます。

• group15—新IKE Diffie-Hellman 交換の実行時に、3072 ビット Diffie-Hellman 主係数グループを使用します。

• group16—新IKE Diffie-Hellman 交換の実行時に、4096 ビット Diffie-Hellman 主係数グループを使用します。

• group24—IKE新しい Diffie-Hellman 交換を実行する際に、2048 ビットの Diffie-Hellman 主係数グループと 256 ビット Prime Order サブグループを使用します。

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

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 policy-1と ) に関連付けられている IPsec ポリシーを定義dynamic-1 します dynamic-2。

メモ：

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

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