Re: why not WPAD?

Taking a step back from the details of this discussion a little bit,
the fundamental difference between WPAD and the TLS-based scheme
proposed in Salvatore's draft (as well as standard MITM) is
out-of-path versus in-path. The pros and cons of each flow from this
difference, I think.

And it sounds like the prevailing opinion (based on the experience of
the few who have posted to this thread) is that in-path is better for
reasons given above. At the same time we're trying to design an
improved "explicit proxy" for HTTP 2. But that term usually implies
configuring the address and port of a proxy explicitly in the browser,
as opposed to using network interception to discover the proxy. It
seems like we're moving towards a new model of an explicit,
intercepting proxy that makes the user aware of its presence but is
deployed in-path.

Peter

On Thu, Jan 16, 2014 at 6:31 AM, Adrien de Croy <adrien@qbik.com> wrote:
>
>
> ------ Original Message ------
> From: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
> To: "Adrien de Croy" <adrien@qbik.com>
> Cc: "Peter Lepeska" <bizzbyster@gmail.com>; "ietf-http-wg@w3.org"
> <ietf-http-wg@w3.org>
> Sent: 16/01/2014 23:09:22
> Subject: Re: why not WPAD?
>
>>
>> Le Jeu 16 janvier 2014 00:59, Adrien de Croy a écrit :
>>>
>>>
>>>  Hi Peter
>>>
>>>  actually IME the client config is the smallest problem. Usually it's
>>>  the DHCP, DNS or WPAD.dat http server.
>>
>>
>> The DNS and DHCP parts are big problems. The http one is not. Right now an
>> embedded http server in the proxy is a de facto requirement to communicate
>> with web clients, since there is no web client <-> proxy signalling layer
>> in http/1
>>
>>>  Another issue with WPAD compared to a per-connection
>>>  intercept/enforcement scheme is that it's one-off. The client performs
>>>  WPAD discovery at the start, and has a static config. After that, it
>>>  won't alter behaviour
>>
>>
>> That's a huge problem you can't notify clients a proxy went down before
>> they restart. Some users like to keep browsers open ad vitam eternam. Some
>> browsers keep stuck on the dns resolution as it happened during the
>> pacfile read, even if the dns of some web sites has changed since.
>>
>>>  If OTOH you are doing something per-connection, you have the ability to
>>>  alter/tailor behaviour. For example don't bug the client for certain
>>>  destination IPs, or source IPs, time of day etc. etc. And this has the
>>>  opportunity to greatly reduce the number of systems involved and
>>>  opportunity for errors.
>>
>>
>> That does not work so well if only part of the traffic is proxified. With
>> pacfile you can tell web client "here are internal websites, you can reach
>> them directly, don't bother with me" and in big corporations internal
>> accesses are the bulk of the traffic, forcing it to a per-connexion proxy
>> node will degrade availability and scalability.
>
>
> What I meant was really the opportunity to do something each connection
> rather than necessarily doing it.
>
> After the client knows it must use a proxy, it will not be directly
> connecting via the router that was issuing this challenge.  Normally also
> intranet traffic need not go via this either so you avoid proxying intranet.
>
> So I guess you have the same failover issues as WPAD.  But you wouldn't want
> to add another few RTs plus proxy estabilshment for each connection.
>
> Adrien
>
>
>>
>> (and sometimes a different proxy gateway sits before a private
>> non-internet link with a partner)
>>
>> Regards,
>>
>> --
>> Nicolas Mailhot
>>
>>
>

Received on Thursday, 16 January 2014 15:20:05 UTC