Internet Engineering Task Force                              Sally Floyd
INTERNET DRAFT                                                     ACIRI
draft-floyd-tcp-reset-01.txt                                  June, 2001
                                                 Expires: December, 2001


              Inappropriate TCP Resets Considered Harmful



                          Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document is being written because there are a number of
   firewalls in the Internet that inappropriately reset a TCP connection
   upon receiving certain TCP SYN packets, in particular, packets with
   flags set in the Reserved field of the TCP header.  In this document
   we argue that this practice is not conformant with TCP standards.  We
   further argue that this is a harmful practice that presents an
   unnecessary obstacle to the evolution of the Internet infrastructure.

1.  Introduction

   TCP uses the RST (Reset) bit in the TCP header to reset a TCP
   connection.  Resets are appropriately sent in response to a
   connection request to a nonexistent connection, for example.  The TCP
   receiver of the reset aborts the TCP connection, and notifies the



Floyd                         Informational                     [Page 1]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   application [RFC793, RFC1122, Ste94].

   Unfortunately, a number of firewalls and load-balancers in the
   current Internet send a reset in response to a TCP SYN packet that
   use flags from the Reserved field in the TCP header.  Section 3 below
   discusses the specific example of firewalls that send resets in
   response to TCP SYN packets from ECN-capable hosts.

   This document is being written to inform administrators of web
   servers and firewalls of this problem, in an effort to encourage the
   deployment of bug-fixes [FIXES].  A second purpose of this document
   is to consider the longer-term consequences of such middlebox
   behavior on the more general evolution of protocols in the Internet.

2.  The history of TCP resets.

   This section gives a brief history of the use of the TCP reset in the
   TCP standards, and argues that sending a reset in response to a SYN
   packet that uses bits from the Reserved field of the TCP header is
   non-compliant behavior.

   RFC 793 contained the original specification of TCP in September,
   1981 [RFC793].  This document defined the RST bit in the TCP header,
   and explained that reset was devised to prevent old duplicate
   connection initiations from causing confusion in TCP's three-way
   handshake.  The reset is also used when a host receives data for a
   TCP connection that no longer exists.

   RFC 793 states the following, in Section 5:

   "As a general rule, reset (RST) must be sent whenever a segment
   arrives which apparently is not intended for the current connection.
   A reset must not be sent if it is not clear that this is the case."

   This makes it clear that a reset must not be sent simply because a
   TCP SYN packet uses one or more of the Reserved flags in the TCP
   header.

   RFC 1122 "amends, corrects, and supplements" RFC 793.  RFC 1122 says
   nothing specific about sending resets, or not sending resets, in
   response to flags in the TCP Reserved field.

   RFC 793 and RFC 1122 both include Jon Postel's famous robustness
   principle, also from RFC 791: "Be liberal in what you accept, and
   conservative in what you send."  RFC 1122 reiterates that this
   robustness principle "is particularly important in the Internet
   layer, where one misbehaving host can deny Internet service to many
   other hosts."  The discussion of the robustness principle in RFC 1122



Floyd                         Informational                     [Page 2]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   also states that "adaptability to change must be designed into all
   levels of Internet host software".

   In summary, there is nothing in RFC 793 or RFC 1122 that suggests
   that it is acceptable to send a reset simply because a SYN packet
   uses Reserved flags in the TCP header, and RFC 793 explicitly forbids
   sending a reset for this reason.

2.1.  The TCP Reserved Field

   RFC 793 says that the Reserved field in the TCP header is reserved
   for future use, and must be zero.  A rephrasing more consistent with
   the rest of the document would have been to say that the Reserved
   field should be zero when sent and ignored when received, unless
   specified otherwise by future standards actions.  However, the
   phrasing in RFC 793 does not condone sending resets in response to
   TCP packets with a non-zero Reserved field, as is explained in the
   section above.

2.2.  Behavior of and Requirements for Internet Firewalls

   RFC 2979 on the Behavior of and Requirements for Internet Firewalls,
   an Informational RFC, contains the following:

   "Applications have to continue to work properly in the presence of
   firewalls.  This translates into the following transparency rule: The
   introduction of a firewall and any associated tunneling or access
   negotiation facilities MUST NOT cause unintended failures of
   legitimate and standards-compliant usage that would work were the
   firewall not present."

   "A necessary corollary to this requirement is that when such failures
   do occur it is incumbent on the firewall and associated software to
   address the problem: Changes to either implementations of existing
   standard protocols or the protocols themselves MUST NOT be
   necessary."

   "Note that this requirement only applies to legitimate protocol usage
   and gratuitous failures -- a firewall is entitled to block any sort
   of access that a site deems illegitimate, regardless of whether or
   not the attempted access is standards-compliant."

   We would note that RFC 2979 is an Informational RFC.  RFC 2026 on
   Internet Standards Process says the following in Section 4.2.2: "An
   `Informational' specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation" [RFC2026].




Floyd                         Informational                     [Page 3]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


2.3.  Sending Resets as a Congestion Control Mechanism

   Some firewalls and hosts send resets in response to SYN packets as a
   congestion control mechanism, for example, when their listen queues
   are full.  These resets are sent without regard to the contents of
   the TCP Reserved field, and this document is not attempting to
   address this use of resets one way or another.

2.4. Resets in Response to Changes in the Precedence Field

   RFC 793 includes the following in Section 5:

   "If an incoming segment has a security level, or compartment, or
   precedence which does not exactly match the level, and compartment,
   and precedence requested for the connection, a reset is sent and
   connection goes to the CLOSED state."

   The "precedence" refers to the (old) Precedence field in the (old)
   ToS field in the IP header.  The "security" and "compartment" refer
   to the obsolete IP Security option.  When it was written, this was
   consistent with the guideline elsewhere in RFC 793 that resets should
   only be sent when a segment arrives which apparently is not intended
   for the current connection.

   RFC 2873 on "TCP Processing of the IPv4 Precedence Field" discusses
   specific problems raised by the sending of resets when the precedence
   field has changed [RFC2873].  RFC 2873, currently a Proposed
   Standard, specifies that TCP must ignore the precedence of all
   received segments, and must not send a reset in response to changes
   in the precedence field.  We discuss this here to clarify that this
   issue never condoned the sending of a reset in response to a segment
   with a non-zero TCP Reserved field.

2.5. Resets in Response to Illegal Option Lengths

   RFC 1122 says the following in Section 4.2.2.5 about TCP options
   [RFC1122]:

   "A TCP MUST be able to receive a TCP option in any segment.  A TCP
   MUST ignore without error any TCP option it does not implement,
   assuming that the option has a length field (all TCP options defined
   in the future will have length fields).  TCP MUST be prepared to
   handle an illegal option length (e.g., zero) without crashing; a
   suggested procedure is to reset the connection and log the reason."

   This makes sense, as a TCP receiver is unable to interpret the rest
   of the data on a segment that has a TCP option with an illegal option
   length.  Again, we discuss this here to clarify that this issue never



Floyd                         Informational                     [Page 4]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   condoned the sending of a reset in response to a segment with a non-
   zero TCP Reserved field.

3.  The Specific Example of ECN

   This section has a brief explanation of ECN (Explicit Congestion
   Notification) in general, and the ECN-setup SYN packet in particular.

   The Internet is based on end-to-end congestion control, and the
   current Internet uses packet drops as the only method for routers to
   indicate congestion to the end nodes.  ECN is an addition to the IP
   architecture to allow routers to set a bit in the IP packet header to
   inform end-nodes of congestion, instead of dropping the packet.  ECN
   requires the cooperation of the transport end-nodes.

   The ECN specification, RFC 2481, was an Experimental standard from
   January, 1999 until June 12, 2001, when the revised document [RFB01]
   was approved by the IESG for Proposed Standard.  More information
   about the status of ECN is available from the ECN Web Page [ECN].

   The use of ECN with TCP requires that both TCP end-nodes have been
   upgraded to support the use of ECN, and that both end-nodes agree to
   use ECN with this particular TCP connection.  This negotiation of ECN
   support between the two TCP end-nodes uses two flags that have been
   allocated from the Reserved field in the TCP header [RFC2481].

       0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |                       | U | A | P | R | S | F |
     | Header Length |        Reserved       | R | C | S | S | Y | I |
     |               |                       | G | K | H | T | N | N |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Figure 1: The standard definition of bytes 13 and 14 of the TCP
   header.

       0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               |               | C | E | U | A | P | R | S | F |
     | Header Length |    Reserved   | W | C | R | C | S | S | Y | I |
     |               |               | R | E | G | K | H | T | N | N |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Figure 2: The definition of bytes 13 and 14 of the TCP Header from
   RFC 2481.

   The two ECN flags in the TCP header are defined from the last two
   bits in the Reserved field of the TCP header.  Bit 9 in the Reserved



Floyd                         Informational                     [Page 5]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   field of the TCP header is designated as the ECN-Echo flag (ECE), and
   Bit 8 is designated as the Congestion Window Reduced (CWR) flag.  To
   negotiate ECN usage, the TCP sender sends an "ECN-setup SYN packet",
   a TCP SYN packet with the ECE and CWR flags set.  If the TCP host at
   the other end wishes to use ECN for this connection, then it sends an
   "ECN-setup SYN-ACK packet", a TCP SYN packet with the ECE flag set
   and the CWR flag not set.  Otherwise, the TCP host at the other end
   returns a SYN-ACK packet with neither the ECE nor the CWR flag set.

   So now back to TCP resets.  When a TCP host negotiating ECN sends an
   ECN-setup SYN packet, an old TCP implementation is expected to ignore
   those flags in the Reserved field, and to send a plain SYN-ACK packet
   in response.  However, there are some broken web firewalls and load-
   balancers in the Internet that instead respond to an ECN-setup SYN
   packet with a reset.  This has been investigated by the Linux
   community, and by the TBIT project [TBIT] in data taken from
   September, 2000, up to June, 2001, and has been discussed in an
   article in Enterprise Linux Today [Cou01].  Some of the offending
   equipment has been identified, and a web page [FIXES] contains a list
   of non-compliant products and the fixes posted by the vendors, where
   these are available.  On the day after ECN was approved as Proposed
   Standard, there were still many sites sending resets in response to
   conformant ECN-setup SYN packets, and I would imagine that this could
   remain the case for some time.  Installing software that blocks
   packets using flags in TCP's Reserved field is considerably easier
   than uninstalling that software later on.

3.1.  ECN: The Work-Around.

   A work-around for maintaining connectivity in the face of the broken
   equipment was been described in [Floyd00], and has been specified in
   the ECN standards document as a procedure that may be included in TCP
   implementations.  We describe this work-around briefly below.

   To provide robust connectivity even in the presence of faulty
   equipment, a TCP host that receives a reset in response to the
   transmission of an ECN-setup SYN packet may resend the SYN with CWR
   and ECE cleared.  This would result in a TCP connection being
   established without using ECN.  This also has the unfortunate result
   of the first valid reset being ignored by the ECN-capable TCP host.
   If a second reset is sent in response to the second SYN, which had
   CWR and ECE cleared, this second reset would not be ignored by the
   TCP host.

   Similarly, a host that receives no reply to an ECN-setup SYN within
   the normal SYN retransmission timeout interval may resend the SYN and
   any subsequent SYN retransmissions with CWR and ECE cleared.  To
   overcome normal packet loss that results in the original SYN being



Floyd                         Informational                     [Page 6]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   lost, the originating host may retransmit one or more ECN-setup SYN
   packets before giving up and retransmitting the SYN with the CWR and
   ECE bits cleared.

   TCP implementors have so far decided not to deploy these workarounds,
   for the following reasons:

   * The work-arounds would result in ECN-capable hosts ignoring the
   first valid reset received in response to a SYN packet.

   * The work-arounds would limit ECN functionality in environments
   without broken equipment, by disabling ECN where the first SYN or
   SYN-ACK packet was dropped in the network.

   * The work-arounds in many cases would involve a delay of six seconds
   or more before connectivity is established with the remote server, in
   the case of broken equipment that drops ECN-setup SYN packets.  By
   accommodating this broken equipment, the work-arounds have been
   judged as implicitly accepting both this delay and the broken
   equipment that would be causing this delay.

   One possibility would be for such work-arounds to be configurable by
   the user.

   One unavoidable consequence of the work-around of resending a
   modified SYN packet in response to a reset is to further erode the
   semantics of the TCP reset.  Thus, when a box sends a reset, the TCP
   host receiving that reset does not know if the reset was sent simply
   because of the ECN-related flags in the TCP header, or because of
   some more fundamental problem.  Therefore, the TCP host resends the
   TCP SYN packet without the ECN-related flags in the TCP header.  The
   ultimate consequence of this absence of clear communications from the
   middlebox to the end-nodes could be an extended spiral of
   communications specified for transport protocols, as end nodes
   attempt to sacrifice as little functionality as possible in the
   process of determining which packets will and will not be forwarded
   to the other end.


4.  On Combating Obstacles to the Proper Evolution of the Internet
Infrastructure

   One of the reasons that this issue of inappropriate resets is
   important (to me) is that it has complicated the deployment of ECN in
   the Internet (though it has fortunately not blocked the deployment
   completely).  It has also added an unnecessary obstacle to the future
   effectiveness of ECN.




Floyd                         Informational                     [Page 7]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   However, a second, more general reason why this issue is important is
   that the presence of equipment in the Internet that rejects valid TCP
   packets limits the future evolution of TCP, completely aside from the
   issue of ECN.  That is, the widespread deployment of equipment that
   rejects TCP packets that use Reserved flags in the TCP header could
   effectively prevent the deployment of new mechanisms that use any of
   these Reserved flags.  It doesn't matter if these new mechanisms have
   the protection of Experimental or Proposed Standard status from the
   IETF in this case, because the broken equipment in the Internet does
   not stop to look up the current status of the protocols before
   rejecting the packets.  TCP is good, and useful, but it would be a
   pity for the deployment of broken equipment in the Internet to result
   in the "freezing" of TCP in its current state, without the ability to
   use the Reserved flags in the future evolution of TCP.

   In the specific case of middleboxes that block TCP SYN packets
   attempting to negotiate ECN, the work-around described in Section 3.1
   is sufficient to ensure that end-nodes could still establish
   connectivity.  However, there are likely to be additional uses of the
   TCP Reserved Field standardized in the next year or two, and these
   additional uses might not coexist quite as successfully with
   middleboxes that send resets.  Consider the difficulties that could
   result if a path changes in the middle of a connection's lifetime,
   and the middleboxes on the old and new paths have different policies
   about exactly which flags in the TCP Reserved field they would and
   would not block.

   Taking the wider view, the existence of web servers or firewalls that
   send inappropriate resets is only one example of functionality in the
   Internet that inappropriately restricts the future evolution of the
   Internet.  The impact of all of these small restrictions taken
   together presents a considerable obstacle to the development of the
   Internet architecture.

5.  Issues for Transport Protocols

   One lesson for designers of transport protocols is that transport
   protocols will have to protect themselves from the unknown and
   seemingly arbitrary actions of firewalls, normalizers, and other
   middleboxes in the network.  For the moment, for TCP, this means
   sending a non-ECN-setup SYN when a reset is received in response to
   an ECN-setup SYN packet.  Defensive actions on the side of transport
   protocols could include using Reserved flags in the SYN packet before
   using them in data traffic, to protect against middleboxes that block
   packets using those flags.  It is possible that transport protocols
   will also have to add additional checks during the course of the
   connection lifetime to check for interference from middleboxes along
   the path.



Floyd                         Informational                     [Page 8]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   Transport protocols will also have to respond in some fashion to an
   ICMP code of "Communication Administratively Prohibited" if
   middleboxes start to use this form of the ICMP Destination
   Unreachable message to indicate that the packet is using
   functionality not allowed [RFC1812].

6.  Issues for Middleboxes

   Given that some middleboxes are going to drop some packets because
   they use functionality not allowed by the middlebox, the larger issue
   remains of how middleboxes should communicate the reason for this
   action to the end-nodes.  Our suggestion would be that firewalls send
   an ICMP Destination Unreachable message with the code "Communication
   Administratively Prohibited".

   We acknowledge that this is not an ideal solution, for several
   reasons.  First, middleboxes along the reverse path might block these
   ICMP messages.  Second, some firewall operators object to explicit
   communication because it simplifies fingerprinting.  And third, the
   response of transport protocols to such an ICMP message is not yet
   specified.  However, an ICMP "Administratively Prohibited" message
   still seems the best fit to the situation.

   We would note that this document does not consider middleboxes that
   block complete transport protocols.  This document is only
   considering the problems caused by middleboxes that block specific
   packets within a transport protocol when other packets from that
   transport protocol are forwarded by the middlebox unaltered.

7.  Conclusions

   Our conclusion is that it is not conformant with current standards
   for a firewall, load-balancer, or web-server to respond with a reset
   to a TCP SYN packet simply because the packet uses flags in the TCP
   Reserved field.  More specifically, it is not conformant to respond
   with a reset to a TCP SYN packet simply because the ECE and CWR flags
   are set in the IP header.  We would urge vendors to make available
   fixes for any nonconformant code, and we could urge ISPs and system
   administrators to deploy these fixes in their web servers and
   firewalls.

   I don't claim that it violates some standard for middleboxes to
   arbitrarily drop packets that use flags in the TCP Reserved field,
   but I would argue that behavior of this kind, without a clear method
   for informing the end-nodes of the reasons for these actions, could
   present a significant obstacle to the development of TCP.





Floyd                         Informational                     [Page 9]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


8.  Acknowledgements

   This document results from discussions and activity by many people,
   so I will refrain from trying to acknowledge all of them here.  My
   specific thanks go to Alex Cannara, Dennis Ferguson, Mark Handley,
   Allison Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan,
   Jamal Hadi Salim, Alex Snoeren, and Dan Wing for feedback on this
   document, and to the End-to-End Research Group for discussion of
   these issues.  I also thank the members of the Firewall Wizards
   mailing list for feedback (generally of disagreement) on an earlier
   draft of this document.

   Email discussions with a number of people, including Mark Handley,
   Dax Kelson, Alexey Kuznetsov, Jitentra Padhye, Kacheong Poon, David
   Reed, Jamal Hadi-Salim, and Venkat Venkatsubra, have addressed the
   issues raised by non-conformant equipment in the Internet that does
   not respond to TCP SYN packets with the ECE and CWR flags set.

9.  References

   [Cou01] Scott Courtney, Why Can't My 2.4 Kernel See Some Web Sites?,
   Enterprise Linux Today, Apr 17, 2001.  URL
   "http://eltoday.com/article.php3?ltsn=2001-04-17-001-14-PS".
   Reference for informational purposes only.

   [ECN] "The ECN Web Page", URL "http://www.aciri.org/floyd/ecn.html".
   Reference for informational purposes only.

   [FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL
   "http://gtf.org/garzik/ecn/".  Reference for informational purposes
   only.

   [Floyd00] Sally Floyd, Negotiating ECN-Capability in a TCP
   connection, October 2, 2000, email to the end2end-interest mailing
   list.  URL "http://www.aciri.org/floyd/papers/ECN.Oct2000.txt".

   [HPK01] Mark Handley, Vern Paxson, and Christian Kreibich, Network
   Intrusion Detection: Evasion, Traffic Normalization, and End-to-End
   Protocol Semantics, May 2001.  Draft paper.  Reference for
   acknowledgement purposes only.

   [QUESO] Toby Miller, Intrusion Detection Level Analysis of Nmap and
   Queso, August 30, 2000.  URL "http://www.securityfocus.com/
   frames/?focus=ids&content=/focus/ids/articles/portscan.html".
   Reference for informational purposes only.

   [RFB01] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
   Explicit Congestion Notification (ECN) to IP, draft-ietf-tsvwg-



Floyd                         Informational                    [Page 10]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   ecn-04.txt, work in progress, June 2001.  Approved for Proposed
   Standard on June 12, 2001.

   [RFC793]  Postel, J., "Transmission Control Protocol - DARPA Internet
   Program Protocol Specification", RFC 793, DARPA, September 1981.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts --
   Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC
   1812, June 1995.

   [RFC2026] S. Bradner, The Internet Standards Process -- Revision 3,
   RFC 2026, BCP 9, October 1996.

   [RFC2481] K. K. Ramakrishnan and S. Floyd, A Proposal to add Explicit
   Congestion Notification (ECN) to IP, RFC 2481, January 1999.

   [RFC2873] Xiao, X., Hannan, A., Paxson, V., and Crabbe, E., TCP
   Processing of the IPv4 Precedence Field, RFC 2873, June 2000.
   Proposed Standard.

   [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols",
   Addison-Wesley, 1994.

   [TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP Behavior
   of Web Servers, ICSI TR-01-002, February 2001.  URL
   "http://www.aciri.org/tbit/".

10.  Security Considerations

   I am not aware of any security risks from the use of the Reserved
   flags in the TCP header.  Security considerations have also been
   discussed in Section 2.2.  The traditional concern of firewalls is to
   prevent unauthorized access to systems, and to prevent DoS attacks
   and other attacks from subverting the end-user terminal, and I am not
   aware of any such risks associated with the use of Reserved flags in
   the TCP header.  To the extent that firewalls also exist to protect
   end systems from buggy code, it is certainly possible that an
   implementation of TCP could appear that has buggy code associated
   with the use of Reserved flags in the TCP header.  I am not aware of
   any such implementation at the moment.  I am also not aware of any
   security risks that would result from middleboxes sending ICMP
   "Administratively Prohibited" messages.

   Unfortunately, misconceived security concerns are one of the reasons
   for the broken equipment described in this document in the first
   place.  An August, 2000, article on "Intrusion Detection Level



Floyd                         Informational                    [Page 11]


draft-floyd-tcp-reset   Inappropriate TCP Resets                May 2001


   Analysis of Nmap and Queso" described the port-scanning tool Queso as
   sending SYN packets with the last two Reserved bits in the TCP header
   set, and said the following:  "[QUESO] is easy to identify, if you
   see [these two Reserved bits and the SYN bit] set in the 13th byte of
   the TCP header, you know that someone has malicious intentions for
   your network."  As is documented on the TBIT Web Page, the
   middleboxes that block SYNs using the two ECN-related Reserved flags
   in the TCP header do not block SYNs using other Reserved flags in the
   TCP header.

   One lesson appears to be that anyone can effectively ``attack'' a new
   TCP function simply by using that function in their publicly-
   available port-scanning tool, thus causing middleboxes of all kinds
   to block the use of that function.

11.  IANA Considerations

   There are no IANA considerations in this document.

   AUTHORS' ADDRESSES


      Sally Floyd
      Phone: +1 (510) 666-2989
      ACIRI (AT&T Center for Internet Research at ICSI)
      Email: floyd@aciri.org
      URL: http://www.aciri.org/floyd/

      This draft was created in June 2001.
      It expires December 2001.





















Floyd                         Informational                    [Page 12]