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

NAT64 and DNSSec



Hi,

I am trying to define the rerquirements on new generation of NAT64 boxes w.r.t. DNSsec according to the disucssion we had in Philadelphia.

It seems clear that one strong candidate solution will use synthetic DNS records. It seems clear that these records are hardly compatible with DNSSec. Let's try to figure out what level of compatibility is reasonable to require.

- Types of communications:

We have v4 initiated communications and v6 intiiated communications.
In v6 initiated communications, the DNS reply will be recieved by a v6-only node and will contain a AAAA record. This will be a synthetic AAAA record containe a v6 address. It is possible that the v6 address is some for of v4 mapped addresses, so it would be possible to validate the synthtic AAAA record from the original A record, (if the v6 prefix is well known) In v4 initiated communications, we are not so lucky, cause the reply will be a synthtic A record, contianing a v4 address, that is likely to be the one of the translator, and has no relation with the original v6 address.

- Levels of support.

- Level 0: we don't anything special in the synthetic DNS reply. the translator just drops the DNSSec information and creates the synthethic DNS RR. the host recives it and doesn't know it is synthetic DNS RR. If it tries to validate it, it won't be able to do that, cause there is no DNSSec information. this may result in additional difficulties in DNSSec deployments, since if the usage of NAT64 boxes becomes pervasive, then unsigned DNS replies will become common and hosts need to accept them, since this is how the NAT64 boxes generate them.

- Level 1: We could add a tag on the DNS reply, EDNS0, marking these as synthetic RR, so the receiving host knows these are fake but that it should accept them anyway. this doesn't really solve the problem described above, but at least DNS semantics are preserved, since synthtic RR are explicitly marked and receivers know about that. (Questio for DNS guys, do normal hosts accept DNS replies contianing EDNS0 tags that they don't know? or they drop these replies?)

- Level 2: another option is to include both the EDNS0 tag and also the original information of the original RR, including the original address and the signature information. this would allow to verify the original packet, but then we need to verify the binding between the original address and the one actually included int eh synthetic DNS RR. In the case of v6 initiated communications, this is possible cause the v6 address included in the synthtic record is related to the original v4 address. In the v4 initiated communication, i am not sure how useful would that be.

- Level 3: extend DNSsec verification to soemwhere near the reciver. This would mean that it is not the NAT64 that generates the synthtic DNS RR but some other box, closer to the receiver does that, prior DNSSec verification. the problem with this approach is how the other box gets the address information that should be included int he synthetic RR. As above, in the v6 initiated case it may be possible cause the v6 address can be constructed from the v4 address, but in the v4 initated case, we need some for of communication with the NAT box, which is hardly a good idea.

- Level 4: generate the synthetic RR locally in the receiving node. this would be perfect, but is simply incopatible with the requirement of not modifying v4 nodes.

so, my questions are:
- are there any other levels of support/options?
- If not, what level should we require?

Regards, marcelo