Some problems with the specification of the Military Standard Transmission Control Protocol
RFC - Informational
(November 1985; No errata)
||RFC Editor Note
RFC 964 (Informational)
||Send notices to
Network Working Group Deepinder P. Sidhu
Request for Comments: 964 Thomas P. Blumer
SDC - A Burroughs Company
SOME PROBLEMS WITH THE SPECIFICATION OF THE
MILITARY STANDARD TRANSMISSION CONTROL PROTOCOL
STATUS OF THIS MEMO
The purpose of this RFC is to provide helpful information on the
Military Standard Transmission Control Protocol (MIL-STD-1778) so
that one can obtain a reliable implementation of this protocol
standard. Distribution of this note is unlimited.
Reprinted from: Proc. Protocol Specification, Testing and
Verification IV, (ed.) Y. Yemini, et al, North-Holland (1984).
This note points out three errors with the specification of the
Military Standard Transmission Control Protocol (MIL-STD-1778, dated
August 1983 [MILS83]). These results are based on an initial
investigation of this protocol standard. The first problem is that
data accompanying a SYN can not be accepted because of errors in the
acceptance policy. The second problem is that no retransmission
timer is set for a SYN packet, and therefore the SYN will not be
retransmitted if it is lost. The third problem is that when the
connection has been established, neither entity takes the proper
steps to accept incoming data. This note also proposes solutions to
In recent years, much progress has been made in creating an
integrated set of tools for developing reliable communication
protocols. These tools provide assistance in the specification,
verification, implementation and testing of protocols. Several
protocols have been analyzed and developed using such tools.
In a recent paper, the authors discussed the verification of the
connection management of NBS class 4 transport protocol (TP4). The
verification was carried out with the help of a software tool we
developed [BLUT82] [BLUT83] [SIDD83]. In spite of the very precise
specification of this protocol, our analysis discovered several
errors in the current specification of NBS TP4. These errors are
incompleteness errors in the specification, that is, states where
there is no transition for the reception of some input event. Our
analysis did not find deadlocks, livelocks or any other problem in
the connection management of TP4. In that paper, we proposed
Sidhu & Blumer [Page 1]
RFC 964 November 1985
Some Problems with MIL-STD TCP
solutions for all errors except for errors associated with 2 states
whose satisfactory resolution may require redesigning parts of TP4.
Modifications to TP4 specification are currently underway to solve
the remaining incompleteness problems with 2 states. It is important
to emphasize that we did not find any obvious error in the NBS
specification of TP4.
The authors are currently working on the verification of connection
management of the Military Standard Transmission Control Protocol
(TCP). This analysis will be based on the published specification
[MILS83] of TCP dated 12 August 1983.
While studying the MIL standard TCP specification in preparation for
our analysis of the connection management features, we have noticed
several errors in the specification. As a consequence of these
errors, the Transmission Control Protocol (as specified in [MILS83])
will not permit data to be received by TCP entities in SYN_RECVD and
The proof of this statement follows from the specification of the
three-way handshake mechanism of TCP [MILS83] and from a decision
table associated with ESTAB state.
2. Transmission Control Protocol
The Transmission Control Protocol (TCP) is a transport level
connection-oriented protocol in the DoD protocol hierarchy for use in
packet-switched and other networks. Its most important services are
reliable transfer and ordered delivery of data over full-duplex and
flow-controlled virtual connections. TCP is designed to operate
successfully over channels that are inherently unreliable, i.e., they
can lose, damage, duplicate, and reorder packets.
TCP is based, in part, on a protocol discussed by Cerf and Kahn
[CERV74]. Over the years, DARPA has supported specifications of
several versions of this protocol, the last one appeared in [POSJ81].
Some issues in the connection management of this protocol are
discussed in [SUNC78].
A few years ago, DCA decided to standardize TCP for use in DoD
networks and supported formal specification of this protocol
following the design of this protocol discussed in [POSJ81]. A
detailed specification of this protocol given in [MILS83] has been
Show full document text