In some mail from Bernd Eckenfels, sie said:
>
> Hi,
>
> > What he has repeatedly said is that TCP has no record boundaries, so
> > even if you always defragment (that obviously makes filtering easier),
> > you still may get the application data in pieces, i.e. in different
> > packets, for a number of reasons, some of them accidental, some of
> > them intentional. You still might get the PORT command in several
> > pieces.
> Yes. But the KErnel only needs to store little information (at least for
> FTP): If you receive:
>
> PORT 1/packet border/23,13,45,45,4,67
>
> You only need to store about 30 bytes for each NATed FTP Connection between
> two packages. That is no big deal. On the other hand:
And so the niave firewaller believes the problem to be solved.
What the above amounts to is a `layer violation'. The only way to truely
solve the problem and fix the above is to fix it so a `layer violation'
doesn't occur.
How much information do you need to store ?
Well, one record's worth.
How big is one record in FTP ?
I believe it is terminated by LF or CR-LF, if I read the spec. it might even
mention a limit around 512 bytes or so (12:37am right now...)
The kernel needs to store information about where every byte it is buffering
(waiting for a complete record) is found within the TCP stream. Maybe that's
not a lot, but it essentially amounts to the same thing as writing parts
of TCP all over.
I could probably go on...
Darren
References:
|
|
