Subject: Re: NAT64 and DNSSec

From: marcelo bagnulo <[email-masked]>
Date: Wed, 02 Apr 2008 18:01:55 +0200

Hi Michael,

see inline...

Michael Richardson escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> okay, so I don't understand the problem, I think.  I read the thread.
> Are you talking about a v4v6v4 mechanism?
>
>   
not really. I am considering communications IPv6-> IPv4 and 
communications IPv4 -> IPv6.
I am not considering the v4v6v4 case or any other more complicated scenario

>   I don't see a problem for v4 nodes that are DNSSEC enabled
>   talking to v4 nodes out there.  Everything should just work.
>
>   
the problem is for v4 nodes that want to initiate a communication with a 
v6 node. In order to do that, we need a synthetic A RR and DNSSec will 
not be able to validate that. This problem is hard, cause even if you 
modify the v4 node, the only one that has auhtority in determining which 
is the v4 address that will be used to reach the v6 address is the NATPT 
box itself, which makes the validation of the synthetic A RR using 
DNSSEc very hard

>   The issue is I see is when an "educated" v6 node in the
>   v6-part of the v4v6v4 cloud wants to talk to a v4-only node
>   that is out there.  That's was where, I think, the thought
>   that we need a synthetic AAAA record is.
>
>   
i was thinking in the case where a an IPv6 node wants to communicate 
with a IPv4 node, In order to do that we need synthetic AAAA RR.

> It seems to me that the problem is resolved if we apply the end-to-end
> principle: the end-node needs to do the work.  No hacking the data in
> the middle.
>
>   
right, there are two issues here afacit:
- first, it would be better if we could deal with legacy IPv6 
implementations (even if in this case DNSSec doesn't work) but build in 
the NATPT behaviour enough features so that upgraded v6 nodes could make 
the DNSEC validation, do you think this is a reasonable goal. So 
probably we want to send the synthetic AAAA RR to the v6 node, so in 
case the node is a legacy box, it simply accept it and cannot make the 
DNSSEc verification, but if it is an upgraded IPv6 box, it can tell this 
is synthetic AAAA RR and also can perform the DNSSEc validation. In 
order to do that, we need to include in the synthetic AAAA RR the 
signature information of the original A RR.
- second, the question is whether the IPv6 node has all the information 
to do the operations that it needs to do do. I mean, in order to 
generate the synthetic AAAA RR, the node needs to know the /96 prefix 
that will be used to generate the v6 address associated to the v4 
address. This information is specific to the NATPT box, so the end node 
will need to learn that information from the NATPt box (this is needed 
also to perform the validation) This can be done, and the problem is not 
so hard as in the case of the synthetic A RR cause the end host only 
needs to learn the prefix (whcih seems to be pretty stable), while in 
the case of the synthetic A RR, the host needs to learn the actual v4 
address associated to the v6 address, which seems highly volatile

> That means that any AAAA record synthesis needs to happen in the
> end-node, (in the resolver library if appropriate for that OS), *AFTER*
> the DNSSEC has been done. 
>
>   

righ but see below, about why it may be needed to use the synthetic AAAA 
RR for backward compatibility with exsiting v6 hosts and then using the 
DNSEc information of the original RR for making the DNSSec validation

> And this is necessary only for v6-only nodes.
> v4/v6 nodes do nothing --- they just act as v4 nodes and experience v4/v6/v4.
>
>   
right but i was not considering this case

> I don't believe the "v4-initiated" situation is real.
>   
well, othe rpeople beleive this is imporntat, especially in the mddle 
term , when maybe there is an imporntat part of v6 only nodes, and v4 
nodes will want to communicate with them
Making DNSSec work with synthetic A RR is more difficult even if you 
upgrade the v4 nodes, cause the endpoint will need to communicate with 
the NATPT box to obtain the address that is included in the synthetic A 
RR. the point is that in this case, the v4 node must trust the natpt box 
to perfomr the DNSSec validation on its behalf and/or trust its work 
about which IPv4 address needs to be used to reach this v6 address.

Of course, what can be done, is also to keep the DNSSec information of 
the original AAAA RR so that the v4 only node cna verify that this node 
is a v6 node (and could also obtain DNSSec information figuring out that 
this node has no v4 address, so it can accept to use the NATPT, 
preventing possible downgrading attacks, where the natpt lies about the 
non existance of v4 address for a given FQDN). I thin we shoudl do this 
last thing, not sure if we should do much more to support DNSSEc with 
synthetic A RR

So, concluding:
- I think DNSec validation should be done by upgraded hosts. I think 
that NATPT mechanisms should work with legacy hosts even if DNSSEc 
validation cannot be perfroemd and that upgraded hosts should be able to 
restore some of the lost DNSSEc capabilities, makes sense?
- I think that validfation of synthetic AAAA RR could be possible, and 
for that we need: to keep the original information of the DNSec 
signature in the syntetic DNS reply. Mark this as a synthetic RR using a 
EDNS0 option and learn the /96 prefix form somewherte trsuted
- I think that the validation of synthetic A RR is muych harder. I think 
that what must be done is to let the upgraded end host to be able to 
verify that no original A RR exsits for the FQDN and to keep the 
original AAAA RR and signature in the reply. The rest is a matter of 
trust between the end host and its NATPT box

Do you agree with this?

Regards, marcelo

> I do believe that v6->v4 NAT-PT is critical to making v6 deployable ---
> the ROI for putting the v6 into the small device in a home is that you
> can yank out the complicated v4 goop.  Combined with a NAT-PT in a
> home-router and 6to4 on it.  But that requires synthesized AAAA.
>
> I didn't understand Iljitsch's comments:
>
>   
>>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
>>>>>>             
>     Iljitsch> This is the rationale behind working with A records rather
>     Iljitsch> than fake AAAA records in MNAT-PT. This makes most of the
>     Iljitsch> compatibility issues go away, at the cost of having to
>     Iljitsch> come up with a mechanism to distribute the /96 for the
>     Iljitsch> translator to the hosts in question and implementing this
>     Iljitsch> mechanism and some other logic in the IPv6 hosts.
>
> perhaps I need a reference to a draft/RFC?
>
>  
> - -- 
> ]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBR/LK9YCLcPvd0N1lAQLSAAgAnTJeLYlVCfnW3hX+0lj//DCAIWQMBgiy
> ebJ0D/d/qM6MyiG96h2XnPN8hXErvP+qOYkjggZ2/fFcB7WvzfhOQICob+c6QAsJ
> Ux5qgpSDTm+qTL3zViNdb5A75d9xqVALvipyTfm1YiEUhe2SkaQka4aWMUNVl8Ie
> HW8tTrY4hAFME+coBWiMF20ZGuuBDm3O88zlHCg0NkYAppKV2gTXKOTaP8mggQ1A
> Fk7lRGLVKRvt+apcVFUk7DV8YLM6Djj7lSod6mlDzGmgan0xAIMwH+QpQZCE+YbU
> 1Jbj/o8N2X/EW8PevQOdgM9wYH0Zhr+MURFzzJwtdrbCI0I7l8wbFA==
> =IcJX
> -----END PGP SIGNATURE-----
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Apr 2008 19:54:16 -0400

- --