[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6ops-nat64-pb-statement-req: DNSSEC requirement

On 22 jul 2008, at 23:20, Thomas Narten wrote:


  DNSSec support MUST NOT be prevented.
  o  R10.1: In particular, if an IPv6 node is initiating a
     communication with an IPv4 that is located behind a translator,
the IPv6 initiator MUST be able to perform DNSSec verification of the DNS information of the IPv4 target. (strong consensus on this 
     one).



  o  R10.2: In particular, if an IPv4 node is initiating a
     communication with an IPv6 that is located behind a translator,
the IPv4 initiator MUST be able to perform DNSSec verification of 
     the DNS information of the IPv4 target.  This may require the
     modification of the IPv4 node as well. (not clear if there
     consensus on this one)



Maybe I don't understand what the above means, but it seems to me to
be unworkable. I.e., If an IPv6 node requests an AAAA record for an
IPv4-only node, there won't be a AAAA record and it will need to be
synthesized. By definition, such a synthesized DNS RR won't be
verifiable via DNSSEC because it is in fact an unauthorized
fabrication.
That's true in an unmodified host that performs the DNSSEC validation itself.
If the DNSSEC validation is performed by a system that knows about NAT64 that system will reject the fake AAAA records by virtue of the EDNS0 SAS option (or simply because the validation fails) and can then retrieve the original A record and validate that.
Then, it can either conclude that the lower 32 bits of the fake AAAA record match the validated IPv4 address and allow the AAAA record, or determine the value of the 96 upper bits through a more secure mechanism and create a full 128-bit address that way.
The idea is that it's ok to break (some) stuff for existing systems as long as it's possible to fix this for updated systems.