On Thu, Apr 02, 2015 at 07:53:07AM -0600, Ian Lepore wrote: I> Discussed, but not really resolved, or even reasonably addressed. I> I> But I guess if you think it's done, more words at this point aren't I> going to make you see the problems clearly enough to make the required I> changes.
I didn't see arguments that would prove the following assertions wrong. 1) There is legitimate case of IP ID reuse withing datagram lifetime, that happens due to overflow of uint16_t. Its probability is X. 2) There is a case of IP ID reuse due to migration between counter_u64_add() and memory fetch. Its probability is Y. 3) Y << X 4) Fixing X is impossible. 5) Fixing Y requires additional computing resources per packet. 6) Due to X being considerably high, the modern Internet has learnt to cope with the problem. >From this assertions I estimate that speaking of Y: (probability * risk cost) < countermeasures cost Please prove wrong my assertions, or the conclusion. P.S. Note that up to this week we had ip_id++ code, which was extremele prone to quick ID reuse. And no one (except Emeric of StormShield) was so worried about the case. But as soon as I made it per-CPU, together with disabling the code for 99% packets (thanks RFC6864), some people got extremely concerned by the possible reuse in the per-CPU case. -- Totus tuus, Glebius. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
