Subject: [BEHAVE] DNS64 validation

From: Simon Perreault <[email-masked]>
Date: Wed, 29 Jul 2009 14:03:22 +0200

Hello,

In section 5.5, item 2, it says that a DNS64 sets the AD bit in its
response if the A answer it received from upstream validates. It does
not need to validate the negative AAAA answer.

Is this intentional? If so, why is this OK?

Thanks,
Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Jul 2009 12:38:27 -0400

> Is this intentional? If so, why is this OK?

No, it's just an oversight.  Thanks for the observation.  I'll fix it
in a subsequent draft.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Jul 2009 08:52:38 +0200

> > response if the A answer it received from upstream 
> > validates. It does not need to validate the negative AAAA answer.
> > 

I guess you would have the DNS64 return an error if the negative 
AAAA doesn't validate.  That seems it would create a new denial of
service vector.  Afterall, the host behind the DNS64 is likely
IPv6-only, thus it won't submit a subsequent query for an A record
(in the hope the A record would validate).

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Jul 2009 09:13:44 +0200

> (in the hope the A record would validate).

I've been reading this over and over, but I can't figure out how this
could be exploited to form a DoS attack. Could you please explain further?

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Jul 2009 09:47:51 +0200

> could be exploited to form a DoS attack. Could you please 

I am assuming there is a way for an attacker to cause a negative AAAA 
response to be received by the DNS64.  If we have the DNS64 return an 
error (to the DNS client) when the negative AAAA doesn't validate, the 
IPv6-only host cannot establish a connection to the server.

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Jul 2009 10:20:16 +0200

> IPv6-only host cannot establish a connection to the server.

How is this different from sending an invalid A response?

How is this different from regular DNSSEC in general? In particular, see
RFC4035 section 4.7 for ways to mitigate this DoS. See also the
following quote from RFC4033 section 12:

"DNSSEC does not protect against denial of service attacks."

DISCLAIMER: I'm not sure I'm right. I'm just asking questions.

Simon

---

From: Dave Thaler <[email-masked]>
Date: Thu, 30 Jul 2009 08:36:58 +0000

> DISCLAIMER: I'm not sure I'm right. I'm just asking questions.

I think you're right it's no different from the attacker causing a
bad A response to be received.  RFC 4035 section 5.5 states:

   5.5.  Resolver Behavior When Signatures Do Not Validate

   If for whatever reason none of the RRSIGs can be validated, the
   response SHOULD be considered BAD.  If the validation was being done
   to service a recursive query, the name server MUST return RCODE 2 to
   the originating client.  However, it MUST return the full response if
   and only if the original query had the CD bit set.  Also see Section
   4.7 on caching responses that do not validate.

So if you can beat the valid response, you can cause the DNS64 to get
an invalid response (positive or negative) before the real response
gets there, it will return a failure.  The same techniques used
to mitigate the Kaminsky bug (source port and nonce randomization)
help mitigate the same DoS attack Dan mentions because the invalid
response will be ignored if they don't match, rather than triggering
the logic from RFC 4035 section 5.5 quoted above.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Jul 2009 10:37:55 +0200

> DISCLAIMER: I'm not sure I'm right. I'm just asking questions.

I don't know.  What is gained by validating a negative AAAA,
other than exercising DNSSEC?

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Jul 2009 10:52:54 +0200

Dan Wing wrote:
> What is gained by validating a negative AAAA,

Hmmmm... The only attack vector I see is directing additional domains to
the NAT64 box in the hope of causing a DoS. Not a big deal.

How about making this a SHOULD instead of a MUST?

Simon

---

From: Dave Thaler <[email-masked]>
Date: Thu, 30 Jul 2009 08:54:07 +0000

I'd prefer the requirement level be the same as for validating
the A record.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Thursday, July 30, 2009 10:53 AM
> To: Dan Wing
> Cc: 'Andrew Sullivan'; [email-masked]
> Subject: Re: [BEHAVE] DNS64 validation
>
> Dan Wing wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Jul 2009 10:55:54 +0200

> Hmmmm... The only attack vector I see is directing additional 
> domains to the NAT64 box in the hope of causing a DoS. 

Me, too.

> Not a big deal.

Still harmful (as there is will be port limits on stateful NAT64 boxes), but I
agree it isn't a huge deal.

> How about making this a SHOULD instead of a MUST?

Works for me.  Dave's suggestion that we remind DNS64 implementors of source
port randomization is useful, too.

-d

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jul 2009 19:12:56 +1000

> other than exercising DNSSEC?

You don't want to send IPv6 connections through the translator
unless you have to.  If there are real AAAA records they need to
be returned in response to the DNS64 client.

DNSSEC is designed to prevent bad data getting through.

Validating resolvers don't usually throw up their hand on the first
validation error.  They re-try assuming that they are under attack.
There is however a limit to the amount of work they will do when
re-trying.

I'm amazed at the amount of mis-information that gets thrown around
about DNSSEC.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Jul 2009 11:19:26 +0200

> I'm amazed at the amount of mis-information that gets thrown around

I, for one, am glad you're here to correct it.

Thanks,
Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 30 Jul 2009 05:24:06 -0400

> other than exercising DNSSEC?

If we don't validate the negative answer before validating the
subsequent A record, then we aren't really validating the conditions
that cause us to synthesize.  The synthesis is supposed to be invoked
just in case there's no AAAA.  In a signed zone, then, you should
validate the negative answer, then query for the A and validate that
positive answer.  Only then should you synthesize, prune the original
A record from the answer, and synthesize the AAAA.

The reason this is important is because otherwise there could be AAAA
actually in the zone at that RNAME, but an attacker somehow manages to
send the (negative) answer back instead.  In such a case, when we
synthesize the AAAA we are not only telling white lies: we're actually
substituting new data for what should be signed and validated data.
Moreover, we're failing to detect an attack whereby native v6 is being
deprecated in favour of synthesis and NAT64, which is probably bad.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Jul 2009 11:25:28 +0200

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 30, 2009 11:13 AM
> To: Dan Wing
> Cc: 'Simon Perreault'; 'Andrew Sullivan'; [email-masked]

Please continue to help; that is why Andrew Sullivan said, in DNSEXT, that
BEHAVE needs help with DNS.  

We're nat stupid, though.  :-)

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Jul 2009 13:23:31 +0200

> deprecated in favour of synthesis and NAT64, which is probably bad.

Thanks.

-d

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 30 Jul 2009 11:23:05 -0400

> We're nat stupid, though.  :-)

I hope it didn't sound like the latter was what I was saying!  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.