[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-behave-tcp

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/