One document matched: draft-floyd-tcp-reset-00.txt
Internet Engineering Task Force Sally Floyd
INTERNET DRAFT ACIRI
draft-floyd-tcp-reset-00.txt May, 2001
Expires: November, 2001
Inappropriate TCP Resets Considered Harmful
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
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. We
further argue that this is a harmful practice that, by blocking off
things new or unknown, presents a significant obstacle 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
Floyd Informational [Page 1]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
receiver of the reset aborts the TCP connection, and notifies the
application [RFC793, RFC1122, Ste94].
Unfortunately, a number of web servers or firewalls 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 web servers or 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].
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."
This makes it clear that a reset must not be sent simply because a
TCP SYN packet uses one or more of the Reserved flags in the TCP
header.
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.
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
Floyd Informational [Page 2]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
levels of Internet host software".
In summary, 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.
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. This does not mean that RFC 793
condones sending resets in response to TCP packets with a non-zero
Reserved field. It does not, 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,
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
Floyd Informational [Page 3]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
are full. These resets are sent without regard to the contents of
the TCP Reserved field, and this document is not attempting to
address this use of resets one way or another.
2.4. Resets in Response to Changes in the Prececence 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 quideline 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 condoned 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
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
condoned the sending of a reset in response to a segment with a non-
zero TCP Reserved field.
Floyd Informational [Page 4]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
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 the
current Internet uses packet drops as the only method for routers to
indicate congestion to the end nodes. ECN is an 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, has been an Experimental standard
since January, 1999. As of the writing of this document, on May 3,
2001, we expect the revised ECN specification to advance to Proposed
Standard shortly. More information about the status of 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 |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: The standard definition of bytes 13 and 14 of the TCP
header.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: The definition of bytes 13 and 14 of the TCP Header from
RFC 2481.
The two ECN flags in the TCP header are defined from the last two
bits in the Reserved field of the TCP header. Bit 9 in the Reserved
field of the TCP header is designated as the ECN-Echo flag (ECE), and
Bit 8 is designated as the Congestion Window Reduced (CWR) flag. To
Floyd Informational [Page 5]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
negotiate ECN usage, the TCP sender sends an "ECN-setup SYN packet",
a TCP SYN packet with the ECE and CWR flags set. If the TCP host at
the other end wishes to use ECN for this connection, then it sends an
"ECN-setup SYN-ACK packet", a TCP SYN packet with the ECE flag set
and the CWR flag not set. Otherwise, the TCP host at the other end
returns a SYN-ACK packet with neither the ECE nor the CWR flag set.
So now back to TCP resets. When a TCP host negotiating ECN sends an
ECN-setup SYN packet, an old TCP implementation is expected to ignore
those flags in the Reserved field, and to send a plain SYN-ACK packet
in response. However, there are some broken web firewalls, load-
balancers, and/or web servers in the Internet that instead respond to
an ECN-setup SYN packet with a reset. This has been investigated by
the Linux community, and by the TBIT project [TBIT] in data taken
from September, 2000, up to April, 2001, and has been discussed in an
article in Enterprise Linux Today [Cou01]. Some of the offending
equipment has been identified, and a web page [FIXES] contains a list
of non-compliant products and the fixes posted by the vendors, where
these are available.
3.1. ECN: The Alternative to Fixing the Broken Equipment
A work-around for maintaining connectivity in the face of the broken
equipment has been described in [Floyd00]. We describe this work-
around briefly below. TCP implementors have so far decided not to
deploy these workarounds, for the following reasons:
* The work-arounds would result in ECN-capable hosts ignoring the
first valid reset received in response to a SYN packet. This would
not be conformant with current standards.
* The work-arounds would limit ECN functionality in environments
without broken equipment, by disabling ECN where the first SYN or
SYN-ACK packet was dropped in the network.
* The work-arounds in many cases would involve a delay of six seconds
or more before connectivity is established with the remote server, in
the case of broken equipment that drops ECN-setup SYN packets. By
accommodating this broken equipment, the work-arounds have been
judged as implicitly accepting both this delay and the broken
equipment that would be causing this delay.
One possibility would be for such work-arounds to be configurable by
the user. For completeness, we describe the possible work-arounds
below.
To provide robust connectivity even in the presence of faulty
equipment, a TCP host that receives a reset in response to the
Floyd Informational [Page 6]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
transmission of an ECN-setup SYN packet could resend the SYN with CWR
and ECE cleared. This would result in a TCP connection being
established without using ECN. This would also have the unfortunate
result of the first valid reset being ignored by the ECN-capable TCP
host. If a second reset was sent in response to the second SYN,
which had CWR and ECE cleared, this second reset would not be ignored
by the TCP host.
Similarly, a host that receives no reply to an ECN-setup SYN within
the normal SYN retransmission timeout interval could resend the SYN
and any subsequent SYN retransmissions with CWR and ECE cleared. To
overcome normal packet loss that results in the original SYN being
lost, the originating host could retransmit one or more ECN-setup SYN
packets before giving up and retransmitting the SYN with the CWR and
ECE bits cleared.
4. On Combatting Obstacles to the Proper Evolution of the Internet
Infrastructure
One of the reasons that this issue of inappropriate resets is
important is that it interferes with the deployment of ECN in the
Internet. My own belief is that ECN is a useful and potentially
valuable addition to the IP architecture, and it would be a pity if
its deployment was compromised or delayed because of the widespread
existence of broken equipment in the Internet.
A second, more general reason why this issue is important is that the
presence of equipment in the Internet that rejects valid TCP packets
limits the future evolution of TCP, completely aside from the issue
of ECN. That is, the widespread deployment of equipment that rejects
TCP packets that use Reserved flags in the TCP header effectively
prevents the deployment of new mechanisms that use any of these
Reserved flags. (It doesn't matter if these new mechanisms have the
protection of Experimental or Proposed Standard status from the IETF
in this case, because the broken equipment in the Internet does not
stop to look up the current status of the protocols before rejecting
the packets.) TCP is good, and useful, but it would be a pity for
the deployment of broken equipment in the Internet to result in the
"freezing" of TCP in its current state, with the inability to use the
Reserved flags in the future evolution of TCP.
Taking the wider view, the existence of web servers or firewalls that
send inappropriate resets is only one example of functionality in the
Internet that inappropriately restricts the future evolution of the
Internet. The impact of all of these restrictions taken together
presents considerable obstacles to the development of the Internet
architecture.
Floyd Informational [Page 7]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
5. Conclusions
Our conclusion is that it is not conformant with current standards
for a firewall, load-balancer, or web-server to respond with a reset
to a TCP SYN packet simply because the packet uses flags in the TCP
Reserved field. More specifically, it is not conformant to respond
with a reset to a TCP SYN packet simply because the ECE and CWR flags
are set in the IP header. We would urge vendors to make available
fixes for any nonconformant code, and we could urge ISPs and system
administrators to deploy these fixes in their web servers and
firewalls.
The companion document to this, "Arbitrarily Discarding TCP SYN
Packets Considered Harmful", should be available shortly.
6. Acknowledgements
This has been the result of discussions and activity by many people,
so I will refrain from trying to acknowledge all of them here. My
specific thanks go to Jamal Hadi Salim, Mark Handley, Allison Mankin,
Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Alex Snoeren, and
Dan Wing for feedback on this document.
7. References
[Cou01] Scott Courtney, Why Can't My 2.4 Kernel See Some Web Sites?,
Enterprise Linux Today, Apr 17, 2001. URL
"http://eltoday.com/article.php3?ltsn=2001-04-17-001-14-PS".
Reference for informational purposes only.
[ECN] "The ECN Web Page", URL "http://www.aciri.org/floyd/ecn.html".
Reference for informational purposes only.
[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL
"http://gtf.org/garzik/ecn/". Reference for informational purposes
only.
[Floyd00] Sally Floyd, Negotiating ECN-Capability in a TCP
connection, October 2, 2000, email to the end2end-interest mailing
list. URL "http://www.aciri.org/floyd/papers/ECN.Oct2000.txt".
[HPK01] Mark Handley, Vern Paxson, and Christian Kreibich, Network
Intrusion Detection: Evasion, Traffic Normalization, and End-to-End
Protocol Semantics, May 2001. Draft paper. Reference for
acknowledgement purposes only.
[QUESO] Toby Miller, Intrusion Detection Level Analysis of Nmap and
Queso, August 30, 2000. URL "http://www.securityfocus.com/
Floyd Informational [Page 8]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
frames/?focus=ids&content=/focus/ids/articles/portscan.html".
Reference for informational purposes only.
[RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2026] S. Bradner, The Internet Standards Process -- Revision 3,
RFC 2026, BCP 9, October 1996.
[RFC2481] K. K. Ramakrishnan and S. Floyd, A Proposal to add Explicit
Congestion Notification (ECN) to IP, RFC 2481, January 1999.
[RFC2873] Xiao, X., Hannan, A., Paxson, V., and Crabbe, E., TCP
Processing of the IPv4 Precedence Field, RFC 2873, June 2000.
Proposed Standard.
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols",
Addison-Wesley, 1994.
[TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP Behavior
of Web Servers, ICSI TR-01-002, February 2001. URL
"http://www.aciri.org/tbit/".
8. Security Considerations
Unfortunately, misconceived security concerns are one of the reasons
for the broken equipment described in this document in the first
place. An August, 2000, article on "Intrusion Detection Level
Analysis of Nmap and Queso" described the port-scanning tool Queso as
sending SYN packets with the last two Reserved bits in the TCP header
set, and said the following: "[QUESO] is easy to identify, if you
see [these two Reserved bits and the SYN bit] set in the 13th byte of
the TCP header, you know that someone has malicious intentions for
your network." Security protection that results in rejecting TCP SYN
packets that use Reserved flags in the TCP header, just because some
port-scanning tool also used those flags, is not doing much of a
service to the network. If we can't do any better than security that
involves rejecting anything new or unknown, then we are in pretty bad
shape, I would say.
Security considerations have also been discussed in Section 2.2.
Floyd Informational [Page 9]
draft-floyd-tcp-reset Inappropriate TCP Resets May 2001
9. IANA Considerations
There are no IANA considerations in this document.
AUTHORS' ADDRESSES
Sally Floyd
Phone: +1 (510) 666-2989
ACIRI (AT&T Center for Internet Research at ICSI)
Email: floyd@aciri.org
URL: http://www.aciri.org/floyd/
This draft was created in May 2001.
It expires November 2001.
Floyd Informational [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 05:59:28 |