[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                                                Cornell U.
Expires: August 5, 2006                                        K. Biswas
                                                           Cisco Systems
                                                                 B. Ford
                                                                  M.I.T.
                                                              P. Francis
                                                              Cornell U.
                                                            S. Sivakumar
                                                           Cisco Systems
                                                            P. Srisuresh
                                                              Consultant
                                                                Feb 2006


              NAT Behavioral Requirements for Unicast TCP
                    draft-hoffman-behave-tcp-04.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 August 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract



Guha, et al.             Expires August 5, 2006                 [Page 1]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


   This document defines a set of requirements for NATs that handle 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.

Table of Contents

   1.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  TCP Session Setup  . . . . . . . . . . . . . . . . . . . . . .  4
     4.1   Address and Port Mapping . . . . . . . . . . . . . . . . .  4
     4.2   Internally Initiated Sessions  . . . . . . . . . . . . . .  4
     4.3   Externally Initiated Sessions  . . . . . . . . . . . . . .  5
   5.  TCP Session Refresh  . . . . . . . . . . . . . . . . . . . . .  6
   6.  Application Level Gateways . . . . . . . . . . . . . . . . . .  7
   7.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
   9.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  9
   11.   Normative References . . . . . . . . . . . . . . . . . . . .  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 12



























Guha, et al.             Expires August 5, 2006                 [Page 2]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


1.  Applicability Statement

   This document is adjunct to RFC FIXME-BEHAVE-UDP [1], which defines
   many terms relating to NATs, lays out general requirements for all
   NATs, and sets requirements for NATs that handle unicast UDP traffic.
   The purpose of this document is to set requirements for NATs that
   handle TCP traffic (that is, almost every NAT).

   The requirements of this specification apply to Traditional NATs as
   described in RFC 2663 [2].

   This document only covers the TCP aspects of NAT traversal.
   Firewalls, and packet inspection above the TCP layer are out-of-
   scope.  Middle-box behavior that is not necessary for network address
   translation of TCP is out-of-scope.  Application and OS aspects of
   TCP NAT traversal are out-of-scope.  Signaling based approaches to
   NAT traversal such as Midcom and UPnP that directly control the NAT
   are out-of-scope.

2.  Introduction

   Network Address Translators (NATs) hinder connectivity in
   applications where connections may be initiated to internal hosts.
   RFC FIXME-BEHAVE-UDP [1] lays out the terminology and requirements
   for NATs in the context of UDP.  This document supplements these by
   setting requirements for NATs that handle TCP traffic.  All
   definitions and requirements in [1] are inherited here.

   Recently, many techniques have been devised to make peer-to-peer TCP
   applications work across NATs.  STUNT [3], NATBLASTER [4], and P2PNAT
   [5] describe UNilateral Self-Address Translation (UNSAF) mechanisms
   to establish TCP through NATs by modifying only endpoints.  These
   approaches depend on specific NAT behavior that is not always
   supported (see [6] and [5] for details).  Consequently a complete TCP
   NAT Traversal solution is sometimes forced to rely on public TCP
   Relays.  This document defines requirements that ensures that TCP NAT
   Traversal approaches are not forced to use data relays.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [7].

   This document uses the term "session" as defined in RFC 2663 [2].
   "NAT" in this specification includes both "Basic NAT" and "Network
   Address/Port Translator (NAPT)" [2].




Guha, et al.             Expires August 5, 2006                 [Page 3]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


   This document uses the terms "address and port mapping", "endpoint
   independent mapping", "filtering behavior", "endpoint independent
   filtering", "address dependent filtering" and "address and port
   dependent filtering" as defined in RFC FIXME-BEHAVE-UDP [1].

4.  TCP Session Setup

   This section describes various NAT behaviors applicable to TCP
   session setup.

4.1  Address and Port Mapping

   RFC FIXME-BEHAVE-UDP [1] defines the criteria for the re-use of a
   mapping for new sessions.  The definition presented there is agnostic
   of the transport protocol used and applies directly to TCP.

   REQ-1: A NAT MUST have an "External NAT mapping is endpoint
      independent" behavior.

   Justification: REQ-1 is necessary for UNSAF methods to work.  Refer
      to REQ-1 in [1] for details.

4.2  Internally Initiated Sessions

   An internal endpoint initiates a TCP session through a NAT by sending
   a SYN packet.  The NAT assigns an external IP address and port number
   for the session so the resulting SYNACK response can be received,
   translated and routed to the internal endpoint.  This translation is
   used for the subsequent ACK and other packets for the duration of the
   session.  This corresponds to the 3-Way Handshake mode of session
   initiation defined in RFC 793 [8] and is supported by all NATs.

   RFC 793 defines an alternate mode of session initiation, termed
   Simultaneous-Open, which is used by peer-to-peer applications to
   traverse NATs.  In the Simultaneous-Open mode of operation, both
   endpoints send SYN packets that cross in the network, followed by
   SYNACK packets that cross in the network.  From the perspective of
   the NAT, the internal host's SYN packet is responded by an inbound
   SYN packet for the same session (as opposed to a SYNACK packet).
   Subsequent to this exchange, both an outbound and inbound SYNACK are
   seen for the session.  Some NATs block the inbound SYN for the
   session; some NATs block or incorrectly translate the outbound
   SYNACK.  Such behavior breaks TCP Simultaneous-Open and prevents
   peer-to-peer applications from functioning correctly behind a NAT.

   In order to provide network address translation service for TCP, it
   is necessary for a NAT to correctly receive, translate, and forward
   all packets for a session that conforms to valid transitions of the



Guha, et al.             Expires August 5, 2006                 [Page 4]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


   TCP State-Machine [8].

   REQ-2: For a TCP session, a NAT MUST support all valid sequences of
      TCP packets as defined in RFC 793.  In particular:
      a) A NAT MUST support TCP Simultaneous-Open.

   Justification: This requirement enables standards compliant TCP
      stacks to traverse NATs.

4.3  Externally Initiated Sessions

   When an internal endpoint initiates a session, the NAT assigns an
   external IP:port.  Some peer-to-peer applications let other external
   endpoints initiate a TCP session to the internal endpoint by sending
   a SYN to the external IP:port allocated.  Such applications depend on
   the NAT to reuse the mapping and route the SYN to the internal
   endpoint.  The internal endpoint replies with a SYNACK packet that
   the NAT is expected to translate and forward to the external
   endpoint, which responds with an ACK to complete the initiation.  The
   filtering behavior of the NAT, defined in [1], governs which external
   endpoints are allowed to send inbound SYN packets for a new session.

   REQ-3: A NAT with "Endpoint independent filtering" or "Address
      dependent filtering" behavior MUST support TCP session initiations
      from the specific external endpoints.  Note that this requirement
      is not applicable to NATs that have "Address and port dependent
      filtering" behavior.

   Justification: This is to avoid breaking peer-to-peer applications
      which do not always initiate sessions from the internal side of
      the NAT.

   If the inbound SYN packet is filtered, either because a corresponding
   mapping does not exist or because of the NAT's filtering behavior, a
   NAT has two basic choices: to ignore the packet silently, or signal
   an error to the sender.  Ignoring the SYN helps applications perform
   TCP Simultaneous-Open in the presence of clock skew and network
   congestion where the inbound SYN may arrive at the NAT before the
   outbound SYN creates the necessary session state.

   REQ-4: It is RECOMMENDED that a NAT silently discard inbound SYN
      packets that are filtered or cannot be routed.

   Justification: This allows applications to traverse NATs with greater
      ease.






Guha, et al.             Expires August 5, 2006                 [Page 5]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


5.  TCP Session Refresh

   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 for the response.  If the NAT cannot 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 [9].  The states of a TCP session that these values
   correspond to are defined in RFC 793 [8] and can be inferred by
   passively examining the TCP flags of inbound and outbound packets for
   that session.

   The established session timer is defined as the time a mapping will
   stay active for a session over which application data can be
   exchanged.  Application data can be exchanged over a TCP session in
   states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and CLOSE_WAIT.

   The transitory session timer is defined as the time a mapping will
   stay active for a session over which application data cannot yet be
   exchanged, or can no longer be exchanged.  This includes partially-
   open TCP sessions in states: SYN_SENT and SYN_RCVD, and closed
   sessions in states: CLOSING, LAST_ACK, and TIME_WAIT.

   REQ-5: 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.  A default value of 2 hours for the established
      session timer is RECOMMENDED.  A default value of 4 minutes for
      the transitory session timer is RECOMMENDED.
      a) The value of the NAT TCP session timers MAY be configurable.

   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), some endpoints send keep-alive packets at 2 hour
      intervals by default.  For idle TCP sessions that are partially-



Guha, et al.             Expires August 5, 2006                 [Page 6]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


      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.  NAT behavior for handling RST packets for a
      session is left undefined.
      a) Configuration helps troubleshoot and accommodate specific
         applications.

6.  Application Level Gateways

   FIXME OPEN ISSUE: Is this out-of-scope?  Do we need to specify all
   TCP ALGs should be off by default?  What about FTP?

7.  Requirements

   A NAT that supports all of the mandatory requirements of this
   specification (i.e., the "MUST") and is compliant with [1], 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 [1] is "fully compliant with all the
   mandatory and recommended requirements of this specification."

   REQ-1: A NAT MUST have an "External NAT mapping is endpoint
      independent" behavior.
   REQ-2: For a TCP session, a NAT MUST support all valid sequences of
      TCP packets as defined in RFC 793.  In particular:
      a) A NAT MUST support TCP Simultaneous-Open.
   REQ-3: A NAT with "Endpoint independent filtering" or "Address
      dependent filtering" behavior MUST support TCP session initiations
      from the specific external endpoints.  Note that this requirement
      is not applicable to NATs that have "Address and port dependent
      filtering" behavior.
   REQ-4: It is RECOMMENDED that a NAT silently discard inbound SYN
      packets that are filtered or cannot be routed.
   REQ-5: 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.  A default value of 2 hours for the established
      session timer is RECOMMENDED.  A default value of 4 minutes for
      the transitory session timer is RECOMMENDED.
      a) The value of the NAT TCP session timers MAY be configurable.

8.  Security considerations

   In addition to the security considerations addressed in [1], there
   are additional concerns for handling TCP packets and are discussed in
   this section.




Guha, et al.             Expires August 5, 2006                 [Page 7]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


   Security considerations for REQ-1: This requirement does not
      introduce any TCP-specific concerns in addition to those already
      addressed in [1].
   Security considerations for REQ-2: This document requires that a NAT
      accept an inbound SYN packet for a session in response to the
      outbound SYN packet.  In order to provide extra security, some
      NATs require the ACK flag to be set in all inbound packets.  This
      attempts to protect against attackers that can blindly spoof SYN
      packets appearing to come from the external destination, but are
      not able to receive, and therefore acknowledge, packets addressed
      to the same.  REQ-2 in this document does not prevent a NAT from
      providing the same security guarantees.  Even after the inbound
      SYN is accepted, the external endpoint is required by the TCP
      specification to explicitly acknowledge the internal endpoint's
      sequence number through a subsequent SYNACK or ACK packet.  The
      NAT can check these subsequent packets to thwart such spoofing
      attacks.
   Security considerations for REQ-3: The security provided by the NAT
      is governed by its filtering behavior as addressed in [1].
      Allowing TCP sessions to be initiated by endpoints in accordance
      with the filtering behavior does not introduce additional
      concerns.
   Security considerations for REQ-4: This document recommends that if
      an inbound SYN packet is filtered, then the NAT should silently
      discard it.  Some NATs send TCP RST or ICMP errors in response to
      filtered packets.  This serves to protect the NAT'ed hosts from
      identity-theft attacks.  In such an attack, the NAT is the
      rightful recipient for an address, but an attacker blindly spoofs
      packets from this address.  If the NAT silently drops unexpected
      inbound packets then the attacker can potentially spoof an entire
      TCP session and masquerade as the NAT'ed endpoint.  REQ-4 allows a
      NAT to respond to such attacks by sending error packets for
      unexpected non-SYN packets that follow the SYN packet.
   Security considerations for REQ-5: 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 by
      default.  If a NAT is under a DoS attack, the NAT administrator
      may configure session timeouts accordingly, or let the NAT
      actively determine session state.

   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 are sometimes used in attacks
   where an attacker resets arbitrary TCP sessions by guessing only the
   endpoint IP addresses and ports.  If the window is too large, an
   attacker can send a small number of packets with crafted sequence
   numbers such that one of these packets is considered an in-window



Guha, et al.             Expires August 5, 2006                 [Page 8]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


   packet that resets the session.

9.  IANA considerations

   This document does not change or create any IANA-registered values.

10.  Acknowledgments

   Thanks to Paul Hoffman for his many contributions to this document.

11.  Normative References

   [1]  Audet, F. and C. Jennings, "NAT Behavioral Requirements for
        Unicast UDP", draft-ietf-behave-nat-udp (work in progress).

   [2]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
        (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [3]  Guha, S. and P. Francis, "NUTSS: A SIP based approach to UDP and
        TCP connectivity", Proceedings of the ACM SIGCOMM Workshop on
        Future Directions in Network Architecture (Portland, OR),
        August 2004.

   [4]  Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig,
        "NATBLASTER: Establishing TCP connections between hosts behind
        NATs", Proceedings of the ACM SIGCOMM Asia Workshop (Beijing,
        China), April 2005.

   [5]  Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer
        communication across network address translators", Proceedings
        of the USENIX Annual Technical Conference (Anaheim, CA),
        April 2005.

   [6]  Guha, S. and P. Francis, "Characterization and Measurement of
        TCP Traversal through NATs and Firewalls", Proceedings of the
        Internet Measurement Conference (Berkeley, CA), October 2005.

   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [8]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [9]  Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1122, October 1989.






Guha, et al.             Expires August 5, 2006                 [Page 9]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


Authors' Addresses

   Saikat Guha
   Cornell University
   331 Upson Hall
   Ithaca, NY  14853
   US

   Email: saikat@cs.cornell.edu


   Kaushik Biswas
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 525 5134
   Email: kbiswas@cisco.com


   Bryan Ford
   M.I.T.
   Laboratory for Computer Science
   77 Massachusetts Ave.
   Cambridge, MA  02139
   US

   Phone: +1 617 253 5261
   Email: baford@mit.edu


   Paul Francis
   Cornell University
   4108 Upson Hall
   Ithaca, NY  14853
   US

   Phone: +1 607 255 9223
   Email: francis@cs.cornell.edu











Guha, et al.             Expires August 5, 2006                [Page 10]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


   Senthil Sivakumar
   Cisco Systems, Inc.
   7100-8 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709-4987
   US

   Phone: +1 919 392 5158
   Email: ssenthil@cisco.com


   Pyda Srisuresh
   Consultant
   20072 Pacifica Dr.
   Cupertino, CA  95014
   US

   Phone: +1 408 836 4773
   Email: srisuresh@yahoo.com
































Guha, et al.             Expires August 5, 2006                [Page 11]


Internet-Draft        NAT TCP Unicast Requirements              Feb 2006


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 (2006).  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, et al.             Expires August 5, 2006                [Page 12]


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