idnits 2.17.1 draft-ietf-ipsec-nat-t-ike-06.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (28 May 2003) is 7639 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 557, but not defined ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'Hutt03' == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-nat-reqts-04 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-ipsec-nat-t-ike-06.txt B. Swander 4 Expires: 28 November 2003 Microsoft 5 A. Huttunen 6 F-Secure Corporation 7 V. Volpe 8 Cisco Systems 9 28 May 2003 11 Negotiation of NAT-Traversal in the IKE 13 Status of This Memo 15 This document is a submission to the IETF IP Security Protocol 16 (IPSEC) Working Group. Comments are solicited and should be 17 addressed to the working group mailing list (ipsec@lists.tislabs.com) 18 or to the editor. 20 This document is an Internet-Draft and is in full conformance 21 with all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as 32 "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes how to detect one or more network address trans- 43 lation devices (NATs) between IPsec hosts, and how to negotiate the use 44 of UDP encapsulation of the IPsec packets through the NAT boxes in 45 Internet Key Exchange (IKE). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 51 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3 53 3.2. Detecting presence of NAT . . . . . . . . . . . . . . . . . 3 54 4. Changing to the new ports . . . . . . . . . . . . . . . . . . . 5 55 5. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 7 57 5.2. Sending the original source and destination addresses . . . 8 58 6. Initial contact notifications . . . . . . . . . . . . . . . . . 9 59 7. Recovering from the expiring NAT mappings . . . . . . . . . . . 9 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 62 10. Intellectual property rights . . . . . . . . . . . . . . . . . 11 63 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 64 12. Normative References . . . . . . . . . . . . . . . . . . . . . 12 65 13. Non-Normative References . . . . . . . . . . . . . . . . . . . 12 66 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 This document is split in two parts. The first part describes what is 71 needed in the IKE phase 1 for the NAT-Traversal support. This includes 72 detecting if the other end supports NAT-Traversal, and detecting if 73 there is one or more NAT along the path from host to host. 75 The second part describes how to negotiate the use of UDP encapsulated 76 IPsec packets in the IKE Quick Mode. It also describes how to transmit 77 the original source and destination addresses to the other end if 78 needed. The original source and destination addresses are used in 79 transport mode to incrementally update the TCP/IP checksums so that they 80 will match after the NAT transform (The NAT cannot do this, because the 81 TCP/IP checksum is inside the UDP encapsulated IPsec packet). 83 The document [Hutt03] describes the details of the UDP encapsulation and 84 [Aboba03] provides background information and motivation of the NAT- 85 Traversal in general. This document in combination with [Hutt03] 86 represent an "unconditionally compliant" solution to the requirements as 87 defined by [Aboba03]. 89 2. Specification of Requirements 91 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 92 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 93 "OPTIONAL" to describe requirements. They are to be interpreted as 94 described in [RFC-2119] document. 96 3. Phase 1 97 The detection of the support for the NAT-Traversal and detection of the 98 NAT along the path happens in the IKE [RFC-2409] phase 1. 99 The NAT may change the IKE UDP source port, and recipients MUST be able 100 to process IKE packets whose source port is different than 500. There 101 are cases where the NAT does not have to change the source port: 103 o only one IPsec host behind the NAT 105 o for the first IPsec host the NAT can keep the port 500, and change 106 only specified IPsec host IP addresses 108 Recipients MUST reply back to the source address from the packet. This 109 also means that when the original responder is doing rekeying, or 110 sending notifications etc. to the original initiator it MUST send the 111 packets from the same set of port and IP numbers that was used when the 112 IKE SA was last time used (i.e the source and destination port and IP 113 numbers must be same). 115 For example, when the initiator sends a packet having source and 116 destination port 500, the NAT may change that to a packet which has 117 source port 12312 and destination port 500. The responder must be able 118 to process the packet whose source port is that 12312. It must reply 119 back with a packet whose source port is 500 and destination port 12312. 120 The NAT will then translate this packet to have source port 500 and 121 destination port 500. 123 3.1. Detecting support of Nat-Traversal 125 The NAT-Traversal capability of the remote host is determined by an 126 exchange of vendor strings; in Phase 1 two first messages, the vendor id 127 payload for this specification of NAT-Traversal (MD5 hash of "RFC XXXX" 128 - ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if supported 129 (and it MUST be received by both sides) for the NAT-Traversal probe to 130 continue. 132 3.2. Detecting presence of NAT 134 The purpose of the NAT-D payload is twofold, It not only detects the 135 presence of NAT between two IKE peers, it also detects where the NAT is. 136 The location of the NAT device is important in that the keepalives need 137 to initiate from the peer "behind" the NAT. 139 To detect the NAT between the two hosts, we need to detect if the IP 140 address or the port changes along the path. This is done by sending the 141 hashes of IP address and port of both source and destination addresses 142 from each end to another. When both ends calculate those hashes and get 143 same result they know there is no NAT between. If the hashes do not 144 match, somebody translated the address or port between, meaning we need 145 to do NAT-Traversal to get IPsec packet through. 147 If the sender of the packet does not know his own IP address (in case of 148 multiple interfaces, and implementation don't know which is used to 149 route the packet out), he can include multiple local hashes to the 150 packet (as separate NAT-D payloads). In this case the NAT is detected if 151 and only if none of the hashes match. 153 The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 154 payload contains one hash, so in case of multiple hashes, multiple NAT-D 155 payloads are sent. In normal case there is only two NAT-D payloads. 157 The NAT-D payloads are included in the third and fourth packet in the 158 main mode and second and third packet in the aggressive mode. 160 The format of the NAT-D packet is 162 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 163 +---------------+---------------+---------------+---------------+ 164 | Next Payload | RESERVED | Payload length | 165 +---------------+---------------+---------------+---------------+ 166 ~ HASH of the address and port ~ 167 +---------------+---------------+---------------+---------------+ 169 The payload type for the NAT discovery payload is 15. 171 The HASH is calculated as follows: 173 HASH = HASH(CKY-I | CKY-R | IP | Port) 175 using the negotiated HASH algorithm. All data inside the HASH is in the 176 network byte-order. The IP is 4 octets for the IPv4 address and 16 177 octets for the IPv6 address. The port number is encoded as 2 octet 178 number in network byte-order. The first NAT-D payload contains the 179 remote ends IP address and port (i.e the destination address of the UDP 180 packet). The rest of the NAT-D payloads contain possible local end IP 181 addresses and ports (i.e all possible source addresses of the UDP 182 packet). 184 If there is no NAT between then the first NAT-D payload received should 185 match one of the local NAT-D payloads (i.e local NAT-D payloads this 186 host is sending out), and the one of the other NAT-D payloads must match 187 the remote ends IP address and port. If the first check fails (i.e first 188 NAT-D payload does not match any of the local IP addresses and ports), 189 then it means that there is dynamic NAT between, and this end should 190 start sending keepalives as defined in the [Hutt03]. 192 The CKY-I and CKY-R are the initiator and responder cookies, and they 193 are added to the hash to make precomputation attacks for the IP address 194 and port impossible. 196 An example of phase 1 exchange using NAT-Traversal in main mode 197 (authentication with signatures) is: 199 Initiator Responder 200 ------------ ------------ 201 HDR, SA, VID --> 202 <-- HDR, SA, VID 204 HDR, KE, Ni, NAT-D, NAT-D --> 205 <-- HDR, KE, Nr, NAT-D, NAT-D 206 HDR*#, IDii, [CERT, ] SIG_I --> 207 <-- HDR*#, IDir, [ CERT, ], SIG_R 209 An example of phase 1 exchange using NAT-Traversal in aggressive mode 210 (authentication with signatures) is: 212 Initiator Responder 213 ------------ ------------ 214 HDR, SA, KE, Ni, IDii, VID --> 215 <-- HDR, SA, KE, Nr, IDir, 216 [CERT, ], VID, NAT-D, 217 NAT-D, SIG_R 218 HDR*#, [CERT, ], NAT-D, NAT-D, 219 SIG_I --> 221 The '#' sign identifies that those packets are sent to the changed port 222 if NAT is detected. 224 4. Changing to the new ports 226 IPsec-aware NATs can cause problems. Some NATs will not change IKE 227 source port 500 even if there are multiple clients behind the NAT. They 228 can also map IKE cookies to demultiplex traffic instead of using the 229 source port. Both of these are problematic for generic NAT transparency 230 since it is difficult for IKE to discover the capabilities of the NAT. 231 The best approach is to simply move the IKE traffic off port 500 as soon 232 as possible to avoid any IPsec-aware NAT special casing. 234 Take the common case of the initiator behind the NAT. The initiator must 235 quickly change to 4500 once the NAT has been detected to minimize the 236 window of IPsec-aware NAT problems. 238 In main mode, the initiator MUST change ports when sending the ID 239 payload if there is NAT between the hosts. The initiator MUST set both 240 UDP source and destination ports to 4500. All subsequent packets sent to 241 this peer (including informational notifications) MUST be sent on 4500. 242 In addition, the IKE data MUST be prepended with a non-ESP marker 243 allowing for demultiplexing of traffic as defined in [Hutt03]. 245 Thus, the IKE packet now looks like: 247 IP UDP(4500,4500) HDR*, IDii, [CERT, ] SIG_I 249 assuming authentication using signatures. The 4 bytes of non-ESP marker 250 is defined in the [Hutt03]. 252 When the responder gets this packet he performs the usual decryption and 253 processing of the various payloads. If this is successful, he MUST 254 update local state so that all subsequent packets (including 255 informational notifications) to the peer use the new port, and possibly 256 new IP address obtained from the incoming valid packet. The port will 257 generally be different since the NAT will map UDP(500,500) to 258 UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will 259 seldom be different from the pre-change IP address. The responder MUST 260 respond with all subsequent IKE packets to this peer using UDP(4500,Y). 262 Similarly, if the responder needs to rekey the phase 1 SA, then he MUST 263 start the negotiation using UDP(4500,Y). Any implementation that 264 supports NAT traversal, MUST support negotiations that begin on port 265 4500. If a negotiation starts on 4500, then it doesn't need to change 266 anywhere else in the exchange. 268 Once port change has occurred, if a packet is received on 500, that 269 packet is old. If the packet is an informational, it MAY be processed if 270 local policy allows. If the packet is a main mode or aggressive mode 271 packet, it SHOULD be discarded. 273 Here is an example of phase 1 exchange using NAT-Traversal in main mode 274 (authentication with signatures) with changing port: 276 Initiator Responder 277 ------------ ------------ 278 UDP(500,500) HDR, SA, VID --> 279 <-- UDP(500,X) HDR, SA, VID 280 UDP(500,500) HDR, KE, Ni, 281 NAT-D, NAT-D --> 282 <-- UDP(500,X) HDR, KE, Nr, 283 NAT-D, NAT-D 284 UDP(4500,4500) HDR*#, IDii, 285 [CERT, ]SIG_I --> 286 <-- UDP(4500,Y) HDR*#, IDir, 287 [ CERT, ], SIG_R 289 The algorithm for aggressive mode is very similar. After the NAT has 290 been detected, the initiator sends: IP UDP(4500,4500) <4 bytes of non- 291 ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I The responder does 292 similar processing to the above, and if successful, MUST update his 293 internal IKE ports. The responder MUST respond with all subsequent IKE 294 packets to this peer using UDP(4500,Y). 296 Initiator Responder 297 ------------ ------------ 299 UDP(500,500) HDR, SA, KE, 300 Ni, IDii, VID --> 301 <-- UDP(500,X) HDR, SA, KE, 302 Nr, IDir, [CERT, ], 303 VID, NAT-D, NAT-D, 304 SIG_R 305 UDP(4500,4500) HDR*#, [CERT, ], 306 NAT-D, NAT-D, 307 SIG_I --> 309 <-- UDP(4500, Y) HDR*#, ... 311 While changing ports, the port in the ID payload in Main Mode/Aggressive 312 Mode MUST be 0. 314 The most common case for the responder behind the NAT is if the NAT is 315 simply doing 1-1 address translation. In this case, the initiator still 316 changes both ports to 4500. The responder uses the identical algorithm 317 as above, although in this case, Y will equal 4500, since no port 318 translation is happening. 320 A different port change case involves out-of-band discovery of the ports 321 to use. For instance, if the responder is behind a port translating NAT, 322 and the initiator needs to contact it first, then the initiator will 323 need to determine which ports to use, usually by contacting some other 324 server. Once the initiator knows which ports to use to traverse the NAT, 325 generally something like UDP(Z,4500), he initiates using these ports. 326 This is similar to the responder rekey case above in that the ports to 327 use are already known upfront, and no additional change need take place. 329 Also the first keepalive timer starts after change to new port, no 330 keepalives are sent to the port 500. 332 5. Quick Mode 334 After the Phase 1 both ends know if there is a NAT present between. The 335 final decision of using the NAT-Traversal is left to the quick mode. The 336 use of NAT-Traversal is negotiated inside the SA payloads of the quick 337 mode. In the quick mode both ends can also send the original addresses 338 of the IPsec packets (in case of the transport mode) to the other, end 339 so the other end has possibility to fix the TCP/IP checksum field after 340 the NAT transform. 342 5.1. Negotiation of the NAT-Traversal encapsulation 344 The negotiation of the NAT-Traversal happens by adding two new 345 encapsulation modes. These encapsulation modes are: 347 UDP-Encapsulated-Tunnel 3 348 UDP-Encapsulated-Transport 4 350 It is not normally useful to propose both normal tunnel or transport 351 mode and UDP-Encapsulated modes. 353 If there is a NAT box between normal tunnel or transport encapsulations 354 may not work and in that case UDP-Encapsulation SHOULD be used. 356 If there is no NAT box between, there is no point of wasting bandwidth 357 by adding UDP encapsulation of packets, thus UDP-Encapsulation SHOULD 358 NOT be used. 360 Also initiator SHOULD NOT include both normal tunnel or transport mode 361 and UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport in its 362 proposals. 364 5.2. Sending the original source and destination addresses 366 In order to perform incremental TCP checksum fix ups, both peers may 367 need to know the original IP addresses used by their peer when that peer 368 constructed the packet. On the initiator, the original Initiator address 369 is defined to be the Initiator's IP address. The original Responder 370 address is defined to be the perceived peer's IP address. On the 371 responder, the original Initiator address is defined to be the perceived 372 peer's address. The original Responder address is defined to be the 373 Responder's IP address. 375 The original addresses are sent using NAT-OA (NAT Original Address) 376 payloads. 378 The Initiator NAT-OA payload is first. The Responder NAT-OA payload is 379 second. 381 Example 1: 383 Initiator <---------> NAT <---------> Responder 384 ^ ^ ^ 385 Iaddr NatPub Raddr 387 The initiator is behind a NAT talking to the publicly available 388 responder. Initiator and Responder have IP addresses Iaddr, and Raddr. 389 NAT has public IP address NatPub. 391 Initiator: 392 NAT-OAi = Iaddr 393 NAT-OAr = Raddr 395 Responder: 396 NAT-OAi = NATPub 397 NAT-OAr = Raddr 399 Example 2: 401 Initiator <------> NAT1 <---------> NAT2 <-------> Responder 402 ^ ^ ^ ^ 403 Iaddr Nat1Pub Nat2Pub Raddr 405 Here, NAT2 "publishes" Nat2Pub for Responder and forwards all traffic to 406 that address to Responder. 408 Initiator: 409 NAT-OAi = Iaddr 410 NAT-OAr = Nat2Pub 412 Responder: 413 NAT-OAi = Nat1Pub 414 NAT-OAr = Raddr 416 In case of transport mode both ends MUST send the both original 417 Initiator and Responder addresses to the other end. For the tunnel mode 418 both ends SHOULD NOT send original addresses to the other end. 420 The NAT-OA payloads are sent inside the first and second packets of the 421 quick mode. The initiator MUST send the payloads if it proposes any UDP- 422 Encapsulated-Transport mode and the responder MUST send the payload only 423 if it selected UDP-Encapsulated-Transport mode. I.e it is possible that 424 the initiator send the NAT-OA payload, but proposes both UDP- 425 Encapsulated transport and tunnel mode. Then the responder selects the 426 UDP-Encapsulated tunnel mode and does not send the NAT-OA payload back. 428 The format of the NAT-OA packet is 430 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 431 +---------------+---------------+---------------+---------------+ 432 | Next Payload | RESERVED | Payload length | 433 +---------------+---------------+---------------+---------------+ 434 | ID Type | RESERVED | RESERVED | 435 +---------------+---------------+---------------+---------------+ 436 | IPv4 (4 octets) or IPv6 address (16 octets) | 437 +---------------+---------------+---------------+---------------+ 439 The payload type for the NAT original address payload is 16. 441 The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 442 ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 443 Type must be zero. 445 An example of quick mode using NAT-OA payloads is: 447 Initiator Responder 448 ------------ ------------ 449 HDR*, HASH(1), SA, Ni, [, KE] 450 [, IDci, IDcr ] 451 [, NAT-OAi, NAT-OAr] --> 452 <-- HDR*, HASH(2), SA, Nr, [, KE] 453 [, IDci, IDcr ] 454 [, NAT-OAi, NAT-OAr] 455 HDR*, HASH(3) 457 6. Initial contact notifications 459 The source IP and port address of the INITIAL-CONTACT notification for 460 the host behind NAT are not meaningful, so the IP and port numbers MUST 461 NOT be used for the determine which IKE/IPsec SAs to remove. The ID 462 payload sent from the other SHOULD be used instead. I.e when INITIAL- 463 CONTACT notification is received from the other end, the receiving end 464 SHOULD remove all the SAs associated with the same ID payload. 466 7. Recovering from the expiring NAT mappings 468 There are cases where NAT box decides to remove mappings that are still 469 alive (for example, the keepalive interval is too long, or the NAT box 470 is rebooted). To recover from those ends which are NOT behind NAT SHOULD 471 use the last valid authenticated packet from the other end to determine 472 which IP and port addresses should be used. The host behind dynamic NAT 473 MUST NOT do this as otherwise it opens DoS attack possibility, and there 474 is no need for that, because the IP address or port of other host will 475 not change (it is not behind NAT). 477 Keepalives cannot be used for this purposes as they are not 478 authenticated, but any IKE authenticated IKE packet or ESP packet can be 479 used to detect that the IP address or the port has changed. 481 8. Security Considerations 483 Whenever changes to some fundamental parts of a security protocol are 484 proposed, the examination of security implications cannot be skipped. 485 Therefore, here are some observations on the effects, and whether or not 486 these effects matter. 488 o IKE probe reveals NAT-Traversal support to everyone. This should not 489 be an issue. 491 o The value of authentication mechanisms based on IP addresses 492 disappears once NATs are in the picture. That is not necessarily a 493 bad thing (for any real security, other authentication measures than 494 IP addresses should be used). This means that pre-shared-keys 495 authentication cannot be used with the main mode without group shared 496 keys for everybody behind the NAT box, which is huge security risk. 497 Use of group shared keys is NOT RECOMMENDED. 499 o As the internal address space is only 32 bits, and it is usually very 500 sparse, it might be possible for the attacker to find out the 501 internal address used behind the NAT box by trying all possible IP- 502 addresses and trying to find the matching hash. The port numbers are 503 normally fixed to 500, and the cookies can be extracted from the 504 packet. This limits the hash calculations down to 2^32. If educated 505 guess of use of private address space is done, then the number of 506 hash calculations needed to find out the internal IP address goes 507 down to the 2^24 + 2 * (2^16). 509 o Neither NAT-D payloads or Vendor ID payloads are authenticated at all 510 in the main mode nor in the aggressive mode. This means that attacker 511 can remove those payloads, modify them or add them. By removing or 512 adding them the attacker can cause Denial Of Service attacks. By 513 modifying the NAT-D packets the attacker can cause both ends to use 514 UDP-Encapsulated modes instead of directly using tunnel or transport 515 mode, thus wasting some bandwidth. 517 o The sending of the original source address in the Quick Mode reveals 518 the internal IP address behind the NAT to the other end. In this case 519 we have already authenticated the other end, and sending of the 520 original source address is only needed in transport mode. 522 o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports 523 for each valid authenticated packet can cause DoS in case we have 524 attacker who can listen all traffic in the network, and can change 525 the order of the packet and inject new packets before the packet he 526 has already seen. I.e attacker can take the authenticated packet from 527 the host behind NAT, change the packet UDP source or destination 528 ports or IP addresses and sent it out to the other end before the 529 real packet reaches there. The host not behind the NAT will update 530 its IP address and port mapping and sends further traffic to wrong 531 host or port. This situation is fixed immediately when the attacker 532 stops modifying the packets as the first real packet will fix the 533 situation back to normal. Implementations SHOULD AUDIT the event 534 every time the mapping is changed, as in normal case it should not 535 happen that often. 537 9. IANA Considerations 539 This documents contains two new "magic numbers" which are allocated from 540 the existing IANA registry for IPsec. This document also renames 541 existing registered port 4500. This document also defines 2 new payload 542 types for IKE, and there is no registry for those in the IANA. 544 New items to be added in the "Internet Security Association and Key 545 Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry: 547 Name Value Reference 548 ---- ----- --------- 549 UDP-Encapsulated-Tunnel 3 [RFC XXXX] 550 UDP-Encapsulated-Transport 4 [RFC XXXX] 552 Change in the registered port registry: 554 Keyword Decimal Description Reference 555 ------- ------- ----------- --------- 556 ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX] 557 ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC XXXX] 559 New IKE payload numbers are (There is no IANA registry related to this, 560 and no need to create new one, but if one is added these should be added 561 to there): 563 NAT-D 15 NAT Discovery Payload 564 NAT-OA 16 NAT Original Address Payload 566 10. Intellectual property rights 568 The IETF has been notified of intellectual property rights claimed in 569 regard to some or all of the specification contained in this document. 570 For more information consult the online list of claimed rights. 572 SSH Communications Security Corp has notified the working group of one 573 or more patents or patent applications that may be relevant to this 574 document. SSH Communications Security Corp has already given a license 575 for those patents to the IETF. For more information consult the online 576 list of claimed rights. 578 11. Acknowledgments 580 Thanks to Markus Stenberg, Larry DiBurro and William Dixon who 581 contributed actively to this document. 583 Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 584 contributed to the document used as base for this document. 586 12. Normative References 588 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 589 November 1998 591 [RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 592 for ISAKMP", November 1998 594 [Hutt03] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 595 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 596 Requirement Levels", March 1997 598 13. Non-Normative References 600 [Aboba03] Aboba, B. et. al., "IPsec-NAT Compatibility Requirements", 601 draft-ietf-ipsec-nat-reqts-04.txt, March 2003. 603 14. Authors' Addresses 605 Tero Kivinen 606 SSH Communications Security Corp 607 Fredrikinkatu 42 608 FIN-00100 HELSINKI 609 Finland 610 E-mail: kivinen@ssh.fi 612 Ari Huttunen 613 F-Secure Corporation 614 Tammasaarenkatu 7, 615 FIN-00181 HELSINKI 616 Finland 617 E-mail: Ari.Huttunen@F-Secure.com 619 Brian Swander 620 Microsoft 621 One Microsoft Way 622 Redmond WA 98052 623 E-mail: briansw@microsoft.com 625 Victor Volpe 626 Cisco Systems 627 124 Grove Street 628 Suite 205 629 Franklin, MA 02038 630 E-mail: vvolpe@cisco.com