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 トンネルは、1 組の単一方向 SA(トンネルの各方向に 1 つの 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 技術をサポートしています。

  • 手動鍵

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

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

このトピックには、以下のセクションが含まれています。

手動鍵

手動鍵を使用すると、トンネルの両端の管理者はすべてのセキュリティ パラメーターを設定します。これは、鍵の配布、保守、追跡が困難ではない、小規模で静的なネットワークに対する実行可能な技術です。ただし、長距離に手動鍵構成を安全に配布すると、セキュリティ上の問題が発生します。鍵を対面で受け渡す以外に、転送中に鍵が侵害されていないことを完全に確認することはできません。また、鍵を変更する際には、最初に鍵を配布したときと同じセキュリティ問題が発生します。

AutoKey IKE

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

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

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

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

Diffie-Hellman エクスチェンジ

Diffie-Hellman(DH)交換により、参加者は共有秘密値を生成できます。この技術の強みは、参加者が秘密の値をワイヤーを通さずに、保護されていない媒体上に秘密値を作成できるようにすることです。各グループの計算で使用される主な係数のサイズは、以下の表に示すように異なります。Diffie Hellman(DH)交換操作は、ソフトウェアまたはハードウェアで実行できます。これらの交換操作をハードウェアで実行する場合、QuickAssist Technology(QAT)暗号化を利用します。次 表 1 に、さまざまな Diffie Hellman(DH)グループを示し、そのグループに対して実行される操作がハードウェアかソフトウェアかを示します。

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

Diffie-Hellman(DH)グループ

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

DH グループ 1

768-bit

DH グループ 2

102-bit

DH グループ 5

1536-bit

DH グループ 14

2048-bit

DH グループ 15

3072-bit

DH グループ 16

4096-bit

DH グループ 19

256 ビット楕円曲線

DH グループ 20

384 ビット楕円曲線

DH グループ 21

521 ビット楕円曲線

DH グループ 24

256ビットプライムオーダーサブグループを備えた2048ビット

Junos OS リリース 19.1R1 以降、SRX シリーズ デバイスは DH グループ 15、16、21 をサポートしています。

Junos OS リリース 20.3R1 以降、junos-ike パッケージがインストールされた vSRX インスタンスは、DH グループ 15、16、21 をサポートしています。

DH グループ 1、2、5 の使用は推奨されません。

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

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

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

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

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

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

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

このトピックには、以下のセクションが含まれています。

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

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

  • Message Digest 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(Advanced Encryption Standard):他のデバイスとの相互運用性を高める暗号化規格です。Junos OS は、128 ビット、192 ビット、256 ビットの鍵を備えた AES をサポートしています。

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

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

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

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

  • トンネル モード:元の IP パケットを VPN トンネル内の別のパケット内にカプセル化することで、トラフィックを保護します。このモードでは、IKEと事前共有鍵を使用してピアを認証し、IKEでデジタル証明書を認証してピアを認証します。これは、個別のプライベート ネットワーク内のホストがパブリック ネットワークを介して通信する場合によく使用されます。このモードは、VPN クライアントと VPN ゲートウェイの両方で使用でき、非 IPsec システムからの通信や非 IPsec システムへの通信を保護します。

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

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

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

  • RFC 2085、 HMAC-MD5 IP Authentication with Replay Prevention

  • RFC 2401、 Security Architecture for the Internet Protocol (RFC 4301 に廃止)

  • RFC 2402、 IP 認証ヘッダー (RFC 4302 に廃止)

  • RFC 2403、『The Use of HMAC-MD5-96 within ESP and AH

  • RFC 2404、 The Use of HMAC-SHA-1-96 within ESP and AH (RFC 4305 に陳腐化)

  • RFC 2405、 ESP DES-CBC 暗号アルゴリズム、Explicit IV

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

  • RFC 2407、 The Internet IP Security Domain of Interpretation for ISAKMP (RFC 4306 に廃止)

  • RFC 2408、 Internet Security Association and Key Management Protocol(ISAKMP) (RFC 4306 に廃止)

  • RFC 2409、 The Internet Key Exchange(IKE) (RFC 4306 に廃止)

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

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

  • RFC 2560、 X.509 Internet 公開鍵基盤オンライン証明書ステータス プロトコル - OCSP

  • RFC 3193,Securing L2TP using IPsec

  • RFC 3280、 Internet X.509 公開鍵基盤証明書および証明書失効リスト(CRL)プロファイル

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

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

  • RFC 4106、『 The Use of Galois/Counter Mode(GCM)in IPsec Encapsulating Security Payload(ESP)

  • RFC 4210、 Internet X.509 公開鍵基盤証明書管理プロトコル(CMP)

  • RFC 4211、 Internet X.509 公開鍵基盤証明書要求メッセージ形式(CRMF)

  • RFC 4301、 Security Architecture for the Internet Protocol

  • RFC 4302、 IP 認証ヘッダー

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

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

  • RFC 4306、 Internet Key Exchange(IKEv2)Protocol

  • RFC 4307, 暗号化アルゴリズム for Use in the Internet Key Exchange Version 2(IKEv2)

  • RFC 4308、 暗号化スイート for IPsec

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

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

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

  • RFC 5996、 Internet Key Exchange Protocol Version 2(IKEv2) (RFC 7296 に廃止)

  • RFC 7296、 Internet Key Exchange Protocol Version 2(IKEv2)

  • RFC 8200、 Internet Protocol、バージョン 6(IPv6)仕様

Junos OS は、IPsec および IKE 用に以下の RFC を部分的にサポートしています。

  • RFC 3526,More Modular Exponential(MODP)Diffie-Hellman グループ for Internet Key Exchange(IKE)

  • RFC 5114、『Additional Diffie-Hellman Groups for Use with IETF Standards

  • RFC 5903、 Elliptic Curve Groups modulo a Prime(ECP グループ)for IKE および IKEv2

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

  • RFC 2104、 HMAC: メッセージ認証のキー付きハッシュ

  • RFC 2412、 THE OAKLEY Key Determination Protocol

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

  • インターネット ドラフト draft-eastlake-sha2-02.txt、 US Secure Hash Algorithms(SHA および HMAC-SHA) (2006 年 7 月に期限切れ)

リリース履歴テーブル
リリース
説明
19.1R1
Junos OS リリース 19.1R1 以降、SRX シリーズ デバイスは DH グループ 15、16、21 をサポートしています。