idnits 2.17.1 draft-ietf-ipsec-nat-reqts-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 222 has weird spacing: '....4) and a dif...' == 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 (18 August 2002) is 7921 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 448 -- Looks like a reference, but probably isn't: '2' on line 453 -- Looks like a reference, but probably isn't: '3' on line 459 -- Looks like a reference, but probably isn't: '4' on line 464 == Missing Reference: 'RFC790' is mentioned on line 273, but not defined ** Obsolete undefined reference: RFC 790 (Obsoleted by RFC 820) == Missing Reference: 'RFC 3193' is mentioned on line 356, but not defined == Missing Reference: 'RFC2408' is mentioned on line 437, but not defined ** Obsolete undefined reference: RFC 2408 (Obsoleted by RFC 4306) -- Looks like a reference, but probably isn't: '5' on line 470 -- Looks like a reference, but probably isn't: '6' on line 478 == Unused Reference: 'RFC791' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC2661' is defined on line 616, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Unexpected draft version: The latest known version of draft-ietf-ipsec-dhcp is -12, but you're referring to -13. Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsec Working Group Bernard Aboba 3 INTERNET-DRAFT William Dixon 4 Category: Informational Microsoft 5 6 18 August 2002 8 IPsec-NAT Compatibility Requirements 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 Perhaps the most common use of IPsec is in providing virtual private 37 networking capabilities. One very popular use of VPNs is to provide 38 telecommuter access to the corporate Intranet. Today NATs are widely 39 deployed in home gateways, as well as in other locations likely to be 40 used by telecommuters, such as hotels. The result is that IPsec-NAT 41 incompatibilities have become a major barrier to deployment of IPsec in 42 one of its principal uses. This draft describes known incompatibilities 43 between NAT and IPsec, and describes the requirements for addressing 44 them. 46 Table of Contents 48 1. Introduction .......................................... 3 49 1.1 Requirements language ........................... 3 50 2. Known incomptabilities between NA(P)T and IPsec ....... 3 51 2.1 Intrinsic NA(P)T issues ......................... 4 52 2.2 NA(P)T implementation weaknesses ................ 6 53 2.3 Helper incompatibilities ........................ 7 54 3. Requirements for IPsec-NAT compatibility .............. 8 55 4. Existing solutions .................................... 10 56 4.1 IPsec tunnel mode ............................... 10 57 4.2 RSIP ............................................ 11 58 4.3 6to4 ............................................ 12 59 5. Security considerations ............................... 12 60 6. Normative references .................................. 13 61 7. Informative references ................................ 14 62 ACKNOWLEDGMENTS .............................................. 15 63 AUTHORS' ADDRESSES ........................................... 15 64 Full Copyright Statement ..................................... 15 65 Intellectual property statement .............................. 16 66 1. Introduction 68 Perhaps the most common use of IPsec [RFC2401] is in providing virtual 69 private networking capabilities. One very popular use of VPNs is to 70 provide telecommuter access to the corporate Intranet. Today NATs, as 71 described in [RFC3022] and [RFC2663], are widely deployed in home 72 gateways, as well as in other locations likely to be used by 73 telecommuters, such as hotels. The result is that IPsec-NAT 74 incompatibilities have become a major barrier to deployment of IPsec in 75 one of its principal uses. This draft describes known incompatibilities 76 between NAT and IPsec, and describes the requirements for addressing 77 them. 79 1.1. Requirements language 81 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 82 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 83 described in [RFC2119]. 85 Please note that the requirements specified in this document are to be 86 used in evaluating protocol submissions. As such, the requirements 87 language refers to capabilities of these protocols; the protocol 88 documents will specify whether these features are required, recommended, 89 or optional. For example, requiring that a protocol support 90 confidentiality is NOT the same thing as requiring that all protocol 91 traffic be encrypted. 93 A protocol submission is not compliant if it fails to satisfy one or 94 more of the MUST or MUST NOT requirements for the capabilities that it 95 implements. A protocol submission that satisfies all the MUST, MUST 96 NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to 97 be "unconditionally compliant"; one that satisfies all the MUST and MUST 98 NOT requirements but not all the SHOULD or SHOULD NOT requirements for 99 its protocols is said to be "conditionally compliant." 101 2. Known incompatibilities between NA(P)T and IPsec 103 The incompatibilities between NA(P)T and IPsec can be divided into three 104 categories: 106 [1] Intrinsic NA(P)T issues. These incompatibilities derive directly 107 from the NA(P)T functionality described in [RFC3022]. These 108 incompatibilities will therefore be present in any NA(P)T device. 110 [2] NA(P)T implementation weaknesses. These incompatibilities are not 111 intrinsic to NA(P)T, but are present in many NA(P)T 112 implementations. Included in this category are problems in handling 113 inbound or outbound fragments. Since these issues are not 114 intrinsic to NA(P)T, they can in principle be addressed in future 115 NA(P)T implementations. However, since the implementation problems 116 appear to be wide spread, they need to be taken into account in a 117 NA(P)T traversal solution. 119 [3] Helper issues. These incompatibilities are present in NA(P)T 120 devices which attempt to provide for IPsec NA(P)T traversal. 121 Ironically, this "helper" functionality creates further 122 incompatibilities, making an already difficult problem harder to 123 solve. While IPsec traversal "helper" functionality is not present 124 in all NA(P)Ts, these features are becoming sufficiently popular 125 that they also need to be taken into account in a NA(P)T traversal 126 solution. 128 2.1. Intrinsic NA(P)T issues 130 Incompatibilities that are intrinsic to NA(P)T include: 132 a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header 133 incorporates the IP source and destination addresses in the 134 keyed message integrity check, NAT or reverse NAT devices making changes 135 to address fields will invalidate the message integrity check. 136 Since IPsec ESP [4] does not incorporate the IP source and 137 destination addresses in its keyed message integrity check, 138 this issue does not arise for ESP. 140 b) Incompatibility between checksums and NAT. TCP/UDP/SCTP 141 checksums have a dependency on the IP source and destination 142 addresses through inclusion of the "pseudo-header" in the 143 calculation. As a result, where checksums are calculated and 144 checked on receipt, they will be invalidated by passage through 145 a NAT or reverse NAT device. 147 As a result, IPsec ESP will only pass unimpeded through a NAT if 148 TCP/UDP/SCTP protocols are not involved (as in IPsec tunnel 149 mode or IPsec/GRE), or checksums are not calculated (as is 150 possible with IPv4 UDP). As described in [RFC793], TCP checksum 151 calculation and verification is required in IPv4. UDP/TCP 152 checksum calculation and verification is required in IPv6. 154 Note that since transport mode IPsec traffic is integrity protected 155 and authenticated using strong cryptography, modifications 156 to the packet can be detected prior to checking UDP/TCP/SCTP 157 checksums. Thus, checksum verification only provides assurance 158 against errors made in internal processing. 160 c) Incompatibility between IKE address identifiers and NAT. 161 Where IP addresses are used as identifiers in IKE MM [RFC2409] 162 or QM, modification of the IP source or destination 163 addresses by NATs or reverse NATs will result in a 164 mismatch between the identifiers and the addresses in the 165 IP header. As described in [RFC2409], IKE implementations are 166 required to discard such packets. 168 In order to avoid use of IP addresses as IKE MM and QM identifiers, 169 userIDs and FQDNs can be used instead. Where user authentication 170 is desired, an ID type of ID_USER_FQDN can be used, as described in 171 [RFC2407]. Where machine authentication is desired, an ID type 172 of ID_FQDN can be used. In either case it is necessary to verify 173 that the proposed identity matches that enclosed in the certificate. 174 However, while use of USER_FQDN or FQDN identity types is possible 175 within IKE, there are usage scenarios (e.g. SPD entries 176 describing subnets) that cannot be accommodated this way. 178 d) Incompatibility between fixed IKE destination ports and NAPT. 179 Where multiple hosts behind the NAPT initiate 180 IKE SAs to the same responder, a mechanism is needed 181 to allow the NAPT to demultiplex the incoming IKE 182 packets. This is typically accomplished by translating 183 the IKE UDP source port. While it is permissible to float 184 the IKE UDP source port, this can result in unpredictable 185 behavior during re-keys. Unless the floated source port is 186 used as the destination port for the re key, the NAT may 187 not be able to send the re-key packets to the correct 188 destination. 190 e) Incompatibilities between overlapping SPD entries and NAT. 191 Where hosts behind a NAT negotiate overlapping SPD entries 192 with the same destination in IKE QM, packets may be sent 193 down the wrong IPsec SA. This occurs because to the 194 sender, the IPsec SAs appear to be equivalent, since they 195 exist between the same endpoints and can be used to pass 196 the same traffic. 198 f) Incompatibilities between IPsec SPI selection and NAT. 199 Since IPsec ESP traffic is encrypted and thus opaque to the NAT, 200 the NAT must use elements of the IP and IPsec header to 201 demultiplex incoming IPsec traffic. The combination of the 202 destination IP address, security protocol (AH/ESP) and IPsec SPI 203 is typically used for this purpose. 205 However, since the outgoing and incoming SPIs are chosen 206 independently, there is no way for the NAT to determine 207 what incoming SPI corresponds to what destination host 208 merely by inspecting outgoing traffic. Thus, were two 209 hosts behind the NAT to attempt to bring up IPsec SAs to 210 the same destination simultaneously, it is possible that 211 the NAT will send the incoming IPsec packets to the 212 wrong destination. 214 Note that this is not an incompatibility with IPsec per 215 se, but rather with the way it is typically implemented. 216 With both AH and ESP, the receiving host specifies the 217 SPI to use for a given SA. At present, the combination of 218 Destination IP, SPI, and Security Protocol (AH, ESP) uniquely 219 identifies a Security Association. This means that the 220 receiving host can select SPIs such that 221 it has one Security Association (SA) with (SPI=470, 222 Dest IP=1.2.3.4) and a different Security Association with 223 (SPI=470, Dest IP=2.3.4.5). 225 It is also possible for the receiving host to allocate 226 a unique SPI to each unicast Security Association. In 227 this case, the Destination IP Address need only be checked 228 to see if it is "any valid unicast IP for this host", not 229 checked to see if it is the specific Destination IP address 230 used by the sending host. This approach is completely backwards 231 compatible and only requires the particular receiving host to 232 make a change to its SPI allocation and IPsec_esp_input() code. 234 g) Incompatibilities between embedded IP addresses and NAT. 235 Since the payload is integrity protected, any IP addresses 236 enclosed within IPsec packets will not be translatable by a 237 NAT. This renders ineffective Application Layer Gateways (ALGs) 238 implemented within NATs. Protocols that utilize embedded IP addresses 239 include FTP, IRC, SNMP, LDAP, H.323, SIP and many games. To 240 address this issue, it is necessary to install ALGs on the host 241 which can operate on application traffic prior to IPsec encapsulation 242 and after IPsec decapsulation. 244 2.2. NA(P)T implementation weaknesses 246 Implementation problems present in many NA(P)Ts include: 248 h) Inability to handle non-UDP/TCP traffic. Some NAPTs discard 249 non-UDP/TCP traffic. Such NAPTs are unable to pass 250 ESP (protocol 50) or AH (protocol 51) traffic. 252 i) UDP "keepalive" timers. NA(P)Ts vary in the time for which an 253 a UDP mapping will be maintained in the absence of traffic. 254 Thus, even where IKE packets can be correctly translated, the 255 translation state may be removed prematurely. 257 j) Inability to handle outgoing fragments. Most NA(P)Ts can 258 properly fragment outgoing IP packets in the case where 259 the IP packet size exceeds the MTU on the outgoing interface. 260 However, proper translation of outgoing packets that are already 261 fragmented is difficult and most NAPTs do not handle this 262 correctly. As noted in Section 6.3 of [RFC3022], where two 263 hosts originate fragmented packets to the same 264 destination, the fragment identifiers can overlap. Since 265 the destination host relies on the fragmentation 266 identifier and fragment offset for reassembly, the result 267 will be data corruption. Few NA(P)Ts protect against 268 identifier collisions by supporting identifier translation. 269 Identifier collisions are not an issue when NATs perform 270 the fragmentation, since the fragment identifier need only 271 be unique within a source/destination IP address pair. 273 Since a fragment can be as small as 68 octets [RFC790], 274 there is no guarantee that the first fragment will contain a 275 complete TCP header. Thus, a NA(P)T looking to recalculate the 276 TCP checksum may need to modify a subsequent fragment. Since 277 fragments can be reordered, and IP addresses can be embedded 278 and possibly even split between fragments, the NA(P)T will 279 need to perform reassembly prior to completing the translation. 280 Few NA(P)Ts support this. 282 k) Inability to handle incoming fragments. Since only the first 283 fragment will typically contain a complete IP/UDP/TCP header, 284 NAPTs need to be able to perform the translation based on the 285 source/dest IP address and fragment identifier alone. Since fragments 286 can be reordered, the UDP/TCP header to a given fragment identifier 287 may not be known if a subsequent fragment arrives prior to the 288 initial one, and the TCP header may be split between fragments. 289 As a result, the NAPT may need to perform reassembly prior to 290 completing the translation. Few NAPTs support this. Note that with 291 NAT, the source/dest IP address is enough to determine the translation, 292 so that this does not arise. However, it is possible for the IPsec 293 or IKE headers to be split between fragments, so that reassembly 294 may still be required. 296 2.3. Helper incompatibilities 298 Incompatibilities between IPsec and NAT "helper" functionality include: 300 l) ISAKMP header inspection. Today some NAT implementations attempt 301 to use IKE cookies to de-multiplex incoming IKE traffic. As with 302 source-port de-multiplexing, IKE cookie de-multiplexing results 303 in problems with re-keying, since re-keys typically will 304 not use the same cookies as the earlier traffic. 306 m) Special treatment of port 500. Since some IKE implementations 307 are unable to handle non-500 UDP source ports, some NATs 308 do not translate packets with a UDP source port of 500. This 309 means that these NATs are limited to one IPsec client per 310 destination gateway, unless they inspect details of the 311 ISAKMP header to examine cookies which creates the problem 312 noted above. 314 n) ISAKMP payload inspection. NA(P)T implementations that attempt 315 to parse ISAKMP payloads may not handle all payload ordering 316 combinations, or support vendor_id payloads for IKE option 317 negotiation. 319 3. Requirements for IPsec-NAT compatibility 321 The goal of an IPsec-NAT compatibility solution is to expand the range 322 of usable IPsec functionality beyond that available in an NAT-compatible 323 IPsec tunnel mode solution described above. 325 In evaluating a solution to IPsec-NAT incompatibility, the following 326 criteria should be kept in mind: 328 Deployment 329 Since IPv6 will address the address scarcity issues that 330 frequently lead to use of NA(P)Ts with IPv4, the IPsec-NAT 331 compatibility issue is a transitional problem that needs to be 332 solved in the time frame prior to widespread deployment of 333 IPv6. Therefore, to be useful an IPsec-NAT compatibility 334 solution MUST be deployable on a shorter time scale than IPv6. 336 Since IPv6 deployment requires changes to routers as well as 337 hosts, a IPsec-NAT compatibility solution which requires 338 changes to both routers and hosts will be deployable on 339 approximately the same time scale as IPv6. Thus, an IPsec-NAT 340 compatibility solution SHOULD require changes only to hosts, 341 and not to routers. 343 Among other things, this implies that communication between 344 the host and the NA(P)T SHOULD NOT be required by an IPsec-NAT 345 compatibility solution, since that would require changes to 346 the NA(P)Ts, and interoperability testing between the host and 347 NA(P)T implementations. In order to enable deployment in the 348 short term, it is necessary for the solution to work with 349 existing router and NA(P)T products within the deployed 350 infrastructure. 352 Telecommuter scenario 353 Since one of the primary uses of IPsec is remote access to 354 corporate Intranets, a NA(P)T traversal solution MUST support 355 NA(P)T traversal via either IPsec tunnel mode or L2TP over 356 IPsec transport mode [RFC 3193]. This includes support for 357 traversal of more than one NA(P)T between the remote client 358 and the VPN gateway. 360 The client may have a routeable address and the VPN gateway 361 may be behind at least one NA(P)T, or alternatively, both the 362 client and the VPN gateway may be behind one or more NA(P)Ts. 363 Telecommuters may use the same private IP address, each behind 364 their own NA(P)T, or many telecommuters may reside on a 365 private network behind the same NA(P)T, each with their own 366 unique private address, connecting to the same VPN gateway. 367 Since IKE uses UDP port 500 as the destination, it is not 368 necessary to enable multiple VPN gateways operating behind 369 the same external IP address. 371 In a gateway-gateway scenario, a privately addressed network 372 (DMZ) may be inserted between the corporate network and the 373 Internet. In this design, IPsec security gateways connecting 374 portions of the corporate network will have private addresses 375 on their external interfaces. A NA(P)T connects the DMZ 376 network to the Internet. 378 A NAT-IPsec solution MUST enable secure host-host 379 communication via IPsec as well as host-gateway 380 communications. A host on a private network MUST be able to 381 bring up IPsec-protected TCP connections or UDP sessions to 382 another host with one or more NA(P)Ts between them. For 383 example, NA(P)Ts may be deployed within branch offices 384 connecting to the corporate network, with an additional NA(P)T 385 connecting the corporate network to the Internet. 387 Firewall Compatibility 388 Since firewalls are widely deployed, a NAT-IPsec compatibility 389 solution MUST enable a firewall administrator to create 390 simple, static access rule(s) to permit or deny IKE and IPsec 391 NA(P)T traversal traffic. This implies, for example, that 392 dynamic allocation of IKE or IPsec destination ports is to be 393 avoided. 395 Scaling An IPsec-NAT compatibility solution should be capable of being 396 deployed within an installation consisting of thousands of 397 telecommuters. In this situation, it is not possible to 398 assume that only a single host is communicating with a given 399 destination at a time. Thus, an IPsec-NAT compatibility 400 solution MUST address the issue of overlapping SPD entries and 401 de-multiplexing of incoming packets. 403 Mode support 404 At a minimum, an IPsec-NAT compatibility solution MUST support 405 traversal of the IPsec modes required for support within 406 [RFC2401]. For example, an IPsec gateway MUST support ESP 407 tunnel mode NA(P)T traversal, and an IPsec host MUST support 408 IPsec transport mode NA(P)T traversal. The purpose of AH is 409 to protect immutable fields within the IP header (including 410 addresses), and NA(P)T translates addresses, invalidating the 411 AH integrity check. As a result, NA(P)T and AH are 412 fundamentally incompatible and there is no requirement that an 413 IPsec-NAT compatibility solution support AH transport or 414 tunnel mode. 416 Backward Compatibility and Interoperability 417 An IPsec-NAT compatibility solution MUST be interoperable with 418 existing IKE/IPsec implementations, so that they can 419 communicate where no NA(P)T is present. This implies that an 420 IPsec-NAT compatibility solution MUST be backwards-compatible 421 with IPsec as defined in [RFC2401] and IKE as defined in 422 [RFC2409]. In addition, it SHOULD be able to detect the 423 presence of a NA(P)T, so that NA(P)T traversal support is only 424 used when necessary. This implies that it MUST be possible to 425 determine that an existing IKE implementation does not support 426 NA(P)T traversal, so that a standard IKE conversation can 427 occur, as described in [RFC2407], [RFC2408], and [RFC2409]. 428 Note that while this implies initiation of IKE to port 500, 429 there is no requirement for a specific source port, so that 430 UDP source port 500 may or may not be used. 432 Security An IPsec-NAT compatibility solution MUST NOT introduce 433 additional IKE or IPsec security vulnerabilities. For 434 example, an acceptable solution must demonstrate that it 435 introduces no new denial of service or spoofing 436 vulnerabilities. IKE MUST be allowed to rekey in a bi- 437 directional manner as described in [RFC2408]. 439 4. Existing solutions 441 4.1. IPsec tunnel mode 443 In a limited set of circumstances, it is possible for an IPsec tunnel 444 mode implementation, such as that described in [DHCP], to traverse 445 NA(P)T successfully. However the requirements for successful traversal 446 are sufficiently limiting that a more general solution is needed: 448 [1] IPsec ESP. IPsec ESP tunnels do not cover the outer IP header 449 within the authentication hash, and so will not suffer hash 450 invalidation due to address translation. IPsec tunnels also need 451 not be concerned about checksum invalidation. 453 [2] No address validation. Most current IPSEC tunnel mode 454 implementations do not perform source address validation so that 455 incompatibilities between IKE identifiers and source addresses will 456 not be detected. This introduces security vulnerabilities as 457 described in the security considerations section. 459 [3] "Any to Any" SPD entries. IPsec tunnel mode clients can negotiate 460 "any to any" SPDs, which are not invalidated by address 461 translation. This effectively precludes use of SPDs for filtering 462 of allowed tunnel traffic. 464 [4] Single client operation. With only a single client behind a NAT, 465 there is no risk of overlapping SPDs. Since the NAT will not need 466 to arbitrate between competing clients, there is also no risk of 467 re-key mis-translation, or improper incoming SPI or cookie de- 468 multiplexing. 470 [5] No fragmentation. When certificate authentication is used, IKE 471 fragmentation can be encountered. This can occur when certificate 472 chains are used, or even when exchanging a single certificate if 473 the key size, or size of other certificate fields (such as the 474 distinguished name and other OIDs) is large enough. However, when 475 pre-shared keys are used for authentication, fragmentation is less 476 likely. 478 [6] Active sessions. Most VPN sessions typically maintain ongoing 479 traffic flow during their lifetime, so that UDP port mappings are 480 less likely be removed due to inactivity. 482 4.2. RSIP 484 RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for IPsec 485 traversal, as described in [RSIPsec]. By enabling host-gateway 486 communication, RSIP addresses issues of IPsec SPI de-multiplexing as 487 well as SPD overlap. It is thus suitable for use in enterprise as well 488 as home networking scenarios. By enabling hosts behind a NAT to share 489 the external IP address of the gateway, this approach is compatible with 490 protocols including embedded IP addresses. 492 By tunneling IKE and IPsec packets, RSIP avoids changes to the IKE and 493 IPsec protocols, although major changes are required to host IKE and 494 IPsec implementations to retrofit them for RSIP-compatibility. It is 495 thus compatible with all existing protocols (AH/ESP) and modes 496 (transport and tunnel). 498 In order to handle de-multiplexing of IKE re-keys, RSIP requires 499 floating of the IKE source port, as well as re-keying to the floated 500 port. As a result, inter-operability with existing IPsec implementations 501 is not assured. 503 RSIP does not satisfy the deployment requirements for a IPsec-NAT 504 compatibility solution because an RSIP-enabled host requires a 505 corresponding RSIP-enabled gateway in order to establish an IPsec SA 506 with another host. Since RSIP requires changes only to clients and 507 routers and not to servers, it is less difficult to deploy than IPv6. 508 However, for vendors, implementation of RSIP requires a substantial 509 fraction of the resources required for IPv6 support. Thus, RSIP solves a 510 "transitional" problem on a long-term time scale, which is not useful. 512 4.3. 6to4 514 6to4, as described in [RFC3056] can form the basis for an IPsec-NAT 515 traversal solution. In this approach, the NAT provides IPv6 hosts with 516 an IPv6 prefix derived from the NAT external IPv4 address, and 517 encapsulates IPv6 packets in IPv4 for transmission to other 6to4 hosts 518 or 6to4 relays. This enables an IPv6 host using IPsec to communicate 519 freely to other hosts within the IPv6 or 6to4 clouds. 521 While 6to4 is an elegant and robust solution where a single NA(P)T 522 separates a client and VPN gateway, it is not universally applicable. 523 Since 6to4 requires assignment of a routable IPv4 address to the NA(P)T, 524 in order to allow formation of an IPv6 prefix, it is not usable where 525 multiple NA(P)Ts exist between the client and VPN gateway. For example, 526 a NA(P)T with a private address on its external interface, cannot be 527 used by clients behind it to obtain an IPv6 prefix via 6to4. 529 While 6to4 requires little additional support from hosts that already 530 support IPv6, it does require changes to NATs, which need to be upgraded 531 to support 6to4. As a result, 6to4 may not be suitable for deployment 532 in the short term. 534 5. Security considerations 536 By definition, IPsec-NAT compatibility requires that hosts and routers 537 implementing IPsec be capable of securely processing packets whose IP 538 headers are not cryptographically protected. A number of issues arise 539 from this that are worth discussing. 541 Since IPsec AH cannot pass through a NAT, one of the side effects of 542 providing an IPsec-NAT compatibility solution may be for IPsec ESP with 543 null encryption to be used in place of AH where a NAT exists between the 544 source and destination. However, it should be noted that ESP with null 545 encryption does not provide the same security properties as AH. For 546 example, there are security risks relating to IP source routing that are 547 precluded by AH, but not by ESP with null encryption. 549 In addition, since ESP with any transform does not protect against 550 source address spoofing, some sort of source IP address sanity checking 551 needs to be performed. The importance of the anti-spoofing check is not 552 widely understood. There is normally an anti-spoofing check on the 553 Source IP Address as part of IPsec_{esp,ah}_input(). This ensures that 554 the packet originates from the same address as that was claimed within 555 the original IKE MM and QM security associations. When a receiving host 556 is behind a NAT, this check might not strictly be meaningful for unicast 557 sessions, whereas in the Global Internet this check is important for 558 tunnel-mode unicast sessions to prevent a spoofing attack described in 559 [AuthSource]. 561 Let us consider two hosts, A and C, both behind (different) NATs, who 562 negotiate IPsec tunnel mode SAs to router B. Hosts A and C may have 563 different privileges; for example, host A might belong to an employee 564 trusted to access much of the corporate Intranet, while C might be a 565 contractor only authorized to access a specific web site. 567 If host C sends a tunnel mode packet spoofing A's IP address, as the 568 source, it is important that this packet not be accorded the privileges 569 corresponding to A. If authentication and integrity checking is 570 performed, but no anti-spoofing check (verifying that the originating IP 571 address corresponds to the SPI) then host C may be allowed to reach 572 parts of the network that are off limits. As a result, an IPsec-NAT 573 compatibility scheme MUST provide some degree of anti-spoofing 574 protection. 576 6. Normative references 578 [RFC791] ISI, "Internet Protocol Specification", RFC 791, September 579 1981. 581 [RFC793] Information Sciences Institute, "Transmission Control 582 Protocol", RFC 793, September 1981. 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 588 Internet Protocol", RFC 2401, November 1998. 590 [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 591 November 1998. 593 [RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload 594 (ESP)", RFC 2406, November 1998. 596 [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation 597 of ISAKMP", RFC 2407, November 1998. 599 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 600 RFC 2409, November 1998. 602 [RFC2663] Srisuresh, P. and Holdredge, M., "IP Network Address 603 Translator (NAT) Terminology and Considerations," RFC 2663, 604 August 1999. 606 [RFC3022] Srisuresh, P., and Egevang, K., "Traditional IP Network 607 Address Translator (Traditional NAT)", RFC 3022, January 2001. 609 [AuthSource] 610 Kent, S., "Authenticated Source Addresses", IPsec WG Archive ( 611 ftp://ftp.ans.net/pub/archive/IPsec ), Message-Id: 612 , January 5, 1996. 614 7. Informative references 616 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 617 and Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, 618 August 1999. 620 [RFC3056] Carpenter, B., Moore, K., "Connection of IPv6 Domains via IPv4 621 Clouds", RFC 3056, February 2001. 623 [RSIPFrame] 624 Borella, M., Lo, J., Grabelsky, D., Montenegro, G., "Realm 625 Specific IP: A Framework", RFC 3102, October 2001. 627 [RSIP] Borella, M., Grabelsky, D., Lo, J., Taniguchi, K., "Realm 628 Specific IP: Protocol Specification", RFC 3103, October 2001. 630 [RSIPsec] Montenegro, G., Borella, M., "RSIP Support for End-to-End 631 IPsec", RFC 3104, October 2001. 633 [DHCP] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 634 Configuration of IPsec Tunnel Mode", Internet draft (work in 635 progress), draft-ietf-ipsec-dhcp-13.txt, June 2001. 637 Acknowledgments 639 Thanks to Steve Bellovin of AT&T Research, William Dixon of Microsoft, 640 Ran Atkinson of Extreme Networks and Daniel Senie for useful discussions 641 of this problem space. 643 Authors' Addresses 645 Bernard Aboba 646 William Dixon 647 Microsoft Corporation 648 One Microsoft Way 649 Redmond, WA 98052 651 Phone: +1 425 882 8080 652 EMail: {bernarda, wdixon}@microsoft.com 654 Full Copyright Statement 656 Copyright (C) The Internet Society (2002). All Rights Reserved. 658 This document and translations of it may be copied and furnished to 659 others, and derivative works that comment on or otherwise explain it or 660 assist in its implementation may be prepared, copied, published and 661 distributed, in whole or in part, without restriction of any kind, 662 provided that the above copyright notice and this paragraph are included 663 on all such copies and derivative works. However, this document itself 664 may not be modified in any way, such as by removing the copyright notice 665 or references to the Internet Society or other Internet organizations, 666 except as needed for the purpose of developing Internet standards in 667 which case the procedures for copyrights defined in the Internet 668 Standards process must be followed, or as required to translate it into 669 languages other than English. The limited permissions granted above are 670 perpetual and will not be revoked by the Internet Society or its 671 successors or assigns. This document and the information contained 672 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 673 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 674 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 675 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 676 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 677 Intellectual Property Statement 679 The IETF takes no position regarding the validity or scope of any 680 intellectual property or other rights that might be claimed to pertain 681 to the implementation or use of the technology described in this 682 document or the extent to which any license under such rights might or 683 might not be available; neither does it represent that it has made any 684 effort to identify any such rights. Information on the IETF's 685 procedures with respect to rights in standards-track and standards- 686 related documentation can be found in BCP-11. Copies of claims of 687 rights made available for publication and any assurances of licenses to 688 be made available, or the result of an attempt made to obtain a general 689 license or permission for the use of such proprietary rights by 690 implementors or users of this specification can be obtained from the 691 IETF Secretariat. 693 The IETF invites any interested party to bring to its attention any 694 copyrights, patents or patent applications, or other proprietary rights 695 which may cover technology that may be required to practice this 696 standard. Please address the information to the IETF Executive 697 Director. 699 Expiration Date 701 This memo is filed as , and expires 702 February 22, 2003.