Subject: Protecting caches?

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Aug 2008 13:08:22 -0400

No hat.

Dear colleagues,

In the discussion around forgery resilience so far, I've seen some
discussion on how to detect cache poisoning attempts, and some
discussion on how to foil the attack itself by reducing the ability of
the attacker to send bad data to a resolver.  (I've also seen the
observation, several times, that DNSSEC will solve these problems
anyway, so we should concentrate on deploying that; that's an
operational problem now, and not on-topic for this list.)  Some of the
proposals floated entail protocol (or maybe near-protocol --
"operational conventions", to borrow Joe Abley's nice phrase) changes,
and so are correctly on-topic for the WG.

What I haven't seen much of is discussion of protecting caches _as
such_.  That is, given that we are going to cache, are there
techniques that solve the dangers of a cache other than just
preventing the cache from ever having the wrong data in the first
place?  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

--
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: Fri, 29 Aug 2008 08:52:07 +0200

> preventing the cache from ever having the wrong data in the first

Here's an idea to contain the damage of a bad record by reducing the
amplification effect (attack one cache, compromise the network view
for thousands of clients):

If information enters the cache for the first time, you only use it a
fixed number of times before fetching it again from the network (say
10).  If the usage count is reached, you fetch the data from the
network (even if the TTL has not yet expired).  If it is still the
same, you double the counter.  If it is different, you fail back to
the initial value.

This will cause additional DNS traffic for those who publish unstable
data.  It is also reasonable to disable it during the cache warm-up
phase, and to keep records past their TTL (to avoid the cold start;
this makes sense for DNSSEC as well, were you often can avoid
cryptographic operations if the freshly fetched RRSIG matches the
stored one).

-- 
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: Paul Hoffman <[email-masked]>
Date: Fri, 29 Aug 2008 12:36:21 -0700

>preventing the cache from ever having the wrong data in the first

What I have not seen, even post-Kaminsky, is a good discussion of 
what we put into a cache. For example, I am still befuddled about why 
part of the Kaminsky attack works. If I have a record in my cache 
with days left on the TTL, why should an attacker be able to change 
that record with bad information when I'm asking about a different 
record? The advantage of this ("we gave too long of a TTL and now 
need to move the IP address quickly") seems to be heavily outweighed 
by the ease of the attack.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Aug 2008 19:55:13 +0000

> by the ease of the attack.

RFC 2181 codified a credibility ranking system which controlled some
aspects of cache replacement.  it's possible that it should have said
more, gone further.  however, it's ultimately desireable that a long
TTL not lock out same-credibility replacement data.  TTL is about 
expiry not replacement.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Aug 2008 13:17:58 -0700

At 7:55 PM +0000 8/29/08, Paul Vixie wrote:
>aspects of cache replacement.

Right.

>it's possible that it should have said
>more, gone further.

Or that it should be reconsidered in the current light. A small 
modification to the text might go a long way. For example, it says:

    Unauthenticated RRs received and cached from the least trustworthy of
    those groupings, that is data from the additional data section, and
    data from the authority section of a non-authoritative answer, should
    not be cached in such a way that they would ever be returned as
    answers to a received query.  They may be returned as additional
    information where appropriate.  Ignoring this would allow the
    trustworthiness of relatively untrustworthy data to be increased
    without cause or excuse.

Adding "or glue from a primary zone" to the list in the first 
sentence would eliminate the effects of the Kaminsky attack, would it 
not?

>however, it's ultimately desireable that a long

That is the crux of the question. It sounds like you disagree with my 
assessment that the disadvantage of this policy (the Kaminsky attack) 
is stronger than the advantage (allowing replacement before expiry, 
even if the replacement is from an attacker).

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Aug 2008 20:26:21 +0000

> Adding "or glue from a primary zone" to the list in the first sentence
> would eliminate the effects of the Kaminsky attack, would it not?

for replacement, but not insertion, yes.

> >however, it's ultimately desireable that a long TTL not lock out
> >same-credibility replacement data.  TTL is about expiry not replacement.
> 
> assessment that the disadvantage of this policy (the Kaminsky attack) is
> stronger than the advantage (allowing replacement before expiry, even if
> the replacement is from an attacker).

i know there are a lot of working configurations which depend on low latency
cache replacement and so have long ttl's.  we'd be breaking these.  i suspect
that there are more such currently working configurations than i know about.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Aug 2008 15:36:00 -0700

>for replacement, but not insertion, yes.

Agree.

>that there are more such currently working configurations than i know about.

Could you (or someone) describe these? What is their reason for a 
long TTL if they know there is going to be a replacement?

--Paul Hoffman, Director
--VPN Consortium

---

From: bert hubert <[email-masked]>
Date: Sat, 30 Aug 2008 21:48:15 +0200

> record? The advantage of this ("we gave too long of a TTL and now 

Most programmers of servers used to act on the assumption that packets (and
by extension, questions) were expensive. An answer carrying 'free' data for
which the resolver considered it authoritative was more than welcome in this
respect.

Plus the oft quoted credibility rules of course.

I'm moving to having a switch that lets data with an unexpired TTL not be
overwritten by newer answers.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services