<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif">You are right, proper randomisation is one property, and secure application thereof to real world systems is another. </div><div class="gmail_default" style="font-family:garamond,serif">
So, as you said, there are a number of requirements, which should be addressed, to ensure correct functionality and security, including having a sufficiently large range which the attacker cannot traverse efficiently, and no collisions/duplications.</div>
<div class="gmail_default" style="font-family:garamond,serif">Using a pseudorandom permutation should satisfy both these requirements. (Although generally, 2^16 does not constitute a sufficiently large range, but, taking into account the (much smaller) defragmentation buffer at the recepient, the result is an `artificially inflated` range of values). I have not written a kernel based implemention of this design, so I am not sure what impact such an implementation has on the efficiency and what its overhead is on systems. But, it seems (again, requires testing) that it should be affordable (and would prevent attacks against [RFC6056]).</div>
<div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">Regarding [RFC6056]: we showed (in papers that will soon appear at ESORICS'13 and ACSAC'13) that the algorithms recommended in [RFC6056] are vulnerable to prediction attacks by off-path attackers. We also showed that some of the online DNS checkers (to best of my recollection we tested 5-6, see details in papers), that were set up to enable clients to test unpredictability of the port allocation that their systems support, report the clients as secure to port prediction, while they are not. </div>
<div class="gmail_default" style="font-family:garamond,serif"><div class="gmail_default">Since DNS checkers may often be the only way for administrators to evaluate security of their systems against off-path attackers, DNS checkers constitute an important tool, and should report susceptibility to vulnerabilities. </div>
<div class="gmail_default"><br></div></div><div class="gmail_default" style="font-family:garamond,serif">For instance, DNS-OARC does not detect port prediction attacks, and reports clients as secure, while they are vulnerable to attacks. I contacted the maintainers of DNS-OARC and notified them of this vulnerability last year, and proposed a simple fix to the problem... but the system was not updated and still reports vulnerable systems as secure, so relying on its feedback may be risky.</div>
<div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">GRC DNS checker, provided by Steve Gibson, exhibited high sensitivity to all attacks against which we tested it, and I highly recommend it.<br>
</div>
<div class="gmail_default" style="font-family:garamond,serif">[Notice, that we have not tested sensitivity of DNS checkers to all attacks, but only against selected known attacks].</div><div class="gmail_default" style="font-family:garamond,serif">
(For details and a complete list of DNS checkers we tested see paper).</div><div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">To conclude, indeed, many systems (based on our inspection of CAIDA captures and tests of the selected systems), deploy algorithms recommended in [RFC6056]. We found a number of different techniques (e.g., exploiting fragmentation, or interrupt driven scheduling) to derandomise ports on clients' systems, which use algorithms from [RFC6056], and so it may be best to patch since these works will be published in the upcoming months. Today at ESORICS I will present fragmentation-based techniques for port derandomisation against resolver-behind-upstream, which support algorithms from [RFC6056] (even if the upstream supports truly random and secure port allocation method). </div>
<div class="gmail_default" style="font-family:garamond,serif">So, we recommend using a PRP both for port allocation and IPID assignment, and will be happy to collaborate and discuss implementation challenges.</div><div class="gmail_default" style="font-family:garamond,serif">
<br></div><div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 9, <a href="tel:2013" value="+9722013" target="_blank">2013</a> at 10:12 AM, Stephane Bortzmeyer <span dir="ltr"><<a href="mailto:bortzmeyer@nic.fr" target="_blank">bortzmeyer@nic.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 06, <a href="tel:2013" value="+9722013" target="_blank">2013</a> at 09:44:34PM +0300,<br>
Haya Shulman <<a href="mailto:haya.shulman@gmail.com" target="_blank">haya.shulman@gmail.com</a>> wrote<br>
<div> a message of 232 lines which said:<br>
<br>
> We studied the IPID randomisation on the name servers (not the resolvers).<br>
<br>
</div>Just a warning: it's IPID _unpredictability_ (for a blind attacker)<br>
which is important. Randomisation can be bad because it creates the<br>
risk of IPID duplication (see RFC <a href="tel:6274" value="+9726274" target="_blank">6274</a> but RFC <a href="tel:6056" value="+9726056" target="_blank">6056</a>, while talking<br>
about a different field, may be interesting too).<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Best Regards,<br></div>S.H.<br></div>
</div></div>