Subject: [BEHAVE] New revision: draft-ietf-behave-nat64-discovery-heuristic-06.txt

From: <[email-masked]>
Date: Mon, 12 Mar 2012 09:51:07 +0000

Hi behave WG,

In the last interim we discussed this draft, and in particular connectivity checks and secure discovery of Pref64::/n. This draft is now attempting to include the ideas and comments given in the interim.

Please check this out and comment - especially on changes.

The plan is to update this according to comments and, hopefully, start WGLC at the next Interim meeting.

Best regards,

        Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext [email-masked]
> Sent: 12. maaliskuuta 2012 11:40
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-
> 06.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Behavior Engineering for Hindrance
> Avoidance Working Group of the IETF.
>
>       Title           : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
>       Author(s)       : Teemu Savolainen
>                           Jouni Korhonen
>                           Dan Wing
>       Filename        : draft-ietf-behave-nat64-discovery-heuristic-06.txt
>       Pages           : 14
>       Date            : 2012-03-12
>
>    This document describes a method for detecting presence of DNS64 and
>    for learning IPv6 prefix used for protocol translation on an access
>    network.  The method depends on existence of a well-known IPv4-only
>    domain name "ipv4only.arpa".  The information learned enables nodes
>    to perform local IPv6 address synthesis and to potentially avoid
>    traversal through NAT64 on dual-stack accesses and multi-interface
>    deployments.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-
> 06.txt
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Mon, 12 Mar 2012 08:15:58 -0600

Hi Teemu and the rest of the authors,

I must be missing something but I can't see how the algorithm in section
3.1.1 is going to be secure. DNSSEC is not going to help here.

Consider the following: 
An attacker with access to inject packets in the path between the node
and the DNS64. The attacker is have the IPv6 network 6666::/48 allocated
to him, is running an evil NAT64 box at 6666::1 where he can listen to
traffic and has registered the domain name example.com. 
1.	Node sends a query for ipv4only.arpa. Attacker injects
6666::1.2.3.4 as the response
2.	Node sends PTR query for 6666::0. This reverse mapping is
delegated to the attacker who is the rightful owner of the IPv6 network
6666::/48. Attacker responds with evilnat64.example.com
3.	Node sends an AAAA query for evilnat64.example.com. This address
is owned by the attacker, he responds with 6666::1 + Signatures for
DNSSEC.
4.	Node performs DNSSEC validation. 
5.	Node starts sending all traffic to the evil NAT64 box!!!

/Stephan Lagerholm

> Behalf Of [email-masked]
> Sent: Monday, March 12, 2012 4:51 AM
> To: [email-masked]
> Subject: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
> 
> Hi behave WG,
> 
> In the last interim we discussed this draft, and in particular
> connectivity checks and secure discovery of Pref64::/n. This draft is
> now attempting to include the ideas and comments given in the interim.
> 
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> heuristic-

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Mon, 12 Mar 2012 08:34:19 -0600

Hi Again,

Section '6. Exit Strategy' relies on NXDOMAIN being sent back to the
client. Note however that a lot of networks are implementing NXDOMAIN
redirect where such response is replaced with a positive response that
is redirecting the client to a portal. Relying on NXDOMAIN being sent
back is not going to be robust. 

Additionally, as I commented earlier, the negative TTL of ipv4only.arpa
will be determined by the parents SOA setting. I don't think the
operator of .arpa is interested in changing this setting when the exit
strategy is implemented since it will affect all negative caching for
the domain.

I suggest that the exit strategy is reworked. Perhaps encode a meaning
in IP address returned by the A record or have a TXT record at
ipv4only.arpa that is either "on" or "off".

/Stephan Lagerholm

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2012 08:09:43 -0700

> Behalf Of Stephan Lagerholm
> Sent: Monday, March 12, 2012 7:16 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
> 

The step missing is that the host needs a list of authorized domain
names.  So, for example, a Comcast subscriber would have comcast.net 
on their list of authorized domain names.  If they take that computer
and visit a Starbucks coffee shop, they would be confronted with a 
domain name other than comcast.net (e.g., "example.com" from your
above attack scenario) -- somewhat akin to what happens, today, with
choosing which of the dozens of SSIDs are "valid" when visiting a
Starbucks.

The need for this pre-configured list of authorized domain names
is certainly not a good aspect of the DNSSEC scheme.  But it is
necessary to prevent the very attack you describe.

-d

> > The plan is to update this according to comments and, hopefully,
> start
> > WGLC at the next Interim meeting.
> >
> > Best regards,
> >
> >         Teemu
> >
> > >       Filename        : draft-ietf-behave-nat64-discovery-
> heuristic-
> > 06.txt
> > >       Pages           : 14
> > >       Date            : 2012-03-12
> > >

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 18:46:25 +0000

Hi Stephan,

Thank you for your comments. I'm thinking about the security comment still.

If the node would have validating resolver, it would not fall into that trap.

Also the node could have this configured off, as said in the end of section 6. Exit strategy.

But... Maybe an address from the 192.0.0.0/24 space could be selected for this "off" indication? (http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml)?

I don't like the TXT record, as it would require additional query.

Best regards,

	Teemu

> From: ext Stephan Lagerholm [mailto:[email-masked]]
> Sent: 12. maaliskuuta 2012 16:34
> To: Savolainen Teemu (Nokia-NRC/Tampere); [email-masked]
> Subject: RE: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
> 
> Hi Again,
> 
> Section '6. Exit Strategy' relies on NXDOMAIN being sent back to the client.
> Note however that a lot of networks are implementing NXDOMAIN redirect
> where such response is replaced with a positive response that is redirecting
> the client to a portal. Relying on NXDOMAIN being sent back is not going to
> be robust.
> 
> Additionally, as I commented earlier, the negative TTL of ipv4only.arpa will
> be determined by the parents SOA setting. I don't think the operator of .arpa
> is interested in changing this setting when the exit strategy is implemented
> since it will affect all negative caching for the domain.
> 
> I suggest that the exit strategy is reworked. Perhaps encode a meaning in IP
> address returned by the A record or have a TXT record at ipv4only.arpa that
> is either "on" or "off".
> 
> /Stephan Lagerholm
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Mar 2012 08:28:57 +1100

> necessary to prevent the very attack you describe.

So basically no security as the method also needs to work at Starbucks.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 21:40:14 +0000

> > The need for this pre-configured list of authorized domain names is
> > certainly not a good aspect of the DNSSEC scheme.  But it is necessary
> > to prevent the very attack you describe.
> 

It does not necessarily. Starbucks may provide dual-stack (native, double translated or tunneled) and be done with the problem.

	Teemu

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 21:43:06 +0000

..and it is always a possibility to have less connectivity in untrusted IPv6-only networks (no connectivity when facing IPv4 literals).

I.e. a device could do this procedure when it trusts the network (to some extent) and not to do elsewhere.

        Teemu

> Behalf Of Savolainen Teemu (Nokia-NRC/Tampere)
> Sent: 12. maaliskuuta 2012 23:40
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> > > certainly not a good aspect of the DNSSEC scheme.  But it is
> It does not necessarily. Starbucks may provide dual-stack (native, double
> translated or tunneled) and be done with the problem.
>
>       Teemu
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Mar 2012 15:08:59 -0700

> From: Mark Andrews [mailto:[email-masked]]
> Sent: Monday, March 12, 2012 2:29 PM
> To: Dan Wing
> Cc: 'Stephan Lagerholm'; [email-masked]; [email-masked]

When visiting Starbucks the user would have to include whatever 
FQDN Starbucks is legitimately using.  How the user determines that
legitimate FQDN (or legitimate SSID) is a problem generally unsolved by 
the industry, unless you have some magic up your sleeve?  Afterall,
if an attacker is in the van outside Starbucks with the SSID "Starbucks 
Coffee" (while the legitimate SSID is "Starbucks", unless it is "AT&T" (who
provides their WiFi in the US), unless it is "tmobile" (who used to
provide their WiFi in the US).  But the attacker would need to cause
the user to add the attacker's domain name to their list of my 
authorized NAT64's.

So, the problem reduces to a currently-unsolved problem.

-d