[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT64 and DNSSec
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 <iljitsch@muada.com> 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[
] mcr@sandelman.ottawa.on.ca 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-----