idnits 2.17.1 draft-ietf-ipsec-udp-encaps-08.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 (February 16, 2004) is 7368 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 3193' is mentioned on line 88, but not defined == Missing Reference: 'RFC 2406' is mentioned on line 465, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC 768' is mentioned on line 163, but not defined == Missing Reference: 'RFC 2409' is mentioned on line 139, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Unused Reference: 'RFC0768' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC3193' is defined on line 505, 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) Summary: 5 errors (**), 0 flaws (~~), 14 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: August 16, 2004 Microsoft 6 V. Volpe 7 Cisco Systems 8 L. DiBurro 9 Nortel Networks 10 M. Stenberg 11 February 16, 2004 13 UDP Encapsulation of IPsec Packets 14 draft-ietf-ipsec-udp-encaps-08.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 August 16, 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 . . . . . . . . . . . . . . 8 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 72 Normative references . . . . . . . . . . . . . . . . . . . . 15 73 Non-normative references . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 75 A. Clarification of potential NAT multiple client solutions . . 18 76 Intellectual Property and Copyright Statements . . . . . . . 20 78 1. Introduction 80 This protocol specification defines methods to encapsulate and 81 decapsulate ESP packets inside UDP packets for the purpose of 82 traversing NATs (see [Aboda03] section 2.2, case i). The UDP port 83 numbers are the same as used by IKE traffic, as defined in [Kiv04]. 85 It is up to the need of the clients whether transport mode or tunnel 86 mode is to be supported (see [Aboda03] Section 3 criteria 87 "Telecommuter scenario"). L2TP/IPsec clients MUST support the modes 88 as defined in [RFC 3193]. IPsec tunnel mode clients MUST support 89 tunnel mode. 91 An IKE implementation supporting this protocol specification MUST NOT 92 use the ESP SPI field zero for ESP packets. This ensures that IKE 93 packets and ESP packets can be distinguished from each other. 95 UDP encapsulation of ESP packets as defined in this document is 96 written in terms of IPv4 headers. There is no technical reason why an 97 IPv6 header could not be used as the outer header and/or as the inner 98 header. 100 2. Packet Formats 102 2.1 UDP-encapsulated ESP Header Format 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Source Port | Destination Port | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Length | Checksum | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | ESP header [RFC 2406] | 112 ~ ~ 113 | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 The UDP header is a standard [RFC 768] header, where 118 o Source Port and Destination Port MUST be the same as used by IKE 119 traffic. 121 o IPv4 UDP Checksum SHOULD be transmitted as a zero value. 123 o Receivers MUST NOT depend upon the UDP checksum being a zero 124 value. 126 The SPI field in the ESP header MUST NOT be zero. 128 2.2 IKE Header Format for Port 4500 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Source Port | Destination Port | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Length | Checksum | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Non-ESP Marker | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | IKE header [RFC 2409] | 140 ~ ~ 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 The UDP header is a standard [RFC 768] header, and is used as defined 145 in [Kiv04]. This document does not set any new requirements for the 146 checksum handling of an IKE packet. 148 Non-ESP Marker is 4 bytes of zero aligning with the SPI field of an 149 ESP packet. 151 2.3 NAT-keepalive Packet Format 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Source Port | Destination Port | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Length | Checksum | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | 0xFF | 161 +-+-+-+-+-+-+-+-+ 163 The UDP header is a standard [RFC 768] header, where 165 o Source Port and Destination Port MUST be the same as used by 166 UDP-ESP encapsulation of Section 2.1 168 o IPv4 UDP Checksum SHOULD be transmitted as a zero value. 170 o Receivers MUST NOT depend upon the UDP checksum being a zero 171 value. 173 The sender MUST use a one octet long payload with the value 0xFF. The 174 receiver SHOULD ignore a received NAT-keepalive packet. 176 3. Encapsulation and Decapsulation Procedures 178 3.1 Auxiliary Procedures 180 3.1.1 Tunnel Mode Decapsulation NAT Procedure 182 When a tunnel mode has been used to transmit packets (see [Aboda03] 183 Section 3 criteria "Mode support" and "Telecommuter scenario"), the 184 inner IP header can contain addresses that are not suitable for the 185 current network. This procedure defines how these addresses are to be 186 converted to suitable addresses for the current network. 188 Depending on local policy, one of the following MUST be done: 190 1. If a valid source IP address space has been defined in the policy 191 for the encapsulated packets from the peer, check that the source 192 IP address of the inner packet is valid according to the policy. 194 2. If an address has been assigned for the remote peer, check that 195 the source IP address used in the inner packet is the same as the 196 IP address assigned. 198 3. NAT is performed for the packet, making it suitable for transport 199 in the local network. 201 3.1.2 Transport Mode Decapsulation NAT Procedure 203 When a transport mode has been used to transmit packets, contained 204 TCP or UDP headers will contain incorrect checksums due to the change 205 of parts of the IP header during transit. This procedure defines how 206 to fix these checksums (see [Aboda03] Section 2.1, case b). 208 Depending on local policy, one of the following MUST be done: 210 1. If the protocol header after the ESP header is a TCP/UDP header 211 and the peer's real source and destination IP address have been 212 received according to [Kiv04], incrementally recompute the TCP/ 213 UDP checksum: 215 * subtract the IP source address in the received packet from the 216 checksum 218 * add the real IP source address received via IKE to the 219 checksum (obtained from the NAT-OA) 221 * subtract the IP destination address in the received packet 222 from the checksum 224 * add the real IP destination address received via IKE to the 225 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. 231 2. If the protocol header after the ESP header is a TCP/UDP header, 232 recompute the checksum field in the TCP/UDP header. 234 3. If the protocol header after the ESP header is an UDP header, 235 zero the checksum field in the UDP header. If the protocol header 236 after the ESP header is a TCP header, and there is an option to 237 flag to the stack that TCP checksum does not need to be computed, 238 then that flag MAY be used. This SHOULD only be done for 239 transport mode, and if the packet is integrity protected. Tunnel 240 mode TCP checksums MUST be verified. [This is not a violation to 241 the spirit of section 4.2.2.7 in RFC 1122 because a checksum is 242 being generated by the sender, and verified by the receiver. 243 That checksum is the integrity over the packet performed by 244 IPsec.] 246 In addition an implementation MAY fix any contained protocols that 247 have been broken by NAT (see [Aboda03] Section 2.1 case g). 249 3.2 Transport Mode ESP Encapsulation 251 BEFORE APPLYING ESP/UDP 252 ---------------------------- 253 IPv4 |orig IP hdr | | | 254 |(any options)| TCP | Data | 255 ---------------------------- 257 AFTER APPLYING ESP/UDP 258 ------------------------------------------------------- 259 IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP| 260 |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth| 261 ------------------------------------------------------- 262 |<----- encrypted ---->| 263 |<------ authenticated ----->| 265 1. Ordinary ESP encapsulation procedure is used. 267 2. A properly formatted UDP header is inserted where shown. 269 3. The Total Length, Protocol and Header Checksum fields in the IP 270 header are edited to match the resulting IP packet. 272 3.3 Transport Mode ESP Decapsulation 274 1. The UDP header is removed from the packet. 276 2. The Total Length, Protocol and Header Checksum fields in the new 277 IP header are edited to match the resulting IP packet. 279 3. Ordinary ESP decapsulation procedure is used. 281 4. Transport mode decapsulation NAT procedure is used. 283 3.4 Tunnel Mode ESP Encapsulation 285 BEFORE APPLYING ESP/UDP 286 ---------------------------- 287 IPv4 |orig IP hdr | | | 288 |(any options)| TCP | Data | 289 ---------------------------- 291 AFTER APPLYING ESP/UDP 292 -------------------------------------------------------------- 293 IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| 294 |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| 295 -------------------------------------------------------------- 296 |<------------ encrypted ----------->| 297 |<------------- authenticated ------------>| 299 1. Ordinary ESP encapsulation procedure is used. 301 2. A properly formatted UDP header is inserted where shown. 303 3. The Total Length, Protocol and Header Checksum fields in the new 304 IP header are edited to match the resulting IP packet. 306 3.5 Tunnel Mode ESP Decapsulation 308 1. The UDP header is removed from the packet. 310 2. The Total Length, Protocol and Header Checksum fields in the new 311 IP header are edited to match the resulting IP packet. 313 3. Ordinary ESP decapsulation procedure is used. 315 4. Tunnel mode decapsulation NAT procedure is used. 317 4. NAT Keepalive Procedure 319 The sole purpose of sending NAT-keepalive packets is to keep NAT 320 mappings alive for the duration of a connection between the peers 321 (see [Aboda03] Section 2.2 case j). Reception of NAT-keepalive 322 packets MUST NOT be used to detect liveness of a connection. 324 A peer MAY send a NAT-keepalive packet if there exists one or more 325 phase I or phase II SAs between the peers, or such an SA has existed 326 at most N minutes earlier. N is a locally configurable parameter with 327 a default value of 5 minutes. 329 A peer SHOULD send a NAT-keepalive packet if a need to send such 330 packets is detected according to [Kiv04] and if no other packet to 331 the peer has been sent in M seconds. M is a locally configurable 332 parameter with a default value of 20 seconds. 334 5. Security Considerations 336 5.1 Tunnel Mode Conflict 338 Implementors are warned that it is possible for remote peers to 339 negotiate entries that overlap in a SGW (security gateway), an issue 340 affecting tunnel mode (see [Aboda03] Section 2.1 case e). 342 +----+ \ / 343 | |-------------|----\ 344 +----+ / \ \ 345 Ari's NAT 1 \ 346 Laptop \ 347 10.1.2.3 \ 348 +----+ \ / \ +----+ +----+ 349 | |-------------|----------+------| |----------| | 350 +----+ / \ +----+ +----+ 351 Bob's NAT 2 SGW Suzy's 352 Laptop Server 353 10.1.2.3 355 Because SGW will now see two possible SAs that lead to 10.1.2.3, it 356 can become confused where to send packets coming from Suzy's server. 357 Implementators MUST devise ways of preventing such a thing from 358 occurring. 360 It is RECOMMENDED that SGW either assign locally unique IP addresses 361 to Ari's and Bob's Laptop using a protocol such as DHCP over IPsec, 362 or uses NAT to change Ari's and Bob's Laptop source IP addresses to 363 such locally unique addresses before sending packets forward to 364 Suzy's Server (this covers "Scaling" criteria of section 3 in 365 [Aboda03]). 367 Please see Appendix A 369 5.2 Transport Mode Conflict 371 Another similar issue may occur in transport mode, with 2 clients, 372 Ari and Bob, behind the same NAT talking securely to the same server 373 (see [Aboda03] Section 2.1 case e). 375 Cliff wants to talk in the clear to the same server. 377 +----+ 378 | | 379 +----+ \ 380 Ari's \ 381 Laptop \ 382 10.1.2.3 \ 383 +----+ \ / +----+ 384 | |-----+-----------------| | 385 +----+ / \ +----+ 386 Bob's NAT Server 387 Laptop / 388 10.1.2.4 / 389 / 390 +----+ / 391 | |/ 392 +----+ 393 Cliff's 394 Laptop 395 10.1.2.5 397 Now, transport SAs on the server will look like: 399 To Ari: Server to NAT, , UDP encap <4500, Y> 401 To Bob: Server to NAT, , UDP encap <4500, Z> 403 Cliff's traffic is in the clear, so there is no SA. 405 is the protocol and port information. The UDP encap 406 ports are the ports used in UDP encapsulated ESP format of Section 407 2.1. Y,Z are the dynamic ports assigned by the NAT during the IKE 408 negotiation. So IKE traffic from Ari's laptop goes out on UDP 409 <4500,4500>. It reaches the server as UDP , where Y is the 410 dynamically assigned port. 412 If the overlaps , then simple filter 413 lookups may not be sufficient to determine which SA needs to be used 414 to send traffic. Implementations MUST handle this situation, either 415 by disallowing conflicting connections, or by other means. 417 Assume now that Cliff wants to connect to the server in the clear. 418 This is going to be difficult to configure since the server already 419 has a policy from Server to the NAT's external address, for securing 420 . For totally non-overlapping traffic descriptions, 421 this is possible. 423 Sample server policy could be: 425 To Ari: Server to NAT, All UDP, secure 427 To Bob: Server to NAT, All TCP, secure 429 To Cliff: Server to NAT, ALL ICMP, clear text 431 Note, this policy also lets Ari and Bob send cleartext ICMP to the 432 server. 434 The server sees all clients behind the NAT as the same IP address, so 435 setting up different policies for the same traffic descriptor is in 436 principle impossible. 438 A problematic example configuration on the server is: 440 Server to NAT, TCP, secure (for Ari and Bob) 442 Server to NAT, TCP, clear (for Cliff) 444 The problem is that the server cannot enforce his policy, since it is 445 possible that misbehaving Bob sends traffic in the clear. This is 446 indistinguishable from Cliff sending traffic in the clear. So it is 447 impossible to guarantee security from some clients behind a NAT, and 448 also allow clear text from different clients behind the SAME NAT. If 449 the server's security policy allows, however, it can do best effort 450 security: if the client from behind the NAT initiates security, his 451 connection will be secured. If he sends in the clear, the server will 452 still accept that clear text. 454 So, for security guarantees, the above problematic scenario MUST NOT 455 be allowed on servers. For best effort security, this scenario MAY be 456 used. 458 Please see Appendix A 460 6. IANA Considerations 462 No IANA assignments are needed. 464 This document depends on the reserved SPI value of zero (0) not being 465 sent over the wire as a part of an ESP-packet [RFC 2406]. 467 This document defines a "Non-ESP Marker" as 4 bytes of zero aligning 468 with the SPI field of an ESP packet, and generally being followed by 469 something that is not an ESP packet. 471 With regard to NAT-traversal in IKE case, the Non-ESP Marker is being 472 followed by an IKE packet as specified in Section 2.2. 474 7. Acknowledgments 476 Thanks to Tero Kivinen and William Dixon who contributed actively to 477 this document. 479 Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen and Santeri 480 Paavolainen who contributed to the early drafts about NAT traversal. 482 Normative references 484 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 485 August 1980. 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 491 Payload (ESP)", RFC 2406, November 1998. 493 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 494 (IKE)", RFC 2409, November 1998. 496 [Kiv04] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe, 497 "Negotiation of NAT-Traversal in the IKE", ID 498 draft-ietf-ipsec-nat-t-ike-08.txt, Februart 2004. 500 Non-normative references 502 [RFC1122] Braden, R., "Requirements for Internet Hosts - 503 Communication Layers", STD 3, RFC 1122, October 1989. 505 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, 506 "Securing L2TP using IPsec", RFC 3193, November 2001. 508 [Aboda03] Aboda, B. and W. Dixon, "IPsec-NAT Compatibility 509 Requirements", ID draft-ietf-ipsec-nat-reqts-06.txt. 511 Authors' Addresses 513 Ari Huttunen 514 F-Secure Corporation 515 Tammasaarenkatu 7 516 HELSINKI FIN-00181 517 FI 519 EMail: Ari.Huttunen@F-Secure.com 521 Brian Swander 522 Microsoft 523 One Microsoft Way 524 Redmond, WA 98052 525 US 527 EMail: briansw@microsoft.com 529 Victor Volpe 530 Cisco Systems 531 124 Grove Street 532 Suite 205 533 Franklin, MA 02038 534 US 536 EMail: vvolpe@cisco.com 537 Larry DiBurro 538 Nortel Networks 539 80 Central Street 540 Boxborough, MA 01719 541 US 543 EMail: ldiburro@nortelnetworks.com 545 Markus Stenberg 547 FI 549 EMail: markus.stenberg@iki.fi 551 Appendix A. Clarification of potential NAT multiple client solutions 553 This appendix provides clarification about potential solutions to the 554 problem of multiple clients behind the same NAT simultaneously 555 connecting to the same destination IP address. 557 Section 5.1 and Section 5.2 say that you MUST avoid this problem. As 558 this isn't a wire protocol matter, but a local implementation matter, 559 specification of the mechanisms do not belong in the protocol 560 specification itself. They are instead listed in this appendix. 562 Choosing an option will likely depend on the scenarios for which you 563 use/support IPsec NAT-T. This list is not meant to be exhaustive, so 564 other solutions may exist. We first describe the generic choices that 565 solve the problem for all upper layer protocols. 567 Generic choices for ESP transport mode: 569 Tr1) Implement a built-in NAT (network address translation) above 570 IPsec decapsulation. 572 Tr2) Implement a built-in NAPT (network address port translation) 573 above IPsec decapsulation. 575 Tr3) An initiator may decide not to request transport mode once NAT 576 is detected and instead request a tunnel mode SA. This may be a retry 577 after transport mode is denied by the responder, or it may be the 578 initiator's choice to propose a tunnel SA initially. This is no more 579 difficult than knowing whether to propose transport mode or tunnel 580 mode without NAT. If for some reason the responder prefers or 581 requires tunnel mode for NAT traversal, it must reject the quick mode 582 SA proposal for transport mode. 584 Generic choises for ESP tunnel mode: 586 Tn1) Same as Tr1. 588 Tn2) Same as Tr2. 590 Tn3) This option is possible if an initiator is capable of being 591 assigned an address through it's tunnel SA with the responder using 592 DHCP. The initiator may initially request an internal address via the 593 DHCP-IPsec method, regardless of whether it knows it is behind a NAT. 594 Or it may re-initiate an IKE quick mode negotiation for DHCP tunnel 595 SA after the responder fails the quick mode SA transport mode 596 proposal, either when NAT-OA payload is sent or because it discovers 597 from NAT-D the initiator is behind a NAT and it's local 598 configuration/policy will only accept connecting through NAT when 599 being assigned an address through DHCP-IPsec. 601 There are also implementation choices offereing limited 602 interoperability. Implementors should specify what applications or 603 protocols should work using their NAT-T solution if these options are 604 selected. Note that neither Tr4 nor Tn4, as described below, are 605 expected to work with TCP traffic. 607 Limited interoperability choices for ESP transport mode: 609 Tr4) Implement upper layer protocol awareness of the inbound & 610 outbound IPsec SA so that it doesn't use the source IP and the source 611 port as the session identifier. (E.g. L2TP session ID mapped to the 612 IPsec SA pair which doesn't use the UDP source port or the source IP 613 address for peer uniqueness.) 615 Tr5) Implement application integration with IKE initiation such that 616 it can rebind to a different source port if the IKE quick mode SA 617 proposal is rejected by the responder, then repropose the new QM 618 selector. 620 Limited interoperability choices for ESP tunnel mode: 622 Tn4) Same as Tr4. 624 Intellectual Property Statement 626 The IETF takes no position regarding the validity or scope of any 627 intellectual property or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; neither does it represent that it 631 has made any effort to identify any such rights. Information on the 632 IETF's procedures with respect to rights in standards-track and 633 standards-related documentation can be found in BCP-11. Copies of 634 claims of rights made available for publication and any assurances of 635 licenses to be made available, or the result of an attempt made to 636 obtain a general license or permission for the use of such 637 proprietary rights by implementors or users of this specification can 638 be obtained from the IETF Secretariat. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights which may cover technology that may be required to practice 643 this standard. Please address the information to the IETF Executive 644 Director. 646 The IETF has been notified of intellectual property rights claimed in 647 regard to some or all of the specification contained in this 648 document. For more information consult the online list of claimed 649 rights. 651 Full Copyright Statement 653 Copyright (C) The Internet Society (2004). All Rights Reserved. 655 This document and translations of it may be copied and furnished to 656 others, and derivative works that comment on or otherwise explain it 657 or assist in its implementation may be prepared, copied, published 658 and distributed, in whole or in part, without restriction of any 659 kind, provided that the above copyright notice and this paragraph are 660 included on all such copies and derivative works. However, this 661 document itself may not be modified in any way, such as by removing 662 the copyright notice or references to the Internet Society or other 663 Internet organizations, except as needed for the purpose of 664 developing Internet standards in which case the procedures for 665 copyrights defined in the Internet Standards process must be 666 followed, or as required to translate it into languages other than 667 English. 669 The limited permissions granted above are perpetual and will not be 670 revoked by the Internet Society or its successors or assignees. 672 This document and the information contained herein is provided on an 673 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 674 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 675 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 676 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 677 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Acknowledgment 681 Funding for the RFC Editor function is currently provided by the 682 Internet Society.