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

[Benjamin Kaduk <[e-mail]>]

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.

-Ben