Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

Mark Andrews <marka@isc.org> Thu, 16 July 2020 03:12 UTC

Return-Path: <marka@isc.org>
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 E47133A0AE5 for <dnsop@ietfa.amsl.com>; Wed, 15 Jul 2020 20:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 hS9IMJXTL06D for <dnsop@ietfa.amsl.com>; Wed, 15 Jul 2020 20:12:50 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0503A0AE7 for <dnsop@ietf.org>; Wed, 15 Jul 2020 20:12:50 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3FD0C3AB001; Thu, 16 Jul 2020 03:12:50 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2B112160043; Thu, 16 Jul 2020 03:12:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EBE0B160055; Thu, 16 Jul 2020 03:12:49 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Esoc4Mu1sGlX; Thu, 16 Jul 2020 03:12:49 +0000 (UTC)
Received: from [1.0.0.3] (unknown [49.2.181.130]) by zmx1.isc.org (Postfix) with ESMTPSA id DDFF0160043; Thu, 16 Jul 2020 03:12:48 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CABzX+qx5+_OUNUNfX8i32iLj_RQWthdQ_KZ_aKXjKjh0L-9U_Q@mail.gmail.com>
Date: Thu, 16 Jul 2020 13:12:45 +1000
Cc: fujiwara@jprs.co.jp, paul@redbarn.org, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <67FB359B-77D2-421C-A0A7-CD2CF8C772E7@isc.org>
References: <159351340969.9763.13693079622434674195@ietfa.amsl.com> <20200708.170123.2054449579631699570.fujiwara@jprs.co.jp> <CABzX+qw11H1JSWT6_EcVirT1LNd9Sxqm4zEyjSrDEqc3j2Cgbg@mail.gmail.com> <BE0E6F2E-3148-42DF-AA94-D8F5D9556055@isc.org> <CABzX+qx5+_OUNUNfX8i32iLj_RQWthdQ_KZ_aKXjKjh0L-9U_Q@mail.gmail.com>
To: Marek Majkowski <majek04@gmail.com>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hKFmQ4pomi6iVMu3xsaGfNmpKOI>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt
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: Thu, 16 Jul 2020 03:12:52 -0000


> On 10 Jul 2020, at 01:34, Marek Majkowski <majek04@gmail.com> wrote:
> 
> On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews <marka@isc.org> wrote:
>>> I have two problems with this proposal. First, it doesn't mention IPv4
>>> vs IPv6 differences at all. In IPv4 landscape fragmentation, while a
>>> security issue, is generally fine. In the IPv6 world, fragmentation is
>>> disastrous - packets with extension headers are known to be dropped.
>> 
>> Not really. UNKNOWN extensions tend to get dropped but the fragmentation
>> header is a KNOWN extension header.
> 
> https://labs.apnic.net/presentations/store/2019-09-11-ipv6-fail.pdf
> 
> Slide 34 and 35 indicate, with IPv6:
> - 38% recursive resolvers fail to reassemble packets with
> fragmentation extension header

Which means 62% of the world properly handles fragmented UDP packets.

Also I forget how Geoff was actually performing the test.  Where any of
the responses greater than the advertised EDNS buffer size sent?  Was
fragmentation introduced when the UDP response size was less that 1280?

> - 22% of browsers fail to process TCP packets with fragmentation header

Which seems to be a very strange test to perform given that TCP segments
are supposed to be atomic on IPv6.

> This data is from 2017 - around that time I did similar experiments
> with similar results. Delivery of fragmented packets in IPv6 sometimes
> work, but this is more of an exception than a rule.
> 
>>> Second, this proposal assumes that path MTU detection works correctly.
>>> This is surprisingly optimistic. Let's consider IPv6 - in IPv6 the
>>> smaller path MTU < 1500 is very common.
>> 
>> Which is why IPV6_USE_MIN_MTU exists (RFC 3542).  USE THE SOCKET OPTION.
>> It was put there specifically to support DNS over UDP and other applications
>> like that.  I know this as I proposed the predecessor option back in 1999
>> which became IPV6_USE_MIN_MTU.
> 
> You are suggesting to always use at most 1280 byte packets in IPv6.
> The draft we are discussing does not suggest that. Did I misunderstand
> something?

I’m suggesting that if you send UDP/IPv6 packets > 1280 that you force them to be
fragmented into 1280 octet fragments.

I’m suggesting that we force DNS/TCP/IPv6 packets to never be bigger that 1280 for
regular requests.  AXFR/IXFR would be a potential exception.  Clients and servers
can do this by setting the MSS to an appropriate value (1280-IPv6 header size-TCP
header size).  Setting IPV6_USE_MIN_MTU should also achieve this as TCP is supposed
to take into account path MTU which is 1280 when this option is set.

The IETF has designed IPv6 such that it is possible to run a DNS server that
will never receive a ICMPv6 PTB to traffic it sends even if other applications
on the server do.

> Marek

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org