On Sun, Sep 8, 2013 at 5:25 PM, Aaron Campbell <aa...@arbor.net> wrote:
> On 2013-09-06, at 3:44 PM, Haya Shulman <haya.shul...@gmail.com> wrote: > > > We studied the IPID randomisation on the name servers (not the > resolvers). Only the name server side IPID randomisation is relevant to the > attack, since it is the response from the name server that the attacker > attempts to alter (by crafting a spoofed second fragment). IPID > randomisation on the server, along with a smaller defragmentation buffer on > the resolver, should suffice to make the attack impractical. The random > suffix further raises the bar for the attacker. > > This is a good recommendation, but In practical terms, the trouble with > randomizing the IPID is that this would require kernel-level patches (as > opposed to just DNS server software upgrade), I believe. This makes it > somewhat harder to deploy. > Can you please extend? In particular, why is it more difficult (and how much more difficult is it) to deploy by distributing a kernel patch? Thanks. > > Unmentioned variation: random-length suffix? Instead of just > randomizing the fictitious IP address, tack a random string on the front of > the fictitious domain name. The advantage is that, in addition to the > checksum, you add IP and UDP length to the entropy (although these adjust > in tandem, unfortunately). > > > > Do you mean to add a random `name` and not only `value` in the > fictitious resource record? I think that this seems like a good idea. > Thanks! > > Yes. > > > I would like to know if there is any merit to my earlier suggestion to > Florian, namely, ignore glue records in large DNS responses, and have the > recursors resolve dangling authority referrals using a separate (shorter) > query. The second request is a simple A or AAAA query for the first[*] > nameserver listed in the original response. The reply should contain the > same authority and glue from the original response, but the data is more > credible since the parameters of this query were not chosen by an untrusted > stub. The assumption is that this second response would not also be > fragmented, although I suppose the recursor could drop the EDNS0 option to > force TC=1 just in case (even though that would result in a 3rd > transaction, ugh). > > > > Fragmentation can also occur in the `authority` section, e.g., similarly > to our attack exploiting referral response from a parent domain. So, I am > not sure how this can work, I think that this requires evaluation to > confirm. > > It has since been mentioned on the thread that the countermeasure I > described above is essentially what the "harden-referral-path" option > implements in Unbound. It would be interesting to re-test your attacks > against Unbound with this option. > Ok, I have not tested this. > > -Aaron > > -- 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
