Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

Jim Reid <jim@rfc1035.com> Fri, 19 March 2021 14:23 UTC

Return-Path: <jim@rfc1035.com>
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 3F3BD3A1658 for <dnsop@ietfa.amsl.com>; Fri, 19 Mar 2021 07:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz8Jhz7HkPva for <dnsop@ietfa.amsl.com>; Fri, 19 Mar 2021 07:23:06 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2663A1654 for <dnsop@ietf.org>; Fri, 19 Mar 2021 07:23:05 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 34D8E2420C28 for <dnsop@ietf.org>; Fri, 19 Mar 2021 14:22:56 +0000 (UTC)
From: Jim Reid <jim@rfc1035.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Date: Fri, 19 Mar 2021 14:22:52 +0000
References: <20210315.131604.152003594194628775.fujiwara@jprs.co.jp> <5AB6AF96-F099-4F9F-812A-2C42C1934FF1@rfc1035.com> <YFQPq6tlvJFiUet/@straasha.imrryr.org>
To: dnsop@ietf.org
In-Reply-To: <YFQPq6tlvJFiUet/@straasha.imrryr.org>
Message-Id: <6AC59AD5-D127-4715-855A-B03161992AE6@rfc1035.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ToL13KrV9Rj2OSul3ST2abYRnV4>
Subject: Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 19 Mar 2021 14:23:08 -0000

On 19 Mar 2021, at 02:42, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> On Mon, Mar 15, 2021 at 05:38:40PM +0000, Jim Reid wrote:
> 
>> Measuring the MTU to well-known locations on the Internet won’t be
>> appropriate for some use cases. For instance inside private nets that
>> aren’t connected to the Internet or for forwarding-only servers that
>> never query an authoritatve server.
> 
> Right, the forwarding-mostly (or only) servers should just measure the
> PMTU to the relevant upstream(s).

The current draft says nothing about this. I’m suggesting it should.

>> IMO it’s a bad idea to recommend specific servers that could be the
>> target for those PMTU probes. [Suppose those names change one day -
>> unlikely for the above but you never know.] That could become a vector
>> of (D)DoS attacks - probably not on the above name servers themselves
>> but on the access routers in front of them that might well be
>> rate-limiting ICMP packets.
> 
> I don't see the DDoS, such measurements should be rather infrequent, in
> particular, I don't see why these would be much more frequent than root
> zone priming queries, which full service resolvers do routinely at
> startup.

The PMTU probing rate could well end up being broadly similar to the rate of priming queries to the root. However those priming queries are almost certainly not going to result in ICMP responses. Which usually take a different code path through routers and get rate-limited. Which means PMTU probing could be a vector for (D)DoS attacks: not on the well-known authoriatative name servers but the access routers and firewalls in front of them.

>> This could get nasty with icky CPE
>> firmware: imagine every home router in (say) Comcast’s net doing PMTU
>> to the same root server.
> 
> These would generally not all boot up at the same time, and would be
> expected to be configured in forward-only mode to the relevant Comcast
> iterators.

It’s unwise to make these assumptions. Besides, Comcast’s net and CPE configuration isn’t the only game in town.