Randomize client address to improve security against cache poisoning
Description
Existing solutions to increase request entropy only provide a few extra bits. Port number randomization provide at most 16 bits of entropy and randomizing casing of the name will often provide less than that. Moreover for responses spanning multiple packets that extra entropy may only protect the first packet of the response.
Request
Take advantage of the larger address space provided by IPv6 to randomize both client IP address and port. Using a /72 prefix would leave 56 bits for randomization which is more than request ID, port number, and name randomization combined. The IP address is part of each packet and will thus protect all packets of the response. It does not require the other methods of adding entropy to be disabled, combined the entropy can be even higher.
Ideally the prefix length used will be configurable. Supporting only multiples of 8 will keep the implementation simpler. A /72 prefix length will be preferred in at least some deployments. It avoids randomizing the multicast and globally unique bits of the address. Additionally it's usable with providers who only route a /64 to customers. (Use cases exist for /48, /56, /64, /72, and /104 with /72 being the best compromise if only a single prefix length is supported.)
To use this feature the server administrator would need to:
- Ensure a prefix is routed to the host
- Choose a sub-prefix of that to use for source IP randomization (could be the entire range if the routed prefix is used for nothing else)
- Add a local route for the chosen sub-prefix (this functionality exists on Linux, I don't know which other OS supports this functionality.)
- Configure the chosen sub-prefix for address randomization in the BIND configuration.
The BIND recursion code will need to do the following:
- Before calling bind on a newly created socket set the IP_FREEBIND option.
- In the arguments for bind provide not just a port number but also a local IP address constructed by combining the configured prefix with a random bitstring to produce a total of 128 bits.
- Ensure that any replies not sent to the correct local IP address are ignored either by the kernel or by BIND itself.
When using TCP IP randomization should also be used, but it should not change how long the TCP connections are kept alive. So multiple queries could be sent over a TCP connection where IP randomization was applied only once.
Links / references
The security feature requested here already exists in Unbound and can be configured using outgoing-interface: https://nlnetlabs.nl/documentation/unbound/unbound.conf/