RFC 3360 (rfc3360) - Page 2 of 19

Inappropriate TCP Resets Considered Harmful

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 [RFC 793].  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