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]