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

Marek Majkowski <majek04@gmail.com> Thu, 09 July 2020 15:35 UTC

Return-Path: <majek04@gmail.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 B5C713A0CDC for <dnsop@ietfa.amsl.com>; Thu, 9 Jul 2020 08:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wWbdRDf6xClw for <dnsop@ietfa.amsl.com>; Thu, 9 Jul 2020 08:35:09 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5643A0CDA for <dnsop@ietf.org>; Thu, 9 Jul 2020 08:35:08 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id y18so1391114lfh.11 for <dnsop@ietf.org>; Thu, 09 Jul 2020 08:35:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4SrAEOr/0Q7vTamWpxoEvJ9e+8J5aIUMMmxLwa73qS8=; b=kuIHq24ZWe/b4yYIBS6UwlVtgdrmLzZqBNcbibQxwxhlejsz4S7d97bEJqzWoGaVFJ cBBLYc9hOFk5aPhWsTRbLnjO09UVzugVbSDCViqL5C0sUvL/sJnugvgYtudsGCFJLjXy aIDR85uxat99f2QvY9+9hJEcgTWUX2jhGcfB6UJvXlQ7hxIvLNCnQIB4vlrWRGwXbNO+ pO8SXdG/rG30iVDVv7S6yP8yfPnh9+9Am43cXNFJgUiV7iurvASZ9lsfgw43XLbQYXci aifB8VXykNcpFXPbWzDvNGwE3Sr8WqaGvAeYCt1DozVuFIoRKhdynhLPpr1r5C0g7zCj yctg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4SrAEOr/0Q7vTamWpxoEvJ9e+8J5aIUMMmxLwa73qS8=; b=ejSO4VWMthoAnHQwW+nNaBQtMKUFo28TO/RVqZXRKS+WBeblrwjqJWWPBaM1x/cT78 JnACQAWWu2r3/WodEtrhvuLIYp2T+Bih4HlWqv1OJNFU7WBXzBNBhN1V8G9JVmYG/C10 XAgLEuQFM3DebuRjJoNuK+VAjtZwr8+egFIMQCbJHOKQe0LCXqb0F2HSN7r2NdVfDmRv gOAA6AxczVprTV6+HKYT12e+8Yg7Gfs5iJS2IpBdLkLeHpEl2x9qkKQq6GU8t4yn+21i fBJ8ynIV8dXzoitf85OAhWFc6eYQbX2xJ3a/MUDJtS/GUIZjk+rVopekRRL3AI56opFy jIbw==
X-Gm-Message-State: AOAM532BJjvBFk0l1tL2Ks1faNgOqLkwj7uoqXrSl8p691hdoT7gKcgh KcfDzCVMqeAN/qf+jER/JSEFeRVh2s624z7HHpUk15Fw
X-Google-Smtp-Source: ABdhPJzoM2O08xGkPyKticYmASN8Hi872uPNY7+bzQcdQ5cYnfJmB8hELAASQMgbu5bvABcVr2z36dUtIwDnu1hwvtk=
X-Received: by 2002:a19:c8c2:: with SMTP id y185mr40539852lff.52.1594308906942; Thu, 09 Jul 2020 08:35:06 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <BE0E6F2E-3148-42DF-AA94-D8F5D9556055@isc.org>
From: Marek Majkowski <majek04@gmail.com>
Date: Thu, 9 Jul 2020 17:34:55 +0200
Message-ID: <CABzX+qx5+_OUNUNfX8i32iLj_RQWthdQ_KZ_aKXjKjh0L-9U_Q@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: fujiwara@jprs.co.jp, paul@redbarn.org, dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xDkDGBzMZ7Lq7IcOPB2xjo4X-0Q>
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, 09 Jul 2020 15:35:11 -0000

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
 - 22% of browsers fail to process TCP packets with fragmentation header

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?

Marek