rfc3360.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/4 页

      | 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