NAT Working Group P. Srisuresh INTERNET-DRAFT Lucent Technologies Category: Informational February 1999 Expire in six months Security Model for Network Address Translator (NAT) Domains Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 can offer network level 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 secure policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Applications that can benefit from the secure NAT model are also outlined in the end. Srisuresh [Page 1] Internet Draft Security for NAT domains February 1999 1. Introduction and Overview NATs provide transparent routing to end hosts trying to communicate from disparate routing 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. 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 external realm connectivity for private domain hosts and secure remote access to enterprise mobile hosts. Srisuresh [Page 2] Internet Draft Security for NAT domains February 1999 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 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. The term "Clear-NAT" refers to NAT processing on the outer packet header. 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 February 1999 +---------------+ 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 an IPsec gateway that does not support NAT 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 only to Secure policies and SA attributes. Srisuresh [Page 4] Internet Draft Security for NAT domains February 1999 +---------------+ +-----------------+ | | 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. 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 packets that may be subject to secure-NAT. All other packets are subject to clear-NAT processing only. Srisuresh [Page 5] Internet Draft Security for NAT domains February 1999 4.0. Operation of IKE protocol on Secure-NAT device. 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 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 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 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. 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. Srisuresh [Page 6] Internet Draft Security for NAT domains February 1999 Depending on the nature of secure 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 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 February 1999 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 external realm. This section will attempt to illustrate two applications of such a model. 5.1. Secure Extranet Connectivity Secure-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, secure-NAT device at the border of a private realm can peer with an IPSec gateway of an external domain to provide secure Extranet connectivity over the Internet. 5.2. Secure Remote Access to Mobile Users of an Enterprise 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 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 rely on source IP address for authentication and deny access for packets that do not originate from the enterprise address space. In these scenarios, secure-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 Secure-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). The secure remote access application described is pertinent to all enterprises, irrespective of whether an enterprise uses IANA registered addresses or not. Srisuresh [Page 8] Internet Draft Security for NAT domains February 1999 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 Secure-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 Secure-NAT gateway, however, is not within the scope of this document. 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 Realm-Specific IP, 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 outlines an approach by which network level security may be obtained within 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 border of a private network. Srisuresh [Page 9] Internet Draft Security for NAT domains February 1999 REFERENCES [1] P. Srisuresh, M. Holdrege, "The IP Network Address Translator (NAT) terminology and considerations", - Work in progress, October 1998 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401 [3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406 [4] S. Kent, R. Atkinson, "IP Authentication Header", RFC2402 [5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409 [6] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407 [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]