Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

Mark, Alex,

Thank you for your comments. I think your concern regarding intermediaries
is legitimate.

One way of moving forward would be to say that intermediaries should not
forward the self-trace request. IIUC, we already have a precedent that
requires some intercepting proxies modify the request-response: when
expect-ct: enforce is being used, an intercepting proxy (typically using a
certificate not registered to CT) has to drop that response header,
otherwise the browser would refuse to reconnect.

Though, the problem here might be lack of incentive. While intercepting
proxies would be incentivized to drop expect-ct (if they see errors due to
the header being forwarded), there would be no incentive for them to add
code for rejecting self-trace requests.

That said, if we are to adopt MT's proposal (i.e., use a response header
for indicating the location of the trace), then probably we would have
better alignment because it would be about having a list of response
headers that an intercepting proxy might want to drop (i.e. except-ct and
the trace header).

The other option would be to add a H3 settings frame that indicates that
the endpoint is an end-client. Though I would prefer having a tracing
scheme that does not require changes to endpoints.


2021年8月15日(日) 2:03 Alex Rousskov <rousskov@measurement-factory.com>:

> On 8/13/21 10:43 PM, Mark Nottingham wrote:
>
> >>    To prevent this attack, servers SHOULD serve self-trace only when
> >>    HTTPS is being used.  The assumption here is that when HTTPS is being
> >>    used, end-clients are directly connected to the server.
>
> > I'm not sure that's a reasonable assumption; enterprise MITM proxies
> > are pretty widely deployed. They may not currently implement h2 or
> > h3, but that's not something we can rely upon.
>
>
> In fact, there are enterprise MITM proxies that inspect H2 already -- we
> have been helping to test them for a few years now. I do not know about
> H3 because Web Polygraph does not support H3 yet.
>
>
> Cheers,
>
> Alex.
>
>
> >> On 13 Aug 2021, at 4:14 pm, Kazuho Oku <kazuhooku@gmail.com> wrote:
> >>
> >> Hello folks,
> >>
> >> Today Jana and I have submitted a tiny I-D called
> draft-kazuho-httpbis-selftrace.
> >>
> >> The draft specifies a well-known URI to be used for providing a trace
> of a particular HTTP/3 connection (e.g., qlog) on that same HTTP/3
> connection.
> >>
> >> One of the biggest hurdles in analyzing HTTP/3 performance issues is
> obtaining traces that show the symptoms. That is because clients being
> affected by issues have to coordinate with the server operators to collect
> the traces.
> >>
> >> This PR solves the problem by defining a well-known URI for serving a
> trace to the client on the HTTP connection that the client is using. When a
> user sees an issue, they can collect the traces themselves and provide it
> to the server operator.
> >>
> >> We have already implemented the feature in h2o, and doing so was easy,
> assuming that the underlying QUIC stack already defines callbacks for
> collecting trace events, see lib/handler/self_trace.c of
> https://github.com/h2o/h2o/pull/2765.
> >>
> >> We also have a public endpoint; to try it out, first open
> https://ora1.kazuhooku.com/test/self-trace/video-only.html (which starts
> streaming a video), then open
> https://ora1.kazuhooku.com/.well-known/self-trace. While the video is
> being served, you would see the trace flowing through the well-known URI.
> >>
> >> At the moment, we are using a custom JSON format for the trace, but
> when gzip compression is applied on-the-fly, the overhead of sending a
> trace alongside ordinary HTTP responses is less than 10%. Therefore, we
> tend to believe that this approach would work well in practice.
> >>
> >> Please let us know what you think - your feedback is very welcome.
> >>
> >> ---------- Forwarded message ---------
> >> From: <internet-drafts@ietf.org>
> >> Date: 2021年8月13日(金) 14:53
> >> Subject: New Version Notification for
> draft-kazuho-httpbis-selftrace-00.txt
> >> To: Jana Iyengar <jri.ietf@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
> >>
> >>
> >>
> >> A new version of I-D, draft-kazuho-httpbis-selftrace-00.txt
> >> has been successfully submitted by Kazuho Oku and posted to the
> >> IETF repository.
> >>
> >> Name:           draft-kazuho-httpbis-selftrace
> >> Revision:       00
> >> Title:          Self-Tracing for HTTP
> >> Document date:  2021-08-13
> >> Group:          Individual Submission
> >> Pages:          5
> >> URL:
> https://www.ietf.org/archive/id/draft-kazuho-httpbis-selftrace-00.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-selftrace/
> >> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-selftrace
> >>
> >>
> >> Abstract:
> >>    This document registers a "Well-Known URI" for exposing state of an
> >>    HTTP connection to the peer using formats such as qlog schema [QLOG].
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >>
> >> --
> >> Kazuho Oku
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
>

-- 
Kazuho Oku