Re: WPAD ideas and considerations

Le Ven 14 mars 2014 05:46, Amos Jeffries a écrit :
> What can we keep and what do we need to get rid of in WPAD?
> Please add to this list
>
> WPAD currently has two well-known methods:
>
> 1) DHCP assignment
>
> Pros:
>  - DHCP ID code already available and well-known
>  - simple URI for PAC file works well for those using DHCP on the network.
>
>
> Cons:
>  - ID code limited to URI of PAC file for legacy implementations
>  - fixed information. Requires another DHCP allocation to change (or
> client to poll the DHCP server)

Does not work in most browsers
No trust management in browsers – you enable for your own equipments, if
your users roam you have a big problem
Posits all users on a network use the same pac file of that your control
of dhcp is sufficient to deploy specific rules (and update them every time
user hardware changes…)
Posits a single proxy point of entry – SPOF with no resilience
Huge hassle keeping dhcp, proxy, firewall and local client config in sync
Does basic discovery, says nothing about proxy auth
dhcp handling is a lot less centralised than dns handling

> 2) DNS search
>
> Pros:
>  - does not require DHCP

yay!

>  - can be supported by a wider range of clients more easily than DHCP
>  - DNS TTL can be specified to cause refresh of the PAC information at
> network admins choice of timing.
>
> Cons:
>  - current implementations use a scan of DNS label names for wpad.*
>  - several different client algorithms used to scan DNS. At least one of
> which is seriously broken.

Can be easily broken by local rent-a-sysadmin DNS servers (aka AD nodes)
with big forced TTLs
wpad* does not really work for complex network topologies
Weird DNS lifetimes in web clients
Weird behaviour when different clients on the same host scan at different
time and get balanced to different equipments
Still requires strong proxy/dns interactions
No pac refresh as far as I know
How do you sync dns ttls with the pac ttl sent in http headers
IPv4/IPv6 usual woes
Does basic discovery, says nothing about proxy auth

Though all of this seems eminently fixable provided the spec is tight
enough to prohibit weirdos.

-- 
Nicolas Mailhot

Received on Monday, 17 March 2014 08:19:04 UTC