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

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

> On Aug 27, 2021, at 1:28 PM, Alan DeKok <[e-mail]> 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
> 
> 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.

Done.


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


To fit this in I added a whole new subsection to History of DNS over TCP.
It might be more than you were expecting but I thought it would be helpful
to have the background on head-of-line blocking issues.

2.6.  Reuse, Pipelining, and Out-of-Order Processing

   The idea that a TCP connection can support multiple transactions goes
   back as far as [RFC0883], which states: "Multiple messages may be
   sent over a virtual circuit."  Although [RFC1035], which updates the
   former, omits this particular detail, it has been generally accepted
   that a TCP connection can be used for more than one query and
   response.

   [RFC5966] clarified that servers are not required to preserve the
   order of queries and responses over any transport.  [RFC7766], which
   updates the former, further encourages query pipelining over TCP to
   achieve performance on par with UDP.  A server that sends out-of-
   order responses to pipelined queries avoids head-of-line blocking
   when the response for a later query is ready before the response to
   an earlier query.

   However, TCP can potentially suffer from a different head-of-line
   blocking problem due to packet loss.  Since TCP itself enforces
   ordering, a single lost segment delays delivery of data in any
   following segments until the lost segment is retransmitted and
   successfully received.



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

This part of section 6 now says:

   Applications
   that capture network packets (e.g., with libpcap [libpcap]) SHOULD
   implement and perform full TCP segment reassembly.  Furthermore, as
   with real TCP, such applications need to protect themselves from
   resource exhaustion attacks by limiting the amount of memory
   allocated to tracking unacknowledged connection state data.


FYI we are tracking this in github at https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/6/files if that is helpful.

DW