Re: [v6ops] NAT64/DNS64 and DNSSEC

On Tuesday, July 28, 2015, Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
wrote:

> 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.
>
>
+1

This is just another way that ipv4 is too broken to use and will not be
fixed.

BCP = use native ipv6

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/v6ops
>