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