idnits 2.17.1 draft-stenberg-ipsec-nat-traversal-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (February 28, 2001) is 8458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2401 (ref. '1') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '3') ** Obsolete normative reference: RFC 2409 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. '6') (Obsoleted by RFC 4306) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Stenberg 2 Internet-Draft S. Paavolainen 3 Expires: August 29, 2001 T. Ylonen 4 T. Kivinen 5 SSH Communications Security Corp 6 February 28, 2001 8 IPsec NAT-Traversal 9 draft-stenberg-ipsec-nat-traversal-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2001. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 This draft details the changes needed in order to make both initial 41 IKE negotiation and subsequent authenticated/encrypted 42 communications across IPsec AH/ESP SAs work despite the changes in 43 the headers, and possible protocol transformations. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.2 IPsec cases . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.2.1 Host-to-host . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.2.2 Host-to-network . . . . . . . . . . . . . . . . . . . . . . 5 54 2.2.3 Network-to-network . . . . . . . . . . . . . . . . . . . . . 5 55 2.3 Issues stemming from NAT technology . . . . . . . . . . . . 5 56 2.4 Summary of issues . . . . . . . . . . . . . . . . . . . . . 5 57 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.1 IKE probe . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1.1 Determining of support . . . . . . . . . . . . . . . . . . . 7 60 3.1.2 NAT-Traversal need-probe . . . . . . . . . . . . . . . . . . 8 61 3.2 IPsec SA traffic encapsulation . . . . . . . . . . . . . . . 8 62 3.3 Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.4 Built-in NAT . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4. Known issues with the solution . . . . . . . . . . . . . . . 12 65 4.1 Conceptual issues . . . . . . . . . . . . . . . . . . . . . 12 66 4.2 Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.3 Security considerations . . . . . . . . . . . . . . . . . . 13 68 4.4 Intellectual property rights . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 70 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 A. Changes since previous version . . . . . . . . . . . . . . . 16 72 B. Implementation notes of de-/encapsulation . . . . . . . . . 17 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 75 1. Introduction 77 NAT devices have proliferated recently. Increased number of 78 IPv6-enabled devices will not automatically mean disappearance of 79 NAT devices, as IPv4 will be probably in use for decade(s). There 80 will be need for bridging between IPv4 and IPv6 networks, and as 81 long as there are NATs around, basic IPsec as defined by RFC 2401 82 [1] will not work. It is quite important that there is a defined 83 standard for handling IPsec traffic in networks with NAT devices. 84 Preferably, a standard will evolve to fit all possible cases that 85 may arise. 87 In Section 2, most of the different IPsec+NAT permutations are 88 analyzed and a list of issues is presented. Section 3 details the 89 proposed solution to these issues. Finally, potential problems in 90 the solution are noted in Section 4. 92 1.1 Definitions 94 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 95 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 96 document, are to be interpreted as described in RFC 2119 [2]. 98 NAT terminology used is described in RFC 2663 [3], with the 99 following exception: 101 o Protocol NAT: Protocol NAT is a NAT process/device that changes 102 the protocol of the packet; this usually involves a whole new 103 header for the packet. 105 2. Analysis 107 2.1 Assumptions 109 It can be safely assumed that IKE, as defined in RFC 2409 [4], 110 works. IKE negotiations are handled with normal UDP traffic. 111 Therefore, it should work despite network address changes along the 112 route. IP packet payloads are assumed to be left unmodified; changes 113 to the UDP headers can occur, as long as nothing drops the packets 114 before they reach the host. 116 As normal IPsec traffic does not pass across NAPTs (nor protocol 117 NATs), a complete NAT-Traversal design should encapsulate IPsec SAs 118 in UDP packets, which behave like IP packets, but as they are used 119 in applications, they can pass through all types of NATs. 121 2.2 IPsec cases 123 Initially, most of the different IPsec+NAT combinations are listed 124 here to make sure that all implications of NAT use are addressed. 125 IPsec cases can be divided into three different categories (with 126 possible NATs in various places along the route between hosts 127 employing IPsec). 129 o Host-to-host (tunnel or transport mode) 131 o Host-to-network (tunnel mode) 133 o Network-to-network (tunnel mode) 135 In all cases, the IKE responder must be only behind a series of 136 basic NATs with static address assignment. Dynamic address 137 assignment does not work for obvious reasons (the IKE initiator 138 cannot contact such an address). NAPTs do not work because most IKE 139 implementations seem to be hardcoded to use port 500. 141 The IKE initiator can be behind any kind of NAT, although in cases 142 where initiation of traffic from both directions should be allowed 143 (primarily VPN-like cases), the same restrictions that apply to the 144 responder apply also to the initiator. 146 Issue #1: Both hosts need to know that there is a NAT in the middle, 147 but currently IKE/IPsec do not provide such method. Only indication 148 of NAT presence is the fact that all IPsec SA packets, if they 149 arrive, will be dropped as invalid if AH is in use. 151 Issue #2: It is obvious that programs residing on an IKE responder 152 that is behind a basic NAT cannot know about the existence of the 153 NAT or about the specific address mappings configured there. 155 Therefore the IKE responder implementation should have advance 156 knowledge about the address mappings. 158 2.2.1 Host-to-host 160 Host-to-host traffic using tunnel or transport mode is the most 161 basic case; it only becomes interesting if there is no shared 162 address space between the parties (a VPN of sorts) and there are 163 NATs in between. 165 Issue #3: If NATs are employed along the route, there may be 166 addressing conflicts in tunnel mode (and there WILL be conflicts in 167 transport mode). From the IKE responder point of view, the IKE 168 initiators' addresses may conflict if they are in private networks 169 (such as the IANA-assigned 10.0.0.0 subnet). 171 2.2.2 Host-to-network 173 Only tunnel mode is applicable for host-to-network communication, 174 and the only apparent problem is the potential lack of shared 175 address space (a host without an address in the remote network that 176 it is accessing). Therefore, there is potential for issue #3-type of 177 problems. 179 2.2.3 Network-to-network 181 Only tunnel mode is applicable in network-to-network communication, 182 and issue #3 is potentially also a problem. That is mostly outside 183 scope of this draft, as at the moment such a case is rarely 184 encountered. 186 2.3 Issues stemming from NAT technology 188 Issue #4: The NATs with dynamic address assignment may change their 189 address mapping suddenly (or they may be rebooted), making the 190 remote host concept unworkable even as a unique ip-port pair. 192 2.4 Summary of issues 194 There are basically four problems that need addressing: 196 1. detection of network address translation during IKE negotiation 197 (issue #1), 199 2. a way of sending packets along the network so that NAT effects 200 can be countered, yet the security of the system will not be 201 affected (UDP encapsulation; assumption), 203 3. keeping NAT mapping static - NAT devices with dynamic address 204 assignment configurations typically contain timeouts that will 205 cause changes in addressing, if not circumvented by using 206 keepalive packets to maintain the specific mappings (issue #4), 207 and 209 4. the lack of unique IP addresses in the NAT world; it is possible 210 for a server to have several clients with the same configured IP 211 address, although they appear to the server to be from different 212 hosts/ports (issue #3). 214 Issue #2 (basic NAT case, where the IKE responder does not know what 215 address to use) is easily solved, as seen in the end of Section 3.2. 217 3. Solution 219 The solution that resolves all the issues mentioned in Section 2.4 220 can be divided into four different parts, explained in this section: 222 o IKE probe to detect NAT presence 224 o IPsec SA traffic encapsulation to counter NAT effects 226 o NAT translation keepalive messages, which maintain NAT mappings 228 o built-in NAT (if needed) to make addresses unique 230 Incoming packet Outgoing packet 231 / | | \ 232 / | | \ 233 NAT-T decap. | | Un-NAT dst 234 | | | | 235 IPsec IPsec IPsec IPsec 236 | | 237 NAT src NAT-T encap. 239 Figure 1: IPsec processing with and without a NAT-Traversal process. 241 3.1 IKE probe 243 There is a need for two different exchanges during the IKE 244 negotiation. Initially, it needs to be determined whether or not 245 both sides support NAT-Traversal. Then, if both sides do support it, 246 there should be a probe sequence that results in knowledge about 247 whether or not the network between hosts contains a NAT device. 249 Although this involves four messages, it is possible to make this 250 work in all modes, as seen shortly. 252 3.1.1 Determining of support 254 The NAT-Traversal capability of the remote host is determined by an 255 exchange of vendor strings; in Phase 1 two first messages, the 256 vendor id payload for this specification of NAT-Traversal (MD5 hash 257 of "draft-stenberg-ipsec-nat-traversal-02" - ['0x61', '0x5', '0xc4', 258 '0x22', '0xe7', '0x68', '0x47', '0xe4', '0x3f', '0x96', '0x84', 259 '0x80', '0x12', '0x92', '0xae', '0xcd']) MUST be sent if supported 260 (and it MUST be received by remote side) for the NAT-Traversal probe 261 to continue. 263 3.1.2 NAT-Traversal need-probe 265 Once the NAT-Traversal support of both parties has been established 266 in the initial stages of Phase 1, further inquiries need to be made 267 using private payloads. 269 Initially, in the 5th message of Main Mode / 3rd message of 270 Aggressive Mode, the initiator will add one private payload to the 271 message. PAYLOAD_TYPE (from private range) is 211. 273 The payload should contain the following: 275 {perceived remote identity - 276 IP address and UDP port} 278 {one or more local identities - 279 local interface IP address+IKE UDP port numbers} 281 Figure 2: Probe payload in Main Mode message #5 283 The probe payload is encoded as a series of Identification Payloads 284 of RFC 2407 [6], with the perceived remote identity as the first 285 payload, and the local identities as the following payloads. 287 Once the IKE responder receives the payload represented in Figure 2, 288 the remote should check whether or not the remote identity, as 289 perceived by the IKE initiator, matches one of the locally 290 configured interface addresses (with proper port number). Also, the 291 remote identity as perceived by the IKE responder should match one 292 of the ip-port pairs sent in the packet. 294 If one (or two) of those tests fails, the responder knows that 295 NAT-Traversal is needed. The decision on whether to use 296 NAT-Traversal or not is left up to the responder, and the responder 297 transmits the decision as a private payload of type 211 in the last 298 message of Main Mode, or in the first or second message of Quick 299 Mode (depending on who initiates, the first message from the 300 responder may be either first or second). 302 The payload is one or more bytes long. Implementations conforming to 303 this draft version should just examine the first byte. The byte 304 should be 0x00 when NAT-Traversal should not be used. All other 305 values indicate that NAT-Traversal should be used. 307 3.2 IPsec SA traffic encapsulation 309 Automatic use of NAT-Traversal encapsulation for IKE-negotiated 310 IPsec SAs MUST NOT be done. Instead, NAT-Traversal SHOULD be used 311 only when IKE negotiation has resulted in a decision to use 312 NAT-Traversal, or when manually keyed IPsec SAs are configured to 313 use it. 315 Traffic that is not in AH or ESP format MUST NOT be encapsulated 316 using this scheme, as that would provide a way to create distributed 317 denial of service attacks, and possibly also some other security 318 threats. 320 Normal AH/ESP traffic does not pass through NATs unmodified. 321 Typically, the source or destination address may change, which makes 322 the resulting AH/ESP packet unusable. Thus, there has to be enough 323 redundant data to be able to recreate a packet to its original form. 324 To make the implementation simpler, it should follow the same NAT 325 route as IKE packets. 327 Therefore (as noted before), the traffic has to be encapsulated as 328 UDP packets between two hosts (which implies that they follow same 329 route even in NAPTs) using the IKE port. The basic idea behind this 330 NAT-Traversal data encapsulation format is that it should be a 331 format that can be adapted to future needs. The only requirement for 332 this initial version is that it contains a version number, and it is 333 invalid for IKE purposes. 335 An IPsec NAT-Traversal envelope for IPv4 packet encapsulation looks 336 like this: 338 342 346 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 347 +---------------+---------------+---------------+---------------+ 348 | IKE initiator cookie - 4 first bytes (00000000) | 349 +---------------+---------------+---------------+---------------+ 350 | IKE initiator cookie - 4 last bytes (00000000) | 351 +---------------+---------------+---------------+---------------+ 352 | NAT-T|IP4 hlen| reserved - 0 | IP4 ID | 353 +---------------+---------------+---------------+---------------+ 355 357 Figure 3: A NAT-Traversal envelope for an IPv4 IPsec packet. 359 IKE initiator cookie that contains only zeros is used only 360 between consenting NAT-Traversal implementations that conform to 361 this draft (normal IKE conversations should never involve IKE 362 initiator cookie that consists of only zeros, as shown in section 363 2.4 of RFC 2408 [5]). 365 NAT-T field is lower 4 bits of the first payload byte. It 366 contains the IP address type and the IP protocol used, as 367 follows: IPv4-AH: 1, IPV4-ESP: 2. 369 IP4 hlen is the original header length field, which includes the 370 IP4 header options. 372 IP4 ID is the original IP4 packet Identification. 374 Description of how the IPsec encapsulation and decapsulation should 375 be implemented is in the Appendix B. 377 3.3 Keepalive 379 Disclaimer: the IKE SA heartbeat should probably be used whenever 380 one becomes a standard. Until then, NAT-Traversal will have its own 381 keepalive packets that are entirely separate from the IKE SA. 383 The sole purpose of the keepalives is to keep the NATs along the 384 route between hosts from removing the mapping from their dynamic 385 configuration (if any). Therefore, the actual contents of the 386 keepalive packets can be more or less ignored (unless they stop 387 arriving), and thus encrypting them would serve no useful purpose. 389 Keepalive packets MUST be sent as long as there is at least one 390 IKE-probed IPsec SA in existence between two hosts that employ 391 NAT-Traversal to communicate with each other. Both sides MUST send a 392 keepalive packet every KEEPALIVE_INTERVAL (=9) seconds. The 9 was 393 picked as reasonable compromise with assumption that nobody would be 394 insane enough to set less than 30 second timeout for NAT mappings 395 (30 seconds exists out there). 9 second keepalive requires 3 396 sequential keepalive messages to be lost in order for the NAT to 397 lose it's mapping. 399 If no keepalive packets from remote side are received for a while, 400 implementation SHOULD consider the connection dead and drop the 401 IPsec SAs prematurely. Specific period can vary by implementation. 402 Typically some multiple of KEEPALIVE_INTERVAL + some value is 403 reasonable, f.ex. 5*KEEPALIVE_INTERVAL+3 (in order to make the SAs 404 time out if 5 sequential keepalives are lost). 406 3.4 Built-in NAT 408 Built-in basic NAT implementation within the IPsec stack is 409 necessary in some tunnel cases and all transport cases. To stay 410 consistent with RFC 2409 [4], which specifies that both tunnel and 411 transport mode MUST be supported, we define that there MUST be a 412 built-in basic NAT implementation for NAT-Traversal use. 414 The built-in NAT is needed in some cases where issue #3 surfaces 415 (see Section 2.2 for details) to make the remote host(s) unique. 416 Typically, the host mapping should be from perceived 417 remote_host-remote_port to some internal A- or B-class network. 418 Whenever the remote side successfully initiates IPsec SA employing 419 NAT-Traversal, there should be an internal NAT definition for the 420 (remote_host, remote_port) if one is required according to the local 421 configuration (or if transport mode is used, in which case internal 422 basic NAT SHOULD always be employed). Whenever IPsec processing for 423 an incoming packet is done, the internal basic NAT should be done to 424 the src. Whenever an outgoing packet headed towards an internal NAT 425 address enters the IPsec, the internal NAT address should be changed 426 to the address that was used for negotiating the IPsec SA. 428 In tunnel mode, it is possible that entire networks may need 429 masking. In the NAT-Traversal+IPsec case, a separate NAT box would 430 not know about the perceived remote_host-remote_port pair which 431 provides uniqueness to the tunneled IP addresses. Therefore, there 432 is a need for NAT within the IPsec implementation. This MAY be 433 supported, but specific implementation details are not provided in 434 this draft. 436 4. Known issues with the solution 438 4.1 Conceptual issues 440 The non-unique hosts may cause problems, as there is a potential 441 problem of ip-port-proto-spi not being unique any more. The problem 442 does not surface in the incoming traffic, but it may occur in the 443 outgoing traffic case. There are (at least) a couple of different 444 solutions to the problem: 446 o Tying the remote-host,remote-port of NAT-T IPsec SA decapsulation 447 and the ip-port-proto-spi. 449 o Refusal of duplicate IPsec SA SPIs during IKE P2QM negotiation. 451 o SAD may be extended to use (remote-perceived-ike-peer, ip, proto, 452 spi) as unique key instead of (ip, proto, spi). 454 4.2 Overhead 456 This solution is about the most minimal possible that covers the 457 eventual possibilities (reasonable combinations of AH, ESP and 458 IPCOMP) without becoming overly complex. Different types of overhead 459 caused by this draft are noted here, as well as possible ways of 460 decreasing/removing the overheads involved. Processing time and 461 memory overhead are ignored as negligible (some more processing for 462 each packet, potentially logarithmic searches for free addresses, 463 minimal extra data for each IPsec SA). 465 o IKE P1 negotiation extra payloads: Moderately small, typically 466 less than 200 bytes. It appears that this cannot be reduced. 468 o Each IPv4-based IPsec SA packet will contain extra overhead of 20 469 bytes (8 bytes of UDP header, 12 bytes of NAT-T header). The 470 impact of the additions is not typically great; for example, 471 ethernet's minimum packet length will cover this for minimal 472 length packets, and for slow networks there may be protocols such 473 as PPP that provides header- or even whole payload compression 474 (in that case, the exactly same UDP, NAT-T- and start of 475 ESP/AH-header should cause negligible overhead). 477 o Keepalive overhead of 56 bytes every KEEPALIVE_INTERVAL (20 bytes 478 of IP header + 8 bytes of UDP header = 28 bytes times 2 for 479 bidirectional traffic). 6 bytes/second may seem excessive, but as 480 long as a general-purpose solution is desired, it cannot be 481 bypassed. Two consenting parties that know there is only static 482 NATs in-between MAY, of course, skip heartbeats altogether. 484 4.3 Security considerations 486 Whenever changes to some fundamental parts of a security protocol 487 are proposed, the examination of security implications cannot be 488 skipped. Therefore, here are some observations on the effects, and 489 whether or not these effects matter. This section will be expanded 490 further in future versions of this draft. 492 o IKE probe reveals NAT-Traversal support to everyone. This should 493 not be an issue. 495 o The value of authentication mechanisms based on IP addresses 496 disappears once NATs are in the picture. That is not necessarily 497 a bad thing (for any real security, other authentication measures 498 than IP addresses should be used). 500 o Some DoS implications exist; a single malicious user can possibly 501 allocate up to (number-of-hosts-available) * 65535 502 (=number-of-ports-on-host) internal host IP addresses at the same 503 time - and cause that many negotiations (this is 65535 times as 504 much DoS potential as traditional IKE). As the IP addresses are 505 allocated only after authentication is successful, the attacker 506 is known. Therefore this can be considered only a slight risk, as 507 it can be ameliorated by adding allocations-per-remote-end-entity 508 limits. 510 o Although two last packets in the Main Mode are encrypted, the IKE 511 responder (if improper) gets some internal IP address information 512 that IKE initiator might not want to reveal. 514 4.4 Intellectual property rights 516 SSH Communications Security Corp hereby announces that one or more 517 patents or patent applications may be relevant to this 518 internet-draft. If this internet-draft becomes an IETF standard, SSH 519 Communications Security Corp intends to support a widespread 520 adoption of the standard by offering - on the basis of reciprocity 521 whenever applicable - to license any IPR owned by SSH Communications 522 Security Corp necessary for implementing the standard on fair, 523 reasonable and nondiscriminatory terms. 525 References 527 [1] Kent, S. and R. Atkinson, "Security Architecture for the 528 Internet Protocol", RFC 2401, November 1998. 530 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 531 Levels", RFC 2119, March 1997. 533 [3] Srisuresh, S. and M. Holdrege, "IP Network Address Translator 534 (NAT) Terminology and Considerations", RFC 2663, August 1999. 536 [4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 537 RFC 2409, November 1998. 539 [5] Maughan, D., Schertler, M., Schneider, M. and J. Turner, 540 "Internet Security Association and Key Management Protocol 541 (ISAKMP)", RFC 2408, November 1998. 543 [6] Piper, D., "The Internet IP Security Domain of Interpretation 544 for ISAKMP", RFC 2407, November 1998. 546 Authors' Addresses 548 Markus Stenberg 549 SSH Communications Security Corp 550 Fredrikinkatu 42 551 FIN-00100 Helsinki 552 Finland 554 EMail: mstenber@ssh.com 556 Santeri Paavolainen 557 SSH Communications Security Corp 558 Fredrikinkatu 42 559 FIN-00100 Helsinki 560 Finland 562 EMail: santtu@ssh.com 564 Tatu Ylonen 565 SSH Communications Security Corp 566 Fredrikinkatu 42 567 FIN-00100 Helsinki 568 Finland 570 EMail: ylo@ssh.com 571 Tero Kivinen 572 SSH Communications Security Corp 573 Fredrikinkatu 42 574 FIN-00100 Helsinki 575 Finland 577 EMail: kivinen@ssh.com 579 Appendix A. Changes since previous version 581 In addition some small fixes to the document (minor changes in 582 wording), there are some significant changes in this revision as 583 compared to the previous one. 585 Aggressive mode support was added by making it possible to have 586 final NAT-T decision private payload sent in QM packet. 588 IPcomp as outer header was removed (due to conflict with goals 589 specified in Section 3.2). 591 ToS field was removed as it isn't required by AH and not really 592 useful to encapsulate regardless. 594 Appendix B. Implementation notes of de-/encapsulation 596 Note that the IP checksum needs to be updated constantly, or 597 alternatively verified in the beginning and recalculated in the end 598 of both decapsulation and encapsulation. 600 Encapsulation should happen after IPsec processing and work as 601 follows (with data changing as shown in Figure 4): 603 1. Insert UDP and NAT-T headers to the end of minimal IP4 header 604 (offset of 20 bytes from beginning of the packet). UDP data: 605 srcport=local-ike-port, dstport=perceived-remote-port. 607 2. Remove the excess IP4 header bytes from the checksum (NAT-T uses 608 only minimal IP4 header - 20 bytes). 610 3. Store IP4 original header length in the NAT-T header. Set NAT-T 611 field according to protocol of the IP packet. Identification 612 should be copied as-is. 614 4. Set the IP4 header length to 20 bytes. 616 5. Set the IP4 protocol to be UDP. 618 IP [N bytes] 619 AH/ESP 620 ... 622 to 624 minimal-IP [20 bytes] 625 UDP [8 bytes] 626 NAT-T [4 bytes] 627 IP-header-options [N-20 bytes] 628 AH/ESP 630 Figure 4: NAT-Traversal encapsulation process. 632 Decapsulation should happen before IPsec processing and work as 633 follows (and work like reverse of Figure 4): 635 1. Check that protocol is UDP and dstport == IKE port. 637 2. If the packet is keepalive (empty UDP payload), update 638 reachability data, if any, and drop the packet. 640 3. Check that initiator cookie is zeros - pass if not (normal IKE 641 content). 643 4. Note the remote ip-port pair and look up respective IKE/IPsec 644 data - drop if unsuccessful. 646 5. Copy header length and identification from NAT-T header to the 647 IP packet. 649 6. Set IP protocol according to NAT-T type. 651 7. Change the source and destination address to be the IPsec 652 endpoints involved (using either SPI or alternatively tying the 653 perceived remote_ip-remote_host to single src-dst pair). 655 8. Eliminate the UDP and NAT-T headers from middle of the packet. 657 Full Copyright Statement 659 Copyright (C) The Internet Society (2001). All Rights Reserved. 661 This document and translations of it may be copied and furnished to 662 others, and derivative works that comment on or otherwise explain it 663 or assist in its implementation may be prepared, copied, published 664 and distributed, in whole or in part, without restriction of any 665 kind, provided that the above copyright notice and this paragraph 666 are included on all such copies and derivative works. However, this 667 document itself may not be modified in any way, such as by removing 668 the copyright notice or references to the Internet Society or other 669 Internet organizations, except as needed for the purpose of 670 developing Internet standards in which case the procedures for 671 copyrights defined in the Internet Standards process must be 672 followed, or as required to translate it into languages other than 673 English. 675 The limited permissions granted above are perpetual and will not be 676 revoked by the Internet Society or its successors or assigns. 678 This document and the information contained herein is provided on an 679 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 680 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 681 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 682 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 683 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 685 Acknowledgement 687 Funding for the RFC editor function is currently provided by the 688 Internet Society.