idnits 2.17.1 draft-ietf-ipsec-udp-encaps-06.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 600 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 == Line 420 has weird spacing: '... do best e...' == 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 (January 2003) is 7744 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) == Unused Reference: 'RFC 1122' is defined on line 475, 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 (-08) exists of draft-ietf-ipsec-nat-t-ike-05 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) A. Huttunen 2 INTERNET-DRAFT F-Secure Corporation 3 Category: Standards track B. Swander 4 Expires: July 2003 Microsoft 5 M. Stenberg 6 SSH Communications Security Corp 7 V. Volpe 8 Cisco Systems 9 L. DiBurro 10 Nortel Networks 11 January 2003 13 UDP Encapsulation of IPsec Packets 14 draft-ietf-ipsec-udp-encaps-06.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 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July, 2003. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This draft defines methods to encapsulate and decapsulate 46 IP Encapsulating Security Payload (ESP) packets inside UDP packets 47 for the purpose of traversing Network Address Translators. 48 ESP encapsulation as defined in this document is capable of being 49 used in both IPv4 and IPv6 scenarios. The encapsulation is used 50 whenever negotiated using Internet Key Exchange (IKE). 52 Change Log 53 Version -01 54 - removed everything related to the AH-protocol 55 - added instructions on how to use the encapsulation with 56 some other key management protocol than IKE 57 Version -02 58 - changed to using 4-byte non-ESP marker, removed all references 59 to using this with other key management protocols 60 - TCP checksum handling for transport mode related discussion 61 modified 62 - copied tunnel mode security considerations from the 63 earlier draft-huttunen-ipsec-esp-in-udp-00.txt draft, 64 added transport mode considerations 65 Version -03 66 - Clarifications to security considerations 67 Version -04 68 - Clarified checksum handling 69 - Added an IANA considerations section 70 - Added an implementation options appendix 71 - Reworded 'Abstract' 72 - References grouped 73 Version -05 74 - Changed incremental checksum fixup for transport mode 75 Version -06 76 - Changed in 'Introduction' the text relating to 77 L2TP/IPsec modes 78 - [RFC 2119] to normative references 80 1. Introduction 82 This draft defines methods to encapsulate and decapsulate ESP 83 packets inside UDP packets for the purpose of traversing NATs. 84 The UDP port numbers are the same as used by IKE traffic, as 85 defined in [Kiv05]. 87 It is up to the need of the clients whether transport mode 88 or tunnel mode is to be supported. L2TP/IPsec clients must support 89 the modes as defined in [RFC 3193]. IPsec tunnel mode clients MUST 90 support tunnel mode. 92 An IKE implementation supporting this draft MUST NOT use the 93 ESP SPI field zero for ESP packets. This ensures that 94 IKE packets and ESP packets can be distinguished from each other. 96 UDP encapsulation of ESP packets as defined in this document is 97 written in terms of IPv4 headers. There is no technical reason 98 why an IPv6 header could not be used as the outer header and/or 99 as the inner header. 101 2. Packet Formats 103 2.1 UDP-encapsulated ESP Header Format 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Source Port | Destination Port | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Length | Checksum | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | ESP header [RFC 2406] | 113 ~ ~ 114 | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 The UDP header is a standard [RFC 768] header, where 118 - Source Port and Destination Port MUST be the same as used by 119 floated IKE traffic. 120 - Checksum SHOULD be transmitted as a zero value. 121 - Receivers MUST NOT depend upon the UDP checksum being 122 a zero value. 124 The SPI field in the ESP header must not be zero. 126 2.2 Floated IKE Header Format 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Source Port | Destination Port | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Length | Checksum | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Non-ESP Marker | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | IKE header [RFC 2409] | 138 ~ ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 The UDP header is a standard [RFC 768] header, and is used 143 as defined in [Kiv05]. This document does not set any new 144 requirements for the checksum handling of an IKE packet. 146 Non-ESP Marker is 4 bytes of zero aligning with the SPI field 147 of an ESP packet. 149 2.3 NAT-keepalive Packet Format 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Source Port | Destination Port | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Length | Checksum | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | 0xFF | 159 +-+-+-+-+-+-+-+-+ 161 The UDP header is a standard [RFC 768] header, where 162 - Source Port and Destination Port MUST be the same as used by 163 UDP-ESP encapsulation of section 2.1 164 - Checksum SHOULD be transmitted as a zero value. 165 - Receivers MUST NOT depend upon the UDP checksum being 166 a zero value. 168 The sender SHOULD use a one octet long payload with the value 0xFF. 169 The receiver SHOULD ignore a received NAT-keepalive packet. 171 3. Encapsulation and Decapsulation Procedures 173 3.1 Auxiliary Procedures 175 3.1.1 Tunnel Mode Decapsulation NAT Procedure 177 When a tunnel mode has been used to transmit packets, the inner 178 IP header can contain addresses that are not suitable for the 179 current network. This procedure defines how these addresses are 180 to be converted to suitable addresses for the current network. 182 Depending on local policy, one of the following MUST be done: 183 a) If a valid source IP address space has been defined in the policy 184 for the encapsulated packets from the peer, check that the source 185 IP address of the inner packet is valid according to the policy. 186 b) If an address has been assigned for the remote peer, check 187 that the source IP address used in the inner packet is the 188 same as the IP address assigned. 189 c) NAT is performed for the packet, making it suitable for transport 190 in the local network. 192 3.1.2 Transport Mode Decapsulation NAT Procedure 194 When a transport mode has been used to transmit packets, contained 195 TCP or UDP headers will contain incorrect checksums due to the change 196 of parts of the IP header during transit. This procedure defines how 197 to fix these checksums. 199 Depending on local policy, one of the following MUST be done: 200 a) If the protocol header after the ESP header is a TCP/UDP 201 header and the peer's real source and destination IP address have 202 been received according to [Kiv05], incrementally recompute the 203 TCP/UDP checksum: 204 - subtract the IP source address in the received packet 205 from the checksum 206 - add the real IP source address received via IKE to the checksum 207 (obtained from the NAT-OA) 208 - subtract the IP destination address in the received packet 209 from the checksum 210 - add the real IP destination address received via IKE to the 211 checksum (obtained from the NAT-OA) 212 Note: if received and real address are the same for a given address, 213 say the source address, the operations cancel and don't need to be 214 performed. 215 b) If the protocol header after the ESP header is a TCP/UDP 216 header, recompute the checksum field in the TCP/UDP header. 217 c) If the protocol header after the ESP header is an UDP 218 header, zero the checksum field in the UDP header. If the protocol 219 header after the ESP header is a TCP header, and there is an 220 option to flag to the stack that TCP checksum does not need to 221 be computed, then that flag MAY be used. This SHOULD only be done 222 for transport mode, and if the packet is integrity protected. Tunnel 223 mode TCP checksums MUST be verified. 224 [This is not a violation to the spirit of section 4.2.2.7 in RFC 1122 225 because a checksum is being generated by the sender, and verified 226 by the receiver. That checksum is the integrity over the packet 227 performed by IPsec.] 229 In addition an implementation MAY fix any contained protocols that 230 have been broken by NAT. 232 3.2 Transport Mode ESP Encapsulation 234 BEFORE APPLYING ESP/UDP 235 ---------------------------- 236 IPv4 |orig IP hdr | | | 237 |(any options)| TCP | Data | 238 ---------------------------- 240 AFTER APPLYING ESP/UDP 241 ------------------------------------------------------- 242 IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP| 243 |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth| 244 ------------------------------------------------------- 245 |<----- encrypted ---->| 246 |<------ authenticated ----->| 248 1) Ordinary ESP encapsulation procedure is used. 249 2) A properly formatted UDP header is inserted where shown. 250 3) The Total Length, Protocol and Header Checksum fields in the 251 IP header are edited to match the resulting IP packet. 253 3.3 Transport Mode ESP Decapsulation 255 1) The UDP header is removed from the packet. 256 2) The Total Length, Protocol and Header Checksum fields in the 257 new IP header are edited to match the resulting IP packet. 258 3) Ordinary ESP decapsulation procedure is used. 259 4) Transport mode decapsulation NAT procedure is used. 261 3.4 Tunnel Mode ESP Encapsulation 263 BEFORE APPLYING ESP/UDP 264 ---------------------------- 265 IPv4 |orig IP hdr | | | 266 |(any options)| TCP | Data | 267 ---------------------------- 269 AFTER APPLYING ESP/UDP 270 -------------------------------------------------------------- 271 IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| 272 |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| 273 -------------------------------------------------------------- 274 |<------------ encrypted ----------->| 275 |<------------- authenticated ------------>| 277 1) Ordinary ESP encapsulation procedure is used. 278 2) A properly formatted UDP header is inserted where shown. 279 3) The Total Length, Protocol and Header Checksum fields in the 280 new IP header are edited to match the resulting IP packet. 282 3.5 Tunnel Mode ESP Decapsulation 284 1) The UDP header is removed from the packet. 285 2) The Total Length, Protocol and Header Checksum fields in the 286 new IP header are edited to match the resulting IP packet. 287 3) Ordinary ESP decapsulation procedure is used. 288 4) Tunnel mode decapsulation NAT procedure is used. 290 4. NAT Keepalive Procedure 292 The sole purpose of sending NAT-keepalive packets is to keep 293 NAT mappings alive for the duration of a connection between 294 the peers. Reception of NAT-keepalive packets MUST NOT be 295 used to detect liveness of a connection. 297 A peer MAY send a NAT-keepalive packet if there exists one 298 or more phase I or phase II SAs between the peers, or such 299 an SA has existed at most N minutes earlier. N is a locally 300 configurable parameter with a default value of 5 minutes. 302 A peer SHOULD send a NAT-keepalive packet if a need to send such 303 packets is detected according to [Kiv05] and if no other packet to 304 the peer has been sent in M seconds. M is a locally configurable 305 parameter with a default value of 20 seconds. 307 5. Security Considerations 309 5.1 DoS 311 On some systems ESPUDP may have DoS attack consequences, 312 especially if ordinary operating system UDP-functionality is 313 being used. It may be recommended not to open an ordinary UDP-port 314 for this. 316 5.2 Tunnel Mode Conflict 318 Implementors are warned that it is possible for remote peers to 319 negotiate entries that overlap in a GW, an issue affecting tunnel 320 mode. 322 +----+ \ / 323 | |-------------|----\ 324 +----+ / \ \ 325 Ari's NAT 1 \ 326 Laptop \ 327 10.1.2.3 \ 328 +----+ \ / \ +----+ +----+ 329 | |-------------|----------+------| |----------| | 330 +----+ / \ +----+ +----+ 331 Bob's NAT 2 GW Suzy's 332 Laptop Server 333 10.1.2.3 335 Because GW will now see two possible SAs that lead to 10.1.2.3, it 336 can become confused where to send packets coming from Suzy's server. 337 Implementators MUST devise ways of preventing such a thing from 338 occurring. 340 It is recommended that GW either assign locally unique IP addresses 341 to A and B using a protocol such as DHCP over IPsec, or uses NAT to 342 change A's and B's source IP addresses to such locally unique 343 addresses before sending packets forward to S. 345 5.3 Transport Mode Conflict 347 Another similar issue may occur in transport mode, with 2 clients, 348 Ari and Bob, behind the same NAT talking securely to the same server. 350 Cliff wants to talk in the clear to the same server. 352 +----+ 353 | | 354 +----+ \ 355 Ari's \ 356 Laptop \ 357 10.1.2.3 \ 358 +----+ \ / +----+ 359 | |-----+-----------------| | 360 +----+ / \ +----+ 361 Bob's NAT Server 362 Laptop / 363 10.1.2.4 / 364 / 365 +----+ / 366 | |/ 367 +----+ 368 Cliff's 369 Laptop 370 10.1.2.5 372 Now, transport SAs on the server will look like: 373 To Ari: S to NAT, , UDP encap <4500, Y> 374 To Bob: S to NAT, , UDP encap <4500, Z> 376 Cliff's traffic is in the clear, so there is no SA. 378 is the protocol and port information. 379 The UDP encap ports are the ports used in UDP encapsulated 380 ESP format of section 2.1. Y,Z are the dynamic ports assigned 381 by the NAT during the IKE negotiation. So IKE traffic from 382 Ari's laptop goes out on UDP <4500,4500>. It reaches the server 383 as UDP , where Y is the dynamically assigned port. 385 If the overlaps , then 386 simple filter lookups may not be sufficient to determine 387 which SA needs to be used to send traffic. Implementations 388 MUST handle this situation, either by disallowing 389 conflicting connections, or by other means. 391 Assume now that Cliff wants to connect to the server S in the 392 clear. This is going to be difficult to configure since 393 the server already has a policy from S to the NAT's external 394 address, for securing . For totally non-overlapping 395 traffic descriptions, this is possible. 397 Sample server policy could be: 398 To Ari: S to NAT, All UDP, secure 399 To Bob: S to NAT, All TCP, secure 400 To Cliff: S to NAT, ALL ICMP, clear text 402 Note, this policy also lets Ari and Bob send cleartext ICMP to the 403 server. 405 The server sees all clients behind the NAT as the same IP address, 406 so setting up different policies for the same traffic descriptor 407 is in principle impossible. 409 A problematic example configuration on the server is: 411 S to NAT, TCP, secure (for Ari and Bob) 412 S to NAT, TCP, clear (for Cliff) 414 The problem is that the server cannot enforce his policy, since it 415 is possible that misbehaving Bob sends traffic in the clear. This 416 is indistinguishable from Cliff sending traffic in the clear. 417 So it is impossible to guarantee security from some clients behind 418 a NAT, and also allow clear text from different clients behind the 419 SAME NAT. If the server's security policy allows, however, it can 420 do best effort security: if the client from behind the NAT 421 initiates security, his connection will be secured. If he sends 422 in the clear, the server will still accept that clear text. 424 So, for security guarantees, the above problematic scenario MUST NOT 425 be allowed on servers. For best effort security, this scenario MAY 426 be used. 428 6. IANA Considerations 430 This document depends on the reserved SPI value of zero (0) not 431 being sent over the wire as a part of an ESP-packet [RFC 2406]. 433 This document defines a "Non-ESP Marker" as 4 bytes of zero aligning 434 with the SPI field of an ESP packet, and generally being followed 435 by something that is not an ESP packet. 437 With regard to NAT-traversal in IKEv1 case, the Non-ESP Marker is 438 being followed by an IKEv1 packet as specified in section 2.2. 440 7. Intellectual Property Rights 442 The IETF has been notified of intellectual property rights claimed in 443 regard to some or all of the specification contained in this document. 444 For more information consult the online list of claimed rights. 446 8. Acknowledgments 448 Thanks to Tero Kivinen and William Dixon who contributed actively 449 to this document. 451 Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen and 452 Santeri Paavolainen who contributed to the previous drafts 453 about NAT traversal. 455 9. References 457 Normative references: 459 [RFC 768] Postel, J., "User Datagram Protocol", August 1980 461 [RFC 2119] Bradner, S., "Key words for use in RFCs to indicate 462 Requirement Levels", March 1997 464 [RFC 2406] Kent, S., "IP Encapsulating Security Payload (ESP)", 465 November 1998 467 [RFC 2409] D. Harkins, D. Carrel, "The Internet Key Exchange 468 (IKE)", November 1998 470 [Kiv05] Kivinen, T. et. al., draft-ietf-ipsec-nat-t-ike-05.txt, 471 "Negotiation of NAT-Traversal in the IKE", December 2002 473 Non-normative references: 475 [RFC 1122] R. Braden (Editor), "Requirements for Internet Hosts 476 -- Communication Layers", October 1989 478 [RFC 3193] Patel, B. et. al, "Securing L2TP using IPsec", 479 November 2001 481 10. Authors' Addresses 483 Ari Huttunen 484 F-Secure Corporation 485 Tammasaarenkatu 7 486 FIN-00181 HELSINKI 487 Finland 488 E-mail: Ari.Huttunen@F-Secure.com 490 Brian Swander 491 Microsoft 492 One Microsoft Way 493 Redmond WA 98052 494 E-mail: briansw@microsoft.com 496 Markus Stenberg 497 SSH Communications Security Corp 498 Fredrikinkatu 42 499 FIN-00100 HELSINKI 500 Finland 501 E-mail: mstenber@ssh.com 503 Victor Volpe 504 Cisco Systems 505 124 Grove Street 506 Suite 205 507 Franklin, MA 02038 508 E-mail: vvolpe@cisco.com 510 Larry DiBurro 511 Nortel Networks 512 80 Central Street 513 Boxborough, MA 01719 514 ldiburro@nortelnetworks.com 516 Appendix A: Clarification of potential NAT multiple client solutions 518 There have been requests to clarify potential solutions to the problem 519 of multiple clients behind the same NAT simultaneously connecting to the 520 same destination IP address. 521 Sections 5.2 and 5.3 say that you MUST avoid this 522 problem. As this isn't a wire protocol matter, but a local 523 implementation matter, specification of the mechanisms do not belong in 524 the draft itself. They are instead listed in this appendix. 526 Choosing an option will likely depend on the scenarios for which you 527 use/support IPsec NAT-T. This list is not meant to be exhaustive, so 528 other solutions may exist. We first describe the generic choices that 529 solve the problem for all upper layer protocols. 531 Generic choices for ESP transport mode: 532 Tr1) Implement a built-in NAT (network address translation) above IPsec 533 decapsulation. SSH may have intellectual property rights relating to 534 this implementation technique. See their IPR notice on the IETF web 535 site for the details. 537 Tr2) Implement a built-in NAPT (network address port translation) above 538 IPsec decapsulation. Microsoft may have intellectual property rights 539 relating to this implementation technique. See the Microsoft IPR notice 540 on the IETF web site for the details. 542 Tr3) An initiator may decide not to request transport mode once NAT is 543 detected and instead request a tunnel mode SA. This may be a retry 544 after transport mode is denied by the responder, or it may be the 545 initiator's choice to propose a tunnel SA initially. This is no more 546 difficult than knowing whether to propose transport mode or tunnel mode 547 without NAT. If for some reason the responder prefers or requires 548 tunnel mode for NAT traversal, it must reject the quick mode SA proposal 549 for transport mode. 551 Generic choises for ESP tunnel mode: 552 Tn1) Same as Tr1. 554 Tn2) Same as Tr2. 556 Tn3) This option is possible if an initiator is capable of being assigned 557 an address through it's tunnel SA with the responder using DHCP. The 558 initiator may initially request an internal address via the DHCP-IPsec 559 method, regardless of whether it knows it is behind a NAT. Or it may 560 re-initiate an IKE quick mode negotiation for DHCP tunnel SA after the 561 responder fails the quick mode SA transport mode proposal, either when 562 NAT-OA payload is sent or because it discovers from NAT-D the initiator 563 is behind a NAT and it's local configuration/policy will only accept 564 connecting through NAT when being assigned an address through 565 DHCP-IPsec. 567 There are also implementation choices offereing limited 568 interoperability. Vendors should specify what applications or 569 protocols should work using their NAT-T solution if these options 570 are selected. Note that neither Tr4 nor Tn4 are expected to work 571 with TCP traffic. 573 Limited interoperability choices for ESP transport mode: 575 Tr4) Implement upper layer protocol awareness of the inbound & outbound 576 IPsec SA so that it doesn't use the source IP and the source port as the 577 session identifier. (E.g. L2TP session ID mapped to the IPsec SA pair 578 which doesn't use the UDP source port or the source IP address for peer 579 uniqueness.) 581 Tr5) Implement application integration with IKE initiation such that it 582 can rebind to a different source port if the IKE quick mode SA proposal 583 is rejected by the responder, then repropose the new QM selector. 584 Microsoft may have intellectual property rights relating to this 585 implementation technique. See the Microsoft IPR notice on the IETF web 586 site for the details. 588 Limited interoperability choices for ESP tunnel mode: 590 Tn4) Same as Tr4.