1IP Security Protocol Working Group (IPSEC) T. Kivinen, M. Stenberg 2INTERNET-DRAFT SSH Communications Security 3draft-ietf-ipsec-nat-t-ike-01.txt A. Huttunen 4Expires: 23 April 2001 F-Secure Corporation 5 W. Dixon, B. Swander 6 Microsoft 7 V. Volpe 8 Cisco Systems 9 L. DiBurro 10 Nortel Networks 11 23 October 2001 12 13 14 15 Negotiation of NAT-Traversal in the IKE 16 17Status of This Memo 18 19This document is a submission to the IETF IP Security Protocol 20(IPSEC) Working Group. Comments are solicited and should be 21addressed to the working group mailing list (ipsec@lists.tislabs.com) 22or to the editor. 23 24This document is an Internet-Draft and is in full conformance 25with all provisions of Section 10 of RFC2026. 26 27Internet-Drafts are working documents of the Internet Engineering 28Task Force (IETF), its areas, and its working groups. Note that 29other groups may also distribute working documents as 30Internet-Drafts. 31 32Internet-Drafts are draft documents valid for a maximum of six 33months and may be updated, replaced, or obsoleted by other 34documents at any time. It is inappropriate to use Internet- 35Drafts as reference material or to cite them other than as 36"work in progress." 37 38The list of current Internet-Drafts can be accessed at 39http://www.ietf.org/ietf/1id-abstracts.txt 40 41The list of Internet-Draft Shadow Directories can be accessed at 42http://www.ietf.org/shadow.html. 43 44Abstract 45 46This document describes how to detect one or more NATs between IPsec 47hosts, and how to negotiate the use of UDP encapsulation of the IPsec 48packets through the NAT boxes in IKE. 49 50 51 52 53 54 55 56 57 58T. Kivinen, et. al. [page 1] 59 60INTERNET-DRAFT 23 October 2001 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 presense of NAT . . . . . . . . . . . . . . . . . 3 694. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 5 71 4.2. Sending the original source address . . . . . . . . . . . . 5 725. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 736. Intellectual property rights . . . . . . . . . . . . . . . . . . 7 747. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 758. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 769. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 78 79 801. Introduction 81 82This document is split in two parts. The first part describes what is 83needed in the IKE phase 1 for the NAT-Traversal support. This includes 84detecting if the other end supports NAT-Traversal, and detecting if 85there is one or more NAT along the path from host to host. 86 87The second part describes how to negotiate the use of UDP encapsulated 88IPsec packets in the IKE Quick Mode. It also describes how to transmit 89the original source address to the other end if needed. The original 90source address can be used to incrementally update the TCP/IP checksums 91so that they will match after the NAT transform (The NAT cannot do this, 92because the TCP/IP checksum is inside the UDP encapsulated IPsec 93packet). 94 95The document [Hutt01] describes the details of the UDP encapsulation and 96the document [Dixon01] provides background information and motivation of 97the NAT-Traversal in general. 98 992. Specification of Requirements 100 101This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 102"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 103"OPTIONAL" to describe requirements. They are to be interpreted as 104described in [RFC-2119] document. 105 1063. Phase 1 107 108The detection of the support for the NAT-Traversal and detection of the 109NAT along the path happens in the IKE [RFC-2409] phase 1. 110 111The NAT is supposed to float the IKE UDP port, and recipients MUST be 112able to process IKE packets whose source port is different than 500. 113There are cases where the NAT does not have to float the source port 114(only one (IPsec) host behind the NAT or for the first IPsec host it can 115 116 117T. Kivinen, et. al. [page 2] 118 119INTERNET-DRAFT 23 October 2001 120 121keep the port 500, and float only the following IPsec hosts). 122 123Recipients MUST reply back to the source address from the packet. This 124also means that when the original responder is doing rekeying, or 125sending notifications etc. to the original initiator it MUST send the 126packets from the same set of port and IP numbers that was used when the 127IKE SA was originally created (i.e the source and destination port and 128IP numbers must be same). 129 130For example the initiator sends packet having source and destination 131port 500, the NAT changes that to such packet which have source port 13212312 and destination port 500, the responder must be able to process 133the packet whose source address is that 12312 and it must reply back 134with packet whose source address is 500 and destination address 12312, 135the NAT will then translate this packet to have source address 500 and 136destination address 500. 137 1383.1. Detecting support of Nat-Traversal 139 140The NAT-Traversal capability of the remote host is determined by an 141exchange of vendor strings; in Phase 1 two first messages, the vendor id 142payload for this specification of NAT-Traversal (MD5 hash of "draft- 143ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd 0be8a846 9579ddcc"]) MUST 144be sent if supported (and it MUST be received by both sides) for the 145NAT-Traversal probe to continue. 146 1473.2. Detecting presense of NAT 148 149The purpose of the NAT-D payload is twofold, It not only detects the 150presence of NAT between two IKE peers, it also detects where the NAT is. 151The location of the NAT device is important in that the keepalives need 152to initiate from the peer "behind" the NAT. 153 154To detect the NAT between the two hosts, we need to detect if the IP 155address or the port changes along the path. This is done by sending the 156hashes of IP address and port of both source and destination addresses 157from each end to another. When both ends calculate those hashes and get 158same result they know there is no NAT between. If the hashes do not 159match, somebody translated the address or port between, meaning we need 160to do NAT-Traversal to get IPsec packet through. 161 162If the sender of the packet does not know his own IP address (in case of 163multiple interfaces, and implementation don't know which is used to 164route the packet out), he can include multiple local hashes to the 165packet (as separate NAT-D payloads). In this case the NAT is detected if 166and only if none of the hashes match. 167 168The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 169payload contains one hash, so in case of multiple hashes, multiple NAT-D 170payloads are sent. In normal case there is only two NAT-D payloads. 171 172The NAT-D payloads are included in the third and fourth packet in the 173main mode and second and third packet in the aggressive mode. 174 175 176T. Kivinen, et. al. [page 3] 177 178INTERNET-DRAFT 23 October 2001 179 180The format of the NAT-D packet is 181 182 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 183 +---------------+---------------+---------------+---------------+ 184 | Next Payload | RESERVED | Payload length | 185 +---------------+---------------+---------------+---------------+ 186 ~ HASH of the address and port ~ 187 +---------------+---------------+---------------+---------------+ 188 189The payload type for the NAT discovery payload is 130 (XXX CHANGE). 190 191The HASH is calculated as follows: 192 193 HASH = HASH(CKY-I | CKY-R | IP | Port) 194 195using the negotiated HASH algorithm. All data inside the HASH is in the 196network byte-order. The IP is 4 octets for the IPv4 address and 16 197octets for the IPv6 address. The port number is encoded as 2 octet 198number in network byte-order. The first NAT-D payload contains the 199remote ends IP address and port (i.e the destination address of the UDP 200packet). The rest of the NAT-D payloads contain possible local end IP 201addresses and ports (i.e all possible source addresses of the UDP 202packet). 203 204If there is no NAT between then the first NAT-D payload should match one 205of the local NAT-D packet (i.e the local NAT-D payloads this host is 206sending out), and the one of the other NAT-D payloads must match the 207remote ends IP address and port. If the first check fails (i.e first 208NAT-D payload does not match any of the local IP addresses and ports), 209then it means that there is dynamic NAT between, and this end should 210start sending keepalives as defined in the [Hutt01]. 211 212The CKY-I and CKY-R are the initiator and responder cookies, and they 213are added to the hash to make precomputation attacks for the IP address 214and port impossible. 215 216An example of phase 1 exchange using NAT-Traversal in main mode 217(authentication with signatures) is: 218 219 Initiator Responder 220 ------------ ------------ 221 HDR, SA, VID --> 222 <-- HDR, SA, VID 223 HDR, KE, Ni, NAT-D, NAT-D --> 224 <-- HDR, KE, Nr, NAT-D, NAT-D 225 HDR*, IDii, [CERT, ] SIG_I --> 226 <-- HDR*, IDir, [ CERT, ], SIG_R 227 228An example of phase 1 exchange using NAT-Traversal in aggressive mode 229(authentication with signatures) is: 230 231 Initiator Responder 232 ------------ ------------ 233 234 235T. Kivinen, et. al. [page 4] 236 237INTERNET-DRAFT 23 October 2001 238 239 HDR, SA, KE, Ni, IDii, VID --> 240 <-- HDR, SA, KE, Nr, IDir, [CERT, ], 241 VID, NAT-D, NAT-D, SIG_R 242 HDR*, [CERT, ], NAT-D, NAT-D, 243 SIG_I --> 244 2454. Quick Mode 246 247After the Phase 1 both ends know if there is a NAT present between. The 248final decision of using the NAT-Traversal is left to the quick mode. The 249use of NAT-Traversal is negotiated inside the SA payloads of the quick 250mode. In the quick mode both ends can also send the original source 251addresses of the IPsec packets (in case of the transport mode) to the 252other, end so the other end has possibility to fix the TCP/IP checksum 253field after the NAT transform. 254 255This sending of the original source address is optional, and it is not 256useful in the UDP-Encapsulated-Tunnel mode, as there is going to be 257proper IP header inside the UDP-Encapsulated packet. In case of only 258UDP-Encapsulated-Tunnel mode is negotiation then both ends SHOULD NOT 259send original source address. 260 261It also might be unnecessary in the transport mode if the other end can 262turn off TCP/IP checksum verification. If the sending end knows (for 263example from the vendor id payload) that the other end can turn off 264TCP/IP checksum verification, he MAY leave the original source address 265payload away. Otherwise he SHOULD send the original source address. 266 2674.1. Negotiation of the NAT-Traversal encapsulation 268 269The negoation of the NAT-Traversal happens by adding two new 270encapsulation modes. These encapsulation modes are: 271 272UDP-Encapsulated-Tunnel 61443 (XXX CHANGE) 273UDP-Encapsulated-Transport 61444 (XXX CHANGE) 274 275It is not normally useful to propose both normal tunnel or transport 276mode and UDP-Encapsulated modes. If there is a NAT box between normal 277tunnel or transport encapsulations may not work, and if there is no NAT 278box between, there is no point of wasting bandwidth by adding UDP 279encapsulation of packets. Because of this initiator SHOULD NOT include 280both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP- 281Encapsulated-Transport in its proposals. 282 2834.2. Sending the original source address 284 285In case of transport mode both ends SHOULD send the original source 286address to the other end. For the tunnel mode both ends SHOULD NOT send 287original source address to the other end. 288 289The original source address of packets put to this transport mode IPsec 290SA is sent to other end using NAT-OA (NAT Original Address) payload. 291 292 293 294T. Kivinen, et. al. [page 5] 295 296INTERNET-DRAFT 23 October 2001 297 298The NAT-OA payloads are sent inside the first and second packets of the 299quick mode. The initiator SHOULD send the payload if it proposes any 300UDP-Encapsulated-Transport mode and the responder SHOULD send the 301payload only if it selected UDP-Encapsulated-Transport mode. I.e it is 302possible that initiator send the NAT-OA payload, but proposes both UDP- 303Encapsulated transport and tunnel mode, and then the responder selectes 304the UDP-Encapsulated tunnel mode and do not send NAT-OA payload back. 305 306A peer MUST NOT fail a negotiation if it does not receive a NAT-OA 307payload if the NAT-OA payload only would contain redundant information. 308I.e. only the machine(s) that are actually behind the NAT need to send 309the NAT-OA payload. A machine with a public, non-changing IP address 310doesn't need to send the NAT-OA payload. 311 312The format of the NAT-OA packet is 313 314 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 315 +---------------+---------------+---------------+---------------+ 316 | Next Payload | RESERVED | Payload length | 317 +---------------+---------------+---------------+---------------+ 318 | ID Type | RESERVED | RESERVED | 319 +---------------+---------------+---------------+---------------+ 320 | IPv4 (4 octets) or IPv6 address (16 octets) | 321 +---------------+---------------+---------------+---------------+ 322 323The payload type for the NAT discovery payload is 131 (XXX CHANGE). 324 325The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 326ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 327Type must be zero. 328 329An example of quick mode using NAT-OA payloads is: 330 331 Initiator Responder 332 ------------ ------------ 333 HDR*, HASH(1), SA, Ni, [, KE] 334 [, IDci, IDcr ] [, NAT-OA] --> 335 <-- HDR*, HASH(2), SA, Nr, [, KE] 336 [, IDci, IDcr ] [, NAT-OA] 337 HDR*, HASH(3) 338 3395. Security Considerations 340 341Whenever changes to some fundamental parts of a security protocol are 342proposed, the examination of security implications cannot be skipped. 343Therefore, here are some observations on the effects, and whether or not 344these effects matter. This section will be expanded further in future 345versions of this draft. 346 347o IKE probe reveals NAT-Traversal support to everyone. This should not 348 be an issue. 349 350o The value of authentication mechanisms based on IP addresses 351 352 353T. Kivinen, et. al. [page 6] 354 355INTERNET-DRAFT 23 October 2001 356 357 disappears once NATs are in the picture. That is not necessarily a 358 bad thing (for any real security, other authentication measures than 359 IP addresses should be used). This means that pre-shared-keys 360 authentication cannot be used with the main mode without group shared 361 keys for everybody behind the NAT box, which is huge security risk. 362 363o As the internal address space is only 32 bits, and it is usually very 364 sparce, it might be possible for the attacker to find out the 365 internal address used behind the NAT box by trying all possible IP- 366 addresses and trying to find the matching hash. The port numbers are 367 normally fixed to 500, and the cookies can be extracted from the 368 packet. This limits the hash calculations down to 2^32. If educated 369 guess of use of private address space is done, then the number of 370 hash calculations needed to find out the internal IP address goes 371 down to the 2^24 + 2 * (2^16). 372 373o The NAT-D payloads nor the Vendor ID payloads are not authenticated 374 at all in the main mode nor in the aggressive mode. This means that 375 attacker can remove those payloads, modify them or add them. By 376 removing or adding them the attacker can cause Denial Of Service 377 attacks. By modifying the NAT-D packets the attacker can cause both 378 ends to use UDP-Encapsulated modes instead of directly using tunnel 379 or transport mode, thus wasting some bandwidth. 380 381o The sending of the original source address in the Quick Mode releveas 382 the internal ip address behind the NAT to the other end. In this case 383 we have already authenticated the other end, and sending of the 384 original source address is only needed in transport mode. 385 3866. Intellectual property rights 387 388The IETF has been notified of intellectual property rights claimed in 389regard to some or all of the specification contained in this document. 390For more information consult the online list of claimed rights. 391 392SSH Communications Security Corp has notified the working group of one 393or more patents or patent applications that may be relevant to this 394internet-draft. SSH Communications Security Corp has already given a 395licence for those patents to the IETF. For more information consult the 396online list of claimed rights. 397 3987. Acknowledgments 399 400Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 401contributed to the drafts used as base for this document. 402 4038. References 404 405[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 406November 1998 407 408[RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 409for ISAKMP", November 1998 410 411 412T. Kivinen, et. al. [page 7] 413 414INTERNET-DRAFT 23 October 2001 415 416[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 417Requirement Levels", March 1997 418 419[Hutt01] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 420draft-ietf-ipsec-udp-encaps-01.txt, October 2001 421 422[Dixon01] Dixon, W. et. al., "IPSec over NAT Justification for UDP 423Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt, June 4242001 425 4269. Authors' Addresses 427 428 Tero Kivinen 429 SSH Communications Security Corp 430 Fredrikinkatu 42 431 FIN-00100 HELSINKI 432 Finland 433 E-mail: kivinen@ssh.fi 434 435 Markus Stenberg 436 SSH Communications Security Corp 437 Fredrikinkatu 42 438 FIN-00100 HELSINKI 439 Finland 440 E-mail: mstenber@ssh.com 441 442 Ari Huttunen 443 F-Secure Corporation 444 Tammasaarenkatu 7, 445 FIN-00181 HELSINKI 446 Finland 447 E-mail: Ari.Huttunen@F-Secure.com 448 449 William Dixon 450 Microsoft 451 One Microsoft Way 452 Redmond WA 98052 453 E-mail: wdixon@microsoft.com 454 455 Brian Swander 456 Microsoft 457 One Microsoft Way 458 Redmond WA 98052 459 E-mail: briansw@microsoft.com 460 461 Victor Volpe 462 Cisco Systems 463 124 Grove Street 464 Suite 205 465 Franklin, MA 02038 466 E-mail: vvolpe@cisco.com 467 468 Larry DiBurro 469 470 471T. Kivinen, et. al. [page 8] 472 473INTERNET-DRAFT 23 October 2001 474 475 Nortel Networks 476 80 Central Street 477 Boxborough, MA 01719 478 ldiburro@nortelnetworks.com 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529T. Kivinen, et. al. [page 9] 530