Subject: [secdir] Secdir review of draft-ietf-dnsop-dns-tcp-requirements-12

From: Alan DeKok <[email-masked]>
Date: Fri, 27 Aug 2021 16:28:07 -0400

Reviewer: Alan DeKok
Review result: Has nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  Over all, I think this document is clear, useful and well written.

Section 1 says:

   ... Section 6.1.3.2 to clarify that all DNS resolvers and recursive MUST
   support and service both TCP and UDP queries.

NIT: bare "recursive" should perhaps be "recursive servers", to match similar text elsewhere in the document.

  It may be good to update Section 3 with notes on "head of line blocking".  This text could arguably be in RFC 7766, but having it here is a reasonable alternative:

   When using UDP as a transport for DNS, there is no ordering of
   packets.  If a packet is lost, that loss has no
   effect on subsequent packets sent by that client or server.

   Unlike UDP, TCP is subject to issues related to Head of Line (HoL)
   blocking.  This occurs when a TCP segment is lost and a subsequent
   TCP segment arrives out of order.  While the DNS implementation can
   process DNS packets out of order, the semantics of TCP makes this
   impossible.  This limitation can lower the maximum packet processing
   rate of DNS over TCP.

Section 6 says:

   Developers SHOULD also keep in mind connection reuse, query
   pipelining, and out-of-order responses when building and testing DNS
   monitoring applications.

  It would also be good to note that if the monitoring software tracks requests and responses, then clients could potentially attack the monitoring software, too.  i.e. by sending large volumes of requests to "black hole" IPs, which will never get a response.   So the monitoring software should have both timeouts for request/response tracking, and also limit the total number of request/responses which are monitored.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 27 Aug 2021 23:05:10 +0000

> On Aug 27, 2021, at 1:28 PM, Alan DeKok <[email-masked]> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> Reviewer: Alan DeKok
> Review result: Has nits

Thanks for the review Alan.

> NIT: bare "recursive" should perhaps be "recursive servers", to match similar text elsewhere in the document.

Yep, I'll make that change.

>   impossible.  This limitation can lower the maximum packet processing

Can you clarify by what you mean with "While the DNS implementation can
process DNS packets out of order, the semantics of TCP makes this impossible."
Do you mean in the case of a lost TCP segment, or in general?

I wonder if this might fit equally well under a new 2.x subsection.

>  It would also be good to note that if the monitoring software tracks requests and responses, then clients could potentially attack the monitoring software, too.  i.e. by sending large volumes of r…

Yes, thats a good point.  I will come up with some text for that.

DW

---

From: Alan DeKok <[email-masked]>
Date: Fri, 27 Aug 2021 21:31:00 -0400

> Do you mean in the case of a lost TCP segment, or in general?

  I mean that DNS has no inter-packet dependencies or ordering.  But when DNS is transported over TCP, TCP enforces ordering, because it's a stream protocol.

  If a client sends packets N, N+1, N+2 over UDP, then losing packet N has no impact on N+1 or N+2.  However, when TCP is used, the OS has to do TCP ACK signalling, and send packet N before N+1 or N+2 can be processed.

  That sequencing is a limitation of TCP, and not of DNS.  But it still affects DNS.

> I wonder if this might fit equally well under a new 2.x subsection.

  Sure.

  Alan DeKok.