IETF Logo Mail Archive

Re: [Int-area] [DNSOP] 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: int-area@ietfa.amsl.com
Delivered-To: int-area@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/int-area/_4QImdXwpW1laBWBguaqwqQZJyA>
Subject: Re: [Int-area] [DNSOP] Please review draft-ietf-dnsop-avoid-fragmentation
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-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>

v2.23.0 | Report a Bug | By Email