idnits 2.17.1 draft-ietf-ipsec-nat-t-ike-07.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 (29 Sep 2003) is 7505 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 562, 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-07.txt B. Swander 4 Expires: 29 March 2004 Microsoft 5 A. Huttunen 6 F-Secure Corporation 7 V. Volpe 8 Cisco Systems 9 29 Sep 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 98 The detection of the support for the NAT-Traversal and detection of the 99 NAT along the path happens in the IKE [RFC-2409] phase 1. 100 The NAT may change the IKE UDP source port, and recipients MUST be able 101 to process IKE packets whose source port is different than 500. There 102 are cases where the NAT does not have to change the source port: 104 o only one IPsec host behind the NAT 106 o for the first IPsec host the NAT can keep the port 500, and change 107 only specified IPsec host IP addresses 109 Recipients MUST reply back to the source address from the packet. This 110 also means that when the original responder is doing rekeying, or 111 sending notifications etc. to the original initiator it MUST send the 112 packets from the same set of port and IP numbers that was used when the 113 IKE SA was last time used (i.e the source and destination port and IP 114 numbers must be same). 116 For example, when the initiator sends a packet having source and 117 destination port 500, the NAT may change that to a packet which has 118 source port 12312 and destination port 500. The responder must be able 119 to process the packet whose source port is that 12312. It must reply 120 back with a packet whose source port is 500 and destination port 12312. 121 The NAT will then translate this packet to have source port 500 and 122 destination port 500. 124 3.1. Detecting support of Nat-Traversal 126 The NAT-Traversal capability of the remote host is determined by an 127 exchange of vendor strings; in Phase 1 two first messages, the vendor id 128 payload for this specification of NAT-Traversal (MD5 hash of "RFC XXXX" 129 - ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if supported 130 (and it MUST be received by both sides) for the NAT-Traversal probe to 131 continue. 133 3.2. Detecting presence of NAT 135 The purpose of the NAT-D payload is twofold, It not only detects the 136 presence of NAT between two IKE peers, it also detects where the NAT is. 137 The location of the NAT device is important in that the keepalives need 138 to initiate from the peer "behind" the NAT. 140 To detect the NAT between the two hosts, we need to detect if the IP 141 address or the port changes along the path. This is done by sending the 142 hashes of IP address and port of both source and destination addresses 143 from each end to another. When both ends calculate those hashes and get 144 same result they know there is no NAT between. If the hashes do not 145 match, somebody translated the address or port between, meaning we need 146 to do NAT-Traversal to get IPsec packet through. 148 If the sender of the packet does not know his own IP address (in case of 149 multiple interfaces, and implementation don't know which is used to 150 route the packet out), he can include multiple local hashes to the 151 packet (as separate NAT-D payloads). In this case the NAT is detected if 152 and only if none of the hashes match. 154 The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 155 payload contains one hash, so in case of multiple hashes, multiple NAT-D 156 payloads are sent. In normal case there is only two NAT-D payloads. 158 The NAT-D payloads are included in the third and fourth packet in the 159 main mode and second and third packet in the aggressive mode. 161 The format of the NAT-D packet is 163 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 164 +---------------+---------------+---------------+---------------+ 165 | Next Payload | RESERVED | Payload length | 166 +---------------+---------------+---------------+---------------+ 167 ~ HASH of the address and port ~ 168 +---------------+---------------+---------------+---------------+ 170 The payload type for the NAT discovery payload is 15. 172 The HASH is calculated as follows: 174 HASH = HASH(CKY-I | CKY-R | IP | Port) 176 using the negotiated HASH algorithm. All data inside the HASH is in the 177 network byte-order. The IP is 4 octets for the IPv4 address and 16 178 octets for the IPv6 address. The port number is encoded as 2 octet 179 number in network byte-order. The first NAT-D payload contains the 180 remote ends IP address and port (i.e the destination address of the UDP 181 packet). The rest of the NAT-D payloads contain possible local end IP 182 addresses and ports (i.e all possible source addresses of the UDP 183 packet). 185 If there is no NAT between then the first NAT-D payload received should 186 match one of the local NAT-D payloads (i.e local NAT-D payloads this 187 host is sending out), and the one of the other NAT-D payloads must match 188 the remote ends IP address and port. If the first check fails (i.e first 189 NAT-D payload does not match any of the local IP addresses and ports), 190 then it means that there is dynamic NAT between, and this end should 191 start sending keepalives as defined in the [Hutt03]. 193 The CKY-I and CKY-R are the initiator and responder cookies, and they 194 are added to the hash to make precomputation attacks for the IP address 195 and port impossible. 197 An example of phase 1 exchange using NAT-Traversal in main mode 198 (authentication with signatures) is: 200 Initiator Responder 201 ------------ ------------ 202 HDR, SA, VID --> 203 <-- 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 anyone watching the 489 traffic. Disclosure that NAT-Traversal is supported does not 490 introduce new vulnerabilities. 492 o The value of authentication mechanisms based on IP addresses 493 disappears once NATs are in the picture. That is not necessarily a 494 bad thing (for any real security, other authentication measures than 495 IP addresses should be used). This means that pre-shared-keys 496 authentication cannot be used with the main mode without group shared 497 keys for everybody behind the NAT box. Using group shared keys is 498 huge risk because that would allow any of the group to authenticate 499 to any other party in the group and claim to be anybody in the group. 500 I.e normal user could be impersonating as vpn-gateway, and acting man 501 in the middle, and read/modify all traffic to/from others in the 502 group. Use of group shared keys is NOT RECOMMENDED. 504 o As the internal address space is only 32 bits, and it is usually very 505 sparse, it might be possible for the attacker to find out the 506 internal address used behind the NAT box by trying all possible IP- 507 addresses and trying to find the matching hash. The port numbers are 508 normally fixed to 500, and the cookies can be extracted from the 509 packet. This limits the hash calculations down to 2^32. If educated 510 guess of use of private address space is done, then the number of 511 hash calculations needed to find out the internal IP address goes 512 down to the 2^24 + 2 * (2^16). 514 o Neither NAT-D payloads or Vendor ID payloads are authenticated at all 515 in the main mode nor in the aggressive mode. This means that attacker 516 can remove those payloads, modify them or add them. By removing or 517 adding them the attacker can cause Denial Of Service attacks. By 518 modifying the NAT-D packets the attacker can cause both ends to use 519 UDP-Encapsulated modes instead of directly using tunnel or transport 520 mode, thus wasting some bandwidth. 522 o The sending of the original source address in the Quick Mode reveals 523 the internal IP address behind the NAT to the other end. In this case 524 we have already authenticated the other end, and sending of the 525 original source address is only needed in transport mode. 527 o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports 528 for each valid authenticated packet can cause DoS in case we have 529 attacker who can listen all traffic in the network, and can change 530 the order of the packet and inject new packets before the packet he 531 has already seen. I.e attacker can take the authenticated packet from 532 the host behind NAT, change the packet UDP source or destination 533 ports or IP addresses and sent it out to the other end before the 534 real packet reaches there. The host not behind the NAT will update 535 its IP address and port mapping and sends further traffic to wrong 536 host or port. This situation is fixed immediately when the attacker 537 stops modifying the packets as the first real packet will fix the 538 situation back to normal. Implementations SHOULD AUDIT the event 539 every time the mapping is changed, as in normal case it should not 540 happen that often. 542 9. IANA Considerations 544 This documents contains two new "magic numbers" which are allocated from 545 the existing IANA registry for IPsec. This document also renames 546 existing registered port 4500. This document also defines 2 new payload 547 types for IKE, and there is no registry for those in the IANA. 549 New items to be added in the "Internet Security Association and Key 550 Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry: 552 Name Value Reference 553 ---- ----- --------- 554 UDP-Encapsulated-Tunnel 3 [RFC XXXX] 555 UDP-Encapsulated-Transport 4 [RFC XXXX] 557 Change in the registered port registry: 559 Keyword Decimal Description Reference 560 ------- ------- ----------- --------- 561 ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX] 562 ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC XXXX] 564 New IKE payload numbers are (There is no IANA registry related to this, 565 and no need to create new one, but if one is added these should be added 566 to there): 568 NAT-D 15 NAT Discovery Payload 569 NAT-OA 16 NAT Original Address Payload 571 10. Intellectual property rights 573 The IETF has been notified of intellectual property rights claimed in 574 regard to some or all of the specification contained in this document. 575 For more information consult the online list of claimed rights. 577 11. Acknowledgments 579 Thanks to Markus Stenberg, Larry DiBurro and William Dixon who 580 contributed actively to this document. 582 Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 583 contributed to the document used as base for this document. 585 12. Normative References 587 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 588 November 1998 590 [RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 591 for ISAKMP", November 1998 593 [Hutt03] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 594 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 595 Requirement Levels", March 1997 597 13. Non-Normative References 599 [Aboba03] Aboba, B. et. al., "IPsec-NAT Compatibility Requirements", 600 draft-ietf-ipsec-nat-reqts-04.txt, March 2003. 602 14. Authors' Addresses 604 Tero Kivinen 605 SSH Communications Security Corp 606 Fredrikinkatu 42 607 FIN-00100 HELSINKI 608 Finland 609 E-mail: kivinen@ssh.fi 611 Ari Huttunen 612 F-Secure Corporation 613 Tammasaarenkatu 7, 614 FIN-00181 HELSINKI 615 Finland 616 E-mail: Ari.Huttunen@F-Secure.com 618 Brian Swander 619 Microsoft 620 One Microsoft Way 621 Redmond WA 98052 622 E-mail: briansw@microsoft.com 624 Victor Volpe 625 Cisco Systems 626 124 Grove Street 627 Suite 205 628 Franklin, MA 02038 629 E-mail: vvolpe@cisco.com