Re: Paying for someone else's traffic?

On Sun, 1 Mar 1998, James R Grinter wrote:

> On Sun 1 Mar, 1998, David J N Begley <david@avarice.nepean.uws.edu.au> wrote:
> >"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).
> but, what is a remote administrator to do when your proxy starts returning
> obviously bogus data in an ICP/TCP cache-hit scenario?

Upgrade Squid to not send refresh requests via neighbours (until ICP
requests are fixed)? After all, what's the point of "miss_access" if not
to provide protection against someone abusing a proxy (intentionally or
not)? If the access mechanisms are so easily circumvented then it's a
wonder any of us use ACLs at all.

(As for bogus data - we've already established that the proxies don't know
that anyway.)

> I trusted operators of neighbour caches to behave the right way (and its
> very easy to see that if you run daily analyses of your log files),

The problem there is that it's too late once the deed is done; as I
mentioned before, it's not necessarily something intentional, either. For
example, if a proxy admin configures their proxy (A) to be a peer of
another proxy (B) and a user of A starts firing off refresh requests for
large objects that A refreshes through B (because B had answered ICP
queries that it had previous copies of these objects) then it's not
breaking any "trust" between the admins of A and B - but it does cause
heartache for the B admin because B has done all the work and picked up
the bill for what amounts to A's traffic.

Unfair (and, depending on circumstances, quite costly), no?

> but it was useful to give them the ability to attempt to flush
> screwed-up data if necessary by connecting manually from the neighbour
> cache.

I'll let my child proxies do that. ;-)

> Money wise, if your request amounts are pretty similar, I think you'd
> find that the 'loss' is about the same on both sides.

In this case, they're not. :-(

In the generic case it's insufficient to assume that for any two given
peer proxies the request amounts will be "pretty similar" such as to
warrant absolutely no protection against this behaviour.

Of course, this raises the question - is my proxy doing the same thing to
them anyway? How can I tell? Looking in my own logs for local IP
addresses making a "REFRESH" request (TCP_REFRESH_MISS,
TCP_CLIENT_REFRESH, TCP_REFRESH_HIT, &c.) I see that they're all going
"DIRECT" - there are absolutely no "SIBLING" entries whatsoever. Is that
sufficient or is the only true indicator the remote proxy's logs?

> For figures I remember in normal cases cache-hit TCP volumes of
> neighbours were around the 98-99% mark (if you're not interfering and
> returning errors when you shouldn't be)

I'm not sure I follow - are you saying that HTTP (TCP) requests for
neighbours are generally around 98-99% with the remaining 1-2% being
misses such as these "refreshes"? (Given that the proxy has to go off and
make a remote request, often retrieving a new object, it can hardly be
called a "hit" as far as traffic is concerned.)

On Sun, 1 Mar 1998, Dancer wrote:

> Well, that's the point...What the 'remote proxy' sees is a _client_
> request. never mind that the client currently happens to be squid. An
> ICP request happened earlier for the same object, but squid can't tell
> the difference between an HTTP request from a neighbour and an HTTP
> request from a client. They're both identically formatted HTTP requests.

Neighbour or not, if the ACL says "don't do remote requests for this given
IP address" then it shouldn't do so, "refresh" or not - that's why the ACL
is there in the first place! :-)

The (non)sense in using that ACL is something that is built into any
site's local security/access policy and is not something the proxy should
"think better of" and avoid.

If that's not the case, then why don't we stop kidding ourselves and just
remove the ACLs altogether? After all, we all trust each other - right?

dave
Received on Sun Mar 01 1998 - 06:46:11 MST