Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Nov 2000 00:29:32 -0700 (MST)
From:      Charles Mott <cmott@scientech.com>
To:        Archie Cobbs <archie@dellroad.org>
Cc:        Ruslan Ermilov <ru@FreeBSD.ORG>, net@FreeBSD.ORG, Ari Suutari <ari@suutari.iki.fi>
Subject:   Re: libalias: Incremental Update of Internet Checksum
Message-ID:  <Pine.BSF.4.21.0011130015100.50906-100000@carcassonne.scientech.com>
In-Reply-To: <Pine.BSF.4.21.0011122254240.50684-100000@carcassonne.scientech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Ok, ok -- Ruslan is mathematically correct, but
the problem is really neglible, because of how checksums
are commonly verified.  Even if DifferentialChecksum()
incorrectly produces a 0xffff instead of 0x0000, this error
does not affect the verification sum computed by a recipient
machine.

To quote from RF 1624:

   If an end system verifies the checksum by including the checksum
   field itself in the one's complement sum and then comparing the
   result against -0, as recommended by RFC 1071, it does not matter if
   an intermediate system generated a -0 instead of +0 due to the RFC
   1141 property described here.

It would be interesting to do some network surveillance
to see how often 0xffff shows up in checksum fields.

  -- Charles Mott


On Sun, 12 Nov 2000, Charles Mott wrote:
> On Sun, 12 Nov 2000, Archie Cobbs wrote:
> > Ruslan Ermilov writes:
> > > The DifferentialChecksum() function in libalias(3) is used
> > > to efficiently recompute the checksum for altered packets.
> > > Unfortunately, the implementation suffers from the problem
> > > described in RFC 1624.  I have implemented the replacement
> > > for it, using the final formula [4] from the RFC.
> > > 
> > > The attached C program demonstrates the problem as well as
> > > the new implementation.
> > > 
> > > Comments?
> > 
> > Wow.. seems like a pretty important thing to fix.
> > We should try to get this into 4.2 if possible.
> 
> I haven't studied the arithmetic yet, but the problem
> cannot be too serious, or a lot of things would break.
> My guess is that this has to be an "edge effect".
> Since Ruslan's example program showed a delta of 1
> for so many cases, I'm not sure what it means yet.
> 
> I would agree that if there is a problem, it should
> be fixed.
> 
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011130015100.50906-100000>