>On Sat, Mar 27, 2004 at 04:20:44AM -0000, James Craig Burley wrote: >> >No. That's one less port he can use to connect to you (on any given >> >destination port). He can still use the same source port to connect to >> >others. TCP connections are four-tuples. >> >> Should I not trust O'Reilly's "TCP/IP Network Administration", by >> Craig Hunt, Second Edition, page 46, where it says, among other things >> consistent with this, >> >> It is the pair of port numbers, source and destination, that >> uniquely identifies each network connection. >> >> or do you think it is just simplifying things for the benefit of its >> audience? > >Read that again. The pair of port numbers, source and destination >(at the TCP layer)... plus the pair of IP addresses (at the IP layer). > >> Further, my Fedora Core 1 system does not appear to reuse dynamic port >> numbers when I open telnet sessions to distinct hosts. >> >> But I could be wrong. > >Many systems will use originating port numbers in sequence; more recently, >for security reasons, they may use them in random order. However the >fact remains that TCP/IP connections are uniquely identified by the >four-tuple [source IP, source port, dest IP, dest port]. The limitation >on the number of open connections is therefore generally available RAM >for the networking structures in the OS kernel (or application, in the >case of an application crafting its own packets.)
Yes, yes, as I said, that's *possible*. Simple question, I'm asking for a simple answer from a *knowledgeable* person on the list, not a theoretical one: Does "vanilla port management" on any deployed OS include multiplexing a dynamic port number for use as a source port for *multiple* outgoing connections? If it doesn't, then unless the spamware in question performs such multiplexing, my original point stands: tarpitting sucks up a spammer's dynamic port numbers at a rate potentially sufficient to be damaging, since they are in short supply compared to the number of outgoing connections needed to support a spam run. If it does, then please identify such TCP/IP stack implementations. Again, if the stack's API does not require an application to provide the destination host IP with the *request* for a dynamic port, then that dynamic port cannot be multiplexed. (Otherwise, how will the stack respond when the application uses that port to connect to a host to which that same port is already being used as a connector?) -- James Craig Burley Software Craftsperson <http://www.jcb-sc.com>
