FYI, I see I missed a number of typo's with 'ENDS'. This should read
instead 'EDNS'. It is fixed below.
--Dean
On Mon, 24 Sep 2007, Dean Anderson wrote:
> 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 EDNSO; 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 EDNSO; 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 EDNS record on the
> server. The attacker then uses a group of computers to send EDNS 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 EDNS 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
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
