Damn I'm getting old, for sping, oob killers and the like that wrecked
havoc on the ip stacks of many OS's were only like two or three years out.
And now we have IP frags doing nasty bits...
Time flies when yer past, well, just past <grin>
Thanks,
Ron DuFresne
On Fri, 4 Aug 2000, mouss wrote:
> At 23:58 03/08/00 -0400, Chris Brenton wrote:
> >Problem is not always the IP stack.
>
> I'd say that the problem has rarely been the IP stack.
> The guys who coded the IP stacks id a good job, or at least
> their bugs were corrected a long time ago.
> on the other hand, new comers were:
> - new OS developpers, such as microsofties who met the MFC, the
> microsoft foundation crashes (got nothing against'm, but got nothing
> against laughing at their expenses...)
> - IP filtering coders, and then many got it wrong...
>
>
> >For example in the case of
> >Checkpoint (given the subject line I assume this is what started the
> >thread ;) the problem was:
> >A) No rule processing prior to reassembly so DoS traffic can originate
> >from anywhere
> >B) The method of logging generated a unique log entry for every fragment
> >thus increasing CPU & disk load
> >
> > > RFC815 outlines a very clear and very simple algorithm for correct (and
> > > efficient) reassembly.
> >
> >I think its the old "why address it till its a real problem?" kind of
> >thing. We saw the same thing with the SYN pool a few years back. People
> >knew it was a problem, it was just not addressed till attack tool where
> >created in order to exploit it.
>
>
> please note that RFC815 presents an algorithm for reassembly at the _receiving_
> host. This is different from what we are talking about here. As Paul said,
> gateway
> coders simply do not want to reassemble packets. If they wanted, then they
> could
> have used the existing algorithms. The problem is how to filter fragments
> without
> queuing them. The most "stupid" way is to reassemble all packets, and sure this
> will work, but this eats perfs (see Paul's message). so developpers have
> come with
> methods to check fragments without queuing data (see RFC1858 for example). But
> these techniques took time to come and are yet unknown to most coders.
>
> note also that most problems are also human. A company hires a new developper,
> considers him a guru based on his CV, asks him to code stuff he never heard
> of, and
> can't wait for weeks, since they consider waiting anti-productive. It's
> more productive
> to sell buggy products than! and the worst is that they ar right! most
> customers are
> simply stupid and "want _it_ now because it's in the press today". Until
> some company
> proves that it can get a huge market thanks to real product quality (in the
> FWing area I mean),
> we'll stay with a much-features-much-hype-much-nothing waterwalls.
>
>
> much cheers,
> much mouss
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
