Re: 2nd try

[Mark Duffy <mduffy@quarrytech.com>]

At 09:58 AM 4/1/2004 -0500, Paul Koning wrote:
> >>>>> "Tero" == Tero Kivinen <kivinen@iki.fi> writes:
>
>  >> Reassembly or reassmebly-like state tracking is not simple,
>  >> although
>
>  Tero> It is not that complicated either. Full reassembly code in the
>  Tero> netbsd kernel is about 200 lines (not counting code for general
>  Tero> queue macros etc), our partial and full reassembly code is
>  Tero> about 1000 lines (it does quite a lot more than only partial
>  Tero> reassembly).
>
>Reassembly isn't all that hard in software, although it gets more
>complicated if you really care about performance when there are a
>large number of simultaneous streams.  But reassembly in hardware is
>quite another matter.
>
>While I'm no great fan of option #2, I feel that requiring it is a
>better choice than requiring reassembly (option #3).
>
>        paul

Not only is it complex to do in hardware, it also can demand a tremendous 
amount of buffering in high speed implementations.  Between the buffering 
issue, and the possible need to handle fragments as a software exception to 
the hardware "fast path", this also opens a DOS opportunity against the 
security gateway.

I believe that option #2 should be the required one and #3 optional.

--Mark