Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Fri, 24 December 2021 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFD4A3A0E60; Fri, 24 Dec 2021 10:03:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IZozWggQmCzO; Fri, 24 Dec 2021 10:03:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E7F83A0E62; Fri, 24 Dec 2021 10:03:05 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 1BOI2fhe028741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Dec 2021 13:02:49 -0500
Date: Fri, 24 Dec 2021 10:02:41 -0800
From: Benjamin Kaduk <>
To: Paul Vixie <>
Cc: "Wessels, Duane" <>, "" <>, "" <>, Suzanne Woolf <>, The IESG <>, "" <>, Lars Eggert <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Dec 2021 18:03:09 -0000

Hi Paul,

On Thu, Dec 23, 2021 at 06:48:24PM +0000, Paul Vixie wrote:
> Benjamin Kaduk wrote on 2021-12-23 10:28:
> > Hi Duane,
> > 
> > On Mon, Nov 29, 2021 at 11:53:48PM +0000, Wessels, Duane wrote:
> >> ...
> >>
> >> Proposed new text:
> >>
> >>     Similarly, DNS server software MAY provide a configurable limit on
> >>     the total duration of a TCP connection.  This can help protect
> >>     against unfair connection use, slow read attacks, and network evasion
> >>     attacks.
> not duane, but...
> > Maybe I'm just being dense today, or lost too much state in the intervening
> > weeks, but how do these limits protect against network evasion attacks?
> > What are "network evasion attacks" in this context, anyway?  The draft
> > references [phrack] in a different location surrounding use of that term,
> > in the context of applications doing TCP stream reassembly from packet
> > captures.  In that location it seems that the TCP segmentation could cause
> > the reassembling application to miss actual DNS protocol messages, but I'm
> > not sure how transaction or time limits on a connection would protect
> > against a similar loss of processing of DNS protocol messages by the
> > reassembling application.
> ...without commenting on the text itself, i'll speak to the question. 
> when a dns responder tries to accept more simultaneous tcp connections 
> than it has capacity for, some kind of error will occur. for example in 
> UNIX the "accept()" system call will fail in user mode, and a TCP RST 
> will be sent in kernel mode. this is nonconstructive from a systemic 
> point of view since the client is not being given enough information to 
> inform its "what now?" decision.
> this condition can be predicted, however, and handled more 
> constructively. as an example if the dns responder knows that it only 
> has some number of file descriptors available or that the kernel only 
> has some number of tcp protocol control blocks available, then it could 
> treat the last few of these "quota slots" specially. for example, saving 
> the last slot or the last 5% of slots for error pathways, and answering 
> SERVFAIL or some other error code rather than attempting any useful work.
> the trouble with state, whether tcp protocol control blocks or any 
> other, is that it must be finite, and can be attacked. "syn flood" 
> attacks are an example, because protection against these was possible by 
> creating more state. DNS RRL is another example of how adding state can 
> resist attacks. in every case we must be able to imagine the outcome of 
> an attack on the limited resource, and try to behave constructively.

Thanks for this; it helps me recover more of the background and paints a
good picture of why these limits are useful.

I'm still unclear on the connection to "network evasion attacks"
specifically, though -- which limited resource are such attacks targeting?
Maybe Duane can help with that.