On Thu, 13 May 2004, Iljitsch van Beijnum wrote: : Guess what, they call them drafts because they're not finished yet. So : why don't you say something to the author? I did exactly this earlier today. I don't necessarily expect action on it, considering that the vendor in question does not currently implement randomness in all appropriate places. But I retain hope. 8-) : I don't think you can fully randomize the source port as it might clash : with well-known ports. Which is why I say "14 bits": you can get away with at least a quarter of the 65536-port range. Most systems can get about 15.5 bits' worth of entropy with reasonable randomness diversity, without trampling well known service ports. : Also, it may be somewhat expensive to make ports truly random. arc4random() is cheap even on m68k's (read: "really old Cisco 25xx's"), only needed when initiating TCP sessions, and it's even more secure if it's fed just a teensy bit of real-world entropy now and then to stir its pot. These days it's a security risk /not/ to make use of randomness if you otherwise could -- and not just for the attack vector presented in this I-D. : But why are you assuming the window size is 64k? The draft's assumption is such, and it's in the bit-vicinity of common TCP stack defaults. With smaller window sizes, you of course get even better connection security -- something that might be worth mentioning on its own, elsewhere in the document. : > How many zombies would it take to search the port number space : > exhaustively? : : How many route processors does it take to look at the packets from all : those zombies? This very quickly becomes a DoS against the route : processor rather than a TCP exploit. Exactly; once the attack requires more packets (due to more guessed bits) than the CPU can handle, the "TCP attack" part becomes pretty much moot. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>