On Mon, 28 Jul 1997, Robert Watson wrote:

Having thought about this a little more, I'd be tempted to go for a more variable data section to this. Probably in the form of a u_int8_t num_records variable, and then a number of strings representing those records, each with variable length. Also, possibly priority. Clustering similar log messages for the sakes of reducing transmissions and number of signing operations is probably a good idea, but retaining order is important too. Has anyone looked statistically at the distribution of log messages on a standard web server or user server (whatever that means?) to see whether messages cluster by source, priority, type, etc?

Is there any concensus on the use of DNSsec in the network community, as it has not yet been made widely available (or at least, it is available, but not largely used.) The key namespace here could be used however one desired, nor necessarily in a DNS-style way. The entity-name, whatever that is, simply suggests which key/algorithm should be used, a server could be configured to pull that information from DNSsec, or from an internal key-file (or both.)

Also, if we make a move to TCP, how should connection-management be worked? Presumably, one must make a connection fairly quickly on receiving to send, assuming that it passes any local authenticity requirements (e.g., a log-message must come from a key in *.my.domain to be forwarded), and then put in a queue for delivery when the transport is available. If the TCP connection is already open, and a new message doesn't arrive quickly, it should be delivered. If the TCP connection is not open, then the forwarder (or source) should wait for a certain time-out (something short) for more messages, or until the queue reaches a threshhold before opening the connection. Some delay is acceptable in log delivery, I think, but not too much. Opening the connection will involve a delay -- a T/TCP startup is probably a good idea, as data is immediately ready to send when the connection is opened, or it would not be opening.

An ACK message has already been stated as desirable -- would a simple signature over the last packet (or header + signature) using the shared secret, entity public key, or whatever, back on the TCP connection suffice? Maybe something lighter-weight?

Robert N Watson

Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Security Research, Trusted Information Systems http://www.tis.com/ Network Administrator, SafePort Network Services http://www.safeport.com/ rob...@fledge.watson.org rwat...@tis.com http://www.watson.org/~robert/