idnits 2.17.1 draft-ietf-behave-tcp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 865. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 23, 2007) is 6262 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1644 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Guha, Ed. 3 Internet-Draft Cornell U. 4 Intended status: Best Current K. Biswas 5 Practice Cisco Systems 6 Expires: August 27, 2007 B. Ford 7 M.I.T. 8 S. Sivakumar 9 Cisco Systems 10 P. Srisuresh 11 Consultant 12 February 23, 2007 14 NAT Behavioral Requirements for TCP 15 draft-ietf-behave-tcp-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 27, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document defines a set of requirements for NATs that handle TCP 49 that would allow many applications, such as peer-to-peer applications 50 and on-line games, to work consistently. Developing NATs that meet 51 this set of requirements will greatly increase the likelihood that 52 these applications will function properly. 54 Table of Contents 56 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. TCP Connection Initiation . . . . . . . . . . . . . . . . . . 4 60 4.1. Address and Port Mapping Behavior . . . . . . . . . . . . 4 61 4.2. Internally Initiated Connections . . . . . . . . . . . . . 5 62 4.3. Externally Initiated Connections . . . . . . . . . . . . . 6 63 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 9 64 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 11 65 7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12 66 7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12 67 7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 12 68 7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13 69 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9. Security considerations . . . . . . . . . . . . . . . . . . . 14 71 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 12.2. Informational References . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 77 Intellectual Property and Copyright Statements . . . . . . . . . . 20 79 1. Applicability Statement 81 This document is adjunct to [BEHAVE-UDP], which defines many terms 82 relating to NATs, lays out general requirements for all NATs, and 83 sets requirements for NATs that handle IP and unicast UDP traffic. 84 The purpose of this document is to set requirements for NATs that 85 handle TCP traffic. 87 The requirements of this specification apply to Traditional NATs as 88 described in [RFC2663]. 90 This document only covers the TCP aspects of NAT traversal. Middle- 91 box behavior that is not necessary for network address translation of 92 TCP is out-of-scope. Firewalls, and packet inspection above the TCP 93 layer are out-of-scope except for Application Level Gateways (ALG) 94 behavior that may interfere with NAT traversal. Application and OS 95 aspects of TCP NAT traversal are out-of-scope. Signaling based 96 approaches to NAT traversal such as Midcom and UPnP that directly 97 control the NAT are out-of-scope. 99 2. Introduction 101 Network Address Translators (NATs) hinder connectivity in 102 applications where sessions may be initiated to internal hosts. 103 Readers may refer to [RFC3022] for detailed information on 104 traditional NATs. [BEHAVE-UDP] lays out the terminology and 105 requirements for NATs in the context of IP and UDP. This document 106 supplements these by setting requirements for NATs that handle TCP 107 traffic. All definitions and requirements in [BEHAVE-UDP] are 108 inherited here. 110 [RFC4614] chronicles the evolution of TCP from the original 111 definition [RFC0793] to present day implementations. While much has 112 changed in TCP with regards to congestion control and flow control, 113 security, and support for high-bandwidth networks, the process of 114 initiating a connection (i.e. the 3-way handshake or simultaneous- 115 open) has changed little. It is the process of connection initiation 116 that NATs affect the most. Experimental approaches such as T/TCP 117 [RFC1644] have proposed alternate connection initiation approaches, 118 but, have been found to be complex and susceptible to denial-of- 119 service attacks. Modern operating systems and NATs consequently 120 primarily support the 3-way handshake and simultaneous-open modes of 121 connection initiation as described in [RFC0793]. 123 Recently, many techniques have been devised to make peer-to-peer TCP 124 applications work across NATs. [STUNT], [NATBLASTER], and [P2PNAT] 125 describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow 126 peer-to-peer applications to establish TCP through NATs. These 127 approaches require only endpoint applications to be modified and work 128 with standards compliant OS stacks. The approaches, however, depend 129 on specific NAT behavior that is usually, but not always, supported 130 by NATs (see [TCPTRAV] and [P2PNAT] for details). Consequently a 131 complete TCP NAT traversal solution is sometimes forced to rely on 132 public TCP relays to traverse NATs that do not cooperate. This 133 document defines requirements that ensure that TCP NAT traversal 134 approaches are not forced to use data relays. 136 3. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 This document uses the term "NAT session" as defined in [RFC2663]. 143 "NAT" in this specification includes both "Basic NAT" and "Network 144 Address/Port Translator (NAPT)" [RFC2663]. 146 This document uses the term "TCP connection" (or just "connection") 147 to refer to individual TCP flows identified by the 4-tuple (source 148 and destination IP address and TCP port) and the initial sequence 149 numbers (ISN). 151 This document uses the term "address and port mapping" (or just 152 "mapping") as defined in [BEHAVE-UDP] to refer to state at the NAT 153 necessary for network address and port translation of TCP 154 connections. This document also uses the terms "endpoint independent 155 mapping", "address dependent mapping", "address and port dependent 156 mapping", "filtering behavior", "endpoint independent filtering", 157 "address dependent filtering", "address and port dependent 158 filtering", "port assignment", "port overloading", "hairpinning", and 159 "external source IP address and port" as defined in [BEHAVE-UDP]. 161 4. TCP Connection Initiation 163 This section describes various NAT behaviors applicable to TCP 164 connection initiation. 166 4.1. Address and Port Mapping Behavior 168 A NAT uses a mapping to translate packets for each TCP connection. A 169 mapping is dynamically allocated for connections initiated from the 170 internal side, and potentially reused for certain subsequent 171 connections. NAT behavior regarding when a mapping can be reused 172 differs for different NATs as described in [BEHAVE-UDP]. 174 Consider an internal IP address and TCP port (X:x) that initiates a 175 TCP connection to an external (Y1:y1) tuple. Let the mapping 176 allocated by the NAT for this connection be (X1':x1'). Shortly 177 thereafter, the endpoint initiates a connection from the same (X:x) 178 to an external address (Y2:y2) and gets the mapping (X2':x2') on the 179 NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all 180 values of (Y2:y2) then the NAT is defined to have "Endpoint 181 Independent Mapping" behavior. If (X1':x1') equals (X2':x2') only 182 when Y2 equals Y1 then the NAT is defined to have "Address Dependent 183 Mapping" behavior. If (X1':x1') equals (X2':x2') only when (Y2:y2) 184 equals (Y1:y1), possible only for consecutive connections to the same 185 external address shortly after the first is terminated and if the NAT 186 retains state for connections in TIME_WAIT state, then the NAT is 187 defined to have "Address and Port Dependent Mapping" behavior. This 188 document introduces one additional behavior where (X1':x1') never 189 equals (X2':x2'), that is, for each connection a new mapping is 190 allocated; in such a case, the NAT is defined to have "Connection 191 Dependent Mapping" behavior. 193 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior 194 for TCP. 196 Justification: REQ-1 is necessary for UNSAF methods to work. 197 Endpoint independent mapping behavior allows peer-to-peer 198 applications to learn and advertise the external IP address and 199 port allocated to an internal endpoint such that external peers 200 can contact it (subject to the NAT's security policy). The 201 security policy of a NAT is independent of its mapping behavior 202 and is discussed later in Section 4.3. Having endpoint 203 independent mapping behavior allows peer-to-peer applications to 204 work consistently without compromising the security benefits of 205 the NAT. 207 4.2. Internally Initiated Connections 209 An internal endpoint initiates a TCP connection through a NAT by 210 sending a SYN packet. The NAT allocates (or reuses) a mapping for 211 the connection, as described in the previous section. The mapping 212 defines the external IP address and port used for translation of all 213 packets for that connection. In particular, for client-server 214 applications where an internal client initiates the connection to an 215 external server, the mapping is used to translate the outbound SYN, 216 the resulting inbound SYNACK response, the subsequent outbound ACK, 217 and other packets for the connection. This method of connection 218 initiation corresponds to the 3-way handshake (defined in [RFC0793]) 219 and is supported by all NATs. 221 Peer-to-peer applications use an alternate method of connection 222 initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse 223 NATs. In the Simultaneous-Open mode of operation, both peers send 224 SYN packets for the same TCP connection. The SYN packets cross in 225 the network. Upon receiving the other end's SYN packet each end 226 responds with a SYNACK packet, which also cross in the network. The 227 connection is considered established once the SYNACKs are received. 228 From the perspective of the NAT, the internal host's SYN packet is 229 met by an inbound SYN packet for the same connection (as opposed to a 230 SYNACK packet during a 3-way handshake). Subsequent to this 231 exchange, both an outbound and an inbound SYNACK are seen for the 232 connection. Some NATs erroneously block the inbound SYN for the 233 connection in progress. Some NATs block or incorrectly translate the 234 outbound SYNACK. Such behavior breaks TCP simultaneous-open and 235 prevents peer-to-peer applications from functioning correctly behind 236 a NAT. 238 In order to provide network address translation service for TCP, it 239 is necessary for a NAT to correctly receive, translate, and forward 240 all packets for a connection that conform to valid transitions of the 241 TCP State-Machine (Fig. 6, [RFC0793]). 243 REQ-2: A NAT MUST support all valid sequences of TCP packets 244 (defined in [RFC0793]) for connections initiated both internally 245 as well as externally when the connection is permitted by the NAT. 246 In particular: 247 a) In addition to handling the TCP 3-way handshake mode of 248 connection initiation, A NAT MUST handle the TCP simultaneous- 249 open mode of connection initiation. 251 Justification: The intent of this requirement is to allow standards 252 compliant TCP stacks to traverse NATs no matter what path the 253 stacks take through the TCP state-machine and no matter which end 254 initiates the connection as long as the connection is permitted by 255 the filtering policy of the NAT (filtering policy is described in 256 the following section). 257 a) In addition to TCP packets for a 3-Way Handshake, A NAT must be 258 prepared to accept an inbound SYN and an outbound SYNACK for an 259 internally initiated connection in order to support 260 Simultaneous-Open. 262 4.3. Externally Initiated Connections 264 The NAT allocates a mapping for the first connection initiated by an 265 internal endpoint to an external endpoint. In some scenarios, the 266 NAT's policy may allow this mapping to be reused for connections 267 initiated from the external side to the internal endpoint. Consider 268 as before an internal IP address and port (X:x) that is assigned (or 269 reuses) a mapping (X1':x1') when it initiates a connection to an 270 external (Y1:y1). An external endpoint (Y2:y2) attempts to initiate 271 a connection with the internal endpoint by sending a SYN to 272 (X1':x1'). A NAT can choose to either allow the connection to be 273 established, or to disallow the connection. If the NAT chooses to 274 allow the connection, it translates the inbound SYN and routes it to 275 (X:x) as per the existing mapping. It also translates the SYNACK 276 generated by (X:x) in response and routes it to (Y2:y2) and so on. 277 Alternately, the NAT can disallow the connection by filtering the 278 inbound SYN. 280 A NAT may allow an existing mapping to be reused by an externally 281 initiated connection if its security policy permits. Several 282 different policies are possible as described in [BEHAVE-UDP]. If a 283 NAT allows the connection initiation from all (Y2:y2) then it is 284 defined to have "Endpoint Independent Filtering" behavior. If the 285 NAT allows connection initiations only when Y2 equals Y1 then the NAT 286 is defined to have "Address Dependent Filtering" behavior. If the 287 NAT allows connection initiations only when (Y2:y2) equals (Y1:y1), 288 then the NAT is defined to have "Address and Port Dependent 289 Filtering" behavior (possible only shortly after the first connection 290 has been terminated but the mapping is still active). One additional 291 filtering behavior defined in this document is when the NAT does not 292 allow any connection initiations from the external side; in such 293 cases, the NAT is defined to have "Connection Dependent Filtering" 294 behavior. The difference between "Address and Port Dependent 295 Filtering" and "Connection Dependent Filtering" behavior is that the 296 former permits an inbound SYN during the TIME_WAIT state of the first 297 connection to initiate a new connection while the latter does not. 299 REQ-3: If application transparency is most important, it is 300 RECOMMENDED that a NAT have an "Endpoint independent filtering" 301 behavior for TCP. If a more stringent filtering behavior is most 302 important, it is RECOMMENDED that a NAT have an "Address dependent 303 filtering" behavior. 304 a) The filtering behavior MAY be an option configurable by the 305 administrator of the NAT. 306 b) The filtering behavior for TCP MAY be independent of the 307 filtering behavior for UDP. 309 Justification: The intent of this requirement is to allow peer-to- 310 peer applications that do not always initiate connections from the 311 internal side of the NAT to continue to work in the presence of 312 NATs. This behavior also allows applications behind a BEHAVE 313 compliant NAT to inter-operate with remote endpoints that are 314 behind non-BEHAVE compliant (legacy) NATs. If the remote 315 endpoint's NAT does not have endpoint independent mapping behavior 316 but has only one external IP address, then an application can 317 still traverse the combination of the two NATs if the local NAT 318 has address dependent filtering. Section 9 contains a detailed 319 discussion on the security implications of this requirement. 321 If the inbound SYN packet is filtered, either because a corresponding 322 mapping does not exist or because of the NAT's filtering behavior, a 323 NAT has two basic choices: to ignore the packet silently, or to 324 signal an error to the sender. Signaling an error through ICMP 325 messages allows the sender to quickly detect that the SYN did not 326 reach the intended destination. Silently dropping the packet, on the 327 other hand, allows applications to perform Simultaneous-Open more 328 reliably. 330 Silently dropping the SYN aids Simultaneous-Open as follows. 331 Consider that the application is attempting a Simultaneous-Open and 332 the outbound SYN from the internal endpoint has not yet crossed the 333 NAT (due to network congestion or clock skew between the two 334 endpoints); this outbound SYN would otherwise have created the 335 necessary mapping at the NAT to allow translation of the inbound SYN. 336 Since the outbound SYN did not reach the NAT in time, the inbound SYN 337 cannot be processed. If a NAT responds to the premature inbound SYN 338 with an error message that forces the external endpoint to abandon 339 the connection attempt, it hinders applications performing a TCP 340 simultaneous-open. If instead the NAT silently ignores the inbound 341 SYN, the external endpoint retransmits the SYN after a TCP timeout. 342 In the meantime, the NAT creates the mapping in response to the 343 (delayed) outbound SYN such that the retransmitted inbound SYN can be 344 routed and simultaneous-open can succeed. The down-side to this 345 behavior is that in the event the inbound SYN is erroneous, the 346 remote side does not learn of the error until after several TCP 347 timeouts. 349 NAT support for simultaneous-open as well as quickly signaling errors 350 are both important for applications. Unfortunately, there is no way 351 for a NAT to signal an error without forcing the endpoint to abort a 352 potential simultaneous-open: TCP RST and ICMP Port Unreachable 353 packets require the endpoint to abort the attempt while ICMP Host and 354 Network Unreachable errors may adversely affect other connections to 355 the same host or network [RFC1122]. 357 In addition, when an unsolicited SYN is received by the NAT, the NAT 358 may not know whether the application is attempting a simultaneous- 359 open (and that it should therefore silently drop the SYN) or whether 360 the SYN is in error (and that it should notify the sender). 362 REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet 363 for at least 6 seconds after the packet is received. If during 364 this interval the NAT receives and translates an outbound SYN for 365 the connection the NAT MUST silently drop the original unsolicited 366 inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port 367 Unreachable error (Type 3, Code 3) for the original SYN, unless 368 REQ-4a applies. 369 a) The NAT MUST silently drop the original SYN packet if sending a 370 response violates the security policy of the NAT. 372 Justification: The intent of this requirement is to allow 373 simultaneous-open to work reliably in the presence of NATs as well 374 as to quickly signal an error in case the unsolicited SYN is in 375 error. As of writing this memo, it is not possible to achieve 376 both; the requirement therefore represents a compromise. The NAT 377 should tolerate some delay in the outbound SYN for a TCP 378 simultaneous-open, which may be due to network congestion or loose 379 synchronization between the endpoints. If the unsolicited SYN is 380 not part of a simultaneous-open attempt and is in error, the NAT 381 should endeavor to signal the error in accordance with [RFC1122]. 382 a) There may, however, be reasons for the NAT to rate-limit or 383 omit such error notifications, for example in the case of an 384 attack. Silently dropping the SYN packet when under attack 385 allows simultaneous-open to work without consuming any extra 386 network bandwidth or revealing the presence of the NAT to 387 attackers. Section 9 mentions the security considerations for 388 this requirement. 390 5. NAT Session Refresh 392 A NAT maintains state associated with in-progress and established 393 connections. Because of this, a NAT is susceptible to a resource- 394 exhaustion attack whereby an attacker (or virus) on the internal side 395 attempts to cause the NAT to create more state than it has resources 396 for. To prevent such an attack, a NAT needs to abandon sessions in 397 order to free the state resources. 399 A common method that is applicable only to TCP is to preferentially 400 abandon sessions for crashed endpoints, followed by closed TCP 401 connections and partially-open connections. A NAT can check if an 402 endpoint for a session has crashed by sending a TCP keep-alive packet 403 and receiving a TCP RST packet in response. If the NAT cannot 404 determine whether the endpoint is active, it should not abandon the 405 session until the TCP connection has been idle for some time. Note 406 that an established TCP connection can stay idle (but live) 407 indefinitely; hence there is no fixed value for an idle-timeout that 408 accommodates all applications. However, a large idle-timeout 409 motivated by recommendations in [RFC1122] can reduce the chances of 410 abandoning a live session. 412 A TCP connection passes through three phases: partially-open, 413 established, and closing. During the partially-open phase, endpoints 414 synchronize initial sequence numbers. The phase is initiated by the 415 first SYN for the connection and extends until both endpoints have 416 sent a packet with the ACK flag set (TCP states: SYN_SENT and 417 SYN_RCVD). ACKs in both directions mark the beginning of the 418 established phase where application data can be exchanged 419 indefinitely (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and 420 CLOSE_WAIT). The closing phase begins when both endpoint have 421 terminated their half of the connection by sending a FIN packet. 422 Once FIN packets are seen in both directions, application data can no 423 longer be exchanged but the stacks still need to ensure that the FIN 424 packets are received (TCP states: CLOSING and LAST_ACK). 426 TCP connections can stay in established phase indefinitely without 427 exchanging any packets. Some end-hosts can be configured to send 428 keep-alive packets on such idle connections; by default, such keep- 429 alive packets are sent every 2 hours if enabled [RFC1122]. 430 Consequently, a NAT that waits for slightly over 2 hours can detect 431 idle connections with keep-alive packets being sent at the default 432 rate. TCP connections in the partially-open or closing phases, on 433 the other hand, can stay idle for at most 4 minutes while waiting for 434 in-flight packets to be delivered [RFC1122]. 436 The "established connection idle-timeout" for a NAT is defined as the 437 minimum time a TCP connection in the established phase must remain 438 idle before the NAT considers the associated session a candidate for 439 removal. The "transitory connection idle-timeout" for a NAT is 440 defined as the minimum time a TCP connection in the partially-open or 441 closing phases must remain idle before the NAT considers the 442 associated session a candidate for removal. TCP connections in the 443 TIME_WAIT state are not affected by the "transitory connection idle- 444 timeout". 446 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 447 connection are active, it MAY abandon the session if it has been 448 idle for some time. In such cases, the value of the "established 449 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 450 The value of the "transitory connection idle-timeout" MUST NOT be 451 less than 4 minutes. 452 a) The value of the NAT idle-timeouts MAY be configurable. 454 Justification: The intent of this requirement is to minimize the 455 cases where a NAT abandons session state for a live connection. 456 While some NATs may choose to abandon sessions reactively in 457 response to new connection initiations (allowing idle connections 458 to stay up indefinitely in the absence of new initiations), other 459 NATs may choose to proactively reap idle sessions. In cases where 460 the NAT cannot actively determine if the connection is alive, this 461 requirement ensures that applications can send keep-alive packets 462 at the default rate (every 2 hours) such that the NAT can 463 passively determine that the connection is alive. The additional 464 4 minutes allows time for in-flight packets to cross the NAT. 466 NAT behavior for handling RST packets, or connections in TIME_WAIT 467 state is left unspecified. A NAT MAY hold state for a connection in 468 TIME_WAIT state to accommodate retransmissions of the last ACK. 469 However, since the TIME_WAIT state is commonly encountered by 470 internal endpoints properly closing the TCP connection, holding state 471 for a closed connection may limit the throughput of connections 472 through a NAT with limited resources. [RFC1337] describes hazards 473 associated with TIME_WAIT assassination. 475 The handling of non-SYN packets for connections for which there is no 476 active mapping is left unspecified. Such packets may be received if 477 the NAT silently abandons a live connection, or abandons a connection 478 in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The 479 decision to either silently drop such packets or to respond with a 480 TCP RST packet is left up to the implementation. 482 6. Application Level Gateways 484 Application Level Gateways (ALGs) in certain NATs modify IP addresses 485 and TCP ports embedded inside application protocols. Such ALGs may 486 interfere with UNSAF methods or protocols that try to be NAT-aware 487 and must therefore be used with extreme caution. 489 REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED 490 that all of those ALGs (except for FTP [RFC0959]) be disabled by 491 default. 493 Justification: The intent of this requirement is to prevents ALGs 494 from interfering with UNSAF methods. The default state of a FTP 495 ALG is left unspecified because of legacy concerns: as of writing 496 this memo, a large fraction of legacy FTP clients do not enable 497 PASV mode by default and require an ALG to traverse NATs. 499 7. Other Requirements Applicable to TCP 501 A list of general and UDP specific NAT behavioral requirements are 502 described in [BEHAVE-UDP]. A list of ICMP specific NAT behavioral 503 requirements are described in [BEHAVE-ICMP]. The requirements listed 504 below reiterate the requirements from these two documents that 505 directly affect TCP. The following requirements do not relax any 506 requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. 508 7.1. Port Assignment 510 NATs that allow different internal endpoints to simultaneously use 511 the same mapping are defined in [BEHAVE-UDP] to have a "Port 512 assignment" behavior of "Port overloading". Such behavior is 513 undesirable as it prevents two internal endpoints sharing the same 514 mapping from establishing simultaneous connections to a common 515 external endpoint. 517 REQ-7 A NAT MUST NOT have a "Port assignment" behavior of "Port 518 overloading" for TCP. 520 Justification: This requirement allows two applications on the 521 internal side of the NAT to consistently communicate with the same 522 destination. 524 NAT behavior for preserving the source TCP port range for connections 525 is left unspecified. Some applications expect the source TCP port to 526 be in the well-known range (TCP ports from 0 to 1023). The "r" 527 series of commands (rsh, rcp, rlogin, etc.) are an example. NATs 528 that preserve the range from which the source port is picked allow 529 such applications to function properly through the NAT, however, by 530 doing so the NAT may compromise the security of the application in 531 certain situations; applications that depend only on the IP address 532 and source TCP port range for security (the "r" commands for example) 533 cannot distinguish between an attacker and a legitimate user behind 534 the same NAT. 536 7.2. Hairpinning Behavior 538 NATs that forward packets originating from an internal address, 539 destined for an external address that matches the active mapping for 540 an internal address, back to that internal address are defined in 541 [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the 542 hairpinned packet with an external source IP address and port (i.e. 543 the mapped source address and port of the originating internal 544 endpoint), then it is defined to have "External source IP address and 545 port" for hairpinning. Hairpinning is necessary to allow two 546 internal endpoints (known to each other only by their external mapped 547 addresses) to communicate with each other. "External source IP 548 address and port" behavior for hairpining avoids confusing 549 implementations that expect the external source address and port. 551 REQ-8: A NAT MUST support "Hairpinning" for TCP. 552 a) A NAT's Hairpinning behavior MUST be of type "External source 553 IP address and port". 555 Justification: This requirement allows two applications behind the 556 same NAT that are trying to communicate with each other using 557 their external addresses. 558 a) Using the external source address and port for the hairpinned 559 packet is necessary for applications that do not expect to 560 receive a packet from a different address than the external 561 address they are trying to communicate with. 563 7.3. ICMP Responses to TCP Packets 565 ICMP responses are used by end-host TCP stacks for Path MTU Discovery 566 and for quick error detection. ICMP messages are rewritten by the 567 NAT (specifically the IP headers and the headers inside the ICMP 568 payload) and forwarded to the appropriate internal or external host. 569 Blocking any ICMP message is discouraged. 571 REQ-9: Receipt of any sort of ICMP message MUST NOT terminate the 572 NAT mapping or TCP connection for which the ICMP was generated. 574 Justification: This is necessary for reliably performing TCP 575 simultaneous-open where a remote NAT may temporarily signal an 576 ICMP error. It is also useful for MTU discovery. 578 8. Requirements 580 A NAT that supports all of the mandatory requirements of this 581 specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], 582 is "compliant with this specification". A NAT that supports all of 583 the requirements of this specification (i.e., included the 584 "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully 585 compliant with all the mandatory and recommended requirements of this 586 specification". 588 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior 589 for TCP. 591 REQ-2: A NAT MUST support all valid sequences of TCP packets 592 (defined in [RFC0793]) for connections initiated both internally 593 as well as externally when the connection is permitted by the NAT. 594 In particular: 595 a) In addition to handling the TCP 3-way handshake mode of 596 connection initiation, A NAT MUST handle the TCP simultaneous- 597 open mode of connection initiation. 598 REQ-3: If application transparency is most important, it is 599 RECOMMENDED that a NAT have an "Endpoint independent filtering" 600 behavior for TCP. If a more stringent filtering behavior is most 601 important, it is RECOMMENDED that a NAT have an "Address dependent 602 filtering" behavior. 603 a) The filtering behavior MAY be an option configurable by the 604 administrator of the NAT. 605 b) The filtering behavior for TCP MAY be independent of the 606 filtering behavior for UDP. 607 REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet 608 for at least 6 seconds after the packet is received. If during 609 this interval the NAT receives and translates an outbound SYN for 610 the connection the NAT MUST silently drop the original unsolicited 611 inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port 612 Unreachable error (Type 3, Code 3) for the original SYN, unless 613 REQ-4a applies. 614 a) The NAT MUST silently drop the original SYN packet if sending a 615 response violates the security policy of the NAT. 616 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 617 connection are active, it MAY abandon the session if it has been 618 idle for some time. In such cases, the value of the "established 619 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 620 The value of the "transitory connection idle-timeout" MUST NOT be 621 less than 4 minutes. 622 a) The value of the NAT idle-timeouts MAY be configurable. 623 REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED 624 that all of those ALGs (except for FTP [RFC0959]) be disabled by 625 default. 626 REQ-7 A NAT MUST NOT have a "Port assignment" behavior of "Port 627 overloading" for TCP. 628 REQ-8: A NAT MUST support "Hairpinning" for TCP. 629 a) A NAT's Hairpinning behavior MUST be of type "External source 630 IP address and port". 631 REQ-9: Receipt of any sort of ICMP message MUST NOT terminate the 632 NAT mapping or TCP connection for which the ICMP was generated. 634 9. Security considerations 636 Security concerns specific to handling TCP packets are discussed in 637 this section. 639 Security considerations for REQ-1: This requirement does not 640 introduce any TCP-specific security concerns. 641 Security considerations for REQ-2: This requirement does not 642 introduce any TCP-specific security concerns. Simultaneous-open 643 and other transitions in the TCP state machine are by-design and 644 necessary for TCP to work correctly in all scenarios. Further, 645 this requirement only affects connections already in progress as 646 authorized by the NAT in accordance with its policy. 647 Security considerations for REQ-3: The security provided by the NAT 648 is governed by its filtering behavior as addressed in 649 [BEHAVE-UDP]. Connection dependent filtering behavior is most 650 secure from a firewall perspective, but severely restricts 651 connection initiations through a NAT. Endpoint independent 652 filtering behavior, which is most transparent to applications, 653 requires an attacker to guess the IP address and port of an active 654 mapping in order to get his packet to an internal host. Address 655 dependent filtering, on the other hand, is less transparent than 656 endpoint independent filtering but more transparent than 657 connection dependent filtering; it is more secure than endpoint 658 independent filtering as it requires an attacker to additionally 659 guess the address of the external endpoint for a NAT session 660 associated with the mapping and be able to receive packets 661 addressed to the same. While this protects against most attackers 662 on the Internet, it does not necessarily protect against attacks 663 that originate from behind a remote NAT with a single IP address 664 that is also translating a legitimate connection to the victim. 665 Security considerations for REQ-4: This document recommends a NAT to 666 respond to unsolicited inbound SYN packets with an ICMP error 667 delayed by a few seconds. Doing so may reveal the presence of a 668 NAT to an external attacker. Silently dropping the SYN makes it 669 harder to diagnose network problems and forces applications to 670 wait for the TCP stack to finish several retransmissions before 671 reporting an error. An implementer must therefore understand and 672 carefully weigh the effects of not sending an ICMP error or rate- 673 limiting such ICMP errors to a very small number. 674 Security considerations for REQ-5: This document recommends that a 675 NAT that passively monitors TCP state keep idle sessions alive for 676 at least 2 hours 4 minutes or 4 minutes depending on the state of 677 the connection. If a NAT is under attack, it may attempt to 678 actively determine the liveness of a TCP connection or let the NAT 679 administrator may configure more conservative timeouts. 680 Security considerations for REQ-6: This requirement does not 681 introduce any TCP-specific security concerns. 682 Security considerations for REQ-7: This requirement does not 683 introduce any TCP-specific security concerns. 685 Security considerations for REQ-8: This requirement does not 686 introduce any TCP-specific security concerns. 687 Security considerations for REQ-9: This requirement does not 688 introduce any TCP-specific security concerns. 690 NAT implementations that modify local state based on TCP flags in 691 packets must ensure that out-of-window TCP packets are properly 692 handled. [TCP-ANTISPOOF] summarizes and discusses a variety of 693 solutions designed to prevent attackers from affecting TCP 694 connections. 696 10. IANA considerations 698 This document does not change or create any IANA-registered values. 700 11. Acknowledgments 702 The editor would like to acknowledge Joe Touch's contributions 703 towards handling unsolicited inbound SYNs. Thanks to Mark Allman, 704 Francois Audet, Paul Francis, Fernando Gont, Paul Hoffman, Dave 705 Hudson, Cullen Jennings, Philip Matthews, Tom Petch, and Dan Wing for 706 their many contributions. 708 12. References 710 12.1. Normative References 712 [BEHAVE-ICMP] 713 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 714 Behavioral Requirements for ICMP protocol", 715 draft-ietf-behave-nat-icmp (work in progress). 717 [BEHAVE-UDP] 718 Audet, F. and C. Jennings, "NAT Behavioral Requirements 719 for Unicast UDP", draft-ietf-behave-nat-udp (work in 720 progress). 722 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 723 RFC 793, September 1981. 725 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 726 STD 9, RFC 959, October 1985. 728 [RFC1122] Braden, R., "Requirements for Internet Hosts - 729 Communication Layers", STD 3, RFC 1122, October 1989. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 12.2. Informational References 736 [NATBLASTER] 737 Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig, 738 "NATBLASTER: Establishing TCP connections between hosts 739 behind NATs", Proceedings of the ACM SIGCOMM Asia 740 Workshop (Beijing, China), April 2005. 742 [P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer 743 communication across network address translators", 744 Proceedings of the USENIX Annual Technical 745 Conference (Anaheim, CA), April 2005. 747 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 748 RFC 1337, May 1992. 750 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 751 Functional Specification", RFC 1644, July 1994. 753 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 754 Translator (NAT) Terminology and Considerations", 755 RFC 2663, August 1999. 757 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 758 Address Translator (Traditional NAT)", RFC 3022, 759 January 2001. 761 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 762 for Transmission Control Protocol (TCP) Specification 763 Documents", RFC 4614, September 2006. 765 [STUNT] Guha, S. and P. Francis, "NUTSS: A SIP based approach to 766 UDP and TCP connectivity", Proceedings of the ACM SIGCOMM 767 Workshop on Future Directions in Network 768 Architecture (Portland, OR), August 2004. 770 [TCP-ANTISPOOF] 771 Touch, J., "Defending TCP Against Spoofing Attacks", 772 draft-ietf-tcpm-tcp-antispoof (work in progress). 774 [TCPTRAV] Guha, S. and P. Francis, "Characterization and Measurement 775 of TCP Traversal through NATs and Firewalls", Proceedings 776 of the Internet Measurement Conference (Berkeley, CA), 777 October 2005. 779 Authors' Addresses 781 Saikat Guha (editor) 782 Cornell University 783 331 Upson Hall 784 Ithaca, NY 14853 785 US 787 Phone: +1 607 255 1008 788 Email: saikat@cs.cornell.edu 790 Kaushik Biswas 791 Cisco Systems, Inc. 792 170 West Tasman Dr. 793 San Jose, CA 95134 794 US 796 Phone: +1 408 525 5134 797 Email: kbiswas@cisco.com 799 Bryan Ford 800 M.I.T. 801 Laboratory for Computer Science 802 77 Massachusetts Ave. 803 Cambridge, MA 02139 804 US 806 Phone: +1 617 253 5261 807 Email: baford@mit.edu 809 Senthil Sivakumar 810 Cisco Systems, Inc. 811 7100-8 Kit Creek Road 812 PO Box 14987 813 Research Triangle Park, NC 27709-4987 814 US 816 Phone: +1 919 392 5158 817 Email: ssenthil@cisco.com 818 Pyda Srisuresh 819 Consultant 820 20072 Pacifica Dr. 821 Cupertino, CA 95014 822 US 824 Phone: +1 408 836 4773 825 Email: srisuresh@yahoo.com 827 Full Copyright Statement 829 Copyright (C) The IETF Trust (2007). 831 This document is subject to the rights, licenses and restrictions 832 contained in BCP 78, and except as set forth therein, the authors 833 retain all their rights. 835 This document and the information contained herein are provided on an 836 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 837 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 838 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 839 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 840 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 841 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 843 Intellectual Property 845 The IETF takes no position regarding the validity or scope of any 846 Intellectual Property Rights or other rights that might be claimed to 847 pertain to the implementation or use of the technology described in 848 this document or the extent to which any license under such rights 849 might or might not be available; nor does it represent that it has 850 made any independent effort to identify any such rights. Information 851 on the procedures with respect to rights in RFC documents can be 852 found in BCP 78 and BCP 79. 854 Copies of IPR disclosures made to the IETF Secretariat and any 855 assurances of licenses to be made available, or the result of an 856 attempt made to obtain a general license or permission for the use of 857 such proprietary rights by implementers or users of this 858 specification can be obtained from the IETF on-line IPR repository at 859 http://www.ietf.org/ipr. 861 The IETF invites any interested party to bring to its attention any 862 copyrights, patents or patent applications, or other proprietary 863 rights that may cover technology that may be required to implement 864 this standard. Please address the information to the IETF at 865 ietf-ipr@ietf.org. 867 Acknowledgment 869 Funding for the RFC Editor function is provided by the IETF 870 Administrative Support Activity (IASA).