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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
