Subject: [dnsop] My reflections on the draft du-jour (reflections)

From: Edward Lewis <[email-masked]>
Date: Mon, 22 May 2006 15:02:32 -0400

Referring to what's at:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-00.txt

#
#            Preventing Use of Nameservers in Reflector Attacks
#               draft-ietf-dnsop-reflectors-are-evil-00.txt

The title is overstated.  To "prevent" you'd have to stop this, and what is
described herein just shuts down one means by which DNS can be used for this.
Perhaps "Why DNS Recursive Service Ought to be Limited."

# Abstract
#
#    This document describes the use of default configured recursive name
#    servers as reflectors on DOS attacks.  Recommended configuration as
#    measures to mitigate the attack are given.

This document discusses a side effect of DNS implementations whose default
configuration offers recursive service to all queriers.  Unless the 
configuration of such servers is altered, these provide one mechanism 
that can be used in launching a DOS attack.  Often times, there is no 
reason to offer recursive service to the general Internet.

# 1.  Introduction
#
#    Recently, DNS [RFC1034] has been named as a major factor in the
#    generation of massive amounts of network traffic used in Denial of
#    Service (DoS) attacks.  These attacks, called reflector attacks,
#    while not being due to any particular flaw in the design of the DNS
#    or its implementations, have preferentially used DNS due to common
#    default configurations that allow for easy use of public recursive
#    name servers that make use of such a default configuration.

It can be argued that this *is* because of a flaw in DNS design, 
which is why simple configuration steps can't solve the problem. 
(Why ingress filtering is a better step.)  Or maybe it is that 
Internet protocols have the weakness that they have to be carefully 
operated so as to not cause a network-wide meltdown.

That DNS uses UDP is inherent, and it is UDP's nature that is being 
abused.  I don't mean to say that UDP is the root of all evil, but 
saying that this is not due to a design or implementation flaw in DNS 
is incorrect.

#    In addition, due to the small query-large response potential of the
#    DNS system it is easy to yield great amplification of the source
#    traffic as reflected traffic towards the victims.

You should point out that closing off recursive service will not end 
the amplification problem, DNSSEC will (eventually) make just about 
any authoritative server a good source of amplification.  If not 
DNSSEC, then ENUM's NAPTR sets.

#    In this document we describe the characteristics of the attack and
#    recommend DNS server configurations that alleviate the problem, while
#    pointing to the only truly real solution to the problem, the wide-
#    scale deployment of Ingress Filtering to prevent use of spoofed IP
#    addresses [BCP38].

Point out that your solution plugs one hole, even though others 
remain open.  Plugging this hole lessens the abuse by "innocent" 
servers in attacks on victims, often without a reduction in service 
to the intended audience of the server.

# 2.  Problem Description

#    and PRNS could generate gigabits of traffic towards the targetted

s/targetted/targeted/  (Shrug, it's an English thing, what can I say?)

# 3.  Recommended Configuration

#    o  Use TSIG [RFC2845]signed queries to authenticate the clients.
#       This is a less error prone method, which allows server operators

I have never, ever, seen any approach using cryptographic wizardry to 
be the "less error prone" method. ;)

In general, I think the rough seas this document is sailing into is 
caused by the impression it gives that this is the only solution to 
the entire problem.

I don't see any specific mention of "reflection" attacks - i.e., the 
use of "bouncing" packets off another server to make the sender 
anonymous.  I don't think that reflection is even the culprit - 
anyone can craft a packet with a false return address.  When it comes 
to "traceback" - if I can trace back directly to the source, I bet 
the server operator can do it too.

Closing unnecessarily open service offerings is wise.  Closing one 
more hole in the dyke is beneficial even if one may think it is 
futile to keep the sea out.  The message should be "if you don't need 
to make it openly available, close it.  Run a tight ship."

Make the case that open recursion is no longer the beneficial thing 
it once was.  Just about any computer can run a full DNS resolver.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html