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

["Wessels, Duane" <[e-mail]>]

> On Dec 23, 2021, at 10:28 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> 
> 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 <[e-mail]> wrote:
> [...]
>>> Section 4.2. , paragraph 3, comment:
>>>>  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
> 

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