On Sun, Jul 31, 2022 at 11:54 AM Paul Vixie <paul= 40redbarn....@dmarc.ietf.org> wrote:
> > > Andrew McConachie wrote on 2022-07-28 03:24: > >> Path MTU discovery remains widely undeployed due to > >> security issues, and IP fragmentation has exposed weaknesses in > >> application protocols. > > > > PMTUD doesn’t work through NAT and that’s probably the main reason why > > it doesn’t work on the Internet. I think that’s less of a security issue > > than just a general issue with PMTUD not working on the modern Internet. > path mtu discovery has been significantly rethought in the modern internet: > > https://www.rfc-editor.org/rfc/rfc8899.html > > apparently, it sometimes works: > > > https://developers.redhat.com/articles/2022/05/23/plpmtud-delivers-better-path-mtu-discovery-sctp-linux > > see also: > > <<This new algorithm does not rely on ICMP or other messages from the > network (so it is not subject to the problems described in RFC2923). > Instead it finds the proper MTU by starting with relatively small > packets and searching upwards by probing with test packets.>> > > https://datatracker.ietf.org/wg/plpmtud/about/ (I would note that the above wg is "status: closed".) > > > i suggest further reading and perhaps reconsideration. we've got to > break out of the MTU 1500 jail some day or the internet will end in > header processing related heat death. some work is being done and some > results are already known. we should be open to the possibility of > improvement. > If there is interest in pursuing DNS-specific methods for learning and using path MTU values, where would the right venue for that be? Concrete suggestions on the subject itself: - Could clients learn per-server PTMU from TCP, and (with some added active measurement/management of those results) use that in EDNS bufsize for UDP? - Maybe some additional explicit signaling for support for whatever PMTUD mechanisms to use? - Since TCP sessions might not be long lived, would a parallel (rather than sequential) packet size attempt mechanism be possible? - E.g. break the DNS message into a number of first-packet sizes that are common or viable MTU sizes, and send them all with the same sequence number but different lengths? Have the server ACK the largest one received within some nominal window of time? (Might not work in standard TCP stack, but perhaps a DNS-specific TCP implementation?) - I am interested in keeping as much DNS traffic on UDP and unencrypted as possible, at the authoritative side. Use DNSSEC to protect the content. I am not convinced of the necessity of ADoX generally. Having said all that, I still am in favor of preventing UDP fragmentation, regardless of the MTU used, and support this draft. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
