OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
FreeBSD Security Archives: Re: Re[2]: explanation and code for

Re: Re[2]: explanation and code for stream.c issues

Subject: Re: Re[2]: explanation and code for stream.c issues
From: Don Lewis (Don.Lewistsc.tdk.com)
Date: Sat Jan 22 2000 - 21:12:25 CST

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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

This archive was generated by hypermail 2b27 : Sat Jan 22 2000 - 21:13:47 CST