diff options
Diffstat (limited to 'doc/rfc/rfc3360.txt')
| -rw-r--r-- | doc/rfc/rfc3360.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3360.txt b/doc/rfc/rfc3360.txt new file mode 100644 index 0000000..af27470 --- /dev/null +++ b/doc/rfc/rfc3360.txt @@ -0,0 +1,1067 @@ + + + + + + +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 + 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 permit 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 + [RFC2979], 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 + are full. These resets are sent without regard to the contents of + the TCP Reserved field. Possibly in response to the use of resets as + + + + + +Floyd Best Current Practice [Page 3] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + a congestion control mechanism, several popular TCP implementations + immediately resend a SYN packet in response to a reset, up to four + times. + + We would recommend that the TCP reset not be used as a congestion + control mechanism, because this overloads the semantics of the reset + message, and inevitably leads to more aggressive behavior from TCP + implementations in response to a reset. We would suggest that simply + dropping the SYN packet is the most effective response to congestion. + The TCP sender will retransmit the SYN packet, using the default + value for the Retransmission Timeout (RTO), backing-off the + retransmit timer after each retransmit. + +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 permitted 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 + + + + + +Floyd Best Current Practice [Page 4] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + 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 + permitted 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 + historically the Internet has used packet drops as the only method + for routers to indicate congestion to the end nodes. ECN is a recent + 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 RFC from January + 1999 until June 2001, when a revised document [RFC3168] was approved + as Proposed Standard. More information about 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 previous definition of bytes 13 and 14 of the TCP + header. + + + + + + + + +Floyd Best Current Practice [Page 5] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + 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 current definition of bytes 13 and 14 of the TCP + Header, from RFC 3168. + + 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 + 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 firewalls and load- + balancers in the Internet that instead respond to an ECN-setup SYN + packet with a reset. Following the deployment of ECN-enabled end + nodes, there were widespread complaints that ECN-capable hosts could + not access a number of websites [Kelson00]. This has been + investigated by the Linux community, and by the TBIT project [TBIT] + in data taken from September, 2000, up to March, 2002, 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. In March 2002, six months after ECN was approved as + Proposed Standard, ECN-setup SYN packets were answered by a reset + from 203 of the 12,364 web sites tested, and ECN-setup SYN packets + were dropped for 420 of the web sites. 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 described in [Floyd00], and has been specified in RFC + 3168 as a procedure that may be included in TCP implementations. We + describe this work-around briefly below. + + + + +Floyd Best Current Practice [Page 6] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + 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 ECN-capable TCP host not responding properly to the first + valid reset. If a second reset is sent in response to the second + SYN, which had CWR and ECE cleared, then the TCP host should respond + properly by aborting the connection. + + 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 + 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. + + Some TCP implementors have so far decided not to deploy these + workarounds, for the following reasons: + + * The work-arounds would result in ECN-capable hosts not responding + properly to 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 + + + +Floyd Best Current Practice [Page 7] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + 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. This is discussed in more detail in Section 6.1 + below. + +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. + + 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, 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 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. + + + +Floyd Best Current Practice [Page 8] + +RFC 3360 Inappropriate TCP Resets August 2002 + + +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. + + The ECN standards document, RFC 3168, contains an extensive + discussion in Section 18 on "Possible Changes to the ECN Field in the + Network", but includes the following about possible changes to the + TCP header: + + "This document does not consider potential dangers introduced by + changes in the transport header within the network. We note that + when IPsec is used, the transport header is protected both in tunnel + and transport modes [ESP, AH]." + + With the current modification of transport-level headers in the + network by firewalls (as discussed below in Section 6.2), future + protocol designers might no longer have the luxury of ignoring the + possible impact of changes to the transport header within the + network. + + 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, if at all. One suggestion, for + consideration in more depth in a separate document, would be that + firewalls send an ICMP Destination Unreachable message with the code + "Communication Administratively Prohibited" [B01]. + + + + + +Floyd Best Current Practice [Page 9] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + 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 reveals too much information about security + policies. And third, the response of transport protocols to such an + ICMP message is not yet specified. + + However, an ICMP "Administratively Prohibited" message could be a + reasonable addition, for firewalls willing to use explicit + communication. One possibility, again to be explored in a separate + document, would be for the ICMP "Administratively Prohibited" message + to be modified to convey additional information to the end host. + + We would note that this document does not consider middleboxes that + block complete transport protocols. We also note that this document + is not addressing firewalls that send resets in response to a TCP SYN + packet to a firewalled-off TCP port. Such a use of resets seems + consistent with the semantics of TCP reset. 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. + + One complication is that once a mechanism is installed in a firewall + to block a particular functionality, it can take considerable effort + for network administrators to "un-install" that block. It has been + suggested that tweakable settings on firewalls could make recovery + from future incidents less painful all around. Again, because this + document does not address more general issues about firewalls, the + issue of greater firewall flexibility, and the attendant possible + security risks, belongs in a separate document. + +6.1. Current Choices for Firewalls + + Given a firewall that has decided to drop TCP packets that use + reserved bits in the TCP header, one question is whether the firewall + should also send a Reset, in order to prevent the TCP connection from + consuming unnecessary resources at the TCP sender waiting for the + retransmit timeout. We would argue that whether or not the firewall + feels compelled to drop the TCP packet, it is not appropriate to send + a TCP reset. Sending a TCP reset in response to prohibited + functionality would continue the current overloading of the semantics + of the TCP reset in a way that could be counterproductive all around. + + As an example, Section 2.3 has already observed that some firewalls + send resets in response to TCP SYN packets as a congestion control + mechanism. Possibly in response to this (or perhaps in response to + something else), some popular TCP implementations immediately resend + a SYN packet in response to a reset, up to four times. Other TCP + + + +Floyd Best Current Practice [Page 10] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + implementations, in conformance to the standards, don't resend SYN + packets after receiving a reset. The more aggressive TCP + implementations increase congestion for others, but also increase + their own chances of eventually getting through. Giving these fluid + semantics for the TCP reset, one might expect more TCP + implementations to start resending SYN packets in response to a + reset, completely apart from any issues having to do with ECN. + Obviously, this weakens the effectiveness of the reset when used for + its original purpose, of responding to TCP packets that apparently + are not intended for the current connection. + + If we add to this mix the use of the TCP reset by firewalls in + response to TCP packets using reserved bits in the TCP header, this + muddies the waters further. Because TCP resets could be sent due to + congestion, or to prohibited functionality, or because a packet was + received from a previous TCP connection, TCP implementations (or, + more properly, TCP implementors) would now have an incentive to be + even more persistent in resending SYN packets in response to TCP + resets. In addition to the incentive mentioned above of resending + TCP SYN packets to increase one's odds of eventually getting through + in a time of congestion, the TCP reset might have been due to + prohibited functionality instead of congestion, so the TCP + implementation might resend SYN packets in different forms to + determine exactly which functionality is being prohibited. Such a + continual changing of the semantics of the TCP reset could be + expected to lead to a continued escalation of measures and + countermeasures between firewalls and end-hosts, with little + productive benefit to either side. + + It could be argued that *dropping* the TCP SYN packet due to the use + of prohibited functionality leads to overloading of the semantics of + a packet drop, in the same way that the reset leads to overloading + the semantics of a reset. This is true; from the viewpoint of end- + system response to messages with overloaded semantics, it would be + preferable to have an explicit indication about prohibited + functionality (for those firewalls for some reason willing to use + explicit indications). But given a firewall's choice between sending + a reset or just dropping the packet, we would argue that just + dropping the packet does less damage, in terms of giving an incentive + to end-hosts to adopt counter-measures. It is true that just + dropping the packet, without sending a reset, results in delay for + the TCP connection in resending the SYN packet without the prohibited + functionality. However, sending a reset has the undesirable longer- + term effect of giving an incentive to future TCP implementations to + add more baroque combinations of resending SYN packets in response to + a reset, because the TCP sender can't tell if the reset is for a + standard reason, for congestion, or for the prohibited functionality + of option X or reserved bit Y in the TCP header. + + + +Floyd Best Current Practice [Page 11] + +RFC 3360 Inappropriate TCP Resets August 2002 + + +6.2. The Complications of Modifying Packet Headers in the Network + + In addition to firewalls that send resets in response to ECN-setup + SYN packets and firewalls that drop ECN-setup SYN packets, there also + exist firewalls that by default zero the flags in the TCP Reserved + field, including the two flags used for ECN. We note that in some + cases this could have unintended and undesirable consequences. + + If a firewall zeros the ECN-related flags in the TCP header in the + initial SYN packet, then the TCP connection will be set up without + using ECN, and the ECN-related flags in the TCP header will be sent + zeroed-out in all of the subsequent packets in this connection. This + will accomplish the firewall's purpose of blocking ECN, while + allowing the TCP connection to proceed efficiently and smoothly + without using ECN. + + If for some reason the ECN-related flags in the TCP header aren't + zeroed in the initial SYN packet from host A to host B, but the + firewall does zero those flags in the responding SYN/ACK packet from + host B to host A, the consequence could be to subvert end-to-end + congestion control for this connection. The ECN specifications were + not written to ensure robust operation in the presence of the + arbitrary zeroing of TCP header fields within the network, because it + didn't occur to the authors of the protocol at the time that this was + a requirement in protocol design. + + Similarly, if the ECN-related flags in the TCP header are not zeroed + in either the SYN or the SYN/ACK packet, but the firewall does zero + these flags in later packets in that TCP connection, this could also + have the unintended consequence of subverting end-to-end congestion + control for this connection. The details of these possible + interactions are not crucial for this document, and are described in + the appendix. However, our conclusion, both for the ECN-related + flags in the TCP header and for future uses of the four other bits in + the TCP Reserved field, would be that if it is required for firewalls + to be able to block the use of a new function being added to a + protocol, this is best addressed in the initial design phase by joint + cooperation between the firewall community and the protocol + designers. + +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 + + + +Floyd Best Current Practice [Page 12] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + fixes for any nonconformant code, and we could urge ISPs and system + administrators to deploy these fixes in their web servers and + firewalls. + + We don't claim that it violates any standard for middleboxes to + arbitrarily drop packets that use flags in the TCP Reserved field, + but we 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. More work + is clearly needed to reconcile the conflicting interests of providing + security while at the same time allowing the careful evolution of + Internet protocols. + +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 Ran Atkinson, Steve Bellovin, Alex Cannara, + Dennis Ferguson, Ned Freed, Mark Handley, John Klensin, Allison + Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Jamal Hadi + Salim, Pekka Savola, Alex Snoeren, and Dan Wing for feedback on this + document, and to the End-to-End Research Group, the IAB, and the IESG + for discussion of these issues. I thank Mikael Olsson for numerous + rounds of feedback. 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 Dax Kelson, + Alexey Kuznetsov, 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. We thank Mark Handley, + Jitentra Padhye, and others for discussions on the TCP initialization + procedures. + +9. Normative References + + [RFC793] Postel, J., "Transmission Control Protocol - DARPA + Internet Program Protocol Specification", STD 7, RFC 793, + September 1981. + + [RFC1122] Braden, R., "Requirements for Internet Hosts -- + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC + 1812, June 1995. + + + + + +Floyd Best Current Practice [Page 13] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2481] Ramakrishnan, K. 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 E. Crabbe, "TCP + Processing of the IPv4 Precedence Field, RFC 2873, June + 2000. + + [RFC2979] Freed, N., " Behavior of and Requirements for Internet + Firewalls", RFC 2979, October 2000. + + [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", RFC + 3168, September 2001. + +10. Informative References + + [B01] Bellovin, S., "A "Reason" Field for ICMP "Administratively + Prohibited" Messages", Work in Progress. + + [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". + + [ECN] "The ECN Web Page", URL + "http://www.icir.org/floyd/ecn.html". + + [FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL + "http://gtf.org/garzik/ecn/". + + [Floyd00] Sally Floyd, Negotiating ECN-Capability in a TCP + connection, October 2, 2000, email to the end2end-interest + mailing list. URL + "http://www.icir.org/floyd/papers/ECN.Oct2000.txt". + + [Kelson00] Dax Kelson, note sent to the Linux kernel mailing list, + September 10, 2000. + + [QUESO] Toby Miller, Intrusion Detection Level Analysis of Nmap + and Queso, August 30, 2000. URL + "http://www.securityfocus.com/infocus/1225". + + + + + + +Floyd Best Current Practice [Page 14] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The + Protocols", Addison-Wesley, 1994. + + [SFO01] FreeBSD ipfw Filtering Evasion Vulnerability, Security + Focus Online, January 23, 2001. URL + "http://www.securityfocus.com/bid/2293". + + [TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP + Behavior of Web Servers, SIGCOMM, August 2001. URL + "http://www.icir.org/tbit/". + +11. Security Considerations + + One general risk of using Reserved flags in TCP is the risk of + providing additional information about the configuration of the host + in question. However, TCP is sufficiently loosely specified as it + is, with sufficiently many variants and options, that port-scanning + tools such as Nmap and Queso do rather well in identifying the + configuration of hosts even without the use of Reserved flags. + + The security considerations and all other considerations of a + possible ICMP Destination Unreachable message with the code + "Communication Administratively Prohibited" will be discussed in a + separate document. + + The traditional concern of firewalls is to prevent unauthorized + access to systems, to prevent DoS attacks and other attacks from + subverting the end-user terminal, and to protect end systems from + buggy code. We are aware of one security vulnerability reported from + the use of the Reserved flags in the TCP header [SFO01]. A packet + filter intended only to let through packets in established + connections can let pass a packet not in an established connection if + the packet has the ECE flag set in the reserved field. "Exploitation + of this vulnerability may allow for unauthorized remote access to + otherwise protected services." It is also possible that an + implementation of TCP could appear that has buggy code associated + with the use of Reserved flags in the TCP header, but we are not + aware of any such implementation at the moment. + + Unfortunately, misconceived security concerns are one of the reasons + for the problems 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." As is documented on the TBIT Web Page, the middleboxes + + + +Floyd Best Current Practice [Page 15] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Floyd Best Current Practice [Page 16] + +RFC 3360 Inappropriate TCP Resets August 2002 + + +12. Appendix: The Complications of Modifying Packet Headers + + In this section we first show that if the ECN-related flags in the + TCP header aren't zeroed in the initial SYN packet from Host A to + Host B, but are zeroed in the responding SYN/ACK packet from Host B + to Host A, the consequence could be to subvert end-to-end congestion + control for this connection. + + Assume that the ECN-setup SYN packet from Host A is received by Host + B, but the ECN-setup SYN/ACK from Host B is modified by a firewall in + the network to a non-ECN-setup SYN/ACK, as in Figure 3 below. RFC + 3168 does not specify that the ACK packet in any way should echo the + TCP flags received in the SYN/ACK packet, because it had not occurred + to the designers that these flags would be modified within the + network. + + Host A Firewall or router Host B + ----------------------------------------------------------------- + Sends ECN-setup SYN ----------------> Receives ECN-setup SYN + <- Sends ECN-setup SYN/ACK + <- Firewall zeros flags + Receives non-ECN-setup SYN/ACK + Sends ACK and data ----------------> Receives ACK and data + <- Sends data packet with ECT + <- Router sets CE + Receives data packet with ECT and CE + + Figure 3: ECN-related flags in SYN/ACK packet cleared in network. + + Following RFC 3168, Host A has received a non-ECN-setup SYN/ACK + packet, and must not set ECT on data packets. Host B, however, does + not know that Host A has received a non-ECN-setup SYN/ACK packet, and + Host B may set ECT on data packets. RFC 3168 does not require Host A + to respond properly to data packets received from Host B with the ECT + and CE codepoints set in the IP header. Thus, the data sender, Host + B, might never be informed about the congestion encountered in the + network, thus violating end-to-end congestion control. + + Next we show that if the ECN-related flags in the TCP header are not + zeroed in either the SYN or the SYN/ACK packet, but the firewall does + zero these flags in later packets in that TCP connection, this could + also have the unintended consequence of subverting end-to-end + congestion control for this connection. Figure 4 shows this + scenario. + + + + + + + +Floyd Best Current Practice [Page 17] + +RFC 3360 Inappropriate TCP Resets August 2002 + + + Host A Firewall or router Host B + ----------------------------------------------------------------- + Sends ECN-setup SYN ----------------> Receives ECN-setup SYN + Receives ECN-setup SYN/ACK <------------ Sends ECN-setup SYN/ACK + Sends ACK and data ----------------> Receives ACK and data + <- Sends data packet with ECT + <- Router sets CE + Receives data packet with ECT and CE + Sends ACK with ECE -> + Firewall resets ECE -> + Receives plain ACK + + Figure 4: ECN-related flags in ACK packet cleared in network. + + The ECN-related flags are not changed by the network in the ECN-setup + SYN and SYN/ACK packets for the scenario in Figure 4, and both end + nodes are free to use ECN, and to set the ECT flag in the ECN field + in the IP header. However, if the firewall clears the ECE flag in + the TCP header in ACK packets from Node A to Node B, then Node B will + never hear about the congestion that its earlier data packets + encountered in the network, thus subverting end-to-end congestion + control for this connection. + + Additional complications will arise when/if the use of the ECN nonce + in TCP becomes standardized in the IETF [RFC3168], as this could + involve the specification of an additional flag from the TCP Reserved + field for feedback from the TCP data receiver to the TCP data sender. + The primary motivation for the ECN nonce is to allow mechanisms for + the data sender to verify that network elements are not erasing the + CE codepoint, and that data receivers are properly reporting to the + sender the receipt of packets with the CE codepoint set. + +13. IANA Considerations + + There are no IANA considerations in this document. + +14. Author's Address + + Sally Floyd + ICIR (ICSI Center for Internet Research) + + Phone: +1 (510) 666-2989 + EMail: floyd@icir.org + URL: http://www.icir.org/floyd/ + + + + + + + +Floyd Best Current Practice [Page 18] + +RFC 3360 Inappropriate TCP Resets August 2002 + + +15. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Floyd Best Current Practice [Page 19] + |