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