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

Mukund Sivaraman <muks@mukund.org> Tue, 14 April 2020 21:59 UTC

Return-Path: <muks@mukund.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 CBA7C3A1118; Tue, 14 Apr 2020 14:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=mukund.org
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 QNqvk44nITlc; Tue, 14 Apr 2020 14:59:07 -0700 (PDT)
Received: from jupiter.mukund.org (jupiter.mukund.org [IPv6:2a01:4f8:231:3f69::9e]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4173A1117; Tue, 14 Apr 2020 14:59:02 -0700 (PDT)
Received: from localhost (unknown [60.243.85.249]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by jupiter.mukund.org (Postfix) with ESMTPSA id 04693E20627; Tue, 14 Apr 2020 21:58:58 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1586901540; bh=FR+1Ri/PJW9DCDjYEM0DfqSwQd98s+zQv5HCdRBLYFk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Kk4HmjXBUb0Z0RUacB1/ykuA/tIPYQGCMtUNrX08UaWRz5kkENyx7IY2X/YcPNxip VpBQsSN6nKB0iGY4/1fwg/0R5YjrSKle93O8Vfd6sll+4sWba5iWlqofy8vIZ3q5TY mHTttoVRttRjyVYxLbDZeV1gKIzSHHpYqi7taVRc=
Date: Wed, 15 Apr 2020 03:28:55 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
Message-ID: <20200414215855.GA464850@jurassic.vpn.mukund.org>
References: <CADyWQ+GECV6aaeKxp-ObgsK0Ax3KN_5hAaYgmXQhssJ1A00Ttw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADyWQ+GECV6aaeKxp-ObgsK0Ax3KN_5hAaYgmXQhssJ1A00Ttw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/W8sm7E2LQusMvgkZHPTWfn3gVpQ>
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 21:59:10 -0000

Hi Fujiwara san and Vixie san,

On Tue, Apr 14, 2020 at 11:47:56AM -0400, Tim Wicinski wrote:
> This starts a Call for Adoption for draft-fujiwara-dnsop-avoid-fragmentation
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.

I support adoption.

A quick read through the current revision, and some review notes:

> 1.  Introduction
 
>    As a result, we cannot trust fragmented UDP datagrams, primarily due
>    to the small amount of entropy provided by UDP port numbers and DNS
>    message identifiers, each of which being only 16 bits in size.  By
>    comparison, TCP is considered resistant against IP fragmentation
>    attacks because TCP has a 32-bit sequence number and 32-bit
>    acknowledgement number in each segment.  In TCP, fragmentation should
>    be avoided for performance reasons, whereas for UDP, fragmentation
>    should be avoided for resiliency and authenticity reasons.

Isn't the 16-bit ID field in the IPv4 header the actual reason that we
cannot trust fragmented UDP datagrams? The secondary (following) IPv4
packet fragments don't contain the UDP and DNS headers, so would the UDP
and DNS header field sizes matter?

Isn't TCP resistant because it is performed in a manner that does not
cause IP fragmentation? (e.g., see section 4.1 of
draft-ietf-intarea-frag-fragile-17).

> 3.  Proposal to avoid IP fragmentation in DNS

>    TCP avoids fragmentation using its Maximum Segment Size (MSS)
>    parameter, but each transmitted segment is header-size aware such
>    that the size of the IP and TCP headers is known, as well as the far
>    end's MSS parameter and the interface or path MTU, so that the
>    segment size can be chosen so as to keep the each IP datagram below a
>    target size.  The takes advantage of the elasticity of TCP's
>    packetizing process as to how much queued data will fit into the next
>    segment.  In contrast, DNS has no message size elasticity and lacks
>    insight into IP header and option size, and so must make more
>    conservative estimates about available UDP payload space.

"In contrast, DNS over UDP has no datagram size elasticity ..."

>    The minimum MTU for and for an IPv6 interface is 1280 octets (see
>    Section 5 of [RFC8200]).

s/The minimum MTU for and for an IPv6 interface/The minimum MTU for an IPv6 interface/ ?

> 6.  Request to zone operator and DNS server operator

>    o  Use 'minimal-responses' configuration: Some implementations have
>       'minimal responses' configuration that enables that DNS servers
>       make response packets smaller, mandatory and required data only.

.. and continued in the follow-up text in section 7.2 (DNS packet size):

This text appears to discourage extraneous RRsets in DNS responses. I've
supported this and made implementation changes towards it as they
require more processing per client query.

There were multiple drafts in the last few years proposing myriad ideas
of EDNS0 option and non-option mechanisms to get the server to return
multiple answers and related RRsets within a single response.

Would this draft contradict such drafts, and discourage unnecessary
RRsets in responses (that the server may think may be useful to the
client, but generally is not used)?

		Mukund