Wrong TCP checksum computation when IP Source Route Option is specified


ROKI@D.ISI.EDU
8 Aug 1986 07:09:01 EDT


Folks,

Following is a short description of a problem which seems to be a bug in
the TCP-IP code at D.ISI.EDU [10.0.0.27] (Tops20) concerning the computation
of a wrong TCP checksum when an IP Source Route Option is specified.

While the fact that a problem exists has been evident (after exchanging a
number of correct (!) packets) in each TCP connection from DFVLR2 [128.7.0.2]
via DFVLR4-X25 [14.0.0.16] (specified as IP Source Route Option) to
D.ISI.EDU [10.0.0.27], it was much more difficult to discover the bug.
Since this problem might occur on other TOPS20 machines as well, I am
sending this message not only to the host administrator of D.ISI.EDU, but
to the TCP-IP and INENG-TF list as well.

INTERNET Configuration:
----------------------

To route packets from the (SATNET isolated) DFVLR-net [128.7.x.x] to
D.ISI.EDU [10.0.0.27] through the PDN [14.x.x.x] and to get packets back
on the same path via the BBN-VAN-GW [14.0.0.10] and DFVLR4-X25 [14.0.0.16],
in the current (poor) routing situation, the local VAN-GW (DFVLR4-X25),
has to be specified as an IP Source Route Option by an user on the DFVLR-net.

  DFVLR2 DFVLR4-X25 BBN-VAN-GW D.ISI.EDU

[128.7.0.2] [128.7.0.4,14.0.0.16] [14.0.0.10,10.3.0.40] [10.0.0.27]

      DFVLR-net ! PDN ! ARPANET
                                  ^
                              Monitoring

Fortunately D.ISI.EDU uses the specified IP Source Route Option [14.0.0.16]
even in its reply packets and therefore after opening an TCP connection to
D.ISI.EDU packets were routed back on the same path via DFVLR4-X25 to DFVLR2
and received there correctly.

However after receiving a number of packets with a correct TCP checksum at
DFVLR2, only packets (retransmissions) with a bad TCP checksum were
received and therefore discarded, so the connection was blocked (no more
data exchange).

After implementing some monitor tools behind the X.25 interface at
DFVLR4-X25 (monitoring the packets as transmitted over X.25 PDN), I found
that those packets look fine (no corruption), but already contain a wrong
TCP checksum.

TCP-checksum:
------------

As you know the TCP checksum also covers a 96 bit pseudo header which contains
the Source Address, Destination Address, Protocol and TCP length.

When recomputing the TCP checksum (TCP header + data + pseudo header) using
a pseudo header of

 10 0 0 27
128 7 0 2
  0 6 length

I got another TCP checksum as contained in the packet. Since the TCP header
and the data looked fine, I played around with some possible computations of
modified TCP pseudo headers and finally (surprise !) I got the same (wrong)
TCP checksum as transmitted in the packet, when using a Destination Address
of 14.0.0.16, which is the Destination Address in the IP Header before the
packet reaches DFVLR4-X25 [14.0.0.16] (IP Source Route Option), but must
never be specified as the Destination Address in the TCP Pseudo Header.

Thus with the following TCP pseudo header:

 10 0 0 27
 14 0 0 16 (instead of 128 7 0 2)
  0 6 length

I computed the TCP checksum contained in the packet.

Assuming that no intermediate host or gateway between D.ISI.EDU and
DFVLR4-X25 recomputes the TCP checksum, I guess that the wrong TCP checksum
is already computed at the source (D.ISI.EDU).

NOTE: Before receiving packets with this bad TCP checksum (14.0.0.16 as
      Destination Address in TCP pseudo header), I am receiving packets
      with correct TCP checksum (128.7.0.2). I have no idea what causes this
      switch, however I have found packets (in which 14.0.0.16 is used to
      compute the TCP checksum) only in packets with an ODD (!) number of data
      bytes.

Monitoring Dump:
---------------

Herewith I enclose a dump of two packets (both might be retransmissions),
which were received immediately one after the other over an virtual circuit
through PDN (X.25) from the BBN-VAN-GW at DFVLR4-X25 (dumped immediately
after the X.25 interface).

While the first packet (IP Source Route specified, ACK only, 52 bytes, 0 data
bytes) contains a correct TCP checksum (assuming 128.7.0.2 as destination
in the TCP pseudo header), the TCP checksum computation of the second packet
(IP Source Route, 53 bytes, 1 data byte (@)) seems to use 14.0.0.16 as the
destination address in the TCP pseudo header. A bad TCP checksum was
therefore computed at the destination DFVLR2 [128.7.0.2] and the packet
was discarded.

Good packet (IP Source Route specified, ACK only, 52 bytes, 0 data bytes):
-------------------------------------------------------------------------

 72 0 0 52 83 135 0 0 58 6 98 125 10 0 0 27 14 0 0 16
VIHL TOS Length Ident. Fl/Frag TTL Pro HChksum Source Destination

131 11 8 10 0 0 27 128 7 0 2 0 0 23 16 0 52 151 0 203
SRR len poi route (source) (destination) pad !SPort DPort Sequence Numb.

  4 165 127 231 80 16 3 190 87 237 0 0
Acknowl. number Offs ACK Window Chksum Urg.Poi
                                 TCP OK

TCP Pseudo Header:

 10 0 0 27 128 7 0 2 0 6 0 20
 Source Address Destin. Address Zer PTCL length

Bad packet (IP Source Route specified, ACK only, 52 bytes, 0 data bytes):
-------------------------------------------------------------------------

 72 0 0 53 79 175 0 0 54 6 106 84 10 0 0 27 14 0 0 16
VIHL TOS Length Ident. Fl/Frag TTL Pro HChksum Source Destination

131 11 8 10 0 0 27 128 7 0 2 0 0 23 16 0 52 151 0 202
SRR len poi route (source) (destination) pad !SPort DPort Sequence Numb.

  4 165 127 231 80 24 3 190 137 222 0 0 64 (0)
Acknowl. number Offs ACK Window Chksum Urg.Poi !Data
                     PSH TCP BAD,
                                should be
                                 23 229

Assumed TCP Pseudo Header:

 10 0 0 27 14 0 0 16 0 6 0 21
 Source Address Destin. Address Zer PTCL length
                should be
                128 7 0 2

Debugging:
---------

For a debugging session similar packets should be reproduceable. Does anybody
has seen similar problems ? (Perhaps somebody could try !?)

Thanks for any comments and fixing the problem.

Best regards,

Carl-H. Rokitansky (Roki)
--------------------------

PS.: Currently I'm routing my packets by means of a cludge (assignment of
     [14.0.0.16] to DFVLR2 !!)
-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:35 GMT