Re: #462: Intermediaries and Alt-Svc [was: Alt-Svc related Chromium bug report (proxy related)]

Hi Amos,

On Mon, Apr 21, 2014 at 04:42:34PM +1200, Amos Jeffries wrote:
> On 21/04/2014 3:08 p.m., Mark Nottingham wrote:
> > 
> > On 20 Apr 2014, at 4:36 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:
> > 
> >> The draft wording however is not limited to "proxies". Which was my
> >> initial report of there being a problem.
> > 
> > Yes; we've discussed this a few times on-list, but it never seemed to have made it onto the issues list.
> > 
> > I've created <https://github.com/http2/http2-spec/issues/462>.
> > 
> > Any thoughts about the suggestion there?
> 
> I think we should go with the SHOULD NOT. The cases that need to be
> enumerated IMO are that the proxy either;
>  a) drop the header completely (consumes with decision not to use the
> alt service)
>  b) uses the alt-service (as if it were the client)
>  c) passes it on un-touched (the case being forced by the MUST NOT)
> 
> I agree that a proxy has no place adding/changing field values the
> client gets. But consuming the header is a different proposition which
> has several uses already mentioned.

Well, we've had this discussion many times in the past on the list about
passing addresses/ports/protocols and whatever is routing-related from
servers to clients, which *never* works if intermediaries cannot change
them. It's always the same thing, just like with redirects where gateways
("reverse-proxies") are filled with many rules to rewrite them.

Such information can only be hop-by-hop by definition since the entity
emitting this information only knows the values to emit for the place
it is connected to (eg: private IP address, internal port, etc). And
gateways need to convert this to the new values.

Let's consider this common example : company A runs a web server in a DMZ
("safe zone") behind an apache reverse proxy acting as an SSL-offloader
and cache running in a different DMZ ("unsafe zone). The same service is
accessible from the internal LAN directly and from a partner company B
over a VPN. These DMZ and VPN are provided by one or multiple firewalls,
some of them performing NAT. This is really *common*. Many of my customers
have services built that way.


              Internet. Pub IP=1.1.1.1:80,443
                   |
                   |       Pub IP=192.168.1.1:80,443
  Company B     +-----+     +--------+
  over VPN -----| FW1 |-----| rproxy |
                +-----+     +--------+
  IP=10.0.0.1:8080 |
                   |
                +-----+     +--------+
                | FW2 |-----| server | Priv IP=192.168.2.1:8080
                +-----+     +--------+
                   |
             ------+---------  Lan with local users.
                               IP=192.168.2.1:8080

So what do we have here ?

  - a server which only knows it's running on 192.168.2.1:8080
  - local users which access it on that IP:port address
  - a reverse proxy configured to access it to that IP address:port
    and exposing it on 192.168.1.1:80 and in https at 192.168.1.1:443.
    This reverse proxy knows its public-facing IP address
  - a firewall which nats the public address 1.1.1.1 to the reverse
    proxy's 192.168.1.1 and keeps the port
  - the same firewall which NATs accesses over the VPN from parner
    company B to 10.0.0.1:8080 to 192.168.2.1:8080 (direct server access).

In such a common scenario, it is clear that it is not possible for the
server to provide a correct information about its location. Having the
public and private accesses (the most common cases) already makes this
impossible without letting each gateway adjust the values. Here it would
easily work if the server just provided http://192.168.2.1:8080 as info
and the front reverse proxy would simply adjust this to become 1.1.1.1:80
or https://1.1.1.1:443 depending on what's expected.

The company B's access over VPN is more annoying because there is no
gateway there. That means that any such information provided to this
place is wrong and cannot be used or must be modified there. It also
discloses internal information which is not always acceptable in some
places.

So at best, information provided in Alt-Svc can only be hop-by-hop and
can only be emitted/modified/filtered by gateways and must not be emitted
by origin servers if they're not authoritative. And quite frankly these
days, origin servers that can claim to be authoritative about their public
address/port/protocol become extremely rare.

Best regards,
Willy

Received on Monday, 21 April 2014 06:34:38 UTC