Inappropriate TCP Resets Considered Harmful
RFC 3360
| Document | Type |
RFC - Best Current Practice
(August 2002; No errata)
Also known as BCP 60
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | Legacy | ||
| Formats | plain text pdf html bibtex | ||
| Stream | Legacy state | (None) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | RFC 3360 (Best Current Practice) | |
| Telechat date | |||
| Responsible AD | Steven Bellovin | ||
| IESG note | Responsible: Finished | ||
| Send notices to | (None) | ||
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
Show full document text