Subject: Re: [dnsext] Re: DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01

From: Alfred Hönes <[email-masked]>
Date: Thu, 22 Jan 2009 21:33:50 +0100 (MEZ)

thanks for your concise analysis of the problem space.

At Thu, 22 Jan 2009 11:35:48 -0500, Ralph Droms <[email-masked]> wrote:

> ...
[[ cutting off most parts of the original message ]]
>
> Note that all of this discussion is aimed at solving the proxy problem
> by avoiding proxies.  I don't know if that goal is in scope of this
> draft.  Another solution, of course, would be to put a real recursive
> resolver in the BGW, which might have other advantages for DNSSEC.

+1

I fully support the idea to call for replacing these proxies by
state-of-the-art recursive resolvers, but this will perhaps not
very quickly result in the actual substitution of these DNS proxies;
Thus, the draft under consideration will still be useful for a while.

One of the reasons for this step ahead not mentioned yet in this
thread would be reducing the global attack surface of the DNS.

The remainder of this note aims at detailing this aspect to a
certain degree.  (There are many more facets and technical details
to consider, but I try to keep this note compact.)

The establishment of ISP (or 3rd-party) supplied centralized
resolvers was and is appropriate in support of a moderate number
of customers with slow modem or ISDN access links, which gain access
acceleration and bandwidth savings from that environment.

Now, the same setting is rather thoughtlessly also used for
broadband access scenarios, in which typical customers have much
higher data volumes and accordingly higher DNS request rates.

The DNS architecture had never promoted this centralized resolver
approach; if always modeled a site-local caching resolver.

The increased number of users of these centralized, ISP controlled
DNS resolvers, and the super-proportionally increasing query rate
served by these resolvers, are the most important factors that have
made these systems attractive targets for all kind of attacks on
the DNS system, in particular:
  a)  spoofing attacks,
  b)  insider attacks.

Unfortunatly, a) attracts much attention although the threat still
rarely is significant for day-to-day Internet usage of many users,
whereas b), almost never surfaced in security discussions, reportedly
affects a significant and rapidly increasing percentage of Internet
users, which already are subject to such attacks regularly.

Regarding a):
  A successful cache poisoning attack against a central resolver
  is regarded as interesting and efficient from an attacker's pov
  because it might affect thousands to millions of users at once.
  Replacing a cluster of central resolvers serving, say 1 million
  broadband access customers, by 1 million independent resolvers
  in the 1 million broadband access routers of these customers
  would completely re-deal the card-deck of potential attackers!
  There's no more central place to place the Jokers!
  Because most broadband access routers get temporary IP address
  leases via DHCP or some flavor of PPP, an attacker would have
  to attack the whole IP address range used by the ISP for that
  purpose, independent of which IP addresses are currently in use,
  and he would normally not be able to detect the identity of
  most IP address holders.  Both factors would even more reduce
  the probability for success of an attacker using comparable
  resources as it would currently use to attack a central resolver.

Regarding b)
  Note well, from a DNS integrity and consistency point of view,
  many emerging "popular" setups pretending to "take care of the
  customers' best interest" by filtering DNS data or inserting non-
  authoritative data (be it for moral, political or business reasons)
  are indistinguishable from plaintiff man-in-the-middle attacks.
  Even without DNSSEC, these attacks would become much more difficult
  and less effective at large in the 'distributed resolver' scenario.
  With a slow adaption of DNSSEC expected for many parts of the DNS,
  but hopefully good progress in significant parts (Root zone,
  important TLDs and registry-/TLD-like 2nd-level domain zones,
  bringing the DNSSEC 'security edge' to the CPE would be a huge
  progress.
  Verifying centralized resolvers would require huge additional
  computing resources and make users even more dependent on security
  policies they can not control.
  On the other hand, fully distributing DNSSEC aware resolvers to the
  customer edge (BB access routers) would distribute the computing
  load and admit customers to have influence on the DNSSEC security
  policy applied at their edge devices, without having to run
  verifying resolvers on their individual end systems.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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