Subject: [DNSOP] Re: secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt

From: Dean Anderson <[email-masked]>
Date: Mon, 24 Sep 2007 18:25:49 -0400 (EDT)

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-masked]
> 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-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Dean Anderson <[email-masked]>
Date: Mon, 24 Sep 2007 18:25:49 -0400 (EDT)

This case is ignored.

Dean Anderson
Av8 Internet, Inc

---

From: Dean Anderson <[email-masked]>
Date: Mon, 24 Sep 2007 21:31:27 -0400 (EDT)

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.   Harm only possible for EDNSO; Update RFC 2671 Instead
> I.   Harm only possible for EDNSO; Update RFC 2671 Instead
> 
> 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
> legitimately large EDNS records.  Blocking all authority nameservers for

---

From: Dean Anderson <[email-masked]>
Date: Mon, 24 Sep 2007 21:31:27 -0400 (EDT)

--Dean