doc: Add RFC documents

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]
+