rfc3360.txt

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

   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/".