idnits 2.17.1 draft-ietf-ipsec-nat-t-ike-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (23 October 2001) is 8192 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) ** 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. 'Hutt01' -- Possible downref: Normative reference to a draft: ref. 'Dixon01' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen, M. Stenberg 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-ipsec-nat-t-ike-01.txt A. Huttunen 4 Expires: 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 13 Negotiation of NAT-Traversal in the IKE 15 Status of This Memo 17 This document is a submission to the IETF IP Security Protocol 18 (IPSEC) Working Group. Comments are solicited and should be 19 addressed to the working group mailing list (ipsec@lists.tislabs.com) 20 or to the editor. 22 This document is an Internet-Draft and is in full conformance 23 with all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet- 33 Drafts as reference material or to cite them other than as 34 "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This document describes how to detect one or more NATs between IPsec 45 hosts, and how to negotiate the use of UDP encapsulation of the IPsec 46 packets through the NAT boxes in IKE. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 52 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3 54 3.2. Detecting presense of NAT . . . . . . . . . . . . . . . . . 3 55 4. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 5 57 4.2. Sending the original source address . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 6. Intellectual property rights . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 This document is split in two parts. The first part describes what is 67 needed in the IKE phase 1 for the NAT-Traversal support. This includes 68 detecting if the other end supports NAT-Traversal, and detecting if 69 there is one or more NAT along the path from host to host. 71 The second part describes how to negotiate the use of UDP encapsulated 72 IPsec packets in the IKE Quick Mode. It also describes how to transmit 73 the original source address to the other end if needed. The original 74 source address can be used to incrementally update the TCP/IP checksums 75 so that they will match after the NAT transform (The NAT cannot do this, 76 because the TCP/IP checksum is inside the UDP encapsulated IPsec 77 packet). 79 The document [Hutt01] describes the details of the UDP encapsulation and 80 the document [Dixon01] provides background information and motivation of 81 the NAT-Traversal in general. 83 2. Specification of Requirements 85 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 87 "OPTIONAL" to describe requirements. They are to be interpreted as 88 described in [RFC-2119] document. 90 3. Phase 1 92 The detection of the support for the NAT-Traversal and detection of the 93 NAT along the path happens in the IKE [RFC-2409] phase 1. 95 The NAT is supposed to float the IKE UDP port, and recipients MUST be 96 able to process IKE packets whose source port is different than 500. 97 There are cases where the NAT does not have to float the source port 98 (only one (IPsec) host behind the NAT or for the first IPsec host it can 99 keep the port 500, and float only the following IPsec hosts). 101 Recipients MUST reply back to the source address from the packet. This 102 also means that when the original responder is doing rekeying, or 103 sending notifications etc. to the original initiator it MUST send the 104 packets from the same set of port and IP numbers that was used when the 105 IKE SA was originally created (i.e the source and destination port and 106 IP numbers must be same). 108 For example the initiator sends packet having source and destination 109 port 500, the NAT changes that to such packet which have source port 110 12312 and destination port 500, the responder must be able to process 111 the packet whose source address is that 12312 and it must reply back 112 with packet whose source address is 500 and destination address 12312, 113 the NAT will then translate this packet to have source address 500 and 114 destination address 500. 116 3.1. Detecting support of Nat-Traversal 118 The NAT-Traversal capability of the remote host is determined by an 119 exchange of vendor strings; in Phase 1 two first messages, the vendor id 120 payload for this specification of NAT-Traversal (MD5 hash of "draft- 121 ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd 0be8a846 9579ddcc"]) MUST 122 be sent if supported (and it MUST be received by both sides) for the 123 NAT-Traversal probe to continue. 125 3.2. Detecting presense of NAT 127 The purpose of the NAT-D payload is twofold, It not only detects the 128 presence of NAT between two IKE peers, it also detects where the NAT is. 129 The location of the NAT device is important in that the keepalives need 130 to initiate from the peer "behind" the NAT. 132 To detect the NAT between the two hosts, we need to detect if the IP 133 address or the port changes along the path. This is done by sending the 134 hashes of IP address and port of both source and destination addresses 135 from each end to another. When both ends calculate those hashes and get 136 same result they know there is no NAT between. If the hashes do not 137 match, somebody translated the address or port between, meaning we need 138 to do NAT-Traversal to get IPsec packet through. 140 If the sender of the packet does not know his own IP address (in case of 141 multiple interfaces, and implementation don't know which is used to 142 route the packet out), he can include multiple local hashes to the 143 packet (as separate NAT-D payloads). In this case the NAT is detected if 144 and only if none of the hashes match. 146 The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 147 payload contains one hash, so in case of multiple hashes, multiple NAT-D 148 payloads are sent. In normal case there is only two NAT-D payloads. 150 The NAT-D payloads are included in the third and fourth packet in the 151 main mode and second and third packet in the aggressive mode. 153 The format of the NAT-D packet is 155 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 156 +---------------+---------------+---------------+---------------+ 157 | Next Payload | RESERVED | Payload length | 158 +---------------+---------------+---------------+---------------+ 159 ~ HASH of the address and port ~ 160 +---------------+---------------+---------------+---------------+ 162 The payload type for the NAT discovery payload is 130 (XXX CHANGE). 164 The HASH is calculated as follows: 166 HASH = HASH(CKY-I | CKY-R | IP | Port) 168 using the negotiated HASH algorithm. All data inside the HASH is in the 169 network byte-order. The IP is 4 octets for the IPv4 address and 16 170 octets for the IPv6 address. The port number is encoded as 2 octet 171 number in network byte-order. The first NAT-D payload contains the 172 remote ends IP address and port (i.e the destination address of the UDP 173 packet). The rest of the NAT-D payloads contain possible local end IP 174 addresses and ports (i.e all possible source addresses of the UDP 175 packet). 177 If there is no NAT between then the first NAT-D payload should match one 178 of the local NAT-D packet (i.e the local NAT-D payloads this host is 179 sending out), and the one of the other NAT-D payloads must match the 180 remote ends IP address and port. If the first check fails (i.e first 181 NAT-D payload does not match any of the local IP addresses and ports), 182 then it means that there is dynamic NAT between, and this end should 183 start sending keepalives as defined in the [Hutt01]. 185 The CKY-I and CKY-R are the initiator and responder cookies, and they 186 are added to the hash to make precomputation attacks for the IP address 187 and port impossible. 189 An example of phase 1 exchange using NAT-Traversal in main mode 190 (authentication with signatures) is: 192 Initiator Responder 193 ------------ ------------ 194 HDR, SA, VID --> 195 <-- HDR, SA, VID 196 HDR, KE, Ni, NAT-D, NAT-D --> 197 <-- HDR, KE, Nr, NAT-D, NAT-D 198 HDR*, IDii, [CERT, ] SIG_I --> 199 <-- HDR*, IDir, [ CERT, ], SIG_R 201 An example of phase 1 exchange using NAT-Traversal in aggressive mode 202 (authentication with signatures) is: 204 Initiator Responder 205 ------------ ------------ 206 HDR, SA, KE, Ni, IDii, VID --> 207 <-- HDR, SA, KE, Nr, IDir, [CERT, ], 208 VID, NAT-D, NAT-D, SIG_R 209 HDR*, [CERT, ], NAT-D, NAT-D, 210 SIG_I --> 212 4. Quick Mode 214 After the Phase 1 both ends know if there is a NAT present between. The 215 final decision of using the NAT-Traversal is left to the quick mode. The 216 use of NAT-Traversal is negotiated inside the SA payloads of the quick 217 mode. In the quick mode both ends can also send the original source 218 addresses of the IPsec packets (in case of the transport mode) to the 219 other, end so the other end has possibility to fix the TCP/IP checksum 220 field after the NAT transform. 222 This sending of the original source address is optional, and it is not 223 useful in the UDP-Encapsulated-Tunnel mode, as there is going to be 224 proper IP header inside the UDP-Encapsulated packet. In case of only 225 UDP-Encapsulated-Tunnel mode is negotiation then both ends SHOULD NOT 226 send original source address. 228 It also might be unnecessary in the transport mode if the other end can 229 turn off TCP/IP checksum verification. If the sending end knows (for 230 example from the vendor id payload) that the other end can turn off 231 TCP/IP checksum verification, he MAY leave the original source address 232 payload away. Otherwise he SHOULD send the original source address. 234 4.1. Negotiation of the NAT-Traversal encapsulation 236 The negoation of the NAT-Traversal happens by adding two new 237 encapsulation modes. These encapsulation modes are: 239 UDP-Encapsulated-Tunnel 61443 (XXX CHANGE) 240 UDP-Encapsulated-Transport 61444 (XXX CHANGE) 242 It is not normally useful to propose both normal tunnel or transport 243 mode and UDP-Encapsulated modes. If there is a NAT box between normal 244 tunnel or transport encapsulations may not work, and if there is no NAT 245 box between, there is no point of wasting bandwidth by adding UDP 246 encapsulation of packets. Because of this initiator SHOULD NOT include 247 both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP- 248 Encapsulated-Transport in its proposals. 250 4.2. Sending the original source address 252 In case of transport mode both ends SHOULD send the original source 253 address to the other end. For the tunnel mode both ends SHOULD NOT send 254 original source address to the other end. 256 The original source address of packets put to this transport mode IPsec 257 SA is sent to other end using NAT-OA (NAT Original Address) payload. 259 The NAT-OA payloads are sent inside the first and second packets of the 260 quick mode. The initiator SHOULD send the payload if it proposes any 261 UDP-Encapsulated-Transport mode and the responder SHOULD send the 262 payload only if it selected UDP-Encapsulated-Transport mode. I.e it is 263 possible that initiator send the NAT-OA payload, but proposes both UDP- 264 Encapsulated transport and tunnel mode, and then the responder selectes 265 the UDP-Encapsulated tunnel mode and do not send NAT-OA payload back. 267 A peer MUST NOT fail a negotiation if it does not receive a NAT-OA 268 payload if the NAT-OA payload only would contain redundant information. 269 I.e. only the machine(s) that are actually behind the NAT need to send 270 the NAT-OA payload. A machine with a public, non-changing IP address 271 doesn't need to send the NAT-OA payload. 273 The format of the NAT-OA packet is 275 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 276 +---------------+---------------+---------------+---------------+ 277 | Next Payload | RESERVED | Payload length | 278 +---------------+---------------+---------------+---------------+ 279 | ID Type | RESERVED | RESERVED | 280 +---------------+---------------+---------------+---------------+ 281 | IPv4 (4 octets) or IPv6 address (16 octets) | 282 +---------------+---------------+---------------+---------------+ 284 The payload type for the NAT discovery payload is 131 (XXX CHANGE). 286 The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 287 ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 288 Type must be zero. 290 An example of quick mode using NAT-OA payloads is: 292 Initiator Responder 293 ------------ ------------ 294 HDR*, HASH(1), SA, Ni, [, KE] 295 [, IDci, IDcr ] [, NAT-OA] --> 296 <-- HDR*, HASH(2), SA, Nr, [, KE] 297 [, IDci, IDcr ] [, NAT-OA] 298 HDR*, HASH(3) 300 5. Security Considerations 302 Whenever changes to some fundamental parts of a security protocol are 303 proposed, the examination of security implications cannot be skipped. 304 Therefore, here are some observations on the effects, and whether or not 305 these effects matter. This section will be expanded further in future 306 versions of this draft. 308 o IKE probe reveals NAT-Traversal support to everyone. This should not 309 be an issue. 311 o The value of authentication mechanisms based on IP addresses 312 disappears once NATs are in the picture. That is not necessarily a 313 bad thing (for any real security, other authentication measures than 314 IP addresses should be used). This means that pre-shared-keys 315 authentication cannot be used with the main mode without group shared 316 keys for everybody behind the NAT box, which is huge security risk. 318 o As the internal address space is only 32 bits, and it is usually very 319 sparce, it might be possible for the attacker to find out the 320 internal address used behind the NAT box by trying all possible IP- 321 addresses and trying to find the matching hash. The port numbers are 322 normally fixed to 500, and the cookies can be extracted from the 323 packet. This limits the hash calculations down to 2^32. If educated 324 guess of use of private address space is done, then the number of 325 hash calculations needed to find out the internal IP address goes 326 down to the 2^24 + 2 * (2^16). 328 o The NAT-D payloads nor the Vendor ID payloads are not authenticated 329 at all in the main mode nor in the aggressive mode. This means that 330 attacker can remove those payloads, modify them or add them. By 331 removing or adding them the attacker can cause Denial Of Service 332 attacks. By modifying the NAT-D packets the attacker can cause both 333 ends to use UDP-Encapsulated modes instead of directly using tunnel 334 or transport mode, thus wasting some bandwidth. 336 o The sending of the original source address in the Quick Mode releveas 337 the internal ip address behind the NAT to the other end. In this case 338 we have already authenticated the other end, and sending of the 339 original source address is only needed in transport mode. 341 6. Intellectual property rights 343 The IETF has been notified of intellectual property rights claimed in 344 regard to some or all of the specification contained in this document. 345 For more information consult the online list of claimed rights. 347 SSH Communications Security Corp has notified the working group of one 348 or more patents or patent applications that may be relevant to this 349 internet-draft. SSH Communications Security Corp has already given a 350 licence for those patents to the IETF. For more information consult the 351 online list of claimed rights. 353 7. Acknowledgments 355 Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 356 contributed to the drafts used as base for this document. 358 8. References 360 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 361 November 1998 363 [RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 364 for ISAKMP", November 1998 365 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 366 Requirement Levels", March 1997 368 [Hutt01] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 369 [Dixon01] Dixon, W. et. al., "IPSec over NAT Justification for UDP 370 Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt, June 371 2001 373 9. Authors' Addresses 375 Tero Kivinen 376 SSH Communications Security Corp 377 Fredrikinkatu 42 378 FIN-00100 HELSINKI 379 Finland 380 E-mail: kivinen@ssh.fi 382 Markus Stenberg 383 SSH Communications Security Corp 384 Fredrikinkatu 42 385 FIN-00100 HELSINKI 386 Finland 387 E-mail: mstenber@ssh.com 389 Ari Huttunen 390 F-Secure Corporation 391 Tammasaarenkatu 7, 392 FIN-00181 HELSINKI 393 Finland 394 E-mail: Ari.Huttunen@F-Secure.com 396 William Dixon 397 Microsoft 398 One Microsoft Way 399 Redmond WA 98052 400 E-mail: wdixon@microsoft.com 402 Brian Swander 403 Microsoft 404 One Microsoft Way 405 Redmond WA 98052 406 E-mail: briansw@microsoft.com 408 Victor Volpe 409 Cisco Systems 410 124 Grove Street 411 Suite 205 412 Franklin, MA 02038 413 E-mail: vvolpe@cisco.com 415 Larry DiBurro 416 Nortel Networks 417 80 Central Street 418 Boxborough, MA 01719 419 ldiburro@nortelnetworks.com