In some email I received from antirez, sie wrote:
>
> On Thu, Oct 21, 1999 at 12:03:56PM +0200, Magosanyi Arpad wrote:
> > Nearly all useful features will require TCP then:)
>
> Important features as client authentication and message signing / encryption
> can be performed in UDP without problems.
There has been a lot of agreement in continuing to support the old protocol.
The *simplest* way to do that is say that using UDP means using the old
protocol. We should stop there - that's simple enough. Enhancing the
protocol further will break that functionality, as it should be able to
both send and receive such messages.
[...]
> Are you sure that syslog2 needs public key cryptography?
Public-key crypto isn't the requirement. Using encryption is, as is using
some sort of strong hash. There are numerous gotchas in bulding your own
mechanism to do all this. Personally, I would rather use something else
that has been evaluated and examined for crypto strength for transporting
messages securely rather than trying to roll my own. If that means using
public key crpyyo to make it happen, then so be it.
> > resources for both state information and number crunching far exceeding
> > the resource requirements of vanilla tcp.
>
> I think that using TCP you will require both state informations and
> socket memory.
So what ? Memory is cheap (or was :). I hate to say it, but I have little
sympathy with people using 386sx20's with 4MB of RAM, running linux, as
"loghosts". If you want to store logs on a reliable host, it will be a
modern box with non-ancient hardware that can cope with some number of
simultaneous TCP connections.
> > > - If a connection drops with no RST, you are potentially still losing
> > > messages
> >
> > But at least you will know that you have loosed them.
>
> But only when you need to send new logs.
You always ACK important information. If the receipt of a message by a
remote syslog is important then the remote end should send an ACK back over
TCP and the sender only discards the message upon receipt of that ACK.
Depending on implementation, this may or may not result in duplicate
messages on the receiver - but this is better than losing them.
[...]
> cyptographically secure authentication using a shared secrets and UDP
> isn't less
> secure. Simply the server will drop all packets with a bad hash value. Hash
> verification can be very fast if we makes a table that links source IP
> address
> and shared secrets and hash functions like MD5 and SHA1 are light to
> compute.
If OpenSSL natively supports UDP then maybe it is worth looking twice at.
If not, then forget it.
