idnits 2.17.1 draft-ietf-ipsec-udp-encaps-04.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 586 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. == 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 406 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 (November 2002) is 7833 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 458, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 461, 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-04 Summary: 5 errors (**), 0 flaws (~~), 8 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: May 2003 Microsoft 5 M. Stenberg 6 SSH Communications Security Corp 7 V. Volpe 8 Cisco Systems 9 L. DiBurro 10 Nortel Networks 11 November 2002 13 UDP Encapsulation of IPsec Packets 14 draft-ietf-ipsec-udp-encaps-04.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 May, 2003. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). 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 74 1. Introduction 76 This draft defines methods to encapsulate and decapsulate ESP 77 packets inside UDP packets for the purpose of traversing NATs. 78 The UDP port numbers are the same as used by IKE traffic, as 79 defined in [Kiv04]. 81 It is up to the need of the clients whether transport mode 82 or tunnel mode is to be supported. L2TP/IPsec clients MUST support 83 transport mode since [RFC 3193] defines that L2TP/IPsec MUST use 84 transport mode], and IPsec tunnel mode clients MUST support tunnel 85 mode. 87 An IKE implementation supporting this draft MUST NOT use the 88 ESP SPI field zero for ESP packets. This ensures that 89 IKE packets and ESP packets can be distinguished from each other. 91 UDP encapsulation of ESP packets as defined in this document is 92 written in terms of IPv4 headers. There is no technical reason 93 why an IPv6 header could not be used as the outer header and/or 94 as the inner header. 96 2. Packet Formats 98 2.1 UDP-encapsulated ESP Header Format 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Source Port | Destination Port | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Length | Checksum | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | ESP header [RFC 2406] | 108 ~ ~ 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 The UDP header is a standard [RFC 768] header, where 113 - Source Port and Destination Port MUST be the same as used by 114 floated IKE traffic. 115 - Checksum SHOULD be transmitted as a zero value. 116 - Receivers MUST NOT depend upon the UDP checksum being 117 a zero value. 119 The SPI field in the ESP header must not be zero. 121 2.2 Floated IKE Header Format 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Source Port | Destination Port | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Length | Checksum | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Non-ESP Marker | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | IKE header [RFC 2409] | 133 ~ ~ 134 | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 The UDP header is a standard [RFC 768] header, and is used 138 as defined in [Kiv04]. This document does not set any new 139 requirements for the checksum handling of an IKE packet. 141 Non-ESP Marker is 4 bytes of zero aligning with the SPI field 142 of an ESP packet. 144 2.3 NAT-keepalive Packet Format 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Source Port | Destination Port | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Length | Checksum | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | 0xFF | 154 +-+-+-+-+-+-+-+-+ 156 The UDP header is a standard [RFC 768] header, where 157 - Source Port and Destination Port MUST be the same as used by 158 UDP-ESP encapsulation of section 2.1 159 - Checksum SHOULD be transmitted as a zero value. 160 - Receivers MUST NOT depend upon the UDP checksum being 161 a zero value. 163 The sender SHOULD use a one octet long payload with the value 0xFF. 164 The receiver SHOULD ignore a received NAT-keepalive packet. 166 3. Encapsulation and Decapsulation Procedures 168 3.1 Auxiliary Procedures 170 3.1.1 Tunnel Mode Decapsulation NAT Procedure 172 When a tunnel mode has been used to transmit packets, the inner 173 IP header can contain addresses that are not suitable for the 174 current network. This procedure defines how these addresses are 175 to be converted to suitable addresses for the current network. 177 Depending on local policy, one of the following MUST be done: 178 a) If a valid source IP address space has been defined in the policy 179 for the encapsulated packets from the peer, check that the source 180 IP address of the inner packet is valid according to the policy. 181 b) If an address has been assigned for the remote peer, check 182 that the source IP address used in the inner packet is the 183 same as the IP address assigned. 184 c) NAT is performed for the packet, making it suitable for transport 185 in the local network. 187 3.1.2 Transport Mode Decapsulation NAT Procedure 189 When a transport mode has been used to transmit packets, contained 190 TCP or UDP headers will contain incorrect checksums due to the change 191 of parts of the IP header during transit. This procedure defines how 192 to fix these checksums. 194 Depending on local policy, one of the following MUST be done: 195 a) If the protocol header after the ESP header is a TCP/UDP 196 header and the peer's real source IP address has been received 197 according to [Kiv04], incrementally recompute the TCP/UDP checksum: 198 - subtract the IP source address in the received packet 199 from the checksum 200 - add the real IP source address received via IKE to the checksum 201 b) If the protocol header after the ESP header is a TCP/UDP 202 header, recompute the checksum field in the TCP/UDP header. 203 c) If the protocol header after the ESP header is an UDP 204 header, zero the checksum field in the UDP header. If the protocol 205 header after the ESP header is a TCP header, and there is an 206 option to flag to the stack that TCP checksum does not need to 207 be computed, then that flag MAY be used. This SHOULD only be done 208 for transport mode, and if the packet is integrity protected. Tunnel 209 mode TCP checksums MUST be verified. 210 [This is not a violation to the spirit of section 4.2.2.7 in RFC 1122 211 because a checksum is being generated by the sender, and verified 212 by the receiver. That checksum is the integrity over the packet 213 performed by IPsec.] 215 In addition an implementation MAY fix any contained protocols that 216 have been broken by NAT. 218 3.2 Transport Mode ESP Encapsulation 220 BEFORE APPLYING ESP/UDP 221 ---------------------------- 222 IPv4 |orig IP hdr | | | 223 |(any options)| TCP | Data | 224 ---------------------------- 226 AFTER APPLYING ESP/UDP 227 ------------------------------------------------------- 228 IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP| 229 |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth| 230 ------------------------------------------------------- 231 |<----- encrypted ---->| 232 |<------ authenticated ----->| 234 1) Ordinary ESP encapsulation procedure is used. 235 2) A properly formatted UDP header is inserted where shown. 236 3) The Total Length, Protocol and Header Checksum fields in the 237 IP header are edited to match the resulting IP packet. 239 3.3 Transport Mode ESP Decapsulation 241 1) The UDP header is removed from the packet. 242 2) The Total Length, Protocol and Header Checksum fields in the 243 new IP header are edited to match the resulting IP packet. 244 3) Ordinary ESP decapsulation procedure is used. 245 4) Transport mode decapsulation NAT procedure is used. 247 3.4 Tunnel Mode ESP Encapsulation 249 BEFORE APPLYING ESP/UDP 250 ---------------------------- 251 IPv4 |orig IP hdr | | | 252 |(any options)| TCP | Data | 253 ---------------------------- 255 AFTER APPLYING ESP/UDP 256 -------------------------------------------------------------- 257 IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| 258 |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| 259 -------------------------------------------------------------- 260 |<------------ encrypted ----------->| 261 |<------------- authenticated ------------>| 263 1) Ordinary ESP encapsulation procedure is used. 264 2) A properly formatted UDP header is inserted where shown. 265 3) The Total Length, Protocol and Header Checksum fields in the 266 new IP header are edited to match the resulting IP packet. 268 3.5 Tunnel Mode ESP Decapsulation 270 1) The UDP header is removed from the packet. 271 2) The Total Length, Protocol and Header Checksum fields in the 272 new IP header are edited to match the resulting IP packet. 273 3) Ordinary ESP decapsulation procedure is used. 274 4) Tunnel mode decapsulation NAT procedure is used. 276 4. NAT Keepalive Procedure 278 The sole purpose of sending NAT-keepalive packets is to keep 279 NAT mappings alive for the duration of a connection between 280 the peers. Reception of NAT-keepalive packets MUST NOT be 281 used to detect liveness of a connection. 283 A peer MAY send a NAT-keepalive packet if there exists one 284 or more phase I or phase II SAs between the peers, or such 285 an SA has existed at most N minutes earlier. N is a locally 286 configurable parameter with a default value of 5 minutes. 288 A peer SHOULD send a NAT-keepalive packet if a need to send such 289 packets is detected according to [Kiv04] and if no other packet to 290 the peer has been sent in M seconds. M is a locally configurable 291 parameter with a default value of 20 seconds. 293 5. Security Considerations 295 5.1 DoS 297 On some systems ESPUDP may have DoS attack consequences, 298 especially if ordinary operating system UDP-functionality is 299 being used. It may be recommended not to open an ordinary UDP-port 300 for this. 302 5.2 Tunnel Mode Conflict 304 Implementors are warned that it is possible for remote peers to 305 negotiate entries that overlap in a GW, an issue affecting tunnel 306 mode. 308 +----+ \ / 309 | |-------------|----\ 310 +----+ / \ \ 311 Ari's NAT 1 \ 312 Laptop \ 313 10.1.2.3 \ 314 +----+ \ / \ +----+ +----+ 315 | |-------------|----------+------| |----------| | 316 +----+ / \ +----+ +----+ 317 Bob's NAT 2 GW Suzy's 318 Laptop Server 319 10.1.2.3 321 Because GW will now see two possible SAs that lead to 10.1.2.3, it 322 can become confused where to send packets coming from Suzy's server. 323 Implementators MUST devise ways of preventing such a thing from 324 occurring. 326 It is recommended that GW either assign locally unique IP addresses 327 to A and B using a protocol such as DHCP over IPsec, or uses NAT to 328 change A's and B's source IP addresses to such locally unique 329 addresses before sending packets forward to S. 331 5.3 Transport Mode Conflict 333 Another similar issue may occur in transport mode, with 2 clients, 334 Ari and Bob, behind the same NAT talking securely to the same server. 336 Cliff wants to talk in the clear to the same server. 338 +----+ 339 | | 340 +----+ \ 341 Ari's \ 342 Laptop \ 343 10.1.2.3 \ 344 +----+ \ / +----+ 345 | |-----+-----------------| | 346 +----+ / \ +----+ 347 Bob's NAT Server 348 Laptop / 349 10.1.2.4 / 350 / 351 +----+ / 352 | |/ 353 +----+ 354 Cliff's 355 Laptop 356 10.1.2.5 358 Now, transport SAs on the server will look like: 359 To Ari: S to NAT, , UDP encap <4500, Y> 360 To Bob: S to NAT, , UDP encap <4500, Z> 362 Cliff's traffic is in the clear, so there is no SA. 364 is the protocol and port information. 365 The UDP encap ports are the ports used in UDP encapsulated 366 ESP format of section 2.1. Y,Z are the dynamic ports assigned 367 by the NAT during the IKE negotiation. So IKE traffic from 368 Ari's laptop goes out on UDP <4500,4500>. It reaches the server 369 as UDP , where Y is the dynamically assigned port. 371 If the overlaps , then 372 simple filter lookups may not be sufficient to determine 373 which SA needs to be used to send traffic. Implementations 374 MUST handle this situation, either by disallowing 375 conflicting connections, or by other means. 377 Assume now that Cliff wants to connect to the server S in the 378 clear. This is going to be difficult to configure since 379 the server already has a policy from S to the NAT's external 380 address, for securing . For totally non-overlapping 381 traffic descriptions, this is possible. 383 Sample server policy could be: 384 To Ari: S to NAT, All UDP, secure 385 To Bob: S to NAT, All TCP, secure 386 To Cliff: S to NAT, ALL ICMP, clear text 388 Note, this policy also lets Ari and Bob send cleartext ICMP to the 389 server. 391 The server sees all clients behind the NAT as the same IP address, 392 so setting up different policies for the same traffic descriptor 393 is in principle impossible. 395 A problematic example configuration on the server is: 397 S to NAT, TCP, secure (for Ari and Bob) 398 S to NAT, TCP, clear (for Cliff) 400 The problem is that the server cannot enforce his policy, since it 401 is possible that misbehaving Bob sends traffic in the clear. This 402 is indistinguishable from Cliff sending traffic in the clear. 403 So it is impossible to guarantee security from some clients behind 404 a NAT, and also allow clear text from different clients behind the 405 SAME NAT. If the server's security policy allows, however, it can 406 do best effort security: if the client from behind the NAT 407 initiates security, his connection will be secured. If he sends 408 in the clear, the server will still accept that clear text. 410 So, for security guarantees, the above problematic scenario MUST NOT 411 be allowed on servers. For best effort security, this scenario MAY 412 be used. 414 6. IANA Considerations 416 This document depends on the reserved SPI value of zero (0) not 417 being sent over the wire as a part of an ESP-packet [RFC 2406]. 419 This document defines a "Non-ESP Marker" as 4 bytes of zero aligning 420 with the SPI field of an ESP packet, and generally being followed 421 by something that is not an ESP packet. 423 With regard to NAT-traversal in IKEv1 case, the Non-ESP Marker is 424 being followed by an IKEv1 packet as specified in section 2.2. 426 7. Intellectual Property Rights 428 The IETF has been notified of intellectual property rights claimed in 429 regard to some or all of the specification contained in this document. 430 For more information consult the online list of claimed rights. 432 8. Acknowledgments 434 Thanks to Tero Kivinen and William Dixon who contributed actively 435 to this document. 437 Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen and 438 Santeri Paavolainen who contributed to the previous drafts 439 about NAT traversal. 441 9. References 443 Normative references: 445 [RFC 768] Postel, J., "User Datagram Protocol", August 1980 447 [RFC 2406] Kent, S., "IP Encapsulating Security Payload (ESP)", 448 November 1998 450 [RFC 2409] D. Harkins, D. Carrel, "The Internet Key Exchange 451 (IKE)", November 1998 453 [Kiv04] Kivinen, T. et. al., draft-ietf-ipsec-nat-t-ike-04.txt, 454 "Negotiation of NAT-Traversal in the IKE", October 2002 456 Non-normative references: 458 [RFC 1122] R. Braden (Editor), "Requirements for Internet Hosts 459 -- Communication Layers", October 1989 461 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 462 Requirement Levels", March 1997 464 [RFC 3193] Patel, B. et. al, "Securing L2TP using IPsec", 465 November 2001 467 10. Authors' Addresses 469 Ari Huttunen 470 F-Secure Corporation 471 Tammasaarenkatu 7 472 FIN-00181 HELSINKI 473 Finland 474 E-mail: Ari.Huttunen@F-Secure.com 476 Brian Swander 477 Microsoft 478 One Microsoft Way 479 Redmond WA 98052 480 E-mail: briansw@microsoft.com 482 Markus Stenberg 483 SSH Communications Security Corp 484 Fredrikinkatu 42 485 FIN-00100 HELSINKI 486 Finland 487 E-mail: mstenber@ssh.com 489 Victor Volpe 490 Cisco Systems 491 124 Grove Street 492 Suite 205 493 Franklin, MA 02038 494 E-mail: vvolpe@cisco.com 496 Larry DiBurro 497 Nortel Networks 498 80 Central Street 499 Boxborough, MA 01719 500 ldiburro@nortelnetworks.com 502 Appendix A: Clarification of potential NAT multiple client solutions 504 There have been requests to clarify potential solutions to the problem 505 of multiple clients behind the same NAT simultaneously connecting to the 506 same destination IP address. 507 Sections 5.2 and 5.3 say that you MUST avoid this 508 problem. As this isn't a wire protocol matter, but a local 509 implementation matter, specification of the mechanisms do not belong in 510 the draft itself. They are instead listed in this appendix. 512 Choosing an option will likely depend on the scenarios for which you 513 use/support IPsec NAT-T. This list is not meant to be exhaustive, so 514 other solutions may exist. We first describe the generic choices that 515 solve the problem for all upper layer protocols. 517 Generic choices for ESP transport mode: 518 Tr1) Implement a built-in NAT (network address translation) above IPsec 519 decapsulation. SSH may have intellectual property rights relating to 520 this implementation technique. See their IPR notice on the IETF web 521 site for the details. 523 Tr2) Implement a built-in NAPT (network address port translation) above 524 IPsec decapsulation. Microsoft may have intellectual property rights 525 relating to this implementation technique. See the Microsoft IPR notice 526 on the IETF web site for the details. 528 Tr3) An initiator may decide not to request transport mode once NAT is 529 detected and instead request a tunnel mode SA. This may be a retry 530 after transport mode is denied by the responder, or it may be the 531 initiator's choice to propose a tunnel SA initially. This is no more 532 difficult than knowing whether to propose transport mode or tunnel mode 533 without NAT. If for some reason the responder prefers or requires 534 tunnel mode for NAT traversal, it must reject the quick mode SA proposal 535 for transport mode. 537 Generic choises for ESP tunnel mode: 538 Tn1) Same as Tr1. 540 Tn2) Same as Tr2. 542 Tn3) This option is possible if an initiator is capable of being assigned 543 an address through it's tunnel SA with the responder using DHCP. The 544 initiator may initially request an internal address via the DHCP-IPsec 545 method, regardless of whether it knows it is behind a NAT. Or it may 546 re-initiate an IKE quick mode negotiation for DHCP tunnel SA after the 547 responder fails the quick mode SA transport mode proposal, either when 548 NAT-OA payload is sent or because it discovers from NAT-D the initiator 549 is behind a NAT and it's local configuration/policy will only accept 550 connecting through NAT when being assigned an address through 551 DHCP-IPsec. 553 There are also implementation choices offereing limited 554 interoperability. Vendors should specify what applications or 555 protocols should work using their NAT-T solution if these options 556 are selected. Note that neither Tr4 nor Tn4 are expected to work 557 with TCP traffic. 559 Limited interoperability choices for ESP transport mode: 561 Tr4) Implement upper layer protocol awareness of the inbound & outbound 562 IPsec SA so that it doesn't use the source IP and the source port as the 563 session identifier. (E.g. L2TP session ID mapped to the IPsec SA pair 564 which doesn't use the UDP source port or the source IP address for peer 565 uniqueness.) 567 Tr5) Implement application integration with IKE initiation such that it 568 can rebind to a different source port if the IKE quick mode SA proposal 569 is rejected by the responder, then repropose the new QM selector. 570 Microsoft may have intellectual property rights relating to this 571 implementation technique. See the Microsoft IPR notice on the IETF web 572 site for the details. 574 Limited interoperability choices for ESP tunnel mode: 576 Tn4) Same as Tr4.