Re: Paying for someone else's traffic?

On Sun, 1 Mar 1998, Henrik Nordstrom wrote:

> David J N Begley wrote:
> > I *am* reading this correctly - I *am* paying for someone else's Web
> > browsing traffic, right? :-/
[...]
> The tools you have to control this:
> 1. icp_hit_stale on/off (default off == don't return ICP HIT for stale
> objects)
> 2. miss_access, to completely deny miss accesses to your cache.

"icp_hit_stale" left at default (off); "miss_access" set to deny access
to remote proxies (the ones who shouldn't be able to, but are, refreshing
objects via my proxy).

> Due to some problems with miss_access, I would not recommend using it
> unless someone is abusing your cache.

Even if it's unintentional, "money talks" as they say. The problems with
"miss_access" only seem to affect FTP and Gopher objects (not HTTP
objects) so I've already denied access to FTP and Gopher objects (via
"icp_access deny") already - not the best solution, but the only one
available at the moment.

> miss_access can be used to force the admins of remote misbehaving caches
> to use your as a neighbour instead of parent.

That's the problem illustrated here - the proxies should only be using me
as a neighbour, and in fact that's what they're configured to do; *BUT*
the request coming through is a *refresh* which effectively makes me a
parent anyway (ie., my proxy goes off to get the object regardless).

There's two sides to this:

- my proxy should be treating "refresh" HTTP requests the same as "miss"
  requests as far as "miss_access" is concerned (so that local users can
  force a refresh, but remote proxies cannot); and,

- to stop the proliferation of bogus error messages being returned to
  end-users, Squid shouldn't send "refresh" HTTP requests to neighbour
  proxies (using ICP), only to parents.

Otherwise, there exists a very obvious backdoor through Squid's ACL
mechanism that would allow someone to bypass all caching, and all
"miss_access" ACLs thus shifting the traffic charges from one organisation
onto another. That's Bad(tm). :-(

Cheers..

dave
Received on Sat Feb 28 1998 - 18:42:41 MST