idnits 2.17.1 draft-ietf-ipsec-nat-t-ike-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 619. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 108 instances of too long lines in the document, the longest one being 54 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (10 Feb 2004) is 7379 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC XXXX' is mentioned on line 587, but not defined == Unused Reference: 'IETF SUB' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'IETF IPR' is defined on line 646, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-06 Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Protocol Working Group (IPsec) T. Kivinen 3 INTERNET-DRAFT SafeNet A. Huttunen 4 draft-ietf-ipsec-nat-t-ike-08.txt B. Swander 5 Expires: 10 July 2004 Microsoft F-Secure Corporation 6 V. Volpe 7 Cisco Systems 8 10 Feb 2004 10 Negotiation of NAT-Traversal in the IKE 12 Status of This Memo 14 This document is a submission to the IETF IP Security Protocol 15 (IPSEC) Working Group. Comments are solicited and should be 16 addressed to the working group mailing list (ipsec@lists.tislabs.com) 17 or to the editor. 19 This document is an Internet-Draft and is in full conformance 20 with all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as 31 "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes how to detect one or more network address trans- 42 lation devices (NATs) between IPsec hosts, and how to negotiate the use 43 of UDP encapsulation of IPsec packets through NAT boxes in Internet Key 44 Exchange (IKE). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 50 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3 52 3.2. Detecting the presence of NAT . . . . . . . . . . . . . . . 3 53 4. Changing to new ports . . . . . . . . . . . . . . . . . . . . . 5 54 5. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 8 56 5.2. Sending the original source and destination addresses . . . 8 57 6. Initial contact notifications . . . . . . . . . . . . . . . . . 10 58 7. Recovering from the expiring NAT mappings . . . . . . . . . . . 10 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 61 10. Intellectual property rights . . . . . . . . . . . . . . . . . 12 62 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 63 12. Normative References . . . . . . . . . . . . . . . . . . . . . 13 64 13. Non-Normative References . . . . . . . . . . . . . . . . . . . 13 65 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 66 15. Full copyright statement . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 This document is split in two parts. The first part describes what is 71 needed in IKE Phase 1 for NAT-Traversal support. This includes detecting 72 if the other end supports NAT-Traversal, and detecting if there is one 73 or more NAT between the peers. 75 The second part describes how to negotiate the use of UDP encapsulated 76 IPsec packets in IKE's Quick Mode. It also describes how to transmit the 77 original source and destination addresses to the peer if required. The 78 original source and destination addresses are used in transport mode to 79 incrementally update the TCP/IP checksums so that they will match after 80 the NAT transform (The NAT cannot do this, because the TCP/IP checksum 81 is inside the UDP encapsulated IPsec packet). 83 The document [Hutt03] describes the details of UDP encapsulation and 84 [Aboba03] provides background information and motivation of NAT- 85 Traversal in general. This document, in combination with [Hutt03] 86 represents an "unconditionally compliant" solution to the requirements 87 as defined by [Aboba03]. 89 The basic scenario for this document is the case where the initiator is 90 behind NA(P)T and the responder has a fixed static IP address. 92 This document defines a protocol that will work even if both ends are 93 behind NAT, but the process of how to locate the other end is out of the 94 scope of this document. In one scenario, the responder is behind a 95 static host NAT (only one responder per IP as there is no way to use any 96 other destination ports than 500/4500), i.e. it is known by the 97 configuration. 99 2. Specification of Requirements 101 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 102 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 103 "OPTIONAL" to describe requirements. They are to be interpreted as 104 described in [RFC-2119] document. 106 3. Phase 1 108 The detection of support for NAT-Traversal and detection of NAT along 109 the path between the two IKE peers occurs in IKE [RFC-2409] Phase 1. 111 The NAT may change the IKE UDP source port, and recipients MUST be able 112 to process IKE packets whose source port is different than 500. There 113 are cases where the NAT does not have to change the source port: 115 o only one IPsec host behind the NAT 117 o for the first IPsec host the NAT can keep the port 500, and the NAT 118 will only change the port number for later connections 120 Recipients MUST reply back to the source address from the packet (See 121 [Aboba03] section 2.1, case d). This also means that when the original 122 responder is doing rekeying, or sending notifications etc. to the 123 original initiator it MUST send the packets using the same set of port 124 and IP numbers that was used when the IKE SA was last time used. 126 For example, when the initiator sends a packet having source and 127 destination port 500, the NAT may change that to a packet which has 128 source port 12312 and destination port 500. The responder must be able 129 to process the packet whose source port is that 12312. It must reply 130 back with a packet whose source port is 500 and destination port 12312. 131 The NAT will then translate this packet to have source port 500 and 132 destination port 500. 134 3.1. Detecting support of Nat-Traversal 136 The NAT-Traversal capability of the remote host is determined by an 137 exchange of vendor ID payloads. In the first two messages of Phase 1, 138 the vendor id payload for this specification of NAT-Traversal (MD5 hash 139 of "RFC XXXX" - ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if 140 supported (and it MUST be received by both sides) for the NAT-Traversal 141 probe to continue. 143 [Note to the RFC Editor: The XXXX is replaced with the RFC number of 144 this document when the number is known. The XXXXXXXX XXXXXXXX XXXXXXXX 145 XXXXXXXX will be replaced with MD5 hash of the text "RFC XXXX" (the 146 exact hex string will be provided by the authors when the rfc number is 147 known). This instruction is to be removed from the final RFC]. 149 3.2. Detecting the presence of NAT 150 The purpose of the NAT-D payload is twofold, It not only detects the 151 presence of NAT between the two IKE peers, it also detects where the NAT 152 is. The location of the NAT device is important in that the keepalives 153 need to initiate from the peer "behind" the NAT. 155 To detect NAT between the two hosts, we need to detect if the IP address 156 or the port changes along the path. This is done by sending the hashes 157 of the IP addresses and ports of both IKE peers from each end to the 158 other. If both ends calculate those hashes and get same result they know 159 there is no NAT between. If the hashes do not match, somebody has 160 translated the address or port, meaning that we need to do NAT-Traversal 161 to get IPsec packets through. 163 If the sender of the packet does not know his own IP address (in case of 164 multiple interfaces, and the implementation does not know which IP 165 address is used to route the packet out), the sender can include 166 multiple local hashes to the packet (as separate NAT-D payloads). In 167 this case, NAT is detected if and only if none of the hashes match. 169 The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 170 payload contains one hash, so in case of multiple hashes, multiple NAT-D 171 payloads are sent. In the normal case there are only two NAT-D payloads. 173 The NAT-D payloads are included in the third and fourth packet of Main 174 Mode, and in second and third packet in the Aggressive Mode. 176 The format of the NAT-D packet is 178 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 179 +---------------+---------------+---------------+---------------+ 180 | Next Payload | RESERVED | Payload length | 181 +---------------+---------------+---------------+---------------+ 182 ~ HASH of the address and port ~ 183 +---------------+---------------+---------------+---------------+ 185 The payload type for the NAT discovery payload is 15. 187 The HASH is calculated as follows: 189 HASH = HASH(CKY-I | CKY-R | IP | Port) 191 using the negotiated HASH algorithm. All data inside the HASH is in the 192 network byte-order. The IP is 4 octets for an IPv4 address and 16 octets 193 for an IPv6 address. The port number is encoded as a 2 octet number in 194 network byte-order. The first NAT-D payload contains the remote end's IP 195 address and port (i.e. the destination address of the UDP packet). The 196 remaining NAT-D payloads contain possible local end IP addresses and 197 ports (i.e. all possible source addresses of the UDP packet). 199 If there is no NAT between the peers, the first NAT-D payload received 200 should match one of the local NAT-D payloads (i.e. the local NAT-D 201 payloads this host is sending out), and one of the other NAT-D payloads 202 must match the remote end's IP address and port. If the first check 203 fails (i.e. first NAT-D payload does not match any of the local IP 204 addresses and ports), then it means that there is dynamic NAT between 205 the peers, and this end should start sending keepalives as defined in 206 the [Hutt03] (this end is behind the NAT). 208 The CKY-I and CKY-R are the initiator and responder cookies. They are 209 added to the hash to make precomputation attacks for the IP address and 210 port impossible. 212 An example of a Phase 1 exchange using NAT-Traversal in Main Mode 213 (authentication with signatures) is: 215 Initiator Responder 216 ------------ ------------ 217 HDR, SA, VID --> 218 <-- HDR, SA, VID 219 HDR, KE, Ni, NAT-D, NAT-D --> 220 <-- HDR, KE, Nr, NAT-D, NAT-D 221 HDR*#, IDii, [CERT, ] SIG_I --> 222 <-- HDR*#, IDir, [ CERT, ], SIG_R 224 An example of Phase 1 exchange using NAT-Traversal in Aggressive Mode 225 (authentication with signatures) is: 227 Initiator Responder 228 ------------ ------------ 229 HDR, SA, KE, Ni, IDii, VID --> 230 <-- HDR, SA, KE, Nr, IDir, 231 [CERT, ], VID, NAT-D, 232 NAT-D, SIG_R 233 HDR*#, [CERT, ], NAT-D, NAT-D, 234 SIG_I --> 236 The '#' sign identifies that those packets are sent to the changed port 237 if NAT is detected. 239 4. Changing to new ports 241 IPsec-aware NATs can cause problems (See [Aboba03] section 2.3). Some 242 NATs will not change IKE source port 500 even if there are multiple 243 clients behind the NAT (See [Aboba03] section 2.3, case n). They can 244 also use IKE cookies to demultiplex traffic instead of using the source 245 port (See [Aboba03] section 2.3, case m). Both of these are problematic 246 for generic NAT transparency since it is difficult for IKE to discover 247 the capabilities of the NAT. The best approach is to simply move the IKE 248 traffic off port 500 as soon as possible to avoid any IPsec-aware NAT 249 special casing. 251 Take the common case of the initiator behind the NAT. The initiator must 252 quickly change to port 4500 once the NAT has been detected to minimize 253 the window of IPsec-aware NAT problems. 255 In Main Mode, the initiator MUST change ports when sending the ID 256 payload if there is NAT between the hosts. The initiator MUST set both 257 UDP source and destination ports to 4500. All subsequent packets sent to 258 this peer (including informational notifications) MUST be sent on port 259 4500. In addition, the IKE data MUST be prepended with a non-ESP marker 260 allowing for demultiplexing of traffic as defined in [Hutt03]. 262 Thus, the IKE packet now looks like: 264 IP UDP(4500,4500) HDR*, IDii, [CERT, ] SIG_I 266 assuming authentication using signatures. The 4 bytes of non-ESP marker 267 is defined in the [Hutt03]. 269 When the responder gets this packet, the usual decryption and processing 270 of the various payloads is performed. If this is successful, the 271 responder MUST update local state so that all subsequent packets 272 (including informational notifications) to the peer use the new port, 273 and possibly the new IP address obtained from the incoming valid packet. 274 The port will generally be different since the NAT will map UDP(500,500) 275 to UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will 276 seldom be different from the pre-changed IP address. The responder MUST 277 respond with all subsequent IKE packets to this peer using UDP(4500,Y). 279 Similarly, if the responder needs to rekey the Phase 1 SA, then the 280 rekey negotiation MUST be started using UDP(4500,Y). Any implementation 281 that supports NAT traversal MUST support negotiations that begin on port 282 4500. If a negotiation starts on port 4500, then it doesn't need to 283 change anywhere else in the exchange. 285 Once port change has occurred, if a packet is received on port 500, that 286 packet is old. If the packet is an informational packet, it MAY be 287 processed if local policy allows. If the packet is a Main Mode or 288 Aggressive Mode packet (with same cookies than previous packets), it 289 SHOULD be discarded. If the packet is new Main Mode or Aggressive 290 exchange then it is processed normally (the other end might have 291 rebooted, and this is starting new exchange). 293 Here is an example of a Phase 1 exchange using NAT-Traversal in Main 294 Mode (authentication with signatures) with changing port: 296 Initiator Responder 297 ------------ ------------ 298 UDP(500,500) HDR, SA, VID --> 299 <-- UDP(500,X) HDR, SA, VID 300 UDP(500,500) HDR, KE, Ni, 301 NAT-D, NAT-D --> 302 <-- UDP(500,X) HDR, KE, Nr, 303 NAT-D, NAT-D 304 UDP(4500,4500) HDR*#, IDii, 305 [CERT, ]SIG_I --> 306 <-- UDP(4500,Y) HDR*#, IDir, 307 [ CERT, ], SIG_R 309 The procedure for Aggressive Mode is very similar. After the NAT has 310 been detected, the initiator sends: IP UDP(4500,4500) <4 bytes of non- 311 ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I. The responder does 312 similar processing to the above, and if successful, MUST update it's 313 internal IKE ports. The responder MUST respond with all subsequent IKE 314 packets to this peer using UDP(4500,Y). 316 Initiator Responder 317 ------------ ------------ 319 UDP(500,500) HDR, SA, KE, 320 Ni, IDii, VID --> 321 <-- UDP(500,X) HDR, SA, KE, 322 Nr, IDir, [CERT, ], 323 VID, NAT-D, NAT-D, 324 SIG_R 325 UDP(4500,4500) HDR*#, [CERT, ], 326 NAT-D, NAT-D, 327 SIG_I --> 329 <-- UDP(4500, Y) HDR*#, ... 331 If the support of the NAT-Traversal is enabled the port in the ID 332 payload in Main Mode/Aggressive Mode MUST be set to 0. 334 The most common case for the responder behind the NAT is if the NAT is 335 simply doing 1-1 address translation. In this case, the initiator still 336 changes both ports to 4500. The responder uses the identical algorithm 337 as above, although in this case Y will equal 4500, since no port 338 translation is happening. 340 A different port change case involves out-of-band discovery of the ports 341 to use. Those discovery methods are out of scope of this document. For 342 instance, if the responder is behind a port translating NAT, and the 343 initiator needs to contact it first, then the initiator will need to 344 determine which ports to use, usually by contacting some other server. 345 Once the initiator knows which ports to use to traverse the NAT, 346 generally something like UDP(Z,4500), it initiates using these ports. 347 This is similar to the responder rekey case above in that the ports to 348 use are already known upfront, and no additional change need take place. 349 Also, the first keepalive timer starts after the change to the new port, 350 no keepalives are sent to the port 500. 352 5. Quick Mode 354 After the Phase 1 both ends know if there is a NAT present between them. 355 The final decision of using NAT-Traversal is left to Quick Mode. The 356 use of NAT-Traversal is negotiated inside the SA payloads of Quick Mode. 357 In Quick Mode, both ends can also send the original addresses of the 358 IPsec packets (in case of the transport mode) to the other end, so the 359 other end has possibility to fix the TCP/IP checksum field after the NAT 360 transform. 362 5.1. Negotiation of the NAT-Traversal encapsulation 364 The negotiation of the NAT-Traversal happens by adding two new 365 encapsulation modes. These encapsulation modes are: 367 UDP-Encapsulated-Tunnel 3 368 UDP-Encapsulated-Transport 4 370 It is not normally useful to propose both normal tunnel or transport 371 mode and UDP-Encapsulated modes. UDP encapsulation is required to fix 372 the inability to handle non-UDP/TCP traffic by NATs (See [Aboba03] 373 section 2.2, case i). 375 If there is a NAT box between hosts, normal tunnel or transport 376 encapsulations may not work and in that case UDP-Encapsulation SHOULD be 377 used. 379 If there is no NAT box between, there is no point of wasting bandwidth 380 by adding UDP encapsulation of packets, thus UDP-Encapsulation SHOULD 381 NOT be used. 383 Also, the initiator SHOULD NOT include both normal tunnel or transport 384 mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport in its 385 proposals. 387 5.2. Sending the original source and destination addresses 389 In order to perform incremental TCP checksum updates, both peers may 390 need to know the original IP addresses used by their peer when that peer 391 constructed the packet (See [Aboba03] section 2.1, case b). For the 392 initiator, the original Initiator address is defined to be the 393 Initiator's IP address. The original Responder address is defined to be 394 the perceived peer's IP address. For the responder, the original 395 Initiator address is defined to be the perceived peer's address. The 396 original Responder address is defined to be the Responder's IP address. 398 The original addresses are sent using NAT-OA (NAT Original Address) 399 payloads. 401 The Initiator NAT-OA payload is first. The Responder NAT-OA payload is 402 second. 404 Example 1: 406 Initiator <---------> NAT <---------> Responder 407 ^ ^ ^ 408 Iaddr NatPub Raddr 410 The initiator is behind a NAT talking to the publicly available 411 responder. Initiator and Responder have IP addresses Iaddr, and Raddr. 412 NAT has public IP address NatPub. 414 Initiator: 416 NAT-OAi = Iaddr 417 NAT-OAr = Raddr 419 Responder: 420 NAT-OAi = NATPub 421 NAT-OAr = Raddr 423 Example 2: 425 Initiator <------> NAT1 <---------> NAT2 <-------> Responder 426 ^ ^ ^ ^ 427 Iaddr Nat1Pub Nat2Pub Raddr 429 Here, NAT2 "publishes" Nat2Pub for Responder and forwards all traffic to 430 that address to Responder. 432 Initiator: 433 NAT-OAi = Iaddr 434 NAT-OAr = Nat2Pub 436 Responder: 437 NAT-OAi = Nat1Pub 438 NAT-OAr = Raddr 440 In case of transport mode both ends MUST send the both original 441 Initiator and Responder addresses to the other end. For tunnel mode both 442 ends SHOULD NOT send original addresses to the other end. 444 The NAT-OA payloads are sent inside the first and second packets of 445 Quick Mode. The initiator MUST send the payloads if it proposes any UDP- 446 Encapsulated-Transport mode and the responder MUST send the payload only 447 if it selected UDP-Encapsulated-Transport mode, i.e. it is possible that 448 the initiator sends the NAT-OA payload, but proposes both UDP- 449 Encapsulated transport and tunnel mode. Then the responder selects the 450 UDP-Encapsulated tunnel mode and does not send the NAT-OA payload back. 452 The format of the NAT-OA packet is 454 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 455 +---------------+---------------+---------------+---------------+ 456 | Next Payload | RESERVED | Payload length | 457 +---------------+---------------+---------------+---------------+ 458 | ID Type | RESERVED | RESERVED | 459 +---------------+---------------+---------------+---------------+ 460 | IPv4 (4 octets) or IPv6 address (16 octets) | 461 +---------------+---------------+---------------+---------------+ 463 The payload type for the NAT original address payload is 16. 465 The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 466 ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 467 Type must be zero. 469 An example of Quick Mode using NAT-OA payloads is: 471 Initiator Responder 472 ------------ ------------ 473 HDR*, HASH(1), SA, Ni, [, KE] 474 [, IDci, IDcr ] 475 [, NAT-OAi, NAT-OAr] --> 476 <-- HDR*, HASH(2), SA, Nr, [, KE] 477 [, IDci, IDcr ] 478 [, NAT-OAi, NAT-OAr] 479 HDR*, HASH(3) 481 6. Initial contact notifications 483 The source IP and port address of the INITIAL-CONTACT notification for 484 the host behind NAT are not meaningful (NAT can change them), so the IP 485 and port numbers MUST NOT be used for determining which IKE/IPsec SAs to 486 remove (See [Aboba03] section 2.1, case c). The ID payload sent from the 487 other end SHOULD be used instead, i.e. when an INITIAL-CONTACT 488 notification is received from the other end, the receiving end SHOULD 489 remove all the SAs associated with the same ID payload. 491 7. Recovering from the expiring NAT mappings 493 There are cases where NAT box decides to remove mappings that are still 494 alive (for example, the keepalive interval is too long, or the NAT box 495 is rebooted). To recover from this, ends which are NOT behind NAT SHOULD 496 use the last valid authenticated packet from the other end to determine 497 which IP and port addresses should be used. The host behind dynamic NAT 498 MUST NOT do this as otherwise it opens a DoS attack possibility, and 499 there is no need for that, because the IP address or port of the other 500 host will not change (it is not behind NAT). 502 Keepalives cannot be used for this purposes as they are not 503 authenticated, but any IKE authenticated IKE packet or ESP packet can be 504 used to detect that the IP address or the port has changed. 506 8. Security Considerations 508 Whenever changes to some fundamental parts of a security protocol are 509 proposed, the examination of security implications cannot be skipped. 510 Therefore, here are some observations on the effects, and whether or not 511 these effects matter. 513 o IKE probes reveal NAT-Traversal support to anyone watching the 514 traffic. Disclosure that NAT-Traversal is supported does not 515 introduce new vulnerabilities. 517 o The value of authentication mechanisms based on IP addresses 518 disappears once NATs are in the picture. That is not necessarily a 519 bad thing (for any real security, authentication measures other than 520 IP addresses should be used). This means that authentication using 521 pre-shared-keys cannot be used in Main Mode without using group 522 shared keys for everybody behind the NAT box. Using group shared keys 523 is huge risk because it allows anyone in the group to authenticate to 524 any other party and claim to be anybody in the group, i.e. a normal 525 user could be impersonating a vpn-gateway, and acting as a man in the 526 middle, and read/modify all traffic to/from others in the group. Use 527 of group shared keys is NOT RECOMMENDED. 529 o As the internal address space is only 32 bits, and it is usually very 530 sparse, it might be possible for the attacker to find out the 531 internal address used behind the NAT box by trying all possible IP- 532 addresses and trying to find the matching hash. The port numbers are 533 normally fixed to 500, and the cookies can be extracted from the 534 packet. This limits the hash calculations down to 2^32. If an 535 educated guess of the private address space is done, then the number 536 of hash calculations needed to find out the internal IP address goes 537 down to 2^24 + 2 * (2^16). 539 o Neither NAT-D payloads or Vendor ID payloads are authenticated at all 540 in Main Mode nor in Aggressive Mode. This means that attacker can 541 remove those payloads, modify them or add them. By removing or adding 542 them, the attacker can cause Denial Of Service attacks. By modifying 543 the NAT-D packets the attacker can cause both ends to use UDP- 544 Encapsulated modes instead of directly using tunnel or transport 545 mode, thus wasting some bandwidth. 547 o The sending of the original source address in the Quick Mode reveals 548 the internal IP address behind the NAT to the other end. In this case 549 we have already authenticated the other end, and sending of the 550 original source address is only needed in transport mode. 552 o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports 553 for each valid authenticated packet can cause DoS in the case where 554 we have an attacker who can listen to all traffic in the network, and 555 can change the order of the packets and inject new packets before the 556 packet he has already seen, i.e. the attacker can take an 557 authenticated packet from the host behind NAT, change the packet UDP 558 source or destination ports or IP addresses and sent it out to the 559 other end before the real packet reaches there. The host not behind 560 the NAT will update its IP address and port mapping and sends further 561 traffic to the wrong host or port. This situation is fixed 562 immediately when the attacker stops modifying the packets as the 563 first real packet will fix the situation back to normal. 564 Implementations SHOULD AUDIT the event every time the mapping is 565 changed, as in the normal case it should not happen that often. 567 9. IANA Considerations 569 This documents contains two new "magic numbers" which are allocated from 570 the existing IANA registry for IPsec. This document also renames 571 existing registered port 4500. This document also defines 2 new payload 572 types for IKE, and there is no registry for those in the IANA. 574 New items to be added in the "Internet Security Association and Key 575 Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry: 577 Name Value Reference 578 ---- ----- --------- 579 UDP-Encapsulated-Tunnel 3 [RFC XXXX] 580 UDP-Encapsulated-Transport 4 [RFC XXXX] 582 Change in the registered port registry: 584 Keyword Decimal Description Reference 585 ------- ------- ----------- --------- 586 ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX] 587 ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC XXXX] 589 New IKE payload numbers are (There is no IANA registry related to this, 590 and no need to create new one, but if one is added these should be added 591 to there): 593 NAT-D 15 NAT Discovery Payload 594 NAT-OA 16 NAT Original Address Payload 596 10. Intellectual property rights 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in this 601 document or the extent to which any license under such rights might or 602 might not be available; nor does it represent that it has made any 603 independent effort to identify any such rights. Information on the 604 IETF's procedures with respect to rights in IETF Documents can be found 605 in RFC XX and RFC XY. [note to RFC Editor - replace XX with the number 606 of IETF IPR and replace XY with number of IETF SUB.] 608 Copies of IPR disclosures made to the IETF Secretariat and any 609 assurances of licenses to be made available, or the result of an attempt 610 made to obtain a general license or permission for the use of such 611 proprietary rights by implementers or users of this specification can be 612 obtained from the IETF on-line IPR repository at 613 http://www.ietf.org/ipr. 615 The IETF invites any interested party to bring to its attention any 616 copyrights, patents or patent applications, or other proprietary rights 617 that may cover technology that may be required to implement this 618 standard. Please address the information to the IETF at ietf- 619 ipr@ietf.org. 621 11. Acknowledgments 623 Thanks to Markus Stenberg, Larry DiBurro and William Dixon who 624 contributed actively to this document. 626 Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 627 contributed to the document used as the base for this document. 629 12. Normative References 631 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 632 November 1998 634 [RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 635 for ISAKMP", November 1998 637 [Hutt03] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 638 draft-ietf-ipsec-udp-encaps-06.txt, January 2003 640 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 641 Requirement Levels", March 1997 643 [IETF SUB] Bradner, S., "IETF Rights in Contributions", draft-ietf-ipr- 644 submission-rights-08.txt, October 2003 646 [IETF IPR] Bradner, S., "Intellectual Property Rights in IETF 647 Technology", draft-ietf-ipr-technology-rights-12.txt, October 2003 649 13. Non-Normative References 651 [Aboba03] Aboba, B. et. al., "IPsec-NAT Compatibility Requirements", 652 draft-ietf-ipsec-nat-reqts-06.txt, October 2003. 654 14. Authors' Addresses 656 Tero Kivinen 657 SafeNet, Inc. 658 Fredrikinkatu 47 659 FIN-00100 HELSINKI 660 Finland 661 E-mail: kivinen@safenet-inc.com 663 Ari Huttunen 664 F-Secure Corporation 665 Tammasaarenkatu 7, 666 FIN-00181 HELSINKI 667 Finland 668 E-mail: Ari.Huttunen@F-Secure.com 670 Brian Swander 671 Microsoft 672 One Microsoft Way 673 Redmond WA 98052 674 E-mail: briansw@microsoft.com 676 Victor Volpe 677 Cisco Systems 678 124 Grove Street 679 Suite 205 680 Franklin, MA 02038 681 E-mail: vvolpe@cisco.com 683 15. Full copyright statement 685 Copyright (C) The Internet Society (year). This document is subject to 686 the rights, licenses and restrictions contained in RFC XXXX and except 687 as set forth therein, the authors retain all their rights. 689 [Note to the RFC Editor - XXXX above to be replaced with the number of 690 [IETF SUB]] 692 This document and the information contained herein are provided on an 693 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS 694 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 695 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 696 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 697 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 698 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.