Subject: NAT64 and DNSSec

From: marcelo bagnulo <[email-masked]>
Date: Wed, 26 Mar 2008 19:23:28 +0100

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Mar 2008 10:04:36 +0100

On 26 mrt 2008, at 19:23, marcelo bagnulo wrote:

> 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)

Right. However, this requires changes on the v6 host.

> 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.

What kind of solution do you have in mind here?

For v6->v4, the IPv4 address is mapped to IPv6 space locally. I.e., if  
you connect to the network elsewhere, you see a different mapping.  
This is easy because a 32 bit space fits into a 128 bit space 2^96  
times.

However, for v4->v6 there aren't even enough IPv4 address bits to map  
the IPv6 space into the IPv4 space _once_, let alone multiple times in  
multiple locations. If, on the other hand, we map a subset of the IPv6  
space into the IPv4 space once, this mapping is globally unique so it  
can be published in the DNS, which means that it can be signed with  
DNSSEC.

> - 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.

Right, and then a NAT-PT/DNSSEC aware host can perform the DNSSEC  
checks and the only thing it has to take on faith are the 96 top bits  
in the synthetic response.

These bits could be signed in some way, too, if desired.

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 27 Mar 2008 13:07:06 +0000

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Mar 2008 15:43:09 +0100

> software called "IPv4 stack" :-) ...

This is the rationale behind working with A records rather than fake  
AAAA records in MNAT-PT. This makes most of the compatibility issues  
go away, at the cost of having to come up with a mechanism to  
distribute the /96 for the translator to the hosts in question and  
implementing this mechanism and some other logic in the IPv6 hosts.

However, the translator remains the same so all of this should be  
incrementally deployable.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 27 Mar 2008 11:29:07 -0700

At Wed, 26 Mar 2008 19:23:28 +0100,

> EDNS0 tags that they don't know? or they drop these replies?)

I don't have a general answer, but libbind (which is incorporated to
the resolver library of many UNIX-like OSes) "accept"s such responses;
actually, it doesn't even care about the contents of the additional
section at all.

FYI, a proposed revised draft of EDNS0
(draft-ietf-dnsext-rfc2671bis-edns0-01.txt) clarifies this point:

========================================================================
4.4.2. Any OPTION-CODE values not understood by a responder or requestor
MUST be ignored.  So, specifications of such options might wish to
include some kind of signalled acknowledgement.  For example, an option
specification might say that if a responder sees option XYZ, it SHOULD
include option XYZ in its response.
========================================================================

And by the way, you should mean EDNS0 "options" (in the OPT RR rdata)
by EDNS0 "tags".

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 28 Mar 2008 09:07:12 +1100

> 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  
> the original v4 address. In the v4 initiated communication, i am not  
> sure how useful would that be.
>
> 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:

=> Personally I prefer discussing the requirements without mentioning  
how it can be addressed in the solution :) but that might be too  
idealistic. I don't see a need to require something that we can't  
support, i.e. DNSSEC. With NAT64 other IETF security protocols will  
not work anyway, 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

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 11:21:15 +0100

Hi Jinmei,

good input, thanks!

regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 17:33:53 +0100

Hi Iljitsch,

Iljitsch van Beijnum escribió:
>> 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)
>
this is an intersting point imho.
Here, a legacy IPv6 hosts without no specific changes would be able to 
process this, but it would lack of security features. However and 
upgraded ipv6 host would be able to perform the verification

So, this seems a good tradeoff, cause it works for legacy hosts (withotu 
security) but iut enables the secure options, if hosts upgrade to 
support it.

so, this could be a good requirement, that i think it is on the lines of 
the current document:
- The (DNS) mechanism should work for legacy hosts
- Upgraded hosts must be able to perform DNSSec validation and make it work.

It seems that this is possible for v6 hosts, would it be possible for v4 
hosts?

> For v6->v4, the IPv4 address is mapped to IPv6 space locally. 
what do you mean by locally?

> I.e., if you connect to the network elsewhere, you see a different 
> mapping. This is easy because a 32 bit space fits into a 128 bit space 
> 2^96 times.
>
i don't have a preference here, but i am nore focused in the 
requirements that we can impose right now.
Do you think it would be possible to impose any form of requirement for 
using DNSSec in the v4 host?

>> 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 
righ, but i fail to see if it would be possible to do it in the v4 world

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 17:44:54 +0100

Hi George,

> v4NATs have proliferated because they are (almost) invisible to IPv4

as currently defined the requirements allow modifications in the v6 side

(My personal opinion, is that a good mechanism should work with legacy 
(v4 and v6) hosts but it would benefit from additional features if the 
host is upgraded. For instance, DNSSec validation. For a legacy host it 
is not possible, but the mechanism should allow that if the host is 
updated, then it can restore the lost fucntionality.

I mean, we have two oposing interests here:
- on one side, i agree with you that if we have the mechanism that works 
wihtou requiring modifictions to the (v4 and v6 hosts) its adoption is 
easier.
- However, doing that will imply to give up some features that are 
importnat (like DNSSec deployment). If we simply allow a mechnaims that 
make these features impossible, then we are simply giving up these 
features in the long run and cannot be restores.

so imho, the mechanism should allow to support these additional 
features, if the host implements an additional mechanism, allowing to 
restore these features

I think DNSSec is a clear example of this

> still have a chance to make "NAT64-aware" software ubiquitous in
so i think we agree here?

Two levels of support: basic for legacy hosts that may break some stuff 
and improved level for upgraded hosts that restore the lost functionlity?

The problem is that even in this case, there seem to be things that are 
not clear if they work (like DNSSEC in the v4 side)

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 17:46:48 +0100

Iljitsch van Beijnum escribió:
> AAAA records in MNAT-PT. 

but this imposes changes in the v6 nodes in order to support that, right?
I mean the v6 node would need to create the IPv6 address from the A record.

This is why i think including both the AAAA and the A (keeping the 
signature as Kurtis suggested) is better, casue, it allows for legacy 
hosts to work and for upgraded hosts to be able to validate DNSSec

Regards, marcelo

> This makes most of the compatibility issues go away, at the cost of 
> having to come up with a mechanism to distribute the /96 for the 
> translator to the hosts in question and implementing this mechanism 
> and some other logic in the IPv6 hosts.
>

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 17:50:55 +0100

Hesham Soliman escribió:
>> this would be perfect, but is simply incopatible with the requirement 
>> of not modifying v4 nodes.
>>
>> so, my questions are:
> 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
>>
>>
>>
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Mar 2008 21:23:04 +0100

This:

>> mapping.

If I connect to ISP A I'd probably see 2001:A::FFFF:0:0/96 as the  
translator prefix and if I then move to ISP B the translator prefix  
there would be something like 2001:A::FFFF:0:0/96. So the 6->4 mapping  
is a local matter.

On the other hand, if for v4 we assume that there is only a single  
IPv4 address that maps to a single IPv6 address (or v4/port to v6/ 
port) because there aren't enough v4 addresses to have several of them  
map to the same v4 address, the IPv4->IPv6 mapping is globally unique  
so it can be published in the DNS. This also means that the records  
can be signed so there shouldn't be a DNSSEC issue. (Note though that  
this requires DNS records TBD. See the MNAT-PT draft for what this  
_could_ look like.)

> Do you think it would be possible to impose any form of requirement  
> for using DNSSec in the v4 host?

Well, for v6->v4 we currently have the synthetic AAAA records. A  
translator that doesn't use these is possible in this direction, and  
even likely in the v4->v6 direction because we don't have an existing  
spec that uses synthetic records for that direction. Even if we use  
the DNS for this synthetic A records seem unlikely so there shouldn't  
be DNSSEC issues. Although if we use additional records to aid in the  
transition we'd probably want those to be signed too if the original  
FQDN->A mapping is signed, but since the path through the hierarchy  
must be different (the FQDN isn't available to the translator so it  
has to do some kind of PTR lookup) this could be fairly non-trivial.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 29 Mar 2008 10:58:51 +1100

> 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?

=> Sorry my comment was not clear. I meant that we won't be able to  
get e2e DNSSEC in all cases. I guess you're trying to work out the  
most graceful way of handling that, which is fine with me. I'd just  
call that DNSSEC "handling" rather than support, but it's just  
wording. I understand what you're trying to do now.

> well, i am preparing a thread on IPSec, so we can continue this  

=> Sure but it's not just IPsec, it's also app-level security for  
those apps transferring addresses (other than the DNS of course).

Hesham

---

From: marcelo bagnulo <[email-masked]>
Date: Sat, 29 Mar 2008 11:01:18 +0100

Iljitsch van Beijnum escribió:
> IPv4 address that maps to a single IPv6 address (or v4/port to 
> v6/port) because there aren't enough v4 addresses to have several of 
> them map to the same v4 address, the IPv4->IPv6 mapping is globally 
> unique so it can be published in the DNS. This also means that the 
> records can be signed so there shouldn't be a DNSSEC issue. (Note 
> though that this requires DNS records TBD. See the MNAT-PT draft for 
> what this _could_ look like.)
>
> spec that uses synthetic records for that direction. 

I don't understand this
Are you saying that we don't have synthetic A records. What about 
section 4.1. of RFC 2766?

What we may not need are synthetic AAAA records, since we can assing a 
fixed IPv6 address to any v4 address, but we will need synthetic A 
records, and these are the ones that can hardly verified using DNSSec 
even if we upgrade the v4 side to do some special DNSSec magic, since it 
woudl require communication with the NAT64 box.
Am i misisng something here?

Regards, marcelo

> Even if we use the DNS for this synthetic A records seem unlikely so 
> there shouldn't be DNSSEC issues. Although if we use additional 
> records to aid in the transition we'd probably want those to be signed 
> too if the original FQDN->A mapping is signed, but since the path 
> through the hierarchy must be different (the FQDN isn't available to 
> the translator so it has to do some kind of PTR lookup) this could be 
> fairly non-trivial.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Mar 2008 14:58:50 +0100

On 29 mrt 2008, at 11:01, marcelo bagnulo wrote:

>>> Do you think it would be possible to impose any form of  
>>> requirement for using DNSSec in the v4 host?

>> translator that doesn't use these is possible in this direction,  
>> and even likely in the v4->v6 direction because we don't have an  
>> existing spec that uses synthetic records for that direction.

> section 4.1. of RFC 2766?

I don't think this is a useful scenario. What happens here is that  
IPv6 addresses are mapped to IPv4 addresses on a temporary basis,  
which makes referral issues (and DNSSEC issues) much harder. It also  
requires a large amount of address space if done in a service provider  
box that serves many customers. I would rather map individual ports on  
a more permanent basis.

---

From: marcelo bagnulo <[email-masked]>
Date: Sun, 30 Mar 2008 10:35:52 +0200

Iljitsch van Beijnum escribió:
>>> even likely in the v4->v6 direction because we don't have an 
that can work easily for v4 initiated communications, but how can you 
make that work for v6 initiated communications?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Mar 2008 10:59:10 +1300

> updated, then it can restore the lost fucntionality.

I think we should aim for the "first, do no harm" principle
which indeed means

1. "no impact worse than NAT44" for the IPv4 host (i.e. no
   changes needed in the IPv4 host stack, but contortions
   like STUN and ICE may be needed).

2. "no loss of connectivity for legacy IPv6" (i.e. an
   unchanged IPv6 stack should see nothing worse that what
   it sees with old NAT-PT).

But certainly an updated IPv6 stack should see an improvement
on old NAT-PT, and authenticated DNS replies would be an
improvement.

    Brian