1IP Security Protocol Working Group (IPSEC) T. Kivinen, M. Stenberg 2INTERNET-DRAFT SSH Communications Security 3draft-ietf-ipsec-nat-t-ike-00.txt A. Huttunen 4Expires: 10 December 2001 F-Secure Corporation 5 W. Dixon, B. Swander 6 Microsoft 7 V. Volpe 8 Cisco Systems 9 L. DiBurro 10 Nortel Networks 11 10 June 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 10 June 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 . . . . . . . . . . . . . 2 68 3.2. Detecting presense of NAT . . . . . . . . . . . . . . . . . 3 694. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 1113.1. Detecting support of Nat-Traversal 112 113The NAT-Traversal capability of the remote host is determined by an 114exchange of vendor strings; in Phase 1 two first messages, the vendor id 115 116 117T. Kivinen, et. al. [page 2] 118 119INTERNET-DRAFT 10 June 2001 120 121payload for this specification of NAT-Traversal (MD5 hash of "draft- 122ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd 0be8a846 9579ddcc"]) MUST 123be sent if supported (and it MUST be received by both sides) for the 124NAT-Traversal probe to continue. 125 1263.2. Detecting presense of NAT 127 128The purpose of the NAT-D payload is twofold, It not only detects the 129presence of NAT between two IKE peers, it also detects where the NAT is. 130The location of the NAT device is important in that the keepalives need 131to initiate from the peer "behind" the NAT. 132 133To detect the NAT between the two hosts, we need to detect if the IP 134address or the port changes along the path. This is done by sending the 135hashes of IP address and port of both source and destination addresses 136from each end to another. When both ends calculate those hashes and get 137same result they know there is no NAT between. If the hashes do not 138match, somebody translated the address or port between, meaning we need 139to do NAT-Traversal to get IPsec packet through. 140 141If the sender of the packet does not know his own IP address (in case of 142multiple interfaces, and implementation don't know which is used to 143route the packet out), he can include multiple local hashes to the 144packet (as separate NAT-D payloads). In this case the NAT is detected if 145and only if none of the hashes match. 146 147The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 148payload contains one hash, so in case of multiple hashes, multiple NAT-D 149payloads are sent. In normal case there is only two NAT-D payloads. 150 151The NAT-D payloads are included in the third and fourth packet in the 152main mode and second and third packet in the aggressive mode. 153 154The format of the NAT-D packet is 155 156 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 157 +---------------+---------------+---------------+---------------+ 158 | Next Payload | RESERVED | Payload length | 159 +---------------+---------------+---------------+---------------+ 160 ~ HASH of the address and port ~ 161 +---------------+---------------+---------------+---------------+ 162 163The payload type for the NAT discovery payload is 130 (XXX CHANGE). 164 165The HASH is calculated as follows: 166 167 HASH = HASH(CKY-I | CKY-R | IP | Port) 168 169using the negotiated HASH algorithm. All data inside the HASH is in the 170network byte-order. The IP is 4 octets for the IPv4 address and 16 171octets for the IPv6 address. The port number is encoded as 2 octet 172number in network byte-order. The first NAT-D payload contains the 173remote ends IP address and port (i.e the destination address of the UDP 174 175 176T. Kivinen, et. al. [page 3] 177 178INTERNET-DRAFT 10 June 2001 179 180packet). The rest of the NAT-D payloads contain possible local end IP 181addresses and ports (i.e all possible source addresses of the UDP 182packet). 183 184If there is no NAT between then the first NAT-D payload should match one 185of the local NAT-D packet (i.e the local NAT-D payloads this host is 186sending out), and the one of the other NAT-D payloads must match the 187remote ends IP address and port. If the first check fails (i.e first 188NAT-D payload does not match any of the local IP addresses and ports), 189then it means that there is dynamic NAT between, and this end should 190start sending keepalives as defined in the [Hutt01]. 191 192The CKY-I and CKY-R are the initiator and responder cookies, and they 193are added to the hash to make precomputation attacks for the IP address 194and port impossible. 195 196An example of phase 1 exchange using NAT-Traversal in main mode 197(authentication with signatures) is: 198 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 207 208An example of phase 1 exchange using NAT-Traversal in aggressive mode 209(authentication with signatures) is: 210 211 Initiator Responder 212 ------------ ------------ 213 HDR, SA, KE, Ni, IDii, VID --> 214 <-- HDR, SA, KE, Nr, IDir, [CERT, ], 215 VID, NAT-D, NAT-D, SIG_R 216 HDR*, [CERT, ], NAT-D, NAT-D, 217 SIG_I --> 218 2194. Quick Mode 220 221After the Phase 1 both ends know if there is a NAT present between. The 222final decision of using the NAT-Traversal is left to the quick mode. The 223use of NAT-Traversal is negotiated inside the SA payloads of the quick 224mode. In the quick mode both ends can also send the original source 225addresses of the IPsec packets (in case of the transport mode) to the 226other, end so the other end has possibility to fix the TCP/IP checksum 227field after the NAT transform. 228 229This sending of the original source address is optional, and it is not 230useful in the UDP-Encapsulated-Tunnel mode, as there is going to be 231proper IP header inside the UDP-Encapsulated packet. In case of only 232UDP-Encapsulated-Tunnel mode is negotiation then both ends SHOULD NOT 233 234 235T. Kivinen, et. al. [page 4] 236 237INTERNET-DRAFT 10 June 2001 238 239send original source address. 240 241It also might be unnecessary in the transport mode if the other end can 242turn off TCP/IP checksum verification. If the sending end knows (for 243example from the vendor id payload) that the other end can turn off 244TCP/IP checksum verification, he MAY leave the original source address 245payload away. Otherwise he SHOULD send the original source address. 246 2474.1. Negotiation of the NAT-Traversal encapsulation 248 249The negoation of the NAT-Traversal happens by adding two new 250encapsulation modes. These encapsulation modes are: 251 252UDP-Encapsulated-Tunnel 61443 (XXX CHANGE) 253UDP-Encapsulated-Transport 61444 (XXX CHANGE) 254 255It is not normally useful to propose both normal tunnel or transport 256mode and UDP-Encapsulated modes. If there is a NAT box between normal 257tunnel or transport encapsulations may not work, and if there is no NAT 258box between, there is no point of wasting bandwidth by adding UDP 259encapsulation of packets. Because of this initiator SHOULD NOT include 260both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP- 261Encapsulated-Transport in its proposals. 262 2634.2. Sending the original source address 264 265In case of transport mode both ends SHOULD send the original source 266address to the other end. For the tunnel mode both ends SHOULD NOT send 267original source address to the other end. In case of AH is negotiated 268each end MUST send original source address. 269 270The original source address of packets put to this transport mode IPsec 271SA is sent to other end using NAT-OA (NAT Original Address) payload. 272 273The NAT-OA payloads are sent inside the first and second packets of the 274quick mode. The initiator SHOULD send the payload if it proposes any 275UDP-Encapsulated-Transport mode and the responder SHOULD send the 276payload only if it selected UDP-Encapsulated-Transport mode. I.e it is 277possible that initiator send the NAT-OA payload, but proposes both UDP- 278Encapsulated transport and tunnel mode, and then the responder selectes 279the UDP-Encapsulated tunnel mode and do not send NAT-OA payload back. 280 281A peer MUST NOT fail a negotiation if it does not receive a NAT-OA 282payload if the NAT-OA payload only would contain redundant information. 283I.e. only the machine(s) that are actually behind the NAT need to send 284the NAT-OA payload. A machine with a public, non-changing IP address 285doesn't need to send the NAT-OA payload. 286 287In case of AH negotiation initiator MUST send NAT-OA payload, and the 288responder MUST reply to it if it selected proposal including AH. 289 290The format of the NAT-OA packet is 291 292 293 294T. Kivinen, et. al. [page 5] 295 296INTERNET-DRAFT 10 June 2001 297 298 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 299 +---------------+---------------+---------------+---------------+ 300 | Next Payload | RESERVED | Payload length | 301 +---------------+---------------+---------------+---------------+ 302 | ID Type | RESERVED | RESERVED | 303 +---------------+---------------+---------------+---------------+ 304 | IPv4 (4 octets) or IPv6 address (16 octets) | 305 +---------------+---------------+---------------+---------------+ 306 307The payload type for the NAT discovery payload is 131 (XXX CHANGE). 308 309The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 310ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 311Type must be zero. 312 313An example of quick mode using NAT-OA payloads is: 314 315 Initiator Responder 316 ------------ ------------ 317 HDR*, HASH(1), SA, Ni, [, KE] 318 [, IDci, IDcr ] [, NAT-OA] --> 319 <-- HDR*, HASH(2), SA, Nr, [, KE] 320 [, IDci, IDcr ] [, NAT-OA] 321 HDR*, HASH(3) 322 3235. Security Considerations 324 325Whenever changes to some fundamental parts of a security protocol are 326proposed, the examination of security implications cannot be skipped. 327Therefore, here are some observations on the effects, and whether or not 328these effects matter. This section will be expanded further in future 329versions of this draft. 330 331o IKE probe reveals NAT-Traversal support to everyone. This should not 332 be an issue. 333 334o The value of authentication mechanisms based on IP addresses 335 disappears once NATs are in the picture. That is not necessarily a 336 bad thing (for any real security, other authentication measures than 337 IP addresses should be used). This means that pre-shared-keys 338 authentication cannot be used with the main mode without group shared 339 keys for everybody behind the NAT box, which is huge security risk. 340 341o As the internal address space is only 32 bits, and it is usually very 342 sparce, it might be possible for the attacker to find out the 343 internal address used behind the NAT box by trying all possible IP- 344 addresses and trying to find the matching hash. The port numbers are 345 normally fixed to 500, and the other ends IP address is usually also 346 known. This limits the hash calculations down to 2^32. If educated 347 guess of use of private address space is done, then the number of 348 hash calculations needed to find out the internal IP address goes 349 down to the 2^24 + 2 * (2^16). 350 351 352 353T. Kivinen, et. al. [page 6] 354 355INTERNET-DRAFT 10 June 2001 356 357o The NAT-D payloads nor the Vendor ID payloads are not authenticated 358 at all in the main mode nor in the aggressive mode. This means that 359 attacker can remove those payloads, modify them or add them. By 360 removing or adding them the attacker can cause Denial Of Service 361 attacks. By modifying the NAT-D packets the attacker can cause both 362 ends to use UDP-Encapsulated modes instead of directly using tunnel 363 or transport mode, thus wasting some bandwidth. 364 365o The sending of the original source address in the Quick Mode releveas 366 the internal ip address behind the NAT to the other end. In this case 367 we have already authenticated the other end, and sending of the 368 original source address is only needed in transport mode. 369 3706. Intellectual property rights 371 372The IETF has been notified of intellectual property rights claimed in 373regard to some or all of the specification contained in this document. 374For more information consult the online list of claimed rights. 375 376SSH Communications Security Corp has notified the working group of one 377or more patents or patent applications that may be relevant to this 378internet-draft. SSH Communications Security Corp has already given a 379licence for those patents to the IETF. For more information consult the 380online list of claimed rights. 381 3827. Acknowledgments 383 384Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 385contributed to the drafts used as base for this document. 386 3878. References 388 389[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 390November 1998 391 392[RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 393for ISAKMP", November 1998 394 395[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 396Requirement Levels", March 1997 397 398[Hutt01] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 399draft-ietf-ipsec-udp-encaps-00.txt, June 2001 400 401[Dixon01] Dixon, W. et. al., "IPSec over NAT Justification for UDP 402Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt, June 4032001 404 4059. Authors' Addresses 406 407 Tero Kivinen 408 SSH Communications Security Corp 409 Fredrikinkatu 42 410 411 412T. Kivinen, et. al. [page 7] 413 414INTERNET-DRAFT 10 June 2001 415 416 FIN-00100 HELSINKI 417 Finland 418 E-mail: kivinen@ssh.fi 419 420 Markus Stenberg 421 SSH Communications Security Corp 422 Fredrikinkatu 42 423 FIN-00100 HELSINKI 424 Finland 425 E-mail: mstenber@ssh.com 426 427 Ari Huttunen 428 F-Secure Corporation 429 Tammasaarenkatu 7, 430 FIN-00181 HELSINKI 431 Finland 432 E-mail: Ari.Huttunen@F-Secure.com 433 434 William Dixon 435 Microsoft 436 One Microsoft Way 437 Redmond WA 98052 438 E-mail: wdixon@microsoft.com 439 440 Brian Swander 441 Microsoft 442 One Microsoft Way 443 Redmond WA 98052 444 E-mail: briansw@microsoft.com 445 446 Victor Volpe 447 Cisco Systems 448 124 Grove Street 449 Suite 205 450 Franklin, MA 02038 451 E-mail: vvolpe@cisco.com 452 453 Larry DiBurro 454 Nortel Networks 455 80 Central Street 456 Boxborough, MA 01719 457 ldiburro@nortelnetworks.com 458 459 460 461 462 463 464 465 466 467 468 469 470T. Kivinen, et. al. [page 8] 471