Re: [Ohai] Call for adoption: draft-rdb-ohai-feedback-to-proxy

[Christopher Wood <[e-mail]>]

> On Aug 16, 2023, at 9:29 AM, tirumal reddy <[e-mail]> wrote:
> 
> On Tue, 15 Aug 2023 at 20:42, Christopher Wood <[e-mail]> wrote:
> On Tue, Aug 15, 2023, at 10:55 AM, Mirja Kuehlewind wrote:
> > Hi all,
> >
> > Sorry for my slightly delayed reply but I finally found time to fully 
> > review the draft. I agree that the problem is an interesting problem to 
> > solve but I’m less sure about the proposed approach. More generally I 
> > wonder if this signal is needed at all (or if some static config/out of 
> > band signalling is enough). Effectively the draft adds an option to 
> > signal the relay that the target is under attack. However, if the 
> > attack source is part of the relay traffic, wouldn’t the relay be able 
> > to detect the attack on its own? Maybe there are other cases for 
> > rate-limiting but the attack scenario isn’t fully clear to me. Also 
> > adding this information to one “random” http response, seem more like a 
> > hack than a clear design. 
> >
> > I’m supportive of further work in this space but I’m not sure if 
> > adopting the proposed solution is the right way forward.
> 
> For what it's worth, I tried to turn my comments into something constructive by turning them into a more complete proposal, located here:
> 
>    https://chris-wood.github.io/draft-wood-remote-rate-limiting/draft-wood-remote-rate-limiting.html
> 
> The salient points of this approach are:
> 
> 1. Rate limit rules happen out-of-band, or outside of the proxy protocol, rather than in-band. This makes it generally applicable to OHTTP, MASQUE, etc.
> 2. Rate limit rules are only allowed from authenticated targets. (This particular proposal leans on ACME based on DV as a way of targets being provisioned with authentication credentials, but this is mainly a convenience and implementation detail.)
> 3. Rate limit rules are restricted in how they can be expressed so that the mechanism can't be misused or abused to harm client privacy. As such, this proposal has limitations that are naturally complemented by privacy-preserving authentication mechanisms such as Privacy Pass. 
> 
> I'm sure there are a lot of odd or imperfect things in the draft, but in writing this down I felt a lot more comfortable with the privacy and security story given the constraints in place. Bike sheds aside, I'm curious to know what people think about the high level aspects of this alternative approach -- especially those in favor of solving this problem.
> 
> The above approach can be done using DOTS, it has DOTS data channel for this purpose which uses RESTCONF and defines filtering rules with rate-limit action 

I’ll leave it to the DOTS experts to determine if that can be extended for this purpose. However, I would like to surface my view of the threat model and essential requirements for this to be done safely (if it’s going to be done at all). Copying directly from the draft above:

# Threat Model

The remote rate limiting (RRL) protocol is based on the following threat model.
Clients are either honest or malicious. Honest clients do not engage in abusive
behavior, whereas malicious clients are carry out whatever behavior they wish,
including abusive behavior. Targets can also be honest or malicious. An honest
target will faithfully use the protocol to protect itself against abuse, whereas
a malicious target will try to use the protocol to carry out the following goals.

1. Learn information about clients. The attacker aims to use the rate limiting
   protocol to learn information about the clients behind a proxy. This information
   might include, for example, the total number of clients behind a proxy, or any
   other information that might be useful in partitioning client anonymity sets.
1. Disproportionately and negatively impact honest clients. The attacker aims to
   misuse the rate limiting protocol to single out honest clients and cause service
   disruption for them.

Malicious clients can engage in abusive behavior with the intent of disrupting service
for honest targets, or for negatively impacting the proxy service for other honest
clients.

The proxy is assumed to be honest, since a malicious proxy could easily violate
client privacy by revealing the client's IP address to targets.

# Overview

Given the threat model in {{threat-model}}, the remote rate limiting (RRL) protocol
is based on the following assumptions:

1. The definition of abuse varies widely and depends on the target service.
   In other words, targets are authoritative for what is considered abusive traffic
   that negatively affects the target.
1. Rate limiting rules can only be expressed in terms of behavior that can be validated
   by both proxy and taget. Importantly, this means that targets can only express rules
   in terms of information that both parties know. In other words, targets cannot express
   rules in terms of information they do not know. As an example, it is not possible to
   express rules in terms of the number of requests per client if the target does not know
   how many clients are behind a particular proxy, nor if the proxy does not know the number
   of requests that a particular client is sending because the client's connection to the
   target is encrypted.
1. Proxies cannot trust targets which cannot authenticate themselves, as this can
   spoofed by attackers (malicious targets). Moreover, authenticating a target does
   not necessarily mean the target is honest; an authenticated target can still engage
   in malicious behavior. As such, the rate limiting protocol cannot leak information
   to the the privacy proxy that it does not already know. In particular, the protocol
   cannot depend on application data that is encrypted and unknown to the proxy.
   This ensures that the protocol cannot be misused by targets in an attempt to
   deanonymize clients.
1. IP addresses are not suitable for authentication and authorization decisions. In
   particular, this means that proxies cannot use target IP addresses to determine
   whether or not a particular target message is authenticated.

Best,
Chris