Thanks Gerry, Comments inline. > 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. > 2. There is no discussion of how to handle reports larger than the maximum UDP > datagram payload. See RFC 8085 section 3.2. The report encoded in the QNAME. In section 6.1.1 there is the following statement: "If the report query QNAME exceeds 255 octets, it MUST NOT be sent.” It is not possible to send a report larger than the maximum UDP datagram payload. Let me know if that is sufficient. > 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. > NiT: It could be useful to expand "DS records" on first usage. Okay. Will add that. Thanks Gerry for your review. Warmly, Roy > > > > _______________________________________________ > DNSOP mailing list > DNSOP@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dnsop -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
