Re: NAT64 and DNSSec

["George Tsirtsis" <tsirtsis@googlemail.com>]

Hi Marcelo,

I think it is important to decide up front on whether NAT64 will
require specific behavior from the IPv6-only nodes behind it or not.
v4NATs have proliferated because they are (almost) invisible to IPv4
nodes behind them.

Many attempts to add something generic to IPv4 nodes behind NATs, to
improve their operation, have mostly failed with the exception of
mostly SIP-specific ICE. In practice, it is of course difficult to get
end nodes to cooperate unless the application they are trying to use
really does not work, which is why ICE became practical in case of
VoIP/SIP.

What I am trying to say is that IMO there is always going to be a
market out there for a box that is simply dropped in and makes things
work...(ok mostly work...). Such a drop-in box would at most do what
is indicated by Level1 or Level2 in your list. In any case, if this is
what we are trying to define then we have to first do the best we can
assuming no end node changes. Then we can add also add software(e.g.,
ICE) in the end nodes to make specific apps work that otherwise don't.

On the other hand, the WG and the IETF may not want to sanction such a
box e.g., because it breaks DNSSEC, and so we define things like Level
3 and/or 4 as well as possibly other end node changes that would also
help. This could be more realistic in this case since the number
IPv6-only nodes in the Internet is still rather low, in which case we
still have a chance to make "NAT64-aware" software ubiquitous in
IPv6-only end nodes.

A devil's advocate here would say that the best software you can add
to an IPv6-only end node  to make it work better with IPv4 is a little
software called "IPv4 stack" :-) ...

Regards
George


On Wed, Mar 26, 2008 at 6:23 PM, marcelo bagnulo <marcelo@it.uc3m.es> wrote:
> 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
>
>
>
>