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