At 5:50 PM 02/01/95, kevin@elvis.wicat.com wrote:
I am not happy with my proposed advertising methods, and was quietly hoping for some guidance from internet gurus in this point (the irc suggestion in particular is a pretty shaky straw man). However, see my earlier message (on some other thread) about Usenet propagation times. Propagation times in days do not seem to be rare (post to misc.test and see when the last reply comes back). While this is better than word-of-mouth propagation, it does not offer the very low latency I was looking for.
I tried to discuss this very issue a few months ago, with little interest. But I'm glad there's someone to discuss it with now. (read, someone who will listen when I spout volumes to the list :) ) Here follows my treatise. :) We already have a solution, actually. Raph's remailer list. If you know your remailer is going down, tell Raph about it, and he'll remove you from the list. [Better would be an automatic way of removing remailers from the list upon receiving a PGP-signed message from the op, without Raph's intervention]. Presumably, if your remailer never returns his ping, it will move to the bottom of his list. So applications like his "premail", which use this list, won't send to those remailers. This is really an excellent solution, and what it doesn't do, could easily be added to it. The problem is that it's too centralized. We like decentralized things hereabouts, and Raph's list requires you to trust Raph not to lie to you, or withhold information to you. And of course a centralized solution is more subject to attack too; if someone mangaged to subvert Raph's list (either by subverting his data collection methods, or the report he generates), then an increasingly large portion of the remailer-using-public is up shit creek. Single point of failure. A partial solution is for lots of people to run remailer pinging and reporting services like Raph's. Then you could use which ever one you want, or even write a script to get info from them all and average em together (throwing out extremely oddball scores, using some sort of statistical method). A better solution to the centralization problem would be for _everyone_ to run their own remailer pinging service. This solves the centralization problem, but now when a remailer op knows his remailer is going down, he can't simply tell Raph, he's got to tell _everyone_, which is the same problem he had originally. Also, this is somewhat realistic. People have been saying for ages that the remailer net is much more secure when every user runs their own remailer, but it still hasn't happened. For obvious reasons. So we've still got the problem of how users are to tell when remailers go down. That's what I see as the basic problem here. It really divides into two problems: the "advertising" problem, and the "pinging" problem. Which actually aren't at all completely seperate. *THE ADVERTISING PROBLEM* The advertising problem consists of how remailers are to get info out to the Remailer-Net-At-Large. I run a remailer, and I know my remailer is going out of business soon (temporarily, or permanently), and I want to tell people. Or, my remailer has returned (or just started started business for the first time), and I want to tell people. ++Usenet. Non-IP, but slow. ++ Usenet is an obvious solution, but the latency is too low. But usenet does work really nicely, aside from the latency problem. Remailers post messages to alt.remailer.auto-announce, giving one of a number of standardized machine-readable messages. For instance FriendlyRemailer might post that it's going down, and expects to be down for about 24 hours. Clients, which could be other remailers, or chaining applications like premail, would periodically check this newsgroup and keep track of info. My client software might decide to stop routing through FriendlyRemailer, and completely ignore the "for 24 hours" thing, and start sending through there again when it gets an "I'm back" message over the usenet. Or it might decide to record the "for 24 hours" thing somewhere for human reading. If a new remailer appears and broadcasts "I'm here", it might add it to the list of useable remailers, or it might ignore it, or it might ask for human approval of adding it to the list. Whatever the user wants it to do. ++Direct TCP. IP-required, complicated, but fast.++ But there's still a latency problem. The only way I can think of to solve that is with direct TCP connections of some kind. IRC would be one way. Remailers could broadcast "I'm here" every 20 seconds on an IRC channel, and clients could keep an eye on this IRC channel to see what's up. Of course, then a client would need to wait up to 20 seconds before sending a piece of mail, which is kind of a pain. So, instead, you might have a background program running always, and tabulating data, so it's got data stored and doesn't need to wait at all. (If the remailer said "I'm here" a minute ago, that's good enough, dont' need to wait another minute for the next "I'm here"). And then remailers wouldn't need to broadcast as often as 20 seconds; something like 5 minutes would probably do. So bandwith is more reasonable. If a remailer goes down, and you send a message to it within 5 minutes, you are shit out of luck, unfortuantely. The problem with this solution is that everyone using it needs to be on the internet. People haven't wanted to exclude UUCP connections and such from participating in the remailernet (as remailer or client) in the past, and I think they're probably right. And IRC might not be that reliable, I don't know. And it requires a lot of proccessing power; remailers have got to be constantly sending out "I'm here", client programs have to be constantly running and scanning for this info. Might not be that scalable either, when you have 100 remailers broadcasting, and 20,000 users listening. Or more. *THE PINGING PROBLEM* The pinging problem consists of how clients (which could be other remailers) can querry remailers about whether they are up or not. (and what features the particular remailers support, which is also something that might be advertised above, incidentally.) The user is taking the initiative, as opposed to the remailer. Because maybe someone subverted your usenet or IRC or other broadcasting medium, so you don't want to place too much trust on it, and you want to check it yourself. And maybe the "advertising" medium is slow usenet, so you the last "I'm here" you got from a remailer was a dated day ago. Is it still there? You'd like a quick way of pinging it to see. Again, we have two solutions: Slower simpler, being-on-the-net unneccesary, pinging with mail; and Faster, More Complicated, need-to-be-on-the-net TCP. ++Mail ping. Non-IP, simple, slow. ++ A mail ping simply consists of sending a message to a remailer with a Request-Resending-To: yourself. When you get it back, you know the remailer is alive. This has the advantage that it's hard for the remailer to trick you, even if it is an evil NSA remailer that wants you to believe it is alive, even though it really throws messages in the trash. It can't differentuate between your "ping" (to be returned), and a normal message (to be thrown in the trash). And you can do it with a UUCP connection, or some other kind of store-and-forward non-IP connection. The problem is that it's slow. Especially with the latency that secure remailers have to put into the mix. This could be solved if you could tell the remailer somehow that this is a ping message which should be sent relatively quickly and not re-ordered and latency-added like a normal message. Of course, then you lose the advantage that the remailer can't tell the difference between a ping and a normal message. The way to deal with the high latency, would again be to have each client have a background process running and pinging periodically, and storing data. Again, if it's gone down since your last ping, you are out of luck. And this is kind of complicated, and high-bandwith. ++TCP transaction ping. IP required, complicated, but fast.++ Again, the other alternative is a direct TCP connection. Connect to a certain port, say "are you there", get an answer. I believe mixmaster will soon support direct TCP traffic transactions, it would probably be trivial to add a "pinging" feature too. Although really unneccesary. If you contact the host directly, and it answers, you know it's there, you don't need to ping. The disadvantage is again that IP is required. **CONCLUSION** Advertising and pinging methods are needed. There should be a way for a new remailer to announce itself to the net (might not be trusted or used by software, but it's up to the user), and a way for existing remailers to announce that they are going down (and announce when they come back up). There also needs to be a way for a user to "querry" a remailer individually, instead of relying on advertising, _especially_ if the advertising method is high-latency. Both the slower store-and-forward (mail, news) techniques, and the faster direct-socket-connection techniques both have advantages and disadvantages. Ideally, _all_ of them would be exist. Some remailers might only support or deal with some of them (out of choice or lack of IP connectivity or bandwith), but client software could gather info from all or some of the pinging and advertising mediums, and make choices about whether to use remailers, based on how much info it has, and what the info says. And the issue not even discussed here, is that of having a succesful way to bounce messages. If all of your advertisment-gathering and pinging fail anyhow, you should be notified that your message didn't make it through. It actually seems possible that a succesful bounce method would remove the need for advertising and/or pinging completely. But a succesful bounce method seems even more remote then succesful pinging/advertising methods.