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>