1IP Security Protocol Working Group (IPSEC) T. Kivinen 2INTERNET-DRAFT SSH Communications Security 3draft-ietf-ipsec-nat-t-ike-06.txt B. Swander 4Expires: 28 November 2003 Microsoft 5 A. Huttunen 6 F-Secure Corporation 7 V. Volpe 8 Cisco Systems 9 28 May 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 28 May 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 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 [Hutt03] describes the details of the UDP encapsulation and 101[Aboba03] provides background information and motivation of the NAT- 102Traversal in general. This document in combination with [Hutt03] 103represent an "unconditionally compliant" solution to the requirements as 104defined by [Aboba03]. 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 28 May 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 28 May 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 received should 215match one of the local NAT-D payloads (i.e local NAT-D payloads this 216host is sending out), and the one of the other NAT-D payloads must match 217the remote 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 [Hutt03]. 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 28 May 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 [Hutt03]. 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 [Hutt03]. 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 28 May 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 28 May 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 28 May 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 28 May 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 28 May 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 everyone. This should not 553 be an issue. 554 555o The value of authentication mechanisms based on IP addresses 556 disappears once NATs are in the picture. That is not necessarily a 557 bad thing (for any real security, other authentication measures than 558 IP addresses should be used). This means that pre-shared-keys 559 authentication cannot be used with the main mode without group shared 560 keys for everybody behind the NAT box, which is huge security risk. 561 Use of group shared keys is NOT RECOMMENDED. 562 563o As the internal address space is only 32 bits, and it is usually very 564 sparse, it might be possible for the attacker to find out the 565 internal address used behind the NAT box by trying all possible IP- 566 addresses and trying to find the matching hash. The port numbers are 567 normally fixed to 500, and the cookies can be extracted from the 568 packet. This limits the hash calculations down to 2^32. If educated 569 guess of use of private address space is done, then the number of 570 hash calculations needed to find out the internal IP address goes 571 down to the 2^24 + 2 * (2^16). 572 573o Neither NAT-D payloads or Vendor ID payloads are authenticated at all 574 in the main mode nor in the aggressive mode. This means that attacker 575 can remove those payloads, modify them or add them. By removing or 576 adding them the attacker can cause Denial Of Service attacks. By 577 modifying the NAT-D packets the attacker can cause both ends to use 578 UDP-Encapsulated modes instead of directly using tunnel or transport 579 mode, thus wasting some bandwidth. 580 581o The sending of the original source address in the Quick Mode reveals 582 the internal IP address behind the NAT to the other end. In this case 583 we have already authenticated the other end, and sending of the 584 original source address is only needed in transport mode. 585 586o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports 587 588 589T. Kivinen, et. al. [page 10] 590 591INTERNET-DRAFT 28 May 2003 592 593 for each valid authenticated packet can cause DoS in case we have 594 attacker who can listen all traffic in the network, and can change 595 the order of the packet and inject new packets before the packet he 596 has already seen. I.e attacker can take the authenticated packet from 597 the host behind NAT, change the packet UDP source or destination 598 ports or IP addresses and sent it out to the other end before the 599 real packet reaches there. The host not behind the NAT will update 600 its IP address and port mapping and sends further traffic to wrong 601 host or port. This situation is fixed immediately when the attacker 602 stops modifying the packets as the first real packet will fix the 603 situation back to normal. Implementations SHOULD AUDIT the event 604 every time the mapping is changed, as in normal case it should not 605 happen that often. 606 6079. IANA Considerations 608 609This documents contains two new "magic numbers" which are allocated from 610the existing IANA registry for IPsec. This document also renames 611existing registered port 4500. This document also defines 2 new payload 612types for IKE, and there is no registry for those in the IANA. 613 614New items to be added in the "Internet Security Association and Key 615Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry: 616 617 Name Value Reference 618 ---- ----- --------- 619 UDP-Encapsulated-Tunnel 3 [RFC XXXX] 620 UDP-Encapsulated-Transport 4 [RFC XXXX] 621 622Change in the registered port registry: 623 624 Keyword Decimal Description Reference 625 ------- ------- ----------- --------- 626 ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX] 627 ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC XXXX] 628 629New IKE payload numbers are (There is no IANA registry related to this, 630and no need to create new one, but if one is added these should be added 631to there): 632 633 NAT-D 15 NAT Discovery Payload 634 NAT-OA 16 NAT Original Address Payload 635 63610. Intellectual property rights 637 638The IETF has been notified of intellectual property rights claimed in 639regard to some or all of the specification contained in this document. 640For more information consult the online list of claimed rights. 641 642SSH Communications Security Corp has notified the working group of one 643or more patents or patent applications that may be relevant to this 644document. SSH Communications Security Corp has already given a license 645for those patents to the IETF. For more information consult the online 646 647 648T. Kivinen, et. al. [page 11] 649 650INTERNET-DRAFT 28 May 2003 651 652list of claimed rights. 653 65411. Acknowledgments 655 656Thanks to Markus Stenberg, Larry DiBurro and William Dixon who 657contributed actively to this document. 658 659Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 660contributed to the document used as base for this document. 661 66212. Normative References 663 664[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 665November 1998 666 667[RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 668for ISAKMP", November 1998 669 670[Hutt03] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 671draft-ietf-ipsec-udp-encaps-06.txt, January 2003 672 673[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 674Requirement Levels", March 1997 675 67613. Non-Normative References 677 678[Aboba03] Aboba, B. et. al., "IPsec-NAT Compatibility Requirements", 679draft-ietf-ipsec-nat-reqts-04.txt, March 2003. 680 68114. Authors' Addresses 682 683 Tero Kivinen 684 SSH Communications Security Corp 685 Fredrikinkatu 42 686 FIN-00100 HELSINKI 687 Finland 688 E-mail: kivinen@ssh.fi 689 690 Ari Huttunen 691 F-Secure Corporation 692 Tammasaarenkatu 7, 693 FIN-00181 HELSINKI 694 Finland 695 E-mail: Ari.Huttunen@F-Secure.com 696 697 Brian Swander 698 Microsoft 699 One Microsoft Way 700 Redmond WA 98052 701 E-mail: briansw@microsoft.com 702 703 Victor Volpe 704 Cisco Systems 705 706 707T. Kivinen, et. al. [page 12] 708 709INTERNET-DRAFT 28 May 2003 710 711 124 Grove Street 712 Suite 205 713 Franklin, MA 02038 714 E-mail: vvolpe@cisco.com 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