In message <[email protected]>, Vernon Schryver writes: > > From: Mark Andrews <[email protected]> > > > As far as I can tell there is no way to stop reflection attacks as > > long as ISP's allow spoof traffic to enter their networks. The > > attackers will just go broad spectrum (millions of reflectors) and > > no single reflector will be able to see that it is part of a attack. > > A problem with using a million reflectors is that it is a lot more > hassle. The goal need not be preventing all reflection attacks but > only making reflection attacks less rewarding and more costly than > other attacks, such as simple UDP floods from a modest botnet. The other part of the goal is to not lose resourse. Reflection attacks help there.
> > It is possible to detect current reflection attacks and mitigate > > them using RRL but this is only a stop gap measure which causes the > > attackers to choose different refectors. > > I agree, with the reservation that eventually RRL could eventually > cause attackers to choose different attacks. > > > What we can do is turn off amplification attacks. We know a number of > > methods of how to do this. > > > > * set TC=1 on all UDP query replies and force the client to TCP. > > which would kill busy DNS servers. Indeed. RRL does this selectively. > > * do a handshake over UDP before sending amplified replies. > > What qualifies as amplification? An unsigned (no DNSSEC) A request/response > is good for at least 3X. 10X or 20X is impressive but merely eases > the attacker's job by allowing fewer reflectors. We can go from 1X upwards. > Would you turn off all DNS/UDP without a DNS cookie by augmenting > https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 > with some kind of minimal "try again with a cookie" response similar > to but different from a minimal TC=1? I like DNS cookies, but they > would take many more years to deploy widely enough to matter than have > already passed since the I-D expired. If we had a code point we could see 10% deployment within a year especially if it pushed out in maintanence releases of older code trains. > If cookies, ttcp, or some other DNS protocol change is The Answer, > then in the years before The Answer is deployed, you're stuck with > making reflection attacks less attractive than alternatives, > which will slow The Answer. > > > Vernon Schryver [email protected] > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
