Re: Replays - thoughts on Gutmann response

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 
flowing...

Cheers.

>
> 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,

-- 
Allwyn Fernandes
Director
Stobor Pty Ltd

Mobile: + 61 414 470 392
Email: [email protected]
Web: http://stobor.net/

--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>