At Thu, 13 Sep 2018 17:25:04 +0200, "Mirja Kuehlewind (IETF)" <i...@kuehlewind.net> wrote:
>>> I'm wondering if it would make sense to provide stronger guidance that the >>> conventional ANY response SHOULD be provided if TCP is used as TCP already >>> provides a retrun routability proof...? Also maybe provide a refernce to >>> RFC7766? >> This has nothing to do with "retrun routability" if big answers >> are given to resolver via TCP then the resolver can be used as >> amplifier and there Millions of those on the net. > With TCP you usually set up a TCP connection (3-way handshake) then > send the request on that connection and get the reply on that > connection. You can not change the IP address in the mean time. So > there should not be that amplification attack anymore. That was what > I was saying. (I'm not intending to speak for him but) I guess what Ólafur intended to say is that if a legacy (so not implementing dnsop-refuse-any) and open resolver sends an ANY query over TCP and gets and caches the large "conventional" response, that resolver can be exploited as an amplifier for subsequent ANY queries with a forged source address (and quite likely over UDP). If so, that's true, but I don't think it trivial to force such a resolver to send the ANY query over TCP in the first place, and the argument against "a return of routability proof" doesn't seem to be strong enough. In fact, I'd interpret Section 4.4 of draft-ietf-dnsop-refuse-any-07 as it allows the conventional ANY response over TCP exactly thanks to this return of routability proof (this "responder" is much less likely to be exploited as an amplifier thanks to that). If the intent of this section has really nothing to do with that, I'd like to see some explanation about the actual intent in the document. Whether we *SHOULD* (rather than MAY) allow the conventional response in case of TCP is a different question, on which I don't have a strong opinion. -- JINMEI, Tatuya
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
