Subject: RE: TCP Checksum Interoperability

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

I'm cross-posting this thread to [email-masked] for archival
purposes, we'll see if any further replies to the ietf list get posted at
[email-masked] too (for instructions to join tcp-impl, see below). My
rationale here is just to try and keep tcp-impl as a good source of material
on tcp/ip implementation issues. It seems you can't post to
[email-masked]' (see also below for discussion on this group).

Sorry, Chris, forgot to copy you on this.

Aloha

Mike Smith
CTO, iReady

To: [email-masked]
Subject: Re: TCP Checksum Interoperability
From: Rob Austein <[email-masked]>
Date: Fri, 05 Apr 2002 14:29:44 -0500
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]
User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2
(Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN)

----------------------------------------------------------------------------
----

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, but one is
(apparently) more surprising to most implementors than the other, due
to the implementation techniques that suggest themselves on most
modern processors.

-----Original Message-----
From: Michael Smith
Sent: Friday, April 05, 2002 10:39 AM
To: [email-masked]'
Cc: Michael Smith
Subject: RE: TCP Checksum Interoperability

Lloyd: your comment is interesting.

I know there hasn't been much activity on tcp-impl, but it's still there.
Allison sent an email a while back encouraging it's use, but I can't find
that just now.

To subscribe (or unsubscribe) to the tcp-impl mailing list, send mail to
[email-masked] with one of the following in the body of the message.

subscribe tcp-impl

unsubscribe tcp-impl

There's also http://groups.yahoo.com/group/tcp-impl/ but activity there
stopped about July 2001. I never understood how the two mailing lists
related, but I posted your mail (below) to both, I hope you don't mind.

Aloha

Mike Smith
CTO, iReady

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Friday, April 05, 2002 4:43 AM
To: Chris Trobridge
Cc: [email-masked]
Subject: Re: TCP Checksum Interoperability

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.

L.

On Fri, 5 Apr 2002, Chris Trobridge wrote:

> I writing to this list because the TCP workgroup was shutdown a while ago.
>
> 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.
>
> 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.
>
> Any thoughts?
>
> Thanks,
> Chris
>

stupid autoappended signatures below.

----------------------------------------------------------------------------
-------------------------------------
> 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.
>
> In addition, certain Marketing collateral may be added from time to time
to
> promote Baltimore Technologies products, services, Global e-Security or
> appearance at trade shows and conferences.
>
> This footnote confirms that this email message has been swept by
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.
>
>

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

-
This message was passed through [email-masked], which
is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 5 Apr 2002 17:09:52 -0500

> From: Joe Touch <[email-masked]>

    >> our interpretation of Robustness Principle applied to this problem
    >> dictated that we .. had to accept either ~(+0) or ~(-0) in received
    >> segments.
    >> Strictly speaking, either zero state is completely legal,

    > as per RFC1624 section 3, only one state (0x0000) is legal as the
    > complement of the checksum of non-zero data. ...
    > ..
    > The receiver is entirely justified in considering 0xffff as an error.

I would tend to disagree strongly with this last line, and agree with the
original statement above.

The TCP (and IP) checksum is defined as "the one's complement of the
one's-complement sum of the packet contents" precisely to allow the following
behaviour: one adds up the incoming packet, *including the checksum as it
sits* (i.e. without having to zero out that field), and then checks to see
that the result is all 1's - which is, as you point out, the only valid zero
value that a one's-complement summation process *of a packet* can compute.

(The only way to get all 0's as a sum of a one's-complement addition
process is to to sum a series of zero's - which a real packet will never
contain.)

Note that if the packet's check sum (i.e. the sum with the checksum field set
to zero) happens to come out to zero (i.e. all one's, before the complement),
then *either* value of zero in the checksum field of the packet will result in
an all-1's sum when the packet is checksummed.

I honestly don't understand why anyone's code even bothers to look at the
actual value in the checksum field of the incoming packet; just do the
checksum of the whole packet, and look at the result.

	Noel

PS: One does have to look at the incoming value for UDP, but that's different.