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

From: John Scudder via Datatracker <[email-masked]>
Date: Thu, 28 Oct 2021 06:42:09 -0700

John Scudder has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/

----------------------------------------------------------------------
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.

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?

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 28 Oct 2021 14:16:52 +0000

Hi John!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of John Scudder via Datatracker
> Sent: Thursday, October 28, 2021 9:42 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; dnsop-
> [email-masked]; [email-masked]
> Subject: John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-
> 13: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 

[snip]
 
> capture (and log, etc) the bytestream that was segmented and transmitted by

I'll let the authors speak to this, but I think this means full TCP stream reassembly -- that is analyze, the reassembled stream, not the individual packets.  There is a long history of evasion attacks in network security analysis tools when individual fragments/packets are analyzed instead of the reassembled streams.

Roman

---

From: John Scudder <[email-masked]>
Date: Thu, 28 Oct 2021 15:21:09 +0000

On Oct 28, 2021, at 10:16 AM, Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:

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?

Right, that makes sense. It’s just not at all clear (at least, to me) from the text as written. I think more words will be required in order to make it clear. (Your sentence above seems like a good candidate for cutting and pasting.)

Thanks,

—John

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 28 Oct 2021 17:53:57 +0000

> On Oct 28, 2021, at 7:16 AM, Roman Danyliw <[email-masked]> wrote:
> 
> 
> [snip]
> 

Thanks Roman, yes that is the intention.  “Segment reassembly” is poor phrasing.

I’ve seen (and probably even written) packet capture applications that only look at the first packet of a DNS over TCP conversation, or assumed that each TCP packet contains a separate DNS message.  This statement is directed at those types of shortcuts.

DW