[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/