[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4358



IMPORTANT
S 5.3.
>      field set to zero, and MUST NOT elicit a response.
>   
>      Every DSO request message (QR=0) with a nonzero MESSAGE ID field is
>      an acknowledged DSO request, and MUST elicit a corresponding response
>      (QR=1), which MUST have the same MESSAGE ID in the DNS message header
>      as in the corresponding request.

How do I handle duplicate message IDs on the responder? Did I miss
where you said this? Is this just an error?


S 9.3.
>   
>      Requests to register additional new DSO Type Codes in the
>      "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert
>      Review [RFC8126].  At the time of publication of this document, the
>      Designated Expert for the newly created DSO Type Code registry is
>      [*TBD*].

What is the standard for the expert to follow

COMMENTS
S 1.
>      is appended to the end of the DNS message header.  When displayed
>      using packet analyzer tools that have not been updated to recognize
>      the DSO format, this will result in the DSO data being displayed as
>      unknown additional data after the end of the DNS message.  It is
>      likely that future updates to these tools will add the ability to
>      recognize, decode, and display the DSO data.

I'm sure you will get to this soon, but what are the backward
compatibility implications for the two endpoints.


S 3.
>      The unqualified term "session" in the context of this document means
>      the exchange of DNS messages over a connection where:
>   
>      o  The connection between client and server is persistent and
>         relatively long-lived (i.e., minutes or hours, rather than
>         seconds).

This is a surprising taxonomy. I would assume that some of the options
you are proposing would be relevant with a 30s connection (very long
by HTTP standards!)


S 3.
>      Where this specification says, "close gracefully," that means sending
>      a TLS close_notify (if TLS is in use) followed by a TCP FIN, or the
>      equivalents for other protocols.  Where this specification requires a
>      connection to be closed gracefully, the requirement to initiate that
>      graceful close is placed on the client, to place the burden of TCP's
>      TIME-WAIT state on the client rather than the server.

Does this mean that the server will ask the client to close?


S 3.
>      connection to be closed gracefully, the requirement to initiate that
>      graceful close is placed on the client, to place the burden of TCP's
>      TIME-WAIT state on the client rather than the server.
>   
>      Where this specification says, "forcibly abort," that means sending a
>      TCP RST, or the equivalent for other protocols.  In the BSD Sockets

Because you bother to mention TLS above, what about non-close_notify
TLS alerts?


S 3.
>      the server's listening socket.
>   
>      The terms "initiator" and "responder" correspond respectively to the
>      initial sender and subsequent receiver of a DSO request message or
>      unacknowledged message, regardless of which was the "client" and
>      "server" in the usual DNS sense.

Might be helpful to say earlier that this is a request/response
protocol


S 3.
>   
>      DNS Stateful Operations uses three kinds of message: "DSO request
>      messages", "DSO response messages", and "DSO unacknowledged
>      messages".  A DSO request message elicits a DSO response message.
>      DSO unacknowledged messages are unidirectional messages and do not
>      generate any response.

This would be useful further up.


S 5.1.
>   
>      DNS over plain UDP [RFC0768] is not appropriate since it fails on the
>      requirement for in-order message delivery, and, in the presence of
>      NAT gateways and firewalls with short UDP timeouts, it fails to
>      provide a persistent bi-directional communication channel unless an
>      excessive amount of keepalive traffic is used.

Note that this is going to make things not work super-well with DNS-
over-QUIC unless you use one stream only.


S 5.1.
>   
>      If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
>      ([TBA2] tentatively 11), then the client MUST assume that the server
>      does not implement DSO at all.  In this case the client is permitted
>      to continue sending DNS messages on that connection, but the client
>      SHOULD NOT issue further DSO messages on that connection.

Why is this a SHOULD and not a MUST?


S 5.1.3.
>      to any problems that could be result from the inadvertent replay that
>      can occur with zero round-trip operation.
>   
>   5.1.3.  Middlebox Considerations
>   
>      Where an application-layer middlebox (e.g., a DNS proxy, forwarder,

I'm having trouble with this section. Is it a set of requirements on
middleboxes or statements of fact? If the latter, it seems like there
are a bunch of ways for middleboxes to mess things up,


S 5.4.
>         generate a response, the application-layer software informs the
>         TCP implementation that it should go ahead and send the TCP ACK
>         and window update immediately, without waiting for the Delayed ACK
>         timer.  Unfortunately it is not known at this time which (if any)
>         of the widely-available networking APIs currently include this
>         capability.

Are you going to make a recommendation here?


S 6.6.1.2.
>      client a Retry Delay message, or by forcibly aborting the underlying
>      transport connection) the client SHOULD try to reconnect, to that
>      service instance, or to another suitable service instance, if more
>      than one is available.  If reconnecting to the same service instance,
>      the client MUST respect the indicated delay, if available, before
>      attempting to reconnect.

Do you want to recommend some sort of randomness around this value to
avoid avalanche?


S 8.2.
>      The table below indicates, for each of the three TLVs defined in this
>      document, whether they are valid in each of ten different contexts.
>   
>      The first five contexts are requests or unacknowledged messages from
>      client to server, and the corresponding responses from server back to
>      client:

Nit. This text is a tiny bit hard to read, because you don't list S-P,
etc.


S 10.
>      messages are subject to the same constraints as any other DNS-over-
>      TLS messages and MUST NOT be sent in the clear before the TLS session
>      is established.
>   
>      The data field of the "Encryption Padding" TLV could be used as a
>      covert channel.

Why not require this to be 0, then?