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

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 3 Dec 2021 23:57:00 +0000

> On Nov 29, 2021, at 11:51 PM, Lars Eggert <[email-masked]> wrote:
> 
> 
>> I dont necessarily agree that operating systems alone do a very good job
>> of preventing DOS conditions.  It is possible that Im not up-to-date on
>> the latest and greatest in terms of operating system features, but I think
>> historically applications have fared better when they manage their own
>> connections.  For example, can we realistically expect the OS to know which
>> idle connections should be closed?
> 
> The OS will certainly try to close sufficient connections under DDoS to remain operational. But if an application wants to see connections closed according to a certain policy - and DNS servers probably would - they need to actively engage. Maybe that's the rationale here?
> 

Yes, that is the rationale.  I’ve added a new sentence to the end
of this paragraph along those lines:

   Operators of DNS server software SHOULD be aware that operating
   system and application vendors MAY impose a limit on the total number
   of established connections.  These limits may be designed to protect
   against DDoS attacks or performance degradation.  Operators SHOULD
   understand how to increase these limits if necessary, and the
   consequences of doing so.  Limits imposed by the application SHOULD
   be lower than limits imposed by the operating system, so that the
   application can apply its own policy to connection management, such
   as closing the oldest idle connections first.

>> 
>>> Section 4.2. , paragraph 3, comment:
>>>> DNS server software SHOULD provide a configurable timeout for idle
>>>> TCP connections.  For very busy name servers this might be set to a
>>>> low value, such as a few seconds.  For less busy servers it might be
>>>> set to a higher value, such as tens of seconds.
>>> 
>>> Ditto.
>> 
>> In this case all of the open source implementations I surveyed have this
>> limit enabled by default.
> 
> It might be useful to add a brief note similar to the one above here as well.

Okay, I’ve done so in this paragraph. Second and third sentences are new:

   DNS server software SHOULD provide a configurable timeout for idle
   TCP connections.  This can be used to free up resources for new
   connections and to ensure that idle connections are eventually
   closed.  At the same time, it possibly limits client performance
   while leaving some TCP resources untilizied.  For very busy name
   servers this might be set to a low value, such as a few seconds.  For
   less busy servers it might be set to a higher value, such as tens of
   seconds.  DNS clients and servers SHOULD signal their timeout values
   using the edns-tcp-keepalive option [RFC7828].

> Thanks,
> Lars

Thank you!

DW

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 23 Dec 2021 10:28:48 -0800

Hi Duane,

On Mon, Nov 29, 2021 at 11:53:48PM +0000, Wessels, Duane wrote:
> 
> 
> > On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker <[email-masked]> wrote:
[...]
> >>   DNS server software MAY provide a configurable limit on the number of
> >>   transactions per TCP connection.
> > 
> > What does that limit protect against?
> 
> proposed new text:
> 
>    DNS server software MAY provide a configurable limit on the number of
>    transactions per TCP connection.  This can help protect against
>    unfair connection use (e.g., not releasing connection slots to other
>    clients) and network evasion attacks.
> 
> 
> > 
> > Section 4.2. , paragraph 2, comment:
> >>   Similarly, DNS server software MAY provide a configurable limit on
> >>   the total duration of a TCP connection.
> > 
> > What does that limit protect against?
> 
> 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.

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.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Dec 2021 10:02:41 -0800

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,
> > 
> >> ...
> not duane, but...
> ...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

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 29 Dec 2021 21:25:40 +0000

> On Dec 23, 2021, at 10:28 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> 
> Hi Duane,
> 

Hi Ben,

Yes, network evasion attack has the same meaning here: An application that
does packet capture can miss some DNS messages if it doesnt implement TCP
stream reassembly, or implements it imperfectly.

I will say that I'm not adamant about including evasion attacks here.  It
may be a bit of a stretch.  I guess I tend to think of packet stream
reassembly somewhat probabilistically, in that unless the implementation
and conditions are perfect, the longer that a TCP session lasts then the
more likely it is to miss data.

If the DNS operator knows that their capture-based monitoring is not
perfect, then they may want to limit TCP sessions either by transaction
count or by time.  Similarly, they might know that packet capture drops/loss
in the system could affect stream reassembly.

Maybe this isn't really a network evasion attack, but rather just a workaround
for a poor implementation, and really argues against capture based monitoring.
I'm happy to remove it if it doesnt make sense.

DW