From owner-freebsd-net Tue Nov 14 19:15:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 5683E37B4CF; Tue, 14 Nov 2000 19:15:24 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAF3FIG60231; Tue, 14 Nov 2000 22:15:19 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011150315.eAF3FIG60231@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Charles Mott Cc: Archie Cobbs , Ruslan Ermilov , net@FreeBSD.ORG, Ari Suutari X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: In-reply-to: Your message of "Mon, 13 Nov 2000 00:29:32 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 2000 22:15:18 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Arithmetically, a value of 0xffff is identical to 0x0000 since they both represent the value of zero when using a one's complement binary representation of values. It turns that this property is used in some network protocols (e.g., UDP) to distinguish between a checksum value that's computed as zero (represented as 0xffff in the packet) from a packet which has no computed checksum at all. This was done in the dark ages when it was deemed "too expensive" to compute a checksum. louie > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message