From owner-freebsd-net  Sat Jan 22 19:12:40 2000
Delivered-To: freebsd-net@freebsd.org
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 90FF014F24; Sat, 22 Jan 2000 19:12:29 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id TAA27114;
	Sat, 22 Jan 2000 19:12:26 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id TAA58575;
	Sat, 22 Jan 2000 19:12:26 -0800 (PST)
	(envelope-from Don.Lewis@tsc.tdk.com)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id TAA18497;
	Sat, 22 Jan 2000 19:12:25 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <200001230312.TAA18497@salsa.gv.tsc.tdk.com>
Date: Sat, 22 Jan 2000 19:12:25 -0800
In-Reply-To: <200001230306.TAA18458@salsa.gv.tsc.tdk.com>
References: <Vladimir Dubrovin <vlad@sandy.ru> <4.2.2.20000122083929.01a5aa90@localhost> <200001230306.TAA18458@salsa.gv.tsc.tdk.com>
X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98)
To: Don Lewis <Don.Lewis@tsc.tdk.com>, Brett Glass <brett@lariat.org>
Subject: Re: Re[2]: explanation and code for stream.c issues
Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

We really should move this conversation from -security to -net.
Followups to -net, only.

On Jan 22,  7:06pm, Don Lewis wrote:
} Subject: Re: Re[2]: explanation and code for stream.c issues
} On Jan 22,  8:52am, Brett Glass wrote:
} } Subject: Re: Re[2]: explanation and code for stream.c issues
} 
} } True. But y'know, he does have a point. Shouldn't tcp_input() drop
} } or reject anything with certain combinations of flags really early on?
} } 
} } About 15 years ago (has it been that long?) I wrote part of a TCP/IP
} } stack for a class at Stanford. The first statement in the routine
} } which was the equivalent of tcp_input() checksummed the packet.
} } The second one was a "case" (this was Pascal) that broke out
} } cases for every combination of the TCP option flags. (The
} } compiler implemented case statements as jump tables, so this
} } was fast.)
} } 
} } Do you think it's worth doing that here, both for clarity and
} } for speed? It would probably help to catch all the issues involving
} } option flags, and it would be more efficient than the current
} } structure (which does lots of tests one at a time and is harder to
} } follow).
} 
} The current code was written for speed rather than for clarity and
} tries to optimize the most commonly used path through the code.
} In the old days, CPUs were slow.  Today, contemplate gigabit Ethernet ...
} 
} I suspect that if you try to implement this as a big switch, you'll
} end up with either a lot of duplicate code or a bunch of gotos, and
} a lot of what happens depends at least as much on the state of the
} connection.  Don't forget that the SYN and FIN bits can be trimmed
} off if they fall outside the window.  RST is more of a unique case,
} but even it needs to pass sequence checks that depend on the state
} of the connection.
} 
} I'm wondering if it might make more sense to generate IPv4 and IPv6
} version unique versions of the code from a common m4 or cpp ancestor
} rather than to fill the code with a mass of ifdefs and inline protocol
} version tests.


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