Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation
Kazunori Fujiwara <fujiwara@jprs.co.jp> Tue, 16 August 2022 09:08 UTC
Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C7C15A720; Tue, 16 Aug 2022 02:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTkAZ01cYrAp; Tue, 16 Aug 2022 02:08:00 -0700 (PDT)
Received: from off-send41.osa.jprs.co.jp (off-send41.osa.jprs.co.jp [IPv6:2001:218:3001:17::50]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC34C14CE40; Tue, 16 Aug 2022 02:07:58 -0700 (PDT)
Received: from off-sendsmg31.osa.jprs.co.jp (off-sendsmg31.osa.jprs.co.jp [172.23.8.161]) by off-send41.osa.jprs.co.jp (Postfix) with ESMTP id D0C5D4058C6; Tue, 16 Aug 2022 18:07:55 +0900 (JST)
Received: from off-sendsmg31.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss91 (Postfix) with ESMTP id 840226024832; Tue, 16 Aug 2022 18:07:55 +0900 (JST)
Received: from localhost (off-cpu08.osa.jprs.co.jp [172.23.4.18]) by off-sendsmg31.osa.jprs.co.jp (Postfix) with ESMTP id 76CCB602457C; Tue, 16 Aug 2022 18:07:55 +0900 (JST)
Date: Tue, 16 Aug 2022 18:07:55 +0900
Message-Id: <20220816.180755.121279054505639914.fujiwara@jprs.co.jp>
To: muks@mukund.org
Cc: touch@strayalpha.com, int-area@ietf.org, dnsop@ietf.org
From: Kazunori Fujiwara <fujiwara@jprs.co.jp>
In-Reply-To: <Yvsq5Hz9kmH/CFm3@d1>
References: <90B5AF9A-DFCB-4A28-AD91-2F8A619FE439@strayalpha.com> <20220816.130734.30982997073008354.fujiwara@jprs.co.jp> <Yvsq5Hz9kmH/CFm3@d1>
X-Mailer: Mew version 6.8 on Emacs 24.5.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSS-9.1.0.1373-9.0.0.1002-27080.006
X-TM-AS-Result: No--16.628-5.0-31-10
X-imss-scan-details: No--16.628-5.0-31-10
X-TMASE-Version: IMSS-9.1.0.1373-9.0.1002-27080.006
X-TMASE-Result: 10--16.627800-10.000000
X-TMASE-MatchedRID: rNgn9H0RAIJCXIGdsOwlUu5i6weAmSDKYawhvkuLgj40C8Dp8kkTtXS/ VNg23pNaZrChzCJ9VmxSOBg59F2OIRwoVh4OYIxqGqSG/c50XgPUoMiU4Mi75bwHu+XsbkzRvjN 9OkaN1tpZDclrwEPGsGLefidyCJTeu7PzMYLlcQcIoUOTWQl7EvSzAdIVxUnoj2iyfwmt0k8is0 tdGfxeOC1nJ+L5JsdT1i1obzNdfwMmheAqCMdRdd9JA2lmQRNUIfyQNHR2naabKItl61J/yfmS+ aPr0Ve8oTCA5Efyn8BJBCh8s9UcDWc9AABlmIKioOaKLxFhZimOhzOa6g8KreUc8BXtsQeCNtbb 3zKoyjryKYhJWnliDuaLUDZGZWrStGs2ZWrgCeA=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/l3nLuAtM_vISxTeloJdaXpFZeb4>
Subject: Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2022 09:08:01 -0000
> From: Mukund Sivaraman <muks@mukund.org> > Subject: Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation > Date: Tue, 16 Aug 2022 10:58:04 +0530 > On Tue, Aug 16, 2022 at 01:07:34PM +0900, Kazunori Fujiwara wrote: >> Thanks very much for your review. >> >> > From: "touch@strayalpha.com" <touch@strayalpha.com> >> > Some comments: >> > IP fragmentation is controlled at both the system (as a default for all new sockets) and per-socket level; this should >> > be discussed. >> > >> > I disagree with “MAY probe to find path MTU”; IMO, they SHOULD. >> >> I will consider changing to "SHOULD" at recommendations to UDP >> requestors (DNS clients). > > Some resolver implementations where possible turn off the effect of ICMP > v4 frag needed and v6 PTB messages to affect the kernel's PMTU cache (as > a blanket cover for possible vulnerabilities in this area). > > As an example, the resolvers in NIOS, BIND, Loop (all of which are BIND > or derived from BIND code) set the IP_PMTUDISC_OMIT and > IPV6_PMTUDISC_OMIT socket options to prevent how the Linux kernel uses > ICMP frag needed/PTB messages received over udp4/udp6 sockets > respectively to modify the PMTU for that peer. > > Would the SHOULD be satisfied by application layer fallback to smaller > advertised sizes (e.g., RFC 6891 section 6.2.5 fallback to lower > requestor payload sizes)? I meant "Yes". In section 2, "Path MTU discovery" | In this document, the term "Path MTU discovery" includes Classical | Path MTU discovery [RFC1191], [RFC8201], Packetization Layer Path MTU | discovery [RFC8899] and as well as similar methods. One of the "similar methods" was supposed to be how BIND 9 chooses EDNS requestors payload size, starting with 512 and larger, per IP address. If you have good idea, please propose good text. -- Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
- [DNSOP] Please review draft-ietf-dnsop-avoid-frag… Kazunori Fujiwara
- Re: [DNSOP] [Int-area] Please review draft-ietf-d… touch@strayalpha.com
- Re: [DNSOP] [Int-area] Please review draft-ietf-d… Kazunori Fujiwara
- Re: [DNSOP] [Int-area] Please review draft-ietf-d… Mukund Sivaraman
- Re: [DNSOP] [Int-area] Please review draft-ietf-d… Kazunori Fujiwara