Re: Squid acl access - neighbours & parents..

michael.james@canberra.edu.au writes:

>>gordon@drogon.net wrote:
>>
>>>someone close to us netwise wants to neighbour with us,
>>> but is there a way I can stop them using us as a parent?
>
>We are part of a regional network, it makes sense for us to peer
> with the other members. But like gordon we don't want to be used as
> a parent from outside our domain.
>
>My expectation of peer behaviour is that only if the request is in the cache
> is it is answered, there is no way for a peer to force a fetch.
>Am I right? If so it is OK to allow friends access to the peer port.
>
>icp_access deny !friend1 !friend2
>
>On the parent port we have these access-lists (acl)s:
>
>acl from-inside src <our class c net/255.255.0.0>
>acl for-us domain <our domain name>
>
>http_access allow from_inside
>http_access deny !for_us
>
>Now our cache runs as a parent for internal hosts and as an accelerator
> for outsiders visiting our servers.
>
>The idea behind this is to throw the bucks at the squid (big machine, fast
>network) and let a relatively small machine sit behind it running the
>httpd.
>Soon all local info is cached and only needs to be replaced as it changes.
>
>Duane, you thought there was some work to be done
> before peers could be controlled, am I missing something?

Well, I think Gordon is talking about something a little different. He
wants to let peers fetch only HIT's from him. He wants to let other
caches be peers, but doesn't want to trust them to specify him as a
neighbor and not a parent.

This gets to be a little tricky; I haven't yet decided where to add in
this new access control feature. It would be easiest to just add it to
the ICP query code, but that doesn't solve the problem of peers taking
advantage of the HTTP port. e.g. a CERN cache could direct all of its
requests at you and since it doesn't use ICP, it would "steal service"
from you.

Adding this to the HTTP port complicates things because now we
do the access control checks before figuring out if the request
is a HIT/MISS/etc. Also adding this to the HTTP port
makes the error messages confusing to the end user I think.
It seems wrong to me that sometimes a peer is allowed to use
the HTTP port and other times it is not.

Duane W.
Received on Wed Sep 11 1996 - 10:47:16 MDT