idnits 2.17.1 draft-huttunen-ipsec-esp-in-udp-01.txt: ** The Abstract section seems to be numbered -(701): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 769 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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 316 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Therefore, TCP checksum MUST not be checked when the packet arrives secured by a SA using NAT encapsulation. UDP packets SHOULD have their xsum field set to 0 on sending into an SA using NAT encapsulation. UDP check sums MUST not be checked on receiving a packet in an SA using NAT encapsulation. -- 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 (March 2001) is 8443 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 106 looks like a reference -- Missing reference section? '1' on line 128 looks like a reference -- Missing reference section? '3' on line 468 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Huttunen, J. Sierwald 3 Expires September 2001 F-Secure Corporation 4 Category: Informational W. Dixon, B. Swander 5 Microsoft 6 V. Volpe 7 Cisco Systems 8 L. DiBurro 9 Nortel Networks 10 March 2001 12 IPsec ESP Encapsulation in UDP for NAT Traversal 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all provisions 18 of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering Task Force 21 (IETF), its areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months and may be 25 updated, replaced, or obsoleted by other documents at any time. It is 26 inappropriate to use Internet- Drafts as reference material or to cite them other 27 than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire September 2001 37 1. Abstract 39 NAT is widely used for Internet "connection sharing" and ships as a standard 40 feature in every router and edge device. Cable and DSL deployments have been 41 known to install NAT in embedded devices resident inside the home. Additionally 42 most hotel Internet connections are using NAT. Many airport & wireless services 43 in public areas use NAT to connect to the Internet. Some Internet Service 44 Providers use a centralized NAT to connect their clients to the Internet. 46 Without a solution to the problem, the L2TP/IPSec VPN client and an IPSec tunnel 47 mode VPN client can not connect from home or from business sites which use NAT to 48 connect to the Internet. Likewise, transport TCP and UPD traffic that is 49 protected by IPSec transport mode can not be exchanged between peer to peer or 50 server-to-server applications. 52 Without an IETF standard solution for IPSec over NAT, vendor products will not 53 interoperate, and will be forced to support multiple methods. 55 This proposal allows ESP to pass through NAT if the NAT allows UDP traffic. It 56 does not require the NAT to be aware of IPSec and IKE negotiation. The technique 57 is used only if the initiator and the responder support it. And it is only used 58 when necessary, because the initiator imbeds information that tells the responder 59 how the packet addressing was formatted when it was originally sent. 61 This technique allows L2TP protected by IPSec transport mode using the most 62 popular and default encryption format (IPSec ESP) to go through existing NATs 63 which do either port and address translation of UDP packets or pure-address 64 translation. 66 It also allows IPSec tunnel mode to go through the same type of NATs, a 67 requirement for many in the industry which implement IKECFG, XAUTH extensions to 68 IPSec tunnel mode for remote access. Address assignment can also use the standards 69 track DHCP over IPSec method. 71 Note however that when IPSec tunneling through a NAT between an end system 72 (static internal & external IP) and a gateway, or between two gateways - the 73 internal addresses used by packets inside the IPSec tunnel can not be changed, 74 even though the external address is changed so the internal packet will retain a 75 potentially invalid address on the destination network. To handle this case, we 76 can do one of the following: 78 - In the gateway-to-gateway case, perform a second NAT function either before the 79 tunnel ingress or after the tunnel egress to handle address space transitions. 80 -In the case where traffic inside the tunnel is clear text TCP & UDP 81 traffic, this is normal NAT and not affected by the IPSec tunnel (through 82 which that traffic passed) being NATed itself. 83 -In the case where traffic inside the IPSec tunnel is IPSec transport 84 traffic, this spec provides the mechanism for the IPSec transport peers to 85 detect this second NAT and pass it accordingly. 86 - Not use the RFC method of negotiating an IPSec tunnel, instead use address 87 assignment inside IKE (with or without IKECFG/XAUTH) for end-system to gateway 88 IPSec tunnels. 89 - Keep the internal address as is, and configure the destination network to be 90 able to handle it. 92 This method should be able to be used in all scales where NAT is deployed today to 93 do simple pure address-to-address, or address and port translation. However, it 94 will not be able to be used where the NAT would otherwise perform packet 95 inspection and replacement of address or port information inside the packet (e.g. 96 modifying the FTP PORT command packet). Thus UDP encapsulated IPSec transport and 97 tunnel traffic will be successful if the communications model is that the client 98 initiates TCP connections & UDP sessions from itself out through the NAT. 100 This protocol does not involve the client communicating directly with the NAT for 101 the purpose of opening ports to receive inbound connections. If required, another 102 method such as RSIP may be used by the application first to communicate with the 103 NAT. 105 IKE & IPSec issues with NAT are documented in this draft 106 (http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt ) [2]. This 107 proposal provides a solution to all issues identified when using IKE Identity 108 Protect Mode (Main Mode), Aggressive Mode or Quick Mode. Other extensions such as 109 ISAKMP Config Mode (IKECFG) and XAUTH may be present. Address assignment can also 110 use the standards track DHCP over IPSec method. 112 Most importantly, this proposal does not require change to the NAT device itself, 113 which is seen as practically too difficult, and presents a problem on the order of 114 magnitude similar to deployment of IPv6 where all end-systems, and at least 1 115 intermediate point (the NAT) must change. We expect the technique described here 116 to be used in the interim to pass IPv4 addressed traffic only and will become, one 117 hopes, outdated as IPv6 is deployed, enabling true end-to-end secure IPSec 118 communication without address translation. 120 2. Conventions used in this document 122 In examples, "C:" and "S:" indicate lines sent by the client and server 123 respectively. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 126 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 127 interpreted as described in RFC-2119 [1]. 129 3. Design Overview and Rationale 131 The IETF standard for NAT traversal by IPSec should be unencumbered from 132 intellectual property claims to ensure rapid adoption by the IPSec vendor 133 community. 135 We propose to UDP encapsulate the ESP traffic, thereby allowing it through the 136 NAT. 138 During design several different criteria needed to be balanced 139 -Encapsulation using UDP port 500 was chosen so as to enable easy deployment 140 without the need to change firewall rules used by corporations. 141 -The chosen method allows only ESP traffic to be encapsulated in UDP. This 142 ensures that the most widely needed traffic protection method is supported, 143 while ensuring that the method is as simple as possible, mainly in terms of 144 implementation effort. 145 -Encapsulation using UDP port 500 makes each packet 8 bytes larger than 146 encapsulation using a different port, this is however balanced by the reduced 147 need to have keepalive packets. 148 -UDP encapsulation can break some of the current HW offload products. 150 3.1 NAT Scenarios 152 All below scenarios may support an IPSec transport/tunnel SA for all possible 153 traffic, where 1 or more TCP or UDP sessions may be protected by the single IPSec 154 transport/tunnel SA pair. There may be multiple transport/tunnel SAs of finer 155 granularity as well. 157 A. One or more clients behind a NAT connecting simultaneously to a destination IP 159 Client1 private IP <-> NAT Internet IP <---------> Internet IP Server 160 Client2 private IP <-> 162 NAT is doing pure address translation 1:1, or doing address and port translation 163 many:1 165 B. One or more clients behind NAT1 connecting simultaneously to the same dest IP 166 address which is behind NAT2 168 client1 private IP <-> NAT1 Internet IP <-> Internet IP NAT2 <-> private IP 169 server 170 Client2 private IP <-> 172 NAT1 is performing many:1 port address translation, NAT2 is performing 1:1 address 173 translation (into DMZ) 175 C. One or more clients through 2 or more outbound NATs to destination Internet IP 176 address 178 Client1 private IP <-> NAT1 private IP <-> NAT2 Internet IP <-> Internet IP 179 Server 180 Client2 private IP <-> 182 NAT1, NAT2 are performing many:1 port address translation. 184 D. Internet client connecting to server behind NAT. 186 Client1 Internet IP <------------> Internet IP NAT <--> private IP Server1 187 <--> private IP Server2 189 NAT would most likely be doing 1:1 address translation. 191 E. Multiple clients identifically configured (i.e. Client1 and Client2 have the 192 same private network IP address assigned to them, like 10.1.2.3), each behind 193 their own NAT, connected to same Internet IP. 195 Client1 private IP <-> NAT1 Internet IP <-> Internet IP Server 196 Client2 private IP <-> NAT2 Internet IP <-> 198 F. One or more clients inside a GW, comprising a remote worker's home LAN, 199 connecting to the corporation's LAN protected by the corporation GW. Both home LAN 200 and corporation LAN are using IP addresses from the same private address pool. 202 Client1 private IP (corp) <-> GW private IP (isp) <-> NAT1 Internet IP <-> GW <-> 203 private IP (corp) <-> server 205 F1. an IPSec tunnel SA for all traffic, where 1 or more TCP or UDP sessions may be 206 protected by the single IPSec tunnel SA pair, between the two GWs. 208 3.2 Encapsulation Scheme and Keeping NAT mappings alive 210 We SHOULD provide a solution to keep alive the NAT port flow mapping - otherwise 211 rekey from the responder will fail - same issue for stateful FWs opening a hole 212 for corresponding inbound ports when it sees outbound src & dst port. See a 213 section below for the specifics on constructing and using a NAT keepalive packet. 215 This draft uses the well-known IKE UDP port 500 to encapsulate both IKE control 216 traffic and ESP data traffic. To distinguish these from one another, ESP traffic 217 contains 8 bytes of zero after the UDP header. Normal IKE packets would contain 218 the initiator cookie in this field which is never = 0. 220 ESP inside UDP encapsulation 221 ------------------------------------------------------------ 222 IPv4 |orig IP hdr | UDP | 8 bytes 0 |ESP | Data | 223 |(any options)| Hdr | |Header | | 224 ------------------------------------------------------------ 225 |<- encrypted->| 226 |<- authenticated -------->| 228 IKE control inside UDP encapsulation 229 ---------------------------------------------------------- 230 IPv4 |orig IP hdr | UDP | Initiator | Responder|Rest of IKE | 231 |(any options)| Hdr | Cookie | Cookie |Header Fields| 232 ---------------------------------------------------------- 234 Initiator cookies is 8 bytes, but non zero. Responder cookie is 8 bytes and may 235 be zero. Implementations must be resilient to modification of this 8 byte 0 236 field, making it non-zero and thus get received by IKE where it would attempt to 237 parse invalid data. 239 This approach allows for: 241 1. a single well known port over which ESP UDP encapsulation would be done. The 242 IKE port is already assigned, and well-known for IPSec so firewalls needn't 243 change, too. 245 2. minimization of keep-alive/heartbeats for both IKE & ESP - as long as there was 246 traffic flowing middle devices like stateful FWs & NATs would keep the mapping 247 alive 249 3. maintenance of alignment boundaries. 251 MTU reductions must be adjusted appropriated to account for 8 bytes + UDP header 252 for ESP payloads. 254 This approach doesn't support AH. 256 4. Implementation Details 258 4.1 IKE Main Mode exchange 260 IKE MM initiator SA payload 261 - Sends from IKE Src S, Dest 500. S is usually 500. This is not required, and 262 the initiator may choose to float its source port. 264 - Sends a VendorId payload of MD5("ESPThruNAT") 266 IKE MM responder SA payload 267 - Receive on UDP port 500. It may also be the case that implementations support 268 receiving on a non-500 destination port. We say this is a well-known-to-the- 269 client destination port in this case. 271 - If Vendor ID payload for ESPThruNAT present UDP encapsulation capability is 272 supported, the responder MUST construct and send the NAT Discovery payload of 273 MD5(Initiator IP addr, I port, Responder IP addr, R port). The IP addresses 274 and ports must be in network byte-order before calculating the hash. 276 - The port value 0 MUST NOT be used in the hash. If the internal representation 277 of the port is 0, 500 must be used for generating this hash. 279 - If the Initiator source port is not 500, store it for future use. In 280 scenarios A, B, and C, the source port is not likely to be 500. 282 - Reply back to initiator's source port 284 1 2 3 285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 ! Next Payload ! RESERVED ! Payload Length ! 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 ! ! 290 ~ NAT Discovery ~ 291 ! ! 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 17: NAT Discovery Payload Format 296 The NAT Discovery Payload fields are defined as follows: 298 o Next Payload (1 octet) - Identifier for the payload type of the 299 next payload in the message. If the current payload is the last 300 in the message, then this field will be 0. 302 o RESERVED (1 octet) - Unused, set to 0. 304 o Payload Length (2 octets) - Length in octets of the current 305 payload, including the generic payload header. 307 . NAT Discovery data (16 octets) - MD5 Hash = MD5(initiator IKE IP address, 308 initiator IKE port, responder IKE IP address, responder IKE port). For an IKE 309 packet constructed by the initiator: 310 o The initiator IP address is the source address of the packet. 4 octets 311 for V4 address, in network order. 16 octets for V6 address, in network 312 byte-order. 313 o The initiator port is the source port of the packet. 2 octets, network 314 byte-order. 315 o The responder IP address is the destination address of the packet. 4 316 octets for V4 address, in network order. 16 octets for V6 address, in 317 network byte-order. 318 o The responder port is the destination port of the packet. 2 octets, 319 network byte-order. 321 The payload type for the NAT Discovery Payload is one hundred thirty (130). 323 IKE MM Initiator KE payload 324 Upon receiving NAT Discovery payload, compute the equivalent MD5 hash locally and 325 compare with the received MD5 hash. If they differ, NAT is present. Send Vendor 326 Id payload of MD5("ESPThruNAT") and the locally generated NAT Discovery payload to 327 responder, so responder knows also whether NAT exists. If UDP encapsulation is 328 supported, the NAT Discovery payload MUST be sent. 330 IKE_MM_ID payload 331 If NAT Discovery payloads have determined that NAT is present, then IP addresses 332 SHOULD NOT be sent in the ID payload. Since the NAT may be changing the IP 333 addresses, sending an IP address that is incorrect as your ID is not recommended. 334 It is up to each peer's policy how to handle this scenario. The recommended 335 approach is to send fully qualified DNS name (FQDN) or some other sort of name- 336 based identity, such as the DN of the subject name in the certificate when using 337 RSA signature authentication. Since reverse DNS lookups may fail, it is again up 338 to local policy if/how to verify this identity. If a peer can determine that its 339 address is not going to be translated, i.e. the address is a 'real' address, then 340 this valid IP address can be sent as the MM Id. 342 4.2 Aggressive Mode 344 The rules for constructing the VID and the NAT Discovery Payload are the same as 345 for Main Mode. 346 In addition to normal aggressive mode: 348 IKE AM Initiator 349 - Send Vendor ID for ESPThruNAT 351 IKE_AM_Responder 352 - If Nat traversal is supported, the responder MUST send the Vendor ID for 353 ESPThruNAT and the Nat Discovery payload as defined above. 355 IKE AM Initiator 3rd message 356 - Send Nat Discovery payload. 358 Since Aggressive Mode sends the initiator's identity in the first payload, before 359 NAT Discovery Payloads are exchanged, the initiator cannot select a different 360 identity based on the result. If IP address based identity is used by the 361 initiator and NAT is detected to exist, a warning SHOULD be issued. 362 The Aggressive Mode negotiation MUST NOT be aborted for this reason, however. 364 4.3 Identity Protect Mode Phase 2 (Quick Mode) 366 IKE QM Initiator 367 If policy allows UDP encapsulation, construct a proposal to negotiate UDP 368 encapsulation. This will be encoded as the encapsulation attribute. Two new 369 values will be added, UDP-TRANSPORT (61441), and UDP-TUNNEL (61440). Any non-UDP 370 encapsulated offers MAY be rejected by the peer, depending on policy. 372 Initiator Proxy ID. The recommended proxy id is hostname FQDN in place of the 373 source address (scenario A, C) and destination address (scenario B, D) for 374 transport mode, with the same recommendations as the MM IDs. IP address MAY be 375 used as a proxy ID if that IP address is a 'real' address. For tunnel mode, this 376 ID can be the private address or net being protected. 378 Initiator 379 SA, ProxyID initiator, ProxyID Responder -----------> 380 [src addr, src port] [dest addr, dest port] 382 IKE_QM_Responder 383 - Receives offers, rejects all that are not NAT Encapsulated based on policy 384 - Local policy decision how to verify the proxy IDs. In transport mode, easiest 385 is to ignore it, and simply use the Main Mode address. 387 4.4 IPSec formats 389 This encapsulation method has the benefit of no additional IKE complexity, and NAT 390 keep alives are aggregated. However, the expense is an extra 8 bytes in the 391 header for each data packet. 393 IKE tells IPSec: 394 - inbound SA = ESPUDP protocol - normal ESP parameters 395 - outbound SA = ESPUDP protocol - normal ESP parameters 396 - which ports to use. In scenarios A & C, initiator machine inside NAT will use 397 src port S, dst port 500; Machine outside of NAT will use src port 500, dest 398 port NAT mapped port. S is usually 500, but may be floated. 400 IPSec formats IPSec packets as: 402 ESP inside UDP encapsulation 403 ------------------------------------------------------------ 404 IPv4 |orig IP hdr | UDP | 8 bytes 0 | ESP |Data | 405 |(any options)| Hdr | | Header | | 406 ------------------------------------------------------------ 407 |<- encrypted->| 408 |<--authenticated -------->| 410 IKE control inside UDP encapsulation 411 ---------------------------------------------------------- 412 IPv4 |orig IP hdr | UDP | Initiator | Responder|Rest of IKE | 413 |(any options)| Hdr | Cookie | Cookie |Header Fields| 414 ---------------------------------------------------------- 416 ESP over NAT packet format receiving: 417 - IPSec aware of new format inspects initiator cookie 8 bytes field - 418 decrypts if dword= 0. 419 - IPSec inspects initiator cookie - passes up UDP packet with initiator cookie set 420 <> 0 421 - Otherwise, IPSec strips UDP header, verifies that the UDP ports are the expected 422 values, and processes the ESP payload 424 ESP over NAT packet format outbound: 425 - IPSec transforms original packet into ESP 426 - IPSec takes constructs UDP encapsulation header with ports received from IKE, and 427 the rest of the ESP as usual. 429 As an example: 431 C <-> NAT <-> X 433 C sends srcport=500, dstport=500 (src 500,dst 500) 434 NAT modifies to (1000,500). X replies with (500,1000). NAT modifies to (500,500). 435 C gets (500,500). This is the same for both IKE and IPSec traffic. 437 Now if C is sending from a different source port than 500: 438 C sends (1111,500). NAT modifies to (2222,500). X replies to (500,2222). NAT 439 modifies to (500,1111). C gets (500,1111). 440 Since C's IPSec driver is going to need to determine this is an encapsulated 441 packet, it will need to know to look at dest port 1111 for all packets. Thus, 442 the IPSec subsystem MAY listen on well-known ports other than 500 for IPSec 443 traffic if mutually agreed upon by the peers. 445 4.3 NAT Keepalives 447 The keepalives will be sent by the Phase I initiator. The purpose of the 448 keepalives is only to keep up the NAT mapping, and not to keep alive any IKE or 449 IPSec or other state. Thus, the keepalive format is simply a UDP packet with the 450 correct source and destination ports and addresses. The packet contains a single 451 data octet of 0xff. This packet is sent as often as the initiator deems 452 necessary, and SHOULD be silently discarded by the receiving IPSec driver. The 453 keep alives SHOULD only be sent if traffic (either IKE of IPSec) is not already 454 present in the desired interval. In addition, in order to allow the peer outside 455 the NAT to initiate a rekey after the Main Mode has been torn down, the keep 456 alives SHOULD be continued for some configurable period after all MMs and QMs are 457 torn down. The default time for the extra keep alives SHOULD be 5 minutes. The 458 packet SHOULD be silently discarded. Since the NAT can fix-up the checksum of 459 this packet and this packet has no IPSec hashing to verify integrity, checksum 460 computation SHOULD be enabled for the keep alive packets. 462 NAT keepalive packet 463 ---------------------------- 464 IPv4 |orig IP hdr | UDP | 0xFF | 465 |(any options)| Hdr | | 466 ---------------------------- 468 See also ref [3]. 470 5. IPSec over NAT Operation 472 A: 10.1.1.1 10.1.1.11 NAT 172.1.1.1 X: 172.0.0.2 473 B: 10.1.1.2 475 We have machines A,B in the private address space, talking to the external machine 476 on the internet X. A initiates a MM to X. A sends the IKE packet with src IP = 477 10.1.1.1, dst IP= 172.0.0.2, src port = 500, dst port = 500. This packet hits the 478 NAT, which translates it to src IP = 172.1.1.1, src port = 6666. X gets the 479 packet, and remembers that it came from src port 6666, and sends IKE reply to src 480 IP 172.0.0.2, dst IP 172.1.1.1, src port 500, dst port 6666. The NAT will 481 translate this to 10.1.1.1, dst port 500, and send to A. The MM exchange 482 continues. At the end, A has a MM [10.1.1.1 (host FQDN),172.0.0.2, src 500, dst 483 500], and X has the MM [172.0.0.2, 172.1.1.1 (host FQDN), src 500, dst 6666]. If 484 we are doing preshared key authentication in MM, then machine A would send the 485 xxxxx as its IKE ID payload. 487 Now, for QM, A proposes the QM proxy IDs as [src host FQDN, dst host FQDN, proto, 488 src port, dest port] = [proxy source, proxy destination, protocol, src & dest 489 ports], and transform ID ESPNAT in the SA payload. The QM succeeds when source 490 port is ignored. When A plumbs the QM SAs into the driver (and possibly filters 491 to match it), it uses its real addresses. 493 Client A's QMs in driver: 494 A->X: [10.1.1.1,172.0.0.2, proto, src port, dst port]; UDP src 500, dst 500 495 X->A: [172.0.0.2,10.1.1.1, proto, src port, dst port]; UDP src *, dst 500 497 Gateway X's QMs in driver: 498 A->X: [172.1.1.1,172.0.0.2, proto, src port, dst port]; UDP src 6666, dst 500 499 X->A: [172.0.0.2,172.1.1.1, proto, src port, dst port]; UDP src 500, dst 6666 501 Now, the data packet is sent on A to 172.0.0.2. It matches the drivers outbound 502 filter, its outbound SA, and the driver encrypts it. It is sent out with IP src 503 10.1.1.1, dst 172.0.0.2, UDP src 500, dst 500. It hits the NAT, and the NAT 504 translates the src address, and source portcreates an entry for the SPI. When 505 the reply comes back from X, the NAT maps the SPI from X with the SPI send from A. 506 Now the NAT knows which internal host to send the packet to, and A gets it. 508 Multiple private network clients 510 Now B wants to connect to X. When B sends to X, the NAT will translate to 511 172.1.1.1, src port 7777. Thus, the NAT will be able to correctly multiplex X's 512 response. X will end up with 2 main modes, 1 to A and 1 to B. 513 To A: [172.0.0.2, 172.1.1.1, src 500, dst 6666] 514 To B: [172.0.0.2, 172.1.1.1, src 500, dst 7777] 515 Multiple private clients are handled by having the external machine add the 516 local/peer IKE ports to its SA key. 518 IKE Rekey 520 If the gateway X initiates a MM or QM rekey, it must do so from the same src (500) 521 to the same destination (6666). The NAT will have maintained the mapping 522 (assuming keep-alive scheme is present either in IKE or in layers above IPSec). 523 If the client A initiates a MM rekey, we just begin the above process over again. 525 TCP, UDP checksum in IPSec transport 527 We need to handle the tcp and udp checksum when IPSec ESP transport is used. The 528 IPSeced packet will look like (from RFC 2406): 530 AFTER APPLYING ESP 531 --------------------------------------------------------------- 532 IPv4 |orig IP hdr |UDP |8 bytes | ESP | | | ESP | ESP| 533 |(any options)|Hdr | 0 | Hdr | TCP | Data | Trailer |Auth| 534 --------------------------------------------------------------- 535 |<----- encrypted --------->| 536 |<-- authenticated -------------->| 538 Notice that none of the IP header is protected, so the NAT is free to modify the 539 addresses. When the NAT modifies the address in the IP header, it can recalculate 540 the IP checksum, which is also unprotected. However, in the TCP (or UDP) portion, 541 is the TCP (or UDP) header, which contains its own checksum. This checksum is 542 over the pseudoheader, which contains the src and dst addresses in the IP header. 543 Thus, if the NAT changes an address in the IP header, it cannot recomputed the TCP 544 (or UDP) checksum since that portion of the packet is encrypted. 546 There are 2 ways around this problem. One is disabling checksum checking on both 547 peers for packets on the SAs in question. The other option is to compute the TCP 548 (or UDP) checksum correctly before sending the packet, or after receiving the 549 packet. If done before sending the packet, it would require that the client know 550 its external address, which is not an assumption in this specification. If done 551 after decrypting the IPSec packet, but would be unnecessary CPU cycles if the 552 stack accepted the value of zero for checksum or using some other implementation 553 specific method. So the choice for performance reasons is to disable UDP & TCP 554 checksum by the stack when possible. 556 Disabling host OS UDP & TCP checksums loses very little functionality since nearly 557 the entire packet is protected by the hash from the ESP. This hash will verify 558 the integrity in transit of all fields protected by the TCP (or UDP) checksums 559 except for those fields in the pseudoheader. Of these fields (src, dst ip 560 address, protocol, length) src and dst address are generally the most important, 561 and verification of them is insured by possession of the session keys for the 562 IPSec session. For large TCP segments that result in multiple IP packets (initial 563 plus IP fragments), the TCP segment can only be reconstituted using individually 564 properly reassembled and authenticated IPSec packet. So there is no value in re- 565 checking TCP checksum. 567 Therefore, TCP checksum MUST not be checked when the packet arrives secured by a 568 SA using NAT encapsulation. UDP packets SHOULD have their xsum field set to 0 on 569 sending into an SA using NAT encapsulation. UDP check sums MUST not be checked on 570 receiving a packet in an SA using NAT encapsulation. 572 6. Justification of design 574 Other methods were carefully considered, and discarded. 576 6.1 Floated IKE port 577 First, there is the option of floating IKE to a different well-known port during 578 the negotiation, and the using this new port number as a demultiplexer. This 579 would allow the encapsulated packet format to be: 581 ESP inside UDP floated port encapsulation 582 -------------------------------------------------- 583 IPv4 |orig IP hdr | UDP |Type | ESP | Data | 584 |(any options)| Hdr | | Hdr | | 585 -------------------------------------------------- 586 |<-- encrypted->| 587 |<-- authenticated --------->| 589 The IKE format on the floated port is: 591 IKE control inside UDP encapsulation 592 ---------------------------------------------------------------- 593 IPv4 |orig IP hdr | UDP | Type |Initiator | Responder|Rest of IKE | 594 |(any options)| Hdr | |Cookie | Cookie |Header Fields| 595 ---------------------------------------------------------------- 597 This would allow the 4 octet type field to give the type of the data following. 598 We can modify these formats in this way because the floated port distinguished 599 between the normal IKE format on port 500, and this format on the new port. 601 This method was discarded because it is very difficult to float IKE to a new port. 602 The biggest difficulty is resolving the conflict between floating the port, 603 preferably before any quick modes are negotiated, yet negotiating in quick mode 604 the encapsulation attribute. Thus, we'd have to always float IKE to a new port if 605 NAT were detected, even if that NAT is known to be IPSec aware, and that UDP 606 encapsulation, and therefore IKE floating is unneeded. However, even though IKE 607 would need to be floated always, actual ESP traffic could be either encapsulated 608 in UDP or not, as defined by policy and as negotiated by QM. 610 In addition, firewalls will need to open another UDP hole, which will meet with 611 strong opposition. 613 6.2 Using two UDP ports 615 This approach left IKE on 500, and encapsulates the IPSec traffic using a 616 different well-known port. The biggest problem with this is that 2 sets of keep- 617 alives must be sent to keep the NAT mappings alive. This will be expensive for 618 the IKE mapping, since IKE traffic is usually infrequent. For wireless, this is 619 extremely expensive. The second problem is that the IPSec subsystem doesn't get 620 the encapsulation information (the ports) from IKE, but must create that state 621 upon receiving the first encapsulated packet. This is more prone to denial of 622 service. It is possible to fail the connection if the attacker grabs the first 623 encapsulated packet, and modifies the unprotected encapsulation header before the 624 receiving IPSec subsystem gets it. This would cause the receiving IPSec 625 subsystem to create state based upon an incorrect mapping, and traffic would fail. 626 The proposed approach is more immune to these first packet manipulations, since an 627 attacker who modified the ports in the UDP header of the initial IKE packet would 628 only cause multiple Main Modes state entries to be created on the responder, but 629 wouldn't necessarily scuttle the connection. 631 This method will also make firewalls open an additional UDP hole. 633 7. Security Considerations 635 The authors do not think this method exposes any security vulnerabilities into 636 otherwise sound IPSec implementation. However, the following issues need to be 637 addressed by implementers. 639 When using IPsec tunnel mode, clients connecting to the gateway may be using the 640 same IP address in the inner IP header. One scenario where this is likely to 641 happen is when the clients are using in the inner IP header their local private 642 network address, and they are in different private networks. The GW MUST ensure 643 that traffic destined towards the clients is sent only to the correct recipient. 645 When using IPsec tunnel mode, a client connecting to a gateway may be trying to 646 steal an IP address from the network protected by the gateway. The QM initiated 647 by the client MUST only be allowed by the gateway if: 648 - The QM IP address identities match the static policy defined at the gateway. 649 - The QM IP source address matches the address assigned to the client by the 650 gateway. 651 - The gateway is configured to do further NAT to the packets, ensuring that 652 whatever IP address the client is using, this cannot be used to steal local 653 network IP addresses. 654 Any of these ensures that attacker is not possible to steal local network IP 655 addresses. 657 8. References 659 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 660 Levels", BCP 14, RFC 2119, March 1997 662 2 Aboba, B., "NAT and IPSEC", Internet draft (work in progress), 663 draft-aboba-nat-ipsec-02.txt, July 2000 665 3 Huitema, C., "Short term NAT requirements for UDP based peer-to-peer 666 applications", Internet draft (work in progress), 667 draft-huitema-natreq4udp-00.txt, February 2001 669 The following IETF WGs have work which has fed into this specification and could 670 be the one to pursue standardizing a solution: 671 NAT Working Group: http://www.ietf.org/html.charters/nat-charter.html 672 IPSec Working Group: http://www.ietf.org/html.charters/ipsec-charter.html 673 IPSec Remote Access Working Group: http://www.ietf.org/html.charters/ipsra- 674 charter.html 676 IKE & IPSec issues with NAT are documented in these drafts. 678 http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt 679 http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-04.txt 681 Lucent has published an information RFC to describe how IPSec tunnels can pass 682 through NATs. 683 http://www.ietf.org/rfc/rfc2709.txt 685 Lucent has documented the VPN Masquerade method of IPSec over NAT, where the NAT 686 is aware of IKE and ESP traffic specifically and takes steps to estimate how to 687 pass the traffic. 688 http://search.ietf.org/internet-drafts/draft-brustoloni-vma-00.txt 690 3Com and others have documented a method for IPSec traversal of NATs where the NAT 691 is changed to support communication with the IPSec peer: 692 http://search.ietf.org/internet-drafts/draft-ietf-nat-rsip-ipsec-04.txt 694 SSH Communications Security is known to have intellectual property on some parts 695 of their design documented in the link below. This design we believe avoids what 696 we guess is the intellectual property. 697 http://search.ietf.org/internet-drafts/draft-stenberg-ipsec-nat-traversal-01.txt 699 0. Acknowledgments 701 Tamir Zegman of CheckPoint provided helpful advice for producing the �00 version 702 of this draft. 704 Many people engaged in discussion which lead to this proposal. In particular, 705 engineers at Microsoft, Cisco Systems, Checkpoint, F-Secure, SSH Communications 706 Security, Inc. 708 1. Author's Addresses 710 Ari Huttunen 711 F-Secure Corporation 712 Phone: +358-9-2520 0700 713 E-Mail: Ari.Huttunen@F-Secure.com 715 Joern Sierwald 716 F-Secure Corporation 717 E-Mail: Joern@F-Secure.com 719 William Dixon, Brian Swander 720 Microsoft 721 One Microsoft Way, Redmond WA 98052 722 Phone: 425-703-8729 723 Email: wdixon@microsoft.com 725 Victor Volpe 726 Cisco Systems 727 Email: vvolpe@cisco.com 729 Larry DiBurro 730 Nortel Networks 731 Phone: 978-264-7171 732 ldiburro@nortelnetworks