idnits 2.17.1 draft-ietf-behave-tcp-08.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 (September 6, 2008) is 5709 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: BCP K. Biswas 5 Expires: March 10, 2009 Cisco Systems 6 B. Ford 7 M.I.T. 8 S. Sivakumar 9 Cisco Systems 10 P. Srisuresh 11 Consultant 12 September 6, 2008 14 NAT Behavioral Requirements for TCP 15 draft-ietf-behave-tcp-08.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 March 10, 2009. 42 Abstract 44 This document defines a set of requirements for NATs that handle TCP 45 that would allow many applications, such as peer-to-peer applications 46 and on-line games, to work consistently. Developing NATs that meet 47 this set of requirements will greatly increase the likelihood that 48 these applications will function properly. 50 Table of Contents 52 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. TCP Connection Initiation . . . . . . . . . . . . . . . . . . 4 56 4.1. Address and Port Mapping Behavior . . . . . . . . . . . . 5 57 4.2. Internally Initiated Connections . . . . . . . . . . . . . 5 58 4.3. Externally Initiated Connections . . . . . . . . . . . . . 7 59 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 10 60 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 12 61 7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12 62 7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12 63 7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 13 64 7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13 65 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 9. Security considerations . . . . . . . . . . . . . . . . . . . 15 67 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 71 12.2. Informational References . . . . . . . . . . . . . . . . . 18 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 73 Intellectual Property and Copyright Statements . . . . . . . . . . 21 75 1. Applicability Statement 77 This document is adjunct to [BEHAVE-UDP], which defines many terms 78 relating to NATs, lays out general requirements for all NATs, and 79 sets requirements for NATs that handle IP and unicast UDP traffic. 80 The purpose of this document is to set requirements for NATs that 81 handle TCP traffic. 83 The requirements of this specification apply to Traditional NATs as 84 described in [RFC2663]. 86 This document only covers the TCP aspects of NAT traversal. Middle- 87 box behavior that is not necessary for network address translation of 88 TCP is out-of-scope. Firewalls, and packet inspection above the TCP 89 layer are out-of-scope except for Application Level Gateways (ALG) 90 behavior that may interfere with NAT traversal. Application and OS 91 aspects of TCP NAT traversal are out-of-scope. Signaling based 92 approaches to NAT traversal such as MIDCOM and UPnP that directly 93 control the NAT are out-of-scope. Finally, TCP connections intended 94 for the NAT (e.g. an HTTP or SSH management interface) and TCP 95 connections initiated by the NAT (e.g. reliable syslog client) are 96 out-of-scope. 98 2. Introduction 100 Network Address Translators (NATs) hinder connectivity in 101 applications where sessions may be initiated to internal hosts. 102 Readers may refer to [RFC3022] for detailed information on 103 traditional NATs. [BEHAVE-UDP] lays out the terminology and 104 requirements for NATs in the context of IP and UDP. This document 105 supplements these by setting requirements for NATs that handle TCP 106 traffic. All definitions and requirements in [BEHAVE-UDP] are 107 inherited here. 109 [RFC4614] chronicles the evolution of TCP from the original 110 definition [RFC0793] to present day implementations. While much has 111 changed in TCP with regards to congestion control and flow control, 112 security, and support for high-bandwidth networks, the process of 113 initiating a connection (i.e. the 3-way handshake or simultaneous- 114 open) has changed little. It is the process of connection initiation 115 that NATs affect the most. Experimental approaches such as T/TCP 116 [RFC1644] have proposed alternate connection initiation approaches, 117 but, have been found to be complex and susceptible to denial-of- 118 service attacks. Modern operating systems and NATs consequently 119 primarily support the 3-way handshake and simultaneous-open modes of 120 connection initiation as described in [RFC0793]. 122 Recently, many techniques have been devised to make peer-to-peer TCP 123 applications work across NATs. [STUNT], [NATBLASTER], and [P2PNAT] 124 describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow 125 peer-to-peer applications to establish TCP through NATs. These 126 approaches require only endpoint applications to be modified and work 127 with standards compliant OS stacks. The approaches, however, depend 128 on specific NAT behavior that is usually, but not always, supported 129 by NATs (see [TCPTRAV] and [P2PNAT] for details). Consequently a 130 complete TCP NAT traversal solution is sometimes forced to rely on 131 public TCP relays to traverse NATs that do not cooperate. This 132 document defines requirements that ensure that TCP NAT traversal 133 approaches are not forced to use data relays. 135 3. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 This document uses the term "NAT session" as defined in [RFC2663]. 142 "NAT" in this specification includes both "Basic NAT" and "Network 143 Address/Port Translator (NAPT)" [RFC2663]. 145 This document uses the term "TCP connection" (or just "connection") 146 to refer to individual TCP flows identified by the 4-tuple (source 147 and destination IP address and TCP port) and the initial sequence 148 numbers (ISN). 150 This document uses the term "address and port mapping" (or just 151 "mapping") as defined in [BEHAVE-UDP] to refer to state at the NAT 152 necessary for network address and port translation of TCP 153 connections. This document also uses the terms "endpoint independent 154 mapping", "address dependent mapping", "address and port dependent 155 mapping", "filtering behavior", "endpoint independent filtering", 156 "address dependent filtering", "address and port dependent 157 filtering", "port assignment", "port overloading", "hairpinning", and 158 "external source IP address and port" as defined in [BEHAVE-UDP]. 160 4. TCP Connection Initiation 162 This section describes various NAT behaviors applicable to TCP 163 connection initiation. 165 4.1. Address and Port Mapping Behavior 167 A NAT uses a mapping to translate packets for each TCP connection. A 168 mapping is dynamically allocated for connections initiated from the 169 internal side, and potentially reused for certain subsequent 170 connections. NAT behavior regarding when a mapping can be reused 171 differs for different NATs as described in [BEHAVE-UDP]. 173 Consider an internal IP address and TCP port (X:x) that initiates a 174 TCP connection to an external (Y1:y1) tuple. Let the mapping 175 allocated by the NAT for this connection be (X1':x1'). Shortly 176 thereafter, the endpoint initiates a connection from the same (X:x) 177 to an external address (Y2:y2) and gets the mapping (X2':x2') on the 178 NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all 179 values of (Y2:y2) then the NAT is defined to have "Endpoint 180 Independent Mapping" behavior. If (X1':x1') equals (X2':x2') only 181 when Y2 equals Y1 then the NAT is defined to have "Address Dependent 182 Mapping" behavior. If (X1':x1') equals (X2':x2') only when (Y2:y2) 183 equals (Y1:y1), possible only for consecutive connections to the same 184 external address shortly after the first is terminated and if the NAT 185 retains state for connections in TIME_WAIT state, then the NAT is 186 defined to have "Address and Port Dependent Mapping" behavior. This 187 document introduces one additional behavior where (X1':x1') never 188 equals (X2':x2'), that is, for each connection a new mapping is 189 allocated; in such a case, the NAT is defined to have "Connection 190 Dependent Mapping" behavior. 192 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior 193 for TCP. 195 Justification: REQ-1 is necessary for UNSAF methods to work. 196 Endpoint independent mapping behavior allows peer-to-peer 197 applications to learn and advertise the external IP address and 198 port allocated to an internal endpoint such that external peers 199 can contact it (subject to the NAT's security policy). The 200 security policy of a NAT is independent of its mapping behavior 201 and is discussed later in Section 4.3. Having endpoint 202 independent mapping behavior allows peer-to-peer applications to 203 work consistently without compromising the security benefits of 204 the NAT. 206 4.2. Internally Initiated Connections 208 An internal endpoint initiates a TCP connection through a NAT by 209 sending a SYN packet. The NAT allocates (or reuses) a mapping for 210 the connection, as described in the previous section. The mapping 211 defines the external IP address and port used for translation of all 212 packets for that connection. In particular, for client-server 213 applications where an internal client initiates the connection to an 214 external server, the mapping is used to translate the outbound SYN, 215 the resulting inbound SYN-ACK response, the subsequent outbound ACK, 216 and other packets for the connection. This method of connection 217 initiation corresponds to the 3-way handshake (defined in [RFC0793]) 218 and is supported by all NATs. 220 Peer-to-peer applications use an alternate method of connection 221 initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse 222 NATs. In the Simultaneous-Open mode of operation, both peers send 223 SYN packets for the same TCP connection. The SYN packets cross in 224 the network. Upon receiving the other end's SYN packet each end 225 responds with a SYN-ACK packet, which also cross in the network. The 226 connection is considered established once the SYN-ACKs are received. 227 From the perspective of the NAT, the internal host's SYN packet is 228 met by an inbound SYN packet for the same connection (as opposed to a 229 SYN-ACK packet during a 3-way handshake). Subsequent to this 230 exchange, both an outbound and an inbound SYN-ACK are seen for the 231 connection. Some NATs erroneously block the inbound SYN for the 232 connection in progress. Some NATs block or incorrectly translate the 233 outbound SYN-ACK. Such behavior breaks TCP simultaneous-open and 234 prevents peer-to-peer applications from functioning correctly behind 235 a NAT. 237 In order to provide network address translation service for TCP, it 238 is necessary for a NAT to correctly receive, translate, and forward 239 all packets for a connection that conform to valid transitions of the 240 TCP State-Machine (Fig. 6, [RFC0793]). 242 REQ-2: A NAT MUST support all valid sequences of TCP packets 243 (defined in [RFC0793]) for connections initiated both internally 244 as well as externally when the connection is permitted by the NAT. 245 In particular: 246 a) In addition to handling the TCP 3-way handshake mode of 247 connection initiation, A NAT MUST handle the TCP simultaneous- 248 open mode of connection initiation. 250 Justification: The intent of this requirement is to allow standards 251 compliant TCP stacks to traverse NATs no matter what path the 252 stacks take through the TCP state-machine and no matter which end 253 initiates the connection as long as the connection is permitted by 254 the filtering policy of the NAT (filtering policy is described in 255 the following section). 256 a) In addition to TCP packets for a 3-Way Handshake, A NAT must be 257 prepared to accept an inbound SYN and an outbound SYN-ACK for 258 an internally initiated connection in order to support 259 Simultaneous-Open. 261 4.3. Externally Initiated Connections 263 The NAT allocates a mapping for the first connection initiated by an 264 internal endpoint to an external endpoint. In some scenarios, the 265 NAT's policy may allow this mapping to be reused for connections 266 initiated from the external side to the internal endpoint. Consider 267 as before an internal IP address and port (X:x) that is assigned (or 268 reuses) a mapping (X1':x1') when it initiates a connection to an 269 external (Y1:y1). An external endpoint (Y2:y2) attempts to initiate 270 a connection with the internal endpoint by sending a SYN to 271 (X1':x1'). A NAT can choose to either allow the connection to be 272 established, or to disallow the connection. If the NAT chooses to 273 allow the connection, it translates the inbound SYN and routes it to 274 (X:x) as per the existing mapping. It also translates the SYN-ACK 275 generated by (X:x) in response and routes it to (Y2:y2) and so on. 276 Alternately, the NAT can disallow the connection by filtering the 277 inbound SYN. 279 A NAT may allow an existing mapping to be reused by an externally 280 initiated connection if its security policy permits. Several 281 different policies are possible as described in [BEHAVE-UDP]. If a 282 NAT allows the connection initiation from all (Y2:y2) then it is 283 defined to have "Endpoint Independent Filtering" behavior. If the 284 NAT allows connection initiations only when Y2 equals Y1 then the NAT 285 is defined to have "Address Dependent Filtering" behavior. If the 286 NAT allows connection initiations only when (Y2:y2) equals (Y1:y1), 287 then the NAT is defined to have "Address and Port Dependent 288 Filtering" behavior (possible only shortly after the first connection 289 has been terminated but the mapping is still active). One additional 290 filtering behavior defined in this document is when the NAT does not 291 allow any connection initiations from the external side; in such 292 cases, the NAT is defined to have "Connection Dependent Filtering" 293 behavior. The difference between "Address and Port Dependent 294 Filtering" and "Connection Dependent Filtering" behavior is that the 295 former permits an inbound SYN during the TIME_WAIT state of the first 296 connection to initiate a new connection while the latter does not. 298 REQ-3: If application transparency is most important, it is 299 RECOMMENDED that a NAT have an "Endpoint independent filtering" 300 behavior for TCP. If a more stringent filtering behavior is most 301 important, it is RECOMMENDED that a NAT have an "Address dependent 302 filtering" behavior. 303 a) The filtering behavior MAY be an option configurable by the 304 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 For NATs that combine NAT functionality with end-host functionality 391 (e.g. an end-host that also serves as a NAT for other hosts behind 392 it), REQ-4 above applies only to SYNs intended for the NAT'ed hosts 393 and not to SYNs intended for the NAT itself. One way to determine 394 whether the inbound SYN is intended for a NAT'ed host is to allocate 395 NAT mappings from one port range, and allocate ports for local 396 endpoints from a different non-overlapping port range. More dynamic 397 implementations can be imagined. 399 5. NAT Session Refresh 401 A NAT maintains state associated with in-progress and established 402 connections. Because of this, a NAT is susceptible to a resource- 403 exhaustion attack whereby an attacker (or virus) on the internal side 404 attempts to cause the NAT to create more state than it has resources 405 for. To prevent such an attack, a NAT needs to abandon sessions in 406 order to free the state resources. 408 A common method that is applicable only to TCP is to preferentially 409 abandon sessions for crashed endpoints, followed by closed TCP 410 connections and partially-open connections. A NAT can check if an 411 endpoint for a session has crashed by sending a TCP keep-alive packet 412 and receiving a TCP RST packet in response. If the NAT cannot 413 determine whether the endpoint is active, it should not abandon the 414 session until the TCP connection has been idle for some time. Note 415 that an established TCP connection can stay idle (but live) 416 indefinitely; hence there is no fixed value for an idle-timeout that 417 accommodates all applications. However, a large idle-timeout 418 motivated by recommendations in [RFC1122] can reduce the chances of 419 abandoning a live session. 421 A TCP connection passes through three phases: partially-open, 422 established, and closing. During the partially-open phase, endpoints 423 synchronize initial sequence numbers. The phase is initiated by the 424 first SYN for the connection and extends until both endpoints have 425 sent a packet with the ACK flag set (TCP states: SYN_SENT and 426 SYN_RCVD). ACKs in both directions mark the beginning of the 427 established phase where application data can be exchanged 428 indefinitely (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and 429 CLOSE_WAIT). The closing phase begins when both endpoint have 430 terminated their half of the connection by sending a FIN packet. 431 Once FIN packets are seen in both directions, application data can no 432 longer be exchanged but the stacks still need to ensure that the FIN 433 packets are received (TCP states: CLOSING and LAST_ACK). 435 TCP connections can stay in established phase indefinitely without 436 exchanging any packets. Some end-hosts can be configured to send 437 keep-alive packets on such idle connections; by default, such keep- 438 alive packets are sent every 2 hours if enabled [RFC1122]. 439 Consequently, a NAT that waits for slightly over 2 hours can detect 440 idle connections with keep-alive packets being sent at the default 441 rate. TCP connections in the partially-open or closing phases, on 442 the other hand, can stay idle for at most 4 minutes while waiting for 443 in-flight packets to be delivered [RFC1122]. 445 The "established connection idle-timeout" for a NAT is defined as the 446 minimum time a TCP connection in the established phase must remain 447 idle before the NAT considers the associated session a candidate for 448 removal. The "transitory connection idle-timeout" for a NAT is 449 defined as the minimum time a TCP connection in the partially-open or 450 closing phases must remain idle before the NAT considers the 451 associated session a candidate for removal. TCP connections in the 452 TIME_WAIT state are not affected by the "transitory connection idle- 453 timeout". 455 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 456 connection are active, it MAY abandon the session if it has been 457 idle for some time. In such cases, the value of the "established 458 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 459 The value of the "transitory connection idle-timeout" MUST NOT be 460 less than 4 minutes. 461 a) The value of the NAT idle-timeouts MAY be configurable. 463 Justification: The intent of this requirement is to minimize the 464 cases where a NAT abandons session state for a live connection. 465 While some NATs may choose to abandon sessions reactively in 466 response to new connection initiations (allowing idle connections 467 to stay up indefinitely in the absence of new initiations), other 468 NATs may choose to proactively reap idle sessions. In cases where 469 the NAT cannot actively determine if the connection is alive, this 470 requirement ensures that applications can send keep-alive packets 471 at the default rate (every 2 hours) such that the NAT can 472 passively determine that the connection is alive. The additional 473 4 minutes allows time for in-flight packets to cross the NAT. 475 NAT behavior for handling RST packets, or connections in TIME_WAIT 476 state is left unspecified. A NAT MAY hold state for a connection in 477 TIME_WAIT state to accommodate retransmissions of the last ACK. 478 However, since the TIME_WAIT state is commonly encountered by 479 internal endpoints properly closing the TCP connection, holding state 480 for a closed connection may limit the throughput of connections 481 through a NAT with limited resources. [RFC1337] describes hazards 482 associated with TIME_WAIT assassination. 484 The handling of non-SYN packets for connections for which there is no 485 active mapping is left unspecified. Such packets may be received if 486 the NAT silently abandons a live connection, or abandons a connection 487 in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The 488 decision to either silently drop such packets or to respond with a 489 TCP RST packet is left up to the implementation. 491 NAT behavior for notifying endpoints when abandoning live connections 492 is left unspecified. When a NAT abandons a live connection, for 493 example due to a timeout expiring, the NAT MAY either send TCP RST 494 packets to the endpoints or MAY silently abandon the connection. 496 Sending a RST notification allows endpoint applications to recover 497 more quickly, however, notifying the endpoints may not always be 498 possible if, for example, session state it lost due to a power 499 failure. 501 6. Application Level Gateways 503 Application Level Gateways (ALGs) in certain NATs modify IP addresses 504 and TCP ports embedded inside application protocols. Such ALGs may 505 interfere with UNSAF methods or protocols that try to be NAT-aware 506 and must therefore be used with extreme caution. 508 REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED 509 that all of those ALGs (except for FTP [RFC0959]) be disabled by 510 default. 512 Justification: The intent of this requirement is to prevents ALGs 513 from interfering with UNSAF methods. The default state of a FTP 514 ALG is left unspecified because of legacy concerns: as of writing 515 this memo, a large fraction of legacy FTP clients do not enable 516 passive (PASV) mode by default and require an ALG to traverse 517 NATs. 519 7. Other Requirements Applicable to TCP 521 A list of general and UDP specific NAT behavioral requirements are 522 described in [BEHAVE-UDP]. A list of ICMP specific NAT behavioral 523 requirements are described in [BEHAVE-ICMP]. The requirements listed 524 below reiterate the requirements from these two documents that 525 directly affect TCP. The following requirements do not relax any 526 requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. 528 7.1. Port Assignment 530 NATs that allow different internal endpoints to simultaneously use 531 the same mapping are defined in [BEHAVE-UDP] to have a "Port 532 assignment" behavior of "Port overloading". Such behavior is 533 undesirable as it prevents two internal endpoints sharing the same 534 mapping from establishing simultaneous connections to a common 535 external endpoint. 537 REQ-7 A NAT MUST NOT have a "Port assignment" behavior of "Port 538 overloading" for TCP. 540 Justification: This requirement allows two applications on the 541 internal side of the NAT to consistently communicate with the same 542 destination. 544 NAT behavior for preserving the source TCP port range for connections 545 is left unspecified. Some applications expect the source TCP port to 546 be in the well-known range (TCP ports from 0 to 1023). The "r" 547 series of commands (rsh, rcp, rlogin, etc.) are an example. NATs 548 that preserve the range from which the source port is picked allow 549 such applications to function properly through the NAT, however, by 550 doing so the NAT may compromise the security of the application in 551 certain situations; applications that depend only on the IP address 552 and source TCP port range for security (the "r" commands for example) 553 cannot distinguish between an attacker and a legitimate user behind 554 the same NAT. 556 7.2. Hairpinning Behavior 558 NATs that forward packets originating from an internal address, 559 destined for an external address that matches the active mapping for 560 an internal address, back to that internal address are defined in 561 [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the 562 hairpinned packet with an external source IP address and port (i.e. 563 the mapped source address and port of the originating internal 564 endpoint), then it is defined to have "External source IP address and 565 port" for hairpinning. Hairpinning is necessary to allow two 566 internal endpoints (known to each other only by their external mapped 567 addresses) to communicate with each other. "External source IP 568 address and port" behavior for hairpinning avoids confusing 569 implementations that expect the external source address and port. 571 REQ-8: A NAT MUST support "Hairpinning" for TCP. 572 a) A NAT's Hairpinning behavior MUST be of type "External source 573 IP address and port". 575 Justification: This requirement allows two applications behind the 576 same NAT that are trying to communicate with each other using 577 their external addresses. 578 a) Using the external source address and port for the hairpinned 579 packet is necessary for applications that do not expect to 580 receive a packet from a different address than the external 581 address they are trying to communicate with. 583 7.3. ICMP Responses to TCP Packets 585 Several TCP mechanisms depend on the reception of ICMP error messages 586 triggered by the transmission of TCP segments. One such mechanism is 587 path MTU discovery [RFC1191], which is required for the correct 588 operation of TCP. The current path MTU discovery mechanism requires 589 the sender of TCP segments to be notified of ICMP "Datagram Too Big" 590 responses. 592 REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination 593 Unreachable (Type 3) messages. 595 Justification: Translating ICMP Destination Unreachable messages, 596 particularly the "Fragmentation Needed and Don't Fragment was Set" 597 (Type 3, Code 4) message avoids communication failures ("black 598 holes" [RFC2923]). Furthermore, TCP's connection establishment 599 and maintenance mechanisms also behave much more efficiently when 600 ICMP Destination Unreachable messages arrive in response to 601 outgoing TCP segments. 603 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 604 NAT mapping or TCP connection for which the ICMP was generated. 606 Justification: This is necessary for reliably performing TCP 607 simultaneous-open where a remote NAT may temporarily signal an 608 ICMP error. 610 8. Requirements 612 A NAT that supports all of the mandatory requirements of this 613 specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], 614 is "compliant with this specification". A NAT that supports all of 615 the requirements of this specification (i.e., included the 616 "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully 617 compliant with all the mandatory and recommended requirements of this 618 specification". 620 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior 621 for TCP. 622 REQ-2: A NAT MUST support all valid sequences of TCP packets 623 (defined in [RFC0793]) for connections initiated both internally 624 as well as externally when the connection is permitted by the NAT. 625 In particular: 626 a) In addition to handling the TCP 3-way handshake mode of 627 connection initiation, A NAT MUST handle the TCP simultaneous- 628 open mode of connection initiation. 629 REQ-3: If application transparency is most important, it is 630 RECOMMENDED that a NAT have an "Endpoint independent filtering" 631 behavior for TCP. If a more stringent filtering behavior is most 632 important, it is RECOMMENDED that a NAT have an "Address dependent 633 filtering" behavior. 635 a) The filtering behavior MAY be an option configurable by the 636 administrator of the NAT. 637 b) The filtering behavior for TCP MAY be independent of the 638 filtering behavior for UDP. 639 REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet 640 for at least 6 seconds after the packet is received. If during 641 this interval the NAT receives and translates an outbound SYN for 642 the connection the NAT MUST silently drop the original unsolicited 643 inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port 644 Unreachable error (Type 3, Code 3) for the original SYN, unless 645 REQ-4a applies. 646 a) The NAT MUST silently drop the original SYN packet if sending a 647 response violates the security policy of the NAT. 648 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 649 connection are active, it MAY abandon the session if it has been 650 idle for some time. In such cases, the value of the "established 651 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 652 The value of the "transitory connection idle-timeout" MUST NOT be 653 less than 4 minutes. 654 a) The value of the NAT idle-timeouts MAY be configurable. 655 REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED 656 that all of those ALGs (except for FTP [RFC0959]) be disabled by 657 default. 659 The following requirements reiterate requirements from [BEHAVE-UDP] 660 or [BEHAVE-ICMP] that directly affect TCP. This document does not 661 relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP]. 663 REQ-7 A NAT MUST NOT have a "Port assignment" behavior of "Port 664 overloading" for TCP. 665 REQ-8: A NAT MUST support "Hairpinning" for TCP. 666 a) A NAT's Hairpinning behavior MUST be of type "External source 667 IP address and port". 668 REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination 669 Unreachable (Type 3) messages. 670 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 671 NAT mapping or TCP connection for which the ICMP was generated. 673 9. Security considerations 675 [BEHAVE-UDP] discusses security considerations for NATs that handle 676 IP and unicast UDP traffic. Security concerns specific to handling 677 TCP packets are discussed in this section. 679 Security considerations for REQ-1: This requirement does not 680 introduce any TCP-specific security concerns. 682 Security considerations for REQ-2: This requirement does not 683 introduce any TCP-specific security concerns. Simultaneous-open 684 and other transitions in the TCP state machine are by-design and 685 necessary for TCP to work correctly in all scenarios. Further, 686 this requirement only affects connections already in progress as 687 authorized by the NAT in accordance with its policy. 689 Security considerations for REQ-3: The security provided by the NAT 690 is governed by its filtering behavior as addressed in 691 [BEHAVE-UDP]. Connection dependent filtering behavior is most 692 secure from a firewall perspective, but severely restricts 693 connection initiations through a NAT. Endpoint independent 694 filtering behavior, which is most transparent to applications, 695 requires an attacker to guess the IP address and port of an active 696 mapping in order to get his packet to an internal host. Address 697 dependent filtering, on the other hand, is less transparent than 698 endpoint independent filtering but more transparent than 699 connection dependent filtering; it is more secure than endpoint 700 independent filtering as it requires an attacker to additionally 701 guess the address of the external endpoint for a NAT session 702 associated with the mapping and be able to receive packets 703 addressed to the same. While this protects against most attackers 704 on the Internet, it does not necessarily protect against attacks 705 that originate from behind a remote NAT with a single IP address 706 that is also translating a legitimate connection to the victim. 708 Security considerations for REQ-4: This document recommends a NAT to 709 respond to unsolicited inbound SYN packets with an ICMP error 710 delayed by a few seconds. Doing so may reveal the presence of a 711 NAT to an external attacker. Silently dropping the SYN makes it 712 harder to diagnose network problems and forces applications to 713 wait for the TCP stack to finish several retransmissions before 714 reporting an error. An implementer must therefore understand and 715 carefully weigh the effects of not sending an ICMP error or rate- 716 limiting such ICMP errors to a very small number. 718 Security considerations for REQ-5: This document recommends that a 719 NAT that passively monitors TCP state keep idle sessions alive for 720 at least 2 hours 4 minutes or 4 minutes depending on the state of 721 the connection. If a NAT is under attack, it may attempt to 722 actively determine the liveliness of a TCP connection or let the 723 NAT administrator configure more conservative timeouts. 725 Security considerations for REQ-6: This requirement does not 726 introduce any TCP-specific security concerns. 728 Security considerations for REQ-7: This requirement does not 729 introduce any TCP-specific security concerns. 731 Security considerations for REQ-8: This requirement does not 732 introduce any TCP-specific security concerns. 734 Security considerations for REQ-9: This requirement does not 735 introduce any TCP-specific security concerns. 737 Security considerations for REQ-10: This requirement does not 738 introduce any TCP-specific security concerns. 740 NAT implementations that modify TCP sequence numbers (e.g., for 741 privacy reasons or for ALG support) must ensure that TCP packets with 742 SACK notifications [RFC2018] are properly handled. 744 NAT implementations that modify local state based on TCP flags in 745 packets must ensure that out-of-window TCP packets are properly 746 handled. [RFC4953] summarizes and discusses a variety of solutions 747 designed to prevent attackers from affecting TCP connections. 749 10. IANA considerations 751 This document does not change or create any IANA-registered values. 753 11. Acknowledgments 755 Joe Touch contributed the mechanism for handling unsolicited inbound 756 SYNs. Thanks to Mark Allman, Francois Audet, Lars Eggert, Paul 757 Francis, Fernando Gont, Sam Hartman, Paul Hoffman, Dave Hudson, 758 Cullen Jennings, Philip Matthews, Tom Petch, Magnus Westerlund, and 759 Dan Wing for their many contributions, comments and suggestions. 761 12. References 763 12.1. Normative References 765 [BEHAVE-UDP] 766 Audet, F. and C. Jennings, "Network Address Translation 767 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 768 RFC 4787, January 2007. 770 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 771 RFC 793, September 1981. 773 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 774 STD 9, RFC 959, October 1985. 776 [RFC1122] Braden, R., "Requirements for Internet Hosts - 777 Communication Layers", STD 3, RFC 1122, October 1989. 779 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 780 November 1990. 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, March 1997. 785 12.2. Informational References 787 [BEHAVE-ICMP] 788 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 789 Behavioral Requirements for ICMP protocol", 790 draft-ietf-behave-nat-icmp (work in progress). 792 [NATBLASTER] 793 Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig, 794 "NATBLASTER: Establishing TCP connections between hosts 795 behind NATs", Proceedings of the ACM SIGCOMM Asia 796 Workshop (Beijing, China), April 2005. 798 [P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer 799 communication across network address translators", 800 Proceedings of the USENIX Annual Technical 801 Conference (Anaheim, CA), April 2005. 803 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 804 RFC 1337, May 1992. 806 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 807 Functional Specification", RFC 1644, July 1994. 809 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 810 Selective Acknowledgment Options", RFC 2018, October 1996. 812 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 813 Translator (NAT) Terminology and Considerations", 814 RFC 2663, August 1999. 816 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 817 RFC 2923, September 2000. 819 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 820 Address Translator (Traditional NAT)", RFC 3022, 821 January 2001. 823 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 824 for Transmission Control Protocol (TCP) Specification 825 Documents", RFC 4614, September 2006. 827 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 828 RFC 4953, July 2007. 830 [STUNT] Guha, S. and P. Francis, "NUTSS: A SIP based approach to 831 UDP and TCP connectivity", Proceedings of the ACM SIGCOMM 832 Workshop on Future Directions in Network 833 Architecture (Portland, OR), August 2004. 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 859 Bryan Ford 860 M.I.T. 861 Laboratory for Computer Science 862 77 Massachusetts Ave. 863 Cambridge, MA 02139 864 US 866 Phone: +1 617 253 5261 867 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 (2008). 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.