As per Relevance of the word standard, we have this rfc below:
Network Working Group Deepinder P.
Request for Comments: 964 Thomas P.
SDC - A Burroughs
November 1985
SOME PROBLEMS WITH THE SPECIFICATION OF
MILITARY STANDARD TRANSMISSION CONTROL
STATUS OF THIS
The purpose of this RFC is to provide helpful information on
Military Standard Transmission Control Protocol (MIL-STD-1778)
that one can obtain a reliable implementation of this
standard. Distribution of this note is unlimited
Reprinted from: Proc. Protocol Specification, Testing
Verification IV, (ed.) Y. Yemini, et al, North-Holland (1984).
This note points out three errors with the specification of
Military Standard Transmission Control Protocol (MIL-STD-1778,
August 1983 [MILS83]). These results are based on an
investigation of this protocol standard. The first problem is
data accompanying a SYN can not be accepted because of errors in
acceptance policy. The second problem is that no
timer is set for a SYN packet, and therefore the SYN will not
retransmitted if it is lost. The third problem is that when
connection has been established, neither entity takes the
steps to accept incoming data. This note also proposes solutions
these problems
1.
In recent years, much progress has been made in creating
integrated set of tools for developing reliable
protocols. These tools provide assistance in the specification
verification, implementation and testing of protocols.
protocols have been analyzed and developed using such tools
In a recent paper, the authors discussed the verification of
connection management of NBS class 4 transport protocol (TP4).
verification was carried out with the help of a software tool
developed [BLUT82] [BLUT83] [SIDD83]. In spite of the very
specification of this protocol, our analysis discovered
errors in the current specification of NBS TP4. These errors
incompleteness errors in the specification, that is, states
there is no transition for the reception of some input event.
analysis did not find deadlocks, livelocks or any other problem
the connection management of TP4. In that paper, we
Sidhu & Blumer [Page 1]
RFC 964 November 1985
Some Problems with MIL-STD
solutions for all errors except for errors associated with 2
whose satisfactory resolution may require redesigning parts of TP4.
Modifications to TP4 specification are currently underway to
the remaining incompleteness problems with 2 states. It is
to emphasize that we did not find any obvious error in the
specification of TP4.
The authors are currently working on the verification of
management of the Military Standard Transmission Control
(TCP). This analysis will be based on the published
[MILS83] of TCP dated 12 August 1983.
While studying the MIL standard TCP specification in preparation
our analysis of the connection management features, we have
several errors in the specification. As a consequence of
errors, the Transmission Control Protocol (as specified in [MILS83])
will not permit data to be received by TCP entities in SYN_RECVD
ESTAB states
The proof of this statement follows from the specification of
three-way handshake mechanism of TCP [MILS83] and from a
table associated with ESTAB state
2. Transmission Control
The Transmission Control Protocol (TCP) is a transport
connection-oriented protocol in the DoD protocol hierarchy for use
packet-switched and other networks. Its most important services
reliable transfer and ordered delivery of data over full-duplex
flow-controlled virtual connections. TCP is designed to
successfully over channels that are inherently unreliable, i.e.,
can lose, damage, duplicate, and reorder packets
TCP is based, in part, on a protocol discussed by Cerf and
[CERV74]. Over the years, DARPA has supported specifications
several versions of this protocol, the last one appeared in [POSJ81].
Some issues in the connection management of this protocol
discussed in [SUNC78].
A few years ago, DCA decided to standardize TCP for use in
networks and supported formal specification of this
following the design of this protocol discussed in [POSJ81].
detailed specification of this protocol given in [MILS83] has
adopted as the DoD standard for the Transmission Control Protocol,
reliable connection-oriented transport protocol for DoD networks
A TCP connection progresses through three phases: opening (
Sidhu & Blumer [Page 2]
RFC 964 November 1985
Some Problems with MIL-STD
synchronization), maintenance, and closing. In this note we
data transfer in the opening and maintenance phases of
connection
3. Problems with MIL Standard
One basic feature of TCP is the three-way handshake which is used
set up a properly synchronized connection between two remote
entities. This mechanism is incorrectly specified in the
specification of TCP. One problem is that data associated with
SYN packet can not be delivered. This results from an
specification of the interaction between the accept_policy
procedure and the record_syn action procedure. Neither of the 2
possible strategies suggested in accept_policy will give the
result when called from the record_syn procedure, because
recv_next variable is updated in record_syn before the accept_
procedure is called
Another problem with the specification of the three-way handshake
apparent in the actions listed for the Active Open event (with
without data) when in the CLOSED state. No retransmission timer
set in these actions, and therefore if the initial SYN is lost,
will be no timer expiration to trigger retransmission. This
prevent connection establishment if the initial SYN packet is lost
the network
The third problem with the specification is that the actions
receiving data in the ESTAB state are incorrect. The accept
procedure must be called when data is received, so that arriving
may be queued and possibly passed to the user
A general problem with this specification is that the
language and action table portions of the specification were
not checked by any automatic syntax checking process.
variable and procedure names are misspelled, and the syntax of
action statements is often incorrect. This can be confusing
especially when a procedure name cannot be found in the
list of procedures because of misspelling
These are some of the very serious errors that we have
with the MIL standard TCP
Sidhu & Blumer [Page 3]
RFC 964 November 1985
Some Problems with MIL-STD
4. Detailed Discussion of the
Problem 1: Problem with Receiving Data Accompanying
The following scenario traces the actions of 2
entities during the establishment of a connection. Only
simplest case is considered, i.e., the case where the
is established by the exchange of 3 segments
TCP entity A TCP entity
------------ ------------
state segment segment
transition recvd or sent recvd or sent
by A by
CLOSED ->
CLOSED -> SYN_SENT SYN -->
SYN --> LISTEN -> SYN_
<-- SYN
SYN_SENT -> ESTAB <-- SYN
ACK -->
ACK --> SYN_RECVD ->
As shown in the above diagram, 5 state transitions occur and 3
segments are exchanged during the simplest case of the three-
handshake. We now examine in detail the actions of each
during this exchange. Special attention is given to the
numbers carried in each packet and recorded in the state
of each entity
In the diagram below, the actions occurring within a procedure
shown indented from the procedure call. The resulting values
sequence number variables are shown in square brackets to
right of each statement. The sequence number variables are
with the entity name (A or B) as prefix so that the two sets
state variables may be easily distinguished
Sidhu & Blumer [Page 4]
RFC 964 November 1985
Some Problems with MIL-STD
Transition 1 (entity B goes from state CLOSED to state LISTEN).
The user associated with entity B issues a Passive Open
Actions: (see p. 104)
open; (see p. 144)
new state := LISTEN
Transition 2 (entity A goes from state CLOSED to SYN_SENT).
user associated with entity A issues an Active Open with Data
Actions: (see p. 104)
open; (see p. 144)
gen_syn(WITH_DATA); (see p. 141)
send_isn := gen_isn(); [A.send_isn = 100]
send_next := send_isn + 1; [A.send_next = 101]
send_una := send_isn; [A.send_una = 100]
seg.seq_num := send_isn; [seg.seq_num = 100]
seg.ack_flag := FALSE; [seg.ack_flag = FALSE
seg.wndw := 0; [seg.wndw = 0]
amount := send_policy() [assume amount > 0]
new state := SYN_SENT
Sidhu & Blumer [Page 5]
RFC 964 November 1985
Some Problems with MIL-STD
Transition 3 (Entity B goes from state LISTEN to state SYN_RECVD).
Entity B receives the SYN segment accompanying data sent by
A
Actions: (see p. 106)
(since this segment has no RESET, no ACK, does have SYN,
we assume reasonable security and precedence parameters,
3 of the table applies
record_syn; (see p. 147)
recv_isn := seg.seq_num; [B.recv_isn = seg_seq_num = 100]
recv_next := recv_isn + 1; [B.recv_next = 101]
if seg.ack_flag
send_una := seg.ack_num; [no change
accept_policy; (see p. 131)
Accept in-order data only
Acceptance Test
seg.seq_num = recv_next
Accept any data within the receive window
Acceptance Test has two
recv_next =< seg.seq_num =< recv_next +
recv_
recv_next =< seg.seq_num + length =<
recv_next + recv_
********************************************
An error occurs here, with either
strategy given in accept_policy,
recv_next > seg.seq_num.
accept_policy will incorrectly indicate
the data cannot be accepted
********************************************
gen_syn(WITH_ACK); (see p. 141)
send_isn := gen_isn(); [B.send_isn = 300]
send_next := send_isn + 1; [B.send_next = 301]
send_una := send_isn; [B.send_una = 300]
seg.seq_num := send_next; [seg.seq_num = 301]
seg.ack_flag := TRUE; [seg.ack_flag = TRUE
seg.ack_num := recv_isn + 1; [seg.ack_num = 102]
new state := SYN_RECVD
Sidhu & Blumer [Page 6]
RFC 964 November 1985
Some Problems with MIL-STD
Transition 4 (entity A goes from state SYN_SENT to ESTAB) Entity
receives the SYN ACK sent by entity B
Actions: (see p. 107)
In order to select the applicable row of the table on p
107, we first evaluate the decision
ACK_status_test1.
ACK_status_test1();
if(seg.ack_flag = FALSE)
return(NONE);
if(seg.ack_num <= send_una)
(seg.ack_num > send_next)
return(INVALID
return(VALID);
... and so on
The important thing to notice in the above scenario is the
that occurs in transition 3, where the wrong value for recv_
leads to the routine record_syn refusing to accept the data
Problem 2: Problem with Retransmission of SYN
The actions listed for Active Open (with or without data; see p
103) are calls to the routines open and gen_syn. Neither of
routines (or routines that they call) explicitly sets
retransmission timer. Therefore if the initial SYN is lost
is no timer expiration to trigger retransmission of the SYN.
this happens, the TCP will fail in its attempt to establish
desired connection with a remote TCP
Note that this differs with the actions specified for
of data from the ESTAB state. In that transition the
dispatch (p. 137) is called first which in turn calls the
send_new_data (p. 156). One of actions of the last routine is
start a retransmission timer for the newly sent data
Sidhu & Blumer [Page 7]
RFC 964 November 1985
Some Problems with MIL-STD
Problem 3: Problem with Receiving Data in TCP ESTAB
When both entities are in the state ESTAB, and one sends data
the other, an error in the actions of the receiver prohibits
data from being accepted. The following simple
illustrates the problem. Here the user associated with entity
issues a Send request, and A sends data to entity B. When
receives the data it replies with an acknowledgment
TCP entity A TCP entity
------------ ------------
state segment segment
transition recvd or sent recvd or sent
by A by
ESTAB -> ESTAB DATA -->
DATA --> ESTAB ->
<--
Transition 1 (entity A goes from state ESTAB to ESTAB) Entity
sends data packet to entity B
Actions: (see p. 110)
dispatch; (see p. 137)
Transition 2 (entity B goes from state ESTAB to ESTAB) Entity
receives data packet from entity B
Actions: (see p. 111)
Assuming the data is in order and valid, we use row 6 of
table
update; (see p. 159)
************************************************************
An error occurs here, because the routine update
nothing to accept the incoming data, or to arrange
pass it on to the user
************************************************************
Sidhu & Blumer [Page 8]
RFC 964 November 1985
Some Problems with MIL-STD
5. Solutions to
The problem with record_syn and accept_policy can be solved by
record_syn call accept_policy before the variable recv_next
updated
The problem with gen_syn can be corrected by having gen_syn or
explicitly request the retransmission timer
The problem with the reception of data in the ESTAB state
apparently caused by the transposition of the action tables on
111 and 112. These tables should be interchanged. This
will also correct a related problem, namely that an entity can
reach the CLOSE_WAIT state from the ESTAB state
Syntax errors in the action statements and tables could be
caught by an automatic syntax checker if the document used a
formal description technique. This would be difficult to do
[MILS83] since this document is not based on a formalized
technique [BREM83].
The errors pointed out in this note have been submitted to DCA
will be corrected in the next update of the MIL STD
specification
6. Implementation of MIL Standard
In the discussion above, we pointed out several serious errors in
specification of the Military Standard Transmission Control
[MILS83]. These errors imply that a TCP implementation
faithfully conforms to the Military TCP standard will not be able
Receive data sent with a SYN packet
Establish a connection if the initial SYN packet is lost
Receive data when in the ESTAB state
It also follows from our discussion that an implementation of
Standard TCP [MILS83] must include corrections mentioned above to
a running TCP
The problems pointed out in this paper with the current
of the MIL Standard TCP [MILS83] are based on an
investigation of this protocol standard by the authors
Sidhu & Blumer [Page 9]
RFC 964 November 1985
Some Problems with MIL-STD
[BLUT83] Blumer, T. P., and Sidhu, D. P., "Mechanical
and Automatic Implementation of Authentication
for Computer Networks", SDC Burroughs Report (1983),
submitted for publication
[BLUT82] Blumer, T. P., and Tenney, R. L., "A Formal
Technique and Implementation Method for Protocols",
Computer Networks, Vol. 6, No. 3, July 1982, pp. 201-217.
[BREM83] Breslin, M., Pollack, R. and Sidhu D. P., "Formalization
DoD Protocol Specification Technique", SDC -
Report 1983.
[CERV74] Cerf, V., and Kahn, R., "A Protocol for Packet
Interconnection", IEEE Trans. Comm., May 1974.
[MILS83] "Military Standard Transmission Control Protocol",
MIL-STD-1778, 12 August 1983.
[POSJ81] Postel, J. (ed.), "DoD Standard Transmission
Protocol", Defense Advanced Research Projects Agency
Information Processing Techniques Office, RFC-793,
September 1981.
[SIDD83] Sidhu, D. P., and Blumer, T. P., "Verification of NBS
4 Transport Protocol", SDC Burroughs Report (1983),
submitted for publication
[SUNC78] Sunshine, C., and Dalal, Y., "Connection Management
Transport Protocols", Computer Networks, Vol. 2, pp.454-473
(1978).
Sidhu & Blumer [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
