On Thu, 9 Oct 2003 02:40, Mark Smith wrote:
> Message deletion has zero impact on the data stream, only on KX. I'm
> still thinking about how to strengthen KX, I've had an evil idea of
> using a TCP stream actually inside the tunnel. Specifically the two
> daemons connect to each other via TCP using the tunnel endpoint
> addresses, which the OS should route correctly through the tunnel.
> That way KX not only looks like tunnel traffic, it really is. The
> difficulty is in working out which way it should connect, which could
> be overcome by having two channels. This has the added benefit of
> allowing a protocol extension for the scripting idea that someone
> came up with.
How about simply addressing the (current, as used at the moment,
encrypted) KX packets to tunnel.end.point.ip rather than peer.ip?
This imposes about as much overhead as the trial-decryption method for
the KX stage, but relieves the overhead for corrupted packets. The
trial-decryption method as I understand it would require every packet
which failed to checksum correctly to be decrypted twice... This method
simply routes an encrypted packet via an encrypted link. Two
decryptions for valid KX packets, one decryption for errors.
I'm not saying it's the best solution, I'm just trying to get ideas
> Please, feel free to tell me why this wouldn't work, but I can't seem
> to find a problem based on my knowledge of the protocol. If I had
> the time, I'd be working on this already.
> Any other news on any of this? Any news about mailing lists yet?
> Take care, and stay happy,
Stobor Pty Ltd
Mobile: + 61 414 470 392