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