RE: draft-nottingham-httpbis-origin-frame

I would think that server2, noticing the client’s location, should send both an ORIGIN frame indicating that it can serve content for server1, but also an Alt-Svc frame or header suggesting the use of a specific node closer to the UK.

From: Phil Lello [mailto:phil@dunlop-lello.uk]
Sent: Wednesday, March 16, 2016 12:18 PM
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: draft-nottingham-httpbis-origin-frame

A possibly related edge case worth considering; suppose server1.example.com<http://server1.example.com> is provided by a global CDN, and server2.example.com<http://server2.example.com> only exists in NZ, and the browser is in the UK.
What would be the desired behaviour if the initial connection is made to server2.example.com<http://server2.example.com> (NZ), which advertises it's also an origin for server1.example.com<http://server1.example.com> (which it is, although the closest CDN endpoint to the browser is in the UK)?
Phil

On Wed, Mar 16, 2016 at 6:35 PM, Patrick McManus <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>> wrote:

On Mon, Mar 14, 2016 at 6:59 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:

It's a small concern, because I think that the risk is small in
comparison to the potential gain, but I don't think that this is
something that we can reasonably ignore.

[until we adopt a draft this is all just kick-the-ball-around stuff]

fwiw, there is a spectrum of ways to interpret the 7540 rules that a declarative origin frame could help with. in 7540 coalescing Firefox goes a little towards the aggressive side in order to enable coalescing on a couple of content providers that want coalescing but don't always advertise consistent DNS views. This has caught a couple other providers by surprise who saw coalescing but did not expect it in an edge case (I get to explain 421 to them :)) - an origin extension that opts in arbitrary origins provides a more deterministic implementation.
I would want to address the change with strong text to make this clear (something I think, only in retrospect, that 7540 could have done stronger around coalescing rules there.) but as a practical matter the internet is moving away from addressing defining content and this just rides that wave. and sure, content-centric or named-data networking lies somewhere on that road. But its too far away to see clearly :)
Names are what identify content and signatures are what makes you believe it. The notion of DNS resolution and IP routes being directly tied to this is already long gone and folks depending on that are probably in grave peril already (i.e. http://). Which is why we already don't rely on it in https://. And if you are faced with a certificate compromise, relying on routing to save you is pretty weak solace.

When I click on my search provider button maybe I am routed to searchProvider's data center.. but maybe I'm routed to a CDN, or maybe dynamically load shifted to a fail over CDN the way CDNI talks about.. perhaps it changes every 300 seconds. maybe I'm served out of a cache (perhaps local, perhaps remote) or directed to an alternate service.. maybe my route is hijacked L4 style by a transparent device that lies about the addressing. Perhaps I'm behind a nat. Or two. Or three. Or have had my DNS spoofed via race condition. Or routed via an onion network or plain old vpn. In all of those cases the decision on whether or not to use the content is independent of addressing and routing - a declarative origin frame isn't moving into uncharted territory.

Those addresses and routes are just the ephemeral glue we use to get you to the content you want - the content doesn't inherently possess addresses or routes.. if another set of addresses and routes delivers the same verifiable content in a better way thats a good thing and loosening the implicit dependence on DNS and IP is also good thing.

-Patrick