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