In message
<CAMm+Lwj+KjTVka1M7O+tsp76C_OCGR0bWKH_k5UrZXSYZrF+GA(_at_)mail(_dot_)gmail(_dot_)com>
, Phillip Hallam-Baker writes:
Following up on the DNS64 discussion. There is an important action item
that IETF can take right now that has a lot of leverage for IPv6
deployment.
* DPRIV be required to provide a mechanism for mutual authentication as
well as confidentiality.
This is not a major increase in scope. Authentication is essential for
confidentiality. But it is a big improvement in leverage.
The idea of DPRIV is that instead of sending requests to a random DNS
resolver in plaintext, we instead send them encrypted. And by implication
we also direct them to a resolver that can be trusted not to disclose the
traffic to an attacker.
So in the DPRIV model, the resolver is trusted. I suggest that there are in
fact quantized levels of trust.
0) Service: To provide responses to requests
1) Confidentiality: To not disclose traffic to third parties
2) Routing Integrity: To provide A and AAAA record responses that connect
traffic to the correct end point
3) Security Integrity: To provide keys for the end points.
Now depending on how much processing you are prepared to put in the client
you can reduce the level of trust. But you do need more code (or human
intervention).
So it is in theory possible to use DNSSEC to avoid the need to rely on the
resolver to return responses but I have never seen that done in a
completely robust fashion because it would require a lot of code and a lot
of corner cases.
The point of DNS64 is to provide a mechanism that makes it easy to turn on
IPv6 today. All the client needs is a connection to a DNS router that
supports DNS64.
Because of network circumstances a client using DNS64 is almost certainly
going to need to use DPRIV for access simply because port 53 has been
sabotaged so thoroughly. So we are going to have to trust the DPRIV
resolver to level 1 at minimum
The fact that we are considering DNS64 at all implies that we are willing
to trust the resolver to level 2. But to do that we have to have
authentication of the resolver at minimum and I would argue that mutual is
also necessary for enterprise deployment.
As soon as we have DPRIV with authentication it becomes possible to ship
IPv6 only products today. The only facility those products require to
connect to the IPv4 Internet is a DPRIV connection to a DNS resolver that
offers DNS64.
Note however, that trust to level 2 does not entail trust to level 3. An IP
address and a Key or Key fingerprint are two very different things. A Key
or Key fingerprint is an authenticator. An IP address is not an
authenticator, or at least it is a very weak one whose interpretation
requires us to trust a great deal more than our resolver.
Phillip,
I don't trust my or any ISP to not alter DNS responses.
Too many ISP have done that in the past and continue to do so. For
that among other reasons I run my own validating resolver.
If my ISP decides to run NAT64 + DNS64 then I need to be able to
get the DNS64 parameters securely for which there is no solution
today. Additionally there is no easy mechanism which doesn't require
me to funnel all my DNS queries through the ISP's nameservers despite
me not wanting to send any queries to them at all. I am not alone
with this desire. Millions of people already don't use their ISP's
nameservers but instead use a third party or run their own.
DNS64 was driven, in part, from the desire to do something that
didn't require changes in the node. It failed to achieve that
and as far as I can tell there is no solution that could achieve
that.
DNS64 is not the only solution for a ISP to go IPv6 only. DS-Lite
allows that. It also doesn't force you to use the ISP's nameservers
and it doesn't break DNSSEC.
Can we just give up on DNS64 as a general solution to going IPv6
only. It has its niche place in the cell phone world.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org