RE: Replays - thoughts on Gutmann response

> The paper suggests using the sliding-window technique for replay
> protection... (as used in IPSEC and OpenVPN)... This
> addresses Allan's
> concerns about how to simultaneously allow out-of-sequence packets,
> while preventing problems with duplicates...

Thank you, that's precisely what I've been looking for.  This is exactly the
solution I was trying to describe.

Although it does detect duplicates or replay, within the time frame or not,
I've got a niggling thought about how you slide the window when the start
actually refers to a dropped packet.  I've rewritten this bit a few times
now trying to explain what I mean, I'm wondering now if I'm assuming
something that's wrong, so bear with me while I attempt to explain myself,
even if only for my own benefit =)

I've worked through a couple of simple examples with regards a simple window
consisting of start and end packet, storing both the packet number and the
time.  This method suffers if multiple packets arrive out of order or are
dropped.  If, however, we maintain a fixed size buffer using head and tail,
we can easily cope with this, ignore packets that are too old, or if we're
processing high bandwidth, packets that haven't arrived within the time it
takes to cycle the buffer once, perhaps 200 packets as an example buffer
size?  Could be configurable with a default if desired.

This latter solution allows for the use of sequence numbers, which gives us
detection of duplicate packets, whether they're replayed or injected.  It
does rely on the sequence number remaining secure within the packet, but I'm
hoping someone else has thought that through.

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.

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,

--
Mark Smith - Avco Systems Ltd
email: [email protected]
Tel: +44 (0)1784 430996 Fax: +44 (0)1784 431078


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