Hi Hagen, > Anyway, I am little bit ambivalent regarding this ID. It may help in some > situations and reduce the attack vector. Any effort to improve the > security should be reviewed! I mean if there are no negative > impacts: why not? ;-)
I'm reluctant to conclude that there are no negative impacts. As an example, think of a lightweight http server running this on a server, an legimtate client (knowing the secret) running on a similar leightweight client without TSopt and only very few ephemeral ports. For each http session, the very same ISN will be re-used for every identical source port. In that enviornment the chances for a delayed packet to corrupt a TCP stream are non-negligible any more... ( the inverse of the number of ephemeral source ports available). Also, the client will have to do a fall-back SYN without TSopt, if an intermediate meddlebox modifies the TSopt in any way; and across normalizers (also not completely uncommon) the scheme breaks down. But then, those meddleboxes shouldn't really be messing around to begin with... :) I guess what I'm saying is that if some randomness (high order bits) could be maintained even when the 4-tuples are identical, that would at least address this concern (such sessions would still be detectable, by checking if the low order bits are identical; unless there is some clever way to randomly distribute the hash-bits and random bits, perhaps also based on a (different?) hash of the 4-tuple... Best regards, Richard Scheffenegger _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
