Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Jan 2000 19:12:25 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        Don Lewis <Don.Lewis@tsc.tdk.com>, Brett Glass <brett@lariat.org>
Cc:        freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject:   Re: Re[2]: explanation and code for stream.c issues
Message-ID:  <200001230312.TAA18497@salsa.gv.tsc.tdk.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001230312.TAA18497>