[DNSOP]Re: Fwd: New Version Notification for draft-momoka-dnsop-3901bis-05.txt
Greetings, There seems to be a mismatch between the document's intended status of Informational and the statement in the Abstract that it "documents Best Current Practice". I note that RFC 3901 in fact was a BCP. Mike Heard ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: draft-ietf-dnsop-avoid-fragmentation-17.txt - implementer notes
Greetings, I am replying from the POV of an outsider to DNSOP. On Mon, May 6, 2024 at 6:59 AM Petr Špaček wrote: > > Hello dnsop, > > Warren asked implementers to provide feedback on the current text, so > I'm doing just that. [ ... ] > > 3.1. Recommendations for UDP responders > > > > R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200]. > > Operational impact of this recommendation is unclear. > > Why? Because clients belong to several sets: > - One set clients cannot receive fragmented answers, > - another set of clients cannot use TCP to overcome unfragmented UDP > size limitations, > - yet another set of clients actually depend on large answers to > function (say because they DNSSEC validate, or need to follow huge NS > sets generated by MS AD, or they need large RRs to deliver e-mail, or ...). > > It's unclear what proportion of clients belong to intersection of these > three sets. Banning fragmentation on the **outgoing** side might break > these clients, and it's extremely hard to measure and debug from the > server side. This complaint is really unclear. The recommendation is specifically for responders, i.e., servers. It's not a priori whether the term "outgoing" means the requestor to responder direction or the responder to requestor direction. I presume the latter, but it would be better if this was made obvious by using the same terminology as the draft. What I think you are saying is that clients that cannot re-send truncated queries using TCP will be hurt by the recommendation. Aren't such clients non-conformant with current DNS standards? If so, are they sufficiently prevalent that it is necessary to continue using workarounds to accommodate them? Wasn't the whole point of DNS Flag Day to break what was broken and get it fixed? [ ... ] > > R6. UDP requestors SHOULD drop fragmented DNS/UDP responses without IP > > reassembly to avoid cache poisoning attacks. > > AFAIK this is impossible to do using normal socket API. The application > has no access to information about UDP reassembly. > > Having said that, even if it was implementable it's IMHO not the best > advice for requestor. > > IF the requestor is able to detect that a fragment was received then it > would be MUCH better to trigger retry using different protocol right > away. Just dropping the packet: > a] causes timeouts > b] leaves a time window open for another attack attempt I wondered about this after I read the draft (which was after WG last call, or I would have commented). I'm not aware of any stack that allows the application to disable IP reassembly, nor any that indicates whether a received UDP datagram was received in a single IP datagram or in multiple IP fragments. If that is indeed the case, this recommendation should be removed, since it is not actionable. Additionally, my understanding of the motivation for this is to prevent off-path cache poisoning attacks. If I correctly understand what I have read, these are a problem for IPv4 (which has only a 16-bit datagram ID) or for IPv6 stacks that emit predictable datagram IDs. It seems to me that the advice to avoid reassembly would need to be more nuanced, even if it were actionable. Thanks and regards, Mike Heard ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
Re: [DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
Thank you for your reply. I have added some comments in-line. On Thu, May 2, 2024 at 10:42 AM Ben Schwartz wrote: > It seems like this draft says that the indicated MRDS overrides the EDNS > BUFSIZE value. This seems likely to create problems if the MRDS value > could be set by a lower layer in the stack or a downstream processing > component (without knowledge of DNS), resulting in responses that are too > large for the DNS client's allocated buffer. In other words, just because > I am capable of receiving very large UDP packets does not mean that I am > capable of processing very large DNS responses. > This actually should not be a concern, as the intent is that UDP options are sent, or responded to, ONLY at the explicit behest of the upper layer. In other words they are always opt-in. In this instance, the upper layer would have to explicitly ask for the MRDS option to be included in the outgoing request, and would have to set the MRDS size appropriately (which would mean, the lesser of its own buffer capacity and what the system would support). > In general, support for very large DNS responses in UDP is considered > harmful because of the potential for reflection-amplification attacks. For > this reason, as well as concerns about legacy compatibility and general > complexity, I think we would be better off not attempting to use UDP > Options with DNS. > Point taken - fallback to TCP does not have this particular vulnerability. Respectfully, Mike Heard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
Greetings, TSVWG currently has the document "Transport Options for UDP" ( https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options) in Working Group Last Call. It includes a capability to fragment datagrams at the UDP layer rather than the IP layer, and one of the use cases that has been discussed over there is using that capability to transmit large DNS responses without suffering the disadvantages of IP fragmentation or fallback to TCP. But we need a reality check from the subject matter experts over here to help us determine whether this idea is viable. Accordingly, I put together a short (and at this point not very polished) individual draft describing how this might work. Your feedback will be greatly appreciated. Thanks and regards, Mike Heard -- Forwarded message - From: Date: Sun, Apr 28, 2024 at 12:52 PM Subject: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt To: C. M. Heard (Mike) A new version of Internet-Draft draft-heard-dnsop-udp-opt-large-dns-responses-00.txt has been successfully submitted by C. M. (Mike) Heard and posted to the IETF repository. Name: draft-heard-dnsop-udp-opt-large-dns-responses Revision: 00 Title:Use of UDP Options for Transmission of Large DNS Responses Date: 2024-04-28 Group:Individual Submission Pages:8 URL: https://www.ietf.org/archive/id/draft-heard-dnsop-udp-opt-large-dns-responses-00.txt Status: https://datatracker.ietf.org/doc/draft-heard-dnsop-udp-opt-large-dns-responses/ HTMLized: https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses Abstract: This document describes an experimental method for using UDP Options to facilitate the transmission of large DNS responses without the use of IP fragmentation or fallback to TCP. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
