メインコンテンツまでスキップ

1.1. Usage Scenarios (利用シナリオ)

1.1 Usage Scenarios (利用シナリオ)

IKE は, それぞれ特有の要件を持つさまざまなシナリオで ESP または AH の SA を交渉するために用いられる.

1.1.1. Security Gateway to Security Gateway in Tunnel Mode

               +-+-+-+-+-+            +-+-+-+-+-+
| | IPsec | |
Protected |Tunnel | tunnel |Tunnel | Protected
Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet
| | | |
+-+-+-+-+-+ +-+-+-+-+-+

Figure 1: Security Gateway to Security Gateway Tunnel

このシナリオでは, IP 接続のどちらのエンドポイントも IPsec を実装しないが, その間のネットワークノードが一部の経路でトラフィックを保護する. 保護はエンドポイントに対して透過であり, 通常のルーティングに依存してパケットを処理のためトンネルエンドポイントへ送る. 各エンドポイントは "背後" のアドレス集合をアナウンスし, パケットは内部 IP ヘッダに実際のエンドポイントの IP アドレスを含むトンネルモードで送られる.

1.1.2. Endpoint-to-Endpoint Transport Mode

  +-+-+-+-+-+                                          +-+-+-+-+-+
| | IPsec transport | |
|Protected| or tunnel mode SA |Protected|
|Endpoint |<---------------------------------------->|Endpoint |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+

Figure 2: Endpoint to Endpoint

このシナリオでは, IP 接続の両エンドポイントが IPsec を実装し, [IPSECARCH] でホストに要求される. トランスポートモードでは通常内部 IP ヘッダなしで用いられる. この SA によって保護されるパケット用に単一のアドレスペアが交渉される. これらのエンドポイントは, 参加者の IPsec 認証済みアイデンティティに基づくアプリケーション層アクセス制御を実装してもよい (MAY). このシナリオは, [ARCHPRINC], [TRANSPARENCY] 以来インターネットの指針となってきたエンドツーエンドセキュリティと, [ARCHGUIDEPHIL] が指摘するネットワークにおける複雑性の内在問題を制限する方法を可能にする. このシナリオは IPv4 インターネットに完全には当てはまらない場合もあるが, IKEv1 を用いたイントラネット内の特定シナリオでは成功裏に展開されている. IPv6 への移行と IKEv2 の採用に伴い, より広く有効にされるべきである.

このシナリオでは, 保護された一方または両方のエンドポイントが network address translation (NAT) ノードの背後にある可能性があり, その場合トンネル化パケットは UDP カプセル化が必要となり, UDP ヘッダのポート番号で NAT "背後" の個々のエンドポイントを識別する (第 2.23 節参照).

1.1.3. Endpoint to Security Gateway in Tunnel Mode

  +-+-+-+-+-+                          +-+-+-+-+-+
| | IPsec | | Protected
|Protected| tunnel |Tunnel | Subnet
|Endpoint |<------------------------>|Endpoint |<--- and/or
| | | | Internet
+-+-+-+-+-+ +-+-+-+-+-+

Figure 3: Endpoint to Security Gateway Tunnel

このシナリオでは, 保護されたエンドポイント (典型的には携帯ローミングコンピュータ) が IPsec で保護されたトンネルを通じて企業ネットワークに接続する. 企業ネット上の情報にアクセスするためだけにこのトンネルを用いる場合も, インターネットベースの攻撃に対する企業ファイアウォールの保護を利用するためにすべてのトラフィックを企業ネット経由でトンネルバックする場合もある. いずれの場合も, 保護されたエンドポイントはセキュリティゲートウェイに関連付けられた IP アドレスを望み, 返送パケットがセキュリティゲートウェイに届きトンネルバックされるようにする. この IP アドレスは静的でも, セキュリティゲートウェイによって動的に割り当てられてもよい. 後者を支援するため, IKEv2 にはイニシエータが SA の存続期間中セキュリティゲートウェイが所有する IP アドレスを要求する機構 (configuration ペイロード) が含まれる.

このシナリオではパケットはトンネルモードを用いる. 保護されたエンドポイントからの各パケットで, 外部 IP ヘッダの送信元は現在位置に関連付けられた IP アドレス (エンドポイントに直接トラフィックをルーティングするアドレス) を含み, 内部 IP ヘッダの送信元はセキュリティゲートウェイが割り当てたアドレス (セキュリティゲートウェイへルーティングされエンドポイントへ転送されるアドレス) を含む. 外部の宛先アドレスは常にセキュリティゲートウェイのものであり, 内部の宛先アドレスはパケットの最終宛先である.

このシナリオでは, 保護されたエンドポイントが NAT の背後にある可能性がある. その場合, セキュリティゲートウェイから見える IP アドレスは保護されたエンドポイントが送ったアドレスと同じではなく, パケットは適切にルーティングされるよう UDP カプセル化が必要である. NAT との相互作用は第 2.23 節で詳述する.

1.1.4. Other Scenarios

他のシナリオや上記のネストした組み合わせもあり得る. 注目すべき例は第 1.1.1 節と第 1.1.3 節の側面を組み合わせたものである. サブネットが IPsec トンネルを介してリモートセキュリティゲートウェイ経由ですべての外部アクセスを行い, インターネットの残りがサブネット上のアドレスをセキュリティゲートウェイへルーティングする場合がある. 例として, ユーザのセキュリティゲートウェイに単一の動的割り当て IP を ISP が割り当てる一方で (静的 IP と IPsec リレーは別の第三者が提供), 家庭ネットワークが静的 IP アドレスを持ち仮想的にインターネット上にある場合がある.