Re: [v6ops] NAT64/DNS64 and DNSSEC

[Philip Homburg <[e-mail]>]

In your letter dated Tue, 28 Jul 2015 21:58:12 +0200 you wrote:
> but isn't there a gap that when performing the RFC7050 64pref
> detection by querying ipv6only.arpa, an attacker can spoof this
> answer (DNSSEC won't work here, for example, the attacker - when
> between the client and the DNS - can return for example
> 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the
> attacker)) and then attract all IPv4 traffic from the victim?
> 
> Nevertheless, an answer to the proliferation of DNSSEC and at the
> same time increasing usage of DNS64/NAT has to be found, not to
> stop the success of one or the other.

Yes, that seems to be a very tricky problem.

One option is perform local translation only for 64:ff9b::/96. This would
force operators to use the well known prefix, but it has to advantage that
the prefix can be filtered at the border of each network. And an attacker
will be quite visible trying to get this traffic by manipulating routing
protocols.

A second approach is for the network to signal that there is no IPv4 present.
For example, by not including a default route in DHCPv4 or otherwise signaling
in DHCPv4 that there is no IPv4.

In this case, if there is a valid IPv4 config, the library can refuse to
perform the synthesis. This would leave all dual stack networks unaffected.

Performing the AAAA lookup on ipv4only.arpa over tcp would require
the attacker to be on the path to the resolver.

An alternative to requiring 64:ff9b::/96, would be to insist that the
NAT64 gateway and the DNS64 are in the same /48. That would require an
attacker to spoof DNS resolvers in RAs or DHCPv6, in which case all bets
are off.

Ultimately, this only affects DNSSEC signed IPv4-only targets. The obvious
solution is that if those sites care about security, they should add a AAAA.