idnits 2.17.1 draft-ietf-ipsec-udp-encaps-09.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (May 5, 2004) is 7294 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) == Missing Reference: 'RFC 3715' is mentioned on line 456, but not defined == Missing Reference: 'NAT-T-IKE' is mentioned on line 319, but not defined == Missing Reference: 'RFC 3193' is mentioned on line 97, but not defined == Missing Reference: 'RFC2401' is mentioned on line 112, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'IKEv2' is mentioned on line 112, but not defined == Missing Reference: 'RFC 2406' is mentioned on line 126, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC 768' is mentioned on line 175, but not defined == Missing Reference: 'RFC 2409' is mentioned on line 151, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Missing Reference: 'RFC 3424' is mentioned on line 455, but not defined == Unused Reference: 'RFC0768' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-nat-t-ike' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC3193' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC3424' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC3715' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 502, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-13 Summary: 6 errors (**), 0 flaws (~~), 24 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Protocol Working Group A. Huttunen 3 (IPSEC) F-Secure Corporation 4 Internet-Draft B. Swander 5 Expires: November 3, 2004 Microsoft 6 V. Volpe 7 Cisco Systems 8 L. DiBurro 9 Nortel Networks 10 M. Stenberg 11 May 5, 2004 13 UDP Encapsulation of IPsec ESP Packets 14 draft-ietf-ipsec-udp-encaps-09.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 3, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This protocol specification defines methods to encapsulate and 45 decapsulate IP Encapsulating Security Payload (ESP) packets inside 46 UDP packets for the purpose of traversing Network Address 47 Translators. ESP encapsulation as defined in this document is capable 48 of being used in both IPv4 and IPv6 scenarios. The encapsulation is 49 used whenever negotiated using Internet Key Exchange (IKE). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 UDP-encapsulated ESP Header Format . . . . . . . . . . . . 4 56 2.2 IKE Header Format for Port 4500 . . . . . . . . . . . . . 4 57 2.3 NAT-keepalive Packet Format . . . . . . . . . . . . . . . 5 58 3. Encapsulation and Decapsulation Procedures . . . . . . . . . . 6 59 3.1 Auxiliary Procedures . . . . . . . . . . . . . . . . . . . 6 60 3.1.1 Tunnel Mode Decapsulation NAT Procedure . . . . . . . 6 61 3.1.2 Transport Mode Decapsulation NAT Procedure . . . . . . 6 62 3.2 Transport Mode ESP Encapsulation . . . . . . . . . . . . . 7 63 3.3 Transport Mode ESP Decapsulation . . . . . . . . . . . . . 7 64 3.4 Tunnel Mode ESP Encapsulation . . . . . . . . . . . . . . 8 65 3.5 Tunnel Mode ESP Decapsulation . . . . . . . . . . . . . . 8 66 4. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 9 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 5.1 Tunnel Mode Conflict . . . . . . . . . . . . . . . . . . . 10 69 5.2 Transport Mode Conflict . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 9.1 Normative references . . . . . . . . . . . . . . . . . . . . 16 75 9.2 Non-normative references . . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 77 A. Clarification of potential NAT multiple client solutions . . . 18 78 Intellectual Property and Copyright Statements . . . . . . . . 20 80 1. Introduction 82 This protocol specification defines methods to encapsulate and 83 decapsulate ESP packets inside UDP packets for the purpose of 84 traversing NATs (see [RFC 3715] section 2.2, case i). The UDP port 85 numbers are the same as used by IKE traffic, as defined in 86 [NAT-T-IKE]. 88 The sharing of the port numbers for both IKE and UDP encapsulated ESP 89 traffic was selected because it offers better scaling (only one NAT 90 mapping in the NAT, no need to send separate IKE keepalives), easier 91 configuration (only one port to be configured in firewalls), and 92 easier implementation. 94 It is up to the need of the clients whether transport mode or tunnel 95 mode is to be supported (see [RFC 3715] Section 3 criteria 96 "Telecommuter scenario"). L2TP/IPsec clients MUST support the modes 97 as defined in [RFC 3193]. IPsec tunnel mode clients MUST support 98 tunnel mode. 100 An IKE implementation supporting this protocol specification MUST NOT 101 use the ESP SPI field zero for ESP packets. This ensures that IKE 102 packets and ESP packets can be distinguished from each other. 104 UDP encapsulation of ESP packets as defined in this document is 105 written in terms of IPv4 headers. There is no technical reason why an 106 IPv6 header could not be used as the outer header and/or as the inner 107 header. 109 Because the protection of the outer IP addresses in IPsec AH is 110 inheritly incompatible with NAT, the IPsec AH was left out of the 111 scope of this protocol specification. This protocol also assumes that 112 IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the IPsec 113 SAs, manual keying is not supported. 115 2. Packet Formats 117 2.1 UDP-encapsulated ESP Header Format 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Source Port | Destination Port | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Length | Checksum | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | ESP header [RFC 2406] | 127 ~ ~ 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 The UDP header is a standard [RFC 768] header, where 132 o Source Port and Destination Port MUST be the same as used by IKE 133 traffic. 134 o IPv4 UDP Checksum SHOULD be transmitted as a zero value. 135 o Receivers MUST NOT depend upon the UDP checksum being a zero 136 value. 138 The SPI field in the ESP header MUST NOT be zero. 140 2.2 IKE Header Format for Port 4500 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Source Port | Destination Port | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Length | Checksum | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Non-ESP Marker | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | IKE header [RFC 2409] | 152 ~ ~ 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 The UDP header is a standard [RFC 768] header, and is used as defined 157 in [NAT-T-IKE]. This document does not set any new requirements for 158 the checksum handling of an IKE packet. 160 Non-ESP Marker is 4 bytes of zero aligning with the SPI field of an 161 ESP packet. 163 2.3 NAT-keepalive Packet Format 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Source Port | Destination Port | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Length | Checksum | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | 0xFF | 173 +-+-+-+-+-+-+-+-+ 175 The UDP header is a standard [RFC 768] header, where 176 o Source Port and Destination Port MUST be the same as used by 177 UDP-ESP encapsulation of Section 2.1 178 o IPv4 UDP Checksum SHOULD be transmitted as a zero value. 179 o Receivers MUST NOT depend upon the UDP checksum being a zero 180 value. 182 The sender MUST use a one octet long payload with the value 0xFF. The 183 receiver SHOULD ignore a received NAT-keepalive packet. 185 3. Encapsulation and Decapsulation Procedures 187 3.1 Auxiliary Procedures 189 3.1.1 Tunnel Mode Decapsulation NAT Procedure 191 When a tunnel mode has been used to transmit packets (see [RFC 3715] 192 Section 3 criteria "Mode support" and "Telecommuter scenario"), the 193 inner IP header can contain addresses that are not suitable for the 194 current network. This procedure defines how these addresses are to be 195 converted to suitable addresses for the current network. 197 Depending on local policy, one of the following MUST be done: 198 1. If a valid source IP address space has been defined in the policy 199 for the encapsulated packets from the peer, check that the source 200 IP address of the inner packet is valid according to the policy. 201 2. If an address has been assigned for the remote peer, check that 202 the source IP address used in the inner packet is the same as the 203 IP address assigned. 204 3. NAT is performed for the packet, making it suitable for transport 205 in the local network. 207 3.1.2 Transport Mode Decapsulation NAT Procedure 209 When a transport mode has been used to transmit packets, contained 210 TCP or UDP headers will contain incorrect checksums due to the change 211 of parts of the IP header during transit. This procedure defines how 212 to fix these checksums (see [RFC 3715] Section 2.1, case b). 214 Depending on local policy, one of the following MUST be done: 215 1. If the protocol header after the ESP header is a TCP/UDP header 216 and the peer's real source and destination IP address have been 217 received according to [NAT-T-IKE], incrementally recompute the 218 TCP/UDP checksum: 219 * subtract the IP source address in the received packet from the 220 checksum 221 * add the real IP source address received via IKE to the 222 checksum (obtained from the NAT-OA) 223 * subtract the IP destination address in the received packet 224 from the checksum 225 * add the real IP destination address received via IKE to the 226 checksum (obtained from the NAT-OA) 227 Note: if received and real address are the same for a given 228 address, say the source address, the operations cancel and don't 229 need to be performed. 230 2. If the protocol header after the ESP header is a TCP/UDP header, 231 recompute the checksum field in the TCP/UDP header. 233 3. If the protocol header after the ESP header is an UDP header, 234 zero the checksum field in the UDP header. If the protocol header 235 after the ESP header is a TCP header, and there is an option to 236 flag to the stack that TCP checksum does not need to be computed, 237 then that flag MAY be used. This SHOULD only be done for 238 transport mode, and if the packet is integrity protected. Tunnel 239 mode TCP checksums MUST be verified. [This is not a violation to 240 the spirit of section 4.2.2.7 in RFC 1122 because a checksum is 241 being generated by the sender, and verified by the receiver. 242 That checksum is the integrity over the packet performed by 243 IPsec.] 245 In addition an implementation MAY fix any contained protocols that 246 have been broken by NAT (see [RFC 3715] Section 2.1 case g). 248 3.2 Transport Mode ESP Encapsulation 250 BEFORE APPLYING ESP/UDP 251 ---------------------------- 252 IPv4 |orig IP hdr | | | 253 |(any options)| TCP | Data | 254 ---------------------------- 256 AFTER APPLYING ESP/UDP 257 ------------------------------------------------------- 258 IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP| 259 |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth| 260 ------------------------------------------------------- 261 |<----- encrypted ---->| 262 |<------ authenticated ----->| 264 1. Ordinary ESP encapsulation procedure is used. 265 2. A properly formatted UDP header is inserted where shown. 266 3. The Total Length, Protocol and Header Checksum (for IPv4) fields 267 in the IP header are edited to match the resulting IP packet. 269 3.3 Transport Mode ESP Decapsulation 271 1. The UDP header is removed from the packet. 272 2. The Total Length, Protocol and Header Checksum (for IPv4) fields 273 in the new IP header are edited to match the resulting IP packet. 274 3. Ordinary ESP decapsulation procedure is used. 275 4. Transport mode decapsulation NAT procedure is used. 277 3.4 Tunnel Mode ESP Encapsulation 279 BEFORE APPLYING ESP/UDP 280 ---------------------------- 281 IPv4 |orig IP hdr | | | 282 |(any options)| TCP | Data | 283 ---------------------------- 285 AFTER APPLYING ESP/UDP 286 -------------------------------------------------------------- 287 IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| 288 |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| 289 -------------------------------------------------------------- 290 |<------------ encrypted ----------->| 291 |<------------- authenticated ------------>| 293 1. Ordinary ESP encapsulation procedure is used. 294 2. A properly formatted UDP header is inserted where shown. 295 3. The Total Length, Protocol and Header Checksum (for IPv4) fields 296 in the new IP header are edited to match the resulting IP packet. 298 3.5 Tunnel Mode ESP Decapsulation 300 1. The UDP header is removed from the packet. 301 2. The Total Length, Protocol and Header Checksum (for IPv4) fields 302 in the new IP header are edited to match the resulting IP packet. 303 3. Ordinary ESP decapsulation procedure is used. 304 4. Tunnel mode decapsulation NAT procedure is used. 306 4. NAT Keepalive Procedure 308 The sole purpose of sending NAT-keepalive packets is to keep NAT 309 mappings alive for the duration of a connection between the peers 310 (see [RFC 3715] Section 2.2 case j). Reception of NAT-keepalive 311 packets MUST NOT be used to detect liveness of a connection. 313 A peer MAY send a NAT-keepalive packet if there exists one or more 314 phase I or phase II SAs between the peers, or such an SA has existed 315 at most N minutes earlier. N is a locally configurable parameter with 316 a default value of 5 minutes. 318 A peer SHOULD send a NAT-keepalive packet if a need to send such 319 packets is detected according to [NAT-T-IKE] and if no other packet 320 to the peer has been sent in M seconds. M is a locally configurable 321 parameter with a default value of 20 seconds. 323 5. Security Considerations 325 5.1 Tunnel Mode Conflict 327 Implementors are warned that it is possible for remote peers to 328 negotiate entries that overlap in a SGW (security gateway), an issue 329 affecting tunnel mode (see [RFC 3715] Section 2.1 case e). 331 +----+ \ / 332 | |-------------|----\ 333 +----+ / \ \ 334 Ari's NAT 1 \ 335 Laptop \ 336 10.1.2.3 \ 337 +----+ \ / \ +----+ +----+ 338 | |-------------|----------+------| |----------| | 339 +----+ / \ +----+ +----+ 340 Bob's NAT 2 SGW Suzy's 341 Laptop Server 342 10.1.2.3 344 Because SGW will now see two possible SAs that lead to 10.1.2.3, it 345 can become confused where to send packets coming from Suzy's server. 346 Implementators MUST devise ways of preventing such a thing from 347 occurring. 349 It is RECOMMENDED that SGW either assign locally unique IP addresses 350 to Ari's and Bob's Laptop using a protocol such as DHCP over IPsec, 351 or uses NAT to change Ari's and Bob's Laptop source IP addresses to 352 such locally unique addresses before sending packets forward to 353 Suzy's Server (this covers "Scaling" criteria of section 3 in [RFC 354 3715]). 356 Please see Appendix A 358 5.2 Transport Mode Conflict 360 Another similar issue may occur in transport mode, with 2 clients, 361 Ari and Bob, behind the same NAT talking securely to the same server 362 (see [RFC 3715] Section 2.1 case e). 364 Cliff wants to talk in the clear to the same server. 366 +----+ 367 | | 368 +----+ \ 369 Ari's \ 370 Laptop \ 371 10.1.2.3 \ 372 +----+ \ / +----+ 373 | |-----+-----------------| | 374 +----+ / \ +----+ 375 Bob's NAT Server 376 Laptop / 377 10.1.2.4 / 378 / 379 +----+ / 380 | |/ 381 +----+ 382 Cliff's 383 Laptop 384 10.1.2.5 386 Now, transport SAs on the server will look like: 388 To Ari: Server to NAT, , UDP encap <4500, Y> 390 To Bob: Server to NAT, , UDP encap <4500, Z> 392 Cliff's traffic is in the clear, so there is no SA. 394 is the protocol and port information. The UDP encap 395 ports are the ports used in UDP encapsulated ESP format of Section 396 2.1. Y,Z are the dynamic ports assigned by the NAT during the IKE 397 negotiation. So IKE traffic from Ari's laptop goes out on UDP 398 <4500,4500>. It reaches the server as UDP , where Y is the 399 dynamically assigned port. 401 If the overlaps , then simple filter 402 lookups may not be sufficient to determine which SA needs to be used 403 to send traffic. Implementations MUST handle this situation, either 404 by disallowing conflicting connections, or by other means. 406 Assume now that Cliff wants to connect to the server in the clear. 407 This is going to be difficult to configure since the server already 408 has a policy from Server to the NAT's external address, for securing 409 . For totally non-overlapping traffic descriptions, 410 this is possible. 412 Sample server policy could be: 414 To Ari: Server to NAT, All UDP, secure 416 To Bob: Server to NAT, All TCP, secure 418 To Cliff: Server to NAT, ALL ICMP, clear text 420 Note, this policy also lets Ari and Bob send cleartext ICMP to the 421 server. 423 The server sees all clients behind the NAT as the same IP address, so 424 setting up different policies for the same traffic descriptor is in 425 principle impossible. 427 A problematic example configuration on the server is: 429 Server to NAT, TCP, secure (for Ari and Bob) 431 Server to NAT, TCP, clear (for Cliff) 433 The problem is that the server cannot enforce his policy, since it is 434 possible that misbehaving Bob sends traffic in the clear. This is 435 indistinguishable from Cliff sending traffic in the clear. So it is 436 impossible to guarantee security from some clients behind a NAT, and 437 also allow clear text from different clients behind the SAME NAT. If 438 the server's security policy allows, however, it can do best effort 439 security: if the client from behind the NAT initiates security, his 440 connection will be secured. If he sends in the clear, the server will 441 still accept that clear text. 443 So, for security guarantees, the above problematic scenario MUST NOT 444 be allowed on servers. For best effort security, this scenario MAY be 445 used. 447 Please see Appendix A 449 6. IANA Considerations 451 No IANA assignments are needed. 453 7. IAB Considerations 455 The UNSAF [RFC 3424] questions are addressed by the IPsec-NAT 456 compatibility requirements document [RFC 3715]. 458 8. Acknowledgments 460 Thanks to Tero Kivinen and William Dixon who contributed actively to 461 this document. 463 Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen and Santeri 464 Paavolainen who contributed to the early drafts about NAT traversal. 466 9. References 468 9.1 Normative references 470 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 471 August 1980. 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 477 Payload (ESP)", RFC 2406, November 1998. 479 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 480 (IKE)", RFC 2409, November 1998. 482 [I-D.ietf-ipsec-nat-t-ike] 483 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 484 draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 485 2004. 487 9.2 Non-normative references 489 [RFC1122] Braden, R., "Requirements for Internet Hosts - 490 Communication Layers", STD 3, RFC 1122, October 1989. 492 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, 493 "Securing L2TP using IPsec", RFC 3193, November 2001. 495 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 496 Self-Address Fixing (UNSAF) Across Network Address 497 Translation", RFC 3424, November 2002. 499 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 500 (NAT) Compatibility Requirements", RFC 3715, March 2004. 502 [I-D.ietf-ipsec-ikev2] 503 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 504 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004. 506 Authors' Addresses 508 Ari Huttunen 509 F-Secure Corporation 510 Tammasaarenkatu 7 511 HELSINKI FIN-00181 512 FI 514 EMail: Ari.Huttunen@F-Secure.com 516 Brian Swander 517 Microsoft 518 One Microsoft Way 519 Redmond, WA 98052 520 US 522 EMail: briansw@microsoft.com 524 Victor Volpe 525 Cisco Systems 526 124 Grove Street 527 Suite 205 528 Franklin, MA 02038 529 US 531 EMail: vvolpe@cisco.com 533 Larry DiBurro 534 Nortel Networks 535 80 Central Street 536 Boxborough, MA 01719 537 US 539 EMail: ldiburro@nortelnetworks.com 541 Markus Stenberg 543 FI 545 EMail: markus.stenberg@iki.fi 547 Appendix A. Clarification of potential NAT multiple client solutions 549 This appendix provides clarification about potential solutions to the 550 problem of multiple clients behind the same NAT simultaneously 551 connecting to the same destination IP address. 553 Section 5.1 and Section 5.2 say that you MUST avoid this problem. As 554 this isn't a wire protocol matter, but a local implementation matter, 555 specification of the mechanisms do not belong in the protocol 556 specification itself. They are instead listed in this appendix. 558 Choosing an option will likely depend on the scenarios for which you 559 use/support IPsec NAT-T. This list is not meant to be exhaustive, so 560 other solutions may exist. We first describe the generic choices that 561 solve the problem for all upper layer protocols. 563 Generic choices for ESP transport mode: 565 Tr1) Implement a built-in NAT (network address translation) above 566 IPsec decapsulation. 568 Tr2) Implement a built-in NAPT (network address port translation) 569 above IPsec decapsulation. 571 Tr3) An initiator may decide not to request transport mode once NAT 572 is detected and instead request a tunnel mode SA. This may be a retry 573 after transport mode is denied by the responder, or it may be the 574 initiator's choice to propose a tunnel SA initially. This is no more 575 difficult than knowing whether to propose transport mode or tunnel 576 mode without NAT. If for some reason the responder prefers or 577 requires tunnel mode for NAT traversal, it must reject the quick mode 578 SA proposal for transport mode. 580 Generic choises for ESP tunnel mode: 582 Tn1) Same as Tr1. 584 Tn2) Same as Tr2. 586 Tn3) This option is possible if an initiator is capable of being 587 assigned an address through it's tunnel SA with the responder using 588 DHCP. The initiator may initially request an internal address via the 589 DHCP-IPsec method, regardless of whether it knows it is behind a NAT. 590 Or it may re-initiate an IKE quick mode negotiation for DHCP tunnel 591 SA after the responder fails the quick mode SA transport mode 592 proposal, either when NAT-OA payload is sent or because it discovers 593 from NAT-D the initiator is behind a NAT and it's local 594 configuration/policy will only accept connecting through NAT when 595 being assigned an address through DHCP-IPsec. 597 There are also implementation choices offereing limited 598 interoperability. Implementors should specify what applications or 599 protocols should work using their NAT-T solution if these options are 600 selected. Note that neither Tr4 nor Tn4, as described below, are 601 expected to work with TCP traffic. 603 Limited interoperability choices for ESP transport mode: 605 Tr4) Implement upper layer protocol awareness of the inbound & 606 outbound IPsec SA so that it doesn't use the source IP and the source 607 port as the session identifier. (E.g. L2TP session ID mapped to the 608 IPsec SA pair which doesn't use the UDP source port or the source IP 609 address for peer uniqueness.) 611 Tr5) Implement application integration with IKE initiation such that 612 it can rebind to a different source port if the IKE quick mode SA 613 proposal is rejected by the responder, then repropose the new QM 614 selector. 616 Limited interoperability choices for ESP tunnel mode: 618 Tn4) Same as Tr4. 620 Intellectual Property Statement 622 The IETF takes no position regarding the validity or scope of any 623 intellectual property or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; neither does it represent that it 627 has made any effort to identify any such rights. Information on the 628 IETF's procedures with respect to rights in standards-track and 629 standards-related documentation can be found in BCP-11. Copies of 630 claims of rights made available for publication and any assurances of 631 licenses to be made available, or the result of an attempt made to 632 obtain a general license or permission for the use of such 633 proprietary rights by implementors or users of this specification can 634 be obtained from the IETF Secretariat. 636 The IETF invites any interested party to bring to its attention any 637 copyrights, patents or patent applications, or other proprietary 638 rights which may cover technology that may be required to practice 639 this standard. Please address the information to the IETF Executive 640 Director. 642 The IETF has been notified of intellectual property rights claimed in 643 regard to some or all of the specification contained in this 644 document. For more information consult the online list of claimed 645 rights. 647 Full Copyright Statement 649 Copyright (C) The Internet Society (2004). All Rights Reserved. 651 This document and translations of it may be copied and furnished to 652 others, and derivative works that comment on or otherwise explain it 653 or assist in its implementation may be prepared, copied, published 654 and distributed, in whole or in part, without restriction of any 655 kind, provided that the above copyright notice and this paragraph are 656 included on all such copies and derivative works. However, this 657 document itself may not be modified in any way, such as by removing 658 the copyright notice or references to the Internet Society or other 659 Internet organizations, except as needed for the purpose of 660 developing Internet standards in which case the procedures for 661 copyrights defined in the Internet Standards process must be 662 followed, or as required to translate it into languages other than 663 English. 665 The limited permissions granted above are perpetual and will not be 666 revoked by the Internet Society or its successors or assignees. 668 This document and the information contained herein is provided on an 669 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 670 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 671 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 672 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 673 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 675 Acknowledgment 677 Funding for the RFC Editor function is currently provided by the 678 Internet Society. 680 --