NAT Working Group P. Srisuresh
INTERNET-DRAFT Lucent Technologies
Category: Informational November 1998
Expire in six months
Security for IP Network Address Translator (NAT) Domains
<draft-ietf-nat-security-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract
There are a variety of NAT flavors, as described in [Ref 1]. Of the
domains supported by NATs, only Host-NAT-clients are allowed to
pursue end-to-end IPsec secure sessions. However, all flavors of NAT
can offer 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 recognized on NAT
devices. In addition, a section is devoted to describing how Secure
policies may be communicated to IKE for automated KEY exchange and
setup of Security Associations for an IPsec secure NAT gateway.
1. Introduction and Overview
NATs provide transparent routing to end hosts trying to communicate
from disparate routing realms, by modifying IP and transport headers
Srisuresh [Page 1]
Internet Draft Security for NAT domains November 1998
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.
End-to-end transport level payload security can be provided for
applications that do not embed realm-specific information that is
meaningless to one of the end-users. Applications that do embed
realm-specific information 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 transport level security.
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.
Section 2 below defines terms specific to this document.
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.
Section 4 assumes that Public Key based IKE protocol [Ref 5] may
be used to automate exchange of secure policies, session keys
and other Security Association (SA) attributes. This section
describes a method by which secure policies administered for
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].
Section 5 describes applications of the security model described
in the document. Applications listed include secure extternal
realm connectivity for private domain hosts and secure remote
access to enterprise mobile hosts.
2. Terminology
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
Srisuresh [Page 2]
Internet Draft Security for NAT domains November 1998
terms defined specifically for this document.
2.1. Clear-NAT
The term "Clear-NAT" is introduced to distinguish NAT processing on
the outer packet header from that of NAT processing used for secure
packets embedded within an IPsec secure tunnel, for which the NAT
device is a tunnel end point.
2.2. Secure-NAT
For lack of a better alternative, the term "Secure-NAT" is defined to
describe the manifestation of NAT applied to packets embedded
within an IPsec secure IP tunnel, for which the NAT node is a tunnel
end point. A Secure-NAT device is essentially a tunnel-mode IPsec
gateway with NAT extensions applied to embedded packets.
Packets subject to secure-NAT processing are beneficiaries of IPsec
security between the NAT device and an external peer entity, be it a
host or a gateway node.
Just as with Clear-NAT, Secure-NAT can assume any of NAT flavors,
including traditional NAT, bi-directional NAT and Twice NAT.
3.0. Secure NAT operation
The IP security architecture document [Ref 2] describes how IP
network level security may be accomplished within a routing 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) Secure
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.
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.
Srisuresh [Page 3]
Internet Draft Security for NAT domains November 1998
+---------------+ 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 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
A NAT device that provides tunnel-mode IPsec security would be
required to administer security policies based on private realm
addressing. In addition, the device would be required to perform
address translation for packets that adhere to secure policies.
A Secure-NAT performs address translation and secure processing
together, based on secure policies. The following diagrams
(figure 3 and figure 4) illustrate the operation of IPsec
tunneling in conjunction with NAT. Operation of Secure-NAT device
may be distinguished from that of a traditional IPsec gateway that
does not support NAT may be summarized as follows.
(1) Secure-NAT device has secure 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 a secure-NAT
device includes Secure-NAT address mapping and other NAT
parameter definitions in conjunction with Secure policies
and SA attributes. Fundamental elements of a traditional
IPsec gateway are limited to Secure policies and SA
attributes.
Srisuresh [Page 4]
Internet Draft Security for NAT domains November 1998
+---------------+ +-----------------+
| | No | Apply Clear-NAT | Forward
Outgoing |Does the packet| +--->| as appropriate. |-------->
-------->|match Outbound |-| +-----------------+
Packet |Security | | +--------+ +-------------+
(Private |Policies? | |Yes |Perform | |Perform | Forward
Domain) | | +--->|Outbound|->|Outbound |--------->
+---------------+ |NAT | |Security | IPsec Pkt
|(Secure)| |(Tunnel mode)|
+--------+ +-------------+
Figure 3. Tunnel-Mode IPsec on a Secure-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)| |(Secure)| |Policies? |
Domain) +----------+ +--------+ +----------+
Figure 4. Tunnel-Mode IPsec on a Secure-NAT device for Incoming pkts
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
secure policies and secure processing on a secure-NAT device. For
illustration purposes in this document, we will assume tunnel mode
IPsec on a Bi-directional NAT device providing secure-NAT.
Notice however that a NAT device capable of providing security across
IPsec tunnels can continue to support Clear-NAT for packets that
do not require secure-NAT. Address mapping and other NAT parameter
definitions for clear-NAT and Secure-NAT are distinct. Figure 3
identifies how a NAT device distinguishes between outgoing packets
that need to be processed through clear-NAT vs. secure-NAT. As for
packets incoming from external realm, figure 4 outlines the packets
that may be subject to secure-NAT. All other packets are subject to
clear-NAT processing only.
4.0. Operation of IKE protocol on Secure-NAT device.
Srisuresh [Page 5]
Internet Draft Security for NAT domains November 1998
Secure-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 Secure-NAT device for automatic
exchange of security filters 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 secure-NAT device, unless specified
otherwise.
IKE is based on UDP protocol and uses public-key encryption to
exchange session keys and other attributes securely across a
routing 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.
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 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.
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.
A secure-NAT device, operating as IPsec gateway, has the secure
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. The
following diagram illustrates how an IKE-ALG process interfaces
with secure-NAT to take the secure policies and secure-NAT maps
and generates secure policies that IKE could communicate to
peers in the external realm.
Depending on the nature of secure policies in place(ex: end-to-end
sessions between a pair of nodes vs. sessions with an address
Srisuresh [Page 6]
Internet Draft Security for NAT domains November 1998
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 secure policies
and that will result in IKE not pursuing phase II negotiation for
the effected policies.
When the Negotiation is complete and successful, IKE will
communicate the negotiated security parameters directly to the
Secure-NAT gateway engine as described in the following diagram.
+---------+
| |
| |
| |
Negotiated Security Parameters | IKE |
+-------------------------------| Process |
|(including session Keys) | |
| | |
| | |
| +---------+
| ^ ^
| | |
| Translated| |
| Secure| |Security
| Policies| |Proposals
v | |
+---------+ Secure Policies, based +---------+
| |------------------------>| |
| | on Pvt. realm addressing| |
| Secure- | | |
| NAT | Secure-NAT MAPs | IKE-ALG |
| (IPsec |-----------------------> | |
| Gateway)| | |
| | Security Proposals | |
| |-----------------------> | |
| | | |
| | NAT Control exchange | |
| |<----------------------->| |
+---------+ +---------+
Figure 5. IKE-ALG translates Security policies, using NAT Maps.
Srisuresh [Page 7]
Internet Draft Security for NAT domains November 1998
5.0. Secure NAT applications
Secure-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 the external realm. This has a direct
application of being able to provide clear as well as secure
connectivity with external realm using a NAT device.
There are other benefits that can be derived from this security
model. One such would be Secure remote access for mobile hosts.
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. In such a case, the
remote user could setup an IPsec tunnel session with the corporate
secure-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.
However, many enterprise servers and applications deny access for
packets that do not originate from the enterprise address space. In
such a case, secure-NAT has the provision (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 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).
Clearly, traditional NAT can either be Basic NAT (using a block of
enterprise addresses for remote access translation) or NAPT(using a
single enterprise address for remote access translation).
The secure remote access application described is pertinent to all
enterprises, irrespective of whether an enterprise uses IANA
registered addresses or not. A mobile users is allowed secure remote
access to corporate resources. The security model outlined in the
document makes such an application possible.
6.0. Security Considerations
If NATs and ALGs are not in a trusted boundary, that is a major
security problem, as ALGs snoop end user traffic payload.
Session 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 Host-NAT, end-to-end IP network level security
assured by current IPsec techniques is not attainable with NATs
in between. The secure-NAT model described in this document
Srisuresh [Page 8]
Internet Draft Security for NAT domains November 1998
offers network level security only in the external realm.
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 Secure-NATs, ALGs and firewalls co-exist
to provide security at the borders of a private network.
Srisuresh [Page 9]
Internet Draft Security for NAT domains November 1998
REFERENCES
[1] P. Srisuresh, M. Holdrege, "The IP Network Address
Translator (NAT) terminology and considerations",
<draft-ietf-nat-terminology-01.txt> - Work in progress,
October 1998
[2] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", <draft-ietf-ipsec-arch-sec-05.txt> - Work in
progress.
[3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
(ESP)", <draft-ietf-ipsec-esp-v2-05.txt> - Work in progress.
[4] S. Kent, R. Atkinson, "IP Authentication Header",
<draft-ietf-ipsec-auth-header-06.txt> - Work in progress.
[5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
<draft-ietf-ipsec-isakmp-oakley-08.txt> - Work in progress.
[6] D. Piper, "The Internet IP Security Domain of Interpretation
for ISAKMP", <draft-ietf-ipsec-ipsec-doi-09.txt> - Work in
progress.
[7] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address
Behavior Today", RFC 2101
[8] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,
Lear, E. "Address Allocation for Private Internets", RFC 1918
Author's Address
Pyda Srisuresh
Lucent technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Voice: (925) 737-2153
Fax: (925) 737-2110
EMail: suresh@ra.lucent.com
Srisuresh [Page 10]
