Abuse-relevant headers added by proxy

[ShivanKaul]

The draft currently says "The oblivious proxy resource MUST NOT add information about the client to this request". While identifying information would obviously defeat the whole point of OHTTP, it would be useful for the proxy to add some headers that would help the server with abuse mitigation while not revealing identity.

For a simple example, the proxy (which is IP address-aware) could add an isMalicious header if it sees a request from a known abusive IP address and then forward that to the server. The server could then use that signal + the contents of the request to determine what to do with the data (if it's telemetry, then it could choose not to count it). This would also be useful for shadowbanning clients, in which case you don't want the proxy to just outright reject the request. Importantly, the server doesn't come to know anything about the client other than the fact that the proxy thinks it is abusive (which doesn't split the anonymity set by too much 😅).

[martinthomson]

This is a reasonable thing to do. The question is how we can best frame this. Implementing shadow bans by flagging requests seems like a good way to manage some aspects of this, but unbounded use of similar mechanisms could partition users too finely. We should talk about this in a working group to understand it more completely.

[chris-wood]

@martinthomson let's throw this one on the agenda for 113.

[enygren]

As discussed in the OHAI discussion on ohai-oblivious-proxy-feedback, the general issue seems to be dealing with abuse in a privacy-preserving manner. It seems like the approaches are proxy->request_resource (eg, a client reputation bit) and a private request_resource->proxy channels (eg, this request may want to degrade client reputation) channel. Rate-limiting on the proxy is just one way to deal with bad reputation.

For request_resource->proxy it might be reasonable to have more than one bit (such as either a few bits of badness-level, or perhaps a vector indicating nature-of-badness which might include things like "this request was expensive", "this request may have been malicious (eg, triggered a WAF rule)", etc).

Proxies could potentially rate-limit clients that have a high ratio of responses "suspicious" responses to non-suspicious responses. Proxies might also use some mixture of reputation information to inform what they send to the request_resource.

Note that at least some CDN services doing client reputation tend to have a vector of reputations, and this blurs into the "demographic" topic. Having a single bit might not be good enough to make good decisions in a fair manner.

It may be worth enumerating some use-cases (rate-limiting against DDoS attacks against a target, dealing with abusive clients/bots with bad reputation, etc) and to explore the design-space before jumping to a particular implementation.

[chris-wood]

@ShivanKaul does #113 address this?

[chris-wood]

Closing now that #113 has been merged. @ShivanKaul, feel free to reopen if more changes are desired.