Sorry for the late message, but I support both the intent and the draft. One question: Would it be feasible for recommending that full service resolvers check for EDNS0 bufsize compliance, and treat violations as if they were TC=1? E.g. Suppose I am a resolver, and send my query to an authority server with bufsize=1220 (per the draft). If I get a response that exceeds that size, I unilaterally modify the response to set the TC bit, which triggers retry over UDP, without looking at any of the response data.
If it makes sense, it probably should be added to the above draft rather than being standalone. I think this suggestion is a very minor hack, and I can't see any real downside to it. The bufsize adherence is mandatory. If bufsize was <= MTU, for sure fragmentation occurring would require bufsize violation. (The reverse is not automatic; if MTU <= actual < bufsize, fragmentation might not have occurred, even though the requested bufsize was not honored.) This adds protection against the one corner case that the original ID isn't able to fix. The upside of this suggestion is, the party at risk (resolver and resolver's clients) is the same party that needs to apply the fix, i.e. it is symmetric in nature. Obviously, authority servers that do not honor bufsize still need to fix their implementations, but at least this allows impacted resolvers to unilaterally protect themselves (exactly analogous to setting bufsize <= MTU in the first place). Brian On Fri, Jul 5, 2019 at 2:02 AM <fujiw...@jprs.co.jp> wrote: > Dear DNSOP, > > I submitted draft-fujiwara-dnsop-avoid-fragmentation-00. > > https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00 > > It proposes avoid IP fragmentation operation in DNS. > > I removed details of attack to path MTU discovery and cache poisoning > attacks using IP fragmentation from > draft-fujiwara-dnsop-fragmentation-attack01, and changed as > recommendations. > > Details of attacks are written in slides at OARC 30. > > https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf > > > If the draft is interested, I will request timeslot at IETF 105. > > I think it is time to consider to avoid IP Fragmentation in DNS. > It is possible to avoid IP fragmentation as much as possible. > > It is not good that DNS is the biggest user of IP fragmentation. > > Regards, > > -- > Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > > > > A new version of I-D, draft-fujiwara-dnsop-avoid-fragmentation-00.txt > has been successfully submitted by Kazunori Fujiwara and posted to the > IETF repository. > > Name: draft-fujiwara-dnsop-avoid-fragmentation > Revision: 00 > Title: Avoid IP fragmentation in DNS > Document date: 2019-07-04 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-avoid-fragmentation-00.txt > Status: > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/ > Htmlized: > https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-avoid-fragmentation > > > Abstract: > Path MTU discovery is vulnerable and IP fragmentation may cause > protocol weakness. Currently, DNS is said to be the biggest user of > IP fragmentation. However, it is possible to avoid IP fragmentation > in DNS because TCP transport and truncation work well. This document > proposes to avoid IP fragmentation in DNS. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
