idnits 2.17.1 draft-ietf-nat-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Ref1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 252 has weird spacing: '... device has a...' == Line 258 has weird spacing: '...ficates and p...' == Line 265 has weird spacing: '...ameters to ne...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1999) is 9018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Ref 1' on line 102 -- Looks like a reference, but probably isn't: 'Ref 2' on line 129 -- Looks like a reference, but probably isn't: 'Ref 3' on line 247 -- Looks like a reference, but probably isn't: 'Ref 4' on line 247 -- Looks like a reference, but probably isn't: 'Ref 5' on line 94 -- Looks like a reference, but probably isn't: 'Ref 6' on line 82 == Unused Reference: '1' is defined on line 407, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 410, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 413, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 416, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 418, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 421, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 424, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 427, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2402 (ref. '4') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. '6') (Obsoleted by RFC 4306) Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NAT Working Group P. Srisuresh 2 INTERNET-DRAFT Lucent Technologies 3 Category: Informational August 1999 4 Expire in six months 6 Security Model with Tunnel-mode IPsec for NAT Domains 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 There are a variety of NAT flavors, as described in [Ref 1]. Of the 34 domains supported by NATs, only Realm-Specific IP clients are able 35 to pursue end-to-end IPsec secure sessions. However, all flavors of 36 NAT are capable of offering tunnel-mode IPsec security to private 37 domain hosts peering with nodes in external realm. This document 38 describes a security model by which tunnel-mode IPsec security can 39 be architected on NAT devices. A section is devoted to describing 40 how security policies may be transparently communicated to IKE (for 41 automated KEY exchange) during Quick Mode. Also outlined are 42 applications that can benefit from the Security Model described. 44 1. Introduction and Overview 46 NAT devices provide transparent routing to end hosts trying to 47 communicate from disparate address realms, by modifying IP and 48 transport headers en-route. This solution works best when the end 49 user identifier (such as host name) is different from the address 50 used to locate end user. 52 End-to-end application level payload security can be provided for 53 applications that do not embed realm-specific information in 54 payloads that is meaningless to one of the end-users. Applications 55 that do embed realm-specific information in payload will require an 56 application level gateway (ALG) to make the payload meaningful in 57 both realms. However, applications that require assistance of an ALG 58 en-route cannot pursue end-to-end application level security. 60 All applications traversing a NAT device, irrespective of whether 61 they require assistance of an ALG or not, can benefit from IPsec 62 tunnel-mode security, when NAT device acts as the IPsec tunnel 63 end point. 65 Section 2 below defines terms specific to this document. 67 Section 3 describes how tunnel mode IPsec security can be 68 recognized on NAT devices. IPsec Security architecture, format and 69 operation of various types of security mechanisms may be found in 70 [Ref 2], [Ref 3] and [Ref 4]. This section does not address how 71 session keys and policies are exchanged between a NAT device acting 72 as IPsec gateway and external peering nodes. The exchange could 73 have taken place manually or using any of known automatic exchange 74 techniques. 76 Section 4 assumes that Public Key based IKE protocol [Ref 5] may 77 be used to automate exchange of security policies, session keys 78 and other Security Association (SA) attributes. This section 79 describes a method by which security policies administered for a 80 private domain may be translated for communicating with external 81 nodes. Detailed description of IKE protocol operation may be 82 found in [Ref 5] and [Ref 6]. 84 Section 5 describes applications of the security model described 85 in the document. Applications listed include secure external 86 realm connectivity for private domain hosts and secure remote 87 access to enterprise mobile hosts. 89 2. Terminology 91 Definitions for majority of terms used in this document may be 92 found in one of (a) NAT Terminology and Considerations document 93 [Ref 1], (b) IP security Architecture document [Ref 2], or 94 (c) Internet Key Enchange (IKE) document [Ref 5]. Below are 95 terms defined specifically for this document. 97 2.1. Normal-NAT 99 The term "Normal-NAT" is introduced to distinguish normal NAT 100 processing from the NAT processing used for secure packets embedded 101 within an IPsec secure tunnel. "Normal-NAT" is the normal NAT 102 processing as described in [Ref 1]. 104 2.2. IPsec Policy Controlled NAT (IPC-NAT) 106 The term "IPsec Policy Controlled NAT" (IPC-NAT, for short) is 107 defined to describe the NAT transformation applied as an extension 108 of IPsec transformation to packets embedded within an IP-IP tunnel, 109 for which the NAT node is a tunnel end point. IPC-NAT function is 110 essentially an adaptation of NAT extensions to embedded packets of 111 tunnel-mode IPsec. Packets subject to IPC-NAT processing are 112 beneficiaries of IPsec security between the NAT device and an 113 external peer entity, be it a host or a gateway node. 115 IPsec policies place restrictions on what NAT mappings are used. 116 For example, IPsec access control security policies to a peer 117 gateway will likely restrict communication to only certain addresses 118 and/or port numbers. Thus, when NAT performs translations, it must 119 insure that the translations it performs are consist with the 120 security policies. 122 Just as with Normal-NAT, IPC-NAT function can assume any of NAT 123 flavors, including Traditional-NAT, Bi-directional-NAT and Twice-NAT. 124 An IPC-NAT device would support both IPC-NAT and normal-NAT 125 functions. 127 3.0. Security model of IPC-NAT 129 The IP security architecture document [Ref 2] describes how IP 130 network level security may be accomplished within a globally unique 131 address realm. Transport and tunnel mode security are discussed. For 132 purposes of this document, we will assume IPsec security to mean 133 tunnel mode IPsec security, unless specified otherwise. Elements 134 fundamental to this security architecture are (a) Security Policies, 135 that determine which packets are permitted to be subject to Security 136 processing, and (b) Security Association Attributes that identify 137 the parameters for security processing, including IPsec protocols, 138 algorithms and session keys to be applied. 140 Operation of tunnel mode IPsec security on a device that does not 141 support Network Address Translation may be described as below in 142 figures 1 and 2. 144 +---------------+ No +---------------------------+ 145 | | +--->|Forward packet in the Clear| 146 Outgoing |Does the packet| | |Or Drop, as appropriate. | 147 -------->|match Outbound |-| +---------------------------+ 148 Packet |Security | | +-------------+ 149 |Policies? | |Yes |Perform | Forward 150 | | +--->|Outbound |---------> 151 +---------------+ |Security | IPsec Pkt 152 |(Tunnel Mode)| 153 +-------------+ 155 Figure 1. Operation of Tunnel-Mode IPsec on outgoing packets. 157 IPsec packet +----------+ +----------+ 158 destined to |Perform | Embedded |Does the | No(Drop) 159 ------------>|Inbound |--------->|Pkt match |--------> 160 the device |Security | Packet |Inbound SA| Yes(Forward) 161 |(Detunnel)| |Policies? | 162 +----------+ +----------+ 164 Figure 2. Operation of Tunnel-Mode IPsec on Incoming packets 166 A NAT device that provides tunnel-mode IPsec security would be 167 required to administer security policies based on private realm 168 addressing. Further, the security policies determine the IPsec 169 tunnel end-point peer. As a result, a packet may be required to 170 undergo different type of NAT translation depending upon the 171 tunnel end-point the IPsec node peers with. In other words, 172 IPC-NAT will need a unique set of NAT maps for each security 173 policy configured. IPC-NAT will perform address translation in 174 conjunction with IPsec processing differently with each peer, 175 based on security policies. The following diagrams (figure 3 and 176 figure 4) illustrate the operation of IPsec tunneling in 177 conjunction with NAT. Operation of an IPC-NAT device may be 178 distinguished from that of an IPsec gateway that does not support 179 NAT as follows. 181 (1) IPC-NAT device has security policies administered using 182 private realm addressing. A traditional IPsec gateway 183 will have its security policies administered using a 184 single realm (say, external realm) addressing. 186 (2) Elements fundamental to the security model of an IPC-NAT 187 device includes IPC-NAT address mapping (and other NAT 188 parameter definitions) in conjunction with Security policies 189 and SA attributes. Fundamental elements of a traditional 190 IPsec gateway are limited only to Security policies and SA 191 attributes. 193 +---------------+ +-------------------------+ 194 | | No | Apply Normal-NAT or Drop | 195 Outgoing |Does the packet| +--->| as appropriate | 196 -------->|match Outbound |-| +-------------------------+ 197 Packet |Security | | +---------+ +-------------+ 198 (Private |Policies? | |Yes |Perform | |Perform |Forward 199 Domain) | | +--->|Outbound |->|Outbound |--------> 200 +---------------+ |NAT | |Security |IPsec Pkt 201 |(IPC-NAT)| |(Tunnel mode)| 202 +---------+ +-------------+ 204 Figure 3. Tunnel-Mode IPsec on an IPC-NAT device for outgoing pkts 206 IPsec Pkt +----------+ +---------+ +----------+ 207 destined |Perform | Embedded |Perform | |Does the |No(Drop) 208 --------->|Inbound |--------->|Inbound |->|Pkt match |--------> 209 to device |Security | Packet |NAT | |Inbound SA|Yes(Forward) 210 (External |(Detunnel)| |(IPC-NAT)| |Policies? | 211 Domain) +----------+ +---------+ +----------+ 213 Figure 4. Tunnel-Mode IPsec on an IPC-NAT device for Incoming pkts 215 Traditional NAT is session oriented, allowing outbound-only sessions 216 to be translated. All other flavors of NAT are Bi-directional. Any 217 and all flavors of NAT mapping may be used in conjunction with the 218 security policies and secure processing on an IPC-NAT device. For 219 illustration purposes in this document, we will assume tunnel mode 220 IPsec on a Bi-directional NAT device. 222 Notice however that a NAT device capable of providing security across 223 IPsec tunnels can continue to support Normal-NAT for packets that 224 do not require IPC-NAT. Address mapping and other NAT parameter 225 definitions for Normal-NAT and IPC-NAT are distinct. Figure 3 226 identifies how a NAT device distinguishes between outgoing packets 227 that need to be processed through Normal-NAT vs. IPC-NAT. As for 228 packets incoming from external realm, figure 4 outlines packets 229 that may be subject to IPC-NAT. All other packets are subject 230 to Normal-NAT processing only. 232 4.0. Operation of IKE protocol on IPC-NAT device. 234 IPC-NAT operation described in the previous section can be 235 accomplished based on manual session key exchange or using an 236 automated key Exchange protocol between peering entities. In this 237 section, we will consider adapting IETF recommended Internet Key 238 Exchange (IKE) protocol on a IPC-NAT device for automatic exchange 239 of security policies and SA parameters. In other words, we will 240 focus on the operation of IKE in conjunction with tunnel mode IPsec 241 on NAT devices. For the reminder of this section, we will refer NAT 242 device to mean IPC-NAT device, unless specified otherwise. 244 IKE is based on UDP protocol and uses public-key encryption to 245 exchange session keys and other attributes securely across an 246 address realm. The detailed protocol and operation of IKE in the 247 context of IP may be found in [Ref 3] and [Ref 4]. Essentially, 248 IKE has 2 phases. 250 In the first phase, IKE peers operate in main or aggressive mode 251 to authenticate each other and set up a secure channel between 252 themselves. A NAT device has an interface to the external realm 253 and is no different from any other node in the realm to negotiate 254 phase I with peer external nodes. The NAT device may assume any of 255 the valid Identity types and authentication methodologies necessary 256 to communicate and authenticate with peers in the realm. The NAT 257 device may also interface with a Certification Authority (CA) in the 258 realm to retrieve certificates and perform signature validation. 260 In the second phase, IKE peers operate in Quick Mode to exchange 261 policies and IPsec security proposals to negotiate and agree upon 262 security transformation algorithms, policies, keys, lifetime and 263 other security attributes. During this phase, IKE process must 264 communicate with IPsec Engine to (a) collect secure session 265 attributes and other parameters to negotiate with peer IKE 266 nodes, and to (b) notify security parameters agreed upon (with 267 peer) during the negotiation. 269 An IPC-NAT device, operating as IPsec gateway, has the security 270 policies administered based on private realm addressing. An ALG 271 will be required to translate policies from private realm 272 addressing into external addressing, as the IKE process needs to 273 communicate these policies to peers in external realm. Note, IKE 274 datagrams are not subject to any NAT processing. IKE-ALG simply 275 translates select portions of IKE payload as per the NAT map 276 defined for the policy match. The following diagram illustrates 277 how an IKE-ALG process interfaces with IPC-NAT to take the security 278 policies and IPC-NAT maps and generates security policies that IKE 279 could communicate during quick mode to peers in the external realm. 281 Policies in quick mode are exchanged with a peer as a combination 282 of IDci and IDcr payloads. The combination of IDs (policies) 283 exchanged by each peer must match in order for the SA parameters on 284 either end to be applied uniformly. If the IDs are not exchanged, 285 the assumption would be that the Quick mode negotiated SA parameters 286 are applicable between the IP addresses assumed by the main mode. 288 Depending on the nature of security policies in place(ex: end-to-end 289 sessions between a pair of nodes vs. sessions with an address 290 range), IKE-ALG may need to request NAT to set up address bindings 291 and/or transport bindings for the lifetime (in seconds or 292 Kilo-Bytes) the sessions are negotiated. In the case the ALG is 293 unable to setup the necessary address bindings or transport 294 bindings, IKE-ALG will not be able to translate security policies 295 and that will result in IKE not pursuing phase II negotiation for 296 the effected policies. 298 When the Negotiation is complete and successful, IKE will 299 communicate the negotiated security parameters directly to the 300 IPC-NAT gateway engine as described in the following diagram. 302 +---------+ 303 | | 304 Negotiated Security Parameters | IKE | 305 +--------------------------------| Process | 306 |(including session Keys) | | 307 | +---------+ 308 | ^ ^ 309 | Translated| | 310 | Secure| |Security 311 | Policies| |Proposals 312 v | | 313 +---------+ Security Policies, based +---------+ 314 | |------------------------->| | 315 | | on Pvt. realm addressing | | 316 | IPC-NAT | | | 317 | (IPsec | IPC-NAT MAPs | IKE-ALG | 318 | Gateway)|------------------------->| | 319 | | | | 320 | | Security Proposals | | 321 | |------------------------->| | 322 | | | | 323 | | NAT Control exchange | | 324 | |<------------------------>| | 325 +---------+ +---------+ 327 Figure 5. IKE-ALG translates Security policies, using NAT Maps. 329 5.0. Applications of IPC-NAT security model 331 IPC-NAT operational model described thus far illustrates how a 332 NAT device can be used as an IPsec tunnel end point to provide 333 secure transfer of data in external realm. This section will 334 attempt to illustrate two applications of such a model. 336 5.1. Secure Extranet Connectivity 338 IPC-NAT Model has a direct application of being able to provide 339 clear as well as secure connectivity with external realm using a 340 NAT device. In particular, IPC-NAT device at the border of a 341 private realm can peer with an IPsec gateway of an external domain 342 to secure the Extranet connection. Extranet refers to the portion of 343 the path that crosses the Internet between peering gateway nodes. 345 5.2. Secure Remote Access to Mobile Users of an Enterprise 347 Say, a node from an enterprise moves out of the enterprise, and 348 attempts to connect to the enterprise from remote site, using a 349 temporary service provider assigned address (Care-of-Address). In 350 such a case, the mobile user could setup an IPsec tunnel session 351 with the corporate IPC-NAT device using a user-ID and 352 authentication mechanism that is agreed upon. Further, the user may 353 be configured with enterprise DNS server, as an extension of 354 authentication following IKE Phase I. This would allow the user to 355 access enterprise resources by name. 357 However, many enterprise servers and applications rely on source IP 358 address for authentication and deny access for packets that do not 359 originate from the enterprise address space. In these scenarios, 360 IPC-NAT has the ability (unlike a traditional IPsec gateway) to 361 perform Network Address Translation (NAT) for remote access users, 362 so their temporary address in external realm is translated into a 363 enterprise domain address, while the packets are within private 364 realm. The flavor of IPC-NAT performed would be traditional 365 NAT (i.e., assuming mobile-user address space to be private realm 366 and Enterprise address space to be external realm), which can 367 either be Basic NAT (using a block of enterprise addresses for 368 translation) or NAPT(using a single enterprise address for 369 translation). 371 The secure remote access application described is pertinent to all 372 enterprises, irrespective of whether an enterprise uses IANA 373 registered addresses or not. 375 The secure remote access application described is different from 376 Mobile-IP in that, the mobile node (described in this application) 377 does not retain the Home-Network address and simply uses the 378 Care-Of-address for communication purposes. It is conceivable for 379 the IPC-NAT Gateway to transparently provide Mobile-IP type 380 connectivity to the Mobile node by binding the mobile node's 381 Care-of-Address with its Home Address. Provision of such an address 382 mapping to IPC-NAT gateway, however, is not within the scope of 383 this document. 385 6.0. Security Considerations 387 If NATs and ALGs are not in a trusted boundary, that is a major 388 security problem, as ALGs snoop end user traffic payload. 389 Application level payload could be encrypted end-to-end, so long 390 as the payload does not contain IP addresses and/or transport 391 identifiers that are valid in only one of the realms. With the 392 exception of Realm-Specific IP, end-to-end IP network level 393 security assured by current IPsec techniques is not attainable 394 with NATs in between. The IPC-NAT model described in this 395 document outlines an approach by which network level security 396 may be obtained within external realm. 398 NATs, when combined with ALGs, can ensure that the datagrams 399 injected into Internet have no private addresses in headers or 400 payload. Applications that do not meet these requirements may 401 be dropped using firewall filters. For this reason, it is not 402 uncommon to find that IPC-NATs, ALGs and firewalls co-exist 403 to provide security at the border of a private network. 405 REFERENCES 407 [1] P. Srisuresh, M. Holdrege, "The IP Network Address 408 Translator (NAT) terminology and considerations", RFC xxxx 410 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 411 Protocol", RFC 2401 413 [3] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 414 (ESP)", RFC 2406 416 [4] S. Kent, R. Atkinson, "IP Authentication Header", RFC2402 418 [5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 419 RFC 2409 421 [6] D. Piper, "The Internet IP Security Domain of Interpretation 422 for ISAKMP", RFC 2407 424 [7] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address 425 Behavior Today", RFC 2101 427 [8] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, 428 Lear, E. "Address Allocation for Private Internets", RFC 1918 430 Author's Address 432 Pyda Srisuresh 433 Lucent technologies 434 4464 Willow Road 435 Pleasanton, CA 94588-8519 436 U.S.A. 438 Voice: (925) 737-2153 439 Fax: (925) 737-2110 440 EMail: srisuresh@lucent.com