Subject: Some musings on forgery resilience

From: Otmar Lendl <[email-masked]>
Date: Tue, 22 Apr 2008 11:37:59 +0200

Having been treated to another iteration of "we need to deploy DNSSEC,
otherwise the DNS will fall apart due to rampant forgeries" talk
recently, I started to think what other options resolvers have to
protect themselves. Bert's draft is good, but one angle is missing.

Is it possible to implement a successful forgery attack without the
target noticing that anything is wrong?

Most scenarios assume that the attacker sends a burst of forged replies
to the recursor in the hope of hitting the right query-ID before the
real answer arrives.

draft-ietf-dnsext-forgery-resilience-03 only contains:

   Note that the attacks mentioned above can be detected by watchful
   server operators - an unexpected incoming stream of 4.5mbit/s of
   packets might be noticed.

IMHO we have more clues than that: even with a successful attack a lot
of answers with mis-matched ID will arrive (and be ignored) before the
forgery actually succeeds.  This spike in ID mismatches towards a query
should tell the recursor that something fishy is going on.

A quick look at the bind sources seems to indicate that bind simply
ignores such packets. (9.4.2, lib/dns/dispatch.c, around line 634)

I haven't checked yet how many such ID mismatches happen during normal
recursor operations, but an attack should be really visible in these
statistics. By looking at the query string in these packets, the
recursor can determine exactly which specific FQDN is under attack.

If this works, then the 99.999% percent of normal DNS lookups which are
not targetted by a forgery attack can continue without modification. The
only question now is: what can a resolver do if he has a clear suspicion
that he is the target of a DNS forgery attack concerning a specific query?

Two simple ideas come to my mind

* Redo the query a few times, preferably utilizing all authoritative servers.

  This does wonders to the probabilities, but assumes that multiple
  queries do indeed result in the same answer. That might be a tad
  optimistic in the age of global load-balancing Akamai-style.

* Switch to TCP

  Yes, there is a performance penalty associated with that, but as this
  switch only affects the targetted domain and not all others, this
  sounds very reasonable.

  A fallback to TCP is already implemented in the recursor code
  (triggered by the TC bit in a reply), so this should be rather
  easy to add.

What did I miss?

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 22 Apr 2008 12:07:30 +0200

On Tue, Apr 22, 2008 at 11:37:59AM +0200,
 Otmar Lendl <[email-masked]> wrote 
 a message of 67 lines which said:

> what can a resolver do if he has a clear suspicion that he is the
> target of a DNS forgery attack concerning a specific query?

Ring the alarm, beep, send SNMP traps, syslog, etc.

The sysadmin must know what is going on.

---

From: Jim Reid <[email-masked]>
Date: Tue, 22 Apr 2008 11:29:59 +0100

> target noticing that anything is wrong?

Yes. In fact that's the definition of a successful forgery attack. :-)

> * Redo the query a few times, preferably utilizing all  

Probably a bad idea, even if the extra traffic is tolerable. It  
barely raises the bar because the attacker now has to spoof DNS  
traffic between N servers and the victim rather than one. The bad guy  
can use the same tools to interfere with N data streams as they use  
for just one. And we all know that computers are very good at doing  
the same thing over and over and over again. :-) The next step down  
that slippery slope would likely be the use of fast-flux techniques  
for "good" DNS zones as well as "bad" ones. Then there's the slight  
possibility of the authoritative servers giving different answers:  
say because the N queries go out while a zone transfer is in  
progress. How could the victim name server tell the difference  
between a spoofed packet and one that's genuine but slightly out of  
date?

> * Switch to TCP

This is even worse IMO. Aside from the OS hassles of keeping track of  
zillions of short-lived TCP connections, it's possible to spoof TCP  
connections. In fact, it's not that much harder than spoofing UDP  
traffic if the bad guy can see the TCP packets go by. And it opens  
new attack vectors too. Instead of tampering with data in the TCP  
stream, just inject a few bogus RST packets and watch the connections  
terminate. Or how about killing the victim resolver by forcing it to  
make lots of TCP connections to lots of servers that ignore SYN packets?

BTW, this discussion probably belongs on the dnsop list...

---

From: Alex Bligh <[email-masked]>
Date: Tue, 22 Apr 2008 11:32:40 +0100

> The sysadmin must know what is going on.

This is susceptible to false positives. If I was attempting to attack
a well known resolver, I might organise my botnet to send a stream of
dysfunctional false replies to the resolver in question months ahead
of the attack. I suggest the sysadmin would have no way to distinguish
this from a real attack, and hence would either switch off the alarm
system or at best be unable to know which of the many thousands of
alerts was a real attack.

Alex

---

From: bert hubert <[email-masked]>
Date: Tue, 22 Apr 2008 13:11:45 +0200

> protect themselves. Bert's draft is good, but one angle is missing.
(..) 
> * Redo the query a few times, preferably utilizing all authoritative servers.

You are very right in that the draft only describes the problem, and part of
the solution. This is not by accident - resolvers will probably start an
arms race with spoofers soon, since the stakes are so high. 

A well positioned spoofer can redirect the . servers - it is not about
single domains!

However, this arms race will be dynamic. It would not be good to restrict
this trajectory too much from an RFC.

Hence my concious choice to describe only an important part of the solution,
and leave the rest up to implementors.

	Bert

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Apr 2008 14:09:00 +0000

> The sysadmin must know what is going on.

in addition to the false positives inherent in such a design, and without
meaning to disagree that this RFC ought to be descriptive rather than
prescriptive due to the coming arms race, i want to point out that any
mechanism that gives an attacker control over one's total work load, where
traffic toward innocent third parties will be amplified at an attacker's
whim, is by definition a DoS vector.  and then there's all the noise in
one's syslog files, making them unreadable other than by daily cron jobs.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 22 Apr 2008 10:52:58 -0400

Paul Vixie wrote:
> whim, is by definition a DoS vector.

Indeed. And it's important to remember that i/o performance to log files 
is orders of magnitude
slower than i/o to network, in general.

It's even worse if logging destinations include console(s), since writes 
can/will block on i/o, and
thus rate-limit performance toward the floor. 19200 bps is *not* your 
friend.

Having an alarm concerning the existence of forgeries is reasonable; 
having any details or state
captured/reported is the path to an arms race.

Flags scale extremely well. :-)

Brian

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 22 Apr 2008 17:39:21 +0200

> Yes. In fact that's the definition of a successful forgery attack. :-)

Well, we seem to be talking about two different scenarios.

The attacks that draft-ietf-dnsext-forgery-resilience-03 talks about
are not about the attacker being able to intercept the query and
crafting a single malicious forgery, but about sending a stream
of forged packets with the hope of hitting the right port/source-IP/
query-ID combination at the right time to get the target to accept
the message as genuine.

"Success" in that case means that the cache is poisoned and that
the resolver returns the wrong answer to his clients.

"Noticing that something is wrong" can be orthogonal to the
success of the attack: if my counter of unmatched replies spikes
I know I'm under attack but I don't know whether that attack was
successful.

> for just one. 

See above. The attack scenario only has a 1 in $BIGNUM chance of
success. If I require 3 identical answers, that probability changes
to 1 / $BIGNUM ^ 3, which is a big difference.

> BTW, this discussion probably belongs on the dnsop list...

As draft-ietf-dnsext-forgery-resilience-03 is a dnsext document,
I posted here ...

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: Alex Bligh <[email-masked]>
Date: Tue, 22 Apr 2008 16:40:34 +0100

> Flags scale extremely well. :-)

In this case they can probably be optimised to:
  return 1;

:-)

Alex

---

From: Alex Bligh <[email-masked]>
Date: Tue, 22 Apr 2008 17:12:22 +0100

> I know I'm under attack but I don't know whether that attack was

I'm probably being very stupid here, but if the resolver could
detect that a successful attack had taken place (i.e. the
cache was poisoned), could it not have detected the packet
as a forgery at the time? IE if the resolver could detect
a successful attack of variant X, then by definition one
could code against attacks of variant X being successful.

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Apr 2008 09:00:11 +0200

On Tue, Apr 22, 2008 at 05:12:22PM +0100,
 Alex Bligh <[email-masked]> wrote 
 a message of 25 lines which said:

> if the resolver could detect that a successful attack had taken
> place

Nobody claimed it was possible. Otmar suggested to detect the attack
*before* it is successful, by looking at the numerous *attempts*,
which, unavoidably, will come before the success. (They seem currently
ignored by the resolvers.)

---

From: Alex Bligh <[email-masked]>
Date: Wed, 23 Apr 2008 08:35:32 +0100

> ignored by the resolvers.)

Yep - wires crossed. Here's what I wrote off-list to Otmar last night
(with apologies for the late-night anthropomorphism):

It might be possible to heuristically detect patterns. For instance,
it's possible to detect multiple A record answers for www.paypal.com
that WERE discarded. That might make a clever resolver think
"hang on, I've had 1,000 of these in the past minute that had
non-matching tuples etc, and now I've got one that matched; I shall
go look up www.paypal.com through a separate recursive resolver
elsewhere (on the basis that is unlikely to be being attacked too)
and use its answer in preference / compare answers / whatever".

Clearly it's not as simple as that as there are possibly multiple
valid answers (so 2 valid answers might differ) and one needs
to avoid turning this into a DoS vector. But a mechanism of
retrospectively detecting the possibility of a forgery based
upon a lot of prior *un*successful attempts could I suppose
be a possibility.

Alex