IPsec VPN 用の IKE(インターネット鍵交換)

IKE パケット処理

クリアテキスト パケットがトンネリングが必要なジュニパーネットワークスのデバイスに到着し、そのトンネル用のアクティブなフェーズ 2 SA が存在しない場合、Junos OS は IKE ネゴシエーションを開始し、パケットをドロップします。IP パケットヘッダー内の送信元と宛先のアドレスは、それぞれローカルおよびリモートの IKE ゲートウェイです。IP パケット ペイロードには、ISAKMP（IKE）パケットをカプセル化した UDP セグメントがあります。IKE パケットの形式は、フェーズ 1、フェーズ 2 と同じです。 図 1を参照してください。

その間に、送信元ホストは破棄されたパケットを再送しました。通常、2 つ目のパケットが到着するまでに IKE ネゴシエーションが完了し、Junos OS はパケットと、セッション内のすべての後続パケットを、転送前に IPsec で保護します。

[次のペイロード] フィールドには、以下のペイロード タイプのいずれかを示す数字が含まれています。

• 0002—SA ネゴシエーション ペイロードに、フェーズ 1 またはフェーズ 2 SA の定義が含まれています。

• 0004:プロポーザル ペイロードは、フェーズ 1 またはフェーズ 2 のプロポーザルになります。

• 0008:変換ペイロードは、SA ペイロードでカプセル化されるプロポーザル ペイロード内でカプセル化されます。

• 0010 - 鍵交換(KE)ペイロードに、DH パブリック値などの鍵交換を実行するのに必要な情報が含まれています。

• 0020 - 識別(IDx)ペイロード。

  • フェーズ 1 では、IDii はイニシエーター ID を示し、IDir はレスポンダ ID を示します。

  • フェーズ 2 では、IDui はユーザー イニシエーターを示し、IDur はユーザー レスポンダを示します。

  ID は、FQDN、U-FQDN、IP アドレス、ASN.1_DN などの IKE ID のタイプです。

• 0040:証明書(CERT)ペイロード。

• 0080:証明書要求(CERT_REQ)ペイロード。

• 0100:ハッシュ(HASH)ペイロードに、特定のハッシュ関数のダイジェスト出力が含まれています。

• 0200:署名(SIG)ペイロードにデジタル署名が含まれています。

• 0400—Nonce(Nx)ペイロードには、交換に必要な擬似情報が含まれています。

• 0800:通知ペイロード。

• 1000 - ISAKMP 削除ペイロード。

• 2000 - ベンダー ID(VID)ペイロードをフェーズ 1 ネゴシエーションの任意の場所に含めることができます。Junos OS はこれを使用して、NAT-T 向けのサポートをマークします。

図 2 に示すように、各 ISAKMP ペイロードは、同じ汎用ヘッダーから開始します。

複数の ISAKMP ペイロードをチェーン化し、後続の各ペイロード タイプを [次のヘッダー] フィールドの値で示すことができます。値 0000 は、最後の ISAKMP ペイロードを示します。例については、図 3 を参照してください。

IPsec パケット処理

IKE ネゴシエーションが完了し、2 つの IKE ゲートウェイがフェーズ 1、フェーズ 2 の SA(セキュリティ アソシエーション)を確立した後、後続のすべてのパケットがトンネルを使用して転送されます。フェーズ 2 SA がトンネル モードで ESP(セキュリティ プロトコルのカプセル化)を指定すると、パケットは 図 4 に示すようになります。デバイスによって、開始側ホストが送信する元のパケットに 2 つのヘッダーが追加されます。

図 4 に示すように、開始側ホストが構築するパケットには、ペイロード、TCP ヘッダー、および内部 IP ヘッダー（IP1）が含まれています。

Junos OS が追加するルーター IP ヘッダー（IP2）には、宛先 IP アドレスとしてリモート ゲートウェイの IP アドレスが、送信元 IP アドレスとしてローカル ルーターの IP アドレスが含まれています。また、Junos OS は、外部と内部の IP ヘッダー間に ESP ヘッダーを追加します。ESP ヘッダーには、リモート ピアがパケット受信時に適切に処理できるようにするための情報が含まれています。これについては、図 5 を参照してください。

[次のヘッダー] フィールドは、[ペイロード] フィールド内のデータのタイプを示しています。トンネル モードではこの値は 4 で、ペイロード内に IP パケットが含まれていることを示します。「図 6」を参照してください。

Junos OS での IKEv2 の設定

VPN ピアは、IKEv1 または IKEv2 のいずれかに構成されます。ピアが IKEv2 として構成されている場合、リモート ピアが IKEv1 のネゴシエーションを開始しても、IKEv1 にフォールバックすることはできません。デフォルトでは、ジュニパーネットワークスのセキュリティデバイスはIKEv1ピアです。

IKEv2を設定するには、[edit security ike gateway gw-name]階層レベルで version v2-only 設定ステートメントを使用します。

IKEバージョンは、 show security ike security-associations および show security ipsec security-associations CLI操作コマンドの出力に表示されます。

ジュニパーネットワークス デバイスは、フェーズ 2 ネゴシエーションの最大 4 つのプロポーザルをサポートします。これにより、受け入れるトンネル パラメーターの範囲をどのくらい制限するかを指定できます。Junos OS は、定義済みの標準、互換、基本フェーズ 2 のプロポーザル セットを提供します。カスタムフェーズ2プロポーザルを定義することもできます。

IKEv2 構成ペイロードについて

構成ペイロードは、応答側から開始側へのプロビジョニング情報の伝送用に提供されるインターネット鍵交換バージョン 2(IKEv2)オプションです。IKEv2 構成ペイロードは、ルートベース VPN でのみサポートされます。

RFC 5996、 インターネット鍵交換プロトコル バージョン 2(IKEv2)では、応答側が開始側に返すことのできる 15 種類の構成属性が定義されています。 表 1 、SRXシリーズファイアウォールでサポートされているIKEv2設定属性について説明します。

表 1: IKEv2 設定属性

属性タイプ	値	説明	長さ
INTERNAL_IP4_ADDRESS	1	内部ネットワーク上のアドレスを指定します。複数の内部アドレスを要求できます。レスポンダは、要求されたアドレス数まで送信できます。	0 または 4 オクテット
INTERNAL_IP4_NETMASK	2	内部ネットワークのネットマスク値を指定します。要求メッセージと応答メッセージで使用できるネットマスク値は 1 つだけ (例:255.255.255.0)、INTERNAL_IP4_ADDRESS 属性でのみ使用する必要があります。	0 または 4 オクテット
INTERNAL_IP4_DNS	3	ネットワーク内の DNS サーバーのアドレスを指定します。複数の DNS サーバーを要求できます。レスポンダは、0 個以上の DNS サーバ属性で応答できます。	0 または 4 オクテット
INTERNAL_IP4_NBNS	4	ネットワーク内の NetBIOS ネーム サーバー (NBNS) (WINS サーバーなど) のアドレスを指定します。複数の NBNS サーバーを要求できます。レスポンダーは、ゼロ以上の NBNS サーバー属性で応答できます。	0 または 4 オクテット
INTERNAL_IP6_ADDRESS	8	内部ネットワーク上のアドレスを指定します。複数の内部アドレスを要求できます。レスポンダは、要求されたアドレス数まで送信できます。	0 または 17 オクテット
INTERNAL_IP6_DNS	10	ネットワーク内の DNS サーバーのアドレスを指定します。複数の DNS サーバーを要求できます。レスポンダは、0 個以上の DNS サーバ属性で応答できます。	0 または 16 オクテット

IKE レスポンダがイニシエーターにプロビジョニング情報を提供するには、RADIUS サーバーなどの指定されたソースから情報を取得する必要があります。プロビジョニング情報は、RADIUS サーバーを介して DHCP サーバーから返すこともできます。RADIUS サーバーでは、ユーザー情報に認証パスワードを含めないでください。RADIUS サーバー プロファイルは、[edit security ike gateway gateway-name] 階層レベルの aaa access-profile profile-name 構成を使用して IKE ゲートウェイにバインドされます。

Junos OSリリース20.3R1以降、ikedプロセスを実行しているSPC3およびvSRX仮想ファイアウォールとのSRX5000ラインで、IKEv2設定ペイロードを次のように改善しました。

• IPv4 および IPv6 ローカル アドレス プールのサポート。ピアに固定 IP アドレスを割り当てることもできます。

  IKE の確立中に、イニシエーターはレスポンダに IPv4 アドレス、IPv6 アドレス、DNS アドレス、または WINS アドレスを要求します。レスポンダーは、イニシエータの認証に成功した後、ローカルアドレスプールから、またはRADIUSサーバーを介してIPアドレスを割り当てます。設定に応じて、この IP アドレスは、ピアが接続するたびに動的に割り当てられるか、固定 IP アドレスとして割り当てられます。RADIUSサーバーがフレームプールで応答した場合、Junos OSは、対応するローカルプールから設定に基づいてIPアドレスまたは情報を割り当てます。ローカルアドレスプールとRADIUSサーバーの両方を設定した場合、RADIUSサーバーから割り当てられたIPアドレスがローカルプールよりも優先されます。ローカル IP アドレス プールを設定し、RADIUS サーバーが IP アドレスを返さなかった場合、ローカル プールは IP アドレスをリクエストに割り当てます。

• authentication-order用に導入された追加オプションnone。認証順序(アクセスプロファイル)を参照してください。

• RADIUSアカウンティングの開始および停止メッセージは、RADIUSサーバーにトンネルまたはピアの状態を通知します。これらのメッセージは、追跡目的または DHCP サーバーなどのサブシステムへの通知に使用できます。

  RADIUS サーバーがアカウンティングの開始メッセージまたは停止メッセージをサポートしていることを確認します。また、SRXシリーズファイアウォールとRADIUSサーバーの両方に、これらのメッセージを追跡するための適切な設定が設定されていることを確認してください。

• IPv6サポートの導入により、設定ペイロードを使用したデュアルスタックトンネルが可能になります。ログイン プロセス中に、IKE は IPv4 アドレスと IPv6 アドレスの両方を要求します。AAA は、要求されたすべてのアドレスが正常に割り当てられた場合にのみログインを許可します。IKE は、要求された IP が割り当てられていない場合、ネゴシエーションを終了します。

ルートベース VPN では、セキュア トンネル(st0)インターフェイスはポイントツーマルチポイントまたはポイントツーポイント モードで動作します。IKEv2 設定ペイロードを介したアドレス割り当てが、ポイントツーマルチポイントモードまたはポイントツーポイントモードでサポートされるようになりました。ポイントツーマルチポイントインターフェイスの場合、インターフェイスには番号が付けられ、設定ペイロードINTERNAL_IP4_ADDRESS属性タイプのアドレスは、関連するポイントツーマルチポイントインターフェイスのサブネットワーク範囲内である必要があります。

Junos OS リリース 20.1R1 以降、IKE ゲートウェイ設定の IKEv2 設定ペイロード要求に共通のパスワードを設定できます。1 から 128 文字の範囲の共通パスワードを使用すると、管理者は共通パスワードを定義できます。このパスワードは、SRXシリーズファイアウォールがIKEv2設定ペイロードを使用してリモートIPsecピアに代わってIPアドレスを要求するときに、SRXシリーズファイアウォールとRADIUSサーバーの間で使用されます。RADIUSサーバーは、設定ペイロード要求用のIP情報をSRXシリーズファイアウォールに提供する前に、認証情報を照合します。[edit security ike gateway gateway-name aaa access-profile access-profile-name] 階層レベルで 設定ステートメントを使用してconfig-payload-password configured-password共通パスワードを設定できます。

SRXシリーズファイアウォールとRADIUSサーバーの両方で同じパスワードを設定し、認証プロトコルとしてパスワード認証プロトコル(PAP)を使用するようにRADIUSサーバーを設定する必要があります。これがないと、トンネルの確立は成功しません。

図 7 は、IKEv2 構成ペイロードの一般的なワークフローを示しています。

IKEv2 設定ペイロード機能は、 ポイントツーマルチポイント セキュア トンネル(st0)インターフェイスとポイントツーポイント インターフェイスの両方でサポートされます。ポイントツーマルチポイントインターフェイスには番号が付けられ、設定ペイロードで提供されるアドレスは、関連するポイントツーマルチポイントインターフェイスのサブネットワーク範囲内である必要があります。

Junos OSリリース20.1R1以降、IKEv2設定ペイロード機能がサポートされています。SRX5000回線上のポイントツーポイントインターフェイスと ikedを実行する vSRX仮想ファイアウォールを使用します。

ピコセルプロビジョニングの理解

IKEv2設定ペイロードを使用して、SRXシリーズファイアウォールなどのIKEレスポンダーから、セルラーネットワーク内のLTEピコセル基地局などの複数のイニシエータにプロビジョニング情報を伝送できます。ピコセルは、SRXシリーズファイアウォールに接続できる標準構成で出荷されますが、ピコセルプロビジョニング情報は、保護されたネットワーク内の1つ以上のプロビジョニングサーバーに保存されます。pico セルは、プロビジョニング サーバーとのセキュアな接続を確立した後、完全なプロビジョニング情報を受信します。

ピコセルのブートストラップとプロビジョニング、そしてサービスへの導入に必要なワークフローには、4つの異なる段階があります。

1. 初期アドレス取得 - ピコセルは、次の情報とともに工場から出荷されます。

   • SRXシリーズファイアウォールへのセキュアゲートウェイトンネルの設定

   • 製造元が発行したデジタル証明書

   • 保護されたネットワーク内にあるプロビジョニング サーバーの完全修飾ドメイン名 (FQDN)

   picoセルが起動し、IKEネゴシエーションに使用するアドレスを DHCPサーバーから取得します。次に、このアドレスを使用して、SRXシリーズファイアウォール上のセキュアゲートウェイへのトンネルが構築されます。保護されたネットワークで使用するために、運用、管理、および管理(OAM)トラフィックのアドレスもDHCPサーバーによって割り当てられます。

2. ピコセルのプロビジョニング:ピコセルは、割り当てられたOAMトラフィックアドレスを使用して、保護されたネットワーク内のサーバーにプロビジョニング情報(通常は事業者証明書、ライセンス、ソフトウェア、設定情報)を要求します。

3. 再起動—ピコセルが再起動し、取得したプロビジョニング情報を使用して、サービスプロバイダのネットワークおよび運用モデルに固有の情報にします。

4. サービスプロビジョニング—ピコセルがサービスを開始すると、識別名(DN)とFQDN付きのサブジェクト代替名の値を含む単一の証明書を使用して、SRXシリーズファイアウォール上のセキュアゲートウェイへの2つのトンネルを構築します。1 つは OAM トラフィック用で、もう 1 つは第 3 世代パートナーシップ プロジェクト(3GPP)データ トラフィック用です。

概要

IKEv2 では、鍵更新と再認証は別個のプロセスです。鍵更新により、IKE セキュリティ アソシエーション（SA）用の新たな鍵が確立され、メッセージ ID カウンターがリセットされますが、ピアの再認証は行われません。再認証は、VPN ピアが認証資格へのアクセスを保持していることを確認します。再認証は、IKE SA および子 SA 用に新たな鍵を確立し、保留中の IKE SA または子 SA の鍵更新は必要なくなります。新しい IKE と子 SA が作成された後、古い IKE と子 SA が削除されます。

IKEv2 の再認証は、デフォルトでは無効になっています。再認証を有効にするには、再認証の頻度を 1～100 の値に構成します。再認証の頻度とは、再認証が行われるまでに発生する IKE 鍵更新の回数のことです。例えば、再認証の頻度を 1 として構成した場合、IKE の鍵更新のたびに再認証が行われます。再認証の頻度を 2 として構成した場合、IKE 鍵更新 2 回につき再認証が 1 回行われます。再認証の頻度を 3 として構成すると、IKE 鍵更新 3 回ごとに再認証が行われる、という具合です。

再認証の頻度は、[edit security ike policy policy-name] 階層レベルの reauth-frequency ステートメントで設定します。再認証の頻度を 0 (デフォルト) に設定すると、再認証が無効になります。再認証の頻度はピアによってネゴシエートされず、各ピアが独自の再認証頻度値を持つことができます。

サポートされている機能

IKEv2 の再認証は、以下の機能でサポートされています。

• IKEv2 イニシエーターまたはレスポンダ

• デッドピア検出（DPD）

• 仮想ルーターと仮想ルーターのセキュア トンネル(st0)インターフェイス

• ネットワーク アドレス変換トラバーサル(NAT-T)

• SRX5400、SRX5600、およびSRX5800デバイス用のアクティブ-アクティブおよびアクティブ-パッシブ モードのシャーシ クラスタ

• SRX5400、SRX5600、SRX5800デバイスでのISSU(インサービスソフトウェアアップグレード)

• インサービスハードウェアアップグレード(ISHU)手順を使用した、新しいサービス処理ユニット(SPU)のアップグレードまたは挿入

限界

IKEv2 再認証を使用する場合は、以下の点に注意してください。

• NAT-T を使用すると、以前の IKE SA とは異なるポートで新しい IKE SA を作成できます。このシナリオでは、古い IKE SA が削除されない可能性があります。

• NAT-T シナリオでは、NAT デバイスの背後にあるイニシエータが、再認証後にレスポンダーになることができます。NAT セッションが期限切れになると、NAT デバイスは、別のポートに到着する可能性のある新しい IKE パケットを破棄することがあります。NAT セッションを存続させるには、NAT-T キープアライブまたは DPD を有効にする必要があります。AutoVPN の場合、スポークに設定された再認証の頻度は、ハブに設定された再認証の頻度よりも小さくすることをお勧めします。

• 再認証の頻度に基づいて、元のIKE SAのイニシエーターまたはレスポンダーのいずれかが新しいIKE SAを開始できます。拡張認証プロトコル(EAP)認証および構成ペイロードでは、IKE SA が元の IKE SA と同じパーティによって開始される必要があるため、EAP 認証または構成ペイロードでの再認証はサポートされません。

証明書認証の複数階層

認定書ベースの認証は、IKE ネゴシエーション中に SRX シリーズファイアウォールでサポートされる認証方法です。大規模なネットワークでは、複数の認証局(CA)がそれぞれのエンドデバイスにエンドエンティティ(EE)証明書を発行できます。個々の場所、部門、または組織に対して個別の CA を持つのが一般的です。

証明書ベースの認証に単一レベルの階層を使用する場合、ネットワーク内のすべての EE 証明書は、同じ CA によって署名されている必要があります。すべてのファイアウォール デバイスには、ピア証明書の検証用に同じ CA 証明書が登録されている必要があります。IKE ネゴシエーション中に送信される証明書ペイロードには、EE 証明書のみが含まれます。

または、IKE ネゴシエーション中に送信される証明書ペイロードに、EE および CA 証明書のチェーンを含めることができます。証明書チェーンは、ピアの EE 証明書を検証するために必要な証明書のリストです。証明書チェーンには、EE 証明書と、ローカルピアに存在しない CA 証明書が含まれます。

ネットワーク管理者は、IKE ネゴシエーションに参加するすべてのピアが、それぞれの証明書チェーンに少なくとも 1 つの共通の信頼される CA を持っていることを確認する必要があります。共通の信頼された CA は、ルート CA である必要はありません。EE の証明書とチェーン内の最上位の CA を含む、チェーン内の証明書の数は 10 を超えることはできません。

Junos OSリリース18.1R1以降では、指定したCAサーバーまたはCAサーバーのグループを使用して、設定されたIKEピアを検証できます。証明書チェーンを使用する場合、ルート CA は IKE ポリシーで設定された信頼できる CA グループまたは CA サーバと一致する必要があります

図 8に示すCA階層例では、ルートCAがネットワーク内のすべてのデバイスにとって共通の信頼できるCAです。ルート CA は、エンジニアリング CA と販売 CA にそれぞれ Eng-CA と Sales-CA として識別される CA 証明書を発行します。Eng-CA は、開発 CA と品質保証 CA にそれぞれ Dev-CA と Qa-CA として識別される CA 証明書を発行します。ホスト A は Dev-CA から EE 証明書を受信し、ホスト B は Sales-CA から EE 証明書を受け取ります。

各エンド デバイスは、その階層内に CA 証明書をロードする必要があります。ホスト A には、ルート CA、英語 CA、および開発 CA の証明書が必要です。sales-CA および Qa-CA の証明書は必要ありません。ホスト B には、ルート CA 証明書と販売 CA 証明書が必要です。証明書は、デバイスに手動で読み込むか、簡易証明書登録プロセス(SCEP)を使用して登録できます。

各エンド デバイスには、証明書チェーン内の各 CA の CA プロファイルを設定する必要があります。以下の出力は、Host-A で構成された CA プロファイルを示しています。

以下の出力は、Host-B に設定された CA プロファイルを示しています。

IKE実装におけるDDoS脆弱性

リモートピア(イニシエーター)がSA_INITメッセージを送信すると、ローカルピア(レスポンダー)が応答し、メッセージ構造にメモリを割り当てます。このセッションをの助けを借りて認証が行われるまでは、このセッションを 半オープンIKEセッション IKE_AUTHと呼びます。 ピアがIKEセキュリティアソシエーションSA)を確立した後セッションはフルオープンIKEセッション になります。

IKEv2 DDoSの脆弱性を理解するために、攻撃者がIKE SAに対して簡単な攻撃ベクトルを作成する方法をいくつか見てみましょう しましょう 。

• 攻撃者がハーフオープンIKEセキュリティアソシエーション構造を作成できるSA_INITメッセージ(なし IKE_AUTHメッセージの大きな数)を送信します。攻撃 により、デバイスはリソースを利用し、メモリが不足します。

• イニシエーターとレスポンダにそれぞれ正しいSPI_iとSPI_rを含む大量の数のジャンクIKE_AUTHパケット,を送信します。 デバイスは パケットの暗号化解除を試行している間 runs メモリが不足しています。

• パケット SA_INIT 継続的に送信。デバイスは、暗号化されたパケットのキーを生成しようとしているときに、メモリ不足を実行。

• 全オープンIKEセッション中に、1秒あたり大きな数のキー更新要求を送信します。

• 個別のメッセージ 識別子 (ID) を持つメッセージの 大きな 数を送信します。デバイスはすべての着信IKEメッセージをキューに入れメモリから実行します。

IKE実装を保護する方法

当社は、IKEv1 と IKEv2 の両方のプロトコルで DDoS 攻撃を緩和および監視するための、堅牢なインフラストラクチャを v2 プロトコルの両方に対して提供します。ファイアウォールがIPsec VPNサービスに対してikedプロセス(junos-ikeパッケージ内)を実行すると、IKE実装に対する攻撃から保護することができます。

注:

IKEv2 の DDoS 攻撃防御の詳細については、RFC 8019 インターネット 鍵交換プロトコル バージョン 2(IKEv2)実装を分散型サービス拒否攻撃から保護するを参照してください。ファイアウォールがikedプロセスを使用してIPsec VPNサービスを実行する場合、IKEv1に同様の保護を提供します。 RFCが提示するクライアントパズルメカニズムはサポートされていません。

防御 Aゲインスト DDoS攻撃

IKEセキュリティアソシエーション作成プロセス中に、DDoS攻撃に対する複数の 防御メカニズムを有効にすることができます。これらのメカニズム、ハーフオープンIKE SAのレート制限や保存期間の設定、さらにはキー更新要求の受信為替レートの管理などが含まれます。 IKE SAに対するDDoS攻撃を確実に保護するために 以下の対策を提供します:

• IKE SAまたはハーフオープンIKE SAの保護対策:

  • レスポンダは、一定時間、ハーフオープンIKE SAの設定を許可しません。この制限を設定して、レスポンダがタイムアウト時間に達するまで SA 設定 を設定しないようにすることができます。 詳細については、オプション timeout の session (Security IKE) を参照してください。

  • レスポンダで許容されるハーフオープンIKE SAの最大許容量にa制限を設定できます。ハーフオープンIKE SAの総数が最大数に達するesと、レスポンダはIKEv1とIKEv2の両方のSAの新しい接続を拒否します。詳細については、 の max-count オプションsession (Security IKE)を参照してください。

  • レスポンダは、ハーフオープンIKE SAのセッション数にしきい値を適用します。ハーフオープンIKE SAの総数がes しきい値に達すると次のようになります。

    • IKEv2 SAの場合、レスポンダは新しい接続に対してクッキーメカニズムを呼び出します。

    • IKEv1 SAの場合、レスポンダは新しい接続を拒否します。

    詳細については、session (Security IKE) のthresholds、send-cookie、およびreduce-timeoutオプション」を参照してください。

  • レスポンダは、重複したセッションを破棄できます。詳細についてはsession (Security IKE) の [discard-duplicate] オプションを参照してください。

  • 認証失敗フェーズと開始失敗フェーズのバックオフ タイムアウトを設定できます。詳細については、オプションbackoff-timeouts、init-phase-failure、およびauth-phase-failureのsession (Security IKE)を参照してください。

• フルオープンIKE SAの場合:

  • 最大受信キー更新要求レートを構成して、スケーリングされたシナリオで要求を調整できます。詳細については の incoming-exchange-max-rates オプションを参照してください session (Security IKE)。

• レスポンダは、ピアIKE IDに基づいて、ピアからの着信IKEセッションをブロックできます。詳細については、「blocklists (Security IKE)」を参照してください。

• 動的ゲートウェイの場合、オプション connections-limit を使用して、IKE ゲートウェイ構成レベルで接続数の制限を設定できます。詳細については、ゲートウェイ(セキュリティ IKE)を参照してください。

これらのオプションを構成する方法の詳細については、次を参照してください: IKE DDoS 攻撃に対する保護を構成する。

以下をサポートしていません。

• kmdプロセスに基づくIPsec VPNサービスによるDDoS攻撃防御

• ハッシュおよびURL証明書エンコーディング攻撃に対する保護は、これらのエンコーディングタイプをサポートしていないためです。

DDoS攻撃を監視する方法

DDoS 攻撃を監視するために、以下のメカニズムを提供しています。

• show security ike security-associations コマンド を使用して、成熟したIKEおよび非成熟IKEセキュリティ アソシエーションをすべて一覧表示します。詳細については、 show security ike security-associationsを参照してください。

• show security ike stats コマンド を使用して、IPsec VPN トンネルのグローバル IKE 統計情報(進行中-、確立済み、期限切れの統計情報など)を表示します。詳細については、 show security ike statsを参照してください。

• show security ike active-peer コマンド を使用して、リモート ピアとの IKE ネゴシエーションの成功の詳細を表示します。詳細については、 show security ike active-peerを参照してください。

• show security ike peers in-progress コマンド を使用して、半分開いているIKE SAを含む、進行中のIKE SAの詳細を表示します。詳細については、「 show security ike peers」を参照してください。このコマンドを使用して、ブロックされたピア、失敗したピア、およびバックオフ ピアの詳細を確認することもできます。

• clear security ike peers コマンド を使用して、バックオフ、ブロック、障害、または進行中の IKE ピアをクリアします。詳細については、「 clear security ike peers」を参照してください。

• 以降の通信からブロックする必要があるピアとの既存のIKEセキュリティアソシエーションを削除するには、 clear security ike security-associations コマンドを使用します。詳細については、 セキュリティ IKE セキュリティ関連付けのクリアを参照してください。

• ikedsystem log (syslog)メッセージIKE_GATEWAY_PEER_BLOCKED、IKE_GATEWAY_PEER_BACKOFF、およびIKE_GATEWAY_PEER_FAILEDは、それぞれリモートピアとのブロック、バックオフ、および失敗したIKEネゴシエーションに関する詳細を提供します。

• セキュリティを強化するために、Junos OSは、フィルタリング、セッション数、、レート制限などのパケットベースのシステム攻撃から保護するサービスをユーザーに提供します。 詳細については、show firewall コマンドおよび ids-option ステートメント[edit security screen ids-option screen-name] 階層レベル)を参照してください。

メッセージのフラグメント化

RFC 7383「 インターネット鍵交換プロトコル バージョン 2(IKEv2)メッセージ フラグメント化」で説明されているように、IKEv2 メッセージ フラグメント化により、IP フラグメントがブロックされ、ピアが IPsec セキュリティ アソシエーション(SA)を確立できないような環境でも IKEv2 を動作させることができます。IKEv2 フラグメント化は、大きな IKEv2 メッセージを小さなメッセージに分割して、IP レベルでフラグメント化が発生しないようにします。フラグメント化は、元のメッセージが暗号化および認証される前に行われるため、各フラグメントは別個に暗号化および認証されます。受信側でフラグメントの収集、検証、復号化、統合が実行されて元のメッセージになります。

IKEv2 フラグメント化が発生するためには、両方の VPN ピアが、IKEV2_FRAGMENTATION_SUPPORTED通知ペイロードをIKE_SA_INIT交換に含めることによって、フラグメント化のサポートを示す 必要があります 。両方のピアがフラグメント化のサポートを示している場合、IKEv2 フラグメント化を使用するかどうかは、メッセージ交換の開始側が判断します。

SRXシリーズファイアウォールでは、IKEv2メッセージごとに最大32のフラグメントが許可されます。送受信される IKEv2 メッセージ フラグメントの数が 32 を超えると、フラグメントはドロップされ、トンネルは確立されません。個々のメッセージフラグメントの再送信はサポートされていません

設定

SRXシリーズファイアウォールでは、IPv4およびIPv6メッセージに対してIKEv2フラグメント化がデフォルトで有効になっています。IKEv2 フラグメント化を無効にするには、[edit security ike gateway gateway-name fragmentation] 階層レベルで disable ステートメントを使用します。また、 size ステートメントを使用して、メッセージをフラグメント化するパケットのサイズを設定することもできます。パケット サイズは、500 から 1300 バイトの範囲です。size が設定されていない場合、デフォルトのパケット サイズは IPv4 トラフィックで 576 バイト、IPv6 トラフィックで 1280 バイトです。構成されたパケット サイズよりも大きい IKEv2 パケットはフラグメント化されます。

IKEv2 フラグメント化が無効または有効になった後、またはパケット フラグメント サイズが変更された後、IKE ゲートウェイでホストされている VPN トンネルがダウンし、IKE および IPsec SA が再ネゴシエートされます。

注意 事項

IKEv2 フラグメント化では、以下の機能はサポートされていません。

• パス MTU 検出。

• SNMP.