idnits 2.17.1 draft-ietf-ipsec-udp-encaps-justification-00.txt: ** The Abstract section seems to be numbered 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Missing revision: the document name given in the document, 'draft-ietf-ipsec-udp-encaps-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ipsec-udp-encaps-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-ipsec-udp-encaps-', but the file name used is 'draft-ietf-ipsec-udp-encaps-justification-00' ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 929 lines 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 ([Kiv00], [Hutt01], [Aboba04]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 2001) is 8344 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2026' is mentioned on line 20, but not defined == Missing Reference: 'IP' is mentioned on line 451, but not defined == Missing Reference: 'UDP 1025' is mentioned on line 451, but not defined -- Looks like a reference, but probably isn't: '501' on line 451 == Unused Reference: 'RFC-2409' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC-2407' is defined on line 796, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-00 == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-00 == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-ike-hash-revised-02 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) Summary: 13 errors (**), 1 flaw (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Protocol Security W. Dixon, B. Swander 2 Internet Draft Microsoft 3 Document: draft-ietf-ipsec-udp-encaps- A. Huttunen, J. Sierwald 4 justification-00.txt F-Secure Corporation 5 Category: Informational V. Volpe 6 Cisco Systems 7 L. DiBurro 8 Nortel Networks 9 M. Stenberg, T. Kivinen 10 SSH Communications Security Corp 12 June 2001 13 IPsec over NAT Justification for UDP Encapsulation 14 draft-ietf-ipsec-udp-encaps-justification-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of [RFC2026]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- Drafts 27 as reference material or to cite them other than as "work in 28 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 1. Abstract 39 This draft explains the design justification and alternatives for 40 two IPsec over NAT drafts, UDP Encapsulation of IPsec Packets, 41 [Hutt01] and [Kiv00]. This draft sets the requirements for a 42 solution in terms of scenarios in which NAT is used, and NAT 43 operations. This draft is specifies the requirements for IPsec NAT 44 traversal, scenarios these extensions enable, and design rationale 45 for the proposed solution. This draft assumes that the reader is 46 familiar with the interactions of NAT with IPsec documented in 47 [Aboba04]. 49 2. Conventions used in this document 51 In examples, "C:" and "S:" indicate lines sent by the client and 52 server respectively. A packet which is processed through a network 53 address translator (NAT) or a network address and port translator 54 (NAPT) is said to be "NATed". 56 Dixon, et. al. 1 57 IPsec over NAT Justification for UDP Encapsulation June 2001 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 61 this document are to be interpreted as described in [RFC-2119] 63 3. Introduction 65 NAT is widely used for Internet "connection sharing" and ships as a 66 standard feature in every router and edge device. Cable and DSL 67 deployments have been known to install NAT in embedded devices 68 resident inside the home. Additionally most hotel Internet 69 connections are using NAT. Many airport & wireless services in 70 public areas use NAT to connect to the Internet. Some Internet 71 Service Providers use a centralized NAT to connect their clients to 72 the Internet. 74 Without a solution to the problem, the L2TP/IPsec VPN client and an 75 IPsec tunnel mode VPN client can not connect from home or from 76 business sites which use NAT to connect to the Internet. Likewise, 77 transport TCP and UPD traffic that is protected by IPsec transport 78 mode can not be exchanged between peer to peer or server-to-server 79 applications. 81 Without an IETF standard solution for IPsec over NAT, vendor 82 products will not interoperate, and will be forced to support 83 multiple methods. 85 This proposal allows ESP to pass through NAT if the NAT allows UDP 86 traffic. It does not require the NAT to be aware of IPsec and IKE 87 negotiations. The technique is used only if the initiator and the 88 responder support it, and only used when necessary, since NAT 89 detection is built into the protocol. 91 This technique allows L2TP protected by IPsec transport mode using 92 the most popular and default encryption format (IPsec ESP) to go 93 through existing NATs - which do either port and address translation 94 of UDP packets or pure-address translation. 96 It also allows IPsec tunnel mode to go through the same type of 97 NATs, a requirement for many in the industry which implement 98 extensions to IPsec tunnel mode for remote access. Address 99 assignment can also use the standards track DHCP over IPsec method. 101 Note however that when RFC IPsec tunneling through a NAT between an 102 end system (static internal & external IP) and a gateway, or between 103 two gateways - the internal addresses used by packets inside the 104 IPsec tunnel can not be changed by the NAT. So the internal IP 105 packet will retain a potentially invalid address on the destination 106 network. There are three options to provide proper addressing for 107 tunneled packets: 109 - perform a second NAT function either before the tunnel ingress 110 or after the tunnel egress. 112 Dixon, et. al. 2 113 IPsec over NAT Justification for UDP Encapsulation June 2001 115 - In the case where traffic inside the tunnel is clear text TCP & 116 UDP traffic, this is normal NAT and not affected by the IPsec tunnel 117 being NATed itself. 119 - In the case where traffic inside the IPsec tunnel is IPsec 120 transport traffic, this spec provides the mechanism for the IPsec 121 transport peers to detect this second NAT and pass it accordingly. 123 - Not use the RFC method of negotiating an IPsec tunnel - instead 124 use proprietary extensions to RFC 2409 for address assignment for 125 remote access VPN tunnels. 127 - Keep the internal address as is, and configure the destination 128 network to be able to handle it. 130 This method should be able to be used in all scales where NAT is 131 deployed today to do simple pure address-to-address, or address and 132 port translation. However, it will not be able to be used where the 133 NAT would otherwise perform packet inspection and replacement of 134 address or port information inside the packet (e.g. modifying the 135 FTP PORT command packet). Thus UDP encapsulated IPsec transport and 136 tunnel traffic will be successful if the communications model is 137 that the client initiates TCP connections & UDP sessions from itself 138 out through the NAT. 140 This protocol does not involve the client communicating directly 141 with the NAT for the purpose of opening ports to receive inbound 142 connections. If required, another method such as RSIP may be used 143 by the application first to communicate with the NAT. 145 IKE & IPsec issues with NAT are documented in [Aboba04]. This 146 proposal provides a solution to all issues identified when using IKE 147 Identity Protect Mode (Main Mode) or Aggressive Mode and Quick Mode. 148 Other proprietary IKE extensions may be present, but are not 149 considered by this draft. Address assignment for a remote access VPN 150 IPsec tunnel client can use DHCPv4 Configuration of IPsec Tunnel 151 Mode [Patel12]. 153 Most importantly, this proposal does not require change to the NAT 154 device itself - which is seen as practically too difficult to 155 accomplish. The deployment of IPsec enabled systems is typically 156 controlled by the user of that system, and thus can be updated 157 independently of the network infrastructure at ISPs, hotels, mobile 158 and temporary networks, and other places where NAT is required to 159 overcome limited IPv4 Internet routeable address availability. We 160 expect the technique described here to be used in the interim to 161 pass IPv4 addressed traffic only. We expect this technique to 162 become outdated as IPv6 is deployed, enabling end-to-end IPsec 163 without address translation. 165 4.
167 Dixon, et. al. 3 168 IPsec over NAT Justification for UDP Encapsulation June 2001 170 Aboba presents requirements for an IPsec over NAT solution. The 171 [Kiv00]and [Hutt01] drafts do this as follows: 173 1. Deployability - the design ensures that IKE and IPsec ESP 174 appear only asUDP protocol packets which are allowed to have their 175 source and destination addresses changed by a common NAT. An IPsec 176 aware NAT is not required. Thus the network infrastructure need not 177 change. Firewalls can filter on a single UDP port. No change in 178 DNS clients, DNS servers, DHCP clients, DHCP servers, or 179 applications programs are required for this IPsec over NAT solution, 180 as is typically required for IPv6 deployment. There is no 181 communication between host and NAT device. The timeframe for 182 deployment is simply the timeframe for end systems to have a 183 software patch or update which enables the protocol functionality 184 defined here. 186 2. Telecommuter scenario. While this draft claims no need for 187 support beyond that needed for telecommuter scenarios, the IPsec 188 protocol is more generally useful than for VPN remote access. Thus 189 our design solves remote access scenarios and makes general IPsec 190 transport mode or tunnel mode work through single and multiple NAT 191 devices. 193 3. Scaling. The solution specified our drafts will provide for 194 scaling on the receiving end on the order which memory, CPU and 195 hardware acceleration allow for RFC IPsec. There is no inherent 196 limitation in our design to scaling. Overlapping SPD entries are 197 addressed by the treatment of values contained in the main mode and 198 aggressive mode ID payloads, and Proxy ID payloads. 200 4. Mode support. Our design provides for both IKE Identity 201 Protect Mode and Aggressive Mode to negotiate IPsec transport and 202 tunnel mode UDP ESP encapsulation. Our wire format and IKE design 203 do specify a solution for AH encapsulation through NAT. However, 204 this capability is included only so the drafts as standards track 205 documents offer a "complete solution". Practically, we do not 206 expect an implementation to support AH over NAT, preferring ESP null 207 encryption with integrity, or an IPsec ESP tunnel mode for full 208 packet encapsulation instead. 210 5. Interoperability. Backward compatibility is assured through 211 the continued use of UDP 500 with additional payloads to announce 212 the capability of NAT discovery and traversal. To the extent that 213 existing implementations properly discard payloads they do not 214 understand, an IPsec-over-NAT capable client will interoperate 215 cleanly with an earlier IPsec/IKE client without the presence of 216 NAT. 218 6. Security. The security considerations section of [Kiv00] 219 discusses specifically the security implications to IKE of including 220 new payloads. It was decided to leave these payloads 221 unauthenticated in order to more expediently reach a solution for 223 Dixon, et. al. 4 224 IPsec over NAT Justification for UDP Encapsulation June 2001 226 IPsec over NAT, rather than adopt new proposals for the 227 authentication of all payloads in IKE phase 1 and phase 2 discussed 228 by the now expired [Kiv-HASH-02]. Further, we specifically did not 229 change anything about verifying the contents of a tunnel match the 230 address selectors negotiated in the Proxy ID. And we provide a NAT- 231 OA original address payload so that the authenticated IPsec 232 receiving peer may either reconstruct the original packet headers or 233 take some other action based on knowledge of the original address 234 for the purpose of anti-spoofing checks during packet processing. 236 Additionally the following goals were set by the authors for an 237 IPsec over NAT solution: 238 1. One IETF standardized way for IKE/IPsec NAT traversal. 240 2. Minimize the use of UDP encapsulation overhead 241 a. Discover if NAT is present in the path between the two IKE 242 peers, and discover which is behind the NAT. 243 b. Allow for products to be configured to not perform UDP 244 encapsulation when the user knows the presence of the NAT, it�s 245 IPsec-friendly capability. product works through IPsec-friendly 246 NATs. 248 3. Transport IKE and IPsec traffic through the NAT without forcing 249 the NATs to be modified. 251 4. Keep the NAT mappings (or state firewall mappings) alive for 252 the duration of the IKE and IPsec sessions. 254 5. Keep IKE as simple as possible for ease of interop, better 255 security. 257 6. Minimize keep-alive traffic to reduce the number of timers 258 required. 260 5. NAT Scenarios 262 This section identifies common network topologies where NAT is used 263 to pass traffic between address boundaries. A NAT device may also 264 be viewed as a stateful filtering device that performs no 265 translation of the address or ports in the packet, but creates 266 mapping states specific to the address and port information in a 267 packet. 269 All below scenarios may support an IPsec transport/tunnel SA for all 270 possible traffic, where 1 or more TCP or UDP or other protocol 271 sessions may be protected by the single IPsec transport/tunnel 272 security association. Security associations are assumed to exist in 273 pairs. There may be multiple transport/tunnel SAs of finer 274 granularity as well. 276 Dixon, et. al. 5 277 IPsec over NAT Justification for UDP Encapsulation June 2001 279 The term "private IP address" used here is not restricted to be the 280 IANA defined private IP address space, but rather is exemplary of an 281 address used within an address boundary defined by the NAT device. 283 A. One or more clients behind a NAT connecting simultaneously to a 284 server's Internet IP address. 286 C1 private IP <-> NAT Internet IP <---> Internet IP S1 288 NAT is doing pure address translation 1:1, or doing many:1 address 289 translation with port translation. 291 B. One or more clients behind NAT1 connecting simultaneously to the 292 same dest IP address which is behind NAT2 294 C1 private IP <-> NAT1 Internet IP <-> Internet IP NAT2 <-> private 295 IP S1 297 NAT1 is performing many:1 port address translation (onto Internet 298 for example), NAT2 is performing 1:1 address translation (into DMZ 299 for example) 301 C. One or more clients through 2 or more outbound NATs to 302 destination Internet IP address 304 C1 private IP <-> NAT1 private IP <-> NAT2 Internet IP <-> Internet 305 IP S1 307 NAT1, NAT2 are performing many:1 port address translation. 309 D. Internet client connecting to server behind NAT. 311 C1 Internet IP <-> Internet IP NAT1 <-> private IP S1 313 NAT would most likely be doing 1:1 address translation, but may be 314 publishing an address and port combination that is fully translated 315 to an private address and different port. 317 E. Multiple clients identically configured (i.e. C1 and C2 have the 318 same private network IP address assigned to them, e.g. 192.168.0.2), 319 each behind their own NAT, connected to same Internet IP of Server1. 321 C1 private IP <-> NAT1 Internet IP <-> Internet IP S1 322 C2 private IP <-> NAT2 Internet IP <-> Internet IP S1 324 F. Gateway to gateway tunnel over NAT. 326 C1 private IP <-> GW1 <=> NAT1 Internet IP <=> GW2 <-> private IP S1 328 An IPsec tunnel SA is established between GW1 and GW2. NAT1 329 performs address translation on the tunnel packets. 331 Dixon, et. al. 6 332 IPsec over NAT Justification for UDP Encapsulation June 2001 334 6. Design Overview and Rationale> 336 The IETF standard for NAT traversal by IPsec should be unencumbered 337 from intellectual property claims to ensure rapid adoption by the 338 IPsec vendor community. 340 We propose to UDP encapsulate the ESP traffic, thereby allowing it 341 through the NAT. 343 During design several different criteria needed to be balanced 344 - Encapsulation using UDP port 500 was chosen so as to enable 345 easy deployment without the need to change firewall rules used by 346 corporations. 347 - The chosen method UDP encapsulates ESP traffic as efficiently 348 as possible. AH and future protocols may be UDP encapsulated, but 349 at greater expense. This ensures that the most widely needed traffic 350 protection method is most efficient. 351 - Encapsulation using UDP port 500 makes each packet 8 bytes 352 larger than encapsulation using a different port, this is however 353 balanced by the reduced need to have keepalive packets, and reduced 354 complexity in IKE. 356 7.0 UDP-encapsulated ESP Header Format 358 7.1 Not using TCP 360 UDP header provided minimal standard encapsulation, 8 bytes, that 361 would traverse exiting NATs. TCP would incur a minimal 20byte 362 header. 364 NAT and firewall devices are aware of TCP connection setup traffic 365 pattern. Thus these devices expect to see a real TCP connection 366 establish and operation, but to varying degrees. It was a non-goal 367 of this work to enable IPsec work through a TCP proxy. Thus a TCP 368 encapsulation would only be for the purpose of exposing a useless 369 header for NAT traversal. 371 We could run IKE over TCP or we could use IKE as it is and just use 372 TCP for IPsec SA packet encapsulation. A real TCP connection would 373 degrade the reliability of communication which the security features 374 of IPsec SAs and packet format provide. For both IKE and IPsec, the 375 traffic flow channel is not subject to disruption, except by packet 376 loss or packet modification. Using a real TCP connection to 377 transport either IKE or IPsec would introduce vulnerability to 378 trivial TCP connection reset attacks by spoofed TCP packets. Thus 379 logic would have to be implemented to constantly re-establish the 380 TCP connection whenever it went down. Which side would do this ? 381 It would have to be the side that originally established the 382 communication if stateful filtering were in place. Therefore a real 383 TCP connection would not be desired. Rather a fake TCP handshake 385 Dixon, et. al. 7 386 IPsec over NAT Justification for UDP Encapsulation June 2001 388 and then using a TCP header without sequence number tracking, 389 ACKing, etc. An additional weakening of the security properties of 390 IKE would be introduced if TCP FIN or RST flags where used in 391 combination with IKE SA delete messages. Thus a keep-alive 392 mechanism would need to be invented for this partial TCP 393 functionality. 395 There is some evidence to suggest that when IPsec transported a 396 normal TCP connection over yet another full TCP connection, the two 397 TCPs will interact with each other to slow down data transfer 398 [Titz]. 400 Routers handle TCP so to ensure in order delivery of TCP segments. 401 Most TCP implementations require nor more than 3-5 packets received 402 out of order. There is no such requirement for UDP, only the IPsec 403 SA anti-replay window. 405 It was the consensus of the authors that the complexity of faking 406 TCP and the additional overhead of the TCP header made UDP the 407 preferred choice for encapsulation. 409 7.2 Unifying Control and Data traffic on UDP 500 411 A single UDP src, dst port mapping is used for both IKE and IPsec 412 packets. Since the IKE initiation is sent to the well known ISAKMP 413 destination port 500, the receiver must use the UDP source port as 414 the packet is received (inbound SA) to be the destination port of 415 the return traffic (outbound SA). The source port of the return 416 traffic must be the destination port observed when the inbound SA 417 packet was received. This is to ensure that NAT port mappings are 418 properly preserved. 420 This draft uses the well-known IKE UDP port 500 to encapsulate both 421 IKE control traffic and ESP data traffic. This approach allows for: 423 - a single well known port over which ESP UDP encapsulation would 424 be done. The IKE port is already assigned, and well-known for IPsec 425 so existing documentation and training won�t have to be changed. 426 - It is easiest to explain how to allow IPsec traffic, simply 427 open UDP port 500 428 - A single approach allows firewall configurations to ship with 429 defaults 430 - minimization of keep-alive/heartbeats for both IKE & ESP - as 431 long as there was traffic flowing middle devices like stateful FWs & 432 NATs would keep the mapping alive 434 8. Alternatives To Unified Data & Control Considered 436 In the following, "501" refers to a newly defined (eventually by 437 IANA) well-known port for IKE. Using "501" either for IKE and/or 438 for the UDP encapsulation of the IPsec packets would allow us to 439 change the header formats of IKE and potentially squeeze out more 441 Dixon, et. al. 8 442 IPsec over NAT Justification for UDP Encapsulation June 2001 444 efficiency for the more common IPsec traffic. For example, the 445 format could be: 447 [IP][UDP 1025, 501][IPsec ESP traffic] 449 And 451 [IP] [UDP 1025, 501][<4 bytes 0>][<4 byte TYPE>][IKE or ESP 452 traffic.] 454 In the second case, the <4 bytes 0> would line up with the ESP 455 header's SPI, which would never be 0, therefore distinguishing the 456 difference if both were encapsulated on 501. This clearly has the 457 benefit of being tighter on the wire for the more common ESP 458 traffic. The alternatives below will show why we discarded these 459 (and similar) encapsulation schemes. 461 8.1 Using a non-500 dest port for "IPsec over NAT" negotiation traffic 463 One desired benefit of using 501 was to completely isolate the 464 IKE/IPsec over NAT from the standard IKE/IPsec implementation. We 465 would still keep IKE and ESP on the same port pair, and thus 466 essentially defined a new well known port and protocol for it, 467 preserving UDP 500 as "unpolluted" for RFC 2409 use only. However, 468 this does not meet [Aboba04] requirement of backward compatibility. 469 Also, UDP 500 is already extended in many ways with special behavior 470 indicated through the use of vendor-id payloads. 472 The operational issue is how the initiator knows to use this UDP 473 dest port 501 for the first packet when IKE initiates. It could be 474 configured if the initiator knows it is behind a NAT. However this 475 seems very impractical as NATs are generally invisible to the end 476 system behind it and there would be no way to establish trust with 477 the hotel NAT, the home NAT, the ISP NAT, etc. 479 The deciding factor is that we only want to use the UDP 480 encapsulation when necessary, that is when a NAT is discovered. So 481 we conclude that NAT discovery must be part of the initial IKE 482 negotiation for this technique to be widely deployable. 484 The initiator could attempt 500 and then retry on 501 at the heavy 485 expense of a timeout. Or the initiator could send simultaneously to 486 501 and to 500. The 501 packet could include NAT discovery, while 487 the 500 packet would not. Either we receive no reply to the 500 488 packet, or we do but also receive a reply from 501 indicating NAT. 489 Clearly timing may introduce a mistake in the decision of which mode 490 to use. Better to avoid this complexity altogether and work within 491 the standard IKE message exchange state machine. 493 To know that 500 did not succeed because of a NAT, we'd need 494 discovery packets in the port 500 usage negotiation. To reply back 495 to the initiator that NAT was discovered, the port 500 receiver 497 Dixon, et. al. 9 498 IPsec over NAT Justification for UDP Encapsulation June 2001 500 would have to reply back to the as-received source port. For some 501 implementations of IKE, this is also a change. So we saw several 502 changes required in IKE using port 500 to enable usage of 501. It 503 was then clear that NAT discovery using port 500 was the way to go. 504 A new NAT-traversal behavior would be engaged by first the 505 capability message, and secondly by the actual discovery payloads. 507 8.2 Initial contact on 500, discovery, move IKE to well known port 501 509 We could still move the negotiation off of 500 when NAT was 510 discovered. In the middle of the negotiation, it is possible for 511 both peers to float to using 501 at the same time. This would be 512 for the eventual purpose of using the same src, dst 501 port pair 513 (NAT mapping) for the IPsec SAs bound to the IKE exchange to 514 aggregate keep-alives. The initial outbound mapping for 500 would 515 expire on the NAT, followed by a new mapping would be established by 516 the completion of IKE and maintained by the IPsec SA packet flow. 518 The main problem here is when and how to float. This would have to 519 be clearly defined with MUST statements to assure interoperability. 520 Clearly, the easiest time to float would be at the end of Main Mode, 521 but before Quick Mode started. However, there is the design 522 requirement that we allow for negotiation of encapsulation type in 523 Quick Mode to support the case of allowing IPsec-friendly NATs to 524 pass non-UDP encapsulated ESP traffic. So, if we floated to 501 525 before Quick Mode, we will do that unnecessarily in the IPsec- 526 friendly NAT case. If we delay floating to 501 until after both 527 sides have agreed to do UDP encapsulation in the quick mode SA 528 payload exchange, then we have timing conditions since there may be 529 multiple quick modes going, and floating any one quick mode, floats 530 the main mode under it, to the potential detriment of the other 531 quick modes. 533 Rekey introduces additional interop complexity. Assume the float to 534 501 by the above means happens at the end of main mode. Assume the 535 peer outside the NAT is rekeying the Main Mode. Since IKE floated 536 to 501, there are no keep alives keeping a UDP 500 hole open, so the 537 peer will need to initiate the MM to 501 instead of 500. Now we 538 have to handle the case where the main mode starts on 501 as well. 540 Finally, we consider the firewall configuration. The case where 541 neither side has initiated, but either side could, means the 542 firewall configuration would have to allow inbound requests on both 543 sides destined to 500 and to 501. The authors didn't think this was 544 a major reason, but one to mention as we have all experienced 545 resistance to opening ports from customer firewall administrators. 547 8.3 Initial contact on 500, discovery, move IKE to dynamically 548 chosen port 550 Dixon, et. al. 10 551 IPsec over NAT Justification for UDP Encapsulation June 2001 553 In addition to all the complexities above, this approach makes 554 static port filtering in effective. Handling the idle (no active 555 IPsec quick mode) and rekey cases make this the most difficult 556 choice with which to achieve interoperability. The typical scenario 557 of double firewalls would pose the greatest difficulty, as IKE can 558 initiate from either side. 560 8.4 Initial contact and maintain IKE on 500, use 501 for IPsec only 562 The motivation for this approach is to avoid an 8 byte cookie=0x00 563 as the demultiplexing value to separate ESP traffic from IKE traffic 564 which is used when all traffic uses only port 500. 566 This approach means that we must keep both the 500 and 501 NAT 567 mappings alive. The only real problem with this approach is that is 568 depends on the initiator of the negotiation to also be the initiator 569 of the UDP src xxx, dst 501 packet in order to establish the NAT 570 mapping. This is not always the case. 572 In scenario A, where the client initiated from behind the NAT to 573 establish the NAT1 translation to UDP source 1025, dest 500, then 574 sent another outbound UDP packet to 501, which the NAT would 575 translate to UDP src 1026, dest 501 - this would work initially. 576 Assume then that the client performs a long running download of 577 data, causing the gateway to rekey quick mode first. When the 578 gateway, still using the UDP 1025, 500 mapping for IKE, completed 579 the quick mode, it could not send to UDP destination 501 because the 580 client's NAT does not have a mapping for this. Instead, the gateway 581 must continue to use UDP 1026, 501 for the UDP encapsulation of the 582 new ESP SA. 584 Now consider that the session goes idle - idle from the point of 585 view of the IPsec SA being used to send protected packets. The 586 client is still sending keep alive packets to maintain the client 587 mapping on the NAT. But the gateway doesn't necessarily get these. 588 So the gateway can delete the IPsec SA, as can the client. Both may 589 or may not make the decision to delete their inbound or outbound SA 590 at any time. The notify messages may or may not be sent and may or 591 may not be honored by the receiver. Perhaps an outbound packet 592 arrives to the IPsec system which would use the already deleted 593 IPsec SA. The gateway rekeys to the client using quick mode on UDP 594 1025, 500. The gateway now must choose a UDP source port with dest 595 501 for the UDP encapsulation of the new IPsec SA. The client's NAT 596 won't have a mapping for anything other than what the client used 597 previously. So the gateway MUST use the previous mapping, and the 598 client MUST keep the mapping alive for deleted IPsec SAs. The 599 client is not the sender of the first ESP packet on the new quick 600 mode. This could be fixed by the client "punching out" with a keep- 601 alive message, in anticipation of the incoming UDP ESP packet from 602 the gateway destined for UDP 501 on the client. But the complexity 603 and timing conditions can be avoiding by always using the 605 Dixon, et. al. 11 606 IPsec over NAT Justification for UDP Encapsulation June 2001 608 established IKE UDP mapping. Interoperability is also better served 609 by keeping the same mapping. 611 Using both 501 and 500 doubles the keep-alives since both must be 612 kept current on the NAT, which increases the state required for each 613 IPsec SA. And again, using both 500 and 501 requires firewall 614 administrators to open both for bidirectional communication. 616 9. Addresses in IKE ID Payloads 618 9.1 IKE Main Mode ID Payload 620 If a NAT is present, certain limitations are placed upon the valid 621 IDs exchanges in IKE. RFC 2408 and 2407 specify the ID payload to 622 represent an identity of the initiator for the purpose of the 623 responder using it for a policy lookup. Section 4.6.2.1 624 Identification Type Values allows many types. However in practice, 625 implementations choose one or a few type values to support in their 626 policy system. Backward compatibility is not a concern, as both 627 initiator and responder must change to support this draft. However, 628 backward compatibility with policy configuration systems is desired. 629 The authors think that the IKE Main Mode ID payload value is largely 630 being ignored or is not relevant to security policy lookup in the 631 majority of IKE implementations, based on interop test results. We 632 think this is because the receiver can not depend on an initiator 633 (other than it's own implementation) using a particular type value. 635 So [Kiv00] simply omits mention of the Main Mode ID payload, leaving 636 it as a local matter. If the ID payload is meaningful in the 637 implementation as an IP address, then that implementation must 638 decide how to handle the case where the initiator's IP address put 639 into the ID payload is invalid to the receiver. The receiver will 640 know that NAT is present based on NAT discovery. 642 9.2 Addresses in IKE Quick Mode Proxy ID Payload 644 There was no consensus among the draft authors about particular 645 language, so [Kiv00] does not address this at all. We note here 646 that the IPsec packet processing comparison against the proxy id 647 selector is a MUST via RFC 2401, 5.2.1 page 32, "In general, a 648 packet's source address MUST match the SA selector value." 650 This is most security critical in tunnel mode. But actually the 651 tunnel mode proxy ID selectors would be the same as without NAT. So 652 it's not an issue in tunnel mode. The tunnel mode Proxy ID using 653 address selectors MUST remain a descriptor for the contents of the 654 tunnel. 656 In transport mode ESP through NAT - to be consistent on this RFC 657 2401 MUST point, there are two ways to go: 658 1. the IKE-NAT-T initiator MUST propose 0.0.0.0 as source IP in the 659 Proxy ID quick mode selector 661 Dixon, et. al. 12 662 IPsec over NAT Justification for UDP Encapsulation June 2001 664 2. the [Kiv00] responder MUST use the actual source IP of the packet 665 to replace the source IP of the initiator's selector before doing 666 responder policy lookup with that selector. 668 #2 seems the best way to go to allow policy to be set for Internet 669 source IPs (e.g. all traffic from DMZ Corp A would have source 670 IP=xxx.xx.xx.xx when going outbound through their NAT - the selector 671 at Corp B could be specific about traffic from Corp A.). 673 We are open to comments on an [Kiv00] section 4.3, something like: 675 "For transport quick mode, the proxy ID source IP address is sent by 676 the initiator per RFC 2409. However the [Kiv00] compliant responder 677 MUST use the actual source IP of the packet to replace the source IP 678 of the initiator's selector before doing responder policy lookup 679 with that selector. This is a MUST, not SHOULD, to be consistent 680 with RFC 2401 section 5.2.1 which requires selector comparison after 681 decryption." 683 However, for transport mode, since the packet is authenticated by 684 the successful processing of the hash, when the selector used in the 685 Proxy ID was NOT an IP address, perhaps an FQDN, there is no meaning 686 to the RFC 2401 MUST check of the packet against the selector. 688 So we have omitted specifying the Proxy ID payload contents and 689 handling, leaving the processing as a local matter. 691 10. Keep-alive Mechanism 693 The keep-alive packet is used to maintain a viable UDP path between 694 IPsec peers. It provides traffic flow in the absence of normal IKE 695 or IPsec traffic so that NAT and stateful filtering mappings remain 696 active. The mechanism must work to maintain the mapping for the 697 majority of existing NATs, without changing the NAT. The keep-alive 698 packet is used strictly for path maintenance. It has no security 699 function and thus does not use the cryptographic context of either 700 IKE or IPsec. Thus a minimal UDP packet is sufficient for this 701 purpose. Since it is not known how far on the path between peers 702 the NAT occurs, the packet is sent with normal TTL values, not 1 or 703 2. The keep-alive SHOULD only be sent by the peer(s) behind the NAT 704 to minimize keep alive traffic. The keep-alive SHOULD be silently 705 discarded by the IPsec packet processor. 707 An informal survey of NAT mapping timeouts showed a minimum of 30 708 seconds as the time at which the mapping expired for UDP. 709 There are IETF IPsec Working Group proposals on a keep-alive 710 mechanism for IPsec or IKE peers, which uses the security context 711 established between them. However, that keep-alive mechanism may 712 not reach consensus in the working group before the NAT traversal 713 work. That mechanism may be necessarily indistinguishable from 714 normal IKE and IPsec traffic, and thus not filterable by the network 716 Dixon, et. al. 13 717 IPsec over NAT Justification for UDP Encapsulation June 2001 719 to conserve bandwidth. Also, that mechanism need not be frequent 720 enough to maintain a UDP path, since its purpose is to reliably 721 verify that a peer cryptographic context exists (e.g. An IPsec 722 tunnel still exists). 724 11. Security Considerations 726 The authors do not think this method exposes any security 727 vulnerabilities into otherwise sound IPsec implementation. However, 728 the following issues need to be addressed by implementers. 730 When using IPsec tunnel mode, clients connecting to the gateway may 731 be using the same IP address in the inner IP header. One scenario 732 where this is likely to happen is when the clients are using in the 733 inner IP header their local private network address, and they are in 734 different private networks. The GW MUST ensure that traffic destined 735 towards the clients is sent only to the correct recipient. 737 When using IPsec tunnel mode, a client connecting to a gateway may 738 be trying to steal an IP address from the network protected by the 739 gateway. The QM initiated by the client MUST only be allowed by the 740 gateway if: 741 - The QM IP address identities match the static policy defined at 742 the gateway. 743 - The QM IP source address matches the address assigned to the 744 client by the gateway. 745 - The gateway is configured to do further NAT to the packets, 746 ensuring that whatever IP address the client is using, this cannot 747 be used to steal local network IP addresses. 748 Any of these ensures that attacker is not possible to steal local 749 network IP addresses. 751 An active attacker can change the UDP header such that the UDP 752 destination port will be different that 500 or 501. This will cause 753 a stream of IKE or ESP packets to be delivered to another port. An 754 application listening on that UDP port may get flooded with packets 755 it can not understand. Denial of service for that other UDP 756 application may be accomplished. Denial of service on the system 757 may be accomplished if the processing of the bogus packets consumes 758 CPU or crashes that service. 760 12. Intellectual Property Rights 762 The IETF has been notified of intellectual property rights claimed 763 in regard to some or all of the specification contained in this 764 document. For more information consult the online list of claimed 765 rights. 767 SSH Communications Security Corp has notified the working group of 768 one or more patents or patent applications that may be relevant to 769 this internet-draft. SSH Communications Security Corp has already 770 given a license for those patents to the IETF. For more information 771 consult the online list of claimed rights. 773 Dixon, et. al. 14 774 IPsec over NAT Justification for UDP Encapsulation June 2001 776 13. References 778 [Aboba04] Aboba, B. "IPsec-NAT Compatibility Requirements", draft- 779 aboba-nat-ipsec-04.txt, 30 May 2001. 781 [Hutt01] Huttunen, A. et. al., "UDP Encapsulation of IPsec 782 Packets", draft-ietf-ipsec-udp-encaps-00.txt, April 2001. 784 [Kiv00] Kivinen, T. et. al., "Negotiation of NAT-Traversal in the 785 IKE", draft-ietf-ipsec-nat-t-ike-00.txt, May 2001. 787 [Kiv-HASH-02] Kivinen, T., "Fixing IKE Phase 1 & 2 Authentication 788 HASHs", draft-ietf-ipsec-ike-hash-revised-02.txt, 22 November 2000. 790 [Patel12] Patel, B. "DHCPv4 Configuration of IPsec Tunnel Mode", 791 draft-ietf-ipsec-dhcp-12.txt, 13 May 2001. 793 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange 794 (IKE)", RFC 2409, November 1998. 796 [RFC-2407] Piper D., "The Internet IP Security Domain Of 797 Interpretation for ISAKMP", RFC 2407, November 1998. 799 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 800 Requirement Levels", RFC 2119, March 1997. 802 [Titz] Titz, Olaf. "Why TCP Over TCP Is A Bad Idea" 803 http://sites.inka.de/sites/bigred/devel/tcp-tcp.html 805 14. Acknowledgements 807 The authors wish to acknowledge and thank Bernard Aboba, Cheryl 808 Madson and Jonathan Trostle. 810 15. Author's Addresses 812 Tero Kivinen 813 SSH Communications Security Corp 814 Fredrikinkatu 42 815 FIN-00100 HELSINKI 816 Finland 817 E-mail: kivinen@ssh.fi 819 Markus Stenberg 820 SSH Communications Security Corp 821 Fredrikinkatu 42 822 FIN-00100 HELSINKI 823 Finland 824 E-mail: mstenber@ssh.com 826 Dixon, et. al. 15 827 IPsec over NAT Justification for UDP Encapsulation June 2001 829 Ari Huttunen 830 F-Secure Corporation 831 Tammasaarenkatu 7, 832 FIN-00181 HELSINKI 833 Finland 834 E-mail: Ari.Huttunen@F-Secure.com 836 William Dixon 837 Microsoft 838 One Microsoft Way 839 Redmond WA 98052 840 E-mail: wdixon@microsoft.com 842 Brian Swander 843 Microsoft 844 One Microsoft Way 845 Redmond WA 98052 846 E-mail: briansw@microsoft.com 848 Victor Volpe 849 Cisco Systems 850 124 Grove Street 851 Suite 205 852 Franklin, MA 02038 853 E-mail: vvolpe@cisco.com 855 Larry DiBurro 856 Nortel Networks 857 XXX address missing 858 ldiburro@nortelnetworks.com 859 Full Copyright Statement 861 "Copyright (C) The Internet Society (date). All Rights Reserved. 863 This document and translations of it may be copied and 864 furnished to others, and derivative works that comment on or 865 otherwise explain it or assist in its implementation may be 866 prepared, copied, published and distributed, in whole or in 867 part, without restriction of any kind, provided that the above 868 copyright notice and this paragraph are included on all such 869 copies and derivative works. However, this document itself may 870 not be modified in any way, such as by removing the copyright 871 notice or references to the Internet Society or other Internet 872 organizations, except as needed for the purpose of developing 873 Internet standards in which case the procedures for copyrights 874 defined in the Internet Standards process must be followed, or 875 as required to translate it into languages other than English. 877 The limited permissions granted above are perpetual and will 878 not be revoked by the Internet Society or its successors or 879 assigns.