idnits 2.17.1 draft-ietf-behave-tcp-07.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 902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 926. 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 (April 28, 2007) is 6206 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: October 30, 2007 B. Ford 7 M.I.T. 8 S. Sivakumar 9 Cisco Systems 10 P. Srisuresh 11 Consultant 12 April 28, 2007 14 NAT Behavioral Requirements for TCP 15 draft-ietf-behave-tcp-07.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 October 30, 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 . . . . . . . . . . . . 5 61 4.2. Internally Initiated Connections . . . . . . . . . . . . . 5 62 4.3. Externally Initiated Connections . . . . . . . . . . . . . 7 63 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 10 64 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 12 65 7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12 66 7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12 67 7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 13 68 7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13 69 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9. Security considerations . . . . . . . . . . . . . . . . . . . 15 71 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 75 12.2. Informational References . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . . . 21 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. Finally, TCP connections intended 98 for the NAT (e.g. an HTTP or SSH management interface) and TCP 99 connections initiated by the NAT (e.g. reliable syslog client) are 100 out-of-scope. 102 2. Introduction 104 Network Address Translators (NATs) hinder connectivity in 105 applications where sessions may be initiated to internal hosts. 106 Readers may refer to [RFC3022] for detailed information on 107 traditional NATs. [BEHAVE-UDP] lays out the terminology and 108 requirements for NATs in the context of IP and UDP. This document 109 supplements these by setting requirements for NATs that handle TCP 110 traffic. All definitions and requirements in [BEHAVE-UDP] are 111 inherited here. 113 [RFC4614] chronicles the evolution of TCP from the original 114 definition [RFC0793] to present day implementations. While much has 115 changed in TCP with regards to congestion control and flow control, 116 security, and support for high-bandwidth networks, the process of 117 initiating a connection (i.e. the 3-way handshake or simultaneous- 118 open) has changed little. It is the process of connection initiation 119 that NATs affect the most. Experimental approaches such as T/TCP 120 [RFC1644] have proposed alternate connection initiation approaches, 121 but, have been found to be complex and susceptible to denial-of- 122 service attacks. Modern operating systems and NATs consequently 123 primarily support the 3-way handshake and simultaneous-open modes of 124 connection initiation as described in [RFC0793]. 126 Recently, many techniques have been devised to make peer-to-peer TCP 127 applications work across NATs. [STUNT], [NATBLASTER], and [P2PNAT] 128 describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow 129 peer-to-peer applications to establish TCP through NATs. These 130 approaches require only endpoint applications to be modified and work 131 with standards compliant OS stacks. The approaches, however, depend 132 on specific NAT behavior that is usually, but not always, supported 133 by NATs (see [TCPTRAV] and [P2PNAT] for details). Consequently a 134 complete TCP NAT traversal solution is sometimes forced to rely on 135 public TCP relays to traverse NATs that do not cooperate. This 136 document defines requirements that ensure that TCP NAT traversal 137 approaches are not forced to use data relays. 139 3. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 This document uses the term "NAT session" as defined in [RFC2663]. 146 "NAT" in this specification includes both "Basic NAT" and "Network 147 Address/Port Translator (NAPT)" [RFC2663]. 149 This document uses the term "TCP connection" (or just "connection") 150 to refer to individual TCP flows identified by the 4-tuple (source 151 and destination IP address and TCP port) and the initial sequence 152 numbers (ISN). 154 This document uses the term "address and port mapping" (or just 155 "mapping") as defined in [BEHAVE-UDP] to refer to state at the NAT 156 necessary for network address and port translation of TCP 157 connections. This document also uses the terms "endpoint independent 158 mapping", "address dependent mapping", "address and port dependent 159 mapping", "filtering behavior", "endpoint independent filtering", 160 "address dependent filtering", "address and port dependent 161 filtering", "port assignment", "port overloading", "hairpinning", and 162 "external source IP address and port" as defined in [BEHAVE-UDP]. 164 4. TCP Connection Initiation 166 This section describes various NAT behaviors applicable to TCP 167 connection initiation. 169 4.1. Address and Port Mapping Behavior 171 A NAT uses a mapping to translate packets for each TCP connection. A 172 mapping is dynamically allocated for connections initiated from the 173 internal side, and potentially reused for certain subsequent 174 connections. NAT behavior regarding when a mapping can be reused 175 differs for different NATs as described in [BEHAVE-UDP]. 177 Consider an internal IP address and TCP port (X:x) that initiates a 178 TCP connection to an external (Y1:y1) tuple. Let the mapping 179 allocated by the NAT for this connection be (X1':x1'). Shortly 180 thereafter, the endpoint initiates a connection from the same (X:x) 181 to an external address (Y2:y2) and gets the mapping (X2':x2') on the 182 NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all 183 values of (Y2:y2) then the NAT is defined to have "Endpoint 184 Independent Mapping" behavior. If (X1':x1') equals (X2':x2') only 185 when Y2 equals Y1 then the NAT is defined to have "Address Dependent 186 Mapping" behavior. If (X1':x1') equals (X2':x2') only when (Y2:y2) 187 equals (Y1:y1), possible only for consecutive connections to the same 188 external address shortly after the first is terminated and if the NAT 189 retains state for connections in TIME_WAIT state, then the NAT is 190 defined to have "Address and Port Dependent Mapping" behavior. This 191 document introduces one additional behavior where (X1':x1') never 192 equals (X2':x2'), that is, for each connection a new mapping is 193 allocated; in such a case, the NAT is defined to have "Connection 194 Dependent Mapping" behavior. 196 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior 197 for TCP. 199 Justification: REQ-1 is necessary for UNSAF methods to work. 200 Endpoint independent mapping behavior allows peer-to-peer 201 applications to learn and advertise the external IP address and 202 port allocated to an internal endpoint such that external peers 203 can contact it (subject to the NAT's security policy). The 204 security policy of a NAT is independent of its mapping behavior 205 and is discussed later in Section 4.3. Having endpoint 206 independent mapping behavior allows peer-to-peer applications to 207 work consistently without compromising the security benefits of 208 the NAT. 210 4.2. Internally Initiated Connections 212 An internal endpoint initiates a TCP connection through a NAT by 213 sending a SYN packet. The NAT allocates (or reuses) a mapping for 214 the connection, as described in the previous section. The mapping 215 defines the external IP address and port used for translation of all 216 packets for that connection. In particular, for client-server 217 applications where an internal client initiates the connection to an 218 external server, the mapping is used to translate the outbound SYN, 219 the resulting inbound SYN-ACK response, the subsequent outbound ACK, 220 and other packets for the connection. This method of connection 221 initiation corresponds to the 3-way handshake (defined in [RFC0793]) 222 and is supported by all NATs. 224 Peer-to-peer applications use an alternate method of connection 225 initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse 226 NATs. In the Simultaneous-Open mode of operation, both peers send 227 SYN packets for the same TCP connection. The SYN packets cross in 228 the network. Upon receiving the other end's SYN packet each end 229 responds with a SYN-ACK packet, which also cross in the network. The 230 connection is considered established once the SYN-ACKs are received. 231 From the perspective of the NAT, the internal host's SYN packet is 232 met by an inbound SYN packet for the same connection (as opposed to a 233 SYN-ACK packet during a 3-way handshake). Subsequent to this 234 exchange, both an outbound and an inbound SYN-ACK are seen for the 235 connection. Some NATs erroneously block the inbound SYN for the 236 connection in progress. Some NATs block or incorrectly translate the 237 outbound SYN-ACK. Such behavior breaks TCP simultaneous-open and 238 prevents peer-to-peer applications from functioning correctly behind 239 a NAT. 241 In order to provide network address translation service for TCP, it 242 is necessary for a NAT to correctly receive, translate, and forward 243 all packets for a connection that conform to valid transitions of the 244 TCP State-Machine (Fig. 6, [RFC0793]). 246 REQ-2: A NAT MUST support all valid sequences of TCP packets 247 (defined in [RFC0793]) for connections initiated both internally 248 as well as externally when the connection is permitted by the NAT. 249 In particular: 250 a) In addition to handling the TCP 3-way handshake mode of 251 connection initiation, A NAT MUST handle the TCP simultaneous- 252 open mode of connection initiation. 254 Justification: The intent of this requirement is to allow standards 255 compliant TCP stacks to traverse NATs no matter what path the 256 stacks take through the TCP state-machine and no matter which end 257 initiates the connection as long as the connection is permitted by 258 the filtering policy of the NAT (filtering policy is described in 259 the following section). 260 a) In addition to TCP packets for a 3-Way Handshake, A NAT must be 261 prepared to accept an inbound SYN and an outbound SYN-ACK for 262 an internally initiated connection in order to support 263 Simultaneous-Open. 265 4.3. Externally Initiated Connections 267 The NAT allocates a mapping for the first connection initiated by an 268 internal endpoint to an external endpoint. In some scenarios, the 269 NAT's policy may allow this mapping to be reused for connections 270 initiated from the external side to the internal endpoint. Consider 271 as before an internal IP address and port (X:x) that is assigned (or 272 reuses) a mapping (X1':x1') when it initiates a connection to an 273 external (Y1:y1). An external endpoint (Y2:y2) attempts to initiate 274 a connection with the internal endpoint by sending a SYN to 275 (X1':x1'). A NAT can choose to either allow the connection to be 276 established, or to disallow the connection. If the NAT chooses to 277 allow the connection, it translates the inbound SYN and routes it to 278 (X:x) as per the existing mapping. It also translates the SYN-ACK 279 generated by (X:x) in response and routes it to (Y2:y2) and so on. 280 Alternately, the NAT can disallow the connection by filtering the 281 inbound SYN. 283 A NAT may allow an existing mapping to be reused by an externally 284 initiated connection if its security policy permits. Several 285 different policies are possible as described in [BEHAVE-UDP]. If a 286 NAT allows the connection initiation from all (Y2:y2) then it is 287 defined to have "Endpoint Independent Filtering" behavior. If the 288 NAT allows connection initiations only when Y2 equals Y1 then the NAT 289 is defined to have "Address Dependent Filtering" behavior. If the 290 NAT allows connection initiations only when (Y2:y2) equals (Y1:y1), 291 then the NAT is defined to have "Address and Port Dependent 292 Filtering" behavior (possible only shortly after the first connection 293 has been terminated but the mapping is still active). One additional 294 filtering behavior defined in this document is when the NAT does not 295 allow any connection initiations from the external side; in such 296 cases, the NAT is defined to have "Connection Dependent Filtering" 297 behavior. The difference between "Address and Port Dependent 298 Filtering" and "Connection Dependent Filtering" behavior is that the 299 former permits an inbound SYN during the TIME_WAIT state of the first 300 connection to initiate a new connection while the latter does not. 302 REQ-3: If application transparency is most important, it is 303 RECOMMENDED that a NAT have an "Endpoint independent filtering" 304 behavior for TCP. If a more stringent filtering behavior is most 305 important, it is RECOMMENDED that a NAT have an "Address dependent 306 filtering" behavior. 307 a) The filtering behavior MAY be an option configurable by the 308 administrator of the NAT. 310 b) The filtering behavior for TCP MAY be independent of the 311 filtering behavior for UDP. 313 Justification: The intent of this requirement is to allow peer-to- 314 peer applications that do not always initiate connections from the 315 internal side of the NAT to continue to work in the presence of 316 NATs. This behavior also allows applications behind a BEHAVE 317 compliant NAT to inter-operate with remote endpoints that are 318 behind non-BEHAVE compliant (legacy) NATs. If the remote 319 endpoint's NAT does not have endpoint independent mapping behavior 320 but has only one external IP address, then an application can 321 still traverse the combination of the two NATs if the local NAT 322 has address dependent filtering. Section 9 contains a detailed 323 discussion on the security implications of this requirement. 325 If the inbound SYN packet is filtered, either because a corresponding 326 mapping does not exist or because of the NAT's filtering behavior, a 327 NAT has two basic choices: to ignore the packet silently, or to 328 signal an error to the sender. Signaling an error through ICMP 329 messages allows the sender to quickly detect that the SYN did not 330 reach the intended destination. Silently dropping the packet, on the 331 other hand, allows applications to perform Simultaneous-Open more 332 reliably. 334 Silently dropping the SYN aids Simultaneous-Open as follows. 335 Consider that the application is attempting a Simultaneous-Open and 336 the outbound SYN from the internal endpoint has not yet crossed the 337 NAT (due to network congestion or clock skew between the two 338 endpoints); this outbound SYN would otherwise have created the 339 necessary mapping at the NAT to allow translation of the inbound SYN. 340 Since the outbound SYN did not reach the NAT in time, the inbound SYN 341 cannot be processed. If a NAT responds to the premature inbound SYN 342 with an error message that forces the external endpoint to abandon 343 the connection attempt, it hinders applications performing a TCP 344 simultaneous-open. If instead the NAT silently ignores the inbound 345 SYN, the external endpoint retransmits the SYN after a TCP timeout. 346 In the meantime, the NAT creates the mapping in response to the 347 (delayed) outbound SYN such that the retransmitted inbound SYN can be 348 routed and simultaneous-open can succeed. The down-side to this 349 behavior is that in the event the inbound SYN is erroneous, the 350 remote side does not learn of the error until after several TCP 351 timeouts. 353 NAT support for simultaneous-open as well as quickly signaling errors 354 are both important for applications. Unfortunately, there is no way 355 for a NAT to signal an error without forcing the endpoint to abort a 356 potential simultaneous-open: TCP RST and ICMP Port Unreachable 357 packets require the endpoint to abort the attempt while ICMP Host and 358 Network Unreachable errors may adversely affect other connections to 359 the same host or network [RFC1122]. 361 In addition, when an unsolicited SYN is received by the NAT, the NAT 362 may not know whether the application is attempting a simultaneous- 363 open (and that it should therefore silently drop the SYN) or whether 364 the SYN is in error (and that it should notify the sender). 366 REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet 367 for at least 6 seconds after the packet is received. If during 368 this interval the NAT receives and translates an outbound SYN for 369 the connection the NAT MUST silently drop the original unsolicited 370 inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port 371 Unreachable error (Type 3, Code 3) for the original SYN, unless 372 REQ-4a applies. 373 a) The NAT MUST silently drop the original SYN packet if sending a 374 response violates the security policy of the NAT. 376 Justification: The intent of this requirement is to allow 377 simultaneous-open to work reliably in the presence of NATs as well 378 as to quickly signal an error in case the unsolicited SYN is in 379 error. As of writing this memo, it is not possible to achieve 380 both; the requirement therefore represents a compromise. The NAT 381 should tolerate some delay in the outbound SYN for a TCP 382 simultaneous-open, which may be due to network congestion or loose 383 synchronization between the endpoints. If the unsolicited SYN is 384 not part of a simultaneous-open attempt and is in error, the NAT 385 should endeavor to signal the error in accordance with [RFC1122]. 386 a) There may, however, be reasons for the NAT to rate-limit or 387 omit such error notifications, for example in the case of an 388 attack. Silently dropping the SYN packet when under attack 389 allows simultaneous-open to work without consuming any extra 390 network bandwidth or revealing the presence of the NAT to 391 attackers. Section 9 mentions the security considerations for 392 this requirement. 394 For NATs that combine NAT functionality with end-host functionality 395 (e.g. an end-host that also serves as a NAT for other hosts behind 396 it), REQ-4 above applies only to SYNs intended for the NAT'ed hosts 397 and not to SYNs intended for the NAT itself. One way to determine 398 whether the inbound SYN is intended for a NAT'ed host is to allocate 399 NAT mappings from one port range, and allocate ports for local 400 endpoints from a different non-overlapping port range. More dynamic 401 implementations can be imagined. 403 5. NAT Session Refresh 405 A NAT maintains state associated with in-progress and established 406 connections. Because of this, a NAT is susceptible to a resource- 407 exhaustion attack whereby an attacker (or virus) on the internal side 408 attempts to cause the NAT to create more state than it has resources 409 for. To prevent such an attack, a NAT needs to abandon sessions in 410 order to free the state resources. 412 A common method that is applicable only to TCP is to preferentially 413 abandon sessions for crashed endpoints, followed by closed TCP 414 connections and partially-open connections. A NAT can check if an 415 endpoint for a session has crashed by sending a TCP keep-alive packet 416 and receiving a TCP RST packet in response. If the NAT cannot 417 determine whether the endpoint is active, it should not abandon the 418 session until the TCP connection has been idle for some time. Note 419 that an established TCP connection can stay idle (but live) 420 indefinitely; hence there is no fixed value for an idle-timeout that 421 accommodates all applications. However, a large idle-timeout 422 motivated by recommendations in [RFC1122] can reduce the chances of 423 abandoning a live session. 425 A TCP connection passes through three phases: partially-open, 426 established, and closing. During the partially-open phase, endpoints 427 synchronize initial sequence numbers. The phase is initiated by the 428 first SYN for the connection and extends until both endpoints have 429 sent a packet with the ACK flag set (TCP states: SYN_SENT and 430 SYN_RCVD). ACKs in both directions mark the beginning of the 431 established phase where application data can be exchanged 432 indefinitely (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and 433 CLOSE_WAIT). The closing phase begins when both endpoint have 434 terminated their half of the connection by sending a FIN packet. 435 Once FIN packets are seen in both directions, application data can no 436 longer be exchanged but the stacks still need to ensure that the FIN 437 packets are received (TCP states: CLOSING and LAST_ACK). 439 TCP connections can stay in established phase indefinitely without 440 exchanging any packets. Some end-hosts can be configured to send 441 keep-alive packets on such idle connections; by default, such keep- 442 alive packets are sent every 2 hours if enabled [RFC1122]. 443 Consequently, a NAT that waits for slightly over 2 hours can detect 444 idle connections with keep-alive packets being sent at the default 445 rate. TCP connections in the partially-open or closing phases, on 446 the other hand, can stay idle for at most 4 minutes while waiting for 447 in-flight packets to be delivered [RFC1122]. 449 The "established connection idle-timeout" for a NAT is defined as the 450 minimum time a TCP connection in the established phase must remain 451 idle before the NAT considers the associated session a candidate for 452 removal. The "transitory connection idle-timeout" for a NAT is 453 defined as the minimum time a TCP connection in the partially-open or 454 closing phases must remain idle before the NAT considers the 455 associated session a candidate for removal. TCP connections in the 456 TIME_WAIT state are not affected by the "transitory connection idle- 457 timeout". 459 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 460 connection are active, it MAY abandon the session if it has been 461 idle for some time. In such cases, the value of the "established 462 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 463 The value of the "transitory connection idle-timeout" MUST NOT be 464 less than 4 minutes. 465 a) The value of the NAT idle-timeouts MAY be configurable. 467 Justification: The intent of this requirement is to minimize the 468 cases where a NAT abandons session state for a live connection. 469 While some NATs may choose to abandon sessions reactively in 470 response to new connection initiations (allowing idle connections 471 to stay up indefinitely in the absence of new initiations), other 472 NATs may choose to proactively reap idle sessions. In cases where 473 the NAT cannot actively determine if the connection is alive, this 474 requirement ensures that applications can send keep-alive packets 475 at the default rate (every 2 hours) such that the NAT can 476 passively determine that the connection is alive. The additional 477 4 minutes allows time for in-flight packets to cross the NAT. 479 NAT behavior for handling RST packets, or connections in TIME_WAIT 480 state is left unspecified. A NAT MAY hold state for a connection in 481 TIME_WAIT state to accommodate retransmissions of the last ACK. 482 However, since the TIME_WAIT state is commonly encountered by 483 internal endpoints properly closing the TCP connection, holding state 484 for a closed connection may limit the throughput of connections 485 through a NAT with limited resources. [RFC1337] describes hazards 486 associated with TIME_WAIT assassination. 488 The handling of non-SYN packets for connections for which there is no 489 active mapping is left unspecified. Such packets may be received if 490 the NAT silently abandons a live connection, or abandons a connection 491 in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The 492 decision to either silently drop such packets or to respond with a 493 TCP RST packet is left up to the implementation. 495 NAT behavior for notifying endpoints when abandoning live connections 496 is left unspecified. When a NAT abandons a live connection, for 497 example due to a timeout expiring, the NAT MAY either send TCP RST 498 packets to the endpoints or MAY silently abandon the connection. 500 Sending a RST notification allows endpoint applications to recover 501 more quickly, however, notifying the endpoints may not always be 502 possible if, for example, session state it lost due to a power 503 failure. 505 6. Application Level Gateways 507 Application Level Gateways (ALGs) in certain NATs modify IP addresses 508 and TCP ports embedded inside application protocols. Such ALGs may 509 interfere with UNSAF methods or protocols that try to be NAT-aware 510 and must therefore be used with extreme caution. 512 REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED 513 that all of those ALGs (except for FTP [RFC0959]) be disabled by 514 default. 516 Justification: The intent of this requirement is to prevents ALGs 517 from interfering with UNSAF methods. The default state of a FTP 518 ALG is left unspecified because of legacy concerns: as of writing 519 this memo, a large fraction of legacy FTP clients do not enable 520 passive (PASV) mode by default and require an ALG to traverse 521 NATs. 523 7. Other Requirements Applicable to TCP 525 A list of general and UDP specific NAT behavioral requirements are 526 described in [BEHAVE-UDP]. A list of ICMP specific NAT behavioral 527 requirements are described in [BEHAVE-ICMP]. The requirements listed 528 below reiterate the requirements from these two documents that 529 directly affect TCP. The following requirements do not relax any 530 requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. 532 7.1. Port Assignment 534 NATs that allow different internal endpoints to simultaneously use 535 the same mapping are defined in [BEHAVE-UDP] to have a "Port 536 assignment" behavior of "Port overloading". Such behavior is 537 undesirable as it prevents two internal endpoints sharing the same 538 mapping from establishing simultaneous connections to a common 539 external endpoint. 541 REQ-7 A NAT MUST NOT have a "Port assignment" behavior of "Port 542 overloading" for TCP. 544 Justification: This requirement allows two applications on the 545 internal side of the NAT to consistently communicate with the same 546 destination. 548 NAT behavior for preserving the source TCP port range for connections 549 is left unspecified. Some applications expect the source TCP port to 550 be in the well-known range (TCP ports from 0 to 1023). The "r" 551 series of commands (rsh, rcp, rlogin, etc.) are an example. NATs 552 that preserve the range from which the source port is picked allow 553 such applications to function properly through the NAT, however, by 554 doing so the NAT may compromise the security of the application in 555 certain situations; applications that depend only on the IP address 556 and source TCP port range for security (the "r" commands for example) 557 cannot distinguish between an attacker and a legitimate user behind 558 the same NAT. 560 7.2. Hairpinning Behavior 562 NATs that forward packets originating from an internal address, 563 destined for an external address that matches the active mapping for 564 an internal address, back to that internal address are defined in 565 [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the 566 hairpinned packet with an external source IP address and port (i.e. 567 the mapped source address and port of the originating internal 568 endpoint), then it is defined to have "External source IP address and 569 port" for hairpinning. Hairpinning is necessary to allow two 570 internal endpoints (known to each other only by their external mapped 571 addresses) to communicate with each other. "External source IP 572 address and port" behavior for hairpinning avoids confusing 573 implementations that expect the external source address and port. 575 REQ-8: A NAT MUST support "Hairpinning" for TCP. 576 a) A NAT's Hairpinning behavior MUST be of type "External source 577 IP address and port". 579 Justification: This requirement allows two applications behind the 580 same NAT that are trying to communicate with each other using 581 their external addresses. 582 a) Using the external source address and port for the hairpinned 583 packet is necessary for applications that do not expect to 584 receive a packet from a different address than the external 585 address they are trying to communicate with. 587 7.3. ICMP Responses to TCP Packets 589 Several TCP mechanisms depend on the reception of ICMP error messages 590 triggered by the transmission of TCP segments. One such mechanism is 591 path MTU discovery [RFC1191], which is required for the correct 592 operation of TCP. The current path MTU discovery mechanism requires 593 the sender of TCP segments to be notified of ICMP "Datagram Too Big" 594 responses. 596 REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination 597 Unreachable (Type 3) messages. 599 Justification: Translating ICMP Destination Unreachable messages, 600 particularly the "Fragmentation Needed and Don't Fragment was Set" 601 (Type 3, Code 4) message avoids communication failures ("black 602 holes" [RFC2923]). Furthermore, TCP's connection establishment 603 and maintenance mechanisms also behave much more efficiently when 604 ICMP Destination Unreachable messages arrive in response to 605 outgoing TCP segments. 607 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 608 NAT mapping or TCP connection for which the ICMP was generated. 610 Justification: This is necessary for reliably performing TCP 611 simultaneous-open where a remote NAT may temporarily signal an 612 ICMP error. 614 8. Requirements 616 A NAT that supports all of the mandatory requirements of this 617 specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], 618 is "compliant with this specification". A NAT that supports all of 619 the requirements of this specification (i.e., included the 620 "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully 621 compliant with all the mandatory and recommended requirements of this 622 specification". 624 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior 625 for TCP. 626 REQ-2: A NAT MUST support all valid sequences of TCP packets 627 (defined in [RFC0793]) for connections initiated both internally 628 as well as externally when the connection is permitted by the NAT. 629 In particular: 630 a) In addition to handling the TCP 3-way handshake mode of 631 connection initiation, A NAT MUST handle the TCP simultaneous- 632 open mode of connection initiation. 633 REQ-3: If application transparency is most important, it is 634 RECOMMENDED that a NAT have an "Endpoint independent filtering" 635 behavior for TCP. If a more stringent filtering behavior is most 636 important, it is RECOMMENDED that a NAT have an "Address dependent 637 filtering" behavior. 639 a) The filtering behavior MAY be an option configurable by the 640 administrator of the NAT. 641 b) The filtering behavior for TCP MAY be independent of the 642 filtering behavior for UDP. 643 REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet 644 for at least 6 seconds after the packet is received. If during 645 this interval the NAT receives and translates an outbound SYN for 646 the connection the NAT MUST silently drop the original unsolicited 647 inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port 648 Unreachable error (Type 3, Code 3) for the original SYN, unless 649 REQ-4a applies. 650 a) The NAT MUST silently drop the original SYN packet if sending a 651 response violates the security policy of the NAT. 652 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 653 connection are active, it MAY abandon the session if it has been 654 idle for some time. In such cases, the value of the "established 655 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 656 The value of the "transitory connection idle-timeout" MUST NOT be 657 less than 4 minutes. 658 a) The value of the NAT idle-timeouts MAY be configurable. 659 REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED 660 that all of those ALGs (except for FTP [RFC0959]) be disabled by 661 default. 662 REQ-7 A NAT MUST NOT have a "Port assignment" behavior of "Port 663 overloading" for TCP. 664 REQ-8: A NAT MUST support "Hairpinning" for TCP. 665 a) A NAT's Hairpinning behavior MUST be of type "External source 666 IP address and port". 667 REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination 668 Unreachable (Type 3) messages. 669 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 670 NAT mapping or TCP connection for which the ICMP was generated. 672 9. Security considerations 674 Security concerns specific to handling TCP packets are discussed in 675 this section. 677 Security considerations for REQ-1: This requirement does not 678 introduce any TCP-specific security concerns. 680 Security considerations for REQ-2: This requirement does not 681 introduce any TCP-specific security concerns. Simultaneous-open 682 and other transitions in the TCP state machine are by-design and 683 necessary for TCP to work correctly in all scenarios. Further, 684 this requirement only affects connections already in progress as 685 authorized by the NAT in accordance with its policy. 687 Security considerations for REQ-3: The security provided by the NAT 688 is governed by its filtering behavior as addressed in 689 [BEHAVE-UDP]. Connection dependent filtering behavior is most 690 secure from a firewall perspective, but severely restricts 691 connection initiations through a NAT. Endpoint independent 692 filtering behavior, which is most transparent to applications, 693 requires an attacker to guess the IP address and port of an active 694 mapping in order to get his packet to an internal host. Address 695 dependent filtering, on the other hand, is less transparent than 696 endpoint independent filtering but more transparent than 697 connection dependent filtering; it is more secure than endpoint 698 independent filtering as it requires an attacker to additionally 699 guess the address of the external endpoint for a NAT session 700 associated with the mapping and be able to receive packets 701 addressed to the same. While this protects against most attackers 702 on the Internet, it does not necessarily protect against attacks 703 that originate from behind a remote NAT with a single IP address 704 that is also translating a legitimate connection to the victim. 706 Security considerations for REQ-4: This document recommends a NAT to 707 respond to unsolicited inbound SYN packets with an ICMP error 708 delayed by a few seconds. Doing so may reveal the presence of a 709 NAT to an external attacker. Silently dropping the SYN makes it 710 harder to diagnose network problems and forces applications to 711 wait for the TCP stack to finish several retransmissions before 712 reporting an error. An implementer must therefore understand and 713 carefully weigh the effects of not sending an ICMP error or rate- 714 limiting such ICMP errors to a very small number. 716 Security considerations for REQ-5: This document recommends that a 717 NAT that passively monitors TCP state keep idle sessions alive for 718 at least 2 hours 4 minutes or 4 minutes depending on the state of 719 the connection. If a NAT is under attack, it may attempt to 720 actively determine the liveliness of a TCP connection or let the 721 NAT administrator configure more conservative timeouts. 723 Security considerations for REQ-6: This requirement does not 724 introduce any TCP-specific security concerns. 726 Security considerations for REQ-7: This requirement does not 727 introduce any TCP-specific security concerns. 729 Security considerations for REQ-8: This requirement does not 730 introduce any TCP-specific security concerns. 732 Security considerations for REQ-9: This requirement does not 733 introduce any TCP-specific security concerns. 735 Security considerations for REQ-10: This requirement does not 736 introduce any TCP-specific security concerns. 738 NAT implementations that modify TCP sequence numbers (e.g., for 739 privacy reasons or for ALG support) must ensure that TCP packets with 740 SACK notifications [RFC2018] are properly handled. 742 NAT implementations that modify local state based on TCP flags in 743 packets must ensure that out-of-window TCP packets are properly 744 handled. [TCP-ANTISPOOF] summarizes and discusses a variety of 745 solutions designed to prevent attackers from affecting TCP 746 connections. 748 10. IANA considerations 750 This document does not change or create any IANA-registered values. 752 11. Acknowledgments 754 Joe Touch contributed the mechanism for handling unsolicited inbound 755 SYNs. Thanks to Mark Allman, Francois Audet, Lars Eggert, Paul 756 Francis, Fernando Gont, Sam Hartman, Paul Hoffman, Dave Hudson, 757 Cullen Jennings, Philip Matthews, Tom Petch, Magnus Westerlund, and 758 Dan Wing for their many contributions, comments and suggestions. 760 12. References 762 12.1. Normative References 764 [BEHAVE-ICMP] 765 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 766 Behavioral Requirements for ICMP protocol", 767 draft-ietf-behave-nat-icmp (work in progress). 769 [BEHAVE-UDP] 770 Audet, F. and C. Jennings, "Network Address Translation 771 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 772 RFC 4787, January 2007. 774 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 775 RFC 793, September 1981. 777 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 778 STD 9, RFC 959, October 1985. 780 [RFC1122] Braden, R., "Requirements for Internet Hosts - 781 Communication Layers", STD 3, RFC 1122, October 1989. 783 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 784 November 1990. 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, March 1997. 789 12.2. Informational References 791 [NATBLASTER] 792 Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig, 793 "NATBLASTER: Establishing TCP connections between hosts 794 behind NATs", Proceedings of the ACM SIGCOMM Asia 795 Workshop (Beijing, China), April 2005. 797 [P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer 798 communication across network address translators", 799 Proceedings of the USENIX Annual Technical 800 Conference (Anaheim, CA), April 2005. 802 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 803 RFC 1337, May 1992. 805 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 806 Functional Specification", RFC 1644, July 1994. 808 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 809 Selective Acknowledgment Options", RFC 2018, October 1996. 811 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 812 Translator (NAT) Terminology and Considerations", 813 RFC 2663, August 1999. 815 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 816 RFC 2923, September 2000. 818 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 819 Address Translator (Traditional NAT)", RFC 3022, 820 January 2001. 822 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 823 for Transmission Control Protocol (TCP) Specification 824 Documents", RFC 4614, September 2006. 826 [STUNT] Guha, S. and P. Francis, "NUTSS: A SIP based approach to 827 UDP and TCP connectivity", Proceedings of the ACM SIGCOMM 828 Workshop on Future Directions in Network 829 Architecture (Portland, OR), August 2004. 831 [TCP-ANTISPOOF] 832 Touch, J., "Defending TCP Against Spoofing Attacks", 833 draft-ietf-tcpm-tcp-antispoof (work in progress). 835 [TCPTRAV] Guha, S. and P. Francis, "Characterization and Measurement 836 of TCP Traversal through NATs and Firewalls", Proceedings 837 of the Internet Measurement Conference (Berkeley, CA), 838 October 2005. 840 Authors' Addresses 842 Saikat Guha (editor) 843 Cornell University 844 331 Upson Hall 845 Ithaca, NY 14853 846 US 848 Phone: +1 607 255 1008 849 Email: saikat@cs.cornell.edu 851 Kaushik Biswas 852 Cisco Systems, Inc. 853 170 West Tasman Dr. 854 San Jose, CA 95134 855 US 857 Phone: +1 408 525 5134 858 Email: kbiswas@cisco.com 860 Bryan Ford 861 M.I.T. 862 Laboratory for Computer Science 863 77 Massachusetts Ave. 864 Cambridge, MA 02139 865 US 867 Phone: +1 617 253 5261 868 Email: baford@mit.edu 869 Senthil Sivakumar 870 Cisco Systems, Inc. 871 7100-8 Kit Creek Road 872 PO Box 14987 873 Research Triangle Park, NC 27709-4987 874 US 876 Phone: +1 919 392 5158 877 Email: ssenthil@cisco.com 879 Pyda Srisuresh 880 Consultant 881 20072 Pacifica Dr. 882 Cupertino, CA 95014 883 US 885 Phone: +1 408 836 4773 886 Email: srisuresh@yahoo.com 888 Full Copyright Statement 890 Copyright (C) The IETF Trust (2007). 892 This document is subject to the rights, licenses and restrictions 893 contained in BCP 78, and except as set forth therein, the authors 894 retain all their rights. 896 This document and the information contained herein are provided on an 897 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 898 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 899 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 900 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 901 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 902 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 904 Intellectual Property 906 The IETF takes no position regarding the validity or scope of any 907 Intellectual Property Rights or other rights that might be claimed to 908 pertain to the implementation or use of the technology described in 909 this document or the extent to which any license under such rights 910 might or might not be available; nor does it represent that it has 911 made any independent effort to identify any such rights. Information 912 on the procedures with respect to rights in RFC documents can be 913 found in BCP 78 and BCP 79. 915 Copies of IPR disclosures made to the IETF Secretariat and any 916 assurances of licenses to be made available, or the result of an 917 attempt made to obtain a general license or permission for the use of 918 such proprietary rights by implementers or users of this 919 specification can be obtained from the IETF on-line IPR repository at 920 http://www.ietf.org/ipr. 922 The IETF invites any interested party to bring to its attention any 923 copyrights, patents or patent applications, or other proprietary 924 rights that may cover technology that may be required to implement 925 this standard. Please address the information to the IETF at 926 ietf-ipr@ietf.org. 928 Acknowledgment 930 Funding for the RFC Editor function is provided by the IETF 931 Administrative Support Activity (IASA).