I opposed this document in the DNSOP working group. I have found some
additional reasons to oppose this document, in addition to the reasons I
gave to the DNSOP WG. I generally agree with Stephen Hanna's findings.
I. Harm only possible for ENDSO; Update RFC 2671 Instead
II. Authority Servers not Addressed, but Present More Harm
III. Motivating Attacks Seem Contrived
IV. Ordinary DDOS Mitigation Appropriate for Reflector Case
V. Mitigation Options Limited in Authority Case
VI. Using "Evil" in a RFC Title is Unprofessional
VII. Reflectors are Useful for Scientic Measurement
VIII.Conclusion: Insufficient Harm to Justify Action
I. Harm only possible for ENDSO; Update RFC 2671 Instead
The maximum non-EDNS amplification factor is 8 (512 byte maximum
response / 64 byte minimum query) The non-EDNS attack has been possble
for over 20 years, but there have been no significant problems reported
in that time. There is no reason to think the non-EDNS case presents
any problem, nor has that case ever presented a problem.
The significant harm posed by the attack described in this document is a
result of EDNS extensions which allow DNS servers to respond with upto
8K byte long response to a relatively short EDNSO query.
The EDNSO extension considered some security vulnerabilies created by
the protocol extension. RFC 2671 states:
6 - Security Considerations
Requestor-side specification of the maximum buffer size may open a
new DNS denial of service attack if responders can be made to send
messages which are too large for intermediate gateways to forward,
thus leading to potential ICMP storms between gateways and
responders.
Security vulnerability of DDOS is nothing new for EDNSO. Therefore at
most, this should be added as an addition to the security considerations
section in an update to RFC 2671.
II. Authority Servers not Addressed, but Present More Harm
This document ignores the implications of these facts:
1. Amplification does not require reflectors, but only requires servers
with sufficiently large packets and high bandwidth capabilities.
2. Authority servers are more difficult to block, since blocking
authority servers results in a outage of DNS service for the zones
served by that authority server.
III. Motivating Attacks Seem Contrived
The motivating attacks also have a feature of being contrived examples.
In the actual attacks reported, serious forensics would lead to the
identity of the attacker, making intelligent attackers avoid this
attack. In the example widely discussed, the attacker obtained root
access to a nameserver and hand-crafted an 8Kbyte ENDS record on the
server. The attacker then uses a group of computers to send ENDS query
packets with false source address to 'reflector' nameservers, which sent
the 8kbyte response to the spoofed source address.
Even though forensics would probably be able to identify the intruder to
the original nameserver, in the motivating attack, the attack was not
serious enough to merit law enforcement to conduct forensic analysis.
There have been no further similar attacks.
IV. Ordinary DDOS Mitigation Appropriate for Reflector Case
Mitigation includes blocking the reflector nameservers with no harm to
the target of the attack. Mitigation can be done at any convenient
point on the path between the reflector and the target. One motivating
statement for the draft was that 'one cannot contact 20,000 server
operators to ask them to block the packets'. But that is not a
requirement for mitigation. Mitigation can be performed by ISPs in the
path, as is currently done for other types of DDOS attacks.
Because the mitigation options are the same as with any other spoofed
DDOS attack, this attack does not merit special attention. And as the
document states, if one can't send spoofed packets, one cannot conduct
this attack at all.
V. Mitigation Options Limited in Authority Case
By contrast with the open recursor case, one cannot easily mitigate an
identical attack using legitimate authority nameservers serving
legitimately large ENDS records. Blocking all authority nameservers for
a given zone disrupts DNS service between the DDOS target and the zones
on the affected nameservers. Examples of such servers include the Root
DNS servers. Blocking the Root DNS servers is at least as bad if not
worse than the DDOS traffic.
This case is ignored.
VI. Using "Evil" in a RFC Title is Unprofessional
The word "evil" in the name given to the draft and used in its title is
also unprofessional, and doesn't belong in IETF documents. A search of
the RFC Index revealed no other similarly titled documents.
VII. Reflectors are Useful for Scientic Measurement
Last, the open recursor is a very useful scientific tool for analyzing
the internet, and is used in a number of scientific papers: "King:
Estimating Latency between Arbitrary Internet End Hosts" by Gummadi,
Saroiu, and Gribble
(http://www.cs.washington.edu/~gribble/rw/papers/awards_assets/king.pdf)
The King method is cited in several scientific papers on Anycast:
"A Measurement-based Deployment Proposal for IP Anycast", Ballani,
Francis, and Ratnasamy
http://pias.gforge.cis.cornell.edu/pub/anymeasure-imc-camera-final.pdf
Because the NSID draft (RFC 5001) makes it impossible to independently
identify Anycast Root DNS server instances (because the returned nonce
is encrypted and only decryptable by the root operators) and therefore
impossible to measure the reliability of Anycast Root DNS services; the
open recursor method is the only economical method to measure anycast
services.
VIII.Conclusion: Insufficient Harm to Justify Action
There is very little or no actual harm to having open DNS recursors, and
a great deal of benefit. DNS server operators should not be discouraged
from operating open recursors.
Dean Anderson
Av8 Internet, Inc
On Mon, 24 Sep 2007, Stephen Hanna wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> DNS is not my area of expertise but the document clearly explains
> the nature of the problem to be solved (DOS attacks that employ
> DNS servers as amplifiers) and the recommendations for solving the
> problem (employing ingress filtering to prevent IP address spoofing
> and changing nameservers to provide recursive name lookup service
> only to the intended clients).
>
> I have no issue with the main content of the document. It does seem
> like a worthwhile recommendation. However, I have a few comments.
>
> The Introduction seems a bit defensive in stating that the DOS attacks
> are not due to any flaw in the design of DNS or its implementations.
> While the blame for the attacks lies with the attackers, some aspects
> of nameserver configuration, behavior, and even protocol design make
> the systems vulnerable to these attacks. I suggest that the defensive
> language be removed.
>
> Although I agree that ingress filtering is a good solution to this
> problem and provides many other benefits since it addresses many
> different attacks that involve spoofed IP addresses, the document
> states repeatedly that ingress filtering is the only solution to
> the problem. Ingress filtering may be the best solution but it is
> NOT the only solution, as evidenced by the other measures described
> in the document. None of these measures (including increased use
> of ingress filtering) will provide complete and absolute protection
> against DOS attacks that use nameservers as attack amplifiers.
> Employing all of the measures as appropriate while emphasizing
> the huge benefits of ingress filtering seems like the best approach.
> So I suggest that the wording in the document be toned down to take
> a more balanced approach to the problem.
>
> Finally, I wonder whether other more fundamental techniques for
> addressing the problem have been explored. For instance, if DNS clients
> were required to perform a simple handshake before a DNS server sent
> a long response, fake requests would provide little amplification.
> For example, requests that elicit long responses could prompt a
> shift to TCP. Of course, this would have other unpleasant side effects
> such as slowing down the processing of DNS requests with long responses
> and troubles getting DNS requests through firewalls. I'm not suggesting
> that this approach be discussed in this document, simply that it be
> considered (which probably has already been done).
>
> Thanks,
>
> Steve
>
> _______________________________________________
> Ietf mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/ietf
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
