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