rfc3360.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/4 页

Network Working Group                                           S. Floyd
Request for Comments: 3360                                          ICIR
BCP: 60                                                      August 2002
Category: Best Current Practice


              Inappropriate TCP Resets Considered Harmful

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document is being written because there are a number of
   firewalls in the Internet that inappropriately reset a TCP connection
   upon receiving certain TCP SYN packets, in particular, packets with
   flags set in the Reserved field of the TCP header.  In this document
   we argue that this practice is not conformant with TCP standards, and
   is an inappropriate overloading of the semantics of the TCP reset.
   We also consider the longer-term consequences of this and similar
   actions as obstacles to the evolution of the Internet infrastructure.

1.  Introduction

   TCP uses the RST (Reset) bit in the TCP header to reset a TCP
   connection.  Resets are appropriately sent in response to a
   connection request to a nonexistent connection, for example.  The TCP
   receiver of the reset aborts the TCP connection, and notifies the
   application [RFC793, RFC1122, Ste94].

   Unfortunately, a number of firewalls and load-balancers in the
   current Internet send a reset in response to a TCP SYN packet that
   use flags from the Reserved field in the TCP header.  Section 3 below
   discusses the specific example of firewalls that send resets in
   response to TCP SYN packets from ECN-capable hosts.

   This document is being written to inform administrators of web
   servers and firewalls of this problem, in an effort to encourage the
   deployment of bug-fixes [FIXES].  A second purpose of this document
   is to consider the longer-term consequences of such middlebox
   behavior on the more general evolution of protocols in the Internet.



Floyd                    Best Current Practice                  [Page 1]

RFC 3360                Inappropriate TCP Resets             August 2002


2.  The history of TCP resets.

   This section gives a brief history of the use of the TCP reset in the
   TCP standards, and argues that sending a reset in response to a SYN
   packet that uses bits from the Reserved field of the TCP header is
   non-compliant behavior.

   RFC 793 contained the original specification of TCP in September,
   1981 [RFC793].  This document defined the RST bit in the TCP header,
   and explained that reset was devised to prevent old duplicate
   connection initiations from causing confusion in TCP's three-way
   handshake.  The reset is also used when a host receives data for a
   TCP connection that no longer exists.

   RFC 793 states the following, in Section 5:

   "As a general rule, reset (RST) must be sent whenever a segment
   arrives which apparently is not intended for the current connection.
   A reset must not be sent if it is not clear that this is the case."

   RFC 1122 "amends, corrects, and supplements" RFC 793.  RFC 1122 says
   nothing specific about sending resets, or not sending resets, in
   response to flags in the TCP Reserved field.

   Thus, there is nothing in RFC 793 or RFC 1122 that suggests that it
   is acceptable to send a reset simply because a SYN packet uses
   Reserved flags in the TCP header, and RFC 793 explicitly forbids
   sending a reset for this reason.

   RFC 793 and RFC 1122 both include Jon Postel's famous robustness
   principle, also from RFC 791: "Be liberal in what you accept, and
   conservative in what you send."  RFC 1122 reiterates that this
   robustness principle "is particularly important in the Internet
   layer, where one misbehaving host can deny Internet service to many
   other hosts."  The discussion of the robustness principle in RFC 1122
   also states that "adaptability to change must be designed into all
   levels of Internet host software".  The principle "be liberal in what
   you accept" doesn't carry over in a clear way (if at all) to the
   world of firewalls, but the issue of "adaptability to change" is
   crucial nevertheless.  The challenge is to protect legitimate
   security interests without completely blocking the ability of the
   Internet to evolve to support new applications, protocols, and
   functionality.








Floyd                    Best Current Practice                  [Page 2]

RFC 3360                Inappropriate TCP Resets             August 2002


2.1.  The TCP Reserved Field

   RFC 793 says that the Reserved field in the TCP header is reserved
   for future use, and must be zero.  A rephrasing more consistent with
   the rest of the document would have been to say that the Reserved
   field should be zero when sent and ignored when received, unless
   specified otherwise by future standards actions.  However, the
   phrasing in RFC 793 does not permit sending resets in response to TCP
   packets with a non-zero Reserved field, as is explained in the
   section above.

2.2.  Behavior of and Requirements for Internet Firewalls

   RFC 2979 on the Behavior of and Requirements for Internet Firewalls
   [RFC2979], an Informational RFC, contains the following:

   "Applications have to continue to work properly in the presence of
   firewalls.  This translates into the following transparency rule: The
   introduction of a firewall and any associated tunneling or access
   negotiation facilities MUST NOT cause unintended failures of
   legitimate and standards-compliant usage that would work were the
   firewall not present."

   "A necessary corollary to this requirement is that when such failures
   do occur it is incumbent on the firewall and associated software to
   address the problem: Changes to either implementations of existing
   standard protocols or the protocols themselves MUST NOT be
   necessary."

   "Note that this requirement only applies to legitimate protocol usage
   and gratuitous failures -- a firewall is entitled to block any sort
   of access that a site deems illegitimate, regardless of whether or
   not the attempted access is standards-compliant."

   We would note that RFC 2979 is an Informational RFC.  RFC 2026 on
   Internet Standards Process says the following in Section 4.2.2: "An
   `Informational' specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation" [RFC2026].

2.3.  Sending Resets as a Congestion Control Mechanism

   Some firewalls and hosts send resets in response to SYN packets as a
   congestion control mechanism, for example, when their listen queues
   are full.  These resets are sent without regard to the contents of
   the TCP Reserved field.  Possibly in response to the use of resets as





Floyd                    Best Current Practice                  [Page 3]

RFC 3360                Inappropriate TCP Resets             August 2002


   a congestion control mechanism, several popular TCP implementations
   immediately resend a SYN packet in response to a reset, up to four
   times.

   We would recommend that the TCP reset not be used as a congestion
   control mechanism, because this overloads the semantics of the reset
   message, and inevitably leads to more aggressive behavior from TCP
   implementations in response to a reset.  We would suggest that simply
   dropping the SYN packet is the most effective response to congestion.
   The TCP sender will retransmit the SYN packet, using the default
   value for the Retransmission Timeout (RTO), backing-off the
   retransmit timer after each retransmit.

2.4. Resets in Response to Changes in the Precedence Field

   RFC 793 includes the following in Section 5:

   "If an incoming segment has a security level, or compartment, or
   precedence which does not exactly match the level, and compartment,
   and precedence requested for the connection, a reset is sent and
   connection goes to the CLOSED state."

   The "precedence" refers to the (old) Precedence field in the (old)
   ToS field in the IP header.  The "security" and "compartment" refer
   to the obsolete IP Security option.  When it was written, this was
   consistent with the guideline elsewhere in RFC 793 that resets should
   only be sent when a segment arrives which apparently is not intended
   for the current connection.

   RFC 2873 on "TCP Processing of the IPv4 Precedence Field" discusses
   specific problems raised by the sending of resets when the precedence
   field has changed [RFC2873].  RFC 2873, currently a Proposed
   Standard, specifies that TCP must ignore the precedence of all
   received segments, and must not send a reset in response to changes
   in the precedence field.  We discuss this here to clarify that this
   issue never permitted the sending of a reset in response to a segment
   with a non-zero TCP Reserved field.

2.5. Resets in Response to Illegal Option Lengths

   RFC 1122 says the following in Section 4.2.2.5 about TCP options
   [RFC1122]:

   "A TCP MUST be able to receive a TCP option in any segment.  A TCP
   MUST ignore without error any TCP option it does not implement,
   assuming that the option has a length field (all TCP options defined





Floyd                    Best Current Practice                  [Page 4]

RFC 3360                Inappropriate TCP Resets             August 2002


   in the future will have length fields).  TCP MUST be prepared to
   handle an illegal option length (e.g., zero) without crashing; a
   suggested procedure is to reset the connection and log the reason."

   This makes sense, as a TCP receiver is unable to interpret the rest
   of the data on a segment that has a TCP option with an illegal option
   length.  Again, we discuss this here to clarify that this issue never
   permitted the sending of a reset in response to a segment with a
   non-zero TCP Reserved field.

3.  The Specific Example of ECN

   This section has a brief explanation of ECN (Explicit Congestion
   Notification) in general, and the ECN-setup SYN packet in particular.

   The Internet is based on end-to-end congestion control, and
   historically the Internet has used packet drops as the only method
   for routers to indicate congestion to the end nodes.  ECN is a recent
   addition to the IP architecture to allow routers to set a bit in the
   IP packet header to inform end-nodes of congestion, instead of
   dropping the packet.  ECN requires the cooperation of the transport
   end-nodes.

   The ECN specification, RFC 2481, was an Experimental RFC from January
   1999 until June 2001, when a revised document [RFC3168] was approved
   as Proposed Standard.  More information about ECN is available from
   the ECN Web Page [ECN].

   The use of ECN with TCP requires that both TCP end-nodes have been
   upgraded to support the use of ECN, and that both end-nodes agree to
   use ECN with this particular TCP connection.  This negotiation of ECN
   support between the two TCP end-nodes uses two flags that have been
   allocated from the Reserved field in the TCP header [RFC2481].

        0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |               |                       | U | A | P | R | S | F |