Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt

From: <[email-masked]>
Date: Wed, 25 Jan 2012 21:19:39 +0000

Hi all,

Please see a revisited version with changes mostly focusing on the connectivity check section and on the DNSSEC section (improved descriptions for both hosts and network - also an example configuration in the Appendix).

All comments are very welcome so that we could get into WGLC in near future.

Best regards,

        Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext [email-masked]
> Sent: 25. tammikuuta 2012 23:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-
> 05.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Behavior Engineering for Hindrance
> Avoidance Working Group of the IETF.
>
>       Title           : Discovery of a Network-Specific NAT64 Prefix using a
> Well-Known Name
>       Author(s)       : Teemu Savolainen
>                           Jouni Korhonen
>                           Dan Wing
>       Filename        : draft-ietf-behave-nat64-discovery-heuristic-05.txt
>       Pages           : 14
>       Date            : 2012-01-25
>
>    This document describes a method for detecting presence of DNS64 and
>    for learning IPv6 prefix used for protocol translation on an access
>    network without explicit support from the access network.  The method
>    depends on existence of a well-known IPv4-only domain name
>    "ipv4only.arpa".  The information learned enables applications and
>    hosts to perform local IPv6 address synthesis and on dual-stack
>    accesses avoid traversal through NAT64.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> heuristic-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-
> 05.txt
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 26 Jan 2012 20:56:04 -0800

Teemu and team,

Thanks again for working on this.  It is very useful work.

To that end, it is cited in our 464XLAT work
http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00 , and the
ideas have been included in 464XLAT Android code
http://code.google.com/p/android-clat/

I am glad the DNSsec work is evolving, it think this be a very
meaningful contribution.  My comments are as follows:

1.  "the information learned enables applications and
   hosts to perform local IPv6 address synthesis and on dual-stack
   accesses avoid traversal through NAT64."

Can we generalize this further?  You say applications and host, but i
am thinking home gateways as well. Perhaps say "enables software to
perform local IPv6 address synthesis..." ?  You also use the term
"node" in the draft, that may be a good fit.

2.  "Furthermore, the host SHOULD cache the replies it
   receives and honor TTLs."  Which TTL?  The TTL or ipv4only.arpa
that is used for discovery?  Are you saying the discover of the PREF64
is bounded by a TTL?

3.  The term NAT64 Prefix is used in this draft.  Would it be better
to use the term Pref64 that is used in RFC 6146 and 6147?  Is NAT64
FQDN in section 3.1.1 the same thing?

4.  Do you see any challenges for validating ULAs as the Pref64 with DNSsec?

5. "The host then does an
   A query of that hostname, which returns one or more A resource
   records, which are the IPv4-facing IP addresses of that NAT64."
What IPv4 address of the NAT64?  RFC 6146 refers to IPv4 transport
address, which i believe are commonly known as the "NAT pool"... do
you mean those addresses?  Since they are tied into the state table,
they are not going to respond to ICMP IPv4 packets.  Also, i dont
think any network operators wants you (or 30,000,000 cell phones)
pinging their NAT box.  There are much cheaper boxes to ping.  This
text needs to be pulled or completely reworked.  I suggest not
treating the topic of connectivity checks at all.

6.  3.1.1 #1 is not clear. Please elaborate on what that FQDN is supposed to be.

7.  Perhaps a state diagram for how DNSSEC validation works with
PREF64 would help.

CB

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 12:42:14 +0000

Cameron, 

Thanks again for reviewing the document:)

Replies inline:

> http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00 , and the ideas
> have been included in 464XLAT Android code

Very nice:-) 

> Can we generalize this further?  You say applications and host, but i am
> thinking home gateways as well. Perhaps say "enables software to perform
> local IPv6 address synthesis..." ?  You also use the term "node" in the draft,
> that may be a good fit.

We can, will think for better wording.
 
>    receives and honor TTLs."  Which TTL?  The TTL or ipv4only.arpa that is
> used for discovery?  Are you saying the discover of the PREF64 is bounded by
> a TTL?

Can be - the discovered Pref64::/n should remain valid at least for the duration of TTL that was used by network's DNS64 to synthetize the AAAA record. Hence node does not have to repeat discovery until the expiration of timer.

This can be clarified if you are ok with the idea.

(The TTL of ipv4only.arpa is probably longer than of Pref64::/n, and the TTL of Pref64::/n should not be longer than of ipv4only.arpa).

> 3.  The term NAT64 Prefix is used in this draft.  Would it be better to use the
> term Pref64 that is used in RFC 6146 and 6147?  Is NAT64 FQDN in section
> 3.1.1 the same thing?

Good point, the RFC6052 didn't use this (only NSP and WKP), but Pref64::/n is fine.

Similar term for the NAT64 FQDN term probably is not used in these other documents? I.e. other documents do not ask for naming the NAT64, while we do for DNSSEC reasons.

> 4.  Do you see any challenges for validating ULAs as the Pref64 with DNSsec?

Reverse lookup might be difficult, i.e. step 2 of 3.1.2, as there is no centrally managed ULA's yet... But I wonder if you could locally (in your DNS64) catch PTR queries for "ULA".ip6.arpa and return NAT64 FQDN as a response? If so, maybe it would work?

> What IPv4 address of the NAT64?  

External Internet facing IPv4 address of NAT64, any that is able to respond to ICMP Echo Req.

>RFC 6146 refers to IPv4 transport address,
> which i believe are commonly known as the "NAT pool"... do you mean those
>addresses?  

Well, not if NAT64 drops ICMP echo requests sent to those addresses or if it forwards them to other nodes...

I.e. preferably some other external IPv4 address NAT64 has. 

Please note that this address can be any IPv4 address, for example as of dedicated "ping server". But we thought it might be nice to keep the connectivity test "inside" NAT64 system.

> Also, i dont think any network operators
> wants you (or 30,000,000 cell phones) pinging their NAT box.  There are
> much cheaper boxes to ping.  This text needs to be pulled or completely
> reworked.  I suggest not treating the topic of connectivity checks at all.

After ping they all send data through the NAT box:) But individual devices should not send these ping tests too often - at most when learning Pref64::/n and not again until TTL timeout or reconnect.

But as written, connectivity test is not always required or useful: it may unnecessarily increase latency if done only at the time when user's transport sessions is already starting - in which case it might be wiser just to proceed with transport session and see if it makes through or not. 

Then again in some cases it might be useful, for example in the home gateway scenario you introduced: if the home gateway does not perform connectivity test, it would be synthesizing AAAA records for local hosts using discovered prefix without any knowledge if the prefix discovery was successful... If it was not, clients behind home gateway would be trying connections with broken IPv6 addresses..

So I'm not quite ready to remove the connectivity check, but we can try to fine tune it.

> 6.  3.1.1 #1 is not clear. Please elaborate on what that FQDN is supposed to

Any Fully Qualified Domain Name, the exact name should not matter much. E.g. "nat64.example.com". 

> 7.  Perhaps a state diagram for how DNSSEC validation works with

The numbered lists on 3.1.1 and 3.1.2 try to show it already.. and the DNSSEC procedures should be described in DNSSEC specifications. Hence I'm not sure I understand what diagram would you like to see?

Best regards,

	Teemu

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Fri, 27 Jan 2012 09:11:44 -0700

Hi Teemu,

I have some questions/comments on the draft:

------------
Introduction, third part:

   Additionally, DNS64 is not able to do IPv6 address synthesis for
   hosts running validating DNSSEC enabled resolvers, but instead the
   synthesis must be done by the hosts themselves.  

How is the service provider's DNS64 able to distinguish between hosts
running validating DNSSEC enabled resolvers and hosts that are not? Is
the idea to simply stop the synthesis whenever a host sends a query with
the DO bit set?

------------------------------
Host behavior, second part:
   When sending AAAA query for the well-known name a host MUST set
   "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not
   perform IPv6 address synthesis hence does not reveal the IPv6
   prefix(es) used for protocol translation.

Where is it defined that CD should force the DNS server to stop DNS64
synthesis? 

------------------------------
Requirements for the network, bullet 3:
Each NAT64 prefix MUST HAVE PTR record that points to
       corresponding NAT64 FQDN.

Can somebody give me an example on how this PTR record would look like?
How do you put PTR for a prefix? Is the idea to use the first address
(0.0.0.0.0.0.0.[PREF64].ip6.arpa.)?

------------------------
Requirements for the network, bullet 5:
   5.  Have access network's authoritative nameservers to respond to DNS
       queries for the NAT64 FQDNs only when the queries have been
       originated from the network domain the NAT64 is serving.  If the
       NAT64's AAAA records are made resolvable throughout the Internet,
       a possible misuse vector of the NAT64 prefixes and NAT64 FQDNs in
       other networks is enabled: an attacker in other access network
       may lure a host on that network to think it is configuring NAT64
       prefix in secure manner, while in reality it is not as the node
       would be configuring NAT64 prefix in a network where the NAT64
       prefix should not be used.

I don't like this requirement because it is forcing the DNS server to
support views. Additionally, you will have to update the authoritative
DNS every time you start provisioning your clients with new addresses
from new IPv6 networks.

-------------------
Exit strategy:

   A day will come when this tool is no longer needed.  At that point
   best suited techniques for implementing exit strategy will be
   documented.  In the global scope the exit strategy may include
   sending NXDOMAIN replies by the authoritative name server of the
   well-known name with a very long TTL.

The negative TTL is determined by the SOA record. If you are removing
the ipv4only.arpa then you will get whatever negative TTL .arpa. is
signaling today.  It might not be that easy to convince the .arpa
maintainers to increase the negative TTL. It would be better if
something like ipv4.only.arpa is used, then the negative TTL can be
changed independently.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 27 Jan 2012 08:24:52 -0800

Resending to the list -- in line

> (The TTL of ipv4only.arpa is probably longer than of Pref64::/n, and the TTL of Pref64::/n should not be longer than of ipv4only.arpa).

Well, in the draft, the only guidance for ipv4only.arpa ttl is that it
not exceed 1 year... which does not help in this situation.

The draft would benefit from explicitly stating discovered pref64 ttl
= pref64 fqdn ttl. That way the ttl is completely in control of the
network operator.

> Similar term for the NAT64 FQDN term probably is not used in these other documents? I.e. other documents do not ask for naming the NAT64, while we do for DNSSEC reasons.

How about nat64 node fqdn? that is descriptive and specific.  But
really, this concept is not acceptable as i will discuss below.

> Reverse lookup might be difficult, i.e. step 2 of 3.1.2, as there is no centrally managed ULA's yet... But I wonder if you could locally (in your DNS64) catch PTR queries for "ULA".ip6.arpa and ret…

I can likely make that work

> External Internet facing IPv4 address of NAT64, any that is able to respond to ICMP Echo Req.

It does not need to be this way, right? What you really want is a
pairing of dns records, right? If that is what is needed, then lets
say that. I would much rather pair the pref64 fqdn with a dummy fqdn
for this purpose.  It is not acceptable to network operators to have a
name for an interface we do not want traffic to be destine to.

> Please note that this address can be any IPv4 address, for example as of dedicated "ping server". But we thought it might be nice to keep the connectivity test "inside" NAT64 system.

Not nice. Cgn boxes are lots of asics / fpga / blah and relatively
weak control plane processors that explicitly rate limit icmp to avoid
control plane resource attacks. You cannot prescribe how this can be
treated, the existing text is not acceptable.  It may be acceptable if
you think NAT64 is a Linux box, but in may large deployments, it is a
very different case.

> After ping they all send data through the NAT box:) But individual devices should not send these ping tests too often - at most when learning Pref64::/n and not again until TTL timeout or reconnect.

Icmp to the cgn and icmp via the cgn/nat64 are treated very
differently. The same can be said for core ip routers....and some
vendors think cgn is a blade on a core router ... those core routers
definately rate limit ICMP destine to the router itself.  This cannot
be changed.

> But as written, connectivity test is not always required or useful: it may unnecessarily increase latency if done only at the time when user's transport sessions is already starting - in which case…

Yes.

> Then again in some cases it might be useful, for example in the home gateway scenario you introduced: if the home gateway does not perform connectivity test, it would be synthesizing AAAA records f…

Fine. But the method described is not acceptable.

> So I'm not quite ready to remove the connectivity check, but we can try to fine tune it.

Ack

> The numbered lists on 3.1.1 and 3.1.2 try to show it already.. and the DNSSEC procedures should be described in DNSSEC specifications. Hence I'm not sure I understand what diagram would you like to…

Since I was fuzzy on the taxonomy, the pieces were not fitting.

Net net, this draft, IMHO, needs to define a procedure based on fqdn
and optional connectivity checks.

And.

It is not acceptable to expect any interface on the nat64 node to have
an fqdn or to send icmp connectivity checks to the nat64 node.  The
pref64 may have an fqdn, that does make sense to me.

This draft would benefit from describing "what" needs to be done, not
"how" it will be done.

Cb

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jan 2012 09:19:37 -0800

> Behalf Of Stephan Lagerholm
> Sent: Friday, January 27, 2012 8:12 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-
> heuristic-05.txt
> 
> Hi Teemu,
> 
> the idea to simply stop the synthesis whenever a host sends a query
> with the DO bit set?

AAAA synthesis has to be skipped of CD is set,
http://tools.ietf.org/html/rfc6147#page-8, 

...
   If a query arrives at a vDNS64 device with the "Checking Disabled"
   (CD) bit set, it is an indication that the querying agent wants all
   the validation data so it can do checking itself.
...

RFC6147.  

The DNSSEC text is all mine, and I believe it's correct and aligned
with RFC6147.  If there is a mistake, we will get it fixed.

http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05#ap
pendix-A

If there is a better format for showing that example, let me know.  I just
used a BIND example configuration that I had laying around.

Fair point.  Teemu, Jouni, thoughts on this?

Myself, I don't think we could ever reach Internet-wide consensus
that NXDOMAIN should be returned; there is always legacy equipment
running somewhere.  Some folks still have active X.25 networks, for
example, and horses and carriages.  Within a network, I could see
someone (e.g., a mobile operator) deciding that their equipment
shouldn't use draft-ietf-behave-nat64-discovery-heuristic and they
might become authoritative for ipv4only.arpa (yes, I know that
is frowned upon by DNS purists.  But we all know it happens.  It
would work as long as ipv4-only.arpa 

But you bring up a tangential point, that "ipv4only.arpa" isn't the 
best choice of name -- we could benefit from a zone below the top-
level arpa domain so the SOA can be self-contained for just this
heuristic.

-d

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Fri, 27 Jan 2012 13:45:32 -0700

Hi Dan and thanks for the reply, See inline.

> Behalf Of Dan Wing
> Sent: Friday, January 27, 2012 11:20 AM
> To: Stephan Lagerholm; [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D
> Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt]
> 

Your assuming that a validating DNS server sets the CD bit on all
upstream queries. That might not be true, at least not until
draft-ietf-dnsext-dnssec-bis-updates section 5.9 is hammered out. People
are still arguing if always setting CD is the right behavior or not. 
(I guess that is more of a problem for RFC6147 than it is for this
draft)

> > (0.0.0.0.0.0.0.[PREF64].ip6.arpa.)?
http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-
> 05#ap

Thanks for pointing me to Appendix A. How will the current wording in
the draft harmonize with RFC6147 option 2 that says that the DNS64
server should respond to that query with:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. CNAME
0.0.0.0.in-addr.arpa.	

The query will in other words not reach the server authoritative for
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA
Or am I missing something?

Thanks /Stephan

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 27 Jan 2012 16:15:58 -0500

> (I guess that is more of a problem for RFC6147 than it is for this

That isn't the assumption there.

The assumption in there is that, if you want to do DNSSEC behind a
NAT64, then you have to do your own validation.  Moreover, if you want
to do your own validation, then you MUST set the CD bit, because
otherwise you will get an unvalidatable answer (from the DNS64).  This
does mean that, in the presence of a DNS64, you can never do
validation where you know you have only a partial TA list. 

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jan 2012 13:29:33 -0800

> From: Stephan Lagerholm [mailto:[email-masked]]
> Sent: Friday, January 27, 2012 12:46 PM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: RE: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D

RFC6147 probably tacitly expects the validating DNS server is also 
the DNS64 (that is, the same box).  If they are the same box I
believe there isn't a problem with CD being propagated. 

If they are separate DNS servers (i.e., the DNS64 forwards the
query to a DNSSEC-validating DNS server), then I agree RFC6147 creates 
a requirement that the DNS64 has to set CD if CD was set on the query
it received.  

Thanks for referencing draft-ietf-dnsext-dnssec-bis-updates; I had
not been tracking it.

> the draft harmonize with RFC6147 option 2

You're referring to Option 2 in Section 5.3.1 of RFC6147,
http://tools.ietf.org/html/rfc6147#section-5.3-1

> that says that the DNS64

If that network is using the IANA-assigned Well Known Prefix for its
NAT64, we are relying on Option 1 of Section 5.3.1 when it is responding
to queries for that network's NAT64 prefix.  So, if that network
is using the IPv6 example address as its NSP, then for that ip6.arpa,
it would need to use Option 1 -- and respond authoritatively for
that prefix.  Also, if trying to use Option 2, the ip6.arpa query 
won't have a valid IPv4 address so it can't query in-addr.arpa.

If, for other prefixes, the DNS64 wants to do Option 2, it can
do that (as allowed by the text in the paragraph immediately above
Option 1 and Option 2).

If that network is using its own prefix for its NAT64, I believe the
DNS64 also needs to do Option 1 for that prefix.  This is because 
Option 2 requires the ip6.arpa query has a an IPv4 address in the 
query (to query in-addr.arpa).

Assuming I got that right, and I hope I did, I'll make a note
to point this out in draft-ietf-behave-nat64-discovery-heuristic.

-d

---

From: Mark Andrews <[email-masked]>
Date: Sat, 28 Jan 2012 11:13:49 +1100

In message <[email-masked]>, "Ste
> I have some questions/comments on the draft:

As a DNS server vendor if DO=1 and the anwser is signed you do not
do synthesis as the client can detect it.  CD=1 is *not* a indication
that a client wants to validate.  RFC 6147 is just plain wrong with
this assertion.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 28 Jan 2012 11:57:14 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> otherwise you will get an unvalidatable answer (from the DNS64).

Which is not correct from a DNSSEC perspective.  The *only* requirement
to do your own validation is that DO=1.  If you want to disable
upstream validation you set CD=1.  These are two independent
operations.

I really do expect applications to do DO=1/CD=0 and if that returns
SERVFAIL to make a second DO=1/CD=1 query to remove upstream
validation failures from the equation.  The DO=1/CD=0 is needed so
that the retry algorithms in the recursive resolver kick in on stale
data from authoritative sources.  The DO=1/CD=0 is needed for the
case where the recusive server has a bad clock/stale trust anchors.

RFC 6147 is just plain *wrong* with respect to DNSSEC and its statement
that CD=1 indicates the client intends to validate.

If the answer to the AAAA query is signed and the client made a
DO=1 query you pass the answer back as is otherwise you can synthesis.
We apply this to all forms of synthesis we do in named.  NXDOMAIN
redirection / DNS64 / AAAA filtering / RPZ (there is a bug fix for
RPZ in the next maintenance release).

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 29 Jan 2012 11:45:54 -0500

> > NAT64, then you have to do your own validation.  Moreover, if you
> > want to do your own validation, then you MUST set the CD bit,
> > because otherwise you will get an unvalidatable answer (from the
> > DNS64).
> 

That is true from a DNSSEC perspective when you are using the real
DNS.  But DNS64 _isn't_ the real DNS.  It's a forked DNS tree: the
DNS64 function systematically lies about what the answers from the DNS
are.  The only way to cope with that and still validate is to do the
lying to yourself, and the only way to do the lying to yourself is to
set the CD bit.  Therefore,

> validation failures from the equation.

if you do this behind a DNS64, it's guaranteed to fail the first step
every time.  If you really expect applications to do that, what you're
committing to is double the queries for zero benefit any time a DNS64
is involved.

> that CD=1 indicates the client intends to validate.

I don't beleve RFC6147 makes that statement, but here are two pieces
that I think could be read as implying such a statement.  I agree that
they ought to be clarified in a future revision of DNS64.  I've given
them letters in order to talk abotut them below.

A

B
   3.  A security-aware and non-validating DNS64 receives a query with
       the DO bit set and the CD bit clear.  Such a resolver is not
       validating responses, likely due to local policy (see [RFC4035],
       Section 4.2).  For that reason, this case amounts to the same as
       the previous case, and no validation happens.

(A) doesn't say that CD=1 indicates that the client intends to
validate; it says that it means the querying agent wants the upstream
to pass everything along.  If you think that could be stated more
clearly (and on re-reading it, I think it could be), then perhaps you
can contribute such text for a future revision of DNS64.

(B) says that CD=0 is an indication that a resolver "is not"
validating; that is clearly an overstatement of the case, and should
have been written as "might not be" validating.  That said, note that
RFC 4035 section 4.9.2 says this:

   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy.
 
> RPZ in the next maintenance release).

The signed AAAA query from the global DNS is simply irrelevant here:
in DNS64 that's supposed to work as you do it.  The question is what
happens when you need to synthesize AAAA from the (signed) A record,
and in that case the _only_ reliable way to validate at the end point
in DNS64 is to use CD=1.  Anything else is automatically going to fail
validation.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Jan 2012 10:08:24 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> lying to yourself,

Good up to here

> and the only way to do the lying to yourself is to
> set the CD bit. 

Total rubbish.  It is pointless to lie to a DO=1/CD=0 query as the client
can detect the lie.

> Therefore,

> > I really do expect applications to do DO=1,CD=0 and if that returns
> > SERVFAIL to make a second DO=1,CD=1 query to remove upstream

A plain DNSSEC client is stuffed if DNS64 is applied to a response
from a signed zone regardless of the state of CD.  It is pointless
to apply DNS64 synthesis, with a DO=1 query, to a answer from a
signed zone regardless of what CD is set to even if you do understand
DNS64.

By *not* saying to disable DNS64 processing on DO=1, the working
has made trouble shooting/working with DNSSEC issues harder,  on
validation failure the DNS64+DNSSEC aware client has to then ask a
DO=1,CD=0 query, to cause the DNS64 recusive server to make upstream
queries to get a good answer can be cached (ttl=0 is a problem
here), which will just have to be discarded as it won't validate,
then it will need to re-make the DO=1,CD=1 query to get the answer
from the cache (assuming that it hasn't got flushed).

What this WG should do is to define a EDNS option so that DNS64+DNSSEC
aware clients can get the DNS64 prefix/suffix returned.  Here is
one that will work.

	DNS64 <length> [<prefixlen> <prefix> <suffix> ] ....

prefix + suffix is always 96 bits.  If DNS64 does not apply then a
empty set of prefixes is returned.  The set of prefixes returned
is specfic to this query.

Alternatively a DNS64 DHCPv6 option should be defined and the
DNS64+DNSSEC client can retrieve that.

> can contribute such text for a future revision of DNS64.

All CD=1 says to a validating resolver is to not validate any answers
to queries you make to answer this query, but instead pass them along
without validation.  It does NOT prevent the upstream returning answers
that have already been validated and cached.
 
> RFC 4035 section 4.9.2 says this:

DO=1 is "the client may be validating".  CD=0 say *nothing* about whether
the client is validating or not.
 
>    acceptable to the stub resolver's local policy.

And as has been pointed out on dnsext that is only half of the argument.
There is a equally good argument for setting CD=0 when talking upstream
to deal with a different lot of mismanagement.  It's a case of pick you
poison or try the other way on failure.
 
> in DNS64 is to use CD=1.  Anything else is automatically going to fail

If the A record is signed then the AAAA response is also signed so I fail
to see how it can be irrelevent.  The rest is simply not true.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 29 Jan 2012 19:39:44 -0500

> to see how it can be irrelevent.  The rest is simply not true.

The only case where DNS64 does anything is when there's no AAAA in the
first place.  If there were AAAA, we wouldn't need DNS64 at all.

I started to respond to the rest of your message, but the above
suggests a deep confusion in what we're talking about.  DNS64 only
does anything at all when you have a node that wants a AAAA, and a
some other node for which there is only an A record.  There can't
possibly be a signed AAAA for that, unless the AAAA is being generated
and signed on the fly in which case it is indistinguishable from
native v6.  This is why the funny handling of CD is appropriate in
DNS64 but not in DNS generally, and attempting to treat DNS64 as
though it's more or less the real DNS is a mistake.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Jan 2012 12:33:04 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> some other node for which there is only an A record.

"Signed AAAA response" != "Signed AAAA RRset".  Below is a "signed
AAAA response".  Note there are no AAAA records.  There are however
signed a signed A RRSet (also below).  Both answers are cryptographically
verifiable.  Neither answer required CD=1 to be set.  Appling DNS64
processing to the first query would be a waste of time as the client
can detect the DNS64 substitution.

; <<>> DiG 9.7.3-P3 <<>> aaaa calendar.isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 221
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;calendar.isc.org.		IN	AAAA

;; AUTHORITY SECTION:
isc.org.		3587	IN	SOA	ns-int.isc.org. hostmaster.isc.org. 2012012900 7200 3600 24796800 3600
isc.org.		3587	IN	RRSIG	SOA 5 2 7200 20120227233235 20120128233235 21693 isc.org. Rilw+0NYXFg94XVcSNHGEnqTVlDNIvis85+cAJrvW9NvZHOx6s/GyWZM ar5TeKXDc16np8YNd9zBe3H08vq4bpUrRsN8biwybDXd/gZ890wkgtMV nxJUopy1515CJv/4UDVUN4g+N+6g1bntdNoDiLCR8gaoTjrHBU5xsgG9 aBs=
calendar.isc.org.	3587	IN	RRSIG	NSEC 5 3 3600 20120227233235 20120128233235 21693 isc.org. BJBXu89OWOUfWmzTBI4iPELSCJrLz2zbwBBpcDTdeICwMaTkUoiPiLPt XBRandsR9UR5vKep1UayI8RVfmtcskm7e/aA5HNg999lrhIadf2s7qXO bfsP+yRBNSh9pC7CRFYC2nLKHifx9U/7f/q4BjPPFh8aVr5ZH74o/WrR FlU=
calendar.isc.org.	3587	IN	NSEC	calendar2.isc.org. A RRSIG NSEC

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 30 12:11:03 2012
;; MSG SIZE  rcvd: 472

; <<>> DiG 9.7.3-P3 <<>> calendar.isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59468
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 15

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;calendar.isc.org.		IN	A

;; ANSWER SECTION:
calendar.isc.org.	7200	IN	A	149.20.48.29
calendar.isc.org.	7200	IN	RRSIG	A 5 3 7200 20120227233235 20120128233235 21693 isc.org. mT1/Vb6Nczgcb1WnhHytO6HI3JnxrtN3O+KAmk0htCaVgShgPl/ff0eF TNpireRcO3zzlQl0MSFovc6GeeCr4JfBuKsRXiM1TPZlFyhD0QXH2vS6 MdwppXqh0eCUoXnVq44ihkaj19EvASsVN9JMT9292fFWQna5r+CJYg3W YDw=

;; AUTHORITY SECTION:
isc.org.		6213	IN	NS	ord.sns-pb.isc.org.
isc.org.		6213	IN	NS	sfba.sns-pb.isc.org.
isc.org.		6213	IN	NS	ams.sns-pb.isc.org.
isc.org.		6213	IN	NS	ns.isc.afilias-nst.info.
isc.org.		6213	IN	RRSIG	NS 5 2 7200 20120227233235 20120128233235 21693 isc.org. tmpOdZj5kL58KjLehl2hsmGKT+C9Pm62LNXdhmw6RD8fKhJIl82EV1s5 FbaCod70y1utteFnUIxooMamt8FB+h6wBmPk6oeamNIDUQPJG/++997w O7W3Q4wxNLXljNSx8IjeHLgUJP5Nu7iuMtQjGCaRUVb3MRUuJxD7o3gJ IQU=

;; ADDITIONAL SECTION:
ns.isc.afilias-nst.info. 45272	IN	A	199.254.63.254
ns.isc.afilias-nst.info. 3237	IN	AAAA	2001:500:2c::254
ams.sns-pb.isc.org.	85413	IN	A	199.6.1.30
ams.sns-pb.isc.org.	78202	IN	AAAA	2001:500:60::30
ord.sns-pb.isc.org.	85413	IN	A	199.6.0.30
ord.sns-pb.isc.org.	78202	IN	AAAA	2001:500:71::30
sfba.sns-pb.isc.org.	85413	IN	A	149.20.64.3
sfba.sns-pb.isc.org.	78202	IN	AAAA	2001:4f8:0:2::19
ams.sns-pb.isc.org.	7200	IN	RRSIG	A 5 4 7200 20120227233235 20120128233235 21693 isc.org. AgPtohr7vlYwYnGhPELyHya7ZEC7WaLnlOiQM4eMAwR2LJkqT9NY9Gg1 jUB6jdSSM8E+UKOdYxi6OWZyMfRdajsvvKBo3bpevz0xsgGoYc9v2bjR M6pEfE9c9WAYfJQ+bARF4cTtcVXzfP7TusdY8uqnav0Zah8Hf3PH9paA 5VI=
ams.sns-pb.isc.org.	7200	IN	RRSIG	AAAA 5 4 7200 20120227233235 20120128233235 21693 isc.org. Rj7/OOo4KxH0ofSpy3rDR/fN9mm9wM5Ez/DLGUf5LI2wc6J+cyRqdfYl LRE6NEa6H4PkXmAVL1/Iq78WdD02OqT0qugn/CV9nSwk0TqnuM0ORvXS N5MU/VKogMU9DMhqb1TLWJ1UMGlfQv3DdhaBtzCd0vJ7reKs+SahgPK6 YKw=
ord.sns-pb.isc.org.	7200	IN	RRSIG	A 5 4 7200 20120227233235 20120128233235 21693 isc.org. j5LUwsHOhMCR0KuToauX5QwMiFLZBU8CgbytTMpEFnNaSPPAXfdLO7m6 ZVSaMV6WQbefxPL+7LGnmJkU5zHL1VEtrrVaX27j1wyaXtQHeBnGKHnS u4C6ww9LfyhvKevpkpX6q1YJuHp7WJHKttthI0MdlSQWMnPNUDoLi6mR nBI=
ord.sns-pb.isc.org.	7200	IN	RRSIG	AAAA 5 4 7200 20120227233235 20120128233235 21693 isc.org. KmU6kBpGMTfjKpYWMtvPvyhGiSIYvKbNrXebYVk41lFGbZtrgzoNpYZR WQRXEthTxua1uH/UXQsTXfEN0/XBe+ZQYZRQNlwAO2meWT5+xUOYC5i8 QesHurfwJdX1nofJ/T/emXUwe9MTxcuCR7Vgj5py9ENgBd+PsxveZFpz PjA=
sfba.sns-pb.isc.org.	7200	IN	RRSIG	A 5 4 7200 20120227233235 20120128233235 21693 isc.org. AyWxyYKgBa5Z8G5/YnBeN/riKaJOfS6AT5RznWaLGxAx54OcM0ZD8ae6 ED+5x6SsnOmC5Dyc+KtxjH/Jqsyzy9EqQCSOkjExuJg/D8ujNON4+KeP lgpgsI0TU2evP1D9Lm+RUApRrQvXLex9BAsgfx7n66yliymHeacXk7vS Yag=
sfba.sns-pb.isc.org.	7200	IN	RRSIG	AAAA 5 4 7200 20120227233235 20120128233235 21693 isc.org. BDaejZw5Fve5+ZF8pik9oQcCyXmTtGpJR+EKaMYo9x/Dt9m5TQlFtluz zXYHsGRKIHuB7rjTk+Ajc6dO9MTjcAWlKE8zCg/+bsyL7vYNySEm19ki 78+pclgRB2bTQiBfIyyKB1/Jpj+D9r+5PEwwy+Jwls+W22G51MOnLDAG QEQ=

;; Query time: 252 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 30 12:11:29 2012
;; MSG SIZE  rcvd: 1672

> There can't

And if I add CD=1 to the query the only thing that changes, other than
the ttls, is "cd" added to the flags.

; <<>> DiG 9.7.3-P3 <<>> aaaa calendar.isc.org +dnssec +cd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43138
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;calendar.isc.org.		IN	AAAA

;; AUTHORITY SECTION:
isc.org.		3073	IN	SOA	ns-int.isc.org. hostmaster.isc.org. 2012012900 7200 3600 24796800 3600
isc.org.		3073	IN	RRSIG	SOA 5 2 7200 20120227233235 20120128233235 21693 isc.org. Rilw+0NYXFg94XVcSNHGEnqTVlDNIvis85+cAJrvW9NvZHOx6s/GyWZM ar5TeKXDc16np8YNd9zBe3H08vq4bpUrRsN8biwybDXd/gZ890wkgtMV nxJUopy1515CJv/4UDVUN4g+N+6g1bntdNoDiLCR8gaoTjrHBU5xsgG9 aBs=
calendar.isc.org.	3073	IN	RRSIG	NSEC 5 3 3600 20120227233235 20120128233235 21693 isc.org. BJBXu89OWOUfWmzTBI4iPELSCJrLz2zbwBBpcDTdeICwMaTkUoiPiLPt XBRandsR9UR5vKep1UayI8RVfmtcskm7e/aA5HNg999lrhIadf2s7qXO bfsP+yRBNSh9pC7CRFYC2nLKHifx9U/7f/q4BjPPFh8aVr5ZH74o/WrR FlU=
calendar.isc.org.	3073	IN	NSEC	calendar2.isc.org. A RRSIG NSEC

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 30 12:19:37 2012
;; MSG SIZE  rcvd: 472

DNS64 is using the wrong bit to disable DNS64 processing.  DO is
the correct bit.

Now if I just set CD=1 it would be perfectly fine to apply DNS64
processing to that answer as the client cannot detect the substitution.

; <<>> DiG 9.7.3-P3 <<>> aaaa calendar.isc.org +cd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25289
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;calendar.isc.org.		IN	AAAA

;; AUTHORITY SECTION:
isc.org.		2834	IN	SOA	ns-int.isc.org. hostmaster.isc.org. 2012012900 7200 3600 24796800 3600

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 30 12:23:36 2012
;; MSG SIZE  rcvd: 88

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Jan 2012 13:01:41 +1100

Attempting to determine intent from DO and CD as section 3 of RFC6147
does is "just not possible".  DNSSEC does not have the "I intend
to validate" bit and no combination of bits means "I intended to
validate".  Pretending that there is such a combination does no-one
any favours.

DO=1 means I want the DNSSEC records.
CD=1 means pass through answers and don't validate if you make upstream
     queries (recurse) to answer this query.

Neither indicates intent to validate however validation is only possible
if DO=1.

---

From: <[email-masked]>
Date: Mon, 30 Jan 2012 12:33:51 +0000

> Fair point.  Teemu, Jouni, thoughts on this?
 
The text was attempting to tackle the following attack:
- Legitimate network A is using NAT64 and related domain names are all secured with DNSSEC
- Host is in hostile network B, where attacker has control over local DNS64, NAT64 and routing services
- Host performs AAAA query for the well-known name, which is replied by attacker's DNS64 using network A's Pref64::/n
- Host performs reverse query to find the FQDN for the prefix, and find's network A's NAT64's FQDN (attacker not involved in this query)
- Host performs forward query for the learned name, validates response with DNSSEC, and gets the same Pref64::/n as it got originally for the well-known name (attacker not involved in this query)
- Host thinks it has learned Pref64::/n safely

Except that the host has not, because even though the discovered Pref64::/n was matching the NAT64 FQDN and all that just fine, the host is in a network B that should not be using the network A's Pref64::/n and hence all host's packets could be routed to network B's NAT64 under control of attacker (instead of NAT64 of network A - remember attacker has taken over routing to Pref64::/n).

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Mon, 30 Jan 2012 12:51:57 +0000

Hi Cameron,

> Well, in the draft, the only guidance for ipv4only.arpa ttl is that it not exceed
> 1 year... which does not help in this situation.
> 
> The draft would benefit from explicitly stating discovered pref64 ttl = pref64
> fqdn ttl. That way the ttl is completely in control of the network operator.

The operator is in control of TTL used in synthetic AAAA records operator's DNS64 creates, or am I mistaken? And that TTL does not have to equal to related A record TTL. I.e. even if ipv4only.arpa would have 1 year TTL, the DNS64 that synthesizes IPv6 addresses can use much lower TTL, hence cause nodes to have much shorter TTL for the discovered prefix. 

If the host performs PTR query and forward AAAA query as currently described in DNSSEC section, then I guess the TTL used by node could be the NAT64 FQDN TTL?

> It does not need to be this way, right? What you really want is a pairing of
> dns records, right? If that is what is needed, then lets say that. I would much
> rather pair the pref64 fqdn with a dummy fqdn for this purpose.  It is not
> acceptable to network operators to have a name for an interface we do not
> want traffic to be destine to.
> 
> Not nice. Cgn boxes are lots of asics / fpga / blah and relatively weak control
> plane processors that explicitly rate limit icmp to avoid control plane
> resource attacks. You cannot prescribe how this can be treated, the existing
> text is not acceptable.  It may be acceptable if you think NAT64 is a Linux box,
> but in may large deployments, it is a very different case.
>
> Net net, this draft, IMHO, needs to define a procedure based on fqdn and
> optional connectivity checks.

What we are looking here is to enable connectivity checks without mandating developers to host connectivity check servers and to keep connectivity checks as local as possible. 

> It is not acceptable to expect any interface on the nat64 node to have an
> fqdn or to send icmp connectivity checks to the nat64 node.  The

The IPv4 address found via described procedure does not really have to point to NAT64, it can point to any IPv4 address chosen by the owner of NAT64's FQDN, or be non-existent... I.e. you could disable connectivity checks by not having A record (which is the case anyway currently as there's no standard way for host to learn NAT64's FQDN, which does not necessarily even exist), or you could point the checks to separate server.

So.. would it help if we would move all of the A record stuff from DNSSEC section to the optional connectivity check section, and describe there that network operator may help nodes on connectivity checks by having A record for the NAT64 FQDN that points to somewhere (be that NAT64 itself, or some dedicated server)? 

Best regards,

Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jan 2012 08:32:05 -0500

Mark,

> validate".  Pretending that there is such a combination does no-one

I do not believe that RFC6147 is intending to determine intent at all.
First, section 3 isn't normative; it's some background that is
intended to motivate the decision to use CD as an extra signal.  But
anyway, as I already suggested in the previous message, section 3
number 3 is likely overstating its case.

All of that said, you seem to be ignoring the use case for DNS64.
Remember that DNS64 _is not_ DNS.  It is a substitute protocol that
systematically alters DNS packets and looks like ordinary DNS under
some circumstances; but it's not the DNS.  The whole point of DNS64 is
that you can put it into an already-deployed network where network
endpoints have IPv6 connectivity, and allow those endpoints to reach
the IPv4 networks using the DNS64/NAT64 trick.

Given that that is what we were trying to do, we clearly couldn't use
DO=1 to signal that the end point needed the original, unmolested DNS
packages, because a large number of resolvers that were shipped in the
past set DO=1 regardless of whether they were planning to validate the
records.  This is fine: DO=1 just means "DNSSEC OK".  But it is the
very lack of a mechanism to signal, "I will validate this answer,"
that causes us a problem.

The only reliable way to validate an answer yourself is to set CD=1.
You have to hope that upstreams, if there are any, also set CD=1 when
they send their queries along; but that instruction (which is
contained in a dnsext document, as you know) isn't in scope for this
WG nor for RFC6147.

Now, given that DNS64 is intended to be used in environments where
there are deployed systems, we had to make a decision about what to do
for end points that wanted to do their own validation.  And the answer
there is twofold.  First, since the only way to be sure you get all
the necessary validation data is to set CD=1, RFC6147 insists that
people behind a DNS64 who want to validate must set CD=1.  Second,
since we had to be able to deploy this in environments where there
already were existing, DNS64-oblivious resolvers that always set DO=1,
we could not use DO=1 as a signal to send an unmolested real DNS
answer to such a query originator.  At the time RFC6147 was written,
validation at end points practically never happened; and even if it
did, it was by people who were more technically clueful and therefore
more likely to be able to upgrade their systems to support DNS64 as
well.  (It seems to me that both of these observations are still true
today, FWIW.)

This was the trade-off we made.  We did not use the EDNS0 option
approach because we decided to specify the mechanism for signalling
the need for DNS64 awareness separately from DNS64 itself -- a
decision I now regret, given the way we seem doomed to do it.  But I'm
not sure we would have made any progress if we'd argued about such
signalling at the time.

So yes, you are quite correct that there is no way to say, "I'm going
to validate this."  We agree about it.  What we do not agree about,
apparently, is what DNS64 should do in order to get around that.
Given the purposes for which DNS64 was intended, it seems to me that
the trade-off we made was the right one, even though I find it
unsatisfying.  You apparently would like a different one, but as
nearly as I can tell your position would make DNS64 send many more
queries in practice.

> DO=1 means I want the DNSSEC records.

I'm not sure I agree with you about that interpretation.  When
serving, DO=1 means, "Send the DNSSEC records."  But when querying,
DO=1 might not mean, "I want those records."  It might mean "I am
security-aware."  For section 3.2.1 of RFC4035 says this:

   The resolver side of a security-aware recursive name server MUST set
   the DO bit when sending requests, regardless of the state of the DO
   bit in the initiating request received by the name server side.

I suspect, in fact, that the above passage is exactly why we have so
many ordinary DNS resolvers that set DO even though they're not
validating: they're in non-validating, security-aware mode, and the
above text suggests that they have to set DO.  That fact is how we got
to the behaviour in DNS64 in the first place.

I'd like not to crowd this list with a lot of arguing about how DNS
itself ought to handle these cases.  I'm trying to respond to what
you're suggesting for the narrow case of DNS64.  What ordinary DNS
resolvers ought to do is actually the subject of an ongoing last call
in another working group.  If you have something to say about that,
I'd suggest you post your views in response to that WGLC (except that
I note you already have done).

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 31 Jan 2012 01:54:01 +1100

> that causes us a problem.

And CD=1 will not help with this senario.  The non-validating
resolver will cache the DNS64 translated responses and will return
those translated responses to DO=1,CD=1 queries which will then
fail to validate.  Or if the DO=1,CD=1 query is the first query
then the non validating stub resolvers will get NODATA responses
to AAAA queries instead of synthesised responses.

The same will happen with a validating resolver and any signed
answer that validates as insecure.

Put a DNS64 recursive server (as described in RFC6147) in front of
a non validating DO=1 recursive server in front of a validating
recursive server.  Then ask the non validating recursive server
some questions which trigger DNS64 processing from a signed zone.
Then ask the validating recursive server the same questions.

> contained in a dnsext document, as you know) isn't in scope for this

But CD=1 does *not* say "make a new upstream query even if you have
cached data".  The validating stub resolver will not get good data.
It will get DNS64 tainted data from the cache.

> the necessary validation data is to set CD=1,

	Not true.

>						 RFC6147 insists that
> people behind a DNS64 who want to validate must set CD=1.

	Which won't help.

>							     Second,

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jan 2012 10:10:54 -0500

> to AAAA queries instead of synthesised responses.

Ah, wait.  You are worried about the case where a caching
security-aware non-validating dns64-oblivious recursive resolver is
behind a DNS64, and providing service for other clients inside that
network?  Yeah, that won't work.  There's a rather clumsy and
too-short discussion of some (but not all) of these issues in RFC6147,
section 6.

> recursive server.

No, don't.  It won't work reliably, I agree.  Basically, if the DNS64
isn't the last hop before the validation point, then you're screwed.

At the same time, I'm a little alarmed at the prospect of caches that
hand out queries discovered with CD=0 to clients querying with CD=1,
regardless of whether they are a DNS64 or a DNS server.  That should
likely be taken up on another list, however.

> > the necessary validation data is to set CD=1,

I think we are just talking with different implicit scope here, but
that's a general DNS issue and not, I think, a subject for this list.
I believe what I said, however, and I think a careful reading of RFC
4035 backs me up.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Jan 2012 08:14:23 -0800

> > Well, in the draft, the only guidance for ipv4only.arpa ttl is that it
not exceed
> The operator is in control of TTL used in synthetic AAAA records
operator's DNS64 creates, or am I mistaken? And that TTL does not have to
equal to related A record TTL. I.e. even if ipv4only.arpa would have 1 year
TTL, the DNS64 that synthesizes IPv6 addresses can use much lower TTL,
hence cause nodes to have much shorter TTL for the discovered prefix.

I believe you are mistaken. Rfc 6147 says the original ttl is passed on,
from the best of my reading.

> If the host performs PTR query and forward AAAA query as currently
described in DNSSEC section, then I guess the TTL used by node could be the
NAT64 FQDN TTL?
> > It does not need to be this way, right? What you really want is a
pairing of
> What we are looking here is to enable connectivity checks without
mandating developers to host connectivity check servers and to keep
connectivity checks as local as possible.

Pushing the burden to the operator is not acceptable without consent. I
suppose having that fqdn implies consent

> > It is not acceptable to expect any interface on the nat64 node to have
an
> The IPv4 address found via described procedure does not really have to
point to NAT64, it can point to any IPv4 address chosen by the owner of
NAT64's FQDN, or be non-existent... I.e. you could disable connectivity
checks by not having A record (which is the case anyway currently as
there's no standard way for host to learn NAT64's FQDN, which does not
necessarily even exist), or you could point the checks to separate server.
>
> So.. would it help if we would move all of the A record stuff from DNSSEC
section to the optional connectivity check section, and describe there that
network operator may help nodes on connectivity checks by having A record
for the NAT64 FQDN that points to somewhere (be that NAT64 itself, or some
dedicated server)?

Yes. That would help. But, pinging the cgn is really a recipe for disaster
that I would rather not see documented or suggested without caution.

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Mon, 30 Jan 2012 12:33:43 -0700

Hi Teemu,

> > >
> > > I don't like this requirement because it is forcing the DNS server
> to support views. Additionally, you will have to update the
> authoritative DNS every time you start provisioning your clients with
new
> addresses from new IPv6 networks.
> >
> - Host performs AAAA query for the well-known name, which is replied
by
> attacker's DNS64 using network A's Pref64::/n
> - Host performs reverse query to find the FQDN for the prefix, and
> find's network A's NAT64's FQDN (attacker not involved in this query)
> - Host performs forward query for the learned name, validates response
> with DNSSEC, and gets the same Pref64::/n as it got originally for the
> well-known name (attacker not involved in this query)
> Except that the host has not, because even though the discovered
> Pref64::/n was matching the NAT64 FQDN and all that just fine, the
host
> is in a network B that should not be using the network A's Pref64::/n
> and hence all host's packets could be routed to network B's NAT64
under
> control of attacker (instead of NAT64 of network A - remember attacker
> has taken over routing to Pref64::/n).

Is sounds very easy to circumvent the security in the proposed discovery
algorithm in that case.
Why would the attacker use A's Pref64::/n why couldn't he just use his
own Perf64::/n and insert the appropriate records into DNS?

/Stephan

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jan 2012 11:55:44 -0800

> Sent: Monday, January 30, 2012 11:34 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: DNSSEC and NAT64 Discovery Heuristic [was RE: [BEHAVE] I-D
> Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt]
> 
> Hi Teemu,
> 
> > > >
> > - Legitimate network A is using NAT64 and related domain names are
> all
> > secured with DNSSEC

The host needs to be configured with the domain names of the NAT64
devices it will trust -- for example, if I get my Internet service 
from Comcast, I would configure my host to allow a name of 
*.comcast.net for the NAT64.  The trusted domain name could reasonably 
be populated by the 'DNS Search List' (DNSSL) provided by DHCP, which 
eliminates the need for any manual configuration, and would work in 
many cases when visiting a friend's house or coffee shop.

This is described in step #b of
http://tools.ietf.org/html/draft-wing-behave-learn-prefix-04#section-5.  But
I see we missed step #b when
http://tools.ietf.org/html/draft-wing-behave-learn-prefix-04#section-5 was
incorporated into draft-ietf-behave-nat64-discovery-heuristic.  Sorry about
that.

-d

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Mon, 30 Jan 2012 14:02:49 -0700

> *.comcast.net for the NAT64.  

Thanks, that make sense but it raises another question: If you 
already know that you are in example.net (or Comcast.net in your 
example). They why couldn't you just ask for 
what-is-my-prefix.example.net, 
what-is-my-prefixlength.example.net,
what-is-my-suffix.example.net ? 
Those could be signed with DNSSEC. That sounds like a much simpler way 
of learning the prefixes.

/S

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Mon, 30 Jan 2012 14:03:20 -0700

Hi Andrew,

> Remember that DNS64 _is not_ DNS. 

My concern is that it is impossible to know if you are behind DNS64 or
not. 
How would somebody validating know that? For somebody behind DNS64, 
DNS64 _is_ DNS.

/S

---

From: Mark Andrews <[email-masked]>
Date: Tue, 31 Jan 2012 08:09:05 +1100

> isn't the last hop before the validation point, then you're screwed.

And RFC6147 doesn't provide any way for a caching server to learn
the DNS64 prefixes to apply from upstream.  It doesn't provide a
away for answers to DO=1 queries not to be tainted.

The EDNS option I suggested earlier in the thread would be sufficient.
Maintain a reference counted cache of learned prefix sets and record
a reference to it with the AAAA nodata negative cache entry.  The
DNS64 prefixes would timeout when the nodata negative cache entry
times out.

Alternatively we could make it more complicated and send the full
policy, client address to match (IPv4 and IPv6) and exclusion address
(IPv4 and IPv6) and TTL.  Upstream requests would include a 32 (64?)
bit hash of the DNS64 policy so that it doesn't have to be transmitted
on every AAAA response.  Sending that hash in the response would
update the TTL entry.

> likely be taken up on another list, however.

While it is fodder for the other list, it isn't wrong as the RFC 4035
now stands.  Additionally asking upstream again on CD=1 is not sufficient
as there is no control of which server is queried.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jan 2012 16:23:26 -0500

> How would somebody validating know that? For somebody behind DNS64, 

Exactly.  That's what this heuristic draft is trying to work out.

I haven't yet had a chance to review the latest version.  I have to be
honest that I remain a little sceptical that this approach is the best
way to do it.  (Ok, to be blunt: I think this is an awful idea, but
since people are apparently going to implement this anyway, we might
as well do it right.)

I am also still somewhat sceptical that all the machinery in Dan's
forward- and reverse-tree mechanism is really necessary, especially
since it requires the static list of "trusted DNS64s" (that part is
the thing that bugs me the most).  But I _think_ the current proposal
mostly works anyway.

One important thing, though: I don't believe that DNS64+NAT64 is going
to be that reliable.  That is, I expect it to have failure modes that
are persistent and annoying, especially in the face of DNSSEC.  I also
don't think there's anything we can really do about that: all the
other options seem to me to be at least as complicated or prone to
failure.  I think the best bet is going to be to have last-hop
security between stubs and the DNS64 doing recursion; and then to use
the AD bit and validation at the DNS64 to solve most of that problem.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jan 2012 16:32:31 -0500

On Tue, Jan 31, 2012 at 08:09:05AM +1100, Mark Andrews wrote:

> the DNS64 prefixes to apply from upstream.

Correct.

> The EDNS option I suggested earlier in the thread would be sufficient.

And it's little different from a similar thought I had when the DNS64
work started taking off.  Everyone said at the time, "Not going to do
an EDNS0 option."  Similarly, the current heuristic draft picked the
well-known name strategy because at some relatively recent IETF
meeting (Prague maybe?  less recent than I thought, I guess) someone
stood at the mic and said, "Add EDNS0 options and other gewgaws all
you want.  I'm going to implement a well-known name anyway."  That's
how an EDNS0 option disappeared from the WG's plans for how to handle
this signalling.

> DNS64 prefixes would timeout when the nodata negative cache entry

How will applications learn about all of this?  There are applications
that need to know about the NAT64 too, because they have IPv4 literals
in them (yes, I know they shouldn't have done that.  If I ran the
circus, the ponies would run in the other direction, too).  Since the
API to DNS data is so crummy, those applications have no easy
(i.e. accessible to people who don't actually know about DNS) way of
learning this.  So they're going to implement this dirty
well-known-name hack anyway.  Therefore, we need to make it as non-bad
as it can be, rather than making it good.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jan 2012 14:53:04 -0800

> Sent: Monday, January 30, 2012 1:03 PM
> Subject: RE: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-
> DAction: draft-ietf-behave-nat64-discovery-heuristic-05.txt]
> 
> >

It won't always work.  In my own home, for example, I override my
ISP's DNS search list to one of my personal domains.  Thus, if 
we only query <IANA_registered_name>.example.net, it would fail
in those instances.  Querying ipv6only.arpa would always work
in those cases.

DNSSEC validation is intended to be optional.

-d

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Mon, 30 Jan 2012 18:51:34 -0700

> in those instances.  Querying ipv6only.arpa would always work

Ok, now I'm confused. You just said that the host needs to be 
configured with the domain names of the NAT64 it will trust...

> DNSSEC validation is intended to be optional.

Thanks for clarifying this. You should probably spell that out in 
the draft. (I was reading it as if DNSSEC were mandatory and that the CD
bit
was set from all handsets/clients.)

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jan 2012 18:17:08 -0800

> Sent: Monday, January 30, 2012 5:52 PM

As document author:

For doing the DNSSEC validation, yes, that's right.  If the
host doesn't want to validate the information it gets from
its ipv4only.arpa query, it can just use it -- it will be
approximately (not exactly) as trustable as other DNS
responses it receives.

Not every host will do DNSSEC validation ("walk, then run").
But, when a host wants to do that, we wanted explanation for
how it happens.

> the draft. (I was reading it as if DNSSEC were mandatory and that the
> CD bit was set from all handsets/clients.)

It's in a subsection right now; I agree that dropping it later 
into the document would help.

-d