Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

IPsec の基本

このトピックでは、IPsec 鍵管理、セキュリティ プロトコル、トンネル ネゴシエーション、IPsec および IKE 標準について説明します。

特定の機能のプラットフォームおよびリリースサポートを確認するには、機能エクスプローラーを使用します。

プラットフォームに関連する注意点については、プラットフォーム固有の IPsec トンネルの動作セクションを参照してください。

詳細については、「 プラットフォームの追加情報 」セクションを参照してください。

IPsec の概要

IPsec は、IP パケット レイヤーでの通信を暗号で保護するための、関連プロトコルのセットです。IPsec は、SA(セキュリティ アソシエーション)の手動および自動ネゴシエーションと、鍵配信のための方法を提供します。解釈の領域(DOI)は、関連するすべての属性を収集します。IPsec DOI は、VPN トンネルのネゴシエーションを成功させるために必要なすべてのセキュリティ パラメーター(基本的には、SA および IKE ネゴシエーションに必要なすべての属性)を定義するドキュメントです。詳細については、RFC 2407 および RFC 2408 を参照してください。

IPsec セキュリティ サービスを使用するには、ホスト間で SA を作成します。SA は、2 つのホストが IPsec によって安全に通信できるようにするシンプレックス接続です。IPsec は、次の 2 種類の SA をサポートします。手動および動的。

IPsec は、2 つのセキュリティ モード(トランスポート モードとトンネル モード)をサポートします。

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

SA（セキュリティ アソシエーション）は、通信チャネルの保護に使用する方法とパラメーターに関する、VPN 参加者間の一方向契約です。完全な双方向通信を行うには、各方向に 1 つずつ、少なくとも 2 つの SA が必要になります。SA を通じて、IPsec トンネルは以下のセキュリティ機能を提供できます。

  • プライバシ（暗号化を使用）

  • コンテンツの整合性（データ認証を使用）

  • 送信者の認証と(証明書を使用している場合)、否認防止(データ送信元認証を使用)

採用すべきセキュリティ機能は、ニーズによって異なります。IP パケットの送信元とコンテンツの整合性のみを認証する必要がある場合は、暗号化を適用せずにパケットを認証できます。一方、プライバシの維持のみに不安がある場合は、認証メカニズムを適用せずにパケットを暗号化することができます。必要に応じて、パケットを暗号化して認証することもできます。多くのネットワーク セキュリティ設計者は、VPN トラフィックを暗号化し、認証し、リプレイして保護することを選択します。

IPsec トンネルは、一方向の SA のペア(トンネルの各方向に 1 つの SA)で構成されています。SA は、SPI(セキュリティ パラメーター インデックス)、IP アドレス、AH(認証ヘッダー)や ESP(セキュリティ ペイロードのカプセル化)などのセキュリティ プロトコルを指定します。SA は、通信を保護するため、以下のコンポーネントをグループ化します。

  • セキュリティ アルゴリズムと鍵

  • プロトコル モード（トランス ポートまたはトンネル）Junos OS デバイスは、常にトンネル モードを使用しますトンネルモードでのパケット処理を参照してください。

  • 鍵管理方法（手動鍵または AutoKey IKE）

  • SA ライフタイム

インバウンド トラフィックの場合、Junos OS は以下の 3 つで SA を検索します。

  • 宛先 IP アドレス

  • セキュリティ プロトコル（AH または ESP）

  • SPI値。

アウトバウンド VPN トラフィックの場合、ポリシーが VPN トンネルに関連づけられた SA を呼び出します。

IPsec 鍵管理

VPN を正常に使用するには、鍵の配布と管理が不可欠です。Junos OS は、次の 3 種類の鍵作成メカニズムにより、VPN トンネルを作成するための IPsec 技術をサポートしています。

  • 手動キー

  • 事前共有鍵(PSK)または証明書を使用した AutoKey IKE

フェーズ 1 およびフェーズ 2 プロポーザルの設定時に、鍵作成メカニズム(認証方法とも呼ばれる)を選択できます。「インターネット鍵交換」を参照してください。

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

手動鍵

手動鍵を使用して、トンネルの両端の管理者がすべてのセキュリティ パラメーターを設定します。手動鍵は、鍵の配布、保守、追跡が困難でない、小規模で静的なネットワークに適した手法です。ただし、長距離間で手動鍵設定を安全に配布すると、セキュリティの問題が発生します。鍵を直接受け渡しする場合は別として、権限のない第三者が転送中に鍵を侵害していないことを完全に保証することはできません。また、鍵の変更が必要になるたびに、鍵を初めて配布したときと同様のセキュリティの問題に直面します。

AutoKey IKE

多数のトンネルを作成して管理する必要がある場合は、すべての要素を手動で設定しないですむ方法が必要になります。IPsec は、IKE(インターネット鍵交換)プロトコルを使用した鍵と SA の自動生成とネゴシエーションをサポートします。Junos OS では、このような自動化されたトンネル ネゴシエーションを AutoKey IKE と呼び、事前共有鍵を使用する AutoKey IKE と、証明書を使用する AutoKey IKE をサポートしています。

  • 事前共有鍵を使用した AutoKey IKE—事前共有鍵による AutoKey IKE を使用して IKE セッションの参加者を認証する場合、両者で事前に PSK を設定し、安全に交換しておく必要があります。この点では、安全な鍵配布で生じる問題は、手動鍵の場合と同様です。ただし手動鍵とは異なり、AutoKey は一度配布されると、IKE プロトコルを使用して、あらかじめ決められた間隔で鍵を自動的に変更できます。頻繁に鍵が変更されることでセキュリティが大幅に向上し、変更が自動的に行われることで鍵管理の責任を大幅に削減できます。ただし、鍵の変更によりトラフィックのオーバーヘッドが増加するため、あまりにも頻繁に鍵を変更すると、データ転送効率が低下する恐れがあります。

    PSK は、暗号化と復号化の両方のキーであり、両方の参加者が通信を開始する前にこれを持っている必要があります。

  • 証明書を使用した AutoKey IKE - AutoKey IKE ネゴシエーション中に証明書を使用して参加者を認証する場合、両者で公開鍵と秘密鍵のペアを生成し、証明書を取得します。双方が発行元の認証局(CA)を信頼している限り、参加者はピアの公開鍵を取得して、ピアの署名を検証できます。キーと SA を追跡する必要はありません。IKE によって自動的に実行されます。

Diffie-Hellman 交換

DH（Diffie-Hellman）交換により、参加者は共有の秘密値を生成できます。この手法の利点は、参加者が、通信を通して秘密値を渡さずに、安全でないメディアを介して秘密値を作成できるということです。各グループの計算で使用される主な係数のサイズは、以下の表に示すように異なります。デバイスは、ソフトウェアまたはハードウェアでDH交換操作を実行します。 次の 表 1 は、さまざまな Diffie Hellman(DH)グループを一覧表示し、そのグループに対して実行される操作がハードウェアまたはソフトウェアのどちらで行われるかを示しています。

表 1: 実行されたDiffie Hellman(DH)グループとその交換操作

Diffie-Hellman(DH)グループ

プライムモジュールサイズ

DHグループ1

768 ビット

DHグループ2

102 ビット

DHグループ5

1536 ビット

DHグループ14

2048 ビット

DH グループ 15

3072 ビット

DH グループ 16

4096 ビット

DH グループ 19

256ビット楕円曲線

DHグループ20

384ビット楕円曲線

DHグループ21

521ビット楕円曲線

DHグループ24

2048 ビット、256 ビット素数位数サブグループ

DH グループ 1、2、5 を使用することは推奨されません。

各 DH グループの係数のサイズは異なるため、参加者は同じグループを使用することに同意する必要があります。

IPsec セキュリティ プロトコル

IPsec は 2 つのプロトコルを使用して、IP レイヤーでの通信を保護します。

  • AH(認証ヘッダー)- IP パケットの送信元を認証し、その内容の整合性を検証するためのセキュリティ プロトコル

  • ESP(セキュリティ ペイロードのカプセル化)—IP パケット全体を暗号化してその内容を認証するためのセキュリティ プロトコル

フェーズ 2 プロポーザルの設定時に、セキュリティ プロトコル( authentication and encryption algorithms とも呼ばれる)を選択できます。「インターネット鍵交換」を参照してください。

各 VPN トンネルでは、SPU（サービス処理ユニット）とコントロール プレーンに、AH および ESP トンネル セッションの両方がインストールされています。ネゴシエーションが完了すると、デバイスはネゴシエートされたプロトコルでトンネル セッションを更新します。show security flow session および show security flow cp-session 動作モードコマンドは、ESP および AH トンネル セッションの詳細を表示します。

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

IPsec認証アルゴリズム(AHプロトコル)

AH（認証ヘッダー）プロトコルは、パケットの内容と送信元の信頼性と整合性を検証する手段を提供します。パケットは、秘密鍵と、MD5 または SHA ハッシュ関数を使用し、HMAC（ハッシュ メッセージ認証コード）を介して計算されたチェックサムにより、認証できます。

  • メッセージ ダイジェスト 5(MD5):任意の長さのメッセージと 16 バイトの鍵から、128 ビット ハッシュ( デジタル署名 または メッセージ ダイジェストとも呼ばれる)を生成するアルゴリズム。結果として得られるハッシュは、入力のフィンガープリントと同様に、内容と送信元の信頼性と整合性を検証するために使用されます。

  • セキュアハッシュアルゴリズム(SHA)— 任意の長さのメッセージと 20 バイトの鍵から 160 ビットのハッシュを生成するアルゴリズム。SHA はより大きなハッシュを生成するため、MD5 よりも安全です。ASICが計算処理を行うため、パフォーマンスコストは無視できません。

MD5 ハッシュ アルゴリズムの詳細については、RFC 1321 および RFC 2403 を参照してください。SHA ハッシュ アルゴリズムの詳細については、RFC 2404 を参照してください。HMAC の詳細については、RFC 2104 を参照してください。

IPsec暗号化アルゴリズム(ESPプロトコル)

ESP プロトコルは、プライバシ (暗号化)、送信元の認証およびコンテンツの整合性 (認証) を保証する手段を提供します。トンネル モードの ESP は、IP パケット全体（ヘッダーとペイロード）をカプセル化し、新しい IP ヘッダーを暗号化されていないパケットに追加します。この新しい IP ヘッダーには、保護されたデータをネットワーク経由でルーティングするのに必要な宛先アドレスが含まれています。トンネルモードでのパケット処理を参照してください。

ESP を使用すると、暗号化と認証の両方、暗号化のみ、または認証のみのいずれかを選択できます。暗号化には、以下の暗号化アルゴリズムのいずれかを選択できます。

  • DES(データ暗号化標準)— 56 ビット鍵を使用した暗号ブロック アルゴリズム。

  • トリプル DES(3DES):168 ビット鍵を使用して、元の DES アルゴリズムが 3 つのラウンドで適用される、DES のより強力なバージョン。DES はパフォーマンスを大幅に節約しますが、多くの機密性の高いデータの転送においては一般に容認されていません。

  • AES(次世代暗号化標準):他のデバイスとの高い相互運用性を提供する暗号化標準。Junos OS では、128 ビット、192 ビット、256 ビットの各鍵で AES をサポートしています。

  • 関連データを使用したChaCha20-Poly1305認証暗号化—Poly1305認証システムを使用した関連データによる認証暗号化(AEAD)をサポートするChaCha20ストリーム暗号。

認証では、MD5 または SHA アルゴリズムのいずれかを使用できます。

暗号化に NULL を選択することもできますが、調査により、IPsec はこのような状況下での攻撃に対して脆弱になる可能性があることが示されています。そのため、最大限のセキュリティを保証できる暗号化アルゴリズムを選択することをお勧めします。

IPsec トンネル ネゴシエーション

以下の 2 つの異なるモードによって、VPN がトラフィックを交換する方法が決まります。

  • トンネル モード - VPN トンネル内の別のパケット内に元の IP パケットをカプセル化することで、トラフィックを保護します。このモードでは、IKE で事前共有された鍵を使用してピアを認証するか、IKE でデジタル証明書を使用してピアを認証します。トンネルモードは、別々のプライベートネットワーク内のホストがパブリックネットワークを介して通信する場合に最も一般的に使用されます。VPN クライアントと VPN ゲートウェイはどちらも、トンネル モードを使用して、非 IPsec システムとの間で送受信される通信を保護します。

  • トランスポート モード - IPsec トンネルを確立した 2 つのホスト間でパケットを直接送信することにより、トラフィックを保護します。すなわち、通信エンドポイントと暗号エンドポイントが同じである場合である。このモードでは、暗号化メカニズムによってIPパケットのデータ部分が保護されますが、IPヘッダーは暗号化されません。保護されたホストに暗号化および復号化サービスを提供する VPN ゲートウェイは、保護された VPN 通信にトランスポート モードを使用できません。パケットが傍受された場合、送信元または宛先のIPアドレスを変更できます。トランスポート モードは、その構造上、通信エンドポイントと暗号化エンドポイントが同じ場合にのみ使用できます。

サポートされている IPsec および IKE の標準

1 つ以上の MS-MPC、MS-MIC、または DPC を装備したルーターでは、カナダおよび米国バージョンの Junos OS は、実質的に以下の RFC をサポートしています。これらの RFC は、IPsec（IP セキュリティ）および IKE（インターネット鍵交換）の標準を定義しています。

  • RFC 2085、HMAC-MD5 IP 認証(リプレイ防御機能付き)

  • RFC 2401、 インターネットプロトコルのセキュリティアーキテクチャ (RFC 4301 に置き換え)

  • RFC 2402、 IP認証ヘッダー (RFC 4302に置き換え)

  • RFC 2403 、 ESPおよびAH内でのHMAC-MD5-96の使用

  • RFC 2404 、 ESPおよびAH内でのHMAC-SHA-1-96の使用 (RFC 4305に置き換え)

  • RFC 2405、 明示的IVを使用したESP DES-CBC Cipher Algorithm

  • RFC 2406、 IPカプセル化セキュリティペイロード(ESP) (RFC 4303およびRFC 4305に置き換え)

  • RFC 2407 、 ISAKMP の解釈のインターネット IP セキュリティ ドメイン (RFC 4306 に置き換え)

  • RFC 2408、 Internet Security Association and Key Management Protocol (ISAKMP) (RFC 4306 に置き換え)

  • RFC 2409、 インターネット鍵交換(IKE) (RFC 4306 に置き換え)

  • RFC 2410、 IPsecでのNULL暗号化アルゴリズムとその使用

  • RFC 2451、 ESP CBCモード暗号アルゴリズム

  • RFC 2560、 X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル - OCSP

  • RFC 3193、 IPsecを使用したL2TPの保護

  • RFC 3280、 インターネット X.509 公開キー インフラストラクチャ証明書および証明書失効リスト (CRL) プロファイル

  • RFC 3602、 AES-CBC暗号アルゴリズムとそのIPsecでの使用

  • RFC 3948、 IPsec ESPパケットのUDPカプセル化

  • RFC 4106 、 IPsec ESP(カプセル化セキュリティペイロード)でのガロア/カウンターモード(GCM)の使用

  • RFC 4210、 インターネット X.509 公開キー インフラストラクチャ証明書管理プロトコル(CMP)

  • RFC 4211、 インターネット X.509 公開キー基盤証明書要求メッセージ形式 (CRMF)

  • RFC 4301、 インターネットプロトコルのセキュリティアーキテクチャ

  • RFC 4302、 IP認証ヘッダー

  • RFC 4303、 IPカプセル化セキュリティペイロード(ESP)

  • RFC 4305、 セキュリティペイロード(ESP)と認証ヘッダー(AH)をカプセル化するための暗号化アルゴリズム実装要件

  • RFC 4306、 インターネット鍵交換(IKEv2)プロトコル

  • RFC 4307、 インターネット鍵交換バージョン2(IKEv2)で使用するための暗号化アルゴリズム

  • RFC 4308、 IPsecの暗号スイート

    Junos OS では、Suite VPN-A のみがサポートされています。

  • RFC 4754、 楕円曲線デジタル署名アルゴリズム(ECDSA)を使用したIKEおよびIKEv2認証

  • RFC 4835、 セキュリティペイロード(ESP)と認証ヘッダー(AH)をカプセル化するための暗号化アルゴリズム実装要件

  • RFC 5996、 インターネット鍵交換プロトコルバージョン2(IKEv2) (RFC 7296に置き換え)

  • RFC 7296、 インターネット鍵交換プロトコル バージョン 2(IKEv2)

  • RFC 7427、 インターネット鍵交換バージョン2(IKEv2)での署名認証

  • RFC 7634、 ChaCha20、Poly1305、インターネット鍵交換プロトコル(IKE)およびIPsecでのそれらの使用

  • RFC 8200、 インターネットプロトコル、バージョン6(IPv6)仕様

Junos OS は、 IPsec と IKE に関する以下の RFC を部分的にサポートしています。

  • RFC 3526、 インターネット鍵交換(IKE)のためのより多くのモジュラー指数(MODP)Diffie-Hellman グループ

  • RFC 5114、 IETF標準で使用するための追加のDiffie-Hellmanグループ

  • RFC 5903、 IKEおよびIKEv2の素数(ECPグループ)をモジュロとする楕円曲線グループ

以下の RFC およびインターネット ドラフトでは、標準は定義されていませんが、IPsec、IKE、関連技術に関する情報が提供されています。IETF は、これらを「情報提供」として分類しています。

  • RFC 2104、 HMAC: Keyed-Hashing for Message Authentication

  • RFC 2412 、 OAKLEY Key Decision Protocol

  • RFC 3706、 死んだ インターネット鍵交換(IKE)ピアを検出するトラフィックベースの方法

  • インターネットドラフトdraft-eastlake-sha2-02.txt、 米国のセキュアハッシュアルゴリズム(SHAおよびHMAC-SHA) (2006年7月終了)

関連項目

プラットフォーム固有の IPsec トンネルの動作

特定の機能のプラットフォームおよびリリースサポートを確認するには、機能エクスプローラーを使用します。

次の表を使用して、プラットフォームのプラットフォーム固有の動作を確認します。

表 2: プラットフォーム固有の動作

プラットフォーム

違い

SRXシリーズ

  • IPsec VPN をサポートする SRX5400、SRX5600、SRX5800 デバイスの場合:

    • Junos OS は、アンカー SPU のトンネル セッションのネゴシエートされたプロトコルを更新します。

    • 非アンカー SPU は、ESP および AH トンネル セッションを保持します。

プラットフォームの追加情報

特定の機能のプラットフォームおよびリリースサポートを確認するには、機能エクスプローラーを使用します。追加のプラットフォームがサポートされる場合があります。

表 3: プラットフォームの追加情報

機能

SRX300 SRX320 SRX340 SRX345SRX380SRX550HM

SRX1500 SRX1600

SRX2300 SRX4100SRX4200SRX4300 SRX4600SRX4700

SRX5400 SRX5600 SRX5800

vSRX仮想ファイアウォール

DH グループ 15、16、21 のサポート

いいえ

◯

◯

◯

vSRX 3.0 junos-ike パッケージの場合は ○

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。

リリース
説明
24.2R1
Junos OSリリース24.2R1のSRX1600、SRX2300、SRX4300、SRX4600、SRX5400、SRX5600、SRX5800、vSRX 3.0に追加されたChaCha20-Poly1305アルゴリズムのサポート。
20.3R1
Junos OS リリース 20.3R1 以降、vSRX 仮想ファイアウォールは DH グループ 15、16、21 をサポートします。
19.1R1
Junos OS リリース 19.1R1 以降、SRX シリーズ ファイアウォールは DH グループ 15、16、21 をサポートしています。