Re: New draft: Reverse HTTP Transport

Hey,

On Thu, Jul 20, 2023 at 10:07 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> Hi Ben and Tiru,
>
> I think I'm confused similarly to Watson here. If the use-case is
> preventing DDoS to the origin, that can be solved today by paying some
> money to a CDN company and having them act as a reverse proxy, then having
> the origin drop all IP packets that don't originate from the CDN. Why do
> you need reverse HTTP for this?
>

Not an author but: yes that's one way that things work but it is just one
form of interaction. It implies that the origin can be contactable from the
CDN, which might require it to have a public IP address. Origins can of
course lock down what sources are allowed to contact them but that requires
work and config that might go stale or invalid.

A different interaction is something like Cloudflare supports with the
Tunnels product [1], where a daemon runs on the origin and dials back to
the CDN. The origin server only allows connections from the local daemon,
the daemon connection allows multiplexing of flows from the CDN etc. The
Reverse HTTP proposal seems to resonate with some of this design.

Different customers find different value in these alternative deployment
and interaction models.

Cheers
Lucas

[1]
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/


> David
>
> On Fri, Jul 14, 2023 at 12:11 AM K Tirumaleswar Reddy (Nokia) <
> k.tirumaleswar_reddy@nokia.com> wrote:
>
>> The clients like browsers are pre-configured with relays that it trusts
>> for Oblivious HTTP transactions and is a well-known configuration. Further,
>> the relay and gateway/target are not operated by the same entity.
>>
>>
>>
>> -Tiru
>>
>>
>>
>> *From:* Watson Ladd <watsonbladd@gmail.com>
>> *Sent:* Thursday, July 13, 2023 8:51 PM
>> *To:* K Tirumaleswar Reddy (Nokia) <k.tirumaleswar_reddy@nokia.com>
>> *Cc:* Benjamin Schwartz <ietf@bemasc.net>; HTTP Working Group <
>> ietf-http-wg@w3.org>
>> *Subject:* Re: New draft: Reverse HTTP Transport
>>
>>
>>
>>
>>
>> *CAUTION:* This is an external email. Please be very careful when
>> clicking links or opening attachments. See the URL nok.it/ext for
>> additional information.
>>
>>
>>
>> Sorry I am still confused.
>>
>>
>>
>> The client knows the gateway but how does the gateway know to open the
>> TCP connection to the relay the client wants?
>>
>>
>>
>> And if we're advertising the relay as well then what's the point of OHAI?
>> The security properties depend on an administrative separation that means
>> the client has to pick.
>>
>>
>>
>> That said I can think of applications like CDN providing anti-DDOS
>> protection where the server can be firewalled off from all but outgoing
>> connections, so this whole conversation is irrelevant (but might inspire
>> more paragraphs in the eventual intro)
>>
>> On Thu, Jul 13, 2023, 4:27 AM K Tirumaleswar Reddy (Nokia) <
>> k.tirumaleswar_reddy@nokia.com> wrote:
>>
>> One of the use cases is to host a DNS over Oblivious HTTP server (DoOH)
>> without being publicly accessible but allows the clients to access the DoOH
>> server via a trusted relay. The DoOH server and associated gateway  can be
>> discovered by the client using
>> https://datatracker.ietf.org/doc/draft-ietf-ohai-svcb-config/.
>>
>> Cheers,
>> -Tiru
>>
>> -----Original Message-----
>> From: Watson Ladd <watsonbladd@gmail.com>
>> Sent: Wednesday, July 12, 2023 4:31 AM
>> To: Benjamin Schwartz <ietf@bemasc.net>
>> Cc: ietf-http-wg@w3.org
>> Subject: Re: New draft: Reverse HTTP Transport
>>
>>
>> CAUTION: This is an external email. Please be very careful when clicking
>> links or opening attachments. See the URL nok.it/ext for additional
>> information.
>>
>>
>>
>> Could you say more about the usecase? I looked over the doc briefly, but
>> am still confused.
>>
>> Sincerely,
>> Watson
>>
>> --
>> Astra mortemque praestare gradatim
>>
>>