On 2013-09-06, at 3:44 PM, Haya Shulman <[email protected]> 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. > 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. -Aaron _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
