Remailer Pings

The current method of pinging Remailers is flawed in terms of both latency and uptime measurement.

  • Measurement of latency works fine for exit Remailers but Middleman nodes have to randhop the ping back through another node. This makes the measurement totally inaccurate as it becomes the sum of two Remailer latencies, not just the one being measured.
  • Uptime measurement is flawed in two ways:-

  • Middleman nodes are treated as failed unless they have good stats, (something they otherwise don’t need). This is because they cannot return a ping directly and without stats can’t randhop it either.
  • Uptime measurement is at the mercy of Remailer latency. It can take 24 hours or more from the time of failure for a node to register a drop in uptime. This exacerbates the previous issue as the Middleman nodes take a hit if they try to randhop pings through that failed node.
  • All these problems stem from the fact that Remailers don’t understand pings. They have no capability to treat them in any way differently from standard Remailer messages.
    Here are some thoughts on what I would like to see:-

  • Uptime pings need to bypass the Remailer pool, thus providing near-instant notification when a node fails.
  • Middleman nodes need to return latency and uptime pings directly to the pinger instead of randhopping them.
  • Implementation would be nice if it took the form of remailer-xxx type commands:-

  • Sending a remailer-upping would instruct the Remailer to generate a Mixmaster message to the sending address. The message would have to bypass the pool in order to avoid the latency problem. This would prove that the node was available and (to some extent) functional. Middleman randhopping would be avoided as the Remailer would respond directly to the request, as with other remailer-xxx messages.
  • Sending a remailer-latping would instruct the Remailer to insert a message into it’s pool for the sending address. This message would need to be tagged in some way to instruct Middleman nodes to return it directly to the sender without randhopping.
  • A nice thing about all this functionality is that it would have no impact on current ping methods, they could carry on until such time as they could adopt the new functionality.

    This entry was posted in Anonymity. Bookmark the permalink.

    Leave a Reply