In message <ecb5866f-cbc7-40a3-b8c3-6fe328dcf...@fl1ger.de>, "Ralf Weber" write s: > Moin! > > On 5 Aug 2015, at 17:05, Paul Hoffman wrote: > > > On 5 Aug 2015, at 1:58, Ralf Weber wrote: > > > >> On 5 Aug 2015, at 5:36, Mark Andrews wrote: > >>> The analysis above is lacking. > >>> > >>> "has cookie" is not the determining factor. "has good server > >>> cookie" > >>> is the determining factor. > >> For the attack that Ted describes later these attackers will have a > >> good server cookie as they are behind open resolvers that implements > >> cookies, so I think his analysis is correct. > > > > If an attacker is causing a system that does cookies to be an attack > > vector, then this proposal does no harm or good. > I have to disagree here. You are introducing additional complexity into > the server which now has to handle two possibly three rate limiter with > tables of counters to keep track of things with different algorithms > what to do. And in the end you still want to answer as many queries as > possible so you can't simply turn off non cookie traffic or rate it very > low.
If the attacker has a good cookie then you have a high degree of confidence that the IP address is correct even if it a UDP request and you can take steps like contacting the operators of the network / server. You can also just block requests from the address knowing that you are not harming someone else sans NAT'd traffic. But hey, you obviously don't want to be able to know that or do that. > > It might be attractive to say "there can be no possible help to the > > DDoS problem other than professional networking services that are seen > > today", but so far the WG has not agreed with that. > I'm not agreeing with that either, but I am saying that for most of the > attacks that this draft wants to protect against the operational > community has found a way to deal with them. > > > This proposal gives those who cannot afford such services a chance to > > respond to a DDoS in a way that might help. > > Which would only work in a vast or universal deployment which we know in > the DNS won't happen fast. Heck we still have a sizeable chunk of severs > not supporting EDNS0 after how many years now. 99.71% of TLD/Root servers support EDNS 96.07% of the Alexa top 1000 support EDNS 91.22% of the Alexa bottom 1000 of the top 1M support EDNS 98.08% of the GOV servers in the top 1M support EDNS 96.08% of the AU servers in the top 1M support EDNS By my book that is vast but not universal. The figures are also improving. > So long > -Ralf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
