< draft-ietf-nat-security-01.txt		draft-ietf-nat-security-02.txt >
	NAT Working Group P. Srisuresh		NAT Working Group P. Srisuresh
	INTERNET-DRAFT Lucent Technologies		INTERNET-DRAFT Lucent Technologies
	Category: Informational February 1999		Category: Informational August 1999
	Expire in six months		Expire in six months
	Security Model for Network Address Translator (NAT) Domains		Security Model with Tunnel-mode IPsec for NAT Domains
	<draft-ietf-nat-security-01.txt>		<draft-ietf-nat-security-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026.		with all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 37 ¶
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	There are a variety of NAT flavors, as described in [Ref 1]. Of the		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		domains supported by NATs, only Realm-Specific IP clients are able
	to pursue end-to-end IPsec secure sessions. However, all flavors of		to pursue end-to-end IPsec secure sessions. However, all flavors of
	NAT can offer network level tunnel-mode IPsec security to private		NAT are capable of offering tunnel-mode IPsec security to private
	domain hosts peering with nodes in external realm. This document		domain hosts peering with nodes in external realm. This document
	describes a security model by which tunnel-mode IPsec security can		describes a security model by which tunnel-mode IPsec security can
	be architected on NAT devices. A section is devoted to describing		be architected on NAT devices. A section is devoted to describing
	how secure policies may be transparently communicated to IKE (for		how security policies may be transparently communicated to IKE (for
	automated KEY exchange) during Quick Mode. Applications that can		automated KEY exchange) during Quick Mode. Also outlined are
	benefit from the secure NAT model are also outlined in the end.		applications that can benefit from the Security Model described.
	1. Introduction and Overview		1. Introduction and Overview
	NATs provide transparent routing to end hosts trying to communicate		NAT devices provide transparent routing to end hosts trying to
	from disparate routing realms, by modifying IP and transport headers		communicate from disparate address realms, by modifying IP and
	en-route. This solution works best when the end user identifier		transport headers en-route. This solution works best when the end
	(such as host name) is different from the address used to locate		user identifier (such as host name) is different from the address
	end user.		used to locate end user.
	End-to-end transport level payload security can be provided for		End-to-end application level payload security can be provided for
	applications that do not embed realm-specific information that is		applications that do not embed realm-specific information in
	meaningless to one of the end-users. Applications that do embed		payloads that is meaningless to one of the end-users. Applications
	realm-specific information will require an application level		that do embed realm-specific information in payload will require an
	gateway (ALG) to make the payload meaningful in both realms.		application level gateway (ALG) to make the payload meaningful in
	However, applications that require assistance of an ALG en-route		both realms. However, applications that require assistance of an ALG
	cannot pursue end-to-end transport level security.		en-route cannot pursue end-to-end application level security.
	All applications traversing a NAT device, irrespective of whether		All applications traversing a NAT device, irrespective of whether
	they require assistance of an ALG or not, can benefit from IPsec		they require assistance of an ALG or not, can benefit from IPsec
	tunnel-mode security, when NAT device acts as the IPsec tunnel		tunnel-mode security, when NAT device acts as the IPsec tunnel
	end point.		end point.
	Section 2 below defines terms specific to this document.		Section 2 below defines terms specific to this document.
	Section 3 describes how tunnel mode IPsec security can be		Section 3 describes how tunnel mode IPsec security can be
	recognized on NAT devices. IPsec Security architecture, format and		recognized on NAT devices. IPsec Security architecture, format and
	operation of various types of security mechanisms may be found in		operation of various types of security mechanisms may be found in
	[Ref 2], [Ref 3] and [Ref 4]. This section does not address how		[Ref 2], [Ref 3] and [Ref 4]. This section does not address how
	session keys and policies are exchanged between a NAT device acting		session keys and policies are exchanged between a NAT device acting
	as IPsec gateway and external peering nodes. The exchange could		as IPsec gateway and external peering nodes. The exchange could
	have taken place manually or using any of known automatic exchange		have taken place manually or using any of known automatic exchange
	techniques.		techniques.
	Section 4 assumes that Public Key based IKE protocol [Ref 5] may		Section 4 assumes that Public Key based IKE protocol [Ref 5] may
	be used to automate exchange of secure policies, session keys		be used to automate exchange of security policies, session keys
	and other Security Association (SA) attributes. This section		and other Security Association (SA) attributes. This section
	describes a method by which secure policies administered for		describes a method by which security policies administered for a
	private domain may be translated for communicating with external		private domain may be translated for communicating with external
	nodes. Detailed description of IKE protocol operation may be		nodes. Detailed description of IKE protocol operation may be
	found in [Ref 5] and [Ref 6].		found in [Ref 5] and [Ref 6].
	Section 5 describes applications of the security model described		Section 5 describes applications of the security model described
	in the document. Applications listed include secure external		in the document. Applications listed include secure external
	realm connectivity for private domain hosts and secure remote		realm connectivity for private domain hosts and secure remote
	access to enterprise mobile hosts.		access to enterprise mobile hosts.
	2. Terminology		2. Terminology
	Definitions for majority of terms used in this document may be		Definitions for majority of terms used in this document may be
	found in one of (a) NAT Terminology and Considerations document		found in one of (a) NAT Terminology and Considerations document
	[Ref 1], (b) IP security Architecture document [Ref 2], or		[Ref 1], (b) IP security Architecture document [Ref 2], or
	(c) Internet Key Enchange (IKE) document [Ref 5]. Below are		(c) Internet Key Enchange (IKE) document [Ref 5]. Below are
	terms defined specifically for this document.		terms defined specifically for this document.
	2.1. Clear-NAT		2.1. Normal-NAT
	The term "Clear-NAT" is introduced to distinguish NAT processing on		The term "Normal-NAT" is introduced to distinguish normal NAT
	the outer packet header from that of NAT processing used for secure		processing from the NAT processing used for secure packets embedded
	packets embedded within an IPsec secure tunnel, for which the NAT		within an IPsec secure tunnel. "Normal-NAT" is the normal NAT
	device is a tunnel end point. The term "Clear-NAT" refers to NAT		processing as described in [Ref 1].
	processing on the outer packet header.
	2.2. Secure-NAT		2.2. IPsec Policy Controlled NAT (IPC-NAT)
	For lack of a better alternative, the term "Secure-NAT" is defined to		The term "IPsec Policy Controlled NAT" (IPC-NAT, for short) is
	describe the manifestation of NAT applied to packets embedded		defined to describe the NAT transformation applied as an extension
	within an IPsec-secure IP tunnel, for which the NAT node is a tunnel		of IPsec transformation to packets embedded within an IP-IP tunnel,
	end point. A Secure-NAT device is essentially a tunnel-mode IPsec		for which the NAT node is a tunnel end point. IPC-NAT function is
	gateway with NAT extensions applied to embedded packets.		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.
	Packets subject to secure-NAT processing are beneficiaries of IPsec		IPsec policies place restrictions on what NAT mappings are used.
	security between the NAT device and an external peer entity, be it a		For example, IPsec access control security policies to a peer
	host or a gateway node. Just as with Clear-NAT, Secure-NAT can		gateway will likely restrict communication to only certain addresses
	assume any of NAT flavors, including traditional NAT, bi-directional		and/or port numbers. Thus, when NAT performs translations, it must
	NAT and Twice NAT.		insure that the translations it performs are consist with the
			security policies.
	3.0. Secure NAT operation		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.
			3.0. Security model of IPC-NAT
	The IP security architecture document [Ref 2] describes how IP		The IP security architecture document [Ref 2] describes how IP
	network level security may be accomplished within a routing realm.		network level security may be accomplished within a globally unique
	Transport and tunnel mode security are discussed. For purposes		address realm. Transport and tunnel mode security are discussed. For
	of this document, we will assume IPsec security to mean tunnel		purposes of this document, we will assume IPsec security to mean
	mode IPsec security, unless specified otherwise. Elements		tunnel mode IPsec security, unless specified otherwise. Elements
	fundamental to this security architecture are (a) Secure		fundamental to this security architecture are (a) Security Policies,
	Policies, that determine which packets are permitted to be		that determine which packets are permitted to be subject to Security
	subject to Security processing, and (b) Security Association		processing, and (b) Security Association Attributes that identify
	Attributes that identify the parameters for security processing,		the parameters for security processing, including IPsec protocols,
	including IPsec protocols, algorithms and session keys to be		algorithms and session keys to be applied.
	applied.
	Operation of tunnel mode IPsec security on a device that does not		Operation of tunnel mode IPsec security on a device that does not
	support Network Address Translation may be described as below in		support Network Address Translation may be described as below in
	figures 1 and 2.		figures 1 and 2.
	+---------------+ No +---------------------------+		+---------------+ No +---------------------------+
	| | +--->|Forward packet in the Clear|		| | +--->|Forward packet in the Clear|
	Outgoing |Does the packet| | |Or Drop, as appropriate. |		Outgoing |Does the packet| | |Or Drop, as appropriate. |
	-------->|match Outbound |-| +---------------------------+		-------->|match Outbound |-| +---------------------------+
	Packet |Security | | +-------------+		Packet |Security | | +-------------+
	|Policies? | |Yes |Perform | Forward		|Policies? | |Yes |Perform | Forward
	| | +--->|Outbound |--------->		| | +--->|Outbound |--------->
	+---------------+ |Security | IPsec Pkt		+---------------+ |Security | IPsec Pkt
	|(Tunnel Mode)|		|(Tunnel Mode)|
	+-------------+		+-------------+
	Figure 1. Operation of Tunnel-Mode IPsec on outgoing packets.		Figure 1. Operation of Tunnel-Mode IPsec on outgoing packets.
	IPsec packet +----------+ +----------+		IPsec packet +----------+ +----------+
	destined to |Perform | Embedded |Does the | No(Drop)		destined to |Perform | Embedded |Does the | No(Drop)
	------------>|Inbound |--------->|Pkt match |-------->		------------>|Inbound |--------->|Pkt match |-------->
	the device |Security | Packet |Inbound SA| Yes(Forward)		the device |Security | Packet |Inbound SA| Yes(Forward)
	|(Detunnel)| |Policies? |		|(Detunnel)| |Policies? |
	+----------+ +----------+		+----------+ +----------+
	Figure 2. Operation of Tunnel-Mode IPsec on Incoming packets		Figure 2. Operation of Tunnel-Mode IPsec on Incoming packets
	A NAT device that provides tunnel-mode IPsec security would be		A NAT device that provides tunnel-mode IPsec security would be
	required to administer security policies based on private realm		required to administer security policies based on private realm
	addressing. In addition, the device would be required to perform		addressing. Further, the security policies determine the IPsec
	address translation for packets that adhere to secure policies.		tunnel end-point peer. As a result, a packet may be required to
	A Secure-NAT performs address translation and secure processing		undergo different type of NAT translation depending upon the
	together, based on secure policies. The following diagrams		tunnel end-point the IPsec node peers with. In other words,
	(figure 3 and figure 4) illustrate the operation of IPsec		IPC-NAT will need a unique set of NAT maps for each security
	tunneling in conjunction with NAT. Operation of Secure-NAT device		policy configured. IPC-NAT will perform address translation in
	may be distinguished from that of an IPsec gateway that does not		conjunction with IPsec processing differently with each peer,
	support NAT as follows.		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.
	(1) Secure-NAT device has secure policies administered using		(1) IPC-NAT device has security policies administered using
	private realm addressing. A traditional IPsec gateway		private realm addressing. A traditional IPsec gateway
	will have its security policies administered using a		will have its security policies administered using a
	single realm (say, external realm) addressing.		single realm (say, external realm) addressing.
	(2) Elements fundamental to the security model of a secure-NAT		(2) Elements fundamental to the security model of an IPC-NAT
	device includes Secure-NAT address mapping and other NAT		device includes IPC-NAT address mapping (and other NAT
	parameter definitions in conjunction with Secure policies		parameter definitions) in conjunction with Security policies
	and SA attributes. Fundamental elements of a traditional		and SA attributes. Fundamental elements of a traditional
	IPsec gateway are limited only to Secure policies and SA		IPsec gateway are limited only to Security policies and SA
	attributes.		attributes.
	+---------------+ +-----------------+		+---------------+ +-------------------------+
	| | No | Apply Clear-NAT | Forward		| | No | Apply Normal-NAT or Drop |
	Outgoing |Does the packet| +--->| as appropriate. |-------->		Outgoing |Does the packet| +--->| as appropriate |
	-------->|match Outbound |-| +-----------------+		-------->|match Outbound |-| +-------------------------+
	Packet |Security | | +--------+ +-------------+		Packet |Security | | +---------+ +-------------+
	(Private |Policies? | |Yes |Perform | |Perform | Forward		(Private |Policies? | |Yes |Perform | |Perform |Forward
	Domain) | | +--->|Outbound|->|Outbound |--------->		Domain) | | +--->|Outbound |->|Outbound |-------->
	+---------------+ |NAT | |Security | IPsec Pkt		+---------------+ |NAT | |Security |IPsec Pkt
	|(Secure)| |(Tunnel mode)|		|(IPC-NAT)| |(Tunnel mode)|
	+--------+ +-------------+		+---------+ +-------------+
	Figure 3. Tunnel-Mode IPsec on a Secure-NAT device for outgoing pkts		Figure 3. Tunnel-Mode IPsec on an IPC-NAT device for outgoing pkts
	IPsec Pkt +----------+ +--------+ +----------+		IPsec Pkt +----------+ +---------+ +----------+
	destined |Perform | Embedded |Perform | |Does the | No(Drop)		destined |Perform | Embedded |Perform | |Does the |No(Drop)
	--------->|Inbound |--------->|Inbound |->|Pkt match |-------->		--------->|Inbound |--------->|Inbound |->|Pkt match |-------->
	to device |Security | Packet |NAT | |Inbound SA| Yes(Forward)		to device |Security | Packet |NAT | |Inbound SA|Yes(Forward)
	(External |(Detunnel)| |(Secure)| |Policies? |		(External |(Detunnel)| |(IPC-NAT)| |Policies? |
	Domain) +----------+ +--------+ +----------+		Domain) +----------+ +---------+ +----------+
	Figure 4. Tunnel-Mode IPsec on a Secure-NAT device for Incoming pkts		Figure 4. Tunnel-Mode IPsec on an IPC-NAT device for Incoming pkts
	Traditional NAT is session oriented, allowing outbound-only sessions		Traditional NAT is session oriented, allowing outbound-only sessions
	to be translated. All other flavors of NAT are Bi-directional. Any		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		and all flavors of NAT mapping may be used in conjunction with the
	secure policies and secure processing on a secure-NAT device. For		security policies and secure processing on an IPC-NAT device. For
	illustration purposes in this document, we will assume tunnel mode		illustration purposes in this document, we will assume tunnel mode
	IPsec on a Bi-directional NAT device.		IPsec on a Bi-directional NAT device.
	Notice however that a NAT device capable of providing security across		Notice however that a NAT device capable of providing security across
	IPsec tunnels can continue to support Clear-NAT for packets that		IPsec tunnels can continue to support Normal-NAT for packets that
	do not require secure-NAT. Address mapping and other NAT parameter		do not require IPC-NAT. Address mapping and other NAT parameter
	definitions for clear-NAT and Secure-NAT are distinct. Figure 3		definitions for Normal-NAT and IPC-NAT are distinct. Figure 3
	identifies how a NAT device distinguishes between outgoing packets		identifies how a NAT device distinguishes between outgoing packets
	that need to be processed through clear-NAT vs. secure-NAT. As for		that need to be processed through Normal-NAT vs. IPC-NAT. As for
	packets incoming from external realm, figure 4 outlines packets		packets incoming from external realm, figure 4 outlines packets
	that may be subject to secure-NAT. All other packets are subject		that may be subject to IPC-NAT. All other packets are subject
	to clear-NAT processing only.		to Normal-NAT processing only.
	4.0. Operation of IKE protocol on Secure-NAT device.		4.0. Operation of IKE protocol on IPC-NAT device.
	Secure-NAT operation described in the previous section can be		IPC-NAT operation described in the previous section can be
	accomplished based on manual session key exchange or using an		accomplished based on manual session key exchange or using an
	automated key Exchange protocol between peering entities. In this		automated key Exchange protocol between peering entities. In this
	section, we will consider adapting IETF recommended Internet Key		section, we will consider adapting IETF recommended Internet Key
	Exchange (IKE) protocol on a Secure-NAT device for automatic		Exchange (IKE) protocol on a IPC-NAT device for automatic exchange
	exchange of security policies and SA parameters. In other words,		of security policies and SA parameters. In other words, we will
	we will focus on the operation of IKE in conjunction with tunnel		focus on the operation of IKE in conjunction with tunnel mode IPsec
	mode IPsec on NAT devices. For the reminder of this section, we		on NAT devices. For the reminder of this section, we will refer NAT
	will refer NAT device to mean secure-NAT device, unless specified		device to mean IPC-NAT device, unless specified otherwise.
	otherwise.
	IKE is based on UDP protocol and uses public-key encryption to		IKE is based on UDP protocol and uses public-key encryption to
	exchange session keys and other attributes securely across a		exchange session keys and other attributes securely across an
	routing realm. The detailed protocol and operation of IKE in the		address realm. The detailed protocol and operation of IKE in the
	context of IP may be found in [Ref 3] and [Ref 4]. Essentially,		context of IP may be found in [Ref 3] and [Ref 4]. Essentially,
	IKE has 2 phases.		IKE has 2 phases.
	In the first phase, IKE peers operate in main or aggressive mode		In the first phase, IKE peers operate in main or aggressive mode
	to authenticate each other and set up a secure channel between		to authenticate each other and set up a secure channel between
	themselves. A NAT device has an interface to the external realm		themselves. A NAT device has an interface to the external realm
	and is no different from any other node in the realm to negotiate		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		phase I with peer external nodes. The NAT device may assume any of
	the valid Identity types and authentication methodologies		the valid Identity types and authentication methodologies necessary
	necessary to communicate and authenticate with peers in the realm.		to communicate and authenticate with peers in the realm. The NAT
	The NAT device may also interface with a Certification Authority		device may also interface with a Certification Authority (CA) in the
	(CA) in the realm to retrieve certificates and perform signature		realm to retrieve certificates and perform signature validation.
	validation.
	In the second phase, IKE peers operate in Quick Mode to exchange		In the second phase, IKE peers operate in Quick Mode to exchange
	policies and IPsec security proposals to negotiate and agree upon		policies and IPsec security proposals to negotiate and agree upon
	security transformation algorithms, policies, keys, lifetime and		security transformation algorithms, policies, keys, lifetime and
	other security attributes. During this phase, IKE process must		other security attributes. During this phase, IKE process must
	communicate with IPsec Engine to (a) collect secure session		communicate with IPsec Engine to (a) collect secure session
	attributes and other parameters to negotiate with peer IKE		attributes and other parameters to negotiate with peer IKE
	nodes, and to (b) notify security parameters agreed upon (with		nodes, and to (b) notify security parameters agreed upon (with
	peer) during the negotiation.		peer) during the negotiation.
	A secure-NAT device, operating as IPsec gateway, has the secure		An IPC-NAT device, operating as IPsec gateway, has the security
	policies administered based on private realm addressing. An ALG		policies administered based on private realm addressing. An ALG
	will be required to translate policies from private realm		will be required to translate policies from private realm
	addressing into external addressing, as the IKE process needs to		addressing into external addressing, as the IKE process needs to
	communicate these policies to peers in external realm. The		communicate these policies to peers in external realm. Note, IKE
	following diagram illustrates how an IKE-ALG process interfaces		datagrams are not subject to any NAT processing. IKE-ALG simply
	with secure-NAT to take the secure policies and secure-NAT maps		translates select portions of IKE payload as per the NAT map
	and generates secure policies that IKE could communicate to		defined for the policy match. The following diagram illustrates
	peers in the external realm.		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.
	Depending on the nature of secure policies in place(ex: end-to-end		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.
			Depending on the nature of security policies in place(ex: end-to-end
	sessions between a pair of nodes vs. sessions with an address		sessions between a pair of nodes vs. sessions with an address
	range), IKE-ALG may need to request NAT to set up address bindings		range), IKE-ALG may need to request NAT to set up address bindings
	and/or transport bindings for the lifetime (in seconds or		and/or transport bindings for the lifetime (in seconds or
	Kilo-Bytes) the sessions are negotiated. In the case the ALG is		Kilo-Bytes) the sessions are negotiated. In the case the ALG is
	unable to setup the necessary address bindings or transport		unable to setup the necessary address bindings or transport
	bindings, IKE-ALG will not be able to translate secure policies		bindings, IKE-ALG will not be able to translate security policies
	and that will result in IKE not pursuing phase II negotiation for		and that will result in IKE not pursuing phase II negotiation for
	the effected policies.		the effected policies.
	When the Negotiation is complete and successful, IKE will		When the Negotiation is complete and successful, IKE will
	communicate the negotiated security parameters directly to the		communicate the negotiated security parameters directly to the
	Secure-NAT gateway engine as described in the following diagram.		IPC-NAT gateway engine as described in the following diagram.
	+---------+		+---------+
	| |		| |
	| |		Negotiated Security Parameters | IKE |
	| |		+--------------------------------| Process |
	Negotiated Security Parameters | IKE |		|(including session Keys) | |
	+-------------------------------| Process |		| +---------+
	|(including session Keys) | |		| ^ ^
	| | |		| Translated| |
	| | |		| Secure| |Security
	| +---------+		| Policies| |Proposals
	| ^ ^		v | |
	| | |		+---------+ Security Policies, based +---------+
	| Translated| |		| |------------------------->| |
	| Secure| |Security		| | on Pvt. realm addressing | |
	| Policies| |Proposals		| IPC-NAT | | |
	v | |		| (IPsec | IPC-NAT MAPs | IKE-ALG |
	+---------+ Secure Policies, based +---------+		| Gateway)|------------------------->| |
	| |------------------------>| |		| | | |
	| | on Pvt. realm addressing| |		| | Security Proposals | |
	| Secure- | | |		| |------------------------->| |
	| NAT | Secure-NAT MAPs | IKE-ALG |		| | | |
	| (IPsec |-----------------------> | |		| | NAT Control exchange | |
	| Gateway)| | |		| |<------------------------>| |
	| | Security Proposals | |		+---------+ +---------+
	| |-----------------------> | |
	| | | |
	| | NAT Control exchange | |
	| |<----------------------->| |
	+---------+ +---------+
	Figure 5. IKE-ALG translates Security policies, using NAT Maps.		Figure 5. IKE-ALG translates Security policies, using NAT Maps.
	5.0. Secure NAT applications		5.0. Applications of IPC-NAT security model
	Secure-NAT operational model described thus far illustrates how a		IPC-NAT operational model described thus far illustrates how a
	NAT device can be used as an IPsec tunnel end point to provide		NAT device can be used as an IPsec tunnel end point to provide
	secure transfer of data in external realm. This section will		secure transfer of data in external realm. This section will
	attempt to illustrate two applications of such a model.		attempt to illustrate two applications of such a model.
	5.1. Secure Extranet Connectivity		5.1. Secure Extranet Connectivity
	Secure-NAT Model has a direct application of being able to provide		IPC-NAT Model has a direct application of being able to provide
	clear as well as secure connectivity with external realm using a		clear as well as secure connectivity with external realm using a
	NAT device. In particular, secure-NAT device at the border of 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		private realm can peer with an IPsec gateway of an external domain
	to provide secure Extranet connectivity over the Internet.		to secure the Extranet connection. Extranet refers to the portion of
			the path that crosses the Internet between peering gateway nodes.
	5.2. Secure Remote Access to Mobile Users of an Enterprise		5.2. Secure Remote Access to Mobile Users of an Enterprise
	Say, a node from an enterprise moves out of the enterprise, and		Say, a node from an enterprise moves out of the enterprise, and
	attempts to connect to the enterprise from remote site, using a		attempts to connect to the enterprise from remote site, using a
	temporary service provider assigned address (Care-of-Address). In		temporary service provider assigned address (Care-of-Address). In
	such a case, the mobile user could setup an IPsec tunnel session		such a case, the mobile user could setup an IPsec tunnel session
	with the corporate secure-NAT device using a user-ID and		with the corporate IPC-NAT device using a user-ID and
	authentication mechanism that is agreed upon. Further, the user may		authentication mechanism that is agreed upon. Further, the user may
	be configured with enterprise DNS server, as an extension of		be configured with enterprise DNS server, as an extension of
	authentication following IKE Phase I. This would allow the user to		authentication following IKE Phase I. This would allow the user to
	access enterprise resources by name.		access enterprise resources by name.
	However, many enterprise servers and applications rely on source IP		However, many enterprise servers and applications rely on source IP
	address for authentication and deny access for packets that do not		address for authentication and deny access for packets that do not
	originate from the enterprise address space. In these scenarios,		originate from the enterprise address space. In these scenarios,
	secure-NAT has the ability (unlike a traditional IPsec gateway) to		IPC-NAT has the ability (unlike a traditional IPsec gateway) to
	perform Network Address Translation (NAT) for remote access users,		perform Network Address Translation (NAT) for remote access users,
	so their temporary address in external realm is translated into a		so their temporary address in external realm is translated into a
	enterprise domain address, while the packets are within private		enterprise domain address, while the packets are within private
	realm. The flavor of Secure-NAT performed would be traditional		realm. The flavor of IPC-NAT performed would be traditional
	NAT (i.e., assuming mobile-user address space to be private realm		NAT (i.e., assuming mobile-user address space to be private realm
	and Enterprise address space to be external realm), which can		and Enterprise address space to be external realm), which can
	either be Basic NAT (using a block of enterprise addresses for		either be Basic NAT (using a block of enterprise addresses for
	translation) or NAPT(using a single enterprise address for		translation) or NAPT(using a single enterprise address for
	translation).		translation).
	The secure remote access application described is pertinent to all		The secure remote access application described is pertinent to all
	enterprises, irrespective of whether an enterprise uses IANA		enterprises, irrespective of whether an enterprise uses IANA
	registered addresses or not.		registered addresses or not.
	The secure remote access application described is different from		The secure remote access application described is different from
	Mobile-IP in that, the mobile node (described in this application)		Mobile-IP in that, the mobile node (described in this application)
	does not retain the Home-Network address and simply uses the		does not retain the Home-Network address and simply uses the
	Care-Of-address for communication purposes. It is conceivable for		Care-Of-address for communication purposes. It is conceivable for
	the Secure-NAT Gateway to transparently provide Mobile-IP type		the IPC-NAT Gateway to transparently provide Mobile-IP type
	connectivity to the Mobile node by binding the mobile node's		connectivity to the Mobile node by binding the mobile node's
	Care-of-Address with its Home Address. Provision of such an address		Care-of-Address with its Home Address. Provision of such an address
	mapping to Secure-NAT gateway, however, is not within the scope of		mapping to IPC-NAT gateway, however, is not within the scope of
	this document.		this document.
	6.0. Security Considerations		6.0. Security Considerations
	If NATs and ALGs are not in a trusted boundary, that is a major		If NATs and ALGs are not in a trusted boundary, that is a major
	security problem, as ALGs snoop end user traffic payload.		security problem, as ALGs snoop end user traffic payload.
	Session level payload could be encrypted end to end, so long as		Application level payload could be encrypted end-to-end, so long
	the payload does not contain IP addresses and/or transport		as the payload does not contain IP addresses and/or transport
	identifiers that are valid in only one of the realms. With the		identifiers that are valid in only one of the realms. With the
	exception of Realm-Specific IP, end-to-end IP network level		exception of Realm-Specific IP, end-to-end IP network level
	security assured by current IPsec techniques is not attainable		security assured by current IPsec techniques is not attainable
	with NATs in between. The secure-NAT model described in this		with NATs in between. The IPC-NAT model described in this
	document outlines an approach by which network level security		document outlines an approach by which network level security
	may be obtained within external realm.		may be obtained within external realm.
	NATs, when combined with ALGs, can ensure that the datagrams		NATs, when combined with ALGs, can ensure that the datagrams
	injected into Internet have no private addresses in headers or		injected into Internet have no private addresses in headers or
	payload. Applications that do not meet these requirements may		payload. Applications that do not meet these requirements may
	be dropped using firewall filters. For this reason, it is not		be dropped using firewall filters. For this reason, it is not
	uncommon to find that Secure-NATs, ALGs and firewalls co-exist		uncommon to find that IPC-NATs, ALGs and firewalls co-exist
	to provide security at the border of a private network.		to provide security at the border of a private network.
	REFERENCES		REFERENCES
	[1] P. Srisuresh, M. Holdrege, "The IP Network Address		[1] P. Srisuresh, M. Holdrege, "The IP Network Address
	Translator (NAT) terminology and considerations",		Translator (NAT) terminology and considerations", RFC xxxx
	<draft-ietf-nat-terminology-01.txt> - Work in progress,
	October 1998
	[2] S. Kent, R. Atkinson, "Security Architecture for the Internet		[2] S. Kent, R. Atkinson, "Security Architecture for the Internet
	Protocol", RFC 2401		Protocol", RFC 2401
	[3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload		[3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
	(ESP)", RFC 2406		(ESP)", RFC 2406
	[4] S. Kent, R. Atkinson, "IP Authentication Header", RFC2402		[4] S. Kent, R. Atkinson, "IP Authentication Header", RFC2402
	[5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",		[5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
	RFC 2409		RFC 2409
	[6] D. Piper, "The Internet IP Security Domain of Interpretation		[6] D. Piper, "The Internet IP Security Domain of Interpretation
	for ISAKMP", RFC 2407		for ISAKMP", RFC 2407
	[7] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address		[7] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address
	Behavior Today", RFC 2101		Behavior Today", RFC 2101
	[8] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,		[8] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,
	Lear, E. "Address Allocation for Private Internets", RFC 1918		Lear, E. "Address Allocation for Private Internets", RFC 1918
	Author's Address		Author's Address
	Pyda Srisuresh		Pyda Srisuresh
	Lucent technologies		Lucent technologies
	4464 Willow Road		4464 Willow Road
	Pleasanton, CA 94588-8519		Pleasanton, CA 94588-8519
	U.S.A.		U.S.A.
	Voice: (925) 737-2153		Voice: (925) 737-2153
	Fax: (925) 737-2110		Fax: (925) 737-2110
	EMail: suresh@ra.lucent.com		EMail: srisuresh@lucent.com
End of changes. 57 change blocks.
	170 lines changed or deleted		181 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/