Bug 787 - IPv6 query source address preference and randomisation
IPv6 query source address preference and randomisation
Product: unbound
Classification: Unclassified
Component: server
x86_64 Linux
: P5 enhancement
Assigned To: unbound team
Depends on:
  Show dependency treegraph
Reported: 2016-07-04 02:51 CEST by Robert Edmonds
Modified: 2016-07-04 17:02 CEST (History)
2 users (show)

See Also:

prefer-ip6: yesno option to prefer IPv6 queries to nameservers (5.18 KB, patch)
2016-07-04 02:52 CEST, Robert Edmonds
Details | Diff
IPv6 query source address randomisation (7.42 KB, patch)
2016-07-04 02:53 CEST, Robert Edmonds
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Edmonds 2016-07-04 02:51:39 CEST

I've written two patches for Unbound (attached). The first one adds a "prefer-ip6: <yes/no>" config option that causes IPv6 transport to be preferred for sending queries, if IPv6 nameserver targets are available.

The second patch extends the "outgoing-interface:" config option to allow specifying an IPv6 network prefix. Unbound will then attempt to perform IPv6 UDP queries using a randomised source address taken from the given netblock. This requires that the prefix be routed to the host running Unbound, and it requires OS support for unprivileged non-local binds. TTBOMK, this is currently just Linux with its IP_FREEBIND socket option. (Other OSes have similar socket options but they appear to require privileges to set.)

In order for the response traffic to be correctly received on a Linux system in this scenario, the destination addresses in the netblock have to be assigned to the host in the host's routing table. E.g., if the network has statically routed the prefix 2001:db8:deb:ac1e::/64 to the host running Unbound, the following commands need to be run on the host in order to receive traffic for the prefix:

  # ip -6 addr add 2001:db8:deb:ac1e::/64 dev lo
  # ip -6 route add local 2001:db8:deb:ac1e::/64 dev lo

If an IPv6 /64 prefix is available to perform source address randomisation from, this allows adding an extra 64 bits of entropy to queries that are performed using IPv6. When added to the ~31 bits available from DNS ID and query source port randomisation, this results in ~95 bits of entropy, which is impractical for an off-path attacker to break.

While this could also be implemented for IPv4 prefixes, I have not done so because IPv4 address space is much more scarce and only modest amounts of entropy could be extracted from wasteful amounts of IPv4 address space (e.g., an IPv4 /24 would only add 8 bits of entropy). So preferring the use of IPv6 transport if IPv6 nameservers are available seems to be the better approach.

I am not sure if the prefer-ip6 patch is complete. I still sometimes see queries being made over IPv4 even when (in theory) IPv6 nameservers should be available. But perhaps the infra cache has not been warmed up with the needed IPv6 addresses yet. The effect seems more pronounced when query minimisation is enabled, unfortunately.

It appears that IPv6 transport is being fielded much more aggressively than DNSSEC in the DNS, especially at leaf nodes (e.g., the unsigned names twitter.com and www.facebook.com can be resolved solely with access to IPv6 nameservers). So perhaps IPv6 source address randomisation is a useful mitigation to have.

These patches were developed against svn revision 3801 and do not include the generated output from re-running flex/bison.
Comment 1 Robert Edmonds 2016-07-04 02:52:24 CEST
Created attachment 334 [details]
prefer-ip6: yesno option to prefer IPv6 queries to nameservers
Comment 2 Robert Edmonds 2016-07-04 02:53:09 CEST
Created attachment 335 [details]
IPv6 query source address randomisation
Comment 3 Wouter Wijngaards 2016-07-04 17:02:59 CEST
Hi Robert,

Thank you very much for this patch!

Integrated.  Moved a variable for no declarations-before-code, and added more documentation (including the ip -6 commands needed).

I agree that an IPv4 version would be wasteful.  Also, sending to IPv6 in preference is actually RFC, eg. preferring IPv6 transport, the entropy gain gets along nicely with that.

Best regards, Wouter