Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

[<mohamed.boucadair at orange-ftgroup.com>]

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : behave-bounces at ietf.org [mailto:behave-bounces at ietf.org] De la part de Andrew Sullivan
Envoyé : lundi 9 novembre 2009 16:19
À : behave at ietf.org
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

On Mon, Nov 09, 2009 at 02:52:15PM +0100, mohamed.boucadair at orange-ftgroup.com wrote: 

> authoritative servers. In the draft an authoritative server will 
> generate A64 records for IPv4-embedded IPv6 addresses but will not 
> generate AAAA records for these addresses. So a host or a resolver 
> needs to ask first for AAAA records. If an AAAA record is received 
> there is no need to ask for A64 records. Moreover, with A64 records, 
> IPv6-only hosts will generate exactly the same load on DNS server as 
> dual-stack hosts. Dual-stack hosts ask first for an AAAA record. If 
> they failed they ask for an A record. With A64 records, IPv6-only 
> hosts ask first for an AAAA record. If they failed they ask for an
> A64 record.

Then your other criterion fails: in order for this to work, all the resolvers in the entire world need to be updated.  Otherwise, how does a host that needs v6-only access to a v4-only host reach that host?

If your answer is that you put an A64-enabled recursor in front of the authority server, this is no help: as far as anyone else in the world can tell, you're just server DNS64-generated AAAAs.  In such a case,
A64 is a wheel that does no work.

Med: The draft describes a scheme in which it is not required to update all resolvers, see http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-01#section-3.2. Is there any harm with what is described there? BTW, a solution based on http://potaroo.net/ietf/idref/draft-bellis-dns-recursive-discovery/ (i.e., "DNS64.LOCAL.ARPA") can be used to retrieve the server that can answer to the A64/DNS64 queries.


> Med/Eric: but draft-behave-dns64 describes in appendix B cases where 
> both IPv4-mapped IPv6 address and native IPv6 can be returned in AAAA 
> records. Then you need a "hint" for the selection of the appropriate 
> record otherwise you will overload the translators even if native 
> communications can be supported.

The draft also says, "Don't do that."  I don't think people should do it.  And indeed, part of the reason not to do it is because you might cause people to use NAT64 when they shouldn't.  But note that the alternatives I suggest would work just as well in this case.

Med: I read that. The pb I see is that IPv4-embedded IPv6 addresses will be used to populate DNS servers, even independently on the DNS64 proposal. The type of these addresses should be signaled somehow to avoid overload translators and also avoid failure (when no ALG are deployed in the core network), etc. 

> -       In a second step: A64 records will be introduced in
> -       Authoritative DNS server and they can be used by DNS64
> -       resolvers from step 1. The main benefit of this second step
> -       is that theses IPv4-embedded IPv6 addresses (i.e., A64) have
> -       a global scope and may be exchanged in referral (i.e., by
> -       applications).

To give you some understanding of the requirement you're imposing here, there's currently a dispute going on over in DNSOP about whether it is safe to introduce DNAMEs at the root.  One of the arguments against them is that they're too new.  The DNAME specification, RFC2672, dates from 1999, and DNAME has a backward compatibility mode where CNAMEs are synthesized in order to deal with clients that don't know about DNAME.  A64 doesn't offer such a compatibility mode, so it will simply break for such users.

Med: I'm aware of some limitations of A64 proposal, but the proposal still work with legacy servers and the DNS behaviour is the same for legacy nodes.  

The basic problem you have here is that you want to solve a backward compatibility problem (make v6-only hosts talk to v4-only hosts) by introducing a new feature.  But the very fact that you want backward compatibility means in itself that you can't just upgrade all the hosts.  That means a new RRTYPE will not solve your problem, because the only people who can use it are the ones who can upgrade.  

If they can upgrade, why not just move them to v6?

Med: But the hosts which will use A64 are IPv6-enabled! If you are talking about the remote hosts, other issues such us ensuring service continuity and to not disturb engineered/offered services (not to mention IS problems) may induce complications to move to v6 quickly.

> 
> Med/Eric: I'm afraid to not agree with this conclusion. Please see below an excerpt form the draft:

I _know_ that's what your draft says.  I claim you're wrong.  There's no way to make the scheme actually work with the deployed software and still achieve the goal of not having to upgrade everyone on the Internet unless you sometimes hand a synthetic AAAA to someone who asked for a AAAA.  You suggest that you'll reply with an A64 record to a AAAA query; but that's no good, of course, because the client asked for a AAAA and if it gets something else in the answer it's as likely as not to throw it away as malformed.  So, you admit that you're going to convert that A64 to a AAAA in the answer.  From the point of view of a querying agent, there is actually no difference here between the synthetic AAAA that comes from a DNS64 synthesizing from an A recor, and the A64-munger that synthesizes the AAAA from the A64.  It's still a AAAA record.

> Med/Eric: This is the aim of section 4.7. We think that a new query 
> type would be useful to avoid this issue. This new query would be used 
> to retrieve both A64 and AAAA records. A more generic proposal as 
> currently discussed in dnsext mailing list would be solve this issue.

This is again the "upgrade everyone" answer in disguise.  Changing all the DNS software on the Internet so that it can query for more than one RR at the same time using an as-yet-unspecified mechanism is not the way to quick deployment of cheap solutions intended to paper over the fact that IPv6 deployment has not happened in time for v4 exhaustion.  The point of the work we're doing is supposed to be fast and fairly easy deployment with few barriers.  Deploying a new query type that likely requires server-side processing (and to work out the not insignificant problem of what the caches do when they have a partial answer) does not meet that requirement.

Med: fair enough.

> Med/Eric: Why? for A64-compliant recursors, the behaviour is as follows: a
>    DNS64 recursor may return an A64 record as a response to AAAA query
>    if no AAAA record is available for the specified resource (A64
>    records are converted to AAAA records in the answer).

All you're doing here is moving around who has to make the A64-in-case-AAAA query decision.  The DNS64 recursor needs to instead.  _Someone_ has to.

>   If it has only A64 records, then it either has to do special processing when it receives a AAAA query, and convert the AAAA into an A64 query; or it has to return NOERROR with an empty answer for the AAAA query, and simply not get the communication benefit of NAT64 that was the whole purpose of the exercise in the first place.
> 
> 
> Med/Eric: The draft says that at a first stage, an A64 can be returned when a AAAA query is received (only when no AAAA is stored).

Yes.  So "special processing".  The first state will, I predict, never end.

Med: What do you mean by "state"? If your are referring to "first stage" of my previous answer, i recall you that we adopt the same behaviour as draft-behave-dns64.

> I haven't really thought through the security implications of any of 
> this, but at first blush it seems to me that the A64 record is going 
> to offer another opportunity to inject DNS poison, since an attacker 
> is going to know something about the capabilities of a querying host 
> and will also automatically know what query is coming next.
> 
> 
> Med/Eric: This is valid for all query types, right?

How?

Med: I meant that if the attacker can get the request sent by the host, it can deduce its capabilities (e.g., v4, v6, dual stack). Are you talking about this kind of capabilities? If not, I admit that I missed your initial point.

> Med/Eric: We have two parts here: the problems to be solved and the 
> solution space. The current draft describes both the problem and a 
> solution candidate. Should we separate both parts and lets agree first 
> on the issues, then analyse the solutions candidates?

I'm reasonably content with the problem you described: I get why it's a problem, and you're putting a finer point on my original impulse that whenever you have funky data in the DNS you want to be able to identify it in case it's relevant.  In this case, it turns out for some applications it _is_ relevant, so the only question is how one identifies the data, especially since part of the problem to be solved is that the whole thing works without anyone else doing any upgrades.

Med: but even for draft-ietf-behave-dns64 we need upgrade to work...I don't understand this constraint.

A new RRTYPE doesn't solve that latter problem, so I think it has to be discounted as a solution.

Med: I'm still not convinced about this even if I agree with some of your comments.
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************