OK, so we need to have some appropriate language here in the threats
document.
In particular we need to be aware that this sort of attack might be
performed as a DDoS attack.
The only solution to this sort of thing is going to be to find a way of
suppressing DDoS type traffic, in particular spoofed source address
packets. This is not very hard for ISPs to do, if a machine is
generating reams of spoofed source address data then it has been botted
and should be either refused service or moved to an isolation network.
-----Original Message-----
From: william(at)elan.net [mailto:william(_at_)elan(_dot_)net]
Sent: Monday, February 27, 2006 11:19 AM
To: Hallam-Baker, Phillip
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Threats Issue - Large DNS records
make servers targets for spoofed source amplification attacks abuse
I think you misunderstood what I said. DKIM does not cause
any greater issues for "misconfigured systems" (i.e. public
dns servers that allow recursive queries) that already exist.
But it does make any dns server that deploys large DKIM
records just as good for use in amplification attacks as
those "misconfigured systems" that do allow recursion.
On Mon, 27 Feb 2006, Hallam-Baker, Phillip wrote:
As a matter of policy it is a bad idea to attempt to
architect around
misconfigured systems.
This should probably be mentioned in threats but the only long term
fix here is for recursive DNS servers that accept unrestricted,
unauthenticated requests to have code in them to make sure they are
not doing this sort of thing.
From a tactical perspective amplified DNS attacks are
vastly easier
to
control than a random spoofed source attack, simply drop
the traffic
from the offending sites which will in any case be seeing a
heavy load.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of
william(at)elan.net
Sent: Monday, February 27, 2006 10:46 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] Threats Issue - Large DNS records
make servers
targets for spoofed source amplification attacks abuse
There have been a lot of discussions going on in the last
few days at
NANOG and other dns operations lists that are related to issue of
public recursive dns servers being used to amplify an attacks:
http://www.gossamer-threads.com/lists/nanog/users/89657
http://lists.oarci.net/pipermail/dns-operations/2006-February/
thread.html
The general description of the problem is that bad guys
are sending
spoofed udp packets to servers in a way so that the servers would
send data (to spoofed source) that is considerably larger then the
original request - thus the amplification. For more
information, you
may want to read
http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf
In current case with DNS abuse documented above, most (almost
all) dns servers only have records that a small and so the servers
are not good targets for any significant amplification. So
attackers
are basically poisoning recursive nameservers with their own large
data as a way to get them to become good targets and good
amplifiers
- this has been quite successful and is currently major
issue for dns
operations and security folks.
Getting back to this group work - you are expecting to introduce
large DNS records as a mainstream for many dns servers. This would
make such servers a great target for use in amplification attacks
even if those servers are not configured to do recursion.
This is bad
and potential for such an attack and abuse for anyone
using DKIM must
be documented and it must be made clear that servers with DKIM
records may become targets for use in DNS amplification
attacks. In
fact the larger the record you put in dns, the better
target for such
an attack it becomes!
Note that there is currently no good solution to this
issue for UDP
protocols (most either do TCP-like session establishment before
sending large data or they are engineered so that responses can be
limited with ACLs to only specified group of systems, i.e.
local LAN
in case of DHCP).
My personal view is that if there is a way to avoid
introducing large
records into UDP one query-response situation, that it absolutely
must be done. So I would see as best solution a
replacement of public
keys in dns with an approach that uses a lot smaller
fingerprints in
DNS.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html