> 3.1) draft-ietf-dnsop-reflectors-are-evil-03.txt
Summary:
Because the solution proposed in the draft is as damaging as the attack
itself, and because the attack is merely an example of a broader
category of attacks already addressed elsewhere, and because the draft
contains false statements about the threats to authoritative
nameservers, I strongly object to this draft.
Detail:
On Wed, 7 Mar 2007, Peter Koch wrote:
> 3.1) draft-ietf-dnsop-reflectors-are-evil-03.txt
> [Joao/Fred][10 min][17:50]
> post WGLC discussion -- ready for the IESG?
This draft falsely claims that the amplification potential is greatly
reduced when authoritative servers are used:
DNS authoritative servers which do not provide recursion to clients
can also be used as amplifiers; however, the amplification potential
is greatly reduced when authoritative servers are used.
The amplification potential to authoritative servers is exactly the same
as for recursive servers, and the attack volume depends only on the
bandwidth available to the nameserver and the number of queries sent.
No evidence was given to show that there is any difference between
authoritative servers and recursive servers. Scanning the internet for
recursive nameservers is as difficult or more difficult than scanning
for authoritative nameservers for large records. Further, no scanning
is necessary at all if one uses the root servers to conduct this attack,
since the root servers IP addresses are known, and there is no
mitigation.
Further, when recursion is denied, a referral list of authority servers
is typically sent. This can also amount to a large packet size and
therefore a high volume of traffic. Denying recursion can be just as
bad as the attack described. Further, denying recursion can disrupt
legitimate recursive use by mobile or traveling users, resulting in
complete disruption of nameservice and internet access for those users.
No consideration has been given to the effects of disabling recursion.
Second, the attack description is also incomplete:
1. The attacker starts by configuring a record (LRECORD) on any zone
he has access to (AZONE), normally with large RDATA and TTL.
The attacker may start by scanning the authority servers for a large DNS
record, such as large PTR records, or large SPF records, large DNSSEC
records, etc. This particularly relevant to step 3
3. Each ORNS proceeds with the resolution, caches the LRECORD and
finally sends it to the target. After this first lookup, access
to the authoritative nameservers for AZONE is normally no longer
necessary. The LRECORD will remain cached for the duration of
the TTL at the ORNS even if the AZONE is corrected.
It may be impossible to "correct" AZONE, since it may be a legitimately
large authority record.
There is a certain amount of exaggeration for the described attack. A
much simpler, and more devastating attack was reported that uses
authority and root nameservers for which there is no mitigation. So
far, no attacks have used the authority or root nameserver methods, even
though there is no mitigation for those attacks.
Attacks using recursive nameservers can be mitigated by blocking queries
from the target address temporarily.
The attacks that have been seen so far, use the method described in the
draft, and have an element of farce to them: Not frequent, not damaging,
and appear only to prove the point that this attack could happen. This
pattern is reminiscent of a similar kind of attack that was conducted on
open SMTP relays by anti-spammers. Real spammers never conducted such
attacks. Likewise, in this case it seems that real DOS attackers don't
use the attack described in the draft. As in the case of open relay
abuse, the abusers are detected and identified by monitoring for
scanning and subsequent abuse. As with open relays, slowly changing the
IP addresses of servers (and updating the users but not the abusers)
makes it necessary for abusers to keep scanning, easing the detection of
the abusers.
As the draft mentions, these attacks depend on the capability to spoof
the IP address of the target in the source address field of the query,
and so these attacks are really part of a much broader array of attacks
that can be conducted if the source IP address can be spoofed as
described in BCP38.
Last, but not least, there are many positive and beneficial uses for
open recursors. Besides the obvious purpose of providing service to
mobile users, they enable remote testing and diagnosis of DNS problems.
They enable testing and detection of Anycast DNS servers. They enable
performance monitoring of diverse internet links. Etc.
Because the solution proposed in the draft is as damaging as the attack
itself, and because the attack is merely an example of a broader
category of attacks already addressed elsewhere, and because the draft
contains false statements about the threats to authoritative
nameservers, I strongly object to this draft.
Dean Anderson
Av8 Internet, Inc
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
