Network Working Group S. Guha Internet-Draft P. Francis Expires: March 5, 2006 Cornell University Sep 2005 NAT Behavioral Requirements for Unicast TCP draft-hoffman-behave-tcp-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a set of requirements for NATs that handle unicast TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Guha & Francis Expires March 5, 2006 [Page 1] Internet-Draft NAT TCP Unicast Requirements Sep 2005 1. Introduction [BEHAVE-UDP] defines many terms relating to NATs, lays out general requirements for all NATs, and sets requirements for NATs that handle unicast UDP traffic. This document is an adjunct to [BEHAVE-UDP] and sets requirements for NATs that handle unicast TCP traffic (that is, almost every NAT). All definitions and requirements in [BEHAVE-UDP] are inherited here. 2. Incoming and outgoing packets for an existing TCP session The TCP specification [RFC-TCP] defines several modes of session initiation and termination. Of these, 3-Way Handshake and Normal- Close are most commonly encountered in client-server applications and are supported by almost all NATs. However, not all NATs support Simultaneous-Open, which is used to set up TCP sessions in certain peer-to-peer applications. In the Simultaneous-Open mode of TCP session initiation, both endpoints send out SYN packets roughly at the same time. From a NAT's perspective, shortly after the internal endpoint sends out a SYN packet to an external endpoint, it receives an incoming SYN packet from that external endpoint. The two endpoints establish the session by responding with SYNACK packets; consequently, a NAT sees an outgoing SYNACK packet followed by an incoming SYNACK packet. Some NATs block the incoming SYN packet, some NATs block or mistranslate the outgoing SYNACK packet; this breaks TCP Simultaneous-Open and prevents peer-to-peer applications from functioning correctly behind a NAT. Some NATs prematurely reclaim session state before TCP finishes gracefully closing a session. In Simultaneous-Close, both endpoints send FIN packets at roughly the same time; upon receiving the other end's FIN each host responds with one final ACK packet. Some NATs reclaim session state after the FIN-exchange and block the final ACK packets; this causes the TCP socket at the endpoints to linger and re-send the FIN packets. REQ-1: A NAT MUST allow all valid sequences of TCP packets for a TCP session that does not violate the NAT's endpoint filtering behavior. In particular: a) A NAT MUST support TCP Simultaneous-Open. b) A NAT with "Endpoint independent filtering" or "Address dependent filtering" behavior MUST support incoming TCP 3-Way Handshake requests from appropriate external endpoints. Guha & Francis Expires March 5, 2006 [Page 2] Internet-Draft NAT TCP Unicast Requirements Sep 2005 c) A NAT MUST support TCP Simultaneous-Close. Justification: TCP Simultaneous-Open, Simultaneous-Close, etc are intentional design decisions, and a NAT must not impede them. 3. Incoming SYN packets for non-existent TCP sessions When a NAT filters an incoming SYN packet either because the corresponding mapping does not exist or because of its endpoint filtering policy, it has two basic choices: ignore the packet or signal an error. Ignoring the SYN can help some applications that perform TCP Simultaneous-Open. In TCP Simultaneous-Open, latency fluctuations may cause a NAT to receive the external endpoint's SYN before the internal endpoint has sent its SYN. Sending a TCP RST packet to signal this error aborts the attempt and forces the application to retry or give up. REQ-2: If a SYN packet sent to the external address of a NAT is filtered, the NAT MUST NOT send a TCP RST packet in response. Justification: Not sending an RST helps applications that use TCP Simultaneous-Open to establish a session, do so with greater ease. 4. Resource exhaustion and timers A NAT maintains state associated with new and established sessions. Because of this, a NAT is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the internal side attempts to cause the NAT to create more state than it has resources for. To prevent such an attack, a NAT needs to abandon sessions in order to free the state resources. A common method that is applicable only to TCP sessions is to preferentially abandon sessions for crashed endpoints, followed by closed TCP sessions and partially-open sessions. A NAT can check if an endpoint has crashed by sending a TCP keep-alive packet and checking the response. If the NAT cannot (or does not) determine whether the session is active, it should not abandon it until the session has been idle for some time. The time is derived from values recommended in [RFC-1122] and depends on the state of the TCP session. The states of a TCP session are defined in [RFC-TCP] and can be inferred by passively examining the TCP flags of incoming and outgoing packets for that session. A new session is considered partially-open until ACK packets are seen in both directions (TCP states: SYN_SENT, SYN_RCVD), and considered Guha & Francis Expires March 5, 2006 [Page 3] Internet-Draft NAT TCP Unicast Requirements Sep 2005 closed once FIN packets are seen in both directions (TCP states: CLOSING, LAST_ACK, TIME_WAIT). In between these two phases, application data can be exchanged over the TCP session (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT). REQ-3: If a NAT cannot determine whether the endpoints of a TCP session are active, it MAY abandon the session if it has been idle for some time. The NAT SHOULD wait for at least 2 hours before abandoning an idle TCP session in ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2 or CLOSE_WAIT states. A NAT SHOULD wait for at least 4 minutes before abandoning an idle TCP session in SYN_SENT, SYN_RCVD, CLOSING, LAST_ACK or TIME_WAIT states. a) When a NAT abandons an idle TCP session, it SHOULD send RST packets to each end of the session. Justification: If a NAT cannot determine whether the endpoint of an idle TCP session has crashed, the NAT should assume that the endpoint is active. However, to defend against DoS attacks, a NAT can abandon session state under certain circumstances while minimally impacting active endpoints. For idle TCP sessions where data can be exchanged (that is, once ACK packets are seen in both directions, and FIN packets have not been seen in both directions), endpoints send keep-alive packets at 2 hour intervals by default. For idle TCP sessions that are partially-open or closed, TCP waits 2xMSL (4 minutes) for in-flight packets to be delivered and acknowledged. If a NAT passively waits for at least this interval and does not see any packets for the TCP session, it can prematurely abandon the session without impacting most applications. Sending a TCP RST packet when abandoning a session can allow the application to recover in case the session was active. Receiving a TCP RST packet may instantly abort a session in any state. 5. Requirements A NAT that supports all of the mandatory requirements of this specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], is "compliant with this specification." A NAT that supports all of the requirements of this specification (i.e., included the "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully compliant with all the mandatory and recommended requirements of this specification." Guha & Francis Expires March 5, 2006 [Page 4] Internet-Draft NAT TCP Unicast Requirements Sep 2005 REQ-1: A NAT MUST allow all valid sequences of TCP packets for a TCP session that does not violate the NAT's endpoint filtering behavior. In particular: a) A NAT MUST support TCP Simultaneous-Open. b) A NAT with "Endpoint independent filtering" or "Address dependent filtering" behavior MUST support incoming TCP 3-Way Handshake requests from appropriate external endpoints. c) A NAT MUST support TCP Simultaneous-Close. REQ-2: If a SYN packet sent to the external address of a NAT is filtered, the NAT MUST NOT send a TCP RST packet in response. REQ-3: If a NAT cannot determine whether the endpoints of a TCP session are active, it MAY abandon the session if it has been idle for some time. The NAT SHOULD wait for at least 2 hours before abandoning an idle TCP session in ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2 or CLOSE_WAIT states. A NAT SHOULD wait for at least 4 minutes before abandoning an idle TCP session in SYN_SENT, SYN_RCVD, CLOSING, LAST_ACK or TIME_WAIT states. a) When a NAT abandons an idle TCP session, it SHOULD send RST packets to each end of the session. 6. Security considerations In addition to the security considerations addressed in [BEHAVE-UDP], there are additional concerns for handling TCP packets and are discussed in this section. Security considerations for REQ-1: This document requires that a NAT accept an incoming SYN packet in response to an outgoing SYN packet as long as the packet satisfies the endpoint filtering behavior of the NAT. That is, if a NAT has "Address and port dependent filtering" behavior, then it must not filter an incoming SYN from Y:y destined for the internal endpoint X:x if X:x has previously sent a SYN packet to Y:y. In order to provide extra security, some NATs filter such SYN packets and require that the external endpoint explicitly acknowledge the original SYN by replying with a SYNACK packet with the acknowledgment number field correctly populated. This attempts to protect against attackers that can blindly spoof SYN packets appearing to come from Y:y, but are not the recipient for packets addressed to Y:y. REQ-1 in this document does not prevent a NAT from providing the same security guarantees. Even after the incoming SYN is accepted, the external Guha & Francis Expires March 5, 2006 [Page 5] Internet-Draft NAT TCP Unicast Requirements Sep 2005 endpoint is required to explicitly acknowledge the internal endpoint's sequence number through a subsequent SYNACK or ACK packet as per the TCP specifications. The NAT can check the acknowledgment number in this subsequent packet to convince itself that the remote endpoint is indeed receiving packets addressed to Y:y and is not blindly spoofing packets. Security considerations for REQ-2: This document requires that if an incoming SYN packet is filtered, then the NAT must not send a TCP RST packet in response. Some NATs send RST packets in such situations in order to protect the NAT'ed hosts from being the victim of identity-theft attacks. In such an attack, the NAT is the rightful recipient of packets addressed to X:x, but an attacker blindly spoofs packets from X:x to some destination; if the NAT silently drops incoming packets from that destination then the attacker can potentially blindly spoof an entire TCP session and masquerade as the NAT'ed endpoint to the destination. REQ-2 does not prevent a NAT from providing security against such identity-theft by allowing it to send ICMP error packets (instead of TCP RST packets) to inform the destination's OS stack that it may be under attack. Security considerations for REQ-3: This document recommends that a NAT that passively monitors session state keep idle TCP sessions alive for at least 4 minutes for partially-open or closed sessions, and for at least 2 hours for established sessions. REQ-3 allows NATs that are under DoS attack to actively determine the state of a session by initiating TCP keep-alive packets and preferentially terminating closed or crashed sessions before the timers above expire. NAT implementations that change local state based on TCP flags in packets must ensure that out-of-window TCP packets are properly handled. Out-of-window TCP packets have been used in many attacks where an attacker can reset a TCP session by simply guessing the endpoint IP:port. If the window is too large, an attacker can send a small number of packets with selected sequence numbers such that one of these packets is considered an in-window packet that resets the session. 7. IANA considerations This document does not change or create any IANA-registered values. 8. Acknowledgments Thanks to Paul Hoffman for his many contributions to this document. Guha & Francis Expires March 5, 2006 [Page 6] Internet-Draft NAT TCP Unicast Requirements Sep 2005 9. Normative References [BEHAVE-UDP] Audet, F. and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", draft-ietf-behave-nat-udp (work in progress). [RFC-1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 793. [RFC-TCP] Postel, J., "Transmission Control Protocol", RFC 793. Authors' Addresses Saikat Guha Cornell University 331 Upson Hall Ithaca, NY 14853 US Email: saikat@cs.cornell.edu Paul Francis Cornell University 4108 Upson Hall Ithaca, NY 14853 US Email: francis@cs.cornell.edu Guha & Francis Expires March 5, 2006 [Page 7] Internet-Draft NAT TCP Unicast Requirements Sep 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Guha & Francis Expires March 5, 2006 [Page 8]