idnits 2.17.1 draft-hoffman-behave-tcp-04.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 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 484. ** 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 (Feb 2006) is 6638 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) ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 793 (ref. '8') (Obsoleted by RFC 9293) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Guha 3 Internet-Draft Cornell U. 4 Expires: August 5, 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 Feb 2006 16 NAT Behavioral Requirements for Unicast TCP 17 draft-hoffman-behave-tcp-04.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 August 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. TCP Session Setup . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1 Address and Port Mapping . . . . . . . . . . . . . . . . . 4 62 4.2 Internally Initiated Sessions . . . . . . . . . . . . . . 4 63 4.3 Externally Initiated Sessions . . . . . . . . . . . . . . 5 64 5. TCP Session Refresh . . . . . . . . . . . . . . . . . . . . . 6 65 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 7 66 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. Security considerations . . . . . . . . . . . . . . . . . . . 7 68 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 70 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . 12 74 1. Applicability Statement 76 This document is adjunct to RFC FIXME-BEHAVE-UDP [1], which defines 77 many terms relating to NATs, lays out general requirements for all 78 NATs, and sets requirements for NATs that handle unicast UDP traffic. 79 The purpose of this document is to set requirements for NATs that 80 handle TCP traffic (that is, almost every NAT). 82 The requirements of this specification apply to Traditional NATs as 83 described in RFC 2663 [2]. 85 This document only covers the TCP aspects of NAT traversal. 86 Firewalls, and packet inspection above the TCP layer are out-of- 87 scope. Middle-box behavior that is not necessary for network address 88 translation of TCP is out-of-scope. Application and OS aspects of 89 TCP NAT traversal are out-of-scope. Signaling based approaches to 90 NAT traversal such as Midcom and UPnP that directly control the NAT 91 are out-of-scope. 93 2. Introduction 95 Network Address Translators (NATs) hinder connectivity in 96 applications where connections may be initiated to internal hosts. 97 RFC FIXME-BEHAVE-UDP [1] lays out the terminology and requirements 98 for NATs in the context of UDP. This document supplements these by 99 setting requirements for NATs that handle TCP traffic. All 100 definitions and requirements in [1] are inherited here. 102 Recently, many techniques have been devised to make peer-to-peer TCP 103 applications work across NATs. STUNT [3], NATBLASTER [4], and P2PNAT 104 [5] describe UNilateral Self-Address Translation (UNSAF) mechanisms 105 to establish TCP through NATs by modifying only endpoints. These 106 approaches depend on specific NAT behavior that is not always 107 supported (see [6] and [5] for details). Consequently a complete TCP 108 NAT Traversal solution is sometimes forced to rely on public TCP 109 Relays. This document defines requirements that ensures that TCP NAT 110 Traversal approaches are not forced to use data relays. 112 3. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [7]. 118 This document uses the term "session" as defined in RFC 2663 [2]. 119 "NAT" in this specification includes both "Basic NAT" and "Network 120 Address/Port Translator (NAPT)" [2]. 122 This document uses the terms "address and port mapping", "endpoint 123 independent mapping", "filtering behavior", "endpoint independent 124 filtering", "address dependent filtering" and "address and port 125 dependent filtering" as defined in RFC FIXME-BEHAVE-UDP [1]. 127 4. TCP Session Setup 129 This section describes various NAT behaviors applicable to TCP 130 session setup. 132 4.1 Address and Port Mapping 134 RFC FIXME-BEHAVE-UDP [1] defines the criteria for the re-use of a 135 mapping for new sessions. The definition presented there is agnostic 136 of the transport protocol used and applies directly to TCP. 138 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 139 independent" behavior. 141 Justification: REQ-1 is necessary for UNSAF methods to work. Refer 142 to REQ-1 in [1] for details. 144 4.2 Internally Initiated Sessions 146 An internal endpoint initiates a TCP session through a NAT by sending 147 a SYN packet. The NAT assigns an external IP address and port number 148 for the session so the resulting SYNACK response can be received, 149 translated and routed to the internal endpoint. This translation is 150 used for the subsequent ACK and other packets for the duration of the 151 session. This corresponds to the 3-Way Handshake mode of session 152 initiation defined in RFC 793 [8] and is supported by all NATs. 154 RFC 793 defines an alternate mode of session initiation, termed 155 Simultaneous-Open, which is used by peer-to-peer applications to 156 traverse NATs. In the Simultaneous-Open mode of operation, both 157 endpoints send SYN packets that cross in the network, followed by 158 SYNACK packets that cross in the network. From the perspective of 159 the NAT, the internal host's SYN packet is responded by an inbound 160 SYN packet for the same session (as opposed to a SYNACK packet). 161 Subsequent to this exchange, both an outbound and inbound SYNACK are 162 seen for the session. Some NATs block the inbound SYN for the 163 session; some NATs block or incorrectly translate the outbound 164 SYNACK. Such behavior breaks TCP Simultaneous-Open and prevents 165 peer-to-peer applications from functioning correctly behind a NAT. 167 In order to provide network address translation service for TCP, it 168 is necessary for a NAT to correctly receive, translate, and forward 169 all packets for a session that conforms to valid transitions of the 170 TCP State-Machine [8]. 172 REQ-2: For a TCP session, a NAT MUST support all valid sequences of 173 TCP packets as defined in RFC 793. In particular: 174 a) A NAT MUST support TCP Simultaneous-Open. 176 Justification: This requirement enables standards compliant TCP 177 stacks to traverse NATs. 179 4.3 Externally Initiated Sessions 181 When an internal endpoint initiates a session, the NAT assigns an 182 external IP:port. Some peer-to-peer applications let other external 183 endpoints initiate a TCP session to the internal endpoint by sending 184 a SYN to the external IP:port allocated. Such applications depend on 185 the NAT to reuse the mapping and route the SYN to the internal 186 endpoint. The internal endpoint replies with a SYNACK packet that 187 the NAT is expected to translate and forward to the external 188 endpoint, which responds with an ACK to complete the initiation. The 189 filtering behavior of the NAT, defined in [1], governs which external 190 endpoints are allowed to send inbound SYN packets for a new session. 192 REQ-3: A NAT with "Endpoint independent filtering" or "Address 193 dependent filtering" behavior MUST support TCP session initiations 194 from the specific external endpoints. Note that this requirement 195 is not applicable to NATs that have "Address and port dependent 196 filtering" behavior. 198 Justification: This is to avoid breaking peer-to-peer applications 199 which do not always initiate sessions from the internal side of 200 the NAT. 202 If the inbound SYN packet is filtered, either because a corresponding 203 mapping does not exist or because of the NAT's filtering behavior, a 204 NAT has two basic choices: to ignore the packet silently, or signal 205 an error to the sender. Ignoring the SYN helps applications perform 206 TCP Simultaneous-Open in the presence of clock skew and network 207 congestion where the inbound SYN may arrive at the NAT before the 208 outbound SYN creates the necessary session state. 210 REQ-4: It is RECOMMENDED that a NAT silently discard inbound SYN 211 packets that are filtered or cannot be routed. 213 Justification: This allows applications to traverse NATs with greater 214 ease. 216 5. TCP Session Refresh 218 A NAT maintains state associated with new and established sessions. 219 Because of this, a NAT is susceptible to a resource-exhaustion attack 220 whereby an attacker (or virus) on the internal side attempts to cause 221 the NAT to create more state than it has resources for. To prevent 222 such an attack, a NAT needs to abandon sessions in order to free the 223 state resources. 225 A common method that is applicable only to TCP sessions is to 226 preferentially abandon sessions for crashed endpoints, followed by 227 closed TCP sessions and partially-open sessions. A NAT can check if 228 an endpoint has crashed by sending a TCP keep-alive packet and 229 checking for the response. If the NAT cannot determine whether the 230 session is active, it should not abandon it until the session has 231 been idle for some time. The time is derived from values recommended 232 in RFC 1122 [9]. The states of a TCP session that these values 233 correspond to are defined in RFC 793 [8] and can be inferred by 234 passively examining the TCP flags of inbound and outbound packets for 235 that session. 237 The established session timer is defined as the time a mapping will 238 stay active for a session over which application data can be 239 exchanged. Application data can be exchanged over a TCP session in 240 states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and CLOSE_WAIT. 242 The transitory session timer is defined as the time a mapping will 243 stay active for a session over which application data cannot yet be 244 exchanged, or can no longer be exchanged. This includes partially- 245 open TCP sessions in states: SYN_SENT and SYN_RCVD, and closed 246 sessions in states: CLOSING, LAST_ACK, and TIME_WAIT. 248 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 249 session are active, it MAY abandon the session if it has been idle 250 for some time. A default value of 2 hours for the established 251 session timer is RECOMMENDED. A default value of 4 minutes for 252 the transitory session timer is RECOMMENDED. 253 a) The value of the NAT TCP session timers MAY be configurable. 255 Justification: If a NAT cannot determine whether the endpoint of an 256 idle TCP session has crashed, the NAT should assume that the 257 endpoint is active. However, to defend against DoS attacks, a NAT 258 can abandon session state under certain circumstances while 259 minimally impacting active endpoints. For idle TCP sessions where 260 data can be exchanged (that is, once ACK packets are seen in both 261 directions, and FIN packets have not been seen in both 262 directions), some endpoints send keep-alive packets at 2 hour 263 intervals by default. For idle TCP sessions that are partially- 264 open or closed, TCP waits 2xMSL (4 minutes) for in-flight packets 265 to be delivered and acknowledged. If a NAT passively waits for at 266 least this interval and does not see any packets for the TCP 267 session, it can prematurely abandon the session without impacting 268 most applications. NAT behavior for handling RST packets for a 269 session is left undefined. 270 a) Configuration helps troubleshoot and accommodate specific 271 applications. 273 6. Application Level Gateways 275 FIXME OPEN ISSUE: Is this out-of-scope? Do we need to specify all 276 TCP ALGs should be off by default? What about FTP? 278 7. Requirements 280 A NAT that supports all of the mandatory requirements of this 281 specification (i.e., the "MUST") and is compliant with [1], is 282 "compliant with this specification." A NAT that supports all of the 283 requirements of this specification (i.e., included the "RECOMMENDED") 284 and is fully compliant with [1] is "fully compliant with all the 285 mandatory and recommended requirements of this specification." 287 REQ-1: A NAT MUST have an "External NAT mapping is endpoint 288 independent" behavior. 289 REQ-2: For a TCP session, a NAT MUST support all valid sequences of 290 TCP packets as defined in RFC 793. In particular: 291 a) A NAT MUST support TCP Simultaneous-Open. 292 REQ-3: A NAT with "Endpoint independent filtering" or "Address 293 dependent filtering" behavior MUST support TCP session initiations 294 from the specific external endpoints. Note that this requirement 295 is not applicable to NATs that have "Address and port dependent 296 filtering" behavior. 297 REQ-4: It is RECOMMENDED that a NAT silently discard inbound SYN 298 packets that are filtered or cannot be routed. 299 REQ-5: If a NAT cannot determine whether the endpoints of a TCP 300 session are active, it MAY abandon the session if it has been idle 301 for some time. A default value of 2 hours for the established 302 session timer is RECOMMENDED. A default value of 4 minutes for 303 the transitory session timer is RECOMMENDED. 304 a) The value of the NAT TCP session timers MAY be configurable. 306 8. Security considerations 308 In addition to the security considerations addressed in [1], there 309 are additional concerns for handling TCP packets and are discussed in 310 this section. 312 Security considerations for REQ-1: This requirement does not 313 introduce any TCP-specific concerns in addition to those already 314 addressed in [1]. 315 Security considerations for REQ-2: This document requires that a NAT 316 accept an inbound SYN packet for a session in response to the 317 outbound SYN packet. In order to provide extra security, some 318 NATs require the ACK flag to be set in all inbound packets. This 319 attempts to protect against attackers that can blindly spoof SYN 320 packets appearing to come from the external destination, but are 321 not able to receive, and therefore acknowledge, packets addressed 322 to the same. REQ-2 in this document does not prevent a NAT from 323 providing the same security guarantees. Even after the inbound 324 SYN is accepted, the external endpoint is required by the TCP 325 specification to explicitly acknowledge the internal endpoint's 326 sequence number through a subsequent SYNACK or ACK packet. The 327 NAT can check these subsequent packets to thwart such spoofing 328 attacks. 329 Security considerations for REQ-3: The security provided by the NAT 330 is governed by its filtering behavior as addressed in [1]. 331 Allowing TCP sessions to be initiated by endpoints in accordance 332 with the filtering behavior does not introduce additional 333 concerns. 334 Security considerations for REQ-4: This document recommends that if 335 an inbound SYN packet is filtered, then the NAT should silently 336 discard it. Some NATs send TCP RST or ICMP errors in response to 337 filtered packets. This serves to protect the NAT'ed hosts from 338 identity-theft attacks. In such an attack, the NAT is the 339 rightful recipient for an address, but an attacker blindly spoofs 340 packets from this address. If the NAT silently drops unexpected 341 inbound packets then the attacker can potentially spoof an entire 342 TCP session and masquerade as the NAT'ed endpoint. REQ-4 allows a 343 NAT to respond to such attacks by sending error packets for 344 unexpected non-SYN packets that follow the SYN packet. 345 Security considerations for REQ-5: This document recommends that a 346 NAT that passively monitors session state keep idle TCP sessions 347 alive for at least 4 minutes for partially-open or closed 348 sessions, and for at least 2 hours for established sessions by 349 default. If a NAT is under a DoS attack, the NAT administrator 350 may configure session timeouts accordingly, or let the NAT 351 actively determine session state. 353 NAT implementations that change local state based on TCP flags in 354 packets must ensure that out-of-window TCP packets are properly 355 handled. Out-of-window TCP packets are sometimes used in attacks 356 where an attacker resets arbitrary TCP sessions by guessing only the 357 endpoint IP addresses and ports. If the window is too large, an 358 attacker can send a small number of packets with crafted sequence 359 numbers such that one of these packets is considered an in-window 360 packet that resets the session. 362 9. IANA considerations 364 This document does not change or create any IANA-registered values. 366 10. Acknowledgments 368 Thanks to Paul Hoffman for his many contributions to this document. 370 11. Normative References 372 [1] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 373 Unicast UDP", draft-ietf-behave-nat-udp (work in progress). 375 [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 376 (NAT) Terminology and Considerations", RFC 2663, August 1999. 378 [3] Guha, S. and P. Francis, "NUTSS: A SIP based approach to UDP and 379 TCP connectivity", Proceedings of the ACM SIGCOMM Workshop on 380 Future Directions in Network Architecture (Portland, OR), 381 August 2004. 383 [4] Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig, 384 "NATBLASTER: Establishing TCP connections between hosts behind 385 NATs", Proceedings of the ACM SIGCOMM Asia Workshop (Beijing, 386 China), April 2005. 388 [5] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer 389 communication across network address translators", Proceedings 390 of the USENIX Annual Technical Conference (Anaheim, CA), 391 April 2005. 393 [6] Guha, S. and P. Francis, "Characterization and Measurement of 394 TCP Traversal through NATs and Firewalls", Proceedings of the 395 Internet Measurement Conference (Berkeley, CA), October 2005. 397 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 398 Levels", BCP 14, RFC 2119, March 1997. 400 [8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 401 September 1981. 403 [9] Braden, R., "Requirements for Internet Hosts - Communication 404 Layers", STD 3, RFC 1122, October 1989. 406 Authors' Addresses 408 Saikat Guha 409 Cornell University 410 331 Upson Hall 411 Ithaca, NY 14853 412 US 414 Email: saikat@cs.cornell.edu 416 Kaushik Biswas 417 Cisco Systems, Inc. 418 170 West Tasman Dr. 419 San Jose, CA 95134 420 US 422 Phone: +1 408 525 5134 423 Email: kbiswas@cisco.com 425 Bryan Ford 426 M.I.T. 427 Laboratory for Computer Science 428 77 Massachusetts Ave. 429 Cambridge, MA 02139 430 US 432 Phone: +1 617 253 5261 433 Email: baford@mit.edu 435 Paul Francis 436 Cornell University 437 4108 Upson Hall 438 Ithaca, NY 14853 439 US 441 Phone: +1 607 255 9223 442 Email: francis@cs.cornell.edu 443 Senthil Sivakumar 444 Cisco Systems, Inc. 445 7100-8 Kit Creek Road 446 PO Box 14987 447 Research Triangle Park, NC 27709-4987 448 US 450 Phone: +1 919 392 5158 451 Email: ssenthil@cisco.com 453 Pyda Srisuresh 454 Consultant 455 20072 Pacifica Dr. 456 Cupertino, CA 95014 457 US 459 Phone: +1 408 836 4773 460 Email: srisuresh@yahoo.com 462 Intellectual Property Statement 464 The IETF takes no position regarding the validity or scope of any 465 Intellectual Property Rights or other rights that might be claimed to 466 pertain to the implementation or use of the technology described in 467 this document or the extent to which any license under such rights 468 might or might not be available; nor does it represent that it has 469 made any independent effort to identify any such rights. Information 470 on the procedures with respect to rights in RFC documents can be 471 found in BCP 78 and BCP 79. 473 Copies of IPR disclosures made to the IETF Secretariat and any 474 assurances of licenses to be made available, or the result of an 475 attempt made to obtain a general license or permission for the use of 476 such proprietary rights by implementers or users of this 477 specification can be obtained from the IETF on-line IPR repository at 478 http://www.ietf.org/ipr. 480 The IETF invites any interested party to bring to its attention any 481 copyrights, patents or patent applications, or other proprietary 482 rights that may cover technology that may be required to implement 483 this standard. Please address the information to the IETF at 484 ietf-ipr@ietf.org. 486 Disclaimer of Validity 488 This document and the information contained herein are provided on an 489 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 490 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 491 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 492 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 493 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 496 Copyright Statement 498 Copyright (C) The Internet Society (2006). This document is subject 499 to the rights, licenses and restrictions contained in BCP 78, and 500 except as set forth therein, the authors retain all their rights. 502 Acknowledgment 504 Funding for the RFC Editor function is currently provided by the 505 Internet Society.