On 2004-08-30, Mike Frantzen <frantzen@nfr.com> wrote:
This is going to be an extremely controversial answer that the security
purists probably will not like. But they're fun to piss off so here goes.
Hehhehe, while my job at Reflex is leading our IPS development, my
research at the GTISC is a bit more pure -- I hope my somewhat
theoretically-minded answer earlier didn't paint me an ivory
towerist :D. Regarding your well thought-out comments:
The real benefit of a full fledged TCP state machine is knowing when to
expire an idle connection. If we expire a connection too early, then
the next packet that comes in on it will appear to be a new connection
and several things may happen:
You list several problems with timing out sessions too early, but none
with timing them out too late. For the sake of argument, what problems
do you see with simply idling out via necessities of LRU applied to a
fixed-size flow cache (obviously, sessions could still be closed based
on 4-way TCP teardown, RST abortion or SYN/OOW xmit, modulo the guesswork
typically involved in such)? A much less intensive state machine can be
developed in this case, if one's merely concerned with the problems
you've raised (I noted several other benefits from a detection
standpoint in my earlier answer).
3) you lose the TCP window scale value
4) the connection will break if you only allow state creation on a SYN
5) any sequence number modulation will break the connection
6) any TCP timestamp modulation will probably break the connection
Are these not issues arising from the use of a half-hearted attempt at
TCP tracking, as opposed to a lack thereof in toto?
--
nick black "np: the class of dashed hopes and idle dreams."
