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