> On 17 Oct 2023, at 12:33, Gorry Fairhurst <go...@erg.abdn.ac.uk> wrote: > > On 17/10/2023 12:05, Roy Arends wrote: >> Thanks Gorry, >> >> Comments inline. > See a quicjk response as GF: >>> On 17 Oct 2023, at 10:22, Gorry Fairhurst via Datatracker >>> <nore...@ietf.org> wrote: >>> >>> Reviewer: Gorry Fairhurst >>> Review result: Not Ready >>> >>> This document has been reviewed as part of the transport area review team's >>> ongoing effort to review key IETF documents. These comments were written >>> primarily for the transport area directors, but are copied to the document's >>> authors and WG to allow them to address any issues raised and also to the >>> IETF >>> discussion list for information. >>> >>> When done at the time of IETF Last Call, the authors should consider this >>> review as part of the last-call comments they receive. Please always CC >>> tsv-...@ietf.org if you reply to or forward this review. >>> >>> Thank you for a well written document, and it's description of the service >>> to >>> be provided. >>> >>> This is proposed as a "lightweight" reporting mechanism. >>> >>> The method states it can be used over TCP. In this case, TCP provides the >>> necessary congestion control, flow control and segmentation. I did not see >>> additional transport concerns. >>> >>> The method also states it can be used over UDP - which is equally >>> recommended. >>> However, the specification for use over UDP is incomplete and raises some >>> transport concerns: >> I want to stress here that the reporting mechanism is using DNS. >> >> Subsequently, it relies on existing methods of transport that DNS relies on. >> As an application that uses DNS to send a report, additional requirements >> such as mechanisms for flow control, segmentation, fragmentation, packet >> reassembly, order, congestion control, buffering, etc, feel like a layer >> violation. >> >> With that in mind, I suggest the following: >> >>> 1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), >>> but no >>> statement about how to mitigate the effects when these are not used. >> There is a statement in the security section: >> >> "The monitoring agent SHOULD respond to queries received over UDP that have >> no DNS COOKIE set with a response that has the truncation bit (TC bit) set >> to challenge the resolver to re-query over TCP.” >> >> Let me know if that is sufficient. > GF: I think it might be wise to include this in the body, so it is not > overlooked?
Good point. I’ve added that to the reporting resolver specification section, and the monitoring agent specification section, respectively. I’ll leave it in the security section as well. >>> 3. I think this method can in some uses could generate a stream of reports >>> at a >>> rate that could be more than a few UDP datagrams per RTT, (e.g., if >>> implement >>> automated responses). In this case, I think method would need to provide >>> some >>> basic rate limiting or implement a form of congestion control. >> DNS software have mitigations for these kind of streams. DNS is a well known >> method to be abused for DDoS purposes, and mitigation strategies have been >> wide and far. Any rate limiting methods in this document would require >> special casing in the DNS software to deal with error reporting. This is >> wholly unnecessary. As far as the transport and application layers are >> concerned, this is just a DNS query going out. >>> I understand the rate is usually "damped" by caching to one message/TTL per >>> report, but I am unsure this is sufficient to mitigate any congestion >>> control >>> concerns. >>> >>> One potential remedy could be to require/recommend use over a >>> congestion-controlled transport (such as TCP) when using an Internet path; >>> an >>> alternative would be to be define appropriate mechanisms to provide at least >>> starvation prevention for UDP services. See RFC 8085 section 3.1. >> We simply can’t. It would require special casing: a DNS query that happens >> to contain a DNS-error-report in its QNAME, should now only be send over >> TCP. An application that asks a stub resolver can’t do this. It would >> require a full “DNS-stack” that makes sure that these reports go over TCP. > GF: I think you likely undertand the gist of my review point 3. Generally - > there would be a problem in repeatedly sending with a UDP transport (i.e. for > something that is more than a query/response protocol), which results in > multiple packets per RTT. I understand what you are referring to. The bulk of resolver implementations have implemented query-deduplication to upstream servers. This specifically targets the case where you have multiple packets per RTT. In addition, standard DNS caching will deal with multiple queries for the same qname/qtype/qclass tuple per (DNS) TTL. > Now it might be also that I simply don't fully understand the expected > interaction, in which case, it might also be easy to add a little to help > avoid this line of questions.... I have added the following line to -07 abstract per request of Warren Kumari: "The error is encoded in the QNAME, thus the very act of sending the query is to report the error.” Thanks Gorry! Roy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
