ネットワークワーキンググループ
Request for Comments: 2709
分類: 情報提供
P. Srisuresh
Lucent Technologies
1999年10月
 

NAT ドメインにおけるトンネルモード IPsec 利用セキュリティモデル
(Security Model with Tunnel-mode IPsec for NAT Domains)

このメモの位置付け 
このメモは、インターネットコミュニティに対して情報提供を行うものです。
いかなる種類のインターネット標準も、このメモでは指定していません。
このメモの配布に制限はありません。
著作権
Copyright (C) The Internet Society (1999). All Rights Reserved.
要旨 
[Ref 1] に記述されているように、NAT には様々な種類があります。
NAT によってサポートされているドメインでは、レルム(realm:領域)特有の IP クライアントのみが終点間の IPsec による安全なセッションを確立することができます。
しかしながら、すべての種類の NAT は、外部のレルムに属するノードと通信するプライベートドメインホストに対して、トンネルモードの IPsec セキュリティを提供することができます。
この文書では、NAT 装置によってトンネルモード IPsec セキュリティを実現するセキュリティモデルについて記述します。
IKE(自動鍵交換のために利用される)のクイックモードによってセキュリティポリシーを提供する方法についても 1 つの章を使って記述します。
また、ここで説明するセキュリティモデルの有用な適用例についても紹介します。
1. 導入および概要 
NAT 装置は、異なるアドレスを持つレルムから通信しようとする末端ホストに対して、IP ヘッダやトランスポート層ヘッダに修正を加えることにより、透過的なルーティングを提供するものです。
この手法は、エンドユーザの識別子(ホスト名のようなもの)が、エンドユーザを位置づけるために使用されるアドレスとは異なる場合に、良好に動作します。

終点間におけるアプリケーションレベルのペイロードのセキュリティは、複数のエンドユーザのうちの一人には意味のないような、レルム特有の情報をペイロード中に含まないアプリケーションに提供されます。
ペイロード中にレルム特有の情報を含むアプリケーションは、両方のレルムにとって意味のあるペイロードにするために、アプリケーションレベルゲートウェイ(ALG)を必要とします。
しかしながら、経路上の ALG による補助を必要とするアプリケーションは、終点間のアプリケーションレベルのセキュリティを確保することはできません。
NAT 装置が IPsec トンネルの終点として動作する場合は、ALG による補助を必要とするかどうかに関係なく、NAT 装置を通過する全てのアプリケーションは、IPsec トンネルモードによるセキュリティの恩恵を受けることができます。

次の第 2 章では、この文書に特有の用語について定義します。

第 3 章では、どのようにトンネルモードの IPsec セキュリティが、NAT 装置上で認識されるのかについて記述します。
IPsec セキュリティのアーキテクチャや、様々な種類のセキュリティメカニズムのフォーマットおよび動作については、[Ref 2][Ref 3][Ref 4] を参照して下さい。
この章では、IPsec ゲートウェイとして動作する NAT 装置と外部の通信相手ノードとの間での、セッション鍵やポリシーの交換の方法については記述しません。
その交換は、手動で行うこともできますし、現在知られている自動交換手法のうちのいずれかを使用して行うこともできます。

第 4 章では、公開鍵ベースの IKE プロトコル [Ref 5] が、セキュリティポリシーや、セッション鍵、そしてその他のセキュリティアソシエーション(SA)の属性の自動交換に利用される場合を想定しています。
この章では、プライベートドメインで管理されるセキュリティポリシーを、外部ノードと通信するために変換する方法について記述します。
IKE プロトコルの動作についての詳細は、[Ref 5] と [Ref 6] に記述されています。

第 5 章では、この文書で記述されるセキュリティモデルの適用例について記述します。
ここでは適用例として、プライベートドメインホストの外部レルムとの安全な接続と、企業モバイルホストの安全なリモートアクセスを取り上げます。

2. 用語 
この文書で使用される用語の大半は、(a)「NAT Terminology and Considerations」文書 [Ref 1]、(b)「IP security Architecture」文書 [Ref 2]、(c)「Internet Key Enchange (IKE)」文書 [Ref 5] のいずれかにおいて定義されています。
この文書のために特別に定義される用語は、以下の通りです。
2.1. ノーマル NAT 
「ノーマル NAT」という用語は、通常の NAT 処理を、IPsec セキュアトンネル内に格納されるセキュアパケットに対して適用する NAT 処理から区別するために使用されます。
「ノーマル NAT」とは、[Ref 1] において記述されている、通常 NAT 処理です。
2.2. IPsec ポリシー制御 NAT(IPC-NAT) 
「IPsec ポリシー制御 NAT」(短く、IPC-NAT と呼ぶ)は、NAT ノードがトンネルの終端である IP-IP トンネル内に格納されるパケットに対して、IPsec 変換の拡張を施した NAT 変換を記述するために定義します。
IPC-NAT 機能は、基本的に、トンネルモード IPsec に格納されたパケットに対して NAT 拡張を適用するものです。
IPC-NAT 処理が施されたパケットは、NAT 装置と外部の通信相手のエンティティ(ホストまたはゲートウェイノード)との間で IPsec セキュリティを受けることになります。

使用される NAT マッピングの種類は、IPsec ポリシーによって制限がかけられます。
例えば、通信相手のゲートウェイに対する IPsec のアクセス制御セキュリティポリシーは、あるアドレスやポート番号に対してのみに通信を制限する可能性があります。
そのため、NAT が変換を行う際には、セキュリティポリシーと矛盾がないように行われることを保証しなければなりません。

IPC-NAT 機能は、ノーマル NAT はもちろん、伝統的 NAT(Traditional-NAT)、両方向 NAT(Bi-directional-NAT)、両変換 NAT(Twice-NAT)を含む、どのような種類の NAT をも想定することができます。
IPC-NAT 装置は、IPC-NAT 機能と ノーマル NAT 機能の両方をサポートします。

3. IPC-NAT のセキュリティモデル 
IP セキュリティアーキテクチャ文書 [Ref 2] には、全体的に一意のアドレスを持つレルムの中で、IP ネットワークレベルのセキュリティを実現させる方法が記述されています。
また、トランスポートモードおよびトンネルモードにおけるセキュリティについて議論されています。
この文書の目的から、特に指定しない限り、IPsec セキュリティは、トンネルモードの IPsec セキュリティを意味するものとします。
このセキュリティアーキテクチャの基本要素は、(a)どのパケットにセキュリティ処理を施すことを許可するのかを決定する「セキュリティポリシー」、そして(b)適用する IPsec プロトコルやアルゴリズム、セッション鍵を含む、セキュリティ処理のためのパラメータを識別する「セキュリティアソシエーション属性」です。

ネットワークアドレス変換をサポートしない装置上での、トンネルモード IPsec セキュリティの動作を、下の図 1 および図 2 に示します。

            +---------------+  No  +---------------------------+
            |               | +--->|Forward packet in the Clear|
   Outgoing |Does the packet| |    |Or Drop, as appropriate.   |
   -------->|match Outbound |-|    +---------------------------+
   Packet   |Security       | |    +-------------+
            |Policies?      | |Yes |Perform      | Forward
            |               | +--->|Outbound     |--------->
            +---------------+      |Security     | IPsec Pkt
                                   |(Tunnel Mode)|
                                   +-------------+

   図 1. 出力パケットに対するトンネルモード IPsec の動作


   IPsec packet +----------+          +----------+
   destined to  |Perform   | Embedded |Does the  | No(Drop)
   ------------>|Inbound   |--------->|Pkt match |-------->
   the device   |Security  | Packet   |Inbound SA| Yes(Forward)
                |(Detunnel)|          |Policies? |
                +----------+          +----------+

   図 2. 入力パケットに対するトンネルモード IPsec の動作

トンネルモード IPsec セキュリティを提供する NAT 装置は、プライベートレルムでのアドレス体系に沿ってセキュリティポリシーを管理することが要求されます。
さらに、そのセキュリティポリシーによって、IPsec トンネルの終端が決定されます。
結果として、パケットは、IPsec ノードの通信相手となるトンネルの終端によって異なる種類の NAT 変換を受ける必要があるかもしれません。
つまり、IPC-NAT は、設定されたそれぞれのセキュリティポリシーに対して、一意な NAT マップのセットを必要とするということです。
IPC-NAT は、セキュリティポリシーに沿って、それぞれの通信相手に対して別々に IPsec 処理と連携したアドレス変換を行います。
以下の図(図 3 および図 4)は、NAT と連携した IPsec トンネリングの動作について示しています。
IPC-NAT の動作は、NAT をサポートしない IPsec ゲートウェイの動作とは以下のように異なります。

  1. IPC-NAT 装置は、プライベートレルムでのアドレス体系により管理されるセキュリティポリシーを持つ。
    伝統的な IPsec ゲートウェイは、単一レルム(つまり外部レルム)のアドレス体系により管理されるセキュリティポリシーを持つ。

  2. IPC-NAT 装置のセキュリティモデルの基本要素には、セキュリティポリシーと SA 属性に関連した IPC-NAT アドレスマッピング(およびその他の NAT パラメータ定義)が含まれる。
    伝統的な IPsec ゲートウェイの基本要素は、セキュリティポリシーと SA 属性にのみに限られる。

            +---------------+      +-------------------------+
            |               |  No  | Apply Normal-NAT or Drop|
   Outgoing |Does the packet| +--->| as appropriate          |
   -------->|match Outbound |-|    +-------------------------+
   Packet   |Security       | |    +---------+  +-------------+
   (Private |Policies?      | |Yes |Perform  |  |Perform      |Forward
    Domain) |               | +--->|Outbound |->|Outbound     |-------->
            +---------------+      |NAT      |  |Security     |IPsec Pkt
                                   |(IPC-NAT)|  |(Tunnel mode)|
                                   +---------+  +-------------+

   図 3. 出力パケットに対する IPC-NAT 装置上のトンネルモード IPsec


   IPsec Pkt +----------+          +---------+  +----------+
   destined  |Perform   | Embedded |Perform  |  |Does the  |No(Drop)
   --------->|Inbound   |--------->|Inbound  |->|Pkt match |-------->
   to device |Security  | Packet   |NAT      |  |Inbound SA|Yes(Forward)
   (External |(Detunnel)|          |(IPC-NAT)|  |Policies? |
    Domain)  +----------+          +---------+  +----------+

   図 4. 入力パケットに対する IPC-NAT 装置上のトンネルモード IPsec

伝統的 NAT は、外部へのセッションのみに対して変換を許可する、セッション依存となっています。
他の全ての種類の NAT は、双方向です。
いずれか、または全ての種類の NAT マッピングは、セキュリティポリシーと IPC-NAT 装置でのセキュア処理と関連して使用されるかもしれません。
この文書で図示する場合には、双方向 NAT 装置でのトンネルモード IPsec を想定します。

しかしながら、IPsec トンネルを越えてセキュリティを提供することの可能な NAT 装置は、パケットに対して、IPC-NAT を必要としない ノーマル NAT をサポートし続けることができることに注意して下さい。
ノーマル NAT と IPC-NAT のためのアドレスマッピングやその他の NAT パラメータの定義は、異なります。
図 3 では、NAT 装置が、出力パケットに対して、ノーマル NAT と IPC-NAT のどちらを通して処理する必要があるのかを区別する方法について示しています。
外部レルムから入ってくるパケットに関しては、図 4 でパケットに IPC-NAT が施される様子を示します。
その他の全てのパケットは、ノーマル NAT 処理のみが施されます。

4. IPC-NAT 装置上での IKE プロトコルの動作 
前章で記述した IPC-NAT の動作は、通信するエンティティ間で、手動でセッション鍵交換を行うか、自動鍵交換プロトコルを使用することによって実現されます。
この章では、セキュリティポリシーと SA パラメータの自動交換のために、IPC-NAT 装置上で、IETF で推奨されている「インターネット鍵交換(IKE)プロトコル」を適用することとします。
つまり、NAT 装置上のトンネルモード IPsec と連携した IKE の動作に焦点を当てます。
この章では、特に指定のない限り、NAT 装置は、IPC-NAT 装置を指すものとしますので注意してください。

IKE は UDP プロトコルをベースとしており、また、セッション鍵やその他の属性をアドレスレルムを越えて安全に交換するために、公開鍵暗号を使用します。
IP に関しての IKE の詳細なプロトコルと動作は、[Ref 3] と [Ref 4] に記述されています。
基本的に、IKE は 2 つのフェーズからなります。

最初のフェーズでは、IKE の通信相手同士は、メインモードまたはアグレッシブモードのどちらかを使用して、互いに認証し、その間に安全な通信路を構築します。
NAT 装置は、外部レルムとのインタフェースを持ちます。 NAT 装置は、外部の相手ノードとフェーズ 1 をネゴシエイトするという意味では、そのレルムの他のノードと変わりはありません。
NAT 装置は、そのレルムの相手と通信し、認証するために必要な有効な識別タイプと認証方式を想定するかもしれません。
NAT 装置は、また、証明書を検索し、署名の有効性を検証するために、そのレルムの認証局(CA)とのインタフェースを持つかもしれません。

2 番目のフェーズでは、IKE の通信相手同士は、クイックモードを使用して、ポリシーと、セキュリティ変換アルゴリズムや、ポリシー、鍵、有効期間、およびその他のセキュリティ属性をネゴシエイトし、合意するための IPsec セキュリティのプロポーザルを交換します。
このフェーズの間は、IKE プロセスは、(a)相手の IKE ノードとネゴシエイトするためのセキュアセッション属性やその他のパラメータを収集するため、そして(b)ネゴシエーションの間に(相手と)合意したセキュリティパラメータを通知するために、IPsec エンジンと通信しなければなりません。

IPsec ゲートウェイとして動作している IPC-NAT 装置は、プライベートレルムのアドレス体系をベースとして管理されるセキュリティポリシーを持っています。
IKE プロセスが外部レルムの通信相手とポリシーを交換する必要があるため、ALG はプライベートレルムのアドレス体系から、外部レルムのアドレス体系へポリシーを変換する必要があります。
ここで、IKE データグラムには、NAT 処理を施さないことに注意して下さい。
IKE-ALG は、IKE ペイロードのある部分を、単純にポリシーマッチングのために定義された NAT マップに従って変換します。
以下の図では、IKE-ALG プロセスが、セキュリティポリシーと IPC-NAT マップを入手するための IPC-NAT とのインタフェース、そして、IKE がクイックモードの間に外部レルムの相手と通信可能となるセキュリティポリシーを生成する方法について示しています。

クイックモードでのポリシーは、IDci ペイロードと IDcr ペイロードの組み合わせとして通信相手と交換されます。
それぞれの相手によって交換された ID(ポリシー)の組み合わせは、どちらかの終点の SA パラメータが一様に適用されるために、あわなければなりません。
もし、ID が交換されない場合には、SA パラメータをネゴシエイトしたクイックモードは、メインモードによって想定された IP アドレスの間に適用されると想定します。

セキュリティポリシーの性質に適切に従うことにより(例:2 つのノード間の終点間セッションと、アドレス範囲のセッション)、IKE-ALG は NAT に対して、セッションがネゴシエイトする有効期間(秒数またはキロバイト数)のために、アドレスのバインディングやトランスポートのバインディングの設定を要求する必要があるかもしれません。
ALG が、必要なアドレスバインディングやトランスポートバインディングの設定に失敗した場合には、IKE-ALG は、セキュリティポリシーを変換できず、影響されたポリシーに対する IKE のフェーズ 2 ネゴシエーションができない状態となります。

ネゴシエーションが完了し、成功した場合には、以下の図に示すように、IKE はネゴシエイトされたセキュリティパラメータを、IPC-NAT ゲートウェイエンジンに直接伝えます。

                                        +---------+
                                        |         |
        Negotiated Security Parameters  |  IKE    |
       +--------------------------------| Process |
       |(including session Keys)        |         |
       |                                +---------+
       |                                   ^   ^
       |                         Translated|   |
       |                             Secure|   |Security
       |                           Policies|   |Proposals
       v                                   |   |
   +---------+ Security Policies, based +---------+
   |         |------------------------->|         |
   |         | on Pvt. realm addressing |         |
   | IPC-NAT |                          |         |
   | (IPsec  | IPC-NAT MAPs             | IKE-ALG |
   | Gateway)|------------------------->|         |
   |         |                          |         |
   |         | Security Proposals       |         |
   |         |------------------------->|         |
   |         |                          |         |
   |         |  NAT Control exchange    |         |
   |         |<------------------------>|         |
   +---------+                          +---------+

   図 5. IKE-ALG での NAT マップを利用したセキュリティポリシーの変換
5. IPC-NAT セキュリティモデルの適用例 
これまでに記述した IPC-NAT の動作モデルでは、NAT 装置を、外部レルムとの安全なデータ転送を提供するために IPsec トンネルの終端として使用する方法について示しています。
この章では、このようなモデルでの 2 つの適用例について示します。
5.1. 安全なエクストラネット接続 
IPC-NAT モデルには、NAT 装置を使用することによって、外部レルムとのクリアで安全な接続を提供することが可能な直接の適用例があります。
特に、プライベートレルムの境界の IPC-NAT 装置は、エクストラネット接続を安全にする目的で、外部ドメインの IPsec ゲートウェイと通信することが可能です。
エクストラネットとは、通信するゲートウェイノードの間にインターネットを介した通信路の部分を言います。
5.2. 企業のモバイルユーザに対する安全なリモートアクセス 
企業のノードが企業の外へ移動し、リモートのサイトから一時的なサービスプロバイダが付与したアドレス(気付アドレス:Care-of-Address)を使用して、その企業へ接続しようとする場合を考えてみます。
このような場合には、モバイルユーザは、事前に合意されたユーザ ID と認証メカニズムを使用して、企業の IPC-NAT 装置との間に IPsec トンネルセッションを確立することができます。
さらに、IKE のフェーズ 1 に続く認証の拡張として、企業の DNS サーバが設定されるかもしれません。
これにより、ユーザは企業の資源に名前によってアクセスすることができるようになります。

しかしながら、多くの企業サーバとアプリケーションは、認証を送信元 IP アドレスに依存しており、企業のアドレス空間から生成されていないパケットのアクセスは拒否されます。
このような場合には、(伝統的な IPsec ゲートウェイとは異なり)IPC-NAT は、パケットがプライベートレルムにある間は、外部レルム内の一時的なアドレスが企業ドメインのアドレスに変換されるように、リモートアクセスユーザのためのネットワークアドレス変換を行う機能を持っています。
IPC-NAT が実現される NAT の種類は、伝統的 NAT(つまり、モバイルユーザのアドレス空間をプライベートレルムと想定し、企業のアドレス空間を外部レルムと想定する)であるだろうし、それは、ベーシック NAT(変換に企業アドレスのブロックを利用する)または NAPT(変換に一つの企業アドレスを利用する)のどちらでも有り得ます。

ここで例として記述した安全なリモートアクセスは、企業が IANA が登録したアドレスを使用しているかどうかに関係なく、全ての企業に対して適用できます。

ここで例として記述した安全なリモートアクセスは、(この例で記述されている)移動ノードがホームネットワークのアドレスを保持し、通信用には単純に気付アドレス(Care-Of-address)を使用する Mobile-IP とは異なります。
IPC-NAT ゲートウェイは、移動ノードの気付アドレス(Care-of-address)をそのホームアドレスに対応づけることによって、移動ノードに対して透過的に Mobile-IP 的な接続を提供するものと考えられます。
しかしながら、IPC-NAT ゲートウェイに対するこのようなアドレスマッピングの提供に関しては、この文書の範囲ではありません。

6. セキュリティに関する考慮事項 
もし、NAT と ALG が信用された境界内に存在しない場合は、ALG がエンドユーザのトラフィックデータを覗くため、これは大きなセキュリティ上の問題となります。
アプリケーションレベルのペイロードに、ある一つのレルムでのみ有効な IP アドレスやトランスポート識別子を含まなければ、そのペイロードを終点間で暗号化することができます。
レルム特有の IP を除けば、現在の IPsec 技術によって保証される終点間の IP ネットワークレベルのセキュリティは、その間に NAT が存在する場合には達成することはできません。
この文書で記述した IPC-NAT モデルでは、外部レルムの中でネットワークレベルのセキュリティを得ることのできるアプローチについての概観を示しています。

NAT が ALG と共に使用される場合には、インターネットに送出されるデータグラムのヘッダやペイロードにプライベートアドレスが含まれないことを保証することができます。
これらの要件を満たさないアプリケーションは、ファイアウォールのフィルタによって破棄されるかもしれません。
この理由から、IPC-NAT と ALG、そしてファイアウォールがプライベートネットワークの境界でセキュリティを提供するために共存することは、珍しいことではありません。

参考文献 
[1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.

[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998

[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998

[4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[7] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.

[8] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

著者の連絡先 
Pyda Srisuresh
Lucent technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.

Phone: (925) 737-2153
Fax: (925) 737-2110
EMail: srisuresh@lucent.com
 

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

著作権表示全文 
Copyright (C) The Internet Society (1999). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。

謝辞 
現在、RFC エディタの機能に対する資金は、インターネットソサエティによって提供されています。