IPsec の概要
IPsec は、デバイス間の転送を保護するために使用できるプロトコルのグループです。
Feature Explorerを使用して、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 を設定します。これらのトンネルは、同じセキュア チャネル上で更新および終了することもできます。
IPsecのJunos OS実装は、2つのセキュリティモード(トランスポートモード と トンネルモード)をサポートします。
参照
IKE 鍵管理プロトコルの概要
IKE は、動的 SAを作成するキー管理プロトコルです。 IPsec の SA をネゴシエートします。IKE 構成は、ピア セキュリティ ゲートウェイとのセキュアな接続を確立するために使用されるアルゴリズムとキーを定義します。
IKE は以下を実行します。
IKE および IPsec パラメータのネゴシエートおよび管理
セキュアな鍵交換の認証
パスワードではなく、共有された秘密鍵と公開鍵による相互ピア認証の提供
ID 保護の提供(メイン モード)
IKE は 2 つのフェーズで発生します。最初のフェーズでは、セキュリティ属性をネゴシエートし、共有シークレットを確立して、双方向IKE SAを形成します。第 2 フェーズでは、インバウンドとアウトバウンドの IPsec SA が確立されます。IKE SA は、第 2 フェーズで交換を保護します。また、IKE は、鍵情報の生成、完全転送機密保持の提供、および ID の交換も行います。
Junos OS リリース 14.2以降、jnxIkeTunnelTableテーブル内のjnxIkeTunnelEntryオブジェクトのSNMPウォークを実行すると、 Request failed: OID not increasing エラーメッセージが生成される場合があります。この問題は、インターネット鍵交換セキュリティ アソシエーション(IKE SA)が同時に作成され、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 が含まれています。以下は、jnxIkeTunnelEntryテーブルで-Ccオプションを指定して実行される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 は SHA-2 の SHA-256 バージョンをサポートしており、AES(高度暗号化標準)、DES(データ暗号化標準)、3DES(トリプル DES)暗号化のすべてのバージョンを処理できます。
暗号化アルゴリズム
暗号化により、データを安全な形式にエンコードして、権限のないユーザーがデータを解読できないようにします。認証アルゴリズムと同様に、共有キーは暗号化アルゴリズムとともに使用され、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(Advanced Encryption Standard)は、ベルギーの暗号学者であるJoan Daemen博士とVincent Rijmen博士によって開発されたRijndaelアルゴリズムに基づく次世代の暗号化方式です。128ビットのブロックと3つの異なるキーサイズ(128、192、256ビット)を使用します。アルゴリズムは、キー・サイズに応じて、バイト置換、列の混合、行のシフト、およびキーの追加を含む一連の計算 (10、12、または 14 ラウンド) を実行します。IPsec と組み合わせた AES の使用については、RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec で定義されています。
Junos OS リリース 17.3R1 以降、MS-MPC と MS-MIC で AES-GCM(Galois/Counter モードの高度な暗号化標準)がサポートされています。ただし、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 ヘッダーでは、AH は、IPv4 パケットの
Protocolフィールドと IPv6 パケットのNext Headerフィールドの値51で識別できます。AH が提供する IPsec 保護の例を図 1 に示します。手記:AH は T Series、M120、および M320 ルーターではサポートされていません。
ESP - RFC 2406 で定義されている ESP は、暗号化と制限されたトラフィック フローの機密性、またはコネクションレスの整合性、データ送信元の認証、アンチリプレイ サービスを提供できます。IP ヘッダーでは、ESP は IPv4 パケットの
Protocolフィールドと IPv6 パケットのNext Headerフィールドの50の値で識別できます。ESP が提供する IPsec 保護の例を図 2 に示します。
バンドル:AH と ESP を比較すると、どちらのプロトコルにもいくつかの長所と短所があります。ESP は適切なレベルの認証と暗号化を提供しますが、これは IP パケットの一部に対してのみ行われます。逆に、AH は暗号化を提供しませんが、IP パケット全体の認証を提供します。このため、Junos OS では、プロトコル バンドルと呼ばれる IPsec プロトコルの第 3 の形式を提供しています。バンドル オプションでは、AH 認証と ESP 暗号化のハイブリッドな組み合わせが提供されます。
参照
SRXシリーズデバイスでサポートされているIKEおよびIPsec暗号
以下の表を使用して、お使いのSRXシリーズプラットフォームでサポートされている暗号方式を確認してください。
| 暗号方式(IKE) |
SRX1500 |
SRX1600 |
SRX2300、SRX4120 |
SRX4100、SRX4200、SRX4300 |
SRX4600、SRX4700 |
SRX5400、SRX5600、SRX5800 |
|---|---|---|---|---|---|---|
| AES-128-GCM |
はい |
はい |
はい |
はい |
はい |
はい |
| AES-192-GCM |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
| AES-256-GCM |
はい |
はい |
はい |
はい |
はい |
はい |
| 暗号方式 (IPSec) |
SRX1500 |
SRX1600 |
SRX2300、SRX4120 |
SRX4100、SRX4200、SRX4300 |
SRX4600、SRX4700 |
SRX5400、SRX5600、SRX5800 |
|---|---|---|---|---|---|---|
| AES-128-GCM |
はい |
はい |
はい |
はい |
はい |
はい |
| AES-192-GCM |
はい |
はい |
はい |
はい |
はい |
はい |
| AES-256-GCM |
はい |
はい |
はい |
はい |
はい |
はい |
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。
Request failed: OID not increasing エラーメッセージが生成される場合があります。