diff options
Diffstat (limited to 'doc/rfc/rfc2709.txt')
| -rw-r--r-- | doc/rfc/rfc2709.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2709.txt b/doc/rfc/rfc2709.txt new file mode 100644 index 0000000..890982b --- /dev/null +++ b/doc/rfc/rfc2709.txt @@ -0,0 +1,619 @@ + + + + + + +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. + +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. Introduction and Overview + + 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. + + 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. + + + + + + +Srisuresh Informational [Page 1] + +RFC 2709 Security for NAT Domains October 1999 + + + 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. + +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. Normal-NAT + + 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]. + +2.2. IPsec Policy Controlled NAT (IPC-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 + + + +Srisuresh Informational [Page 2] + +RFC 2709 Security for NAT Domains October 1999 + + + 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. + +3. Security model of IPC-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. + + 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. + + + + +Srisuresh Informational [Page 3] + +RFC 2709 Security for NAT Domains October 1999 + + + 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 + + + +Srisuresh Informational [Page 4] + +RFC 2709 Security for NAT Domains October 1999 + + + 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. + +4. Operation of IKE protocol on IPC-NAT device. + + 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. + + 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. + + 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 + + + +Srisuresh Informational [Page 5] + +RFC 2709 Security for NAT Domains October 1999 + + + 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. + + + + + +Srisuresh Informational [Page 6] + +RFC 2709 Security for NAT Domains October 1999 + + + +---------+ + | | + 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. Applications of IPC-NAT security model + + 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. + +5.1. Secure Extranet Connectivity + + 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. + + + + + + + + +Srisuresh Informational [Page 7] + +RFC 2709 Security for NAT Domains October 1999 + + +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 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. + + 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). + + The secure remote access application described is pertinent to all + enterprises, irrespective of whether an enterprise uses IANA + registered addresses or not. + + 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. + +6. 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. + 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 + + + +Srisuresh Informational [Page 8] + +RFC 2709 Security for NAT Domains October 1999 + + + 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. + +REFERENCES + + [1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator + (NAT) Terminology and Considerations", RFC 2663, August 1999. + + [2] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998 + + [3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload + (ESP)", RFC 2406, November 1998 + + [4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, + November 1998. + + [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", + RFC 2409, November 1998. + + [6] Piper, D., "The Internet IP Security Domain of Interpretation + for ISAKMP", RFC 2407, November 1998. + + [7] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address + Behavior Today", RFC 2101, February 1997. + + [8] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + + + + + + + + + + + + + + + +Srisuresh Informational [Page 9] + +RFC 2709 Security for NAT Domains October 1999 + + +Author's Address + + Pyda Srisuresh + Lucent technologies + 4464 Willow Road + Pleasanton, CA 94588-8519 + U.S.A. + + Phone: (925) 737-2153 + Fax: (925) 737-2110 + EMail: srisuresh@lucent.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Srisuresh Informational [Page 10] + +RFC 2709 Security for NAT Domains October 1999 + + +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. + + + + + + + + + + + + + + + + + + + +Srisuresh Informational [Page 11] + |