Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

IPsec の基本

IPsec の概要

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

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

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

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

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

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

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

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

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

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

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

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

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

  • SA ライフタイム

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

  • 宛先 IP アドレス

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

  • SPI（セキュリティ パラメーター インデックス）値

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

IPsec 鍵管理

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

  • 手動鍵

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

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

このトピックは、以下のセクションで構成されています。

手動鍵

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

AutoKey IKE

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

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

    事前共有鍵は、暗号化と暗号解読の両方にとって不可欠です。両方の参加者が、通信を開始する前にこれを持っている必要があります。

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

Diffie-Hellman 交換

DH（Diffie-Hellman）交換により、参加者は共有の秘密値を生成できます。この手法の利点は、参加者が、通信を通して秘密値を渡さずに、安全でないメディアを介して秘密値を作成できるということです。各グループの計算で使用される主な係数のサイズは、以下の表に示すように異なります。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 ビット素数位数サブグループ

Junos OS リリース 19.1R1 以降、SRX シリーズ ファイアウォール(SRX300、SRX320、SRX340、SRX345、SRX380、SRX550HM シリーズ ファイアウォールを除く)は、DH グループ 15、16、21 をサポートしています。

Junos OS リリース 20.3R1 以降、junos-ike パッケージがインストールされた vSRX 仮想ファイアウォール(vSRX 3.0)インスタンスは、DH グループ 15、16、21 に対応します。

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

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

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

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

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

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

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

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

このトピックは、以下のセクションで構成されています。

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

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

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

  • セキュアハッシュアルゴリズム(SHA)— 任意の長さのメッセージと 20 バイトの鍵から 160 ビットのハッシュを生成するアルゴリズム。より大きなハッシュを生成するため、一般的に 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 トンネル ネゴシエーション

VPNでのトラフィック交換方法を決定する次の2つの異なるモード。

  • トンネル モード - 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 8200、 インターネットプロトコル、バージョン6(IPv6)仕様

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

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月終了)

関連項目

変更履歴

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

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