Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

Florian Weimer <fweimer@redhat.com> Mon, 25 September 2017 12:01 UTC

Return-Path: <fweimer@redhat.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 13C471342D8 for <dnsop@ietfa.amsl.com>; Mon, 25 Sep 2017 05:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 H6TRTb0nTy_d for <dnsop@ietfa.amsl.com>; Mon, 25 Sep 2017 05:01:56 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84831321A1 for <dnsop@ietf.org>; Mon, 25 Sep 2017 05:01:56 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2743C3D96F; Mon, 25 Sep 2017 12:01:56 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2743C3D96F
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com
Received: from oldenburg.str.redhat.com (ovpn-116-138.ams2.redhat.com [10.36.116.138]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 64A3570BA0; Mon, 25 Sep 2017 12:01:53 +0000 (UTC)
To: Paul Vixie <paul@redbarn.org>, =?UTF-8?B?RGF2ZXkgU29uZyjlrovmnpflgaUp?= <ljsong@biigroup.cn>
Cc: 'Davey Song' <songlinjian@gmail.com>, 'dnsop' <dnsop@ietf.org>, 'william manning' <chinese.apricot@gmail.com>
References: <150509601027.9852.16967877638602485585@ietfa.amsl.com> <CAAObRXJ6wJGCXkbKVkNmQCJ8NccBT63A8-9-LiRVZCFsDicchw@mail.gmail.com> <CACfw2hhaKTyfJfjQ5-_kfqiHX1oX+9P6mUWD06B87y_2ysdztA@mail.gmail.com> <045b01d33288$d3fadad0$7bf09070$@cn> <59C34510.4080705@redbarn.org>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <9e84000b-fc4e-b92d-58f2-186a3e0b9e65@redhat.com>
Date: Mon, 25 Sep 2017 14:01:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <59C34510.4080705@redbarn.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 25 Sep 2017 12:01:56 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yREuPkeO5iiko5tY4yyaXMVMfow>
Subject: Re: [DNSOP] =?utf-8?b?562U5aSNOiBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXNv?= =?utf-8?q?ng-atr-large-resp-00=2Etxt?=
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 25 Sep 2017 12:01:58 -0000

On 09/21/2017 06:50 AM, Paul Vixie wrote:
> both ideas are wrong. what we have to do is arrange to fragment, using 
> the ipv6 extension header, all ipv6 udp, for a period of not less than 
> five years. noone who blocks ipv6 extension headers should be able to 
> get reliable ipv6 udp services. we have to make this problem felt where 
> it is made. we must NOT work around it to insulate the makers of the 
> problem from the costs of their actions.

I disagree with this approach.  Just avoid fragmentation altogether.  We 
know that it's harmful and can be used to bypass existing DNS hardening 
features.  Within five or ten years, packet rates have increased so much 
that the additional protection afforded by the 32-bit reassembly ID in 
IPv6 isn't sufficient anymore, either.

IP fragmentation is dead.  Use something else.

Thanks,
Florian