IPsec の概要
セキュリティ アソシエーションの概要
IPsecセキュリティ サービスを使用するには、ホスト間で SAを作成します。SA は、2 つのホストが IPsec によって安全に相互に通信できるようにするシンプレックス接続です。SA には、手動と動的の 2 種類があります。
手動 SA にはネゴシエーションは必要ありません。キーを含むすべての値は静的であり、設定で指定されます。手動 SA は、使用する SPI(セキュリティ パラメータ インデックス)の値、アルゴリズム、および鍵を静的に定義し、トンネルの両端で一致する設定が必要です。各ピアには、通信が実行されるために同じ設定されたオプションがある必要があります。
ダイナミック SA には追加の設定が必要です。ダイナミックSAでは、最初に IKE を設定してから、SAを設定します。IKE は動的なセキュリティ アソシエーションを作成します。IPsec のために SA をネゴシエートします。IKE 設定は、ピアセキュリティゲートウェイとのセキュア IKE 接続を確立するのに使用するアルゴリズムと鍵を定義します。この接続は、動的IPsec SAで使用されるキーやその他のデータを動的に同意するために使用されます。IKE SA は、最初にネゴシエートされ、次に動的 IPsec SA を決定するネゴシエーションを保護するために使用されます。
トンネル属性のネゴシエーションや鍵管理など、ユーザーレベルのトンネルまたは SA を設定します。これらのトンネルは、同じセキュア チャネル上で更新および終了することもできます。
Junos OS の IPsec の実装は、2 つのセキュリティ モード(トランスポート モード と トンネル モード)をサポートします。
関連項目
IKE 鍵管理プロトコルの概要
IKE は、動的 SAを作成する鍵管理プロトコルです。 IPsec のために SA をネゴシエートします。IKE 設定は、ピア セキュリティ ゲートウェイとのセキュアな接続を確立するのに使用されるアルゴリズムと鍵を定義します。
IKE は以下を実行します。
IKE および IPsec パラメータのネゴシエートおよび管理
セキュアな鍵交換の認証
パスワードではなく、共有された秘密鍵と公開鍵による相互ピア認証の提供
ID 保護の提供(メイン モード)
IKE は 2 つのフェーズで発生します。第 1 段階では、セキュリティ属性をネゴシエートし、双方向 IKE SA を形成する共有シークレットを確立します。第 2 フェーズでは、インバウンドおよびアウトバウンドの IPsec SA が確立されます。IKE SA は、第 2 フェーズで交換を保護します。IKE は、キー情報の生成、完全転送機密保持の提供、ID の交換も行います。
Junos OS Release 14.2 以降、jnxIkeTunnelTable テーブル内の jnxIkeTunnelEntry オブジェクトの SNMP ウォークを実行すると、 Request failed: OID not increasing
エラーメッセージが生成されることがある。この問題は、SA の両端が同時に IKE SA ネゴシエーションを開始するときに、同時にインターネット キー交換セキュリティ アソシエーション (IKE SA) が作成された場合にのみ発生します。IKE SA を表示するために SNMP MIB ウォークが実行される場合、snmpwalk ツールはオブジェクト識別子(OID)の昇順であると想定します。ただし、同時IKE SAの場合、SNMPテーブルのOIDが昇順にならない場合があります。この動作は、OID の一部であるトンネル ID が、IKE SA のイニシエーターに基づいて割り当てられるために発生します。これは、IKE トンネルのどちらの側にも配置できます。
IKE 同時 SA で実行される SNMP MIB ウォークの例を次に示します。
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
SNMP ウォークがトンネル ID(47885 および 47392)の場合、OID 比較は失敗します。SNMP ウォークの実行時には、トンネルがどちらの側からでも開始される可能性があるため、トンネル ID の昇順であることを保証することはできません。
この問題を回避するために、SNMP MIB ウォークには、増加する OID のチェックを無効にするオプション -Cc が含まれています。以下は、-Ccオプションを使用してjnxIkeTunnelEntryテーブルで実行されるMIBウォークの例です。
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
関連項目
Junos-FIPS の IPsec 要件
Junos-FIPS 環境では、ルーティング エンジン間のすべての通信に IPsec とプライベート ルーティング インスタンスを使用するように、2 つのルーティング エンジンを持つハードウェア構成を構成する必要があります。ルーティングエンジンとAS II FIPS PIC間のIPsec通信も必要です。
関連項目
IPsec の概要
IP セキュリティ (IPsec) は、IP ネットワーク上の安全なプライベート通信を確保するための標準ベースのフレームワークです。IPsec は、送信者を認証し、ルーターやホストなどのネットワーク デバイス間の IP バージョン 4(IPv4)およびバージョン 6(IPv6)トラフィックを暗号化するセキュアな方法を提供します。IPsec には、データの整合性、送信者の認証、ソース データの機密性、およびデータ リプレイに対する保護が含まれています。
理解する必要がある主な概念は次のとおりです。
IPsec対応ラインカード
Junos OSベースのルーターにIPsecを実装する場合、まず選択する必要があるのは、使用するラインカードのタイプです。ラインカードという用語には、PIC(物理インターフェイスカード)、MIC(モジュラーインターフェイスカード)、DPC(高密度ポートコンセントレータ)、MPC(モジュラーポートコンセントレータ)が含まれます。次のラインカードは、IPsec実装をサポートしています。
ルーターのラインカードがIPsecをサポートしているかどうかを確認するには、ルーターのハードウェアマニュアルを参照してください。
次のラインカードはIPsecをサポートしています。
暗号化サービス(ES)PICは、IPsecの暗号化サービスとソフトウェアサポートを提供します。
アダプティブ サービス(AS)PIC とアダプティブ サービス(AS)II PIC は、IPsec サービスのほか、ネットワーク アドレス変換(NAT)やステートフル ファイアウォールなどのサービスを提供します。
AS II 連邦情報処理標準(FIPS)PIC は、内部 IPsec を使用してルーティング エンジンと安全に通信するAS PIC の特別なバージョンです。ルーターで FIPS モードを有効にする場合は、AS II FIPS PIC で IPsec を設定する必要があります。FIPS モードで設定されたルーターにインストールされた AS II FIPS PIC への IPsec 実装の詳細については、 コモンクライテリアと Junos-FIPS のセキュアな設定ガイドを参照してください。
マルチサービスPICは、パケット処理を多用する一連のサービスにハードウェアアクセラレーションを提供します。これらのサービスには、IPsec サービスのほか、ステートフル ファイアウォール、NAT、IPsec、異常検知、トンネル サービスなどのサービスが含まれます。
マルチサービス高密度ポート コンセントレータ(DPC)は、IPsec サービスを提供します。
マルチサービス モジュラー ポート コンセントレータ(MS-MPC)は、IPsec サービスをサポートします。
マルチサービス モジュラー インターフェイス カード(MS-MIC)は、IPsec サービスをサポートしています。
IPsec サービス パッケージを含む Junos OS 拡張プロバイダ パッケージは、MS-MPC および MS-MIC に事前インストールおよび設定されています。
関連項目
認証アルゴリズム
認証は、送信者の身元を確認するプロセスです。認証アルゴリズムは、共有キーを使用して IPsec デバイスの信頼性を検証します。Junos OSは、以下の認証アルゴリズムを使用します。
Message Digest 5(MD5)は、一方向ハッシュ関数を使用して、任意の長さのメッセージを 128 ビットの固定長メッセージ ダイジェストに変換します。変換プロセスのため、元のメッセージを結果のメッセージ ダイジェストから逆算して計算することは数学的に不可能です。同様に、メッセージ内の 1 文字を変更すると、非常に異なるメッセージ ダイジェスト番号が生成されます。
メッセージが改ざんされていないことを確認するために、Junos OS は計算されたメッセージ ダイジェストを、共有鍵で復号化されたメッセージ ダイジェストと比較します。Junos OSは、追加レベルのハッシュを提供するMD5ハッシュメッセージ認証コード(HMAC)バリアントを使用します。MD5 は、AH(認証ヘッダー)、ESP(セキュリティ ペイロードのカプセル化)、IKE(インターネット鍵交換)で使用できます。
セキュア ハッシュ アルゴリズム 1(SHA-1)は、MD5 よりも強力なアルゴリズムを使用します。SHA-1 は、長さが 264 ビット未満のメッセージを受け取り、160 ビットのメッセージ ダイジェストを生成します。ラージ・メッセージ・ダイジェストは、データが変更されていないこと、およびデータが正しいソースから発信されたことを保証します。Junos OS は、追加レベルのハッシュを提供する SHA-1 HMAC バリアントを使用します。SHA-1 は、AH、ESP、IKE で使用できます。
SHA-256、SHA-384、および SHA-512 (SHA-2 という名前でグループ化されることもあります) は SHA-1 のバリアントであり、より長いメッセージ ダイジェストを使用します。Junos OSは、AES(高度暗号化規格)、DES(データ暗号化規格)、3DES(トリプルDES)暗号化のすべてのバージョンを処理できるSHA-2のSHA-256バージョンをサポートしています。
暗号化アルゴリズム
暗号化によってデータが安全な形式にエンコードされるため、権限のないユーザーがデータを解読することはできません。認証アルゴリズムと同様に、共有キーは暗号化アルゴリズムとともに使用され、IPsecデバイスの信頼性を検証します。Junos OSは、以下の暗号化アルゴリズムを使用します。
データ暗号化標準暗号ブロック連鎖 (DES-CBC) は、対称秘密鍵ブロック アルゴリズムです。DES は 64 ビットの鍵サイズを使用し、8 ビットはエラー検出に使用され、残りの 56 ビットは暗号化を提供します。DES は、置換や置換など、共有キーに対して一連の単純な論理操作を実行します。CBC は、DES から出力の 64 ビットの最初のブロックを取得し、このブロックを 2 番目のブロックと結合し、これを DES アルゴリズムにフィードバックし、後続のすべてのブロックに対してこのプロセスを繰り返します。
トリプル DES-CBC (3DES-CBC) は、DES-CBC に似た暗号化アルゴリズムですが、168 ビット (3 x 56 ビット) 暗号化に 3 つのキーを使用するため、はるかに強力な暗号化結果が得られます。3DES は、最初のキーを使用してブロックを暗号化し、2 番目のキーを使用してブロックを復号化し、3 番目のキーを使用してブロックを再暗号化します。
高度暗号化標準(AES)は、ベルギーの暗号学者であるJoan Daemen博士とVincent Rijmen博士によって開発されたRijndaelアルゴリズムに基づく次世代の暗号化方法です。128 ビット ブロックと 3 つの異なるキー サイズ (128、192、および 256 ビット) を使用します。鍵サイズに応じて、アルゴリズムは、バイト置換、列混合、行シフト、およびキー追加を含む一連の計算 (10、12、または 14 ラウンド) を実行します。AES と IPsec の組み合わせは、RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec で定義されています。
Junos OS リリース 17.3R1 以降、MS-MPC および MS-MIC では、ガロア/カウンター モード(AES-GCM)の高度暗号化規格がサポートされます。しかし、Junos FIPSモードでは、AES-GCMはJunos OSリリース17.3R1ではサポートされていません。Junos OS リリース 17.4R1 以降、AES-GCM は Junos FIPS モードでサポートされます。AES-GCM は、認証とプライバシーの両方を提供するように設計された認証済み暗号化アルゴリズムです。AES-GCMは、バイナリガロアフィールド上でユニバーサルハッシュを使用して認証された暗号化を提供し、数十Gbpsのデータレートで認証された暗号化を可能にします。
関連項目
IPsec プロトコル
IPsec プロトコルは、ルーターによって保護されているパケットに適用される認証と暗号化の種類を決定します。Junos OS は、以下の IPsec プロトコルをサポートしています。
AH—RFC 2402で定義されているAHは、IPv4およびIPv6パケットのコネクションレスの整合性とデータ送信元の認証を提供します。また、リプレイに対する保護も提供します。AH は、IP ヘッダーに加え上位プロトコル データをできる限り認証します。ただし、一部の IP ヘッダー フィールドがトランジットで変更される場合があります。これらのフィールドの値は送信者から予測可能ではないため、AH によって保護できません。IP ヘッダーでは、IPv4 パケットの
Protocol
フィールドおよび IPv6 パケットのNext Header
フィールドの値が51
で、AH を識別できます。AHが提供するIPsec保護の例を図1に示します。手記:AH は、T シリーズ、M120、および M320 ルーターではサポートされていません。
ESP—RFC 2406で定義されているESPは、暗号化と制限されたトラフィックフローの機密性、またはコネクションレスの整合性、データ送信元の認証、およびアンチリプレイサービスを提供できます。IPヘッダーでは、IPv4パケットの
Protocol
フィールドとIPv6パケットのNext Header
フィールドの50
の値でESPを識別できます。ESP が提供する IPsec 保護の例を図 2 に示します。
バンドル:AH と ESP を比較する場合、両方のプロトコルにいくつかの利点と欠点があります。ESPは適切なレベルの認証と暗号化を提供しますが、IPパケットの一部に対してのみ提供します。逆に、AH は暗号化を提供しませんが、IP パケット全体の認証を提供します。このため、Junos OSでは、プロトコルバンドルと呼ばれる第3の形式のIPsecプロトコルを提供しています。バンドル オプションは、AH 認証と ESP 暗号化のハイブリッドな組み合わせを提供します。
関連項目
変更履歴テーブル
機能のサポートは、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がプラットフォームでサポートされているかどうかを判断します。
Request failed: OID not increasing
エラーメッセージが生成されることがある。