[RC5] Pluggable client modules...

Wilson, Bruce bwilson at fers.com
Sun Dec 19 00:42:29 EST 1999

Hash: SHA1

Thanks for your reply.  You raise some good points.

|-----Original Message-----
|> The data reported to the servers includes an IP address for most
|> versions.  (I suspect the Netware version does not, for 
|example).  This
|> IP address should be a unique identifier for each machine,
|> otherwise, you've got bigger problems.  I'm also of the
|> understanding  
|that the IP
|> address of the dnetc machine is preserved even if the blocks 
|are routed
|> through a perproxy.
|But many organizations that have 300+ computers don't have unique
|IP-addresses for all machines. DHCP, NAT, IP-masquerading, etc. If
|the client is generating this IP address, the address might be in the
|192.168.*.* range, or the 10.*.*.*. If the server attaches an 
|to the logs, it'll attach the IP address of the firewall for each of
|the 300 clients.

I don't think this will be as limiting as it sounds.  I believe
(someone correct me if I'm wrong) that the IP address is captured in
the client's own log (if enabled), using the client's own "local" IP
address.  This IP address is what's reported to the next keyserver up
the line, whether it be a perproxy or one of the main proxies.  The
proxies also keep a log (optionally but recommended).  *If* (and I
already said I'm fuzzy on this point) a perproxy strips the client's IP
address and replaces it with it's own, then that is the address which
would be reported to the d.net keyservers.  The IP address available to
us in the log is transmitted as part of the data, not extrapolated by
d.net servers.

What this suggests to me is that such a mailing should also mention a
sample block which was completed by the client, along with whatever
other information we can give to help the diligent administrator trace
back through the logs to find the right client.

|It's also not true for clients running on private PCs, that 
|use a dial-up
|connection to an ISP to connect to the internet. Only a very 
|small subset
|will have the same IP address each time.

I would guess that in most of these cases, the email address itself
would give enough unique information to correct the problem.  We might
be able to filter out many of these people by looking at the number of
blocks and variety of addresses.  Perhaps we should avoid e-mailing
anyone who is generating less than 10 blocks a week at a single IP
address, or some such cutoff?  Those people are a very small part of
the problem.

|And unless the IP address is attached to each block, you would 
|also lose
|in a situation where the buffers are stored in a shared filesystem.

I don't know if the IP address is stored in the buff-out.* files, so I
can't answer this question.

|It hasn't been true for a long, long time that an IP address uniquely
|identifies a machine. Now, once IPv6 becomes popular....

True.  There are obviously lots of cases where this type of mailing
would not be useful.  I mentioned one myself - the Novell client.  My
belief is that it would be enough use to enough people to warrant a
one-time mailing of this type.  Hopefully we can screen out enough
useless cases to save people the headache when it's obviously not

Your e-mail, and others like it, have helped point out some of the
things we need to be careful of.

Bruce Wilson, Manager, FERS
bwilson at fers.com, 312.245.1750, http://www.fers.com
PGP KeyID: 5430B995

"Give me ambiguity or give me something else."

Version: PGP Personal Privacy 6.5.1


To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list