Re: [DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes

Lanlan Pan <abbypan@gmail.com> Sat, 22 July 2017 13:19 UTC

Return-Path: <abbypan@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 A6D31129AD1 for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 06:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (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 qUrU0exnUSjo for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 06:19:36 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 936DE127058 for <dnsop@ietf.org>; Sat, 22 Jul 2017 06:19:36 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id t2so37814447qkc.1 for <dnsop@ietf.org>; Sat, 22 Jul 2017 06:19:36 -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=XPsAUAjd+ZmE3+vZ5sDB2XhapYfbKeVj2zPP3e8HdDk=; b=D2lgNgAngpvhcZjWYBBzPNmaH5R7vqHMakFcq4lxyiZ3jhYnY6juCo798juREmnEvM fmYON3LcnBkiBTm5BFlFOtfCJNqz9GNyCuZwcnfhgKL9QpeJzkujgKs6B7KwTmvyU/j9 SKlmyM5Bh8xVTqUczkocQ2PClbjSi6cTJjyCxCvqeOajYrp3npJ/KdW3qPxxa3hHAM+u k6hsNYEu5MaBBFUCRJMV7R3ZplQC9NtSCiMxZXyx0SQF9x9wCWXoyRhmuj7gXhKgUimQ 2V5IIr9J2eGI3ysBPAICFMffiPWxDXTb3YufwL2tFSZPL2oukdvHdxmzhotRjK24bfbp geUA==
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=XPsAUAjd+ZmE3+vZ5sDB2XhapYfbKeVj2zPP3e8HdDk=; b=bCFDtU66tPMs6k8c3I4gJPI/Ls0ijO9kJB+jwhHVR4HzrLMJFc8puN45oKWR74AzAQ JHiOg6PWFvlp4n0gyQ5fTDqKsiyjJXCpwVcYIZbDI4G/OHJXMhefn8KG4pdHN7afZGJ0 FDv8WzBVbll5uFBR/E1RBYmqY740C8h04+3g0O6rVHAlw7/EVcJ23BMaC4NQ3unsT0dD +2FodXFbdhc0mmr/8xSnFyQnV6ZgII1oqoKp2lVX9RBide2VUDjyaCjxzxgZYhFYPZfq ax6L0TsSEJsBzzR4Jg4kTgl8WIK9TG0VzK1NTRuL4n63uHAFr1825EFiJRnSMa9Nimyl 13FA==
X-Gm-Message-State: AIVw111xuDk1sEg+5s6lHguGYq31c3gYafK2xdoftaHvdUFXvdnKT80o 4irMtMZ/44pwOXOyq05R6kOr8qIU9q8M
X-Received: by 10.55.217.215 with SMTP id q84mr1528034qkl.186.1500729575680; Sat, 22 Jul 2017 06:19:35 -0700 (PDT)
MIME-Version: 1.0
References: <1686897744.6421.1500568893614.JavaMail.zimbra@nic.cz>
In-Reply-To: <1686897744.6421.1500568893614.JavaMail.zimbra@nic.cz>
From: Lanlan Pan <abbypan@gmail.com>
Date: Sat, 22 Jul 2017 13:19:25 +0000
Message-ID: <CANLjSvUTOj_=3eG4WZEyVegjNLPOe4OMfj555+rkoMYiyYVg4g@mail.gmail.com>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej.sury@nic.cz>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a1147a3004330090554e7d5e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ugPkLxoua5J8F3QNM5TgTiN0BFE>
Subject: Re: [DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes
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: Sat, 22 Jul 2017 13:19:39 -0000

+1

Avoid UDP fragmentations (big response packet) on protocol level could
reduce DDoS defense cost.

Similar to the DNS ANY qtype deprecation.

Ondřej Surý <ondrej.sury@nic.cz>于2017年7月21日周五 上午12:41写道:

> multi-qtypes Security Considerations says:
> >    The method documented here does not change any of the security
> >    properties of the DNS protocol itself.
>
> I don't think this statement is true.  Why?
>
> a) DNS DDoS threats are real and there was a shift towards minimizing
>    answers.  This goes in the reverse direction.  But you address this
>    in both security considerations.
>
> multiple-responses Security Considerations says:
> >
> >    Additional records will make DNS responses even larger than they are
> >    currently, leading to larger records that can be used in DNS
> >    reflection attacks.  One could mitigate this by only serving
> >    responses to EXTRA requests over TCP or when using Cookies [RFC5395],
> >    although there is no easy way to signal this to a client other than
> >    through the use of the truncate bit.
>
> multi-qtypes Security Considerations says:
> >    It should however be noted that this method does increase the
> >    potential amplification factor when the DNS protocol is used as a
> >    vector for a denial of service attack.
>
>
> b) UDP fragmentations - it strongly increases the risk of UDP fragmentation
>    which is strongly discouraged (SHOULD NOT) in BCP 145.
>
> also multiple-responses Security Considerations says:
>
> >    A malicious authoritative server could include a large number of
> >    extra records (and associated DNSSEC information) and attempt to DoS
> >    the recursive by making it do lots of DNSSEC validation.  However,
> >    this is not considered a realistic threat; CPU for validation is
> >    cheap compared to bandwidth.  This can be mitigated by allowing the
> >    recursive resolver to ignore Additional records whenever it considers
> >    itself under attack or its CPU resources are otherwise over-
> >    committed.
>
> It should be noted, that ECC validation is more CPU intensive than RSA, as
> as such I find "CPU for validation is cheap compared to bandwidth" quite
> bold claim that should come with some data.
>
> Cheers,
> --
>  Ondřej Surý -- Technical Fellow
>  --------------------------------------------
>  CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
>  Milesovska 5, 130 00 Praha 3, Czech Republic
>  mailto:ondrej.sury@nic.cz    https://nic.cz/
>  --------------------------------------------
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan