Can clients cancel requests/xfr?
martinthomson opened this issue · comments
STOP_SENDING would seem to be useful for this. But you will need an application error code at the QUIC level for that.
My first question is, what happens with TCP? It seems see section 2.3 of RFC 5936 that the server can drop a transfer by closing the TCP connection. According to section 4.1.1. of RFC5936, a client "can cancel the delivery of a zone only by closing the
connection. However, this action will also cancel all other outstanding activity using the connection. There is no other mechanism by which an AXFR response can be cancelled."
Given that, what should we do? We could indeed let the client issue a "STOP SENDING" request, with an appropriate application error code. (Internal error code by default, but we could create a new one.) However, I don't know whether that's the right thing. We have to be concerned about the possibility of clients ddossing the servers. With TCP, cancelling the transfer has a cost for the client, since it closes the entire connection. With the stop sending mechanism, the client could open a transfer, then cancel it, then open a new one, etc. In fact, it could try open and cancel a bunch of transfers in parallel. Is that a new attack?
But then, nothing of course prevents clients from issuing "STOP_SENDING (DOQ_INTERNAL_ERROR)". In fact, clients could do that on any pending request, not just the AXFR requests. So, at a minimum, we need to explain how the server shall react to that. My gut feeling is that the server MAY close the connection. Just for matching TCP behavior.
We may also need to explain how either peer would react to a "RESET STREAM" request. Again, I am tempted to say that the peer MAY just close the connection. @amankin, @saradickinson, what do you think?
A few minor points:
- You probably want an error code that points less to the client being broken. In HTTP, we let servers refuse requests and clients just say that they don't wan the answer.
- Why would you point to closing the connection? The point here is that you can cancel requests without having that affect the whole connection. If you are concerned about a pattern of request cancellation that might indicate that the client is abusing server resources, that's something I wouldn't attach directly to this discussion. Talk about that more generally under a heading of load management and denial of service. In that context, yes, closing the connection is a reasonable reaction (but then so is ignoring any new packets).
There is no natural way of doing cancellations within DNS - for TCP it is done purely be closing connections. Servers should send REFUSED to a query they don't want to answer.
I can see this could be useful extension to current behaviour for XFR (particularly where there are multiple transfers happening in parallel) I'm not so convinced how useful this is for regular queries but I wouldn't want to specify XFR only behaviour.
We could specify
- Clients can send STOP_SENDING(DOQ_REQUEST_CANCELLED)
- Servers MAY limit the number of cancellations received on a connection before closing the connection.
- Servers can send RESET_STREAM(DOQ_INTERNAL_ERROR) and the client should handle this in the same way as any other DOQ_INTERNAL_ERROR (e.g. apply a re-try mechanism)
- Client MAY limit the number of stream resets received on a connection before closing the connection (just as they would errors and timeouts).
Actually, we already have Section 5.3.1 that says:
If a server is incapable of sending a DNS response due to an internal error,
it may issue a QUIC Stream Reset with error code DOQ_INTERNAL_ERROR.
The corresponding transaction MUST be abandoned.
I think we need to say something similar to the reset blurb. Clients and server can send "stop sending" frames. For the server, it does not make a lot of sense because in most cases the client's stream will already be closed. For the client, that makes more sense, either if the server is waiting too long before responding or, in the case of XFR, because the client did not expect so long a response. Better specify than leave implementers guessing.
Fixed in draft 05.