---------- Forwarded message ----------
Date: Mon, 13 Nov 2006 15:51:59 -0800 (PST)
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
To: dnsop(_at_)lists(_dot_)uoregon(_dot_)edu
Subject: [dnsop] More on NXdomain attack scenarios
First I have to say I'm disappointed that Doug in his slides on
'draft-otis-spf-dos-exploit' draft did not explain attack scenario
at all. He basically just went ahead with rant about how SPF is all bad
(including in some bad data in order to increase his numbers) - this
is very very clear case of FUD and I'm disappointed that it has been
allowed to happen on IETF WG meeting - at the very least the WG chair
should have recognized it and either not allowed presentation on such
a draft or required Doug to use SPF as only in an example for showing
general issue (which probably he cant do given his very strong anti-SPF
bias and that being entire reason for that draft).
Now regarding the attack scenario itself (which is purely theoretical
at this point), I have some operational network security experience
and I find this attack to be somewhat unlikely or at least less then
preferred for an attacker given other alternatives. The reason is
that this is not pure DDOS but combination of using distributed
botnet and centralized dns server used for amplification. Given
that amplification numbers seem closer to 10:1 it means that an
attacker who wants victim to get 1Gb DoS would have to endure
100Mb traffic to his DNS server. I dont think attacker wants to
see that and what is worse this has one central point which unlike
zombie control box can be identified from outside and shutdown
fairly quickly when it does happen. This one central point can
also give an additional means of tracking down responsible party
which is again something attacker wants to avoid. Since the attacker
is already assumed to be controlling zombie army I find more likely
that he'd use it directly to launch DDoS attack and he'd then also
have more control over amount of traffic and length of the attack.
As far as NXDomain attack, I do think similar scenario not involving
amplification slightly more likely. What can happen is if attacker
indeed wants to try to hide his zombie army he can try to just directly
input victim's domains in his spam, i.e. one name in EHLO another in
MAIL FROM, some other in header "From", others in "Received", in URLs
embedded in the message text, etc. Given current anti-spam filtering
systems he can probably get about 5 NXDOMAIN requests to victim for
each email message without having to involve his own domain at all.
Now such attacks already do happen - they are called joejobs and
spammers use them quite successfully (I'm not sure if NXDomain
in main DoS part itself; more likely is to use this to impersonate
victim so he receives bounces and angry emails; this is in fact
what SPF is trying to protect against).
Now given all the above I'm not at all sure if DNSOP should even
try to address this issue given that redirection to multiple sources
is already is at the core of protocol and its use. At best you
may want to discuss giving recommendations on how many NS records
should be used by resolvers (to limit the NS amplification scenario
I specified in last post; at least this scenario is something that
involves purely DNS implementations i.e. its on-topic for the WG).
Last time I asked similar question (on ISC's dns-operations mail list):
http://lists.oarci.net/pipermail/dns-operations/2006-June/000654.html
I was told by Paul Vixie that I'm supposed to go through all of them
(but ignore already known bad leafs), I still think its too open for
either direct abuse or just due to unintentional errors.
For other applications that use DNS records you may also want to say
that certain limits and timeouts should exist to avoid potential
amplification problem - this is especially true regarding use of MX
and SRV. Regarding SPF, unlike other protocols there are actually
already limits (10/10/10 i.e. no more then 10 of same type of operators
like mx) specified in RFC4408 and it is still under discussion if this
needs to be made tighter or not with general dns limit (though I'm not
entirely sure if its on-topic for this list, you're welcome to comment
about it and I'll pass it on to appropriate list and to spec author -
I can also do the same if you write to me in private).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735