Wouldn't a behavior like this be able to be used to bring name servers
down by simply killing CPU time?
Yes, and it's easier than killing CPU time; there's a targetted attack
wherein I can pick a resource record and continuously throw forged
responses for it, with bad query IDs, at a nameserver - that server is now
unable to resolve requests for that record.
And, of course, this ties in nicely with other unfixed servers, since,
right now, any problem that allows me to prevent a BIND server from
responding to queries will allow me to spoof anything it's authoritative
for.
Attack detection is a tool, not an answer. I'm curious as to why it hasn't
been discussed further; it's certainly not MY idea, and it's certainly
been talked about on other forums.
There are other tools available as well. I suppose the point (right now)
is that there are things that can be done to strengthen the current DNS
protocol (as well as it's implementations) that won't break naieve servers
and will make attacks far harder, even in the absence of DNSSEC.
What do you think the timeline is on global deployment of DNSSEC? It's
surprising to me that people aren't more concerned, in light of the fact
that you've just been told flat out, by myself as well as by Mr. Vixie,
that there are exploitable problems that can't be entirely fixed until the
entire protocol is modified.
I suppose the operations context to this is, "hey, you realize DNS is
COMPLETELY BROKEN? What are your plans for dealing with the possibility
of someone posting exploits?" Do we simply stop using DNS?
The same could be said of IP. If you forge packets and ICMP or UDP attack
someone, as long as your packets cross a busy enough NAP (say one of the
MAE's) you can do it with impunity and effectively knock entire ISP's off
the internet.
"And how do I configure my router for that?" Use access-lists to prevent
your networks from accepting spoofed packets from your customers, or
insist that they use such filters on their routers.
This is not a valid answer. People who think that the entire Internet can
be globally configured to prevent packet forgery from occurring in tone he
first place are deluding themselves, and I think we, as Internet
professionals with an understanding of how these protocols work,
understand that.
Unfortunately, a bizarre faction of people have decided that the best way
to address problems that are made difficult to repair by the design of
legacy software is to deny that they A.) exist or B.) are fixeable.
"Wait for IPsec" and "Wait for DNSsec" are, in my opinion, inadequate
answers. "Prevent packet forgery from happening" seems ludicrous.
Thomas, you seem to have a misconception about the audience you are
addressing here. The people on this list are network operators. We operate
backbone networks with national or international scope. We operate regional
networks. And we operate networks in large organizations such as
universities. We are not protocol designers and we are not programmers.
Some of us are indeed capable of both protocol design and programming but
that is not the hat we wear in this group. Here we are concerned with the
nuts and bolts of keeping IP packets flowing through are networks and
through the gateways we maintain with other networks using tools such as
routers and switches. Since we are operators, we mainly concern ourselves
with things that we can implement in the field in fullscale production
networks right now. If we have any horizon into the future it is short,
perhaps 6 months at the most. If a topic does not concern equipment or
configurations that we can use withing 4-6 months, there is no point in
discussing it here. If we were really interested in that sort of thing we
would join the appropriate IETF working group or read it in USENET.
So, rather than discuss what attacks people *COULD* mount on our networks
and how they would build exploit tools to mount these attacks, if you would
explain the things that we could do to protect ourselves from these attacks
or to track down these attacks then we would be more receptive I think. In
fact, I think that the discussion to dat regarding possible DNS attacks has
led us all down the wrong path. If this sort of attack did occur there is
not much that a network operator can do to harden themselves against it.
However there is probably a *LOT* that could be done to track down the
source of the attacks so that the FBI, RCMP, Interpol, etc. can solve the
real problem.
I certainly am not denying that problems exist but whenever someone claims
to have the real solution to a problem I always ask myself wFrom owner-nanog@merit.edu Sat Aug 2 23:52:45 1997
Received: from merit.edu (merit.edu [198.108.1.42])
by nic.merit.edu (8.8.4/8.8.5) with ESMTP id XAA29758
for <hyper_nanog@nic.merit.net>; Sat, 2 Aug 1997 23:52:44 -0400 (EDT)
Received: from localhost (daemon@localhost)
by merit.edu (8.8.6/8.8.5) with SMTP id PAA05845;
Fri, 1 Aug 1997 15:07:12 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 1 Aug 1997 15:01:36 -0400
Received: (from majordom@localhost)
by merit.edu (8.8.6/8.8.5) id PAA05685
for nanog-outgoing; Fri, 1 Aug 1997 15:01:35 -0400 (EDT)
Received: from lovefm.cisco.com (lovefm.cisco.com [171.68.228.35])
by merit.edu (8.8.6/8.8.5) with SMTP id PAA05681
for <nanog@merit.edu>; Fri, 1 Aug 1997 15:01:31 -0400 (EDT)
Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id MAA14999; Fri, 1 Aug 1997 12:00:01 -0700
Message-Id: <199708011900.MAA14999@lovefm.cisco.com>