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

> -----Original Message-----
> From: teemu.savolainen@... [mailto:teemu.savolainen@...]
> Sent: Monday, January 30, 2012 1:41 PM
> To: stephan.lagerholm@...; dwing@...
> Cc: behave@...
> 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).

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