Internet Engineering Task Force Sally Floyd INTERNET DRAFT ACIRI draft-floyd-tcp-reset-01.txt June, 2001 Expires: December, 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 presents an unnecessary 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 receiver of the reset aborts the TCP connection, and notifies the Floyd Informational [Page 1] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 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. 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 Floyd Informational [Page 2] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 also states that "adaptability to change must be designed into all 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. A rephrasing more consistent with the rest of the document would have been to say that the Reserved field should be zero when sent and ignored when received, unless specified otherwise by future standards actions. However, the phrasing in RFC 793 does not condone sending resets in response to TCP packets with a non-zero Reserved field, 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]. Floyd Informational [Page 3] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 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 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 Precedence 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 guideline 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 Floyd Informational [Page 4] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 condoned the sending of a reset in response to a segment with a non- zero TCP Reserved field. 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, was an Experimental standard from January, 1999 until June 12, 2001, when the revised document [RFB01] was approved by the IESG for Proposed Standard. 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 Floyd Informational [Page 5] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 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 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 and load- balancers 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 June, 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. On the day after ECN was approved as Proposed Standard, there were still many sites sending resets in response to conformant ECN-setup SYN packets, and I would imagine that this could remain the case for some time. Installing software that blocks packets using flags in TCP's Reserved field is considerably easier than uninstalling that software later on. 3.1. ECN: The Work-Around. A work-around for maintaining connectivity in the face of the broken equipment was been described in [Floyd00], and has been specified in the ECN standards document as a procedure that may be included in TCP implementations. We describe this work-around briefly below. To provide robust connectivity even in the presence of faulty equipment, a TCP host that receives a reset in response to the transmission of an ECN-setup SYN packet may resend the SYN with CWR and ECE cleared. This would result in a TCP connection being established without using ECN. This also has the unfortunate result of the first valid reset being ignored by the ECN-capable TCP host. If a second reset is 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 may 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 Floyd Informational [Page 6] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 lost, the originating host may retransmit one or more ECN-setup SYN packets before giving up and retransmitting the SYN with the CWR and ECE bits cleared. 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. * 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. One unavoidable consequence of the work-around of resending a modified SYN packet in response to a reset is to further erode the semantics of the TCP reset. Thus, when a box sends a reset, the TCP host receiving that reset does not know if the reset was sent simply because of the ECN-related flags in the TCP header, or because of some more fundamental problem. Therefore, the TCP host resends the TCP SYN packet without the ECN-related flags in the TCP header. The ultimate consequence of this absence of clear communications from the middlebox to the end-nodes could be an extended spiral of communications specified for transport protocols, as end nodes attempt to sacrifice as little functionality as possible in the process of determining which packets will and will not be forwarded to the other end. 4. On Combating Obstacles to the Proper Evolution of the Internet Infrastructure One of the reasons that this issue of inappropriate resets is important (to me) is that it has complicated the deployment of ECN in the Internet (though it has fortunately not blocked the deployment completely). It has also added an unnecessary obstacle to the future effectiveness of ECN. Floyd Informational [Page 7] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 However, 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 could effectively prevent 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, without the ability to use the Reserved flags in the future evolution of TCP. In the specific case of middleboxes that block TCP SYN packets attempting to negotiate ECN, the work-around described in Section 3.1 is sufficient to ensure that end-nodes could still establish connectivity. However, there are likely to be additional uses of the TCP Reserved Field standardized in the next year or two, and these additional uses might not coexist quite as successfully with middleboxes that send resets. Consider the difficulties that could result if a path changes in the middle of a connection's lifetime, and the middleboxes on the old and new paths have different policies about exactly which flags in the TCP Reserved field they would and would not block. 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 small restrictions taken together presents a considerable obstacle to the development of the Internet architecture. 5. Issues for Transport Protocols One lesson for designers of transport protocols is that transport protocols will have to protect themselves from the unknown and seemingly arbitrary actions of firewalls, normalizers, and other middleboxes in the network. For the moment, for TCP, this means sending a non-ECN-setup SYN when a reset is received in response to an ECN-setup SYN packet. Defensive actions on the side of transport protocols could include using Reserved flags in the SYN packet before using them in data traffic, to protect against middleboxes that block packets using those flags. It is possible that transport protocols will also have to add additional checks during the course of the connection lifetime to check for interference from middleboxes along the path. Floyd Informational [Page 8] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 Transport protocols will also have to respond in some fashion to an ICMP code of "Communication Administratively Prohibited" if middleboxes start to use this form of the ICMP Destination Unreachable message to indicate that the packet is using functionality not allowed [RFC1812]. 6. Issues for Middleboxes Given that some middleboxes are going to drop some packets because they use functionality not allowed by the middlebox, the larger issue remains of how middleboxes should communicate the reason for this action to the end-nodes. Our suggestion would be that firewalls send an ICMP Destination Unreachable message with the code "Communication Administratively Prohibited". We acknowledge that this is not an ideal solution, for several reasons. First, middleboxes along the reverse path might block these ICMP messages. Second, some firewall operators object to explicit communication because it simplifies fingerprinting. And third, the response of transport protocols to such an ICMP message is not yet specified. However, an ICMP "Administratively Prohibited" message still seems the best fit to the situation. We would note that this document does not consider middleboxes that block complete transport protocols. This document is only considering the problems caused by middleboxes that block specific packets within a transport protocol when other packets from that transport protocol are forwarded by the middlebox unaltered. 7. 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. I don't claim that it violates some standard for middleboxes to arbitrarily drop packets that use flags in the TCP Reserved field, but I would argue that behavior of this kind, without a clear method for informing the end-nodes of the reasons for these actions, could present a significant obstacle to the development of TCP. Floyd Informational [Page 9] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 8. Acknowledgements This document results from discussions and activity by many people, so I will refrain from trying to acknowledge all of them here. My specific thanks go to Alex Cannara, Dennis Ferguson, Mark Handley, Allison Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Jamal Hadi Salim, Alex Snoeren, and Dan Wing for feedback on this document, and to the End-to-End Research Group for discussion of these issues. I also thank the members of the Firewall Wizards mailing list for feedback (generally of disagreement) on an earlier draft of this document. Email discussions with a number of people, including Mark Handley, Dax Kelson, Alexey Kuznetsov, Jitentra Padhye, Kacheong Poon, David Reed, Jamal Hadi-Salim, and Venkat Venkatsubra, have addressed the issues raised by non-conformant equipment in the Internet that does not respond to TCP SYN packets with the ECE and CWR flags set. 9. 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/ frames/?focus=ids&content=/focus/ids/articles/portscan.html". Reference for informational purposes only. [RFB01] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, draft-ietf-tsvwg- Floyd Informational [Page 10] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 ecn-04.txt, work in progress, June 2001. Approved for Proposed Standard on June 12, 2001. [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. [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [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/". 10. Security Considerations I am not aware of any security risks from the use of the Reserved flags in the TCP header. Security considerations have also been discussed in Section 2.2. The traditional concern of firewalls is to prevent unauthorized access to systems, and to prevent DoS attacks and other attacks from subverting the end-user terminal, and I am not aware of any such risks associated with the use of Reserved flags in the TCP header. To the extent that firewalls also exist to protect end systems from buggy code, it is certainly possible that an implementation of TCP could appear that has buggy code associated with the use of Reserved flags in the TCP header. I am not aware of any such implementation at the moment. I am also not aware of any security risks that would result from middleboxes sending ICMP "Administratively Prohibited" messages. 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 Floyd Informational [Page 11] draft-floyd-tcp-reset Inappropriate TCP Resets May 2001 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." As is documented on the TBIT Web Page, the middleboxes that block SYNs using the two ECN-related Reserved flags in the TCP header do not block SYNs using other Reserved flags in the TCP header. One lesson appears to be that anyone can effectively ``attack'' a new TCP function simply by using that function in their publicly- available port-scanning tool, thus causing middleboxes of all kinds to block the use of that function. 11. 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 June 2001. It expires December 2001. Floyd Informational [Page 12]