[要約] RFC 2709は、NATドメインにおけるトンネルモードIPsecのセキュリティモデルに関するものです。このRFCの目的は、NAT環境でのIPsecのセキュリティを向上させるためのガイドラインを提供することです。
Network Working Group P. Srisuresh
Request for Comments: 2709 Lucent Technologies
Category: Informational October 1999
Security Model with Tunnel-mode IPsec for NAT Domains
NATドメイン用のトンネルモードIPSECを使用したセキュリティモデル
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described.
[Ref 1]に記載されているように、さまざまなNATフレーバーがあります。NATによってサポートされているドメインのうち、レルム固有のIPクライアントのみがエンドツーエンドのIPSECセッションセッションを追求できます。ただし、NATのすべてのフレーバーは、外部領域のノードを使用してピアリングをホストするプライベートドメインにトンネルモードIPSECセキュリティを提供することができます。このドキュメントでは、Tunnel-Mode IPSECセキュリティをNATデバイスでアーキテクチャ化できるセキュリティモデルについて説明します。セクションは、クイックモード中にセキュリティポリシーをIKE（自動化されたキー交換用）に透過的に通信する方法を説明することに専念しています。また、説明されているセキュリティモデルの恩恵を受けることができるアプリケーションも概説されています。
NAT devices provide transparent routing to end hosts trying to communicate from disparate address realms, by modifying IP and transport headers en-route. This solution works best when the end user identifier (such as host name) is different from the address used to locate end user.
NATデバイスは、IPおよびトランスポートヘッダーをエンラウトすることにより、異なるアドレスレルムから通信しようとするホストを終了するための透明なルーティングを提供します。このソリューションは、エンドユーザー識別子（ホスト名など）がエンドユーザーを見つけるために使用されるアドレスとは異なる場合に最適に機能します。
End-to-end application level payload security can be provided for applications that do not embed realm-specific information in payloads that is meaningless to one of the end-users. Applications that do embed realm-specific information in payload will require an application level gateway (ALG) to make the payload meaningful in both realms. However, applications that require assistance of an ALG en-route cannot pursue end-to-end application level security.
エンドツーエンドのアプリケーションレベルのペイロードセキュリティは、エンドユーザーの1人にとって無意味なペイロードにレルム固有の情報を埋め込まないアプリケーションに提供できます。ペイロードにレルム固有の情報を埋め込んだアプリケーションでは、両方のレルで有意義なペイロードをするために、アプリケーションレベルゲートウェイ（ALG）が必要です。ただし、ALG En-Routeの支援を必要とするアプリケーションは、エンドツーエンドのアプリケーションレベルのセキュリティを追求することはできません。
All applications traversing a NAT device, irrespective of whether they require assistance of an ALG or not, can benefit from IPsec tunnel-mode security, when NAT device acts as the IPsec tunnel end point.
ALGの支援が必要かどうかに関係なく、NATデバイスを通過するすべてのアプリケーションは、NATデバイスがIPSECトンネルエンドポイントとして機能する場合、IPSECトンネルモードセキュリティの恩恵を受けることができます。
Section 2 below defines terms specific to this document.
以下のセクション2は、このドキュメントに固有の用語を定義しています。
Section 3 describes how tunnel mode IPsec security can be recognized on NAT devices. IPsec Security architecture, format and operation of various types of security mechanisms may be found in [Ref 2], [Ref 3] and [Ref 4]. This section does not address how session keys and policies are exchanged between a NAT device acting as IPsec gateway and external peering nodes. The exchange could have taken place manually or using any of known automatic exchange techniques.
セクション3では、トンネルモードIPSECセキュリティをNATデバイスでどのように認識できるかについて説明します。IPSECセキュリティアーキテクチャ、さまざまなタイプのセキュリティメカニズムの形式、および操作は、[Ref 2]、[Ref 3]、および[Ref 4]に記載されている場合があります。このセクションでは、IPSECゲートウェイと外部ピアリングノードとして機能するNATデバイスとの間でセッションキーとポリシーがどのように交換されるかについては説明していません。交換は、手動で行われたか、既知の自動交換技術のいずれかを使用していた可能性があります。
Section 4 assumes that Public Key based IKE protocol [Ref 5] may be used to automate exchange of security policies, session keys and other Security Association (SA) attributes. This section describes a method by which security policies administered for a private domain may be translated for communicating with external nodes. Detailed description of IKE protocol operation may be found in [Ref 5] and [Ref 6].
セクション4では、公開キーベースのIKEプロトコル[Ref 5]を使用して、セキュリティポリシー、セッションキー、その他のセキュリティ協会（SA）属性の交換を自動化できると想定しています。このセクションでは、外部ノードと通信するためにプライベートドメインに管理されるセキュリティポリシーを翻訳する方法について説明します。IKEプロトコル操作の詳細な説明は、[Ref 5]および[Ref 6]に記載されている場合があります。
Section 5 describes applications of the security model described in the document. Applications listed include secure external realm connectivity for private domain hosts and secure remote access to enterprise mobile hosts.
セクション5では、ドキュメントに記載されているセキュリティモデルのアプリケーションについて説明します。リストされているアプリケーションには、プライベートドメインホストの安全な外部レルム接続が含まれ、エンタープライズモバイルホストへの安全なリモートアクセスが含まれます。
Definitions for majority of terms used in this document may be found in one of (a) NAT Terminology and Considerations document [Ref 1], (b) IP security Architecture document [Ref 2], or (c) Internet Key Enchange (IKE) document [Ref 5]. Below are terms defined specifically for this document.
このドキュメントで使用されている用語の大部分の定義は、（a）NAT用語と考慮事項ドキュメント[Ref 1]、（b）IPセキュリティアーキテクチャドキュメント[Ref 2]、または（c）Internet Key Enchange（IKE）のいずれかに記載されている場合があります。文書[参照5]。以下は、このドキュメントに特に定義されている用語です。
The term "Normal-NAT" is introduced to distinguish normal NAT processing from the NAT processing used for secure packets embedded within an IPsec secure tunnel. "Normal-NAT" is the normal NAT processing as described in [Ref 1].
「通常のNAT」という用語は、IPSECセキュアトンネル内に埋め込まれた安全なパケットに使用されるNAT処理と通常のNAT処理を区別するために導入されます。[ref 1]で説明されているように、「通常のナット」は通常のNAT処理です。
The term "IPsec Policy Controlled NAT" (IPC-NAT, for short) is defined to describe the NAT transformation applied as an extension of IPsec transformation to packets embedded within an IP-IP tunnel, for which the NAT node is a tunnel end point. IPC-NAT function is essentially an adaptation of NAT extensions to embedded packets of tunnel-mode IPsec. Packets subject to IPC-NAT processing are beneficiaries of IPsec security between the NAT device and an external peer entity, be it a host or a gateway node.
「IPSECポリシーコントロールNAT」（略してIPC-NAT）という用語は、IP-IPトンネルに埋め込まれたIPSEC変換の拡張として適用されるNAT変換を記述するために定義されます。。IPC-NAT関数は、本質的に、Tunnel-Mode IPSECの埋め込みパケットへのNAT拡張機能の適応です。IPC-NAT処理の対象となるパケットは、ホストであろうとゲートウェイノードであろうと、NATデバイスと外部ピアエンティティ間のIPSECセキュリティの受益者です。
IPsec policies place restrictions on what NAT mappings are used. For example, IPsec access control security policies to a peer gateway will likely restrict communication to only certain addresses and/or port numbers. Thus, when NAT performs translations, it must insure that the translations it performs are consist with the security policies.
IPSECポリシーNATマッピングが使用するものに制限があります。たとえば、ピアゲートウェイへのIPSECアクセス制御セキュリティポリシーは、特定のアドレスおよび/またはポート番号のみに通信を制限する可能性があります。したがって、NATが翻訳を実行する場合、実行する翻訳がセキュリティポリシーで構成されていることを保証する必要があります。
Just as with Normal-NAT, IPC-NAT function can assume any of NAT flavors, including Traditional-NAT, Bi-directional-NAT and Twice-NAT. An IPC-NAT device would support both IPC-NAT and normal-NAT functions.
通常のナットと同様に、IPC-NAT関数は、従来のナット、双方向ナット、2回のナットなど、NATフレーバーのいずれかを想定できます。IPC-NATデバイスは、IPC-NATとNorm-NAT機能の両方をサポートします。
The IP security architecture document [Ref 2] describes how IP network level security may be accomplished within a globally unique address realm. Transport and tunnel mode security are discussed. For purposes of this document, we will assume IPsec security to mean tunnel mode IPsec security, unless specified otherwise. Elements fundamental to this security architecture are (a) Security Policies, that determine which packets are permitted to be subject to Security processing, and (b) Security Association Attributes that identify the parameters for security processing, including IPsec protocols, algorithms and session keys to be applied.
IPセキュリティアーキテクチャドキュメント[Ref 2]は、グローバルにユニークなアドレスの領域内でIPネットワークレベルのセキュリティがどのように達成されるかを説明しています。輸送およびトンネルモードのセキュリティについて説明します。このドキュメントの目的のために、IPSECセキュリティは、特に指定されていない限り、トンネルモードIPSECセキュリティを意味すると仮定します。このセキュリティアーキテクチャの基本的な要素は、（a）セキュリティ処理の対象となるパケットを決定するセキュリティポリシー、および（b）IPSECプロトコル、アルゴリズム、セッションキーを含むセキュリティ処理のパラメーターを識別するセキュリティ協会の属性を決定することです。適用されます。
Operation of tunnel mode IPsec security on a device that does not support Network Address Translation may be described as below in figures 1 and 2.
ネットワークアドレスの変換をサポートしていないデバイス上のトンネルモード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)|
+-------------+
Figure 1. Operation of Tunnel-Mode IPsec on outgoing packets.
図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? |
+----------+ +----------+
Figure 2. Operation of Tunnel-Mode IPsec on Incoming packets
図2.着信パケット上のトンネルモードIPSECの操作
A NAT device that provides tunnel-mode IPsec security would be required to administer security policies based on private realm addressing. Further, the security policies determine the IPsec tunnel end-point peer. As a result, a packet may be required to undergo different type of NAT translation depending upon the tunnel end-point the IPsec node peers with. In other words, IPC-NAT will need a unique set of NAT maps for each security policy configured. IPC-NAT will perform address translation in conjunction with IPsec processing differently with each peer, based on security policies. The following diagrams (figure 3 and figure 4) illustrate the operation of IPsec tunneling in conjunction with NAT. Operation of an IPC-NAT device may be distinguished from that of an IPsec gateway that does not support NAT as follows.
プライベートレルムアドレス指定に基づいてセキュリティポリシーを管理するには、トンネルモードIPSECセキュリティを提供するNATデバイスが必要です。さらに、セキュリティポリシーがIPSECトンネルエンドポイントピアを決定します。その結果、IPSECノードのピアがトンネルのエンドポイントに応じて、異なるタイプのNAT翻訳を受けるにはパケットが必要になる場合があります。言い換えれば、IPC-NATは、構成された各セキュリティポリシーに一意のNATマップセットが必要です。IPC-NATは、セキュリティポリシーに基づいて、各ピアとは異なるIPSEC処理と組み合わせてアドレス変換を実行します。次の図（図3および図4）は、NATと併せてIPSECトンネルの動作を示しています。IPC-NATデバイスの動作は、次のようにNATをサポートしないIPSECゲートウェイの動作と区別される場合があります。
(1) IPC-NAT device has security policies administered using private realm addressing. A traditional IPsec gateway will have its security policies administered using a single realm (say, external realm) addressing.
(1) IPC-NATデバイスには、プライベートレルムアドレス指定を使用して管理されたセキュリティポリシーがあります。従来のIPSECゲートウェイには、単一の領域（外部領域）のアドレス指定を使用して、セキュリティポリシーが管理されます。
(2) Elements fundamental to the security model of an IPC-NAT device includes IPC-NAT address mapping (and other NAT parameter definitions) in conjunction with Security policies and SA attributes. Fundamental elements of a traditional IPsec gateway are limited only to Security policies and SA attributes.
(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)|
+---------+ +-------------+
Figure 3. Tunnel-Mode IPsec on an IPC-NAT device for outgoing pkts
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) +----------+ +---------+ +----------+
Figure 4. Tunnel-Mode IPsec on an IPC-NAT device for Incoming pkts
図4.着信PKTS用のIPC-NATデバイス上のトンネルモードIPSEC
Traditional NAT is session oriented, allowing outbound-only sessions to be translated. All other flavors of NAT are Bi-directional. Any and all flavors of NAT mapping may be used in conjunction with the security policies and secure processing on an IPC-NAT device. For illustration purposes in this document, we will assume tunnel mode IPsec on a Bi-directional NAT device.
従来のNATはセッション指向であり、アウトバウンドのみのセッションを翻訳することができます。NATの他のすべてのフレーバーは双方向です。NATマッピングのすべてのフレーバーは、IPC-NATデバイスでのセキュリティポリシーと安全な処理と組み合わせて使用できます。このドキュメントの図のために、双方向NATデバイスのトンネルモードIPSECを想定します。
Notice however that a NAT device capable of providing security across IPsec tunnels can continue to support Normal-NAT for packets that do not require IPC-NAT. Address mapping and other NAT parameter definitions for Normal-NAT and IPC-NAT are distinct. Figure 3 identifies how a NAT device distinguishes between outgoing packets that need to be processed through Normal-NAT vs. IPC-NAT. As for packets incoming from external realm, figure 4 outlines packets that may be subject to IPC-NAT. All other packets are subject to Normal-NAT processing only.
ただし、IPSECトンネル全体でセキュリティを提供できるNATデバイスは、IPC-NATを必要としないパケットの通常のNATを引き続きサポートできることに注意してください。通常のNATおよびIPC-NATのアドレスマッピングおよびその他のNATパラメーター定義は異なります。図3は、NATデバイスが通常のナットとIPC-NATを介して処理する必要がある発信パケットをどのように区別するかを示しています。外部領域からのパケットについては、図4はIPC-NATの対象となる可能性のあるパケットの概要を示しています。他のすべてのパケットは、通常の処理のみの対象となります。
4. Operation of IKE protocol on IPC-NAT device.
4. IPC-NATデバイスでのIKEプロトコルの操作。
IPC-NAT operation described in the previous section can be accomplished based on manual session key exchange or using an automated key Exchange protocol between peering entities. In this section, we will consider adapting IETF recommended Internet Key Exchange (IKE) protocol on a IPC-NAT device for automatic exchange of security policies and SA parameters. In other words, we will focus on the operation of IKE in conjunction with tunnel mode IPsec on NAT devices. For the reminder of this section, we will refer NAT device to mean IPC-NAT device, unless specified otherwise.
前のセクションで説明したIPC-NAT操作は、手動セッションのキー交換に基づいて、またはピアリングエンティティ間の自動化されたキー交換プロトコルを使用して実現できます。このセクションでは、セキュリティポリシーとSAパラメーターの自動交換のために、IETF推奨インターネットキー交換（IKE）プロトコルをIPC-NATデバイスに適応させることを検討します。言い換えれば、NATデバイスのトンネルモードIPSECと併せてIKEの操作に焦点を当てます。このセクションのリマインダーについては、特に指定されていない限り、NATデバイスを平均IPC-NATデバイスと呼びます。
IKE is based on UDP protocol and uses public-key encryption to exchange session keys and other attributes securely across an address realm. The detailed protocol and operation of IKE in the context of IP may be found in [Ref 3] and [Ref 4]. Essentially, IKE has 2 phases.
IKEはUDPプロトコルに基づいており、パブリックキー暗号化を使用して、アドレスの領域全体でセッションキーやその他の属性を安全に交換します。IPのコンテキストでのIKEの詳細なプロトコルと動作は、[Ref 3]および[Ref 4]に記載されている場合があります。基本的に、Ikeには2つのフェーズがあります。
In the first phase, IKE peers operate in main or aggressive mode to authenticate each other and set up a secure channel between themselves. A NAT device has an interface to the external realm and is no different from any other node in the realm to negotiate phase I with peer external nodes. The NAT device may assume any of the valid Identity types and authentication methodologies necessary to communicate and authenticate with peers in the realm. The NAT device may also interface with a Certification Authority (CA) in the realm to retrieve certificates and perform signature validation.
第1フェーズでは、IKEピアはメインモードまたは攻撃的なモードで動作し、お互いを認証し、自分自身の間に安全なチャネルを設定します。NATデバイスには、外部領域へのインターフェイスがあり、ピア外部ノードとフェーズIをネゴシエートするために、領域内の他のノードと違いはありません。NATデバイスは、領域内のピアと通信および認証するために必要な有効なIDタイプと認証方法論を想定する場合があります。NATデバイスは、証明書を取得して署名検証を実行するために、領域内の認証機関（CA）とインターフェイスすることもできます。
In the second phase, IKE peers operate in Quick Mode to exchange policies and IPsec security proposals to negotiate and agree upon security transformation algorithms, policies, keys, lifetime and other security attributes. During this phase, IKE process must communicate with IPsec Engine to (a) collect secure session attributes and other parameters to negotiate with peer IKE nodes, and to (b) notify security parameters agreed upon (with peer) during the negotiation.
第2フェーズでは、IKEピアはクイックモードで運用してポリシーとIPSECセキュリティ提案を交換し、セキュリティ変換アルゴリズム、ポリシー、キー、生涯、その他のセキュリティ属性について交渉し、同意します。この段階では、IKEプロセスはIPSECエンジンと通信して、（a）ピアIKEノードと交渉するための安全なセッション属性およびその他のパラメーターを収集し、（b）交渉中に（ピアと）合意されたセキュリティパラメーターに通知する必要があります。
An IPC-NAT device, operating as IPsec gateway, has the security policies administered based on private realm addressing. An ALG will be required to translate policies from private realm addressing into external addressing, as the IKE process needs to communicate these policies to peers in external realm. Note, IKE datagrams are not subject to any NAT processing. IKE-ALG simply translates select portions of IKE payload as per the NAT map defined for the policy match. The following diagram illustrates how an IKE-ALG process interfaces with IPC-NAT to take the security policies and IPC-NAT maps and generates security policies that IKE could communicate during quick mode to peers in the external realm.
IPSECゲートウェイとして動作するIPC-NATデバイスには、プライベートレルムアドレス指定に基づいてセキュリティポリシーが管理されています。IKEプロセスは、これらのポリシーを外部領域のピアに伝える必要があるため、ポリシーをプライベートレルムから外部アドレス指定に変換するためにALGが必要になります。IKEデータグラムは、NAT処理の対象ではありません。Ike-Algは、ポリシーマッチで定義されたNATマップに従って、ikeペイロードの一部の部分を単純に翻訳します。次の図は、IKE-ALGプロセスがIPC-NATとインターフェイスしてセキュリティポリシーとIPC-NATマップを取得し、IKEがクイックモード中に外部領域のピアに通信できるセキュリティポリシーをどのように生成するかを示しています。
Policies in quick mode are exchanged with a peer as a combination of IDci and IDcr payloads. The combination of IDs (policies) exchanged by each peer must match in order for the SA parameters on either end to be applied uniformly. If the IDs are not exchanged, the assumption would be that the Quick mode negotiated SA parameters are applicable between the IP addresses assumed by the main mode.
クイックモードのポリシーは、IDCIとIDCRペイロードの組み合わせとしてピアと交換されます。各ピアによって交換されるID（ポリシー）の組み合わせは、両端のSAパラメーターを均一に適用するために一致する必要があります。IDが交換されていない場合、クイックモードネゴシエートされたSAパラメーターがメインモードで想定されるIPアドレス間に適用されると仮定します。
Depending on the nature of security policies in place(ex: end-to-end sessions between a pair of nodes vs. sessions with an address range), IKE-ALG may need to request NAT to set up address bindings and/or transport bindings for the lifetime (in seconds or Kilo-Bytes) the sessions are negotiated. In the case the ALG is unable to setup the necessary address bindings or transport bindings, IKE-ALG will not be able to translate security policies and that will result in IKE not pursuing phase II negotiation for the effected policies.
配置されているセキュリティポリシーの性質に応じて（例：一対のノードとアドレス範囲のセッション間のエンドツーエンドのセッション）、IKE-ALGは、アドレスバインディングおよび/または輸送バインディングを設定するためにNATを要求する必要がある場合があります生涯（秒またはキロバイト）の場合、セッションは交渉されます。ALGが必要なアドレスバインディングまたはトランスポートバインディングをセットアップできない場合、Ike-Algはセキュリティポリシーを翻訳できず、IKEが影響を受けたポリシーのフェーズII交渉を追求しません。
When the Negotiation is complete and successful, IKE will communicate the negotiated security parameters directly to the IPC-NAT gateway engine as described in the following diagram.
交渉が完全かつ成功した場合、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 | |
| |<------------------------>| |
+---------+ +---------+
Figure 5. IKE-ALG translates Security policies, using NAT Maps.
図5. Ike-Algは、NATマップを使用してセキュリティポリシーを変換します。
IPC-NAT operational model described thus far illustrates how a NAT device can be used as an IPsec tunnel end point to provide secure transfer of data in external realm. This section will attempt to illustrate two applications of such a model.
これまでに説明されているIPC-NAT運用モデルは、NATデバイスをIPSECトンネルエンドポイントとして使用して、外部領域でのデータの安全な転送を提供する方法を示しています。このセクションでは、このようなモデルの2つのアプリケーションを説明しようとします。
IPC-NAT Model has a direct application of being able to provide clear as well as secure connectivity with external realm using a NAT device. In particular, IPC-NAT device at the border of a private realm can peer with an IPsec gateway of an external domain to secure the Extranet connection. Extranet refers to the portion of the path that crosses the Internet between peering gateway nodes.
IPC-NATモデルには、NATデバイスを使用して外部領域との明確な接続と安全な接続を提供できるという直接的なアプリケーションがあります。特に、プライベートレルムの境界にあるIPC-NATデバイスは、外部ドメインのIPSECゲートウェイでピアでき、エクストラネット接続を保護できます。エクストラネットとは、ピアリングゲートウェイノードの間でインターネットを横断するパスの部分を指します。
Say, a node from an enterprise moves out of the enterprise, and attempts to connect to the enterprise from remote site, using a temporary service provider assigned address (Care-of-Address). In such a case, the mobile user could setup an IPsec tunnel session with the corporate IPC-NAT device using a user-ID and authentication mechanism that is agreed upon. Further, the user may be configured with enterprise DNS server, as an extension of authentication following IKE Phase I. This would allow the user to access enterprise resources by name.
たとえば、エンタープライズからのノードはエンタープライズから外れ、一時的なサービスプロバイダーが割り当てられたアドレス（Care-of-Address）を使用して、リモートサイトからエンタープライズに接続しようとします。そのような場合、モバイルユーザーは、合意されたユーザーIDと認証メカニズムを使用して、企業IPC-NATデバイスとのIPSECトンネルセッションをセットアップできます。さらに、ユーザーは、IKEフェーズIに続く認証の拡張として、エンタープライズDNSサーバーで構成される場合があります。これにより、ユーザーは名前でエンタープライズリソースにアクセスできます。
However, many enterprise servers and applications rely on source IP address for authentication and deny access for packets that do not originate from the enterprise address space. In these scenarios, IPC-NAT has the ability (unlike a traditional IPsec gateway) to perform Network Address Translation (NAT) for remote access users, so their temporary address in external realm is translated into a enterprise domain address, while the packets are within private realm. The flavor of IPC-NAT performed would be traditional NAT (i.e., assuming mobile-user address space to be private realm and Enterprise address space to be external realm), which can either be Basic NAT (using a block of enterprise addresses for translation) or NAPT(using a single enterprise address for translation).
ただし、多くのエンタープライズサーバーとアプリケーションは、認証のためにソースIPアドレスに依存しており、エンタープライズアドレススペースに由来しないパケットのアクセスを拒否しています。これらのシナリオでは、IPC-NATには（従来のIPSECゲートウェイとは異なり）リモートアクセスユーザーのネットワークアドレス変換（NAT）を実行する機能があるため、外部領域の一時アドレスはエンタープライズドメインアドレスに変換され、パケットは内部にあります。プライベートレルム。実行されるIPC-NATのフレーバーは、従来のNAT（つまり、モバイルユーザーアドレス空間がプライベートレルムであると仮定し、エンタープライズアドレススペースが外部領域であると仮定します）。またはNAPT（翻訳に単一のエンタープライズアドレスを使用）。
The secure remote access application described is pertinent to all enterprises, irrespective of whether an enterprise uses IANA registered addresses or not.
説明されている安全なリモートアクセスアプリケーションは、IANAがIANA登録アドレスを使用しているかどうかに関係なく、すべての企業に関連しています。
The secure remote access application described is different from Mobile-IP in that, the mobile node (described in this application) does not retain the Home-Network address and simply uses the Care-Of-address for communication purposes. It is conceivable for the IPC-NAT Gateway to transparently provide Mobile-IP type connectivity to the Mobile node by binding the mobile node's Care-of-Address with its Home Address. Provision of such an address mapping to IPC-NAT gateway, however, is not within the scope of this document.
記載されている安全なリモートアクセスアプリケーションは、モバイルIPとは異なります。これは、モバイルノード（このアプリケーションで説明）はホームネットワークアドレスを保持せず、通信目的でアドレスドレスのケアを使用するだけです。IPC-NATゲートウェイが、モバイルノードのアドレスレスを自宅の住所にバインドすることにより、モバイルIPタイプの接続をモバイルノードに透過的に提供することが考えられます。ただし、IPC-NATゲートウェイへのこのようなアドレスマッピングの提供は、このドキュメントの範囲内ではありません。
If NATs and ALGs are not in a trusted boundary, that is a major security problem, as ALGs snoop end user traffic payload. Application level payload could be encrypted end-to-end, so long as the payload does not contain IP addresses and/or transport identifiers that are valid in only one of the realms. With the exception of Realm-Specific IP, end-to-end IP network level security assured by current IPsec techniques is not attainable with NATs in between. The IPC-NAT model described in this document outlines an approach by which network level security may be obtained within external realm.
NATとALGが信頼できる境界にない場合、それはALGS Snoopエンドユーザートラフィックペイロードとして、大きなセキュリティの問題です。ペイロードにIPアドレスが含まれていない限り、アプリケーションレベルのペイロードはエンドツーエンドで暗号化できます。Realm固有のIPを除き、現在のIPSEC技術によって保証されたエンドツーエンドのIPネットワークレベルセキュリティは、その間のNATで達成できません。このドキュメントで説明されているIPC-NATモデルは、外部領域内でネットワークレベルのセキュリティを取得できるアプローチの概要を示しています。
NATs, when combined with ALGs, can ensure that the datagrams injected into Internet have no private addresses in headers or payload. Applications that do not meet these requirements may be dropped using firewall filters. For this reason, it is not uncommon to find that IPC-NATs, ALGs and firewalls co-exist to provide security at the border of a private network.
NATは、ALGSと組み合わせると、インターネットに注入されたデータグラムにヘッダーまたはペイロードにプライベートアドレスがないことを確認できます。これらの要件を満たさないアプリケーションは、ファイアウォールフィルターを使用して削除される場合があります。このため、IPCナット、アルグ、ファイアウォールが共存してプライベートネットワークの境界線でセキュリティを提供することは珍しくありません。
REFERENCES
参考文献
[1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[1] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998
[2] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998
[3] Kent、S。and R. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月
[4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[4] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[5] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[6] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[7] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
[7] Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
[8] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[8] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot G.およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
Author's Address
著者の連絡先
Pyda Srisuresh Lucent technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A.
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
電話：（925）737-2153ファックス：（925）737-2110メール：srisuresh@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。