rfc964.txt

RFC 相关的技术文档

RFC 964                                                    November 1985
Some Problems with MIL-STD TCP


      Transition 3 (Entity B goes from state LISTEN to state SYN_RECVD).
      Entity B receives the SYN segment accompanying data sent by entity
      A.

         Actions: (see p. 106)
            (since this segment has no RESET, no ACK, does have SYN, and
            we assume reasonable security and precedence parameters, row
            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 then
                  send_una := seg.ack_num;                   [no change]
               accept_policy; (see p. 131)
                  Accept in-order data only:
                     Acceptance Test is
                        seg.seq_num = recv_next;
                  Accept any data within the receive window:
                     Acceptance Test has two parts
                        recv_next =< seg.seq_num =< recv_next +
                                                               recv_wndw
                        or
                        recv_next =< seg.seq_num + length =<
                                                   recv_next + recv_wndw
                        ********************************************
                           An error occurs here, with either possible
                           strategy given in accept_policy, because
                           recv_next > seg.seq_num.  Therefore
                           accept_policy will incorrectly indicate that
                           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 TCP


      Transition 4 (entity A goes from state SYN_SENT to ESTAB) Entity A
      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 function
            ACK_status_test1.
               ACK_status_test1();
                  if(seg.ack_flag = FALSE) then
                     return(NONE);
                  if(seg.ack_num <= send_una) or
                     (seg.ack_num > send_next) then
                        return(INVALID)
                  else
                     return(VALID);

                  ... and so on.

      The important thing to notice in the above scenario is the error
      that occurs in transition 3, where the wrong value for recv_next
      leads to the routine record_syn refusing to accept the data.

   Problem 2:  Problem with Retransmission of SYN Packet

      The actions listed for Active Open (with or without data; see p.
      103) are calls to the routines open and gen_syn.  Neither of these
      routines (or routines that they call) explicitly sets a
      retransmission timer.  Therefore if the initial SYN is lost there
      is no timer expiration to trigger retransmission of the SYN.  If
      this happens, the TCP will fail in its attempt to establish the
      desired connection with a remote TCP.

      Note that this differs with the actions specified for transmission
      of data from the ESTAB state.  In that transition the routine
      dispatch (p. 137) is called first which in turn calls the routine
      send_new_data (p.  156).  One of actions of the last routine is to
      start a retransmission timer for the newly sent data.












Sidhu & Blumer                                                  [Page 7]



RFC 964                                                    November 1985
Some Problems with MIL-STD TCP


   Problem 3:  Problem with Receiving Data in TCP ESTAB State

      When both entities are in the state ESTAB, and one sends data to
      the other, an error in the actions of the receiver prohibits the
      data from being accepted.  The following simple scenario
      illustrates the problem.  Here the user associated with entity A
      issues a Send request, and A sends data to entity B.  When B
      receives the data it replies with an acknowledgment.

      TCP entity A                                          TCP entity B
      ------------                                          ------------

      state                segment         segment          state
      transition           recvd or sent   recvd or sent    transition
                           by A            by B

      ESTAB -> ESTAB       DATA -->

                                           DATA -->       ESTAB -> ESTAB
                                           <-- ACK

      Transition 1 (entity A goes from state ESTAB to ESTAB) Entity A
      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 B
      receives data packet from entity B.

         Actions: (see p. 111)
            Assuming the data is in order and valid, we use row 6 of the
            table.
            update; (see p. 159)
            ************************************************************
               An error occurs here, because the routine update does
               nothing to accept the incoming data, or to arrange to
               pass it on to the user.
            ************************************************************










Sidhu & Blumer                                                  [Page 8]



RFC 964                                                    November 1985
Some Problems with MIL-STD TCP


5.  Solutions to Problems

   The problem with record_syn and accept_policy can be solved by having
   record_syn call accept_policy before the variable recv_next is
   updated.

   The problem with gen_syn can be corrected by having gen_syn or open
   explicitly request the retransmission timer.

   The problem with the reception of data in the ESTAB state is
   apparently caused by the transposition of the action tables on pages
   111 and 112.  These tables should be interchanged.  This solution
   will also correct a related problem, namely that an entity can never
   reach the CLOSE_WAIT state from the ESTAB state.

   Syntax errors in the action statements and tables could be easily
   caught by an automatic syntax checker if the document used a more
   formal description technique.  This would be difficult to do for
   [MILS83] since this document is not based on a formalized description
   technique [BREM83].

   The errors pointed out in this note have been submitted to DCA and
   will be corrected in the next update of the MIL STD TCP
   specification.

6.  Implementation of MIL Standard TCP

   In the discussion above, we pointed out several serious errors in the
   specification of the Military Standard Transmission Control Protocol
   [MILS83].  These errors imply that a TCP implementation that
   faithfully conforms to the Military TCP standard will not be able to

      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 MIL
   Standard TCP [MILS83] must include corrections mentioned above to get
   a running TCP.

   The problems pointed out in this paper with the current specification
   of the MIL Standard TCP [MILS83] are based on an initial
   investigation of this protocol standard by the authors.




Sidhu & Blumer                                                  [Page 9]



RFC 964                                                    November 1985
Some Problems with MIL-STD TCP


REFERENCES

   [BLUT83]  Blumer, T. P., and Sidhu, D. P., "Mechanical Verification
             and Automatic Implementation of Authentication Protocols
             for Computer Networks", SDC Burroughs Report (1983),
             submitted for publication.

   [BLUT82]  Blumer, T. P., and Tenney, R. L., "A Formal Specification
             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 of
             DoD Protocol Specification Technique", SDC - Burroughs
             Report 1983.

   [CERV74]  Cerf, V., and Kahn, R., "A Protocol for Packet Network
             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 Control
             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 Class
             4 Transport Protocol", SDC Burroughs Report (1983),
             submitted for publication.

   [SUNC78]  Sunshine, C., and Dalal, Y., "Connection Management in
             Transport Protocols", Computer Networks, Vol. 2, pp.454-473
             (1978).
















Sidhu & Blumer                                                 [Page 10]