Re: New Draft: draft-ohanlon-transport-info-header

[Patrick McManus <[e-mail]>]

On Mon, Nov 25, 2019 at 11:50 AM Piers O'Hanlon <[e-mail]>
wrote:

>
> The only transactions that traverse that connection are between the client
> and the “origin”.
>
>
no - connections are not limited to a single origin as far back as the h1
proxy use case and its definitely not true in h2/h3 at all. And even if it
were, that's not enough protection. HTTP exchanges are explicitly stateless
- mechanisms that ignore that to create some kind of ambient state always
cause trouble (e.g. ntlm).


> > These transactions don't necessarily share the same origin (or the same
> auth properties).
> >
> If they don’t share the same origin they’re transported on a different
> connection so would have a different CWND(s).
>

no.


>
> The CWND sent in a Transport-Info header would only be related to a single
> transport connection between one “origin" and one client over which flows
> transactions related to those entities.


I want to put up a flag here and say that even same-origin exchanges need
to be isolated from each other. Two different sets of login cookies on the
same origin don't share the same security context.


> The transactions from the same origin to other clients would be over a
> different transport connection so the cwnd would be different.
> Transactions that don’t share the same origin would be a different
> connection and contain yet another cwnd.
>
>
no.


> *when I say “origin” I mean the last hop edge node of whatever CDN serves
> the origin.
>
>
origin is the combination of scheme host and port. A CDN edge serves many
origins.


> Apologies if I’m missing your point but from what have you have described
> the side channel isn’t clear to me?
>
>
obviously the HTTP protocol is aware of this sharing - indeed it initiates
it! but the ramifications of it are generally opaque to the semantics of
HTTP exchanges (roughly expressed by headers and messages). So perhaps what
you want is better carried in the protocol (e.g. as a frame).. if you are
proposing exposing it to content it needs to be scrutinized for the same
reason that it is useful. This can be subtle - see CRIME and BREACH for
example.

hth



> Piers
>
> > On Mon, Nov 25, 2019 at 7:19 AM Piers O'Hanlon <[e-mail]>
> wrote:
> > Hi Patrick,
> >
> > Thanks for your feedback.
> >
> > I'm assuming most cross-origin issues should be dealt with by CORS but
> > were you concerned with that suggestion that the header could be
> > contained in an OPTIONS response? I can see that since such a response
> > is not subject to CORS - such as in a CORS pre-flight request - then
> > we could drop that as an approach and just keep to using HEAD requests
> > as a mechanism to obtain the Transport-Info.
> >
> > Let me know what if that doesn't address your issue or if you have any
> > other concerns.
> >
> > Piers
> >
> >
> > On Fri, 22 Nov 2019 at 21:41, Patrick McManus <[e-mail]>
> wrote:
> > >
> > > To the extent that this leaks information across origins to js its
> probably a problem too.
> > >
> > > On Fri, Nov 22, 2019 at 8:58 PM Piers O'Hanlon <[e-mail]>
> wrote:
> > >>
> > >> Hi Lucas,
> > >>
> > >> Thanks for bring that up - as you say Nginx's default for
> > >> http2_max_requests is 1000, although it can be changed (and appears to
> > >> be done so for RPC applications). I'm not sure how many other server
> > >> implementations do this?
> > >>
> > >> Firstly, we can detect this through of the use of the dstport
> > >> parameter - as a new TCP connection would use a different port.
> > >> Although it could potentially lead to temporary loss of information
> > >> for a time as discussed below.
> > >>
> > >> Secondly, the affect of this would be only apparent each time the
> > >> request count is exceeded - so say every 1000 requests - when a switch
> > >> over would occur. When a switch over does occur then it depends on the
> > >> comparative duration of the data responses of interest, versus how
> > >> often one wants to perform parallel HEAD/OPTION requests for
> > >> Transport-Info. So for the case where where the frequency of parallel
> > >> requests is about the same then I think it shouldn't matter much as
> > >> with most server systems these days the congestion control parameters
> > >> are cached in the kernel so a subsequent connection to the same
> > >> destination would be preloaded with the cached metrics so the
> > >> Transport-Info header would contain these. In the case where there's a
> > >> series of long running responses then it might be an issue as after
> > >> switch over point there would also be two parallel TCP connections to
> > >> the same point but they would exist separately for a longer period so
> > >> potentially the metrics obtained via subsequent HEAD/OPTIONS could be
> > >> different as the cwnd can be reduced for low volume flows, though
> > >> these would generally not be used since the dstport would not match so
> > >> there could be a loss of information in this case.
> > >>
> > >> Cheers
> > >>
> > >> Piers
> > >>
> > >> On Fri, 22 Nov 2019 at 10:51, Lucas Pardue <
> [e-mail]> wrote:
> > >> >
> > >> > Hi Piers,
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, 22 Nov 2019, 17:58 Piers O'Hanlon, <[e-mail]>
> wrote:
> > >> >>
> > >> >> Hi all,
> > >> >>
> > >> >> - “It only provides information per response which isn’t very
> often”
> > >> >> We mention in the draft that with H2+ one can send and arbitrary
> number of requests (using OPTIONS/HEAD) to obtain more measurements
> responses per unit time.
> > >> >
> > >> >
> > >> > I have an observation but not sure it belongs in a document.
> Implementations such as nginx have a soft max number of HTTP/2 requests
> before closing the connection (default 1000 last I checked). If you're
> trying to sample the transport info to frequently you may end ip blowing it
> up. This seems unfortunate because the client use case is designed around
> making smarter transport related decisions.
> > >> >
> > >> > Cheers
> > >> > Lucas
> > >> >
> > >> >>
> > >> >> We would welcome any more feedback by email and/or Github issues
> > >> >>
> > >> >> Thanks,
> > >> >>
> > >> >> Piers O'Hanlon
> > >>
> >
>
>