Re: METADATA frames for HTTP/2 and HTTP/3

On Tue, Jul 26, 2022 at 12:24 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hi David,
>
>
> On Tue, Jul 26, 2022 at 2:49 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> Hi Lucas,
>>
>> I don't think capsules are a good fit here. Our deployment involves
>> traditional HTTP intermediaries that speak standards-compliant HTTP between
>> each other, except that we want to add a little bit more information. This
>> is the very reason that HTTP was made to be extensible, to allow adding
>> features without having to build your own custom protocol like PROXY. For
>> example PROXY would be a huge performance hit because it would conceptually
>> require falling back to h1 and we see significant gains from the connection
>> reuse properties of h2 and h3.
>>
>
> Right. I'm not saying you should use PROXY protocol here (apologies if
> that was unclear). What I'm saying is that deployments that care about
> adding sidecar metadata in the way I think you are using it, probably
> already have a solution for doing that, which isn't METADATA frames. That's
> typically by virtue of some out of band or private arrangement within an
> organization or between entities with a business relationship.
>
> To quote what mnot said earlier:
>
> > There's no semantics to 'grab onto', nothing an intermediary can do
> without application-specific knowledge or configuration, etc.
>
> > If the use case is telemetry, we could talk about how that might be best
> accommodated in the protocol, and it might end up as a TELEMETRY frame (or
> header, or trailer, or resource...). As it is, this is just another
> tunnelling mechanism, and we already have a lot of options there.
>
> I agree with this.
>
> If I'm reading things correctly, it seems to make a presumption that it is
> easy to add to the long tail of HTTP applications, which I'm skeptical
> about because even things like 1xx responses are not well supported even
> today. Biren stated a desire for the METADATA frame to be treated as
> hop-by-hop, but the second paragraph of the intro states: "An HTTP
> intermediary MAY consume METADATA frames, pass them along unmodified,
> modify the payloads, or emit new METADATA frames, depending on the specific
> needs of the application" - this raises a tone of questions about what
> applications should do, beyond just what the wire format allows them to do.
> A client that can influence load balancer decisions seems bad in the same
> way that the Forwarded header field might be abused [1]. In the reverse
> direction, it might expose information about the server(s) to clients that
> could aid forms of attack.
>

This was an oversight in the -00 version of the draft, which was corrected
in the following PR. That should address those security concerns.
https://github.com/bencebeky/metadata/pull/10/files

mnot mentions tunneling mechanisms. If you only care about
> private-arrangement communications within intermediaries, there's lots of
> options. Using capsules is one such mechanism that has recently been
> defined in the IETF, which could easily support the use case. I'm not
> advocating strongly to do it that way (it probably has more overheads than
> we'd like) but it would help to understand why something like METADATA is
> prefferable to other mechanisms.
>

There is definitely an infinite array of solutions, but this one is very
practical because it is very easy to implement when you already have an
HTTP intermediary - it incrementally adds to HTTP instead of building
something from scratch.

David