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 は、IPsec を使用して2つのホストが相互に安全に通信できるようにする、シンプレックス接続です。2つのタイプのSA: 手動および動的です。

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

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

SA (セキュリティ関連) は、通信チャネルのセキュリティー強化に使用する方法とパラメーターに関して、VPN の参加者間の片方向契約です。完全な双方向通信には、各方向に1つずつ、少なくとも2つの Sa が必要です。SA を通じて、IPsec トンネルは以下のセキュリティ機能を提供できます。

  • プライバシ (暗号化を使用)

  • コンテンツの整合性 (データ認証を通じて)

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

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

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

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

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

  • キー管理方法 (手動キーまたは自動キー IKE)

  • SA ライフタイム

インバウンドトラフィックの場合、Junos OS は次の3つの方法を使用して SA を検索します。

  • 宛先 IP アドレス。

  • セキュリティープロトコル (AH または ESP)

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

アウトバウンド VPN トラフィックでは、VPN トンネルに関連付けられた SA がポリシーによって呼び出されます。

IPsec キー管理

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

  • 手動キー

  • 事前共有鍵または証明書を使用した自動キー IKE

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

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

手動キー

手動キーを使用すると、トンネルの両方のエンドの管理者がすべてのセキュリティパラメーターを構成します。これは、キーの配信、保守、および追跡が難しくない、小規模で静的なネットワークに適した手法です。ただし、長距離間で手動キー設定を安全に配布すると、セキュリティーの問題が発生します。キーを対面するだけでなく、キーが転送中に侵害されていないことを完全に確認することはできません。また、キーの変更が必要になった場合でも、初めてそれを配布したときと同じようなセキュリティの問題が発生しています。

AutoKey IKE

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

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

    事前共有鍵は、暗号化と復号化の両方にとって重要です。どちらも、通信を開始する前に、どちらの参加者にすべきかを示しています。

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

Diffie-hellman 交換

Diffie-hellman (DH) エクスチェンジを使用すると、参加者は共有シークレット値を生成できます。この手法の強度は、参加者は、通信を通して機密値を渡さずに、セキュリティ保護されていないメディアを介してシークレット値を作成できるということです。各グループの計算で使用される主な係数のサイズは、以下の表に示すように異なります。DH(Diffie Hellman)交換操作は、ソフトウェアまたはハードウェアで実行できます。これらの交換操作がハードウェアで実行される場合、QuickAssist Technology(QAT)暗号化を利用します。以下に、DH(異なる Diffie Hellman)グループをリストし、そのグループに対して実行される操作がハードウェア内かソフトウェア中かを 表 1 指定します。

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

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 プロポーザルの設定中に、セキュリティ プロトコル(認証 および暗号化アルゴリズムとも呼ばれる)を選択できます。詳細 については、 インターネット鍵交換をご覧ください。

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

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

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

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

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

  • Secure Hash Algorithm(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 つの異なるモード。

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

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

サポートされている IPsec と IKE 規格

1つ以上の ms-mpcs、mic、 または dpc を装備したルーターでは、カナダおよび米国バージョンの Junos OS が、IP セキュリティ (IPsec) およびインターネット鍵交換 (IKE) の標準を定義する以下の rfc を大幅にサポートしています。

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

  • RFC 2401,Security Architecture for the Internet Protocol(RFC 4301 に旧バージョン)

  • RFC 2402、IP Authentication Header(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、THE ESP DES-CBC Cipher Algorithm with Explicit IV

  • RFC 2406、IP Encapsulating Security ペイロード(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 インターネット鍵交換(IKE)(RFC 4306 に変更)

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

  • RFC 2451,The ESP CBC-Mode Cipher Algorithms(CBC モード暗号アルゴリズム)

  • RFC 2460、Internet Protocol、Version 6(IPv6)

  • RFC 2560、X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

  • RFC 3193, Securing L2TP using IPsec

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

  • RFC 3602, The AES-CBC Cipher Algorithm and Its use with IPsec

  • RFC 3948, UDP カプセル化 of IPsec ESP パケット

  • RFC 4106, The Use of Galois/Counter Mode(GCM)in IPsec Encapsulating Security ペイロード(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 Encapsulating Security ペイロード(ESP)

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

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

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

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

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

  • RFC 4754,IKE IKEv2 認証 Using the Elliptic Curve Digital Signature Algorithm(ECDSA)

  • RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating Security ペイロード(ESP)and Authentication Header(AH)

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

Junos OS 一部は IPsec と IKE に対応する以下の Rfc をサポートしています。

  • RFC 3526, More Modular Exponential(MODP) Diffie-Hellman グループ for インターネット鍵交換(IKE)

  • RFC 5114、Additional Diffie-Hellman グループ for use with IETF Standards

  • RFC 5903、Elliptic Curve Groups modulo a Prime(ECP Groups)for IKE IKEv2

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

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

  • RFC 2412 The OAKLEY Key Determination Protocol

  • RFC 3706, A Traffic-Based Method of Detect dead インターネット鍵交換(IKE ピア)

  • インターネット ドラフト draft-eastlake-sha2-02.テキスト 、US Secure Hash Algorithms(SHA および HMAC-SHA)( 有効期限は 2006 年 7 月)

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