search

huitema / dnsoquic

DNS over QUIC
10 stars 7 forks source link

Define unexpected error codes and greasing. #108

Closed huitema closed 3 years ago

huitema commented 3 years ago

This addresses issue #80 and #81. The PR reserves an error code with a large integer value that may be used for greasing purposes. The PR does not exactly define how to do greasing, leaving that to the discretion of developers.

saradickinson commented 3 years ago

DOQ_EXCESSIVE_LOAD is interesting, but based on previous work, you might expect push back on the that since it is a handy signal for attackers that they have hit some internal threshold the server is using. When working on DSO we ended up with an error that was just 'go away and don't try to connect again for X seconds'. A server using RFC7858 (edns0-tcp-keepalive) just has a 'I'm closing the connection` signal (timeout is set to 0) even when under load.

LPardue commented 3 years ago

I won't pretend to understand the requirements of DNS :-) What you decide to do here should fit your domain. Closing the connection when client misbehave is advisable, independent of what error code you might decide to use.

In HTTP/2 and HTTP/3 we have an error for "you're doing some pattern of behaviour I don't like" (ENHANCE_YOUR_CALM or H3_EXCESSIVE_LOAD respectively) that implementations can use. There is no requirement that they MUST use that code. Some do, and some don't. From experience debugging interop in live deployments, knowing that there isn't a protocol error has been useful.

For HTTP, an instance where a connection is closed without satisfying requests is probably the biggest signal that they tripped over some form of attack mitigation.

If it makes sense to avoid defining a new error code to resolve this issue, then I can live with that.