Date: Thu, 2 Apr 2015 17:20:17 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Ian Lepore <ian@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf Message-ID: <20150402142017.GH64665@FreeBSD.org> In-Reply-To: <1427982787.82583.111.camel@freebsd.org> References: <201504012226.t31MQedN044443@svn.freebsd.org> <1427929676.82583.103.camel@freebsd.org> <20150402123522.GC64665@FreeBSD.org> <1427982787.82583.111.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150402142017.GH64665>