Subject: Re: TCP Checksum Interoperability

From: Michael Smith <[email-masked]>
Date: Fri, 5 Apr 2002 11:50:29 -0800

Forwarding post from ietf list to [email-masked]' (I'm desperately
hoping this doesn't go on for much longer).

Mike Smith
CTO, iReady

Re: TCP Checksum Interoperability

To: Lloyd Wood <[email-masked]> 
Subject: Re: TCP Checksum Interoperability 
From: Joe Touch <[email-masked]> 
Date: Fri, 05 Apr 2002 11:41:08 -0800 
CC: Chris Trobridge <[email-masked]>, [email-masked] 
References:
<[email-masked]> 
Sender: [email-masked] 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9)
Gecko/20020311 

Lloyd Wood wrote:
> See sections 3-5 of RFC1624 for discussion of the one's complement
> problem for the IP header checksum. I presume similar applies for TCP,
> although I don't know offhand if it's written down anywhere.

RFC793 describes the use of 1's complement as the TCP checksum.

A TCP checksum can never be 0x0000, by the same argument of RFC1624, 
since the TCP header length is never 0.

Most of RFC1624 is clarification of the mathematical properties of 1's 
complement arithmetic; it's not specific to IP.

>>We have a compatibility problem between two third party implementations of
>>the TCP checksum.
>>
>>The problem concerns the representation of zero, which has two 1-s
>>complement representations (0000 and ffff).
>>
>>We don't have source to either stack but I managed to deduce the problem
>>from looking at a packet trace.  The receiver drops all datagrams
containing
>>a TCP with a TCP checksum of ffff.
>>
>>The receiver appears to be following the checksum procedure in the RFC
>>literally - ie zero checksum, recalculate and check that the result is the
>>complement of what the sender sent.  The problem is that the sender and
>>receiver don't agree about zero and hence the datagram is dropped
silently.
>>
>>My view is that the receiver is in error; it should be checking the
special
>>case of 0.

The sender is in error. As noted in RFC1624, there is no summation of 
words which yields a 1's complement sum of 0x0000 except all zeroes, 
which can't occur because (as above) the TCP header length renders at 
least one word non-zero.

Since the TCP checksum is the 1's complement of the sum, and 0x0000 
cannot occur as a sum, 0xffff cannot occur as a valid TCP checksum.

It would be useful to check the math used at the source to compute the 
checksum. It is likely there is an error, in particular, see section 3 
of RFC1624 for one typical one.

>>All the receiver code I have seen doesn't work this way.  The normal
>>approach is to calculate the1-s complement sum with checksum in place and
>>check that this is zero.  The methods I konw always return just one
>>representation for zero, hence there is no special case.

As per RFC1624, that depends on the inputs. Nonzero inputs generate only 
0xffff as a sum, it takes all-zeroes to generate 0x0000 as a sum, but, 
as per above, that can't occur.

Joe

References: 
Re: TCP Checksum Interoperability 
From: Lloyd Wood <[email-masked]>
Prev by Date: Re: draft-iab-unsaf-considerations-01.txt 
Prev by thread: Re: TCP Checksum Interoperability 
Next by thread: Re: TCP Checksum Interoperability 
Index(es): 
Date 
Thread

---

From: Chris Trobridge <[email-masked]>
Date: Mon, 8 Apr 2002 15:30:18 +0100

FYI, The 'offending' stacks are PC/TCP (reception) and in Open VMS
(transmission).

This is an age-old issue; the following dates from 1985(!):

http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8502.mm.www/0389.html

I think RFC 1624 is missing the UDP case, where +0 means "not calculated".
Indeed, RFC 768 asserts that the two values (+0 and -0) are equivalent.

Part of the problem is that there isn't an RFC standard that deals with the
issue of a zero checksum, apart from for UDP.

The protocol RFCs don't specify the details and the implementation RFCs
(1071, 1141, 1624) state explicitly that they are not standards, "It is not
a standard, but a set of useful implementation techniques".

They are a very good idea but not mandatory.

That's why I said I thought the receiver wasn't compliant: it rejects -0 as
invalid.

Chris

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: 05 April 2002 21:45
> To: Michael Smith
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]';
> [email-masked]'
> Subject: RE: TCP Checksum Interoperability
> 
> 
> On Fri, 5 Apr 2002, Michael Smith wrote:
> 
> > The last time this came up for a TCP implementation I used to
> > maintain, our interpretation of Robustness Principle applied to this
> > problem dictated that we shouldn't send segments with 
> checksum fields
> > set to all ones (that is, we shouldn't send ~(+0)), but 
> that we had to
> > accept either ~(+0) or ~(-0) in received segments.
> >
> > Strictly speaking, either zero state is completely legal
> 
> Not so. Please read RFC1624 sections 3-5.
> 
> L.
> 
> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> 
> 

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.
 
This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.

http://www.baltimore.com

---

From: Bob Braden <[email-masked]>
Date: Mon, 8 Apr 2002 16:41:12 GMT

I have filed this conversation away in my "cksum" folder.  The
previous messages in the folder are from 1988-1990 (I surely
must have missed some in between!).  For those with a nostalgic
bent, the earlier messages were sent to the tcp-ip mailing list.

Bob Braden