Efficient public peer access control *without ACLs*

I had an idea and I'm looking for comments and criticism.
---------

I'm getting really frustrated with some people who are abusing the cache
registration service (tracker.nlanr.net). It tells you to ask the cache
administrator for permission and access, but alas, some bozos try to use
my cache (and probably others) without asking.

Before anyone says anything, thank goodness for ACLs.

I wouldn't mind people peering with my cache, because it's their problem
if my cache goes belly up and started doing everything wrong (i.e. stale
pages, security issues, etc.).

Here is the root of the problem: Often times, these people are from
*very* far away, usually in Europe. (as evident with nslookups, and
traceroutes, and ping response times). I'm on the west coast of the
United States.

Now I have a solution that might also benefit the super-caches (sv, sd,
pa, etc. and any other nation caches) in addition to little guys like me.

If we could implement a special feature that would add ICP clients to the
netdb, then we could selective not respond to ICP requests if the client
is to too far away. We might even send a UDP_TOOFAR response back to say
why we're denying the remote clients and that the remote cache should
stop querying the local cache for a given amount of time (UDP_TOOFAR is
made up and is in no way official). If the remote client continues to
query, then they will be ignored.

# distant_peer_deny (icmp rtt) (hops)
# If the ICP client is farther than "x" milliseconds
# away, or "x" hops, then deny.
distant_peer_deny 200 10

# distant_peer_deny_attempts (attempt)
# If the ICP client continues to query after "x"
# attempts, stop responding and the client should
# eventually think we're dead. ;-) Once the former
# rule is clear, we then will begin to respond again.
distant_peer_deny_attempts 10

#distant_peer_backoff (minutes)
# If the sibling/parent sends a UDP_TOOFAR, we should
# back off for a while until the network calms down
# and we can contact them in a descent amount of time
# and/or the unstable routes will have stabilized.
distant_peer_backoff 30

Maybe after another CS course or two, I might just do it myself.

davez

----------------------------------------------------------------------
Dave Zarzycki Student
Workgroup Server QA Tester San Jose State University
Apple Computer, Inc. zarzycki@ricochet.net
zarzycki@apple.com dave@zarzycki.ml.org
----------------------------------------------------------------------

PGP Fingerprints:
DSS/Diffie-Hellman: CB9E 2621 B4BA 3F96 3516 B312 15B4 D842 3809 EF99
RSA: 8AF2 1040 8A9C D025 47BE 70DD A51C C887

Contact pgpkeys.mit.edu for my public keys.
Received on Wed Oct 15 1997 - 22:45:36 MDT