Named listen addresses in VCL

[Dridi Boukelmoune]

>>I don't understand, the use cases I'm suggesting are as "unsafe" as
>>relying on ACLs with either client.ip or server.ip.
>
> With your suggestion, any traffic coming through a particular
> listen address would be trusted, even if that traffic does not
> have anything to do on that particular subnet.

That's the point of providing the mechanism. If you trust your network
because you happen to have a trustworthy and competent team of network
engineers, why turn a networking problem into an application problem?

>>You have the same problem if anything matching one of your ACLs
>>trusted address is compromised.
>
> There is a big difference between hijacking the IP of a server in
> use, which is likely to trigger alarms, and being able to attack
> using any IP going in through a particular interface.

I don't see any difference between dealing with clunky VCL constructs
and using a label to achieve the same.

> Neither is watertight, but I don't see "convenience" as a valid argument
> for increasing the sizes of the holes.

The main goal is not *mere* convenience but actual decoupling between
the application layer and the networking nitty gritty. On my dev box
the "hitch" listen address might mean localhost:8888 while in
production the hitch server may be on a different host in front of a
Varnish cluster.

With named listen addresses I can write my VCL policy once and not
require changes between environments (dev, qa, prod...) instead of
using platform-dependent server.ip.

Dridi