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?
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.
GF: This sounds a sensible limit - I overlooked that, this is fine.
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.
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....
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
_______________________________________________
Tsv-art mailing list
Tsv-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tsv-art
Hope this helps,
Gorry
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
