> On Dec 23, 2021, at 10:28 AM, Benjamin Kaduk <ka...@mit.edu> 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 <nore...@ietf.org>
>>> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
