1 2 3 4 5 6 7Network Working Group A. Huttunen 8Request for Comments: 3948 F-Secure Corporation 9Category: Standards Track B. Swander 10 Microsoft 11 V. Volpe 12 Cisco Systems 13 L. DiBurro 14 Nortel Networks 15 M. Stenberg 16 January 2005 17 18 19 UDP Encapsulation of IPsec ESP Packets 20 21Status of this Memo 22 23 This document specifies an Internet standards track protocol for the 24 Internet community, and requests discussion and suggestions for 25 improvements. Please refer to the current edition of the "Internet 26 Official Protocol Standards" (STD 1) for the standardization state 27 and status of this protocol. Distribution of this memo is unlimited. 28 29Copyright Notice 30 31 Copyright (C) The Internet Society (2005). 32 33Abstract 34 35 This protocol specification defines methods to encapsulate and 36 decapsulate IP Encapsulating Security Payload (ESP) packets inside 37 UDP packets for traversing Network Address Translators. ESP 38 encapsulation, as defined in this document, can be used in both IPv4 39 and IPv6 scenarios. Whenever negotiated, encapsulation is used with 40 Internet Key Exchange (IKE). 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Huttunen, et al. Standards Track [Page 1] 59 60RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 61 62 63Table of Contents 64 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. UDP-Encapsulated ESP Header Format . . . . . . . . . . . 3 68 2.2. IKE Header Format for Port 4500 . . . . . . . . . . . . 4 69 2.3. NAT-Keepalive Packet Format . . . . . . . . . . . . . . 4 70 3. Encapsulation and Decapsulation Procedures . . . . . . . . . . 5 71 3.1. Auxiliary Procedures . . . . . . . . . . . . . . . . . . 5 72 3.1.1. Tunnel Mode Decapsulation NAT Procedure . . . . 5 73 3.1.2. Transport Mode Decapsulation NAT Procedure . . . 5 74 3.2. Transport Mode ESP Encapsulation . . . . . . . . . . . . 6 75 3.3. Transport Mode ESP Decapsulation . . . . . . . . . . . . 6 76 3.4. Tunnel Mode ESP Encapsulation . . . . . . . . . . . . . 7 77 3.5. Tunnel Mode ESP Decapsulation . . . . . . . . . . . . . 7 78 4. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 7 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 5.1. Tunnel Mode Conflict . . . . . . . . . . . . . . . . . . 8 81 5.2. Transport Mode Conflict . . . . . . . . . . . . . . . . 9 82 6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 8.2. Informative References . . . . . . . . . . . . . . . . . 11 87 A. Clarification of Potential NAT Multiple Client Solutions . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 89 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 90 911. Introduction 92 93 This protocol specification defines methods to encapsulate and 94 decapsulate ESP packets inside UDP packets for traversing Network 95 Address Translators (NATs) (see [RFC3715], section 2.2, case i). The 96 UDP port numbers are the same as those used by IKE traffic, as 97 defined in [RFC3947]. 98 99 The sharing of the port numbers for both IKE and UDP encapsulated ESP 100 traffic was selected because it offers better scaling (only one NAT 101 mapping in the NAT; no need to send separate IKE keepalives), easier 102 configuration (only one port to be configured in firewalls), and 103 easier implementation. 104 105 A client's needs should determine whether transport mode or tunnel 106 mode is to be supported (see [RFC3715], Section 3, "Telecommuter 107 scenario"). L2TP/IPsec clients MUST support the modes as defined in 108 [RFC3193]. IPsec tunnel mode clients MUST support tunnel mode. 109 110 111 112 113 114Huttunen, et al. Standards Track [Page 2] 115 116RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 117 118 119 An IKE implementation supporting this protocol specification MUST NOT 120 use the ESP SPI field zero for ESP packets. This ensures that IKE 121 packets and ESP packets can be distinguished from each other. 122 123 As defined in this document, UDP encapsulation of ESP packets is 124 written in terms of IPv4 headers. There is no technical reason why 125 an IPv6 header could not be used as the outer header and/or as the 126 inner header. 127 128 Because the protection of the outer IP addresses in IPsec AH is 129 inherently incompatible with NAT, the IPsec AH was left out of the 130 scope of this protocol specification. This protocol also assumes 131 that IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the 132 IPsec SAs. Manual keying is not supported. 133 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 137 1382. Packet Formats 139 1402.1. UDP-Encapsulated ESP Header Format 141 142 0 1 2 3 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Source Port | Destination Port | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Length | Checksum | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | ESP header [RFC2406] | 150 ~ ~ 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 154 The UDP header is a standard [RFC0768] header, where 155 156 o the Source Port and Destination Port MUST be the same as that used 157 by IKE traffic, 158 o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and 159 o receivers MUST NOT depend on the UDP checksum being a zero value. 160 161 The SPI field in the ESP header MUST NOT be a zero value. 162 163 164 165 166 167 168 169 170Huttunen, et al. Standards Track [Page 3] 171 172RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 173 174 1752.2. IKE Header Format for Port 4500 176 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Source Port | Destination Port | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Length | Checksum | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Non-ESP Marker | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | IKE header [RFC2409] | 187 ~ ~ 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 191 The UDP header is a standard [RFC0768] header and is used as defined 192 in [RFC3947]. This document does not set any new requirements for 193 the checksum handling of an IKE packet. 194 195 A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field 196 of an ESP packet. 197 1982.3. NAT-Keepalive Packet Format 199 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Source Port | Destination Port | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Length | Checksum | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | 0xFF | 208 +-+-+-+-+-+-+-+-+ 209 210 The UDP header is a standard [RFC0768] header, where 211 212 o the Source Port and Destination Port MUST be the same as used by 213 UDP-ESP encapsulation of Section 2.1, 214 o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and 215 o receivers MUST NOT depend upon the UDP checksum being a zero 216 value. 217 218 The sender MUST use a one-octet-long payload with the value 0xFF. 219 The receiver SHOULD ignore a received NAT-keepalive packet. 220 221 222 223 224 225 226Huttunen, et al. Standards Track [Page 4] 227 228RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 229 230 2313. Encapsulation and Decapsulation Procedures 232 2333.1. Auxiliary Procedures 234 2353.1.1. Tunnel Mode Decapsulation NAT Procedure 236 237 When a tunnel mode has been used to transmit packets (see [RFC3715], 238 section 3, criteria "Mode support" and "Telecommuter scenario"), the 239 inner IP header can contain addresses that are not suitable for the 240 current network. This procedure defines how these addresses are to 241 be converted to suitable addresses for the current network. 242 243 Depending on local policy, one of the following MUST be done: 244 245 1. If a valid source IP address space has been defined in the policy 246 for the encapsulated packets from the peer, check that the source 247 IP address of the inner packet is valid according to the policy. 248 2. If an address has been assigned for the remote peer, check that 249 the source IP address used in the inner packet is the assigned IP 250 address. 251 3. NAT is performed for the packet, making it suitable for transport 252 in the local network. 253 2543.1.2. Transport Mode Decapsulation NAT Procedure 255 256 When a transport mode has been used to transmit packets, contained 257 TCP or UDP headers will have incorrect checksums due to the change of 258 parts of the IP header during transit. This procedure defines how to 259 fix these checksums (see [RFC3715], section 2.1, case b). 260 261 Depending on local policy, one of the following MUST be done: 262 263 1. If the protocol header after the ESP header is a TCP/UDP header 264 and the peer's real source and destination IP address have been 265 received according to [RFC3947], incrementally recompute the 266 TCP/UDP checksum: 267 268 * Subtract the IP source address in the received packet from the 269 checksum. 270 * Add the real IP source address received via IKE to the 271 checksum (obtained from the NAT-OA) 272 * Subtract the IP destination address in the received packet 273 from the checksum. 274 * Add the real IP destination address received via IKE to the 275 checksum (obtained from the NAT-OA). 276 Note: If the received and real address are the same for a given 277 address (e.g., say the source address), the operations cancel and 278 don't need to be performed. 279 280 281 282Huttunen, et al. Standards Track [Page 5] 283 284RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 285 286 287 2. If the protocol header after the ESP header is a TCP/UDP header, 288 recompute the checksum field in the TCP/UDP header. 289 290 3. If the protocol header after the ESP header is a UDP header, set 291 the checksum field to zero in the UDP header. If the protocol 292 after the ESP header is a TCP header, and if there is an option 293 to flag to the stack that the TCP checksum does not need to be 294 computed, then that flag MAY be used. This SHOULD only be done 295 for transport mode, and if the packet is integrity protected. 296 Tunnel mode TCP checksums MUST be verified. (This is not a 297 violation to the spirit of section 4.2.2.7 in [RFC1122] because a 298 checksum is being generated by the sender and verified by the 299 receiver. That checksum is the integrity over the packet 300 performed by IPsec.) 301 302 In addition an implementation MAY fix any contained protocols that 303 have been broken by NAT (see [RFC3715], section 2.1, case g). 304 3053.2. Transport Mode ESP Encapsulation 306 307 BEFORE APPLYING ESP/UDP 308 ---------------------------- 309 IPv4 |orig IP hdr | | | 310 |(any options)| TCP | Data | 311 ---------------------------- 312 313 AFTER APPLYING ESP/UDP 314 ------------------------------------------------------- 315 IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP| 316 |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth| 317 ------------------------------------------------------- 318 |<----- encrypted ---->| 319 |<------ authenticated ----->| 320 321 1. Ordinary ESP encapsulation procedure is used. 322 2. A properly formatted UDP header is inserted where shown. 323 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields 324 in the IP header are edited to match the resulting IP packet. 325 3263.3. Transport Mode ESP Decapsulation 327 328 1. The UDP header is removed from the packet. 329 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields 330 in the new IP header are edited to match the resulting IP packet. 331 3. Ordinary ESP decapsulation procedure is used. 332 4. Transport mode decapsulation NAT procedure is used. 333 334 335 336 337 338Huttunen, et al. Standards Track [Page 6] 339 340RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 341 342 3433.4. Tunnel Mode ESP Encapsulation 344 345 BEFORE APPLYING ESP/UDP 346 ---------------------------- 347 IPv4 |orig IP hdr | | | 348 |(any options)| TCP | Data | 349 ---------------------------- 350 351 AFTER APPLYING ESP/UDP 352 -------------------------------------------------------------- 353 IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| 354 |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| 355 -------------------------------------------------------------- 356 |<------------ encrypted ----------->| 357 |<------------- authenticated ------------>| 358 359 1. Ordinary ESP encapsulation procedure is used. 360 2. A properly formatted UDP header is inserted where shown. 361 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields 362 in the new IP header are edited to match the resulting IP packet. 363 3643.5. Tunnel Mode ESP Decapsulation 365 366 1. The UDP header is removed from the packet. 367 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields 368 in the new IP header are edited to match the resulting IP packet. 369 3. Ordinary ESP decapsulation procedure is used. 370 4. Tunnel mode decapsulation NAT procedure is used. 371 3724. NAT Keepalive Procedure 373 374 The sole purpose of sending NAT-keepalive packets is to keep NAT 375 mappings alive for the duration of a connection between the peers 376 (see [RFC3715], Section 2.2, case j). Reception of NAT-keepalive 377 packets MUST NOT be used to detect whether a connection is live. 378 379 A peer MAY send a NAT-keepalive packet if one or more phase I or 380 phase II SAs exist between the peers, or if such an SA has existed at 381 most N minutes earlier. N is a locally configurable parameter with a 382 default value of 5 minutes. 383 384 A peer SHOULD send a NAT-keepalive packet if a need for it is 385 detected according to [RFC3947] and if no other packet to the peer 386 has been sent in M seconds. M is a locally configurable parameter 387 with a default value of 20 seconds. 388 389 390 391 392 393 394Huttunen, et al. Standards Track [Page 7] 395 396RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 397 398 3995. Security Considerations 400 4015.1. Tunnel Mode Conflict 402 403 Implementors are warned that it is possible for remote peers to 404 negotiate entries that overlap in an SGW (security gateway), an issue 405 affecting tunnel mode (see [RFC3715], section 2.1, case e). 406 407 +----+ \ / 408 | |-------------|----\ 409 +----+ / \ \ 410 Ari's NAT 1 \ 411 Laptop \ 412 10.1.2.3 \ 413 +----+ \ / \ +----+ +----+ 414 | |-------------|----------+------| |----------| | 415 +----+ / \ +----+ +----+ 416 Bob's NAT 2 SGW Suzy's 417 Laptop Server 418 10.1.2.3 419 420 Because SGW will now see two possible SAs that lead to 10.1.2.3, it 421 can become confused about where to send packets coming from Suzy's 422 server. Implementors MUST devise ways of preventing this from 423 occurring. 424 425 It is RECOMMENDED that SGW either assign locally unique IP addresses 426 to Ari's and Bob's laptop (by using a protocol such as DHCP over 427 IPsec) or use NAT to change Ari's and Bob's laptop source IP 428 addresses to these locally unique addresses before sending packets 429 forward to Suzy's server. This covers the "Scaling" criteria of 430 section 3 in [RFC3715]. 431 432 Please see Appendix A. 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450Huttunen, et al. Standards Track [Page 8] 451 452RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 453 454 4555.2. Transport Mode Conflict 456 457 Another similar issue may occur in transport mode, with 2 clients, 458 Ari and Bob, behind the same NAT talking securely to the same server 459 (see [RFC3715], Section 2.1, case e). 460 461 Cliff wants to talk in the clear to the same server. 462 463 +----+ 464 | | 465 +----+ \ 466 Ari's \ 467 Laptop \ 468 10.1.2.3 \ 469 +----+ \ / +----+ 470 | |-----+-----------------| | 471 +----+ / \ +----+ 472 Bob's NAT Server 473 Laptop / 474 10.1.2.4 / 475 / 476 +----+ / 477 | |/ 478 +----+ 479 Cliff's 480 Laptop 481 10.1.2.5 482 483 Now, transport SAs on the server will look like this: 484 485 To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y> 486 487 To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z> 488 489 Cliff's traffic is in the clear, so there is no SA. 490 491 <traffic desc> is the protocol and port information. The UDP encap 492 ports are the ports used in UDP-encapsulated ESP format of section 493 2.1. Y,Z are the dynamic ports assigned by the NAT during the IKE 494 negotiation. So IKE traffic from Ari's laptop goes out on UDP 495 <4500,4500>. It reaches the server as UDP <Y,4500>, where Y is the 496 dynamically assigned port. 497 498 If the <traffic desc1> overlaps <traffic desc2>, then simple filter 499 lookups may not be sufficient to determine which SA has to be used to 500 send traffic. Implementations MUST handle this situation, either by 501 disallowing conflicting connections, or by other means. 502 503 504 505 506Huttunen, et al. Standards Track [Page 9] 507 508RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 509 510 511 Assume now that Cliff wants to connect to the server in the clear. 512 This is going to be difficult to configure, as the server already has 513 a policy (from Server to the NAT's external address) for securing 514 <traffic desc>. For totally non-overlapping traffic descriptions, 515 this is possible. 516 517 Sample server policy could be as follows: 518 519 To Ari: Server to NAT, All UDP, secure 520 521 To Bob: Server to NAT, All TCP, secure 522 523 To Cliff: Server to NAT, ALL ICMP, clear text 524 525 Note that this policy also lets Ari and Bob send cleartext ICMP to 526 the server. 527 528 The server sees all clients behind the NAT as the same IP address, so 529 setting up different policies for the same traffic descriptor is in 530 principle impossible. 531 532 A problematic example of configuration on the server is as follows: 533 534 Server to NAT, TCP, secure (for Ari and Bob) 535 536 Server to NAT, TCP, clear (for Cliff) 537 538 The server cannot enforce his policy, as it is possible that 539 misbehaving Bob sends traffic in the clear. This is 540 indistinguishable from when Cliff sends traffic in the clear. So it 541 is impossible to guarantee security from some clients behind a NAT, 542 while allowing clear text from different clients behind the SAME NAT. 543 If the server's security policy allows this, however, it can do 544 best-effort security: If the client from behind the NAT initiates 545 security, his connection will be secured. If he sends in the clear, 546 the server will still accept that clear text. 547 548 For security guarantees, the above problematic scenario MUST NOT be 549 allowed on servers. For best effort security, this scenario MAY be 550 used. 551 552 Please see Appendix A. 553 5546. IAB Considerations 555 556 The UNSAF [RFC3424] questions are addressed by the IPsec-NAT 557 compatibility requirements document [RFC3715]. 558 559 560 561 562Huttunen, et al. Standards Track [Page 10] 563 564RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 565 566 5677. Acknowledgments 568 569 Thanks to Tero Kivinen and William Dixon, who contributed actively to 570 this document. 571 572 Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri 573 Paavolainen, who contributed to the early documents about NAT 574 traversal. 575 5768. References 577 5788.1. Normative References 579 580 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 581 August 1980. 582 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 586 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 587 Internet Protocol", RFC 2401, November 1998. 588 589 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 590 Payload (ESP)", RFC 2406, November 1998. 591 592 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 593 (IKE)", RFC 2409, November 1998. 594 595 [RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 596 RFC 3947, January 2005. 597 5988.2. Informative References 599 600 [RFC1122] Braden, R., "Requirements for Internet Hosts - 601 Communication Layers", STD 3, RFC 1122, October 1989. 602 603 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 604 "Securing L2TP using IPsec", RFC 3193, November 2001. 605 606 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 607 Self-Address Fixing (UNSAF) Across Network Address 608 Translation", RFC 3424, November 2002. 609 610 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 611 (NAT) Compatibility Requirements", RFC 3715, March 2004. 612 613 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 614 Work in Progress, October 2004. 615 616 617 618Huttunen, et al. Standards Track [Page 11] 619 620RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 621 622 623Appendix A. Clarification of Potential NAT Multiple Client Solutions 624 625 This appendix provides clarification about potential solutions to the 626 problem of multiple clients behind the same NAT simultaneously 627 connecting to the same destination IP address. 628 629 Sections 5.1 and 5.2 say that you MUST avoid this problem. As this 630 is not a matter of wire protocol, but a matter local implementation, 631 the mechanisms do not belong in the protocol specification itself. 632 They are instead listed in this appendix. 633 634 Choosing an option will likely depend on the scenarios for which one 635 uses/supports IPsec NAT-T. This list is not meant to be exhaustive, 636 so other solutions may exist. We first describe the generic choices 637 that solve the problem for all upper-layer protocols. 638 639 Generic choices for ESP transport mode: 640 641 Tr1) Implement a built-in NAT (network address translation) above 642 IPsec decapsulation. 643 644 Tr2) Implement a built-in NAPT (network address port translation) 645 above IPsec decapsulation. 646 647 Tr3) An initiator may decide not to request transport mode once NAT 648 is detected and may instead request a tunnel-mode SA. This may be a 649 retry after transport mode is denied by the responder, or the 650 initiator may choose to propose a tunnel SA initially. This is no 651 more difficult than knowing whether to propose transport mode or 652 tunnel mode without NAT. If for some reason the responder prefers or 653 requires tunnel mode for NAT traversal, it must reject the quick mode 654 SA proposal for transport mode. 655 656 Generic choices for ESP tunnel mode: 657 658 Tn1) Same as Tr1. 659 660 Tn2) Same as Tr2. 661 662 Tn3) This option is possible if an initiator can be assigned an 663 address through its tunnel SA, with the responder using DHCP. The 664 initiator may initially request an internal address via the 665 DHCP-IPsec method, regardless of whether it knows it is behind a NAT. 666 It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA 667 after the responder fails the quick mode SA transport mode proposal. 668 This happens either when a NAT-OA payload is sent or because it 669 670 671 672 673 674Huttunen, et al. Standards Track [Page 12] 675 676RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 677 678 679 discovers from NAT-D that the initiator is behind a NAT and its local 680 configuration/policy will only accept a NAT connection when being 681 assigned an address through DHCP-IPsec. 682 683 There are also implementation choices that offer limited 684 interoperability. Implementors should specify which applications or 685 protocols should work if these options are selected. Note that 686 neither Tr4 nor Tn4, as described below, are expected to work with 687 TCP traffic. 688 689 Limited interoperability choices for ESP transport mode: 690 691 Tr4) Implement upper-layer protocol awareness of the inbound and 692 outbound IPsec SA so that it doesn't use the source IP and the source 693 port as the session identifier (e.g., an L2TP session ID mapped to 694 the IPsec SA pair that doesn't use the UDP source port or the source 695 IP address for peer uniqueness). 696 697 Tr5) Implement application integration with IKE initiation so that it 698 can rebind to a different source port if the IKE quick mode SA 699 proposal is rejected by the responder; then it can repropose the new 700 QM selector. 701 702 Limited interoperability choices for ESP tunnel mode: 703 704 Tn4) Same as Tr4. 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730Huttunen, et al. Standards Track [Page 13] 731 732RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 733 734 735Authors' Addresses 736 737 Ari Huttunen 738 F-Secure Corporation 739 Tammasaarenkatu 7 740 HELSINKI FIN-00181 741 FI 742 743 EMail: Ari.Huttunen@F-Secure.com 744 745 746 Brian Swander 747 Microsoft 748 One Microsoft Way 749 Redmond, WA 98052 750 US 751 752 EMail: briansw@microsoft.com 753 754 755 Victor Volpe 756 Cisco Systems 757 124 Grove Street 758 Suite 205 759 Franklin, MA 02038 760 US 761 762 EMail: vvolpe@cisco.com 763 764 765 Larry DiBurro 766 Nortel Networks 767 80 Central Street 768 Boxborough, MA 01719 769 US 770 771 EMail: ldiburro@nortelnetworks.com 772 773 774 Markus Stenberg 775 FI 776 777 EMail: markus.stenberg@iki.fi 778 779 780 781 782 783 784 785 786Huttunen, et al. Standards Track [Page 14] 787 788RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 789 790 791Full Copyright Statement 792 793 Copyright (C) The Internet Society (2005). 794 795 This document is subject to the rights, licenses and restrictions 796 contained in BCP 78, and except as set forth therein, the authors 797 retain all their rights. 798 799 This document and the information contained herein are provided on an 800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 802 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 803 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 804 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 807Intellectual Property 808 809 The IETF takes no position regarding the validity or scope of any 810 Intellectual Property Rights or other rights that might be claimed to 811 pertain to the implementation or use of the technology described in 812 this document or the extent to which any license under such rights 813 might or might not be available; nor does it represent that it has 814 made any independent effort to identify any such rights. Information 815 on the IETF's procedures with respect to rights in IETF Documents can 816 be found in BCP 78 and BCP 79. 817 818 Copies of IPR disclosures made to the IETF Secretariat and any 819 assurances of licenses to be made available, or the result of an 820 attempt made to obtain a general license or permission for the use of 821 such proprietary rights by implementers or users of this 822 specification can be obtained from the IETF on-line IPR repository at 823 http://www.ietf.org/ipr. 824 825 The IETF invites any interested party to bring to its attention any 826 copyrights, patents or patent applications, or other proprietary 827 rights that may cover technology that may be required to implement 828 this standard. Please address the information to the IETF at ietf- 829 ipr@ietf.org. 830 831Acknowledgement 832 833 Funding for the RFC Editor function is currently provided by the 834 Internet Society. 835 836 837 838 839 840 841 842Huttunen, et al. Standards Track [Page 15] 843 844