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