Re: [DNSOP] Call for Adoption: draft-fujiwara-dnsop-avoid-fragmentation

Paul Vixie <paul@redbarn.org> Tue, 14 April 2020 17:44 UTC

Return-Path: <paul@redbarn.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 98E373A0829; Tue, 14 Apr 2020 10:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ArWTaGKQD4OZ; Tue, 14 Apr 2020 10:44:20 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC86C3A080E; Tue, 14 Apr 2020 10:44:19 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B05B6B074A; Tue, 14 Apr 2020 17:44:19 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Tim Wicinski <tjw.ietf@gmail.com>, dnsop@ietf.org
Cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, Paul Wouters <paul@nohats.ca>
Date: Tue, 14 Apr 2020 17:44:18 +0000
Message-ID: <1735330.BsMnFUdyVo@linux-9daj>
Organization: none
In-Reply-To: <alpine.LRH.2.21.2004141329180.28470@bofh.nohats.ca>
References: <CADyWQ+GECV6aaeKxp-ObgsK0Ax3KN_5hAaYgmXQhssJ1A00Ttw@mail.gmail.com> <alpine.LRH.2.21.2004141329180.28470@bofh.nohats.ca>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5tVnCXW2j8HHBl-FA8mj0lZ3Ydo>
Subject: Re: [DNSOP] Call for Adoption: draft-fujiwara-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: Tue, 14 Apr 2020 17:44:22 -0000

On Tuesday, 14 April 2020 17:32:54 UTC Paul Wouters wrote:
> On Tue, 14 Apr 2020, Tim Wicinski wrote:
> > This starts a Call for Adoption for
> > draft-fujiwara-dnsop-avoid-fragmentation
> > 
> > ...
> > 
> > We are looking for *explicit* support for adoption.
> 
> I am in favour of adoption.
> 
> > Please also indicate if you are willing to contribute text, review, etc.
> 
> I am willing to contribute text and review.

ty!

> What I find missing is some text to explain that this is only a problem
> for legacy DNS not using DNSSEC[*] and perhaps even mention that when
> resolvers are setting the +DO flag, then fragmentation should still be
> avoided, but that this is no longer a security issue.
> 
> I think it is important to point out (again) that this issue would have
> been a non-issue if people deploy DNSSEC. If we don't keep hammering
> that down, people keep being misguided into believing DNSSEC is
> optional and a matter of personal taste.

that view, while agreeable, is also very narrow. the draft references three 
sources related to cache poisoning and dnssec:

>    [Fujiwara2018]
>               Fujiwara, K., "Measures against cache poisoning attacks
>               using IP fragmentation in DNS", OARC 30 Workshop , 2019.
>    
>    [Herzberg2013]
>               Herzberg, A. and H. Shulman, "Fragmentation Considered
>               Poisonous", IEEE Conference on Communications and Network
>               Security , 2013.
>    
>    [Hlavacek2013]
>               Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67
>               Meeting , 2013, <https://ripe67.ripe.net/
>               presentations/240-ipfragattack.pdf>.

however, the motivation for this draft is inclusive but not exclusive of those 
sources. see for example:

>    [I-D.ietf-intarea-frag-fragile]
>               Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
>               and F. Gont, "IP Fragmentation Considered Fragile", draft-
>               ietf-intarea-frag-fragile-17 (work in progress), September
>               2019.

and also:

Fragmentation Considered Harmful, Kent, C., Mogul, J., December 1978
https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf

---

what's at issue for fragments and fragmentation is that inter packet gap 
introduced for rate limiting so as to avoid congestion in a UDP-spewing 
service like NFS or DNS, there is no way to avoid microbursts which occur 
below the kernel. thus a steady-state equilibrium maintained with usleep() can 
be fatally upset when fragmentation occurs. this would be true even if PMTUD6 
had actually worked.

we have to never fragment. this draft specifies IP_DONTFRAG and IP6_DONTFRAG 
for that reason. and it's because of that recommendation, it becomes vital 
that we not copy/paste magic numbers like "1232" but rather make a considered 
decision as to what the response size ought to be, assuming that the PMTU is 
either 1500, or something smaller represented by the interface's MTU.

-- 
Paul