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

[Ted Lemon <[e-mail]>]

On Wed, Aug 1, 2018 at 7:03 PM, Ben Campbell <[e-mail]> wrote:

> §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 the SHOULD NOT not MUST NOT? Do you envision situations where it
> might
> make sense to violate the SHOULD NOT?
>

You are the second person to notice this, and it has been changed in the
working version to MUST NOT.


> §5.1.2: Are there security considerations for using zero round trip
> handshakes?
>

This isn't a concern with anything in the current specification, but I've
added the following text in the Security Considerations section:

## TCP Fast Open Considerations

It would be possible to add a TLV that requires the server to do some
significant
work, and send that to the server as initial data in a TCP SYN packet.   A
flood
of such packets could be used as a DoS attack on the server.   None of the
TLVs
defined here have this property.   If a new TLV is specified that does have
this
property, the specification should require that some kind of exchange be
done with
the server before work is done.   That is, the TLV that requires work could
not
be processed without a round-trip from the server to the client to verify
that
the source address of the packet is reachable.

One way to accomplish this would be to have the client send a TLV
indicating that
it wishes to have the server do work of this sort; this TLV would not
actually result
in work being done, but would request a nonce from the server.   The client
could
then use that nonce to request that work be done.

Alternatively, the server could simply disable TCP fast open.   This same
problem
would exist for DNS-over-TLS with TLS early data; the same remedies would
apply.



> §5.1.3: "In cases where a DSO session is terminated on one side of a
>    middlebox, and then some session is opened on the other side of the
>    middlebox in order to satisfy requests sent over the first DSO
>    session, any such session MUST be treated as a separate session."
>
> By what? How would the ultimate endpoints know?
>

That's not the issue.   The issue is that if you start a session to a
caching server, it can start an arbitrary number of sessions to satisfy the
questions asked on the first session.   Those sessions are separate
sessions, with their own signaling, determined by the server that received
the initial session.   The server could also not set up a session at all.
 Tom added the following text in response to another question about this:

To illustrate the above, consider a network where a middlebox
terminates one or more TCP connections from clients and multiplexes the
queries therein over a single TCP connection to an upstream server.
The DSO messages and any associated state are specific to the individual
TCP connections.  A DSO-aware middlebox MAY in some circumstances be
able to retain associated state and pass it between the client and
server (or vice versa) but this would be highly TLV-specific.  For
example, the middlebox may be able to maintain a list of which clients
have made Push Notification subscriptions {{?I-D.ietf-dnssd-push}} and
make its own subscription(s) on their behalf, relaying any subsequent
notifications to the client (or clients) that have subscribed to that
particular notification.


>
> §5.2.2.4: "
>    If DSO unacknowledged message is received containing an unrecognized
>    Primary TLV, with a zero MESSAGE ID (indicating that no response is
>    expected), then this is a fatal error and the recipient MUST forcibly
>    abort the connection immediately."
>
> Doesn't that make extensibility difficult? What if an extension adds a new
> unacknowledged message type that uses a new primary TLV?
>

It doesn't ever make sense to send an unacknowledged TLV other than in
response to a request that indicates that that TLV is supported.   So this
isn't an issue—a client that wants the TLV will ask for it, and a client
that doesn't understand the TLV will never get it, because it didn't ask
for it.


> §6.1: "The server MUST act on messages in the order they are
>    transmitted, but responses to those messages SHOULD be sent out of
>    order when appropriate."
>
> The SHOULD seems more like a MAY, unless you mean for implementors to go
> looking for reasons to do things out of order.
>

"when appropriate"


> §6.4.1: Does "consider delinquent" entail any concrete actions beyond
> resetting
> the connection?
>

No.


> §12.2: It seems like TLS1.3 should be a normative reference, given that
> it's
> used to describe the condition for a normative statement.
>

I'm not seeing the normative statement you're referring to.  TLS 1.3 is
mentioned only twice in the document, in both cases as examples of what
could be done.


> Editorial Comments:
>
> - General: Please watch for comma splices.
>
> §1:
> -- " It is likely that future updates to these tools will add the ability
> to
> recognize, decode, and display the DSO data." That sentence may not age
> well.
>

I agree, and have removed the text (of course, my co-authors may want it
added back!)


> -- " A goal of this approach is to avoid the operational issues that have
> befallen EDNS(0), particularly relating to middlebox behaviour." Is there
> something that can be cited to describe the operational issues?
>

Sure.   I've added a reference to
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-11#section-4
(and also section 3)


> §2: There's a fair amount of procedure, including normative statements,
> described in the terminology section. That would better reserved to the
> sections that are more about procedure. Some readers only use terminology
> sections to look up terms on demand; such users may miss the procedure
> bits.
>

The authors are aware of this, and considered a rewrite of the document to
improve the situation.   However, we concluded that it was good enough as
is, and the amount of work required was not justified by the potential
benefit.   You are of course free to hassle us more urgently to do so, but
we really did think about this.   It's a lot of work, and risks muddying
the document, which is actually in pretty good shape despite this
completely valid criticism.


> §5.1, "DSO messages MUST be carried in only protocols "
> "MUST ... only" constructions can be ambiguous. Consider reformulating
> into a
> "MUST NOT" construction.
>

Done:

DSO messages MUST NOT be carried in protocols and
environments where a session can't be established according to the
definition
given above in the Terminology section ({{terminology}}).


> §5.1.3:
> -- 3rd paragraph: Should "stateless" be "stateful"?
> -- "will have no way to
>    know on which connection to forward a DSO message, and therefore will
>    not be able to behave incorrectly."
> That seems like famous last words :-)
>

Fair enough, but the bottom line is that we don't control middleboxes that
were implemented in ignorance of this spec.   We believe that such a
middlebox couldn't screw things up; it's obviously possible that we are
wrong.   But e.g. a DSO message doesn't have any recognizable names in it,
so the middlebox has no plausible place to send it unless it has a single
upstream forwarder to which it sends everything.   In this case, if it sent
the DSO message without breaking it, and sent the responses back as well,
all would be well.   It's conceivable that it might send all DSO messages
to its forwarder, but some non-DSO messages to some other server; in this
case, that other server would never see a DSO message, and all would be
well.   So yeah, sure, in principle there's probably some way for something
bad to happen, but it's pretty implausible.   I don't think there's much
point explaining this in the document, because it's pure speculation.


> §5.2.3, first paragraph: The MUST NOT seems more like a statement of fact.
>

I've changed to:

Since the ARCOUNT field MUST be zero, a DSO message
can't contain a valid EDNS(0) option in the additional records section.


>
> §5.3: The section has a number of redundant normative keywords.  Please
> consider stating them authoritatively in one place, and making the others
> descriptive
>

I assume you're talking about this paragraph, and I have edited it
accordingly:

As described above in {{header}}, an initiator MUST NOT reuse a
MESSAGE ID that it already has in use for an outstanding request
(unless specified otherwise by the relevant specification for the DSO-TYPE
in question).
At the very least, this means that a MESSAGE ID can't
be reused in a particular direction on a particular DSO
Session while the initiator is waiting for a response to a
previous request using that MESSAGE ID on that DSO Session
(unless specified otherwise by the relevant specification for the DSO-TYPE
in question),
and for a long-lived operation the MESSAGE ID for the operation
can't be reused while that operation remains active.