Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

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

John, thanks for the review.


> On Oct 28, 2021, at 6:42 AM, John Scudder via Datatracker <[e-mail]> wrote:
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the well-written document!
> 
> A few comments --
> 
> 1. I have similar concerns to Ben's regarding the use of BCP as a vehicle to
> update the Standards Track documents in question. If I had a better option to
> offer at this stage in the document's history, I would, but under the
> circumstances I don't. If we had it to do over again, my preference would have
> been to progress a small PS to update the Standards Track documents, and a BCP
> to provide all the rest of the content. In addition to the points Ben made, my
> discomfort also stems from the fact that the advice regarding implementations
> has inherently short shelf life (relatively speaking) whereas the updates are
> forever (or at least until the updated documents are bis'd).
>   I'm not requesting any change with this observation, just putting it out
>   there for discussion (without making it a DISCUSS...).
> 
> 2. In Section 3, another +1 to Ben's comment. In particular the "lastly" part
> seemed especially loosy-goosy to me as written, as to what precisely is updated
> in RFC 1536. The flow of the prose is nice, but the conclusion is less than
> clear. I do think some rewrite of this section would be helpful.

Here’s how this part reads now:

   Lastly, Section 1 of [RFC1536] is updated to eliminate the
   misconception that TCP is only useful for zone transfers:

   OLD:

      DNS implements the classic request-response scheme of client-
      server interaction.  UDP is, therefore, the chosen protocol for
      communication though TCP is used for zone transfers.

   NEW:

      DNS implements the classic request-response scheme of client-
      server interaction.


> 3. Section 6 says applications should perform “full TCP segment reassembly”.
> What does that mean? A quick google search doesn’t suggest it’s a well-known
> term of art. I'm guessing that what you mean is that the applications should
> capture (and log, etc) the bytestream that was segmented and transmitted by TCP?

This has been updated as follows:

   Applications
   that capture network packets (e.g., with libpcap [libpcap]) SHOULD
   implement and perform full TCP stream reassembly and analyze the
   reassembled stream instead of the individual packets.  Otherwise,
   they are vulnerable to network evasion attacks [phrack].


DW