Date: Sat, 3 Sep 2011 00:07:28 +1000 From: "Jarrod Lee Petz" <jlpetz@internode.on.net> To: <freebsd-hackers@freebsd.org> Subject: TIME_WAIT Assassination in FreeBSD??? Message-ID: <007301cc6979$a690f9a0$f3b2ece0$@internode.on.net>
next in thread | raw e-mail | index | archive | help
Hi All, This is a repost (to mailing list) of my forum post here. http://forums.freebsd.org/showthread.php?t=26075 All links to RFCs can be found in that forum post. Please excuse my lack of mailing list decorum or ASCII formatting (I am new here). In my day to day work I have just run into a particular issue. Given it is at the foundations of the TCP stack I am obviously out of my depth here. I would like to know if anyone can tell me. 1. The best or most correct solution to my problem (this is not a FreeBSD related question)? Do I need TIME_WAIT assassination? Or a better port randomisation algorithm? Is it a problem with the Windows OS? 2. Is this even a problem in the FTP stack? Is it just bad design in active mode FTP? Will other protocols be impacted (a big concern of mine)? 3. Does FreeBSD handle this situation? How? I can't seem to find much info on TIME_WAIT assassination in FreeBSD is mentioned in RFC 6056 MY PROBLEM -------------------------------------------------------------------------- We have an AIX system which performs a number of FTP (active mode) mget & mdelete operations against a Windows 2003 R2 SP2 x64 FTP server(IIS). This all worked fine until we upgraded the AIX system from 5.3 TL8 to 6.1 TL6. When we did this, FTP would now hang forever for no apparent reason. However we found that two things had happened which had caused this. The first item revealed the second (bug). 1. As of AIX 6.1 TL6 & AIX 7.1. Ephemeral port allocation by the TCP/IP stack is now random instead of linear (for security). See ---> "IBM IZ73313:TCP/IP VULNERABILITY PROTECTION PHASE 1" 2. AIX FTP implementation was busted. Fixes provided by IBM to retry operation for default 90 seconds on receipt of FTP response 425 & then continue on if it still gets no incoming connection on PORT provided to server. So now that we have the FTP fixes for item 2.(above). Everything works you ask? Well kind of. FTP no longer hangs which is good. But we still see problems when AIX decides to use the same Ephemeral in close succession. For example. Step 1. AIX client sends FTP server request for data connection on port 38672. Step 2. Windows FTP server opens data link to 38672, Does its business & closes the connections. This leaves the socket/port on AIX in the CLOSED state. However the windows server the port is held in TIME_WAIT state for 2MSL(default 120 minimum configurable 30). Step 3. AIX client sends FTP server another request for data connection on port 38672 (reusable as it was CLOSED). Windows server responds with 425 because the port cannot be used. It is still in TIME_WAIT and is likely going to stay in that state longer then 90 seconds (default period FTP is retying for). The only thing I can find that would seem to address this circumstance is "RFC1122 TCP TIME_WAIT Assassination" But it seems to have reported issues "RFC1337 TIME-WAIT Assassination Hazards in TCP" and here "IETF Internet Draft - Problems with TCP Connections Terminated by RSTs or Timer draft-heavens-problems-rsts-00.txt - Ian Heavens - July 1995" I'm not sure how keen IBM is to change their TCP stack for a small fry like me. They seem to be wanting me to just reduce the 2MSL on the windows side. But I don't like this because 1. I will still have a delay sometimes, from 0-30 seconds (minimum 2MSL for Windows OS). 2. I don't know if other protocols will be or are being impacted. This looks interesting too. "RFC 6056 - Recommendations for Transport-Protocol Port Randomization" I was initially thinking along the same lines, why go to the trouble of assassination if you can just avoid it. Perhaps the randomisation algorithm IBM are using could be better. I have no idea what they do though. I do know though that our server is not busy(heaps of free ports) and the ports seem to get re-used quickly!! Regards Jarrod
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007301cc6979$a690f9a0$f3b2ece0$>