Subject: secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt

From: "Stephen Hanna" <[email-masked]>
Date: Mon, 24 Sep 2007 15:51:38 -0400

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Sep 2007 09:36:23 +1000

> the systems vulnerable to these attacks. I suggest that the defensive

	No, the blame lies with the parties not implementing BCP 38.
	A rogue end site should not be able to inject spoofed packets.
 
> in the document.

	The other measure reduce the number of amplifiers.  There
	are however enough other amplifiers out there that many
	argued that this whole docuement was a waste of time as it
	can't reduce the problem enough.  That being said they
	wern't going to try to stop it being published.

	At best this document helps build a "Clue x 4" bat.

> None of these measures (including increased use

	It reduces the places to launch these attacks to ISP's
	routers if BCP 38 is correctly deployed by ISP's.  All the
	end sites should be filtered as well as any internal subnets
	of the ISP itself.

	If you have a rogue ISP then they should be disconnected by
	their peers / transits.

> shift to TCP.

	The DNS already does this.  The DNS is optimised so that the
	normal responses go via UDP and the exceptional responses via
	TCP.

> Of course, this would have other unpleasant side effects

	It's been consided, tried, and proved a dismal failure.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Sep 2007 11:04:09 -0400

>a long response, fake requests would provide little amplification.

It would be easier to just disable the UDP transport and go to TCP 
only to accomplish the same goal.  (For one, the handshake would be 
subject to the same vulnerabilities that TCP has been strengthened 
against.)  Removing UDP from DNS erode the light, quick nature of 
(legitimate) use.

>considered (which probably has already been done).

Consider it considered.  That cure would be worse than the disease. 
Especially as the trend will likely be towards a greater incidence of 
large DNS responses, e.g., for IPv6, for ENUM, and (if it ever flies) 
for DNSSEC.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.