Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt]

From: <[email-masked]>
Date: Mon, 30 Jan 2012 21:40:53 +0000

For attacker to use own Pref64::/n the attacker would need to be able to sign the required DNS records in a way that validating host accepts them. In that case the attacker would appear to be as legitimate as any ISP.

I'm wondering if the attack I described is actually something we need to address? I mean if the attacker controls DNS(64) a host is using and routing on the access network the host is attached to, the attacker can cause problems anyway (including to the traffic using non-synthetic addresses).

If we agree we do not adress this attack, we could drop the split DNS text.

Teemu

----- Original message -----
> Hi Teemu,
>
> > > >
> > > > I don't like this requirement because it is forcing the DNS server
> > to support views. Additionally, you will have to update the
> > authoritative DNS every time you start provisioning your clients with
> new
> > addresses from new IPv6 networks.
> > >
> > > Fair point.  Teemu, Jouni, thoughts on this?
> >
> > The text was attempting to tackle the following attack:
> > - Legitimate network A is using NAT64 and related domain names are all
> > secured with DNSSEC
> > - Host is in hostile network B, where attacker has control over local
> > DNS64, NAT64 and routing services
> > - Host performs AAAA query for the well-known name, which is replied
> by
> > attacker's DNS64 using network A's Pref64::/n
> > - Host performs reverse query to find the FQDN for the prefix, and
> > find's network A's NAT64's FQDN (attacker not involved in this query)
> > - Host performs forward query for the learned name, validates response
> > with DNSSEC, and gets the same Pref64::/n as it got originally for the
> > well-known name (attacker not involved in this query)
> > - Host thinks it has learned Pref64::/n safely
> >
> > Except that the host has not, because even though the discovered
> > Pref64::/n was matching the NAT64 FQDN and all that just fine, the
> host
> > is in a network B that should not be using the network A's Pref64::/n
> > and hence all host's packets could be routed to network B's NAT64
> under
> > control of attacker (instead of NAT64 of network A - remember attacker
> > has taken over routing to Pref64::/n).
>
> Is sounds very easy to circumvent the security in the proposed discovery
> algorithm in that case.
> Why would the attacker use A's Pref64::/n why couldn't he just use his
> own Perf64::/n and insert the appropriate records into DNS?
>
> /Stephan
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jan 2012 15:01:09 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, January 30, 2012 1:41 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: DNSSEC and NAT64 Discovery Heuristic [was RE: [BEHAVE] I-D
> Action: draft-ietf-behave-nat64-discovery-heuristic-05.txt]
> 
> For attacker to use own Pref64::/n the attacker would need to be able
> to sign the required DNS records in a way that validating host accepts
> them. In that case the attacker would appear to be as legitimate as any
> ISP.
> 
> I'm wondering if the attack I described is actually something we need
> to address? I mean if the attacker controls DNS(64) a host is using and
> routing on the access network the host is attached to, the attacker can
> cause problems anyway (including to the traffic using non-synthetic
> addresses).

That attack (manipulation of DNS) is prevented by host DNSSEC.  

> If we agree we do not adress this attack, we could drop the split DNS

-d