>
>
> On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews
> <[EMAIL PROTECTED]> wrote:
>
> >> 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.
> >
> > No, the blame lies with the parties not implementing BCP 38.
> > A rogue end site should not be able to inject spoofed packets.
>
> No; the blame for an attack _always_ lies with the attacker, not the
> victim.
I'm not blaming the victim, I'm pointing out the contributory
negligence on behalf of the ISP that is supplying the
attacker bandwidth.
BCP 38 is over 7 years old now. The time has past where you can
blame the hardware vendors for lack of support. The blame
now has to be squarely brought down on the ISP's that have failed
to deploy BCP 38.
A attacker should not be able to send spoofed packet and have
them reach the destination. I don't care if the destination
is the other side of the world or the neighbor.
ISP's should be doing this anyway to protect their customers
from accidental traffic. e.g. DHCP lease changes where not
all of the sockets with the old address have shutdown. RFC
1918 sourced traffic.
> While I certainly wish more network providers would implement BCP
> 38, those who fail to do so are not to blame for the bad acts of others.
>
> FWIW, I believe the "defensive language" in question is neither necessary
> nor particularly problematic, so I take no position on whether it should be
> removed.
>
> >> 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.
> >
> > The DNS already does this. The DNS is optimised so that the
> > normal responses go via UDP and the exceptional responses via
> > TCP.
>
> It does, but normally only responses which are too long for UDP require the
> use of TCP. A recursive nameserver could mitigate this type of attack by
> lowering the maximum response size it is willing to send via UDP, forcing
> the use of TCP and thus a three-way handshake for larger responses. The
> tricky part is that setting the threshold too low can have serious
> performance impact.
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
