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
