Subject: [v6ops] NAT64/DNS64 and DNSSEC

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jul 2015 09:13:26 +0200 (CEST)

Hi,

as far as I know, DNS64 and DNSSEC are fundamentally incompatible, because 
modifying A records into AAAA records breaks DNSSEC.

Since we now have implementations (from what I understand at least APple 
does this) that do bump-in-the-API, would it make sense to work on a 
document that recommends to just use DNS64 just to discover the NAT64 
prefix, and then do bump-in-the-API synthesis to do the A-to-AAAA 
NAT64-mapping?

I really care about DNSSEC and I don't want this to be broken for a 
prolonged amount of time just because people are doing NAT64+DNS64.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2015 19:42:29 +1200

Read RFC 6147 - it covers this issue, and points out that
"The main drawback of this mode is its
deployability, since it requires changes in the end hosts."

Regards
   Brian

On 23/07/2015 19:13, Mikael Abrahamsson wrote:
> 
> Hi,
> 
> as far as I know, DNS64 and DNSSEC are fundamentally incompatible, because modifying A records into AAAA records breaks DNSSEC.
> 
> Since we now have implementations (from what I understand at least APple does this) that do bump-in-the-API, would it make sense
> to work on a document that recommends to just use DNS64 just to discover the NAT64 prefix, and then do bump-in-the-API synthesis
> to do the A-to-AAAA NAT64-mapping?
> 
> I really care about DNSSEC and I don't want this to be broken for a prolonged amount of time just because people are doing
> NAT64+DNS64.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jul 2015 09:55:16 +0200 (CEST)

> deployability, since it requires changes in the end hosts."

So you see no use for a document that gives guidance on this issue now 
that NAT64+DNS64 seems to be gaining traction, primarily in the mobile 
world?

---

From: "Heatley, Nick" <[email-masked]>
Date: Thu, 23 Jul 2015 08:17:54 +0000

>a document that recommends to just use DNS64 just to discover the NAT64 prefix, and then do bump-in-the-API synthesis to do the A-to-AAAA NAT64-mapping?
What does this mean for wifi tethering/mobile hotspot?

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 23 Jul 2015 10:41:28 +0200

>modifying A records into AAAA records breaks DNSSEC.

My conclusion is that essentially you have to do 464XLAT if the network
does NAT64.

That way you can have IPv4 literals and you can run unmodified DNS.

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Thu, 23 Jul 2015 10:08:09 +0000

+1

no DNS64 when NAT64+CLAT (464XLAT)
but one domain must be dns64 - "ipv4only.arpa"

BR,
Mcz

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: Thursday, July 23, 2015 10:41 AM
To: [email-masked]
Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC

In your letter dated Thu, 23 Jul 2015 09:13:26 +0200 (CEST) you wrote:
>as far as I know, DNS64 and DNSSEC are fundamentally incompatible, 
>because modifying A records into AAAA records breaks DNSSEC.

My conclusion is that essentially you have to do 464XLAT if the network does NAT64.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jul 2015 06:30:59 -0400

> deployability, since it requires changes in the end hosts."

I think Mikael is asking for a stronger statement than “you could do this, but probably won’t.”

I think this would take the form of a document describing recommendations for DNSSEC-aware stub resolvers, which I don’t think currently exists, and hence could in theory be worked on.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 01:59:32 +1200

> I think this would take the form of a document describing recommendations for DNSSEC-aware stub resolvers, which I don’t think currently exists, and hence could in theory be worked on.

No, afaik it doesn't exist. I'm not certain that it needs to exist, though.
Would it specify anything that isn't already specified?

The code needs to exist.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jul 2015 10:05:40 -0400

> Would it specify anything that isn't already specified?

A document that says how to implement a DNSSEC stub resolver and talks about all the cases you need to handle might be useful, but probably ought to be written as part of an implementation exercise with testing and a list of the applicable use cases (the types of networks you might connect to) to inform it.

> The code needs to exist.

Yes.   However, I am not convinced that it would be obvious to an implementor who hasn’t been through the transition mechanism wars what set of behaviors to implement in order to fully support it.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jul 2015 10:26:06 +0200

Based on the discussion after Stuart's presenation about IPv6 at Apple.

Assuming NAT64 without 464XLAT, assuming we want local DNSSEC validation.

The way to make it work would be 'bump-in-the-api'. 

One way of doing that, the comes it mind is to have the DNS resolver bypass
any DNS64 by setting the CD bit and then after validation, at the request
of the application synthesize AAAA records from A records based on the
NAT64 prefix.

I guess this is easy enough to add to for example getdns
(https://getdnsapi.net/). One question is how an application would find out
that it is running in a DNS64 environment. Another option is for getdns to
do the probing and enable this option automatically.

---

From: Erik Kline <[email-masked]>
Date: Fri, 24 Jul 2015 12:37:05 +0200

> do the probing and enable this option automatically.

One approach comes to ming: when a client resolver starts up, it
checks ipv4only.arpa
(https://tools.ietf.org/html/rfc7050#section-8.2), and after that can
synthesize AAAAs as needed (DNS64 in done in the client) while getting
validated answers for other things as desired.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jul 2015 13:07:54 +0200

>validated answers for other things as desired.

I was wondering whether this should be done by the application or be part of
the library.

If it is documented somewhere as a thing to do for local DNSSEC validating 
libraries then we can treat NAT64/DNS64 as completely transparent to the
application.

But there might be reasons why applications don't want this to happen.

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 24 Jul 2015 16:58:12 +0000

+1

A client that can't synthesize internally, MAY need DNS64 from the network.
So can we frame the problem as: lack of internal synthesis is incompat with DNSSEC?

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Erik Kline
Sent: 24 July 2015 11:37
To: Philip Homburg
Cc: [email-masked]
Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC

> (https://getdnsapi.net/). One question is how an application would 
> find out that it is running in a DNS64 environment. Another option is 
> for getdns to do the probing and enable this option automatically.

One approach comes to ming: when a client resolver starts up, it checks ipv4only.arpa (https://tools.ietf.org/html/rfc7050#section-8.2), and after that can synthesize AAAAs as needed (DNS64 in done in the client) while getting validated answers for other things as desired.

EE Limited

---

From: <[email-masked]>
Date: Tue, 28 Jul 2015 21:58:12 +0200

Hello,

but isn't there a gap that when performing the RFC7050 64pref detection by querying ipv6only.arpa, an attacker can spoof this answer (DNSSEC won't work here, for example, the attacker - when between the client and the DNS - can return for example 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the attacker)) and then attract all IPv4 traffic from the victim?

Nevertheless, an answer to the proliferation of DNSSEC and at the same time increasing usage of DNS64/NAT has to be found, not to stop the success of one or the other.

-- 
Holger Metschulat 
Deutsche Telekom Technik GmbH 
Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt 
+49 6151 58 - 18671 (Tel.) 
+49 160 901 35443 (Mobil) 
E-Mail: [email-masked] 
http://www.telekom.de 
Erleben, was verbindet.  
Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Jul 2015 23:44:51 +0200

In your letter dated Tue, 28 Jul 2015 21:58:12 +0200 you wrote:
> but isn't there a gap that when performing the RFC7050 64pref
> detection by querying ipv6only.arpa, an attacker can spoof this
> answer (DNSSEC won't work here, for example, the attacker - when
> between the client and the DNS - can return for example
> 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the
> attacker)) and then attract all IPv4 traffic from the victim?
> 
> Nevertheless, an answer to the proliferation of DNSSEC and at the
> same time increasing usage of DNS64/NAT has to be found, not to
> stop the success of one or the other.

Yes, that seems to be a very tricky problem.

One option is perform local translation only for 64:ff9b::/96. This would
force operators to use the well known prefix, but it has to advantage that
the prefix can be filtered at the border of each network. And an attacker
will be quite visible trying to get this traffic by manipulating routing
protocols.

A second approach is for the network to signal that there is no IPv4 present.
For example, by not including a default route in DHCPv4 or otherwise signaling
in DHCPv4 that there is no IPv4.

In this case, if there is a valid IPv4 config, the library can refuse to
perform the synthesis. This would leave all dual stack networks unaffected.

Performing the AAAA lookup on ipv4only.arpa over tcp would require
the attacker to be on the path to the resolver.

An alternative to requiring 64:ff9b::/96, would be to insist that the
NAT64 gateway and the DNS64 are in the same /48. That would require an
attacker to spoof DNS resolvers in RAs or DHCPv6, in which case all bets
are off.

Ultimately, this only affects DNSSEC signed IPv4-only targets. The obvious
solution is that if those sites care about security, they should add a AAAA.

---

From: Ca By <[email-masked]>
Date: Tue, 28 Jul 2015 14:49:47 -0700

+1

This is just another way that ipv4 is too broken to use and will not be
fixed.

BCP = use native ipv6

> [email-masked] <javascript:;>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 29 Jul 2015 03:00:01 +0000

> On Jul 23, 2015, at 12:13 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I really care about DNSSEC and I don't want this to be broken for a prolonged amount of time just because people are doing NAT64+DNS64.

Between us girls, I don't think many of us really like NAT64...

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Jul 2015 10:38:45 +0200

>Between us girls, I don't think many of us really like NAT64...

I don't like it either. But there seems to be a vocal group of operators who
like it. Not a lot of opposition and now Apple seems to like it as well.

So the only way forward is to make it work.

---

From: Ondřej Caletka <[email-masked]>
Date: Wed, 29 Jul 2015 12:06:14 +0200

Hello,

> but isn't there a gap that when performing the RFC7050 64pref detection by querying ipv6only.arpa, an attacker can spoof this answer (DNSSEC won't work here, for example, the attacker - when betwee…

That is why there is a requirement in RFC7050 Section 3.1. to validate
network-specific NAT64 prefix using reverse and forward DNSSEC secured
queries. The only problem is that there is no way so far how to seed the
list of trusted NSP domains. Instead of asking users "Do you want to
trust the network prefix dns64.example.org?", there could probably be
some matching with domain name received by other means like DHCP or DNSSL.

Of course, using the Well-known prefix is on the safe side, and should
be IMO used wherever applicable.

Cheers,
Ondřej Caletka

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Jul 2015 12:26:47 +0200

In your letter dated Wed, 29 Jul 2015 12:06:14 +0200 you wrote:
>some matching with domain name received by other means like DHCP or DNSSL=
>=2E
>

It seems to me that Section 3.1 is very far from something can be implemented
in a practical way in a consumer device.

I.e. if a user with a mobile device connects to a random network that employs
NAT64, there is essentially no way for an ordinary user to verify if the
prefix is valid or not.

Now if there would be DHCPv6 and RA options for the prefix, there would be
no need to discover the prefix using the DNS64 resolver and the problem would
reduce to whether to trust DHCPv6 or RA. Which is already part of the
security model (i.e. RA guard can protect users from each other).

---

From: <[email-masked]>
Date: Wed, 29 Jul 2015 12:38:51 +0000

Dear Philip, 

FWIW, another solution is defined here: https://tools.ietf.org/html/rfc7225#section-3.

Cheers,
Med 

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Philip Homburg
> Envoyé : mercredi 29 juillet 2015 12:27
> À : [email-masked]
> Objet : Re: [v6ops] NAT64/DNS64 and DNSSEC
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Jul 2015 15:13:32 +0200

In your letter dated Wed, 29 Jul 2015 12:43:17 +0000 you wrote:
>I forgot to mention that behave WG analyzed the use of DHCP and RA as candi=
>date solutions. See the analysis available at:=20
>
>* RA: https://tools.ietf.org/html/rfc7051#section-5.7=20
>* DHCPv6: https://tools.ietf.org/html/rfc7051#section-5.6=20

Seems like a really poor analysis from a security point of view. 
- DNSSEC is not taken into account
- The existing need for RA security is ignored when introducing another way
  to attack the system.

The idea to piggyback the NAT64 prefix in PCP is nice if PCP is widely 
deployed, but I'm not sure it is widely deployed enough to rely on it.

Note that if a host takes the NAT64 from PCP then all networks have to protect
PCP whether they use it or not.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2015 10:01:35 -0400

> like it. Not a lot of opposition and now Apple seems to like it as well.

I don’t really know what all the hate is for NAT64.   It does a great job of letting me run a v6only network whilst still communicating with v4 services on the Internet.  Maybe it’s not everybody’s cup of tea, but it’s a pretty nice solution, and I agree that making it work with DNSSEC ought to be a priority.

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Wed, 29 Jul 2015 14:10:39 +0000

NAT64 is cool, but DNS64 not.

From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, July 29, 2015 4:02 PM
To: Philip Homburg
Cc: [email-masked]
Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC

On Jul 29, 2015, at 4:38 AM, Philip Homburg <[email-masked]<mailto:[email-masked]>> wrote:
I don't like it either. But there seems to be a vocal group of operators who
like it. Not a lot of opposition and now Apple seems to like it as well.

---

From: Erik Kline <[email-masked]>
Date: Wed, 29 Jul 2015 23:11:30 +0900

On 29 July 2015 at 23:01, Ted Lemon <[email-masked]> wrote:
> I don’t really know what all the hate is for NAT64.   It does a great job of
> letting me run a v6only network whilst still communicating with v4 services
> on the Internet.  Maybe it’s not everybody’s cup of tea, but it’s a pretty
> nice solution, and I agree that making it work with DNSSEC ought to be a
> priority.

The suckiness, such as it is, is a feature, not a bug (vis a vis
Cameron's earlier comment).

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2015 10:12:34 -0400

> NAT64 is cool, but DNS64 not.

Not even DNS64 in the resolver? :)

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Jul 2015 16:52:48 +0200

In your letter dated Wed, 29 Jul 2015 10:01:35 -0400 you wrote:
>    I dont really know what all the hate is for NAT64.   It does a
>    great job of letting me run a v6only network whilst still
>    communicating with v4 services on the Internet.  Maybe its not
>    everybodys cup of tea, but its a pretty nice solution, and I
>    agree that making it work with DNSSEC ought to be a priority.

I guess it depends on your expectations. Right now, for me IPv4 is production
traffic. The moment has not yet come to treat IPv4 as something that may or
may not work.

But there are an endless number of gotchas in IPv4. And at the moment those
gotchas are neatly confined to the IPv4 specific processing.

When IPv4 gets incorporated into IPv6 like NAT64 does, then all IPv6 processing
suddenly also has to take tose gotchas into account, without even knowing
whther the other end was IPv4 or IPv6.

In that sense 464XLAT is better because it again makes the IPv4/IPv6 split.

In any case, I can see why operators like NAT64 so it is better to make it
work.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Jul 2015 17:04:16 +0200

When IPv4 gets incorporated into IPv6 like NAT64 does, then all IPv6 processing
suddenly also has to take those gotchas into account, without even knowing
whther the other end was IPv4 or IPv6.

---

From: Gert Doering <[email-masked]>
Date: Wed, 29 Jul 2015 22:57:56 +0200

Hi,

> Between us girls, I don't think many of us really like NAT64...

I think it's the best thing that happened in quite a long time :-)

So, yes, I like NAT64, when the alternative is "client network with
dual-stack IPv6 + NAT444'ed IPv4".

Dual-stack is an annoyance, dual-stack with NAT44(4) stinks.

gert

-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Jul 2015 16:35:44 +0200