Re: [Int-area] draft-bonica-intarea-frag-fragile-01

"C. M. Heard" <heard@pobox.com> Fri, 01 June 2018 16:01 UTC

Return-Path: <heard@pobox.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8312DA08; Fri, 1 Jun 2018 09:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 EpMoXwoIcaBP; Fri, 1 Jun 2018 09:01:38 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404B212DA0D; Fri, 1 Jun 2018 09:01:38 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 1C08AEF677; Fri, 1 Jun 2018 12:01:35 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=O6iGBOdkZPxQjcplh4tgVVZYh8w=; b=etjOh4 mVe8sMCD5OSpf3gmJLYlpMudRREVLoYAYDy0dla0qsYP8abD0ID69sIKRUf83N+t 6whXd/A1d6cKZ8u6Oj1xxfr7flO0Gt7aJQEHp5CmYgN4B0g6fTBXdOcIf098LgFw rutSHnhHH65FzwS0YxDRa/wfbg4ZWO58wzQ6k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=hZSACCpaVr0aSU5w8fYIPzsSVLy9Ok+r i8yEBqNCHiio2ByNcBfxDol8KJRrXL4pmPQduE4lh6KHO1wjQVGxn4pl9TZ5eE11 CgHgQIqUvFeL+KSncmm6PN4jOfPDmdfWWYxWFyvIGJTsptqgaASYmcqb4pyyqIqR KeiI0HbStjo=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 11A92EF676; Fri, 1 Jun 2018 12:01:35 -0400 (EDT)
Received: from mail-oi0-f43.google.com (unknown [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 80EB1EF674; Fri, 1 Jun 2018 12:01:34 -0400 (EDT)
Received: by mail-oi0-f43.google.com with SMTP id b130-v6so22871079oif.12; Fri, 01 Jun 2018 09:01:34 -0700 (PDT)
X-Gm-Message-State: APt69E15j6PSMjRjfjFBJ/UGyDaF8sRFtu5uu38RUOZX1XzgdsCLCkDn s0/L4jMmiEA0ibg7XT/4GEtsxOAxhAjZmIEmyYQ=
X-Google-Smtp-Source: ADUXVKLBZ5C/8+9KWgMJVARY6wtgfhcZd71uPBxoDbjRdEQI/8qU0M+LITNpiAzGBdUgrth40oJNtXEJPMSelT/rNSU=
X-Received: by 2002:aca:4ed6:: with SMTP id c205-v6mr575334oib.254.1527868893979; Fri, 01 Jun 2018 09:01:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:88c6:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 09:01:13 -0700 (PDT)
In-Reply-To: <SN6PR05MB42403BB45F2E0E012C706D05AE630@SN6PR05MB4240.namprd05.prod.outlook.com>
References: <CACL_3VE8A-fEHDR0Bz=EhG0QVfvBqwfHeFgkOXbPXTAvjn75fg@mail.gmail.com> <SN6PR05MB42403BB45F2E0E012C706D05AE630@SN6PR05MB4240.namprd05.prod.outlook.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Fri, 01 Jun 2018 09:01:13 -0700
X-Gmail-Original-Message-ID: <CACL_3VFmfybY9Cp+i+ek76GYQDrDi5EV5j0MNSz2CO9F8CbjRQ@mail.gmail.com>
Message-ID: <CACL_3VFmfybY9Cp+i+ek76GYQDrDi5EV5j0MNSz2CO9F8CbjRQ@mail.gmail.com>
To: Ron Bonica <rbonica@juniper.net>
Cc: draft-intarea-frag authors <draft-bonica-intarea-frag-fragile@ietf.org>, int-area <int-area@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b068cf056d96b212"
X-Pobox-Relay-ID: 0EBAF9CE-65B5-11E8-90D6-67830C78B957-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/X2jmbEwu8zR9AfUxjqQxN_-MhFo>
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2018 16:01:50 -0000

On Thu, May 31, 2018 at 12:39 PM, Ron Bonica <rbonica@juniper.net> wrote:
>
> In Section 6.1, *DNS*, please note that draft-ietf-tsvwg-udp-options
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dudp-2Doptions&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=J_pOJLHC_gbCzzfyeW8omX8B8j4T6I07igUCmsA7vPg&s=l9Z0Kh7PKrF4seGUMRn2kViHzJspMRaoNPTKtZ62uIs&e=> may
> offer an *incrementally deployable* solution to the problem of oversize
> DNS responses. As far as I know, this specific use case is not yet
> documented in any I-D, but the basic idea is that a client would indicate
> its willingness to accept a UDP-fragmented response by including in its
> (unfragmented) request a UDP options trailer with the FRAG option as
> specified on page-15
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dudp-2Doptions-2D02-23page-2D15&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=J_pOJLHC_gbCzzfyeW8omX8B8j4T6I07igUCmsA7vPg&s=VyqM-WCNZiwxsDRAU9buCv7rxPTo9FyDxsWRLlwh_T8&e=>
>  of draft-ietf-tsvwg-udp-options. A server that does not implemented UDP
> options would ignore the options trailer and use IP-layer fragmentation for
> large responses; a server that implements UDP options would use UDP-layer
> fragmentation for large responses.
>
>
>
> RB> While I agree, such a recommendation might be overstepping my charter.
> Isn’t that a decision for another WG?
>

Fair enough. But it might be worth noting possible solutions, Let me offer
the following proposal for your consideration.

OLD:

   DNS Servers that execute DNSSEC [RFC4035
<https://tools.ietf.org/html/rfc4035>] procedures are more likely
   to generate large responses.  Therefore, when running over UDP, they
   are more likely to cause the generation of IPv6 fragments.  DNS's
   reliance upon IPv6 fragmentation is fundamental and cannot be broken
   without changing the DNS specification.


NEW:

   DNS Servers that execute DNSSEC [RFC4035
<https://tools.ietf.org/html/rfc4035>] procedures are more likely
   to generate large responses.  Therefore, when running over UDP, they
   are more likely to cause the generation of IPv6 fragments.  DNS's
   reliance upon IPv6 fragmentation is fundamental and cannot be fully
   eliminated without changing the DNS specification, e.g., by adding

   UDP or application layer fragmentation, or by measures such as those
   described in https://tools.ietf.org/html/draft-song-atr-large-resp.




> Section 4.4, *Security Vulnerabilities:* please cite RFC 3828 in addition
> to RFC 1858 in both places where the latter is cited.
>
>
>
> RB> Are you sure that you want me to reference 3828 (UDP lite)? I don’t
> see the connection.
>

 That was a typo. I meant RFC 3128 <https://tools.ietf.org/html/rfc3128>.
Sorry about that.

Mike Heard