Subject: resolver side mitigation

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 25 Aug 2008 13:41:40 +0200

Hi,

I've submitted a draft with the resolver side mitigations that I
envision for Unbound.

http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt

Best regards,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 Aug 2008 16:23:36 +0200

> http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt

I think RTT banding with 200 ms does not work that well if the
attacker is less than 200 ms away from the resolver which is attacked:
Suppose that NS1 has got a RTT of 20 ms, and NS2 one of 220 ms, and
the attacker is very close to the resolver (negligible RTT).  The
attacker sends a query to the resolver, initially spoofing responses
from both resolvers.  If no answer is received within 20 ms, it
concentrates spoofing on the other resolver.  As a result, the
necessary attack bandwidth has been reduced, leading to a better
attack.

In the end, the question whether RTT banding is useful boils down to
how we measure attack costs.  Without proper cost metrics, it's hard
to tell if a countermeasure is a real improvement (and how it
interacts with other resolver features like lameness caches).

Section 3.3 could mention that these techniques stop query mining
attacks on DNSSEC (because an off-path attacker cannot proxy DNSSEC
traffic anymore).  The downside is that when you detect a failure
(even if it's just a timeout), you need to back up, maybe even back to
the root, in order to get a fresh version of the data you've just
invalidated.  (I don't think this should be a priority item, though.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 26 Aug 2008 16:41:49 +0200

> interacts with other resolver features like lameness caches).

Well, time to infection. Or is bandwidth better?
If the attacker does not determine what nameserver is being used, 2x in
the case above.  If smart, like you describe, about 1.1x (1/10 of the
time it has to use double bandwidth).  If the resolver sticks to the
fastest nameserver: 1x.

> invalidated.  (I don't think this should be a priority item, though.)

I do not understand what you mean with query mining.

If the NS or nameserver address query fails, simply give up on it.  Do
not back up to higher servers.  When the next query for this bailiwick
comes along, you'll get to the same spot again, and try again.

Best regards,
   Wouter

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 Aug 2008 16:51:13 +0200

> Well, time to infection. Or is bandwidth better?

Or packet count?  Or traffic volume?  It's not an easy answer, and
there are certainly lots of different trade-offs.

> I do not understand what you mean with query mining.

Spoofing the delegation while returning correct data, to get an
insight into which DNS data the victim is interested in.

> comes along, you'll get to the same spot again, and try again.

But this doesn't deal with the situation that you keep querying the
wrong name server set, does it?

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 26 Aug 2008 08:01:11 -0700

> interacts with other resolver features like lameness caches).

Actually, I think it does up the attacker work, just not by a full bit.

During the first 20ms, the attacker is sending as if from the "close"  
resolver, and then during the remaining 200ms of an epoc, from the  
"far" resolver..

If the attacker DOES have the feedback loop to know if there is  
immediate success and is "local" (0ms latency) and observing when the  
response comes back to determine that an attempt has failed.

If the resolver chose the "close" one, for the entire 20ms, none of  
the traffic is wasted. (no entropy gain), because the attacker starts  
a new race as soon as he observes the first one having failed.

If the resolver chose the "far" one, for the first 20ms, all the  
traffic is wasted, and for the remaining 200ms, the traffic is fully  
effective, which is still a gain in entropy but a far lower gain. (a  
less than 1b entropy gain, but still some gain).

If the attacker does NOT have the feedback loop, then it is a big gain  
in entropy:

If the resolver chose the "close" one, 200ms out of 220ms is wasted
If the resolver chose the "far" one, 20ms out of 220ms is wasted.

Thus I think if the attacker doesn't have the feedback loop, you still  
get a 1b gain in entropy (but not positive).

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 26 Aug 2008 09:01:21 -0700

> there are certainly lots of different trade-offs.

Packet counts == traffic volume to rough approximation.

And mitigations have different factors.

Entropy defenses is all about increasing the packet count required:  
making the probability of a win per packet being lower.

If there are cases, however, where an attacker can "run until win",  
entropy defenses don't affect time, but time*bandwidth product.  If  
you add one bit to the entropy, you either double the time the  
attacker needs or double the bandwidth required.

Cache policy is all about increasing the time required:  If there are  
no "run until win" cases, the packet count for an attack is not  
increased, but because of the attacker's inability to run multiple  
races for the same name within a single TTL, the number of races which  
can be run per unit time goes down, and with even short TTLs being  
60s, by a large amount.

Although its still a time*bandwidth problem, if the attacker doubles  
his bandwidth, the probability of winning any given race goes up, so  
fewer races need to be run to win, but time ends up dominating if the  
authority increases the TTL to 60 minutes.  Thus TTL is ONLY relevant  
as a defense if you can eliminate ALL "run until win" cases.

So my personal belief is "Packets, Time, and Time*Bandwidth" are all  
important criteria, and different defenses affect different portions,  
and we should be precise about which defenses affect which aspects of  
an attack.

> wrong name server set, does it?

If you ALSO validate this when you put it in the cache for the first  
time, as well as anytime it changes, it should actually keep the wrong  
nameserver set from getting into the cache in the first place.

Basically, it works as follows.

If the attacker is doing a blind attack against the NS RRset set  
because its not yet in the cache, thats a "Run once every TTL" attack  
(conventional blind attack), which requires a LOT of time given the  
normal TTL on the NS RRset.

If instead, the attacker is doing a kaminski attack against the NS  
RRset, where he's taking advantage of trying to get the resolver to  
accept a change to the existing NS RRset, now the attacker doesn't  
have to win one race, he has to win two back-to-back races: one to  
make the resolver believe that the NS RRset has changed, which is  
immediately followed by a race where the resolver looks up the NS  
RRset again to see what the new value should be.

Yet at the same time, such a policy allows the NS RRset to  
legitimately change.

This is an example by what I mean about glue policy affecting the "run  
until win" property of a race:  With the policy of validating the NS  
RRset separately, you've changed the conditions from "Run until Win"  
to either "Run once every TTL" or "Run until win two races in a row"  
for attacks on the NS RRset: an exponentially harder problem.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Aug 2008 17:04:15 +0200

On Mon, Aug 25, 2008 at 01:41:40PM +0200,
 W.C.A. Wijngaards <[email-masked]> wrote 

>   o  source address randomisation
>
>      If the resolver has multiple public IP addresses these can be used
>      to randomise with.

With IPv4, this would add only one or two bits of entropy.

But, with IPv6, there is a huge potential for randomisation, may be 64
bits of entropy if the resolver has a full /64.

However, it has implications for the router's Neighbor Discovery
cache. Did anyone tried aggressive source address randomisation with
IPv6 to see until where the router and/or server OS can go?

> Specifically, they must not put the costs of the solution with 3rd
> parties.  

That's a noble goal but it is impossible to follow completely. For
instance:

>   o  Authority queries for nameserver addresses, A and AAAA.
>
>      Same idea, like NS query above.  You ask for A or AAAA records
>      directly at the authoritative server.  

This would increase the load of the authoritative servers and
therefore would put a part of the cost (an acceptable one, IMHO) on
third parties.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Aug 2008 08:46:19 -0700

> therefore would put a part of the cost (an acceptable one, IMHO) on

I've been looking at this myself, from a trace based viewpoint.

Some preliminary suggestion on the traces I have is that the MOST  
paranoid AND agressive policy (which I believe ends up being roughly  
equivelent to the new policy for Unbound):

+ Do not accept ANY data into the cache that was not a direct answer.

+ Deliberately fetch all data that wasn't a direct answer and isn't  
already in the cache independently to place in the cache.

Thus, eg, for the NS RRSet, it generates both a separate fetch for the  
NS RRSet, and a fetch for each name in that RRSet.

This policy increases the number of queries outbound from the  
resolvers by about 70-90%, so its less than double.

It would not increase the latency of queries however, except in the  
case of CNAME chains, assuming you are still able to use the glue  
records in the local context of an individual query.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Aug 2008 10:29:46 -0700

At Thu, 28 Aug 2008 17:04:15 +0200,

> IPv6 to see until where the router and/or server OS can go?

I've not played with this idea yet, but if I were to do it, I would
reserve a separate /64 for the server machine, assign any addresses
under that prefix on some "loopback" interface (with disabling DAD),
and let the server announce the prefix for neighboring routers (and
have them accept the route).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.