hi suresh,
explanation of possible DOS attack :
if either of the client/server in a TCP connection is advertising a
large window then it is possible the other end might send only part of
the data falling withing the window(causing them to be stored in the
buffers) say window is 64k but server sent everything except first 1k(so
rest of 63k shud be buffered).. this may result in DOS attack if
multiple such connections are opened..
but now by some googling i came to know that linux stack automatically
tunes the window sizes if there is memory crunch...
now i am facing a problem :
in client i am advertising a large window(64k) with setsockopt but in
the tcpdump the client window is changing b/n 5840 to 14170....
how can i make sure that client sends window size equal to 64k..???
when did getsockopt to display rcvbuf it is showing it as 131070(which
is greater than 64k)... does this rcvbuf has anything do with tcp
window??
On Fri, 2004-03-26 at 11:15, suresh kumar wrote:
>
>
> hello list members,
> this is regarding linux tcp implementation ..
> if a tcp client application is requesting large receive window using
> setsockopt..
> and is opening multiple connections to different servers...
> there is a possiblity that tcp buffers might get exhausted(in scenarios
> where there is lot of congestion or when a server is deliberately
> sending only some packets in the advertised window whereby the native
> tcp has to buffer all these packets before passing to the user,
> resulting in a DOS attack).
>
> Could u be more specific as how this would be a DOS attack?
>
> ->My question is whether linux tcp implementation deal with such
> situations by lowering the window sizes outgoing packets so that buffers
> will not get exhausted....
>
>
> When application requested too much of buffer space, during
> connection establishment time, may be set to some default max
> value by systems. Use getsockopt to find the value.
> Modiying the window size once the connection is established,
> doesn't change the buffer space allocated.
>
> i have seen tcp_adv_win_scale and tcp_app_win of proc by which one can
> control the window sizes.
> 1st signifies size of the window+application buffer to isolate
> network from application latencies and scheduling.
> 2nd signifies size of the application buffer.
>
> ->how can one use these options to mitigate the aforesaid problems?
> and does this problem is automatically taken care of by linux stack...
> I might be missing some thing, if u are more specific abt the
> DOS attack that u see, I will try to explain. Correct me
> if I am wrong in ne of the above.
> cheers
> Suresh
>
> thanks and regards
> Syed
>
>
>
> --
> ______________________________________________
> IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com
> Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes!
>
> Powered by Outblaze
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
