[dns-operations] DNS Attack over UDP fragmentation

[Aaron Campbell]

On 2013-09-06, at 3:44 PM, Haya Shulman <haya.shulman at 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.

> 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