svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf

[Gleb Smirnoff]

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.