Oskar Andreasson wrote:
My question hence is, how is the state of syn cookies today? How does it actually affect SACK, T/TCP, ECN, and other new extensions? That's what I want to find out before making a more final statement in the document. (erh, ok it sounds kind of final as it looks right now, but I want to check it up at least before doing any final statements).According to the netfilter documentation at <http://logi.cc/linux/netfilter-log-format.php3>, you should always have SYN cookies on with publically accessible TCP ports (log analysis page, fwiw).
Paper on advanced TCP algorithms:
http://www.google.ca/search?q=cache:vVQeUAOMmnoC:www.ce.chalmers.se/staff/otel/papers-mine/tcp-improvements/TCP-improvements.ps+linux+syn+cookies+ecn+sack&hl=en&ie=UTF-8
Advantages and flaws of T/TCP:
http://www.linuxgazette.com/issue47/stacey.html
"SYN cookies were implemented in the Linux kernel to combat this attack. It involves sending a cookie to the sender to verify the connection is valid. SYN cookies cause problems with T/TCP as no TCP options are sent in the cookie and any data arriving in the initial SYN can't be used immediately. The CC option in T/TCP does provide some protection on its own, but it is not secure enough."
Mailing list discussion on cookies and T/TCP from 1998:
http://www.uwsg.iu.edu/hypermail/linux/kernel/9804.1/0650.html
FWIW, could the kernel code that uses T/TCP automagically disable SYN cookies for those packets?
--
Michael T. Babcock
C.T.O., FibreSpeed Ltd.
http://www.fibrespeed.net/~mbabcock
_______________________________________________
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
