You are right, proper randomisation is one property, and secure application thereof to real world systems is another. 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. 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]).
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. 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. 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. GRC DNS checker, provided by Steve Gibson, exhibited high sensitivity to all attacks against which we tested it, and I highly recommend it. [Notice, that we have not tested sensitivity of DNS checkers to all attacks, but only against selected known attacks]. (For details and a complete list of DNS checkers we tested see paper). 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). So, we recommend using a PRP both for port allocation and IPID assignment, and will be happy to collaborate and discuss implementation challenges. On Mon, Sep 9, 2013 at 10:12 AM, Stephane Bortzmeyer <bortzme...@nic.fr>wrote: > On Fri, Sep 06, 2013 at 09:44:34PM +0300, > Haya Shulman <haya.shul...@gmail.com> wrote > a message of 232 lines which said: > > > We studied the IPID randomisation on the name servers (not the > resolvers). > > Just a warning: it's IPID _unpredictability_ (for a blind attacker) > which is important. Randomisation can be bad because it creates the > risk of IPID duplication (see RFC 6274 but RFC 6056, while talking > about a different field, may be interesting too). > -- Best Regards, S.H.
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
