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