Network Working Group P. Srisuresh
Request for Comments: 2709 Lucent Technologies
Category: Informational October 1999
Security Model with Tunnel-mode IPsec for NAT Domains
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.
著作権（C）インターネット協会（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.
[参照1]で説明したようにNAT風味の様々ながあります。 NATのでサポートされているドメインの、唯一のレルム固有のIPクライアントは、エンドツーエンドのIPsecの安全なセッションを追求することができます。しかし、NATのすべての種類は、外部レルム内のノードとのピアリングプライベートドメインホストにトンネルモードのIPsecセキュリティを提供することができます。この文書では、トンネルモードの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デバイスは、EN-ルート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.
エンドツーエンドのアプリケーションレベルのペイロードのセキュリティは、エンドユーザーのいずれかに無意味であるペイロードにおけるレルム固有情報を埋め込むないアプリケーションのために提供することができます。ペイロードに埋め込むレルム固有の情報を行うアプリケーションは、両方のレルム内のペイロードが有意義にするためにアプリケーションレベルゲートウェイ（ALG）を必要とするであろう。しかし、ALGエンルートの援助を必要とするアプリケーションは、エンドツーエンドのアプリケーション・レベルのセキュリティを追求することはできません。
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.
NATデバイスを通過するすべてのアプリケーションは、かかわらず、それらはALGの援助を必要とするか否かを、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のセキュリティアーキテクチャ、フォーマットおよびセキュリティメカニズムの様々なタイプの動作は、[参考文献2]に見出すことができる[参考文献3]及び[参考文献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プロトコル[参考文献5]は、セキュリティポリシー、セッションキーとその他のセキュリティアソシエーション（SA）属性の交換を自動化するために使用することができることを前提としています。このセクションでは、プライベートドメインのために投与セキュリティポリシーは、外部ノードと通信するために翻訳されるかもしれない方法を説明しています。 IKEプロトコルの動作の詳細な説明は、[参考文献5]に見出すことができ、[参考文献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用語と考慮事項文書の一つで見つけることができる[参考文献1]、（b）は、IPセキュリティアーキテクチャ文書[参考文献2]、または（c）インターネット鍵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処理を区別するために導入されます。 「ノーマルNAT」は、[参考文献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.
用語（略してIPC-NAT）「NATを制御IPSecポリシーは、」NATノードがトンネルエンドポイントされたIP-IPトンネル内に埋め込まれたパケットへのIPsec変換の拡張として適用NAT変換を記述するために定義されています。 IPC-NAT機能は、本質的に、トンネル・モードの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.
NATマッピングが使用されているかについてのIPsecポリシーの場所の制限。例えば、ピア・ゲートウェイへの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.
普通-NATと同様に、IPC-NAT機能は、従来の-NATを含め、双方向-NATとトワイスNATのNAT風味のいずれかをとることができます。 IPC-NATデバイスは、IPC-NATと通常-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セキュリティアーキテクチャ文書[参照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.
図発信パケットのトンネルモードのIPsecの1.操作。
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
着信パケットのトンネルモードのIPsecの図2.動作
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.
(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
発信パケット数のためのIPC-NATデバイス上の図3のトンネル・モードの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) +----------+ +---------+ +----------+
Figure 4. Tunnel-Mode IPsec on an IPC-NAT device for Incoming pkts
着信パケット数のためのIPC-NATデバイス上の図4のトンネル・モードの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対ノーマル、NATによって処理する必要が発信パケットを区別どのように識別します。外部レルムからの着信パケットについては、図4は、IPC-NATを受ける可能性があるパケットを概説します。他のすべてのパケットは通常、NAT処理の対象となっています。
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動作が手動セッション鍵交換又はピアリングエンティティ間の自動化された鍵交換プロトコルを使用することに基づいて行うことができます。このセクションでは、IETFは、セキュリティポリシーとSAパラメータの自動交換のためのIPC-NATデバイスのインターネット鍵交換（IKE）プロトコルを推奨適応を検討します。言い換えれば、我々は、NATデバイス上のトンネルモードのIPsecと連動してIKEの動作に焦点を当てます。このセクションのリマインダのために、私たちは、特に指定がない限り、IPC-NATデバイスを意味する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の詳細なプロトコル及び動作中に見出すことができる[参考文献3]及び[参考文献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.
第一段階では、IKEピアが互いを認証し、それらの間でセキュアチャネルを設定するメインまたはアグレッシブモードで動作します。 NATデバイスは、外部領域へのインタフェースを有し、ピア、外部ノードと相Iを交渉するためにレルム内の他のノードからの違いはありません。 NATデバイスが通信し、レルム内のピアで認証するために必要な有効なIdentityタイプと認証方法のいずれかをとることができます。 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.
第二段階では、IKEピアがセキュリティ変換アルゴリズム、ポリシー、鍵、寿命およびその他のセキュリティ属性に交渉し、合意するポリシーおよびIPsecセキュリティ提案を交換するクイックモードで動作します。このフェーズでは、IKEプロセスは、（a）は、ピアIKEノードとネゴシエートするセキュア・セッション属性および他のパラメータを収集すること、及び（b）は、セキュリティパラメータを通知するためのIPsecエンジンと通信しなければならないネゴシエーション中に（ピアに）合意。
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.
IPC-NATデバイスは、IPsecゲートウェイとして動作し、取り組む民間分野に基づいて投与されたセキュリティポリシーを持っています。 IKEプロセスは、外部レルム内のピアにこれらのポリシーを通信する必要があるとして、ALGは、アドレス指定の外部に取り組む民間分野からポリシーを変換する必要があります。 IKEデータグラムは、任意のNAT処理の対象にはなりません、注意してください。 IKE-ALGは単にポリシー一致のために定義されNATマップに従ってIKEペイロードの選択部分を変換します。次の図は、IPC-NATとIKE-ALGプロセスインタフェースは、セキュリティポリシーと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は、セキュリティポリシーを翻訳すると、それが影響ポリシーのフェーズIIネゴシエーションを追求していないIKEになりますことはできません。
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.
、企業の企業の外に移動し、アドレス（気付アドレス）が割り当てられ、一時的なサービスプロバイダを使用して、リモートサイトから企業に接続しようとする試みからノードを言います。このような場合には、モバイルユーザが設定合意されたユーザ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は、リモートアクセスユーザーのためのネットワークアドレス変換（NAT）を実行する（従来のIPsecゲートウェイとは違って）能力を持っています民間分野。 IPC-NATの風味が実行される基本的な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は、アドレスを登録していないか、使用するかどうかの、すべての企業に適切です。
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は、信頼境界にない場合、それはのALGスヌープエンドユーザトラフィックペイロードとして、主要なセキュリティ上の問題です。アプリケーションレベルのペイロードは限りペイロードが一つだけのレルムに有効なIPアドレスおよび/またはトランスポート識別子が含まれていないとして、エンドツーエンドの暗号化することができます。レルム固有の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は、のALGと組み合わせると、インターネットに注入されたデータグラムは、ヘッダやペイロードに何のプライベートアドレスを持っていないことを確認することができます。これらの要件を満たしていないアプリケーションでは、ファイアウォールのフィルタを使用して削除することができます。このため、IPC-NATの、のALGとファイアウォールは、プライベートネットワークの境界にセキュリティを提供するために共存することを見つけることは珍しいことではありません。
REFERENCES
REFERENCES
[1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[1] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998
[2]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998
[3]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月
[4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[4]ケント、S.とR.アトキンソン、 "IP認証ヘッダ"、RFC 2402、1998年11月。
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[5]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[6]パイパー、D.、 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、RFC 2407、1998年11月。
[7] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
[7]カーペンター、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、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.、モスコウィッツ、B.、Karrenberg、D.、デ・グルートG.およびE.リア、 "個人的なインターネットのための配分"、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ルーセント・テクノロジー4464ウィロー・ロードプレザントン、CA 94588から8519 U.S.A.
Phone: (925) 737-2153 Fax: (925) 737-2110 EMail: srisuresh@lucent.com
電話：（925）737-2153ファックス：（925）737-2110 Eメール：srisuresh@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。