1 2 3 4 5 6 7Network Working Group B. Aboba 8Request for Comments: 3715 W. Dixon 9Category: Informational Microsoft 10 March 2004 11 12 13 IPsec-Network Address Translation (NAT) Compatibility Requirements 14 15Status of this Memo 16 17 This memo provides information for the Internet community. It does 18 not specify an Internet standard of any kind. Distribution of this 19 memo is unlimited. 20 21Copyright Notice 22 23 Copyright (C) The Internet Society (2004). All Rights Reserved. 24 25Abstract 26 27 This document describes known incompatibilities between Network 28 Address Translation (NAT) and IPsec, and describes the requirements 29 for addressing them. Perhaps the most common use of IPsec is in 30 providing virtual private networking capabilities. One very popular 31 use of Virtual Private Networks (VPNs) is to provide telecommuter 32 access to the corporate Intranet. Today, NATs are widely deployed in 33 home gateways, as well as in other locations likely to be used by 34 telecommuters, such as hotels. The result is that IPsec-NAT 35 incompatibilities have become a major barrier in the deployment of 36 IPsec in one of its principal uses. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Aboba & Dixon Informational [Page 1] 59 60RFC 3715 IPsec-NAT Compatibility Requirements March 2004 61 62 63Table of Contents 64 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2 67 2. Known Incompatibilities between NA(P)T and IPsec . . . . . . . 3 68 2.1. Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . . 3 69 2.2. NA(P)T Implementation Weaknesses . . . . . . . . . . . . 7 70 2.3. Helper Incompatibilities . . . . . . . . . . . . . . . . 8 71 3. Requirements for IPsec-NAT Compatibility . . . . . . . . . . . 8 72 4. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12 74 4.2. RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 14 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 79 6.2. Informative References . . . . . . . . . . . . . . . . . 16 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 81 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 82 9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 83 841. Introduction 85 86 Perhaps the most common use of IPsec [RFC2401] is in providing 87 virtual private networking (VPN) capabilities. One very popular use 88 of VPNs is to provide telecommuter access to the corporate Intranet. 89 Today, Network Address Translations (NATs) as described in [RFC3022] 90 and [RFC2663], are widely deployed in home gateways, as well as in 91 other locations likely to be used by telecommuters, such as hotels. 92 The result is that IPsec-NAT incompatibilities have become a major 93 barrier in the deployment of IPsec in one of its principal uses. 94 This document describes known incompatibilities between NAT and 95 IPsec, and describes the requirements for addressing them. 96 971.1. Requirements Language 98 99 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 100 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 101 described in [RFC2119]. 102 103 Please note that the requirements specified in this document are to 104 be used in evaluating protocol submissions. As such, the 105 requirements language refers to capabilities of these protocols; the 106 protocol documents will specify whether these features are required, 107 recommended, or optional. For example, requiring that a protocol 108 support confidentiality is not the same thing as requiring that all 109 protocol traffic be encrypted. 110 111 112 113 114Aboba & Dixon Informational [Page 2] 115 116RFC 3715 IPsec-NAT Compatibility Requirements March 2004 117 118 119 A protocol submission is not compliant if it fails to satisfy one or 120 more of the MUST or MUST NOT requirements for the capabilities that 121 it implements. A protocol submission that satisfies all the MUST, 122 MUST NOT, SHOULD, and SHOULD NOT requirements for its capabilities is 123 said to be "unconditionally compliant"; one that satisfies all the 124 MUST and MUST NOT requirements, but not all the SHOULD or SHOULD NOT 125 requirements for its protocols is said to be "conditionally 126 compliant." 127 1282. Known Incompatibilities between NA(P)T and IPsec 129 130 The incompatibilities between NA(P)T and IPsec can be divided into 131 three categories: 132 133 1) Intrinsic NA(P)T issues. These incompatibilities derive directly 134 from the NA(P)T functionality described in [RFC3022]. These 135 incompatibilities will therefore be present in any NA(P)T device. 136 137 2) NA(P)T implementation weaknesses. These incompatibilities are not 138 intrinsic to NA(P)T, but are present in many NA(P)T 139 implementations. Included in this category are problems in 140 handling inbound or outbound fragments. Since these issues are 141 not intrinsic to NA(P)T, they can, in principle, be addressed in 142 future NA(P)T implementations. However, since the implementation 143 problems appear to be wide spread, they need to be taken into 144 account in a NA(P)T traversal solution. 145 146 3) Helper issues. These incompatibilities are present in NA(P)T 147 devices which attempt to provide for IPsec NA(P)T traversal. 148 Ironically, this "helper" functionality creates further 149 incompatibilities, making an already difficult problem harder to 150 solve. While IPsec traversal "helper" functionality is not 151 present in all NA(P)Ts, these features are becoming sufficiently 152 popular that they also need to be taken into account in a NA(P)T 153 traversal solution. 154 1552.1. Intrinsic NA(P)T Issues 156 157 Incompatibilities that are intrinsic to NA(P)T include: 158 159 a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH 160 header incorporates the IP source and destination addresses in the 161 keyed message integrity check, NAT or reverse NAT devices making 162 changes to address fields will invalidate the message integrity 163 check. Since IPsec ESP [RFC2406] does not incorporate the IP 164 source and destination addresses in its keyed message integrity 165 check, this issue does not arise for ESP. 166 167 168 169 170Aboba & Dixon Informational [Page 3] 171 172RFC 3715 IPsec-NAT Compatibility Requirements March 2004 173 174 175 b) Incompatibility between checksums and NAT. TCP and UDP checksums 176 have a dependency on the IP source and destination addresses 177 through inclusion of the "pseudo-header" in the calculation. As a 178 result, where checksums are calculated and checked upon receipt, 179 they will be invalidated by passage through a NAT or reverse NAT 180 device. 181 182 As a result, IPsec Encapsulating Security Payload (ESP) will only 183 pass through a NAT unimpeded if TCP/UDP protocols are not involved 184 (as in IPsec tunnel mode or IPsec protected GRE), or checksums are 185 not calculated (as is possible with IPv4 UDP). As described in 186 [RFC793], TCP checksum calculation and verification is required in 187 IPv4. UDP/TCP checksum calculation and verification is required 188 in IPv6. 189 190 Stream Control Transmission Protocol (SCTP), as defined in 191 [RFC2960] and [RFC3309], uses a CRC32C algorithm calculated only 192 on the SCTP packet (common header + chunks), so that the IP header 193 is not covered. As a result, NATs do not invalidate the SCTP CRC, 194 and the problem does not arise. 195 196 Note that since transport mode IPsec traffic is integrity 197 protected and authenticated using strong cryptography, 198 modifications to the packet can be detected prior to checking 199 UDP/TCP checksums. Thus, checksum verification only provides 200 assurance against errors made in internal processing. 201 202 c) Incompatibility between IKE address identifiers and NAT. Where IP 203 addresses are used as identifiers in Internet Key Exchange 204 Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the 205 IP source or destination addresses by NATs or reverse NATs will 206 result in a mismatch between the identifiers and the addresses in 207 the IP header. As described in [RFC2409], IKE implementations are 208 required to discard such packets. 209 210 In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 211 identifiers, userIDs and FQDNs can be used instead. Where user 212 authentication is desired, an ID type of ID_USER_FQDN can be used, 213 as described in [RFC2407]. Where machine authentication is 214 desired, an ID type of ID_FQDN can be used. In either case, it is 215 necessary to verify that the proposed identifier is authenticated 216 as a result of processing an end-entity certificate, if 217 certificates are exchanged in Phase 1. While use of USER_FQDN or 218 FQDN identity types is possible within IKE, there are usage 219 scenarios (e.g. Security Policy Database (SPD) entries describing 220 subnets) that cannot be accommodated this way. 221 222 223 224 225 226Aboba & Dixon Informational [Page 4] 227 228RFC 3715 IPsec-NAT Compatibility Requirements March 2004 229 230 231 Since the source address in the Phase 2 identifier is often used 232 to form a full 5-tuple inbound SA selector, the destination 233 address, protocol, source port and destination port can be used in 234 the selector so as not to weaken inbound SA processing. 235 236 d) Incompatibility between fixed IKE source ports and NAPT. Where 237 multiple hosts behind the NAPT initiate IKE SAs to the same 238 responder, a mechanism is needed to allow the NAPT to demultiplex 239 the incoming IKE packets from the responder. This is typically 240 accomplished by translating the IKE UDP source port on outbound 241 packets from the initiator. Thus responders must be able to 242 accept IKE traffic from a UDP source port other than 500, and must 243 reply to that port. Care must be taken to avoid unpredictable 244 behavior during re-keys. If the floated source port is not used 245 as the destination port for the re-key, the NAT may not be able to 246 send the re-key packets to the correct destination. 247 248 e) Incompatibilities between overlapping SPD entries and NAT. Where 249 initiating hosts behind a NAT use their source IP addresses in 250 Phase 2 identifiers, they can negotiate overlapping SPD entries 251 with the same responder IP address. The responder could then send 252 packets down the wrong IPsec SA. This occurs because to the 253 responder, the IPsec SAs appear to be equivalent, since they exist 254 between the same endpoints and can be used to pass the same 255 traffic. 256 257 f) Incompatibilities between IPsec SPI selection and NAT. Since 258 IPsec ESP traffic is encrypted and thus opaque to the NAT, the NAT 259 must use elements of the IP and IPsec header to demultiplex 260 incoming IPsec traffic. The combination of the destination IP 261 address, security protocol (AH/ESP), and IPsec SPI is typically 262 used for this purpose. 263 264 However, since the outgoing and incoming SPIs are chosen 265 independently, there is no way for the NAT to determine what 266 incoming SPI corresponds to what destination host merely by 267 inspecting outgoing traffic. Thus, were two hosts behind the NAT 268 to attempt to create IPsec SAs at the same destination 269 simultaneously, it is possible that the NAT will deliver the 270 incoming IPsec packets to the wrong destination. 271 272 Note that this is not an incompatibility with IPsec per se, but 273 rather with the way it is typically implemented. With both AH and 274 ESP, the receiving host specifies the SPI to use for a given SA, a 275 choice which is significant only to the receiver. At present, the 276 combination of Destination IP, SPI, and Security Protocol (AH, 277 ESP) uniquely identifies a Security Association. Also, SPI values 278 in the range 1-255 are reserved to IANA and may be used in the 279 280 281 282Aboba & Dixon Informational [Page 5] 283 284RFC 3715 IPsec-NAT Compatibility Requirements March 2004 285 286 287 future. This means that, when negotiating with the same external 288 host or gateway, the internal hosts behind the same NAPT can 289 select the same SPI value, such that one host inbound SA is 290 (SPI=470, Internal Dest IP=192.168.0.4) 291 and a different host inbound SA is 292 (SPI=470, Internal Dest IP=192.168.0.5). 293 The receiving NAPT will not be able to determine which internal 294 host an inbound IPsec packet with SPI=470 should be forwarded to. 295 296 It is also possible for the receiving host to allocate a unique 297 SPI to each unicast Security Association. In this case, the 298 Destination IP Address need only be checked to see if it is "any 299 valid unicast IP for this host", not checked to see if it is the 300 specific Destination IP address used by the sending host. Using 301 this technique, the NA(P)T can be assured of a low but non-zero 302 chance of forwarding packets to the wrong internal host, even when 303 two or more hosts establish SAs with the same external host. 304 305 This approach is completely backwards compatible, and only 306 requires the particular receiving host to make a change to its SPI 307 allocation and IPsec_esp_input() code. However, NA(P)T devices 308 may not be able to detect this behavior without problems 309 associated with parsing IKE payloads. And a host may still be 310 required to use a SPI in the IANA reserved range for the assigned 311 purpose. 312 313 g) Incompatibilities between embedded IP addresses and NAT. Since 314 the payload is integrity protected, any IP addresses enclosed 315 within IPsec packets will not be translatable by a NAT. This 316 renders ineffective Application Layer Gateways (ALGs) implemented 317 within NATs. Protocols that utilize embedded IP addresses include 318 FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (optionally), and many 319 games. To address this issue, it is necessary to install ALGs on 320 the host or security gateway that can operate on application 321 traffic prior to IPsec encapsulation and after IPsec 322 decapsulation. 323 324 h) Implicit directionality of NA(P)T. NA(P)Ts often require an 325 initial outbound packet to flow through them in order to create an 326 inbound mapping state. Directionality prohibits unsolicited 327 establishment of IPsec SAs to hosts behind the NA(P)T. 328 329 i) Inbound SA selector verification. Assuming IKE negotiates phase 2 330 selectors, inbound SA processing will drop the decapsulated 331 packet, since [RFC2401] requires a packet's source address match 332 the SA selector value, which NA(P)T processing of an ESP packet 333 would change. 334 335 336 337 338Aboba & Dixon Informational [Page 6] 339 340RFC 3715 IPsec-NAT Compatibility Requirements March 2004 341 342 3432.2. NA(P)T Implementation Weaknesses 344 345 Implementation problems present in many NA(P)Ts include: 346 347 j) Inability to handle non-UDP/TCP traffic. Some NA(P)Ts discard 348 non-UDP/TCP traffic or perform address-only translation when only 349 one host is behind the NAT. Such NAPTs are unable to enable SCTP, 350 ESP (protocol 50), or AH (protocol 51) traffic. 351 352 k) NAT mapping timeouts. NA(P)Ts vary in the time for which a UDP 353 mapping will be maintained in the absence of traffic. Thus, even 354 where IKE packets can be correctly translated, the translation 355 state may be removed prematurely. 356 357 l) Inability to handle outgoing fragments. Most NA(P)Ts can properly 358 fragment outgoing IP packets in the case where the IP packet size 359 exceeds the MTU on the outgoing interface. However, proper 360 translation of outgoing packets that are already fragmented is 361 difficult and most NAPTs do not handle this correctly. As noted 362 in Section 6.3 of [RFC3022], where two hosts originate fragmented 363 packets to the same destination, the fragment identifiers can 364 overlap. Since the destination host relies on the fragmentation 365 identifier and fragment offset for reassembly, the result will be 366 data corruption. Few NA(P)Ts protect against identifier 367 collisions by supporting identifier translation. Identifier 368 collisions are not an issue when NATs perform the fragmentation, 369 since the fragment identifier need only be unique within a 370 source/destination IP address pair. 371 372 Since a fragment can be as small as 68 octets [RFC791], there is 373 no guarantee that the first fragment will contain a complete TCP 374 header. Thus, a NA(P)T looking to recalculate the TCP checksum 375 may need to modify a subsequent fragment. Since fragments can be 376 reordered, and IP addresses can be embedded and possibly even 377 split between fragments, the NA(P)T will need to perform 378 reassembly prior to completing the translation. Few NA(P)Ts 379 support this. 380 381 m) Inability to handle incoming fragments. Since only the first 382 fragment will typically contain a complete IP/UDP/SCTP/TCP header, 383 NAPTs need to be able to perform the translation based on the 384 source/dest IP address and fragment identifier alone. Since 385 fragments can be reordered, the headers to a given fragment 386 identifier may not be known if a subsequent fragment arrives prior 387 to the initial one, and the headers may be split between 388 fragments. As a result, the NAPT may need to perform reassembly 389 prior to completing the translation. Few NAPTs support this. 390 Note that with NAT, the source/dest IP address is enough to 391 392 393 394Aboba & Dixon Informational [Page 7] 395 396RFC 3715 IPsec-NAT Compatibility Requirements March 2004 397 398 399 determine the translation so that this does not arise. However, 400 it is possible for the IPsec or IKE headers to be split between 401 fragments, so that reassembly may still be required. 402 4032.3. Helper Incompatibilities 404 405 Incompatibilities between IPsec and NAT "helper" functionality 406 include: 407 408 n) Internet Security Association and Key Management Protocol (ISAKMP) 409 header inspection. Today some NAT implementations attempt to use 410 IKE cookies to de-multiplex incoming IKE traffic. As with 411 source-port de-multiplexing, IKE cookie de-multiplexing results in 412 problems with re-keying, since Phase 1 re-keys typically will not 413 use the same cookies as the earlier traffic. 414 415 o) Special treatment of port 500. Since some IKE implementations are 416 unable to handle non-500 UDP source ports, some NATs do not 417 translate packets with a UDP source port of 500. This means that 418 these NATs are limited to one IPsec client per destination 419 gateway, unless they inspect details of the ISAKMP header to 420 examine cookies which creates the problem noted above. 421 422 p) ISAKMP payload inspection. NA(P)T implementations that attempt to 423 parse ISAKMP payloads may not handle all payload ordering 424 combinations, or support vendor_id payloads for IKE option 425 negotiation. 426 4273. Requirements for IPsec-NAT Compatibility 428 429 The goal of an IPsec-NAT compatibility solution is to expand the 430 range of usable IPsec functionality beyond that available in the 431 NAT-compatible IPsec tunnel mode solution described in Section 2.3. 432 433 In evaluating a solution to IPsec-NAT incompatibility, the following 434 criteria should be kept in mind: 435 436 Deployment 437 438 Since IPv6 will address the address scarcity issues that 439 frequently lead to use of NA(P)Ts with IPv4, the IPsec-NAT 440 compatibility issue is a transitional problem that needs to be 441 solved in the time frame prior to widespread deployment of IPv6. 442 Therefore, to be useful, an IPsec-NAT compatibility solution MUST 443 be deployable on a shorter time scale than IPv6. 444 445 446 447 448 449 450Aboba & Dixon Informational [Page 8] 451 452RFC 3715 IPsec-NAT Compatibility Requirements March 2004 453 454 455 Since IPv6 deployment requires changes to routers as well as 456 hosts, a potential IPsec-NAT compatibility solution, which 457 requires changes to both routers and hosts, will be deployable on 458 approximately the same time scale as IPv6. Thus, an IPsec-NAT 459 compatibility solution SHOULD require changes only to hosts, and 460 not to routers. 461 462 Among other things, this implies that communication between the 463 host and the NA(P)T SHOULD NOT be required by an IPsec-NAT 464 compatibility solution, since that would require changes to the 465 NA(P)Ts, and interoperability testing between the host and NA(P)T 466 implementations. In order to enable deployment in the short term, 467 it is necessary for the solution to work with existing router and 468 NA(P)T products within the deployed infrastructure. 469 470 Protocol Compatibility 471 472 An IPsec NAT traversal solution is not expected to resolve issues 473 with protocols that cannot traverse NA(P)T when unsecured with 474 IPsec. Therefore, ALGs may still be needed for some protocols, 475 even when an IPsec NAT traversal solution is available. 476 477 Security 478 479 Since NA(P)T directionality serves a security function, IPsec 480 NA(P)T traversal solutions should not allow arbitrary incoming 481 IPsec or IKE traffic from any IP address to be received by a host 482 behind the NA(P)T, although mapping state should be maintained 483 once bidirectional IKE and IPsec communication is established. 484 485 Telecommuter Scenario 486 487 Since one of the primary uses of IPsec is remote access to 488 corporate Intranets, a NA(P)T traversal solution MUST support 489 NA(P)T traversal, via either IPsec tunnel mode or L2TP over IPsec 490 transport mode [RFC3193]. This includes support for traversal of 491 more than one NA(P)T between the remote client and the VPN 492 gateway. 493 494 The client may have a routable address and the VPN gateway may be 495 behind at least one NA(P)T, or alternatively, both the client and 496 the VPN gateway may be behind one or more NA(P)Ts. Telecommuters 497 may use the same private IP address, each behind their own NA(P)T, 498 or many telecommuters may reside on a private network behind the 499 same NA(P)T, each with their own unique private address, 500 connecting to the same VPN gateway. Since IKE uses UDP port 500 501 as the destination, it is not necessary to enable multiple VPN 502 gateways operating behind the same external IP address. 503 504 505 506Aboba & Dixon Informational [Page 9] 507 508RFC 3715 IPsec-NAT Compatibility Requirements March 2004 509 510 511 Gateway-to-Gateway Scenario 512 513 In a gateway-gateway scenario, a privately addressed network (DMZ) 514 may be inserted between the corporate network and the Internet. 515 In this design, IPsec security gateways connecting portions of the 516 corporate network may be resident in the DMZ and have private 517 addresses on their external (DMZ) interfaces. A NA(P)T connects 518 the DMZ network to the Internet. 519 520 End-to-End Scenario 521 522 A NAT-IPsec solution MUST enable secure host-host TCP/IP 523 communication via IPsec, as well as host-gateway communications. 524 A host on a private network MUST be able to bring up one or 525 multiple IPsec-protected TCP connections or UDP sessions to 526 another host with one or more NA(P)Ts between them. For example, 527 NA(P)Ts may be deployed within branch offices connecting to the 528 corporate network, with an additional NA(P)T connecting the 529 corporate network to the Internet. Likewise, NA(P)Ts may be 530 deployed within a corporate network LAN or WAN to connect wireless 531 or remote location clients to the corporate network. This may 532 require special processing of TCP and UDP traffic on the host. 533 534 Bringing up SCTP connections to another host with one or more NA(P)Ts 535 between them may present special challenges. SCTP supports multi- 536 homing. If more than one IP address is used, these addresses are 537 transported as part of the SCTP packet during the association setup 538 (in the INIT and INIT-ACK chunks). If only single homed SCTP end- 539 points are used, [RFC2960] section 3.3.2.1 states: 540 541 Note that not using any IP address parameters in the INIT and 542 INIT-ACK is an alternative to make an association more likely 543 to work across a NAT box. 544 545 This implies that IP addresses should not be put into the SCTP packet 546 unless necessary. If NATs are present and IP addresses are included, 547 then association setup will fail. Recently [AddIP] has been proposed 548 which allows the modification of the IP address once an association 549 is established. The modification messages have also IP addresses in 550 the SCTP packet, and so will be adversely affected by NATs. 551 552 Firewall Compatibility 553 554 Since firewalls are widely deployed, a NAT-IPsec compatibility 555 solution MUST enable a firewall administrator to create simple, 556 static access rule(s) to permit or deny IKE and IPsec NA(P)T 557 traversal traffic. This implies, for example, that dynamic 558 allocation of IKE or IPsec destination ports is to be avoided. 559 560 561 562Aboba & Dixon Informational [Page 10] 563 564RFC 3715 IPsec-NAT Compatibility Requirements March 2004 565 566 567 Scaling 568 569 An IPsec-NAT compatibility solution should be capable of being 570 deployed within an installation consisting of thousands of 571 telecommuters. In this situation, it is not possible to assume 572 that only a single host is communicating with a given destination 573 at a time. Thus, an IPsec-NAT compatibility solution MUST address 574 the issue of overlapping SPD entries and de-multiplexing of 575 incoming packets. 576 577 Mode Support 578 579 At a minimum, an IPsec-NAT compatibility solution MUST support 580 traversal of the IKE and IPsec modes required for support within 581 [RFC2409] and [RFC2401]. For example, an IPsec gateway MUST 582 support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST 583 support IPsec transport mode NA(P)T traversal. The purpose of AH 584 is to protect immutable fields within the IP header (including 585 addresses), and NA(P)T translates addresses, invalidating the AH 586 integrity check. As a result, NA(P)T and AH are fundamentally 587 incompatible and there is no requirement that an IPsec-NAT 588 compatibility solution support AH transport or tunnel mode. 589 590 Backward Compatibility and Interoperability 591 592 An IPsec-NAT compatibility solution MUST be interoperable with 593 existing IKE/IPsec implementations, so that they can communicate 594 where no NA(P)T is present. This implies that an IPsec-NAT 595 compatibility solution MUST be backwards-compatible with IPsec as 596 defined in [RFC2401] and IKE as defined in [RFC2409]. In 597 addition, it SHOULD be able to detect the presence of a NA(P)T, so 598 that NA(P)T traversal support is only used when necessary. This 599 implies that it MUST be possible to determine that an existing IKE 600 implementation does not support NA(P)T traversal, so that a 601 standard IKE conversation can occur, as described in [RFC2407], 602 [RFC2408], and [RFC2409]. Note that while this implies initiation 603 of IKE to port 500, there is no requirement for a specific source 604 port, so that UDP source port 500 may or may not be used. 605 606 Security 607 608 An IPsec-NAT compatibility solution MUST NOT introduce additional 609 IKE or IPsec security vulnerabilities. For example, an acceptable 610 solution must demonstrate that it introduces no new denial of 611 service or spoofing vulnerabilities. IKE MUST be allowed to re- 612 key in a bi-directional manner as described in [RFC2408]. 613 614 615 616 617 618Aboba & Dixon Informational [Page 11] 619 620RFC 3715 IPsec-NAT Compatibility Requirements March 2004 621 622 6234. Existing Solutions 624 6254.1. IPsec Tunnel Mode 626 627 In a limited set of circumstances, it is possible for an IPsec tunnel 628 mode implementation, such as that described in [DHCP], to traverse 629 NA(P)T successfully. However, the requirements for successful 630 traversal are sufficiently limited so that a more general solution is 631 needed: 632 633 1) IPsec ESP. IPsec ESP tunnels do not cover the outer IP header 634 within the message integrity check, and so will not suffer 635 Authentication Data invalidation due to address translation. 636 IPsec tunnels also need not be concerned about checksum 637 invalidation. 638 639 2) No address validation. Most current IPsec tunnel mode 640 implementations do not perform source address validation so that 641 incompatibilities between IKE identifiers and source addresses 642 will not be detected. This introduces security vulnerabilities as 643 described in Section 5. 644 645 3) "Any to Any" SPD entries. IPsec tunnel mode clients can negotiate 646 "any to any" SPDs, which are not invalidated by address 647 translation. This effectively precludes use of SPDs for the 648 filtering of allowed tunnel traffic. 649 650 4) Single client operation. With only a single client behind a NAT, 651 there is no risk of overlapping SPDs. Since the NAT will not need 652 to arbitrate between competing clients, there is also no risk of 653 re-key mis-translation, or improper incoming SPI or cookie 654 de-multiplexing. 655 656 5) No fragmentation. When certificate authentication is used, IKE 657 fragmentation can be encountered. This can occur when certificate 658 chains are used, or even when exchanging a single certificate if 659 the key size, or the size of other certificate fields (such as the 660 distinguished name and other extensions), is large enough. 661 However, when pre-shared keys are used for authentication, 662 fragmentation is less likely. 663 664 6) Active sessions. Most VPN sessions typically maintain ongoing 665 traffic flow during their lifetime so that UDP port mappings are 666 less likely be removed due to inactivity. 667 668 669 670 671 672 673 674Aboba & Dixon Informational [Page 12] 675 676RFC 3715 IPsec-NAT Compatibility Requirements March 2004 677 678 6794.2. RSIP 680 681 RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for 682 IPsec traversal, as described in [RSIPsec]. By enabling host-NA(P)T 683 communication, RSIP addresses issues of IPsec SPI de-multiplexing, as 684 well as SPD overlap. It is thus suitable for use in enterprises, as 685 well as home networking scenarios. By enabling hosts behind a NAT to 686 share the external IP address of the NA(P)T (the RSIP gateway), this 687 approach is compatible with protocols including embedded IP 688 addresses. 689 690 By tunneling IKE and IPsec packets, RSIP avoids changes to the IKE 691 and IPsec protocols, although major changes are required to host IKE 692 and IPsec implementations to retrofit them for RSIP-compatibility. 693 It is thus compatible with all existing protocols (AH/ESP) and modes 694 (transport and tunnel). 695 696 In order to handle de-multiplexing of IKE re-keys, RSIP requires 697 floating of the IKE source port, as well as re-keying to the floated 698 port. As a result, interoperability with existing IPsec 699 implementations is not assured. 700 701 RSIP does not satisfy the deployment requirements for an IPsec-NAT 702 compatibility solution because an RSIP-enabled host requires a 703 corresponding RSIP-enabled gateway in order to establish an IPsec SA 704 with another host. Since RSIP requires changes only to clients and 705 routers and not to servers, it is less difficult to deploy than IPv6. 706 However, for vendors, implementation of RSIP requires a substantial 707 fraction of the resources required for IPv6 support. Thus, RSIP 708 solves a "transitional" problem on a long-term time scale, which is 709 not useful. 710 7114.3. 6to4 712 713 6to4, as described in [RFC3056] can form the basis for an IPsec-NAT 714 traversal solution. In this approach, the NAT provides IPv6 hosts 715 with an IPv6 prefix derived from the NAT external IPv4 address, and 716 encapsulates IPv6 packets in IPv4 for transmission to other 6to4 717 hosts or 6to4 relays. This enables an IPv6 host using IPsec to 718 communicate freely to other hosts within the IPv6 or 6to4 clouds. 719 720 While 6to4 is an elegant and robust solution where a single NA(P)T 721 separates a client and VPN gateway, it is not universally applicable. 722 Since 6to4 requires the assignment of a routable IPv4 address to the 723 NA(P)T in order to allow formation of an IPv6 prefix, it is not 724 usable where multiple NA(P)Ts exist between the client and VPN 725 726 727 728 729 730Aboba & Dixon Informational [Page 13] 731 732RFC 3715 IPsec-NAT Compatibility Requirements March 2004 733 734 735 gateway. For example, an NA(P)T with a private address on its 736 external interface cannot be used by clients behind it to obtain an 737 IPv6 prefix via 6to4. 738 739 While 6to4 requires little additional support from hosts that already 740 support IPv6, it does require changes to NATs, which need to be 741 upgraded to support 6to4. As a result, 6to4 may not be suitable for 742 deployment in the short term. 743 7445. Security Considerations 745 746 By definition, IPsec-NAT compatibility requires that hosts and 747 routers implementing IPsec be capable of securely processing packets 748 whose IP headers are not cryptographically protected. A number of 749 issues arise from this that are worth discussing. 750 751 Since IPsec AH cannot pass through a NAT, one of the side effects of 752 providing an IPsec-NAT compatibility solution may be for IPsec ESP 753 with null encryption to be used in place of AH where a NAT exists 754 between the source and destination. However, it should be noted that 755 ESP with null encryption does not provide the same security 756 properties as AH. For example, there are security risks relating to 757 IPv6 source routing that are precluded by AH, but not by ESP with 758 null encryption. 759 760 In addition, since ESP with any transform does not protect against 761 source address spoofing, some sort of source IP address sanity 762 checking needs to be performed. The importance of the anti-spoofing 763 check is not widely understood. There is normally an anti-spoofing 764 check on the Source IP Address as part of IPsec_{esp,ah}_input(). 765 This ensures that the packet originates from the same address as that 766 claimed within the original IKE Phase 1 and Phase 2 security 767 associations. When a receiving host is behind a NAT, this check 768 might not strictly be meaningful for unicast sessions, whereas in the 769 Global Internet this check is important for tunnel-mode unicast 770 sessions to prevent a spoofing attack described in [AuthSource], 771 which can occur when access controls on the receiver depend upon the 772 source IP address of verified ESP packets after decapsulation. 773 IPsec-NAT compatibility schemes should provide anti-spoofing 774 protection if it uses source addresses for access controls. 775 776 Let us consider two hosts, A and C, both behind (different) NATs, who 777 negotiate IPsec tunnel mode SAs to router B. Hosts A and C may have 778 different privileges; for example, host A might belong to an employee 779 trusted to access much of the corporate Intranet, while C might be a 780 contractor only authorized to access a specific web site. 781 782 783 784 785 786Aboba & Dixon Informational [Page 14] 787 788RFC 3715 IPsec-NAT Compatibility Requirements March 2004 789 790 791 If host C sends a tunnel mode packet spoofing A's IP address as the 792 source, it is important that this packet not be accorded the 793 privileges corresponding to A. If authentication and integrity 794 checking is performed, but no anti-spoofing check (verifying that the 795 originating IP address corresponds to the SPI) then host C may be 796 allowed to reach parts of the network that are off limits. As a 797 result, an IPsec-NAT compatibility scheme MUST provide some degree of 798 anti-spoofing protection. 799 8006. References 801 8026.1. Normative References 803 804 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 805 September 1981. 806 807 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 808 793, September 1981. 809 810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 811 Requirement Levels", BCP 14, RFC 2119, March 1997. 812 813 [RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the 814 Internet Protocol", RFC 2401, November 1998. 815 816 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 817 RFC 2402, November 1998. 818 819 [RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security 820 Payload (ESP)", RFC 2406, November 1998. 821 822 [RFC2407] Piper, D., "The Internet IP Security Domain of 823 Interpretation for ISAKMP", RFC 2407, November 1998. 824 825 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 826 (IKE)", RFC 2409, November 1998. 827 828 [RFC2663] Srisuresh, P. and M. Holdredge, "IP Network Address 829 Translator (NAT) Terminology and Considerations", RFC 830 2663, August 1999. 831 832 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 833 Address Translator (Traditional NAT)", RFC 3022, January 834 2001. 835 836 837 838 839 840 841 842Aboba & Dixon Informational [Page 15] 843 844RFC 3715 IPsec-NAT Compatibility Requirements March 2004 845 846 8476.2. Informative References 848 849 [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, 850 "Internet Security Association and Key Management 851 Protocol (ISAKMP)", RFC 2408, November 1998. 852 853 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 854 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 855 Zhang, M. and V. Paxson, "Stream Control Transmission 856 Protocol", RFC 2960, October 2000. 857 858 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 859 via IPv4 Clouds", RFC 3056, February 2001. 860 861 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, 862 "Securing L2TP using IPsec", RFC 3193, November 2001. 863 864 [RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control 865 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 866 September 2002. 867 868 [RSIPFrame] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, 869 "Realm Specific IP: Framework", RFC 3102, October 2001. 870 871 [RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, 872 "Realm Specific IP: Protocol Specification", RFC 3103, 873 October 2001. 874 875 [RSIPsec] Montenegro, G. and M. Borella, "RSIP Support for End- 876 to-End IPsec", RFC 3104, October 2001. 877 878 [DHCP] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic 879 Host Configuration Protocol (DHCPv4) Configuration of 880 IPsec Tunnel Mode", RFC 3456, January 2003. 881 882 [AuthSource] Kent, S., "Authenticated Source Addresses", IPsec WG 883 Archive (ftp://ftp.ans.net/pub/archive/IPsec), Message- 884 Id: <v02130517ad121773c8ed@[128.89.0.110]>, January 5, 885 1996. 886 887 [AddIP] Stewart, R., et al., "Stream Control Transmission 888 Protocol (SCTP) Dynamic Address Reconfiguration", Work 889 in Progress. 890 891 892 893 894 895 896 897 898Aboba & Dixon Informational [Page 16] 899 900RFC 3715 IPsec-NAT Compatibility Requirements March 2004 901 902 9037. Acknowledgments 904 905 Thanks to Steve Bellovin of AT&T Research, Michael Tuexen of Siemens, 906 Peter Ford of Microsoft, Ran Atkinson of Extreme Networks, and Daniel 907 Senie for useful discussions of this problem space. 908 9098. Authors' Addresses 910 911 Bernard Aboba 912 Microsoft Corporation 913 One Microsoft Way 914 Redmond, WA 98052 915 916 Phone: +1 425 706 6605 917 Fax: +1 425 936 7329 918 EMail: bernarda@microsoft.com 919 920 921 William Dixon 922 V6 Security, Inc. 923 601 Union Square, Suite #4200-300 924 Seattle, WA 98101 925 926 EMail: ietf-wd@v6security.com 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954Aboba & Dixon Informational [Page 17] 955 956RFC 3715 IPsec-NAT Compatibility Requirements March 2004 957 958 9599. Full Copyright Statement 960 961 Copyright (C) The Internet Society (2004). This document is subject 962 to the rights, licenses and restrictions contained in BCP 78 and 963 except as set forth therein, the authors retain all their rights. 964 965 This document and the information contained herein are provided on an 966 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 967 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 968 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 969 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 970 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 971 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 972 973Intellectual Property 974 975 The IETF takes no position regarding the validity or scope of any 976 Intellectual Property Rights or other rights that might be claimed to 977 pertain to the implementation or use of the technology described in 978 this document or the extent to which any license under such rights 979 might or might not be available; nor does it represent that it has 980 made any independent effort to identify any such rights. Information 981 on the procedures with respect to rights in RFC documents can be 982 found in BCP 78 and BCP 79. 983 984 Copies of IPR disclosures made to the IETF Secretariat and any 985 assurances of licenses to be made available, or the result of an 986 attempt made to obtain a general license or permission for the use of 987 such proprietary rights by implementers or users of this 988 specification can be obtained from the IETF on-line IPR repository at 989 http://www.ietf.org/ipr. 990 991 The IETF invites any interested party to bring to its attention any 992 copyrights, patents or patent applications, or other proprietary 993 rights that may cover technology that may be required to implement 994 this standard. Please address the information to the IETF at ietf- 995 ipr@ietf.org. 996 997Acknowledgement 998 999 Funding for the RFC Editor function is currently provided by the 1000 Internet Society. 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010Aboba & Dixon Informational [Page 18] 1011 1012