Internet Draft H. Jamjoom K. G. Shin Document: draft-jamjoom-icmpreject-00.txt University of Michigan Expires: October 2002 August 2002 Reject Message Extension for ICMP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 specifies the incorporation of a Reject message to ICMP to improve a serverÆs ability for controlling TCP connection requests during periods of overload beyond dropping them. The Reject message serves two purposes: (1) it can inform a connecting host (the client) to completely abort the connection attempt as if a connection timeout has expired, and (2) modify the retransmission timeout interval to reduce the clientÆs wait times and also to break the re-synchronization of connection requests when multiple SYN packets are dropped. Introducing an additional ICMP message, as opposed to modifying the behavior of TCP, was motivated by the need for backward compatibility (i.e., a host can ignore the ICMP Reject message without affecting the behavior of TCP) and incremental deployment. Jamjoom Expires û October 2002 [Page 1] ICMP Reject August 2002 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. This document is mainly concerned with two types of host machines: ôSERVERSö and ôCLIENTSö. A ôCLIENTö is a host machines that send a request via TCP (only) to a ôSERVERö machine, which, in turn, process the request and sends a response back. A ôGATEWAYö is interpreted as any packet- forwarding device between the client and the server. Each ôREQUESTö is assumed in this document to require a separate connection, which means that it will involve a three-way connection establishment before any data is sent between the server and client. Table of Contents 1. Introduction...................................................2 2. Source Reject Message..........................................4 Security Considerations...........................................5 References........................................................6 Author's Addresses................................................6 1. Introduction Short-lived Transport Control Protocol (TCP) connections are typical of interactive Web sessions. They are delay-sensitive and have transfer times dominated by TCP back-offs, if any, during connection establishment [3]. Unfortunately, arrivals of such connections (i.e., SYN packets) at a server tend to be bursty [4], and when the server is busy, they may get dropped, triggering retransmission timeouts. This results in long average client-perceived delays. To date, TCP does not provide any explicit mechanism during the connection establishment phase that improves a serverÆs controls beyond dropping connection requests. In fact, TCP relies solely on dropping packets to trigger clients to back off (exponentially) and retransmit their request at a later time. This process is repeated until either the connection is established or a connection timeout expires and the connection attempt is aborted [5]. Three particular issues arise from TCPÆs limitation. First, we observed that when a large number of packets are dropped due to Jamjoom Expires û October 2002 [Page 2] ICMP Reject August 2002 a burst, these will re-synchronize themselves and will be retransmitted by the clients and arrive at the server at roughly the same time resulting in an additional burst at the server. Second, because TCP exponentially backs off, the client experiences excessively long delays even when the server is temporarily busy and drops the clientÆs connection requests. We assume here that the serverÆs listen buffer is full. The server, in this case, has no control over how long the client should wait before trying to connect again. Third, in some cases the server may have an advantage for rejecting a clientÆs connection request to (a) immediately inform the client that it will not be able to process its request and, thus, minimize the clientÆs wait time (traditionally, the client must wait for a long connection timeout period), and (b) minimize the number of retransmissions by the client since a single Reject message is returned to the client. Existing TCP control mechanisms, which include Explicit Congestion Notification [6] and ICMP Source Quench Message [7], only take effect after the connection is established. However, providing better controls for the connection establishment phase is of importance, especially for short-lived TCP connections. Two basic functionalities should be provided. First, a server should be able to inform the client of when to resubmit the connection request. The client, in return, should reduce its retransmission timeout to that value. Second, the server should be able to reject the connection request altogether. The client would then abort the connection as if the connection timeout has been reached. The addition of one ICMP message type will achieve both goals. The use of an ICMP message, as opposed to modifying the actual transport protocol, is motivated by the need for incremental deployment and backward compatibility. More specifically, if the ICMP message is dropped by intermediate gateways or if the client does not honor such message, then the client will perceive a typical TCP behavior, namely an unacknowledged SYN packet. This will, in turn, trigger a retransmission timeout as defined in [5]. On the other hand, if the client does honor such message, then only TCP timeout values are transparently adjusted, and thus, higher-level applications should continue to work properly. There is one issue of importance, namely, the security effects of modifying TCPÆs timeout values. This arises because the clientÆs retransmission timeout value is set under the discretion of the server. A minimum timeout value must then be enforced to avoid the situations where the server drops SYN packets and informs the client to retransmit immediately, which Jamjoom Expires û October 2002 [Page 3] ICMP Reject August 2002 would create another form of Denial of Service attack. We recommend that this value set to the initial RTO value, which is typically 3 sec. In that respect, the server is only able to control the exponential backoff behavior of clients in a highly secure fashion. 2. Source Reject Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Retransmission Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Data Datagram | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Destination Address The source network and address of the original datagram's data. ICMP Fields: Type 19 Code 0 = abort connection; 1 = modify retransmission timeout. Checksum The computation of the checksum follows the same requirements in other ICMP messages as described in [7]: ôThe checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero. This checksum may be replaced in the future.ö Jamjoom Expires û October 2002 [Page 4] ICMP Reject August 2002 Minimum Retransmission Time: This field contains the number of milliseconds that the client must wait before retransmitting the SYN packet. It must contain a minimum value of 3 seconds. Internet Header + 64 bits of Data Datagram Similarly, the same specification as [7] for the Internet header plus the first 64 bits of the original datagram's data is used. The host uses this data to match the message to the appropriate process. Of course since this is the message in response to a TCP SYN packet, the port numbers are assumed to be in the first 64 data bits of the original datagram's data. Description A host receiving a Reject message will either abort the connection as if a TCP connection timeout has expired (Code 0) or change the retransmission timeout of the corresponding TCP connection, which is determined from the Internet Header and the 64 bits of Data, to the value specified in the Minimum Retransmission Timeout field (Code 1). If the Minimum Retransmission Time is less than the recommended 3 seconds, the host should discard the message and wait for the regular TCP timeout to expire. Security Considerations The use of ICMP Reject does not increase a clientÆs or a serverÆs vulnerability beyond existing TCP implementations or other ICMP messages. The inclusion of the original SYN packet header in the Reject message allows the receiving host to validate the authenticity of the message. In the case of a Denial of Service (DoS) attack at the server, the server must implement similar defense techniques for minimizing the number of Reject messages sent to its clients. This is in par with traditional techniques used for reducing the number of SYN ACK replies. Jamjoom Expires û October 2002 [Page 5] ICMP Reject August 2002 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Olshefski, D., J. Nieh, and D. Agrawal, ôInferring Client Response Time at the Web Server,ö In Proceedings of ACM SIGMETRICS 2003, June 2003 4 Feldmann, A., ôCharacteristics of TCP Connection Arrivals.ö Self-Similar Network Traffic and Performance Evaluation. John Wiley and Sons, Inc., 2000, ch. 15, pp. 367-399 5 Postel, J. (ed.), "Transmission Control Protocol û DARPA Internet Program Protocol Specification," RFC 793, USC/Information Sciences Institute, September 1981 6 Ramakrishnan, K., S. Floyd, and D. Black, ôThe Addition of Explicit Congestion Notification (ECN) to IP,ö RFC 3168, TeraOptic Networks, September 2001 7 Postel, J. (ed.), "Internet Control Message Protocol û DARPA Internet Program Protocol Specification," RFC 792, USC/Information Sciences Institute, September 1981 Author's Addresses Hani Jamjoom University of Michigan 1301 Beal Ave. Ann Arbor, MI 48109-2122 Email: jamjoom@eecs.umich.edu Jamjoom Expires û October 2002 [Page 6]