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

Re: NAT64 and DNSSec



Hesham Soliman escribió:
- 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?

=> Personally I prefer discussing the requirements without mentioning how it can be addressed in the solution :)
right

but that might be too idealistic.
exactly

I don't see a need to require something that we can't support, i.e. DNSSEC.
that is exactly the point for this discussion, figure out if we can support it somehow, and then require it :-) As i mentioned in the mail to George, it may be possible to make a mechanism that works with legacy hosts without DNSSEc but that upgraded hosts can perform DNSSec validation. That would leave the door open to restore DNSSec fucntionality if hosts are upgraded,. I think this is a reasonable tradeoff, don't you think so?

(however, i am not sure this is possible in the v4 side though)

With NAT64 other IETF security protocols will not work anyway,
well, i am preparing a thread on IPSec, so we can continue this discussion there :-) I agree that security is weakened, but i would like to understand if some of the security can be preserved and moreover, if it can be restored if hosts are (optionally) upgraded, which i think it is the best tradeoff we can do

Regards, marcelo


so I'm not sure that DNS should be a special case. Also, I'm against requiring any special tricks in the host, it's really late for that IMHO.

Hesham



Regards, marcelo