INTERNET-DRAFT C. Sapuntzakis Cisco Systems August 2000 Expires February 2001 TCP Message Boundary Option 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 docuˇ ments 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. Copyright Notice Copyright (C) Cisco Systems (2000). All Rights Reserved. Abstract TCP does not have a mechanism for specifying message boundaries in a stream. This I-D describes a new TCP option and a new way of using the TCP urgent field to specify message boundaries in the stream. Sapuntzakis [Page 1] Internet-Draft TCP Message Boundary option 29 August 2000 Introduction TCP does not have a built-in mechanism for signalling message boundaries at the TCP layer. Most current TCP message encapsulations place the message length at the beginning of each message. The message length serves to delinˇ eate the end of the current message as well as the beginning of the next message. Unfortunately, when relying solely on this scheme, missing a segˇ ment with a message length makes it impossible to find message boundaries in subsequent segments. The missing segment must be received before later segments can be parsed and processed. There are several ways to get around this. * Make each message fixed size * Put synchronization information in the stream at fixed intervals * Use a marker byte to mark message boundaries However, none of these techniques seems particularly appetizing. Marker bytes work well for hardware but the escape sequences they assume make it difficult for software. Putting information at fixed intervals in the stream does not prevent the information from being split across segments. Instead, this document proposes a combination of a TCP option and an overloaded usage of the urgent field in the TCP header. This option brings TCP more in-line with the principles of applicaˇ tion-layer framing outlined in [ALF]. 1. Message boundary option 1.1. Usage This TCP option appears only during negotiation. It is a two byte option, with kind and length 2. If both sides indiˇ cate support for the TCP message boundary option, then the URG bit is interpreted as below. Sapuntzakis [Page 2] Internet-Draft TCP Message Boundary option 29 August 2000 2. Redefinition of the URG bit and The URG bit and urgent pointer are redefined from RFC 793. An URG bit set to one in a segment indicates that the urgent pointer is valid. The sum of the urgent pointer and sequence number of the TCP segˇ ment yields the sequence number of the first byte of an applicaˇ tion-layer message. 3. Security considerations A malicious interceptor could modify the message boundary informaˇ tion, falsely indicating message boundaries and corrupting the stream. However, such an interceptor could probably manipulate the stream to corrupt it in other ways. Sapuntzakis [Page 3] Internet-Draft TCP Message Boundary option 29 August 2000 4. Authors' Addresses Constantine Sapuntzakis Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 USA Phone: +1 408 525 5497 Email: csapuntz@cisco.com 5. References [ALF] D. D. Clark and D. L. Tennenhouse, "Architectural consideraˇ tions for a new generation of protocols," in SIGCOMM Symposium on Communications Architectures and Protocols , (Philadelphia, Pennˇ sylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review, Vol. 20(4), Sept. 1990. [TCP] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, September 1981 Expires February 2001 Sapuntzakis [Page 4]