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.
AbstractThere 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.
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 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]. 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. 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. Ref 1].
which the NAT node is a tunnel end point. IPC-NAT function is essentially an adaptation of NAT extensions to embedded packets of tunnel-mode IPsec. Packets subject to IPC-NAT processing are beneficiaries of IPsec security between the NAT device and an external peer entity, be it a host or a gateway node. IPsec 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. 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. 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. 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. +---------------+ 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. 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. (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. +---------------+ +-------------------------+ | | No | Apply Normal-NAT or Drop| Outgoing |Does the packet| +--->| as appropriate | -------->|match Outbound |-| +-------------------------+ Packet |Security | | +---------+ +-------------+ (Private |Policies? | |Yes |Perform | |Perform |Forward Domain) | | +--->|Outbound |->|Outbound |--------> +---------------+ |NAT | |Security |IPsec Pkt |(IPC-NAT)| |(Tunnel mode)| +---------+ +-------------+ Figure 3. Tunnel-Mode IPsec on an IPC-NAT device for outgoing pkts
IPsec Pkt +----------+ +---------+ +----------+ destined |Perform | Embedded |Perform | |Does the |No(Drop) --------->|Inbound |--------->|Inbound |->|Pkt match |--------> to device |Security | Packet |NAT | |Inbound SA|Yes(Forward) (External |(Detunnel)| |(IPC-NAT)| |Policies? | Domain) +----------+ +---------+ +----------+ Figure 4. Tunnel-Mode IPsec on an IPC-NAT device for Incoming pkts 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. 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. 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. 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. 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 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. 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.
+---------+ | | 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.
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 IPC-NATs, ALGs and firewalls co-exist to provide security at the border of a private network.  Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.  Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.  Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. 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.