Inappropriate TCP Resets Considered Harmful
RFC 3360

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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