Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

プロポーザルIKEの構成

動的なSA(セキュリティ アソシエーション)には、ポリシー設定IKE必要があります。動的 SA では、最初にIKE SA を設定します。IKEは動的なSAを作成し、IPsec用にネゴシエートします。このIKE設定では、ピア セキュリティ ゲートウェイとのセキュアなセキュリティ 接続を確立IKE使用するアルゴリズムと鍵を定義します。

1 つ以上のプロポーザルを設定IKEできます。各プロポーザルは、デバイス ホストIKEピア間のIKE保護するためのIKE属性のリストです。

IKEプロポーザルを設定するには、 proposal ステートメントを含め、階層レベルで名前を [edit services ipsec-vpn ike] 指定します。

メモ:

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

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

プロトコル プロポーザルの認証アルゴリズムIKE設定

プロポーザルの認証アルゴリズムを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設定

要求プロポーザルの認証方法を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グループIKE設定

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設定

プロポーザルの暗号化アルゴリズムを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 使用されます。

IKE SA のライフタイムの設定

ステートメント 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設定

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

ポリシー IKEの設定

ポリシー IKEでは、ネゴシエーションの最中に使用するセキュリティ パラメーター(プロポーザルIKE組みIKE定義します。ピア アドレスと、その接続に必要なプロポーザルを定義します。使用する認証方法に応じて、指定されたピアまたはローカル証明書の事前共有鍵を定義します。ネゴシエーションのIKE、IKEピアで同IKEポリシーを必要とします。ネゴシエーションを開始するピアは、そのすべてのポリシーをリモート ピアに送信し、リモート ピアは一致を見つけようとします。

2 つのピアの両方のポリシーに、同じ設定された属性を含むプロポーザルが存在する場合、一致が行されます。ライフタイムが同じではない場合は、2 つのポリシー(ホストとピアから)間の短いライフタイムが使用されます。設定済みの事前共有鍵も、そのピアと一致する必要があります。

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

鍵管理プロセス(kmd)デーモンは、ネゴシエーションで使用される鍵IKEバージョンを決定します。kmd がサービス イニシエータIKE場合、デフォルトで IKEv1 が使用され、ネゴシエーション用に設定済みバージョンが保持されます。kmd がサービス レスIKE、IKEv1 と IKEv2 の両方からの接続を受け入れる。

各ピアに優先順位付けされた複数のプロポーザルを作成して、少なくとも 1 つのプロポーザルがリモート ピアのプロポーザルと一致させる必要があります。

まず、1 つ以上のプロポーザルをIKEします。プロポーザルを他のプロポーザルとIKEしますステートメント内のIKEプロ policy ポーザルのリストに優先順位を付け、最初から最後まで使用するプロポーザルをリストすることができます。

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

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

フェーズの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設定

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設定

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

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

仮想ポリシーに対する事前共有鍵IKE設定

階層レベルにステートメントを 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設定

階層レベルで ステートメントを authentication-method rsa-signatures 含める [edit services ipsec-vpn ike proposal proposal-name] 場合、公開鍵基盤(PKI)デジタル証明書はピアを認証します。認証フェーズの間にピアに送信されるローカル証明書を識別IKE必要があります。

ポリシー ポリシーに対してローカル証明書をIKEするには、ステートメント local-certificate を階層レベルに [edit services ipsec-vpn ike policy policy-name] 含める:

ステートメント local-certificate は、認証機関からエンド エンティティの証明書を取得するために使用される識別子を指定します。アプリケーション ポリシーで設定IKE、必要に応じて各リモート ピアで個別の証明書を使用する柔軟性が得されます。ステートメントを階層レベルで設定するには、認証 ca-profile 機関の ID も指定する [edit security pki] 必要があります。

設定されたプロファイルを使用して、特定のサービス セットで使用する信頼できる認証機関のセットを確立できます。これにより、IPサービスを提供する個々のクライアントに対して個別のサービスセットを設定できます。異なるサービス セットでは、異なるローカル ゲートウェイ アドレスまたはサービス を使用して、セッションのIKEセットを論理的に分離 仮想化。信頼できる認証機関のセットを設定するには、ステートメントを階層 trusted-ca レベルに [edit services service-set service-set-name ipsec-vpn-options] 含める:

証明書失効リストを設定するには、以下を参照してください。

証明書失効リストの設定

証明書失効リスト(高信頼化リスト)には、有効期限の前にキャンセルされたデジタル証明書のリストが含まれている。参加ピアがデジタル証明書を使用すると、証明書の署名と有効性を確認します。また、最近発行されたSLDを取得し、そのSLDに証明書シリアル番号が入っていないチェックをします。

メモ:

デフォルトでは、証明書失効リストの検証が有効になっています。階層レベルにステートメントを含め、このステートメントを含めて disable 、この場合 [edit security pki ca-profile ca-profile-name revocation-check] 、このステートメントを無効にできます。

デフォルトでは、ルーターが軽量ディレクトリ アクセス プロトコル(LDAP)の URL にアクセスできない場合、または有効な証明書失効リストを取得できない場合、証明書の検証は失敗し、IPsec トンネルは確立されません。この動作をオーバーライドし、THE を disable on-download-failure ダウンロードしていない場合に IPsec ピアの認証を許可するには、ステートメントを階層レベルに [edit security pki ca-profile ca-profile-name revocation-check crl] 含める必要があります。

証明書失効リストCAするには、階層レベルにステートメントを含 [edit security pki ca-profile ca-profile-name revocation-check] める必要があります。詳細については、「 システム基本 構成ガイドJunos OSを参照してください

ポリシー ポリシーの説明IKE設定

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

フェーズ 1 ネゴシエーション用のIKEおよびリモート IP の設定

フェーズ 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 を使用すると、任意のリモート アドレスを接続できます。このオプションは動的エンドポイント設定でのみサポートされ、特定の値とともに設定することはできません。

無効な SPI 回復の有効化

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

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

例: IKE ポリシーの設定

以下の 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 プロポーザルの設定

IPsecプロポーザルは、リモートIPsecピアとネゴシエートするプロトコルとアルゴリズム(セキュリティサービス)をリストします。

IPsec プロポーザルを設定するには、 ステートメント proposal を含め、階層レベルで IPsec プロポーザル名を [edit services ipsec-vpn ipsec] 指定します。

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

IPsecプロポーザルの認証アルゴリズムの設定

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プロポーザルの説明の設定

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

IPsecプロポーザルの暗号化アルゴリズムの設定

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 のライフタイムの設定

動的 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 秒

動的 SA のプロトコルの設定

ステートメント 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ポリシーの設定

IPsec ポリシーは、IPsec ネゴシエーションで使用されるセキュリティ パラメーター(IPsec プロポーザル)の組み合わせを定義します。PFS(Perfect Forward Secrecy)と、接続に必要なプロポーザルを定義します。IPsec ネゴシエーション中に、IPsec は両方のピアで同じプロポーザルを確認します。ネゴシエーションを開始するピアは、そのすべてのポリシーをリモート ピアに送信し、リモート ピアは一致を見つけようとします。

2 つのピアの両方のポリシーに、同じ設定された属性を含むプロポーザルが存在する場合、一致が行されます。ライフタイムが同じではない場合は、2 つのポリシー(ホストとピアから)間の短いライフタイムが使用されます。

各ピアに優先順位付けされた複数の IPsec プロポーザルを作成して、少なくとも 1 つのプロポーザルがリモート ピアのプロポーザルと一致させる必要があります。

まず、1 つ以上の IPsec プロポーザルを設定します。プロポーザルをIPsecポリシーに関連付ける必要がありますステートメント内で IPsec policy が使用するプロポーザルのリストを優先順位付けするには、最初から最後まで使用するプロポーザルをリストできます。

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

このセクションでは、IPsec ポリシーの設定に関する以下のトピックを説明します。

IPsecポリシーの説明の設定

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

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

動的エンドポイントの IPsec ポリシー

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

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

例: IPsecポリシーの設定

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

メモ:

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

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

リリース履歴テーブル
リリース
説明
17.4R1
FIPS Junos OS リリース 17.4R1、ECDSA は FIPS Junosサポートされています。
17.4R1
FIPS Junos OS リリース 17.4R1、ECDSA は FIPS Junosサポートされています。
17.4R1
リリースのJunos OS、group15 17.4R1 16、グループ 24 も使用できます。
17.4R1
FIPS Junos OS リリース 17.4R1、AES-GCM は FIPS Junosサポートされています。
17.4R1
最初のリリース Junos OS、17.4R1 15、group16、グループ 24 を鍵に使用できます。
17.3R1
256 ビットJunos OS 17.3R1 MS-MPC および MS-MIC の場合は、ECDSA(Elliptic Curve Digital Signature Algorithm)のソフトウェア リリース 17.3R1から開始します。
17.3R1
384 ビットJunos OS 384 ビット係数17.3R1 MS-MPC および MS-MIC の ECDSA(Elliptic Curve Digital Signature Algorithm)のリリース 17.3R1開始。
17.3R1
MS-MPC および MS-MIC 用の Junos OS リリース 17.3R1 から、Galois/Counter Mode(AES-GCM)の高度な暗号化標準(AES-GCM)128 ビット暗号化アルゴリズムと、16 オクテットの整合性チェック値(I GAL)を使用しています。
17.3R1
MS-MPC および MS-MIC 用の Junos OS リリース 17.3R1 から、Galois/Counter Mode(AES-GCM)の高度な暗号化標準(AES-GCM)192 ビット暗号化アルゴリズムと 16 オクテット整合性チェック値 I GAL を使用しています。
17.3R1
MS-MPC および MS-MIC 用の Junos OS 17.3R1 リリース 17.3R1 から、Galois/Counter Mode(AES-GCM)の高度な暗号化標準(AES-GCM)256 ビット暗号化アルゴリズムと 16 オクテット整合性チェック値 I GAL を使用しています。
14.2
Junos OSリリース14.2から、無効なSSPを持つパケットがSAを再同期して受信した場合にデバイスを復元できます。