> On 17 Oct 2023, at 12:33, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> 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 <noreply@xxxxxxxx> 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-art@xxxxxxxx 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
