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