1 2IP Security Protocol Working Group (IPSEC) A. Huttunen 3INTERNET-DRAFT F-Secure Corporation 4Category: Standards track B. Swander 5Expires: December 2002 Microsoft 6 M. Stenberg 7 SSH Communications Security Corp 8 V. Volpe 9 Cisco Systems 10 L. DiBurro 11 Nortel Networks 12 June 2002 13 14 UDP Encapsulation of IPsec Packets 15 draft-ietf-ipsec-udp-encaps-03.txt 16 17Status of this Memo 18 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 21 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 26 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 31 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 34 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 37 38 This Internet-Draft will expire on December, 2002. 39 40Copyright Notice 41 42 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 44Abstract 45 46 This draft defines methods to encapsulate and decapsulate ESP 47 packets inside UDP packets for the purpose of traversing NATs. 48 49 ESP encapsulation as defined in this document is capable of being 50 used in both IPv4 and IPv6 scenarios. 51 52 The encapsulation is used whenever negotiated using IKE, as 53 defined in [Kiv02]. 54 55Change Log 56 Version -01 57 - removed everything related to the AH-protocol 58 - added instructions on how to use the encapsulation with 59 some other key management protocol than IKE 60 Version -02 61 - changed to using 4-byte non-ESP marker, removed all references 62 to using this with other key management protocols 63 - TCP checksum handling for transport mode related discussion 64 modified 65 - copied tunnel mode security considerations from the 66 earlier draft-huttunen-ipsec-esp-in-udp-00.txt draft, 67 added transport mode considerations 68 Version -03 69 - Clarifications to security considerations 70 711. Introduction 72 73 This draft defines methods to encapsulate and decapsulate ESP 74 packets inside UDP packets for the purpose of traversing NATs. 75 The UDP port numbers are the same as used by IKE traffic, as 76 defined in [Kiv02]. 77 78 It is up to the need of the clients whether transport mode 79 or tunnel mode is to be supported. L2TP/IPsec clients MUST support 80 transport mode since [RFC 3193] defines that L2TP/IPsec MUST use 81 transport mode], and IPsec tunnel mode clients MUST support tunnel 82 mode. 83 84 An IKE implementation supporting this draft MUST NOT use the 85 ESP SPI field zero for ESP packets. (XXX To be changed to 86 an IANA allocated SPI value later.) This ensures that 87 IKE packets and ESP packets can be distinguished from each other. 88 89 UDP encapsulation of ESP packets as defined in this document is 90 written in terms of IPv4 headers. There is no technical reason 91 why an IPv6 header could not be used as the outer header and/or 92 as the inner header. 93 942. Packet Formats 95 962.1 UDP-encapsulated ESP Header Format 97 98 0 1 2 3 99 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 100+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101| Source Port | Destination Port | 102+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103| Length | Checksum | 104+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105| ESP header [RFC 2406] | 106~ ~ 107| | 108+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 110The UDP header is a standard [RFC 768] header, where 111- Source Port and Destination Port are the same as used by 112 floated IKE traffic. 113- Checksum is zero. 114 115The SPI field in the ESP header must not be zero. (XXX To be 116changed to an IANA allocated SPI value later.) 117 1182.2 Floated IKE Header Format 119 120 0 1 2 3 121 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 122+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123| Source Port | Destination Port | 124+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125| Length | Checksum | 126+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127| Non-ESP Marker | 128+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129| IKE header [RFC 2409] | 130~ ~ 131| | 132+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 134The UDP header is a standard [RFC 768] header, and is used 135as defined in [Kiv02]. 136 137Non-ESP Marker is 4 bytes of zero aligning with the SPI field 138of an ESP packet. (XXX To be changed to an IANA allocated SPI 139value later.) 140 1412.3 NAT-keepalive Packet Format 142 143 0 1 2 3 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 145+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146| Source Port | Destination Port | 147+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148| Length | Checksum | 149+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150| 0xFF | 151+-+-+-+-+-+-+-+-+ 152 153The UDP header is a standard [RFC 768] header, where 154- Source Port and Destination Port are the same as used by floated 155 IKE traffic. 156- Checksum is zero. 157 158The sender SHOULD use a one octet long payload with the value 0xFF. 159The receiver SHOULD ignore a received NAT-keepalive packet. 160 1613. Encapsulation and Decapsulation Procedures 162 1633.1 Auxiliary Procedures 164 1653.1.1 Tunnel Mode Decapsulation NAT Procedure 166 167When a tunnel mode has been used to transmit packets, the inner 168IP header can contain addresses that are not suitable for the 169current network. This procedure defines how these addresses are 170to be converted to suitable addresses for the current network. 171 172Depending on local policy, one of the following MUST be done: 173a) If a valid source IP address space has been defined in the policy 174 for the encapsulated packets from the peer, check that the source 175 IP address of the inner packet is valid according to the policy. 176b) If an address has been assigned for the remote peer, check 177 that the source IP address used in the inner packet is the 178 same as the IP address assigned. 179c) NAT is performed for the packet, making it suitable for transport 180 in the local network. 181 1823.1.2 Transport Mode Decapsulation NAT Procedure 183 184When a transport mode has been used to transmit packets, contained 185TCP or UDP headers will contain incorrect checksums due to the change 186of parts of the IP header during transit. This procedure defines how 187to fix these checksums. 188 189Depending on local policy, one of the following MUST be done: 190a) If the protocol header after the ESP header is a TCP/UDP 191 header and the peer's real source IP address has been received 192 according to [Kiv02], incrementally recompute the TCP/UDP checksum: 193 - subtract the IP source address in the received packet 194 from the checksum 195 - add the real IP source address received via IKE to the checksum 196b) If the protocol header after the ESP header is a TCP/UDP 197 header, recompute the checksum field in the TCP/UDP header. 198c) If the protocol header after the ESP header is an UDP 199 header, zero the checksum field in the UDP header. If the protocol 200 header after the ESP header is a TCP header, and there is an 201 option to flag to the stack that TCP checksum does not need to 202 be computed, then that flag MAY be used. This SHOULD only be done 203 for transport mode, and if the packet is integrity protected. Tunnel 204 mode TCP checksums MUST be verified. 205 [This is not a violation to the spirit of section 4.2.2.7 in RFC 1122 206 because a checksum is being generated by the sender, and verified 207 by the receiver. That checksum is the integrity over the packet 208 performed by IPsec.] 209 210In addition an implementation MAY fix any contained protocols that 211have been broken by NAT. 212 2133.2 Transport Mode ESP Encapsulation 214 215 BEFORE APPLYING ESP/UDP 216 ---------------------------- 217 IPv4 |orig IP hdr | | | 218 |(any options)| TCP | Data | 219 ---------------------------- 220 221 AFTER APPLYING ESP/UDP 222 ------------------------------------------------------- 223 IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP| 224 |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth| 225 ------------------------------------------------------- 226 |<----- encrypted ---->| 227 |<------ authenticated ----->| 228 2291) Ordinary ESP encapsulation procedure is used. 2302) A properly formatted UDP header is inserted where shown. 2313) The Total Length, Protocol and Header Checksum fields in the 232 IP header are edited to match the resulting IP packet. 233 2343.3 Transport Mode ESP Decapsulation 235 2361) The UDP header is removed from the packet. 2372) The Total Length, Protocol and Header Checksum fields in the 238 new IP header are edited to match the resulting IP packet. 2393) Ordinary ESP decapsulation procedure is used. 2404) Transport mode decapsulation NAT procedure is used. 241 242 2433.4 Tunnel Mode ESP Encapsulation 244 245 BEFORE APPLYING ESP/UDP 246 ---------------------------- 247 IPv4 |orig IP hdr | | | 248 |(any options)| TCP | Data | 249 ---------------------------- 250 251 AFTER APPLYING ESP/UDP 252 -------------------------------------------------------------- 253IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| 254 |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| 255 -------------------------------------------------------------- 256 |<------------ encrypted ----------->| 257 |<------------- authenticated ------------>| 258 2591) Ordinary ESP encapsulation procedure is used. 2602) A properly formatted UDP header is inserted where shown. 2613) The Total Length, Protocol and Header Checksum fields in the 262 new IP header are edited to match the resulting IP packet. 263 264 2653.5 Tunnel Mode ESP Decapsulation 266 2671) The UDP header is removed from the packet. 2682) The Total Length, Protocol and Header Checksum fields in the 269 new IP header are edited to match the resulting IP packet. 2703) Ordinary ESP decapsulation procedure is used. 2714) Tunnel mode decapsulation NAT procedure is used. 272 2734. NAT Keepalive Procedure 274 275The sole purpose of sending NAT-keepalive packets is to keep 276NAT mappings alive for the duration of a connection between 277the peers. Reception of NAT-keepalive packets MUST NOT be 278used to detect liveness of a connection. 279 280A peer MAY send a NAT-keepalive packet if there exists one 281or more phase I or phase II SAs between the peers, or such 282an SA has existed at most N minutes earlier. N is a locally 283configurable parameter with a default value of 5 minutes. 284 285A peer SHOULD send a NAT-keepalive packet if a need to send such 286packets is detected according to [Kiv02] and if no other packet to 287the peer has been sent in M seconds. M is a locally configurable 288parameter with a default value of 20 seconds. 289 2905. Security Considerations 291 2925.1 DoS 293 294 On some systems ESPUDP may have DoS attack consequences, 295 especially if ordinary operating system UDP-functionality is 296 being used. It may be recommended not to open an ordinary UDP-port 297 for this. 298 2995.2 Tunnel Mode Conflict 300 301 Implementors are warned that it is possible for remote peers to 302 negotiate entries that overlap in a GW, an issue affecting tunnel 303 mode. 304 305 +----+ \ / 306 | |-------------|----\ 307 +----+ / \ \ 308 Ari's NAT 1 \ 309 Laptop \ 310 10.1.2.3 \ 311 +----+ \ / \ +----+ +----+ 312 | |-------------|----------+------| |----------| | 313 +----+ / \ +----+ +----+ 314 Bob's NAT 2 GW Suzy's 315 Laptop Server 316 10.1.2.3 317 318 Because GW will now see two possible SAs that lead to 10.1.2.3, it 319 can become confused where to send packets coming from Suzy's server. 320 Implementators MUST devise ways of preventing such a thing from 321 occurring. 322 323 It is recommended that GW either assign locally unique IP addresses 324 to A and B using a protocol such as DHCP over IPsec, or uses NAT to 325 change A's and B's source IP addresses to such locally unique 326 addresses before sending packets forward to S. 327 3285.3 Transport Mode Conflict 329 330 Another similar issue may occur in transport mode, with 2 clients, 331 Ari and Bob, behind the same NAT talking securely to the same server. 332 333 Cliff wants to talk in the clear to the same server. 334 335 +----+ 336 | | 337 +----+ \ 338 Ari's \ 339 Laptop \ 340 10.1.2.3 \ 341 +----+ \ / +----+ 342 | |-----+-----------------| | 343 +----+ / \ +----+ 344 Bob's NAT Server 345 Laptop / 346 10.1.2.4 / 347 / 348 +----+ / 349 | |/ 350 +----+ 351 Cliff's 352 Laptop 353 10.1.2.5 354 355 356 357 Now, transport SAs on the server will look like: 358 To Ari: S to NAT, <traffic desc1>, UDP encap <4500, Y> 359 To Bob: S to NAT, <traffic desc2>, UDP encap <4500, Z> 360 361 Cliff's traffic is in the clear, so there is no SA. 362 363 <traffic desc> is the protocol and port information. 364 The UDP encap ports are the ports used in UDP encapsulated 365 ESP format of section 2.1. Y,Z are the dynamic ports assigned 366 by the NAT during the IKE negotiation. So IKE traffic from 367 Ari's laptop goes out on UDP <4500,4500>. It reaches the server 368 as UDP <Y,4500>, where Y is the dynamically assigned port. 369 370 If the <traffic desc1> overlaps <traffic desc2>, then 371 simple filter lookups may not be sufficient to determine 372 which SA needs to be used to send traffic. Implementations 373 MUST handle this situation, either by disallowing 374 conflicting connections, or by other means. 375 376 Assume now that Cliff wants to connect to the server S in the 377 clear. This is going to be difficult to configure since 378 the server already has a policy from S to the NAT's external 379 address, for securing <traffic desc>. For totally non-overlapping 380 traffic descriptions, this is possible. 381 382 Sample server policy could be: 383 To Ari: S to NAT, All UDP, secure 384 To Bob: S to NAT, All TCP, secure 385 To Cliff: S to NAT, ALL ICMP, clear text 386 387 Note, this policy also lets Ari and Bob send cleartext ICMP to the 388 server. 389 390 The server sees all clients behind the NAT as the same IP address, 391 so setting up different policies for the same traffic descriptor 392 is in principle impossible. 393 394 A problematic example configuration on the server is: 395 396 S to NAT, TCP, secure (for Ari and Bob) 397 S to NAT, TCP, clear (for Cliff) 398 399 The problem is that the server cannot enforce his policy, since it 400 is possible that misbehaving Bob sends traffic in the clear. This 401 is indistinguishable from Cliff sending traffic in the clear. 402 So it is impossible to guarantee security from some clients behind 403 a NAT, and also allow clear text from different clients behind the 404 SAME NAT. If the server's security policy allows, however, it can 405 do best effort security: if the client from behind the NAT 406 initiates security, his connection will be secured. If he sends 407 in the clear, the server will still accept that clear text. 408 409 So, for security guarantees, the above problematic scenario MUST NOT 410 be allowed on servers. For best effort security, this scenario MAY 411 be used. 412 4136. Intellectual Property Rights 414 415The IETF has been notified of intellectual property rights claimed in 416regard to some or all of the specification contained in this document. 417For more information consult the online list of claimed rights. 418 419SSH Communications Security Corp has notified the working group of one 420or more patents or patent applications that may be relevant to this 421internet-draft. SSH Communications Security Corp has already given a 422licence for those patents to the IETF. For more information consult the 423online list of claimed rights. 424 4257. Acknowledgments 426 427Thanks to Tero Kivinen and William Dixon who contributed actively 428to this document. 429 430Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen and 431Santeri Paavolainen who contributed to the previous drafts 432about NAT traversal. 433 4348. References 435 436[RFC 768] Postel, J., "User Datagram Protocol", August 1980 437 438[RFC 1122] R. Braden (Editor), "Requirements for Internet Hosts 439-- Communication Layers", October 1989 440 441[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 442Requirement Levels", March 1997 443 444[RFC 2406] Kent, S., "IP Encapsulating Security Payload (ESP)", 445November 1998 446 447[RFC 2409] D. Harkins, D. Carrel, "The Internet Key Exchange 448(IKE)", November 1998 449 450[RFC 3193] Patel, B. et. al, "Securing L2TP using IPsec", 451November 2001 452 453[Kiv02] Kivinen, T. et. al., draft-ietf-ipsec-nat-t-ike-02.txt, 454"Negotiation of NAT-Traversal in the IKE", April 2002 455 456 4579. Authors' Addresses 458 459 Ari Huttunen 460 F-Secure Corporation 461 Tammasaarenkatu 7 462 FIN-00181 HELSINKI 463 Finland 464 E-mail: Ari.Huttunen@F-Secure.com 465 466 Brian Swander 467 Microsoft 468 One Microsoft Way 469 Redmond WA 98052 470 E-mail: briansw@microsoft.com 471 472 Markus Stenberg 473 SSH Communications Security Corp 474 Fredrikinkatu 42 475 FIN-00100 HELSINKI 476 Finland 477 E-mail: mstenber@ssh.com 478 479 Victor Volpe 480 Cisco Systems 481 124 Grove Street 482 Suite 205 483 Franklin, MA 02038 484 E-mail: vvolpe@cisco.com 485 486 Larry DiBurro 487 Nortel Networks 488 80 Central Street 489 Boxborough, MA 01719 490 ldiburro@nortelnetworks.com 491