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

[tirumal reddy <[e-mail]>]

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

-Tiru


>
> Best,
> Chris
>
> --
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai
>