idnits 2.17.1 draft-ietf-ipsec-nat-t-ike-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 October 2002) is 7854 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC XXXX' is mentioned on line 518, but not defined ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'Hutt02' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-udp-encaps-justification is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'Dixon02' == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-nat-reqts-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-nat-reqts (ref. 'Aboba02') Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-ipsec-nat-t-ike-04.txt A. Huttunen 4 Expires: 24 April 2002 F- Secure Corporation 5 B. Swander 6 Microsoft 7 V. Volpe 8 Cisco Systems 9 24 October 2002 11 Negotiation of NAT-Traversal in the IKE 13 Status of This Memo 15 This document is a submission to the IETF IP Security Protocol 16 (IPSEC) Working Group. Comments are solicited and should be 17 addressed to the working group mailing list (ipsec@lists.tislabs.com) 18 or to the editor. 20 This document is an Internet-Draft and is in full conformance 21 with all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as 32 "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes how to detect one or more NATs between IPsec 43 hosts, and how to negotiate the use of UDP encapsulation of the IPsec 44 packets through the NAT boxes in IKE. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 50 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3 52 3.2. Detecting presence of NAT . . . . . . . . . . . . . . . . . 3 53 4. Changing to the new ports . . . . . . . . . . . . . . . . . . . 5 54 5. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 7 56 5.2. Sending the original source address . . . . . . . . . . . . 8 57 6. Initial contact notifications . . . . . . . . . . . . . . . . . 9 58 7. Recovering from the expiring NAT mappings . . . . . . . . . . . 9 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 61 10. Compatibility with older versions of NAT-Traversal . . . . . . 11 62 11. Intellectual property rights . . . . . . . . . . . . . . . . . 11 63 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 64 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 This document is split in two parts. The first part describes what is 70 needed in the IKE phase 1 for the NAT-Traversal support. This includes 71 detecting if the other end supports NAT-Traversal, and detecting if 72 there is one or more NAT along the path from host to host. 74 The second part describes how to negotiate the use of UDP encapsulated 75 IPsec packets in the IKE Quick Mode. It also describes how to transmit 76 the original source address to the other end if needed. The original 77 source address can be used to incrementally update the TCP/IP checksums 78 so that they will match after the NAT transform (The NAT cannot do this, 79 because the TCP/IP checksum is inside the UDP encapsulated IPsec 80 packet). 82 The document [Hutt02] describes the details of the UDP encapsulation and 83 the document [Dixon02] and [Aboba02] provides background information and 84 motivation of the NAT-Traversal in general. This document in combination 85 with [Hutt02] represent an "unconditionally compliant" solution to the 86 requirements as defined by [Aboba02]. 88 2. Specification of Requirements 90 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 91 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 92 "OPTIONAL" to describe requirements. They are to be interpreted as 93 described in [RFC-2119] document. 95 3. Phase 1 96 The detection of the support for the NAT-Traversal and detection of the 97 NAT along the path happens in the IKE [RFC-2409] phase 1. 99 The NAT may change the IKE UDP source port, and recipients MUST be able 100 to process IKE packets whose source port is different than 500. There 101 are cases where the NAT does not have to change the source port: 103 o only one IPsec host behind the NAT 105 o for the first IPsec host the NAT can keep the port 500, and change 106 only specified IPsec host IP addresses 108 Recipients MUST reply back to the source address from the packet. This 109 also means that when the original responder is doing rekeying, or 110 sending notifications etc. to the original initiator it MUST send the 111 packets from the same set of port and IP numbers that was used when the 112 IKE SA was last time used (i.e the source and destination port and IP 113 numbers must be same). 115 For example, when the initiator sends a packet having source and 116 destination port 500, the NAT may change that to a packet which has 117 source port 12312 and destination port 500. The responder must be able 118 to process the packet whose source port is that 12312. It must reply 119 back with a packet whose source port is 500 and destination port 12312. 120 The NAT will then translate this packet to have source port 500 and 121 destination port 500. 123 3.1. Detecting support of Nat-Traversal 125 The NAT-Traversal capability of the remote host is determined by an 126 exchange of vendor strings; in Phase 1 two first messages, the vendor id 127 payload for this specification of NAT-Traversal (MD5 hash of "RFC XXXX" 128 - ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if supported 129 (and it MUST be received by both sides) for the NAT-Traversal probe to 130 continue. 132 3.2. Detecting presence of NAT 134 The purpose of the NAT-D payload is twofold, It not only detects the 135 presence of NAT between two IKE peers, it also detects where the NAT is. 136 The location of the NAT device is important in that the keepalives need 137 to initiate from the peer "behind" the NAT. 139 To detect the NAT between the two hosts, we need to detect if the IP 140 address or the port changes along the path. This is done by sending the 141 hashes of IP address and port of both source and destination addresses 142 from each end to another. When both ends calculate those hashes and get 143 same result they know there is no NAT between. If the hashes do not 144 match, somebody translated the address or port between, meaning we need 145 to do NAT-Traversal to get IPsec packet through. 147 If the sender of the packet does not know his own IP address (in case of 148 multiple interfaces, and implementation don't know which is used to 149 route the packet out), he can include multiple local hashes to the 150 packet (as separate NAT-D payloads). In this case the NAT is detected if 151 and only if none of the hashes match. 153 The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 154 payload contains one hash, so in case of multiple hashes, multiple NAT-D 155 payloads are sent. In normal case there is only two NAT-D payloads. 157 The NAT-D payloads are included in the third and fourth packet in the 158 main mode and second and third packet in the aggressive mode. 160 The format of the NAT-D packet is 162 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 163 +---------------+---------------+---------------+---------------+ 164 | Next Payload | RESERVED | Payload length | 165 +---------------+---------------+---------------+---------------+ 166 ~ HASH of the address and port ~ 167 +---------------+---------------+---------------+---------------+ 169 The payload type for the NAT discovery payload is 15. 171 The HASH is calculated as follows: 173 HASH = HASH(CKY-I | CKY-R | IP | Port) 175 using the negotiated HASH algorithm. All data inside the HASH is in the 176 network byte-order. The IP is 4 octets for the IPv4 address and 16 177 octets for the IPv6 address. The port number is encoded as 2 octet 178 number in network byte-order. The first NAT-D payload contains the 179 remote ends IP address and port (i.e the destination address of the UDP 180 packet). The rest of the NAT-D payloads contain possible local end IP 181 addresses and ports (i.e all possible source addresses of the UDP 182 packet). 184 If there is no NAT between then the first NAT-D payload should match one 185 of the local NAT-D packet (i.e the local NAT-D payloads this host is 186 sending out), and the one of the other NAT-D payloads must match the 187 remote ends IP address and port. If the first check fails (i.e first 188 NAT-D payload does not match any of the local IP addresses and ports), 189 then it means that there is dynamic NAT between, and this end should 190 start sending keepalives as defined in the [Hutt02]. 192 The CKY-I and CKY-R are the initiator and responder cookies, and they 193 are added to the hash to make precomputation attacks for the IP address 194 and port impossible. 196 An example of phase 1 exchange using NAT-Traversal in main mode 197 (authentication with signatures) is: 199 Initiator Responder 200 ------------ ------------ 201 HDR, SA, VID --> 202 <-- HDR, SA, VID 203 HDR, KE, Ni, NAT-D, NAT-D --> 204 <-- HDR, KE, Nr, NAT-D, NAT-D 205 HDR*#, IDii, [CERT, ] SIG_I --> 206 <-- HDR*#, IDir, [ CERT, ], SIG_R 208 An example of phase 1 exchange using NAT-Traversal in aggressive mode 209 (authentication with signatures) is: 211 Initiator Responder 212 ------------ ------------ 213 HDR, SA, KE, Ni, IDii, VID --> 214 <-- HDR, SA, KE, Nr, IDir, 215 [CERT, ], VID, NAT-D, 216 NAT-D, SIG_R 217 HDR*#, [CERT, ], NAT-D, NAT-D, 218 SIG_I --> 220 The '#' sign identifies that those packets are sent to the changed port 221 if NAT is detected. 223 4. Changing to the new ports 225 IPsec-aware NATs can cause problems. Some NATs will not change IKE 226 source port 500 even if there are multiple clients behind the NAT. They 227 can also map IKE cookies to demultiplex traffic instead of using the 228 source port. Both of these are problematic for generic NAT transparency 229 since it is difficult for IKE to discover the capabilities of the NAT. 230 The best approach is to simply move the IKE traffic off port 500 as soon 231 as possible to avoid any IPsec-aware NAT special casing. 233 Take the common case of the initiator behind the NAT. The initiator must 234 quickly change to 4500 once the NAT has been detected to minimize the 235 window of IPsec-aware NAT problems. 237 In main mode, the initiator MUST change ports when sending the ID 238 payload if there is NAT between the hosts. The initiator MUST set both 239 UDP source and destination ports to 4500. All subsequent packets sent to 240 this peer (including informational notifications) MUST be sent on 4500. 241 In addition, the IKE data MUST be prepended with a non-ESP marker 242 allowing for demultiplexing of traffic as defined in [Hutt02]. 244 Thus, the IKE packet now looks like: 246 IP UDP(4500,4500) HDR*, IDii, [CERT, ] SIG_I 248 assuming authentication using signatures. The 4 bytes of non-ESP marker 249 is defined in the [Hutt02]. 251 When the responder gets this packet he performs the usual decryption and 252 processing of the various payloads. If this is successful, he MUST 253 update local state so that all subsequent packets (including 254 informational notifications) to the peer use the new port, and possibly 255 new IP address obtained from the incoming valid packet. The port will 256 generally be different since the NAT will map UDP(500,500) to 257 UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will 258 seldom be different from the pre-change IP address. The responder MUST 259 respond with all subsequent IKE packets to this peer using UDP(4500,Y). 261 Similarly, if the responder needs to rekey the phase 1 SA, then he MUST 262 start the negotiation using UDP(4500,Y). Any implementation that 263 supports NAT traversal, MUST support negotiations that begin on port 264 4500. If a negotiation starts on 4500, then it doesn't need to change 265 anywhere else in the exchange. 267 Once port change has occurred, if a packet is received on 500, that 268 packet is old. If the packet is an informational, it MAY be processed if 269 local policy allows. If the packet is a main mode or aggressive mode 270 packet, it SHOULD be discarded. 272 Here is an example of phase 1 exchange using NAT-Traversal in main mode 273 (authentication with signatures) with changing port: 275 Initiator Responder 276 ------------ ------------ 277 UDP(500,500) HDR, SA, VID --> 278 <-- UDP(500,X) HDR, SA, VID 279 UDP(500,500) HDR, KE, Ni, 280 NAT-D, NAT-D --> 281 <-- UDP(500,X) HDR, KE, Nr, 282 NAT-D, NAT-D 283 UDP(4500,4500) HDR*#, IDii, 284 [CERT, ]SIG_I --> 285 <-- UDP(4500,Y) HDR*#, IDir, 286 [ CERT, ], SIG_R 288 The algorithm for aggressive mode is very similar. After the NAT has 289 been detected, the initiator sends: IP UDP(4500,4500) <4 bytes of non- 290 ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I The responder does 291 similar processing to the above, and if successful, MUST update his 292 internal IKE ports. The responder MUST respond with all subsequent IKE 293 packets to this peer using UDP(4500,Y). 295 Initiator Responder 296 ------------ ------------ 298 UDP(500,500) HDR, SA, KE, 299 Ni, IDii, VID --> 300 <-- UDP(500,X) HDR, SA, KE, 301 Nr, IDir, [CERT, ], 302 VID, NAT-D, NAT-D, 303 SIG_R 304 UDP(4500,4500) HDR*#, [CERT, ], 305 NAT-D, NAT-D, 306 SIG_I --> 307 <-- UDP(4500, Y) HDR*#, ... 309 While changing ports, the port in the ID payload in Main Mode/Aggressive 310 Mode MUST be 0. 312 The most common case for the responder behind the NAT is if the NAT is 313 simply doing 1-1 address translation. In this case, the initiator still 314 changes both ports to 4500. The responder uses the identical algorithm 315 as above, although in this case, Y will equal 4500, since no port 316 translation is happening. 318 A different port change case involves out-of-band discovery of the ports 319 to use. For instance, if the responder is behind a port translating NAT, 320 and the initiator needs to contact it first, then the initiator will 321 need to determine which ports to use, usually by contacting some other 322 server. Once the initiator knows which ports to use to traverse the NAT, 323 generally something like UDP(Z,4500), he initiates using these ports. 324 This is similar to the responder rekey case above in that the ports to 325 use are already known upfront, and no additional change need take place. 327 Also the first keepalive timer starts after change to new port, no 328 keepalives are sent to the port 500. 330 5. Quick Mode 332 After the Phase 1 both ends know if there is a NAT present between. The 333 final decision of using the NAT-Traversal is left to the quick mode. The 334 use of NAT-Traversal is negotiated inside the SA payloads of the quick 335 mode. In the quick mode both ends can also send the original source 336 addresses of the IPsec packets (in case of the transport mode) to the 337 other, end so the other end has possibility to fix the TCP/IP checksum 338 field after the NAT transform. 340 This sending of the original source address is optional, and it is not 341 useful in the UDP-Encapsulated-Tunnel mode, as there is going to be 342 proper IP header inside the UDP-Encapsulated packet. In case of only 343 UDP-Encapsulated-Tunnel mode is negotiation then both ends SHOULD NOT 344 send original source address. 346 It also might be unnecessary in the transport mode if the other end can 347 turn off TCP/IP checksum verification. If the sending end knows (for 348 example from the vendor id payload) that the other end can turn off 349 TCP/IP checksum verification, he MAY leave the original source address 350 payload away. Otherwise he SHOULD send the original source address. 352 5.1. Negotiation of the NAT-Traversal encapsulation 354 The negotiation of the NAT-Traversal happens by adding two new 355 encapsulation modes. These encapsulation modes are: 357 UDP-Encapsulated-Tunnel 3 358 UDP-Encapsulated-Transport 4 359 It is not normally useful to propose both normal tunnel or transport 360 mode and UDP-Encapsulated modes. If there is a NAT box between normal 361 tunnel or transport encapsulations may not work, and if there is no NAT 362 box between, there is no point of wasting bandwidth by adding UDP 363 encapsulation of packets. Because of this initiator SHOULD NOT include 364 both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP- 365 Encapsulated-Transport in its proposals. 367 5.2. Sending the original source address 369 In case of transport mode both ends SHOULD send the original source 370 address to the other end. For the tunnel mode both ends SHOULD NOT send 371 original source address to the other end. 373 The original source address of packets put to this transport mode IPsec 374 SA is sent to other end using NAT-OA (NAT Original Address) payload. 376 The NAT-OA payloads are sent inside the first and second packets of the 377 quick mode. The initiator SHOULD send the payload if it proposes any 378 UDP-Encapsulated-Transport mode and the responder SHOULD send the 379 payload only if it selected UDP-Encapsulated-Transport mode. I.e it is 380 possible that initiator send the NAT-OA payload, but proposes both UDP- 381 Encapsulated transport and tunnel mode, and then the responder selects 382 the UDP-Encapsulated tunnel mode and do not send NAT-OA payload back. 384 A peer MUST NOT fail a negotiation if it does not receive a NAT-OA 385 payload if the NAT-OA payload only would contain redundant information. 386 I.e. only the machine(s) that are actually behind the NAT need to send 387 the NAT-OA payload. A machine with a public, non-changing IP address 388 doesn't need to send the NAT-OA payload. 390 The format of the NAT-OA packet is 392 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 393 +---------------+---------------+---------------+---------------+ 394 | Next Payload | RESERVED | Payload length | 395 +---------------+---------------+---------------+---------------+ 396 | ID Type | RESERVED | RESERVED | 397 +---------------+---------------+---------------+---------------+ 398 | IPv4 (4 octets) or IPv6 address (16 octets) | 399 +---------------+---------------+---------------+---------------+ 401 The payload type for the NAT original address payload is 16. 403 The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 404 ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 405 Type must be zero. 407 An example of quick mode using NAT-OA payloads is: 409 Initiator Responder 410 ------------ ------------ 411 HDR*, HASH(1), SA, Ni, [, KE] 413 [, IDci, IDcr ] [, NAT-OA] --> 414 <-- HDR*, HASH(2), SA, Nr, [, KE] 415 [, IDci, IDcr ] [, NAT-OA] 416 HDR*, HASH(3) 418 6. Initial contact notifications 420 The source IP and port address of the INITIAL-CONTACT notification for 421 the host behind NAT are not meaningful, so the IP and port numbers MUST 422 NOT be used for the determine which IKE/IPsec SAs to remove. The ID 423 payload sent from the other SHOULD be used instead. I.e when INITIAL- 424 CONTACT notification is received from the other end, the receiving end 425 SHOULD remove all the SAs associated with the same ID payload. 427 7. Recovering from the expiring NAT mappings 429 There are cases where NAT box decides to remove mappings that are still 430 alive (for example, the keepalive interval is too long, or the NAT box 431 is rebooted). To recover from those ends which are NOT behind NAT SHOULD 432 use the last valid authenticated packet from the other end to determine 433 which IP and port addresses should be used. The host behind dynamic NAT 434 MUST NOT do this as otherwise it opens DoS attack possibility, and there 435 is no need for that, because the IP address or port of other host will 436 not change (it is not behind NAT). 438 Keepalives cannot be used for this purposes as they are not 439 authenticated, but any IKE authenticated IKE packet or ESP packet can be 440 used to detect that the IP address or the port has changed. 442 8. Security Considerations 444 Whenever changes to some fundamental parts of a security protocol are 445 proposed, the examination of security implications cannot be skipped. 446 Therefore, here are some observations on the effects, and whether or not 447 these effects matter. 449 o IKE probe reveals NAT-Traversal support to everyone. This should not 450 be an issue. 452 o The value of authentication mechanisms based on IP addresses 453 disappears once NATs are in the picture. That is not necessarily a 454 bad thing (for any real security, other authentication measures than 455 IP addresses should be used). This means that pre-shared-keys 456 authentication cannot be used with the main mode without group shared 457 keys for everybody behind the NAT box, which is huge security risk. 458 Use of group shared keys is NOT RECOMMENDED. 460 o As the internal address space is only 32 bits, and it is usually very 461 sparse, it might be possible for the attacker to find out the 462 internal address used behind the NAT box by trying all possible IP- 463 addresses and trying to find the matching hash. The port numbers are 464 normally fixed to 500, and the cookies can be extracted from the 465 packet. This limits the hash calculations down to 2^32. If educated 466 guess of use of private address space is done, then the number of 467 hash calculations needed to find out the internal IP address goes 468 down to the 2^24 + 2 * (2^16). 470 o Neither NAT-D payloads or Vendor ID payloads are authenticated at all 471 in the main mode nor in the aggressive mode. This means that attacker 472 can remove those payloads, modify them or add them. By removing or 473 adding them the attacker can cause Denial Of Service attacks. By 474 modifying the NAT-D packets the attacker can cause both ends to use 475 UDP-Encapsulated modes instead of directly using tunnel or transport 476 mode, thus wasting some bandwidth. 478 o The sending of the original source address in the Quick Mode reveals 479 the internal IP address behind the NAT to the other end. In this case 480 we have already authenticated the other end, and sending of the 481 original source address is only needed in transport mode. 483 o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports 484 for each valid authenticated packet can cause DoS in case we have 485 attacker who can listen all traffic in the network, and can change 486 the order of the packet and inject new packets before the packet he 487 has already seen. I.e attacker can take the authenticated packet from 488 the host behind NAT, change the packet UDP source or destination 489 ports or IP addresses and sent it out to the other end before the 490 real packet reaches there. The host not behind the NAT will update 491 its IP address and port mapping and sends further traffic to wrong 492 host or port. This situation is fixed immediately when the attacker 493 stops modifying the packets as the first real packet will fix the 494 situation back to normal. Implementations SHOULD AUDIT the event 495 every time the mapping is changed, as in normal case it should not 496 happen that often. 498 9. IANA Considerations 500 This documents contains two new "magic numbers" which are allocated from 501 the existing IANA registry for IPsec. This document also renames 502 existing registered port 4500. This document also defines 2 new payload 503 types for IKE, and there is no registry for those in the IANA. 505 New items to be added in the "Internet Security Association and Key 506 Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry: 508 Name Value Reference 509 ---- ----- --------- 510 UDP-Encapsulated-Tunnel 3 [RFC XXXX] 511 UDP-Encapsulated-Transport 4 [RFC XXXX] 513 Change in the registered port registry: 515 Keyword Decimal Description Reference 516 ------- ------- ----------- --------- 517 ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX] 518 ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC XXXX] 520 New IKE payload numbers are (There is no IANA registry related to this, 521 and no need to create new one): 523 NAT-D 15 NAT Discovery Payload 524 NAT-OA 16 NAT Original Address Payload 526 10. Compatibility with older versions of NAT-Traversal 528 There are some NAT-Traversal implementations out that will same protocol 529 as described in this document but numbers are allocated from the private 530 use range. The values used in those versions are: 532 NAT-D 130 533 NAT-OA 131 534 UDP-Encapsulated-Tunnel 61443 535 UDP-Encapsulated-Transport 61444 537 Those previous versions used also different Vendor ID payload hash 538 value. The use of old numbers is indicated with Vendor ID hash "90cb8091 539 3ebb696e 086381b5 ec427b1f" or "7d9419a6 5310ca6f 2c179d92 15529d56". If 540 implementations want to include compatibility with those older versions 541 they should send also those Vendor ID payloads, and if either one of 542 those two is received enable the old backward compatibility mode. 544 Implementations MAY support for backward compatibility, but if both ends 545 support both old version and new version they MUST use the new numbers, 546 not the old private use numbers. 548 11. Intellectual property rights 550 The IETF has been notified of intellectual property rights claimed in 551 regard to some or all of the specification contained in this document. 552 For more information consult the online list of claimed rights. 554 SSH Communications Security Corp has notified the working group of one 555 or more patents or patent applications that may be relevant to this 556 document. SSH Communications Security Corp has already given a license 557 for those patents to the IETF. For more information consult the online 558 list of claimed rights. 560 12. Acknowledgments 562 Thanks to Markus Stenberg, Larry DiBurro and William Dixon who 563 contributed actively to this document. 565 Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 566 contributed to the document used as base for this document. 568 13. References 570 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 571 November 1998 572 [RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 573 for ISAKMP", November 1998 575 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 576 Requirement Levels", March 1997 578 [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 579 [Dixon02] Dixon, W. et. al., "IPSec over NAT Justification for UDP 580 Encapsulation", draft-ietf-ipsec-udp-encaps-justification-01.txt, June 581 2001 583 [Aboba02] Aboba, B. et. al., "IPsec-NAT Compatibility Requirements", 584 draft-ietf-ipsec-nat-reqts-02.txt, June 2002. 586 14. Authors' Addresses 588 Tero Kivinen 589 SSH Communications Security Corp 590 Fredrikinkatu 42 591 FIN-00100 HELSINKI 592 Finland 593 E-mail: kivinen@ssh.fi 595 Ari Huttunen 596 F-Secure Corporation 597 Tammasaarenkatu 7, 598 FIN-00181 HELSINKI 599 Finland 600 E-mail: Ari.Huttunen@F-Secure.com 602 Brian Swander 603 Microsoft 604 One Microsoft Way 605 Redmond WA 98052 606 E-mail: briansw@microsoft.com 608 Victor Volpe 609 Cisco Systems 610 124 Grove Street 611 Suite 205 612 Franklin, MA 02038 613 E-mail: vvolpe@cisco.com